| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-09-13 | |||
| 17:42:46 | dansmith | oh, "once rc1 is out" yeah | |
| 17:42:47 | sean-k-mooney | yep | |
| 17:42:57 | sean-k-mooney | so from friday or next week | |
| 17:43:03 | sean-k-mooney | we can trun it back on on master | |
| 17:43:08 | sean-k-mooney | and pin to yoga | |
| 17:43:12 | sean-k-mooney | as teh from branch | |
| 17:43:24 | sean-k-mooney | its currently wallaby | |
| 17:43:38 | sean-k-mooney | for xena | |
| 17:43:49 | sean-k-mooney | sorry for yoga | |
| 17:44:10 | sean-k-mooney | letters are hard hehe | |
| 17:44:20 | dansmith | yeah | |
| 18:27:42 | opendevreview | Merged openstack/python-novaclient master: Update master for stable/zed https://review.opendev.org/c/openstack/python-novaclient/+/856790 | |
| #openstack-nova - 2022-09-14 | |||
| 07:38:47 | obre | Hi all! I wonder if it is possible for me to propse a small change to nova? In short I would like to add a config-option allowing us to specify the value nova-compute reports to placement for VCPU:max_unit. The use-case is to avoid having instances consuming all CPU's of a compute-node (ex: I do not want instances using 24 cores to end up on my hypervisor with 24 cores; Id | |
| 07:38:50 | obre | rather want them on larger hypervisors). Does it make sense? | |
| 07:40:13 | obre | I am able to write the changes needed in nova/virt/libvirt/driver.py and nova/conf/compute.py, I just wonder if this is something that makes sense for me to try push upstream; or if there are obvious blockers I dont see? | |
| 07:40:56 | gibi | obre: I'm wondering. it might be already possible with a provider.yaml file https://docs.openstack.org/nova/latest/admin/managing-resource-providers.html | |
| 07:41:16 | gibi | but if not, then I would enhance that facility to configure max_unit | |
| 07:41:21 | obre | gibi: Only for resources named CUSTOM_* | |
| 07:41:28 | obre | gibi: AFAIK | |
| 07:41:50 | gibi | could be. so I would suggest to extend that for non CUSTOM_ resources too | |
| 07:42:21 | gibi | so if somebody wants to do the max_unit on memory tomorrow then we have a generic solution | |
| 07:43:21 | obre | I think the reason for only allowing CUSTOM is to avoid having conflicts within nova; as nova already reports values for VCPU, MEMORY_MB and DISK_GB in its virt drivers. | |
| 07:44:28 | obre | So I guess that if we extend the provider.yaml to also allow setting these we need to do major work to ensure that it does not create conflicts? | |
| 07:45:13 | obre | Thats why I am basicly thinking that something similar to reserved_host_memory_mb, reserved_host_cpus and reserved_host_disk_mb is tempting for min/max_unit for these values. | |
| 07:47:55 | opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (db) https://review.opendev.org/c/openstack/nova/+/831193 | |
| 07:47:56 | opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (manila abstraction) https://review.opendev.org/c/openstack/nova/+/831194 | |
| 07:47:56 | opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (objects) https://review.opendev.org/c/openstack/nova/+/839401 | |
| 07:47:57 | opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (api) https://review.opendev.org/c/openstack/nova/+/836830 | |
| 07:47:57 | opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (drivers and compute manager part) https://review.opendev.org/c/openstack/nova/+/833090 | |
| 07:47:58 | opendevreview | ribaudr proposed openstack/nova master: Add metadata for shares https://review.opendev.org/c/openstack/nova/+/850500 | |
| 07:47:58 | opendevreview | ribaudr proposed openstack/nova master: Bump compute version and check shares support https://review.opendev.org/c/openstack/nova/+/850499 | |
| 07:47:59 | opendevreview | ribaudr proposed openstack/nova master: Add instance.share_attach notification https://review.opendev.org/c/openstack/nova/+/850501 | |
| 07:48:00 | opendevreview | ribaudr proposed openstack/nova master: Add shares to InstancePayload https://review.opendev.org/c/openstack/nova/+/851029 | |
| 07:48:00 | opendevreview | ribaudr proposed openstack/nova master: Add instance.share_detach notification https://review.opendev.org/c/openstack/nova/+/851028 | |
| 07:48:02 | opendevreview | ribaudr proposed openstack/nova master: Add instance.power_off_error notification https://review.opendev.org/c/openstack/nova/+/852278 | |
| 07:48:02 | opendevreview | ribaudr proposed openstack/nova master: Add instance.power_on_error notification https://review.opendev.org/c/openstack/nova/+/852084 | |
| 07:48:04 | opendevreview | ribaudr proposed openstack/nova master: Add libvirt test to ensure metadata are working. https://review.opendev.org/c/openstack/nova/+/852086 | |
| 07:48:04 | opendevreview | ribaudr proposed openstack/nova master: Add helper methods to attach/detach shares https://review.opendev.org/c/openstack/nova/+/852085 | |
| 07:48:06 | opendevreview | ribaudr proposed openstack/nova master: Add share_info parameter to reboot method for each driver (driver part) https://review.opendev.org/c/openstack/nova/+/854823 | |
| 07:48:06 | opendevreview | ribaudr proposed openstack/nova master: Add virt/libvirt error test cases https://review.opendev.org/c/openstack/nova/+/852087 | |
| 07:48:08 | opendevreview | ribaudr proposed openstack/nova master: Change microversion to 2.94 https://review.opendev.org/c/openstack/nova/+/852088 | |
| 07:48:08 | opendevreview | ribaudr proposed openstack/nova master: Support rebooting an instance with shares (compute and API part) https://review.opendev.org/c/openstack/nova/+/854824 | |
| 08:16:16 | obre | gibi: I am unable to find the real reason to only allow specifying CUSTOM inventories/traits through provider.yaml, but I guess there is a reason for this limitation? And that you not really want me to create a patch simply removing the check that traits/inventories specified in provider.yaml starts with "CUSTOM_"? | |
| 08:17:03 | gibi | obre: good point about the possible conflict. | |
| 08:17:24 | gibi | obre: I think max_unit will not be a conflict as nova never specify that other than 1 | |
| 08:18:10 | gibi | obre: as of why we have the limitation today, I think we wanted to avoid thinking through all the possible conflict scenarios when we first introduced the provider.yaml to limit the scope of that first step. | |
| 08:19:07 | gibi | obre: I agree that defining VCPU.total via provider.yaml needs thinking and some agreement what does that mean, which input has higher priority the virt driver or the provider.yaml one | |
| 08:19:29 | gibi | but I don't think you need VCPU.total you only need RC.max_unit to be allowed for your use case | |
| 08:20:56 | obre | Yes; it is basiclu max_unit which is relevant; but the driver sets that to the same value as "total" quite explicitly: | |
| 08:22:20 | obre | https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L8797-L8804 | |
| 08:23:56 | obre | And since we have the CONF.reserved_host_cpus, it seemed like a similar solution for max_unit (and even min_unit) would make sense, and be consistent with something that already exists. | |
| 08:50:08 | opendevreview | Amit Uniyal proposed openstack/nova master: Adds check if blk_dev_info has correct flavor.swap https://review.opendev.org/c/openstack/nova/+/857339 | |
| 09:05:21 | gibi | obre: I'm not saying having a dedicated CONF is not a valid alternative. I think both direction worth thinking. | |
| 09:05:43 | gibi | obre: there are couple of ways to get a bit wider input for the ideas | |
| 09:07:09 | gibi | i) try to put it on the agenda of the next nova meeting https://wiki.openstack.org/wiki/Meetings/Nova 2) try to file a blueprint and a spec describing the alternatives https://specs.openstack.org/openstack/nova-specs/#process 3) raise this as a Project Team Gathering topic in https://etherpad.opendev.org/p/nova-antelope-ptg | |
| 09:12:20 | auniyal_ | O/ | |
| 09:12:29 | opendevreview | Eigil Obrestad proposed openstack/nova master: Config parameters for min/max cpu/memory allocation. https://review.opendev.org/c/openstack/nova/+/857595 | |
| 09:12:30 | auniyal_ | please review this -https://review.opendev.org/c/openstack/nova/+/852737 | |
| 09:13:14 | auniyal_ | https://review.opendev.org/c/openstack/nova/+/857339 | |
| 09:14:54 | obre | gibi: I submitted a change to illustrate what I consider to be the simplest solution. Ill have a look at your three alternatives in a little while. First I need to eat and do a little bit of other work. | |
| 09:15:23 | gibi | obre: sure :) | |
| 09:25:54 | opendevreview | Ghanshyam proposed openstack/osc-placement master: Switch to 2023.1 Python3 unit tests and generic template name https://review.opendev.org/c/openstack/osc-placement/+/856787 | |
| 09:28:53 | opendevreview | Ghanshyam proposed openstack/os-vif master: Switch to 2023.1 Python3 unit tests and generic template name https://review.opendev.org/c/openstack/os-vif/+/856783 | |
| 09:29:18 | opendevreview | Ghanshyam proposed openstack/python-novaclient master: Switch to 2023.1 Python3 unit tests and generic template name https://review.opendev.org/c/openstack/python-novaclient/+/856791 | |
| 10:15:22 | obre | gibi: To "try to put it on the agenda of the next nova meeting"; is that simply updating the agenda on the wikipage? | |
| 10:15:57 | gibi | obre: there is an #topic Open discussion and under that you can add your topic | |
| 11:32:04 | opendevreview | Takashi Natsume proposed openstack/nova master: Update min supported service version for Zed https://review.opendev.org/c/openstack/nova/+/856895 | |
| 11:32:51 | sean-k-mooney | bauzas: gibi can we land this before RC1 https://review.opendev.org/c/openstack/nova/+/831844 | |
| 11:33:15 | sean-k-mooney | its addign the centos 9 fips job to the weekly periodic | |
| 11:33:24 | sean-k-mooney | pipelien and experimental | |
| 11:33:42 | sean-k-mooney | its finally passing again so it woudl be nice to include that so it can run on stable | |
| 11:34:10 | sean-k-mooney | without having to backport it explcitly to stable when the branch is cut | |
| 11:34:30 | sean-k-mooney | gmann:^ you have reviewd that before | |
| 11:36:48 | gmann | sean-k-mooney: +W | |
| 11:37:00 | sean-k-mooney | gmann++ many thanks | |
| 11:37:51 | sean-k-mooney | gmann: did you see my question here https://review.opendev.org/c/openstack/os-vif/+/856783/2#message-3aaeaa39501922e15ae5bfebb78fdf8e5c4c262c | |
| 11:38:38 | sean-k-mooney | are we goign to branch the openstack-python3-jobs via job vairiant | |
| 11:38:53 | sean-k-mooney | to make sure that the jobs in that template do not change on stable branches | |
| 11:41:19 | gmann | sean-k-mooney: yes, replied, like this we can do - https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/856903/2/zuul.d/project-templates.yaml#1600 | |
| 11:41:41 | gmann | we will pin the changed job for stable and master once new release and change in python version jobs | |
| 11:44:22 | sean-k-mooney | ack thats all i needed to know. i assuemd ye would use job variant and the branches key | |
| 11:46:33 | sean-k-mooney | gmann: so with this change if we do it on nova and all the other compute deliverable we never need to review/merge these defualt job template paches again right :) | |
| 11:46:57 | sean-k-mooney | its just the central review going forward for the job variant | |
| 11:55:35 | gmann | sean-k-mooney: right. we do not need to update template name in nova side | |
| 11:56:10 | sean-k-mooney | that will be nice | |
| 11:56:26 | sean-k-mooney | its not like this takes much time but less manual stuff every release it a good thing | |
| 13:09:31 | bauzas | cores, can we please review https://review.opendev.org/c/openstack/nova/+/857467 (prelude) | |
| 13:09:37 | bauzas | this becomes critical | |
| 13:09:46 | bauzas | sean-k-mooney: gibi: others | |
| 13:09:53 | sean-k-mooney | oh the prelude | |
| 13:09:57 | sean-k-mooney | sure ill do it now | |
| 13:10:08 | bauzas | gracias and danke | |
| 13:10:15 | sean-k-mooney | i tought we had already merge that but it was the release highlights i was thinking of | |
| 13:10:31 | sean-k-mooney | for marketing | |
| 13:10:59 | bauzas | correct | |
| 13:11:18 | bauzas | cycle highlights go to some other website | |
| 13:11:37 | bauzas | here, the prelude is just for ops not wanting to read the long list of things we have in the relnotes | |
| 13:11:41 | sean-k-mooney | -1 i think you ment zed https://review.opendev.org/c/openstack/nova/+/857467/1/releasenotes/notes/zed-prelude-a3cddb8b2ac8e293.yaml | |
| 13:12:08 | sean-k-mooney | otherwise i think it looks ok to me | |
| 13:13:04 | sean-k-mooney | if you fix that im +1 | |