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: [email protected] personal: [email protected] https://equinoxOLI.org On Fri, Nov 4, 2022 at 11:40 AM Bill Erickson via Evergreen-dev <[email protected]> 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
