Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Discussion: BREAKING CHANGE: Host and instance parameter is not consistent throughout the module #308
Details of the scenario you try and problem that is occurring:
I suggest we try to come to an agreement to which names we are gonna use and add that to the contribution guidelines so we can be more consistent in the future.
I would also want to discuss what you think about trying to make all of these consistent. Is that unnecessary? (it would be a module size breaking change)
I compiled a list of each module. Some are missing both parameters and some are missing either parameter. For this discussion I assume they do need them. Those resource that do not need either parameter, those are removed from the total sum.
Below is a list for each module (includes changes that will merge eventually). But to summarize.
The unique host parameters (order by most to fewest):
Question 1: The name
The unique instance parameters (order by most to fewest):
Question 2: The name
Compiled list for all resources
The DSC configuration that is using the resource (as detailed as possible):
Version of the Operating System, SQL Server and PowerShell the DSC Target Node is running:
Version of the DSC module you're using, or 'dev' if you're using current dev branch:
xSQLAliasServer -> I think we can add SQLServer and SQLInstanceName and concatenate these parameters in resource.
referenced this issue
Apr 10, 2017
@luigilink What do you mean by concatenate the parameters in xSQLServerAlias? xSQLServerAlias does not connect to any SQL Server, it only changes the registry on the host it runs on. It do have a ServerName parameter, but it is what the remote server is that is set in the registry.
I really think we should make SQLServer (the Host) parameter non-mandatory (see issue #319). I think then we should have $env:COMPUTERNAME as default value for SQLServer (the Host) parameter.
Any votes for the name of the parameter for the host name?
For the host name parameter, I personally don't think host name parameter name
Options (please add more options if there are any):
I'm kind of divided between ServerName, ComputerName and HostName. But I personally think ServerName is best suited. But I go with whatever the majority of the community likes.
I tend to like HostName because of connecting to Failover Cluster Instances. However, NodeName seems to line up better with the DSC configurations defining nodes. I'm with @johlju on this one, I could go with ServerName, NodeName, or HostName.
I'm wondering if the host name parameter is even needed since the node configuration already knows which host the instance is on. The only exception is when connecting to a Failover Cluster Instance, however, this could potentially be dynamically determined. I'm thinking out loud on this one, so be gentle
I could go with NodeName. I started using that when I created resource when I started out with DSC because it was a term used by DSC. But I tend to like ServerName because I think that is how you think of it from an SQL perspective, I do like HostName also, because it's a term used with DNS.
I think host names is needed when using AG groups, please see this issue #319.