Aminator cmd line questions

[Carl Quinn]

The command line options used in the "Aminate an Asgard AMI" tutorial:

   https://github.com/Netflix/aminator/wiki/Aminate-an-Asgard-AMI

don't match the current version. The tutorial uses -p to define a package, while the 1.2.0 version does not have a -p, but takes the package_spec as the last argument.

Which is the newer command line syntax?

And if the 1.2.0 form is correct, what is the right package_spec for getting asgard for the tutorial?

Oh, btw, regarding the -B ami-86e15bef in the tutorial: it looks like that AMI is in us-east-1, and an equivalent one in us-west-1 is ami-f61630b3.

  CentOS-6-x86_64-20121031-ebs-...

maybe you could list the IDs for each of the us regions.

Now, when I run:

% aminate -B ami-86e15bef asgard

I get a big nasty:

IOError: [Errno 2] No such file or directory: '/var/log/aminator/asgard-201305090428.log'

How do you recommend that I track this down?

[Carl Quinn]

I figured out that error was caused by /var/log/aminator/ needing to be created before running aminate.

Then I ran into /var/aminator/lock/ needing to be created, ok fixed that.

Now:

  File "/usr/lib/python2.6/site-packages/aminator/plugins/cloud/ec2.py", line 171, in attach_volume

    self.allocate_base_volume(tag=tag)

  File "/usr/lib/python2.6/site-packages/aminator/plugins/cloud/ec2.py", line 150, in allocate_base_volume

    rootdev = context.base_ami.block_device_mapping[context.base_ami.root_device_name]

KeyError: u'/dev/sda1'

Think something's up with my sda devices? This is just the generic CentOS 6.3.

[K Vick]

Glad you figured it out Carl.  Apologies about the bad documentation, it was good docs until the Great Big Pull Request.   The dust is starting to settle and we should take another pass at the docs to reduce grief and confusion.

You ran into Issue 26 (formerly known as issue 23).  You're workaround is the best solution until we get it sorted out.

Which region did you wind up using?  I'll try it tomorrow on a fresh instance and see if I can reproduce it on 6.3.  Mike may also know the answer off the top of his head.

K

[Carl Quinn]

I am using us-west-1 for our tooling systems for the same reasons that you guys are :)

But I have not yet gotten past the problem with /dev/sda1. Is that another case of something needing to be created first?

[Michael Tripoli]

Hey, Carl.

There are a couple of problems in using this AMI. First, it's registration seems broken. The rootDeviceName doesn't match up with any deviceNames in the AMI's blockDeviceMapping. This is what is causing aminate to croak. Even if this weren't broken, you'd have problems aminating against this AMI because the snapshot is not public. If you really want to use this image you could:

- launch an instance of the AMI

- (you may get by with ec2cim here but that may preserve the broken device mapping. instead)

- snapshot the root volume

- register the snapshot with sane device mappings.

Mike

<DescribeImagesResponse xmlns="http://ec2.amazonaws.com/doc/2013-02-01/">

    <requestId>8d97cab4-3971-49bf-b0fc-28505339156f</requestId>

    <imagesSet>

        <item>

            <imageId>ami-f61630b3</imageId>

<snip>

            <rootDeviceName>/dev/sda1</rootDeviceName>

            <blockDeviceMapping>

                <item>

                    <deviceName>/dev/sda</deviceName>

<snip>

        </item>

    </imagesSet>

</DescribeImagesResponse>"

--
You received this message because you are subscribed to the Google Groups "Aminator" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aminator+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Carl Quinn]

I'm not particular about what image to use. Any CentOS 6 or even Amzn linux would probably be OK. Do you know of any in us-west-1 that I could start from?

Or, will the inability to access the snapshot be a general issue with using public AMIs? And thus I will need to make my own snapshot?

[Michael Tripoli]

It's more likely the latter - you'll need to start from your own AMI. I don't know of any public AMIs with public snapshots and Amazon doesn't make it easy to find out, either. You can list public AMIs and public snapshots but you'll have to do the join yourself. 

On Thu, May 9, 2013 at 10:05 AM, Carl Quinn <carl....@gmail.com> wrote:

I'm not particular about what image to use. Any CentOS 6 or even Amzn linux would probably be OK. Do you know of any in us-west-1 that I could start from?

Or, will the inability to access the snapshot be a general issue with using public AMIs? And thus I will need to make my own snapshot?

[Brian Moyles]

The Amazon Linux AMIs have public snaps for sure. That came in handy.

There are a few tutorials out there on laying down a manual foundation I could dig up, too, if you really wanted to stick with CentOS 6.x.

[Brian Moyles]

Really though, step 1 of using aminator is getting a foundation image you can use for baking.  ec2cim also takes block device mapping arguments if I'm not mistaken, so in the very worst case you'd have to launch and snap like Mike suggested. Cleaner would be to lay down a vanilla CentOS onto an empty volume, though. 

This looks to be a fairly solid overview of that process for CentOS

http://www.idevelopment.info/data/AWS/AWS_Tips/AWS_Management/AWS_10.shtml

Skip towards the middle of the page for the actual AMI building piece.

[K Vick]

I removed that wiki page as it was basically wrong :(  Sorry for the inconvenience.

I'll get an updated version up next week.  I do have a wiki page on creating an Ubuntu foundation, but that doesn't help you.

K