j k and J K seem to work well, but x/c or [ ] don't seem to do anything on
the diff page.
John
=:->
On Wed, Sep 17, 2014 at 10:26 AM, Menno Smits
wrote:
> Thumper was asking earlier if RB had keyboard shortcuts and it turns it
> out it does:
>
>
> https://www.reviewboard.org/docs/manual/dev/user
Thumper was asking earlier if RB had keyboard shortcuts and it turns it out
it does:
https://www.reviewboard.org/docs/manual/dev/users/reviews/reviewing-diffs/#keyboard-shortcuts
Unfortunately the previous and next comment bindings don't seem to work for
me but the others do. Is it just me?
--
J
Even with the rate limiting on, I'm seeing 100% of 1 CPU dedicated to
rsyslogd, I'm *guessing* that is TLS connection overhead, but I really
don't have any insight there. I can say that I'm still seeing some agents
get "could not connect" or "connection reset by peer" errors.
I certainly think we
> Has there been any discussion or have any decisions made about Client API
> Facades in Juju?
>
Yes.
> It seems all of the Client API is exposed on one Client facade, and we'll
> just be adding more to it in rolling out Actions.
>
Not all, but most, see below.
> I'd like to consider a new cl
On Tue, Sep 16, 2014 at 4:27 PM, John Weldon wrote:
> Hi;
>
> Has there been any discussion or have any decisions made about Client API
> Facades in Juju?
>
> It seems all of the Client API is exposed on one Client facade, and we'll
> just be adding more to it in rolling out Actions.
>
> I'd like
Hi;
Has there been any discussion or have any decisions made about Client API
Facades in Juju?
It seems all of the Client API is exposed on one Client facade, and we'll
just be adding more to it in rolling out Actions.
I'd like to consider a new client facade just for Actions.
Thoughts?
--
Jo
John,
Thank you taking the time to run the logging through these tests.
I found that there is also the $SystemLogRateLimitInterval setting. Setting
that to 0 will disable the default rate limiting in rsyslog.
http://www.rsyslog.com/changing-the-settings/
I would be curious to see what the pe
I think this comes down to checking whether the target unit's
agent-version is one that supports invoking relation contexts, and
failing nicely if it isn't -- ie I don't *think* it's to do with the
version of cmd/juju, but the version of cmd/juju*d* in play. Helpful?
On Fri, Sep 12, 2014 at 3:20 P
On 16/09/14 19:19, roger peppe wrote:
> On 16 September 2014 02:12, Tim Penhey wrote:
>> On 12/09/14 01:35, Nate Finch wrote:
>>> Separation of logic is absolutely a good thing. Separation of data is
>>> not nearly so useful.
>>
>> What I see as the real benefit of this work is based behind the
On 16 September 2014 13:45, David Cheney wrote:
> On Tue, Sep 16, 2014 at 7:27 PM, roger peppe
> wrote:
>> On 16 September 2014 09:22, Jonathan Aquilina
>> wrote:
>>> If i am not mistaken if you have multiple commits in a branch git has
>>> something built in called git squash. This obviously
On Tue, Sep 16, 2014 at 7:27 PM, roger peppe wrote:
> On 16 September 2014 09:22, Jonathan Aquilina wrote:
>> If i am not mistaken if you have multiple commits in a branch git has
>> something built in called git squash. This obviously eliminates the 5 step
>> process into one merge and one push.
On Tue, Sep 16, 2014 at 7:59 PM, William Reade
wrote:
> On Thu, Sep 11, 2014 at 3:35 PM, Nate Finch wrote:
>> I don't see how having different identical structs that are updated
>> simultaneously in any way prevents any problems with compatibility.
>
> If we're updating those structs simultaneous
On 16 September 2014 10:59, William Reade wrote:
> On Thu, Sep 11, 2014 at 3:35 PM, Nate Finch wrote:
>> I don't see how having different identical structs that are updated
>> simultaneously in any way prevents any problems with compatibility.
>
> If we're updating those structs simultaneously, w
That is it indeed :)
---
Regards,
Jonathan Aquilina
Founder Eagle
Eye T
On 2014-09-16 11:58, Dimiter Naydenov wrote:
> -BEGIN PGP
SIGNED MESSAGE-
> Hash: SHA1
>
> On 16.09.2014 12:32, Jonathan
Aquilina wrote:
>
>> I dont think you have to rebase though. I think
you can squash mult
On Thu, Sep 11, 2014 at 3:35 PM, Nate Finch wrote:
> I don't see how having different identical structs that are updated
> simultaneously in any way prevents any problems with compatibility.
If we're updating those structs simultaneously, we're completely
missing the point. Once we've defined a p
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 16.09.2014 12:32, Jonathan Aquilina wrote:
> I dont think you have to rebase though. I think you can squash
> multiple commits together.
>
You're probably thinking about git commit --amend -m "msg", which
folds the current changeset into the one b
I dont think you have to rebase though. I think you can squash
multiple commits together.
---
Regards,
Jonathan Aquilina
Founder
Eagle Eye T
On 2014-09-16 11:27, roger peppe wrote:
> On 16 September
2014 09:22, Jonathan Aquilina wrote:
>
>> If
i am not mistaken if you have multiple commit
On 16 September 2014 09:22, Jonathan Aquilina wrote:
> If i am not mistaken if you have multiple commits in a branch git has
> something built in called git squash. This obviously eliminates the 5 step
> process into one merge and one push.
I don't see that command. Are you thinking of the "squas
On 16 September 2014 02:12, Tim Penhey wrote:
> On 12/09/14 01:35, Nate Finch wrote:
>> Separation of logic is absolutely a good thing. Separation of data is
>> not nearly so useful.
>
> What I see as the real benefit of this work is based behind the
> "interface segregation principle".
>
> Effec
If i am not mistaken if you have multiple commits in a branch git
has something built in called git squash. This obviously eliminates the
5 step process into one merge and one push.
---
Regards,
Jonathan
Aquilina
Founder Eagle Eye T
On 2014-09-16 09:44, roger peppe wrote:
> On 15 September
Oh, and after all this has been running for a while, I did see:
-rw--- 1 syslog adm178M Sep 16 08:11 all-machines.log
-rw--- 1 syslog adm513M Sep 16 07:53 all-machines.log.1
-rw--- 1 syslog adm513M Sep 16 07:26 all-machines.log.2
So it is successfully rotating the log file,
So poking around and filing
https://bugs.launchpad.net/juju-core/+bug/1369909
I found lines about
Sep 16 07:48:14 ip-10-39-60-247 rsyslogd-2079: message repeated 498 times:
[too many tcp sessions - dropping incoming request [try
http://www.rsyslog.com/e/2079 ]]
That is 500 times rsyslog had to den
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 16.09.2014 10:44, roger peppe wrote:
> As far as I can make out, as long as you want to propose your
> branch with only a single commit added to the log, this makes it
> easy to use a merge-based flow and amounts to the same thing in the
> end.
>
On 15 September 2014 21:39, Ian Booth wrote:
> On 16/09/14 00:50, Eric Snow wrote:
>> On Mon, Sep 15, 2014 at 8:09 AM, Eric Snow wrote:
>>> Yeah, those steps are a lot, though keep in mind that effectively it's
>>> only 2 steps more than before if you use the -p flag to rbt post and
>>> were alre
I tested your branch in the same configuration. First I had to change
"logging-config: =DEBUG" again. I thought that if you did "juju
bootstrap --debug" that it always left DEBUG level on.
Anyway, something doesn't quite seem right, as I saw:
-rw--- 1 syslog adm500M Sep 16 07:25 all-machin
25 matches
Mail list logo
