Skip to content
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

factoring out chunks of this repo #2

Open
nsheff opened this issue Jul 24, 2020 · 3 comments
Open

factoring out chunks of this repo #2

nsheff opened this issue Jul 24, 2020 · 3 comments
Projects

Comments

@nsheff
Copy link
Contributor

nsheff commented Jul 24, 2020

The goal is to have several repos, each representing a server, which can be taken over by a community that governs the contents of that server. Generic components apply to all servers and should not live in every repo.

Right now this repo really has a several things:

  • asset_pep/ -- a PEP describing the assets for this server
  • pipeline_interfaces/ -- looper interfaces for downloading, building, and archiving . This is the connection between the PEP and refgenie.
  • config/... -- the config file representation of that PEP (output of refgenie runs)
  • task_defs/ -- the AWS image descriptions for autodeploy
  • .github/ -- github actions defined for automatic deploy

Some of these are specific to this server instance, others are generic.

specific: asset_pep, config.
generic: pipeline_interfaces, task_defs, .github

We could:

  • factor out taskdefs and .github into a generic github action that could be called from multiple repos.
  • move pipeline interfaces into a separate repo that provides everything needed for the download/build/archive steps.
@nsheff
Copy link
Contributor Author

nsheff commented Nov 17, 2020

Since the .github workflow is using more than one action, it's non-trivial to extract those into a separate action. Some day, it may be possible to construct an action from multiple other actions (I think GitHub is working on this), and we can revisit that then.

It may be possible to factor out the taskdefs, and then just check that out.

I believe refactoring the pifaces would also be possible.

@stolarczyk
Copy link
Contributor

It may be possible to factor out the taskdefs, and then just check that out.

the task definitions are not identical, actually. The hostPorts are variable:

[mstolarczyk@MichalsMBP code]: diff refgenomes.databio.org/task_defs/primary.json rg.databio.org/task_defs/dev1.json 
12c12
<           "hostPort": 85,
---
>           "hostPort": 86,
[mstolarczyk@MichalsMBP code]: diff refgenomes.databio.org/task_defs/primary.json plantref/task_defs/plant.json 
12c12
<           "hostPort": 85,
---
>           "hostPort": 84,

There's no way to dynamically populate values in the task definitions in amazon-ecs-render-task-definition action provided by AWS: aws-actions/amazon-ecs-render-task-definition#20.

We could create a populate-refgenieserver-task_def action that would store the action template, take hostPort as the parameter and populate, but that's overkill in my opinion.

@nsheff nsheff added this to Simplified Deploy in Refgenie Mar 16, 2021
@nsheff
Copy link
Contributor Author

nsheff commented Mar 16, 2021

yeah that's annoying.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Refgenie
New servers
Development

No branches or pull requests

2 participants