| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-08-31 | |||
| 14:24:21 | JayF | It's all in the devstack Ironic plugin | |
| 14:24:30 | sean-k-mooney | ya that makes sense | |
| 14:24:42 | ozzzo_work | What's the best way to determine whether a VM is locked? | |
| 14:24:58 | sean-k-mooney | ozzzo_work: you can tell in the api with a server show | |
| 14:26:35 | ozzzo_work | I'm on Train. Was that added in a later version? | |
| 14:27:17 | sean-k-mooney | i dont think so but i dont think it is shown in openstack client by default | |
| 14:27:29 | ozzzo_work | I'm comparing "server show" output from locked and unlocked VMs, and I can't find a difference | |
| 14:27:49 | sean-k-mooney | is there a --long option for that command | |
| 14:28:06 | ozzzo_work | no | |
| 14:28:34 | ozzzo_work | aha I can see it with "nova show" | |
| 14:28:59 | johnthetubaguy | Maybe also try update to the very latest openstack CLI and SDK so it uses the latest microversion by default, it was added in 2.9 apparently: https://docs.openstack.org/nova/latest/reference/api-microversion-history.html#id8 | |
| 14:29:52 | sean-k-mooney | you can do "openstack sever list --locked" | |
| 14:30:08 | sean-k-mooney | https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/server.html#cmdoption-openstack-server-list-locked | |
| 14:42:11 | ozzzo_work | ah very nice, ty! | |
| 15:40:59 | opendevreview | Pavlo Shchelokovskyy proposed openstack/nova master: Replace -- as 3-4 char in hostname with - https://review.opendev.org/c/openstack/nova/+/893072 | |
| 16:20:04 | alaysd | Hey everyone | |
| 16:38:07 | sean-k-mooney | bauzas: fyi i put a -2 on https://review.opendev.org/c/openstack/nova/+/893072 for https://bugs.launchpad.net/nova/+bug/2033401 | |
| 16:38:43 | sean-k-mooney | this is an api change so it would need a spec but in general im not sure we want to do any mroe vlaidation fo hostname with all the pain we had last time | |
| 16:38:53 | bauzas | NOOOOOOOOO | |
| 16:39:33 | bauzas | (not no because of your -2 but because of the rathole we entered when we went with supporting FQDNs | |
| 16:40:10 | sean-k-mooney | right so if we add even more santaisation to ensure we comply with https://www.rfc-editor.org/rfc/rfc5891#section-4.2.3.1 | |
| 16:40:26 | bauzas | my personal take : fix it with docs | |
| 16:40:28 | sean-k-mooney | it will break someone who does not care about it | |
| 16:40:51 | sean-k-mooney | im not enven sure it needs to be in our docs but we could jus tadd a note | |
| 16:41:04 | bauzas | change as much as you want on clients (incl SDK and OSC), API-ref and the likes, but please please please, never ever touch this again | |
| 16:41:18 | sean-k-mooney | but basically i think we shoudl leave this up to the user to do | |
| 16:41:40 | bauzas | we have api-reference | |
| 16:41:49 | bauzas | and I know 1% of our users read it | |
| 16:42:16 | bauzas | but that's the place where we can put 'doh, we don't support rfc5891' | |
| 16:42:23 | sean-k-mooney | ya a note in api-ref would be ok but it woudl basically say. if you do not follwo the relvente RFCs for hostname formats thigns might break | |
| 16:42:37 | sean-k-mooney | its not that we dont suport it | |
| 16:42:39 | bauzas | true, nova is just passing thru the hostname | |
| 16:42:49 | bauzas | so you're due to respect this | |
| 16:42:51 | sean-k-mooney | its that we dont auto manage names that are invlaid to make it pass | |
| 16:43:12 | opendevreview | Amit Uniyal proposed openstack/nova master: Allow swap resize from non-zero to zero https://review.opendev.org/c/openstack/nova/+/857339 | |
| 16:51:40 | bauzas | cores, there are two series that still require love from you in order to be accepted in time for the FF : https://review.opendev.org/q/topic:ironic-shards+project:openstack/nova+is:open and https://review.opendev.org/q/topic:bp%252Funified-limits-nova-tool-and-docs | |
| 16:51:58 | bauzas | both have all their changes at least having a single +2 | |
| 17:19:38 | sean-k-mooney | bauzas: this is already approved but we shoudld track this for rc1 https://review.opendev.org/c/openstack/nova/+/883344 | |
| 17:19:42 | opendevreview | John Garbutt proposed openstack/nova master: Add nova-manage ironic-compute-node-move https://review.opendev.org/c/openstack/nova/+/886989 | |
| 17:20:00 | bauzas | sean-k-mooney: I'll start creating an etherpad | |
| 17:21:01 | sean-k-mooney | its running in zuul now so we can just keep an eye on it but i tought this was already merged | |
| 17:21:16 | opendevreview | John Garbutt proposed openstack/nova master: Make compute node rebalance safter https://review.opendev.org/c/openstack/nova/+/887151 | |
| 17:22:26 | johnthetubaguy | melwitt: bauzas sorry, my rebase broke the functional tests without me noticing, I fixed that up now. | |
| 17:22:43 | bauzas | johnthetubaguy: already sent back to the gate | |
| 17:23:01 | johnthetubaguy | thank you. | |
| 17:23:52 | melwitt | dual wielding | |
| 17:23:55 | sean-k-mooney | so given how close this is if it does not merge today i would be open to an FFE for the ironic shard stuff | |
| 17:25:05 | bauzas | we don't need to define a RFE process | |
| 17:25:36 | bauzas | the ironic shard one can be late approved IMHO, one core is already giving his go, and two patches of 4 are already +W | |
| 17:25:52 | bauzas | eventually, the change surface is quite restricted to the ironic driver | |
| 17:26:14 | sean-k-mooney | well more just indrectly noting that today is thehnicall feature freeze | |
| 17:26:35 | sean-k-mooney | but as you note it had +2 across the borad | |
| 17:26:36 | bauzas | so, provided JayF or other ironic folks can hardly stress-test this thing and can provide bugfixes those 2 weeks, I'm good | |
| 17:26:49 | melwitt | this patch has only one +2 but was +W'ed, was that intentional? https://review.opendev.org/c/openstack/nova/+/887151 | |
| 17:26:51 | bauzas | sean-k-mooney: I'm very well aware of today's FF :) | |
| 17:27:07 | johnthetubaguy | in perfect timing, I am going to the beach tomorrow... (obvs to celebrate feature freeze with an ice cream) | |
| 17:27:22 | bauzas | melwitt: doh, my fault ! | |
| 17:27:28 | sean-k-mooney | johnthetubaguy: nice | |
| 17:27:35 | sean-k-mooney | johnthetubaguy: enjoy it | |
| 17:27:49 | sean-k-mooney | im also not planning to be here at this time tomrorrow evening | |
| 17:28:18 | bauzas | melwitt: I don't know why but when I proxy'd your +W on the dependent patch, I messed up and added it too to the top patch | |
| 17:28:24 | johnthetubaguy | Thanks for the reviews, I am back Monday if there is stuff to help push it across the line | |
| 17:28:28 | bauzas | apologies, no pun intended | |
| 17:28:37 | melwitt | ah ok | |
| 17:29:34 | bauzas | https://etherpad.opendev.org/p/nova-bobcat-blueprint-status tells me we are mostly done with all the blueprints we were able to review | |
| 17:29:57 | bauzas | except the large manila series and the ephemeral storage | |
| 17:32:39 | bauzas | so, again, we still have some patches requiring second +2 on https://review.opendev.org/q/topic:ironic-shards and https://review.opendev.org/q/topic:bp%252Funified-limits-nova-tool-and-docs | |
| 17:32:47 | bauzas | for me, my day is almost over | |
| 17:33:03 | bauzas | but I can hang for a bit | |
| 17:37:37 | zer0c00l | I think this change in libvirt 9.5.0 (shipped with centos stream 9) breaks nova, (atleast yoga) https://github.com/libvirt/libvirt/commit/a2ae3d299cf Any one seen this before? | |
| 17:39:29 | sean-k-mooney | zer0c00l: with what network backend | |
| 17:39:46 | sean-k-mooney | calico? | |
| 17:40:09 | sean-k-mooney | the intree network backends do not create taps nor does os-vif | |
| 17:40:19 | sean-k-mooney | they are only created by libvirt | |
| 17:41:07 | sean-k-mooney | zer0c00l: i am not aware of any supported backend where the tap is precreated | |
| 17:41:19 | sean-k-mooney | so i dont think this will impact nova | |
| 17:41:20 | zer0c00l | sean-k-mooney: yeah we are running calico | |
| 17:41:47 | sean-k-mooney | well even in the calico case libvirt is ment to create the tap | |
| 17:42:07 | sean-k-mooney | calico just manges the routing | |
| 17:54:10 | sean-k-mooney | calico is apprently still using vif type tap https://github.com/projectcalico/calico/blob/cf7fa35475eba84f5afcd7f53ac7d07dcb403202/networking-calico/networking_calico/plugins/ml2/drivers/calico/test/lib.py#L66C31-L66C34 | |
| 17:54:27 | JayF | bauzas: Yeah, I am dedicating at least one full day next week to testing sharding in devstack, and potentially writing a tempest test if I get far enough :) | |
| 17:54:37 | sean-k-mooney | vif type tap is not supported by our os-vif code so its usign the legacy fallback | |
| 17:55:23 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/virt/libvirt/vif.py#L595-L596 | |
| 17:55:47 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/virt/libvirt/vif.py#L420-L430 | |
| 17:56:20 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/virt/libvirt/designer.py#L44-L55 | |
| 17:57:12 | sean-k-mooney | zer0c00l: with that said the tap was always ment to be created by libvirt so it sound like calico might have been doing things it shoudl not have been | |
| 17:57:35 | zer0c00l | sean-k-mooney: Thanks for looking into this. :( | |
| 17:58:07 | sean-k-mooney | we could proably correct this with a bug fix | |
| 17:58:23 | sean-k-mooney | jsut setting managed='no' | |
| 17:58:45 | sean-k-mooney | here https://github.com/openstack/nova/blob/master/nova/virt/libvirt/vif.py#L427 | |
| 17:59:26 | sean-k-mooney | the problem is that the there is no way to test this really upstream | |
| 17:59:38 | sean-k-mooney | well beyond unit/fucntional tests | |
| 17:59:44 | sean-k-mooney | but we dont have any calico ci | |
| 18:00:09 | sean-k-mooney | calico should be the only backend using vif_type=tap | |
| 18:00:24 | sean-k-mooney | but im not sure if we woudl need a config option in the workarounds section for this or not | |
| 18:00:51 | zer0c00l | sean-k-mooney: yeah, my team member is doing exactly that. | |
| 18:01:00 | sean-k-mooney | im kind of reluctant to set managed='no' because that might eb a security issue | |
| 18:01:07 | zer0c00l | dev.append(etree.Element("target", dev=self.target_dev, managed=self.managed)) | |
| 18:01:07 | zer0c00l | if self.target_dev is not None: | |
| 18:02:22 | sean-k-mooney | zer0c00l: can you file a bug for this. | |