21:03:23 #startmeeting 21:03:24 Meeting started Tue Nov 29 21:03:23 2011 UTC. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:03:25 Useful Commands: #action #agreed #help #info #idea #link #topic. 21:03:37 Our agenda for today: http://wiki.openstack.org/Meetings/TeamMeeting 21:03:54 Note that we'll discuss the new core repositories for client projects after the project updates, so stay around after your project topic is done... 21:04:04 #topic Actions from previous meeting(s) 21:04:16 * mtaylor devcamcar to discuss and converge to a common view on the need to split repos for horizon (or not) 21:04:24 mtaylor: Did you discuss that yet ? 21:04:52 * Keystone devs to help with bug 891442 21:04:53 Launchpad bug 891442 in horizon "renaming of api_key causes several unhandled exceptions" [Critical,Confirmed] https://launchpad.net/bugs/891442 21:05:10 dolphm: not sure if your help is still needed there ? 21:06:05 ttx: don't believe so 21:06:33 Hmm, let's talk back about it during the horizon topic, hopefully we'll have devcamcar in by then 21:06:39 #topic Keystone status 21:06:43 hi ttx 21:06:49 mtaylor: ah 21:07:10 mtaylor: let's discuss that at the split repo topic 21:07:18 ttx: great 21:07:19 #link https://launchpad.net/keystone/+milestone/essex-2 21:07:28 dolphm: is the status on there current ? 21:07:38 keystone updates -- we're focusing mostly on open bugs (yay!), doc improvements (yay!) and finally paying more attention to integration efforts 21:08:07 ttx: here 21:08:18 ttx: yes, those statii (-es? lol) look accurate? 21:08:31 So service-endpoint-location endpoint-identifiers are not started yet ? 21:09:17 I'm not aware of any code published for locations, and we're still discussing endpoint identifiers 21:09:25 (Remember the E2 changes need to be proposed and merged by December 13.) 21:09:39 Looking at the general essex roadmap, there is a blueprint without a milestone target: 21:09:44 https://blueprints.launchpad.net/keystone/+spec/keystone-domains 21:09:50 dolphm: Should that be targeted to essex-3 ? 21:10:14 (since that's you last feature milestone, iirc) 21:10:37 ttx: endpoint-identifiers probably should be... in exchange, we may be addressing https://blueprints.launchpad.net/keystone/+spec/portable-identifiers sooner rather than later 21:10:45 (as the endpoint-identifiers mentions) 21:11:38 dolphm: should keystone-domains be targeted to E3 ? 21:12:13 or you don't know when is HP committed to it ? 21:12:18 ttx: (hi) - that's a HP question 21:12:40 yeah, i don't have any visibility on keystone-domains myself 21:12:49 ok, will try to break the bug IRC wall and get more status updates 21:12:53 big* 21:12:59 dolphm: Anything else ? 21:13:11 also I'm wondering if https://blueprints.launchpad.net/keystone/+spec/endpoint-identifiers and https://blueprints.launchpad.net/keystone/+spec/portable-identifiers can be merged 21:13:39 jsavak: noted 21:13:43 In other news, we cut a 2011.3.1 "Diablo+" tarball last week: 21:13:48 https://launchpad.net/keystone/diablo/2011.3.1 21:13:54 Questions for Keystone ? 21:14:05 yes, i have an open question for keystone consumers / CI peeps -- we'd like to directly support a CI effort in the long run... is openstack-integration-tests the best place to do that? 21:14:48 dolphm: yep 21:15:07 dolphm: it's handled the same as all core projects... gerrit-ified and all. 21:15:16 is it the *only* such effort we should support? 21:15:26 #info keystone updates -- we're focusing mostly on open bugs (yay!), doc improvements (yay!) and finally paying more attention to integration efforts 21:15:31 dolphm: yes. 21:15:46 cool -- will do 21:15:47 dolphm: or rather, the only one that the QA team is focusing on. 21:15:54 fair enough 21:15:56 Other questions for Keystone ? 21:16:00 dolphm: awesome, thx 21:16:04 i'll be joining those meetings then 21:16:21 #topic Swift status 21:16:25 notmyname: o/ 21:16:28 hi 21:16:53 swift 1.4.4 was released last thursday 21:17:01 #info swift 1.4.4 was released last thursday 21:17:04 we recommend you upgrade 21:17:10 notmyname: do you agree that the next version will be called 1.4.5 ? 21:17:26 drumroll 21:17:28 ttx: I have no reason to think otherwise right now 21:17:35 No ETA yet, I suspect ? 21:17:44 ttx: of course, that can quickly get in to other topics :-) 21:17:53 #action ttx to create swift/1.4.5 milestone, no ETA yet 21:17:55 no ETA for the next version of swift yet 21:18:03 notmyname: Anything else ? 21:18:15 I'm currently working on getting better visibility into progress and tasks and such 21:18:35 I'l be in the bay area next week. come to the meetup to talk swift 21:18:48 Questions on Swift ? 21:18:58 notmyname, visibility into progress? can you elaborate? 21:19:22 reed: better coordination with internal project management tools and expternal, openstack ones. 21:19:31 cool. thanks 21:19:34 reed: and better visibility on what's being worked on and planned 21:20:00 reed: so it's easier to coordinate between companies 21:20:21 #topic Glance status 21:20:24 #info I'm currently working on getting better visibility into progress and tasks and such [to the community] 21:20:28 jaypipes: yo 21:20:33 ttx: oy 21:20:36 #link https://launchpad.net/glance/+milestone/essex-2 21:20:44 Progress on features looks good... 21:21:08 ttx: meh. got a bunch of reviews currently in progress. 21:21:17 Looking at the general essex plan at: https://blueprints.launchpad.net/glance/essex 21:21:27 You still have glance-xml and gzip-compression in plan, with no milestone... 21:21:33 ttx: ran into a bunch of issues with our Keystone functional tests that required fixes to Keystone. 21:21:40 jaypipes: Should I unset the series goal for them ? Or do you have someone committed to do them ? 21:21:55 ttx: you can unset those. sorry for not doing that earlier. 21:21:59 willdo 21:22:16 #action ttx to unset glance-xml and gzip-compression 21:22:27 jaypipes: "required", so it's ok now ? 21:22:45 jaypipes: thanks for those :) 21:22:46 * ttx likes the dependency tree at https://blueprints.launchpad.net/glance/+spec/api-2 21:23:07 jaypipes: feeling confident that this tree can all be completed in E3 ? 21:23:20 dolphm: yeah, no worries. mostly just version skew. 21:23:31 (Lots of small blueprints, I suspect) 21:23:58 ttx: no, it's going to be tough. I've been trying to get the third version of the 2.0 API proposal done. 90% there. 21:24:07 ttx: everything depends on signoff on the 2.0 proposal. 21:24:41 my bad 21:24:46 jaypipes: so it may overflow on E4 ? 21:25:17 ttx: perhaps, yes. 21:25:22 ok 21:25:24 glenc: not your fault. 21:25:27 jaypipes: Anything else ? 21:25:45 ttx: no, not right now. thx. 21:25:46 jaypipes: but I do have some stuff I need to run by you - I'll contact you tomorrow 21:25:53 glenc: cool. 21:26:24 Questions on Glance ? 21:26:50 #topic Nova status 21:26:54 vishy: yo 21:27:01 #link https://launchpad.net/nova/+milestone/essex-2 21:27:07 hi 21:27:10 Progress looks good in general 21:27:19 yes we need some reviews 21:27:30 Right, two essential blueprints look blocked in review: 21:27:37 nova-vm-state-management -> https://review.openstack.org/#change,1695 21:27:41 nova-volume-snapshot-backup-api -> https://review.openstack.org/#change,1202 21:27:48 the first is the big one 21:27:58 the second we are waiting on updates from the author 21:28:11 * vishy wishes we had a WIP flag 21:28:24 mtaylor: ^ :) 21:28:45 the other stuff seems to be implemented/on track 21:28:53 vishy: yes! it's on the CI roadmap with high priority 21:28:58 vishy: on the general Essex plan, are you making progress with the subteams ? 21:29:08 Or do you need help in getting feedback from them ? 21:29:18 vishy: I will have the blueprint about it done today 21:29:34 titan team. Anyone know how much more uuid related changes are needed? 21:29:39 * many 21:29:50 ttx: I haven't received any feedback 21:29:51 coming to a close, very close to being done 21:30:16 bcwaldon: next round don't need as many changes? 21:30:21 vishy: would going to thei 21:30:24 and not much is targeted to e-3 yet 21:30:29 r team meeting help ? 21:30:30 we're up around 40 branches at this point already in, with a few more left to do 21:30:37 westmaas: correct 21:30:42 vishy: or they don't have any ? 21:30:43 so maybe i should start threatening violence 21:30:58 if violence means "less features" i'm all for it 21:31:06 I've been attending meetings as I can 21:31:19 I just want the features actually targetted 21:31:24 I'm concerned about disk-configuration-parity (feature parity team / sleepsonthefloor) 21:31:25 and assigned 21:31:38 vishy: is the uuid story a problem? 21:31:42 and separate-nova-volumeapi (Nova API team, bcwaldon) 21:31:46 westmaas: no 21:31:47 s/story/bp/ 21:31:49 ok 21:31:51 I'm not sure it's going to scale to have the PTL to attend other's team meetings.. 21:32:02 soren: cloning? 21:32:16 vishy: Clones still need to grow up. PEople always forget that. 21:32:38 soren: well I would appreciate general updates occasionally 21:32:52 soren: but mostly if the subteam leads just stay on top of their blueprints 21:32:57 that would probably be enough 21:33:01 It should be. 21:33:04 That's my point :) 21:33:15 ttx: what is your concern about those two? 21:33:34 vishy: they are marked essential, so I suppose they are extra-important for you 21:33:55 and they won't happen if nobody is committed to work on them 21:34:00 they are 21:34:10 didn't they figure out how to accelerate the growth rate of clones 21:34:19 which means I will probably have to do them myself! 21:34:21 :) 21:34:51 vishy: if teams don't produce anything and don't report up, they should be disbanded. Having them becomes a distraction 21:35:05 ttx: true 21:35:06 or new leaders appointed. 21:35:16 ttx: know there are things going on 21:35:20 Vek: depends if the problem is leadership or membership 21:35:30 point. 21:35:30 ttx: they just haven't congealed into specific tasks 21:35:39 vishy: ok, will talk to you about that this week 21:35:51 ttx: cool. Open to suggestions 21:36:03 maybe we need a mandatory team-lead meeting? 21:36:03 #action ttx and vishy to discuss how to solve Nova's team structure 21:36:13 In other news, https://blueprints.launchpad.net/nova/+spec/consolidate-testing-infrastructure is in the plan, without a milestone set 21:36:14 vishy: that seems like a good idea 21:36:19 soren, oubiwann: do you have a target milestone for that ? 21:36:35 ttx: When's the next milestone again? 21:36:38 E2 21:36:42 Dec 15 21:36:43 "when" 21:36:46 soren: ah yes I pinged you about that yesterday. 21:36:56 vishy: Yeah. I suck. I know :) 21:36:59 soren: i wanted to make sure you thought it was correct before I approved it 21:37:14 although apparently i already accepted for essex :) 21:37:19 vishy: could you approve/set prio ? 21:37:21 Yes, I saw that too :) 21:37:24 I think E2 is doable. 21:37:34 soren: no qualms with approving it? 21:37:40 vishy: soren is in drivers so it's auto-approved to Essex 21:37:46 * soren smells a trick questino 21:37:48 oh! 21:37:49 question, even. 21:37:57 ttx: I didn't touch it! 21:38:00 vishy: he is supposed to know what he is doing 21:38:11 soren: no, just wanted to make sure it fits in with your testing refactor 21:38:15 you didn't set the series goal to essex ? 21:38:22 I think it must have been vishy. It was approved when I first went and looked. 21:38:30 heh 21:38:37 i might have done it 21:38:40 vishy: Anything else ? 21:38:41 Anyways. 21:38:49 yes I want to talk about ppas 21:38:55 Yes, I think it definitely falls within the testing refactor. 21:38:58 but I don't know if i should save that until the end. 21:39:15 #action vishy to set E2/prio/approval on consolidate-testing-infrastructure 21:39:29 vishy: save it, if it's general 21:39:47 Questions on Nova ? 21:39:51 vishy: ping me when you start talking about that 21:40:04 devcamcar: around now ? 21:40:51 skipping Horizon, we'll be back if devcamcar or someone else shows up to represent Horizon 21:40:57 #topic Status on new core repositories 21:41:09 So, for E2 we are introducing new repositories for several core projects 21:41:20 For Nova for example we are adding novaclient as an additional release deliverable 21:41:34 I'd like to go over the list and get status, see if we are on track for that for E2 21:41:47 mtaylor: For Nova, we have novaclient being added -- how is that going so far ? 21:42:22 ttx: novaclient is in and good to go 21:42:29 Do we have tarball CI jobs up yet ? 21:42:34 or just the repo ? 21:42:34 ttx: it's gerrit-ified and cutting tarballs 21:42:39 ok 21:42:51 We'll probably need milestone-proposed jobs 21:42:55 I'll check that 21:43:15 For Horizon, there was a proposal to split the django lib and the reference implementation, where are we with that ? 21:43:25 we are not doing that at the moment 21:43:32 there are workflow issues that need to be solved 21:43:39 #action ttx to check the need for MP jenkins jobs on novaclient 21:43:48 I have a todo list item to present devcamcar with some options of how it could work 21:43:54 mtaylor: so we keep a single tarball for e2 ? 21:44:03 ttx: yes. 21:44:23 mtaylor: ok, but it would be good to have the final form by E3 21:44:33 ttx: ok. noted 21:44:37 whatever that is 21:44:41 ++ 21:44:45 mtaylor: Do we need client splits for other projects (Keystone, Swift, Glance) ? 21:44:47 we need to pull python-keystoneclient in to the fold, split out quantum client and glance client, and I think we'll be in good shape 21:45:14 those are still TODOs, right ? 21:45:14 Yes. Would like to do that for Keystone. 21:45:38 mtaylor: we should get Melange set up right from the start 21:45:38 mtaylor: but on track for E2 ? 21:45:43 zns: is the 4P repo the one we should work on bringing in? 21:45:45 troytoman: ++ 21:45:50 ttx: glance is not 21:46:05 ttx: I think we can get quantum, keystone and melange on track by E2 21:46:13 mtaylor: that's a good start. I've added Keystone code to novaclient, but we can start with 4P. 21:46:14 glance is... done ? or not on track ? 21:46:40 zns: cool. I'll try to arrange 21:47:00 ttx: glance client is a little bit more integrated into glance, I need to chat with jaypipes about splitting strategy 21:47:00 glance client is still tightly attached to glance, afaik 21:47:16 mtaylor: ok, let's keep horizon and glance for E3 then 21:47:22 mtaylor: anything needed on swift side ? 21:47:50 ttx: I think similar to glance- notmyname said it's doable, but not on the immediate todo list 21:48:04 ok 21:48:13 step one, make a client library 21:48:27 any other remark on that topic ? 21:48:58 #topic Incubated projects and other Team reports 21:49:04 danwent, troytoman: o/ 21:49:15 i'll let troy go first :P 21:49:22 Anything interesting in Melange and Quantum land ? 21:49:31 we plan to have Melange moved into gerrit tomorrow afternoon 21:49:53 otherwise, cleaning up docs and other items to make it more accessible 21:49:54 related to the cli extraction I've been talking to various folks about how to make the CLI tools work the same way - http://wiki.openstack.org/CLIAuth 21:50:18 #info we plan to have Melange moved into gerrit tomorrow afternoon 21:50:26 #info related to the cli extraction I've been talking to various folks about how to make the CLI tools work the same way - http://wiki.openstack.org/CLIAuth 21:50:33 * Vek wonders whatever happened to his blueprint about auth 21:51:02 not much else to report at this point 21:51:04 (because getting auth to work the same way across all the tools was part of my goal when I wrote that up...) 21:51:08 for quantum, we are trimming essex-2 a bit: https://launchpad.net/quantum/+milestone/essex-2 21:51:21 main code changes for quantum that need to get into nova are already under review. 21:51:26 danwent: looks more reasonable :) 21:51:36 mtaylor: let's chat about quantum client lib offline 21:51:42 or you can come to netstack meeting next 21:51:50 Any other team lead with a status report ? 21:51:52 Vek: link? 21:51:58 Vek: been heavily focused on Keystone itself and middleware testing. Not much on the client yet. 21:52:05 and a heads up to the horizon folks, we'll probably be pinging you about some quantum related changes this week. can target either e2 or e3 21:52:08 danwent: yes! I've been meaning to find you to chat about that - yours is actually probably one of the easiest to deal with :) 21:52:17 Docs team working on a blueprint for API reference pages… see http://heckj.github.com/api-site-mock/# for a mockup. 21:52:26 anotherjesse: looking up now. 21:52:30 #info Docs team working on a blueprint for API reference pages… see http://heckj.github.com/api-site-mock/# for a mockup. 21:52:42 annegentle: looks nice 21:52:45 anotherjesse: http://wiki.openstack.org/ClientAuthenticationPlugin 21:52:49 troytoman: danwent: can you guys put some current status info for quantum and melange on http://etherpad.openstack.org/nova-network-team 21:53:16 I want one more level of navigation added, but as a wireframe it's going to be useful. 21:53:17 devcamcar: still not around ? 21:53:29 annegentle: very cool! 21:53:38 tr3buchet: I assume this is limited to quantum changes affecting nova, not quantum changes in general? 21:53:52 We experimenting with WADL as source for this output. 21:54:02 annegentle: how is this being built? 21:54:24 thanks ^^ 21:54:24 dolphm: this is a wireframe made with copy/paste for review :) the actual building will be based on the reqs gathered. 21:54:31 danwent: yes correct 21:54:39 OK, switching to open discussion, as we have a few things to discuss there 21:54:43 #topic Open discussion 21:54:44 danwent: i assume you have plenty of etherpads floating around for the rest 21:54:50 vishy: you wanted to mention PPAs ? 21:54:53 tre3buchet: indeed. sounds like a plan 21:54:59 awesome 21:55:07 dolphm: <<"Status" is a male noun of the Fourth Declension in Latin, and as such the plural is "status", spelled identically>> 21:55:22 yes 21:55:26 Vek: that seems like it would make doing the what the CLI Auth page is talking about easier. the cli auth page is talking about what the interface for users is, whereas the CAP page is about how you would then implement it 21:55:34 vishy: go for it 21:55:35 psh, i studied latin, i'll stick with statii 21:55:38 in my mind we have a big problem with our ppa 21:55:46 and we need to fix it 21:55:53 which ppa ? 21:55:55 *nod* 21:55:57 we are still providing a release ppa 21:56:00 and it is broken 21:56:03 ttx: second declension 21:56:10 https://en.wiktionary.org/wiki/status#Latin 21:56:17 i would like to replace all of our ppas 21:56:24 with a stable ppa 21:56:31 mtaylor: ping 21:56:39 * mtaylor agrees with vishy 21:56:41 * annegentle cheers 21:56:51 i don't want to have people installing a bunch of stuff that doesn't work 21:56:59 having a ppa up there with broken packages isn't doing anybody any favors 21:57:00 vishy: I agree we should remove the release PPA. But.. 21:57:04 and currently there is no option for people running on lucid 21:57:16 I don't want to have people installing a bunch of stuff nobody actually maintains 21:57:27 ttx: well we already have that :) 21:57:32 I think that we have people maintaining stable/diablo now 21:57:51 reed: that shows statii (stat-longI), right? 21:57:52 and that is at least more maintained than the current diablo packages in openstack-release 21:57:53 we might as well give them something that is a best effort at working rather than something that is totally broken 21:58:04 we are going to be releasing a stable/diablo we just have to get through some bureacracy 21:58:12 vishy, how about doing releases from stable/diablo and pushing ppas of those? 21:58:13 zul: for lucid? 21:58:17 right, what zul said 21:58:19 mtaylor: oneiric 21:58:21 mtaylor: my point is that they maintain a branch for backports... not necessarily something that is supposed to be run in production 21:58:22 right. 21:58:24 Tu es adhuc bene litteratus, sed fallitur. 21:58:26 vishy, rather than e.g. nightly builds of stable/diablo 21:58:34 dolphm, not for the noun 21:58:40 markmc: I'm ok with that 21:58:43 reed: just noticed that :P 21:58:58 and we might have a ppa that has a weekly snapshot of stable/diablo soon as well 21:58:59 markmc: mainly i just want to give people an option who aren't running on oneiric 21:59:14 yeah. that's the important bit. 21:59:15 so we will be testing stable/diablo for oneiric 21:59:20 ttx, any release from stable/diablo should be as production ready as 2011.3 21:59:34 * dolphm happily ignored latin conjugation in highschool 21:59:36 zul: is it possible to have a stable/diablo for lucid? 21:59:39 ttx, or put it this way, we wouldn't release from stable/diablo until we were confident of it being production ready 21:59:58 markmc, ttx: any release would be better than 2011.3 :) 22:00:02 and natty? 22:00:03 * Vek 's high school did not have latin, or in fact most other foreign languages... 22:00:05 vishy: i dont know.. 22:00:23 markmc: I still think it's "less good" than something the distros would provide. 22:00:28 we already have all of the infrastructure (backports etc.) in place for a lucid ppa 22:00:35 ttx: distros don't provide for pre-oneiric 22:00:35 compare stable/diablo and the current SRUs on Oneiric 22:00:39 ttx, oh, I agree with that 22:00:41 it just needs the nova code to be updated. 22:00:59 ttx, it's less bad than 2011.3 from upstream, too though 22:01:06 markmc: so if it ends up being "better but not good enough for production", I'd rather just scrap them 22:01:12 if that means a 2011.3.1 release that is fine? 22:01:42 ttx, well - 2011.3.x releases would be useful IMHO 22:01:51 until someone maintains a true distribution of openstack for old stable versions of distros 22:01:59 ttx, if release PPAs are useful at all, then a release PPA of 2011.3.x would be useful too 22:02:15 * dolphm tried unsuccessfully to sign up for Canadian 22:02:18 I think we should cut packages from 2011.3.1 and upload them to the release ppa. whatever we do for essex, the diablo release exists and people are trying to sue it 22:02:19 use it 22:02:33 this all needs a discussion. I'll explain why I think this is a bad idea 22:02:53 but that would probably delay the net guys by a few hours 22:02:55 ttx, perhaps separate out doing 2011.3.x releases from the usefulness of release PPAs 22:03:02 a bad idea for keystone, or for every project? 22:03:17 A bad idea for openstack itself as an upstreal 22:03:18 m 22:03:39 which one is a bad idea? 2011.3.x releases or release PPAs? 22:03:39 if I can't get by in on updating the ppa 22:03:45 i think we need to delete it 22:03:48 and someone else can make one 22:03:55 so far we had a model where we put out releases and downstreams make them production-ready and updateable 22:04:01 but there is a lot of backporting effort that will be hard to redo 22:04:03 vishy, e.g. Kiall :) 22:04:04 vishy: that already happened ;) 22:04:13 ttx: I do not believe that model has worked 22:04:26 #action ttx or vishy to start a discussion on release PPA 22:04:49 Kiall: you have a lucid ready version of stable/diablo? 22:04:51 mtaylor: I think we'll just end up spreading our resourecs and lower end quality as a result 22:05:04 but let's close this meeting and let the netstack guys in 22:05:10 vishy: nope.. I havent done any bar oneiric 22:05:10 ttx, which one is a bad idea? 2011.3.x releases or release PPAs? or both? 22:05:12 kool 22:05:33 ttx: I think that it's clear people want this ppa. at the moment, Kiall is maintaining one. and I'd really love to avoid the sentence: 22:05:48 "the openstack release ppa is broken, please see this person's ppa for working packages" 22:05:55 If there is a need, a company should make a distro around it 22:06:01 mtaylor, indeed 22:06:18 no 22:06:20 I disagree ttx 22:06:27 better none than a broken one 22:06:29 this is theoretically a community project 22:06:30 why is the https://launchpad.net/~nova-core/+archive/trunk nova 2 weeks old also? 22:06:37 mtaylor: even I agree there... People use my PPA doesnt look good for ubuntu or openstack... 22:06:37 there is community making pacakges 22:06:46 how about we actually embrace that 22:06:57 mtaylor: we should have that discussion on the ML 22:07:02 instead of deferring to theoretical companies who do not exist 22:07:02 and close this meeting. 22:07:06 yes, this is ml material 22:07:09 #endmeeting