| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-09-13 | |||
| 17:08:22 | sean-k-mooney | so that is why a mager change broke stable | |
| 17:08:24 | elodilles | sean-k-mooney: sorry :S now i get it o:) | |
| 17:11:58 | sean-k-mooney | so we might want to drop https://review.opendev.org/c/openstack/openstacksdk/+/857471/1/openstack/block_storage/v3/_proxy.py but https://review.opendev.org/c/openstack/openstacksdk/+/857471/1/openstack/tests/functional/cloud/test_project_cleanup.py is the flaky test that we should revert out | |
| 17:12:16 | sean-k-mooney | ill do that and rebase it to the tip of master | |
| 17:14:52 | elodilles | sean-k-mooney: thanks! | |
| 17:20:07 | sean-k-mooney | https://review.opendev.org/c/openstack/openstacksdk/+/857471 | |
| 17:20:15 | sean-k-mooney | ok so that is just removing the test cases now | |
| 17:20:45 | sean-k-mooney | the retry they added is preserved to not regress https://storyboard.openstack.org/#!/story/2010217 | |
| 17:23:10 | elodilles | sean-k-mooney: ++ | |
| 17:30:24 | sean-k-mooney | bauzas: by the way while im going to attent the ptg i dont plan on addign any topics this time to the adgenda | |
| 17:32:38 | sean-k-mooney | dansmith: by the way does your n-2 greade job still work | |
| 17:33:13 | sean-k-mooney | if so we should likely add that to the check pipline or the perodic pipelien one RC1 is out using yoga as a base | |
| 17:33:43 | sean-k-mooney | so weekly at a minium but we could run it on each patch if we wanted too | |
| 17:34:09 | sean-k-mooney | thats proably a ptg topic i guess | |
| 17:34:55 | sean-k-mooney | i.e. how and what level of testing we wil do in A as part of the dress rehersal for C | |
| 17:36:08 | sean-k-mooney | is it the grenade-skip-level: jobs | |
| 17:36:17 | sean-k-mooney | https://github.com/openstack/nova/blob/master/.zuul.yaml#L705-L706 | |
| 17:37:38 | sean-k-mooney | ya it is https://opendev.org/openstack/grenade/src/branch/master/.zuul.yaml#L377 | |
| 17:38:19 | sean-k-mooney | so we wil need a variant for tha tthat is based on yoga as the base and master as the target for A | |
| 17:38:42 | sean-k-mooney | its proably best to do that in hte grenade repo | |
| 17:42:20 | dansmith | sean-k-mooney: we won't know until we start running it again, but it's supposed to | |
| 17:42:38 | dansmith | but we shouldn't be running it on zed-rc right? just on master (antelope) right? | |
| 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 (objects) https://review.opendev.org/c/openstack/nova/+/839401 | |
| 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: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:57 | opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (api) https://review.opendev.org/c/openstack/nova/+/836830 | |
| 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:58 | opendevreview | ribaudr proposed openstack/nova master: Add metadata for shares https://review.opendev.org/c/openstack/nova/+/850500 | |
| 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 instance.share_detach notification https://review.opendev.org/c/openstack/nova/+/851028 | |
| 07:48:00 | opendevreview | ribaudr proposed openstack/nova master: Add shares to InstancePayload https://review.opendev.org/c/openstack/nova/+/851029 | |
| 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:02 | opendevreview | ribaudr proposed openstack/nova master: Add instance.power_off_error notification https://review.opendev.org/c/openstack/nova/+/852278 | |
| 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: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:06 | opendevreview | ribaudr proposed openstack/nova master: Add virt/libvirt error test cases https://review.opendev.org/c/openstack/nova/+/852087 | |
| 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: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 | |
| 07:48:08 | opendevreview | ribaudr proposed openstack/nova master: Change microversion to 2.94 https://review.opendev.org/c/openstack/nova/+/852088 | |
| 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 | |