> 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 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 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 xen.org > 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, > https://github.com/bhaisaab/RBTool > 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, https://github.com/vogxn, 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, https://github.com/radeksm/incubator-cloudstack Please discard this review request. - 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 > >
