Open Stack

On 16/05/17 14:08 +0200, Thierry Carrez wrote:
>Flavio Percoco wrote:
>> From a release perspective, as Doug mentioned, we've avoided releasing projects
>> in any kind of built form. This was also one of the concerns I raised when
>> working on the proposal to support other programming languages. The problem of
>> releasing built images goes beyond the infrastructure requirements. It's the
>> message and the guarantees implied with the built product itself that are the
>> concern here. And I tend to agree with Doug that this might be a problem for us
>> as a community. Unfortunately, putting your name, Michal, as contact point is
>> not enough. Kolla is not the only project producing container images and we need
>> to be consistent in the way we release these images.
>>
>> Nothing prevents people for building their own images and uploading them to
>> dockerhub. Having this as part of the OpenStack's pipeline is a problem.
>
>I totally subscribe to the concerns around publishing binaries (under
>any form), and the expectations in terms of security maintenance that it
>would set on the publisher. At the same time, we need to have images
>available, for convenience and testing. So what is the best way to
>achieve that without setting strong security maintenance expectations
>for the OpenStack community ? We have several options:
>
>1/ Have third-parties publish images
>It is the current situation. The issue is that the Kolla team (and
>likely others) would rather automate the process and use OpenStack
>infrastructure for it.
>
>2/ Have third-parties publish images, but through OpenStack infra
>This would allow to automate the process, but it would be a bit weird to
>use common infra resources to publish in a private repo.
>
>3/ Publish transient (per-commit or daily) images
>A "daily build" (especially if you replace it every day) would set
>relatively-limited expectations in terms of maintenance. It would end up
>picking up security updates in upstream layers, even if not immediately.
>
>4/ Publish images and own them
>Staff release / VMT / stable team in a way that lets us properly own
>those images and publish them officially.
>
>Personally I think (4) is not realistic. I think we could make (3) work,
>and I prefer it to (2). If all else fails, we should keep (1).

Agreed #4 is a bit unrealistic.

Not sure I understand the difference between #2 and #3. Is it just the cadence?

I'd prefer for these builds to have a daily cadence because it sets the
expectations w.r.t maintenance right: "These images are daily builds and not
certified releases. For stable builds you're better off building it yourself"

Flavio

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 862 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170516/8e064aa7/attachment.sig>