Could we ask them to buik add a list of people to add to the list? We could
add all PMC members and previous release managers to the list. That might
cover a good chunk of the future releases.
On Wed, Feb 12, 2020 at 10:10 PM Hannah Jiang <hannahji...@google.com>
wrote:
> Thanks everyone for supporting it.
>
> Yes, it's very slow to get tickets resolved by infra. I propose a minor
> improvement to reduce interactions with infra.
>
> So far, we have granted maintainer permission(read & write) to release
> managers' personal accounts. This step needs help from infra to add new
> members to the group for every new release manager.
> In order to avoid this, I proposed that we create a new account for
> release purpose only and share it with release managers. The new account
> will have read & write permissions to all Apache Beam docker repositories.
> A password will be shared on an as-needed basis and we can change the
> password periodically if needed, which is in our control. Are there any
> concerns which I am not aware of with the sharing account approach?
>
> Thanks,
> Hannah
>
>
> On Thu, Jan 16, 2020 at 10:41 AM Kenneth Knowles <k...@apache.org> wrote:
>
>> +1 very nice explanation
>>
>> On Wed, Jan 15, 2020 at 1:57 PM Ahmet Altay <al...@google.com> wrote:
>>
>>> +1 - Thank you for driving this!
>>>
>>> On Wed, Jan 15, 2020 at 1:55 PM Thomas Weise <t...@apache.org> wrote:
>>>
>>>> +1 for the namespace proposal.
>>>>
>>>> It is similar to github repos. Top-level is the org, then single level
>>>> for repo (beam-abc, beam-xzy, ..)
>>>>
>>>>
>>>>
>>>> On Wed, Jan 15, 2020 at 1:45 PM Robert Bradshaw <rober...@google.com>
>>>> wrote:
>>>>
>>>>> 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
>>>>>
>>>>
