Open Stack

On 12 July 2014 05:07, Jay Pipes <jaypipes at gmail.com> wrote:
> On 07/11/2014 07:14 AM, John Garbutt wrote:
>> While I am not against moving the resource tracker, I feel we could
>> move this to Gantt after the core scheduling has been moved.
>
> Big -1 from me on this, John.
>
> Frankly, I see no urgency whatsoever -- and actually very little benefit
> -- to moving the scheduler out of Nova. The Gantt project I think is
> getting ahead of itself by focusing on a split instead of focusing on
> cleaning up the interfaces between nova-conductor, nova-scheduler, and
> nova-compute.
>
> I see little to no long-term benefit in splitting the scheduler --
> especially with its current design -- out from Nova. It's not like
> Neutron or Cinder, where the split-out service is providing management
> of a particular kind of resource (network, block storage). The Gantt
> project isn't providing any resource itself. Instead, it would be acting
> as a proxy for the placement other services' resources, which, IMO, in
> and of itself, is not a reason to go through the trouble of splitting
> the scheduler out of Nova.

I am thinking about scaling out the Nova community here.

I like the idea of a smaller sub-community, outside of the Nova review
queue, that focus its efforts of moving the scheduler forward. I was
hoping we get Gantt created by the end of Juno, with nova-scheduler
deprecated at the end of Juno, as is. Then the Gantt community can
start evolving the current system.

We have blocked lots of ideas, saying please wait for Gantt. The
people wanting to have scheduling that is aware of both nova and
cinder resources, and similar arguments for networking locality aware
compute scheduling, and the ones that come to mind.

Clearly there is a cost of evolving the interface, once the scheduler
is split out. Maybe in this case we want to wait, and I am cool with
that, but I wanted to make sure we have our eyes open to what we are
delaying.

>> I was imagining the extensible resource tracker to become (sort of)
>> equivalent to cinder volume drivers.
>
> The problem with the extensible resource tracker design is that it,
> again, just shoves a bunch of stuff into a JSON field and both the
> existing resource tracker code (in nova-compute) as well as the
> scheduler code (in nova-scheduler) then need to use and abuse this BLOB
> of random data.
>
> I tried to make my point on the extensible resource tracker blueprint
> about my objections to the design.
>
> My first, and main, objection is that there was never demonstrated ANY
> clear use case for the extensibility of resources that was not already
> covered by the existing resource tracker and scheduler. The only "use
> case" was a vague "we have out of tree custom plugins that depend on
> divergent behaviour and therefore we need a plugin point to change the way
> the scheduler thinks of a particular resource." And that is not a use case.
> It's simply a request to break compatibility between clouds with out-of-tree
> source code.
...
> please somebody explain a clear use case for these things
> that does not involve "we want to run our divergent code".

To be clear, I have no interest in making life easier for out of tree
extensions.

One reason I like it, is because the code is becoming unwieldy as we
keep extending what people would like to report, and what was proposed
seemed very like a nice version of the Open Closed principle.

Another use case I want to see is to allow deployers to reduce the
data each compute node is reporting to the scheduler down the bare
minimum for what is required in the configured scheduler filters and
weights. This, coupled with the work of only sending deltas rather
than all the data all the time, sound really help reduce the DB load
generated by the host reporting.

We also urgently need to version the data, and the above refactoring,
assuming it was quick, I hoped would help us more clearly see where to
add in the versioning. In the end this has now just delayed that
effort, and thats a probably the biggest looser in this whole debate.

Agreed, these are all quite short term goals, and maybe there are
better ways of achieving those goals.

I intensely dislike the current complexly of the configuration, but I
have not had any time to suggest a viable alternative yet. The only
thing that popped into my head, is that moving the resource tracker to
the scheduler would really help, because you end up getting a single
model with related filter vs weight and reporter pairs, or something
like that. With the idea of combining filters and weights into a
single system, where you can weight and/or filter on based on some
property reported form the Resource Tracker.

>> Also the persistent resource claims will give us another plugin point
>> for gantt. That might not be enough, but I think it easier to see
>> once the other elements have moved.
>
> Is there some code you can provide me a link to for these persistent
> resource claims? Not sure I've seen that code yet... or a blueprint?

http://git.openstack.org/cgit/openstack/nova-specs/tree/specs/juno/persistent-resource-claim.rst

> As for the idea that things will get *easier* once scheduler code is
> broken out of Nova, I go back to my original statement that I don't
> really see the benefit of the split at this point, and I would just
> bring up the fact that Neutron/nova-network is a shining example of how
> things can easily backfire when splitting of code is done too early
> before interfaces are cleaned up and responsibilities between internal
> components are not clearly agreed upon.

I am thinking more about the Cinder approach here.

Create a smaller community that can iterate through the ideas faster
than you could inside Nova.

As for nova-network, I would love to see a group of people work hard
to split that out, similar to Cinder, and evolve a better interface
between nova and nova-network, then work to move neutron integration
over to that new interface. But yeah, I have lots of silly ideas.

> I don't think we should be afraid to change course on the Gantt effort
> just because we've talked about (and agreed in the past) to a split for
> a long time now.

Agreed.

I just don't want to "throw out the baby with the bath water".
(Honestly that is a common saying in the UK, for exactly this situation!)

Thanks,
John