<br><br><div class="gmail_quote">On Mon, Nov 12, 2012 at 5:57 AM, Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">On 11/12/2012 05:54 AM, Thierry Carrez wrote:<br>
> Russell Bryant wrote:<br>
>> This service would act as a proxy for nova-compute in a couple of ways.<br>
>><br>
>> 1) The nova-compute service would use it as a proxy to accomplish<br>
>> certain tasks, such as targeted operations that need database access.<br>
>><br>
>> 2) Over time, it would be used as a proxy for other services that wish<br>
>> to execute some sort of compute action.  For example, instead of<br>
>> directly asking nova-compute to complete a long running operation, the<br>
>> nova-compute-proxy would take this operation and monitor its progress.<br>
><br>
> I'm not convinced nova-compute-proxy is the best name for this. It's a<br>
> bit of a mouthful and IMHO proxying has a "one-way" meaning into it...<br>
> If the proxying was only in one direction (compute -> db) that would<br>
> make perfect sense but if you add other more complex abstractions (like<br>
> nodes -> compute), I think "proxy" is a bit reductive. nova-controller ?<br>
<br>
</div>nova-controller is fine with me ... naming is hard.<br></blockquote><div><br></div><div>the term 'controller' is already heavily used, with over 1k uses.</div><div><br></div><div>how about something along the lines alone of:</div>

<div><br></div><div>* nova-supervisor</div><div>* nova-commandor</div><div>* nova-director</div><div>* nova-maestro</div><div><br></div><div><br></div><div>best,</div><div>Joe </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div class="im"><br>
> Otherwise my main gripe with it would be that this new service would be<br>
> compute-node-oriented, whereas the "nova-sink" approach was a bit more<br>
> generic (could one day be called by other nodes to access DB). But I<br>
> suspect you had the choice between the two approaches covered in the<br>
> summit session I missed :)<br>
><br>
<br>
</div>I suppose if it wasn't called "nova-compute-proxy" it's not artificially<br>
limited to compute.  It could still be used for those other things.<br>
<br>
The proposal in the summit session was nova-sink.  The feedback wasn't<br>
that it was bad, but just that it didn't do enough.  Folks wanted a path<br>
that would allow us to continue to do some more drastic work to<br>
nova-compute, such as orchestrating long running tasks from a single<br>
place so we can more easily ensure forward progress.<br>
<br>
What I'm proposing now is something not called "nova-sink" but looks<br>
just like it in the short term, but extending it to orchestrate more<br>
complex compute operations in the medium term.  We need to make sure<br>
choices made now are not in conflict with the medium term plan.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Russell Bryant<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br>