[openstack-dev] [Mistral][PTL] PTL candidacy for Rocky

[Dougal Matthews]

I am announcing my candidacy for Mistral PTL for the Rocky release cycle.

If you don't know me, I am d0ugal on Freenode. I have been working full
time on
OpenStack since the Icehouse release cycle in 2014. I started to contribute
to
Mistral in 2016 and joined the core team later that year. Since then I have
been dedicating more of my time to the Mistral project. I am also a core in
TripleO, which relies on Mistral. I am employed by Red Hat.

Mistral has consistently been improving at a steady pace under the
leadership
of Renat, the current PTL, with well defined cycle goals. I hope to continue
this work and focus our efforts in the following areas:

* CI and testing

  In the Queens cycle we made some key improvements here, we enabled voting
on
  the devstack CI jobs and transitioned to zuulv3 but we still have work to
do.
  The Tempest jobs can still be unstable and only exercise small portions of
  the API. The coverage jobs have remained non-voting as they are unstable.
We
  don't test database migrations.

* Documentation and Onboarding

  I would like to put a stronger focus on documentation, to make the Mistral
  onboarding process easier for new users, operators and contributors.
Mistral
  has proven itself to be very powerful and useful but I think we need to
make
  it easier and more attractive to new users. This will likely require an
  overhaul of the documentation and a stricter requirement of documentation
for
  changes and additions.

* Further work on mistral-extra

  mistral-extra will provide a library of Actions that will let workflow
  authors easily integrate with more services and tools. In Queens we made
good
  progress with mistral-lib, a new library for writing actions. In Rocky I
  would like to see more progress with mistral-extra. The first addition is
  likely to be Ansible integration and the relocation of the OpenStack
actions
  from the main Mistral repo. This work will increase Mistrals utility and
  lower the barrier to entry for new workflow authors.

* Consistency, Stability and HA

  Some components, like the event engine have been added without HA taken
into
  consideration. I would like to see us resolve these and set a higher
standard
  for further additions to avoid this problem returning. The cron triggers
  subsystem also doesn't meet the quality standard we should expect -
enabling
  it creates high load and it requires refactoring.


These are some of my personal goals and ideas. However, I see the PTL role
as
much about coordination and collaboration. This is why I believe a focus on
onboarding, documentation and stability would be best for the project. I
hope
to incorporate ideas from other community members and help everyone work
more
efficiently.

I would love to speak to more new users and contributors. You can reach out
to
me directly or find me in #openstack-mistral.

Related patch to openstack/election:
https://review.openstack.org/#/c/541191/

Thanks,
Dougal
__
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-dev] [mistral][ptl] PTL candidacy

[Renat Akhmerov]

Hi,

I'm Renat Akhmerov. I'm running for PTL of Mistral in Rocky.

Mistral is a workflow service developed within the OpenStack community from
the ground up.

In queens we mainly focused on bugfixing, improving performance and
documentation. Performance was again significantly improved (~100%)
by optimizing DB operations and data schema (mostly additional indexex)
and using caching technics. We also made Mistral more robust in various
failure situations. To achieve that we came up with a number of protection
mechanisms.

The two other noticeable features we added are:

* We can now start a Mistral workflow based on an existing workflow
  execution, no matter if it's still running or finished. Given an ID of
  an execution Mistral copies all needed parameters (input, env etc.) and
  creates a new execution.
* When creating a workflow execution, we can now pass an ID of the new
  execution. If an execution with this ID already exists the REST endpoint
  just returns details of this execution as if it was GET operation. If
  not, it create a execution with this ID. Thus creation of workflow
  execution can be idempotent.


For the next cycle I'd like to propose the following roadmap:

* Keep improving multi-node mode and HA
* Rearchitect Mistral Scheduler, make it more suitable for HA
* Optimize ‘join’ tasks
* Close all the gaps in the documentation and restructure it so it is more
  convenient to read and navigate
* Usability
  * New CLI/API (more consistent and human friendly interface)
  * Debugging workflows
  * Workflow failure analysis (error messages, navigate through nested
    workflows etc.)
* Refactor Actions subsystem
  * Actions testability
  * Move OpenStack actions into mistral-extra and with better test coverage
    and usability

Some of those items have now been in progress for a few months. We keep
working on them and I hope most of them will be completed in the next
cycle.

Should you have any ideas on these points we're always happy to discuss and
correct our plans.

We're always happy to get new contributors on the project and always ready
to help people interested in Mistral development get up to speed. The best
way to get in touch with us is IRC channel #openstack-mistral.


The corresponding patch to openstack/election:
https://review.openstack.org/#/c/540720/

Thanks

Renat Akhmerov
@Nokia
__
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-dev] [mistral][ptl] PTL candidacy

[Renat Akhmerov]

I'm Renat Akhmerov. I would like to announce my candidacy for being a PTL of
Mistral Workflow Service in Ocata cycle.

I think Mistral now is a pretty mature project which provides really useful
and cool capabilities. The project now is moving into the phase when technical
perfection should be the number one priority. In many case Mistral serves as
one of the central infrastructural components. To be able to build production
ready solutions on top of Mistral it needs to be reliable, demonstrate
excellent performance, provide good usability and comprehensive documentation.

Here are my priorities for Ocata cycle:

* Performance. In Newton cycle we made Mistral work about 30 times faster.
  Now it's able to complete a workflow consisting of hundreds of tasks with
  highly parallel structure and lots of join operations during tens of
  seconds or less depending on workflow actions. That's not all, there's
  still a potential to do even better and also improve Mistral when dealing
  with parallel loads.
* Scaling. Although it's now possible to scale Mistral engine tier we still
  need to improve when having a high load.
* Extensibility. We started working on Custom Action API which will allow
  writing custom Mistral actions in a more flexible, elegant and powerful
  way. We're planning to finish this work in Ocata cycle.
* Usability and documentation. There are some gaps in Mistral documentation.
  User experience, especially CLI, also needs to be improved. We finally
  started gathering ideas for new CLI and API versions in Newton cycle.
* Building even more robust and diverse community.

I'd like to welcome everyone who wants to help with Mistral development.
We'll provide all necessary assistance.

Here’s a link to the patch with the description of my candidacy:
https://review.openstack.org/#/c/371943 


Renat Akhmerov
@Nokia

__
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