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

feat: add configmaps & secrets to kubernetes #7681

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

cdrage
Copy link
Contributor

@cdrage cdrage commented Jun 17, 2024

feat: add configmaps & secrets to kubernetes

What does this PR do?

  • Adds ConfigMaps and Secrets to Kubernetes
  • Ability to delete / view / edit both configmap and secrets

Screenshot / video of UI

Screenshot 2024-06-17 at 4 24 23 PM

Screen.Recording.2024-06-17.at.4.23.56.PM.mov

What issues does this PR fix or reference?

Closes #7342
Closes #7190 (its the last part of it)

How to test this PR?

  • Tests are covering the bug fix or the new feature
  1. Create a ConfigMap and Secrets on your k8s cluster.
  2. Delete / Edit / View them

Signed-off-by: Charlie Drage [email protected]

@cdrage cdrage requested review from benoitf and a team as code owners June 17, 2024 20:29
@cdrage cdrage requested review from jeffmaury and feloy and removed request for a team June 17, 2024 20:29
@cdrage
Copy link
Contributor Author

cdrage commented Jun 17, 2024

FYI the icon is the "rocket" temporary until #7680 has a PR.

Apologizes for the large PR! Tried splitting it up a bit, but a lot of the tests are intertwined.

Most of this code is very similar to #7640 however.

Copy link
Collaborator

@deboer-tim deboer-tim left a comment

Choose a reason for hiding this comment

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

Code worked fine for me in testing and added a few comments, but this PR is so massive that I haven't gone through it all. Parts of this really should be broken out so that we can review and merge independently.

