[openstack-dev] [Nova] Concerns around the Extensible Resource Tracker design - revert maybe?

Nikola Đipanov ndipanov at redhat.com
Fri Aug 15 06:10:50 UTC 2014


On 08/14/2014 10:25 PM, Sylvain Bauza wrote:
> Hi mikal,
> 
> Le 14 août 2014 01:49, "Michael Still" <mikal at stillhq.com
> <mailto:mikal at stillhq.com>> a écrit :
>>
>> So, there's been a lot of email in the last few days and I feel I am
>> not keeping up.
>>
>> Sylvain, can you summarise for me what the plan is here? Can we roll
>> forward or do we need to revert?
> 
> Well, as we agreed with Nikola, the problem is not with ERT but RT, as
> the request data needs to be passed when claiming a resource.
> 
> I'm proposing to keep ERT and only consider plugins that are not needing
> request_spec when claiming, but here there is no agreement yet.
> 

Yes - we could do this, I still see no benefit in this.

FWIW - Jay Pipes made a comment that highlights much of the same issues
I did in this thread even before I started it, on the patch itself
(scroll down).

https://review.openstack.org/#/c/109643/

It's easy to miss since it was added post merge.

> Unfortunately, I'm on PTO till Tuesday, and Paul Murray this week as
> well. So I propose to delay the discussion by these days as that's not
> impacted by FPF.
> 
> In the meantime, I created a patch for discussing a workaround [1] for
> Juno until we correctly figure out how to fix that issue, as it deserves
> a spec.
> 
>> Time is running out for Juno.
>>
> 
> Indeed, I'm mostly concerned by the example exception spec that Nikola
> mentioned [2] (isolate-scheduler-db) as it still needs a second +2 while
> FPF is in 1 week...
> I'm planning to deliver an alternative implementation without ERT wrt
> this discussion.
> 

Ripping it out will make it more difficult for the Gantt team to go
ahead with the current plan for the split - yes, but maybe that actually
means you might want to re-visit some of your decision (did not follow
all of it, so don't want to comment in depth at this point, but throwing
it out there)?

N.

> -Sylvain
> 
> [1] https://review.openstack.org/#/c/113936/
> 
> [2] https://review.openstack.org/#/c/89893
> 
>> Thanks,
>> Michael




More information about the OpenStack-dev mailing list