| *** dendro-afk is now known as dendrobates | 00:27 | |
| *** littleidea has quit IRC | 01:00 | |
| *** dendrobates is now known as dendro-afk | 01:43 | |
| *** littleidea has joined #openstack-meeting | 01:52 | |
| *** dendro-afk is now known as dendrobates | 02:02 | |
| *** littleidea has quit IRC | 02:09 | |
| *** littleidea has joined #openstack-meeting | 02:30 | |
| *** littleidea has quit IRC | 02:32 | |
| *** troytoma` has joined #openstack-meeting | 03:05 | |
| *** westmaas_ has quit IRC | 03:06 | |
| *** kpepple_ has quit IRC | 03:06 | |
| *** sleepsonthefloor has quit IRC | 03:06 | |
| *** Daviey has quit IRC | 03:06 | |
| *** xtoddx has quit IRC | 03:06 | |
| *** errr has quit IRC | 03:06 | |
| *** Adri2000 has quit IRC | 03:06 | |
| *** annegentle has quit IRC | 03:06 | |
| *** alekibango has quit IRC | 03:06 | |
| *** jeremyb has quit IRC | 03:06 | |
| *** troytoman-away has quit IRC | 03:06 | |
| *** _cerberus_ has quit IRC | 03:06 | |
| *** jbarratt_ has quit IRC | 03:06 | |
| *** comstud has quit IRC | 03:06 | |
| *** chmouel has quit IRC | 03:06 | |
| *** ke4qqq has quit IRC | 03:06 | |
| *** antonym has quit IRC | 03:06 | |
| *** zul has quit IRC | 03:06 | |
| *** soren has quit IRC | 03:06 | |
| *** devcamcar has quit IRC | 03:06 | |
| *** dovetaildan has quit IRC | 03:06 | |
| *** vishy has quit IRC | 03:06 | |
| *** tr3buchet has quit IRC | 03:06 | |
| *** termie has quit IRC | 03:06 | |
| *** errr has joined #openstack-meeting | 03:14 | |
| *** Adri2000 has joined #openstack-meeting | 03:14 | |
| *** annegentle has joined #openstack-meeting | 03:14 | |
| *** zul has joined #openstack-meeting | 03:18 | |
| *** soren has joined #openstack-meeting | 03:18 | |
| *** jbarratt has joined #openstack-meeting | 03:18 | |
| *** alekibango has joined #openstack-meeting | 03:18 | |
| *** jeremyb has joined #openstack-meeting | 03:18 | |
| *** chmouel has joined #openstack-meeting | 03:19 | |
| *** devcamcar has joined #openstack-meeting | 03:19 | |
| *** ke4qqq has joined #openstack-meeting | 03:19 | |
| *** antonym has joined #openstack-meeting | 03:19 | |
| *** Daviey has joined #openstack-meeting | 03:19 | |
| *** westmaas_ has joined #openstack-meeting | 03:20 | |
| *** kpepple_ has joined #openstack-meeting | 03:20 | |
| *** sleepsonthefloor has joined #openstack-meeting | 03:20 | |
| *** xtoddx has joined #openstack-meeting | 03:20 | |
| *** _cerberu` has joined #openstack-meeting | 03:20 | |
| *** dovetaildan has joined #openstack-meeting | 03:20 | |
| *** vishy has joined #openstack-meeting | 03:20 | |
| *** tr3buchet has joined #openstack-meeting | 03:20 | |
| *** termie has joined #openstack-meeting | 03:20 | |
| *** _cerberu` is now known as _cerberus_ | 04:55 | |
| *** adjohn has joined #openstack-meeting | 05:55 | |
| *** adjohn has quit IRC | 09:51 | |
| *** ovidwu has quit IRC | 10:43 | |
| *** ovidwu has joined #openstack-meeting | 10:43 | |
| *** ovidwu has quit IRC | 11:28 | |
| *** ovidwu has joined #openstack-meeting | 11:28 | |
| *** adjohn has joined #openstack-meeting | 11:30 | |
| *** ovidwu has joined #openstack-meeting | 11:31 | |
| *** dprince has joined #openstack-meeting | 12:11 | |
| *** adjohn has quit IRC | 12:35 | |
| *** ric has joined #openstack-meeting | 12:41 | |
| *** chuck_ has joined #openstack-meeting | 13:45 | |
| *** zul has quit IRC | 13:45 | |
| *** chuck_ is now known as zul | 13:46 | |
| *** zul has joined #openstack-meeting | 13:46 | |
| *** adjohn has joined #openstack-meeting | 14:11 | |
| *** adjohn has quit IRC | 14:38 | |
| *** creiht has joined #openstack-meeting | 14:39 | |
| *** johnpur has joined #openstack-meeting | 15:25 | |
| *** edconzel has joined #openstack-meeting | 15:59 | |
| *** dendrobates is now known as dendro-afk | 16:32 | |
| *** dendro-afk is now known as dendrobates | 16:58 | |
| *** dendrobates is now known as dendro-afk | 17:11 | |
| *** Xenith has joined #openstack-meeting | 17:28 | |
| *** westmaas_ is now known as westmaas | 17:31 | |
| *** dendro-afk is now known as dendrobates | 17:49 | |
| *** johnpur has quit IRC | 18:37 | |
| *** danwent has joined #openstack-meeting | 19:53 | |
| *** colinnich has joined #openstack-meeting | 19:56 | |
| *** ric has quit IRC | 19:57 | |
| *** User871 has joined #openstack-meeting | 20:04 | |
| *** dprince has quit IRC | 20:06 | |
| *** User871 has quit IRC | 20:07 | |
| *** ttx has joined #openstack-meeting | 20:31 | |
| *** dabo has joined #openstack-meeting | 20:40 | |
| *** Vek has joined #openstack-meeting | 20:50 | |
| *** dubs has joined #openstack-meeting | 20:51 | |
| *** adiantum has joined #openstack-meeting | 20:51 | |
| *** jaypipes has joined #openstack-meeting | 20:53 | |
| *** jlmjlm has joined #openstack-meeting | 20:57 | |
| *** adiantum has quit IRC | 20:58 | |
| *** jk0 has joined #openstack-meeting | 20:58 | |
| jk0 | hi | 20:59 |
|---|---|---|
| ttx | o/ | 20:59 |
| *** justinsb has joined #openstack-meeting | 20:59 | |
| dabo | o/ | 20:59 |
| vishy | o/ | 20:59 |
| *** anotherjesse has joined #openstack-meeting | 21:00 | |
| dendrobates | o/ | 21:00 |
| soren | o/ | 21:00 |
| *** murkk has joined #openstack-meeting | 21:00 | |
| sandywalsh | o/ | 21:00 |
| ttx | ok, let's get started... | 21:00 |
| ttx | #startmeeting | 21:00 |
| openstack | Meeting started Tue Mar 29 21:00:49 2011 UTC. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. | 21:00 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic. | 21:00 |
| ttx | Welcome everyone to our weekly meeting... | 21:01 |
| ttx | Today's agenda: | 21:01 |
| ttx | #link http://wiki.openstack.org/Meetings | 21:01 |
| *** comstud has joined #openstack-meeting | 21:01 | |
| *** User679 has joined #openstack-meeting | 21:01 | |
| ttx | No actions from last week... | 21:01 |
| ttx | Moving directly to: | 21:01 |
| ttx | #topic Current release stage: QA | 21:01 |
| *** openstack changes topic to "Current release stage: QA" | 21:01 | |
| ttx | We are 9 days away from GammaFreeze, which will happen late on April 7. | 21:01 |
| ttx | Like for the Bexar release, I just pushed back the Gamma milestone by two days so as to maximize the open bugfixing time... | 21:02 |
| ttx | before we switch to release-targeted bugfixing for the last 3 days before release. | 21:02 |
| jaypipes | cool with me... we need it. | 21:02 |
| ttx | Worked well last time | 21:02 |
| ttx | #info Until GammaFreeze, all bugfix branches are accepted, so the idea is to go and fix as many of them as you can. | 21:02 |
| ttx | #info We no longer accept feature branches: core teams should reject proposed branches that add a new feature or change default (non-buggy) behavior, unless they have a standing exception. | 21:03 |
| *** eday has joined #openstack-meeting | 21:03 | |
| *** dragondm has joined #openstack-meeting | 21:03 | |
| ttx | #topic Cactus Release status | 21:03 |
| *** openstack changes topic to "Cactus Release status" | 21:03 | |
| ttx | All the targeted features that had feature freeze exceptions got recently merged. | 21:04 |
| ttx | We have two feature branches left with FeatureFreeze exceptions that expire tonight, I'd like us to review them to see if that should be extended. | 21:04 |
| *** ewanmellor has joined #openstack-meeting | 21:04 | |
| ttx | Please consider that the cost of a standing feature freeze exception is double: | 21:04 |
| ttx | it diverts review resources from bugfixing and bugfix reviews... | 21:04 |
| ttx | and it introduces instability in the code base, hindering testing. | 21:04 |
| *** Ryan_Lane has joined #openstack-meeting | 21:05 | |
| ttx | Both result in a less stable release. The longer the exception stands, the higher the cost. | 21:05 |
| ttx | First BMP to consider is: https://code.launchpad.net/~justin-fathomdb/nova/volumes-api/+merge/54464 | 21:05 |
| ttx | So this is still under heavy discussion, so it doesn't seem close to merging... | 21:05 |
| ttx | My opinion is that it's too late for this release and should now be deferred. Opinions ? | 21:05 |
| anotherjesse | ttx: why doesn't it seem close to merging | 21:06 |
| anotherjesse | ttx: I thought the needs fixings were for style issues | 21:06 |
| ttx | anotherjesse: it has a disapprove, no approve. | 21:06 |
| justinsb | I don't think we can look customers in the eye and tell them to use the OpenStack API if it doesn't support volumes | 21:06 |
| *** spectorclan_ has joined #openstack-meeting | 21:06 | |
| justinsb | I believe the only remaining issue is the Disapprove, which is about whether it should go in to Cactus or not | 21:06 |
| anotherjesse | justinsb: I agree - sucks to have to tell customers they have to use ec2 api | 21:06 |
| ttx | justinsb: when do you think it would be ready for merging ? | 21:07 |
| vishy | this may be a general problem with time based releases, but I think we aren't offering much to users in cactus without a more complete openstack api | 21:07 |
| justinsb | ttx: It is ready | 21:07 |
| *** johan_ has joined #openstack-meeting | 21:07 | |
| justinsb | ttx: IMHO :-) | 21:07 |
| ttx | justinsb: so you think it can make it tonight ? | 21:07 |
| pvo | ttx: agree we need to get the api finished | 21:07 |
| ttx | justinsb: in which case it doesn't need an extension :) | 21:08 |
| alekibango | +1 | 21:08 |
| justinsb | I personally think it should not be an extension | 21:08 |
| justinsb | But I had given up hope of that | 21:08 |
| jaypipes | vishy, all: the goal of cactus was *parity with the OS API 1.0*. and testing. this isn't in the goals of cactus. | 21:08 |
| soren | vishy: Well, this release was supposed to be about stability and deployability. I do think we made great strides in those areas. | 21:08 |
| ttx | justinsb: I mean, a feature freeze exception extension. | 21:08 |
| justinsb | Oops... sorry, overload of 'extension' word - sorry! | 21:09 |
| anotherjesse | jaypipes: we had assumed that the api when released would include volumes | 21:09 |
| anotherjesse | but it came so late and didn't | 21:09 |
| *** littleidea has joined #openstack-meeting | 21:09 | |
| jaypipes | anotherjesse: who assumed what? I didn't assume that. | 21:09 |
| jaypipes | I'd like to make it clear that I don't think the volumes code is bad. just that it isn't for cactus, IMO. Nothing that was ever said about the goals of this release would point to including volumes. Period. | 21:10 |
| vishy | soren, jaypipes: Customers are actually trying to deploy cactus. If we push out cactus now, we're basically telling them they have to use ec2_api if they want volumes. That makes me sad, but I don't have a good suggestion aside from delaying the release. | 21:10 |
| justinsb | vishy: I don't think we need to delay the release | 21:11 |
| *** adiantum has joined #openstack-meeting | 21:11 | |
| justinsb | I think I can resolve any style issues in a few hours | 21:11 |
| justinsb | It's just about whether volumes goes in or not | 21:11 |
| ttx | I certainly won't delay the release on an unplanned feature. | 21:11 |
| justinsb | That I can't resolve easily | 21:11 |
| jaypipes | vishy: believe me, it makes me sad, too. But if volumes had a blueprint that was Essential, and people made it a priority, it would have already been in there. but it wasn't and isn't. | 21:11 |
| justinsb | So the question is: Is the OpenStack API the one we expect customers to use, or is the EC2 API? | 21:11 |
| ttx | I might consider extending the merging deadline fopr this one is there is consensus that it should be part of cactus. | 21:11 |
| sandywalsh | gotta have OS API | 21:12 |
| jk0 | OS API | 21:12 |
| jaypipes | sandywalsh: volumes is not in the OS API. Period. | 21:12 |
| justinsb | No volumes => customers that want to use volumes should use the EC2 API though | 21:12 |
| justinsb | So if we want customers to use the OS API => we need volumes in there | 21:13 |
| *** masumotok has joined #openstack-meeting | 21:13 | |
| anotherjesse | justinsb: ++ | 21:13 |
| ttx | justinsb: that's a failure in the API definition I guess... | 21:13 |
| tr3buchet | so in a few hours volumes can be in OS api? | 21:13 |
| justinsb | I thought packaging it as an extension was a nice compromise | 21:13 |
| justinsb | tr3buchet: Yes, particularly if I sacrifice my Java principles :-) | 21:14 |
| tr3buchet | sounds like a good compromise! | 21:14 |
| ttx | justinsb: how much more time do you expect to need to get it merged ? | 21:14 |
| justinsb | I didn't see Dan's review until just now | 21:14 |
| jaypipes | gah.. | 21:14 |
| justinsb | But I can probably resolve the issues today | 21:14 |
| justinsb | Other than "should it go in" | 21:14 |
| tr3buchet | if a few hours is the difference between recommending the OS api instead of the ec2 api, i think it's an easy decision | 21:14 |
| ttx | justinsb: the FFe still stands until the end of today. | 21:15 |
| _cerberus_ | I'm with jaypipes. I think allowing it would set a precedent we don't want. | 21:15 |
| ttx | I won't take it back :) | 21:15 |
| justinsb | Can we try to resolve the "should it go in" question now pls? | 21:16 |
| justinsb | That's the real barrier, not the style stuff | 21:16 |
| vishy | I vote for should go in | 21:16 |
| justinsb | I vote in, obviously :-) | 21:16 |
| dendrobates | _cerberus_: what is that precedent? | 21:16 |
| tr3buchet | yeah i was just about to ask that | 21:17 |
| jaypipes | this is exactly why the process of documenting blueprints, prioritizing those blueprints and discussing them in the public square is so critical... so we don't get into just this kind of situation where "oh, a customer wants this, so we *have* to put this feature in even though it doesn't relate to the stated goals of the release". | 21:17 |
| _cerberus_ | dendrobates: we'd be opening the gates for anyone to argue their feature belongs in the release? | 21:17 |
| jaypipes | _cerberus_: exactly what I've been trying to say. | 21:17 |
| soren | _cerberus_: ++ | 21:17 |
| jaypipes | we go from a stated process to "release by marketing". | 21:17 |
| _cerberus_ | Yep | 21:17 |
| soren | This discussion belongs months ago. | 21:18 |
| anotherjesse | jaypipes: volumes api isn't a marketing feature | 21:18 |
| justinsb | Isn't this just an oversight though? Does anyone really not think volumes belongs in the OS API? (If we were in a world without blueprints etc) | 21:18 |
| vishy | jaypipes, _cerberus_: who is this project for? | 21:18 |
| tr3buchet | this branch was already granted FFe? | 21:18 |
| jaypipes | anotherjesse: that's precisely what it is. you just said "how do we convince people to use OS API without it". sorry, that's marketing. | 21:18 |
| anotherjesse | jaypipes: it is core functionality | 21:18 |
| justinsb | I don't think it's marketing... marketing will tell them to use the OS API no matter what :-) | 21:18 |
| jaypipes | anotherjesse: if it is, it should have been voted as Essential. | 21:18 |
| dendrobates | I think it should come down to risk and impact | 21:18 |
| justinsb | It's our job to make sure it works :-) | 21:19 |
| anotherjesse | we've been asking since the first design summit how to move to openstack api | 21:19 |
| ttx | dendrobates: it's low-risk, which is why I granted an exception, expiring tonight | 21:19 |
| _cerberus_ | vishy: customers, certainly. What I'm saying is we should take the time to learn from our poor planning, not shovel things in | 21:19 |
| anotherjesse | and were told to wait for the openstack 1.1 api | 21:19 |
| anotherjesse | which came too late | 21:19 |
| pvo | isn't this irrelevant if justinsb gets it in? | 21:19 |
| vishy | _cerberus_: agreed, planning on this feature was botched | 21:19 |
| pvo | vishy: don't disagree there either | 21:19 |
| justinsb | pvo: The barrier to getting it in is whether we can agree that it belongs in | 21:19 |
| sandywalsh | and, it's an extension so it's OS 1.1 anyway | 21:19 |
| ttx | ok everyone --- | 21:19 |
| tr3buchet | i think if he was granted the FFe, he's got until tonight. | 21:19 |
| dendrobates | I don't think it has to set a precedent, if we don't let it | 21:20 |
| jaypipes | vishy: if you're trying to imply that I don't think OpenStack is for its users, you're off target. I'm trying to get us to think about releases in a professional, consistent manner, so that our users can say "OK, I understand what this release is about, and I understand what is coming in the next one". | 21:20 |
| jbryce | i think justinsb is right when he said it was oversight. many (including some devs in this meeting) thought the new api would be able to expose the underlying features of the system | 21:20 |
| anotherjesse | jbryce: ++ | 21:21 |
| vishy | _cerberus_, jaypipes: we should definitely improve the process, but blocking a feature that makes the project usable, because it wasn't in the planning and priorities is silly. | 21:21 |
| *** old_devel has joined #openstack-meeting | 21:21 | |
| jaypipes | vishy: silly? hmm. no, I think that's what consistency is, and is the whole point of consistent, train-based, timed releases. | 21:21 |
| ttx | So, from a release management perspective, this feature can land until EOD today. If it passes the nova-core reviews and gets in, it's fine by me | 21:22 |
| dendrobates | If we resolve not to allow it again and discuss process at the summit, I don;t think letting this in would do any harm | 21:22 |
| jaypipes | vishy: delaying for some feature is what defines marketing-driven releases or releases of software for a single user or few users. | 21:22 |
| pvo | ttx: EOD what timezone? | 21:22 |
| tr3buchet | this conflict ensures allowing it doesn't set a precendent. It should have been discussed months ago, but wasn't. here's our chance to rectify that. | 21:22 |
| ttx | EOD Hawaii time | 21:22 |
| eday | besides volumes, what about the other holes in OS API? shared IPs haven't made it in yet either, so we still can't support all core functionality via OS. Any other features? | 21:22 |
| *** reldan has joined #openstack-meeting | 21:22 | |
| eday | it may be pointless to try to get volumes if other parts are not yet supported in OS, and we need to push ec2 anyways | 21:23 |
| vishy | eday: floating_ips are not in, shared_ip groups are a bit moot | 21:23 |
| soren | eday: Shared IP's as in EC2 style floating ip's or as in cloud servers shared ip groups? | 21:23 |
| vishy | eday: I think they are only needed for rackspace | 21:23 |
| ttx | justinsb: but given that it was very unplanned I won't grant an extension, so if it doesn't make it today... it's out | 21:23 |
| ttx | justinsb: is that fair ? | 21:23 |
| justinsb | ttx: I think the real issue isn't the FFE | 21:23 |
| justinsb | ttx: It'll either make it today or not at all | 21:23 |
| jaypipes | I'm willing to lift my Disapprove on volumes in favour of a community consensus to push it through (because I actually do believe in a democratic process). I've said my piece on this and will continue to argue it in the future and at the summit. | 21:23 |
| eday | soren: floating IPs, what the core supports (we don't have shared ip groups, RS, in any way yet) | 21:23 |
| justinsb | ttx: So I think the FFE point is moot | 21:23 |
| ttx | justinsb: ack. | 21:24 |
| justinsb | jaypipes: That would be great, thank you | 21:24 |
| soren | eday: I know. That's why I wondered :) | 21:24 |
| anotherjesse | the real issue was that we still don't have ownership of the api | 21:24 |
| anotherjesse | we didn't get it until a couple of weeks ago - and didn't know it was a gap | 21:24 |
| ttx | anotherjesse: soren pushed a summit discussion in that area | 21:24 |
| tr3buchet | jaypipes: i think this means we definitely need to improve the process | 21:24 |
| ttx | anotherjesse: I agree the API definition should be more dev-centric | 21:24 |
| eday | also, key pair management isn't in OS API yet either, correct? | 21:24 |
| vishy | soren: good, we need to get api sorted out | 21:24 |
| vishy | eday: i think there is already a feature for uploading a key in os api? | 21:25 |
| jaypipes | eday: no, though justinsb has some stuff in the works on that I believe for Diablo. | 21:25 |
| soren | Yeah, the API definition process is fundamentally broken, IMO. | 21:25 |
| justinsb | eday: I think no keypairs, but you can upload the authorized_keys file instead | 21:25 |
| vishy | soren: +1 | 21:25 |
| jaypipes | soren: ya. | 21:25 |
| alekibango | i would love to have some smarter limits in api... allowing to contract resource partitioning.... | 21:25 |
| ttx | ok, can we switch to the next one before I fall asleep ? | 21:25 |
| eday | so, even with volumes, what's the point of pushing for volumes branch now? OS API still has many holes that won't help repalce ec2 for cactus | 21:26 |
| tr3buchet | i hear that alekibango | 21:26 |
| tr3buchet | :) | 21:26 |
| ttx | The rest of the discussion can happen on the branch review | 21:26 |
| eday | unless we file all those as bugs and get busy :) | 21:26 |
| anotherjesse | ttx: any chance that lp:nova/diablo will be opened sooner? | 21:26 |
| _cerberus_ | eday: +1 | 21:26 |
| tr3buchet | yep i agree with eday's stance here as well | 21:26 |
| soren | anotherjesse: I'd be against that. | 21:26 |
| ttx | anotherjesse: no. I don't want everyone to switch to diablo development and letting all those bugs in Cactus | 21:26 |
| soren | Yeah, what ttx said. | 21:27 |
| ttx | anotherjesse: unless you volunteer to fix all of them. | 21:27 |
| jbryce | ttx: +1 | 21:27 |
| ttx | anotherjesse: that doesn't prevent you from having your own staging branch | 21:27 |
| anotherjesse | ttx: yep | 21:27 |
| soren | Less excuses to spend time on not fixing bugs is a win. | 21:27 |
| ttx | ok next branch ! | 21:27 |
| ttx | https://code.launchpad.net/~sleepsonthefloor/nova/vnc_console/+merge/54805 | 21:27 |
| ttx | That one looks slightly less conflictual, but it also looks like it might take a few days before it can land. Opinions ? | 21:28 |
| ttx | will it make it by EOD ? | 21:28 |
| alekibango | maybe we should do releases weekly and monthly... :) | 21:28 |
| vishy | ttx: seems pretty close to me | 21:28 |
| alekibango | and daily... :) | 21:28 |
| dabo | 'conflictual'? | 21:28 |
| termie | i've been reviewing it with anthony, i think it will land today | 21:28 |
| termie | very self contained only minor cleanups left | 21:28 |
| ttx | dabo: hmm, "generating conflicts" ? | 21:28 |
| vishy | if it doesn't make it today, i don't really see the need for extending | 21:29 |
| ttx | dabo: "creating arguments" ? | 21:29 |
| jlmjlm | contentious | 21:29 |
| ttx | jlmjlm: oh, that one. | 21:29 |
| dabo | ttx - I like it - gonna steal it! | 21:29 |
| jaypipes | I haven't seen any answer to dragondm's questions on that. | 21:29 |
| dragondm | true. | 21:29 |
| ttx | dabo: must be french | 21:29 |
| jaypipes | dragondm: perhaps they are in the github comments? ... | 21:29 |
| ttx | vishy: I'm fine with that. | 21:29 |
| dragondm | ? | 21:29 |
| jaypipes | dragondm: https://github.com/termie/nova/pull/1 | 21:30 |
| ttx | vishy: in today or out. I'm cool with that. | 21:30 |
| ttx | We also have one that didn't file an exception, but is proposed for merging nevertheless: | 21:30 |
| ttx | https://code.launchpad.net/~xtoddx/nova/disable_creds/+merge/54453 | 21:30 |
| ttx | I'm split on this one... on one hand I should just reject it now, since it's not even filed. | 21:30 |
| ttx | On the other hand it's quite simple, and could be seen as a security fix rather than a feature. Opinions ? | 21:30 |
| jaypipes | xtoddx: ? | 21:31 |
| vishy | i don't think there is any vital reason for that to go into cactus | 21:32 |
| * jaypipes would almost be inclined to file a bug like "No way to revoke creds" for that one... | 21:32 | |
| anotherjesse | either way ... | 21:32 |
| jaypipes | vishy: ya.. | 21:32 |
| *** benb_ has joined #openstack-meeting | 21:32 | |
| ttx | ok, works for me. Should be a bug. | 21:32 |
| ttx | In other news, the Nova stabilization effort: | 21:33 |
| eday | jaypipes: uh, github pull request comments? since when are we doing reviews there? :) | 21:33 |
| ttx | Last week we had 31 bugs opened and 29 fixes committed | 21:33 |
| ttx | eday: don't start him :) | 21:33 |
| jaypipes | eday: ask termie. | 21:33 |
| vishy | :) | 21:33 |
| termie | eday: anthony and i were testing it out | 21:33 |
| ttx | This week we had 65 bugs opened (!) and 27 fixes committed | 21:33 |
| ttx | So now the focus is on fixing those bugs. For nova, going to http://tinyurl.com/nova-bugs is a good start. | 21:34 |
| termie | eday: so i could make informed statements about it | 21:34 |
| ttx | I'll send a few "let's focus on this list" emails this week so that we get the most obnoxious ones fixed for Cactus. | 21:34 |
| ttx | Any last comments before we switch to the next topic ? | 21:34 |
| anotherjesse | ttx: I'm really close to actually having the staging environment for smoketesting | 21:35 |
| alekibango | anotherjesse: how are u making it? is it described somewhere? | 21:35 |
| anotherjesse | ttx: took a really long time to get the boxes up - almost done with ipmi/preseed/... to format between each build | 21:36 |
| anotherjesse | alekibango: writing up as I go - it is being abstracted from our testing environment we setup for nasa that runs after each commit | 21:36 |
| alekibango | anotherjesse: would you like me to help you to automate this using FAI ? | 21:36 |
| ttx | anotherjesse: sounds cool, you would trigger it after each merge ? | 21:36 |
| ttx | maybe a topic for open discussion once we are done with the agenda topiccs | 21:36 |
| anotherjesse | ttx: the goal is each combination of: commit+reference architecture (hypervisor, api, ...) | 21:36 |
| anotherjesse | k | 21:36 |
| ttx | #topic Preparation for Diablo design summit | 21:37 |
| *** openstack changes topic to "Preparation for Diablo design summit" | 21:37 | |
| alekibango | anotherjesse: ic... +1000 | 21:37 |
| anotherjesse | I think it is a vital part of stabiliization | 21:37 |
| soren | ttx: We did that last week :) | 21:37 |
| ttx | soren: what ? what ? | 21:37 |
| soren | 21:36 < ttx> maybe a topic for open discussion once we are done with the agenda topiccs | 21:37 |
| soren | That. | 21:37 |
| ttx | haha | 21:37 |
| ttx | So at the end of next month we'll have the Design Summit in Santa Clara, 3 days from Wednesday April 27th to Friday April 29th. | 21:37 |
| ttx | On the Tuesday there is the OpenStack conference running, for those interested | 21:37 |
| ttx | Like last time, the agenda of the design summit is made of the sessions discussing the features the developers propose. | 21:38 |
| ttx | You can already start thinking about and proposing sessions, the current process is outlined at: | 21:38 |
| ttx | http://wiki.openstack.org/Summit | 21:38 |
| ttx | Once the PTLs are elected we'll review the process together | 21:38 |
| dendrobates | when is the call for blueprints? | 21:38 |
| ttx | and confirm it | 21:38 |
| ttx | dendrobates: you can start filing them. I wanted to discuss the whole thing with PTLs before actually sending a call | 21:39 |
| ttx | dendrobates: think that will be too late ? | 21:39 |
| jaypipes | anotherjesse: ++ on that. (stabilization and your smoketest env.) | 21:39 |
| ttx | (i.e. next week) | 21:39 |
| dendrobates | ttx: it should be fine | 21:40 |
| ttx | ok | 21:40 |
| ttx | #topic Open discussion | 21:40 |
| *** openstack changes topic to "Open discussion" | 21:40 | |
| tr3buchet | TOPIC -> how to handle changing something in nova that would break certain hypervisors. | 21:40 |
| vishy | tr3buchet: explain? | 21:41 |
| ttx | anotherjesse: btw the branching/release model will be discussed at the summit -- justinsb already filed a session on that subject. | 21:41 |
| dabo | tr3buchet: you mean outside of confining the change to nova/virt? | 21:41 |
| tr3buchet | yes | 21:41 |
| alekibango | vishy: for example sheepdog support ? | 21:41 |
| tr3buchet | vishy, let's say changing db structure | 21:41 |
| adiantum | tr3buchet: May be we need register several blueprints and leave it unassigned? | 21:41 |
| ttx | anotherjesse: how many reference architectures did you identify ? | 21:41 |
| vishy | tr3buchet: how does that break other hypervisors? | 21:42 |
| tr3buchet | vishy, say certain places in certain hypervisors refer to a column that gets moved to a different table | 21:42 |
| anotherjesse | ttx: one per hypervisor (potentially times the number of network models) -- then a hand full of things like - multiple hypervisor deploys - multiple zone deploys | 21:42 |
| vishy | tr3buchet: you mean features that aren't supported? | 21:42 |
| tr3buchet | vishy: specifically, moving the mac address column from instances, into it's own table. | 21:42 |
| anotherjesse | ttx: I'm going to try to get 3 simple reference deployments and then start increasing the complexity | 21:42 |
| vishy | tr3buchet: ah ok i'm with you now | 21:43 |
| anotherjesse | ttx: the goal is that before we accept a new hypervisor / network model / ... we have a testing environemtn for it | 21:43 |
| tr3buchet | there are many places that pull that mac address data straight from the table | 21:43 |
| vishy | tr3buchet: an architecture change like that needs to be fixed in all hypervisors | 21:43 |
| vishy | IMO | 21:43 |
| ttx | anotherjesse: so you expect to cover all of them ? In San Antonio we discussed the possibility of asking Citrix/Microsft etc. to give out test resources | 21:43 |
| vishy | tr3buchet: changes that are specific to one hypervisor should not be modifying shared tables imo | 21:44 |
| tr3buchet | vishy: agree, how to arrange the fixing. | 21:44 |
| alekibango | anotherjesse: i did installing nova using http://fai-project.org/ --> on debian stable/testing/unstable and ubuntu (selected few versions). servers up and running in few (4-10) minutes... this can be used for smoketesting | 21:44 |
| anotherjesse | ttx: we would run as many as possible - but you can chain jenkins so others can chain to us for their custom ones | 21:44 |
| ttx | anotherjesse: sounds cool. | 21:44 |
| tr3buchet | vishy: none of this is specific to a certain hypervisor | 21:44 |
| dabo | tr3buchet: shouldn't they be getting it from the orm? | 21:44 |
| vishy | tr3buchet: i think we just have to do our best to fix all of the hypervisors | 21:44 |
| anotherjesse | alekibango: neat - does fai support xenserver :) | 21:44 |
| vishy | and notify the teams that are responsible for them that we will need help | 21:45 |
| alekibango | anotherjesse: can do... i just used kvm for now... but i can help you to set it up | 21:45 |
| anotherjesse | vishy / tr3buchet - having a testing environment for each hypervisor would help with this | 21:45 |
| anotherjesse | vishy / tr3buchet the goal is that we can request a test run on any branch - not just trunk | 21:45 |
| tr3buchet | vishy: so the actual work gets done by a team responsible for the hypervisor? | 21:45 |
| pvo | anotherjesse: I think tr3buchet is wanting to know how to coordinate all the work? | 21:45 |
| alekibango | anotherjesse: we can run tests on different environments and systems, on different HW even.... to test it well | 21:45 |
| tr3buchet | yes thanks pvo | 21:45 |
| soren | tr3buchet: Have you seen this happen or is this entirely hypothetical? | 21:45 |
| vishy | tr3buchet, dabo: they use the orm, but this is a large arch change, that will break everything | 21:46 |
| pvo | soren: this is for multi-nic blueprint | 21:46 |
| ttx | tr3buchet: ideally, with a good design summit session where you have people representing all the hypervisors, you should be able to make sure work will be done | 21:46 |
| tr3buchet | soryen this is very soon to happen | 21:46 |
| tr3buchet | oops | 21:46 |
| tr3buchet | soren ^ | 21:46 |
| soren | pvo: Ok. | 21:46 |
| dabo | vishy: just wondering if the change can be handled via orm access | 21:46 |
| ttx | tr3buchet: and obviously the code breaking stuff would have to land very early to give time to fix it | 21:46 |
| alekibango | anotherjesse: i would love to help with this... | 21:46 |
| anotherjesse | in my opinion openstack shouldn't accept a hypervisor / network model into core that it can't test with each change - so developers know they can see if they are breaking systems | 21:46 |
| vishy | dabo: i think we could hack around it at the orm layer | 21:46 |
| pvo | anotherjesse: I dont' disagree, but the problem exists when you don't have the expertise or dev systems to test all the changes | 21:47 |
| tr3buchet | vishy/dabo i'd prefer not hacking around it in the orm layer if possible | 21:47 |
| vishy | dabo: but all hypervisors should support multiple nics | 21:47 |
| tr3buchet | vishy dabo: if the network db ever gets moved restructured etc, it will cause problems | 21:47 |
| vishy | tr3buchet: agreed | 21:47 |
| dabo | vishy: e.g., 'mac_address' returns the default (first?), and 'mac_addresses' return all of them | 21:47 |
| anotherjesse | pvo: that is why the testing environemnt is so important and why I've been working on getting it setup since joining rackspace | 21:47 |
| ttx | anotherjesse: I agree with that -- but in the past the pressure has been important on getting that extra support in | 21:47 |
| _cerberus_ | I don't think the intent is to leave it "hacked" in the ORM, but simply to buy time for the other implementers to catch up, no? | 21:48 |
| ttx | anotherjesse: see Hyper-V, vSphere | 21:48 |
| vishy | tr3buchet, dabo: right we could provide that for compatibility, but then work with other hypervisors to fix them for multi-nic | 21:48 |
| anotherjesse | ttx: the problem is that we've not prioritized setting up this environment | 21:48 |
| adiantum | actually in two virt drivers changes already done not at the orm | 21:48 |
| dabo | vishy: re: multiple nics - agreed | 21:48 |
| anotherjesse | ttx: we don't even do it for "simple" environments yet | 21:48 |
| pvo | anotherjesse: but tr3buchet's branch would break those. | 21:48 |
| ttx | anotherjesse: so we shouldn't accept HP SAN support code if we don't have a test rig with HP SANs ? | 21:48 |
| dabo | _cerberus_: exactly | 21:49 |
| vishy | ttx: hopefully the group proposing will offer to have a test cluster that we can test against | 21:49 |
| dabo | the concern was breaking other hypervisors | 21:49 |
| dabo | not improving them all | 21:49 |
| pvo | anotherjesse: I agree +1000 with test env. But tr3buchet is trying to figure out how to coordinate a disruptive change. I think the PTL has to solve this with hypervisor lieutenants | 21:49 |
| ewanmellor | If you let us know in advance, I'd be happy for us to smoke test a branch on XenServer or vSphere for you, whatever the change is. I think it's the responsibility of the feature developer to try and get the code write in all hypervisor backends though. We have unit tests with hypervisor simulators included. | 21:49 |
| anotherjesse | ttx: in the case of HP san I would hope that either: 1) a hp san is donated to test cluster 2) someone runs jenkins against trunk with their hp san 3) someone implements a mock where we can test it | 21:49 |
| ttx | vishy: (justinsb landed in HP Lefthand/SAN support in cactus) | 21:50 |
| justinsb | ttx: We can probably get an HP SAN VM image | 21:50 |
| justinsb | Although I do agree that a real HP SAN would be cooler | 21:50 |
| vishy | dabo, tr3buchet, pvo: I propose a) try to provide a compatibilty mode for breaking changes. b) the PTL gets a clear picture of which teams are "responsible" for each hypervisor c) the breaking changers work with the PTL to help get all of the hypervisors aligned with the new world view. | 21:50 |
| ewanmellor | s/code write/code right/ (how embarrassing) | 21:50 |
| anotherjesse | ewanmellor: I want to talk about how to automatically install / test xenserver - we've got code for ubuntu/kvm environemnt | 21:50 |
| dragondm | yup. we need someone to answer the questions like "I think this is going to affect the HyperV virt lay which I know naught abt. Who do I ask abt HyperV?!?!" | 21:51 |
| tr3buchet | pvo: in teh case of hypervisor lieutenants, each lieutenant is in charge of making sure changes to nova don't break in their hypervisor, correct? | 21:51 |
| dabo | vishy: agree 100% | 21:51 |
| ttx | justinsb: right, my point is that for some areas (storage comes to mind) this will seriously slow down code acceptation | 21:51 |
| pvo | vishy: agree with that. | 21:51 |
| anotherjesse | ewanmellor: once I get kvm/ubuntu going here I'll ping the mailing list | 21:51 |
| pvo | tr3buchet: something like that. | 21:51 |
| vishy | tr3buchet: yes, although the person proposing breaking changes should note it in the Spec/MP, and try to work with the PTL to get the changes done in tandem. | 21:52 |
| ewanmellor | anotherjesse: Would love to talk. I don't have a lot of hardware myself yet, so I can't donate a cluster to the public right now, but we are obviously going to bring up a cluster internally. | 21:52 |
| anotherjesse | ewanmellor: rax just stood up a small cluster | 21:52 |
| justinsb | ttx: I think requiring VM images that simulate the device is reasonable. | 21:52 |
| tr3buchet | vishy: but the feature developer wouldn't be responsible for updating the hypervisors? | 21:52 |
| anotherjesse | justinsb: or someone can provide a chained jenkins that runs the tests against the real device if we can't add one to our testing environment | 21:53 |
| vishy | tr3buchet: i don't think we can make a clear rule on that, the responsiblity would probably be shared | 21:53 |
| ewanmellor | I think the feature developer _should_ be responsible for updating the hypervisors. We can't expect all cross-cutting changes to be made by one or two "lieutenants". | 21:54 |
| dragondm | but no-one will have the knowlage to update all hypervisors, in many cases. | 21:54 |
| ewanmellor | If our unit tests are good enough, then you should be able to check your work that way. | 21:54 |
| ttx | anotherjesse: I've had several contacts that told me they would consider donating some chained jenkins to ensure their use case is properly tested against new revisions of the code | 21:54 |
| vishy | tr3buchet, ewanmellor: I'm seeing the reviews being done on a feature branch and hypervisor fixes being proposed and merged into the feature branch. | 21:55 |
| tr3buchet | vishy this is true | 21:55 |
| vishy | tr3buchet, ewanmellor: As long as there is a compatibility mode provided, it isn't necessary that "all" hypervisor fixes go in at once | 21:55 |
| tr3buchet | it seems like in general people use a particular hypervisor.. seems to happen | 21:55 |
| anotherjesse | vishy / tr3buchet / ewanmellor - that is why we want to run the smoketests against arbitrary branches | 21:55 |
| dabo | tr3buchet: ewanmellor: the developer should be responsible for coordinating the lieutenants, if they want their change to be adopted. | 21:55 |
| vishy | (for example, perhaps hyper-v will only have single-nic for a while) | 21:55 |
| tr3buchet | dabo: why i should the feature developer be responsible for keeping track of many hypervisors do we support now? | 21:56 |
| vishy | we should make every effort to allow for backward compatiblity, though | 21:56 |
| tr3buchet | i agree there needs to be clear communication | 21:57 |
| jk0 | you'd have to (at the very least) stick in some pass or NotImplemented methods | 21:57 |
| vishy | tr3buchet: this is one of the roles of the PTL | 21:57 |
| tr3buchet | vishy: yep | 21:57 |
| dabo | tr3buchet: that's where the PTL should be involved - getting all the concerned people working together. Once that group is defined, the feature developer should coordinate among them | 21:57 |
| ewanmellor | vishy: Yes, I'm not saying that all hypervisors need to have all features. Just that people shouldn't be allowed to make a change in one place that completely breaks something else. | 21:57 |
| anotherjesse | ewanmellor: ++ | 21:57 |
| vishy | tr3buchet: but i don't think you can expect to just toss a feature over the wall and hope that somehow all of the hypervisors will need to adopt it. | 21:57 |
| pvo | I think we will have a much clearer picture once PTL is announced. | 21:58 |
| vishy | ewanmellor: Agreed, breaking changes need to have equivalent fixes in the hypervisors brefore merging | 21:58 |
| tr3buchet | vishy: yes absolutely correct. | 21:58 |
| *** markwash has joined #openstack-meeting | 21:59 | |
| tr3buchet | vishy: that's my goal. getting the hypervisors in good shape before merging | 21:59 |
| vishy | btw: good work on the multi-nic stuff | 21:59 |
| vishy | :) | 21:59 |
| tr3buchet | my plan was to have fixtures in place in each hypervisor which allowed them to work with and without multi-nic. then once multi-nic is merged to trunk, the fixtures can be removed | 21:59 |
| ttx | oook, I'll close the meeting now, since I really need to get some sleep... | 22:00 |
| ewanmellor | This doesn't just apply to hypervisors, by the way. Just wait until the networking topologies get more interesting -- we'll have this same problem in that layer. Very few people will run loads of different network topologies. | 22:00 |
| tr3buchet | thanks vishy | 22:00 |
| ttx | but you can continue the discussion here, or even better, on #openstack. | 22:00 |
| *** adiantum_ has joined #openstack-meeting | 22:00 | |
| pvo | longest meeting ever | 22:00 |
| ttx | #endmeeting | 22:00 |
| * Vek yawns | 22:00 | |
| *** openstack changes topic to "Openstack Meetings: http://wiki.openstack.org/Meetings | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/" | 22:00 | |
| openstack | Meeting ended Tue Mar 29 22:00:41 2011 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 22:00 |
| comstud | i need sleep after this meeting, too. | 22:00 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-03-29-21.00.html | 22:00 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-03-29-21.00.txt | 22:00 |
| comstud | :) | 22:00 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-03-29-21.00.log.html | 22:00 |
| *** spectorclan_ has quit IRC | 22:00 | |
| *** User679 has quit IRC | 22:00 | |
| *** dubs has left #openstack-meeting | 22:00 | |
| *** Vek has left #openstack-meeting | 22:01 | |
| *** comstud has left #openstack-meeting | 22:01 | |
| *** jk0 has left #openstack-meeting | 22:01 | |
| *** annegentle has left #openstack-meeting | 22:01 | |
| *** jlmjlm has left #openstack-meeting | 22:01 | |
| *** ewanmellor has left #openstack-meeting | 22:01 | |
| *** anotherjesse has left #openstack-meeting | 22:01 | |
| *** eday has left #openstack-meeting | 22:02 | |
| *** creiht has left #openstack-meeting | 22:02 | |
| *** adiantum has quit IRC | 22:02 | |
| *** markwash has left #openstack-meeting | 22:05 | |
| *** adiantum_ has quit IRC | 22:06 | |
| *** adiantum_ has joined #openstack-meeting | 22:11 | |
| *** benb_ has quit IRC | 22:23 | |
| *** old_devel has left #openstack-meeting | 22:25 | |
| *** reldan has quit IRC | 22:27 | |
| *** reldan has joined #openstack-meeting | 22:31 | |
| *** littleidea has quit IRC | 22:32 | |
| *** johan_ has left #openstack-meeting | 22:34 | |
| *** littleidea has joined #openstack-meeting | 22:38 | |
| *** edconzel has quit IRC | 22:47 | |
| *** adiantum_ has quit IRC | 22:49 | |
| *** adiantum_ has joined #openstack-meeting | 22:55 | |
| *** adiantum_ has quit IRC | 23:05 | |
| *** dendrobates is now known as dendro-afk | 23:09 | |
| *** adiantum has joined #openstack-meeting | 23:10 | |
| *** Daviey has quit IRC | 23:13 | |
| *** Daviey has joined #openstack-meeting | 23:21 | |
| *** jaypipes is now known as jaypipes-afk | 23:58 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!