Skip to content

my interpretation of a policy-document defining a state#8

Closed
gaelcolas wants to merge 3 commits intoPowerShell:mainfrom
gaelcolas:gael/winget_config
Closed

my interpretation of a policy-document defining a state#8
gaelcolas wants to merge 3 commits intoPowerShell:mainfrom
gaelcolas:gael/winget_config

Conversation

@gaelcolas
Copy link
Collaborator

Example of what a configuration doc may look like authored by end user or through a tool (compilation) to be used by an utility.
I don't like to call the utility "orchestrator" because you can orchestrate at many levels (i.e. orchestrating the change from a desired state to another desired state).

I refer to the Utility for a simple tool that tries to apply a resource at a time, or agent (sometimes interchangeably) although an agent would have some more cleverness to refresh the desired state policy document, and how/when to converge to the desired state.

This approach (in contrast with the other proposal), tries to minimise the features/complexity needed when converging to the DesiredState, and push them back to a higher level (called AgentContext here).

We're enabling Parameters to be defined in the configuration and re-used as needed.

We uniquely identify each resource instances with an instance ID that has to be unique.
We're using this string to identify the resource to use (namespace\resource), but if we want it to be free text, each resource instance will have to refer to detailed resource defintion (as listed in dependencies).

$schema: https://json-schema.org/draft/2020-12/schema
$id: https://aka.ms/schemas/dsc/manifest.schema.yaml #manifest is too generic, that's configuration policy

AgentContext: # Reserved for the "managing context or config before converging to the desired state". Could be a different file!
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe include a timeOut property? or maxRunTime?

Copy link
Collaborator Author

@gaelcolas gaelcolas Feb 6, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I understand it, @SteveL-MSFT was focusing on the "config" utility that only enacts resource per resource...
So in this approach of having a separate "layer" of configuration for the agent/orchestrator, the AgentContext key is there mostly for illustration, as we don't need to agree on that part yet.
I agree with you it would be nice, but I don't think that's necessarily the config utility's job.

# postchecks:
assertBeforeRun:
# assertions: # every assertion should pass before any config is applied and calls `test` method, multiple resources can be here and if any fail, the entire config fails
- resource: assert-osversion # naming convention for assert resources
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

are these resources special in some way or just a typicaly DSC resource, and only Test is run?

assertBeforeRun:
# assertions: # every assertion should pass before any config is applied and calls `test` method, multiple resources can be here and if any fail, the entire config fails
- resource: assert-osversion # naming convention for assert resources
settings:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If typical DSC resources, these Settings could be just DSC properties



ResourceGraph: # this is the Directed Acyclic Graph of the resources drawing the path of states (nodes) or changes (edges) a system need to go through to converge towards the desired state
- resource_instance_id: '[Microsoft.PowerShell.OSResourcesDsc\osversion]MyInstanceOfOsversion' # unique identifier of the instance, composed at "compile" time.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what would Set look like for an OSVersion resource?

resource_parameters:
id: Microsoft.VisualStudioCode
version: "[1.27.2-*)"
runas: Admin # this will require to be more complex objects, which means the interface for this object has to be defined...
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Possibly links to a session configuration?

@mgreenegit
Copy link
Member

there are a lot of great ideas represented throughout the file. is there any prior art from 3rd parties we will need to consider?

@gaelcolas
Copy link
Collaborator Author

gaelcolas commented Feb 6, 2023

there are a lot of great ideas represented throughout the file. is there any prior art from 3rd parties we will need to consider?

I did not go through previous art as the approach is already opinionated from the outset, and I don't have the time.
From the top of my head, I can't think of another solution that use a serialised graph as the driver for the automation (I think it's great, but well-integrated solution probably wouldn't expose that anyway).
I also don't see much user-specific scenarios, at least not compatible with the Windows model (most of the tools were born for other things).
To me, that's one of the biggest gap customers complained about with DSC, but that introduce the challenge of "user data", how to store and manage it.
At a low level, that's simple enough (cache graph-parameters including user inputs for a resource graph the first time it asked for it). High level tools will have to handle data stores, central store, overrides, priorities, merge behaviour and so on...

It's still good to have in mind how the task oriented Ansible playbook are expressed.
Remember how Chef's databag are referenced in recipes.
How facts can be used in Puppet...

Then draw the line what comes prior the configuration document, and what is runtime parameter.
How can the author of the configuration constrain the runtime information, and offer the tool to get that info from the user...
Then how that info is managed for the first and subsequent runs...

@gaelcolas gaelcolas mentioned this pull request Feb 14, 2023
@SteveL-MSFT
Copy link
Member

Closing as we're currently aligning with ARM template syntax

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants