+1 to a bulk add. Shared account removes all accouttabillity and is at risk
for abuse.
As it stands, the release managers could abuse their privilege, but we'd
have the opportunity to know about whodunnit.
On Thu, Feb 13, 2020, 9:51 AM Robert Bradshaw <rober...@google.com> wrote:
> +1, granting permission to individual accounts is preferable to trying
> to share a single account.
>
> On Thu, Feb 13, 2020 at 9:44 AM Ahmet Altay <al...@google.com> wrote:
> >
> > 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
>
