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 <rvya...@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 <ogelb...@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 >> <vkozhuka...@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 <ikalnit...@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 <ogelb...@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 >>>> > <dtesel...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev