quads icon indicating copy to clipboard operation
quads copied to clipboard

Abstract VLAN calculations out of move-and-rebuild and into Cloud Itself

Open sadsfae opened this issue 6 years ago • 0 comments

Currently we do VLAN calculation for moving sets of machines into an environment in the orchestration that also does provisioning, network changes etc.

It would be better long-term (and open up more flexibility in network automation) if we moved this out of quads/tools/move_and_rebuild_hosts.py here https://github.com/redhat-performance/quads/blob/master/quads/tools/move_and_rebuild_hosts.py#L62

And instead made cloud VLANs a Python list associated with the cloud definition itself, one for every supported private VLAN type (currently Q-in-Q: 0 and Q-in-Q: 1)

e.g. for each cloud (matching either our defacto incremental numberings scheme by default or can be entered by the user when defining the cloud:

qinq_0_vlans =  ["1110", "1111", "1112", "1113"]
qinq_1_vlans =  ["1110", "1110", "1110", "1110"]

Where index 0,1,2,3 match the first, second, third, and fourth private internal interface of every system going into that cloud, for each respective, supported vlan type.

When network automation fires off it can simply compare the list index value of a host's interfaces to match the correct qinq_X_vlans index value for what vlan it should be moved to and no calculation at the orchestration level ala quads/tools/move_and_rebuild_hosts.py is needed.

Advantages

  • More flexibility in integrating into environments that might already have their own VLAN numbering scheme, or some id's are taken
  • Being a list allows for duplicates, so we could allow multi-cloud connectivity across common internal interfaces
  • Moves complexity out of the systems/network provisioning mechanics which is usually always a good thing
  • Allows host vlans to be easily redefined at the cloud level as an attribute, and being a list it's possible now to do things like have interface 1 + 2 be on the same VLAN and interface 3 + 4 have their own, or any combination of this.

Additional Uses

There's a bunch of new metadata in 1.1 which is contained under the interfaces section of the host collection. Currently there is an unused/optional variable for vlan. Let's make this a private var that looks up the value of the vlan that host(s) interface(s) are in at that current time. This would be useful for informative queries and information gathering.

e.g.

> db.host.find( { name : "f13-h20-b04-5039ms.rdu2.example.com" } ).toArray()[0]["interfaces"]
[
        {
                "name" : "em1",
                "mac_address" : "00:25:90:5f:5f:1e",
                "ip_address" : "10.1.34.248",
                "vlan" : "601",
                "switch_port" : "et-0/0/10:2"
        },
        {
                "name" : "em2",
                "mac_address" : "00:25:90:5f:5f:1f",
                "ip_address" : "10.1.34.248",
                "vlan" : "601",
                "switch_port" : "et-0/0/10:3"
        },
        {
                "name" : "em3",
                "mac_address" : "ac:1f:6b:2d:58:2d",
                "ip_address" : "10.1.34.248",
                "vlan" : "601",
                "switch_port" : "xe-0/0/22:3"
        }
]

sadsfae avatar Mar 07 '19 14:03 sadsfae