[FOLIO-2131] SPIKE: how to deploy containers based on feature branches Created: 01/Jul/19 Updated: 03/Jun/20 Resolved: 07/Aug/19 |
|
| Status: | Closed |
| Project: | FOLIO |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None |
| Type: | Task | Priority: | P3 |
| Reporter: | Jakub Skoczen | Assignee: | John Malconian |
| Resolution: | Done | Votes: | 0 |
| Labels: | platform-backlog | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||||||||||||||
| Sprint: | CP: sprint 69 | ||||||||||||||||||||
| Story Points: | 5 | ||||||||||||||||||||
| Development Team: | Core: Platform | ||||||||||||||||||||
| Description |
|
Wayne Schneider John Malconian mark.stacy Ian Hardy let's provide steps here and consider how/where to upload descriptors for feature builds. |
| Comments |
| Comment by Wayne Schneider [ 01/Jul/19 ] |
|
One possible approach for each PR that includes a backend dependency based on a feature branch (leaving out how to figure that out for now):
What is the scope of this issue? Is this only for feature branches of backend modules? That is, can a front-end module feature branch request one (or more) feature branches of backend modules? |
| Comment by Jakub Skoczen [ 02/Jul/19 ] |
|
Wayne Schneider I think we could make creating tenants and installing the module optional in this pipeline and rely on the front-end pipeline to do this. |
| Comment by Jakub Skoczen [ 02/Jul/19 ] |
|
Wayne Schneider John Malconian Adam Dickmeiss Since there could be potentially MANY feature branches at any given point it would be good if the CI deployment were opt-in through a setting in a configuration file (Jenkinsfile?) and off by default. E.g something like: ciDeploy = "never" | "pr" | "commit" pr would deploy the branch when a PR is issued from the branch, commit would (re)deploy on any commit to the branch. we may also consider adding: ciDeployPRTarget= name-of-the-target-pr-branch to constrain deployment only to PRs issued against a specific branch, defaulting to master probably makes sense. |
| Comment by Wayne Schneider [ 08/Jul/19 ] |
|
One issue with multiple Okapis using the same set of running modules is that unless we can guarantee that the tenant ID is unique, we will run into storage conflicts. |
| Comment by John Malconian [ 25/Jul/19 ] |
|
'ciDeployPRTarget= name-of-the-target-pr-branch' is a good idea. I'm not sure about 'ciDeploy'. We need to be clear that only PRs issued against a particular branch will create a preview environment and deploy a container for that branch. This will not work with any other branch build. We need the PR for various reasons. There is no need to do anything special for additional commits against the branch that has an open PR. Any new commits to this branch will redeploy a new container into the same preview environment. Not sure of the mechanics of this yet, but that's how it should work. Here's how I envision this on the kubernetes side: When a PR is created, a new namespace is created in the cluster. A docker image is built and container deployed to the namespace in the cluster as part of the build pipeline. We'll probably want a local docker repo in the cluster and not use Docker Hub for these images. For the PR preview, we can either deploy a local okapi instance to the PR namespace or use an okapi running in the primary folio namespace. Either way, we'll need to create virtual service definitions that allow us to access services in other namespaces using the 'ExternalName' service type which is essentially a local namespace alias to a service that resides in a different namespace. If we use a local okapi instance, then we would need to create a service definition for each module that resides in the primary folio namespace so that the local namespace okapi can access each module running outside the PR preview namespace. The service alias would be used by Okapi's discovery. Advantages to using a local namespace okapi:
Disadvantages:
On the other hand, we could create a service alias in the preview namespace that points to a dedicated okapi instance in the primary folio namespace instead. The advantages of this approach would be:
Disadvantages:
When the PR is closed the namespace all associated services associated with that namespace are destroyed. |