BookmarkSubscribeRSS Feed
Calcite | Level 5

A lot of shops are going to desired state configuration tools, like Puppet, Chef, SaltStack, Windows PowerShell DSC, etc., to enable rapid deployment of systems and to reduce drift. I looked through and Google and haven't seen any mention of SAS and desired state configuration tools, so I thought I would float the question.

Does SAS have (or intend to produce) modules, cookbooks, or other packages that will allow SAS Administrators to declare a desired state and let the "automagic" system make it so? For instance, it would be great to have, say, a Puppet manifest that contains all user definitions with information like groups they should (or should not) belong to, accounts, etc., that my team would update and run whenever we add or remove a user from the system or a group. Running the manifest through Puppet would make the necessary changes to Metadata to make the environment resemble the desired state. A different manifest file could control server mappings, connections, and such, while a third could handle libraries. This would get us out of the business of either pointing-and-clicking our way through the wizards (which hurts with over a thousand users and almost as many libraries) or writing our own Bash-and-SAS tools to do it automate it ourselves (which is a support headache). Similar concepts apply to Chef cookbooks, PowerShell DSC definitions, et al.

Producing such a package as the vendor would mean that the user community doesn't have to write the package on a case-by-case basis for their own systems, that it follows SAS' own best-practices and advice, and it would be a nice advertising point showing that SAS is keeping up with emerging trends to simplify systems automation at scale.

This is mainly for my own curiosity. Thanks!

Amethyst | Level 16

I also would like to know! Smiley Happy

Barite | Level 11

This could be added to (yep juan)

If I understand you are talking on the infrastructure DTAP(middleware). For the D (Development) you have the SDW to build an initial version.

It would be far more acceptable when it was a rpm (Red Hat Package Manager) with a clear segregation between the installation and configuration.

The SASHFADD is for fixes and should not be used on the -TAP only on the D.  This is IMO not what SAS institute is assuming.

There are batch tools SAS(R) 9.4 Intelligence Platform: System Administration Guide, Third Edition   you could do something in a cookbook (template) with that.

There are synchronization tools for identity management. The issue with all this is that the last details can not be solved.

An Rbac implementation will be always be different on technical details and on organizational details.

The same applies for business environments (code life cycle management and data segragations). Mostly other tools are used for that. (nolio endeavor) as there are technical and organizational differences. This is a business DTAP life cycle process.

To get all the hierarchy these is also something and the low level OS network etc. That is having also a life cycle management.

With configuration management there is an attempt to manage that all. 

Com on SAS why are your guys not aligned to all of this?

---->-- ja karman --<-----
Pyrite | Level 9

I would also love to see this feature.

Instead of the mentioned DSC tools, the support for Docker ( would also be nice.

I also agree with gpandzik:

Using the point-and-click tools or using the SAS batch tools or building an own custom solution is not the optimal solution.

Amethyst | Level 16

Agreed. Some time ago, I also built a custom life cycle management system for SAS, but of course it is not the most desirable option.

As far as I can guess or imagine, probably there are many interesting solutions for SAS around the world, trying to fill this gap on the SAS offer for the IT (business!) demand. Also, most probably the real situation is that all of those solutions are: custom, proprietary (Amazon AWS?) and not standardized/centralized by SAS Institute.

I would bet that if many voices raise demanding an specific functionality, SAS Institute will implement in the future an initial approach to it, or purchase an existing one and then centralize it (as some times before).

Is any of those ideas on the wish-list for the next releases? it will have my vote!

Barite | Level 11

I do not agree with a single tool as idea.

The first requirement would be getting into the related artifacts/objects properties.

For the SAS tooling (SDW installation stage and all imbedded third party components as of VMfabic) it is better to stick to RPM Package Manager - Wikipedia, the free encyclopedia as that is the standard tooling for that environment. A more correct folder structure according to common Linux/Unix guidelines should also be done.

At the Microsoftlevel using MSI packages with SCCM  System Center Configuration Manager - Wikipedia, the free encyclopedia supporting bubbles with the related instructions as that is the standard for a Windows desktop environment. There are two of them now with 9.4, but guessing they are not complete.

For the java desktop clients a copy deploy is sufficient and with that approach a lot of headaches on Desktop management processes could be avoided.

Not being aligned with processes and tools at the OS level is the issue that should be solved.

For SAS specific configuration there is mess on al kind type of files databases records and relations. The well known tools for release management as docker nolio rational endevor or whatever only are applicable to OS file types that are promotable not the ones that are unique to an dedicated environment.

Within the SAS metadata based there are objects artifacts that are part of the security management (not promotable). Ones with dedicated names to an machine or local physical names or ... )all not promotable) . Than some type should be promoted (defined for release management) others not (eg ad-hoc). To solve this a well defined metadatafolder structure should be in place.

This misalignment is the one causing all trouble when going for a -AAS approach.

The way of configuration (appservers, themes etc)  could be improved by sas.

That well defined folderstructure getting it architecture is the real work.  No the work is not the tooling to manage those.  When this is the case I am convinced that is signal that folder (metadata) architecture has failed. Solving that should be done not finding new tools too hide that failure/mistake.

The whole metadata approach is nice but complicated. I realize it is the same approach as the IDD with IDMS a long time ago. It was difficult to get used with that for me, by now I am used to those concepts may be a unique situation. All the questions on "which version?" are also confusing. The origin is release management and not version management.

By the way reviewing docker is an alternative on the virtual machines. An applicaton in that context are the tools like an Oracle DBMS that is what UNix nerds are indicating as the "application". That part however is infrastructure to the business. Just having a RDBMS is not giving you anything at the businesss level. 

---->-- ja karman --<-----

suga badge.PNGThe SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment. 

Join SUGA 

CLI in SAS Viya

Learn how to install the SAS Viya CLI and a few commands you may find useful in this video by SAS’ Darrell Barton.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 5 replies
  • 4 in conversation