Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-10-28
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 sean-k-mooney placemnt only depneds on keystone
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: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 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:48 openstackgerrit melanie witt proposed openstack/nova stable/queens: [stable-only] Add functional test for bug 1731668 https://review.opendev.org/756636
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 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:28:20 brinzhang_ it comes from bug 1897424
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 openstack Launchpad bug 1901739 in OpenStack Compute (nova) " libvirt.libvirtError: internal error: missing block job data for disk 'vda'" [High,Confirmed]
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: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 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:01 openstackgerrit melanie witt proposed openstack/nova stable/queens: [stable-only] Add functional test for bug 1731668 https://review.opendev.org/756636
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
15:42:06 sean-k-mooney the other cyborg like storage usecause weas using cyborg or something else to manage local storage on the host that can be exposed as fast epmeral storage withoug using the falvor epmeral option
15:42:37 sean-k-mooney that would only be useful if we had the ablity to have multiple device profiles or have a --device attach/detach
15:43:07 sean-k-mooney so right now im not proposing the cyborg approch since you cant contole it outside the flavor
15:43:17 sean-k-mooney also i have other more important things
15:51:01 sean-k-mooney but ya i have wanted to have a cyborg lvm driver for a while that we could use for local storage and testing in the gate since we can test programablity by just downloading the glance image to the volume.

Earlier   Later