| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-06 | |||
| 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 | |
| 11:38:12 | kplant | also vcpus_used == vcpus is a bad idea, unless nova knows about vcpus you're reserving | |
| 11:38:53 | sean-k-mooney | yes by default resize to same host is disabled so it normally does a move and will only stay on the same host if the weigher consider it to be the best host | |
| 11:39:13 | sean-k-mooney | if you enable same host resize in the config | |
| 11:40:28 | sean-k-mooney | kplant: if you use vcpu_pin_set or (cpu_shared_set and cpu_dedicated_set) then yes vcpu_used == vcpu shared is fine | |
| 11:40:59 | kplant | yeah, if not ideal :-) | |
| 11:41:18 | sean-k-mooney | ideally you should sue the *_sets for doing host reservation instead fo the reserved_host_cpus | |
| 11:41:25 | sean-k-mooney | *use | |
| 11:42:18 | sean-k-mooney | if you use the set you can choose which cpus to reserve and then you can use systemd to run the host process only on thos cores | |
| 11:42:34 | kplant | you can go further and use the bootloader | |
| 11:42:56 | sean-k-mooney | using isolcpus? is so you should really avoid that | |
| 11:43:07 | kplant | my only complaint with *_sets is you can't have open ended ranges | |
| 11:43:13 | kplant | like "3-" | |
| 11:43:24 | kplant | makes it easier to deal with hosts with, not vastly, different configs | |
| 11:43:40 | sean-k-mooney | you can do negations | |
| 11:43:51 | sean-k-mooney | "^0-2" | |
| 11:43:59 | kplant | ooo | |
| 11:44:10 | sean-k-mooney | i think negated ranges works | |
| 11:44:18 | sean-k-mooney | you can negate indivcual cores | |
| 11:45:01 | sean-k-mooney | we prably could add open ended ranges too you could always file a bug/blueprint | |
| 11:45:27 | kplant | i think negated ranges provide the same result | |
| 11:45:38 | kplant | nice | |
| 11:46:03 | sean-k-mooney | ill triple check the code to make sure that works | |
| 11:46:16 | sean-k-mooney | we support it for cpu_realtime_mask | |
| 11:46:27 | sean-k-mooney | but i think its supported in teh *_sets too | |
| 11:47:59 | sean-k-mooney | kplant: this is the code and it inclde the negation example for 1 core | |
| 11:48:20 | openstackgerrit | Balazs Gibizer proposed openstack/nova-specs master: template: consider openstack client besides novaclient https://review.opendev.org/717722 | |
| 11:48:46 | sean-k-mooney | kplant: yep negated ranges should work https://github.com/openstack/nova/blob/31aa4a6d7f0b8c301b093ad176ee2b44b5d3cec8/nova/virt/hardware.py#L134-L140 | |
| 11:50:05 | sean-k-mooney | sorry miss read that | |
| 11:50:53 | sean-k-mooney | the negation only works with 1 cpu | |
| 11:51:20 | kplant | looking at 113 -> 116 | |
| 11:51:26 | kplant | i think you might have been right originally | |
| 11:51:36 | kplant | it tests for ^str == '^' | |