When available, use Mistral workflows to scale stacks

[rwsu]

Modifies update_stack to queue tasks to scale up or down stacks
using Mistral if the workflows are available. Workflows are
available starting with OSP10.

For OSP9 and older environments, the existing behavior of updating
the stack directly is used.

Depends on ManageIQ/manageiq-providers-openstack#55

[tzumainn]

This looks good in principle! Scaling down a node doesn't require updating the heat parameters? Does the delete_node workflow take care of that?

[rwsu]

@tzumainn, heat parameters update is not required. delete_node takes care of it, and we just need to pass in a list of nodes to remove.

…

On Thu, Jun 15, 2017 at 6:25 AM, tzumainn ***@***.***> wrote: This looks good in principle! Scaling down a node doesn't require updating the heat parameters? Does the delete_node workflow take care of that? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1533 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA7eQ7_Pj7gkkpBM9fv_zXgLenDJ8F-0ks5sETDEgaJpZM4N30UF> .

[tzumainn]

This looks good to me!

[tzumainn]

@h-kataria can this be merged?

[martinpovolny]

@rwsu, @tzumainn : is it possible to fix the Rubocop issues before we merge this?

[rwsu]

@martinpovolny all fixed. Can you take a look?

[rwsu]

@martinpovolny the rubocop issues have been fixed. Can this be merged?

[martinpovolny]

Guys, the code looks good. Sure. But there's a fundamental problem with the approach.

 +        if can_use_scale_up_workflow?
 +          # OSP >= 10 use workflows
 +          stack.scale_up_queue(session[:userid], stack_parameters)
 +        else
 +          # OSP < 10 use heat stack update
 +          stack.update_stack_queue(session[:userid], nil, stack_parameters)
 +        end

This looks like a business logic. Based on some condition:

+  def can_use_scale_up_workflow?
 +    !workflow_service.nil? && workflow_service.has_action?("tripleo.parameters.update") && workflow_service.has_workflow?("tripleo.deployment.v1.deploy_plan")
 +  end

you are deciding how a particular operation should be accomplished. I can't see why this would live in the frontend.

I am sorry, but if there's any reason for this to be in the frontend, I need to hear it from the core guys. Ping @Ladas, @blomquisg

[agrare]

@rwsu @tzumainn all of this should be done in the provider stack code, the only thing the UI controller should do is queue the action for the stack instance.

Also stack.update_ready? connects to the provider directly to get the status, the UI appliance isn't guaranteed to be able to route to the provider API. This is why we queue provider operations for the generic worker running in the provider's zone. We cannot do any direct API calls to the provider from any UI code.

[martinpovolny]

the UI appliance isn't guaranteed to be able to route to the provider API

It's actually a supported usecase where it CANNOT route there. We had this discussion a couple of times already ;-)

[tzumainn]

Ah, that makes sense. @rwsu can we move that business logic into a unified scaling method in the backend?

[blomquisg]

@martinpovolny @h-kataria I don't have commit rights to this repo. So, if this PR has to be closed, merged, or whatever, I'm not going to be able to deal with it.

[martinpovolny]

@blomquisg : I asked for your expertise, but all is resolved already.

@rwsu : do you prefer carrying on in this PR or will you open a new one? Thanks and sorry for the trouble.

[miq-bot]

Checked commits rwsu/manageiq-ui-classic@f97c26d~...1488c9b with ruby 2.3.3, rubocop 0.47.1, and haml-lint 0.20.0
2 files checked, 0 offenses detected
Everything looks fine. 🏆

[rwsu]

Hi @martinpovolny, I've moved the calls that were hitting the OpenStack API into the orchestration stack model (ManageIQ/manageiq-providers-openstack#117). Does this look better?

[mansam]

@martinpovolny could someone from the UI team review whether this needs any further changes?