-
Notifications
You must be signed in to change notification settings - Fork 898
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] Set context data for the task associated with conversion host creation #18541
[V2V] Set context data for the task associated with conversion host creation #18541
Conversation
@fdupont-redhat @mturley Please review. |
So this will store all the params of the original request in Sorry if I'm misunderstanding. |
If we need to break the SSH keys into a separate request that we do before the enable request, that would be fine. Not sure if that makes this easier. |
Ah, true, forgot about private ssh keys. I don't know if we want to make that a separate request, though. I guess I would need some idea of the behavior of a retry option where the user had supplied a key. I can always just filter it out, too. |
Wouldn't that be more practical to create the conversion host before queuing the enablement task ? That would give the conversion host id pretty early, while being quite fast. Upon creation, it would create the Authentication from the SSH key, so we could discard it from the params hash. Then the @mturley, about filtering out SSH keys, would it be possible to ask the user to provide the VMware hypervisors SSH key when retrying ? That would prevent storing the private key in clear text. |
@fdupont-redhat we could pop a modal when you click Retry asking for the key again, sure. @vconzola what do you think about that from a UX perspective? Wouldn't it also need to ask them for the Conversion Host SSH key again? (and only ask about the VMware hypervisors key if they selected SSH for a transformation method?) |
@mturley I'm ok with your suggestion of asking the user to re-enter the SSH key information again on Retry. Not ideal from a UX perspective, but reasonable since we don't want to store the key. We should add some explanatory text to the modal explaining why we're asking the user to enter it again. "Because we care about you,..." :-) |
Added a comment describing the prompt for re-entering SSH keys in ManageIQ/manageiq-v2v#901. @djberg96 that works for us if you just want to filter those keys out of the params here. I think they'll be |
I'll just filter out anything with |
@mturley Updated. |
@fdupont-redhat If I had seen what a problem this coupling would have been I would have pushed back harder in my original PR for the rest API. I think that ship has sailed, so I'm going to look for other ways. |
@miq-bot add_label transformation, enhancement, hammer/yes |
@djberg96 I just wanted to reference my other comment here: #18540 (comment) If in that other PR there's no good way to use |
@mturley Ok, I'll modify this one to include the conversion host id as part of the context data. |
This should be listed in https://bugzilla.redhat.com/show_bug.cgi?id=1622728 I think |
@djberg96 are you expecting to add |
@mturley Was going to make the params a nested property, e.g. |
@@ -24,7 +25,21 @@ def queue_configuration(op, instance_id, resource, params, auth_user = nil) | |||
:zone => resource.ext_management_system.my_zone, | |||
:args => params | |||
} | |||
MiqTask.generic_action_with_callback(task_opts, queue_opts) | |||
|
|||
task_id = MiqTask.generic_action_with_callback(task_opts, queue_opts) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@djberg96 how about adding :context_data
to the options hash and pass it to the MiqTask.create!
here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about making modifications there - I think that method could use some refactoring in general - but was worried about introducing some sort of unexpected regression. I'd like to do that in a separate PR if you don't mind. If/when that happens, we can return to this and refactor it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd rather fix it first even if it is in a separate PR, a quick search of the callers should be enough to see if anyone is doing anything strange like passing in invalid keys.
I'd expect to be able to control any of the task attributes in the first argument, so something like:
Task.create!(
{
:state => STATE_QUEUED,
:status => STATUS_OK,
:message => msg
}.merge(options)
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually had this already started, so I've created a WIP here: #18578
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome!
This pull request is not mergeable. Please rebase and repush. |
I think this is now the only PR we're waiting for to enable the Conversion Hosts settings UI 🎉 |
I'll be focused on this one tomorrow. :) |
Checked commits https://github.com/djberg96/manageiq/compare/54746a1c10e85f716b34e5ee449c5d421607d224~...af2795546536fefff0e6178cb9bea3a23c78ac5f with ruby 2.3.3, rubocop 0.52.1, haml-lint 0.20.0, and yamllint 1.10.0 |
# any ssh key information. Useful for a retry option in the UI, and | ||
# informational purposes in general. | ||
# | ||
MiqTask.find(task_id).tap do |task| |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@djberg96 so you want to use the old method so this can be backported then followup with a refactoring PR to just pass in the context_data?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's the plan, yes.
…data [V2V] Set context data for the task associated with conversion host creation
…data [V2V] Set context data for the task associated with conversion host creation (cherry picked from commit 65617fa) Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1702278
Hammer backport details:
|
This PR modifies the
ConversionHost::Configurations#enable_queue
method so that the original params are stored in thecontext_data
of the associated task. This is a serialized field, so it would be accessible as a hash of options.A few things to head off potential questions about why this PR is written the way it is:
Q: What is this going to be used for?
A: The UI team would like it for a "retry" option. To do that they need the original parameters, which they can retrieve from the associated task.
Q: Why not just add
context_data
to thetask_opts
hash above?A: Because
MiqTask.generic_action_with_callback
only recognizes certain options. The rest are dropped.Q: Why use
MiqTask.find
on a task that you just created?A: Because
MiqTask.generic_action_with_callback
returns atask_id
instead of the full task object.Q: Where are
task_id
andmiq_task_id
coming from, and why explicitly.except
them?A: They're injected at some point in the queue lifecycle, so I have to manually reject them because they aren't actually part of the params. The specs revealed that. Without that, the specs will fail.
https://bugzilla.redhat.com/show_bug.cgi?id=1622728https://bugzilla.redhat.com/show_bug.cgi?id=1695886