Kubernetes playbooks for postgresql

[rthallisey]

We're going to use the extra_var CLUSTER to determine which
playbook to use. This will allow us to keep the playbooks separate.

[rthallisey]

(13) Agnostic Runtime phase 3

[djzager]

My initial impression is that there must be a better way to accomplish this than having distinct roles based on the cluster type. I understand that the APB must be aware of the cluster, but I would think that these deployments would be more alike than not alike.

At first glance this method puts a lot of the onus on the APB developer to create and maintain separate paths for OpenShift vs Kubernetes, which is already true...but if we could make it easier for them that would be better.

I'm still trying to think this through so this idea hasn't been totally thought out. What if you were to not separate roles but conditional logic when you must deploy an OpenShift/Kubernetes specific object. Is there something that an OpenShift DeploymentConfig buys us that isn't available in a Kubernetes Deployment? Are we hurt in OpenShift if we simply create a Deployment?

These are just some of the thoughts that I have. What's happening looks good, I just want to encourage some more conversation about the implications of splitting on the cluster this way for APB development.

[rthallisey]

My initial impression is that there must be a better way to accomplish this than having distinct roles based on the cluster type. I understand that the APB must be aware of the cluster, but I would think that
these deployments would be more alike than not alike.

The apps we have here are more alike than not alike, but this only gets trickier as they get more complex. For instance, a route is not equal to an endpoint. A route is an ingress in kubernetes which requires you setup a loadbalancer like haproxy in you cluster to handle that resource.

At first glance this method puts a lot of the onus on the APB developer to create and maintain separate paths for OpenShift vs Kubernetes, which is already true...but if we could make it easier for them that would be better.

I understand your point. Here are some of the other options I looked at:

1. jinja2 template the resources: I really don't like this one because it makes the templates un-readable.
2. abstract differing resource calls behind an ansible module: This is very challenging. The module would have to correctly identify the resource the user is asking for, but also correctly render the template.
3. Use kubernetes resources everywhere

To you point about maintaining two - If folks are using the broker on k8s then they only need to maintain one playbook. Maintaining two occurs if you go openshift -> kubernetes. This is part of why I harp on making kubernetes the default because it makes 3) the solution for the maintaining two playbooks problem.

I'm still trying to think this through so this idea hasn't been totally thought out. What if you were to not separate roles but conditional logic when you must deploy an OpenShift/Kubernetes specific object. Is there something that an OpenShift DeploymentConfig buys us that isn't available in a Kubernetes
Deployment? Are we hurt in OpenShift if we simply create a Deployment?

I don't think we will be hurt by a deployment. There are some things that I've heard are different between deploymentconfigs and deployments, but nothing game changing. A bigger change might be a route. I don't know all the details on how they are different, but again I don't think it impacts functionality.

These are just some of the thoughts that I have. What's happening looks good, I just want to encourage
some more conversation about the implications of splitting on the cluster this way for APB development.

Thanks David.

[rthallisey]

I'm having trouble getting the conflict to resolve. Closing in favor of #27