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

juju login change

Hi, Just a heads up to say that we're planning on changing the "juju login" command on juju tip soon so that (by default) it logs into a controller not a username. This is a backwardly incompatible change - to get the old behaviour, there will be a new "-u" flag. This has landed in a feature

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

Fwd: Showing Juju GUI in controller model

On 16 January 2017 at 22:13, Merlijn Sebrechts wrote: > Exactly what I need, thanks! Cool, glad it's appreciated :) Note that you will still need to manually change your DNS entry to point to the controller IP addresses or host names so that letsencrypt can resolve

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: Charm release fails with "cannot update base entity for..."

OK, I've found the issue. Your metadata.yaml specifies "trusty" twice in the "series" attribute. Specifying it only once should allow you to release. We should produce a better error message for this case (or just de-duplicate series). cheers, rog. On 3 January 2017 at 12:17, Merlijn

Re: using a bundle with manually added machines (redux)

On 4 January 2017 at 15:34, roger peppe <roger.pe...@canonical.com> wrote: > a dep option I meant to say "a deploy option" here. -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju

Re: Charm release fails with "cannot update base entity for..."

rk. It's in the normal charm store that I used the > incorrect jupiter-notebook-spark. > > 2017-01-04 11:04 GMT+01:00 roger peppe <roger.pe...@canonical.com>: >> >> On 3 January 2017 at 13:05, Merlijn Sebrechts >> <merlijn.sebrec...@gmail.com>

Re: Charm release fails with "cannot update base entity for..."

On 3 January 2017 at 13:05, Merlijn Sebrechts wrote: > I have the same issue in the staging charm store. > > > charm release cs:~tengu-team/jupyter-notebook-spark-0 > ERROR cannot release charm or bundle: cannot publish charm or bundle: cannot > update base entity

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

Fwd: breaking API change: controller vs model API connections

There is a PR that's soon to land [edit: just landed] 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:

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: "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: Model config

On 8 June 2016 at 10:41, Andrew Wilkins wrote: > Hi folks, > > We're in the midst of making some changes to model configuration in Juju > 2.0, separating out things that are not model specific from those that are. > For many things this is very clear-cut, and for

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

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

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

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: 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: New feature for charmers - min-juju-version

On 23 March 2016 at 15:06, David Ames wrote: > On 03/21/2016 06:54 PM, Stuart Bishop wrote: >> >> On 22 March 2016 at 11:42, Rick Harding >> wrote: >>> >>> I believe that went out and is ok Stuart. The charmstore update is >>> deployed >>>

Re: New feature for charmers - min-juju-version

If the released Juju 2.0 uses v5 of the charmstore API (which it will soon hopefully anyway when my branch to support the new publishing model lands), then there's a straightforward solution here, I think: change v4 of the charmstore API to refuse to serve min-juju-version charm archives to

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

  1   2   3   >