Re: JAAS outage this afternoon

Service should be restored now. Let us know in #juju on Freenode if you have any issues, but all should be well. On Mon, Jul 2, 2018 at 3:36 PM, Casey Marshall wrote: > We're currently dealing with an outage this afternoon in JAAS. Users will > be temporarily unable to add models

JAAS outage this afternoon

We're currently dealing with an outage this afternoon in JAAS. Users will be temporarily unable to add models until it is resolved; however, existing models are not impacted. Will provide an update when status changes. Hopefully will not be too much longer.. -Casey -- Juju mailing list

Re: Deploying a charm with t's & c's

Casey. The version of Juju I'm running is > 2.2.6-xenial-amd64 > > > Spicule Ltd > > Tel: 01603 327762 > > > > www.spicule.co.uk > > On Tue, Nov 28, 2017 at 6:30 PM, Casey Marshall < > casey.marsh...@canonical.com> wrote: > >> On Tue, Nov 28,

Re: Deploying a charm with t's & c's

ocal bundle we were testing, just exported from the gui, Ste > can provide it if you need it. > Thanks for clarifying. One last question, what version of Juju was used on the command line when trying to deploy the exported bundle? > > Tom > > > On 28 Nov 2017 6:00 pm, "C

Re: Deploying a charm with t's & c's

On Tue, Nov 28, 2017 at 10:50 AM, Stephen Downie wrote: > Thanks. I have tried running juju agree spiculecharms/pdi-terms/1 and it > states terms already agreed? > > When trying to deploy in the GUI it returns the error message cannot > create bundle: already exists. It

Re: Deploying a charm with t's & c's

On Tue, Nov 28, 2017 at 5:59 AM, John Meinel wrote: > Do you know what terms you need to accept? You should be able to 'juju > accept termname'. > The other thing to check is if your local clock time is fairly accurate. > I believe we filed a bug recently that the term

Planned Maintenance Advisory (Service Affecting): JAAS; 2017-08-31, 1800-2200 UTC

age exceeds these expectations, we will post updates on our status & progress. Thank you, Casey Marshall Canonical - Cloud Online Services -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju

Re: How to quickly re-deploy the same charm

With juju 2, you can also use --force-units to upgrade the charm even in an error state: juju upgrade-charm --path /path/to/mycharm --force-units mycharm The unit agent will then usually retry the hook that's failing automatically, but you can use `juju resolved` on the unit(s) without the

Re: Juju 2.2-rc2 has been released

On Fri, Jun 9, 2017 at 12:29 PM, Uros Jovanovic < uros.jovano...@canonical.com> wrote: > Quick instructions on how the new azure credentials flow works in Juju > 2.2-RC2: > > # install az client using a snap > $ sudo snap install azure-cli --classic --edge > I've pushed the snap to stable, so

Re: Juju 2.2-rc2 has been released

On Fri, Jun 9, 2017 at 12:29 PM, Uros Jovanovic < uros.jovano...@canonical.com> wrote: > Quick instructions on how the new azure credentials flow works in Juju > 2.2-RC2: > > # install az client using a snap > $ sudo snap install azure-cli --classic --edge > I've pushed the snap to stable, so

Re: Orchestration charms

Hi Simon, I'm glad you asked about this. The need for certain services to operate on the controller for autoscaling and other purposes has come up before. Juju's considering exposing different aspects of the controller as applications -- for monitoring, log access and other aspects of operating

Re: Opaque automatic hook retries from API

^^ s/immutability/idempotency On Thu, Jan 5, 2017 at 12:39 PM, Casey Marshall < casey.marsh...@canonical.com> wrote: > On Thu, Jan 5, 2017 at 3:33 AM, Adam Collard <adam.coll...@canonical.com> > wrote: > >> Hi, >> >> The automatic hook retries[0] tha

Re: Opaque automatic hook retries from API

On Thu, Jan 5, 2017 at 3:33 AM, Adam Collard wrote: > Hi, > > The automatic hook retries[0] that landed as part of 2.0 (are documented > as) run indefinitely[1] - this causes problems as an API user: > > Imagine you are driving Juju using the API, and when you perform

Re: A (Very) Minimal Charm

