Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-03-15
20:32:04 mriedem ok but there is also this https://docs.openstack.org/admin-guide/cli-nova-specify-host.html
20:32:32 bauzas mriedem: yeah, because it's a terrible UX
20:32:43 mriedem i know it's not part of a filter, but i'm trying to figure out how it becomes a list,
20:32:46 bauzas forced_hosts is set by the AZ flag
20:33:02 bauzas mriedem: honestly, I don't remember why, lemme verify the change
20:33:02 mriedem because the only thing i see that sets forced_hosts in the request spec comes through the REST API using the az parsing in ^
20:33:39 mriedem those docs are also a bit wrong btw, they say "HOST is an optional parameter. In such cases, use the --availability-zone ZONE::NODE." - but they fail to mention that NODE is also an optional parameter
20:34:19 bauzas node was added later
20:34:26 bauzas because of $ironic :)
20:34:30 openstackgerrit Ed Leafe proposed openstack/nova master: Add check for invalid inventory amounts https://review.openstack.org/428800
20:34:31 openstackgerrit Ed Leafe proposed openstack/nova master: Add check for invalid allocation amounts https://review.openstack.org/416752
20:34:35 edleafe jaypipes: mriedem: updated ^^
20:35:21 jaypipes cool
20:37:19 bauzas mriedem: so, in between PS7 and PS8, I modified force_hosts to be a list
20:37:20 bauzas https://review.openstack.org/#/c/145528/8..9/nova/objects/request_spec.py
20:37:39 bauzas I'm trying to remember the context why
20:37:47 mriedem 8..9, butok
20:38:40 bauzas mmm
20:38:55 mriedem it's 46 patch sets is hurting my browser
20:39:44 bauzas so, the only reason I see that is because filter_props was having a list
20:40:12 bauzas it's not what I say a reasonable answer, so lemme verify why we have a list for the legacy dict
20:40:35 mriedem i smell a rackspace reason here
20:41:26 bauzas at least the host manager waits for a list
20:41:32 bauzas and I haven't changed that
20:41:42 bauzas so somewhere we accepted a list
20:42:11 bauzas yeah... build_filter_properties() in nova.scheduler.utils
20:42:14 bauzas mriedem: ^
20:43:00 mriedem https://github.com/openstack/nova/commit/90620a27e0831345864f574256b30bac1ced5843
20:43:03 bauzas mriedem: https://github.com/openstack/nova/commit/9998c51f
20:43:47 mriedem https://github.com/openstack/nova/commit/90620a27e0831345864f574256b30bac1ced5843 goes back to havana,
20:43:52 bauzas mriedem: sure, but both don't explain why we want a list
20:43:55 mriedem and appears to introduce the idea that forced_hosts is a list
20:44:18 mriedem could have been a mistake if the key was named "force_hosts" so plural
20:44:53 mriedem https://github.com/openstack/nova/blob/90620a27e0831345864f574256b30bac1ced5843/nova/compute/api.py#L727
20:44:55 bauzas we should go back where force_hosts was originally created
20:45:04 mriedem i'm going
20:45:31 bauzas yeah, like I said there are a shit ton of places where we expect a list
20:45:39 bauzas so I shamelessly copied that
20:46:05 bauzas although I originally found it was a string like I wrote in my PS8
20:46:10 bauzas defeated by tech debt
20:47:41 mriedem https://github.com/openstack/nova/commit/7b34a2d767b60e053ac1f49d1cdd8c853b8d9133
20:47:46 mriedem is about as far back as i see
20:48:27 bauzas https://github.com/openstack/nova/commit/836ee3f45
20:48:27 mriedem oh wait it goes further
20:49:22 jroll don't you guys know to always blame comstud by now
20:51:00 mriedem https://github.com/openstack/nova/commit/16ea348a1623f055809d0d9b7fe9f046515b5dd1
20:51:01 melwitt I was seeing some stuff from essex
20:51:54 mriedem ^ is essex
20:52:20 bauzas yeah I was an diablo op and I don't remember that feature
20:52:21 melwitt hah, nice
20:52:41 bauzas I just remember Essex added lots of things like that
20:52:54 bauzas but it's very old stories at the corner of the fireplace
20:53:41 bauzas soooo... to answer mriedem's question, I guess that the terrible answer he was afraid was the correct one
20:53:56 bauzas ie. "we planned that for the future"
20:54:31 bauzas just give me a license to kill that AZ hack, and I'll write a specx
20:54:45 melwitt it was maybe mirroring ignore_hosts, which was already there when force_hosts was added
20:55:00 bauzas yeah
20:55:20 bauzas anyway, force_hosts is a legacy from the past, and we should get rid of it
20:55:37 mriedem i'm not necessarily saying let's remove it,
20:55:43 bauzas I'm saying it :p
20:55:55 mriedem but it sure as shit causes a lot of confusion when you're looking at all of the code that uses it, and the API that provides the value, and you see it's not a list
20:56:00 mriedem and you say, wtf am i missing?
20:56:20 bauzas mriedem: you know that the policy differs for that, right?
20:56:25 mriedem yes
20:56:37 melwitt would have to run that by operators because afaik they use that to test new compute host before making it available for scheduling?
20:56:38 mriedem you mean "create:forced_host" right?
20:56:45 bauzas yup
20:56:54 mriedem yeah i thought operators were pretty keen on this,
20:56:59 bauzas I was
20:57:03 mriedem and we've baked it into the migration APIs right?
20:57:11 bauzas in Essex, it was terribly necessary
20:57:40 bauzas but now, we are in a far better place, but at least we should mimic what we merged for the move operations
20:57:53 bauzas ie. having a possible target with a force flag
20:58:24 bauzas which would then verify the filters if the target is set without force
20:58:34 bauzas or totally bypass the scheduler if force
20:58:55 mriedem so, i'm going to just start with a code comment in the request spec object
20:59:04 mriedem so when i look at this in a year, i won't have to do all of the detective work again
20:59:59 bauzas fine by me
21:04:41 openstackgerrit Matt Riedemann proposed openstack/nova master: Add a note about force_hosts only ever having a single value https://review.openstack.org/446175
21:04:42 mriedem there you go ^
21:04:49 openstackgerrit Roman Dobosz proposed openstack/nova-specs master: Provide detailed error information for placement API https://review.openstack.org/418393
21:06:09 mriedem ok, well, back to figuring out how i can mock the scheduler to send build requests to certain hosts in order
21:07:28 bauzas melwitt: https://review.openstack.org/#/c/446175/1 could be worth of interest
21:07:51 bauzas mriedem: what's your concern ?
21:08:06 mriedem bauzas: i'm writing a functional test to recreate https://review.openstack.org/#/c/444106/
21:08:07 bauzas mriedem: you want the scheduler to return you a specific destination ?
21:08:21 mriedem i have 2 hosts, i want the scheduler to send them in order
21:10:34 mriedem i think i can just use the disk weigher and fake it out
21:13:50 mriedem oh now i see a bug in the docs
21:15:28 openstackgerrit Matt Riedemann proposed openstack/nova master: Fix the help for the disk_weight_multiplier option https://review.openstack.org/446177
21:16:31 bauzas mriedem: the scheduler is only returning one host, so 2 calls one after the other ?
21:17:21 mriedem bauzas: i need the test to make the scheduler put the server on the hosts in order, where the first host will fail during driver.spawn which would normally trigger a retry to the 2nd host
21:17:30 mriedem i've got 2 hosts in the test
21:17:45 mriedem i want to trick the scheduler into picking the hosts in order
21:17:52 mriedem so i really just need it to pick the bad one first
21:18:06 mriedem i guess maybe it doesn't matter which order as long as i can keep track of the first host that's called
21:18:18 mriedem i'll just do that
21:19:05 bauzas I see
21:21:32 bauzas mriedem: tbh, just asks the scheduler for one host, kill the spawn and then the reschedule will put that host in the retry list
21:22:02 bauzas in case retry doesn't work, then you'll get the first node

Earlier   Later