| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-05-02 | |||
| 16:59:39 | enriquetaso | bauzas, do you a have a doc? :P | |
| 16:59:55 | bauzas | enriquetaso: I can provide you pointers and more than that : guidance | |
| 17:00:11 | enriquetaso | sure bauzas | |
| 17:00:19 | bauzas | #agreed enriquetaso to provide a spec for this feature | |
| 17:00:33 | bauzas | #action bauzas to provide enriquetaso details on the spec process | |
| 17:00:40 | bauzas | we're on time | |
| 17:00:45 | bauzas | the agenda is done | |
| 17:00:56 | bauzas | so thanks all and see you next week | |
| 17:01:01 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2023/nova.2023-05-02-16.00.log.html | |
| 17:01:01 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2023/nova.2023-05-02-16.00.txt | |
| 17:01:01 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2023/nova.2023-05-02-16.00.html | |
| 17:01:01 | opendevmeet | Meeting ended Tue May 2 17:01:01 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 17:01:01 | bauzas | #endmeeting | |
| 17:01:06 | elodilles | thanks o/ | |
| 17:01:07 | enriquetaso | thansk!! | |
| 17:01:09 | bauzas | enriquetaso: gimme a sec | |
| 17:01:16 | enriquetaso | sure bauzas | |
| 17:01:42 | bauzas | enriquetaso: so the spec process is quite simple : it's a doc | |
| 17:01:52 | bauzas | enriquetaso: we have a template you can reuse https://specs.openstack.org/openstack/nova-specs/specs/2023.2/approved/2023.2-template.html | |
| 17:02:41 | enriquetaso | looks good | |
| 17:02:45 | bauzas | enriquetaso: what you have to do is to write your own rst file based on that template and propose it for the approved/ directory | |
| 17:02:47 | bauzas | like https://review.opendev.org/q/project:openstack/nova-specs+is:open | |
| 17:03:07 | enriquetaso | bauzas, do you remember when is the spec freeze? | |
| 17:03:25 | sean-k-mooney | its milestone 2 | |
| 17:03:38 | sean-k-mooney | so after the physical ptg at the end of july | |
| 17:03:51 | bauzas | enriquetaso: sure, look https://releases.openstack.org/bobcat/schedule.html#b-nova-spec-review-day | |
| 17:04:06 | sean-k-mooney | july 6th actullly so start of july | |
| 17:04:06 | bauzas | damn | |
| 17:04:20 | sean-k-mooney | https://releases.openstack.org/bobcat/schedule.html#b-nova-spec-freeze | |
| 17:04:32 | bauzas | yup, my link was wrong | |
| 17:05:17 | bauzas | enriquetaso: honestly, as you understood, most of the review process on that file will consist on us to agree on the upgrade concerns | |
| 17:05:37 | bauzas | which are not only the rolling upgrade concerns but also the fact that we need a recent libvirt | |
| 17:05:55 | bauzas | enriquetaso: you know our minimum libvirt versions we support, right? | |
| 17:06:21 | enriquetaso | sorry | |
| 17:06:25 | enriquetaso | it desconnect | |
| 17:06:27 | enriquetaso | i'm back | |
| 17:06:37 | bauzas | enriquetaso: no worries | |
| 17:06:48 | enriquetaso | but I think I have all the info i need sean-k-mooney bauzas | |
| 17:06:53 | bauzas | I was mentioning that most of the spec review will be about the upgrade concerns | |
| 17:07:06 | bauzas | enriquetaso: our current minimums for libvirt are https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L219-L222 | |
| 17:07:21 | bauzas | sean-k-mooney: have you already proposed the libvirt min bump ? | |
| 17:08:42 | sean-k-mooney | no i asked kashyap to do that | |
| 17:08:53 | sean-k-mooney | i dont think they have had time to propose any patches | |
| 17:09:34 | kashyap | sean-k-mooney: Yes; it's on my list for this week | |
| 17:09:39 | bauzas | ack | |
| 17:09:45 | sean-k-mooney | if our currnt mins are enough this is simple as its just a min comptue service bump. if we have a min os-brick we can do that by raising or min os-brick | |
| 17:09:46 | kashyap | Right now I'm chasing down the kernel crash Dan pointed out earlier | |
| 17:10:19 | dansmith | can't do the min bump until I finish the ceph job stuff I think | |
| 17:10:50 | sean-k-mooney | it might be possibel but im ok waiting to m2 i guess | |
| 17:10:57 | sean-k-mooney | i would have preferd to do it at m1 | |
| 17:11:07 | sean-k-mooney | but i think ceph is a higher piority | |
| 17:12:27 | bauzas | I was under the impression that the nfs encryption was requiring a recent libvirt version but I could be wrong and mixing two things | |
| 17:15:26 | enriquetaso | mmmh, I'm not sure | |
| 17:15:51 | sean-k-mooney | i donthing think libvirt matters | |
| 17:15:59 | sean-k-mooney | but qemu-img might | |
| 17:16:03 | sean-k-mooney | and qemu | |
| 17:17:35 | enriquetaso | I can check and add this information on the spec if the feature need a min version of libvirt or qemu | |
| 17:18:55 | enriquetaso | okay, I'm going to disconnect now | |
| 17:19:01 | enriquetaso | thank you so much again | |
| #openstack-nova - 2023-05-03 | |||
| 07:52:51 | opendevreview | Amit Uniyal proposed openstack/nova master: Allow swap resize from non-zero to zero https://review.opendev.org/c/openstack/nova/+/857339 | |
| 08:09:14 | dvo-plv_ | Hello, All Could you pelase help me with file naming | |
| 08:09:37 | dvo-plv_ | opt/stack/glance/releasenotes/notes/zed-milestone-3-3e38697ae4677a81.yaml where should I get hash ( zed-milestone-....yaml) in this file ? | |
| 08:31:22 | sean-k-mooney | its auto geneerated using a tool | |
| 08:31:48 | sean-k-mooney | tox -e venv reno new zed-milestone-3 | |
| 08:32:16 | sean-k-mooney | reno is the tool we use to create releasenotes | |
| 08:32:31 | sean-k-mooney | dvo-plv_:^ | |
| 08:37:30 | dvo-plv_ | thank you | |
| 11:33:03 | opendevreview | Danylo Vodopianov proposed openstack/nova master: Packed virtqueue support was added. https://review.opendev.org/c/openstack/nova/+/876075 | |
| 11:53:15 | opendevreview | Amit Uniyal proposed openstack/nova stable/wallaby: fup: Print message logging uncaught nova-manage exceptions https://review.opendev.org/c/openstack/nova/+/877334 | |
| 11:54:10 | opendevreview | Danylo Vodopianov proposed openstack/nova-specs master: VirtIO PackedRing Configuration support https://review.opendev.org/c/openstack/nova-specs/+/868377 | |
| 12:15:15 | dvo-plv_ | gibi: I have resolved your comment at this bp https://review.opendev.org/c/openstack/nova-specs/+/868377 | |
| 12:18:18 | gibi | dvo-plv_: look good to me | |
| 12:23:14 | opendevreview | Danylo Vodopianov proposed openstack/nova-specs master: VirtIO PackedRing Configuration support https://review.opendev.org/c/openstack/nova-specs/+/868377 | |
| 12:38:29 | dvo-plv_ | I fixed pep8 validation. Should I do something more for further bp activities? | |
| 12:38:54 | sean-k-mooney | im just waitign for ci to report back im still happy with it so ill readd +2 once its green | |
| 12:39:08 | sean-k-mooney | oh its already repoted back | |
| 12:40:18 | sean-k-mooney | gibi: care to send it on its way https://review.opendev.org/c/openstack/nova-specs/+/868377 | |
| 12:43:03 | gibi | sean-k-mooney, dvo-plv_ : done | |
| 12:47:55 | dvo-plv_ | Great. So spec file is approved. Then we have to wait for code review ? https://review.opendev.org/q/topic:bp%252Fvirtio-packedring-configuration-support | |
| 12:58:51 | opendevreview | Merged openstack/nova-specs master: VirtIO PackedRing Configuration support https://review.opendev.org/c/openstack/nova-specs/+/868377 | |
| 13:05:38 | sahid | quick question regarding host aggregate and AZ | |
| 13:06:55 | sahid | we have noticed that when we add a compute host, that one is always considered in the AZ nova (the one that is by default configured in default_avalibility_zone) | |
| 13:07:29 | sahid | it seems that if we don't want this behavior to happen, we have to first add the host to the correct aggregate and then start nova-compute service | |
| 13:08:09 | sahid | the problem is that, it seems not possible to add in an aggregate a host that has not been "registered" by a service like nova-compute, right? | |
| 13:09:18 | sean-k-mooney | sahid: that not how it works | |
| 13:09:42 | sean-k-mooney | if you dont add a host to an aggreate with az metadta | |
| 13:09:43 | sahid | so during deployement of a new compute host we always have that window where the host is considered in AZ nova (this az does not exist in our deployement) until that we set the host to the correct aggregate | |
| 13:10:26 | sean-k-mooney | if you dont add a host to an aggreate with az metadta then its is considerd part of default_availability_zone | |
| 13:10:30 | sahid | (a aggregate with ZA metadata, yes) | |
| 13:10:50 | sahid | sean-k-mooney: yes we are in the same page | |
| 13:11:08 | sean-k-mooney | sahid: yes ther is no way to atomically ahve a comptue node com up and register in an az | |
| 13:11:38 | sean-k-mooney | sahid: if you want to prevent ti beign selected you can make the service register in a disabeld state | |
| 13:12:01 | sahid | i think it may be possible to achieve that if we allow to add an host that does not yet exist in a aggregate (that has az metadata), right? | |
| 13:12:13 | sahid | sean-k-mooney: ahh interesting point | |
| 13:12:43 | sahid | what do you mean by "selected"? | |
| 13:12:53 | sahid | I don't want that nova az appears | |
| 13:12:58 | sean-k-mooney | considerd as a valid host for scheduling | |
| 13:13:03 | sahid | because it's confusing for users | |
| 13:13:09 | sahid | ah... | |
| 13:13:14 | sean-k-mooney | that is not somethign you can do currently | |