Date: Mon, 16 Nov 2015 12:08:45 -0500 From: Allan Jude <allanjude@freebsd.org> To: Dan Partelly <dan_partelly@rdsor.ro> Cc: freebsd-current@freebsd.org Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? Message-ID: <564A0D9D.1060400@freebsd.org> In-Reply-To: <C9828129-DBE1-4BE9-B957-863C4B4E152E@rdsor.ro> References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <5648C89C.2050206@freebsd.org> <C9828129-DBE1-4BE9-B957-863C4B4E152E@rdsor.ro>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HNlj8XK8u868bQ93OPEQfqbX8S2HlnNQj Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2015-11-15 14:44, Dan Partelly wrote: >> I would welcome competing ideas/solutions, but someone would have to a= ctually build them, not just >=20 >> rattle off some ideas on the mailing list. >=20 > Am I missing the point of a mailing list ? it is a place to present an= d exchange ideas, ask why some things are the way they are , and get crit= icism. Rattling ideas is generally where it all starts. You cant realisti= cally expect one to start a pervasive project like transactioanl database= s for an OS configuration without not one mailing list discussion, but a = lot of consultation.=20 >=20 Sorry, I didn't mean to say we shouldn't talk about this. The reason for the less-than-warm response you got from multiple people, is that this is the third or fourth such discussion on the mailing list (this is what mailing list archives are for). Once every so many months, someone rants about how libxo is horrible and is ruining the base system, and wants to lib-ize everything. And no one every does it. Meanwhile, libxo actually gets worked on. >=20 >> There are tools available to filter json/ucl output > yes they are. vim is one . sed is another. awk is the third =E2=80=A6 = But a pipe needs both ends to talk the same language. I can generate json= as output, i can filter it , but what tool in FreeBSD will accept it as= input ? None. A >=20 >> and my forthcoming uclcmd >=20 > What uclcmd does / will do ? =20 It can read, filter, and write UCL (as well as JSON, YAML, and msgpack. Hopefully it will be able to do NVLists in a few months). It is designed to be able to view, extract information from, and edit config files. AsiaBSDCon Paper: http://allanjude.com/talks/AsiaBSDCon2015_paper_-_UCL_for_FreeBSD.pdf BSDCan Dev Summit working group: Wiki Page: https://wiki.freebsd.org/201506DevSummit/UCL Slides: http://www.allanjude.com/bsd/BSDCan2015_-_UCL_Working_Group.pdf Additional Slides about libucl: http://www.allanjude.com/bsd/cebka_BSDCan2015-UCL.pdf Video: <apparently not online yet> BSDCan Presentation: Slides: http://allanjude.com/talks/BSDCan2015_-_UCL_for_FreeBSD.pdf Video: https://www.youtube.com/watch?v=3D8l6bhKIDecg >=20 >> UCL is a good solution to having a universal config file, and is bette= r >> than the bespoke config files each utility has >=20 >=20 > I agree with you, if you manage somehow to port every ad-hoc database F= reeBSD has in base to ucl, (including all the bestiary we have in /etc ) = and offer tools to parse them in the rc init system to fetch the settings= =2E I dont expect this to be done in one release , but do you tend toward= s this in your projects ? One config format to rule them all is good. Yet= another config format in selected places in base is evil. >=20 The goal is to change everything, and I am making progress. The working group at BSDCan had quite a wish list of things to convert, including a bunch that I figured people would prefer not to touch, like login.conf (I need to polish that patch and get it up for review) >> A transactional database >> might be better (for some uses, likely less so for some people), but I= >> don't hear anyone volunteering to do that work. >=20 > IIRC Solaris uses sqlite. Might be a decent solution. ( a lot of the ad= hoc unix databases are relational databases in disguise, with unix tools= acting as operators) And if you abstract a config interface API over UC= L, someone could benefit from it by plugging in a transactional backend = one day. All you would have to do is not directly plug in UCL, but work o= n a orthogonal abstract API. You could even model it after UCL API. > Please consider it.=20 >=20 For bhyve, the basic design they have in mind is UCL config files that are parsed and presented to the application as an nvlist, which it then passed between modules of bhyve (like networking, out-of-band access, graphics, disk (vmdk, qcow, etc)), without the base bhyve application having to know what config options modules actually support. It seems like a reasonable design to me. I don't know that further abuse of sqlite is actually a good idea, but I am still a bit new at this. >=20 >> I would welcome competing ideas/solutions, but someone would have to a= ctually build them, not just >=20 >> >> lib-izing all of the utilities instead of using libxo is a better >> solution. It would likely be gratefully accepted if someone were to do= >> it, but most likely, no one will. >> >> libxo exists now, and most applications can be converted very quickly >> (although care does need to be taken, and it sometimes has not been). >> >> There are tools available to filter json/ucl output, namely textproc/j= q >> and my forthcoming uclcmd >> >> One of the major other consumers of the json/xml output of libxo, is w= eb >> control panels. This is why Juniper is doing the work, and I can think= >> of a list of other appliance vendors who would love to replace fragile= >> per-application parsers with a json parser to extract data from variou= s >> command line tools. >> >> UCL is a good solution to having a universal config file, and is bette= r >> than the bespoke config files each utility has. A transactional databa= se >> might be better (for some uses, likely less so for some people), but I= >> don't hear anyone volunteering to do that work. >> >> So, libxo and libucl may not be the very best solutions, but they are >> the ones that are moving forward. I would welcome competing >> ideas/solutions, but someone would have to actually build them, not ju= st >> rattle off some ideas on the mailing list. >> >> --=20 >> Allan Jude >> >=20 --=20 Allan Jude --HNlj8XK8u868bQ93OPEQfqbX8S2HlnNQj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJWSg2kAAoJEBmVNT4SmAt+JfYQAJMu2sJq3h8VEgcRFf199GKr pYS+PWbteJpKh8M4goBSGLvpom7NI1V5vfPC+04YoEpAhQZYO24zfS5q7sHkujv8 F52ERz1iOONwEt5A/fvkTew38rJEq1htdW/18siNg1KJQU2491FO9Rhcv99NE/SV HRbWHq81r/mY23/uaGbfzxj5jFf3h62yrLqz2xbweZc29Om2ouEA6HeulzHkDp0h VszRrwfIokdDcKyNuRIugy45HVx2AO4ltHoxn3DKbL26QNGs5qTsOWVdhoIiVFeS 3VJO5GwLqVo9RGPLGdCEvAuE9XBPdQjkQ0PT6/1tTulubLI4VoB/X9REb2kSZjNK bKBRqSbYfVo0lI8GIU0ahPEx6ipO/def3pgzl6wpg98dxBoF+gBG2STVgqkBmuM0 Y0yFGlKZ8vOe27N+ZUmPFGqAD3sBT2YCSvQpTJGkhwJKhPKbKImWnIUrE7nh68n1 mJAZb0cm2WtJUTTh7rzVwvl9x25E5jGUfweGjYuks6TAqYvKyYsNCu7Ce5feF5Q2 cuzdz+YdQVgViZCTr+tti2IFETeoy/rkxNc8PIYFoAYOlf/s+hqI3REYta5QAJzk 15K2K+qQFIPqPryh6hYX5OWVT4+BvctrN8AOOV0AJSIzgd1k3sGZq1Mp+lCfYQVq MdtoNzwOw4JsnMUEBfuF =xpx8 -----END PGP SIGNATURE----- --HNlj8XK8u868bQ93OPEQfqbX8S2HlnNQj--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?564A0D9D.1060400>