redhat_best_placement_with_scope: vm network availability in the selected cluster not evaluated

[sigbjornaib]

The vm placement code In the / RedHatConsulting_Utilities / Infrastructure / VM / Provisioning / Placement / redhat_best_placement_with_scope method does not check if the selected RHV VM Network Profile is available in the RHV Cluster being selected.

This results in a failure where the vm configuration is attempted to be updated with the selected RHV network profile.

The issue occur when RHV Clusters inside a RHV Data Center have different networks configured. Not all networks defined in the RHV Data Center are configured on all RHV Clusters. Networks are defined in the RHV Cluster based on what services should be provided by the RHV Cluster.

[itewk]

@sigbjornaib first let me make sure we are on the same page with how everything is selected.

As an innate property of CFME to call create_provision_request you must specify a VM template, that VM template will exist by necessity of RHV on one cluster. Therefor by selecting the VM template you have by defacto selected the cluster. Therefor the only thing that can happen in the dynamic determine placement method is selecting a host and/or storage.

If you look at https://github.com/RedHatOfficial/miq-Utilities/blob/master/Automate/RedHatConsulting_Utilities/Service/Provisioning/DynamicDialogs.class/__methods__/get_templates_based_on_selected_os_and_location.rb you will see that the code for determining the template is based on the selected Location and OS, where it is expecting the location on a provider, and the OS on a template. Therefor the current code is woefully cluster un-aware. It was only ever tested and used in a single cluster RHV environment and a multi cluster with DRS VMware environment. For VMware it is fine because https://github.com/RedHatOfficial/miq-Utilities/blob/master/Automate/RedHatConsulting_Utilities/Infrastructure/VM/Provisioning/Placement.class/__methods__/vmware_drs_cluster_best_fit_with_scope.rb#L78-L91 will select a DRS enabled cluster no matter the selected template.

For RHV, I have not tested this in a long time, but if memory serves, you have to have the template on the cluster you are cloning it onto, therefor the tempalte must drive the cluster decision and the cluster can not be decided in placement for RHV. So, first thing would be to find out whether you can clone a template on Cluster A onto Cluster B. If that is possible then a new placement method could be made that only pays attention to the provider a template is on for RHV and then selects a cluster based on some other algorithm. If it is not possible for a tempalte on Cluster A to be cloned onto Cluster B then the logic in https://github.com/RedHatOfficial/miq-Utilities/blob/master/Automate/RedHatConsulting_Utilities/Service/Provisioning/DynamicDialogs.class/__methods__/get_templates_based_on_selected_os_and_location.rb would need to be updated to allow clusters to be tagged with locations as well and look at the clusters if the provider is tagged with more then one location. So you could tag the provider with "Location A and Location B" and then on cluster on the provider with "Location A" and another cluster with "Location B", thus allowing you to select the destination cluster as part of the location you are selecting.

Now as far as the network goes. This gets even trickier. Reading through and understanding https://github.com/RedHatOfficial/miq-Utilities/blob/master/Automate/RedHatConsulting_Utilities/Service/Provisioning/DynamicDialogs.class/__methods__/get_networks.rb#L138-L175 is important.

The main steps are:

1. collect host based networks
2. determine the destination networks shared by all hosts on the selected destination provider
3. find networks that match the network configuration names
4. determine the selecatable networks shared by all hosts that are also have network configuration with a network address space

Based on those steps it should be currently impossible to select a network that isn't available on all hosts for a given provider precisely to avoid this issue are seeing. There is the ability to do networking naming selection based on a regex so that if cluster A calls a network one thing, and cluster B calls it another that the code can find that network on both. But since this set of code is not cluster aware it does not allow you to be able to select a network that only exists on one cluster and not another.

If you want to take a stab at determine:

1. can you select a template on cluster A and have it provision to cluster B
2. based on that answer either

• create a new placement method that ignores the cluster a tempalte is on rather only looks at the provider and selects a cluster based on other criteria
• OR update the get_templates_based_on_selected_os_and_location to be cluster aware by allowing providers to be tagged with multiple locations, and if so then looking at location tags at the cluster level and then updating the get_networks code accordingly.

