Just received this, from a client account, and cannot believe it:
As someone that has developed several dozen of extensions, most of them in EF 1, the target is not doable! What is worse is knowing this, this way.
@Mike_L, we need some urgent clarifications on this...
This message was sent out to all accounts we believe are affected by this discontinuation.
There is an accompanying blog post coming with additional information. We are also working on a how-to guide on how to convert Python extensions to the new framework as soon as customers and partners can do that.
I have forwarded this thread to the work group who are busy with the EF1 removal.
Yes, that's true. Unfortunately, Python Code Extensions 2.0 are not even available yet. We definitely need to know what the sunset in October 2024 means. Extensions will stop working completely? Just new extensions could not be added? Just support will be discontinued and the extensions will keep working?
Even with a successful conversion, there can be quite a significant impact on existing customers in terms of DDUs, as the EF2 is based on a continuous "data-stream" (logs/events/metrics/...) to have the entities created and alive (at least once in 15 minutes). There is currently no option to create the entities without it as it was possible in EF1.
Python extensions in EF2 is scheduled to be available somewhere around Perform. We are aiming to release the how-to guides on conversions in December or January so people can prepare for it.
The sunset date means that we will remove the extension framework from OneAgents and ActiveGates.
If you are aware of use cases which is not possible with Extension Framework 2.0 our product management team will be interested to hear about that.
We will provide some automation scripts as part of the vscode plugin from my team to simplify the conversions of Python extensions, such as converting a part of the plugin.json file. We are also able to help out through Dynatrace services if the 12 month advance notice is too limited for planning.
For JMX the automatic conversions instructions are already available on https://developer.dynatrace.com/extensions-v2/dynatrace-extensions-vscode/guides/jmx-conversion/
There are so many questions that have arised in the last two hours, since I was notified of this. The Community is certainly not the place to put them, so I have channeled them internally. I hope to get replies really fast.
We all value your contributions here, and especially how fast they are. But I'll repeat what I said initially, given what else I have discovered in the meantime: this sunset timing is not reasonable, and in my opinion, not doable...
Now that we are in the hope phase, I hope:
You're absolutely correct - I acknowledge that our communication with the experts could have been handled better. In September we did have two internal messages shared, followed now by this public message to customers. We are providing a 12-month window prior to the End-of-Life (EOL) of Extension Framework 1.0 (EF1.0). And as we understand that this timeframe may not suffice for some of you, and we want to ensure that Dynatrace will support you in various ways. Starting from automated JMX conversion to dedicated trainings on Python migration.
When we introduced Extension Framework 2.0 (EF2.0) in March 2021 (blog) we already mentioned that EF1.0 would eventually be phased out. Subsequently, our primary focus has been on maximizing the value of the new EF2.0, resulting in limited investments in EF1.0. As a result, maintaining its functionality and security beyond October '24 is not feasible especially that Python 3.8 (base for custom plugins) will reach end of life then.
You've rightly brought up the issue of feature parity between EF2 and EF1. While I agree that we may not have all the same functionalities in EF2 as we did with plugins, we are actively working to bridge most of these gaps or provide suitable workarounds. It's worth noting that a similar process occurred with Custom Charts, where functionalities were added during 12-month period after deprecation was announced.
In the meantime, I suggest we focus on two key areas:
Looking forward to discuss further
Michal Nalezinski (Senior Product Manager)
Dynatrace Enterprise Applications and Services
I have transmitted internally many issues that I believe are important. You should have access to them, and I'll use the correct forums to deal with them. And that includes the two key areas you mention.
Now, here in the Community, we have to address at least the following:
Finally, I would say that this is a problem that at the moment few of us have a real perception of the impacts. I have talked to several other EF1 developers, and treatment was the same. Fortunately, clients don't know the real impacts this will have, at least for now.
@michal_nalezin where can we track the gaps and features, so we can speed up the feature parity? Product Ideas here in the community?
The largest gaps I see are:
And yes, at least partners with existing extensions in the HUB need to have access to code-level extensions, preferably prior to Perform. We have existing customers, re-developing the extensions in EF2 will take some time and also we need to reach out to our customers to deploy it.
Hi @lucas_hocker ,
one of the use cases integrating other 3rd party monitoring tools such as Zabbix and Nagios. Both those extensions are already in the Dynatrace HUB and we have several customers using them. Our two extensions create entities in smartscape and send problem opening events based on problem data in the integrated monitoring system.
Benefits customers are now using:
Typically it's not beneficial just to pump metrics from one tool to another, so we have no continuous data stream. In EF2 we would need to send "dummy" data and the customer will need to pay DDUs for that. Customers really take DDU consumption into account.
@AntonioSousa just published :
@AurelienGravier, thanks for the notice 😄
Unfortunately, nothing really new is said, while introducing even more doubt on the process...
The worst part is that this clearly undermines confidence in developers developing in Dynatrace. In a Platform that is trying to move forward convincing developers to invest into it, this is not a good signal for them/us.
Hi @AntonioSousa ! If you will attend to Perform, there will be training on this topic: https://www.dynatrace.com/perform/training/?training=dynatrace-extensions
Thanks. I know about Perform training, but there are several problems with that:
Fortunately, haven't booked flights & hotel yet, but probably not attending the HoT session, given that only one of the five points seems interesting to me.
As a developer of about 50 custom Oneagent and a couple of activegate EF1 extensions I was shocked to get these news. Especially since the Python scripts in EF2 is not available yet. From the planned release of Python scripts I will have to convert two extensions a week until EOL, which is a lot of technical debt.
Please consider me as an early adopter of EF2.0 python scripts and the documentation since this is of high criticality.
I have already written a couple of EF2.0 extensions, so I am familiar with most concepts.
Also, will the HoT session be available virtually?
As partner, we are invited to attend a first workshop this Thursday titled "migrating Python-coded extensions from old Extension Framework 1.0 to new version 2.0".
The positive aspect is that the Dynatrace team doesn't rely on Perform to offer insights regarding this End of Life (EoL) situation. I appreciate it.
Yes, the JMX/PMI wizard will be deprecated as well. What we are looking to do instead is to expose the JMX class browser over API and integrate it into our VScode addon for extensions. This will enable automatic creation of EF2 JMX extensions just like we do for Prometheus for example.
It is not yet certain that a PMI data source will be created for extension framework 2.0. This is currently being discussed based on PMI being deprecated for quite some time.