| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-09-14 | |||
| 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 | |
| 13:13:13 | sean-k-mooney | or +2 i guess | |
| 13:13:56 | sean-k-mooney | also set review priorty lable on that | |
| 13:14:17 | sean-k-mooney | bauzas: you were on pto when i had this converstaion with gibi and stephenfin | |
| 13:14:31 | bauzas | sean-k-mooney: I can respin quickly | |
| 13:14:43 | sean-k-mooney | bauzas: but the tl;dr is that review priorty is a littel weird for core so i use it slightly differnt then the doc | |
| 13:15:16 | bauzas | sean-k-mooney: honestly, I was about to write a topic for the PTG agenda about the use of review-prio | |
| 13:15:18 | sean-k-mooney | bauzas: if i set +1 it means im looking at it but im not askign other cores to look at it if i set +2 it means im looking at it and would like other cores to look at it too | |
| 13:15:24 | bauzas | and how we could make this better | |
| 13:15:48 | sean-k-mooney | so im using +1 to comunicate to the author that they have my attention | |
| 13:16:04 | sean-k-mooney | and +2 to comunciate to the core team that i think its imporant for them to look at too | |
| 13:16:18 | opendevreview | Sylvain Bauza proposed openstack/nova master: Prelude section for Zed release https://review.opendev.org/c/openstack/nova/+/857467 | |
| 13:16:26 | sean-k-mooney | im not commiting them to but usign it to signal asyc that i think its more important for wider review | |
| 13:16:27 | bauzas | sean-k-mooney ack, then let's discuss this at the PTG | |
| 13:16:38 | bauzas | sean-k-mooney: gibi: updated prelude ^ | |
| 13:16:38 | sean-k-mooney | cool | |
| 13:16:51 | sean-k-mooney | im trying to decople priorty from quality | |
| 13:17:15 | sean-k-mooney | i.e. rp +2 my be with a buch of -1 but may have topic that need wider input | |
| 13:19:54 | sean-k-mooney | bauzas: when will that move to zed https://6bc7844fa7b995ed5b77-cdf523d3b16150ab0b9ddc512a79d512.ssl.cf2.rackcdn.com/857467/1/check/build-openstack-releasenotes/b8db3f7/docs/unreleased.html should that also be in the patch or is it when we cut the stable branch | |
| 13:20:21 | bauzas | sean-k-mooney: ah | |
| 13:20:24 | sean-k-mooney | stephenfin: ^ pbr has some magic based on commit messages right it it tied into that or do we need to do somethign esle | |
| 13:20:30 | bauzas | you mean when it will be told "zed" | |
| 13:20:37 | sean-k-mooney | yep | |