[WIP] Add 3.7 #197
[WIP] Add 3.7 #197
Conversation
|
For those in the peanut gallery wondering about what this new configuration is / where it's documented, see http://next.rabbitmq.com/configure.html. |
|
Discussed this a little bit over in #199 (comment) -- current leaning is towards taking the version bump as an opportunity to slim things down considerably, suggesting that users instead use the newer (simpler) configuration file, or definitions import (which should be much more reliable than our fiddly shell scripting anyhow). |
tianon
force-pushed
the
3.7
branch
2 times, most recently
from
0b04c9e to
7f410ca
Compare
|
Since 3.7 has just been released. Any news on the publication ? |
|
@michaelklishin looking at getting this in ASAP so we can get the new 3.7.0 GA release out -- I'm thinking we should gut On the one hand, I'd like to be as close to only supporting what upstream does out-of-the-box as we can reasonably be, but on the other, Docker containers are much easier to configure via environment variables than files. 😞 Any suggestions, advice, or even just opinion you're willing to offer? 🙏 ❤️ |
|
For completeness, here's what I believe is the full list of
|
|
Two places we apply additional processing are around |
|
Oh, and a couple of those support an See #203. |
|
Perhaps we should simply adjust to the new configuration file format so that we're more respectful of bring-your-own-config users, since this currently-supported set doesn't seem all that large, IMO. @yosifkit your thoughts would obviously be appreciated too 🙏 |
tianon
force-pushed
the
3.7
branch
7 times, most recently
from
c41391b to
c775c5e
Compare
|
I've updated this to convert to the new format (useful commit for review is 946a6d2). The only major gotcha I've found so far is rabbitmq/rabbitmq-server#1445, which I've left as a This also allows folks to bring their own |
|
@tianon @yosifkit note that the old config format can be used in combination with the new one. Some plugins (e.g. LDAP) support configuration that is really hard to express without a language with "real" data structures (or a DSL). So the image should support the advanced config file (a yet another file, in the Erlang term format). I suspect that a massive % of users would prefer to "bring their own" advanced config file. |
|
Right, but we can't have both "rabbitmq.config" and "rabbitmq.conf"
together, right? Just "rabbitmq.conf" with "advanced.config" together?
(the script simply checks for "rabbitmq.config" and errors out if we're
expected to write "rabbitmq.conf", since my understanding is that the two
of those were exclusive)
|
Yep! Riak works the same way, too. |
- `bash`: apply Alpine patch to 4.4 for process substitution hang (tianon/docker-bash#4) - `golang`: add `alpine3.7` variant of 1.9 (docker-library/golang#192) - `rabbitmq`: add 3.7, which includes a new configuration file format (docker-library/rabbitmq#197) - `ruby`: remove `2.5-rc-alpine3.6` variant (superseded by `2.5-rc-alpine3.7`)
Closes #183
This builds on #195 to start implementing support for 3.7. I haven't converted the entrypoint to use
rabbitmq.confyet, but I've looked at a lot of the documentation and am really pleased with how nice and simple everything looks. 😄I'm casually pondering (as noted in #187 (comment)) whether we should use this major version bump as an opportunity to claw back our supported environment variables to something closer to what upstream natively supports out-of-the-box, but would appreciate if @michaelklishin (or anyone else from upstream) would be willing to provide some color on whether that's something we definitely should try do, definitely should not do, or something upstream is likely to be indifferent about. 🙏
It's definitely easier in Docker to provide environment variables than it is to provide a whole new config file, although only really for the one-off use case -- for a real production deployment, the difference is pretty negligible.
There's also the new auto-clustering behavior proposed in #183 that we ought to consider supporting somehow (which if we stick with environment variables will mean new ones to configure that, but if we ditch the environment variables will likely mean a total punt on any additional behavior to support that out-of-the-box due to strictly bring-your-own configuration).