Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 0.9.0
    • Fix Version/s: 1.0.0
    • Component/s: documentation
    • Labels:
      None

      Description

      Hi folks. we now have several bigtop related docker images.

      Lets create a wiki page for the scope and specification of the images which bigtop curates.

      As part of this, I'd like to add to that Specification that we curate the bigpetstore-load-generator image which I recently described on the mailing list.

        Issue Links

          Activity

          Hide
          rvs Roman Shaposhnik added a comment -

          There's absolutely no shame in having multiple Docker containers for multiple use cases around Bigtop. With that in mind, I'd really like to encourage us to:

          1. commit Dockerfiles to Bigtop repo (I'm as guilty as everybody else here – even more so!)
          2. put all [semi-]official containers on docker hub under Bigtop name
          3. leverage puppet for creation of specifics in Docker images rather than direct Dockerfile functionality

          Makes sense?

          Show
          rvs Roman Shaposhnik added a comment - There's absolutely no shame in having multiple Docker containers for multiple use cases around Bigtop. With that in mind, I'd really like to encourage us to: commit Dockerfiles to Bigtop repo (I'm as guilty as everybody else here – even more so!) put all [semi-] official containers on docker hub under Bigtop name leverage puppet for creation of specifics in Docker images rather than direct Dockerfile functionality Makes sense?
          Hide
          cos Konstantin Boudnik added a comment -

          Sure, let's do it. Shall we start with adding the Dockerfiles/their generator for CI images?

          Show
          cos Konstantin Boudnik added a comment - Sure, let's do it. Shall we start with adding the Dockerfiles/their generator for CI images?
          Hide
          evans_ye Evans Ye added a comment -

          +1 to the idea, and here's what I'm thinking:
          It would be great to have dockerfiles stored at a central place of our code base. I'm thing about moving Dockerfiles in bigtop-deploy to somewhere like bigtop-dockerfiles, which might have build specific dockerfile stored as well, and then push all the official images built from bigtop-dockerfiles up to bigtop dockerhub. If we can do so:

          • Users do not need to build local image by themselves to make docker provisioner work. This improves the UX.
          • Users can easily find and customize all the needed Dockerfile for their own bigtop environment.
            Do you think this make sense?
          Show
          evans_ye Evans Ye added a comment - +1 to the idea, and here's what I'm thinking: It would be great to have dockerfiles stored at a central place of our code base. I'm thing about moving Dockerfiles in bigtop-deploy to somewhere like bigtop-dockerfiles , which might have build specific dockerfile stored as well, and then push all the official images built from bigtop-dockerfiles up to bigtop dockerhub. If we can do so: Users do not need to build local image by themselves to make docker provisioner work. This improves the UX. Users can easily find and customize all the needed Dockerfile for their own bigtop environment. Do you think this make sense?
          Hide
          jayunit100 jay vyas added a comment -

          Okay, cool ! So ... who has the credentials for the dockerhub/bigtop account? Please go ahead and create a wiki page that describes the workflow for getting password / verifying an image / pushing to docker hub

          Show
          jayunit100 jay vyas added a comment - Okay, cool ! So ... who has the credentials for the dockerhub/bigtop account? Please go ahead and create a wiki page that describes the workflow for getting password / verifying an image / pushing to docker hub
          Hide
          cos Konstantin Boudnik added a comment -

          Can we get less obsessed with with 'bigtop' prefix? I think we use too much E.g.

          bigtop/
            bigtop_toolchain/
            bigtop-deploy/
              puppet/
              vm/
              bigtop-dockerfiles/
          ...
          

          Let's just make it bigtop-deploy/dockerfiles/. I like the rest of it.

          Show
          cos Konstantin Boudnik added a comment - Can we get less obsessed with with 'bigtop' prefix? I think we use too much E.g. bigtop/ bigtop_toolchain/ bigtop-deploy/ puppet/ vm/ bigtop-dockerfiles/ ... Let's just make it bigtop-deploy/dockerfiles/ . I like the rest of it.
          Hide
          evans_ye Evans Ye added a comment -

          Hi Konstantin Boudnik,
          Aactually I was thinking about something like this to centralize dockerfiles:

          bigtop/
          	bigtop-deploy/
          	bigtop-dockerfiles/
          		deploy/
          			centos/
          				Dockerfile
          			debian
          			ubuntu
          		slaves/
          			centos
          			debian
          			ubuntu
          …
          

          But either way is ok for me. If we're going to auto-gen dockerfiles for those bigtop/slaves, then Konstantin Boudnik's version would be better. I'm happy to help dealing with stuffs to put those bigtop-deploy image up to dockerhub.

          Show
          evans_ye Evans Ye added a comment - Hi Konstantin Boudnik , Aactually I was thinking about something like this to centralize dockerfiles: bigtop/ bigtop-deploy/ bigtop-dockerfiles/ deploy/ centos/ Dockerfile debian ubuntu slaves/ centos debian ubuntu … But either way is ok for me. If we're going to auto-gen dockerfiles for those bigtop/slaves, then Konstantin Boudnik 's version would be better. I'm happy to help dealing with stuffs to put those bigtop-deploy image up to dockerhub.
          Hide
          cos Konstantin Boudnik added a comment -

          yeah, I see what you're saying. Do you think it would be a good idea to start dropping the bigtop[-_] prefix for the top-level directories in the project? E.g. just dockerfiles instead of bigtop-dockerfiles? And at some point we might even get rid of all of them?

          Show
          cos Konstantin Boudnik added a comment - yeah, I see what you're saying. Do you think it would be a good idea to start dropping the bigtop [-_] prefix for the top-level directories in the project? E.g. just dockerfiles instead of bigtop-dockerfiles ? And at some point we might even get rid of all of them?
          Hide
          luciano resende Luciano Resende added a comment -

          How about bigtop-containers...... As for the bigtop prefix, sure, but just get rid of them all at once.

          Show
          luciano resende Luciano Resende added a comment - How about bigtop-containers...... As for the bigtop prefix, sure, but just get rid of them all at once.
          Hide
          cos Konstantin Boudnik added a comment - - edited

          As for the bigtop prefix, sure, but just get rid of them all at once

          Sure, but shall we keep adding the new ones in the meanwhile?

          Show
          cos Konstantin Boudnik added a comment - - edited As for the bigtop prefix, sure, but just get rid of them all at once Sure, but shall we keep adding the new ones in the meanwhile?
          Hide
          evans_ye Evans Ye added a comment - - edited

          Surly removing bigtop prefix can improves readability, but this kind of big change may generates lots of documents update and probably breaks some features. Shall we do this improvement after major release?
          I prefer dockerfiles only because this indicates we only stores Dockerfiles. Users needs to build their own with customization or automatically download bigtop's image from dockerhub when executing Docker provisioner. However this is not a very strong reason
          To setup the process, I think we need to have a set of Jenkins job to build those docker images or we can leverage auto build which dockerhub provides.

          Show
          evans_ye Evans Ye added a comment - - edited Surly removing bigtop prefix can improves readability, but this kind of big change may generates lots of documents update and probably breaks some features. Shall we do this improvement after major release? I prefer dockerfiles only because this indicates we only stores Dockerfiles. Users needs to build their own with customization or automatically download bigtop's image from dockerhub when executing Docker provisioner. However this is not a very strong reason To setup the process, I think we need to have a set of Jenkins job to build those docker images or we can leverage auto build which dockerhub provides.
          Hide
          jayunit100 jay vyas added a comment - - edited

          regarding bigtop- prefix removal... there is alot of work using it... and alot of code & docs will be out of date if we remove it. can we keep the convention ?

          if not please create a jira, add that as a blocker for this one

          Show
          jayunit100 jay vyas added a comment - - edited regarding bigtop- prefix removal... there is alot of work using it... and alot of code & docs will be out of date if we remove it. can we keep the convention ? if not please create a jira, add that as a blocker for this one
          Hide
          jayunit100 jay vyas added a comment -

          Konstantin Boudnik can we have a MAINTAINER.txt entry for the dockerhub manager ? That person can push docker images for us in the interim of all this automation stuff. Im happy to play this role , or you or evans can , the key thing is the dockerhub admin needs to have the password...

          Show
          jayunit100 jay vyas added a comment - Konstantin Boudnik can we have a MAINTAINER.txt entry for the dockerhub manager ? That person can push docker images for us in the interim of all this automation stuff. Im happy to play this role , or you or evans can , the key thing is the dockerhub admin needs to have the password...
          Hide
          cos Konstantin Boudnik added a comment -

          I don't see why not? After all - it's your time and volunteer contribution. Thanks a lot for doing this!

          Show
          cos Konstantin Boudnik added a comment - I don't see why not? After all - it's your time and volunteer contribution. Thanks a lot for doing this!
          Hide
          cos Konstantin Boudnik added a comment -

          Shall we do this improvement after major release?

          Good point! And I wasn't pushing to make this huge change right away: in a future, perhaps. Was only saying that if we want to make the change, let's avoid adding bigtop_ prefixes to anything that will end up without them; hence reducing the amount of work in the future.

          Show
          cos Konstantin Boudnik added a comment - Shall we do this improvement after major release? Good point! And I wasn't pushing to make this huge change right away: in a future, perhaps. Was only saying that if we want to make the change, let's avoid adding bigtop_ prefixes to anything that will end up without them; hence reducing the amount of work in the future.
          Hide
          jayunit100 jay vyas added a comment -

          I think the plan is to encrypt a file with PGPs, and put it into the main repository.
          We can close this JIRA and then let anyone in the commuters commit docker images.

          Show
          jayunit100 jay vyas added a comment - I think the plan is to encrypt a file with PGPs, and put it into the main repository. We can close this JIRA and then let anyone in the commuters commit docker images.
          Hide
          jayunit100 jay vyas added a comment -

          this is solved via the pgp file, which will allow commiters to access all our stuff easily

          Show
          jayunit100 jay vyas added a comment - this is solved via the pgp file, which will allow commiters to access all our stuff easily

            People

            • Assignee:
              Unassigned
              Reporter:
              jayunit100 jay vyas
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development