Thursday, 2011-03-31

*** dendrobates is now known as dendro-afk00:06
*** westmaas1 has joined #openstack-meeting00:26
*** reldan has quit IRC00:50
*** westmaas_ has joined #openstack-meeting00:59
*** reldan has joined #openstack-meeting01:09
*** Ryan_Lane has quit IRC01:18
*** reldan has quit IRC01:22
*** reldan has joined #openstack-meeting01:34
*** reldan has quit IRC01:44
*** yamahata_desktop has joined #openstack-meeting02:11
*** westmaas1 has quit IRC02:12
*** yamahata_desktop has quit IRC02:14
*** Ryan_Lane has joined #openstack-meeting02:16
*** Ryan_Lane1 has joined #openstack-meeting02:17
*** dendro-afk is now known as dendrobates02:19
*** Ryan_Lane has quit IRC02:21
*** yamahata-desk has joined #openstack-meeting02:53
*** yamahata-desk has quit IRC02:54
*** yamahata_desktop has joined #openstack-meeting02:54
*** yamahata_desktop has quit IRC03:00
*** yamahata_desktop has joined #openstack-meeting03:01
*** Ryan_Lane1 has quit IRC03:03
*** dendrobates is now known as dendro-afk03:17
*** dendro-afk is now known as dendrobates03:20
*** littleidea has joined #openstack-meeting03:57
*** dendrobates is now known as dendro-afk05:15
*** Ryan_Lane has joined #openstack-meeting05:49
*** Ryan_Lane1 has joined #openstack-meeting05:55
*** Ryan_Lane has quit IRC05:58
*** Ryan_Lane1 has quit IRC06:14
*** ttx has left #openstack-meeting06:22
*** Ryan_Lane has joined #openstack-meeting06:31
*** Ryan_Lane has quit IRC06:58
*** littleidea has quit IRC07:52
*** littleidea has joined #openstack-meeting08:03
*** littleidea has quit IRC08:21
*** reldan has joined #openstack-meeting09:05
*** reldan has quit IRC09:30
*** VanpoofFluffy-ku has joined #openstack-meeting09:46
*** reldan has joined #openstack-meeting10:09
*** reldan has quit IRC10:20
*** reldan has joined #openstack-meeting10:32
*** romain_lenglet has joined #openstack-meeting11:04
*** adjohn has quit IRC11:14
*** adjohn has joined #openstack-meeting11:20
*** romain_lenglet has quit IRC11:22
*** adjohn has quit IRC12:02
*** VanpoofFluffy-ku has quit IRC12:54
*** dprince has joined #openstack-meeting12:55
*** littleidea has joined #openstack-meeting13:36
*** edconzel has joined #openstack-meeting13:45
*** edconzel has quit IRC13:49
*** edconzel has joined #openstack-meeting13:56
*** littleidea has quit IRC14:08
*** littleidea has joined #openstack-meeting14:44
*** dragondm has joined #openstack-meeting15:03
*** adjohn has joined #openstack-meeting15:04
*** adjohn has quit IRC15:16
*** littleidea has quit IRC15:18
*** adjohn has joined #openstack-meeting15:36
*** adjohn has quit IRC15:40
*** reldan has quit IRC15:42
*** adjohn has joined #openstack-meeting15:50
*** Ryan_Lane has joined #openstack-meeting16:09
*** Ryan_Lane has left #openstack-meeting16:09
*** dprince has quit IRC16:13
*** adjohn has quit IRC16:18
*** troytoman-away is now known as troytoman16:25
*** dendro-afk is now known as dendrobates16:36
*** reldan has joined #openstack-meeting16:43
*** littleidea has joined #openstack-meeting17:00
*** dendrobates is now known as dendro-afk17:08
*** dendro-afk is now known as dendrobates17:15
*** dprince has joined #openstack-meeting17:22
*** dendrobates is now known as dendro-afk18:30
*** dovetaildan has quit IRC18:50
*** dovetaildan has joined #openstack-meeting18:51
*** dendro-afk is now known as dendrobates18:51
*** zul has quit IRC19:23
*** zul has joined #openstack-meeting19:33
*** reldan has quit IRC19:35
*** zul has quit IRC19:44
*** dprince has quit IRC19:52
*** zul has joined #openstack-meeting19:57
*** ewanmellor has joined #openstack-meeting19:58
*** jbryce has joined #openstack-meeting19:58
*** jbryce has quit IRC20:00
*** jbryce has joined #openstack-meeting20:00
jbrycesoren, vishy, dendrobates, ewanmellor: you guys around?20:03
ewanmellorAnd dendrobates waved a couple of minutes ago.20:04
vishyjesse is next to me20:05
*** johnpur has joined #openstack-meeting20:05
vishyi'm afk for one min20:05
* soren sets a timer20:05
johnpurhi folks20:05
vishybak20:07 internet is flaking20:07
openstackMeeting started Thu Mar 31 20:07:22 2011 UTC.  The chair is jbryce. Information about MeetBot at
openstackUseful Commands: #action #agreed #help #info #idea #link #topic.20:07
jbryce#topic More frequent releases20:07
*** openstack changes topic to "More frequent releases"20:07
jbrycechuck sent out a note talking about more frequent releases...there was some discussion on the list about it20:08
johnpuri'm wondering if the issue can be handled by projects self-identifying stable branches?20:09
jbrycethe existing temporary policy that we had put in place previously basically said that all core projects would release together on a time basis, but that in between that releases were basically up to the individual projects20:09
vishyjohnpur: i had a similar idea20:09
johnpurrather than packaged releases?20:09
dendrobatesthere was always the intention to allow subproject to have more frequent releases20:09
dendrobatesoriginally at least20:09
dendrobatesthey would then pick one release to be the version included in the overall openstack release20:10
vishybasically 3 repos: trunk . tested . release20:10
johnpurthis would be adequate for the RAX product teams, i think20:10
johnpurand be simple20:11
vishymoving from trunk to "tested" would be determined by the team, either through automated or manual testing and qa20:11
dendrobatesthat means that they will be managing those releases outside of ttx's domain, right?20:11
jbrycevishy: does that sync up at some point to an "openstack release"?20:11
vishyjbryce: my thought is that when we do an "openstack release" we just copy the most recent tested into "release"20:11
vishyjbryce: obviously there is a little more to it than that20:12
dendrobatesall that an openstack realease has to mean is that these are the versions that we have tested and work together well20:12
johnpurdendrobates: yes, ttx is focussed on the OS idenified releases20:12
vishyjbryce: but that is the basic idea20:12
vishydendrobates: right we need to put extra effort into integration and upgrade paths when we move things into release20:12
jbrycei think the points ewanmellor brought up about longer term support are really valid too20:12
johnpuralso, the points that ewanmellor brought up about enterprise adoption and timing/testing cycles are right on20:13
dendrobateslike ewanmellor said upgrade between openstack releases is important20:13
vishyjbryce: exactly i think we only need to provide upgrade paths between the "release", but it gives more frequent options for bleeding edge deployments that can't handle the instability of trunk.20:13
vishyit would be good to find out from chuck if this idea would work for them.20:13
johnpurthiss is what chuck and the RAX CF team are doing now, essentially20:14
vishywe are planning a summit discussion about how we could do this and automate it for nova.20:14
sorenI don't think I fully understand what is being proposed.20:14
dendrobatesit's very similar to what ubuntu does with lts releases20:14
jbrycesoren: i'm right there with you20:14
jbrycesounds like a few different ideas being tossed around20:15
vishysoren: basically we have the current trunk20:15
vishyeach build from trunk goes through automatic/manual testing20:15
vishythere is some process to move one of these builds into "testing"20:15
vishynot sure what the best name for this repo is20:16
vishyi think debian calls it "unstable"?20:16
sorenThat would be trunk.20:16
vishybut they are basically "more stable/tested versions of the code"20:16
sorenvishy: That really feels like we're giving up on trunk.20:16
sorenI don't think stuff should hit trunk until it's gone through the test battery.20:17
vishysoren: I think it is very optimistic to think that trunk is going to be stable enough20:17
johnpurthe one add is that we need to be able to "freeze" a stable branch... this is the interim "release" that chuck talks about, perhaps it is a production version for someone that will only take show-stopping bug fixes20:17
sorenvishy: How is it more optimistic to think that the same thing, named differently will be stable?20:17
vishysoren: think about how large the test battery is supposed to be.20:18
sorenvishy: *massive*20:18
vishysoren: merging will likely become a nightmare if every bugfix has to wait for the whole battery to run.20:18
vishysoren: ultimately I agree with you i would like trunk == testing20:18
johnpurthis branch will not only get the OS automated testing, it will likely be the version that devops in target organizations will be testing extensively20:19
vishysoren: I just don't think we are there in a reasonable amount of time20:19
sorenThe alternative seems to be that once a broken thing lands in trunk, *everything* after it will also fail to reach the "stable" thing, until the original breakage is fixed.20:19
vishysoren: + some projects may want to include manual testing.20:19
vishysoren: correct20:19
sorenvishy: I have some ideas how to pull this off.20:20
vishysoren: say we make a large change that breaks one little-used hypervisor20:20
sorenvishy: I firmly believe we can keep trunk stable without impeding development.20:20
vishysoren: if there are a lot of branches dependent on that change20:20
vishysoren: all merges are held up until the fix is in for that hypervisor20:20
sorenvishy: I'd love to have this discussion, but I think it's the wrong forum.20:20
vishysoren: agreed, i was just going to suggest20:21
*** troytoman is now known as troytoman-away20:21
vishysoren: this is the summit discussion we want to have20:21
dendrobateswe also need to think about how much of this should be mandated by this board20:21
vishysoren: the more important question is can projects provide a "stable" branch that isn't the official openstack "release".20:22
dendrobatesI think we need to leave most of this up to the sub project20:22
jbrycedendrobates: agreed...i think it should mostly be around the major openstack releases where things need to work well together20:22
vishyI think that they should be able to, but I would prefer to not call it a "release"20:22
vishyfor the reasons around upgrading that ewan mentioned20:22
vishypeople should know that if they are using these other branches that upgrades crossing multiple versions and integration with other components aren't supported20:23
jbryceso it seems like there are 2 issues (tell me where i'm wrong):20:24
*** reldan has joined #openstack-meeting20:24
jbryce1) getting updates/fixes/features out in individual projects between openstack releases20:25
jbrycethis one i think should mostly be up to the projects as long as the projects are able to have stable, compatible software when combined release time comes around20:25
jbryce2) longer term support for organizations who don't want to/aren't able to update on less than X month bases (12? 18? 24?)20:26
johnpurfor #1 there has to be a stronger statement on interop and compatibility20:27
johnpurit is useless to have a stable version (say of glance) that is broken from the stable version of nova20:27
sorenSee, if we're serious about having Ubuntu as our reference platform..20:28
sorenUbuntu promises to have a working upgrade path from one LTS to another.20:28
sorenIn terms of OpenStack releases, that means that upgrades for N to N+8 must work, for specific N.20:29
sorenso we could use that as our goal.20:29
sorenSo we at least line up with *something*20:29
dendrobatesbut ubuntu could do that work20:30
vishyas long as we are clear in our messaging about the difference between an "openstack release" and a "project release" I think we are fine.20:30
johnpursoren: don't disagree, but this is a different topic than the one chuck brought up20:30
sorenjohnpur: Sort of.20:31
sorenjohnpur: It's a specific example of a consumer of our code that has specific requirements about upgrade paths.20:31
johnpurwe need to give guidance on what a project release is and what the expectations are20:31
sorenjohnpur: One that is well-defined and known *right now*. We can make all sorts of guesses about what sort of upgrade frequency this or the other enterprise wants, but this is known, existing data.20:32
vishyexpectations: 1) they need a project release that lines up with openstack release schedule.  2) They should expect to spend time on that release focusing on interop and upgrades20:32
jbrycejohnpur: you think project releases should be uniform across all the projects for every project release?20:32
vishy3) upgrade path between OS releases should be required20:33
johnpurjbryce: hmmm... i just don't want there to be a random proliferation of "project releases" that all have differing expectations on what is delivered, what needs to be upgradable, etc.20:34
jbrycesoren: do you foresee doing 3 mo releases forever (thinking in terms of your n+8 comment)20:35
johnpurexpectation on interop, etc.20:35
vishyfyi, in another meeting as well right now so I'll be a little slow to respond20:35
dendrobatesjbryce: god I hope not20:35
sorenjbryce: At least for the foreseeable future.20:35
sorenjbryce: Once things start settling down, we might go for longer release cycles.20:36
jbryceit doesn't seem like we're really coalescing around a specific plan on this one right now. i think discussing at design summit is a good idea20:37
jbrycealso, i have to admit that i have a lot less experience shipping software that users are going to deploy on their own than building software that i get to push to them, so i'd love if someone who has more experience there wanted to volunteer to help coordinate this20:39
johnpursuggestion: let's have someone actually describe what the monthly release for swift will look like, workflow and repository-wise. Swift is easy, as it has no dependencies. then, let's look at Nova and how we would manage keeping glance, network, volume, and compute in sync20:39
johnpurit may be that there is too much to handle less than 3 month cycles for compute20:40
dendrobatescould swifts monthly releases just be milestones in lp?20:40
johnpurdendrobates: likely, but they don't want to maintain private branches to match the deployed code20:40
ewanmellorI agree that this would be good to discuss at the summit.  We need representatives from Nova & Swift at least.  Also, I think it would be good to have representatives from distros (e.g. Ubuntu, Citrix).Could someone own this, and co-ordinate the discussion at the summit?20:40
dendrobatesthose milestones could be a part of a larger OS release20:41
dendrobateseach milestone can have a branch/tarball associated with it20:41
jbryceewanmellor: i can organize the discussion and ask a lot of dumb questions if there will be smarter people there to help answer them. = )20:42
ewanmellorjbryce: Thanks, that would be useful.20:42
jbrycejohnpur: do you want to ask chuck or someone to work on that release description for swift?20:44
jbryce#action jbryce to schedule summit discussions on releases; include projects representatives and distro experts20:45
jbryce#action johnpur to coordinate release process description for frequent swift releases20:45
jbryceanyone have anything else on this topic they want to get out there now?20:46
jbryce#topic PTL nomination requirement20:46
*** openstack changes topic to "PTL nomination requirement"20:46
jbrycethis was the other question chuck raised over email20:47
jbryce"I would like to propose the requirements of the PTL should be changed so that in order to be nominated, and serve as PTL, that person must also be a core contributor to that project.  Currently, the only requirement is that the PTL has a commit to the code base.  I don't foresee this being an issue in this election, but could see it being an issue down the road."20:47
johnpurI agree.20:47
jbryceone of the reasons why it was laid out the way it was is because of the makeup of the core teams with respect to rackspace employees20:49
vishyit doesn't really block people, it just means that they have to go through the "get added to core" process before they can be nominated.20:50
jbrycecore teams have been overwhelmingly made up of rackspace employees20:50
johnpurhard to imagine that a ptl could even be effective, having not been a core contributor20:50
jbrycesounds like most people agree...ewanmellor do you have any thoughts on it?20:52
jbryce#info agreed that PTL nominees should be members of the project's -core team20:53
ewanmellorI'm ambivalent.  I agree with johnpur that the person likely won't be effective unless they've done the job, but I agree with jbryce that it's good not to put additional barriers that make it look like non-Rackers are kept out.20:53
jbrycewe are getting a little more diversity on the nova-core team at least20:53
ewanmellorI think that the election should be enough to decide whether the person is capable of doing the job or not.20:53
ewanmellorSo I'm a +0.20:54
jbryce#topic Other stuff...20:55
*** openstack changes topic to "Other stuff..."20:55
jbryceanyone have anything else they want to discuss?20:55
vishyperhaps "nominated by a core member is enough"20:55
vishygetting one core member to vouch for you is a lot easier than becoming a core member20:55
jbrycethat's not a bad idea20:56
ewanmellorYes, good compromise.20:56
johnpurdo we want the person who is leading the project to not be able to approve merges on their own? Seems a little off to me, but hey...20:56
jbrycejohnpur: which seems off? being able to do it or not being able to do it?20:57
johnpuri vote that the ptl needs to be a core contributor. the ptl position should be hard to obtain!20:58
sorenI forget, who can vote for PTL's?20:59
johnpurcontributors to the project20:59
jbryceanyone who has had code accepted for that project20:59
vishyif someone wins the ptl and they aren't in core, we should add them.  I honestly think this is never going to happen...20:59
sorenpeople with a commit in the tree or members of ~openstack on lp?20:59
jbrycevishy: i agree that it's never going to happen20:59
vishysoren: they used the Authors file20:59
sorenIsn't it awesome how that is guaranteed to be up-to-date? :)21:00
* soren pats himself on the back21:00
jbrycesoren: yes!21:00
vishysoren: yes, some rockstar added a test.21:00
* jbryce pats soren on the back too21:00
jbryceok...well...that's time. i'll send an email out on the PTL issue21:00
*** troytoman-away is now known as troytoman21:00
jbrycethanks guys!21:01
*** openstack changes topic to "Openstack Meetings: | Minutes:"21:01
openstackMeeting ended Thu Mar 31 21:01:22 2011 UTC.  Information about MeetBot at . (v 0.1.4)21:01
openstackMinutes (text):
*** ewanmellor has quit IRC21:06
*** troytoman is now known as troytoman-away21:14
*** johnpur has left #openstack-meeting21:19
*** dendrobates is now known as dendro-afk21:29
*** dendro-afk is now known as dendrobates21:50
*** edconzel has quit IRC22:12
*** dragondm has quit IRC22:15
*** adjohn has joined #openstack-meeting23:13
*** jsgotangco has joined #openstack-meeting23:32
*** jsgotangco has quit IRC23:42

Generated by 2.14.0 by Marius Gedminas - find it at!