Open Stack

nova-conductor is what I've always called this service in my head.

Vish

On Nov 12, 2012 12:36 PM, "Russell Bryant" <rbryant at redhat.com> wrote:
>
> On 11/12/2012 01:59 PM, Joe Gordon wrote:
> >
> >
> > On Mon, Nov 12, 2012 at 5:57 AM, Russell Bryant <rbryant at redhat.com
> > <mailto:rbryant at redhat.com>> wrote:
> >
> >     On 11/12/2012 05:54 AM, Thierry Carrez wrote:
> >     > Russell Bryant wrote:
> >     >> This service would act as a proxy for nova-compute in a couple of
> >     ways.
> >     >>
> >     >> 1) The nova-compute service would use it as a proxy to accomplish
> >     >> certain tasks, such as targeted operations that need database
access.
> >     >>
> >     >> 2) Over time, it would be used as a proxy for other services that
> >     wish
> >     >> to execute some sort of compute action.  For example, instead of
> >     >> directly asking nova-compute to complete a long running
> >     operation, the
> >     >> nova-compute-proxy would take this operation and monitor its
> >     progress.
> >     >
> >     > I'm not convinced nova-compute-proxy is the best name for this.
It's a
> >     > bit of a mouthful and IMHO proxying has a "one-way" meaning into
it...
> >     > If the proxying was only in one direction (compute -> db) that
would
> >     > make perfect sense but if you add other more complex abstractions
> >     (like
> >     > nodes -> compute), I think "proxy" is a bit reductive.
> >     nova-controller ?
> >
> >     nova-controller is fine with me ... naming is hard.
> >
> >
> > the term 'controller' is already heavily used, with over 1k uses.
> >
> > how about something along the lines alone of:
> >
> > * nova-supervisor
> > * nova-commandor
> > * nova-director
> > * nova-maestro
>
> It may be heavily used, but it does make sense (at least to me).  Let's
> not bikeshed too much over the name.
>
> The direction where we're taking the architecture is the key to this
> discussion.  It's easy to make changes to the plan right now.  It won't
> be long before the cost of change will go *way* up.
>
> --
> Russell Bryant
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121112/1b66c519/attachment.html>