Open Stack

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 support of upgrades / rollbacks that proved
to be non-working well

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?

Thanks,
Igor


On Thu, Nov 19, 2015 at 10:31 AM, Vladimir Kuklin <vkuklin at mirantis.com> wrote:
> 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
> <sgolovatiuk at mirantis.com> wrote:
>>
>> Hi,
>>
>> On Thu, Nov 19, 2015 at 5:50 PM, Matthew Mosesohn <mmosesohn at mirantis.com>
>> 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.0 to 9.0, then back to 8.0)? Should we hardcode persistent
>>> data directories (or symlink them?) to
>>> /var/lib/fuel/$fuel_version/$service_name, as we are doing behind the scenes
>>> currently with Docker? If we keep that mechanism in place, all the existing
>>> puppet modules can be used without any modifications. On the same note,
>>> upgrade/rollback is the same as backup and restore, that means our restore
>>> should follow a similar approach.
>>> -Matthew
>>
>>
>> There only one idea I have is to do dual partitioning system. The similar
>> approach is implemented in CoreOS.
>>
>>>
>>>
>>> On Thu, Nov 19, 2015 at 6:36 PM, Bogdan Dobrelya <bdobrelia at mirantis.com>
>>> wrote:
>>>>
>>>> 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
>>>> > something goes wrong.
>>>> >
>>>> > Now we are at the point where we can not use our tarball based upgrade
>>>> > approach any more and those patches that deprecate upgrade tarball has
>>>> > been already merged. Although it is a matter of a separate discussion,
>>>> > it seems that upgrade process rather should be based on kind of backup
>>>> > and restore procedure. We can backup Fuel data on an external media,
>>>> > then we can install new version of Fuel from scratch and then it is
>>>> > assumed backed up Fuel data can be applied over this new Fuel
>>>> > instance.
>>>>
>>>> A side-by-side upgrade, correct? That should work as well.
>>>>
>>>> > The procedure itself is under active development, but it is clear that
>>>> > rollback in this case would be nothing more than just restoring from
>>>> > the
>>>> > previously backed up data.
>>>> >
>>>> > As for Docker containers, still there are potential advantages of
>>>> > using
>>>> > them on the Fuel master node, but our current implementation of the
>>>> > feature seems not mature enough to make us benefit from the
>>>> > containerization.
>>>> >
>>>> > At the same time there are some disadvantages like
>>>> >
>>>> >   * it is tricky to get logs and other information (for example, rpm
>>>> >     -qa) for a service like shotgun which is run inside one of
>>>> > containers.
>>>> >   * it is specific UX when you first need to run dockerctl shell
>>>> >     {container_name} and then you are able to debug something.
>>>> >   * when building IBP image we mount directory from the host file
>>>> > system
>>>> >     into mcollective container to make image build faster.
>>>> >   * there are config files and some other files which should be shared
>>>> >     among containers which introduces unnecessary complexity to the
>>>> >     whole system.
>>>> >   * our current delivery approach assumes we wrap into rpm/deb
>>>> > packages
>>>> >     every single piece of the Fuel system. Docker images are not an
>>>> >     exception. And as far as they depend on other rpm packages we
>>>> > forced
>>>> >     to build docker-images rpm package using kind of specific build
>>>> >     flow. Besides this package is quite big (300M).
>>>> >   * I'd like it to be possible to install Fuel not from ISO but from
>>>> > RPM
>>>> >     repo on any rpm based distribution. But it is double work to
>>>> > support
>>>> >     both Docker based and package based approach.
>>>>
>>>> There is another point, the containers long build time when installing
>>>> the master node.
>>>>
>>>> >
>>>> > Probably some of you can give other examples. 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.
>>>> >
>>>> > As far as there is nothing new here, we just need to use our old
>>>> > site.pp
>>>> > (with minimal modifications), it looks like it is possible to
>>>> > implement
>>>> > this during 8.0 release cycle. If there are no principal objections,
>>>> > please give me a chance to do this ASAP (during 8.0), I know it is a
>>>> > huge risk for the release, but still I think I can do this.
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > Vladimir Kozhukalov
>>>> >
>>>> >
>>>> >
>>>> > __________________________________________________________________________
>>>> > 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
>>>> >
>>>>
>>>>
>>>> --
>>>> Best regards,
>>>> Bogdan Dobrelya,
>>>> Irc #bogdando
>>>>
>>>>
>>>> __________________________________________________________________________
>>>> 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
>>
>
>
>
> --
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 35bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com
> www.mirantis.ru
> vkuklin at mirantis.com
>
> __________________________________________________________________________
> 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
>