Open Stack

Steve Baker <sbaker at redhat.com> wrote on 18.07.2013 00:00:40:
> From: Steve Baker <sbaker at redhat.com>
> To: openstack-dev at lists.openstack.org,
> Date: 18.07.2013 00:08
> Subject: Re: [openstack-dev] [Heat] Long-term, how do we make heat
> image/flavor name agnostic?
>
> 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?

> >
> > 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).

>
> 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
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>