<CALL TO ACTION> SAS_lsm, the next generation

[clmeye]

Fellow administrators

Today, version 3.0 of the SAS_lsm utility provides consistent management of single or multi-tiered SAS-related services for UNIX/Linux deployments from a single shell script. Consistent management includes tier dependency checking, starting, stopping, status checking (tier- and deployment-based), error log collection, analysis, and potential resolution recommendations.   See blogpost The SAS_lsm Utility Makes it Easy to Control SAS Servers in a Multi-Tier UNIX/Linux Deployment for additional detail.

We are now in the process of defining potential version 4.0 line items. Currently under consideration:

• Solaris support
• Windows support
• GRID based support
• SAS_lsm non sas.servers based tier samples:
• ObjectSpawner
• DataFlux Data Management Server
• Visual Process Orchestration Server
• Visual Analytics LASR monitor
• Deployment Agent
• Environment Manager Server & Agent
• ...
• support customized pre & post tier based start/stop/status action user defined tools, for example: 
• backup 
• cleanwork
• log rolling
• user email notifications
• ...
• ...

Feel free to reach out here if you have any additional functionality that you would like to have considered for version 4.0 and/or if you have feedback on the items currently being considered.

Thanks!

Cliff

[ronan]

Hello Cliff,

Thanks a lot for asking !

I'd like having SAS_lsm next version being able, selectively (y/n=Default) perhaps, to

1. zip and keep
2. delete

   the old log files generated by the services (servers) to be stopped,

This being done conditionally with a retention policy of,say, 30 days by default.

The zip archive naming rule could be based upon the Server own folder name (grand-parent folder),

though sometimes it must be adjusted in the case of MidTier  specific folder hierarchies, sometimes deeper.

/<ServerName>/Logs/<ServerName>_<variable suffix>.zip

The variable suffix could be based upon ISO 8601 date format - completed by any random number if necessary.

2019-04-16  if daily

2019W16  (if weekly : Week 16 of 2019)

2019-04 (if monthly)

etc.

In addition to that, maybe also having meaningful Return Codes after the completion, like

for instance

RC_LSM=0 (OK)

RC_LSM=2 (SSH Error)

RC_LSM=...

This would be useful to pass on to the launcher tool (usually a scheduler, I suppose).

Ronan

[clmeye]

Ronan

Thanks for taking the time to provide great input!  I'll invite you to join us when we have a meeting to discuss the proposed v4 content...

Cliff

[SASKiwi]

Absolutely number 1 for us is Windows support. All our SAS infrastructure runs on Windows Server so we can't use SAS_lsm and have to resort to custom shell scripting done by IT administrators not familiar with SAS. As a result our server starting and stopping procedures are not as robust and reliable as they could and should be. It would be great to have the same automation capability under Windows that is already available for Unix.

[PaulS_]

Thanks Cliff!

I vote for Grid-based and non-sas.servers support, and also the ability to act on one individual tier (for example, just tier 4), or act on a range of tiers (for example, just tiers 4 through 6).

Thanks!

Paul

[sgibbs]

Definitely that windows support! 

Thanks Cliff!

[Resa]

My vote goes out to the non sas.servers based tier samples and like to suggest adding starting, stopping SPDS to the list.

Furthermore indeed adding the possibility to include cleanwork and backup is surely high on my wishlist.

[JuanS_OCS]

I think it would be nice some web tier and services maintenance, before starting services.

Also, for the new Grid M6 ( SAS provider ) perhaps implementing the support and interface for starting, stopping, status and restart of every service, using the template script in the documentation, so we can use a single script, eith different parameters, in the Services area of SAS Workload Orchestrator (or LSF/RTM), for the HA and Failover of each SAS service.

In addition, often some services, such as Object Spawners, do not want to stop gracefully, then sudo kill -9 is needed. Is this contemplated, somehow, in SAS_lsm?

I fully agree with Reza on scripting SAS_lsm not dependant on the sas.servers script, but using each service interface. One main reason for me to think about it is the fact that sas.servers do not cover properly certain standard prompts from SDW, such as the custom name or location of the SAS compute logs, in UNIX based OS.

[JuanS_OCS]

Hello @clmeye,

I was wondering, if almost after a year, you could share an update in regards of aprox release date of version 4.0, what would it include, etc. 

Looking forward to hear back from you!

Thanks in advance,

Best regards,

Juan

[clmeye]

Juan

Thanks for your patience.  We are still working through the backlog:

• Solaris support
• Windows support
• GRID based support
• SAS_lsm non sas.servers based tier samples:
• ObjectSpawner
• DataFlux Data Management Server
• Visual Process Orchestration Server
• Visual Analytics LASR monitor
• Deployment Agent
• Environment Manager Server & Agent
• ...
• support customized pre & post tier based start/stop/status action user defined tools, for example: 
• backup 
• cleanwork
• log rolling
• user email notifications
• ...

... and not yet ready to release.  Will keep everyone posted via this thread.

[JuanS_OCS]

Hi Cliff / @clmeye ,

thanks for your reply. I was hoping to see some more items than in the initial post of a year ago, perhaps some inclusions of what has been asked for input and discussed in this thread!

Will definitely keep attention to this thread.