Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-27
16:31:33 johnthetubaguy superdan: +1, but lets keep that separate
16:31:40 cdent superdan: k, I wasn't think in terms of the gate, but you know, like real people ;)
16:32:52 superdan johnthetubaguy: yeah, I was going to pull it out regardless, but I was going to keep it in the path of this set, but I won't now
16:33:00 superdan cdent: yes, which is why I asked for the reset thing initially
16:34:14 cdent johnthetubaguy: tacking back to that allocations thing now
16:36:42 mriedem is someone fixing up the nova side scheduler change? because if they are, can they address the exception wording comment in https://review.openstack.org/#/c/425806/ ?
16:37:47 johnthetubaguy cdent: ack
16:38:06 mriedem snikitin: are you saying the diagnostics patches were all approved yesterday before nit fixing?
16:38:10 mriedem or just had +2s on them?
16:38:44 openstackgerrit Jim Rollenhagen proposed openstack/nova: DNM: hack ironic with resource providers https://review.openstack.org/426296
16:38:49 jroll mriedem: enjoy
16:41:07 mriedem jroll: cool hopefully i can load that sometime today
16:41:24 jroll heh
16:48:53 sdague cdent: there are many ways that things can go wrong. My biggest concern is that we don't have a failed software stack that provides a passing result. As long as we don't have that, our cost is debug time and time until test completion.
16:49:33 sdague because we have a specific test that attempts to schedule to all nodes, and a min node count, we have one test that points in the right direction already, so debug time isn't hugely negatively impacted
16:49:46 sdague and test run time until failure is basically +15m here
16:49:47 cdent sdague: I'm not sure which of several context to put that response in?
16:50:01 figleaf johnthetubaguy: can you summarize the sticking points in https://review.openstack.org/#/c/404472 for your -1?
16:50:29 cdent johnthetubaguy: are you concerned about the situation of old style ironic allocations being deleted but then nothing allocation the new style? I'm still confused (apparently like figleaf too)
16:50:44 sdague cdent: about why I said don't both with this - https://review.openstack.org/#/c/424730/12/projects/60_nova/resources.sh@136 at the moment
16:51:17 cdent sdague: I hadn't made any comments with respect to that?
16:51:37 sdague cdent: ok, well a bunch of the superdan cross comments were about that
16:51:45 johnthetubaguy cdent: figleaf: the bit I don't understand, is who make allocations for ironic instances, making use of the new resource class
16:51:46 sdague anyway, lunch, biab
16:51:58 cdent johnthetubaguy: nobody
16:52:07 cdent which is why the old allocations will never be cleaned up
16:52:19 cdent because InventoryInUse will never get raised
16:52:26 mriedem jroll: CUSTOM_LOL eh
16:52:32 johnthetubaguy cdent: figleaf: it looks like we still trying to make the old style allocations in the resource tracker
16:53:05 johnthetubaguy cdent: figleaf: which should fail I assume, as that resource class isn't present for that resource provider any more
16:53:16 superdan sdague: if you mean cross in the "unhappy" sense, you're misinterpreting my exhaustion
16:53:38 cdent I think it was "cross" as in "interleaved"
16:53:42 openstackgerrit John Garbutt proposed openstack/nova: Scheduler calling the Placement API https://review.openstack.org/417961
16:53:49 superdan sdague: I think that check should be in there given the requirement we're adding that it be right at scheduler start, but I'm okay to wait until later if you think it's best
16:53:52 superdan cdent: okay, cool
16:54:28 cdent johnthetubaguy: why are they not there anymore? (not asserting they are, just tracing your thought process)
16:55:00 openstackgerrit Stephen Finucane proposed openstack/nova: console: Move proxies to 'console/proxy' https://review.openstack.org/408192
16:55:03 johnthetubaguy cdent: because the code now only creates inventory entires for the new custom resource class
16:56:05 figleaf johnthetubaguy: existing ironic nodes won't have the custom resource class set
16:56:09 cdent johnthetubaguy: so if a new ironic thing comes into existence, with a defined, resource class, that's when we run into trouble?
16:56:18 figleaf johnthetubaguy: so they'll get handled like they were vms
16:56:21 johnthetubaguy cdent: yes
16:56:34 figleaf johnthetubaguy: ah
16:56:59 figleaf johnthetubaguy: so your concern is that we don't have the ironic-aware bits to select a resource provider?
16:57:06 mriedem andreykurilin: your upper-constraints dreams have come true https://review.openstack.org/#/c/426116/5/upper-constraints.txt@332
16:57:25 openstackgerrit Sarafraj Singh proposed openstack/nova: Adopts keystoneauth with glance client. https://review.openstack.org/412634
16:57:25 andreykurilin mriedem: \o/
16:57:46 johnthetubaguy figleaf: ish, its basically that this method will fail (looking for link)
16:58:45 johnthetubaguy figleaf: ah, so this will fail, when there is a new style ironic resource provider being used by a new instance that is created: https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L664
16:58:50 johnthetubaguy figleaf: at least I think it will
16:58:51 openstackgerrit Sarafraj Singh proposed openstack/nova: Adopts keystoneauth with glance client. https://review.openstack.org/412634
16:58:55 sfinucan Interesting problem here - I've backported a bugfix that's exposed a latent Python 3 issue in the code https://review.openstack.org/#/c/425087
16:59:11 johnthetubaguy figleaf: cdent: maybe a quick google hangout would make this easier to talk through?
16:59:14 sfinucan Wonder if I should fix the Python 3 issue or drop the test?
17:01:48 figleaf johnthetubaguy: maybe, but I'm switching context to follow the code through the different parts
17:02:16 figleaf johnthetubaguy: I can't keep it all straight while working on something else :)
17:02:23 johnthetubaguy figleaf: no worries, it took me a good while to trace all that back too
17:05:45 superdan sdague: I have to merge something in devstack to make grenade consider a new projects/XX_thing plugin?
17:06:32 cdent johnthetubaguy: will objects.InstanceList.get_by_host_and_node return ironic things?
17:06:54 johnthetubaguy cdent: I believe it does
17:07:22 superdan cdent: it'll return ironic instances yeah
17:07:56 cdent k, thanks johnthetubaguy and superdan, trying to properly trace the code (as figleaf said, is meandering...)
17:09:01 superdan sdague: oh, nm I think i see
17:12:01 openstackgerrit John Garbutt proposed openstack/nova: Scheduler calling the Placement API https://review.openstack.org/417961
17:12:02 openstackgerrit John Garbutt proposed openstack/nova: Block starting compute unless placement conf is provided https://review.openstack.org/425806
17:13:13 mriedem johnthetubaguy: ah i see you updated it :)
17:13:19 mriedem was just leaving comments, will finish that up on the older PS
17:13:46 johnthetubaguy mriedem: hopefully, that was a rebase, but I think it was superdan 's change that failed to merge, but never mind
17:15:57 mriedem johnthetubaguy: just posted comments in PS36
17:16:37 jroll mriedem: sure why not :P
17:16:55 johnthetubaguy mriedem: I thought I had removed all that :S
17:17:50 mriedem johnthetubaguy: want to update the wording on https://review.openstack.org/#/c/425806/4/nova/exception.py ?
17:17:53 mriedem while you're at it
17:18:31 johnthetubaguy mriedem: aye
17:18:43 figleaf johnthetubaguy: cdent: so update_instance_allocation() should only be called for "old-style" allocations. create_provider_allocations() should be called for "new-style" (i.e., ironic with custom RC)
17:19:15 superdan mriedem: johnthetubaguy I'm going to avoid rechecking the nova scheduler patch until I have reasonable faith in the refactor to move placement into its own top-level
17:19:16 superdan just FYI
17:19:43 jroll More than one endpoint exists with the name 'placement'. <- not cool, devstack, not cool
17:19:56 figleaf johnthetubaguy: cdent: what it looks like is that we need to make sure that the update_instance_allocation() calls are all checked to make sure that they aren't called for new ironic nodes
17:20:19 mriedem johnthetubaguy: i'll go through PS38 too
17:20:36 johnthetubaguy figleaf: but there are no new calls right now, so surely we need someone to claim the new resource class?
17:21:36 figleaf johnthetubaguy: I only see two places where update_instance_allocations() is called in the RT.
17:21:44 johnthetubaguy figleaf: I would rather update_instance_allocation() was able to know from the instance what resources it should be claiming, and it just claims the correct ones, for now thats a bit hard coded I guess, but eventually its the same logic the scheduler has to do when requesting the correct resource class
17:22:24 figleaf johnthetubaguy: yeah, this is all transitional code
17:22:59 figleaf johnthetubaguy: we wanted to get ironic handled before we are able to handle all types of RPs
17:23:21 figleaf johnthetubaguy: can you think of a test that would fail now with ironic?
17:23:42 johnthetubaguy figleaf: add resource class on ironic node, boot instance that will land there, resource claim fails
17:23:50 johnthetubaguy figleaf: at least, thats the way it looks to me
17:23:56 cdent figleaf, johnthetubaguy my read of the code in the rt ironic inventory patch is that johnthetubaguy is right: it is possible to reache update_instance_allocation with a compute node and an instance and depending on what "compute_node" is, the allocations will either fail, or apply to the nova-compute node, incorrectly
17:24:19 cdent because the data at that point is about resource usages (vcpu etc)
17:24:49 johnthetubaguy yeah, instead of allocating for vcpu, it should be for the custom resource class, I think
17:25:21 cdent which should mean that the ironic "instance" is not include in the loop that is calling update_instance_allocation
17:25:21 johnthetubaguy oh balls...
17:25:27 cdent because it isn't really an instance
17:25:36 cdent (in that context)
17:25:45 johnthetubaguy if we merge the code to query placement, we will never land on an iroinc node in the first place, unless it is reporting VCPU resources
17:26:02 figleaf johnthetubaguy: that's a known issue
17:26:11 cdent "oh balls" means we've passed the "bugger" state of affairs
17:26:23 johnthetubaguy cdent: heh, ack
17:26:25 figleaf johnthetubaguy: which is why ironic has to keep reporting vm-type resources until Pike

Earlier   Later