Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-06-10
15:12:37 sean-k-mooney when people do it manually and get it wrong
15:12:55 sean-k-mooney i honestly dont mind either way to be honest
15:13:08 stephenfin dansmith: in general they're correct, but things break if you've to make any modification to an earlier patch
15:13:11 sean-k-mooney the only thing i find annoying is that gerrit does not do it the way we want
15:13:35 dansmith it also helps me see how far something was backported.. like if I'm looking at something on stein and it has N backport lines, I know that came from stein+N
15:14:29 sean-k-mooney stephenfin: maybe try using git review for backport for a while
15:14:34 stephenfin True, but you have that information in the cherry picks box on the right
15:14:39 stephenfin in the UI, that is
15:14:44 dansmith not in the command line tho
15:14:44 dansmith right
15:15:19 stephenfin fair point
15:15:32 stephenfin sean-k-mooney: in general, there's no issue. I just use 'git cherry-pick -x'
15:16:03 stephenfin but I've been bitten a few times now where I had a stack of stable changes and had to make a tweak to a single patch higher up
15:16:50 stephenfin so you've add the missing mock or the typo in your commit message or whatever else you missed
15:17:22 stephenfin and then you've to go update the cherry-picked lines in every backported patch plus any patch on top in each branch. not fun :)
15:17:32 stephenfin it'd be nice if it was optional
15:18:10 stephenfin as something that's nice-to-have but not really necessary, particularly if it incurs pain
15:18:34 stephenfin *when it incurs pain
15:21:08 dansmith well, my vote is that it's worthwhile bookkeeping
15:22:19 stephenfin Definitely worthwhile but not essential. I'd like to be able to loosen the cuffs on the occasion they start hurting
15:24:49 elod if i'm not mistaken, then gerrit adds the cherry-picked lines correctly, iff the original patch has merged. if the patch is not merged yet, it does not add the cherry-picked line, for logical reasons, as it might not be the one that gets merged
15:25:14 stephenfin elod: Ah, so that's how it makes the decision :) Can't confirm but makes sense
15:26:09 stephenfin Waiting for a patch series to land on stable/X before backporting to the stable/X-1 etc. is less than optional though. It causes unnecessary context switching for both submitter and reviewer, assuming the submitter even remembers to keep backporting things
15:27:00 elod that's true, we had the same discussion in our team :]
15:27:34 stephenfin Ha! I'm about to discuss it downstream too 😇
15:27:34 stephenfin Ha! I'm about to discuss it downstream too 😇
15:27:37 dansmith I'd much prefer to have the bookkeeping right and I think it's very unusual that backports to N releases are that urgent
15:28:25 elod otherwise, if a patch needs to be fixed, then all its backports need to be fixed, so that's another extra burden. so there are two sides
15:29:35 elod if we stick to policy and do the backporting branch-by-branch, when a patch has merged, then this is not an issue, though
15:29:39 stephenfin dansmith: so not including the cherry-picked from line would be very unusual too
15:29:48 stephenfin it'd be exceptional, not the norm
15:31:03 stephenfin elod: yes and no. It really depends on the nature of the change to the higher up patch
15:32:57 stephenfin Consider that series I reviewed from lyarwood yesterday. The extra 'cherry-picked from' line was something that affected all commit messages
15:32:57 stephenfin but there were other issues that were specific to certain backports like the 'Conflicts' and 'NOTE' sections being the wrong way round
15:33:56 stephenfin it's not black and white
15:34:19 stephenfin anyway, I've made my point :) now to forget about it until next time I hit this
15:35:56 elod if the editing of a 'middle' patch is allowed, then that could be a source of an inproper backport. i mean most of the time it's not a problem, but sometimes we forget to backport some new changes
15:36:34 elod the cherry-picked line is good to identify where the backport is coming from
15:37:18 elod and as dansmith said, it's good to see how many previous backports there are
15:38:44 elod but yes, if we want to backport to multiple branches at the same time, it could be painful :)
15:39:01 stephenfin yup, all fair points
15:39:09 stephenfin it'd just be nice have the optional, is all
15:39:15 stephenfin *the option
15:53:30 openstackgerrit Dan Smith proposed openstack/nova master: DNM: Try to make a glance multistore job https://review.opendev.org/734184
16:13:21 openstackgerrit Jiri Suchomel proposed openstack/nova master: Add ability to download Glance images into the libvirt image cache via RBD https://review.opendev.org/574301
16:16:14 stephenfin sean-k-mooney: your cherry-picked from lines are wrong in this https://review.opendev.org/#/c/728057/
16:19:18 sean-k-mooney they may be yes
16:19:24 sean-k-mooney i did it via the gerrit ui
16:23:16 openstackgerrit Stephen Finucane proposed openstack/nova stable/train: Silence amqp heartbeat warning https://review.opendev.org/728057
16:23:52 mandre hi, quick question regarding the hw_scsi_model and hw_disk_bus glance image annotations. Did nova always had support for them? and if we specify a virt driver that the hypervison doesn't support, does it fallback to the default driver?
16:24:05 mandre Context is, I'm wondering if it's safe to set the hw_scsi_model=virtio-scsi and hw_disk_bus=scsi annotations for my images, not knowing what the environment will be.
16:25:26 sean-k-mooney mandre: yes well for several years
16:25:37 sean-k-mooney it predates icehouse
16:26:09 sean-k-mooney mandre: technically you could detect it via the glance metadta api
16:26:25 sean-k-mooney but if the could cupport nova v2 api it also support them
16:26:43 sean-k-mooney mandre the issue is that the values are virt driver dependnet
16:27:00 sean-k-mooney so if you dont know what hyperviror your cloud is using you don tknow what value are vaild
16:27:24 sean-k-mooney if you know that its libvirt then those values will work
16:27:33 mandre cool, so that answers the first part of the question, we're not deploying on anything that is older that queens I think
16:28:26 sean-k-mooney as of ussuri maybe train we also report the support models to placment as traits
16:28:52 sean-k-mooney just an fyi but plamcnet is an admin only api normally so that may or may not be helpful to you
16:29:38 mandre right, we won't be able to use placement because we need to deploy as tenant
16:31:30 sean-k-mooney ya so if you know its libvirt then as i siad those values will work
16:31:37 mandre is there a way to progmatically discover the hypervisor as a tenant?
16:31:44 sean-k-mooney no
16:31:48 sean-k-mooney and that is intentional
16:31:52 sean-k-mooney as an admin yes
16:31:58 sean-k-mooney via the hyperviors api
16:32:15 mandre fair enough, just checking :)
16:32:35 openstackgerrit Stephen Finucane proposed openstack/nova stable/stein: libvirt: avoid cpu check at s390x arch https://review.opendev.org/701526
16:33:00 sean-k-mooney mandre: you can boot a vm and then you can kind fo tell form inside the vm
16:34:29 mandre so if I set a driver via hw_scsi_model that the hypervisor doesn't support, it won't be able to boot the VM? or is there a fallback mechanism?
16:34:53 sean-k-mooney if you set it and its not supported it wont boot
16:35:02 sean-k-mooney because we could not fullfile your request
16:35:22 mandre OK
16:37:03 sean-k-mooney mandre: if you boot a vm with a default image and run lscpi like this http://paste.openstack.org/show/794593/
16:37:19 sean-k-mooney and you see 00:02.0 PCI bridge: Red Hat, Inc. QEMU PCIe Root port for example
16:37:36 sean-k-mooney you basically know it either libvirt/kvm or xen
16:37:42 openstackgerrit Stephen Finucane proposed openstack/nova stable/stein: Create instance action when burying in cell0 https://review.opendev.org/729531
16:38:03 sean-k-mooney you can also infer the hypervior in other ways
16:39:27 mandre sean-k-mooney: thanks for the help
16:39:51 sean-k-mooney hyperv and vmware all have similr things you can look for
16:40:08 sean-k-mooney if you run lspci on hyperv for example it will almsot be empty
16:40:26 sean-k-mooney there nics and disk dont show up as pci device in the normal way
16:40:47 sean-k-mooney in vmware the nic model will be a special vmware one by defualt at least
16:41:25 sean-k-mooney mandre: so if you are enruling you applcaiton on a generic cloud that is one way to figure it out.
16:42:05 openstackgerrit Stephen Finucane proposed openstack/nova stable/stein: Add admin doc information about image cache resource accounting https://review.opendev.org/732542
16:45:17 mandre sean-k-mooney: IIUC as a tenant there is no other way than spinning a VM to guess the hypervisor, so we may refrain from adding the image annotations since we won't know the environment in advance
16:46:19 sean-k-mooney well we are discussing worlad onboarding or VNF onboaridng right
16:46:34 sean-k-mooney i assume you are a vendor of a product that runs or can run on openstack
16:47:11 sean-k-mooney if so you have a few options the first is to document your miniurm and recommended setting when onboarnidng your applcation
16:47:26 sean-k-mooney if you atomate that you can add a config or do auto detection
16:48:32 sean-k-mooney but its likely that you will have implcit depenencies in your applcation that will only work on some hypervieors so targeting 1 or a limites set will roably be requried jsut from a vlaidation perspective
16:48:49 sean-k-mooney most openstack cloud usei libvirt/kvm
16:49:02 sean-k-mooney and all that use libvirt/kvm will support those options
16:49:43 sean-k-mooney if you plan to also support vmware, powervm or hyperv then you have to explore one of the other options
16:49:44 mandre ok, that's good info.
16:49:53 sean-k-mooney e.g. confg or docs
16:52:25 mandre this is for the openshift installer on openstack platforms, so there's a good chance the hypervisor will be libvirt/kvm. If using vmware or hyperv, it's likely they'll deploy directly on vsphere or azure.
17:16:57 openstackgerrit Merged openstack/nova master: Add reproducer for bug #1881455 https://review.opendev.org/733667

Earlier   Later