Configuration & distributed setups: INI files wont get us there

[ArcEye]

Issue by mhaberler Fri Apr 4 21:05:06 2014 Originally opened as https://github.com/machinekit/machinekit/issues/104

---

currently LinuxCNC classic uses INI files for configuration information. This assumes a common filesystem and will generally not work a distributed setup.

Related problems are: persistent values (store on exit, reload on startup), and live tunable persistent parameters.

I've written up some thoughts here: https://github.com/mhaberler/asciidoc-sandbox/wiki/Config-Service

problem: the current INI file method wont work downstream - find or build a suitable successor.

[ArcEye]

Comment by zultron Sat Apr 5 04:16:39 2014

---

Pluggable persistence backends would preserve legacy .ini storage while enabling new storage schemes. (Wouldn't it be great to write a ten line python script that read in all your old files and plopped the config into a new database in one shot?)

If the inheritance and parameter override model were strong enough, command line options could be abstracted as another pluggable persistence backend (read-only and, well, not actually persistent).

Seems I need a library like this for every project I work on. :P

[ArcEye]

Comment by mhaberler Sat Apr 5 06:16:03 2014

---

Well, loading the existing INI's and other files into say redis is certainly possible; one nasty issue is comment continuity though: what happens if values are changed in whatever the storage vehicle is - do they find their way back into that INI file? Export is surely possible, but if comments are gone this is not going to be popular.

That's why I thought we'd retain INI files for now, keep the config INI unchangeable, and create designated sections for persistent variables and file contents; kv pairs in the 'persistent' section would be saved on exit, but without comment, into another INI file; this scheme is already used in the gladevcp persistence.py module. Same for the 'files' section.

The sizes/numbers of key/value pairs are not much of a problem either way, the using side API is though, and it better be remote capable; the reason this came up was Alex's Android UI. There is no common filesystem so the UI needs some way to access config info remotely.

Surprising that there's no stock solution to such a common problem.

[ArcEye]

Comment by mhaberler Sat Apr 5 15:47:44 2014

---

yes, I think pluggable backends are a good idea.

My current approach would be a mix of the Pub-Sub-Clone code for a start, and some webdis functionality thrown in (serve dicts over JSON/websockets or http). Actually the latter part might make it easy to provide a web UI to config.

[ArcEye]

Comment by mhaberler Mon Apr 21 21:22:35 2014

---

turns out czmq has a related file format and C library API:

spec: http://rfc.zeromq.org/spec:4/ZPL (some very good reasons..) API: https://github.com/zeromq/czmq/blob/master/src/zconfig.c (not in the docs yet)

supports comment retention, repeating groups and arbitrary nesting. Autoconversion from INI files to this format easy.

example:

 #   ZPL configuration file example
 #   This format is designed to be trivial to write and parse 
 #
 context
    iothreads = 1
    verbose = 1      #   Ask for a trace

 main
    type = zmq_queue
    frontend
        option
            hwm = 1000
            swap = 25000000
            subscribe = "#2"
        bind = tcp://eth0:5555
    backend
        bind = tcp://eth0:5556

looks like a candidate post-INI format to me. It could be the lowest common denominator of 'storage backends' for the config service.

[ArcEye]

Comment by mhaberler Mon Jun 16 19:37:26 2014

---

[from the list]

Charles wrote:

Also, due to the history of LinuxCNC, many core settings (things like homing, maximum velocity and acceleration, etc) are only settable in the .ini file, and yes, you do need to reload LinuxCNC if you make any changes. Newer features have hal pins and can mostly be tweaked at runtime using "halcmd setp ...".

At some point, the legacy .ini settings might get migrated to hal. If you create an issue on github with the values you'd like to change it might happen a bit sooner.

I initially had reservations about the idea: pins, linking, strings, file references - that didnt fit together well for me; so I had laid out my ideas for future config handling here: https://github.com/mhaberler/asciidoc-sandbox/wiki/Config-Service; the key idea is a 'live store' - you'd have a single store; change a value therein, value subscribers get a notice with the new value and may choose to react

I am changing my mind on 'config in HAL':

if pins are not the right kind of objects, it might still make sense to use the HAL namespace with new types of objects - lets call them configitems.

config items would have:

a name - an arbitrary HAL name, dotted notation would map nicely onto nested structures in INI files a value - minimum string, maybe numeric too maybe types - like int, bool, float, 'string', 'uri' (a file is really a URI which needs dereferencing - this handles the remote file access case); but just string x string would be ok I think, not sure a full blown type system is warranted for the task

operations would be be pretty much only 'add ', 'set ', and 'get ' for accessing a value, wrapped in halcmd, C and Python

config items would not live in a component, but say a 'space' or 'configspace' (which possibly could be a variant of a component) the number of items need not necessarily be fixed at startup time config items could live in shared memory, likely rseparate segment and ead-only in to using code except for the managing thread

what's the upside?

first, we'd have a common namespace with HAL, so it could be used with the same tools - halcmd, python bindings, C API.., and minimal learning effort

so in halcmd we'd have 'show conf TRAJ.MAX*' or somesuch, and 'setc TRAJ.MAX_ACCEL 200.0', dang, value changed

for free we now get: config items are available to RT and userland components in a uniform API - reading ini files, and pumping values down through shoddy methods is not needed anymore (see motion for details on 'shoddy' ;)

but my strongest argument is my laziness - I dont have to write a new config server which I described in the abovementioned link:

haltalk could service such a config space with minimum adaptation - the whole state replication pattern for the 'live store' is already in place for remote and local userland cnsumers; it just needs to handle the new object types, but the flow is exactly the same; plus, webtalk will happily translate a HAL config change into a websockets frame with a JSON object just alike - NOW. Nothing to be done in webtalk.

this needs a bit more thought and hashing out, but it could be a really fast way to nail the config problem, with good functionality and low learning effort

[ArcEye]

Comment by cdsteinkuehler Mon Jun 16 21:22:05 2014

---

I think of hal parameters like this already: something that is set once (or occasionally) to control operation and is not a dynamically changing signal.

Have strings been added as basic HAL types? If so, I think that's a very workable solution. I do think it would be good to have numerical types directly supported as well. I don't want to start having to do ascii to value conversions (complete with support for international locales and unicode) in HAL components. Also, in a typical ini file (CRAMPS.ini) there are 39 strings and 92 numerical values, so directly handling numbers and putting some type checking in the (few) places they can be updated seems like it would make things safer overall.

Charles Steinkuehler charles@steinkuehler.net

[ArcEye]

Comment by mhaberler Mon Jun 16 21:33:15 2014

---

the conversion argument makes sense, noted

there are several upsides for going with strong typing:

• string conversion routines in RT are potential issues ontop (NAN, infinite..)
• basic scalars do not vary in size, strings might

the only hard-ish issue is - how to deal with strings or blobs of varying size; I'd hate to set a hard limit at creation time but it makes things much easier

here's the protobuf type universe for a basic type menu ;) - the fixed/vs variable size thing is irrelevant here: https://developers.google.com/protocol-buffers/docs/proto#scalar

as for pin/signal compatibility - I would say assignment could work in both directions (say halcmd) as far as the types match - so 'setp foo config.init.pininitvalue' works, and vice versa

[ArcEye]

Comment by cdsteinkuehler Mon Jun 16 21:51:00 2014

---

Can the length defined strings from protobuf be used, or does that start creating issues with garbage collection?

It seems like the string values are unlikely to change often, so I wouldn't be too concerned with memory 'churn', and the shared memory allocation could be done outside the real-time context. Surely there's a fairly efficient small-memory allocator we can pull from somewhere?

Charles Steinkuehler charles@steinkuehler.net

[ArcEye]

Comment by machinekoder Mon Jun 16 21:56:09 2014

---

How do we handle different settings? There needs to be some way to store and load a complete group of settings. Maybe also portable on a client device. (E.g. uploading a calibration to one, some or all devices)

Also note that there might be some settings which are client specific and have nothing to do with HAL. However, it might be useful to store them to remote place anyway. Lets say for example the size of the client window. In general we don't want to sync that settings to all clients, but it might be useful to do in some cases.

[ArcEye]

Comment by mhaberler Mon Jun 16 22:00:08 2014

---

Chares: yes they can, they are always length/buffer notation coming & going; the distinction string vs blob is more for Unicode handling

ah, another advantage. I guess rw access to scalars would be atomic, so the only ones which would need protection are strings/blobs.

I think a string/max size argument at creation time would cover most cases - I dont see file contents stored there, those would be URI's (file://...)

semi-related - remote file access (eg UI definition files like glade .ui or QML) - dereferencing a URI needs to be supported; that can be either done in-band with a 'dereference URI' operation; or in the simplest case with a http access library and the existing embedded http server; the latter would open up the need to authenticate/encrypt the second access path once we 'do security'; if we stay in the zeromq encryption universe and do file dereferencing in-band it'd be easier to manage even if less flexible than http

[ArcEye]

Comment by cdsteinkuehler Mon Jun 16 22:00:19 2014

---

I wouldn't have thought persistent data subject to change (window size, last opened file, etc) would be stored with this mechanism, but perhaps it should be?

If so, that fundamentally changes the requirements.

Charles Steinkuehler charles@steinkuehler.net

[ArcEye]

Comment by machinekoder Mon Jun 16 22:02:16 2014

---

For that purpose the config component might have some kind of storage slots where one can store and load s´configs from. This might also be useful to calibrate parameters of HAL components.

[ArcEye]

Comment by mhaberler Mon Jun 16 22:03:37 2014

---

not necessarily; I envisage that configspaces be loaded at startup one way or the other and persistence can be handled the same way

eg redis would be a haltalk subscriber to the persistent configspace - done initial loading from redis is trivial

[ArcEye]

Comment by mhaberler Mon Jun 16 22:06:32 2014

---

Alex - have a look at this image: https://github.com/mhaberler/asciidoc-sandbox/wiki/Config-Service#architecture-notes

all topics (probably a better name than configspace) would do live update if desired; some can be persistent, but that need not be a HAL code proper thing, it could be done ontop of the API

[ArcEye]

Comment by mhaberler Mon Jun 16 22:10:24 2014

---

Charles: yes, you're spot on with HAL params - that's concept needs to be extended, and disassociated from HAL components (right now HAL params are second-order objects as they are component properties)

to clarify - not proposing to remove HAL params as they stand; just take the idea further

[ArcEye]

Comment by mhaberler Mon Jun 16 22:57:32 2014

---

Just thinking on where to place config topics. It occurred to me there's a logical place, and it is not the HAL shm segment, it is the 'global segment' - the very first shared memory segment allocated at startup by msgd, which contains key parameters and the logging ringbuffer. It is also the last one to go away.

By having config items there and hence early, the config C/Python API would be live/loadable/usable available even before rtapi_app and HAL proper are started - meaning the latter could already use the config API during RTAPI and HAL startup - big plus, fewer chicken-and-eggs issues which would require special handling.

Also, being in a different shared memory segment than HAL means config items dont disturb HAL object memory layout which is done with some thought towards cache-friendliness.

config then would be a completely separate API from HAL, and conceptually 'under' HAL such that HAL could be using code. Value inspection and bridging (setp, setc etc) could still be in halcmd for less surprise. The RT config support could actually be a module loaded before hal (even if there's not much point since it wouldnt be optional eventually once RT HAL starts using config; more in terms how to think about this).

[ArcEye]

Comment by cdsteinkuehler Mon Jun 16 23:09:40 2014

---

+1 on using global memory segment, sounds like a great idea!

Plus, it seems to me like these values aren't really part of the hard real-time layer like true HAL pins and parameters, so this give the flexibility to tie to a file backing store, parse NANs and throw exceptions, make Linux system calls, etc.

I like!

Charles Steinkuehler charles@steinkuehler.net

[ArcEye]

Comment by mhaberler Mon Jun 16 23:21:38 2014

---

no, changes are non-RT

I'm just thinking through change notification. Easy in userland.

Do we need config item change notification to an RT thread? I think we should have it 'in principle' for orthogonality - it could be posted to the access structure in the component, or a per-componet event bitset.

[ArcEye]

Comment by mhaberler Mon Jun 16 23:31:07 2014

---

data organisation and namespace:

I think this library is almost copy and paste except for the shm pointer handling and locking: https://github.com/zeromq/czmq/blob/master/src/zconfig.c

it is actually the C implementation of a tree-structured config file format specified here: http://rfc.zeromq.org/spec:4/ZPL

nice plus: retains comments - very important with config languages, people expect those to be retained on update.

[ArcEye]

Comment by mhaberler Tue Jun 17 09:44:32 2014

---

I trailed the net a bit for shared memory malloc/free and lockfree stuff in connex with the above

I did not find exactly what I need, but this rather interesting tookit: http://concurrencykit.org/index.html

joining their mailing list to see what they have to say on the issue; project sponsor seems to come from the right space - RT aware: http://en.wikipedia.org/wiki/AppNexus

[ArcEye]

Comment by DejayRezme Thu Jul 17 14:01:47 2014

---

Just my little 2 cent suggestion: For the config would be to include comments in any new configuration file format that can be shown and edited with a potential graphical configuration screen. Ideally there should be "schema" comments that work like code documentation (javadoc) that can be shown in a graphical tool and wouldn't have to be repeated for each individual machine variant (for example, what a specific parameter means and what it does), and specific user comments for your machine (for example notes or calculations or alternative values). Separating those into different files might be overkill though and more hassle than it's worth.

For an ini file you could simple collect all the # comments above a config parameter line and parse them to the new format as a starting point. Or you could add tags to them. I've written an ini file parser in the distant past that was able to read, store and write back comments so they don't get lost when changing the values.

[ArcEye]

Comment by mhaberler Sun Jan 11 01:37:51 2015

---

@strahlex, @cdsteinkuehler, @zultron : looking at #425 and #426 and the horrendous warts it entails:

what about using Python instead of ini:

[HAL] HALFILE=foo.hal HALFILE=bar.hal

becomes (can be autotranslated from ini):

hal = Section("HAL") hal.halfiles = [ "foo.hal", "bar.hal"]

any Python feature at your fingertips btw stolen from Django: https://docs.djangoproject.com/en/1.3/topics/settings/

and to turn the crank further:

why not make an application just a Python script which does a couple of imports (bits, pieces, maybe config), and at the end run it? I mean burying scripts/linuxcnc is a worthwhile cause ;)

[ArcEye]

Comment by zultron Sun Jan 11 03:15:08 2015

---

On 01/10/2015 07:37 PM, Michael Haberler wrote:

what about using /Python/ instead of ini:

I still have to digest this a little...

and to turn the crank further:

why not make an application just a Python script which does a couple of imports (bits, pieces, maybe config), and at the end run it? I mean burying scripts/linuxcnc is a worthwhile cause ;)

