Sat, Feb 27, 2016 at 12:59:26PM IST, jiri(a)resnulli.us wrote:
Thu, Feb 25, 2016 at 11:46:51AM CET, jprochaz(a)redhat.com wrote:
>Hello,
>this mail is status update on PyRecipes. I'm sorry there is no visible
>progress yet, but it's because I was considering several different formats
>and tried to satisfy both parties, which won't be probably possible.
>
>Current use cases of LNST (RedHat vs Mellanox)
>==============================================
>Currently, we have both sides, each with their own use case scenarios. Red
>Hat is using LNST for performance regression testing, along with PerfRepo.
>Each test uses same tools (ethtool, netperf, ping). The setups are very
>similar, as for hosts and eth ifaces, what is changing is soft interface
>setup (bond, team, VLAN, ovs, bridge). Setup of soft interfaces is
>currently done via XML and in task is only execution of test tools and
>additional setup (ethtool, MTU). Currently, the code is duplicated in every
>task (perfrepo methods, ethtool setups, mtu setups, netperf inits and
>calls) so a new layer of abstraction would be welcomed in order to simplify
>the code and maintainability.
>
>As for Mellanox side, I can only speak about what I can see in switchdev
>recipes. Their approach is to define only hardware interfaces in XML and do
>all soft interface setting in the task. In order to create an abstraction
>layer a TestLib was created, which looks really appealing to me.
All our (Mellanox) recipes are in lnst git. So you can see everything.
>
>What do RH/Mellanox expect from PyRecipes
>=========================================
>We had a video call in January about PyRecipes with olichtne (RH) and
>jpirko (Mellanox). Both sides had different view of PyRecipes.
>
>Red Hat POW
>-----------
>1. Wants to be able to define soft and hard interfaces together in setup
>2. Wants to be able to combine network setup with different tasks
>3. Task should be understood as a function, with network as argument
>4. Task should be generic
>
>Mellanox POW
>------------
>1. Wants to get rid of ID's (hosts and interfaces)
>2. Wants soft iface definition only in task, not in setup
>3. Task should be specific
>4. Wrappers for generic stuff
>5. 1 task == 1 test == 1 file, do not combine it
>
>Proposed approach #1 (Mlx like)
>===============================
>Description: Setup and task is in one file, no IDs are used, soft interface
>definition is part of task
>
>Example:
>import lnst
>
>m1 = lnst.add_host()
>m2 = lnst.add_host()
>
>m1_eth1 = m1.add_interface(label="tnet")
>m1_eth2 = m1.add_interface(label="tnet")
>
>m2_eth1 = m2.add_interface(label="tnet")
>
>while match(match=lnst.SingleMatch):
> m1_team = m1.create_team([m1_eth1, m1_eth2], ip="1.2.3.4/24")
> m2_eth1.reset(["1.2.3.5/24"])
>
> ping_mod = ...
> m1_team.run(ping_mod)
>
>Proposed approach #2 (RH like)
>==============================
>Description: Soft interfaces can be defined in both setup() and task()
>methods. IDs muset used due to different scopes of variables. Setup can be
>in separate file and can be imported in multiple tasks. In one file,
>multiple tasks can be called.
>
>Example:
>import lnst
>
>def setup():
> m1 = lnst.add_host("m1")
> m2 = lnst.add_host("m2")
>
> m1_eth1 = m1.add_interface(id="eth1", label="tnet")
> m1_eth2 = m1.add_interface(id="eth2", label="tnet")
>
> m2_eth1 = m2.add_interface(id="eth1", label="tnet",
ip="1.1.1.1/24")
>
> m1.create_team(id="team1", slaves=[m1_eth1, m1_eth2],
ip="1.1.1.2/24")
>
>def task():
> m1 = lnst.get_host("m1")
> m2 = lnst.get_host("m2")
>
> m1_team = m1.get_interface("team1")
>
> m2_eth1 = m2.get_interface("eth1")
>
> ping_mod = ...
> m1_team.run(ping_mod)
>
>lnst.run(match=lnst.SingleMatch,
> setup,
> task)
>
>Proposed approach #3 (RH like)
>==============================
>Description: Task method is portable, it uses machine and interface objects
>as args so no IDs are required. Soft interfaces can be created in both
>do_task and in setup phase. In one file, multiple tasks can be called.
>
>Example:
>import lnst
>
>def do_task(m1, if1, if2):
> ping_mod = ...src=if1, dst=if2...
> m1.run(ping_mod)
>
>m1 = lnst.add_machine()
>m2 = lnst.add_machine()
>
>m1_eth1 = m1.add_interface(label="tnet")
>m1_eth2 = m1.add_interface(label="tnet")
>m1_team = m1.create_team(slaves=[m1_eth1, m1_eth2], ip="1.1.1.1/24")
>
>m2_eth1 = m2.add_interface(label="tnet", ip="1.1.1.2/24")
>
>while lnst.match(match=lnst.SingleMatch):
> do_task(m1, m1_team, m2_eth1)
This is the same as #1, only with possibility to create soft devices in
setup phase. I personally don't mind much is the api would be the same
for soft device manipulation in setup phase and task phase.
OK, so it seems like #1 would be the most flexible and can accommodate
everyone's needs.
But, I believe that it would be very complicated to implement. Also,
some runtime methods of the soft device object would be possible to call
only in tasks and in setup phase the soft device does not exist yet.
Confusing as hell. And what is the gain? Nothing. You can easily change
soft device creation to tasks. Some helper function to do if before you
call your actual function that runs tests. Lets not complicate things.
With approach:
1 define hw ifaces
2 do match
3 run task - create soft ifaces, manipulate configuration, run tests
you can easily achieve whatever you need. I don't understand why you still
persist possibility to create soft devices in phase 1. That simply does
not make sense.
>
>Summary
>=======
>Drafts above are not meant to be final, it sure can be improved and
>modified to satisfy our needs. But we need to come to conclusion for both
>Mlx and RH side, so I can start working on it.
>
>Some important questions regarding PyRecipes:
>---------------------------------------------
>I. Soft interfaces - in setup phase and task phase or only in task phase?
As I wrote above, only in task. It is completely pointless to do it in
setup phase.
>II. Portability - one task == one recipe, or allow combinations of networks
>with different tasks?
One task=one recipe. You can easily use some lib that will do the common
things for you. Exactly as we do it in switchdev recipes. It's a python,
the task here is just an entry point. You can do whatever from that.
>III. Should task be generic or specific?
As I wrote above, you can easily split this in:
1 specific wrapper
2 lib methods - called by specific wrapper
>IV. Do we have to get rid of IDs?
YES! No reason for them what so ever.
+1