-
Notifications
You must be signed in to change notification settings - Fork 123
CSPL-1206: Introducing the App Source scope clusterWithPreConfig #442
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
With the changes listed here in this PR, first-time ES app installation works fine. However, when the Deployer Pod resets for any reason(say, for example, a new app added or existing app modified), then it is getting into crashLoopBackoff. When the new deployer Pod is coming up, Ansible playbooks validate all the installed apps. In case if the ES app is available, it runs the post set up playbooks, which is failing with the following error
Had a discussion with Jeff and Julien, and we all believe the command eesinstall is not recognized anymore, as the app was already installed, configured, and deployed to the SHC members. (Ideally, this should be the same issue even with the traditional way of deploying the ES app), and is outside the scope of the Operator. To work around this behavior on the Ansible side added the following fix, and it works fine, for all the Pod reset scenarios. This is just to make sure that the ES installation works in the big picture of the Operator framework, and not the final fix at this time, as we may miss the genuine error cases.
|
3b1feaa
to
2cac5ee
Compare
- Also, intruduce the additoinal liveness intialDelay of 1500 sec if the App framework configured - CR configured liveness probe config always wins - Exclude the MC Pod using the extraEnv from CR - Fix the Pod merge logic to include the liveness and readiness probe intial delays
Support for new App Source scope
clusterWithPreConfig