[openstack-dev] 答复: [Heat] conditional resource exposure - second thoughts
huangtianhua at huawei.com
Wed Jul 15 02:44:36 UTC 2015
发件人: Zane Bitter [mailto:zbitter at redhat.com]
发送时间: 2015年7月15日 3:35
收件人: openstack-dev at lists.openstack.org
主题: 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 , and soon we will do the same based on
> whether actual user roles allow creating specific resources . 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.
> 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'd agree with Zane. Only allow admins to getting all resource types not ordinary users.
> 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)?
I'd prefer to allow admins to show all resource type. The behavior should be consistent, ordinary users can only show the resource type which they can list.
> 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'd agree with Zane. And I think if we can give the detail reasons(service unavailable or resources type is not supported) why the validation is failed will be good to users.
> 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.
> Best regards,
> Dr. Pavlo Shchelokovskyy
> Senior Software Engineer
> Mirantis Inc
> ____ OpenStack Development Mailing List (not for usage questions)
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev