Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: Proposal to support multi-source apps in the UI (#17106) #17108

Merged
Binary file added docs/proposals/images/current-summary-tab.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added docs/proposals/images/helm-parameter-list.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added docs/proposals/images/new-sources-tab.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
225 changes: 225 additions & 0 deletions docs/proposals/multiple-sources-for-applications-ui.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,225 @@
---
title: Proposal for support multi-source apps in the UI
authors:
- "@keithchong"
sponsors:
- TBD
reviewers:
- "@alexmt"
- "@crenshaw-dev"
- "@ishitasequeira"
- "@jannfis"
- "@rbreeze"
approvers:
- "@jannfis"
- "@alexmt"
- "@crenshaw-dev"

creation-date: 2024-02-06
last-updated: 2024-02-06
---

# UI Support for Multiple Sources in Applications

This is the proposal for the UI changes to support multiple sources for an Application.

Related Issues:
* [Proposal: Support multiple sources for an application](https://github.com/argoproj/argo-cd/blob/master/docs/proposals/multiple-sources-for-applications.md)
* [Issue for the Proposal: Support multiple sources for an application](https://github.com/argoproj/argo-cd/issues/677)

## Summary

This is a follow-on proposal to supporting Multiple Sources for Applications, but for the UI.

The above [original](https://github.com/argoproj/argo-cd/blob/master/docs/proposals/multiple-sources-for-applications.md#changes-to-ui) ‘core’ proposal deferred
any design changes for the UI to a separate feature or secondary proposal. The proposal implementation that was made in [PR 10432](https://github.com/argoproj/argo-cd/pull/10432)
enabled the UI to tolerate multi-source applications with the new Sources field, while still supporting the original Source field.

Here are currently the restrictions and limitations of the UI when applications with multiple sources are used:
keithchong marked this conversation as resolved.
Show resolved Hide resolved

1. The application’s details page (for example [here](https://cd.apps.argoproj.io/applications/argocd/guestbook?view=tree&node=argoproj.io%2FApplication%2Fargocd%2Fguestbook%2F0&resource=))
keithchong marked this conversation as resolved.
Show resolved Hide resolved
currently shows one ApplicationSource, regardless of whether the application has one source or multiple sources. With the PR 10432 implementation, if the application has multiple sources,
the UI displays only the first one from the list of sources. Also, in particular, in the Summary tab, the source parameters are non-editable.
keithchong marked this conversation as resolved.
Show resolved Hide resolved

2. History and Rollback is disabled for multi-source applications. The button is disabled. Jorge has submitted a PR for
rollback which includes controller and UI changes [here](https://github.com/argoproj/argo-cd/pull/14124).
keithchong marked this conversation as resolved.
Show resolved Hide resolved

<img height="40%" width="40%" src="images/history-and-rollback-button.png"/>

3. The New Application dialog currently only allows users to provide one source.

Thus, multiple source applications are not considered first class citizens in the UI.

Note, see the Open Questions section for concerns regarding the priority or value of some of the above changes.
keithchong marked this conversation as resolved.
Show resolved Hide resolved

## Motivation

The motivation behind this change is to add a more complete story for the multiple source feature. The UI should support
the creation of multiple source applications, and also support the viewing and editing of parameters from all sources. The three
points in the summary above are the base or core changes that need to be addressed.

### Goals

The goals of the proposal are:

- Provide first-class support of multiple sources for applications in the UI (eg. address the aforementioned restrictions)
keithchong marked this conversation as resolved.
Show resolved Hide resolved
- Outline stages of implementation that will help ease PR review, and reduce the risk of introducing regressions/issues.


### Non-goals
* The design changes for the Argo CD CLI is beyond the scope of this proposal (The server APIs can probably be reused)

## Proposal

As mentioned in the previous summary section, the application source parameters are surfaced in the UI in three locations.
The Resource details pages, specifically, the Summary and Parameters tabs, the deployment history, and the Application
Create panel page. These pages should be updated.

### Resource Details

The following describes the current behavior and proposed changes for the Summary tab and the Parameters Tab.

#### i) Summary Tab

_Current Behavior:_

The current Summary tab includes source-related information, including the repository. For example, in Figure 1 below,
the REPO URL and PATH.

<img height="50%" width="50%" src="images/current-summary-tab.png"/>

Figure 1: The current Summary tab

_Proposed Change:_

To support multiple sources, the source-related information, from a single-source-based design, will be ‘pulled out’
and put into a new tab called **Sources**, and it will be combined with the **Parameters** tab (more details following).
The new **Sources** tab will allow users to view all the information related to each source, including the repo URL
keithchong marked this conversation as resolved.
Show resolved Hide resolved
and path, chart and revision for Helm, etc.

The view should show one source at a time (similar to what the UI is doing now, which only shows one source), but with
widgets to allow users to cycle (via pagination or combo selector?) through each source. There are API calls to retrieve
the data for each source.
Comment on lines +101 to +103
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to clarify the proposal based on what was discussed above, does this make sense?

Suggested change
The view should show one source at a time (similar to what the UI is doing now, which only shows one source), but with
widgets to allow users to cycle (via pagination or combo selector?) through each source. There are API calls to retrieve
the data for each source.
The view should show all the different sources in individual collapsible widgets with pagination to allow users to cycle through each source.
There are API calls to retrieve the data for each source.
When there is only one source is the view, it will be expanded by default. If multiple sources are defined, they will be collapsed and the user will be able to expand them and paginate based on the number of items per page and page number. The default number of item per page should be 3 and saved in the user session.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @agaudreault . Looks good. Just one comment about pagination with 3 items per page. The paginate component has hardcoded values, with 5 items per page as the minimum, then, 10, 15, 20 and All, as choices. How about keeping it at 5 items per page as the minimum, because if we add 3 as a choice (as the simplest change, and ignoring an enhancement to provide custom values), it will change all the pages that use this paginate component.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Regarding the comment "There are API calls to retrieve the data for each source": I looked into this some more and I think for better performance and usability, it should load the source details 'on demand' when the source section is expanded. Like this:

Just shortly after clicking the expand button:
LoadingOneSource

Loading complete:
LoadedOneSource

Copy link
Member

@agaudreault agaudreault Apr 8, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, I thought the default could have been configurable easily. I like the async loading, I was expecting the data to be already fetched, because it is part of the Application Manifest information, but if it needs to load something, async is definitely my preference.


<img height="50%" width="50%" src="images/new-sources-tab.png"/>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not a huge fan of this specific rendering.

  • Generally this specific widget is more commonly used at the bottom of a view (sometimes both top and bottom).
  • I don't have a better proposal at this time.
  • Sometimes drop-downs are used for this purpose, although there are definite downsides.

How many are likely? Just 3, or are 10, and 100 conceivable/likely?

Copy link
Contributor Author

@keithchong keithchong Feb 9, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @jsoref, I think there will be advantages and disadvantages as well. In the appendix, I talked about collapsible cards where each card houses the source/input parameters. But it can get unwieldy if we try to support N-number of sources.

Maybe it could end up being a combination of collapsible cards and pagination. Note that there is some time required to load the source details. So potentially, we can defer loading until the page is turned. If all cards are in the one tab, then all sources need to be loaded.

From what I was told, from the original multi-source proposal, they discussed 10 sources. But don't know what users will do.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I'm slightly more inclined to a vertical list of things on the left that one can click on, akin to: github.com/settings:
image

It's also more or less how IntelliJ and some other things manage...

But, I'm not wed to anything... This is more of a seeking scenarios.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, I agree. Good to see what scenarios there are and what people suggest. The Argo CD UI doesn't really have a 'representation' like that right now...I think. The closest thing I think is the list view of applications (and also the details list view of an application). The Applications cards represent the Source cards, but they need to be expandable and collapsible. The delete action will be on each card. And the New Source action will be at the top somewhere above the top card. So maybe for consistency, this is the way to go? I don't think it will take much effort to get this up and running.

Yeah, I agree that the IntelliJ (and also the VSCode) vertical view on the left is good, but this change will be more involved.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be difficult to add enough information about the sources in the vertical view without making each item a bigger block with multiple fields. It might be good to have 10 sources per page and a collapsible card / pop-up modal for each source.

Copy link
Contributor Author

@keithchong keithchong Feb 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

StickyTitleForSources

Here I'm taking advantage of white box's additional top space that is already defined in containers.scss.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's not bad -- although it's kinda hard to read. Could you give it a ring and opacity or something so it's easier to see?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is what I was referring to, where if you change the repo URL, or simply change the path within the repo, the input parameters and even the source type can change. So it's probably better to keep these values as separate sections. So perhaps we will need two Edit buttons, like in the screenshot below? As mentioned, for single source apps, these fields are shown in the Summary section, under a different editable section. If you change the values there, the parameters tab will be updated once you visit the tab.

multipleEditableSections

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm... Yeah, I think it makes sense to have two edit buttons because they're really very unrelated things

Copy link
Contributor Author

@keithchong keithchong Mar 1, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The initial PR changes for 'read-only' mode is here. #17275.

A lot of it is refactoring. I think we can make more progress from these changes.


Figure 2. The new SOURCES tab will allow access to view all sources and application parameters.

#### ii) Parameters Tab
_Current Behavior:_

The Parameters tab shows the application parameters for the application’s repository details type or source. These can
be Helm, Kustomize, Directory or Plugin (CMP).

_Proposed Change:_

The Parameter tab will be removed but the contents of the current parameters tab will be ‘reused’ and will be shown in
the new **SOURCES** tab as described above. The parameters and parameter values will be shown for whatever source is
selected by the user.

#### iii) Update/Edit Capability in the New Sources Tab

The above points describe how all the sources will be rendered. However, the Sources tab should be the page to allow
users to delete and add sources. (You can currently change the repo URL and path from the Summary tab, or manually edit
the application by hand, in the Manifest tab, but this is not considered as ‘guided’ editing).
keithchong marked this conversation as resolved.
Show resolved Hide resolved

_Current Behavior:_

The current form-based UI doesn’t support deleting a chosen/desired source of a multi-source application. It certainly
does not obviously support deleting the only source there is in a single-source application.
keithchong marked this conversation as resolved.
Show resolved Hide resolved

_Proposed Change:_

In addition to adding the new SOURCES tab from section i) and ii), two new buttons (_Add Source_ and _Delete Source_) will
be added to the page. For the _Add Source_ button, a separate dialog/panel will need to appear to allow the user to
input the parameters or other information.

Validation of any newly added source should prevent users from adding the same resource, and prevent users from
deleting all sources, etc.

### History and Rollback

Current Behavior: The History and Rollback button for multi-source apps is disabled. It's only enabled
for single-source apps, and shows source information as shown in Figure 3.

<img height="50%" width="50%" src="images/history-rollback-contents.png"/>

Figure 3: Source information in History

Jorge has submitted a PR for rollback which includes controller and UI changes [here](https://github.com/argoproj/argo-cd/pull/14124).
keithchong marked this conversation as resolved.
Show resolved Hide resolved
This can be treated as a separate, independent proposal.

Other related changes pertain to the Last Synced Details. The Sync Details panel needs to be updated to show sync info
ashutosh16 marked this conversation as resolved.
Show resolved Hide resolved
from multiple sources. See [Issue 13215](https://github.com/argoproj/argo-cd/issues/13215).

### New App Dialog

_Current Behavior:_

The dialog currently allows users to ‘quickly’ create a single source application..

_Proposed Changes:_

Make the form view of the dialog support adding, updating and viewing of multiple sources. The issue with the current
single source New App wizard is that it can lead to loss of “input” provided by the user. The content in the form-based
editor and the YAML editor (accessed via the Edit as YAML button) must match. If the user provides multiple sources in
the YAML editor, and then switches back to the form view, the form will only show the first source. The other sources
are effectively ‘lost’. Furthermore, if the user switches back to the YAML editor, only one source will be shown as well.

The design and changes (React components) from the new Sources tab can likely be reused in this dialog.

Other Changes. This includes the underlying plumbing to create an app using the Sources field of the Application CR, so that the
deprecated Source field can be removed in the future.



### Use cases

The use cases involves those areas in the UI where the current source is displayed. These have been described
in the Summary and Proposal sections.


### Implementation Details

The implementation plan can be divided into different stages. Read-only capability can be provided first and it will
be the safest change. The UI currently is not showing all the sources for the multi-source application so this should
be the highest priority. (Before you can edit, you have to first display it.)

Here are the general enhancements to be implemented (Upstream issues to be opened if not already):

1. Create new Sources tab to replace Parameters tab so that all sources can be displayed (Read-only)
2. Update History and Rollback to show a summary of all sources of an application
As mentioned above, this is already covered by Jorge’s [PR](https://github.com/argoproj/argo-cd/pull/14124)
3. Add _Add Source_ and _Delete Source_ buttons to Sources tab. This will depend on #1 above. (Update and Delete)
4. Update New App dialog. (Creation)
- Support adding multiple sources in New App dialog. (This will likely depend on the Components from #1 and #3)
- Use Sources field instead of Source field. Clean up code.

### Security Considerations
None

### Risks and Mitigations
None

### Upgrade / Downgrade Strategy
If downgraded, the UI will revert to showing just the first source.

## Drawbacks
None

## Open Questions

Supporting multiple sources in the New App dialog may not be ‘worth’ the effort? The drawback is that switching from the
YAML editor and form editor can lead to loss of information.
keithchong marked this conversation as resolved.
Show resolved Hide resolved

Users can simply edit the application manifest to add their sources by hand.


## Appendix
Multiple sources can be shown as a list of collapsible cards or sections, one below the other, under one page of the
SOURCES tab. However, this can be cumbersome especially when a source, like Helm, has many source parameters.
so it'll be difficult to find the desired source. Perhaps showing one source per page will be better.

Appendix Figure 1: Zoomed out view of the Helm source parameter list

<img height="50%" width="50%" src="images/helm-parameter-list.png"/>
Loading