Community Call Comments, Questions, and Feedback (June 30)

[kwirkykat]

This issue is open for the community to submit comments, questions, or feedback from the DSC Resource Kit community call on June 30 1-3PM PT.

The agenda for the call is available on GitHub here.

[ArieHein]

I couldn't attend the call due to previous engagements so ill pitch in some replies:

• Release Cadence - over all I'm pleased with the frequency of releases.
  I have yet to see bug fixes go out when its not the "normal" release cycle. Hope it is just that
  the bug fixes aren't that serious that your just waiting for the "normal" release cycle to add the fixes.

As not all can, or have the time to lurk on GitHub to find the latest builds and fixes in-between
releases, not to mention, some of us follow quite a few projects so its sometimes hard to keep track.
So better messaging that new resources are about to be offered and what's the latest changes is
much needed. I'd like to see it tweeted on the PS team account, a pre-release blog post, a "Notify Me
by Mail" button people can sign up to, either through their MS account or other way. Just more publicly
announcing the new updates.

• HQRM Plans - Happy this is being focused now. Would like to see the ticket i opened about the
  xRegistry being closed :)
  I think the plan is still missing some vital point which is "stress" testing. Unit tests will not show you
  how good it will behave in a high volume of changes \ mass node deployment. Neither will
  PSSScriptAnalyzer unless someone writes pure performance related rules. I think you should have
  Integration tests to test the resources to behave nicely for say 50 items of the same resource
  running against 50 nodes (with slight hardware/OS variations) and average the results.
  Perhaps something along the lines of web-load-stress-testing sort of framework only for PowerShell DSC.

The question about the SharePointDSC having good time and test coverage, while being good
guidelines for quality isn't addressing the point above. The SharePointDSC has 3 registry keys, 2 are
in samples and one active and its only one key change, so its not actually testing the scenario above.
By itself, it could be a good way to measure other complex modules but since all of them are at the
lower level depending on built-in core resources, those have to be HQRM first and then you can really
say that SharePointDSC, for example, is indeed at HQRM level.

Remember that people deploying DSC scripts will not 'just' use the SharePointDSC resource as is, it
will eventually be grouped up with more DSC resources to build a full 'image' of how a certain server
would look like. When that happens and the LCM has to test the big configuration every hour for
example, you'll get issues as were described in powershell.org and in an issue raised on GitHub
sometime ago where LCM check times went from merely seconds to hours when no changes were
implemented when a DSC script that changed 60-80 registry keys was used.

So the list of the 6 steps to update a resource module to HQRM level should have a new entry - Integration\Stress testing

As for the Nano vs Full Server resolving, separating them into different versions is best imho. The
configuration tool should make the decision which package to download and not the package logic. In
the distant future, using the Nano server version will probably be the only option as more roles will be
addressed and filled by Nano to make the rest of the versions not needed and obsolete.
Perhaps its just my wishful thinking :)

SharePointDSC seems to follow most of xWebAdministration, and the xPSDSC isn't that different from what's in xWebAdministration, its just not sorted nicely in a table and missing a part. Dont think its between the three methods, its more combine it all to one.

I would like to see one of the other tickets I've opened being addressed, concerning the need
to "reinstall" my pull servers every time a new xPSDSC resource is released and by that loosing the
information already stored in the internal database. A Method of "upgrade" would be a very helpful
thing to have.

This this will do for now, thanks !

[kilasuit]

Just a few of my thoughts on this

Release Cadence - 6 weekly as a whole rollup is good but individual releases are good when required.

Notification on releases - Twitter & Blogs are good for getting information out there - perhaps some slack integration with the PowerShell Slack Team could also work

Also perhaps a D/L and also emails to the PSMVP D/L on new releases could help get the word spread out there

Production Ready - Good examples that can be used easily with deployments to Hyper-V VM's (Lability Example configs - https://github.com/VirtualEngine/Lability/tree/dev/Examples would be good here as easy to stand up a simple fully fledged lab environment example) / VMWare VM's & Azure ARM Templates

Regarding Naming See my response at PowerShell/PowerShell-RFC#10 but ensure that all DSC Resources are released under the PowerShell Team Company Name - making sure that included MetaData is fully featured is really important for finding right resources for the right scenario as this is then searchable in the PSGallery.

Best Practices - for me I would like there to be less adding of resources that closely mimics an existing resource xSQLServerFirewall where there is already xFirewall that can be used - this reduces possibility of resource clashes in a configuration and this will make cross resource use more accepted and easier understood with better examples as suggested above.

Outside resources - I think there should be an issue in the DSCResource repository that lists possible new resource modules that haven't been already published / developed but could be then made available as a repository in the PowerShell Organisation for community members to be able to work on directly under the MS hood so to speak.

All new repositories in the PowerShell Organisation should be linked up to Appvayor for builds on all Pull Requests & commits across all branches by default

[ArieHein]

Some more points after going over the call video and points:

• Release Cadence + Community calls

Dont link amount of contributions directly to frequency of releases - what happens on "slow" months ? If there are bug fixes but not enough "content" otherwise, release, just call it a minor release in terms of versioning.

Two weeks prior to major release, put the word out, make a call discussing what's going into the next
release. Four weeks after major release, make a call discussing issues with last release and plans for
next one. (this assumes 6 weeks cycle)

For bug fixes or "slow" months, a call might not be needed, just the other means of communication - blogs, community channels (like posting on powershell.org and powershellmagazine.com for example, twitter, mail, slack etc.

Individual resource releases is best, the ability to use that sort of release schedule was one of the many reasons behind splitting them into different repos imho.

• HQRM

Already wrote in #160 about PowerShell best practices usage not implemented.
Adding Performance rules ?

• Class-Based Resources

Soon the OS will stop being supported, if only then work will be done to convert resources to class based, well not benefit for what PowerShell 5 changes. Perhaps start two distinct dev branches one for WMF 4 backward compatibility and one for the new WMF 5 and start porting resources. Will introduce complexity but will also provide choice.

My environment consists only of Win2K12R2 with only WMF 5, why should i then be limited to using WMF 4 based resources ?
(backward compatibility is sometimes too much safeguarded and just gives people the reason not to upgrade or delay it even longer)

• Dependencies in Resource Examples

Real life examples area good progress just re-evaluate all the new examples by say internal MS people or MVPs for example concerning best practices as displayed in those examples.

• How to Help Contributers

Testing is a bit difficult to learn, not because of the lack of tutorials. There are quite a few videos and documentation on the web.
Finding them might be hard(?) but imho, the difficulty stems from knowledge of the person both in understanding what to test and how to test it - to what depth of tests does one needs to go to. As was noted in the call, most of the people dealing with this are Sysadmins, not necessarily programmers. Ive seen score of programmers having difficuly with the idea of writing unit tests on various testing frameworks so its only to be expected that sysadmins face the same "labor pains". Only cure for that is education and self example by prominent figures in the powershell scene.

The other difficulty is becuase we normaly start coding and only then start writing the unit tests when we should be doing the opposite

Ontop of that you have to remember that the first hurdle is actually Github and understanding how to set it up and understand the concepts and then going over all the various guildelines so the contributions actaully fit the standard

Hats down to those that do contribute via PRs as its not an easy thing.