deis / registry-proxy

Deis Workflow Registry Proxy

	Deis Workflow is no longer maintained. Please read the announcement for more detail.
09/07/2017	Deis Workflow v2.18 final release before entering maintenance mode
03/01/2018	End of Workflow maintenance: critical patches no longer merged
	Hephy is a fork of Workflow that is actively developed and accepts code contributions.

Deis Registry Proxy

Deis (pronounced DAY-iss) Workflow is an open source Platform as a Service (PaaS) that adds a developer-friendly layer to any Kubernetes cluster, making it easy to deploy and manage applications on your own servers.

For more information about the Deis Workflow, please visit the main project page at https://github.com/deis/workflow.

We welcome your input! If you have feedback, please submit an issue. If you'd like to participate in development, please read the "Development" section below and submit a pull request.

About

registry-proxy is a proxy deployed on every Kubernetes worker node, proxying all requests to the Deis Workflow registry. This allows the worker nodes' Docker daemons to communicate to the registry over localhost, bypassing the need for adding the --insecure-registry flag to the daemons.

Development

The Deis project welcomes contributions from all developers. The high level process for development matches many other open source projects. See below for an outline.

• Fork this repository
• Make your changes
• Submit a pull request (PR) to this repository with your changes, and unit tests whenever possible.
  • If your PR fixes any issues, make sure you write fixes #1234 in your PR description (where #1234 is the number of the issue you're closing)
• The Deis core contributors will review your code. After each of them sign off on your code, they'll label your PR with LGTM1 and LGTM2 (respectively). Once that happens, the contributors will merge it

Testing Your Code

When you've built your new feature or fixed a bug, make sure you've added appropriate unit tests and run make test to ensure your code works properly.

registry-proxy's Issues

Why does this have to be a DaemonSet?

I figure that the way the builder is communicating with the registry proxy is via some sort of on-the-same-host logic, right? If that is the reason, couldn't pod affinities be used to schedule them on the same host?

Connection Refused on 2 e2e tests

scheduler.KubeException: Error while pulling image: Get http://localhost:5555/v1/repositories/test-265842571/images: dial tcp 127.0.0.1:5555: connection refused

Happened on 2 tests:

• Deis Workflow.deis healthchecks with an existing user who owns an existing app that has already been deployed that user can set an exec readiness healthcheck
• Deis Workflow.deis builds with an existing user who owns an existing app that has not been deployed that user can create multiple builds of that app with DEPLOY_BATCHES set to 5

https://ci.deis.io/job/workflow-test-pr/4353/artifact/4353/logs/deis-controller-2807243241-ssx08.log

https://ci.deis.io/job/workflow-test-pr/4353/

Going to run the suite again just to see how flakey that is

add to workflow-dev chart

In order to integrate this into Deis Workflow, we need to add this component to the workflow-dev chart.

cut v1.1.0

Changes since last release: v1.0.0...master

weird malformed URL requests during e2e runs

https://gist.github.com/bacongobbler/58bcb06941f0536e1fe2adf30533a53e