Re: [systemd-devel] [RFC][PATCH] conf-parser: distinguish between multiple sections with the same name
On Thu, 21.11.13 02:27, Tom Gundersen (t...@jklm.no) wrote: Maybe then back to labelled sections: [Address:foobar] Label=waldo Address=1.1.1.1 or so, so that the suffix foobar is purely an id that is by default disconnected from any setting? And then maybe optionally inherit it into Label= if Label= is not explicitly set? I think the section name should not have any other function/meaning. I first tried to make 'section name'='Label', but I'm worried it might be confusing: If section names are required, it means we now require labeling, or force the admin to set Label= to disable it, which seems a bit weird. It hink that would actually be OK. Doing something useful without explicit configuration sounds like a good approach. Inheriting the Label= from the section name if no explicit Label= is specified sounds quite OK to me... Also, I find it asymmetric the way section names for Addresses have this extra meaning, but for Routes or other types of sections where there is no natural equivalent to Label=, they have no meaning apart from a name. Well, we wouldn't really bind the section name only and exclusively to the label. It's just that when fields are not explicitly set they might inherit the section name, in some field-specific way. For Label= it would be quiet obvious, but for other things this might work too. For example, for the ipv6 tunnel stuff we could inherit the section name into the tunnel iface name or so, whatever comes up... I'm really not convinced one way or the other, but I think my preferred solution is: go with unnamed sections now, and if ever it becomes necessary, introduce named ones additionally. Sounds OK. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] conf-parser: distinguish between multiple sections with the same name
Am 20.11.2013 14:38, schrieb Tom Gundersen: Pass on the line on which a section was decleared to the parsers, so they can distinguish between multiple sections (if they chose to). Currently no parsers take advantage of this, but a follow-up patch will do that to distinguish [Address] Address=192.168.0.1/24 Label=one [Address] Address=192.168.0.2/24 Label=two from [Address] Address=192.168.0.1/24 Label=one Address=192.168.0.2/24 Label=two This is a bad idea. When we have a config file [Section] Foo=bar [Section] Foo=baz and have a corresponding .d snippet with [Section] Foo=bay what does this mean? Does it override the value of the first section, the second section or does it create a new section? signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] conf-parser: distinguish between multiple sections with the same name
On Wed, Nov 20, 2013 at 2:57 PM, Thomas Bächler tho...@archlinux.org wrote: Am 20.11.2013 14:38, schrieb Tom Gundersen: Pass on the line on which a section was decleared to the parsers, so they can distinguish between multiple sections (if they chose to). Currently no parsers take advantage of this, but a follow-up patch will do that to distinguish [Address] Address=192.168.0.1/24 Label=one [Address] Address=192.168.0.2/24 Label=two from [Address] Address=192.168.0.1/24 Label=one Address=192.168.0.2/24 Label=two This is a bad idea. When we have a config file [Section] Foo=bar [Section] Foo=baz and have a corresponding .d snippet with [Section] Foo=bay what does this mean? Does it override the value of the first section, the second section or does it create a new section? Yeah, in this case it would not make sense. However, this stuff is opt-in only, and unit files don't opt-in (currently nothing does). For the use-case I have in mind we won't allow partial overrides and probably not even drop-ins/includes. -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] conf-parser: distinguish between multiple sections with the same name
Am 20.11.2013 15:02, schrieb Tom Gundersen: what does this mean? Does it override the value of the first section, the second section or does it create a new section? Yeah, in this case it would not make sense. However, this stuff is opt-in only, and unit files don't opt-in (currently nothing does). For the use-case I have in mind we won't allow partial overrides and probably not even drop-ins/includes. So, we'd have inconsistent config file syntax across systemd? Some section types override/extend when we write them more than once, some section types create new instances? I like the idea of assigning unique names to section instances much more. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] conf-parser: distinguish between multiple sections with the same name
On Wed, Nov 20, 2013 at 3:05 PM, Thomas Bächler tho...@archlinux.org wrote: Am 20.11.2013 15:02, schrieb Tom Gundersen: what does this mean? Does it override the value of the first section, the second section or does it create a new section? Yeah, in this case it would not make sense. However, this stuff is opt-in only, and unit files don't opt-in (currently nothing does). For the use-case I have in mind we won't allow partial overrides and probably not even drop-ins/includes. So, we'd have inconsistent config file syntax across systemd? Some section types override/extend when we write them more than once, some section types create new instances? We have contradicting domain specific stuff and rules everywhere. The network files are a stream of files to read and stop at the first match, file names do not matter at all besides the ordering of apply. With unit files we have one set of keys, the file name is the key to lookup the entire set and the drop-ins. Drop-in for a flow of unnamed files make not much sense, I think. I like the idea of assigning unique names to section instances much more. We could still support/allow them to be named, but not sure why we would need to require them. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] conf-parser: distinguish between multiple sections with the same name
On Wed, 20.11.13 14:38, Tom Gundersen (t...@jklm.no) wrote: Pass on the line on which a section was decleared to the parsers, so they can distinguish between multiple sections (if they chose to). Currently no parsers take advantage of this, but a follow-up patch will do that to distinguish [Address] Address=192.168.0.1/24 Label=one [Address] Address=192.168.0.2/24 Label=two from [Address] Address=192.168.0.1/24 Label=one Address=192.168.0.2/24 Label=two I do like this solution better, but I can see Thomas' point. And the issue Thomas points out manifests itself in handling of .d/ directories... If we want to support .d/ directories for these configuration files (do we?) then how can we extend the settings of a specific existing [Address] section? So I do prefer the linear version above, but I see a problem with it... Hmm, what other options do we have? We could number things: [Address.0] ... [Address.1] ... [Address.2] ... and so on. I kinda like that too, but numbers might suck as ids? Maybe then back to labelled sections: [Address:foobar] Label=waldo Address=1.1.1.1 or so, so that the suffix foobar is purely an id that is by default disconnected from any setting? And then maybe optionally inherit it into Label= if Label= is not explicitly set? Other ideas? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] conf-parser: distinguish between multiple sections with the same name
On Wed, Nov 20, 2013 at 10:37 PM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 20.11.13 14:38, Tom Gundersen (t...@jklm.no) wrote: Pass on the line on which a section was decleared to the parsers, so they can distinguish between multiple sections (if they chose to). Currently no parsers take advantage of this, but a follow-up patch will do that to distinguish [Address] Address=192.168.0.1/24 Label=one [Address] Address=192.168.0.2/24 Label=two from [Address] Address=192.168.0.1/24 Label=one Address=192.168.0.2/24 Label=two I do like this solution better, but I can see Thomas' point. And the issue Thomas points out manifests itself in handling of .d/ directories... If we want to support .d/ directories for these configuration files (do we?) then how can we extend the settings of a specific existing [Address] section? My take was that we do not want to support .d/ directories, in which case unnamed sections would be fine, right? (i.e., as long as we only ever consider one file at a time). Essentially I think it would be ok to just tell people to copy the .network file to /etc and edit it there. If, on the other hand, we do want to allow .d/ directories in the future, I think I'd advocate allowing both named and unnamed sections (where only the named ones can be overridden of course). Notice that we already encounter a similar overriding issue with the plain Address= and Gateway= entries from the [Network] section, which can not be accessed individually from .d/ fragments (but possibly cleared altogether, as we allow in similar situations elsewhere). I guess the normal use-case would then be that .nework files created by admins would mostly (only) use the unnamed sections, as it is simpler/neater and won't be something you'd ever override, but stuff shipped by packages could use the named sections where overriding might possibly make sense. So I do prefer the linear version above, but I see a problem with it... Hmm, what other options do we have? We could number things: [Address.0] ... [Address.1] ... [Address.2] ... and so on. I kinda like that too, but numbers might suck as ids? Yes, I guess for someone writing the .d/ fragment it is annoying to have to remember the number. So for something we expect could be overridden, descriptive names would be best. Maybe then back to labelled sections: [Address:foobar] Label=waldo Address=1.1.1.1 or so, so that the suffix foobar is purely an id that is by default disconnected from any setting? And then maybe optionally inherit it into Label= if Label= is not explicitly set? I think the section name should not have any other function/meaning. I first tried to make 'section name'='Label', but I'm worried it might be confusing: If section names are required, it means we now require labeling, or force the admin to set Label= to disable it, which seems a bit weird. Also, I find it asymmetric the way section names for Addresses have this extra meaning, but for Routes or other types of sections where there is no natural equivalent to Label=, they have no meaning apart from a name. I'm really not convinced one way or the other, but I think my preferred solution is: go with unnamed sections now, and if ever it becomes necessary, introduce named ones additionally. If we end up adding named sections, I do see the possible confusion of oh, I have to name these before I can override them...?. But if we force always to name them I see people using 'random' strings foo, bar, baz, rtyrty, tryytr, and at some point getting lost in what strings they have used and accidentally reusing strings (of course the clever person would in this case name the sections 1, 2, 3, etc). Basically, my concern is that there is not a big step from requiring the user to invent unique strings to requiring UUID's... -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] conf-parser: distinguish between multiple sections with the same name
On Thu, Nov 21, 2013 at 02:27:28AM +0100, Tom Gundersen wrote: On Wed, Nov 20, 2013 at 10:37 PM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 20.11.13 14:38, Tom Gundersen (t...@jklm.no) wrote: Pass on the line on which a section was decleared to the parsers, so they can distinguish between multiple sections (if they chose to). Currently no parsers take advantage of this, but a follow-up patch will do that to distinguish [Address] Address=192.168.0.1/24 Label=one [Address] Address=192.168.0.2/24 Label=two from [Address] Address=192.168.0.1/24 Label=one Address=192.168.0.2/24 Label=two I do like this solution better, but I can see Thomas' point. And the issue Thomas points out manifests itself in handling of .d/ directories... If we want to support .d/ directories for these configuration files (do we?) then how can we extend the settings of a specific existing [Address] section? My take was that we do not want to support .d/ directories, udev supports overrides, tmpfiles support them too, so do systemd units, and sysctl settings. I'm pretty sure we can assume that overrides for network files will happen sooner or later. Also, it's not just /etc/... overriddes, but also /run/... overrides, for until-reboot settings. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] conf-parser: distinguish between multiple sections with the same name
On Thu, Nov 21, 2013 at 2:39 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Thu, Nov 21, 2013 at 02:27:28AM +0100, Tom Gundersen wrote: On Wed, Nov 20, 2013 at 10:37 PM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 20.11.13 14:38, Tom Gundersen (t...@jklm.no) wrote: Pass on the line on which a section was decleared to the parsers, so they can distinguish between multiple sections (if they chose to). Currently no parsers take advantage of this, but a follow-up patch will do that to distinguish [Address] Address=192.168.0.1/24 Label=one [Address] Address=192.168.0.2/24 Label=two from [Address] Address=192.168.0.1/24 Label=one Address=192.168.0.2/24 Label=two I do like this solution better, but I can see Thomas' point. And the issue Thomas points out manifests itself in handling of .d/ directories... If we want to support .d/ directories for these configuration files (do we?) then how can we extend the settings of a specific existing [Address] section? My take was that we do not want to support .d/ directories, udev supports overrides, tmpfiles support them too, so do systemd units, and sysctl settings. I'm pretty sure we can assume that overrides for network files will happen sooner or later. Also, it's not just /etc/... overriddes, but also /run/... overrides, for until-reboot settings. Nah, this is only about fragment drop-ins, they are only supported by unit files. The network files surely support individual files in a directory, but not fragments to overwrite parts of a file. As mentioned earlier, network files are like udev rules, the file name is meaningless, so .d/ fragment drop-ins make not much sense here. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] conf-parser: distinguish between multiple sections with the same name
Just to suggest the wildly different approach I mentioned on IRC, we could treat addresses (including DHCP) as the main units and then specify the backing hardware as part of the address's configuration. This would be particularly useful for bridges. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] conf-parser: distinguish between multiple sections with the same name
On Thu, Nov 21, 2013 at 11:48 AM, David Timothy Strauss da...@davidstrauss.net wrote: This would be particularly useful for bridges. Actually, I meant bonded interfaces, not bridges. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
