Migrate from RA Agent to Integration Agent for the same type of agent

[Olgun Onur Ozmen]

Hi ,

We have an uncertainty that we discussed and clarified with support months ago and it is not fully specified in the documentation. 

If you are going to convert an RA agent of the same type to an Integration Agent;

• If you have UP the new Integration agent, the old RA solution is crushed (Agent keep remain UP) . As only one RA/Integration pair agent/solution can be made active on same time.
• Jobs on the old RA agent can continue when the new Integration agent is installed. As long the old RA agent is UP this will have no impact on old jobs.
• If you Down/Up the old RA agent or turn automic Off/On, the old RA agent is no longer UP. (in order to want the old RA agent UP again, you need to load the RA solution, but in this case the situation is reversed, the new Integration Agent solution will be crushed)
• If you have the new Integration agent UP, all jobs created from scratch now come with the job menu of the new Integration agent. (You can't think like "I'm doing the old RA agent job").

They even added the following below part in the documentation as a result of my initiatives. Here it is that warning:

Migration Suggestion:

Both agent should only be needed for a short term . Will have to decide a agent migration time period, install the new agent and then try and migrate all of the jobs to the new agent one by one, without deactivating the old agent and without  taking it down automic.  You will not be able to do the old ra job and once you start migration and if you start switching jobs to the new agent, there is no going back. After migrate , then you will free to remove the old agent completely. 

Criticism:

The first thing that the designers of these new Integration agents should have thought was “if we are introducing a new agents, it should in no way affect the functioning of the old agents”. But they didn't think like that. These agents should have been completely separate solutions, independent of each other.

Question:

These steps I have determined for "FTP RA / Integration FTP conversion". Are the same situations valid for "RA webservice Rest / Integration Rest conversion" ?  Has anyone made such a transformation. Please share your experiences. 

Thanks.

------------------------------
Olgun Onur Ozmen
https://www.linkedin.com/in/olgunonurozmen/
------------------------------

[Keld Mollnitz]

Hi all,

We are not happy with the IG agents, first of all due to the many bugs which still to this day, prevents us from deploying it to our Production system and secondly due to the migration path Broadcom has decided to set. 

If you, like us, has business critical workflows depending on the RA agents, I would think twice before migration to the IG agents.

/Keld.

[Leon Carroll]

Hello, I've migrated to the IG FTP agent in all our environments.

There's a few changes and I have my own checklist for anyone else about to do this:

1 - create the IG Agent and duplicate it to another agent using the workaround to support older cyphers. Create agent groups for each and replicate the secure and insecure agent groups to higher environments.  In your test and production add the ra_ftp to both groups.  Ensure that no jobs use the agent directly.  If you used puttygen to generate the certs and export to ossh through the tool, these will need to be handled through the agent with extended cypher support.  - see https://knowledge.broadcom.com/external/article/278025/ig-ftp-cannot-connect-to-sftp-with-sshrs.html

2 - review all filter objects used, the error messages have changed between implementations and your filter may not pick up the new report content

3 - check for usage of set connection in pre process steps on all jobs.  Avoid if possible and set one target to a variable instead.  One connection must be fixed. If a target connection is swapped out at runtime this is unlikely to work.

4 - I had issues using ed25519 certs and passwords, I was generating these using 1password but I think I managed to test ok with just using ssh-keygen and a more basic password. So do test this with complex passwords containing special characters.

On the whole it's working but i had to make a lot of patches to the ftp jobs in use.  I'll be cycling certs with development teams and vendors till i can replace the work around implementation for the older cyphers.

[Eric Lontz]

I have a post with my notes from implementing IG FTP. Here https://community.broadcom.com/discussion/automic-ig-ftp-agent-deployment-notes 

I do have to disagree there is no going back. We had to rollback the IG FTP agent solution to RA FTP agents due to bugs in 21.0.0, 21.0.1 and 21.1. 21.2 seems to taken care of these issues. We had to ensure any object created with IG FTP was recreated after being rolled back. Removed the old plugin from UC_ECC_PLUGIN and reloaded the RA FTP solution and have encountered no issues from it.
We didn't have much in the way of objects updates, 99% of our JOBS were able to be updated with Replace and updating our HOSTG objects in client 0.

We haven't yet migrated to the IG Rest agent, but likely will either later this year or next year.