Earlier  
Posted Nick Remark
#openstack-nova - 2021-03-01
13:46:13 legochen our requirement is just wanted to let VM instance can use our block storage as root partition to boot.
13:46:31 sean-k-mooney that is the default if you dont use --block-device
13:46:44 sean-k-mooney unless you mean cinder
13:47:07 sean-k-mooney if you want to use cinder as teh root disk then you can use https://docs.openstack.org/nova/latest/user/launch-instance-from-volume.html#create-volume-from-image-and-boot-instance
13:47:12 legochen block storage - yes, managed by cinder
13:47:28 sean-k-mooney then yes follow ^ and it will create a bfv guest
13:47:40 legochen what’s bfv?
13:47:49 sean-k-mooney boot form volumn
13:48:21 sean-k-mooney *boot from volume
13:48:43 sean-k-mooney it gets tiresome to type so we usually use bfv as a shorthand
13:48:57 legochen ok, thanks. I just feel this flow is not that efficient. because it needs to
13:49:04 legochen 1) copy the image from glance to cinder image conversation folder
13:49:06 legochen 2) mount cinder block storage on control plance
13:49:21 legochen 3) create image volume
13:49:28 legochen 4) create VM by this volume
13:49:32 sean-k-mooney it wont do that in all cases
13:50:07 sean-k-mooney as i said if cinder and glance share teh same sotrage backend or if glance uses cinder volumns to store the image then cinder can do a more effect process
13:50:20 legochen feel the first two steps take time and cause disk-io loading during copy images.
13:50:42 sean-k-mooney cinder does not need to do a copy in all cases
13:51:00 sean-k-mooney if you you ceph for glance and cidner then no copy happens provided they both use the same ceph cluster
13:51:31 sean-k-mooney cinder will insted create a new volume as a thin snapshot of the image
13:51:56 sean-k-mooney it will also do this in most cases when cinder is used as the glance image store backend
13:51:59 legochen do I need to configure something on both cinder and glance config? let them can identify they don’t need to do copy stuff
13:52:00 gibi stephenfin: thanks for the comment on the vnc series. I'm glad we had the tempest test to show that we have a more complicated situation than what I thought
13:52:24 sean-k-mooney it need driver support but the copy should be elided.
13:52:47 sean-k-mooney legochen: am for ceph i dont think so but you would be better asking that question in the cinder channel
13:53:02 legochen do you have example … I’d like to look into more about this.
13:53:05 sean-k-mooney they can explaine how to configure ciner/glace to avoid the copy
13:53:39 legochen our glance is using NetApp filer to store images, but cinder is using EMC VxFlex block storage
13:54:28 sean-k-mooney legochen: in that case i dont think there is any way to fuly elid the copy although cinder also has an image cache.
13:54:28 legochen we don’t use ceph :)
13:55:07 sean-k-mooney legochen: in general its not a great idea to have multiple sotrage solution deployed in a single openstack cloud it prevent some optimnisation form being done
13:57:10 sean-k-mooney ok i have to go do some work downstream for a while so ill be semi away from irc for a while o/
13:57:35 legochen got it. thank you for your knowledge
13:57:48 legochen sean-k-mooney :)
13:59:29 sean-k-mooney legochen: in your spcific case createing vms form volumne snapshots might be the most effecinct
14:00:31 sean-k-mooney but do follow up with the cinder folks they may be able to help more. i belvie cinder has some config option to optimise this somewhat but im not super familar with all the options they have
14:01:40 legochen sean-k-mooney, stephenfin - as my misunderstanding about —block-device option, I thought it can be used to root partition. So, I think to support —volume-type in OSC become a more useful feature … we need to have. otherwise, we’ll need to create image volume first and use that volume to boot an instance.
14:02:39 legochen sean-k-mooney, got it. will check with cinder channel about that. thank you. “volume snapshots” could be a good idea, let me try it more.
14:08:04 sean-k-mooney legochen: it can be used for the root disk but --block-device is not only used for cinder it is used for advance block device configuration in general
14:08:51 legochen so, sounds like —block-device is also an ideal option?
14:08:53 sean-k-mooney i think that is what you missed if the dest type is local for exaple its used to configure epmermal storage
14:10:23 legochen I guess I can use nova command to test that, right
14:10:24 legochen --block-device source=volume,id=33ecc63a-ccc1-496b-ae9a-61babe615568,dest=volume,shutdown=preserve
14:11:53 legochen ,bootindex=0
14:11:57 legochen need to add this
14:13:36 sean-k-mooney well that will bot with an exsiting volumn
14:13:41 sean-k-mooney it wont create a new one
14:13:58 sean-k-mooney but ya anyway sorry got to go.
14:14:25 legochen ERROR (BadRequest): Block Device Mapping is Invalid: Boot sequence for the instance and image/block device mapping combination is not valid. (HTTP 400) (Request-ID: req-c004edcf-0deb-4354-8358-c78cdf7f6c08)
14:14:36 legochen okay, I got this error when add “,bootindex=0"
14:14:47 legochen sure, you busy first.
14:17:25 openstackgerrit Lee Yarwood proposed openstack/nova master: libvirt: Deprecate disable_native_luksv1 and rbd_volume_local_attach https://review.opendev.org/c/openstack/nova/+/778004
14:19:36 sean-k-mooney lyarwood: i thought ^ was alredy dperecated when we added them
14:20:04 sean-k-mooney ik guess you did not formally do it but that was the intent of your comment
14:20:14 sean-k-mooney to so we could actully remove them in W
14:21:18 lyarwood sean-k-mooney: yeah I didn't formally do it at the time, was about to do it now and noticed so thought I'd follow normal procedure and remove them early in Xena
14:21:46 sean-k-mooney ok i guess it does not matter too much
14:21:59 sean-k-mooney it proably makes upgrades slightly simpler for 17
14:22:00 lyarwood yeah, would be nice to remove them now for my sanity but that's about it
14:22:05 sean-k-mooney since they can disable this after upgrade instead
14:22:07 lyarwood right
14:22:20 lyarwood well they can disable it after they move to 16.2 downstream
14:22:28 lyarwood we've backported the perf fixes to 8.3
14:23:40 sean-k-mooney ah ya good point
14:24:55 sean-k-mooney lyarwood: also no worries about lunch, if we can move the os-vif backport forward that would be good as we need it before 16.2 is release but we have a few months to work on that
14:26:25 lyarwood kk
15:00:51 openstackgerrit Jessie Lass proposed openstack/nova master: Add emulation support if host arch != guest arch. https://review.opendev.org/c/openstack/nova/+/772156
15:09:18 kashyap Strange, before rebasing, I didn't see this exception when running unit tests; but after rebase, I see:
15:09:26 kashyap "Exception: This test uses methods that set internal oslo_db state, but it does not claim to use the database [...]"
15:10:32 kashyap [https://zuul.opendev.org/t/openstack/build/0347425ea0d74725a73f41ee4eaf6dd1]
15:17:55 sean-k-mooney likely not mocking something you should
15:18:57 lyarwood yeah it should be in the trace
15:19:23 lyarwood ah it's my stuff that's causing this for you
15:19:24 lyarwood _register_instance_machine_type
15:19:35 lyarwood just mock that out
15:19:43 lyarwood kashyap: ^
15:20:03 kashyap lyarwood: Oh, I see. That's the change the rebase brought
15:20:24 kashyap sean-k-mooney: It came only after the rebase; it was not there before.
15:20:25 sean-k-mooney lyarwood: that might want to be mocked in the setup funciton
15:22:35 lyarwood sean-k-mooney: I assume kashyap's tests are calling init_host directly
15:23:16 kashyap lyarwood: Indeed, I noticed that removing the call to init_host "fixes" it - drvr.init_host("dummyhost")
15:23:33 kashyap lyarwood: I don't even think it's required to call here. Because, I checked in the PDB --
15:23:51 kashyap My test asserts expected results w/o the init_host() call
15:24:21 kashyap So I'm actually going to remove it; it's not required in this case, near as I can tell
15:24:49 kashyap Thanks for looking, folks!
15:25:03 lyarwood kashyap: https://review.opendev.org/c/openstack/nova/+/774240/10/nova/tests/unit/virt/libvirt/test_driver.py@1478
15:25:17 lyarwood kashyap: looks like you removed the mock from test__check_cpu_compatibility_start_ok
15:25:44 kashyap lyarwood: Urgh; that was accidental damage during rebase. Sloppy me.
15:25:52 kashyap I thought I double-checked, and still I failed
15:28:39 kashyap That's it; it's the missing mock
15:34:50 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: libvirt: Allow disabling CPU flags via `cpu_model_extra_flags` https://review.opendev.org/c/openstack/nova/+/774240
15:43:06 openstackgerrit Balazs Gibizer proposed openstack/nova stable/pike: rt: Make resource tracker always invoking get_inventory() https://review.opendev.org/c/openstack/nova/+/778014
15:45:06 openstackgerrit Balazs Gibizer proposed openstack/nova stable/pike: Update resources once in update_available_resource https://review.opendev.org/c/openstack/nova/+/612295
16:23:59 openstackgerrit Merged openstack/nova master: apidb: Compact Mitaka database migrations https://review.opendev.org/c/openstack/nova/+/759400
16:24:13 stephenfin sean-k-mooney: Can you live with the bit of duplication in this? https://review.opendev.org/c/openstack/nova/+/775415/ I'd like to keep that series moving forward /o\
16:33:12 openstackgerrit Balazs Gibizer proposed openstack/nova stable/pike: rt: Make resource tracker always invoking get_inventory() https://review.opendev.org/c/openstack/nova/+/778014
16:34:30 openstackgerrit Balazs Gibizer proposed openstack/nova stable/pike: Update resources once in update_available_resource https://review.opendev.org/c/openstack/nova/+/612295
16:37:59 sean-k-mooney stephenfin: ill take a look after the meeting
16:53:30 dansmith bauzas: the compute 6.0 patch is failing almost everything because of versioning stuff. You have a TODO to fix that in the commit message, but are you looking for help via review or are we still waiting for you to work those issues out first?

Earlier   Later