| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-11-20 | |||
| 13:55:32 | mnaser | ya nope no oversubscription | |
| 13:58:52 | mnaser | epyc rome numbers https://www.irccloud.com/pastebin/3bgON0HX/ | |
| 13:59:18 | mnaser | intel (but much older hardware) https://www.irccloud.com/pastebin/6M7B4QLY/ | |
| 13:59:22 | mnaser | sean-k-mooney: ^ fyi, interesting to see latency numbers | |
| 14:01:05 | coreycb | kashyap: do you know if anything has landed for removing cpu flags, similar to cpu_model_extra_flags? | |
| 14:01:28 | kashyap | coreycb: Hi...afraid, no; but I've filed a Blueprint for it: | |
| 14:01:55 | kashyap | coreycb: https://blueprints.launchpad.net/nova/+spec/allow-disabling-cpu-flags | |
| 14:02:30 | coreycb | kashyap: thanks | |
| 14:03:40 | coreycb | kashyap: fyi this bug is why I'm asking: https://bugs.launchpad.net/bugs/1853200 | |
| 14:03:40 | openstack | Launchpad bug 1853200 in libvirt (Ubuntu) "cpu features hle and rtm disabled for security are present in /usr/share/libvirt/cpu_map.xml" [High,Confirmed] - Assigned to Ubuntu Security Team (ubuntu-security) | |
| 14:03:44 | kashyap | coreycb: I know :-( | |
| 14:03:51 | kashyap | And I guessed as much | |
| 14:04:35 | kashyap | coreycb: One (very valid) 'workaround' is that have QEMU add new "named CPU models" to remove the said flags. | |
| 14:05:00 | coreycb | kashyap: ok I'll mention that, thanks | |
| 14:05:43 | kashyap | coreycb: For that, upstream QEMU folks must add them...please file a QEMU "RFE" bug on launchpad for it | |
| 14:06:03 | sean-k-mooney | mnaser: did you enable cluster on die for the intel system out of interest | |
| 14:06:28 | coreycb | kashyap: thanks I'll pass the details on to cpaelzer, he's our qemu maintainer | |
| 14:06:39 | kashyap | (Nod) | |
| 14:06:50 | sean-k-mooney | mnaser: but yes the amd number seam to be much higher | |
| 14:07:17 | sean-k-mooney | mnaser: that is quite surprising to be honest | |
| 14:39:15 | efried | bauzas, gibi, stephenfin: would one of you please have a look at the nova/cyborg spec update https://review.opendev.org/#/c/684151/ and +A if appropriate? | |
| 14:39:35 | bauzas | efried: yeah, I can do | |
| 14:39:40 | efried | thanks bauzas | |
| 14:39:48 | stephenfin | I didn't review the original so I'll defer to others | |
| 14:39:55 | bauzas | I promised to do spec reviews, in particular following the ones we discussed at the PTG | |
| 14:39:58 | efried | After all, melissaml and Viere are +1. | |
| 14:45:43 | efried | dustinc: Did you pick up what I laid down yesterday about compute node conflicts for provider config? http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2019-11-19.log.html#t2019-11-19T22:19:41 | |
| 14:45:59 | aarents | Hi guys I need some review on this https://review.opendev.org/#/c/678016/ gibi already put +2, if you can have a look ? | |
| 14:46:55 | bauzas | aarents: /me clicks | |
| 14:47:24 | efried | dansmith: TL;DR: since, ironic notwithstanding, it would be insane for one compute node's $name to be the same as another's $uuid, we're just going to punt if there's a conflict across the whole $name+$uuid space. With that in play, it makes sense to treat $COMPUTE_NODE as a "default", which can be overridden by a specific $name/$uuid. And all that means we can detect conflicts immediately (on startup) and fail (to start up) if o | |
| 14:48:40 | dansmith | buffer overflow | |
| 14:50:10 | aarents | thks | |
| 14:51:21 | sean-k-mooney | efried: ill try and review the cyborg spec shortly | |
| 14:51:39 | efried | sean-k-mooney: thanks. It's just an update to the existing spec, nothing earth-shaking. | |
| 14:52:02 | dansmith | efried: your message was too long and was cut off after "fail to (start up)" | |
| 14:52:04 | sean-k-mooney | ya looks short | |
| 14:52:28 | efried | dansmith: oh, weird. "...fail (to start up) if one is detected." | |
| 14:52:33 | efried | that was all. | |
| 14:52:51 | efried | my buffer says I had another 25c | |
| 14:52:56 | efried | clearly I need to work on my TL;DRing. | |
| 14:53:11 | dansmith | efried: okay, so I think I was (and likely still am) missing some context yesterday and I was hurrying, | |
| 14:53:34 | dansmith | but the problem is that ironic nodes specified there may not exist as providers on startup, is that it? | |
| 14:53:53 | efried | that's pretty much the only scenario that makes us have to deal with this, yeah. | |
| 14:54:23 | dansmith | so we wanted to make that hard-fail if you provide something that doesn't exist there yeah? | |
| 14:54:28 | efried | no | |
| 14:54:48 | efried | generically the "problem" is that theoretically you can specify a config by $name and another by $uuid, but those are for the same node, but we wouldn't know that until that node "appeared". | |
| 14:55:04 | efried | In practice this shouldn't be possible because for ironic, $name == $uuid. | |
| 14:56:03 | dansmith | you mean if you had two entries in the list, one by name and one by uuid and they were in fact the same provider? | |
| 14:56:08 | efried | right | |
| 14:56:44 | dansmith | that seems like a really tiny detail to be concerned about.. did this come up in some testing or something? | |
| 14:56:53 | efried | more code inspection | |
| 14:57:06 | dansmith | remind me why we have the by-name option anyway? | |
| 14:57:10 | efried | ikr | |
| 14:57:27 | dansmith | uuid or the "self" option should really be all we need I would think | |
| 14:57:30 | efried | It was because you don't necessarily know the UUID yet in a green field. | |
| 14:57:44 | efried | but you want your tripleo to be able to lay down the config a priori. | |
| 14:57:46 | dansmith | in which case, non-ironic? in that case you use $COMPUTE_NODE yeah? | |
| 14:58:12 | efried | Yeah, I would think so. gibi, can we convince you we don't need identification by name? | |
| 14:58:23 | efried | (I think it was gibi who talked us into it) | |
| 14:58:26 | dansmith | either way, | |
| 14:58:46 | dansmith | I'm not sure we really need to care that much if someone puts a thing in there twice | |
| 14:59:12 | efried | right, you kinda f'ed up if that happens, but the code has to do *something* in that case. | |
| 14:59:21 | dansmith | *if* we can detect and log an error later that's helpful, but.. | |
| 14:59:34 | dansmith | your concern is just not being able to detect that at startup? | |
| 14:59:40 | efried | right. | |
| 14:59:51 | gibi | efried: I'm sort on context. Is it about provider config? | |
| 15:00:05 | efried | if we can detect it at startup, we can halt the service and force you to fix it. But we don't want to kill the service if it creeps in after we've already started running. | |
| 15:00:07 | efried | gibi: yes | |
| 15:00:16 | dansmith | efried: if it's hard/impossible to do at start, is clearly wrong config, and we can log an error later I think that's reasonable | |
| 15:00:29 | dansmith | efried: no, don't halt.. log an error periodically | |
| 15:00:36 | efried | dansmith: ack | |
| 15:00:41 | gibi | efried: so in case of a compute RP the name is known before the compute was ever started but the uuid only known after the compute creates the RP | |
| 15:00:44 | dansmith | we should never kill nova-compute after it's hit steady-state | |
| 15:00:48 | efried | right | |
| 15:00:57 | dansmith | gibi: we have $COMPUTE_NODE for that | |
| 15:01:05 | efried | gibi: Right, in that case, we can use the special ``$COMPUTE_NODE`` ... yeah ^ | |
| 15:01:07 | gibi | dansmith: I see. | |
| 15:01:09 | dansmith | they don't need to know either the name or the uuid for the compute node | |
| 15:01:33 | gibi | so instead of allowing RP identification by name in general, we add a specific case for compute node | |
| 15:01:50 | dansmith | we have that already | |
| 15:02:03 | dansmith | uuid can be a uuid or the special string "$COMPUTE_NODE" | |
| 15:02:40 | gibi | so far I'm OK with this. I guess if other RPs needs to be identified by name then we will add other symboles for that or we re-think the identify-by-name feature | |
| 15:02:41 | dansmith | efried: note that I'm okay with either removing name, or just detecting and logging this case later | |
| 15:02:50 | bauzas | gibi: dansmith: I haven't paid attention yet to this convo as I'm dragged into some internal all-hands but when I was looking on how to use the new COMPUTE_NODE trait, I think that we miss the world of nested RPs | |
| 15:03:11 | bauzas | unless we have some way to have some traits to be cascaded into child RPs | |
| 15:03:24 | bauzas | (and I really want to avoid saying 'inheritance') | |
| 15:03:59 | bauzas | but for example, if you lookup some RP, you need to call the RP and check its trait to know whether the original RP is still related to a compute node | |
| 15:04:02 | efried | bauzas: The only rp we're supporting this "wildcard" for right now is the root. If we find we need a way to generically identify its children later, we'll have more designing to do. | |
| 15:04:23 | bauzas | you need to call the *root* RP | |
| 15:04:27 | bauzas | (sorry for confusing) | |
| 15:04:40 | dansmith | is bauzas talking about this same thing? | |
| 15:04:46 | efried | almost :P | |
| 15:04:53 | gibi | hm, the neutron device RPs (provising bandwidth) also has a stable name generated from the device name. But as I don't have a use case for provider config related to the bandwidth feature I rest my case. | |
| 15:05:01 | bauzas | efried: sure, I'm just saying this is only convenient when you're in a flat world | |
| 15:05:26 | efried | I agree. Predictably-named nested RPs make a case for identifying by name. | |
| 15:06:08 | efried | though I think we've talked about the brittleness of relying on names before. | |
| 15:06:32 | gibi | efried: we have predicatable named nested RPs | 1110cf59-cabf-526c-bacc-08baabbac692 | aio:Open vSwitch agent:br-test | |
| 15:06:55 | mnaser | sean-k-mooney: sorry, was in a meeting too then, but no that wasnt enabled, but they are much older and also running ddr3 memory for comparision | |
| 15:07:02 | mnaser | much lower latency but lower bandwidth | |
| 15:07:12 | gibi | efried: but as I said I have no direct use case so I don't want to push for the naming support in provider config | |