Olaf,
With much respect, yes, the presentation missed a lot of targets
and stirred up the natives. I understand that, having done my share of
these things. What we are doing now in this follow up thread is bringing
to light the better parts of this, with more context.
On the current if* scripts. Indeed, the scheme has grown into a
byzantine collection of apps, poorly documented and with horrid command
line syntax. We agree that this area could be done vastly better. We
aren't there yet, the travel arrangements and what the destination looks
like are not known to us in the field. My hope is this will be another
solidly engineered SUSE project, as many are.
In the meanwhile we have servers to keep running and future side effects
to consider. Those scripts keep us going. That is why I commented that
the heavy development should be a parallel effort until it is ready to
assume active duty.
Mere managers rightly ask what is that new approach doing to my
gear, and can I cope with it (whatever presently nebulous "it" may
mean). There needs to be a smooth transition, with suitable warm fuzzies.
The XML stuff illustrates an aspect which we tend to lose sight of
while pounding keys. It is the user side of the work. We know that XML
is By Computers For Computers, not for people. And we know that people
have to control things (else we are doomed). In the end people ought to
be the winners. Thus a small amount of computer science is needed to
keep things people friendly yet expressive enough for technical nuances.
Lists are no problem, standard stuff. Categories are not much of a
problem either, as we can see in zillions of configuration files on our
machines. Handling this well is an integral part of the design process,
not much fun but really necessary.
On the current networking problems. I will accept your comments
that wicked is not the guilty party. Good.
Once again, I am much in favour of such creative work. We need to
manage it well.
A couple of quick comments are in-line below.
Thanks,
Joe D.
On 25/03/2014 10:42, Olaf Kirch wrote:
> 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?
A YaST and /etc/sysconfig option
> ... set up an interface for DHCPv4 and DHCPv6?
A Yast, /etc/sysconfig/network ifcfg-X, and in some cases
ifconfig options
> ... change the link speed on an Ethernet interface?
IP, horrid syntax and worse man page not withstanding.
> ... 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.
Yes, you have good points in the latter half of the list. What's
missing is presentation to the sysadmin. YaST is a highly useful tool,
see and change. The above list items are handled today, not slickly but
using known methods.
>
>> 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