search

CodeForPhilly / ops

File an issue here to deploy an application or create a new repo
3 stars 4 forks source link

Propagate container updates #7

Closed lottspot closed 6 years ago

lottspot commented 7 years ago

Project owners need to be able to tell the cluster that a new version of their container is available without the intervention of a cluster administrator.

lottspot commented 7 years ago

The best solution for this will involve providing project-specific API keys which are permitted to perform API operations on their own containers.

lottspot commented 7 years ago

This should be simple enough to do if we deploy each project into its own namespace-- the difficulty comes with the fact that the apiserver doesn't appear to be running any authorization modules right now. So we'll have to turn one of those on before we can go anywhere with this.

lottspot commented 7 years ago

Due to the lack of authorization control on the alpha cluster, we aren't going to be hitting this target for our alpha phase.

themightychris commented 7 years ago

What if instead of something transactional like an API call, it was a declarative push to a git repo? That gives us auth, audibility, revertability...

The cluster can just be hooked up to hooks in the repo so when someone with write access pushes a change or something without gets a pull request merged by someone who does, the declared new version gets deployed

lottspot commented 7 years ago

Yeah I think if all project releases travel through PRs to this repo, we can easily work out something reasonable. I still don't consider this issue a blocker though; we can deploy projects manually until we work out a CD pipeline that we like.