New policy proposals (take 2)

Mark Canonical Ramm-Christensen mark.ramm-christensen at canonical.com
Wed Jun 5 00:04:03 UTC 2013


+1 "pinning" becoming become policy
+1 on standard default file system locations
Tentative +1 on the "subordinates" infrastructure services thing -- I think
this needs a bit more meat on it's bones to be usable as a best practice.

Then for the testing bit, I am a huge +1 on getting
the necessary infrastructure in place to make that happen, and when it's
all in place and the exact details of a continuous integration gating
policy are available I expect that I would be a huge +1 on there too.

--Mark Ramm

On Wed, May 15, 2013 at 11:51 AM, Marco Ceppi <marco.ceppi at canonical.com>wrote:

> +1
>
>
> On Wed, May 15, 2013 at 11:46 AM, Jorge O. Castro <jorge at ubuntu.com>wrote:
>
>> Ok so we had a discussion at UDS, and we've narrowed it down to one
>> policy proposal, and 2 best practice submissions.
>>
>> - [policy] Charms should provide a way, when possible, to pin versions
>> of a software (defaulting to packages, when packages are available -
>> in order to maintain stability between versions of the charm) and the
>> charm has to provide a clean upgrade path (via upgrade-charm) to
>> insure all data created and stored by the charm is maintained from
>> past versions
>>
>> - [best practice, not policy] installation locations should be
>> configurable yet default to standard FHS locations (like /srv)
>>
>> - [best practice not policy] charms should implement relations for
>> common subordinate services such as monitoring, backups, log
>> aggregation, etc... best practice that will evolve as we develop more
>> infrastructure services to plug together
>>
>> and then last one is a "Future policy submission" which we should
>> discuss. Instead of +3 acks, we'd like to:
>>
>> - Gate on tests.
>>   - charm has to have non-trivial integration tests ($CHARM_DIR/tests)
>>   - passing tests against (preferably all) providers
>>
>> The current problem is that gating on tests isn't currently turned on,
>> but Marco/Mims/GUI team are working on it.
>>
>> --
>> Jorge Castro
>> Canonical Ltd.
>> http://juju.ubuntu.com
>>
>> --
>> Juju mailing list
>> Juju at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>
>
> --
> 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/20130604/d5b3a0b5/attachment.html>


More information about the Juju mailing list