| 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:26 |
|---|---|---|
| opendevreview | melanie witt proposed openstack/nova master: libvirt: Introduce support for rbd with LUKS https://review.opendev.org/c/openstack/nova/+/889912 | 02:42 |
| opendevreview | melanie witt proposed openstack/nova master: Enable use of native threads in scatter_gather_cells https://review.opendev.org/c/openstack/nova/+/650172 | 03:35 |
| opendevreview | melanie witt proposed openstack/nova master: libvirt: Introduce support for raw with LUKS https://review.opendev.org/c/openstack/nova/+/884313 | 05:00 |
| opendevreview | melanie witt proposed openstack/nova master: libvirt: Introduce support for rbd with LUKS https://review.opendev.org/c/openstack/nova/+/889912 | 05:01 |
| 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. | 05:57 |
| frickler | songwenping_: commented on the review | 06:30 |
| 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 | 07:14 |
| dvo-plv | Hello, All | 08:02 |
| dvo-plv | I have a question regarding our spec-file. https://review.opendev.org/c/openstack/nova-specs/+/859290 | 08:02 |
| 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:03 |
| dvo-plv | We would like to suggest new approach what should be mentioned in the spec file, how I should do it properly ? | 08:04 |
| opendevreview | Vasyl Saienko proposed openstack/nova master: Fix returning empty availability zone https://review.opendev.org/c/openstack/nova/+/902875 | 08:57 |
| songwenping__ | frickler: thanks, the extra line issue. | 09:10 |
| opendevreview | Yalei Li proposed openstack/nova master: Implement get_power_state using domain.state https://review.opendev.org/c/openstack/nova/+/904970 | 09:18 |
| opendevreview | Pavlo Shchelokovskyy proposed openstack/nova master: Ignore group_policy extra spec in aggregate filter https://review.opendev.org/c/openstack/nova/+/905210 | 12:03 |
| 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 |
| sean-k-mooney | the spec approval deadline is tomorrow | 12:19 |
| noonedeadpunk | sean-k-mooney: ah, sorry, I compleltely missed your comment | 12:31 |
| sean-k-mooney | the ones i litrally just left :) | 12:32 |
| 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 |
| sean-k-mooney | otherwise we shoudl propsoe it for next cycle | 12:32 |
| noonedeadpunk | regarding tests, I think I was more thinking of real tempest tests, meaning them as "functional" | 12:35 |
| noonedeadpunk | and rest are "unit" kinda | 12:35 |
| sean-k-mooney | not form our perpseictive | 12:37 |
| sean-k-mooney | unit test test function in isolation | 12:37 |
| noonedeadpunk | yeah, I got that from your comment | 12:37 |
| sean-k-mooney | functional tests test how subsystems or services in isolation | 12:37 |
| sean-k-mooney | and then tempest are consider integration tests where we are testing multiple services togeter | 12:38 |
| noonedeadpunk | yeah, sorry for mixing terminology here | 12:38 |
| sean-k-mooney | no worries | 12:38 |
| noonedeadpunk | will edit spec corresponsively | 12:38 |
| sean-k-mooney | gibi is unfortunetly on pto until monday so wont be around beofre spec freeze | 12:39 |
| sean-k-mooney | bauzas: ^ can you review noonedeadpunk spec when the next version is proposed and be the second +2 | 12:39 |
| sean-k-mooney | bauzas: its what we disucssed at the ptg regarding the az affinity/anti affinity filter enhancements | 12:39 |
| 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:40 |
| sean-k-mooney | so it shoudl not take long to reivew | 12:41 |
| 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 |
| noonedeadpunk | here we go ^ | 12:46 |
| sean-k-mooney | +2 | 12:49 |
| sean-k-mooney | thanks | 12:49 |
| sean-k-mooney | have you started on the implementaion | 12:49 |
| sean-k-mooney | can you use the cross-az-instance-scheduling gerrit topic when working on that | 12:50 |
| sean-k-mooney | to keep the spec and code all on the same topic | 12:50 |
| 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:51 |
| noonedeadpunk | and yes, sure I can use the topic you've mentioned | 12:52 |
| bauzas | sean-k-mooney: yeah today I'm looking at specs | 13:32 |
| dvo-plv | sean-k-mooney, Hello | 13:39 |
| sean-k-mooney | dvo-plv: o/ | 13:44 |
| dvo-plv | I asked a question above regarding correct appropriate with spec file changes, when it was merged | 13:44 |
| dvo-plv | Could you pelase advice me something | 13:44 |
| sean-k-mooney | sorry i didnt see that question can you restate it | 13:47 |
| sean-k-mooney | are you asking when is it ok to update a merges spec | 13:47 |
| sean-k-mooney | to reflect change based on the review of the code | 13:47 |
| 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 |
| 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 | 13:48 |
| 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:04 |
| bauzas | ratailor: ^ see my comment above ^ | 14:06 |
| sean-k-mooney | bauzas: responed | 14:25 |
| sean-k-mooney | your not wrong altough i dont entirly agree with all your coments | 14:25 |
| sean-k-mooney | i would not be opposed to the spec if your comment were adressed however | 14:26 |
| sean-k-mooney | you and i are readign requested to have 2 diffent meanings | 14:26 |
| sean-k-mooney | for me an az is requested if the az filed in the request_spec is populated for any reason | 14:27 |
| sean-k-mooney | for you its requested only if it was in the http post | 14:27 |
| sean-k-mooney | thats disconnect between my reading and your reading of the spec | 14:27 |
| noonedeadpunk | I'd actually vote for taking AZ from request_spec regardless of how it's appeared there | 14:28 |
| 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 |
| bauzas | sean-k-mooney: I provided an alternative name for the API field | 14:28 |
| noonedeadpunk | As actually I assume that what matters at the end... | 14:29 |
| bauzas | 'attached_availability_zone' | 14:29 |
| sean-k-mooney | i dont like attached | 14:29 |
| sean-k-mooney | you also sugggested pinned_availablity_zone | 14:29 |
| bauzas | we already have 'cross_az_attach' option, hence my name | 14:29 |
| sean-k-mooney | attach in that context is refering to the volume not the az | 14:29 |
| bauzas | possibly yeah | 14:30 |
| sean-k-mooney | so pinned_aviableity_zone or required_avilablity_zone are all fine | 14:30 |
| 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 |
| sean-k-mooney | noonedeadpunk: form an operator perspective what would you find more intuitive | 14:30 |
| bauzas | I'm not fine with 'requested_az' for the reason I explained | 14:30 |
| sean-k-mooney | right but i actully think that is the most correct form for the reasons i explaied :) | 14:31 |
| 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 |
| sean-k-mooney | but i dont really care too much what the field name is | 14:31 |
| sean-k-mooney | bauzas: right but its part of the requst_spec | 14:31 |
| sean-k-mooney | there for the az was requested | 14:31 |
| sean-k-mooney | it does not makter who requeteded it | 14:32 |
| bauzas | sean-k-mooney: well, some enduser doesn't know the internals | 14:32 |
| sean-k-mooney | yep which is why im interested in noonedeadpunk input | 14:32 |
| sean-k-mooney | im fine with using a diffent name | 14:32 |
| bauzas | noonedeadpunk: tell me a better name and I +2 your own spec :p | 14:32 |
| bauzas | (jk) | 14:32 |
| sean-k-mooney | so if you think somethign else is better that is ok with me althoug lets avoid attach | 14:32 |
| sean-k-mooney | bauzas: this is now noonedeadpunk spec | 14:33 |
| sean-k-mooney | theres is the other one | 14:33 |
| bauzas | sean-k-mooney: I'm quite conservative on AZs given it's an enduser param | 14:33 |
| bauzas | and most OVH endusers (for example) don't know a single bit of the nova internals | 14:33 |
| sean-k-mooney | well even those that do disagree on how az should be used | 14:34 |
| bauzas | sean-k-mooney: yeah I know, we're speaking of ratailor's spec | 14:34 |
| sean-k-mooney | i for one have no issue with explcitly requesting the nova az | 14:34 |
| sean-k-mooney | i know why you dont like that | 14:34 |
| sean-k-mooney | but to me that is perfectly valid | 14:34 |
| sean-k-mooney | and i know of cloud that have configured default_schedule_zone=nova | 14:34 |
| sean-k-mooney | thats a tangent | 14:35 |
| bauzas | that's a terrible thing | 14:35 |
| * noonedeadpunk reading the spec itself now | 14:35 | |
| bauzas | and we documented that | 14:35 |
| sean-k-mooney | bauzas: right but horizon default to nova and i belive it always puts it in the request | 14:35 |
| bauzas | NOOOOOOOOOOOOOOOOOOOOOOOOOOO | 14:35 |
| bauzas | are you joking ? | 14:36 |
| sean-k-mooney | i know that horizon use to alwasy require an az in the drop down | 14:36 |
| sean-k-mooney | and if nova was the only one in the list you had no other choice | 14:36 |
| bauzas | that's an horizon bug then | 14:36 |
| sean-k-mooney | one that has been there forever | 14:36 |
| noonedeadpunk | ooopps | 14:36 |
| bauzas | https://docs.openstack.org/nova/latest/admin/availability-zones.html | 14:36 |
| sean-k-mooney | like litrally since i started workin on openstack 10 years ago | 14:37 |
| bauzas | I wrote that in solid red | 14:37 |
| 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 | 14:37 |
| ratailor | sean-k-mooney, bauzas I took that name, because its easy to differentiate for endusers, who don't know anything about nova internals. | 14:37 |
| bauzas | ratailor: read my comments | 14:37 |
| ratailor | bauzas, ack. | 14:38 |
| bauzas | endusers would wonder why their instance has a returned param saying 'requested_az' : "bar" without them asking for it | 14:38 |
| bauzas | sean-k-mooney: sure, I understand people doing wild things are usual, but for those we also say "unsupported" | 14:39 |
| noonedeadpunk | I then have a question towards default_availability_zone that you already discussed some time ago with damiandabrowski. As like in some usecases I see close to no other option rather then define default_availability_zone, for instance when cross_az_attach = False | 14:39 |
| bauzas | noonedeadpunk: default_schedule_zone you mean . | 14:40 |
| bauzas | ? | 14:40 |
| bauzas | https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.default_schedule_zone | 14:40 |
| bauzas | ". The instance(s) will be bound to this availability zone " | 14:40 |
| bauzas | ahah, third alternative name ! "bound_availability_zone" | 14:41 |
| noonedeadpunk | yeah, sorry, default_schedule_zone | 14:41 |
| bauzas | noonedeadpunk: what's your question with this option ? | 14:41 |
| noonedeadpunk | So, when you have multiple AZs, and isolated storage in each AZ (so volumes can't migrate cross-AZ), and user does not provide AZ explicitly - VM will try to move between AZs, since it's not ending up in request_specs | 14:42 |
| noonedeadpunk | unless default_schedule_zone is defined | 14:43 |
| noonedeadpunk | nah, disregard, I already found answer to my "question" :) | 14:46 |
| bauzas | noonedeadpunk: yeah, it depends on cross_az_attach value | 14:46 |
| bauzas | if True, indeed | 14:47 |
| bauzas | if False, nope, we'll automatically change the value of reqspec.az to the volume's az name | 14:47 |
| bauzas | so it will be "pinned" or "bound" | 14:47 |
| bauzas | even if the user "requested" something elsze | 14:48 |
| bauzas | hence my concern on the ratailor's API parameter name | 14:48 |
| bauzas | noonedeadpunk: how much your users know about Nova internals and the fact we have a DB table named "request_specs" ? | 14:48 |
| noonedeadpunk | bauzas: I think it's true only _if_ volume was created first | 14:49 |
| bauzas | the fact is that I don't like ourselves naming a new parameter "requested" if something else but the user changed it | 14:49 |
| noonedeadpunk | bauzas: they don't give a sh*** about it :D | 14:49 |
| bauzas | that's my point | 14:49 |
| noonedeadpunk | Because if volume is being created together with server - reqspec.az is not populated then | 14:50 |
| bauzas | noonedeadpunk: yeah, if you bfv your instance by asking nova to create a volume, then nova asks cinder for a new volume without passing the AZ | 14:50 |
| ykarel | thx sean-k-mooney for your response yesterday re. https://bugs.launchpad.net/nova/+bug/2045785 | 14:50 |
| ykarel | do you have link for the other tempest unfixed issue that you mentioned or link it into the bug ^ | 14:51 |
| bauzas | noonedeadpunk: because (IIRC) we create the volume *before* we schedule | 14:51 |
| ykarel | i will check later if it's same or some other issue | 14:51 |
| noonedeadpunk | bauzas: but shouldn't then it be veeery close to usage of already existing volume? | 14:52 |
| noonedeadpunk | Ie, you should be already be able to check AZ of that volume? | 14:52 |
| bauzas | honestly, I need to remember the details | 14:52 |
| bauzas | I also wrote a functional test for it | 14:52 |
| noonedeadpunk | Yeah, no worries | 14:53 |
| bauzas | so we could test | 14:53 |
| bauzas | noonedeadpunk: you haven't responded to our question about your preference for naming the new parameter that ratailor would provide | 14:53 |
| noonedeadpunk | We're just close to have each scheduler having it's own `default_schedule_zone` for some "random" provisionment | 14:54 |
| bauzas | from an user point of view, I was arguing on the fact that 'requested AZ' is wrongly named | 14:54 |
| bauzas | and I would prefer the new returned param to be something like 'pinned AZ' or 'bound AZ' | 14:54 |
| noonedeadpunk | Sorry, I'm trying to come up with some extra comments to it | 14:57 |
| noonedeadpunk | Well, given that indeed it's not "requested" per say, I think it may indeed being confusing | 15:00 |
| *** blarnath is now known as d34dh0r53 | 15:01 | |
| noonedeadpunk | Like in our case, where we want to have instances "evenly" distributed across AZs even when clients requested nothing | 15:01 |
| noonedeadpunk | But, they will indeed be pinned to this AZ | 15:01 |
| noonedeadpunk | But I also kinda wonder, if the output from the spec should be shown to everyone. As a user I will be also very confused if for some reasone these 2 will differ | 15:03 |
| noonedeadpunk | While I totally get why I'd love to monitor that without doing DB queries on my own | 15:03 |
| bauzas | noonedeadpunk: we have some customers that wonder why they can't move their instances to something else | 15:04 |
| bauzas | endusers don't really know about that, but they can see that their instance is pinned or not | 15:05 |
| bauzas | but agreed on the fact operators would want to have a specific policy for this parameter | 15:05 |
| noonedeadpunk | Hm, does scheduler hint for specific compute may also result in instance being pinned to it? I guess not? | 15:05 |
| noonedeadpunk | As it's hint after all... | 15:06 |
| bauzas | it shouldn't | 15:06 |
| bauzas | we only pin on three facts : | 15:06 |
| bauzas | - the user requested an AZ | 15:06 |
| bauzas | - the operator defaulted instances to an AZ (per nova-api service) | 15:06 |
| bauzas | - the instance is attached to a volume that *already* uses an AZ | 15:07 |
| bauzas | I don't see any other conditions where we would pin | 15:07 |
| noonedeadpunk | I think `pinned_availablity_zone` makes sense indeed. As "attached" as Sean mentioned can also be slightly confusing | 15:08 |
| bauzas | except of course if some operator changed the RequestSpec value directly :p | 15:08 |
| bauzas | noonedeadpunk: could you then add a comment in the spec ? | 15:08 |
| bauzas | noonedeadpunk: fwiw, /me going to look at your own spec :) | 15:10 |
| sean-k-mooney | ykarel: https://review.opendev.org/c/openstack/tempest/+/905130 is the fix for what i mentioned | 16:12 |
| sean-k-mooney | or at least my first attempt of a fix | 16:12 |
| bauzas | noonedeadpunk: https://review.opendev.org/c/openstack/nova-specs/+/900296 mostly because you haven't written the work items and the spec doesn't have any owner | 16:15 |
| bauzas | will you have time to work on it this cycle ? | 16:15 |
| bauzas | you or someone else you know ? | 16:15 |
| noonedeadpunk | Well. Yes, I was planning to work on that, though I initially also expected to have slightly more time for it... | 16:20 |
| bauzas | shouldn't be a large feature | 16:20 |
| bauzas | add a new weigher should be an easy peasy | 16:21 |
| noonedeadpunk | Yeah, that's true. | 16:21 |
| bauzas | the most large patch would be adding the policy and the rule, with all files to touch due to the new microversion | 16:21 |
| bauzas | most largest* | 16:21 |
| bauzas | but I can help you on that | 16:22 |
| noonedeadpunk | and caching part you wrote concerns me as well a bit | 16:22 |
| noonedeadpunk | as will need get myself aware of how that's done today (never touched this part of code) | 16:22 |
| noonedeadpunk | bauzas: about policies - what policies you have in mind? | 16:28 |
| noonedeadpunk | as I was thinking that existing `os_compute_api:os-server-groups` would cover this? | 16:28 |
| bauzas | noonedeadpunk: well, I wrote "cache it" but actually, it shouldn't be a cache | 16:28 |
| noonedeadpunk | it's jsut get AZs to a var and then iterate over filters kinda? | 16:29 |
| bauzas | yeah exactly | 16:29 |
| noonedeadpunk | gotcha | 16:29 |
| bauzas | but the fact is that the weigher only knows about a few things | 16:29 |
| bauzas | https://github.com/openstack/nova/blob/master/nova/scheduler/weights/affinity.py#L39 | 16:29 |
| bauzas | so you would need to pass the list of azs into some object- | 16:30 |
| noonedeadpunk | well, request_spec sounds like what is needed? | 16:30 |
| noonedeadpunk | ah, ok, list of available ones | 16:31 |
| bauzas | req_spec is a formal oslo object | 16:31 |
| bauzas | I wouldn't recommend to use it, but that's your choice | 16:31 |
| bauzas | I just want to not have a oslo.versioned field for that | 16:32 |
| bauzas | some internal attribute for this object would work for it | 16:32 |
| bauzas | for me* | 16:32 |
| bauzas | noonedeadpunk: got my concern ? we run filters and weighers once per instance per host | 16:33 |
| noonedeadpunk | yeah, totally | 16:33 |
| bauzas | so if we were calling the list of AZs in the weigher, we would run it N times, N being the number of filtered hosts | 16:33 |
| bauzas | noonedeadpunk: you could stuff the list of AZs somewhere in https://github.com/openstack/nova/blob/master/nova/scheduler/manager.py#L299 | 16:35 |
| noonedeadpunk | will adjust spec with your notes | 16:40 |
| opendevreview | Amit Uniyal proposed openstack/nova master: Refactor vf profile for PCI device https://review.opendev.org/c/openstack/nova/+/905134 | 16:42 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/nova-specs master: [spec] Add Cross-AZ scheduling blueprint https://review.opendev.org/c/openstack/nova-specs/+/900296 | 17:20 |
| noonedeadpunk | bauzas: I've tried to address your concerns ^ | 17:25 |
| noonedeadpunk | but actually now I get a bit more your concerns for getting AZs out of filter itself | 17:26 |
| noonedeadpunk | because eventually, here we should be caring about "aggregates" rather then individual host and also weight based on that | 17:28 |
| sean-k-mooney | noonedeadpunk: i was too hasty with reviewing your spec | 17:30 |
| sean-k-mooney | if forgot there was also a second spec on this topic | 17:30 |
| sean-k-mooney | https://review.opendev.org/c/openstack/nova-specs/+/890779/3/specs/2024.1/approved/availability-zone-affinity-filters.rst | 17:30 |
| sean-k-mooney | and that we have to do some non trivial stuff with the request spec | 17:30 |
| sean-k-mooney | noonedeadpunk: for contiend we need to suport multi create | 17:31 |
| sean-k-mooney | i.e. one reuest that ask for n vms | 17:31 |
| sean-k-mooney | as well as parallal create | 17:31 |
| sean-k-mooney | sorry not parralle serial non overlapping creates of instance one after another waiting for each to go to active before doing the next | 17:32 |
| noonedeadpunk | I probably should jsut abandon mine I guess as it indeed now looks like a duplicate one | 17:34 |
| noonedeadpunk | I guess the one you posted originated from Vacouver PTG, as this discussion was raised there as well.... | 17:38 |
| noonedeadpunk | It really slipped my attention, though I was checking for simmilar existing blueprints :( | 17:46 |
| bauzas | noonedeadpunk: you somehow need to flip between hosts | 17:46 |
| bauzas | but ya, looks to me a bit difficult | 17:47 |
| bauzas | anyway, I need to go off | 17:48 |
| sean-k-mooney | so we have example code that we can reuse for this for the normal host based affinity | 18:11 |
| sean-k-mooney | i just dont think i will have time to track that down and provide links to it before sepc freeze | 18:12 |
| JayF | https://review.opendev.org/c/openstack/nova/+/900831 needs an additional core review, it is a bugfix for the Ironic driver. Your reviews would be appreciated o/ | 21:29 |
| *** jph4 is now known as jph | 23:48 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!