Fix default registry path

[joshuaspence]

Fixes #45. Changes $filebeat::registry_path to be consistent with the Filebeat documentation.

[pcfens]

I think that I used the the default from the tarball (this module was originally written pre-1.0).

I don't think this will be a problem to merge, but I'm going to test in my environment to make sure that changing it doesn't create issues for environments that are already running.

[joshuaspence]

Unfortunately I think that this will cause issues for pre-existing environments because they will essentially lose their state.

[pcfens]

I think you're right. Any thoughts on possible mitigations? The only thing I can think of is an exec resource with a cp command if the old .filebeat registry exists, but that feels pretty dirty.

Even though the module hasn't made it to 1.0 I'd like to avoid breaking things best I can.

[joshuaspence]

Yeah I can't think of a good way to do the migration unfortunately. A mv command is going to be tricky because you would also need to stop the filebeat service, which may not even be installed or running yet.

[pcfens]

It looks like deleting the registry file is a bad thing to do, so I'm stuck with what seems like 2 options:

• Merge it now as a new release and put warnings everywhere while telling myself that this is why I didn't release v1.0 yet.
• Wait until I add support for filebeat v5, which may not be backwards compatible either (I don't know yet because it's not done yet)

I find myself leaning towards the latter since nothing is broken in the current model, it just doesn't match the filebeat documentation. I can probably be talked into something else if there are strong feelings about it though.

[pcfens]

For completeness of documentation here: I suspect that I used this as the default because of how it's documented in the filebeat configuration reference.

[joshuaspence]

So how do you want to proceed here?

[pcfens]

I added this to the other issue, but for completeness I wanted to add here:

I think the easiest way to keep moving on this will be to add something to the README.md file about a future change to this, and that it may be breaking. In a future release (after the v5 stuff stabilizes) we'll send a deprecation warning, then follow up a few days later with an actual change in the default.

[pcfens]

I'm going to let the just released v5 run for a few days at least before we try and make this change. I don't want to introduce too many changes at once in case there are bugs I didn't anticipate in the v5 release.

[joshuaspence]

So how do we want to proceed here?