Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature req: Multiple STA endpoints in single GOST server instance #81

Open
justb4 opened this issue Apr 11, 2017 · 4 comments
Open

Feature req: Multiple STA endpoints in single GOST server instance #81

justb4 opened this issue Apr 11, 2017 · 4 comments

Comments

@justb4
Copy link

justb4 commented Apr 11, 2017

The STA entity model has a single global namespace. In many IoT scenario's and services like ThingSpeak it is convenient to have multiple "contexts" (users, customer, projects etc) in a single server instance. This would allow multiple small IoT projects/customers to share a single GOST instance, each with their own URL, Entity conventions, and possibly (external) authorizations.

For example GeoServer has a concept of virtual services allowing multiple OWS-endpoints within a single GeoServer instance. MapProxy has a similar concept: MultiMapProxy and with MapServer it is trivial to declare multiple (CGI-)endpoints.

With GOST we now would need multiple GOST instances, which on a single VM would mean a more complex maintenance (multiple ports, Docker Containers etc). Also we would need multiple MQTT instances and ports.

In theory I think it would be possible, while adhering to the STA-spec, to define a similar concept as GeoServer virtual services: via endpoint URLs (and MQTT Topics). For example taken endpoints ep1, ep2..epN:

  • each endpoint would have a unique URI: http://localhost:8080/ep1/v1.0, http://localhost:8080/ep2/v1.0...
  • each endpoint would have their own config (config.yaml) and database schema
  • each endpoint would have its own Dashboard
  • MQTT: each would have their own root Topic: /ep1/Datastreams(1)/Observations, /GOST/ep1/Datastreams(1)/Observations (publication) etc

Configurations could each be in a separate directory, named after the endpoint.

I hope my proposal is clear. This would make GOST much more useful over the other STA implementations. I can't estimate the impact though, but could support any effort.

@bertt
Copy link
Contributor

bertt commented Apr 12, 2017

thanks for this request :-)

We should definitely research the options for easy install/configure multiple GOST instances on a single machine.

Another thought: Maybe somewhere in the Docker tools there is support for this scenario? Seems like a common usecase (running multiple docker-compose instances of an app for different customers).

@justb4
Copy link
Author

justb4 commented Apr 13, 2017

To answer the last: I have not found Docker support for this other than running multiple daemons using supervisord but my search was not exhaustive. So in theory multiple gost instances each with their own config (port, db schema etc) and using a single HTTP proxy server (mapping /gost_<name>/ to container name/port) and database (multiple v1_<name> schema's). But then multiple Docker containers could also be done. Something to experiment, leuke stage opdracht :-).

Like said: at some point there will be a need and (with multi-endpoint) GOST will be ahead of the competition :-). Installing STA Java servers is already more complex...Early implementation has advantages. In GeoServer they implemented this (workspaces-->virtual services) quite late, and took quite some time to stabilize.

But all depends on the need from the GOST community and especially funding I realize...Let's see if we get more thumbs up :-).

@bertt
Copy link
Contributor

bertt commented Oct 10, 2017

@bertt
Copy link
Contributor

bertt commented Oct 11, 2017

see gost/docker-compose#4 for a test using docker-compose -p option

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants