nmstate-devel September 2020

nmstate-devel@lists.fedorahosted.org

9 participants
3 discussions

Re: adding suport for additional backend
by Till Maas 16 Oct '20

16 Oct '20

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 1

Re: adding suport for additional backend
by Gris Ge 16 Oct '20

16 Oct '20

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

3 6

[RFE] Using inclusive language in API/Schema
by Gris Ge 05 Sep '20

05 Sep '20

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

11 40

2024

2023

2022

2021

2020

2019

nmstate-devel September 2020