| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-06-12 | |||
| 12:49:36 | 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 | |
| 14:01:55 | ozzzo_work | We built a new venv for wallaby which uses openstack CLI version 6.6.0 (old venv used 5.5.0), and now I get an error when I try to use "openstack server list --limit -1" to get all hosts: https://paste.openstack.org/show/bYNdWz8brEgB2ovSGiUF/ | |
| 14:02:11 | ozzzo_work | how can I get a list of all VMs in 6.6.0? | |
| 15:18:48 | 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 | |
| 15:19:43 | 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 | |
| 15:27:07 | melwitt | I have found that it's not possible to install the ceph reef release with devstack-plugin-ceph (due to a recent-ish change) and there's changes proposed that AFAICT would remove the ability to install ceph on ubuntu entirely https://review.opendev.org/q/topic:%22cleanup-ceph-installer%22 | |
| 15:28:56 | frickler | melwitt: that change should only drop the old pkg based install and use cephadm instead? at least that's how I understood gouthamr's mail | |
| 15:29:46 | gouthamr | frickler: +1 ; melwitt: i use reef most of the time these days.. what's failing? | |
| 15:30:15 | melwitt | frickler: hm, so that may mean it's not doing so intentionally but AFAICT from the code, it would have that result https://review.opendev.org/c/openstack/devstack-plugin-ceph/+/918952/6/devstack/lib/cephadm#141 | |
| 15:31:20 | frickler | melwitt: according to the comment the binary should be the same for all distros | |
| 15:32:19 | melwitt | I only see it pulling rpm packages in that function? I dunno if I'm just totally misunderstanding this | |
| 15:33:10 | frickler | it is pulling the cephadm binary afaict, which then is executed to do everything else | |
| 15:35:29 | gouthamr | melwitt: yes that's confusing, i thought my comment above would help with the confusion | |
| 15:35:59 | gouthamr | melwitt: https://zuul.opendev.org/t/openstack/build/a9d3d319d36f403f9e33febec5064a48/log/controller/logs/devstacklog.txt#9960 -- here's a recent integrated gate/CI job deploying reef | |
| 15:36:29 | melwitt | hm, ok. so the curl -f -O https://download.ceph.com/rpm-${ceph_version}/${os_release}/noarch/cephadm should be a binary that also runs on ubuntu I guess? | |
| 15:36:33 | gouthamr | yes | |
| 15:36:55 | gouthamr | melwitt: its not an RPM even if its put, very confusingly, in a rpm repo | |
| 15:37:35 | gouthamr | (the integrated job above runs on ubuntu 22.04/jammy) | |
| 15:37:38 | melwitt | I ran with CEPHADM_DEPLOY=true yesterday and it installed quincy even though I used CEPH_RELEASE=reef so I guess I should have known that. so I guess the only issue currently is that it can't install reef for some reason | |
| 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? | |