Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

File resource as part of base package #567

Open
SteveL-MSFT opened this issue Oct 5, 2024 · 2 comments
Open

File resource as part of base package #567

SteveL-MSFT opened this issue Oct 5, 2024 · 2 comments
Labels
Milestone

Comments

@SteveL-MSFT
Copy link
Member

Summary of the new feature / enhancement

Need a cross-platform file resource. Probably base it initially on the built-in file resource that is part of DSCv1.

Proposed technical implementation details (optional)

No response

@SteveL-MSFT SteveL-MSFT added Issue-Enhancement The issue is a feature or idea Needs Triage labels Oct 5, 2024
@SteveL-MSFT SteveL-MSFT added this to the Post-3.0 milestone Oct 5, 2024
@michaeltlombardi
Copy link
Collaborator

What properties are we expecting of the initial release of the File resource?

For reference and prior art, see:

One thing to note is that while you could use a single resource to control file existence, contents, permissions, and link type for Windows and not-Windows, everything but existence and contents gets messy quickly when trying to represent things with a single resource.

Puppet handles this with providers and converting unix-isms to Windows, advising users to add a separate ACL resource to manage permissions more idiomatically for Windows if needed. Chef uses similar behavior, having users define the file resource and apply cumulative rights to it for Windows. Ansible has separate modules for Windows files and related resources (template files, copying, etc). While the salt state works on Windows, any unix file system specific options are ignored or not supported on Windows, and Salt has a separate win_file for managing permissions.

I would recommend either following the Puppet/Chef model (assume Unix, translate unix options to Windows in a standardized, documented way, and advise using a separate ACL resource for more control) or the Ansible model (one resource for unix files and another for Windows, fully separated idiosyncracies).

The benefit of the one file resource + Windows permissions is that you're always using a single resource type for files regardless of OS, though you may conditionally need to add ACLs for Windows (having a group depend on the OSInfo assertion). On the other hand, it's more complex to implement (not necessarily maintain, as the APIs for files aren't exactly high-churn for changes and features).

The benefit of two resources is primarily simplicity of implementation and declaration, though they can make manifests fork a bit when managing Windows/not-Windows simultaneously. On the other hand, for servers, I don't think that's as common an issue, as servers tend to be more focused in their configuration needs than client devices.

@SteveL-MSFT
Copy link
Member Author

I think this is where @theJasonHelmick should author a spec to define the requirements and scenarios/use-cases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants