Re: [openstack-dev] [Heat] conditional resource exposure - second thoughts
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:zbit...@redhat.com] Sent: Wednesday, July 15, 2015 1:05 AM To: openstack-dev@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 p
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/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
Re: [openstack-dev] [Heat] conditional resource exposure - second thoughts
On 07/14/2015 02:46 PM, Clint Byrum wrote: > 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. I'd agree with Clint. Think about a user that says to themselves "Hey, I want to see *all* the Heat resources!" Will they: 1) Google "heat resources openstack" or similar, landing at our docs page with the list in a nice, human-friendly format. 2) Look in the API endpoint docs and find a flag to show disabled resources. Then call that endpoint and read the JSON response. I think the answer is going to be (1) for the vast majority of users >> 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. Maybe it would be valuable to distinguish (when failing a validation) between "Resource Foo::Bar is not a thing at all" and "Resource OS::Zaqar::Queue is disabled on this cloud". I'm not sure if validate currently makes that distinction, but it likely should. -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. __ 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
Re: [openstack-dev] [Heat] conditional resource exposure - second thoughts
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. __ 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-dev] [Heat] conditional resource exposure - second thoughts
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 __ 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
