21:01:24 #startmeeting 21:01:25 Meeting started Tue Nov 16 21:01:24 2010 UTC. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:01:26 Useful Commands: #action #agreed #help #info #idea #link #topic. 21:01:27 * dabo waves 21:01:50 Meeting agenda is available at http://wiki.openstack.org/Meetings 21:02:01 #topic Current release stage: Submit specs for approval 21:02:23 #info So the most pressing thing right now is to get all your blueprints/specs ready for approval 21:02:50 If you are still lost in the process, I started the promised BlueprintsLifecycle page 21:02:57 #link http://wiki.openstack.org/BlueprintsLifecycle 21:03:06 ttx, will you or dendrobates leave notes on the blueprints for what is keeping it from approval? 21:03:10 also, who can approve? 21:03:28 xtoddx: dendrobates should approve 21:03:31 yes we will leave notes and send emails 21:04:03 SpecsSubmissionDeadline is Thursday, Nov 16, 23:59 UTC 21:04:28 #link http://wiki.openstack.org/SpecsSubmissionDeadline 21:04:46 That brings us to the release status topic... 21:05:12 Unless there are questions on the specs submission process ? 21:05:33 (if you have any, feel free to ask me or dendrobates) 21:05:42 5 21:05:45 4 21:05:48 quick question 21:05:58 I /knew/ I should have counted faster. 21:06:07 vishy: yes ? 21:06:10 if we come up with an important feature in the middle o 21:06:18 for example 1 month from now 21:06:30 is there any way to add a blueprint/spec into Bexar later? 21:06:42 for the things we don't know that we don't know 21:06:45 vishy: yes, there is an exception process... but that sounds like a bad idea 21:07:02 See "Exception procedure" in http://wiki.openstack.org/SpecsSubmissionDeadline 21:07:20 All the freezes have an exception process. I'm in the process of documenting them all. 21:07:23 anotherjesse: is there something specific you are thinking abour? 21:07:43 an example perhaps? 21:08:03 I have an example 21:08:19 dendrobates: not yet, but if we fix a bug or add a feature needed by a client (such as windows support) but we didn't think it was going to be high priority, it would suck to have it bit rot for months until the next release 21:08:24 so we have an (old) blueprint for whole-image booting 21:08:39 we assume that that will allow us to boot windows images 21:08:50 but no one has actually tested it 21:08:58 bug fixing does not require any kind of spec 21:09:11 so if 1 month down the line we realize that we actually need feature X to make windows usable 21:09:19 * creiht quickly changes his blue prints to bugs 21:09:43 vishy: we will deal with it then. We have to expect things to come up. 21:09:47 that is just the easiest example i can think of 21:09:49 creiht: it's no use, my bugs all got changed to blueprints when i wasn't looking! 21:09:56 Hopefully that will not happen too often 21:10:13 I just want to make sure that we all realize we're not in a magical universe where we can forsee 2 months into the future and know everything that we will need 21:10:15 vishy: that's the case of a bugfix needing to introduce new behavior 21:10:38 vishy: which is kind of grey area that you can catch with the exception procedures 21:10:40 ttx: so small features can be filed in bugfixes? 21:10:55 dendrobates: probably a larger item is that we are going to be building tools to help run the system (like a sys-ops ui, api, ...) - we don't know all the features of the API yet since we are adding them as they become something our ops people need 21:11:10 vishy: I would say they still require getting an exception granted 21:11:20 ttx: ok 21:11:23 This all seems very heavy weight to me 21:11:27 since they modify nehavior, even if for the greater good 21:11:31 behavior, even 21:12:03 creiht: we can discuss this off-meeting 21:12:07 other questions ? 21:12:11 we are going to make generic blueprints 21:12:15 for things like sys-ops panel 21:12:22 since we don't know the feature set yet 21:13:14 anotherjesse: sounds good, but then can we make dependencies (blueprints) w/o invoking the exception process? 21:13:58 are blueprints that are dependencies of accepted specs exempt from exceptions, assuming they exist for no reason other than to break up work from the larger, accepted blueprint? 21:13:59 we use an agile process - where every 3 weeks is a new sprint ... so our feature set is always based on the results of the last sprint and requirements from clients 21:14:30 * creiht hears the water falling 21:14:32 anotherjesse: hrm 21:14:53 creiht: lol 21:15:10 we can make guesses, but just because we write a blueprint doesn't mean we will be doing it ;) 21:15:14 anotherjesse: ahh, so in theory all the blueprints you guys are going to work on in the next couple months should have been discussed last week :) 21:15:27 eday - yes that is the theory - :) 21:15:49 anotherjesse: your agile process seems a bit orthogonal with the 3-month time based release process 21:15:52 oh, definitely. many approved bps are not implemented 21:16:18 If this is the development style that openstack is adopting, we'll just have to hornswaggle our sprints into bps and specs as best we can. 21:16:33 the 3-month release process seems a bit orthoginal to how both projects were developed in the first place :) 21:16:51 I wish we would have had that discussion last week :) 21:16:56 anyway - we can continue 21:17:15 creiht: we are releasing software in a completely different way than before 21:17:31 the process needs to be a little different 21:17:53 the tight feedback loop agile has with the stakeholder is different 21:17:57 worst case, anso labs will just be 3 months ahead of OS, and they will contribute back their changes in a big merge after each release. 21:18:07 well, one thing to keep in mind, both projects were developed by smaller teams.. getting larger and being in the open tends to require a bit more structure since many loosely connected folks are involved, hence the 3 month thing. the tough part is finding a balance :) 21:18:08 s/release/OS release/ 21:18:19 gundlach: which isn't working out very well right now, have you seen our deploy branch? 21:18:27 eday: I wouldn't have stated it any clearer :) 21:18:30 gundlach: I see 7000 line patch number two in our future :p 21:18:31 xtoddx: that's why i called it the 'worst' case :) 21:18:43 ok, moving on 21:18:49 #topic Release status 21:19:09 So at this point, I can only complain about the slow progress in getting specs submitted for approval... 21:19:35 #info Looking at the design summit blueprints, we have 15% of them ready, 10% obviously in progress and 75% not updated yet 21:19:46 ... and two days left. 21:20:09 So expect some nagging from me tomorrow. 21:20:16 so we just need to set them to "pending approval"? 21:20:30 * creiht sighs 21:20:39 See "Before SpecsSubmissionDeadline" in http://wiki.openstack.org/BlueprintsLifecycle 21:20:43 most of mine I wrote the specs out prior to summint. I'll go through and update them tonight 21:21:08 * gundlach wonders if we need to spend more time on the release process topic since there seems to be some unrest still? though i don't mean to drag out the meeting... 21:21:18 xtoddx: in essence, yes (you should also set an assignee and a series goal) 21:21:25 ttx: ok 21:21:49 gundlach: I don't think we're going to get any resolution here, we may have to take it to the mailing list 21:21:51 moving on in 5 seconds 21:22:00 I guess I don't see how blueprints will work when people join at random times - do we force new people to hold off development on their idea until the next release? 21:22:08 vishy: sounds good, as long as we don't just drop the issue :) 21:22:17 anotherjesse: they are free to develop in branches 21:22:39 anotherjesse: the process is for merging into trunk and getting into the release 21:22:41 and if they develop in a branch and it works, and we aren't in feature freeze, why not accept it then? 21:22:51 anotherjesse: or help with bug fixes or helping with existing blueprints 21:22:53 if the tests, docs, code works 21:23:26 i hope that would be a reasonable example of how to use the "exception" process 21:23:32 eday: open source is all about scratching your own itch, not scratching others 21:23:38 anotherjesse: I think we might accept it with an exception 21:23:51 i put that bad boy in air-quotes because that seems the norm for open source, not the exception 21:24:05 anotherjesse: it bypasses the design summit discussion, preventing people to comment on the idea... 21:24:19 creiht: and that usually manifests itself as fixing bugs. :) but yeah, I agree.. new features would be nice to include if it's reasonable 21:24:20 ttx: mailing lists? 21:24:29 mailing lists are more accessible than design summits? 21:24:45 in general it seems like more should be happening there 21:24:52 (on mailing lists) 21:24:52 ttx: e.g. the idea to break apart the DB into many small ones. there was lots of discussion of that in mailing lists, and then we basically said "yep, let's do it" at the summit. 21:25:11 So someone has an idea, but can't make the design summit, so sorry, too bad? 21:25:21 The summit is really good to make decisions. MLs are not so great for reaching consensus 21:25:35 * ttx feels general unrest 21:25:50 So does ubuntu tell mysql what features they can add? 21:25:59 isn't the only thing that blue print approval does is "strongly hope" that a branch will get merged at an preset time? 21:26:14 creiht: I think the solution there would be partial streaming of the summits with participation for remote partoies 21:26:15 developers will code at their own pace in their own branches? 21:26:22 s/partoies/parties/ 21:26:28 no, but they decide what version to merge 21:26:28 sorry, I thought most of the process was agreed upon :/ I guess we need to discuss it a bit more. I really wish we had that discussion last week, now :/ 21:26:50 dendrobates: which is fine by me 21:26:56 ttx: is our process based on how canonical was run? 21:27:07 xtoddx: more and more every day 21:27:19 xtoddx: s/canonical/ubuntu/ 21:27:28 we have to have a predictable release. with it becoming more clear as time passes what will be included and what will not 21:27:44 ttx: does ubuntu track all features in blueprints for the software/projects it is built on? 21:27:44 (canonical uses agile for internal development) 21:28:10 anotherjesse: only for significant upstream changes 21:28:41 ttx: and the current process is to do blueprints for any non-bug change? 21:28:47 are their other projects that work that way? 21:29:13 * anotherjesse sucks at english - thanks for point it out vishy ;) 21:29:18 if you releasing something that is getting deployed internally with clear stakeholders agile works very well, it needs to be modified for our case 21:29:29 lmao 21:29:41 anotherjesse: drizzle 21:29:46 blueprints are not change control 21:30:19 they are to give us and all the people and businesses around us an idea of what is going into a release and let us track progress 21:30:47 personally I'm confused with a blue print being a design proposal vs. a part of a release contract. Or is it both? 21:31:08 ttx: one thing with drizzle though, blueprints were frequently injexted mid-cycle, we didn't really have an exception process. if it sounded good on the ml/irc, it was in (at least when I was involved) 21:31:23 eday: that seems reasonable 21:31:32 sandywalsh: blueprint is a part of a release contract. The associated spec is a design proposal 21:32:10 ttx, thx 21:32:17 I'm not sure which is the "best", i've seen a few different methods work fine and fail.. really depends on the folks involved 21:32:21 eday: that was my impression of how ubuntu worked -- blueprints can be added at any time, but their features must be in by feature freeze at which point we switch to polish mode. seems like more work would get done per release that way... 21:32:26 eday: we are a young project - and it feels like there are too many unknowns about openstack and the community to know 3 months ahead of time everything that will exist 21:32:42 ok, I propose that those uncomfortable with the current process start up a thread on the ML 21:33:02 #agreed 21:33:09 #agreed 21:33:30 (note #agreed can just be used by the chair :) 21:33:38 oh :) 21:33:39 anotherjesse: that's how drizzle was. "oh, we really need to rework the auth plugin layer" one month before release.. so we'd create a blueprint and code. again, not sure if this was the best way since most of the discussion happened on a weekly call with a small team 21:33:40 #disagree to that 21:33:43 ;) 21:33:49 #agreed 21:33:53 we need a starting point for a process and this is it. There nothing that is going to be draconian about it. 21:33:56 #action Dissenters to start a blueprint process thread on the MLs 21:33:58 larger/disributed coordination means more lead time and discussion 21:34:14 and... moving on to 21:34:18 #topic Full Bexar release schedule 21:34:26 #link http://wiki.openstack.org/BexarReleaseSchedule 21:34:59 I'm documenting all the freezes, should be done by tomorrow 21:35:15 Hopefully the other ones won't meet that much resistance :) 21:35:44 I'll also publish the tentative release schedule for Cactus soon 21:35:54 Both are based on the consensus from the summit discussion 21:36:04 Questions ? 21:37:44 Moving on in 5 seconds 21:37:57 #topic Contents of the release meeting 21:38:25 So I wanted to open the floor on what you want out of the release meeting... recurrent subjects, if any. 21:38:33 Personally I see: 21:38:38 - Reminder of stage 21:38:51 - Release status 21:38:58 - Status of essential specs 21:39:11 - Status of interdependant specs (specs depending on specs from another group) 21:39:47 ^ I think that last one is particularly important, so make sure you record the dependencies between your blueprints 21:40:14 Anything else you want to recurrently see in meetings ? 21:41:16 I would like to have a conversation about what the top issues that people see in the stack 21:41:24 it could be on the mailing list though 21:41:50 discussing at a high level what we need to focus on to make openstack successful 21:41:54 anotherjesse: A recurrent "Blockers" subject ? 21:42:03 Or would that fit an "Open discussion" topic ? 21:42:07 we could discuss the buglist 21:42:19 and state of the merge queue 21:42:24 I think the bug list is too low level -- things like -- users want to deploy but the docs sucked 21:42:37 until Anne and others worked on it, it was the #1 comment I heard 21:42:42 from companies and hackers 21:42:53 dendrobates: we'll discuss the RC bug list when we near release (after FeatureFreeze) 21:43:04 dendrobates: you want to mention the "general state" of the bug lists ? 21:43:39 how about bugs targeted to milestones 21:44:02 * ttx takes notes 21:44:20 i do like that that meeting is an hour earlier though 21:44:39 zul: not for everyone 21:44:45 zul: only if you're in dst :) 21:44:59 zul: don't start us on that one :) 21:45:13 ok, anything else on the meeting contents subject ? 21:45:56 #topic Open discussion 21:47:07 so how can we change ubuntu's process so that those changes will bubble down to us? 21:47:10 :) 21:47:25 so we've been discussing internally and there aren't any legal barriers left for us to open source our django based web ui 21:47:36 devcamcar: woot! 21:47:38 it needs a bit of tlc 21:47:39 \o/ 21:47:41 too bad there isn't a blueprint for it 21:47:46 :) 21:47:50 creiht: our process is actually quite different 21:47:59 cool...does it just use the openstack api and the ec2 api? 21:48:30 creiht: ubuntu (and drizzle) detail each blueprints into "work items" that you check out one by one in the Bp whiteboard 21:48:35 zul: openstack api doesn't yet have the feature set that the ec2 api has 21:48:54 zul: currently it uses the ec2 api. it has ui's for volumes, security groups, and a few others items that aren't supported yet by the openstack api. it's our goal to move to openstack api once there is parity 21:49:02 anotherjesse: just making sure 21:49:10 devcamcar: great! where are you going to post it? 21:49:13 after documentation - having to use EC2 to fully use nova is significant issue imho 21:49:47 adjohn: TBD - working with greensius to figure out those details 21:49:48 anotherjesse: I agree 21:50:01 creiht/anotherjesse: I think most of your objections revolve around which changes warrant a blueprint and which not. 21:50:04 the goal is for it to be on launchpad next to the other bits 21:50:05 devcamcar: excellent, looking forward to it 21:50:26 ttx: My objections revolve around process getting in the way of getting things done 21:50:35 ttx: mine resolve around the fact I know people will come in with cool patches/ideas and don't want to slow down good code getting added 21:50:43 we'll be releasing it as two parts: a django module and a reference implementation of a django site that incorporates it 21:51:10 devcamcar: and probably as a separate project? 21:51:14 in the openstack group 21:51:22 anotherjesse: yes 21:52:03 creiht/anotherjesse: noted. I'll let you develop that in the Freedom vs. Time-based process thread. 21:52:03 dendrobates: are there stackers or rackers focusing on expanding the OS api to have more features ? 21:52:04 creiht: on the other hand, there needs to be some process so folks know what is getting done, and for there to be a forum/time to discuss and make sure things get done in the right way. we can't develop independently and hope it all merges clean in the end :) 21:52:20 creiht: I'm all for minimal process though, I just don't know what the right balance is yet 21:52:33 anotherjesse: yes, the ozone team 21:52:33 anotherjesse: i'll probably end up working on that, as i've done a lot of the API thus far 21:52:54 gundlach: if you add an example of how to extend things we can help 21:52:59 we are waiting for rackspace to release 1.1 and hand the namespace over. We can make minimal changes before then 21:53:10 it would be nice to develop the "sys-admin apis" against it from the beginning 21:53:19 eday: I think if you trigger blueprints only for significant changes (or as a feature group) we get the best of both worlds 21:53:44 anotherjesse, dendrobates: we should discuss the "service catalog" as part of API version rev 21:53:47 anotherjesse: cool, i'm not sure exactly what there is to show but i'll be happy to help. 21:53:48 not too many blueprints (so not too much time spent updating them) and still being able to track progress 21:53:53 we want to make sure they at least finalize what is going in it, so we don't duplicate their work 21:55:11 ok, I'll close it now, feel free to continue discussions in #openstack 21:55:14 gundlach: i'm afraid the details of where / how to implement the additional apis will be more time consuming then the of implementing the APIs themselves 21:55:48 gundlach: so taking a simple api method that doesn't exist in the "openstack api guide" and adding it would be useful to work through the mechanics 21:56:03 anotherjesse: thats where service catalog comes in, then new apis can just register themselves and be discoverable, w/o modifying the existing api docs 21:56:09 anotherjesse: got it. WSGI makes it easy as pie. 21:56:17 xtoddx: does this exist? 21:56:26 anotherjesse: like destro said, you may want to wait until RS hands off the 1.1 API 21:56:26 I've only done EC2 api stuff 21:56:32 anotherjesse: not yet, but pvo and some others are discussing it 21:56:37 gundlach / dendrobates eta? 21:57:00 xtoddx: right but we want to start adding those api methods (like stop/start/list VPNs) now 21:57:00 anotherjesse: anyhow, i'll start a mail w/ you and annegentle about the best way to document this :) 21:57:08 any last minute comment ? 21:57:15 gundlach, anotherjesse: I'm all ears 21:57:25 #endmeeting