questions on Charm Store Policy

[Matt Bruzek]

Jason,

I think we discussed this in the #juju irc channel, but I wanted to follow
up with an email to be complete.

   - Matt Bruzek <matthew.bruzek at canonical.com>

On Fri, Jan 16, 2015 at 5:07 PM, Jason Hobbs <jason.hobbs at canonical.com>
wrote:

> Hi all,
>
> I spent some time this week reviewing a charm, and have some questions
> about some of the Charm Store Policy requirements. I want to make sure I
> understand these requirements well enough to explain them to people
> who's charms I review, and to be able to give them direction on how they
> can bring their charms in line with the policy. I also want to make sure
> that if someone else reviews the same charm I review they come to the
> same conclusions as I do. Some of these have been discussed some already
> on #juju at freenode, but it was suggested I post them here too; I would
> appreciate any thoughts you have on this!
>
> "Must follow the spirit of the Ubuntu Philosophy."
> As applied to a charm I think this essentially boils down to the charm
> only containing free and open source software, and not doing anything
> nefarious. But, it should be acceptable for a charm to install non-free
> software from a location outside of the charm itself, as long it's clear
> up front, right?
>

We discussed this policy recently and I agree that it is vague.  Indeed we
do want to charm up non-free software as well.  We have partnered with
different companies and have developed several charms with partners
(mellanox, mariadb, websphere-liberty).  The important things to point out
here are the charm code should be an FOSS license, but the software or
service can be under its own license.

>
> "Must also be valid for the charm and/or bundle format defined in Juju's
> documentation."
> I think this means that to be in the charm store, the software needs to
> be a charm or a bundle - not just some arbitrary piece of code like you
> can stick in a bzr repo.  Is that right?
>
> My understanding of this policy is the charm must be in a structure that
Juju understands.  There are certain files that must exist to be a valid
charm (metadata.yaml for example), or a valid bundle (bundles.yaml).  All
that means is the charm must not break with convention in ways that would
break Juju, or our automated testing.

Currently charms must be in launchpad to get in the recommended section of
the charm store.  However we recognise that many developers are using
github these days and we are looking at ways to support that.  Technically
you can write a charm in github, and deploy it from a local repository on
your machine (no launchpad needed).


> "Should make use of AppArmor to increase security."
> I read this is a recommendation, not a requirement, because of the
> "should". However, it's not clear what the intent is. It would be nice
> if there was guidance we could point to here on how charms should deal
> with apparmor. I think it's usually handled by packaging, and a charm
> shouldn't need to deal with it if it is. Are there cases where a charm
> does need to do something with apparmor, even if the package does? When
> developing a charm for software without apparmor enabled packaging, what
> are the recommendations?
> Thanks for the questions, my responses are in-line.
>
> Our documentation falls down here.  Since our discussion there are plans
made to improve that.  I would like to learn how to use apparmor better and
will post more information when I do.



> "Must include tests for trusty series and any series afterwards. Testing
> is defined as unit tests, functional tests, or integration tests."
> Does "any series" mean any LTS or does it include non LTS releases too?
>  Is this saying that if tests are included, they must support Trusty and
> future releases? Or is it ok to leave tests out altogether? If tests are
> required, is there a minimum standard of coverage? Is verifying the
> service is pingable after deploying it enough, or does it need to
> exercise features?
>
>
We are running all the recommended charms automatically now against
different Juju environments.  All trusty charms must contain tests to
become recommended charms so we can ensure the quality of the charms.

This is a relatively new policy so we could not retroactively enforce that
on older charms.  So older series can get by without tests, but are highly
encouraged.

The tests are up to the author.  Ideally there would be a full suite of
tests, unit, functional and integration tests.  The tests that charmers are
looking for are functional (does the charm work) and integration (does the
charm deploy, relate, scale, and configure properly).


> Thanks,
> Jason
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20150127/b134348b/attachment.html>