Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC - Extract DSC from Existing Environments #147

Closed
wants to merge 4 commits into from
Closed

RFC - Extract DSC from Existing Environments #147

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
4733235
Initial Draft
NikCharlebois Oct 31, 2018
217b58c
Moved to Draft_Accepted
NikCharlebois Oct 31, 2018
f2f1806
Moved back to Draft...I guess
NikCharlebois Oct 31, 2018
30d37dd
Updated Template
NikCharlebois Nov 1, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
39 changes: 39 additions & 0 deletions 1-Draft/RFCNNNN-Extract DSC from Existing Environments
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,39 @@
--
RFC: RFC00xx
Author: Nik Charlebois
Status: Draft
SupercededBy: N/A
Version: 0.0
Area: DSC
Comments Due: December 1st
Plan to implement: Yes

---

# Reverse Engineering Existing Environment into DSC

Users have been complaining about the learning curve to get started with DSC and about the amount of work it takes for them to re-write their existing technology investment onto DSC for monitoring purposes. There have been various community projects to solve this issue by extracting DSC configurations out of existing environments, such as ReverseDSC, which had incredible success with clients wanting to adopt Configuration as Code practices within their organizations.

The purpose of this RFC is to propose that a fourth method that would retrieve all instances of a resource against an existing environment be included in DSC resources for them to be identified as HQRM.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that if this is to target the HRQM standard, DSC Community would be the place to have this RFC going forward (I know, you wrote that in 2018).


# Motivation

* Reduce amount of work required to on-board existing environments onto DSC
* Reduce learning curve to get started with DSC
* Provide an automated path to migrate on-premises environments onto Azure
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While I do see value in ReverseDSC, I strongly disagree with what should be the "advertised benefit".
Transforming is more important than lift and shift.
Transforming to Infra as code is so much more than convert existing config into a DSC configuration script.
The value in the transformation is to refactor using more solid principle, IaC should be built for change (to improve change capacity)

So the benefits is greater discoverability, easier learning curve, data extraction to help with the transformation, comparison & documentation...
But we should definitively avoid showing this as "conversion path to Infrastructure as Code".

* Allow users to easily document their environment’s configuration as code
* Quickly compare configuration deltas between two environments

# Specifications

There are three components to the requested solution:
* Component 1 needs to iterate through all instances of the current resource and provide the Get-TargetResource function the key parameters for it to be able to retrieve all other parameters associated with this resource instance.
* Component 2 needs to retrieve the Hash tables received back from the Get-TargetResource and convert them into a DSC string. This is already automated and handled by the existing ReverseDSC Core module https://github.com/microsoft/reversedsc
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be explained a bit more in the RFC. Looking at reverseDSC, I don't know what I should be looking for.

* Component 3 needs to orchestrate the calls to the resources’ Component 1 and 2 and collect the results into a resulting file, which will be a DSC script that can be used to replicate the environment.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think the resulting file should be a DSC script. It should probably be an object that a function exposed by the ReverseDsc module could convert to a DSC Configuration script.
The point is that people should avoid writing Configuration Scripts and rather write Composite configurations and compose them.
The data extracted is the real value, the way to use it should be flexible but not bound to the DSC resource.
For this feature to be useful, we need to think about other Configuration Management solutions to consume it.
Chef, Puppet, Ansible and so on could benefit to use ReverseDSC to extract the data, but would translate it into their own DSL.


The vision is as follow:
Component 1 and 2 would be combined into a new fourth function required by every HQRM, call it Export-TargetResource. Component 3 would be a global utility module, contained within the DSC module, which would orchestrate all the calls to the module’s Export-TargetResource methods (see SharePointDSC.Reverse at https://github.com/microsoft/sharepointdsc.reverse for a reference)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Although Component 1 and 2 sounds doable, it would be good to have clarification, details and examples within this RFC.

I'm not sure I fully understand the following:

would be a global utility module, contained within the DSC module


## Alternate Proposals and Considerations

N/A