This essentially sounds like what I was going for with the initial 'masterd' concept: Write a full MK application with a few lines of Python (including the currently cumbersome job of handling RT setup/teardown). Michael's suggestion to handle HAL config helped fill out the bigger idea, where it feels natural to junk the linuxcnc script and run the application all from Python.

In re. to above discussion about HAL params in SHM, I have the basic library coded to store typed config variables in a tree-like structure in SHM. I'll get that in a github repo soon for your scrutiny. It uses Michael's rtapi_heap stuff, so data structure nodes are dynamically initialized, and string variable length is variable. It is a 'live store', and updating a value updates it anywhere it's used, rtapi and ulapi. Still missing are update pub/sub service and callback system for things that want to be notified of changes.

The config persistence is implemented as plugins that read from and (where applicable) write to configuration sources, like .ini files, env vars, argv[], etc.

I'll fill the details more when I get back to it next.

[ArcEye]

Comment by mhaberler Sun Jan 11 10:10:48 2015

---

yes - your code could be the 'storage engine' for the key/value pairs and any tree structure on top, and the way you populate them is by executing Python code

btw if we do that, a minor syntactic variation might be able to handle persistence (another mess with ini files):

[FOO] BAR = somevalue # great, just now how to make BAR persistent?

well like so:

foo = Section("FOO")
foo.bar = 12345 # not persistent foo.bar = persist.int(12345) # persistent - automagially restored at startup

