I marked this as affecting maas.
to make cloud-init configure syslog to the maas system , maas will have to adjust the cloud-config that it sends to instances.
a.) supported back to precise
#cloud-config
rsyslog:
- "*.* @<MAAS_SERVER_IP>"
b.) supported trunk (wily) and going forward. This format can be ported back to trusty if requested.
#cloud-config
rsyslog:
remotes:
maas: <MAAS_SERVER_IP>
The benefit of using 'b' is that it "merges" better, for the future world when maas provides vendor-data.
To illustrate that point, consider:
i.) maas provides remote syslog config via vendor-data
#cloud-config
rsyslog:
remotes: {'maas': "<MAAS_SERVER>"}
ii.) juju provides remote syslog config via user-data
#cloud-config
rsyslog:
remotes: {'juju': "JUJU_SERVER"}
cloud-init merges those 2 configs so that the result has both 'juju' and 'maas' config.
if the user (or juju) wanted to disable maas, then they can by providing user-data like;
#cloud-config
rsyslog:
remotes: {'maas': "", 'myserver': "MYSERVER"}
I marked this as affecting maas.
to make cloud-init configure syslog to the maas system , maas will have to adjust the cloud-config that it sends to instances.
a.) supported back to precise
#cloud-config
rsyslog:
- "*.* @<MAAS_SERVER_IP>"
b.) supported trunk (wily) and going forward. This format can be ported back to trusty if requested.
#cloud-config
rsyslog:
remotes:
maas: <MAAS_SERVER_IP>
The benefit of using 'b' is that it "merges" better, for the future world when maas provides vendor-data.
To illustrate that point, consider:
i.) maas provides remote syslog config via vendor-data
#cloud-config
rsyslog:
remotes: {'maas': "<MAAS_SERVER>"}
ii.) juju provides remote syslog config via user-data
#cloud-config
rsyslog:
remotes: {'juju': "JUJU_SERVER"}
cloud-init merges those 2 configs so that the result has both 'juju' and 'maas' config.
if the user (or juju) wanted to disable maas, then they can by providing user-data like;
#cloud-config
rsyslog:
remotes: {'maas': "", 'myserver': "MYSERVER"}