Open Stack

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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>