| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-10-28 | |||
| 18:28:21 | rm_work | followup -- placement is microversioned, right? so ... we could feasibly run nova at Stein and placement at ... Master? :P | |
| 18:28:52 | rm_work | (once we've done the initial migration to standalone placement service/DB, in stein) | |
| 18:30:35 | rm_work | there is only a dependency on the NOVA side that placement must be at least at the same version as nova | |
| 18:30:54 | rm_work | there's no such reverse dependency on the placement side? | |
| 18:31:07 | sean-k-mooney | rm_work: correct | |
| 18:31:18 | melwitt | yeah. as mentioned in the doc, placement must be same or ahead of nova bc of the dependency but other than that, it is designed to work independently by way of the API microversions | |
| 18:31:20 | sean-k-mooney | nova has a min placment version it works with | |
| 18:31:22 | rm_work | our cloud is about to look like: Nova(Stein), Placement(Master), Neutron(Train), Octavia(Master) | |
| 18:31:27 | sean-k-mooney | but placement does not have any depency on nova | |
| 18:31:57 | sean-k-mooney | rm_work: that should be fine at least Nova(Stein), Placement(Master), Neutron(Train) | |
| 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 | 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 :) | |