| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-09-16 | |||
| 18:17:06 | melwitt | tomorrow we can ask elodilles what he thinks. I think he's likely done for today | |
| 18:17:17 | sean-k-mooney | we fixed it the last time https://github.com/openstack/nova/commit/b2037fc4e356b55949339a1358c16431a9ab8930 | |
| 18:17:24 | fungi | right, i personally never had high hopes for the l-c experiment (mainly because of the forward flow of time and packages from a decade ago not being able to reasonably predict modern systems), but especially not for stable branches. i would cut my losses on l-c if it were me, but it's not my call | |
| 18:17:46 | dansmith | we had some resistance to removing it in glance, | |
| 18:18:03 | dansmith | but then we got to a point where we couldn't add a new dep version or pip would run off into lala land, which helped seal the deal :) | |
| 18:18:20 | sean-k-mooney | it would resolve the disccion im haveing with stephenfin too | |
| 18:18:39 | sean-k-mooney | where he wanted to have it pinend to the oldest python we support for a release | |
| 18:18:47 | sean-k-mooney | which i disagreed with | |
| 18:19:03 | sean-k-mooney | since that was not realistic to how distors worked | |
| 18:19:37 | fungi | well, basically if you head down that road, using old dependencies is not isolated to the python deps you have, those don't exist in a vaccuum and they make assumptions about contemporary systems as a whole | |
| 18:20:35 | sean-k-mooney | speaking of being done for today i likely should finish up soon | |
| 18:20:48 | fungi | i agree it's not a very good way to try to mimic what stable distros experience, because 1. they pin a lot more about the entire environment than we reasonably can, and 2. they backport fixes to things which wouldn't be reflected with this test methodology anyway | |
| 18:21:00 | sean-k-mooney | since this is now efffectily blocking the backport of a cve fix however i think we likely should move forward with droping it so we can do the release | |
| 18:21:37 | fungi | another alternative is early transition out of maintenance mode for stable/ussuri, but that seems like the most drastic choice | |
| 18:22:02 | sean-k-mooney | fungi: well it was more the version of the packate and the version of python are often uncoupled | |
| 18:22:16 | fungi | yes, that too | |
| 18:22:42 | fungi | anyway, lower constraints jobs are not mandated by the pti, so dropping them doesn't affect the maintenance state for the branch | |
| 18:22:54 | fungi | at least not in any official sense | |
| 19:08:02 | opendevreview | Dmitrii Shcherbakov proposed openstack/nova master: [PoC][yoga] Off-path Networking Backends Support https://review.opendev.org/c/openstack/nova/+/808199 | |
| 19:48:16 | gibi | bauzas: I've update the nova rc1 patch with the prelude hash https://review.opendev.org/c/openstack/releases/+/808706 I think it is good to go now | |
| 20:34:52 | admin1 | hi @all .. how does a nova snapshot work when both glance and nova are backed by ceph ? does it still create a local disk on the hypervisor and uploads ? | |
| 20:35:03 | admin1 | or does everything happen entirely on the ceph side ? | |
| 20:39:10 | admin1 | my snapshot is kind of stuck .. even for a small instance .. and i don't see anything in the hypervisor ( files, or uploads or disk waiting ) so i think its entirely on the ceph side .. just wanted to validate | |
| 20:52:01 | dansmith | admin1: if you have them share a pool, nova just asks ceph to do the snapshot in-place and then nova "tells" glance about it.. no bits fly around like normal | |
| 20:52:35 | dansmith | ("them" meaning glance and nova) | |
| 20:56:12 | opendevreview | melanie witt proposed openstack/nova master: Add section for 'nova-manage placement audit' tool https://review.opendev.org/c/openstack/nova/+/809479 | |
| 20:56:32 | admin1 | nova is on vms pool and glance is on images pool .. so 2 diff pools | |
| 20:58:15 | dansmith | admin1: okay so I think that means it's going to download and then re-upload it, but not totally positive | |
| 20:59:05 | melwitt | admin1: if you have configured your deployment like this https://docs.ceph.com/en/mimic/rbd/rbd-openstack/#configure-openstack-to-use-ceph it should be able to do the fast snapshot | |
| 21:00:09 | admin1 | melwitt , refering to enabling copy-on-write cloning of images ? | |
| 21:00:35 | melwitt | yes | |
| 21:01:17 | admin1 | its not enabled .. | |
| 21:01:22 | admin1 | what does exactly "Note that this exposes the back end location via Glance’s API, so the endpoint with this option enabled should not be publicly accessible." mean ? | |
| 21:01:54 | admin1 | i will try to find more | |
| 21:02:07 | admin1 | melwitt, in absense of this setting, how does the nova snapshot work ? | |
| 21:02:08 | melwitt | another thing that can cause it to not do the CoW is if the image is not in RAW format, but I think glance might automatically convert to RAW now, depending on what release you have | |
| 21:02:19 | admin1 | all images are in raw format | |
| 21:02:31 | admin1 | i converted them before uploading to glance | |
| 21:02:58 | melwitt | that is a warning that the backend url will be shown to users querying glance API so it should not be a url that is publicly accessible (for security reason) | |
| 21:03:45 | melwitt | ok cool. if you don't set up as described in that ceph doc, nova will download the image from glance first and then boot the instance | |
| 21:04:40 | melwitt | if the image is large, it can be slow | |
| 21:08:37 | melwitt | there's some glance setting around chunk size which you might want to adjust to get better throughput, I think it's this? https://docs.openstack.org/glance/latest/configuration/glance_api.html#glance.store.rbd.store.rbd_store_chunk_size | |
| 21:09:03 | melwitt | *settings | |
| 21:18:58 | opendevreview | melanie witt proposed openstack/nova master: Add section for 'nova-manage placement audit' tool https://review.opendev.org/c/openstack/nova/+/809479 | |
| 21:26:55 | admin1 | melwitt, when you meant backend url, is that the url of the ceph ? | |
| 21:27:01 | admin1 | i mean its osd url | |
| 21:29:12 | admin1 | melwitt, what glance command can i use to see the url being exposed .. | |
| 22:07:48 | opendevreview | melanie witt proposed openstack/nova master: Add section for 'nova-manage placement audit' tool https://review.opendev.org/c/openstack/nova/+/809479 | |
| 22:19:47 | melwitt | admin1: yeah ceph url I think. you can see it by doing an 'image show' if you have enabled showing it https://docs.openstack.org/api-ref/image/v2/index.html?expanded=show-image-detail#show-image | |
| 22:20:13 | melwitt | https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/image-v2.html#image-show | |
| 22:45:33 | dansmith | admin1: that location thing means glance will show things like rbd://mycephserver:port/path/to/thing, and so you likely want a different endpoint with that enabled that regular untrusted users can't see | |
| 22:46:00 | dansmith | admin1: without the fast cow snapshot, nova will pause the VM, download its disk, flatten it out, upload it to glance, and then unpause the VM | |
| 22:46:30 | dansmith | admin1: it's far more efficient to just let ceph snapshot it for you (pretty much instantaneously) and then just tell glance it exists | |
| #openstack-nova - 2021-09-17 | |||
| 04:56:48 | opendevreview | melanie witt proposed openstack/nova master: WIP Enable unified limits in the nova-next job https://review.opendev.org/c/openstack/nova/+/789963 | |
| 07:02:12 | opendevreview | melanie witt proposed openstack/nova master: WIP Enable unified limits in the nova-next job https://review.opendev.org/c/openstack/nova/+/789963 | |
| 07:26:11 | bauzas | gibi: thanks for having approved the nova RC1 change | |
| 07:26:38 | gibi | bauzas: the gate seems to be down due to pip resolve issue (jobs times out) so we haven't merged the RC1 yet | |
| 07:26:46 | bauzas | yeah I saw | |
| 07:26:54 | bauzas | infra is on it ? | |
| 07:27:12 | gibi | release team knows it but nobody able to reproduce it locally afaik | |
| 07:27:17 | bauzas | shit. | |
| 07:53:59 | bauzas | gibi: I'm happy to see you signed up our team for the PTG :p | |
| 07:54:39 | gibi | bauzas: yepp I did that early :) | |
| 07:54:46 | gibi | would be fun missing that | |
| 07:55:04 | bauzas | what could be fun would be the miss the registration | |
| 07:55:10 | bauzas | be to miss* | |
| 07:59:50 | songwenping_ | bauzas: morning, i have two gpus virtualized on my env, and i config one pci address for the vgpu device_addresses, but nova report all gpus to placement, is this a bug? | |
| 08:00:14 | bauzas | songwenping_: could you provide me the conf ? | |
| 08:00:24 | bauzas | songwenping_: I think it's because you only have one type | |
| 08:00:36 | bauzas | you need to create a fake second type | |
| 08:00:37 | songwenping_ | yes, only one type. | |
| 08:00:43 | bauzas | yeah, I know, it's bad | |
| 08:01:05 | bauzas | do something like enabled_vgpu_types = nvidia-XXX, foo | |
| 08:01:17 | bauzas | and create a fake section [vgpu_foo] | |
| 08:01:20 | bauzas | with a fake device | |
| 08:01:41 | bauzas | that's because we don't look at the vgpu sections if we only have one type | |
| 08:01:55 | bauzas | for supporting the previous releases | |
| 08:02:14 | songwenping_ | yes, i looked into the code. | |
| 08:02:38 | songwenping_ | if the lenth of supported type is 1, it returns the type. | |
| 08:04:27 | bauzas | yup | |
| 08:05:54 | songwenping_ | will we change this logic? | |
| 08:10:37 | bauzas | songwenping_: we could remove the compatibility and just look whether we have a specific section | |
| 08:11:06 | bauzas | actually, this would continue to support the compatibility | |
| 08:11:33 | bauzas | songwenping_: if you want, create a new bug report and if you want, you could provide a new change that I'd review | |
| 08:11:45 | bauzas | it's simple, that's only done in a methond | |
| 08:11:47 | bauzas | method* | |
| 08:12:52 | songwenping_ | bauzas: ok, i will report a new bug and fix it. | |
| 08:13:04 | bauzas | songwenping_: lovely, thanks ! | |
| 08:13:29 | songwenping_ | cool | |
| 08:39:31 | gibi | melwitt, bauzas: the placement release notes now published properly https://docs.openstack.org/releasenotes/placement/xena.html | |
| 08:39:41 | bauzas | naïce | |
| 08:39:50 | gibi | you have strange letters :) | |
| 08:40:40 | bauzas | ... tells someone speaking Hungarian :p | |
| 08:40:53 | gibi | those are not strange :D | |
| 08:40:56 | gibi | to me :D | |
| 08:41:16 | gibi | áÁ-éÉ-íÍ-óÓ-öÖ-őŐ-úÚ-üÜ-űŰ | |
| 08:41:43 | bauzas | heh | |
| 08:41:59 | bauzas | actually, naïce is a French pun | |
| 08:42:23 | bauzas | this is because naice would mean "ai" == "è" (like heh) | |
| 08:42:43 | bauzas | instead, aï mean "ah-ee" | |