<div dir="ltr">I support this proposal but I just wanted to mention that we'll lose an easy way to develop manifests. I agree that manifests in this case have no difference with Neutron code, for instance. But anyway I +1 this, especially with Vova Kuklin's additions.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 10, 2015 at 12:25 PM, Vladimir Kuklin <span dir="ltr"><<a href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@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>Folks </div><div><br></div>I have a strong +1 for the proposal to decouple master node and slave nodes.<div>Here are the stregnths of this approach</div><div>1) We can always decide which particular node runs which particular set of manifests. This will allow us to do be able to apply/roll back changes node-by-node. This is very important from operations perspective.</div><div>2) We can decouple master and slave nodes manifests and not drag new library version onto the master node when it is not needed. This allows us to decrease probability of regressions</div><div>3) This makes life easier for the user - you just run 'apt-get/yum install' instead of some difficult to digest `mco` command.<br><div><br></div><div>The only weakness that I see here is on mentioned by Andrey. I think we can fix it by providing developers with clean and simple way of building library package on the fly. This will make developers life easier enough to work with proposed approach.</div><div><br></div><div>Also, we need to provide ways for better UX, like provide one button/api call for:</div><div><br></div><div>1) update all manifests on particular nodes (e.g. all or only a part of nodes of the cluster) to particular version</div><div>2) revert all manifests back to the version which is provided by the particular GA release </div><div>3) <more things we need to think of></div><div><br></div><div>So far I would mark need for simple package-building system for developer as a dependency for the proposed change, but I do not see any other way than proceeding with it.<br><div><br></div><div><br></div></div></div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Thu, Sep 10, 2015 at 11:50 AM, Sergii Golovatiuk <span dir="ltr"><<a href="mailto:sgolovatiuk@mirantis.com" target="_blank">sgolovatiuk@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 dir="auto" style="word-wrap:break-word">Oleg,<div><br></div><div>Alex gave a perfect example regarding support folks when they need to fix something really quick. It's client's choice what to patch or not. You may like it or not, but it's client's choice.</div><div><div><div><br></div><div><div style="direction:ltr"><blockquote type="cite"><div>On 10 Sep 2015, at 09:33, Oleg Gelbukh <<a href="mailto:ogelbukh@mirantis.com" target="_blank">ogelbukh@mirantis.com</a>> wrote:</div><br><div><div dir="ltr">Alex,<div><br></div><div>I absolutely understand the point you are making about need for deployment engineers to modify things 'on the fly' in customer environment. It's makes things really flexible and lowers the entry barrier for sure.</div><div><br></div><div>However, I would like to note that in my opinion this kind on 'monkey patching' is actually a bad practice for any environments other than dev ones. It immediately leads to emergence of unsupportable frankenclouds. I would greet any modification to the workflow that will discourage people from doing that.</div><div><br></div><div>--</div><div>Best regards,</div><div>Oleg Gelbukh</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 9, 2015 at 5:56 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">Hey Vladimir,<div><br></div><div><div class="gmail_extra"><br><div class="gmail_quote"><span><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>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></blockquote><div><br></div></span><div>Don't get me wrong, I think it would be good to move to a fuel-library distributed via package only. I'm bringing these points up to indicate that there is many other things that live in the fuel library puppet path than just the fuel-library package. The plugin example is just one place that we will need to invest in further design and work to move to the package only distribution. What I don't want is some partially executed work that only works for one type of deployment and creates headaches for the people actually having to use fuel. The deployment engineers and customers who actually perform these actions should be asked about packaging and their comfort level with this type of requirements. I don't have a complete understanding of the all the things supported today by the fuel plugin system so it would be nice to get someone who is more familiar to weigh in on this idea. Currently plugins are only rpms (no debs) and I don't think we are building fuel-library debs at this time either. So without some work on both sides, we cannot move to just packages.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></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"><span><font color="#888888"><br clear="all"></font></span></div></blockquote><div><br></div></span><div>Yes, we do have a service like Perestroika to build packages for us. That doesn't mean everyone else does or has access to do that today. Setting up a build system is a major undertaking and making that a hard requirement to interact with our product may be a bit much for some customers. In speaking with some support folks, there are times when files have to be munged to get around issues because there is no package or things are on fire so they can't wait for a package to become available for a fix. We need to be careful not to impose limits without proper justification and due diligence. We already build the fuel-library package, so there's no reason you couldn't try switching the rsync to install the package if it's available on a mirror. I just think you're going to run into the issues I mentioned which need to be solved before we could just mark it done.</div><span><font color="#888888"><div><br></div><div>-Alex</div></font></span><span><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><span><font color="#888888"><div><div><div>Vladimir Kozhukalov</div></div></div></font></span><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><font color="#888888"><div><br></div><div>-Alex</div></font></span></div><div><div><div class="gmail_extra"><br></div></div></div></div></blockquote></div></div></div></div></blockquote></span></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>
__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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></blockquote></div><br></div></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"><div><br></div></div></div>-- <br><div><div dir="ltr"><div><div dir="ltr">Yours Faithfully,<br>Vladimir Kuklin,<br>Fuel Library Tech Lead,<br>Mirantis, Inc.<br>+7 (495) 640-49-04<br>+7 (926) 702-39-68<br>Skype kuklinvv<br>35bk3, Vorontsovskaya Str.<br>Moscow, Russia,<br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.com</a><br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.ru</a><br><a href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@mirantis.com</a></div></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>-- <br><div class="gmail_signature">Andrey Danin<br><a href="mailto:adanin@mirantis.com" target="_blank">adanin@mirantis.com</a><br>skype: gcon.monolake<br></div>
</div>