Open Stack

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