Adjustments for SUSE manager for retail - Rough network setting

[Bischoff]

This pull request adds support for SUSE Manager for retail:

    +------------+-----------+------------+  10.160.0.0/16
    |            |           |            |
+---+----+   +---+---+   +---+----+   +---+----+
|  eth0  |   |  eth0 |   |  eth0  |   |  eth0  |
|        |   |       |   |        |   |        |
| server |   | proxy |   | client |   | minion |
|        |   |       |   |        |   |        |
+  eth1  |   |  eth1 |   |  eth1  |   |  eth1  |
+---+----+   +---+---+   +---+----+   +---+----+
    |            |           |            |
    +------------+-----------+------------+  192.168.5.0/24

• variable geometry bits:
  • new retail base setting
  • corresponding retail grain on the hosts
  • corresponding $RETAIL variable in the .bashrc on the host
• minimalistic network setup if in retail mode:
  • additional private network
  • a second interface to that network on each host
• hacks: needed repos and packages
  • retail "devel" repo (*)
  • branch network formula (**)
  • dhcp server and SuSEfirewall2 packages (**)

The plan is to rebase the finer setup from #383 on top of this PR.

(*) should go away when merged with suse manager
(**) should go away when we have minions as proxies

[aaannz]

One thing; retail as a solution can have two network topologies. One specified in PR (machine with dedicated network interface for internal network) and one where there is only one NIC.

Example:

WAN <----> [ROUTER] --+-----------+------------+------------+--
                      |           |            |            |
                   [BRANCH]  [TERMINAL1]  [TERMINAL2]  [TERMINAL3]  ...

That's why I am not so sure about naming this toggle retail. I would prefer something descriptive i.e. dedicated_network or internal_net or similar.

[aaannz]

Still, even in "retail-only" module there are two options for network - one separate and one to leave it as is, but setup libvirt dhcp to use next-server and dns from branch.

The thing is that I thought for years that having dedicated internal network was how the retail solution was used. This kickoff I learned from Jeff that it is not the case and instead this shared network is used in majority.

[Bischoff]

In the context of this PR, there are 3 things:
1 - "variable geometry" bits - needed in all the cases to make retail tests optional. It could be controlled by a retail flag.
2 - a special network setup, that I need if I want to test in place the branch network, DHCP, and DNS formulas. It could be controlled by a second flag, for example branch_network.
3 - hacks, that are temporary only ; some will go away when Retail team's work is merged, and the others will go when we have the "proxy as minion" functionality. For the sake of simplicity, these hacks should also be controlled by retail flag.

As Ondrej pointed out, Retail can be tested in a second network setup, where the formulas are not used because DHCP and DNS are on a separated box (the so-called "router"). This is not covered in this PR, but if it is needed, I could add it without too much effort. I'm not sure though this would bring much to the testing side of things...

To sum up the needed flags:

• retail : variable geometry bits, temporary hacks
• branch_network : a special network including the clients and the branch server
• a third flag that would control whether the branch server is also a router / dhcp / dns box or whether those functionalities are external.

I have to check, but the retail flag is probably not needed in base module, while the other one probably needs to be there.

Does that make sense to you, @aaannz ? @moio ?

[moio]

I suggest renaming the retail variable in base as additional_network and its output variable additional_network_id.

It would be cool if it also had additional_network_name/additional_network_bridge/additional_network_mac to have the same expressing power of the primary network, but this is only "nice to have" - I am fine with anything that makes testing retail scenarios possible.

What will be needed is OpenStack support as this is not a libvirt exclusive. I can offer to help testing.

Thank you very much

[MalloZup]

looks good to me

[Bischoff]

Current status: I have divided retail variable into 3 variables into 3 different modules:

• private_network (base): use a private network?
• retail_repo (server): install Retail team repository and packages? temporary
• retail (controller): should we run SUSE Manager for Retail tests?

retail_network_id was renamed to private_network_id.

What is missing:

• support in cloud
• possibility to have the private network not configured via formulas

[MalloZup]

@Bischoff for retail_repo i would not create a variable but use the built-in:
https://github.com/moio/sumaform/blob/master/README_ADVANCED.md#add-custom-repos-and-packages

(this is more flexible then adding new temp variable)

for :

• retail (controller): should we run SUSE Manager for Retail tests?

My opinion is that we can have a mechanism for disabling Retail tests but imho we should run them together with the HEAD testsuite.

If we have 2 differents testsuite to me is hardware/resource waste and also people are struggling revieing 1 head, imagine to have 2 differents stuff. ( this is the same pattern we had seen with SLE15 tests, which went not well)

For the rest ok

[Bischoff]

@Bischoff for retail_repo i would not create a variable but use the built-in:

yes, good idea.

retail (controller): should we run SUSE Manager for Retail tests?
My opinion is that we can have a mechanism for disabling Retail tests but imho we should run them together
with the HEAD testsuite.

It was the plan....

Well, not immediately in HEAD, but in 3.2, and once it works in 3.2, in HEAD too. Why so? Because Retail is a 3.2 MU in the first place.

If we have 2 differents testsuite to me is hardware/resource waste

I never wanted to do that 😋 .

[moio]

Feel free to merge, small fixups might come later.

Thanks for all the work here

[moio]

Would it make sense to name this resource additional_network for consistency?

[Bischoff]

OK, will do.

[Bischoff]

Ok, I'm convinced by @MalloZup, let's remove retail variable completly and have only one test suite.
However, I will need not to merge the new testsuite features now as they would be too red. But waiting is enough, we don't need a flag.

To answer @moio's comment, for the moment there is no additional_network_name : the name is currently derived from prefix and private, eg ebi3-private, we could change that. The additional network in Retail context cannot be bridged to the outside. I don't see well why we would need to specify a MAC.

If or when we add the possibility to externally set the additional network, we will have to be creative for a new variable.

[Bischoff]

@mbologna the retail repos are installed on the minions too because of Kiwi packages. What about moving this hack out of sumaform as well and into the main.tf files with @MalloZup's trick?

(since I have everything ready, I can do it for you).

[mbologna]

@mbologna the retail repos are installed on the minions too because of Kiwi packages. What about moving this hack out of sumaform as well and into the main.tf files with @MalloZup's trick?

(since I have everything ready, I can do it for you).

I agree with moving this HACK into main.tf but please remember that it's temporary and it will be removed as soon as the FATE entry linked will be closed.
Thanks for taking care of that

[Bischoff]

I agree with moving this HACK into main.tf but please remember that it's temporary
and it will be removed as soon as the FATE entry linked will be closed.

Of course. My hack too is temporary.

Thanks for taking care of that

No worries, while I'm at it...

[mbologna]

My advice is: if you don't need to invest too much time in it && you like more having this HACK in main.tf, then yes, go ahead.

[MalloZup]

i have seen temporary hack for 10 years 👍 🤣

[Bischoff]

Temporary hack removed, merging.