Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-02-28
17:02:04 gibi mriedem: OK
17:07:33 openstackgerrit Matt Riedemann proposed openstack/python-novaclient master: Add support for microversion 2.70 - expose device tags https://review.openstack.org/636779
17:07:39 mriedem melwitt: can you look at ^ again
17:07:46 mriedem takashin's comments should be addressed
17:08:13 melwitt yep, looking
17:09:09 mriedem dansmith: you want to send cells v1 docs to their watery grave? https://review.openstack.org/#/c/636718/
17:10:02 openstackgerrit Matt Riedemann proposed openstack/nova stable/rocky: Avoid BadRequest error log on volume attachment https://review.openstack.org/640110
17:10:03 dansmith mriedem: only if I can go with them
17:10:35 mriedem i'm struggling to make an under-the-sea merman joke here
17:11:02 mriedem https://i.imgur.com/qiJRWMM.gif
17:14:16 melwitt lol
17:14:59 mriedem gibi: oh i guess jay is reviewing the port detach / deallocate change, so feel free to respin the pci request one
17:15:29 gibi I did the fix locally, and I will publish it before I leave. which is in ~15 minutes
17:16:07 openstackgerrit Matt Riedemann proposed openstack/nova stable/queens: Avoid BadRequest error log on volume attachment https://review.openstack.org/640116
17:16:31 mriedem gibi: ok then we have 3 more patches to get to what i think is the target goal for stein which is the microversion change
17:16:37 mriedem how are you feeling about the rest of the changes to that point?
17:17:21 gibi mriedem: correct. If we can merge the microversion patch then I'm happy. However heal port allocation is _after_ the microversion patch so that might make people sad
17:17:40 mriedem i think that is backportable
17:17:44 mriedem since it's an edge case
17:17:54 gibi mriedem: yeah, I hope so
17:18:14 gibi mriedem: the microversion patch itself is small and formal but needs some API doc
17:18:23 gibi mriedem: however I can add doc after FF
17:18:42 mriedem sure. i imagine we'll want some more involved docs about this somewhere, probably nova user docs
17:18:53 mriedem because the spec is going to be overwhelming for a user to try and figure out how this all works
17:18:54 stephenfin mriedem: Missed the ping earlier, but I'll take a shot at https://review.openstack.org/#/c/567860/ tomorrow
17:19:10 stephenfin notifications on Cinnamon suuuuck
17:19:10 gibi mriedem: rubasov started creating a networking doc for the whole
17:19:20 gibi mriedem: I will add to it
17:19:39 sean-k-mooney stephenfin: you dont like the way they pop up in the corner of the screen
17:20:02 stephenfin sean-k-mooney: Not at all. It's pretty but they're no in your face enough
17:20:14 stephenfin Nor are they duplicated across all screens
17:20:27 gibi mriedem: the other two patches handing an edge case (two PF on the same compute connected to the same physnet) and it needs an extra tag in the passthrough_whitelist config
17:20:35 sean-k-mooney stephenfin: well that is why i like them i hate os notification and i tolerater there because they are non intrusive
17:20:55 gibi mriedem: stephenfin has some issue with that which I trying to explain away right now
17:21:41 openstackgerrit Chris Friesen proposed openstack/nova master: Add emulated TPM support to Nova https://review.openstack.org/631363
17:22:46 cfriesen This ^ should be ready to review now
17:25:29 mriedem cfriesen: throw it in runways
17:25:34 mriedem https://etherpad.openstack.org/p/nova-runways-stein
17:25:56 mriedem kashyap: have you looked at this at all? https://review.openstack.org/#/c/637834/
17:26:04 mriedem i know you like to think about cpu models
17:28:17 gibi stephenfin: I've just replied to your concerns about the pf_interface_name tag in https://review.openstack.org/#/c/625311/25/doc/source/admin/networking.rst@266
17:29:33 openstackgerrit Balazs Gibizer proposed openstack/nova master: Record requester in the InstancePCIRequest https://review.openstack.org/625310
17:29:59 gibi mriedem: ^^ fixed
17:30:51 mriedem gibi: are you sure? https://review.openstack.org/#/c/625310/28..29
17:30:55 mriedem you only changed the commit message
17:31:01 gibi mriedem: looking
17:31:11 gibi forget to add the cahnge to the commit
17:31:12 gibi :/
17:31:25 openstackgerrit Balazs Gibizer proposed openstack/nova master: Record requester in the InstancePCIRequest https://review.openstack.org/625310
17:31:27 mriedem git review should not allow you to push if you have pending local changes
17:31:29 mriedem but ok :)
17:31:46 mriedem i get a rebase conflict if i try doing that
17:31:57 gibi mriedem: I never tried to use git review as that hides to much
17:32:08 mriedem so you're both ahead of your time,
17:32:10 mriedem and stuck in the past
17:32:32 gibi :D
17:32:33 gibi yeah
17:32:35 gibi sort of
17:33:15 gibi I hope it is good now as I have to run
17:33:18 gibi talk to you tomorrow
17:33:26 mriedem it's not, but i'll fix it :)
17:33:47 gibi mriedem: OK, thanks :)
17:33:58 melwitt fore
17:34:08 openstackgerrit melanie witt proposed openstack/nova master: Add get_counts() to InstanceMappingList https://review.openstack.org/638072
17:34:08 openstackgerrit melanie witt proposed openstack/nova master: Add online data migration for populating user_id https://review.openstack.org/633351
17:34:09 openstackgerrit melanie witt proposed openstack/nova master: WIP Count instances from mappings and cores/ram from placement https://review.openstack.org/638073
17:34:10 openstackgerrit melanie witt proposed openstack/nova master: Use instance mappings to count server group members https://review.openstack.org/638324
17:34:34 mriedem i laugh at your measly 4 patches
17:35:11 melwitt hmph!
17:35:33 mriedem need i remind you https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/cross-cell-resize
17:35:47 melwitt no, I know I can't compete
17:48:03 openstackgerrit Matt Riedemann proposed openstack/nova master: Record requester in the InstancePCIRequest https://review.openstack.org/625310
18:09:34 mriedem for people to think about prior to the nova meeting http://lists.openstack.org/pipermail/openstack-discuss/2019-February/003356.html
18:18:48 openstackgerrit Merged openstack/nova master: ironic: partition compute services by conductor group https://review.openstack.org/635006
18:24:29 aspiers efried, mriedem: is this the new understanding? https://pasteboard.co/I3hSwZ5.jpg
18:25:31 efried aspiers: couple things...
18:26:40 efried CUSTOM_ traits owned by drivers are not deprecated (did you mean "discouraged"?). There will always be custom traits for things that are dynamic in nature. To use an example that some people hate, CUSTOM_<PCI_ADDRESS>
18:27:02 aspiers gotcha, I didn't know about those
18:29:07 efried aspiers: When you include the bottom middle bubble in the "things manipulated by admin", you mean that it's *possible* for them to muck with it, but they shouldn't, and we'll "heal" it, per your note at the top.
18:29:23 aspiers right
18:29:34 aspiers I'll clarify that
18:31:07 efried Cool.
18:31:08 efried The only other note is use of the word "never" on the right hand side. The top two middle bubbles are supposed to be "exclusive" - i.e. traits that are owned by the driver are a *subset* of the traits the driver will actually *set*.
18:31:38 efried aspiers: So like, I'm not sure if you did this on purpose, but the space in the intersection of the big bubbles, but outside of the three middle bubbles, is that set.
18:32:26 efried ...assuming that yellow bubbles are things that are set, and stuff outside of yellow bubbles is things that are unset.
18:32:43 efried Now in theory, the driver will "always" know what's in that set, and "always" switch off a trait from that set if the admin switches it on.
18:33:01 efried But knowing the full list of things in that space is... hard.
18:33:01 aspiers ah no, stuff outside yellow bubbles is unspecified other stuff, or nothing at all
18:33:13 efried okay, then does what I'm saying above make sense?
18:33:21 aspiers my brain hasn't grokked it yet
18:33:25 aspiers give me a few secs :)
18:34:09 efried There's a set of traits the driver owns. A subset of that will be turned on (by the driver). Anything in there that's turned on by the driver, and turned off by the admin, will get turned back on. Conversely, anything in there that's *not* turned on by the driver, but turned on by the admin, is *supposed* to be switched back off by the driver.
18:34:13 aspiers hrm, you are saying the driver will set traits which it *doesn't* own?
18:34:46 efried no, I'm saying it will switch *off* traits that it *does* own but doesn't think *should* be on. I.e. same logic as for the capability traits.
18:35:26 efried but I have low confidence that drivers will succeed in doing that with 100% accuracy.
18:37:51 aspiers Still not sure I understand. Is your point that outside of the new caps->traits code, there are other driver-owned traits for which the driver *should* override admin changes, but currently might not?
18:37:58 efried What we really ought to do is come up with a namespacing convention so that this ^ can be done more accurately. E.g. compute is allowed to switch off anything set by the admin that's [CUSTOM_]COMPUTE_*. And conversely, compute has to leave alone anything not in that namespace that the admin sets.
18:38:17 efried aspiers: Well, yes, "currently might not" because bug, not by design.
18:39:57 efried A pedantic example: Let's say compute decorates a pGPU provider with CUSTOM_PCI_ADDRESS_00_01_02_03. Obviously it should be nonsensical for the admin to decorate the same RP with a trait like CUSTOM_PCI_ADDRESS_FF_AA_BB_CC. So compute should notice that second one and switch it off.
18:40:09 efried but how will it know?

Earlier   Later