20:00:52 #startmeeting 20:00:53 Meeting started Tue Nov 8 20:00:52 2011 UTC. The chair is jbryce. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:54 Useful Commands: #action #agreed #help #info #idea #link #topic. 20:00:55 all right, 2000 UTC, PPB roll call? 20:01:03 o/ 20:01:04 here 20:01:06 o/ 20:01:13 Aiiight 20:01:13 (for zns) 20:02:14 \o 20:02:43 jaypipes, pvo, vishy? 20:02:52 here, sorry 20:03:00 multitasking 20:03:44 we still need one more to have a quorum. we can wait a few minutes 20:04:08 troytoman: while we wait are you here as well? 20:04:31 o/ 20:04:39 * jaypipes mutters about daylight savings... 20:04:52 jbryce: I don't think he is. I see his compute and he isn't sitting in front of it 20:04:55 jaypipes: it hurts twice a year only :P 20:05:07 pvo: thanks 20:05:14 http://wiki.openstack.org/Governance/PPB - agenda 20:05:30 we have 2 items scheduled: the melange application and the client library discussion 20:05:50 with troy not around yet, we can start with client libraries and if he returns, discuss melange with him 20:06:02 #topic http://wiki.openstack.org/Governance/PPB#preview 20:06:07 #topic Policy around and management of client libraries 20:06:42 we've got a couple of different questions swirling around in the email thread that we probably need to look at 20:06:47 The first step is to decide if we are even competent to discuss that issue, since some members disagree 20:06:55 maybe start with mtaylor summary ? 20:07:08 works for me 20:07:17 so - the basic summary is this 20:07:46 I'm proposing that we keep client libs separated as they are now, and that we pull them in as official things that we manage 20:08:20 to mitigate the potential explosion of PTLs, I was proposing that we manage them under the PTL of the associated project 20:08:21 o/ sorry - time change mishap 20:08:50 but that we have them exist as top-level repos in our git/gerrit/jenkins setups 20:08:59 My opinion is that the PPB is legitimate to discuss the issue, since it either adds core projects, or expands their scope significantly to include previously non-core projects. 20:09:03 the PTL discussion is actually secondary to the part I really care about 20:09:20 (depending on how you view the change) 20:09:27 well yeah 20:09:32 mtaylor: the point of this is because some of the (current?) gating requires the client libraries? 20:09:42 notmyname: yes 20:10:05 notmyname: and we already have issues with pip-requires between projects winding up pulling in entire projects (like glance) 20:10:23 horizon needing glance is the thing that precipitated the conversation 20:10:32 but the pattern of need isn't one that's unique there 20:10:47 mtaylor: I understand the dependency problem (and am generally supportive of separate client bindings). but I'm not really a big fan of making those part of the gating (my opinion) 20:10:49 mtaylor: I'm familiar with the python-novaclient situation (separate project that would be added as new core project), what's the status of the others ? 20:10:49 we use novaclient and keystoneclient in integration testing 20:11:28 notmyname: it's mainly just that they already are part of projects that are gating, so figuring out how to manage them sanely 20:11:41 ttx: glanceclient needs to be split from glance, which is a todo list item for jaypipes already 20:11:49 ttx: keystoneclient exists already 20:11:55 Basically I'm against adding new core projects in the middle of a cycle. We already decided against that. If it's just novaclient brought in and a few package splits, I think that's ok 20:12:14 mtaylor: ya I get that. seems to be that the gating should be as low-level as possible (ie using http directly instead of a client library that adds complexity and its own bugs) 20:12:25 keystoneclient exists inside keystone ? Or out ? 20:12:25 ttx: but it wouldn't be a new core project 20:12:46 https://github.com/4P/python-keystoneclient 20:12:53 ttx: a client binding would still be part of its associate core project 20:12:54 ttx: ^^ 20:13:01 notmyname: yeah, I hear you - I think that the integratoin testss folks decided to do both straight http and use the client libs 20:13:02 notmyname: if project A depends on the client library of project B, then project A's trunk should be gated on changes to the client library for project B. IMHO... 20:13:10 notmyname: except from my point of view 20:13:22 notmyname: but also it's the depends - such as nova depending on keystone and glance internally 20:13:28 notmyname: for everyone else it's two separate projects (CI, relmgmt...) 20:14:00 from the tools perspective it's two separate projects 20:14:06 ttx: I'm (obviously) fine with considering it a single project for the purposes of openstack policy 20:14:52 mtaylor: then it introduces confusion. One project "for purposes of openstack policy" covers an identified number of real projects as far as tooling is concerned 20:14:59 unindentified* 20:15:14 mtaylor: where do you track the link between the two ? 20:15:14 * jaypipes would like to see the client library projects named after the API, not the reference implementation... i.e. openstack-images-client instead of glance-client. 20:15:17 ttx: that's just the thing though - we have real dependencies that we arent' admitting to at the moment 20:15:42 At this point it's rather simple: you have a list of core projects, that's what I need to care about 20:15:52 jaypipes: that gets into a different conversation (that we should have at a later date) on whether the project is the API or the API + implementation 20:16:05 ttx: then I am proposing the addition of four core projects 20:16:18 ttx: and I am requesting a policy exemption to add them as part of this cycle 20:16:19 notmyname: sure, you're right. sorry for polluting the conversation :) 20:16:41 ttx: because I believe organizationally they are already unrecognized core projects 20:17:05 isn't the policy that there is one project ("nova") that provides 2 things ("nova" and "nova-client")? 20:17:21 OR - that we do that ^^ 20:17:34 don't we already do that? 20:17:38 mtaylor: I can align with that. And you can also rule that client projects can share teams with another project 20:18:07 notmyname: Where can I query that magic relationship ? 20:18:34 I thought this was primarily a discussion about how to do the packaging and release management for things that are in separate source repos, not whether a "project" is the combination of a server and a client lib? 20:19:01 I think it's because the separate source repos idea is triggering a thought that now there are new core projects 20:19:02 You're telling me that the core project list doesn't change -- however in all the tools I have to change CORE_PROJECTS to add new projects names. 20:19:21 whereas if these were contained in a single repo it would be different from a governance perspective 20:19:23 I find that confusing that what we call core project depends on who is using the term 20:19:31 so far we had a single list and definition. 20:20:13 I'm personally fine with just adding them as core projects ... the project sharing part was just for expediency (an attempt to make things easier - silly me) 20:20:25 "projects that gets released in the common openstack release every 6 months" 20:20:44 <_0x44> ttx: Why were the repos called projects? 20:21:11 _0x44: I think ttx is caring less about repos and more about release artifacts? 20:21:14 _0x44: because they are 1:1 linked to LP projects and to a release deliverable 20:21:30 but why is there the 1:1 mapping? 20:21:38 * mtaylor should avoid attempting to speak for other people 20:21:40 <_0x44> notmyname: +1 20:21:49 mtaylor: actually, I care about being consistent. 20:22:05 it's certainly not required ... we could tie python-novaclient to the nova project on launchpad and track bugs there 20:22:08 notmyname: If we don't do 1:1 then the client project and main project share the same bug DB 20:22:16 We could do that. 20:22:29 <_0x44> ttx: You're telling me launchpad can't handle multiple code repositories per project? 20:22:30 ttx: would that make the distinction easier from your end? 20:22:33 Same project means same blueprint set, same bug database 20:22:40 _0x44: no, of course not 20:22:43 _0x44: it can. 20:22:59 <_0x44> mtaylor: Then we've obviously chosen the wrong set of nouns to refer to the governance projects. 20:23:15 _0x44: nouns are tricky :) 20:23:23 could be the same project pointing to two repos. 20:23:31 I'm fine with that. That would still be consistent 20:23:50 *But* that means sharing the same set of BP and bugs. Everyone fine with that ? 20:23:56 I'm fine with that 20:23:59 me too. 20:24:22 mtaylor: that means adding some mapping on the bugclosing magic on Gerrit 20:24:26 ttx: I think that's less than ideal, but it can work. I've found benefit on the RAX-specific side to manage language bindings separately from swift (or cloud files stuff) 20:24:51 i'm fine with that, but i'd love to get vishy's input on this before we make the final call 20:25:26 The "correct" way of doing that would be to create a nova project group in LP, and projects benath that -- but I don't think it's worth all the tropuble of changing 20:25:52 I'm ok waiting for vish ... can we say that it's ok pending vishy's input so that we don't have to put off dealing with it from a technical perspective until next ppb meeting? 20:25:56 sure 20:26:03 We need to discuss Melange 20:26:21 mtaylor: +1 20:26:32 does everyone else agree? i will follow up with vish directly 20:26:37 mtaylor: what about requirements for the separate bindings? 20:26:47 is that something that the PPB will mandate for the core projects? 20:26:59 Also does the PPB need to be consulted to add new code repos (or modules) under an existing core project ? 20:27:11 ttx: seems that would be up to the PTL 20:27:17 ++ 20:27:24 sorry, that was vague 20:27:25 mtaylor: ++ to what ? 20:27:31 I ++'d what notmyname said about the PTL 20:27:41 i think if we are treating it as part of the project it's up to the ptl 20:27:42 notmyname: I'm not sure about mandating it 20:27:44 I think the PPB should be consulted for project scope expansion 20:27:48 and in terms of mandating, how does that work for dashboard? 20:27:58 PTLs are supposed to manage all of the technical details of the project. that seems to include client libraries and dependencies 20:28:01 notmyname: how about we leave that bit up to ptl's until it's a problem? 20:28:33 notmyname: I agree with you, as long as you don't suddenly expand your scope -- I'm all for letting you do it and solve it at PPB level if it becomes an issue 20:29:02 ttx: i think we can say that client libraries are acceptable to expand to within a project with having to get involved in each project 20:29:10 For example, client libs would obviously be ok -- just keep us informed when you do one 20:29:15 ttx: is adding a client binding adding scope? 20:29:19 ah 20:29:42 let's get to melange 20:29:44 notmyname: I think we can say: do whatever you want, and the PPB will hunt you down if you abuse that freedom 20:29:52 like, client bindings are obviously ok - but if nova wanted to suddenly add DBaaS as a "sub project" ... that might be a bit much :) 20:29:59 notmyname: like doing a web UI. 20:30:06 ttx: you want me to ask lp losa's if we can get project group set up and get project and client lib into the project group without causing too much of a headache? or do you want just just skip it? 20:30:07 ttx: i agree with that 20:30:28 mtaylor: I think that's a headache. We can discuss that more tomorrow 20:30:33 ttx: ok 20:30:41 I think we're good on this one, yeah? 20:30:52 #topic melange incubation 20:30:55 http://wiki.openstack.org/Projects/IncubatorApplication/Melange - application 20:31:34 I am requesting that we establish Melange as an incubated project 20:31:54 Melange was identified as a need as part of the Netstack discussions at the Diablo summit 20:32:16 Based on some discussion there, we were requested to try and do it within Nova 20:32:30 But, that has proven to be a bad model, i think, on a number of fronts 20:33:06 troytoman: please explain why it's bad 20:33:10 After discussions with a number of folks including vishy, jaypipes and others, incubation makes more sense 20:33:52 notmyname: we have had difficulty getting the attention of core devs for reviews 20:34:10 notmyname: packaging/testing/ci has also been complicated 20:34:43 the eventual goal is for Melange to provide IPAM and other information across multiple services (servers, firewall, LB, etc,) 20:34:57 it's hard to fit that idea into a Nova project 20:35:01 those are a few 20:35:25 troytoman: does our previous discussion on client bindings change either of the first 2? (the possible change to allow a 1:* mapping of core project to deliverables) 20:36:04 I think he'd still have a problem with the core team reviewers being not the melange team 20:36:11 troytoman: wasn't the main motivator the fact that you have your own API ? 20:36:14 i don't think it solves the problem that Melange intends to be a service easily accessible to more projects 20:36:24 ttx: that was definitely another element 20:36:37 ISTR vishy mentioning that as the key reason 20:36:48 separate user-facing API 20:37:03 ttx: yes. that was one of his biggest concerns 20:37:09 separate user-facing API sounds like a whole separate thing to me 20:37:30 mtaylor: could even be the definition of where the "project" boundary stops :) 20:37:41 troytoman: (could you please split off a python-melangeclient repo :) ) 20:37:43 ttx: ++ 20:37:58 mtaylor: hehe 20:38:06 it makes sense to me as a separate project like quantum does where we want to enable a more generic service rather than something that is just specific to getting traffic in and our of vms 20:38:17 mtaylor: ttx: that gets tricky, though. arguably, the server and a client binding expose different APIs /devilsadvocate 20:38:26 I'm all for having Melange incubated, since Quantum depends on it and is in incubation. 20:38:41 notmyname: heh. one exposes, the other implements? same API? 20:38:50 in actively participating in both Melange and Quantum projects, i think Quantum represents a much better model for Melange 20:38:59 ..and we almost had it in Nova for Diablo, so I guess the scope issue is solved 20:39:02 ttx: quantum is incubated? 20:39:10 when did that happen? 20:39:19 notmyname: a while ago? 20:39:29 notmyname: let me find that for you 20:39:35 notmyname: before the diablo release 20:39:41 I think that was in late aug/early sep 20:39:58 hmmm...must have missed that. I thought all of the incubated projects had been promoted (dashboard and keystone) 20:40:16 nope, Quantum was inclubated at around the same time as core promotion for the others 20:40:19 notmyname: I think it was decided to add it as incubated for the essex cycle 20:40:57 For reference: http://wiki.openstack.org/Projects 20:41:06 * ttx tries to find the right meeting logs 20:41:20 ttx: no worries 20:41:21 let's get back to Melange... 20:41:22 one of the things i think we learned in diablo with keystone is that incubated projects should probably follow the core release cycle more closely 20:41:32 troytoman: do you feel like the melange team will be able to do that? 20:41:35 jbryce: ++ 20:41:36 jbryce: ++ 20:41:43 jbryce: ++ 20:41:56 jbryce: definitely. we were already tracking to Nova cycles 20:41:59 A bit difficult sonce jbryce did not archive all the logs: jbryce-- :) 20:42:09 we have some work to do to setup the project structure, etc. but that is all doable 20:42:24 ttx: sorry, i try to do it, but i'm sure i've missed a few 20:42:34 we will need to stay close to both Quantum and Nova 20:42:40 troytoman: well, you get help from me on that when you become incubated :) 20:42:50 troytoman: i think the biggest thing is that there will probably be an expectation around essex release time that there will be a melange release as well 20:43:09 notmyname: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-08-23-20.04.html 20:43:14 jbryce: that should not be a problem 20:43:29 we have a working Melange/Quantum/Nova implementation now 20:43:39 notmyname: you voted against it :) 20:43:45 ttx: heh 20:43:59 then suppressed it from your memory. 20:44:26 are we ready to vote on incubation for Melange then? 20:44:28 troytoman: who is the core team. are all of the developers listed in the incubation application core? 20:44:56 yes. although I would like to recruit some non-rackspace/thoughtworks devs to the project. 20:45:06 yes...i think that should definitely be a goal 20:45:15 ++ 20:45:17 something else that i think we learned from the previous incubation cycles 20:45:21 troytoman: so melange is a software service? like a combo dns/dhcp server? 20:45:27 i am hoping that the visibility will help get more people involved 20:45:39 troytoman: amen 20:45:44 troytoman: obviously more than that. just trying to get my head around it 20:46:06 Devils advocate: Why not put Melange functionality in with Quantum, and have one NaaS project? 20:46:12 notmyname: it is primarily a network information service. central resource for IP/MAC/routes/DNS info 20:46:42 troytoman: so it isn't a dns/etc server, but it manages the metadata for one? or the data about what is configured? 20:46:57 ewanmellor: good question 20:47:29 notmyname: correct 20:47:31 troytoman: is it similar in scope to a thing like ocsinventory at all? 20:47:51 mtaylor: sorry but I'm not familiar with ocsinventory 20:48:13 mtaylor: I don't think it is 20:48:25 after a quick look, i don't think so. 20:48:46 ttx: ok. (I was wondering if it might make sense to point the canonical guys who were going to extend cobbler to look at melange) 20:48:47 troytoman: I may need to talk more about it with you in person, but the usefulness of that doesn't seem to jump out at me (my ignorance, I'm sure) 20:48:49 mtaylor: OCSinventory is hardware inventory, not a network resource repo 20:48:50 troytoman: cool. 20:49:01 ttx: GOTCHA 20:49:08 notmyname: think IP Commander for OpenStack if that helps at all 20:49:34 troytoman: could you answer Devils advocate: Why not put Melange functionality in with Quantum, and have one NaaS project? 20:49:44 after that I'll be ready to vote :) 20:50:17 ttx: I think that is an idea worth exploring personally. I know that danwendt has been pretty strong in his position that Quantum should just be network segments. 20:50:39 troytoman: I think it warranst two projects if oen can be used without the other, I guess 20:51:15 in this case I suspect Melange could be used without Quantum ? 20:51:23 ttx: I think that is something we will learn as these projects evolve. 20:51:45 ttx: you certainly can, i'm not sure how often it will. 20:51:54 troytoman: ttx: I think one of the big worries is being able to change layer 2 manager without changing the layer 3 manager 20:52:13 I'm all for having them in incubation and see how they evolve. 20:52:40 jbryce: I guess we can vote ? 20:52:52 i'm having some network problems 20:53:10 jbryce: perhaps you need a NaaS 20:53:16 ++ 20:53:16 happends to the best of us. 20:53:17 hehe 20:53:59 troytoman: do you feel like you're going to be able to dedicate enough of your time as ptl? i think something else we've realized is that it can be pretty time consuming 20:54:21 indeed 20:54:42 jbryce: I believe so. I have essentially been in that role since May. there will be some extra demands as we try and grow the team. 20:54:47 yeah, the PTL are expected to be quite available on IRC 20:54:50 but I think I will be able to cover it. 20:55:06 for cross-team communication 20:55:12 any other questions from anyone? 20:55:52 #info VOTE: Should the Melange project be added as an Incubated project with Troy Toman as PTL? 20:56:01 +1 20:56:06 +1 20:56:14 +1 20:56:16 +1 20:56:27 +1 20:56:29 +0 20:56:34 +1 20:56:49 notmyname: you say you don't like being different, but you are ! 20:57:01 webx: 20:57:04 heh 20:57:17 #agreed Melange should be added as an incubated project (6 agree, 1 abstain) 20:57:28 thanks all 20:57:41 perhaps we should express the number of PPB at-large members in terms of a percentage of extant PTLs, rather than as a fixed number? 20:57:41 troytoman: congrats and condolences 20:57:47 * ttx wil modify wiki.openstack.org/Projects 20:57:49 troytoman: ++ 20:58:09 jaypipes: :-) 20:58:15 troytoman: whenever https://launchpad.net/melange is set up 20:58:23 thanks ttx 20:58:28 * mtaylor may have spent too much time in poly-sci class growing up 20:58:33 now the real work begins 20:58:53 hmm 20:58:53 troytoman: let's circle up with jeblair and come up with a time to get you migrated to gerrit 20:58:58 vishy: !!! 20:58:59 hi vishy 20:59:06 mtaylor: and get the LP project set up 20:59:09 * vishy forgot time change doesn't affect utc 20:59:11 vishy: we missed you 20:59:12 vishy: anything you'd like to say in the last 40 seconds? 20:59:19 +1 to everything 20:59:27 * ttx sobs at the number of early warnings he sent for nothing 20:59:48 vishy: i need to catch up with you on something real quick, but we're out of time for ppb 20:59:52 thanks everyone 21:00:14 #endmeeting