| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-11-14 | |||
| 17:42:56 | dansmith | none of my deeply-rooted concerns are addressed in the discussion | |
| 17:43:19 | dansmith | more definition of how it's expected to be used (although still missing stuff), but nothing about how to provide some affinity | |
| 17:43:42 | dansmith | and I'm super concerned about altering this fundamental part of nova, especially without serious planning | |
| 17:43:51 | bauzas | efried: sounded like people were interested in, including mnaser | |
| 17:44:16 | bauzas | dansmith: that's the reason why we asked to *not* change the notion of a flavor | |
| 17:44:25 | bauzas | a flavor remains a flavor | |
| 17:45:00 | bauzas | they can compose bits of something, but the result of this API is a flavor | |
| 17:45:01 | dansmith | yep, and that helps, but it still brings a lot of complexity to everything that looks at flavors (which is lots of stuff) and also, with no affinity, it's just a toy for single-tenant clouds where everyone is trusted, IMHO | |
| 17:45:26 | efried | dansmith: I all along have assumed that backward compat of current flavor usage would not be affected, period. Agree that part is worth -1ing all day until addressed in the spec. My -2 was for "not worth the effort" -- but if folks are clamoring, I can be persuaded otherwise. | |
| 17:45:35 | bauzas | dansmith: honestly, that's why I don't want this to be in for example POST /servers | |
| 17:45:59 | bauzas | it would be just a os-stuff-my-flavor API, that's it | |
| 17:46:21 | mriedem | aren't you describing basically a flavor template? | |
| 17:46:24 | dansmith | efried: keeping the flavor whole helps the loss of feature, but doesn't help needing to touch everywhere that handles flavors | |
| 17:46:27 | bauzas | mriedem: -ish | |
| 17:46:44 | mriedem | wouldn't a flavor template be a lot simpler? | |
| 17:47:10 | mriedem | create a flavor based on a generic template with extra specs and then override whatever things are unique to that flavor | |
| 17:47:15 | efried | dansmith: Also been assuming/pushing for the composition to happen just once, at spawn time, whereupon all the contents go into the instance's existing flavor record. | |
| 17:47:17 | bauzas | mriedem: that's one of the approaches | |
| 17:47:26 | mriedem | though that doesn't help with the explosion | |
| 17:47:41 | bauzas | mriedem: correct, and we said that too | |
| 17:47:57 | mriedem | nested flavors! | |
| 17:47:59 | efried | That (composition at spawn only) hits POST /servers, but nothing else. No explosion. | |
| 17:48:01 | bauzas | I just feel people want a Domino's Make-My-Pizza generator thingy | |
| 17:48:12 | mriedem | efried: if you add it to spawn people are going to want it in resize also | |
| 17:48:19 | efried | yes | |
| 17:48:31 | bauzas | that's a reasonable concern | |
| 17:48:34 | dansmith | I think people that want the pair-anything-with-anything also don't realize how much that is going to kill their packing and capacity planning, | |
| 17:48:35 | efried | okay, but not "everywhere that touches flavors" (internally). | |
| 17:48:49 | bauzas | dansmith: I exacly had that concern ! | |
| 17:48:56 | dansmith | so when we do that, it will be not very usable even by the people that think they want it, and we will have to iterate | |
| 17:49:14 | bauzas | dansmith: and I said 'well, let's not overthink over that API, it's the operator's responsibility to stuff in it' | |
| 17:49:22 | mriedem | bauzas: do they counter the capacity management argument with "we'll just use watcher to fix things in post" | |
| 17:49:41 | bauzas | watcher never went into discussion | |
| 18:11:06 | openstackgerrit | sean mooney proposed openstack/nova master: block rebuild when numa topology changed https://review.opendev.org/687957 | |
| 18:11:07 | openstackgerrit | sean mooney proposed openstack/nova master: Disable NUMATopologyFilter on rebuild https://review.opendev.org/689861 | |
| 18:37:33 | efried | What does "signed-off-by" actually mean in a commit message, to those who care about it? | |
| 18:38:20 | jroll | efried: it means it was signed by that person's GPG key | |
| 18:38:39 | jroll | wait, no | |
| 18:39:28 | jroll | https://git-scm.com/docs/git-commit#Documentation/git-commit.txt--s | |
| 18:39:46 | efried | specifically for the vtpm patch, which bears almost no resemblance to when it was last touched by cfriesen or Paul-Emile, I'm wondering if I should remove their Signed-off-by lines | |
| 18:40:10 | jroll | I think I would | |
| 18:40:25 | efried | I was actually considering putting it under a new change-id. | |
| 18:40:38 | efried | but decided no harm in having the history in one place. | |
| 18:40:55 | dansmith | efried: S-o-B is a legal construct from the linux kernel community | |
| 18:41:16 | dansmith | efried: it's their accepted mechanism to declare that you have permission to submit the code you're submitting | |
| 18:41:40 | dansmith | some people have hooks in their git config to add it automatically, and/or some orgs may require people to put it in there regardless of the community for some perceived legal shield | |
| 18:42:07 | efried | Okay. So it's really only relevant when it's the same as the uploader for a given patch set, because otherwise it's n/a whether you have permission to submit, because you're not submitting. | |
| 18:42:43 | dansmith | well, not quite | |
| 18:42:47 | efried | Really in the case of openstack gerrit, you've already declared that by signing the things, which are a prereq to being able to submit code at all. | |
| 18:43:01 | dansmith | right which is why it's just noise for our patches | |
| 18:43:04 | dansmith | and really shouldn't be in there | |
| 18:43:33 | efried | ack, makes sense. I'll just axe it. | |
| 18:43:55 | openstackgerrit | Eric Fried proposed openstack/nova master: Add support for resize and cold migration of emulated TPM files https://review.opendev.org/639934 | |
| 18:43:55 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP: Add emulated TPM support to Nova https://review.opendev.org/631363 | |
| 18:44:58 | efried | jroll: I should do a visual inspection quick, but I think the bottom patch ^ is "done" from the impl & docs side. Test is basically not started, but if you want to skim the non-test bits and let me know if anything stands out horribly, that would be helpful. | |
| 18:45:12 | efried | dansmith: I fully expect you to say "split this sucker". | |
| 18:45:13 | jroll | efried: can do today or tomorrow sometime | |
| 18:45:19 | efried | jroll: cool, thanks. | |
| 18:45:36 | dansmith | efried: noted | |
| 18:53:19 | sean-k-mooney | by the way anyone know what might be preventing us form using self.assertRaises in nova as a context manager | |
| 18:53:33 | sean-k-mooney | i have worked around it for now | |
| 18:54:02 | sean-k-mooney | but i suspect we have some legcy code form the py2.6 days | |
| 18:54:44 | sean-k-mooney | im doing "with self.assertRaisesRegex(ValueError, '.*'):" instead for now | |
| 19:07:07 | efried | dansmith, mriedem: offhand, do you have a problem adding a context param to the `unrescue` compute driver method? | |
| 19:07:15 | efried | Will heads-up the ML etc. | |
| 19:07:43 | dansmith | what I have a problem with is notifying the ML when we change an internal interface | |
| 19:07:46 | dansmith | but otherwise, no | |
| 19:08:50 | sean-k-mooney | well its a heads up not asking permission but i get what you mean | |
| 19:08:59 | efried | Heh, it has ever been thus. | |
| 19:09:38 | efried | I have the scars from my initial contact with nova when the oot powervm driver was my whole world. | |
| 19:09:44 | sean-k-mooney | i ment the ml message by they way | |
| 19:10:08 | sean-k-mooney | yes is anyone looking after that now | |
| 19:11:15 | sean-k-mooney | i found out recently a vendor is bypassing the blocks we put in place to prevent people form import stuff form the os-vif internal module | |
| 19:11:17 | efried | yeah, there's a new team struggling to come to grips with it. | |
| 19:11:53 | efried | barely treading water keeping up with nova changes that break it, and still trying to resurrect the CI. | |
| 19:15:56 | mriedem | it's only a problem for tonyb | |
| 19:22:09 | openstackgerrit | Merged openstack/nova master: Filter duplicates from compute API get_migrations_sorted() https://review.opendev.org/636224 | |
| 19:24:28 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Block deleting compute services with in-progress migrations https://review.opendev.org/694389 | |
| 19:30:04 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Block deleting compute services with in-progress migrations https://review.opendev.org/694389 | |
| 19:43:00 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Fail compute service delete if resource provider delete fails https://review.opendev.org/678100 | |
| 19:52:25 | openstackgerrit | Merged openstack/nova master: Start functional testing for cross-cell resize https://review.opendev.org/636253 | |
| 19:52:34 | openstackgerrit | Merged openstack/nova master: Helper to start computes with different HostInfos https://review.opendev.org/686832 | |
| 20:11:13 | mriedem | dansmith: can you hit these 3 bug fix backports to train from gibi https://review.opendev.org/#/q/owner:balazs.gibizer%2540est.tech+status:open+project:openstack/nova+branch:stable/train ? | |
| 20:11:25 | mriedem | i think at least 2 of those still have to go to stein | |
| 20:14:22 | efried | mriedem: grenade seems very ill lately. Do we have any idea what the deal is, yo? | |
| 20:16:22 | dansmith | mriedem: so, there was a bug recently under security review that makes me think about this stuff now... | |
| 20:16:46 | mriedem | efried: yes | |
| 20:16:54 | mriedem | efried: have you seen my recent state of the gate thread? | |
| 20:17:14 | mriedem | dansmith: the qos ports stuff? | |
| 20:17:21 | efried | mriedem: Recent like a week or two ago? Yes. | |
| 20:17:28 | mriedem | efried: yeah halloween | |
| 20:17:30 | dansmith | mriedem: any chance the user could provide someone else's port id and get access to it or even just validate that they guessed right? | |
| 20:17:33 | mriedem | efried: same problems, no progress | |
| 20:17:38 | efried | mmph | |
| 20:17:50 | dansmith | mriedem: I'm not sure what the actual call path on this actual patch is, | |
| 20:17:57 | mriedem | dansmith: provide where? during server create? | |
| 20:17:59 | dansmith | but the move to using an admin client makes me think.. | |
| 20:18:14 | dansmith | mriedem: either there or anything that calls this | |
| 20:18:30 | mriedem | ports are under a project so you'd have to be able to GET the port given your token | |
| 20:19:02 | mriedem | fwiw we use admin client all over the place for dealing with ports b/c the binding stuff is admin-only by default policy in neutron | |