-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/08/2010 08:44 AM, Dmitri Pal wrote: > Stephen Gallagher wrote: >> On 04/07/2010 08:10 PM, Dmitri Pal wrote: >>>> >>> Jeff, I value your input too. >>> But for me it is just a non starter even if it is generally a right >>> thing do in a long run. >>> I have some time to do some dev work on the project. >>> I can't commit myself to doing it if I do not see that I can actually do >>> it in >>> a reasonable amount of time. This is the constraint on my contributions >>> to the project. >> >>> But back to the technical part of the discussion. >>> Here is my thinking about the whole file editing situation. >>> The editing of the files is prohibited by the Fedora guidelines at the >>> install time. >>> But did I say anything about the install time? >> >>> Would it be fine if an admin comes and manually edits the file? >>> The answer is yes, this is what admins do. >>> It can be sssd.conf, pam.conf or any other file. They can edit it >>> (assuming they know what they are doing). >>> Ok but if I am a smart admin I will probably create a script to do so. >>> If I also have some sort of the central config management solution >>> I will create a puppet or cfengine module that would do this editing >>> centrally, right? Have I violated anything? Even if I did this is a >>> natural thing people do and if it is against any guidelines then the >>> guidelines >>> should be considered for a re-review. >> >>> So as a third party vendor (and I worked for one for 10 years) >>> I would just include a puppet module into my solution and say: >>> * Install this package >>> * Edit the files this way, here are the scripts an modules that would >>> help you >>> to do so. >>> And this would fly fine with everybody. >> >>> So the whole discussion boils down to making things work nicer together >>> and letting 3rd party vendors to do less work. >>> Since there are no third party vendors lined up for their life to be >>> made easier >>> I come to conclusion that the requirement can be deferred in the first >>> implementation of the INI validation library and can be added as we >>> get 3rd party vendors lined up to build the plugins. >> >>> I agree that there is no sense to continue this discussion. >> >> >> I disagree. >> >> Dmitri, you're missing a fundamental piece of information here. You're >> confusing "configuration files" with "data files". >> >> Configuration files, like the sssd.conf are files that it is expected >> that an admin will need to modify for their environment to function. The >> proper approach is to have configuration files handle values that will >> be site-specific. In RPM terminology, these are config files marked as >> noreplace (in other words, RPM upgrades won't overwrite local changes, >> they will simply drop sssd.conf.rpmnew in place, so an admin can >> manually merge differences if they are necessary, which in most cases >> they won't be). >> >> Data files, on the other hand, are files that by necessity MUST be the >> same for all deployments. A schema file is one such. In order for the >> SSSD to be stable on all deployments, the bare minimum set of options >> must always be reliable. These are the files that RPM upgrades would >> INTENTIONALLY overwrite on an upgrade, to ensure that they were always >> in-sync with the project. >> >> Right now, with the SSSDConfig API, we are already following this >> approach. We have a schema file /etc/sssd.api.conf and a drop-directory, >> sssd.api.d. The sssd.api.conf contains the common options that all >> services and domains must support. The sssd.api.d/ contains separate >> files for all of the internal backends that we support: sssd-local.conf, >> sssd-ldap.conf, sssd-simple.conf, sssd-krb5.conf. Each of these >> subsequent files contains the set of options available for use by that >> particular backend. >> >> In theory, for a v1 approach, we could continue using this exact schema >> format, though it's extremely limited. Right now, it cannot describe the >> proper format of the value, it will only guarantee that it is an >> integral type, string type, or list of [int|str] >> >> I could write a module using libini_config in C to follow this exact >> behavior in about two days, without adding an actual schema validation >> into libini_config, but my real goal here is to come up with a solution >> that can be packaged with libini_config and be available for other >> projects. We can make this a later goal, if time is constrained. >> >> However, I would REALLY like to come up with the complete format now. I >> can write a custom validator JUST for the SSSD, but we need to agree on >> how the format should look. >> >> I think it is very important to get the format down right from the >> start. We can always opt to ignore certain things at first. (For >> example, maybe in the first pass we will ignore the dependency checks, >> but we'll absolutely handle the range/regex checks) >> >> Having a complete format doesn't mandate that the parser has to actually >> implement everything all at once, but it's VERY hard to change the >> format later on. >> >> So at this time, I'm recommending that we solve this format question >> immediately, and defer implementation into the libini_config itself. >> > > I would not argue about the "fundamental" things. > I just know how vendors bend the rules if they need to. > IMO it is like building a house of cards in front of Godzilla. :-) > But this is more a philosophical discussion. > We can table it for now. > > Defining format - sure. We can and should do it now so that we know > how it would work to avoid problems in future. > But the actual implementation should be deferred or at list done is stages. > > But with Jakub's finding should we reconsider XML approach or > the XML approach con's still outweigh the pros? >
The more I have been thinking about it, the more I think that XML would be a bad idea for the schema. It's a difficult format to use correctly, and I think it would introduce more headaches than it solves. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAku92cwACgkQeiVVYja6o6NwDgCglrDOdXp5P2Jv5P4YCPmNfO40 qtQAn2pFTz5wZHTXH7hLU8jHE6GBEOsg =JUoc -----END PGP SIGNATURE----- _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
