Details

Description

To prevent having to ask the customer for two different sets of output, can we please include the information contained within http://<host>:8091/diag in the collect_info output? I don't think we "need" to just call that URL, but that might be easiest (though very inefficient since we're already calling browse_logs). It's just the top part of the 'diag' that's necessary

Is that really necessary? Surely we can get the same information out of erlang without requiring the username/pass? It will just add to the complexity of support having to explain how to use this tool to the user...and all of the ones that currently use it a) will have to change and b) might forget to and defeat the purpose altogether.

I'm going to have to push back on requiring the username/pass since we currently get all that we need without it.

Perry Krug
added a comment - 08/May/12 1:22 PM Is that really necessary? Surely we can get the same information out of erlang without requiring the username/pass? It will just add to the complexity of support having to explain how to use this tool to the user...and all of the ones that currently use it a) will have to change and b) might forget to and defeat the purpose altogether.
I'm going to have to push back on requiring the username/pass since we currently get all that we need without it.

Steve Yen
added a comment - 10/May/12 3:35 PM Bin did this is a way where optional user/pswd aren't needed.
Bin just looked at what /diag was providing above and beyond cbcollect_info and added what he could to cbcollect_info in a way such that he didn't need to query a running ns_server process.

Steve Yen
added a comment - 30/May/12 7:52 PM looks like collecting /diag is important...
reopening this bug to get these additional steps...
1) get the REST user/pswd out of the cbdumpconfig.escript (rest_creds).
2) using the REST user/pswd to grab a CURL /diag output into the cbcollect_info zip file.