Tuesday, 2011-10-25

*** bencherian has joined #openstack-meeting00:01
*** zul has joined #openstack-meeting00:04
*** bencherian has quit IRC00:17
*** dendro-afk is now known as dendrobates00:22
*** adjohn has joined #openstack-meeting00:32
*** medberry is now known as med_out00:38
*** vladimir3p has quit IRC00:39
*** dragondm has quit IRC00:56
*** dendrobates is now known as dendro-afk01:07
*** ohnoimdead has quit IRC01:15
*** jakedahn_ has quit IRC01:21
*** adjohn has quit IRC01:58
*** mdomsch has quit IRC02:06
*** vladimir3p has joined #openstack-meeting02:13
*** dendro-afk is now known as dendrobates02:20
*** vladimir3p has quit IRC02:42
*** med_out is now known as medberry02:55
*** pvo has quit IRC02:56
*** pvo has joined #openstack-meeting03:00
*** novas0x2a|laptop has quit IRC03:02
*** medberry is now known as med_out03:04
*** bmcconne_ has quit IRC03:27
*** bmcconne has joined #openstack-meeting03:27
*** Arminder has left #openstack-meeting03:51
*** bencherian has joined #openstack-meeting05:01
*** reed has quit IRC05:11
*** chmouel has quit IRC05:16
*** jkoelker has quit IRC05:20
*** bencherian has quit IRC05:29
*** vladimir3p has joined #openstack-meeting05:35
*** vladimir3p has quit IRC05:40
*** chmouel has joined #openstack-meeting06:31
*** mmetheny_ has joined #openstack-meeting07:12
*** mmetheny has quit IRC07:12
*** mmetheny_ is now known as mmetheny07:12
*** shang has quit IRC07:23
*** shang has joined #openstack-meeting07:43
*** darraghb has joined #openstack-meeting08:50
*** jsavak has joined #openstack-meeting09:19
*** jsavak has quit IRC09:24
*** joesavak has joined #openstack-meeting09:24
*** joesavak has quit IRC10:12
*** shang has quit IRC10:51
*** shang has joined #openstack-meeting10:56
*** dprince has joined #openstack-meeting12:02
*** mdomsch has joined #openstack-meeting12:10
*** jsavak has joined #openstack-meeting12:10
*** blakeyeager has joined #openstack-meeting12:59
*** med_out is now known as medberry13:08
*** Binbin has joined #openstack-meeting13:24
*** joesavak has joined #openstack-meeting13:32
*** jsavak has quit IRC13:32
*** mdomsch has quit IRC13:36
*** martines has quit IRC14:05
*** sleepsonthefloor has quit IRC14:06
*** sleepsonthefloor has joined #openstack-meeting14:06
*** vishy has quit IRC14:06
*** vishy has joined #openstack-meeting14:07
*** dprince has quit IRC14:33
*** vladimir3p has joined #openstack-meeting14:35
*** bencherian has joined #openstack-meeting14:39
*** dprince has joined #openstack-meeting14:42
*** Binbin has quit IRC14:43
*** dragondm has joined #openstack-meeting14:54
*** adjohn has joined #openstack-meeting15:00
*** rnirmal has joined #openstack-meeting15:01
*** reed has joined #openstack-meeting15:19
*** adjohn has quit IRC15:23
*** bencherian has quit IRC15:31
*** DuncanT has quit IRC15:34
*** cp16net has joined #openstack-meeting15:42
*** martines has joined #openstack-meeting16:05
*** martines_ has joined #openstack-meeting16:08
*** blamar has joined #openstack-meeting16:15
*** bengrue has quit IRC16:15
*** mdomsch has joined #openstack-meeting16:16
*** adjohn has joined #openstack-meeting16:24
*** dprince has quit IRC16:39
*** blamar has quit IRC16:40
*** blamar has joined #openstack-meeting16:41
*** bhall has quit IRC16:41
*** dprince has joined #openstack-meeting16:41
*** bhall has joined #openstack-meeting16:41
*** ohnoimdead has joined #openstack-meeting16:51
*** carlp has quit IRC16:53
*** carlp has joined #openstack-meeting16:54
*** dendrobates is now known as dendro-afk17:01
*** _adjohn has joined #openstack-meeting17:08
*** adjohn has quit IRC17:09
*** _adjohn is now known as adjohn17:09
*** heckj has joined #openstack-meeting17:12
*** adjohn has quit IRC17:17
*** adjohn has joined #openstack-meeting17:17
*** adjohn has quit IRC17:22
*** bengrue has joined #openstack-meeting17:25
*** adjohn has joined #openstack-meeting17:26
*** ohnoimdead_ has joined #openstack-meeting17:29
*** ohnoimdead has quit IRC17:29
*** ohnoimdead_ is now known as ohnoimdead17:29
*** adjohn has quit IRC17:32
*** adjohn has joined #openstack-meeting17:33
*** novas0x2a|laptop has joined #openstack-meeting17:36
*** adjohn has quit IRC17:39
*** adjohn has joined #openstack-meeting17:42
*** adjohn has quit IRC17:51
*** heckj has quit IRC17:51
*** blamar has quit IRC17:53
*** hisaharu has joined #openstack-meeting17:53
*** adjohn has joined #openstack-meeting17:54
*** anotherjesse has joined #openstack-meeting17:56
*** heckj has joined #openstack-meeting17:56
*** blamar has joined #openstack-meeting17:58
*** adjohn has quit IRC17:58
heckjo/ for keystone meeting17:58
joesavak#startmeeting Keystone Team Meeting17:59
openstackMeeting started Tue Oct 25 17:59:08 2011 UTC.  The chair is joesavak. Information about MeetBot at http://wiki.debian.org/MeetBot.17:59
openstackUseful Commands: #action #agreed #help #info #idea #link #topic.17:59
*** openstack changes topic to " (Meeting topic: Keystone Team Meeting)"17:59
joesavak#topic Roadmap for Essex - status on blueprints17:59
*** openstack changes topic to "Roadmap for Essex - status on blueprints (Meeting topic: Keystone Team Meeting)"17:59
joesavakAgenda is located at http://wiki.openstack.org/Meetings/KeystoneMeeting17:59
joesavakwelcome y'all. Who is here?17:59
heckjme :-)18:00
joesavakhi joseph!18:00
joesavaki'll give it a couple more mins18:00
joesavakhi jesse18:01
joesavakok - blueprints. Joseph - i saw you contributed a lot of doc for https://blueprints.launchpad.net/keystone/+spec/keystone-documentation18:01
heckjAnd another pull request to finish that out: https://review.openstack.org/#change,108918:01
heckjI was hoping for feedback from the keystone team, never got anything other than "merge it", so I'm assuming I'm not lying anywhere. Wasn't 100% sure though :-)18:02
joesavakok - i'll review that but will need a 2nd. Jesse, can you review too?18:02
*** adjohn has joined #openstack-meeting18:02
joesavakJoseph - i'll take a look. The keystone team (dolph & yogi) have been pretty busy recently.18:02
heckjthe original was what needed reviewing - and I have some questions I wanted to ask when appropriate - things that didn't make much sense while I was trying to document the work18:03
joesavakok. Feel free to send those questions to the mailing list18:03
heckjOk - will do18:04
anotherjessejoesavak: not to beat a dead horse but I am really confused about how to review doc changes18:04
*** jakedahn has joined #openstack-meeting18:04
anotherjesseif this is going to run against diablo components (eg, e0 is for diablo+) or is this for essex?18:04
anotherjessewhat is it documenting, what is the protocol, ...18:04
joesavakjoseph, you were doing this for diablo, right?18:05
heckjI was writing those to catch it up - I'm presuming we're documenting whatever is in trunk, since the (developer) docs get branched with the code.18:05
anotherjesseya - the merges are against master18:05
anotherjessemaster is currently 45 commits different than stable/diablo18:05
heckjI honestly don't know if it's entirely accurate for trunk - hence the desire for someone who intimately knows Keystone to give a looksee.18:05
anotherjesseis master supposed to become e0 and e0 becomes what we recommend instead of stable/diablo?18:05
*** zns has joined #openstack-meeting18:05
anotherjessezns: maybe you know: is master supposed to become e0 and e0 becomes what we recommend instead of stable/diablo?18:06
joesavake0 will probably not exist due to timeframes. In talking with Yogi, I think we're shooting for e118:06
*** adjohn has quit IRC18:07
anotherjessefor people wanting to run diablo do will we recommend stable/diablo even once e1 exists then?18:07
*** jdag has joined #openstack-meeting18:07
znsIf master has only bug fixes and is stable by e0 then we should propose it as a backport for Diablo. My understanding is that it does not contain new functionality. Same API. Same schema. Thoughts?18:07
anotherjessehttps://github.com/openstack/keystone/compare/stable%2Fdiablo...master <- we are at +2743 -1372 lines already -- many docs :) but ...18:07
joesavakprobably. It depends if the customer was affected by a bug that'll be fixed in e-118:07
anotherjessewe have already changed schema18:07
anotherjessein master18:08
*** adjohn has joined #openstack-meeting18:09
joesavakis the removing of the default tenant id the only schema change? (https://review.openstack.org/#change,1068)18:09
sleepsonthefloorthere is a table rename as well18:10
joesavakif so, then maybe this is more suited for essex and not a diablo back-port18:10
anotherjessezns: so your goal is that all of18:10
anotherjessehttps://github.com/openstack/keystone/compare/stable%2Fdiablo...master + whatever else happens up to e0 or e1 becomes the new stable/diablo?18:11
joesavak#topic Essex e-0 release possibility18:12
*** openstack changes topic to "Essex e-0 release possibility (Meeting topic: Keystone Team Meeting)"18:12
anotherjesseI just need to know what the plans / goals are for diablo - as our team hasn't been able to switch to helping with essex due to working on keystone integration still18:12
joesavakthere are 2 paths that I see: 1 - leave stable diablo as it is and focus on e1 release that will not backport to diablo18:13
anotherjesseperhaps it is more:18:13
joesavak2 - rush to get e-0 done quickly which is the bugs & doc for diablo then back-port it to stable-diablo, then focus on e118:13
anotherjesse1) have a stable/diablo that has cherrypicked backports to fix specific issues - rather than just taking master18:14
joesavakJesse - what is your preference and why?18:14
anotherjesseunfortunately we are kinda damned either way - since cherrypicking backports from master to stable/diablo is hard due to commits not being atomic - we18:15
anotherjesse've spent time trying to identify them but end up having to rewrite since the commits aren't logically separated18:15
anotherjesseand we don't have tags on bugs / commits to say it should be backported18:16
anotherjesseignoring implementation - thinking only of the api (contracts) in stable/diablo18:16
anotherjessedo we know what the issues that would need to be addressed for your team to feel happy doing a release?18:16
anotherjessestable/diablo release that is18:16
joesavakignoring impl, i think it's good. The doc updates just need to be verified and merged18:17
joesavakbut then people will try to get it to work and see that the impl is missing for calls or broken on others18:17
anotherjessezns: or why do you feel that we should switch to e0 / e1?18:18
anotherjesseI know jaypipes et al are still working on integration with keystone as it exists now - but he can speak more to that18:19
anotherjesseI just think we need to have a target that lets us finish diablo - and I can't find a document / bug list / blueprint / … that says what that is18:19
joesavakok. I'll get jay's opinion too. I'm leaning to just e-1 with no backporting though18:19
*** adjohn has quit IRC18:20
anotherjessesomething like https://bugs.launchpad.net/nova/+bugs?field.tag=diablo-backport18:20
joesavakok - i'll create a bug so there's more visibility18:20
joesavakgood catch18:20
heckjsomewhat related, I'd really like to see the keystone team at least doing peer reviews - I'm still seeing checkins from someone being self-approved18:21
joesavakanything else on e-0? Right now: no e-0 and i'll talk to Jay Pipes18:21
joesavakjoseph - i agree. I'll bring that up18:21
anotherjessepushing through commits in a day by the author minimizes the chance of peer review18:22
joesavakyup. I think these are symptomatic of the keystone growing pains.18:22
joesavakback to blueprints -18:23
joesavak#topic Roadmap for Essex - status on blueprints18:23
*** openstack changes topic to "Roadmap for Essex - status on blueprints (Meeting topic: Keystone Team Meeting)"18:23
joesavakthere is an RBAC blueprint we are drafting and are planning to do an RBAC prototype for e-118:23
*** adjohn has joined #openstack-meeting18:23
joesavakthat blueprint is here: https://blueprints.launchpad.net/keystone/+spec/rbac-keystone18:23
joesavakand the full specification has proposed API changes. RBAC will be developed as a Keystone Extension18:24
joesavakAny feedback on this will be helpful. I'll schedule a time for a review as well probably for the next meeting.18:25
heckjI'll make sure to pass it around the folks working on dash here in Seattle18:25
joesavakHP is working on 2-way SSL (https://blueprints.launchpad.net/keystone/+spec/2-way-ssl) and keystone domains right now (https://blueprints.launchpad.net/keystone/+spec/keystone-domains)18:26
joesavakjoseph - thanks!18:26
anotherjessejoesavak: can we get an estimated on when the decision on what is the plan for keystone in diablo?  after talking with jay/...18:26
anotherjesseI need to set expectations for our team and people who are deploying diablo18:26
anotherjesseseems like it is really a ptl question but zns doesn't appear to be here18:27
joesavakanotherjesse: let me talk it over with zns. My thoughts is that e-1 with no backporting will be decided18:27
joesavakso by COB tomorrow?18:27
joesavak#topic Open bugs18:28
*** openstack changes topic to "Open bugs (Meeting topic: Keystone Team Meeting)"18:28
anotherjessek - i have questions about the rbac but don't really have time to think about it until diablo is done18:28
joesavakYogi has been working on bug fixes against trunk. He's focusing on the high and critical ones18:28
joesavakJesse - we will start work on the prototype next week - FYI18:28
heckjI'm working on the doc bug - and I think I've identified more, but wasn't sure  - will be asking questions about the functionality on the mailing list18:29
*** adjohn has quit IRC18:29
anotherjessejoesavak: does high and critical mean by the importance in launchpad?18:29
joesavakjoseph: thanks18:29
joesavakjesse: yes18:29
*** dendro-afk is now known as dendrobates18:29
*** adjohn has joined #openstack-meeting18:29
joesavakif there are any bugs you feel should be addressed soon, let me know.18:30
anotherjessejoesavak: there are lots of bugs with "undecided" importance with "fix commited" - seems like a weird state for so many bugs to be in18:30
joesavakyeah. Triage has been an issue and we're working on that too.18:30
joesavakMany of them are old or may have been fixed already. Yogi is going through as he's fixing to update the bugs where appropriate18:31
joesavakIf you own any of these bugs and see that the importance is missing or not what you'd expect - let me know that too.18:31
joesavak#topic Open Discussion18:32
*** openstack changes topic to "Open Discussion (Meeting topic: Keystone Team Meeting)"18:32
joesavakOk - what questions do y'all have?18:32
anotherjesseI really feel like we have lots of technical debt we need to fix - things like processes and bugs and docs18:32
anotherjessebefore spending too much time on new stuff18:32
anotherjessefeels like adding on top of a shaky foundation18:32
joesavakjesse: i agree. It's difficult for keystone since it is really part of essex core (not diablo), was forced to grow up quick, and has really only 2 contributing devs on it.18:33
anotherjessejoesavak: any chance you can have your developers slow down, take a deep breath and approach things with a slow and steady wins the race attitude?18:34
anotherjessenot trying to push e0 / e1 out with lots of additions18:34
joesavakjesse: yes - and we're potentially looking at resources as well. The issue is that keystone needs to freeze early on in essex with RBAC for services to start coding against that functionality18:35
heckjif we coordinated the tasks and made them a bit more available for other developers to add in, we might be able to get some external resources contributing here too18:36
heckjWe don't need to have the "only 2 devs, so push everything through as fast as possible"18:36
joesavakjoseph - i agree. Thanks for that. :)18:36
heckjBut structure is needed to enable other developers to help18:36
joesavakjoseph: ok - i think we're already on the right path - more blueprints & bug management for essex than diablo18:37
heckjThe conversations appear to be happening between some of the devs and HP, but I haven't seen anything on the lists, open conversations, or even announcements of meetings yet. We really need to get that straightened out.18:37
heckjI'm helping with docs now, and I've found it very difficult because of lack of access - and honestly I've been hesitant to just slap this into the mailing list. Maybe my bad18:38
*** ewindisch has joined #openstack-meeting18:38
heckjjoesavak: I don't want to say "essex only" - just more structure is needed in coordinating community involvement. Right now it appears to be all inward facing18:38
joesavakj - yea, we have been talking with Liem and Jason especially around domains18:38
heckjcan we shift that conversation to the mailing list? Or set up a time to talk about design ideas and considerations on IRC? SOmething to make it more available/accessible18:39
joesavakj - yes. I'll setup some time and we can do a sprint planning together. That may help18:39
joesavakok - any other questions or issues?18:40
*** jog0 has joined #openstack-meeting18:40
joesavak#topic action-items18:40
*** openstack changes topic to "action-items (Meeting topic: Keystone Team Meeting)"18:40
joesavakJoe Savak to schedule a meeting with HP contributors and RS contributors for keystone to flush out design more, task, and estimate work18:41
joesavakJoe Savak to check with Ziad on the E-0 possibility and communicate it out18:41
heckjHow about changing that to scheduling a "public" meeting18:41
anotherjesseheckj: ++18:42
joesavakj- ok, public. We might do it on our next ks status meeting18:42
joesavakJoe Savak to request peer reviews of RS developers18:42
joesavakdid i miss anything?18:42
joesavakJoe Savak to have a beer?18:43
joesavakok - thanks y'all.18:43
*** openstack changes topic to "Openstack Meetings: http://wiki.openstack.org/Meetings | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/"18:43
openstackMeeting ended Tue Oct 25 18:43:56 2011 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)18:43
openstackMinutes:        http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-10-25-17.59.html18:43
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-10-25-17.59.txt18:44
openstackLog:            http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-10-25-17.59.log.html18:44
*** adjohn has quit IRC18:49
*** darraghb has quit IRC18:55
*** robertn_ has joined #openstack-meeting18:59
* soren pokes mtaylor 19:00
* mtaylor pokes soren19:00
* carlp doesn't like poking19:01
mtaylorwho's here. anyone19:01
* mtaylor pokes carlp19:01
* mtaylor pokes carlp19:01
* mtaylor pokes carlp19:01
* mtaylor pokes carlp19:01
* mtaylor pokes carlp19:01
carlpthanks Monty19:01
robertn_pokes carp in the tenders19:01
mtaylorand with that ...19:01
openstackMeeting started Tue Oct 25 19:01:43 2011 UTC.  The chair is mtaylor. Information about MeetBot at http://wiki.debian.org/MeetBot.19:01
openstackUseful Commands: #action #agreed #help #info #idea #link #topic.19:01
mtaylorsigh. the minutes linked to on the wiki are not the droids I'm looking for19:03
mtaylorso - last time we talked for about two hours on the topic of packaging19:03
mtayloranybody want to start that freight train moving again?19:03
carlpit was exciting19:03
mtaylorit was so exciting19:03
mtaylor#agreed everyone loved talking about packaging last week19:03
anotherjessemore exciting than keystone meeting?19:03
mtayloranotherjesse: I was eating a sandwich during the keystone meeting - did I miss fun?19:04
mtaylorblast. that'll teach me to eat19:04
carlpmtaylor: do you have time this week where we can meet and setup netstack jenkins slave?19:05
zullest talk about it again :)19:05
mtaylorso - in general, since last week I've gotten nova trunk gating moved to building from pip-based venv instead of slaves with depends installed from packages19:05
mtaylorit was fun - I discovered in working on caching the process of building the venv that venvs are not terribly relocatable, even after running virtualenv --relocatable19:06
*** naehring has joined #openstack-meeting19:06
mtaylorcarlp: YES19:06
sorenmtaylor: Huh?19:06
sorenmtaylor: Oh, nm.19:06
carlpmtaylor: Let's schedule a time offline for that then19:06
heckjmtaylor: definitely missed the fun of keystone mtg19:06
mtaylorcarlp: how does sometime during the day tomorrow work?19:06
mtaylorcarlp: yes to offline19:07
sorenmtaylor: What about all the stuff that isn't in pip?19:07
mtaylorsoren: those are still installed via apt19:07
sorenmtaylor: Where does that come from? Which versions of everything to expect?19:07
mtaylorsoren: tools/pip-requires19:07
mtaylorsoren: virtualenvs are rebuilt any time tools/pip-requires changes, and additionally are rebuilt every night for good measure19:07
sorenmtaylor: Eh?19:07
heckjsoren: the tools/pip-requires are pretty religiously updated too, since almost all the devs are using them19:07
heckjoh wait, I think I misread your question19:08
mtaylorI'm not thrilled about the current state of tracking the things that get installed not via pip19:08
sorenmtaylor: Right, but the stuff that isn't in pip. Where does that come from? Which versions of those things can one expect?19:08
heckjmtaylor: I think it's mostly in README and the like, is that correct?19:08
sorenmtaylor: I'm with you. Mixing packaging systems is craptastic.19:08
mtaylorcurrently, anotherjesse has a list in devstack, I have a list in the puppet modules for our slaves, and jeblair has one in the preseed launch stuff for bare metal19:08
anotherjessemtaylor: we are currently focusing on diablo19:09
mtaylorI would really love to figure out a sane way to maintain that list that makes it easy for devs to deal with and not wonky for the currently 3 automated systems that need the list19:09
anotherjesseonce we move to essex then we will want to figure out a way to share lists19:09
anotherjesse(perhaps coming from the projects themselves?)19:09
mtayloranotherjesse: cool. yeah - it's a terrible problem right now - but it's going to get old over time19:09
sorenmtaylor: Which kernel version, which version of libvirt, etc. etc.? Whatever's in Maverick? Natty? Oneiric?19:10
mtaylorit's NOT a terrible problem right now19:10
heckjmake some files in tools/ for each project - packagedeps-apt packagedeps-rpm19:10
mtaylorsoren: so, the idea is that we'll still have a ppa with depends19:10
heckjwould that work?19:10
sorenmtaylor: Also, how do we handle it when we need changes to upstream code?19:10
mtaylorsoren: at the moment it's nova-core's ppa driving the slaves - but I would like a non-project specific ppa - I made one in ~openstack-ci but I'm not 100% convinced that's the right place for it19:11
*** zns has quit IRC19:11
sorenmtaylor: We've on more than one occasion had sporadic test suite failures due to Eventlet bugs.19:11
mtaylorheckj: the main issue there is that from an integration perspective, we kind of need people to agree on dep versions ... so I'd like to have a master list of "this is what needs installed for openstack"19:12
mtaylorsoren: yes - that would be the sorts of things we'd want in the ppa of depends - and also of course forwarded upstream and to the distros19:12
*** mmetheny has quit IRC19:12
heckjmtaylor: ah - so a need for a combined list, rather than one for each project19:12
*** mmetheny has joined #openstack-meeting19:12
mtaylorheckj: that's what _I'd_ like19:12
mtaylorbut I'm open to being shot down there19:12
sorenmtaylor: So how would that work? Would we temporarily remove it from pip-requires and move it somewhere else?19:12
heckjgiven the growing cross-dependencies in code, that makes sense to me19:13
mtaylorsoren: oh - you mean pip-requires-based things19:13
sorenmtaylor: Yes.19:13
mtaylorsorry - brain dead for a sec19:13
mtaylorgood question ... it's still on the cards to make our own pypi server that trunk versions of our software gets uploaded to19:13
mtaylorI would think we could temporarily upload other things there - but I'd like to keep that to emergencies- otherwise I think things start getting weird19:14
sorenWe didn't choose not to use pip to begin with at random. It was a rather conscious decision.19:14
sorenJust sayin'.19:14
mtaylorI know19:14
sorenIn other words: I don't know. I don't have a good answer for how to do it with pip.19:15
mtaylorthat's fair. I'm going to propose then that when we run against that, we can look at uploading something to our openstack pypi and see how that works for us19:16
*** zns has joined #openstack-meeting19:16
*** blamar has quit IRC19:17
mtayloranybody have any sense if the projects would be opposed to changing the location of the virtual env that run_tests.sh creates from .${project}-venv to .virtualenv ?19:17
anotherjessemtaylor: wouldn't that make it harder if different projects need different versions?19:18
anotherjesseI'm not a venv expert19:18
heckjmtaylor: I don't think it makes that big of a difference - they're never in the same directory19:18
mtaylorbecause right now I've got a template job in jenkins that handles venv stuff - and I'd love if it could not have to attempt to figure out the name of the venv ...19:18
mtayloranotherjesse: what heckj said19:18
mtayloranotherjesse: but we're also trying to incite projects to need the same versions of deps :)19:18
anotherjessemtaylor: crazy talk19:19
mtaylorI know. I'm completely mental19:19
mtaylorheckj: cool. I'll try to propose some patches there - I think it'll make the jenkins code a little more reusable19:19
mtaylorso moving forward:19:20
mtaylor#action mtaylor get run_tests.sh patched to create .virtualenv instead of .${project}-venv19:20
mtaylor#action get other projects migrated to the pip builders19:20
mtaylor#action mtaylor get that darned pypi server set up19:20
mtaylorthat's the stuff I'm going to try to get going on this front19:21
mtayloranybody got anything else on pip builders?19:22
mtaylor#topic bare metal19:23
*** openstack changes topic to "bare metal"19:23
mtaylorin other news, jeblair has made great progress in getting the bare metal stuff ready to start running tests19:23
mtaylorjeblair: wanna catch folks up?19:23
jeblairhere's a summary:19:24
jeblairi have a procedure for setting up a machine to drive tests, based on ubuntu orchestra19:24
jeblairdocumentation for that will be up real soon now19:25
anotherjesseorchestra = juju?19:25
jeblairi have a jenkins slave running on that machine, and it's running the above job19:25
jeblairensemble == juju19:25
jeblairorchestra == cobbler19:25
jeblairbasically the idea is to distill down to instructions that look like "apt-get install ubuntu-orchestra-server" and install these config files19:26
jeblairattempting to get the barrier to entry for running bare metal tests very low19:26
* anotherjesse would be interested in adding it to devstack tools directory once done19:26
jeblairpart of the orchestra configuration is to set the test machines up with an lvm snapshot so we can do use kexec to quickly reset them to a known state.  that seems really solid now19:27
jeblairso the above job runs kexec to reset the machines, then runs devstack on them to set up openstack19:28
anotherjessejeblair: interesting - any good docs on reading how that works?19:28
jeblairanotherjesse: mostly written, should be up soon19:28
anotherjessejeblair: I was referring to kexec in general for this use case - but can't wait to see your docs as well19:29
anotherjesse(eg when researching this did you find any good resources)19:29
jeblairthen the job runs exercise.sh, which is where we are now.  it looks like we'll need to change the configuration a bit19:29
jeblairanotherjesse: i think this is a moderately novel use of kexec.  mostly it's used by kernel developers to test new versions of the kernel.  i didn't run into many folks using it for qa, but i could have just missed it.19:30
anotherjessejeblair: trail blazing!19:30
heckjneat, looking forward to seeing how you did it!19:31
*** hggdh has quit IRC19:31
jeblair:)  another improvement over our last iteration of bare metal testing is:19:31
jeblairif you visit the link above, you'll see that the syslogs for each host are separately archived along with the build19:31
jeblairso it should be easier to diagnose problems by looking at the syslog for just the head node, or just a compute node, etc.19:32
*** blamar has joined #openstack-meeting19:32
jeblairthat's about the state.  mostly we need to tune the devstack config so exercise.sh works and make sure all the openstack components are syslogging so we get all the info19:32
mtaylorjeblair: you're doing this with oneiric images, yeah?19:33
jeblairthen we should be able to start running post-commit tests on that19:33
anotherjessejeblair: making devstack enable syslog is probably a good thing in genearl19:33
jeblairif post commit is solid, we can start gating19:33
mtayloranotherjesse: I was thinking perhaps a flag to devstack which toggles between starting things in screen or starting things normally spitting to syslog? or is that too much?19:33
anotherjessenot too much - lets create an issue (once we move to essex we will move to lp+gerrit for devstack)19:34
jeblairmtaylor: i don't care if things start in screen as long as they also syslog19:34
mtayloranotherjesse: ++19:34
mtayloranotherjesse: actually, I think we're going to have to gerrit devstack before we can use devstack based things for trunk gating19:34
*** hggdh has joined #openstack-meeting19:35
mtaylorbecause we'll want to be able to make sure that devstack changes don't break known good trunk, and then that trunk works with known good devstack, yeah?19:35
anotherjessewe were hoping to move to essex at end of day today - but given the uncertainity about keystone I'm not sure19:35
anotherjessemtaylor: if needed we can move earlier19:35
mtayloroh well - we should be fine then :)19:35
jeblairyeah, i thought you meant something other than that by 'move to essex'. ;)19:35
*** adjohn has joined #openstack-meeting19:35
mtaylorsame here19:35
heckjanotherjesse: you're still in the last meeting in your head, aren't you… I am.19:36
anotherjessemtaylor: stackrc points to diablo and we haven't worked on essex (eg master) since we need to get diablo working for users first19:36
anotherjesseit *might* work on master- not sure19:36
mtaylormakes total sense ...19:36
jeblairi'm happy to move devstack into lp/gerrit as soon as you're ready.  is openstack/ or openstack-ci/ the right place for it?19:36
anotherjesseI think openstack/ but it doesn't feel like a full project19:36
anotherjesseit is just a shell script19:37
anotherjessewe can email the list19:37
heckjI'm good with either.19:37
mtaylorjeblair: that might be the reason why exercise.sh isn't working for you? or are you running it on diablo too19:37
jeblairno, it's running on cloudbuilders diablo19:37
heckjanotherjesse: I may not get the swift stuff complete before you want to move it - in that case I'll just re-do into gerrit from your branch19:37
jeblairbreak one thing at a time. :)19:37
mtaylorjeblair: ok. good to know :)19:37
jeblairi'd like to see openstack/ be for full openstack projects in the long term.  i know the ci team has some stuff in there. we're going to move it out i think, but it's a little tricky due to the number of machines with operational scripts expecting those repos right now19:38
jeblairshould be easier once monty finishes the pip builders, actually.19:39
jeblairmaybe devstack belongs there, if not, openstack-ci makes some sense to me.  it's possible this is a bit of a bikeshed now. :)19:39
jeblairany other questions about bare metal19:39
anotherjessejeblair: just a note that we (rax cloudbuilders) are working on build_domu.sh that works like build_kvm or build_lxc19:40
anotherjessefor xenserver19:40
anotherjesseyou might want to add a xenserver version eventually for gating19:40
anotherjessejeblair:  sleepsonthefloor is working on that and getting help from citrix / rax public cloud19:40
mtayloronly one is the one I hinted at earlier - which also affects non baremetal stuff - currently we're doing all testing on natty still - partially because there are no oneiric images in cloud servers yet19:41
jeblairanotherjesse: cool19:41
mtaylorI'd like to move that to oneiric when we have images for it - anybody have a problem with that?19:41
anotherjessemtaylor: could you use freecloud with oneiric uec images?19:41
anotherjesseI think using oneiric is probalby good as it (should) decrease the size of the ppa needed?19:41
mtayloranotherjesse: possibly. we've also gotten access to an account on the hp cloud which we're working on integrating in to slave pools19:42
jeblairwhatever provider we use does need to be very stable19:42
mtayloryes. which so far is mainly rax cloud servers ... but as soon as we have jclouds plugin finished, I'd love to have on-demand slaves across a few different clouds once we can19:43
mtaylorespecially if we can use the same uec image on each provider19:43
anotherjessemtaylor: is anyone working on the jcloud? I'm not a java person but would love to see that working19:43
mtaylorbut that's starting to be a whole other topic - and a bit longer-term than this week :)19:43
mtayloranotherjesse: still sourcing around for someone to do that work - I have a few leads - but yeah, it'll be great to get that plugin done19:44
zykes-what meeting is this again?19:44
carlpzykes-: CI19:44
mtaylorI think that's about it for bare metal...19:45
mtaylor#topic open discussion19:45
*** openstack changes topic to "open discussion"19:45
mtayloranybody got anything else?19:45
mtaylorwant to throw rotten fruit?19:45
jeblairwe should maybe cancel next week's meeting?19:45
anotherjessemtaylor: I'd love to hear the state of the actual tests - is that what soren has been doing?19:45
carlpI think I got that out of my system with the poking earlier19:45
mtayloroh yeah - jeblair, soren, vishy, ttx and I are all going to be at UDS next week19:46
*** jk0 has joined #openstack-meeting19:46
mtayloranotherjesse: are you coming? or are you staying home?19:46
anotherjessemtaylor: I'll be there - as soon as I get my tix19:46
mtayloranotherjesse: sweet19:46
heckjme too19:46
jeblairanotherjesse: gabe and daryl are working on that as well as soren19:46
carlpI'll be at home :(19:46
mtaylorso I think it's fair to say we will not have an IRC meeting for CI next week19:47
zykes-anyone at the citrix summit now or ?19:47
ttxOur plan is to drown mtaylor in the pool before he starts relying on devstack for CI19:47
zulcount me in19:47
mtaylorttx: too late19:47
ttxsoren: will need your help19:47
ttxmtaylor: you mean you started to learn swimming ?19:47
mtaylorttx: started? dude, I've been swiming since I was a wee small boy- I grew up in the south, there is only one thing to do in the summer down there, and it's get in a pool of water19:48
mtayloranotherjesse: it is set up in gerrit - and I've seen patches come through19:48
mtayloranotherjesse: I think it'll be really helpful once we're using at least part of it to gate something, so that there can be good feedback in terms of inputs/outputs needed19:48
ttxStill think that with soren and zul we can succeed.19:49
jeblairoh, regarding that, if we're ready to gate before os-integration-tests are ready, i'm planning on just using exercise.sh as a placeholder and to have something to gate on19:50
mtaylorthat seems like a great step one to me19:50
anotherjessejeblair: exercise.sh is a place holder for us too ;)19:50
anotherjessejeblair: we plan on helping with the ci tests once we things have stabilized19:50
jeblairgroovy :)19:51
sorenSorry, was away for a little bit.19:54
sorenttx: Need my help for what?19:54
jeblairthis would be a great time to end the meeting!19:55
*** jbryce has joined #openstack-meeting19:56
*** naehring has quit IRC19:56
*** ewanmellor has joined #openstack-meeting19:56
*** openstack changes topic to "Openstack Meetings: http://wiki.openstack.org/Meetings | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/"19:57
openstackMeeting ended Tue Oct 25 19:57:08 2011 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)19:57
openstackMinutes:        http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-10-25-19.01.html19:57
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-10-25-19.01.txt19:57
mtaylorthanks everybody19:57
openstackLog:            http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-10-25-19.01.log.html19:57
*** bencherian has joined #openstack-meeting19:58
sorenttx: Oh. That. Yeah, sign me up.19:59
*** johnpur has joined #openstack-meeting19:59
openstackMeeting started Tue Oct 25 20:00:01 2011 UTC.  The chair is jbryce. Information about MeetBot at http://wiki.debian.org/MeetBot.20:00
openstackUseful Commands: #action #agreed #help #info #idea #link #topic.20:00
jbryceroll call?20:00
jbryceewanmellor, johnpur, vishy, anotherjesse: around?20:01
jbryceall right...that's enough to get started20:02
jbrycehttp://wiki.openstack.org/Governance/PPB - agenda has 1 thing on it20:02
jbryce#topic Status on vulnerability management team setup20:02
*** openstack changes topic to "Status on vulnerability management team setup"20:02
jbrycettx: want to take it away?20:03
ttxyes, wanted to do a quick update20:03
ttxwe recently made progress in setting up proper security teams20:03
ttxThe proposed plan is to have a very small team of vulnerability management people (that will just be reponsible for tracking the fix and disclosure process)...20:03
ttx...and a large (open) team of security-concerned folks to discuss auditing and security improvements to OpenStack.20:03
ttxFor the first team, see http://wiki.openstack.org/VulnerabilityManagement20:03
ttx#info Proposal is that the small vuln-mgmt team would be set as "security contact" for all the core projects20:04
ttxNote that the affected PTL is getting involved as the very first step to vulnerability resolution.20:04
ttxYou can also see the proposed openstack.org/security page contents at:20:04
ttx#link http://etherpad.openstack.org/8hWNQwkWf920:04
ttxLet me know if you see anythign wrong in there20:05
znsttx: says to join https://launchpad.net/~openstack-security but the group does not exist.20:05
ttxzns: sure, the contents needs t obe approved first20:06
ttxbasically I'm not sure we should have a common openstack group, or should we have project-oriented groups20:06
ttxlike the nova-security-improvements subgroup that vishy set up20:06
znsttx: ah. OK.20:06
mtayloris there any benefit to having per-project security groups?20:07
vishyttx: that subgroup was meant for improving the security of the code as opposed to responding to vulnerabilities20:07
ttxvishy: the same for ~openstack-security20:07
*** adiantum has joined #openstack-meeting20:07
mtaylorseems like openstack group is the easier to maintain - and I'd think that doing that and then moving to more complex if needed would make sense20:07
vishyah ok20:07
ttxvishy #openstack-vuln-mgmt is the team for responding to vuln20:07
jbrycei think there are big benefits to only have one team and i don't expect the volume to be extremely high20:07
jbryceespecially in the area of simplifying the process20:08
ttxvishy: would you mind if we refunded ~nova-security-improvements into ~openstack-security ?20:08
vishyone team for improvements seems kind of silly to me20:08
ttx(that one is an open security interest group)20:08
vishythey are very project specific20:08
jbrycesorry...i'm talking one team for vulnerabilities20:08
ttxjbryce: we need one team for vuln20:09
vishywhy would anyone who works in glance or swift care about reimplementing a nova-db worker to lock down the database?20:09
jbrycei agree that improvements probably make more sense as separate teams20:09
vishy(for example)20:09
anotherjessevishy: the http://wiki.openstack.org/VulnerabilityManagement seems to say it is about processes not code fixes20:09
anotherjessefor handling security issues20:09
vishyone team for process seems fine20:09
vishyseparate teams for implementation though20:09
pvofor just security issues, I would think 1 team would work .20:09
ewanmellorOn the vuln side, I would like to see a statement that "responsible disclosure" includes disclosing to downstream products and distros in a private, co-ordinated fashion, so that we can get patches to our customers on the day of the public disclosure.20:09
pvovishy: agree for implementation20:09
ttxewanmellor: see http://wiki.openstack.org/VulnerabilityManagement20:10
ttxewanmellor: it states it a bit more clearly20:10
jbryce#info one team for vulnerability management across all openstack projects20:11
ewanmellorttx: OK, I would like to see one page with this stuff written down, not two ;-)20:11
jbryce#info separate teams by project for general security improvements20:11
ttxanotherjesse: the question is whether a common "openstack-security" group (to discuss security improvements) is better or worse than separate ~nova-security and others20:11
vishyttx: imo, security improvements are code specific and a shared group would just get bogged down in theory20:12
ttxvishy: yes, I have no string opinion either way20:12
ttxvishy: the security folks kinda prefer a common group, but I agree that a project-focused group would deliver more results20:12
*** heckj has quit IRC20:12
ttxewanmellor: will make sure that is written down in both places !20:13
vishyttx: who are "the security folks"?20:13
ttxewanmellor: (the etherpad is the static website content, the wiki is much more controllable)20:13
ttxvishy: people that came to Ray and I at the end of the nova security meeting and with which we brainstormed this so far20:13
ttxvishy: mostly code auditors20:14
reedwe should also close the list openstack-security20:14
ttxreed: close ? list ?20:14
ewanmellorttx: What is the meaning of the term "downstream users"?  I would expect a company like Citrix, as a downstream software vendor, to be notified before e.g. Disney, as a downstream deployer.20:14
reedI don't think it's used at the moment http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security20:14
_0x44I think in general it makes more sense for there to be project level sub-teams that can serve as the single-point of contact for the openstack-security team when it actually is formed.20:15
_0x44They're complementary20:15
ttxvishy: I'll discuss the split with them20:15
*** dendrobates is now known as dendro-afk20:15
ttxewanmellor: downstream users = distributions and public cloud providers20:16
ewanmellorttx: OK, worth clarifying.  Private cloud users may wonder whether they are in that category, or why they are not.20:16
ttxewanmellor: we will refine the process once the team is in place.20:16
ttxewanmellor: we badly need some process set up. it won't be set in stone once it's in place20:17
ttxewanmellor: but I see what you mean.20:17
jbrycettx: +120:17
jbrycelet's get it in place and then we will really find out where we need to improve it20:17
ttxOK, so we'll proceed in setting up the vuln-mgmt team and make progress on vuln management process20:17
ewanmellorttx: Also, does the Coordinated Disclosure section imply that those phases happen in strict order?  I would want to be notified that a vuln was known even before a fix was ready, because I usually need to get a QA slot reserved.20:18
ttxand I'll discuss splitting the security interest groups per project20:18
ttxewanmellor: the problem is to balance disclosure with speed of fix20:18
ttxewanmellor: once downstream users (with my definition) know about it, it's all downhill from there20:19
ttxewanmellor: you need to coordinate release fast20:19
johnpurttx: fixes hit the "stable" branch quickly?20:20
ttxewanmellor: that's why the current proposed process gets a fix first20:20
ttxthe stable branch would be one of the downstreams.20:20
ewanmellorttx: Not true.  The aim is to be co-ordinated and careful, not necessarily fast.  Citrix would handle any vuln with strict non-disclosure rules (we have a team that does this).20:20
ttxewanmellor: and then coordinates the fix down20:20
*** dendro-afk is now known as dendrobates20:21
ttxewanmellor: the "downstream users" group will be large. You can't keep a secret long with such a group20:21
ttxin my experience with 20+ people in the loop you can't embargo for more than one week.20:22
notmynamettx: based on the foundation announcement, seems that we can't keep a secret in the PPB either ;-)20:22
mtaylorit should be assumed that secrets are impossible to keep20:22
ttxmtaylor: indeed, that's why time is of the essence20:22
ewanmellorttx: That's why I asked what the definition of "downstream users" was.  You said that is was distros and public cloud providers, by which I assumed you meant the professional security teams of said companies.20:22
ttxI bet the moment the vulnerability is known, some affected people will start deploying fixes.20:24
ttxewanmellor: I see your point. I guess we can discuss that when we'll have a list for the "downstream users" :)20:24
ewanmellorttx: So I would expect that the existence of a vuln, disclosed to professionals, would be treated with the professionalism, respect, and secrecy that we would all expect.  We _have_ to be able to keep a secret for more than a week, because we may need to do more than a week's QA on it.20:24
ttxsee if we can reorder the process20:24
johnpurfor users in production, it may be critical to get the fixes, get through QA, and pushed to production20:25
ttxewanmellor: I guess a few years on vendor-sec has left me a bit pessimistic20:25
ttxjohnpur: that's agreed. ewan is proposing that all downstream users know about the vulnerability as early as possible, even with no fix available yet20:26
jbryceso where do we sit on this? we think the proposal is good but we need to determine exactly when a broader group is notified that a vulnerability exists vs. that it exists and has a fix?20:27
ttxewanmellor: I guess we could say something is coming up, without too much detail20:27
ewanmellorttx: Know about the _existence_ of a vuln.  Not necessarily what it is.20:27
ttxewanmellor: oh, I see20:27
ttxewanmellor: sure, that's acceptable20:27
ttx(I think)20:27
johnpurttx: agree. need to define downstream crisply, particularly the branches that have deployed systems20:27
ttx"something affecting that and that, severity High, coming up, patch on its way"20:28
jbrycettx: that makes sense to me20:28
ttxewanmellor: I'll roll that in the process20:28
ttxewanmellor: or you can. hey, it's a wiki :)20:28
*** blamar has quit IRC20:28
ewanmellorttx: Sounds good.20:28
ttxjbryce: I think I'm done, will keep you posted with more progress next week20:29
ewanmellorSecurity processes documented on wikis *shudder*20:29
ttxewanmellor: hehe20:29
jbryce#topic open discussion20:29
*** openstack changes topic to "open discussion"20:29
jbryceanyone have anything else they'd like to discuss?20:30
mtaylorI'd like to propose making the core dev infrastructure (CI, gerrit, jenkins, whatnot) an openstack project with a ptl who's voted in by its devs rather than just something everything depends on and happens to be there20:31
*** dprince has quit IRC20:31
devcamcarhere now btw20:31
mtaylorespecially now that we're starting to get more contributions in that space from non-rackspace folks20:31
ttxmtaylor: I would keep "openstack projects" to pure user-facing code. Make up a team and hold elections if you want ?20:32
notmynamemtaylor: I like that idea20:32
mtaylorttx: well yes - I essentially just want to make it a thing we recognize and manage, rather than merely something we count on20:32
ttxi.e. don't reuse the word PTL but copy the idea20:32
jbrycettx: i agree. i wouldn't consider that "administrative" type thing to be part of the shipped openstack software20:33
ttx"Team lead"20:33
bencherianmtaylor: i like it as well. we're working on a lot of the core dev infrastructure stuff right now and will definitely contribute it back if we can20:33
ttxteam leads should be elected as soon as people don't agree who should be the lead, basically20:33
notmynameI like the idea of the packaging/integration piece being an equal voice and managed the same as the other projects. and we all integrate with the 6 month releases20:33
jbrycei think set it up as a project and elect a team lead if you want and encourage contributions, but it's not really part of a cloud software stack20:34
jbryceit's not going to get get shipped in a downstream distribution or deployed at a service provider20:34
ttxi.e. it's not incubating or core or whatever20:34
notmynamejbryce: no, but it's an essential piece of openstack itself20:34
mtaylortotally not part of the cloud software stack ... but I think notmyname put it well ... it's about explicit governance/managment/ppb oversight20:34
ttxnotmyname: I'm not sure mtaylor includes packaging in that20:35
notmynamettx: he should ;-)20:35
johnpurmtaylor: do you consider the openstack-qa effort part of this?20:35
mtaylorttx: well... I would include packaging in that if the openstack project decided it wanted to provide packaging :)20:35
notmynamejohnpur: I would20:35
ttxmtaylor: my point :)20:35
mtaylorjohnpur: interesting question - one consumes the output of the other in my head20:35
johnpurmtaylor: right20:36
mtaylorI actually think that openstack-qa should similarly be an administrative managed grouping that also doesn't produce shipped code20:36
annegentleI get encouraged to do the same for Docs - PTL for docs, but I think it's not necessary as doc doesn't create/maintain clouds20:36
ttxSo we might need some area for "official team" or something20:36
ttxI don't want all teams to go through PPB for formation*20:36
znsWould this be something the "foundation" would own?20:36
ttxthough some teams, owning some critical central stuff, would benefit from PPB oversight20:36
annegentleor rather, not necessarily unnecessary, but the wrong governance model20:36
jbrycei'm fine if we want these things to have some kind of oversight/governance, but i think that we should not confuse it with the "product" that we're building20:37
notmynamethese things, IMO, are all part of a meta-project. I'd consider all of the support pieces (including docs) to be part of it20:37
johnpurso we need to "define" how we handle automation, qa, and docs?20:37
notmynamezns: IMO, no more than the foundation "owns" swift, nova, or keystone20:37
ttxjbryce: sure. Not project, but "official team" or "meta-project", or whatever new name we can come up with20:37
devcamcarthrowing all the support projects into one lump doesn't seem wise20:37
ttxfor a team that own s a part of openstack that the PPB still should have oversight over20:38
johnpurttx: +120:38
ttxdevcamcar: I agree it should not be a single "janitor meta-project", but rather a category of stuff.20:38
notmynameIMO, it's not about oversight but consistency. allow each of the projects (including this yet-to-be-defined meta-project) to do things according to their needs and integrate with every major release. this means packaging, etc too20:39
ttxI can think of two teams that fit that description20:39
ttxdoc and CI20:39
johnpurttx: qa?20:39
*** adiantum_ has joined #openstack-meeting20:39
mtaylorI think qa is the third. it's currently working on producing openstack-integration-tests20:39
ttxjohnpur: I don't think so.20:39
mtaylorwhich will be pretty stinking important to the project20:39
mtaylorhopefully :)20:40
ttxWe could have multiple competing QA projects, no ?20:40
mtaylorgod I hope not20:40
zykes-devcamcar: got time for some questions regarding nova & db in #..-dev ?20:40
*** joesavak has quit IRC20:40
znsnotmyname: own wasn't the best word. I mean would this come under PPB and technical oversight or would it become infrastructure that is not directly governed by the PPB?20:40
mtaylorlet's put it this way - the CI system will not use multiple competing QA projects to tests openstack20:40
annegentlettx: I think QA and Doc could help each other.20:40
ttxI really see QA as a team thing. You don't need permission to do QA20:41
ttxand all QA is good20:41
*** blamar has joined #openstack-meeting20:41
ttxcontrast with CI -- you only have one CI.20:41
mtayloryou don't need permission to do qa - you do need permission to check in new tests to the tests suite that is used for trunk gating20:41
*** adiantum has quit IRC20:41
devcamcarzykes: I will be able to in a min20:41
ttxmtaylor: CI can choose to use whatever team's tests they want20:41
znsanngentle: Doc provides concrete deliverables that ship with the stack (PDF, webhelp, RST, etc..). QA/CI does not - what it delivers is quality but you don't download, install, and run that...20:41
ttxmtaylor: just choose to use the ones from the super-QA team20:42
mtaylorso the test suites that are the output of the QA team's work20:42
johnpurttx: getting a coherent and consistent qa effort amongst the community is super important20:42
mtaylorttx: so, that's a business I do not want to be involved in - choosing _which_ qa product I prefer20:42
mtaylorthere is currently a defined super-QA team for openstack, and I will use what they hand me - since that affects trunk gating, I think it should be managed20:42
mtayloris all I'm saying20:42
ttxjohnpur: my point is that if someone can't bear Jay and still wants to do QA, he should be able to20:42
mtaylorttx: and if someone can't bear vishy and still wants to hack on nova?20:43
johnpurttx: lol, who doesn't love jay?20:43
annegentlettx: the benefits would be in consistency (for all three teams)20:43
mtayloror doesn't like me and wants to help run the CI system? ;) (that's the more believable example)20:43
ttxmtaylor: my point -- QA is something you can do in multiple ways. While CI or Nova are unique20:44
annegentleall doc is good, but it's better if it's consistent and trustworthy20:44
*** adiantum_ has quit IRC20:44
mtaylorttx: I think you and I are using the word QA differently20:44
mtaylorttx: you are referring to the act of QA - I am referring to the concrete set of test code produced by the team who is doing testing activities20:44
ttxmtaylor: imagine a group calling themselves "the-fuzzers" wanting to do some code analysis and file bugs based on their results20:45
mtaylorttx: so we might need an additional word20:45
mtaylorttx: right. I don't give a shit about that :)20:45
ttxmtaylor: do you want to prevent them from forming a group ?20:45
ttxmtaylor: that's QA too20:45
mtaylorgod not. but that's not what I'm talking about20:45
mtaylorok. so let's call what I'm talking about "openstack integration test developers"20:45
ttxmtaylor: so I think you're not after "QA", you are after "the ones producing my test suite" which is quite different20:45
mtaylorso in my view - we have three of this style of currently unmanaged group - CI, Docs, and "the ones producing my test suite" - and I think we should come up with something slightly more official for them :)20:46
ttxmtaylor: agreed, that should be unique :)20:46
johnpurttx: i see it as more than that. consistent test frameworks, hooks to the ci mesh, gating trunk, etc.20:46
*** dendrobates is now known as dendro-afk20:47
devcamcarmtaylor: are you looking for a name or formal policy?20:47
ttxmtaylor: sure, just don't call them "projects" and don't call their lead "PTL".20:48
johnpurcode coverage, bare metal provisioning and deployment, etc.20:48
notmynamettx: -120:48
devcamcarjohnpur: sounds like we just had our first major scope creep20:48
devcamcarsome of the things you described are proposed for satellite20:49
mtaylorjohnpur: well, that's sort of why jim and I like to refer to ourselves as "core dev infrastructure" rather than just CI20:49
johnpurdevcamcar: it is part of the on-going openstack-qa discussion20:49
zykes-scope creep devcamcar ?20:49
mtaylorjohnpur: since we currently manage all of those things in the set of systems that are relyed on by the project20:49
ttx<jbryce> i think set it up as a project and elect a team lead if you want and encourage contributions, but it's not really part of a cloud software stack20:49
ttx<jbryce> it's not going to get get shipped in a downstream distribution or deployed at a service provider20:49
jbrycethere is a difference between software we're shipping to our users and things that help us produce that software20:50
*** wwkeyboard has joined #openstack-meeting20:50
devcamcarjbryce: Exactly20:50
jbrycei agree with ttx that we shouldn't call the latter exactly the same thing as the former20:50
ttxnotmyname: if they don't have release code deliverables, they shoudn't be a core project20:50
devcamcarqa and ci arw closely coupled, but docs?20:50
johnpurservice providers (being part of the community) will be setting up and running CI and QA systems (hopefully).20:50
jbrycebut i think if we want to come up with some more official mechanism for oversight we can do that20:50
ttxand if they can't be a core project... then calling them "projects" is confusing20:51
notmynameintegration with packaging, CI, docs, etc (whatever this group is called) should be the same as eg integration between nova+glance+swift+keystone20:51
notmynamettx: it's about consistency20:51
*** bcwaldon has joined #openstack-meeting20:51
jbrycenotmyname: i think they're too different to try to enforce artificial consistency20:51
notmynamejbryce: what's artificial?20:51
jbrycetheir output has very different purposes20:51
notmynamettx: I thought we only had one deliverable: Openstack ;-)20:51
*** robertn_ has quit IRC20:52
ttxI don't have strong feelings either way, but calling them all "projects" while they are all different things doesn't really help20:52
notmynamettx: I think you've used the word "component" in the past :-)20:52
mtaylorso, I guess the thing that I'm on about is that currently there are a set of us doing the tasks to get these things done, and we respond to the needs and wishes of the ppb... but the relationship of the people doing the jobs to the openstack project is happenstance rather than explicit20:53
jbrycenotmyname: yes...the projects are components of the open source cloud system we are trying to build....20:53
ttxnotmyname: the word "project" unfortunately survived !20:53
mtaylorI think the areas themselves are actually working pretty well20:53
jbryceci software would not be a component of that20:53
notmynamemtaylor: so are you in search of a problem here?20:53
mtaylornotmyname: possibly20:53
ttxmtaylor: maybe wait for it to fail20:54
*** mdomsch has quit IRC20:54
* mtaylor likes having failover systems in place _before_ failure ... but perhaps spent too much time doing HA consulting20:54
ttxmtaylor: the PPB (currently) has the power to fix things going wrong... not sure it should be involved in things that work well20:54
notmynamejbryce: ttx: this may poison my whole argument for a separate project, but I really like this idea because it's part of what I originally wanted with with project autonomy. each project (including the meta-project) choosing for themselves their best things and integrating with every major openstack release20:55
*** joesavak has joined #openstack-meeting20:55
*** Oneiroi has joined #openstack-meeting20:55
ttxI guess I don't like the idea of a single meta-project with one true lead. I think Anne should lead docs, whoever happens to lead CI.20:56
jbrycei'm not sure there's an action to take right now unless someone wants to try to put together a real proposal20:56
ttxand if there is more than one, you need a category20:56
johnpurwhere i see ppb involvement is enforcing that the ci and qa processes are required of projects. that we use common processes and utilize the same mechanisms to gate trunck, etc. trying to push a consistent approach.20:56
notmynamettx: no different that nova and lieutenants20:56
*** Ravikumar_hp has joined #openstack-meeting20:57
ttxnotmyname: we don't call lieutenants areas "projects". They are called "subteams"20:57
notmynamejohnpur: enforcing integration across the projects20:57
notmynamettx: sounds good to me20:57
notmynamettx: a doc subteam of the openstack integration project20:57
ttxnotmyname: but who could lead a single frankenstein meta-project ? I don't think such a PTL would make sense20:58
*** Tushar has joined #openstack-meeting20:58
notmynamevishy is doing well ;-)20:58
notmynamej/k j/k20:58
jbryce1 minute20:58
vishyITS ALIVE!!!!20:58
jbryceparting thoughts?20:58
mtaylornotmyname: wait - are you now saying that vishy is _not_ doing well? ;)20:58
*** adiantum has joined #openstack-meeting20:58
*** joesavak has quit IRC20:58
notmynamemtaylor: you're putting words in my mouth :-)20:59
ttxmtaylor: that's what I heard !20:59
ttxBurn the witch !20:59
*** danwent has joined #openstack-meeting20:59
jbryceon that note....20:59
*** dubsquared has joined #openstack-meeting20:59
*** markmc has joined #openstack-meeting20:59
*** rjh has joined #openstack-meeting20:59
jbrycewe're out of time20:59
*** openstack changes topic to "Openstack Meetings: http://wiki.openstack.org/Meetings | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/"20:59
openstackMeeting ended Tue Oct 25 20:59:45 2011 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)20:59
openstackMinutes:        http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-10-25-20.00.html20:59
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-10-25-20.00.txt20:59
openstackLog:            http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-10-25-20.00.log.html20:59
devcamcarI heard that notmyname hates vishy omg! :)20:59
*** mcohen has joined #openstack-meeting20:59
*** johan_-_ has joined #openstack-meeting21:00
notmynamedevcamcar: whew. that wasn't logged :-)21:00
*** Gordonz has joined #openstack-meeting21:00
jbrycedo we need to schedule a witch-burning session at the next design summit?21:00
vishycan we get a scale?21:00
vishyand a duck?21:00
notmynamejbryce: the swift team calls those the PPB meetings ;-)21:01
zykes-pitchforks and torches ;p21:01
devcamcarand angry villagers!21:01
*** Vek has joined #openstack-meeting21:01
ttxok, let's get started21:01
_0x44devcamcar: I think between the two of us we can provide the angry villagers.21:01
openstackMeeting started Tue Oct 25 21:01:50 2011 UTC.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.21:01
openstackUseful Commands: #action #agreed #help #info #idea #link #topic.21:01
ttxWelcome everyone to the weekly general meeting... Today's agenda is at:21:02
ttx#link http://wiki.openstack.org/Meetings/TeamMeeting21:02
*** somik has joined #openstack-meeting21:02
*** jbryce has quit IRC21:02
ttx#info Please use #info #link #idea #action for a richer summary...21:02
ttx#topic Actions from previous meeting21:02
*** openstack changes topic to "Actions from previous meeting"21:02
ttx* ttx to set up some survey monkey for summit feedback21:02
ttxAFAICT the survey (common with Conference) should be launched today or tomorrow.21:02
ttxit's out of my hands now21:02
ttxAll the other actions were DONE and we'll talk about them in each project status.21:03
*** adiantum has quit IRC21:03
ttxzns: around ?21:03
ttx#topic Keystone status21:03
*** openstack changes topic to "Keystone status"21:03
ttxzns: Looking at:21:03
znsKeystone status update:21:03
zns- Many blueprints updated and targeted (more to come) - this was an action item from last week.21:03
zns- Working on upleveling our commit quality. Getting good feedback (thanks anotherjesse). More blueprints, specs, and bugs are being authored on and will be targeted to the appropriate milestones.21:03
zns- Documentation work for E0 making good progress.21:03
zns- Implementation of Diablo API calls that were not implemented is going slower than expected, but making progress.21:03
zns- We have updates in e0 that we'd like to back port to Diablo (especially bug fixes). But there are also schema changes which I think only belong in Essex, so we need to figure out how we can back port the fixes without the schema changes. Working on that.21:03
zns- Big question on the table is are we trying to go to fast? We are going to focus on getting the implementation done and stabilizing, so that might delay how much we can deliver by E3 (our early freeze). Stability and continuity (i.e. migration scripts) come first given customers are using Diablo.21:03
ttxso you decided to do a E0 ?21:04
*** renuka has joined #openstack-meeting21:04
znsI'd like to get whatever bug fixes we have shipped for E0. No need for customers to live with bugs.21:04
jaypipeszns: are you tracking a stable/diablo branch?21:04
ttxI heard that essex trunk already contains backwards-incompatible changes wrt diablo21:04
ttxso E0 can't be used as a bugfix release...21:05
ttxzns: if taht's the case, you should rather tag something on the stable/diablo branch21:05
ttxno ?21:05
jaypipeszns: ok, good. have any been applied to a stable/diablo branch yet? (not sure they could be, considering the rate of change in Essex trunk)21:05
znsttx: I don't know - what do you think? Better to backport to 2011.3 or have people try to find out what is the latest stable release (is it E0, E1, ex…?). I thought having the last stable release be THE release was a decision in Boston…21:06
zns… looking for your advice on this. We can do either...21:06
ttxdepends on what you want to do a milestone or release for...21:07
znsEssex trunk BTW works with all core projects. But it has a schema change, which is the main issue...21:07
ttxdo you want to do a diablo+, i.e. only bugfixes over what you released as diablo ?21:07
*** sifusam has joined #openstack-meeting21:07
devcamcarzns: we do need stable diablo branch asap. I'm fielding a ton of bug reports on my side related to keystone. quite a bit of overhead for us...21:07
znsMy take is that we should only backport fixes. No API changes or schema updates/migrations.21:07
anotherjesseI field this but https://bugs.launchpad.net/keystone/+bug/854425 is in the backports21:08
uvirtbotLaunchpad bug 854425 in keystone "schema normalization (token vs users/tenants)" [Low,Fix committed]21:08
anotherjesseand is a schema change without migrations21:08
znsdevcamcar: what would help you best; an E0 release with schema changes or backport to Diablo without schema changes?21:08
devcamcarzns: also for the schema changes I didnt see migrations21:08
devcamcarwhat jesse said21:08
znsI don't think we can do migrations for every milestone. That's a lot of work.21:08
anotherjessezns: disagree21:09
devcamcarzns: backport without schema changes21:09
znsHence my thought we backport to Diablo and leave the schema changes in Essex.21:09
anotherjessemigrations is how you do scheam change21:09
zykes-ttx: just as a note i use keystone (latest from trunk) and i'm grately satisfied...21:09
devcamcarzns: you should have migrations for every change, not every milestone21:09
_0x44How are you changing the schema without a migration?21:09
ttxzns: so you're after stable/diablo work and a tag there21:09
jaypipeszykes-: yes, but unfortunately, if you do that with diablo packages of nova or glance, everything blows up.21:09
znszykes-: thanks. Did you migrate from Diablo?21:09
ttxnot after a E021:09
anotherjessepretty easy to do migratinos21:09
znsttx: yes21:10
mtaylorI would think in this case that the migration isn't as much of a practical issue because noone out there is probably running the diablo keystone because of the issues21:10
zykes-jaypipes: uhm, i got nova + swift diablo and glance21:10
zykes-works dandy21:10
mtaylorso in GENERAL, things not having migrations is probably a good policy21:10
jaypipeszykes-: nova and glance DIABLO packages...21:10
mtaylorin this case, there is likely nothing large to migrate FROM21:10
ttxok, people calm down21:10
ttxso the keystone folks need to work on stable/diablo, backport what can be, and tag/ cut a tarball from that21:11
znsSo should we do releases every milestone (with migrations if the schema changes)? anotherjesses: you run many production deployments. Thoughts?21:11
ttxsince it's diablo work, it's not a formal Essex milestone21:11
zykes-jaypipes: yeah, i use the griddynamics packages for what was the core projects in the diablo release but keystone didn't work so i use it from trunk there21:11
ttxdiscussion on specifics of what is relevant for each branch and not can go off-meeting21:12
anotherjessezns: my view is migrations should always be explicit21:12
anotherjessein released software or even if you are just running a service21:12
ttxzns: I had a few questions about specs that may or may not be in your Essex plans:21:12
ttxhttps://blueprints.launchpad.net/keystone/+spec/pluggable-protocols (marked deferred) ?21:13
zns_0x44: changing the definitions in the model. That generates the schema in sqlalchemy.21:13
_0x44anotherjesse: +N, where N is the number of potential schema changes21:13
_0x44zns: ಠ_ಠ21:13
anotherjessepython model introspection and creating a new sqlite database any time you touch keystone-manage is not a good idea21:13
ttxhttps://blueprints.launchpad.net/keystone/+spec/2-way-ssl (targeted to essex-1 but not with series=Essex yet) ?21:13
ttxhttps://blueprints.launchpad.net/keystone/+spec/service-endpoint-location (targeted to essex-2 but not with series=Essex yet) ?21:13
ttxanotherjesse: looks like we could have an ML thread around that21:14
znsttx: OK. We'll fix those.21:14
ttxI don't want to spend the hour on this21:14
ttxzns: thx21:14
ttxzns: So your plan for essex-1 is https://launchpad.net/keystone/+milestone/essex-121:14
znsanotherjesse, _0x44: shall we go off thread? Would love to get your thoughts on how to handle this better/in line with other projects.21:14
ttxzns: Is that correct and on track (with 2 weeks left) ?21:15
devcamcarzns: I'm happy to help as well21:15
*** russellb has joined #openstack-meeting21:15
ttxAbout migrations / the best is to copy how other projects are doing it21:15
znsttx: yes. There are also additional changes we have not put in as separate BPs yet. Part of what we need to catch up on. They are calls in the Core API that were not yet implemented.21:15
ttxzns: OK, I'll be in touch with you this week21:16
znsdevcamcar: thanks. I'll start a mailing list thread.21:16
ttxI'd like to have finalized essex-1 plans by Thursday21:16
ttxzns: Anything else ?21:16
znsOK. No, nothing else.21:16
ttxSo in summary, two discussions are to be had around keystone -- migrations, and working on a diablo+ tag in the stable/diablo branch21:17
ttxis that a fair summary ?21:17
ttxwhen do you need that diablo+ tag ? last week ?21:17
znsttx: yes21:18
ttx#agreed two discussions are to be had around keystone -- migrations, and working on a diablo+ tag in the stable/diablo branch21:18
zykes-seems yogi is already working on backports? alot of mails raining in21:18
znszykes-: yes, he's working on it.21:19
ttxok, moving on to next project, then21:19
ttxunless someone has a question ?21:19
ttx#topic Swift status21:19
*** openstack changes topic to "Swift status"21:19
ttxnotmyname: o/21:19
ttxnotmyname: Any hint on when you'll want to release 1.4.4 ?21:19
notmynamewhen https://launchpad.net/swift/+milestone/1.4.4 is done21:19
*** adiantum has joined #openstack-meeting21:20
ttxok, that's a complete plan ?21:20
ttx(so far ?)21:20
notmynameI'd like to see most of https://review.openstack.org/#q,status:open+project:openstack/swift,n,z done for 1.4.421:20
notmynamethe milestone in LP covers most of that21:20
ttxnotmyname: Anything else ?21:21
notmynameI don't think so.21:21
ttxQuestions on Swift ?21:21
ttx#topic Glance status21:22
*** openstack changes topic to "Glance status"21:22
ttxjaypipes: had a few questions about https://blueprints.launchpad.net/glance/essex21:23
ttxAbout protected-properties: what is it blocking on ?21:23
*** carlp has quit IRC21:23
*** carlp has joined #openstack-meeting21:23
*** carlp has quit IRC21:23
jaypipesit's actually not going to be done at all. The 2.0 API proposal makes them irrelevant.21:23
ttxok, will mark superseded and remove from plan21:24
*** adiantum has quit IRC21:24
ttx#action ttx to mark protected-properties superseded and remove from essex21:24
jaypipesttx: already done.21:24
ttxAbout changes-since-filter: it's marked "Needs Code Review" but I couldn't find a corresponding review.21:24
jaypipesbcwaldon: ?21:24
ttxI was wondering if it wasn't just merged already and should be added to essex-121:25
bcwaldonbah, sorry, I'm here21:25
jaypipesttx: no, there was a branch bcwaldon did for that, but not sure what happened with it21:25
bcwaldonchanges-since-filter is implemented21:25
bcwaldonsorry for not updating the BP21:25
bcwaldonthat was done in diablo21:26
ttxbcwaldon: you mean it's a hidden diablo feature ?21:26
jaypipesok, done.21:26
bcwaldonttx: it's in the 1.1 spec, so it would have been a bug if it weren't done21:26
*** Gordonz has quit IRC21:26
ttxbcwaldon: heh21:26
jaypipesttx: it was added to nova first, then glance afterwards made it actually efficient IIRC.21:26
ttxjaypipes: Any other thing on your mind ?21:26
bcwaldonttx: just didn't make it into Glance release notes, I guess21:26
bcwaldonjaypipes: it was *accepted* as a param in nova first, just didn't affect the result21:27
jaypipesttx: trying to get the 2.0 Images API proposal out to the ML soon.21:27
jaypipesttx: for an RFC period of about 3-4 weeks21:27
ttxjaypipes: does one of your BP cover that ? Or is it still tbd ?21:27
jaypipesttx: after I get the API proposal out, I will create BPs for each subsequent change in the API that needs implemented...21:28
jaypipesttx: gotta get the proposal done first then I promise I will update the BPs to better represent the work.21:28
ttxjaypipes: ok. Already have a milestone target for that ? essex-2/3 ?21:28
*** bencherian has quit IRC21:28
ttxlooks like a busy milestone :)21:28
ttxanyone: Questions on Glance ?21:29
ttx#topic Nova status21:29
*** openstack changes topic to "Nova status"21:29
ttxvishy: yo21:29
ttx#link https://blueprints.launchpad.net/nova/essex21:30
vishy* hi21:30
ttxlot of activity today, still work in progress ?21:30
vishyso I've been targetting like mad21:30
ttxor seeing the end of the tunnel ?21:30
vishyI'm very close to having everything in essex21:30
ttx(the white light)21:30
vishyprioritization and milestone targetting haven't happened in detail yet21:30
*** cp16net has quit IRC21:30
vishyI did a first pass on the obvious ones21:30
ttxvishy: as far as targeting goes, would be good to nail essex-1 first21:31
vishyI'm going to send a message out to all the lists asking for help from the leads in targetting and cleanup21:31
vishyI think there are a few duplicates still.  There were a lot of very crufty blueprints21:31
ttxalso would be good to convert those team assignments into real people :)21:31
ttxthe kind I can ping to death on IRC21:31
*** Gordonz_ has joined #openstack-meeting21:32
ttxin doubt, I'll pig the team lead :P21:32
ttxvishy: how complete is https://launchpad.net/nova/+milestone/essex-121:32
ttxvishy: Is it complete or do you have more in mind ?21:32
vishyprobably pretty close actually21:32
vishyjust because it is coming up soon21:32
ttxright, two weeks left21:33
ttxSo pci-passthrough and osapi-console-log need to be completed over the next two weeks21:33
vishyboth of those are in review now21:33
vishyso i think they are ok21:33
vishyif anything else gets added, it will likely be stuff that is already under review that i didn't notice21:33
ttxoh, cool. btw, please use bp/* branch topics in Gerrit, so that we get magic links at http://wiki.openstack.org/releasestatus/21:34
ttxthat helps me in trying to update BP status for you21:34
vishyall stuff that hasn't been started i expect to be targetted e2 or later21:34
vishyttx: yes I guess they didn't know how to do that21:34
ttxWorking on more auto-BP-updating from commit messages with jeblair21:35
ttxvishy: Anything else ?21:35
vishyttx: I think that is it21:36
ttxvishy: think you can have essex-1 plan in order by Thursday ? Looks almost ok to me21:36
ttx(the rest of essex can wait a bit)21:36
ttxQuestions on Nova ?21:37
vishyttx: sure21:37
ttx#topic Horizon status21:37
*** openstack changes topic to "Horizon status"21:37
ttxyay Horizon.21:37
ttxdevcamcar: o/21:38
ttxdevcamcar: You got a nice and complete plan at https://blueprints.launchpad.net/horizon/essex21:38
*** bcwaldon has quit IRC21:38
devcamcarand a name!21:38
ttxIt's so complete it's a bit scary :) A few remarks:21:38
ttxWe need to keep "Essential" blueprints to a bare minimum.21:38
devcamcarunderstood, I will tweak21:38
ttxThey are supposed to delay the release if not completed. So I'm being even more a PITA about them, and having 7 of them is just too much.21:38
ttxSo I'd try to reprioritize a bit lower and keep the "Essential" ones a minimum, if possible.21:38
devcamcarthat's fair21:39
ttxFor any "Essential" you keep (if any), I'd like an assignee to be set. That would be the person I'll be a pain to :)21:39
ttxEssential: must do / High: will do / Medium: wants to do / Low: may do21:39
ttxthanks :)21:39
devcamcarmy other update is that we are really close to having migrated to all of the official tools21:39
devcamcargerrit transition should happen this week21:40
devcamcarand then we will be back into Jenkins, which is a relief for me :)21:40
ttxnext week I'll look into the release tooling, making sure we have what we need (basically Ci set up to produce tarballs)21:40
devcamcaroh and yea, we named it Horizon21:40
ttxdevcamcar: A few remarks on https://launchpad.net/horizon/+milestone/essex-121:40
*** liemmn has joined #openstack-meeting21:40
ttxYou should set assignees to all the blueprints and bugs targeted.21:41
ttxAt this point, if they are not assigned, they just won't get done in time :)21:41
ttxdevcamcar: Are all the blueprints you have there on track ?21:41
ttxI was wondering about improve-dev-documentation (slow progress ?) and javascript-unit-tests (not started ?)21:41
devcamcarthanks autocomplete21:41
devcamcarjs unit tests will get done next week21:41
devcamcardev documentation has been ongoing21:41
devcamcari think evry21:42
devcamcarI think everything is tracking well right now21:42
ttxok, great21:42
ttxdevcamcar: Anything else ?21:42
ttxQuestions on Horizon ?21:42
ttx"no question on the horizon"...21:42
anotherjessedevcamcar: event horizon = ?21:42
devcamcaranotherjesse: oh god, I didn't even make that connection21:43
anotherjessebackbone.js powered websocket + yagi21:43
anotherjessedashboard 5.321:43
devcamcaranotherjesse: patches welcome21:44
ttx#topic Incubated projects and other Team reports21:44
*** openstack changes topic to "Incubated projects and other Team reports"21:44
ttxdanwent: how is Quantum doing these days ?21:44
danwentgood.  slowing getting the dev wheels turning again after the summit21:44
danwent#link here is a wiki page with a rough plan for essex overall: http://wiki.openstack.org/QuantumEssexRoadmap21:44
ttxyes, it always takes a bit of time to recover21:44
danwent#info essex-1 milestone blueprints are filling in a bit slowly: https://launchpad.net/quantum/+milestone/essex-121:45
danwentWe have a couple reviews in for the Quantum network manager in nova, would be great to get help from network savvy nova core devs21:45
ttxvishy: you don't really have a network subteam, do you ?21:46
anotherjessearen't we all on vishy's subteams?21:46
danwentactually, i think they just created one with trey21:46
vishywe just created one21:46
ttxI'm so yesterday21:46
danwentI'll work with trey on those reviews21:46
danwentnothing much else to report, unless there are questions.21:46
ttxOther team leads with a status report ?21:47
ttxdoc/CI/QA ?21:47
ttxstable release ?21:47
annegentlenothing today, next Docs Team Meeting in November (14th) and watch for the time change Nov 6th.21:47
anotherjessedon't know if devstack is going to join CI or QA or … but we are hoping to get diablo "done" so we can move to essex … at which point we will start doing gerrit & lp instead of github issues/pull requests21:48
ttxyes we are entering DST fuzzy zone. Double check UTC time for all meetings21:48
*** dubsquared has quit IRC21:49
*** troytoman-away is now known as troytoman21:49
ttxEurope goes off DST on Oct 3021:49
ttxtopic Open discussion21:49
ttx#topic Open discussion21:49
*** cdub has joined #openstack-meeting21:49
*** openstack changes topic to "Open discussion"21:49
ttxAnything, anyone ?21:49
wwkeyboardWhat about the Melange/Nova merge thing?21:49
danwentthere are a couple pull requests at: https://github.com/rackspace/python-novaclient21:49
wwkeyboardis that still on?21:49
danwentwould be great if someone on that team could take a look.21:50
danwentor tell me a better place to push patches21:50
ttxvishy: did you rule on the Melange in/exclusion ?21:50
vishyttx: no i didn't21:50
vishyi was trying to find out the status of that today21:50
anotherjesseis troytoman around?21:50
annegentlehey I did want to remind nova core reviewers to also keep an eye on compute-api - Nati has some changes that need review.21:50
wwkeyboardThere is a merge request for the merge21:51
ttxvishy: feel free to abuse the open discussion for that.21:51
troytomanvishy: what was the melange question?21:51
vishytroytoman: where are we at with melange21:52
vishytroytoman: are we still trying to merge?21:52
pvodanwent: will get someone on the pull req21:52
troytomanvishy: yes. after talking with jaypipes we cut the merge prop into 3 phases to make it easier to review21:52
troytomanthe first one has been approved by jay but we need more to get it merged21:52
troytomanthen we can do the additional pieces21:53
vishytroytoman: ok if we are going that route21:53
vishyI will get the new nova-network team to take responsibility for getting it going21:53
vishybtw as an fyi21:54
vishyI'm marking all of the "good idea" blueprents as Undefined / New / Deferred21:55
*** debo_os has joined #openstack-meeting21:55
*** SumitNaiksatam has joined #openstack-meeting21:55
vishyso that is where to find the backlog21:56
ttxvishy: ++21:56
ttxvishy: so Melange will still be in Nova itself ?21:56
vishyyes sounds that way21:57
ttxvishy: should be your call, not someone else's :)21:57
troytomanvishy: since we haven't merged it, we don't have to do it that way21:57
troytomanbut based on initial input and the latest convo with jay that was the plan21:57
vishywe have to do one or the other21:57
troytomanif we want to do something else, i just want to know so we can have a clean path forward21:58
vishytroy, lets discuss this offline22:00
ttxvishy: if you don't feel strongly one wy or the other, raise an ML thread -- there is always someone feeling strongly about something somewhere :)22:00
ttxok, let's close this...22:00
*** edgarmagana has joined #openstack-meeting22:00
Vekno kidding :)22:00
vishyttx: we have just been discussing it for far too long22:00
vishyan ml thread will just go around and around again22:00
ttxvishy: yes, you even lost me :)22:00
ttxok, just decide then22:01
*** openstack changes topic to "Openstack Meetings: http://wiki.openstack.org/Meetings | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/"22:01
troytomanvishy: sure. ping me when you are ready22:01
openstackMeeting ended Tue Oct 25 22:01:21 2011 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)22:01
openstackMinutes:        http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-10-25-21.01.html22:01
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-10-25-21.01.txt22:01
openstackLog:            http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-10-25-21.01.log.html22:01
*** markmc has quit IRC22:01
danwentthanks ttx :)22:01
ttxdanwent: 5 seconds into the next hour, sorry22:01
*** Vek has left #openstack-meeting22:01
danwentok netstackers, let's get this started...22:01
openstackMeeting started Tue Oct 25 22:01:57 2011 UTC.  The chair is danwent. Information about MeetBot at http://wiki.debian.org/MeetBot.22:01
openstackUseful Commands: #action #agreed #help #info #idea #link #topic.22:01
*** jk0 has left #openstack-meeting22:02
*** rjh has quit IRC22:02
danwenteverybody here?22:02
bhallI am :)22:02
danwentsalv is out today22:02
edgarmaganaHello Everybody!22:02
danwentwell, i know troy is there, so let's start with melange22:03
danwent#topic melange status22:03
*** openstack changes topic to "melange status"22:03
*** liemmn has quit IRC22:03
danwent#info based on discussion in previous openstack team meeting, melange merge into nova is still waiting22:03
danwentmmm… maybe troy is not here.22:04
danwent#action #danwent contact troytoman about melange packaging22:04
danwentanything else that anyone has on melange?22:04
danwentjust in time :)22:04
troytomanmerge is still waiting. vishy and I are going to nail down the path forward22:05
*** Ravikumar_hp has quit IRC22:05
troytomani promised blueprints that are not done (mac address creation and /interfaces)22:05
troytomanthose are still in draft mode22:05
troytomanthat's it, i think22:05
danwentok, any questions for troy?22:05
danwenttroy, any comments on packaging?  my question above?22:05
danwentor does that depend on merging into nova?22:06
troytomanit may depend. sounds like they might revisit if melange should merge or be separate22:06
troytomanso it could impact packaging22:06
danwentok, i guess we'll wait until the dust settles there22:06
danwentok, sounds like we're good on melange22:06
danwent#topic quantum status22:06
*** openstack changes topic to "quantum status"22:06
danwentbtw, I forgot to post the agenda link earlier.22:07
danwent#link: agenda: http://wiki.openstack.org/Network/Meeting22:07
danwentessex-1 is only two weeks out22:07
danwentmilestone is looking a bit sparse in general: https://launchpad.net/quantum/+milestone/essex-122:07
*** robertn_ has joined #openstack-meeting22:08
danwentif there is anything (bug or feature) that you are targeting for this release, please target something to this milestone by thursday22:08
danwentany other updates on essex-1?22:08
edgarmaganadan: you mean this Thursday 27th?22:09
edgarmaganaor the next one?22:09
danwentedgar: by target I just meant create a blueprint or bug and associate it with the milestone.22:09
edgarmaganadan: got it22:09
danwentyes, the 27th, at least for any major work (i.e., work that will take a while to review or might disrupt other code)22:09
danwentif it is a small bug fix, it is fine to target it to a release later in the cycle22:10
danwentOk, want to cover the major reviews we have outstanding22:10
danwent#info review:  tyler just submitted the new quantum packaging for review.  this is a major change, so please look it over and make sure you are OK with it.22:10
danwentanyone have the link handy?22:11
bhalljust a sec22:11
markvoelkerThis one? https://review.openstack.org/109422:11
bhalldamn, beat me to it22:11
danwentpackaging is a really key deliverable for essex-1, so we want to get reviews on this quickly.22:11
danwent#info: review bhall also submitted DHCP changes for QuantumManager (this is also much of the code to get L3 routing + NAT working as well)22:12
danwentbrad, you have the link?22:12
bhallyup, sec22:12
*** renuka has quit IRC22:13
danwentI'm really hoping more quantum folks will get up to speed on the QuantumManager code, so it would be great to have people do a review, even if they aren't a nova core dev.22:13
danwentany other reviews outstanding?22:13
danwentOk, is Carl P here?22:14
danwentI don't see his handle...22:14
danwent#action #danwent contact Carl P about functional testing for essex-1, have him send to ML22:14
danwentanything else to report on packaging, other than the in progress review?22:15
*** johnpur has quit IRC22:15
markvoelkerNothing from me...22:15
bhalldanwent: one more review22:15
danwentbhall: please use info tag so it shows up in agenda22:15
bhall#info review on switching to update port/net calls: https://review.openstack.org/#change,92922:16
markvoelkerDoes that work if you're not the chair?22:16
danwentyes, I believe everything but "agreed" works even if you are not chair22:16
danwentso everyone should feel free to use "info" and "link"22:16
danwent#info from salvatore:  Operational status: spec published, received good feedback. Will update specification according to feedback received during this week.22:17
danwent#info: from salvatore: API framework: work in progress, and in good shape. I have now code that can run both v1.0 and v1.1 APIs. Unit tests pass (note: I’m running the whole set of API unit tests against both versions. This is a bit paranoid at the moment, but might come handy in the future)22:17
danwent#info: from salvatore:  Nova-network feature parity: willing to investigate what it will take to get to parity on AWS-style security groups. Posted a reply to Brad initial mail on the ML.22:17
danwentSalvatore is traveling, so please send any questions to ML22:17
danwentI want to try and draft a Quantum Essex roadmap so I could see everything in one place and think about dependencies22:18
danwent#link draft Quantum Essex Roadmap: http://wiki.openstack.org/QuantumEssexRoadmap22:18
danwentwe can definitely add/delete/modify, but I found it helpful to identify the different "chunks" we're working on for Essex.22:19
danwentparticuarly, I think we need to get people committed to milestones in a couple key areas:22:20
danwent1) nova-parity work for Quantum Manager22:20
danwent2) dashboard work22:20
danwent3) API work22:20
danwent4) functional / integration test22:20
danwentso I was thinking of trying to setup phone calls or meetings to make sure we get stuff nailed down.22:20
danwentRam and I already chatted on doing a whiteboard session for #1 to get his team more familiar with the QuantumManager stuff that Brad and I have been doing22:21
danwentMark, are you able to drive #2?22:21
danwentdoesn't seem over eager….22:22
danwentor he's not here :)22:22
markvoelkerSorry, getting pulled into multitasking =)22:22
*** jmeredit has joined #openstack-meeting22:22
markvoelkerI'm working on resource allocation this week, should have better answers soon.  But I think we'll be able to tackle it.22:23
danwentmark: just saying that I'd like to get a plan around dates + who is doing what for the dashboard22:23
danwentone of my goals is to get folks from different teams working on different parts of the code, so it definitely doesn't have to be all your team on the dashboard stuff, I'm just looking for you to drive the planning.22:23
somikfor dashboard: I received another volunteer willing to help out, I'll send your way once I know more22:23
markvoelkersomik: great, please do!22:24
danwentSalvatore can drive the API stuff, but we're also looking for someone else to participate on that end.  Please speak up if you're interested.  I know Ram mentioned there might be someone on his team interested.22:24
danwentAnd I will be bugging Carl P about the system/functional test.22:25
danwentMark: is there a cisco contact that you want as a driver on the system/functionanl test?22:25
markvoelkerHmm... how about CC myself and shwetap?22:25
danwentOk, I will let Carl know.22:26
danwentso expect emails from me in the next few days around how we can firm up plans in each of these areas.  Please look over the draft roadmap and give your thoughts.22:26
danwentany questions/comments on quantum before we go to open discussion?22:26
danwent#topic open discussion22:27
*** openstack changes topic to "open discussion"22:27
*** sifusam has quit IRC22:27
danwentjame urquhart had a good write-up on quantum this week: http://t.co/sqauRvpb22:27
danwentanything else?22:28
*** openstack changes topic to "Openstack Meetings: http://wiki.openstack.org/Meetings | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/"22:28
openstackMeeting ended Tue Oct 25 22:28:40 2011 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)22:28
openstackMinutes:        http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-10-25-22.01.html22:28
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-10-25-22.01.txt22:28
openstackLog:            http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-10-25-22.01.log.html22:28
danwentthanks folks!22:28
*** cdub has left #openstack-meeting22:29
danwenthave a good one22:29
*** cdub has joined #openstack-meeting22:29
*** Tushar has quit IRC22:30
*** danwent has left #openstack-meeting22:31
*** nati2 has joined #openstack-meeting22:31
*** debo_os has left #openstack-meeting22:32
*** debo_os has joined #openstack-meeting22:32
*** wwkeyboard has left #openstack-meeting22:32
*** SumitNaiksatam has left #openstack-meeting22:35
*** debo_os has quit IRC22:36
*** mcohen_ has joined #openstack-meeting22:42
*** anotherjesse has quit IRC22:42
*** rnirmal has quit IRC22:42
*** jmeredit has left #openstack-meeting22:44
*** mcohen has quit IRC22:44
*** mcohen_ is now known as mcohen22:44
*** danwent_ has joined #openstack-meeting22:44
*** danwent_ has quit IRC22:45
*** Gordonz_ has quit IRC22:51
*** Gordonz has joined #openstack-meeting22:52
*** bengrue has quit IRC22:56
*** ewanmellor has left #openstack-meeting22:58
*** troytoman is now known as troytoman-away22:58
*** zns has quit IRC23:00
*** Oneiroi has quit IRC23:01
*** blamar has quit IRC23:01
*** reed has quit IRC23:03
*** russellb has left #openstack-meeting23:06
*** reed has joined #openstack-meeting23:09
*** adjohn has quit IRC23:26
*** adjohn has joined #openstack-meeting23:26
*** mcohen has quit IRC23:27
*** mcohen has joined #openstack-meeting23:28
*** markvoelker has quit IRC23:34
*** adjohn has quit IRC23:35
*** adjohn has joined #openstack-meeting23:36
*** dendro-afk is now known as dendrobates23:46
*** mcohen has quit IRC23:56

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!