Agreed, but I also agree that the error on split ranges is a good
simplification to get an implementation in place, and it also doesn't
sound super useful, so it sounds okay to fail to begin with. The other
cases are easy to handle, though.
On Wed, Aug 6, 2014 at 8:26 AM, Kapil Thangavelu
wrote:
That sounds like what I would have expected was happening (we only run
upgrade steps if we think they have a reason to change things, and then
only set the last known version once all the upgrade steps have finished.)
I'm concerned about the "if there is a mongo problem", because if we're
running
agreed. to be clear .. imo, close-port shouldn't error unless there's a
type mismatch on inputs. ie none of the posited scenarios in this thread
should result in an error.
-k
On Tue, Aug 5, 2014 at 8:34 PM, Gustavo Niemeyer
wrote:
> On Tue, Aug 5, 2014 at 4:18 PM, roger peppe wrote:
> > close
You had my verbal SGTM but have it written also
On Tuesday, August 5, 2014, David Cheney wrote:
> SGTM.
>
> On Wed, Aug 6, 2014 at 11:10 AM, Menno Smits > wrote:
> > Right now, a Juju machine agent is in "upgrade mode" from the moment it
> > starts until the upgrade-steps worker is finished. Du
SGTM.
On Wed, Aug 6, 2014 at 11:10 AM, Menno Smits wrote:
> Right now, a Juju machine agent is in "upgrade mode" from the moment it
> starts until the upgrade-steps worker is finished. During this period API
> logins are heavily restricted and most of the agent's workers don't start
> until upgra
Right now, a Juju machine agent is in "upgrade mode" from the moment it
starts until the upgrade-steps worker is finished. During this period API
logins are heavily restricted and most of the agent's workers don't start
until upgrade mode stops.
This happens even when there is no upgrade to perfor
In recent versions of Juju (i.e. post 1.20) the "agent-state-info" field
for each machine agent in the status output will say "upgrading to
" while the upgrade is in progress. This is could be used by tests
to know when the upgrade is finished.
On 6 August 2014 05:40, Horacio Duran wrote:
> H
take a look at restore, it does that by hand look for rs.config on the code.
On Tue, Aug 5, 2014 at 5:33 PM, Wayne Witzel
wrote:
> A user had some issues after an upgrade put them on the unstable Juju
> path. We've been working to get them back on stable and finally have them
> upgraded to 1.20
A user had some issues after an upgrade put them on the unstable Juju path.
We've been working to get them back on stable and finally have them
upgraded to 1.20.1.
The issue we've run in to is that we have manually run an rs.initiate() to
get the replica set setup. When they jumped versions it was
On Tue, Aug 5, 2014 at 4:18 PM, roger peppe wrote:
> close ports 80-110 -> error (mismatched port range?)
I'd expect ports to be closed here, and also on 0-65536.
gustavo @ http://niemeyer.net
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists
Hello,
I am working in to reproduce some of the CI Jenkins jobs on my local
Jenkins installation, but sometimes is a bit hard to replicate the
exact job configuration.
I am wondering if someone else is interested in to create a
versionable configuration of the jenkins installation, so we can just
Hey, I have been running several CI tests lately and find very often the
following error:
2014-08-04 22:27:42 ERROR juju.cmd supercommand.go:323 upgrade in progress
-
At least when my machine is not under heavy load and I am at decent network
reach of amazon.
I wonder, is there a way to poll juju t
Hi,
given that juju ssh now proxies by default via the bootstrap node, do you
think it would be a good idea to have a new option that would allocate a
floating IP only for that node, and not any other future nodes?
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe
+1
also:
close ports 90-110 -> error (cannot close part of a port range)
close ports 80-110 -> error (mismatched port range?)
On 5 August 2014 13:51, Domas Monkus wrote:
> Ok, so the behavior would have to be:
> opened ports : 80-100
>
> close ports 60-70 -> no error (noop)
> close ports 60-9
+1
also:
close ports 90-110 -> error (cannot close part of a port range)
close ports 80-110 -> error (mismatched port range?)
On 5 August 2014 13:51, Domas Monkus wrote:
> Ok, so the behavior would have to be:
> opened ports : 80-100
>
> close ports 60-70 -> no error (noop)
> close ports 60-9
Ok, so the behavior would have to be:
opened ports : 80-100
close ports 60-70 -> no error (noop)
close ports 60-90 -> error (cannot close part of a port range)
close ports 80-100 -> no error
I'm starting to think this scenario is preferrable, especially with respect
to the idempotency of charm ho
imo, no, its a no-op. the end state is still the same. if its an error, and
now we have partial failure modes to consider against ranges.
On Tue, Aug 5, 2014 at 1:25 PM, David Cheney
wrote:
> Yes, absolutely.
>
> On Tue, Aug 5, 2014 at 8:33 PM, Domas Monkus
> wrote:
> > A follow-up question:
Yes, absolutely.
On Tue, Aug 5, 2014 at 8:33 PM, Domas Monkus wrote:
> A follow-up question: should closing a port that was not opened previous to
> that result in an error?
>
> Domas
>
>
> On Fri, Jun 27, 2014 at 2:13 PM, Matthew Williams
> wrote:
>>
>> +1 on an opened-ports hook tool, I've add
A follow-up question: should closing a port that was not opened previous to
that result in an error?
Domas
On Fri, Jun 27, 2014 at 2:13 PM, Matthew Williams <
matthew.willi...@canonical.com> wrote:
> +1 on an opened-ports hook tool, I've added it to the task list
>
>
> On Fri, Jun 27, 2014 at 9
19 matches
Mail list logo
