"Each service should be consuming the parameters set in the deployment.cfg at runtime. You shouldn't need to redeploy to modify those values." What I meant by "deploy-time" was that the server is started with a certain configuration, and once started the configuration is static… as you say, I'd like to set the configuration when I call a method in the service. "There are already some services whose command line scripts take a url argument" Absolutely. For example, all methods in the FBA service take a "wsurl" argument that lets the user specify which workspace they want to use when running their command. And it works very nicely… and it proves the principle. What I'm proposing is to have that formalized, scaled up, and applied KBase wide. On Jun 20, 2013, at 12:00 AM, Dan Olson <[email protected]> wrote:

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