AADSC: Composite Resource Reporting

This topic contains 8 replies, has 3 voices, and was last updated by  Will Anderson 2 months ago.

  • Author
    Posts
  • #96449

    Gert Humphris
    Participant

    Hi Guys

    New here and this site seems to be the best resource on Powershell DSC.

    We are currently in the process of creating cloud tooling for our software packages. We are busy testing Azure DSC and written quite a bit of Composite resources.

    The problem is that Composite resources are not really reported on at all. The only thing you can really see is the physical resources that the Composite used.

    For example I would have a composite resource that calls the file and xSmbShare resources and all that would be reported on is those specific resources.
    If you then click on the resource it give you this: PackageFolder::[cPackageTestResc and the details page would give you version details of the xSmbShare module.

    Is there a way to have the Composite Resource report more details into Azure, or if this is not possible can you write a normal DSC resource that makes use of other DSC resources?

  • #96452

    Will Anderson
    Keymaster

    Hi there Gert,

    I'm trying to visualize how you'd like to see this reporting. Are you saying that you'd like the top level report to separate the resources by composite? Something like:

    [Composite1]
    – xSMBshare::ProviderName
    – xService::ProviderName
    [Composite2]
    – xFirewall::ProviderName

    etc?

  • #96455

    Will Anderson
    Keymaster

    Also, there's the Export-AzureRmAutomationDscNodeReportContent command that allows you to get the raw content of reporting. It's not the best, as it downloads a txt file to your present working directory or specified path. And you also have to do your own manipulation to make it readable, but you can get the granular reporting from there.

    Example:

    Export-AzureRmAutomationDscNodeReportContent -NodeId $NodeReport.NodeId -ReportId $NodeReport.Id -ResourceGroupName $NodeReport.ResourceGroupName -AutomationAccountName $NodeReport.AutomationAccountName

  • #96459

    Gert Humphris
    Participant

    Hi Will

    Thanks you for the quick response.

    I think your First post is a good start but also if I can list maybe the Composite version number etc.

    Thanks I will look at your command but it needs to be GUI driven from our Azure Portal at least so our consultants and customer can see what version of the composite module is running for example.

  • #96531

    Will Anderson
    Keymaster

    TL;DR – this isn't actually AADSC's fault.

    I'm going to reach out for verification on this, because this is based on my observations.

    First off, the raw reporting you get from AADSC is based on the reporting output from the DSC LCM on the local machine. If you were to look through how the LCM processes this, it doesn't output the version of the composite resource either. This is because even though you are uploading the configuration as a module, it's not really.

    When DSC (regardless if it's the AADSC node or a push server) compiles the configuration, the composites are compiled into the same singular MOF. Really all it is when you composite a configuration is just saying (I want to add these other configs here) and it does so like one big configuration.

    Now, you do get reference points in the logging for composites, if you look in the logging, you'll see a reference to the source composite config, but as you pointed out, no module versioning.

    With that being said, I don't think the current LCM would be able to support what you're looking for without major design changes. But, you can validate your composite versioning simply by looking at the stored composite in your modules directory. Since Azure Automation doesn't yet (if it ever will) support side-by-side versioning, you only have that one version that you're config is going off of.

    If you really feel strongly about this being a requirement, you might be able to put in a User Voice to Microsoft regarding the issue.

  • #96548

    Michael Greene
    Participant

    This is great feedback. Our engineering team will review it today. I don't have any estimation for what it will take to deliver but if we can make it happen, we should.

    Thank you very much for calling this out,
    Michael Greene
    Principal Program Manager
    Azure State Configuration and DSC

  • #96572

    Gert Humphris
    Participant

    Thanks guys for the prompt feedback. Will especially for the detailed feedback on the LCM, also I wasn't aware that AZDSC doesn't support side by side versioning of Modules.

    I might create another discussion with detailed info on what we are trying to do as I think quite a few people can benefit from it trying to do Configuration Management with DSC.

    • #96573

      Will Anderson
      Keymaster

      Anytime! I'd be interested to hear it. I'm doing some pretty wild stuff with it as well. Sharing use cases is always fun. ^_^

You must be logged in to reply to this topic.