Utilize SIG Build Docker Images

[seanpmorgan]

Description

Move to managed SIG Build images.

[bhack]

@angerson A TF 2.6 has still a python 3.6 wheel do you plan to push also a 3.6 image?

[bhack]

OK.. green lights here..

[bhack]

https://discuss.tensorflow.org/t/adopting-open-source-dockerfiles-for-official-tf-nightly-ci/6050

[bhack]

We are having some issues with the auditwheel patch now.
What was the origin of this patch? Is it still required?

#27 0.585 + sed -i 's/libresolv.so.2"/libresolv.so.2", "libtensorflow_framework.so.2"/g' /usr/local/lib/python3.8/dist-packages/auditwheel/policy/policy.json
#27 0.588 sed: can't read /usr/local/lib/python3.8/dist-packages/auditwheel/policy/policy.json: No such file or directory
#27 ERROR: executor failed running [/bin/sh -c bash tools/releases/tf_auditwheel_patch.sh]: exit code: 2
------

[seanpmorgan]

We are having some issues with the auditwheel patch now. What was the origin of this patch? Is it still required?

#27 0.585 + sed -i 's/libresolv.so.2"/libresolv.so.2", "libtensorflow_framework.so.2"/g' /usr/local/lib/python3.8/dist-packages/auditwheel/policy/policy.json
#27 0.588 sed: can't read /usr/local/lib/python3.8/dist-packages/auditwheel/policy/policy.json: No such file or directory
#27 ERROR: executor failed running [/bin/sh -c bash tools/releases/tf_auditwheel_patch.sh]: exit code: 2
------

Was solved in #2623

[seanpmorgan]

We are having some issues with the auditwheel patch now. What was the origin of this patch? Is it still required?

#27 0.585 + sed -i 's/libresolv.so.2"/libresolv.so.2", "libtensorflow_framework.so.2"/g' /usr/local/lib/python3.8/dist-packages/auditwheel/policy/policy.json
#27 0.588 sed: can't read /usr/local/lib/python3.8/dist-packages/auditwheel/policy/policy.json: No such file or directory
#27 ERROR: executor failed running [/bin/sh -c bash tools/releases/tf_auditwheel_patch.sh]: exit code: 2
------

Just for visibility the reason for this auditwheel patch is to specify that tensorflow shared library should be added to the approved manylinux2010 libraries. If we remove this it will fail to export a manylinux2010 package.

SIG IO does a similar thing: https://github.com/tensorflow/io/blob/master/tools/build/auditwheel

[seanpmorgan]

Nice to be able to cut a lot of this tech debt from the build file

[bhack]

If https://github.com/tensorflow/addons/blob/master/.devcontainer/Dockerfile#L1-L2

[bhack]

If you can add here a fake but future-proof IMAGE_TYPE arg I think that we could remove the overhead of maintaining another separated Dockerfile (if you suppose that the our devel and our Vscode/Codespaces images could be almost the same one):

addons/.devcontainer/Dockerfile

Lines 1 to 2 in 4617bc2

	ARG IMAGE_TYPE=latest-cpu
	FROM tfaddons/dev_container:$IMAGE_TYPE

The main thing we are doing on that additional Dockerfile, other then let the user controlling the IMAGE_TYPE when they need the GPU image (currently not available) is that we are adding a default (guid/uid) non root user in the image build.

If we exclude that, with the unification we need to evaluate if without a default non root user, we can still official suggest that we prefer/support only Docker in rootless mode. This is currently the SIG Build policy that doesn't want to add a "default" user in the image.
It is hard to support both as rootless Docker vs root Docker are mutually exclusive for root and non root users permission on the host mounted volumes:

moby/moby#41497
https://discuss.tensorflow.org/t/adopting-open-source-dockerfiles-for-official-tf-nightly-ci/6050/9

[seanpmorgan]

Added the holder for IMAGE_TYPE. And updated to push it correctly as gpu dev container. I think it should be good to merge and we can revisit once we have a means to get a cpu image.

[seanpmorgan]

Made a new PR for the release:
tensorflow/community#406