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

Bogdan Dobrelya bdobreli at redhat.com
Thu May 18 10:36:44 UTC 2017


On 16.05.2017 20:57, Michał Jastrzębski wrote:
> On 16 May 2017 at 11:49, Doug Hellmann <doug at doughellmann.com> wrote:
>> Excerpts from Michał Jastrzębski's message of 2017-05-16 11:38:19 -0700:
>>> On 16 May 2017 at 11:27, Doug Hellmann <doug at doughellmann.com> wrote:
>>>> Excerpts from Michał Jastrzębski's message of 2017-05-16 09:46:19 -0700:
>>>>> So another consideration. Do you think whole rule of "not building
>>>>> binares" should be reconsidered? We are kind of new use case here. We
>>>>> aren't distro but we are packagers (kind of). I don't think putting us
>>>>> on equal footing as Red Hat, Canonical or other companies is correct
>>>>> here.
>>>>>
>>>>> K8s is something we want to work with, and what we are discussing is
>>>>> central to how k8s is used. K8s community creates this culture of
>>>>> "organic packages" built by anyone, most of companies/projects already
>>>>> have semi-official container images and I think expectations on
>>>>> quality of these are well...none? You get what you're given and if you
>>>>> don't agree, there is always way to reproduce this yourself.
>>>>>
>>>>> [Another huge snip]
>>>>>
>>>>
>>>> I wanted to have the discussion, but my position for now is that
>>>> we should continue as we have been and not change the policy.
>>>>
>>>> I don't have a problem with any individual or group of individuals
>>>> publishing their own organic packages. The issue I have is with
>>>> making sure it is clear those *are* "organic" and not officially
>>>> supported by the broader community. One way to do that is to say
>>>> they need to be built somewhere other than on our shared infrastructure.
>>>> There may be other ways, though, so I'm looking for input on that.
>>>
>>> What I was trying to say here is, current discussion aside, maybe we
>>> should revise this "not supported by broader community" rule. They may
>>> very well be supported to a certain point. Support is not just yes or
>>> no, it's all the levels in between. I think we can afford *some* level
>>> of official support, even if that some level means best effort made by
>>> community. If Kolla community, not an individual like myself, would
>>> like to support these images best to our ability, why aren't we
>>> allowed? As long as we are crystal clear what is scope of our support,
>>> why can't we do it? I think we've already proven that it's going to be
>>> tremendously useful for a lot of people, even in a shape we discuss
>>> today, that is "best effort, you still need to validate it for
>>> yourself"...
>>
>> Right, I understood that. So far I haven't heard anything to change
>> my mind, though.
>>
>> I think you're underestimating the amount of risk you're taking on
>> for yourselves and by extension the rest of the community, and
>> introducing to potential consumers of the images, by promising to
>> support production deployments with a small team of people without
>> the economic structure in place to sustain the work.
> 
> Again, we tell what it is and what it is not. I think support is
> loaded term here. Instead we can create lengthy documentation
> explaining to a detail lifecycle and testing certain container had to
> pass before it lands in dockerhub. Maybe add link to particular set of
> jobs that container had passed. Only thing we can offer is automated
> and transparent process of publishing. On top of that? You are on your
> own. But even within these boundaries, a lot of people could have
> better experience of running OpenStack...

That totally makes sense. Supporting builds like "a published container
passed some test scenarios for our CI gates, here is a link to
particular set of jobs that container had passed" benefits all and has
nothing to the production use cases and guarantees nothing in terms of
supporting them.

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



More information about the OpenStack-dev mailing list