Re: [PROPOSAL] Transition released containers to the official ASF dockerhub organization
Perhaps we can make this part of committer onboarding. And maybe other one time steps of the release guide. Kenn On Fri, Feb 14, 2020 at 10:12 AM Ahmet Altay wrote: > How long does it take to add a new person to the list? > > On Fri, Feb 14, 2020 at 9:11 AM Hannah Jiang > 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. >> >> Adding PMC members and previous release managers will not solve the long >> term permission issue, because we need to add new release managers to the >> maintainers group and only the infra team has permission to add/remove >> members from whatever group. >> I will add upcoming release managers to the maintainers group as well so >> we don't need to deal with this issue at least the next three releases. >> Let's try with this approach first and revisit it later if needed. >> >> On Thu, Feb 13, 2020 at 9:55 AM Robert Burke wrote: >> >>> +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 >>> 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 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 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 wrote: >>> >>> +1 very nice explanation >>> >>> On Wed, Jan 15, 2020 at 1:57 PM Ahmet Altay wrote: +1 - Thank you for driving this! On Wed, Jan 15, 2020 at 1:55 PM Thomas Weise 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 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 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,
Re: [PROPOSAL] Transition released containers to the official ASF dockerhub organization
How long does it take to add a new person to the list? On Fri, Feb 14, 2020 at 9:11 AM Hannah Jiang 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. > > Adding PMC members and previous release managers will not solve the long > term permission issue, because we need to add new release managers to the > maintainers group and only the infra team has permission to add/remove > members from whatever group. > I will add upcoming release managers to the maintainers group as well so > we don't need to deal with this issue at least the next three releases. > Let's try with this approach first and revisit it later if needed. > > On Thu, Feb 13, 2020 at 9:55 AM Robert Burke wrote: > >> +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 >> 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 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 >>> 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 >>> wrote: >>> >>> >>> >>> +1 very nice explanation >>> >>> >>> >>> On Wed, Jan 15, 2020 at 1:57 PM Ahmet Altay >>> wrote: >>> >>> +1 - Thank you for driving this! >>> >>> On Wed, Jan 15, 2020 at 1:55 PM Thomas Weise >>> 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 >>> 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 >>> 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 >>>
Re: [PROPOSAL] Transition released containers to the official ASF dockerhub organization
> > 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. Adding PMC members and previous release managers will not solve the long term permission issue, because we need to add new release managers to the maintainers group and only the infra team has permission to add/remove members from whatever group. I will add upcoming release managers to the maintainers group as well so we don't need to deal with this issue at least the next three releases. Let's try with this approach first and revisit it later if needed. On Thu, Feb 13, 2020 at 9:55 AM Robert Burke wrote: > +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 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 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 >> 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 >> wrote: >> >>> >> >>> +1 very nice explanation >> >>> >> >>> On Wed, Jan 15, 2020 at 1:57 PM Ahmet Altay wrote: >> >> +1 - Thank you for driving this! >> >> On Wed, Jan 15, 2020 at 1:55 PM Thomas Weise 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 >> 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 >> 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.
Re: [PROPOSAL] Transition released containers to the official ASF dockerhub organization
+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 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 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 > 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 > wrote: > >>> > >>> +1 very nice explanation > >>> > >>> On Wed, Jan 15, 2020 at 1:57 PM Ahmet Altay wrote: > > +1 - Thank you for driving this! > > On Wed, Jan 15, 2020 at 1:55 PM Thomas Weise 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 > 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 > 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 > 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. >
Re: [PROPOSAL] Transition released containers to the official ASF dockerhub organization
+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 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 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 wrote: >>> >>> +1 very nice explanation >>> >>> On Wed, Jan 15, 2020 at 1:57 PM Ahmet Altay wrote: +1 - Thank you for driving this! On Wed, Jan 15, 2020 at 1:55 PM Thomas Weise 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 > 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 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 wrote: >> >> >> >> SG +1 >> >> >> >> On Wed, Jan 15, 2020 at 12:59 PM Hannah Jiang >> >> 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 >> >>> >> >>> >> >>>
Re: [PROPOSAL] Transition released containers to the official ASF dockerhub organization
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 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 wrote: > >> +1 very nice explanation >> >> On Wed, Jan 15, 2020 at 1:57 PM Ahmet Altay wrote: >> >>> +1 - Thank you for driving this! >>> >>> On Wed, Jan 15, 2020 at 1:55 PM Thomas Weise 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 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 > 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 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 > wrote: > > > > On Fri, Jan 10, 2020 at 3:33 PM Ahmet Altay > wrote: > > > > > > > > On Fri, Jan 10, 2020 at 3:32 PM Ankur Goenka > wrote: > >> > >> Also curious to know if apache provide any infra support fro > projects
Re: [PROPOSAL] Transition released containers to the official ASF dockerhub organization
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 wrote: > +1 very nice explanation > > On Wed, Jan 15, 2020 at 1:57 PM Ahmet Altay wrote: > >> +1 - Thank you for driving this! >> >> On Wed, Jan 15, 2020 at 1:55 PM Thomas Weise 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 >>> 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 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 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 wrote: On Fri, Jan 10, 2020 at 3:33 PM Ahmet Altay wrote: > > > > On Fri, Jan 10, 2020 at 3:32 PM Ankur Goenka 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
Re: [PROPOSAL] Transition released containers to the official ASF dockerhub organization
+1 very nice explanation On Wed, Jan 15, 2020 at 1:57 PM Ahmet Altay wrote: > +1 - Thank you for driving this! > > On Wed, Jan 15, 2020 at 1:55 PM Thomas Weise 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 >> 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 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 wrote: >>> >> >>> >> SG +1 >>> >> >>> >> On Wed, Jan 15, 2020 at 12:59 PM Hannah Jiang >>> 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 >>> wrote: >>> >>> >>> >>> On Fri, Jan 10, 2020 at 3:33 PM Ahmet Altay >>> wrote: >>> > >>> > >>> > >>> > On Fri, Jan 10, 2020 at 3:32 PM Ankur Goenka >>> 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
Re: [PROPOSAL] Transition released containers to the official ASF dockerhub organization
+1 - Thank you for driving this! On Wed, Jan 15, 2020 at 1:55 PM Thomas Weise 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 > 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 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 wrote: >> >> >> >> SG +1 >> >> >> >> On Wed, Jan 15, 2020 at 12:59 PM Hannah Jiang >> 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 wrote: >> >> >> >> On Fri, Jan 10, 2020 at 3:33 PM Ahmet Altay >> wrote: >> > >> > >> > >> > On Fri, Jan 10, 2020 at 3:32 PM Ankur Goenka >> 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 >> 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
Re: [PROPOSAL] Transition released containers to the official ASF dockerhub organization
+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 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 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 wrote: > >> > >> SG +1 > >> > >> On Wed, Jan 15, 2020 at 12:59 PM Hannah Jiang > 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 wrote: > > > > On Fri, Jan 10, 2020 at 3:33 PM Ahmet Altay wrote: > > > > > > > > On Fri, Jan 10, 2020 at 3:32 PM Ankur Goenka > 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 > 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 > 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
Re: [PROPOSAL] Transition released containers to the official ASF dockerhub organization
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 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 wrote: >> >> SG +1 >> >> On Wed, Jan 15, 2020 at 12:59 PM Hannah Jiang 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 wrote: On Fri, Jan 10, 2020 at 3:33 PM Ahmet Altay wrote: > > > > On Fri, Jan 10, 2020 at 3:32 PM Ankur Goenka 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 >> 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 >>> 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 >>> > 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 wrote: >>> >>> >>> >>> Hi all, >>> >>> >>> >>> I saw recent progress on the containers and wanted to bring this
Re: [PROPOSAL] Transition released containers to the official ASF dockerhub organization
+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 wrote: > SG +1 > > On Wed, Jan 15, 2020 at 12:59 PM Hannah Jiang > 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 wrote: >> >>> >>> >>> On Fri, Jan 10, 2020 at 3:33 PM Ahmet Altay wrote: >>> On Fri, Jan 10, 2020 at 3:32 PM Ankur Goenka 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 > 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 >> 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 >> 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 >> 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 >> >
Re: [PROPOSAL] Transition released containers to the official ASF dockerhub organization
SG +1 On Wed, Jan 15, 2020 at 12:59 PM Hannah Jiang 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 wrote: > >> >> >> On Fri, Jan 10, 2020 at 3:33 PM Ahmet Altay wrote: >> >>> >>> >>> On Fri, Jan 10, 2020 at 3:32 PM Ankur Goenka 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 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 > 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 > 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 > 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 > smime.p7s Description: S/MIME Cryptographic Signature
Re: [PROPOSAL] Transition released containers to the official ASF dockerhub organization
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 wrote: > > > On Fri, Jan 10, 2020 at 3:33 PM Ahmet Altay wrote: > >> >> >> On Fri, Jan 10, 2020 at 3:32 PM Ankur Goenka 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 >>> 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 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 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 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 >>>
Re: [PROPOSAL] Transition released containers to the official ASF dockerhub organization
On Fri, Jan 10, 2020 at 3:33 PM Ahmet Altay wrote: > > > On Fri, Jan 10, 2020 at 3:32 PM Ankur Goenka 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 >> 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 >>> 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 >>> 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 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 >>> >>
Re: [PROPOSAL] Transition released containers to the official ASF dockerhub organization
On Fri, Jan 10, 2020 at 3:32 PM Ankur Goenka wrote: > Also curious to know if apache provide any infra support fro projects > under Apache umbrella and any quota limits they might have. > > On Fri, Jan 10, 2020, 2:26 PM Robert Bradshaw 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 >> wrote: >> > >> > Thanks Ahmet for proposing it. >> > I will take it and work towards v2.19. >> > >> > Hannah >> > >> > On Fri, Jan 10, 2020 at 1:50 PM Kyle Weaver >> 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 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 >> >
Re: [PROPOSAL] Transition released containers to the official ASF dockerhub organization
Also curious to know if apache provide any infra support fro projects under Apache umbrella and any quota limits they might have. On Fri, Jan 10, 2020, 2:26 PM Robert Bradshaw 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.) > > On Fri, Jan 10, 2020 at 2:06 PM Hannah Jiang > wrote: > > > > Thanks Ahmet for proposing it. > > I will take it and work towards v2.19. > > > > Hannah > > > > On Fri, Jan 10, 2020 at 1:50 PM Kyle Weaver 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 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 >
Re: [PROPOSAL] Transition released containers to the official ASF dockerhub organization
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.) On Fri, Jan 10, 2020 at 2:06 PM Hannah Jiang wrote: > > Thanks Ahmet for proposing it. > I will take it and work towards v2.19. > > Hannah > > On Fri, Jan 10, 2020 at 1:50 PM Kyle Weaver 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 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
Re: [PROPOSAL] Transition released containers to the official ASF dockerhub organization
Thanks Ahmet for proposing it. I will take it and work towards v2.19. Hannah On Fri, Jan 10, 2020 at 1:50 PM Kyle Weaver 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 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 >> >
Re: [PROPOSAL] Transition released containers to the official ASF dockerhub organization
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 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 >