On Thu, Dec 1, 2016 at 6:53 AM, Marco Ceppi wrote: > On Thu, Dec 1, 2016 at 5:00 AM Adam Collard > wrote: > >> On Thu, 1 Dec 2016 at 04:02 Nate Finch wrote: >> >> On IRC, someone was lamenting the fact that the

Re: A (Very) Minimal Charm

On Thu, Dec 1, 2016 at 6:53 AM, Marco Ceppi wrote: > On Thu, Dec 1, 2016 at 5:00 AM Adam Collard > wrote: > >> On Thu, 1 Dec 2016 at 04:02 Nate Finch wrote: >> >> On IRC, someone was lamenting the fact that the

Re: Complex store queries

On Mon, Oct 24, 2016 at 6:15 AM, Merlijn Sebrechts < merlijn.sebrec...@gmail.com> wrote: > +1 for "which charms use this layer" queries. This has a number of uses: > > - for finding what the quality of a layer is (more use in recommended > charms = better quality) > - for the maintainer of a

Re: [ANN] Mattermost and layer:lets-encrypt

On Mon, Oct 24, 2016 at 3:51 AM, Andrew Wilkins < andrew.wilk...@canonical.com> wrote: > On Sun, Oct 16, 2016 at 12:07 AM Casey Marshall < > casey.marsh...@canonical.com> wrote: > >> With a much appreciated recent contribution from James Beedy (bdx) our >> Matter

[ANN] Mattermost and layer:lets-encrypt

With a much appreciated recent contribution from James Beedy (bdx) our Mattermost charm cs:~cmars/mattermost[1] is working again! This encouraged me to add some followup improvements to the charm to make it even easier to deploy with secure defaults -- automatic registration with Let's Encrypt.

Re: Github Reviews vs Reviewboard

+1, as I work on many other Github projects besides Juju and it's familiar. It's not perfect by any means but I can work with it. I thought the ReviewBoard we had was pretty ugly and buggy, but it was reasonably easy to use. Gerrit is cleaner and clearer to me -- though I feel like Gerrit is also

ANN: Metrics in Juju 2.0

I’m pleased to announce Juju Metrics, new in Juju 2.0! Knowing an application's configuration isn’t enough to effectively operate and manage it. Consider that a well-designed application will have as few configurable parameters as possible. As an operator, you may find yourself wanting to know

Re: Proposal: DNS for Juju Charms

Awesome idea! Probably more of a wishlist thing at this point.. but can we also add SSHFP records for all the units? -Casey On Sat, Sep 24, 2016 at 11:47 AM, Marco Ceppi wrote: > Hey everyone, > > I'm currently working on a charm for NS1, which is a DNS service >

Re: How to offer debugging help for stuck controller

Hi Tom, Sorry to hear you're having trouble.. I think there might be something interesting in the controller logs that could help us fix it. If you can ssh into the controller machine, could you tar up the logs in /var/log/juju and attach to a Launchpad bug (

Re: Reviews on Github

I'm halfway through my first Github review (different project though) on the new system, and so far I'm loving it. Also consider the issues we've had with rbt being unable to handle diffs with files added/removed/relocated. +1 from me! -Casey On Wed, Sep 14, 2016 at 3:23 PM, Reed O'Brien

Re: Latest new about Juju master branch - upload-tools obsoleted

I discovered another trick that works: set the streams and urls to invalid values in your bootstrap config. This will force Juju to use an already compiled jujud in your $PATH. For example, bootstrap --config with: image-metadata-url: http://localhost image-stream: nope agent-metadata-url:

Re: kill-controller, unregister, destroy-controller

My main use case for killing controllers is development & testing. For this, I have a script that force deletes all the juju-* LXC containers, and then unregisters all controllers with cloud: lxd. It's *much* faster than waiting for each juju controller to tear itself down. It's also nothing I'd

Re: Faster LXD bootstraps and provisioning

I decided it'd be easier & safer to host squid-deb-proxy in a LXD container rather than the host. My host doesn't route inbound to LXD from other networks, and all the Juju machines can see it. On Tue, Aug 16, 2016 at 12:30 AM, John Meinel wrote: > ... >> > > >> +###

Re: Faster LXD bootstraps and provisioning

