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

[Bill Erickson]

Inline...

On Fri, Nov 4, 2022 at 12:15 PM Blake Henderson via Evergreen-dev <
evergreen-dev at list.evergreen-ils.org> wrote:

> Bill,
>
> I think our opensrf.xml file has several places that need attention. I'm
> glad you're taking it on! I support the move to yaml over xml for much
> the same reasons you've stated.


Great!


> It's easier to read but it is *very*
> sensitive to spaces.


Interesting.  My experience so far has shown the extracted values to be
very predictable.  (I suppose it depends somewhat on the parser).
 Anything in particular I should look out for?


> If I'm understanding this right, "service-defaults"
> definition will fill in blanks for any of the open-ils services when
> they are omitted in their specific definition block?


Yes.


> I think that's
> brilliant because it cuts back on repetitive blocks thereby making it
> even easier to read for us lowly humans (insert Bender joke here). And
> the same logic for the all-important database block! That's awesome. I
> suppose we could have any number of database definitions, each with
> their own name.
>

Yes.


>
> All-in-all, I'm digging it. I like the direction this is going. Each
> time I setup Ejabberd, I feel like a bad server admin when I turn on
> "plain". Moving to Redis should be a huge improvement. Still using
> memcached for the "other" stuff though (for now)?
>

I have not taken any steps toward replacing Memcache.  I'd like to, though,
at some point.

-b


>
> -Blake-
> Conducting Magic
> Will consume any data format
> MOBIUS
>
> On 11/4/2022 10:40 AM, Bill Erickson via Evergreen-dev 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
>
> _______________________________________________
> 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/d203f719/attachment.htm>