On Fri, Sep 30, 2016 at 12:52 PM, Adam Miller
<maxamillion@xxxxxxxxxxxxxxxxx> wrote:
> On Fri, Sep 30, 2016 at 10:07 AM, Dusty Mabe <dusty@xxxxxxxxxxxxx> wrote:
>>
>>
>> On 09/29/2016 06:03 PM, Adam Miller wrote:
>>> Hello all,
>>> I was recently discussing some items around docker layered image
>>> release process in the future with Randy (bowlofeggs) and Patrick
>>> (puiterwijk). As a side effect of our discussion there were two
>>> questions I wanted to ask of the Cloud WG:
>>>
>>> 1) Do we want to maintain docker images for every Fedora Release or do
>>> we want to focus only on latest? (i.e. - do we want to maintain them
>>> like we do rpms or take a different position)
>>
>> Just a quick question about "ownership". In the current landscape rpm
>> maintainers own the packages and manage when they get updated. Would
>> we not have the same kind of spread out ownership for docker images?
>>
>
> That is the current plan, but if we like we can establish a Layered
> Image SIG who would be the owner of all things Layered Images and then
> anyone could update/fix/whatever any of the layered images. Afaik this
> is similar to how various programming language stack SIGs are setup.
>
> -AdamM
>
>> Dusty
>>
>>>
>>> 2) Do we want to keep around multiple versions of a container?
>>>
>>> For example:
>>> If we had the following images:
>>>
>>> registry.fedoraproject.org/cockpit:0.95-1.23
>>> registry.fedoraproject.org/cockpit:0.95-1.24
>>> registry.fedoraproject.org/cockpit:0.95-1.25
>>>
>>> One we release to stable 0.95-1.25, can we delete -1.24 and/or
>>> -1.23? What kind of retention do we want here? (Note that rpm content
>>> does not currently maintain a N and N-1 in the repositories)
Hello all,
I'd like to bump this conversation with a revised proposal.
For base images we would follow a naming guideline such as:
registry.fedoraproject.org/fedora/24
registry.fedoraproject.org/fedora/25
registry.fedoraproject.org/fedora/26
For layered images, we would follow something similar to:
registry.fedoraproject.org/fedora/24/httpd:latest
registry.fedoraproject.org/fedora/24/httpd:2.4
registry.fedoraproject.org/fedora/24/httpd:2.4.23
This will allow for the base image to easily "map" to the layered
images for the sake of naming consistency.
The main drawback I see is that this is kind of verbose and for users
of docker directly this may or may not be problematic. Also, a method
by which we can index and make the layered images discoverable is
still something to be sorted out.
However, thinking towards the future of modularity this would allow us
to follow a common pattern as we would effectively have the base image
correlate to a "base runtime" and the base runtime "generation" will
take on the fedora major release number which would allow us to
effectively "namespace" by base runtime generation.
For example:
For base runtime generation 27 (think Fedora 27), we would have
the following base runtime images (known today as the base docker
image).
registry.fedoraproject.org/fedora/27
Any updates to the generation lineage would be handled via tags to
that repository in the registry.
We could also maintain a tag for posterity and to keep things more
"familiar" for users of just the docker comman line tool.
registry.fedoraproject.org/fedora:latest
registry.fedoraproject.org/fedora:27
Where fedora:latest is a "moving pointer" to whatever the newest
stable generation of base runtime is and the fedora:27 is a moving
pointer to whatever the latest update version of the fedora/27
generation (i.e. fedora/27:20171201 or some other arbitrary versioning
scheme the modularity group comes up with)
Thoughts?
No matter what we do there's likely to be some patching needed to
various components of OSBS and we'll need to sort out a proper koji
tag layout but those are implementation details that I mostly wanted
to bring up so that everyone knows that once we make a decision it's
not going there will be some amount of lead time before that decision
is made into a reality and that it will potentially be non-trivial to
make wildly different changes to the convention.
-AdamM
>>>
>>> Thank you,
>>> -AdamM
>>> _______________________________________________
>>> cloud mailing list -- cloud@xxxxxxxxxxxxxxxxxxxxxxx
>>> To unsubscribe send an email to cloud-leave@xxxxxxxxxxxxxxxxxxxxxxx
>>>
>> _______________________________________________
>> cloud mailing list -- cloud@xxxxxxxxxxxxxxxxxxxxxxx
>> To unsubscribe send an email to cloud-leave@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
cloud mailing list -- cloud@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to cloud-leave@xxxxxxxxxxxxxxxxxxxxxxx
