| *** zaneb has quit IRC | 00:41 | |
| *** ricolin has joined #openstack-tc | 01:02 | |
| *** dangtrinhnt_ has joined #openstack-tc | 01:31 | |
| *** dklyle has joined #openstack-tc | 02:42 | |
| *** david-lyle has quit IRC | 02:43 | |
| *** dklyle has quit IRC | 02:43 | |
| *** dklyle has joined #openstack-tc | 02:43 | |
| *** Bhujay has joined #openstack-tc | 03:18 | |
| *** gcb_ has joined #openstack-tc | 03:23 | |
| *** Bhujay has quit IRC | 03:26 | |
| *** Bhujay has joined #openstack-tc | 04:16 | |
| *** jaosorior has joined #openstack-tc | 04:31 | |
| *** gcb_ has quit IRC | 05:10 | |
| *** e0ne has joined #openstack-tc | 05:26 | |
| *** e0ne has quit IRC | 06:00 | |
| *** e0ne has joined #openstack-tc | 06:42 | |
| *** e0ne has quit IRC | 06:43 | |
| *** jaosorior has quit IRC | 07:17 | |
| *** tosky has joined #openstack-tc | 07:31 | |
| *** jaosorior has joined #openstack-tc | 07:37 | |
| *** dtantsur|afk is now known as dtantsur | 08:25 | |
| *** cdent has joined #openstack-tc | 08:37 | |
| *** e0ne has joined #openstack-tc | 08:58 | |
| *** jpich has joined #openstack-tc | 09:00 | |
| * cdent makes yet another "what is the tc really" post to os-dev | 09:05 | |
| dims | o/ | 10:22 |
|---|---|---|
| dims | lots to catch up on :) | 10:22 |
| * cdent waves to dims | 10:22 | |
| dims | hi cdent | 10:23 |
| *** dtantsur is now known as dtantsur|brb | 10:27 | |
| *** e0ne has quit IRC | 10:51 | |
| cmurphy | welcome back dims | 10:55 |
| *** Bhujay has quit IRC | 11:17 | |
| *** Bhujay has joined #openstack-tc | 11:40 | |
| *** e0ne has joined #openstack-tc | 11:47 | |
| *** jroll has quit IRC | 12:00 | |
| *** jroll has joined #openstack-tc | 12:01 | |
| *** ricolin has quit IRC | 12:09 | |
| *** cdent has quit IRC | 12:14 | |
| *** Bhujay has quit IRC | 12:16 | |
| *** Bhujay has joined #openstack-tc | 12:16 | |
| *** needssleep is now known as TheJulia | 12:23 | |
| TheJulia | o/ | 12:24 |
| *** dtantsur|brb is now known as dtantsur | 12:45 | |
| *** cdent has joined #openstack-tc | 12:48 | |
| *** zaneb has joined #openstack-tc | 12:55 | |
| *** mriedem has joined #openstack-tc | 13:23 | |
| dims | thanks cmurphy | 13:39 |
| *** cdent has quit IRC | 13:43 | |
| *** cdent has joined #openstack-tc | 13:53 | |
| openstackgerrit | Merged openstack/project-team-guide master: Remove proactive backport stable instructions https://review.openstack.org/593198 | 13:57 |
| *** Bhujay has quit IRC | 14:02 | |
| openstackgerrit | Tobias Urdin proposed openstack/governance master: Update Puppet PTL IRC nick https://review.openstack.org/593637 | 14:17 |
| *** e0ne has quit IRC | 14:28 | |
| *** efried has joined #openstack-tc | 14:34 | |
| efried | ō/ | 14:34 |
| *** e0ne has joined #openstack-tc | 14:35 | |
| ttx | o/ | 14:36 |
| *** annabelleB has joined #openstack-tc | 14:42 | |
| *** ricolin has joined #openstack-tc | 14:47 | |
| *** cdent has quit IRC | 14:50 | |
| *** lbragstad has joined #openstack-tc | 14:54 | |
| *** cdent has joined #openstack-tc | 15:18 | |
| efried | tc-members: For those of you who have been following the dev ML thread on placement extraction (http://lists.openstack.org/pipermail/openstack-dev/2018-August/133445.html)... | 15:27 |
| * mnaser has been following quietly :X | 15:28 | |
| efried | In the nova-scheduler meeting this morning (http://eavesdrop.openstack.org/meetings/nova_scheduler/2018/nova_scheduler.2018-08-20-14.00.html) we started discussing how the decision should actually get made. | 15:28 |
| efried | I.e. should it be democratic? Who should get a vote? Should all votes weigh the same? Who would even decide on *these* questions? | 15:29 |
| efried | And the idea came up that we could possibly ask the TC to govern the process. Not make the decision - just help us wade through the politics, mechanics, process, etc. | 15:29 |
| efried | So | 15:29 |
| mnaser | efried: that is a very interesting thing to bring up honestly. maybe we can look at how the decision to split nova to cinder was done? | 15:30 |
| smcginnis | That was a very different time though. | 15:30 |
| efried | Okay. I wasn't around for that, so I would be relying on others. | 15:30 |
| mnaser | maybe those who were around could comment about it, i'm sure that was a painful split too | 15:30 |
| * mnaser personally doesn't see why it's a big issue of splitting it out especially with how nicely zuul allows us to build dependency chains across projects | 15:31 | |
| mnaser | build x feature in placement, depends-on in a nova change that consumes it, | 15:31 |
| smcginnis | Yeah, I'm still not clear why the push to keep it in Nova honestly. | 15:32 |
| efried | I agree: I don't see any situations where depends-on would be worse than having patches in series. | 15:33 |
| mnaser | my concern is would it be extra work for everyone if no one else is consuming/using it | 15:34 |
| mnaser | i.e. in deployment tool world we need to figure out how to do the entire split without breaking $world | 15:34 |
| persia | Could have a higher-level depends-on that covered it (e.g. requirements). | 15:34 |
| efried | cdent has been leading the thinking through that | 15:34 |
| mnaser | if we have to do all of that for no one except nova to end up consuming it (i think the important thing to note is *consume* it, not *report* to it) | 15:34 |
| efried | mnaser: There's also the issue of core/maintainer team separation. | 15:35 |
| efried | There are at least three people who should be placement cores who are not nova cores. And will probably not become nova cores due to their focus being primarily on placement code. | 15:35 |
| mnaser | efried: is there anything stopping the nova team from adding members to core and telling them "you're core for placement, please kindly don't +A anything that doesnt touch placement" | 15:36 |
| mnaser | i like to think we all trust each other pretty well :D | 15:36 |
| efried | mnaser: I've asked that question. It's just "not done". | 15:36 |
| efried | The reasons are weak IMO, because I agree we should be able to trust, but that seems like a non starter. | 15:36 |
| smcginnis | efried: The core question is a key one in my mind for why this makes sense to separate. | 15:36 |
| smcginnis | mnaser: No comment. | 15:37 |
| mnaser | well | 15:37 |
| mnaser | perhaps we can ask if infra would be interested in https://gerrit.googlesource.com/plugins/owners/+/refs/heads/master/README.md ? | 15:37 |
| jroll | we've been talking about the "partial core" thing for years and teams refuse to do it, I'm not sure it's worth bringing up in this context | 15:38 |
| mnaser | as an interim solution if there are some who are not comfortable of giving "full core" | 15:38 |
| smcginnis | Hmm, k8s-like OWNERS. Maybe could work. But does seem like a bigger thing than just making placement its own team. | 15:38 |
| jroll | it'll just derail | 15:38 |
| cdent | even if we made some "placement-only" cores, that wouldn't address the issues with competition for blueprint space | 15:38 |
| smcginnis | jroll: ++ | 15:38 |
| mnaser | cdent: thats valid too re: blueprint space | 15:38 |
| smcginnis | And cdent: ++ | 15:38 |
| mnaser | cdent: is this type of conversation pressing to have now pre-PTG? | 15:39 |
| mnaser | or maybe is this something we can find time for at the PTG? | 15:39 |
| efried | I would love the PTG conversation to be "HOW are we going to do this?" as opposed to "ARE we going to do this?". | 15:40 |
| cdent | the hope was to get it resolved before the ptg, so that we could focus the ptg on dealing with resolving the technical problems. based on my experience with working to move this forward for the past two years, putting it off to the ptg has meant that it doesn't get done | 15:40 |
| cdent | efried++ | 15:40 |
| mnaser | efried: i agree | 15:40 |
| mnaser | i wonder if we can extract commits done inside the specific paths that placement api includes | 15:40 |
| cdent | though it would be nice for the ptg to be about big picture planning, nova historically has resisted that in favor of details for the immediate cycle | 15:40 |
| cdent | this has happened again and again | 15:40 |
| mnaser | i.e.: nova.api.openstack.placement, placement docs | 15:41 |
| mnaser | try to come up with a list of all placement API (server side, not consumer side) | 15:41 |
| mnaser | and then just make a poll for those commiters.. | 15:41 |
| cdent | mnaser: that's in progress, the list of people in my email message are those people | 15:42 |
| cdent | (the long one in response to doug) | 15:42 |
| cdent | that list of people is the top ten committers on placement service side code | 15:43 |
| mnaser | maybe if we can come up with a transparent way of determining all placement committers (that we all agree too) and then setup a vote for all of them | 15:43 |
| cdent | it's hard to get super accurate results because of file moves, and different opionions on whether a commit or loc ought to mean more | 15:44 |
| efried | But mnaser ++ this is just the kind of thing I was hoping to get out of this conversation. | 15:44 |
| * cdent nods | 15:44 | |
| jroll | I agree that the decision should be made by the heavier placement contributors, but I do think we need to get agreement from nova leadership that they'll live by the decision, even if they don't agree with it | 15:44 |
| mnaser | i dont think # of commits or loc means more or not imho | 15:44 |
| mnaser | the same way we do our ptl elections | 15:44 |
| efried | jroll: Exactly. | 15:44 |
| smcginnis | In or out, no weight. | 15:44 |
| smcginnis | But there are some more involved in placement than others, so just being part of the identified group of "contributors" does seem like it would be missing a semi-important aspect of it. | 15:45 |
| smcginnis | I do think that would be a first step though. | 15:46 |
| efried | I'm fairly confident the result would be the same, tbh. | 15:46 |
| * cdent nods | 15:46 | |
| zaneb | I haven't read the whole thread, but if it's going to be in a separate repo within the Nova project then it can easily have its own core team enforced by Gerrit ACLs | 15:46 |
| smcginnis | I suppose placement isn't old enough to have URLs that are not https. ;) | 15:46 |
| efried | The main rub is as jroll says: whatever process we come up with has to be agreed upon by the nova leadership. | 15:47 |
| jroll | zaneb: that 'if' is the primary question | 15:47 |
| efried | zaneb: So far the consensus in the pro-extraction camp is to extract fully into an independent repository. | 15:47 |
| smcginnis | I would say if the placement contributors are in favor of full extraction, the existing nova core can weigh in but shouldn't have any veto power on it. | 15:48 |
| zaneb | jroll: the thread starts at least with the premise that it will at least be in a separate repo as a given, and that the primary question is whether it should be inside or outside the Nova project | 15:48 |
| * zaneb continues reading | 15:48 | |
| efried | smcginnis: ++ But does the TC (or *anyone*) have the authority to enforce that or any other procedural decision here? | 15:49 |
| smcginnis | Yes | 15:49 |
| jroll | zaneb: fair | 15:49 |
| efried | Oh. Well then. | 15:49 |
| smcginnis | We don't want to have to, but when it all comes down to it, yes. | 15:49 |
| smcginnis | I very much hope that isn't even necessary to be considered an option. | 15:50 |
| * efried puts in back pocket | 15:50 | |
| efried | I agree | 15:50 |
| *** edleafe has joined #openstack-tc | 15:50 | |
| jroll | the nova team may not have a real veto power, but they can always do things like not remove the placement code from nova or stop depending on placement | 15:50 |
| smcginnis | If a team of people are working on something and they want to control its direction, then just because they work along side another group of people, that shouldn't have an impact on it. | 15:50 |
| edleafe | jroll: the placement code will remain in Nova, albeit frozen | 15:50 |
| jroll | edleafe: then not freeze it, whatever, you get the point | 15:51 |
| edleafe | jroll: yep | 15:51 |
| jroll | I understand the TC could overrule somehow to "force" them not to do these sorts of effective veto things, but I don't believe the TC will do that | 15:51 |
| smcginnis | Forking is an option. A bad one, but an option. | 15:51 |
| jroll | forking nova? | 15:51 |
| edleafe | smcginnis: the idea is that it would be temporary | 15:52 |
| efried | cdent: ^ is a good point - the etherpad talks about what happens to the placement project after the fork, but what about the old placement code on the nova side? Does it get removed? Frozen? | 15:52 |
| jroll | technically that works, but a fork would be dead without nova leadership | 15:52 |
| smcginnis | Haha, I suppose there are some that might condifer that, but I meant just placement jroll. | 15:52 |
| zaneb | we really really really want people to agree on the best way forward amongst themselves (though of course we are happy to help that process along) | 15:52 |
| jroll | smcginnis: yeah, but if nova doesn't consume said fork... what's the point | 15:53 |
| edleafe | smcginnis: get placement to a stable place, freeze it, and then extract. Nova would continue to its version of placement. When the new placement is up and running, Nova can delete its placement code and work with the service from the separated code | 15:53 |
| jroll | what I'm saying is nova leadership has an effective veto whether or not they have a technical one | 15:53 |
| cdent | efried: I left it off simply because I hadn't thought of it yet, but presumably we'd freeze it until such a point as we've demonstrated the new stuff is healthy and then let it be removed as/when people were happy | 15:53 |
| zaneb | that said, technically the TC has the power to impose a solution. we just want to avoid having to use it | 15:53 |
| smcginnis | Something just seems really wrong if the people working on placement want it separate and one of its consumers (granted one of its primary/only(?) consumers) could effectively shoot it down. Or even want to. | 15:54 |
| cdent | efried: because of the way placement works and uses config and exposes it's testable-ness, there should be very very little difrent between an in tree and an out of tree placement | 15:55 |
| zaneb | edleafe: isn't that exactly how Gantt failed? | 15:55 |
| edleafe | zaneb: nope | 15:55 |
| edleafe | gannt failed because scheduler and nova were tightly bound | 15:55 |
| edleafe | trying to remove the code resulted in an unworkable mess | 15:55 |
| edleafe | So we dropped gannt and focused on cleaning up the interface | 15:56 |
| edleafe | this was all pre-placement | 15:56 |
| efried | So *if*, hypothetically, the TC imposed a process, what would it be? [any contribution] == [one vote]? Weighted by amount of contribution? Do cores get more say? etc? | 15:56 |
| edleafe | Once scheduler and nova had a clean interface, then it would be separated | 15:56 |
| jroll | smcginnis: I agree, I just want to point out that it could happen, if people so desired | 15:56 |
| edleafe | But with placement, the decision was made to leave the scheduler in nova, and instead run a separate placement service | 15:57 |
| edleafe | Placement was always supposed to be separate | 15:57 |
| edleafe | It was kept in Nova because some thought it would allow faster development | 15:57 |
| edleafe | Extraction was always "next cycle" | 15:58 |
| jroll | I would have to re-read to confirm, but I don't think anyone in the thread is saying it should be in nova forever, just 'not now' | 15:58 |
| dhellmann | I can't imagine a scenario in which we "impose" a process on anyone to make this decision. If the people involved want some outside mediation, we can help with that, but imposing something hardly seems like a recipe for future successful collaboration. | 15:58 |
| cdent | jroll: I think that's a correct interpretation, but it has been "not now" every six months for the last two years | 15:58 |
| efried | Agree dhellmann, swhat I'm looking for here, "outside mediation" | 15:58 |
| jroll | cdent: yep | 15:59 |
| dhellmann | frankly, if we've reached a point where we think the people involved can't make the decision for themselves without any help then I think the project is already showing signs of failing | 15:59 |
| dhellmann | s/the project/placement/ | 15:59 |
| cdent | dhellmann: I think that's an extremely unfair interpretation | 15:59 |
| efried | dhellmann: I think that's the issue. It's not placement people who are making it difficult. | 15:59 |
| jroll | cdent: to be clear, extracting it now seems right to me, but I'm not well informed on the details :) | 15:59 |
| cdent | efried++ | 15:59 |
| edleafe | Placement is finally ahead of Nova. IOW, Nova still has to do work to implement the newer features of placement. So now is an ideal time to freeze placement development, extract, and then continue separately | 15:59 |
| edleafe | Nova isn't currently bottlenecked by placement | 16:00 |
| dhellmann | cdent : do you somehow anticipate the 2 separate teams working better together than what we have now that is leading to this even being a question? | 16:00 |
| efried | dhellmann: My answer to that is actually "yes". | 16:01 |
| cdent | dhellmann: the main advantage and improvement I can see is one of the things that eric has mentioned: placement expertise can be localized | 16:01 |
| cdent | and people who are not and never will be cores in nova can be in placement | 16:02 |
| * jroll wishes he could stick around for this but has to eat so he doesn't pass out during meetings later | 16:02 | |
| * cdent pauses for efried | 16:02 | |
| efried | dhellmann: Of note, the teams won't be all that "separate" in terms of personnel. I anticipate there being about the same number of still-nova-core placement cores as non-nova-core placement cores. | 16:02 |
| dhellmann | I can see how that would make some people happy. I don't see how that makes collaboration happen more smoothly. | 16:02 |
| smcginnis | I don't think it's about making some people happy. It's about letting a team control their own project. | 16:04 |
| edleafe | dhellmann: if the idea is that Nova will be the only consumer of placement, I would agree with you | 16:04 |
| dhellmann | smcginnis : I agree, in principle. But setting the situation up so that the decision is made through confrontation doesn't feel like a good way to start out. | 16:05 |
| smcginnis | Well, back to my earlier comment, I don't even see why this is confrontational. If the team working on placement wants to extract it to its own thing, why is this even an issue. | 16:06 |
| dhellmann | that's an excellent question | 16:07 |
| dhellmann | I believe there have been a couple of technical answers to that question, so it sounds like all of the people involved do not yet agree. | 16:07 |
| edleafe | smcginnis: and this isn't a reactionary move. This has been the intent since placement was started | 16:07 |
| smcginnis | edleafe: Another good point. | 16:07 |
| edleafe | smcginnis: We simply feel that now is an ideal time to do this | 16:10 |
| cdent | yes. | 16:11 |
| *** tellesnobrega has joined #openstack-tc | 16:11 | |
| smcginnis | It sounds like it to me, but again something I think should be up to the folks working on placement. | 16:11 |
| efried | dhellmann: The dissenters have been a vocal minority, and of people who aren't historically heavy placement contributors. | 16:11 |
| efried | corollary: The dissenters seem mostly concerned with the impact to the nova project | 16:12 |
| edleafe | efried: I haven't heard of any specifics as to how Nova would suffer. Just some hand-wavy generic statements | 16:13 |
| edleafe | Do you know of any? | 16:13 |
| efried | edleafe: I have heard specific arguments, but none that I thought had a lot of merit, no. | 16:14 |
| edleafe | thx | 16:14 |
| efried | dhellmann: ^ | 16:14 |
| *** e0ne has quit IRC | 16:16 | |
| *** bswrchrd has joined #openstack-tc | 16:18 | |
| efried | So dhellmann "it sounds like all of the people involved do not yet agree" <== depends what you mean by "people involved". | 16:20 |
| efried | Major contributors to placement itself agree (though Jay is a loud +0), assuming contribution is measured by commits. If we include reviews, we get a little bit of a shift toward the dissenting side. | 16:20 |
| efried | If we include "architecture" - the talkytalk that leads to code and reviews - a little more shift. | 16:20 |
| dhellmann | who owns the code today? | 16:20 |
| efried | dhellmann: "owns" how? | 16:20 |
| evrardjp | dhellmann: isn't that the Nova PTL? ;p | 16:21 |
| dhellmann | it's in the openstack/nova repo, right? | 16:21 |
| efried | yes | 16:21 |
| dhellmann | so then I would expect the nova core team to be involved in the decision | 16:21 |
| dhellmann | not solely, but to be included | 16:21 |
| efried | Well and good. How involved? One vote per? And to the exclusion of other contributors? | 16:21 |
| evrardjp | Maybe I am out of bounds here, but that's a nova thing, so nova team decides, and if no consensus Nova PTL decides? | 16:21 |
| efried | okay | 16:21 |
| dhellmann | I don't think we've had to resort to formal voting structures in the past. Why do we need that for this decision? | 16:22 |
| cdent | evrardjp: what is "the nova team"? Is it just the cores? What does it means when some signficant (large) chunk of the code was composed by non-cores? | 16:23 |
| efried | dhellmann: In case not doing that leads to stalemate, which is a distinct possibility. | 16:23 |
| smcginnis | Even though I've admitted I don't fully understand the issue, this is all coming across as a hostage situation. That's extreme, but there are parts about it that seem that way based on what I've seen so far. | 16:23 |
| efried | Yeah smcginnis, good analogy. I was going to say, it feels like Georgia asking the Union whether it's allowed to secede. | 16:24 |
| evrardjp | cdent: prior doesn't matter -- code dies at every commit. Ppl actively working on it now "owns" the code. Core or non core it doesn't matter to me. | 16:24 |
| cdent | evrardjp: sure, same thing: significant maintainership of placement is not nova-cores | 16:24 |
| mnaser | so i did some quick hacking and i identify 51 authors that have worked on the placement code | 16:24 |
| mnaser | what's against setting up a quick poll for those and asking them on their say in that? | 16:25 |
| efried | evrardjp: Most commits and reviews in the last, say, six months => Jay, Chris, me, Tetsuro, Ed. (cdent does that sound about right?) That's two nova cores (one heavily pro-extraction, one vocally +0) and three non-nova cores (all pro extraction). | 16:25 |
| mnaser | the code i used to build it out: http://paste.openstack.org/show/728437/ | 16:25 |
| dhellmann | look, there's nothing at all preventing you from extracting the code into its own repository today. you can just do that, but it would *fail* if the teams using the code don't agree to use that version of the code. so if the nova team isn't convinced, how would a vote help that? | 16:26 |
| efried | mnaser: I like that. As informational, not actionable, it can't hurt, can it? | 16:26 |
| mnaser | there's some automation in there but mostly seems to be folks with actual commits in there | 16:26 |
| evrardjp | agreed with mnaser view's except I think this idea should come from melwitt , but I am pedantic there :p | 16:26 |
| cdent | mnaser: doing a "quick poll" doesn't address dhellmann's main concern (as I understand it): We need to all work together after this. There seems to be concern that that might be challenging. | 16:26 |
| dhellmann | yes, that's exactly my concern | 16:26 |
| mnaser | IMHO: if you want to split placement, you're going to have to front the extra work, so it will be a bit more heavy on the placement team | 16:27 |
| edleafe | The problem with any kind of vote is social. If the Nova supercores don't want it to happen, it isn't going to happen. | 16:27 |
| cdent | mnaser: that's understood. I've already done it 3 times in the past two years (as experiments) | 16:27 |
| dhellmann | I have no doubt of our ability to solve any technical issues with extracting the code. | 16:27 |
| mnaser | i like to think if the nova team has most things taken care for them in terms of extracting the entire code base, it won't be that much of an issue to deal with | 16:27 |
| mnaser | but if it starts taking up their cycles, i can imagine it not being a subject of interest for them | 16:27 |
| * dhellmann has to step away | 16:28 | |
| mnaser | hell, if it comes down to it, this feels much easier for me on a deployer, but start a new project called $something_other_than_placement, copy the code over, and slowly start extracting things out of the nova version until its non existant | 16:28 |
| mnaser | and if nova cores are -2'ing a reasonable patch to remove functionality from the "internal" placement out to the new external service.. then we can discuss that | 16:29 |
| mnaser | but it feels easier to have a seperate service run side by side for migration purposes rather than take one down and replace it, but thats just my operator hat | 16:29 |
| edleafe | mnaser: it already runs as a separate service | 16:30 |
| cdent | mnaser: that's a completely doable thing, and is within the options already being discussed. | 16:30 |
| mnaser | edleafe: oh i'm aware, but it feels like the current move is removing it from nova and putting it somewhere else, in the same cycle | 16:30 |
| mnaser | also maybe as an intermediate step, instead of nova.api.placement living in nova/, we just move that to a seperate repo and it gets imported instead.. as i'm thinking out loud, maybe others already came to this conclusion, but code living in a seperate repo doesn't have to be tied to the idea of it being consumed by other projects | 16:31 |
| *** mriedem has quit IRC | 16:32 | |
| edleafe | mnaser: the plan has *always* been for placement to be separate. This isn't a new thing. It just keeps getting postponed until "next cycle" for $REASONS. Now that placement is ahead of Nova, it seems like the ideal time to finally do it. | 16:32 |
| edleafe | mnaser: Nova only communicates to placement via HTTP. | 16:32 |
| mnaser | i mean, some sort of compatibility shim for 1 cycle would be nice at least, even if its just importing something from the placement libs | 16:33 |
| cdent | mnaser: that's not necessary. placement in nova and placement out of nova are the same thing | 16:34 |
| edleafe | mnaser: I'm not sure I follow. Nova doesn't work directly with any placement code. Nothing on the Python level | 16:34 |
| mnaser | cdent: but think of deployment tools/downstream tools | 16:34 |
| mnaser | e.g in openstack ansible we deploy the placement api wsgi which comes in the nova package | 16:35 |
| * cdent nods | 16:35 | |
| mnaser | now we have to build out a whole new role that deploys placement alone, rdo/etc have to rebuild new packages that are outside the nova namespace, etc | 16:35 |
| efried | I agree with dhellmann that it's not about technical challenges. There's nothing there that we can't overcome relatively easily. | 16:35 |
| * cdent nods at efried | 16:35 | |
| mnaser | efried: the reason i go back to technical challenges is i'm hoping that's the only reason that's holding us back from doing it | 16:35 |
| efried | mnaser: It's not. It's not even one of the main reasons. | 16:36 |
| cdent | efried++ | 16:36 |
| mnaser | well, i'm hoping that we're discussing on technical terms of "this is a better solution" rather than "i dont like this" | 16:36 |
| edleafe | mnaser: it seems to be a fear among some nova cores that an independent Placement will go rogue and thumb its nose at Nova | 16:36 |
| efried | which would of course be suicide | 16:37 |
| mnaser | pretty much, considering it is the biggest and heaviest consumer | 16:37 |
| efried | assuming it was even considered | 16:37 |
| efried | which it wouldn't be | 16:37 |
| efried | that's just... silly. | 16:37 |
| mnaser | and i'd hope that in this case, we can figure it out if it comes down to that. | 16:37 |
| efried | ++ | 16:38 |
| mnaser | i.e. if placement says "no, you cant do this, because we built this other feature you should leverage" | 16:38 |
| edleafe | efried: that's why I asked if you were aware of any technical objections | 16:38 |
| efried | which happens all the time today. | 16:38 |
| mnaser | then that's fine, but if placement says "no you cant do that because we don't want to" | 16:38 |
| mnaser | that's different | 16:38 |
| efried | "because we want to express our independence from Nova, like a rebellious teenager". | 16:38 |
| efried | Yeah, I hope we're all more mature than that. | 16:38 |
| mnaser | i like to think we're not in a place where that's an issue. if anything, i feel like this might help blossom placement and increase the velocity of stuff being added to it | 16:39 |
| evrardjp | mnaser: we wouldn't have to build a new role for placement, but it's indeed a pain I wanted to discuss just after :) | 16:39 |
| cdent | I'd just like to note that we're doing a lot of speculating here, without all the relevant people | 16:39 |
| edleafe | "You don't understand what my life is like!!" | 16:39 |
| efried | mnaser: ++ | 16:39 |
| mnaser | because now placement devs feel free to iterate quicker, as long as we agree to maintain some sort of jobs to make sure that you dont break downstream consumers (such as nova) | 16:39 |
| edleafe | cdent: true, this is just based on the email thread | 16:39 |
| mnaser | so having jobs inside nova etc, but that's a given | 16:39 |
| edleafe | mnaser: of course. Nobody wants to break anything | 16:40 |
| mnaser | the only reason i'm not fully supportive of it yet is that i know mel as PTL mentioned that she sees value in keeping it, and i would want to hear her side of it | 16:40 |
| cdent | mnaser: yes we've already got stuff in place so that nova functional tests can still run a placement | 16:40 |
| mnaser | because i'm sure as a PTL she might be seeing things that i have no idea in terms of roadmap/etc | 16:41 |
| efried | mnaser: Yes. Nothing really changes there. Nova scheduler is running placement. We flip from installing it from the nova project to installing it from the placement project and we're done. | 16:41 |
| * efried rereads melwitt's contribution to the ML thread... | 16:41 | |
| mnaser | (with my deployer hat on though, i'd still hope that for one cycle we can still maintain nova-placement-wsgi in repo) | 16:41 |
| mnaser | that way it helps us transition a tad bit easier | 16:41 |
| cdent | mnaser: yes, we'd want to do that. there's at least two ways to accomplish that | 16:42 |
| evrardjp | in the past things were pulled out of the repositories and transitioned into things like oslo. Isn't that similar? If not, why? could we make it similar? | 16:43 |
| cdent | evrardjp: this is more like cinder leaving nova, rather that oslo. oslo is shared code | 16:44 |
| efried | cdent: What does it mean to extract "as a repo within the compute project"? | 16:44 |
| evrardjp | cdent: I agree, but we said cinder leaving nova already -- I am curious why it's not like oslo. | 16:44 |
| evrardjp | why can't this new place be shared? | 16:44 |
| efried | shared in what sense evrardjp? | 16:45 |
| evrardjp | if new place happens | 16:45 |
| evrardjp | efried: I am new. I am just comparing to things to understand. | 16:45 |
| cdent | efried: compute is the overall project of which mel is the ptl. It has several repos. nova is the biggest, but there's also novaclient, os-traits, others. as a collection they are "compute" | 16:45 |
| cdent | being a repo in the compute project means that placement is still "compute" | 16:46 |
| mnaser | efried, cdent i think the better term is the compute team | 16:46 |
| mnaser | nova team, subprojects inside | 16:46 |
| mnaser | s/subprojects/projects/ | 16:46 |
| cdent | one of the concerns with that is the perception of not bein separate enough | 16:46 |
| evrardjp | cdent: that can be resolved separately? | 16:47 |
| evrardjp | can that* | 16:47 |
| mnaser | *personally* i dont write stuff that talks to placement but if my application depended on it but it lived under nova, it would feel.. weird. | 16:47 |
| fungi | oof, i go to lunch and you people leave me hundreds of lines of scrollback | 16:47 |
| fungi | er, i mean, thanks! | 16:47 |
| mnaser | fungi: have fun :) | 16:47 |
| efried | cdent: What are the process implications of that? Taking the examples you gave, they inherit nova-core and then get to add extra cores. Is that the extent of it? | 16:47 |
| evrardjp | fungi: hahah yw | 16:47 |
| evrardjp | efried: you could have different cores on different repos... | 16:47 |
| mnaser | i think that solves the velocity issues but it might not resolve the issue that folks will still think its a nova thing that i can use | 16:47 |
| cdent | mnaser: yes that | 16:47 |
| evrardjp | mnaser: but that can later be changed in governance by having this repo as its own thing | 16:48 |
| evrardjp | if needed | 16:48 |
| mnaser | i.e. think cinder depending on an api that is not nova specific but lives in nova | 16:48 |
| mnaser | sure, that is a valid point too | 16:48 |
| mnaser | this can be split into two steps, and that way it'll still somewhat be under nova control | 16:48 |
| mnaser | until it can graduate to be it's own thing. | 16:48 |
| cdent | efried: from a purely technical standpoint there is little that _has_ to be different between placement within nova, but separate repo, and placement its own project team | 16:48 |
| mnaser | and that way it's just a matter of a governance patch | 16:48 |
| efried | Sorry I'm slow, but now I even more don't understand the difference. | 16:49 |
| mnaser | i think splitting this into smaller pieces *might* make it a little easier | 16:49 |
| efried | It's just a governance patch? | 16:49 |
| evrardjp | to what I hear, there are two opinions, one that consider it would hurt the nova catching up features, and one that consider it wouldn't hurt | 16:49 |
| mnaser | so step 1: split placement repo outside nova repo, but keep it under nova team | 16:49 |
| cdent | the reasons I would like to see it be its own project team, now, are at leat twofold: if we're going ot make change, let's make a lot of change because we seem incapable of moving quickly on this issue. | 16:49 |
| mnaser | step 2: move placement outside nova team (governance patch) | 16:49 |
| mnaser | i feel like step 2 can happen quite easily and quickly, step 1 is the hard one. | 16:50 |
| cdent | 2) there is a real perception issue out there in the world, it's been mentioned in the thread, and mentioned in other discussions. those perceptions matter | 16:50 |
| edleafe | mnaser: IMO, the reverse is true | 16:50 |
| cdent | as evidenced by this discussion | 16:51 |
| edleafe | mnaser: the code is essentially separate; we would just do some directory shuffling. | 16:51 |
| *** ricolin has quit IRC | 16:51 | |
| mnaser | edleafe: i guess i have this sort of perception that the code is heavily tied into nova | 16:51 |
| efried | what does governance mean in this context? That placement doesn't get its own PTL? That the nova core team has "architectural control"? That the blueprint/spec process is not separated? | 16:51 |
| mnaser | so extracting it out seems like a big task but i might not know that | 16:51 |
| mnaser | efried: without placement in it's own team, placement's ptl is the nova team ptl | 16:52 |
| jroll | are the anti-extract people okay with extracting to a separate repo, but within nova governance? | 16:52 |
| mnaser | however, core's on project is a decision of the ptl | 16:52 |
| jroll | efried: right, it means it's another nova project, just like python-novaclient or os-traits | 16:53 |
| jroll | er, another compute project | 16:53 |
| mnaser | yep ^ | 16:53 |
| edleafe | efried: all of the above | 16:53 |
| zaneb | mnaser++ | 16:53 |
| evrardjp | then as a separate repo, you can decide things easier, IMO. | 16:53 |
| edleafe | efried: we are also tied to all of Nova's processes, Nova's release cycle cadence, etc | 16:54 |
| efried | jroll: melwitt (the ptl) is in favor of extraction but remaining under compute (http://lists.openstack.org/pipermail/openstack-dev/2018-August/133452.html) | 16:54 |
| mnaser | right, but as a project under governance, you'd have to be using the openstack release process and likely you'll be on a similar cadence | 16:54 |
| mnaser | you can still do releases of deliverables seperately | 16:55 |
| jroll | efried: and the others? | 16:55 |
| mnaser | i.e. you can do placement 2.0.5 if the nova ptl OK's it | 16:55 |
| edleafe | mnaser: sure. I was just pointing out the implications | 16:55 |
| mnaser | you dont have to release all nova deliverables all at once | 16:55 |
| mnaser | smcginnis: can maybe confirm | 16:55 |
| jroll | mnaser: correct | 16:55 |
| evrardjp | edleafe: a team can have multiple deliverables that have different releasing cadences | 16:55 |
| efried | jroll: dansmith has expressed that he wants to make sure we're not arguing for full extraction for the wrong reasons (http://lists.openstack.org/pipermail/openstack-dev/2018-August/133454.html) but also that there are issues of dev velocity and collaboration which argue against extraction at all (http://lists.openstack.org/pipermail/openstack-dev/2018-August/133516.html) | 16:55 |
| evrardjp | oh mnaser said it. :) | 16:56 |
| jroll | efried: trying to get a feel for if extract-within-governance has the same issues as extract-and-separate-governance | 16:56 |
| edleafe | evrardjp: yes, as long as the PTL embraces that | 16:56 |
| jroll | efried: thanks | 16:56 |
| efried | jroll: jaypipes came in with a nominal +0, but it's definitely ambivalence as opposed to apathy (http://lists.openstack.org/pipermail/openstack-dev/2018-August/133510.html) | 16:56 |
| efried | jroll: The remainder of the voices have been pro, afair | 16:57 |
| mnaser | given that the PTL feels it's okay for it to live in a separate repo.. i would proceed. once there are actual real consumers of placement beyond nova, then we can move it out of governance. | 16:57 |
| jroll | efried: I did read the thread, but wasn't sure if there was other discussion. thank you | 16:57 |
| efried | jroll: Certainly there has been other discussion, but not really anything that hasn't been said in the ML thread. I could be wrong. | 16:58 |
| jroll | 👍 | 16:58 |
| mnaser | given that no one actually consumes placement right now, i dont see a super important need to split it out to its own team, but if we can get through step 1 and move it into a seperate repo, it'll help the developers start working on it | 16:59 |
| cdent | mnaser: what do you mean when you say "no one actually consumes placement" and what's your data? | 16:59 |
| mnaser | cdent: from reading that topic, it looks like reporting happens but not consumption, though i may be wrong | 16:59 |
| mnaser | so the only consumer of data seems to be nova, where other tools are just reporting | 17:00 |
| efried | I'm not sure I agree with the distinction between "reporting" and "consuming". | 17:00 |
| cdent | both dan and jay have said that without looking at all the data | 17:00 |
| * jroll thinks placement is clearly its own team, thinks that is a positive thing, and thinks we should structure governance accordingly | 17:00 | |
| efried | jroll: ++ | 17:00 |
| mnaser | so: create `openstack/placement`, cores are nova-cores + whomever the ptl deems is good for that and it's a project under `nova` team. once that step is done, we can look into moving it out into its own team in governance | 17:00 |
| cdent | mnaser: just to be clear, why wait? | 17:01 |
| mnaser | cdent: honestly? because this is probably the easiest way to get this accomplished. this is a good compromise from both teams to split it out | 17:01 |
| mnaser | once nova seems to realize that "hey this ain't so bad" | 17:01 |
| cdent | I would hope you would be honest with me all the time :) | 17:01 |
| efried | mnaser: IMO that's one of the major concerns. I would like to see the placement core team to be independent regardless of the governance dealy. | 17:01 |
| mnaser | then it might be easier to drop it entirely after | 17:01 |
| mnaser | efried: i like to think that the ptl will put those who are appropriate to be cores on placement | 17:02 |
| efried | mnaser: But if we start off with nova-core == placement-core, and a -1 to adding a new core is essentially a veto, it sets us up for a continuation of some of the political issues we have today. | 17:03 |
| cdent | core-ness is only one of several issues related to independence | 17:03 |
| efried | mnaser: issues which are strong motivators for this initiative in the first place. | 17:03 |
| efried | yeah | 17:03 |
| mnaser | afaik core-ness is not happening because nova doesn't do "partial cores" | 17:03 |
| efried | mnaser: Partially correct, yes. | 17:03 |
| efried | mnaser: Also, politics. | 17:03 |
| mnaser | i dont think its because ptls want to disallow people who know placement to not touch it | 17:03 |
| evrardjp | nova or compute partial cores? | 17:05 |
| *** mriedem has joined #openstack-tc | 17:05 | |
| *** e0ne has joined #openstack-tc | 17:05 | |
| *** jpich has quit IRC | 17:05 | |
| *** annabelleB has quit IRC | 17:06 | |
| evrardjp | just curious if cores on traits are the same as nova, etc. | 17:07 |
| evrardjp | for example | 17:07 |
| efried | evrardjp: In that example, os-traits doesn't have its own core team at all - it's fully inherited from nova. | 17:08 |
| efried | evrardjp: os-vif is maybe a better example: https://review.openstack.org/#/admin/groups/1175,members | 17:08 |
| efried | nova-core, plus three | 17:08 |
| mnaser | https://review.openstack.org/#/admin/groups/572,members novaclient seems to have a different team | 17:09 |
| evrardjp | so that fits the bill? | 17:09 |
| efried | mnaser: no, same thing. | 17:09 |
| efried | mnaser: nova-core, plus two. | 17:09 |
| mnaser | i mean, i think as a start, nova-core + 2-3 placement specific cores | 17:09 |
| mnaser | heck, they cant even block code from merging if it's up to that, but there's no need to assume bad intentions | 17:10 |
| mnaser | this will start the process of separation and allow increased velocity and maybe take a small load off the placement team | 17:10 |
| efried | mnaser: Mechanically, what is the difference between "under nova" and "independent"? A choice between two different and mutually-exclusive governance patches? | 17:14 |
| *** mriedem has quit IRC | 17:14 | |
| *** annabelleB has joined #openstack-tc | 17:15 | |
| *** e0ne has quit IRC | 17:15 | |
| dims | i like the os-vif model | 17:15 |
| dhellmann | tc-members: I'm about to propose a bunch of patches to update our repositories for the python3-first goal. | 17:15 |
| efried | mnaser: I.e. could we do all the things - create the repo, set up the core team, extract the code, set up the infra, etc. - and let the governance patches be the deciding ground for that piece? | 17:15 |
| openstackgerrit | Doug Hellmann proposed openstack/governance master: import zuul job settings from project-config https://review.openstack.org/593701 | 17:16 |
| openstackgerrit | Doug Hellmann proposed openstack/project-team-guide master: import zuul job settings from project-config https://review.openstack.org/593704 | 17:16 |
| mnaser | efried: under nova would need the PTL ok to split the code inside the team. your own team would involve an entire application process (afaik) | 17:16 |
| mnaser | about what is placement, what is it good for, what does it do, etc. | 17:16 |
| *** dtantsur is now known as dtantsur|afk | 17:17 | |
| cdent | mnaser: agree some of that would be necessary (and some of it already exists) but ttx appeared to suggestion some of it could be fast-tracked (if that's the way things went): http://lists.openstack.org/pipermail/openstack-dev/2018-August/133495.html | 17:18 |
| mnaser | right, but i dont see the big reason to make all those majors changes for that at the moment. i'd start with a split under compute team. | 17:18 |
| mnaser | if it's because you don't want to see nova-core in the list of cores, i think if we split placement, the initial core team of placement *should* be nova-core. | 17:19 |
| cdent | I'm going to need to leave soon, but I guess I can/will catch up in the logs. Before I go, just want to thank everyone for paying so much attention. | 17:19 |
| cdent | mnaser: it doesn't really have much to do with cores at all | 17:19 |
| dhellmann | https://review.openstack.org/#/q/topic:python3-first+(+openstack/service-types-authority+OR+openstack/project-team-guide+OR+openstack/project-navigator-data+OR+project:openstack/governance+OR+project:openstack/openstack-specs+OR++project:openstack/election+OR+project:openstack/goal-tools+)+is:open | 17:19 |
| cdent | it's about a) striking while the iron is hot, b) addressing long held perception issues about what is possible | 17:19 |
| mnaser | i doubt most people even know our governance model and its depths, if openstack/placement is a thing, most people dont even know that its under nova team | 17:19 |
| mnaser | i don't think that way of going about things is more productive, i dont think anyone looks at governance and says "oh openstack/placement is a nova thing, nevermind" .. the governance stuff is very much just a 'political' thing. we can look into it, but it certainly doesnt change much | 17:21 |
| mnaser | repo name is what most people look at anyways | 17:21 |
| mnaser | who controls openstack/os-vif or openstack/os-brick .. dunno but if i need to consume them, i will | 17:21 |
| cdent | we may wish to get some input from people who have wanted to use or develop against placement on that account. I've heard different things from different people | 17:22 |
| efried | How many of the action items are common to both approaches, and not blocked by the decision? E.g. can we create placement and placement-specs repositories in gerrit, start shoving code in them, and set them up for zuul while we're still discussing governance? | 17:22 |
| dims | efried : do you see a push back for the os-vif model? (new placement-core with nova-core as included group)? | 17:22 |
| mnaser | efried: given that melwitt said she's okay with that, then yes, i think it would be okay. | 17:22 |
| efried | dims: I think that would be fine, assuming reason is used when nominating and ratifying additional placement-core team members. | 17:23 |
| dims | right | 17:23 |
| efried | mnaser: I was asking from a technical standpoint whether we can get things accomplished while we're still discussing the governance decision. | 17:24 |
| efried | or if there's some aspect of that where we would be blocked until that decision is finalized. | 17:24 |
| mnaser | efried: i think if the ptl said they'd be okay with splitting repos, then i dont see the big problem with it. i do think you still need to use nova-specs for now | 17:25 |
| mnaser | because specs are a team thing rather than a project thing (i think). | 17:25 |
| cdent | efried: nothing is blocking us from making physical extraction progress, in large part because we'll want to do a lot of it in a third repo that we then push to gerrit | 17:25 |
| dims | efried : the mechanics is here - https://docs.openstack.org/infra/manual/creators.html - "Add New Repository to the Governance Repository" is optional, you can start without governance and then submit to governance | 17:25 |
| dims | exactly cdent | 17:26 |
| efried | Well then, cdent, I say we get started with those parts of the process, since the PTL is in favor of *some* form of extraction. Get some momentum going. | 17:26 |
| dims | ++ efried cdent | 17:27 |
| edleafe | efried: I have some cycles to work on that | 17:27 |
| edleafe | But let's discuss in -placement | 17:27 |
| cdent | efried: we already are, behind the scenes experiments have been in progress | 17:27 |
| cdent | with tools and strategies for extraction | 17:27 |
| efried | cdent: Cool, let's raise the curtain. | 17:27 |
| *** lbragstad has quit IRC | 17:28 | |
| cdent | efried: third times a charm? or is fourth? | 17:28 |
| cmurphy | I think this has moreorless been said but in terms of a decision process I believe we do already have a process, which is that the PTL is the "the buck stops here" person, it's ultimately up to her to decide what happens to the compute project | 17:28 |
| efried | cmurphy: The counterargument is that, when in the course of OpenStack events it becomes necessary for one project to dissolve the political bands which have connected it with another... | 17:29 |
| dims | cdent : this time do it in a openstack/ repo :) | 17:29 |
| cdent | dims: my constant desire to get consensus and agreement before doing things has not served me well in this instance | 17:30 |
| cdent | it apparently makes me look disruptive. very sad. | 17:31 |
| edleafe | efried: so eloquent! | 17:31 |
| melwitt | I'm in favor of making progress -- and thus extracting placement into its own repo under compute. but I don't agree that "placement is ahead of nova" and there are features that don't yet exist in placement, that we need in nova, that are part of what placement was designed for as a project in nova. affinity, numa, shared storage. it doesn't make sense to me to split placement out into a separate organization while we are in the middle | 17:31 |
| melwitt | of implementing features that will require tightly coupled cooperation. that's my opinion | 17:31 |
| efried | /nick tjefferson | 17:31 |
| cdent | melwitt: I hear you, but I don't agree with your assertion that there is any tight coupling there. | 17:32 |
| melwitt | okay | 17:32 |
| efried | melwitt: Do you feel like cooperation would suffer? | 17:32 |
| edleafe | melwitt: My concern is the unspoken assumption that there would not be cooperation | 17:32 |
| edleafe | Or a diminished level of cooperation | 17:33 |
| dims | edleafe : y that would be weird | 17:33 |
| melwitt | that is why, for example, in a corporate situation you don't split teams whose components need to integrate closely together into separate organizations. things go much more quickly and smoothly if the group is a cohesive entity moving toward a common goal. and IMO the compute project is that common goal | 17:34 |
| dims | melwitt : so would (new placement-core with nova-core as included group) work for you? | 17:35 |
| mnaser | i dont think there is any scenario in all of those where i would be okay with the placement repo cores not included nova-core for start | 17:36 |
| mnaser | i'm hoping thats a given | 17:36 |
| melwitt | nova-core inclusion is a minimum, IMO | 17:36 |
| dims | mnaser : 3 choices (just nova-core in charge, placement-core including nova-core in charge, placement-core seeded with folks in nova-core in charge) | 17:37 |
| dims | ack melwitt | 17:38 |
| dims | i am hoping more folks get added to placement core as they get active and then we can revisit in a release or two? | 17:39 |
| dims | melwitt : one argument against it if i read correctly was that not all nova-core(s) are active in placement. right? | 17:40 |
| evrardjp | melwitt: what we've moved to in openstack-ansible is that every repo gets its own core team, and we integrate the "global OSA" core team into each of the roles. We have a completely different structure, but that allows malleability | 17:40 |
| dhellmann | that sounds like how oslo is set up, too | 17:41 |
| dims | evrardjp : for the longest time, oslo has been doing the same | 17:41 |
| evrardjp | yup :) | 17:41 |
| evrardjp | Just saying, we've got prior expertise there :) | 17:41 |
| melwitt | dims: I think you'd have to clarify that with those who are against it | 17:41 |
| evrardjp | it's been good to us so far | 17:41 |
| *** e0ne has joined #openstack-tc | 17:42 | |
| dims | melwitt : guess for the new repo to be under nova in governance, nova-core would be a must | 17:43 |
| dims | melwitt : just looking at different view points | 17:43 |
| cdent | Now I really gotta go. Will catch up later. Thanks again. | 17:43 |
| *** cdent has quit IRC | 17:43 | |
| efried | I need to run as well. Thanks very much for the discussion, all. | 17:44 |
| dims | edleafe : efried : may be we should start there ... :) | 17:44 |
| efried | dims: Acknowledged. | 17:44 |
| edleafe | dims: I don't know of anyone who said they didn't want nova cores to be placement cores. | 17:45 |
| edleafe | Current nova cores only use their powers in the areas they have expertise. I wouldn't expect that to change | 17:46 |
| dims | edleafe : ++ | 17:46 |
| dims | so let's get rolling with a gerrit repo request edleafe | 17:47 |
| dims | melwitt : ^ | 17:47 |
| *** e0ne has quit IRC | 17:51 | |
| *** diablo_rojo_ has joined #openstack-tc | 17:53 | |
| *** diablo_rojo_ has quit IRC | 17:53 | |
| *** diablo_rojo has joined #openstack-tc | 17:53 | |
| dhellmann | tc-members: did anyone have anything to add to the searchlight PTL appointment after ttx's comments? https://review.openstack.org/#/c/590601/ | 17:54 |
| * cmurphy 's opinion is unchanged | 17:58 | |
| mugsie | yeah, I think we give the new team a cycle, and see what happens | 18:00 |
| openstackgerrit | Andreas Jaeger proposed openstack/governance master: Add operations-guide repo for Operations Guide team https://review.openstack.org/591248 | 18:01 |
| openstackgerrit | Merged openstack/governance master: Reorganise OpenStack-Ansible deliverables https://review.openstack.org/589446 | 18:02 |
| openstackgerrit | Merged openstack/governance master: Move refstack-client, refstack and python-tempestconf to interop WG https://review.openstack.org/590179 | 18:02 |
| openstackgerrit | Merged openstack/governance master: Add a house rule about how to signal appointed PTLs https://review.openstack.org/590790 | 18:02 |
| openstackgerrit | Merged openstack/governance master: appoint Omer Anson PTL for Dragonflow for Stein https://review.openstack.org/591470 | 18:03 |
| openstackgerrit | Merged openstack/governance master: appoint Sam Yaple PTL of Loci for Stein https://review.openstack.org/591474 | 18:05 |
| openstackgerrit | Merged openstack/governance master: appoint Claudiu Belu PTL of Winstackers for Stein https://review.openstack.org/591476 | 18:07 |
| *** e0ne has joined #openstack-tc | 18:14 | |
| *** lbragstad has joined #openstack-tc | 18:17 | |
| *** tellesnobrega has quit IRC | 18:31 | |
| *** cdent has joined #openstack-tc | 18:34 | |
| *** e0ne has quit IRC | 18:42 | |
| *** mriedem1 has joined #openstack-tc | 18:42 | |
| *** hongbin has joined #openstack-tc | 18:51 | |
| fungi | okay, i think i'm about caught up finally | 18:52 |
| fungi | cmurphy: while the ptl is the "the buck stops here" person for what happens to the compute project, a split-out repository under its own team isn't necessarily happening *in* the compute project (though it might be nice for everyone involved if the plan was for it to be anyway) | 18:53 |
| fungi | mnaser: i can think of a number of reasons why nova-core might not be a member of placement-core even if it's within the nova team as a whole. that's entirely up to the ptl to decide. it might be a little weird, but our governance really says nothing about core review teams in that regard | 18:55 |
| *** annabelleB has quit IRC | 18:58 | |
| *** annabelleB has joined #openstack-tc | 19:02 | |
| *** mriedem1 is now known as mriedem | 19:04 | |
| *** e0ne has joined #openstack-tc | 19:06 | |
| cmurphy | fungi: that was partly my point and i think partly the direction of the conversation (I'll admit I skimmed it), really the placement team could create whatever repositories they want with whatever governance and core structure they want, but what happens to the *compute* project is up to melwitt, and it seems like whether or not nova will willingly consume the split out project is the crux of the | 19:14 |
| cmurphy | question | 19:14 |
| fungi | indeed, i wholeheartedly agree | 19:16 |
| *** dkrol has joined #openstack-tc | 19:16 | |
| efried | The fact that the core teams will greatly overlap should hopefully mitigate that level of drama. | 19:20 |
| efried | if there was any danger of it in the first place. | 19:20 |
| cdent | Is there? | 19:21 |
| efried | Are you asking me? | 19:22 |
| cdent | Not you specifically. It was a question that was raised earlier in the discussion but never really answered | 19:23 |
| zaneb | I feel like we should be focusing less on how to handle a nuclear scenario than on making sure we never get near that scenario coming about | 19:24 |
| dhellmann | zaneb +1 | 19:25 |
| dhellmann | tc-members, do we want to have a "team photo" taken with the TC at the PTG? | 19:25 |
| TheJulia | I think it would be a good idea | 19:25 |
| smcginnis | That might be fun. | 19:25 |
| cdent | I'm confused/concerned that people see "being independent" as nuclear? | 19:25 |
| zaneb | dhellmann: +1 | 19:25 |
| *** e0ne has quit IRC | 19:26 | |
| dhellmann | cdent : the nuclear option is more having some outside body get too involved in what should be a decision by the folks directly involved | 19:26 |
| cdent | rather than something we should be striving for given that we've talked frequently about wanting to make nova smaller/less massive in various dimensions | 19:26 |
| fungi | i'm on the fence about the photo. not sure if that makes us seem more exclusive, or more approachable | 19:26 |
| zaneb | cdent: failing to agree and having a fork, of either placement or Nova or both, with the TC knocking heads together to sort it out is the nuclear scenario | 19:27 |
| zaneb | metaphorically speaking, obviously | 19:27 |
| dhellmann | discussions about how to vote and how to weigh votes makes it seem like the process is being engineered to ensure an outcome instead of just getting folks to agree on a plan like we would for any other change | 19:27 |
| cdent | zaneb: ah okay, if we had not brought it up with the tc at all, yet, would it feel different? | 19:28 |
| cdent | fungi: I agree that photos are weird that way | 19:28 |
| cdent | I tend to not want to do them | 19:28 |
| dhellmann | on the other hand, being married to a historian, I see the value in a record of that sort | 19:29 |
| efried | dhellmann: Realistically, *any* variant of the democratic process will yield the same result. | 19:29 |
| efried | dhellmann: So in the sense that we're trying to get it to *be* a democratic process at all, yes, we're trying to engineer an outcome. | 19:30 |
| zaneb | cdent: it's fine to bring it up! but there has been a lot of discussion along the lines of exactly which powers the TC would invoke to force a decision if we had to, and while that's academically interesting, let's not get to the point where we have to | 19:30 |
| fungi | yeah, i was basically watching the ml thread and waiting for someone to approach the tc collectively | 19:31 |
| dhellmann | efried : in what way is it not democratic now? | 19:31 |
| *** EvilienM is now known as EmilienM | 19:31 | |
| cdent | fungi: as you'll recall, efried approached the tc as a result of joint discussion in the scheduler meeting | 19:31 |
| fungi | i'm also very much in favor of focusing on mediation rather than dictating a solution | 19:31 |
| efried | dhellmann: Well, the other options on the table include "the Nova PTL decides". That's not democratic. | 19:32 |
| fungi | cdent: yep! ;) | 19:32 |
| efried | dhellmann: There's also been an undercurrent of "there exists a vocal minority with effective (if not explicit) veto powers". | 19:32 |
| dhellmann | efried : do you think melwitt would just make that decision on her own without consulting everyone involved? | 19:32 |
| zaneb | efried: PTLs are elected every cycle... | 19:32 |
| efried | nonono, of course not. | 19:33 |
| efried | but | 19:33 |
| efried | might also not take a vote. | 19:33 |
| dhellmann | do you think that minority should not have any say? or that they should just be overruled by a vote? | 19:33 |
| fungi | i'm less interested in any vocal minority with effective veto powers, and more interested in any minority who feels disenfranchised and unable to decide their destniy as a group | 19:33 |
| dhellmann | what is the effective result if they are ignored and the extraction happens? is that somehow going to convince them that it's a good idea after the fact? | 19:33 |
| efried | dhellmann: All extremely good questions, and exactly why we're here. | 19:34 |
| dhellmann | ok, well, I'm waiting to see what happens as you continue to try to convince them, because that seems like the only way forward to me | 19:34 |
| efried | Put another way: *should anyone* have veto powers? If so, based on what criteria? | 19:35 |
| fungi | i have to wonder whether the situation be any better for the nova team if the majority of the placement-only contributors get fed up and go work on something else? | 19:35 |
| efried | fungi: Unfortunately, that's the kind of thing that has led to the current shortage in nova dev/reviewer volume. | 19:35 |
| dhellmann | efried : you're presenting this as "them" trying to force "you" to do something you don't want, but I see it that way from both sides. If there is no compromise position and there is no consensus then there needs to be more discussion. | 19:36 |
| fungi | we've got an established culture of trying not to tell people they can't work on what they want to work on, mainly because that comes with significant risk that they'll work on it anyway but just not include us any longer | 19:36 |
| efried | dhellmann: That's a great ideal. But there will always be situations where complete agreement is not possible. | 19:37 |
| * jroll wants to be clear that when I was talking about an effective veto, I wasn't saying that it will or should happen, just that it's a possible outcome of the nuclear option (the TC making the decision that placement should have separate governance) | 19:37 | |
| dhellmann | consensus is not the same as 100% agreement | 19:37 |
| * jroll didn't mean for it to derail the discussion | 19:37 | |
| fungi | still, better to start from an expectation that a mostly mutually-beneficial compromise can be reached | 19:37 |
| zaneb | jroll: hold up. the nuclear option is the TC making any decision at all | 19:38 |
| dhellmann | ttx's recent vote related to searchlight is a great example of that: He said he opposed the appointment but would live by the decision of the rest of the group. That means we can have consensus. | 19:38 |
| cmurphy | again we actually do have a pretty clear process on this that really doesn't involve the TC at all https://governance.openstack.org/tc/reference/charter.html#project-team-leads | 19:38 |
| dhellmann | cmurphy : exactly | 19:38 |
| jroll | zaneb: sure. though I think my hypothetical effective veto thing only happens with a particular decision | 19:38 |
| smcginnis | I don't 100% buy the PTL argument. | 19:39 |
| efried | smcginnis: ++ | 19:39 |
| dhellmann | smcginnis : "all disputes should be resolved through active debate and discussion" | 19:39 |
| dhellmann | the PTL is the last resort | 19:39 |
| efried | Because the whole point of this discussion is that a hypothetical placement PTL would have different interests than the nova PTL. | 19:39 |
| fungi | cmurphy: that process only necessarily applies if the dispute really is in their team, and not between their team and another group of people who don't want to be in their team | 19:39 |
| jroll | I also want to point out, once again, that this discussion started with efried asking if the TC might be willing to guide the discussion/decision, not step in and make a decision | 19:40 |
| cdent | jroll++ | 19:40 |
| dhellmann | efried : I think you're doing melwitt a disservice by implying that she would not be objective. | 19:40 |
| jroll | 15:29:39 efried | And the idea came up that we could possibly ask the TC to govern the process. Not make the decision - just help us wade through the politics, mechanics, process, etc. | 19:40 |
| smcginnis | PTL is the last resort for the project. But if a group is trying to leave that project, the PTL is just another voice, IMO. | 19:40 |
| smcginnis | jroll: ++ | 19:40 |
| efried | dhellmann: Well, it's not her job to be objective. It's her job to act in the best interests of *nova* - see above. | 19:40 |
| cmurphy | they are free to leave the project but not free to change the direction of that project | 19:40 |
| fungi | completely agree | 19:41 |
| mnaser | i agree with cmurphy | 19:41 |
| fungi | or rather, not free to change the direction of that project without agreement from that project's ptl | 19:41 |
| cmurphy | right | 19:41 |
| smcginnis | Who is trying to change the direction of Nova? | 19:41 |
| *** annabelleB has quit IRC | 19:41 | |
| dhellmann | how is placement going to be successful at all as a separate project if the placement team and nova team can't work together? this step of extract seems like the first of many possible conflicts. | 19:41 |
| efried | Nobody has said the teams can't work together. | 19:42 |
| dhellmann | then why do you need someone from the outside to help make this decision? | 19:42 |
| smcginnis | How is extraction going to stop nova's interaction with placement being much different than it is today. There's a large part of a thought process I'm missing in all this. | 19:42 |
| efried | smcginnis: ++ | 19:43 |
| dhellmann | smcginnis : there seems to be an assumption that the nova team would use the version of placement that is pulled out before they agree. I don't want to make that assumption. | 19:43 |
| jroll | dhellmann: this came up when the placement team was talking during a meeting about how to navigate the decision, if there should be a vote or what: http://eavesdrop.openstack.org/meetings/nova_scheduler/2018/nova_scheduler.2018-08-20-14.00.log.html#l-66 | 19:43 |
| dhellmann | we don't want 2 placement services. | 19:43 |
| jroll | and efried came here asking if the TC would be willing to guide that process, not help make the decision | 19:44 |
| dhellmann | what help is needed, then? | 19:44 |
| smcginnis | If all the folks working on placement are working on the independent one, then I would think anyone that wants to use placement would use the non-stale version of it. | 19:44 |
| jroll | and we kept asking what if until we were all discussing this under the assumption agreement could not be reached | 19:45 |
| efried | dhellmann: We're not asking, "Help us work together." We're good on that. And I definitely don't see the nova team pulling a take-ball-and-go-home and refusing to use the new project - that's silly. We're asking "help us decide how to decide". | 19:45 |
| dhellmann | whether or not placement is ready to be in its own repo is a technical decision. how do you make other technical decisions and why does that approach not work in this case? | 19:45 |
| dhellmann | I'm not even hearing agreement on that point so far | 19:46 |
| jroll | I was under the impression the technical decision of separate repos was agreed upon (and if not, the PTL wants to do it, so I think worst case the ball stops with her) | 19:47 |
| efried | "ready to be in its own repo" is not at question. | 19:47 |
| efried | yeah | 19:47 |
| zaneb | melwitt and dansmith were both in favour of it being in it's own repo, as I understood it. I haven't seen anyone against that yet | 19:47 |
| dhellmann | ok, great! | 19:47 |
| jroll | the governance is the question - does that repo live under the compute umbrella or elsewhere? | 19:47 |
| efried | ^^ | 19:48 |
| dhellmann | so how does the nova team settle other questions of policy and why does that approach not work for making this decision? | 19:48 |
| * jroll wonders how long it has been since nova leadership disagreed on a thing | 19:50 | |
| mnaser | dhellmann: the nova team would like to split it into a project inside the compute team | 19:50 |
| mnaser | however, others feel like that's not enough and would like to move it into its own team | 19:51 |
| dhellmann | ok, and what are the 2 sides doing to resolve that disagreement? | 19:51 |
| efried | Posting on the ML. Discussing in nova IRC meetings. Reaching out to you. | 19:52 |
| *** annabelleB has joined #openstack-tc | 19:53 | |
| zaneb | efried: 'We're asking "help us decide how to decide".' OK, here's how you decide. You talk about the pros and cons until you come up with a consensus everyone can live with, even if it wasn't their first choice. | 19:53 |
| dhellmann | right | 19:53 |
| zaneb | what you don't want to do is take a vote | 19:53 |
| efried | So how do we define consensus? | 19:54 |
| zaneb | because that solidifies people's positions into camps, and that's the opposite of what you need | 19:54 |
| efried | Vote is a way to achieve consensus that people can understand. | 19:54 |
| dhellmann | efried : everyone agrees they can "live by" the outcome, even if they don't necessarily like it | 19:54 |
| jroll | consensus is a decision everyone agrees to live by, even if they don't like the decision | 19:54 |
| zaneb | efried: OpenStack works by the principle of lazy consensus, so we define consensus as when people stop complaining | 19:54 |
| * jroll tosses dhellmann a zinger-brownie | 19:54 | |
| dhellmann | a vote is a way to count | 19:54 |
| dhellmann | it is not a way to reach consensus | 19:54 |
| dhellmann | you can use it to see how people feel about a decision, but a vote has no argumentative power | 19:55 |
| efried | None of that answers the question, except what zaneb says, which is basically that anyone has veto power by not quitting complaining. | 19:55 |
| cdent | point of order here: we can't make consensus if we don't have all the parties involved participating | 19:55 |
| efried | We're never going to get everyone participating in a single venue at the same time. The ML thread has done the best job of flushing out the various voices, and I don't think discussions outside of that have added anything technical to the discussion. | 19:56 |
| cdent | so trying to build consensus _here_ without melwitt, dansmith, jaypipes and, based on recent inputs, members of zun is embedding positions and causing a lot of confusion | 19:56 |
| cdent | efried: I agree. | 19:56 |
| efried | Yeah, I don't want to try to build consensus here! | 19:56 |
| dhellmann | efried : if you have one person who won't come to any agreement, then you have to question whether that person should be involved in the discussion. But I thought more than one person did not agree in this case? | 19:56 |
| efried | I want to understand *how* one would build consensus at all. | 19:56 |
| dhellmann | communicate, discuss, argue -- as zaneb said, make your case and weigh both sides | 19:57 |
| zaneb | efried: if somebody won't stop complaining you need to listen to them until you're sure you understood their concern and addressed it, or until you're very very sure that they're a crank that can/should be ignored | 19:57 |
| efried | dhellmann: Yes, to my understanding, there are two. Neither are heavy contributors to placement code. Both are approaching the topic from the point of view of what's best for nova. | 19:58 |
| dhellmann | is the placement team not concerned about that at all? | 19:58 |
| efried | Yes, which is why we're here. | 19:58 |
| dhellmann | do you think their arguments are completely wrong? | 19:58 |
| mriedem | am i in that group? i'd like to know if i'm assumed to be part of a group w/o actually being asked | 19:59 |
| dhellmann | you should be talking to *them* though, right? you don't need to convince us | 19:59 |
| cdent | mriedem: no, I keep hoping you'll input _something_ | 19:59 |
| efried | not "completely". But not with enough compelling merit to sway it the other way - *in my opinion* | 19:59 |
| mriedem | hey, | 19:59 |
| dhellmann | so it sounds like there needs to be some sort of compromise position | 19:59 |
| mriedem | i've made it through at least the first couple of sentences of the first email | 20:00 |
| mriedem | and etherpad | 20:00 |
| * efried deflects zinger-brownie to mriedem | 20:00 | |
| dhellmann | change is hard, and introduces risk, and risk brings fear. so if you want to make change, you have to show how you're going to deal with the risk involved. doing that is going to require accepting that even if you don't think their position has merit, it still has to be addressed, because that's how you collaborate. | 20:01 |
| cdent | dhellmann: one of the original questions was whether or not a thing which is currently being identified as "the placement team" needs to convince another group (any other group). The discussion here indicates that thay at least should and to have best form must. | 20:01 |
| cdent | The feeling on my part is that if a group wants to be self-determining there's is not to convince to be allowed, but rather to be convinced they should not | 20:03 |
| dhellmann | cdent : I think that the nova team owns this code right now based on our governance structure. the set of people who are contributors to the code intersect with the set of people who are formally on the nova team. and I think the union of those sets needs to reach consensus. | 20:03 |
| cdent | that's not how the conversation has gone thus far | 20:03 |
| cdent | what's happened instead is that as soon as some members of nova said "hmmm, maybe not, people came to a screeching halt" | 20:03 |
| dhellmann | so, go argue with those people | 20:03 |
| *** diablo_rojo has quit IRC | 20:04 | |
| cdent | dhellmann: I'm in this channel because eric came here to ask for advice | 20:04 |
| cdent | and this is where discussion is happening | 20:04 |
| cdent | later I will go argue with whoever needs to be argued with | 20:04 |
| zaneb | it's worth noting that melwitt's position would be more accurately described as "maybe not *yet*" | 20:05 |
| dhellmann | ok, I'm trying to give you that advice | 20:05 |
| cdent | dhellmann: I've not asked for the advice. efried has. | 20:05 |
| efried | There not being officially any such thing as the "placement team" makes it hard to reach "consensus", where that's defined as, "The 'placement team' has heard your objections, taken them into consideration, and tried to mitigate them as best as possible, and has decided to move forward with XYZ anyway." It's a chicken/egg kind of thing. | 20:05 |
| dhellmann | you is plural | 20:05 |
| dhellmann | is it somehow unclear who needs to be involved in the discussion, then? | 20:06 |
| efried | not at all. | 20:06 |
| jroll | efried: "we hear you but are doing it anyway" doesn't sound like consensus to me :/ | 20:07 |
| efried | huh? | 20:07 |
| zaneb | dhellmann: no, no, y'all is plural | 20:08 |
| dhellmann | zaneb : y'all is also plural, yes | 20:08 |
| efried | jroll: oh, you mean the part where "I don't like it but I can live with it" is consensus, but "I don't like it" is veto. Right. That's a problem IMO. | 20:08 |
| dhellmann | which I guess makes "all y'all" meta-plural? | 20:08 |
| jroll | efried: sorry, maybe I misread, but it sounds like you're defining consensus as "The 'placement team' has heard your objections...and has decided to move forward with XYZ anyway." | 20:08 |
| scas | n.b. "all y'all" is the plural form -- "y'all" can refer to singular or plural | 20:09 |
| zaneb | scas: false | 20:09 |
| dhellmann | the thing all y'all need to agree on is not "can placement be its own team" but "will nova use the placement service after it is managed by another team" | 20:09 |
| efried | jroll: The stuff in the ... is important too, but yes; that's the middle ground zaneb mentioned above. | 20:09 |
| dhellmann | because the first question does not need anyone else's input, but is moot if the answer to the second question is no | 20:10 |
| efried | dhellmann: That answer is certainly yes. | 20:10 |
| dhellmann | is it? | 20:10 |
| dhellmann | then what's the problem exactly? | 20:10 |
| efried | "consensus" that it should be done. | 20:10 |
| efried | complaining == veto | 20:10 |
| dhellmann | ah, but if you do not have consensus on the second question, then you have not agreed | 20:10 |
| efried | The second question is not the one we need consensus on. | 20:11 |
| efried | It's the question of "should we extract, and how far?" | 20:11 |
| dhellmann | oh, I think you're wrong on that | 20:11 |
| scas | zaneb: i'm only going on the time i lived in the southern US | 20:11 |
| cdent | efried: I believe what dhellmann is trying to say is: you can fork if you want to, but will anybody use it? | 20:11 |
| dhellmann | because forking placement and not having nova delete the old copy seems pretty pointless | 20:11 |
| dhellmann | not just anybody. will the existing users use it? | 20:12 |
| efried | I really, really don't believe anyone has said or even implied that they would not use an extracted placement service. cdent, true? | 20:12 |
| cdent | I've heard no one say that anywhere, except in this channel | 20:13 |
| dhellmann | is that not implied by the sentiment that it isn't ready to be extracted? | 20:13 |
| efried | I don't think so, no. Maybe I'm misunderstanding something. | 20:13 |
| dhellmann | maybe we should ask that question of the people who think it isn't ready, then | 20:14 |
| smcginnis | Again, I think everyone is in agreement that extraction to its own repo is fine, from what I've seen. | 20:14 |
| dhellmann | would they help make the extracted version work? would they deprecate/delete the old one? | 20:14 |
| cdent | efried: it _may_ be. if people believe that "concurrent developement" is required, then they will do that | 20:14 |
| smcginnis | It's a question of ownership. | 20:14 |
| zaneb | placement and Nova both need each other. the solution isn't to be found in defining the group of 'placement developers' so they can decide, which is another way of saying defining the people who are not placement developers and therefore don't get a say | 20:14 |
| zaneb | the solution is everyone agreeing together | 20:14 |
| cdent | Is it perhaps the case we all talking out the sides or our mouths and being mealy-mouthed? I dion't know if we are, but it certainly feels like we're behind some vaseline or something. | 20:15 |
| cdent | because we keep going around in circles | 20:15 |
| jroll | perhaps it's the case that we're all making assumptions about the anti-placement-in-its-own-governance people's motivations, because they aren't talking here | 20:16 |
| cdent | perhaps | 20:16 |
| mriedem | i would benefit from less fox news-style "i've heard" and "people are saying" and just state things directly | 20:17 |
| cdent | that would be nice | 20:17 |
| mriedem | re: my question above about which group i'm perceived to be in | 20:17 |
| cdent | mriedem: still none | 20:17 |
| cdent | nobody knows | 20:17 |
| cdent | which is fine | 20:17 |
| mriedem | note: i accept nazi gold | 20:18 |
| smcginnis | mriedem: That's for you to define. | 20:18 |
| mriedem | too soon? | 20:18 |
| cdent | mriedem: apparently you've brought things to a crashing halt, anything else to add? | 20:20 |
| mriedem | i assume everyone in this channel is just exhausted at this point, | 20:21 |
| mriedem | since this convo started several hours ago | 20:21 |
| *** diablo_rojo has joined #openstack-tc | 20:21 | |
| mriedem | and i was out for a few hours, and then it's still going | 20:21 |
| mriedem | so assuming people are taking a break | 20:21 |
| cdent | fair enough | 20:22 |
| * cdent eats some cookies | 20:22 | |
| mriedem | in general, i think we all know placement is going into it's own repo, that was the plan from the start | 20:23 |
| mriedem | governance was never really talked about until now, at least not publicly | 20:23 |
| mriedem | i wasn't around for nova-volume becoming cinder so don't really know what that experience was like | 20:23 |
| mriedem | plus, what came first? ironic or the nova-bm driver? | 20:23 |
| mriedem | jroll: ^? | 20:24 |
| jroll | mriedem: nova-baremetal was first | 20:25 |
| dtroyer | FWIW, I really think trying to compare this to nova-volume -> cinder is not worth it, darn near everything was different back then except we used Python… | 20:25 |
| jroll | mriedem: and nova very much wanted it out, there was no disagreement, heh | 20:25 |
| jroll | other than like... upgrade procedures/testing/whatever | 20:25 |
| mriedem | jroll: in folsom/grizzly the upgrade procedure would have just been, "upgrade everything at the same time else dragons" | 20:26 |
| jroll | mriedem: sorry, migration not upgrade | 20:26 |
| jroll | sean and dan very much did not want to screw the users over | 20:27 |
| zaneb | dtroyer: +1. I think that was being used as a proxy for figuring out the mechanics of voting or whatever, but that isn't where the solution lies. The solution lies in finding out why people disagree about the next step to take. | 20:27 |
| fungi | at this point what i'm hearing is that at least some contributors working on the placement service feel under-represented in the decision-making body which controls it, and would like more control over the direction of the service. i concur we've heard little argumentation yet from people who feel that's a bad idea, but also agree we aren't the ones they (either contingent) should be trying to convince | 20:31 |
| fungi | at this stage | 20:31 |
| cdent | fungi: that is probably a latent concern, but isn't one of the main ones that have been broadcasted. where lack of representation has been expressed as more of a concern is with non-nova consumers of placement (real and potential) such as zun or cinder | 20:34 |
| cdent | who are in the group of potential contributors | 20:34 |
| mriedem | i personally think placement on its own governance-wise makes sense, if it's meant to be consumed by multiple projects (cyborg, cinder, neutron, ironic, cyborg, at least) and it has its own entry in the service catalog; the fear is a new leadership team taking it in a radically different direction wrt things like microversions (they are annoying so let's not use them) or not having the same types of concerns about upgrades | 20:35 |
| mriedem | cdent: i know you're no fan of microversions | 20:36 |
| cdent | so: a goal with independent governance is trying to build in equal treatment of all potential services | 20:36 |
| mriedem | also, | 20:36 |
| cdent | mriedem: that's not _quite_ accurate. I wouldn't get rid of them at this point. | 20:36 |
| cdent | I think _if_ there were any change with regard to microversions, it would be "needing a spec for every single one" and the commitment to CD that they sometime imply | 20:37 |
| fungi | cdent: if under-representation in the present governing body is only a latent concern, then what other reasons are there to form a separate team? to me, that's pretty much the only thing you get by having your own governance: self determination | 20:37 |
| cdent | but nobody has said "let's do that". that's just things I've said at various times, and I'm not in charge | 20:37 |
| mriedem | cdent: no, but if placement is on its own and you run for and are elected as ptl, | 20:38 |
| smcginnis | Self determination and the potential for others to join that wouldn't if it was part of nova. | 20:38 |
| cdent | fungi: what I said: to build in equal treatment of all potential services | 20:38 |
| mriedem | you could say, "i don't think we should do microversions, or have a spec for all of them" | 20:38 |
| melwitt | I think placement on its own governance-wise makes sense *at some point* but not *now* being that we are still tightly coupled and still have not implemented the features we *need* in placement | 20:38 |
| melwitt | it makes no sense to me to split them out in different directions right now | 20:38 |
| cdent | mriedem: do you think after all this time that I would not be consensus oriented? I'm painfully consensus oriented | 20:38 |
| smcginnis | melwitt: Are you concerned they would not be implemented? | 20:39 |
| mriedem | cdent: i have a hard time knowing which end of the spectrum you're on at times, | 20:39 |
| mriedem | wrt design philosophy vs just getting something done | 20:39 |
| mriedem | the main contributors to placement, namely cdent, jaypipes and efried, are all highly opinioned individuals | 20:40 |
| melwitt | smcginnis: I wouldn't go that far, but I think of this like an org structure. if you separate things into different orgs that could have different goals, you are reducing the ability of things to get done efficiently and cooperatively | 20:40 |
| fungi | cdent: if you don't feel that you can build in equal treatment of all potential services while under the current governance, then that's exactly as i stated. you seek self-determination so that you may choose that path | 20:40 |
| cdent | mriedem: I think you're pretty aware of the stuff I've actually implemented, as different from things I'm willing to talk about | 20:40 |
| cdent | I'm willing to consider plenty of things | 20:41 |
| mriedem | melwitt: we probably need a define a list of what nova needs that's not done yet | 20:41 |
| mriedem | if we're going to use that as a reason for keeping it in compute for governance | 20:41 |
| melwitt | mriedem: yep, I think we should. I listed some in my ML responses | 20:41 |
| smcginnis | melwitt: I could see that in poorly run orgs, but I would hope with open source that would not be an issue. | 20:41 |
| melwitt | multi-cell affinity is a big one that I know Oath needs. we need NRP integration for vCPUs, NUMA, dedicated CPUs | 20:42 |
| jroll | smcginnis: to mel's point, it took a long long time for nova and ironic to work well together, even though we had some common goals | 20:42 |
| cdent | melwitt: those are indeed feature we all want to see happen, but how/why is there a coupling between nova and placement on those things? | 20:43 |
| melwitt | smcginnis: I wouldn't say it's only for "poorly run orgs". it's just what happens when you separate things under different goals, they will not be working together as well as they would under a common goal and direction | 20:43 |
| mriedem | it took a long time to get volume multiattach done across 2 teams and 2 apis too, but we didn't really argue about stuff, it was just a lot of cooks in the kitchen | 20:43 |
| cdent | assuming the nature of the current interface | 20:43 |
| cdent | melwitt: and why is it you feel that a repo in nova governance is easier to manage than one that has it's own governance? what's the barrier there? | 20:44 |
| mriedem | people | 20:44 |
| * fungi wonders to what extent within openstack any team necessarily works with a common goal and direction | 20:44 | |
| mriedem | it's about people | 20:44 |
| mriedem | this whole debate is about people | 20:44 |
| cdent | say more please mriedem | 20:44 |
| efried | melwitt: I agree collaboration is needed for those things, but only one of them requires new placement work - the rest need nova to implement the client side of what's already been done in placement. And I (still) don't see collaboration suffering as a result of this move. | 20:44 |
| mriedem | if we rename placement, let's name it soylant | 20:44 |
| melwitt | cdent: there's a coupling because it will take iteratively landing things on either side to get it right. we know this. and I think it makes the most sense to keep us under one common group to do that with the least amount of friction | 20:45 |
| zaneb | melwitt: do you feel like the number of shared personnel might help to mitigate that in this case? | 20:45 |
| cdent | we're already under one common group: openstack? | 20:45 |
| melwitt | zaneb: it might. but looking at it from a higher level, I don't see how it makes sense to separate into separate groups under separate governance while this type of development is happening | 20:46 |
| zaneb | efried: I replied to your email with a list of questions y'all can try asking each other to try to move closer to consensus | 20:47 |
| efried | zaneb: Thanks. | 20:47 |
| mriedem | melwitt: by multi-cell affinity do you mean just modeling affinity in placement in general? | 20:47 |
| jroll | so it sounds like a concern is silos between teams, which is historically a problem in openstack. I wonder if there's something we can do to ensure that doesn't happen | 20:47 |
| melwitt | we are not all tightly coupled under "openstack". we created placement to solve specific problems in nova and we are still right in the middle of solving those problems, in nova, with placement. and we still need specific features in placement. so it doesn't seem like the time to split it out as completely separate | 20:48 |
| melwitt | I think eventually it will be completely separate and that's a vision we all have, but I don't think _now_ is the time for that | 20:48 |
| efried | I don't agree we're in the middle. | 20:48 |
| mriedem | as efried said, i thought we had the things in place in placement with NRP to already support numa and pcpus? | 20:48 |
| cdent | melwitt: if we keep waiting until nova is "done" with placement we will never extract. at the moment placement is well ahead of nova | 20:48 |
| melwitt | you don't think multi-cell affinity and shared storage support is in the middle? | 20:49 |
| mriedem | the missing piece was the nova client side stuff for numa and pcpu | 20:49 |
| cdent | so now is a good time to break, if we ever plan to | 20:49 |
| melwitt | I disagree | 20:49 |
| cdent | melwitt: was that in response to me or matt? | 20:49 |
| mriedem | we don't have a concrete plan for modeling affinity yet do we? | 20:49 |
| melwitt | cdent: no, sorry. it was in response to "now is a good time to break" | 20:49 |
| mriedem | b/c that problem is f'ing hairy | 20:49 |
| efried | melwitt: For nrp and shared storage, I think the placement side is done - certainly done enough that tweaks can be developed whether we're together or separate, even if it consumed a lot of resources to split. | 20:50 |
| melwitt | mriedem: we don't | 20:50 |
| mriedem | efried: i'd agree with that | 20:50 |
| mriedem | the shared storage stuff is problems in nova | 20:50 |
| mriedem | as far as i know | 20:50 |
| zaneb | cdent: what does the word 'extraction' mean in that context? | 20:50 |
| efried | melwitt: WRT NUMA affinity, what mriedem said. We're pretty far from even having conceived a solution to that. | 20:50 |
| efried | but again, extracting placement shouldn't prevent us from developing that solution. | 20:50 |
| cdent | zaneb: that's a good question. I think that's part of the issue here. But in this case I mean "make placement maximally available to all services" | 20:50 |
| zaneb | extraction like hostage extraction, or extraction like tooth extraction? | 20:51 |
| zaneb | cdent: is that part in dispute? | 20:51 |
| melwitt | I'm talking about just regular affinity, with multiple cells. we are still blocked by the inability to do an "up-call" with a split MQ architecture and we need true affinity modeling in placement to solve that | 20:51 |
| cdent | zaneb: above in response to fungi I suggested that remaining under nova governance puts other projects at a disadvantage for influencing placement | 20:51 |
| mriedem | but we don't have a plan yet for what is needed in placement right? | 20:51 |
| melwitt | not that I'm aware of | 20:52 |
| mriedem | cdent: i wouldn't agree with that | 20:52 |
| mriedem | ironic has gotten stuff in that they needed | 20:52 |
| mriedem | cyborg is working with us right? | 20:52 |
| zaneb | cdent: I think that's a fair concern, and should be a legitimate subject of debate | 20:52 |
| cdent | zaneb: this is somewhat the same as the concern that mriedem was implying before: some parts of nova feel like nova will be at advantage if placement is under its own governance | 20:52 |
| mriedem | cinder is the only team, i'm aware of, that is hesitant to use placement while it's under nova governance | 20:52 |
| mriedem | some parts of *openstack*? | 20:53 |
| mriedem | neutron is cool with using placement since routed networks | 20:53 |
| mriedem | in like pike? | 20:53 |
| efried | What we heard from Zun, it sounds like they might be hesitant too - or at least prefer a world where their patches/blueprints would get as much attention as Nova's. | 20:53 |
| mriedem | might have been ocata | 20:53 |
| fungi | though it does seem like once placement reaches the point at which it can be installed separate from installing nova, so that other projects can more easily declare a dependency on it in so-called "stand-alone" deployment contexts | 20:53 |
| cdent | I'd like to hear more from zun and blazar and cyborg when we have the chance | 20:53 |
| zaneb | cdent: like mnaser said earlier, I'm not totally convinced that most people would even know the difference though | 20:53 |
| cdent | zaneb: what fungi just said | 20:54 |
| cdent | the dependency weight of being 'in nova' creates a huge python import debt | 20:54 |
| mriedem | ok so it's that other projects don't feel their requirements are being met and we (nova specs core) aren't spending time reviewing their proposals | 20:54 |
| fungi | being separately installable doesn't necessarily mean separate governance however | 20:54 |
| melwitt | there are a number of things that are "done" in placement already, but I expect that a flurry of bugs may shake out when we integrate, and I think it would be helpful to go through that process as one group, as well | 20:54 |
| mriedem | fwiw, i don't know of any cinder or zun specs to nova for placement that are being ignored | 20:54 |
| mriedem | do they exist? | 20:54 |
| fungi | python-novaclient can be installed separately from nova, yet is governed by the same team (as a crude example) | 20:54 |
| mriedem | or are they magical "if you extract they will come"? | 20:55 |
| mnaser | i mean my argument was does anyone even know who owns os-vif and os-brick? | 20:55 |
| mriedem | i do :) | 20:55 |
| zaneb | cdent: oh yeah, it totally needs to be a separate repo, and there is consensus on that. everybody here is on board | 20:55 |
| mnaser | mriedem: most probably don't :p | 20:55 |
| mriedem | it should be on the quiz | 20:55 |
| cdent | mriedem: maybe the specs don't exist becuase people have given up? I don't know about that kind of thing with regard to placement, but I'm certainly aware of that with lots of nova features | 20:55 |
| cdent | cf starlingx | 20:55 |
| cdent | (to name just one example) | 20:56 |
| mriedem | starlingx has put up nova specs, | 20:56 |
| mriedem | which have had thoughtful review | 20:56 |
| mriedem | that doesn't mean we should accept them though | 20:56 |
| cdent | sure | 20:56 |
| mriedem | s/starlingx/windriver/ | 20:56 |
| zaneb | efried: you can also read hongbin's email as carefully but not directly saying that he doesn't care whose governance it's under as long as it doesn't ignore their patches | 20:56 |
| smcginnis | Are there any challenges to creating an openstack/placement and openstack/placement-specs repo and getting that moved out, then having a placement-core group created that can contain nova-core, at least to start? | 20:57 |
| mriedem | hongbin: you're here right? | 20:57 |
| hongbin | o/ | 20:57 |
| cdent | smcginnis: we've already established that's going to happen | 20:57 |
| mriedem | hongbin: what changes does zun need in placement that are being ignored by nova-core today? | 20:57 |
| smcginnis | cdent: Including a -specs repo? | 20:57 |
| hongbin | mriedem: we haven't started adopting placement yet, so we don't have any patch so far | 20:58 |
| cdent | smcginnis: the earier discussion said not a specs repo, if the initial assumption is under nova (so uses nova-specs)_ | 20:58 |
| cdent | smcginnis: at this point there are only two or three pending specs that involve change in placement itself | 20:58 |
| dhellmann | maybe that point need further discussion, then. it seems like an opportunity for compromise and planning ahead. | 20:58 |
| cdent | and the hope/expectation is that we can/will slow down to allow the nova-side to catch up | 20:58 |
| mriedem | but we haven't fully gotten around to stein specs time yet | 20:58 |
| mriedem | they will come | 20:58 |
| zaneb | dhellmann++ | 20:59 |
| cdent | and we should stop them because we didn't finish _anything_ on the nova side with regard to placement | 20:59 |
| mriedem | in rocky? | 20:59 |
| mriedem | consumer generations was added to placement in rocky and nova is using it | 21:00 |
| efried | nope | 21:00 |
| mriedem | alloc candidates member of is being used | 21:00 |
| mriedem | by the nova pre-request filtering stuff | 21:00 |
| mriedem | allow reserved equal to total | 21:00 |
| mriedem | i see several things done on both sides in rocky | 21:01 |
| mriedem | forbidden traits | 21:01 |
| mriedem | optionaly placement db | 21:01 |
| mriedem | *optional | 21:01 |
| cdent | sorry, I've over generalized. we didn't finish near as much as we planned. I'm not sure why that's super relevant here, though, other than pointing out my logic flaw | 21:01 |
| mriedem | that's my point | 21:02 |
| mriedem | i'm not sure what else was planned for rocky that didn't get done | 21:02 |
| TheJulia | For my understanding, how is nova sizing/planning work? | 21:03 |
| efried | Consumer gen (https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:consumer_gen), reshaper (https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/reshape-provider-tree), nrp in allocations (https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:use-nested-allocation-candidates)... | 21:03 |
| mriedem | for the tc people in here that don't work on nova, | 21:03 |
| mriedem | i don't want generalizations to lead them to believe what reality is in nova | 21:03 |
| mriedem | or what's getting done | 21:03 |
| efried | Shared storage (aborted attempt in libvirt) | 21:04 |
| mriedem | sure, that was never a blueprint right? | 21:04 |
| mriedem | it wasn't a concerted effort, | 21:04 |
| efried | For some values of "never". | 21:04 |
| mriedem | and i'm pretty sure when you guys declared mission accomplished i said, "let's maybe test it first" | 21:04 |
| cdent | mriedem: we did some detailed progress on things, but didn't progress on the big picture of nested resourece providers or shared providers as the big main selling points | 21:04 |
| efried | To give a concrete example, IMO the reshaper series could have been completed in rocky if we had had a couple more qualified core reviewers early on to land the placement side of it. | 21:05 |
| mriedem | efried: sure, but the reason there is a -2 on the api change is to make sure the client side bits are good | 21:05 |
| mriedem | this is why volume multiattach took like at least 3 different APIs in cinder, | 21:05 |
| mriedem | before we had it all working properly on the nova side | 21:05 |
| efried | Yes, and I'm saying the client side could have gotten more, earlier attention if the placement side had been completed earlier. | 21:05 |
| efried | Point being, I don't get this argument that splitting placement out will somehow *slow* progress. | 21:06 |
| mriedem | and if placement were on its own with its own core team, if we found issues in the reshaper API, would those just be considered bug fixes or a new microversion | 21:06 |
| mriedem | anyway, that's theoretical | 21:07 |
| mriedem | efried: i believe what is not being said publicly is that progress could be slowed by a new core team | 21:07 |
| mriedem | with different ideas on what placement, ideally, should be | 21:07 |
| efried | How could it? | 21:07 |
| efried | Hm. | 21:08 |
| mriedem | case in point: the consumer generation fiasco with storing projects and users in placement | 21:08 |
| mriedem | because that's too keystone-y | 21:08 |
| mriedem | here i'm wildly generalizing, | 21:08 |
| mriedem | because i wasn't personally heavily invested in that debate | 21:08 |
| mriedem | i just knew it slowed shit to a crawl for awhile | 21:08 |
| efried | And that would have been... worse with a separate placement-core team? | 21:09 |
| cdent | mriedem: I get your point, but that's wasn't the problem in that case, just to be clear. and presumably we'd still have most of the same existing cores | 21:09 |
| efried | separate/different? | 21:09 |
| efried | Yeah, given that we're talking about at least starting off with placement-core being a superset of nova-core, the same people would be able to land changes as can today. | 21:09 |
| mriedem | and then dansmith and i came in and tried to move forward, burning some bridges in the process | 21:09 |
| cdent | so what you're really saying is: the problem here is that cdent and edleafe being cores is a problem | 21:09 |
| mriedem | i think that's the fear no one is saying | 21:10 |
| mriedem | because feelings can get hurt | 21:10 |
| efried | That's... outrageous. | 21:10 |
| bswrchrd | wow | 21:10 |
| cdent | I think they're more hurtful when it is _not_ said | 21:10 |
| cdent | it is better to address these things out in the open | 21:10 |
| mriedem | after how many hours in this channel talking about this now? :) | 21:11 |
| cdent | it's been obvious since the beginning of the discssuion | 21:11 |
| efried | coming up on 6h, with about 45 minutes for lunch. | 21:11 |
| cdent | do you have this fear mriedem, or are you trying to interpret the fears of other people? | 21:11 |
| mriedem | if the initial placement-core is a superset of nova-core, then i think it's less of an issue | 21:11 |
| zaneb | ok wat just happened here | 21:12 |
| efried | zaneb: Elephant materialized | 21:12 |
| mriedem | cdent: at times i do yes, but less about you - i didn't realize we were talking about ed being core right away | 21:12 |
| TheJulia | zaneb: possibly in the form of a small mushroom cloud | 21:12 |
| mriedem | i'm not sure why everyone else is so aghast | 21:13 |
| efried | mriedem: How about, we're talking about that being a decision for placement-core rather than for nova-core. | 21:13 |
| cdent | mriedem: nobody is making any assumptions about cores at this point, except apparently people being worried that some potential cores can't be trusted | 21:13 |
| mriedem | nobody? | 21:14 |
| cdent | mriedem: the people who aren't core right now that have been mentioned (by efried) are me, edleafe, tetsuro, but since we haven't even made a real plan there's nothing solid. gotta get past the first hurdle, yeah? | 21:14 |
| cdent | it would certainly make sense given commit and review history | 21:15 |
| mriedem | i believe the plan is affected by that concern | 21:15 |
| cdent | yes, I agree with you, and I'm grateful that you've made it visible | 21:15 |
| efried | Yeah, if by "assumptions" you mean it's a foregone conclusion that these people will be made cores, then no. I would expect core nominations and appointments to undergo the same process as for any other team. | 21:15 |
| efried | and as with any other instance of that process, if folks have concerns, they will need to air them explicitly so they can be discussed. | 21:16 |
| efried | Right now it's easy to say "X shouldn't be a nova core" because X is placement-focused. Which is masking whatever real issues people have ^ | 21:17 |
| mriedem | i'd -1 ed for placement core if that helps | 21:17 |
| cdent | I'd like to say publically that working under this cloud for many months has bene exhausting and incredibly dispiriting | 21:17 |
| mriedem | no offense, but if we're being honest | 21:18 |
| cdent | so having the elephant materialized is rather a relief | 21:18 |
| mriedem | subsystems in nova is less a blocking factor, alex and ken'ichi were mostly nova api when made core | 21:18 |
| mriedem | it's more about interactions with the group in addition to be technical experts in their given subsystem | 21:18 |
| mriedem | i.e. is person x going in the same direction as the rest of the team, or are we always arguing | 21:19 |
| cdent | is singlemindedness in a group a virtue? | 21:19 |
| TheJulia | cdent: I would say not a virtue | 21:20 |
| efried | Sure gets things done. But are they the right things? | 21:20 |
| TheJulia | Are they for the common good kind of question | 21:20 |
| efried | Not for nothing, but the lack of singlemindedness is why we're having a hard time right here. | 21:20 |
| mriedem | also, | 21:20 |
| mriedem | i take issue with *all* nova core members at various times, whether i state it publicly or privately or not | 21:21 |
| mriedem | but that's me, and i'm assuming it's true of the others | 21:21 |
| mriedem | and the same in all core teams | 21:21 |
| TheJulia | efried: I'm kind of reading it differently though, and maybe I'm missing context by spending a good chunk of my day focused on other things | 21:22 |
| efried | TheJulia: Heh, lucky you :) | 21:22 |
| bswrchrd | efried: maybe it's not singlemindedness but the ability to compromise? I'm a total outsider since Folsom, it just looks like there's a lot of "it's my way, deal with it" | 21:23 |
| efried | Dissenting voices are necessary for spirited discussion and lead to progress; often to better progress than if everyone thinks the same. | 21:23 |
| efried | bswrchrd: Yes, and that's just what I'm getting at. | 21:23 |
| mriedem | i'm not saying there shouldn't be dissent | 21:23 |
| efried | When the dissenting voice is from someone in a position of power, that gets treated differently than when it's not. | 21:23 |
| mriedem | there frequently is with a general understanding of what the problem is and that it's a valid problem worth fixing | 21:23 |
| mriedem | as i said this morning in the scheduler (placement) meeting (was that today?) | 21:24 |
| mriedem | yesterday? | 21:24 |
| mriedem | i give weight to maintaineres | 21:24 |
| mriedem | *maintainers | 21:24 |
| cdent | it was today but it was days and days ago | 21:24 |
| mriedem | so when it came to the consumer generation kerfuffle between cdent/edleafe and jaypipes, | 21:25 |
| mriedem | not being heavily involved from day 0 but knowing we were blocking progress on stuff, | 21:25 |
| mriedem | i went with who i expected to be around to maintain the thing, which was jay over ed for me | 21:25 |
| cdent | i don't think this is a great example, because in the end it was demonstrated that jay's way was wrong in several ways | 21:25 |
| cdent | and we had to go back to doing it in a way that was more aligned with what ed was trying to accomplish | 21:26 |
| mriedem | i'm likely not caught up on why - is that gibi's ML thread? | 21:26 |
| efried | no | 21:26 |
| cdent | I agree that often jay is the right choice when presented with a choice involving the db, but it's been demonstrated a lot of times that we all have valid input | 21:27 |
| mnaser | forgive me if this might be oblivious but was jay's solution (in that case) the technically better way as agreed by most at the time? | 21:27 |
| mriedem | honestly i'd need to dig up any scheduler meetings where we tried to summarize and shit or get off the pot | 21:28 |
| efried | mnaser: My interpretation is that that was not the tiebreaker | 21:28 |
| cdent | mnaser: I don't know that it matters, and I need to move locations to go home | 21:28 |
| cdent | my family is pulling me away | 21:28 |
| cdent | back in about 30m | 21:28 |
| mnaser | cdent: it's probably getting late there, you should :p | 21:28 |
| *** cdent has quit IRC | 21:28 | |
| mnaser | i'd hope that the decision was just what was deemed to be the better, more correct and technically better solution at the end of the day | 21:30 |
| efried | no, it wasn't, and I think that's a major point here. | 21:30 |
| mriedem | honestly i'll have to go back and read through scheduler meeting logs to put this into context | 21:30 |
| mnaser | mriedem: thanks for looking into that | 21:32 |
| mriedem | so jay's spec change merged on may 21 https://review.openstack.org/#/c/565565/ | 21:33 |
| * edleafe catches up | 21:34 | |
| edleafe | The problem wasn't technical merit. The problem was not working together. | 21:34 |
| mriedem | i don't see anything in the last 3 scheduler meetings about that change before that spec update was merged | 21:35 |
| mriedem | efried asked for status on june 4 http://eavesdrop.openstack.org/meetings/nova_scheduler/2018/nova_scheduler.2018-06-04-14.04.log.html#l-37 | 21:35 |
| mriedem | i complained about it on june 11 http://eavesdrop.openstack.org/meetings/nova_scheduler/2018/nova_scheduler.2018-06-11-14.02.log.html#l-271 | 21:35 |
| edleafe | Instead of working together on the patch series I had been working on, Jay created a whole separate series. | 21:35 |
| mriedem | fin | 21:35 |
| mriedem | i mostly remember "let's not use objects b/c we don't like objects" and jay, dan and me saying "but we use objects to model everything, so let's be consistent" | 21:36 |
| * dims reads scrollback | 21:37 | |
| edleafe | mnaser: the overarching problem was, by Jay's own admission, was that he did it because he knew he could get away with it. | 21:37 |
| mriedem | i assume there is more to the differences in the two series | 21:37 |
| edleafe | mriedem: it was because "we don't like objects" | 21:38 |
| mriedem | that's it? | 21:38 |
| edleafe | it was because they weren't needed | 21:38 |
| mriedem | we use them to model pretty much all data in nova/placement right? including all the stuff before this in placement | 21:38 |
| mriedem | we don't have anything in the api code that just messes with sqla ORM dict-like objects right? | 21:39 |
| edleafe | mriedem: look, I'm not going to re-argue the technical details. The only issue for me was the way it was handled | 21:39 |
| mriedem | well, | 21:40 |
| edleafe | Even if Jay's approach was 100% better, you don't work like that in a community | 21:40 |
| mriedem | if the technical detail was, "hey let's be consistent" and "i don't care about consistency, i'm not changing this" which prompted jay to write an alternate | 21:40 |
| mriedem | that's important informatoin | 21:40 |
| mriedem | i can't speak for jay or what his motives were | 21:41 |
| mriedem | edleafe: i know you are very prone to doing things a particular way per your style concerns, which i've taken issue with in the past | 21:41 |
| edleafe | fair enough | 21:42 |
| edleafe | But you've dealt with that by addressing me and explaining your POV | 21:42 |
| edleafe | Jay stopped responding before I implemented the objects. The only feedback was from others, who thought it was overkill. | 21:43 |
| edleafe | So I reverted, and continued | 21:43 |
| edleafe | All without feedback from Jay | 21:43 |
| edleafe | I got some from Dan, and was implementing what he requested | 21:43 |
| edleafe | When Jay dropped his series | 21:44 |
| edleafe | You really should discuss this with Jay | 21:44 |
| edleafe | He has been very up front about it | 21:44 |
| edleafe | And to relieve your and others' concerns, I'm not really interested in being a core | 21:45 |
| edleafe | I switched a lot of my focus to internal projects after those events | 21:46 |
| edleafe | I don't need that aggravation | 21:46 |
| mriedem | i would have thought at some point within the month and a half before landing jay's updated spec this would have been discussed in the scheduler / placement meeting for those that aren't involved in all discussions in the -placement channel | 21:47 |
| mriedem | as an outsider, i only cared about moving forward | 21:47 |
| mriedem | dealing with the placement crew can be exhausting | 21:47 |
| mriedem | because of the highly opinionated nature of the people working on it | 21:48 |
| mriedem | which is a lot of why i want nova-core at least a subset of the placement-core when it's split out | 21:48 |
| edleafe | mriedem: sorry. At that point I stopped caring. | 21:49 |
| mriedem | that's fair | 21:49 |
| mriedem | just explaining i personally came into the tail end of a shit storm | 21:49 |
| edleafe | I had an opportunity to work on some internal stuff, so I dropped running the scheduler meetings and stopped reviewing | 21:49 |
| mriedem | and wanted to make progress | 21:49 |
| *** annabelleB has quit IRC | 22:00 | |
| *** cdent has joined #openstack-tc | 22:05 | |
| *** zaneb has quit IRC | 22:47 | |
| *** annabelleB has joined #openstack-tc | 22:48 | |
| *** hongbin has quit IRC | 22:49 | |
| *** annabelleB has quit IRC | 23:01 | |
| *** annabelleB has joined #openstack-tc | 23:04 | |
| *** zaneb has joined #openstack-tc | 23:07 | |
| *** tosky has quit IRC | 23:08 | |
| *** annabelleB has quit IRC | 23:37 | |
| *** bodgix has joined #openstack-tc | 23:39 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!