RFC - Extract DSC from Existing Environments #147
Conversation
NikCharlebois
changed the title
The RFC instructions are saying to put it in Draft_Accepted.....but that seems wrong
|
FYI - The Office365DSC team is implementing this 4th function in their DSC module as a Proof of Concept to prove the feasibility and utility. |
|
|
||
| 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. |
There was a problem hiding this comment.
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).
|
|
||
| * 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 |
There was a problem hiding this comment.
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".
|
|
||
| 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 |
There was a problem hiding this comment.
This should be explained a bit more in the RFC. Looking at reverseDSC, I don't know what I should be looking for.
| 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 | ||
| * 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. |
There was a problem hiding this comment.
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.
| * 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. | ||
|
|
||
| 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) |
There was a problem hiding this comment.
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
|
Hey @NikCharlebois, sorry for the late reply, this is obviously an old one. As @gaelcolas noted, I'm not sure there's enough here to understand why ReverseDSC wasn't an adequate solution for what you're proposing. I'm also personally having trouble with the fact that it sounds like a lot of magic that may or may not work in real world cases. Could you update on us on how that proof-of-concept went, and whether it ever got published anywhere? Experimental/prototype implementations help immensely for us to understand whether the concept may be successful in the long-run. |
|
For housekeeping, we're going to close this one. Feel free to resubmit it with the above questions addressed if you're still interested in pursuing it. However, I think that innovating and proving the scenario out in the |
Associated with Issue #146