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