20:02:27 <ttx> #startmeeting tc
20:02:28 <openstack> Meeting started Tue Mar 31 20:02:27 2015 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:02:29 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:32 <openstack> The meeting name has been set to 'tc'
20:02:34 <mikal> Hi
20:02:39 <mordred> hi mikal
20:02:41 <ttx> Our agenda for today:
20:02:47 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:03:06 <ttx> #topic Final rubberstamp on "Add library stable release procedures/policy"
20:03:09 <ttx> #link https://review.openstack.org/#/c/155072/
20:03:21 <jaypipes> o/
20:03:22 <ttx> OK, I think it's time to approve it now, unless someone objects.
20:03:29 <ttx> It's short of one vote but there are no objections, and we had the same discussion last week
20:03:41 <ttx> so I'll count that as "consensus"
20:03:57 <mordred> do it
20:04:08 <ttx> done
20:04:14 <ttx> Doug will be happy
20:04:23 <ttx> #topic Add the Congress project
20:04:30 <ttx> #link https://review.openstack.org/165204
20:04:34 <ttx> Big tent, level 3
20:04:43 <mikal> I just -1'ed that one if you need to refresh your gerrit tab
20:05:18 <vishy> you got my vote so that should be enough
20:05:56 <ttx> Got some nework issues right now, please discuss without waiting for me
20:06:01 <mordred> sarob: you still working on this?
20:06:08 <mikal> Ok, shall we talk about my -1 then?
20:06:16 <sarob> Yup
20:06:21 <sarob> My patch
20:06:32 <mikal> So, sarob just replied to my comment (I assume)
20:06:33 <jeblair> mikal: i don't think a release should be a requirement -- i would like us to be able to handle projects that even _start_ within our structure
20:06:41 <sarob> Mikal: yup
20:06:42 <mordred> awesome
20:06:53 <ttx> jeblair: I tend to agree with that
20:06:57 <mikal> jeblair: so, I worry about everyones random ideas ending up being openstack projects and never releasing
20:06:59 <russellb> ttx: jeblair agree
20:07:01 <ttx> I noted my small concern in a comment -- I know we are not supposed to judge maturity but more of a cultural fit, but I have a hard time seeing the current status and future of this project
20:07:06 <mikal> jeblair: that's not the case with congress, but I worry about the precident
20:07:16 <russellb> i dunno, this seems far enough along though that i'm not worried
20:07:19 <mordred> sarob: btw - there is a stackalytics feature called corrections.json where you can remote unnatural commits from the calculations ...
20:07:22 <russellb> it's not an empty repo or something
20:07:38 <sarob> Mordred: roger that
20:07:42 <mordred> (in response to tim hinrichs comment about that one commit)
20:07:44 <ttx> but then the comments I got in answer to my comment were reassuring
20:07:45 <mikal> russellb: Agreed
20:08:01 <mikal> As I said, I'm mostly concerned about the precident, not congress itself
20:08:04 <russellb> mikal: interesting point though worth considering ... is "empty repo" enough?  or if not, what is the line?
20:08:12 <ttx> mikal: I guess if it goes nowhere and dies we could remove them
20:08:19 <anteaya> ttx have we ever?
20:08:25 <mestery> ttx: Is there a process for removing things defined yet?
20:08:33 <russellb> not a process, but stuff has been killed
20:08:43 <ttx> anteaya, mestery when "'things" were only the integrated release, we couldn't realease easily
20:08:44 <sdague> yeh, honestly, I'm with mikal on the fact that I'd really like to see software release before we include them
20:08:49 <mestery> Because if not, letting things in and trying to remove them will be challenging.
20:08:53 <ttx> err.. remove easily
20:08:56 <mikal> Its also not super onerous to ask Congress to do a release when ready and then come back
20:08:58 * mordred submitted a patch to kill gantt earlier today in fact
20:09:04 <ttx> In a big tent setting it's slightly easier to do
20:09:04 <mikal> That's probably only a couple of weeks delay at this point
20:09:23 <anteaya> mordred: you just removed the code, the repo lives on
20:09:25 <sdague> mordred: yeh, gantt is a good instance of a repo that has generated huge confusion in it still existing
20:09:25 <sarob> Planning on a kilo release good enough for concern?
20:09:25 <ttx> mikal: if they enter now they get summit space though
20:09:28 <russellb> ttx: unless it's in the tc approved release, and we have to follow a process with the board around removals
20:09:35 <mordred> anteaya: the repo will always live on :)
20:09:36 <ttx> russellb: yes
20:09:40 * mestery doesn't like that we're dangling summit space as incentive to bring projects onboard
20:09:42 <mordred> mikal: we regularly start projects in infra from completely blank repos
20:09:42 <jeblair> i'm coming to terms with the fact that git repos are free, and we are building a structure around navigating a lot of git repos and filtering out the important ones
20:09:43 <anteaya> mordred: right that is the point
20:09:50 <mikal> ttx: seriously? We can't just grant an exception for summit space?
20:10:05 <anteaya> jeblair: but are we filtering them out
20:10:06 <mikal> ttx: surely we could recognize this as an unusual situation and handle that...
20:10:08 <mordred> mikal: and I'd like for the big tent to allow us to keep doing that
20:10:25 <anteaya> jeblair: see I think the filtering out thing is where some folks (me) are having an problem
20:10:25 <jeblair> i think a benefit of that structure is that we can actually _start_ projects within it
20:10:25 <sdague> mordred: I think that's a bit different as it's under an existing team structure
20:10:30 <ttx> mikal: well, waiting for them to push a tag is about as silly
20:10:35 <sarob> Noting that summit space is a big deal
20:10:38 <sdague> we're talking about a new team that's never demonstrated a release on anything
20:10:41 <morganfainberg> jeblair, ++ i like the attitude that repos are free ;)
20:10:53 <mikal> Repos inside projects are free
20:10:56 <mikal> Projects are not
20:11:10 <russellb> sarob: quick, go push a tag :-p
20:11:16 <markmcclain> except that the bar for making a release is so
20:11:16 <mordred> :)
20:11:18 <jeblair> it's always seemed strange to me that we don't have a good way of starting a new project from scratch within openstack.  i see the opportunity to correct that in the big tent
20:11:22 <mordred> ++
20:11:35 <sarob> Well congress did push m2
20:11:35 <jeblair> anteaya: that's what the project tags effort is about -- helping to navigate that
20:11:44 <markmcclain> jeblair: +1
20:11:54 <sarob> And plans to push kilo too
20:11:56 <ttx> mikal: We can certainly give exceptions out -- but in that precise case saying "you will be in once you push a tag" is unnecessary wait imho
20:12:01 <anteaya> jeblair: well hopefully that will help me then
20:12:35 <anteaya> the concern I'm hearing is about clutter
20:12:36 * markmcclain waits for a project to tag a release entitled the tc_requires_this
20:12:42 <anteaya> what do we do with the clutter
20:12:49 <mikal> ttx: you are welcome to disagree with me
20:12:51 <russellb> lack of any release tags helps communicate "doesn't do releases yet" i suppose
20:12:57 <mestery> russellb: ++
20:13:00 <mordred> russellb: ++
20:13:08 * annegentle looks for a jumping in spot
20:13:18 <jeblair> annegentle: here's one!
20:13:20 <anteaya> annegentle: sharpen your elbows
20:13:20 <annegentle> sarob: how did congress discuss last summit?
20:13:20 <mordred> or maybe "has chosen to not believe in releases and instead only targets CD style"
20:13:31 <russellb> mordred: touche
20:13:37 <sdague> what about the concern that policy already means something in openstack, which is not this?
20:13:42 <sarob> Annegentle: congress got a design space
20:13:53 <sdague> because I'm not looking forward to that becoming more confusing
20:13:59 <sarob> Floor 2 and 3/4
20:14:18 <sarob> About 80 people
20:14:20 <annegentle> sdague: with ya on that one
20:14:24 <mestery> sdague: That's a valid concern IMHO
20:14:25 <jaypipes> sdague: ++
20:14:28 <mordred> sdague: that is a fair point ... I've been meaning to write something up about resource names
20:14:32 <sarob> With 3 follow up sessions
20:14:40 <sarob> In the Dev lounge
20:14:41 * mordred glares at keystone domains
20:14:44 <jaypipes> sdague: that is something I raised with the GBP folks last year as well.
20:14:58 <mordred> otoh - keystone has a thing called domains which are not part of the domain name system
20:14:59 <russellb> fair point
20:15:01 <sdague> yeh, I have the same fundamental issue with GBP
20:15:09 <mestery> jaypipes: Except GBP isn't policy, it's a networking API :)
20:15:10 * morganfainberg apologizes for the poor naming from before he worked on the project
20:15:10 <russellb> i have bigger issues with GBP :)
20:15:27 <mordred> so, if we're going to start in on that, I'd really like to see the TC ask keystone to rename domains to realm
20:15:27 <morganfainberg> keystone domains should have been called Realms (we basically are KRB anyway...)
20:15:33 <sdague> mordred: well, lets sort out a deprecation path to get sane naming
20:15:43 <ttx> back on topic please
20:15:45 * mordred starts working on a spec
20:15:47 <ttx> Looks like we have two camps
20:15:48 <mordred> ttx: I think it's on topic
20:15:53 <mikal> OMG, let's focus on congress for now please
20:15:54 <sdague> but the reality is that reusing a const pointer for a name for a different thing is terribly confusing
20:16:04 <anteaya> sdague: ++
20:16:05 <mordred> sdague had an excellent point about the generic concept that congress implements
20:16:12 <jeblair> so can we ask congress to describe it as "Non-domain specific regulatory policy enforcement" ?
20:16:15 <russellb> sdague: is the pointer const, or the contents it points to const?
20:16:19 <russellb> sorry, been writing C ...
20:16:22 <ttx> camp 1 says project teams should at least have a release, otherwise how do they actually contribute to the openstack mission
20:16:24 <sdague> russellb: :P
20:16:39 <ttx> camp 2 says project teams should be able to start from nothing as long as their intentions are pure
20:17:04 <mordred> ttx: camp 3 says that project teams shoudl be able to start frmo nothing even if they never intend on making a release
20:17:14 <mordred> but also counts itself in camp 2 for the purposes of talying
20:17:22 <mestery> lol
20:17:27 <dtroyer> does camp 2/3 have any sort of idea _who_ can do this?  anyone at all?
20:17:30 <ttx> mordred: that is camp 2
20:17:36 <dtroyer> or just people we 'know'
20:17:48 <annegentle> dtroyer: it's people we 'like'
20:17:51 <jeblair> anyone
20:17:53 <annegentle> dtroyer: :P
20:17:55 <mordred> jeblair: ++
20:17:56 <mikal> ttx: so... this is what gerrit is for right?
20:18:02 <ttx> yes
20:18:05 <mikal> ttx: can't people just vote, and if I am the only -1, then merge it
20:18:08 <dtroyer> so why do we continue to need stackforge in that world?
20:18:08 <jeblair> which is the status quo for projects that join stackforge, which is part of openstack
20:18:13 <mestery> If it's anyone, why are you even debating this? :)
20:18:16 <russellb> sarob says they did milestone 2
20:18:19 <mestery> Just let them all in! :)
20:18:22 <russellb> and will be doing kilo
20:18:25 <ttx> mikal: fwiw I was on camp 1 until I realized that a tag is cheap and doesn't carry any meaning of maturity
20:18:36 <russellb> i'm sympathetic to camp 1, just see it as largely addressed
20:18:37 <annegentle> ttx: +1
20:18:46 <jeblair> dtroyer: i don't think we do.  i'd like to remove "rename repostories" as part of our software lifecycle
20:18:50 <ttx> russellb: they don't have tarball jobs though :)
20:18:53 <russellb> heh
20:18:56 <zaneb> mikal: consensus >> voting
20:18:58 <mikal> ttx: it is unproven that our users and the community will interpret the git namespace in the way we hope they will
20:19:01 <ttx> so the tag doesn't create a release
20:19:04 <russellb> well i'm still in camp 2, i don't think it's required
20:19:08 <dtroyer> ok, cool.  then we're removed that barrier to resource allocation in corporations.
20:19:09 <russellb> no releases is a valid choice MIO
20:19:11 <russellb> IMO*
20:19:13 <mikal> ttx: they have certainly done strange things we didn't intend with that stuff in the past
20:19:17 <dtroyer> they'll find anoher one to use unless we give them one we like
20:19:26 <mordred> zaneb: I'm not sure what bitshifting consensus and voting does ...
20:19:31 <jeblair> mikal: i feel certain they will as soon as we have enough things in there to make it clear where the bar is set
20:19:34 <anteaya> dtroyer: is there one we like?
20:19:43 <mordred> zaneb: :)
20:19:55 <sdague> ok, so I'm fine with no release if we've got some reasonable way to have someone outside of a project realize it's dead and get it killed off
20:20:03 <dtroyer> anteaya: unknown, except we haven't particularly cared for the two previous ones
20:20:06 <ttx> One more +1 and this passes now, otherwise we have to wait for final vote next week
20:20:09 <anteaya> sdague: me too
20:20:09 <sdague> but that still doesn't address 'Policy as a Service' being confusing
20:20:18 <anteaya> dtroyer: yes I agree to that
20:20:40 <ttx> Any other question on Congress ?
20:20:45 <jeblair> ttx: +1
20:20:57 <mordred> sdague: I agree - I'd love to see either a different word or maybe an adjective added
20:21:03 <jeblair> i'm going to write a patch
20:21:05 <ttx> OK, we have 7
20:21:09 <mordred> since I believe we're expecting keystone to start offering access to policy files soon
20:21:09 <russellb> mordred: sdague ++
20:21:13 <sarob> Sweet
20:21:14 <mordred> sarob: ^^
20:21:21 <ttx> Last call before I approve it
20:21:23 <zaneb> mordred: tbh, to this day I have no idea what congress is
20:21:33 <morganfainberg> mordred, fwiw, I expect that to be a big focus in liberty [if that weighs in anywhere]
20:21:35 <mordred> sarob: it would be a friendly if you could figure out a better word than "policy"
20:21:37 <morganfainberg> mordred, for the conversation
20:21:43 <russellb> zaneb: it's less scary if you really look into what it does :)
20:21:43 <mordred> sarob: I have no suggestions
20:21:51 <sdague> mordred: it's compliance
20:22:02 <sdague> Compliance Enforcement
20:22:06 <zaneb> after reading the wiki page multiple times, being pitched on IRC about it and attending an unrelated summit session that was hijacked by congress devs
20:22:07 <sdague> that's what it should be called
20:22:07 <mordred> sarob: perhaps compliance as a service then?
20:22:09 <jeblair> i proposed https://review.openstack.org/169480
20:22:18 <sarob> I think policy is sticky
20:22:23 <jeblair> sdague, sarob: ^ maybe we can take that as a strawman to bikeshed on
20:22:32 <sdague> sarob: ?
20:22:58 <ttx> OK, it's in
20:22:59 <mordred> sarob, sdague, jeblair: let's find a cage and fight it out outside of the TC meeting
20:23:04 <sdague> sure
20:23:15 <sarob> ;)
20:23:16 <ttx> next topic
20:23:23 <jeblair> mordred: agreed, yeah, that's what i intended to do with that change
20:23:29 <ttx> sarob: welcome
20:23:36 <ttx> #topic Apply release:* tags to current projects
20:23:45 <ttx> #link https://review.openstack.org/167682
20:23:47 <sarob> Ttx: thanks!
20:23:54 <ttx> This is describing the release model for each of the code repositories in the yaml file (if they do releases)
20:23:57 <annegentle> oh he's capital Ttx now!
20:24:04 <ttx> I think it's pretty straightforward and a base we can iterate on.
20:24:21 <ttx> It's got 7 YES so I can approve it now
20:24:25 <ttx> Last minute questions ?
20:24:25 <russellb> yay
20:25:04 <annegentle> I think it's great it's already bringing in good questions.
20:25:16 <ttx> Right, that exercise raised two interesting questions (which I would consider orthogonal to the patch)
20:25:22 <ttx> (Approved)
20:25:23 <annegentle> it being tag application
20:25:29 <ttx> The first one is the need for a "release:has-stable-branches" tag to differentiate between a project that just merely has a stable branch cut from their last release (which may have been months away), like an Oslo library
20:25:37 <ttx> and a project that consciously tries to align with the 6-month release cycle end (like Swift)
20:25:43 <ttx> I'll propose that new tag in a subsequent patch
20:25:56 <ttx> The second question is more general, and is about how to provide the most useful information to our downstream users
20:26:07 <ttx> Should we tag every git repository, or just "deliverables" (OpenStack software git repositories) ?
20:26:19 <ttx> I think our users, when they will browse the catalog of OpenStack projects, only want to see things they might actually consume ('Neutron') and not necessarily every git repo in OpenStack-land
20:26:33 <ttx> So it feels like we could use an abstraction layer between project teams and git repositories and apply tags to that new layer
20:26:40 <ttx> Bear with me while I illustrate with a few examples
20:26:54 <ttx> Nova currently has 3 repositories (nova, nova-specs and python-novaclient). I'd argue that as far as our users are concerned, it produces two deliverables (Nova and the Nova python client library), and apply tags only to those
20:26:59 <russellb> i had a variation on that question ... whether it makes sense to tag the team in some cases (like diversity)
20:27:05 <ttx> It is an abstraction layer, because in some cases deliverables can contain more than one code repository
20:27:21 <ttx> For example, Neutron currently produces a "Neutron" deliverable out of openstack/neutron, openstack/neutron-fwaas, openstack/neutron-lbaas and openstack/neutron-vpnaas, since they are always released at the same time.
20:27:31 <ttx> The users consume "Neutron", the fact that it's technically separated into 4 code repositories is a technical implementation detail
20:27:50 <ttx> Now... there are corner cases. Should we consider libraries "deliverables" ? For example should Cinder have an "os-brick" deliverable ?
20:28:04 <ttx> Should we tag individual infrastructure projects ? Or not tag them at all, since they are a supporting cast and not really a part of the IaaS platform ?
20:28:15 <ttx> Or should we consider that all infra forms a single "deliverable" ?
20:28:19 <ttx> Is docs a deliverable ?
20:28:21 <ttx> etc.
20:28:34 <mordred> I'm pretty sure all of infra is not a single deliverable, for whatever that is worth
20:28:38 <jeblair> ttx: that makes sense, especially with projects collecting more component repos, that people may not need to see the components listed separately when evaluating what the project produces.
20:29:01 <ttx> trying to see what would make the most sen,se for a consumer of the tag system (a downstream user)
20:29:14 <russellb> the components of the Neutron deliverable likely have different maturity levels
20:29:21 <anteaya> would you ask individual projects to answer that question?
20:29:26 <anteaya> what is your deliverable?
20:29:27 <jaypipes> russellb: that was *exactly* my thought.
20:29:31 <jeblair> mordred: depends on what a deliverable is.  in some ways, yes, in others, no.
20:29:39 <mestery> Maybe also ask downstream consumers what they'd prefer?
20:29:46 <russellb> so maybe they're separate deliverables and the model holds
20:29:48 <ttx> russellb, jaypipes: in the neutron example above, they are released as a single "thing"
20:29:51 <mordred> jeblair: fair
20:29:53 <zaneb> crazy idea: TC assigns tags to projects, projects decide for themselves which of their repos the approved tags are applied to
20:29:55 <ttx> (maybe deliverable is not the right term for this)
20:29:59 <russellb> but they're different enough to consider them separately :)
20:30:04 <zaneb> (thinking out loud here)
20:30:13 <anteaya> ttx: no I think it is
20:30:22 <russellb> they are optional bits of significant functionality with vastly different maturity levels, AFAICT
20:30:26 <anteaya> the problem is the variety
20:30:28 <jaypipes> ttx: well, yes, but python-neutronclient and neutron (the 4 repos) have different release cycles.
20:30:29 <sdague> russellb: ++
20:30:31 <ttx> zaneb: right, that was my point. Nova produces "nova" and the python nova client... how many repos they split Nova into is not really significant
20:30:44 <ttx> jaypipes: that's two difefrent deliverables though
20:30:49 <jaypipes> ok
20:30:52 <jeblair> ttx, mordred: regarding infra specifically, i don't want to get too hung up on it because we are here to support the overall effort, not make it more difficult.  however, we do want to participate in it as much as possible.  so if tags are being applied for diversity, etc., i would like them to be applied to infra in some way.  but i also don't think we need 160 entries in the openstack project browser.
20:30:54 <mikal> I can see the projects with many hundreds of repos being very confusing to consumers
20:30:57 <ttx> One team, two deliverables, 7 repos
20:30:57 <mikal> Tripleo for example
20:31:00 <zaneb> ttx: yeah, it would be really nice for the TC not to have to care at the repo level
20:31:07 <mordred> jeblair: +100
20:31:22 <sdague> ttx: I think the fact that neutron advanced services are on the same deliverable schedule is just a bug of the current split being only partial
20:31:31 <sdague> I assume they will become more independent over time
20:31:49 <jeblair> sdague: maybe they become separate deliverables then, but are one now?
20:32:06 <russellb> i think i like the deliverables concept to create a more natural place to apply some tags
20:32:09 <ttx> jeblair: hmm.. maybe we can filter the project browser on some other data -- like a relevant-for-the-browser tag.
20:32:15 <russellb> just ... details to work out, i guess
20:32:27 <ttx> anyway, I was thinking out loud. Blame devananda
20:32:30 <sdague> jeblair: yeh, but I think it's important to consider them separately, because as many folks have said, they are vastly different maturities
20:32:49 <ttx> just wanted to throw it out there and see what you thought
20:32:58 <russellb> tentative optimism
20:33:11 <jeblair> sdague: and people may choose not to deploy some of them based on that maturity level, even now?
20:33:18 <russellb> jeblair: yes
20:33:20 <russellb> for sure
20:33:20 <sdague> jeblair: yes
20:33:34 <russellb> i'd say most people don't deploy any of them, in fact
20:33:37 <jeblair> yeah, so that feels like multiple deliverables then,
20:34:02 <ttx> right maybe that was not the right example
20:34:07 <markmcclain> russellb: I've have LBaaS in the wild
20:34:10 <agentle_> whacky internets, catching up now
20:34:11 <ttx> I think everyone agrees we should not tag nova-specs
20:34:21 <ttx> or openstack/governance
20:34:25 <russellb> markmcclain: cool :)
20:34:37 <ttx> so *some* repos do not make sense being tagged
20:34:39 <anteaya> ttx I agree with that
20:34:42 <dougwig> it's almost as if you need a TC managed integrated-release tag, which defines what is "openstack".
20:34:55 <jaypipes> ttx: are we *specifically* referring to release:* tags here?
20:34:56 <russellb> ttx: i also agree that for some projects split into repos, tagging individually doesn't make good sense
20:34:59 <jeblair> ttx: but should contributing to nova-specs feed into the contributions we look at when we evaluate diversity of nova?
20:35:04 <ttx> jaypipes: no
20:35:10 <jaypipes> dougwig: very funny.
20:35:31 <russellb> dougwig: just wait until we get back to defining the "TC Approved Release"
20:35:42 <ttx> full circle completed!
20:35:47 <russellb> pretty much
20:35:47 <jeblair> we do, of course, have exactly that tag.  it is deprecated.
20:35:48 <dougwig> isn't that what you're doing right now?   re-arranging the deck chairs notwithstanding.
20:35:53 <jaypipes> ttx: then I'm -1 on this. I want to tag repos with fine-grained information about that repo, not broad tags that may or may not accurately represent individual repos within a project space.
20:36:04 <ttx> jaypipes: ok
20:36:15 <jaypipes> dougwig: no.
20:36:47 <ttx> OK, I propose we move on. I'lml give the idea some more thought and propose a strawman change if I think the idea has value
20:37:02 <ttx> Thanks for the feedback though
20:37:05 <vishy> or we could elect someone to tag the release with their name
20:37:08 <ttx> #topic Projects list housekeeping
20:37:09 <jeblair> ttx: thanks; there are definitely some good things in there
20:37:13 <vishy> “jaypipes certified openstack”
20:37:15 <vishy> :p
20:37:18 <ttx> * Adds the openstack/os-cloud-management to TripleO... (https://review.openstack.org/166723)
20:37:26 <ttx> Mikal raised an interesting point on the name of the lib being a bit too generic
20:37:27 * jaypipes remarks that it's easy to aggregate fine-grained data. Not so easy to go the other way round.
20:38:08 * jaypipes still waiting for the os-on-os-on-os-on-os repo.
20:38:09 <mikal> I fear we might not have been all that consistent with generic names in the past
20:38:17 <sdague> ttx: it's at least better than os-cloud-middleware
20:38:24 <ttx> sdague: lol
20:38:27 <jaypipes> heh
20:38:33 <jaypipes> tru nuf
20:38:33 <jeblair> mikal, ttx: i agree it's too generic, but matches the level of descriptiveness we have in other similar projects.  :/
20:38:34 <vishy> septuple-o
20:38:36 <vishy> nice
20:38:42 <jeblair> i feel like the ship has sailed
20:38:56 <mikal> jeblair: its never too late to be grumpy about it though
20:39:06 <mordred> mikal: I'm grumpy about plenty of things all day long :)
20:39:13 <sdague> yeh, until we dissallow the words middleware and lib  in projects, it seems overly harsh to be grumpy of generic names
20:39:18 <jeblair> we could suggest the tripleo folks mass-rename s/os-/tripleo-/ in their project names
20:39:24 <ttx> we could
20:39:27 <mikal> OMG, I was just thinking that
20:39:28 <annegentle> jeblair: the naming ship?
20:39:33 <mikal> jeblair: let's do it
20:39:43 <ttx> mikal: that is orthogonal to that patch though
20:39:46 <russellb> what if they change the number of Os
20:39:48 <ttx> Can I approve this one ?
20:39:51 <mikal> ttx: true dat
20:39:54 <annegentle> s/os-/ooo-
20:39:55 <mikal> ttx: and probably also a dick move
20:40:09 <ttx> well os-* is not a great prefix anyway
20:40:10 <russellb> SeveralO
20:40:32 * zaneb can provide more info on what this lib will do if anyone has questions
20:40:42 <ttx> So I'll approve all of thoise unless a -1 is posted (in which case we'll discuss it next week
20:40:46 <ttx> * Add os-testr repo to QA (https://review.openstack.org/167244)
20:40:47 <russellb> zaneb: what?  the name is the important part
20:40:48 <mikal> zaneb: can I use it outside of the context of tripleo?
20:40:49 <ttx> * Add ansible-puppet repo to infra (https://review.openstack.org/166820)
20:40:52 <ttx> * Add ansible-build-image to infra (https://review.openstack.org/166821)
20:40:56 <ttx> * Add bashate to the QA program (https://review.openstack.org/168012)
20:40:59 <ttx> * Add puppet-diskimage-builder to Infra (https://review.openstack.org/167612)
20:41:03 <ttx> * Move os-client-config to openstack namepsace (https://review.openstack.org/167730)
20:41:45 <jaypipes> ttx: cool with me.
20:41:47 <ttx> I'll collect that tomorrow morning. So if you really think os-cloud-management is too generic, -1 it
20:41:59 <zaneb> mikal: not really, the idea is for it to be the common part for things that need to be done by both the Tuskar UI and CLI users, but which are not in the Tuskar API
20:42:02 <ttx> and we'll continue that interesting discussion next week
20:42:16 <mikal> zaneb: ok, in that case I am -1 on that name
20:42:33 <annegentle> zaneb: gotta go with mikal on that one too
20:42:33 <ttx> #topic Open discussion
20:42:49 <ttx> A few topics I wanted us to discuss
20:42:52 <ttx> * Neutron renaming "core reviewers" to "maintainers" (https://review.openstack.org/164208)
20:43:00 * mikal seems to be the grumpy one this week
20:43:03 <ttx> This was proposed in parallel to https://review.openstack.org/#/c/163660/ which we rejected
20:43:16 <ttx> mikal: I have a damn cold so I am also grumpy
20:43:21 <russellb> mikal: we all get a turn :)
20:43:23 <ttx> The main objections raised (by TC members, not really by Neutron devs) are:
20:43:29 <ttx> (1) the bundling of review duties with other project duties to form a single super-developer status
20:43:34 <ttx> (2) the choice of the "maintainers" term which is a bit overloaded and far away from "reviewing"
20:43:45 <ttx> Now Neutron devs (and others) claim it's none of our business since we are not Neutron devs, and that you can't dictate culture by committee
20:43:48 <mordred> I believe my objection here is going to be that I do not think this is a project level thing
20:43:53 <mordred> and I do believe that we can do that
20:43:58 <ttx> That said, TC members judge OpenStack projects inclusion in the big tent by the sharing of common community and development values (the "are you one of us" test)
20:44:02 <russellb> mordred: ++
20:44:06 <mestery> What? We're not creating a super developer, we're acknowldeging those already exist. I've broken the patch in two.
20:44:07 <mordred> and I believe taht if they want me to butt out they have another thing coming
20:44:08 <ttx> And we have oversight as long as they are called openstack/neutron and not stackforge/neutron
20:44:09 <annegentle> I'm with mordred on consistency in names and understanding.
20:44:13 <mestery> I think that's not a fair characterization of hte patch to be honest
20:44:29 <annegentle> but I do like doing what I want with my specialty teams :)
20:44:34 <marun> I don't think it should be the place of the TC to define culture at the project level.
20:44:34 <mordred> I do not believe that it is appropriate for neutron to try to rename a concept that exists across openstack
20:44:44 <mordred> marun: I believe it is exactly the place of the TC
20:44:44 <ttx> mestery: ok, you're defining a super-developer class, not creating it because it already exists in Neutron
20:44:53 <marun> mordred: Really?
20:44:55 <mordred> marun: yes
20:44:59 <mestery> ttx: Nope, I'm not saying that.
20:45:02 <dougwig> ttx: it exists everywhere in openstack.  that most refuse to admit that does not make it less true.
20:45:05 <mestery> ttx: I'm documenting what existing core reviewers do
20:45:18 <russellb> my main objection was changing the name, honestly
20:45:18 <mordred> mestery: I agree with documenting what exisitng core reviewers do
20:45:22 <mestery> How did you interpret the first patch as "defining a super developer class in neutron"?
20:45:25 <marun> mordred: Tell me, where have you ever seen design-by-committee be applied to defining culture?
20:45:29 <mestery> mordred: thank you
20:45:41 <annegentle> marun: we try to be the resolvers of conflict while representing the contributors
20:45:51 <mordred> the name change is troubling because it creates a schism in terminology between one of our projects and another
20:45:56 <mordred> and in the world of the big tent
20:45:57 <marun> mordred: sure
20:46:04 <mordred> one of the few things we have remaining is a common culture
20:46:05 <marun> mordred: design-by-committee is the way forward, gotcha
20:46:06 <annegentle> marun: it's not design by committee, more like representation
20:46:09 * mestery thinks maintainers better reflects what core reviewers do and was hopeful that jogo'
20:46:13 <marun> annegentle: if you say so.
20:46:19 <mestery> patch would have been better received
20:46:33 <marun> annegentle: kind of potayto, potahto to me
20:46:35 <jeblair> mordred: i agree
20:46:44 <marun> mordred: there isn't common culture
20:46:46 <marun> news flash
20:46:48 <mordred> marun: what i'm saying is that if there is a term, called "core reviewer" that is used across openstack, and neutron choses to abandon it
20:46:53 <ttx> mestery: I think you bundle a number of duties together -- that prevents for example non-reviewers from being a "maintainer"
20:46:53 <marun> each project is different and unique
20:47:07 <mordred> marun: believe me, as a consumer of all of them, that is clear
20:47:08 <marun> and we need to be results oriented instead of process oriented
20:47:10 <mestery> ttx: Yes, that's the current reality. All that patch does is reflect that.
20:47:13 <russellb> mordred: lol
20:47:19 <annegentle> marun: happy to deep dive on it with you esp. where you see actions aren't reflecting that representation. As we grow, culture remaining meaningful is the hardest part.
20:47:20 <mestery> ttx: I'd like to change that, but thought that documenting what exists now is better to start with
20:47:23 * jogo is still planning to follow up with ttx's suggestion of 'We should probably be having that discussion on the ML'
20:47:24 <marun> where is the TC in defining what results we're trying to achieve?
20:47:32 <mordred> marun: what are you even talking about right now/
20:47:36 <annegentle> jogo: probably best
20:47:37 <marun> as opposed to defining seemingly arbitrary ways we have to achieve it?
20:47:46 <mordred> marun: we are talking about a patch that was proposed to change a name of a group of people
20:47:49 <mestery> jogo: ++
20:47:49 <russellb> so if mestery just updates the docs and leaves the name alone, is there objection?
20:48:12 <sdague> russellb: I'd have no objection to documentation of existing role without a name change
20:48:16 <marun> mordred: yes, to change how we perceive ourselves in the project so we can forment change in how we achieve results
20:48:17 <russellb> same here
20:48:20 <ttx> jogo: yes, I don't expec that discussion to go anywhere, just wanted to raise it to the collective attention
20:48:21 <sdague> I think terminology changes need to be global
20:48:27 <russellb> sdague: agree
20:48:28 <mordred> sdague: ++
20:48:28 <marun> sure, design-by-commiitte it is
20:48:33 <annegentle> marun: if you don't want seemingly arbitrary I would think you'd want tc representatives to be able to debate this uncovered naming issue respectfully and honestly.
20:48:36 <marun> yay for the TC, arbiter of all that is right and good
20:48:38 <sdague> because it's too f-ing confusing for people to interface otherwise
20:48:51 <marun> right
20:48:59 <marun> culture is messy, let's simplify
20:49:14 <dougwig> can we dial ourselves back to duties within mystery's change that the TC has a problem with?
20:49:15 <ttx> marun: some people in openstack work on multiple projects
20:49:21 <mestery> russellb: Abandoned
20:49:31 <marun> ttx: some people in the world paricipate in different social realities, too
20:49:37 <marun> ttx: and somehow, they manage
20:49:49 <anteaya> dougwig: I don't think the duties were the issue
20:49:50 <marun> but sure, openstack is special
20:50:06 <ttx> marun: I envy the simplicity of your life
20:50:15 <russellb> i think this whole thing is being blown way out of proportion
20:50:19 <russellb> mestery abandoned the name change portion
20:50:22 <marun> ttx: I think that's my line
20:50:23 <mordred> russellb: I agree
20:50:24 <mestery> It's gone
20:50:25 <russellb> what other concern remains?
20:50:29 <mordred> russellb: none from me
20:50:32 <russellb> that was my only concern
20:50:36 <russellb> issue resolved from my side
20:50:39 <mordred> I think the clarification is awesome
20:50:47 <zaneb> marun: I think we should be differentiating where that adds real value. renaming stuff like this is not one of those places imho
20:50:55 <mordred> zaneb: ++
20:50:58 <marun> zaneb: you are certainly entiteld to your opinion
20:51:02 <jeblair> mestery: ++
20:51:09 <marun> language matters
20:51:11 <ttx> mestery: I like it
20:51:11 <annegentle> thanks mestery
20:51:13 <jaypipes> marun: everyone is entitled to my opinion.
20:51:19 <mordred> jaypipes: :)
20:51:20 <mestery> Thanks mordred!
20:51:28 <mestery> Thanks for the discussion here folks!
20:51:33 <russellb> thanks, mestery
20:51:35 <mestery> I do look forward to jogo's ML thread on the same :)
20:51:40 <ttx> mestery: I think we actually disagreed on different things
20:51:43 <mordred> thanks mestery !
20:51:49 <mestery> ttx: lol :)
20:52:05 <ttx> ok, next fun discussion
20:52:06 <ttx> * WIP: Add Group Based Policy Project (https://review.openstack.org/161902)
20:52:07 <annegentle> matrixed disagreement
20:52:12 <ttx> Since we have some time left we could discuss the GBP addition
20:52:14 <SumitNaiksatam> ttx: hi
20:52:19 <ttx> They have removed it from the agenda because someone raised a question on the review and to give them time to address it
20:52:33 <SumitNaiksatam> ttx: just about to say that
20:52:50 <ttx> Maybe we should see how much of a common concern that raised question is
20:52:56 <sdague> so objection #0, beyond all other objections, we *can not* have 3 things in openstack that use policy to mean different things
20:52:57 <SumitNaiksatam> we felt that putting the patch in WIP would give some more time for discussions
20:53:03 <ttx> I for one share russellb's concern about diluting Neutron
20:53:05 <sdague> that's just super crazy pants clown car
20:53:05 <markmcclain> sdague: ++
20:53:19 <anteaya> ++ to both sdague and ttx
20:53:22 <mordred> sdague: ++
20:53:23 <russellb> i just don't want a 3rd competing networking API
20:53:27 <SumitNaiksatam> sdague: i agree
20:53:28 <mestery> sdague: ++
20:53:29 <anteaya> russellb: agreed
20:53:36 <mestery> russellb: STRONG ++
20:53:36 <sdague> russellb: also, I agree strongly with you on that
20:53:38 <dougwig> so if nova-net and neutron both suck, we still won't let competition find a better solution?  isn't that the opposite of big tent?
20:53:39 <mestery> We already have two
20:53:49 <markmcclain> I share the same concern about having yet another api
20:53:56 <anteaya> dougwig: competition here isn't wan't our users want
20:54:01 <russellb> dougwig: no, if there seemed to be strong consensus and support that GBP was the future, it'd be a different conversation
20:54:03 <SumitNaiksatam> ttx: i dont think it dilutes Neutron
20:54:04 <anteaya> dougwig: we have some things they like
20:54:07 <russellb> a very messy situation, but we'd work through it
20:54:08 <ttx> I basically question the "positive contribution to the OpenStack Mission" when we circumvent such a basic component
20:54:14 <prasadv> russellb: I dont think it is competing network api. It is aapplication oriented api that uses neutron
20:54:24 <ivar-laz_> prasadv: +1
20:54:26 <anteaya> ttx: ++
20:54:32 <SumitNaiksatam> russellb: the intention is definitey not to create a 3rd competing API for networking
20:54:39 <russellb> i know you keep saying that
20:54:43 <russellb> i heard it
20:54:45 <ttx> prasadv: is it purely building on top of Neutron ? Or has it its own network hardware plugins ?
20:54:47 <russellb> but that's not what i see
20:54:47 <dougwig> i'm more commenting on how big tent could lead to this sort of issue becoming common.  it's open for all, except for sub-clause a, b, and subsection d.
20:54:52 <mestery> It's a networking API
20:54:53 <markmcclain> SumitNaiksatam: that is contrary to statement made by the GBP team last summer
20:55:01 <SumitNaiksatam> ttx: we dont circumvent any of the components
20:55:04 <ivar-laz_> russellb: I've tried to answer your concern on the review. At any point GBP can or will circumvent Neutron's API
20:55:10 <mestery> Look at the "hands on lab" session in vancouver, and at the ODL Summit
20:55:10 <markmcclain> SumitNaiksatam: at the time it was stated the intent was to be the v3 API
20:55:20 <mestery> Look at the fact it exists in OpenDaylight ... an SDN controller project ... focused on networking
20:55:21 <mordred> dougwig: I think we shoudl be clear with people that there are some things, probably things that have made their way into defcore, where we're not particularly looking for competition
20:55:25 <mordred> competition is GREAT
20:55:26 <mestery> markmcclain: ++
20:55:28 <SumitNaiksatam> markmcclain: absolutely yes, but the project has evolved
20:55:28 <anteaya> networking needs to fix the problems we have, we aren't lacking here, and we don't need more
20:55:29 <mordred> but after a point, it becomes noise
20:55:40 <russellb> mordred: ++
20:55:42 <ttx> SumitNaiksatam: I think that's the bottom of the question -- are we having network hardware plugins in two difefrent places
20:55:42 <jeblair> there was a lot of positive reception to the idea that the big tent would enable us to consider alternative approaches and implementations of functionality.  this seems to be that, so how do we exclude gbp on that basis?
20:55:46 <SumitNaiksatam> markmcclain: you are referring to the patch that was posted in neutron
20:56:02 <SumitNaiksatam> anteaya: agree 100%
20:56:12 <anteaya> jeblair: it doesn't help us achieve the openstack mission?
20:56:18 <markmcclain> SumitNaiksatam: ok.. that evolution in thinking wasn't very clear
20:56:22 <ttx> jeblair: I think that competition becomes more costly the further down the layers you go
20:56:24 <mordred> jeblair: oh, I'm not saying we should say no to gbp - I'm just saying that I don't necessarily think that competition in the area of networking APIs for openstack is good for our users
20:56:33 <ivar-laz_> ttx: which plugin are you referring?
20:56:36 <ttx> jeblair: for example, keystone competition makes no sense
20:56:40 <jeblair> would it be okay to accept ceph-based object storage?
20:56:47 <ttx> jeblair: and actively hurts the openstack mission
20:56:52 <jeblair> lots of people use and want that
20:56:58 <mordred> jeblair: I would have no problem with that
20:57:05 <russellb> i look it at as competition is more welcome the higher we go in the stack, or the less mature its "competitors" are ... basically we should use our heads and evaluate whether competition makes sense
20:57:09 <ivar-laz_> ttx: all the existing drivers, vendor or not, must use Neutron for their data path to work
20:57:10 <SumitNaiksatam> markmcclain: happy to clarify, thanks fo asking
20:57:12 * jogo finds this whole exercise of difficult because all of the GBP documentation seems to be self contradicting and very out of date
20:57:18 <jeblair> mordred: i struggle to see the difference
20:57:26 <mordred> jeblair: I do not believe there is one
20:57:33 <jeblair> mordred: so this is a gut thing?
20:57:35 <mordred> jeblair: I believe we are talking about two different things ...
20:57:42 <mordred> jeblair: one of them is "do we let a project into the big tent"
20:57:46 <annegentle> SumitNaiksatam: agree with jogo that docs would help provide evidence for your stated cause
20:57:50 <mikal> So, we used competing with nova as an example in the original discussions, and we liked that idea then. I'm confused about the distinction here to be honest.
20:57:56 <jaypipes> jeblair: I think the difference is that, at least from my perspecitve (and I know SumitNaiksatam is updated docs and stuff) GBP isn't an alternative implementation of the Neutron API. It's a whole different networking API that essentially makes the Neutron API irrelevant (and is pretty much just a passthru to ACI-like vendor APIs.
20:57:59 <ttx> ivar-laz_: my question is.. will GBP forever act as a proxy API on top of Neutron API, or is it prone to plug directly into networking hardware features, and therefore use plugins
20:57:59 <mikal> I'm not saying we should replace Neutron
20:57:59 <mordred> jeblair: another is "do we consider the output of that project an essential part of the deliverable called OpenStack"
20:58:11 <mordred> jeblair: I believe that letting someone in the tent does not imply the second thing
20:58:12 <russellb> jaypipes: ++
20:58:13 <ttx> ivar-laz_: my understanding is that the goal is the latter
20:58:18 <mikal> But this "less competition at lower layers" thing wasn't discussed during the original votes
20:58:19 <SumitNaiksatam> annegentle: sure, perhaps we were not clear, and we should do a better job
20:58:19 <mestery> jaypipes: ++
20:58:21 <mestery> jaypipes: Nailed it!
20:58:28 <ivar-laz_> ttx: the Mission statement is to act on top of Openstack, by *using* it
20:58:33 <jeblair> mordred: okay, i follow you and agree with you there
20:58:37 <annegentle> SumitNaiksatam: believe me I know it's hard to find all the corners of the 'net :)
20:58:39 <jeblair> mordred: so which question are we discussing? :)
20:58:41 <ivar-laz_> ttx: that's the commitment, and today code base shows it.
20:58:49 <mordred> jeblair: we SHOULD be discussing letting them into the party
20:59:00 <mordred> jeblair: we seem to be forgetting that we are not defcore
20:59:05 <ttx> ivar-laz_: exactly. So GBP will forver be a proxy API on top of Neutron API ? In which case +1
20:59:21 <russellb> ttx: it's not that today
20:59:33 <mestery> ttx: I wouldn't bank on that down the road
20:59:42 <mordred> so a) I think GBP is a bad idea. b) I support it being added to the openstack tent because I do not think inclusion in that tent should carry meaning
20:59:42 <SumitNaiksatam> ttx: thats how it works for networking constructs today
20:59:43 <jeblair> mordred: so i'm with you on 1) +1 and 2) -1 (or really n/a -- see defcore)
21:00:07 <ttx> OK, no time left -- I suspect Sumit will clarify the points we raised, in time for next week discussion
21:00:10 <SumitNaiksatam> russellb: why do you think its not like that today?
21:00:14 <ivar-laz_> ttx: that's the mission :)
21:00:20 <SumitNaiksatam> ttx: sure
21:00:23 <zaneb> mordred: bad idea or bad implementation?
21:00:24 <SumitNaiksatam> thanks all for the time
21:00:26 <SumitNaiksatam> and the disscussion
21:00:33 <mordred> zaneb: the idea of having a competing networking API approach
21:00:37 <ttx> Thanks everyone, closing the meeting to make room for next
21:00:37 <mordred> zaneb: I think it serves nobody well
21:00:39 <mordred> however
21:00:43 <mordred> I don't think I should make that call right now
21:00:45 <ivar-laz_> Thanks people for showing your concerns! join us on #openstack-gbp for more questions
21:00:50 <ttx> Feel free to continue this discussion on #openstack-dev :)
21:00:52 <mordred> and I think it's fine for GBP to play in our sandbox
21:00:54 <mestery> lol
21:00:55 <zaneb> mordred: agreed, I would prefer to fix the neutron api in a future rev
21:01:01 <ivar-laz_> ttx: or there!
21:01:05 <sdague> I think an important question is how open the api design process was here, and will be in the future
21:01:08 <annegentle> thanks SumitNaiksatam!
21:01:11 <ttx> #endmeeting