I am new to Tidal and have to automate the agent restart process using API.
From the architecture stand point, I understand the agents are running on the nodes, so when the tidal master is not able to reach agent, it sends an error message with agent name that is not running. How can I use this information to restart the agent ? Is there any API to restart an agent ?
Thanks!
OK, so apparently there is no API to restart Tidal agent. This has to be done through command by logging into the target machine where the agent is running.
Related
We are running a pipeline that has run successfully for ages. It is failing as of yesterday. We are getting the error
The agent request is not running because all potential agents are running other requests.
The agent pool is offline
This stackoverflow solution says I need to run.cmd, but I am not running a self-hosting agent.
We also get this additional error
Failed to get scaleset from Azure with error: No service Endpoint found with Id: xxxx and Scope xxxx
How do I bring the agent back online and is that the solution to fix the error that is preventing the publish/deploy. If not, how do we fix this issue.
There are three kinds of icon of agent pool in Azure DevOps.
Microsoft-hosted agent:
Self-hosted agent:
VMSS(Azure Virtual Machine Scale Set):
So the type you are using is VMSS(Azure Virtual Machine Scale Set) pool. This type of agent pool will based on service connection of one of your project or subscription.
So if the machines are in the VMSS, you can try to edit your VMSS pool settings on Azure DevOps side, you can set up another service connection(please make sure the related register app on azure portal side has required permissions to the VMSS).
If no machine instances or the previous instances were been deleted, then the object on DevOps side will not be able to recovery. You can rec-config to a new VMSS or delete the old pool and create a new one.
After reading the very short official documents about the azure pipeline agent, I am getting very confused.
What exactly is an azure pipeline agent?
What is an agent job?
What's the relationship between agent and VM?
What's the relationship between agent job and VM? For each agent， one VM will be temporally assigned to it and will be back to the pool after the agent job finished?
If 2 different agent jobs run by 2 agents need the same running environment and the VM is agent job dependent. How should I retain the first agent job's running environment after it's finished running? Recreated again?
If each agent needs a VM, why create this concept? why not just directly use the VM or container?
Pipeline agent is machine where your build is performed. An agent is installable software that runs one job at a time.
Agent job is a set of steps which is recognized as execution boundary. Each job runs on an agent. All of the steps run together on the same agent.
From that perspective you can distinguish two kind of jobs - the onces installed on VM and onces instaled on container.
Agent job runs on agent which can be installed on VM. VM's are not assigned. Agents are assigned. There is agent pool, not VM pool.
I don't understand this one. Agents after finishing their job are going back to pool.
You may have more agents on on VM for instance one agents is installed on VM and few others as containers.
Please take a look here. You will find explanation for these concepts.
I have installed agent on VM and configured a CI build pipeline. The pipeline is triggered and works perfectly fine.
Now I want to use same build pipeline, same agent, but different VM. Is this possible?
How will the execution happen for builds and on which VM will the source be copied?
Thank you.
Like the others I'm also not sure what you're trying to do and also think that the same agent across multiple machines is not possible.
But if you have to alternate or choose easily between VMs, you could set up for each of your VMs (used for this special scenario) an individual agent queue with one agent in that pool. That way you can choose the agent pool at queue time via the agent queue dropdown field. But that would only work if you're triggering manually, not in a typical CI scenario. In that case you would have to edit the definition to enforce any particular VM each time you want to swap VMs.
NO. These private agents are supposed to have a unique name and are assigned to an Agent Pool/Queue. They are polling up to VSTS/Azure Devops server if they have a job to do. Then they execute it. If you clone a machine with the same private build agent, then theoretically the agent that picks it up will execute the job, but that is theoretic. I really don't know how the Agent Queues will handle this.
It depends on what you want to do.
If you want to spread the workload, like 2 build servers and have builds go to whichever build server isn't busy, then you would create 1 Agent Pool/Queue. Create a Private Agent on one server and register it to that Pool, then on the second server un-register the agent and then re-register the agent add it to the SAME pool.
If you want to do work on 2 servers at the exact same time, like a deployment to 2 servers at the same time, then you would create a 'Deployment Group' and add both servers to that. You would unregister both agents from the Agent Pool/Queue. From your 'Deployment Group' copy the PowerShell script snippet and run it on each machine. This way you can use this in your Release Pipeline and deployments in parallel, which take less time to do deployments.
You could set up a variable in the pipeline so you can specify the name of the VM at build-time.
Also, once you have one or more agents, you would add them to an app pool. When builds are run, it will choose one agent from the pool and use that.
I have installed the latest mongodb mms agent (6.5.0.456) on ubuntu 16.04 and initialised the replicaset. Hence I am running a single node replicaset with the monitoring agent enabled. The agent works fine, however it does not seem to actually find the replicaset member:
[2018/05/26 18:30:30.222] [agent.info] [components/agent.go:Iterate:170] Received new configuration: Primary agent, Assigned 0 out of 0 plus 0 chunk monitor(s)
[2018/05/26 18:30:30.222] [agent.info] [components/agent.go:Iterate:182] Nothing to do. Either the server detected the possibility of another monitoring agent running, or no Hosts are configured on the Group.
[2018/05/26 18:30:30.222] [agent.info] [components/agent.go:Run:199] Done. Sleeping for 55s...
[2018/05/26 18:30:30.222] [discovery.monitor.info] [components/discovery.go:discover:746] Performing discovery with 0 hosts
[2018/05/26 18:30:30.222] [discovery.monitor.info] [components/discovery.go:discover:803] Received discovery responses from 0/0 requests after 891ns
I can see two processes for monitor agents:
/bin/sh -c /usr/bin/mongodb-mms-monitoring-agent -conf /etc/mongodb-mms/monitoring-agent.config >> /var/log/mongodb-mms/monitoring-agent.log 2>&1
/usr/bin/mongodb-mms-monitoring-agent -conf /etc/mongodb-mms/monitoring-agent.config
However if I terminate one, it also tears down the other, so I do not think that is the problem.
So, question is what is the Group that the agent is referring to. Where is that configured? Or how do I find out which Group the agent refers to and how do I check if the group is configured correctly.
The rs.config() looks fine, with one replicaset member, which has a host field, which looks just fine. I can use that value to connect to the instance using the mongo command. no auth is configured.
EDIT
It kind of looks that the cloud manager now needs to be configured with the seed host. Then it starts to discover all the other nodes in the replicaset. This seems to be different to pre-cloud-manager days, where the agent was able to track the rs - if I remember correctly... Probably there still is a way to get this done easier, so I am leaving this question open for now...
So, question is what is the Group that the agent is referring to. Where is that configured? Or how do I find out which Group the agent refers to and how do I check if the group is configured correctly.
Configuration values for the Cloud Manager agent (such as mmsGroupId and mmsApiKey) are set in the config file, which is /etc/mongodb-mms/monitoring-agent.config by default. The agent needs this information in order to communicate with the Cloud Manager servers.
For more details, see Install or Update the Monitoring Agent and Monitoring Agent Configuration in the Cloud Manager documentation.
It kind of looks that the cloud manager now needs to be configured with the seed host. Then it starts to discover all the other nodes in the replicaset.
Unless a MongoDB process is already managed by Cloud Manager automation, I believe it has always been the case that you need to add an existing MongoDB process to monitoring to start the process of initial topology discovery. Once a deployment is monitored, any changes in deployment membership should automatically be discovered by the Cloud Manager agent.
Production employments should have authentication and access control enabled, so in addition to adding a seed hostname and port via the Cloud Manager UI you usually need to provide appropriate credentials.
I created a simple process by Applicaiton Lab interface in Bluemix Workload Scheduler. I ran my process, but the step didn't proceed and remained in queued status.
How can I proceed the step?
I executed the process by "Run now". The process doesn't have triggers
The step remains "Queued status".
The Process information
There is only one step. The step is "ping www.ibm.com"
Process doesn't have trigger. It is an on-demand process.
There might be a problem with the agent as I can successfully run a simple workload process without any issues. If you are using the Workload Automation Agent that is created for you then you will need to open a support ticket to have the Workload team look at that agent.
reviewing your question I think that a process submitted to the Workload Scheduler service should be a process which will complete: a ping command like the one you are trying to submit, will never complete if not 'killed' using CTRL+C (or called with [-c count] option)