Open Stack

On Fri, Apr 26, 2013 at 12:24:57PM +0100, Alex Heneveld wrote:
> 
> D+ here too.  seems unanimous.  (a bad mark at school but here a
> good thing!)
> 
> this captures the single biggest thing i think most of us care
> about:  composition / more flexible re-use.
> and does it in a manageable incremental way.
> 
> in the interest of separating issues, these are two other areas
> which are mostly independent but i think
> also very important:
> 
> * intuitive DSL -- something easier to write and easier to read. two
> offenders which it seems not hard to
> fix are long type names eg "OS::Nova::Server" (for which could
> introduce supertypes/aliases eg "server"?),
> and embedded scripts/mappings (which a bundle could alleviate eg ZIP
> as per Thomas's suggestion)
> 
> * modelling relationships -- if we can support typed relationships
> between components (resources)
> then we have a leg-up both for auto-wiring and for acting on wait
> conditions at a finer granularity.  this
> makes the descriptions smaller and more portable, makes deployment
> faster, and allows more use cases.
> (i've experimented with modelling this as requirements and
> fulfillments, which seems parsimonious and
> natural, but that's part of what we need to figure out!)
>     as an example, here are two use cases i believe we would
> struggle with (people would have to roll
> their own co-ordination; but please correct me if i'm wrong):
> ** some of the hadoop distros need to know the ip's of a quorum of
> servers in order to seed the
> config for those servers; and

I might be misunderstanding the problem, but I think you could do this in a
similar way to the method used to reload the loadbalancer config for an
AutoScalingGroup;

InstanceGroup (and derived AutoScalingGroup) provide a heat extension to
FnGetAtt, which provides a list of all the server PublicIp's in the group,
which you could refer to in the LaunchConfiguration instance Metadata, then
use cfn-hup to update the config of all instances in the group.

There are probably other solutions, e.g using AWS::EC2::NetworkInterface
(or OS::Quantum::Port) resources, but the above is the one which
immediately springs to mind.

Steve