| mnaser | sean-k-mooney: https://bugs.launchpad.net/nova/+bug/1917645?comments=all there's literally no way to workaround this issue, if that rabbitmq is down, the whole clouds melts down, even with retry=0 | 04:02 |
|---|---|---|
| opendevreview | Nicolas Parquet proposed openstack/nova master: Add v2.91 microversion, allowing @ and dot (.) characters in keypair name https://review.opendev.org/c/openstack/nova/+/781076 | 08:49 |
| opendevreview | Nicolas Parquet proposed openstack/nova master: Add v2.91 microversion, allowing @ and dot (.) characters in keypair name https://review.opendev.org/c/openstack/nova/+/781076 | 09:04 |
| gibi | mnaser: hi, about notification blocking the main thread, there is a bug from belmiro https://bugs.launchpad.net/nova/+bug/1917645 | 09:14 |
| gibi | I intended to look into at some point, but never had the time | 09:15 |
| gibi | now I feel again I should look | 09:17 |
| gibi | stephenfin: I have a bad feeling about https://review.opendev.org/c/openstack/nova/+/817746/comment/6690000b_3989ece7/ but if there is no better way then I will +A it | 09:46 |
| bauzas | gibi: looking at https://docs.openstack.org/nova/latest/contributor/ptl-guide.html#milestone-1 | 09:46 |
| bauzas | gibi: wondering if all this fish is still needed ? | 09:46 |
| gibi | bauzas: launchpad bookkeeping is really just bookkeeping. If you don't do it then nothing will fail | 09:47 |
| bauzas | gibi: you did this for Xena ? | 09:48 |
| gibi | bauzas: the lib releases are probably proposed by the release team automatically | 09:48 |
| bauzas | if so, I'll do it | 09:48 |
| bauzas | gibi: yeah I'm looking at the releases gerrit | 09:48 |
| bauzas | gibi: I wasn't asked to look at some changes | 09:48 |
| gibi | bauzas: it seems that I only released xena-3 in launchpad not 1, 2 or rc1 | 09:49 |
| * gibi is a lazy bastard | 09:49 | |
| bauzas | hah, OK | 09:49 |
| bauzas | I'll look at that | 09:49 |
| gibi | bauzas: I think the release team only proposes a release if there was real content on the branch since the last release | 09:50 |
| bauzas | yeah, I only see https://review.opendev.org/c/openstack/releases/+/818415 | 09:51 |
| bauzas | elodilles: ^ correct ? | 09:51 |
| gibi | bauzas: we have os-vif release proposed https://review.opendev.org/c/openstack/releases/+/818415 | 09:51 |
| bauzas | jinxed :p | 09:51 |
| gibi | but not python-novaclient | 09:51 |
| bauzas | yup | 09:52 |
| gibi | os-vif had some meaningfull change since 2.6 | 09:52 |
| bauzas | yes | 09:52 |
| gibi | novaclient does not | 09:52 |
| bauzas | correct | 09:52 |
| gibi | and I thin placement's os-traits and os-resource-classes are marked as independent libs so there we don't need a release | 09:53 |
| gibi | per milestone | 09:53 |
| bauzas | this is correct | 09:53 |
| bauzas | https://releases.openstack.org/independent.html#os-traits | 09:54 |
| bauzas | https://releases.openstack.org/independent.html#os-resource-classes | 09:54 |
| bauzas | they are independant | 09:54 |
| gibi | what I did at m1 is to move the bps targeted to m1 to m2 | 09:56 |
| gibi | but as far as see you opted not to target bps to milestones at all, so that retargeting is not needed | 09:58 |
| gibi | the list https://blueprints.launchpad.net/nova/yoga seem OK | 09:58 |
| elodilles | bauzas: gibi is right :) at milestone-1 only such projects had a generated release patch that had some real content in their master branch since the last release | 10:02 |
| *** blmt is now known as Guest6597 | 10:08 | |
| bauzas | elodilles: thanks for explaining :) | 10:17 |
| elodilles | :) | 10:33 |
| opendevreview | Merged openstack/nova master: db: Replace use of Executable.scalar(), Executable.execute() https://review.opendev.org/c/openstack/nova/+/804878 | 11:10 |
| bauzas | lyarwood: haven't seen that https://specs.openstack.org/openstack/nova-specs/specs/yoga/approved/ephemeral-encryption-libvirt.html shares the same BP than https://specs.openstack.org/openstack/nova-specs/specs/yoga/approved/ephemeral-encryption.html | 11:17 |
| bauzas | lyarwood: could you please create another BP for the libvirt one so I could mark it for yoga ? | 11:17 |
| bauzas | lyarwood: also, could you please modify the spec to use the new BP ? | 11:18 |
| opendevreview | Merged openstack/nova master: db: Replace use of 'autoload' parameter https://review.opendev.org/c/openstack/nova/+/805734 | 11:26 |
| opendevreview | Merged openstack/nova master: db: Replace use of legacy select() calling style https://review.opendev.org/c/openstack/nova/+/805735 | 11:26 |
| lyarwood | bauzas: do we need a bp per spec? It appears to graph them out correctly in the bp at least | 11:34 |
| opendevreview | Merged openstack/nova master: db: Replace 'insert.inline' parameter with 'Insert.inline()' method https://review.opendev.org/c/openstack/nova/+/805736 | 11:35 |
| opendevreview | Merged openstack/nova master: db: Don't pass strings to 'Connection.execute' https://review.opendev.org/c/openstack/nova/+/805737 | 11:35 |
| jhartkopf | Hi there, I'd like to add another topic to the open discussion section of today's Nova meeting, but it seems to be quite full already. Would you recommend to add the topic to next week's meeting instead? And how can I add a topic to the list? Should I just edit the Wiki page? | 13:09 |
| sean-k-mooney | you can just add it to the adgenda | 13:14 |
| sean-k-mooney | just edit the wiki | 13:14 |
| sean-k-mooney | what is the topic | 13:14 |
| sean-k-mooney | lyarwood: normally yes we have a blueprint per spec, you can model the depencies between the blueprints | 13:15 |
| sean-k-mooney | lyarwood: i think that works across projects too but not tried that in a while so not 100% sure | 13:16 |
| sean-k-mooney | lyarwood: im pretty sure i have linke a nova blueprint to a neutron one at some point | 13:16 |
| jhartkopf | sean-k-mooney: Alright, thanks. The topic is the spec for updating user data. We've already discussed it on OpenDev but I'd like to bring up some specific use cases once again. | 13:22 |
| sean-k-mooney | ack | 13:23 |
| opendevreview | Lee Yarwood proposed openstack/nova-specs master: fup: Correct the libvirt ephemeral encryption blueprint link https://review.opendev.org/c/openstack/nova-specs/+/818917 | 13:28 |
| lyarwood | sean-k-mooney: right thanks I thought the single bp showed the spec relationship but it looks like you created another bp previously | 13:29 |
| lyarwood | updated the spec to point to that second bp, iirc gibi was cool with one bp previously but I really don't mind either way | 13:29 |
| sean-k-mooney | ya im fine with both where it was useful in the past was vhost-user | 13:30 |
| sean-k-mooney | we had one blueprint for generic vhost-user support and a second for vhost-user with ovs-dpdk | 13:30 |
| sean-k-mooney | we happend to enable both in the same release but if the ovs-dpdk supprot had slipped we could have closed the generic one and move the ovs one | 13:30 |
| sean-k-mooney | we rarely have 2 feature that share a common part like that | 13:31 |
| sean-k-mooney | at least rarely in the same cycle | 13:31 |
| sean-k-mooney | lyarwood: actully one minor reason to have 2 bluepritns is the script we use to mark specs as implemented and move them uses the script file name to determin which blueprint to query | 13:34 |
| sean-k-mooney | lyarwood: i thinkthat is why i originally created the second libvirt one | 13:34 |
| EugenMayer | is it a known issue that ubuntu (20.04) does not accept the DNS server pushed by DHCP openstack (OVN)? Debian generic cloud image does work though | 13:37 |
| sean-k-mooney | EugenMayer: thats odd i would have expected that to work | 13:38 |
| sean-k-mooney | you set the nameservers on the subnet as normal | 13:39 |
| EugenMayer | Same does me. Spinnging up a debian box right now, expecting it to work (since all the debian boxes worked) | 13:39 |
| sean-k-mooney | and it just does not pic those up via dhcp? | 13:39 |
| EugenMayer | yes i do | 13:39 |
| EugenMayer | it ignores it on ubuntu, exactly | 13:39 |
| sean-k-mooney | ya that sound like a dhcpclint bug in ubuntu 20.04 | 13:39 |
| sean-k-mooney | i assume they are both useing the came dhcp clinet implemenation by default | 13:40 |
| EugenMayer | yes debian works. Same network same everything (using terraform here, so just replaced the image) | 13:40 |
| sean-k-mooney | perhap its fixed in a later cloud image? im not sure if you are using the latest point release image of 20.04 but might be worth trying the nightly image | 13:41 |
| EugenMayer | using the latest one | 13:41 |
| EugenMayer | not older then 5 days | 13:41 |
| EugenMayer | did you find a bug reeport? | 13:41 |
| sean-k-mooney | no have not look | 13:41 |
| EugenMayer | i look it up and try > 20.xx | 13:42 |
| sean-k-mooney | it used to work i think but that the only thing i can think of is a bug in the dhcpclient or the cloud-init default behavior in ubuntu | 13:42 |
| EugenMayer | maybe it is netplan related | 13:42 |
| EugenMayer | i use what is referenced at Same does me. Spinnging up a debian box right now, expecting it to work about | 13:43 |
| EugenMayer | sorry | 13:43 |
| EugenMayer | here https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest/configure-openstack.html#set-up-public-networking | 13:43 |
| EugenMayer | interesting, resolvectl status shows up the right dns serevers... but the resolution of my internal domains does not work | 13:49 |
| EugenMayer | i have to use 'dig @IP domain' | 13:49 |
| bauzas | lyarwood: oh, sorry, I haven't seen https://blueprints.launchpad.net/nova/+spec/ephemeral-encryption-libvirt | 13:56 |
| bauzas | lyarwood: then we need to update the spec to tell that the BP is ^ | 13:56 |
| bauzas | lyarwood: I mean, in https://specs.openstack.org/openstack/nova-specs/specs/yoga/approved/ephemeral-encryption-libvirt.html | 13:56 |
| lyarwood | bauzas: yeah there's a fup above for that now | 13:57 |
| lyarwood | https://review.opendev.org/c/openstack/nova-specs/+/818917 sorry | 13:59 |
| EugenMayer | sean-k-mooney ok i found it. Damn i confused the isolated test. I had a typo in my CNAME thus the isolated test with a blank 20.04 box failed and i assumed a general issues. Now vanilla focal works. just focal + rke2 has the wrong DNS servers, which might be an RKE2 setup thing. Sorry for wasting time, got dragged away, missed that typo | 14:03 |
| sean-k-mooney | EugenMayer: no worries | 14:04 |
| opendevreview | Merged openstack/nova-specs master: fup: Correct the libvirt ephemeral encryption blueprint link https://review.opendev.org/c/openstack/nova-specs/+/818917 | 14:19 |
| bauzas | eeeeek https://github.com/libvirt/libvirt/commit/3bd8181bc5548a0ce81107cbfb480dfdcba5679d | 14:33 |
| bauzas | sean-k-mooney ^ | 14:33 |
| mnaser | gibi: yeah i saw your comments and found that issue, it seems like even with retry=0, it still is kinda failing | 14:34 |
| mnaser | since it gets stuck in a reconnecting loop | 14:34 |
| bauzas | sean-k-mooney: context is https://bugs.launchpad.net/nova/+bug/1951656 | 14:34 |
| gibi | mnaser: yepp the retry config is only used to message sending but not connection setup | 14:34 |
| mnaser | that's where i ended up and it felt pretty non-trivial at that point to go from there :( | 14:35 |
| mnaser | at least, it's beyond my scope of comfortable knowledge anyways | 14:35 |
| gibi | mnaser: it seems the current oslo.messaging driver interface does not have way to express that the consumer wants configurable retry for conenction setup | 14:35 |
| sean-k-mooney | bauzas: we proably shoudl jsut not use libvirt for mdevs at all honestly but fun | 14:36 |
| gibi | mnaser: I'm still digging oslo.messaging to understand more how to fit this in | 14:36 |
| bauzas | sean-k-mooney: well, I'd prefer the other way, ie. asking libvirt to create mdevs | 14:36 |
| mnaser | gibi: something i found interesting was - https://docs.celeryproject.org/projects/kombu/en/stable/_modules/kombu/connection.html#Connection.ensure_connection | 14:36 |
| bauzas | sean-k-mooney: but they won't do it | 14:36 |
| mnaser | it looks like kombu has it's own error handling inside ensure_connection that maybe didn't exist back when openstack started using it | 14:36 |
| sean-k-mooney | bauzas: well the reason i say that is libvirt does not define that as a stable interface | 14:37 |
| sean-k-mooney | and createing/remvoing mdevs via the filesystem is pretty trivial | 14:37 |
| gibi | mnaser: yeah komubo has the flags in the interface | 14:37 |
| gibi | kombu | 14:37 |
| bauzas | anyway, when I'm seeing it, I wonder whether libvirt folks know there are some upper services that use them | 14:37 |
| gibi | mnaser: so we could configure kombu to stop after x retries | 14:37 |
| gibi | mnaser: we just don't have the scaffolding in oslo.messaging to use that | 14:38 |
| mnaser | gibi: yeah but i think then that brings the other interesting issue of 'does that mean it gives up forever for all future notifications' | 14:38 |
| sean-k-mooney | bauzas: they are partly aware i had a converstaion with them about this in relateino to vdpa | 14:38 |
| sean-k-mooney | and mac adresses | 14:38 |
| sean-k-mooney | they do not guarenttee the names are stabel and said we shoudl avoid realying on them | 14:38 |
| bauzas | meh | 14:40 |
| bauzas | OK | 14:40 |
| sean-k-mooney | bauzas: to me this is incorrect behavior in mdevctl and the libvirt chagne should be reverted | 14:40 |
| bauzas | gibi: heh https://bugs.launchpad.net/nova/+bug/1951623 | 14:40 |
| bauzas | gibi: I guess this will be fixed by your change, right ? | 14:40 |
| bauzas | oh, nevermind, it was for reboot | 14:41 |
| mnaser | i do see a point in 'if notifications are down, stop doing things that can be billed' | 14:43 |
| gibi | bauzas: unfortunatly that is a different problem | 14:45 |
| sean-k-mooney | mnaser: that is anyting other then delete including allowing the instance to continue running :) | 14:45 |
| bauzas | gibi: looks like, yes | 14:45 |
| mnaser | sean-k-mooney: but that means more $$$ am i rite? =ap | 14:45 |
| gibi | mnaser: yepp, I agree, but I think this behavior needs to be configurable | 14:46 |
| gibi | mnaser: to handle the case when notification only just good to have | 14:46 |
| gibi | but not must have | 14:46 |
| opendevreview | Artom Lifshitz proposed openstack/nova master: DNM: Explode libvirt builds to trigger tempest error code https://review.opendev.org/c/openstack/nova/+/818932 | 14:47 |
| sean-k-mooney | mnaser: :) i think the correct behavior if notification cant be sent is either to just log an error and drop them or continue to have the service work but set its healtch check to degraded | 14:47 |
| sean-k-mooney | the only other option i see would be for the service to terminate | 14:47 |
| opendevreview | Artom Lifshitz proposed openstack/nova master: DNM: Explode libvirt builds to trigger tempest error code https://review.opendev.org/c/openstack/nova/+/818932 | 14:48 |
| sean-k-mooney | mnaser: if we are going to stop some operation from workign i dont think we shoudl be reportign the srvice as up in our current status filed | 14:48 |
| sean-k-mooney | but that is based on a heatbeat which might still be working | 14:48 |
| sean-k-mooney | so that not really something we can change | 14:48 |
| mnaser | sean-k-mooney: historically i rather a failure and consistent behaviour than a degraded 'pass' that leaves a bit of a mess | 14:49 |
| mnaser | (see: ignore cinder volume deletes) | 14:49 |
| sean-k-mooney | well notifocation are generally considerd besteffort | 14:49 |
| sean-k-mooney | its not a mission cirtical part of the cloud | 14:50 |
| sean-k-mooney | so we could make the service exit as an opt in behavior but in generally i think logging an error and reportign a degrated health status then allowing something external to decied what to do i think is better | 14:50 |
| mnaser | i guess notifications being critical will dpeend on who you ask ;p | 14:51 |
| sean-k-mooney | form a nova point of view i dont think they ever have had any guarentees | 14:51 |
| sean-k-mooney | i know people do consume them for billing and other uses but the in ablity to send a notificaotn shoudl not have any impact on a user operation by default | 14:52 |
| sean-k-mooney | mnaser: as a customer if i tried to reboot a vm and it failed because fo a notrifcaiton issue i wold expect a 500 or other error code to be logged showing its an infra issue so i can file a ticket with my cloud provider for downtime | 14:53 |
| mnaser | sean-k-mooney: that's true, but i guess since we don't have any buffering right now, it means notifications can be lost .. and in theory, they'll get a 500 anyways now if the notifications are down =P | 14:54 |
| sean-k-mooney | mnaser:basicly in cloud where notificaiotn are treated as critical it would be a cloud outage from a customer point of ivew | 14:54 |
| sean-k-mooney | mnaser: hehe i guess they will get the 500 now ture | 14:55 |
| sean-k-mooney | although only if you dont set a retry limit right | 14:55 |
| mnaser | nope, even if you set retry=0 it fails :( | 14:55 |
| mnaser | see what gibi mentioned above, it gets stuck on trying to connect and that has no retries | 14:55 |
| sean-k-mooney | oh ok then that is a bug | 14:55 |
| mnaser | it loops forever on trying to connect | 14:55 |
| sean-k-mooney | ah right | 14:56 |
| sean-k-mooney | because its the amqp connection that is down its not an issue with sendign to a queue or exchange | 14:56 |
| mnaser | i captured GMR and updated info here - https://bugs.launchpad.net/nova/+bug/1917645 | 14:56 |
| sean-k-mooney | mnaser: well that proably should be converted to an oslo messaging bug at this point | 14:57 |
| mnaser | sean-k-mooney: good point actually | 14:57 |
| sean-k-mooney | nova might be able to work around this but eventually we will want to adress this there i suspect | 14:57 |
| opendevreview | Dmitrii Shcherbakov proposed openstack/os-traits master: Add a trait for remote_managed port-capable nodes https://review.opendev.org/c/openstack/os-traits/+/818514 | 15:01 |
| gibi | sean-k-mooney: sure oslo.messaging lacks a configuration possibility to stop retrying the connect, but I don't think it is purelya bug | 15:03 |
| sean-k-mooney | pro tip dont put a folder with 2412 sub directories in your test path if you want test discovery to happen before the heat death of the universe | 15:03 |
| gibi | sean-k-mooney: on nova side it is sure a bug if the instances stuck in some tranisitional state due to hanging | 15:04 |
| sean-k-mooney | gibi: yes but i dont think im sold that we should intoduction config driven api behavior | 15:04 |
| gibi | sean-k-mooney: not in nova no | 15:04 |
| gibi | sean-k-mooney: we need oslo.messaging configurability | 15:05 |
| sean-k-mooney | right so we cant block opertaion because we failed to send a notification | 15:05 |
| sean-k-mooney | gibi: well not i think not at all nova need to proceed even if the notificaiton cant be sent | 15:05 |
| sean-k-mooney | we can log an error ro report it via a healthcheck or similar | 15:05 |
| gibi | sean-k-mooney: I don't agree. If notifications are used for billing then I can imagine that the operator want the instance boot to fail if the notification bus is down | 15:06 |
| sean-k-mooney | gibi: its a grey area i guess | 15:06 |
| gibi | sure, don't stuck, but fail cleanly | 15:06 |
| sean-k-mooney | to me unless we can report a 500 to the user im not sure we should block the operation | 15:06 |
| bauzas | gibi: sean-k-mooney: thoughts abotu https://bugs.launchpad.net/nova/+bug/1951623 be a nova or neutron issue ? | 15:07 |
| * sean-k-mooney clicks | 15:07 | |
| sean-k-mooney | ..... both | 15:08 |
| bauzas | nova wouldn't know whether the port is disabled | 15:08 |
| gibi | bauzas: nova, as nova waits unconditionally | 15:08 |
| sean-k-mooney | nova can check that | 15:08 |
| bauzas | yeah | 15:08 |
| gibi | bauzas: nova can query the port sate | 15:08 |
| gibi | state | 15:08 |
| sean-k-mooney | nova because this is not checked today | 15:08 |
| sean-k-mooney | and neutron because this change depending on the backend | 15:08 |
| bauzas | gibi: mmm, that means that we would call neutron to get the port state | 15:08 |
| sean-k-mooney | bauzas: i think we have that in the network info cache but yes we have a check for this in some of the code already | 15:09 |
| bauzas | sean-k-mooney: ok, then it's a nova bug if we already call it | 15:09 |
| sean-k-mooney | we just dont in that part of the code | 15:09 |
| sean-k-mooney | but part of me is wondering if we would be better off just not using those event until we actully define a contract with neutorn on when they will be sent | 15:10 |
| gibi | sean-k-mooney: but thing might never happen based on past experience ^^ :) | 15:10 |
| sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L7221-L7228 | 15:11 |
| bauzas | gibi: sean-k-mooney: I just triaged the bug https://bugs.launchpad.net/nova/+bug/1951623 | 15:11 |
| sean-k-mooney | so we check if its active here but we dont for the migration events | 15:11 |
| sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/network/model.py#L488-L508 or here https://github.com/openstack/nova/blob/master/nova/network/model.py#L567-L586 | 15:12 |
| sean-k-mooney | bauzas: gibi so we just need to update the model fucntion to skip disbaled ports | 15:12 |
| bauzas | ack | 15:13 |
| bauzas | bug confirmed anyway | 15:13 |
| sean-k-mooney | the issue is that in some cases we will get event if the port is disabled | 15:13 |
| sean-k-mooney | which we will now be ignorign but thats is likely ok | 15:13 |
| gibi | yeah | 15:13 |
| bauzas | elodilles: I hadn't time to update the meeting agenda, but add your points if you want | 15:20 |
| bauzas | reminder : nova meeting in 40 mins here in #openstack-nova | 15:20 |
| elodilles | bauzas: adding it now then | 15:23 |
| DK4 | when creating instances they are all stuck in creating state. ive combed thrtough logs and did not find anything special. any advice on debugging that? | 15:23 |
| elodilles | bauzas: done, just added a short info update, quickly | 15:25 |
| elodilles | bauzas: you can edit now the page if you want | 15:26 |
| sean-k-mooney | bauzas: by the way unless youhave actully repoduced the bug or root caused it you should be setting it to triaged not confirmed | 15:31 |
| sean-k-mooney | we treat them more or less the same so i guess it does not matter but confrimed imples we coudl repoduces it triage does not | 15:32 |
| opendevreview | Dan Smith proposed openstack/nova master: Revert project-specific APIs for servers https://review.opendev.org/c/openstack/nova/+/816206 | 15:37 |
| bauzas | last reminder: nova meeting starts in 10 mins here at #openstack-nova IRC chan | 15:51 |
| bauzas | sean-k-mooney: yes and no, we could put in Triaged if we don't know the direction | 15:51 |
| bauzas | sean-k-mooney: we don't ask bug triagers to test all the issues | 15:51 |
| bauzas | (even if Launchpad says it) | 15:52 |
| bauzas | at least that's the census we have | 15:52 |
| sean-k-mooney | yes i know which is why i am saying confirmed is a larger statement | 15:52 |
| sean-k-mooney | triaged just means we think its valid and have some understading of why it happens, confrimed implies you ahve actully tried to repoduce it an have confirmed the behavior is as reported in the bug | 15:53 |
| sean-k-mooney | or at least that is how i treat it | 15:53 |
| bauzas | #startmeeting nova | 16:00 |
| opendevmeet | Meeting started Tue Nov 23 16:00:15 2021 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:00 |
| opendevmeet | The meeting name has been set to 'nova' | 16:00 |
| gibi | o/ | 16:00 |
| elodilles | o/ | 16:00 |
| bauzas | #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting | 16:00 |
| bauzas | good day, 'vyone | 16:00 |
| lyarwood | \o | 16:00 |
| bauzas | ok, let's start | 16:01 |
| * kashyap waves | 16:01 | |
| bauzas | a few folks could be off b/c of some holiday they have on Thursday :) | 16:02 |
| bauzas | not French , tho | 16:02 |
| bauzas | #topic Bugs (stuck/critical) | 16:02 |
| bauzas | #info No Critical bug | 16:02 |
| bauzas | #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 29 new untriaged bugs (+1 since the last meeting) | 16:02 |
| bauzas | I did a bit of triage and will continue on it tomorrow | 16:02 |
| bauzas | thanks for the people who did this too | 16:03 |
| bauzas | #help Nova bug triage help is appreciated https://wiki.openstack.org/wiki/Nova/BugTriage | 16:03 |
| bauzas | #link https://storyboard.openstack.org/#!/project/openstack/placement 33 open stories (+0 since the last meeting) in Storyboard for Placement | 16:03 |
| bauzas | any bug to discuss by now ? | 16:03 |
| bauzas | #topic Gate status | 16:04 |
| bauzas | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | 16:04 |
| bauzas | no new gate bug AFAICS | 16:04 |
| bauzas | btw. we could triage three of them that are NEW :) | 16:05 |
| bauzas | (even 4) | 16:05 |
| bauzas | #link https://zuul.openstack.org/builds?project=openstack%2Fplacement&pipeline=periodic-weekly Placement periodic job status | 16:05 |
| bauzas | we have an issue | 16:05 |
| bauzas | #info tempest-integrated-placement job had a CI issue | 16:05 |
| bauzas | #link https://zuul.openstack.org/build/43f380b91bd14579806d0b9be0d702c8 the job itself | 16:06 |
| bauzas | looks like an unrelated package issue | 16:06 |
| gibi | it is a known issue https://zuul.openstack.org/build/43f380b91bd14579806d0b9be0d702c8/log/job-output.txt#4206 | 16:06 |
| gibi | the pmlogger service did not start | 16:07 |
| kashyap | What does the service even do? | 16:07 |
| gibi | we see it time to time in nova jobs too | 16:07 |
| gibi | kashyap: never digged into it | 16:07 |
| kashyap | Is it this? - https://man7.org/linux/man-pages/man1/pmlogger.1.html | 16:07 |
| kashyap | Anyway, don't want to distract from the main point :) | 16:07 |
| bauzas | #agreed this is a known issue related to pmlogger, should be automatically fixed next run | 16:08 |
| bauzas | agreed on the agreed ? ^ | 16:08 |
| gibi | pmlogger.service - Performance Metrics Archive Logge | 16:08 |
| gibi | so yes | 16:08 |
| gibi | bauzas: sure | 16:08 |
| bauzas | ok, if this is done, let's move on | 16:08 |
| bauzas | #info Please look at the gate failures, file a bug, and add an elastic-recheck signature in the opendev/elastic-recheck repo (example: https://review.opendev.org/#/c/759967) | 16:08 |
| bauzas | any other gate issue to mention ? | 16:09 |
| bauzas | looks not | 16:10 |
| bauzas | #topic Release Planning | 16:10 |
| bauzas | Yoga-1 was Nova 18th#link https://releases.openstack.org/yoga/schedule.html#y-1 | 16:10 |
| bauzas | dang | 16:10 |
| bauzas | link https://releases.openstack.org/yoga/schedule.html#y-1 | 16:10 |
| bauzas | Yoga-1 was Nova 18th | 16:10 |
| bauzas | #info Spec review day helped to merge 3 specs | 16:10 |
| bauzas | thanks people who reviewed them | 16:11 |
| bauzas | #info at Yoga-1 timeframe, Nova already accepted 7 specs and 4 specless BPs | 16:12 |
| bauzas | (sorry, was counting) | 16:12 |
| bauzas | anything to mention about the pace we have ? | 16:13 |
| bauzas | #info reminder that we plan another spec review day mid-Dec, exact date to be discussed in a next meeting | 16:13 |
| bauzas | moving on ? | 16:14 |
| bauzas | I guess so | 16:14 |
| bauzas | #topic Review priorities | 16:14 |
| bauzas | #link https://review.opendev.org/q/status:open+(project:openstack/nova+OR+project:openstack/placement)+label:Review-Priority%252B1 | 16:14 |
| bauzas | #link https://review.opendev.org/c/openstack/nova/+/816861 bauzas proposing a documentation change for helping contributors to ask for reviews | 16:15 |
| bauzas | that reminds me I need to update this change | 16:15 |
| bauzas | #action bauzas to update his change to reflect the consensus about non-ownership ask for this label | 16:15 |
| bauzas | but then, I'll ask next week what and how people feel about how to asynchronously ask reviewers (cores and non-cores) to look at changes | 16:16 |
| bauzas | or the other way, how reviewers can discover changes | 16:16 |
| bauzas | we have room for contributors happy to review that we can help them how to do this | 16:17 |
| gibi | bauzas: btw, can we remove review priority from https://review.opendev.org/c/openstack/nova/+/810220 it is in -1 since 5th of Nov | 16:18 |
| bauzas | gibi: fair enough, you provided good comments on it, and I didn't added my ones since I agree with you | 16:19 |
| gibi | and I have the same feeling about https://review.opendev.org/c/openstack/nova/+/810849 too | 16:19 |
| bauzas | even if I'd like this bugfix to be merged somehow | 16:19 |
| gibi | and this too https://review.opendev.org/c/openstack/nova/+/803713 | 16:19 |
| bauzas | #info we removed the Review-Priority flag from a few changes as they were lacking updates | 16:21 |
| bauzas | I added a comment to each of the changes explaining to ping me again once they revise the change | 16:21 |
| bauzas | gibi: thanks for the cleanup | 16:22 |
| bauzas | I should somehow think about how to periodically check this | 16:22 |
| bauzas | that's it for the RP labelling and usage ? | 16:22 |
| bauzas | I guess so | 16:24 |
| bauzas | #topic Stable Branches | 16:24 |
| bauzas | elodilles: the mic is yours | 16:24 |
| elodilles | #info stable gates are not blocked | 16:24 |
| bauzas | woow | 16:24 |
| elodilles | #info Ussuri transitioned to Extended Maintenance for nova projects \o/ | 16:25 |
| elodilles | and that's it i think | 16:25 |
| elodilles | i have no updates for the intermittent failures on stable gates :( | 16:25 |
| bauzas | elodilles: don't wanna release any stable branch as we're around yoga-1 ? | 16:25 |
| elodilles | good question | 16:26 |
| bauzas | we could do a xena .z release | 16:26 |
| elodilles | i haven't checked how much new content we have on stable branches | 16:26 |
| bauzas | not sure if people want it tho | 16:26 |
| bauzas | I'm pretty sure gibi would like a release, nope? | 16:26 |
| bauzas | given of the backports | 16:26 |
| bauzas | or do people want to stack a bit more until we release ? | 16:27 |
| elodilles | i can prepare some if there is need :) | 16:27 |
| gibi | bauzas: no hard push on a release | 16:29 |
| bauzas | I have no personal interest beyond curiosity | 16:29 |
| bauzas | ok, we can wait them | 16:29 |
| bauzas | then* | 16:29 |
| gibi | bauzas: the waiting for plug fix needed on victora / pike for my downstream counterpart | 16:29 |
| elodilles | (i don't see much merged content) | 16:29 |
| opendevreview | Dan Smith proposed openstack/nova master: Revert project-specific APIs for servers https://review.opendev.org/c/openstack/nova/+/816206 | 16:29 |
| bauzas | gibi: well, for us, wallaby and train, but whatever | 16:30 |
| gibi | yeah probably train too | 16:30 |
| bauzas | I guess we're done with this topic, we can rediscuss about the opportunity to release a bit later in the cycle | 16:30 |
| elodilles | yes, let's discuss later | 16:31 |
| bauzas | ++ | 16:32 |
| bauzas | #topic Sub/related team Highlights | 16:32 |
| bauzas | Libvirt (lyarwood) | 16:32 |
| lyarwood | We are tracking a QEMU 6.1.0 regression downstream with [libvirt]num_pcie_ports >= 15 when using the q35 machine type, we aren't hitting it yet upstream in Nova itself as we only use q35 in nova-next but TripleO is seeing it with centos 8 and 9 stream after a QEMU rebase. The workaround is to lower the port count to <=14. Just a heads up for now, I've got a TODO to create a known issue release note in Nova for the time being while we | 16:32 |
| lyarwood | wait on a fix in QEMU. | 16:32 |
| bauzas | ouch. | 16:32 |
| lyarwood | and that's all I have this week | 16:33 |
| sean-k-mooney | ack so noting to do in nova other then the known issue | 16:33 |
| bauzas | ack, I also saw some bad libvirt modification that creates problems for our vgpu support | 16:33 |
| sean-k-mooney | and perhaps change job config if needd | 16:33 |
| lyarwood | sean-k-mooney: ack pretty much | 16:33 |
| bauzas | https://bugs.launchpad.net/nova/+bug/1951656 | 16:33 |
| bauzas | the fix is easy but that makes me worried about the fact that the namings we have are not a public API | 16:34 |
| sean-k-mooney | its not the first time we have been broken by such name changes | 16:35 |
| bauzas | can't imagine what would happen if the drivers can also change their mdev type names | 16:35 |
| bauzas | we're a bit fragile | 16:36 |
| bauzas | anyway | 16:36 |
| bauzas | let's not overdiscuss this | 16:36 |
| bauzas | we have a few specless bps requests again this week | 16:36 |
| bauzas | #info QEMU 6.1.0 regression downstream with [libvirt]num_pcie_ports >= 15 requires for the moment to work around by lowering the port count to <=14. lyarwood will provide a relnote for it until the QEMU regression is fixed | 16:38 |
| bauzas | moving on | 16:38 |
| bauzas | #topic Open discussion | 16:38 |
| bauzas | #topic Open discussion | 16:38 |
| bauzas | (dasp) Blueprint for review: "Make no_compression_image_types configurable" -- https://blueprints.launchpad.net/nova/+spec/configurable-no-compression-image-types | 16:38 |
| bauzas | dasp: around ? | 16:38 |
| bauzas | Rationale: hardcoded behavior slows down cold migrations with local RAW disk images to 8 mbps and maxes CPU. It might be a good idea to change the default value as well or disable compression for all types. | 16:38 |
| dansmith | this is compression of just the stream? | 16:39 |
| * bauzas reads the blueprint description | 16:41 | |
| dansmith | I assume the original thought is that raw disks *might* be mostly zeroes which compress to nothing during transfer, | 16:41 |
| dansmith | but that probably falls apart over time and makes it compression for no reason | 16:41 |
| bauzas | that's my general assumption | 16:41 |
| sean-k-mooney | for ssh | 16:42 |
| dansmith | ideally libvirt would just do hole detection and not transfer the holes, I think, but... | 16:42 |
| sean-k-mooney | it just adds -C | 16:42 |
| sean-k-mooney | for rsync it enable rsync compression | 16:42 |
| dansmith | sean-k-mooney: ah, right | 16:42 |
| dansmith | well, I see no reason to prevent people from choosing this, so seems okay to me | 16:42 |
| bauzas | oh the ssh transfer itself ? | 16:42 |
| sean-k-mooney | yes | 16:42 |
| bauzas | I guess the proposal is to make it configurable ? | 16:42 |
| dansmith | yeah | 16:43 |
| bauzas | but that would be for all images of the same type | 16:43 |
| dasp | I'm here | 16:43 |
| dansmith | default to the same behavior it looks like, so no change unless you want change | 16:43 |
| bauzas | (I guess) | 16:43 |
| sean-k-mooney | its this https://github.com/openstack/nova/blob/50fdbc752a9ca9c31488140ef2997ed59d861a41/nova/virt/libvirt/volume/remotefs.py#L192-L193 | 16:43 |
| bauzas | dansmith: if this is opt-in for uncompress, that's OK | 16:43 |
| dansmith | bauzas: right | 16:43 |
| bauzas | dansmith: if that's changing the default to *not* compress raw images, I'm -1 | 16:44 |
| sean-k-mooney | so the current patch if they have not reviesed it maintianed the exsting behavior | 16:44 |
| dansmith | bauzas: no, it's keeping the same default, just allowing people to control it | 16:44 |
| sean-k-mooney | and i was suggesting we would not change the default without more dicussion | 16:44 |
| bauzas | then it looks to me a simple configurable ask, which doesn't require a spec provided they don't break existing behaviour | 16:44 |
| sean-k-mooney | although both rsync and ssh recommend it only for slow connections | 16:44 |
| dasp | yes, changing default is not in scope right now as it comes from me. However, based on my tests, the default behavior is very bad unless I'm doing something unusually wrong. | 16:45 |
| dasp | So I'm likely going to propose another future spec to change the default separately. | 16:45 |
| sean-k-mooney | dasp: right so for now i think we shoudl add the option and consider changing the default after we get some operator input | 16:45 |
| bauzas | what sean-k-mooney said | 16:45 |
| dansmith | I dunno if discard will cause qemu to zero sections of a raw disk, but if not, over time your raw disk of zeroes becomes not that, so compression becomes useless after a point | 16:45 |
| bauzas | expose the new knob | 16:45 |
| bauzas | let operators play with it | 16:46 |
| bauzas | and give us figures about why this is helpful to change the default | 16:46 |
| bauzas | anyone having concerns about https://blueprints.launchpad.net/nova/+spec/configurable-no-compression-image-types NOT being a specless BP ? | 16:47 |
| bauzas | no API modifications, no upgrade concerns, no DB modifications, just a configurable add | 16:48 |
| sean-k-mooney | this is ok to me so no objections | 16:48 |
| dansmith | yup | 16:48 |
| bauzas | looks like nobody is freaking out | 16:49 |
| bauzas | #agreed https://blueprints.launchpad.net/nova/+spec/configurable-no-compression-image-types is approved as a specless BP, provided no change in default behaviour | 16:49 |
| bauzas | next one | 16:49 |
| bauzas | (jhartkopf) Update user data spec (https://review.opendev.org/c/openstack/nova-specs/+/816542) | 16:49 |
| bauzas | jhartkopf: around ? | 16:49 |
| bauzas | are you just asking for spec review ? | 16:49 |
| jhartkopf | around | 16:50 |
| bauzas | oh, I remember this one | 16:50 |
| bauzas | that's an interesting case | 16:50 |
| sean-k-mooney | i think jhartkopf wanted to expand on there usecase | 16:50 |
| bauzas | right | 16:51 |
| jhartkopf | We have already discussed this spec extensively, but I’d like to focus on a specific use case now. | 16:51 |
| jhartkopf | We think the change would make sense when using Cloudbase-init plugins, which can run at every boot and configures guest settings based on user data | 16:51 |
| jhartkopf | We already brought that up, but still think this would be a valid use case | 16:51 |
| sean-k-mooney | cloud-init support that too by the way its just not how its typically used | 16:52 |
| bauzas | jhartkopf: IIRC, your usecase was for ssh key management, right? | 16:52 |
| sean-k-mooney | i thikn that was someone else usecase | 16:52 |
| jhartkopf | bauzas: no, that was the other person who wanted the same feature some years ago | 16:52 |
| bauzas | hah, apologies then | 16:53 |
| sean-k-mooney | for ssh key manament i do think there is vaule in support multiple keys and updating them | 16:53 |
| bauzas | jhartkopf: my concern is, which specific cases are useful that require the userdata to be mutable ? | 16:53 |
| bauzas | besides the fact that other big Fives do this | 16:53 |
| sean-k-mooney | speificly is there a usecase you are trying to enable that is a usecase for the end user/tenant not the operator | 16:54 |
| jhartkopf | sean-k-mooney: Cloud-init supports this as well, yes. But why would you want to restrict API functionality and potentially restrict other's workflows? | 16:54 |
| bauzas | sean-k-mooney: indeed, cases about end user | 16:55 |
| sean-k-mooney | the user-data is "owned" by the enduser so if the reason to make it mutable is so operators can chagne it it would not be consitnet with the usage of that api | 16:55 |
| dasp | when rebuilding an instance, you can't redeclare userdata (AFAIK) but you effectively make cloud-init re-run, that's a trap my users run into | 16:55 |
| sean-k-mooney | dasp: for rebuild we do allow new user data to be pass in a later microverion i belive | 16:56 |
| bauzas | yeah that rings me a bell | 16:56 |
| sean-k-mooney | dasp: you are correct that orginally we did not | 16:56 |
| bauzas | sec | 16:56 |
| dasp | oh, sorry my org is running a bit "behind" on versions | 16:56 |
| bauzas | sean-k-mooney: 2.3 | 16:57 |
| bauzas | so... Kilo | 16:57 |
| sean-k-mooney | 2.54 allows the key to be changed on rebuild https://docs.openstack.org/nova/latest/reference/api-microversion-history.html#id50 and 2.57 allows user data to be updated | 16:57 |
| bauzas | oh, that one | 16:57 |
| sean-k-mooney | bauzas: its no 2.3 | 16:57 |
| bauzas | yeah my bad | 16:57 |
| bauzas | this is Queens | 16:58 |
| sean-k-mooney | but ya since queens | 16:58 |
| bauzas | we only have 2 mins left | 16:58 |
| bauzas | (as a timekeeper) | 16:58 |
| sean-k-mooney | jhartkopf: we could proably make it mutable if there is a use facing usecase but we would need to support config dirve and note that the change may not fully be ableable untill after a hard reboot | 16:59 |
| bauzas | I'll have to call it a wrap | 16:59 |
| bauzas | for this week | 16:59 |
| bauzas | we can revisite this in the spec | 16:59 |
| bauzas | #info https://review.opendev.org/c/openstack/nova-specs/+/816542 requires propre description of enduser cases for mutable user data | 17:00 |
| bauzas | that's it, we're over time | 17:00 |
| bauzas | thanks all | 17:00 |
| bauzas | #endmeeting | 17:00 |
| opendevmeet | Meeting ended Tue Nov 23 17:00:36 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 17:00 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2021/nova.2021-11-23-16.00.html | 17:00 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2021/nova.2021-11-23-16.00.txt | 17:00 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2021/nova.2021-11-23-16.00.log.html | 17:00 |
| sean-k-mooney | jhartkopf: so i dont think bauzas or myself are entirly aginst this but the reasons for doing it present sofare in the spec dont fully seam valid | 17:01 |
| bauzas | correct | 17:01 |
| jhartkopf | Well, I understand your concerns. | 17:01 |
| bauzas | copying others isn't enough for me | 17:01 |
| jhartkopf | This was definitely not a copy, as you can see in the implementation. We had a use case internally, which may seem not valid to others. | 17:02 |
| jhartkopf | I don't know if we will put further work into it. | 17:03 |
| sean-k-mooney | jhartkopf: i think you orginally mention NTP servers chanign which i woudl have expected to be pushed out via either vendor data or neutron via dhcp | 17:03 |
| opendevreview | Artom Lifshitz proposed openstack/nova master: DNM: Explode libvirt builds to trigger tempest error code https://review.opendev.org/c/openstack/nova/+/818932 | 17:03 |
| sean-k-mooney | jhartkopf: i do liek the multiple key pairs or updating keypairs usecase | 17:04 |
| sean-k-mooney | so perhaps if we support that it also makes sense to allow updatign the user-datat to allow bootstraping that | 17:05 |
| bauzas | jhartkopf: sorry, didn't wanted to nack, I need to revisite your spec | 17:05 |
| bauzas | jhartkopf: probably understanding which specific instance action you'd like the userdata to be updated, and why, would help | 17:06 |
| sean-k-mooney | bauzas: well without config driver i think its just a server update | 17:06 |
| bauzas | and what would be the benefit for the end user | 17:06 |
| bauzas | sean-k-mooney: that's why I don't want to discuss about the solution yet | 17:07 |
| sean-k-mooney | then its updated in the metadata api so the instance can retirve the new version | 17:07 |
| bauzas | I need to understand the problem that a immutable userdata creaters | 17:07 |
| bauzas | creates* | 17:07 |
| jhartkopf | sean-k-mooney: Maybe, I have to think about that multiple SSH keys use case more. | 17:08 |
| sean-k-mooney | jhartkopf: with your proposal this would also be a replace of the user data right | 17:09 |
| sean-k-mooney | so you would have to get it then update it localy then submit the updated version | 17:09 |
| sean-k-mooney | so its a replace not inplace update/patch | 17:09 |
| jhartkopf | This replaces current user data, yes | 17:09 |
| sean-k-mooney | part of my consern is this is a potenital securrity issue | 17:10 |
| sean-k-mooney | in that an admin could alter the user data, reboot the instnace and then gain access to the instnace | 17:10 |
| sean-k-mooney | i know the admin can get acess other ways | 17:11 |
| sean-k-mooney | but its potentally problematic in some cases | 17:11 |
| jhartkopf | sean-k-mooney: I see, it's something to consider. | 17:14 |
| jhartkopf | Will discuss with my team and decide what to do | 17:15 |
| jhartkopf | Thanks for your time sean-k-mooney and bauzas | 17:15 |
| jhartkopf | have a good day :) | 17:16 |
| bauzas | you too | 17:21 |
| * bauzas stops for the day | 17:21 | |
| ganso | stephenfin, sean-k-mooney: hi! very quick question: in light of patch https://review.opendev.org/c/openstack/nova/+/792356 then it means this doc is incorrect, right?: https://docs.openstack.org/neutron/wallaby/admin/config-ovs-dpdk.html#using-vhost-user-multiqueue | 17:39 |
| sean-k-mooney | ganso: just looking | 17:40 |
| sean-k-mooney | what specificlly | 17:40 |
| ganso | grepping the code in wallaby branch still doesn't turn anything up related to vif_multiqueue_enabled being used through the flavor | 17:40 |
| ganso | sean-k-mooney: the doc states the property could be used in the flavor | 17:41 |
| ganso | sean-k-mooney: which does not seem to be the case | 17:41 |
| sean-k-mooney | yes so that will need to be udated as part of this change | 17:41 |
| sean-k-mooney | sorry not | 17:41 |
| sean-k-mooney | it has $ openstack flavor set $m1.large --property hw:vif_multiqueue_enabled=true and $ openstack image set --property hw_vif_multiqueue_enabled=true IMAGE_NAME | 17:41 |
| ganso | sean-k-mooney: oh cool so no need to update the doc, thanks! | 17:42 |
| sean-k-mooney | ganso: it looks like the doc was incorreectly updated at some point | 17:43 |
| sean-k-mooney | assuming likely that this chagne had already merged | 17:43 |
| sean-k-mooney | ganso: there is a docs change in this serise anyway https://review.opendev.org/c/openstack/nova/+/792362/8 | 17:44 |
| sean-k-mooney | which can be used to do any more change that are required | 17:44 |
| *** mdbooth8 is now known as mdbooth | 17:48 | |
| opendevreview | Rodrigo Barbieri proposed openstack/nova master: Move 'hw:pmu', 'hw_pmu' parsing to nova.virt.hardware https://review.opendev.org/c/openstack/nova/+/792364 | 17:48 |
| ganso | sean-k-mooney: oh thanks I had forgotten about the other patches in the topic | 17:49 |
| *** jamesdenton_alt is now known as jamesdenton | 20:12 | |
| *** artom_ is now known as artom | 20:20 | |
| * artom will end up just doing https://review.opendev.org/c/openstack/nova/+/813419 for https://review.opendev.org/c/openstack/nova/+/817303 | 20:20 | |
| artom | Until Neutron starts telling us authoritatively what kind of events to wait for and when, we're pushing the responsibility on the operator to tell us in config options. | 20:21 |
| sean-k-mooney | artom: maybe | 20:47 |
| sean-k-mooney | we have a simialir issue wiht disable ports and evacuatate apparently | 20:48 |
| sean-k-mooney | im not sure we can really just set thse for every operation | 20:48 |
| opendevreview | Dan Smith proposed openstack/nova master: Revert project-specific APIs for servers https://review.opendev.org/c/openstack/nova/+/816206 | 21:01 |
| artom | sean-k-mooney, ugh | 21:43 |
| sean-k-mooney | the disable prot issue is simpel to fix | 21:47 |
| sean-k-mooney | but im not sure if the downstream evacute issue is related to the revirt migrate issue or not | 21:47 |
| sean-k-mooney | artom: the event handeling is all a bit of a mess since neutron is so inconsitent when sending events | 21:47 |
| sean-k-mooney | artom: latest live migration issue https://bugs.launchpad.net/nova/+bug/1951623 | 21:48 |
| sean-k-mooney | i outlined the fix in comment 3 but technically neutron should be seind plug event even for disable interface | 21:49 |
| artom | sean-k-mooney, yeah, so if Neutron's not fixing themselves, and we're not dumping all that complexity on the operator, then... just stop using external events altogether? | 21:49 |
| sean-k-mooney | because we do plug them the agent is just ment to set the port down | 21:49 |
| artom | And too bad if the instance has no network for the first few seconds? | 21:49 |
| sean-k-mooney | no we need to find time to fix it | 21:50 |
| sean-k-mooney | you can just disable treating vif plug failrue as error today | 21:51 |
| sean-k-mooney | its not the right solution long term but you can if you need too | 21:51 |
| sean-k-mooney | and we have a second option specificly for live migration i belte and now gibi has added a new one | 21:51 |
| opendevreview | Artom Lifshitz proposed openstack/nova master: Add nova-next-hybrid-plug job https://review.opendev.org/c/openstack/nova/+/817303 | 21:52 |
| sean-k-mooney | https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.vif_plugging_is_fatal | 21:52 |
| sean-k-mooney | and https://docs.openstack.org/nova/latest/configuration/config.html#compute.live_migration_wait_for_vif_plug | 21:52 |
| artom | True, we have the first config option | 21:53 |
| * artom preps supper and other household chores | 21:55 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!