Bigtop
  1. Bigtop
  2. BIGTOP-871

Add a Boxgrinder wrapper to Bigtop

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      There are certain improvements that I think can be made to the Bigtop VMs that are probably best accomplished by making a simple wrapper around Boxgrinder. Improvements include:

      • For including hypervisor-specific extensions, like VMWare Tools or Virtualbox Guest additions
      • More polishing of the resulting artifacts, like creating OVA appliances, tweak the VMX appliances
      • A good way to separate the boxgrinder configuration for each component

      I've done some tinkering in this direction and will post code for my ideas soon.

        Activity

        Hide
        Bruno Mahé added a comment -

        That sounds awesome!
        Unfortunately I recently learned that boxgrinder is now unmaintained. So if you already have the code handy or if it will not take long to implement, sure go ahead. If this is for a more long term effort, it may or may not be worth it.
        I am about to open a discussion about it on the mailing list.

        Show
        Bruno Mahé added a comment - That sounds awesome! Unfortunately I recently learned that boxgrinder is now unmaintained. So if you already have the code handy or if it will not take long to implement, sure go ahead. If this is for a more long term effort, it may or may not be worth it. I am about to open a discussion about it on the mailing list.
        Hide
        Sean Mackrory added a comment -

        I've put together a Bigtop-based example of what I've already done. It won't build right now because for some reason it's missing the default repositories, but this should demonstrate the concept sufficiently well.

        Given the discussion going on in the mailing list I think I'll hold off until we know what direction we want to head and then throw my wait behind that effort...

        Show
        Sean Mackrory added a comment - I've put together a Bigtop-based example of what I've already done. It won't build right now because for some reason it's missing the default repositories, but this should demonstrate the concept sufficiently well. Given the discussion going on in the mailing list I think I'll hold off until we know what direction we want to head and then throw my wait behind that effort...
        Hide
        Bruno Mahé added a comment -

        Great! Thanks!
        It's a little bit late for me to go over it now, but will try to do so tomorrow. Looks interesting though.

        Show
        Bruno Mahé added a comment - Great! Thanks! It's a little bit late for me to go over it now, but will try to do so tomorrow. Looks interesting though.
        Hide
        Roman Shaposhnik added a comment -

        Sean, regardless of the direction, I think it is good to stick to the small incremental improvements rule. This appears to be exactly that – a small incremental improvement. Would you mind turning this into a proper patch?

        Show
        Roman Shaposhnik added a comment - Sean, regardless of the direction, I think it is good to stick to the small incremental improvements rule. This appears to be exactly that – a small incremental improvement. Would you mind turning this into a proper patch?
        Hide
        Sean Mackrory added a comment -

        I'm actually thinking a better approach is to use Packer - which would allow us to share "provisioning" scripts with Jay Vyas' recent Vagrant work...

        Show
        Sean Mackrory added a comment - I'm actually thinking a better approach is to use Packer - which would allow us to share "provisioning" scripts with Jay Vyas' recent Vagrant work...
        Hide
        jay vyas added a comment -

        Do we really have a high priority on curating raw VMs? If not, I think raw vagrant on top of existing vagrant boxes is much more efficient to maintain and easier to customize for developers .

        Instead:

        0) Let boxgrinder packages stay as they are, or else remove them.
        1) Take existing vagrant box's from the vagrant community (vagrant.es).
        2) Maintain our existing puppet recipes to work really well on vagrant.
        3) For binary images (if we really need them)... Use vagrant repackage to repackage boxes.
        4) Do the same for docker (see BIGTOP-1154).

        I know its a "vagrant-centric" solution but I think , alongside the docker ticket, ( BIGTOP-1154 ), we will be able to support most use cases pretty effectively, and it frees bigtop of having to manage and create ISOs.

        Show
        jay vyas added a comment - Do we really have a high priority on curating raw VMs? If not, I think raw vagrant on top of existing vagrant boxes is much more efficient to maintain and easier to customize for developers . Instead: 0) Let boxgrinder packages stay as they are, or else remove them. 1) Take existing vagrant box's from the vagrant community (vagrant.es). 2) Maintain our existing puppet recipes to work really well on vagrant. 3) For binary images (if we really need them)... Use vagrant repackage to repackage boxes. 4) Do the same for docker (see BIGTOP-1154 ). I know its a "vagrant-centric" solution but I think , alongside the docker ticket, ( BIGTOP-1154 ), we will be able to support most use cases pretty effectively, and it frees bigtop of having to manage and create ISOs.
        Hide
        Sean Mackrory added a comment - - edited

        I've actually had to create quite a lot of "raw" VMs for demonstration or learning purposes. I seriously doubt vagrant and docker are going to be acceptable platforms for less-technical end-users any time soon. Furthermore, the reason I suggest Packer is that it can share the provisioner with Vagrant with little modification, if any. Also, no one has to manage and create ISOs if they don't want to. A bigtop release is just of source code. Binary packages are only provided as a convenience. If I want raw VMs, I'll do the work when I need to.

        Show
        Sean Mackrory added a comment - - edited I've actually had to create quite a lot of "raw" VMs for demonstration or learning purposes. I seriously doubt vagrant and docker are going to be acceptable platforms for less-technical end-users any time soon. Furthermore, the reason I suggest Packer is that it can share the provisioner with Vagrant with little modification, if any. Also, no one has to manage and create ISOs if they don't want to. A bigtop release is just of source code. Binary packages are only provided as a convenience. If I want raw VMs, I'll do the work when I need to.
        Hide
        jay vyas added a comment -

        Thats a good point: So lets keep pushing forward. So, to get us back on track, is it fair to say that the goal of this JIRA is :

        • To migrate to packer to replace boxgrinder for creating Raw (Virtualbox, VMWare, KVM) VMs and
        • (bouns) To also configure packer also to output a vagrant box for each VM created.
        Show
        jay vyas added a comment - Thats a good point: So lets keep pushing forward. So, to get us back on track, is it fair to say that the goal of this JIRA is : To migrate to packer to replace boxgrinder for creating Raw (Virtualbox, VMWare, KVM) VMs and (bouns) To also configure packer also to output a vagrant box for each VM created.
        Hide
        Bruno Mahé added a comment -

        Packer looks nice!
        +1 to deprecate boxgrinder once we have some working recipes for packer.

        Show
        Bruno Mahé added a comment - Packer looks nice! +1 to deprecate boxgrinder once we have some working recipes for packer.

          People

          • Assignee:
            Sean Mackrory
            Reporter:
            Sean Mackrory
          • Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:

              Development