> On Dec. 4, 2012, 7:29 p.m., Prasanna Santhanam wrote:
> > I like the idea that this script can be provided as a convenience to 
> > collect various logs. One problem however is that the script assumes root 
> > access on the management server and executes a bunch of commands (ip 
> > routes, hostnames, top, df, dmesg) etc that someone might not be okay with. 
> > May be it should be made interactive and warn the user of the actions it 
> > will/has performed. When as a commercial support provider you have 
> > permission to access and troubleshoot a system it would be okay to run 
> > this. But IMO it could be provided by that company which is looking to 
> > provide support to the operator of the said cloud to simplify their process 
> > of support. So I'm slightly wary of accepting something like this unless 
> > someone else convinces me that this would absolutely be beneficial. Also 
> > admins operating large clouds might be using a syslog server to already do 
> > some (or more) of these actions for them. If the logs are moved away from 
> > where one expects them to be then this script fails.

> So I'm slightly wary of accepting something like this unless someone else 
> convinces 
> me that this would absolutely be beneficial.
Prasanna, let me try then. 

The main reasons why I created this tools: 
1. CloudStack is a project which targets cloud enthusiasts but also 
"enterprises" and if you have a look on all the big products, vendors on the 
marker they offer utilities which do exactly what cs-bugtool does. Collect 
logs, basic system and configuration information. Examples: NetApp autosupport, 
XenServer xs-bugtool, VMware vSphere Client does this, . . ., and many others 
which I don't know. So IMHO CloudStack should also include this type of utility.
2. CloudStack becomes more and more complex, having this log bundle we can 
share it with other trusted persons or some support representative and this 
really can speed up analysis, avoid tens of questions, sending emails and files 
back and forth. 
3. I fully understand your concern about sharing sensitive information and to 
address this: 
 a.) I am going to implement some switches which let user decided what to 
include in output archive 
 b.) It's clearly written in README but we can repeat this information what 
exactly is collected 
 c.) We can add warning, the output archive can contain information which you 
can consider as a sensitive please be aware of this and be careful with who you 
sharing this(!!!)
 d.) The main use case of this utility is to share output archive with trusted 
people or some sort of support representative not to make public users' 
configurations. We do not send any information automatically, we just give a 
user a blob and user decides what to do with this. 

> script assumes root access on the management server and executes a bunch of 
> commands
This is a good point, I need to add logic which detect non-root execution 
situation. 
We this also should be in README. 

I hope above change your mind :) 

Radek.


- Radoslaw


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/8248/#review14023
-----------------------------------------------------------


On Dec. 4, 2012, 6:49 p.m., Radoslaw Smigielski wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/8248/
> -----------------------------------------------------------
> 
> (Updated Dec. 4, 2012, 6:49 p.m.)
> 
> 
> Review request for cloudstack, Prasanna Santhanam and Rohit Yadav.
> 
> 
> Description
> -------
> 
>   The main purpose behind cs-bugtool is to make easier collecting 
> logs required for CloudStack/CloudPlatform troubleshooting 
> and it mainly comes from Support. cs-bugtool collects logs, system 
> information and cloud database dump, compress everything and creates 
> .zip archive file ready to share with others. 
> For those familiar with Xen/XenServer cs-bugtool name may sound similar 
> to xen-bugtool, this similarity is intentional. 
> 
>   Current version of cs-bugtool collects: 
>  - basic system and environment information
>  - CP/CS management service logs 
>  - basic system logs 
>  - cloud database 
> 
>   Current version does not accept any arguments but this may
> changed in next iterations of cs-bugtool. 
> 
>   We DO NOT collect and do not want to collect any sensitive information.
> If there is still any sensitive pice of information please let us know
> and we will try to remove it or replace by meaningless data.
> 
> 
> Diffs
> -----
> 
>   tools/support/README PRE-CREATION 
>   tools/support/cs-bugtool PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/8248/diff/
> 
> 
> Testing
> -------
> 
> I tested this on CS 3.0.4 and 3.0.5.
> 
> 
> Thanks,
> 
> Radoslaw Smigielski
> 
>

Reply via email to