Allow "deis create" to supply a namespace

[Cryptophobia]

From @chicagozer on May 5, 2016 23:43

I would like to be able to assign a kubernetes namespace when I use deis create. It appears that the namespace is always derived from the application name.

The advantage would be to allow me to run separate environments in the same cluster (uat, dev, stage, etc).

Copied from original issue: deis/controller#710

[Cryptophobia]

From @bacongobbler on May 6, 2016 14:45

related: deis/deis#4173 (the idea being that deploying an app into a team changes the namespace)

[Cryptophobia]

From @krancour on May 6, 2016 15:37

The advantage would be to allow me to run separate environments in the same cluster (uat, dev, stage, etc).

@chicagozer, does this imply you might want the same application name to exist in multiple namespaces? e.g. dev/foo and staging/foo?

[Cryptophobia]

From @chicagozer on May 6, 2016 22:38

Yes - I would like to have the same app name in different namespaces.This way we can promote to production through the same cluster.

[Cryptophobia]

From @krancour on May 9, 2016 1:15

I believe having the same app name exist in multiple namespaces would be quite problematic.

First consider all the ambiguity that would be introduced by allowing two apps with the same name to exist. When you say deis <some command> -a foo, which "foo" are you talking about? Staging? Production? We'd have to introduce some further mechanisms for qualifying commands such as these.

A second problem is one of routing. How would routing work in a cluster where two apps can have the same name? Does foo.example.com bring you to staging? Or production?

The easiest way to solve for this is through a pattern that many users already are applying... Create apps named like foo-staging and foo-production. Where any deis commands are concerned, which app they apply to is unambiguous because the application names are unique. The same applies to routing. The staging app can be accessed at foo-staging.example.com while production can be accessed at foo-production.example.com. The latter is an ugly name, so you would add a custom / vanity domain of foo.example.com or www.foo.com or something along those lines.

[Cryptophobia]

From @bacongobbler on May 9, 2016 1:38

First consider all the ambiguity that would be introduced by allowing two apps with the same name to exist.

With deis/deis#4173 you'd have to specify a team like "prod", which would look like deis <some command> -a foo -g prod. Think of it like github's organizations and repositories. :)

Does foo.example.com bring you to staging? Or production?

That is an interesting thought... This is starting to get off topic but I'd imaging it'd work like foo.<group>.example.com, since the group name is an organization of applications which we can reserve the application names under.

The easiest way to solve for this is through a pattern that many users already are applying... Create apps named like foo-staging and foo-production.

And yes, I agree. This is the way that users have been doing it in prod. They've also been doing deis domains:add foo --app foo-prod to ensure that the production app has the domain foo.example.com as well.

[Cryptophobia]

From @krancour on May 9, 2016 2:8

With deis/deis#4173 you'd have to specify a team like "prod"

I don't think I'd find myself a fan of that approach. "Teams" have thus far struck me as a funny way of saying roles. (imo, we should stick to the usual RBAC vernacular). I don't believe we should (quite needlessly, tbh) intertwine the otherwise separate topics of improved access control and maintaining a clear and unambiguous way to address each application (which, frankly, we already have).

I'd imaging it'd work like foo.<group>.example.com

That cannot work simply for the fact that wildcard certs cannot go more than one subdomain deep. i.e. It is not possible to obtain a cert for *.*.example.com and this would leave users needing to procure a separate *.<group>.example.com cert for each group. Besides being expensive, that adds a lot of administrative burden on users of the platform, and would also require us to completely re-imagine how we handle certificates (again)-- replacing the notion of a wildcard "platform cert" with multiple wildcard "group certs--" one per group.

[Cryptophobia]

From @jchauncey on May 9, 2016 3:0

The first solution that comes to mind is allow people to specify an environment via a flag. By default apps are in their own environment (ala namespace). Then we allow people to do --environment=staging or accounting this way they would deploy apps together that belong to the same logical unit.

Routing by default would be foo.domain.com but if you specified a environment you get foo.environment. domain.com.

We should stop treating domains as pets and instead use them as cattle because ultimately people don't deploy that many world facing apps. They usually have a few and then a ton of background apps. We need to start thinking about this type of use case.

[Cryptophobia]

From @krancour on May 9, 2016 3:35

Routing by default would be foo.domain.com but if you specified a environment you get foo.environment. domain.com.

Refer to my comments above about why that cannot be done with HTTPS. No wildcard cert could accomodate all your cattle if you want to stack them two layers deep like that (subdomain of a subdomain).

[Cryptophobia]

From @jchauncey on May 9, 2016 3:45

You would need a cert for the final domain which is how most sec guys would want you to do it anyways.

[Cryptophobia]

From @krancour on May 9, 2016 3:52

You're presuming then that users only care about HTTPS if they're using a custom / vanity domain and app.env.domain.com never needs to be secured? That doesn't sound right.

[Cryptophobia]

From @chicagozer on May 9, 2016 3:58

The main reason I asked about namespaces was going down the path of suffixing my apps with the environment names as suggested by @krancour.

When I call my apps "foo-dev, service1-dev, service2-dev" I got stuck having to append an environment when calling a sub-service from "foo". With namespaces, I can just reference "service1" and kubernetes dns will handle it.

The multi-subdomain wildcard thing isn't a showstopper for us. Understood we need a wildcard cert per env.

Having said all that, I was able to move an existing deis app into a new namespace by manipulating the manifest - seemed to work with no issues. So I have some options to implement our approach.

Thanks all for the feedback!

[Cryptophobia]

From @krancour on May 9, 2016 4:8

With namespaces, I can just reference "service1" and kubernetes dns will handle it.

Just as fyi, currently, Workflow doesn't require / presume the k8s DNS add on is installed. So while this may work for you, it couldn't necessarily work for everyone.

Also, I think your last comment exposes something that wasn't initially clear to me from your OP...

You don't only want to be able to have multiple apps woth the same name exist in different "environments" (namespaces). You also want to be able to put multiple apps in a given namespace.

The desire to do that makes total sense to me, however, it's a significant departure from how Workflow works today.

As I have understood it, Workflow is best suited to relatively simple web apps. If you are looking to deploy a more complex system that uses its own microservice architecture, then Helm may (currently) be the better choice for managing that.

[Cryptophobia]

From @blindpirate on September 8, 2016 8:31

Hi @krancour, I have met a problem that I want to limit resources used by user, but k8s's resource limitation is namespace-scoped, so I want to have one namespace per user. Is there any solution that I can put several application into one namespace (their name are unique globally)?

Thank you very much.

[Cryptophobia]

From @bacongobbler on October 11, 2016 19:37

@blindpirate not at this time.