Open Stack

On 22/01/16 22: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
>
> 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?
>

I'm OK with switching to POLL_SERVER_HEAT in theory, however I have a 
couple of practical considerations:
1. POLL_SERVER_HEAT doesn't work for me at the moment, I haven't 
investigated why:
    WARNING os_collect_config.heat [-] Invalid username or password 
(Disable debug mode to suppress these details.) (HTTP 401)
2. We *must* ensure that existing stacks that were launched with default 
POLL_SERVER_CFN continue to work when the default changes to 
POLL_SERVER_HEAT

What I think would be more useful than changing the default in our 
release is making puppet-heat set the default to POLL_TEMP_URL if a 
swift or ceph is configured, falling back to POLL_SERVER_HEAT otherwise.