Tuesday, 2011-03-29

*** dendro-afk is now known as dendrobates00:27
*** littleidea has quit IRC01:00
*** dendrobates is now known as dendro-afk01:43
*** littleidea has joined #openstack-meeting01:52
*** dendro-afk is now known as dendrobates02:02
*** littleidea has quit IRC02:09
*** littleidea has joined #openstack-meeting02:30
*** littleidea has quit IRC02:32
*** troytoma` has joined #openstack-meeting03:05
*** westmaas_ has quit IRC03:06
*** kpepple_ has quit IRC03:06
*** sleepsonthefloor has quit IRC03:06
*** Daviey has quit IRC03:06
*** xtoddx has quit IRC03:06
*** errr has quit IRC03:06
*** Adri2000 has quit IRC03:06
*** annegentle has quit IRC03:06
*** alekibango has quit IRC03:06
*** jeremyb has quit IRC03:06
*** troytoman-away has quit IRC03:06
*** _cerberus_ has quit IRC03:06
*** jbarratt_ has quit IRC03:06
*** comstud has quit IRC03:06
*** chmouel has quit IRC03:06
*** ke4qqq has quit IRC03:06
*** antonym has quit IRC03:06
*** zul has quit IRC03:06
*** soren has quit IRC03:06
*** devcamcar has quit IRC03:06
*** dovetaildan has quit IRC03:06
*** vishy has quit IRC03:06
*** tr3buchet has quit IRC03:06
*** termie has quit IRC03:06
*** errr has joined #openstack-meeting03:14
*** Adri2000 has joined #openstack-meeting03:14
*** annegentle has joined #openstack-meeting03:14
*** zul has joined #openstack-meeting03:18
*** soren has joined #openstack-meeting03:18
*** jbarratt has joined #openstack-meeting03:18
*** alekibango has joined #openstack-meeting03:18
*** jeremyb has joined #openstack-meeting03:18
*** chmouel has joined #openstack-meeting03:19
*** devcamcar has joined #openstack-meeting03:19
*** ke4qqq has joined #openstack-meeting03:19
*** antonym has joined #openstack-meeting03:19
*** Daviey has joined #openstack-meeting03:19
*** westmaas_ has joined #openstack-meeting03:20
*** kpepple_ has joined #openstack-meeting03:20
*** sleepsonthefloor has joined #openstack-meeting03:20
*** xtoddx has joined #openstack-meeting03:20
*** _cerberu` has joined #openstack-meeting03:20
*** dovetaildan has joined #openstack-meeting03:20
*** vishy has joined #openstack-meeting03:20
*** tr3buchet has joined #openstack-meeting03:20
*** termie has joined #openstack-meeting03:20
*** _cerberu` is now known as _cerberus_04:55
*** adjohn has joined #openstack-meeting05:55
*** adjohn has quit IRC09:51
*** ovidwu has quit IRC10:43
*** ovidwu has joined #openstack-meeting10:43
*** ovidwu has quit IRC11:28
*** ovidwu has joined #openstack-meeting11:28
*** adjohn has joined #openstack-meeting11:30
*** ovidwu has joined #openstack-meeting11:31
*** dprince has joined #openstack-meeting12:11
*** adjohn has quit IRC12:35
*** ric has joined #openstack-meeting12:41
*** chuck_ has joined #openstack-meeting13:45
*** zul has quit IRC13:45
*** chuck_ is now known as zul13:46
*** zul has joined #openstack-meeting13:46
*** adjohn has joined #openstack-meeting14:11
*** adjohn has quit IRC14:38
*** creiht has joined #openstack-meeting14:39
*** johnpur has joined #openstack-meeting15:25
*** edconzel has joined #openstack-meeting15:59
*** dendrobates is now known as dendro-afk16:32
*** dendro-afk is now known as dendrobates16:58
*** dendrobates is now known as dendro-afk17:11
*** Xenith has joined #openstack-meeting17:28
*** westmaas_ is now known as westmaas17:31
*** dendro-afk is now known as dendrobates17:49
*** johnpur has quit IRC18:37
*** danwent has joined #openstack-meeting19:53
*** colinnich has joined #openstack-meeting19:56
*** ric has quit IRC19:57
*** User871 has joined #openstack-meeting20:04
*** dprince has quit IRC20:06
*** User871 has quit IRC20:07
*** ttx has joined #openstack-meeting20:31
*** dabo has joined #openstack-meeting20:40
*** Vek has joined #openstack-meeting20:50
*** dubs has joined #openstack-meeting20:51
*** adiantum has joined #openstack-meeting20:51
*** jaypipes has joined #openstack-meeting20:53
*** jlmjlm has joined #openstack-meeting20:57
*** adiantum has quit IRC20:58
*** jk0 has joined #openstack-meeting20:58
*** justinsb has joined #openstack-meeting20:59
*** anotherjesse has joined #openstack-meeting21:00
*** murkk has joined #openstack-meeting21:00
ttxok, let's get started...21:00
openstackMeeting started Tue Mar 29 21:00:49 2011 UTC.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.21:00
openstackUseful Commands: #action #agreed #help #info #idea #link #topic.21:00
ttxWelcome everyone to our weekly meeting...21:01
ttxToday's agenda:21:01
ttx#link http://wiki.openstack.org/Meetings21:01
*** comstud has joined #openstack-meeting21:01
*** User679 has joined #openstack-meeting21:01
ttxNo actions from last week...21:01
ttxMoving directly to:21:01
ttx#topic Current release stage: QA21:01
*** openstack changes topic to "Current release stage: QA"21:01
ttxWe are 9 days away from GammaFreeze, which will happen late on April 7.21:01
ttxLike for the Bexar release, I just pushed back the Gamma milestone by two days so as to maximize the open bugfixing time...21:02
ttxbefore we switch to release-targeted bugfixing for the last 3 days before release.21:02
jaypipescool with me... we need it.21:02
ttxWorked well last time21: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-meeting21:03
*** dragondm has joined #openstack-meeting21:03
ttx#topic Cactus Release status21:03
*** openstack changes topic to "Cactus Release status"21:03
ttxAll the targeted features that had feature freeze exceptions got recently merged.21:04
ttxWe 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-meeting21:04
ttxPlease consider that the cost of a standing feature freeze exception is double:21:04
ttxit diverts review resources from bugfixing and bugfix reviews...21:04
ttxand it introduces instability in the code base, hindering testing.21:04
*** Ryan_Lane has joined #openstack-meeting21:05
ttxBoth result in a less stable release. The longer the exception stands, the higher the cost.21:05
ttxFirst BMP to consider is: https://code.launchpad.net/~justin-fathomdb/nova/volumes-api/+merge/5446421:05
ttxSo this is still under heavy discussion, so it doesn't seem close to merging...21:05
ttxMy opinion is that it's too late for this release and should now be deferred. Opinions ?21:05
anotherjessettx: why doesn't it seem close to merging21:06
anotherjessettx: I thought the needs fixings were for style issues21:06
ttxanotherjesse: it has a disapprove, no approve.21:06
justinsbI don't think we can look customers in the eye and tell them to use the OpenStack API if it doesn't support volumes21:06
*** spectorclan_ has joined #openstack-meeting21:06
justinsbI believe the only remaining issue is the Disapprove, which is about whether it should go in to Cactus or not21:06
anotherjessejustinsb: I agree - sucks to have to tell customers they have to use ec2 api21:06
ttxjustinsb: when do you think it would be ready for merging ?21:07
vishythis 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 api21:07
justinsbttx: It is ready21:07
*** johan_ has joined #openstack-meeting21:07
justinsbttx: IMHO :-)21:07
ttxjustinsb: so you think it can make it tonight ?21:07
pvottx: agree we need to get the api finished21:07
ttxjustinsb: in which case it doesn't need an extension :)21:08
justinsbI personally think it should not be an extension21:08
justinsbBut I had given up hope of that21:08
jaypipesvishy, 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
sorenvishy: Well, this release was supposed to be about stability and deployability. I do think we made great strides in those areas.21:08
ttxjustinsb: I mean, a feature freeze exception extension.21:08
justinsbOops... sorry, overload of 'extension' word - sorry!21:09
anotherjessejaypipes: we had assumed that the api when released would include volumes21:09
anotherjessebut it came so late and didn't21:09
*** littleidea has joined #openstack-meeting21:09
jaypipesanotherjesse: who assumed what? I didn't assume that.21:09
jaypipesI'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
vishysoren, 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
justinsbvishy: I don't think we need to delay the release21:11
*** adiantum has joined #openstack-meeting21:11
justinsbI think I can resolve any style issues in a few hours21:11
justinsbIt's just about whether volumes goes in or not21:11
ttxI certainly won't delay the release on an unplanned feature.21:11
justinsbThat I can't resolve easily21:11
jaypipesvishy: 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
justinsbSo the question is: Is the OpenStack API the one we expect customers to use, or is the EC2 API?21:11
ttxI might consider extending the merging deadline fopr this one is there is consensus that it should be part of cactus.21:11
sandywalshgotta have OS API21:12
jk0OS API21:12
jaypipessandywalsh: volumes is not in the OS API. Period.21:12
justinsbNo volumes => customers that want to use volumes should use the EC2 API though21:12
justinsbSo if we want customers to use the OS API => we need volumes in there21:13
*** masumotok has joined #openstack-meeting21:13
anotherjessejustinsb: ++21:13
ttxjustinsb: that's a failure in the API definition I guess...21:13
tr3buchetso in a few hours volumes can be in OS api?21:13
justinsbI thought packaging it as an extension was a nice compromise21:13
justinsbtr3buchet: Yes, particularly if I sacrifice my Java principles :-)21:14
tr3buchetsounds like a good compromise!21:14
ttxjustinsb: how much more time do you expect to need to get it merged ?21:14
justinsbI didn't see Dan's review until just now21:14
justinsbBut I can probably resolve the issues today21:14
justinsbOther than "should it go in"21:14
tr3buchetif a few hours is the difference between recommending the OS api instead of the ec2 api, i think it's an easy decision21:14
ttxjustinsb: 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
ttxI won't take it back :)21:15
justinsbCan we try to resolve the "should it go in" question now pls?21:16
justinsbThat's the real barrier, not the style stuff21:16
vishyI vote for should go in21:16
justinsbI vote in, obviously :-)21:16
dendrobates_cerberus_: what is that precedent?21:16
tr3buchetyeah i was just about to ask that21:17
jaypipesthis 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
jaypipeswe go from a stated process to "release by marketing".21:17
sorenThis discussion belongs months ago.21:18
anotherjessejaypipes: volumes api isn't a marketing feature21:18
justinsbIsn'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
vishyjaypipes, _cerberus_: who is this project for?21:18
tr3buchetthis branch was already granted FFe?21:18
jaypipesanotherjesse: 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
anotherjessejaypipes: it is core functionality21:18
justinsbI don't think it's marketing... marketing will tell them to use the OS API no matter what :-)21:18
jaypipesanotherjesse: if it is, it should have been voted as Essential.21:18
dendrobatesI think it should come down to risk and impact21:18
justinsbIt's our job to make sure it works :-)21:19
anotherjessewe've been asking since the first design summit how to move to openstack api21:19
ttxdendrobates: it's low-risk, which is why I granted an exception, expiring tonight21:19
_cerberus_vishy: customers, certainly. What I'm saying is we should take the time to learn from our poor planning, not shovel things in21:19
anotherjesseand were told to wait for the openstack 1.1 api21:19
anotherjessewhich came too late21:19
pvoisn't this irrelevant if justinsb gets it in?21:19
vishy_cerberus_: agreed, planning on this feature was botched21:19
pvovishy: don't disagree there either21:19
justinsbpvo: The barrier to getting it in is whether we can agree that it belongs in21:19
sandywalshand, it's an extension so it's OS 1.1 anyway21:19
ttxok everyone ---21:19
tr3bucheti think if he was granted the FFe, he's got until tonight.21:19
dendrobatesI don't think it has to set a precedent, if we don't let it21:20
jaypipesvishy: 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
jbrycei 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 system21:20
anotherjessejbryce: ++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-meeting21:21
jaypipesvishy: silly? hmm. no, I think that's what consistency is, and is the whole point of consistent, train-based, timed releases.21:21
ttxSo, 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 me21:22
dendrobatesIf we resolve not to allow it again and discuss process at the summit, I don;t think letting this in would do any harm21:22
jaypipesvishy: delaying for some feature is what defines marketing-driven releases or releases of software for a single user or few users.21:22
pvottx: EOD what timezone?21:22
tr3buchetthis 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
ttxEOD Hawaii time21:22
edaybesides 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-meeting21:22
edayit may be pointless to try to get volumes if other parts are not yet supported in OS, and we need to push ec2 anyways21:23
vishyeday: floating_ips are not in, shared_ip groups are a bit moot21:23
soreneday: Shared IP's as in EC2 style floating ip's or as in cloud servers shared ip groups?21:23
vishyeday: I think they are only needed for rackspace21:23
ttxjustinsb: but given that it was very unplanned I won't grant an extension, so if it doesn't make it today... it's out21:23
ttxjustinsb: is that fair ?21:23
justinsbttx: I think the real issue isn't the FFE21:23
justinsbttx: It'll either make it today or not at all21:23
jaypipesI'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
edaysoren: floating IPs, what the core supports (we don't have shared ip groups, RS, in any way yet)21:23
justinsbttx: So I think the FFE point is moot21:23
ttxjustinsb: ack.21:24
justinsbjaypipes: That would be great, thank you21:24
soreneday: I know. That's why I wondered :)21:24
anotherjessethe real issue was that we still don't have ownership of the api21:24
anotherjessewe didn't get it until a couple of weeks ago - and didn't know it was a gap21:24
ttxanotherjesse: soren pushed a summit discussion in that area21:24
tr3buchetjaypipes: i think this means we definitely need to improve the process21:24
ttxanotherjesse: I agree the API definition should be more dev-centric21:24
edayalso, key pair management isn't in OS API yet either, correct?21:24
vishysoren: good, we need to get api sorted out21:24
vishyeday: i think there is already a feature for uploading a key in os api?21:25
jaypipeseday: no, though justinsb has some stuff in the works on that I believe for Diablo.21:25
sorenYeah, the API definition process is fundamentally broken, IMO.21:25
justinsbeday: I think no keypairs, but you can upload the authorized_keys file instead21:25
vishysoren: +121:25
jaypipessoren: ya.21:25
alekibangoi would love to have some smarter limits in api... allowing to contract resource partitioning....21:25
ttxok, can we switch to the next one before I fall asleep ?21:25
edayso, 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 cactus21:26
tr3bucheti hear that alekibango21:26
ttxThe rest of the discussion can happen on the branch review21:26
edayunless we file all those as bugs and get busy :)21:26
anotherjessettx: any chance that lp:nova/diablo will be opened sooner?21:26
_cerberus_eday: +121:26
tr3buchetyep i agree with eday's stance here as well21:26
sorenanotherjesse: I'd be against that.21:26
ttxanotherjesse: no. I don't want everyone to switch to diablo development and letting all those bugs in Cactus21:26
sorenYeah, what ttx said.21:27
ttxanotherjesse: unless you volunteer to fix all of them.21:27
jbrycettx: +121:27
ttxanotherjesse: that doesn't prevent you from having your own staging branch21:27
anotherjessettx: yep21:27
sorenLess excuses to spend time on not fixing bugs is a win.21:27
ttxok next branch !21:27
ttxThat one looks slightly less conflictual, but it also looks like it might take a few days before it can land. Opinions ?21:28
ttxwill it make it by EOD ?21:28
alekibangomaybe we should do releases weekly and monthly... :)21:28
vishyttx: seems pretty close to me21:28
alekibangoand daily... :)21:28
termiei've been reviewing it with anthony, i think it will land today21:28
termievery self contained only minor cleanups left21:28
ttxdabo: hmm, "generating conflicts" ?21:28
vishyif it doesn't make it today, i don't really see the need for extending21:29
ttxdabo: "creating arguments" ?21:29
ttxjlmjlm: oh, that one.21:29
dabottx - I like it - gonna steal it!21:29
jaypipesI haven't seen any answer to dragondm's questions on that.21:29
ttxdabo:  must be french21:29
jaypipesdragondm: perhaps they are in the github comments? ...21:29
ttxvishy: I'm fine with that.21:29
jaypipesdragondm: https://github.com/termie/nova/pull/121:30
ttxvishy: in today or out. I'm cool with that.21:30
ttxWe also have one that didn't file an exception, but is proposed for merging nevertheless:21:30
ttxI'm split on this one... on one hand I should just reject it now, since it's not even filed.21:30
ttxOn the other hand it's quite simple, and could be seen as a security fix rather than a feature. Opinions ?21:30
jaypipesxtoddx: ?21:31
vishyi don't think there is any vital reason for that to go into cactus21:32
* jaypipes would almost be inclined to file a bug like "No way to revoke creds" for that one...21:32
anotherjesseeither way ...21:32
jaypipesvishy: ya..21:32
*** benb_ has joined #openstack-meeting21:32
ttxok, works for me. Should be a bug.21:32
ttxIn other news, the Nova stabilization effort:21:33
edayjaypipes: uh, github pull request comments? since when are we doing reviews there? :)21:33
ttxLast week we had 31 bugs opened and 29 fixes committed21:33
ttxeday: don't start him :)21:33
jaypipeseday: ask termie.21:33
termieeday: anthony and i were testing it out21:33
ttxThis week we had 65 bugs opened (!) and 27 fixes committed21:33
ttxSo now the focus is on fixing those bugs. For nova, going to http://tinyurl.com/nova-bugs is a good start.21:34
termieeday: so i could make informed statements about it21:34
ttxI'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
ttxAny last comments before we switch to the next topic ?21:34
anotherjessettx: I'm really close to actually having the staging environment for smoketesting21:35
alekibangoanotherjesse: how are u making it? is it described somewhere?21:35
anotherjessettx: took a really long time to get the boxes up - almost done with ipmi/preseed/... to format between each build21:36
anotherjessealekibango: writing up as I go - it is being abstracted from our testing environment we setup for nasa that runs after each commit21:36
alekibangoanotherjesse: would you like me to help you  to automate this using FAI ?21:36
ttxanotherjesse: sounds cool, you would trigger it after each merge ?21:36
ttxmaybe a topic for open discussion once we are done with the agenda topiccs21:36
anotherjessettx: the goal is each combination of: commit+reference architecture (hypervisor, api, ...)21:36
ttx#topic Preparation for Diablo design summit21:37
*** openstack changes topic to "Preparation for Diablo design summit"21:37
alekibangoanotherjesse: ic... +100021:37
anotherjesseI think it is a vital part of stabiliization21:37
sorenttx: We did that last week :)21:37
ttxsoren: what ?  what ?21:37
soren21:36 < ttx> maybe a topic for open discussion once we are done with the agenda topiccs21:37
ttxSo 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
ttxOn the Tuesday there is the OpenStack conference running, for those interested21:37
ttxLike last time, the agenda of the design summit is made of the sessions discussing the features the developers propose.21:38
ttxYou can already start thinking about and proposing sessions, the current process is outlined at:21:38
ttxOnce the PTLs are elected we'll review the process together21:38
dendrobateswhen is the call for blueprints?21:38
ttxand confirm it21:38
ttxdendrobates: you can start filing them. I wanted to discuss the whole thing with PTLs before actually sending a call21:39
ttxdendrobates: think that will be too late ?21:39
jaypipesanotherjesse: ++ on that. (stabilization and your smoketest env.)21:39
ttx(i.e. next week)21:39
dendrobatesttx:  it should be fine21:40
ttx#topic Open discussion21:40
*** openstack changes topic to "Open discussion"21:40
tr3buchetTOPIC -> how to handle changing something in nova that would break certain hypervisors.21:40
vishytr3buchet: explain?21:41
ttxanotherjesse: btw the branching/release model will be discussed at the summit -- justinsb already filed a session on that subject.21:41
dabotr3buchet: you mean outside of confining the change to nova/virt?21:41
alekibangovishy: for example sheepdog support ?21:41
tr3buchetvishy, let's say changing db structure21:41
adiantumtr3buchet: May be we need register several blueprints and leave it unassigned?21:41
ttxanotherjesse: how many reference architectures did you identify ?21:41
vishytr3buchet: how does that break other hypervisors?21:42
tr3buchetvishy, say certain places in certain hypervisors refer to a column that gets moved to a different table21:42
anotherjessettx: one per hypervisor (potentially times the number of network models) -- then a hand full of things like -  multiple hypervisor deploys - multiple zone deploys21:42
vishytr3buchet: you mean features that aren't supported?21:42
tr3buchetvishy: specifically, moving the mac address column from instances, into it's own table.21:42
anotherjessettx: I'm going to try to get 3 simple reference deployments and then start increasing the complexity21:42
vishytr3buchet: ah ok i'm with you now21:43
anotherjessettx: the goal is that before we accept a new hypervisor / network model / ... we have a testing environemtn for it21:43
tr3buchetthere are many places that pull that mac address data straight from the table21:43
vishytr3buchet: an architecture change like that needs to be fixed in all hypervisors21:43
ttxanotherjesse: so you expect to cover all of them ? In San Antonio we discussed the possibility of asking Citrix/Microsft etc. to give out test resources21:43
vishytr3buchet: changes that are specific to one hypervisor should not be modifying shared tables imo21:44
tr3buchetvishy: agree, how to arrange the fixing.21:44
alekibangoanotherjesse: 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 smoketesting21:44
anotherjessettx: we would run as many as possible - but you can chain jenkins so others can chain to us for their custom ones21:44
ttxanotherjesse: sounds cool.21:44
tr3buchetvishy: none of this is specific to a certain hypervisor21:44
dabotr3buchet: shouldn't they be getting it from the orm?21:44
vishytr3buchet: i think we just have to do our best to fix all of the hypervisors21:44
anotherjessealekibango: neat - does fai support xenserver :)21:44
vishyand notify the teams that are responsible for them that we will need help21:45
alekibangoanotherjesse: can do... i just used kvm for now... but i can help you to set it up21:45
anotherjessevishy / tr3buchet - having a testing environment for each hypervisor would help with this21:45
anotherjessevishy / tr3buchet the goal is that we can request a test run on any branch - not just trunk21:45
tr3buchetvishy: so the actual work gets done by a team responsible for the hypervisor?21:45
pvoanotherjesse: I think tr3buchet is wanting to know how to coordinate all the work?21:45
alekibangoanotherjesse: we can run tests on different environments and systems, on different HW even.... to test it well21:45
tr3buchetyes thanks pvo21:45
sorentr3buchet: Have you seen this happen or is this entirely hypothetical?21:45
vishytr3buchet, dabo: they use the orm, but this is a large arch change, that will break everything21:46
pvosoren: this is for multi-nic blueprint21:46
ttxtr3buchet: 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 done21:46
tr3buchetsoryen this is very soon to happen21:46
tr3buchetsoren ^21:46
sorenpvo: Ok.21:46
dabovishy: just wondering if the change can be handled via orm access21:46
ttxtr3buchet: and obviously the code breaking stuff would have to land very early to give time to fix it21:46
alekibangoanotherjesse: i would love to help with this...21:46
anotherjessein 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 systems21:46
vishydabo: i think we could hack around it at the orm layer21:46
pvoanotherjesse: I dont' disagree, but the problem exists when you don't have the expertise or dev systems to test all the changes21:47
tr3buchetvishy/dabo i'd prefer not hacking around it in the orm layer if possible21:47
vishydabo: but all hypervisors should support multiple nics21:47
tr3buchetvishy dabo: if the network db ever gets moved restructured etc, it will cause problems21:47
vishytr3buchet: agreed21:47
dabovishy: e.g., 'mac_address' returns the default (first?), and 'mac_addresses' return all of them21:47
anotherjessepvo: that is why the testing environemnt is so important and why I've been working on getting it setup since joining rackspace21:47
ttxanotherjesse: I agree with that -- but in the past the pressure has been important on getting that extra support in21: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
ttxanotherjesse: see Hyper-V, vSphere21:48
vishytr3buchet, dabo: right we could provide that for compatibility, but then work with other hypervisors to fix them for multi-nic21:48
anotherjessettx: the problem is that we've not prioritized setting up this environment21:48
adiantumactually in two virt drivers changes already done not at the orm21:48
dabovishy: re: multiple nics - agreed21:48
anotherjessettx: we don't even do it for "simple" environments yet21:48
pvoanotherjesse: but tr3buchet's branch would break those.21:48
ttxanotherjesse: so we shouldn't accept HP SAN support code if we don't have a test rig with HP SANs ?21:48
dabo_cerberus_: exactly21:49
vishyttx: hopefully the group proposing will offer to have a test cluster that we can test against21:49
dabothe concern was breaking other hypervisors21:49
dabonot improving them all21:49
pvoanotherjesse: 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 lieutenants21:49
ewanmellorIf 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
anotherjessettx: 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 it21:49
ttxvishy: (justinsb landed in HP Lefthand/SAN support in cactus)21:50
justinsbttx: We can probably get an HP SAN VM image21:50
justinsbAlthough I do agree that a real HP SAN would be cooler21:50
vishydabo, 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
ewanmellors/code write/code right/  (how embarrassing)21:50
anotherjesseewanmellor: I want to talk about how to automatically install  / test xenserver - we've got code for ubuntu/kvm environemnt21:50
dragondmyup. 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
tr3buchetpvo: 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
dabovishy: agree 100%21:51
ttxjustinsb: right, my point is that for some areas (storage comes to mind) this will seriously slow down code acceptation21:51
pvovishy: agree with that.21:51
anotherjesseewanmellor: once I get kvm/ubuntu going here I'll ping the mailing list21:51
pvotr3buchet: something like that.21:51
vishytr3buchet: 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
ewanmelloranotherjesse: 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
anotherjesseewanmellor: rax just stood up a small cluster21:52
justinsbttx: I think requiring VM images that simulate the device is reasonable.21:52
tr3buchetvishy: but the feature developer wouldn't be responsible for updating the hypervisors?21:52
anotherjessejustinsb: or someone can provide a chained jenkins that runs the tests against the real device if we can't add one to our testing environment21:53
vishytr3buchet: i don't think we can make a clear rule on that, the responsiblity would probably be shared21:53
ewanmellorI 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
dragondmbut no-one will have the knowlage to update all hypervisors, in many cases.21:54
ewanmellorIf our unit tests are good enough, then you should be able to check your work that way.21:54
ttxanotherjesse: 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 code21:54
vishytr3buchet, 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
tr3buchetvishy this is true21:55
vishytr3buchet, ewanmellor: As long as there is a compatibility mode provided, it isn't necessary that "all" hypervisor fixes go in at once21:55
tr3buchetit seems like in general people use a particular hypervisor.. seems to happen21:55
anotherjessevishy / tr3buchet / ewanmellor - that is why we want to run the smoketests against arbitrary branches21:55
dabotr3buchet: 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
tr3buchetdabo: why i should the feature developer be responsible for keeping track of many hypervisors do we support now?21:56
vishywe should make every effort to allow for backward compatiblity, though21:56
tr3bucheti agree there needs to be clear communication21:57
jk0you'd have to (at the very least) stick in some pass or NotImplemented methods21:57
vishytr3buchet: this is one of the roles of the PTL21:57
tr3buchetvishy: yep21:57
dabotr3buchet: 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 them21:57
ewanmellorvishy: 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
anotherjesseewanmellor: ++21:57
vishytr3buchet: 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
pvoI think we will have a much clearer picture once PTL is announced.21:58
vishyewanmellor: Agreed, breaking changes need to have equivalent fixes in the hypervisors brefore merging21:58
tr3buchetvishy: yes absolutely correct.21:58
*** markwash has joined #openstack-meeting21:59
tr3buchetvishy: that's my goal. getting the hypervisors in good shape before merging21:59
vishybtw: good work on the multi-nic stuff21:59
tr3buchetmy 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 removed21:59
ttxoook, I'll close the meeting now, since I really need to get some sleep...22:00
ewanmellorThis 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
tr3buchetthanks vishy22:00
ttxbut you can continue the discussion here, or even better, on #openstack.22:00
*** adiantum_ has joined #openstack-meeting22:00
pvolongest meeting ever22:00
* Vek yawns22:00
*** openstack changes topic to "Openstack Meetings: http://wiki.openstack.org/Meetings | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/"22:00
openstackMeeting ended Tue Mar 29 22:00:41 2011 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)22:00
comstudi need sleep after this meeting, too.22:00
openstackMinutes:        http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-03-29-21.00.html22:00
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-03-29-21.00.txt22:00
openstackLog:            http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-03-29-21.00.log.html22:00
*** spectorclan_ has quit IRC22:00
*** User679 has quit IRC22:00
*** dubs has left #openstack-meeting22:00
*** Vek has left #openstack-meeting22:01
*** comstud has left #openstack-meeting22:01
*** jk0 has left #openstack-meeting22:01
*** annegentle has left #openstack-meeting22:01
*** jlmjlm has left #openstack-meeting22:01
*** ewanmellor has left #openstack-meeting22:01
*** anotherjesse has left #openstack-meeting22:01
*** eday has left #openstack-meeting22:02
*** creiht has left #openstack-meeting22:02
*** adiantum has quit IRC22:02
*** markwash has left #openstack-meeting22:05
*** adiantum_ has quit IRC22:06
*** adiantum_ has joined #openstack-meeting22:11
*** benb_ has quit IRC22:23
*** old_devel has left #openstack-meeting22:25
*** reldan has quit IRC22:27
*** reldan has joined #openstack-meeting22:31
*** littleidea has quit IRC22:32
*** johan_ has left #openstack-meeting22:34
*** littleidea has joined #openstack-meeting22:38
*** edconzel has quit IRC22:47
*** adiantum_ has quit IRC22:49
*** adiantum_ has joined #openstack-meeting22:55
*** adiantum_ has quit IRC23:05
*** dendrobates is now known as dendro-afk23:09
*** adiantum has joined #openstack-meeting23:10
*** Daviey has quit IRC23:13
*** Daviey has joined #openstack-meeting23:21
*** jaypipes is now known as jaypipes-afk23:58

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!