-
Notifications
You must be signed in to change notification settings - Fork 27
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
cloudera.cloud.env failing when environment already exists #59
Comments
the public_key_text value looks to be identical to me, so it shouldn't be triggering this behaviour, but I also cannot reproduce it. |
Hi Chaffelson, I was able to replicate the error. This happened when I tried updating our CDP environment by including new groups with its corresponding resource role assignment like MLUser, DEUser, ODUser, etc. Our environment is running with version 7.15. It is hosted in AWS and it comes with CDE, CML, and CDW. Any specific configuration that you are looking for that can help identify the issue? Thank you
|
Ah ok, so it's probably a different violation that is not being reported, so the public key text is actually probably a red herring. |
We are using the following module to execute updates on cred - name: "Create credential {{ env_credential['credential_name'] }}"
cloudera.cloud.**env_cred**:
state: present
cloud: aws
name: "{{ env_credential['credential_name'] }}"
description: "{{ env_credential['description'] }}"
role: "{{ env_credential['role_arn'] }}"
debug: true
cp_region: "{{ cp_region }}" |
I have one question on the behavior below. I re-ran the same pipeline that created this environment and, when the environment is present, it fails. From what I saw, the environment is the only component where this happens. When trying to install a CDE/CML/etc, cluster that is already installed, the same warnings appear but the module does not fail.
Any insights on this ? I could go around it by tweaking the
failed_when: never
flag and having another task which checks if the installation went fine by querying the environment status. However, that is not oki since, in case of an environment creation failure, the failed_when will hide the error.The text was updated successfully, but these errors were encountered: