Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-09-06
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
17:42:41 sean-k-mooney yep
17:43:06 sean-k-mooney cold standby or a tool like k8s that will recreat the comptue agent with the same name/config elsewhere
17:43:09 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:26 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:44:02 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:27 sean-k-mooney JayF: for me the real highlight willl be when we delete the peer_list code in 2024.2
17:44:46 JayF I mean, that's really the culmination of the pieces I'm talking about
17:44:54 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:45:31 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:39 JayF but I'm one vote out of many on how it gets framed, so we'll see how it works out
17:45:56 sean-k-mooney well the intent of the highlights is to be short
17:46:05 sean-k-mooney we also have the release notes
17:46:09 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:22 sean-k-mooney but again im not agaisnt advertising the change in driection so more peopel see it
17:47:03 sean-k-mooney next cycle im expectign the highlights to include the deletion of the hyperv and vmware dirvers...
17:47:38 sean-k-mooney that woudl be both a highlight and a lowlight
17:47:55 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:59 JayF yeah?
17:48:20 sean-k-mooney well we marked them as experimeental and almost deleted vmware 2 before
17:48:27 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:47 sean-k-mooney the removal is becasue of 0 testing or maintainces for basicely 2-3 years
17:49:27 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:42 gmann sure
17:49:59 sean-k-mooney we have similar issues with oslo.vmware i think
17:50:36 gmann oslo.vmware is still there not sure what status but it is not retired yet
17:51:27 sean-k-mooney it looks like it had 6ish patches since last cycle
17:51:45 sean-k-mooney the issue in the past was with its use of studs-jarako or whatever it was
17:52:18 sean-k-mooney its now using suds-community
17:52:28 sean-k-mooney but i dont know if that is healty or not
17:52:49 sean-k-mooney last release was a year ago "Jun 28, 2022"
17:53:27 sean-k-mooney it officlally supprot up to 3.9 but i dont knwo if we will start seeing issues with 3.11

Earlier   Later