| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-12-05 | |||
| 21:46:06 | sean-k-mooney | anyway if we say only the entity that created the RP may set the reserved value on the invetories im fine with that if we document it | |
| 21:46:58 | dansmith | I thought there was some other reason for doing the rpc cast on disable, but I can't remember what it was | |
| 21:47:46 | dansmith | maybe so ironic driver can do something? | |
| 21:47:52 | sean-k-mooney | on disableing a compute node. i think some dirver can take actions on disable and ironic might be one of them but i dont remember eiter | |
| 21:48:14 | efried | <do a right thing to disable the inventory> | |
| 21:48:14 | efried | if self.disabled: | |
| 21:48:14 | efried | we can ask each driver's upt to do | |
| 21:48:39 | dansmith | efried: we still have to do it as soon as the api is called though, | |
| 21:48:44 | dansmith | so waiting for the next periodic is not good enough | |
| 21:48:51 | efried | mm | |
| 21:49:08 | dansmith | oh yeah, so.. | |
| 21:49:11 | mriedem | right i could disable an entire cell, | |
| 21:49:11 | efried | do we have a ComputeDriver hook that we call on disable? | |
| 21:49:15 | dansmith | disable is on the service not the node, right? | |
| 21:49:23 | efried | or could/should we implement one? | |
| 21:49:25 | mriedem | er half a cell, and then live migrate stuff within the cell | |
| 21:49:27 | dansmith | so if you disable the thing running on ironic, the nodes will still be schedule-able | |
| 21:49:30 | mriedem | dansmith: yes on the service | |
| 21:49:53 | mriedem | efried: we don't have one for os-services disable no | |
| 21:49:55 | dansmith | so you have to do the service->nodes translation, and set the trait on all the nodes | |
| 21:50:04 | mriedem | we had one for os-hosts update status, but that was something else that only xen implemented | |
| 21:50:09 | dansmith | but if you rpc to the compute, it gets to do that itself | |
| 21:50:10 | mriedem | dansmith: yup | |
| 21:50:11 | efried | um, or we could make upt that thing - i.e. call it immediately on disable | |
| 21:50:40 | dansmith | mriedem: that also gets wonky if you disable a service and then they rebalance, but you have set the trait on some nodes that rebalanced out | |
| 21:50:42 | sean-k-mooney | mriedem: so the trait way woudl be add status_down trait and change placment query to include status_down forbien trait? | |
| 21:50:46 | dansmith | I guess they'll eventually un-disable, but.. ick | |
| 21:50:52 | dansmith | well, not actualy | |
| 21:51:00 | dansmith | because we just said virt has to leave those alone if the api set them | |
| 21:51:18 | mriedem | sean-k-mooney: essentially yes | |
| 21:51:28 | mriedem | if ComputeFilter is enabled or something | |
| 21:51:30 | dansmith | efried: right point being we don't have an rpc call for disable right now, but I think we probably should | |
| 21:51:35 | mriedem | or some new boolean that replaces ComputeFilter | |
| 21:51:57 | efried | oh, because the disabling is being prompted not by the compute itself. | |
| 21:52:03 | mriedem | correct | |
| 21:52:04 | dansmith | it's an api call | |
| 21:52:09 | dansmith | in most cases | |
| 21:52:12 | mriedem | https://developer.openstack.org/api-ref/compute/#compute-services-os-services | |
| 21:52:14 | dansmith | however, | |
| 21:52:16 | sean-k-mooney | well the trait could elminate the host before the filster so we dont need the computeFilter anymore | |
| 21:52:24 | mriedem | if the hypervisor dies the libvirt driver auto-disables it's own compute service | |
| 21:52:28 | dansmith | mriedem: computes can self-disable, so you'd also have to have them be able to set/clear the trait | |
| 21:52:38 | efried | this would be a great use case for sean-k-mooney's reverse-required traits :P | |
| 21:52:39 | mriedem | i smell spec | |
| 21:52:52 | dansmith | if you just let the compute always manage this in response to an rpc call, the ownership of it is a lot more clear I think | |
| 21:52:59 | efried | ++ | |
| 21:53:03 | mriedem | sure i'm fine with rpc call to compute to do the thing | |
| 21:53:18 | sean-k-mooney | efried: you mean the " you cant be schduled to this RP without asking for trait X" | |
| 21:53:23 | mriedem | btw this was the old thing from the os-hosts API https://github.com/openstack/nova/blob/master/nova/compute/api.py#L5026 | |
| 21:53:25 | efried | sean-k-mooney: yeah, that one. | |
| 21:53:57 | mriedem | we could maybe re-use that | |
| 21:54:38 | mriedem | that was only used by this before https://developer.openstack.org/api-ref/compute/#update-host-status | |
| 21:54:41 | mriedem | which is deprecated | |
| 21:55:14 | dansmith | I wonder if jaypipes is okay with a status_enabled or status_disabled trait on compute nodes | |
| 21:55:35 | sean-k-mooney | mriedem was that repalce by the mark host down thing that we added for opnfv | |
| 21:55:46 | mriedem | sean-k-mooney: on | |
| 21:55:47 | mriedem | *no | |
| 21:56:02 | dansmith | m-h-d is not just for opnfv | |
| 21:56:08 | mriedem | sean-k-mooney: https://specs.openstack.org/openstack/nova-specs/specs/pike/implemented/deprecate-os-hosts.html | |
| 21:56:29 | sean-k-mooney | dansmith: ya i know but they where the group i had the most conversation with | |
| 21:57:46 | sean-k-mooney | mriedem the more you know. we have/had a lot of duplicate/legacy apis | |
| 22:30:56 | cfriesen | just saw mriedem's mail on placement and disabled computes...rather than mucking around with inventory values why not just explicitly add a separate field that says whether a given RP is enabled or not? | |
| 22:33:52 | mriedem | field? | |
| 22:34:00 | mriedem | omg have you talked to jay or chris ever? | |
| 22:34:11 | mriedem | it's a trait at best | |
| 22:34:14 | mriedem | but jay might not even like that | |
| 22:34:18 | edleafe | cfriesen: because that feels like having placement mirror nova's design. IMO it would be cleaner to set reserved=total | |
| 22:34:19 | mriedem | since it's not a capability | |
| 22:35:03 | edleafe | mriedem: although it would be fun watching Jay foam at the mouth | |
| 22:35:22 | mriedem | yes i was hoping dan pinging him would summon the beast | |
| 22:35:31 | sean-k-mooney | well the cappablity is its abiltiy to provide resouces. | |
| 22:35:49 | sean-k-mooney | there is proably a general usecase there but ya likely not a new field | |
| 22:36:09 | mriedem | https://assets.rbl.ms/14621189/980x.jpg | |
| 22:37:04 | sean-k-mooney | for a second i tought it was a crock and wasl like aw its a lab | |
| 22:37:41 | cfriesen | edleafe: I don't like modifying "reserved" when nova hasn't really reserved anything, and I'm concerned that the math makes no sense if we set "reserved" equal to total but have already-allocated resources as well | |
| 22:38:05 | cfriesen | some sort of flag saying "don't consider this RP" makes more sense, I think | |
| 22:38:33 | sean-k-mooney | cfriesen: if it was a non nova specific one like avaiable then maybe | |
| 22:38:59 | cfriesen | oh, sure. I don't care about the actual name. :) | |
| 22:39:16 | edleafe | cfriesen: I don't like it at all; I just hate it much, much less than adding a nova-specific field | |
| 22:39:18 | sean-k-mooney | cfriesen: if you want jay and other to buy in to it you should :) | |
| 22:39:39 | edleafe | cfriesen: It should be a nova filter ideally | |
| 22:39:52 | mriedem | that's what the trait would do | |
| 22:39:55 | mriedem | provide filtering | |
| 22:39:57 | cfriesen | edleafe: it is already | |
| 22:40:18 | cfriesen | the problem is that if placement only returns disabled compute nodes then nova filters them all out and ends up with novalidhost | |
| 22:40:31 | sean-k-mooney | mriedem: yes and it would just be using required/forben traits which already exist so no placment change requried | |
| 22:40:45 | sean-k-mooney | we would be jsut establishing it as a patteren | |
| 22:41:35 | sean-k-mooney | the issue is that we are usign placement to store metadata.. again about the resouce which is kindo fo what a trait is but not entirely | |
| 22:41:46 | mriedem | if people don't think that lots of external services, like vcenter agents and such, are going to be dynamically adding/removing traits to coerce scheduling behavior in nova,... | |
| 22:42:05 | mriedem | how many people have already talked about adding basically encoding into traits for the lack of metadata | |
| 22:42:31 | edleafe | mriedem: "disabled" is a nova concept, not a placement one. If you don't want to use a scheduler filter on the nova side, then create a "disabled" agg, and add/remove compute nodes as needed, then use the upcoming negative member_of. | |
| 22:42:52 | sean-k-mooney | mriedem: i was talking to an onap person at one point and when i told them what placement was they ask if the could use traits to tag the compute nodes with there uuids so they could say where to boot... | |
| 22:43:20 | sean-k-mooney | edleafe: there are paralles in other service | |
| 22:43:26 | mriedem | edleafe: even using forbidden aggregates means nova needs to know to filter on that | |
| 22:43:43 | mriedem | which is tpatil's spec | |
| 22:43:49 | mriedem | https://review.openstack.org/#/c/609960/ | |
| 22:44:01 | mriedem | which is totally complicated for me btw | |
| 22:44:06 | mriedem | but again, i might just be dumb | |
| 22:44:07 | sean-k-mooney | edleafe: you can mark a neutron dataplane as down i would be surprised if cinder does not have something similar | |
| 22:44:15 | edleafe | mriedem: Sure, just include that in every request, since you never want to schedule to a disabled host | |