Skip to content
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

[V2V] Refactor ConversionHost to use AuthenticationMixin #18309

Merged
merged 39 commits into from
Mar 26, 2019
Merged

[V2V] Refactor ConversionHost to use AuthenticationMixin #18309

merged 39 commits into from
Mar 26, 2019

Conversation

djberg96
Copy link
Contributor

@djberg96 djberg96 commented Dec 20, 2018

Currently there's a lot of hand-crafted ssh handling using the MiqSshUtil library baked into the ConversionHost model that is tied to specific providers. I thought we should leverage the AuthenticationMixin to take advantage of its features.

Specifically, this would give use a direct association between conversion hosts and authentications. This would be beneficial for certain providers, e.g. openstack, where we are currently using credentials set at the provider level. This way, we can set it on a per-resource level for all provider types by setting the authentication on the conversion host instance itself.

This will also be necessary for the UI where users are allowed to upload their own ssh keys.

https://bugzilla.redhat.com/show_bug.cgi?id=1673729
https://bugzilla.redhat.com/show_bug.cgi?id=1695861

@miq-bot miq-bot added the wip label Dec 20, 2018
@djberg96
Copy link
Contributor Author

@fdupont-redhat @agrare Just looking for some feedback here to see if it makes sense to leverage the AuthenticationMixin instead of the current code, while seems a bit clumsy to me.

@agrare
Copy link
Member

agrare commented Dec 21, 2018

Hm I think we were relying on the fact that the underlying resource had the authentication not the conversion host? And a Vm and a Host both include AuthenticationMixin afaik

@ghost
Copy link

ghost commented Dec 26, 2018

We don't exactly rely on the resource authentications. In the case of OpenStack for example, the authentication is associated with the provider, forcing us to have a single key for all conversion hosts of the provider. It was implemented this way to simplify the UX, as it only required to expose the ssh_keypair authentication for the provider. It might be a good idea to revisit this topic with advanced UI for conversion host.

@agrare agrare self-assigned this Feb 13, 2019
app/models/conversion_host.rb Outdated Show resolved Hide resolved
app/models/conversion_host.rb Outdated Show resolved Hide resolved
app/models/conversion_host.rb Outdated Show resolved Hide resolved
app/models/conversion_host.rb Show resolved Hide resolved
@miq-bot
Copy link
Member

miq-bot commented Mar 5, 2019

This pull request is not mergeable. Please rebase and repush.

@miq-bot
Copy link
Member

miq-bot commented Mar 7, 2019

This pull request is not mergeable. Please rebase and repush.

@miq-bot
Copy link
Member

miq-bot commented Mar 13, 2019

This pull request is not mergeable. Please rebase and repush.

@djberg96
Copy link
Contributor Author

djberg96 commented Mar 18, 2019

@agrare Made a few changes. First, it will now use auth_type if present, using the mixed-in authentication_type method. To make that work properly however, I had to modify the AuthenticationMixin by adding a authentication_private_keys method (surprisingly not already present) and then modifying available_authentications to include them.

Second, I came around to the idea that iterating over every authentication was not necessary as there should only ever be one associated authentication. Plus, it simplified the code.

Third, an AuthPrivateKey is automatically associated with the conversion host if the conversion_host_ssh_private_key param is found (originally just ssh_key, but we're changing it).

I've updated the specs, too. Please let me know if there are any other issues and/or if you want me to squash these commits.

@mturley
Copy link
Contributor

mturley commented Mar 18, 2019

This one should also be hammer/yes and listed in https://bugzilla.redhat.com/show_bug.cgi?id=1622728

@ghost
Copy link

ghost commented Mar 18, 2019

@miq-bot add_label transformation, enhancement, hammer/yes

@djberg96 djberg96 changed the title [WIP] Refactor ConversionHost to use AuthenticationMixin Refactor ConversionHost to use AuthenticationMixin Mar 18, 2019
@djberg96 djberg96 changed the title Refactor ConversionHost to use AuthenticationMixin [V2V] Refactor ConversionHost to use AuthenticationMixin Mar 18, 2019
@miq-bot miq-bot removed the wip label Mar 18, 2019
@miq-bot
Copy link
Member

miq-bot commented Mar 19, 2019

This pull request is not mergeable. Please rebase and repush.

@djberg96
Copy link
Contributor Author

@agrare I think I've addressed your concerns. The only question mark is the available_authentications that strangely was limited to openstack infra authkeypairs. IMO my update is more sensical.

…on_private_keys method and instead redefine authentication_key_pairs.
@djberg96
Copy link
Contributor Author

@agrare, just realized there's a minor issue i need to work out for cases where there's no associated authentication.

@djberg96
Copy link
Contributor Author

@agrare ok, I had to update the rescue handler because otherwise we could get a false positive for connect_ssh. I added some more specs to cover that.

@miq-bot
Copy link
Member

miq-bot commented Mar 26, 2019

Checked commits https://github.com/djberg96/manageiq/compare/5bc0dc517fdc68788d16e8d00a63f3dd6a7bf2eb~...002f7b4653511403f4eb6ca1be99b11ac2a73e74 with ruby 2.3.3, rubocop 0.52.1, haml-lint 0.20.0, and yamllint 1.10.0
5 files checked, 4 offenses detected

app/models/conversion_host.rb

Copy link
Member

@agrare agrare left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@agrare agrare merged commit 1922983 into ManageIQ:master Mar 26, 2019
@agrare agrare added this to the Sprint 108 Ending Apr 1, 2019 milestone Mar 26, 2019
@@ -67,7 +67,7 @@ def authentication_tokens
end

def authentication_key_pairs
authentications.select { |a| a.kind_of?(ManageIQ::Providers::Openstack::InfraManager::AuthKeyPair) }
authentications.select { |a| a.kind_of?(AuthPrivateKey) }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@djberg96 given the issues this causes on other providers I'm going to mark this refactoring hammer/no

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I recall, this was because in public clouds we also store the inventory-refreshed keypairs from the providers in the authentications table, and those happen to also be AuthKeyPair. Querying your key_pairs from the base class thus brings back both MIQ-owned and provider-owned, which is generally not wanted.

What really needs to happen is that we need to either a) move inventory-based key-pairs into a different table or b) create a separate intermediate class.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Fryguy PR added here #18633

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants