On 18/07/13 08:14, Thomas Spatzier wrote:
Steve Baker <sba...@redhat.com> wrote on 18.07.2013 00:00:40:
On 07/18/2013 08:53 AM, Gabriel Hurley wrote:
I spent a bunch of time working with and understanding Heat in H2,
and I find myself with one overarching question which I wonder if
anyone's thought about or even answered already...
At present, the CloudFormation template format is the first-class
means of doing things in Heat. CloudFormation was created for
Amazon, and Amazon has this massive convenience of having a (more or
less) static list of images and flavors that they control. Therefore
in CloudFormation everything is specified by a unique, specific name.
OpenStack doesn't have this luxury. We have as many image and
flavor names as we have deployments. Now, there are simple answers...
1. Name everything the way Amazon does, or
2. Alter your templates.
But personally, I don't like either of these options. I think in
the long term we win at platform/ecosystem by making it possible to
take a template off the internet and having it work on *any* OpenStack
cloud.
+1 on making the selection based on requirements like platform, arch etc.
for images and minimum cpu, memory, ephemeral storage requirement for
flavors.
I think that would allow a template writer to express exactly what he needs
for his template to work reasonably without binding to any specific naming.
I think we can do something in this direction when we work on the
requirements feature in HOT.
In addition, wouldn't it make sense to enable lookup of flavors as a
starter (image could come later, because metadata could become more
complex) in the native instance resource Steven Dake is working on?
I'm not against this, but I think it needs to be done in a way that is
(a) repeatable [this should be no trouble], and (b) predictable to the
user in advance. Most users will be charged (in some sense) for their
usage, so it had better be clear what they are signing up for before
they launch the template.
To get there, we need a system that chooses images based on
metadata (platform, architecture, distro) and flavors based on
actual minimum requirements.
Has anyone on the Heat team thought about this? Are there efforts
in the works to alleviate this? Am I missing something obvious?
Yes, each openstack cloud could have completely different flavors and
images available. My current approach is to not have a Mappings section
at all and just specify the flavor and image on launch, ie:
Parameters:
KeyName:
Type: String
InstanceType:
Type: String
ImageId:
Type: String
...
Resources:
SmokeServer:
Type: AWS::EC2::Instance
Properties:
ImageId: {Ref: ImageId}
InstanceType: {Ref: InstanceType}
KeyName: {Ref: KeyName}
...
While this would solve the problem of binding to specific names, it could
lead to binding to something that is not in line with what the template
writer wanted to have so the template works fine. E.g. how can the deployer
know what size the instances should have so the stack performs well without
having minimum requirements expressed (see my earlier comment above).
The environment feature (see Steve's example below) can help solve this
problem, by providing default parameter values. Typically I imagine
there would be a different environment file for each cloud provider -
the idea is to abstract any cloud differences out of the template and
into the environment - which ideally would be usable across e.g. all of
an organisation's templates.
InstanceType and ImageId could even be specified in the environment file
that is specified on launch, so they don't need to be specified in the
launch command, ie env.yaml:
parameters:
KeyName: heat_key
InstanceType: m1.micro
ImageId: ubuntu-vm-heat-cfntools-tempest
heat stack-create mystack -e env.yaml --template-file=mytemplate.yaml
cheers,
Zane.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
