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

Add Groovy installation to the bigtop_toolchain

    Details

    • Type: Improvement
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 0.7.0
    • Fix Version/s: 1.0.0
    • Component/s: build
    • Labels:
      None

      Description

      Having standalone groovy in the development environment seems to be helpful. Hence, let's add it.

        Issue Links

          Activity

          Hide
          rvs Roman Shaposhnik added a comment -

          While having it is helpful, here's one concern that I have: given that it isn't mandatory for building packages, how should we approach specifying mandatory vs. optional stuff in bigtop_toolchain?

          For example, there's absolutely no reason for me to bloat my docker/build slave images with optional stuff, yet being able to initialize those images with our bigtop_toolchain puppet code is super useful.

          Show
          rvs Roman Shaposhnik added a comment - While having it is helpful, here's one concern that I have: given that it isn't mandatory for building packages, how should we approach specifying mandatory vs. optional stuff in bigtop_toolchain? For example, there's absolutely no reason for me to bloat my docker/build slave images with optional stuff, yet being able to initialize those images with our bigtop_toolchain puppet code is super useful.
          Hide
          cos Konstantin Boudnik added a comment - - edited

          From the top of my head, we can use a sys.prop flag to explicitly turn it the installation on (being "off" by default?). So unless you just run GROOVY_PROVISIONING=yes puppet apply.... you just won't get groovy provisioned??

          Show
          cos Konstantin Boudnik added a comment - - edited From the top of my head, we can use a sys.prop flag to explicitly turn it the installation on (being "off" by default?). So unless you just run GROOVY_PROVISIONING=yes puppet apply.... you just won't get groovy provisioned??
          Hide
          rvs Roman Shaposhnik added a comment -

          I'd be cool with that! Was just wondering if there's any 'prior art' in that area around Puppet.

          Show
          rvs Roman Shaposhnik added a comment - I'd be cool with that! Was just wondering if there's any 'prior art' in that area around Puppet.
          Hide
          cos Konstantin Boudnik added a comment -

          Potentially there's a way to define new stage type of something, but I don't think it worth it in the particular case.

          Show
          cos Konstantin Boudnik added a comment - Potentially there's a way to define new stage type of something, but I don't think it worth it in the particular case.
          Hide
          cos Konstantin Boudnik added a comment -

          Here's the version of the patch to add Groovy installation for Bigtop development needs. As such, I have moved to a separate manifest called development-tools.

          It works pretty well. The only issue I have as I don't know how I can update /etc/profiles.d/bigtop.sh file to set GROOVY_HOME is Groovy is indeed getting installed. Would appreciate a hint from Puppet experts. Thanks!

          Show
          cos Konstantin Boudnik added a comment - Here's the version of the patch to add Groovy installation for Bigtop development needs. As such, I have moved to a separate manifest called development-tools . It works pretty well. The only issue I have as I don't know how I can update /etc/profiles.d/bigtop.sh file to set GROOVY_HOME is Groovy is indeed getting installed. Would appreciate a hint from Puppet experts. Thanks!
          Hide
          jayunit100 jay vyas added a comment - - edited

          Thanks cos. on the code part, +1. Before you commit...
          Can you clarify ...

          • why we are adding development tools to the toolchain?
          • why we arent just using the rpms/debs bigtop is packaging for fulfilling the same requirements?
            forgive me for my ignorance on this subject
          Show
          jayunit100 jay vyas added a comment - - edited Thanks cos. on the code part, +1. Before you commit... Can you clarify ... why we are adding development tools to the toolchain? why we arent just using the rpms/debs bigtop is packaging for fulfilling the same requirements? forgive me for my ignorance on this subject
          Hide
          cos Konstantin Boudnik added a comment -

          I believe exact purpose of the toolchain is to deliver the development tools, is it not? We are installing all the packages that are required for the build: java, maven, etc. Groovy is an SDK - just like java, hence I am adding it to the toolchain.

          As for using packages: are you saying that if I need to develop some Groovy smoke tests I'd need to the following:

          • run toolchain to configure my dev env.
          • build groovy package
          • install groovy package
          • develop my tests
            Whereas I can do just that:
          • run toolchain to configure my dev env
          • develop my tests

          Let me turn the question around: what's your concern?

          Show
          cos Konstantin Boudnik added a comment - I believe exact purpose of the toolchain is to deliver the development tools, is it not? We are installing all the packages that are required for the build: java, maven, etc. Groovy is an SDK - just like java, hence I am adding it to the toolchain. As for using packages: are you saying that if I need to develop some Groovy smoke tests I'd need to the following: run toolchain to configure my dev env. build groovy package install groovy package develop my tests Whereas I can do just that: run toolchain to configure my dev env develop my tests Let me turn the question around: what's your concern?
          Hide
          jayunit100 jay vyas added a comment - - edited

          no concern just making sure i understood
          like i said, +1, and now +2 b/c it also makes sense to me what we're doing here.
          your saying toolchain is for dev, packages are bigtop artifacts, so they serve a different purpose.

          Show
          jayunit100 jay vyas added a comment - - edited no concern just making sure i understood like i said, +1, and now +2 b/c it also makes sense to me what we're doing here. your saying toolchain is for dev, packages are bigtop artifacts, so they serve a different purpose.
          Hide
          cos Konstantin Boudnik added a comment -

          Right. And so far we've been using toolchain to prep. the environment that's required to build the stack; and lately we added deployment tools into (under a separate manifest); and this patch just follow the path with yet another manifest.

          There might be a better approach to this - I really can't think of any. Let me commit it now; we can restructure it if needed at a later time. Thanks!

          Show
          cos Konstantin Boudnik added a comment - Right. And so far we've been using toolchain to prep. the environment that's required to build the stack; and lately we added deployment tools into (under a separate manifest); and this patch just follow the path with yet another manifest. There might be a better approach to this - I really can't think of any. Let me commit it now; we can restructure it if needed at a later time. Thanks!
          Hide
          cos Konstantin Boudnik added a comment -

          Could you please take one more look? I have added a gradle build entry point, so that the setup can be done with gradlew toolchain-devtools without ever going to puppet. Thanks!

          Show
          cos Konstantin Boudnik added a comment - Could you please take one more look? I have added a gradle build entry point, so that the setup can be done with gradlew toolchain-devtools without ever going to puppet. Thanks!
          Hide
          jayunit100 jay vyas added a comment -

          +1 LGTM , assuming this has been tested !

          Show
          jayunit100 jay vyas added a comment - +1 LGTM , assuming this has been tested !
          Hide
          cos Konstantin Boudnik added a comment -

          Yes, it has been tested. With that type of interface the testing is pretty easy - you just run the gradle task Thanks, I will commit it in a bit.

          Show
          cos Konstantin Boudnik added a comment - Yes, it has been tested. With that type of interface the testing is pretty easy - you just run the gradle task Thanks, I will commit it in a bit.
          Hide
          cos Konstantin Boudnik added a comment -

          Committed and pushed to the master.

          Show
          cos Konstantin Boudnik added a comment - Committed and pushed to the master.

            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