Re: [charms] Barbican + Identity Standalone - AWS

Very cool, thanks for sharing! On Wed, Nov 30, 2016 at 10:36 AM, James Beedy wrote: > Another great day of Juju driven successes - deploying the barbican > standalone stack for identity mgmt and secrets mgmt. For those that don't > know, newton horizon brings support for

Re: [charms] Barbican + Identity Standalone - AWS

Very cool, thanks for sharing! On Wed, Nov 30, 2016 at 10:36 AM, James Beedy wrote: > Another great day of Juju driven successes - deploying the barbican > standalone stack for identity mgmt and secrets mgmt. For those that don't > know, newton horizon brings support for

Re: kill-controller, unregister, destroy-controller

t unblock command seems better to me than either an >> explicit flag or an extra prompt, both of which are vulnerable to typing >> without thinking. Particularly if "throwaway" controllers created for >> testing purposes are not blocked by default, so you don't get used

Re: kill-controller, unregister, destroy-controller

of betas, and should be addressed *directly* rather than as they say "applying lipstick to a pig" On Thu, Sep 1, 2016 at 4:04 PM, Marco Ceppi <marco.ce...@canonical.com> wrote: > On Thu, Sep 1, 2016 at 9:59 AM Mark Ramm-Christensen (Canonical.com) < > mark.ramm-christen...@can

Re: kill-controller, unregister, destroy-controller

of betas, and should be addressed *directly* rather than as they say "applying lipstick to a pig" On Thu, Sep 1, 2016 at 4:04 PM, Marco Ceppi <marco.ce...@canonical.com> wrote: > On Thu, Sep 1, 2016 at 9:59 AM Mark Ramm-Christensen (Canonical.com) < > mark.ramm-christen...@can

Re: kill-controller, unregister, destroy-controller

I believe keeping the --destroy-all-models flag is helpful in keeping you from accidentally destroying a controller that is hosting important models for someone without thinking. On Thu, Sep 1, 2016 at 3:40 PM, Marco Ceppi wrote: > Hey everyone, > > I know we've had

Re: kill-controller, unregister, destroy-controller

I believe keeping the --destroy-all-models flag is helpful in keeping you from accidentally destroying a controller that is hosting important models for someone without thinking. On Thu, Sep 1, 2016 at 3:40 PM, Marco Ceppi wrote: > Hey everyone, > > I know we've had

Re: Go 1.6 is now in trusty-proposed

My point is not to advocate for a specific solution but rather to suggest that *any* sensible incremental approach will produce real results. --Mark Ramm On Mon, Mar 28, 2016 at 7:51 PM, David Cheney <david.che...@canonical.com> wrote: > On Tue, Mar 29, 2016 at 10:42 AM, Mark Ramm-Ch

Re: Go 1.6 is now in trusty-proposed

Never a good time to stop feature work entirely and fix what amounts to a race prone set of tests. But I would advocate building in some practices to improve the situation incrementally: - fixing one major issue per team per week - promoting all issues which fail CI more than x times per

Re: Use of Jujucharms to launch non-opensource code

Thanks Marco! On Tue, Feb 9, 2016 at 1:33 PM, Marco Ceppi wrote: > This is actually a non-issue. The codebase was moved to LGPL over a year > ago, there was just two places this was not updated. First LaunchPad and > second was the setup.py file. I've corrected both.

Re: Juju for Redhat linux

>> Does Juju work on Redhat linux platform ? > No, unfortunately not. The only supported OSs are Ubuntu and CentOS, and I'm not aware of any work in progress towards Red Hat. I'm sorry! Exactly RHEL isn't supported yet, but if CentOS is good enough for you the work is already done. If you want

Re: How to make Juju High Availability work properly?

Thanks for following up! We will take a look at the logs and get back to you soon. --Mark Ramm On Mon, Oct 26, 2015 at 4:41 AM, 曾建銘 wrote: > Hi Mark & Marco, > > Really appreciate your help. I have already provide the logs to Marco. > > Hope it could help you to enhance the

Re: What's the future of Juju?

Well, I can provide a few things off the top of my head that should help. - Canonical is fully committed to Juju as the way we deploy software internally, the way we deploy Open Stack clouds for our largest clients - Windows workloads are supported in the current beta version of Juju,

Re: disabling upgrades on new machines by default?

In practice, it almost never happens. I don't remember seeing anything actually from the archive break a charm on update -- though the cloud tools pocket did have a breakage about 8 months ago which did bad things. --Mark Ramm On Thu, Oct 2, 2014 at 10:14 AM, Matt Rae matt@canonical.com

Re: Juju is still too hard

I think we need to make sure that we do the best error reporting we can, so if Juju isn't working because of Azure issues, we should find some way to let users know that so that they can try another cloud, contact microsoft, or otherwise find another way forward. --Mark Ramm On Mon, Sep 22, 2014

Re: Unit Tests Integration Tests

On Thu, Sep 11, 2014 at 3:41 PM, Gustavo Niemeyer gust...@niemeyer.net wrote: Performance is the second reason Roger described, and I disagree that mocking code is cleaner.. these are two orthogonal properties, and it's actually pretty easy to have mocked code being extremely confusing and

Re: Unit Tests Integration Tests

On Fri, Sep 12, 2014 at 12:25 PM, Gustavo Niemeyer gust...@niemeyer.net wrote: On Fri, Sep 12, 2014 at 12:00 PM, Mark Ramm-Christensen (Canonical.com) mark.ramm-christen...@canonical.com wrote: I think the two issues ARE related because a bias against mocks, and a failure to separate out

Re: getting rid of all-machines.log

you'll have to be more specific, there's been a shotgun of statements in this thread, touching on logstash, aggregation removal, rsyslog removal, log rotation, deferring to stderr/stdout, 12factor apps, working with ha state servers, etc. I was referring to Nate's lumberjack package (PR

Re: Juju induction sprint summary

Great work, I am particularly happy to see that we have an incremental, and useful plan to take care of some of the technical debt in state.State. This is the classic form of technical debt as described by Ward Cunningham -- we have learned a good bit about the problem space and where

Re: Port ranges - restricting opening and closing ranges

My belief is that as long as the error messages are clear, and it is easy to close 8000-9000 and then open 8000-8499 and 8600-9000, we are fine. Of course it is nicer if we can do that automatically for you, but I don't see why we can't add that later, and I think there is a value in keeping a

Re: Juju is on github

WOOOT!!! On Tue, Jun 3, 2014 at 7:38 PM, Martin Packman martin.pack...@canonical.com wrote: Juju development is now done on github: https://github.com/juju/juju See the updated CONTRIBUTING doc for the basics. To land code you want the magic string $$merge$$ in a comment on the pull

Re: --constraints root-disk=16384M fails in EC2

The link to the bug is here: https://bugs.launchpad.net/juju-core/+bug/1324729 On Thu, May 29, 2014 at 7:26 PM, Ian Booth ian.bo...@canonical.com wrote: Hi Stein This does appear to be a bug in Juju's constraints handling for EC2. I'd have to do an experiment to confirm, but certainly