Re: Port ranges - restricting opening and closing ranges

2014-08-06 Thread Kapil Thangavelu
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 gust...@niemeyer.net wrote: On Tue, Aug 5, 2014 at 4:18 PM, roger

Re: avoiding unnecessarily entering upgrade mode

2014-08-06 Thread John Meinel
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

Re: Port ranges - restricting opening and closing ranges

2014-08-06 Thread Gustavo Niemeyer
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

Re: avoiding unnecessarily entering upgrade mode

2014-08-06 Thread Dimiter Naydenov
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This SGTM as well, however (see below)... On 6.08.2014 04:10, 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

Re: Port ranges - restricting opening and closing ranges

2014-08-06 Thread roger peppe
On 5 August 2014 19:34, Gustavo Niemeyer gust...@niemeyer.net wrote: On Tue, Aug 5, 2014 at 4:18 PM, roger peppe rogpe...@gmail.com wrote: close ports 80-110 - error (mismatched port range?) I'd expect ports to be closed here, and also on 0-65536. I'm not sure. An advantage of requiring that

Re: Port ranges - restricting opening and closing ranges

2014-08-06 Thread Gustavo Niemeyer
How many port ranges are typically made available? One.. Two? Sounds like a trivial problem. In terms of concurrency, there are issues either way. Someone can open a port while it is being closed, and whether that works or not depends purely on timing. gustavo @ http://niemeyer.net On Aug 6,

Re: Port ranges - restricting opening and closing ranges

2014-08-06 Thread Gustavo Niemeyer
Why would any application well designed open thousands of ports individually rather than a range? Sounds like an unreasonable use case. I also don't get your point about concurrency. You don't seem to have addressed the point I brought up that opening or closing ports concurrently today already

Re: Port ranges - restricting opening and closing ranges

2014-08-06 Thread roger peppe
On 6 August 2014 13:57, Gustavo Niemeyer gust...@niemeyer.net wrote: Why would any application well designed open thousands of ports individually rather than a range? Sounds like an unreasonable use case. I don't know. But if it's easy to make it work well in this case too (and I believe it

Re: Port ranges - restricting opening and closing ranges

2014-08-06 Thread Gustavo Niemeyer
gustavo @ http://niemeyer.net On Aug 6, 2014 3:03 PM, roger peppe roger.pe...@canonical.com wrote: On 6 August 2014 13:57, Gustavo Niemeyer gust...@niemeyer.net wrote: Why would any application well designed open thousands of ports individually rather than a range? Sounds like an

Re: getting rid of all-machines.log

2014-08-06 Thread Tim Penhey
On 06/08/14 16:11, Nate Finch wrote: all-machines.log seems both redundant and a ticking time bomb of disk space usage. Do we really need it? Can we drop it and maybe later schedule some time to use something like logstash that is both more featureful and is cross platform compatible (unlike

Re: getting rid of all-machines.log

2014-08-06 Thread Nate Finch
Fair enough, I forgot about debug-log. Do we have an idea of how we'll aggregate logs from Windows machines? rsyslog won't run there. We might be able to do a go-only solution by using the syslog package gabriel made a port of it that will run on Windows and supports TLS:

Re: getting rid of all-machines.log

2014-08-06 Thread John Meinel
That's probably a reasonable starting point. With the caveat that we know we don't really want to just use rsyslog forever. Just didn't get scheduled for this cycle. John =:- On Wed, Aug 6, 2014 at 4:42 PM, Nate Finch nate.fi...@canonical.com wrote: Fair enough, I forgot about debug-log. Do

Re: avoiding unnecessarily entering upgrade mode

2014-08-06 Thread William Reade
SGTM too. It should always have worked like this -- rerunning all our upgrade steps every time is *crazy*. On Wed, Aug 6, 2014 at 3:19 AM, David Cheney david.che...@canonical.com wrote: SGTM. On Wed, Aug 6, 2014 at 11:10 AM, Menno Smits menno.sm...@canonical.com wrote: Right now, a Juju

Re: getting rid of all-machines.log

2014-08-06 Thread Aaron Bentley
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14-08-06 10:11 AM, Nate Finch wrote: all-machines.log seems both redundant and a ticking time bomb of disk space usage. Do we really need it? Can we drop it and maybe later schedule some time to use something like logstash that is both more

Re: Reproducing Jenkins

2014-08-06 Thread Aaron Bentley
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14-08-05 02:24 PM, Jorge Niedbalski wrote: 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