opendevreview | Vasyl Saienko proposed openstack/nova master: [ironic] Fix rebooting instance https://review.opendev.org/c/openstack/nova/+/918195 | 05:24 |
---|---|---|
gibi | bauzas: do you have anything special for today's nova meeting for me to not forget? | 06:25 |
bauzas | gibi: nothing special, but I'll create a change for the schedule deadlines | 06:28 |
bauzas | for the review priorities, I'll also modify the etherpad | 06:28 |
gibi | ack, thanks | 06:38 |
bauzas | thanks again for running the meeting | 06:49 |
bauzas | fwiw, I'm eventually taking my afternoon off ( I was about to stop at 4pm, so I prefer just to take the whole afternoon) | 06:50 |
bauzas | and I'll be back on Monday | 06:50 |
bauzas | (Wed + Thur are bank holidays here) | 06:50 |
gibi | bauzas: have a nice time off | 07:01 |
bauzas | thanks, visiting long distance friends :) | 07:21 |
opendevreview | Sylvain Bauza proposed openstack/nova master: mtty: add devstack compilation for fedora builds https://review.opendev.org/c/openstack/nova/+/918420 | 09:11 |
bauzas | gibi: I just uploaded https://review.opendev.org/c/openstack/releases/+/918422 which is the Dalmatian schedule for nova | 09:42 |
bauzas | gibi: actually we will have a spec review day on next Tuesday | 09:42 |
bauzas | I'll just write an email | 09:42 |
bauzas | but please tell it during the nova meeting | 09:42 |
gibi | sure I will | 11:10 |
sean-k-mooney | JayF: feel free to rework my base patch as needed | 11:46 |
*** haleyb is now known as haleyb|out | 12:40 | |
opendevreview | Fabian Wiesel proposed openstack/nova master: Vmware: Remove uuid parameter from get_vmdk_info call https://review.opendev.org/c/openstack/nova/+/910627 | 12:45 |
opendevreview | Elod Illes proposed openstack/nova stable/2023.2: DNM: grenade-skip-level fix https://review.opendev.org/c/openstack/nova/+/918454 | 14:34 |
ganso | gibi: hi! I would like to ask you about https://review.opendev.org/c/openstack/nova/+/822050 and https://review.opendev.org/c/openstack/nova/+/810915 | 15:18 |
opendevreview | Dan Smith proposed openstack/nova master: Enable virtio-scsi in nova-next https://review.opendev.org/c/openstack/nova/+/918458 | 15:21 |
ganso | gibi: I copied the entire nova/tests/functional/libvirt/test_numa_servers.py file resulted from applying all 5 patches in ussuri and placed it in the 21.2.4 tag (where the fixes do not exist) and ran the functional text. The 2 new tests are still passing | 15:21 |
dansmith | sean-k-mooney: ^ | 15:21 |
ganso | gibi: is there anything that I am doing wrong? or is it that due to being a race condition sometimes the test will not fail? | 15:21 |
gibi | ganso: could you push what you have locally to gerrit so I can look at it? | 15:37 |
gibi | ganso: the test are stable in newer branches but maybe something changed in nova inbetween that making the tests invalid | 15:38 |
gibi | folks, nova meeting starts in 13 minutes here on the channel. | 15:47 |
ganso | gibi: ok I just realized what I did wrong, I was running the tests in a container, using "tox -efunctional-py38 -vv --skip-missing-interpreters=false | 15:52 |
ganso | gibi: just like the CI is doing, as I expected that I wouldn't have to deploy a real env for that | 15:52 |
ganso | gibi: but not functional tests are really running, just unit tests | 15:52 |
ganso | gibi: I tried forcing it to run only the numa tests and it says it doesn't match anything | 15:53 |
ganso | gibi: "tox -efunctional-py38 -vv --skip-missing-interpreters=false -- nova.tests.functional.libvirt.test_numa_servers" | 15:53 |
ganso | gibi: how is the CI job running it without a full deployment? do I need to set a parameter or flag? | 15:54 |
ganso | gibi: https://0b2ab51d56a67edcd93c-a3ef59e9a62996701b6308cf25770b88.ssl.cf2.rackcdn.com/918195/6/check/nova-tox-functional-py38/cb62697/job-output.txt | 15:54 |
ganso | gibi: I am deploying a focal-ussuri env in parallel just in case it really needs a real env to run | 15:54 |
clarkb | ganso: are you running the test-setup.sh step? I dont' really know anything about nova's functional tests but that is a step the CI jobs take and the log you link confirms it is running | 15:55 |
ganso | clarkb: hmm no. I just tried to run it and it tried to run a mysql command. I just installed mysql and ran it again, and it says the syntax is wrong... | 15:58 |
gibi | ganso: check tox.ini to see what envs are defined in ussrui | 16:00 |
gibi | but now, lets have a quick nova meeting | 16:00 |
gibi | #startmeeting nova | 16:00 |
opendevmeet | Meeting started Tue May 7 16:00:44 2024 UTC and is due to finish in 60 minutes. The chair is gibi. 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 |
erlon | o/ | 16:01 |
tkajinam | o/ | 16:01 |
gibi | bauzas is off today, so I will be your chair | 16:01 |
auniyal | o/ | 16:01 |
elodilles | o/ | 16:01 |
sean-k-mooney | dansmith: using local.sh works too | 16:01 |
sean-k-mooney | o/ | 16:01 |
fwiesel | o/ | 16:01 |
gibi | #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting | 16:01 |
dansmith | o/ | 16:01 |
gibi | #topic Bugs (stuck/critical) | 16:02 |
gibi | #info No Critical bug | 16:02 |
gibi | is there any bug that needs discussion today? | 16:03 |
erlon | Must be critical I suppose? | 16:03 |
auniyal | gibi, not critical but seems imp to me https://bugs.launchpad.net/nova/+bug/2063342 | 16:04 |
tkajinam | this is not very critical now but there is one remaining follow-up about excludes cleanup. would be nice if it can get 2nd +2 https://review.opendev.org/c/openstack/os-traits/+/917713 | 16:04 |
gibi | erlon: if you feel it worth discussing with the foks then sure | 16:04 |
erlon | So, I need some reviews on the RBAC support patch. Its the last one fron the series: https://review.opendev.org/c/openstack/nova/+/811521?usp=search | 16:05 |
gibi | erlon: OK, noted. | 16:06 |
erlon | thanks | 16:06 |
gibi | auniyal: my immediate reaction that bug is to ask if they tried to archive deleted rows | 16:07 |
erlon | Should I add it to the etherepad or you do? | 16:07 |
gibi | erlon: I will | 16:07 |
erlon | Thanks | 16:08 |
gibi | auniyal: but reading it more it is about instance action | 16:08 |
gibi | growing without bound for non deleted instances | 16:08 |
sean-k-mooney | erlon's patch is for a blueprint that is not approved | 16:09 |
auniyal | yes, can we add some preodic updated nova can do to DB | 16:09 |
gibi | and I see they proposed a nova-manage command to trim the action list. We at least need a blueprint for it | 16:09 |
sean-k-mooney | so it need to be appoved here first before we can proceed with it | 16:09 |
sean-k-mooney | https://blueprints.launchpad.net/nova/+spec/shared-security-groups | 16:10 |
erlon | what does that require? to aprove? | 16:10 |
sean-k-mooney | agreement that this does not requrie a spec and that we are ok to proceed with adding supprot for neutron SRBC for security groups to nova | 16:11 |
sean-k-mooney | basically this is a case of the new feature was added to neutron a few release ago and the nova side was not done | 16:11 |
erlon | ok, so I suppose that the blueprint was mostly a formality | 16:11 |
sean-k-mooney | well no the blueprint is alwasy requried for features like this but the quetion is does it also need a spec | 16:12 |
erlon | a spec seems a overkill | 16:13 |
gibi | erlon: does it need any nova API, db, RPC, or object model changes? Does it have upgrade impct? | 16:13 |
sean-k-mooney | in this particalr case there is not direct api impact. do we want to move this to the opendicussion stection by the way | 16:13 |
sean-k-mooney | or resolve this now | 16:13 |
gibi | lets resolve it | 16:14 |
sean-k-mooney | the reason i say there is no direct api impact is the api bechiaov changes but the requesst does not and i dont think we need a microversion | 16:14 |
gibi | OK. | 16:14 |
sean-k-mooney | so without this feature you can only reference secuirty groups that are created in your project | 16:14 |
gibi | I see it depends on a new neutron extension | 16:14 |
erlon | @gibi, no, just adds some calls to neutron client | 16:14 |
sean-k-mooney | with this feature you can use a secrutiy group defiend in another project but shread with your project | 16:15 |
sean-k-mooney | so before the change you would have got a error and after the vm would boot | 16:15 |
gibi | sean-k-mooney: that is a reasonable behavior change | 16:15 |
sean-k-mooney | yep its tradign a vm in error due to SecurityGroupNotFound: Security group 0c649378-1cf8-48e0-9eb4-b72772c35a62 not found. in swpan | 16:16 |
sean-k-mooney | for a booting vm | 16:16 |
sean-k-mooney | so i dont think that a breaking change and therfor no api impact | 16:16 |
sean-k-mooney | gibi: erlon has a patch for review https://review.opendev.org/c/openstack/nova/+/811521 and the code changes are confied to the neutorn module in nova | 16:17 |
gibi | There is a preformance impact discussed in the impl, does that sever enough to pull it out to a spec? | 16:17 |
sean-k-mooney | the performace impact is 1 addtion call to list security group that are shared with you | 16:17 |
gibi | as far as I see if you don't use shared SG then you don't have the extra overhead | 16:18 |
sean-k-mooney | based on the trace back in the bug it got to the comptue manger beforfe that happend | 16:18 |
sean-k-mooney | so i think that ok | 16:18 |
gibi | OK. I'm not against approving this without a spec | 16:18 |
sean-k-mooney | am well no we dont know fi its shared or not | 16:18 |
sean-k-mooney | but we only need to make the call if neutron has the extention | 16:19 |
gibi | sean-k-mooney: I mean if the deployment doesn't use share SGs the the first query will find the grouo | 16:19 |
gibi | scratch it, I'm wrong | 16:19 |
sean-k-mooney | well if we reorded https://review.opendev.org/c/openstack/nova/+/811521/8/nova/network/neutron.py | 16:20 |
sean-k-mooney | we proably could avoid that ya | 16:20 |
gibi | anyhow I'm OK to approve this and continue discussing the impl | 16:20 |
gibi | do we feel we have chorum without bauzas ? | 16:20 |
sean-k-mooney | so im not against doing this as specless and ya defering to the gerrit review | 16:20 |
sean-k-mooney | dansmith: what do you think? | 16:20 |
gibi | quorum even | 16:21 |
sean-k-mooney | i dont know if gmann is around either | 16:21 |
sean-k-mooney | im tentivly ok with saying yes but mabey we can double check next week | 16:21 |
sean-k-mooney | "yes" -> approve this as specless and move discuuion to gerrit review | 16:22 |
gibi | OK. lets discuss it next week with the others around | 16:22 |
dansmith | yeah, sorry, multitasking | 16:22 |
gibi | ack, lets get back to this next week then | 16:23 |
dansmith | looks like basic enablement of a neutron feature though, | 16:23 |
dansmith | so unless it breaks some nova-side model it seems like specless would be fine | 16:23 |
gibi | OK | 16:23 |
dansmith | but also think it's probably fine/good to wait for bauzas anyway | 16:23 |
gibi | then I will let bauzas know that is it OK to approve from our side | 16:24 |
dansmith | ++ | 16:24 |
gibi | thanks | 16:24 |
gibi | #action bauzas to approve //blueprints.launchpad.net/nova/+spec/shared-security-groups if he don't disagree | 16:24 |
opendevreview | ribaudr proposed openstack/nova-specs master: Update and Re-propose "Allow Manila shares to be directly attached to an instance when using libvirt" for Dalmatian https://review.opendev.org/c/openstack/nova-specs/+/913997 | 16:25 |
gibi | tkajinam: I will check https://review.opendev.org/c/openstack/os-traits/+/917713 after the meeting | 16:25 |
gibi | any other bug to discuss? | 16:26 |
tkajinam | gibi, thx | 16:27 |
gibi | moving on | 16:27 |
gibi | #topic Gate status | 16:27 |
gibi | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | 16:27 |
gibi | #link https://etherpad.opendev.org/p/nova-ci-failures-minimal | 16:28 |
gibi | #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&pipeline=periodic-weekly Nova&Placement periodic jobs status | 16:28 |
gibi | emulation job failed on zed and antelope | 16:28 |
gibi | ohh actually failed on every branch | 16:29 |
sean-k-mooney | fun anything obvious | 16:29 |
gibi | this is the master failure https://f267574198a517c003d1-a40b9478ae1bd073dc32f331038fe6d7.ssl.cf5.rackcdn.com/periodic-weekly/opendev.org/openstack/nova/master/nova-emulation/825cc9a/testr_results.html | 16:29 |
gibi | I did not dig deeper | 16:30 |
auniyal | I added this https://review.opendev.org/c/openstack/tempest/+/918439 for same - is there a way we can run priodic depends on this ? | 16:30 |
auniyal | it only adds req-id | 16:30 |
gibi | would be nice to see if the failures on each branch are the same or not | 16:30 |
sean-k-mooney | Instance failed to spawn: oslo_messaging.rpc.client.RemoteError: Remote error: DBConnectionError (pymysql.err.OperationalError) (2013, 'Lost connection to MySQL server during query') | 16:30 |
sean-k-mooney | so maybe an oom kill | 16:30 |
sean-k-mooney | of the db | 16:31 |
auniyal | I saw this for antelope https://zuul.openstack.org/build/183dfe690ad44431b023ef95ec347bd9 | 16:31 |
gibi | OK, I can check the logs tomorrow for possible oom | 16:31 |
dansmith | emulation being slower, oom kill seems likely I bet | 16:31 |
sean-k-mooney | we can move on lill quickly tak a look | 16:32 |
gibi | #action gibi to check the nova-emulation periodic failures for oom kill events | 16:32 |
gibi | any other gate issue we need to discuss today? | 16:32 |
sean-k-mooney | ay 04 08:51:02 np0037439600 kernel: nova-compute invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0 | 16:33 |
gibi | nice catch | 16:33 |
sean-k-mooney | oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/system.slice/mysql.service,task=mysqld,pid=63525,uid=116 | 16:33 |
sean-k-mooney | so nova trigered it and it kills mysql | 16:33 |
sean-k-mooney | which is why the job was unhappy | 16:34 |
gibi | could you please file a bug for it? if you cannot the I will file it tomorrow | 16:34 |
sean-k-mooney | sure this might jut need swap or some tweak to the concurancy | 16:34 |
gibi | ack, thanks | 16:34 |
gibi | moving on | 16:34 |
gibi | #topic Release Planning | 16:34 |
gibi | #link https://releases.openstack.org/dalmatian/schedule.html | 16:35 |
gibi | #link https://review.opendev.org/c/openstack/releases/+/918422 nova specific schedule is proposed | 16:35 |
gibi | #info Dalmatian-1 in 1 week | 16:35 |
gibi | #info Spec review day is next Tuesday (14th of May) | 16:35 |
gibi | anything else about the release? | 16:36 |
gibi | #topic Review priorities | 16:37 |
gibi | #link https://etherpad.opendev.org/p/nova-dalmatian-status | 16:37 |
gibi | bauzas update the status etherpad | 16:37 |
gibi | *updated | 16:37 |
gibi | any questions about the priorities? | 16:37 |
gibi | #topic Stable Branches | 16:38 |
gibi | elodilles: your turn | 16:38 |
elodilles | yepp, so | 16:38 |
elodilles | #info no recent merges, but stable/2024.1 gate should be OK | 16:38 |
elodilles | #info stable/2023.2 gate is broken due to grenade-skip-level job (fix: https://review.opendev.org/c/openstack/grenade/+/918452 ) | 16:39 |
elodilles | and it seems meanwhile, that the fix is not enough, as e.g. keystone haven't transitioned to unmaintained yet :S | 16:39 |
elodilles | #info stable/2023.1 gate is probably also broken due to grenade job, probably same issue | 16:40 |
elodilles | i'll try to look further tomorrow | 16:40 |
gibi | thanks | 16:40 |
elodilles | i've updated the stable gate pad: | 16:40 |
elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | 16:41 |
elodilles | will continue to update that, too | 16:41 |
elodilles | that's all from me | 16:41 |
gibi | thanks elodilles | 16:41 |
elodilles | np | 16:41 |
gibi | any other stable topic from others? | 16:41 |
gibi | #topic vmwareapi 3rd-party CI efforts Highlights | 16:42 |
gibi | from the agenda | 16:42 |
gibi | #info Fixing some "lost" changes | 16:42 |
fwiesel | Hi, that's me... | 16:43 |
gibi | sure go ahead | 16:43 |
fwiesel | So, the way I get the changes are via ssh stream, if that gets restarted and there is a new change, that one would get lost. | 16:43 |
opendevreview | Merged openstack/os-traits master: Bump min versions to exclude known bad versions https://review.opendev.org/c/openstack/os-traits/+/917713 | 16:43 |
fwiesel | I work on polling all past changes to fix that. | 16:43 |
fwiesel | That's from my side, unless there are any questions? | 16:44 |
gibi | fwiesel: thanks for the update | 16:44 |
gibi | and the continued effort on the CI | 16:44 |
gibi | if no question from others then we move to our last topic today | 16:45 |
gibi | #topic Open discussion | 16:46 |
gibi | nothing on the agenda | 16:46 |
gibi | does anybody has anything else for today? | 16:46 |
tkajinam | nothing from me. | 16:47 |
gibi | It seem we are done for today. | 16:47 |
gibi | thanks for joining | 16:47 |
gibi | have a nice rest of the day | 16:47 |
gibi | #endmeeting | 16:47 |
opendevmeet | Meeting ended Tue May 7 16:47:50 2024 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:47 |
opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2024/nova.2024-05-07-16.00.html | 16:47 |
opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2024/nova.2024-05-07-16.00.txt | 16:47 |
opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2024/nova.2024-05-07-16.00.log.html | 16:47 |
elodilles | thanks o/ | 16:48 |
fwiesel | Thanks | 16:48 |
opendevreview | sean mooney proposed openstack/nova master: tweak emulation job to avoid OOM errors https://review.opendev.org/c/openstack/nova/+/918464 | 16:48 |
sean-k-mooney | gibi: i think ^ will fix the emulation job | 16:49 |
gibi | ganso: as far as I see in ussuri the functional env called functional | 16:49 |
gibi | so tox -e functional should work | 16:49 |
tkajinam | I wonder if we have any core time concept for review spec days. I'll try to be available around the irc meeting time anyway. | 16:49 |
gibi | tkajinam: I think there are no core time for it | 16:50 |
opendevreview | sean mooney proposed openstack/nova master: [DNM] test nova-emulation https://review.opendev.org/c/openstack/nova/+/918465 | 16:50 |
tkajinam | gibi, ok, thanks. that's what I guessed. | 16:52 |
sean-k-mooney | dansmith: by the way as far as im aware for the libvirt driver virtio-scsi should be the default scsi modle when you enable it with hw_disk_bus=scsi | 16:52 |
dansmith | sean-k-mooney: it is most definitely not | 16:52 |
dansmith | defaults to lsilogic | 16:53 |
sean-k-mooney | looking at the code paths it looks like there might be a second way to get a contoler | 16:53 |
dansmith | took me a while while debugging to realize it was working, but cirros didn't have drivers for lsi | 16:53 |
sean-k-mooney | so i dont knwo fi we regressed it then | 16:53 |
sean-k-mooney | beucase at one point it was virtio-scisi | 16:54 |
sean-k-mooney | we doucmented it as vrito-scsi here https://github.com/openstack/glance/blob/master/etc/metadefs/compute-libvirt-image.json#L65-L69 | 16:54 |
sean-k-mooney | in libverty | 16:55 |
dansmith | just sayin' it doesn't work for me locally unless I set that | 16:55 |
sean-k-mooney | what do you have hw_disk_bus set too | 16:56 |
sean-k-mooney | it looks like we have 2 ways to get a scsi contoler either we get fone form seting hw_scsi_modle here https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L5794 | 16:57 |
sean-k-mooney | or we get one by setign hw_disk_bus or hw_cdrom_bus to scsi | 16:57 |
sean-k-mooney | i was aware of the latter two options but i didnt knwo about https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L5923 | 16:58 |
dansmith | I don't have disk_bus set on the image or flavor, but it _is_ set in the BDM of courtse | 16:58 |
opendevreview | Dan Smith proposed openstack/nova master: Enable virtio-scsi in nova-next https://review.opendev.org/c/openstack/nova/+/918458 | 16:59 |
dansmith | forgot the zuul bit ^ | 16:59 |
sean-k-mooney | oh including the playbook ya | 16:59 |
dansmith | yeah, duh | 17:00 |
sean-k-mooney | so realted quetion | 17:00 |
sean-k-mooney | if we are trying to test this with BFV or even a data volume | 17:00 |
sean-k-mooney | to we really need to set this on the image | 17:00 |
sean-k-mooney | or can it be set on the voulume createf from the image | 17:01 |
dansmith | it only works on the image, FWIW.. doesn't work on the flavor | 17:01 |
sean-k-mooney | well it should not work on the flaovr | 17:01 |
dansmith | also, BFV in this case doesn't work.. there's some other bug that we hit when it tries | 17:01 |
sean-k-mooney | ok | 17:01 |
dansmith | ack, well, it doesn't, but I expected it to because it's a hardware sort of thing | 17:01 |
sean-k-mooney | then that answer my quetion regrading data voluem with a data volume we take the info form the root disk | 17:02 |
sean-k-mooney | basically i was wondering if in teh tempest test we coudl create a volmue form the glance image | 17:03 |
gmann | gibi: sean-k-mooney: RE on SG BP. I cannot join the Nova meeting as it conflicts with the time I drop my son to school. I checked the BP/code change https://blueprints.launchpad.net/nova/+spec/shared-security-groups | 17:03 |
sean-k-mooney | then update the image properites on teh volume to add it | 17:03 |
sean-k-mooney | and then boot form the volume | 17:03 |
sean-k-mooney | to avoid needing to configure this in the job | 17:03 |
sean-k-mooney | gmann: no worries | 17:03 |
gmann | gibi: sean-k-mooney: it seems ok to approve specless, there is no interface or API change here, SecurityGroupNotFound error can occur in any case even no SG in tenant or so and adding to get shared SG does not change it even improve to avoid notFound cases | 17:04 |
opendevreview | Vasyl Saienko proposed openstack/nova master: [ironic] Fix rebooting instance https://review.opendev.org/c/openstack/nova/+/918195 | 17:04 |
sean-k-mooney | gmann: ya i had a simialr feeling. the secuirty gorup could also have been delete between the vm create request being accpeted by the api and the swapn on the compute | 17:05 |
gmann | and as it check the neutron extension enable or not, we have the discovery path also for inteop point of view | 17:05 |
gmann | sean-k-mooney: yeah | 17:05 |
sean-k-mooney | gmann: so its always possibel that this would fail the way it is now | 17:05 |
sean-k-mooney | dansmith: so i think there is some funky interaction between specifying block_device_mapping_v2.disk_bus vs haveign hw_disk_bus=scsi on the image | 17:09 |
sean-k-mooney | as far as im waware we dont offically supprot having multiple diffent disk buses in a nova inastance at once | 17:10 |
sean-k-mooney | however using bdms you could achive that | 17:10 |
sean-k-mooney | i tought on of the geneal probelms with that was that we did nto have the correct code to create teh requried contolers | 17:12 |
sean-k-mooney | i.e. scsi contoler in this case but i think your hiiting that other code path | 17:12 |
dansmith | sean-k-mooney: I don't know that's true.. without the hw_scsi_model I can still request the disk_bus=scsi, and I get a lsilogic controller, I just don't have the drivers | 17:13 |
sean-k-mooney | dansmith: so i think that a bug | 17:14 |
sean-k-mooney | or libvirt defaulting is happeing | 17:14 |
sean-k-mooney | if you try doing that for stata | 17:14 |
sean-k-mooney | i dont think it will work | 17:14 |
dansmith | the docs for hw_scsi_model also don't say that you can request lsi, it only says that if it's set, you can set it to virtio, which kinda implies it's not virtio by default | 17:14 |
sean-k-mooney | my understanding was hw_scsi_model was only ment to be coniderd if hw_disk_bu, hw_cdrom_bus or hw_rescuse bus was set to scsi | 17:15 |
sean-k-mooney | i.e. i did not exepct it to be used just bey settign disk_bus=scsi in the bdms | 17:16 |
sean-k-mooney | evedently it can be | 17:16 |
dansmith | I guess it doesn't seem reasonable to force all block devices to scsi in order to be able to have one as scsi | 17:16 |
dansmith | meaning, sata for everything and scsi for this special direct lun volume makes sense, no/ | 17:16 |
sean-k-mooney | well we dont support having diffent disk on diffent busses in general | 17:17 |
sean-k-mooney | i.e. if you have root swap and multiple ephmeral volumes | 17:17 |
sean-k-mooney | then by default they are all specified vai hw_disk_bus | 17:17 |
sean-k-mooney | you could use the bdm api with destion_type=local | 17:18 |
sean-k-mooney | at leat for epmeral disk i think | 17:18 |
sean-k-mooney | but i have never seen that documented or recommended before | 17:18 |
dansmith | well, we do for ide cd and sata/scsi root disk right? | 17:19 |
sean-k-mooney | i always found block_device_mapping_v2.disk_bus (Optional) odd because i didnt knwo fo a supproted usecase wehre it could ever be diffent then the root disk | 17:19 |
dansmith | given the BDM takes a disk_bus, I think it's sort of implied that you should be able to ... you know, select it | 17:19 |
sean-k-mooney | for q35 ya | 17:19 |
sean-k-mooney | its implied but i dotn think we docuement or test it | 17:20 |
sean-k-mooney | like this has been somethign that has bugged me for years because i tied to do that in the past and it didnt appear to work | 17:20 |
sean-k-mooney | so i have alwasy wondered why its there if it does nto work | 17:20 |
sean-k-mooney | anyway you made it work but to me this still feels like a grey area | 17:21 |
sean-k-mooney | our docs https://docs.openstack.org/nova/latest/user/block-device-mapping.html#block-device-mapping-v2 still say "Leaving these empty is the most common thing to do" with regards to disk_bus and device_type | 17:23 |
sean-k-mooney | so i alwasy tough these we hold overs form bdm v1 with no reall usecase now outside fo device_type=cdrom for cinder vomues created form install isos | 17:25 |
dansmith | IMHO it shouldn't be grey.. it might be because of other problems we have, but I see no reason not to allow picking the bus per device | 17:25 |
sean-k-mooney | we can my issue is not with the feature | 17:25 |
sean-k-mooney | its with the testing fo that | 17:25 |
sean-k-mooney | i.e. i dont think we have tempest coverage of this in general | 17:26 |
sean-k-mooney | as far as im aware the only tempest test we hav efor attaching a device to a speicic disk bus is https://github.com/openstack/tempest/blob/ccd034eb3a916ce4d3955fa11fe905aa50cbc15d/tempest/api/compute/admin/test_volume.py#L93 | 17:28 |
sean-k-mooney | and that does it via the image properties | 17:28 |
sean-k-mooney | dansmith: with that said your partly adressing that now | 17:29 |
opendevreview | Dan Smith proposed openstack/nova master: Fix device_type=lun with boot_index https://review.opendev.org/c/openstack/nova/+/918470 | 17:32 |
dansmith | sean-k-mooney: this fixes the other problem ^ with BFV | 17:32 |
dansmith | I have a tempest change to test BFV with multi-attach type=lun, which seems to work fine | 17:32 |
dansmith | I'll get them all re-swizzled after this run finishes | 17:32 |
sean-k-mooney | sure no rush ah you had to add lun as a possible boot dev | 17:33 |
sean-k-mooney | i wonder if this was previously only "supported" for data voluems | 17:33 |
sean-k-mooney | based on that list | 17:33 |
dansmith | just never tried, I imagine | 17:33 |
dansmith | it would be easy to say "don't do that for root" but I'm sure someone will want it and the kinds of pets that want this sort of thing are likely to be in that boat | 17:34 |
sean-k-mooney | im not sure if there is any disadvantage ot having root on a lun | 17:34 |
dansmith | I think there are some potential performance improvements with this for root if you have a very static pet.. I was reading that it's common to do this on vmware | 17:34 |
dansmith | maybe something related to the OS knowing its root is basically an iscsi device | 17:35 |
sean-k-mooney | i mean you proably dont need the extra locking apis | 17:35 |
dansmith | right, not for locking, but for perf | 17:35 |
sean-k-mooney | and we dont supprot multiatcch BFV right | 17:35 |
dansmith | we do actually. it's already tested even | 17:35 |
dansmith | in tempest | 17:35 |
dansmith | so I'm doing this as multi-attach BFV just to make sure it's covered that way | 17:35 |
sean-k-mooney | oh well in that case you may want the locking apis | 17:35 |
dansmith | presumably for hot spare type things I guess | 17:36 |
sean-k-mooney | ya so we cant do the vmware "keep the memroy in sync" type of failover | 17:36 |
sean-k-mooney | but if your application can do that or the bits it needs | 17:36 |
sean-k-mooney | then i can see that use case kind of | 17:37 |
dansmith | or you just want another instance already configured potentially hanging at the bootloader screen ready to boot, recover journal and be the master | 17:37 |
sean-k-mooney | it would be interesting to here form anyone who has used BFV multi attach | 17:37 |
sean-k-mooney | ... using grub as a active/passive lock sound like a nightmare to debug | 17:38 |
sean-k-mooney | but i could see that | 17:38 |
opendevreview | Vasyl Saienko proposed openstack/nova master: [ironic] Fix rebooting instance https://review.opendev.org/c/openstack/nova/+/918195 | 17:39 |
sean-k-mooney | that feels like "hay this is how we did it in my enteriprise virt solution, make it work the same in cloud" | 17:39 |
dansmith | yep, that's what I mean by "these sorts of pets" :) | 17:41 |
dansmith | Because of the boot order thing, I opened https://bugs.launchpad.net/nova/+bug/2065084 for the combined "device_type=lun is broken" issue and will tag both fixes to it | 17:43 |
opendevreview | Dan Smith proposed openstack/nova master: Avoid setting serial on raw LUN devices https://review.opendev.org/c/openstack/nova/+/918089 | 18:19 |
opendevreview | Dan Smith proposed openstack/nova master: Fix device_type=lun with boot_index https://review.opendev.org/c/openstack/nova/+/918470 | 18:19 |
opendevreview | Dan Smith proposed openstack/nova master: Enable virtio-scsi in nova-next https://review.opendev.org/c/openstack/nova/+/918458 | 18:19 |
opendevreview | Dan Smith proposed openstack/nova master: Enable virtio-scsi in nova-next https://review.opendev.org/c/openstack/nova/+/918458 | 18:49 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!