Chip, how did you get your superpower to discard (I'm guessing submit as well) a review request? May I have the superpower to close a review request once it has been shipped?
Regards. On 19-Dec-2012, at 7:31 AM, Chip Childers <chip.child...@sungard.com> wrote: > On Wed, Dec 19, 2012 at 2:00 AM, Radoslaw Smigielski > <radoslaw.smigiel...@eu.citrix.com> 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 >>>> 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 >> > > 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! > > -chip