I decided it'd be easier & safer to host squid-deb-proxy in a LXD container rather than the host. My host doesn't route inbound to LXD from other networks, and all the Juju machines can see it. On Tue, Aug 16, 2016 at 12:30 AM, John Meinel wrote: > ... >> > > >> +###

Re: Faster LXD bootstraps and provisioning

Menno, This is great and thanks for sharing! In case anyone else runs into this.. charms that install from PPAs will fail with this squid-deb-proxy setup. You'll need to allow archive mirrors for this to work. See https://1337.tips/ubuntu-cache-packages-using-squid-deb-proxy/ for an example. On

Re: Faster LXD bootstraps and provisioning

Menno, This is great and thanks for sharing! In case anyone else runs into this.. charms that install from PPAs will fail with this squid-deb-proxy setup. You'll need to allow archive mirrors for this to work. See https://1337.tips/ubuntu-cache-packages-using-squid-deb-proxy/ for an example. On

Re: So I wanted to update a dependency . .

On Thu, Aug 11, 2016 at 5:44 PM, Nicholas Skaggs < nicholas.ska...@canonical.com> wrote: > This is a simple story of a man and a simple mission. Eliminate the final > 2 dependencies that are in bazaar and launchpad. It makes juju and it's > dependencies live completely in git. A notable goal, and

Updating relation info during charm upgrades

I need some help with understanding the best way to manage relation info across an application's lifecycle with the reactive framework. I'll start with the situation that brings me here: I have a reactive charm that provides some fairly static relation info: nagios checks over the

Automatic hook retries in Juju 2.0

What is the intended behavior for automatic hook retries in Juju 2.0? Specifically, I'd like to know, as a Juju user: Are errors in hooks all retried with the same policy, or are some retried with a different policy / strategy than others (install, for example)? Is there a limit to the number

Re: Awful dependency problem caused by romulus

Matty, this sounds like a great idea. Dave, I understand and thanks for clarifying. Please give us some time to coordinate the package relocation in our next iteration (begins next week). Thanks, Casey On Thu, May 19, 2016 at 2:57 AM, David Cheney wrote: > Thanks

Re: Awful dependency problem caused by romulus

On Wed, May 18, 2016 at 11:02 PM, David Cheney wrote: > Hello, > > github.com/juju/juju/cmd/juju/commands: > github.com/juju/romulus/cmd/commands: > github.com/juju/romulus/cmd/setplan: < > github.com/juju/juju/api/service: >

Re: Connecting to the controller database w/mongodb 3.2

send you links > > Well, for use case #1, yes, use the shell. For use case #2, I'd be using github.com/dcu/mongodb_exporter, which uses mgo.v2 and just needs a mongodb URI <https://github.com/dcu/mongodb_exporter/blob/master/mongodb_exporter.go#L26> . > On Friday, 13 May 201

Connecting to the controller database w/mongodb 3.2

I seem to be unable to connect to the Juju 2.0 controller database lately. I'm thinking this might be related to the move to mongodb 3.2. Can someone in the know please share how to do this? While most users should never, ever connect directly to the controller's database, I have two good use

Re: Reminder: write tests fail first

An excellent demonstration of writing tests that fail first that I've seen recently: https://www.youtube.com/watch?v=PEbnzuMZceA On Wed, May 4, 2016 at 9:24 PM, Andrew Wilkins wrote: > See: https://bugs.launchpad.net/juju-core/+bug/1578456 > > Cheers, > Andrew > >

Re: LXD v2.0.0-rc8 does not work with Juju v2.0-beta3

On Wed, Apr 6, 2016 at 2:51 PM, Alexis Bruemmer < alexis.bruem...@canonical.com> wrote: > > Hi All, > > As recently highlighted in bug https://bugs.launchpad.net/bugs/1566589 the > latest LXD will not work with Juju 2.0-beta3. This is a result of LXD > moving to use a default bridge of lxdbr0

Re: LXD v2.0.0-rc8 does not work with Juju v2.0-beta3

On Wed, Apr 6, 2016 at 2:51 PM, Alexis Bruemmer < alexis.bruem...@canonical.com> wrote: > > Hi All, > > As recently highlighted in bug https://bugs.launchpad.net/bugs/1566589 the > latest LXD will not work with Juju 2.0-beta3. This is a result of LXD > moving to use a default bridge of lxdbr0

