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. 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. > 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. > 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. 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
