On 22/01/16 04:36, Steven Hardy wrote:
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
+1 for these reasons alone.
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.
The metadata API also uses the describe_stack_resource RPC call. Which
was not really a big deal at the time, but the addition of polling the
resource for every one of its attributes and the failure to make that
optional in at least the RPC API (let alone the ReST API) is making this
incredibly expensive compared to what it needs to be.
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.
Sadly, that alternative suffers from the exact same problem. Either way
we need an actual fix, which I am working on at the moment.
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.
+1
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
__________________________________________________________________________
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
