topic Re: <CALL TO ACTION> SAS_lsm, the next generation in Administration and Deployment

SAS_lsm, the next generation

clmeye — Mon, 15 Apr 2019 11:49:59 GMT

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

Re: SAS_lsm, the next generation

ronan — Tue, 16 Apr 2019 12:17:50 GMT

Hello Cliff,

Thanks a lot for asking !

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

zip and keep
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

Re: SAS_lsm, the next generation

clmeye — Wed, 17 Apr 2019 13:12:29 GMT

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

Re: SAS_lsm, the next generation

SASKiwi — Wed, 17 Apr 2019 20:00:52 GMT

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.

Re: SAS_lsm, the next generation

PaulS_ — Tue, 14 May 2019 15:38:05 GMT

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

Re: SAS_lsm, the next generation

sgibbs — Tue, 18 Jun 2019 14:58:45 GMT

Definitely that windows support!

Thanks Cliff!

Re: SAS_lsm, the next generation

Resa — Wed, 19 Jun 2019 17:58:42 GMT

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.

Re: SAS_lsm, the next generation

JuanS_OCS — Wed, 19 Jun 2019 18:20:59 GMT

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.

Re: SAS_lsm, the next generation

JuanS_OCS — Thu, 27 Feb 2020 15:44:59 GMT

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

Re: SAS_lsm, the next generation

clmeye — Thu, 27 Feb 2020 16:06:10 GMT

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.

Re: SAS_lsm, the next generation

JuanS_OCS — Thu, 27 Feb 2020 16:13:42 GMT

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.