Skip to content

Planning

Jump to bottom
Steven edited this page Jun 22, 2019 · 13 revisions

1. Development Steps (Beta 1)

Look and Feel Details

  • For now, let's hide these tools:
    • Annotation
    • The bar graph
  • For discussion - the visualization real estate is getting a bit cramped by the schema/graph banner and the toolbar. Are there other ways to arrange this to leave more of the view clear?

Bug Fixes

  • Formerly, when I ran the workflow-5 or workflow-4 queries (tranql/queries/*), the legend included population_of_individual_organism, chemical_substance, etc. Now, it seems to contain far fewer items and the result graph is much smaller. Haven't had a chance to investigate but are the TimeOut errors from the async module dropping answers? Maybe try w/o async.

  • When the browser window resizes, the 3D visualization does not. Change this so the force-graph component resizes smoothly to fit in the browser window as the browser window resizes.

  • Minimizing the legend sometimes leaves two minimized bars. May have to do with an interaction with schema display.

2. Deploy to Production Environment

It's time to move towards a production deployment and towards a new production environment.

Mesos

Production currently runs from a production Mesos cluster. Applications are configured via Marathon and executed in Mesos. This cluster has been up for several years.

Kubernetes (K8s)

We'll be moving production to a Kubernetes cluster.

  • Development: For local development, use Minikube. It is a Kubernetes version for the desktop.
    • If your desktop doesn't host it effectively, we can create a virtual machine.
    • See these steps for installing and using Minikube with TranQL
    • The containing directory contains the pod, deployment, service, and ingress artifacts for TranQL.
  • Production: We are configuring a local Kube cluster. That work is pending. Artifacts deployable to Minikube should be deployable to the new cluster.

Deployment Model

  • Create a Helm Chart for TranQL
  • Parameterize the chart to demonstrate
    • Ability to deploy it in a Minikube development environment with minimal resources
    • Ability to deploy it on a production Kubernetes cluster with more resources
  • Configure the tranql.renci.org reverse proxy to point to the new production deployment. Steps include:
    • Get a RENCI account
    • Get login access to the hosting machine for this NGinx server which is stars.renci.org
    • Find the tranql reverse proxy in /etc/nginx/config.d
    • Modify to point to the Kubernetes ingress for TranQL

3. Hackathon (Beta 2)

Project Structure

We currently have two copies of requirements.txt. One is at tranql/tranql. The other is at tranql/docker/tranql-base. The second one should be replaced by a link to the first.

  • Create a symbolic link in the repo from the docker tree to the tranql source code for requirements.txt. See this discussion for reference.

Query Management and Help

  1. It's virtually impossible for a new user to make sense of the application at this point. They have neither documentation nor examples to follow. To remedy this:
  • Create a corpus of ten example queries of increasing complexity.
  • Each should have a substantial comment to explain what the query is doing.
  • Provide a tool or other trigger for displaying a list of example queries.
  • Selecting a query in the list should populate the query editor with the text of the query.

  1. Save the state of the query in the query editor in the cache.

  2. Allow the user to review all cached queries. Selecting one should populate the query editor.

  3. Add the ability to minimize the query editor (as we can with the legend).

  4. Provide a link to documentation

Continuous Deployment

  • Create a Jenkins Job to automate querying the TranQL API
  • Verify each query produces the expected answers

Merge Answers

  • Examine the answers component of a knowledge graph. This is the element that binds nodes and edges in the question to values returned in the knowledge_graph.
  • Merge answers from multiple reasoners.
    • This means creating the union of answers from generated sub-questions.
    • For schema based questions, it's more complicated. The portion of the original question (node/edge) must be matched to the content of the answer.
    • Create unit tests to verify schema merge works as expected.

Extended Unified Schema Query

Use TranQL's schema mechanism to address all existing KGS compliant reasoners.

We can currently invoke Robokop and ICEES. The next step is to invoke additional reasoners conforming to the KGS spec. These include Indigo and RTX. See the API registry for details on their APIs. Tasks include:

  • Locate the schema URL for each
  • Create sample requests establishing KGS compliance
  • Create a TranQL backplane endpoint for each managing version incompatibilities.
  • Test direct queries to each backplane endpoint (indigo, rtx).
  • Test incorporation of each reasoner into a schema based query.

TangeReasoner

Clone this wiki locally