Open Stack

On 15/07/14 20:01, Zane Bitter wrote:
> On 14/07/14 12:21, Tomas Sedovic wrote:
>> On 12/07/14 06:41, Zane Bitter wrote:
>>> On 11/07/14 09:37, Tomas Sedovic wrote:
> 
[snip]
> 
>>>
>>>> Alternatively, we could extend the ResourceGroup's get_attr behaviour:
>>>>
>>>>       {get_attr: [controller_group, resource.0.networks.ctlplane.0]}
>>>>
>>>> but the former is a bit cleaner and more generic.
>>>
>>> I wrote a patch that implements this (and also handles (3) above in a
>>> similar manner), but in the end I decided that this:
>>>
>>>    {get_attr: [controller_group, resource.0, networks, ctlplane, 0]}
>>>
>>> would be better than either that or the current syntax (which was
>>> obviously obscure enough that you didn't discover it). My only
>>> reservation was that it might make things a little weird when we have an
>>> autoscaling API to get attributes from compared with the dotted syntax
>>> that you suggest, but I soon got over it ;)
>>
>> So now that I understand how this works, I'm not against keeping things
>> the way we are. There is a consistency there, we just need to document
>> it and perhaps show some examples.
> 
> It kind of fell out of the work I was doing on the patches above anyway.
> It would be harder to _not_ implement this (and the existing way still
> works too).

Okay, fine by me :-)

> 
>>>
>>>> ---
[snip]
>>
>>>
>>> There is one aspect of this that probably doesn't work yet: originally
>>> outputs and attributes were only allowed to be strings. We changed that
>>> for attributes, but probably not yet for outputs (even though outputs of
>>> provider templates become attributes of the facade resource). But that
>>> should be easy to fix. (And if your data can be returned as a string, it
>>> should already work.)
>>
>> Unless I misunderstood what you're saying, it seems to be working now:
>>
>> controller.yaml:
>>
>>      outputs:
>>        hosts_entry:
>>          description: An IP address and a hostname of the server
>>          value:
>>            ip: {get_attr: [controller_server, networks, private, 0]}
>>            name: {get_attr: [controller_server, name]}
>>
>> environment.yaml:
>>
>>      resource_registry:
>>        OS::TripleO::Controller: controller.yaml
>>
>> test-resource-group.yaml:
>>
>>      resources:
>>        servers:
>>          type: OS::Heat::ResourceGroup
>>          properties:
>>            count: 3
>>            resource_def:
>>              type: OS::TripleO::Controller
>>              properties:
>>                key_name: {get_param: key_name}
>>                image: {get_param: image_id}
>>
>>      outputs:
>>        hosts:
>>          description: "/etc/hosts entries for each server"
>>          value: {get_attr: [servers, hosts_entry]}
>>
>> Heat stack-show test-resource-group:
>>
>>     {
>>       "output_value": [
>>         "{u'ip': u'10.0.0.4', u'name':
>> u'rg-7heh-0-tweejsvubaht-controller_server-mscy33sbtirn'}",
>>         "{u'ip': u'10.0.0.3', u'name':
>> u'rg-7heh-1-o4szl7lry27d-controller_server-sxpkalgi27ii'}",
>>         "{u'ip': u'10.0.0.2', u'name':
>> u'rg-7heh-2-l2y6rqxml2fi-controller_server-u4jcjacjdrea'}"
>>       ],
>>       "description": "/etc/hosts entries for each server",
>>       "output_key": "hosts"
>>     },
> 
> It looks like the dicts are being converted to strings by Python, so
> there probably is a small bug here to be fixed. (At the very least, if
> we're converting to strings we should do so using json.dumps(), not
> repr().)

Ooops, you're right. In my excitement, I completely missed that!

> 
> [snip]
> 
>>>>
>>>> So this boils down to 4 features proposals:
>>>>
>>>> 1. Support extended attributes in ResourceGroup's members
>>>
>>> Sorted.
>>
>> Yep
>>
>>>
>>>> 2. Allow a way to use a Resource ID (e.g. what you get by {get_attr:
>>>> [ResourceGroup, refs]} or {get_attr: [ResourceGroup, resource.0]}) with
>>>> existing intrinsic functions (get_resource, get_attr)
>>>
>>> No dice, but (1) solves the problem anyway.
>>
>> Agreed
>>
>>>
>>>> 3. A `map` intrinsic function that turns a list of items to another
>>>> list
>>>> by doing operations on each item
>>>
>>> There may be a better solution available to us already, so IMO
>>> investigate that first. If that turns out not to be the case then we'll
>>> need to reach a consensus on whether map is something we want.
>>
>> You're right. I no longer think map (or anything like it) is necessary.
> 
> That's the kind of thing I love to hear :D
> 
>>>> 4. A `concat_list` intrinsic function that joins multiple lists into
>>>> one.
>>>
>>> Low priority.
>>
>> Yeah.
>>
>>>
>>>> I think the first two are not controversial. What about the other two?
>>>> I've shown you some examples where we would find a good use in the
>>>> TripleO templates. The lack of `map` actually blocks us from going
>>>> all-Heat.
>>>
>>> Hopefully that's not actually the case.
>>>
>>>> The alternative would be to say that this sort of stuff to be done
>>>> inside the instance by os-apply-config et al. It would complicate
>>>> things
>>>> for TripleO, but oh well.
>>>
>>> It seems to me that the alternative is not necessarily to modify
>>> os-apply-config, but rather to provide a software config with a script
>>> that converts the data from whatever format Heat can supply to whatever
>>> format is needed by the application. Although I don't think it's even
>>> required in the specific case you mention, I find that a much better
>>> answer for the general case than turning the template format into the
>>> JSON equivalent of XSLT ;)
>>
>> That's what I thought -- not rewriting os-apply-config but simply
>> passing the raw data to it and changing the tripleo image elements to
>> output the configuration format required by the applications.
>>
>> +1 on the XSLT sentiment, I just didn't realise we pretty much solve
>> everything with the existing model (hat off to the design btw, I love
>> how it works together -- we just maybe need to communicate it a bit
>> more).
> 
> Yeah, we're thinking of trying to put something together for the summit
> to explain how the pieces fit together. You're not the only one looking
> for that documentation, I suspect :)
> 
> cheers,
> Zane.
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
>