There are two distinct features aiming for 1.21 which address your needs:
* multiple environments in a single juju server
* multiple users in a single juju server
The combination will allow you to:
* bootstrap Juju once (perhaps across a few servers for HA)
* create several user accounts
1. The following branch adds a simple backup mechanism to mysql. +1 (I
would land it but since it's one of my first reviews I'll wait for
feedback on here before I do).
https://code.launchpad.net/~jacekn/charms/trusty/mysql/mysql-backups/+merge/245343
2. This branch adds an optional apt source
On 22 January 2015 at 15:13, David Britton david.brit...@canonical.com wrote:
lint:
- make lint
Could we also make[1] the charm linter lint the makefile for the
presence of targets agreed in the outcome of this thread?
[1] Pun fully intended :)
--
Simon
--
Juju mailing list
On Thu, Jan 22, 2015 at 10:13 AM, David Britton david.brit...@canonical.com
wrote:
functional tests:
- make functional-test
We need to be careful about things like this - as bundletester is already
looking in tests/ for the amulet suite and might end up running the
integration tests
Attached are the meeting notes that came from the ~charmer quorem that took
place today. We encourage your feedback on any meeting items discussed, and
welcome proposed agenda items for the next meeting.
I'm attaching Markdown inline, and there is a PDF attachment for anyone who
doesn't enjoy
Thanks for pointing out the yaml control file, that could be useful. But
before we make any modifications to the OpenStack charms, I think it would
be helpful to have an agreed-upon convention for the following in terms of
Makefile target names:
- nose / unit tests
- make test
-
+1, but I would propose using hyphens for word separators, not
underscores -- at least for the recommendation. I would also recommend
*not* having multiple default names.
As mentioned, the yaml control file I think can be used to override all
this, so it still leaves room for individual
Same here, the OpenStack charms have charm proof in the lint target. I
expect it would be run twice in that case.
On Thu, Jan 22, 2015 at 10:36 AM, Simon Davy bloodearn...@gmail.com wrote:
On 22 January 2015 at 16:29, David Britton david.brit...@canonical.com
wrote:
On Thu, Jan 22, 2015 at
On 22 January 2015 at 16:36, Simon Davy bloodearn...@gmail.com wrote:
On 22 January 2015 at 16:29, David Britton david.brit...@canonical.com
wrote:
On Thu, Jan 22, 2015 at 04:17:26PM +, Simon Davy wrote:
On 22 January 2015 at 15:13, David Britton david.brit...@canonical.com
wrote:
Marco, I like your proposal with one change - we don't need the test.yaml
changes. Instead I would suggest we add 'unit-test' to the list of default
bundletester targets. So bundletester will run proof, lint, test, and
unit-test (charm author should choose test or unit-test, not both).
On 22 January 2015 at 16:29, David Britton david.brit...@canonical.com wrote:
On Thu, Jan 22, 2015 at 04:17:26PM +, Simon Davy wrote:
On 22 January 2015 at 15:13, David Britton david.brit...@canonical.com
wrote:
lint:
- make lint
Could we also make[1] the charm linter lint the
We can also add Makefile checking to charm proof, for an even greater
redundancy.
To avoid multiple invocations of charm proof (not terrible, IMO) lint could
be broken down further:
lint: proof code_lint
proof:
charm proof
code_lint:
# Your code here
Then have bundle tester sniff out
On Thu, Jan 22, 2015 at 04:57:36PM +, Marco Ceppi wrote:
test: lint unit-test functional-test
-1, I'd rather 'test' be unit testing only. Many charms have this
already and it seems like unecessary busy work to change it.
```
makefile:
- code-lint
- unit-test
```
-1, vote for
13 matches
Mail list logo
