Call for ideas for Ubuntu cloud / [UEC|EC2] images / cloud-init

187 views
Skip to first unread message

Scott Moser

unread,
Sep 28, 2010, 4:55:17 PM9/28/10
to ec2u...@googlegroups.com, ubuntu...@lists.ubuntu.com
Hello,
Sorry for the cross-post/duplicate thread, but I'm interested in
getting input from as large of a community as possible, and I don't think
there is much overlap between the ec2ubuntu, ubuntu-cloud, and
ubuntu-devel lists.

Allison Randal sent requests for ideas / brainstorming [1,2].
I'd like to extend that thread here. I am willing to pick up any
pieces and bring them back to the main thread. There are also ideas being
dumped at [3]. The key point is that we want your input.

If you've used Ubuntu Enterprise Cloud, or our UEC/EC2 Images, or
cloud-init, we want to hear your thoughts on what we can do better. If
you're not using UEC or the UEC Images, why not?

What could Ubuntu Enterprise Cloud do that it doesn't do?
What could it do better?
What do our UEC/EC2 images do not-so-well?
What cool things could they do?
What pain points have you come across when using "Ubuntu in the Cloud"

We want to make "Ubuntu in the Cloud" as famously simple as Ubuntu is
known to be elsewhere.

--
[1] https://lists.ubuntu.com/archives/ubuntu-devel/2010-September/031504.html
[2] https://lists.ubuntu.com/archives/ubuntu-devel/2010-September/031509.html
[3] https://wiki.ubuntu.com/ServerTeam/NattyIdeaPool

Eric Hammond

unread,
Sep 28, 2010, 9:53:37 PM9/28/10
to ec2ubuntu
Scott:

I would love to see packages in Ubuntu for the EC2 command line tools
that are not part of ec2-api-tools and ec2-ami-tools. For example:

- Cloud Watch
- Auto Scaling
- Elastic Load Balancing
- AWS Identity Management

Each of these has a separate set of programs to download and install,
sometimes in slightly different ways. It would be a credit to Ubuntu
if this were as easy as apt-get install.

My personal preference would be to have these available in Ubuntu
10.04 Lucid, even if it were just in somebody's PPA.

--
Eric Hammond
http://alestic.com

On Sep 28, 1:55 pm, Scott Moser <smo...@ubuntu.com> wrote:
> Hello,
>    Sorry for the cross-post/duplicate thread, but I'm interested in
> getting input from as large of a community as possible, and I don't think
> there is much overlap between the ec2ubuntu, ubuntu-cloud, and
> ubuntu-devel lists.
>
>    Allison Randal sent requests for ideas / brainstorming [1,2].
>    I'd like to extend that thread here.  I am willing to pick up any
> pieces and bring them back to the main thread.  There are also ideas being
> dumped at [3].  The key point is that we want your input.
>
>    If you've used Ubuntu Enterprise Cloud, or our UEC/EC2 Images, or
> cloud-init, we want to hear your thoughts on what we can do better.  If
> you're not using UEC or the UEC Images, why not?
>
> What could Ubuntu Enterprise Cloud do that it doesn't do?
> What could it do better?
> What do our UEC/EC2 images do not-so-well?
> What cool things could they do?
> What pain points have you come across when using "Ubuntu in the Cloud"
>
>    We want to make "Ubuntu in the Cloud" as famously simple as Ubuntu is
> known to be elsewhere.
>
> --
> [1]https://lists.ubuntu.com/archives/ubuntu-devel/2010-September/031504....
> [2]https://lists.ubuntu.com/archives/ubuntu-devel/2010-September/031509....
> [3]https://wiki.ubuntu.com/ServerTeam/NattyIdeaPool

Alexey

unread,
Sep 29, 2010, 6:36:26 AM9/29/10
to ec2ubuntu
Hi All,

I have in mind the following points:
- extend the default contents of "/etc/sources.list" to be able to
install all range of applications available for usual desktop
configurations;
- generalize and publish scripts for the custom AMIs building
(through the PyPi, for example) - make them "one click" functionality;
- support cluster units.

At any case, I am really enjoining working with UEC and that Amazon
Linux is based on UEC - is a very good sign, great job!!!

Best regards,
Alexey

Moritz Grimm

unread,
Sep 29, 2010, 4:37:10 AM9/29/10
to ec2u...@googlegroups.com
Hello Scott,


at the start, the official Ubuntu 10.04 AMIs are what we use to build
stuff on in EC2. Thanks for providing all of this!

However, since you're asking about pain points ... we'll never be able
to use the official AMIs as-is and have to repackage our own to get a
usable base. Almost all of the (automated) repackaging steps are to
remove pain points.

I'll only write about cloud-init, as the others are specific to Ubuntu
or even Debian (no root login, dash broken beyond repair,
patched-to-death netcat, no UID/GID range for system accounts with a
fixed UID/GID.)

It does nothing of value for us, except interfere. It isn't properly
documented (not even cloud.cfg), however, removing it altogether opens a
whole different can of worms. When it was still called ec2-init, at
least the code base was less complex and easier to disable/patch ...

