| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-12-05 | |||
| 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 | |
| 22:44:43 | mriedem | that's what we'd do with a disabled trait as well | |
| 22:45:17 | mriedem | https://developer.openstack.org/api-ref/block-storage/v3/?expanded=freeze-a-cinder-backend-host-detail#freeze-a-cinder-backend-host | |
| 22:45:21 | mriedem | sean-k-mooney: you mean like that ^ | |
| 22:45:36 | sean-k-mooney | yep | |
| 22:46:41 | sean-k-mooney | i think it woudl be common usecase that other servcies woudl use if we figured out a generic way of doing it in nova | |
| 22:46:51 | sean-k-mooney | * in placement | |
| 22:47:37 | cfriesen | how about a "resource unavailable" trait? | |
| 22:47:57 | sean-k-mooney | cfriesen: that is the trait we were suggesting by another name | |
| 22:48:03 | cfriesen | yes | |
| 22:49:20 | cfriesen | just trying to come up with a suitably generic name | |
| 22:50:14 | sean-k-mooney | edleafe: any comment on using a trait? | |
| 22:51:43 | edleafe | sean-k-mooney: You mean besides the design that a trait is not for status? | |
| 22:52:15 | sean-k-mooney | edleafe: yep beside the general object ot using placement as a metdata store / etcd standin | |
| 22:52:34 | edleafe | sean-k-mooney: :) | |
| 22:54:38 | mriedem | here are some sufficiently out of band proxy via nova via placement things you guys will probably all like then https://review.openstack.org/#/c/552190/ https://review.openstack.org/#/c/549067/ | |
| 22:57:34 | sean-k-mooney | vmware are aware that openstack in not vspher/vcloud right ... | |
| 22:58:57 | sean-k-mooney | the vmware-vm-groups sound kindof like the tenant aggreate affintiy usecase | |
| 22:59:11 | sean-k-mooney | oh actully | |
| 22:59:49 | sean-k-mooney | ok the usecase is compulte different to what i was expecte form the intro and problem descripteion | |
| 23:27:57 | sean-k-mooney | does blazer not use its specs repos | |
| 23:30:49 | sean-k-mooney | its in tree never mind | |
| 23:40:10 | openstack | Launchpad bug 1805984 in OpenStack Compute (nova) "Placement is not aware of disable compute nodes" [Undecided,New] | |
| 23:40:10 | tssurya | mriedem: we have filed the bug already regarding placement not knowing about disabled computes: https://bugs.launchpad.net/nova/+bug/1805984 | |
| 23:41:14 | sean-k-mooney | tssurya: its not really a bug its a new feature that shoudl live in nova | |
| 23:41:26 | sean-k-mooney | well not quite | |
| 23:41:44 | sean-k-mooney | its not currently expected that placement would know | |
| 23:41:55 | sean-k-mooney | so its no a bug in that sence | |
| 23:49:44 | openstack | Launchpad bug 1708958 in OpenStack Compute (nova) "disabling a compute service does not disable the resource provider" [Wishlist,Won't fix] | |
| 23:49:44 | tssurya | sean-k-mooney: right agreed its not a bug since it was decided as a won't fix on the placement side (https://bugs.launchpad.net/nova/+bug/1708958) | |
| 23:50:19 | tssurya | but mriedem wanted a bug (was replying to his ML post) | |
| 23:50:25 | sean-k-mooney | tssurya: i set it to triage and wish list with the suggestion of converting to a spec or specless blueprint | |
| 23:50:28 | tssurya | to just track the issue | |
| 23:50:58 | sean-k-mooney | tssurya: if it was neutron i would have just set the RFE tag on the bug but nova does not use that | |
| 23:51:24 | sean-k-mooney | its definetly an edge case an i can see it causeing issues for larger deployments | |
| 23:52:17 | sean-k-mooney | did you see the conversation we had on this an hour ago | |
| 23:56:08 | tssurya | sean-k-mooney: was just scrolling back up to read it :D | |
| 23:56:25 | tssurya | I can see a couple of plausible solutions being proposed | |
| 23:56:42 | sean-k-mooney | yep there are 2 or 3 options | |
| 23:57:11 | tssurya | probably the one where reserved=total + disabling periodic updates on disabled computes to avoid overwrite is the better option | |
| 23:57:23 | sean-k-mooney | it looks like we should be able to come up with somethign | |
| 23:57:27 | tssurya | considering adding another periodic task just for this might be a overhead | |
| 23:57:32 | sean-k-mooney | tssurya: im not sure about that | |
| 23:58:03 | sean-k-mooney | i guess we will see the traits approch or using a disabled aggreate seam like a clean solution | |
| 23:58:43 | tssurya | oh disabled aggregates! didn't see that part yet, reading now | |
| 23:59:53 | sean-k-mooney | tssurya: well a disable aggreage is just an aggrage that we "nova" adds host that are down too and we jsut use the not member_of proposal to avoid | |
| #openstack-nova - 2018-12-06 | |||
| 00:00:49 | sean-k-mooney | specifcially use this feature https://review.openstack.org/#/c/603352/ | |
| 00:03:33 | tssurya | sean-k-mooney: yea thanks, did read the full spec yet but got the idea | |
| 00:04:19 | tssurya | so it would be something like adding/removing to an aggregate when we disable/enable the service I guess | |
| 00:05:44 | tssurya | and the fourth solution was traits I see | |
| 00:05:45 | sean-k-mooney | yep and we then jsut alway include member_of=!<uuid of disbaled aggreage> | |
| 00:05:51 | sean-k-mooney | in the placement request | |
| 00:06:06 | tssurya | sean-k-mooney: yep makes sense | |