Fixes #18088 - Add compute resources to subnets

[bagasse]

Depends on [1]. No change needed on fog.

• Add association between foreman subnets and compute resource
  • Add migration for SubnetComputeResource
  • Now in the subnet form, a new tab to select compute resources was added (like it was for DNS domains)
• On host nic's form, select only subnets associated to the selected compute resource
• On host nic's form, when you select a subnet for the current nic:
  • For oVirt CR, the 'network' select have only untagged networks or tagged networks with the same VLAN ID of the selected subnet. Preselect the last CR network with the same VLAN ID as selected subnet if any.
  • For other CR types, 'network' select didn't change and return all CR networks without automatic pre-selection.

Tested with oVirt 4.0.5 with APIv3 and [1] applied to rbovirt. Any advises to add automated test for this PR are welcome.

[1] abenari/rbovirt#116

[mention-bot]

@bagasse, thanks for your PR! By analyzing the history of the files in this pull request, we identified @timogoebel, @domcleal and @dLobatog to be potential reviewers.

[ohadlevy]

wouldnt it be better to link the compure resource to an interface object (nic) instead? /cc @ares ?

[ares]

I think it makes more sense to link CR to subnet as suggested in the patch. For virtual interfaces (vlans, aliases, bonds, bridges) the association would not make sense since they don't exist in the hypervisor. Or is there some use case I'm missing? From quick scan of the PR, we should make sure that it works with bare metals well too, I haven't tested but I think it might fail in host form.

[bagasse]

The fog part was released yesterday (fog 1.40), so all third party deps are now released.

• Rebased
• Updated Gemfile (bump fog-core and fog versions)

[bagasse]

[test foreman]

[ohadlevy]

is there a way to default to the taxonomy subnets instead of introducing a new db model?

[bagasse]

@ohadlevy thanks for taking time to look at this PR. I implemented it like it was already done for domains. All the code i've seen related to taxonomy was for rights management, orgs and locations, so i didn't take a look at it as a way to implement this. I didn't saw many documentation (developer handbook, blog, or videos/deepdive) about taxonomies. If you have some resources to share, i will be happy to take a look at it.

[timogoebel]

@bagasse : First of all, thanks for the PR.

I briefly checked it out and I think, this isn't a complete solution. I'd suggest that instead of linking subnets to compute resources it would be better to link subnets to compute resource networks instead.

Allow me elaborate:
With VMWare or Ovirt you can define virtual networks (e.g. VLANs). There usually is a one-to-one relationship to a subnet. We have a lot of users that complain that when they create a host they have have to select the VMWare network in addition to the subnet. E.g. we have a Subnet called "general purpose VLAN 123" and a VMWare network called "VLAN-123". If we could link them, that would avoid a lot of errors.
As to other compute resources: AWS has VPC subnets. It would make sense there as well. Openstack is similar. Digitalocean doesn't have the concept of subnets.
Baremetal could be a "virtual compute resource".

@ohadlevy / @ares: Any comments to this approach?

[bagasse]

@timogoebel, thank you for your comment. The original purpose of this PR was to automatically link foreman subnets to VLAN based Compute resources virtual networks based on VLAN ID in the foreman subnet and in the virtual network. So the mapping to compute resource is mostly sufficient for these case because of this common id. It keep the mapping configuration and the mapping UI simple and similar to the subnet-domain mapping. We don't use any other compute resource than ovirt ATM, so I didn't take a look on how other common foreman compute resources work on the network part.
From your comment I understand that this work can be used on more compute resources than vlan based ones if I map subnet directly to a compute resource network. I will dig into the other compute resources available in the foreman to see how i can do the mapping.

For the UI part, do you have any pointer ?
I don't see how to make it on a single page like it is now, because we add another level. For each compute resource, we have to select the corresponding network to be mapped. From the top of my head i think about an UI like it is used for host interfaces. A table of mapping, and a modal with two searchable select boxes. The first one for compute resources, the second for the selected compute resource networks. When you validate your selection, it add it to the mapping table.

[timogoebel]

@bagasse:

The original purpose of this PR was to automatically link foreman subnets to VLAN based Compute resources virtual networks based on VLAN ID in the foreman subnet and in the virtual network.

Yeah. That would have been my preferred way to do that as well. Unfortunately, reality looks different. On VMWare you actually don't have an easy way to get the VLAN-ID of a VM. I think my previous comment didn't make this clear. I believe, it's similar with OpenStack. AWS doesn't have the concept of a VLAN, just VPCs. That's why I'd suggest to use a different mapping.
In addition there are customers who have independent subnets with the same Vlan id, e.g. they reuse vlan id "10" at different locations and the networks are not connected.

We don't use any other compute resource than ovirt ATM

Unfortunately I don't have oVirt available to fully test this PR.

For the UI part, do you have any pointer ?

How about using multiple_selects (see form_helper) and display them for every compute resource in an accordion?
Or displaying multiselects for every compute resource?
Please don't forget that we need a solution for BareMetal as well.
How about a policy like this:

• When you create a network and don't associate it to any Compute Resource / Baremetal it's always shown when creating a host. If you limit it to BareMetal, it's only shown for BareMetal. If you limit it to a network of a compute resource, it's only shown for this specific compute resource.

Does that make sense to you? If you are willing to change your implementation to what I suggested, I'd be happy to assist if time permits.
Before you start, I'd like to hear more comments from foreman core members first.

[lzap]

I am with @timogoebel here, we need better flexibility here. Therefore associating subnet with CR network is better, but much more challenging of course as networks are not stored in our database. I will be more than happy to test on libvirt and also oVirt 3.6 (will need to install 4.0 I don't have one yet).

Additional note, when you look in the Foreman Survey 2017 you will find that libvirt is in wide use. This needs to work on there as well, luckily libvirt is very similar to oVirt (as oVirt uses it for backend).

I don't understand how exactly this should work with bare-metal. What is the expectations and workflow in this case?

[xprazak2]

Any progress here?

[bagasse]

Hi @xprazak2,

No this was abandoned. I think foreman is missing some piece on network management as stated in this comment to integrate compute resource correctly at network/subnet level. I will make a post on this to get some comments on this.