On 14/07/15 14:34, Pavlo Shchelokovskyy wrote:
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 :)
I worry that this could result in leakage of potentially-sensitive
information. e.g. once we have this feature implemented, an operator
could deploy a plugin that is only for the use of one particular user,
who has a custom role. I don't think it would be expected that other
users (without that role) in other tenants could find out about that,
even if all they can find out is the name of the resource type.
I definitely think that admins should have a way of getting a list of
_all_ resource types (preferably annotated with the roles required to
use them). Just not ordinary users.
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)?
This is totally unnecessary IMHO for the reasons Clint mentioned. Again,
I could imagine an exception for admins though, since I suspect that
this API is the only way we can annotate resource types with the roles
required without performing major surgery on resource-type-list.
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?
You call template-validate when you're about to launch the template and
you want to know what parameters and stuff are required. If YOU cannot
launch THIS template on THIS cloud right NOW it should fail, period.
cheers,
Zane.
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
__________________________________________________________________________
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
__________________________________________________________________________
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
