Comments (3)
(@evanfarrar Sorry, I realize after writing this that it sounds pretty harsh. It's not meant to be directed at you in particular, there's just a lot of frustration here.)
After living in the CF bubble for years I'm extremely wary of new tools like bbl
that seem to augment BOSH without it feeling like an official part of BOSH or a recommended part of its ecosystem (i.e. prominently in https://bosh.io docs, not an afterthought). There have been so many of these invented over the years that I'd rather not expend the effort to embrace any of them until BOSH does.
I'm even more wary of tools that also require work for individual release authors. If and when BOSH's ecosystem grows to the point I want it to, that'll be a whole lot of busywork. I appreciate that it's something your team would like to do/automate for us, but the point still stands. What is it about the bbl.yml
file that couldn't just be provided by other, more generic, ops files? (Or, as @jama-pivotal said, it could be in your own repos.)
I want to see BOSH succeed as an open-source project. So I'm trying to have Concourse remain an exemplary use of BOSH, as a user knowing only BOSH (further, knowing nothing about BOSH) would see it. For this approach, https://bosh.io, its documentation, and the bosh
CLI is the source of truth. There's enough of a stigma around BOSH's learning curve that I'd rather not perpetuate it by making it appear that you have to use a third-party tool (even if it's within CF) just to get started. It makes BOSH's open-source users feel like an afterthought.
from concourse-bosh-deployment.
Interesting suggestion @evanfarrar. Sounds like a mighty powerful ops file. Apologies in advance if my follow questions are a bit noob; I'm not too familiar with bbl
and how it sets up Concourse:
- I assume this
operations/bbl.yml
would be to enhance the steps described here? - You describe this is a pilot, what are the uncertainties and/or assumptions that you are testing for by doing this programmatically?
- Follow up: what are the specific uncertainties that you want to test that make it necessary to be put under this repo (concourse-deployment)
from concourse-bosh-deployment.
Sorry, I missed this for a long time.
I assume this operations/bbl.yml would be to enhance the steps described here?
Yes, this PR is the ops file that those instructions tell you to write out and then use when deploying. But there are still problems, even if this little YML file editing weren't adding another step to the process: it takes a million years to compile, it still requires 17 totally static command line arguments to bosh deploy
, and there is a bit of an uncertain leap to figuring out how to make this more production-friendly with external databases. That's why I went on to suggest maybe this one YML file shouldn't the end of BBL's relationship with concourse-deployment. We could show some new features in one "experimental, community maintained" corner of the manifest, and y'all could decide if and when you want to make them mainstream.
You describe this is a pilot, what are the uncertainties and/or assumptions that you are testing for by doing this programmatically?
By programmatically, I mean, via Continuous Integration. I could compile releases, and add them to "my" ops file in this repo, but I'd rather have a test suite do that only after verifying that the latest versions actually work then commit the result. Nobody should have to argue with robots though, so I'm suggesting this hypothetical CI robot get commit rights to your repo so that it can edit that ops file (bbl.yml) without a PR.
Follow up: what are the specific uncertainties that you want to test that make it necessary to be put under this repo (concourse-deployment)
I have very few uncertainties about this ops file, or the potential for continuing to close the gap concourse-deployment has with the operator friendly features of cf-deployment. Having it in this repo enhances the odds that users (and maintainers) might discover this new, easier experience, and allows me to point users to a single repo with everything necessary to conveniently deploy Concourse.
I'm even more wary of tools that also require work for individual release authors. If and when BOSH's ecosystem grows to the point I want it to, that'll be a whole lot of busywork. I appreciate that it's something your team would like to do/automate for us, but the point still stands. What is it about the bbl.yml file that couldn't just be provided by other, more generic, ops files? (Or, as @jama-pivotal said, it could be in your own repos.)
I would want a bbl.yml file to pack it with even more opinionated defaults in the future. I could have just PRed these particular changes into the base manifest, but I assume you knew this was possible, and had reasons for not doing it. Likewise, there are like 17 other vars that you could have made sane defaults for, but for some reason do not. That's fine, but I'd like to supply as few flags as possible to bosh deploy
, even if it means some duplication and even if you want to name this file experimental/bbl-community-maintained-experimental-do-not-use.yml
.
Nothing about deploying Concourse to a BBL created BOSH director requires sustained work for manifest authors. There are some things that require sustained work that are unrelated to BBL, but I would happily do them just to make the experience of Concourse on BOSH as good as it can possibly be: compiled releases, new IaaS features, and new opinions about the best configuration of the IaaS. I'd also like to supply release versions that I know have been smoke tested, because that has not been my experience.
Maintaining a separate concourse-deployment manifest was what you suggested originally (concourse/concourse#1034). I was thrilled when Concourse finally made a manifest, but I kind of assumed you read mine or cf-deployment when you made this one? I want to point users at a single source of truth. I don't want to verbally describe editing YAML files to my users. I want version controlled, declarative descriptions of our software that we know work. I don't want to describe the recipe for creating that declarative description.
I'd be the first to admit that there is a ton of busywork involved in making a good BOSH deployment manifest, and ironically Concourse has been the only way out of that mess. By demonstrating the patterns we follow in automation and higher level abstractions, we have collectively made BOSH much better. There is still a long way to go.
I want to see BOSH succeed as an open-source project. So I'm trying to have Concourse remain an exemplary use of BOSH, as a user knowing only BOSH (further, knowing nothing about BOSH) would see it. For this approach, https://bosh.io, its documentation, and the bosh CLI is the source of truth. There's enough of a stigma around BOSH's learning curve that I'd rather not perpetuate it by making it appear that you have to use a third-party tool (even if it's within CF) just to get started. It makes BOSH's open-source users feel like an afterthought.
We could merge into both the BOSH cli as bosh bootload
and update the docs (and already do merge our features into the BOSH cli from time to time), but we'd love it if some more teams who are such paragons of BOSH usage as yourself would try the new experience and give feedback on it before we throw it at users who don't get a paycheck to use BOSH.
from concourse-bosh-deployment.
Related Issues (20)
- versions file assumes access to bosh.io, provide an operations file that _forces_ offline mode
- uaa requires the disabling of postgres TLS to be used correctly HOT 2
- uaa requires larger canary watch
- documented uaa and credhub versions as vars files
- make AZs a variables, rather than hard code it, it is never `z1` HOT 1
- AZs need to be parameterized in all Ops files
- v6.1.0 - tagged incorrectly in this repo - Concourse unable to track HOT 2
- basic-auth.yml ops file has a misleading name
- Oauth2: cannot fetch token: 404.. Response: 404 page not found; Concourse 5.5.11 to 6.3.0 upgrade HOT 1
- credhub and uaa dbs are not backed up when colocated on web HOT 2
- BBR backup CredHub fails due to hostname verification failure with internal postgres server's certificate HOT 2
- bionic stemcell HOT 8
- mTLS unintentionally(?) enabled when deploying v7.0.0+ HOT 3
- concourse 7.3.1 upgrade failure HOT 4
- BBR 1.15.0 deployment fails, but 1.18.9 succeeds
- uaa job fails to start when using ssl mode on self signed certs
- The v7.4.4 versions.yml references v.7.4.0. HOT 4
- Empty versions.yml for 7.9.0 concourse release HOT 5
- Are there plans to update the stemcell to Jammy Jellyfish? HOT 2
- Web instance is not running after update. (pthread_create failed) HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from concourse-bosh-deployment.