<div dir="ltr"><div>Inline...</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 4, 2022 at 12:15 PM Blake Henderson via Evergreen-dev <<a href="mailto:evergreen-dev@list.evergreen-ils.org" target="_blank">evergreen-dev@list.evergreen-ils.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Bill,<br>
<br>
I think our opensrf.xml file has several places that need attention. I'm <br>
glad you're taking it on! I support the move to yaml over xml for much <br>
the same reasons you've stated. </blockquote><div><br></div><div>Great!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It's easier to read but it is *very* <br>
sensitive to spaces. </blockquote><div><br></div><div>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If I'm understanding this right, "service-defaults" <br>
definition will fill in blanks for any of the open-ils services when <br>
they are omitted in their specific definition block? </blockquote><div><br></div><div>Yes.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I think that's <br>
brilliant because it cuts back on repetitive blocks thereby making it <br>
even easier to read for us lowly humans (insert Bender joke here). And <br>
the same logic for the all-important database block! That's awesome. I <br>
suppose we could have any number of database definitions, each with <br>
their own name.<br></blockquote><div><br></div><div>Yes.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
All-in-all, I'm digging it. I like the direction this is going. Each <br>
time I setup Ejabberd, I feel like a bad server admin when I turn on <br>
"plain". Moving to Redis should be a huge improvement. Still using <br>
memcached for the "other" stuff though (for now)?<br></blockquote><div><br></div><div>I have not taken any steps toward replacing Memcache.  I'd like to, though, at some point.  </div><div><br></div><div>-b</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-Blake-<br>
Conducting Magic<br>
Will consume any data format<br>
MOBIUS<br>
<br>
On 11/4/2022 10:40 AM, Bill Erickson via Evergreen-dev wrote:<br>
> Hi Devs,<br>
><br>
> Some background:<br>
><br>
> Some may recall my Redis demo at the last EG conference. In the <br>
> session, I proposed deprecating the OpenSRF router. The discussion <br>
> continued, particularly with Mike R. and Galen, where we discussed <br>
> retaining support for multi-domain routing for high <br>
> availability setups.  (Think restarting a service on one domain/brick <br>
> and having requests to said service get routed to another domain/brick <br>
> via the Router).<br>
><br>
> Skip ahead, I've started working on code to implement multi-domain <br>
> support in my Redis branch, but quickly found the existing <br>
> opensrf_core.xml file to be less than ideal with respect to defining <br>
> which services run on which domains, among other things.<br>
><br>
> Maybe this is an opportunity to change the configuration file format?  <br>
> As an experiment I put together a sample of what made sense to me:<br>
><br>
> <a href="https://github.com/berick/OpenSRF/blob/user/berick/lpxxx-redisrf-streams-v3/examples/opensrf.yml.example" rel="noreferrer" target="_blank">https://github.com/berick/OpenSRF/blob/user/berick/lpxxx-redisrf-streams-v3/examples/opensrf.yml.example</a><br>
><br>
> [I used YAML because I find it tidy and flexible.  I'm more concerned <br>
> about the configuration structure than the file type, so we could <br>
> continue using XML or something else, but for my part YAML is superior.]<br>
><br>
> One key difference is that the message bus / connection section is <br>
> separated into reusable chunks:<br>
><br>
> 1. Routable domains<br>
> 2. Message bus credentials<br>
> 3. Connection types.<br>
>   -- These link credentials with logging configs.<br>
><br>
> At runtime, clients/services link a domain with a connection type to <br>
> derive the bus connection information.<br>
><br>
> Other benefits of the modified structure:<br>
><br>
> * Services are collected into named groups and linked to domains <br>
> instead of routers.<br>
> * Support for other named configuration chunks.  E.g. create a named <br>
> database setup that can be referenced from the cstore, storage, <br>
> reporter-store, etc. configurations.  Less duplication.<br>
> * One file format for standalone OpenSRF clients, gateways, and <br>
> services.  The file just contains less stuff for clients that don't <br>
> need the full data set -- or not, either works.<br>
> * Custom connection types for ad-hoc scripts, etc. so they don't <br>
> require their own config file.<br>
><br>
> And last but not least, the changes work much better for my Redis <br>
> branch, where we have to be more explicit with our bus domains and <br>
> their behavior for multi-domain support.<br>
><br>
> One thing not included in the sample are host-specific setups, where a <br>
> "brick" contains multiple hosts, some running different services than <br>
> others.  This could be added, but I wasn't sure if that was still a <br>
> common use case.<br>
><br>
> Thoughts?  Other config wishlist items?<br>
><br>
> Thanks for reading!<br>
><br>
> -b<br>
><br>
><br>
><br>
> _______________________________________________<br>
> Evergreen-dev mailing list<br>
> <a href="mailto:Evergreen-dev@list.evergreen-ils.org" target="_blank">Evergreen-dev@list.evergreen-ils.org</a><br>
> <a href="http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-dev" rel="noreferrer" target="_blank">http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-dev</a><br>
<br>
_______________________________________________<br>
Evergreen-dev mailing list<br>
<a href="mailto:Evergreen-dev@list.evergreen-ils.org" target="_blank">Evergreen-dev@list.evergreen-ils.org</a><br>
<a href="http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-dev" rel="noreferrer" target="_blank">http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-dev</a><br>
</blockquote></div></div>