That's great Ken. 

I'll have a look.   My .fog file was correct but I was missing that 
ec2.yaml.  

I get the user experience thing, it'll evolve and I'll help if I can.   

Would I be right to assume you built your images with packer?   

Thanks! 

On Tuesday, 7 October 2014 04:37:43 UTC-6, Ken Barber wrote:
>
> >> I was just testing the host config file from puppetdb coupled with the 
> documentation on the beaker documentation. 
> > 
> > Those docs honestly look old, they are still mentioning blimpy which I 
> > effectively deprecated/superseded with the aws_sdk driver. 
> > 
> >> I was actually going to omit the error message.  That's actually all of 
> it except for the json output of the compiled beaker configs.   I can send 
> the full output  in the morning. 
> > 
> > Send the full output and the configuration and I can take a closer 
> > look. Anything less, I'll probably struggle. 
> > 
> >> It looks like the Google Compute Engine docs  are more complete...  It 
> doesn't matter where it runs. Mostly looking for a free tier cloud to get 
> started with.   I'm not sure aws micro would even be big enough anyways. 
> But it'd be cool to get it working. 
> > 
> > Sure, well we use EC2 heavily so I'm happy to help you there, I know 
> > some people use Google Compute Engine also, but I have no intimate 
> > knowledge of how this one works. 
>
> Actually Brett, maybe this is a better approach. I've got a working 
> new project here showing beaker + beaker-rspec with EC2 support: 
>
> https://github.com/kbarber/sample-beaker 
>
> And you can see how I've launched it here: 
>
> https://gist.github.com/kbarber/850a7d88fce409592bab 
>
> Perhaps a better example will set you straight :-). It does fail 
> incidentally, but it is kind of meant to as an example. Perhaps you 
> can start with this project skeleton and modify to taste. 
>
> Now as Justin mentioned, you do need a ~/.fog file - this was 
> primarily to be compatible with the old Blimpy driver, but alas, we 
> don't use Fog any more. The file should look something like: 
>
> :default: 
>   :aws_access_key_id: AAAAAA 
>   :aws_secret_access_key: BBBBBB 
>
> (And obviously match your own EC2 access keys and secrets) 
>
> Also pay close attention to the config/image_templates/ec2.yaml file 
> ... these map names of images to AMIs today, and the AMIs provided are 
> the ones we use for our own testing, but you might want to maintain 
> your own list. This is entirely up to you, just be aware each AMI 
> needs a small amount of pre-setup if you want to create your own (that 
> is certain minimal things might need 'baking' into the image, but 
> nothing drastic). Of course, you are free to use the ones here, but if 
> you need customisation I'd suggest forking your own images :-). 
>
> Let me know how you get on with that. I think generally speaking all 
> of this needs an overhaul in regards to usability, a lot of this 
> awkward layout is due to backwards compatibility from legacy elements. 
> That aside, once you get the fundamental elements right it should be 
> okay. 
>
> 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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/cea098e8-56e9-4c17-b02e-5cfc209be3d7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to