+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 <sha...@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-requ...@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
__________________________________________________________________________ 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
