Open Stack

On Nov 12, 2012 1:03 PM, "Vishvananda Ishaya" wrote:
> nova-conductor is what I've always called this service in my head.

Works for me.

By decree of the nova PTL, the service formerly known as
nova-compute-proxy, and before that formerly known as nova-sink, is now
known as nova-conductor.

(The Aeolus guys will love this, since they have a component named
conductor. [1])

On 11/12/2012 04:12 PM, Vishvananda Ishaya wrote:
> And fwiw I think the plan of starting small with db writes and building
> up us the right one. But I wonder about the requirement of a new
> service. For cleanliness I like separating into a new service but for
> ease of deployment it seems far easier to make this a part of
> nova-scheduler.

Thanks.  I see your point about deployment complexity.  It worries me,
too.  So, let's think about the "expand nova-scheduler" option a bit.

>From a technical perspective, it would be pretty easy.  We even have
infrastructure set up so that a single service can serve up more than
one rpc API, so the different functions could be well separated in the
code.  It already needs db access, and it is already isolated from
direct contact from the most untrusted parts of the system (public to
the world APIs, guest VMs).

So what are the downsides?  The main one I can think of is *conceptual*
complexity.  nova-scheduler has very well defined scope.  However, if
you just think of scheduling as one of many high level compute
operations, it also makes sense as a part of a nova-conductor.

The only other downside I can think of is the name.  The name
"nova-scheduler" would no longer reflect its scope.

I'll continue mulling over this ...

[1] http://www.aeolusproject.org/about.html

-- 
Russell Bryant