incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <>
Subject Re: Review Request: cs-bugtool implementation, new troubleshooting tool dedicated for collecting CS logs and basic system information
Date Wed, 19 Dec 2012 15:31:41 GMT
On Wed, Dec 19, 2012 at 2:00 AM, Radoslaw Smigielski
<> wrote:
>> 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.
>> Radoslaw Smigielski wrote:
>>     > So I'm slightly wary of accepting something like this unless someone else
>>     > 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 Smigielski wrote:
>>     > The collated logs may contain private information, and if you are at all
>>     > worried about that, you should not use this tool, or you should explicitly
>>     > exclude those logs from the archive.
>>     Prasanna, this is fragment of README.xen-bugtool taken from project.
>>     We can add similar disclaimer in our README and in cs-bugtool output.
>>     Radek.
>> Hugo Trippaers wrote:
>>     I agree with the worry of Prasanna that this script is mainly useful for parties
that provide support professionally. That said it can not hurt to have the tool in the main
code, but it might trigger people to make these blobs and send them to the -users mailing
list looking for support. Not sure yet if that is a good thing or not. A lot of deployments
will have slight changes based on the preferences of the administrators, so the script should
handle this gracefully.
>>     Note on testing, this should be tested on at least a recent ASF release (4.0.0-incubating)
or a recent branch (4.0 branch or master branch).
>> Rohit Yadav wrote:
>>     The idea is that a lot of stuff that has nothing to do with CloudStack directly
should not be part of it.
>>     I would suggest that you work on this on your own git repo, say on github and
share with users. Get their feedback on ML, implement new features and if everyone starts
using this for sharing logs, we can go ahead and merge it. I only worry that if this gets
committed now, and not used it would add bloat. I would really want to use this tool if this
could also go to all the hosts and maybe ssvm/cpvm and get me logs, it would be awesome. But,
if the folks don't give this a "ship it" I would want you to show 'em why we would want this
tool with the next iteration of this tool and features.
>>     It makes sense to not commit tools that should n't be part of CS, for ex. let
me give my personal examples;
>>     Initially I was writing cloudmonkey as a separate repo, but then I thought it
is dependent on apis, marvin, so I moved it in.
>>     I've another cmd tool that helps me review,
>>     I did not commit it because, even though I think it's an awesome tool to reviewing
stuff and it was helpful to me at least during the 4.0 release.
>>     See repos by tsp,, he has a lot of 'em on test infra
etc. but it does not make sense to move all of that code to CS-git.
> I understand some of above concerns but not all of them :)
> Rohit, I followed your advice and forked incubator-cloudstack repository on github,
> Please discard this review request.
> - Radoslaw

I've just discarded it.

I'd suggest that you actually don't want to fork the cloudstack
codebase, as much as you should have your own repo with just this code
in it.  That way, it can evolve independently!


View raw message