Rohit, David emailed the following instructions:
> On a slightly related note, there is now a CloudStack authorization > group in reviewboard and any committer can now file a ticket with > INFRA and request to be added to that group and gain the ability to > close existing submissions. On Wed, Dec 19, 2012 at 2:19 PM, Rohit Yadav <rohit.ya...@citrix.com> wrote: > 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 > >
