[sles-beta] Comments on wicked in today's presentations

[Olaf Kirch]

Hello Joe,

On Monday 24 March 2014 18:50:16 Joe Doupnik wrote:
>      If I may, this is a better place to make some comments on the
> interesting presentation about wicked today. I will be critical, but in
> a sympathetic way.
>      To start with the bottom line as I see things at this time. This is
> an experiment which ought to appear in production a year from now. The
> attempt seems to be to invent a robot which somehow magically makes all
> that "complicated" networking gear disappear behind a on/off switch plus
> a green/red light.

Well, apparently I did a very bad job at describing the intention of this
new development.

(1) We did this because the complexity of the ifup/ifdown script melange
	was beyond the breaking point. Honestly, trying to extend what we
	have has driven developers up the wall :)

	And we did extend this framework a lot - I tried to give a first
	order approximatin with my slides, but maybe that was too visual
	an attempt... but if you look past traditional IPv4 networking,
	there's a huge set of changes around DCB, FCoE support, iBFT, IPv6,
	bonding and bridging, virtualization related stuff etc, all of which
	went in over the past couple of years.

	And more is in the pipeline - I'm sure we haven't seen the last
	IPv6 tunneling technologies; there's NIC teaming support that's being
	requested, and so on. And remember, this product is going to be in
	the market for a long time. So the last thing we want to do is keep
	gluing more bits and pieces to something that showing structural
	strains already today.

(2)	This is not about dumbing down anything. It's not about making
	complicated stuff disappear - it's about making complex stuff
	available to the admin in a useful way.

	Can you, or anyone else on the list, tell me off the top of your head
	(and without going back through lots of READMEs) how to do all of
	the following:

	... disable IPv6 on a specific interface?
	... set up an interface for DHCPv4 and DHCPv6?
	... change the link speed on an Ethernet interface?
	... reconfigure a bonding device without bringing it down?
	... set up a bridge on top of a bond
	... change the firewall rules on your UMTS modem?
	... set up 802.1x authentication for your Ethernet NIC?
	... set up persistent names for your System z devices?
	... disable segmentation offloading on your Ethernet NIC?

	There are knobs and tunables for all of these things. Right now,
	they're not available to the admin (short of messing with
	rc.local scripts), or if they are, they need some non-intuitive
	syntax.

Our goal with wicked would be to offer as many of these through one
consistent configuration file format.

> That is an interesting goal, speaking
> sympathetically, but first one ought to sort things into simple
> arrangements so that people can easily cope with it.

Correct. And this is why, in SLE12, we started by replacing the old ifcfg
machinery, while still retaining the interfaces (read, the ifcfg files).
We're taking one step after the other, avoiding to change too many things
at once. As a consequence, wicked is currently not living up to the promise.
The best it can offer in GA is being as stable as its predecessor - but with
SP1, I would like us to move to the new config file format that actually
offers all the power of a unified API.

>      Our discussions on the list about lan device naming and similar
> reflect the realities we have in the field today, being very clear about
> This device does That thing in a form compatible with other parts of the
> system, as well as our need to see that information at it is preserved
> in configuration files. In other words, people are smarter than the
> robot and should win more than an average number of battles with such
> things. To couple the two requires much thinking about what displays and
> what controls each side should have.

Well, let's not confuse two things here - the naming issue has nothing,
absolutely nothing to do with the introduction of wicked. It's a separate
issue. (And I assume the wireshark problem seen recently is yet a different
topic).

One way to address it would be to reintroduce the old SLE11 code for device
renaming back to udev. So far, we're pretty reluctant to go there, beceause
it has a tendency to break once in a while because it's an inherently racy
operation, especially on machines with lots of NICs.

The other way is to try to get rid of a dependency on names as much as possible.
How many people actually did implement their own naming scheme? I think, most
everyone was happy that the system did offer naming persistence, but didn't
really care if NIC A was called eth0 or eth1, as long as that didn't change
over the life time of the system.

And I think that is the main point. Yes, I agree, en123456789 is neither
easy to remember nor easy to type, but can we agree that this is a secondary
issue (worth addressing, but maybe less pressing?)

>      Additional comments on XML files and similar. I am in the camp
> which says that is for computers to read and write, not for people. The
> current situation is one of creating name-value pairs, so far as I can
> surmise, not complicated hierarchical structures. Classical name-value
> files are for people as much as computers. They work well with people,
> and computers think they are trivial to parse. Thus, why complicate when
> it isn't necessary or desirable to do so.

Point taken. One remark on hierarchy though - that's something that will be
needed. If you think of IP addresses assigned to a NIC, you're talking
about lists, potentially. For routing, you're talking about lists as
well, and possibly even nested. All of that is currently flattened
artificially because of the very restricted syntax that the shell offers
(as in the case of IPADDR_* variables), or because of what we can parse
easily in a shell script (eg in the case of the ifcfg-routes file). But
I wouldn't go as far as establishing that as the gold standard worth
enshrining for eternity.

Regards,
Olaf
-- 
Neo didn't bring down the Matrix. SOA did. (soafacts.com)
--------------------------------------------
Olaf Kirch - Director SUSE Linux Enterprise; R&D (okir at suse.com)
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)