In September 2017 we communicated some of our plans for PowerShell Desired State Configuration (DSC). Over the past few months, we have been executing on these plans and collecting feedback from customers and partners. The intent of this blog is to provide an update on the plans we shared back in September. I will have additional posts in the near future to discuss updates for Azure DSC Extension and Windows Pull Server.
Specifically:
- What is the relationship between the next version of DSC and PowerShell Core?
- Will DSC be Open Source?
- What does this mean for my skillset and my existing projects?
We appreciate the continued feedback and look forward to working with the DSC community to make incremental improvements as we progress together.
What Are We Trying to Achieve?
The mission for DSC is to provide a platform for server configuration management that is maintained together with the community, releasing at an agile cadence, to meet the demands of hybrid cloud environments.
Local Configuration Manager (LCM)
LCM is the engine that runs DSC so it is a logical place for us to start work on a new version. For DSC in Windows, this shipped in Windows Server 2012 R2 and later and has been updated through the WMF release cycle.
The work going on by the DSC team since the last major update has been focused on making LCM a small, lightweight, cross-platform, and portable engine that can meet the requirements for cloud management capabilities long term. In fact, the new codebase is already in use by some of the Management services available in Azure such as Inventory and Change Tracking, and is scaling to hundreds of thousands of servers.
The team’s plan is to make LCM an open source project in GitHub within the next 12 months. We want to make sure we are prepared when we reach that milestone. Our team has gained experience through management of many open source projects including the DSC Resource community and from shipping PowerShell Core as an open source language. We understand that the onramp to open source projects includes a complex set of requirements, so we can be respectful and responsive to community contributions. We are working through creation of the repository with the appropriate assets such as governance and documentation. I will have more to share in a few months at the PowerShell Summit events happening around the world.
Initially, the new LCM would be distributed as compiled binaries via GitHub releases and through Azure Services. It will need to be installed on systems where the current DSC platform exists today, and we will need to offer conflict detection across versions.
To be crystal clear, we do not plan for LCM to require .NET, .NET Core, or PowerShell Core. The project is written in C++ and will be able to be compiled for multiple platforms.
Provider Model
The community has been providing valuable feedback regarding backward compatibility with existing DSC Resources. To deliver DSC provided by LCM, we anticipate a provider model with the ability to work with multiple languages.
To make sure we are not creating unnecessary work for community maintainers, the first implementation of the provider model for LCM will be Windows PowerShell. This means that in the future a new open source LCM would be able to manage configurations that include the existing community-maintained DSC Resources authored using Windows PowerShell. Our intention is that no changes to the resources will be required.
We also expect to have LCM providers for PowerShell Core, C++, and Python. These providers will introduce the ability to Get/Set/Test across Windows, Linux, and MacOS, by a common LCM. Leveraging cross-platform languages, authors will have the opportunity to create DSC resources that can be used on multiple operating systems. For resources written in PowerShell Core, there are built-in Boolean variables $IsWindows, $IsLinux, and $IsMacOS that will simplify OS detection for resource authors.
Feature Backlog
The feedback in User Voice will not be lost as we transition to the new project. Examples of top requests include support for maintenance windows, intermediate state, sharing information between resources, and support for managed service accounts. These will be moved to GitHub to be the top items in the new DSC project and we will carry forward any existing work in these areas.
What is The Impact?
By following a provider model that can leverage Windows PowerShell and multiple other languages, we honor our commitment to existing versions of Windows, while introducing new choices such as the latest versions of PowerShell. The development of your skillset around DSC and the investment you have made in custom resources will carry forward, while enabling more agility to releasing incremental updates and the features you have requested.
Feedback
We look forward to hearing your feedback and suggestions. Please leave blog comments here, or via Twitter using tag #PSDSC. I look forward to more in depth conversation in the DSC forum, PowerShell User Groups, and the community-led PowerShell Summits in 2018.
Michael Greene
@migreene
Principal Program Manager
Microsoft PowerShell DSC and Azure Configuration Management