21:03:41 #startmeeting 21:03:42 Meeting started Tue Apr 24 21:03:41 2012 UTC. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:03:43 Useful Commands: #action #agreed #help #info #idea #link #topic. 21:03:48 Today's agenda: http://wiki.openstack.org/Meetings/ProjectMeeting 21:03:58 We are still recovering from the Design Summit, I'd like to get some feedback from it while it's fresh 21:04:09 But first, let's discuss the Folsom release schedule for a bit 21:04:15 #topic Proposed release schedule options 21:04:30 For the projects wanting to follow a common schedule, please see the options at: 21:04:36 #link http://ubuntuone.com/4J6FGOsWNdTCpUWUf9S87X 21:05:00 there are 4 options outlined in there 21:05:10 let me know if you can't read it 21:05:19 reads fine. 21:05:19 First I'd like to confirm whether you want to have 4 milestones + final release (option A, milestone every 4-5 weeks) 21:05:31 or 3 milestones + final release (options B to D, milestone every 5-7 weeks) 21:05:42 For Essex we did 4 milestones + Final release (every 5-6 weeks) 21:05:54 At the design summit the PTLs present said 3 milestones + final release was preferable 21:06:06 especially if we want to keep the option of using milestones as "releases" toward the end of the cycle if ready 21:06:21 I don't think Dan, Devin and Joe were there though. 21:06:30 ttx: I'm in agreement with that 21:06:40 devin agrees (i hope) 21:06:45 heh 21:06:47 I'm ok with that. 21:06:56 Another question: Do you prefer to have one week between release and design summit (options B, D)... or two weeks (option C) ? 21:07:12 in docland we did talk about it, but not sure resources are there to track docs with milestones (regardless of 3 or 4) 21:07:19 so far we did one week... and it puts some stress on our collective shoulders 21:07:21 things were pretty rushed with essex release and folsom summit 21:07:33 danwent: ++ 21:07:49 and I noticed people pulling back from testing to begin prepping for the summit, which was bad 21:07:56 I don't want to "lose" too much time between the two, but I could use a week to breathe 21:08:01 ttx: I'd prefer 2 weeks given the option. 21:08:08 ttx: I like C with the extra time 21:08:26 C is pretty regular 21:08:38 2 weeks is probably better/safer: Option C 21:08:42 I like C too fwiw :) 21:08:54 don't book travel just yet :) 21:08:56 C ++ :D 21:09:03 hee 21:09:23 I'll pursue C as the proposed option. 21:09:57 ohnoimdead: if C causes problems to Horizon, let me know soon 21:10:01 #topic Keystone status 21:10:01 so first agenda is done ? 21:10:09 xsad: yes 21:10:18 heckj: Could you sum up the main outcome of the Keystone sessions for us ? (if any) 21:10:37 Anything affecting the other projects that they should be aware of ? 21:10:49 ttx: at the moment, not - but some will be 21:10:50 ttx: i think c is good 21:11:13 ttx: looking at taking a number of what were previously extensions and bringing them into core with a new rev API. 21:11:38 proposal for the new API to be up as a google doc (ala Jay Pipes setup) in a few weeks, ideally implemented by F2 21:11:43 heckj: ok 21:12:00 heckj: When do you think you'll be able to have the folsom plans filed as blueprints ? 21:12:05 aim is to keep any broad changes mostly done by F2 to propogate and implement with other projects over that last milestone 21:12:28 heckj: I like that 21:12:38 ttx: initial blueprints are up there, pending some additional that weren't in the keystone track to get created. 21:12:56 heckj: ok, we could do a Folsom review next week then 21:13:05 heckj: anything else ? 21:13:06 blueprint for the "v.Next API" pending documenting a proposal 21:13:16 nope 21:13:20 Questions about Keystone ? 21:13:54 #topic Swift status 21:13:59 notmyname: o/ 21:13:59 o/ 21:14:03 notmyname: A quick summary of the Swift sessions outcome ? 21:14:41 Anything significant or affecting others ? 21:14:44 swift sessions went very well, I thought. we've got some good changes coming up (statsd integration and splitting the client library) 21:15:08 About splitting the client library. Would that be for the next release ? or some after that ? 21:15:12 and we've got some other proposals (like CDMI support) that are also dependent on ongoing discussions in the PPB, etc 21:15:52 * ttx needs to align the release machinery for a separate release deliverable 21:16:03 I'm not sure when we'll split the client lib. probably not in the next swift release, but perhaps for the one after that. either way, I expect it to be int he folsom cycle 21:16:26 ok. I'll try to follow the work on that 21:16:33 notmyname: Anything else ? 21:16:40 thinking 21:17:08 not I don't think so. lots of exciting stuff at the summit. mostly around a growing installed base 21:17:22 I saw that with my own eyes ;) 21:17:24 Questions on Swift ? 21:18:01 #topic Glance status 21:18:07 bcwaldon: How did the Glance sessions go ? 21:18:15 ttx: excellent! 21:18:19 We discussed quite a bit at the summit. It looks like we'll be investigating trusted glance deployments, image replication, image property detection, and the v2 API. I'm working on getting everything set up in blueprints now. 21:18:27 Do you expect to separate the Glance client out of Glance itself ? 21:18:46 ttx: yes, already working on that 21:18:55 Any timeframe on that ? 21:18:57 ttx: python-glanceclient is being integrated into devstack right now 21:19:01 F1 or F2 ? 21:19:05 ttx: F1 hopefully 21:19:13 ok 21:19:16 Will you have all blueprints filed by next week ? 21:19:25 ttx: that would be a good goal to have, yes 21:19:29 cool. 21:19:41 bcwaldon: Anything else you wanted to mention ? 21:20:00 no sir 21:20:03 Questions on Glance ? 21:20:11 just that https://bugs.launchpad.net/glance/+bug/987654 is a blocker for integrating glanceclient right now 21:20:13 Launchpad bug 987654 in openstack-ci "glanceclient bin scripts overwrite glance" [Undecided,New] 21:20:19 gabrielhurley: yep, I saw that 21:20:25 sounds annoying. 21:20:32 gabrielhurley: not sure how to move forward on it :/ 21:20:46 I wouldn't care except it kills the integration test gate 21:21:08 gabrielhurley: it would only break things if the commands were expecting old glance client 21:21:22 nope, check out the log I linked to in the bug report 21:21:29 it actually kills the setup of the env 21:21:40 ok, we can follow up on this later 21:21:43 k 21:21:52 mtaylor and jeblair can certainly help 21:22:04 gabrielhurley: but I'll start looking into that now, thanks for bringing it up 21:22:13 #topic Quantum status 21:22:19 yeah 21:22:19 danwent: hey 21:22:30 hey 21:22:31 Wrong window, sorry. 21:22:35 danwent: Could you do a quick summary of Quantum track, especially where the decisions affect the other projects ? 21:22:41 yup. 21:23:04 probably biggest topic was merging in Melange IPAM functionality, which will be part of Quantum in Folsom 21:23:38 we'll also have a heavy focus on making sure functionality like L3 Forwarding + NAT, Security Groups, etc. are implemented in Quantum to give Quantum full Nova parity 21:23:41 definitely. I need to know if I should still consider Melange in incubation for milestone release purposes 21:23:53 I believe you should not 21:24:01 but an email to troytoman wouldn't hurt :) 21:24:02 Would Melange be merged by F1 ? 21:24:13 (in which case it's a non-issue) 21:24:31 We're shooting for it, but I can't say for sure right now. When is F1 with new schedule? 21:24:43 either way, I don't think it makes sense to have melange releases for F 21:25:06 May 24 21:25:19 i'll talk to troy about it and get back to you 21:25:23 ok, thx 21:25:42 #action danwent to see what to do with Melange for F1 21:25:44 Other questions were around what it means for Quantum to be core in Folsom, and whether that means it would be "default". Based on past discussions with Vish, we definitely won't remove old networking managers from nova in Folsom 21:25:58 but we need to see if Quantum is up to par to be the default in Folsom. 21:26:09 My goal was to make that call based on the F2 release 21:26:09 I think we can make that decision by F2 21:26:12 yup. 21:26:16 great minds alike :) 21:26:20 :) 21:26:33 but I'd be "hell yeah" 21:26:45 other touch points are with Horizon, we'll work with them directly to help support their quantum integration work. that depends on the new api with melange folded in. 21:26:56 danwent: when do you think you'll be able to finialize digesting the sessions into meaningful blueprints ? 21:27:05 next week might be a bit short ? 21:27:07 We're also working with CI team to get gating on quantum (still some issues to sort out here) 21:27:28 ttx: spent a good chunk of time on it already. I think we can have rough bps next week. 21:27:36 I want people to be able to get to work :) 21:27:38 ack 21:27:47 danwent: Anything else ? 21:27:52 i think that's good for now 21:27:54 Questions on Quantum ? 21:27:56 oh, one more thing 21:28:01 go for it 21:28:22 we're going to be in a holding pattern with respect to using the netstack list until the OS community decides on its overall email list strategy 21:28:29 hopefully that will be wrapped up soon. 21:28:44 right. I'm on it. Unfortunately piled up lots of work in the last weeks 21:28:54 understood :) 21:29:04 #topic Nova status 21:29:09 vishy: hey 21:29:11 heyo! 21:29:17 vishy: Won't ask you for a complete summary, anything particular you wanted to mention ? 21:29:21 so there were an epic amount of discussions 21:29:36 ttx: I don't think we have a complete plan regarding upgrades esp. regarding db migrations 21:29:57 rpc versioning and ability to shutdown workers 21:30:05 is part of it that we are well underway 21:30:23 I understand there was a discussion about db migrations at the summit that I missed, but I think we don't have a good plan there yet. 21:30:40 yes, in openstack-common 21:30:49 led by adam_g 21:31:04 ok we may need to take that one to the ml 21:31:30 other stuff seems underway, I need to spend the next week or two dealing with blueprints etc. 21:31:39 What's the general plan for nova-volumes -> Cinder ? Anything that needs to be implemenetd on Nova side to make room ? 21:31:40 are the nova "spinoffs" going to be projects in here? 21:31:41 but the plans all seem pretty clear. 21:31:55 med_: what spinoffs ? 21:32:03 jinx, Cinder for one 21:32:09 ttx: there are a couple of things. I'm taking the lead on that 21:32:27 med_: Cinder is not core, will certainly be incubated in Folsom 21:32:31 I will be shepherding cinder for the first month or two 21:33:01 ttx: there are a couple of changes that need to go into nova that are already proposed 21:33:02 if Cinder isn't core, what's the state of volume support for Folsom? 21:33:20 there will be a couple more once python-cinderclient exists 21:33:54 gabrielhurley: use of Cinder is supposed to be optional in folsom. 21:34:02 a bit like Quantum was in Essex 21:34:13 ttx: interesting. nova volume was sort of implicitly core in essex since it was in nova, which is core... right? 21:34:19 i thought cinder was nova-volume+? 21:34:47 gabrielhurley: my understanding is that code would survive in Nova in Folsom 21:34:49 so will there still be a nova-volume throughout F? and then cutover in G timeframe (similar to nova-network)? 21:34:51 vishy: ? 21:35:11 gabrielhurley: it's not a one-time split, it's a parallel thing. 21:35:20 ttx: gotcha. interesting. 21:35:36 gabrielhurley: that's my understanding, mind you I wasn't even in the room :) 21:35:49 that's a second-hand report 21:36:03 existing code will stay in 21:36:03 should horizon support both? 21:36:04 vishy should be able to confirm when his MacBook unfreezes 21:36:12 until we are sure that we should move back 21:36:23 * move over 21:36:50 vishy: Anything else ? 21:36:53 ttx: I didn't commit to a specific time frame, but I don't see any reason to remove it prior to the folsom release 21:37:08 but it will be literally just specifying a different endpoint in settings 21:37:17 to switch back and forth 21:37:19 vishy: it would cause interesting "core nomination" problems. 21:37:42 ttx: I was considering that cinder would become the default for folsom 21:37:46 vishy: unless we do fast releases befor ethe end of Folsom, which is a bit unlikely now 21:37:55 ttx: but old code would stay in for compatibility 21:38:01 one question on nova-client: will we ever get an update in pypi? 21:38:10 ttx: I think we need a month to see if we can get everything lined up though 21:38:22 vishy: for Cinder to be default it needs to be core... and you can't be incubated and core in the same cycle so far 21:38:42 ttx: does it need to go through incubated? 21:38:55 glance was immediately core when we split it from nova 21:39:01 it was incubated inside of nova :) 21:39:03 vishy: it's not really the problem. I kinda prefer that a core project goes through the whole cycle 21:39:04 ohnoimdead: mtaylor has committed to doing that. he's just slacking (by his own admission) ;-) 21:39:15 vishy: but we could relax that 21:39:28 gabrielhurley: that's why i'm bringing it up. ;) 21:39:34 since we are getting used to the f 21:39:36 dance* 21:39:36 ttx: i expect cinder to be ready to release a milestone along with the other projects 21:39:50 (and Cinder was discussed at the design summit) 21:40:08 milestone 1 probably won't add any new code, just be nova-volumes transplanted into new project 21:40:10 #action ttx to look into relaxing the Core rules for project splits 21:41:30 Questions on Nova ? 21:42:15 who is the team working on Cinder? 21:42:22 (the rule was there to protect the release against late additions that would not suffer under release management the whole cycle, we can certainly relax it for project splits if the first milestones are followed) 21:42:27 * annegentle hunts for docs pros 21:42:35 jgriffith, Renuka, Nirmal and Vladimir to start 21:42:48 jgriffith: ok, thanks. 21:43:07 #topic Horizon status 21:43:16 ohnoimdead: How did the Horizon track go ? Anything that the other projects should know about ? 21:44:21 track went well. main focuses for folsom: workflows, scaffolding for dashboards/panels, making volume/cinder optional, quantum support, new swift ui, more extenisibility, more ux improvements 21:44:52 most of those have blueprints and i'll be adding a couple more over the next couple of days 21:45:02 ohnoimdead: do you think you'll have F1 plans as blueprints ready for review next week ? 21:45:09 yes 21:45:16 * ttx will create the milestones with dates btw 21:45:53 #action ttx to create F milestones where missing when schedule is ready 21:45:59 ohnoimdead: Anything else ? 21:46:14 Questions for Horizon ? 21:46:25 let's do this!! 21:46:41 #topic Other Team reports 21:46:54 annegentle: want to summarize doc track outcome ? 21:47:17 ttx: I want to log maybe 2 blueprints - 21:48:05 summary was lots of people wanting to contribute more operations and daily use content 21:48:44 and publish early publish often 21:48:46 annegentle: got new doc team members signed up ? 21:48:57 jaypipes: around ? 21:49:17 ttx: seems like it - for sysadmins and daily operators especially. It's tough when the processes are very very dev-centered though, need better onboarding. 21:49:57 annegentle: we should discuss together how we can improve that 21:50:04 Any other team lead with a status report ? 21:50:16 ttx: sure, and would love input on easier "just find and fix doc bugs" workflow 21:50:53 FWIW I piled up some work on fixing our communication & bug handling, will post to ML soon 21:51:01 ttx: nice 21:51:20 "soon" becoming farther away as we speak 21:51:29 another doc note - I plan to "close out" the docs for Essex by May 1 or so 21:51:44 ok, good to know 21:51:55 #topic General design summit feedback 21:52:10 It is my understanding that a survey should soon be out, but I welcome your direct feedback here... 21:52:10 ttx: where are actions following up on the internationalistion meeting? 21:52:34 gabrielhurley: we need someone to take the lead on that. Counting on me is a recipe for failure 21:52:56 so the action is find a team lead and make a team? ;-) 21:53:21 that's what I said in that meeting. We need a I18N advocacy group to pressure the other stakeholders 21:53:36 and the group won't rise without someone committing time to it 21:53:40 cool. just wanted to follow up. 21:53:54 I'll send something to the ML if that doesn't naturally happen, though 21:54:06 So, design summit. While it's hot. Anything we should change next time ? Do we need more time ? 21:55:05 wifi was good :0 21:55:12 Some people told me the schedule was too busy so they were double-booked all the time... and some others told me they would not survive 4 or 5 days of this 21:55:24 it was my first summit. i loved it and it left me even more pumped up about OpenStack in general. My main issue was too many good sessions I wanted to be in. :-) <3 21:55:38 we do need to clone ourselves. but I don't think you want to spread it out to account for double booking. 21:56:05 my way of cloning is to accept to defer to others to make the right decisions 21:56:12 +1 21:56:29 I can't really sign up for more work than I can attend sessions anyway :) 21:56:32 is it possible to stagger/stairstep the wrapups (maybe that happened to some extent) 21:56:32 I thought the tracks were well separated by interest - loved that there was a devops track too. 21:56:55 med_: stairstep ? 21:56:59 So you could follow your interest. If you have multiple interest/investments then yes delegation is about the only option :) 21:57:05 * ttx looks up a dictionary 21:57:14 What did you think of the Ecosystem track folks? 21:57:43 annegentle: I think it was great, but we had too many non-Ecosystem talks in there 21:58:03 like things that was actually Nova or CI but could not fit in other track 21:58:11 hence my suggestion of adding one day 21:58:35 ttx: how would it work with conference if we added one day? 21:58:37 ttx, I meant not putting all of the track wrapups at the same time (ie, the last hour of the third day) 21:58:40 Lots of tracks would have loved to have more time in their track 21:58:53 med_: oh, I see. Good suggestion 21:59:14 ecosystem++, but i second not turning it into the dumping ground/overflow track. 21:59:21 danwent: the conference could run in parallel. Or the next week, for all I care :) 22:00:14 one thing that was kind of weird was the overlapping hour vs half-hour blocks. It led to some odd leaving or joining in the middle of some sessions. 22:00:47 russellb: it's an artifact of track-specific scheduling 22:00:48 I don't know if standardizing on a single length (45 min?) would be better, though. 22:01:08 if we do 4-5 days, we can standardize on a one-hour track 22:01:17 We really need discussions about what the Conference should be, how it helps people, and more details around invites and scaling the events for more and more contributors. 22:01:18 there were also a few complaints about the remote access/days 22:01:30 there were also a few complaints about the remote access 22:01:30 and just close the discussion if you don't have enough material to fit one hour 22:01:52 25 minutes was right for many brainstorming sessions and two of the 50 minute ones ended early that I was in. 22:02:10 annegentle: we should try to open up the design of the design summit, earlier rather than later 22:02:13 anyway, time is up 22:02:23 make sure to mention that in the upcoming survey 22:02:36 #endmeeting