Earlier  
Posted Nick Remark
#openstack-nova - 2017-04-07
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
14:45:41 mriedem nicodemus_: you can see here https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/extended_server_attributes.py#L34 that hypervisor_hostname comes from the instances.node column

Earlier   Later