Thank you all for the comments. We can prototype something closer to (a)
and we can always change it later. My concern was that this would consume
more resources, but this might be a non-issue.
>From a procedure perspective, do we need a formal vote on this?
On Thu, Dec 21, 2017 at 1:33 PM, Holde
So I think we (or more accurately the PMC) need to be careful with how we
post the container artifacts from an Apache POV since they most likely
contain non-Apache licensed code (and also posting daileys can be
conolicated since the PMC hasn’t voted on each one).
For just testing it should probabl
The GCR repository can be configured with public pull access, which I think
will be required to use the container.
On Thu, Dec 21, 2017 at 2:34 AM, David Sabater Dinter <
david.saba...@gmail.com> wrote:
> +1
> Hi,
> It makes sense to use GCR (locality with GCP services and works like any
> other
+1
Hi,
It makes sense to use GCR (locality with GCP services and works like any
other container repository), only caveat being that the images will be
private, in case anyone requires to debug locally will need access to pull
the image or build locally and push.
I agree getting closer to (a) is pre
+1
It would be great to be able to test this aspect of portability. For
testing purposes, I think whatever container registry is convenient to use
for distribution is fine.
Regarding frequency, I think we should consider something closer to (a).
The container images -- although usually quite stab
Hi all,
After some recent changes (e.g. [1]) we have a feasible container that we
can use to test Python SDK on portability framework. Until now we were
using Google provided container images for testing and for the released
product. We can gradually move away from that (at least partially) for
Py