As it is I am not seeing a path for how it would be possible for you to select a Location and OS tag that in turn selects a template which in turn determine the network list that would allow you to select a network that is not available on the cluster that the template is on.

[sigbjornaib]

First of all. Thank you for the very good and thorough feedback.

I have read through the code and your comments. I see that the code in get_templates_based_on_selected_os_and_location.rb expects the OS tag for a Template to be unique across the entire provider. This seem a bit confusing when reading the INSTALL.md which uses only RHEL6 and RHEL7 as examples for the OS tag. I would suggest updating the examples to use DC-Cluster-RHEL6 and DC-Cluster-RHEL7 as examples instead, if the code in get_templates_based_on_selected_os_and_location.rb is expected to remain unchanged.

I have tested that a template from cluster A can be deployed to cluster B withtin RHV 4.2.8. The test was done using the RHV webadmin, not sure if the RHV API works differently. I believe what you are referring to is the way RHV used to work in the past, if memory serves me correctly.

Perhaps looking at how Satellite 6 handels integration to RHV would be a good place to start. Our current deployment methods for all RHV datacenters and clusters are performed using Satellite. When I go to "Create Host" in Satellite I start by entering a Name, Organization, Location, and Host Group. Based on the Organization and Location selections I am displayed an available Satellite Compute Resource to deploy on, which is mapped to a RHV Data Center. Switching to the Virtual Machine tab I can now select any of the RHV Clusters in the selected Compute Resource (RHV Data Center). Now switching to the "Interfaces" tab and editing the interface, I see only the RHV Networks available in the selected RHV Cluster in the selected Compute Resource (RHV Data Center).

In other words, the available RHV Networks exposed to the Satellite user is only the interfaces available in the selected destination cluster.

Satellite is doing an OK job of provisioning VMs, however customisation of the config on the provisioned RHV VM is limited. The rest of the configuration process in Satellite is very flexible, but it does require advanced knowledge to operate. And the role based access for non-admins does not work well. Hence the move to Cloudforms.

Going back to Cloudforms I do not see any reason to expose the full Satellite workflow, as this does require advanced knowledge, however perhaps this would be a good workflow:

1. Create 1 template per RHV cluster, tag the template using

• RHEL OS tag
• environment tag.
• pod (Point of Delivery) tag.
• provisioning scope tag

2. Expose the pod tag in the service catalog item
3. Tag the Provider with a single location, but multiple environments.
4. Filter the templates returned from get_templates_based_on_selected_os_and_location.rb on the

• The provider matching the selected location tag (as it is today)
• The template matching the selected os tag, the selected environment tag, the select pod tag and the provisioning scope tag.

4. The get_networks.rb displays the networks available on the cluster where the selected template is located. Filter the networks based on the provisioning scope tag.

(Not sure how the prov scope tag filtering can be done for the networks coming from RHV, as I do not see anywhere you can put tags on RHV Networks even though the Cloudforms 4.7 release notes mentioned a new feature for tagging networks.)

This should not be too hard to implement? Perhaps some of this is possible already which I am just aware of?

This would allow for reuse of most of the existing code as the main changes happens in the template tagging, and it allows for a much more flexible provisioning model based on more than just provider and os tag selection.

[itewk]

I have tested that a template from cluster A can be deployed to cluster B withtin RHV 4.2.8. The test was done using the RHV webadmin, not sure if the RHV API works differently. I believe what you are referring to is the way RHV used to work in the past, if memory serves me correctly.

If that is indeed the case then there is probably some streamlining that could be done.

(Not sure how the prov scope tag filtering can be done for the networks coming from RHV, as I do not see anywhere you can put tags on RHV Networks even though the Cloudforms 4.7 release notes mentioned a new feature for tagging networks.)

@sigbjornaib we did look into, and even prototype a way of doing this that involved tagging networks, but it involved a lot of hacks and custom UI dialogs that were janky since the feature was not built into CFME itself. This is why we ultimately ended up going with the solution of having the config domain where you create the configs per the network patterns you want to provision too.

If CFME ever has UI for tagging networks then maybe this could change in the future.

This should not be too hard to implement? Perhaps some of this is possible already which I am just aware of?

Not sure which part you are refering to to implement here.