When we repackage AMIs, we configure them to have the ephemeral disk on
/dev/sdb always (which are encrypted after provisioning.) We need
consistency with all configuration files no matter the size of the
instance (why Amazon made those different I don't know.) Our fstab is
therefore static, and there mustn't be some random magic rewriting it,
or my apt sources list, or phone home to check for updates it must not
install anyways (because they need to go through our QA first.)

I currently need this, but it is really just based on educated guesswork
after reading cloud-init source:
# printf 'cloud_type: auto\nuser: root\ndisable_root:
0\napt_preserve_sources_list: True\nmounts: None\nupdates-check:
False\n' > /etc/cloud/cloud.cfg
# echo "# Automatic fstab mangling disabled." >
/etc/init/cloud-config-mounts.conf
# rm /etc/cron.d/cloudinit-updates

It is not clear or documented, how to "reset" cloud-init when
repackaging an AMI that is public and must be sanitized. What appears to
be working is a ``find /var/lib/cloud -type f -delete'', which seems
harsh and causes a (benign) Python error on first boot of the new AMI.

Long story short, when we use something as a base, it must be simple
enough to be understood and do only easy-to-understand things. All magic
must be documented and have its documented way of being disabled.

When an instance is started, it really is just a stand-alone CPU-power
dispenser. Registering it in a cloud, where it can start providing a
service, is a step that depends on the rest of the cloud infrastructure
and the service provided. Maybe cloud-init helps some people with this
in some way, with all its special features. What is really required,
however, is just two very simple features that can all be implemented
with a trivial shell-script:
1. Ensure working SSH access for active provisioning (authorized key
from the metadata service.)
2. Fetch and run/provide user-data for autonomous provisioning
(user-data from the metadata service.)
(3. Maybe set the hostname -- once per instance.)

What I hope for with this is maybe a nudge towards simplicity and better
documentation, away from magic on top of magic. Or better, please keep
the magic separate and provide a supported and tested off-switch.

That's it, thanks for listening. :)


Moritz

> --
> You received this message because you are subscribed to the "ec2ubuntu"
> Google Group:
> http://groups.google.com/group/ec2ubuntu
> To unsubscribe, send email to ec2ubuntu-...@googlegroups.com
>

--
Moritz Grimm | mgr...@astaro.com | Software Engineer
Astaro GmbH & Co. KG | www.astaro.de |
Phone +49-721-25516-219 | Fax -200
An der RaumFabrik 33a | 76227 Karlsruhe | Germany

Ajay Ohri

unread,
Sep 29, 2010, 7:33:38 AM9/29/10
to ec2u...@googlegroups.com
Hi,

Could we have all rcran packages installed by default in the images (tarting from base-core)

Lot of people need R for stats data mining and R (or GNU S) is really helpful if we start it.

Another idea that really could help a lot of people connect to the EC2 image is simplifying the Remote Desktop or NX way to connect and see the Desktop.

A third would be to ask on startup how long instance is going to run to avoid instance running-forget cases.

Regards

Daniel Sikar

unread,
Sep 29, 2010, 1:41:29 PM9/29/10
to ec2ubuntu
Hi Scott
In the threads you quoted, I saw Hadoop and JBoss mentioned.
I'll carry on in that vein and suggest Memcached and Cassandra -
though there are several other examples of memory grids and nosql
apps.
There is an amount of plumbing that goes with setting up data
crunching clusters and data grids.
It would be great if every added Ubuntu EC2 instance was "cluster
aware". Obviously this would have to be package-specific as plumbing
varies from one to the other.
Anyway, that would be a famous simplication.
Best regards
Daniel

On Sep 29, 12:33 pm, Ajay Ohri <ohri2...@gmail.com> wrote:
> Hi,
>
> Could we have all rcran packages installed by default in the images (tarting
> from base-core)
>
> Lot of people need R for stats data mining and R (or GNU S) is really
> helpful if we start it.
>
> Another idea that really could help a lot of people connect to the EC2 image
> is simplifying the Remote Desktop or NX way to connect and see the Desktop.
>
> A third would be to ask on startup how long instance is going to run to
> avoid instance running-forget cases.
>
> Regards
>
> Ajay
>
> Websites-http://decisionstats.comhttp://dudeofdata.com
>
> Linkedin-www.linkedin.com/in/ajayohri
>

Simon de boer

unread,
Sep 29, 2010, 2:21:11 PM9/29/10
to Scott Moser, ec2u...@googlegroups.com, ubuntu...@lists.ubuntu.com
Hi,

I would support Moritz Grimm's view of cloud-init, mostly.

I believe my situation is similar to their's where post-ami-release from Ubuntu there are a bunch of things I need to do to the defaults as given in order to create my own base-ami.  

cloud-init should either be very simple (and well documented)...or...should be even more magical (and fantastically documented).  If it stays simple...then the following suggestions probably aren't valuable.

If it gets more magical....

Suggestion 1:  Having a way to automate the creation of a new base instance.  This isn't incredibly terribly time-saving since this only happens every once in awhile (although, potentially you need to do it for 4 instance types in each zone -- 20ish times currently).

Part of this should be saving  a list of versions to upgrade packages (kernels, releases, etc) to -- and using it.  (ie. something similar to the Bundler concept from Rails)  Further magic would be a tool to take a snapshot of this informati

Second: To start up "in the cloud" means that after the CPU/OS comes online the system has to somehow begin to offer a service.  Unless that service is (almost) ridiculously simple it goes beyond one script...

A particularly huge pain point is how to get AWS (or any other) credentials _securely_ onto the new instance as it starts up.  These should not / cannot be embedded in the base image.  Perhaps the new instance tags is a way through this.

The next one is monitoring and warnings.  Lets say a new web instance is told to start up -- there are many points this could fail:
* AWS
* OS startup
* cloud-init
* user-script
* application (ie. apache configuration)
* load-balancer
If another system from which you issued the "Start" command was doing some monitoring how long should it wait to see the final service come up?  (and a approach to monitor such)

And, more directly, how does cloud-init monitor and scream for help itself.  The current approach of having to connect and look through the user.log and (if you're lucky) see an error there is tolerable in development...but...

In a large deployment with instances up and downing themselves automatically, the last thing you want to have happen is for some bunch of instances all sitting around doing nothing (but costing you money) because of an error in the user-data script.

And on the similar topic...there should be a cloud-shutdown as well. (Think of a slave database instance going offline -- it will probably need to inform application instances elsewhere that this is happening)

Simon



--
Ubuntu-cloud mailing list
Ubuntu...@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-cloud



--
Become the head coach with InGamer Sports!
http://www.InGamer.com/

Simon de Boer
519-400-4774

Mark Russell

unread,
Sep 30, 2010, 4:32:03 PM9/30/10
to ec2u...@googlegroups.com, ubuntu...@lists.ubuntu.com
Hi Scott,

On 09/28/2010 04:55 PM, Scott Moser wrote:
> What cool things could they do?

Being able to automatically assign an Elastic IP on instance start up
would be very cool. Here's one solution I found:
http://www.krzywanski.net/archives/592. But it requires putting your
private key and cert on the image. Seems like you could do something
similar but more securely from your workstation though, maybe an option
to cloud-utils "uec-run-instances"?

Thanks,
Mark

Scott Moser

unread,
Oct 1, 2010, 10:45:54 AM10/1/10
to Liraz Siri, Mark Russell, ubuntu...@lists.ubuntu.com, ec2u...@googlegroups.com
On Fri, 1 Oct 2010, Liraz Siri wrote:

> Mark Russell wrote:
>
> > Being able to automatically assign an Elastic IP on instance start up
> > would be very cool. Here's one solution I found:
> > http://www.krzywanski.net/archives/592. But it requires putting your
> > private key and cert on the image. Seems like you could do something
> > similar but more securely from your workstation though, maybe an option
> > to cloud-utils "uec-run-instances"?
>

> Putting your private key and cert on an image is a bad idea. If one
> machine gets compromised the attacker now has access to your entire EC2
> infrastructure.

Well, thanks to IAM, the above is not nearly as true as it used to be.

I wrote two blog entries when I just started playing with IAM [1,2] on
ubuntu.

You could easily create a set of IAM credentials that is only able to the
AssociateAddress api call [3], and stuff those credentials into the image.
The point is still valid, though, that those credentials could then be
used to make other 'AssociateAddress' calls.

If you had credentials limited to only that call, the possibility for
exploitation is somewhat low. Worst case, a hacker got those credentials
and assigned an address to another of *your* instances (the target of the
instance has to be owned by that account... you can't assign your IP to my
instance-id).

Additional, safeguards:
a.) do not provide acl to 'DescribeAddresses', the exploiter then would
have to guess at what IPs might be.
b.) limit the acl to being used from inside the instance's IP address via
a policy.

