| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-06 | |||
| 10:30:49 | johnthetubaguy | stephenfin: no, they mean the same thing on every cloud, just not all clouds have them available, at least that is the design | |
| 10:31:04 | bauzas | johnthetubaguy: correct, my only concern is the potential issues we could raise or any potential new keys we would want to provide | |
| 10:31:22 | johnthetubaguy | plus the wild west of custom scheduler stuff, which we need to keep | |
| 10:31:23 | bauzas | and that wasn't addressed in the spec AFAIK | |
| 10:31:39 | johnthetubaguy | bauzas: yeah, agreed with that worry | |
| 10:32:42 | bauzas | there are actually 2 different things in my mind | |
| 10:32:52 | bauzas | A/ a forgotten key | |
| 10:33:00 | bauzas | B/ a new key in a future release | |
| 10:33:36 | bauzas | A/ sounds a bug, and I personnally agree with gibi on the fact we should just accept to backport a bugfix aiming to fix such things | |
| 10:33:56 | bauzas | B/ is still undesigned in my mind | |
| 10:34:34 | bauzas | because 'Cloud OVH' could unsupport 'myfancynewkey' while 'Cloud Vexxhost' would | |
| 10:34:46 | gibi | bauzas: we might now better what to do with B as when we have the situation to add an new in tree key | |
| 10:35:05 | stephenfin | kick that decision to Victoria? :) | |
| 10:35:07 | bauzas | compared to now where both support it (well, actually, just accepting it silently) | |
| 10:35:18 | gibi | bauzas: those OVH and Vexxhost keys won't be in tree keys | |
| 10:35:36 | gibi | so they need to implement custom validators | |
| 10:35:45 | gibi | I guess | |
| 10:36:02 | bauzas | gibi: if this key is written to be used in a Victoria change, and if OVH lags with a Ussuri cloud compared to Vexxhost, then you'll see a change | |
| 10:36:33 | stephenfin | only the cloud operators themselves will see it though | |
| 10:36:37 | gibi | bauzas: do you mean a situation, when I have a script that creates flavors both in OVH and Veexhost? | |
| 10:36:46 | stephenfin | and they'd see the same thing for image metadata | |
| 10:36:48 | bauzas | that's exactly why 3 years ago, we left the custom filters to be wildcards | |
| 10:37:28 | bauzas | gibi: for a flavor, this requires an admin by default policy | |
| 10:37:35 | bauzas | so i wouldn't worry too much | |
| 10:37:51 | gibi | bauzas: then in what situation you worry? | |
| 10:38:06 | bauzas | image properties that can be user-defined | |
| 10:38:28 | bauzas | do we expose the flavor extra specs to the users ? I think so too | |
| 10:38:58 | gibi | stephenfin: does the same validator code runs for the image properties? | |
| 10:39:26 | sean-k-mooney | bauzas: image propertiese cant be userdeined | |
| 10:39:34 | stephenfin | gibi: no, image properties are already validated because they're mapped to o.vos | |
| 10:39:36 | sean-k-mooney | bauzas: we made them ovo years ago | |
| 10:39:57 | bauzas | hem you're right | |
| 10:40:00 | sean-k-mooney | bauzas: yes its configurable by policy but extra specs are shown | |
| 10:40:02 | gibi | bauzas: so the image properties are a different story | |
| 10:40:30 | bauzas | okay, I just to reconsider whether we have a problem or not | |
| 10:40:33 | stephenfin | different but also the same, in as far as they're not tied to microversions | |
| 10:40:40 | sean-k-mooney | gibi: they use to be a blank sting until like extra specs but peopel were exploiting them to pass virt driver specific stuff | |
| 10:40:42 | gibi | adding an extra spec is also admin only by default, like creating flavor | |
| 10:40:56 | bauzas | I said (and gibi too) that A/ (a bugfix for adding a forgotten key) isn't a problem. johnthetubaguy, you okay with this ? | |
| 10:41:24 | gibi | sean-k-mooney, stephenfin: ack, thanks | |
| 10:42:18 | sean-k-mooney | in the current spec we have the query arg to disable validation right | |
| 10:42:58 | johnthetubaguy | sorry in a meeting | |
| 10:43:14 | sean-k-mooney | if we really really want too we can have that vailadte=false flag be valdiate=2020-01 or some other validation version | |
| 10:43:56 | sean-k-mooney | so kind of like the microverions if you want the ussuri behavior then you just set teh right validation version | |
| 10:44:31 | sean-k-mooney | i think thats proably overkill untill people ask for it or clould have issue with it but its a simple enough solution to implement | |
| 10:46:15 | sean-k-mooney | also morning all o/ | |
| 10:46:41 | bauzas | fwiw, I just left a comment on https://review.opendev.org/#/c/708436/ to summarize our thoughts | |
| 10:46:55 | alex_xu | stephenfin: I just go through them all https://review.opendev.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/use-pcpu-and-vcpu-in-one-instance | |
| 10:47:31 | alex_xu | stephenfin: a question for https://review.opendev.org/714658, I think we need to add data migration script, right? it isn't hard I think | |
| 10:47:51 | mensis | Hello, we are currently using OpenStack Pike version. i wanted to ask a question about VM Resize operation. After i resize a virtual machine, when i log in to it via SSH, i get 'kernel:NMI watchdog: BUG: soft lockup - CPU#12 stuck for 29s! [python:9846]' message. And VM is really slow right now. When i check CPU utilization, sometimes i see %1000. Any suggestions, please? | |
| 10:47:58 | bauzas | stephenfin: could you just respin a revision of https://review.opendev.org/#/c/704643/ by just amending the commit msg and explaining why you add into the ignore list H328 ? | |
| 10:48:04 | bauzas | stephenfin: do this and I +2 | |
| 10:48:13 | bauzas | (+2/+W) actually | |
| 10:49:19 | stephenfin | alex_xu: yeah, we could (and probably should) add an online migration for that, yes. It shouldn't be difficult. You saw my patch to update the ComputeNode.numa_topology and Instance.numa_topology fields | |
| 10:49:27 | johnthetubaguy | stephenfin: I think I am ok with the trade off, because its an admin API, I think if we changed the meaning of an existing extra spec (in a big way, like a rename) we would want a microversion (basically we shouldn't do that) | |
| 10:49:35 | stephenfin | bauzas: cool. gimme 5. Finishing up doc rework | |
| 10:49:40 | alex_xu | stephenfin: the huaqiang's one, about adding pcpuset field | |
| 10:50:18 | alex_xu | stephenfin: oops, misunderstand your word. right, I saw your patch | |
| 10:50:18 | bauzas | johnthetubaguy: stephenfin: actually, that's a good call | |
| 10:50:25 | stephenfin | alex_xu: cool :) | |
| 10:50:32 | alex_xu | cool | |
| 10:50:52 | bauzas | johnthetubaguy: stephenfin: we could just say that we won't support new filters with fancy new keys upstream until we somehow come up with a plan | |
| 10:50:55 | bauzas | \o/ | |
| 10:50:59 | bauzas | problem solved. | |
| 10:50:59 | stephenfin | johnthetubaguy: Yeah, sticking in TODOs is as close as I've gotten to reworking the extra specs yet | |
| 10:51:41 | bauzas | johnthetubaguy: stephenfin: that would solidly refrain the need for pushing new filters in-tree and would at least require a spec, which I think is always good | |
| 10:52:10 | bauzas | and since people can provide their own out-of-tree filters and do what they want, they wouldn't be hit | |
| 10:52:25 | bauzas | I like that plan actually | |
| 10:54:39 | gibi | bauzas: replied in https://review.opendev.org/#/c/708436/ | |
| 10:55:33 | bauzas | gibi: cool, we're on the same page | |
| 10:56:20 | bauzas | I'd appreciate johnthetubaguy to agree on https://review.opendev.org/#/c/708436/16//COMMIT_MSG@12 | |
| 10:56:41 | bauzas | but if he's ok, I'll change my vote to +2 (at least once I'm fully done with reviewing) | |
| 10:57:58 | openstackgerrit | Stephen Finucane proposed openstack/nova master: api: Add framework for extra spec validation https://review.opendev.org/704643 | |
| 10:58:01 | stephenfin | bauzas: ^ | |
| 11:01:04 | bauzas | stephenfin: +W | |
| 11:01:26 | bauzas | stephenfin: but you need to rebase the whole tree now | |
| 11:01:51 | bauzas | (sorry, if it was other thing but a commit msg, I would have proposed a FUP) | |
| 11:02:14 | stephenfin | I'm not sure if I do or if Gerrit will do it for me, but I'm reworking the doc patch so can do so shortly if needed | |
| 11:02:27 | stephenfin | I'll wait to see if there are review comments first | |
| 11:11:27 | ierdem | Hello guys, i have a question about resizing a running VM. I tried to increase vCPU counts of a running VM and after that i connected succesfully but it is too slow to run anything. When i see process list via "top" command, i saw CPU usage is approximately 1000 percent and it decrease sometimes but increase again. Any suggestions please? | |
| 11:12:30 | stephenfin | bauzas: out out? :O | |
| 11:12:34 | stephenfin | :P | |
| 11:12:46 | bauzas | out from my room :p | |
| 11:13:05 | bauzas | Who Let the Dogs out out ? | |
| 11:13:44 | bauzas | https://www.youtube.com/watch?v=Qkuu0Lwb5EM | |
| 11:15:50 | sean-k-mooney | well regardign fancy new keys. i would rather just define a custom: name spaces that should be used for user defined extra_specs and declare all other namespaced keys as owned by nova | |
| 11:16:16 | sean-k-mooney | and if a new intree filter wants to add keys it gets its own namespace | |
| 11:16:44 | sean-k-mooney | if our of tree filter need to define keys the do it via custom: | |
| 11:17:11 | sean-k-mooney | ideally with a prefix e.g. custom:myfilter_mykey | |
| 11:30:14 | sean-k-mooney | ierdem: i assume you have oversubsrtion enabled on your cloud? | |
| 11:30:25 | sean-k-mooney | ierdem: is the host over subsibed | |
| 11:31:53 | sean-k-mooney | ierdem: it should like you either have someing in the vm that is broken/maliusly consumeing cpu, the vm workload need more vcpus or the host is over subsribed | |
| 11:32:54 | sean-k-mooney | ierdem: simply seeing high cpu usage in the guest is not an indication that something is wrong form a nova point of view | |
| 11:33:36 | ierdem | hmm, how can i check if the host is oversubscribed? | |
| 11:34:32 | ierdem | by the way, before resizing vCPU count, it was working fine | |
| 11:35:00 | kplant | a resize can move the instance to another hypervisor | |
| 11:36:41 | kplant | if you just do a 'nova hypervisor-show <uuid>' | |
| 11:36:49 | kplant | you can check vcpus vs vcpus_used | |
| 11:36:58 | kplant | if vcpus_used > vcpus; you're over subscribed | |
| 11:37:38 | ierdem | ok, thanks i will try and return to you | |