<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Nov 19, 2013 at 4:27 PM, Zane Bitter <span dir="ltr"><<a href="mailto:zbitter@redhat.com" target="_blank">zbitter@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On 19/11/13 19:14, Christopher Armstrong wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im"><br></div></blockquote></blockquote>
<div><br></div><div>[snip]</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
It'd be interesting to see some examples, I think. I'll provide some<br>
examples of my proposals, with the following caveats:<br>
</blockquote>
<br></div>
Excellent idea, thanks :)<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
- I'm assuming a separation of launch configuration from scaling group,<br>
as you proposed -- I don't really have a problem with this.<br>
- I'm also writing these examples with the plural "resources" parameter,<br>
which there has been some bikeshedding around - I believe the structure<br>
can be the same whether we go with singular, plural, or even<br>
whole-template-as-a-string.<br>
<br>
# trivial example: scaling a single server<br>
<br>
POST /launch_configs<br>
<br>
{<br>
"name": "my-launch-config",<br>
"resources": {<br>
"my-server": {<br>
"type": "OS::Nova::Server",<br>
"properties": {<br>
"image": "my-image",<br>
"flavor": "my-flavor", # etc...<br>
}<br>
}<br>
}<br>
}<br>
</blockquote>
<br></div>
This case would be simpler with my proposal, assuming we allow a default:<div class="im"><br>
<br>
POST /launch_configs<br>
<br>
{<br>
"name": "my-launch-config",<br></div>
"parameters": {<div class="im"><br>
"image": "my-image",<br>
"flavor": "my-flavor", # etc...<br>
}<br>
}<br>
<br></div>
If we don't allow a default it might be something more like:<div class="im"><br>
<br>
<br>
POST /launch_configs<br>
<br>
{<br>
"name": "my-launch-config",<br></div>
"parameters": {<div class="im"><br>
"image": "my-image",<br>
"flavor": "my-flavor", # etc...<br>
},<br></div>
"provider_template_uri": "<a href="http://heat.example.com/" target="_blank">http://heat.example.com/</a><<u></u>tenant_id>/resources_types/OS:<u></u>:Nova::Server/template"<div class="im">
<br>
}<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
POST /groups<br>
<br>
{<br>
"name": "group-name",<br>
"launch_config": "my-launch-config",<br>
"min_size": 0,<br>
"max_size": 0,<br>
}<br>
</blockquote>
<br></div>
This would be the same.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
(and then, the user would continue on to create a policy that scales the<br>
group, etc)<br>
<br>
# complex example: scaling a server with an attached volume<br>
<br>
POST /launch_configs<br>
<br>
{<br>
"name": "my-launch-config",<br>
"resources": {<br>
"my-volume": {<br>
"type": "OS::Cinder::Volume",<br>
"properties": {<br>
# volume properties...<br>
}<br>
},<br>
"my-server": {<br>
"type": "OS::Nova::Server",<br>
"properties": {<br>
"image": "my-image",<br>
"flavor": "my-flavor", # etc...<br>
}<br>
},<br>
"my-volume-attachment": {<br>
"type": "OS::Cinder::VolumeAttachment"<u></u>,<br>
"properties": {<br>
"volume_id": {"get_resource": "my-volume"},<br>
"instance_uuid": {"get_resource": "my-server"},<br>
"mountpoint": "/mnt/volume"<br>
}<br>
}<br>
}<br>
}<br>
</blockquote>
<br></div>
This appears slightly more complex on the surface; I'll explain why in a second.<div class="im"><br>
<br>
POST /launch_configs<br>
<br>
{<br>
"name": "my-launch-config",<br></div>
"parameters": {<div class="im"><br>
"image": "my-image",<br>
"flavor": "my-flavor", # etc...<br>
}<br></div>
"provider_template": {<br>
"hot_format_version": "some random date",<br>
"parameters" {<br>
"image_name": {<br>
"type": "string"<br>
},<br>
"flavor": {<br>
"type": "string"<br>
} # &c. ...<div class="im"><br>
},<br>
"resources" {<br>
"my-volume": {<br>
"type": "OS::Cinder::Volume",<br>
"properties": {<br>
# volume properties...<br>
}<br>
},<br>
"my-server": {<br>
"type": "OS::Nova::Server",<br>
"properties": {<br></div>
"image": {"get_param": "image_name"},<br>
"flavor": {"get_param": "flavor"}, # etc...<div class="im"><br>
}<br>
},<br>
"my-volume-attachment": {<br>
"type": "OS::Cinder::VolumeAttachment"<u></u>,<br>
"properties": {<br>
"volume_id": {"get_resource": "my-volume"},<br>
"instance_uuid": {"get_resource": "my-server"},<br>
"mountpoint": "/mnt/volume"<br>
}<br>
}<br></div>
},<br>
"outputs" {<br>
"public_ip_address": {<br>
"Value": {"get_attr": ["my-server", "public_ip_address"]} # &c. ...<br>
}<br>
}<br>
}<br>
<br>
(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.)<br>
<br>
There are a number of advantages to including the whole template, rather than a resource snippet:<br>
- Templates are versioned!<br>
- Templates accept parameters<br>
- Templates can provide outputs - we'll need these when we go to do notifications (e.g. to load balancers).<br>
<br>
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::<u></u>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.</blockquote>
<div><br></div><div><br></div><div>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:</div>
<div><br></div><div> - Templates can provide outputs - we'll need these when we go to do notifications (e.g. to load balancers).<br></div><div><br></div><div>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.</div>
<div><br></div><div>Thanks for the helpful discussion!</div></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div>IRC: radix</div>Christopher Armstrong<div>Rackspace</div></div>
</div></div>