20:01:37 <ttx> #startmeeting tc
20:01:38 <openstack> Meeting started Tue Sep  8 20:01:37 2015 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:42 <openstack> The meeting name has been set to 'tc'
20:01:46 * rockyg is shaking jaypipes' hand
20:01:52 <ttx> Agenda for this Technical committee meeting lives at:
20:01:57 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:02:07 <ttx> #topic Adding Monasca to OpenStack
20:02:12 <ttx> #link https://review.openstack.org/213183
20:02:19 <ttx> Two weeks ago we decided to table Monasca application for two weeks
20:02:27 <ttx> In order for them to implement a few logistics change to further align with the OpenStack Way
20:02:36 <ttx> But also to give some TC members more time to investigate how closely Monasca worked with Ceilometer and/or API overlap issues
20:02:49 <jaypipes> "some TC members"? :)
20:02:56 <ttx> >=1
20:02:58 <ttx> At this stage I'd say that while they were not exactly "one of us" in the past, they are now organized to be one of us in the future, and certainly feel responsive and motivated to do so
20:02:59 * mordred looks at jaypipes
20:03:02 <jaypipes> heh
20:03:03 <dhellmann> o/
20:03:12 <ttx> That leaves jaypipes's objections
20:03:20 <edleafe> jaypipes: http://blog.leafe.com/establishing-apis/
20:03:24 * dimsum__ sneaks in
20:03:25 <jaypipes> ttx: I agree that they are now organized to be one of us.
20:03:25 <ttx> one is the question of compatible API between competing implementation of the same functionality, which arguably was never articulated before
20:03:49 <dtroyer> o/
20:04:02 <ttx> two is fairness in comparison of how Fuel / GBP were treated, asking for the same kind of delay to assess cooperation
20:04:10 <jaypipes> ttx: it was indeed brought up in the GBP big tent proposal, which I brought up in my latest comment.
20:04:31 <ttx> So I guess we should discuss both points
20:04:59 <dhellmann> I tend to agree with jaypipes
20:05:00 <ttx> do we want compatible APIs for  competing implementation of the same functionality ?
20:05:11 <mordred> for one - I think I do not care about the API overlap if the two are not claiming the same key in the new keystone catalog
20:05:28 <dhellmann> I read the logs from the first irc meeting, and noticed early on a discussion of an in-person whiteboarding session being scheduled, which seemed ironic
20:05:29 <edleafe> mordred: good point
20:05:44 <dhellmann> but I also agree with mordred in that I don't think API overlap is an issue
20:05:53 <mordred> if monasca has a pile of ceilometer's API but is also different in some ways BUT calls itself by a different catalog key - Im fine with it
20:05:56 <flaper87> mordred:++
20:06:04 <jaypipes> mordred: the key being claimed by monasca in the projects.yaml patch is "telemetry"
20:06:06 <sdague> mordred: I agree with that, unless they are both trying to claim the same service catalog entry, same API seems weird
20:06:18 <dhellmann> the problem with GBP wasn't the API, it was that they had not been able to work with the other teams working on networking, and that's a much lower-level feature than monitoring
20:06:26 <mordred> jaypipes: is that the key they intend to have in the new world order of catalog with standards?
20:06:28 <annegentle> do we have the Object Storage API implemented with ceph already?
20:06:29 <ttx> dhellmann: so you would also ask for more time before reconsidering the application ?
20:06:37 <dhellmann> ttx: yes, to see how the community thing works out
20:07:00 <ttx> Personally I'm on the fence. I think waiting for mitaka is fine
20:07:00 <jaypipes> dhellmann: there was also a number of points raised by me and mestery around the GBP API essentially supplanting the OpenStack Network API.
20:07:02 <flaper87> dhellmann:++
20:07:21 <mordred> because if that is the case, I would like to say "no" to similar but also different things claiming the same catalog id - that seems like  road to insane
20:07:32 <rhochmuth> i've left a lot of comments on why monasca isn't the same api as ceilometer
20:07:34 * flaper87 is catching up on the topic since he didn't attend the meeting where this was first discussed
20:07:38 <jaypipes> mordred: not sure. I suggested changing it to "monitoring" per rhochmuth's response to me about "what makes monasca different from ceilometer"
20:07:48 <annegentle> mordred: it would be crazy-making to have dupes in the catalog
20:07:50 <flaper87> so mostly speaking based on generic cases, tbh
20:07:52 <rhochmuth> also, i've commented on the community and the number of organizations involved
20:07:59 <dhellmann> jaypipes: right, if the rest of the community was not behind neutron, then I would support a competitor, but because there is support for neutron and it's a foundation piece I think the argument for duplication of feature set (not API, feature set) is a harder sell
20:08:03 <sdague> jaypipes: I agree that the service catalog entry should be changed
20:08:03 <ttx> jaypipes: in the GBP case there was the question of diluting a pretty fundamental project, which had questionable value for our users
20:08:12 <rhochmuth> i already think we are part of the openstack community
20:08:17 <mordred> rhochmuth: so, in short- you think monasca and ceilomter API are same or different?
20:08:21 <sdague> I also think that we should probably discuss monasca separate from GBP
20:08:24 <rhochmuth> they are different
20:08:27 <ttx> jaypipes: whereas in the monitoring game, multiple solutions are less likely to cause loss of value for our users
20:08:29 <dhellmann> mordred, annegentle : yes, we can't allow dupes in the catalog, that would defeat the purpose of all of the consistency work being done there
20:08:36 <rhochmuth> and the reasons have been documented
20:08:37 <mordred> rhochmuth: great. are you planning on wanting the same keystone catalog id?
20:08:48 <jaypipes> ttx dhellmann: sure, fair points both. I just thought there was enough similarity here for a pause before fast-tracking.
20:08:55 <dhellmann> jaypipes: ++
20:08:56 <rhochmuth> monasca is more than about monitoring of openstack resources
20:09:03 <sdague> rhochmuth: the concern is L1194 here - https://review.openstack.org/#/c/213183/1/reference/projects.yaml,cm
20:09:16 <mordred> rhochmuth: so you would not register in the keystone catalog as "telemetry" - but as "monitoring"?
20:09:17 <rhochmuth> it is also highly performance and in production today at scale
20:09:17 <flaper87> rhochmuth: I take that as a No to mordred's question
20:09:21 <ttx> jaypipes: I'm fine with a pause, I see no reason for fast-tracking. But we need to address the question of compatible APIs or not
20:09:29 <rhochmuth> i would register as monitoring
20:09:37 * flaper87 phew
20:09:39 <mordred> rhochmuth: awesome. I'm sold
20:09:40 <sdague> rhochmuth: ok, so you need to change L1194 then
20:09:44 <jaypipes> rhochmuth: yes, that's what I figured, thus my comment on the projects.yaml file...
20:09:44 <rhochmuth> originally when i wrote the submission i said monitoring
20:09:44 <mordred> rhochmuth: I tink we need to ^^ that
20:09:47 <flaper87> mordred: ditto
20:09:50 <rhochmuth> and changed to telemetry
20:09:58 <rhochmuth> do be honest i don't know the difference
20:10:01 <mordred> rhochmuth: sorry for the whiplash -let's change it back
20:10:12 <rhochmuth> sure, i would chnage back
20:10:17 <jaypipes> rhochmuth: thus my concern about overlapping APIs with the OpenStack Telemetry API ;)
20:10:20 <mordred> rhochmuth: the thing is is related to a spec up by anne and sdague to get a consistent set of standards into the keystone catalog
20:10:24 <dhellmann> rhochmuth: we don't want 2 projects using the same terminology there, because that's one of the key fields users have to tell projects apart
20:10:30 <rhochmuth> i tend to use monitoring and telemetry interchangeably
20:10:34 <mordred> rhochmuth: where we want to make sure we know what people are registering in the catalog as
20:10:34 <ttx> ok, so it seems we have a clear answer on the compatible APIs question
20:10:37 <annegentle> rhochmuth: yeah don't do that :)
20:10:41 <jaypipes> ttx: :)
20:10:46 <rhochmuth> ok, will switch to monitoring
20:10:48 <dhellmann> annegentle: ++
20:10:49 <lifeless> rhochmuth: thank ou
20:10:50 <ttx> the question of timing remains
20:10:59 <sdague> ok, so if this gets sorted, are there other pressing concerns?
20:11:15 <mordred> rhochmuth: in this case, it means that someone saying keystone.session.get_session_endpoint('telemetry') gets a ceilomter endpoint and ...('monitoring') gets monasca
20:11:23 <jeblair> ttx: the answer is "we are okay with different apis for similar services as long as they have different names" ?
20:11:26 <rhochmuth> sounds good to me
20:11:27 <annegentle> I would like resolution on the multiple languages support and details of that scope before voting on monasca to be honest
20:11:33 <flaper87> I seem to remember from the logs that there were some concerns about some Java code... Am I mixing up things?
20:11:34 <ttx> jeblair: seems to be
20:11:39 <rhochmuth> we actually want both ceilometer and monasca
20:11:40 <dhellmann> sdague: well, I'd like to see the team actually be able to use the IRC meeting space, instead of immediately jumping to in-person and screen-sharing systems again (as was brought up in their first irc meeting)
20:11:44 <annegentle> I'm not super comfortable with "we're Java now but we'll be Python on <timeline>"
20:11:58 <jaypipes> sdague: my final comment was this, which AFAIK, remains unaddressed: "Finally, another condition we asked the Fuel project to meet was alignment of the continuous integration systems used in Fuel development with those of the upstream infra CI. Does the Monasca community have a plan/roadmap for aligning with the upstream CI systems, particularly for the remaining Java parts of the Monasca project? We asked Fuel to put t
20:11:58 <jaypipes> his plan together. To not ask Monasca to do the same seems inconsistent to me."
20:12:02 <dhellmann> rhochmuth: yes, I appreciate your comments clarifying that ceilometer is a source of input for monasca
20:12:02 <flaper87> annegentle: ah-ha, so I'm not crazy. I did read that on the logs
20:12:04 <flaper87> :D
20:12:22 <rhochmuth> in the first irc meeting, we held it completely in irc
20:12:37 <rhochmuth> we had a performance issue that needed to follow-up
20:12:47 <rhochmuth> we discussed with all in irc how to do that
20:12:49 <mordred> jaypipes: totally. but I believe monasca has been doing 100% of its CI in upstream CI, so I think that bit is already done, no?
20:12:55 <sdague> dhellmann: ok, I consider that a fair point
20:12:59 <dhellmann> rhochmuth: yes, but one of the topics brought up was how to address an issue by having a separate meeting either in person or with screensharing, right?
20:13:00 <rhochmuth> many of us or local to the denver region
20:13:06 <mordred> jaypipes: (I agree it's inconsistent, I just don't think it's the case)
20:13:07 <jaypipes> mordred: our upstream CI supports testing Java components?
20:13:11 <mordred> jaypipes: yes
20:13:16 <rhochmuth> so we did a face to face and had cisco tele conference in
20:13:18 <jaypipes> ah, well awesome then.
20:13:21 <jeblair> mordred, jaypipes, rhochmuth: it looks like there are both java and python unit tests, but i don't see integration tests, and of course the java tests hit the internet for deps.
20:13:35 <dhellmann> "15:11:53 <rhochmuth> if it is just deklan and me, we could to a physical meeting, but if others want to be invovled, can do desktop sharing" from http://eavesdrop.openstack.org/meetings/monasca/2015/monasca.2015-09-02-15.00.log.html
20:13:37 <jaypipes> jeblair: ty for that info, appreciated.
20:13:41 <sdague> jeblair: right, but so does diskimage-builder, for instance
20:13:42 <mordred> jeblair, jaypipes: yah - there are places we need to flesh out the awesome for sure
20:13:48 <rhochmuth> so we are completely in irc, unless we need to use teleconferencing
20:13:50 <annegentle> rhochmuth: and are docs sphinx/rst/wadl (tobeswaggersoon)?
20:13:53 <mordred> sdague: we need to flesh out the awesome there too
20:13:53 <flaper87> does Monasca use rabbitmq ?
20:13:54 <rhochmuth> which in this cases was required
20:13:54 <sdague> so not hitting the internet is not just a sin of this project
20:14:03 <rhochmuth> monasca doe not use rabbitmq
20:14:03 * flaper87 should dig into this
20:14:04 <mordred> sdague: we need tons more awesome :)
20:14:06 <jeblair> so we've yet to have a java project volunteer to invest in fixing that
20:14:11 <ttx> SO the remaining question is... do we consider that they are already "one of us" or could use more time to align, no need to hurry
20:14:18 <jeblair> sdague: yes, but dib folks are actively engaged in fixing that
20:14:22 <flaper87> rhochmuth: any messaging technology?
20:14:32 <rhochmuth> we use kafka
20:14:47 <jaypipes> jeblair: perhaps a member of the Monasca contributor team might provide that necessary help on the Java project front.
20:14:57 <mordred> jaypipes: ++
20:15:00 <jeblair> jaypipes: i think that would be swell
20:15:00 <rhochmuth> rabbitmq can not sustaing the perofmrance we need, it is not durable, it does not handle ha well
20:15:06 <flaper87> rhochmuth: gotcha
20:15:27 * mordred has heard that there are humans who would like to discuss making an oslo.messaging backend for kafka
20:15:27 <flaper87> rhochmuth: not judging, just looking for some info :D
20:15:28 <sdague> jaypipes: yeh, that would be the right place for that to come from, it sort of feeds into the lang support discussion
20:15:44 <ttx> should we do a quick show of hands to solve that remaining question ?
20:15:58 <dhellmann> ++
20:15:59 <flaper87> mordred: yeah, there've been discussions since Atlanta
20:16:00 <lifeless> ++
20:16:02 <sdague> right, I've heard tons of rumble about kafka, so having something regularly poking that in upstream CI would be really interesting
20:16:02 <flaper87> mordred: no one has step up for that yet
20:16:10 <gordc> mordred: https://review.openstack.org/#/c/189006/
20:16:21 <mordred> gordc: well then!
20:16:28 <jaypipes> ttx: you mean the question on CI alignment?
20:16:40 <jaypipes> ttx: or soemthing else? sorry, got lost here a bit.
20:16:40 <flaper87> ttx: go
20:16:42 <sdague> ttx: yes, I'm not sure which question you are asking about
20:16:47 <mordred> I'm not sure what I'm showing my hands on
20:16:59 * mordred waves hands just on general principle
20:16:59 <ttx> <ttx> SO the remaining question is... do we consider that they are already "one of us" or could use more time to align, no need to hurry
20:17:11 <ttx> <ttx> should we do a quick show of hands to solve that remaining question ?
20:17:13 <annegentle> more time seems helpfu
20:17:17 <flaper87> gordc: oh, I had missed that
20:17:18 <annegentle> helpful even
20:17:23 <sdague> ttx: well, I thought the hurry was whether or not they get any space in tokyo
20:17:34 <mordred> ttx: I am comfortable with their level of one of us
20:17:38 <annegentle> yeah let's not hurry due to a summit
20:17:42 <rhochmuth> i don't need space tor tokyo
20:17:43 <jaypipes> ttx: gotcha. well, I think it would be more consistent if we asked for a bit of a "prove yourselves" period, as we did with Fuel.
20:17:45 <gordc> flaper87: it's been on and off. that said, i'm interested as well.
20:17:48 <ttx> well, space was allocated last week, so it's too late to get "regular" space now
20:17:51 <ddieterly> we are one of you
20:17:56 <jaypipes> ttx: 2 months, maybe.
20:17:56 <rhochmuth> will gladyl take spacei if available, but that isn't an issue to me
20:18:06 <mordred> I'm not sure what I'd be asking them to do or how I'd judge it
20:18:12 <rhochmuth> what is the action that i'm supposed to work on for 2 months?
20:18:19 <rhochmuth> would someone clarify this now?
20:18:23 <mordred> rhochmuth: ++
20:18:31 <rhochmuth> 6 serious companies are working on this
20:18:35 <dhellmann> rhochmuth: could you last 2 months with only video meetings?
20:18:36 <rhochmuth> in is deployed in production
20:18:40 <dhellmann> I mean only RIC
20:18:41 <dhellmann> IRC
20:18:50 <jaypipes> rhochmuth: I was looking for 8 unserious companies.
20:18:55 <rhochmuth> there was no problems with last weeks irc
20:18:56 <annegentle> rhochmuth: CI assignments, docs assignments?
20:19:00 <rhochmuth> i actually enjoyed that
20:19:07 <rhochmuth> has some advantages
20:19:12 <rhochmuth> like log files
20:19:15 <mordred> logging ++
20:19:19 <rhochmuth> i think the meeting was productive
20:19:26 <ttx> ok, let me start a quick show of hands poll for the TC members
20:19:37 <ttx> #startvote Can Monasca be considered "one of us" now or should it be given a couple months, waiting for Mitaka to further align to OpenStack ways? now, mitaka, dunno
20:19:37 <openstack> Begin voting on: Can Monasca be considered "one of us" now or should it be given a couple months, waiting for Mitaka to further align to OpenStack ways? Valid vote options are now, mitaka, dunno.
20:19:38 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
20:19:49 <mordred> #vote now
20:19:52 <jaypipes> #vote mitaka
20:19:58 <ttx> #vote dunno
20:19:58 <annegentle> #vote mitaka
20:19:58 <sdague> #vote now
20:20:08 <lifeless> #vote mitaka
20:20:08 <dhellmann> rhochmuth: you haven't addressed my question about this part of the conversation: http://paste.openstack.org/show/450730/
20:20:14 <flaper87> #vote mitaka
20:20:17 <dhellmann> #vote mitaka
20:20:18 <markmcclain> #vote mitaka
20:20:21 <lifeless> #vote now
20:21:01 <ttx> #endvote
20:21:02 <openstack> Voted on "Can Monasca be considered "one of us" now or should it be given a couple months, waiting for Mitaka to further align to OpenStack ways?" Results are
20:21:03 <openstack> mitaka (5): annegentle, jaypipes, dhellmann, flaper87, markmcclain
20:21:04 <openstack> now (3): mordred, lifeless, sdague
20:21:05 <openstack> dunno (1): ttx
20:21:20 <ttx> Looks like people are more comfortable tabling this for a couple months
20:21:21 <jeblair> i think it would be good to see some engagement on the CI front -- both in supporting java infrastructure and some integration testing
20:21:44 <rhochmuth> jeblair we are moving away from java
20:21:53 <jeblair> then that part isn't so important :)
20:21:55 <rhochmuth> and monasca is already in the ci/cd systems
20:21:58 <jaypipes> perhaps we might invite rhochmuth and ddieterly to the TC meeting on Monday in Tokyo and hold an in-person vote for Monasca?
20:21:59 <rhochmuth> we run unit tests
20:22:01 <rhochmuth> ...
20:22:17 <rhochmuth> what are we waiting for
20:22:27 <rhochmuth> not sure what is actionable on my part
20:22:29 <dhellmann> unit tests are good, but I'm not seeing any integration test jobs
20:22:34 <jeblair> rhochmuth: but there are no integration tests, right?
20:22:42 <mordred> rhochmuth: I think getting some devstack integration tests owuld be nice - especeially if you've got kafka stuff - that would actually likely be helpful for the oslo.messaging kafka folks to build on
20:22:43 <sdague> rhochmuth: right, integration tests seem kind of important
20:22:49 <ttx> maybe those who voted "mitaka" in the poll could detail what they would like to see in the coming months
20:22:50 <jaypipes> rhochmuth: time. trust. patience.
20:22:50 <rhochmuth> we have an entire suite of tempest tests in a separate repo that we would merge
20:22:50 <jeblair> probably something with a keystone service catalog entry ought to have an integration test
20:23:09 <anteaya> jaypipes: well said
20:23:13 <flaper87> I'd personally like to see more interactions with the rest of the community, perhaps better CI (integration tests)
20:23:22 <sdague> full stack testing in some regard at least
20:23:42 <ttx> Personally I'd like to see if the OpenStack ways work for you -- it's one thing to be forced to use IRC, it's another to come to appreciate what it brings you
20:23:46 <dhellmann> jeblair: ++
20:23:51 <jeblair> rhochmuth: have a link to those tests or that repo?
20:23:54 <anteaya> ttx agreed
20:24:00 <ttx> it's perfectly fine to discover that it doesn't work for you
20:24:01 <flaper87> I think nothing bad will happen in the next couple of months, if anything it's just some extra time to migrate more of the code to python, integrate with other parts of the ocmmunity and CI
20:24:13 <flaper87> so, I believe waiting is just for the better
20:24:34 <flaper87> other than that, I don't have anything against welcoming monasca in the big tent
20:25:12 <markmcclain> right and I since there's not an immediate pressing working a bit wider with CI, meetings makes sense before adding into tent
20:25:29 <ttx> so it looks like it won't gather the required votes today anyway
20:25:46 <ttx> and this should be tabled until Mitaka starts, when we'll reconsider Fuel as well
20:26:25 <ttx> anyone else wanting to detail what they expect from Monasca between now and then ?
20:26:40 <mordred> so - it might be good for one person to write up a $something that summarizes the above thoughts for rhochmuth ?
20:26:47 <sdague> rhochmuth: do you feel like you have a handle on what's expected of your team?
20:26:56 <rhochmuth> no, i do not know what you want
20:27:03 <rhochmuth> more irc meetings???
20:27:25 <rhochmuth> more community
20:27:30 <anteaya> rhochmuth: I think jaypipes made the point of patience
20:27:34 <dhellmann> I think my concerns were included in those summaries: more meetings using tools the community can all use & integration test jobs
20:27:40 <rhochmuth> do all the project that you've accepted have 6 companies working on it
20:27:42 <markmcclain> ++
20:27:48 <jeblair> * an integration test (likely based on devstack and tempest, using plugins)
20:27:58 <jaypipes> rhochmuth: nope, that doesn't have anything to do with this vote result.
20:28:06 <ttx> rhochmuth: I'd like to feel that you're one of us. Not that you're forced to adopt our ways to pass a bar
20:28:08 <flaper87> jeblair: ++
20:28:14 <lifeless> so
20:28:19 <dhellmann> rhochmuth: the criteria we use to evaluate a project are listed at http://governance.openstack.org/reference/new-projects-requirements.html
20:28:23 <lifeless> we don't have integration tests as a requirement in the governance
20:28:36 <rhochmuth> do all other projects have integration tests
20:28:40 <dhellmann> lifeless: The project has core reviewers and adopts a test-driven gate in the OpenStack infrastructure for changes
20:28:42 <lifeless> have we uncovered another thing we should be requiring?
20:28:46 <rhochmuth> anyway we have a suite of integration tests in a repo
20:28:46 <jeblair> lifeless: it's true, however, this project, at the point it is in its development, should have one.
20:28:49 <lifeless> dhellmann: yes, which it has
20:29:15 <jeblair> lifeless: if it were a less mature project, i would not ask it to develop one first
20:29:16 <lifeless> jeblair: so we wouldn't have asked for it if they'd become one-of-us earlier ?. I am confused.
20:29:28 <sdague> rhochmuth: right, but most projects run those on every commit
20:29:33 <rhochmuth> https://github.com/hpcloud-mon/monasca-tempest
20:29:46 <sdague> definitely all the projects we consider mature
20:29:47 <jaypipes> why is it so hard to ask for just time to pass so that we can see the new community processes/meetings/collaboration is not just all for show?
20:30:07 <dhellmann> rhochmuth: are those in gerrit, too?
20:30:21 <rhochmuth> no, we have not merged them with gerrit
20:30:22 <sdague> jaypipes: well I think that letting time pass was agreed
20:30:29 <dhellmann> jaypipes: yeah, that's my bigger concern
20:30:31 <anteaya> jaypipes: I am really glad you have that position
20:30:35 <sdague> I think the question is on other more concrete things
20:30:35 <dhellmann> rhochmuth: are there other parts of monasca not in gerrit?
20:30:43 <anteaya> jaypipes: you also mentioned trust earlier as well
20:30:45 <jeblair> lifeless: i think for a project to get to this level of maturity and not have an uptream integration test shows that it was not developed as an openstack project.  this is something specific to this project that needs to be remedied.
20:30:46 <fungi> i have to concur, it seems odd for a "one of us" project to prefer to start developing their tests in a github repo
20:30:49 <sdague> which did get brought up, the point of critical bits not in gerrit is good
20:30:52 <flaper87> jaypipes: dunno (?)
20:30:54 <rhochmuth> all the source is in gerrit
20:31:08 <ttx> OK, we really need to write a more explicit response here
20:31:10 * flaper87 connection is lagging like crazy and he's not even on a plane
20:31:13 <rhochmuth> there are a bunch of repos for Ansible and side project not part of the core submission
20:31:23 <ttx> any volunteer to draft that over the coming week ?
20:31:28 <dhellmann> rhochmuth: why aren't those part of the project?
20:31:30 <flaper87> I'm happy to collect it and report back to the review
20:31:42 <dhellmann> I'll work with flaper87
20:31:42 * flaper87 read ttx's mind
20:31:43 <jaypipes> flaper87: ty.
20:31:50 <flaper87> dhellmann: danke!
20:31:51 <flaper87> jaypipes: np
20:32:12 <rhochmuth> a tester developed the monasca tempest test and was unfamilier with next steps
20:32:15 <dhellmann> and a late ++ to jeblair's comment
20:32:18 <ttx> flaper87: awesome. Etherpad and -tc list should do
20:32:41 <dhellmann> rhochmuth: ok. that does need to be addressed, though.
20:32:48 <rhochmuth> the ansible is not part of gerrit, becuase it isn't really considered core
20:32:58 <ttx> we need to move on
20:33:27 <ttx> #action flaper87 to draft a clearer response with TC expectations
20:33:43 <ttx> #agreed Monasca application tabled until start of Mitaka cycle
20:34:12 <ttx> #topic Add team:danger-not-diverse tag
20:34:16 <ttx> #link https://review.openstack.org/218725
20:34:20 <annegentle> thanks flaper87
20:34:27 <ttx> jogo proposed a tag to describe project teams that are "dangerously" not diverse.
20:34:35 <flaper87> annegentle: np :)
20:34:39 <ttx> I think that's a great data point to communicate out -- projects that rely on a single company or where only two companies are contributing are fragile
20:34:46 <annegentle> I had a late "danger is judgemental" comment :)
20:35:01 <sdague> annegentle: I think judgemental is fine here
20:35:10 <ttx> yeah, i think it's fine too
20:35:12 <sdague> because this is really not a state we want any project to be in
20:35:19 <ttx> consumers of the project should know that before they choose to invest in deliverables produced by that team
20:35:37 <ttx> There are fragile (or already dead) projects in the big tent today
20:35:44 <dtroyer> a simple non-diverse would work too, but I agree the extra bit implied by danger is ok here
20:35:44 <sdague> personally I probably would have dropped the 2 orgs at 95% bit
20:35:45 <annegentle> sdague: danger to whom? Might be a sign that the project should break up anyway? fragile might be better
20:35:49 <dhellmann> I think it's fine to say "danger" but I'm less comfortable assuming that lack of diversity is associated with a lack of desire for diversity, as is implied by line 14
20:35:58 <sdague> annegentle: dangerous to adopters
20:35:58 <dhellmann> (of draft 4)
20:36:05 * jaypipes curious what benefit this explicit negative tag has versus just the absense of the diverse-affiliation tag
20:36:16 <ttx> fragile-not-diverse ?
20:36:17 <annegentle> sdague: ok
20:36:24 <dhellmann> jaypipes: it identifies the other end of the spectrum
20:36:35 <ttx> jaypipes: you may not have a divcerse affiliation, but still not be fragile
20:36:38 <dtroyer> jaypipes: it's the red zone just before you run out of gas
20:36:42 <annegentle> I think it's a valid measure
20:36:50 <jeblair> dhellmann: i strongly endorse your objection.
20:36:56 <jaypipes> dhellmann: by that token, should we add tags for "doesn't-assert-deprecation-policy"?
20:37:14 <ttx> jaypipes: well, that more binary
20:37:15 <dhellmann> jaypipes: no, because that's a boolean. diversity is a float
20:37:26 <ttx> dhellmann: ++
20:37:36 <sdague> jaypipes: if you have a different set of labels to get 3 states here, those are welcomed
20:37:44 <sdague> but this is a tristate, not a dual-state
20:37:50 <jaypipes> dhellmann: I agree 100.0000028283 percent.
20:37:59 <jeblair> jaypipes: and yes, i also wonder the same thing -- i thought when we added the 'diverse' tag that was sufficient.
20:38:10 <angdraug> I thought tags were supposed to be boolean?
20:38:12 <jeblair> sdague: what are the three states?
20:38:16 <ttx> seriously, I think it's great that MagnetoDB gets the tag. It's pretty dead now that Mirantis seems to have pulled from it
20:38:25 <jaypipes> angdraug: they were supposed to be, yes.
20:38:30 <ttx> and if we had the tag before every consumer could have seen it coming
20:38:30 <sdague> diverse-affiliation, none, diversity-danger
20:38:33 <jaypipes> angdraug: either you have the tag, or you don't.
20:39:21 <sdague> it is not possible for 1 project to have both tags, it is possible for a project to have neither tag
20:39:31 <angdraug> why then should diversity be any special? either the project is diverse, or it's not, why add a third state of "kinda diverse but kinda not enough"?
20:39:34 <sdague> so they are 2 binary tags, that together represent a tristate
20:39:35 <jeblair> sdague: i'm not sure "low, medium, high" diversity helps me decide that something is well supported as much as "almost none, some" diversity.
20:39:43 <jaypipes> this isn't quite like the ops "tags" stuff, where you have a value part like "packaged:76%" or something, but this is less than ideal, IMHO... more confusing than anything.
20:40:06 <ttx> those tags answer different questions.
20:40:18 <ttx> One says the project is produced by a diverse community
20:40:25 <ttx> $The other says the projecvt is at risk
20:40:28 <sdague> honestly, I think this is hugely important to be explicit about the fact that we have a set of really healthy projects that clearly can handle one or more big players falling out
20:40:45 <angdraug> ttx: what's the value of the first one if not to mitigate the risk represented by the second one?
20:40:48 <jeblair> sdague: me too, i consider that the diversity tag.
20:40:50 <sdague> and on the other end a set of projects which are very clearly at the whim of a single orgs budge cycle
20:40:51 <ttx> Every project that the tag is applied to is in danger of not being there tomorrow
20:41:01 <jaypipes> ttx: I disagree. One says the project is diverse or a project is not diverse. The other doesn't say something positive at all.
20:41:26 <mordred> I think it's a trinary state which our tags don't show
20:41:26 <jeblair> sdague: i guess i don't see the middle road as being not in danger.  i think anything without the current diversity tag is in danger.
20:41:38 <jaypipes> ttx: couldn't you say the same thing about any project without the diverse-affiliation tag?
20:41:40 <mordred> the diversity tag has a much different threshold
20:42:03 <jeblair> i think any project without the diversity tag is unhealthy.  i certainly thought that when infra lost it.
20:42:04 <ttx> jaypipes: I think they are not indanger. They are not produced by a diverse community, but they shuold survive a given company pulling out
20:42:04 <angdraug> jeblair: ++
20:42:05 <sdague> jeblair: infra is not going to collapse if a single org has a priority shift. cue will
20:42:14 <sdague> as a for instance
20:42:19 <sdague> that's a really concrete one
20:42:28 <jeblair> sdague: i'm worried about it.
20:42:31 <ttx> jeblair: unhealthy doesn't mean in immediate danger of dying.
20:42:45 <ttx> which is what I mean by answering two different questions
20:42:50 <flaper87> jeblair: ++
20:42:58 <mordred> perhaps if the tag was named non-negatively
20:42:59 <ttx> sdague: ++
20:43:04 <annegentle> still points to "danger" and "fragile" as not really describing this
20:43:05 <angdraug> Fuel is in no immediate danger of dying even though it's definitely a Mirantis monoculture
20:43:08 <mordred> so that the meaning could be captured - but not with the negative voice?
20:43:25 <sdague> jeblair: I agree that it's a concern, but it won't literally cease to exist if one of the orgs changes priorities in their annual budget review
20:43:26 <jeblair> ttx: i think i'm starting to see where you and sdague are coming from.  i think this may be a matter of audience.
20:43:42 <ttx> angdraug: Fuel can die is a single person decides it. That is what I call "danger";
20:43:46 <flaper87> mordred: ++
20:43:54 <jaypipes> angdraug: I think what folks are saying is that Fuel *is* in danger of dying if Mirantis goes belly up, simply because it is not a diverse affiliation.
20:43:56 <sdague> we have a set of projects that will completely cease to exist if an exec at one org decides to move people around
20:43:59 <jeblair> as a user, or even general observer of the project, i think my primary concern is whether a project is healthy (diverse) or not
20:44:14 <mordred> jaypipes: yah. and we'd like for that not to be the case, beause fuel is pretty cool - as is cue
20:44:24 <jeblair> sdague, ttx: i agree there is a further degree that you have articulated here, but what audience is that of use to?
20:44:30 <flaper87> while I understand the points behind flags being booleans, I also see how, in this specific case, it's useful to have it describing something else other than yes/no
20:44:35 <mordred> jaypipes: so I tihnk what I'd like to communicate is "opportunity for other people to make a difference by getting involved"
20:44:37 <sdague> jeblair: operators deciding to deploy a component
20:44:38 <ttx> angdraug: MagnetoDB is in the bug tent, has the tag, was removed from Mirantis priorities apparently and is now a zombie project
20:44:41 <jeblair> sdague, ttx: users should already have panicked based on not having diverse
20:44:43 <sdague> and thus taking on support
20:44:56 <sdague> this is actually a question that gets asked
20:44:58 <angdraug> given the amount of activity around Fuel and number of people using it, it's very likely that all that will be picked up by current users of Fuel even if Mirantis pulls out of it
20:45:04 <jeblair> sdague: right, i guess i think that's the diverse tag.
20:45:06 <jaypipes> mordred: well, branding a project with a negative "diverse-affiliation-danger" tag is unlikely to inventivize a project. negative incentives rarely work in the way that positive ones do, IME.
20:45:08 <flaper87> mordred: that's exactly what I "not so diverse but could be" state would mean to me
20:45:15 <flaper87> and I think we should have a way to express that
20:45:17 <ttx> jeblair: I still think the projects the tag applies to are in more... immediate danger.
20:45:20 <mordred> jaypipes: right. that's why I'm syaing we should hav ea better name
20:45:21 <mordred> jaypipes: or whatnot
20:45:24 <jeblair> sdague: are there really people willing to deploy something "somewhat non-diverse but not dangerously so"?
20:45:36 <sdague> jeblair: yes, I think so
20:45:40 <flaper87> jeblair: I really hope there are
20:45:44 <mordred> jaypipes: just I think the piece of information encoded is potentially useful in a positive way - I agree the name is incendiary
20:45:51 <flaper87> otherwise there's close to no chance for new projects to evolve and improve
20:45:54 <flaper87> i.e Zaqar
20:45:57 <sdague> jeblair: because the option is "implement it yourself"
20:45:59 <flaper87> or Cue
20:46:09 <markmcclain> team:really-needs-contributors
20:46:15 <jaypipes> heh
20:46:17 <ttx> OK, looks like we can iterate a few times on the patch
20:46:24 <ttx> We ahve a few other items to cover today
20:46:29 <dhellmann> looking at http://stackalytics.com/?project_type=all&module=monasca-group monasca would get this tag
20:46:34 <sdague> dhellmann: yep
20:46:44 <mordred> it took sometihng like 3 years before infra had humans working on it who weren't on my team ... and during that time we _constantly_ sounded the danger gong
20:46:45 <jaypipes> yeah, I'm not 100% opposed to this tag or anything... just would like it to be positive rather than negative if possible.
20:46:45 <dhellmann> so they have 6 companies, but HP is doing 90% of the review work
20:47:10 <sdague> in the old days we'd have rejected all these projects, in the new days I think it's fine to have them in, but just mark them as being really seriously in danger
20:47:16 <jeblair> i'm okay with the negative but still wrapping my head around its utility.  :)
20:47:18 <ttx> sdague: ++
20:47:32 <sdague> and I think negative connotation is good here, as it makes people want to make it a priority to get out of that zone
20:47:41 <jeblair> sdague: oh!
20:47:44 <ttx> OK, let's move on, please comment on the review and talk to jogo directly
20:47:44 <sdague> which hopefully leads them down a path to an actual diverse project
20:47:49 <jaypipes> sdague: we'll agree to disagree on that motivator :)
20:47:55 <markmcclain> jeblair: I look at as grading risk severity
20:47:57 <jeblair> sdague: i think my biggest disconnect is that this makes "lack of diversity" seem less negative than i think it is.
20:47:59 <mordred> jaypipes: I disagree about agreeing
20:48:04 <jaypipes> lol
20:48:05 <ttx> #topic OpenStack programming languages resolution
20:48:12 <jogo> ttx: just leave comments on the review, I am more async these days
20:48:13 <ttx> #link https://review.openstack.org/217710
20:48:22 <ttx> We discussed this one last week.
20:48:29 <ttx> I tweaked the initial proposal to remove language that sounded preemptively negative to language addition ("silo", "convenience"...)
20:48:30 <mordred> jogo: are you more pinsync?
20:48:35 <jaypipes> jogo: don't you mean "pinsync"?
20:48:40 <ttx> To cover annegentle's concerns I expanded on the "exception" clause, and to cover jeblair's concerns I removed the silly 2/3 vote clause
20:48:41 <annegentle> heh you guys
20:48:51 <ttx> I think it's pretty neutral now: it opens the door and says "there are benefits and drawbacks, we'll consider it when it comes"
20:49:09 <ttx> I see annegentle left a few comments earlier today
20:49:10 <jogo> :)
20:49:45 <jeblair> ttx: the requirement to use common sense seems daunting.
20:49:47 <jeblair> ;)
20:49:48 <flaper87> I'm good with that resolution, I'm just waiting on the next version w/ fixes to annegentle's concerns
20:49:53 <annegentle> ttx: what about the other side's benefits and drawbacks, each time I review this I keep thinking there's soo much overhead to being an OpenStack project, we should also document expectations for ci/docs/test/etc
20:49:56 <mordred> annegentle: I think I want SDKs to submit if they want to submit - I'm not sure this resolution to me is about incentivizing or not incentivzing people to want to be here
20:49:56 <sdague> ttx: so I guess lines 25-28 seem to beg "where is the list of current supported languages"
20:50:00 <ttx> I'm fine with Anne's language suggestion for line 28
20:50:15 <ttx> sdague: it's higher in the resolution
20:50:21 <mordred> annegentle: but rather, for people who do want to be here, providing clarity on how we're going to think about that - and to let them know we welcome the theory but that there is work
20:50:36 <sdague> ttx: so it should be probably called out directly
20:50:40 <mordred> annegentle: (I agree, for a lot of them I bet they would not find it valuable and I do not expect to see them beating down our door)
20:50:48 <annegentle> it's completely insane to keep up seven languages for docs, ci, test, translation (believe me I know the SDK work_
20:50:49 <sdague> The currently supported languages in OpenStack are: bash, python, javascript
20:51:12 <ttx> OK, I can make a new patchset with that and Anne's new wording
20:51:28 <ttx> sdague: could you please add it as a review comment so that I don't forget ?
20:51:31 <sdague> yep
20:51:38 <annegentle> mordred: right, so why would we encourage sdks to submit, only to unfurl a list of requirements a mile long? (I'm exaggerating, sure)
20:51:54 <flaper87> if we add a list of programming languages, we gotta make sure we keep it updated
20:51:56 <ttx> annegentle: maybe cross that bridge when we get there ?
20:51:59 <annegentle> and, how do we still encourage people to make SDKs for OpenStack
20:52:09 <flaper87> I'm fined with either adding it or not, really.
20:52:15 <ttx> flaper87: we'll probably have to have a reference document, this is a (dated) resolution
20:52:20 <EmilienM> sdague: PuppetOpenStack + Infra modules are in Puppet+ruby
20:52:35 <ttx> #action ttx to make another patchset
20:52:37 <mordred> annegentle: I'm not sure we're doing that
20:52:57 <ttx> EmilienM: they have an exception under the resolution
20:53:09 <sdague> ttx: the exceptions should be called out explicitly as well then
20:53:10 <mordred> annegentle: and we can't even get people to work on the existing python one inside of openstack - so I'm not even thinking about trying to get people to work on _other_ sdks in openstack
20:53:16 <annegentle> mordred: right
20:53:23 <flaper87> EmilienM: the resolution is about services specifically
20:53:37 <annegentle> flaper87: I think it should be, but is the language that way now?
20:53:37 <flaper87> mordred: true that
20:53:40 <ttx> sdague: I don't think a resolution needs to call all the rules out. I added "let's use common sense", which means, we'll discuss it when it comes
20:54:06 <ttx> anyway, no time so let's move on
20:54:08 <edleafe-> ttx: which also means that this document doesn't provide much information
20:54:17 <flaper87> annegentle: that's how I read it or at least I think I did :P
20:54:23 <flaper87> annegentle: u messing with my weak brain?
20:54:26 <flaper87> :D
20:54:35 <ttx> edleafe-: sure, it's just saying "bring it on, we'll discuss it", which is better than "meh, no idea if it's ok"
20:54:42 <ttx> #topic Applies naming guidelines to service object
20:54:46 <ttx> #link https://review.openstack.org/201670
20:54:47 <sdague> ttx: I guess, except I think we don't all agree on the costs vs. benefits here. common sense assumes we're all on the same page there
20:54:52 <annegentle> flaper87: never :)
20:55:01 <ttx> This one seems ready
20:55:04 <ttx> I'll approve it now
20:55:09 * flaper87 agrees
20:55:14 <flaper87> ready, ship it. BAM!
20:55:18 <annegentle> woo!
20:55:19 <ttx> #topic Creates labs project
20:55:22 <ttx> #link https://review.openstack.org/218346
20:55:25 <ttx> I added this one to the agenda because it raises an interesting question
20:55:30 <ttx> We said repo additions are fine as long as the PTL wants it
20:55:35 <edleafe-> sdague: exactly
20:55:39 <ttx> But usage of generic names in a single namespace (like "openstack/labs") stretches it
20:55:52 <ttx> I have two concerns: generic names can be a bit misleading: what if ceilometer wanted to get "openstack/documentation" for example ?
20:55:58 <annegentle> yeah we have had multiple discussions :)
20:56:01 * flaper87 agrees w/ ttx's comment
20:56:05 <ttx> the other is the potential consequence: the risk of a repo rename when we realize that was not such a good idea
20:56:09 <annegentle> and I personally am not a fan of labs
20:56:25 <annegentle> so he has brought it back to the -docs mailing list for more naming ideas
20:56:40 <dhellmann> these are labs for use during training exercises?
20:56:58 <jeblair> ttx: i think bringing this for discussion was a good call, thank you.
20:57:15 <anteaya> I think jogo makes a good point
20:57:44 <annegentle> dhellmann: these are labs that follow the install guide so that trainers can use them for training classes at say user group meetings
20:58:12 <dhellmann> annegentle: ok. I suggest that the name include some form of "training" then, for enhanced clarity. :-)
20:58:15 <sdague> annegentle: so what's going to be in this repo? is it docs, or is it code like vagrant scripts?
20:58:21 <annegentle> dhellmann: also what I wanted :)
20:58:21 <anteaya> provide automated way of deploying a multi node OpenStack cluster
20:58:24 <annegentle> sdague: it is scripts
20:58:26 <ttx> annegentle: ok, so other names will be suggested ?
20:58:28 <anteaya> automated
20:58:29 <dhellmann> sdague: this seems to be related: http://specs.openstack.org/openstack/docs-specs/specs/liberty/openstacklabs.html
20:58:32 <annegentle> ttx: already were :)
20:58:43 <flaper87> annegentle: cool
20:58:51 <annegentle> dhellmann: sdague: yes that's their blueprint
20:59:09 <ttx> ok, cool, I think we are good then. i'll freeze that one until we are ok it's less of a rename wanabee
20:59:10 <sdague> annegentle: that doesn't have a lot of detail
20:59:13 <jeblair> this seems really similar to devstack's reason for existing
20:59:25 <sdague> yeh, or yet another installer.
20:59:25 <ttx> #topic Open discussion
20:59:45 <ttx> I skipped the workgroup reports, comms did a post last week
20:59:55 <flaper87> #link http://www.openstack.org/blog/2015/09/technical-committee-highlights-september-2-2015/
21:00:01 <ttx> and cross-project-track is still forming up
21:00:11 <ttx> and.. we are out of time
21:00:14 <annegentle> sdague: agreed
21:00:23 <flaper87> o/
21:00:25 <EmilienM> ttx: as usual :P
21:00:27 <annegentle> tweet it!
21:00:28 <annegentle> :)
21:00:33 <ttx> Sorry that was a bit rushed, but those were all valuable and important discussions
21:00:46 <dhellmann> ++
21:00:53 <ttx> I should have seen they would overflow and schedule a little less
21:01:06 <ttx> I guess I was fooled with how smooth difficult discussions have gone lately
21:01:12 <ttx> #endmeeting