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. It's easier to read but it is *very*
sensitive to spaces. 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? 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.
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)?
-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
[email protected]
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-dev
_______________________________________________
Evergreen-dev mailing list
[email protected]
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-dev
