Closed tbalasavage closed 3 years ago
Not sure I have the full picture, but I believe if you update your automation DSC script to indicate the version that you now have, it should eventually reach consistency.
Context: My DSC script doesn't specify a version. I installed the agent and it was version 2.10 (making up the number here). In DevOps I updated the agents and it went to 2.17 (again, made up). This seems to have caused the nodes to become noncompliant.
Is this a correct strategy/summary/plan: Don't rely on the latest version in the DSC script but instead specify a version and update the version in the DSC script when you want to upgrade and NOT in Azure Devops? Or specify a minimum version.
Looking into this though, these are the options:
PARAMETER Name
What's the name of the agent we're concerned with?
.PARAMETER Pool
What's the pool of the agent we're concerned with? Note, only used on install.
.PARAMETER AgentDirectory
What directory is used for agents?
.PARAMETER Account
What VSTS account should we be concerned with?
.PARAMETER AccountCredential
The credential used to auth with VSTS.
.PARAMETER LogonCredential
What credential should the agent service use?
.PARAMETER Ensure
Should we ensure the agent exists or that it doesn't?
It doesn't appear that I can set version. Is that incorrect?
Whoops, you're right. I was thinking of a similar DSC resource for a different tool. You should be able to update via ADO and retain consistency. Perhaps the update removed the agent from the specified AgentDirectory when it updated? Do you have access to the VM to try running the Test-TargetResource cmdlet directly?
It also logs verbose so if you can capture the logs when DSC does a consistency check you may get some more information about why it believes its not consistent.
I'm using Azure Automation with this DSC resource and have build agents that have been updated and the consistency is maintained. I'm updating one right now as well to verify that behavior is still functioning for me.
I've confirmed that the agents were updated (2.1650->2.175.2) and my DSC nodes have tested/reported consistency since the update. We'll need to dig into the details of your setup I think to diagnose what might be going wrong.
If you don't mind providing input, this is my config:
configuration BuildAgentConfig
{
$Pat = Get-AutomationPSCredential 'personalAccessToken'
$Creds = Get-AutomationPSCredential 'userCreds'
Import-Module Orchestrator.AssetManagement.Cmdlets -ErrorAction SilentlyContinue
Import-DscResource -ModuleName 'VSTSAgent'
Node $AllNodes.NodeName
{
xVSTSAgent VSTSAgent {
Name = 'Agent01'
ServerUrl = 'https://dev.azure.com/myorg'
AccountCredential = $Pat
LogonCredential = $Creds
AgentDirectory = 'C:\VSTSAgents'
Work = 'D:\VSTSAgentsWork\Agent01'
Pool = 'Development'
Ensure = 'Present'
}
}
}
I also had the ConfigurationMode set as ApplyAndMonitor. I've since unregistered the node and changed the configuration to ApplyAndAutoCorrect. I'm new to DSC and Azure Automation so this may have been my stupid mistake and I've wasted your time. I come from a world of Ansible so I understand the core ideas but don't quite understand all the vocabulary and implications of decisions yet.
Hmmm, the config there seems reasonable. I also use ApplyAndAutoCorrect so that's a good move. Did that resolve the issue? If not I think we'll want to remote into the box and run the test or get the logs so we can see why it believes it's not consistent.
It seems to have yes. The state is compliant now and continues to be.
It does seem that ApplyAndAutoCorrect is reverting the the agent version, which is interesting. Using real numbers, the agent is 2.177.0 when installed by DSC. If I update the agent, and maybe I'm missing something, it "updates" to 2.175.2. Shortly thereafter it's 2.177.0, which I think is being applied by DSC. This indicates that the update was causing the noncompliant state.
Interesting. I don't have the version revision happening for me. The update went to 2.175.2 and has stayed there. Seems like you have things working, but if you get a chance, learning why it thinks its inconsistent after the update would be great so we can allow updates for everyone. =)
Yep. I'll share what I learn as I go. I'll close this issue for now and then contribute what I can. @jwittner Thanks for all your input.
I've recently been looking for ways to automate the configuration of Windows VMs, part of which includes adding build agents, and so glad to have been directed to this project. This may not be the place to raise this issue so please let me know if that is the case.
I've installed the build agent successfully via DSC in Azure Automation. It appears that it was compliant until I updated the agent in DevOps. Once I did that, it became noncompliant in the dashboard and isn't going to return to a compliant state. Does the project have a recommendation for keeping the nodes in a compliant state? Should updating the agents be avoided and the nodes kept up-to-date via some other means? Thanks for any help.