Hi,
My set up is as follows.
Machine A) my local machine - client machine for test studio
Machine B) VM - Storage Service, Scheduling Service, Execution Service
All components seem to be able to see each other, but running a list remotely from my local machine throws and error relating to the access of the Storage Service.
I get the following error message
"Running test list failed internally due to an unhandled error", the log entry for this is as follows
"[04/30 11:47:06,Telerik.TestStudio.Desktop.exe(13464:1),TestStudio] StorageUploader.UploadToCloudAsync() : ------- Function Start -------
[04/30 11:47:09,Telerik.TestStudio.Desktop.exe(13464:23),Error] CloudStorageSession.SendRequestAsync() : Send to Storage failed: An error occurred while sending the request.
[04/30 11:47:09,Telerik.TestStudio.Desktop.exe(13464:23),Error] CloudStorageRepository`2.All() : Response is null due to a hardware connnection error."
So it seems there is an issue connecting to the storage service - this can be further backed up by looking into the Mongo dB - See attachment. "RoboDatabaseStructureMissingDataBase.PNG" where there is no "TSStorageData" database.
So far I have tried everything I can find under similar issues - restarting the services, dropping the database, using fully qualified address for services.
I can run test lists locally.
All settings - see attachments - seem to be as should be.
All version are the same.
The firewall on the vm is turned off.
The security protection in azure (which hosts the vm) has been opened for all ports,
I can connect my client to the remote scheduling server.
I'm at a loss - could you please help to resolve this issue
Thank you.
4 Answers, 1 is accepted
Thank you for the detailed description of the setup you have built. I also appreciate your efforts to find a solution on your own using any public resources on the topic.
Basically, the configuration seems to be correct as you pointed yourself, though the Storage service still cannot be accessed. This is the reason why there is no TSStorageData collection in the MongoDB. There are few things, which I am not completely sure of, and will be happy if you correct me in any of the below statements:
1. The two machines are in different domains (since the VM is hosted in Azure)
2. Ping from machine A to B and vice versa is successful
3. Machine B is named sel-uks-01 and its IP is 51.145.118.237.
Assuming that the above notes are correct, here are few more things to try: If Machine A - the local one, has an active firewall and/or antivirus software, please stop these (or at least the firewall) for testing purposes. Then try to run a test list on the Machine B. Does this change the behavior?
- if the run is successful in this situation and it was the firewall that prevented the communication, please open ports 8009, 8492 and 55555 on Machine A both in- and outbound. Then activate the firewall (and AV if applicable) and verify if the run is still possible.
- if the execution with disabled firewall was still unsuccessful, please, open the Scheduling setup wizard and in the third tab (pint 4. in the mentioned article) enter the IP address of Machine B for the Storage Service Location, then apply the changes. Will a remote run start with this configuration?
In addition, please, ensure the logged users on both machines have admin rights and they will not be restricted in any action.
In case the issue is still ongoing, please generate the complete application logs for both machines during an attempt to run - the application log on the local machine can be accessed through the Help menu and the one from Machine B can be found in the Execution Status view. Please, first clear the logs - that way the information in the files will be only relevant to the current issue. Then try to execute a remote run to generate the encountered error. After that you can collect the generated log records and send these zipped via this communication thread.
I hope the shared information is useful and will help us to find out what prevents the successful communication with the Storage. Please, do not hesitate to get back to me in case of any further questions or doubts.
Regards,
Elena Tsvetkova
Progress Telerik
Rank 1
Thank you for a quick response – I’ve worked through your notes as summarized below
Your 3 statements were correct. This issue turned out to be our firewall – however this is run by our networking and infrastructure team, and it wasn’t possible to open specific ports for my machine, so to work around we spun up another azure vm to be used as our client machine connecting to a second vm for execution, scheduling and storage.
This has resolved the issue for us.
Thank you once again for your help here.
Rank 1
Hi Elena -
Because our infrastructure wont allow certain ports to be opened fully on client machines - Opening these ports would leave our entire network at risk - are there plans to improve this mechanism in the future, or are there other workarounds available?
Thank you
Thank you for getting back to me. I am pleased to know my directions were helpful to drill down what caused the error.
To address your next query I have to admit that there are no plans for changing the communication flow of how Test Studio communicates in a multiple machine environment. Actually, we had improved the communication flow recently and reduced the necessary ports to these I mentioned already - 8009, 8492 and 55555. And to be honest, if there will be any data exchanged between different machines, there should be some ports available to ensure the machines can reach each other.
Having that said, a possible next step is to discuss the matter with the networking and infrastructure team on your end and decide how to allow these ports for Test Studio without threatening the network vulnerability. As a side note for such a discussion is that these ports are configurable as of Test Studio point of view - in the Scheduling configuration wizard, in its last tab (point 4. in the shared article), you can set different ports for the Scheduling and Storage services. That way you can use ports in a range, which will suit the particular requirements.
I hope this information will be helpful for you. Of course, if you have any further question, I will be happy to continue the discussion on this topic.
Thank you in advance for your understanding.
Regards,
Elena Tsvetkova
Progress Telerik