20:00:30 #startmeeting tc 20:00:31 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:33 o/ 20:00:35 The meeting name has been set to 'tc' 20:00:37 Happy new year everyone! 20:00:48 happy new year! 20:00:50 Our agenda for today is at: 20:00:55 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:01:07 (2017 new year resolution: use #info #idea and #link liberally to make for a more readable summary) 20:01:11 o/ 20:01:26 #topic Driver teams: establish new "driver team" concept, or not 20:01:36 Two weeks ago we discussed this and boiled it down to two options 20:01:45 Consider driver teams as being a piece of "OpenStack" (using the grey option as implementation): 20:01:48 #link https://review.openstack.org/403829 20:01:57 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 #link https://review.openstack.org/403836 20:02:09 o/ 20:02:12 mtreinish in particular was still not comfortable living by the grey option, and several TC members still preferred soft black. 20:02:24 Taking a step back, for me the choice all depends on whether driver teams are looking for *recognition* or *discoverability*. 20:02:40 what would our users find useful here? 20:02:40 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 without having to permanently change governance or compromise on open collaboration requirements for "OpenStack" proper 20:02:59 right, I'm not that concerned with discoverability as a goal for this 20:03:02 so choosing "soft black" + getting our act together on driverlog/docs/marketplace is a valid answer 20:03:12 (and thingee volunteered to work on that, to give those teams what they need fast enough) 20:03:22 But if they are /also/ looking for recognition, then grey is probably the most reasonable way to give it to them 20:03:29 So... Do we have a clear view on what those teams are really after ? 20:03:31 ttx: heh, that's a much more eloquent way to put what I was getting at during that last meeting :) 20:03:44 johnthetubaguy: in both cases they get discoverability 20:03:46 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 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 dhellmann: +1, that's what marketing/sales departments are for. 20:03:47 mtreinish: ttx does that 20:03:57 stevemar: that is called preparation 20:04:03 :) 20:04:31 so approving this is not necessary of what was originally being asked 20:05:10 thingee: for the original case, maybe. But we are considering a class of projects here... 20:05:17 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 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 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 dhellmann: from your interactions with that crowd, what would you say the need/want ? 20:05:27 they* 20:05:46 dtroyer exactly what dims asked, does anybody else want this, and give a good reason why 20:05:58 fungi: ++ 20:06:13 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 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 I think if we fix some legacy things that disallow out of trees to be discovered, this is not necessary 20:06:37 s/old/hold/ 20:06:58 thingee : discoverability and encouraging participation are orthogonal 20:07:13 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 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 dhellmann can you explain how you see this encouraging participation? 20:07:49 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 jroll: FWIW, I do not think it is _really_ possible, having tried that in more than one $DAY_JOB 20:08:04 jroll: I think it's hard. May involve sending free test rigs to everyone interested. 20:08:05 you can't not allow out of tree drivers -- it's open source 20:08:05 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 dhellmann who is saying we're not interested? 20:08:31 thingee : if we tell teams working on drivers that their contributions aren't allowed to be official, we are. 20:08:49 again official and discoverability. 20:08:50 I think the level playing field statement is a quagmire of vagueness when it comes to drivers. 20:08:56 fungi: good example 20:09:06 dhellmann: arguably we are saying they are not "OpenStack", but something that can be used with "OpenStack" 20:09:07 you are official if we make it easy to discover your driver compatible with openstack 20:09:15 ttx +1 20:09:36 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 dhellmann: I get your point though. We need drivers for openstack to be successful so why not consider them in 20:10:04 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 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 not all of them will choose to go through the trouble to become official, for various reasons 20:10:38 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 johnthetubaguy : I agree, we should encourage open development of drivers. 20:10:54 I'm on the fence, mostly because once official driver teams are created it will be hard to go back 20:11:21 I think we should fix the larger problem first. If that doesn't fix things, we should revisit doug's proposal 20:11:35 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 ttx: ++ and why it is clear to me we are not ready to go this route quite yet (if at all) 20:11:36 thingee: and you think the larger issue is documentation discovery? 20:11:51 sdague: and proper marketplace listings 20:11:56 dhellmann we already do. cinder drivers which are in tree and are allowed to contribute their drivers in 20:12:13 sdague that is one example and the one given to me by sambetts|afk himself with cisco 20:12:14 thingee: being in cinder's tree is definitely some relationship 20:12:23 or we could make it so only openly accessible teams are listed? 20:12:25 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 jroll right, again larger problem is with out of tree drivers here 20:12:50 thingee : if all of the drivers were in tree, we wouldn't even be having this conversation 20:12:52 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 this would open it to *anything* in the openstack git namespace, which is open to any code 20:13:08 "it" being docs.o.o 20:13:20 dhellmann and again, I say revisit whether we should allow out of tree 20:13:29 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 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 this is just a bandaid fix imo 20:13:34 thingee: so you're after the red option? 20:13:53 * thingee checks color code cliff notes 20:14:06 thingee : that's the one where the TC requires project teams to take in all drivers 20:14:19 thingee : we rejected that as too harsh 20:14:28 this isn't a question of the motivation of the driver authors for being in tree 20:14:32 dhellmann: I think he is after one of the black options. Drivers can be made out of openstack 20:14:34 they've been kicked out by their host project 20:14:48 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 ttx: under that approach we can solve the discoverability problem, but not the community membership problem 20:15:18 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 thingee : I'm not sure we're on the same page at all. 20:15:55 not all "drivers" are the same thing at this point either 20:16:01 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 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 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 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 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 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 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 thingee : that doesn't solve *my* problem, though 20:17:14 dhellmann: well, the alternative was to relax rules for everyone... 20:17:21 fungi: the project teams can and do review it, as do the docs team 20:17:44 bswartz: even for repos maintained by unofficial teams? 20:17:48 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 ttx: true. 20:18:39 back to whether driver teams want recognition as a part of openstack or really don't care that much 20:18:55 fungi: talking about cinder/manila config guides 20:19:17 dhellmann : right, so i was asking if anyone is really is feeling left out 20:19:22 dhellmann: was there anything explicit, or do you consider them applying as sufficient proof ? 20:19:24 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 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 dims : do we wait for someone to have that problem and not report it before we do something? 20:19:35 dhellmann ^ 20:19:43 dhellmann : good point 20:19:55 fungi: manila has all the drivers in tree -- I don't want them anywhere else 20:20:21 out of tree drivers are an abomination IMO 20:20:40 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 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 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 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 ttx: correct -- they should contribute directly to manila or stay on github 20:21:20 dhellmann: supposing that's a carrot to them 20:21:25 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 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 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 do we have neutron community folks around? Because this really impacts neutron first. 20:21:57 The carrot is you're compatible with OpenStack because you follow the individual project team's guidelines of what is official 20:21:58 ttx: yes, well, interpretation is up to the observer. 20:22:12 sdague: yes, wondering if we should not survey driver teams and see how much they care with the two solutions 20:22:24 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 s/with/about/ 20:22:32 sdague: yeah, although do we think any other project will follow the neutron model? 20:22:35 fungi: idk, I don't have a problem with that, personally. some docs are better than none 20:22:37 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 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 because it seems kinda unlikely to me that any of the other projects will 20:23:01 mtreinish: neutron seems to be unique partially because of its histroy as a heavily vendor-driven project from the start 20:23:10 dtroyer: right 20:23:18 jroll: would ironic end up in this model as well? 20:23:20 mtreinish: I agree 20:23:22 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 ironic has out of tree drivers as we require CI 20:23:30 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 bswartz: thx 20:23:36 sdague: not pushing 100% out, but forcing some to stay out, yes 20:23:45 OK, so that we know where we stand today... I propose a quick indicative vote for TC members 20:23:47 or, so ironic and neutron are going to be primary consumers 20:24:02 and I feel like we haven't really had a ton of neutron feedback here 20:24:07 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 fungi: yeah, I suppose. I guess I lean toward 'why not' on the docs point, rather than 'why' :) 20:24:44 #startvote Where do you stand? allow-driver-teams, just-improve-discovery, on-the-fence 20:24:45 Begin voting on: Where do you stand? Valid vote options are allow-driver-teams, just-improve-discovery, on-the-fence. 20:24:46 Vote using '#vote OPTION'. Only your last vote counts. 20:24:54 #vote on-the-fence 20:24:56 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 #vote just-improve-discovery 20:25:02 #vote allow-driver-teams 20:25:07 #vote just-improve-discovery 20:25:12 #vote on-the-fence 20:25:16 #vote allow-driver-teams 20:25:18 #vote allow-driver-teams 20:25:23 dhellmann contributors being paid by a company don't need to incentive from the community to contribute driver code. 20:25:25 #vote on-the-fence 20:25:31 vote one-the-fence 20:25:39 johnthetubaguy: you need a # 20:25:40 johnthetubaguy: add # 20:25:40 thingee : the company needs an incentive to allow them to do anything other than that, though 20:25:41 #vote just-improve-discovery 20:25:48 #vote on-the-fence 20:25:59 dhellmann can you give me examples of where that's a problem today though? 20:26:17 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 sdague: ttx: sorry one handed badness 20:26:21 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 because we seem to be assuming a lot (one way or another) 20:26:40 thingee : I don't think we need to wait for a problem to exist before we try to address it. 20:26:41 #vote on-the-fence 20:26:44 thingee: rather than requiring cinder and neutron to agree on what makes a driver supported 20:26:52 ending vote in 20 sec 20:27:10 #endvote 20:27:11 Voted on "Where do you stand?" Results are 20:27:12 on-the-fence (5): dims, ttx, stevemar, sdague, johnthetubaguy 20:27:13 allow-driver-teams (3): EmilienM, dhellmann, dtroyer 20:27:15 just-improve-discovery (3): thingee, mtreinish, fungi 20:27:19 Pretty split 20:27:25 dhellmann I find that too bad that the TC wants to open this gate when there is no problem. 20:27:44 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 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 fungi: I like that starting point idea, the projects know best 20:28:00 johnthetubaguy +1 20:28:03 fungi : true 20:28:04 As an on-the-fence I propose to reach out to driver teams and try to get their feeling 20:28:13 stevemar: would you mid helping me in there ? 20:28:18 mind* 20:28:21 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 ttx: sure 20:28:38 Does anyone have a sense of what might change for the nova/cinder/manila teams if driver teams were introduced? 20:28:47 ttx: stevemar: I can hook you up with some folks maintaining out of tree ironic drivers, if that's helpful 20:28:48 dims, stevemar, sdague, johnthetubaguy: anything else we should do this week to help you make a call ? 20:28:52 ie, unintended consequences? 20:29:23 dtroyer: My only concern with all of this is having less incentive to contribute to core code. 20:29:32 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 dtroyer: not really, but yes introducing driver-teams is a more significant move than just sitting and fixing discoverability 20:29:42 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 ttx: I would be tempted to approve driver teams, but I am attracted by the option of discoverability controlled by projects 20:29:59 smcginnis: you feel that you might see companies going in the opposite driection of what we are trying to achieve? 20:30:05 smcginnis : I wouldn't expect a lot of impact on that to teams that welcome drivers into the parent projects. 20:30:12 smcginnis I think this proposal in recognizing individual contributors in their vendor's team deliverables will not help with core contributions 20:30:44 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 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 recognizing openstack contributors have to come from the projects themselves, not vendor python libraries, etc 20:31:02 I guess I feel more worried about encouraging open collaboration on the vendor drivers 20:31:03 ++ sdague 20:31:04 sdague: ok, so making sure we cover neutron in our analysis 20:31:10 ttx yes I will be happy to continue working this out with dhellmann 20:31:18 I propose we move on 20:31:22 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 yes, let's move on 20:31:58 sdague: good point, the proposal currently excludes many neutron drivers due the the API clause 20:32:00 #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 #topic Disallow downtime of controlled resources during upgrades 20:32:14 #link https://review.openstack.org/404361 20:32:18 o/ 20:32:22 dolphm: o/ 20:32:29 * ttx checks for refresh 20:32:49 since the last time this was on the agenda, i've incorporated some feedback into the latest review... 20:33:05 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 lgtm 20:33:36 dhellmann: does the new wording fix your concerns ? 20:33:38 the new wording addresses my only nit, thanks dolphm 20:33:44 dhellmann: thanks for the feedback 20:34:14 dolphm: ok, so basically if we do this the net is 20:34:30 dolphm: lgtm, but i was OK with previous revs too 20:34:39 nova, cinder get accessible upgrades, neutron / glance do not? 20:34:50 just to get this chunking in my head 20:35:09 just checking a phrase here: "continuously validated" 20:35:19 sdague: glance doesn't? 20:35:25 no one would get it out of the gate, unless someone is already asserting the availability of resourcing during an upgrade? 20:35:32 johnthetubaguy: that's a slight change since the last revision as well 20:35:45 EmilienM: you can't get to the images during an upgrade 20:35:46 EmilienM: when the glance services are offline, there is no access to their resources 20:35:59 because their resources are only http accessable 20:36:02 indeed 20:36:23 dolphm: ok, but conceptually, the services that can do this 20:36:38 neutron can't because of ovs link resets and the like 20:37:18 sdague : is that a fundamental problem with neutron, or could it be fixed? 20:37:23 are ovs link resets "abnormal", though ? 20:37:24 I thought the neutron thing changed in the last releases, I remember some parameters in Neutron to disable this thing 20:37:36 dhellmann: it's a fundamental problem with some backends 20:37:42 including the leading ones 20:37:47 ok 20:38:25 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 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 its generally where projects sit in the dataplane, they have lots to do 20:38:34 like, things ops would care about, not 0 downtime ever 20:38:40 if that makes sense 20:38:41 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 jroll : ++ 20:38:45 jroll: that feels like yet another tag, but thats a fair point 20:38:55 but maybe i'm getting too deep into imagining the implementation? 20:39:12 fungi: "continuously" is the bit worrying me 20:39:12 jroll: yes, and that definition may vary 20:39:14 johnthetubaguy: if it's another tag, I guess I'm asserting this one isn't terribly useful 20:39:48 jroll: this one would be one Nova could assert (if you turn off consoles, I guess...) 20:39:52 johnthetubaguy: for something like glance, if an op wants zero downtime, a load balancer (and coordination) should be a requirement 20:40:11 sdague: I think the neutron thing was fixed by https://review.openstack.org/#/c/182920/ 20:40:15 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 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 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 dhellmann: ++ 20:40:26 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 s/drops/drops any packets/ 20:40:32 johnthetubaguy: indeed 20:40:43 mtreinish: that only proves it was up at the times those icmp echo requests arrived 20:40:46 mtreinish : ssh session instead? :) 20:40:47 sdague: would glance pass this with rolling updates (like you can always find an API server that works) ? 20:41:00 mtreinish: but proves nothing about the (micro?)seconds between each ping 20:41:14 dims: yeah, ssh would be a better test :) 20:41:18 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 fungi: fair point 20:41:22 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 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 dhellmann: ++ 20:42:15 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 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 sdague: I think you reminded me I need to understand those neutron problems better 20:42:41 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 OK, I'm starting to wonder what user question this answers 20:42:50 sdague : is the problem in the driver, or in the thing the driver talks to? 20:43:19 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 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 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 so, EmilienM may be right that - https://review.openstack.org/#/c/182920/ fixed it 20:43:35 basically WHY are we introducing this if it's not to drive behavior nor to answer a user question 20:43:37 yay, ok 20:43:41 EmilienM: if the OVS backend flow rebuild is handled, that's fine 20:43:43 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 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 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 but that can't survice an OVS upgrade itself 20:44:08 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 jroll: sure, I don't disagree, it's just new territory 20:44:13 as one of the first people to ever deploy ironic in production... I would have loved to have that 20:44:15 nod 20:44:33 russellb: any thoughts on ^^^^ ? 20:44:58 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 johnthetubaguy: are you focusing on the word "continuously", or something else? 20:45:03 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 sdague: +10000000 20:45:19 dolphm: yeah, I am fixed on that word for reasons I don't understand 20:45:21 dolphm: feels a lot like "are those services working as the industry considers they should" 20:45:27 sdague: jroll: +1 20:46:06 I thought the basic question being answered was to Operators 20:46:07 I think of these as answers to ops questions, "how often (and how painful) is it reasonable to upgrade things" 20:46:15 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 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 OK, feels like we'll need another round here 20:46:47 * johnthetubaguy face palm 20:47:02 ignore that, thats more outage than ovs replace 20:47:08 dhellmann, sdague: please make sure to file your remarks/concerns on the review 20:47:17 jroll: right, and if I upgrade service X do I need to plan for customers seeing an outage 20:47:23 we did some ovs upgrades, but you get packet loss 20:47:42 sdague: yep, meaning service X is going to get real old real fast :) 20:48:06 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 feels like we'll have a hard time defining this as a tag, could be suggestions for improvements / goal instead 20:48:26 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 s/thinbs/things/ 20:48:42 dolphm: not solving ops pain points, answering ops questions 20:48:52 jroll: ah, i follow then 20:48:52 because defining "reasonable" and "normal" behavior will be hard overall 20:48:54 I like sdague's suggestion of upgrade focused goals 20:48:59 ideally users never notice an upgrade :) 20:49:00 anyway, i suggest we move on 20:49:10 and continue to discuss on the review 20:49:14 jroll: +1, tricky to define 20:49:26 since this is not ready 20:50:07 #topic Pike goals 20:50:14 Not much time to discuss this 20:50:16 o/ 20:50:18 EmilienM: looks like we have two goals proposed so far ? 20:50:26 anything else promising in the backlog ? 20:50:30 #link https://etherpad.openstack.org/p/community-goals 20:50:31 yes, python-3 and tempest plugin AFIK 20:50:36 * Add Pike goal split out tempest plugins (https://review.openstack.org/369749) 20:50:39 * add goal "support python 3.5" (https://review.openstack.org/349069) 20:50:59 we had one goal for Ocata, having 2 goals for Pike would probably make sense 20:51:01 I saw some useful input from the product working group on the etherpad earlier today 20:51:08 ah, missed it 20:51:27 How are the proposed two doing in terms of community acceptance ? 20:51:29 there were comments about their interest in some of the existing things, and one new one at the bottom 20:52:14 ttx: for the python 3.5 goal, I haven't seen any pushback - https://review.openstack.org/#/c/349069/ (and ML) 20:52:32 those seem like reasonably scoped things, and have champions, so seems solid 20:52:33 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 the only issue reported there was some concern about which python 3.5, since there's a bug swift needs fixed 20:52:39 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 yes, I think we can move forward with py 3.5 20:52:41 ttx: for the tempest plugin goal - https://review.openstack.org/369749 - there are still some discussions in the proposal 20:52:54 sdague: ++ indeed 20:53:03 has the tempest plugin goal been talked about on the ML? it has had some opposition in the patch 20:53:37 dhellmann: I guess that could be grounds for an exemption until 3.6 is done (or the bug is fixed) ? 20:53:38 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 jroll: I haven't seen a thread, but I'm a few hours out of date 20:53:53 i like the advantages outlined in the tempest plugin patch 20:53:57 dhellmann: I'd expect a thread more than a few hours old by now :P 20:54:06 done -> widely available 20:54:07 ttx : there are other things that need to be fixed in swift well before that referenced bug is of concern 20:54:09 IMHO 20:54:20 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 dims: right, so they could be working on that 20:54:41 dims : excellent, and thank you for picking that up 20:54:47 jroll: oops, i forgot to start a thread before the holidays when you asked me before 20:55:02 EmilienM: when do you want to have the goals set in stone ? 20:55:14 mtreinish: heh, yeah, my question was "did I miss that during vacation" in disguise :) 20:55:15 ttx: ocata-3 or rc1 if possible 20:55:18 At least one month before PTG would be nice, so that people can plan to spend time in the Goal room 20:55:35 ttx: it would gives us some window to prepare the communication and work in governance 20:55:43 (each goal will have a room for people wanting to quick-hack on them) 20:55:57 a month before ptg would be o-3, Jan 23-27 20:55:59 ttx: eg: reach out teams so they can prepare their sessions at PTG if needed 20:56:00 (on Monday-Tuesday) 20:56:20 ok, let's target o-3 20:56:22 jroll: I'll push something out later today to start a ml discussion on it 20:56:24 ttx: +1 20:56:30 that means refining the goals really quick 20:56:42 and make sure people know they are coming 20:56:54 ++ ttx 20:56:58 alright, this seems to be on the right track 20:57:00 mtreinish: awesome 20:57:01 ttx: I'll take actions on that, working closely with mtreinish and dhellmann 20:57:04 EmilienM: thanks again for coordinating 20:57:12 #topic Open discussion 20:57:18 FYI Piet Kruithof reached out to me saying he is stepping down from UX team PTLship 20:57:24 There is a question of whether that team should continue as a standalone team 20:57:31 (or if UX efforts should rather be blended into every team) 20:57:40 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 stevemar: we would probably call that something else to avoid confusion 20:58:14 ttx: how would we formalize #2 ? 20:58:14 then we don't have to worry about 'setting them in stone' by a specific milestone 20:58:19 I think the standalone UX team helped expose UX tools (personas, usability studies) to everyone 20:58:25 I think a ux working group like we have api's etc would suffice 20:58:26 But now that those tools are better-known, it's maybe time to encourage every team to use them directly 20:58:32 don't think we need a team 20:58:42 thingee: agree 20:58:43 not even sure what their deliverables were 20:58:45 does the existing ux team want to stay a team? 20:58:57 what we lose without Piet's team is the expertise in executing the studies 20:58:58 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 ttx +1 20:59:13 dtroyer : ++, it's harder than it looks 20:59:21 ttx: sounds like a plan 20:59:22 stevemar: how would you iterate? 20:59:25 We'll see -- if nobody steps up the solution will find itself 20:59:26 dhellmann: I've done two of them and it really is... 20:59:35 #action ttx to start a UX thread 20:59:38 dtroyer +1 I guess what I meant was repo based deliverables. 20:59:59 we also have a pholio instance in production now, requested by the ux team 21:00:03 thingee : they produced some ux reports that were distributed at the summit 21:00:03 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 dtroyer: agreed it's difficult to define personas or conduct studies without some centralization or guidance 21:00:14 (as a replacement for their use of the proprietary "invision" saas) 21:00:16 Alright we are out of time 21:00:25 dhellmann that is true. I guess those could be in a repo to recreate the pdfs 21:00:31 stevemar: I see, lgtm 21:00:36 stevemar : I like the idea of having a pipeline of goal definitions ready to go 21:00:47 better yet, put in a sphinx based doc on HIG, etc 21:00:49 Thanks everyone! Don't despair, discussion is still progress :) 21:00:53 thingee : I think that's also part of what pholio was for 21:00:54 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 #endmeeting