Inline... On Fri, Nov 4, 2022 at 12:15 PM Blake Henderson via Evergreen-dev < [email protected]> 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 > > [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 >
_______________________________________________ Evergreen-dev mailing list [email protected] http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-dev
