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