Kill it!
...except in hook tools, which I think we want to keep the same lest we
break charms.
On Wed, Aug 10, 2016 at 12:44 AM, Rick Harding
wrote:
> +1 we should only do tabular, yaml, and json
>
> On Tue, Aug 9, 2016, 6:38 PM Tim Penhey wrote:
>
>> Hi folks,
>>
>> While perusing the codebas
+1 we should only do tabular, yaml, and json
On Tue, Aug 9, 2016, 6:38 PM Tim Penhey wrote:
> 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 default
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
Modi
FYI I have opened 1 bug and merged 2 PRs to help track this:
https://bugs.launchpad.net/juju-core/+bug/1611427
https://github.com/juju/juju/pull/5958
https://github.com/juju/utils/pull/229
Katherine Cox-Buday writes:
> Hey All,
>
> We currently have 3 ways we're performing retries in Juju:
>
>
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 you'd like to
> write quite we
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" the
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
>
> ...
>
>
> 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 sh
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 initially). This will
> allow thw
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 exi
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 provisioner,
and I think a timer queue
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
sam
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:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
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 structur
On 9 August 2016 at 08:33, Andrew Wilkins wrote:
> On Tue, Aug 9, 2016 at 3:31 PM William Reade
> wrote:
>>
>> I feel obliged to note that we also have axw's operation queue, used in
>> storageprovisioner, and that it's the only one which doesn't make the
>> assumption that the code being retried
On Tue, Aug 9, 2016 at 3:31 PM William Reade
wrote:
> I feel obliged to note that we also have axw's operation queue, used in
> storageprovisioner, and that it's the only one which doesn't make the
> assumption that the code being retried is the only important thing that
> could possibly be happe
I feel obliged to note that we also have axw's operation queue, used in
storageprovisioner, and that it's the only one which doesn't make the
assumption that the code being retried is the only important thing that
could possibly be happening in the calling context.
All the other approaches discuss
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 for an
interface which is to JUJU_HOME that would give
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.
>> 2. github.com/juju/utils::{Countdown,BackoffTimer}
>> 3. gith
19 matches
Mail list logo