RFC: time to remove the "smart" output formatter?

2016-08-09 Thread Tim Penhey
Hi folks, While perusing the codebase, I was reminded of our "smart" output formatter. It is the yaml but not quite yaml one. I propose we remove it, and default commands that were defaulting to that to use yaml instead. Thoughts? Tim -- Juju-dev mailing list Juju-dev@lists.ubuntu.com

Re: Let's talk retries

2016-08-09 Thread Katherine Cox-Buday
roger peppe writes: > There's a fourth way that you haven't mentioned, which fits somewhere > in between 1 and 2 I think (it was the first explicit general retry > code in Juju AFAIK), which is utils.Attempt. > > I'd suggest that the way it's used matches the pattern

Re: Let's talk retries

2016-08-09 Thread Nate Finch
So, in my opinion, juju/retry is pretty good. I think with some tweaking and some intelligent use, it can feel every bit as lightweight as we'd like. If we have common use cases, we just need to write up an API to encapsulate them. If we want a "retry N times or until this channel is closed"

Re: Let's talk retries

2016-08-09 Thread Katherine Cox-Buday
Andrew's queue is certainly nice, but I agree with the points Roger is raising: 1. Go's idiom for coordinating concurrent operations are goroutines and channels. 2. Sticking to these idioms makes it much easier to compose parts into a whole (if only because the language strongly bends code that

Re: Juju and snappy implementation spike - feedback please

2016-08-09 Thread John Meinel
> > ... > > > The big difference to me is that $SNAP_USER_DATA will roll back if the > snap is rolled back. I'm not sure what happens if the snap is removed and > reinstalled. Given end users should no longer need to be messing around > with the dotfiles, I think the rollback behaviour is what

Re: Juju and snappy implementation spike - feedback please

2016-08-09 Thread Stuart Bishop
On 9 August 2016 at 19:08, Ian Booth wrote: > I personally like the idea that the snap could use a juju-home interface to > allow access to the standard ~/.local/share/juju directory; thus allowing > a snap > and regular Juju to be used interchangeably (at least

Re: Juju and snappy implementation spike - feedback please

2016-08-09 Thread Ian Booth
I personally like the idea that the snap could use a juju-home interface to allow access to the standard ~/.local/share/juju directory; thus allowing a snap and regular Juju to be used interchangeably (at least initially). This will allow thw use case "hey, try my juju snap and you can use your

Re: Let's talk retries

2016-08-09 Thread William Reade
On Tue, Aug 9, 2016 at 10:17 AM, roger peppe wrote: > BTW I'm not saying that a timer queue is never the correct answer. In some > circumstances, it can be the exactly the right thing to use. > Yeah -- the context here is that katco has been looking at the

Re: RFC: proposed changes to debug-log API call

2016-08-09 Thread John Meinel
Sounds like a good idea. Can we get some form of versioning like we do with Facades so that we can do changes in the future? AIUI we could put it in the "Accept" header, in the URL or in a Query parameter. Please coordinate with Ian who has been designing the REST API for CMR so that we use the

Re: RFC: proposed changes to debug-log API call

2016-08-09 Thread Adam Collard
On Tue, 9 Aug 2016 at 09:43 Tim Penhey wrote: > Is anyone currently using the streaming text aspects of the API right now? > Not us. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at:

RFC: proposed changes to debug-log API call

2016-08-09 Thread Tim Penhey
Hi folks, This is regarding the streaming /api/:model-uuid/log api server endpoint. Currently this method sends an initial possible error, then just turns on a tap of bytes of preformatted log messages. What I propose is to change the streaming protocol from just text to a stream of

Re: Juju and snappy implementation spike - feedback please

2016-08-09 Thread John Meinel
On Aug 9, 2016 1:06 AM, "Nicholas Skaggs" wrote: > > > > On Mon, Aug 8, 2016 at 11:49 AM, John Meinel wrote: >> >> If we are installing in '--devmode' don't we have access to the unfiltered $HOME directory if we look for it? And we could ask

Re: Let's talk retries

2016-08-09 Thread roger peppe
On 9 August 2016 at 07:28, roger peppe wrote: > 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.

Re: Let's talk retries

2016-08-09 Thread roger peppe
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