| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-10-01 | |||
| 18:10:56 | melwitt | mriedem: sure | |
| 18:13:27 | openstackgerrit | Merged openstack/nova stable/train: make virtual pmem feature compatible with python3 https://review.opendev.org/685742 | |
| 18:25:05 | openstack | Launchpad bug 1715374 in OpenStack Compute (nova) "Reloading compute with SIGHUP prevents instances from booting" [High,In progress] - Assigned to Ralf Haferkamp (rhafer) | |
| 18:25:05 | sean-k-mooney | efried: can i mark this as fix released https://bugs.launchpad.net/nova/+bug/1715374 | |
| 18:25:35 | sean-k-mooney | it should be in rc1 right as of https://github.com/openstack/nova/commit/73f1fda7e93325d3ca2b2c62afb17fe011d650f3 | |
| 18:26:30 | efried | sean-k-mooney: Yeah, that makes sense, please do. | |
| 18:29:51 | sean-k-mooney | cool im doing some downstream bug traige and linking them to the upstream ones | |
| 18:34:12 | mnaser | hmm | |
| 18:34:16 | mnaser | how nova-friendly is https://docs.openstack.org/releasenotes/zun/train.html#upgrade-notes ? | |
| 18:34:22 | mnaser | [compute]/host_shared_with_nova = true | |
| 18:35:44 | mnaser | so looks like its integrated with placement and gets the rp that nova uses and makes claims against it | |
| 18:35:51 | sean-k-mooney | i assume that is in the zun.conf | |
| 18:35:55 | sean-k-mooney | not the nova.conf | |
| 18:36:07 | mnaser | which i (thinking out loud) don't think that it can do bad things(tm) | |
| 18:36:14 | mnaser | because placement would just not return that compute host as a likely candidate at that point | |
| 18:36:42 | sean-k-mooney | am it depends | |
| 18:37:05 | sean-k-mooney | it could do bad things if you are using cpu pinning or hugepages | |
| 18:37:26 | mnaser | true, i guess its mostly focusing around ram and cpu claims (blindly) | |
| 18:38:01 | sean-k-mooney | well if they claim VCPU not PCUP then they woudl be required to enusre that the contaiern swapen on the cpu_shared_set | |
| 18:38:18 | sean-k-mooney | if they do not then thants a problemn | |
| 18:39:55 | mnaser | looks like its claiming VCPU | |
| 18:40:09 | mnaser | but i think it might not know to pin workloads | |
| 18:40:16 | mnaser | dont even think thats possible with docker | |
| 18:40:21 | sean-k-mooney | it is | |
| 18:40:27 | sean-k-mooney | you can pass a cpuset | |
| 18:40:38 | mnaser | https://github.com/openstack/zun/commit/7b3b1c5e07eb8b9e81031fa6ee4625ff6870b41d | |
| 18:40:44 | mnaser | this is the big commit and i dont think they have that (yet) | |
| 18:41:19 | sean-k-mooney | ya so without that it would not be safe to run zun on a nova host that has a PCPU inventory | |
| 18:41:50 | sean-k-mooney | s/safe/correct/ as the contianer could steal cpu time from the pinned instnace | |
| 18:44:00 | sean-k-mooney | mnaser: i also see this being an issue if we delet the nova compute service on that host but not the zun service | |
| 18:44:19 | mnaser | yeah i think that's an operator problem at that point because setting the zun setting would be invalid | |
| 18:44:24 | sean-k-mooney | unless they intentally took acount of that | |
| 18:44:35 | sean-k-mooney | not really | |
| 18:44:38 | mnaser | but then i think if you swap out that setting in flight | |
| 18:44:40 | sean-k-mooney | if i deploy with both | |
| 18:44:41 | mnaser | you probably lose all your allocation | |
| 18:44:54 | sean-k-mooney | and then later wanted to remvoe nova to just have zun | |
| 18:45:12 | sean-k-mooney | then wen we delete the compute node rp as part of service deleteion it might cause issue for zuun | |
| 18:45:37 | sean-k-mooney | right we will try to delete all the allcoation against the compute node ro | |
| 18:45:41 | sean-k-mooney | *RP | |
| 18:46:49 | sean-k-mooney | i dont recal the zun team discussing this with the nova team at the denver PTG did i miss a session on this? | |
| 18:47:34 | mnaser | yeah i think i remember talking about it with dansmith saying "it would be cool if" but i think they mentioned that "nova assumes it owns the rp, there is no such thing as rp sharing" | |
| 18:48:09 | sean-k-mooney | mnaser: right as of today it does | |
| 18:48:25 | sean-k-mooney | back in the dublin ptg i was suggestign nova should not own the compute node RP | |
| 18:48:45 | mnaser | ok so compute node rp sharing is a thing that isn't an antipattern | |
| 18:48:59 | sean-k-mooney | and each service should have there own nested RP subtree runder a shared compute node RP with no inventories | |
| 18:49:16 | sean-k-mooney | mnaser: right now it not a thing | |
| 18:50:00 | sean-k-mooney | well not really a thing im not 100% sure that neutorn bandwith based schduleing is not shareing an RP with nova | |
| 18:50:11 | sean-k-mooney | gibi: ^ do you know the answer to that | |
| 18:50:55 | sean-k-mooney | mnaser: im not aware of share where not is not the owner of the compute node RP. | |
| 18:54:43 | sean-k-mooney | looking at the zun patch tehy seam to have ported alot of code form nova which is not nessisarlly a good thing. | |
| 18:55:34 | efried | mnaser, sean-k-mooney: For some definition of "sharing". It doesn't matter who creates the RP (neutron vs nova for bw, cyborg vs nova for accels, etc) -- the important thing is that, if you're creating an instance, the entire *claim* needs to be atomic, and therefore done by nova. | |
| 18:55:56 | sean-k-mooney | or zun | |
| 18:56:16 | efried | as long as nova doesn't think it's going to come in afterwards and do some other claim, sure. | |
| 18:56:33 | sean-k-mooney | well zun has its own top level api | |
| 18:56:41 | efried | I don't really know what zun is or what it does | |
| 18:57:19 | sean-k-mooney | its a container as a service project that started as a replacment for nova-docker | |
| 18:57:29 | efried | I do recall seeing they were porting in a bunch of nova's resource tracker and scheduler gorp | |
| 18:57:32 | sean-k-mooney | so it can be used as a nova virt driver or as a standalone service | |
| 18:57:36 | efried | basically inheriting a mountain of technical debt | |
| 18:57:39 | efried | and we told them not to do that | |
| 18:57:42 | efried | and they did it anyway. | |
| 18:57:52 | sean-k-mooney | yes hence my comment above | |
| 18:59:00 | sean-k-mooney | when i see patches merge with TODO comments from jaypipes i assume that was not a recent TODO and there for form nova | |
| 19:00:57 | sean-k-mooney | the bit that worres my is fi the share with nova flag is set | |
| 19:02:15 | sean-k-mooney | the pass the full provider tree for the nova compute node RP to there update_provider_tree function | |
| 19:03:46 | sean-k-mooney | they are also modifing trait possible on the root RP | |
| 19:17:42 | mriedem | sean-k-mooney: bw providers are nested under the compute node rp | |
| 19:18:48 | mriedem | the case that sean-k-mooney mentioned about nova deleting the compute node and root resource provider when you delete a compute service, i can definitely see that screwing with zun if they assume the same resource provider with the same uuid is going to exist, i don't know how they link that up, maybe via hostname | |
| 19:19:03 | mriedem | we have our own problems managing that stuff, i.e. the orphaned allocations/providers bug we have right now, | |
| 19:19:11 | mriedem | let alone worrying about how we're going to be breaking external things | |
| 19:19:21 | efried | mriedem: Did you have something to do with https://review.opendev.org/#/c/684326/ not being combined with its (current) successor https://review.opendev.org/#/c/685937/ ? (USE_NEUTRON refactoring in tests) | |
| 19:19:37 | sean-k-mooney | ya so depending on the valude of "share with nova" they either create there own root RP or share nova | |
| 19:20:13 | sean-k-mooney | and they use the hostname to look up the one created by nova if "shareing" is enabled | |
| 19:20:14 | mriedem | efried: you can see my comments on PS1, i don't know why it changed like it did, i haven't looked yet, but it definitely isn't what i was expecting | |
| 19:20:29 | mriedem | efried: he had https://review.opendev.org/#/c/684326/1 | |
| 19:20:44 | mriedem | and then in the next patch in the series reverted a bunch of what he added with https://review.opendev.org/#/c/684327/ | |
| 19:20:45 | efried | mriedem: yeah, the earlier comments have been addressed to squash together a now-abandoned change | |
| 19:20:48 | mriedem | i said just squash those | |
| 19:21:02 | mriedem | sure, he did but then there were other things tacked on that i wasn't expecting | |
| 19:21:05 | efried | I'm just wondering why there's still two patches, one that sets False and the other that removes True | |
| 19:21:09 | mriedem | and haven't taken the time to grok the diff | |
| 19:21:29 | mriedem | iow, i said "just do x" and he did x + 4 | |
| 19:22:43 | mriedem | btw, unrelated to this, but we have another train rc2 fix on master with a +2 and ack from the bug reporter that it fixes the regression https://review.opendev.org/#/c/685194/ | |
| 19:23:28 | efried | o, I was reviewing that and then... didn't finish for some reason. | |
| 19:23:30 | efried | stand by. | |
| 19:24:19 | sean-k-mooney | i was going to say we shoudl navoe nova serial testing in the gate but it actuly just i nthe unit tests | |
| 19:25:01 | sean-k-mooney | getting spice testing should be pretty simple we jus tneed to pick one of our exisitg jobs to swap over ot it | |
| 19:25:12 | sean-k-mooney | im not sure if devstack deploy nova-serial | |
| 19:25:19 | sean-k-mooney | it proably does but i have never used it | |
| 19:25:27 | sean-k-mooney | melwitt: ^ | |
| 19:27:47 | efried | mriedem, melwitt: +A | |
| 19:27:54 | mriedem | hot | |
| 19:28:10 | sean-k-mooney | if we change greande-py3 to nova-serial-proxy and sawped nova-greade-multione to spice and kept the neturon-greade multinoe as the default novnc it should cover all three? | |
| 19:38:55 | efried | above my pay grade, sounds like a melwitt question. | |
| 19:42:13 | zigo | Heya ! Got my first VM running on Train with all the RC1 packaged and uploaded to Debian already ! :) | |
| 19:42:29 | zigo | It's never been that smooth ... :P | |
| 19:46:24 | mriedem | zigo: that's good news, thanks for sharing | |
| 19:46:32 | mriedem | we'll have an RC2, just fyi | |
| 19:46:53 | zigo | mriedem: For the moment, there's no "but x is broken" part, as much as I know... :P | |