packer-arch
packer-arch copied to clipboard
elasticdog
Made some changes to how this is laid out so it will work on Atlas
I got the VMware tools working for Arch and plan on pull requesting that back upstream, I also love wrapacker and updated it to handle the fact that I needed to split the Parallels template out of the base template (but still improved the overall structure using common install files so you don't need to make changes 3 places).
Let me know if you have any questions or if there is something you think can be done a better way. I took a lot of inspiration from boxcutter/ubuntu but you had 90% of what I needed to make it happen.
This looks good.
My only complaint is that the standard arch-template.json doesn't work unless you feed in Atlas creds.
If someone doesn't use Atlas ( like me :raising_hand: ) then there's a little bit of editing that needs to be done to get it to work right off the bat, and the turn-key usefulness of this goes away.
I'd prefer if we could roll the Atlas stuff into the wrapacker script, or have Atlas disabled by default.
@tomswartz07 I agree, I've been trying to figure out if it is possible to feed in extra post processors at runtime as user variables or from reading the environment. One of the limitations of Packer/Atlas is you need to predefine the environment variables for all builds in their service, or you need to use Packer to 'packer push' the template to the service, and I don't know if it supports passing variables at that time.
Awesome stuff @dragon788! I have been meaning to split up the files to reduce duplication for a while and adding support for Atlas is a great idea. I do agree with @tomswartz07 that we should have the default workflow be functional without Atlas being involved, but still have a nice means of publishing boxes. I can mess around with this process as well to see if we can find a good solution. I do have an Atlas account and would be fine on maintaining "official" packer-arch images once we have this process ironed out.
That said, there are a lot of changes here that aren't directly related to the goal at hand, which can make things harder to test/verify. It would be a lot easier to review if those were split out into dedicated/smaller PRs...for instance, changes like https://github.com/dragon788/packer-arch/commit/538835f6fc708801b306a9ae28d5b711a71d7dad worry me a bit, as that original workaround was in place for a very specific bug. If that workaround isn't working anymore, I'd like to investigate that issue further. Admittedly, that particular commit of yours isn't in this final PR, as later merges got rid of your change...
Related to that, with the long history of these changes and the various merges you've done, there are also some updates here that revert previous bug fixes. For instance, the changes done by #35 to fix the pacman cache cleaning has been removed by this PR.
I'm not sure how best to proceed, as I absolutely appreciate the work you've done, would like to commit 95% of it, and don't want to burden you completely...but I also am worried about introducing regressions and not having a clean history to follow. Would you be willing to work with me on splitting out some of these changes, basing them off of the current master, and submitting them through separate PRs to get to this end-goal?
@elasticdog I'd definitely love to work with you to get this in better shape if its going to become an official build. I had forgotten about the change I'd made from the delayed poweroff bug, I'm sure the bug is still present. I think I was having issues related to something else and that "fixed" it. I also hadn't caught the subtlety of the cache cleaning, using yes makes way more sense now. I really opened this to get some more eyes on it. I can definitely go through and make it cleaner by doing a rebase and dropping any commits on my fork that you don't think have provided value or caused regressions.
Don't forget that 'git cherry-pick' can be your best friend in this case! :) On Jan 6, 2016 10:02 PM, "dragon788" [email protected] wrote:
@elasticdog https://github.com/elasticdog I'd definitely love to work with you to get this in better shape if its going to become an official build. I had forgotten about the change I'd made from the delayed poweroff bug, I'm sure the bug is still present. I think I was having issues related to something else and that "fixed" it. I also hadn't caught the subtlety of the cache cleaning, using yes makes way more sense now. I really opened this to get some more eyes on it. I can definitely go through and make it cleaner by doing a rebase and dropping any commits on my fork that you don't think have provided value or caused regressions.
— Reply to this email directly or view it on GitHub https://github.com/elasticdog/packer-arch/pull/41#issuecomment-169534411 .
Just want to note that Atlas was discontinued a while back [1].
[1] https://www.hashicorp.com/blog/vagrant-cloud-migration-announcement
