Open kennethmorton opened 2 years ago
Tentatively assigning this to @sarah-seitanakis but I might pick this up in the next couple of days. I think this means that when our service has x-maturity=development we should point to other services with x-maturity=development. Ditto for x-maturity=production. So on startup up there needs to be some logic that gets the right urls and makes that magic happen. Correct me if I'm wrong @kennethmorton
I actually think, that we should go the environment variable route. For a given deployment we should just set those variables correctly. The work is then to define the variables and pipe them through to all of the necessary locations. Here is one and I am sure there are others.
I actually think, that we should go the environment variable route. For a given deployment we should just set those variables correctly. The work is then to define the variables and pipe them through to all of the necessary locations. Here is one and I am sure there are others.
agree
I think these are the lines that need to be changed.
./app/server.py:104: "https://automat.renci.org/robokopkg/1.2/query", ./app/server.py:112: "https://aragorn-ranker.renci.org/1.2/omnicorp_overlay", ./app/server.py:120: "https://aragorn-ranker.renci.org/1.2/weight_correctness", ./app/server.py:128: "https://aragorn-ranker.renci.org/1.2/score", ./app/identifiers.py:11: "https://nodenormalization-sri.renci.org/1.2/get_normalized_nodes", ./app/identifiers.py:33: "https://automat.renci.org/robokopkg/1.2/meta_knowledge_graph", ./tests/test_server.py:74: "https://nodenormalization-sri.renci.org/", ./tests/test_server.py:78: "https://automat.renci.org/robokopkg/1.2/meta_knowledge_graph", ./tests/test_server.py:82: "https://automat.renci.org/robokopkg/1.2/query", ./tests/test_server.py:86: "https://aragorn-ranker.renci.org/", ./README.md:9:-e OPENAPI_SERVER_URL=http://robokop.renci.org:7092 \
This PR should take care of this: #41
Currently we hardcode the paths to difference services within the source. These need to be found via the smart-api registry and referenced by a configurable maturity, or fed in from configuration directly. I think the latter might be the best option.