Re: Juju's dependencies, juju/utils and a road forward

I agree wholeheartedly about splitting up the utils package. We talked about this potential issue when it was initially created (and named "trivial", for trivial functionality with no better place and no dependencies). The dependency graph is crucial - one of the main reasons that utils is

Re: Juju 2.3 beta2 is here!

On 10 November 2017 at 10:40, Dmitrii Shcherbakov wrote: > This might not be an ideal example after all. However, I encountered > something else in this case - final model machine IDs are not the same as I > would expect while looking at the bundle. I'd've

Re: Juju 2.3 beta2 is here!

On 9 November 2017 at 22:49, Tim Penhey wrote: > No we aren't going to reuse --to. > > The --to directive is just for placement directives. Trying to use that > to overload machine mappings for bundles adds complexity for no real value. As I see it, machine mapping *is*

Re: Juju 2.3 beta2 is here!

I still like the idea of overloading the --to flag rather than having a new --map-machines flag. It's concise and fits well, I think - we want the machines in this bundle to mapped *to* the machines we're specifying here. I like the thrust of Tim's suggestion for "existing" but I'm not entirely

Re: Juju 2.3 beta2 is here!

On 6 November 2017 at 17:24, roger peppe <roger.pe...@canonical.com> wrote: > juju deploy --to 3=0,4=3 Also, looking further forward, I'd like to see more informative machine names in bundles, because with a command line like the above, it's not clear what the purpose of the assigned

Re: Juju 2.3 beta2 is here!

On 2 November 2017 at 07:16, Mark Shuttleworth wrote: > On 11/02/2017 04:56 AM, Chris Lee wrote: > > A new development release of Juju is here, 2.3-beta2. > > > 2.3 is looking great, and is worth a test run for those of you with larger > models and an interest in cross-model

Re: Organising apiserver facades

Getting all of that facade-specific logic out of the apiserver package seems like a great idea to me. I don't think it would take *too* much work to factor the helper logic into its own package entirely, with no dependencies on the facades. The client is actually almost there already with its

Re: lost reviews

t being used. > > Juju QA folks may be able to shed more light. > > On 25 May 2017 at 01:44, roger peppe <roger.pe...@canonical.com> wrote: >> >> Despite my plea (quoted below) it seems that our reviewboard site is >> not available any more, so an important set of

Re: Maximum AllWatcher frame size?

On 14 June 2017 at 17:14, Cory Johns wrote: > So, I'm not sure if this resolves the issue. The python websockets library > supports fragmented messages but I think that is separate from the maximum > message size that it's enforcing. I think that maximum is for the

/etc/juju/certs.d status?

I recently came across the code introduced by https://github.com/juju/juju/pull/2294 which provides support for reading extra certificates from /etc/juju/certs.d when connecting to an API server. The PR description says: "This feature is likely to be used when there is an agreed central JES

lost reviews

, roger peppe <roger.pe...@canonical.com> wrote: > On 24 October 2016 at 22:22, Menno Smits <menno.sm...@canonical.com> wrote: >> On 25 October 2016 at 10:17, Horacio Duran <horacio.du...@canonical.com> >> wrote: >>> >>> Shouldn't we leave it for h

Re: PROPOSAL: stop recording 'executing update-status hook'

set by the hook code is always available regardless of what hooks are executing. On 22 May 2017 at 14:02, roger peppe <roger.pe...@canonical.com> wrote: > On 22 May 2017 at 09:55, Ian Booth <ian.bo...@canonical.com> wrote: >> On 22/05/17 18:23, roger peppe wrote: >>> I

Re: PROPOSAL: stop recording 'executing update-status hook'

On 22 May 2017 at 09:55, Ian Booth <ian.bo...@canonical.com> wrote: > On 22/05/17 18:23, roger peppe wrote: >> I think it's slightly unfortunate that update-status exists at all - >> it doesn't really need to, >> AFAICS, as a charm can always do the polling it

Re: PROPOSAL: stop recording 'executing update-status hook'

I think it's slightly unfortunate that update-status exists at all - it doesn't really need to, AFAICS, as a charm can always do the polling itself if needed; for example: while :; do sleep 30 juju-run $UNIT 'status-set current-status "this is what is happening"' done &

Re: PROPOSAL: stop recording 'executing update-status hook'

