Open Stack

On 18/07/13 08:14, Thomas Spatzier wrote:
> Steve Baker <sbaker at 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.