On Wed, Jan 16, 2019 at 5:37 PM Ahmet Altay <al...@google.com> wrote:
> > > On Wed, Jan 16, 2019 at 5:28 PM Ankur Goenka <goe...@google.com> wrote: > >> - Could we start from snapshots first and then do it for releases? >> +1, releasing snapsots first makes sense to me. >> - For snapshots, do we need to clean old containers after a while? >> Otherwise I guess we will accumulate lots of containers. >> For snap shots we can maintain a single snapshot image from git HEAD >> daily. Docker has the internal image container id which changes everytime >> an image is changed and pulls new images as needed. >> > > There is a potential use this may not work with. If a user picks up a > snaphsot build and want to use it until the next release arrives. I guess > in that case the user can copy the snapshotted container image and rely on > that. > > Yes, that should be reasonable. > - Do we also need additional code changes for snapshots and releases to >> default to these specific containers? There could be a version based >> mechanism to resolve the correct container to use. >> The current image defaults have username in it. We should be ok by just >> updating the default image url to published image url. >> >> We should also check for pricing and details about Apache-Bintray >> agreement before pushing images and changing defaults. >> > > There is information on bintray's pricing page about open source projects > [1]. I do not know if there is a special apache-bintray agreement or not. > If there is no special agreement there is a 10GB storage limit for using > bintray. > As each image can easily run into Gigs, 10GB might not be sufficient for future proofing. We can also register docker image to docker image registry and not have bintray in the name to later host images on a different vendor for future proofing. > [1] https://bintray.com/account/pricing?tab=account&type=pricing > > >> >> On Wed, Jan 16, 2019 at 5:11 PM Ahmet Altay <al...@google.com> wrote: >> >>> This sounds like a good idea. Some questions: >>> >>> - Could we start from snapshots first and then do it for releases? >>> - For snapshots, do we need to clean old containers after a while? >>> Otherwise I guess we will accumulate lots of containers. >>> - Do we also need additional code changes for snapshots and releases to >>> default to these specific containers? There could be a version based >>> mechanism to resolve the correct container to use. >>> >>> On Wed, Jan 16, 2019 at 4:42 PM Ankur Goenka <goe...@google.com> wrote: >>> >>>> Hi All, >>>> >>>> As portability/FnApi is taking shape and are compatible with ULR and >>>> Flink. I wanted to discuss the release plan release of SDKHarness Docker >>>> images. Of-course users can create their own images but it will be useful >>>> to have a default image available out of box. >>>> Pre build image are a must for making FnApi available for users and not >>>> just the developers. >>>> The other purpose of these images is to be server as base image layer >>>> for building custom images. >>>> >>>> Apache already have bintray repositories for beam. >>>> https://bintray.com/apache/beam-snapshots-docker >>>> https://bintray.com/apache/beam-docker >>>> >>>> Shall we start pushing Python/Java/Go SDK Harness containers to >>>> https://bintray.com/apache/beam-docker for beam release and maintain >>>> daily snapshot at https://bintray.com/apache/beam-snapshots-docker ? >>>> >>>> Thanks, >>>> Ankur >>>> >>>
