Re: adding suport for additional backend
by Till Maas
Hi Ruben,
it's great to see interest in nmstate. Hope you don't mind me asking.
How did you learn about Nmstate? How are you planning to use it?
Thanks
Till
--
Till Maas
He/His/Him
Associate Manager, Software Engineering
NetworkManager, Nmstate, Ansible RHEL Networking System Role
Red Hat GmbH, https://de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
2 years, 5 months
Re: adding suport for additional backend
by Gris Ge
On Mon, Aug 31, 2020 at 04:37:24PM +0000, Ruben Torrero Marijnissen wrote:
> Hi,
>
> I'm looking into the possibility of adding support for an additional
> backend (wicked) inside nmstate. What would be a good starting point?
> what things should I keep in mind when doing so? What would be the
> requirements that would have to be met to send a PR with chances of it
> being accepted?
Hi Ruben Torrero Marijnissen,
Nmstate now provides plugin support, you may refer to
`libnmstate/plugins/nmstate_plugin_ovsdb.py` as an example plugin.
Currently, we are moving to nispor(via netlink) for querying kernel
network state, so your plugin will only have to apply the config and
some user space only state(e.g. OVS, DHCP status).
For accepting a PR, these are required besides maintainer approval:
* License LGPL 2.1+
* CI pass.
* New code has test cases covered.
Besides that, we can discuss the detail in github PR.
> Any suggestion is appreciated as well as pointing me in the right
> direction to find more documentation is appreciated (I'm already going
> through the contents of nmstate.io)
I will draft out an document for `Nmstate Plugin Developer Guide`
for this use case before end of this week.
I am in freenode IRC #nmstate channel as Gris, ping me if you need any
help on this.
Best regards!
--
Gris Ge
2 years, 5 months
[RFE] Using inclusive language in API/Schema
by Gris Ge
Hi,
I would like to suggest we deprecate our use of `master/slave` in
nmstate project.
And switching to these terminologies for interface relationship in
the coming new release of nmstate-0.4.0:
* For bond/team/bridge:
* controller/subordinate
# For bridge, we can also use controller/port.
* For VLAN/VxLAN:
* parent/child
* base/child
# Current API using `base-iface`, no need to change
For example:
* The `controller` of eth1 is bond0 and `controller_type` is bond
* The br0 is `controller` of eth1
* The eth1 is `port` of bridge br0 or `subordinate` of bridge br0
* The eth1 is `subordinate` of bond0
* The VLAN eth1.100 is child of eth1
* The base interface of eth1.100 is eth1
* The parent of VLAN eth1.100 is eth1
* The VLAN eth1.100 is child of eth1
I am not English native speaker, please kindly help on this if you have
better ideas.
Thank you very much!
Best regards!
--
Gris Ge
2 years, 6 months