<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">Hello, </div><div class="gmail_quote"><br></div><div class="gmail_quote">On Tue, Mar 3, 2015 at 6:12 PM, Evgeniy L <span dir="ltr"><<a href="mailto:eli@mirantis.com" target="_blank">eli@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Solution [3] is to implement plugin manager as a separate service</div><div>and move all of the complexity there, fuelclient will be able to use</div><div>REST API to install/delete/update/downgrade plugins.</div><div>In the same way as it's done for OSTF.</div></blockquote><div> </div><div>I remember that such manager was discussed, but cant recall all details.</div><div>So, can you please provide more information on what that manager will be doing?</div><div><br></div><div>If it is going to reimplement code that is added into fuel client, than i think it should not be a separate service,</div><div>but another kind of deffered task that will be executed by orchestrator.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div></div><div>The only technical question which I have is how are we going to</div><div>install the packages from the container on the host system, ssh?</div></blockquote></div><br>If we want to add some complexity to plugin manager, and lets say install additional packages in nailgun container, ostf</div><div class="gmail_extra">container - than ssh will not be enough, and probably we need rpc agent in each of those containers. </div><div class="gmail_extra">But I would prefer not to mess with container state at all, and if we are going to provide extension to nailgun/other services code</div><div class="gmail_extra">than it is a time to raise a question about going away from docker once again. </div></div>