Open Stack

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121112/47aa473c/attachment.html>