You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Radoslaw Smigielski <ra...@eu.citrix.com> on 2012/11/28 15:34:01 UTC
Review Request: cs-bugtool implementation,
new troubleshooting tool dedicated for collecting CS logs and basic system
information
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/8248/
-----------------------------------------------------------
Review request for cloudstack.
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
Re: Review Request: cs-bugtool implementation,
new troubleshooting tool dedicated for collecting CS logs and basic system
information
Posted by Rohit Yadav <ro...@citrix.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/8248/#review14022
-----------------------------------------------------------
Looks better now, please add Prasanna (tsp) and myself on the people/reviewer field.
@Prasanna: can you do a review on this, before we commit it?
- Rohit Yadav
On Dec. 4, 2012, 11:50 a.m., Radoslaw Smigielski wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/8248/
> -----------------------------------------------------------
>
> (Updated Dec. 4, 2012, 11:50 a.m.)
>
>
> Review request for cloudstack.
>
>
> 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
>
>
Re: Review Request: cs-bugtool implementation, new troubleshooting
tool dedicated for collecting CS logs and basic system information
Posted by Chip Childers <ch...@sungard.com>.
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 <ro...@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 <ch...@sungard.com> wrote:
>
>> On Wed, Dec 19, 2012 at 2:00 AM, Radoslaw Smigielski
>> <ra...@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
>
>
Re: Review Request: cs-bugtool implementation, new troubleshooting
tool dedicated for collecting CS logs and basic system information
Posted by Rohit Yadav <ro...@citrix.com>.
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 <ch...@sungard.com> wrote:
> On Wed, Dec 19, 2012 at 2:00 AM, Radoslaw Smigielski
> <ra...@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
Re: Review Request: cs-bugtool implementation, new troubleshooting
tool dedicated for collecting CS logs and basic system information
Posted by Chip Childers <ch...@sungard.com>.
On Wed, Dec 19, 2012 at 2:00 AM, Radoslaw Smigielski
<ra...@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
Re: Review Request: cs-bugtool implementation,
new troubleshooting tool dedicated for collecting CS logs and basic system
information
Posted by Radoslaw Smigielski <ra...@eu.citrix.com>.
> 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
>
>
Re: Review Request: cs-bugtool implementation,
new troubleshooting tool dedicated for collecting CS logs and basic system
information
Posted by Radoslaw Smigielski <ra...@eu.citrix.com>.
> 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.
>
> 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.
- 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
>
>
Re: Review Request: cs-bugtool implementation,
new troubleshooting tool dedicated for collecting CS logs and basic system
information
Posted by Radoslaw Smigielski <ra...@eu.citrix.com>.
> 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
>
>
RE: Review Request: cs-bugtool implementation, new troubleshooting
tool dedicated for collecting CS logs and basic system information
Posted by Sudha Ponnaganti <su...@citrix.com>.
+1 on the suggestion by Rohit to keep it separate for time being.
Tool is useful for support professionals and debugging. We will give it a try
-----Original Message-----
From: Rohit Yadav [mailto:noreply@reviews.apache.org] On Behalf Of Rohit Yadav
Sent: Thursday, December 06, 2012 9:56 AM
To: Prasanna Santhanam; Rohit Yadav
Cc: cloudstack; Radoslaw Smigielski; Hugo Trippaers
Subject: Re: Review Request: cs-bugtool implementation, new troubleshooting tool dedicated for collecting CS logs and basic system information
> 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).
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.
- Rohit
-----------------------------------------------------------
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
>
>
Re: Review Request: cs-bugtool implementation,
new troubleshooting tool dedicated for collecting CS logs and basic system
information
Posted by Rohit Yadav <ro...@citrix.com>.
> 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).
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.
- Rohit
-----------------------------------------------------------
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
>
>
Re: Review Request: cs-bugtool implementation,
new troubleshooting tool dedicated for collecting CS logs and basic system
information
Posted by Hugo Trippaers <ht...@schubergphilis.com>.
> 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.
>
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).
- Hugo
-----------------------------------------------------------
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
>
>
Re: Review Request: cs-bugtool implementation,
new troubleshooting tool dedicated for collecting CS logs and basic system
information
Posted by Prasanna Santhanam <Pr...@citrix.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/8248/#review14023
-----------------------------------------------------------
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.
tools/support/cs-bugtool
<https://reviews.apache.org/r/8248/#comment29994>
- Prasanna Santhanam
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
>
>
Re: Review Request: cs-bugtool implementation,
new troubleshooting tool dedicated for collecting CS logs and basic system
information
Posted by Radoslaw Smigielski <ra...@eu.citrix.com>.
-----------------------------------------------------------
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.
Changes
-------
Changed reviewers as Rohit asked.
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
Re: Review Request: cs-bugtool implementation,
new troubleshooting tool dedicated for collecting CS logs and basic system
information
Posted by Radoslaw Smigielski <ra...@eu.citrix.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/8248/
-----------------------------------------------------------
(Updated Dec. 4, 2012, 11:50 a.m.)
Review request for cloudstack.
Changes
-------
Changes made since previous patch:
- excluded sensitive files: cloudmanagementserver.keystore, cloud.keystore, key
- checking if mysqldump in standard system PATH
- move logs directory under the system, it makes more sense to have them together
- changed the output filename from "cloud-bugtool_..." to "cloudstack-bugtool_..."
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 (updated)
-----
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
Re: Review Request: cs-bugtool implementation,
new troubleshooting tool dedicated for collecting CS logs and basic system
information
Posted by Radoslaw Smigielski <ra...@eu.citrix.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/8248/
-----------------------------------------------------------
(Updated Nov. 29, 2012, 2:25 p.m.)
Review request for cloudstack.
Changes
-------
Rohit, thanks for looking on this.
> 1. Make python code PEP8 compliant
Done.
> 2. Chmod +x cs-bugtool, so it's an executable by default
I am looking on the patch and see:
create mode 100644 tools/support/README
create mode 100755 tools/support/cs-bugtool
so I assume it should be right.
> 3. For the shebang interpretor use this path: /usr/bin/python
Done.
> Logs can have sensitive information (api, mgmt server logs for example with auth, keys information,
> access logs with full urls and sensitive values such as passwords and keys as arguments).
> Maybe we can identify such string patterns and search and replace them, add code for doing that?
I understand your concern but I am not sure how we can avoid this and how useful those information may be?
We would have session keys in api-server.log which are expired and even having those session keys it would be extremely difficult to use them. Please correct me is I ma wrong?
Maybe we can add some warring which will say, please be aware there may be some small piece of sensitive information in output file.
And after all, user who uses this utility is going to send this info to some trusted person, support representative to process it.
> 4. This is using zip (which assumes zip tool is preinstalled and which is the case for most installations)
We use Python zip library.
>5. Add help docs in README.
Done.
Cheers,
Radek.
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 (updated)
-----
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
Re: Review Request: cs-bugtool implementation,
new troubleshooting tool dedicated for collecting CS logs and basic system
information
Posted by Rohit Yadav <ro...@citrix.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/8248/#review13809
-----------------------------------------------------------
Radoslaw, nice tool. Can you see few issues:
1. Make python code PEP8 compliant and fix trailing spaces as per the coding conventions (http://docs.cloudstack.org/CloudStack_Documentation/Design_Documents/Coding_Conventions).
Download the pep8 tool and fix code:
pip install pep8
pep8 <cs-bugtool>
Fix whatever it reports
2. Chmod +x cs-bugtool, so it's an executable by default
3. For the shebang interpretor use this path: /usr/bin/python, /usr/bin/env does not exist for other than Linux distros, /usr/bin/python is standard for most Linux distros and Macs. But assuming this would be used by users, how is a user supposed to use it? Logs can have sensitive information (api, mgmt server logs for example with auth, keys information, access logs with full urls and sensitive values such as passwords and keys as arguments). Maybe we can identify such string patterns and search and replace them, add code for doing that?
4. This is using zip (which assumes zip tool is preinstalled and which is the case for most installations), may be make it pure python so as to avoid external dependencies, like explore built in packages such as http://docs.python.org/2/library/zipfile And make sure whatever shell tools the script would execute, they are available for standard installations.
5. Add help docs in README.
- Rohit Yadav
On Nov. 28, 2012, 2:33 p.m., Radoslaw Smigielski wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/8248/
> -----------------------------------------------------------
>
> (Updated Nov. 28, 2012, 2:33 p.m.)
>
>
> Review request for cloudstack.
>
>
> 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
>
>