Embedded Ansible doesn't clear authentications on destroy

[himdel]

(created because of ManageIQ/guides#276 (comment) )

Running ManageIQ::Providers::EmbeddedAnsible::Provider.first.destroy (while having exactly 1 embedded ansible provider) does not delete all it's authentications.

This needed to be done manually after:

db = MiqDatabase.first
db.authentication_type('ansible_secret_key').delete    # db.ansible_secret_key.delete
db.ansible_rabbitmq_authentication.delete
db.ansible_admin_authentication.delete
db.ansible_database_authentication.delete

Cc @jrafanie

[jrafanie]

@jameswnl could this be related to the orchestrated destroy?

[jameswnl]

Very likely.

Do we support this use case? To delete the embedded?

[carbonin]

So this is interesting because it is something we should never do in production.

The authentication records stored against the MiqDatabase row are not really dependents of the provider. They are there so that we can recreate the provider if it was removed.

I don't really think this is a thing we should add.

[jameswnl]

So the other issue that @jrafanie mentioned is that external Ansible Tower (as well as Foreman) provider destroy is always rolling back and the fix is here.

Now reading a bit closer, i am not sure if this issue is the same - @himdel when you do the provider.destroy, does the provider remain or not?

[himdel]

Now reading a bit closer, i am not sure if this issue is the same - @himdel when you do the provider.destroy, does the provider remain or not?

This is not the same, when I did provider.destroy, it worked and the provider (and the manager) went away.

---

How I hit this was: I had my dev setup set to use an external Ansible Tower as an embedded ansible.
Then that stopped working because of some "invalid pk" issues, so I started looking at how to make embedded ansible work again on dev setups - @carbonin provided a solution (the one documented in the guides PR), but it didn't work until I removed the old keys.

(I also have no opinion whatsoever on whether this should happen by default or not, it was a special case.)

[jrafanie]

I'm fine with leaving this as something to document as developer specific workflow. I was concerned there was something else causing authentications to stick around.

[Fryguy]

Assigning to @carbonin .

[Fryguy]

I'm kind of on @himdel 's side...why wouldn't we delete them in an after_destroy anyway?

They are there so that we can recreate the provider if it was removed.

@carbonin How can that happen?

[carbonin]

The provider can't be removed through the UI in production, but if we remove these authentication records then we lose all ability to access the awx database and might as well delete all of the data there and start from scratch.

It depends on what deleting the provider means from a higher level. I don't think the concept was really fleshed out as this was never supposed to happen.

[miq-bot]

This issue has been automatically marked as stale because it has not been updated for at least 6 months.

If you can still reproduce this issue on the current release or on master, please reply with all of the information you have about it in order to keep the issue open.

Thank you for all your contributions!

[JPrause]

@himdel is this still a valid issue. If not can you close.
If there's no update by next week, I'll be closing this issue.

[himdel]

Still very much true,

> ManageIQ::Providers::EmbeddedAnsible::Provider.first.destroy
...(lots of DELETE)

> db.authentication_type('ansible_secret_key')
=> #<AuthToken id: 1, name: "Ansible Secret Key", authtype: "ansible_secret_key", userid: nil, password: nil, resource_id: 1, resource_type: "MiqDatabase", created_on: "2017-10-06 16:39:06", updated_on: "2018-02-19 22:03:10", last_valid_on: nil, last_invalid_on: "2017-10-06 16:39:08", credentials_changed_on: "2017-10-06 16:39:06", status: "Incomplete", status_details: "Missing credentials", type: "AuthToken", auth_key: "v2:(whatever)", fingerprint: nil, service_account: nil, challenge: nil, login: nil, public_key: nil, htpassd_users: [], ldap_id: [], ldap_email: [], ldap_name: [], ldap_preferred_user_name: [], ldap_bind_dn: nil, ldap_insecure: nil, ldap_url: nil, request_header_challenge_url: nil, request_header_login_url: nil, request_header_headers: [], request_header_preferred_username_headers: [], request_header_name_headers: [], request_header_email_headers: [], open_id_sub_claim: nil, open_id_user_info: nil, open_id_authorization_endpoint: nil, open_id_token_endpoint: nil, open_id_extra_scopes: [], open_id_extra_authorize_parameters: nil, certificate_authority: nil, google_hosted_domain: nil, github_organizations: [], rhsm_sku: nil, rhsm_pool_id: nil, rhsm_server: nil, manager_ref: nil, options: nil, evm_owner_id: nil, miq_group_id: nil, tenant_id: nil>

[JPrause]

Thanks @himdel for checking, and thanks @jrafanie for removing the stale label.

[miq-bot]

This issue has been automatically marked as stale because it has not been updated for at least 6 months.

If you can still reproduce this issue on the current release or on master, please reply with all of the information you have about it in order to keep the issue open.

Thank you for all your contributions!

[JPrause]

@miq-bot remove_label stale
@miq-bot add_label pinned

[chessbyte]

@himdel since we changed the implementation of Embedded Ansible in the Ivanchuk release, would you please re-test once again.

[himdel]

db.ansible_rabbitmq_authentication
db.ansible_admin_authentication
db.ansible_database_authentication

None of those methods exist anymore.

But, I'm currently seeing these authentication types:

> MiqDatabase.first.send(:available_authentications).pluck(:name, :authtype)
=> [["Ansible Rabbitmq Authentication", "ansible_rabbitmq_auth"],
    ["MiqDatabase vmdb_production", "registration"],
    ["Ansible Admin Authentication", "ansible_admin_password"],
    ["Ansible Database Authentication", "ansible_database_password"],
    ["Ansible Secret Key", "ansible_secret_key"]]

None of ansible_rabbitmq_auth, ansible_admin_password, ansible_database_password, ansible_secret_key appear anywhere in the code.

So, I would guess that this is irrelevant to the new implementation but we still need a migration to remove the old authentications.

@NickLaMuro WDYT?^

[carbonin]

This is no longer an issue with the new ansible-runner based embedded ansible implementation.