New Charm: rsyslog

[Joseph Heck]

rsyslogd and accompanying rsyslog-forwarder subordinate

[Clint Byrum (clint-fewbar)]

Hi Joe, thanks for the interest!

When you want to submit a new charm, please add the tag 'new-charm' .. that is used as a queue for new charms to review. Adding it now, and we'll take a look soon.

[Clint Byrum (clint-fewbar)]

Joe, just took a look at the charm. It definitely looks pretty raw. :)

You can remove the apparmor directory. Upon thinking about that bit of policy twice, we've decided to back away from it quite a bit. You should find that recent versions of 'charm proof' no longer inspect that directory at all.

We're using new-charm as a queue for sponsorship into the charm store. Since this charm is still lacking in most of what we'd want from a charm, I'm going to decline to import it just yet, and remove the new-charm tag. When co-location lands, and we can drop an rsyslog-client charm in each node ... that will make this one quite useful, and at that time we'll want the aggregator relation to be in working order. :)

[Joseph Heck (heckj)]

Thanks Clint,

You'll want to check 'charm create', as it made the apparmor directory for me.

Totally understand on the 'new-charm' tag - was mostly just looking to get some feedback on the setup. I think anything real will require the collocation facilities as you mention, as that tweaks the config files respectively.

-joe

On Nov 11, 2011, at 10:06 PM, Clint Byrum <email address hidden> wrote:

> Joe, just took a look at the charm. It definitely looks pretty raw. :)
>
> You can remove the apparmor directory. Upon thinking about that bit of
> policy twice, we've decided to back away from it quite a bit. You should
> find that recent versions of 'charm proof' no longer inspect that
> directory at all.
>
> We're using new-charm as a queue for sponsorship into the charm store.
> Since this charm is still lacking in most of what we'd want from a
> charm, I'm going to decline to import it just yet, and remove the new-
> charm tag. When co-location lands, and we can drop an rsyslog-client
> charm in each node ... that will make this one quite useful, and at that
> time we'll want the aggregator relation to be in working order. :)
>
> ** Tags removed: new-charm
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/886234
>
> Title:
> rsyslog charm review request
>
> Status in juju Charms:
> New
>
> Bug description:
> request for reviewing lp:~heckj/charm/oneiric/rsyslog/trunk for
> inclusion as a general charm. Improvements needed when colocation
> functionality lands. No relations yet enabled - just basic rsyslog
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/charm/+bug/886234/+subscriptions

[Clint Byrum (clint-fewbar)]

Found these sitting in my local charm repo basically finished. Submitting for the charm store.

[Juan L. Negron (negronjl)]

Reviewing this now:

-Juan

[Juan L. Negron (negronjl)]

rsyslog-forwarder:

This looks good to me. Thanks for the work on this Clint. I particularly like the Known Limitations part at the end of the README file. I think we should include that in all of our charms .... It certainly makes reviewing easier and it provides a bit more transparency.

rsyslog:

Looks good to me.

Non-blocking ( from charm proof ):
I: relation aggregator has no hooks

-Juan

[Juan L. Negron (negronjl)]

Clint:

You can promulgate both of these.

-Juan

[Juan L. Negron (negronjl)]

I just pushed and promulgated them both.

-Juan