14:00:35 #startmeeting oVirt Weekly Sync 14:00:35 Meeting started Wed Jul 25 14:00:35 2012 UTC. The chair is mburns. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:35 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:00:40 * sgordon is here 14:00:44 #topic Agenda and roll call 14:00:48 #chair oscherieb 14:00:48 Current chairs: mburns oscherieb 14:00:55 * lpeer is ere 14:00:58 its oschreib 14:01:00 * oschreib here 14:01:00 * quaid is here 14:01:02 * rickyh here 14:01:15 * dustins here 14:01:19 mburns: you got my nick wrong 14:01:30 * lpeer is here 14:01:32 #chair oschreib 14:01:32 Current chairs: mburns oscherieb oschreib 14:01:48 oschreib: sorry...fat-finger... 14:02:03 * lh is here 14:02:31 Agenda: Status of Next Release 14:02:31 Sub-project reports (engine, vdsm, node, infra) 14:02:31 Upcoming workshops 14:02:33 * jb_netapp here 14:02:34 here 14:02:54 * RobertM here 14:03:02 any objection to doing the workshop update first so those people don't have sit around through the release discussion? 14:03:18 +1 14:03:23 +m mburns 14:03:29 +1 14:03:34 ok 14:03:40 #topic oVirt Workshops 14:03:43 lh: you're up 14:04:37 'o, 14:05:12 hmm... 14:05:25 ok, guess lh isn't here at the moment 14:05:36 so in the interest of not wasting time, we'll go to release status 14:05:39 #topic Release Status 14:06:01 looks like my topic 14:06:05 oschreib: you're up 14:06:13 so nothing special. 14:06:23 just need to decide about release. 14:06:36 Hi 14:06:37 #info no more blockers at https://bugzilla.redhat.com/showdependencytree.cgi?id=822145&hide_resolved=1 14:06:40 #link https://bugzilla.redhat.com/showdependencytree.cgi?id=822145&hide_resolved=1 14:06:58 bottom line - there are no more reported blockers 14:06:59 oschreib, May I ask, how ready are we, if we decide to pull the trigger? 14:07:24 oschreib: we should discuss: https://bugzilla.redhat.com/show_bug.cgi?id=842948 14:07:31 oschreib, I would have liked to have our ducks in a row re website and release notes before launch 14:07:33 it came up yesterday 14:07:49 There are still a lot of "TODO: check if this is in the 3.1 release" notes in the release notes 14:08:07 ok, one by one. 14:08:29 Also, I was hoping to have one or two video demos before the release (sure, they're not essential but they would have been nice - I need a volunteer to record the demos) 14:08:30 dneary: I guess the RN can be fixed. 14:08:35 * dneary keeps quiet 14:08:46 sgordon: any thought? 14:09:22 oschreib, well there are still a number of items on release notes which have not been confirmed as in 3.1 14:09:30 dneary: I wouldn't delay the build on instrumentation. but that's my opinion only. 14:09:36 i emailed maintainers directly and didn't get yay or nays either way 14:09:40 instrumentation? 14:09:56 they also dont have installation or upgrade instructions 14:10:02 dneary: videos and such 14:10:05 http://wiki.ovirt.org/wiki/OVirt_3.1_release_notes 14:10:55 sgordon: I see 5 TODOs there, I think we can get the needed info quickly. 14:11:03 sgordon: I sent some comments but I see they are not updated in the wiki, should i update the wiki directly? 14:11:08 oschreib, You mean documentation? 14:11:13 dneary: indeed 14:11:29 lpeer, yes sorry, i am concentrating on ones that weren't covered at all before implementing that feedback ;) 14:11:31 sgordon: install instructions for ovirt-node should be identical to 3.0 14:11:40 can we just point to the install guide for that? 14:11:43 still need to confirm use sanlock for pool locks (need to see if made ovirt 3.1) 14:11:52 native spice usb support (need to see if made ovirt 3.1) 14:11:52 spice wan options (need to see if made ovirt 3.1) 14:11:56 oschreib, Not suggesting that they should be blockers, but I am suggesting they should be a higher priority :) 14:12:01 new cpu models: sandy bridge and opteron G4 (need to see if made ovirt 3.1) 14:12:01 vnc details screen (need to see if made ovirt 3.1) 14:12:04 danken: can you please help sgordon regarding sanlock? 14:12:44 referring to install guide depends on me knocking it into shape with correct instructions based on where all the bits are going in the next hour or two 14:13:03 (deciding where the bits are going the day before release kind of leaves me in a bad spot here ;)) 14:13:31 all the bits will go into the stable repo 14:13:49 sure, but the structure is different 14:13:54 sgordon: if you don't have input, just drop them from RN 14:14:30 sgordon: we will put everything in the new format 14:15:14 all rpms under http://www.ovirt.org/releases/3.1/rpm/Fedora/17/ (most of them under noarch) 14:16:08 I left beta in tack for now. 14:17:07 RobertM: that's fine, but the official repo should be different 14:17:15 dneary: anything I'm missing? 14:17:44 oschreib, Sorry - dual meetings... catching up 14:18:13 oschreib, I'm afraid I don't know what you mean 14:18:24 Do you mean anything else re RN we need to talk about? 14:18:46 dneary: indeed 14:18:51 where is ovirt-release going to sit in the structure? 14:19:13 ovedo: can you help with native spice usb support 14:19:26 oschreib, sgordon owns the release notes - when he's happy, I am :) 14:19:29 ovedo: do you know if it make it to ovirt 3.1 release? 14:19:45 14[[07OVirt Global Workshops14]]4 !10 02http://wiki.ovirt.org/w/index.php?diff=3974&oldid=3817&rcid=4068 5* 03Lh 5* (-547) 10made updates to add details re: upcoming workshops 14:19:46 note: owning them doesn't mean you can't contribute.... ;) 14:19:59 sgordon, The headers for the "quick start" at the end of the page - do you need to fill out those sections before the release? 14:20:05 ideally yes 14:20:10 sgordon, Agreed 14:20:15 im particularly concerned about upgrade 14:20:26 given that nobody seems to have actually tested it successfully... ;p 14:20:31 sgordon, Also, you mentioned wanting to have the upgrade process from 3.0 to 3.1 confirmed as working before the release? 14:20:47 sgordon, jbrooks has spent a lot of time trying... 14:20:48 upgrade doesn't work? 14:20:59 mburns, There's a thread on the Users list about it 14:20:59 that should be blocker, IMO 14:21:00 well the only one who tried on that thread was jbrooks 14:21:03 and it didn't work for him 14:21:05 wait, guys, we're jumping 14:21:07 * mburns hasn't caught up on users list yet 14:21:22 well we're jumping because i need working upgrade instructions for the RN 14:21:32 that's fine 14:21:32 key word, working 14:21:34 ;D 14:21:52 currently, upgrade is in the release criteria 14:22:03 but is probably a PITA 14:22:23 since we moved from F16 to F17, and changed from using our own jboss rpm 14:22:30 to the official one 14:22:46 not mentioning multiple configuration location changes and such 14:23:46 oschreib: that's fine, upgrade can be "export db, install ovirt clean on f17, import db, run this script or series of steps to migrate old database to new database" 14:23:53 but we need something that works 14:23:53 having to move between fedora releases is probably almost going to be a problem though 14:24:03 unless our release cadence ends up faster than fedoras 14:24:05 * dneary agrees with mburns 14:24:45 otherwise early adopters are in trouble 14:24:52 and we don't want to hurt early adopters 14:24:53 i just need those instructions, and probably more importantly someone to actually verify they work 14:26:07 mburns: it's more complicated than that, since we the user will need to re-install hosts (setup will re-generate the keystore) 14:26:37 oschreib: ok, so have steps for backing up and restoring the keystore too 14:26:47 mburns: and again, testing the F16 to F17 upgrade is a huge pain 14:27:09 oschreib: the point is that we need *something* 14:27:22 and if we don't have that something, we can't release, IMO 14:27:22 if that's the decision it's fine. 14:27:32 by not testing it ourselves we are forcing that testing on our users instead 14:27:57 migrating the keystore is not trivial 14:28:04 i'm not opposed to community testing 14:28:09 i think re-installing the hosts is simpler. 14:28:16 mburns, sure, but not post-release 14:28:17 itamar, Do we have any docs on migrating the keystore? 14:28:18 ;) 14:28:20 sgordon: right 14:28:34 should be in alpha/beta 14:28:35 dneary, not that i'm aware of. 14:28:36 not in GA 14:28:52 itamar: that works if we ignore local storage domains 14:29:09 reinstalling those hosts would wipe the storage domains (at least with node) 14:29:11 Workaround for 839677 could be mentioned in installation manual. 14:29:26 mburns: reinstall as in "install host" via the GUI 14:29:26 re-install hosts should not wipe the local store. 14:29:48 re-install is just in engine side (click re-install host when it is in maint). 14:30:00 for node, removing/adding should also work 14:30:19 ok, not sure if that has ever been tested before 14:31:26 This might be a silly question... how would a 3.1 engine work with 3.0 nodes? 14:31:47 if the keystore is the issue, not at all 14:31:53 in a 3.0 cluster level, it should 14:32:14 oschreib, that is after re-adding/installing the hosts though no? 14:32:25 sgordon: that's another thing, 14:32:39 sgordon: on a clean 3.1 install, 3.0 hosts should work 14:32:53 sgordon: upgrade is not a well-known teritory 14:32:54 yeah but i think dneary was suggesting it as a workardound 14:32:59 *workaround 14:33:37 workaround? I don't get it. 14:33:49 Sounds like the release needs to be delayed until the upgrade process is sorted out. 14:33:52 guys, bottom line - we don't KNOW if the upgrade works 14:34:18 we can 1. release without upgrade path (well, it's F16 to F17 upgrade, really not trivial) 14:34:34 and the users can exports vm before, and reinstall ovirt-enigne 14:34:49 2. delay until we get input on upgrade - that's at least two weeks delay 14:35:02 and fix issues that we're not aware og. 14:35:03 of* 14:35:39 if we choose 2 - we need some community help to test it. 14:36:27 sgordon, Yes, thanks - you read my mind :) 14:36:55 Sounds like the real question here is whether the upgrade process is really a blocker or not. ;) 14:37:10 jclift, That does about sum it up 14:37:23 And the question will come up for RHEV also 14:37:24 jclift: it's currently in the release criteria, I would +1 the idea not supporting it in this release. 14:37:30 since we are only releasing it in ovirt, not yet to fedora, i think upgrade can wait a bit 14:37:36 dneary: sgordon: yes, it's a workaround, but it also means that a lot of the new features will be unavailable 14:37:40 MUST: Upgrade from previous release 14:37:43 for the fedora distro, we need to revisit 14:38:01 Sounds feasible to me. 14:38:15 itamar: so our early adopters are out of luck? 14:38:16 That's purely personal opinion tho. ;) 14:38:35 mburns: "Don't upgrade yet, we're still working out if it's feasible" 14:38:43 mburns, no, just have to wait a couple more weeks for an upgrade path (3.1.1) or something like that. 14:38:45 It's uncertainty 14:38:53 (or a documented path to upgrade) 14:38:58 There's no guarantee that if we block on this that it will be resolved in 2 weeks 14:39:35 Will there be a 3.1.1? There wasn't a 3.0.1 14:39:35 mburns: about early adopters - well, they can always export the data, nothing is lost 14:39:35 I'd suggest being honest that we do not recommend upgrading from 3.0 to 3.1 14:39:39 i'll agree as long as there are people that are actively working on it and it's not going to just slip out... 14:39:53 "3.1 supports a clean install. we are still working on upgrade from 3.0". I know its not great, but i think this version got delayed week by week quite enough. 14:39:55 And then working to provide an upgrade path, in anticipation of future releases 14:39:58 and have us in the same position for 3.2 14:40:24 Better to admit that upgrade sucks than say it works and have someone lose days trying to make it work 14:40:28 the upgrade is going to be a pain, until our packing infra is stable, yes 14:40:30 dneary: "To upgrade, you'll need to export all of your 3.0 vm's, then manually re-import them to your 3.1 setup" 14:40:39 dneary: (or similar wording?) 14:41:05 jclift, Yes, modulo comments on keeping old database, re-initialising keystore, etc 14:41:10 i'd rather take a look of what it will mean to give a process to migrate not involving export/import of all VMs, though it is of course the simplest for us. 14:41:22 That also means documentation exporting an importing steps. 14:41:59 ok, so we're ok to release, but only with the no upgrade caveat 14:42:11 are there people who will be investigating steps to do an upgrade then? 14:42:32 itamar, If that's what we're sure works, then that's what we should document 14:42:50 my view: 14:42:50 1. release 3.1, say no upgrade yet, use export/import. 14:42:50 2. check if there is a reasonable upgrade path not involving #1 (db script to fix the issue in upgrade, certificate migration, etc.) 14:43:08 people can wait for #2, or go with #1. 14:43:09 We can always say something on users@ later, and encourage people to come up with better upgrade scripts 14:43:35 Again, the important thing is that we're honest about what we're sure works 14:43:53 +1 itamar 14:43:53 export/import process is just creating an export domain and exporting the VMs to it, deatching it and attaching to the 3.1 and importing the VMs? 14:43:54 Are we sure there is a working upgrade path? 14:44:21 what about backup of user permissions etc? 14:44:22 RobertM: no, that's the whole discussion about. 14:44:35 there is also rather large storage overhead 14:44:40 acathrow, Hi there 14:44:46 with export/import option 14:45:01 hence i say people can wait for #2 to maybe get a better solution. 14:46:08 OK, sounds like a vote to me 14:46:17 unless mburns want to discuess https://bugzilla.redhat.com/show_bug.cgi?id=842948 first 14:46:40 oschreib: there is that one, and https://bugzilla.redhat.com/show_bug.cgi?id=842119 14:46:52 you proposed that the second might be a blocker 14:46:59 but that's upgrade, so we can probably defer that 14:47:19 14[[07OVirt 3.1 release notes14]]4 !10 02http://wiki.ovirt.org/w/index.php?diff=3975&oldid=3973&rcid=4069 5* 03Sgordon 5* (+686) 10/* Installation Instructions */ Rough 'upgrade path' 14:47:38 oschreib: first one is ugly, but dougsland is working on a fix 14:47:53 and as long as people don't reboot, we should be ok 14:48:03 mburns: do you think it's an release blocker? 14:48:05 14[[07OVirt 3.1 release notes14]]4 !10 02http://wiki.ovirt.org/w/index.php?diff=3976&oldid=3975&rcid=4070 5* 03Sgordon 5* (-12) 10/* Upgrade Instructions */  14:48:22 oschreib: normally, i'd say yes 14:48:33 since a reboot of ovirt-node will cause it to be unresponsive 14:49:02 but i don't know what the time impact is for vdsm to get a fix in 14:49:45 I'm afraid to say, it sounds like a blocker to me. 14:50:32 danken: ping -- https://bugzilla.redhat.com/show_bug.cgi?id=842948 14:51:15 dougsland: ^^ 14:51:47 oschreib, are you asking my opinion about blocker? or fix? 14:51:52 or both 14:51:53 :) 14:52:04 dougsland: both 14:52:26 oschreib, blocker: IMHO I would say yes. 14:52:53 oschreib, I don't have a fix yet 14:53:15 oschreib: looking at probably ~1 week for fix to get in 14:53:16 oschreib, however, mburns is the right person to say about node blocker 14:53:29 oschreib: then 1 week for stability 14:53:35 a bit more time might allow the updated qemu to get into the node -- no f16 or F17 hosting is awkward... 14:53:54 and i would +1 blocker for this issue 14:55:00 Might I suggest for the next release (not this one) that we include some of the marketing & documentation preparation as a requirement to release? If the release notes aren't ready, or we have not got an installation guide/upgrade guide, we really shouldn't be releasing 14:55:14 We run the risk of disappointing visitors who come to the site 14:55:20 dneary: sure you can 14:55:29 dneary: i agree, but let's defer that discussion until after we this release out 14:55:44 dneary, Last week it was decided that lack of install doc's would be a blocker 14:56:17 so to get back on track -- vote on 842948 being a blocker 14:56:28 +1 14:56:39 +1 14:56:41 do we really need a week post this fixed rather than just test this specific issue? 14:56:43 +1 14:56:55 that is what we put in our criteria 14:56:56 yes 14:57:27 i'd agree with waiving that requirement as long as nothing but node changes 14:57:38 agreed. 14:57:38 node+vdsm that is 14:57:52 mburns, Yes, I agree 14:57:58 i'm troubled by every week one thing comes up, fixed, another week, another thing comes up, etc. 14:58:03 but we do want to put it in beta repo for a day or two 14:58:31 mburns, (about deferring the discussion) 14:59:12 oschreib: yes, i'll build, post to beta, then if we can get at least 1 person outside of node and vdsm teams to ack, then we should be good 14:59:45 itamar: i agree, but i'd rather delay like this than release something that is known broken 15:00:11 and have users just decide that this is too unstable and go to some other solution 15:00:47 mburns, We're talking about 842948 as the blocker? 15:00:51 yes 15:00:55 Is it the only one? 15:01:10 yes, it's the only one that's been proposed 15:02:11 ok, so it sounds like we need to block 15:02:17 3 +1's and no -1's 15:02:42 #info need to block on https://bugzilla.redhat.com/show_bug.cgi?id=842948 15:02:42 indeed 15:03:07 next release date -> 08.08? 15:03:25 oschreib: we can do that, but release earlier if we're ready 15:04:30 mburns: agreed 15:04:38 I'll be away when the release comes up 15:04:53 Should we do a fresh pull of the engine? 15:04:54 this gives us a bit more time with release notes and screencasts too 15:05:01 Who do we have who can spend some time working with sgordon ensuring that the release notes are accurate? 15:05:13 And who has 3.1 running, and can do some screencaps for me? ;) 15:05:29 dneary: I can do that 15:05:36 dneary, I can too 15:05:37 dneary: about RN 15:05:57 RobertM: fresh pull? 15:06:10 i'll work on node related RN 15:06:19 and work on getting fixed image posted 15:06:29 anything else to discuss? 15:06:43 yes, 15:06:46 install guide is WIP 15:06:48 oschreib, Pull in the last weeks worth of minor fixes to the 3.0 branch to the 3.1 branch 15:06:48 great oschreib, jbrooks! 15:06:57 + we need ovirt-release updated 15:06:59 but the upgrade discussion can wait for next week 15:07:06 sgordon, I can help go throughh the install guide 15:07:19 dneary, to be honest it's mostly finding search and replace issues 15:07:23 RobertM: you mean, rebase the engine_3.1 upstream branch? 15:07:27 plus working out how to stuff my branch back into git 15:07:29 oschreib, I can keep testing upgrade as well 15:07:39 i can work on ovirt-release 15:07:40 jbrooks: I'd appriciate that 15:07:44 oschreib, Perhaps we can be proactive on the users list, say that the upgrade process doesn't work well, explain why, and ask for help making it work 15:07:48 oschreib, Make new RPM based on the branch 15:08:16 robertm, 3.1 branch didn't change. only thing exepcted to go to it is a fix to the db upgrade script to try and solve the upgrade issue 15:08:18 Perhaps there's someone on the list who cares enough about the upgrade to help make it work 15:08:47 ok, lets sum some actions 15:08:58 #action oschreib to help sgordon with RN 15:09:09 dneary: That's a really good idea. 15:09:34 #action jbrooks to give some screenshoots to sgordon 15:09:55 dneary: Make it an action point for yourself? i.e. to ask on users list for assistance with that 15:11:01 #action mburns to work with vdsm team on a fix for 842948 15:11:12 #action mburns to update ovirt-release 15:11:31 jclift, I can bring it to the list, if it's not over-stepping my bounds 15:11:37 lets first see how our investigation into making the upgrade works + the db patch goes, then ask for people to try it (though upgrade is very hard to "test". once you upgraded you can only go back if you didn't do any change (add/remove vm, etc.) 15:11:40 i thought it was already on the list 15:11:48 dneary: There are bounds? 15:11:55 jbrooks has been documenting his efforts in response to that thread 15:12:01 jclift, stepping on toes, if you prefer 15:12:14 Yeah, no idea. 15:12:18 Srry. :) 15:12:33 though perhaps we need to redirect that discussion in light of what we talked about today wrt exporting/importing the VMs and doing fresh installs of the engine and hosts 15:12:46 sgordon, Yes, I mean the "upgrade's basically broken, and won't get fiexd for 3.1 because..." message 15:12:51 I don't know the details 15:13:34 dneary: lets wait with this msg 15:13:40 and review it next week 15:13:53 oschreib, Happy to follow your lead 15:15:49 ok, sounds like we have our actions 15:15:53 anything else with release status? 15:16:37 nope 15:16:42 ok 15:16:43 nope from my side 15:16:51 #topic workshops 15:16:58 lh: anything to report? 15:17:20 mburns, not much new but to recap 15:17:30 http://wiki.ovirt.org/wiki/OVirt_Global_Workshops 15:17:37 the wiki is up to date with all workshop info 15:17:40 #link http://wiki.ovirt.org/wiki/OVirt_Global_Workshops 15:17:57 we're full up (50 participants) for ovirt at LinuxCon North America and are adding additional free of charge seats for registrants 15:18:22 I will be sending a follow up email to the board asking for their help in sponsoring additional seats for LC North America and for KVM Forum + oVirt at LC Europe 15:18:49 And asking the Board companies to help us with promoting the workshops and the 3.1 release (when it is ready to ship) 15:18:53 LCNA is full, we'll be adding additional seats 15:19:06 #info LCNA is full, we'll be adding additional seats 15:19:08 The Open Virtualization Alliance has agreed to promote the workshops and 3.1 to their membership 15:19:25 And IBM agreed to promote the 3.1 release via their newsletter and social media channels 15:19:36 #info will be asking for help from board to sponsor additional seats with LCNA and LC Europe 15:19:54 #info OVA will be promoting the workshops and 3.1 release to membership 15:19:58 I have boilerplate text available should any board companies like to forward to their media/PR/comms teams to promote the workshops and 3.1 release 15:20:03 mburns, that's all I have for now, thanks. 15:20:06 #info IBM will promote 3.1 via newsletter and social media 15:20:46 #info boilerplate text is available from lh if anyone would like to forward to their media/PR/comms teams to promote workshops/releases 15:20:48 lh: thanks 15:20:54 #topic Other topics 15:20:59 anything else to discuss today? 15:21:09 mburns, my pleasure. folks should keep an eye out for mail to board@ovirt.org with details 15:21:27 going once... 15:21:41 One question 15:22:19 SRPM for 3.1 are we going to be generating those for the 3.1 release only? 15:22:38 not sure i follow... 15:22:42 Or are we going to be generating them with the new build 15:22:51 There are no SRPM 15:22:57 inside the beta repo 15:22:59 RobertM: they should always be posted with new rpms 15:23:05 as should tarballs 15:23:15 RobertM: the srpm are in the src dir 15:23:26 mburns: if we need .tar.gz, we better upload them now 15:23:31 they need to be moved around a bit as well 15:23:33 oschreib: ack 15:24:02 oschreib: those should be posted 15:24:04 Missed those 15:24:13 RobertM: http://www.ovirt.org/releases/beta/src/ 15:24:16 i'll handle getting node tarballs up when we have the new build 15:24:19 Was expecting them to be in an SRPM folder 15:24:43 should we move rpms from beta repo to 3.1? 15:24:47 maintain both? 15:24:59 RobertM: yes, there was mis communication about how we should share source 15:25:06 Or put then im the 3.1 and symlink the beta? 15:25:15 minimum is tarball 15:25:27 but if we're providing rpms, srpms should be posted alongside as well 15:25:40 oschreib: i'd vote to move rpms into 3.1 15:25:49 then update beta to point to 3.1 15:25:58 mburns: sounds good to me 15:26:04 oschreib: hmm, maybe maintain both short term though 15:26:14 until we get new ovirt-release rpm posted with new structure 15:26:39 * mburns will try to update that today and post new version 15:27:06 ok, anything else? 15:27:44 nope 15:27:54 ok, thanks everyone 15:27:57 #endmeeting