Open Stack

Excerpts from Pavlo Shchelokovskyy's message of 2015-07-14 11:34:37 -0700:
> 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 :)
> 

There are more variables that lead to a resource being hidden than
the catalog. The version of Heat, whether the plugin is available,
libraries installed on the server, etc. The canonical place for all
things possible, and the place that users should be encouraged to use,
is the documentation of Heat. These API's should only be for inspection
of what is available on the Heat service one is talking to.

> 
> 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?
> 

I believe the current behavior is correct. The idea is to be able to
edit a template, and then validate it on all the clouds you want to push
it to.