<div dir="ltr">Hi all,<br><br>as you know, Rally runs inside docker on Fuel master node, so docker removal (good improvement) is a problem for Rally users.<br><br>To solve this, I'm planning to make native Rally installation on Fuel master node that is running on CentOS 7,<br>and then make a step-by-step instruction how to make this installation.<br><br>So I hope docker removal will not make issues for Rally users.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 23, 2015 at 12:28 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">ETA:<div><br></div><div>experimental ISO w/o docker: tonight</div><div>spec: tomorrow night</div><span class="HOEnZb"><font color="#888888"><div><br></div><div><br></div></font></span></div><div class="gmail_extra"><span class="HOEnZb"><font color="#888888"><br clear="all"><div><div><div>Vladimir Kozhukalov</div></div></div></font></span><div><div class="h5">
<br><div class="gmail_quote">On Mon, Nov 23, 2015 at 9:25 AM, Anastasia Urlapova <span dir="ltr"><<a href="mailto:aurlapova@mirantis.com" target="_blank">aurlapova@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>@Vova, </div><div>thanks for bringing this up. </div><div>The new approach without docker containers on master node really has many advantages. </div><div><br></div><div><div><span style="font-size:12.8px">@Igor,</span></div><div><span style="font-size:12.8px">regarding your question, I would say that we have many dependencies from containers in CI/CD systems and test's codebase. The test alignment to the new implementation won't be easy. In such things we should move forward step by step.</span></div><div><span style="font-size:12.8px">As you know the first step is a spec file, can you give us a link to it?</span></div></div><div><span style="font-size:12.8px"><br></span></div><div><br></div><div><span style="font-size:12.8px">Nastya.</span></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Nov 21, 2015 at 6:10 AM, Oleg Gelbukh <span dir="ltr"><<a href="mailto:ogelbukh@mirantis.com" target="_blank">ogelbukh@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">With CentOS7 we will have python2.7 at Fuel Admin node as a default version, I believe.<div><br></div><div>--</div><div>Best regards,</div><div>Oleg Gelbukh,</div><div>Principal Engineer</div><div>Mirantis</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 20, 2015 at 6:27 AM, Timur Nurlygayanov <span dir="ltr"><<a href="mailto:tnurlygayanov@mirantis.com" target="_blank">tnurlygayanov@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">Hi Andrey,<span><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"><span style="font-size:12.8000001907349px">As far as I remember from the last usage of fuel master node, there was Centos + py26 installation. Python 2.6 is old enough and sometimes it is hard to launch some application on fuel node without docker (image with py27/py3). Are you planning to provide py27 at least or my note is outdated and I can already use py27 from the box?</span></blockquote></span><div><span style="font-size:12.8000001907349px">We can install docker on master node anyway to run Rally / Tempest or other test suites and scripts from master node with Python 2.7 or something also.</span></div></div><div class="gmail_extra"><div><div><br><div class="gmail_quote">On Fri, Nov 20, 2015 at 5:20 PM, Andrey Kurilin <span dir="ltr"><<a href="mailto:akurilin@mirantis.com" target="_blank">akurilin@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">Hi!<br>I'm not fuel developer, so opinion below is based on user-view.<br>As far as I remember from the last usage of fuel master node, there was Centos + py26 installation. Python 2.6 is old enough and sometimes it is hard to launch some application on fuel node without docker (image with py27/py3). Are you planning to provide py27 at least or my note is outdated and I can already use py27 from the box?<br></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Thu, Nov 19, 2015 at 4:59 PM, Vladimir Kozhukalov <span dir="ltr"><<a href="mailto:vkozhukalov@mirantis.com" target="_blank">vkozhukalov@mirantis.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr"><div>Dear colleagues,</div><div><br></div><div>As might remember, we introduced Docker containers on the master node a while ago when we implemented first version of Fuel upgrade feature. The motivation behind was to make it possible to rollback upgrade process if something goes wrong. </div><div><br></div><div>Now we are at the point where we can not use our tarball based upgrade approach any more and those patches that deprecate upgrade tarball has been already merged. Although it is a matter of a separate discussion, it seems that upgrade process rather should be based on kind of backup and restore procedure. We can backup Fuel data on an external media, then we can install new version of Fuel from scratch and then it is assumed backed up Fuel data can be applied over this new Fuel instance. The procedure itself is under active development, but it is clear that rollback in this case would be nothing more than just restoring from the previously backed up data.</div><div><br></div><div>As for Docker containers, still there are potential advantages of using them on the Fuel master node, but our current implementation of the feature seems not mature enough to make us benefit from the containerization.</div><div><br></div><div>At the same time there are some disadvantages like</div><div><ul><li>it is tricky to get logs and other information (for example, rpm -qa) for a service like shotgun which is run inside one of containers. </li><li>it is specific UX when you first need to run dockerctl shell {container_name} and then you are able to debug something.</li><li>when building IBP image we mount directory from the host file system into mcollective container to make image build faster.</li><li>there are config files and some other files which should be shared among containers which introduces unnecessary complexity to the whole system.</li><li>our current delivery approach assumes we wrap into rpm/deb packages every single piece of the Fuel system. Docker images are not an exception. And as far as they depend on other rpm packages we forced to build docker-images rpm package using kind of specific build flow. Besides this package is quite big (300M).</li><li>I'd like it to be possible to install Fuel not from ISO but from RPM repo on any rpm based distribution. But it is double work to support both Docker based and package based approach. </li></ul><div>Probably some of you can give other examples. Anyway, the idea is to get rid of Docker containers on the master node and switch to plane package based approach that we used before. </div><div><br></div><div>As far as there is nothing new here, we just need to use our old site.pp (with minimal modifications), it looks like it is possible to implement this during 8.0 release cycle. If there are no principal objections, please give me a chance to do this ASAP (during 8.0), I know it is a huge risk for the release, but still I think I can do this.</div></div><span><font color="#888888"><div><br></div><div> </div><div><br></div><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><span><font color="#888888"><br><br clear="all"><br>-- <br><div><div dir="ltr">Best regards,<br>Andrey Kurilin.<br></div></div>
</font></span></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>-- <br></div></div><span><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><font color="#888888"><font color="#888888"><br></font></font><div style="font-family:arial;font-size:small">Timur,</div><div style="font-family:arial;font-size:small">Senior QA Engineer</div><div style="font-family:arial;font-size:small">OpenStack Projects</div><div style="font-family:arial;font-size:small">Mirantis Inc</div></div></div></div></div></div></div>
</span></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><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><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>
<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>