All in all, not that bad. The IAM is a *huge* win for doing things like
this, and I definitely expect for people to be experimenting with using
it inside instances.

One thing that you cannot do right now for EC2, is explicitly limit inputs
to the 'AssociateAddress'. Ideally, you could create a ACL that could only
call 'AssociateAddress' with 'PublicIp' == 'your-desired-ip' and
'InstanceId' == 'your-instance-id'. Of course, knowing the instance-id
would prevent you from being able to do this before launching the
instance, but you get the picture.

--
[1] http://ubuntu-smoser.blogspot.com/2010/09/playing-with-aws-access-identity.html
[2] http://ubuntu-smoser.blogspot.com/2010/09/using-policies-in-aws-identity-and.html
[3] http://docs.amazonwebservices.com/AWSEC2/latest/APIReference/

Scott Moser

unread,
Oct 1, 2010, 1:24:32 PM10/1/10
to ec2u...@googlegroups.com
On Wed, 29 Sep 2010, Moritz Grimm wrote:

> Hello Scott,
>
> at the start, the official Ubuntu 10.04 AMIs are what we use to build
> stuff on in EC2. Thanks for providing all of this!

Thanks.
I hope you didn't interpret my long wait to respond as meaning I disliked
the content of your post. I'm honestly interested in all input, we want
to make Ubuntu better. I certainly don't think I'm the only one whose
ideas can do that.

> However, since you're asking about pain points ... we'll never be able
> to use the official AMIs as-is and have to repackage our own to get a
> usable base. Almost all of the (automated) repackaging steps are to
> remove pain points.

I'm interested in seeing a complete list of your pain points, so feel free
to follow on.

> I'll only write about cloud-init, as the others are specific to Ubuntu
> or even Debian

> no root login

You can enable root login into our instances, and cloud-config has an
option for not disabling it [1]. Set 'disable_root: false' to do so. You
should be able to do that either in cloud-config passed through user data
or from /etc/cloud/cloud.cfg.

> dash broken beyond repair,

dash as in /bin/sh -> /bin/dash ?
I honestly haven't been touched or been pinched by dash itself.

> patched-to-death netcat,
> no UID/GID range for system accounts with a fixed UID/GID.

I'm sure you're aware, but the appropriate place to address those is with
ubuntu or debian bugs. I also realize that it is difficult and/or slow at
times to get particular pain points addressed.

> It does nothing of value for us, except interfere. It isn't properly
> documented (not even cloud.cfg), however, removing it altogether opens a
> whole different can of worms. When it was still called ec2-init, at
> least the code base was less complex and easier to disable/patch ...

well, cloud.cfg is basically cloud-config syntax [1]. The goal is that
all things you can do in cloud-config can be done wihtout user data by
setting them in cloud.cfg.

I will not pretend that the documentation for cloud-init is even
remotely sufficient. I'll mark that as a pain point in and of itself, and
hopefully we can dedicate some time to enhancing documentation.

> When we repackage AMIs, we configure them to have the ephemeral disk on
> /dev/sdb always (which are encrypted after provisioning.) We need
> consistency with all configuration files no matter the size of the
> instance (why Amazon made those different I don't know.) Our fstab is
> therefore static, and there mustn't be some random magic rewriting it,

This can be accomplished via cloud-config with:
| mounts:
| - [ ephemeral0 ]
| - [ swap ]

The above will stop cloud-config from writing anything to /etc/fstab.
Alternatively, you can let it write the entry for you:
| mounts:
| - [ ephemeral0, /mountpoint ]

> or my apt sources list

cloud-init can be told to not touch your sources.list with:
| apt_preserve_sources_list: true

That said, what I would instead recommend is using
/etc/apt/sources.list.d, and letting it chose the specific region mirror.

> , or phone home to check for updates it must not
> install anyways (because they need to go through our QA first.)

I'm not sure what you mean by this. It does install a cronjob that
"phones home" once per day to see if there is a newer AMI than the one
you've used, and then will inform you of that. This is something that
makes much less sense now that we can manage our own kernels in the
instance. I need to at very least make that configurable off, and likely
just get rid of it now. 'apt-get update && apt-get upgrade' will get you
what you want in 10.10 and later, and nothing in the default images will
do that without you telling it to.

> I currently need this, but it is really just based on educated guesswork
> after reading cloud-init source:
> # printf 'cloud_type: auto\nuser: root\ndisable_root:
> 0\napt_preserve_sources_list: True\nmounts: None\nupdates-check:
> False\n' > /etc/cloud/cloud.cfg
> # echo "# Automatic fstab mangling disabled." >
> /etc/init/cloud-config-mounts.conf
> # rm /etc/cron.d/cloudinit-updates

You did pretty well above. I typed all the above before seeing this.
See, theres *great* doc, found what you needed ;-).

I'd have to look at code to tell you if 'mounts: None' would work and I'm
pretty sure that 'updates-check: False' will not work, but in 10.10 you
can specify the list of "cloud_config_modules" that you want to run, and
you could just not include 'updates-check' in it.

> It is not clear or documented, how to "reset" cloud-init when
> repackaging an AMI that is public and must be sanitized. What appears to

Yeah, "cleaning" a booted image is somewhat difficult. I think that is
true across the board. I would like to make it easy for someone to do,
but there has not been any effort to do so at this point. Its not
completely straightforward though. For example, should this process
remove the keys that were written to ~/.ssh/authorized_keys ?

I will bring this as a discussion point though, and I agree, that we want
to have a clear process for taking an image, booting it, and then saving
it as a image.

My suggestion all along is to simply avoid booting the image, instead,
download our partition image [2], mount it loopback and do what you want.
Then its not had its "first boot". I know thats less user friendly, but
its much more easily programable.

