Uploaded image for project: 'Bigtop'
  1. Bigtop
  2. BIGTOP-2171

shared gradle directory on slave containers should be writable for non-root users

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.1.0
    • Fix Version/s: 1.1.0
    • Component/s: docker
    • Labels:
      None

      Description

      After BIGTOP-2110 slave docker images do auto-setting for GRADLE_HOME and GRADLE_USER_HOME in order to share pre-populated cache.

      However, these directories aren't writable for non-root users, which leads to gradle build failures if ran by not-privileged users. E.g. smoke tests will be failing because of that.

        Issue Links

          Activity

          Hide
          cos Konstantin Boudnik added a comment - - edited

          Looks like something like this should be solving the problem for us. But I'd like to hear from people more advanced in docker

          diff --git docker/bigtop-slaves/centos-6/Dockerfile docker/bigtop-slaves/centos-6/Dockerfile
          index 3071d48..787e0db 100644
          --- docker/bigtop-slaves/centos-6/Dockerfile
          +++ docker/bigtop-slaves/centos-6/Dockerfile
          @@ -17,5 +17,6 @@ MAINTAINER oflebbe@apache.org
           
           COPY bigtop_toolchain /etc/puppet/modules/bigtop_toolchain
           COPY gradle.home /usr/share/gradle.home
          +RUN chmod -R 777 /usr/share/gradle.home
           
           RUN puppet apply -e "include bigtop_toolchain::installer"
          
          Show
          cos Konstantin Boudnik added a comment - - edited Looks like something like this should be solving the problem for us. But I'd like to hear from people more advanced in docker diff --git docker/bigtop-slaves/centos-6/Dockerfile docker/bigtop-slaves/centos-6/Dockerfile index 3071d48..787e0db 100644 --- docker/bigtop-slaves/centos-6/Dockerfile +++ docker/bigtop-slaves/centos-6/Dockerfile @@ -17,5 +17,6 @@ MAINTAINER oflebbe@apache.org COPY bigtop_toolchain /etc/puppet/modules/bigtop_toolchain COPY gradle.home /usr/share/gradle.home +RUN chmod -R 777 /usr/share/gradle.home RUN puppet apply -e "include bigtop_toolchain::installer"
          Hide
          cos Konstantin Boudnik added a comment -

          Any input from Olaf Flebbe, Evans Ye, anyone else? Thanks!

          Show
          cos Konstantin Boudnik added a comment - Any input from Olaf Flebbe , Evans Ye , anyone else? Thanks!
          Hide
          evans_ye Evans Ye added a comment -

          It's good to me.
          Although I've a thinking that maybe we can chown the dir to 1000:1000 because you've already tight the jenkins user id to 1000 in toolchain.
          Then we just need to enforce user to use jenkins user in-side container. How do you think?

          Show
          evans_ye Evans Ye added a comment - It's good to me. Although I've a thinking that maybe we can chown the dir to 1000:1000 because you've already tight the jenkins user id to 1000 in toolchain. Then we just need to enforce user to use jenkins user in-side container. How do you think?
          Hide
          cos Konstantin Boudnik added a comment -

          Yeah, that could be a better way to it. Lemme rework the patch.

          Show
          cos Konstantin Boudnik added a comment - Yeah, that could be a better way to it. Lemme rework the patch.
          Hide
          cos Konstantin Boudnik added a comment -

          Here's the patch. Validated it on centos-7 and seemingly the extra line does the trick

          Show
          cos Konstantin Boudnik added a comment - Here's the patch. Validated it on centos-7 and seemingly the extra line does the trick
          Hide
          cos Konstantin Boudnik added a comment -

          Pushed to the master.

          Show
          cos Konstantin Boudnik added a comment - Pushed to the master.
          Hide
          evans_ye Evans Ye added a comment -

          +1.
          BTW. I guess we can further improve the docker image generation by using docker-compose, which we can use variables in docker-compose.yml and get rid of dockerfile duplication. Just a tangential thing pop up in my mind.

          Show
          evans_ye Evans Ye added a comment - +1. BTW. I guess we can further improve the docker image generation by using docker-compose, which we can use variables in docker-compose.yml and get rid of dockerfile duplication. Just a tangential thing pop up in my mind.
          Hide
          cos Konstantin Boudnik added a comment -

          Yup, whenever docker-compose is ready to be used

          Show
          cos Konstantin Boudnik added a comment - Yup, whenever docker-compose is ready to be used

            People

            • Assignee:
              cos Konstantin Boudnik
              Reporter:
              cos Konstantin Boudnik
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development