Open Stack

Like to share my opinions as below:

Resource-type-list/resource-type-show:
	Once the role based resource exposure is enabled, based on the user's role, I believe, (s)he would expect to see those deployed resource-types, which are authorized. And wanted to know if that resource-type is available currently on that cloud. So by default, it will essentially filter out those un-authorized resource-types from the users, but it will provide the additional information, whether resource-type is currently available or not. (admin has access to all resource-types). And resource-type-list could be enhanced further with additional filtering flag like :

'---show-authorized': default behavior
'--show-unavailable': list those authorized un-available resource-types
 '--show-available': list those authorized available resource-types
'--show-unauthorized': This may be wrong one, I too believe. But like to get others opinion on it. It list all the deployed resource-types, which are un-authorized. It  becomes like live resource-type documents from running heat service. (other place user may want to know the same details from the public resource-type document available in the internet) . But here, operators may want to disable to report the un-authorized resource-types to those user, who does not have right roles. So we could provide config parameter for the same. I'm not sure on it though !

Template-validate:
	As it really helps user to validate the template, before starting the stack creation, it would be better to validate complete template and report all the errors in the template, which includes the unavailability of the service in the service catalog, authorization check as well. Currently, template-validate exit on the occurrence of first error in the template. (I'm working on it)

Regards
Kanagaraj M


-----Original Message-----
From: Zane Bitter [mailto:zbitter at redhat.com] 
Sent: Wednesday, July 15, 2015 1:05 AM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [Heat] conditional resource exposure - second thoughts

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/conditio
> nal-resource-exposure-services.html
>
> [2]
> http://specs.openstack.org/openstack/heat-specs/specs/liberty/conditio
> nal-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
>


__________________________________________________________________________
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