<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">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. ;)<div><br></div><div>- Chris<br><div><br></div><div><br><div><div>On Nov 12, 2012, at 11:05 AM, Nathanael Burton <<a href="mailto:nathanael.i.burton@gmail.com">nathanael.i.burton@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><p>We are talking about a service that talks to the database, right? </p><p>nova-db?<br>
nova-dbproxy?</p><p>I agree that 'controller' is quite heavily used to mean different things and might be more confusing for new people.</p><p>Nate </p>
<div class="gmail_quote">On Nov 12, 2012 2:00 PM, "Joe Gordon" <<a href="mailto:jogo@cloudscaling.com">jogo@cloudscaling.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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>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><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><font color="#888888"><br>
--<br>
Russell Bryant<br>
</font></span><div><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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></blockquote></div><br>
<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>
<br></blockquote></div>
_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br></blockquote></div><br></div></div></body></html>