Dashboard UI Implementation for Secrets

[kimholmes]

Expected Behavior

The portion of the Dashboard UI for Secrets should use design patterns and components for Carbon 10 and reflect the user experience created through collaboration between Development, Design and User Research

Actual Behavior

The actual behavior is found in the current implementation of the Dashboard UI

Design Specs:

Secrets Main List View

(Done)

Specs: https://kimholmes.github.io/Exported-Specs/Secrets/Secrets_Main/

Secrets - Create

(Done)

Screen 1:
https://kimholmes.github.io/Exported-Specs/Secrets/Secrets_Create1/
Screen2:
https://kimholmes.github.io/Exported-Specs/Secrets/Secrets_Create/index.html#artboard2
Screen3:
https://kimholmes.github.io/Exported-Specs/Secrets/Secrets_Create/index.html#artboard1
Screen4:
https://kimholmes.github.io/Exported-Specs/Secrets/Secrets_Create/index.html#artboard3

Secrets - Detail View

Specs: https://kimholmes.github.io/Exported-Specs/Secrets/Secrets_Detail/Secrets_Detail1/

Edit Mode:
Specs: https://kimholmes.github.io/Exported-Specs/Secrets/Secrets_Detail/Secrets_DetailEdit/

[kimholmes]

@AlanGreene

[kimholmes]

FYI - They may not keep the Image Pull Secrets

[ncskier]

For reference, here's the issue investigating the use of Image Pull Secrets: #757

[kimholmes]

Updated the specs above with the changes to the annotation design in "Create" mode.

[carlos-logro]

Based on the issue that Alan referenced aboved, the wire frames should be updated to include the service account name.

[AlanGreene]

@carlos-logro I simply referenced the 2 currently open design issues related to service accounts and secrets so this request could be discussed/considered as part of that work.

There are some technical considerations we should be aware of, such as how we can identify which service accounts a given secret is patched onto? Currently the connection is one way, in the opposite direction (service account holds record of which secrets are patched onto it). Other than retrieving all service accounts and checking if the selected secret is patched onto any of them do we have a way of building this list? If not, is the overhead acceptable?

[carlos-logro]

I just checked this and I can confirm what you said about it being in an opposite direction. It can be done by building the list but its kinda inefficient given that we'll need to loop through the SAs, and during that loop iterate through each respective list of secrets. Finally we need to loop through the secrets to make the output for the table so in short to render the table properly three loops has to happen.

[carlos-logro]

@AlanGreene here is a draft approach:
serviceAccounts fetched from store with reducer

const secretsFormatted = secrets.map(secret => {
      let annotations = '';
      if (secret.annotations !== undefined) {
        Object.keys(secret.annotations).forEach(function annotationSetup(key) {
          if (key.includes('tekton.dev')) {
            annotations += `${key}: ${secret.annotations[key]}\n`;
          }
        });
      }
      const secretSA = [];
      serviceAccounts.forEach(sa => {
        sa.secrets.forEach(saSecret => {
          if (saSecret.name === secret.name) {
            secretSA.push(sa.metadata.name);
          }
        });
      });
      const formattedSecret = {
        annotations,
        id: `${secret.namespace}:${secret.name}`,
        namespace: secret.namespace,
        name: secret.name,
        sa: secretSA.join(',')
      };

      return formattedSecret;
    });

[carrenelloyd]

@carlos-logro @kimholmes

Redlines for Secrets posted here: https://ibm.invisionapp.com/share/MPNZNGNZJ3E

Original high-fis here: https://ibm.invisionapp.com/share/EMNZB7QKZAT

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[AlanGreene]

/remove-lifecycle stale

[AlanGreene]

No further work planned for either secrets or service accounts at the moment. We can revisit these designs in future if this changes.

/close

[tekton-robot]

@AlanGreene: Closing this issue.

In response to this:

No further work planned for either secrets or service accounts at the moment. We can revisit these designs in future if this changes.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.