Azure/helm-charts

Ghost chart deviates too much from upstream

Closed this issue · 3 comments

krancour commented

This is a follow-up to #89.

Our Ghost chart (still) deviates more from the "upstream" kubernetes/charts/stable/ghost chart than I am (personally) comfortable with.

The community in the upstream kubernetes/charts repo is vibrant and active. They are continuously improving all the charts in that repository. Maintaining the charts in this repository is our responsibility, but it is one that could easily reach burdensome proportions. I would prefer that we limit how much we deviate from "upstream" to just changes that are necessary to adapt the charts for use with OSBA. By doing so, we lessen our burden by making it substantially easier to diff our charts against upstream and hand-pick valuable changes.

Unfortunately, as in the case of this chart, that might mean passing on obvious opportunities to improve the charts. In such cases, we should contribute those improvements upstream instead.

prydonius commented

Would it make sense to come up with a way to generalise service catalog resources in charts and contribute it upstream? Perhaps we could add values to charts e.g.:

serviceCatalogDatabase:
  enabled: true
  clusterServiceClassExternalName: ...
  clusterServicePlanExternalName: ...
  parameters: {...}

I haven't looked into the service catalog in a while, so I'm not sure how viable that is/how common we can make this. However, it would be nice to have a standard way for charts to consume managed DBs from different providers, rather than each provider having to maintain their own set of charts.

krancour commented

Would it make sense to come up with a way to generalise service catalog resources in charts and contribute it upstream?

@prydonius yes. I think that would be a good goal. But...

I'm not sure how viable that is/how common we can make this.

That's a problem, for the moment. Provisioning any service x from different providers is likely to vary in the following ways:

  • What they offer. Take Postgres for example. Does it provision you a Postgres server (i.e. an entire RDBMS) or just a database on a (new? existing?) server.
  • The required parameters. In Azure, for instance, all services need to a location and resource group. Those parameters are meaningless to other service providers... but then they'd likely have parameters they require that we don't.
  • The credentials. K8s service catalog writes credentials as secrets, but what fields are included might vary by provider. So, for instance, our broker might inject host, username, and password for into a secret, but someone else's broker might inject address, login, and pass. The scheme of what's injected into the secret is super important because, obviously, specs for application deployments / pods will often use the downward API to push those secret fields into environment variables. So if field names vary, that's a problem.

My intuition is that it doesn't make sense to start supporting these sort of things upstream until more of this is sorted out.

That being said, our own plans around this Azure/helm-charts repository may be evolving such that we do not seek to provide alternatives to many upstream charts that use Azure-based backing services. Instead, we may be taking this into a direction where this repository showcases just a few such alternatives to merely demonstrate the power of K8s Service Catalog + our broker, without becoming a maintenance burden for us to track and cherry-pick improvements from upstream.

Bottom line is we'll see what happens, but when a better sense emerges that the timing is right to start supporting K8s service catalog in the upstream charts, I think you can count on our help.

prydonius commented

Thanks for the detailed overview @krancour.

The credentials. K8s service catalog writes credentials as secrets, but what fields are included might vary by provider.

This sounds to me like the biggest issue in reliably consuming services from different providers. Does the Open Service Broker API plan to draw up a set of standard credential fields for common (types of) services? We, at Bitnami, would certainly like to see this and perhaps we could help with forming this.

For required parameters, like an Azure resource group, I think this could be a freeform object that the chart can accept and use to form the parameters of a ServiceInstance. Not ideal, but documentation can help, and/or this repository could even become a place to host example values.yaml files for upstream charts.

That being said, our own plans around this Azure/helm-charts repository may be evolving such that we do not seek to provide alternatives to many upstream charts that use Azure-based backing services. Instead, we may be taking this into a direction where this repository showcases just a few such alternatives to merely demonstrate the power of K8s Service Catalog + our broker, without becoming a maintenance burden for us to track and cherry-pick improvements from upstream.

This sounds like a good medium-term goal to me.