Open Stack

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.
> On Jul 2, 2015, at 12:46 PM, Steven Hardy <shardy at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev