Support realized_id in ip pool data source

[annakhm]

This id should be used in transport node resource
Signed-off-by: Anna Khmelnitsky akhmelnitsky@vmware.com

[annakhm]

/test-all

[ksamoray]

nsxt_policy_realization_info data source is usable with IP pools, why do we need this specifically for IP pool?

[annakhm]

nsxt_policy_realization_info data source is usable with IP pools, why do we need this specifically for IP pool?

It is just more convenient.. we expose this attribute in resource, makes sense to do this in data source as well

[ksamoray]

nsxt_policy_realization_info data source is usable with IP pools, why do we need this specifically for IP pool?

It is just more convenient.. we expose this attribute in resource, makes sense to do this in data source as well

But policy_ip_pool resource doesn't have this attribute.

[salv-orlando]

nsxt_policy_realization_info data source is usable with IP pools, why do we need this specifically for IP pool?

It is just more convenient.. we expose this attribute in resource, makes sense to do this in data source as well

But policy_ip_pool resource doesn't have this attribute.

It's always good to be consistent indeed. Also, as the attribute in API spec is called realization_id, I would stay consistent also with naming

[ksamoray]

nsxt_policy_realization_info data source is usable with IP pools, why do we need this specifically for IP pool?

It is just more convenient.. we expose this attribute in resource, makes sense to do this in data source as well

But policy_ip_pool resource doesn't have this attribute.

It's always good to be consistent indeed. Also, as the attribute in API spec is called realization_id, I would stay consistent also with naming

We already have realized_id attributes in other objects. It's better to remain consistent within the provider than being consistent with NSX.

[annakhm]

nsxt_policy_realization_info data source is usable with IP pools, why do we need this specifically for IP pool?

It is just more convenient.. we expose this attribute in resource, makes sense to do this in data source as well

But policy_ip_pool resource doesn't have this attribute.

It's always good to be consistent indeed. Also, as the attribute in API spec is called realization_id, I would stay consistent also with naming

We already have realized_id attributes in other objects. It's better to remain consistent within the provider than being consistent with NSX.

I've added this attribute to the resource as well

[annakhm]

/test-all

[ksamoray]

/test-all

[ksamoray]

LGTM. Please rebase on top of master so tests will pass.
I think that maybe in a couple of more we can justify a getRealizedIdSchema() func :)

[annakhm]

/test-all