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

[Joe Doupnik]

     Adding a few more words to my message.
     As I mull what was shown to us today the more it seems that wicked 
should be a nearly independent product which could be added to SLES upon 
need. Many servers need simple steady connections, static, some bonded 
many not. There are some sites which have fluid environments where hot 
plugging and whatnot occur all the time, heaven help them, and elaborate 
network management software would be a great blessing. The latter need 
such a product, the former don't and can be spared the complexity.
      Further on what we know so far. Just what are those problems which 
need solving (my place may not face them), and how would wicked go about 
solving them? I dunno. What does wicked do today in Beta 3? I really 
don't know, but its presence might contribute to our current problems. 
Do I need to take a training course to keep my Ethernet adapter and 
IPtables script working? I hope not, travel costs being what they are 
today, but the signs are not favourable. Should I pay attention to the 
alphabet soup being offered today? No, thanks anyway, I know protocols 
and prefer plain tomato soup (aka IP v4, static addresses, eth0 style). 
The soup offering is really a layer cake plus side dishes plus coffee 
all on one trolley.
     I wish the development team much luck in building the wicked tool 
set. I would love to help but I lack the environment in which do test 
such things. In a year's time the problem set ought to become well 
defined, the results should be understandable by mere mortals, the 
benefits be clear and appealing to those with the needs, and hopefully 
SUSE would make a bundle of money from the effort.
     Joe D.


On 24/03/2014 17:50, 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. 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. Use of the term 
> "complicated" implies, to me, incomplete understanding and that is not 
> a proper state for production tools. I am a scientist and I recognise 
> partly formed ideas when they appear. Wicked does seem to be in that 
> category presently, too early to judge for possible merits but 
> appealing in its promise.
>     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.
>     To be fair, I am very cautious about critiquing ambitious projects 
> by SUSE because in the end they often turn out to be very clever work. 
> An example is snapper, another is zypper, and not least YaST itself. 
> Wicked may be, in time. Between that happy end state and now reside 
> our servers and our managers, and they are becoming subjects of an 
> experiment in progress. OpenSUSE is a normal proving ground for such 
> efforts.
>     Consequently, my feeling is we need to retain the clarity and 
> simplicity of what we have with ifconfig and relatives, let wicked 
> grow to maturity and prove its value to our situations, and then 
> create a smooth bridge between these worlds. What it is, what it ought 
> to do, how one transitions from A to B, and where people fit into the 
> scheme are still not well defined, not to me as an end user.
>
>     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.
>
>     Thanks,
>     Joe D.
> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta