-
Notifications
You must be signed in to change notification settings - Fork 224
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
SqlServerRole: Conflict in Composite Resources #1002
Comments
Just to make sure we validate this, I updated one of the examples for SqlServerRole to have to server roles in the same configuration, and that works. See configuration here: And compiled successfully here: |
The error message you are receiving feels like you trying to update the same server role, for example 'securityadmin', in both composite resources. The two resource configurations you submitted above should work together without a problem, since they update two different server roles they should not conflict, just as the example in my previous comment. |
By design (of Desired State Configuration) you will not be able to use the same key properties for the same resource in the same (compiled) configuration. If that was possible it would become a ping-pong behavior on each run. |
Hi! Thanks for the feedback. Sorry for the typo mistake. Both composites are updating securityadmin role. I fixed it in the text. |
Just thinking about the SqlServerRole design. Current state make sense if you specify fix memebers otherwise as you said it will do ping pong in case of multiple different configurations. But in my case i’m using includeMembers and in this case i should be able to use the resource multiple times. |
It is not possible to use a property as key if that property takes a array of strings. So we can’t make IncludeMembers a key. Making the IncludeMembers just take a single user is not an option I see either. I don’t think it is possible to do what you are asking for. I think you have to re-evaluate how you use the resource. |
Thanks Johan, understand. Would suggest to keep this issue in mind when creating such nice DSCResources like this one so we can be flexible as much as we can. Many thanks again! |
Yes I'm sure we will. And thanks for submitting this issue, it was a good discussion! Sadly we are limited to what DSC/LCM is capable of today. Partial configurations and composite resource are powerful but at the end it's limited of the final compiled configuration which has it's limitations. But I bet that will improve in the future.. Closing this as I don't see us being able to change the design of SqlServerRole to handle this scenario. |
I'm going to suggest a potential solution that I really hate... The
|
I don't like that suggestion either. 😄 I rather then that we make a new resource beside the current one, that "pivots the parameters" and uses the concept as the resource SqlDatabaseRole. That is, single user parameter as key and a required parameter for which roles (one or more) to add or remove the user from. Ensure parameter is set to 'Present' och 'Absent' depending if the user should be added or removed from the group. This resource would not create new server roles.
One problem that can occur if the same configuration has both SqlServerRole and SqlServerRoleMember and both sets memebers. Then we would get a ping pong behavior in some scenarios. Update: Updated the order of the parameters, so they begin with keys, and follows by required and write. |
Thinking out loud here.... If the SqlServerRoleMember resource is created, then SqlServerRole could become a composite resource that consumes SqlServerRoleMember for defining role members. I have zero experience with composite resources at this point, so I don't know if that's a good idea or not. |
I'm not seeing any of the two resource being a composite resource, but both should be normal mof resources. Both resource has different behavior, but both will end upp adding members to a server role. Simple mockup:
@schwaizi can use either or both in their own composite resources, where the new resource would solve the problem they having with their composite resources. A composite resource is basically a bunch of resources in a configuration, and that configuration is made to be seen as a resource which can be used as a resource in a second configuration. See http://duffney.io/UsingDscCompositeResources which is a good source for this. I'm a making sense? Or is it a totalyl bad idea? 😄 |
You're making sense, however I think we will have duplicated code. The use of helper functions will help to reduce that though. |
Yes, helper functions would be needed to not having duplicated code. |
@schwaizi What are your thoughts? |
Hi @johlju. Thanks to you for taking time with this issue. I think your proposal SqlServerRoleMember will work pretty well! I would suggest to add ServerName as Key property as well to minimize conflict in case of two role configuration with the same instance name (just thinking possible scenarios). More unique is better. I remember in one of my custom made mof resources i created dummy key to avoid this conflict, but it was dirty and quick solution. I believe your option is much cleaner and also minimize the risk of ping-pong config or conflict between configs. But still there is possibility if someone is using same account in two composites will conflict as well.
But using unique groups like i have may be option to avoid it. So a pretty good solution you proposed! |
Can't think of a reason why Is there a scenarion you see where
|
I'm not following you here. Could you explain in more detail what you mean? |
Labeling this as a resource proposal and help wanted so that someone can take a look at it and send in a PR. |
Hi @johlju, i know scenarios where in DEV Stage are all and multiple Application placed on one server and the same instance. Those application are then split in production servers on separate nodes. So you can have scenario with one login on one server in multiple Composites/Resources:
And in Production Stage it will look like this:
As i said, using Groups can be a solution for the DEV Stage
And ServerName as key because of you can have multiple Resources with the same group on different servers like in Production Stage example above. |
Do you mean that in your scenario the application server configures both the SQL Server target nodes? I would target the the SQL Server nodes by them self. I think you should split these up so the final configuration does only contain the configuration for that specific target node. So I would have changed the above configuration so it target each servers individually, like this. Final configuration for SQLPROD1
Final configuration for SQLPROD2
|
Hi, sorry for late response. |
I think I'm following you know. Using the proposed new resource SqlServerRoleMember, the |
Hi again. I agree it will do the job as you described. Production > using different instances i can add the SqlServerRoleMember resource twice You doing a pretty good job here! Many thanks! |
Hi, i have two Composite resources, each with own members in specific SQL role (securityadmin) and those two composites are used in one parent configuration document.
Unfortunately it is not possible to have two composites with SqlServerRole config. See the error message below.
Composite_A
Composite_B
Error:
The only way how it is possible right now is to move the config in parent Configuration document.
This solution is making the configuration chaotic.
Possible Solution:
Please change the key properties so we can separate those configuration in composite resources
System / Module Info
The text was updated successfully, but these errors were encountered: