<div dir="ltr"><div><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 12, 2020 at 8:54 AM Renat Akhmerov <<a href="mailto:renat.akhmerov@gmail.com">renat.akhmerov@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">



<div>
<div name="messageBodySection">
<div dir="auto">Hi,<br>
<br>
Although the decision was made long ago (about 1.5 years AFAIK) it’s still disappointing for me to see it happening and I feel like saying something.<br>
<br>
It may sound weird but, in the best attempt to be technically honest, I actually agree with the decision to remove Mistral from TripleO. As far as I know, TripleO never used the strongest distinguishing sides of Mistral (like running workflows at scale, using it for very long running workflows etc). Mistral was mostly used just to extend configurability customizability of TripleO. Red Hat’s engineers who I had a great pleasure to work with on Mistral a few times told me “Hey, we are allocated to Mistral but we just don’t know what else to work on that our company would need. It just works for us. Works very well for the case we use it. Bugs are very rare, maintenance doesn’t require 4 people from Red Hat. So we’ll be shrinking our presence.” So it happened, as expected. I realized there was no point in trying to keep them on the project. Then some new engineers came and said: “Why can’t we use something else, more well-known, like Ansible?” So, honestly, for this use case, yes. However, I heard many times that Ansible is essentially the same thing as Mistral but it is more mature, well maintained, etc etc. And every time I had to explain why these two technologies are fundamentally different, have different purposes, different method of solving problems.<br>
<br>
I’m saying this now because I feel it is my fault that I failed to explain these differences clearly when we started actively promoting Mistral years ago. And it would be bad if misunderstanding of the technology was the real reason behind this decision. For what it’s worth, if you ever want me to elaborate on that, let me know. This thread is not a good place for that, I apologize.<br>
<br>
And finally, I want to reassure you that the project is still maintained. More than that, it keeps evolving in a number of ways and new functionality is consistently being added. The number of active contributors is now lower than in our best times (Also true I believe for OpenStack in general) but it’s now promising to change.<br>
<br>
Again, my apologies for writing it here.</div>
</div>

</div>

</blockquote></div></div><div><br></div><div>Renat, I don't think you need to apologize here.</div><div>Your team has done excellent work at maintaining Mistral over the years.</div><div>For us, the major reason to not use Mistral anymore is that we have no UI anymore; which was the main reason why we wanted to use Mistral workflows to control the deployment from both UI & CLI with unified experience.</div><div>Our deployment framework has shifted toward Ansible, and without UI we rewrote our workflows in pure Python, called by Ansible modules via playbooks.</div><div><br></div><div>Again, your message is appreciated, thanks for the clarification on your side as well!</div><div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Emilien Macchi<br></div></div></div></div>