| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-01-10 | |||
| 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 | |
| 14:32:51 | bauzas | noonedeadpunk: tell me a better name and I +2 your own spec :p | |
| 14:32:53 | bauzas | (jk) | |
| 14:32:55 | sean-k-mooney | so if you think somethign else is better that is ok with me althoug lets avoid attach | |
| 14:33:14 | sean-k-mooney | bauzas: this is now noonedeadpunk spec | |
| 14:33:19 | sean-k-mooney | theres is the other one | |
| 14:33:22 | bauzas | sean-k-mooney: I'm quite conservative on AZs given it's an enduser param | |
| 14:33:45 | bauzas | and most OVH endusers (for example) don't know a single bit of the nova internals | |
| 14:34:07 | sean-k-mooney | well even those that do disagree on how az should be used | |
| 14:34:10 | bauzas | sean-k-mooney: yeah I know, we're speaking of ratailor's spec | |
| 14:34:18 | sean-k-mooney | i for one have no issue with explcitly requesting the nova az | |
| 14:34:31 | sean-k-mooney | i know why you dont like that | |
| 14:34:39 | sean-k-mooney | but to me that is perfectly valid | |
| 14:34:58 | sean-k-mooney | and i know of cloud that have configured default_schedule_zone=nova | |
| 14:35:15 | sean-k-mooney | thats a tangent | |
| 14:35:22 | bauzas | that's a terrible thing | |
| 14:35:32 | bauzas | and we documented that | |
| 14:35:47 | sean-k-mooney | bauzas: right but horizon default to nova and i belive it always puts it in the request | |
| 14:35:54 | bauzas | NOOOOOOOOOOOOOOOOOOOOOOOOOOO | |
| 14:36:13 | bauzas | are you joking ? | |
| 14:36:17 | sean-k-mooney | i know that horizon use to alwasy require an az in the drop down | |
| 14:36:31 | sean-k-mooney | and if nova was the only one in the list you had no other choice | |
| 14:36:34 | bauzas | that's an horizon bug then | |
| 14:36:42 | sean-k-mooney | one that has been there forever | |
| 14:36:44 | noonedeadpunk | ooopps | |
| 14:36:58 | bauzas | https://docs.openstack.org/nova/latest/admin/availability-zones.html | |
| 14:37:00 | sean-k-mooney | like litrally since i started workin on openstack 10 years ago | |
| 14:37:09 | bauzas | I wrote that in solid red | |
| 14:37:29 | sean-k-mooney | bauzas: ya i know. im just saying that what you expect and how thing are used in the wild dont actully agreee | |