+1 I like the idea. However, we will have to make sure that the regex is
limited to the server's working directory only.
On Mon, Jan 30, 2017 at 5:23 PM Jens Deppe wrote:
> What about simply having --exclude and --include options that take a regex
> in order to exclude and
On Mon, Jan 30, 2017 at 10:15 AM, Udo Kohlmeyer
wrote:
> I think stats should always be included by default
+1 stats should be included always. If they are not needed, users can use
--include-stats=false.
I'm not sure I like the --stats-only flag since the command
I think stats should always be included by default
maybe a '--stats-only' or '--logs-only' flag...
On 1/30/17 10:08, Kevin Duling wrote:
+1 to the idea of '--include-stats'
If --include-stats is offered, there should also be a '--stats-only' flag.
That way you can get logs, logs and
+1 to the idea of '--include-stats'
If --include-stats is offered, there should also be a '--stats-only' flag.
That way you can get logs, logs and stats, or just stats.
On Fri, Jan 27, 2017 at 11:30 AM, Swapnil Bawaskar
wrote:
> >
> >
> >
> > There are some
The ‘export logs’ command deals with this by having —start-time and —end-time
parameters that can be used to specify a particular time window. I’m not sure
whether statistics files roll over and have timestamps or not. This could be
one approach to limiting the size of the data returned for
I agree with dan... We need to be able to limit how much data is being
collected and sent.
In many cases clients don't clean up the files so they might drag a lot
of stuff over.
On 1/26/17 13:52, Dan Smith wrote:
+1 for export artifacts and +1 for zip-file
I'm also generally in favor of
+1 for export artifacts and +1 for zip-file
I'm also generally in favor of gathering the artifacts on the gfsh client
but I am a little concerned that in some cases that could be a lot of data
going to the client (10s or 100s of GBs), especially if logs and stats
aren't being cleaned up on a