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

Fox, Kevin M Kevin.Fox at pnnl.gov
Tue May 16 18:25:07 UTC 2017


+1. ironic and trove have the same issues as well. lowering the bar in order to kick the tires will help OpenStack a lot in adoption.
________________________________________
From: Sean Dague [sean at dague.net]
Sent: Tuesday, May 16, 2017 6:28 AM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [tc][infra][release][security][stable][kolla][loci][tripleo][docker][kubernetes] do we want to be publishing binary container images?

On 05/16/2017 09:24 AM, Doug Hellmann wrote:
> Excerpts from Luigi Toscano's message of 2017-05-16 11:50:53 +0200:
>> On Monday, 15 May 2017 21:12:16 CEST Doug Hellmann wrote:
>>> Excerpts from Michał Jastrzębski's message of 2017-05-15 10:52:12 -0700:
>>>
>>>> On 15 May 2017 at 10:34, Doug Hellmann <doug at doughellmann.com> wrote:
>>>>> 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.
>>
>> Sorry for hijacking the thread, but we have a similar scenario for example in
>> Sahara. It is about full VM images containing Hadoop/Spark/other_big_data
>> stuff, and not containers, but it's looks really the same.
>> So far ready-made images have been published under http://sahara-files.mirantis.com/images/upstream/, but we are looking to have them hosted on
>> openstack.org, just like other artifacts.
>>
>> We asked about this few days ago on openstack-infra@, but no answer so far
>> (the Summit didn't help):
>>
>> http://lists.openstack.org/pipermail/openstack-infra/2017-April/005312.html
>>
>> I think that the answer to the question raised in this thread is definitely
>> going to be relevant for our use case.
>>
>> Ciao
>
> Thanks for raising this. I think the same concerns apply to VM images.

Agreed.

        -Sean

--
Sean Dague
http://dague.net

__________________________________________________________________________
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