[openstack-dev] [Fuel] Getting rid of Docker containers on the Fuel master node
Vladimir Kozhukalov
vkozhukalov at mirantis.com
Tue Dec 1 15:09:50 UTC 2015
Fox, this is one of the reasons. There are others listed in my original
letter.
Guys, I have prepared two patches [1] and [2] that can properly deploy the
master node. I still have not got any positive feedback on the spec [3]. My
intention was to wait until Centos 7 feature is merged and then to rebase
my patches, but now it seems too late. FF is tomorrow and my suggestion is
to make these two patches fully compatible with master so as to make it
possible to build ISO both with and without docker containers. Then we can
remove docker after SCF.
[1] https://review.openstack.org/#/c/248649/
[2] https://review.openstack.org/#/c/248650/
[3] https://review.openstack.org/#/c/248814/
Vladimir Kozhukalov
On Mon, Nov 30, 2015 at 11:19 PM, Fox, Kevin M <Kevin.Fox at pnnl.gov> wrote:
> Is that because of trying to shoehorn docker containers into rpm's though?
> I've never seen anyone else try and use them that way. Maybe they belong in
> a docker repo like the hub or something openstack.org hosted instead?
>
> Thanks,
> Kevin
> ________________________________________
> From: Igor Kalnitsky [ikalnitsky at mirantis.com]
> Sent: Friday, November 27, 2015 1:22 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Fuel] Getting rid of Docker containers on
> the Fuel master node
>
> Hey Vladimir,
>
> Thanks for your effort on doing this job. Unfortunately we have not so
> much time left and FF is coming, so I'm afraid it's become unreal to
> make it before FF. Especially if it takes 2-3 days to fix system
> tests.
>
>
> Andrew,
>
> I had the same opinion some time ago, but it was changed because
> nobody puts effort to fix our Docker experience. Moreover Docker is
> still buggy and we have a plenty of issues such as stale mount points
> for instance. Besides, I don't like our upgrade procedure -
>
> 1. Install fuel-docker-images.rpm
> 2. Load images from installed tarball to Docker
> 3. Re-create containers from new images
>
> Where (2) and (3) are manual steps and breaks idea of "yum update"
> delivery approach.
>
> Thanks,
> Igor
>
> On Wed, Nov 25, 2015 at 9:43 PM, Andrew Woodward <xarses at gmail.com> wrote:
> > <opinion>
> > IMO, removing the docker containers is a mistake v.s. fixing them and
> using
> > them properly. They provide an isolation that is necessary (and that we
> > mangle) to make services portable and scaleable. We really should sit
> down
> > and document how we really want all of the services to interact before we
> > rip the containers out.
> >
> > I agree, the way we use containers now still is quite wrong, and brings
> us
> > some negative value, but I'm not sold on stripping them out now just
> because
> > they no longer bring the same upgrades value as before.
> > </opinion>
> >
> > My opinion aside, we are rushing into this far to late in the feature
> cycle.
> > Prior to moving forward with this, we need a good QA plan, the spec is
> quite
> > light on that and must receive review and approval from QA. This needs to
> > include an actual testing plan.
> >
> > From the implementation side, we are pushing up against the FF deadline.
> We
> > need to document what our time objectives are for this and when we will
> no
> > longer consider this for 8.0.
> >
> > Lastly, for those that are +1 on the thread here, please review and
> comment
> > on the spec, It's received almost no attention for something with such a
> > large impact.
> >
> > On Tue, Nov 24, 2015 at 4:58 PM Vladimir Kozhukalov
> > <vkozhukalov at mirantis.com> wrote:
> >>
> >> The status is as follows:
> >>
> >> 1) Fuel-main [1] and fuel-library [2] patches can deploy the master node
> >> w/o docker containers
> >> 2) I've not built experimental ISO yet (have been testing and debugging
> >> manually)
> >> 3) There are still some flaws (need better formatting, etc.)
> >> 4) Plan for tomorrow is to build experimental ISO and to begin fixing
> >> system tests and fix the spec.
> >>
> >> [1] https://review.openstack.org/#/c/248649
> >> [2] https://review.openstack.org/#/c/248650
> >>
> >> Vladimir Kozhukalov
> >>
> >> On Mon, Nov 23, 2015 at 7:51 PM, Vladimir Kozhukalov
> >> <vkozhukalov at mirantis.com> wrote:
> >>>
> >>> Colleagues,
> >>>
> >>> I've started working on the change. Here are two patches (fuel-main [1]
> >>> and fuel-library [2]). They are not ready to review (still does not
> work and
> >>> under active development). Changes are not going to be huge. Here is a
> spec
> >>> [3]. Will keep the status up to date in this ML thread.
> >>>
> >>>
> >>> [1] https://review.openstack.org/#/c/248649
> >>> [2] https://review.openstack.org/#/c/248650
> >>> [3] https://review.openstack.org/#/c/248814
> >>>
> >>>
> >>> Vladimir Kozhukalov
> >>>
> >>> On Mon, Nov 23, 2015 at 3:35 PM, Aleksandr Maretskiy
> >>> <amaretskiy at mirantis.com> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On Mon, Nov 23, 2015 at 2:27 PM, Bogdan Dobrelya
> >>>> <bdobrelia at mirantis.com> wrote:
> >>>>>
> >>>>> On 23.11.2015 12:47, Aleksandr Maretskiy wrote:
> >>>>> > Hi all,
> >>>>> >
> >>>>> > as you know, Rally runs inside docker on Fuel master node, so
> docker
> >>>>> > removal (good improvement) is a problem for Rally users.
> >>>>> >
> >>>>> > To solve this, I'm planning to make native Rally installation on
> Fuel
> >>>>> > master node that is running on CentOS 7,
> >>>>> > and then make a step-by-step instruction how to make this
> >>>>> > installation.
> >>>>> >
> >>>>> > So I hope docker removal will not make issues for Rally users.
> >>>>>
> >>>>> I believe the most backwards compatible scenario is to keep the
> docker
> >>>>> installed while removing the fuel-* docker things back to the host
> OS.
> >>>>> So nothing would prevent user from pulling and running whichever
> docker
> >>>>> containers he wants to put on the Fuel master node. Makes sense?
> >>>>>
> >>>>
> >>>> Sounds good
> >>>>
> >>>>
> >>>>
> __________________________________________________________________________
> >>>> 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
> >
> > --
> >
> > --
> >
> > Andrew Woodward
> >
> > Mirantis
> >
> > Fuel Community Ambassador
> >
> > Ceph Community
> >
> >
> >
> __________________________________________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151201/b7d9fc74/attachment.html>
More information about the OpenStack-dev
mailing list