[Evergreen-dev] Thoughts on experimental OpenSRF config format change

[Mike Rylander]

Hi Bill,

First, thanks for moving this forward!

(unfortunately?) Right off the bat, I'm /really/ not liking the idea
of merging application settings (opensrf.xml) into initial connection
settings (opensrf_core.xml).  If anything, I'd prefer to see the
application settings move farther away from the file system, somehow,
rather than have to spray that info all over the place -- right now
application config only /has/ to be colocated with the
opensrf.settings app, but it looks like this would require it
everywhere and in potentially only-very-slightly-different files
(differences of service assigned, or service settings, per host) that
would be difficult to troubleshoot.

Setting, er, application settings aside, though, I /do/ like the idea
of restructuring configuration files to be simpler (or at least more
modern).

(Ironic historical note: the original config file format was an
enhanced "INI" style, with named section links (even section nesting),
file includes, and typed values -- a lot like yaml today, but without
the whitespace as syntax part.)

I need to look at your example in more detail and do some more
noodling on the implications, but to answer your question about
"multi-server bricks", yes, we do and will still need that.  There are
significant (read: cost-impacting) situations where one needs to run
more horizontally scaled instances of service X than they need for Y,
and in those cases running extra Ys is a waste of resources. I believe
this comes back to "should one 'domain' be able to know about more
than one instance of a service" -- and the answer to that is yes, we
need that.  In fact, if you have the concept of a router (even if it's
really just a redis stream now), and you support cross-domain
registration, it seems like it would be extra work to /disallow/
multiple domain-local instances of a service.

Thanks again for working on this! I hope to have some time to dig into
this in the next week or two.

--
Mike Rylander
Research and Development Manager
Equinox Open Library Initiative
1-877-OPEN-ILS (673-6457)
work: miker at equinoxOLI.org
personal: mrylander at gmail.com
https://equinoxOLI.org

On Fri, Nov 4, 2022 at 11:40 AM Bill Erickson via Evergreen-dev
<evergreen-dev at list.evergreen-ils.org> wrote:
>
> Hi Devs,
>
> Some background:
>
> Some may recall my Redis demo at the last EG conference.  In the session, I proposed deprecating the OpenSRF router.  The discussion continued, particularly with Mike R. and Galen, where we discussed retaining support for multi-domain routing for high availability setups.  (Think restarting a service on one domain/brick and having requests to said service get routed to another domain/brick via the Router).
>
> Skip ahead, I've started working on code to implement multi-domain support in my Redis branch, but quickly found the existing opensrf_core.xml file to be less than ideal with respect to defining which services run on which domains, among other things.
>
> Maybe this is an opportunity to change the configuration file format?  As an experiment I put together a sample of what made sense to me:
>
> https://github.com/berick/OpenSRF/blob/user/berick/lpxxx-redisrf-streams-v3/examples/opensrf.yml.example
>
> [I used YAML because I find it tidy and flexible.  I'm more concerned about the configuration structure than the file type, so we could continue using XML or something else, but for my part YAML is superior.]
>
> One key difference is that the message bus / connection section is separated into reusable chunks:
>
> 1. Routable domains
> 2. Message bus credentials
> 3. Connection types.
>   -- These link credentials with logging configs.
>
> At runtime, clients/services link a domain with a connection type to derive the bus connection information.
>
> Other benefits of the modified structure:
>
> * Services are collected into named groups and linked to domains instead of routers.
> * Support for other named configuration chunks.  E.g. create a named database setup that can be referenced from the cstore, storage, reporter-store, etc. configurations.  Less duplication.
> * One file format for standalone OpenSRF clients, gateways, and services.  The file just contains less stuff for clients that don't need the full data set -- or not, either works.
> * Custom connection types for ad-hoc scripts, etc. so they don't require their own config file.
>
> And last but not least, the changes work much better for my Redis branch, where we have to be more explicit with our bus domains and their behavior for multi-domain support.
>
> One thing not included in the sample are host-specific setups, where a "brick" contains multiple hosts, some running different services than others.  This could be added, but I wasn't sure if that was still a common use case.
>
> Thoughts?  Other config wishlist items?
>
> Thanks for reading!
>
> -b
>
>
> _______________________________________________
> Evergreen-dev mailing list
> Evergreen-dev at list.evergreen-ils.org
> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-dev