Permalink
Find file
e0ee2ff Dec 30, 2016
67 lines (60 sloc) 4.6 KB

Brainstorming

This is a place to capture random thoughts and ideas. If/when these start to get developed, they should be moved to a ticket where they can be discussed, defined and designed.

  • Tug Server CLI - make use of a combination of CommandLineUtils and/or Configuration.CommandLine to support a few different modes of operation and altering operational behavior:

    • Mode(s) to describe/validate configuration file - we would need to propery attributes/tagging to config model to support self-describing documenation and validation
      • e.g. Tug.Server config-help -> print out documentation on configurable settings and terminate
      • e.g. Tug.Server config-check -> validate the current config settings files/env/cli-args and terminate
    • Mode(s) to explore available providers and their details:
      • e.g. Tug.Server list-handlers -> lists out the discovered DSC Handler providers and exists
      • e.g. Tug.Server list-auth -> lists out the discovered authentication/authorization providers and exists
      • e.g. Tug.Server show-handler <handler-name> -> print out details (labels, description, platforms, etc) and parameter details (names, optionality, data types, value enums)
  • Continuous Integration (CI)

  • Tug Client - Moved to https://github.com/PowerShellOrg/tug/issues/25

  • MOF Parser - this is more of a "nice to have" idea:

    • if we were able to parse MOF files, we could extract all the referenced DSC Resource modules which could be used by the client to support better test automation, i.e. fetch a Configuration, parse it and fetch all the modules referenced within
    • on the server side -- this could be used by a handler to parse any configurations that are stored within, for example, when they are uploaded or upon startup, and could be used to do any number of things, such as:
      • pre-fetch the DSC Resource modules so they are available to nodes if needed
      • determine if the modules pass some set of validations (i.e. blacklisting modules or allowing only known, tested modules)
      • simply validating the MOF is a valid file
    • The latest MOF Specification can be found on the DMTF site for the CIM standard.
    • Looks like the most recent, or perhaps prerelease versions of ANTLR already have support for .NET Standard
  • Alerting - another possible "nice to have" idea: Could be some opportunity for generating alerts on server-side such as when an unexpected exception is encountered (discovered a few 500 errors in the default xDscWebService under some test scenarios using the Tug.Client) or when a node has fallen out of compliance for some length of time, or some other conditions. The natural approach would be to define a new extension point (i.e. Provider interface) and throw in a few provider impls like SMTP (MailKit of course ;-)), chatops (Slack, HipChat, etc.) or just plain old WebHooks.