Expose extended attribute in realization info data source

[GraysonWu]

Fixes #793

[ksamoray]

Should we be able to retrieve multiple attributes for the same resource?
Also, why is this a part of the generic realization info, instead of being part of the tier1 datasource?

[annakhm]

Should we be able to retrieve multiple attributes for the same resource? Also, why is this a part of the generic realization info, instead of being part of the tier1 datasource?

If we choose to expose extended attributes for all objects, I would suggest to return the whole set as a Map type, so that the user would be able to use it as follows: data.nsxt_policy_realization_info.info.extended_attributes["ip_address"]

[GraysonWu]

Should we be able to retrieve multiple attributes for the same resource? Also, why is this a part of the generic realization info, instead of being part of the tier1 datasource?

If we choose to expose extended attributes for all objects, I would suggest to return the whole set as a Map type, so that the user would be able to use it as follows: data.nsxt_policy_realization_info.info.extended_attributes["ip_address"]

Yes, using a map could be a better option. But there might be multiple entities for a specific entity_type. For example, a user wants to know the IP addresses. Multiple RealizedLogicalRouterPort entities will be returned, and only one of it have IP addresses. We are not sure which attribute users care to decide which entity we want to return.

Our current logic is: if entity_type is not specified, we return the first one. If entity_type is specified, we return the first one matching the entity_type. So I added the extended_attribute_key to let the users specify which key they want. If multiple entities have the key, the first one will be returned.

[GraysonWu]

Should we be able to retrieve multiple attributes for the same resource? Also, why is this a part of the generic realization info, instead of being part of the tier1 datasource?

Because in API, those IP addresses are not exposed in tier1, only in realization info. But we could call realization info API behind the scenes for tier1 data source, which may also require a polling mechanism to wait for that logical router port to be in the REALIZED state. Glad to hear your ideas thx.

[ksamoray]

Should we be able to retrieve multiple attributes for the same resource? Also, why is this a part of the generic realization info, instead of being part of the tier1 datasource?

Because in API, those IP addresses are not exposed in tier1, only in realization info. But we could call realization info API behind the scenes for tier1 data source, which may also require a polling mechanism to wait for that logical router port to be in the REALIZED state. Glad to hear your ideas thx.

Or require the user to add a dependency between the T1 data source and the realization resource if the IPs are needed - we can document this if we don't trust the user's intuition 😁

Either way these are just proposals - I'm good with any solution.

[annakhm]

LGTM, but lets add a test for this data source? We could piggyback on existing test for gateway interface resource and add this data source.

[vmwclabot]

@GraysonWu, you must sign every commit in this pull request acknowledging our Developer Certificate of Origin before your changes are merged. This can be done by adding Signed-off-by: John Doe <[email protected]> to the last line of each Git commit message. The e-mail address used to sign must match the e-mail address of the Git author. Click here to view the Developer Certificate of Origin agreement.

• Commit 77a339d must be signed by [email protected]

[GraysonWu]

/test-all

[GraysonWu]

/test-all

[GraysonWu]

/test-all