Open Stack

On Tue, Nov 19, 2013 at 4:27 PM, Zane Bitter <zbitter at redhat.com> wrote:

> On 19/11/13 19:14, Christopher Armstrong wrote:
>
>>
>>
[snip]



>> It'd be interesting to see some examples, I think. I'll provide some
>> examples of my proposals, with the following caveats:
>>
>
> Excellent idea, thanks :)
>
>
>  - I'm assuming a separation of launch configuration from scaling group,
>> as you proposed -- I don't really have a problem with this.
>> - I'm also writing these examples with the plural "resources" parameter,
>> which there has been some bikeshedding around - I believe the structure
>> can be the same whether we go with singular, plural, or even
>> whole-template-as-a-string.
>>
>> # trivial example: scaling a single server
>>
>> POST /launch_configs
>>
>> {
>>      "name": "my-launch-config",
>>      "resources": {
>>          "my-server": {
>>              "type": "OS::Nova::Server",
>>              "properties": {
>>                  "image": "my-image",
>>                  "flavor": "my-flavor", # etc...
>>              }
>>          }
>>      }
>> }
>>
>
> This case would be simpler with my proposal, assuming we allow a default:
>
>
>  POST /launch_configs
>
>  {
>       "name": "my-launch-config",
>       "parameters": {
>
>           "image": "my-image",
>           "flavor": "my-flavor", # etc...
>       }
>  }
>
> If we don't allow a default it might be something more like:
>
>
>
>  POST /launch_configs
>
>  {
>       "name": "my-launch-config",
>       "parameters": {
>
>           "image": "my-image",
>           "flavor": "my-flavor", # etc...
>       },
>       "provider_template_uri": "http://heat.example.com/<
> tenant_id>/resources_types/OS::Nova::Server/template"
>
>  }
>
>
>  POST /groups
>>
>> {
>>      "name": "group-name",
>>      "launch_config": "my-launch-config",
>>      "min_size": 0,
>>      "max_size": 0,
>> }
>>
>
> This would be the same.
>
>
>
>> (and then, the user would continue on to create a policy that scales the
>> group, etc)
>>
>> # complex example: scaling a server with an attached volume
>>
>> POST /launch_configs
>>
>> {
>>      "name": "my-launch-config",
>>      "resources": {
>>          "my-volume": {
>>              "type": "OS::Cinder::Volume",
>>              "properties": {
>>                  # volume properties...
>>              }
>>          },
>>          "my-server": {
>>              "type": "OS::Nova::Server",
>>              "properties": {
>>                  "image": "my-image",
>>                  "flavor": "my-flavor", # etc...
>>              }
>>          },
>>          "my-volume-attachment": {
>>              "type": "OS::Cinder::VolumeAttachment",
>>              "properties": {
>>                  "volume_id": {"get_resource": "my-volume"},
>>                  "instance_uuid": {"get_resource": "my-server"},
>>                  "mountpoint": "/mnt/volume"
>>              }
>>          }
>>      }
>> }
>>
>
> This appears slightly more complex on the surface; I'll explain why in a
> second.
>
>
>  POST /launch_configs
>
>  {
>       "name": "my-launch-config",
>       "parameters": {
>
>           "image": "my-image",
>           "flavor": "my-flavor", # etc...
>       }
>       "provider_template": {
>           "hot_format_version": "some random date",
>           "parameters" {
>               "image_name": {
>                   "type": "string"
>               },
>               "flavor": {
>                   "type": "string"
>               } # &c. ...
>
>           },
>           "resources" {
>               "my-volume": {
>                   "type": "OS::Cinder::Volume",
>                   "properties": {
>                       # volume properties...
>                   }
>               },
>               "my-server": {
>                   "type": "OS::Nova::Server",
>                   "properties": {
>                       "image": {"get_param": "image_name"},
>                       "flavor": {"get_param": "flavor"}, # etc...
>
>                  }
>               },
>               "my-volume-attachment": {
>                   "type": "OS::Cinder::VolumeAttachment",
>                   "properties": {
>                       "volume_id": {"get_resource": "my-volume"},
>                       "instance_uuid": {"get_resource": "my-server"},
>                       "mountpoint": "/mnt/volume"
>                   }
>               }
>           },
>           "outputs" {
>                "public_ip_address": {
>                    "Value": {"get_attr": ["my-server",
> "public_ip_address"]} # &c. ...
>           }
>       }
>  }
>
> (BTW the template could just as easily be included in the group rather
> than the launch config. If we put it here we can validate the parameters
> though.)
>
> There are a number of advantages to including the whole template, rather
> than a resource snippet:
>  - Templates are versioned!
>  - Templates accept parameters
>  - Templates can provide outputs - we'll need these when we go to do
> notifications (e.g. to load balancers).
>
> The obvious downside is there's a lot of fiddly stuff to include in the
> template (hooking up the parameters and outputs), but this is almost
> entirely mitigated by the fact that the user can get a template, ready
> built with the server hooked up, from the API by hitting
> /resource_types/OS::Nova::Server/template and just edit in the Volume and
> VolumeAttachment. (For a different example, they could of course begin with
> a different resource type - the launch config accepts any keys for
> parameters.) To the extent that this encourages people to write templates
> where the outputs are actually supplied, it will help reduce the number of
> people complaining their load balancers aren't forwarding any traffic
> because they didn't surface the IP addresses.



My immediate reaction is to counter-propose just specifying an entire
template instead of parameters and template separately, but I think the
crux will be this point you mentioned:

 - Templates can provide outputs - we'll need these when we go to do
notifications (e.g. to load balancers).

Can you explain this in a bit more depth? It seems like whatever it is may
be the real deciding factor that means that your proposal can do something
that a "resources" or a "template" parameter can't do.  I thought we had a
workable solution with the "LoadBalancerMember" idea, which you would use
in a way somewhat similar to CinderVolumeAttachment in the above example,
to hook servers up to load balancers.

Thanks for the helpful discussion!


-- 
IRC: radix
Christopher Armstrong
Rackspace
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131120/cb312a47/attachment.html>