<p dir="ltr">And fwiw I think the plan of starting small with db writes and building up us the right one. But I wonder about the requirement of a new service. For cleanliness I like separating into a new service but for ease of deployment it seems far easier to make this a part of nova-scheduler.</p>

<div class="gmail_quote">On Nov 12, 2012 1:03 PM, "Vishvananda Ishaya" <<a href="mailto:vishvananda@gmail.com">vishvananda@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">nova-conductor is what I've always called this service in my head.</p>
<p dir="ltr">Vish</p>
<p dir="ltr">On Nov 12, 2012 12:36 PM, "Russell Bryant" <<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>> wrote:<br>
><br>
> On 11/12/2012 01:59 PM, Joe Gordon wrote:<br>
> ><br>
> ><br>
> > On Mon, Nov 12, 2012 at 5:57 AM, Russell Bryant <<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a><br>
> > <mailto:<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>>> wrote:<br>
> ><br>
> >     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<br>
> >     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<br>
> >     wish<br>
> >     >> to execute some sort of compute action.  For example, instead of<br>
> >     >> directly asking nova-compute to complete a long running<br>
> >     operation, the<br>
> >     >> nova-compute-proxy would take this operation and monitor its<br>
> >     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<br>
> >     (like<br>
> >     > nodes -> compute), I think "proxy" is a bit reductive.<br>
> >     nova-controller ?<br>
> ><br>
> >     nova-controller is fine with me ... naming is hard.<br>
> ><br>
> ><br>
> > the term 'controller' is already heavily used, with over 1k uses.<br>
> ><br>
> > how about something along the lines alone of:<br>
> ><br>
> > * nova-supervisor<br>
> > * nova-commandor<br>
> > * nova-director<br>
> > * nova-maestro<br>
><br>
> It may be heavily used, but it does make sense (at least to me).  Let's<br>
> not bikeshed too much over the name.<br>
><br>
> The direction where we're taking the architecture is the key to this<br>
> discussion.  It's easy to make changes to the plan right now.  It won't<br>
> be long before the cost of change will go *way* up.<br>
><br>
> --<br>
> Russell Bryant<br>
><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>
</p>
</blockquote></div>