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: 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 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: 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: 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: 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: 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: 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

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

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: [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