| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-07 | |||
| 14:30:34 | bauzas | mriedem: no, not yet | |
| 14:30:39 | bauzas | mriedem: looking at your spec | |
| 14:30:41 | mriedem | the host state would have an empty instance dict | |
| 14:30:48 | mriedem | it would anyway | |
| 14:30:54 | bauzas | mriedem: yeah, so it's all good | |
| 14:31:02 | mriedem | dansmith: so in general ok with that patch? if so i'll start tests | |
| 14:31:09 | dansmith | mriedem: yeah | |
| 14:31:11 | mriedem | cool | |
| 14:31:19 | bauzas | it's just meaningless to update the scheduler with an empty list given the HostState already has it :) | |
| 14:31:39 | mriedem | it's kind of nice that after so many years i've finally have to start looking at the HostManager code in the scheduler | |
| 14:32:06 | mriedem | can't avoid it forever i guess | |
| 14:32:37 | mriedem | bauzas: it's not a spec btw, it's just, don't send a full InstanceList of full objects from all computes to the scheduler | |
| 14:32:50 | mriedem | when all the scheduler filters need really is uuid (and apparently instance_type_id) | |
| 14:33:11 | bauzas | mriedem: yeah they also need the flavor id | |
| 14:33:14 | bauzas | AFAIR | |
| 14:33:24 | bauzas | some filter is verifying it | |
| 14:33:31 | mriedem | the TypeAffinityFilter uses the instance.instance_type_id | |
| 14:33:31 | bauzas | oh yeah, the InstanceTypeFilter one you mentioned | |
| 14:33:34 | mriedem | which is the flavor primary key | |
| 14:33:38 | mriedem | which is bad | |
| 14:33:39 | bauzas | yeah yeah | |
| 14:33:41 | mriedem | as noted in the ML | |
| 14:33:48 | mriedem | and i'd be surprised if anyone uses it | |
| 14:34:17 | bauzas | don't be surprised | |
| 14:34:28 | bauzas | mriedem: I'm pretty sure I'll find operators using it | |
| 14:34:40 | figleaf | mriedem: there was debate over that back when we removed db access from the filters | |
| 14:34:51 | bauzas | oh man, TGIF | |
| 14:35:06 | figleaf | There were people then who claimed those filters were used | |
| 14:35:11 | bauwser | zactly | |
| 14:35:15 | mriedem | if they claim they are used, | |
| 14:35:21 | mriedem | then i want to know how they deal with changing flavors | |
| 14:35:27 | mriedem | or do they just never change flavors | |
| 14:35:34 | mriedem | i.e. delete and recreate | |
| 14:35:37 | bauwser | the latter I guess | |
| 14:35:38 | figleaf | Otherwise I would have been happy to chuck 'em in the trash | |
| 14:35:44 | mriedem | maybe they just don't know they've been broken | |
| 14:35:50 | mriedem | and this explains their NoValidHost issues | |
| 14:35:58 | figleaf | Could be | |
| 14:36:02 | bauwser | hah | |
| 14:36:04 | mriedem | if i have to send both, | |
| 14:36:04 | bauwser | anyway | |
| 14:36:16 | figleaf | It always seemed fragile | |
| 14:36:26 | mriedem | i'll probably still trim it down from a full InstanceList to a simple InstanceInfo object or something that's versioned and has 2 fields | |
| 14:36:29 | dansmith | fragile is an understatement | |
| 14:36:46 | openstackgerrit | John Garbutt proposed openstack/nova master: Add description to policies in remote_consoles.py https://review.openstack.org/454372 | |
| 14:36:46 | mriedem | rather than just a dict | |
| 14:37:04 | bauwser | lgtm | |
| 14:37:11 | bauwser | and honestly | |
| 14:37:15 | mriedem | i was thinking, if we did deprecate TypeAffinityFilter, we'd have to wait on sending a list of uuids until queens | |
| 14:37:17 | bauwser | when I wrote that BP | |
| 14:37:28 | bauwser | about fanouting the scheduler API with stuff | |
| 14:37:33 | mriedem | and even then, some later filter might need something new and we'd have to add another field to the thing we send | |
| 14:37:41 | bauwser | I was rather thinking of how to update the scheduler differently | |
| 14:37:46 | bauwser | so, now we have placement | |
| 14:38:03 | bauwser | I do wonder if we shouldn't rather use placement for pushing those kind of "resources" | |
| 14:38:15 | bauwser | not saying placement should verify those | |
| 14:38:29 | bauwser | but then the scheduler would query placement rather | |
| 14:38:44 | bauwser | I dunno, it's just a thought | |
| 14:39:02 | mriedem | well, placement does have the list of consumers (instance uuids) per resource provider (compute node) | |
| 14:39:10 | mriedem | placement doesn't have the flavor id | |
| 14:39:10 | bauwser | I don't like computes doing RPC fanouts to the scheduler, and I'm even not comfortable because I wrote that in the past | |
| 14:39:14 | figleaf | bauwser: placement doesn't "know" instance ids and flavor ids | |
| 14:39:18 | bauwser | figleaf: I know | |
| 14:39:35 | bauwser | I'm just saying it's a problem for cellsv2 at least | |
| 14:39:40 | bauwser | because it's an upcall | |
| 14:39:44 | mriedem | the resource provider will have a COMPUTE trait though right? | |
| 14:39:47 | bauwser | like rescheduling | |
| 14:39:55 | mriedem | the compute trait replaces the can_host field | |
| 14:40:10 | bauwser | mriedem: sure, but I don't get your idea | |
| 14:40:35 | mriedem | i don't either so let's not talk about it | |
| 14:40:44 | bauwser | just to make it clear, from a cells perspective, there are 3 upcalls from compute to the API world | |
| 14:40:55 | bauwser | one is when you reschedule, you call out conductor | |
| 14:41:05 | bauwser | the second is the instance list | |
| 14:41:10 | bauwser | (to the scheduler) | |
| 14:41:16 | bauwser | the third one is the aggregate list | |
| 14:41:22 | bauwser | (to the scheduler too) | |
| 14:41:23 | mriedem | did you forget server group members? | |
| 14:41:40 | mriedem | https://review.openstack.org/#/c/442736/ | |
| 14:41:41 | bauwser | we don't do that | |
| 14:41:46 | nicodemus_ | hello | |
| 14:41:46 | mriedem | we do | |
| 14:41:48 | bauwser | it's passed in the Spec AFAIK | |
| 14:41:54 | mriedem | see ^ | |
| 14:42:48 | bauwser | oh fuck, I thought you were talking of the Affinity filters verifying the group | |
| 14:42:50 | nicodemus_ | how can I modify the OS-EXT-SRV-ATTR properties on an instance? I've migrated five instances but had to do a rollback on the DB, and although the instances are in the new host the attributes show the old host... | |
| 14:43:09 | bauwser | mriedem: ServerGroup is an API DB thing ? | |
| 14:43:16 | bauwser | I didn't recall that | |
| 14:43:19 | mriedem | bauwser: yes | |
| 14:43:36 | bauwser | a-ha then sorry, s/3/4 indeed | |
| 14:43:52 | bauwser | but | |
| 14:43:56 | mriedem | nicodemus_: what does rollback on the db mean? | |
| 14:44:07 | bauwser | the 4th upcall is because we know it's racy | |
| 14:44:15 | mriedem | nicodemus_: and which specific field? | |
| 14:44:39 | bauwser | I do wonder if claims in the scheduler could help that race | |
| 14:44:51 | mriedem | bauwser: yes that's the idea for the workaround | |
| 14:44:59 | mriedem | is it's temporary until we have claims in the scheduler | |
| 14:45:02 | mriedem | per my understanding | |
| 14:45:04 | nicodemus_ | mriedem, two DB nodes went down and the remaining node didn't update the migration. The attributes I'd like to change are OS-EXT-SRV-ATTR:host and OS-EXT-SRV-ATTR:hypervisor_hostname | |
| 14:45:05 | mriedem | and the commit message | |
| 14:45:17 | bauwser | mriedem: well, the race still exists even if claims | |