<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 12 December 2014 at 22:18, Ryu Ishimoto <span dir="ltr"><<a href="mailto:ryu@midokura.com" target="_blank">ryu@midokura.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div>Hi All,</div><div><br></div><div>It's great to see the vendor plugin decomposition spec[1] finally getting merged!  Now that the spec is completed, I have a question on how this may impact neutronclient, and in particular, its handling of vendor extensions.</div></div></blockquote><div><br></div><div>Thanks for the excitement :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>One of the great things about splitting out the plugins is that it will allow vendors to implement vendor extensions more rapidly.  Looking at the neutronclient code, however, it seems that these vendor extension commands are embedded inside the project, and doesn't seem easily extensible.  It feels natural that, now that neutron vendor code is split out, neutronclient should also do the same.</div><div><br></div><div>Of course, you could always fork neutronclient yourself, but I'm wondering if there is any plan on improving this.  Admittedly, I don't have a great solution myself but I'm thinking something along the line of allowing neutronclient to load commands from an external directory.  I am not familiar enough with neutronclient to know if there are technical limitation to what I'm suggesting, but I would love to hear thoughts of others on this.</div></div></blockquote><div><br></div><div>There is quite a bit of road ahead of us. We haven't thought or yet considered how to handle extensions client side. Server side, the extension mechanism is already quite flexible, but we gotta learn to walk before we can run!<br></div><div><br></div><div>Having said that your points are well taken, but most likely we won't be making much progress on these until we have provided and guaranteed a smooth transition for all plugins and drivers as suggested by the spec referenced below. Stay tuned!</div><div><br></div><div>Cheers,</div><div>Armando</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Thanks in advance!</div><div><br></div><div>Best,</div><div>Ryu</div><div><br></div><div>[1] <a href="https://review.openstack.org/#/c/134680/" target="_blank">https://review.openstack.org/#/c/134680/</a></div></div>
<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></div></div>