Open Stack

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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>