Or the proxy could create on demand for the user. Point of concern is long running clones - those need to be controlled and managed by some stateful process that can wake up and continue running those operations (that's in favor of a background controller).

Also, you should note that a git repo has to be scheduled onto a git backend by some process, much like pods are bound onto hosts. The simplest implementation is a loop that just assigns it to the same backend, but we'll need to be more sophisticated than that.

Point of concern is long running clones - those need to be controlled and managed by some stateful process that can wake up and continue running those operations (that's in favor of a background controller).

I'm not sure I follow this. Are you talking about a clone to provision a new repo? If so, why would that be long running? And why would a clone process need to be woken up?

Could we somehow leverage the scheduler for shard assignment?

I get clone a repo that downloads at 1k a second that is 20M. I trigger a thousand of those and crash the app server.

On Nov 14, 2014, at 12:54 PM, Andy Goldstein notifications@github.com wrote:

In openshift-pep-015-git.md:

+For token authentication, the token uniquely identifies the client and must be considered secret and equivalent to a password.
+
+For client certificate authentication, the certificate also uniquely identifies the client.
+
+Clients may be real users or service accounts. Tokens and client certificates may be revoked and regenerated by project administrators.
+
+### Git repostiory authorization
+After the proxy authenticates the client, it verifies the client is authorized to access the Git repository by querying the OpenShift master. If authorization succeeds, the proxy determines the internal URL of the Git backend (again, by asking the OpenShift master). It then forwards the request to the Git backend.
+
+### Git backend pod
+The Git backend pod runs a container capable of handling Git requests using Git's "smart HTTP" protocol. When it receives a requested forward from the proxy, it first repeats the same authentication and authorization checks as the proxy. This may be achieved via a container acting as a proxy inside the Git backend pod, or in the same container that handles the smart HTTP requests.
+
+### Git repository provisioning & management
+A custom controller running in a Git backend pod watches the OpenShift master for new GitRepositories and creates a new Linux user and the appropriate directories and files for the new repository.
+
+The controller could either run in the background in the same Git backend container that is running the smart HTTP server, or it could run in a separate container that is part of the same pod, as long as the appropriate files and directories are shared between the containers (/etc/passwd and the base directory for all the git repositories, e.g. /var/lib/git).
Point of concern is long running clones - those need to be controlled and managed by some stateful process that can wake up and continue running those operations (that's in favor of a background controller).

I'm not sure I follow this. Are you talking about a clone to provision a new repo? If so, why would that be long running? And why would a clone process need to be woken up?

—
Reply to this email directly or view it on GitHub.

It would be something like that but much simpler.

On Nov 14, 2014, at 12:54 PM, Andy Goldstein notifications@github.com wrote:

In openshift-pep-015-git.md:

+For token authentication, the token uniquely identifies the client and must be considered secret and equivalent to a password.
+
+For client certificate authentication, the certificate also uniquely identifies the client.
+
+Clients may be real users or service accounts. Tokens and client certificates may be revoked and regenerated by project administrators.
+
+### Git repostiory authorization
+After the proxy authenticates the client, it verifies the client is authorized to access the Git repository by querying the OpenShift master. If authorization succeeds, the proxy determines the internal URL of the Git backend (again, by asking the OpenShift master). It then forwards the request to the Git backend.
+
+### Git backend pod
+The Git backend pod runs a container capable of handling Git requests using Git's "smart HTTP" protocol. When it receives a requested forward from the proxy, it first repeats the same authentication and authorization checks as the proxy. This may be achieved via a container acting as a proxy inside the Git backend pod, or in the same container that handles the smart HTTP requests.
+
+### Git repository provisioning & management
+A custom controller running in a Git backend pod watches the OpenShift master for new GitRepositories and creates a new Linux user and the appropriate directories and files for the new repository.
+
+The controller could either run in the background in the same Git backend container that is running the smart HTTP server, or it could run in a separate container that is part of the same pod, as long as the appropriate files and directories are shared between the containers (/etc/passwd and the base directory for all the git repositories, e.g. /var/lib/git).
Could we somehow leverage the scheduler for shard assignment?

—
Reply to this email directly or view it on GitHub.