Re: Multi user account management in juju
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 on that Juju server * those users can then create environments as and when they need them * each environment has its own cloud credentials * the user can share the environment with selected other users You're seeing the first parts of support for that combination show up in the GUI now, but 1.21 will be the first cut of a release with those capabilities. It will work for both the command line and the GUI, of course :) The main benefits of this are: * fewer machines devoted to Juju and more to actual workloads * faster environment startup (you re-use the existing Juju server) * easier onramp for new users (bootstrap is hard, do it once HA) * sharing of environments between a group of admins Hope that helps, Mark On 19/01/15 14:15, Rick Harding wrote: Note that this is pre-support for a new feature in Juju 1.21 which is not yet released. This is multiple users accessing the same deployed environment and doesn't seem to quite match the requirements. Rick Harding On Mon, Jan 19, 2015 at 4:50 AM, Vahric Muhtaryan vah...@doruk.net.tr wrote: Today I red the juju-gui 1.3.0 release , its supporting multiple user https://jujugui.wordpress.com/2015/01/14/juju-gui-1-3-0-release/ From: Malshan Peiris mals...@hsenidmobile.com Hi all, Is there a way in juju to do following (We are going to use AWS as deploy target and ubuntu 14.04 as client). 1) Have multiple user accounts for juju-gui, where a certain user will only see his/her work area. If possible, a reserved machine for a single user. Currently I only know to confiure a single admin password. 2) Same as above, but deployment using juju command line. So individual users should have unique keys to AWS account where they can only affect a specific AWS instance, not the whole account (so they can't add / remove AWS instances). -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
[Review Queue] Mysql, HAProxy
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 to HAProxy, and seems ok as well. Note: the automated tests failed initially but it seems simply to have been a timeout problem with Azure and not a genuine problem, as a re-run of the tests passed. This made me realize the haproxy charm should sync charm-helpers to make use of some newer additions to it, such as retying when the apt lock cannot be acquired, but that is an independent remark (out of scope for this particular branch in my opinion). +1'd https://code.launchpad.net/~free.ekanayaka/charms/trusty/haproxy/custom-apt-source-support/+merge/247116 - Chris -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Makefile target names
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 Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Makefile target names
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 multiple times according to the make target + bundletesters sniffer. This is kind of an overlap of concerns with how bundletester works and I feel warrants caution. Tim would know best on the behavior here, and can recommend / amend as required. -- All the best, Charles Butler charles.but...@canonical.com - Juju Charmer Come see the future of datacenter orchestration: http://jujucharms.com -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Meeting Notes from Charmer Quorem [1/22/2015]
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 reading markdown. #Charmers Meeting Notes ## Minutes from 01-22-2015 Members Present: - mbruzek - jose - marcoceppi - tvansteenburgh - lazypower ## Meeting Item 1 Proposed: marcoceppi Topic: Hours for meeting. Alternate / stagger the meeting times so people outside of US timezones are accounted for and able to attend. Plan the next meeting at the end of the current meeting vs having a set schedule which yields days in which we are not able to attend due to travel and other reasons. Resolution: TODO assigned: mbruzek ## Meeting Item 2 Proposed: lazypower Topic: Charmer Meetings made more public Charmer meetings should be Ubuntu On Air / Public - to promote community involvement and take the planning process out from closed doors. The store is part of the community and it should be presented as such. Voting: - jose: +1 - mbruzek: +1 - marcoceppi: +1 - tvansteenburgh: +1 - lazypower: +1 ## Meeting Item 3 proposed: jose Topic: Review Queue Woes Review queue is a pain point from an ingestion standpoint, with items getting stuck in the queue and not showing up when we would expect them to. Move the Review Queue to Canonical IS Response: Canonical IS will not run the queue in its current state due to the technology contained therein. The code is kind of hacky - and have some plans to refactor out the hacks, and time to implement said fixes is pending additional time to work. Adding admins to the system requires documentation, and adding trusted members to re-launch the jobs when the queue is in a stuck state. Resolution: pending, however issues are identified and task items assigned ## Meeting Item 4 proposed: marcoceppi Topic: Documentation Docs - sent many notices over this last month. Moving to a version locked number and the doc quality are still fairly lacking in charm authorship. As ~charmers we need to own this section and contribute to this cleanup effort. Resolution: pending, coordinate with other charmers on the mailing list. ## Meeting Item 5 proposed: marcoceppi Topic: Makefiles (subject on the list) Add makefile target to `charm proof` as a target, subject when missing is I: on charm proof. If present, lint for proper target, and set as W: when targets are not in compliance with policy for CI Makefile templating is great, and document the proper targets for CI. However linting the makefile doesn't necessarily make sense. Bundletester already checks for tests in `tests/*` that are +x. There is also a limitation on people who don't know makefiles, and aren't exciting about adding a makefile to their charm. Ammended resolution: Remove W's and keep the template + I: message when missing. Voting: - marcoceppi: +1 - jose: +1 - mbruzek: +1 - tvansteenburgh: +1 - lazypower: +1 Resolution: TODO: Add template makefile, and update existing charm templates with template makefile. Update docs regarding makefile inclusion, and what is tested on our infrastructure. Next Meeting Date Proposed: 2PM UTC - Feb 16'th -- All the best, Charles Butler charles.but...@canonical.com - Juju Charmer Come see the future of datacenter orchestration: http://jujucharms.com meeting-notes-01222015.pdf Description: Adobe PDF document -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Makefile target names
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 - make unit_test - Both are in use. - 2 cents: I would reserve both of these for unit tests, never for amulet tests. - lint checks - make lint - Already unified on this afaict. - amulet tests - make test - make functional_test - Both are in use. - 2 cents: I think functional_test leaves no question as to usage. - charm-helpers sync - make sync - Already unified on this afaict. If there is not a documented convention, can we have the necessary discussions here to create one? Thanks again, Ryan On Wed, Jan 21, 2015 at 11:40 AM, Benjamin Saller benjamin.sal...@canonical.com wrote: While convention is great there is an additional path, you can if your project differs from the de facto standards, include an explicit list of targets in your tests/tests.yaml file makefile: - lint - unit_test - something_else That file allows customization of much of bundletesters policy. -Ben On Wed, Jan 21, 2015 at 9:05 AM, Ryan Beisner ryan.beis...@canonical.com wrote: Greetings, I'd like to invite discussion on Makefile target names. I've seen a few different takes on Makefile target naming conventions across charms. For example, in the OpenStack charms, `make test` runs amulet and `make unit_test` performs nose tests. In many/most other charms, `make test` infers unit/nose testing, and amulet target names can vary. As I understand bundletester: it expects `make test` to be unit tests. Amulet targets in the Makefile aren't processed if they exist. Instead, the executables in the test dir are fired off. And, I think that should all be quite fine as long as the charm's amulet make target isn't doing anything important. The net effect for OpenStack charms at the moment is that when they hit Juju QA, amulet fires off twice, and unit is not run. I'd like to make sure the OpenStack charms are in line with any established Makefile convention. Is there a reference or doc for such a convention? I've seen 'unit_test' and 'functional_test' target names in use as well, and I quite like those, as they leave no question as to purpose. To work around the variations we've seen across charms, server team's OSCI (OpenStack CI charm testing) ignores make target names, and instead parses the Makefile, looking for the right thing-to-do, then execs the target found. Bear in mind that OSCI isn't intended to be a replacement for general charm QA, rather it is an intense safety trigger for the OpenStack charm developers. We also want these charms to succeed in Juju QA / CI. Input and advice are much appreciated! Many thanks, Ryan Beisner -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Makefile target names
+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 preferences on the exact namings. unit tests: - make test unit tests dependencies: - make test-depends functional tests: - make functional-test lint: - make lint charm-helpers upstream sync: - make sync -- David Britton david.brit...@canonical.com -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Makefile target names
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 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 makefile for the presence of targets agreed in the outcome of this thread? charm proof I like it. (bundle tester already runs this) Which is interesting, as my lint targets general runs charm proof too, so it'd be run twice in that case? Not a big issue, but if the charm store/review queue is automatically charm-proofing too, perhaps the make lint target should not be? -- Simon -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Makefile target names
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: 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? charm proof I like it. (bundle tester already runs this) Which is interesting, as my lint targets general runs charm proof too, so it'd be run twice in that case? Not a big issue, but if the charm store/review queue is automatically charm-proofing too, perhaps the make lint target should not be? -- Simon Whelp it's still nice to have as part of lint when developing the charm, and charm-proof isn't exactly the slowest process to run multiple times. -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Makefile target names
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). Bundletester will *not* run functional-test, since it runs everything +x in the tests/ dir, which almost always overlaps with functional-test. On Thu, Jan 22, 2015 at 11:57 AM, Marco Ceppi ma...@ondina.co wrote: 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 code_lint, or use the test.yaml configuration to point lint to code_lint. Doesn't change UX for the author/contributor but does add a level of complexity. It seems like Makefile's are the overwhelming method for consolidating tasks for charms, I'd like to kick off the following proposal for Makefile format to be placed in charm create templates: ``` test: lint unit-test functional-test lint: proof code-lint sync: charm-helpers-sync code-lint: # FILL IN COMMANDS FOR PERFORMING CODE LINT unit-test: # COMMANDS REQUIRED TO UNIT TEST charm-helpers-sync: @scripts/sync.py functional-test: juju test proof: charm proof ``` With a test.yml file that contained the following: ``` makefile: - code-lint - unit-test ``` And where applicable, add a .venv target for python charms and recommend the use of having charm deps modeled in requirements.txt and pip installed to that virtualenv. Opinions, additions, concerns? On Thu Jan 22 2015 at 11:41:56 AM Wes Mason wesley.ma...@canonical.com wrote: 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: 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? charm proof I like it. (bundle tester already runs this) Which is interesting, as my lint targets general runs charm proof too, so it'd be run twice in that case? Not a big issue, but if the charm store/review queue is automatically charm-proofing too, perhaps the make lint target should not be? -- Simon Whelp it's still nice to have as part of lint when developing the charm, and charm-proof isn't exactly the slowest process to run multiple times. -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/ mailman/listinfo/juju -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Makefile target names
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 makefile for the presence of targets agreed in the outcome of this thread? charm proof I like it. (bundle tester already runs this) Which is interesting, as my lint targets general runs charm proof too, so it'd be run twice in that case? Not a big issue, but if the charm store/review queue is automatically charm-proofing too, perhaps the make lint target should not be? -- Simon -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Makefile target names
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 code_lint, or use the test.yaml configuration to point lint to code_lint. Doesn't change UX for the author/contributor but does add a level of complexity. It seems like Makefile's are the overwhelming method for consolidating tasks for charms, I'd like to kick off the following proposal for Makefile format to be placed in charm create templates: ``` test: lint unit-test functional-test lint: proof code-lint sync: charm-helpers-sync code-lint: # FILL IN COMMANDS FOR PERFORMING CODE LINT unit-test: # COMMANDS REQUIRED TO UNIT TEST charm-helpers-sync: @scripts/sync.py functional-test: juju test proof: charm proof ``` With a test.yml file that contained the following: ``` makefile: - code-lint - unit-test ``` And where applicable, add a .venv target for python charms and recommend the use of having charm deps modeled in requirements.txt and pip installed to that virtualenv. Opinions, additions, concerns? On Thu Jan 22 2015 at 11:41:56 AM Wes Mason wesley.ma...@canonical.com wrote: 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: 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? charm proof I like it. (bundle tester already runs this) Which is interesting, as my lint targets general runs charm proof too, so it'd be run twice in that case? Not a big issue, but if the charm store/review queue is automatically charm-proofing too, perhaps the make lint target should not be? -- Simon Whelp it's still nice to have as part of lint when developing the charm, and charm-proof isn't exactly the slowest process to run multiple times. -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/ mailman/listinfo/juju -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Makefile target names
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 'lint', 'test' (unit test only) at this level, and agree with Tim that it's redundnat to print these out, we should make the recommeneded defaults what bundletester supports. All else I agree with. -- David Britton david.brit...@canonical.com -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
