Made some changes to how this is laid out so it will work on Atlas #41
Conversation
You can't ssh as root by default, so use a user that will succeed.
Parallels is only supported on darwin as a build platform.
I guess in an hour I'll find out, but I'm putting it back for the next build.
Adding scripts folder and provisioners
… or new install-arch-base
…ection it used to be in
…ng packer directly uses new scripts directory
…ng packer directly uses new scripts directory
… two can be built on any platform, also added default and parallels override to wrapacker for this new file
…r in Atlas, but can still be run via wrapacker
| @@ -0,0 +1,61 @@ | |||
| { | |||
There was a problem hiding this comment.
This file is also json file.
Please add json extension.
There was a problem hiding this comment.
Good call, I had removed the extension when pushing to packer because it was building Parallels, but afterwards noticed that I hadn't actually removed it from the base template which meant the extension wasn't the problem.
| [VirtualBox](https://www.virtualbox.org/), and Vagrant installed, you can jump right in | ||
| with: | ||
|
|
||
| vagrant init dragon788/arch-ala-elasticdog; vagrant up --provider virtualbox |
There was a problem hiding this comment.
Should we publish an 'official' packer-arch vagrant files here, rather than use @dragon788's version?
This way, @dragon788 can do his thing without worrying about messing up the upstream project.
|
This looks good. My only complaint is that the standard I'd prefer if we could roll the Atlas stuff into the |
|
@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 dragon788@538835f 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! :)
|
|
Just want to note that [1] https://www.hashicorp.com/blog/vagrant-cloud-migration-announcement |
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.