Support multiple service registrations
Closed this issue · 5 comments
So I just wanted to start a rethinkdb container. A single rethinkdb process exposes three ports: A driver port for queries, a cluster port and a web interface.
Using three nested sdutil calls seems a bit stupid. Ideally sdutil exec would allow multiple registrations.
The question is as to the syntax, because right now, args is used to specify an arbitrary number of arguments to the command.
Options include:
- A flag (sdutil exec -s foo:999 -s bar:888 cmd) - this would be backwards incompatible.
- Comma-separated list: (sdutil exec foo:999,bar:888 cmd) - possibly would mean no commas in services.
- A separator (sdutil exec foo:999 bar:999 -- cmd) - standards-abuse, complicated interface affecting everyone.
- Detect based on existence of ":" when command starts - too brittle, magical, maybe?
Thoughts?
It might be best to think of rethinkdb as a single service (you already
do), where it exposes a primary address and then secondary addresses as
attributes. I don't believe attributes are exposed in exec, but what do you
think of that approach?
On Thu, Feb 6, 2014 at 4:48 PM, Michael Elsdörfer
notifications@github.comwrote:
So I just wanted to start a rethinkdb container. A single rethinkdb
process exposes three ports: A driver port for queries, a cluster port and
a web interface.Using three nested sdutil calls seems a bit stupid. Ideally sdutil execwould allow multiple registrations.
The question is as to the syntax, because right now, args is used to
specify an arbitrary number of arguments to the command.Options include:
- A flag (sdutil exec -s foo:999 -s bar:888 cmd) - this would be
backwards incompatible.- Comma-separated list: (sdutil exec foo:999,bar:888 cmd) - possibly
would mean no commas in services.- A separator (sdutil exec foo:999 bar:999 -- cmd) - standards-abuse,
complicated interface affecting everyone.- Detect based on existence of ":" when command starts - too brittle,
magical, maybe?Thoughts?
Reply to this email directly or view it on GitHubhttps://github.com//issues/9
.
Jeff Lindsay
http://progrium.com
Hm. I suppose that is fine when I am writing my own code to interact with service discovery (currently also hindered by the fact that rpcplus is go-specific), but what if I wanted to use existing tools - like expose the rethinkdb web interface through a proxy. Wouldn't strowger, sdutil etc. all have to be updated to support reading services from attributes?
That's fair. Registering multiple services is probably necessary, but it's
really blowing up the amount of runtime configuration you need to set up.
At this rate we might end up needing to use configuration files, which just
makes me wonder if there is a better way.
On Thu, Feb 6, 2014 at 5:05 PM, Michael Elsdörfer
notifications@github.comwrote:
Hm. I suppose that is fine when I am writing my own code to interact with
service discovery (currently also hindered by the fact that rpcplus is
go-specific), but what if I wanted to use existing tools - like expose the
rethinkdb web interface through a proxy. Wouldn't strowger, sdutil etc. all
have to be updated to support reading services from attributes?Reply to this email directly or view it on GitHubhttps://github.com//issues/9#issuecomment-34385282
.
Jeff Lindsay
http://progrium.com
I like the first option, backwards compatibility isn't a concern since there are no users yet.
I'm not sure about the "runtime configuration" aspect, I haven't worked my way up to flynn-host etc. yet. FWIW, I currently process a YAML file that says something like this:
register: {28015: "driver", 29015: "cluster", "8080": web}