Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-10-28
18:31:58 rm_work any specific neutron version dependencies?
18:32:16 rm_work If we jump Nova to Victory with Neutron still at Train, could we see problems?
18:32:26 sean-k-mooney it depends on the feature you are using but we disable feature if neutron is not new enough
18:32:34 rm_work ok, so it handles it
18:32:57 sean-k-mooney rm_work: that is not tested. in thory it might be ok generally you want to upgrade neutorn before nova
18:33:01 rm_work assuming that'd only be for newer features anyway, and if we're JUST upgrading nova, we wouldn't already be relying on them
18:33:06 rm_work ok, noted
18:33:07 sean-k-mooney but it shoudl work for those versions
18:33:25 rm_work it's probably fine to plan to "be safe" and just upgrade neutron first, not really a huge issue
18:33:46 rm_work how common do you think it is for folks to run clouds with services at completely different versions?
18:33:54 sean-k-mooney https://github.com/openstack/grenade is what we use for upgrade testing in the ci
18:34:09 sean-k-mooney so usign the same or a similar orderign is likely to work better
18:34:55 rm_work I haven't seen it discussed a ton, but I've been giving a lot of thought to how Openstack at this point really shouldn't have a ton of requirements as far as versions go, in many cases, so running a cloud with patchwork versioning seems actually quite reasonable
18:35:07 rm_work so we've moved in that direction
18:35:36 rm_work starting to wonder if that might be worth a presentation next summit ;)
18:35:55 sean-k-mooney it might
18:36:18 sean-k-mooney this summerises how upgrades should work in openstack https://github.com/openstack/grenade#theory-of-upgrade
18:36:51 sean-k-mooney thats specific to singel version upgrades
18:36:54 rm_work cool thanks, I THINK i've gone through this but it's been a while so will give it a re-read
18:37:10 rm_work yeah, seems no matter what we should probably avoid fast-forward / skip-level
18:37:32 sean-k-mooney rm_work: this is the order of upgrades done by grenade https://github.com/openstack/grenade/tree/master/projects
18:38:04 sean-k-mooney i acutlly expected cinder to go before nova but i guess it does not
18:38:23 rm_work I have been studying https://docs.openstack.org/placement/latest/admin/upgrade-to-stein.html EXTENSIVELY, heh
18:38:27 rm_work that's our current challenge
18:38:52 sean-k-mooney its more a case of manageing dependices.
18:39:01 sean-k-mooney keystone has none outside oslo
18:39:09 melwitt +1 running services at different versions is reasonable. it's designed to work that way. there are likely limitations (like placement needs to be >= nova) but prior to that things were supposed to work with mixed versions
18:39:09 sean-k-mooney placemnt only depneds on keystone
18:39:21 sean-k-mooney ectra
18:39:28 sean-k-mooney rm_work: are you using a containerised install
18:39:34 sean-k-mooney or package install
18:39:35 rm_work mixed :P
18:39:45 rm_work we create our own portable venvs for most services
18:39:52 rm_work but placement will be our first actual container
18:39:54 sean-k-mooney ah perfect
18:40:16 melwitt fast-forward is ok but skip-level is not, you could get screwed if data migration code was removed in the middle of what you're skipping
18:40:17 sean-k-mooney i was going to point out the bigest obstical to different version will be oslo requirements
18:40:26 sean-k-mooney venvs or container solve that
18:40:51 rm_work yeah, the thought of installing multiple openstack services in the SAME PYTHON ENV is just ... i know it's halloween, but that's TOO scary
18:41:07 sean-k-mooney rm_work: well we test that in the gate
18:41:14 sean-k-mooney but only on a singel version
18:41:34 sean-k-mooney at a minium you would want 1 python env per release
18:41:45 rm_work yeah honestly I think a lot of stuff will become a lot simpler once people are willing to accept that it just isn't good practice to do IMO T_T
18:41:49 sean-k-mooney but if you are already doing that per servicce then cool
18:42:13 rm_work or rather, if we were willing to make the decision to say "no, one env per service", think of how much simpler G-R management would be, heh
18:42:34 sean-k-mooney well co installablity is currenlty a goal/requirement
18:42:42 rm_work right, but imagine if it weren't! :P
18:43:00 sean-k-mooney packaging would be a pain and you would have to use containers
18:43:11 sean-k-mooney well or venvs
18:43:21 sean-k-mooney so it would make distro lives harder
18:43:27 rm_work well, I guess to be fair packaging venvs is ... not STRICTLY recommended by the pip/venv folks
18:43:41 rm_work seeing as how they keep trying to break it / make it harder to create portable venvs
18:43:51 rm_work and saying "this was never actually intended to work"
18:44:17 sean-k-mooney :)
18:44:44 sean-k-mooney but ya do think about shareing your experince with multiple versions at some point
21:44:48 openstackgerrit melanie witt proposed openstack/nova stable/queens: [stable-only] Add functional test for bug 1731668 https://review.opendev.org/756636
21:44:48 openstack bug 1731668 in OpenStack Compute (nova) queens "placement: claim allocations fails with IndexError in _ensure_lookup_table_entry" [Low,In progress] https://launchpad.net/bugs/1731668 - Assigned to melanie witt (melwitt)
21:44:49 openstackgerrit melanie witt proposed openstack/nova stable/queens: [stable-only] Use a separate transaction for reading after race https://review.opendev.org/756637
#openstack-nova - 2020-10-29
00:47:40 openstackgerrit norman shen proposed openstack/nova master: DNM: Cpu and memory live resize https://review.opendev.org/760264
08:20:42 bauzas good morning Nova
08:24:45 gibi bauzas: o/
09:01:55 lyarwood Morning all
09:27:15 brinzhang_ lyarwood: morning^
09:27:47 brinzhang_ lyarwood: hope you can review Add instance_state to ensure volume attachment successful https://review.opendev.org/#/c/758920/ while you have free time
09:28:20 brinzhang_ it comes from bug 1897424
09:28:20 openstack bug 1897424 in OpenStack Compute (nova) "attach volume consume too long time, and if attaching another volume at the same time, create the bdm will be timeout" [Wishlist,Incomplete] https://launchpad.net/bugs/1897424 - Assigned to Lee Yarwood (lyarwood)
09:32:16 lyarwood brinzhang_: ack yeah it's in my queue
09:32:33 lyarwood brinzhang_: thanks for reminding me :)
09:33:52 brinzhang_ larywood: np, thanks for your concern :D
11:18:42 openstackgerrit Shi Yan proposed openstack/nova master: Remove unused bindir config option https://review.opendev.org/760331
11:49:41 gibi melwitt, lyarwood, elod: reviewed https://review.opendev.org/#/q/topic:bug/1731668+(status:open+OR+status:merged) and I think this is OK from db/placement perspective.
12:10:09 elod thx gibi, I was just about to comment that 'it looks OK to me, but I would ask for other core members to review it' :)
12:48:57 elod sean-k-mooney: a minor thing: I don't want to merge this with your -1 on it o:) -- https://review.opendev.org/#/c/750925/
12:50:18 sean-k-mooney elod: oh ill change that we talked about it on the master version
12:51:23 sean-k-mooney i dont really like the change sicne we have never used it for lower constraitns and apparently that is why it was renamed but its was not enought for me to -2 on master and other were happy so its fine
12:52:01 sean-k-mooney elod: +1 now
12:53:24 sean-k-mooney elod: this was the master version https://review.opendev.org/#/c/756135/
12:53:48 sean-k-mooney it looks like the review bot version is not a cherry pick but a stable only patch
12:54:21 sean-k-mooney but for something this trivail im not sure we care too much that its stable only
12:59:54 openstackgerrit Andrey Volkov proposed openstack/nova master: Functional test test_boot_reschedule_with_proper_pci_device_count https://review.opendev.org/760354
13:08:19 kashyap lyarwood: The libvirt/QEMU folks are rushing hither and thither w/ KVM Forum thing in flight; I'm still tryin to get the right eyes on this: https://bugs.launchpad.net/nova/+bug/1901739
13:08:19 openstack Launchpad bug 1901739 in OpenStack Compute (nova) " libvirt.libvirtError: internal error: missing block job data for disk 'vda'" [High,Confirmed]
13:08:52 kashyap lyarwood: Peter Krempa would be the right one, based on my Git analysis; but it's probly a holiday in Czech
13:10:25 tosky kashyap: it was yesterday
13:10:48 kashyap tosky: Oh, sorry. Let me check w/ him again, then :)
13:10:51 kashyap tosky: Thank you
13:11:27 tosky but then people may have used that for longer holidays :)
13:12:01 lyarwood kashyap: ack thanks
13:58:48 lyarwood anyone having issues pushing new patchsets to nova-specs?
14:27:24 elod sean-k-mooney: thanks, I'll +2 then :)
15:03:11 melwitt gibi, elod: thank you both for the reviews! so much appreciated, I know that was a tough one. please lmk if there is anything I can review for you. I will fix the nits in the bottom patch
15:08:41 melwitt lyarwood: easy review for the cherry pick check fix https://review.opendev.org/759118 (it's blocking my stable-only patch, need it back to queens)
15:13:01 openstackgerrit melanie witt proposed openstack/nova stable/queens: [stable-only] Add functional test for bug 1731668 https://review.opendev.org/756636
15:13:01 openstack bug 1731668 in OpenStack Compute (nova) queens "placement: claim allocations fails with IndexError in _ensure_lookup_table_entry" [Low,In progress] https://launchpad.net/bugs/1731668 - Assigned to melanie witt (melwitt)
15:13:02 openstackgerrit melanie witt proposed openstack/nova stable/queens: [stable-only] Use a separate transaction for reading after race https://review.opendev.org/756637
15:17:05 lyarwood melwitt: ack I'll look shortly
15:18:17 melwitt thanks
15:39:56 sean-k-mooney johnthetubaguy: so i would need to find it again but there is a fuse module that allows you to mount http directoes as a local file system
15:40:25 sean-k-mooney so the config drive alternitve was basically mounting metadata on the host and exposing it via cephfs
15:40:51 sean-k-mooney allow a config driver style approch without a config drive for guests without networking or whatever

Earlier   Later