Open Stack

Sounds like an orchestrator to me :-P

Nova-orc ftw, ha.

On 11/12/12 1:27 PM, "Russell Bryant" <rbryant at redhat.com> wrote:

>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
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev