<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 25, 2014 at 10:40 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"><span class="">On Mon, Nov 24, 2014 at 4:40 AM, Evgeniy L <<a href="mailto:eli@mirantis.com">eli@mirantis.com</a>> wrote:<br>
> Hi Andrew,<br>
><br>
> Comments inline.<br>
> Also could you please provide a link on OpenStack upgrade feature?<br>
> It's not clear why do you need it as a plugin and how you are going<br>
> to deliver this feature.<br>
><br>
> On Sat, Nov 22, 2014 at 4:23 AM, Andrew Woodward <<a href="mailto:xarses@gmail.com">xarses@gmail.com</a>> wrote:<br>
>><br>
>> 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>
><br>
><br>
> Yes, it was removed, but nothing stops you from creating the install<br>
> script and putting it in tarball, you don't need any changes in the<br>
> current implementation.<br>
<br>
</span>how would it be executed? the plugin loading done by fuel-client<br>
doesn't cover this.<br></blockquote><div><br></div><div>Manually untar and run your script, as it was designed before we implemented</div><div>more user friendly approach.</div><div><br></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">
<div><div class="h5"><br>
><br>
> The reasons why it was done this way, see in separate mailing thread [1].<br>
><br>
> [1]<br>
> <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><br>
><br>
>><br>
>><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>
><br>
><br>
> 1. if you have custom installation you have to provide custom permissions<br>
>     for /var/www/nailgun/plugins directory<br>
> 2. you are absolutely right, see the thread from above why we decided to add<br>
>     this feature even if it was a wrong decision from architecture point of<br>
> view<br>
> 3. "haven't done any validation" - not exactly, validation is done on plugin<br>
>     building stage, also we have simple validation on plugin installation<br>
> stage on<br>
>     Nailgun side (that data are consistent from nailgun point of view).<br>
> There are<br>
>     several reasons why it was done mainly on fuel-plugin-builder side:<br>
>       a. plugin is validated before it's installed (it dramatically<br>
> simplifies development)<br>
>       b. also you can check that plugin is valid without plugin building,<br>
>           use 'fpb --check fuel_plugin_name' parameter<br>
>       c. faster fixes delivery, if there is a bug in validation (we had<br>
> several of them<br>
>           during the development in fuel-plugin-builder), we cannot just<br>
> release new<br>
>           version of fuel, but we can do it with fuel-plugin-builder, we had<br>
> 2 releases [1].<br>
>           For more complicated structures you will have bugs in validation<br>
> for sure.<br>
>       d. if we decide to support validations on both sides, we will come up<br>
> with a lot of bugs<br>
>           which are related to desynchronization of validators between<br>
> Nailgun and fuel-plugin-builder<br>
<br>
</div></div>the main validation points that should be done by nailgun is to verify<br>
that the paths are correct. i.e.<br>
* the tar ./<folder> == metadata.yaml['name']<br>
* tasks.yaml + metadata.yaml refer to valid paths for "cmd",<br>
"deployment_scripts_path", "repository_path"<br>
<br>
Rright now there is no contract between the user building the plugin<br>
with fpb, vs adding all the files to a tarball. if fpb is supposed to<br>
be doing this, then there should be some form of signature that can be<br>
parsed to ensure that these items have been pre-validated and the<br>
package wasn't modified, or built by hand. Something that would be<br>
easy, and cheap would be something like 'cat metdata.yaml tasks.yaml |<br>
md5sum >md5sum' and validate this when we load the package. It also<br>
gives us a starting point for other signers.<br></blockquote><div><br></div><div>Do we really want to cover cases when somebody made a tar-ball manually</div><div>and gave it to a user without any testing?</div><div>I don't think so.</div><div><br></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>
Alternatly, we would use fpb to validate the package prior to<br>
installing it into nailgun.</blockquote><div><br></div><div>I'm not sure if it's a good option, fpb should not be included in the iso,</div><div>it has separate release cycle, we shouldn't increase the amount</div><div>of packages which we update during the upgrade, because of</div><div>rollback problems with packages which are not in the containers.</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">
<div class=""><div class="h5"><br>
><br>
> [1]<br>
> <a href="https://github.com/stackforge/fuel-plugins/blob/master/fuel_plugin_builder/CHANGELOG.md" target="_blank">https://github.com/stackforge/fuel-plugins/blob/master/fuel_plugin_builder/CHANGELOG.md</a><br>
><br>
>><br>
>><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]<br>
>> <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]<br>
>> <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>
>><br>
>> --<br>
>> Andrew<br>
>> Mirantis<br>
>> Ceph community<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>
><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>
<br>
<br>
<br>
--<br>
Andrew<br>
Mirantis<br>
Ceph community<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>
</div></div></blockquote></div><br></div></div>