Reset cloud profile counter

Cloud profile is adding incrementing id to VMs when launched.

Is there any way to reset them (when already deleted in infrastructure environment)?

Thanks,

10 comments
Comment actions Permalink
Hello,
I'll need to ask for some extra information to be able to help you.
  1. Concerning what you mean by incremental IDs: Agent names, when a name is already taken and the agent is not the same (And a new image is not the same), can take the form of myAgentName-1 (and -2, -3, -4, etc). This is typically the sign that that agent name is already occupied. Is this what you mean with incremental IDs? If not, can you please elaborate on what you mean with it?
  2. Are there other agents with the same name?
  3. Are the agents reusable instances/VMs or are they spawned fresh from images? And if they are image based, why is the name relevant?
Thanks,
 
Guilherme
0
Comment actions Permalink

Hi Guilherme Barbosa,

yes, that's what I mean with incremental id.

In general all is fine about this, but I would like to "restart" this counter. All previous ones where destroyed, no buildagt-1 .. -180 exist anymore and the next which is created will get -181.

I just want to say to TeamCity "please reset the counter, next agent to be created will get -1" again.

Best & Thanks,

Matthias

0
Comment actions Permalink

Hello Matthias,

In order to be able to help you further, can you please answer the following questions:

  1. Are the agents reusable instances/VMs or are they spawned fresh from images?
  2. When you say that agents are destroyed, you mean that they are removed? Or are they just being disconnected (you can check it on the Agents screen if they appear in the disconnected tab);
  3. Can you please upload the logs that you find under <BUILDAGENT_HOME>/logs to the following url: https://uploads.jetbrains.com/ and share the upload ID with us?

Thanks,

Guilherme

0
Comment actions Permalink

Hi Guilherme,

I am not sure if I could explain my issue or goal.

There is nothing wrong with behaviour when a VM is created, re-used or removed itself.

When a VM is configured as being reused, it is reused.

When a VM is configured as being destroyed, it gets destroyed and a new VM is created afterwards.

But no matter in which of those two cases TC decides that a new instance is needed, it automatically increments the agent's VM counter suffix by one. Assume that due to lifecycle changes a reused VM (agent-1) needs to be destroyed and created from scratch afterwards by next TC run (or on manual start): TC will increment the ID to agent-2. In our case, due to lifecycle and pipeline build config development and test we are at agent-138.

How can I tell TC that the next agent will be agent-1 again.

Best,
Matthias

 

0
Comment actions Permalink
Hello,
The logic behind the agent naming is the following:
  • If the agent has a name defined in /conf/buildAgent.properties, the server will try to use that name.
  • If the name in /conf/buildAgent.properties is empty, the server will try to use the agent's hostname.
  • If the agent name is in use, TeamCity server will add the incremental ID that you are seeing.
We would like to understand what is happening in your case, and if TeamCity should be using the normal agent name or if it is working properly and what you are experiencing is related to your setup.
As such, I will ask you again if you can upload:
  1.  The logs that you find under <BUILDAGENT_HOME>/logs;
  2.  The agents information XML file that you can find under TEAMCITY_URL/app/rest/agents
Please upload them to the following url: https://uploads.jetbrains.com/ and share the upload ID with us.
 
Thanks
0
Comment actions Permalink

Hi Guilherme Barbosa

thanks for following up, but I am afraid we are possibly not on the same page yet?

Your properties referenced above are used by the registration of the agent when it's machine is already up. This part is working as well. The agent's name is empty in its buildAgent.properties and is set fresh to the IP of the agent's machine.

The same regarding agent's logs, as they are created as soon as agent started on the created machine.

My issue is about the moments before this applies:

In our case TC server's cloud profile is launching a new VM and deciding on the desired agent or - if not available - name of the agent VM to be created. Then vCenter addon is creating the VM with the name chosen by server's cloud profile. At this step the -n suffix is already chosen and applied.

I want to reset this one.

Best,
Matthias

0
Comment actions Permalink

Hello Matthias,

Thank you for the clarification, I believe I have more clarity on your issue now. The counter used on the -n suffix is stored in a file in the TeamCity directory that should not be changed manually because it can affect other cloud profiles.

Can you explain why we need to reset it? If it really is necessary I can check if there is a safe way to do it or if I can find any alternatives for you.

Thanks,

Guilherme

0
Comment actions Permalink

Hi Guilherme Barbosa

as the name of the agents needs to be <15 chars (incl. number extension) due to Windows sysprep issues, we just have 11 chars for VM and hostname. This raises already the general request of resetting this so maybe only 3 chars are needed for suffix and 12 can be used for VM and hostname.

Additionally it is an idea coming from lifecycle management that when using a new version of the image to reset this counter, as - due to the issue described above - version information is hard to put into the VM name as only 11 chars can be really used.

Best,
Matthias

 

0
Comment actions Permalink

Hello Matthias,

You can reset this incremental suffix, but as said above, we can't recommend to change it manually as this scenario has not been tested internally and the consequences are unclear (even if there is only one cloud profile). As such, if you are willing to perform the change at your own risk, you can stop the server and edit the file containing the ID under the <TeamCity_data_directory>/system/pluginData/vmwareIdx/ folder.

For the reasons stated above, if you want to try this we recommend you to test this on a non-production server first with a test VM image.

Please let me know if you have any more questions.

Guilherme

0
Comment actions Permalink

Hi Guilherme Barbosa

ah, ok, didn't acknowledged that this is the "final" solution, but then accepted. So bottom line: there is no standard supported way for such a reset. 

We'll have a look if we will perform that or not.

Thanks,
Matthias

0

Please sign in to leave a comment.