Open Stack

Hi all,

Wanted to start some discussion re $subject, context is:

https://bugs.launchpad.net/heat/+bug/1507568

Here, we're hitting issues because by default OS::Nova::Server uses the
POLL_SERVER_CFN transport.  This made sense back when the
SoftwareDeployment stuff was first implemented, but now we have other
options, and there are some negative consequenses of choosing this default:

1. All heat deployments rely on the heat-api-cfn service by default, when
this should really be a CFN compatibility layer.

2. Related to (1) we then require the keystone ec2tokens extension to be
enabled

3. The cfn API action DescribeStackResource is used to retrieve server
metadata.  Because that API has no action to only show the metadata, we get
*all* data for that resource - and recent changes to show all attributes by
default have made this *much* higher overhead than it once was.

4. As mentioned in the bug above, trying to resolve all the attributes
doesn't work, because we're using stack domain user credentials to poll the
CFN API, which don't have access to the related nova API for the server
resource.  This can probably be fixed, but an alternative is just don't use
this API.

So, my question is, now that we have other (better) alternatives, can we
consider switching the Server transport e.g to POLL_SERVER_HEAT by default,
and relatedly the SoftwareDeployment signal_transport to HEAT_SIGNAL?

http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Nova::Server-prop-software_config_transport

http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Heat::SoftwareDeployment-prop-signal_transport

The advantage of this is it only requires the native heat-api service, when
all other options require some other service/API to exist.

Long term, we should probably consider deprecating the CFN transport for
these (native) resources, but switching the default would be the first step
- what do people think?

Thanks,

Steve