| *** bauzas_ is now known as bauzas | 00:17 | |
| *** bauzas_ is now known as bauzas | 00:49 | |
| *** bauzas_ is now known as bauzas | 03:01 | |
| *** bauzas_ is now known as bauzas | 03:50 | |
| *** bauzas_ is now known as bauzas | 04:26 | |
| *** bauzas_ is now known as bauzas | 05:32 | |
| *** bauzas_ is now known as bauzas | 05:45 | |
| *** bauzas_ is now known as bauzas | 06:30 | |
| *** bauzas_ is now known as bauzas | 06:38 | |
| *** ralonsoh_away is now known as ralonsoh | 07:09 | |
| bauzas | morning from a 4G LTE connection | 07:17 |
|---|---|---|
| bauzas | frickler: heh, just saw your yesterday ping | 07:19 |
| bauzas | frickler: FWIW, I get a pretty decent and solid 20Mbps on LTE despite many folks doing the same around me | 07:20 |
| 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 |
| bauzas | (chosen my provider on purpose :) ) | 07:21 |
| frickler | bauzas: looks like your irc connection still has been flapping a lot, but that sounds better than I had expected indeed | 07:26 |
| bauzas | frickler: I eventually fixed the flapping yesterday around 9pm local time, so yeah my bouncer may have flipped a bit | 07:27 |
| bauzas_ | doh | 07:30 |
| bauzas_ | just because I said that :) | 07:30 |
| *** bauzas_ is now known as bauzas | 07:33 | |
| bauzas | that's actually the problem with 4G connections : they aren't designed to be stable and the connections can flip | 07:35 |
| *** bauzas_ is now known as bauzas | 08:04 | |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| opendevreview | OpenStack Release Bot proposed openstack/python-novaclient master: Update master for stable/2023.2 https://review.opendev.org/c/openstack/python-novaclient/+/894077 | 09:37 |
| *** bauzas_ is now known as bauzas | 10:07 | |
| *** bauzas_ is now known as bauzas | 10:15 | |
| *** bauzas_ is now known as bauzas | 11:31 | |
| 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: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 |
| 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:14 |
| 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:51 |
| bauzas | if you can review them quickly, would be awesome | 14:52 |
| opendevreview | Amit Uniyal proposed openstack/nova master: Added context manager for instance lock https://review.opendev.org/c/openstack/nova/+/873648 | 15:48 |
| opendevreview | Amit Uniyal proposed openstack/nova master: Disconnecting volume from the compute host https://review.opendev.org/c/openstack/nova/+/877446 | 15:48 |
| opendevreview | Amit Uniyal proposed openstack/nova master: Removed explicit call to delete attachment https://review.opendev.org/c/openstack/nova/+/891289 | 15:48 |
| auniyal | dansmith, sean-k-mooney can you please have another look on https://review.opendev.org/q/topic:lp%252F2012365 | 15:51 |
| 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 |
| bauzas | I spoke about ironic-shards, unified limits and all the other features, so please bare my Frenglish wording | 17:22 |
| 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:37 |
| sean-k-mooney | JayF: the tow kind of go hand in had but | 17:38 |
| sean-k-mooney | im not sure if that is a nova or iroic highlight | 17:38 |
| sean-k-mooney | i.e. the ha model change | 17:38 |
| sean-k-mooney | the ha model change is not really a nova feature/highlight in my mind | 17:39 |
| 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 |
| sean-k-mooney | since it was technially somethign you could have done before, you just needed to share by conductor group | 17:39 |
| 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 |
| JayF | okay, you're missing a piece here I think | 17:39 |
| 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 |
| JayF | today, you do a build request, any of those 5 can build on any of those 1000 nodes | 17:40 |
| 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:40 |
| sean-k-mooney | yes and no | 17:41 |
| JayF | this race-y half-horizontal-scaled compute service model goes away | 17:41 |
| sean-k-mooney | the scudler still selectied one of the 5 to do the build | 17:41 |
| sean-k-mooney | what really changed is it wotn rebalance | 17:41 |
| 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 |
| sean-k-mooney | if the service died | 17:41 |
| 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 |
| sean-k-mooney | to the avaiable nodes yes | 17:42 |
| 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 | 17:42 |
| sean-k-mooney | yep | 17:42 |
| sean-k-mooney | cold standby or a tool like k8s that will recreat the comptue agent with the same name/config elsewhere | 17:43 |
| JayF | this is a pretty radical change from how nova compute services have been treated alongside Ironic ... probably the largest since the actual deprecation of the clusteredcomputemanager back in like, Juno | 17:43 |
| JayF | so yeah, it's going to be in Ironic cycle highlights and I'll talk about it, but it should be in Nova too | 17:43 |
| JayF | tbh this is sorta a win for unity in OpenStack overall, we're removing what has traditionally been a significant point of technical tension between Ironic/Nova, we should all celebrate it :D | 17:44 |
| sean-k-mooney | JayF: for me the real highlight willl be when we delete the peer_list code in 2024.2 | 17:44 |
| JayF | I mean, that's really the culmination of the pieces I'm talking about | 17:44 |
| sean-k-mooney | but sure we can mention it i just would have epected the highlights to be framed mainly in the context of new featurs | 17:44 |
| JayF | My background is sorta, in-the-weeds operations traditionally, so I tend to bristle at "look at the new shiny" without calling out the tradeoff made | 17:45 |
| JayF | but I'm one vote out of many on how it gets framed, so we'll see how it works out | 17:45 |
| sean-k-mooney | well the intent of the highlights is to be short | 17:45 |
| sean-k-mooney | we also have the release notes | 17:46 |
| JayF | I hope johnthetubaguy weighs in on that though, I think he has a pretty good view on what this would mean across a wider variety of environments than I have | 17:46 |
| sean-k-mooney | but again im not agaisnt advertising the change in driection so more peopel see it | 17:46 |
| sean-k-mooney | next cycle im expectign the highlights to include the deletion of the hyperv and vmware dirvers... | 17:47 |
| sean-k-mooney | that woudl be both a highlight and a lowlight | 17:47 |
| JayF | interesting, that means that at least at the virt driver layer, you've gotten rid of most of the centralized drivers *or* we've added a mechanism to make them shardable | 17:47 |
| JayF | yeah? | 17:47 |
| sean-k-mooney | well we marked them as experimeental and almost deleted vmware 2 before | 17:48 |
| * JayF afk for a bit | 17:48 | |
| gmann | hyperv can definitely go in as ow-win is gone now and I am going to remove the all deps of it once 2024.1 is open | 17:48 |
| sean-k-mooney | the removal is becasue of 0 testing or maintainces for basicely 2-3 years | 17:48 |
| sean-k-mooney | gmann: i was goign to bring this up on the ptg adgenda but ya that why i mentioned hyperv i was aware of the os-win dep issue | 17:49 |
| gmann | sure | 17:49 |
| sean-k-mooney | we have similar issues with oslo.vmware i think | 17:49 |
| gmann | oslo.vmware is still there not sure what status but it is not retired yet | 17:50 |
| sean-k-mooney | it looks like it had 6ish patches since last cycle | 17:51 |
| sean-k-mooney | the issue in the past was with its use of studs-jarako or whatever it was | 17:51 |
| sean-k-mooney | its now using suds-community | 17:52 |
| sean-k-mooney | but i dont know if that is healty or not | 17:52 |
| sean-k-mooney | last release was a year ago "Jun 28, 2022" | 17:52 |
| sean-k-mooney | it officlally supprot up to 3.9 but i dont knwo if we will start seeing issues with 3.11 | 17:53 |
| sean-k-mooney | 3.10 and 3.11 started removing some deperecated features | 17:53 |
| *** bauzas_ is now known as bauzas | 18:00 | |
| *** bauzas_ is now known as bauzas | 22:11 | |
| opendevreview | Merged openstack/python-novaclient master: Update master for stable/2023.2 https://review.opendev.org/c/openstack/python-novaclient/+/894077 | 22:21 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!