Various tags of the same image should at least logically be the same
thing, so I agree that we should not be trying to share a single
repository in that way. A full suite of apache/beam-{image_desc}
repositories, if apache is fine with that, seems like the best
approach.
On Wed, Jan 15, 2020 at 1:32 PM Kyle Weaver <kcwea...@google.com> wrote:
>
> +1, agree that moving current image name to tags is a non-starter. Thanks for
> driving this Hannah. Let us know what they say about repo creation.
>
> On Wed, Jan 15, 2020 at 1:16 PM Udi Meiri <eh...@google.com> wrote:
>>
>> SG +1
>>
>> On Wed, Jan 15, 2020 at 12:59 PM Hannah Jiang <hannahji...@google.com> wrote:
>>>
>>> I have done some research about images released under apache namespace at
>>> docker hub, and here is my proposal.
>>>
>>> Currently, we are using apachebeam as our namespace and each image has its
>>> own repository. Version number is used to tag the images.
>>> ie: apachebeam/python2.7_sdk:2.19.0, apachebeam/flink1.9_job_server:2.19.0
>>>
>>> Now we are migrating to apache namespace and docker hub doesn't support
>>> nested repository names, so we cannot use
>>> apache/beam/{image-desc}:{version}.
>>> Instead, I propose to use apache/beam-{image_desc}:{version} as our
>>> repository name.
>>> ie: apache/beam-python2.7_sdk:2.19.0, apache/beam-flink1.9_job_server:2.19.0
>>> => When a user searches for apache/beam at docker hub, it will list all the
>>> repositories we deployed with apache/beam-, so no concerns that some
>>> released images are missed by users.
>>> => Repository names give insights to the users which repositories they
>>> should use.
>>> => A downside with this approach is we need to create a new repository
>>> whenever we release a new image, time and effort needed for this is
>>> pending, I am contacting apache docker hub management team.
>>>
>>> I have considered using beam as repository name and moving image name and
>>> version to tags, (ie: apache/beam:python3.7_sdk_2.19.0), which means put
>>> all images to a single repository, however, this approach has some
>>> downsides.
>>> => When a user searches for apache/beam, only one repository is returned.
>>> Users need to use tags to identify which images they should use. Since we
>>> release images with new tags for each version, it will overwhelm the users
>>> and give them an impression that the images are not organized well. It's
>>> also difficult to know what kind of images we deployed.
>>> => With both image name and version included at tags, it is a little bit
>>> more complicated to maintain the code.
>>> => There is no correct answer which image the latest tag should point to.
>>>
>>> Are there any concerns with this proposal?
>>>
>>> Thanks,
>>> Hannah
>>>
>>>
>>>
>>>
>>> On Fri, Jan 10, 2020 at 4:19 PM Ahmet Altay <al...@google.com> wrote:
>>>>
>>>>
>>>>
>>>> On Fri, Jan 10, 2020 at 3:33 PM Ahmet Altay <al...@google.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Jan 10, 2020 at 3:32 PM Ankur Goenka <goe...@google.com> wrote:
>>>>>>
>>>>>> Also curious to know if apache provide any infra support fro projects
>>>>>> under Apache umbrella and any quota limits they might have.
>>>>
>>>>
>>>> Maybe Hannah can ask with an infra ticket?
>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Jan 10, 2020, 2:26 PM Robert Bradshaw <rober...@google.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> One downside is that, unlike many of these projects, we release a
>>>>>>> dozen or so containers. Is there exactly (and only) one level of
>>>>>>> namespacing/nesting we can leverage here? (This isn't a blocker, but
>>>>>>> something to consider.)
>>>>>
>>>>>
>>>>> After a quick search, I could not find a way to use more than one level
>>>>> of repositories. We can use the naming scheme we currently use to help
>>>>> with. Our repositories are named as apachebeam/X, we could start using
>>>>> apache/beam/X.
>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Jan 10, 2020 at 2:06 PM Hannah Jiang <hannahji...@google.com>
>>>>>>> wrote:
>>>>>>> >
>>>>>>> > Thanks Ahmet for proposing it.
>>>>>>> > I will take it and work towards v2.19.
>>>>
>>>>
>>>> Missed this part. Thank you Hannah!
>>>>
>>>>>>>
>>>>>>> >
>>>>>>> > Hannah
>>>>>>> >
>>>>>>> > On Fri, Jan 10, 2020 at 1:50 PM Kyle Weaver <kcwea...@google.com>
>>>>>>> > wrote:
>>>>>>> >>
>>>>>>> >> It'd be nice to have the clout/official sheen of apache attached to
>>>>>>> >> our containers. Although getting the required permissions might add
>>>>>>> >> some small overhead to the release process. For example, yesterday,
>>>>>>> >> when we needed to create new repositories (not just update existing
>>>>>>> >> ones), since we have top-level ownership of the apachebeam
>>>>>>> >> organization, it was quick and easy to add them. I imagine we'd have
>>>>>>> >> had to get approval from someone outside the project to do that
>>>>>>> >> under the apache org. But this won't need to happen very often, so
>>>>>>> >> it's probably not that big a deal.
>>>>>>> >>
>>>>>>> >> On Fri, Jan 10, 2020 at 1:40 PM Ahmet Altay <al...@google.com> wrote:
>>>>>>> >>>
>>>>>>> >>> Hi all,
>>>>>>> >>>
>>>>>>> >>> I saw recent progress on the containers and wanted to bring this
>>>>>>> >>> question to the attention of the dev list.
>>>>>>> >>>
>>>>>>> >>> Would it be possible to use the official ASF dockerhub organization
>>>>>>> >>> for new Beam container releases? Concretely, starting from 2.19
>>>>>>> >>> could we release Beam containers to https://hub.docker.com/u/apache
>>>>>>> >>> instead of https://hub.docker.com/u/apachebeam ?
>>>>>>> >>>
>>>>>>> >>> Ahmet
