Add zone to service templates.

[lfu]

Add zone to service templates to allow the running of service-related automate tasks in a specific zone.

Blocks ManageIQ/manageiq#18601
https://bugzilla.redhat.com/show_bug.cgi?id=1415106

@miq-bot add_label enhancement
cc @tinaafitz

[carbonin]

Shouldn't this be adding a reference? Not a column called zone?

[lfu]

Oops, I changed it from add_reference to add_column and forgot renaming the field.

Index seems not necessary so I selected add_column over add_reference. Seems there is no any place where we would query select service templates by a zone.

[carbonin]

Should we set a zone for the already existing service templates as a part of this change as well?

[carbonin]

Also, why is this on the service template and not the service? Should this not be overrideable at the service level?

[miq-bot]

Checked commit lfu@d2008ef with ruby 2.3.3, rubocop 0.52.1, haml-lint 0.20.0, and yamllint 1.10.0
1 file checked, 0 offenses detected
Everything looks fine. 🏆

[lfu]

A service template's zone is an optional column. If the zone is not specified, the service provision would behave like before that the work can be handled in any zone.

A service template is the blueprint of the service provision where it defines what resources would be provisioned and how the provision should be processed. As a result of the provision, a service object along with its resources would be created.

The added zone column would be used to decide in which zone the provision should be handled.

@carbonin Is this helpful?

[carbonin]

@lfu Yes, but it leads to another question. If a service is provisioned to a particular zone, should we be recording that in the service? What if a user changes the zone of the service template after the service was provisioned? Should that zone change be inherited by the service or should we always know the zone the service was originally assigned to?

[pemcg]

My view is that we wouldn't need to record this in the service. The advantage of being able to specify the zone at service template creation time is to be able to target the service's workflow towards a particular zone in the service definition, rather than it being run in any zone as at present. It's about defining where the workflow will run to take into account things like network restrictions.

Does that make sense?

[tinaafitz]

Thanks @pemcg, that makes sense.

[carbonin]

Yeah, I'm not questioning the motivation for specifying the zone in the template, I'm just questioning if this is all the information we need.

None of your justification addresses the situation I proposed in my last comment where the template zone is changed after provisioning. So to take that example further, is the service-specific automation the only place we will use this zone or might it get used for some custom retirement logic in the future? And will that logic always be run where the template specifies or should it be run where the service was first provisioned?

[carbonin]

I guess this conversation doesn't preclude merging this PR though, so this looks good to me as is. If we end up needing this on the service as well that can be a follow-up.