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" <cl...@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.tar...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
