-
Notifications
You must be signed in to change notification settings - Fork 14
Description
As a BOSH deployment framework author, I'm concerned about this library not being an extension of RFC 6902 patches and RFC 6901 pointers. The only incompatibility right now, is the type key instead of op. The rest are (useful) extensions to the RFC standards.
Let me tell you a bit more about my use-case. The point of GBE is to express many BOSH deployments that are tied together in order to collaborate nicely in an integrated way. Currently, GBE uses go-patch ops files for building deployment manifests. So only go-patch syntax is currently used and it's OK because ops files are specific to BOSH.
Now in the near future, I need to introduce upstream sets of integrated BOSH deployments (that one could also call “GBE distributions”), that would be customized (or just configured) by downstream actual deployments.
GBE is based on modular subsystems, each one of these being described in a spec.yml file. I'd like to provide my GBE downstream users with the possibility to customize those subsys specs with elegant YAML patches. And I guess I'll need expressive operations for those YAML patches to actually be elegant. As I see that bosh int is quite limited in its feature set, I'm therefore wondering whether I should stick to it.
For example, PCF-pipelines people have chosen the yaml-patch tool for customizing their pipelines.
But in adopting a richer YAML patch syntax, I'd like it to find a balance with those 3 requirements:
- Offer a rich set of patch operations.
- Be consistent with
go-patch, because GBE is a great place for experimenting with new BOSH ops files. I expect my users to write ops files and possibly submit them to upstream release repositories if they turn out to be useful. - Extend existing standards and don't redefine any new one.
That's why I'm advocating here for convergence between go-patch and yaml-patch. And the only small improvement to make in this direction is for go-patch to accept op as an alias for type. And I wanted you to understand more in depth the reasons that are behind this request.
So, could we accept op as an alias for type? I'll be happy to submit a PR for this.