> be working is a ``find /var/lib/cloud -type f -delete'', which seems
> harsh and causes a (benign) Python error on first boot of the new AMI.

I'm not sure what python error you get. I do this all the time when
testing cloud-init.

> Long story short, when we use something as a base, it must be simple
> enough to be understood and do only easy-to-understand things. All magic
> must be documented and have its documented way of being disabled.

Good summary.

> When an instance is started, it really is just a stand-alone CPU-power
> dispenser. Registering it in a cloud, where it can start providing a
> service, is a step that depends on the rest of the cloud infrastructure
> and the service provided. Maybe cloud-init helps some people with this
> in some way, with all its special features. What is really required,
> however, is just two very simple features that can all be implemented
> with a trivial shell-script:
> 1. Ensure working SSH access for active provisioning (authorized key
> from the metadata service.)
> 2. Fetch and run/provide user-data for autonomous provisioning
> (user-data from the metadata service.)
> (3. Maybe set the hostname -- once per instance.)

What cloud-init provides (or tries to) above that is:
a.) boothooks earlier in the boot process, so you can affect more of the
first boot
b.) more friendly mechanism (cloud-config) for doing easy things
c.) an "easy" way for you to append items into user-data . The
multi-part input means that you can have a set user-data that you
launch all instances with, and then still let a user add their own
data to that without having to modify what was there.

Also, I think that you could easily state that all that is *required* is:
1.) ssh access
2.) absolute bare minimum filesystem including posix tar

From there, you could just lay down whatever filesystem you want. Theres
a balance somewhere in the middle.

> What I hope for with this is maybe a nudge towards simplicity and better
> documentation, away from magic on top of magic. Or better, please keep
> the magic separate and provide a supported and tested off-switch.

10.10 is much better in regard to "provide a supported and tested
off-switch"

> That's it, thanks for listening. :)

Thank you.

[1] http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/annotate/head%3A/doc/examples/cloud-config.txt
[2] http://uec-images.ubuntu.com/releases/10.04/release/

Scott Moser

unread,
Oct 1, 2010, 1:51:20 PM10/1/10
to ec2ubuntu
On Wed, 29 Sep 2010, Alexey wrote:

> Hi All,
>
> I have in mind the following points:
> - extend the default contents of "/etc/sources.list" to be able to
> install all range of applications available for usual desktop
> configurations;

I'm not sure that I understand what you mean here. The default contents
of /etc/apt/sources.list in the "Official Ubuntu Images" are not going to
include anything that is not the "Official Ubuntu Archives".

You can easily add apt sources sources via cloud-config with [1]. Syntax
for adding a ppa is simply:
| apt_sources:
| - source: "ppa:smoser/ppa"

There is also more verbose options for other sources.

If you're interested in a Desktop like distribution, you can definitely do
something like 'apt-get install ubuntu-desktop' and generally get there.
The sources that are configured contain all available Ubuntu packages.

We also make "technical preview" like builds of a desktop image available
[2]. That might be a better place to start.

I will add a request for desktop like images to the list of discussion
points.

> - generalize and publish scripts for the custom AMIs building
> (through the PyPi, for example) - make them "one click" functionality;

I'm not sure how PyPi would tie in exactly (that term is new to me other
than i just googled it). But we've had other requests for better
"rebundle" documentation or tools.

> - support cluster units.

Definitely added to the list. I hope that by 11.04 we'll have cluster
compute images.

> At any case, I am really enjoining working with UEC and that Amazon
> Linux is based on UEC - is a very good sign, great job!!!

