AMBARI-26315: Ambari Web Switchable experience

[vanshuhassija]

What changes were proposed in this pull request?

A switchable experience for ambari-web modernization. The changes were made in order to have existing version as well as new version in parallel to test and very newly created flows.

How was this patch tested?

Manual Testing

[vanshuhassija]

Screen.Recording.2025-03-24.at.2.46.39.PM.mov

[himanshumaurya09876]

+1

[vanshuhassija]

@zRains Can you please help with review of this one? According to the mail thread discussion in community started by @arshadmohammad, this change will enable further development in the project without any changes required in ambari-server.

cc @JiaLiangC

[sandeep318kumar]

+1

[zRains]

This feature change involves a large number of files. Let's defer it to a later time.

[vanshuhassija]

@zRains Most of the changes are due to restructured app and are categorized as moves in the PR itself. The newly created structure is as follows
ambari-web
------| classic // Contains existing ember Js code
------| latest // Creates a React project using vite js

[chenyuan99]

hi @vanshuhassija I would encourage to reuse use the framework from the ambari-admin to reduce the duplicates of the vite generated code and take advantage of the react capability, there is no merits to maintain three seperate react frontend projects

[vanshuhassija]

@zRains @chenyuan99
Based on our initial community discussions, we proposed a "switch experience" allowing users to toggle between the classic and latest versions of Ambari Admin and Ambari Web. We are part of a team working on different features taken up voluntarily and multiple changes ready to be submitted for review.
While unifying the projects under a single tech stack promotes reusability, I recommend starting with the switch experience as two separate React applications. This allows for:
Focused Development: Isolated development enables faster, more focused iterations without being constrained by the existing codebase.
No Server-Side Changes: We can use existing APIs without altering the server-side, ensuring seamless integration.
Rapid Iteration: Developing separately allows for quick prototyping, testing, and refining based on user feedback.
Future Scope: Using the same technologies now facilitates easier future unification of the projects.

[zRains]

Thanks to @chenyuan99 and @vanshuhassija ! As mentioned by chenyuan99, we should totally lean into the perks of componentization. Combining that with the “switch experience” idea, I’d like to throw out a suggestion that I think could work nicely:

The frontend code for ambari-admin would move into ambari-web-next as a package, and the React-refactored ambari-web would also live there as its own package. Shared components (like buttons, tables, etc.) would be handled by a ui-shared package. Meanwhile, the classic ambari-web stays untouched.

Here’s how it could look:

├── ambari-admin
├── ambari-funtest
├── ambari-project
├── ambari-server
├── ambari-server-spi
├── ambari-serviceadvisor
├── ambari-utility
├── ambari-views
├── ambari-web
│   ├── api-docs
│   ├── app
│   └── ...
├── ambari-web-next
│   ├── web
│   ├── admin
│   ├── package.json
│   └── ...
├── ...
└── version

Here’s what we’d get out of it:

1. With pnpm workspace, we’re not just sharing components—we’d also share dependencies and keep versions in sync. That’d speed up dev and builds(CI/CD) time.

2. Keeping the original ambari-web as-is means we don’t have to mess with existing docs or guides (though admin might still need some tweaks). We can focus on writing fresh docs for the refactored projects.

3. Moving ambari-web would bundle in vanshuhassija’s change commits, which might make tracking issues a bit trickier. This can be avoided.

For the “switch experience,” we could tweak the URL prefix to make it happen—maybe even throw in a button for it? @chenyuan99 @vanshuhassija @arshadmohammad @nikita15p @JiaLiangC thoughts?

[vanshuhassija]

The proposed design appears promising and is expected to enhance the developer experience. Developers will be able to utilize common UI components and even the context logic. Based on the initial analysis, it seems that no server-side modifications will not be required to implement these changes. Instead, the frontend projects can be restructured to align with this concept. Most of the existing UI has been migrated from ember.js to react-js which can be re-purposed, re-used and restructured as required. if we have that available that would need less efforts.
What are your thoughts?
@chenyuan99 @zRains @arshadmohammad @vishalsuvagia @JiaLiangC

[chenyuan99]

agree. We could also take advantage of the mature ecosystem of the modern frameworks and much more flexibility in the dashboard components and layout down the line in future

[vanshuhassija]

@zRains @JiaLiangC I have unassigned the ticket initially assigned to myself. Now that the members are aligned with the design, this can be worked upon and later add switch experience to the same.

[vishalsuvagia]

+1 LGTM, @zRains , can you kindly review the patch.

The discussion here seems out of scope of the patch. we can have a separate mail discussion or in a jira ticket with the task for unification of front-end components.
Also if you kindly check here, I had asked @chenyuan99 to share a design document for the same in a jira or through a mail thread where we can discuss the pro's and con's of the approach as well as look into covering the major use cases we would like to target for unification of the same.

We are in favour of the unification of the modules, but we can achieve it easily if we have the admin and web modules migrated to react implementation.

The patch here is only adding switchable experience to a react equivalent of the existing implementation which would be anyways useful and handy when we take up the unification task(just need to move the newer implementation to a new module). A significant proportion of the re-write to react implementation has been achieved and will be shortly published for review once this patch is reviewed and merged, that would make it easier to achieve the unification task.

[zRains]

@vishalsuvagia I'll create a Jira ticket for it. This PR doesn't introduce significant changes. If it's blocking development, we can merge it. Core code won't be impacted by the project structure updates.

[zRains]

LGTM.

[nikita15p]

Thanks @zRains . I have created another ticket AMBARI-26507 for the same.
Please add more details as you think would be needed on the ticket.