Open Stack

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.
On Nov 12, 2012 1:03 PM, "Vishvananda Ishaya" <vishvananda at gmail.com> wrote:

> 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/875b0cdc/attachment.html>