> The default.yaml is in the gist I supplied. I used the el6 and centos6 64 > from your sample project.
Taking a look again, its even more confusing than that, the platform name you have used is pointing at one of the very very old AMI's. The newer ones we actually use are private, but I don't have the ability to make it public. Looks like its locked up in someone elses older amazon account. Sorry about that. This is why we are slowly replacing these older ones, the management of them has slipped, my fault mainly - we'll work on that for PuppetDB. > An Ami search on aws by the name or Ami ID didn't turn up any results which > is why I thought they were private. > > I'll try building an Ami with packer. Are there any conventions that need > to go into the VM required by beaker? I think the main requirement to make your life easier, is to allow logging in from root (which can be often disabled) this is often done by changing just sshd_config (and hupping/restarting sshd), and removing the /root/.ssh/authorized_keys files also. Some distros support doing this kind of thing via cloud-init as well, so you can pass something like: #cloud-config disable-root: false Into the user_data field of packer for example, but not this will not persist on its own, you can change the configuration in /etc/cloud/ and bake that setting into the image. This usually affects Debian/Ubuntu images I believe, I haven't built one of the newer centos images in a while so try firing up the image and checking if it has /etc/cloud/ in its build, this usually indicates its got some sort of cloud-init. Having said that, someone has a patch up for beaker to allow logging in as non-root and 'fixing' this: https://github.com/puppetlabs/beaker/pull/478 Beyond that it depends on the tests and helpers you want to use. Both 'curl' and 'git' are good tools to have around on an image, since a lot of tests can utilize these commands, having said that some tools on top of the image can most certainly be installed by beaker in the spec_helper_acceptance.rb there is a section for doing this _before_ the suite runs. In fact, the base beaker stuff will attempt to install items for you, like timing is important so the code goes to lengths to make sure the the image has the right tools before it uses ntp to update the time. Having the tooling there (I believe it uses ntpdate? but look at your log output from beaker it will tell you) should make that exercise mildly faster. Starting simple, and trying to run tests against an image is usually a good move in general, and being additive when you need it. Like I said you have two choices most of the time - bake in a tool, or do it during the testing run _before_ suite ... its really dependant on the wider problem you are going to solve with the image. Baking items into the image will of course speed up the exercise at test time, at the cost of forcing you to remake it when it needs a change. Starting conservatively with what goes into the image I think is a good idea. After that you'll start to see the wider problems when you run your tests a lot ... such as the flakiness of public mirrors :-). But thats a story for another day :-). ken. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAE4bNT%3DmaOQ9QvoVC-e9DkQm%2Bs7iRDrgt3%3Dvn%2BHYU%3D_Zvsw%3DAQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
