deis / router

Edge router for Deis Workflow
https://deis.com
MIT License
80 stars 57 forks source link

feat(charts): Add helm charts for the router #271

Closed kmala closed 8 years ago

helgi commented 8 years ago

Do you want to ditch the manifests dir now or when we have fully moved over?

kmala commented 8 years ago

I will remove it after merging this and ci job to publish the charts along with updating the readme file.

helgi commented 8 years ago

Giving it 👍 as long as you are sure this is up to date with the current charts :)

codecov-io commented 8 years ago

Current coverage is 55.11% (diff: 100%)

Merging #271 into master will not change coverage

@@             master       #271   diff @@
==========================================
  Files             6          6          
  Lines           381        381          
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
  Hits            210        210          
  Misses          151        151          
  Partials         20         20          

Powered by Codecov. Last update 5c0042f...0241013

krancour commented 8 years ago

@kmala-- this looks pretty good. I have just a couple questions.

  1. Is the idea (in general), that each Workflow component will have its own chart sourced embedded within its own repo? Will the Workflow chart reference each of these as dependencies? If that's the case, I think I really like this. 😄
  2. What's the workflow for deploying the router's chart? I imagine each time we tag a release, we want packaging and uploading of the chart to be automatic, right? That doesn't seem to be accounted for here.
  3. @helgi mentioned getting rid of the /manifests directory soon. That would be great. When that happens, what's the new workflow for a contributor who has (more than likely) installed all of Workflow into a cluster and now wishes to replace just the router component with a custom build? (i.e. You've helm installed Workflow and that has resulted in a Workflow release in your cluster, but to hack on router, you want to replace a few discrete pieces of that Workflow release. I'm not sure how that is accomplished.)
kmala commented 8 years ago
  1. Is the idea (in general), that each Workflow component will have its own chart sourced embedded within its own repo? Will the Workflow chart reference each of these as dependencies?

yes, each will be in its own repo and workflow will add these add dependencies.

2.What's the workflow for deploying the router's chart? I imagine each time we tag a release, we want packaging and uploading of the chart to be automatic, right?

if you want just router you can helm install charts.deis.com/router-<version> or you install workflow and the router will be part of it. Tagging a new release will automatically package and upload the chart which will doe through our CI(I am working on it).

3.What's the new workflow for a contributor who has (more than likely) installed all of Workflow into a cluster and now wishes to replace just the router component with a custom build?

Currently, you either hack on the manifest through kubectl or install a new workflow with the latest router.But i would want something like helm upgrade <workflow-release-name> <dependency-name> <chart of the dependency> to happen and i am discussing with helm team for this use case.

You can see more details on how everything should work here https://github.com/deis/charts/issues/350#issuecomment-251587320

krancour commented 8 years ago

if you want just router you can helm install charts.deis.com/router- or you install workflow and the router will be part of it. Tagging a new release will automatically package and upload the chart which will doe through our CI(I am working on it).

Sorry... I need to restate my question more clearly...

What is the process for taking the chart sources from this repo, archiving them, and uploading them to a repository? Ideally, what is the process for doing this automatically when a router release gets tagged in github?

But i would want something like helm upgrade to happen and i am discussing with helm team for this use case.

👍 I think that's a valid use case. I want to update a dependency of another chart without updating the whole thing. Cool.

kmala commented 8 years ago

When ever we tag a release there is already a job which runs to verify the image and push it to the deis org with the release tag, i want to add to the same job once it uploads the new image replace the org, version in the values.yaml file in the charts directory, run helm publish <router> and upload the tar.gz to our hosting directory(s3).

krancour commented 8 years ago

Ok. Cool. Should that be part of this PR? Or you want to tackle that separately?

kmala commented 8 years ago

that will be part of the our jobs infrastructure... it will be just one job for all the repos.

kmala commented 8 years ago

i will merge this PR once that has been setup.

krancour commented 8 years ago

Got it.