Concerns about Project's Viability and Support? Is this project being abandoned?

[iandrianov77]

Dear ManageIQ Community,

As an experienced DevOps engineer, I find myself increasingly concerned about the quality of the ManageIQ appliance. My recent experiences, particularly with the configuration wizard, have been fraught with difficulties. This feature fails to function correctly from the outset, leading to significant troubleshooting efforts on my part. The messaging component of the wizard fails right out of the box. While exploring the product, I've had nothing but trouble getting the SmartState Analysis feature to work in the Oparin release, along with numerous other quirks.

I lost my Proof of Concept (POC) appliance when trying to upgrade from the Oparin release to the latest. Even when I issue a 'dnf update' on a brand-new appliance of the Petrosian release, it fails right from the start on ansible dependencies, similar to the Oparin release. This makes me question whether the upgrade path has been tested. Are there QA personnel actively working on the project team?

I configured the local database on a brand-new appliance and attempted to initiate the EVM service, only to find that it remains stale/inactive, providing no access to the user interface.

These technical challenges are compounded by what appears to be a lack of community engagement on this forum. I've noticed that questions posted over the last five months have gone unanswered, which raises serious concerns about the ongoing support and development of ManageIQ.

Given these circumstances, I can't help but wonder about the future of this project. Was there a strategic shift when RedHat transitioned ManageIQ to IBM? The current state of affairs suggests that ManageIQ might not be a viable long-term solution.

Am I missing a crucial piece of information that could assist in better understanding or resolving these issues? In other words, am I the only one who struggles? By no means am I a 'newbie' in the DevOps and System Engineering space – so if, with my experience, I face these many challenges, either I am missing some key insights, or this code/project is just spaghetti code with no ownership/leadership, or quality control. Please validate me... Am I wrong in my assumptions?

Any insights or guidance from the community would be greatly appreciated.

[Fryguy]

Hi @iandrianov77, thank you for posting your concerns. Hopefully I can respond to them.

The messaging component of the wizard fails right out of the box.

While exploring the product, I've had nothing but trouble getting the SmartState Analysis feature to work in the Oparin release, along with numerous other quirks.

when I issue a 'dnf update' on a brand-new appliance of the Petrosian release, it fails right from the start on ansible dependencies, similar to the Oparin release

I configured the local database on a brand-new appliance and attempted to initiate the EVM service, only to find that it remains stale/inactive, providing no access to the user interface.

Have you opened any bug reports and/or discussion topics on these issues? We'd like to know more details so we can correct any of those problems, or perhaps improve the documentation where it's lacking.

when I issue a 'dnf update' on a brand-new appliance of the Petrosian release, it fails right from the start on ansible dependencies, similar to the Oparin release

I think you might be hitting this issue: ManageIQ/manageiq-rpm_build#364. I noticed we didn't update the upgrade page with a note about this, so we will do that.

This makes me question whether the upgrade path has been tested. Are there QA personnel actively working on the project team?

At release time we smoke test the appliance builds as well as the containerized builds, and have not encountered the issues above. As far as regular testing goes, every pull request goes through a suite of automated tests. There can always be more tests, and frequently if a bug report is opened and addressed we add test cases to avoid regressions. Additionally, we do rely on a QA team who does regular testing through the lifecycle of a release.

These technical challenges are compounded by what appears to be a lack of community engagement on this forum. I've noticed that questions posted over the last five months have gone unanswered, which raises serious concerns about the ongoing support and development of ManageIQ.

We do our best to answer questions on the discussion forum, but we're a small team and we can't always get to everything. Also note that we have a matrix chat channel where questions are asked and answered as well. Some questions are harder to solve and may not have an answer. We also rely on the community to help answer questions, and we're always looking for more people to help out. We could probably do a better job of getting to those discussions on a more frequent basis, and we're working on that.

Note that the phrase "Unanswered" in the GitHub UI does not mean that the discussion question wasn't responded to. This is a feature of GitHub discussions where the questioner can mark a response as the "official" answer. If the questioner doesn't do that the status is "Unanswered" even if there are replies.

It's important to note that this project would not be possible to maintain without paid support from IBM (and thus IBM customers). The team members who work for IBM are obligated to help and respond to those paying customers first, and community support is on a best effort basis. This is no different from when the core team worked full-time for Red Hat and Red Hat was the primary sponsor of the project.

Given these circumstances, I can't help but wonder about the future of this project.

We're still here, and we're still working on the project as part of our full-time jobs. Honwever, we can't do this without the community, so if you are seeing any issues please open bug tickets with as much detail as possible.

Again, thanks for your question, and please feel free to open bug tickets on any problems you find.

[bdunne]

Hi @iandrianov77,

Thanks for your concerns! I'm going to jump back and forth a bit while trying to address them.

Was there a strategic shift when RedHat transitioned ManageIQ to IBM? The current state of affairs suggests that ManageIQ might not be a viable long-term solution.

As you mention, ManageIQ is the upstream project that Red Hat CloudForms was based on and the Red Hat product has been moved to IBM and rebranded as Infrastructure Management in the CloudPak for Multi-Cloud Management first and now CloudPak for AIOps.
While we do have community contributors, the core ManageIQ team members are employed by IBM.
The decision to move the downstream product was not made by the core development team, but it did cause a downsizing as some team members decided to work on other products rather than move to IBM.
We have also welcomed several new contributors since then and are working to backfill knowledge gaps.

Given these circumstances, I can't help but wonder about the future of this project.

There is still a growing interest in the product (upstream and downstream) and we continue to make regular enhancements. Please see our sprint reviews and the roadmap if you are interested in more details.

These technical challenges are compounded by what appears to be a lack of community engagement on this forum. I've noticed that questions posted over the last five months have gone unanswered, which raises serious concerns about the ongoing support and development of ManageIQ.

We appreciate the discussions and issues opened by the community, unfortunately some have slipped through the cracks. We are adding discussions to our triage meetings and will review them on a regular basis.

This makes me question whether the upgrade path has been tested. Are there QA personnel actively working on the project team?

As a smaller team, there are not as many people testing upstream as there used to be. The basic functionality is tested upstream before the release is announced, and the documentation is reviewed, but we can't guarantee that everything is thoroughly tested on upstream releases.

I lost my Proof of Concept (POC) appliance when trying to upgrade from the Oparin release to the latest. Even when I issue a 'dnf update' on a brand-new appliance of the Petrosian release, it fails right from the start on ansible dependencies, similar to the Oparin release.

As always, we recommend backups and/or snapshots before major changes like upgrades.
Unfortunately, our ansible integration has caused some problems for the dnf update experience. It's a problem where support lifecycles don't match perfectly and we need to remain on an older version.

Am I missing a crucial piece of information that could assist in better understanding or resolving these issues? In other words, am I the only one who struggles? By no means am I a 'newbie' in the DevOps and System Engineering space – so if, with my experience, I face these many challenges, either I am missing some key insights, or this code/project is just spaghetti code with no ownership/leadership, or quality control. Please validate me... Am I wrong in my assumptions?

With an open source project it's difficult to gauge the impact that we have and what the pain points are for people like yourself installing and upgrading existing appliances unless we see some feedback in issues or discussions.
As we find problems in the downstream product, we fix those upstream as well. It's a very large code base with many external integrations to maintain (and increasing every day), I certainly wouldn't call it "spaghetti code with no ownership/leadership".