| *** diablo_rojo has quit IRC | 00:45 | |
| *** ricolin has joined #openstack-tc | 00:50 | |
| *** lbragstad has quit IRC | 01:42 | |
| *** lbragstad has joined #openstack-tc | 01:51 | |
| *** whoami-rajat has joined #openstack-tc | 02:06 | |
| *** dklyle has joined #openstack-tc | 02:14 | |
| *** dhellmann has quit IRC | 02:23 | |
| *** dhellmann has joined #openstack-tc | 02:23 | |
| *** lbragstad has quit IRC | 02:40 | |
| *** lbragstad has joined #openstack-tc | 02:43 | |
| *** lbragstad has quit IRC | 04:59 | |
| *** Luzi has joined #openstack-tc | 05:40 | |
| *** e0ne has joined #openstack-tc | 05:53 | |
| *** sarob has joined #openstack-tc | 06:09 | |
| *** sarob has quit IRC | 06:19 | |
| *** e0ne has quit IRC | 06:36 | |
| *** openstackgerrit has quit IRC | 07:03 | |
| *** jaosorior has quit IRC | 07:06 | |
| *** tosky has joined #openstack-tc | 07:48 | |
| *** e0ne has joined #openstack-tc | 08:08 | |
| *** dtantsur|afk is now known as dtantsur | 08:50 | |
| *** tosky has quit IRC | 10:10 | |
| *** tosky has joined #openstack-tc | 10:11 | |
| *** jaosorior has joined #openstack-tc | 10:12 | |
| *** zhipeng has joined #openstack-tc | 10:22 | |
| *** ricolin has quit IRC | 10:39 | |
| asettle | AFternoooon o/ | 11:00 |
|---|---|---|
| jroll | \o | 11:28 |
| *** dtantsur is now known as dtantsur|brb | 11:46 | |
| *** lbragstad has joined #openstack-tc | 13:09 | |
| *** mriedem has joined #openstack-tc | 13:15 | |
| smcginnis | Mooooorning o/ :) | 13:16 |
| *** dtantsur|brb is now known as dtantsur | 13:18 | |
| *** ianychoi has joined #openstack-tc | 13:26 | |
| *** Luzi has quit IRC | 13:45 | |
| *** openstackgerrit has joined #openstack-tc | 14:43 | |
| openstackgerrit | Sean McGinnis proposed openstack/governance master: Nest tag project output to make sorting look sane https://review.opendev.org/659310 | 14:43 |
| ttx | ohai | 15:01 |
| fungi | looks like it's office hour time | 15:01 |
| zaneb | o/ | 15:01 |
| ttx | I'd like to raise 3 reviews that look stuck | 15:02 |
| ttx | or missing some input from y'all | 15:03 |
| ttx | https://review.opendev.org/#/c/655484/ | 15:03 |
| ttx | (the winstackers / compute-hyperv one) | 15:03 |
| ttx | i.e. how much do we want two hyperv drivers "in" OpenStack | 15:04 |
| ttx | any opinion on that? | 15:05 |
| zaneb | it's worse than that; nobody wants two drivers but the one we do want isn't the one in OpenStack | 15:05 |
| ttx | heh yes | 15:06 |
| ttx | I guess one question would be to remove/deprecate the mainline one | 15:06 |
| ttx | s/question/solution | 15:06 |
| ttx | if nobody can recommend it being used | 15:07 |
| ttx | basically 3 ways out - A/ have both in OpenStack (approve this review), B/ have only the mainline one in OpenStack (reject that review), C/ have only the winstackers one in openstack (approve review + deprecate the mainline one) | 15:08 |
| smcginnis | Great detailed response from lpetrut on there. | 15:09 |
| smcginnis | Bad yeah, bad situation. | 15:09 |
| ttx | Yes, I feel like they are doing the best they can to get people to use the "working" driver | 15:09 |
| fungi | the project reform did allow for competing scope between projects as long as it was not gratuitous duplication of effort | 15:10 |
| ttx | It's not competition, it's a process artifact | 15:10 |
| ttx | that creates user confusion | 15:10 |
| clarkb | nova wanting drivers in tree being the process artifact? | 15:10 |
| ttx | clarkb: no, the fact that the driver in tree is not as advanced as the one out, because it takes time to merge things | 15:11 |
| ttx | Maybe we could have both and call one experimental and the other stable | 15:11 |
| zaneb | tbh I don't understand why the nova teams takes such a... legalistic approach to things such as this and powervm. people are using this thing and as far as they're concerned it's OpenStack. Nova say they can't be associated with it unless they've reviewed every line of code. well... you're already associated with it so why be difficult? | 15:12 |
| ttx | I guess that is the key question -- which one is actually used | 15:12 |
| ttx | And if the people working on it and supporting the users using it are saying they'd rather support people using the experimental one... I'm not sure there is value in the in-tree one | 15:13 |
| ttx | I understand Nova's position that they need to vouch for the in-tree driver design / feature / patches | 15:14 |
| zaneb | right, but nobody's suggesting that the experimental driver move in-tree | 15:14 |
| ttx | But if that process ends up producing somethign that nobody uses because everyone is using the experimental out-tree driver... | 15:14 |
| ttx | zaneb: that would be D/ but I don't think that is a good idea unless Nova is comfortable with it | 15:15 |
| zaneb | I think I'm recalling more the discussion around powervm, but this is essentially the same | 15:16 |
| zaneb | from a TC perspective I think we should probably just approve this review and leave the teams to figure out what they want to do about the duplication | 15:16 |
| ttx | At this point I'd rather push for C/ than for D/. And if that's not possible, I'm torn between A and B | 15:17 |
| ttx | zaneb: yes, so A with an eye toward potential C or D? | 15:17 |
| zaneb | A with an eye toward C | 15:18 |
| ttx | The problem with A being it perpetuates the user confusion as to what they should be using | 15:18 |
| zaneb | or not if the teams so decide | 15:18 |
| dhellmann | it sounds like C is going to put the winstackers team in a position where changes in nova might break hyperv support, though | 15:19 |
| dhellmann | maybe we can deal with that through gating | 15:19 |
| zaneb | aren't they already in that situation | 15:19 |
| zaneb | ? | 15:19 |
| dhellmann | apparently with the minimal in-tree driver, they're able to keep that to a minimum? I'm going based on comments on the review | 15:19 |
| zaneb | right, but nobody is advised to use that | 15:21 |
| dhellmann | my position on this has always been that 1 project team does not get to decide if another project team should exist. That's the TC's role. So I think approving this team and encouraging the two groups to sort out the confusion/testing issues is probably the right path forward | 15:21 |
| dhellmann | "We had to keep the upstream driver as well so that Nova would continue to officially support Windows/Hyper-V, otherwise anyone could introduce breaking changes" | 15:21 |
| dhellmann | that's the comment I was referring to | 15:21 |
| clarkb | re gating we can't do functional testing of hyperv (but if they faked hyperv could probably test large bits of the driver) | 15:22 |
| dhellmann | I assume we would replicate whatever they're doing with that in-tree driver just using the 2nd repo | 15:23 |
| dhellmann | if there's no testing, then it's just false hope that nothing is going to end up broken anyway | 15:23 |
| smcginnis | Isn't that usually addressed by third party CI? I thought we had that for others. (VMware?) | 15:23 |
| ttx | so the hyperv's in tree driver only use is to ensure taht base functions won't get broken | 15:23 |
| clarkb | yes Ithink third part ci usually fills those gaps (this isn't gating though) | 15:23 |
| ttx | it serves as an undocumented API | 15:24 |
| smcginnis | They can be though. | 15:24 |
| dhellmann | right, this is unit-test level checks for API breaking changes | 15:24 |
| dhellmann | we don't need third-party CI to do that | 15:24 |
| ttx | I guess that is what I meant by "process artifact" | 15:24 |
| ttx | It serves as an intermediary by-product that should probably not be used by users | 15:25 |
| ttx | and yet it is what users see by default | 15:25 |
| fungi | this nova/hyperv discussion reminds me of situations like the qlogic storage drivers in the mainline linux kernel, where production deployments almost always just rebuilt the vendor's out-of-tree version and loaded that instead | 15:25 |
| clarkb | smcginnis: third party ci cannot gate in our system | 15:25 |
| clarkb | (this is intentional) | 15:26 |
| smcginnis | clarkb: We no longer allow voting? | 15:26 |
| clarkb | smcginnis: we allow voting, but only the votes from the zuul user control mergeability | 15:26 |
| smcginnis | Ah | 15:26 |
| fungi | we allow voting, we don't allow external ci systems to decide what will merge | 15:26 |
| fungi | or block things from merging | 15:26 |
| *** sarob has joined #openstack-tc | 15:27 | |
| dhellmann | another path forward is to have a declared stable driver interface, but I know some teams are reluctant to do that | 15:27 |
| dhellmann | that would allow the in-tree driver to be removed safely, and would at least remove the confusion caused by duplicate drivers | 15:28 |
| smcginnis | There are times when the interface does not change, but something else still is able to break functionality. | 15:28 |
| ttx | a stable API is one thing. Getting warned about changes in an unstable API is another. | 15:29 |
| ttx | Maybe the latter is enough in that case | 15:29 |
| dhellmann | sure | 15:29 |
| dhellmann | it would be good to get the nova team's perspective on this, too. I don't know how recently they were involved in this discussion. | 15:30 |
| ttx | I think the resistance to stable API was mostly around the ability to change it as necessary | 15:30 |
| dhellmann | it sounds like "supporting" out of tree drivers is a bit easier than it used to be | 15:30 |
| ttx | yes -- the question being, do we start the discussion before or after approving that review :) | 15:30 |
| ttx | The other review I wanted to raise as undecided is https://review.opendev.org/#/c/657142/ -- the Docs SIG one | 15:31 |
| zaneb | ideally all of the drivers would be out of tree and the API would be stable. but that's not something we can make happen | 15:31 |
| zaneb | what we can do is eliminate at least one piece of bureaucratic BS that contradicts the facts on the ground | 15:32 |
| ttx | that one also could use a variety of views, sinc I'm very much on the fence | 15:32 |
| zaneb | dhellmann: what is it about a team vs. a SIG that makes it "someone clearly signed up" vs "leaving it to chance"? | 15:36 |
| zaneb | (last comment on the docs review) | 15:36 |
| smcginnis | Isn't the issue that SIG membership is very light weight and easy to come and go? At least with a team, there's a PTL that's ultimately somewhat responsible. | 15:37 |
| smcginnis | Though I could see an argument that a SIG chair would be roughly the same. | 15:37 |
| smcginnis | But that also makes me wonder why change it if things are basically the same. | 15:37 |
| zaneb | with a project it's more obvious when everybody has gone I guess, because of the PTL election | 15:37 |
| zaneb | just not sure that solves anything | 15:38 |
| jroll | FWIW, nova's virt API is stable in practice, there's just no guarantees | 15:38 |
| *** e0ne has quit IRC | 15:38 | |
| ttx | Yes tbh I'm not sure where the idea came from, and teh commit message does not go at length to motivate the change | 15:38 |
| jroll | I've personally had to do extra work to make sure we don't break out of tree drivers | 15:38 |
| *** ricolin has joined #openstack-tc | 15:38 | |
| ttx | (talking about Docs SIG) | 15:38 |
| jroll | honestly, this out of tree driver just feels like a way to work around review bandwidth, which isn't good but is understandable | 15:39 |
| zaneb | now that most of the docs are in project repos, most contributions to docs are not actually to the docs project. I assume that's what's motivating it? | 15:39 |
| ttx | jroll: also allows questionable shortcuts | 15:40 |
| jroll | ttx: that's part of my "isn't good" statement :) | 15:40 |
| smcginnis | Would be good to get some input from asettle when it's her work hours. | 15:41 |
| zaneb | jroll: the fact that it's actual stable in practice is what makes it extra-weird | 15:48 |
| ttx | The third I had was the caching service, but I think a more visible ML thread is the real next step there | 15:48 |
| ttx | I feel like it's very important to not rush base service additions and take the pulse of the ops community on proposed additions | 15:49 |
| ttx | even if in that specific case it should definitely make sense | 15:49 |
| jroll | zaneb: Lucian's comments on the patch somewhat reflect this as well - I think this out of tree driver came before the relative stability of the driver interface | 15:50 |
| clarkb | ttx: (as someone not on the TC) it felt like the etcd base service move was premature too because very little actually uses it (and it took a long time to get there) seems like a better approach is to make something work well then decide to use it more globally rather than deciding globally then hoping it works well or that anyone will even use it | 15:51 |
| ttx | yes... it's always a bit of a chicken-egg problem | 15:52 |
| cmurphy | tbh i'm torn on whether to keep pushing caching as a base service, i think it may not really need to be an openstack-wide commitment and the keystone team can probably just make the call that the keystone project alone depends on caching | 15:52 |
| ttx | The hope is that the news trigger a virtuous cycle but in that case it did not work that well | 15:52 |
| fungi | i still intend to propose barbican to base services, castellan was a good first step though | 15:52 |
| ttx | cmurphy: how is it most commonly deployed ? With local memcached on keystone nodes ? | 15:53 |
| cmurphy | ttx: usually sharded memcached across keystone nodes | 15:54 |
| zaneb | the good news is that nobody is going to choose not to use keystone in their deployment because it requires memcached | 15:54 |
| ttx | I feel like caching is generally sufficiently sharded that I'm not sure I'd call it a "service" like MySQL or Rabbit | 15:54 |
| ttx | Maybe adding it as a dependency would be enough | 15:55 |
| zaneb | ttx: other services can make use of the same memcached though | 15:55 |
| zaneb | also there's nothing to stop you from running a separate DB for each service | 15:55 |
| zaneb | I don't feel like this is a qualitatively different case | 15:56 |
| ttx | fair | 15:56 |
| mugsie | I don't see the issue really - we added etcd3 before any services actually used it, and from what I can figure out, none of them require it yet | 15:59 |
| clarkb | mugsie: the issue is groups like infra and qa invested a ton off effort for getting it in place and its basically doa | 16:01 |
| mugsie | clarkb: oh, i know - we already have this in place for keystone thought - all of the keystone gates already use it | 16:02 |
| ttx | yeah, if we add a base service and nobody requires it yet, maybe we should remove it | 16:02 |
| ttx | because the goal was to be able to actually depend on it being present | 16:02 |
| clarkb | mugsie: ah I see so this caching case is more like what I describe in proving it first (I got the other impression from ttx's comments earlier) | 16:02 |
| ttx | at least in the caching case we have one project signed up to hard-depend on it | 16:03 |
| smcginnis | Etcd is used in some Cinder tests for distributed locking. | 16:05 |
| *** dims has quit IRC | 16:05 | |
| *** sarob has quit IRC | 16:16 | |
| *** dtantsur is now known as dtantsur|afk | 16:19 | |
| *** sarob has joined #openstack-tc | 16:26 | |
| *** sarob has quit IRC | 16:32 | |
| *** ricolin has quit IRC | 16:44 | |
| dhellmann | my impression of the docs transition is that there's basically no one left contributing to the current team, and operators who might contribute to docs do not want to do it as part of a "team" because they perceive it as burdensome to follow the team processes. so, this is mostly a recognition of the fact that the team largely dissolved over the last year but the tools are still being maintained | 16:49 |
| dhellmann | zaneb : "clearly signed up" in the sense that there is someone who has committed to do it as part of the structure we have for managing producing "openstack", which SIGs aren't automatically doing. so if we're OK with the web site potentially not reflecting the current release status correctly, then we can leave it alone. but if we are not ok with that, we need someone to say they will do it every cycle. | 16:52 |
| dhellmann | I don't care what that group is called, but my impression is that SIGs have a more "when we get around to it" nature than I'm comfortable with for that task. | 16:53 |
| *** bauzas has quit IRC | 16:54 | |
| zaneb | teams also have a tendency to evaporate (as you point out, the docs team already mostly did) | 16:54 |
| clarkb | does making it a sig unevaporate people? | 16:54 |
| zaneb | "operators who might contribute to docs do not want to do it as part of a "team" because they perceive it as burdensome to follow the team processes" | 16:56 |
| zaneb | (I have no idea if that is actually true) | 16:56 |
| *** bauzas has joined #openstack-tc | 16:57 | |
| mugsie | I would worry that without the team processes we would have a lot of random wiki pages in varing states of decay - which is what happened with the ops guide | 16:58 |
| mugsie | and I am not sure a sig is going to remove the need to use gerrit | 16:59 |
| fungi | in fact the ops guide editors tried relocating the content to a wiki and ultimately decided they'd rather stuff it back into gerrit | 17:01 |
| *** dims has joined #openstack-tc | 17:03 | |
| fungi | so on the expectations of people front, if there is effectively already no docs team except on paper (pun?), then dissolving it officially just seems like a reflection of reality whether it's a reality we like or not | 17:04 |
| *** sarob has joined #openstack-tc | 17:05 | |
| fungi | whether there are folks interested in writing documentation who don't form a cohesive team is somewhat orthogonal in my mind | 17:05 |
| *** lbragstad has quit IRC | 17:05 | |
| fungi | but if there are and they have sufficient interest in forming a sig around it, then that works for me | 17:06 |
| zaneb | yeah, so there are some folks who maintain the docs tooling, and I think everyone agrees that makes sense as a SIG. Doug's point is that there are also actual documentation repos to be maintained, and stuff to do on every release, and a team should handle that | 17:07 |
| fungi | so i'd approach it as two things: 1. official dissolution of the already vacant documentation team, 2. people expressing a desire to form a documentation sig | 17:07 |
| zaneb | although it's not clear that those latter people exist in either scenario | 17:07 |
| zaneb | that's fair, but step 1 also involves deciding where the repos currently owned by that team end up | 17:11 |
| *** dims has quit IRC | 17:12 | |
| *** lbragstad has joined #openstack-tc | 17:13 | |
| *** dims has joined #openstack-tc | 17:13 | |
| fungi | and my counter to dhellmann's concern is mainly that if the assertion is there's nobody around any longer who wants to do the documentation-related stuff which needs to happen at each release, declaring a team around it won't necessarily make that any less the case | 17:15 |
| fungi | so we need a plan to distribute that work to the folks who have a vested interest in seeing it continue | 17:15 |
| fungi | and if nobody has a vested interest in seeing it continue, then maybe it's not as important as we think it is | 17:16 |
| zaneb | dhellmann also suggested moving those repos to the release management team iirc | 17:16 |
| *** dklyle has quit IRC | 17:34 | |
| *** sarob has quit IRC | 17:35 | |
| -openstackstatus- NOTICE: Gerrit is being restarted to add gitweb links back to Gerrit. Sorry for the noise. | 17:37 | |
| *** ianychoi has quit IRC | 18:15 | |
| dhellmann | yeah, I don't want to make a new team, I want someone to pick up the work that used to be done by people that aren't here any more | 18:55 |
| dhellmann | teams do also evaporate, but if we go by ttx's definition of what makes a team vs. a sig, then I think updating docs.openstack.org each cycle to reflect the current state of each release is part of the process of building that release and should be done by a team | 18:57 |
| fungi | and that could be done by infusing the existing team with new people, or by further distributing that work to other existing teams with a vested interest in the work continuing | 18:57 |
| dhellmann | the "existing team" is basically Stephen, so I don't know about that approach | 18:57 |
| dhellmann | well, and of course asettle | 18:58 |
| dhellmann | we have lots of hypothetical solutions to the problem. I'm trying to point out that we need to pick a realistic one. I proposed one such realistic solution in my comments on the patch. | 18:58 |
| fungi | but if the aggregation of documentation-interested folks isn't going to have time to do that per-cycle routine work, then i don't see that telling them they can't form a sig around documentation interests solves the problem either | 18:59 |
| dhellmann | I didn't say anything about creating a sig | 18:59 |
| dhellmann | I don't like the patch as proposed because it moves a repo to a sig that I think should stay owned by a team | 18:59 |
| dhellmann | the rest of it is fine | 19:00 |
| fungi | yep, that much makes sense | 19:00 |
| *** sarob has joined #openstack-tc | 19:27 | |
| *** whoami-rajat has quit IRC | 20:05 | |
| *** sarob has quit IRC | 20:09 | |
| *** e0ne has joined #openstack-tc | 20:10 | |
| *** e0ne has quit IRC | 20:12 | |
| *** diablo_rojo has joined #openstack-tc | 20:48 | |
| *** sarob has joined #openstack-tc | 21:06 | |
| *** mriedem has quit IRC | 21:53 | |
| *** tosky has quit IRC | 21:59 | |
| *** sarob has quit IRC | 22:12 | |
| *** dklyle has joined #openstack-tc | 23:21 | |
| *** diablo_rojo has quit IRC | 23:24 | |
| *** dklyle has quit IRC | 23:35 | |
| *** diablo_rojo has joined #openstack-tc | 23:52 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!