Open Stack

I'd actually prefer to see this new service named 'nova-compute'. :)   (And find another name for the current nova-compute).  But I realize that probably creates a lot of headaches. ;)

- Chris


On Nov 12, 2012, at 11:05 AM, Nathanael Burton <nathanael.i.burton at gmail.com> wrote:

> We are talking about a service that talks to the database, right?
> 
> nova-db?
> nova-dbproxy?
> 
> I agree that 'controller' is quite heavily used to mean different things and might be more confusing for new people.
> 
> Nate
> 
> On Nov 12, 2012 2:00 PM, "Joe Gordon" <jogo at cloudscaling.com> wrote:
> 
> 
> On Mon, Nov 12, 2012 at 5:57 AM, Russell Bryant <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
> 
> 
> best,
> Joe 
>  
> 
> > Otherwise my main gripe with it would be that this new service would be
> > compute-node-oriented, whereas the "nova-sink" approach was a bit more
> > generic (could one day be called by other nodes to access DB). But I
> > suspect you had the choice between the two approaches covered in the
> > summit session I missed :)
> >
> 
> I suppose if it wasn't called "nova-compute-proxy" it's not artificially
> limited to compute.  It could still be used for those other things.
> 
> The proposal in the summit session was nova-sink.  The feedback wasn't
> that it was bad, but just that it didn't do enough.  Folks wanted a path
> that would allow us to continue to do some more drastic work to
> nova-compute, such as orchestrating long running tasks from a single
> place so we can more easily ensure forward progress.
> 
> What I'm proposing now is something not called "nova-sink" but looks
> just like it in the short term, but extending it to orchestrate more
> complex compute operations in the medium term.  We need to make sure
> choices made now are not in conflict with the medium term plan.
> 
> --
> Russell Bryant
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> 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/0fc93f93/attachment.html>