Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-06-01
10:48:05 kashyap stephenfin: I see the use-case here, though. But it requires great care when using it to quadruple-check things
10:48:29 kashyap It sounds very nice on paper :)
10:48:31 stephenfin yeah, it's much less useful for Gerrit where you're forced to think in terms of individual commits and use rebase extensively
10:48:47 lyarwood yeah it's working around the bork'd nature of the PR workflow
10:48:47 sean-k-mooney kashyap: yep that is why by default it create the delta as patch that you then can merge with an interactive rebase
10:48:59 bauzas stephenfin: okay, then why it would be nice for our, then ?
10:48:59 sean-k-mooney yep
10:49:14 stephenfin it wouldn't really, but that doesn't make it a bad tool
10:49:16 lyarwood git stash ftw
10:49:22 bauzas stephenfin: we can already provide a new patch per change
10:49:30 sean-k-mooney yep it kidof reminded me of https://docs.openstack.org/infra/git-restack/
10:49:38 stephenfin and I don't see what impact this would have on a working master branch
10:49:46 sean-k-mooney although a different approch
10:49:48 lyarwood it's useful when you need to fix HEAD~$something up but at pointing at HEAD
10:49:58 lyarwood but are*
10:49:59 stephenfin lyarwood: yup, agree RE: borked PR workflow
10:50:04 bauzas honestly, I don't see *why* I'd need this new tool
10:50:09 jkulik in our GH workflow, we still rebase the changes into every commit even for multi-commit PRs. no tool necessary. git commit --fixup and git rebase -i
10:50:16 sean-k-mooney bauzas: im not saying you do
10:50:29 sean-k-mooney bauzas: just wondering if people had used it
10:50:32 bauzas stephenfin: I don't like it because it means that it's OK to have a patch having bugs
10:50:46 bauzas if the next patch fixes them
10:50:53 gibi lyarwood: I tend to prepare commits top of HEAD and then do an interactive rebase to meld them into the proper origin commit they belong
10:50:55 stephenfin jkulik: yup, which works for a change to a single patch. Trickier if you have changes that affect multiple patches
10:50:58 bauzas of course, you *can* squash both
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 sean-k-mooney bauzas: that not what the tool is enabling at all though so that is kind of irrelevent
10:51:23 lyarwood gibi: yeah that's another way, I just find stash a little quicker for small things
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 opendevmeet Launchpad bug 1930406 in OpenStack Compute (nova) "parallel volume-attachment requests might starve out nova-api for others" [Undecided,New]
10:52:17 jkulik lyarwood: here's the bug you requested https://bugs.launchpad.net/nova/+bug/1930406
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:19 stephenfin which doesn't really make sense
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: tests: Merge 'test_utils', 'test_scheduler_utils' https://review.opendev.org/c/openstack/nova/+/773646
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: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?

Earlier   Later