The short answer is that we produce our OVA files using VMware's OVFTool.
The long answer, is that all of our builds (e.g. ISO, OVA, Xen, Openstack, etc) are generated by our buildtasks toolkit. Buildtasks is included by default in our TKLDev appliance (which is essentially our "build tool in a box"). The bt-vm script is the top level script that converts an ISO to both of our VM builds (OVA & VMDK). The heavy lifting is done by the bin/vm-bundle script.
Essentially the process unpacks the ISO, writes the contents to a VMDK image file and then creates the legacy VMX file. This is zipped up for the VMDK build. It then processes those same files (i.e. the VMX and VMDK), via the OVFTool, to create the OVA file. As you can see from the script(s) a bit of hackery is involved, but it works incredibly smoothly.
If you care to provide a little more context to your question, I'm happy to share more specifics on how and why we do particular things.
The context is that I'm using tkldev to make an appliance of https://gravitational.com/gravity. I've successfully created the ISO, but had somehow missed the buildtasks, so I didn't see how to take the next step. Time to get reading! Thanks again for the link!
I probably should have also mentioned that there is a bin/vm-setup script which will install all the dependencies, with the exception of the OVFTool (which unfortunately isn't open source, so we can't redistribute it). If the OVFTool isn't already installed, it will give instructions on installing it.
Also, as you are using a custom ISO you created yourself, you may need to rebuild the ISO (using bt-iso) to generate the hash file (which buildtasks checks when making the OVA file). Either that, or manually generate the hash file for your ISO (see bin/generate-signature). Or simply comment out the relevant lines that require/check the hash file.
Good luck with it all and if you have any feedback on buildtasks, I'd be interested to hear.
So I've been banging around with bt-iso for a bit now. My general impression is that it is optimized for a production build environment, less so for a development environment.
Network connectivity. The git clone/pull actions (lines 88, 92) require network connectivity. They're also hardcoded to https://github.com/turnkeylinux-apps... ;)
Assumed git workflow. I certainly don't commit every time I make a change, so I worked around this by sharing my working directory to the virtual machine. This caused file ownership problems with the build, which I worked around with `ln -s /tmp/build /mnt/hgfs/gravity/`to put the build folder back onto an ext3 fs. The script doesn't seem to take advantage of the BT_BUILDS setting used elsewhere.
Disk space. The 20GB that the tkldev OVA starts with doesn't leave a lot of headroom, and I didn't initially realize that exporting BT_DEBUG=1 to increase logging would have the side effect of not cleaning up various intermediate build artifacts. The defaults in config.example/common.cfg hint at the disk space problem -- there is a clear assumption that additional mount points will be required (but no documentation along these lines). This was obfuscated by some red herring error messages about iso being corrupt, when really the disk was exhausted.
Lack of defaults. As a newcomer to the project, I would of course love if the non-BT_PUBLISH_* variables all had reasonable defaults so that test build (presumably of core) could succeed without any additional configuration.
Sourcing config/common.cfg. My general inclination rather than to drop a config file into the tkldev appliance was to export some BT_* env vars in my build script, which was not possible because sourcing config/common.cfg failed. It would be preferable to disqualify a build by testing -n the necessary BT_* env vars and make sourcing of that file optional with -f $BT_CONFIG/common.cfg conditionals.
Changelog version. It was not immediately obvious to me that the output version of my iso was derived from the changelog (similar to rpmbuild). As an idiot in a hurry, this resulted in me wondering why my new build had generated turnkey-core-15.0-stretch-amd64.iso
You are correct. It is primarily intended for internal TurnKey purposes (that's what it was built for). We started including it in TKLDev because people (similar to yourself) asked for it to be available so that they could do their own alternate builds. There have been some minor improvements, but it is mostly still primarily for our purposes. In a perfect world, we'd make it more generically useful, but it always seems to get pushed down the priorities...
1. Are you sure they're hard coded to TKL GH urls?! TBH I haven't double checked the code, but I'm pretty sure that they just default to the current git remote. If you haven't set up an alternate git remote, then they certainly would still try to access the TKL GH repos.
2. Again, I'm not completely sure on this one. Generally I do make sure everything is committed before I build, but not always. From time to time (especially early in development, or if I'm just doing a local build to test something out) I will build from uncommitted code. So long as it has a git remote configured that is equal to, or behind the local code, then it should "just work". If the remote has additional commits, and you have uncommitted code, then that can certainly cause issues.
3. Yes great point. It should be better documented. The 20 GB VMDK is a generic default and certainly unlikely to be sufficient for any serious use. Point certainly taken. Next time I give TKLDev some love, I'll make an effort to make that more explicit. At least in the docs.
4. Another good point. That is totally reasonable, and we really should consider improving that.
5. And another one... I quite like your idea of allowing environmental vars to be set, rather than requiring a config file.
6. I think that it is noted somewhere in the docs, but again, it probably should be quite clearly documented somewhere.
Thanks tons for taking the time to post feedback regarding your experience. I can't promise when these things might be addressed, but I'll certainly keep them in mind and at least hope to make some subtle improvements along the lines of some of the lower hanging fruit for the next release. FWIW it's only been included since v14.2 (the release prior to v15.0) so whilst we've been using it forever, and it has been public for almost as long, it's only been a default part of TKLDev for a relatively brief time (in context of TurnKey releases anyway...).
So thanks again. Any further feedback is always appreciated and if you have any questions, please ask. Hopefully bt-vm will "just work" now (it should I hope...).
Hey Adam
The short answer is that we produce our OVA files using VMware's OVFTool.
The long answer, is that all of our builds (e.g. ISO, OVA, Xen, Openstack, etc) are generated by our buildtasks toolkit. Buildtasks is included by default in our TKLDev appliance (which is essentially our "build tool in a box"). The bt-vm script is the top level script that converts an ISO to both of our VM builds (OVA & VMDK). The heavy lifting is done by the bin/vm-bundle script.
Essentially the process unpacks the ISO, writes the contents to a VMDK image file and then creates the legacy VMX file. This is zipped up for the VMDK build. It then processes those same files (i.e. the VMX and VMDK), via the OVFTool, to create the OVA file. As you can see from the script(s) a bit of hackery is involved, but it works incredibly smoothly.
If you care to provide a little more context to your question, I'm happy to share more specifics on how and why we do particular things.
Thanks for the link!
The context is that I'm using tkldev to make an appliance of https://gravitational.com/gravity. I've successfully created the ISO, but had somehow missed the buildtasks, so I didn't see how to take the next step. Time to get reading! Thanks again for the link!
Sounds cool!
That certainly sounds like a cool project! :)
I probably should have also mentioned that there is a bin/vm-setup script which will install all the dependencies, with the exception of the OVFTool (which unfortunately isn't open source, so we can't redistribute it). If the OVFTool isn't already installed, it will give instructions on installing it.
Also, as you are using a custom ISO you created yourself, you may need to rebuild the ISO (using bt-iso) to generate the hash file (which buildtasks checks when making the OVA file). Either that, or manually generate the hash file for your ISO (see bin/generate-signature). Or simply comment out the relevant lines that require/check the hash file.
Good luck with it all and if you have any feedback on buildtasks, I'd be interested to hear.
Initial review of bt-iso
So I've been banging around with bt-iso for a bit now. My general impression is that it is optimized for a production build environment, less so for a development environment.
Moving on to bt-vm now, fingers crossed!
Thanks for the feedback and input
You are correct. It is primarily intended for internal TurnKey purposes (that's what it was built for). We started including it in TKLDev because people (similar to yourself) asked for it to be available so that they could do their own alternate builds. There have been some minor improvements, but it is mostly still primarily for our purposes. In a perfect world, we'd make it more generically useful, but it always seems to get pushed down the priorities...
1. Are you sure they're hard coded to TKL GH urls?! TBH I haven't double checked the code, but I'm pretty sure that they just default to the current git remote. If you haven't set up an alternate git remote, then they certainly would still try to access the TKL GH repos.
2. Again, I'm not completely sure on this one. Generally I do make sure everything is committed before I build, but not always. From time to time (especially early in development, or if I'm just doing a local build to test something out) I will build from uncommitted code. So long as it has a git remote configured that is equal to, or behind the local code, then it should "just work". If the remote has additional commits, and you have uncommitted code, then that can certainly cause issues.
3. Yes great point. It should be better documented. The 20 GB VMDK is a generic default and certainly unlikely to be sufficient for any serious use. Point certainly taken. Next time I give TKLDev some love, I'll make an effort to make that more explicit. At least in the docs.
4. Another good point. That is totally reasonable, and we really should consider improving that.
5. And another one... I quite like your idea of allowing environmental vars to be set, rather than requiring a config file.
6. I think that it is noted somewhere in the docs, but again, it probably should be quite clearly documented somewhere.
Thanks tons for taking the time to post feedback regarding your experience. I can't promise when these things might be addressed, but I'll certainly keep them in mind and at least hope to make some subtle improvements along the lines of some of the lower hanging fruit for the next release. FWIW it's only been included since v14.2 (the release prior to v15.0) so whilst we've been using it forever, and it has been public for almost as long, it's only been a default part of TKLDev for a relatively brief time (in context of TurnKey releases anyway...).
So thanks again. Any further feedback is always appreciated and if you have any questions, please ask. Hopefully bt-vm will "just work" now (it should I hope...).
Add new comment