> In parallel to that, we think we should also have a discussion about heat and heat-templates. The activity of these projects seems quite slow and (do not hesitate to correct me if I'm wrong) they are more or less in a way to be replaced with more modern ways to orchestrate OpenStack. Should we not prioritize their deprecation or at least start a wider discussion about their fate?
>
Well, I'm quite surprised to see this statement without any discussion with the heat project,
or even me who has been maintaining the project for some time.
You're right Takashi, I should have contacted you
first. I apologize.
My goal with that thread was simply to ensure that
we are able to conduct the eventlet migration safely and not to dictate
an architecture or a decision. I simply wanted to ensure that this
migration effort wouldn't rely on the shoulders of only one person and
ensure that we assign the needed resources in time. but I admit that I did it clumsily. and again I
apologize for that. In the case some
vendors would already have some tracks to replace heat by an
alternative, I wanted to weigh the pros and cons of a potential global
replacement rather than an eventlet costly migration. But, now that the nail is hammered in, the sooner the
discussion, the better resource allocation, the smoother the migration.
In addition to that, when I wrote my original sentence, especially the part about "more modern ways to orchestrate OpenStack" I was only supposing that the recent OpenShift move (RHOSO) by Red Hat would open the doors of an alternative orchestration of OpenStack through OpenShift mechanisms. But I had a RedHat centric point of view concerning this point, and I didn't consider the feasibility and all the vendors and the community sides.This is an abusive generalization on my part. You should also notice that I speak on my own concerning this point, there is yet no official RedHat downstream discussions/positions about removing Heat either.
To finish, given all the various discussions I recently had following this thread, it seems, at first glance, that the migration is feasible and not so hard, so that's good news.
Thank you Takashi for all your hard work on Heat and in OpenStack in general and sorry again for the misunderstanding generated by this thread.
Yes. Heat is not very active. However it is used in multiple deployments or products.
The User survay data[1] shows 57% of deployment is using heat. I know there are several
vendors using it in their product. However the sad fact is that most of them rarely
prioritize improvement or even maintenance of Heat recently.
[1] https://www.openstack.org/analytics/
I've seen number of people insisting that Heat can be "easily" replaced by any other
"much better" tools such as ansible. Yes. It may be easy to create resources using
such tools, but you likely find multiple problems when you try to modify your resource
stacks, like reducing number of servers. You should be always careful about the resource
dependencies (for example you can not delete a volume before you detach it from an instance)
and implementing the correct dependency is usually messy unless your tool can detect
diff and construct the appropriate order of resource update, which heat does.
I saw number of softwares, especially NFV managers, were built on Heat in the past and
I don't know how many of these could have migrated away from heat really.
However I'm happy to retire it if there is a common consensus within the community
that heat is no longer a thing and can be easily replaced by something much better.
I'm quite interested in learning what 57% of deployments may use next to replace heat,
so that I know what I can/should focus instead of Heat (or even OpenStack) :-).
> ## Call to Action
>
> Epoxy is a SLURP series, and as we are close from lib freeze and from milestone 3, that's the right time to prioritize your deprecations in your deliverables in view of removing these pieces with non-SLURP series. The sooner they are deprecated the better.
>
> ## Important Dates
>
> Please do not hesitate to join us during our bi-weekly meeting on #openstack-eventlet-removal.
> Bring your own topics and do not hesitate to ask questions.
>
> All the details are available in the links below:
> - https://wiki.openstack.org/wiki/Eventlet-removal#Recurring_Events <https://wiki.openstack.org/wiki/Eventlet-removal#Recurring_Events>
> - https://etherpad.opendev.org/p/epoxy-eventlet-tracking <https://etherpad.opendev.org/p/epoxy-eventlet-tracking>
>
> ## Final Thoughts
>
> This series strongly demonstrated the feasibility to remove our dependency to Eventlet. There is still a long way to go but the path is now well cleared. Do not hesitate to take example on the ongoing efforts, and If there are any questions or if you need assistance with your project’s transition away from Eventlet, please join the discussion on the #openstack-eventlet-removal OFTC channels . We will be happy to help you!
>
> Thank you for your dedication and hard work!
>
> --
> Hervé Beraud
> Senior Software Engineer at Red Hat
> irc: hberaud
> https://github.com/4383/ <https://github.com/4383/>
>