<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">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>