Move ingress to a new repo

[bprashanth]

I've been meaning to split ingress off into its own repo but haven't had time. All ingress controllers are already modular enough to run in their own containers, and already have Godeps in the contrib/ingress/_vendor directory.

Currently we get some tooling for free in contrib (persubmit verification, munging etc) that would be nice to continue to have. It would also be good to nail down a concrete release and test plan. The latter doesn't block going to a new repo, but if we don't do it now I fear we'll just never do it.

The release plan right now is: whenever we feel like, directly in contrib/releases, and the test plan right now is: e2e in main kubernetes repo. Ideally we should at least sketch out a proposal to run e2es with ingress ToT in addition to the e2es in main repo, just like we do for cadvisor.

#762

[porridge]

I'd be happy to work on this this quarter.

[bprashanth]

Maybe link up with @aledbf and write a rough plan? I can get Tim to open the repo. See disucssion on https://groups.google.com/forum/#!topic/kubernetes-dev/fSZcq9zkI-s

The big pieces are probably:

1. tooling: presubmit runs basic verification and unittests
2. docs restructure: this definitely needs to happen, but we need to think of what would make sense at a high leve. Probably the main README shouldn't start off with: here's how you write an ingress controller
3. e2e testing: If we could figure out a way to setup an e2e builder that runs https://github.com/kubernetes/kubernetes/blob/master/test/e2e/ingress.go#L58 for every commit just like the cadvisor repo https://github.com/google/cadvisor, that would be great. I'm sure our test-infra people would be more than willing to help with this problem (file an issue like kops wants the bots - or do we kubernetes/test-infra#939, but more descriptive maybe :)
4. releases: we should at least write down how we're going to do this

We don't need to fix all of these before moving, we can simply lift and shift, but we should take this opportunity to think about how we're going to handle the issues.

We also need at least an OWNERS and CONTRIBUTING.md

[aledbf]

@bprashanth I already have:

1. tooling, tests and coverage: https://github.com/aledbf/ingress-controller/blob/master/.travis.yml
2. e2e testing
   travis starts etcd and api-server. I still need open a PR to start the ingress controller
3. Same as now? (make and changelog.md)

[bprashanth]

We need to agree on versioning (semver?) and what qualificatio one needs to perform before cutting a new release (if we have an e2e builder this will not matter as much). Also some guidelines for what to include in release notes. I'd agree with just running the basic nginx e2e (https://github.com/kubernetes/kubernetes/blob/master/test/e2e/ingress.go#L154) is a good starting block (not all on localhost, setup an actual kube-up cluster like most users will if possible), but ideally we'd find a way to test this on gce and aws as well (though those don't necessarily need to happen presubmit).

[fejta-bot]

Issues go stale after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle rotten
/remove-lifecycle stale

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close