I'm not quite sure why we need the flexibility to change syslog port dynamically. If we want TLS, surely we want it always, which means there is an upgrade migration to TLS (where we upgrade machine-0 to support it, and then all agent machines to request it), but leave both ports open until the next upgrade where we know all agents are connected to TLS.
I can understand wanting people to configure their own environments, but in the end it is just more moving parts unless there is a real benefit to allowing it to be configurable. I may have missed the utility in it, though, so feel free to enlighten me. John =:-> On Mon, Feb 24, 2014 at 9:02 AM, Andrew Wilkins < andrew.wilk...@canonical.com> wrote: > I'm been working on https://bugs.launchpad.net/bugs/1281071, to enable > TLS on rsyslog connections. The core work is done, it's now down to > upgrades. > > Ideally we should upgrade all existing rsyslog configuration to use TLS. > The problem with this is that currently, our rsyslog configuration is > effectively static: you cannot change syslog-port after bootstrap, and > similarly you would not be able to change syslog-tls (which I'm adding, and > making the default for new environments). > > It is true that we can change rsyslog config on upgrade (and will - > there's a step defined already), but this doesn't seem ideal to me. You > still can't change the port, and you still couldn't change the TLS flag > easily. We could hack the environment config in state on upgrade, but this > seems ugly to me. So, I think the best path forward is to have a new worker > to manage the configuration. > > The question I have for the group is, is it of enough value to have > rsyslog configured during bootstrap/provisioning that we continue to do it > in machine init? If we take it out of there, we simplify the provisioning > code, and relegate all rsyslog configuration to this single worker. > > Upgrades should be automatic; the rsyslog config worker would simply > rewrite the configuration file at machine agent startup and kill -HUP > rsyslogd. The (only?) downside is that we would not see any logging if the > machine agent failed to start. It would still be there on the machine, but > not accumulated in all-machines.log. OTOH, if the machine agent failed that > early on, there's a good chance there's nothing to accumulate anyway. > > Cheers, > Andrew > > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev