bringup adhoc stack instance for PR code builds

[kbsingh]

can the kompose tool be used to bringup adhoc app instances when PR builds succeed ?

we would need to limit it somewhere( at most 6 instances ? ), and the app would need to get reaped after a specified amount of time ( 12 hrs ? )

At the very least, we would need the kompose tool to create a route and allocate hostname to the UI and API ( ref: kubernetes/kompose#140 ), and we would need to setup a new account in openshift cluster that has a policy to terminate and reclaim all resources from apps after a specified amount of time.

cc: @kadel

[kadel]

Kompose is just tool for deploying/converting docker-compose.yml to OpenShift/Kubernetes.
Technical it can be used to deploy whatever as long as it is in docker-compose.yml.
But reaping is out of scope for Kompose, something else should take care of that.

[kbsingh]

the reaper would run from the openshift admin side against the user, it wont have anything to do with the deploy piece.

[kbsingh]

@kadel and I had a chat around the workflow for what this might look like and how it might work. We've got a map of the process, beyond the code build stages, that looks like this :

The Jenkins -> Build -> Test phase needs to be fleshed out a bit. Once we have the process beyond that ( ie, once the container is in the registry ), we will work back on howto influence the tag's for the container push based on the PR being currently evaluated.

cc: @kwk

[maxandersen]

It says "Per PR Tag" and <api/core- in another place - are these not simply the same ?

so if PR 25 is in UI it will result in almighty-ui-PR25.almighty.io ?

[aslakknutsen]

@maxandersen Yes, they are just in different systems. "Per PR Tag" would be the Tag in the DockerRegistry, which 'map' to a set of containers deployed in OpenShift and exposed via URL xxxx .. ?

[aslakknutsen]

I would suggest we set the timeout a lot longer than 48h. Would be nice if it followed the lifecycle of the PR. We could always comment on the PR [test] to force a redeploy I assume if it got garbage collected, but.

One use case from Core's perspective would be;

• Core delivers a feature that is in review (PR)
• UI starts work on the UI part and can simply point the UI to the backend PR exposed URL to see the changes before it goes into master.

The development time around 'most' features that would benefit from this type of setup would probably last for more than 10h in a 2day period.

[kbsingh]

@aslakknutsen initially we will work without this timeout - and see what sort of resource usage we ramp up - there is a fair bit of capacity dedicated to Almighty, so we might be able to live with a week or find a way to tear-down on PR teardown ( either merged, closed, rejected etc ).

[kbsingh]

http://ui-157.pr.almighty.io/ is an example ( run manually )

[kbsingh]

DNS work to get *.pr.almighty.io pointing at the service load balancer is also done

[kwk]

Hi @kbsingh . Great stuff!

[baijum]

@kbsingh This is great!

Is there anything pending for Core?

[vpavlin]

What is the status of this? Is it solved by using badger for PR deployments? Like in fabric8-ui/fabric8-ui#1844 (comment)

[maorfr]

closing due to coming deprecation of this repository (see README).