nStack 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 co
From: Igor Kalnitsky [ikalnit...@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. Unf
Hi,
On Wed, Nov 25, 2015 at 9:43 PM, Andrew Woodward wrote:
>
> 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 an
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 beca
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
r
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 e
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]
On Mon, Nov 23, 2015 at 2:27 PM, Bogdan Dobrelya
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 ma
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.
On Mon, Nov 23, 2015 at 3:27 PM, Bogdan Dobrelya
wrote:
> On
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
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
ETA:
experimental ISO w/o docker: tonight
spec: tomorrow night
Vladimir Kozhukalov
On Mon, Nov 23, 2015 at 9:25 AM, Anastasia Urlapova
wrote:
> @Vova,
> thanks for bringing this up.
> The new approach without docker containers on master node really has many
> advantages.
>
> @Igor,
> regardi
@Vova,
thanks for bringing this up.
The new approach without docker containers on master node really has many
advantages.
@Igor,
regarding your question, I would say that we have many dependencies from
containers in CI/CD systems and test's codebase. The test alignment to the
new implementation wo
With CentOS7 we will have python2.7 at Fuel Admin node as a default
version, I believe.
--
Best regards,
Oleg Gelbukh,
Principal Engineer
Mirantis
On Fri, Nov 20, 2015 at 6:27 AM, Timur Nurlygayanov <
tnurlygaya...@mirantis.com> wrote:
> Hi Andrey,
>
> As far as I remember from the last usage of
Hey Timur,
> I think we can change all docker-based code from our tests / scripts
> in 2-3 days
That sounds good.
> Do we really want to remove docker containers from master node?
Yes, we do. Currently we're suffering from using container-based
architecture on master node, and since we've deci
Hi Igor and Alexander,
>But I'd like to hear from QA how do we rely on container-based
> infrastructure? Would it be hard to change our sys-tests in short
> time?
QA team hadn't significant dependencies from docker images in our tests
[0], I think we can change all docker-based code from our test
On 20.11.2015 17:31, Vladimir Kozhukalov wrote:
> Bogdan,
>
>>> So, we could only deprecate the docker feature for the 8.0.
>
> What do you mean exactly when saying 'deprecate docker feature'? I can
> not even imagine how we can live with and without docker containers at
> the same time. Deprecat
+1 to remove docker in new CentOS 7.
On Fri, Nov 20, 2015 at 7:31 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:
> Bogdan,
>
> >> So, we could only deprecate the docker feature for the 8.0.
>
> What do you mean exactly when saying 'deprecate docker feature'? I can not
> even imagine h
Bogdan,
>> So, we could only deprecate the docker feature for the 8.0.
What do you mean exactly when saying 'deprecate docker feature'? I can not
even imagine how we can live with and without docker containers at the same
time. Deprecation is usually related to features which directly impact UX
(
On 20.11.2015 15:10, Timur Nurlygayanov wrote:
> Hi team,
>
> I think it too late to make such significant changes for MOS 8.0 now,
> but I'm ok with the idea to remove docker containers in the future
> releases if our dev team want to do this.
> Any way, before we will do this, we need to plan ho
Hi Andrey,
As far as I remember from the last usage of fuel master node, there was
> Centos + py26 installation. Python 2.6 is old enough and sometimes it is
> hard to launch some application on fuel node without docker (image with
> py27/py3). Are you planning to provide py27 at least or my note
Hi!
I'm not fuel developer, so opinion below is based on user-view.
As far as I remember from the last usage of fuel master node, there was
Centos + py26 installation. Python 2.6 is old enough and sometimes it is
hard to launch some application on fuel node without docker (image with
py27/py3). Are
Hi team,
I think it too late to make such significant changes for MOS 8.0 now, but
I'm ok with the idea to remove docker containers in the future releases if
our dev team want to do this.
Any way, before we will do this, we need to plan how we will perform
updates between different releases with a
Hello, Igor.
>But I'd like to hear from QA how do we rely on container-based
infrastructure? Would it be hard to change our sys-tests in short
time?
At first glance, system tests are using docker only to fetch logs and run
shell commands.
Also, docker is used to run Rally.
If there is an action
+1 to remove containers
On Fri, Nov 20, 2015 at 12:29 AM, Thomas Goirand wrote:
> On 11/19/2015 03:59 PM, Vladimir Kozhukalov wrote:
> > Anyway, the idea is to get
> > rid of Docker containers on the master node and switch to plane package
> > based approach that we used before.
>
> +1
>
>
> ___
On 11/19/2015 03:59 PM, Vladimir Kozhukalov wrote:
> Anyway, the idea is to get
> rid of Docker containers on the master node and switch to plane package
> based approach that we used before.
+1
__
OpenStack Development Mai
Hey guys,
Despite the fact I like containers (as deployment unit), we don't use
them so. That means I +1 idea to drop containers, just because I
believe that would
* simplify a lot of things
* helps get rid of huge amount of hacks
* increase master node deployment
* release us from annoying suppo
Folks
I guess it should be pretty simple to roll back - install older version and
restore the backup with preservation of /var/log directory.
On Thu, Nov 19, 2015 at 7:38 PM, Sergii Golovatiuk wrote:
> Hi,
>
> On Thu, Nov 19, 2015 at 5:50 PM, Matthew Mosesohn
> wrote:
>
>> Vladimir,
>>
>> The
Hi,
On Thu, Nov 19, 2015 at 5:50 PM, Matthew Mosesohn
wrote:
> Vladimir,
>
> The old site.pp is long out of date and should just be recreated from the
> content of all the other $service-only.pp files.
>
> My main question is how do we propose to do a rollback from an update (in
> theory, from 8
Vladimir,
The old site.pp is long out of date and should just be recreated from the
content of all the other $service-only.pp files.
My main question is how do we propose to do a rollback from an update (in
theory, from 8.0 to 9.0, then back to 8.0)? Should we hardcode persistent
data directories
Vladimir
Although I am a big fan of this idea, I think it is too risky to do this
during our latest iteration for 8.0 release. There is a lot of stuff that
relies on our containerised approach. For example, it is our Fuel CI
master-node tests which will require adjustments. There are pieces of
thi
On 19.11.2015 15:59, Vladimir Kozhukalov wrote:
> Dear colleagues,
>
> As might remember, we introduced Docker containers on the master node a
> while ago when we implemented first version of Fuel upgrade feature. The
> motivation behind was to make it possible to rollback upgrade process if
> som
Dear colleagues,
As might remember, we introduced Docker containers on the master node a
while ago when we implemented first version of Fuel upgrade feature. The
motivation behind was to make it possible to rollback upgrade process if
something goes wrong.
Now we are at the point where we can not
33 matches
Mail list logo
