<div dir="ltr">+1 from me.<div><br></div><div>Somewhat related, would also be nice to switch the default for "user_data_format" in OS::Nova::Server to RAW someday, as now it defaults to HEAT_CFNTOOLS.<br></div><div><br></div><div>Best regards,</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jan 22, 2016 at 11:38 AM Steven Hardy <<a href="mailto:shardy@redhat.com">shardy@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
Wanted to start some discussion re $subject, context is:<br>
<br>
<a href="https://bugs.launchpad.net/heat/+bug/1507568" rel="noreferrer" target="_blank">https://bugs.launchpad.net/heat/+bug/1507568</a><br>
<br>
Here, we're hitting issues because by default OS::Nova::Server uses the<br>
POLL_SERVER_CFN transport.  This made sense back when the<br>
SoftwareDeployment stuff was first implemented, but now we have other<br>
options, and there are some negative consequenses of choosing this default:<br>
<br>
1. All heat deployments rely on the heat-api-cfn service by default, when<br>
this should really be a CFN compatibility layer.<br>
<br>
2. Related to (1) we then require the keystone ec2tokens extension to be<br>
enabled<br>
<br>
3. The cfn API action DescribeStackResource is used to retrieve server<br>
metadata.  Because that API has no action to only show the metadata, we get<br>
*all* data for that resource - and recent changes to show all attributes by<br>
default have made this *much* higher overhead than it once was.<br>
<br>
4. As mentioned in the bug above, trying to resolve all the attributes<br>
doesn't work, because we're using stack domain user credentials to poll the<br>
CFN API, which don't have access to the related nova API for the server<br>
resource.  This can probably be fixed, but an alternative is just don't use<br>
this API.<br>
<br>
So, my question is, now that we have other (better) alternatives, can we<br>
consider switching the Server transport e.g to POLL_SERVER_HEAT by default,<br>
and relatedly the SoftwareDeployment signal_transport to HEAT_SIGNAL?<br>
<br>
<a href="http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Nova::Server-prop-software_config_transport" rel="noreferrer" target="_blank">http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Nova::Server-prop-software_config_transport</a><br>
<br>
<a href="http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Heat::SoftwareDeployment-prop-signal_transport" rel="noreferrer" target="_blank">http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Heat::SoftwareDeployment-prop-signal_transport</a><br>
<br>
The advantage of this is it only requires the native heat-api service, when<br>
all other options require some other service/API to exist.<br>
<br>
Long term, we should probably consider deprecating the CFN transport for<br>
these (native) resources, but switching the default would be the first step<br>
- what do people think?<br>
<br>
Thanks,<br>
<br>
Steve<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><div dir="ltr">-- <br></div><div dir="ltr"><span>Dr. Pavlo Shchelokovskyy</span><div>Senior Software Engineer</div><div>Mirantis Inc</div><div><a>www.mirantis.com</a></div></div>