Each service should be consuming the parameters set in the deployment.cfg at runtime. You shouldn't need to redeploy to modify those values. That being said, we should have a standard for specifying an alternate endpoint at the time you invoke a method. There are already some services whose command line scripts take a url argument, but that may be too simple for something that invokes multiple methods accessing multiple endpoints. ----- Original Message -----
From: "Christopher Henry" <[email protected]> To: [email protected] Sent: Wednesday, June 19, 2013 11:44:17 PM Subject: [Kbase-core] Server URLs should not be set at deploy
I'm growing increasingly concerned about the fact that we're setting the server inter-connects at deploy time instead of run-time.
It's making deploy complex, and it's really reducing the flexibility we could have with our system infrastructure.
I see two alternative options:
Every API command takes a "configuration" has as optional input: { workspace_url => "http//kbase.us/services/workspace" fba_url => "http//kbase.us/services/fba" etc…. }
There would be a default "production" config, but this would allow users to build their own custom config for use with development servers for example.
Alternative option:
We have a single "configuration" store where configurations like the one above can be generated and stored behind user-specified names. Then when I call a server command, I can tell it which "configuration" I'm using. It will talk to the config store and pull the URLs out of there.
Just throwing it out there… not sure if this is what we have in mind with the service registry… but it's worth thinking about. Where this becomes really important is when you're working with an outside group to build a new service that interfaces with many other services… because then you may have to coordinate multiple development servers… and it gets tough.
Chris
_______________________________________________ Kbase-core mailing list [email protected] https://lists.kbase.us/mailman/listinfo/kbase-core