I think it's slightly unfortunate that update-status exists at all - it doesn't really need to, AFAICS, as a charm can always do the polling itself if needed; for example: while :; do sleep 30 juju-run $UNIT 'status-set current-status "this is what is happening"' done &

Re: PROPOSAL: stop recording 'executing update-status hook'

On 19 May 2017 at 03:13, Tim Penhey wrote: > Hi folks, > > Currently juju will update the status of any hook execution for any unit to > show that it is busy doing things. This was all well and good until we do > things based on time. > > Every five minutes (or so) each

Re: removing colours from loggo package

I've proposed an initial PR to address this: https://github.com/juju/loggo/pull/25 On 21 February 2017 at 14:02, roger peppe <roger.pe...@canonical.com> wrote: > In August, the loggo package was changed to make it log ANSI-terminal > colour escape sequences by default. >

removing colours from loggo package

In August, the loggo package was changed to make it log ANSI-terminal colour escape sequences by default. I'm not sure that was the right decision, for a couple of reasons: - daemons are often given a pseudo tty to run in, so the log files produced by our running services are now obscured by

godeps now includes all architectures and OS's

I just landed a change to godeps that makes it include dependencies for all known architectures and operating systems. It also now includes testing dependencies by default (no need for -t flag - use -T if you need the old default behaviour). This means that to calculate dependencies for juju (or

Re: "unfairness" of juju/mutex

On 17 November 2016 at 12:12, Stuart Bishop <stuart.bis...@canonical.com> wrote: > On 17 November 2016 at 02:34, roger peppe <roger.pe...@canonical.com> wrote: >> >> +1 to using blocking flock. Polling is a bad idea with a heavily contended >> lock. >> >&

Re: "unfairness" of juju/mutex

+1 to using blocking flock. Polling is a bad idea with a heavily contended lock. FWIW I still think that mutexing all unit hooks is a bad idea that's really only there to paper over the problem that apt-get doesn't work well concurrently. cheers, rog. On 16 November 2016 at 15:26, John

Re: Long tests

Thanks for looking at this long standing issue. If you really want to speed up the tests, I believe the most fruitful place is to work on speeding up JujuConnSuite.SetUpTest I'm pretty sure it does a bunch of stuff (e.g. creating a fake juju home directory) that aren't required by 95% of tests.

Re: juju/retry take 2 - looping

On 26 October 2016 at 04:46, John Meinel wrote: >> I think this is a hint that this is the wrong approach. The edge-cases >> begin showing the cracks in the abstraction and end up making the code more >> complex. Consider your example instead of: >> >> var finalResult Foo

Re: juju/retry take 2 - looping

On 25 October 2016 at 22:40, Tim Penhey wrote: > On 26/10/16 10:30, Katherine Cox-Buday wrote: >> >> I think this is a hint that this is the wrong approach. The edge-cases >> begin showing the cracks in the abstraction and end up making the code more >> complex. Consider

Re: juju/retry take 2 - looping

On 20 October 2016 at 16:30, Katherine Cox-Buday wrote: > John Meinel writes: > >> As commented on the pull request, passing 'err' into Next() initially feels >> weird, but >> it allows a big improvement to whether the loop exited

Re: Github Reviews vs Reviewboard

[from canonical email address this time] On 14 October 2016 at 12:45, Adam Collard wrote: > Not sure I get a vote, but -1 > > You're running an old version of ReviewBoard (2.0.12 released in January > 2015) and many of the issues I think you've been hitting are fixed

Re: Github Reviews vs Reviewboard

On 14 October 2016 at 12:45, Adam Collard wrote: > Not sure I get a vote, but -1 > > You're running an old version of ReviewBoard (2.0.12 released in January > 2015) and many of the issues I think you've been hitting are fixed in later > revisions. Latest stable is

Re: Github Reviews vs Reviewboard

+1. Although github reviews are by no means perfect, reviewboard is worse. It loses draft comments if you click in the wrong place; it takes two page reloads to be able to reply to a comment; it doesn't work well on mobile platforms; it doesn't understand file renames, and the comments are

Re: List plugins installed?

On 28 September 2016 at 14:55, Rick Harding wrote: > This is just a miss. The original ability to see the plugins was a subset of > the help command and didn't make our CLI spreadsheet for things to rework. I > agree that list-plugins is the right idea here and that

Re: kill-controller, unregister, destroy-controller

It seems to me that this kind of thing is exactly what "blocks" are designed for. An explicit 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

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

This seems really nice, but I'm slightly wary of "magic" heuristics like this. In particular, bootstrapping can take a while and I have wasted plenty of time in the past trying to find bugs but having bootstrapped using the wrong binary... So I'm hoping this new feature provides at least these

breaking API change: controller vs model API connections

There is a PR that's soon to land that will change the Juju API so that controller-level RPC calls can no longer be executed on a model-specific connection. https://github.com/juju/juju/pull/5986 This is a breaking API change. The affected facades are the following: AllModelWatcher

Re: So I wanted to update a dependency . .

On 12 August 2016 at 14:11, Nate Finch wrote: > No other repo should ever depend on github.com/juju/juju. I have to call this out. There is no decent way to use Juju from Go without depending on github.com/juju/juju. And backward compatibility isn't insurmountable -

Re: Let's talk retries

On 9 August 2016 at 07:28, roger peppe <roger.pe...@canonical.com> wrote: > On 9 August 2016 at 01:22, Katherine Cox-Buday > <katherine.cox-bu...@canonical.com> wrote: >> Hey All, >> >> We currently have 3 ways we're performing retries in Juju: >> >&

Re: Let's talk retries

On 9 August 2016 at 01:22, Katherine Cox-Buday wrote: > Hey All, > > We currently have 3 ways we're performing retries in Juju: > > 1. Archaic, custom, intra-package retry code. > 2. github.com/juju/utils::{Countdown,BackoffTimer} > 3. github.com/juju/retry

Re: Schema for Juju RPC messages

On 28 July 2016 at 15:11, Mark Shuttleworth <m...@ubuntu.com> wrote: > On 28/07/16 13:47, roger peppe wrote: >> I agree with that. But we're talking about sugar here, I think. Added >> sugar doesn't *necessarily* imply a cleaner, less messy or better >> articulated

Re: Schema for Juju RPC messages

On 28 July 2016 at 12:12, Mark Shuttleworth <m...@ubuntu.com> wrote: > On 28/07/16 12:57, roger peppe wrote: >> On 28 July 2016 at 10:01, Mark Shuttleworth <m...@ubuntu.com> wrote: >>> On 28/07/16 10:42, roger peppe wrote: >>>> On 28 July 2016 at 01:07

Re: Schema for Juju RPC messages

On 28 July 2016 at 10:33, John Meinel wrote: > ... >> >> >> FWIW there is a proposal for strict field checking in the Go >> encoding/json package (https://github.com/golang/go/issues/15314) >> which would fix the specific issue raised at the start of this thread. >> It's

Re: Schema for Juju RPC messages

On 28 July 2016 at 01:25, Rick Harding wrote: > My understanding is that we need three distinct calls in the API because of > Go and the way that these things need to be declared/defined. Actually, it would be perfectly possible in Go for there to be only a single

Re: Schema for Juju RPC messages

On 28 July 2016 at 01:07, Rick Harding wrote: > However, an API client in any language should never be auto generated. This is a strong statement. I feel that, as with most things in software engineering, there's a trade-off. Personally I'm with Katherine "use the

Re: RFC: remove juju publish?

Yes, it should be removed. It's superceded by charm push. On 15 July 2016 at 04:32, Tim Penhey wrote: > Does 'juju publish' still serve a purpose in Juju 2.0? > > Should we just remove it? > > Tim > > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com > Modify

Re: Natural sorting helper

Nice! Could I suggest that the Less implementation is exported independently so that it can be used in other sort.Interface implementations (for example if we wanted to sort a slice of structs by a naturally-sorted key)? Perhaps call it StringCompareNatural and make it the same signature as

Re: Natural sorting helper

Nice! Could I suggest that the Less implementation is exported independently so that it can be used in other sort.Interface implementations (for example if we wanted to sort a slice of structs by a naturally-sorted key)? Perhaps call it StringCompareNatural and make it the same signature as

Re: "juju attach"

mount ? On 18 June 2016 at 09:23, Mark Shuttleworth wrote: > > We can change a CLI until RC, and its good for us to debate them. > > Here are the guiding principles. > > * shorter is better, much much better > * we strongly prefer one word to always mean the same thing > * we

Re: Automatic commit squashing

Squashed commits are nice, but there's something worth watching out for: currently the merge commit is committed with the text that's in the github PR, but when a squashed commit is made, this text is ignored and only the text in the actual proposed commit ends up in the history. This surprised me

Re: A cautionary tale - mgo asserts

On 9 June 2016 at 01:20, Menno Smits wrote: > On 8 June 2016 at 22:36, John Meinel wrote: >>> >>> ... >> >> >>> >>> >>> ops := []txn.Op{{ >>> C: "collection", >>> Id: ..., >>> Assert: bson.M{ >>> "some-field.A":

Re: A cautionary tale - mgo asserts

On 8 June 2016 at 16:44, Gustavo Niemeyer <gustavo.nieme...@canonical.com> wrote: > Is it mgo/txn that is internally unmarahalling onto that? > > Let's get that fixed at its heart. Yes, good plan. > On Jun 8, 2016 12:27 PM, "roger peppe" <roger.pe...@canonical.com

Re: A cautionary tale - mgo asserts

eme...@canonical.com> wrote: > Is it mgo itself that is changing the order internally? > > It should not do that. > > On Wed, Jun 8, 2016 at 8:00 AM, roger peppe <rogpe...@gmail.com> wrote: >> >> OK, I understand now, I think. >> >> The underlying problem is that sub

Re: A cautionary tale - mgo asserts

This is also relevant (but probably only for larger documents): https://jeremywsherman.com/blog/2013/04/23/key-reordering-ruins-mongodb/ Another reason to avoid entire-subdocument matches. On 8 June 2016 at 10:42, Menno Smits wrote: > > > On 8 June 2016 at 21:05, Tim

Re: A cautionary tale - mgo asserts

OK, I understand now, I think. The underlying problem is that subdocument searches in MongoDB are order-sensitive. For example, I just tried this in a mongo shell: > db.foo.insert({_id: "one", x: {a: 1, b: 2}}) > db.foo.find({x: {a: 1, b: 2}}) { "_id" : "one", "x" : { "a" : 1, "b" : 2 } } >

Re: A cautionary tale - mgo asserts

OK, I understand now, I think. The underlying problem is that subdocument searches in MongoDB are order-sensitive. For example, I just tried this in a mongo shell: > db.foo.insert({_id: "one", x: {a: 1, b: 2}}) > db.foo.find({x: {a: 1, b: 2}}) { "_id" : "one", "x" : { "a" : 1, "b" : 2 } } >

Re: A cautionary tale - mgo asserts

On 8 June 2016 at 10:05, Tim Penhey wrote: > Hi folks, > > tl;dr: not use structs in transaction asserts > > I have spent the last two days looking at this bug: > https://bugs.launchpad.net/juju-core/+bug/1537585 > > It was one where the instance poller got itself in a

Re: A cautionary tale - mgo asserts

On 8 June 2016 at 10:05, Tim Penhey wrote: > Hi folks, > > tl;dr: not use structs in transaction asserts > > I have spent the last two days looking at this bug: > https://bugs.launchpad.net/juju-core/+bug/1537585 > > It was one where the instance poller got itself in a

Re: go test github.com/juju/juju/state takes > 10 minutes to run

A bit more info for those interested, I ran all the juju tests through that tool: go test -p 1 -v -timeout 60m github.com/juju/juju/... -check.vv 2>&1 | timestamp and this is what it said: total suites 1219 total test time 49m10.093s total suite time 1h18m9.061s total setup test 14m27.71s

Re: go test github.com/juju/juju/state takes > 10 minutes to run

Duran <horacio.du...@canonical.com> wrote: > Uh, ill take a look at that, I am the author of said test > > On Fri, May 20, 2016 at 6:50 AM, roger peppe <roger.pe...@canonical.com> > wrote: >> >> The state tests "only" take 10m26s for me. >> &

Re: go test github.com/juju/juju/state takes > 10 minutes to run

The state tests "only" take 10m26s for me. I built a thing to analyse gocheck output https://play.golang.org/p/veBCtrmmPR and used it on the state test output. total suites 94 total test time 10m25.752s total suite time 10m26.033s total setup test 3m4.727s total teardown test 14.277s total setup

Re: Awful dependency problem caused by romulus

On 19 May 2016 at 07:02, 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: Three CI builds in the last 48 hours have failed because launchpad had a lie down

On 19 May 2016 at 02:05, David Cheney wrote: > We already have godeps which can take a set of vcs repos and flick > them to the right revisions. > > Why does CI check out every single dependency from upstream every > single time we do a build ? That introduces wc -l

Re: Today I submitted 5 PR's to be merged, 3 failed because mongo shat itself

Out of interest, what's causing the 3.2 slowdown and what's the hack to speed it up again? On 18 May 2016 09:51, "Christian Muirhead" wrote: > > > On Wed, May 18, 2016 at 2:04 AM David Cheney > wrote: > >> 100x more webscale >> > Ha!

Re: hacking upload tools for development

I wonder what the best way for this to work might be. Presumably it would have to establish something (a local server? A temporary directory?) and then juju would need to run in that context. Are you imagining some kind of wrapper command that would set up the tools and then run the juju command?

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

On 7 April 2016 at 17:34, Reed O'Brien wrote: >> Do you want to NAT the IPv4 traffic? n > > You do want to NAT the traffic, unless you have routing explicitly setup. Ah, thanks. I knew it must be something stupid like that. It now bootstraps and works OK, yay! Thanks

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

what I ran once I installed >> > the >> > new lxd package and it seemed to get things working. Tycho added some >> > helpful prompts as part of "juju bootstrap" to point users in the right >> > direction if LXD looks to be improperly configur

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

the right > direction if LXD looks to be improperly configured. > > https://github.com/juju/juju/pull/4984 > > > I'm trying to land that now. > > John > =:-> > > On Apr 7, 2016 6:19 PM, "roger peppe" <roger.pe...@canonical.com> wrote: > > To ad

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

To add to this conversation, I have encountered this issue today and have been unable to resolve it so far in the limited time I've been able to spend on it. I'm running on Trusty; I have the new version of lxd and the latest version of Juju tip. In my case, the issue seems to be that my lcdbr0

Re: New juju in ubuntu

On 7 April 2016 at 10:17, Stuart Bishop <stuart.bis...@canonical.com> wrote: > On 7 April 2016 at 16:03, roger peppe <roger.pe...@canonical.com> wrote: >> On 7 April 2016 at 09:38, Tim Penhey <tim.pen...@canonical.com> wrote: >>> We could probably set an enviro

Re: New juju in ubuntu

On 7 April 2016 at 09:38, Tim Penhey wrote: > We could probably set an environment variable for the plugin called > JUJU_BIN that is the juju that invoked it. > > Wouldn't be too hard. How does that stop old plugins failing because the new juju is trying to use them?

Re: Unable to kill-controller

My 2p: FWIW I also would have no idea which was stronger, kill-controller or destroy-controller. Assuming we do really want a separate command, a variant of "destroy-controller" might be more intuitive, e.g. "destroy-controller-with-prejudice", "destroy-controller-regardless"... If fact I think

Re: Planning for Juju 2.2 (16.10 timeframe)

On 16 March 2016 at 12:31, Kapil Thangavelu wrote: > > > On Tue, Mar 8, 2016 at 6:51 PM, Mark Shuttleworth wrote: >> >> Hi folks >> >> We're starting to think about the next development cycle, and gathering >> priorities and requests from users of Juju. I'm

Re: PatchValue (AddCleanup) unsafe with non pointer receiver test

On 17 March 2016 at 04:52, John Meinel wrote: > I came across this in the LXD test suite today, which was hard to track > down, so I figured I'd let everyone know about it. > > We have a nice helper in testing.IsolationSuite with "PatchValue()" that > will change a global

Re: Planning for Juju 2.2 (16.10 timeframe)

info hangs around. Having the credential info associated with the relation itself would be perfect. > > On Wed, Mar 16, 2016 at 9:17 AM roger peppe <roger.pe...@canonical.com> > wrote: >> >> On 16 March 2016 at 12:31, Kapil Thangavelu <kap...@gmail.com> wrote:

Re: httpbakery .Client overly restrictive on body - io.ReaderSeeker

On 9 March 2016 at 03:03, Tim Penhey wrote: > Hi folks, > > I came across this recently while looking at sending tools and charms > between two controllers. > > The local storage interface gives us an io.ReaderCloser. Unfortunately, > we can't give that to the http

Re: Juju 2.0 and local charm deployment

On 4 March 2016 at 05:55, Ian Booth wrote: > Hi folks > > TL;DR we want to remove support for old style local charm repositories in > Juju 2.0 > > Hopefully everyone is aware that Juju 2.0 and the charm store will support > multi-series charms. To recap, a multi-series

Re: Diffing string checker

Nice. FWIW I have a related tool that tries to help find where a regexp mismatch has happened. It parses the output of gocheck, so it's probably not that useful to non-acme users but you might want to consider including the approach (http://paste.ubuntu.com/15195795/) for fancycheck.Matches and

Re: Defaulting tests internal to the package

On 22 January 2016 at 09:40, William Reade wrote: > I do not want anyone to add unit tests for non-exported code, because those > tests are almost completely worthless. I'd beg to disagree with this. I think it very much depends what you are testing. For me tests are

Re: Automatic retries of hooks

On 21 January 2016 at 09:51, James Page wrote: > On Wed, 20 Jan 2016 at 20:31 William Reade > wrote: >> >> On Wed, Jan 20, 2016 at 8:01 PM, Dean Henrichsmeyer >> wrote: >>> >>> You realize James was complaining and not

Re: Automatic retries of hooks

On 20 January 2016 at 12:20, Martin Packman wrote: > Another common error we see in CI is apt mirrors being unhappy leading > to hook failures. Just retry later does tend to be the right option > there, though it will often be an our or two until the archive is in a

Re: "environment" vs "model" in the code

On 15 January 2016 at 06:03, Ian Booth wrote: > > > On 15/01/16 10:16, Menno Smits wrote: >> Hi all, >> >> We've committed to renaming "environment" to "model" in Juju's CLI and API >> but what do we want to do in Juju's internals? I'm currently adding >> significant new

Re: Comprehensive reviews & when to do them?

On 14 December 2015 at 15:39, Katherine Cox-Buday wrote: > Hey All, > > I think we have a mis-alignment in how we currently do reviews and feature > branches. > > We've switched over to feature-branches which is great and has allowed > Moonstone to land "good

Re: apiserver authorizers

Could you link to the offending change(s) please, so we can see what doing it wrong looks like? On 2 December 2015 at 09:28, William Reade wrote: > I just noticed that the unitassigner facade-constructor drops the authorizer > on the floor; and I caught a similar

Re: utils/fslock needs to DIAF

st solution is) I think using hackery with the filesystem locking on > Windows is a mistake. Is there something wrong with using the Windows file-exclusive-open semantics to implement a lock associated with a entity in the file system? Isn't that what it's for? > On Tue, Dec 1, 2015 at 4:10 A

Re: utils/fslock needs to DIAF

So I'm with axw on this one - flock seems like it is a reasonable tool for the job here. FWIW a Unix domain socket also suffers from the "won't work across NFS" problem. Abstract unix domain sockets also have the problem that they won't work with long file paths (what were they thinking?) We have

Re: utils/fslock needs to DIAF

On 1 December 2015 at 12:34, David Cheney <david.che...@canonical.com> wrote: > On Tue, Dec 1, 2015 at 8:10 PM, roger peppe <roger.pe...@canonical.com> wrote: >> So I'm with axw on this one - flock seems like it is a reasonable tool for >> the job here. FWIW a Unix doma

Re: trouble with dependent repos

On 24 November 2015 at 15:51, Eric Snow wrote: > On Mon, Nov 23, 2015 at 9:32 PM, Nate Finch wrote: >> Last week, I had trouble landing code in gopkg.in/juju/charm.v6-unstable, > > I had a similar experience last week with backward-incompatible

Re: trouble with dependent repos

On 24 November 2015 at 04:32, Nate Finch wrote: > Last week, I had trouble landing code in gopkg.in/juju/charm.v6-unstable, > and using that code from master of github.com/juju/juju. I was hoping > someone could help me figure out a way to avoid problems I've

Re: trouble with dependent repos

On 24 November 2015 at 04:32, Nate Finch wrote: > Last week, I had trouble landing code in gopkg.in/juju/charm.v6-unstable, > and using that code from master of github.com/juju/juju. I was hoping > someone could help me figure out a way to avoid problems I've

Re: Musings around environments, cloud credentials, and the new Juju Controllers

On 13 November 2015 at 12:58, Rick Harding wrote: > The goal is to get the user onto 'best practices' out of the box and > deploying into the controller environment isn't best practice since it's no > longer as easily transient. If you bootstrap, deploy something to

Re: New feature for 1.26 (master), $(JUJU_HOME)/aliases

On 23 October 2015 at 05:12, Tim Penhey wrote: > Hi folks, > > I scratched a personal itch yesterday and added the ability for users to > specify their own aliases for juju commands. > > There are two primary use cases that I was trying to address. > > Firstly, the

Re: Making logging to MongoDB the default

This seems reasonable to me. For myself, the time I'm looking at all-machines.log is often when the system is broken. I wonder whether a reasonable substitute might be a low level tool that can operate directly on the mongo database to fetch the logs, bypassing the juju system. I have one

local juju users: bob vs bob@local

We've been working on adding external user support to juju and a discussion arose from a throwaway comment on the IRC channel: "The difference between Canonical() and Id() seems confusing to me" The comment referred to two names.UserTag methods (defined in the package github.com/juju/names).

Re: Proposal: doc.go for each package

On 27 August 2015 at 08:39, James Tunnicliffe james.tunnicli...@canonical.com wrote: A good way of reading go docs is godoc -http=:6060 and pointing your browser at http://localhost:6060/pkg/github.com/juju/juju/ to read the docs - no grep required. +1. Or godoc . if you're in the package

Re: Proposal: doc.go for each package

+1. We should definitely have package docs for every package, explaining what it's for, how it is intended to be used and explaining any overarching concepts. There's no particular need for it to be in a separate doc.go file though. On 26 August 2015 at 14:11, Frank Mueller

Re: Pointer Receivers on Error() and String() methods

recovery is a good idea either, but fmt sets the precedent to follow here. On Mon, Aug 24, 2015 at 3:22 AM David Cheney david.che...@canonical.com wrote: Yup, I agree with Rog. This is fixing the problem in the wrong place. On Mon, Aug 24, 2015 at 5:14 PM, roger peppe roger.pe...@canonical.com

Re: Pointer Receivers on Error() and String() methods

I'm afraid I'm not convinced. Declaring the Error method on the pointer receiver is idiomatic (just grep for ' Error\(' in the Go source) and is a useful indicator that the error value is always intended to be a pointer. There's a much simpler fix for this: let the errors package recover from

Re: Godeps PSA (or don't make the same mistake I did)

To do it *right*, one would probably want to do something like: for os in darwin windows linux; do for arch in amd64 arm; do godeps -t github.com/juju/juju/... done done | sort -u but even that's probably not good enough for the unusual cases though. I've been pondering on this

Fwd: Recurring fails on windows tests and the recent CentOS failure

the base suite up; to discover that they didn't set the base suite up *on purpose* adds significant insult to the injury. If you don't need it, don't embed it; if you do need it, please use it properly. Cheers William On Wed, Jul 15, 2015 at 7:39 AM roger peppe rogpe...@gmail.com wrote

Re: Recurring fails on windows tests and the recent CentOS failure

It shouldn't be hard to write some code (using go/types) that automatically checks for these invariants. On 15 July 2015 at 07:05, John Meinel j...@arbash-meinel.com wrote: On Wed, Jul 15, 2015 at 2:44 AM, Bogdan Teleaga btele...@cloudbasesolutions.com wrote: Hello everybody, Lately I've

Re: Blocking bugs process

[as roger.pe...@canonical.com this time] On 14 July 2015 at 10:02, Nate Finch nate.fi...@canonical.com wrote: I don't think it's unreasonable to just make such a bug a blocker, just to get it addressed ASAP, even if it is not strictly making things worse than an earlier version. FWIW I think

Re: previously valid amazon environment now invalid?

On 30 April 2015 at 11:55, Ian Booth ian.bo...@canonical.com wrote: Right now, the default tabular output is behind a feature flag because it's experimental. We still need to decide how to allow users to have that output by default without the feature flag, but also without breaking 1.18

Re: previously valid amazon environment now invalid?

At the Nuremberg sprint, I saw a demo of juju status that produced tabular format by default. I'm guessing that this issue means that can never actually be enabled. Although... it could be done backwardly compatibly (with a required environment variable or configuration file setting) and perhaps

Re: previously valid amazon environment now invalid?

On 28 April 2015 at 19:41, Nate Finch nate.fi...@canonical.com wrote: No one seems to be answering my actual question. That error message seems new. Is it? Either way, the error message is incorrect - control bucket is not required - and whatever is emitting that message needs to be fixed.

  1   2   3   >