Create initial site

[ronaldtse]

Libraries:

• Nereon parser (Rust) https://github.com/riboseinc/rust-nereon
  • Docs: https://docs.rs/nereon
• Nereon parser (C) https://github.com/riboseinc/libnereon

Software using Nereon:

• Nereon configuration daemon (Rust) https://github.com/riboseinc/nereond
• Riffol (Rust) https://github.com/riboseinc/riffol
• RVC (C) https://github.com/riboseinc/rvc
• Retrace (C) https://github.com/riboseinc/retrace
• Enprot (Rust) https://github.com/riboseinc/enprot

Spec:

• Nereon syntax https://github.com/riboseinc/nereon-syntax
• Engyon syntax https://github.com/riboseinc/ros-engyon-syntax/

Thanks @strogonoff 😉

[ronaldtse]

CC: @drystone

[strogonoff]

I suspect I sound like a broken record asking this for each project, but what would be the key feature / top priority (philosophically) / raison d'être of Nereon the project? This information is needed for better tagline/pitch copy that project site design requires.

@drystone / @ronaldtse

[strogonoff]

Down the line some questions would be:

• Is it fair to say that Nereon is the configuration daemon? (Like Riffol is an initialization system.) What part does the daemon play in the project as a whole?
• Or, is it fair to say that Nereon is an alternative parser for UCL? (https://github.com/riboseinc/libnereon/issues/37)
• Why Nereon and not LibUCL? (https://github.com/vstakhov/libucl)

[drystone]

Nereon is a specification for application configuration and logging. The aim is to be able to configure arbitrary software using a standard configuration syntax and to generate log messages and event information in a standard format. This will allow for meta tools to manage configuration and logging for a large number of varied applications.

Nereond is such a tool: it is a daemon that applications can use to bootstrap configuration and receive dynamic updates to configuration at runtime. Nereond itself will be updated by a user interface called Gyndol. Configuration changes made using Gyndol will be forwarded to Nereond which will in turn notify the running application to update it's configuration.

Central to Nereon is NOC or Nereon Object Configuration. NOC is a configuration language similar to UCL but with some additional features such as the ability to define templates and evaluate expressions during parsing. Applications will use NOC syntax for their configuration files. NOC syntax is defined at the Nereon-syntax repo - currently out of date but soon to be updated.

Then there is NOS or Nereon Object Schema. NOS describes how an application gets configured. It describes how command line arguments and environment variables are translated into an application's runtime configuration. NOS, although written using NOC syntax, is compiled into the application. NOS will also be defined in the Nereon-syntax repo.

Thus all new applications can have a uniform configuration structure so tools such as Nereond can be used without having to write adapters to support varying formats. We also intend to write adapters for existing configuration languages so, for example, we can configure Apache or Nginx, perhaps even using the same NOC. This will enable us to develop user and machine interfaces such as Gyndol which can be used for universal configuration management.

That's my take :) Hopefully @ronaldtse can correct/expand further.

[strogonoff]

@drystone thank you, this was super helpful and clear.

[ronaldtse]

Thank you @drystone for the excellent explanation. If I may slightly explain on "configuration and login", Nereon is a set of data models (https://github.com/riboseinc/nereon-models/) including:

• a universal configuration model
• a universal event logging model

(Perhaps we should separate the event logging model? It's not even been used yet. Thoughts...?)

The universal configuration model is what rust-hereon and libnereon (the parsers), nereon-syntax, NOC, NOS (the specifications) and Nereond (the configuration daemon), are based on. Which are what Riffol and RVC (the users of Nereon) are based on.

The configuration model is valuable for exactly what @drystone mentioned, is for treating any program, container, OS as a state machine, with a single configuration, that can be changed via multiple ways:

• environment variables
• command line arguments
• configuration file in NOC
• interactive command-line interface such as Gyndol.

And provide a "configuration schema" to allow machines to directly understand (and present, via UI or command line autocomplete) what configuration is allowed by this {program, container, OS}.

While I am typing this I can see a diagram will be very useful in explaining 😉

[strogonoff]

From my first look as an outsider, as far as configuration concerned event logging does seem a bit tangential (something from syslog’s territory?)

I mean in the long view it’s all related, just more difficult to adopt all at once perhaps

[strogonoff]

Thanks for additional details @ronaldtse!

What’s the relationship between Engyon and Nereon? Engyon’s repo is scarce in docs & Gitlab link doesn’t work. Seems like it’s related to crypto[graphy]?

[ronaldtse]

Engyon so far has no relation with Nereon; it is a secure document model. Sorry I got confused 🤣

[ronaldtse]

@strogonoff agree on the unrelated-ness of the event/log model. Let's take it out.