One base manifest, many operator files

[drnic]

I appreciate that you've shown many different ways to run Harbor with different manifests. I'm writing to share a pattern that is evolving in other BOSH releases.

In the BOSH community, the consistent pattern we're going with is:

• A manifests folder (some older projects have a templates folder, but manifests is newer and nicer)
• A manifests/operators folder (some projects have manifests/ops-files)
• A manifests/harbor.yml base manifests that works with zero user-provided variables, e.g. no static IPs or elastic IPs, contains releases: that reference final releases or ideally compiled releases, and allows the very simple README instructions:

  bosh -d harbor deploy manifests/harbor.yml

• manifests/operators/create.yml - overrides the harbor release with version: create and uri: . to make it easy to run bosh deploy manifests/harbor.yml -o manifests/operators/create.yml to emulate bosh create-release --force && bosh upload-release --rebase && bosh deploy ...
• various other operator files to reproduce your existing manifest examples; some of these might be vsphere.yml etc where you're trying to communicate something specific about the target infrastructure; but this isn't common. In your manifests, the only "vsphere" idea I see is the static IP, rather than an elastic IP for other infrastructures?

An example BOSH release project that maintains this pattern is https://github.com/cloudfoundry-community/redis-boshrelease

Thanks for open sourcing the Harbor bosh release!

/cc @cppforlife

[jessehu]

Thanks a lot @drnic. Your suggestions are really helpful. We will find time to make according improvement. We also welcome any kind of contribution to harbor-boshrelease project.

[jessehu]

Hi @drnic, I have cleaned up the manifest files in commit https://github.com/vmware/harbor-boshrelease/commit/089c7c536b7ccb2aee67c54f4aad8f125e077169. Will use the operators approach when adding more deployment manifests.