ramming this into ini files (any maybe several ones, one written at shutdown to 'provide persistence' and reading them all is super messy and half-baked (and we dont get strong typing too with INI's)

[ArcEye]

Comment by zultron Mon Jan 12 17:58:11 2015

---

My config storage is all broken now after we decided to store config in shm, but that'll get reconnected at some point.

The system handled persistence through config store plugins. For example, if a .ini file plugin pointing at e.g. ~/linuxcnc/configs/doo-dah/persist.ini were loaded and were read/write, then the config param would automatically be written to the file upon change. There would be no need to explicitly persist foo.bar if the param's source were a writable config store.

It would help me to understand two things:

• What kinds of parameters need to be persisted between sessions? As I understood before, the list of parameters that a config service is required to manage is strictly limited to those related to RT setup, and those currently coming from the .ini files in /config. Is that still true?
• What are the possible sources of value updates? If parameters are only updated from Machinekit clients through the config service, it greatly simplifies programming requirements. However, ISTR there's a requirement for parameters to be writable from both ULAPI and RTAPI (i.e. code running locally with direct access to shm), and that requires a special 'setter' routine that would not only change the parameter value but also trigger callbacks for other subsystems 'watching' the parameter. Such a piece is still missing from my dev branch.

[ArcEye]

Comment by mhaberler Tue Jan 13 23:16:01 2015

---

John and I had a long phone call on how to proceed with the config service, notes below

status:

• there's code by John which can store a tree structure of strongly typed values in shared memory, making those accessible to HAL land; this code already handles int/bool/double/string and lists thereof; nameing will be similar to pathnames (/section/subsection/item)
• there's a demon managing this space (masterd) which handles loading and saving of persistent config items

topics discussed:

type universe: we agreed on making config types a superclass of HAL types (HAL bool/s32,u32,float plus strings/blobs)

type checking: strong typing is a must; John already has a Python-based scheme in place, basically a type template with source/destination information for storage backends

change monitoring: this will happen through a zeromq PUB/SUB mechanism very similar to what is in haltalk already; if using code subscribes to a config item, that item is marked for change monitoring in masterd, and updates sent as needed. Hence monitoring/setting possible locally and remotely.

unique handle field: Config items will have a handle field like all HAL objects, to unify handling with rcomps and groups.

persistence: there will be an API provision to mark a config item as persistent, such that it will be saved at session exit and reloaded with that value at next startup.

using configitems in HAL: it should be possible to link a pin to a config item maybe like so (halcmd mockup here, but eventually C and Cython APIs available):

net /foo/bar/baz comp.0.pin [persist]

semantics: the pin will inherit the value from the config item if set. If marked as persistent, save/restore as above will happen.

we discussed linking configitems to signals too - not sure about the use case yet and if that is needed; but the scheme is similar to pins and simpler to code

this linking capability will require the entity managing the config space and serving subscription and updates to 'see into HAL' to reference and set pins/signals. An extension of the value storage struct will provide the basis.

outline of using code watching a parameter (flow of zmq/protobuf messages):

--> subscribe /foo/bar/baz <---- type/current value/name/handle ... change happening here... <---- handle/updated value ...

open issue: handling of parameters in config shm if not defined in the config file/backend. The current scheme would store any parameter ever defined, regardless if explicitly set in the current configuration, which result in a poor signal/noise ration on inspection of the config space

[ArcEye]

Comment by mhaberler Wed Jan 14 23:27:12 2015

---

regarding linking pins to config items - there are several options:

• "link" those (per se separate) objects, which requires an 'unlink' for completeness and entails the chores of handling the transitions, but allows exposing pins in a particular section
• automatically expose unlinked pins in a section (like /halpins/) without explicit linking

second one is easy first option is more natural as related items are collected in a section, but other than (2) this requires some activity/method to mark pins (explicit link)

what do you think?

[ArcEye]

Comment by jpmoniz Mon Feb 16 13:31:43 2015

---

@mhaberler @zultron

Guys, If there is any remedial work not high on your priority list, that is within my capability. I would be willing to help out on this. Even if it's just testing and Doc type stuff.

[ArcEye]

Comment by mhaberler Mon Feb 16 20:17:13 2015

---

I see really two ways to deal with config items disguised as HAL objects:

• there's a "config" component which exports pins, those correspond to config items; this component would be the first to come into existence on RT startup
• config items are HAL signals; those signals do have a "writer" or an I/O pin equivalent (a writer in normal signal parlance is an output pin which can change the signal); it would be a new kind of reader/writer which would be associated with a config item

the nice part about signals is - they do not require a component hence they do not go away with the component, they are longer-life if you will; config items must appear very early during startup to be useful

[ArcEye]

Comment by mhaberler Fri May 8 10:23:59 2015

---

Alex recommended we have a look at Elektra: http://www.freedesktop.org/wiki/Software/Elektra/

see also: http://community.libelektra.org/wp/ https://github.com/ElektraInitiative/libelektra/blob/master/doc/NEWS.md

[ArcEye]

@markus2330 commented on 10 May 2015

Thanks for considering Elektra (http://www.libelektra.org). @zultron quite nicely sums up how Elektra can be described: "Pluggable persistence backends" In the current implementation, however, there are limitations concerning distributed setups. A completely new backend would be needed to support that. The current team in Elektra does not have a focus on such a backend, because there will always local configuration needed (e.g. how to find your configuration) but a distributed configuration is already solved many times (e.g. by cfengine, puppet or by simply using a distributed file system). Elektra would certainly provide a good migration path (you could create a backend with your status-quo) and it would certainly deliver much more than using TOML directly (e.g. an abstraction that no file names need to be hardcoded in applications). Elektra has a focus on writing configuration files and retaining the comments for 100% (e.g. see the ini plugin, when the augeas plugin is in use you have a guarantee to not lose any space, but this seems to be not really suited for your requirements in many ways. I just mention it that you see we are interested in such things.). I f you have any questions you can write here, at Elektra's issue tracker or also contact me directly (markus at libelektra.org).

[ArcEye]

@mhaberler commented on 10 May 2015

well, the 'new backend' requirement doesnt fend me off ;) we've been putting the better part of LinuxCNC onto a new middleware already - it is based on zeroMQ, protobuf and mDNS for discovery

the obvious pattern for consumers would be a publish/subscribe pattern like already used in STP which is already implemented in src/machinetalk/haltalk (server side) and gladvcp+qtquickVCP (client side)

this would cover both initial value conveyance as incremental updates as parameters are changed

@markus2330 - what is the status of the Qt5 UI for editing elektra trees - do you think it is good for production use yet?

[ArcEye]

@machinekoder commented on 10 May 2015

@markus2330 @mhaberler The Qt5 Ui was mentioned in a pro-linux article. I have read the paper of the student and one the problems he faced (tree structure in QML) will be solved with Qt 5.5. QML is a huge plus for us since it would easily integrative with QtQuickVcp. With the right backend it could work out as remote configuration tool.

[ArcEye]

@markus2330 commented on 11 May 2015

Qt5 QML GUI: I think its basic functionality including undo is working very well. It obviously did not receive the testing the core parts did, but I use it regularly with only minor issues (are listed in the bug tracker). I like the Idea with QtQuickVcp, would be great to see that running. @0003088 also had in mind to create a web interface, but the thesis would have become too large.

A REST interface should be a piece of cake with the python bindings, if you are interested in that.

@mhaberler between-process notification can done via plugins inside a backend (and a listener with reload code on the other side). Currently there is a dbus plugin, but a zeroMQ plugin should be easy to write.

[ArcEye]

@mhaberler commented on 12 Jun 2015

One possible field of machinekit applications is playing an "intelligent drive" (aka ROS node), with ROS being the driving layer

ROS has its own way of storing/accessing parameters (see example here ).

It would be extremely valuable if machinekit could interwork with a ROS parameter server and maybe act as a server as well (client being more important for now)

I guess a ROS parameter plugin would be the way to do that in elektra

[ArcEye]

@machinekoder commented on 28 Oct 2015

@markus2330 I think I have reached the point where it is time to fix the issue. I have some problems getting started with libelektra. Are there any basic kdb tutorials?

A combination of libelektra to mount the existing ini file + a ROS parameter service like (ROS parameter server is not standalone) plugin might be the solution.

Once that is established it should be easy to creata HAL plugin for libelektra exposing relevant pins as IO pins to a HAL configuration.

I summarized my idea here: https://github.com/strahlex/asciidoc-sandbox/blob/master/param-service.org

[ArcEye]

@markus2330 commented on 29 Oct 2015

Basic tutorials can be found here: https://github.com/ElektraInitiative/libelektra/tree/master/doc/tutorials

Man pages for kdb are not yet merged, but will be in next release: ElektraInitiative/libelektra#304

Mounting the current INI files is definitely the easiest migration path. We are currently improving the ini plugin so that it preserves order (comments are already preserved).

About the summary: Sounds ok, some details are missing. I think you mean user/foo instead of user/bar? You should prefer cascading keys, e.g. /foo, then the lookup layer will automatically use all namespaces (spec, proc, dir, user, system in that order), see also https://github.com/ElektraInitiative/libelektra/blob/master/doc/tutorials/namespaces.md and the release notes of 0.8.12 (dir namespace) and 0.8.11 (spec namespace) https://github.com/ElektraInitiative/libelektra/blob/master/doc/NEWS.md

It might be a good idea, to have some idea about the hierarchy of your configuration, see https://github.com/ElektraInitiative/libelektra/blob/master/doc/tutorials/application-integration.md and ElektraInitiative/libelektra#302 (proposal for naming conventions).

Btw. upstream welcomes any additional plugins, even if they are specific to your project (e.g. using Protobuf). We run all provided tests for every commit and merge request.

[cerna]

Is this issue completely stale and dead?

I am trying to wrap my head around it and see how it fits into my own model of Machinetalk functionality. Is any mentioned code available for postmortem? (I guess this is the aforementioned masterd daemon, but the Elektra idea was never materialized?)

[markus2330]

Elektra implemented some features you wanted (arrays in INI, improved notifications, Web-UI) but I also have the impression that the integration within machinekit did not progress.

We are currently mainly working with LCDproc, Oyranos and KDE but we are looking forward to continue our collaboration with machinekit.

[ArcEye]

The big question is do you think there are any distributed machinekit systems out there which require this?

The theory behind this is fine, but it appears the user base only uses remote access so that they can get free software and not have to bother leaving their windoze/mac comfort zone either.

They are remotely using a single actor, single instance system, which only requires one setup.

[markus2330]

The big question is do you think there are any distributed machinekit systems out there which require this?

This is for you to decide. Elektra provides various abstractions but it also supports to directly read/write old-fashioned INI files. As first step, I would suggest that Elektra simply goes on reading and writing the same INI files. We will also do this for LCDproc that way. Once Elektra is used everywhere, you can switch easily to different storage backends (like YAML or something distributed).

[cerna]

The big question is do you think there are any distributed machinekit systems out there which require this?

Hard to say. Probably not. Because if there were then probably someone would try to merge his solution upstream. And I don't think that there are commercial companies big enough to maintain completely separate code-stream using Machinekit. However, that said, it's not a proof that there is no need for similar solution. And if nobody will create, then nobody will use it.

Truth be told, no disrespect to original authors intended, but I have a feeling that the Machinetalk idea and implementation turned into a bit of mess and corroded from Machinekit non-deterministic middleware into remote GUI connector.

My idea of "cool as a cucumber" is machine composed of 1-∞ small nodes (cheap SoC SBCs) connected by application bus to one bigger system. For this, some kind of a better configuration would be needed.

However, reading thought this, I again feel that it was discussed as a something with overflowing capability. (Like systemd.)

I don't know about Electra's overhead, but given that the system should run as single node and be protected against failure, then on every node would need to be replicated storage of all configurations. (Well, I really don't see a need for more that one, but...). Maybe @markus2330 would know.

I have been thinking if simple FUSE based in-memory tree structure configuration registry with file watching from components (HAL and otherwise) on one side of the broker and ZeroMQ/something or Electra on the other for storage and outside access would not be simpler to implement.

[markus2330]

I don't know about Electra's overhead,

We've put a lot of effort into optimization. The core library is 64K (master version on amd64) and due to mmap caches we are nearly 100x faster than parsing config files. Furthermore, we have an order-preserving hash-map to have O(1) lookups and still preserving O(1) iteration.

then on every node would need to be replicated storage of all configurations

Yes, I also see it that way. There are many good solutions to replicate config on many nodes (ansible, puppet, or simply NFS, ...)

ZeroMQ

Elektra supports notification via ZeroMQ.