[tripleo] deprecating Mistral service
Hi folks,
In our long term goal to simplify TripleO and deprecate the services that aren't used by our community anymore, I propose that we deprecate Mistral services. Mistral was used on the Undercloud in the previous cycles but not anymore. While the service could be deployed on the Overcloud, we haven't seen any of our users doing it. If that would be the case, please let us know as soon as possible. Removing it from TripleO will help us with maintenance (container images, THT/puppet integration, CI, etc). Maybe we could deprecate it in Victoria and remove it in Wallaby?
Thanks,
Hi,
Deprecating in Victoria and removing in Wallaby sounds reasonable.
чт, 8 окт. 2020 г. в 14:35, Emilien Macchi emilien@redhat.com:
Hi folks,
In our long term goal to simplify TripleO and deprecate the services that aren't used by our community anymore, I propose that we deprecate Mistral services. Mistral was used on the Undercloud in the previous cycles but not anymore. While the service could be deployed on the Overcloud, we haven't seen any of our users doing it. If that would be the case, please let us know as soon as possible. Removing it from TripleO will help us with maintenance (container images, THT/puppet integration, CI, etc). Maybe we could deprecate it in Victoria and remove it in Wallaby?
Thanks,
Emilien Macchi
On Thu, Oct 8, 2020 at 3:34 PM Emilien Macchi emilien@redhat.com wrote:
Hi folks,
In our long term goal to simplify TripleO and deprecate the services that aren't used by our community anymore, I propose that we deprecate Mistral services. Mistral was used on the Undercloud in the previous cycles but not anymore. While the service could be deployed on the Overcloud, we haven't seen any of our users doing it. If that would be the case, please let us know as soon as possible. Removing it from TripleO will help us with maintenance (container images, THT/puppet integration, CI, etc). Maybe we could deprecate it in Victoria and remove it in Wallaby?
+1 - at least for tripleo CI we aren't running mistral on anything newer than train
Thanks,
Emilien Macchi
On Thu, Oct 8, 2020 at 9:47 AM Marios Andreou marios@redhat.com wrote:
On Thu, Oct 8, 2020 at 3:34 PM Emilien Macchi emilien@redhat.com wrote:
Hi folks,
In our long term goal to simplify TripleO and deprecate the services that aren't used by our community anymore, I propose that we deprecate Mistral services. Mistral was used on the Undercloud in the previous cycles but not anymore. While the service could be deployed on the Overcloud, we haven't seen any of our users doing it. If that would be the case, please let us know as soon as possible. Removing it from TripleO will help us with maintenance (container images, THT/puppet integration, CI, etc). Maybe we could deprecate it in Victoria and remove it in Wallaby?
+1 - at least for tripleo CI we aren't running mistral on anything newer than train
+1 In main branch (to be Victoria) Ceph and Derived parameters are not using Mistral anymore.
Thanks,
Emilien Macchi
+1
On Thu, Oct 8, 2020 at 8:04 AM John Fulton johfulto@redhat.com wrote:
On Thu, Oct 8, 2020 at 9:47 AM Marios Andreou marios@redhat.com wrote:
On Thu, Oct 8, 2020 at 3:34 PM Emilien Macchi emilien@redhat.com
wrote:
Hi folks,
In our long term goal to simplify TripleO and deprecate the services
that aren't used by our community anymore, I propose that we deprecate Mistral services.
Mistral was used on the Undercloud in the previous cycles but not
anymore. While the service could be deployed on the Overcloud, we haven't seen any of our users doing it. If that would be the case, please let us know as soon as possible.
Removing it from TripleO will help us with maintenance (container
images, THT/puppet integration, CI, etc).
Maybe we could deprecate it in Victoria and remove it in Wallaby?
+1 - at least for tripleo CI we aren't running mistral on anything newer
than train
+1 In main branch (to be Victoria) Ceph and Derived parameters are not using Mistral anymore.
Thanks,
Emilien Macchi
+1
Will we deprecate Zaqar as well ? AFAIK Zaqar is a part of deployment method by Mistral, As I've never seen users have Zaqar deployed in overcloud I think we are good to deprecate it following Mistral.
On Fri, Oct 9, 2020 at 1:38 AM Wesley Hayutin whayutin@redhat.com wrote:
+1
On Thu, Oct 8, 2020 at 8:04 AM John Fulton johfulto@redhat.com wrote:
On Thu, Oct 8, 2020 at 9:47 AM Marios Andreou marios@redhat.com wrote:
On Thu, Oct 8, 2020 at 3:34 PM Emilien Macchi emilien@redhat.com
wrote:
Hi folks,
In our long term goal to simplify TripleO and deprecate the services
that aren't used by our community anymore, I propose that we deprecate Mistral services.
Mistral was used on the Undercloud in the previous cycles but not
anymore. While the service could be deployed on the Overcloud, we haven't seen any of our users doing it. If that would be the case, please let us know as soon as possible.
Removing it from TripleO will help us with maintenance (container
images, THT/puppet integration, CI, etc).
Maybe we could deprecate it in Victoria and remove it in Wallaby?
+1 - at least for tripleo CI we aren't running mistral on anything
newer than train
+1 In main branch (to be Victoria) Ceph and Derived parameters are not using Mistral anymore.
Thanks,
Emilien Macchi
On Thu, Oct 8, 2020 at 6:08 PM Emilien Macchi emilien@redhat.com wrote:
Hi folks,
In our long term goal to simplify TripleO and deprecate the services that aren't used by our community anymore, I propose that we deprecate Mistral services. Mistral was used on the Undercloud in the previous cycles but not anymore. While the service could be deployed on the Overcloud, we haven't seen any of our users doing it. If that would be the case, please let us know as soon as possible.
I would be surprised if no one in the community has been deploying mistral on overcloud with TripleO. Though it's good to support as many _active_ services available in OpenStack, probably not worth the effort to maintain stuff that no one uses.
Removing it from TripleO will help us with maintenance (container images, THT/puppet integration, CI, etc). Maybe we could deprecate it in Victoria and remove it in Wallaby?
Thanks,
Emilien Macchi
Hi,
On Thu, Oct 8, 2020 at 10:06 AM Emilien Macchi emilien@redhat.com wrote:
Hi folks,
In our long term goal to simplify TripleO and deprecate the services that aren't used by our community anymore, I propose that we deprecate Mistral services. Mistral was used on the Undercloud in the previous cycles but not anymore. While the service could be deployed on the Overcloud, we haven't seen any of our users doing it. If that would be the case, please let us know as soon as possible. Removing it from TripleO will help us with maintenance (container images, THT/puppet integration, CI, etc). Maybe we could deprecate it in Victoria and remove it in Wallaby?
Thanks,
Emilien Macchi
+1
+1
On Thu, Oct 8, 2020 at 07:37 Emilien Macchi emilien@redhat.com wrote:
Hi folks,
In our long term goal to simplify TripleO and deprecate the services that aren't used by our community anymore, I propose that we deprecate Mistral services. Mistral was used on the Undercloud in the previous cycles but not anymore. While the service could be deployed on the Overcloud, we haven't seen any of our users doing it. If that would be the case, please let us know as soon as possible. Removing it from TripleO will help us with maintenance (container images, THT/puppet integration, CI, etc). Maybe we could deprecate it in Victoria and remove it in Wallaby?
Thanks,
-- Emilien Macchi
+1 I believe it is good for us to focus on the core OpenStack services that still have an active community and usage in production. For better or worse, Mistral has dropped in popularity due to other similar swiss-army-knife workflow automation tools.
On Thu, Oct 8, 2020, 6:34 AM Emilien Macchi emilien@redhat.com wrote:
Hi folks,
In our long term goal to simplify TripleO and deprecate the services that aren't used by our community anymore, I propose that we deprecate Mistral services. Mistral was used on the Undercloud in the previous cycles but not anymore. While the service could be deployed on the Overcloud, we haven't seen any of our users doing it. If that would be the case, please let us know as soon as possible. Removing it from TripleO will help us with maintenance (container images, THT/puppet integration, CI, etc). Maybe we could deprecate it in Victoria and remove it in Wallaby?
Thanks,
Emilien Macchi
Hi,
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.
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.
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.
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.
Again, my apologies for writing it here.
Thanks
Renat Akhmerov @Nokia 11 окт. 2020 г., 05:28 +0700, Luke Short ekultails@gmail.com, писал:
+1 I believe it is good for us to focus on the core OpenStack services that still have an active community and usage in production. For better or worse, Mistral has dropped in popularity due to other similar swiss-army-knife workflow automation tools.
On Thu, Oct 8, 2020, 6:34 AM Emilien Macchi emilien@redhat.com wrote:
Hi folks,
In our long term goal to simplify TripleO and deprecate the services that aren't used by our community anymore, I propose that we deprecate Mistral services. Mistral was used on the Undercloud in the previous cycles but not anymore. While the service could be deployed on the Overcloud, we haven't seen any of our users doing it. If that would be the case, please let us know as soon as possible. Removing it from TripleO will help us with maintenance (container images, THT/puppet integration, CI, etc). Maybe we could deprecate it in Victoria and remove it in Wallaby?
Thanks,
Emilien Macchi
On Mon, Oct 12, 2020 at 8:54 AM Renat Akhmerov renat.akhmerov@gmail.com wrote:
Hi,
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.
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.
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.
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.
Again, my apologies for writing it here.
Renat, I don't think you need to apologize here. Your team has done excellent work at maintaining Mistral over the years. 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. Our deployment framework has shifted toward Ansible, and without UI we rewrote our workflows in pure Python, called by Ansible modules via playbooks.
Again, your message is appreciated, thanks for the clarification on your side as well!
Renat, I don't think you need to apologize here. Your team has done excellent work at maintaining Mistral over the years. 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. Our deployment framework has shifted toward Ansible, and without UI we rewrote our workflows in pure Python, called by Ansible modules via playbooks.
Again, your message is appreciated, thanks for the clarification on your side as well!
Emilien, makes sense. Thanks and the best luck to you and your team :)
Renat
participants (11)
-
Brent Eagles
-
Carter, Kevin
-
Emilien Macchi
-
John Fulton
-
Luke Short
-
Marios Andreou
-
Rabi Mishra
-
Renat Akhmerov
-
Sergii Golovatiuk
-
Takashi Kajinami
-
Wesley Hayutin