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

[Bill Erickson]

On Fri, Nov 4, 2022 at 1:23 PM Mike Rylander <mrylander at gmail.com> wrote:

> 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.
>

Not exactly.  I didn't dig into this too much in my previous message, but
the idea was to support a single file structure, without necessarily
requiring a single file.

A ~/.srfsh.yml file might look like this:

=====
message-bus:
  domains:
    - name: private.localhost
      port: 5222
  credentials:
    opensrf:
      username: opensrf
      password: password
  connections:
    srfsh:
      credentials: opensrf
      logfile: /openils/var/log/srfsh.log
      loglevel: debug
=======

Gateway, router,  standalone client configs could be similarly paired
down.  Or, if you want just one file (like me), that works too.


>
> 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.
>

OK, good to know.  That should be pretty straightforward to add.


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

Awesome, thanks for the feedback!

-b




>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.evergreen-ils.org/pipermail/evergreen-dev/attachments/20221104/77e71bba/attachment.htm>