20:01:35 <ttx> #startmeeting tc
20:01:36 <openstack> Meeting started Tue Sep  6 20:01:35 2016 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:37 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:39 <openstack> The meeting name has been set to 'tc'
20:01:42 <mtreinish> o/
20:01:43 <sambetts> o/
20:01:50 <ttx> Hello everyone! Our agenda for today:
20:01:54 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:02:10 <ttx> (remember everyone can use #info #idea and #link to make for a more readable summary)
20:02:18 <ttx> #topic Add 'library convergence' to Requirements mission
20:02:25 <ttx> #link https://review.openstack.org/363502
20:02:41 <ttx> This is a follow-up patch to address one of my comments on the Requirements team mission
20:02:49 <ttx> just reached majority approval
20:02:58 <ttx> any objection to merging it now ?
20:03:35 <ttx> I'll take that as a no
20:03:56 <dims> go for it ttx
20:03:57 <ttx> approved
20:04:02 <ttx> #topic Mention where the metric rules are defined/used
20:04:06 <ttx> #link https://review.openstack.org/342225
20:04:16 <ttx> This is a clarification of how those tags is actually applied
20:04:24 <ttx> Looks like a good incremental improvement to me
20:04:30 <ttx> flaper87: anything you wanted to mention ?
20:04:47 <flaper87> nope, I'll address the typos
20:04:54 <flaper87> if folks have questions, I'm happy to answer them
20:05:03 <flaper87> I noticed amrith's comment but dhellmann replied to him
20:05:06 <dhellmann> since this is a formal-vote item, do you want to do the typos as a separate patch?
20:05:06 <flaper87> so, I think I'm good
20:05:14 <flaper87> yup, sounds good to me
20:05:23 <ttx> yes typo, patches are fasttracked too
20:05:33 <dhellmann> unless you wanted to do the more substantial rewrite annegentle proposed
20:05:33 <annegentle> yeah I think that follow up's fine
20:05:36 <dhellmann> k
20:05:42 <annegentle> plural possessive ftw
20:05:44 <amrith> ./
20:06:01 <ttx> I think "proposed" is valid, so amrith -1 is probably shallow
20:06:04 <mtreinish> flaper87: how does the tool handle repos with a single review in 6 months?
20:06:08 * mtreinish is just curious
20:06:19 <amrith> none of my concerns are of the ilk that require a hold up. my -1 is as ttx said, shallow
20:06:40 <flaper87> mtreinish: mmh, good question. I should double check that. can't remember OTOH
20:06:48 <ttx> mtreinish: we still use common sense when applying tag changes, fwiw
20:06:54 <flaper87> mtreinish: iirc, it considers the project as not active
20:06:59 <ttx> which is why we end up reviewing the proposed changes
20:07:01 <flaper87> but yeah
20:07:08 <flaper87> common sense is still the rule
20:07:14 <mtreinish> ttx: sure, its just we are encoding that it's what the script does in there right?
20:07:40 <amrith> ttx, dhellmann, flaper87 just the observation is that the tool currently doesn't deal with patch proposal, rather with 'reviews during the period'.
20:07:52 <amrith> the distinciton is subtle but one that exists ...
20:07:59 <dhellmann> amrith : we're measuring the activity of the reviewer, right?
20:08:07 <ttx> mtreinish: patch just says we measure activity based on rules of the script. Not that we blindly apply script's output as law
20:08:18 <flaper87> dhellmann: +1
20:08:37 <amrith> yes, dhellmann .. in that case you should consider reviews proposed during the period, not patches proposed during the period.
20:08:39 <dhellmann> amrith : there is no requirement that a core-reviewer submit patches
20:09:00 <flaper87> mtreinish: the line was more generic and annegentle correctly pointed out that we may want to have some of the current rules explained in plain English
20:09:11 <dhellmann> amrith : I'm not understanding whatever you're trying to say
20:09:15 <amrith> dhellmann, if a review lasts longer than the six months
20:09:20 <amrith> it was not 'proposed' within the period
20:09:26 <amrith> it was 'reviewed' within the period
20:09:28 <dhellmann> amrith : a "review" is when I click -1, etc.
20:09:32 <amrith> that was the distinciton I was looking at
20:09:33 <dhellmann> we count those events
20:09:45 <dhellmann> those are point-in-time, and don't span releases
20:09:46 <flaper87> we don't count the proposed patches
20:09:48 <ttx> "patches currently proposed for review"
20:09:51 <flaper87> but the reviews made to those patches
20:09:59 <ttx> not patches created in a given timeframe
20:10:07 <sambetts> "have reviewed at least 2% of the proposed..."
20:10:38 <dhellmann> I think the word order is confusing some people here
20:10:48 <dhellmann> reviews need to be on patches that are open
20:10:53 <dhellmann> they can have been opened at any time
20:10:53 <amrith> the verbiage is "of the proposed
20:10:53 <amrith> patches", change it to "of the proposed reviews" and I think it will say what you are saying here ...
20:11:01 <dhellmann> the reviews need to happen in the period being measured
20:11:18 <flaper87> if annegentle's text is clearer, I'll update the patch
20:11:23 <dhellmann> amrith : you are using the term 'review' to mean what I think this is meaning when it says 'patch'
20:11:53 <amrith> dhellmann, in that case we're saying the same thing. I withdraw my -1
20:12:06 <annegentle> I'm not sure mine addressed the proposed, vs. not proposed in the window of reviews
20:12:16 <dhellmann> flaper87 : "review comment" might be clearer
20:12:24 <annegentle> but yeah
20:12:39 <annegentle> main thing is to write it like we're talking about it
20:12:52 <flaper87> dhellmann: would that still count as typo ?
20:12:54 <flaper87> :P
20:12:59 * flaper87 can do a ninja fix during the meeting
20:13:13 <ttx> ok, let's try that and move on
20:13:22 <ttx> we'll be back to this one on open discussion
20:13:27 <annegentle> sounds good
20:13:28 <dhellmann> ok
20:13:35 <ttx> #topic Write down OpenStack principles (initial discussion)
20:13:45 <ttx> timeboxing to 15min
20:13:51 <ttx> #link https://review.openstack.org/357260
20:13:59 <ttx> So... this one is an effort to document a few principles we historically follow in how we write OpenStack
20:14:10 <ttx> Credits for the original draft goes to mordred
20:14:23 <ttx> although I removed most of the swearing so you wouldn't be able to tell
20:14:27 <annegentle> ha
20:14:38 <ttx> Once we are happy with the draft, we should start a larger discussion on the ML before approving it
20:14:40 <annegentle> there's no swearing in OpenStack
20:14:48 <ttx> But I'd like to see some consensus on the TC before we move to that
20:15:06 <annegentle> How do we revise to be more welcoming?
20:15:20 <ttx> I've not seen objections from TC members, but from the larger community, so far there is some discussion around the wording of the "One OpenStack" principle
20:15:21 <annegentle> I mean, I know I said somethign like that on the review, but hadn't offered a true revision.
20:15:41 <ttx> annegentle: yes, I'll come back to that
20:15:47 <annegentle> ttx ok thanks
20:15:51 <ttx> On "One OpenStack" there are definitely some developers who would prefer to see OpenStack as a loose collection of independent projects
20:16:03 <ttx> I'll just point out that this was discussed and decided before (in 2011) by the ancestor to the TC, the PPB
20:16:14 <anteaya> can I just ask whoever is doing the style reviews if we could get some consenseus on language before we have a lot more on things like case used in headings
20:16:18 <mtreinish> ttx: my only issue with it was already pointed out among the sea of comments there. Which is a definition of the 'OpenStack Way'
20:16:20 <ttx> So this is nothing new, we are just copying it over. That doesn't mean we couldn't change it in the future, but that's not the goal of this change
20:16:42 <ttx> mtreinish: yes, that is a bit fuzzy and could use other wording
20:16:51 <ttx> The other one which seems to trigger reactions is the last one, "Participation is voluntary"
20:16:54 <mtreinish> but other than that I was happy with most of what was there (for what I could parse amongst all the inline comments)
20:16:59 <ttx> which is seen as overly negative and could probably be rewritten in a more positive way
20:17:09 <ttx> The rest of the principles seem to be mostly acceptable so far, some wording tweaks might be necessary
20:17:21 <ttx> like mentioning "the OpenStack Way" without defining it
20:17:45 <ttx> should probably just say "those principles"
20:17:46 <notmyname> ttx: please don't read my comments on the proposed doc as disagreeing with previous TC rules. I simply found the phrasing inconsistent and unclear. I didnt' advocate for a particular "side"
20:18:01 <mtreinish> ttx: well I have know what that is, (especially if it was an mordred draft originally) but I think definiing it would be useful
20:18:21 <mtreinish> I think we also mention it in the big tent resolution
20:19:06 <ttx> So I'll probably propose a new revision and start a thread on the ML to expose it to more eyes
20:19:24 <flaper87> ++
20:19:26 <ttx> I don't think there are strong objections to any of those, but the wording matters
20:19:27 <dims> ttx : agree
20:19:39 <dtroyer> ttx: ++
20:19:45 <dhellmann> ++
20:19:48 <ttx> like notmyname says, they can be read in a lot of different ways and could use extra precision
20:20:20 <ttx> I certainly don't see any need to rush that. I see it more like missing documentation than a new thing though
20:20:40 <annegentle> ttx I wondered if a set of positive statements "If we have these attributes, then these other results happen" along the lines of "we know we are doing these things when..." will help
20:20:41 <dtroyer> I do like the amount of input from folk with different perspectives.  we assume a bit too much tribal knowledge sometimes
20:20:57 <annegentle> ttx I do see it as helping us to articulate what is not known by all
20:20:59 <edleafe> dtroyer: +1
20:21:06 <annegentle> dtroyer exactly
20:21:09 <flaper87> dtroyer: yeah
20:21:12 <ttx> dtroyer: especially those that have been around forever assume that what they think is what others think
20:21:29 <ttx> I'm guilty of that and I thank mordred for starting the effort to document those
20:22:12 <anteaya> annegentle: ++ postiive statements
20:22:58 <ttx> ok, so I'll do a new revision, let it bake a few days and if it holds the water start a thread on the ML to see how it floats
20:23:33 <flaper87> ttx: lol
20:23:36 <flaper87> sounds good to me
20:23:47 <ttx> Currently assuming there are no objection to any of the principles from the TC, but that we need to refine the wording
20:24:26 <ttx> In particular the "my way or the highway" tone of the last one is, I think, missing the mark
20:24:38 <dhellmann> yes, that needs some work
20:24:54 <annegentle> ttx I only did a first read, and I would like to do a deeper read again... I feel it is missing some vision.
20:24:59 <annegentle> ttx like why are we openstack at all?
20:25:24 <annegentle> ttx sounds a bit philosophical I know, but it felt like it was missing vision and purpose
20:25:45 <ttx> annegentle: this is not a new thing we don't have, it's a write-up of rules we've been operating under
20:25:55 <ttx> annegentle: I'd say the vision work is separate
20:26:26 <ttx> annegentle: vision != principles != mission
20:26:37 <flaper87> yeah, I'd firs try to write down the things we've been operating on, see how sound they are and see if they still apply
20:26:45 <flaper87> we can let this evolve from there
20:26:48 <edleafe> Positive statements are great, but the occasional "we don't do it this way" can also be enlightening to someone coming in new
20:26:50 <jroll> document the world before you change the world :)
20:27:08 <ttx> jroll: yes!
20:27:10 <flaper87> we can even trim it a bit and discuss some of those points separately if we find them controversial but let's first get some further feedback
20:27:45 <ttx> Also like all things we do, the form of this one won't be eternal
20:27:51 <ttx> it will evolve over time
20:27:59 <annegentle> ttx I sense there's still tension between "are we building blocks for different types of clouds" or "a community that builds software for all clouds" (Hence the storage focused cloud vs. a compute focused cloud could give you a different set of project selections.)
20:28:49 <annegentle> flaper87 you might be onto something, can the rules be collected in separate patches (they probably shouldn't be though if we really are getting agreement to the agreements we already operate within)
20:28:50 <ttx> annegentle: I'd say this is a "mission" question -- and we have "interoperability" in the Openstack mission now
20:28:58 <dhellmann> annegentle : do you think that tension goes beyond the question about whether we're talking about monolithic deployments vs. governance?
20:29:01 <flaper87> mmh, but I don't think that belongs to the principles
20:29:09 <flaper87> unless I'm misreading you, annegentle
20:29:14 <annegentle> dhellmann hmmmm thinking
20:29:40 <annegentle> I'm trying to get at the question of "be governed or hit the road"
20:29:54 <ttx> one minute to timebox
20:30:14 <annegentle> With governance comes accountability, so are we holding the contributors accountable? Yes. The deployers? Not so much.
20:30:35 <ttx> ok, let's continue the discussion on the review and the future ML thread
20:30:37 <dhellmann> but isn't this about the contributors?
20:30:39 <dhellmann> k
20:30:39 <annegentle> So I'll re-read and try to offer revisions with those thoughts top-of-mind ttx
20:30:44 <annegentle> dhellmann yep it is.
20:31:15 <ttx> but please don't try to pile up too much on this doc. It's n,t a code of conduct nor a mission statement nor a vision description
20:31:22 <ttx> Just a set of principles beyond the "4 opens"
20:31:29 <dims> ++ttx
20:31:45 <ttx> It's not the answer to all the questions
20:31:50 <ttx> ok, moving on
20:31:53 <annegentle> yeah good point
20:31:56 <ttx> #topic Add networking-cisco back into the Big Tent
20:32:03 <ttx> #link https://review.openstack.org/363709
20:32:09 <ttx> Some history
20:32:14 <ttx> networking-cisco was officially removed from the Neutron stadium back in April
20:32:29 <ttx> That was following a decision by the Neutron team in February to "not vouch for projects that are purely interfaces to proprietary technologies"
20:32:45 <ttx> So the networking-cisco folks would like to be recognized as a separate official project team
20:33:01 <ttx> First of all, like flaper87 and dtroyer said, I don't think we should fast-track that application on the grounds that it was originally part of the Neutron stadium.
20:33:19 <ttx> We should consider if teams belong in OpenStack separately from decisions made in the past by a specific project team
20:33:35 <ttx> Looking at the proposal I have two concerns, which I mentioned in the review
20:33:47 <ttx> The first is the timing -- post-FF is a pretty bad timing to add any project team. The release contents is set, the Design Summit tracks are assigned, elections are being organized
20:34:10 <ttx> This should really have been proposed earlier, shortly after it was removed in April
20:34:20 <ttx> So at this stage I'd rather reconsider this one at the start of Ocata
20:34:35 <ttx> Then there is my second concern, which is around the "level and open collaboration playing field" requirement
20:34:35 <flaper87> ++
20:34:37 <dtroyer> ++
20:34:38 <mtreinish> ttx: also wouldn't this fall under the same thing as poppy, where it only works with a proprietary backend? Or because it's a neutron plugin does that make it different?
20:34:50 <ttx> To me a project team whose deliverables purely interface with proprietary technologies violates that requirement
20:34:54 <flaper87> mtreinish: that's the second concern :)
20:34:59 <dhellmann> It's a bit unfortunate that the dissolution of neutron is leading to this being a question at all. Having different teams handle drivers in different ways is going to lead to a lot of confusion.
20:35:00 <mtreinish> ttx: also I'm fine with deferring to O :)
20:35:00 <ttx> mtreinish: yes, prettmuch
20:35:16 <annegentle> do we know the original neutron requirements, are they written down?
20:35:18 <ttx> Or in other words, should we provide open collaboration resources to a project that is clearly tilted in favor of one single organization contributors
20:35:22 <russellb> dhellmann: ++
20:35:23 <annegentle> agreed on timing, btw
20:35:25 <dougwig> mtreinish: being part of neutron does not confer magical vendor openness powers.  it is not different, IMO.
20:35:50 <mtreinish> dougwig: I agree with that. I was just playing devil's advocate with the second question
20:36:03 <sambetts> the bad timing is my fault, I only realised we had been removed from the big tent too when I dug into why I couldn't publish to docs.openstack.org any more
20:36:24 <ttx> So yes, I'd like to defer this one until RC1 at least, and probably the new TC elections
20:36:31 <mtreinish> because in the past we were discussing a service with a proprietary backend, but this isn't a service
20:36:31 <dhellmann> We have several teams struggling with how to handle vendor-specific contributions like drivers, and they're coming to different conclusions. It would be useful to see what sort of commonality there might be.
20:36:43 <annegentle> dhellmann yeah I'd like this written down
20:36:47 <ttx> But I wouldn't mind a quick read of the current TC on the "level playing field" requirement
20:36:50 <annegentle> dhellmann and agreed to
20:37:13 <dtroyer> the projects that have proprietary components are all still useful on their own in some way without the proprietary bits
20:37:21 <fungi> it's a bit of an existential question on drivers in general. was the code "more free and open" when it was under neutron's governance than it is when governed separately?
20:37:37 <ttx> annegentle: yes, neutron subproject acceptance policy is written down
20:37:41 <russellb> i just think it's organizational bizarre and awkward
20:37:46 <russellb> organizationally*
20:37:50 <dhellmann> fungi : as a part of a larger whole, maybe?
20:37:50 <edleafe> How is this different than the VMWare or Hyper-V drivers for Nova?
20:38:23 <ttx> edleafe: it's not a separate team. If they were, they would fall under the same argument
20:38:30 <flaper87> edleafe: It might not be but the governance rules are
20:38:34 <dtroyer> edleafe: they are part of Nova, and subject to everything Nova is subject to as a whole, with at least one exception of testing in our environment
20:38:36 <ttx> i.e. the "Nova team" is a level playing field
20:38:38 <annegentle> #link http://docs.openstack.org/developer/neutron/stadium/sub_projects.html
20:38:43 <flaper87> I mean, Nova's requirement is not (was not) the same as the big tent
20:38:46 <russellb> but it represents the consensus in neutron team at the moment
20:38:48 <flaper87> it's unfortunate
20:38:56 <edleafe> I was thinking more in terms of Neutron kicking them out
20:38:57 <dougwig> edleafe: the nova core team agreed to maintain those drivers.
20:39:11 <fungi> it's possibel that the neutron stadium was masking vendor-specific teams under a larger non-vendor-specific team
20:39:36 <edleafe> dougwig: Hyper-v was kicked out because no one was supporting it
20:39:37 <fungi> so once those subteams are cut loose, they're suddenly exposed as vendor-specific
20:39:39 <ttx> In other words, if we were to accept networking-cisco, we'd have an "OpenStack project team" that is clearly a "Cisco project team" since Cisco contributors have access to more data than other contributors
20:39:47 <dtroyer> fungi: isn't that what led to its undoing?
20:39:50 <dhellmann> fungi : likely. do we see that in the other teams with vendor-specific drivers?
20:39:52 <cburgess> fungi I'm pretty sure it was doing exactly like. But then I think you have a similar thing in cinder and nova with some of their driver teams as well.
20:39:52 <russellb> fungi: of course it was
20:39:53 <edleafe> They wer eonly let back in when there were resources from Microsoft and others
20:39:57 <russellb> naturally, for any vendor driver ...
20:40:21 <dhellmann> ttx: yes, that's right, I don't think I could vote to accept this as a standalone team :-(
20:40:24 <russellb> i'd ask this another way ... do vendor drivers belong "in" OpenStack?
20:40:28 <fungi> dtroyer: i'm mostly curious because neutron's stadium governance model is at least suprtficially to infra's council model
20:40:37 <edleafe> IOW, Nova will not support it if the vendor support disappears
20:40:40 <sdague> so... honestly the bigger concern is that, correct me if I'm wrong, in neutron drivers can actually change the API in substantial ways
20:40:40 * fungi really can't type today
20:40:53 <dhellmann> russellb : I would like to have them all in-tree, or at least in repos accepted by the parent project team.
20:41:00 <russellb> dhellmann: agreed
20:41:01 <sambetts> in regards to openness, all our code and libraries are apache 2.0 opensource, and though we right now have mostly developers from Cisco, we are unbias to code contributions from anywhere
20:41:02 <flaper87> dhellmann: ++
20:41:10 <persia> Is it important that it is a single vendor, or that the back end is not open, or only if both apply?
20:41:11 <russellb> sdague: some have in the past, though it's frowned upon these days
20:41:23 <dhellmann> persia : the closed backend is more important, imho
20:41:27 <sdague> russellb: do we know where this driver falls on that line?
20:41:44 <russellb> in terms of hacking the API?  i don't.  sambetts, does networking-cisco add custom REST APIs?
20:41:46 <dhellmann> persia : i have to have access to gear to test, and I have to have access to new project feature information that might not be public to develop
20:41:48 <ttx> sambetts: but contributors from Cisco happen to have access to the code of the black box you're interfacing with... which gives them a clear advantage
20:41:51 <fungi> lack of an open backend means nobody can test changes to the driver adequately unless they buy/license the target backend
20:41:59 <flaper87> sdague: not sure that's the biggest concern, tbh.
20:42:21 <ttx> sambetts: unless you end up providing every potential contributor with the appliances source code and test hardware
20:42:55 <ttx> sambetts: the end result will be that only Cisco will contribute to that team, and that team will forever be single-vendor
20:43:07 <cburgess> ttx sambetts how is this different from most of the cinder drivers? Is the difference the fact that this is *out of tree* from an already accepted project?
20:43:08 <ttx> I don't see the point of putting that under OpenStack governance
20:43:10 <dhellmann> rather than rejecting this, I would prefer that we work with the neutron team to reverse the dissolution decision
20:43:13 <russellb> i think the more valuable conversation here is trying to figure out if we can make driver handling more consistent in openstack
20:43:27 <flaper87> russellb: dhellmann ++
20:43:29 <dhellmann> cburgess : yes
20:43:32 <flaper87> yes
20:43:43 <dougwig> dhellmann: that's not likely to happen.
20:43:45 <russellb> because this is going to come up 25 times
20:43:46 <fungi> also that makes for some rather slow turn-around on adding new contributors if they do. for example i may want to propose some mass changes for a particular bug across many projects. i wouldn't be able to locally test my changes for that particular repo without some significant turn-around time to get the required hardware
20:43:47 <russellb> just for neutron
20:43:51 <ttx> So, let's use the delay to have a larger discussion about vendor drivers in OpenStack
20:43:57 <ttx> and try to present a coherent front
20:44:05 <flaper87> sounds good to me
20:44:08 <anteaya> dhellmann: I think that ship sailed when neutron decided to make driver testing optional
20:44:09 <dhellmann> dougwig : does neutron have a stable driver API?
20:44:21 <russellb> stable-ish
20:44:26 <sambetts> we have documented open APIs for our hardware, and I don't see why someone unrelated to Cisco who has a peice of our hardware couldn't contribute a feature they want
20:44:28 <russellb> has been getting much better lately
20:44:52 <annegentle> I think this is about consistency in treatment of driver teams -- the conversation about backports comes to mind as well.
20:45:03 <dhellmann> sambetts : could I do the same for an unreleased piece of hardware?
20:45:16 <dougwig> dhellmann: even simple requirements bumps can break things.  and with 30+ drivers, and drive-by vendor contributors, it was a lot of work even to kick out the stuff that had gone idle. that solution doesn't scale.
20:45:35 <ttx> sambetts: they would still have a harder time than a Cisco developer with access to the black box code, and factory-cost hardware
20:45:41 <sambetts> dhellmann: we wouldn't consider putting in there
20:46:00 <dhellmann> dougwig : is the neutron team accepting any of these drivers, or are they all being pushed out? what's the dividing line?
20:46:06 <sambetts> and we strive to provide third party CI for all hardware backends we support
20:46:09 <ttx> We need to move on
20:46:30 <russellb> everything is split, except for the "default" stuff, which was honestly too embedded to be split out (my take on how it went down)
20:46:34 <dougwig> dhellmann: the ref implementation (ovs & lb) are all that remain.  the plugin interfaces are being maintained as stable interfaces.
20:46:36 <russellb> nobody motivated enough to extract that stuff
20:46:37 <ttx> My take is, we need to delay this until Ocata is started and the var is open to new project teams again (and the next TC is elected)
20:46:42 <ttx> bar*
20:46:50 <fungi> sambetts: on the requirements change point, avoiding involvement in community processes which are hard to implement because your backend is proprietary doesn't make for a compelling argument for why it should be an official community project
20:46:53 <cburgess> ttx I think you put too much on this whole access to the black box. I'm a cisco employee and I can't just go download the source for how one of our devices works. It doesn't work that way.
20:46:58 <dhellmann> ttx: I agree with waiting.
20:47:03 <ttx> And we should take the time until then to reflect back on vendor drivers everywhere and present a more coherent front
20:47:17 <russellb> ttx: +1, especially to the latter point
20:47:30 <dhellmann> ++
20:47:33 * flaper87 nods
20:47:35 <fungi> cburgess: i find that (and all proprietary software) unfortunate
20:47:47 <ttx> ok, next topic
20:47:49 <dtroyer> cburgess: it really is not about individual contributors as much as it is about simply being open and accessible and available
20:47:58 <ttx> #topic Add ocata goal "support python 3.5"
20:48:06 <ttx> #link https://review.openstack.org/349069
20:48:18 <ttx> Last week we explored three ideas -- making unit tests an optional part of the goal, rewrite it with full-stack-testing as an objective, or find some other goal entirely
20:48:31 <ttx> notmyname said dropping unit tests would not really make the goal easier for Swift, so there seems to be little point in doing  that
20:48:48 <ttx> sdague said he would explore a py35 full-stack-testing goal variant but was worried about lack of activity drivers, since most py35-pushing folks are not involved with devstack/gate
20:49:01 <ttx> ... and no alternate goal was proposed
20:49:11 <ttx> So this is a bit stalled
20:49:15 <sdague> ttx: well, it was feature freeze week :)
20:49:19 <sdague> + holiday
20:49:23 <dhellmann> ttx: haypo has agreed to lead a team of helpers. I'll be on the team. We can recruit others.
20:49:28 <russellb> this goal still seems to obvious to me ... i'm not sure what to say
20:49:36 <dhellmann> where helpers != "we're going to write your patches for you"
20:49:37 <ttx> sdague: yes, fair. Happy to put it back on agenda next week. Not much time left today anyway
20:49:39 <russellb> s/to/so/
20:50:04 <sdague> russellb: I think the end goal is good for sure
20:50:16 <russellb> ok
20:50:28 <sdague> I guess the question is if it's just implementation path, do we figure out how to fuzz that and agree on the end goal
20:50:48 <dhellmann> I think it would be a mistake to say we can only have goals where we have a set of people "driving" the work. The point is to get project teams to integrate these things with their existing work.
20:50:49 <russellb> i think it's good enough to just say "yes, we agree this end goal is important, and we should try"
20:51:17 <sdague> dhellmann: I think that assumes that it's complete rote
20:51:29 <sdague> I'm not convinced we're at the completely rote stage here
20:51:31 <ttx> personally I'd rather have goals that can be clearly "completed", as opposed to say "advance the state of py35" and have everyone evaluate what "some progress" means
20:51:33 <notmyname> russellb: projects work on a goal and report progress?
20:52:05 <dhellmann> sdague : we have seen over and over that having a central team try to do work across all repos does not scale.
20:52:10 <jroll> sdague: I wonder if you might get more folks hacking on nova/devstack/gate than you think, if only because so many projects full stack testing depends on nova working
20:52:12 <ttx> but I also agree this one as proposed is a bit assymetric for that
20:52:29 <dhellmann> jroll : right
20:52:35 <sdague> jroll: that's fine
20:52:53 <mtreinish> dhellmann: it's more than just an isolated thing in each project. We've had projects declare they're py3 compat on the ML but it's just unit tests. No one is driving getting a dsvm job running or any of the cross project work
20:52:55 <sdague> my instinct is that it won't just happen, but I'm happy to be proved wrong
20:53:09 <dtroyer> ttx: I do think it is worth us saying this is a high community priority, as a lot of the decision makers in corporate sponsors watch these things… this is one way to influence how resources get allcated
20:53:12 <dhellmann> mtreinish : that is the entire point of this goal, to make all of that happen
20:53:12 <ttx> OK, I propose to put it back on agenda next week (hopefully first item) and have people more ready to discuss it then
20:53:38 <flaper87> ttx: sounds good. We don't have much time left anyway
20:53:47 <dhellmann> please be ready to say something more specific than "this won't work"
20:53:54 <sdague> dhellmann: ok, but which project team owns the sunk shared cost? Like getting the first job running is going to be 10x the cost of the second project joining in.
20:53:54 <ttx> dhellmann: ++
20:53:57 <mtreinish> dhellmann: except nothing in the goal has people stepping up to do that work. Like d-g is an infra thing and devstack is an qa thing, but who owns getting things running with py3
20:54:20 <mtreinish> there is a lot of effort in getting things running in the gate on all projects, and it's not owned by a particular silo
20:54:25 <dhellmann> sdague : do we need to pick someone up front?
20:54:28 <ttx> mtreinish: a bit of everyone, that's the idea with the goals
20:54:30 <sdague> mtreinish: ++
20:54:42 <ttx> if we know who will do the work, what's the point in inspiring people to work on a thing
20:54:51 <dims> "tiger team"!
20:54:56 <sdague> ttx: is that the point?
20:55:04 <sdague> I thought the point was getting the thing done in a timely manner?
20:55:21 <flaper87> sdague: well, that's one of the points.
20:55:22 <sdague> if the point is to recruit new folks to a task, that's fine
20:55:30 <flaper87> If we have a goal, we also need to move it forward
20:55:31 <ttx> one of the points at least
20:55:35 <clarkb> mtreinish: there shouldn't be anything required from d-g to run openstack under python3
20:55:38 <clarkb> mtreinish: fwiw
20:55:39 <sdague> but it is actually orthoginal to timely manner
20:55:49 <mtreinish> clarkb: well flipping a devstack switch probably
20:55:56 <mtreinish> clarkb: or in project-config
20:56:06 <ttx> ok, need some time for open discussion, so we'll continue this one next week (or on the review in the mean time)
20:56:12 <ttx> #topic Open discussion
20:56:17 <amrith> ./
20:56:21 <mtreinish> clarkb: but it's a minimal change in code. It's more about tracking things and making it work. Which was kinda my point
20:56:24 <flaper87> patch updated
20:56:25 <ttx> I announced the first PTG date/location (Atlanta, Feb 20-24, 2017) in a ML thread
20:56:26 <clarkb> ya project-config might need to be edited to flip an env var, just pointing out python3 vs 2 isn't really something we care about when cloning git repos and collecting logs
20:56:30 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2016-September/102981.html
20:56:32 <flaper87> ttx: w00h0000
20:56:38 <ttx> On the Design Summit side, it will soon be time to plan the cross-project workshop track
20:56:48 <ttx> Traditionally we had 7 time slots and used 3 parallel rooms
20:56:57 <ttx> For this one, as sdague suggested we'll likely scale it back a little to preserve space for the "normal" sessions
20:57:06 <ttx> i.e. use only 6 time slots instead of 7 (we can still use 3 rooms, or more if needed)
20:57:27 <flaper87> happy to help with that, btw!
20:57:43 <ttx> does 6 time slots sound good ?
20:57:48 <annegentle> #info PTG date/location (Atlanta, Feb 20-24, 2017)
20:58:00 <flaper87> annegentle: +1
20:58:09 <sdague> ttx: honestly, I think we should see if we even have 6 x 3 sessions worth having
20:58:20 <sdague> I feel like we got very mixed at the bottom of the list last time
20:58:22 <fungi> i guess the minimal registration cost mentioned in the faq will have a specific number associated with it soon?
20:58:27 <fungi> (ptg)
20:58:28 <mtreinish> ttx: how does that effect scheduling. like how many sessions are there in a day?
20:58:31 <amrith> ttx, I've put my questions into https://etherpad.openstack.org/p/gMPYW40Fmq and referenced it in https://review.openstack.org/#/c/342225/8/reference/tags/team_diverse-affiliation.rst; not sure if there's time to discuss here and now.
20:58:38 <ttx> can be 6x (2 to 4 based on parallelization needs)
20:59:18 <ttx> mtreinish: not sure I understand your question, but we can take it offline
20:59:25 <ttx> flaper87: your patch is up ?
20:59:30 <flaper87> ttx: yup
20:59:33 <annegentle> amrith you have a good point on change set nomenclature vs review
20:59:33 <annegentle> vs patch set
20:59:45 <ttx> Please rereview https://review.openstack.org/#/c/342225/
21:00:00 <anteaya> annegentle: the gerrit wording is change and change set
21:00:00 <ttx> If it gets to majority I'll just approve it, otherwise it will be back next week
21:00:17 <annegentle> anteaya ah, good to know
21:00:19 <anteaya> annegentle: patch review CR and others are socialization terms
21:00:25 <amrith> ttx, to be clear, my question isn't a -1, rather a request to clarify.
21:00:28 <ttx> and ... we are out of time
21:00:33 <annegentle> wah
21:00:34 <annegentle> :) kidding
21:00:37 <mtreinish> ttx: what's the diff between 6 session vs 7? Does that mean we have 1 non cross project session on the tues? I'm not sure I see what diff it makes
21:00:44 <flaper87> bye folks!
21:00:47 <flaper87> thanks everyone
21:00:53 <sambetts> thanks :D
21:00:53 <ttx> #endmeeting