<options> under <eth>

Jiri Pirko jpirko at redhat.com
Thu May 23 12:07:37 UTC 2013


Wed, May 22, 2013 at 03:50:43PM CEST, olichtne at redhat.com wrote:
>Hi everyone,
>
>while rewriting a team recipe to suit the new format I came across a
>problem. The old files contain <options> tags under the <eth> tags.
>
>For example the file recipes/team/netconfig-team_ab.xml contains the
>following:
><eth id="1" network="A">
>    <options>
>        <option name="teamd_port_config">
>            {
>                "prio": -10,
>                "sticky": true
>            }
>        </option>
>    </options>
></eth>
>
>This was previously possible because our parser accepted the <options> tag
>under any type of <interface> tag. However after the recent changes, to
>use the type of the interface as the name of the tag, we have agreed
>to only accept <params> and <addresses> tags for the <eth> tag. This is
>because lnst currently doesn't do any other sort of configuration than
>setting a network address, and params are used for machine matching.
>
>The <options> tag is only used in the case the interface is a slave to a
>team interface. The values that are being set are also directly related
>to the team driver. For this reason I suggest moving these <options>
>tags and placing them directly under the <slave> tag that binds the
><eth> interface to the <team> interface. The recipe would then look
>something like this:
>
><eth id="1" network="A"/>
><team id="testiface">
>    <options>
>        <option>...</option>
>    </options>
>    <slaves>
>        <slave id="1">
>            <options>
>                <option name="teamd_port_config">
>                    {
>                        "prio": -10,
>                        "sticky": true
>                    }
>                </option>
>            </options>
>        </slave>
>    </slaves>
>    <addresses>
>        <address>...</address>
>    </addresses>
></team>
>
>This would of course require bigger changes than just accepting the
><options> tag under the <eth> tag just as before, but not by much. This
>format, in my opinion, makes more sense.
>
>The usability of this format depends on what kind of options can team
>use here, and if this could be also used for other types of interfaces
>that have slaves.
>
>I would like to hear your oppinions on this.

Makes sense to me. Go for it.


>
>-Ondrej
>_______________________________________________
>LNST-developers mailing list
>LNST-developers at lists.fedorahosted.org
>https://lists.fedorahosted.org/mailman/listinfo/lnst-developers


More information about the LNST-developers mailing list