Idea Details

AutoSys Client in the Docker Container

Last activity 07-13-2018 08:22 AM
Chykp's profile image
07-06-2018 10:07 AM

Autosys client in the Docker container fails with the following error when an attempt to run AutoSys cmds (eg: autorep) is made. 

CAUAJM_E_10527 Timed out waiting for response from the CA WAAE Application Server: [ ****** :9000]

CAUAJM_E_50033 Error initializing tx subsystem:  CAUAJM_E_10062 Failed to get initial configuration from CA WAAE Application Server(s).

 

It appears that the AutoSys cmd  is trying to respond back (from the App Server) to the client using the container's hostname/IP. As a result, the command times out as the container is not visible on the network from outside of the docker's host machine.

 

We believe that the problem is because of the AutoSys base technology --  the way the client communicates with the App Server & how the App Server responds back to the client. There is currently no way the client can be configured to handle App Server communications in sending the host machine's name/IP instead of the docker container's name/IP.

  

In order for the client to seamlessly work in Build, Ship and Run anywhere type of nimble Docker environment,  we need a fix for this issue whereby the App Server is able to learn & respond back to the AutoSys Client through the (physical) host machine where the Docker container resides.


Comments

07-13-2018 08:22 AM

The Sched/App Server setting for EnableIPCaching is below.

 

 

 

Our CA Case #:

Case: 01085646 - Docker Agent Connectivity

 

Thx!

Bendu Czerwinski

AutoSys Engineering

Architecture & Engineering

Technology Services

703-456-5696 (w)

703-915-2589 (c)

 

Reston 1

1771 Business Center Drive

Reston, VA 20190-5300

 

07-12-2018 04:41 PM

Hi Bendu,

 

I suspect it may have something to do with the IPCACHING setting that the app server is using.  If you want to send me the issue number, I'll take a look.

 

Regards,

Mike

07-06-2018 12:26 PM

I agree with most of what you’ve said. Our client (user) doesn’t want to have to chg his docker configs due to multiple reasons, related to their setup.

 

Thx for your input.

 

Bendu Czerwinski

AutoSys Engineering

Architecture & Engineering

Technology Services

703-456-5696 (w)

703-915-2589 (c)

 

Reston 1

1771 Business Center Drive

Reston, VA 20190-5300

 

07-06-2018 12:04 PM

as i suspected, Bendu shoehorned something and it isn't 100%.

I for one wouldn't ask for this until CA has a proper support platform for it. between SP7 and R12 so many changes anyone of them may break this undocumented feature.

This reminds me when VMs came to existence CA had a big caveat on the banner. if you use VMs the product may work but we will not debug. Until of course they certified. This is one of those situations. fun times..

if you ask me i dont want the core product tweaked where it may break the core product. 

 

may i ask you why can't there be conditional docker config chgs required?

 

There are always constraints to getting something to work and if there's a tweak for AutoSys so be it. 

 

This will be a long journey and i will keep my vote up but honestly i do not want to see the core break as a result of this endeavor. 

 

 

Steve C.

07-06-2018 11:44 AM

This is not technically a “bug”. It’s the default behavior/design of the AutoSys Client/App Server that we’re trying to get tweaked for the docker container clients to work, without any conditional docker config chgs required.

 

We’ve already got a ticket opened with CA, when this problem was first reported.

 

Excerpts from CA’s response during one of our conversations…

“I still don’t see why the container host name matters.  It was discussed on the call that only one container in the docker host could run the AE CLIs so there will only be one host which has this set per docker host.  It is not possible for multiple containers within a single docker host to run the AE CLIs given the current technology and architecture.

 

Why does it matter that a container, which is in the docker private network, has the same name as the docker host?  The docker environment does not provide DNS servers in the internal private network.  Also what the container thinks is it’s host name does not have to match what the container is known by externally.

 

The problem is rooted in the base technology used for communication with AE.  It is not trivial to change the underlying communication architecture and doing something which is nonstandard.    We have future plans to change the communication protocol used for the CLIs and APIs but I cannot give a timeline on that.”

 

Bendu Czerwinski

AutoSys Engineering

Architecture & Engineering

Technology Services

703-456-5696 (w)

703-915-2589 (c)

 

Reston 1

1771 Business Center Drive

Reston, VA 20190-5300

 

07-06-2018 11:10 AM

If this is supported then you don't open an ideation, you open a ticket and you request a BUG FIX. This tells me, the REP was mistaken,or this is one of those its supported if you, you stand on your head and yodel, but we don't officially support it. 

my worry about making this docker is what if 10000 requests come in for an autorep. from all of these spun up clients? 

I would think if the agent wasn't mean to be in a container they wouldn't recommend making the client agent ready either.

Not sure what Dan Shannon has to say about this situation, but since you told us CA said its good then if i were you i would close the ideation and log a bug fix. 

 

I will vote up only because a CA *cough* engineer claimed its supported... I still think it's a ticket. 

just my 3 cents as always.. and good luck...

 

Steve C.

07-06-2018 11:01 AM

I support all fixes for defects.

07-06-2018 10:51 AM

Hi Steve,

 

CA told us that they do  support the AutoSys Client in the Docker Container. They’ve been assisting us to get it working. It was the CA Rep who recommended that we submit this enhancement request/idea to the CA Community site in order to get interested parties to support any expedited fixes to the issues we’ve encountered in the container.

 

The AutoSys Client in the Container works but the Docker config needs to be tweaked in order to effect certain behaviors seen. This is the recommendated fix we’ve submitted.

Bendu Czerwinski

AutoSys Engineering

Architecture & Engineering

Technology Services

703-456-5696 (w)

703-915-2589 (c)

 

Reston 1

1771 Business Center Drive

Reston, VA 20190-5300

 

07-06-2018 10:21 AM

AUTOSYS agent/client are NOT micro-services. If you look at the as_server log it most likely couldn't find the machine.

I would not think anyone would run the client as a micro-service.

I suggest you NOT run autosys CLI as a micro-service run it from the actual VM as it was meant. or use the AEWS that comes with. The error is germane to the issue at hand and did you not first talk to CA about whether or not agents/clients should be loaded in docker, because it is NOT supported.

 

just my 3 cents and based off other conversations i have had with CA. 

 

Steve C.