<div dir="ltr">Since we have potential plans for the contents of opensrf.xml, I'll set that aside for now. That simplifies the discussion quite a bit.<div><br></div><div>Just looking at opensrf_core.xml, then a YAML version that supports current OpenSRF and a potential Redis-based future might look something like:</div><div><br></div><div><a href="https://github.com/berick/OpenSRF/blob/user/berick/lpxxx-redisrf-streams-v3/examples/opensrf_core.yml.example">https://github.com/berick/OpenSRF/blob/user/berick/lpxxx-redisrf-streams-v3/examples/opensrf_core.yml.example</a><br></div><div><br></div><div>* Codify public vs. private subdomains. This is explicit in the install docs. Making it explicit in the configs offers clarity and simplifies some things. </div><div>* Link specific hosts to domains. </div><div> ** We need to know both the specific hostname (for running services) and its domain or some way to derive one from the other. </div><div> ** One alternative to listing every host would be to pass both a domain name and a hostname (or --localhost) to osrf_control during startup. <br></div><div> ** Another alternative would be a way to specify a default domain to use for clients connecting "here". This is closer to how opensrf_core.xml works now, but requires different configs per brick.</div><div> ** A combo of the above could also work.</div><div>* Instead of specifying which services run on which subdomains (as in my previous example), specify which services are permitted to register with the router on each subdomain. Which services actually run on a given host are still controlled by the settings server.<br></div><div><br></div><div>I'm still experimenting, and thinking out loud, so this may evolve. Thoughts appreciated.</div><div><br></div><div>-b</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Nov 5, 2022 at 1:09 PM Bill Erickson <<a href="mailto:berickxx@gmail.com">berickxx@gmail.com</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"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 4, 2022 at 5:46 PM Mike Rylander <<a href="mailto:mrylander@gmail.com" target="_blank">mrylander@gmail.com</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">On Fri, Nov 4, 2022 at 1:47 PM Bill Erickson <<a href="mailto:berickxx@gmail.com" target="_blank">berickxx@gmail.com</a>> wrote:<br>
><br>
> On Fri, Nov 4, 2022 at 1:23 PM Mike Rylander <<a href="mailto:mrylander@gmail.com" target="_blank">mrylander@gmail.com</a>> wrote:<br>
>><br>
>> Hi Bill,<br>
>><br>
>> First, thanks for moving this forward!<br>
>><br>
>> (unfortunately?) Right off the bat, I'm /really/ not liking the idea<br>
>> of merging application settings (opensrf.xml) into initial connection<br>
>> settings (opensrf_core.xml). If anything, I'd prefer to see the<br>
>> application settings move farther away from the file system, somehow,<br>
>> rather than have to spray that info all over the place -- right now<br>
>> application config only /has/ to be colocated with the<br>
>> opensrf.settings app, but it looks like this would require it<br>
>> everywhere and in potentially only-very-slightly-different files<br>
>> (differences of service assigned, or service settings, per host) that<br>
>> would be difficult to troubleshoot.<br>
><br>
><br>
> Not exactly. I didn't dig into this too much in my previous message, but the idea was to support a single file structure, without necessarily requiring a single file.<br>
><br>
<br>
Hrm... maybe I'm misunderstanding, sorry if that's the case. Let me<br>
try to explain my thought process, concerns, and desires.<br>
<br>
After my first reading of your original message, I thought you were<br>
basically only talking about yaml-izing opensrf_core.xml. I'm fully<br>
on board with making that smarter (reusable chunks, etc) and like you<br>
I don't care much what the format is in the long run. And, FTR, I'm<br>
fully on board with making opensrf.xml smarter, or more dynamic, or<br>
non-existent (as a filesystem object).<br></blockquote><div><br></div><div>That was the original goal. It quickly started evolving...</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>
But then I saw Blake's response that mentioned service defaults, and<br>
looked at your linked example more closely, and that's when I came<br>
away with the impression that you may /also/ be wanting to embed the<br>
application config (what opensrf.settings reads and then distributes<br>
to applications) in the connection config file /for the services to<br>
look at directly/. Is that correct?<br></blockquote><div><br></div><div>Embed, yes. Look at directly, no. More below.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
My fervent hope is that we retain the separation of concerns that the<br>
two files embody today. Right now, we just tell things how to connect<br>
to the opensrf network via opensrf_core.xml, and then they ask the<br>
opensrf.settings service for their config data. I promise that's not<br>
just an idle desire! Because there are two "layers" (for lack of a<br>
better term) of configuration, and human error is unfortunately still<br>
a thing, it increases the risk that things will become broken in a<br>
complicated environment when All The Things live in just one place,<br>
instead of dedicated (and tool-enrobed) locations for different<br>
configuration concerns and targets.<br>
<br>
To expand a little on my mention of opensrf.xml above, eventually I<br>
would like to see the opensrf.settings service stop getting it's<br>
pile-o-data from opensrf.xml (or any file, for that matter) and<br>
instead read it from a structured data store. Maybe a full-on<br>
database, maybe a simple persistent document store, but something more<br>
machine-actionable than a file that a human edits and SCP's around.<br></blockquote><div><br></div><div>This. As I'm reviewing the stock opensrf.xml file, I keep asking myself why so much of this stuff isn't stored in global flags, org settings, etc. (Of course, it's just easier to change a config file than create a database upgrade script with INSERTs, etc.). I'm fully on board with moving as much of opensrf.xml as we can into a structured data store.</div><div><br></div><div>In a world... where OpenSRF relies on Redis, for example, persistent storage is an option with a lot of controls about what/when gets stored. This would be one way to do it w/o requiring, say, Postgres to run OpenSRF.</div><div><br></div><div>(At the risk of fully derailing the conversation, I'd actually be fine with OSRF requiring PG or, for that matter, merging into Evergreen. That's a substantial can of worms, though).</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>
Put another way, I don't want services to read a local file for<br>
anything other than initial bootstrapping. If we do without even a<br>
bootstrap config file and just have command line parameters, all the<br>
better. I don't see a way to do that right now, though.<br>
<br>
BUT WAIT!<br>
<br>
That all looks pretty negative, so let me offer a counter to myself.<br>
<br>
If what you meant (and what I misunderstood) was that opensrf.xml<br>
could/would eventually turn into a yaml file which would have mutually<br>
exclusive structural sections from opensrf_core.yml, and<br>
opensrf.settings could be /actively/ told to read a yaml file that<br>
just happens to be the same file on disk for both bootstrap and<br>
settings data purposes (or, I guess, be pointed to a section?) --<br>
meaning, opensrf.settings would just look at different parts of the<br>
file for each purpose and other services would just ignore all of the<br>
non-bootstrap parts, and not try to use them directly without going to<br>
the settings service -- then I retract my concerns.<br></blockquote><div><br></div><div>Yes, that! I didn't mean to suggest we deprecate opensrf.settings or point services directly at the service configuration part of the file. I just like the idea of having one config file structure that can cover every purpose.</div><div><br></div><div>Thanks!</div><div> </div><div>-b</div><div><br></div><div><br></div></div></div>
</blockquote></div>