Comments (14)
or we can simply pass the config file as argument, better than reading from stdin.
from go-libp2p-daemon.
So maybe
-o <filename>
for reading from a file, and-O
for reading from stdin.
Yeah sounds good, or -f/-i (-o sounds like output)
I'd shy away from watching the file and hot-reloading when it changes. It creates a significant security hole, and also it's not very polite. I'd propose reacting to
SIGSTOP
or another unused signal by re-loading the config file, or ignoring if we're reading from stdin.
Agree on not watching the file and handling a signal instead, but SIGHUP or SIGUSR1 are most common for reloading. I've only ever seen SIGSTOP used for log rotation (in combination with SIGCONT), I think the process doesn't even get it (same as SIGKILL).
from go-libp2p-daemon.
SIGHUP
is used for config reload for daemons (detached from a console) as a signal that the console closed doesn't make sense for daemons (go-ipfs is not a daemon in the traditional scheme). So if you are planning this I would go with SIGUSR1
.
Also, as it is a config, maybe just go with --config
flag.
from go-libp2p-daemon.
👍 i think it should be as simple as trying to read stdin, and ignoring any command line options if data exists
from go-libp2p-daemon.
See #35 for a discussion on configuration flags precisely!
from go-libp2p-daemon.
or we can simply pass the config file as argument, better than reading from stdin.
I'm good with this approach
from go-libp2p-daemon.
yeah, fine by me. makes reproducibility easier too.
from go-libp2p-daemon.
we should add, one of the motivating factors behind this was wanting to easily add lists (i.e. how we already do bootstrap nodes) and eventually add listen addresses to the configuration
from go-libp2p-daemon.
If the configuration becomes too complex to represent with flags (😢 ), consider the merits of libp2p/go-libp2p#526. If you're able to represent your configuration as a tree (explicit configuration structs with appropriate embedding), you can marshal the root of your configuration type to and from your configuration file format of choice (JSON/yaml etc.).
type Libp2pDaemonConfig struct {
Host host.Config
Dht dht.Config
SomeMultiaddrsCozWhyNot []ma.Multiaddrs
}
Ultimately lists lack the structure to represent complex configuration. Maybe nip it in the bud before it gets out of hand?
from go-libp2p-daemon.
It looks like @jacobheun already essentially suggested this, but libp2p/go-libp2p#526 does add some context. It would be unfortunate to reexport a bunch of config in other packages in this way when they could be exposing it like that already.
from go-libp2p-daemon.
interesting. the daemon ultimately has a different set of configuration options, but we are heavily leaning towards reading it from a JSON file.
from go-libp2p-daemon.
from go-libp2p-daemon.
or we can simply pass the config file as argument, better than reading from stdin.
But it'd also mean introducing a dependency on the filesystem. We'd make one-off invocations slightly more concise, but virtualization and automation more-than-slightly more involved.
But well I guess we can also have both ¯\_(ツ)_/¯
many unix tools accept a -
filename meaning stdin.
As long as we make sure not to require stuff in the filesystem (apart from the control socket obviously, but that's not something the user needs to create themselves).
Another approach not mentioned here yet is to configure the daemon over its own API.
Disclaimer: I'm not yet very familiar with the daemon, or with all the teams that already have a need for the daemon (and it offering complex functionality). That need is there right now, so it's good to make small, swift, pragmatic steps. All I'd ask is we do steps that are in line with an overall longterm design goal and don't push ourselves into a corner that we eventually don't get out of. Things that trigger me: big config structs, god objects, long lists of cli flags, (bidirectionally) leaking abstractions between UIs and "business" code :P
There'd be a command running the daemon (let's say run
), and a command starting and configuring it (let's say start
). And I guess there would also be commands reloading/stopping/killing it. start
would pass through run
's stdout and stderr, so to the user it could look much the same as it does right now.
The handling of the user interface (CLI (and config file)) would be nicely confined to one command and decoupled from the actual work. We can focus mainly on API design instead. There's probably even a named design pattern for this.
Most importantly it'd help much on the way towards hot-reloading, which I think is super-desirable for anything networking-focused. Long way to get there, but very desirable, and as we get more networky down the roadmap, networking people will expect it.
It'll require pretty hefty design and refactoring work, but if we're going to refactor Host/Swarm in Go anyway... Don't need to have 100% hot-reloading ability right away, can do it step by step.
from go-libp2p-daemon.
But it'd also mean introducing a dependency on the filesystem. We'd make one-off invocations slightly more concise, but virtualization and automation more-than-slightly more involved.
But well I guess we can also have both
¯\_(ツ)_/¯
many unix tools accept a-
filename meaning stdin.
Exactly my thoughts. I'm not sure if -
is the right interface here. I've seen it in vim -
and others that expect a filename as an CLI arg, not as an option flag. If we want to do p2pd <config file>
it should be ok, but I'm thinking we probably want to pass the config file as an option. So maybe -o <filename>
for reading from a file, and -O
for reading from stdin.
Anyway, it should be trivial to support both inputs, and agree it's the best path forward.
Most importantly it'd help much on the way towards hot-reloading, which I think is super-desirable for anything networking-focused. Long way to get there, but very desirable, and as we get more networky down the roadmap, networking people will expect it.
I'd shy away from watching the file and hot-reloading when it changes. It creates a significant security hole, and also it's not very polite. I'd propose reacting to SIGSTOP
or another unused signal by re-loading the config file, or ignoring if we're reading from stdin.
from go-libp2p-daemon.
Related Issues (20)
- Graceful shutdown
- Update build to stop using gx
- Panic on launch with gossipsub HOT 4
- Crash on daemon shutdown HOT 4
- Any instruction? Examples? HOT 1
- Print version information in help / --version HOT 1
- Cannot build xerrors on MacOS go1.13 HOT 3
- `Stream.reset`?
- Windows failure due to prometheus/client_golang HOT 1
- Missing module with go 1.12
- Howto connect to daemon HOT 6
- Remove secio usage as default connection encryption
- Running with configuration file HOT 2
- creack/pty v1.1.7 needs to be upgraded to v.1.1.11 HOT 1
- Unexpected behavior when trying to connect to bootstrap nodes HOT 11
- Usage Documentation HOT 1
- Bad error message when running p2pd with no arguments
- Listen flag is confusing
- Resurrect project by updating go-libp2p version HOT 2
- manual release created (v0.5.0)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from go-libp2p-daemon.