dsccommunity / WebAdministrationDsc

This module contains DSC resources for deploying and configuring web servers and related components.
MIT License
160 stars 147 forks source link

WebApplication: Physical path overwritten after desired state applied #587

Open spriet2000 opened 3 years ago

spriet2000 commented 3 years ago

Hello,

I am setting up a webserver with some applications using dsc and the first run works. All apps and settings are correct setup. The physical path is pointing to a default directory.

The physical path is pointing to a default directory, because an automated deployment process runs after the initial dsc run and sets the correct physical path.

The automated deployment process will set the physical path to a new folder after each deployment. Deployments are organised by another team.

The problem for me starts when I want to run the dsc script again to update something on the node. All the physical paths are set back to default directory which breaks the application.

How can this behavior be prevented? Could you give me some advice?

johlju commented 3 years ago

You should not have the PhysicalPath as part of the configuration if you do not want to enforce that property.

spriet2000 commented 3 years ago

Thanks for your reply. I have tried that option and it seems that physical path for xWebApplication is a required property.

spriet2000 commented 3 years ago

If its a good idea to make physical path optional, I could spend some time on it and try to create a pull request. But why is it optional for a website and not for an application? Does it have a good reason? Tried before?

renebrandnewday commented 1 year ago

Is there any news here?

johlju commented 1 year ago

The parameter PhysicalPath could be made optional. Then logic need to be added that verifies that it is set when a web application should be created as it probably a necessary value for creation (?), but is should not be a mandatory parameter if there is an existing web application where one do not want to enforce the property PhysicalPath.

Community need to update logic in resource, update unit test and creat necessary integration tests. 🙂 Happy to review a PR.

renebrandnewday commented 1 year ago

Thanks for answering. I could get some pointers before actually building this.

When creating a website/app, its required. When updating for example the app pool it is not.
Are there other DSC examples which work like this and could be used as an example?

Alternative:

A property could be added to the Website/WebApplication to set the behavior. For example: SetPhysicalPath = $false.

My current solution is to retrieve all the physical paths first from a target node and write them in the DSC file before executing: It's too complicated, error prone and difficult to explain to my co-workers.

Are there preferences how to do this?

johlju commented 1 year ago

Are there other DSC examples which work like this...

The normal behaviour for a DSC resource is only to enforce the properties that are part of the configuration. Due to that the property PhysicalPath is mandatory all configurations must set it regardless if it should be enforced or not. Since your configuration must set the property, even thought you do not want to enforce it, you get the issue that PhysicalPath is overwritten with the wrong value. By removing that the parameter is mandatory, since there are scenarios where a configuration does not ant to enforce it, we solve that problem. This assumes that your configuration never create the actual object that depends on PysicalPath. Because if a configuration should create the object then we want to enforce the property, because then you say that there should always be a object with the pysical path 'X', and no other pysical path.

A property could be added to the Website/WebApplication to set the behavior. For example: SetPhysicalPath = $false.

You mean we could add the boolean parameter OnlyUsePhysicalPathOnCreate. Not sure that is the right way to go since we do want to enforce it if it is part of the configuration, though I have seen resources implement such a way, but only for mandatory parameter, and in this case we do not need to have it mandatory. But if the community likes the idea, sure. :slightly_smiling_face: