Open Stack

Hi.

I think to use Mistral with k8s extension for ironic use cases is not 
very good idea

because:

- Yes, Mistral can be used for executions of long-running business 
processes [1].

But business processes in Mistral are multi-step sets of abstract "jobs" 
(tasks) [1],

[2]. For ironic consoles use case long running task is set of OS 
processes which can

be started somewhere (host, container) and have all needed networking 
access.

- Due to difference mentioned above create long running task in Mistral is

over-complex for ironic use case. We should use additional "workflow" 
scripting

layer [3] and Mistral DSL [4]. K8s can be integrated with Mistral via 
custom actions

[5] or functions [6], but there is no "pure" API plugins, these 
extensions we should

use as part of scripting.

- Mistral can offload business processes to 3rd party services [1], but 
main problem

is asynchronous execution: ".. the concept of asynchronous action 
assumes that a

result won’t be known at a time when executor is running it" (therefore 
is not easy

to get task statuses for example) [7]. This increases complexity of 
scripting layer

that mentioned above.


Because of these reasons Mistral-k8s solution for ironic use cases 
(typical is consoles)

will be unclear and complex (without any technical arguments) in 
comparison with

directly usage of k8s API via client library [8].


[1] https://wiki.openstack.org/wiki/Mistral

[2] https://wiki.openstack.org/wiki/Mistral/Long_Running_Business_Process

[3] https://docs.openstack.org/developer/mistral/terminology/workflows.html

[4] https://docs.openstack.org/developer/mistral/dsl/dsl_v2.html

[5] 
https://docs.openstack.org/developer/mistral/developer/creating_custom_action.html

[6] 
https://docs.openstack.org/developer/mistral/developer/extending_yaql.html

[7] 
https://docs.openstack.org/developer/mistral/developer/asynchronous_actions.html

[8] 
https://github.com/openstack/requirements/blob/master/global-requirements.txt#L89


Yuriy Zveryanskyy


On 17.03.17 20:00, Taryma, Joanna wrote:
> Thank you for this explanation, Clint.
> Kuberentes gets more and more popular and it would be great if we could also take advantage of it. There are already projects in Openstack that have a mission that aligns with task scheduling, like Mistral, that could possibly support Kubernetes as a backend and this solution could be adopted by other projects. I’d rather think about enriching an existing common project with k8s support, than starting from scratch.
> I think it’s a good idea to gather cross-project use cases and expectation to come up with a solution that will be adoptable by all the projects that desire to use while still being generic.
>
> WRT Swift use case – I don’t see what was listed there as excluded from Kubernetes usage, as K8S supports also 1 time jobs [0].
>
> Joanna
>
> [0] https://kubernetes.io/docs/concepts/jobs/run-to-completion-finite-workloads/
>
> On 3/16/17, 11:15 AM, "Clint Byrum" <clint at fewbar.com> wrote:
>
>      Excerpts from Dean Troyer's message of 2017-03-16 12:19:36 -0500:
>      > On Wed, Mar 15, 2017 at 5:28 PM, Taryma, Joanna <joanna.taryma at intel.com> wrote:
>      > > I’m reaching out to you to ask if you’re aware of any other use cases that
>      > > could leverage such solution. If there’s a need for it in other project, it
>      > > may be a good idea to implement this in some sort of a common place.
>      >
>      > Before implementing something new it would be a good exercise to have
>      > a look at the other existing ways to run VMs and containers already in
>      > the OpenStack ecosystem.  Service VMs are a thing, and projects like
>      > Octavia are built around running inside the existing infrastructure.
>      > There are a bunch of deployment projects that are also designed
>      > specifically to run services with minimal base requirements.
>      
>      The console access bit Joanna mentioned is special in that it needs to be
>      able to reach things like IPMI controllers. So that's not going to really
>      be able to run on a service VM easily. It's totally doable (I think we
>      could have achieved it with VTEP switches and OVN when I was playing
>      with that), but I can understand why a container solution running on
>      the same host as the conductor might be more desirable than service VMs.
>      
>      __________________________________________________________________________
>      OpenStack Development Mailing List (not for usage questions)
>      Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>      http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>      
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev