21:01:24 <ttx> #startmeeting
21:01:25 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
21:01:27 * dabo waves
21:01:50 <ttx> Meeting agenda is available at http://wiki.openstack.org/Meetings
21:02:01 <ttx> #topic Current release stage: Submit specs for approval
21:02:23 <ttx> #info So the most pressing thing right now is to get all your blueprints/specs ready for approval
21:02:50 <ttx> If you are still lost in the process, I started the promised BlueprintsLifecycle page
21:02:57 <ttx> #link http://wiki.openstack.org/BlueprintsLifecycle
21:03:06 <xtoddx> ttx, will you or dendrobates leave notes on the blueprints for what is keeping it from approval?
21:03:10 <xtoddx> also, who can approve?
21:03:28 <ttx> xtoddx: dendrobates should approve
21:03:31 <dendrobates> yes we will leave notes and send emails
21:04:03 <ttx> SpecsSubmissionDeadline is Thursday, Nov 16, 23:59 UTC
21:04:28 <ttx> #link http://wiki.openstack.org/SpecsSubmissionDeadline
21:04:46 <ttx> That brings us to the release status topic...
21:05:12 <ttx> Unless there are questions on the specs submission process ?
21:05:33 <ttx> (if you have any, feel free to ask me or dendrobates)
21:05:42 <ttx> 5
21:05:45 <ttx> 4
21:05:48 <vishy> quick question
21:05:58 <ttx> I /knew/ I should have counted faster.
21:06:07 <ttx> vishy: yes ?
21:06:10 <vishy> if we come up with an important feature in the middle o
21:06:18 <vishy> for example 1 month from now
21:06:30 <vishy> is there any way to add a blueprint/spec into Bexar later?
21:06:42 <anotherjesse> for the things we don't know that we don't know
21:06:45 <ttx> vishy: yes, there is an exception process... but that sounds like a bad idea
21:07:02 <ttx> See "Exception procedure" in http://wiki.openstack.org/SpecsSubmissionDeadline
21:07:20 <ttx> All the freezes have an exception process. I'm in the process of documenting them all.
21:07:23 <dendrobates> anotherjesse: is there something specific you are thinking abour?
21:07:43 <dendrobates> an example perhaps?
21:08:03 <vishy> I have an example
21:08:19 <anotherjesse> 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 <vishy> so we have an (old) blueprint for whole-image booting
21:08:39 <vishy> we assume that that will allow us to boot windows images
21:08:50 <vishy> but no one has actually tested it
21:08:58 <dendrobates> bug fixing does not require any kind of spec
21:09:11 <vishy> 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 <dendrobates> vishy: we will deal with it then.  We have to expect things to come up.
21:09:47 <vishy> that is just the easiest example i can think of
21:09:49 <gundlach> creiht: it's no use, my bugs all got changed to blueprints when i wasn't looking!
21:09:56 <dendrobates> Hopefully that will not happen too often
21:10:13 <vishy> 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 <ttx> vishy:  that's the case of a bugfix needing to introduce new behavior
21:10:38 <ttx> vishy: which is kind of grey area that you can catch with the exception procedures
21:10:40 <vishy> ttx: so small features can be filed in bugfixes?
21:10:55 <anotherjesse> 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 <ttx> vishy: I would say they still require getting an exception granted
21:11:20 <vishy> ttx: ok
21:11:23 <creiht> This all seems very heavy weight to me
21:11:27 <ttx> since they modify nehavior, even if for the greater good
21:11:31 <ttx> behavior, even
21:12:03 <ttx> creiht: we can discuss this off-meeting
21:12:07 <ttx> other questions ?
21:12:11 <anotherjesse> we are going to make generic blueprints
21:12:15 <anotherjesse> for things like sys-ops panel
21:12:22 <anotherjesse> since we don't know the feature set yet
21:13:14 <xtoddx> anotherjesse: sounds good, but then can we make dependencies (blueprints) w/o invoking the exception process?
21:13:58 <xtoddx> 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 <anotherjesse> 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 <ttx> anotherjesse: hrm
21:14:53 <dabo> creiht: lol
21:15:10 <anotherjesse> we can make guesses, but just because we write a blueprint doesn't mean we will be doing it ;)
21:15:14 <eday> 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 <anotherjesse> eday - yes that is the theory - :)
21:15:49 <ttx> anotherjesse: your agile process seems a bit orthogonal with the 3-month time based release process
21:15:52 <dendrobates> oh, definitely. many approved bps are not implemented
21:16:18 <vishy> 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 <creiht> the 3-month release process seems a bit orthoginal to how both projects were developed in the first place :)
21:16:51 <ttx> I wish we would have had that discussion last week :)
21:16:56 <anotherjesse> anyway - we can continue
21:17:15 <dendrobates> creiht: we are releasing software in a completely different way than before
21:17:31 <dendrobates> the process needs to be a little different
21:17:53 <dendrobates> the tight feedback loop agile has with the stakeholder is different
21:17:57 <gundlach> 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 <eday> 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 <gundlach> s/release/OS release/
21:18:19 <xtoddx> gundlach: which isn't working out very well right now, have you seen our deploy branch?
21:18:27 <ttx> eday: I wouldn't have stated it any clearer :)
21:18:30 <vishy> gundlach: I see 7000 line patch number two in our future :p
21:18:31 <gundlach> xtoddx: that's why i called it the 'worst' case :)
21:18:43 <ttx> ok, moving on
21:18:49 <ttx> #topic Release status
21:19:09 <ttx> So at this point, I can only complain about the slow progress in getting specs submitted for approval...
21:19:35 <ttx> #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 <ttx> ... and two days left.
21:20:09 <ttx> So expect some nagging from me tomorrow.
21:20:16 <xtoddx> so we just need to set them to "pending approval"?
21:20:30 * creiht sighs
21:20:39 <ttx> See "Before SpecsSubmissionDeadline" in http://wiki.openstack.org/BlueprintsLifecycle
21:20:43 <vishy> 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 <ttx> xtoddx: in essence, yes (you should also set an assignee and a series goal)
21:21:25 <xtoddx> ttx: ok
21:21:49 <vishy> 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 <ttx> moving on in 5 seconds
21:22:00 <anotherjesse> 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 <gundlach> vishy: sounds good, as long as we don't just drop the issue :)
21:22:17 <ttx> anotherjesse: they are free to develop in branches
21:22:39 <ttx> anotherjesse: the process is for merging into trunk and getting into the release
21:22:41 <anotherjesse> 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 <eday> anotherjesse: or help with bug fixes or helping with existing blueprints
21:22:53 <anotherjesse> if the tests, docs, code works
21:23:26 <xtoddx> i hope that would be a reasonable example of how to use the "exception" process
21:23:32 <creiht> eday: open source is all about scratching your own itch, not scratching others
21:23:38 <dendrobates> anotherjesse: I think we might accept it with an exception
21:23:51 <xtoddx> i put that bad boy in air-quotes because that seems the norm for open source, not the exception
21:24:05 <ttx> anotherjesse: it bypasses the design summit discussion, preventing people to comment on the idea...
21:24:19 <eday> 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 <gundlach> ttx: mailing lists?
21:24:29 <anotherjesse> mailing lists are more accessible than design summits?
21:24:45 <anotherjesse> in general it seems like more should be happening there
21:24:52 <anotherjesse> (on mailing lists)
21:24:52 <gundlach> 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 <creiht> So someone has an idea, but can't make the design summit, so sorry, too bad?
21:25:21 <ttx> 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 <creiht> So does ubuntu tell mysql what features they can add?
21:25:59 <sandywalsh> 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 <piken> creiht: I think the solution there would be partial streaming of the summits with participation for remote partoies
21:26:15 <sandywalsh> developers will code at their own pace in their own branches?
21:26:22 <piken> s/partoies/parties/
21:26:28 <dendrobates> no, but they decide what version to merge
21:26:28 <ttx> 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 <creiht> dendrobates: which is fine by me
21:26:56 <xtoddx> ttx: is our process based on how canonical was run?
21:27:07 <creiht> xtoddx: more and more every day
21:27:19 <ttx> xtoddx: s/canonical/ubuntu/
21:27:28 <dendrobates> 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 <anotherjesse> ttx: does ubuntu track all features in blueprints for the software/projects it is built on?
21:27:44 <ttx> (canonical uses agile for internal development)
21:28:10 <ttx> anotherjesse: only for significant upstream changes
21:28:41 <anotherjesse> ttx: and the current process is to do blueprints for any non-bug change?
21:28:47 <anotherjesse> are their other projects that work that way?
21:29:13 * anotherjesse sucks at english - thanks for point it out vishy ;)
21:29:18 <dendrobates> 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 <vishy> lmao
21:29:41 <ttx> anotherjesse: drizzle
21:29:46 <dendrobates> blueprints are not change control
21:30:19 <dendrobates> 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 <sandywalsh> 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 <eday> 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 <anotherjesse> eday: that seems reasonable
21:31:32 <ttx> sandywalsh: blueprint is  a part of a release contract. The associated spec is  a design proposal
21:32:10 <sandywalsh> ttx, thx
21:32:17 <eday> 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 <gundlach> 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 <anotherjesse> 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 <ttx> ok, I propose that those uncomfortable with the current process start up a thread on the ML
21:33:02 <gundlach> #agreed
21:33:09 <vishy> #agreed
21:33:30 <ttx> (note #agreed can just be used by the chair :)
21:33:38 <vishy> oh :)
21:33:39 <eday> 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 <gundlach> #disagree to that
21:33:43 <gundlach> ;)
21:33:49 <tr3buchet> #agreed
21:33:53 <dendrobates> 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 <ttx> #action Dissenters to start a blueprint process thread on the MLs
21:33:58 <eday> larger/disributed coordination means more lead time and discussion
21:34:14 <ttx> and... moving on to
21:34:18 <ttx> #topic Full Bexar release schedule
21:34:26 <ttx> #link http://wiki.openstack.org/BexarReleaseSchedule
21:34:59 <ttx> I'm documenting all the freezes, should be done by tomorrow
21:35:15 <ttx> Hopefully the other ones won't meet that much resistance :)
21:35:44 <ttx> I'll also publish the tentative release schedule for Cactus soon
21:35:54 <ttx> Both are based on the consensus from the summit discussion
21:36:04 <ttx> Questions ?
21:37:44 <ttx> Moving on in 5 seconds
21:37:57 <ttx> #topic Contents of the release meeting
21:38:25 <ttx> So I wanted to open the floor on what you want out of the release meeting... recurrent subjects, if any.
21:38:33 <ttx> Personally I see:
21:38:38 <ttx> - Reminder of stage
21:38:51 <ttx> - Release status
21:38:58 <ttx> - Status of essential specs
21:39:11 <ttx> - Status of interdependant specs (specs depending on specs from another group)
21:39:47 <ttx> ^ I think that last one is particularly important, so make sure you record the dependencies between your blueprints
21:40:14 <ttx> Anything else you want to recurrently see in meetings ?
21:41:16 <anotherjesse> I would like to have a conversation about what the top issues that people see in the stack
21:41:24 <anotherjesse> it could be on the mailing list though
21:41:50 <anotherjesse> discussing at a high level what we need to focus on to make openstack successful
21:41:54 <ttx> anotherjesse: A recurrent "Blockers" subject ?
21:42:03 <ttx> Or would that fit an "Open discussion" topic ?
21:42:07 <dendrobates> we   could discuss the buglist
21:42:19 <dendrobates> and state of the merge queue
21:42:24 <anotherjesse> I think the bug list is too low level -- things like -- users want to deploy but the docs sucked
21:42:37 <anotherjesse> until Anne and others worked on it, it was the #1 comment I heard
21:42:42 <anotherjesse> from companies and hackers
21:42:53 <ttx> dendrobates: we'll discuss the RC bug list when we near release (after FeatureFreeze)
21:43:04 <ttx> dendrobates: you want to mention the "general state" of the bug lists ?
21:43:39 <dendrobates> how about bugs targeted to milestones
21:44:02 * ttx takes notes
21:44:20 <zul> i do like that that meeting is an hour earlier though
21:44:39 <dendrobates> zul: not for everyone
21:44:45 <eday> zul: only if you're in dst :)
21:44:59 <ttx> zul: don't start us on that one :)
21:45:13 <ttx> ok, anything else on the meeting contents subject ?
21:45:56 <ttx> #topic Open discussion
21:47:07 <creiht> so how can we change ubuntu's process so that those changes will bubble down to us?
21:47:10 <creiht> :)
21:47:25 <devcamcar> 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 <creiht> devcamcar: woot!
21:47:38 <devcamcar> it needs a bit of tlc
21:47:39 <soren> \o/
21:47:41 <creiht> too bad there isn't a blueprint for it
21:47:46 <creiht> :)
21:47:50 <dendrobates> creiht: our process is actually quite different
21:47:59 <zul> cool...does it just use the openstack api and the ec2 api?
21:48:30 <ttx> creiht: ubuntu (and drizzle) detail each blueprints into "work items" that you check out one by one in the Bp whiteboard
21:48:35 <anotherjesse> zul: openstack api doesn't yet have the feature set that the ec2 api has
21:48:54 <devcamcar> 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 <zul> anotherjesse: just making sure
21:49:10 <adjohn> devcamcar: great!  where are you going to post it?
21:49:13 <anotherjesse> after documentation - having to use EC2 to fully use nova is significant issue imho
21:49:47 <devcamcar> adjohn: TBD - working with greensius to figure out those details
21:49:48 <dendrobates> anotherjesse: I agree
21:50:01 <ttx> creiht/anotherjesse: I think most of your objections revolve around which changes warrant a blueprint and which not.
21:50:04 <devcamcar> the goal is for it to be on launchpad next to the other bits
21:50:05 <adjohn> devcamcar: excellent, looking forward to it
21:50:26 <creiht> ttx: My objections revolve around process getting in the way of getting things done
21:50:35 <anotherjesse> 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 <devcamcar> 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 <anotherjesse> devcamcar: and probably as a separate project?
21:51:14 <anotherjesse> in the openstack group
21:51:22 <devcamcar> anotherjesse: yes
21:52:03 <ttx> creiht/anotherjesse: noted. I'll let you develop that in the Freedom vs. Time-based process thread.
21:52:03 <anotherjesse> dendrobates: are there stackers or rackers focusing on expanding the OS api to have more features ?
21:52:04 <eday> 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 <eday> creiht: I'm all for minimal process though, I just don't know what the right balance is yet
21:52:33 <eday> anotherjesse: yes, the ozone team
21:52:33 <gundlach> anotherjesse: i'll probably end up working on that, as i've done a lot of the API thus far
21:52:54 <anotherjesse> gundlach: if you add an example of how to extend things we can help
21:52:59 <dendrobates> we are waiting for rackspace to release 1.1 and hand the namespace over.  We can make minimal changes before then
21:53:10 <anotherjesse> it would be nice to develop the "sys-admin apis" against it from the beginning
21:53:19 <ttx> 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 <xtoddx> anotherjesse, dendrobates: we should discuss the "service catalog" as part of API version rev
21:53:47 <gundlach> anotherjesse: cool, i'm not sure exactly what there is to show but i'll be happy to help.
21:53:48 <ttx> not too many blueprints (so not too much time spent updating them) and still being able to track progress
21:53:53 <dendrobates> we want to make sure they at least finalize what is going in it, so we don't duplicate their work
21:55:11 <ttx> ok, I'll close it now, feel free to continue discussions in #openstack
21:55:14 <anotherjesse> 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 <anotherjesse> 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 <xtoddx> 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 <gundlach> anotherjesse: got it.  WSGI makes it easy as pie.
21:56:17 <anotherjesse> xtoddx: does this exist?
21:56:26 <gundlach> anotherjesse: like destro said, you may want to wait until RS hands off the 1.1 API
21:56:26 <anotherjesse> I've only done EC2 api stuff
21:56:32 <xtoddx> anotherjesse: not yet, but pvo and some others are discussing it
21:56:37 <anotherjesse> gundlach / dendrobates eta?
21:57:00 <anotherjesse> xtoddx: right but we want to start adding those api methods (like stop/start/list VPNs) now
21:57:00 <gundlach> anotherjesse: anyhow, i'll start a mail w/ you and annegentle about the best way to document this :)
21:57:08 <ttx> any last minute comment ?
21:57:15 <annegentle> gundlach, anotherjesse: I'm all ears
21:57:25 <ttx> #endmeeting