Integrate app level configuration with k8s

[helgi]

Today there are two ways of affecting router configuration.  

We can separately consider global router configuration (things like are we or are we not using proxy protocol) and then router configuration that’s more at an app/vhost level.  

• The former are configured using deisctl config set router foo=bar.
• The latter are derived from each application’s model.

The former requires no action for v2. If someone wants to modify global router configuration, they can directly edit the router RC’s manifest.

What we need is for all necessary information about an application, for instance (but not limited to) custom domains, certs, or a flag indicating e2e https on/off, get mapped to appropriate k8s constructs

In most cases, that means adding/updating annotations on an app’s service and the router will read those. In other cases, it might involve something slightly more complex like managing certs as k8s secrets (secrets will be in scope for beta).

Ultimately, what this means is that how the router fulfills requests initiated from the likes of deis domains:add www.example.com or deis certs:add server.crt server.key will have to change.

[bacongobbler]

@helgi do you happen to have a checklist handy of all the resources we need to imitate in the controller for the router? I know we've tackled domains, but I guess app config like IP whitelisting and certs still need to be done.

[krancour]

@bacongobbler see annotation reference in https://github.com/deis/router#annotations

The four app-level things that can be tweaked at present are domains, connect timeout, read/write timeout, and whitelists.

[helgi]

Certificates were the only thing on my list so far - We may be able to pull Config over and use that as a way to cover for IP whitelisting and such. Shouldn't be hard if we come up with a convention (emulated deis.io/routerConfig)

I know that is a bigger scope than router but might be worth it

[krancour]

We don't need to concern ourselves with certs for alpha.

[helgi]

Agreed but I may start work on that so the workflow side of it is done before we touch the router itself

[helgi]

Removing showstopper label since this is a broader ticket

[krancour]

If this is broadening to that level, the alpha milestone on the ticket is wrong. I'm thinking we need separate issues for achieving the minimum functionality required for alpha and then anything else that's for beta and beyond.

fwiw... I just realized the controller does not need to add any support for setting timeouts, even though the router supports it. v1.x did not have this feature and the only reason I added support for this to the router itself was that it allowed me to treat the controller as "just another app." (Controller itself needed those values tweaked-- see the chart-- but does not need to manage them on other apps in order to achieve feature parity.)

https://github.com/deis/charts/blob/master/deis/manifests/deis-workflow-service.yaml#L13-L14

[krancour]

So if workflow can handle whitelists, we're in decent shape.

[bacongobbler]

yeah I imagined this was a post-alpha milestone. Not something we need to tackle today if the basic workflow is good (deis open)

[technosophos]

This is on the beta list, but it's not clear to me what is left to do. Can someone update a status on it? And maybe assign it to themselves?

[helgi]

The IP whitelist is not really done but we haven't really planned it either. Not have we figured out how we want to do configuration changes (if at all) that affect other deis components, ala deisctl.

Removing it from beta for now but we need to get to this and make decisions sooner or later

[helgi]

Closing this since we got all the items above, last one was IP Whitelist, and we have a way we like (so far) to modify things like the router, etc