17:04:28 <dendrobates> #startmeeting
17:04:29 <open_stack> Meeting started Fri Aug 27 17:04:28 2010 UTC.  The chair is dendrobates. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:04:30 <open_stack> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:04:30 <dendrobates> hello
17:04:41 <pvo> phew, it worked. :)
17:04:53 <_0x44> pvo: Is he connected over your nexus one?
17:05:04 <pvo> _0x44: hopefully over his nexus one. : )
17:05:06 <jk0> hah
17:05:06 <spy> yay
17:05:19 <dendrobates> #link http://wiki.openstack.org/Meetings
17:05:45 <dendrobates> I am lagging a bit so if I drop I will need someone to take over
17:06:32 <dendrobates> Topic:  Release
17:07:03 <dendrobates> #topic Blueprints
17:07:17 <dendrobates> damn meetbot
17:07:52 <dendrobates> first I wan to talk about what we want the austin release to be.
17:08:21 <dendrobates> We doing time based not feature based releases
17:08:54 <dendrobates> with the caveat that we might slip a date only if a mandatory feature is not ready.
17:09:04 <dendrobates> but we don;t expect that to happen.
17:09:23 <dendrobates> The mandatory features for Austin are:
17:09:36 <dendrobates> Rackspace API
17:09:50 <dendrobates> Image caching service
17:09:56 <dendrobates> Xen support
17:10:51 <clayg> Image caching service == Glance ?
17:10:54 <dendrobates> everything else only goes in if it is ready by feature freeze and stable by final freeze
17:11:04 <dendrobates> clayg: yes
17:11:22 <dendrobates> do the swift guys have any required features?
17:11:24 <pvo> what about the pluggable scheduler for nova? Is that mandatory?
17:11:31 <clayg> is rconradharris here?
17:11:35 <_0x44> dendrobates: We need to #info that for the meetbot to log it.
17:11:39 <_0x44> #info mandatory features for austin are: Rackspace API, Image Caching Service, Xen support
17:11:50 <dubs> clayg: yes, that is sirp1
17:11:51 <sirp1> *rconradharris*
17:11:54 <dendrobates> meetbot is not responding
17:12:05 <pvo> it doesn't while in flight
17:12:09 <spy> dendrobates: it doesn't respond for info
17:12:19 <dendrobates> hmm
17:12:19 <gholt> For Swift, Very Large File Support is required, I have many more desired.
17:12:20 <dendrobates> ok
17:12:29 <pvo> #help
17:12:43 <dendrobates> gholt: what about nova auth for swirt
17:12:48 <dendrobates> required or not?
17:13:25 <gholt> Unsure on that. I'd like a separate Scalable Auth Project. I've been working on Swauth to hopefully fill that gap, but..
17:13:46 <_0x44> #info swift mandatory features for austin: very large file support, more desired
17:13:48 <dendrobates> ok, we will not make it a req, if it gets done it gets done.
17:13:58 <dubs> gholt: are public containers in swift set for Austin?
17:14:18 <gholt> I hope so, and they should be barring performance problems.
17:14:38 <gholt> They are second on my list. :)
17:14:39 <pvo> dubs: that what I heard.
17:14:52 <dendrobates> So everybody should have gotten the message that for every feature we need a blueprint and spec by next friday
17:15:34 <dendrobates> I will be glad to help anyone that needs it
17:15:39 <gholt> Yes, I've been putting that off, sorry. I'll do that today/this-weekend for what I see in Swift.
17:16:15 <letterj> What are we going to use for a mulit-server test/qa lab?
17:16:40 <gholt> I love for bringing that up. :)
17:17:06 <letterj> Is having a test/qa lab a requirement for the release?
17:17:13 <dendrobates> We have a couple of options, we can use soren's uml work to do some testing in the rackspace cloud
17:17:47 <dendrobates> and we will have to spin up some servers in the rackspace lab for bare metal testing
17:18:02 <pvo> I think the concern is how to measure performance impacts for large clusters
17:18:05 <dendrobates> NASA might be able to help with testing as well.
17:18:44 <letterj> there is no public access in the rackspace lab.  (Something to keep in mind)
17:18:48 <gholt> Is the funding in place, ongoing for a Rackspace sponsored lab? Will it be accessible to all contributors? etc.
17:18:49 <dendrobates> We need a in depth test plan, which we donot have yet.
17:19:16 <letterj> I'm assuming blueprints will be needed for that?
17:19:17 <pvo> dendrobates: you or I can take that as an action item
17:19:35 <pvo> its a discussion point first before we have blueprint, no?
17:20:01 <dendrobates> #action find out about rackspace test lab for qa
17:20:05 <pvo> #action Determine testing/qa environments for OpenStack
17:20:06 <pvo> heh
17:20:08 <letterj> I'll be happy to help with the swift side as much as I can
17:20:24 <dendrobates> a blueprint for what, testing?
17:20:55 <letterj> yes testing and qa process
17:20:56 <pvo> yea, to find out about testing
17:21:27 <dendrobates> I hadn't thought that we would, but it is a good idea
17:22:09 <dendrobates> #action create a testing/QA blueprint
17:22:39 <dendrobates> Does anyone have any questions about blueprints?
17:22:57 <dendrobates> Is there anyone else that would volunteer to help others with Blueprints?
17:23:05 <gholt> There will definitely be some lab contention, so getting your-favorite-feature-to-be-tested on some list will help. "You get x days in the lab starting on y, succeed or unmerge" :)
17:23:32 <pvo> i guess we can explore UML in the public cloud, no?
17:23:38 <spy> really if we could get some sort of openstack images in the cloud, we could spin up an environment very easily
17:23:54 <spy> we could have the images check out the latest code as they come on-line or something
17:24:20 <soren> pvo: Yeah, with my last few patches to libvirt, its UML support seems to be in really good shape.
17:24:34 <spy> probably wouldn't be ideal for performance but integration testing
17:24:36 <dendrobates> that's a good thing about having Rackspace as a primary sponsor servers galoree
17:24:38 <pvo> soren: yea, thats exactly what I was thinking.
17:25:03 <dendrobates> the topic is still blueprints
17:25:13 <dendrobates> are there any more questions about them?
17:25:22 <soren> My primary motivation for doing that work was exactly for testing, but of course we still need testing with serious hypervisors.
17:25:38 <dendrobates> does everyone understand what needs to be done?
17:25:39 <dendrobates> I will take silence as yes
17:26:04 <littleidea> is there a good document that explains blueprints and how to use them/interact with the community through them?
17:26:56 <dendrobates> littleidea: I'm not sure. There should be.  I'll ask the launchpad folks
17:27:27 <dendrobates> if I find anything, I'll send it to the openstack ml
17:27:27 <_0x44> Are we still using the etherpad to do the writeups of the blueprints since the blueprint UI was so abysmal?
17:27:38 * _0x44 remembers some discussion about that in #openstack
17:27:39 <eday> https://help.launchpad.net/Blueprint  is a good start
17:27:50 <sirp1> #link https://help.launchpad.net/Blueprint
17:27:54 <soren> https://edge.launchpad.net/+tour/feature-tracking  perhaps
17:28:08 <soren> Err... without "edge.".
17:28:14 <dendrobates> they need to end up in lainchpad so I can track and approve them
17:28:24 <soren> #link https://launchpad.net/+tour/feature-tracking
17:28:46 <dendrobates> I think we need a naming scheme for blueprints too
17:28:51 <dendrobates> any suggestions?
17:29:06 <pvo> can you give an example?
17:29:09 <kirkland> $(tempfile)
17:29:20 <pvo> are you meaning if we want it in austin, it would be austin-someniftyfeature ?
17:29:31 <dendrobates> openstack-$release-feature
17:29:46 <pvo> works for me
17:29:55 <clayg> and if it's not ready for release... does it get renamed to try for next time?
17:29:56 <dendrobates> or openstack-component-release-feature
17:30:03 <dendrobates> or ...
17:30:08 <dendrobates> yes
17:30:12 <pvo> just nitpicking, but is the 'openstack' part redundant?
17:30:18 <_0x44> If they're already associated with a
17:30:20 <_0x44> Err what pvo said
17:30:33 <dendrobates> true,
17:30:37 <_0x44> Would release-component-feature be better?
17:30:41 <_0x44> That way they're grouped by release
17:30:41 <pvo> yes
17:30:42 <dendrobates> but shutup :)
17:30:46 <eday> _0x44: yeah, there is a wiki/spec link on the blueprint, and I've been linking ehterpad docs to those that need more
17:30:46 <_0x44> And then by component
17:31:48 <_0x44> eday: I think people have preferred the etherpad docs to the wiki/spec stuff attached to the blueprints. I guess we can use both, but it would be nice if we only had to worry about one.
17:32:42 <eday> _0x44: well, they don't really overlap.. etherpad is just the description.. blueprints have assignment, project tracking, dependencies, ...
17:32:51 <spy> might be a good idea to work in etherpad, and once the doc is completed update it in the blueprint
17:33:07 <eday> I would say don't put the release name in the blueprint, since we have URLs like this to do that for us: https://blueprints.launchpad.net/nova/austin
17:33:21 <_0x44> eday: No, I meant use etherpad instead of the wiki/spec, not instead of the blueprint.
17:33:24 <jaypipes> spy: ++
17:33:31 <eday> lots of renaming if a feature doesn't make a release
17:33:56 <eday> _0x44: oh, yeah
17:34:07 <_0x44> Are we doing blueprints in each component or in the umbrella project?
17:34:09 <eday> _0x44: I've been using etherpad over the wiki
17:34:10 <dabo> eday: +1
17:34:24 <jaypipes> _0x44: good question.
17:34:42 <_0x44> If we do them in the components, then the naming scheme is just "feature name"
17:34:42 <jaypipes> _0x44: I prefer to put them in the specific project unless the blueprint touches multiple projects...
17:35:22 <eday> jaypipes: ++, and if they do touch many, it's probably going to actually be in another project like openstack-common :)
17:35:37 <jaypipes> _0x44: or "feature-category-feature-name" ... example: data-model-support-sqlite ?
17:35:48 <jaypipes> eday: yeah, agreed.
17:36:08 <_0x44> jaypipes I'd prefer a different delimiter than hyphen in that case.
17:37:10 <dendrobates> ok I'm back
17:37:12 <jaypipes> _0x44: sure, no worries...
17:37:32 <dendrobates> did we come to agreement on bluepprint naming?
17:37:33 <_0x44> dendrobates: Blueprints in the umbrella project or in the component projects?
17:37:34 <jaypipes> _0x44: any prefix is fine.  Consistency is my only need
17:37:52 <dendrobates> umbrella
17:38:00 <_0x44> WHy?
17:38:10 * jaypipes votes for blueprints in subproject
17:38:19 * _0x44 agrees with jaypipes
17:38:23 <dendrobates> jaypipes: why?
17:38:24 <_0x44> (shock, horror)
17:38:43 <jaypipes> dendrobates: for blueprints that touch on multiple projects, use the openstack-common project.
17:39:18 <jaypipes> dendrobates: and for blueprints that affect things like the unified build and packaging platforms (like Hduson/Tarmac), put the blueprint in the umbrella project
17:39:21 <dendrobates> I am concerned with tracking the whole project and ensuring all the subprojects are on track
17:39:32 <dendrobates> ok, I see
17:39:45 <dendrobates> I'm talking about naming only
17:39:47 <eday> dendrobates: you still cna if they are created in the context of a project
17:39:55 <dendrobates> not obout where we create them
17:39:57 <jaypipes> dendrobates: I understand that concern, but Nova devs don't necessarily want to sift through Swift blueprints and vice versa...
17:40:25 <_0x44> dendrobates: Right, but if they're tracked in the sub project they won't need a project prefix.
17:40:27 <dendrobates> the will all show up in the umbrella project any way, so I agree
17:40:38 <dendrobates> I would still like a prefix
17:40:40 <_0x44> We can use "feature-categoryDELIMITERfeature-name"
17:40:44 <jaypipes> dendrobates: ah, sorry. misunderstood.  I think it would be a better idea (than prefixing blueprint names with the project name) to bug the LP team to have better search/filtering for lists of blueprints! :)
17:40:52 <_0x44> ^^^ +1
17:41:00 <gholt> Ah, do the blueprints float up to the umbrella?
17:41:10 * jaypipes has had a beef with the blueprints filtering ability for a while now..
17:41:15 <dendrobates> let me check , I assumed so.
17:41:19 <eday> gholt: they do, see: https://blueprints.launchpad.net/openstack/
17:41:22 <jaypipes> gholt: yes
17:41:30 <gholt> Gotcha. They do have the project column though...
17:41:36 <jaypipes> gholt: which would be great if we could filter the list by project... :)
17:41:58 <gholt> Well, none of the project workers would use that, just dendrobates. :)
17:42:04 <eday> jaypipes: just add project to that URL :)
17:42:05 <dendrobates> yes
17:42:12 <dendrobates> ant it list the sub project
17:42:14 <_0x44> dendrobates: Each blueprint is already labeled by project
17:42:15 <dendrobates> weeeeee
17:42:24 <jaypipes> gholt: hey, poison frog is important, too ;)
17:42:40 <jaypipes> _0x44, eday: hmm, that's new.  cool.. much beter.
17:42:51 <_0x44> jaypipes: Only because Destro hangs with the Baronness
17:42:58 <jaypipes> hehe
17:43:08 <dendrobates> so are we in agreement?
17:43:11 <jaypipes> OK, so does that settle the prefix-with-project debate?
17:43:19 <jaypipes> ++ from me.
17:43:44 <dendrobates> blueprints under the subproject named - $release-feature?
17:43:56 <dendrobates> or did I miss something else?
17:44:09 <_0x44> dendrobates: We sort of decided not to prefix with release name
17:44:09 <eday> dendrobates: I think we decided without project name in there, since that is already a field
17:44:20 <_0x44> Because if it gets dumped from a release we have to rename it.
17:44:29 <pvo> so, just feature, under the subproject
17:44:33 <gholt> Series is also a blueprint column. :)
17:45:04 <gholt> So just component/feature is fine by me. Hehe
17:45:05 <dendrobates> I want release in the name
17:45:11 <eday> dendrobates: why?
17:45:11 <_0x44> So $feature_category/$feature
17:45:14 <dendrobates> they are trivial to change
17:45:14 <_0x44> ?
17:45:37 <dendrobates> and they help with sorting.
17:45:39 <soren> Searchability.
17:46:09 <soren> Stuff doesn't land on b.l.n/openstack/austin (as an example) until it's actually been approved for that release.
17:46:19 <soren> ...so until then, the only way to filter stuff is by name.
17:46:21 <soren> IIRC.
17:46:25 <dendrobates> so let me repeat I want the release as a prefix
17:46:38 <gholt> soren: Ah, gotcha
17:46:46 <dendrobates> it also let's you weed out old bluprints
17:46:52 <jaypipes> dendrobates: I strongly disagree with that, having been the person to rename crap-tons of blueprints in the past...
17:47:09 <eday> soren: but then as features slip we need to rename them all :)
17:47:33 <dendrobates> jaypipes: let;s agree to disagree.   I have also renamed a crap ton of blueprints
17:47:42 <_0x44> I think we can probably compromise on this by allowing dendrobates release names in blueprints, but if they slip he has to rename them.
17:47:58 <dendrobates> or delegate someone to do it
17:48:22 <_0x44> I dunno, if you want them this badly, you should be prepared to do the effort of maintaining them.
17:48:32 <jaypipes> dendrobates: I agree to that, as long as I never am the delegate ;)
17:48:42 <dendrobates> agreed
17:49:04 <eday> or the folks assigned can rename their own so it's not just one.. spread the burden. but anyways, not a big deal :)
17:49:41 <dendrobates> it is probably a candidate for a simple script
17:49:56 * jaypipes disagrees for another reason... if I post something on a mailing list referencing the blueprint, and it is renamed because of a release slip, the link is now defunct...
17:50:09 <eday> although I would file this as a LP feature request, since this is redundant info in their system
17:50:46 <dendrobates> eday
17:50:51 <dendrobates> true
17:50:52 <eday> but we can have that discussion later
17:51:06 <dendrobates> Can we do it this release and revisit at the dev summit?
17:51:23 <dendrobates> We can invite the LP devs
17:51:30 <jaypipes> dendrobates: fine by me.
17:51:40 <eday> sounds good
17:51:42 <dendrobates> ok
17:52:11 <dendrobates> so for this release $(release)-feature
17:52:20 <dendrobates> name me as the approver.
17:52:37 <dendrobates> Sept 3 is the deadline
17:52:49 <dendrobates> any last questions.
17:52:57 <jaypipes> nope
17:53:00 <_0x44> None here
17:53:25 <dendrobates> great
17:53:27 <eday> this may be more dev/process, but do we want to use milestones for smaller releases? ie, every two weeks or something?
17:53:52 <eday> (since this relates to blueprints, being a field in them)
17:53:59 <dendrobates> I was thinking of using milestones for release cycle stuff
17:54:45 <dendrobates> such as feature freeze, Beta, and RC
17:55:24 <dendrobates> Let's take this discussion to the mailing list for time sake.
17:55:38 <eday> ok... just thinking if you only get a PPA update/tarball every 3-6 months.. is that often enough?
17:56:28 <dendrobates> I think we should have daily builds, and then a beta, release candidate, ...
17:56:40 <dendrobates> in a 6 mo release we can insert more.
17:56:50 <eday> k
17:57:35 <dendrobates> btw, it has been suggested that we have two more 3 month releases before switching to a 6 month schedule.
17:57:59 <dendrobates> #topic release schedule
17:58:21 <dendrobates> is there anyone who disagrees with that?
17:58:37 <dendrobates> countdown 5
17:58:37 <dendrobates> 4
17:58:38 <dendrobates> 3
17:58:38 <dendrobates> 2
17:58:39 <dendrobates> 1
17:58:41 <dendrobates> done
17:59:24 <dendrobates> we are running out of time let move the remaining topics to the mailing list, except meeting time
17:59:25 <soren> Well..
17:59:34 <dendrobates> too late!!!!!!!! :)
17:59:35 <soren> Does that mean we'll have an extra summit?
17:59:41 <eday> sounds good, and I wouldn't be opposed to keeping 3 month indefinitely :)
17:59:54 <dendrobates> no, the next summit will cover 2  three month releases
17:59:58 <soren> Alright.
18:00:12 <dendrobates> #topic meeting time
18:00:14 <soren> I'd very much like to discuss this meeting time, by the way.
18:00:16 <soren> Oh
18:00:18 <soren> Heh :)
18:00:34 <dendrobates> I want to move it to 3am DK time.
18:00:40 <soren> +1
18:01:00 <eday> soren: because it's friday night, or just any night?
18:01:09 <soren> I've said it many times before. Middle of the night beats the 5-8 pm slot any day.
18:01:13 <dendrobates> so next week I want to keep the day the same, because of the blueprint deadline
18:01:27 <dendrobates> after that we should move to a more reasonable day
18:01:38 <soren> eday: I'd be cool with a couple of hours later if it was a different day.
18:01:41 <dendrobates> but does anyone have a better time suggestion
18:02:05 <soren> eday: Tuesday 1900 UTC?
18:02:09 <soren> Err..
18:02:17 <soren> Not just to eday, obviously :)
18:02:23 <dendrobates> A couple hours later might allow our friends in Asia to patrticipate
18:03:22 <soren> I work late Tuesdays anyway, so that would be ideal for me.
18:03:36 <_0x44> How abotu 1530 or 1600 CDT next friday, then we move to Tuesdays?
18:03:40 <dendrobates> after next week
18:04:20 <dendrobates> great, but I think that is VERY early in Japan, where I know we have people that want to participate
18:04:39 <soren> How long do we expect the meetings to be? If they're capped at 1 hour, 1600 CDT (2100 UTC, right?) is fine.
18:05:27 <soren> ....while we're in DST, at least.
18:05:29 <dendrobates> that is 6am in Japan,
18:05:51 <dendrobates> which is better than this,
18:05:55 <_0x44> So 1900 CDT?
18:06:02 <dendrobates> but 10pm for most of EU
18:06:08 <dendrobates> works for me.
18:06:25 <_0x44> That's really late in the EU though.
18:06:29 <soren> 1600 CDT is 2300 for EU.
18:06:37 <soren> Well, mainland EU.
18:07:22 <ttx> I think there is no time that can fit all. Even USwestcoast + europe is difficult, without considering Japan.
18:07:35 <dendrobates> how about 3 hours forward 20:00 UTC
18:07:55 <dendrobates> http://goo.gl/tdg0
18:08:39 <dendrobates> anyone
18:08:44 <soren> That's fine with me.
18:08:47 <soren> Perfect, even.
18:09:03 <_0x44> 1500 CDT is fine
18:09:06 <dendrobates> any other Europeans want to comment?
18:09:26 <soren> It's outside business hours, but also outside family time. => me happy
18:09:35 <soren> Er... Hang on.
18:09:37 <soren> Which day?
18:09:50 <dendrobates> next week it is friday
18:09:56 <dendrobates> after that we will change it
18:09:59 <soren> Wicked.
18:10:11 <dendrobates> countdown for objections 5
18:10:15 <dendrobates> 4
18:10:18 <dendrobates> 3
18:10:21 <dendrobates> 2
18:10:24 <dendrobates> 1
18:11:34 <dendrobates> #item next release meeting http://goo.gl/WHj2
18:11:47 <dendrobates> We've gone over
18:11:57 <dendrobates> any last items?
18:12:17 <dendrobates> ok, continue discussions on #openstack if you want
18:12:23 <dendrobates> #endmeeting