Open Stack

I performed a back to back upgrade of one of my kubernetes clusters across 2 separate major versions yesterday (1.11.x -> 1.13.x) in under 30 minutes. The prep time for it was about the same.

I'm not writing this to sing k8s's praises and slam on OpenStack. I'm trying to help ensure folks have an understanding of OpenStacks continual situation here.... What OpenStack asks of Operators is a huge amount of work while similar software does not, while achieving very similar things.

While its good that your not pushing folks to use untested stuff, that should be top priority to fix I think.

One of the big reasons the k8s upgrade was so easy was not needing to rebuild the universe. The software deployed as part of the upgrade was 1, built upstream, 2, tested upstream, 3, upgrade tested upstream. What I deployed was completely binary identical, all the way down to libc, to what they released. This ensured to a high level of reliability that upgrades would be smooth.

I pushed for a while to get all of that workflow in kolla/kolla-kubernetes and infra just wasn't ready at the time. they are now though, which is fantastic.

Please seize this opportunity cause it really has the potential to help OpenStack's Operators in a big way.

There are a few other reasons the upgrade was so easy/quick. Those should be tackled by OpenStack too. but that's for another thread...

Thanks,
Kevin
________________________________________
From: Chris Hoge [chris at openstack.org]
Sent: Wednesday, January 30, 2019 7:56 AM
To: openstack-discuss at lists.openstack.org
Subject: Re: [infra][tc] Container images in openstack/ on Docker Hub

I want to clear up a few things about Loci images. To start with, I would
not be comfortable publishing Loci images to the OpenStack namespace in
Docker Hub because currently they have no functional testing. In several
instances over the past couple of months we've sent up patches to fix
images that just didn't work because of dependency issues. We're working
on a way to do functional testing, and once we're gating with functional
testing on master and stable branches we can revisit the issue.

Still, we assume that deployment tooling will want to modify images
anyway, and specifically designed the build system to accomodate
injecting different binary and python dependencies. Also, Loci does not
provide it's own Makefile for building images. The Dockerfile and
installation scripts use environment variables to control the entire
build process, which makes is very easy to use tools like Make or
Ansible to build the images.

Supporting multiple base operating systems is trivial with Loci and
Docker image tagging. If we do push images to some central location, as a
community we should think about adopting a common tagging strategy for
consitency across all projects. For example, in my own little deployments
I use a naming scheme that follows this pattern:

loci-<project>:<release>-<base>

So Nova from master on Leap15 would be tagged as:

loci-nova:master-leap15

We should be listening to demand for such images, but for now I encourage
people interested in Loci to build their own to suit their particular
needs.

-Chris


> On Jan 30, 2019, at 6:35 AM, Jeremy Stanley <fungi at yuggoth.org> wrote:
>
> On 2019-01-30 13:57:03 +0000 (+0000), Sean Mooney wrote:
> [...]
>> i would recommend basing such a container on the offical
>> python:3-alpine image as it is only 30mb and has everything we
>> should need to just pip install the project. it has python 3.7.2
>> currently but the 3-alpine tag tracks both the latest release of
>> alpine and the latest release of python alpine supports.
>
> In a twist of irony, Python manylinux1 wheels assume glibc and so
> any with C extensions are unusable with Alpine's musl. As a result,
> we'll likely need to cross-compile any of our non-pure-Python
> dependencies from sdist/source with an appropriate toolchain and
> inject them into image.
>
>> in some rare cases we might need to also install bindeps but i
>> would hope that between bindeps and pip we could build small
>> images for source fairly simpely and leave the orchestration of
>> those images to the enduser.
> [...]
>
> The bindep tool does at least have support for Alpine now, so as
> long as there are packages available for our system dependencies
> that should hopefully be a viable option.
> --
> Jeremy Stanley