@@ -34,11 +35,13 @@ import { contributions } from './stores/contribs';
import { imagesInfos } from './stores/images';
import { kubernetesContexts } from './stores/kubernetes-contexts';
import {
kubernetesCurrentContextConfigMapsFiltered,
Copy link
Collaborator

Choose a reason for hiding this comment

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

Should be the unfiltered, not the filtered store here.

kubernetesCurrentContextDeployments,
kubernetesCurrentContextIngresses,
kubernetesCurrentContextNodes,
kubernetesCurrentContextPersistentVolumeClaims,
kubernetesCurrentContextRoutes,
kubernetesCurrentContextSecretsFiltered,
Copy link
Collaborator

Choose a reason for hiding this comment

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

Should be the unfiltered, not the filtered store here.

@@ -0,0 +1,27 @@
/**********************************************************************
* Copyright (C) 2023 Red Hat, Inc.
Copy link
Collaborator

Choose a reason for hiding this comment

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

2024

if (isSecret) {
await window.kubernetesDeleteSecret(configmapSecret.name);
} else {
await window.kubernetesDeleteConfigMap((configmapSecret as ConfigMapSecretUI).name);
Copy link
Collaborator

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 worth the readability/type checking if you created a configmapSecretUtils.isConfigMap() and just turned this into a configmapSecretUtils.isSecret() {...} else if configmapSecretUtils.isConfigMap() {...}

Copy link
Collaborator

Choose a reason for hiding this comment

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

I think you can remove the as ConfigMapSecretUI now?

@@ -3,12 +3,13 @@ import { Tooltip } from '@podman-desktop/ui-svelte';

export let name = '';
export let tip = '';
export let capitalize = true;
Copy link
Collaborator

Choose a reason for hiding this comment

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

I went with 'capitalize on' because it was on the first instance I made a component out of, but most of the files that have used it since haven't needed this. As a component I wonder if it's better if capitalize is off by default, i.e. an optional feature instead.

Copy link
Collaborator

Choose a reason for hiding this comment

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

This was delivered via #7788, can remove it here.

@@ -1157,6 +1157,17 @@ export class ColorRegistry {
dark: colorPalette.gray[100],
light: colorPalette.gray[400],
});
// If it's considered "good" (like a successful operation), use green
this.registerColor(`${status}good`, {
Copy link
Collaborator

Choose a reason for hiding this comment

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

To me there's a disconnect between the name 'good' and the actual use 'config map exists'. I think we should either just use an existing color (e.g. 'updated' from #7526) or name it something more generic like (object) 'exists'.

});
// If it's "secure" (like a successful TLS connection), use yellow
// as often keys are yellow in the real world / "caution" / padlock colour uses on other GUIs
this.registerColor(`${status}secure`, {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Amber is more of a warning color than a yellow lock. I think @ekidneyrh should weigh in on what color 'secure' is, whether we need another color in the palette or should just use 'status-connected' (green 600).

If we do go the route of a 'secure' color different from connected, I'd wonder if Log In or other places should use that instead of -connected.

@cdrage
Copy link
Contributor Author

cdrage commented Jun 18, 2024

@deboer-tim I've updated the PR with a new commit with the suggested changes:

  • Added isConfigMap / made the if statements more intuitive
  • Use green for the "running" / working configmap and secret.
  • Updated the incorrect filtered areas

Still unsure what to do with Label? I guess another PR / issue, since removing the capitalization will affect other parts of PD.


// If it is a configMap, then it will **not** have a type property
isConfigMap(storage: V1ConfigMap | V1Secret): storage is V1ConfigMap {
return !('type' in storage);
Copy link
Collaborator

Choose a reason for hiding this comment

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

It would probably be better to have a 'positive' check for something unique about config map vs 'it's not a secret' 😆. Is there nothing that's only in configmap?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

actually yes! I'll update it to also check for 'binaryData' too.

if (isSecret) {
await window.kubernetesDeleteSecret(configmapSecret.name);
} else {
await window.kubernetesDeleteConfigMap((configmapSecret as ConfigMapSecretUI).name);
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think you can remove the as ConfigMapSecretUI now?

@@ -0,0 +1,56 @@
/**********************************************************************
* Copyright (C) 2023 Red Hat, Inc.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Should be 2024

@feloy
Copy link
Contributor

feloy commented Jun 19, 2024

configmaps-list

The values in the Type column for secrets are the ones displayed in kubectl get secret, but I would prefer to have the ones used when using kubectl create secret <type> (docker-registry, generic or tls). WDYT?

For specific secrets (docker, tls), I wonder if we need to display the keys, as they are standard (and not really useful to the user).

kubectl get cm / secret display the number of data, without the names of the keys. I wonder if it is relevant to display the key names in the list, as it can easily be unreadable

@feloy
Copy link
Contributor

feloy commented Jun 19, 2024

configmap-details

I would prefer to have the display of the data moved up one level:

Details

Type      Opaque
Immutable  No


Data

key1       value1
key2       value2
key3       value3
key4       value4
key5       value5

@cdrage
Copy link
Contributor Author

cdrage commented Jun 19, 2024

Thank you for the suggestions @feloy I agree. Having keys on there is not ideal. Other GUI's do it, but because of our spacin and simplicity it's nice to say the length / how many rather than every name of the key..

I've updated the UI with the "Summary" changes as well as the list changes. I agree it looks a lot better.

Screenshot 2024-06-19 at 2 10 40 PM
Screenshot 2024-06-19 at 2 10 54 PM

@cdrage
Copy link
Contributor Author

cdrage commented Jun 19, 2024

Screenshot 2024-06-19 at 4 36 14 PM
Updated so now they are on newlines @feloy

@cdrage cdrage force-pushed the add-configmaps-secrets branch 3 times, most recently from 7d5e1e9 to 04d2da1 Compare June 19, 2024 23:04
### What does this PR do?

* Adds ConfigMaps and Secrets to Kubernetes
* Ability to delete / view / edit both configmap and secrets

### Screenshot / video of UI

<!-- If this PR is changing UI, please include
screenshots or screencasts showing the difference -->

### What issues does this PR fix or reference?

<!-- Include any related issues from Podman Desktop
repository (or from another issue tracker). -->

Closes containers#7342
Closes containers#7190

### How to test this PR?

<!-- Please explain steps to verify the functionality,
do not forget to provide unit/component tests -->

- [X] Tests are covering the bug fix or the new feature

1. Create a ConfigMap and Secrets on your k8s cluster.
2. Delete / Edit / View them

Signed-off-by: Charlie Drage <[email protected]>
Signed-off-by: Charlie Drage <[email protected]>
Signed-off-by: Charlie Drage <[email protected]>
Signed-off-by: Charlie Drage <[email protected]>
Signed-off-by: Charlie Drage <[email protected]>
deboer-tim added a commit to deboer-tim/desktop that referenced this pull request Jun 23, 2024
When creating Label I left 'capitalize' the default because the first
Label (ProviderInfo) needed it, but none of the other instances do.
PR containers#7681 it requires no capitalization so this just separates that out
- making capitalization off by default and only used by the one use
that requires it, ProviderInfo.

Prereq of containers#7681.

Signed-off-by: Tim deBoer <[email protected]>
deboer-tim added a commit that referenced this pull request Jun 24, 2024
When creating Label I left 'capitalize' the default because the first
Label (ProviderInfo) needed it, but none of the other instances do.
PR #7681 it requires no capitalization so this just separates that out
- making capitalization off by default and only used by the one use
that requires it, ProviderInfo.

Prereq of #7681.

Signed-off-by: Tim deBoer <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants