How to Control Two Servers with a Single User Interface?
My users can initiate a series of jobs, which to them, all look the same, and are part of the same product family. Based on their environmental variable choices, the individual job needs to be routed to either of two servers, because among other things, a different version of a compiler is used. What's the best way to set this up?
The trouble is that when the master console is choosing a server, it doesn't take environmental variables into account. So the choice either has to be done by the user (by choosing among different projects - but that doesn't maintain the requirement of the single user interface), or in a step using .bset AFTER the master console has already assigned the job to a server. The problem with the latter approach is that working directories don't get set up properly if the server is changed. Thanks, John Bobinyec |
3 answers
|
I might have found a way to do this with project chaining. The users would run a project which does nothing more than examine their environmental choices and would then end with either PASS or FAIL. This would set off either of two chained projects which would actually get the work done, but would be sent to the proper server by their own selector.
The key is whether or not the success or failure of the chained projects is accurately reflected up to the user ( don't want the pseudo-failure of the first project to make the user think their project actually failed) and whether the working directories are set up properly on the target servers. I'll post what I find out, unless someone can save me from this rigamarole. Thanks, John Bobinyec |
At our site, we have build and deploy processes where there are several steps that run on specific servers known at the time of the project creation and we set the selector in the step to the appropriate selector. Some of the steps run on a server whose name is stored in a property file, so we have one step that does a .bset selector and then the steps that run on the server specified in the property file just have the selector set to default. You can do this as many times as you need in a single project.
I think this would be easier than using pass/fail chains. |
At our site, we have build and deploy processes where there are several steps that run on specific servers known at the time of the project creation and we set the selector in the step to the appropriate selector. Some of the steps run on a server whose name is stored in a property file, so we have one step that does a .bset selector and then the steps that run on the server specified in the property file just have the selector set to default. You can do this as many times as you need in a single project. I started out with .bset server and then moved on to .bset selector. It seemed to work well except that the working directories are only created on the initial server. So then I tried moving to chaining projects together. The problem I'm trying to solve is that I need to create a data file in one of the steps and have it available for a later step. Both of these steps execute on the same server, so I just need to know where to put it. I thought of putting it in the working directory because it's unique to the job, and the working directory gets cleaned up when the job is purged. It sounds to me like I'm going to have to create a private directory, put the data in it, and then clean the directory myself. Besides the extra work that this entails, the data file is gone as soon as the job is finished. If it were kept in the real working directory, at least it could be left around until the job is actually purged. Thanks, John Bobinyec |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.