<div dir="ltr">Hi Andrew,<div><br></div><div>Comments inline.</div><div>Also could you please provide a link on OpenStack upgrade feature?</div><div>It's not clear why do you need it as a plugin and how you are going</div><div>to deliver this feature.</div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Nov 22, 2014 at 4:23 AM, Andrew Woodward <span dir="ltr"><<a href="mailto:xarses@gmail.com" target="_blank">xarses@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">So as part of the pumphouse integration, I've started poking around<br>
the Plugin Arch implementation as an attempt to plug it into the fuel<br>
master.<br>
<br>
This would require that the plugin install a container, and some<br>
scripts into the master node.<br>
<br>
First look:<br>
I've looked over the fuel plugins spec [1] and see that the install<br>
script was removed from rev 15 ->16 (line 134) This creates problems<br>
do to the need of installing the container, and scripts so I've<br>
created a bug [2] for this so that we can allow for an install script<br>
to be executed prior to HCF for 6.0.<br></blockquote><div><br></div><div>Yes, it was removed, but nothing stops you from creating the install</div><div>script and putting it in tarball, you don't need any changes in the</div><div>current implementation.</div><div><br></div><div>The reasons why it was done this way, see in separate mailing thread [1].</div><div><br></div><div>[1] <a href="http://lists.openstack.org/pipermail/openstack-dev/2014-October/049073.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2014-October/049073.html</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Looking into the implementation of the install routine [3] to<br>
implement [2], I see that the fuelclient is extracting the tar blindly<br>
(more on that at #3) on the executor system that fuelclient is being<br>
executed from. Problems with this include 1) the fuelclient may not<br>
root be privileged (like in Mirantis OpenStack Express) 2) the<br>
fuelclient may not be running on the same system as nailgun 3) we are<br>
just calling .extractall on the tarball, this means that we haven't<br>
done any validation on the files coming out of the tarball. We need to<br>
validate that 3.a) the tarball was actually encoded with the right<br>
base path 3.b) that the tasks.yaml file is validated and all the noted<br>
scripts are found. Really, the install of the plugin should be handled<br>
by the nailgun side to help with 1,2.<br></blockquote><div><br></div><div>1. if you have custom installation you have to provide custom permissions</div><div> for /var/www/nailgun/plugins directory</div><div>2. you are absolutely right, see the thread from above why we decided to add</div><div> this feature even if it was a wrong decision from architecture point of view</div><div>3. "haven't done any validation" - not exactly, validation is done on plugin</div><div> building stage, also we have simple validation on plugin installation stage on</div><div> Nailgun side (that data are consistent from nailgun point of view). There are</div><div> several reasons why it was done mainly on fuel-plugin-builder side:</div><div> a. plugin is validated before it's installed (it dramatically simplifies development)</div><div> b. also you can check that plugin is valid without plugin building,</div><div> use 'fpb --check fuel_plugin_name' parameter</div><div> c. faster fixes delivery, if there is a bug in validation (we had several of them</div><div> during the development in fuel-plugin-builder), we cannot just release new</div><div> version of fuel, but we can do it with fuel-plugin-builder, we had 2 releases [1].</div><div> For more complicated structures you will have bugs in validation for sure.</div><div> d. if we decide to support validations on both sides, we will come up with a lot of bugs</div><div> which are related to desynchronization of validators between Nailgun and fuel-plugin-builder</div><div><br></div><div>[1] <a href="https://github.com/stackforge/fuel-plugins/blob/master/fuel_plugin_builder/CHANGELOG.md">https://github.com/stackforge/fuel-plugins/blob/master/fuel_plugin_builder/CHANGELOG.md</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Whats next?<br>
There are many parts of PA that need to be extended, I think that<br>
these are the ones that we must tackle next to cover the most cases<br>
a) plugin packaging: it appears that non of the "core plugins" (those<br>
in fuel-plugins) are bundled into the iso.<br>
b) plugin signing: we cant have "core plugins" with out some method of<br>
testing, certifying, and signing them so that we can know that they<br>
are trusted.<br>
<br>
with the help of granular roles:<br>
c) the ability to replace or add new granular roles<br>
d) the ability to add or modify real roles<br>
<br>
with the help of advanced networks:<br>
e) add new network roles<br>
<br>
At some point soon, we also need to discuss making it easier to find a<br>
catalog of modules and pull them from it, but this is less important<br>
than the above<br>
<br>
[1] <a href="https://review.openstack.org/#/c/125608/15..16/specs/6.0/cinder-neutron-plugins-in-fuel.rst" target="_blank">https://review.openstack.org/#/c/125608/15..16/specs/6.0/cinder-neutron-plugins-in-fuel.rst</a><br>
[2] <a href="https://bugs.launchpad.net/fuel/+bug/1395228" target="_blank">https://bugs.launchpad.net/fuel/+bug/1395228</a><br>
[3] <a href="https://github.com/stackforge/fuel-web/blob/master/fuelclient/fuelclient/objects/plugins.py#L49" target="_blank">https://github.com/stackforge/fuel-web/blob/master/fuelclient/fuelclient/objects/plugins.py#L49</a><br>
<span><font color="#888888"><br>
--<br>
Andrew<br>
Mirantis<br>
Ceph community<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>
</font></span></blockquote></div><br></div></div>