Good day, I tested, reviewed and discussed the following *rabbitmq-server* charm proposal with peers.
While the Ubuntu OpenStack Engineering team supports the essence of this proposal as a more secure default stance for the charm to take, and the impact of the default change has been assessed as very low, there are some issues to address before it can be accepted. *Summary of proposed changes:* Disable the guest account by default, while exposing a new charm config option which allows users to re-enable it if they so choose. *Review summary:* https://code.launchpad.net/~pjdc/charms/trusty/rabbitmq-server/no-more-guest-user/+merge/276831 * It is not safe to assume a non-clustered rabbitmq configuration in absence of the Leadership Election feature. * The new charm config option, as well as the default behavior change both need test coverage, such as: -- Validate that the guest user is not enabled by adding a test case to the existing test suite in the tests/ dir; -- Validate that the guest user is enabled on the units when the charm config option is changed from False to True. * The changes are proposed against the stable/trunk charm, and need to be targeted to the "next" development branch of the charm [1]. As a matter of course, any new features and changes must first land in "next," then make their way to the stable charm via the OpenStack charm release cadence, or by requesting a backport from next to stable. [1] https://code.launchpad.net/~openstack-charmers/charms/trusty/rabbitmq-server/next Cheers, -- Ryan Beisner QA Engineer, Ubuntu OpenStack Engineering, Canonical, Ltd. irc:beisner lp:~1chb1n
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
