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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev