| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-01-09 | |||
| 17:22:41 | sean-k-mooney | so the default will still be None meaning the virt driver chooses | |
| 17:23:21 | sean-k-mooney | bauzas: on a related note i want to remove some config options that should have been removed a long time ago but i need to deprecate them first. | |
| 17:24:02 | sean-k-mooney | obviously we need to agree to do that but is that something yoru happy to agree on via gerrirt or do you want me to file something | |
| 17:24:48 | sean-k-mooney | i want to for https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.vif_plugging_is_fatal to be true and remove it as an option or at least move it to workarounds | |
| 17:25:25 | sean-k-mooney | you shoudl not run with vif_plugging_is_fatal=false in production | |
| 17:25:28 | sean-k-mooney | ever | |
| 17:25:58 | sean-k-mooney | so i want to deprecate that in this release and then condier removing it next cycle | |
| 17:26:42 | opendevreview | Amit Uniyal proposed openstack/nova master: Refactor vf profile for PCI device https://review.opendev.org/c/openstack/nova/+/905134 | |
| 17:35:55 | opendevreview | Amit Uniyal proposed openstack/nova master: Refactor vf profile for PCI device https://review.opendev.org/c/openstack/nova/+/905134 | |
| 18:40:36 | opendevreview | Merged openstack/nova stable/xena: Avoid n-cond startup abort for keystone failures https://review.opendev.org/c/openstack/nova/+/859000 | |
| 19:04:04 | sean-k-mooney | bauzas: can you review this spec tomorrow its trivial but required as its an api change https://review.opendev.org/c/openstack/nova-specs/+/904368 | |
| 20:38:02 | opendevreview | Merged openstack/nova stable/zed: Fix rebuild compute RPC API exception for rolling-upgrades https://review.opendev.org/c/openstack/nova/+/900341 | |
| #openstack-nova - 2024-01-10 | |||
| 02:26:54 | opendevreview | melanie witt proposed openstack/nova master: Enable use of native threads in scatter_gather_cells https://review.opendev.org/c/openstack/nova/+/650172 | |
| 02:42:36 | opendevreview | melanie witt proposed openstack/nova master: libvirt: Introduce support for rbd with LUKS https://review.opendev.org/c/openstack/nova/+/889912 | |
| 03:35:11 | opendevreview | melanie witt proposed openstack/nova master: Enable use of native threads in scatter_gather_cells https://review.opendev.org/c/openstack/nova/+/650172 | |
| 05:00:59 | opendevreview | melanie witt proposed openstack/nova master: libvirt: Introduce support for raw with LUKS https://review.opendev.org/c/openstack/nova/+/884313 | |
| 05:01:00 | opendevreview | melanie witt proposed openstack/nova master: libvirt: Introduce support for rbd with LUKS https://review.opendev.org/c/openstack/nova/+/889912 | |
| 05:57:12 | songwenping_ | stephenfin: this patch https://review.opendev.org/c/openstack/openstacksdk/+/883238 pep8 check passed on my env,but online is always failed, pls help to review, tks. | |
| 06:30:23 | frickler | songwenping_: commented on the review | |
| 07:14:45 | elodilles | bauzas: i've updated the Zed stable release patch as the long waited patch has merged \o/ (i think the PATCH version bump is still enough here, but correct me if i'm wrong): https://review.opendev.org/c/openstack/releases/+/899604/3 | |
| 08:02:35 | dvo-plv | Hello, All | |
| 08:02:45 | dvo-plv | I have a question regarding our spec-file. https://review.opendev.org/c/openstack/nova-specs/+/859290 | |
| 08:03:31 | dvo-plv | it was already merge, but when we've started to implement this solution, we faced with some concerns from the core dev side | |
| 08:04:14 | dvo-plv | We would like to suggest new approach what should be mentioned in the spec file, how I should do it properly ? | |
| 08:57:41 | opendevreview | Vasyl Saienko proposed openstack/nova master: Fix returning empty availability zone https://review.opendev.org/c/openstack/nova/+/902875 | |
| 09:10:45 | songwenping__ | frickler: thanks, the extra line issue. | |
| 09:18:02 | opendevreview | Yalei Li proposed openstack/nova master: Implement get_power_state using domain.state https://review.opendev.org/c/openstack/nova/+/904970 | |
| 12:03:15 | opendevreview | Pavlo Shchelokovskyy proposed openstack/nova master: Ignore group_policy extra spec in aggregate filter https://review.opendev.org/c/openstack/nova/+/905210 | |
| 12:19:48 | sean-k-mooney | noonedeadpunk: are you planning to work on https://review.opendev.org/c/openstack/nova-specs/+/900296/3/specs/2024.1/approved/cross-az-instance-scheduling.rst this cycle? | |
| 12:19:57 | sean-k-mooney | the spec approval deadline is tomorrow | |
| 12:31:51 | noonedeadpunk | sean-k-mooney: ah, sorry, I compleltely missed your comment | |
| 12:32:14 | sean-k-mooney | the ones i litrally just left :) | |
| 12:32:42 | sean-k-mooney | once you fix the pep8 issue im +2 on your spec if you still intent to implement it this cycle | |
| 12:32:52 | sean-k-mooney | otherwise we shoudl propsoe it for next cycle | |
| 12:35:32 | noonedeadpunk | regarding tests, I think I was more thinking of real tempest tests, meaning them as "functional" | |
| 12:35:47 | noonedeadpunk | and rest are "unit" kinda | |
| 12:37:34 | sean-k-mooney | not form our perpseictive | |
| 12:37:40 | sean-k-mooney | unit test test function in isolation | |
| 12:37:44 | noonedeadpunk | yeah, I got that from your comment | |
| 12:37:53 | sean-k-mooney | functional tests test how subsystems or services in isolation | |
| 12:38:07 | sean-k-mooney | and then tempest are consider integration tests where we are testing multiple services togeter | |
| 12:38:33 | noonedeadpunk | yeah, sorry for mixing terminology here | |
| 12:38:38 | sean-k-mooney | no worries | |
| 12:38:49 | noonedeadpunk | will edit spec corresponsively | |
| 12:39:10 | sean-k-mooney | gibi is unfortunetly on pto until monday so wont be around beofre spec freeze | |
| 12:39:30 | sean-k-mooney | bauzas: ^ can you review noonedeadpunk spec when the next version is proposed and be the second +2 | |
| 12:39:58 | sean-k-mooney | bauzas: its what we disucssed at the ptg regarding the az affinity/anti affinity filter enhancements | |
| 12:40:53 | sean-k-mooney | like rajesh's spec for showing the requested az in the server show its small and i dont think contovitiol any more | |
| 12:41:03 | sean-k-mooney | so it shoudl not take long to reivew | |
| 12:46:33 | opendevreview | Dmitriy Rabotyagov proposed openstack/nova-specs master: [spec] Add Cross-AZ scheduling blueprint https://review.opendev.org/c/openstack/nova-specs/+/900296 | |
| 12:46:38 | noonedeadpunk | here we go ^ | |
| 12:49:11 | sean-k-mooney | +2 | |
| 12:49:12 | sean-k-mooney | thanks | |
| 12:49:22 | sean-k-mooney | have you started on the implementaion | |
| 12:50:20 | sean-k-mooney | can you use the cross-az-instance-scheduling gerrit topic when working on that | |
| 12:50:30 | sean-k-mooney | to keep the spec and code all on the same topic | |
| 12:51:48 | noonedeadpunk | I have not yet (as was not sure if lueprint will land or not, and that was kinda requirement from here to start working on it) | |
| 12:52:05 | noonedeadpunk | and yes, sure I can use the topic you've mentioned | |
| 13:32:41 | bauzas | sean-k-mooney: yeah today I'm looking at specs | |
| 13:39:43 | dvo-plv | sean-k-mooney, Hello | |
| 13:44:03 | sean-k-mooney | dvo-plv: o/ | |
| 13:44:11 | dvo-plv | I asked a question above regarding correct appropriate with spec file changes, when it was merged | |
| 13:44:20 | dvo-plv | Could you pelase advice me something | |
| 13:47:05 | sean-k-mooney | sorry i didnt see that question can you restate it | |
| 13:47:19 | sean-k-mooney | are you asking when is it ok to update a merges spec | |
| 13:47:32 | sean-k-mooney | to reflect change based on the review of the code | |
| 13:48:15 | sean-k-mooney | if so, while we avoid chanign things during review in general we allwo reconsiling the spec based on those changes at any time | |
| 13:48:54 | sean-k-mooney | we would prefer the spec to be correct since it is use as documetation by both us and operator so you can propose a patch to the spec repo to fix a spec even after spec freeze | |
| 14:04:36 | bauzas | sean-k-mooney: fwiw, even if I agree with the usecase (listing the pinned AZ), I -1d https://review.opendev.org/c/openstack/nova-specs/+/904368 because of the difference between 'I requested a AZ' and 'my instance is pinned' | |
| 14:06:13 | bauzas | ratailor: ^ see my comment above ^ | |
| 14:25:38 | sean-k-mooney | bauzas: responed | |
| 14:25:49 | sean-k-mooney | your not wrong altough i dont entirly agree with all your coments | |
| 14:26:23 | sean-k-mooney | i would not be opposed to the spec if your comment were adressed however | |
| 14:26:54 | sean-k-mooney | you and i are readign requested to have 2 diffent meanings | |
| 14:27:15 | sean-k-mooney | for me an az is requested if the az filed in the request_spec is populated for any reason | |
| 14:27:26 | sean-k-mooney | for you its requested only if it was in the http post | |
| 14:27:43 | sean-k-mooney | thats disconnect between my reading and your reading of the spec | |
| 14:28:33 | noonedeadpunk | I'd actually vote for taking AZ from request_spec regardless of how it's appeared there | |
| 14:28:36 | sean-k-mooney | im ok with using your interperation and updating the spec to reflect that but form the persptice of the schduelr its requested if there is a value in the request spec | |
| 14:28:54 | bauzas | sean-k-mooney: I provided an alternative name for the API field | |
| 14:29:02 | noonedeadpunk | As actually I assume that what matters at the end... | |
| 14:29:05 | bauzas | 'attached_availability_zone' | |
| 14:29:17 | sean-k-mooney | i dont like attached | |
| 14:29:34 | sean-k-mooney | you also sugggested pinned_availablity_zone | |
| 14:29:39 | bauzas | we already have 'cross_az_attach' option, hence my name | |
| 14:29:52 | sean-k-mooney | attach in that context is refering to the volume not the az | |
| 14:30:02 | bauzas | possibly yeah | |
| 14:30:24 | sean-k-mooney | so pinned_aviableity_zone or required_avilablity_zone are all fine | |
| 14:30:31 | bauzas | the fact is that I want my user to understand that the instance is only using this AZ without looking at the api docs | |
| 14:30:50 | sean-k-mooney | noonedeadpunk: form an operator perspective what would you find more intuitive | |
| 14:30:51 | bauzas | I'm not fine with 'requested_az' for the reason I explained | |
| 14:31:17 | sean-k-mooney | right but i actully think that is the most correct form for the reasons i explaied :) | |
| 14:31:27 | bauzas | the fact that neither the operator nor the user could request this instance to be pinned while the instance would still be pinned | |
| 14:31:31 | sean-k-mooney | but i dont really care too much what the field name is | |
| 14:31:47 | sean-k-mooney | bauzas: right but its part of the requst_spec | |
| 14:31:58 | sean-k-mooney | there for the az was requested | |
| 14:32:04 | sean-k-mooney | it does not makter who requeteded it | |
| 14:32:12 | bauzas | sean-k-mooney: well, some enduser doesn't know the internals | |
| 14:32:28 | sean-k-mooney | yep which is why im interested in noonedeadpunk input | |
| 14:32:35 | sean-k-mooney | im fine with using a diffent name | |