You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello,
I'm excited to see the next milestone release and a working NuGet install package. Is there any plan for this next release? Aspirational plans are good too :)
A big hats off to those contributing to this project -- I believe it solves a lot of issues that prevent PowerShell DSC from working in an enterprise environment.
@bbollard -- I'm finally getting some spare cycles to devote more time to this project again, so I'll be resuming work on this again, and the situation with .NET Core and PS Core has become a lot more stable so the dependencies on those components can finally be resolved.
I'll be looking for input on installation and usability, so any feedback or contributions you can provide will be much appreciated.
The main story around distribution and installation will focus around PowerShell Gallery, as I think that's a great platform that is underutilized in the PS community and solves lots of problems.
My interest in Tug is more about the DSC compatible endpoint than the PowerShell "DSC Manager". Thanks to your plug-able architecture, I was able to easily build a POC provider that leverages a No-SQL document database to store modules, configurations, and node status. If I add in some caching it should easily scale to support my large environment.
We just submitted our first open source contribution to another project (Boxstarter). Our contribution process is brand new and there are kinks to work out so perhaps there may be some opportunities to contribute once we streamline the contribution process.
Now that PowerShellGet has great support for web proxies (yes, we have those) using the PowerShell Gallery is feasible,
We are using CouchBase as our NoSQL document store. For the POC, we implemented several document types, many of which map directly to PowerShell DSC artifacts including : DscAgent (registered agent information), DscConfiguration (the serialized MOF file of the configuration), DscModule (serialized custom module, in this case xPSDesiredStateConfiguration version 6.4.0.0, DscReport (the compliance report sent by the LCM Client), and a custom document I call DscNodeStatus which gives the current status (based on the last compliance report received) of the node. DscNodeStatus may be combined into the DscAgent document as we move forward from POC to implementation.
In a nutshell, everything is saved within CouchBase so the Tug service endpoint is completely stateless to enable easy scaling behind a load balancer. Besides having to comment out the VeryStrictInputFilter (see my other issue for for more information) validation, everything is working well.
We chose a NoSQL solution mainly due to the ability to handle documents without a strict schema with the DSC "compliance report" being a good example. We are aware of some JSON data handling capabilities of newer versions of Microsoft SQL Server but we did not investigate them.
Activity
ebekker commentedon Oct 26, 2017
@bbollard -- I'm finally getting some spare cycles to devote more time to this project again, so I'll be resuming work on this again, and the situation with .NET Core and PS Core has become a lot more stable so the dependencies on those components can finally be resolved.
I'll be looking for input on installation and usability, so any feedback or contributions you can provide will be much appreciated.
The main story around distribution and installation will focus around PowerShell Gallery, as I think that's a great platform that is underutilized in the PS community and solves lots of problems.
bbollard commentedon Oct 27, 2017
My interest in Tug is more about the DSC compatible endpoint than the PowerShell "DSC Manager". Thanks to your plug-able architecture, I was able to easily build a POC provider that leverages a No-SQL document database to store modules, configurations, and node status. If I add in some caching it should easily scale to support my large environment.
We just submitted our first open source contribution to another project (Boxstarter). Our contribution process is brand new and there are kinks to work out so perhaps there may be some opportunities to contribute once we streamline the contribution process.
Now that PowerShellGet has great support for web proxies (yes, we have those) using the PowerShell Gallery is feasible,
ebekker commentedon Oct 27, 2017
Interesting, can you share any more details about what NoSQL doc store you are experimenting with?
bbollard commentedon Nov 27, 2017
We are using CouchBase as our NoSQL document store. For the POC, we implemented several document types, many of which map directly to PowerShell DSC artifacts including : DscAgent (registered agent information), DscConfiguration (the serialized MOF file of the configuration), DscModule (serialized custom module, in this case xPSDesiredStateConfiguration version 6.4.0.0, DscReport (the compliance report sent by the LCM Client), and a custom document I call DscNodeStatus which gives the current status (based on the last compliance report received) of the node. DscNodeStatus may be combined into the DscAgent document as we move forward from POC to implementation.
In a nutshell, everything is saved within CouchBase so the Tug service endpoint is completely stateless to enable easy scaling behind a load balancer. Besides having to comment out the VeryStrictInputFilter (see my other issue for for more information) validation, everything is working well.
We chose a NoSQL solution mainly due to the ability to handle documents without a strict schema with the DSC "compliance report" being a good example. We are aware of some JSON data handling capabilities of newer versions of Microsoft SQL Server but we did not investigate them.