[ubuntu-cloud] Call for ideas for Ubuntu cloud / [UEC|EC2] images / cloud-init
Simon de boer
sdeboer at ingamer.com
Wed Sep 29 19:21:11 BST 2010
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
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:
* OS startup
* application (ie. apache configuration)
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)
On Tue, Sep 28, 2010 at 4:55 PM, Scott Moser <smoser at ubuntu.com> wrote:
> 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 . 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.
>  https://wiki.ubuntu.com/ServerTeam/NattyIdeaPool
> Ubuntu-cloud mailing list
> Ubuntu-cloud at lists.ubuntu.com
> Modify settings or unsubscribe at:
Become the head coach with InGamer Sports!
Simon de Boer
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ubuntu-cloud