20:00:30 <ttx> #startmeeting tc
20:00:31 <openstack> Meeting started Tue Jan  3 20:00:30 2017 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:33 <dtroyer> o/
20:00:35 <openstack> The meeting name has been set to 'tc'
20:00:37 <ttx> Happy new year everyone!
20:00:48 <stevemar> happy new year!
20:00:50 <ttx> Our agenda for today is at:
20:00:55 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:01:07 <ttx> (2017 new year resolution: use #info #idea and #link liberally to make for a more readable summary)
20:01:11 <sdague> o/
20:01:26 <ttx> #topic Driver teams: establish new "driver team" concept, or not
20:01:36 <ttx> Two weeks ago we discussed this and boiled it down to two options
20:01:45 <ttx> Consider driver teams as being a piece of "OpenStack" (using the grey option as implementation):
20:01:48 <ttx> #link https://review.openstack.org/403829
20:01:57 <ttx> or not consider driver teams as being a piece of OpenStack unless they fill all the open collaboration requirements (soft black option):
20:02:02 <ttx> #link https://review.openstack.org/403836
20:02:09 <sigmavirus> o/
20:02:12 <ttx> mtreinish in particular was still not comfortable living by the grey option, and several TC members still preferred soft black.
20:02:24 <ttx> Taking a step back, for me the choice all depends on whether driver teams are looking for *recognition* or *discoverability*.
20:02:40 <johnthetubaguy> what would our users find useful here?
20:02:40 <ttx> If they are just looking for *discoverability*, then I think we can work out documentation / marketplace solutions that gives vendor drivers equivalent visibility to in-tree / in-team drivers
20:02:54 <ttx> without having to permanently change governance or compromise on open collaboration requirements for "OpenStack" proper
20:02:59 <dhellmann> right, I'm not that concerned with discoverability as a goal for this
20:03:02 <ttx> so choosing "soft black" + getting our act together on driverlog/docs/marketplace is a valid answer
20:03:12 <ttx> (and thingee volunteered to work on that, to give those teams what they need fast enough)
20:03:22 <ttx> But if they are /also/ looking for recognition, then grey is probably the most reasonable way to give it to them
20:03:29 <ttx> So... Do we have a clear view on what those teams are really after ?
20:03:31 <mtreinish> ttx: heh, that's a much more eloquent way to put what I was getting at during that last meeting :)
20:03:44 <ttx> johnthetubaguy: in both cases they get discoverability
20:03:46 <dhellmann> I'm much more interested in having us consider drivers to be an important enough contribution that we include those contributors in our community.
20:03:47 <thingee> as noted in 403829 I'm not in favor of it because I believe based on the conversations I've had with sambetts|afk at the summit that it's discoverability
20:03:47 <gordc> dhellmann: +1, that's what marketing/sales departments are for.
20:03:47 <stevemar> mtreinish: ttx does that
20:03:57 <ttx> stevemar: that is called preparation
20:04:03 <dims> :)
20:04:31 <thingee> so approving this is not necessary of what was originally being asked
20:05:10 <dtroyer> thingee: for the original case, maybe.  But we are considering a class of projects here...
20:05:17 <fungi> while i second dhellmann's desire to include driver development as contributing to our community, i worry that the grey option removes some impetus to follow our real community development expectations by giving them a watered-down version they can follow instead
20:05:18 * edleafe wanders in late
20:05:20 <dims> thingee ttx : is anyone else in the "drivers to be an important enough contribution that we include those contributors in our community" category?
20:05:20 <thingee> I understand sambetts|afk put up a review to created. I said originally, because at the summit, he was concerned about out of tree drivers in neutron not having documentation at docs.o.o
20:05:22 <ttx> dhellmann: from your interactions with that crowd, what would you say the need/want ?
20:05:27 <ttx> they*
20:05:46 <thingee> dtroyer exactly what dims asked, does anybody else want this, and give a good reason why
20:05:58 <mtreinish> fungi: ++
20:06:13 <dhellmann> ttx: I took their original request to be official at face value. The subsequent discussions about discoverability may speak more to their motivation. *My* motivation hasn't changed.
20:06:29 <fungi> i still old that is _is_ possible to develop drivers in a completely open fashion, and am not entirely comfortable saying it's okay if you find that too much effort
20:06:29 <thingee> I think if we fix some legacy things that disallow out of trees to be discovered, this is not necessary
20:06:37 <fungi> s/old/hold/
20:06:58 <dhellmann> thingee : discoverability and encouraging participation are orthogonal
20:07:13 <thingee> and if people are not in favor of making what a team's community of out of tree drivers more discoverable, then we should rediscuss if we want to allow out of tree drivers at all
20:07:17 <jroll> fungi: do you think it's possible to develop drivers for proprietary things on a level playing field? (how does that work, simulator-y things?)
20:07:35 <thingee> dhellmann can you explain how you see this encouraging participation?
20:07:49 <dhellmann> I don't believe if we tell a large number of groups of people we're not interested in what they're producing, they'll be highly motivated to participate in the core of projects.
20:08:01 <dtroyer> jroll: FWIW, I do not think it is _really_ possible, having tried that in more than one $DAY_JOB
20:08:04 <ttx> jroll: I think it's hard. May involve sending free test rigs to everyone interested.
20:08:05 <bswartz> you can't not allow out of tree drivers -- it's open source
20:08:05 <fungi> as evidence, i look to the littany of linux and *bsd kernel drivers which were developed initially without vendor assistance, and used as leverage to convince manufacturers to start providing better specs and documentation for their products so that anyone could write drivers for them
20:08:09 <thingee> dhellmann who is saying we're not interested?
20:08:31 <dhellmann> thingee : if we tell teams working on drivers that their contributions aren't allowed to be official, we are.
20:08:49 <thingee> again official and discoverability.
20:08:50 <sdague> I think the level playing field statement is a quagmire of vagueness when it comes to drivers.
20:08:56 <jroll> fungi: good example
20:09:06 <ttx> dhellmann: arguably we are saying they are not "OpenStack", but something that can be used with "OpenStack"
20:09:07 <thingee> you are official if we make it easy to discover your driver compatible with openstack
20:09:15 <thingee> ttx +1
20:09:36 <dhellmann> there's plenty of evidence that folks will write drivers anyway. I'm not worried about drivers going away. I'm worried about these companies with little experience being open having a bad experience when they're *trying* to be open.
20:09:52 <ttx> dhellmann: I get your point though. We need drivers for openstack to be successful so why not consider them in
20:10:04 <dhellmann> and deciding that a community built on the idea that we want lots of varied contributions doesn't want *their* contributions, of any sort
20:10:32 <johnthetubaguy> dhellmann: thats what I meant about what users want, they want their driver to be written in the open, following similar patterns to other drivers, ideally, but maybe I am overthinking it
20:10:33 <dhellmann> not all of them will choose to go through the trouble to become official, for various reasons
20:10:38 <thingee> dhellmann I agree. and that's why I think the larger problem of them not being included in various things they would get without this patch should be considered first
20:10:47 <dhellmann> johnthetubaguy : I agree, we should encourage open development of drivers.
20:10:54 <ttx> I'm on the fence, mostly because once official driver teams are created it will be hard to go back
20:11:21 <thingee> I think we should fix the larger problem first. If that doesn't fix things, we should revisit doug's proposal
20:11:35 <dhellmann> thingee : I don't think we want to start opening docs.openstack.org up to folks who have no relationship with us
20:11:35 <dtroyer> ttx: ++  and why it is clear to me we are not ready to go this route quite yet (if at all)
20:11:36 <sdague> thingee: and you think the larger issue is documentation discovery?
20:11:51 <ttx> sdague: and proper marketplace listings
20:11:56 <thingee> dhellmann we already do. cinder drivers which are in tree and are allowed to contribute their drivers in
20:12:13 <thingee> sdague that is one example and the one given to me by sambetts|afk himself with cisco
20:12:14 <jroll> thingee: being in cinder's tree is definitely some relationship
20:12:23 <johnthetubaguy> or we could make it so only openly accessible teams are listed?
20:12:25 <dhellmann> thingee : cinder drivers in-tree are part of a repo that belongs to a team that works with the tc, even if the specific contributors are not
20:12:28 <thingee> jroll right, again larger problem is with out of tree drivers here
20:12:50 <dhellmann> thingee : if all of the drivers were in tree, we wouldn't even be having this conversation
20:12:52 <thingee> we need to set what they can do that you get for being in tree. we have no business of saying what an individual team considers part of their project
20:12:56 <jroll> this would open it to *anything* in the openstack git namespace, which is open to any code
20:13:08 <jroll> "it" being docs.o.o
20:13:20 <thingee> dhellmann and again, I say revisit whether we should allow out of tree
20:13:29 <ttx> thingee: I agree we could give the non-nuclear option a try, but how long do you expect it will take to get things fixed on the documentation / discovery front ?
20:13:32 <fungi> it seems to me like docs.o.o is probably not the ideal venue to host driver-specific documentation anyway, and instead we should let official projects continue to document driver-related things in their own documentation while simultaneously improving the marketplace to allow driver authors to specify links to wherever they want to host their own driver-specific documentation
20:13:32 <thingee> this is just a bandaid fix imo
20:13:34 <dhellmann> thingee: so you're after the red option?
20:13:53 * thingee checks color code cliff notes
20:14:06 <dhellmann> thingee : that's the one where the TC requires project teams to take in all drivers
20:14:19 <dhellmann> thingee : we rejected that as too harsh
20:14:28 <dhellmann> this isn't a question of the motivation of the driver authors for being in tree
20:14:32 <ttx> dhellmann: I think he is after one of the black options. Drivers can be made out of openstack
20:14:34 <dhellmann> they've been kicked out by their host project
20:14:48 <thingee> dhellmann no, I'm saying that the discussion should be revisited if we're even beginning to question out of tree drivers.
20:14:59 <dhellmann> ttx: under that approach we can solve the discoverability problem, but not the community membership problem
20:15:18 <fungi> yeah, i don't feel comfortable telling ptls what drivers they have to include in their project teams, much less in their source code trees for consuming services
20:15:23 <dhellmann> thingee : I'm not sure we're on the same page at all.
20:15:55 <johnthetubaguy> not all "drivers" are the same thing at this point either
20:16:01 <ttx> dhellmann: agreed. It is the crux of the issue. Whether we want to consider those teams (and their slightly-less-open development methods) as a part of OpenStack
20:16:01 <thingee> ttx I guess if I begin proposing various ways to have to vendor products more included and the person who originally requested this sambetts|afk feels I'm meeting his requests reasonably, that we can consider that a win?
20:16:05 <dhellmann> thingee : all of the alternatives you've proposed can be done independently of this change except allowing publishing to docs.openstack.org, afaict. Am I missing something?
20:16:07 <bswartz> fungi: I disagree about the docs -- for some projects the most important part of configuring them is the driver configuration, and the config guide on docs.o.o is a good place for that information
20:16:36 <thingee> dhellmann yes, I'm saying we can do maybe do without your proposals and just fix sambetts|afk's initial problems with even requesting to be an official team
20:16:43 <dhellmann> ttx: if you remember, I was in favor of *not* allowing special openness rules. I do see the argument in favor of loosening some, and could live with it, though.
20:16:49 <fungi> bswartz: and letting each individual driver vendor write that documentation inconsistently and outside your project's control and host that on docs.o.o is a good idea?
20:16:57 <dhellmann> thingee : that doesn't solve *my* problem, though
20:17:14 <ttx> dhellmann: well, the alternative was to relax rules for everyone...
20:17:21 <bswartz> fungi: the project teams can and do review it, as do the docs team
20:17:44 <fungi> bswartz: even for repos maintained by unofficial teams?
20:17:48 <dhellmann> thingee : the request from sambetts|afk highlighted a separate issue related to community membership that I'm trying to address in some way. I'm not really concerned with discoverability, except as a side-effect of being inclusive.
20:18:01 <dhellmann> ttx: true.
20:18:39 <ttx> back to whether driver teams want recognition as a part of openstack or really don't care that much
20:18:55 <bswartz> fungi:  talking about cinder/manila config guides
20:19:17 <dims> dhellmann : right, so i was asking if anyone is really is feeling left out
20:19:22 <ttx> dhellmann: was there anything explicit, or do you consider them applying as sufficient proof ?
20:19:24 <fungi> bswartz: i'm not concerned about documentation vetted by and under teh control of manila, more worried about letting random manila driver teams not under manila or the docs team's oversight push up whatever documentation they want and serving it from an official-looking openstack website
20:19:32 <thingee> well if it's about community membership, there's the incentive some have brought up in your proposal review. Contribute to the core project to rather than just your individual out of tree driver repo.
20:19:34 <dhellmann> dims : do we wait for someone to have that problem and not report it before we do something?
20:19:35 <thingee> dhellmann ^
20:19:43 <dims> dhellmann : good point
20:19:55 <bswartz> fungi: manila has all the drivers in tree -- I don't want them anywhere else
20:20:21 <bswartz> out of tree drivers are an abomination IMO
20:20:40 <dhellmann> thingee : telling people we don't care about their driver contributions isn't likely to have a positive effect on their contributions elsewhere. Offer them a carrot.
20:20:49 <ttx> bswartz: but if someone does drivers somewhere on github, you'd prefer that we don't adopt them as a separate openstack project, right ?
20:20:51 <fungi> bswartz: and that's fine. i'm saying instead of encouraging random out-of-tree drivers not maintained by the teams responsible for the services with which they're integrated host their own individual documentation on docs.o.o themselves
20:21:04 <jroll> fungi: reminder that the docs team does not oversee most of the big tent's docs, e.g. ironic just pushes whatever docs it wants
20:21:09 <bswartz> ttx: correct -- they should contribute directly to manila or stay on github
20:21:20 <ttx> dhellmann: supposing that's a carrot to them
20:21:25 <thingee> dhellmann are we having a shortage of drivers though in this being a problem. Last time I checked cinder drivers are still growing beyond 80 drivers now
20:21:46 <fungi> jroll: yep, which is why i said "or" here. i'm worried that a team which isn't the docs team nor ironic would be greenlit to publish ironic driver docs on docs.o.o
20:21:47 <dtroyer> bswartz: does that approach result in any (or many?) thin in-tree wrapper drivers calling out to a propriteaty actual-driver somewhere?
20:21:53 <sdague> do we have neutron community folks around? Because this really impacts neutron first.
20:21:57 <thingee> The carrot is you're compatible with OpenStack because you follow the individual project team's guidelines of what is official
20:21:58 <dhellmann> ttx: yes, well, interpretation is up to the observer.
20:22:12 <ttx> sdague: yes, wondering if we should not survey driver teams and see how much they care with the two solutions
20:22:24 <sdague> And it would be good to have inputs there. I think we've mostly had cinder, nova, manilla voices, which are definitely more intree oriented
20:22:26 <ttx> s/with/about/
20:22:32 <mtreinish> sdague: yeah, although do we think any other project will follow the neutron model?
20:22:35 <jroll> fungi: idk, I don't have a problem with that, personally. some docs are better than none
20:22:37 <dhellmann> thingee : and if the project team's guideline is "only this one driver, and we don't care about yours" then what option does someone have?
20:22:49 <bswartz> dtroyer: that hasn't been a problem for us -- we make it hard to do that by frequently changing the driver interface (similar to how Linux makes out of tree drivers painful to maintain)
20:22:51 <mtreinish> because it seems kinda unlikely to me that any of the other projects will
20:23:01 <dtroyer> mtreinish: neutron seems to be unique partially because of its histroy as a heavily vendor-driven project from the start
20:23:10 <mtreinish> dtroyer: right
20:23:18 <sdague> jroll: would ironic end up in this model as well?
20:23:20 <smcginnis> mtreinish: I agree
20:23:22 <thingee> dhellmann again, that's a problem of a particular project that I think we're trying to fix in the tempest related review I gave
20:23:26 <jroll> ironic has out of tree drivers as we require CI
20:23:30 <fungi> jroll: i mean as opposed to letting them host their documentation elsewhere. they're not going to automatically end up in an index on docs.o.o anyway, so if the driver marketplace is the index to driver documents, having some of them linking to documentation elsewhere seems fine to me
20:23:31 <dtroyer> bswartz: thx
20:23:36 <jroll> sdague: not pushing 100% out, but forcing some to stay out, yes
20:23:45 <ttx> OK, so that we know where we stand today... I propose a quick indicative vote for TC members
20:23:47 <sdague> or, so ironic and neutron are going to be primary consumers
20:24:02 <sdague> and I feel like we haven't really had a ton of neutron feedback here
20:24:07 <fungi> saying driver=specific documentation without collaboration from the consuming project doesn't automatically become more "discoverable" by getting served from docs.o.o
20:24:19 <jroll> fungi: yeah, I suppose. I guess I lean toward 'why not' on the docs point, rather than 'why' :)
20:24:44 <ttx> #startvote Where do you stand? allow-driver-teams, just-improve-discovery, on-the-fence
20:24:45 <openstack> Begin voting on: Where do you stand? Valid vote options are allow-driver-teams, just-improve-discovery, on-the-fence.
20:24:46 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
20:24:54 <ttx> #vote on-the-fence
20:24:56 <thingee> armax has started the conversation in setting the precedent of how out of tree drivers could be tested. If we support that idea, we can begin using the neutron communities' guideline  of what  is official and highlight those like we do with other vendor products.
20:24:59 <fungi> #vote just-improve-discovery
20:25:02 <dhellmann> #vote allow-driver-teams
20:25:07 <mtreinish> #vote just-improve-discovery
20:25:12 <sdague> #vote on-the-fence
20:25:16 <EmilienM> #vote allow-driver-teams
20:25:18 <dtroyer> #vote allow-driver-teams
20:25:23 <thingee> dhellmann contributors being paid by a company don't need to incentive from the community to contribute driver code.
20:25:25 <dims> #vote on-the-fence
20:25:31 <johnthetubaguy> vote one-the-fence
20:25:39 <sdague> johnthetubaguy: you need a #
20:25:40 <ttx> johnthetubaguy: add #
20:25:40 <dhellmann> thingee : the company needs an incentive to allow them to do anything other than that, though
20:25:41 <thingee> #vote just-improve-discovery
20:25:48 <johnthetubaguy> #vote on-the-fence
20:25:59 <thingee> dhellmann can you give me examples of where that's a problem today though?
20:26:17 <fungi> thingee: i'd rather start from an even more loose position of giving projects a means of registering driver details into the driver marketplace using whatever criteria they feel is appropriate to determine "support"
20:26:18 <johnthetubaguy> sdague: ttx: sorry one handed badness
20:26:21 <ttx> Explaining my on-the-fence: I'd like to reach out to driver teams and assess how much they want recognition vs. discoverability
20:26:34 <ttx> because we seem to be assuming a lot (one way or another)
20:26:40 <dhellmann> thingee : I don't think we need to wait for a problem to exist before we try to address it.
20:26:41 <stevemar> #vote on-the-fence
20:26:44 <fungi> thingee: rather than requiring cinder and neutron to agree on what makes a driver supported
20:26:52 <ttx> ending vote in 20 sec
20:27:10 <ttx> #endvote
20:27:11 <openstack> Voted on "Where do you stand?" Results are
20:27:12 <openstack> on-the-fence (5): dims, ttx, stevemar, sdague, johnthetubaguy
20:27:13 <openstack> allow-driver-teams (3): EmilienM, dhellmann, dtroyer
20:27:15 <openstack> just-improve-discovery (3): thingee, mtreinish, fungi
20:27:19 <ttx> Pretty split
20:27:25 <thingee> dhellmann I find that too bad that the TC wants to open this gate when there is no problem.
20:27:44 <dims> i'd like to understand if what can be done w.r.t just-improve-discovery without the need for TC intervention
20:27:48 <fungi> i'll note that i'm really in favor of "first-improve-discovery" (and then see if we still have a problem)
20:27:48 <johnthetubaguy> fungi: I like that starting point idea, the projects know best
20:28:00 <thingee> johnthetubaguy +1
20:28:03 <dims> fungi : true
20:28:04 <ttx> As an on-the-fence I propose to reach out to driver teams and try to get their feeling
20:28:13 <ttx> stevemar: would you mid helping me in there ?
20:28:18 <ttx> mind*
20:28:21 <jroll> fwiw the TC is typically pretty reactive, I'd love to see some proactiveness here if we're confident the problem will happen eventually
20:28:26 <stevemar> ttx: sure
20:28:38 <dtroyer> Does anyone have a sense of what might change for the nova/cinder/manila teams if driver teams were introduced?
20:28:47 <jroll> ttx: stevemar: I can hook you up with some folks maintaining out of tree ironic drivers, if that's helpful
20:28:48 <ttx> dims, stevemar, sdague, johnthetubaguy: anything else we should do this week to help you make a call ?
20:28:52 <dtroyer> ie, unintended consequences?
20:29:23 <smcginnis> dtroyer: My only concern with all of this is having less incentive to contribute to core code.
20:29:32 <fungi> jroll: i'm happy to talk to the foundation site devs about dumping some more time into improving the driver marketplace (which is really just a sort of poc right now), but would need input from different teams on what would make it usable for them
20:29:40 <ttx> dtroyer: not really, but yes introducing driver-teams is a more significant move than just sitting and fixing discoverability
20:29:42 <stevemar> jroll: that would be helpful. ttx i just want to make sure what we're proposing actually helps the folks we're trying to help (so reaching out to driver teams sounds like a good place to start that)
20:29:48 <johnthetubaguy> ttx: I would be tempted to approve driver teams, but I am attracted by the option of discoverability controlled by projects
20:29:59 <dtroyer> smcginnis: you feel that you might see companies going in the opposite driection of what we are trying to achieve?
20:30:05 <dhellmann> smcginnis : I wouldn't expect a lot of impact on that to teams that welcome drivers into the parent projects.
20:30:12 <thingee> smcginnis I think this proposal in recognizing individual contributors in their vendor's team deliverables will not help with core contributions
20:30:44 <sdague> ttx: mostly I want to know that whatever we're doing is actually going to solve the problem for neutron over the next year, with feedback from some of the neutron leadership on that
20:30:50 <ttx> OK, I don't think we'll make more progress today. Feel free to discuss this (dhellmann and thingee in particular as you seem to lead both options)
20:30:50 <thingee> recognizing openstack contributors have to come from the projects themselves, not vendor python libraries, etc
20:31:02 <johnthetubaguy> I guess I feel more worried about encouraging open collaboration on the vendor drivers
20:31:03 <dims> ++ sdague
20:31:04 <ttx> sdague: ok, so making sure we cover neutron in our analysis
20:31:10 <thingee> ttx yes I will be happy to continue working this out with dhellmann
20:31:18 <ttx> I propose we move on
20:31:22 <smcginnis> dtroyer: Just a concern if we do anything that they are able to state they contribute to OpenStack by allowing them to work in isolation. Unfounded concerns probably.
20:31:25 <dhellmann> yes, let's move on
20:31:58 <johnthetubaguy> sdague: good point, the proposal currently excludes many neutron drivers due the the API clause
20:32:00 <ttx> #action ttx and stevemar to reach out to prospective driver teams and assess how much they care about recognition vs. just discoverability
20:32:07 <ttx> #topic Disallow downtime of controlled resources during upgrades
20:32:14 <ttx> #link https://review.openstack.org/404361
20:32:18 <dolphm> o/
20:32:22 <ttx> dolphm: o/
20:32:29 * ttx checks for refresh
20:32:49 <dolphm> since the last time this was on the agenda, i've incorporated some feedback into the latest review...
20:33:05 <dolphm> specifically, checkout L45-51 for some updated wording https://review.openstack.org/#/c/404361/6/reference/tags/assert_supports-accessible-upgrade.rst
20:33:22 <ttx> lgtm
20:33:36 <ttx> dhellmann: does the new wording fix your concerns ?
20:33:38 <dhellmann> the new wording addresses my only nit, thanks dolphm
20:33:44 <dolphm> dhellmann: thanks for the feedback
20:34:14 <sdague> dolphm: ok, so basically if we do this the net is
20:34:30 <stevemar> dolphm: lgtm, but i was OK with previous revs too
20:34:39 <sdague> nova, cinder get accessible upgrades, neutron / glance do not?
20:34:50 <sdague> just to get this chunking in my head
20:35:09 <johnthetubaguy> just checking a phrase here: "continuously validated"
20:35:19 <EmilienM> sdague: glance doesn't?
20:35:25 <dolphm> no one would get it out of the gate, unless someone is already asserting the availability of resourcing during an upgrade?
20:35:32 <dolphm> johnthetubaguy: that's a slight change since the last revision as well
20:35:45 <mtreinish> EmilienM: you can't get to the images during an upgrade
20:35:46 <sdague> EmilienM: when the glance services are offline, there is no access to their resources
20:35:59 <sdague> because their resources are only http accessable
20:36:02 <EmilienM> indeed
20:36:23 <sdague> dolphm: ok, but conceptually, the services that can do this
20:36:38 <sdague> neutron can't because of ovs link resets and the like
20:37:18 <dhellmann> sdague : is that a fundamental problem with neutron, or could it be fixed?
20:37:23 <ttx> are ovs link resets "abnormal", though ?
20:37:24 <EmilienM> I thought the neutron thing changed in the last releases, I remember some parameters in Neutron to disable this thing
20:37:36 <sdague> dhellmann: it's a fundamental problem with some backends
20:37:42 <sdague> including the leading ones
20:37:47 <dhellmann> ok
20:38:25 <jroll> maybe this needs to reference a 'reasonable' amount of downtime? e.g. one packet dropping is probably fine, putting glance behind a load balancer and coordinating service restarts is probably fine
20:38:26 <dhellmann> I'm not really sure what it buys us to have this flag at all if we have 2 fundamental services that can't achieve it, and therefore the cloud can't achieve it.
20:38:33 <johnthetubaguy> its generally where projects sit in the dataplane, they have lots to do
20:38:34 <jroll> like, things ops would care about, not 0 downtime ever
20:38:40 <jroll> if that makes sense
20:38:41 <fungi> i'm still a little fuzzy on how we expect to "continuously" test to prove that a service isn't unavailable at some random point during teh upgrade process
20:38:44 <dhellmann> jroll : ++
20:38:45 <johnthetubaguy> jroll: that feels like yet another tag, but thats a fair point
20:38:55 <fungi> but maybe i'm getting too deep into imagining the implementation?
20:39:12 <johnthetubaguy> fungi: "continuously" is the bit worrying me
20:39:12 <ttx> jroll: yes, and that definition may vary
20:39:14 <jroll> johnthetubaguy: if it's another tag, I guess I'm asserting this one isn't terribly useful
20:39:48 <johnthetubaguy> jroll: this one would be one Nova could assert (if you turn off consoles, I guess...)
20:39:52 <jroll> johnthetubaguy: for something like glance, if an op wants zero downtime, a load balancer (and coordination) should be a requirement
20:40:11 <EmilienM> sdague: I think the neutron thing was fixed by https://review.openstack.org/#/c/182920/
20:40:15 <dhellmann> jroll, johnthetubaguy : right, if the point is to get to a state where it's possible to upgrade openstack with little disruption, and we're defining the way to do that as something some projects can't ever do, then how is it useful to say that even some projects can do it?
20:40:16 <mtreinish> fungi: start a separate process to ping a server in a loop throughout a grenade job and fail if it drops? :p
20:40:22 <dolphm> for services that don't manage resources outside the control plane, i think the question is whether the tag should apply at all, or whether you get this tag for "free" by successfully asserting the rolling upgrade tag
20:40:22 <jroll> dhellmann: ++
20:40:26 <johnthetubaguy> jroll: yeah, I am OK with that, but they need to be able to run old and new services at the same time to do that
20:40:29 <mtreinish> s/drops/drops any packets/
20:40:32 <jroll> johnthetubaguy: indeed
20:40:43 <fungi> mtreinish: that only proves it was up at the times those icmp echo requests arrived
20:40:46 <dims> mtreinish : ssh session instead? :)
20:40:47 <ttx> sdague: would glance pass this with rolling updates (like you can always find an API server that works) ?
20:41:00 <fungi> mtreinish: but proves nothing about the (micro?)seconds between each ping
20:41:14 <mtreinish> dims: yeah, ssh would be a better test :)
20:41:18 <johnthetubaguy> dhellmann: depends if you can make a very available cloud with a set of projects that all assert the "better" tag, until we can, its a bit useless I guess
20:41:20 <mtreinish> fungi: fair point
20:41:22 <dhellmann> fungi : I think "continuously" was added when someone pointed out that a test before and after an upgrade doesn't actually ensure that the resources was available *during* the upgrad
20:41:27 <sdague> dhellmann: well I think the fact that neutron can't right now should impact future evolution, because it's not really a neutron limitation but how some backends were done because this wasn't being thought of
20:41:33 <dolphm> dhellmann: ++
20:42:15 <sdague> ttx: maybe, we're starting to get pretty deep into HA architecture... which is fine, but up until this point the OpenStack upstream hasn't dictated that (it was left to distros / install tools)
20:42:15 <dhellmann> fungi : so it's not the literal mathematical definition of continuously, but "during the upgrade with a reasonable sampling rate" or something else less word salady
20:42:36 <johnthetubaguy> sdague: I think you reminded me I need to understand those neutron problems better
20:42:41 <dolphm> i feel like asserting testing methodologies in tags is getting a little bit too much into the implementation details. if a project applies for a tag, i think it's up to the TC to determine whether the implementation of the tests satisfies the spirit of the tag
20:42:48 <ttx> OK, I'm starting to wonder what user question this answers
20:42:50 <dhellmann> sdague : is the problem in the driver, or in the thing the driver talks to?
20:43:19 <dhellmann> dolphm : yeah, I was trying to clarify the wording for the discussion but I think it's fine as it is in the doc now
20:43:21 <EmilienM> what are the neutron problems we are discussing of? is there any launchpad bug reference? I've seen https://bugs.launchpad.net/neutron/+bug/1383674 but it seems fixed for OVS backend. What else would cause this downtime?
20:43:23 <openstack> Launchpad bug 1383674 in neutron "Restarting neutron openvswitch agent causes network hiccup by throwing away all flows" [High,Fix released] - Assigned to Ann Taraday (akamyshnikova)
20:43:23 <sdague> so, EmilienM may be right that - https://review.openstack.org/#/c/182920/ fixed it
20:43:35 <ttx> basically WHY are we introducing this if it's not to drive behavior nor to answer a user question
20:43:37 <dhellmann> yay, ok
20:43:41 <sdague> EmilienM: if the OVS backend flow rebuild is handled, that's fine
20:43:43 <johnthetubaguy> dolphm: yeah, I am largely agreed with that (does the testing spot the massive whoppers), I worry the wording in the proposed tag doesn't cover that
20:43:47 <dolphm> ttx: "my cloud provider advertises that they upgrade their cloud every day with the latest security updates, etc. will that affect my ability to consume cloud without interruption?"
20:43:54 <jroll> sdague: reference HA architecture bits feels like a useful thing for upstream to dictate - e.g. "you should run two of these conductor things, you should put APIs behind LB"
20:43:56 <sdague> but that can't survice an OVS upgrade itself
20:44:08 <fungi> dhellmann: my concern with "continuously" is more that i think there may be a misconception that there's anything _actually_ continuous in computing, and we need to design around the native discontinuity there instead (and word things accordingly)
20:44:11 <sdague> jroll: sure, I don't disagree, it's just new territory
20:44:13 <jroll> as one of the first people to ever deploy ironic in production... I would have loved to have that
20:44:15 <jroll> nod
20:44:33 <EmilienM> russellb: any thoughts on  ^^^^ ?
20:44:58 <dhellmann> fungi : sure. I think I agree with dolphm that we don't want to put too much detail about the way to do it in the tag, but try to express the desired outcome.
20:44:59 <dolphm> johnthetubaguy: are you focusing on the word "continuously", or something else?
20:45:03 <sdague> jroll: and something that needs to be a bit more consistent across the projects. Because if one shows how to do it with haproxy, and another with something else, it's not super useful for a whole system :)
20:45:11 <jroll> sdague: +10000000
20:45:19 <johnthetubaguy> dolphm: yeah, I am fixed on that word for reasons I don't understand
20:45:21 <ttx> dolphm: feels a lot like "are those services working as the industry considers they should"
20:45:27 <johnthetubaguy> sdague: jroll: +1
20:46:06 <sdague> I thought the basic question being answered was to Operators
20:46:07 <jroll> I think of these as answers to ops questions, "how often (and how painful) is it reasonable to upgrade things"
20:46:15 <fungi> really, we have a lot of different services used in different ways, and what sorts of outages are impactful for each of them varies accordingly
20:46:27 <johnthetubaguy> sdague: FWIW, I consider ovs a host/hypervisor upgrade, so its like a machine swap, if you don't want some packet loss
20:46:35 <ttx> OK, feels like we'll need another round here
20:46:47 * johnthetubaguy face palm
20:47:02 <johnthetubaguy> ignore that, thats more outage than ovs replace
20:47:08 <ttx> dhellmann, sdague: please make sure to file your remarks/concerns on the review
20:47:17 <sdague> jroll: right, and if I upgrade service X do I need to plan for customers seeing an outage
20:47:23 <johnthetubaguy> we did some ovs upgrades, but you get packet loss
20:47:42 <jroll> sdague: yep, meaning service X is going to get real old real fast :)
20:48:06 <fungi> and brief packet loss for tcp-based protocols or thinbs which implement error correction/retransmission at the application layer may still be completely seamless
20:48:24 <ttx> feels like we'll have a hard time defining this as a tag, could be suggestions for improvements / goal instead
20:48:26 <dolphm> jroll: if users are experiencing pain, then ops experiences the wrath of users... i don't see this as solving an ops pain point directly
20:48:27 <fungi> s/thinbs/things/
20:48:42 <jroll> dolphm: not solving ops pain points, answering ops questions
20:48:52 <dolphm> jroll: ah, i follow then
20:48:52 <ttx> because defining "reasonable" and "normal" behavior will be hard overall
20:48:54 <johnthetubaguy> I like sdague's suggestion of upgrade focused goals
20:48:59 <jroll> ideally users never notice an upgrade :)
20:49:00 <ttx> anyway, i suggest we move on
20:49:10 <ttx> and continue to discuss on the review
20:49:14 <johnthetubaguy> jroll: +1, tricky to define
20:49:26 <ttx> since this is not ready
20:50:07 <ttx> #topic Pike goals
20:50:14 <ttx> Not much time to discuss this
20:50:16 <EmilienM> o/
20:50:18 <ttx> EmilienM: looks like we have two goals proposed so far ?
20:50:26 <ttx> anything else promising in the backlog ?
20:50:30 <ttx> #link https://etherpad.openstack.org/p/community-goals
20:50:31 <EmilienM> yes, python-3 and tempest plugin AFIK
20:50:36 <ttx> * Add Pike goal split out tempest plugins (https://review.openstack.org/369749)
20:50:39 <ttx> * add goal "support python 3.5" (https://review.openstack.org/349069)
20:50:59 <EmilienM> we had one goal for Ocata, having 2 goals for Pike would probably make sense
20:51:01 <dhellmann> I saw some useful input from the product working group on the etherpad earlier today
20:51:08 <ttx> ah, missed it
20:51:27 <ttx> How are the proposed two doing in terms of community acceptance ?
20:51:29 <dhellmann> there were comments about their interest in some of the existing things, and one new one at the bottom
20:52:14 <EmilienM> ttx: for the python 3.5 goal, I haven't seen any pushback - https://review.openstack.org/#/c/349069/ (and ML)
20:52:32 <sdague> those seem like reasonably scoped things, and have champions, so seems solid
20:52:33 <mtreinish> ttx: well I don't think anyone ever opposed the python 3 support. It was always more just a matter of feasibility in a timeframe and scope
20:52:39 <dhellmann> the only issue reported there was some concern about which python 3.5, since there's a bug swift needs fixed
20:52:39 <fungi> though the infra team is using its own definition of compliance with the python 3.5 goal, which may not align with others' assumptions
20:52:40 <thingee> yes, I think we can move forward with py 3.5
20:52:41 <EmilienM> ttx: for the tempest plugin goal - https://review.openstack.org/369749 - there are still some discussions in the proposal
20:52:54 <EmilienM> sdague: ++ indeed
20:53:03 <jroll> has the tempest plugin goal been talked about on the ML? it has had some opposition in the patch
20:53:37 <ttx> dhellmann: I guess that could be grounds for an exemption until 3.6 is done (or the bug is fixed) ?
20:53:38 <dims> mtreinish : dhellmann : i have only good things to say about teams i reached out to with issues for the dsvm up/down test
20:53:42 <dhellmann> jroll: I haven't seen a thread, but I'm a few hours out of date
20:53:53 <stevemar> i like the advantages outlined in the tempest plugin patch
20:53:57 <jroll> dhellmann: I'd expect a thread more than a few hours old by now :P
20:54:06 <ttx> done -> widely available
20:54:07 <dims> ttx : there are other things that need to be fixed in swift well before that referenced bug is of concern
20:54:09 <dims> IMHO
20:54:20 <dhellmann> ttx: the fix is in a patch-level update to 3.5 (I don't remember which off the top of my head) but yes, I agree, that would make a delay OK in my mind
20:54:21 <ttx> dims: right, so they could be working on that
20:54:41 <dhellmann> dims : excellent, and thank you for picking that up
20:54:47 <mtreinish> jroll: oops, i forgot to start a thread before the holidays when you asked me before
20:55:02 <ttx> EmilienM: when do you want to have the goals set in stone ?
20:55:14 <jroll> mtreinish: heh, yeah, my question was "did I miss that during vacation" in disguise :)
20:55:15 <EmilienM> ttx: ocata-3 or rc1 if possible
20:55:18 <ttx> At least one month before PTG would be nice, so that people can plan to spend time in the Goal room
20:55:35 <EmilienM> ttx: it would gives us some window to prepare the communication and work in governance
20:55:43 <ttx> (each goal will have a room for people wanting to quick-hack on them)
20:55:57 <dhellmann> a month before ptg would be o-3, Jan 23-27
20:55:59 <EmilienM> ttx: eg: reach out teams so they can prepare their sessions at PTG if needed
20:56:00 <ttx> (on Monday-Tuesday)
20:56:20 <ttx> ok, let's target o-3
20:56:22 <mtreinish> jroll: I'll push something out later today to start a ml discussion on it
20:56:24 <EmilienM> ttx: +1
20:56:30 <ttx> that means refining the goals really quick
20:56:42 <ttx> and make sure people know they are coming
20:56:54 <dims> ++ ttx
20:56:58 <ttx> alright, this seems to be on the right track
20:57:00 <jroll> mtreinish: awesome
20:57:01 <EmilienM> ttx: I'll take actions on that, working closely with mtreinish and dhellmann
20:57:04 <ttx> EmilienM: thanks again for coordinating
20:57:12 <ttx> #topic Open discussion
20:57:18 <ttx> FYI Piet Kruithof reached out to me saying he is stepping down from UX team PTLship
20:57:24 <ttx> There is a question of whether that team should continue as a standalone team
20:57:31 <ttx> (or if UX efforts should rather be blended into every team)
20:57:40 <stevemar> for the future, can we have a set of goals for all projects to hit, not necessarily bound to a specific release/dev cycle?
20:58:11 <ttx> stevemar: we would probably call that something else to avoid confusion
20:58:14 <EmilienM> ttx: how would we formalize #2 ?
20:58:14 <stevemar> then we don't have to worry about 'setting them in stone' by a specific milestone
20:58:19 <ttx> I think the standalone UX team helped expose UX tools (personas, usability studies) to everyone
20:58:25 <thingee> I think a ux working group like we have api's etc would suffice
20:58:26 <ttx> But now that those tools are better-known, it's maybe time to encourage every team to use them directly
20:58:32 <thingee> don't think we need a team
20:58:42 <EmilienM> thingee: agree
20:58:43 <thingee> not even sure what their deliverables were
20:58:45 <dhellmann> does the existing ux team want to stay a team?
20:58:57 <dtroyer> what we lose without Piet's team is the expertise in executing the studies
20:58:58 <ttx> ok, I propose to start a thread and check if there is a PTL candidate, or if that effort no longer needs a teazm or centralization.
20:59:05 <thingee> ttx +1
20:59:13 <dhellmann> dtroyer : ++, it's harder than it looks
20:59:21 <mtreinish> ttx: sounds like a plan
20:59:22 <EmilienM> stevemar: how would you iterate?
20:59:25 <ttx> We'll see -- if nobody steps up the solution will find itself
20:59:26 <dtroyer> dhellmann: I've done two of them and it really is...
20:59:35 <ttx> #action ttx to start a UX thread
20:59:38 <thingee> dtroyer +1 I guess what I meant was repo based deliverables.
20:59:59 <fungi> we also have a pholio instance in production now, requested by the ux team
21:00:03 <dhellmann> thingee : they produced some ux reports that were distributed at the summit
21:00:03 <stevemar> EmilienM: add them to a backlog once approved and when they are ready to target move the goal from backlog to cycle
21:00:04 <ttx> dtroyer: agreed it's difficult to define personas or conduct studies without some centralization or guidance
21:00:14 <fungi> (as a replacement for their use of the proprietary "invision" saas)
21:00:16 <ttx> Alright we are out of time
21:00:25 <thingee> dhellmann that is true. I guess those could be in a repo to recreate the pdfs
21:00:31 <EmilienM> stevemar: I see, lgtm
21:00:36 <dhellmann> stevemar : I like the idea of having a pipeline of goal definitions ready to go
21:00:47 <thingee> better yet, put in a sphinx based doc on HIG, etc
21:00:49 <ttx> Thanks everyone! Don't despair, discussion is still progress :)
21:00:53 <dhellmann> thingee : I think that's also part of what pholio was for
21:00:54 <stevemar> i would like to add support for say, microversions, in keystone, if it's approved. and once the cycle hits we're done.
21:00:59 <ttx> #endmeeting