20:00:52 <jbryce> #startmeeting
20:00:53 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:00:55 <jbryce> all right, 2000 UTC, PPB roll call?
20:01:03 <mtaylor> o/
20:01:04 <notmyname> here
20:01:06 <jsavak> o/
20:01:13 <ewanmellor> Aiiight
20:01:13 <jsavak> (for zns)
20:02:14 <ttx> \o
20:02:43 <jbryce> jaypipes, pvo, vishy?
20:02:52 <pvo> here, sorry
20:03:00 <pvo> multitasking
20:03:44 <jbryce> we still need one more to have a quorum. we can wait a few minutes
20:04:08 <jbryce> troytoman: while we wait are you here as well?
20:04:31 <jaypipes> o/
20:04:39 * jaypipes mutters about daylight savings...
20:04:52 <pvo> jbryce: I don't think he is. I see his compute and he isn't sitting in front of it
20:04:55 <ttx> jaypipes: it hurts twice a year only :P
20:05:07 <jbryce> pvo: thanks
20:05:14 <jbryce> http://wiki.openstack.org/Governance/PPB - agenda
20:05:30 <jbryce> we have 2 items scheduled: the melange application and the client library discussion
20:05:50 <jbryce> with troy not around yet, we can start with client libraries and if he returns, discuss melange with him
20:06:02 <jbryce> #topic http://wiki.openstack.org/Governance/PPB#preview
20:06:07 <jbryce> #topic Policy around and management of client libraries
20:06:42 <jbryce> we've got a couple of different questions swirling around in the email thread that we probably need to look at
20:06:47 <ttx> The first step is to decide if we are even competent to discuss that issue, since some members disagree
20:06:55 <ttx> maybe start with mtaylor summary ?
20:07:08 <jbryce> works for me
20:07:17 <mtaylor> so - the basic summary is this
20:07:46 <mtaylor> 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 <mtaylor> to mitigate the potential explosion of PTLs, I was proposing that we manage them under the PTL of the associated project
20:08:21 <troytoman> o/ sorry - time change mishap
20:08:50 <mtaylor> but that we have them exist as top-level repos in our git/gerrit/jenkins setups
20:08:59 <ttx> 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 <mtaylor> the PTL discussion is actually secondary to the part I really care about
20:09:20 <ttx> (depending on how you view the change)
20:09:27 <mtaylor> well yeah
20:09:32 <notmyname> mtaylor: the point of this is because some of the (current?) gating requires the client libraries?
20:09:42 <mtaylor> notmyname: yes
20:10:05 <mtaylor> notmyname: and we already have issues with pip-requires between projects winding up pulling in entire projects (like glance)
20:10:23 <mtaylor> horizon needing glance is the thing that precipitated the conversation
20:10:32 <mtaylor> but the pattern of need isn't one that's unique there
20:10:47 <notmyname> 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 <ttx> 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 <mtaylor> we use novaclient and keystoneclient in integration testing
20:11:28 <mtaylor> 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 <mtaylor> ttx: glanceclient needs to be split from glance, which is a todo list item for jaypipes already
20:11:49 <mtaylor> ttx: keystoneclient exists already
20:11:55 <ttx> 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 <notmyname> 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 <ttx> keystoneclient exists inside keystone ? Or out ?
20:12:25 <notmyname> ttx: but it wouldn't be a new core project
20:12:46 <heckj> https://github.com/4P/python-keystoneclient
20:12:53 <notmyname> ttx: a client binding would still be part of its associate core project
20:12:54 <heckj> ttx: ^^
20:13:01 <mtaylor> 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 <jaypipes> 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 <ttx> notmyname: except from my point of view
20:13:22 <mtaylor> notmyname: but also it's the depends - such as nova depending on keystone and glance internally
20:13:28 <ttx> notmyname: for everyone else it's two separate projects (CI, relmgmt...)
20:14:00 <ttx> from the tools perspective it's two separate projects
20:14:06 <mtaylor> ttx: I'm (obviously) fine with considering it a single project for the purposes of openstack policy
20:14:52 <ttx> 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 <ttx> unindentified*
20:15:14 <ttx> 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 <mtaylor> ttx: that's just the thing though - we have real dependencies that we arent' admitting to at the moment
20:15:42 <ttx> 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 <notmyname> 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 <mtaylor> ttx: then I am proposing the addition of four core projects
20:16:18 <mtaylor> ttx: and I am requesting a policy exemption to add them as part of this cycle
20:16:19 <jaypipes> notmyname: sure, you're right. sorry for polluting the conversation :)
20:16:41 <mtaylor> ttx: because I believe organizationally they are already unrecognized core projects
20:17:05 <notmyname> isn't the policy that there is one project ("nova") that provides 2 things ("nova" and "nova-client")?
20:17:21 <mtaylor> OR - that we do that ^^
20:17:34 <jaypipes> don't we already do that?
20:17:38 <ttx> mtaylor: I can align with that. And you can also rule that client projects can share teams with another project
20:18:07 <ttx> notmyname: Where can I query that magic relationship ?
20:18:34 <jaypipes> 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 <mtaylor> I think it's because the separate source repos idea is triggering a thought that now there are new core projects
20:19:02 <ttx> 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 <mtaylor> whereas if these were contained in a single repo it would be different from a governance perspective
20:19:23 <ttx> I find that confusing that what we call core project depends on who is using the term
20:19:31 <ttx> so far we had a single list and definition.
20:20:13 <mtaylor> 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 <ttx> "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 <mtaylor> _0x44: I think ttx is caring less about repos and more about release artifacts?
20:21:14 <ttx> _0x44: because they are 1:1 linked to LP projects and to a release deliverable
20:21:30 <notmyname> 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 <ttx> mtaylor: actually, I care about being consistent.
20:22:05 <mtaylor> it's certainly not required ... we could tie python-novaclient to the nova project on launchpad and track bugs there
20:22:08 <ttx> notmyname: If we don't do 1:1 then the client project and main project share the same bug DB
20:22:16 <ttx> 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 <mtaylor> ttx: would that make the distinction easier from your end?
20:22:33 <ttx> Same project means same blueprint set, same bug database
20:22:40 <mtaylor> _0x44: no, of course not
20:22:43 <ttx> _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 <mtaylor> _0x44: nouns are tricky :)
20:23:23 <ttx> could be the same project pointing to two repos.
20:23:31 <ttx> I'm fine with that. That would still be consistent
20:23:50 <ttx> *But* that means sharing the same set of BP and bugs. Everyone fine with that ?
20:23:56 <mtaylor> I'm fine with that
20:23:59 <jaypipes> me too.
20:24:22 <ttx> mtaylor: that means adding some mapping on the bugclosing magic on Gerrit
20:24:26 <notmyname> 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 <jbryce> 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 <ttx> 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 <mtaylor> 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 <ttx> sure
20:26:03 <ttx> We need to discuss Melange
20:26:21 <jbryce> mtaylor: +1
20:26:32 <jbryce> does everyone else agree? i will follow up with vish directly
20:26:37 <notmyname> mtaylor: what about requirements for the separate bindings?
20:26:47 <notmyname> is that something that the PPB will mandate for the core projects?
20:26:59 <ttx> Also does the PPB need to be consulted to add new code repos (or modules) under an existing core project ?
20:27:11 <notmyname> ttx: seems that would be up to the PTL
20:27:17 <mtaylor> ++
20:27:24 <mtaylor> sorry, that was vague
20:27:25 <ttx> mtaylor: ++ to what ?
20:27:31 <mtaylor> I ++'d what notmyname said about the PTL
20:27:41 <jbryce> i think if we are treating it as part of the project it's up to the ptl
20:27:42 <mtaylor> notmyname: I'm not sure about mandating it
20:27:44 <ttx> I think the PPB should be consulted for project scope expansion
20:27:48 <jbryce> and in terms of mandating, how does that work for dashboard?
20:27:58 <notmyname> PTLs are supposed to manage all of the technical details of the project. that seems to include client libraries and dependencies
20:28:01 <mtaylor> notmyname: how about we leave that bit up to ptl's until it's a problem?
20:28:33 <ttx> 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 <jbryce> 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 <ttx> For example, client libs would obviously be ok -- just keep us informed when you do one
20:29:15 <notmyname> ttx: is adding a client binding adding scope?
20:29:19 <notmyname> ah
20:29:42 <jbryce> let's get to melange
20:29:44 <ttx> 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 <mtaylor> 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 <ttx> notmyname: like doing a web UI.
20:30:06 <mtaylor> 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 <jbryce> ttx: i agree with that
20:30:28 <ttx> mtaylor: I think that's a headache. We can discuss that more tomorrow
20:30:33 <mtaylor> ttx: ok
20:30:41 <mtaylor> I think we're good on this one, yeah?
20:30:52 <jbryce> #topic melange incubation
20:30:55 <jbryce> http://wiki.openstack.org/Projects/IncubatorApplication/Melange - application
20:31:34 <troytoman> I am requesting that we establish Melange as an incubated project
20:31:54 <troytoman> Melange was identified as a need as part of the Netstack discussions at the Diablo summit
20:32:16 <troytoman> Based on some discussion there, we were requested to try and do it within Nova
20:32:30 <troytoman> But, that has proven to be a bad model, i think, on a number of fronts
20:33:06 <notmyname> troytoman: please explain why it's bad
20:33:10 <troytoman> After discussions with a number of folks including vishy, jaypipes and others, incubation makes more sense
20:33:52 <troytoman> notmyname: we have had difficulty getting the attention of core devs for reviews
20:34:10 <troytoman> notmyname: packaging/testing/ci has also been complicated
20:34:43 <troytoman> the eventual goal is for Melange to provide IPAM and other information across multiple services (servers, firewall, LB, etc,)
20:34:57 <troytoman> it's hard to fit that idea into a Nova project
20:35:01 <troytoman> those are a few
20:35:25 <notmyname> 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 <mtaylor> I think he'd still have a problem with the core team reviewers being not the melange team
20:36:11 <ttx> troytoman: wasn't the main motivator the fact that you have your own API ?
20:36:14 <troytoman> i don't think it solves the problem that Melange intends to be a service easily accessible to more projects
20:36:24 <troytoman> ttx: that was definitely another element
20:36:37 <ttx> ISTR vishy mentioning that as the key reason
20:36:48 <ttx> separate user-facing API
20:37:03 <troytoman> ttx: yes. that was one of his biggest concerns
20:37:09 <mtaylor> separate user-facing API sounds like a whole separate thing to me
20:37:30 <ttx> mtaylor: could even be the definition of where the "project" boundary stops :)
20:37:41 <mtaylor> troytoman: (could you please split off a python-melangeclient repo :) )
20:37:43 <mtaylor> ttx: ++
20:37:58 <troytoman> mtaylor: hehe
20:38:06 <jbryce> 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 <notmyname> mtaylor: ttx: that gets tricky, though. arguably, the server and a client binding expose different APIs /devilsadvocate
20:38:26 <ttx> I'm all for having Melange incubated, since Quantum depends on it and is in incubation.
20:38:41 <mtaylor> notmyname: heh. one exposes, the other implements? same API?
20:38:50 <troytoman> in actively participating in both Melange and Quantum projects, i think Quantum represents a much better model for Melange
20:38:59 <ttx> ..and we almost had it in Nova for Diablo, so I guess the scope issue is solved
20:39:02 <notmyname> ttx: quantum is incubated?
20:39:10 <notmyname> when did that happen?
20:39:19 <mtaylor> notmyname: a while ago?
20:39:29 <ttx> notmyname: let me find that for you
20:39:35 <jbryce> notmyname: before the diablo release
20:39:41 <troytoman> I think that was in late aug/early sep
20:39:58 <notmyname> hmmm...must have missed that. I thought all of the incubated projects had been promoted (dashboard and keystone)
20:40:16 <ttx> nope, Quantum was inclubated at around the same time as core promotion for the others
20:40:19 <mtaylor> notmyname: I think it was decided to add it as incubated for the essex cycle
20:40:57 <ttx> For reference: http://wiki.openstack.org/Projects
20:41:06 * ttx tries to find the right meeting logs
20:41:20 <notmyname> ttx: no worries
20:41:21 <jaypipes> let's get back to Melange...
20:41:22 <jbryce> 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 <jbryce> troytoman: do you feel like the melange team will be able to do that?
20:41:35 <mtaylor> jbryce: ++
20:41:36 <jaypipes> jbryce: ++
20:41:43 <dolphm_> jbryce: ++
20:41:56 <troytoman> jbryce: definitely. we were already tracking to Nova cycles
20:41:59 <ttx> A bit difficult sonce jbryce did not archive all the logs: jbryce-- :)
20:42:09 <troytoman> we have some work to do to setup the project structure, etc. but that is all doable
20:42:24 <jbryce> ttx: sorry, i try to do it, but i'm sure i've missed a few
20:42:34 <troytoman> we will need to stay close to both Quantum and Nova
20:42:40 <mtaylor> troytoman: well, you get help from me on that when you become incubated :)
20:42:50 <jbryce> 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 <ttx> notmyname: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-08-23-20.04.html
20:43:14 <troytoman> jbryce: that should not be a problem
20:43:29 <troytoman> we have a working Melange/Quantum/Nova implementation now
20:43:39 <ttx> notmyname: you voted against it :)
20:43:45 <notmyname> ttx: heh
20:43:59 <ttx> then suppressed it from your memory.
20:44:26 <jaypipes> are we ready to vote on incubation for Melange then?
20:44:28 <jbryce> troytoman: who is the core team. are all of the developers listed in the incubation application core?
20:44:56 <troytoman> yes. although I would like to recruit some non-rackspace/thoughtworks devs to the project.
20:45:06 <jbryce> yes...i think that should definitely be a goal
20:45:15 <jaypipes> ++
20:45:17 <jbryce> something else that i think we learned from the previous incubation cycles
20:45:21 <notmyname> troytoman: so melange is a software service? like a combo dns/dhcp server?
20:45:27 <troytoman> i am hoping that the visibility will help get more people involved
20:45:39 <ttx> troytoman: amen
20:45:44 <notmyname> troytoman: obviously more than that. just trying to get my head around it
20:46:06 <ewanmellor> Devils advocate: Why not put Melange functionality in with Quantum, and have one NaaS project?
20:46:12 <troytoman> notmyname: it is primarily a network information service. central resource for IP/MAC/routes/DNS info
20:46:42 <notmyname> 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 <notmyname> ewanmellor: good question
20:47:29 <troytoman> notmyname: correct
20:47:31 <mtaylor> troytoman: is it similar in scope to a thing like ocsinventory at all?
20:47:51 <troytoman> mtaylor: sorry but I'm not familiar with ocsinventory
20:48:13 <ttx> mtaylor: I don't think it is
20:48:25 <troytoman> after a quick look, i don't think so.
20:48:46 <mtaylor> 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 <notmyname> 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 <ttx> mtaylor: OCSinventory is hardware inventory, not a network resource repo
20:48:50 <mtaylor> troytoman: cool.
20:49:01 <mtaylor> ttx: GOTCHA
20:49:08 <troytoman> notmyname: think IP Commander for OpenStack if that helps at all
20:49:34 <ttx> troytoman: could you answer <ewanmellor> Devils advocate: Why not put Melange functionality in with Quantum, and have one NaaS project?
20:49:44 <ttx> after that I'll be ready to vote :)
20:50:17 <troytoman> 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 <ttx> troytoman: I think it warranst two projects if oen can be used without the other, I guess
20:51:15 <ttx> in this case I suspect Melange could be used without Quantum ?
20:51:23 <troytoman> ttx: I think that is something we will learn as these projects evolve.
20:51:45 <troytoman> ttx: you certainly can, i'm not sure how often it will.
20:51:54 <wwkeyboard> 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 <ttx> I'm all for having them in incubation and see how they evolve.
20:52:40 <ttx> jbryce: I guess we can vote ?
20:52:52 <jbryce> i'm having some network problems
20:53:10 <notmyname> jbryce: perhaps you need a NaaS
20:53:16 <mtaylor> ++
20:53:16 <ttx> happends to the best of us.
20:53:17 <jbryce> hehe
20:53:59 <jbryce> 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 <notmyname> indeed
20:54:42 <troytoman> 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 <ttx> yeah, the PTL are expected to be quite available on IRC
20:54:50 <troytoman> but I think I will be able to cover it.
20:55:06 <ttx> for cross-team communication
20:55:12 <jbryce> any other questions from anyone?
20:55:52 <jbryce> #info VOTE: Should the Melange project be added as an Incubated project with Troy Toman as PTL?
20:56:01 <pvo> +1
20:56:06 <ewanmellor> +1
20:56:14 <ttx> +1
20:56:16 <mtaylor> +1
20:56:27 <jbryce> +1
20:56:29 <notmyname> +0
20:56:34 <jaypipes> +1
20:56:49 <ttx> notmyname: you say you don't like being different, but you are !
20:57:01 <notmyname> webx:
20:57:04 <notmyname> heh
20:57:17 <jbryce> #agreed Melange should be added as an incubated project (6 agree, 1 abstain)
20:57:28 <troytoman> thanks all
20:57:41 <mtaylor> 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 <jaypipes> troytoman: congrats and condolences
20:57:47 * ttx wil modify wiki.openstack.org/Projects
20:57:49 <mtaylor> troytoman: ++
20:58:09 <troytoman> jaypipes: :-)
20:58:15 <ttx> troytoman: whenever https://launchpad.net/melange is set up
20:58:23 <troytoman> thanks ttx
20:58:28 * mtaylor may have spent too much time in poly-sci class growing up
20:58:33 <troytoman> now the real work begins
20:58:53 <vishy> hmm
20:58:53 <mtaylor> troytoman: let's circle up with jeblair and come up with a time to get you migrated to gerrit
20:58:58 <mtaylor> vishy: !!!
20:58:59 <jbryce> hi vishy
20:59:06 <ttx> mtaylor: and get the LP project set up
20:59:09 * vishy forgot time change doesn't affect utc
20:59:11 <mtaylor> vishy: we missed you
20:59:12 <jbryce> vishy: anything you'd like to say in the last 40 seconds?
20:59:19 <vishy> +1 to everything
20:59:27 * ttx sobs at the number of early warnings he sent for nothing
20:59:48 <jbryce> vishy: i need to catch up with you on something real quick, but we're out of time for ppb
20:59:52 <jbryce> thanks everyone
21:00:14 <jbryce> #endmeeting