| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-09-05 | |||
| 16:37:47 | elodilles | sean-k-mooney: gate tests have passed | |
| 16:37:52 | sean-k-mooney | sweet | |
| 16:38:02 | auniyal | #info Please{10} *review* these backport patches of stable 2023.1, zed and yoga for next minor release | |
| 16:38:09 | auniyal | #info most of these already have one +2. | |
| 16:38:09 | auniyal | #link https://etherpad.opendev.org/p/release-liaison-PatchesToReview | |
| 16:38:15 | auniyal | thanks | |
| 16:38:43 | bauzas | cool, will try a round tomorrow | |
| 16:39:11 | bauzas | sounds to me it's important to deliver a 2023.1 release shortly | |
| 16:39:34 | bauzas | #topic Open discussion | |
| 16:39:45 | bauzas | nothing on the agenda, anything anyone ? | |
| 16:42:01 | bauzas | ok, looks not | |
| 16:42:05 | bauzas | thanks everyone | |
| 16:42:09 | bauzas | see you next week | |
| 16:42:12 | bauzas | #endmeeting | |
| 16:42:12 | opendevmeet | Meeting ended Tue Sep 5 16:42:12 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 16:42:12 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2023/nova.2023-09-05-16.00.html | |
| 16:42:12 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2023/nova.2023-09-05-16.00.txt | |
| 16:42:12 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2023/nova.2023-09-05-16.00.log.html | |
| 16:42:20 | elodilles | thanks o/ | |
| #openstack-nova - 2023-09-06 | |||
| 02:37:21 | opendevreview | Ghanshyam proposed openstack/os-traits master: DNM: testing python 3.11 https://review.opendev.org/c/openstack/os-traits/+/893819 | |
| 02:39:10 | opendevreview | Ghanshyam proposed openstack/os-resource-classes master: DNM testing python 3.11 https://review.opendev.org/c/openstack/os-resource-classes/+/893820 | |
| 02:48:12 | opendevreview | Ghanshyam proposed openstack/placement master: Fix bindep.txt for python 3.11 job(Debian Bookworm) https://review.opendev.org/c/openstack/placement/+/893821 | |
| 02:49:51 | opendevreview | Ghanshyam proposed openstack/python-novaclient master: DNM testing python 3.11 https://review.opendev.org/c/openstack/python-novaclient/+/893822 | |
| 08:19:30 | yusufgungor | Hi everyone, is it possible to update server group of an existing instance? | |
| 08:32:53 | sean-k-mooney | yusufgungor: no its not. they are set when the vm is created and cannot be modified | |
| 09:15:04 | yusufgungor | Thanks @sean-k-mooney this is so sad to hear. I wish there is a way like updating db tables etc. | |
| 09:57:25 | sean-k-mooney | yusufgungor: updating the db tables could be doen but you woudl have to manually verify that the server group rules were not violated | |
| 10:12:41 | bauzas | sorry folks, facing a huge fiber network outage today, resolution around Sep 11 | |
| 10:12:56 | bauzas | on 4G networking | |
| 10:14:08 | sean-k-mooney | thats kind of rediculous | |
| 11:29:47 | auniyal | sean-k-mooney, can you please have review this series again https://review.opendev.org/c/openstack/nova/+/873648 | |
| 12:30:43 | bauzas | sean-k-mooney: looks like the town operator trampled a lot of fibers when he tried to fix just one this morning | |
| 12:31:26 | bauzas | I'd say around 200-300 houses have problems | |
| 12:31:55 | bauzas | I'll eventually just pay for a 4G router I think | |
| 12:32:05 | sean-k-mooney | or starlink | |
| 12:36:22 | bauzas | sean-k-mooney: I wouldn't pay 500€ just for once | |
| 12:36:22 | bauzas | sean-k-mooney: I wouldn't pay 500€ just for once | |
| 12:41:12 | sean-k-mooney | hehe i know just saying if it was a common issue that might be better then 4g | |
| 12:46:54 | frickler | how much performance do you expect from 4g if 300 houses around you are doing the same thing? ;) | |
| 13:15:19 | auniyal | thanks sean-k-mooney | |
| 15:44:01 | atmark | hello, can anyone tell me what is happening behind the scenes with nova when a VM is left in `VERIFY_STATE` ? Is there kind of locking mechanism in place that nova does to remote storage and it's only get released a when the state is confirmed or reverted ? | |
| 15:52:15 | atmark | or just a hint to which a file should I look so I can reading the code | |
| 15:52:27 | atmark | start reading* | |
| 17:50:43 | opendevreview | Ghanshyam proposed openstack/placement master: Fix bindep.txt for python 3.11 job(Debian Bookworm) https://review.opendev.org/c/openstack/placement/+/893821 | |
| 19:49:52 | gmann | bauzas: dansmith gibi sean-k-mooney in case either of you around, py3.11 on placement is passing now https://review.opendev.org/c/openstack/placement/+/893821 | |
| 19:50:45 | dansmith | gmann: got it thanks | |
| 19:50:48 | gmann | and I tested all other nova repo and they are good for py3.11 which will become voting after 2023.2 release, so once 893821 merge we are good from nvoa side - https://review.opendev.org/q/topic:nova-py311 | |
| 19:52:24 | sean-k-mooney | placement one looks reasonable to me | |
| 21:26:34 | opendevreview | Merged openstack/placement master: Fix bindep.txt for python 3.11 job(Debian Bookworm) https://review.opendev.org/c/openstack/placement/+/893821 | |
| #openstack-nova - 2023-09-07 | |||
| 07:17:02 | bauzas | morning from a 4G LTE connection | |
| 07:19:47 | bauzas | frickler: heh, just saw your yesterday ping | |
| 07:20:15 | bauzas | frickler: FWIW, I get a pretty decent and solid 20Mbps on LTE despite many folks doing the same around me | |
| 07:21:08 | bauzas | but I'm lucky, my mobile provider is using a very specific 4G band that a few devices can support (B28 700MHz) so I'm not very impacted by noisy neighbors | |
| 07:21:44 | bauzas | (chosen my provider on purpose :) ) | |
| 07:26:16 | frickler | bauzas: looks like your irc connection still has been flapping a lot, but that sounds better than I had expected indeed | |
| 07:27:05 | bauzas | frickler: I eventually fixed the flapping yesterday around 9pm local time, so yeah my bouncer may have flipped a bit | |
| 07:30:07 | bauzas_ | doh | |
| 07:30:08 | bauzas_ | just because I said that :) | |
| 07:35:10 | bauzas | that's actually the problem with 4G connections : they aren't designed to be stable and the connections can flip | |
| 09:37:02 | opendevreview | OpenStack Release Bot proposed openstack/os-vif stable/2023.2: Update .gitreview for stable/2023.2 https://review.opendev.org/c/openstack/os-vif/+/894060 | |
| 09:37:04 | opendevreview | OpenStack Release Bot proposed openstack/os-vif stable/2023.2: Update TOX_CONSTRAINTS_FILE for stable/2023.2 https://review.opendev.org/c/openstack/os-vif/+/894062 | |
| 09:37:07 | opendevreview | OpenStack Release Bot proposed openstack/os-vif master: Update master for stable/2023.2 https://review.opendev.org/c/openstack/os-vif/+/894064 | |
| 09:37:11 | opendevreview | OpenStack Release Bot proposed openstack/osc-placement stable/2023.2: Update .gitreview for stable/2023.2 https://review.opendev.org/c/openstack/osc-placement/+/894066 | |
| 09:37:12 | opendevreview | OpenStack Release Bot proposed openstack/osc-placement stable/2023.2: Update TOX_CONSTRAINTS_FILE for stable/2023.2 https://review.opendev.org/c/openstack/osc-placement/+/894067 | |
| 09:37:14 | opendevreview | OpenStack Release Bot proposed openstack/osc-placement master: Update master for stable/2023.2 https://review.opendev.org/c/openstack/osc-placement/+/894069 | |
| 09:37:24 | opendevreview | OpenStack Release Bot proposed openstack/python-novaclient stable/2023.2: Update .gitreview for stable/2023.2 https://review.opendev.org/c/openstack/python-novaclient/+/894074 | |
| 09:37:25 | opendevreview | OpenStack Release Bot proposed openstack/python-novaclient stable/2023.2: Update TOX_CONSTRAINTS_FILE for stable/2023.2 https://review.opendev.org/c/openstack/python-novaclient/+/894076 | |
| 09:37:26 | opendevreview | OpenStack Release Bot proposed openstack/python-novaclient master: Update master for stable/2023.2 https://review.opendev.org/c/openstack/python-novaclient/+/894077 | |
| 14:13:33 | tstachecki | sean-k-mooney (or whomever else): Apologies, but could I poke you fro a follow up on: https://review.opendev.org/c/openstack/nova/+/892614 | |
| 14:14:13 | tstachecki | An intern authored the PR and his time is ending with us Friday; trying to leave him with a good impression of working iwth the OSS community. | |
| 14:14:46 | tstachecki | I can always take ownership of the PR if it lingers past Friday, but would love to see him drag it across the line before he leaves. | |
| 14:51:56 | bauzas | folks I was wanting to work on the cycle highlights yesterday but given my network outage, I forgot about it, I'll provide them today | |
| 14:52:09 | bauzas | if you can review them quickly, would be awesome | |
| 15:48:06 | opendevreview | Amit Uniyal proposed openstack/nova master: Added context manager for instance lock https://review.opendev.org/c/openstack/nova/+/873648 | |
| 15:48:07 | opendevreview | Amit Uniyal proposed openstack/nova master: Disconnecting volume from the compute host https://review.opendev.org/c/openstack/nova/+/877446 | |
| 15:48:07 | opendevreview | Amit Uniyal proposed openstack/nova master: Removed explicit call to delete attachment https://review.opendev.org/c/openstack/nova/+/891289 | |
| 15:51:46 | auniyal | dansmith, sean-k-mooney can you please have another look on https://review.opendev.org/q/topic:lp%252F2012365 | |
| 17:22:02 | bauzas | johnthetubaguy: JayF: dansmith: sean-k-mooney: melwitt: others: I just provided our Bobcat cycle highlights, I'd appreciate if all of you could round about this change and comment on it https://review.opendev.org/c/openstack/releases/+/894213 | |
| 17:22:41 | bauzas | I spoke about ironic-shards, unified limits and all the other features, so please bare my Frenglish wording | |
| 17:37:12 | JayF | bauzas: Commented. The bigger thing for me is logically, for most Ironic+Nova operators, the HA model changing is much more impactful than node sharding being intorduced. (peer list change impacts all Ironic deployments; sharding only impacts those at multi-hundreds of nodes exposed in nova scale) | |
| 17:38:12 | sean-k-mooney | JayF: the tow kind of go hand in had but | |
| 17:38:25 | sean-k-mooney | im not sure if that is a nova or iroic highlight | |
| 17:38:31 | sean-k-mooney | i.e. the ha model change | |
| 17:39:15 | sean-k-mooney | the ha model change is not really a nova feature/highlight in my mind | |
| 17:39:33 | JayF | I look at this sharding+peer_list deprecation change as Ironic team mostly giving up and adopting the nova model of "one logical compute service has exclusive ownership of resources it manages", and accepting the follow-on HA model of "if a section of the cloud goes dark, it's probably OK" (with a "or you can have a cold standby" as an option for Ironci users) | |
| 17:39:48 | sean-k-mooney | since it was technially somethign you could have done before, you just needed to share by conductor group | |
| 17:39:54 | JayF | From an Ironic standpoint; there is zero Ironic configuration that changes to enable the HA model change. It's all nova configuration and system configuration on the node | |
| 17:39:58 | JayF | okay, you're missing a piece here I think | |
| 17:40:23 | JayF | Lets talk about a real world example; you could have 1000 nodes exposed across 5 computes, with 5 compute services in peer_list | |
| 17:40:33 | JayF | today, you do a build request, any of those 5 can build on any of those 1000 nodes | |
| 17:40:53 | JayF | with the peer_list deprecation, we are *forcing* users to either shard, or have all their nodes managed by a single compute service | |
| 17:41:05 | sean-k-mooney | yes and no | |
| 17:41:07 | JayF | this race-y half-horizontal-scaled compute service model goes away | |
| 17:41:21 | sean-k-mooney | the scudler still selectied one of the 5 to do the build | |
| 17:41:30 | sean-k-mooney | what really changed is it wotn rebalance | |
| 17:41:31 | JayF | so a Nova+Ironic user will have to nontrivially change the devops automation around building their compute services, even if they aren't going to be sharding anymore | |
| 17:41:37 | sean-k-mooney | if the service died | |
| 17:42:09 | JayF | if the service died, any instances it was managing would not be able to be managed, but you'd retain access to all the ironic capacity thru its peers | |
| 17:42:27 | sean-k-mooney | to the avaiable nodes yes | |
| 17:42:30 | JayF | now if you want to maintain access to that capacity, you'd need something like e.g. a cold standby compute service to spin up and restore that access | |