-
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
Notify when an Openstack VM has been relocated #14604
Notify when an Openstack VM has been relocated #14604
Conversation
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.
Nice! Unfortunatelly, specs fail.
The ./spec/models/manageiq/providers/openstack/cloud_manager/vm_spec.rb
perhaps needs to NotificationType.seed
?
Could you please fix rubocop warnings?
eabb410
to
46f565c
Compare
connection.live_migrate_server(ems_ref, hostname, block_migration, disk_over_commit) | ||
rescue => ex | ||
error_message = parse_error_message_from_fog_response(ex.to_s) | ||
Notification.create(:type => :vm_cloud_live_migrate_error, :options => {:instance_name => name, :error_message => error_message}) |
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.
Shouldn't we re-throw the exception?
So, the raw_power_state
is not modified? (or any other side-effects)
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.
Yes, it absolutely should be reraised.
6410e85
to
011199e
Compare
Checked commits mansam/manageiq@46f565c~...011199e with ruby 2.2.6, rubocop 0.47.1, and haml-lint 0.20.0 |
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.
👍 thanks!
Emitting a notification when an Openstack VM relocation operation completes (successfully or otherwise) will allow the UI to further decouple from the underlying API call, rather than having to wait to report on its completion.