Amazon Linux is not based on UEC. Publicly I believe they've stated that
they intend to remain compatible (at what level, i'm not sure) with Red
Hat Enterprise Linux 5. i could be wrong, you can definitely search for
more info there.

What they *did* do, which was promising, was include cloud-init. It was
patched to do the same sorts of things on Amazon Linux (rpm based) that it
does on Ubuntu. In the future I hope to get some contributions from them
both in distribution-agnostic work and in new development.

--
[1] http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/annotate/head%3A/doc/examples/cloud-config.txt
[2] http://uec-images.ubuntu.com/desktop/lucid/current/

Scott Moser

unread,
Oct 1, 2010, 2:04:44 PM10/1/10
to ec2u...@googlegroups.com
On Wed, 29 Sep 2010, Ajay Ohri wrote:

> Hi,
>
> Could we have all rcran packages installed by default in the images (tarting
> from base-core)
>
> Lot of people need R for stats data mining and R (or GNU S) is really
> helpful if we start it.

I'm not terribly familiar with 'R'. I see that it is available in the
archive, but it is in Universe. Right now, the core images only contain
things that are in main. That by no means rules it out, though, things
move from Universe to Main with justification.

I just did a quick:
apt-get install rbase-core
and it tells me its going to need an additional 219M of space to install
it. The base images now have a root filesystem of 660M, so this would be
a fairly large increase.

I'll add this as an item, but such a large change would be difficult to
justify.

> Another idea that really could help a lot of people connect to the EC2 image
> is simplifying the Remote Desktop or NX way to connect and see the Desktop.

The desktop images [1] have work done towards this. They're not supported
releases, though. Right now only our Ubuntu Server Images are fully supported.

This is a fairly popular request. Searching this group will show you some
hits on getting NX up and going.

> A third would be to ask on startup how long instance is going to run to
> avoid instance running-forget cases.

We could definitely add an option to cloud-config to queue an at job that
would halt the machine. That said, with ebs backed instances, you'd still
pay for provisioned storage unless you lauched the instance with
InstanceInitiatedShutdownBehavior=terminate
(--instance-initiated-shutdown-behavior = terminate)

Also, anything done from inside the instance could potentially fail (ie,
the 'at' job could be deleted, or /sbin/halt could fail). But it is
definitely a good failsafe.

I'll add that.

Thank you for taking the time to give input.

Scott Moser

unread,
Oct 1, 2010, 2:13:29 PM10/1/10
to ec2ubuntu
On Wed, 29 Sep 2010, Daniel Sikar wrote:

> Hi Scott
> In the threads you quoted, I saw Hadoop and JBoss mentioned.
> I'll carry on in that vein and suggest Memcached and Cassandra -
> though there are several other examples of memory grids and nosql
> apps.
> There is an amount of plumbing that goes with setting up data
> crunching clusters and data grids.
> It would be great if every added Ubuntu EC2 instance was "cluster
> aware". Obviously this would have to be package-specific as plumbing
> varies from one to the other.

Well, there are a few Ubuntu efforts tied to addressing similar issues.
Mathiaz did the great work of getting puppet enabled in cloud-config .
He's written several great articles on how to utilize this to get up and
going quickly [1].

Also, the 'Ensemble' project is targeted at doing for services what apt
did for packages [2]. I know that the project is interested in help to
drive it forward.

Do you have other ideas on concrete things we could do to make instances
"cluster aware" ? Playing well with other systems is definitely a goal of
our base images.

--
[1] http://ubuntumathiaz.wordpress.com/
[2] https://launchpad.net/ensemble

Scott Moser

unread,
Oct 1, 2010, 2:43:21 PM10/1/10
to Simon de boer, ec2u...@googlegroups.com, ubuntu...@lists.ubuntu.com
On Wed, 29 Sep 2010, Simon de boer wrote:

> If it gets more magical....

Well, of course, magical is more fun than simple. Definitely we want to
make easy and implement once the things that people do over and over
again.

> Suggestion 1: Having a way to automate the creation of a new base instance.
> This isn't incredibly terribly time-saving since this only happens every
> once in awhile (although, potentially you need to do it for 4 instance types
> in each zone -- 20ish times currently).

I'm curious why you would rebundle for each instance type, and btw, there
are 10 instance types in my counting. There are 4 regions at the moment.

> Part of this should be saving a list of versions to upgrade packages
> (kernels, releases, etc) to -- and using it. (ie. something similar to the
> Bundler concept from Rails) Further magic would be a tool to take a
> snapshot of this informati

I'm not sure I'm following.
For building images, there is vmbuilder [1]. For re-bundling our base
images (a starting point that I would recommend) I have a bit of work at
ec2-ubuntu-base [2], but it hasn't seen a lot of time devoted to it.
better tools and documentation for this is definitely a common request.

> Second: To start up "in the cloud" means that after the CPU/OS comes online
> the system has to somehow begin to offer a service. Unless that service is
> (almost) ridiculously simple it goes beyond one script...
>
> A particularly huge pain point is how to get AWS (or any other) credentials
> _securely_ onto the new instance as it starts up. These should not / cannot
> be embedded in the base image. Perhaps the new instance tags is a way
> through this.

Well, I think the IAM (AWS Identity and Access Management) [3] is
definitely amazon acknowledging this need. I personally think that to be
*really* usable, the EC2 portion of this api needs some work.

Creating/Managing credentials would be a client side (prior to launching)
effort, which that we've not spent a lot of effort so far
(uec-run-instances does launch instances, but it is very basic at the
moment [4]).

If you're aware of utilities that do this sort of thing, then those would
be good things for us to package and include in Ubuntu so they would be
easily usable.

For a 'rebundle' app that needed to run inside an instance, I think
generating temporary acls to run snapshot or register or s3 bucket
uploads, and deleting them on termination would be great.

> The next one is monitoring and warnings. Lets say a new web instance is
> told to start up -- there are many points this could fail:
> * AWS
> * OS startup
> * cloud-init
> * user-script
> * application (ie. apache configuration)
> * load-balancer
> If another system from which you issued the "Start" command was doing some
> monitoring how long should it wait to see the final service come up? (and a
> approach to monitor such)

This is not made any better by the fact that there is a 4 minute lag
between instance launch and availability of console log. I really hate
that limitation.

We can definitely add 'phone home' like functionality into cloud-init, so
that it makes a http request to another entity indicating "I'm all ready",
but that doesn't help to know when you should give up on an instance and
just terminate it. I could see value in the instance posting public keys
so it could be more securely reached without waiting for console output.

the 10.10 version of cloud-init has support for using python's logging [5]
module, and taking a logging configuration from either
/etc/cloud/cloud.cfg or from user-data. This would allow you to configure
that logging to go to a remote syslog.

> And, more directly, how does cloud-init monitor and scream for help itself.
> The current approach of having to connect and look through the user.log and
> (if you're lucky) see an error there is tolerable in development...but...

in 10.10 that now all goes to /var/log/cloudinit.log , and as mentioned
above can go elsewhere via syslog or other python logging mechanisms.

One part of cloud-init that I'm pretty happy with, and very interested in
making better, is the ability for you to inject things and change its
behavior from user-data. In this sense, you could inject a python module
to extend the python logging method, and also specify a python logging
configuration that utilized that. Then, after '/usr/bin/cloud-init' ended,
subsequent pieces of cloud-cfg and such would use that new logging.

For changing the initial logging of cloud-init, you have to put that data
in the filesystem so it can read it.

> And on the similar topic...there should be a cloud-shutdown as well. (Think
> of a slave database instance going offline -- it will probably need to
> inform application instances elsewhere that this is happening)

Hmm... Is there some portion of normal instance shutdown that you think
would be insufficient for this ? Ie, on init, you can definitely insert
upstart jobs that would be called on shutdown.

Do you think there would be enough common ground to make a
"cloud-shutdown" useful ? The bare bones approach I could take would be
to add a call to run-parts of a given directory on shutdown. Then,
dropping scripts in there would get them called on shutdown. (there
actually already is something like this -- sysvinit and /etc/rc6.d/).

--
[1] https://launchpad.net/vmbuilder
[2] https://code.launchpad.net/~smoser/+junk/ec2-ubuntu-base
[3] http://aws.amazon.com/iam/
[4] http://bazaar.launchpad.net/~ubuntu-on-ec2/ubuntu-on-ec2/cloud-utils/annotate/head%3A/uec-run-instances
[5] http://docs.python.org/library/logging.html

Moritz Grimm

unread,
Oct 2, 2010, 9:15:13 AM10/2/10
to ec2u...@googlegroups.com
Hello Scott,


thanks for your reply.

> I'm interested in seeing a complete list of your pain points, so feel free
> to follow on.

Sure. In that case it might make sense to explain some background on how
we actually ran into them (or even perceive them as such.)

We started out with a historical requirement of having to be RPM-based,
which means we didn't start development on Ubuntu. Eventually, we
realized that our choice wasn't the best. The lesson learned was that we
need to be reasonably OS- and architecture-independent, and our current
UNIX-flavored base OS will be Ubuntu -- at least when running on AWS.

>> no root login
>
> You can enable root login into our instances, and cloud-config has an
> option for not disabling it [1]. Set 'disable_root: false' to do so. You
> should be able to do that either in cloud-config passed through user data
> or from /etc/cloud/cloud.cfg.

Our means of provisioning instances is "active", i.e. an automated
process at a central place runs commands via SSH. (We need that for
various reasons.) I learned to accept that some Linux distributions,
especially those with Desktop background, do that "non-root login only"
thing. We can handle that without using the user data feature of the
cloud environment ... that's how we try to do it whenever possible, to
remain flexible.

>> dash broken beyond repair,
>
> dash as in /bin/sh -> /bin/dash ?
> I honestly haven't been touched or been pinched by dash itself.

I never found the time to figure out the real problem and file a useful
bug report. All I can say that the issue is completely random and not
easily reproduced. The following code snippet randomly fails and causes
shell script content (!) to be printed to stdout or -err:

#!/bin/sh
[...]
(cd ${src} && tar -cfz - *) | openssl enc -aes256 -salt -pass
file:${keyfile} | (cd ${dst} && split -b2047m -a3 - ${pfx})

(This runs in a loop.)

Something is wrong with dash's subshell IO handling ... easy to work
around with using a single command line, though:

# echo "dash dash/sh boolean false" | /usr/bin/debconf-set-selections &&
dpkg-reconfigure -fnoninteractive dash

>> patched-to-death netcat,
>> no UID/GID range for system accounts with a fixed UID/GID.
>
> I'm sure you're aware, but the appropriate place to address those is with
> ubuntu or debian bugs. I also realize that it is difficult and/or slow at
> times to get particular pain points addressed.

For the former, I did. It was reclassified as "wishlist"
(https://bugs.launchpad.net/ubuntu/+source/netcat-openbsd/+bug/544935)
... I stopped caring shortly after, especially since the reason for the
breakage is completely baloney.

The latter is a Debian'ism that has always been like that, not sure it's
worth asking for a change.

Other changes affect the common software selection. For example, I've
put a complete set of debugging tools on our AMIs, gdb, valgrind,
strace, debugging symbols of most system libraries, etc.

> well, cloud.cfg is basically cloud-config syntax [1]. The goal is that
> all things you can do in cloud-config can be done wihtout user data by
> setting them in cloud.cfg.
>
> I will not pretend that the documentation for cloud-init is even
> remotely sufficient. I'll mark that as a pain point in and of itself, and
> hopefully we can dedicate some time to enhancing documentation.

Excellent, this was helpful. Having this information (both the intent
behind the cloud* tools and config files and the [1]-example) referenced
and/or directly available in obvious places on the instances themselves
would already be a very good leap towards better documentation.

> That said, what I would instead recommend is using
> /etc/apt/sources.list.d, and letting it chose the specific region mirror.

Yes ... but it was a surprise when we moved from Karmic to Lucid LTS,
where as a new "feature" cloud-init disabled multiverse again in our
AMIs. Since we have AMIs for all regions, and we even keep them updated
regularly, this would never be something that should be ever changed
dynamically.

The official Ubuntu AMIs could/should already come with fixed and
correct-for-the-region sources lists.

>> , or phone home to check for updates it must not
>> install anyways (because they need to go through our QA first.)
>
> I'm not sure what you mean by this. It does install a cronjob that
> "phones home" once per day to see if there is a newer AMI than the one
> you've used, and then will inform you of that. This is something that

... which is complete nonsense if it's no longer running off the
original Ubuntu AMI. And since "nobody" ever logs in interactively to
production cloud instances (you know what I mean ... AWS is expensive if
you don't use it as the cloud infrastructure as it's meant to be) to see
the notification, I misinterpreted the good intentions behind this as a
cheap way to get web server log entries from the user base.

I see that it may help a select few, but I'd rather see things like this
off by default.

> instance. I need to at very least make that configurable off, and likely
> just get rid of it now. 'apt-get update && apt-get upgrade' will get you
> what you want in 10.10 and later, and nothing in the default images will
> do that without you telling it to.

This sounds very good. Tough luck for me, since we'll probably stay with
LTS for now ... ;)

>> I currently need this, but it is really just based on educated guesswork
>> after reading cloud-init source:
>> # printf 'cloud_type: auto\nuser: root\ndisable_root:
>> 0\napt_preserve_sources_list: True\nmounts: None\nupdates-check:
>> False\n' > /etc/cloud/cloud.cfg
>> # echo "# Automatic fstab mangling disabled." >
>> /etc/init/cloud-config-mounts.conf
>> # rm /etc/cron.d/cloudinit-updates
>
> You did pretty well above. I typed all the above before seeing this.
> See, theres *great* doc, found what you needed ;-).

Took me several iterations of repackaging and testing, though ... ;)

