[openstack-dev] [Heat] conditional resource exposure - second thoughts

Pavlo Shchelokovskyy pshchelokovskyy at mirantis.com
Tue Jul 14 18:34:37 UTC 2015


Hi Heaters,

currently we already expose to the user only resources for services
deployed in the cloud [1], and soon we will do the same based on whether
actual user roles allow creating specific resources [2]. Here I would like
to get your opinion on some of my thoughts regarding behavior of
resource-type-list, resource-type-show and template-validate with this new
features.

resource-type-list
We already (or soon will) hide unavailable in the cloud / for the user
resources from the listing. But what if we add an API flag e.g. --all to
show all registered in the engine resources? That would give any user a
glimpse of what their Orchestration service can manage in principle, so
they can nag the cloud operator to install additional OpenStack components
or give them required roles :)

resource-type-show
Right now the plan is to disable "showing" unavailable to the user
resources. But may be we should leave this as it is, for the same purpose
as above (or again add a --all flag or such)?

template-validate
Right now Heat is failing validation for templates containing resource
types not registered in the engine (e.g. typo). Should we also make this
call available services- and roles-sensitive? Or should we leave a way for
a user to check validity of any template with any in principle supported
resources?

The bottom line is we are good in making Heat service to be as much
self-documented via its own API as possible - let's keep doing that and
make any Heat deployment to be the Heat primer :)

Eager to hear your opinions.

[1]
http://specs.openstack.org/openstack/heat-specs/specs/liberty/conditional-resource-exposure-services.html

[2]
http://specs.openstack.org/openstack/heat-specs/specs/liberty/conditional-resource-exposure-roles.html

Best regards,
 --
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/20150714/28679fa5/attachment.html>


More information about the OpenStack-dev mailing list