Open Stack

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.