<div dir="ltr">That's good to know, thank you, Vladimir, Dmitry.<div><br></div><div>--</div><div>Best regards,</div><div>Oleg Gelbukh</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 24, 2015 at 3:10 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>In fact, we (I and Dmitry) are on the same page of how to merge these two features (Centos7 and Docker removal). We agreed that Dmitry's feature is much more complicated and of higher priority. So, Centos 7 should be merged first and then I'll rebase my patches (mostly supervisor -> systemd).<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><div><br></div><div><br></div><div><br></div><div> </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 Tue, Nov 24, 2015 at 1:57 AM, Igor Kalnitsky <span dir="ltr"><<a href="mailto:ikalnitsky@mirantis.com" target="_blank">ikalnitsky@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey Dmitry,<br>
<br>
Thank you for your effort. I believe it's a huge step forward that<br>
opens number of possibilities.<br>
<span><br>
> Every container runs systemd as PID 1 process instead of<br>
> supervisord or application / daemon.<br>
<br>
</span>Taking into account that we're going to drop Docker containers, I<br>
think it was unnecessary complication of your work.<br>
<br>
Please sync-up with Vladimir Kozhukalov, he's working on getting rid<br>
of containers.<br>
<span><br>
> Every service inside a container is a systemd unit. Container build<br>
> procedure was modified, scripts setup.sh and start.sh were introduced<br>
> to be running during building and configuring phases respectively.<br>
<br>
</span>Ditto. :)<br>
<br>
Thanks,<br>
Igor<br>
<br>
P.S: I wrote the mail and forgot to press "send" button. It looks like<br>
Oleg is already pointed out that I wanted to.<br>
<div><div><br>
On Mon, Nov 23, 2015 at 2:37 PM, Oleg Gelbukh <<a href="mailto:ogelbukh@mirantis.com" target="_blank">ogelbukh@mirantis.com</a>> wrote:<br>
> Please, take into account the plan to drop the containerization of Fuel<br>
> services:<br>
><br>
> <a href="https://review.openstack.org/#/c/248814/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/248814/</a><br>
><br>
> --<br>
> Best regards,<br>
> Oleg Gelbukh<br>
><br>
> On Tue, Nov 24, 2015 at 12:25 AM, Dmitry Teselkin <<a href="mailto:dteselkin@mirantis.com" target="_blank">dteselkin@mirantis.com</a>><br>
> wrote:<br>
>><br>
>> Hello,<br>
>><br>
>> We've been working for some time on bringing CentOS-7 to master node,<br>
>> and now is the time to share and discuss the transition plan.<br>
>><br>
>> First of all, what have been changed:<br>
>> * Master node itself runs on CentOS-7. Since all the containers share<br>
>> the same repo as master node they all have been migrated to CentOS-7<br>
>> too. Every container runs systemd as PID 1 process instead of<br>
>> supervisord or application / daemon.<br>
>> * Every service inside a container is a systemd unit. Container build<br>
>> procedure was modified, scripts setup.sh and start.sh were introduced<br>
>> to be running during building and configuring phases respectively.<br>
>> The main reason for this was the fact that many puppet manifests use<br>
>> service management commands that require systemd daemon running. This<br>
>> also allowed to simplify Dockerfiles by removing all actions to<br>
>> setup.sh file.<br>
>> * We managed to find some bugs in various parts that were fixed too.<br>
>> * Bootstrap image is also CentOS-7 based. It was updated to better<br>
>> support it - some services converted to systemd units and fixes to<br>
>> support new network naming schema were made.<br>
>> * ISO build procedure was updated to reflect changes in CentOS-7<br>
>> distribution and to support changes in docker build procedure.<br>
>> * Many applications was updated (puppet, docker, openstack<br>
>> components).<br>
>> * Docker containers moved to LVM volume to improve performance and get<br>
>> rid of annoying warning messages during master node deployment.<br>
>> bootstrap_admin_node.sh script was updated to fix some deployment<br>
>> issues (e.g. dracut behavior when there are multiple network<br>
>> interfaces available) and simplified by removing outdated<br>
>> functionality. It was also converted to a "run once" logon script<br>
>> instead of being run as a service, primarily because of a way it's<br>
>> used.<br>
>><br>
>> As you can see there are a lot of changes were made. Some of them might<br>
>> be merged into current master if surrounded by conditionals to be<br>
>> compatible with current master node, but some of them simply can't.<br>
>><br>
>> To simplify the code review process we've splitted CRs that we were<br>
>> using during active development to a set of smaller CRs and assigned<br>
>> the same topic centos7-master-nod to all of them [0].<br>
>><br>
>> So, here is the plan:<br>
>> * We will put a mark 'Breaks' in every commit message indicating if the<br>
>> CR is compatible with current master node. E.g. 'Breaks: centos-6'<br>
>> means it can't be merged without breaking things, but 'Breaks:<br>
>> nothing' means it OK to merge.<br>
>> * All the CRs should be reviewed, regardless of their 'breaks' label,<br>
>> and voted. We will not merge breaking CRs accidentally, only those<br>
>> that are safe will be merged.<br>
>> * While code review is in progress we will work on passing our custom<br>
>> ISO BVT and scale lab tests. When these tests pass - we will run<br>
>> swarm on top of this custom ISO.<br>
>> * In the meantime our QA infrastructure will be updated to support<br>
>> CentOS-7 master node - it should be compatible in most cases,<br>
>> however, there are some places that are not. We plan to make changes<br>
>> compatible with current ISO.<br>
>> * As soon as ISO becomes good enough we should take a deep breath and<br>
>> turn the switch by merging all the changes that will bring CentOS-7<br>
>> to master branch (and break CentOS-6 version). This step requires<br>
>> all repositories involved to be frozen for small period of time, and<br>
>> that's why a merge freeze might be called. Immediately after all the<br>
>> changes are merged we will build new ISO and run reduced set of swarm<br>
>> tests. If the results are acceptable we will go on with CentOS-7. If<br>
>> not - we will revert breaking changes.<br>
>><br>
>><br>
>> [0]<br>
>> <a href="https://review.openstack.org/#/q/status:open+topic:centos7-master-node,n,z" rel="noreferrer" target="_blank">https://review.openstack.org/#/q/status:open+topic:centos7-master-node,n,z</a><br>
>><br>
>><br>
>> --<br>
>> Thanks,<br>
>> Dmitry Teselkin<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>
> __________________________________________________________________________<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>
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></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>