20:02:00 <ttx> #startmeeting tc
20:02:01 <openstack> Meeting started Tue Oct  6 20:02:00 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:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:04 <openstack> The meeting name has been set to 'tc'
20:02:09 * maishsk is lurking
20:02:10 <mordred> o/
20:02:10 <ttx> This is the last of the meetings for the liberty membership !
20:02:16 <ttx> Next week we'll seat the newly-elected members.
20:02:22 <flaper87> o/
20:02:24 <ttx> Our agenda for today:
20:02:29 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:02:43 <ttx> #topic Add Astara to OpenStack Projects List
20:02:50 <ttx> #link https://review.openstack.org/194892
20:03:09 <ttx> This one seems to have triggered some opposition, not really on the "are you one of us" aspect, but more about being created as a separate project team from Neutron
20:03:21 <ttx> Maybe someone opposed could re-voice their concern here, so that we can take it under consideration ?
20:03:38 <russellb> i don't have much to add here, i've commented heavily on the review
20:03:56 * ttx refreshes
20:04:09 <annegentle> even with coffee I was having trouble understanding why propose outside of neutron?
20:04:09 <mordred> I'm not worried about it not being in neutron personally - since it's not aiming at user-facing api stuff
20:04:17 <flaper87> I've reviewed and I'd like russellb's concerns to be addressed.
20:04:18 <mordred> to me, it's more like ovn
20:04:25 <mordred> than like something that would exist in neutron
20:04:39 <jeblair> flaper87: which ones?  i think the only outstanding is "consensus with neutron ptl"
20:04:45 <russellb> we did the more important point to me which was whether or not it intended to expose any of its own tenant facing APIs (it does not)
20:04:46 <mestery> morgan: OVN exists in Neutron
20:04:49 <mestery> mordred: ^^^^
20:04:51 <annegentle> mind, I do appreciate the further explanations people put in this afternoon
20:04:53 <russellb> we did *clarify*, i mean
20:04:56 <lifeless> o/
20:04:59 <russellb> mestery: i think he means OVN itself vs the driver
20:05:00 <lifeless> sorry, reviewing :)
20:05:02 <mordred> mestery: ovn _plugin_ exists in neutron
20:05:05 <mestery> russellb: YEah, :)
20:05:06 <mordred> mestery: ovn exists in ovs
20:05:07 <mestery> mordred: Yuppers
20:05:16 * mestery is slow today
20:05:20 <mordred> I believe an astara plugin for neutron should be in neutron
20:05:21 * stevemar_ sneaks in late
20:05:21 <ttx> russellb: yes, I agree that clarifying that they would not do a competing API over the long run was important
20:05:21 <jeblair> and this proposal has the astara plugin in the stadium
20:05:28 <mordred> sweet
20:05:30 <sdague> mordred: and I believe that was proposed
20:05:32 <adam_g> it wasnt mentioned in review but worth noting that astara consumes and uses nova as much as neutron (to actually do the orchestrating)
20:05:33 <russellb> ttx: that was my biggest concern for the previous -1
20:05:35 <mordred> sdague: ++
20:05:40 <dhellmann> russellb, mestery : was your main concern the idea that there might be a tenant-facing API?
20:05:58 <flaper87> jeblair: I meant the one w.r.t the API and the agreement with neutron's PTL
20:06:06 <ttx> mestery: were your concerns addressed by the Astara team answers ?
20:06:09 <russellb> i also feel that inclusion in Neutron should be considered, but i'm not interested in forcing it from the TC level.  that's between the projects
20:06:09 <flaper87> at least, discussion. Probably agreement is not the right word
20:06:14 <annegentle> autonomy? access to OpenStack-ish stuff?
20:06:16 <mestery> ttx: Ack, refresh again please :)
20:06:23 <ttx> (and armax's concerns)
20:06:23 <russellb> i don't think 25 OpenStack projects implementing different pieces of Neutron is what we want, though
20:06:27 <russellb> and that's why most things are in Neutron today
20:06:29 <jaypipes> adam_g: could the orchestration aspect of astara-rug be done with Heat?
20:06:29 <adam_g> mordred, the current akanda-neutron plugin (soon to be astara-neutron) could/should be
20:06:38 <mordred> adam_g: ++
20:06:46 <mestery> adam_g: ++, nice
20:06:51 <sdague> annegentle: personally, I think there is a already *a lot* in neutron, and I don't think it's a success story for either neutron or astara to force fit them
20:06:54 <flaper87> ok, re-reviewed
20:06:55 <adam_g> jaypipes, not to my knowledge
20:07:05 <annegentle> sdague: yeah sdn could / would eat the world
20:07:21 <dhellmann> jaypipes: no, IIRC, it requires using admin APIs in some cases to make connections to networks not owned by the tenant
20:07:24 <mestery> I don't this is SDN folks
20:07:25 <ttx> Alright. Any other concern, then ?
20:07:27 <mestery> It's an ochestrator
20:07:30 <russellb> i don't see it as a force fit when literally it's entire purpose in life is to be a neutron backend
20:07:31 * armax lurks
20:07:35 <jaypipes> adam_g, dhellmann: got it, thank you.
20:07:46 <annegentle> mestery: that's helpful thanks
20:08:19 <flaper87> not from me
20:08:26 <mordred> russellb: I thnk for me keeping a separation between nova and neutron and the things that they drive is good - splitting ironic out into its own thing has been great for both nova and ironic, for instance
20:08:33 <mordred> russellb: but I understand the concern
20:08:47 <russellb> i'm not concered enough on that point to -1 over it
20:08:51 <dhellmann> mordred: good analogy
20:08:59 <russellb> they're also different projects
20:09:10 <russellb> in different industries, with different cultures
20:09:12 <SpamapS> russellb: Ironic's sole purpose in life was to be a backend for Nova.
20:09:15 <russellb> it's amazing how different they are, really
20:09:37 <russellb> but anyway, i don't want to take up an hour going off on the theory of why i think as much unification in neutron is beneficial
20:09:52 <russellb> i just hope everyone understands that there's been a ton of thought and good reasoning behind how the project is structured
20:09:56 <ttx> OK, it's got 9 YES, without markmcclain's vote
20:10:02 <lifeless> I don't think rejecting them from the tent would make unification happen either
20:10:13 <russellb> i'm not suggesting rejection
20:10:16 <mestery> russellb: Obviously armax and I understand, thanks for bringing that up :)
20:10:20 <annegentle> armax: Armando, if you're good with the integration I think my questions are answered
20:10:27 <russellb> but there was pushback to the suggestion that unification should be considered
20:10:28 <dhellmann> russellb: are there other parts of neutron that implement similar amounts of backend pieces vs. just drivers? I'm honestly uninformed on that.
20:10:31 <lifeless> russellb: sure, I get that
20:10:35 <russellb> dhellmann: absolutely, several
20:10:41 <dtroyer> one suggestion was to put it under Neutron and move out later if that were determined to be the Right Thing.  That works both ways…
20:10:42 <russellb> i mentioned that multiple times in my review comments
20:10:44 <dhellmann> russellb: ok, cool
20:11:00 <ttx> russellb: I'm not against them going inside neutron if they prefer, I'm against rejecting their application because they prefer to be a separate team
20:11:07 <dhellmann> russellb: well, it wasn't clear initially that folks understood what this actually was so I wasn't sure
20:11:12 <russellb> the many pieces referred to as the "reference implementation" for L2 and L3, octavia, the default vpnaas backend, others i'm sure
20:11:19 <armax> annegentle: I’ll will have to go through the comments/logs etc…but my initial position is
20:11:20 <annegentle> dhellmann: russellb: right I'm definitely in that camp
20:11:22 <flaper87> ttx: ++ my thoughts exactly
20:11:30 <russellb> dhellmann: right, it was also clear ot me that not everyone understood what this was, or what is in neutron.
20:11:38 * dhellmann nods
20:11:40 <ttx> I'm going to approve it now unless someone screams and has more questions
20:11:41 <russellb> ttx: yep, fair
20:11:49 <annegentle> ttx: give me a sec to click please
20:11:54 <armax> so long as the TC is happy with the proposal, I am comfortable with their decision
20:12:08 <armax> and won’t stand in the way
20:12:11 <lifeless> armax: does Neutron have a strong opinion here?
20:12:19 <lifeless> armax: e.g. 'this really should be part of Neutron' ?
20:12:25 <armax> lifeless: does that count?
20:12:44 <sdague> armax: it's data, all data counts
20:12:50 <mestery> lifeless: Did you read the review?
20:12:58 <lifeless> armax: its certainly a factor. I would hesitat before doing something that made an OpenStack project PTL unhappy
20:12:59 <mestery> wow
20:13:03 <armax> I expressed my opinion
20:13:05 <annegentle> armax: well, I for one rely on the PTL to do the front-line comms
20:13:07 <russellb> did you read the review?
20:13:09 <mestery> I think armax russellb and I all commented there I thought?
20:13:15 <lifeless> mestery: presumably not closely enough
20:13:19 <mestery> lol
20:13:22 * lifeless re-reads
20:13:23 <flaper87> armax: all input from the community is extremely important
20:13:26 <russellb> right, current neutron PTL, previous neutron PTL, and myself all commented to that effect
20:14:05 <ttx> Yes, Neutron leadership would have preferred that Astara was added within the Neutron team rather than as a separate team
20:14:11 * jaypipes personally liked the introduction of the very OpenStacky word "tenantive"
20:14:28 <flaper87> jaypipes: lol
20:14:30 <annegentle> jaypipes: +1
20:14:42 <ttx> ok, approving now
20:15:00 <edleafe> jaypipes: heh
20:15:06 <armax> so long as someone is policing that the astara team stays true to their words
20:15:06 <armax> then I am happy with what they are doing
20:15:22 <armax> but I am not sure if anyone is
20:15:22 <dhellmann> armax: policing how? what are you worried about them doing?
20:15:24 <mestery> Who's gonna do that?
20:15:31 <ttx> approved
20:15:33 <russellb> in theory the TC has that authority
20:15:37 <ttx> yes
20:15:39 <russellb> if concerns are raised in the future
20:15:48 <sdague> sure, but I guess what's the concern that should be looked for
20:15:52 <flaper87> russellb: ++
20:15:54 <markmcclain> armax: the networking APIs are tough enough... last thing I'd want to do is write another
20:15:55 <annegentle> armax: really the PTL has that day-to-day communication with teams.
20:15:56 <lifeless> The big tent also explicitly allows for competition
20:15:59 <russellb> new tenant facing APIs
20:16:01 <dhellmann> I'm pretty disturbed at the implication of bad faith here. :-(
20:16:02 <ttx> if the assumptions we are operating on for this decision are contracdicted by fact, we can undo what we've done
20:16:03 <lifeless> *if* it goes that way
20:16:05 <russellb> as discussed in several review comments .......
20:16:07 <armax> say that the API all of a sudden becomes tenant facing etc
20:16:07 <armax> who is going to make sure that there’s no overlap...
20:16:13 <armax> I am not saying there’s foul play or even intention for it
20:16:14 <russellb> it would be nice if people read the review in advance of the meeting
20:16:17 <dhellmann> lifeless: this project does not in any way compete with neutron
20:16:20 <armax> but this does open a loophole
20:16:26 <armax> or at least it feels like it does
20:16:29 <armax> but don’t mind me
20:16:32 <armax> I am paranoid
20:16:33 <lifeless> dhellmann: armax explicitly raised a concern about such things in the review
20:16:46 <armax> I am not going to watch over their shoulders
20:16:52 <armax> Astara or anyone else
20:16:56 <lifeless> russellb: the meeting is literally the first thing my morning. I try but sometimes family things happen and its a rush
20:17:00 <dhellmann> lifeless: ok, well, as I wrote a bunch of the original version of this project I'm going to claim more knowledge than armax
20:17:05 <ttx> armax: and let us know if you see any issue.
20:17:19 <armax> I am only taking Astara as an example because they are the one applying for inclusion
20:17:28 <armax> dhellmann: I didn’t intend to claim otherwise
20:17:30 <flaper87> armax: your input and neutron's team input will be super valuable on these matters
20:17:31 <adam_g> armax, dont worry, we're a small team of long time openstackers... and the last thing any of us want is another public facing API :)
20:17:33 <armax> but things change
20:17:38 <armax> over time
20:17:49 <ttx> OK, we need to move on.
20:17:50 <armax> I am only asking: who is going to monitor the change?
20:17:55 <armax> if at all?
20:17:59 <armax> ok
20:18:08 <lifeless> armax: I think the answer is noone
20:18:14 <russellb> flaper87: i don't think they feel that way in this case
20:18:15 <jaypipes> armax: ceilometer?
20:18:22 <armax> lifeless: that’s the worst answer I could get
20:18:24 <lifeless> jaypipes: boom tish
20:18:34 <armax> but it’s an answer nonetheless
20:18:38 <dhellmann> armax: we don't have rules like what you want enforced, though
20:18:39 <armax> lifeless: I appreciate it
20:18:49 <ttx> armax: "everyone" ?
20:18:51 <armax> dhellmann: that’s fine, I get it
20:18:58 <ttx> (it's the same answer)
20:19:08 <flaper87> russellb: yeah, I have that feeling and I'd like that to change :(
20:19:15 <lifeless> armax: because as dhellmann says - http://governance.openstack.org/reference/new-projects-requirements.html - we don't (anymore) require that things be entirely distinct/non-overlap etc
20:19:23 <lifeless> so monitoring to make sure they are would be counterproductive
20:19:46 <armax> lifeless: I agree…so I feel there’s a double standard then
20:19:47 <dhellmann> russellb, flaper87 : I listened, I just disagree.
20:19:55 <ttx> If two project teams interests collide, they can escalate to the TC for conflict resolution
20:19:59 <dhellmann> armax: how so?
20:20:04 <ttx> I just fail to see a conflict right now
20:20:13 <ttx> just presumption of potential conflict
20:20:28 <armax> ttx: indeed, and that’s ok
20:20:36 <lifeless> armax: whats the double standard?
20:20:44 <armax> lifeless: gbp was shot down
20:20:44 <ttx> armax: so if the situation evolves, feel free to raise it
20:20:49 <ttx> armax: no
20:20:53 <armax> is it back?
20:20:54 <dhellmann> armax: gpb *does* overlap quite a bit
20:20:55 <ttx> armax: they retracted their proposal
20:21:00 <armax> ok
20:21:04 <mordred> armax: gbp wanted to replace neutron user-facing APIs
20:21:06 <mestery> dhellmann: Quite a bit? It's another networking API with HW drivers
20:21:07 <ttx> armax: current in WIP
20:21:12 <mestery> It more than overlaps
20:21:19 <flaper87> dhellmann: that's fine, I'm not saying that one has to agree
20:21:41 <armax> again, I am not picking up on astara…but who is going to stop that from happening now?
20:21:44 <dhellmann> mestery: ok, well, degrees :-)  -- in any case, that's not astara is
20:21:50 <mestery> dhellmann: Agreed
20:21:57 <mestery> armax: The answer is no one
20:22:01 <armax> or any other project that does the same?
20:22:05 <armax> mestery: right
20:22:06 <armax> that’s fine
20:22:09 <mestery> Yip
20:22:16 <mestery> It's documented now at least
20:22:46 <ttx> ok, moving on, other topics to cover
20:22:50 <ttx> #topic Cinder v1 drop postmortem
20:22:56 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2015-September/075765.html
20:23:03 <ttx> sdague: want to drive this one ?
20:23:07 <sdague> yes
20:23:20 <armax> let’s move on and cross that bridge should we ever get to it
20:23:21 <armax> I only flagged the potential loophole
20:23:45 <sdague> so, in the lead up to liberty release, the cinder team tried to disable by default v1 in devstack, which is their previously deprecated major API
20:23:48 <annegentle> thanks armax and mestery
20:23:54 <sdague> lots of things broke
20:23:59 <sdague> *lots* of things broke
20:24:11 <annegentle> so you're saying. lots of things broke.
20:24:22 <dhellmann> annegentle: I heard it was more than lots
20:24:25 <lifeless> I hear lots of things broke
20:24:34 <mordred> how man?
20:24:35 <sdague> and in unpacking the situation after, it turns out that very few bits of code in the wild actually supported cinder v2
20:24:36 <mordred> many?
20:24:40 <dhellmann> mordred: 42
20:24:43 <mordred> dhellmann: ++
20:24:44 <sdague> basically, only tempest
20:24:44 <flaper87> lol
20:24:59 <sdague> and openstack client in the last 3 months
20:25:02 <sdague> -ish
20:25:18 <sdague> so, we reverted that
20:25:18 <russellb> seems to be a trend in major API revs ...
20:25:19 <dhellmann> yeah, I think it wasn't complete support in osc, was it?
20:25:36 <dtroyer> dhellmann: no support until june/july-ish
20:25:39 <sdague> however it does raise a question about how this can be done better
20:25:50 <lifeless> sounds like a data problem
20:25:55 * dhellmann points to his cross-project summit session proposal on "themes", including "functional testing" http://odsreg.openstack.org/cfp/details/19
20:25:57 <lifeless> like, we don't know enough about how we're deployed
20:26:00 <sdague> and what additions to our deprecation tag we should have for due dilligence
20:26:19 <sdague> the link above suggested some from the operator community
20:27:04 <SpamapS> Seems to me that developer queues need to be filled when deprecated API's are used in the gate. As in, "hey there's a bug over here please fix it"
20:27:27 <sdague> I think rally / tempest / and openstack client support for at least 1 full cycle seems useful
20:27:30 <mordred> I would think that at the very least we cannot _start_ deprecation of an old API until everyting in OpenStack supports the new one
20:27:36 <dhellmann> I think the things from the email made sense, and I just assumed projects would actually be following through on that work before deprecating APIs. I mean, if the client didn't even properly support it deprecation was obviously premature
20:27:47 <mordred> like, you can't mark it deprecated if anything else in OpenStack (which we do have control over) is still using it
20:27:56 <dhellmann> mordred: ++
20:27:56 <lifeless> ++mordred
20:27:58 <jaypipes> sdague: so tempest supported v2 cinder API, but didn't test anything a deployment that *only* had v2 enabled and not v1?
20:28:01 <mordred> becaue it's really not actually deprecated until then
20:28:01 <ttx> sdague: the tag mandates making a survey of operators around usage of the feature to be removed
20:28:02 <dhellmann> sdague: do you think we need a time frame?
20:28:11 <sdague> jaypipes: tempest worked
20:28:11 <lifeless> mordred: using-by-default though IMO
20:28:13 <jeblair> it's possible our thinking around 2 cycles was from when we had 3 projects and everyone in the same room.
20:28:15 <mordred> lifeless: yes
20:28:16 <flaper87> dhellmann: mordred ++
20:28:17 <ttx> sdague: it's just that the procedure (which is new) wasn't followed
20:28:25 <stevemar_> jeblair: ++
20:28:26 <lifeless> mordred: like, we probably want clients to support old-and-new and be new-by-default before deprecating
20:28:35 <sdague> ttx: sure, because deprecation of the v1 api predates that
20:28:38 <jaypipes> sdague: sorry that should have said "but didn't test *against* a deployment that *only* had v2 enabled and not v1"
20:28:39 <sdague> by at least a year
20:28:39 <mordred> lifeless: using by default across all of openstack should be a barrier to being able to suggest deprecation of old
20:28:39 <flaper87> I guess a good first step is to have non-voting gates running with the deprecated API disabled
20:28:43 <dhellmann> jeblair: are you suggesting longer?
20:28:49 <ttx> sdague: so I'm not sure the tag language is insufficient
20:28:50 <lifeless> mordred: yes, that language should be in our tag
20:28:50 <sdague> jaypipes: no, but that part actually worked
20:28:51 <flaper87> that should give an idea of what's would happen
20:28:52 <SpamapS> There almost needs to be a different word than deprecated.
20:28:54 * flaper87 shrugs
20:29:07 <mordred> dhellmann: I'd personally suggest that we NEVER deprecate old APIs
20:29:10 <lifeless> SpamapS: abandonded ?
20:29:12 <mordred> but I know I'll get killed for that
20:29:16 <sdague> rally didn't support v2 at all, and grenade blew up because of osc issues
20:29:20 <dhellmann> mordred: let's take this one step at a time
20:29:22 <mordred> so I'll stand for "not until it's default across all of openstack"
20:29:22 <annegentle> mordred: I"m thinking that's reality and we should match it
20:29:24 <mordred> for now
20:29:30 <annegentle> for now
20:29:32 <jeblair> dhellmann: more that the idea that a single fixed period is sufficient only if everyone is on top of things and pushing adoption aggressively, which wasn't the case here.
20:29:40 <stevemar_> sdague: same with barbican when we tried to switch keystone to v3
20:29:45 <dhellmann> jeblair: ah, right, I agree with that assessment
20:29:55 <lifeless> jeblair: I think the period is fine, as long as the *starting point* is 'when all the work has been completed'
20:29:59 <annegentle> jeblair: good point
20:30:02 <jeblair> lifeless: yes, i think that's key.
20:30:10 <mordred> lifeless, jeblair++
20:30:11 <dhellmann> mordred: on the other hand, that means all openstack projects have veto of any project they consume
20:30:18 <mordred> dhellmann: they already do
20:30:43 <dhellmann> well, your rule would make that more explicit
20:30:44 <sdague> so, I think there is a deadlock issue with that approach. However, it does seem like a project should know which other parts of openstack do / don't work with it.
20:30:50 <sdague> and be deliberate about that
20:30:50 <dhellmann> mordred: I don't like cross-project veto powers
20:31:03 <sdague> dhellmann: yeh, I agree, because you get lazy deadlock there
20:31:04 <lifeless> sdague: tell me more about the deadlock concerns ?
20:31:07 <dhellmann> mordred: it means deadlock
20:31:09 <dhellmann> sdague: right
20:31:16 <mordred> dhellmann: well, if a project just decides to be a bonehead about it - I think we should look at that project and their esprit de corps
20:31:20 <annegentle> sdague: yeah
20:31:27 <dhellmann> lifeless: A won't adopt B's v2, so B can never drop V1 support
20:31:28 <SpamapS> So there's really 4 phases in the life of an API in OpenStack. Right now. "New', "Usable", "Deprecated", and "Removed"
20:31:28 <mordred> dhellmann: to me it means the ornery project gets themselves kicked out of the tent
20:31:48 <lifeless> dhellmann: that might mean that V2 has some real issues?
20:31:48 <ttx> mordred: I'm not sure that will be that well-cut
20:31:54 <mordred> of course not :)
20:31:59 <jaypipes> mordred: not sure that is realistic. :)
20:32:00 <dhellmann> lifeless: or that project A is not prioritizing collaboration
20:32:06 <SpamapS> What seems to be missing is something between "Usable" and "Removed" which sets off alarm bells.
20:32:07 <dhellmann> lifeless: both happen in practice
20:32:08 <ttx> mordred: a lot of projects were pretty lazy (and still are) with keystone v3
20:32:25 <lifeless> dhellmann: so I don't like the thing there were a project can unilaterally force another project to do a bunch of work
20:32:31 <lifeless> dhellmann: it seems like there should be a middle ground
20:32:36 <ttx> until it's down to one "bonehead" there is some road to travel
20:32:45 <sdague> so, before we got down the fisty-cuffs route, how about having a standard for what we expect projects to know about their API usage
20:32:45 <dhellmann> lifeless: agreed, we need projects to work together to support each other's evolutions
20:32:47 <stevemar_> SpamapS: maybe that's where "Abandoned" comes in
20:32:49 <mordred> ttx: yes. exactly
20:32:56 <flaper87> I think one of the things that have caused delays on moving projects to new APIs is who's going to do that work
20:33:03 <annegentle> mordred: it's not like that, it's more the "prioritizing collaboration" description
20:33:08 <flaper87> It's happened w/ keystone, Cinder and Glance
20:33:08 <dhellmann> sdague: ++
20:33:19 <dhellmann> flaper87: ++
20:33:20 <russellb> flaper87: yep
20:33:29 <sdague> because, I'll admit, when we make API changes in nova I go off and look at some of the 3rd party sdks like fog to see what people actually consume
20:33:29 <russellb> generally always assume the "other team" should/will do it
20:33:30 <ttx> mordred: so "until everyone supports it or you are tired to wait and ask the TC for a bonehead exemption ?"
20:33:36 <SpamapS> Right, like "Deprecated" just means "Disapproved of". So the project is saying "we have something else now, we disapprove of using this one", but it still gets attention.
20:33:38 <lifeless> brook's law is starting to hit us here :)
20:33:52 <flaper87> exactly, whereas I believe this is exactly what cross-project efforts are fore
20:34:06 <flaper87> As of Glance, we've now a small team between nova and glance working on this
20:34:20 * SpamapS steps down from box.
20:34:21 <flaper87> Joint efforts like this are the ones that would help APIs moving forward
20:34:35 <markmcclain> flaper87: ++
20:34:48 <ttx> SpamapS: the tag uses "deprecation" and "obsolesence"
20:34:52 <flaper87> Also, achieving everything in 1 cycle is just impossible unless there's just 1 project consuming your API
20:34:55 <ttx> http://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html
20:35:10 <flaper87> And since project resources are not infinite, it must be scheduled carefully
20:35:17 <david-lyle> from a horizontal project perspective, watching this realization of big tent difficulties with a distributed governance model is fun
20:35:33 <annegentle> End-user docs have Current, Supported, Deprecated, Experimental.
20:35:35 <sdague> ok, so moving this conversation towards actionable. I think I heard mixed things about do we need more language in the tag
20:35:35 <annegentle> #link http://developer.openstack.org/api-ref.html
20:35:54 <sdague> annegentle: right, but experimental is pre current
20:36:07 <lifeless> sdague: I think we need more guidance
20:36:12 <ttx> sdague: we have to move on -- what do you suggest as a next step ? Dedicating one of the cross-project sessions to the question of deprecation ?
20:36:19 <dhellmann> sdague, annegentle : it would be good to have those 2 docs use consistent language
20:36:29 <sdague> ttx: we could do that
20:36:32 <lifeless> sdague: I don't know that the *tag* should specify development process, but the user-visible impact and process for deprecation certainly makes sense to be in there to me
20:36:37 <annegentle> dhellmann: sdague: yes, also my thinking, consistent terms are needed
20:36:41 <ttx> sdague: or ML thread between now and then
20:36:49 <flaper87> ttx: if there's a free slot, yes
20:37:05 <flaper87> but I would put this in the box with all other proposals
20:37:05 <sdague> well originally, I was going to suggestion we bring in the ideas in here - http://lists.openstack.org/pipermail/openstack-dev/2015-September/075765.html as a starting point
20:37:29 <sdague> but we could do this as a cross project session given that it's fresh
20:37:44 <sdague> and get some write up after about additional guidelines on deprecation
20:38:03 <ttx> that sounds like a good topic to me
20:38:08 <sdague> ok, I'll propose
20:38:10 <sdague> and run
20:38:32 <david-lyle> terminology is not the issue; defining, scheduling and driving work is the issue. any project can choose to deprecate something, the problem is making other projects care
20:38:51 <annegentle> david-lyle: good perspetive
20:39:00 <ttx> david-lyle: ties into defining "cycle goals", a session that dhellmann proposed
20:39:04 <annegentle> david-lyle: and I think you're right fwiw
20:39:15 <ttx> i.e. having common goals and driving them
20:39:18 <dhellmann> david-lyle: yes, see my comments earlier about veto power
20:39:30 <flaper87> it's not just about making other projects care, the project deprecating things should care enough as well
20:39:44 <flaper87> *cough* glance *cough*
20:39:51 <flaper87> It's literally a cross-project effort
20:40:07 <ttx> ok, let's move on, we have a path forward and won't solve it in-meeting anyway
20:40:07 <david-lyle> but in the big tent, how widely do they have to care?
20:40:10 <flaper87> one that must be taken 1 project at a time (depending on the resources available)
20:40:19 <ttx> david-lyle: big tent doesn't mean no rule
20:40:25 <flaper87> ttx: ++
20:40:26 <ttx> just means easier entry
20:40:38 <ttx> (which also means easier kicking out)
20:40:44 <sdague> and you should care about all your consumers, not just the ones in the openstack namespace
20:40:56 <david-lyle> not arguing is does, but if you push deprecation work on one project to carry out across openstack
20:41:01 <david-lyle> how wide is that
20:41:29 <mtaylor> depends on how widely you're used, honestly ... keystone might have more work ahread of them than other projects, for instance
20:41:36 <ttx> david-lyle: totally agree that some coordination is required. Can't be all consumer or all originating project
20:41:42 <sdague> there is actually a reason we rolled back 2 years of development on Nova API and went down a different path
20:41:52 <mtaylor> and the cost of that is something that projects should think about when looking at new APIs
20:41:58 <flaper87> which will require them more time to do it
20:41:58 <edleafe> sdague: +1
20:42:00 <mtaylor> because if it's hard to get the new api rolled out across openstack
20:42:07 <mtaylor> think about how hard it is on the users you do not know
20:42:08 <david-lyle> sdague: my concern is we can't even seem to drive these changes in the namespace, outside is harder yet
20:42:20 <sdague> david-lyle: yep, for sure
20:42:24 <sdague> ok, we'll take it to summit
20:42:24 <ttx> ok, we really need to move on, but I'm looking forward to the discussion on this
20:42:33 <david-lyle> sdague: I think that was a more sane direction for sure
20:42:35 <ttx> Not really a TC-specific thing anyway
20:42:42 <ttx> moving on
20:42:43 * david-lyle sits back down
20:42:45 <ttx> #topic stackforge retirement: make workflow reqs+cla clearer
20:42:50 <ttx> #link https://review.openstack.org/229176
20:43:03 <ttx> cool, plenty of votes
20:43:08 <ttx> Questions, comments, objections ?
20:43:14 <flaper87> go go go go
20:43:36 <ttx> gone
20:43:40 <russellb> +1
20:43:41 <ttx> #topic Note that the TC expects some project history.
20:43:46 <ttx> #link https://review.openstack.org/229456
20:43:57 <ttx> same
20:44:02 <ttx> Questions, comments, objections ?
20:44:09 <dhellmann> did we lose anyone to the netsplit?
20:44:18 * flaper87 crickets
20:44:19 <annegentle> here
20:44:19 <russellb> dtroyer
20:44:19 <dhellmann> I dtroyer gone
20:44:25 <ttx> not that my smart filter could tell
20:44:26 <dhellmann> *see
20:45:00 <ttx> dtroyer approved it so I'll suppose he is fine with it
20:45:02 <jeblair> i think dtroyer made a really good point on the review which i think perhaps many agree with but i'm afraid will be lost since it's just a comment.
20:45:03 <flaper87> ttx: mmh, I think our smart filters need refining
20:45:07 <ttx> gone
20:45:15 <ttx> #topic Add team:non-diverse-affiliation tag
20:45:20 <ttx> #link https://review.openstack.org/218725
20:45:23 <mordred> dhellmann: I got lost too and had to reconnect
20:45:35 <ttx> Oh! Objections.
20:45:38 <dhellmann> jeblair: maybe a follow-up patch to add text
20:45:46 <ttx> must be very recent
20:46:10 <ttx> go home barjavel you're drunk
20:46:25 <russellb> i mentioned my concern in a tc meeting once, was going to abstain
20:46:26 <russellb> but decided to go ahead and -1
20:46:33 <ttx> lifeless, russellb: could you further elaborate why we are netter without it ?
20:46:39 <ttx> better*
20:47:30 <lifeless> ttx: so we discussed it previously. I think that the social negatives of 'earnt a bad badge' are worse than the social negatives of 'failing to expose these risks to our users'
20:47:38 <russellb> just concerned with "negative" tags in general, and whether they are overall good.  my gut says it's not an overall win.
20:47:40 <ttx> FWIW this has enough votes to pass now, just want to understand your concern to see if that makes me revert my vote
20:47:47 <lifeless> ttx: I'd be ok with 'failed to earn a specific good badge'
20:47:53 <russellb> agree with lifeless summary
20:48:15 <dhellmann> ttx: I've removed my vote, for now
20:48:23 <lifeless> ttx: negative feedback tends to really be felt brutally and viscerally by folk
20:48:40 <lifeless> ttx: you need to be super careful about how you do it, and an automated algorithm on our governance site is *not it*
20:49:08 <edleafe> isn't it an objective evaluation?
20:49:17 <lifeless> edleafe: it is both
20:49:18 <edleafe> It's not like saying "we don't like you"
20:49:19 <ttx> lifeless: I'm not sure I see it as a subjective thing, what edleafe said
20:49:19 <sdague> lifeless: even if it's pretty clear to applying teams that it's a boundary
20:49:20 <dhellmann> the numbers for diversity are visible through stackalytics without a lot of effort, I wonder if we'd do better to link to that in the regular diversity tag docs
20:49:35 <lifeless> ttx: I didn't say subjective at any point :)
20:49:44 <ttx> it's like, don't force our consumers to go through stackallytics to get their opinion on how diverse a team is
20:49:54 <lifeless> dhellmann: I'd be comfortable with that
20:50:01 <russellb> dhellmann: sure, "if you want to understand more, regardless of whether a project has met this defined threshold, see stackalytics" +1
20:50:02 <ttx> it's not as if the facts weren't there
20:50:07 <sdague> I guess I feel like in the past projects in this bucket would have been shown the door completely
20:50:20 <flaper87> To me, the tag is stating something that can is evident by looking at the project's activity.
20:50:33 <ttx> sdague: they would not have been accepted in the first place
20:50:40 <sdague> ttx: right, that's what I mean
20:50:59 <ttx> basically, it's something we used to judge as part of the integrated-release concept
20:51:11 <ttx> and we erased that bit of information
20:51:20 <ttx> this is just proposing to expose it again
20:51:39 <flaper87> I think the concern here is not about the information but about how it's exposed
20:51:49 <ttx> if it is seen as a bad thing and teams work on diversity as a result, all the better ?
20:51:54 <dhellmann> ttx: I see lifeless and russellb's point that this feels more like stick than carrot
20:51:56 <jeblair> ttx: we do still have the diverse-affiliation tag for exposing that information.
20:51:59 <lifeless> ttx: hang on, we have a diversity carrot tag
20:52:03 <maishsk> flaper87: +1
20:52:10 <devananda> ttx: is exposing that in a negative way (project X does not Y) valuable to the community, or in shaping the community, in a big-tent world?
20:52:18 <flaper87> I don't want to just tell people that they should look into stackalytics before deploying things because I kinda thing we should also be a bit more informative
20:52:45 <ttx> I'm fine deferring the decision on this one. That means deferring to the next TC membership though
20:52:49 <lifeless> we can create a curated list of projects that have earnt all the previously-this-was-integrated badges
20:53:04 <dhellmann> lifeless: that's the tc-approved-release
20:53:09 <devananda> lifeless: we started from that list. it's inthe history
20:53:10 <lifeless> dhellmann: no
20:53:10 <dhellmann> at least as it stands today
20:53:22 <lifeless> dhellmann: thats the interface with the board and defcore AIUI
20:53:23 <dhellmann> oh, you mean as individual things
20:53:31 <dhellmann> well, I mean we have the list of those projects already
20:53:31 <flaper87> What if we tag diverse projects and leave non-diverse projects tagless ?
20:53:38 <lifeless> dhellmann: I just mean gather up the various carrt tags
20:53:38 <russellb> dhellmann: yes, and i want to trend toward being a community with a culture of more carrots and less sticks
20:53:38 <flaper87> that's pretty much the same but the other way around
20:53:40 <dhellmann> flaper87: that's what we're doing now
20:53:45 <ttx> OK, let's continue the discussion on the review, it doesn't have majority yet.
20:53:47 <lifeless> dhellmann: and provide a list of 'super good healthy happy projects'
20:53:48 <flaper87> however, the tag would be positive
20:53:57 <dhellmann> russellb: ++
20:53:59 <ttx> if still blocked at next meeting we'll call for direct vote
20:54:06 <lifeless> dhellmann: and say 'this is the safe space. Beyond that you'll need to learn aboutthe project to assess'
20:54:21 <ttx> we need to move on to cover the rest of the agenda
20:54:24 <lifeless> russellb: ++ that trend. Me too.
20:54:27 <flaper87> dhellmann: ? don't think so or I didn't express myself correctly
20:54:45 <edleafe> is the purpose of the tag to reward/punish the team, or to enlighten potential outside users about the project's state?
20:54:48 <lifeless> flaper87: I think dhellmann means the status quo
20:54:51 <markmcclain> my main concern is the education side of it.. ie how do folks know which carrots a project should have
20:54:53 <ttx> edleafe: the latter
20:54:56 <flaper87> lifeless: ah, that makes more sense
20:54:57 <lifeless> flaper87: is that we have no negative tag and only the positive tag.
20:55:11 <flaper87> lifeless: thanks
20:55:14 <annegentle> edleafe: all about giving others info
20:55:15 <dhellmann> markmcclain: get all the carrots!
20:55:18 <edleafe> ttx: that's what I thought. Seems childish to insist on only positive tags to spare hurt feelings
20:55:24 <ttx> ok, continue discussion on the review
20:55:27 <ttx> #topic Cross-project track at Mitaka design summit
20:55:33 <ttx> http://odsreg.openstack.org/
20:55:40 <ttx> I submitted a bunch there, you should too
20:55:52 <ttx> content will be decided next week
20:56:02 <russellb> edleafe: feelings matter to me.  openstack is people and i care about them.
20:56:13 <dhellmann> ttx: does that system email the proposer when comments are added?
20:56:20 <ttx> we need to set up a meeting on Monday to hash the results
20:56:26 <dhellmann> ttx: if not, we should make sure folks know to go look at the questions that have been left
20:56:27 <ttx> dhellmann: not really
20:56:28 <russellb> edleafe: feel free to go work on the linux kernel if you'd like to be in a place where feelings don't matter
20:56:28 <flaper87> russellb: ++ on feelings matters
20:56:36 <edleafe> russellb: so do I, but this isn't a judgment on the people; it's an objective assessment
20:56:50 <russellb> that's quite an over simplification
20:56:54 <russellb> anyway we have moved on
20:56:58 <edleafe> yep
20:57:01 <ttx> russellb: agreed, that's why I don't want to rush a decision on this
20:57:12 <flaper87> ttx: meeting on monday sounds good
20:57:23 <ttx> Who is up for a meeting on Monday to prepare the results ?
20:57:31 <flaper87> o/
20:57:31 <ttx> 1500 UTC ?
20:57:39 <sdague> 1500 utc seems fine
20:57:45 <flaper87> ttx: 14 would be better
20:57:47 <ttx> that's usually the magic time
20:57:55 <dhellmann> o/
20:57:57 <ttx> I'm fine with 1400, but PT people might not
20:57:58 <flaper87> but if it doesn't work for others, I'll adapt
20:58:30 <ttx> ok, sync with flaper on your availability, he will setup the meeting
20:58:38 <ttx> #topic Communications workgroup report
20:58:42 <ttx> annegentle, flaper87: o/
20:58:44 <annegentle> boy. um....
20:58:52 * annegentle shuffles feet and looks down
20:58:54 <ttx> do we have enough for a "end of liberty" blogpost ?
20:59:10 <annegentle> I meant to have one ready by tomorrow but haven't given much thought to it
20:59:14 <annegentle> I think we do ttx
20:59:29 <flaper87> I think we could do that and we had some other good content from today's meeting too
20:59:31 <annegentle> flaper87: up for drafting with me?
20:59:34 <annegentle> flaper87: yep
20:59:37 <ttx> #action flaper87 to set up a meeting on Monday to prepare the cross-project track agenda ahead of the TC meeting
20:59:39 <flaper87> annegentle: yes, lets etherpad together
20:59:45 <annegentle> flaper87: cool thanks
20:59:49 <stevemar_> annegentle: i thought this was nice: http://www.slideshare.net/openstack/liberty-release-preliminary-marketing-materials-messages no idea who did it though
21:00:01 <ttx> annegentle: can be a bit of a retrospective
21:00:09 <ttx> #topic Open discussion
21:00:13 <ttx> Remember we'll have a joint Board of Directors / TC meeting on Monday Oct 26 afternoon starting at 2:30pm
21:00:16 <ttx> mordred: any progress on the TC dinner plans ?
21:00:20 <ttx> Anything else, anyone ?
21:00:22 <annegentle> stevemar_: nice find, thanks!
21:00:35 <russellb> a DCO non-update posted to the foundation ML: http://lists.openstack.org/pipermail/foundation/2015-October/002201.html
21:00:37 <lifeless> flaper87: 1400 UTC - uhm, 2am, nope
21:00:43 <sdague> russellb: thanks for that
21:00:53 <flaper87> lifeless: 15 is not any better
21:00:55 <russellb> sdague: hopefully it's an oversight
21:00:56 <flaper87> :P
21:01:04 <ttx> mordred: note: no dinner planned on Monday evening, only the snacks at the WOO event until 7:30pm
21:01:09 <dhellmann> lifeless: leave comments on the proposals
21:01:11 <ttx> so that's an option
21:01:17 <flaper87> lifeless: 15 UTC is midnight here
21:01:31 <ttx> #endmeeting