peach-dynds-client sharing data with peach-web #7

New Issue

2021-05-04T09:16:12Z

mhfowler commented

2021-05-04 09:16:12 +00:00

(Migrated from github.com)

was thinking through peach-dynds-client, and how it interacts with the datastore. here are my thoughts, to start a conversation from:

peach-dyndns-client
... runs every 5 minutes and makes a curl request to peach-dyndns-server providing the new IP, the domain, and the secret... but where does it read these last two values from?

A: from a datastore, the same datastore which peach-web reads and writes from (sled or sqlite via diesel or a yaml file)
B: from its own yaml file? or from its own systemd file? or from a .env file?

my initial feeling is A makes the most sense. the database becomes something which multiple processes share and communicate through.

as we discussed earlier, it could be nice if the main settings configuration/database is just a yaml, as its human editable and readable.

if we use https://github.com/dtolnay/serde-yaml, then it looks like the yaml could still be strongly typed.

perhaps reading and writing to the peach-settings yaml, could also be a part of peach-lib, so that multiple processes can use it if needed

sqlite is more extensible in the future. but maybe if its mostly key-values as is the case for peach-dyndns-client (externaldomain, dynamicdomain, ip, secret) then yaml is sufficient

was thinking through peach-dynds-client, and how it interacts with the datastore. here are my thoughts, to start a conversation from: peach-dyndns-client ... runs every 5 minutes and makes a curl request to peach-dyndns-server providing the new IP, the domain, and the secret... but where does it read these last two values from? - A: from a datastore, the same datastore which peach-web reads and writes from (sled or sqlite via diesel or a yaml file) - B: from its own yaml file? or from its own systemd file? or from a .env file? my initial feeling is A makes the most sense. the database becomes something which multiple processes share and communicate through. as we discussed earlier, it could be nice if the main settings configuration/database is just a yaml, as its human editable and readable. if we use https://github.com/dtolnay/serde-yaml, then it looks like the yaml could still be strongly typed. perhaps reading and writing to the peach-settings yaml, could also be a part of peach-lib, so that multiple processes can use it if needed sqlite is more extensible in the future. but maybe if its mostly key-values as is the case for peach-dyndns-client (externaldomain, dynamicdomain, ip, secret) then yaml is sufficient

👍 1

mhfowler commented

2021-05-04 09:16:20 +00:00

(Migrated from github.com)

@mycognosist

mhfowler commented

2021-05-21 06:51:39 +00:00

(Migrated from github.com)

had one more thought which makes me lean towards just making the jump to use sqlite

it could be nice if the cronjob that runs nsupdate and keeps the dynamic dns IP up to date logged its result somewhere, with these three fields: time (time that it ran), success (did the peach-dyndns-server return a success message), msg (if there was an error what was the message)

then somewhere in peach-web it would be pretty easy to have a status indicator showing that peach-dyndns is working (just check this value, if the time is < 10 minutes ago, the value is success then green light)

of course we can do this without sqlite, but again getting the feeling if there are multiple processes on the peachcloud all communicating to s omedegree, maybe just reading and writing from the same database, with a single ORM implemented in peach-lib which they all share, might be a nice organized way to do this, instead of having a separate file and format for every type of data and configuration hmm

had one more thought which makes me lean towards just making the jump to use sqlite it could be nice if the cronjob that runs nsupdate and keeps the dynamic dns IP up to date logged its result somewhere, with these three fields: time (time that it ran), success (did the peach-dyndns-server return a success message), msg (if there was an error what was the message) then somewhere in peach-web it would be pretty easy to have a status indicator showing that peach-dyndns is working (just check this value, if the time is < 10 minutes ago, the value is success then green light) of course we can do this without sqlite, but again getting the feeling if there are multiple processes on the peachcloud all communicating to s omedegree, maybe just reading and writing from the same database, with a single ORM implemented in peach-lib which they all share, might be a nice organized way to do this, instead of having a separate file and format for every type of data and configuration hmm

👍 1

mhfowler commented

2021-05-21 06:54:07 +00:00

(Migrated from github.com)

and if there are multiple processes writing data, it will probably save us a headache to have something which is built to support concurrency. if multiple processes are all writing to the same yaml file I wonder if there could be occasional random collisions

mycognosist commented

2021-05-21 07:17:03 +00:00

(Migrated from github.com)

@mhfowler

I agree with your instinct to switch to using SQLite and like the approach of exposing that functionality through peach-lib. +1 to collapsing complexity into a single database which is well-known and concurrency-friendly (also makes back-ups a little less brittle).

If we really want to expose a humyn-readable / editable configuration in the future, we could always have a YAML file which is written to SQLite in the background (so that the config file is just an interface). Though I guess my feeling is that it would be simpler to receive this input through the web interface and write straight to the DB.

then somewhere in peach-web it would be pretty easy to have a status indicator showing that peach-dyndns is working (just check this value, if the time is < 10 minutes ago, the value is success then green light)

Super rad!

@mhfowler I agree with your instinct to switch to using SQLite and like the approach of exposing that functionality through `peach-lib`. +1 to collapsing complexity into a single database which is well-known and concurrency-friendly (also makes back-ups a little less brittle). If we really want to expose a humyn-readable / editable configuration in the future, we could always have a `YAML` file which is written to SQLite in the background (so that the config file is just an interface). Though I guess my feeling is that it would be simpler to receive this input through the web interface and write straight to the DB. > then somewhere in peach-web it would be pretty easy to have a status indicator showing that peach-dyndns is working (just check this value, if the time is < 10 minutes ago, the value is success then green light) Super rad!

Sign in to join this conversation.