Support multiple versions of logstash by renaming the logstash class

[AlexWerz]

Hi!
This modul has supported older versions of logstash with the version 0.6.x. With 5.x it only supports logstash 5. For older versions the legacy module should be used as stated in the readme.

The problem is that both modules use the same classname and thus can't be used together in one environment. We are providing a lot of servers with different versions of logstash which is not possible if both modules share the same classname.
My suggestion: if v5.x if this module only supports v5.x of logstash, then rename the class to logstash5.

Regards,
Alex

[flysen]

I have not tried but isn't the recommended way to deal with this kind of cases to create different environments?
I can imagine a scenario like this:
env=puppetV2.34 (has logstash 2.3)
env=puppetV2.35 (has logstash 5.1)

And each time you upgrade a module you create a new environment. I'm curious to know how this are intended to work. I can imagine that "java" will suffer from the same problem.

Cheers
Fredrik

[AlexWerz]

That would mean you need to create an environment for every combination of modules which are conflicting. If you only have a small number it might be possible but with growing projects the number of used modules are growing as well. My personal opinion is that a module should have no version number if it supports multiple versions of a product. But if it is specific to a certain version it should contain that in the class name.

[flysen]

@AlexWerz That's true 👎
We are in the same situation and don't want to "paint our self into a corner". I've asked around and read a few pages but still confused how to handle this.
We have +300 machines running puppet in one environment, we are moving to Redhat satellite so I need to understand how they'll handle it...

[igalic]

I definitely agree with @AlexWerz here, it should also be noted that loading multiple different versions of a single module in different environments has only been supported since rather recent puppetserver releases.

[jarpy]

I think there are some great points here, and unfortunately, no easy answers. Versioning and namespacing in Puppet have always been challenging. Directory environments and SCM certainly help, but as you correctly point out @AlexWerz, the directory environment solution doesn't scale well if you have multiple challenges of this kind.

If my shop was facing this problem, I would most likely fork and rename the Logstash 2 module. Forking is not as bad as it may sound in this case, because upstream development (hey that's me!) on the version 2 module has ceased except for critical bugs. We could even consider formalising the rename if people think it's useful, by maintaining a branch here on GitHub and perhaps releasing it on The Forge as elastic/logstash2. What do you all think?

I'd rather not rename the version 5 module. It's released to The Forge now, so renaming it will spontaneously break every site that is using it. It's also very possible that we will be able to maintain forward compatibility when Logstash 6 comes out. It would be a shame to force ourselves (and our users) into a versioned naming scheme if we don't need to. I also want to maintain the best possible out of box experience for new users, and part of that is the promise that include logstash is all you need to get a working install of the latest version.

[vinzent]

another problem regarding different versions of the same (named) module in different environments is https://docs.puppet.com/puppet/latest/environment_isolation.html with ruby types. adding new parameters or completly new types will break things.

by comparing names elastic/logstash and elastic/logstash2 it sounds like logstash2 would be newer. If renaming something indicating its not the latest like elastic/logstash_legacy?

[RogierSchuring]

Don't know why there is no reply all these months (I would expect more people to want this!) but, please do @jarpy
It would help our situation.