-
Notifications
You must be signed in to change notification settings - Fork 13
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
Overhaul deployment #155
Comments
@EvanDietzMorris @jdr0887 @YaphetKG what are your thoughts? |
There is a lot to talk about here but I thought I'd first add the most simple overview of the issue to help bring @jdr0887 up to speed on the current situation. Right now ORION starts with a graph spec yaml and creates a bunch of graphs (a neo4j dump, kgx files, and a few metadata files) and outputs a list of the graph ids and new versions it just built that looks like: I have a script that takes that list and moves over all the files to our publicly exposed directory on stars and spits out all the values that would go into the helm charts, like this: Right now, I have to copy and paste those values into the existing helm charts. It would be easy to write a script to overwrite the helm chart values files with those, but currently the helm charts are named something different than the graphs themselves so it'd be slightly more complex than generating file paths with the graph IDs. Then we deploy them all manually with helm commands (there are separate issues about how sometimes it isn't enough to do a helm upgrade, sometimes we have to full reinstall). It would be really nice if we could, in ORION, somehow specify which helm charts need to be updated and do all of this automatically, and also decouple the graphs from specific deployments, so like Chris said maybe separate files from the Graph Spec, a Deployment Spec, that could specify a number of different deployment endpoints. |
There is currently a lot of effort involved in deploying an automat. There are numerous helm charts, because each plater has its own helm chart (or at least its own values file). So there is a lot of updating of values in different places.
This was annoying but manageable in the past, but we are now moving into a situation where we want to have multiple deployments of automat, each with its own set of platers. Specifically, we will have one for robokop and one for translator. We might put, for instance, some things in the robokop U24 instance that are not appropriate for Translator. Or they may need to be on different versions for a while.
One approach that we have been considering: Creation of a deployment metadata document. This could be a simple yaml file that points at individual versioned graphs, and the minimal things that are going to change from version to versoin. Then something reads that document and templates out the relevant helm charts
The text was updated successfully, but these errors were encountered: