Open Stack

+1 from me.

Somewhat related, would also be nice to switch the default for
"user_data_format" in OS::Nova::Server to RAW someday, as now it defaults
to HEAT_CFNTOOLS.

Best regards,

On Fri, Jan 22, 2016 at 11:38 AM Steven Hardy <shardy at redhat.com> 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?
>
> 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
>
-- 
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160122/6df0f980/attachment.html>