Earlier  
Posted Nick Remark
#openstack-nova - 2024-06-12
15:38:11 melwitt i.e. at the end of the run 'ceph version' showed me it installed quincy
15:38:16 gouthamr melwitt: that's something we can clean up.. i think the CONTAINER_IMAGE variable is pointing to quincy
15:38:49 gouthamr or not: https://github.com/openstack/devstack-plugin-ceph/blob/13f94aaaf2b4a59581b1be5979600ca18a8df5c3/devstack/lib/cephadm#L32
15:40:33 melwitt yeah, I saw that too. but it ended up installing quincy and I don't remember how. at the moment I'm running devstack-plugin-ceph off the unmaintained/zed branch with a couple of tweaks to make it accept "jammy" and it's successfully installed reef
15:41:39 melwitt actually let me pull up logs on our nova-ceph-multistore job to see if it shows there
15:45:08 melwitt it starts out pulling the reef container image https://zuul.opendev.org/t/openstack/build/d33fa43a546446639f9aa189e341d091/log/job-output.txt#11766 but then it ends up installing the default release (quincy) from the distro https://zuul.opendev.org/t/openstack/build/d33fa43a546446639f9aa189e341d091/log/job-output.txt#3622
15:53:37 melwitt actually it's the other way around, it installs the quincy packages before pulling the container image for reef (L3622 < L11766 ... sigh). I'll try to figure out how it ended up with quincy only, given this
15:54:17 frickler where do you see quincy? e.g. the mon log says reef https://224a5c0545942c9a5cc7-5b0493bbf4e0cfcdf1eae0328a979da8.ssl.cf2.rackcdn.com/884313/46/check/nova-ceph-multistore/d33fa43/controller/logs/ceph/ceph/43acd3ae-f7d3-456c-af2b-229fd530d8bc/ceph-mon.np0037692866_log.txt
15:54:40 frickler (also, where does is actually matter?)
15:54:47 frickler s/is/it/
15:56:18 melwitt I don't yet. I ran the same setup locally and after it was done I ran 'ceph version' and it was quincy. CEPH_RELEASE=reef should install reef, so for me it's a problem
15:57:23 melwitt I have to work backward from that to try to find how that happened. I'm hoping I'll be able to see it in the upstream log so I don't have to run it again locally
16:00:42 frickler might be a good idea to add the output of "ceph versions" at the end of the devstack setup
16:22:16 melwitt all of the ceph logs in the job are showing reef ...
16:24:29 melwitt so I dunno wtf happened in my local run and I have to dig into it. sorry for the noise ... 😖
16:36:00 gouthamr > might be a good idea to add the output of "ceph versions" at the end of the devstack setup
16:36:00 gouthamr thanks frickler; ashrodri will do this
#openstack-nova - 2024-06-13
05:46:33 ralonsoh stephenfin, hello! quick question: I was playing with devstack master but using branch=2024.1
05:46:43 ralonsoh and this came out: https://review.opendev.org/c/openstack/devstack/+/902758
05:46:54 ralonsoh because Nova patch is in master, nova-api was failing
05:47:59 ralonsoh is that ok? shouldn't devstack 2024.2 (in some months) be able to spawn a 2024.1 environment? just asking
06:24:04 frickler ralonsoh: no, devstack isn't supposed to be backwards compatible, you always need to use the matching stable branch for what you want to deploy
06:24:31 ralonsoh understood, so we are good then
06:26:14 sean-k-mooney master does sometimes work with older release but wihtout pinning all the versions in stack rc its proably not going to deploy what you think it is. so ya i always checkout the relevent branch before trying to use it to deploy something
06:27:49 sean-k-mooney just overridieng TARGET_BRANCH has never worked reliably so i dont even try since that is not tested
09:54:19 opendevreview Stephen Finucane proposed openstack/placement master: tox: Simplify functional testenv definitions https://review.opendev.org/c/openstack/placement/+/919578
09:54:20 opendevreview Stephen Finucane proposed openstack/placement master: Integrate pre-commit https://review.opendev.org/c/openstack/placement/+/919579
09:54:20 opendevreview Stephen Finucane proposed openstack/placement master: pre-commit: Add sphinx-lint https://review.opendev.org/c/openstack/placement/+/919580
10:47:22 opendevreview Merged openstack/osc-placement master: Replace simplejson by built-in json https://review.opendev.org/c/openstack/osc-placement/+/919999
13:12:27 ozzzo_work Can anyone help with my "openstack server list" question?
13:12:47 sean-k-mooney proably ask away
13:15:45 ozzzo_work I'm using this stupid web client so I have no history; I'll email it to work from my home computer
13:16:41 sean-k-mooney oh i see
13:16:44 sean-k-mooney openstack server list --limit -1
13:16:50 sean-k-mooney you want to list all vms
13:16:57 sean-k-mooney https://paste.openstack.org/show/bYNdWz8brEgB2ovSGiUF/
13:17:04 ozzzo_work yes
13:17:40 sean-k-mooney i think "openstack server list --all-projects" will list all vms if you jsut dont have limit unless that changed with the sdk and its alwasy using pagination now
13:18:03 ozzzo_work In 5.5.0 the limit is 1000
13:18:11 ozzzo_work let me test in 6.6.0 real quick
13:19:28 sean-k-mooney if you have more vms then the api limit
13:19:34 sean-k-mooney you need to use https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/server.html#cmdoption-openstack-server-list-marker
13:19:44 sean-k-mooney passing the last server uuid as the marker
13:19:50 sean-k-mooney and make mulitple requests
13:20:17 sean-k-mooney but assuming you dont hit the api limit and if you dont pass --limit i would expelct it to list htem all
13:20:45 ozzzo_work we have >1000 VMs in some regions
13:20:50 sean-k-mooney i am not sure if osc handeles automatic pagination if you dont pass a limit
13:24:04 ozzzo_work Theoretically I could rewrite my scripts to use pagination, but "--limit -1" was nice because it was simple. Is there anything I can do to make it work in 6.6.0? I tried setting a different api version but that didn't seem to make a difference
13:26:13 sean-k-mooney no i dont think so. i belive this behaivor changed bcause osc is not using nova clinet anymore and the sdk does not supprot -1 for automatic client side pagination
13:26:32 sean-k-mooney you could try using 2.1
13:26:45 sean-k-mooney but i think pagination for servers predates microverions
13:28:21 ozzzo_work 2.1 doesn't change the behavioor
13:30:50 sean-k-mooney then ya server list supported pagination before micorverions so there is no way to turn it off
13:30:57 sean-k-mooney which means it has to be done client side
13:36:13 ozzzo_work ok ty sean
13:36:27 opendevreview Sahid Orentino Ferdjaoui proposed openstack/nova master: scheduler: fix _get_sharing_providers to support unlimited aggr https://review.opendev.org/c/openstack/nova/+/921665
13:39:46 ozzzo_work aha it looks like I can delay rewriting my script by using "nova list" with -1
13:49:57 sean-k-mooney yes although nova client is deprecated. we proably wont delete it for another release or 3 becasue the python binding are still used in some other project
13:50:05 sean-k-mooney but eventually it will go away
#openstack-nova - 2024-06-14
11:18:32 stephenfin bauzas: The OpenAPI work is kind of in no mans land atm: it's ready to go on my end but I'm waiting for reviews for a few weeks now. Is there someone I can ask to start reviewing that? I've a whole load of patches sitting locally to close it out but I don't want to push them until we're making progress
11:18:48 stephenfin (asking you as PTL, as much as a potential reviewer)
13:11:03 bauzas stephenfin: I have some problems this week due to my internet provider, but I want to review some specs
16:27:17 gmann stephenfin: sorry for delay, I had that in my list. I will start reviewing those soon.
#openstack-nova - 2024-06-17
03:03:35 opendevreview Takashi Kajinami proposed openstack/nova master: WIP: Migrate MEM_ENCRYPTION_CONTEXT from root provider https://review.opendev.org/c/openstack/nova/+/921814
03:10:28 opendevreview Takashi Kajinami proposed openstack/nova master: Migrate MEM_ENCRYPTION_CONTEXT from root provider https://review.opendev.org/c/openstack/nova/+/921814
03:32:32 opendevreview Takashi Kajinami proposed openstack/nova master: Migrate MEM_ENCRYPTION_CONTEXT from root provider https://review.opendev.org/c/openstack/nova/+/921814
06:44:52 opendevreview Takashi Kajinami proposed openstack/nova master: Migrate MEM_ENCRYPTION_CONTEXT from root provider https://review.opendev.org/c/openstack/nova/+/921814
06:45:49 opendevreview Takashi Kajinami proposed openstack/nova master: Migrate MEM_ENCRYPTION_CONTEXT from root provider https://review.opendev.org/c/openstack/nova/+/921814
07:11:42 opendevreview Takashi Kajinami proposed openstack/nova master: Remove unused default argument https://review.opendev.org/c/openstack/nova/+/922073
07:35:38 opendevreview Takashi Kajinami proposed openstack/nova master: Report availability of stateless firmware support https://review.opendev.org/c/openstack/nova/+/908888
07:35:39 opendevreview Takashi Kajinami proposed openstack/nova master: libvirt: Launch instances with stateless firmware https://review.opendev.org/c/openstack/nova/+/908890
09:22:16 opendevreview Takashi Kajinami proposed openstack/nova master: Migrate MEM_ENCRYPTION_CONTEXT from root provider https://review.opendev.org/c/openstack/nova/+/921814
11:57:23 opendevreview Konrad Gube proposed openstack/nova master: Use Cinder's os-extend_volume_completion volume action. https://review.opendev.org/c/openstack/nova/+/873560
12:14:18 opendevreview Takashi Kajinami proposed openstack/nova master: libvirt: Launch instances with stateless firmware https://review.opendev.org/c/openstack/nova/+/908890
14:22:24 dansmith sean-k-mooney: are you going to reply to this? https://review.opendev.org/c/openstack/nova/+/904424/9
14:31:47 sean-k-mooney oh i spoke to stephen about that in person
14:32:14 sean-k-mooney tldr the missed that the monkey patch was done as a sideefect of the __init__.py
14:33:05 sean-k-mooney that was however goign to be one fo the things i changed based on other feedback
14:33:48 dansmith ack, maybe you could update it so it doesn't look like it's hanging?
14:33:55 sean-k-mooney sure
14:34:10 dansmith and I assume that means we're waiting on a revision?
14:34:15 sean-k-mooney in mels version fo the scater gather change you ask for this to be more explict liek this https://review.opendev.org/c/openstack/nova/+/650172/28/nova/cmd/__init__.py
14:34:39 sean-k-mooney dansmith: yes i was ment to work on it last week but got pulled into other things
14:34:52 sean-k-mooney the core would be the same but one thing i noticed in neutron is
14:35:07 sean-k-mooney instead of using /bin at the top level they use /cmd and /cmd/eventlet
14:35:22 sean-k-mooney where only the eventlet subdir is monkney patched
14:35:35 dansmith ack
14:35:36 sean-k-mooney i was wondering if that would be better for consitency
14:36:05 dansmith yeah I mean, if there is prior art that makes sense to me, and also makes it easier to see where major eventlet deps are
14:36:44 sean-k-mooney yep that was the idea behind /bin but stephen said having a bin directory at the top level could be confusing
14:36:52 sean-k-mooney since technially they files are not executable
14:36:59 sean-k-mooney they are used by pbr to create teh executables
14:37:06 dansmith meh
14:37:45 sean-k-mooney the pathces are reviewable in general but i do plan to respine them this week
14:38:24 dansmith ack, I just figure I'll wait until they're respun, but I think we should make sure we don't lose track of this
14:39:57 sean-k-mooney thanks for looking in anycase. ill let you know when its up
15:39:11 zigo How may I check why the nova-scheduler is filtering my destination host when doing a live-migration ?
15:41:12 zigo I'm trying to do:
15:41:12 zigo openstack --os-compute-api-version 2.96 server migrate --live-migration --host compute-1.infomaniak.ch <vm-id>
15:41:12 zigo and then in the scheduler logs, I'm getting:

Earlier   Later