the job target lists are always going to be resolved to the servers - the group names do not carry through. why can't you use the smart groups directly as the job targets ?
Hi Bill --
Once we begin our prep work for a particular group of servers (opening change records, doing email notifications, compliance scanning or patch analysis, etc...) we do not want the list of servers to change at all. Other people do various other BladeLogic maintenance tasks during the week, which may cause servers to fall into or out of the smart group. Thus, in order to maintain a consistent list for the work, we need to use the static group as a snapshot of the server list at that point in time.
In other words, if a half-dozen servers found their way into the smart group on the day the maintenance was to be performed, and were worked on and rebooted without any notice being sent or any change requests being filed, lots of people would be very unhappy with us and say lots of naughty words.
This process was actually established for us by the original consultant who set up BladeLogic in our environment, and has worked very reliably for us for the past few years. We recently upgraded to version 8.1 of the console, and with the slower performance and the paging of groups, the task of emptying and re-populating the static groups now takes close to 6 hours per week (prior to the upgrade it took about 1-2 hours) and our staff member who does it is much less happy. So we are looking for a way to automate the emptying and re-filling of the groups.
You can do it using blcli's though -
server findAllByServerGroup to get all Servers in the group - shoudl work for smart groups
server findServerObjectsByGroup - get server objects and then getName or so
"StaticServerGroup removeServerFromServerGroupByName" - removes a server from a server group name
StaticServerGroup addServerToServerGroup to add new server
That is not what he’s trying to do. he’s trying to get the name of the group that is the target of the job.
Oh , i thought he is open to this
"Or would there be another/better way to clear out and re-populate a static group based on a smart group? We cannot have the script create a new static group, because the groups we want to work with are already specified as targets for several other jobs (so we don't want to have to go re-assign the new groups)."
Yeah – but I think he still wants to pass in the name of the group as the target, not as an arg.
Well ideally, all we want to be able to do is find an easy way to specify or change the target group -- without having to type in or hard-code it anywhere (there are several dozen). I've specified groups as parameters to NSH scripts before, and been burned by typographical errors ("Oh, whoever named this group put 2 spaces and I spelled it as 'Gorup' instead of 'Group'...). It occurred to me that since you can select a group as a target, there might be some way to reference the group itself, instead of just a list of server names.
Outside of the console functionality, would there be any way to use BLCLI commands to refer to the job itself and see the target list? I wouldn't mind doing it that way, we could keep the job with a constant name and location, and just use "Execute Against" for each run.
Just looking for any way to make this whole process less cumbersome. (Other than reverting back to version 7.x, I mean...)
if i understood you correctly
Yes, there is tricky hack where in u can refer to the job itself
Whenever the appserver runs a NSH script job it copies the NSH script to a temp path with a name that contains the Job DB Key, so you can take the $0, the name of the script actually running , and get the db key
once yoou have the db key, you should be able to get job details including the target server list, see Job namespace of blcli or NSHScript namespace job for the same.
here is the perl code I have which gets the db key, you can translate it into NSH
print "\n Script Job db key is $script_dbkey";
and yes this way you dont have to keep this job at a fixed location with fixed name.
You still can’t get the name of the target server group, even w/ the job key ☺
1 of 1 people found this helpful
so what if you set a server property on the set of servers you want to use at a point in time, targeted another smart group for your jobs, and then reset that property when you were done?
That could work... the only issue there is that we already have (literally) hundreds of jobs pointing to our various static groups. So there would be quite a manual effort to re-direct all those jobs to the NEW smart groups.
I will keep that in mind as a "last resort" option if nothing better presents itself.
I'm having a hard time believing that there is no way to talk to the target list directly and see what the UI sees. UI has no trouble showing the group name, so there must be SOME way to get it!
Yes – you can get the job target groups via some db queries –but that doesn’t really work in a nsh script…
So to move everything to smart groups you could run some db queries and then use the blcli to reset the job targets after you set the property value and create new server groups. I don’t think that is a last resort – it should be pretty easy.
Hi Bill --
For us, it would be a last resort simply because of the sheer number of jobs and target groups currently set up. As an example, these tasks are for our 4-week patching process. The first week alone has over 150 jobs that would have to have the targets reset to the new smart groups. Unfortunately, the groups are named in such a way (at present) that we could not systematically or programatically reference them in a script (they include, for example, day of the week, as well as other descriptive text). Over a 4-week schedule, this ends up affecting over 600 jobs in total.
In this case, we would still have to hard-code the group names somewhere -- into a text file for input, say, or into the script itself. And, if we did this, we are back to the situation I was hoping to avoid (manually keying in group names). While we could consider changing the group names to something more automatic, our concern is that transparency/clarity may become lost in the process.
Or, put another way, it's a lot easier to remember what "Week 1 Thursday Group B 0300 Special No-Reboot" is when reading it, than "Week 1 Group 27" would be.
Aparently, we're just too complicated for our own good.
Maybe there would be a way to start at a specified top "node", and then recursively iterate through all the static groups under that one and export the group names to a text file? That would at least eliminate the possibility of typos and allow for us to add or change names to the group structure.