| LarsErikP | Happy new year everyone! Any updates on nova zed 26.2.1? https://review.opendev.org/c/openstack/releases/+/899604 | 08:20 |
|---|---|---|
| bauzas | LarsErikP: we need to merge https://review.opendev.org/c/openstack/nova/+/900307/3 first | 09:06 |
| bauzas | sean-k-mooney: could you please +2 this backport ? | 09:06 |
| bauzas | https://review.opendev.org/c/openstack/nova/+/900307/3 | 09:06 |
| tobias-urdin | had a issue in december where a nova-compute was installed with same hostname and nova-compute service happily started even though placement RP creation got a conflict | 09:43 |
| tobias-urdin | imo nova-compute should fail on startup if placement RP create gets conflict | 09:43 |
| opendevreview | melanie witt proposed openstack/nova master: libvirt: Introduce support for rbd with LUKS https://review.opendev.org/c/openstack/nova/+/889912 | 09:43 |
| tobias-urdin | so this: https://review.opendev.org/c/openstack/nova/+/904381 – but that changes all exceptions, see the child patch on that for just catching ResourceProviderCreationFailed | 09:43 |
| tobias-urdin | which approach is acceptable? | 09:44 |
| opendevreview | Amit Uniyal proposed openstack/nova stable/yoga: Fix the PCI device capability dict creation https://review.opendev.org/c/openstack/nova/+/899252 | 10:05 |
| opendevreview | Amit Uniyal proposed openstack/nova stable/yoga: Store pf_mac_address and vf_num in extra_info https://review.opendev.org/c/openstack/nova/+/899253 | 10:05 |
| opendevreview | Amit Uniyal proposed openstack/nova stable/yoga: Translate VF network capabilities to port binding https://review.opendev.org/c/openstack/nova/+/899254 | 10:05 |
| zigo | stephenfin: Hi there! Do you agree with the new version of my patch? https://review.opendev.org/c/openstack/keystoneauth/+/903860 | 10:36 |
| stephenfin | zigo: wrong channel, but comment left on same | 11:41 |
| sean-k-mooney | zigo: for what its worht the current version of the patch looks ok to me | 12:24 |
| sean-k-mooney | bauzas: ill review it now | 12:25 |
| sean-k-mooney | bauzas: done | 12:28 |
| tobias-urdin | sean-k-mooney: can u check above – would like your feedback on it and i'll whip up a correct patch based on that | 12:33 |
| sean-k-mooney | you started 2 nova compute services withthe same host name | 12:34 |
| sean-k-mooney | and the placement rp failed to be created because it was using a diffent service uuid | 12:34 |
| sean-k-mooney | that should only be possibel if they are in diffent cells today | 12:35 |
| sean-k-mooney | the first one to start will register its self as a service, and write the uuid to /var/lib/nova/compute_node | 12:36 |
| sean-k-mooney | the second one will find the service and not the file containing the uuid and will fail to start | 12:36 |
| tobias-urdin | kind of, the original nova-compute was already removed, new node was added with same hostname before it was removed, but nova-compute reported up even though RP creation failed | 12:40 |
| tobias-urdin | i would expect nova-compute to fail if RP could not be created i.e wrong uuid = conflict | 12:41 |
| tobias-urdin | s/removed/stopped/g | 12:41 |
| sean-k-mooney | the current expection is that it will eventually be crated | 12:41 |
| sean-k-mooney | but it soudn like you incorrectly replafced the node | 12:42 |
| sean-k-mooney | if you are replacing the node and keeping the same identity/hostname | 12:42 |
| sean-k-mooney | then you shoudl not do a compute service delete | 12:42 |
| sean-k-mooney | as part of the replacement | 12:42 |
| sean-k-mooney | and you shoudl take the old compute_node uuid and put it in the compute node file | 12:43 |
| tobias-urdin | yes automation/manual steps failed for removing the nova service record (and thus RP) before installing new node, but issue would be caught if nova-compute failed start so that it reported as down | 12:43 |
| sean-k-mooney | right but what im saying is the logic is wrong | 12:43 |
| sean-k-mooney | there are 2 ways to do that replacement | 12:43 |
| sean-k-mooney | you can scale in (fully deleting the node in nova/neutron/placemetn) and then scale out | 12:44 |
| sean-k-mooney | if you do that there is a strict ordering requirement | 12:44 |
| sean-k-mooney | the name cannot be reused until its fully deleted | 12:44 |
| sean-k-mooney | or you can replace the node without deleting the compute/neutron agent services | 12:44 |
| sean-k-mooney | which is how we normally recommend you replace a node when maintaining its identity | 12:45 |
| tobias-urdin | normally we just delete everything but this time somebody forgot the compute service delete step, i would like to protect operators from having a nova-compute reporting up when it's not working | 12:45 |
| sean-k-mooney | ... | 12:46 |
| tobias-urdin | fail on nova-compute startup if RP creation failed | 12:46 |
| tobias-urdin | like neutron-ovs-agent is looping forever and not reporting up if br-int or local_ip is wrong | 12:46 |
| tobias-urdin | safety first ¯\_(ツ)_/¯ | 12:47 |
| sean-k-mooney | so the problem is that we expect to be able to start the compute agents before placement is up | 12:47 |
| sean-k-mooney | and for them to eventually register when it becomes aviableable | 12:47 |
| sean-k-mooney | that woudl still be true if you have something liek systemd | 12:47 |
| sean-k-mooney | that will restart nova-compute externally | 12:48 |
| tobias-urdin | but if we explicitly fail on placement RP conflict then? would that work | 12:48 |
| sean-k-mooney | so your change might be ok | 12:48 |
| sean-k-mooney | it woudl only work if you have an external service restarting it | 12:48 |
| sean-k-mooney | im not nessisarly agaisnt this change | 12:49 |
| sean-k-mooney | im a little wary of just doing it for any exception | 12:50 |
| sean-k-mooney | tobias-urdin: the up status of a compute service is primarly ment to signal that its able to comunicate via rpc with the hypervior | 12:51 |
| sean-k-mooney | i say it that way as we have specific logic to mark it down if the connection to libivrt is lost | 12:51 |
| sean-k-mooney | its technially not ment to be a healtcheck | 12:52 |
| sean-k-mooney | so im a little concerned about scope creap | 12:52 |
| sean-k-mooney | with that said you are stoping the agent if it fails | 12:53 |
| sean-k-mooney | so the meaning of up technically has not been changed by this patch | 12:53 |
| tobias-urdin | yeah i understand, for us basically since we don't verify anything in placement specifically with monitoring, the nova-compute was up but it never scheduled any workload there | 12:54 |
| tobias-urdin | it's a messy edge case but if we get ResourceProviderCreationFailed and it's a conflict we could perhaps just fail on startup to not report up | 12:55 |
| sean-k-mooney | for what its worht this is why im working on adding a per process healt check endpoint | 12:55 |
| tobias-urdin | so took us some day or two before we noticed it | 12:55 |
| tobias-urdin | yea | 12:55 |
| sean-k-mooney | so i think i would be happier if you added a new except for ResourceProviderCreationFailed | 12:55 |
| sean-k-mooney | rather then doing this for just Exception | 12:55 |
| sean-k-mooney | the other thing im thinking about is | 12:56 |
| sean-k-mooney | how does your chage work with ironic | 12:56 |
| sean-k-mooney | im not expictly aware of an issue with ironic but each ironic agent is managing multiple compute nodes (1 per ironic node) each with there own RP | 12:57 |
| sean-k-mooney | in its current form if there was an error for any of the ironic RPs it would cause the ironic compute agent to exit | 12:58 |
| sean-k-mooney | so we may want to skip this if its ironic | 12:58 |
| sean-k-mooney | tobias-urdin: what release are you runing by the ay | 13:01 |
| sean-k-mooney | *way | 13:01 |
| tobias-urdin | mix of yoga and zed, but nova is yoga | 13:05 |
| sean-k-mooney | ack so ya you dont have the stabel uuid feature | 13:05 |
| sean-k-mooney | which would catch this. | 13:05 |
| tobias-urdin | didn't think about the ironic use-case | 13:06 |
| tobias-urdin | would nova-compute service be down in that case? | 13:06 |
| sean-k-mooney | so usign the normal meaning of up/down it should be up if it cna comunicate with teh ironic rest api and it accessabel over the rpc bus | 13:07 |
| sean-k-mooney | even if one of the ironic computes is not usabel | 13:07 |
| sean-k-mooney | comptue nodes do not have an up or down state | 13:07 |
| sean-k-mooney | only comptue services do | 13:07 |
| tobias-urdin | sorry, with stable uuid feature | 13:08 |
| sean-k-mooney | oh for stable uuid we explcitly dont use the fature with ironic | 13:08 |
| sean-k-mooney | we put if checks in the code to skip it if its ironic because ironic is special | 13:08 |
| tobias-urdin | i mean if we were on newer release with stable uuid feature would nova-compute service fail to start and not report itself as up if there was a conflict like this? | 13:08 |
| sean-k-mooney | it will be less special once the peer_list and hashring is removed | 13:08 |
| sean-k-mooney | yes | 13:09 |
| sean-k-mooney | in antelope it shoudl not start for libvirt | 13:09 |
| sean-k-mooney | to reuse the same hostname you now need to create /var/lib/nova/comptue_node with the old comptue node uuid | 13:09 |
| tobias-urdin | then imo i will just drop the patches and ignore the issue until we are there, it's a edge case that at best helps operators know they have done something wrong (which imo is good, but prob not worth the work here) | 13:10 |
| sean-k-mooney | the placment RP is curated useing the hypervior_hostname as the RP name and the compute node uuid as the rp uuid | 13:10 |
| sean-k-mooney | i prefer your second patch by the way | 13:10 |
| sean-k-mooney | i woudl not be against that approch as a backprot pre antelope | 13:10 |
| sean-k-mooney | if it also didnt raise for ironic | 13:11 |
| tobias-urdin | ack, thx for your time! | 13:13 |
| opendevreview | Merged openstack/nova stable/xena: Unify placement client singleton implementations https://review.opendev.org/c/openstack/nova/+/858999 | 13:22 |
| opendevreview | Merged openstack/nova stable/zed: add a regression test for all compute RPCAPI 6.x pinnings for rebuild https://review.opendev.org/c/openstack/nova/+/900307 | 13:31 |
| opendevreview | Rajesh Tailor proposed openstack/nova-specs master: List requested availability zones https://review.opendev.org/c/openstack/nova-specs/+/904368 | 13:41 |
| ykarel | hi is the issue known checked https://bugs.launchpad.net/nova/+bug/2045785 ? | 13:44 |
| * bauzas reminder : nova meeting in 1.5h here | 14:31 | |
| sean-k-mooney | ykarel: maybe a timeout issue with the tempet test | 14:33 |
| sean-k-mooney | i knwo there is at least one unfixed tempest bug | 14:34 |
| sean-k-mooney | where tempet is not currectly using the instance action events api to determin if voluem detach? has completed | 14:34 |
| sean-k-mooney | so perhaps this test is not waiting properly | 14:34 |
| dansmith | bauzas: FYI, I have a dentist appointment so I'll miss the meeting | 15:01 |
| bauzas | ++ hope you'll be all good :) | 15:01 |
| kashyap | dansmith: Good luck with the dentist :) | 15:58 |
| bauzas | #startmeeting nova | 16:00 |
| opendevmeet | Meeting started Tue Jan 9 16:00:59 2024 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 |
| bauzas | heyho | 16:01 |
| bauzas | happy new year folks ! | 16:01 |
| elodilles | o/ | 16:01 |
| * kashyap waves hi | 16:01 | |
| grandchild | o/ | 16:01 |
| elodilles | happy new year o/ | 16:01 |
| bauzas | #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting | 16:01 |
| opendevreview | Rajesh Tailor proposed openstack/nova master: Add support for showing requested az in output https://review.opendev.org/c/openstack/nova/+/904568 | 16:02 |
| fwiesel | o/ | 16:02 |
| kashyap | bauzas: I had one more item to bring up, but didn't add it to the wiki (bad me) | 16:03 |
| bauzas | ok let's start our first meeting of 0x7E8 | 16:03 |
| bauzas | kashyap: no worries, I'll ping you at the end | 16:03 |
| bauzas | #topic Bugs (stuck/critical) | 16:03 |
| bauzas | #info No Critical bug | 16:03 |
| bauzas | woohoo | 16:03 |
| bauzas | #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 43 new untriaged bugs (-1 since the last meeting) | 16:04 |
| bauzas | thanks folks ! | 16:04 |
| bauzas | #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster | 16:04 |
| bauzas | #info bug baton could be Uggla | 16:04 |
| bauzas | any bug reports you would want to discuss ? | 16:04 |
| bauzas | looks none | 16:05 |
| bauzas | #topic Gate status | 16:05 |
| bauzas | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | 16:05 |
| bauzas | #link https://etherpad.opendev.org/p/nova-ci-failures-minimal | 16:05 |
| bauzas | #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&pipeline=periodic-weekly Nova&Placement periodic jobs status | 16:05 |
| bauzas | all greens | 16:06 |
| bauzas | #info Please look at the gate failures and file a bug report with the gate-failure tag. | 16:06 |
| bauzas | I've seen some post-failure on the zed stable | 16:07 |
| bauzas | but apart from this, nothing else | 16:07 |
| bauzas | anything else ? | 16:08 |
| bauzas | looks not | 16:10 |
| bauzas | #topic Release Planning | 16:10 |
| bauzas | #link https://releases.openstack.org/caracal/schedule.html#nova | 16:10 |
| bauzas | IMPORTANT : | 16:10 |
| bauzas | #info Caracal-2 (and spec freeze) milestone this Thursday | 16:10 |
| bauzas | this means that after Thursday, we would not accept new specs | 16:10 |
| elodilles | note: there is only os-vif with changes worth to release at Caracal-2 it seems: https://review.opendev.org/c/openstack/releases/+/904927 | 16:11 |
| bauzas | I'll try to look at all the already open specs but we already have a lot of accepted specs for this cycle : https://blueprints.launchpad.net/nova/2024.1 | 16:11 |
| bauzas | elodilles: I've seen the email, I'll look at it | 16:11 |
| elodilles | bauzas: ++ | 16:12 |
| bauzas | anything people want to discuss about open specs ? | 16:14 |
| bauzas | looks not | 16:15 |
| bauzas | moving on | 16:15 |
| bauzas | #topic Review priorities | 16:15 |
| bauzas | #link https://etherpad.opendev.org/p/nova-caracal-status | 16:16 |
| bauzas | folks, please look at the etherpad | 16:16 |
| bauzas | I've added all the blueprints in it | 16:16 |
| bauzas | (I actually forgot to add the last blueprint we agreed) | 16:17 |
| kashyap | Thanks for the link; /me bookmarks | 16:18 |
| bauzas | voila | 16:18 |
| bauzas | moving on | 16:18 |
| bauzas | #topic Stable Branches | 16:18 |
| bauzas | elodilles: ? | 16:19 |
| elodilles | #info stable gates are not blocked but patches on older branches can have many rechecks until they get merged | 16:19 |
| elodilles | the usual, i would say. | 16:19 |
| elodilles | #info nova stable Zed release: https://review.opendev.org/c/openstack/releases/+/899604 | 16:19 |
| elodilles | this is waiting for one last patch to merge afaik ^^^ | 16:19 |
| bauzas | indeed | 16:19 |
| elodilles | +1 | 16:19 |
| elodilles | #info according to TC's plan (train and) ussuri branches are proposed to be End of Life if a team is OK with that: https://review.opendev.org/c/openstack/releases/+/903278 | 16:20 |
| sean-k-mooney | yep | 16:20 |
| sean-k-mooney | can we proceed with that | 16:20 |
| bauzas | I'll look at the Ussuri EOL change and if everything is OK, I'll +1 it | 16:21 |
| elodilles | the patch needs a PTL / release liaison +1 | 16:21 |
| elodilles | otherwise i think it's OK | 16:21 |
| elodilles | bauzas: thx | 16:21 |
| elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | 16:21 |
| elodilles | and that's all from me | 16:21 |
| bauzas | cool | 16:21 |
| bauzas | thanks elodilles for reporting | 16:22 |
| bauzas | #topic vmwareapi 3rd-party CI efforts Highlights | 16:22 |
| fwiesel | #Info Access to logs was blocked automatically thanks to corporate policy. Working on exemption. | 16:22 |
| bauzas | cool | 16:22 |
| fwiesel | So, the link I provided was promptly automatically shut down. Nothing says IaaS like introducing a ticket process on top of it. | 16:22 |
| fwiesel | #Info Limited external network access from test infrastructure with allow-list (currently: opendev.org, pypi.org). | 16:22 |
| fwiesel | The test infrastructure is now fairly locked down, we probably need to figure out, what we have to add to the allow-list. | 16:23 |
| fwiesel | But at least, that way we feel more comfortable running essentially random stuff from the internet. | 16:23 |
| fwiesel | That's it more or less from my side. Any questions? | 16:23 |
| bauzas | nope for me :) | 16:24 |
| bauzas | thanks for reporting :) | 16:24 |
| fwiesel | You're welcome. Any happy new year. | 16:24 |
| bauzas | you too | 16:24 |
| bauzas | #topic Open discussion | 16:24 |
| auniyal | bauzas, I have one bug to discuss/share | 16:24 |
| auniyal | we got the bug w.r.t clean dangling volume patch | 16:25 |
| auniyal | https://bugs.launchpad.net/nova/+bug/2048154 | 16:25 |
| auniyal | https://bugs.launchpad.net/nova/+bug/2048184 | 16:25 |
| bauzas | nothing in the wikipage, but kashyap had one point | 16:25 |
| kashyap | Yeah | 16:25 |
| kashyap | So it's about this specless blueprint - a suggestion that came from sean-k-mooney: https://blueprints.launchpad.net/nova/+spec/allow-disabling-ephemeral-disk-formatting | 16:25 |
| kashyap | The main motivation (as I understand it) seems to be the following: | 16:25 |
| kashyap | (1) To explore removal of libguestfs / and unneeded dependencies | 16:26 |
| kashyap | (2) Doing so will help reduce security/package footprint from containers that might be shipping nova-compute. | 16:26 |
| kashyap | Today libguestfs' usage seems to be in the area of file injection and ephemeral disk creation. | 16:27 |
| bauzas | to be clear, the default would be "formatted", right? | 16:27 |
| kashyap | I think so, yes. I need to check. | 16:27 |
| kashyap | bauzas: That said, putting my upstream hat on: | 16:27 |
| bauzas | we can't really change our current behaviour so I'd prefer to keep the current usage by default | 16:28 |
| bauzas | but of course, if operators and products want to not use libguestfs, they can change the option value | 16:28 |
| kashyap | We should also bear in mind that libguestfs provides many other "adjacent tools" (e.g. an incomplete list: https://paste.opendev.org/show/bfNahtW5QJVeYSQUNaFH/) that operators might be using. | 16:29 |
| bauzas | there could be some nits on the values of the items for this config option | 16:29 |
| kashyap | (These "adjacent tools" are all to do with disk images, etc. They're extremely useful. So even for downstreams I'd be wary of suggesting to 'drop' libguestfs.) | 16:29 |
| bauzas | but looks to me some implementation question, not a design one | 16:29 |
| kashyap | bauzas: Yeah, the nits could be worked out. But yeah, the devil is in the implementation indeed. | 16:30 |
| bauzas | kashyap: do you remember the current defaults we have for ephemeral disks ? ext4 ? | 16:30 |
| kashyap | Quickly checking... | 16:31 |
| bauzas | this would mean that we would need to provide all the supported disk formats in the config option items | 16:31 |
| bauzas | maybe people don't want this, right? | 16:31 |
| kashyap | (I'd think so, it'd be one of ext3) | 16:31 |
| bauzas | are we able to format our disks by something else but the default format ? | 16:31 |
| bauzas | I can quickly look at the code | 16:32 |
| kashyap | (There's several places the CONF.default_ephemeral_format is used - I guess you're looking for this?) | 16:34 |
| bauzas | nope, I just wonder the negative value of 'unformatted' which then would be the default | 16:37 |
| kashyap | bauzas: The current default is ext4, as I see it | 16:38 |
| bauzas | everything seems to be handled by this module https://github.com/openstack/nova/blob/master/nova/virt/disk/vfs/guestfs.py | 16:38 |
| kashyap | It depends on what you mean by "everything" :) I think you mean everything related to libguestfs. But we don't have to get into the details of it here. | 16:39 |
| bauzas | anyway, I'm OK to approve this specless blueprint but we'll need to make sure that the default behaviour is continuing to support to format the ephemeral disk | 16:39 |
| bauzas | sean-k-mooney: any concern by what I said ? | 16:40 |
| kashyap | Please add that remark in the BP. I need to still explore what makes sense here | 16:40 |
| kashyap | But also I need to hear if anyone actually needs this. We shouldn't do needless work | 16:40 |
| kashyap | I have a hard stop in 5 minutes; afraid. I need to visit a friend in a hospital. Can discuss the rest afterwards | 16:41 |
| bauzas | anyone not wanting to accept this blueprint ? | 16:41 |
| bauzas | if not, | 16:41 |
| bauzas | #agreed https://blueprints.launchpad.net/nova/+spec/allow-disabling-ephemeral-disk-formatting is approved as specless, provided it defaults to format the disks | 16:42 |
| bauzas | kashyap: ^ | 16:42 |
| kashyap | Okay; for now we can go ahead; thank you | 16:43 |
| bauzas | ++ | 16:44 |
| bauzas | auniyal: you wanted to discuss a specific bug ? | 16:44 |
| auniyal | yeah - we got this bug https://bugs.launchpad.net/nova/+bug/2048154 | 16:45 |
| auniyal | similar to this - https://bugs.launchpad.net/nova/+bug/2048184 | 16:45 |
| auniyal | I have created a patch - https://review.opendev.org/c/openstack/nova/+/904817 | 16:45 |
| bauzas | add your patch proposals into https://etherpad.opendev.org/p/nova-caracal-status | 16:46 |
| auniyal | sean-k-mooney for " source_type: snapshot and source_type:image" | 16:46 |
| auniyal | is it snapshot image | 16:46 |
| auniyal | I created snapshot of Vm then Vm from that snapshot, but their source_type was sa same as original vm | 16:47 |
| bauzas | auniyal: add your patches into https://etherpad.opendev.org/p/nova-caracal-status#L114 so people could review them | 16:47 |
| auniyal | ack bauzas | 16:47 |
| bauzas | I think we're done for the meeting | 16:48 |
| bauzas | auniyal: we don't really discuss bugs in the nova meeting | 16:48 |
| bauzas | but if you want, please ping other folks after we end this meeting | 16:48 |
| auniyal | ack | 16:48 |
| auniyal | bauzas, I added the patch in etherpad | 16:49 |
| bauzas | ok, thanks all then | 16:49 |
| bauzas | and happy new year again | 16:50 |
| bauzas | #endmeeting | 16:50 |
| opendevmeet | Meeting ended Tue Jan 9 16:50:04 2024 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:50 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2024/nova.2024-01-09-16.00.html | 16:50 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2024/nova.2024-01-09-16.00.txt | 16:50 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2024/nova.2024-01-09-16.00.log.html | 16:50 |
| elodilles | thanks o/ | 16:50 |
| opendevreview | Amit Uniyal proposed openstack/nova master: Refactor vf profile for PCI device https://review.opendev.org/c/openstack/nova/+/905134 | 17:00 |
| sean-k-mooney | auniyal: i was refering to a volume created form a volume snapshot | 17:01 |
| sean-k-mooney | bauzas: sorry i was on another call | 17:02 |
| sean-k-mooney | bauzas: but know i dont have an objection ot https://blueprints.launchpad.net/nova/+spec/allow-disabling-ephemeral-disk-formatting being specless | 17:02 |
| sean-k-mooney | bauzas: and ya the default should not change from today | 17:03 |
| sean-k-mooney | you shoudl just have the option of configuring it to be unformatted. and not require libguestfs as a result | 17:03 |
| sean-k-mooney | but no change of behavior by defaul | 17:03 |
| opendevreview | Amit Uniyal proposed openstack/nova stable/2023.2: Refactor vf profile for PCI device https://review.opendev.org/c/openstack/nova/+/905135 | 17:05 |
| opendevreview | Amit Uniyal proposed openstack/nova stable/2023.1: Refactor vf profile for PCI device https://review.opendev.org/c/openstack/nova/+/905137 | 17:07 |
| opendevreview | Amit Uniyal proposed openstack/nova stable/zed: Refactor vf profile for PCI device https://review.opendev.org/c/openstack/nova/+/905138 | 17:08 |
| bauzas | sean-k-mooney: my only implementation concern is what we would provide as a option value for continuing to format the disk | 17:15 |
| bauzas | should it be "formatting" or "ext4" or something else | 17:16 |
| sean-k-mooney | well the propsasl is to extend the existing enum value with unformated | 17:19 |
| sean-k-mooney | and leave the existing behavior unchaged | 17:20 |
| sean-k-mooney | the current formating is driver speciric | 17:20 |
| sean-k-mooney | and we also look at the OS_TYPE metadta if set on the instnace image | 17:20 |
| sean-k-mooney | for linux i belive we default to ext4 but use fat32 or ntfs for windows | 17:21 |
| sean-k-mooney | non of that behavior needs to change | 17:21 |
| sean-k-mooney | we just need to add unformated ot https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.default_ephemeral_format | 17:21 |
| sean-k-mooney | an yes so looking at the docs windows guest use ntfs by default | 17:22 |
| sean-k-mooney | so the default will still be None meaning the virt driver chooses | 17:22 |
| sean-k-mooney | bauzas: on a related note i want to remove some config options that should have been removed a long time ago but i need to deprecate them first. | 17:23 |
| sean-k-mooney | obviously we need to agree to do that but is that something yoru happy to agree on via gerrirt or do you want me to file something | 17:24 |
| sean-k-mooney | i want to for https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.vif_plugging_is_fatal to be true and remove it as an option or at least move it to workarounds | 17:24 |
| sean-k-mooney | you shoudl not run with vif_plugging_is_fatal=false in production | 17:25 |
| sean-k-mooney | ever | 17:25 |
| sean-k-mooney | so i want to deprecate that in this release and then condier removing it next cycle | 17:25 |
| opendevreview | Amit Uniyal proposed openstack/nova master: Refactor vf profile for PCI device https://review.opendev.org/c/openstack/nova/+/905134 | 17:26 |
| opendevreview | Amit Uniyal proposed openstack/nova master: Refactor vf profile for PCI device https://review.opendev.org/c/openstack/nova/+/905134 | 17:35 |
| opendevreview | Merged openstack/nova stable/xena: Avoid n-cond startup abort for keystone failures https://review.opendev.org/c/openstack/nova/+/859000 | 18:40 |
| sean-k-mooney | bauzas: can you review this spec tomorrow its trivial but required as its an api change https://review.opendev.org/c/openstack/nova-specs/+/904368 | 19:04 |
| opendevreview | Merged openstack/nova stable/zed: Fix rebuild compute RPC API exception for rolling-upgrades https://review.opendev.org/c/openstack/nova/+/900341 | 20:38 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!