[openstack-dev] [Heat] Combination of Heat ResourceGroup(index) with Fn::Select doesnt work ?

Hemanth Ravi hemanthraviml at gmail.com
Tue Oct 21 23:43:15 UTC 2014


On Tue, Oct 21, 2014 at 12:32 PM, Zane Bitter <zbitter at redhat.com> wrote:

> On 21/10/14 14:05, Subrahmanyam Ongole wrote:
>
>> Hi
>>
>> We are in fact using OS::Neutron::PoolMember resource. I guess
>> ResourceGroup is the only iterative construct in Heat. Is the use case
>> supported today?  I think this is more than a simple usage question, hence
>> posting it here. Thank you.
>>
>> Regards
>> Subra
>>
>> On Tue, Oct 21, 2014 at 8:55 AM, Fox, Kevin M <Kevin.Fox at pnnl.gov> wrote:
>>
>>    use a OS::Neutron::PoolMember instead. Then each member template can
>>> add
>>> itself to the pool.
>>>
>>>   ------------------------------
>>> *From:* Magesh GV [magesh.gv at oneconvergence.com]
>>> *Sent:* Tuesday, October 21, 2014 12:07 AM
>>> *To:* openstack-dev at lists.openstack.org
>>> *Subject:* [openstack-dev] Combination of Heat ResourceGroup(index) with
>>> Fn::Select doesnt work ?
>>>
>>>    I am trying to find a way of creating a dynamic List of
>>> Resources(Loadbalancer PoolMembers to be exact) using Heat.
>>>
>>>   The idea is that the number of PoolMembers and the required Addresses
>>> would be received as  Heat parameters.
>>>
>>>   However, I am unable to get %index% working inside a Fn:Select block.
>>>
>>
> Yeah, it doesn't work inside intrinsic functions.
>
>    Is this a bug with Heat or am I doing something wrong ?
>>>
>>
> It's arguable ;)
>
>  If this is a
>>> bug/limitation in heat is there some other way to get what I am trying to
>>> do working with heat ?
>>>
>>
> You should define the PoolMember near the server it is linking to the
> pool, not in a separate ResourceGroup. Group together the things you want
> to scale as a group in a separate template and scale them as a unit.
>
>    IMO this is a very important usecase for the %index%.
>>>
>>
> I'm very uneasy about %index% existing at all, and I'm not at all
> convinced that allowing something like this would achieve anything beyond
> making bad template design more tempting.
>
> Can you talk more about why you need to define the PoolMember resources in
> a different place to the actual pool members?
>

The use-case is to define a template for an LB service and customize it.
The parameters i) number of members in the pool and ii) IP addr of each of
these members are not known when the template is defined. When the service
is instantiated using the template the code that generates the values for
these params will pass these in as parameter values to heat.


>
> cheers,
> Zane.
>
>
>    "Parameters": {
>>> "NumberOfMembers": {
>>>              "Description": "Number of Pool Members to be created",
>>>              "Type": "Number",
>>>      "Default": 1
>>>          },
>>>          "MembersList": {
>>>              "Description": "Pool Member IP Address",
>>>              "Type": "Json",
>>>      "Default": {"key0":"11.0.0.43"}
>>>          }
>>>      },
>>>
>>>   "MemberList": {
>>>           "Type": "OS::Heat::ResourceGroup",
>>>          "Properties": {
>>>            "count": {"Ref":"NumberOfMembers"},
>>>            "resource_def": {
>>>       "type": "OS::Neutron::PoolMember",
>>>       "properties": {
>>> "address": { "Fn::Select" : [ "key%index%", {"Ref":"MembersList"}] },
>>>               "admin_state_up": true,
>>>               "pool_id": {"Ref":"HaproxyPool"},
>>>               "protocol_port": "80",
>>>       "weight": 1
>>>             }
>>>       }
>>>            }
>>>   }
>>>
>>>   Regards,
>>> Magesh
>>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141021/3cbcc5e7/attachment.html>


More information about the OpenStack-dev mailing list