BoxGrinder Build
  1. BoxGrinder Build
  2. BGBUILD-354

Providing path to child appliance file so that building hierarchy of AMI's is smoother.

    Details

    • Type: Feature Request Feature Request
    • Status: Open Open (View Workflow)
    • Priority: Optional Optional
    • Resolution: Unresolved
    • Affects Version/s: 0.10.1
    • Fix Version/s: None
    • Component/s: Appliance definition
    • Labels:
      None
    • Similar Issues:
      Show 10 results 

      Description

      When build an appliance, it would be easier if we could provide a path to a child appliance file. This avoids the need that both the appliance files shoul dbe present in the same directory. It facilitates a good structure when you want to automate the boxgrinder process to build a hierarchy of appliances.

        Activity

        Hide
        Chris Rankin
        added a comment -

        Agree with this. We have a large heirarchy of .appl files, all under source control, that we use as "facets" / "mix-ins". In order to build a VM, we use Jenkins to collect all of the different facets and run boxgrinder over them. Each facet therefore lives in / is extracted into its own subdirectory. We do not want these subdirectory names to be written into our final VM image. However, nor can we (reliably) merge the contents of all of the facet subdirectories into the current working directory. But at the moment, boxgrinder must have all of the .appl files in the current working directory!

        And so the current strategy is to copy all of the .appl files out of the facet subdirectories into the current working directory instead. Our CentOS6-base facet therefore looks something like this:

        files:
         "/tmp":
          - "CentOS6-base/sysconfig/clock"
          - "CentOS6-base/sysconfig/i18n"
          - "CentOS6-base/sysconfig/kernel"
          - "CentOS6-base/sysconfig/keyboard"
          - ... etc
        
        post:
         base:
          - "cp /tmp/CentOS6-base/sysconfig/clock /etc/sysconfig/clock"
          - "cp /tmp/CentOS6-base/sysconfig/i18n /etc/sysconfig/i18n"
          - "cp /tmp/CentOS6-base/sysconfig/kernel /etc/sysconfig/kernel"
          - "cp /tmp/CentOS6-base/sysconfig/keyboard /etc/sysconfig/keyboard"
          - ... etc
        

        Without all this hideous messing around in the /tmp directory, the CentOS6-base directory name would be written into the VM, of course. And we definitely don't want that.

        I can't see an alternative strategy to this at the moment. The files section is documented as being relative to the .appl file, but all .appl files must be placed in the current working directory. Which to my mind conflicts with the usefulness of appliances section.

        It would be nicer to be able to use the facet like this:

        applicances:
          - "CentOS6-base/CentOS6-base.appl"
        

        so that the CentOS6-base facet itself could be written more sanely as:

        files:
         "/etc":
          - "sysconfig/clock"
          - "sysconfig/i18n"
          - "sysconfig/kernel"
          - "sysconfig/keyboard"
        

        without fuss in /tmp.

        Show
        Chris Rankin
        added a comment - Agree with this. We have a large heirarchy of .appl files, all under source control, that we use as "facets" / "mix-ins". In order to build a VM, we use Jenkins to collect all of the different facets and run boxgrinder over them. Each facet therefore lives in / is extracted into its own subdirectory. We do not want these subdirectory names to be written into our final VM image. However, nor can we (reliably) merge the contents of all of the facet subdirectories into the current working directory. But at the moment, boxgrinder must have all of the .appl files in the current working directory! And so the current strategy is to copy all of the .appl files out of the facet subdirectories into the current working directory instead. Our CentOS6-base facet therefore looks something like this: files: "/tmp" : - "CentOS6-base/sysconfig/clock" - "CentOS6-base/sysconfig/i18n" - "CentOS6-base/sysconfig/kernel" - "CentOS6-base/sysconfig/keyboard" - ... etc post: base: - "cp /tmp/CentOS6-base/sysconfig/clock /etc/sysconfig/clock" - "cp /tmp/CentOS6-base/sysconfig/i18n /etc/sysconfig/i18n" - "cp /tmp/CentOS6-base/sysconfig/kernel /etc/sysconfig/kernel" - "cp /tmp/CentOS6-base/sysconfig/keyboard /etc/sysconfig/keyboard" - ... etc Without all this hideous messing around in the /tmp directory, the CentOS6-base directory name would be written into the VM, of course. And we definitely don't want that. I can't see an alternative strategy to this at the moment. The files section is documented as being relative to the .appl file, but all .appl files must be placed in the current working directory. Which to my mind conflicts with the usefulness of appliances section. It would be nicer to be able to use the facet like this: applicances: - "CentOS6-base/CentOS6-base.appl" so that the CentOS6-base facet itself could be written more sanely as: files: "/etc" : - "sysconfig/clock" - "sysconfig/i18n" - "sysconfig/kernel" - "sysconfig/keyboard" without fuss in /tmp .
        Hide
        Chris Rankin
        added a comment -

        The basic issue is that it is difficult to assemble appliances from multiple sources, and it can be re-expressed thus:

        Suppose we want to bake scriptA from Project A and scriptB from Project B into /usr/local/bin. So we check Project A out into a subdirectory directoryA, and Project B out into a subdirectory directoryB. We then try to write an .appl file to handle this.

        Perhaps:

        files:
          "/usr/local/bin":
          - "scriptA"
          - "scriptB"
        

        Boxgrinder fails here because it cannot find scriptA or scriptB without their correct relative paths, so then we try:

        files:
          "/usr/local/bin":
          - "directoryA/some/path/scriptA"
          - "directoryB/some/other/path/scriptB"
        

        But this doesn't work either because we end up with /usr/local/bin/directoryA/some/path/scriptA instead of just /usr/local/bin/scriptA etc. Which is why we end up laundering both scripts through /tmp instead:

        files:
          "/tmp":
          - "directoryA/some/path/scriptA"
          - "directoryB/some/other/path/scriptB"
        
        post:
          base:
          - "cp /tmp/directoryA/some/path/scriptA /usr/local/bin"
          - "cp /tmp/directoryB/some/other/path/scriptB /usr/local/bin"
          - "rm -rf /tmp/directory[AB]"
        

        What boxgrinder is missing is a way of differentiating between "source" paths (used for finding) and "destination" paths (written to the image).

        Show
        Chris Rankin
        added a comment - The basic issue is that it is difficult to assemble appliances from multiple sources, and it can be re-expressed thus: Suppose we want to bake scriptA from Project A and scriptB from Project B into /usr/local/bin . So we check Project A out into a subdirectory directoryA , and Project B out into a subdirectory directoryB . We then try to write an .appl file to handle this. Perhaps: files: "/usr/local/bin" : - "scriptA" - "scriptB" Boxgrinder fails here because it cannot find scriptA or scriptB without their correct relative paths, so then we try: files: "/usr/local/bin" : - "directoryA/some/path/scriptA" - "directoryB/some/other/path/scriptB" But this doesn't work either because we end up with /usr/local/bin/directoryA/some/path/scriptA instead of just /usr/local/bin/scriptA etc. Which is why we end up laundering both scripts through /tmp instead: files: "/tmp" : - "directoryA/some/path/scriptA" - "directoryB/some/other/path/scriptB" post: base: - "cp /tmp/directoryA/some/path/scriptA /usr/local/bin" - "cp /tmp/directoryB/some/other/path/scriptB /usr/local/bin" - "rm -rf /tmp/directory[AB]" What boxgrinder is missing is a way of differentiating between "source" paths (used for finding) and "destination" paths (written to the image).

          People

          • Assignee:
            Unassigned
            Reporter:
            Supriya Shivkumar
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: