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