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

[Joe Doupnik]

     Good, I think a little sorting is occurring.
     The subject yesterday was networking, where the focus was on 
wicked. My comments are on networking, and the unknown role which wicked 
may or may not play in them. I did ask just what does wicked do, a 
matter not really addressed in yesterday's presentation. I asked about 
the effects of it on systems which do not involve complicated 
networking. And similar queries. Hopefully these matters will be 
documented in due course. Further, I am pleased to see creative projects 
in this and related areas, keeping in mind that our production systems 
are not the proving ground.
     I will add that my impression of the wicked management is of 
concern, particularly the heavy emphasis on dbus traffic (yet another 
congestion/failure point). That's a technical nuance, judged from afar. 
I know, I can hear the reply, "How else can the management system learn 
about events." The kernel knows is one reply. The concern includes human 
vs machine where the machine thinks it knows better. Creating an 
understandable network management console (or equivalent) would be 
really interesting, but there is yet little evidence of that in wicked. 
I hope the team can make it happen. As stated, it might be best as a 
product in its own right.
     The problems mentioned below are real enough, but the cause of the 
wireshark part remains to be determined. More testing here might help, 
and your observation that packet captures work at your end is encouraging.
     Thanks,
     Joe D.

On 25/03/2014 09:27, Thorsten Kukuk wrote:
> Hi,
>
> On Tue, Mar 25, Joe Doupnik wrote:
>
>>      The difficulties to which I refer below are two: the discussed
>> interface naming and associated ifcfg-X contents,
> Ok, the interface naming is a real problem, but it has nothing to do
> with wicked. That's systemd/udev/biosdevname and whatever else thinks
> it has to play around with this names. wicked does not care about how
> the interface is named.
>
>> and then yesterday the
>> peculiar problem of wireshark seeing no packets. The latter suggests wicked
>> derived apparatus is not yet ready for packet captures.
> Sorry, but packet captures have nothing to do with wicked, too, but
> with the kernel driver.
> wireshark is working fine for me on all of my SLES12 test systems.
>
> About xinetd and vsftpd: this looks like a xinetd problem, vsftpd does
> work fine standalone. Not wicked, too.
>
>>      As for shell scripts, they at least work and are well proven in the
>> field.
> Until you want to bring up a bridge in a running system for
> virtualisation guests, etc...
>
>> Wicked exchanges them for its own scripts. So I think this is not a
>> good argument on either side of the problem.
>>      What counts is the apparatus works as intended, is understood by owners
>> and not least how it interfaces with human managers.
> And from your problems I would say: wicked just works.
> What I already assumed: you don't have a problem with wicked,
> but with bugs in other code completly unrelated to wicked.
> That's at bad, too, but dropping wicked will not solve any of
> your above problems. It's like with a car: if your tires are
> flat, exchanging the motor engine will not fix it.
>
> Instead we need to look at every single issue, debug and fix it.
>
>    Thorsten
>