[openstack-dev] [tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes] do we want to be publishing binary container images?

Michał Jastrzębski inc007 at gmail.com
Mon May 15 19:32:15 UTC 2017

On 15 May 2017 at 12:12, Doug Hellmann <doug at doughellmann.com> wrote:
> Excerpts from Michał Jastrzębski's message of 2017-05-15 10:52:12 -0700:
>> For starters, I want to emphasize that fresh set of dockerhub images
>> was one of most requested features from Kolla on this summit and few
>> other features more or less requires readily-available docker
>> registry. Features like full release upgrade gates.
>> This will have numerous benefits for users that doesn't have resources
>> to put sophisticated CI/staging env, which, I'm willing to bet, is
>> still quite significant user base. If we do it correctly (and we will
>> do it correctly), images we'll going to push will go through series of
>> gates which we have in Kolla (and will have more). So when you pull
>> image, you know that it was successfully deployed within scenerios
>> available in our gates, maybe even upgrade and increase scenerio
>> coverage later? That is a huge benefit for actual users.
> I have no doubt that consumers of the images would like us to keep
> creating them. We had lots of discussions last week about resource
> constraints and sustainable practices, though, and this strikes me
> as an area where we're deviating from our history in a way that
> will require more maintenance work upstream.
>> On 15 May 2017 at 10:34, Doug Hellmann <doug at doughellmann.com> wrote:
>> > Last week at the Forum we had a couple of discussions about
>> > collaboration between the various teams building or consuming
>> > container images. One topic that came up was deciding how to publish
>> > images from the various teams to docker hub or other container
>> > registries. While the technical bits seem easy enough to work out,
>> > there is still the question of precedence and whether it's a good
>> > idea to do so at all.
>> >
>> > In the past, we have refrained from publishing binary packages in
>> > other formats such as debs and RPMs. (We did publish debs way back
>> > in the beginning, for testing IIRC, but switched away from them to
>> > sdists to be more inclusive.) Since then, we have said it is the
>> > responsibility of downstream consumers to build production packages,
>> > either as distributors or as a deployer that is rolling their own.
>> > We do package sdists for python libraries, push some JavaScript to
>> > the NPM registries, and have tarballs of those and a bunch of other
>> > artifacts that we build out of our release tools.  But none of those
>> > is declared as "production ready," and so the community is not
>> > sending the signal that we are responsible for maintaining them in
>> > the context of production deployments, beyond continuing to produce
>> > new releases when there are bugs.
>> So for us that would mean something really hacky and bad. We are
>> community driven not company driven project. We don't have Red Hat or
>> Canonical teams behind us (we have contributors, but that's
>> different).
> Although I work at Red Hat, I want to make sure it's clear that my
> objection is purely related to community concerns. For this
> conversation, I'm wearing my upstream TC and Release team hats.
>> > Container images introduce some extra complexity, over the basic
>> > operating system style packages mentioned above. Due to the way
>> > they are constructed, they are likely to include content we don't
>> > produce ourselves (either in the form of base layers or via including
>> > build tools or other things needed when assembling the full image).
>> > That extra content means there would need to be more tracking of
>> > upstream issues (bugs, CVEs, etc.) to ensure the images are updated
>> > as needed.
>> We can do this by building daily, which was the plan in fact. If we
>> build every day you have at most 24hrs old packages, CVEs and things
>> like that on non-openstack packages are still maintained by distro
>> maintainers.
> A daily build job introduces new questions about how big the images
> are and how many of them we keep, but let's focus on whether the
> change in policy is something we want to adopt before we consider
> those questions.

http://tarballs.openstack.org/kolla/images/ we are already doing this
for last few months. Only difference is that it's hacky and we want
something that's not hacky.

Let's separate resource constrains for now please, because from
current standpoint all the resources we need is a single vm that's
gonna run 1hr every day and some uplink megabytes (probably less than
1gig every day as Docker will cache a lot). If that's an issue, we can
work on it and limit amount of pushes to just version changes,
something we were discussing anyway.

>> > Given our security and stable team resources, I'm not entirely
>> > comfortable with us publishing these images, and giving the appearance
>> > that the community *as a whole* is committing to supporting them.
>> > I don't have any objection to someone from the community publishing
>> > them, as long as it is made clear who the actual owner is. I'm not
>> > sure how easy it is to make that distinction if we publish them
>> > through infra jobs, so that may mean some outside process. I also
>> > don't think there would be any problem in building images on our
>> > infrastructure for our own gate jobs, as long as they are just for
>> > testing and we don't push those to any other registries.
>> Today we use Kolla account for that and I'm more than happy to keep it
>> this way. We license our code with ASL which gives no guarantees.
>> Containers will be licensed this way too, so they're available as-is
>> and "production readiness" should be decided by everyone who runs it.
>> That being said what we *can* promise is that our containers passed
>> through more or less rigorous gates and that's more than most of
>> packages/self-built containers ever do. I think that value would be
>> appreciated by small to mid companies that just want to work with
>> openstack and don't have means to spare teams/resources for CI.
> The ASL would clearly apply to the source of our projects that we
> put into the images. The images do contain other software, though,
> and it's less clear to me how to interpret the support guarantees
> for an image that contains a mix of projects with different licenses
> and written by different communities. Or even if we can say that
> the images are available under the ASL if some of the contents are
> GPL.
> Regardless, I'm not sure the copyright license is the correct
> document to learn about the support guarantees.  If I had an issue
> with one of those images, I would be much more likely to try to
> find the person or community responsible for publishing them than
> the author of a given package contained in the image. If we're
> asserting that consumers should not ask for support, why are we
> even talking about publishing them?

We have Kolla community to approach. We will be responsible for help
with these images and to keep them healthy. I personally volunteer to
be contact point if we need contact points. Otherwise we can just
point to irc, buglist, ML...all the channels we use today to help.

I'm not a lawyer, but I assume there is a way to say that this doesn't
have any formal guarantees and we ship it as-is?

>> > I'm raising the issue here to get some more input into how to
>> > proceed. Do other people think this concern is overblown? Can we
>> > mitigate the risk by communicating through metadata for the images?
>> > Should we stick to publishing build instructions (Dockerfiles, or
>> > whatever) instead of binary images? Are there other options I haven't
>> > mentioned?
>> Today we do publish build instructions, that's what Kolla is. We also
>> publish built containers already, just we do it manually on release
>> today. If we decide to block it, I assume we should stop doing that
>> too? That will hurt users who uses this piece of Kolla, and I'd hate
>> to hurt our users:(
> Well, that's the question. Today we have teams publishing those
> images themselves, right? And the proposal is to have infra do it?
> That change could be construed to imply that there is more of a
> relationship with the images and the rest of the community (remember,
> folks outside of the main community activities do not always make
> the same distinctions we do about teams). So, before we go ahead
> with that, I want to make sure that we all have a chance to discuss
> the policy change and its implications.

Infra as vm running with infra, but team to publish it can be Kolla
team. I assume we'll be responsible to keep these images healthy...

> Doug
> __________________________________________________________________________
> 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

More information about the OpenStack-dev mailing list