> I'd have to look at code to tell you if 'mounts: None' would work and I'm

It doesn't ... that explains the Python error I get when booting my AMIs
for the first time. :-P I will certainly revisit this to get our AMIs
error-free. Thanks for the help and insight!

>> It is not clear or documented, how to "reset" cloud-init when
>> repackaging an AMI that is public and must be sanitized. What appears to
>
> Yeah, "cleaning" a booted image is somewhat difficult. I think that is
> true across the board. I would like to make it easy for someone to do,
> but there has not been any effort to do so at this point. Its not
> completely straightforward though. For example, should this process
> remove the keys that were written to ~/.ssh/authorized_keys ?

It should, because it's the only universally safe solution, but it will
bite a few people that have a justified need to not do it. How about:

1. Documenting where individual changes happen when using an AMI, that
should be cleaned before repackaging, then
2. Implementing those steps in a program that
- comes with a manual
- provides an option to, for example, keep the current authorized keys

It's really just a matter of doing stuff in the right order, i.e. think
about what the actual requirements are first, and write them down.
Implementing things, where the technical difficulty level is so trivial
and boring as it is here, is quite secondary.

> My suggestion all along is to simply avoid booting the image, instead,
> download our partition image [2], mount it loopback and do what you want.
> Then its not had its "first boot". I know thats less user friendly, but
> its much more easily programable.

No idea if what we do is so special, but in our case it wouldn't. I made
it so that every colleague with access can do this on their workstation
without having to do any manual steps or "modify" their workstation
somehow. Getting there was the hard part. ;)

>> When an instance is started, it really is just a stand-alone CPU-power
>> dispenser. Registering it in a cloud, where it can start providing a
>> service, is a step that depends on the rest of the cloud infrastructure
>> and the service provided. Maybe cloud-init helps some people with this
>> in some way, with all its special features. What is really required,
>> however, is just two very simple features that can all be implemented
>> with a trivial shell-script:
>> 1. Ensure working SSH access for active provisioning (authorized key
>> from the metadata service.)
>> 2. Fetch and run/provide user-data for autonomous provisioning
>> (user-data from the metadata service.)
>> (3. Maybe set the hostname -- once per instance.)
>

