<div dir="ltr">Alex, <div><br></div><div>Regarding plugins: plugins are welcome to install specific additional DEB/RPM repos on the master node, or just configure cluster to use additional onl?ne repos, where all necessary packages (including plugin specific puppet manifests) are to be available. Current granular deployment approach makes it easy to append specific pre-deployment tasks (master/slave does not matter). Correct me if I am wrong. </div><div><br></div><div>Regarding flexibility: having several versioned directories with puppet modules on the master node, having several fuel-libraryX.Y packages installed on the master node makes things "exquisitely convoluted" rather than flexible. Like I said, it is flexible enough to use mcollective, plain rsync, etc. if you really need to do things manually. But we have convenient service (Perestroika) which builds packages in minutes if you need. Moreover, In the nearest future (by 8.0) Perestroika will be available as an application independent from CI. So, what is wrong with building fuel-library package? What if you want to troubleshoot nova (we install it using packages)? Should we also use rsync for everything else like nova, mysql, etc.?</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div>Vladimir Kozhukalov</div></div></div>
<br><div class="gmail_quote">On Wed, Sep 9, 2015 at 4:39 PM, Alex Schultz <span dir="ltr"><<a href="mailto:aschultz@mirantis.com" target="_blank">aschultz@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 dir="ltr">I agree that we shouldn't need to sync as we should be able to just update the fuel-library package. That being said, I think there might be a few issues with this method. The first issue is with plugins and how to properly handle the distribution of the plugins as they may also include puppet code that needs to be installed on the other nodes for a deployment. Currently I do not believe we install the plugin packages anywhere except the master and when they do get installed there may be some post-install actions that are only valid for the master. Another issue is being flexible enough to allow for deployment engineers to make custom changes for a given environment. Unless we can provide an improved process to allow for people to provide in place modifications for an environment, we can't do away with the rsync.<div><br></div><div>If we want to go completely down the package route (and we probably should), we need to make sure that all of the other pieces that currently go together to make a complete fuel deployment can be updated in the same way. <span class="HOEnZb"><font color="#888888"><div><br></div><div>-Alex</div></font></span></div><div><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 9, 2015 at 8:15 AM, Andrey Danin <span dir="ltr"><<a href="mailto:adanin@mirantis.com" target="_blank">adanin@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 dir="ltr">I don't think juggling with repos and pull requests is easier than direct editing of files on Fuel node. Do we have Perestorika installed on Fuel node in 7.0?<br><div class="gmail_extra"><div><div><br><div class="gmail_quote">On Wed, Sep 9, 2015 at 3:47 PM, Vladimir Kozhukalov <span dir="ltr"><<a href="mailto:vkozhukalov@mirantis.com" target="_blank">vkozhukalov@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 dir="ltr"><div>Andrey, <br></div><div><br></div><div>This change is going to make things even easier. Currently you don't need to build fuel-library package manually, Perestroika is going to do it for you. It builds necessary packages during minutes for every review request and packaging ci even tests it for you. You just need to make necessary changes not on master node but on your MACBOOK using your favorite editor. Then you need to commit this change and send this patch on review. If you want to test this patch manually, you just need to append this CR repo (example is here [1]) to the list of repos you define for your cluster and start deployment. Anyway, you still have rsync, mcollective and other old plain tools to run deployment manually. </div><div class="gmail_extra"><br></div><div class="gmail_extra">[1] <a href="http://perestroika-repo-tst.infra.mirantis.net/review/CR-221719/" target="_blank">http://perestroika-repo-tst.infra.mirantis.net/review/CR-221719/</a></div><span><font color="#888888"><div><br></div><div class="gmail_extra"><br></div></font></span><div class="gmail_extra"><span><font color="#888888"><br clear="all"><div><div><div>Vladimir Kozhukalov</div></div></div></font></span><div><div>
<br><div class="gmail_quote">On Wed, Sep 9, 2015 at 2:48 PM, Dmitry Pyzhov <span dir="ltr"><<a href="mailto:dpyzhov@mirantis.com" target="_blank">dpyzhov@mirantis.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"><div dir="ltr">Vladimir,<div><br></div><div>thanks for bringing this up. It greatly correlates with the idea of modularity. Everything related to an openstack release should be put in one place and should be managed as a solid bundle on the master node. Package repository is the first solution that comes to the mind and it looks pretty good. Puppet modules, openstack.yaml and maybe even serialisers should be stored in packages in the openstack release repository. And eventually every other piece of our software should get rid of release-specific logic.</div></div><div class="gmail_extra"><br><div class="gmail_quote"><span>On Tue, Sep 8, 2015 at 11:41 PM, Vladimir Kozhukalov <span dir="ltr"><<a href="mailto:vkozhukalov@mirantis.com" target="_blank">vkozhukalov@mirantis.com</a>></span> wrote:<br></span><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><div dir="ltr"><div>Dear colleagues,</div><div><br></div><div>Currently, we install fuel-libraryX.Y package(s) on the master node and then right before starting actual deployment we rsync [1] puppet modules (one of installed versions) from the master node to slave nodes. Such a flow makes things much more complicated than they could be if we installed puppet modules on slave nodes as rpm/deb packages. Deployment itself is parameterized by repo urls (upstream + mos) and this pre-deployment task could be nothing more than just installing fuel-library package from mos repo defined for a cluster. We would not have several versions of fuel-library on the master node, we would not need that complicated upgrade stuff like we currently have for puppet modules.</div><div><br></div><div>Please give your opinions on this. </div><div><br></div><div><br></div><div>[1] <a href="https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/orchestrator/tasks_serializer.py#L205-L218" target="_blank">https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/orchestrator/tasks_serializer.py#L205-L218</a></div><span><font color="#888888"><br clear="all"><div><div><div>Vladimir Kozhukalov</div></div></div>
</font></span></div>
<br></div></div><span>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></span></blockquote></div><br></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><br></div></div><span>-- <br><div>Andrey Danin<br><a href="mailto:adanin@mirantis.com" target="_blank">adanin@mirantis.com</a><br>skype: gcon.monolake<br></div>
</span></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>