On Jul 2, 2015, at 2:35 PM, Steve Baker <sba...@redhat.com>
wrote:
> On 03/07/15 06:03, Randall Burt wrote:
>> Maybe use "all" for all attributes in the schema and use "show" for the raw
>> output from the service (as is done today for server and neutron stuff).
> Instead of "all", how about allowing a special form of {get_attr:
> [resource_name]} with no extra arguments to return a dict of all attributes?
> This would be consistent with how extra arguments traverse attribute data.
+1 (Hope you can read this despite my bobo client).
>> On Jul 2, 2015, at 12:46 PM, Steven Hardy <sha...@redhat.com>
>> wrote:
>>
>>> On Thu, Jul 02, 2015 at 04:40:49PM +0300, Sergey Kraynev wrote:
>>>> Hi Heaters.
>>>> I don't think that my question is very huge for openstack-dev, but it
>>>> affects a lot of Heat resourcesA
>>>> and need collect more opinions before apply some of follow approaches.
>>>> I recently uploaded initial approach for implementation common 'show'
>>>> attribute [1]A
>>>> On one of this review was raised one interesting suggestion:
>>>> 'show' attribute should return map of all resource's attributes, i.e.
>>>> for each attr in self.attributes_schema:
>>>> A A outputs[attr] = A _resolve_attribute(attr)
>>>> return outputs
>>>> I agree, that it's more easier than separate show_resource method for
>>>> each
>>>> resource and it's the same, what returns Neutron API on "show" request.
>>>> However, we already has opposite example, when OS::Nova::Server resource
>>>> has bunch of attributes which are not similar on current 'show' attribute
>>>> output:
>>>>
>>>> https://github.com/openstack/heat/blob/master/heat/engine/resources/openstack/nova/server.py#L918
>>>> I suppose, that the same situation will be and for other resources.
>>>> So I want to ask about way, which we would like to follow?
>>>> [1] "show" as collection of attributes
>>>> [2] "show" as the same output for command "<some client> A <name of
>>> I think [2] is the most useful, and most consistent with both the nova and
>>> all neutron resources:
>>>
>>> https://github.com/openstack/heat/blob/master/heat/engine/resources/openstack/neutron/neutron.py#L129
>>>
>>> Another advantage of this "transparent" passthrough of the data returned by
>>> the client is folks have a workaround in the event heat attributes schema
>>> lack some new value that the client returns. Obviously when it's added
>>> to the attributes schema, it'll be better to use that instead.
>>>
>>> Steve
>>>
>>> __________________________________________________________________________
>>> 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
>
>
> __________________________________________________________________________
> 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
