On Mon, 2012-09-03 at 09:44 +0200, Olaf Kirch wrote: > Hi Miloslav, > > On Wednesday 29 August 2012 18:42:44 Miloslav Trmač wrote: > > Considering that it's not reasonable to expect that the replacement > > will cover 100% of the previous functionality, the "old" and "new" > > projects will have to live side by side again for some time. So a > > switch to a different system needs to provide benefits that exceed the > > quite large costs of the migration. > > > > Therefore, in general, I'd assume that modifying NetworkManager (in a > > backward-compatible way) is probably an easier way to add features > > than replacing the whole subsystem with something else. > > Hm, I beg to differ here. NetworkManager aims at a relatively compact > DBus API that hides most of the complexities of the network stack. > That, I believe, is one of the major reasons why it hasn't caught on > much in an Enterprise world - there's always one little extra knob an > admin wants to twiddle. NM tries to hide things where it makes sense; there's a *lot* of stuff that is simply unnecessary for clients to care about while handling networking. But there's a lot of stuff administrators and clients also want to change, and we're moving pretty quickly in that direction already. There are a lot more knobs in NM than people realize. > By contrast, I think a good network management framework needs to > have a low entry barrier (in terms of writing configuration files) > but still expose as many of the tunables and knobs as possible. And that pretty much describes how NM works today too; it'll handle your existing network configuration, but still does expose a lot of tunables in the configuration. But you have to ask whether those knobs are actually required. Knobs fall into one of three classes: 1) useful ones, like IPv6 privacy settings, IPv6 on/off, etc 2) dubious ones, where the kernel or low-level implementation just tries to avoid hard choices and decides to give up 3) workarounds for broken hardware or kernel drivers We've tried really hard over the past 6 or so years to *not* expose knobs that allow people to work around broken kernel stuff or hardware, and instead *fix* the kernel to do the right thing instead of expecting users to know which knob to twiddle to get the right result. Examples of this include SSID scanning in wifi drivers and carrier detection capability in wired drivers. Nobody should ever have to know whether their driver supports a specific feature or not and then set some option because of that; instead we need to fix this sort of thing in the kernel and then handle it automatically. My point is, not all knobs are worth exposing, and some knobs shouldn't be exposed, but should get fixed so they don't need to be exposed in the first place. It's hard, but it makes life better. Next, you need to analyze *why* a particular knob is requested. Is there a better way to do that? I've often found people want a checkbox for this or that, when there's actually a much better way to fix the problem for the user. Sometimes there's not and you just add the knob. But often there is. Adding knobs left and right often (a) increases complexity and therefore confusion, and (b) creates code that's really hard to maintain and document. > > Now, with my once-upon-a-time sysadmin and initscripts comaintainer hat on: > > > > Yes, it is possible to design a better configuration format than the > > ifcfg files, but I'm not sure that this is a really pressing problem: > > the primary problem with networking is understanding the concepts and > > designing the desired state, not the configuration format - once you > > know what you want to do, you can always find the > > HOPELESSLY_UNINTUITIVE_OPTION_NAME (or even > > nicely-scoped/well-designed-option-name-that-you-need-to-write-precisely-co > > rrectly-to-the-letter) in documentation. > > Sure, I'm not talking about the syntax. As I said, I couldn't care > less if its XML or anything else. My point was that the shell variable > syntax is unable to express anything but the most basic concepts, > and hence our network management remains simplistic. It actually works pretty well for most things, we've found. We have gone through rounds of trying to figure out better formats, but it turns out that for the most part, the ifcfg format is: 1) widely used and thus well-understood 2) compatible with a huge number of existing tools 3) easily machine-parsible (except for embedding shell inside the variables, ie backticks or whatever) 4) simple and fairly flexible If you treat the file as a simple key/value file, and disallow using actual shell macros or expansion, then it's actually pretty suitable. And nothing else anyone has come up with is actually so much better that it's worth the cost to switch. I came up with the NetworkManager "keyfile" format, and it's not hugely better, just cross-platform. But ifcfg will live a long, long time. > > In addition to a different configuration format, having new features > > could be more attractive (e.g. the ability to replace a bonding slave > > without restarting the whole interface, or 802.1x support) - but > > because any of the implementations already cover the basic > > functionality reasonably well, the new attractive features would > > necessarily be something of a niche / not-that-frequently-used > > features. So, again, it seems reasonable to assume that the new > > features might not be attractive enough to trump the costs of the > > migration. > > Well, if you take each of these niche things by themselves, they > don't count for much. But they add up, and Cloud/Virtualization is > really adding a *lot* of complexity. netcf being a fine example of > the hoops you need to jump through in order to support the brave new > world of virtualization hosts. Yup, all the nice enterprise/virtualization stuff is actually extremely complicated, and I think we can do better than the hodgepodge of scripts that people currently use to handle things. But in the end, it doesn't really help anyone to have competing network management systems, lease of all users. I haven't seen a great case for one in preference to the other, or a great case against modifying one to pick up the advantages one has over the other. Dan > My point is that the current system has reach a breaking point. We've > piled brick on brick, and the stack is teetering dangerously :) > > And regarding your comment as to adding new features - that is > definitely in scope for wicked. It does already allow to change > the set of bonding slaves on the fly, and 802.1x support is on the > TODO list. > > Olaf > -- > Neo didn't bring down the Matrix. SOA did. (soafacts.com) > -------------------------------------------- > Olaf Kirch - Director SUSE Linux Enterprise; R&D (okir@xxxxxxxx) > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
