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