Re: Proposal: Charm testing for 2.0

On Wed, Mar 16, 2016 at 7:52 PM, Marco Ceppi wrote: > Hello everyone! > > This is an email I've been meaning to write for a while, and have > rewritten a few times now. With 2.0 on the horizon and the charm ecosystem > rapidly growing, I couldn't keep the idea to

Re: Reactive roadmap

Simon, You raise some very interesting questions and good points. I've also been developing charms with layers, run into some of these same issues, and developed a pragmatic approach that has helped me manage it pretty well so far. In a more mature layer/interface ecosystem, it might not be the

Re: LXD Bootstrap

after booting up my laptop this morning, opened a bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1551854 > > thanks, > -serge > > Quoting Casey Marshall (casey.marsh...@canonical.com): > > On Mon, Feb 29, 2016 at 4:57 PM, Tom Barber <t...@analytical-labs.com&g

Re: utils/fslock needs to DIAF

How about github.com/camlistore/lock ? On Mon, Nov 30, 2015 at 5:43 PM, Tim Penhey wrote: > Hi folks, > > The fslock was a mistake that I added to the codebase some time back. It > provided an overly simplistic solution to a more complex problem. > > Really the

Re: Inconsistencies between juju debug-hooks and "normal" hook environment

On Wed, Oct 21, 2015 at 1:49 PM, Cory Johns wrote: > Matty, > > I do think that a bug should be opened for it, and I will do so. Is LP > still the better place to open the bug vs GitHub? > Yes, please open the bug in Launchpad. Thanks, Casey > > On Wed, Oct 21,

Re: Juju 1.24.7 is proposed for stable release

I just upgraded to 1.24.7 and tried bootstrapping, got this message: Starting new instance for initial state server WARNING failed to find 1.24.7 tools, will attempt to use 1.24.6 Is there a problem with the publish to 'proposed' simple-streams? -Casey On Thu, Oct 15, 2015 at 3:14 PM, John

Re: Juju 1.24.7 is proposed for stable release

On Fri, Oct 16, 2015 at 2:29 PM, Curtis Hovey-Canonical < cur...@canonical.com> wrote: > On Fri, Oct 16, 2015 at 2:06 PM, Casey Marshall > <casey.marsh...@canonical.com> wrote: > > I just upgraded to 1.24.7 and tried bootstrapping, got this message: > > > > Sta

Graduated Juju core reviewer: Aleš Stimec

All, I'm pleased to announce Aleš Stimec is now a graduated Juju core reviewer. His recent contributions and improvements to the Juju unit agent, command-line infrastructure and API login clearly demonstrate a depth and breadth of Juju core knowledge befitting this role. Welcome Aleš, and well

Fix for LP: #1174610 landing (unit ids should be unique)

Just a friendly heads-up.. a fix for this longstanding bug will be landing into master shortly: LP: #1174610, unit ids should be unique What this fix essentially does is assign each deployed workload a distinct unit ID (incrementing sequentially) within the scope of an environment. Example: 1.

Graduated reviewer: Domas Monkus

Juju developers, I would like to announce Domas Monkus is a fully graduated Juju core reviewer. This announcement is really long overdue.. Domas is careful and thoughtful in his reviews, his feedback is useful, actionable and relevant, and he's landed several significant improvements that

Re: Proposal: feature flag implementation for Juju

+1 for feature flags in general and +1 for using environment variables in upstart to get them to the servers agents. I think it'd be nice to have an environment variable per flag, with a common prefix JUJU_FEATURE_. That way, if you need to check one in a package init(), you don't have to parse

Re: Reminder: juju-core github migration

On 06/02/2014 11:57 AM, Martin Packman wrote: On 02/06/2014, roger peppe rogpe...@gmail.com wrote: What is the policy around rebasing before commenting with $$merge$$ ? Does this need to be done? If not, how does the merge procedure decide what commit message gets attached to the final merge?

juju-nat: Easy NAT routing for services in LXC containers

All, I'd like to share a small set of juju plugins I've developed: https://github.com/cmars/juju-nat The juju nat-* commands automate the tedious process of port forwarding and routing for services deployed into LXC containers. I like to use it with the manual provider for my personal stuff, or