Remove some of the scheduling abstraction in favour of more tightly coupled model <-> k8s integration

[deis]

Remove some of the scheduling abstraction in favour of more tightly coupled model <-> k8s integration

[krancour]

This makes sense to me, and this write up makes the issue more clear to me than our convo yesterday. Things such as "service," for example are unique to k8s. Keeping a generic interface that was suitable for multiple schedulers before, meant not hooking into app creation, for instance, to define a service. It had to be done elsewhere where it was a tad trickier. I get it.

It no longer needs to be this way. To be fair, there was probably a clever way to have done this better in the past too, but hindsight is 20/20. I'm no django expert, but here's what I have in mind...

Separate generic, highly reusable k8s functions such as crud operations on services, rcs, etc. into their own module for eventual extraction into a package. (I know you already intend that.) Then create a layer between that and the model with very generic fuction names on its interface-- things like postAppCreate() or postDomainAdd(). The idea would be that in any given implementation of this layer, the hooks can be implemented against the underlying scheduler (k8s in this case) without function names like start() or scale() polluting the interface. This layer's functions can be observers of all the events on the model. Theoretical support for another scheduler in the future is thus only a matter of providing an alternate implementation of a listener/observer layer that's already hooked into the model.

This would allow, for instance, k8s service creation to be triggered by app creation, even though services aren't a thing in other schedulers. Persisting a new app object triggers postAppCreate(), which in this case creates a service, but in the theoretical case of another scheduler might do something else entirely or may even be a no-op.

[helgi]

I'm going to close this as we have done a lot to separate things out and the high level functions left in the scheduler are pretty slim, beside run, which is up for a rewrite with Jobs