[raziel2p]

I'm looking forward to experimenting with this.

At least in the documentation, there seems to be a lot of focus on extra tools. BOSH seems very off-putting. Having to use the "fly" CLI command to update pipeline configuration seems unnecessary - can I just update the files on the filesystem myself, either via my configuration management tool or a git repository?

[twic]

This is very much a trait of BOSH. When BOSH manages a machine, it owns that machine. It deploys the stuff that's specified in the manifest, but that has to come out of one or more 'releases', ie precisely structured tarballs of stuff, and there's no way to manage a file here or a setting there. You could push out a file by packing into a release, uploading that, and adding it to the manifest, but that's quite a ritual for one file. You are essentially expected to treat the machine as a black box.

As a result, BOSH-based systems tend to be managed via APIs exposed by the software running on them, which often come with a command-line tool. BOSH itself is like this, and so is Cloud Foundry.

This is a very different approach to tools like Puppet or Ansible, which are much more about openness and empowering the operator to directly manage machines. Although it is fairly similar to Docker etc, where you fire up images without any sensible way to fiddle with them, and rely on talking to the software.

So, if you are comfortable with the Puppet/Ansible type tools, then you won't like BOSH. This is 30% because BOSH isn't as good as them, but 70% just because it's different.

[sneal]

BOSH being different I think is why a former collegue of mine created a Chef cookbook for Concourse: https://github.com/dvanbuskirk/concourse

[Jjarro]

I have a handy heuristic about this: if you are interacting (directly or via a third party) with the filesystem of a service in order to use it, said service is probably solving your problem wrong.

Try `fly`. It's worth it.

[raziel2p]

Funny, I use the opposite approach. If I can't configure and manage something via the filesystem, I usually stay clear of it.

Specifically, not relying on the filesystem means I can't easily browse configuration, I can't have version control, and I can't use my configuration manager to have events trigger when things change.

[jacques_chester]

I think there's some confusion. The actual config you send to a Concourse server is on your filesystem and ideally it's checked in.

`fly` is the CLI you use to tell the server "hey, here is a pipeline config", or "hey, I've changed the config, here's the new one".

[twic]

No, i think raziel2p understands. If you're using a configuration management tool like Puppet or Ansible, by far the easiest way to manage a piece of software is through a configuration file on disk that the configuration management tool can manage directly: it's easy to see the current state, and to make changes. Anything that requires a tool or an API requires you to interpose some sort of update mechanism between the configuration management tool and the software, which doesn't have the transparency of a simple file.

[jacques_chester]

Ah, gotcha. So if I'm following this line correctly, it'll need someone to write a wrapper that detects updates to .yml files and invokes fly?

[twic]

Something like that. You could either have a little daemon that watches a file and flies it when it changes, or you could do it straight from the configuration management tool. For example, in Ansible you'd write a handler which is triggered after updating a copy of the pipeline file somewhere:

http://docs.ansible.com/ansible/playbooks_intro.html#handler...

The handler could use the command module to run fly:

http://docs.ansible.com/ansible/command_module.html

[krishicks]

Using the `fly` CLI allows you to know what changes are being made when you update the pipeline (it shows a diff), and when your configuration is invalid (or when the update fails for another reason).

[raziel2p]

I get the exact same features from my configuration manager, as long as there is a command I can run to validate the configuration file(s).

[vito]

That command would just be `fly` or something else coming from Concourse. To me it makes more sense for the entry into the system to be safeguarded with validation, and then possibly bring your own filesystem-based configuration management system that goes through that same front door, building on trusted tools from Concourse itself. Mucking with files on disk that directly affect a live system (shipping production code!) seems like a recipe for disaster.

[emmelaich]

What configuration manager do you use?