[Fuego] release test issues

Tim.Bird at sony.com Tim.Bird at sony.com
Thu Feb 22 20:19:23 UTC 2018



> -----Original Message-----
> From: Guilherme Camargo
> On Wed, Feb 21, 2018 at 10:19 PM, <Tim.Bird at sony.com
> <mailto:Tim.Bird at sony.com> > wrote:
> 
> 
> 
> 
> 	> -----Original Message-----
> 	> From: Guilherme Camargo
> 	>
> 
> 	> Hello, Tim, thanks for trying it out again and thanks for your time
> 	> in debugging this issue and providing logs.
> 	>
> 	> This problem is happening because we're not using fuego-host-
> scripts
> 	> in the derived fuego-release-test, what ends up resulting in the
> 	> jenkins' user not being properly mapped to the host's user.
> 	>
> 	> That's my fault, I forgot that this would be required in the
> 	> derivate image as well.
> 	>
> 	> I temporarily added that logic to build_and_run.sh (as a fixup
> commit)
> 	>
> 	> so that you're able to test it out, please see the patch below:
> 	>
> 	> diff --git a/build_and_run.sh b/build_and_run.sh
> 	> index e448ddf..0134759 100755
> 	> --- a/build_and_run.sh
> 	> +++ b/build_and_run.sh
> 	> @@ -50,6 +50,25 @@ fi
> 	>
> 	>  if [ "$1" = "up" ]; then
> 	>      if [ -v clean_start ]; then
> 	> +        # FIXME: We should provide a simpler way of mapping jenkins
> uid with
> 	> +        # hosts uid, that does not require the user (that's extending
> 	> +        # fuego-base) to have this logic in his docker build.
> 	> +        #
> 	> +        # Jenkins' uid/gid should probably be given as a docker-run
> variable
> 	> +        # (as http_proxy/https_proxy, and set properly through
> fuego-base
> 	> +        # entrypoint.)
> 	> +        #
> 	> +        if [ "${UID}" == "0" ]; then
> 	> +            uid=$(id -u "${SUDO_USER}")
> 	> +            gid=$(id -g "${SUDO_USER}")
> 	> +        else
> 	> +            uid="${UID}"
> 	> +            gid=$(id -g "${USER}")
> 	> +        fi
> 	> +
> 	> +        sed -i "s/HOST_UID/${uid}/" ./fuego-ro/conf/fuego.conf
> 	> +        sed -i "s/HOST_GID/${gid}/" ./fuego-ro/conf/fuego.conf
> 	> +
> 	>          docker build -t "${fuego_rt_image}" .
> 	>          docker rm -f "${fuego_rt_container}"
> 	>          docker run -dit --name ${fuego_rt_container} \
> 	> diff --git a/fuego-ro/conf/fuego.conf b/fuego-ro/conf/fuego.conf
> 	> index 0c95eae..96cdcc9 100644
> 	> --- a/fuego-ro/conf/fuego.conf
> 	> +++ b/fuego-ro/conf/fuego.conf
> 	> @@ -1,3 +1,3 @@
> 	> -docker_jenkins_uid=1000
> 	> -docker_jenkins_gid=987
> 	> +docker_jenkins_uid=HOST_UID
> 	> +docker_jenkins_gid=HOST_GID
> 	>
> 	> As I mentioned in my FIXME message, its undesirable to require a
> derivate
> 	> image to contain specific build steps (as the one that's replacing the
> id into
> 	> fuego.conf),
> 	> so we might need to come up with a better approach to make this
> work.
> 	>
> 	> The patch has already been pushed to
> 	> <https://bitbucket.org/profusionmobi/fuego-release-test
> <https://bitbucket.org/profusionmobi/fuego-release-test> >
> 	> 
> 	> https://bitbucket.org/profusionmobi/fuego-release-test
> <https://bitbucket.org/profusionmobi/fuego-release-test>  (master).
> 	> Can you please re-sync and test again?
> 
> 
> 	The jenkins uid and gid in the container now match those of my host
> user,
> 	but I'm getting the same start failure as before.
> 
> 	Even when I explicitly change permissions in the path:
> 	/var/cache/jenkins/war/META-INF/MANIFEST.MF, I still
> 	get the same (Permission denied) message shown in the log (as
> below).
> 
> 	I'm not sure what to try next.
> 	 -- Tim
> 
> 
> 
> 
> Thanks for helping, Tim.
> 
> I'm taking a closer look to understand why this is happening.

I'm not sure what is the root cause of this, and fear it might be a docker bug.
I have some notes I made when I was first integrating ProFusion's
changes to Fuego to start from a base docker container (on Feb 1).

In my notes I describe the same permission problem with
/var/cache/jenkins/war/META-INF/MANIFEST.MF.

In my notes it says:
"changed permissions, and it worked"
then later
"changed permissions back, and it still works (docker fs bug??)"

But I may have done something else, unrelated to the permissions,
which I didn't take note of at the time.
However, I'm pretty sure the current issue has the same root cause
as what I was seeing before.

Hopefully that's helpful information.
 -- Tim


More information about the Fuego mailing list