Earlier  
Posted Nick Remark
#openstack-nova - 2021-06-01
10:51:17 stephenfin bauzas: sounds like your issue is with the PR workflow rather than this tool :)
10:51:20 bauzas but heh, you can *not* squash, and that's why I dislike
10:51:23 lyarwood gibi: yeah that's another way, I just find stash a little quicker for small things
10:51:23 sean-k-mooney bauzas: that not what the tool is enabling at all though so that is kind of irrelevent
10:51:25 gibi lyarwood: I guess instead of commits I could do stash
10:51:28 bauzas stephenfin: correct
10:51:30 stephenfin or rather the CI systems built on this workflow
10:51:44 sean-k-mooney gibi: i dont like stash because i have lost work that way
10:51:49 bauzas stephenfin: and that's why i said "I prefer the Gerrit workflow for this"
10:51:51 gibi sean-k-mooney: ditto
10:52:11 stephenfin Ah, okay. Given we were talking about the tool, I thought you were comparing the _tool_ to Gerrit
10:52:17 jkulik lyarwood: here's the bug you requested https://bugs.launchpad.net/nova/+bug/1930406
10:52:17 opendevmeet Launchpad bug 1930406 in OpenStack Compute (nova) "parallel volume-attachment requests might starve out nova-api for others" [Undecided,New]
10:52:19 stephenfin which doesn't really make sense
10:52:19 sean-k-mooney i much prefer to either do an interactive rebase and fix inline or put patches on the end an move them
10:52:25 lyarwood jkulik: thanks
10:52:32 bauzas sean-k-mooney: gibi: well, I use git reflog in this case
10:52:43 gibi for the git absorb thingy, if it can do a smart split of the local changes then it might help me with the commit creation what I do manually with git add -p
10:52:47 sean-k-mooney bauzas: i dont think that works with stash
10:52:48 lyarwood ah yes the get out of jail free card that is reflog
10:52:59 sean-k-mooney if it does good to know
10:53:00 bauzas sean-k-mooney: nah, I prefer to commit
10:53:06 lyarwood yeah it doesn't with stash
10:53:13 sean-k-mooney ya so do i so i can use reflog if i mess things up
10:53:25 stephenfin trying to parse a reasonably complex reflog is *soo* much fun
10:53:27 bauzas anyway, me needs to lunch
10:54:07 lyarwood stephenfin: always helps when you're looking for something rather important that would take ages to rewrite ^_^
10:54:19 gibi :D
10:54:22 lyarwood can't say I ever look at reflog when I'm relaxed
10:54:26 stephenfin touché
10:54:29 sean-k-mooney stephenfin: totes fun but 99% of the time when i need it i just need the sha that is a 2-3 lines form the top
10:55:07 gibi have you ever git pulled one repo into another? that is fun to realize later on :D
10:55:18 sean-k-mooney lyarwood: ya when i use it its oftehn to fix an unitential rebase with git reivew
10:55:25 sean-k-mooney gibi: yep
10:55:51 sean-k-mooney gibi: nova has a full copy of the openwrt sorce tree in it somewhere
10:55:57 gibi at some point I had placement back in nova :D
10:56:36 sean-k-mooney at least the gerrit version of it had at one point we may have eventually git gc that out of the public repos
10:57:13 gibi ohh so the central copy of nova had openwrt? nice!
10:57:48 lyarwood sounds like some kind of go project repo
10:58:18 sean-k-mooney yep thats something jaypipes told me a long time ago. i assume someone pushed a review where tehy acindtally commited it locally
10:58:40 sean-k-mooney but gerrit would keep that around forever as a result in the gerrit copy of the repo
10:59:20 sean-k-mooney you would have to manually purge the review ref to remove it
11:08:39 opendevreview Stephen Finucane proposed openstack/nova master: Use neutronclient's port binding APIs https://review.opendev.org/c/openstack/nova/+/706295
11:13:03 opendevreview Stephen Finucane proposed openstack/nova master: docs: Drop references to non-filter scheduler drivers https://review.opendev.org/c/openstack/nova/+/773645
11:13:04 opendevreview Stephen Finucane proposed openstack/nova master: scheduler: Merge driver into manager https://review.opendev.org/c/openstack/nova/+/773644
11:13:04 opendevreview Stephen Finucane proposed openstack/nova master: tests: Merge 'test_utils', 'test_scheduler_utils' https://review.opendev.org/c/openstack/nova/+/773646
11:13:05 opendevreview Stephen Finucane proposed openstack/nova master: conf: Remove deprecated aliases https://review.opendev.org/c/openstack/nova/+/773647
11:38:57 opendevreview norman shen proposed openstack/nova master: Saving security group to info_cache https://review.opendev.org/c/openstack/nova/+/786348
11:42:15 stephenfin dead simple Python 3.10 prep patch here if anyone has 2 mins https://review.opendev.org/c/openstack/nova/+/790405
11:45:15 gibi stephenfin: done
11:45:18 stephenfin ta
12:15:20 opendevreview Lee Yarwood proposed openstack/nova stable/wallaby: hardware: Use image_meta.id within get_mem_encryption_constraint https://review.opendev.org/c/openstack/nova/+/793956
12:16:29 opendevreview Lee Yarwood proposed openstack/nova stable/victoria: hardware: Use image_meta.id within get_mem_encryption_constraint https://review.opendev.org/c/openstack/nova/+/793957
12:17:15 opendevreview Lee Yarwood proposed openstack/nova stable/ussuri: hardware: Use image_meta.id within get_mem_encryption_constraint https://review.opendev.org/c/openstack/nova/+/793958
13:07:29 ganso Hi nova folks! Not sure if you're familiar with this behavior, whether it is a known bug or limitation (I didn't find any launchpad entry for it), but it is very easy to reproduce: if you try attach a volume with hw_disk_bus property that is different from the root disk's hw_disk_bus one, it gets ignored. Example, root disk's is ide, volume's is virtio, and it gets attached as ide.
13:08:16 ganso using pure kvm through virt-manager, it is possible to have mixed ide+virtio disks, but nova doesn't seem to be allowing that
13:08:32 sean-k-mooney ganso: yes that is expected behavior
13:08:44 sean-k-mooney ganso: the image metadta is only use form the root disk
13:08:57 sean-k-mooney we do not use image metadta form any other disk
13:09:11 sean-k-mooney ganso: you might be able to enable this using the block device mappings api
13:09:39 ganso sean-k-mooney: is there a reason why you would want to keep it this way?
13:10:28 sean-k-mooney well if the bus is not already present in the vm at a minitum we woudl have to also attach a contole for that bus be it ide/stata whatever
13:10:38 sean-k-mooney and then all attach the volume to that new contoler
13:10:55 sean-k-mooney that could fail for a number of reasons
13:11:24 sean-k-mooney in general image metadata was intened to only be used form teh root disk
13:11:56 sean-k-mooney when not using cinder it does not really make sense to have multipel image metadta soruce
13:12:14 ganso sean-k-mooney: hmmm I see, so this is like a new feature, to handle independent disk_bus values for each new volume, something nova doesn't do today
13:12:34 sean-k-mooney if we allowed it to work for cinder there is an issue with confilt between volumens that we would have to determin how to handel
13:12:40 ganso sean-k-mooney: I was able to hack the code just to test it, I replaced the variable with "virtio" here: https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L2018
13:13:04 sean-k-mooney ganso: yes it would basiclaly be a new feature
13:13:06 ganso and it worked, upon attach it added a virtio disk beside an ide one (the root disk)
13:13:28 sean-k-mooney yes there is a virtio contoler present by defualt for the nic
13:13:37 sean-k-mooney if you put stata it will fail
13:13:55 sean-k-mooney /stata/sata
13:14:53 ganso sean-k-mooney: so, adding a controller during attach is something risk you say? would it be 100% safe if it requires the VM to be shutoff?
13:15:15 sean-k-mooney it may or may not fail
13:15:43 sean-k-mooney and it may depend on the version fo libvirt if the contoler is hot pluggable or not
13:16:20 ganso sean-k-mooney: I understand. I will do some testing around this, thank you for the clarification!
13:16:24 sean-k-mooney for example when using q35 machine type libvirt only alloctes 1 spare pcie port for hotplug devices
13:16:37 sean-k-mooney so you would not have enough to add the contoler and a volume
13:16:54 sean-k-mooney there is one way you might be able to do this today
13:17:05 sean-k-mooney but only for new vms
13:17:07 sean-k-mooney https://docs.openstack.org/api-ref/compute/?expanded=create-server-detail#create-server
13:17:25 sean-k-mooney server create allows you to specify the block device mappings block_device_mapping_v2 (Optional)
13:17:31 sean-k-mooney "block_device_mapping_v2": [{
13:17:33 sean-k-mooney "boot_index": "0",
13:17:35 sean-k-mooney "uuid": "ac408821-c95a-448f-9292-73986c790911",
13:17:37 sean-k-mooney "source_type": "image",
13:17:38 ganso sean-k-mooney: oh I see, it would depend on that as well, so depending on how I test it, I may be avoiding a problem (like testing with just 1 extra disk instead of 2 or 3, as it could run out of devices)
13:17:39 sean-k-mooney "volume_size": "25",
13:17:41 sean-k-mooney "destination_type": "volume",
13:17:43 sean-k-mooney "delete_on_termination": true,
13:17:45 sean-k-mooney "tag": "disk1",
13:17:47 sean-k-mooney "disk_bus": "scsi"}]
13:17:49 sean-k-mooney which has the disk bus
13:18:07 sean-k-mooney ganso: yes although we have a config option for how may free port to allcote
13:18:18 ganso sean-k-mooney: I will try that! could just work out for my use case! thank you!
13:18:47 sean-k-mooney ganso: if that works and you can set the disk bus per volume when creatign a new server
13:18:50 sean-k-mooney which the api imples
13:19:03 sean-k-mooney then we could consider if that would be extanded to port attach

Earlier   Later