Open Stack

Hey Roman,

Few notes about fuel-web patches:

* https://review.openstack.org/#/c/246535/ - Could be (and should be)
merged after FF.
* https://review.openstack.org/#/c/246531/ - Has -1 from Jenkins.
Looks like a floating test failure, so I've restarted tests. But
please track this one, and fix it if it fails again.

Thanks,
Igor

On Thu, Nov 26, 2015 at 12:22 PM, Roman Vyalov <rvyalov at mirantis.com> wrote:
> Hi all,
> Part of those change requests may be merged shortly (today). They are
> compatible with Centos6.
> List of change requests ready to merge (compatible with Centos6):
> Fuel-library
>
> https://review.openstack.org/#/c/247066/
> https://review.openstack.org/#/c/248781/
> https://review.openstack.org/#/c/247727/
>
> Fuel-nailgun-agent
>
> https://review.openstack.org/#/c/244810/
>
> Fuel-web
>
> https://review.openstack.org/#/c/248206/
> https://review.openstack.org/#/c/246531/
> https://review.openstack.org/#/c/246535/
>
> Python-fuelclient
>
> https://review.openstack.org/#/c/231935/
>
> Fuel-ostf
>
> https://review.openstack.org/#/c/248096/
>
> Fuel-menu
>
> https://review.openstack.org/#/c/246888/
>
>
> List with all change requests related to the support Centos7:
> https://etherpad.openstack.org/p/fuel_on_centos7
>
> On Tue, Nov 24, 2015 at 4:37 PM, Oleg Gelbukh <ogelbukh at mirantis.com> wrote:
>>
>> That's good to know, thank you, Vladimir, Dmitry.
>>
>> --
>> Best regards,
>> Oleg Gelbukh
>>
>> On Tue, Nov 24, 2015 at 3:10 PM, Vladimir Kozhukalov
>> <vkozhukalov at mirantis.com> wrote:
>>>
>>> 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).
>>>
>>>
>>>
>>>
>>>
>>> Vladimir Kozhukalov
>>>
>>> On Tue, Nov 24, 2015 at 1:57 AM, Igor Kalnitsky <ikalnitsky at mirantis.com>
>>> wrote:
>>>>
>>>> Hey Dmitry,
>>>>
>>>> Thank you for your effort. I believe it's a huge step forward that
>>>> opens number of possibilities.
>>>>
>>>> > Every container runs systemd as PID 1 process instead of
>>>> > supervisord or application / daemon.
>>>>
>>>> Taking into account that we're going to drop Docker containers, I
>>>> think it was unnecessary complication of your work.
>>>>
>>>> Please sync-up with Vladimir Kozhukalov, he's working on getting rid
>>>> of containers.
>>>>
>>>> > Every service inside a container is a systemd unit. Container build
>>>> > procedure was modified, scripts setup.sh and start.sh were introduced
>>>> > to be running during building and configuring phases respectively.
>>>>
>>>> Ditto. :)
>>>>
>>>> Thanks,
>>>> Igor
>>>>
>>>> P.S: I wrote the mail and forgot to press "send" button. It looks like
>>>> Oleg is already pointed out that I wanted to.
>>>>
>>>> On Mon, Nov 23, 2015 at 2:37 PM, Oleg Gelbukh <ogelbukh at mirantis.com>
>>>> wrote:
>>>> > Please, take into account the plan to drop the containerization of
>>>> > Fuel
>>>> > services:
>>>> >
>>>> > https://review.openstack.org/#/c/248814/
>>>> >
>>>> > --
>>>> > Best regards,
>>>> > Oleg Gelbukh
>>>> >
>>>> > On Tue, Nov 24, 2015 at 12:25 AM, Dmitry Teselkin
>>>> > <dteselkin at mirantis.com>
>>>> > wrote:
>>>> >>
>>>> >> Hello,
>>>> >>
>>>> >> We've been working for some time on bringing CentOS-7 to master node,
>>>> >> and now is the time to share and discuss the transition plan.
>>>> >>
>>>> >> First of all, what have been changed:
>>>> >> * Master node itself runs on CentOS-7. Since all the containers share
>>>> >>   the same repo as master node they all have been migrated to
>>>> >> CentOS-7
>>>> >>   too. Every container runs systemd as PID 1 process instead of
>>>> >>   supervisord or application / daemon.
>>>> >> * Every service inside a container is a systemd unit. Container build
>>>> >>   procedure was modified, scripts setup.sh and start.sh were
>>>> >> introduced
>>>> >>   to be running during building and configuring phases respectively.
>>>> >>   The main reason for this was the fact that many puppet manifests
>>>> >> use
>>>> >>   service management commands that require systemd daemon running.
>>>> >> This
>>>> >>   also allowed to simplify Dockerfiles by removing all actions to
>>>> >>   setup.sh file.
>>>> >> * We managed to find some bugs in various parts that were fixed too.
>>>> >> * Bootstrap image is also CentOS-7 based. It was updated to better
>>>> >>   support it - some services converted to systemd units and fixes to
>>>> >>   support new network naming schema were made.
>>>> >> * ISO build procedure was updated to reflect changes in CentOS-7
>>>> >>   distribution and to support changes in docker build procedure.
>>>> >> * Many applications was updated (puppet, docker, openstack
>>>> >>   components).
>>>> >> * Docker containers moved to LVM volume to improve performance and
>>>> >> get
>>>> >>   rid of annoying warning messages during master node deployment.
>>>> >>   bootstrap_admin_node.sh script was updated to fix some deployment
>>>> >>   issues (e.g. dracut behavior when there are multiple network
>>>> >>   interfaces available) and simplified by removing outdated
>>>> >>   functionality. It was also converted to a "run once" logon script
>>>> >>   instead of being run as a service, primarily because of a way it's
>>>> >>   used.
>>>> >>
>>>> >> As you can see there are a lot of changes were made. Some of them
>>>> >> might
>>>> >> be merged into current master if surrounded by conditionals to be
>>>> >> compatible with current master node, but some of them simply can't.
>>>> >>
>>>> >> To simplify the code review process we've splitted CRs that we were
>>>> >> using during active development to  a set of smaller CRs and assigned
>>>> >> the same topic centos7-master-nod to all of them [0].
>>>> >>
>>>> >> So, here is the plan:
>>>> >> * We will put a mark 'Breaks' in every commit message indicating if
>>>> >> the
>>>> >>   CR is compatible with current master node. E.g. 'Breaks: centos-6'
>>>> >>   means it can't be merged without breaking things, but 'Breaks:
>>>> >>   nothing' means it OK to merge.
>>>> >> * All the CRs should be reviewed, regardless of their 'breaks' label,
>>>> >>   and voted. We will not merge breaking CRs accidentally, only those
>>>> >>   that are safe will be merged.
>>>> >> * While code review is in progress we will work on passing our custom
>>>> >>   ISO BVT and scale lab tests. When these tests pass - we will run
>>>> >>   swarm on top of this custom ISO.
>>>> >> * In the meantime our QA infrastructure will be updated to support
>>>> >>   CentOS-7 master node - it should be compatible in most cases,
>>>> >>   however, there are some places that are not. We plan to make
>>>> >> changes
>>>> >>   compatible with current ISO.
>>>> >> * As soon as ISO becomes good enough we should take a deep breath and
>>>> >>   turn the switch by merging all the changes that will bring CentOS-7
>>>> >>   to master branch (and break CentOS-6 version). This step requires
>>>> >>   all repositories involved to be frozen for small period of time,
>>>> >> and
>>>> >>   that's why a merge freeze might be called. Immediately after all
>>>> >> the
>>>> >>   changes are merged we will build new ISO and run reduced set of
>>>> >> swarm
>>>> >>   tests. If the results are acceptable we will go on with CentOS-7.
>>>> >> If
>>>> >>   not - we will revert breaking changes.
>>>> >>
>>>> >>
>>>> >> [0]
>>>> >>
>>>> >> https://review.openstack.org/#/q/status:open+topic:centos7-master-node,n,z
>>>> >>
>>>> >>
>>>> >> --
>>>> >> Thanks,
>>>> >> Dmitry Teselkin
>>>> >>
>>>> >>
>>>> >>
>>>> >> __________________________________________________________________________
>>>> >> OpenStack Development Mailing List (not for usage questions)
>>>> >> Unsubscribe:
>>>> >> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > __________________________________________________________________________
>>>> > OpenStack Development Mailing List (not for usage questions)
>>>> > Unsubscribe:
>>>> > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>> >
>>>>
>>>>
>>>> __________________________________________________________________________
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>