ResourceGroup attributes don't work with index lookups

Yeah that behavior looks correct to me. It is indeed a bit confusing with regard to the regular get_attr behavior, but it behaves fairly differently on stack resources in general.

Fortunately you don't need yaql. You can either do:

{get_attr: [rg, 'resource.0', value]}

Or

  rg_val:
    type: OS::Heat::Value
    properties:
      value: {get_attr: [rg, value]}

{get_attr: [rg_val, value, 0]}

Yeah this has been discussed earlier too and documenting it would be help. I assume specifying as below would work, no?

value: {get_attr: [rg, resource.0, value]}

@therve, I did not see your comment before posting mine;)

> {get_attr: [rg, 'resource.0', value]}

Yeah this is what TripleO already does, but there's a subtle problem here - the "0" doesn't refer to a list index, it refers to a resource name "0" in the nested stack. So this breaks if you ever remove that node from the group via removal_policies (ref https://bugs.launchpad.net/tripleo/+bug/1640449)

> rg_val:
> type: OS::Heat::Value
> properties:
> value: {get_attr: [rg, value]}
>
> {get_attr: [rg_val, value, 0]}

Hmm, yeah this may work, as what we want is the first item in the list, independent of the group member naming.

I also have a yaql workaround, but it's probably more ugly than the OS::Heat::Value approach. One question - what does the value return during validation? If it's None I'm wondering if the index lookup in the second get_attr will fail? (I had to work around that in my yaql solution):

      input_values:
        bootstrap_nodeid:
          yaql:
            expression: coalesce($.data, [''])[0]
            data: {get_attr: [{{role.name}}, hostname]}

So the OS::Heat::Value workaround doesn't work, because during validation the index "0" doesn't exist, see https://review.openstack.org/#/c/395699/

Deployment fails with:

ERROR: resources.BlockStorageAllNodesDeployment.Properties.input_values.bootstrap_nodeid.get_attr: : The Referenced Attribute (BlockStorageHostnameDetails 0) is incorrect."

So I suspect we'll be forced to go with the yaql approach unless we can figure out a cleaner workaround?

All I want is to get the first resource from the group, without hard-coding a name for a group member which may subsequently get removed.

I think the ultimate answer is to stop using removal policies and mark resources as unhealthy instead.

> I think the ultimate answer is to stop using removal policies and mark resources as unhealthy instead.

Long term you may be right, but short term that doesn't help us as we're doing index based personalization of servers, which means we want index->server relationships to be unique (e.g rebuilding index "0" and getting a completely different node in the rack built will not be acceptable for some operators).

Another possibility is we stop using heat to build the servers altogether and instead build them via a mistral workflow, but again that is a long term idea. For now I'll hack around it with some ugly yaql logic :\

For anyone interested in the workaround, it looks like this:

        first_hostname_in_group:
          yaql:
            expression: coalesce($.data, []).first(null)
            data: {get_attr: [TheResourceGroup, hostname]}

hostname returns a list, which may be empty for zero count ResourceGroups, hence the first(null). The coalesce is needed because get_attr returns None during validation, which breaks the query unless we handle it by defaulting to an empty list.

We don't really have a great solution for now, I suspect it relies on improving validation in general. There is a workaround, so let's push it for now.