[...]


> Also, I think that you could easily state that all that is *required* is:
> 1.) ssh access
> 2.) absolute bare minimum filesystem including posix tar
>
> From there, you could just lay down whatever filesystem you want. Theres
> a balance somewhere in the middle.

Of course. To me, this balance is a bit earlier than where cloud-*
currently is. The AMIs I create are right there before they become
specific to their role in the cloud service that they're the base for.
My way of provisioning would be okay with your bare requirements, and
being able to go further is simply a time-saver.

A different service we're working on, however, uses this "autonomous"
provisioning and requires the user data feature of the meta data
service. It's a perfectly fine way of setting up instances, and a
requirement for every mature cloud infrastructure.

In short, ssh pubkey and user data, provided by the infrastructure's
meta data service, are things that need to be supported by a cloud OS --
they're the lowest common denominator. Cloud-init's attempts to
anticipate additional use cases after this are what make it complex and
"surprising".

Consider this: Where, except Ubuntu and *maybe* Debian could cloud-init
be useful? It comes with features specific to apt, it interfaces
directly with the boot process, and has (I'd think) dependencies, so ...
not in many places. I think it would be cool to have a universally
useful and highly portable cloud-init, and OS-specific cloud-init-<os>
subpackages.

But even that is not yet where cloud-init apparently wants to go -- you
even mention (at least thoughts about) anticipating ways how fully
provisioned instances register themselves with their cloud service as
"available" (that's how I understand your email to Simon de Boer). This
is so application-specific that I can't help but think "bad idea". It's
an entirely different topic, which should really be kept separate both
in code, package and configuration.


Best regards,

Moritz

--
Moritz Grimm | mgr...@astaro.com | Software Engineer

Astaro AG | www.astaro.com | Phone +49-721-25516-219 | Fax -200 |

Ajay Ohri

unread,
Oct 2, 2010, 11:15:15 AM10/2/10
to ec2u...@googlegroups.com
I just gave up on Ubuntu cloud because of th stupid NX client and created a 30g Windows Image for 64 bit R (statitistical packages). Ubuntu is great, but the RDP way of connecting is smoooth.

Still sticking on Ubuntu on my laptop (VMPlayer is better than dual boot as I can alt tab between OS though)

I would recomend anyone to first benchmark the user experience of Windows RDP Cloud Instance----and then start  making changes to the user experience from a design interface perspective not just a tech engg one --- 

sounds dumb- but making Ubuntu Cloud as painless as possible will make it accept even more just like the Ubuntu netbook edition did for Linux (and never mind the 1% of code versus Red Hat's even more painful version for semi geeks like me)

Best

Ajay

Blog

--

Michael Wood

unread,
Oct 2, 2010, 3:28:25 PM10/2/10
to ec2u...@googlegroups.com
On 2 October 2010 17:15, Ajay Ohri <ohri...@gmail.com> wrote:
> I just gave up on Ubuntu cloud because of th stupid NX client and created a
> 30g Windows Image for 64 bit R (statitistical packages). Ubuntu is great,
> but the RDP way of connecting is smoooth.

Excuse my ignorance of R, but why do you need X? It seems things
would go much more smoothly for you if you could use R without a GUI.

> I would recomend anyone to first benchmark the user experience of Windows
> RDP Cloud Instance----and then start  making changes to the user experience
> from a design interface perspective not just a tech engg one ---

I find SSH access to be far faster and therefore superior to VNC or NX
or RDP or Apple Screensharing for what I need to do. Of course there
are things for which a GUI is necessary. Is R one of those things?

--
Michael Wood <esio...@gmail.com>

sgheeren

unread,
Oct 2, 2010, 3:45:59 PM10/2/10
to ec2u...@googlegroups.com
+1

The only reason that would drive me to using X is _interactive_ graphing
of results. [1] At that point, I would reconsider moving the application
into the cloud at all. It is probably a good idea to just find a
powerful workstation near you.
To me, EC2/the cloud is about scaling out: the need to distribute jobs
across multiple CPUs/instances. It is not ususally the case that all
instances simultaneous have meaningful _interactive_ graphical
interfaces. Most often, the process can be monitored on a network node
(which might be in your office locally)

[1] (Static imaging is best done offline; it is Yet An Other number
crunch job).

Ajay Ohri

unread,
Oct 2, 2010, 3:51:28 PM10/2/10
to ec2u...@googlegroups.com
you can see about R at http://r-project.org it is also known as GNU S

I need to build multiple graphs on huge datasets and also have interactivity (including 3D Graphs) -


I am not so happy with .net shingbangs in Windows Server 2008, but graphical user interface helps... and in fact that's what distinguished Ubuntu on earth, so why not the cloud

--

Jonathan Weiss

unread,
Oct 4, 2010, 3:35:19 AM10/4/10
to ec2u...@googlegroups.com
>> Lot of people need R for stats data mining and R (or GNU S) is really
>> helpful if we start it.
>
> I'm not terribly familiar with 'R'.  I see that it is available in the
> archive, but it is in Universe.  Right now, the core images only contain
> things that are in main.  That by no means rules it out, though, things
> move from Universe to Main with justification.

Please don't add R. I don't see why the image has to increase for
everybody while installing R from packages it not a problem at all.

Jonathan

--
Jonathan Weiss
http://blog.innerewut.de
http://twitter.com/jweiss

Jonathan Weiss

unread,
Oct 4, 2010, 3:38:48 AM10/4/10
to ec2u...@googlegroups.com
>>> , or phone home to check for updates it must not
>>> install anyways (because they need to go through our QA first.)
>>
>> I'm not sure what you mean by this.  It does install a cronjob that
>> "phones home" once per day to see if there is a newer AMI than the one
>> you've used, and then will inform you of that.  This is something that
>
> ... which is complete nonsense if it's no longer running off the
> original Ubuntu AMI. And since "nobody" ever logs in interactively to
> production cloud instances (you know what I mean ... AWS is expensive if
> you don't use it as the cloud infrastructure as it's meant to be) to see
> the notification, I misinterpreted the good intentions behind this as a
> cheap way to get web server log entries from the user base.
>
> I see that it may help a select few, but I'd rather see things like this
> off by default.

+1

Scott Moser

unread,
Oct 4, 2010, 10:19:28 AM10/4/10
to ec2u...@googlegroups.com
On Sat, 2 Oct 2010, Moritz Grimm wrote:

> Hello Scott,
>
>
> thanks for your reply.
>

> >> patched-to-death netcat,
> >> no UID/GID range for system accounts with a fixed UID/GID.
> >
> > I'm sure you're aware, but the appropriate place to address those is with
> > ubuntu or debian bugs. I also realize that it is difficult and/or slow at
> > times to get particular pain points addressed.
>
> For the former, I did. It was reclassified as "wishlist"
> (https://bugs.launchpad.net/ubuntu/+source/netcat-openbsd/+bug/544935)
> ... I stopped caring shortly after, especially since the reason for the
> breakage is completely baloney.

Well, thanks for pointing at that bug, I happened to see a new bug report
last night
https://bugs.launchpad.net/ubuntu/+source/netcat-openbsd/+bug/653304 that
is a duplicate, but I would not have known that otherwise.

> Excellent, this was helpful. Having this information (both the intent
> behind the cloud* tools and config files and the [1]-example) referenced
> and/or directly available in obvious places on the instances themselves
> would already be a very good leap towards better documentation.

In maverick, /usr/share/doc/cloud-init/examples is populated with the
examples.

> > That said, what I would instead recommend is using
> > /etc/apt/sources.list.d, and letting it chose the specific region mirror.
>
> Yes ... but it was a surprise when we moved from Karmic to Lucid LTS,

I'm fairly sure that all actually "Official Ubuntu" images of Karmic had
multiverse disabled. If not, its a bug. Other *buntu (including -server)
do not have multiverse enabled by default.

> where as a new "feature" cloud-init disabled multiverse again in our
> AMIs. Since we have AMIs for all regions, and we even keep them updated
> regularly, this would never be something that should be ever changed
> dynamically.

The /etc/apt/sources.list in 10.10 starts with:
## Note, this file is written by cloud-init on first boot of an instance
## modifications made here will not survive a re-bundle.
## if you wish to make changes you can:
## a.) add 'apt_preserve_sources_list: true' to /etc/cloud/cloud.cfg
## or do the same in user-data
## b.) add sources in /etc/apt/sources.list.d

It also includes lines for multiverse so that users can easily comment
them out to affect *this* instance.

> The official Ubuntu AMIs could/should already come with fixed and
> correct-for-the-region sources lists.

Well, they could, yes. I find a lot of value in us-east-1 or
ap-southeast-1 images being bit for bit identical even if they behave
in a way that is region-aware on boot.

> >> , or phone home to check for updates it must not
> >> install anyways (because they need to go through our QA first.)
> >
> > I'm not sure what you mean by this. It does install a cronjob that
> > "phones home" once per day to see if there is a newer AMI than the one
> > you've used, and then will inform you of that. This is something that
>
> ... which is complete nonsense if it's no longer running off the
> original Ubuntu AMI. And since "nobody" ever logs in interactively to
> production cloud instances (you know what I mean ... AWS is expensive if
> you don't use it as the cloud infrastructure as it's meant to be) to see
> the notification, I misinterpreted the good intentions behind this as a
> cheap way to get web server log entries from the user base.

Well, there was a more invasive solution suggested around Karmic, and
it was dropped due to the explaination you've given.

I opened bug 653220 last week to get that removed in 11.04.

> It's really just a matter of doing stuff in the right order, i.e. think
> about what the actual requirements are first, and write them down.
> Implementing things, where the technical difficulty level is so trivial
> and boring as it is here, is quite secondary.

I agree. It can be done, its just a matter of doing it. Thanks for
raising the request.

> > My suggestion all along is to simply avoid booting the image, instead,
> > download our partition image [2], mount it loopback and do what you want.
> > Then its not had its "first boot". I know thats less user friendly, but
> > its much more easily programable.
>
> No idea if what we do is so special, but in our case it wouldn't. I made
> it so that every colleague with access can do this on their workstation
> without having to do any manual steps or "modify" their workstation
> somehow. Getting there was the hard part. ;)

Well, yes, mounting loopback and using root can be dangerous and does
require linux and possibly ubuntu as the host. The easy solution is to do
it in a ec2 instance.

> Consider this: Where, except Ubuntu and *maybe* Debian could cloud-init
> be useful? It comes with features specific to apt, it interfaces
> directly with the boot process, and has (I'd think) dependencies, so ...
> not in many places. I think it would be cool to have a universally
> useful and highly portable cloud-init, and OS-specific cloud-init-<os>
> subpackages.

Well, the Amazon AMIs now have cloud-init. Amazon did some work to move
to be less debian/ubuntu specific. I expect to pull that work into trunk.
So, maybe we're moving there.

> But even that is not yet where cloud-init apparently wants to go -- you
> even mention (at least thoughts about) anticipating ways how fully
> provisioned instances register themselves with their cloud service as
> "available" (that's how I understand your email to Simon de Boer). This
> is so application-specific that I can't help but think "bad idea". It's
> an entirely different topic, which should really be kept separate both
> in code, package and configuration.

I wouldn't do anything terribly specific. I'd just add a config option
for a utility to make a http request to a specified url, possibly passing
in potentially useful information such as its instance-id or a single use
key generated by the system that lauched the instance.

I've used something like this myself, having the instance "phone-home",
and posting generated ssh keys to it. The launching service just provides
a URL like:
https://example.com/phone-home/<secret-one-time-pass>

The instance then does a post to that url when its up. If nothing else,
it gets around the waiting for the console to appear.

Again, thanks for your input.
I generally agree with your request for "no magic by default", and will
keep that in mind.

Scott

Moritz Grimm

unread,
Oct 4, 2010, 10:55:41 AM10/4/10
to ec2u...@googlegroups.com
Hello Scott,


> > The official Ubuntu AMIs could/should already come with fixed and
> > correct-for-the-region sources lists.
>
> Well, they could, yes. I find a lot of value in us-east-1 or
> ap-southeast-1 images being bit for bit identical even if they behave
> in a way that is region-aware on boot.

I can relate, and identical images are easier to test, too. It simply
was (at the time) an undocumented change between Karmic and Lucid, and
therefore surprising.

The 10.10 comment you pasted sounds exactly what I would've needed to
not run into that issue. Maybe it's possible to always get those
comments at the same time when the file-changing feature is implemented
in the future? :)

Again, thank you for your time!


Best regards,

Moritz

--
Moritz Grimm | mgr...@astaro.com | Software Engineer

Astaro GmbH & Co. KG | www.astaro.com |

Reply all
Reply to author
Forward
0 new messages