juju stable 1.21.0 is proposed for release
# juju-core 1.21.0 A new proposed stable release of Juju, juju-core 1.21.0, is now available. This release may replace 1.20.14 on Thursday January 29 after a period of evaluation. ## Getting Juju juju-core 1.21.0 is available for utopic and backported to earlier series in the following PPA: https://launchpad.net/~juju/+archive/proposed The proposed packages in this archive use the proposed simple-streams. You must configure the 'agent-stream' option in your environments.yaml to use the matching juju agents. agent-stream: proposed ## Notable Changes * Selecting provisioner harvest modes * Using apt mirrors * Configuring OS update and upgrade for faster provisioning * Using daily image streams for faster provisioning * Selecting the agent stream to get alternate version of Juju * Tuning Juju to take advantage of NUMA * Configuring the MAAS network rules * Improved availability zone selection in Openstack and MAAS * Juju now prefers SSD storage in AWS * Adding many machines * Choosing the nodes used to ensure high availability * Inspecting the API connection settings * Managing who can connect to the Juju environment * Upgrade robustness * Rebooting units from charm hooks * Improvements to ports management for charms * Developing Juju providers for clouds without storage * More mirrors for faster bootstraps ### Selecting provisioner harvest modes Juju keeps a model of what it thinks the environment looks like, and based on that model, can harvest machines which it deems are no longer required. This can help keep your costs low, and keep you out of web consoles. Juju supports several harvesting modes to suit your needs. Destroyed: Juju will harvest only machine instances that are marked as dead, and that Juju knows about. Running instances unknown to Juju will not be harvested. This is the default mode. Unknown: Juju will harvest only instances that Juju does not know about. All: Juju will terminate all instances – destroyed or unknown – that it finds. This is a good option if you are only utilizing Juju for your environment. None: Juju won't harvest any machines. This is the most conservative mode, and a good choice if you manage your machines utilizing a separate process outside of Juju. Juju's harvesting behaviour is set through the environments.yaml file. provisioner-harvest-mode: 'provisioner-harvest-mode' replaces 'safe-mode'. Environments with 'safe-mode' set will be converted to 'provisioner-harvest-mode' when upgraded. ### Using apt mirrors You can now configure 'apt-mirror' in environments.yaml to specify the mirror used by all the machines provisioned in the environment: apt-mirror: http://my.archive.ubuntu.com On precise, the cloud tools archive is now pinned before calling apt upgrade to ensure its packages are a lower priority than the default precise archives. Charms developed on precise will see the same packages when deployed into a Juju provisioned machine. If your precise charm requires packages from the cloud tool's archive, you can use the 'target-release' option to specify the archive to select: apt-get --target-release precise-updates/cloud-tools my-package ### Configuring OS update and upgrade for faster provisioning When Juju provisions a machine, its default behaviour is to update the list of available packages and upgrade the existing packages to the latest version. If your OS images are fresh or the services you deploy do not require updated packages, you can disable updates and upgrades to provision the machine faster. Two configuration options are available to disable apt updates and upgrades. When your OS images are fresh, you can set both 'enable-os-refresh-update', and 'enable-os-upgrade' to false. When you know that some charms want the latest packages to to set up services, you will want to keep 'enable-os-refresh-update' set to "true". You can configure the options in environments.yaml for fast provisioning like so: enable-os-upgrade: false enable-os-refresh-update: false The local provider skips apt upgrades by default for faster provisioning. If you wish to enable upgrades in your local development, set 'enable-os-upgrade' to "true" in your environments.yaml: enable-os-upgrade: true Document best practices purging or updating /var/cache/lxc and juju-*-lxc-templates so that they are fresh for charm developers. ### Using daily image streams for faster provisioning Juju prefers to use the slow-changing "released" images when provisioning machines. The 'image-stream' option in environments.yaml can be set to "daily" use more up-to-date images, thus shortening the time it takes to perform apt-get update/upgrade. While this feature has existed since 1.18.0, it was not applied consistently to KVM containers. KVM containers will now use "daily" when environments.yaml is set to: image-stream: daily ### Selecting the agent stream to get alternate version of Juju The 'ag
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 - 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
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 -- 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 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 > wrote: > >> On 22 January 2015 at 16:36, Simon Davy wrote: >> >>> On 22 January 2015 at 16:29, David Britton >>> 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
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 wrote: > On 22 January 2015 at 16:36, Simon Davy wrote: > >> On 22 January 2015 at 16:29, David Britton >> 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 22 January 2015 at 16:36, Simon Davy wrote: > On 22 January 2015 at 16:29, David Britton > wrote: > > On Thu, Jan 22, 2015 at 04:17:26PM +, Simon Davy wrote: > >> On 22 January 2015 at 15:13, David Britton > 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
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 wrote: > On 22 January 2015 at 16:29, David Britton > wrote: > > On Thu, Jan 22, 2015 at 04:17:26PM +, Simon Davy wrote: > >> On 22 January 2015 at 15:13, David Britton > 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:29, David Britton wrote: > On Thu, Jan 22, 2015 at 04:17:26PM +, Simon Davy wrote: >> On 22 January 2015 at 15:13, David Britton >> 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 Thu, Jan 22, 2015 at 04:17:26PM +, Simon Davy wrote: > On 22 January 2015 at 15:13, David Britton > 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) -- David Britton -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Makefile target names
Yep absolutely, we want to make sure we're in line with the existing tools. After talking with Tim, the way I understand it, bundletester doesn't use the Makefile for amulet tests. Instead, it execs everything which is +x in the tests dir (a la juju test). On Thu, Jan 22, 2015 at 9:51 AM, Charles Butler < charles.but...@canonical.com> wrote: > > 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 - 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
Re: Makefile target names
On 22 January 2015 at 15:13, David Britton 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 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 - 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
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 -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Makefile target names
On 01/22/2015 03:57 PM, Ryan Beisner wrote: > 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. +1. >- lint checks > - make lint > - Already unified on this afaict. +1 >- 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 +1 for functional_test Also, at the recent mtg it was mentioned that automated test suite doesn't care for 'functional_test' target, presumably because amulet tests are run with 'juju test', so make target is actually not needed. But to avoid confusion I'm +1-ing again 'functional_test. Maybe worth mentioning - the MongoDB charm I inherited has .venv target that prepares venv for unit_tests to be run. Shall this also be a standard? The issue with this approach is that only 'running' series are tested - if I'm on precise, then I'll be unit_testing precise, if I upgraded to utopic, then I'd be testing utopic, etc... In that light - shall .venv remain as it is, or? Mario -- 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 > 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: 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 > 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 >> >> 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
