Skip to content

Conversation

rxinui
Copy link
Contributor

@rxinui rxinui commented Jun 6, 2025

Summary

The implementation of Preferences used to be on-the-fly by using corev1.ConfigMap as "k8s.io/client-go/tools/clientcmd/api" requires runtime.Object type for Extension.

In our new implementation, a new file extensions.go is created where structs are defined. This allow us Static typing and check at compilation time, reducing likelihood of errors.

BREAKING CHANGES

Within the code, breaking changes are indicated through comment // BREAKING CHANGE

const (
	ExtensionConfigName                = "config-extension-name"    // BREAKING CHANGE
	ExtensionHostingClusterContextName = "hosting-cluster-ctx-name" // BREAKING CHANGE

Those values have changed. Also, perhaps some of these values are now useless. In fact, all kubeflex metadata are stored under kubeflex key (ie. extensions.kubeflex) therefore ExtensionConfigName seems irrelevant.

Functions defined in pkg/kubeconfig/kubeconfig.go are no longer looking up to preferences.extensions within a Kubeconfig. Thereby, any clients/end-users using kflex version prior this PR has their Kubeconfig populated by Preferences. Once this PR merge to kubestellar/kubeflex, metadata stored under Preferences are ignored (hence become irrelevant) and new metadata will be inserted under extensions and contexts[].extensions. Breaking changes are to be expected for the end user.

Old way:

preferences:
  extensions:
  - extension:
      data:
        kflex-initial-ctx-name: kind-kubeflex    # key=ExtensionHostingClusterContextName
      metadata:
        creationTimestamp: null
        name: kflex-config-extension-name        # value=ExtensionConfigName
    name: kflex-config-extension-name            # value=ExtensionConfigName

New way:

# global
extensions:
- extension:
    data:
      hosting-cluster-ctx-name: kind-kubeflex    # key=ExtensionHostingClusterContextName
    metadata:
      creationTimestamp: null
      name: kubeflex                             # value=ExtensionKubeflexKey
  name: kubeflex                                 # value=ExtensionKubeflexKey
# ...
# context-scope
contexts:
- name: kind-kubeflex
  context:
    cluster: kind-kubeflex
    user: kind-kubeflex
  extensions:
  - extension:
      data:
        first-ctx-name: kind-kubeflex            # key=ExtensionInitialContextName
        is-hosting-cluster-ctx: true             # key=ExtensionContextsIsHostingCluster
      metadata:
        creationTimestamp: null
        name: kubeflex
    name: kubeflex

To alleviate those breaking changes, a follow up PR is to be considerated. The creation of a command kflex config seems ideal where subcommands interact with Kubeconfig. For instance, to help the transition to this breaking changes, we can imagine:

  • kflex config tidy to migrate/clean-up a kubeconfig to adapt with kubeflex latest changes.

Related issue(s)

Fixes #385

rxinui added 10 commits June 1, 2025 00:24
- new: implement KubeflexConfig

Signed-off-by: rxinui <rainui.ly@gmail.com>
Signed-off-by: rxinui <rainui.ly@gmail.com>
- new: kubeconfig extensions funcs are implemented
- test: extensions tests OK

Signed-off-by: rxinui <rainui.ly@gmail.com>
Signed-off-by: rxinui <rainui.ly@gmail.com>
Signed-off-by: rxinui <rainui.ly@gmail.com>
Signed-off-by: rxinui <rainui.ly@gmail.com>
Signed-off-by: rxinui <rainui.ly@gmail.com>
- ref: update SetHostingClusterContext using KubeflexConfig

Signed-off-by: rxinui <rainui.ly@gmail.com>
Signed-off-by: rxinui <rainui.ly@gmail.com>
Signed-off-by: rxinui <rainui.ly@gmail.com>
Copy link
Contributor

Hi @rxinui. Thanks for your PR.

I'm waiting for a kubestellar member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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-sigs/prow repository.

@rxinui
Copy link
Contributor Author

rxinui commented Jun 6, 2025

CC: @pdettori @dumb0002

Signed-off-by: rxinui <rainui.ly@gmail.com>
@rxinui rxinui force-pushed the main branch 2 times, most recently from af3f091 to 2c35c59 Compare June 8, 2025 04:52
- test: update ctx_test.go

Signed-off-by: rxinui <rainui.ly@gmail.com>
@rxinui
Copy link
Contributor Author

rxinui commented Jun 8, 2025

The constant ExtensionConfigName does not bring any value in the new way and in my opinion, should be totally removed as ExtensionKubeflexKey is taking over indicating clearly that such extension refers to kubeflex usage.

@pdettori
Copy link
Contributor

pdettori commented Jun 9, 2025

/ok-to-test

Copy link
Contributor

@pdettori pdettori left a comment

Choose a reason for hiding this comment

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

Overall looks good, I have couple of general comments I think would be best to address before merging:

  1. Since this is a breaking change, it would be helpful adding a script or command to migrate old kubeconfig extensions to the new format, or at least provide documentation about this breaking change and how the user can migrate (even by manually editing the file if no automation is provided)

  2. Should add some text to README or release notes to explain the new extension mechanism, breaking changes, and manual steps required by users.

return err
}
return nil
}
Copy link
Contributor

Choose a reason for hiding this comment

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

I think the code assumes all kubeconfig for Kubeflex have well-formed KubeflexExtensions objects under the extensions key. If a user manually edits kubeconfig, or if there are partial/invalid extension values, code may panic or behave unexpectedly.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

True. What should we do then? Isn't a panic a good situation to act as such?

Copy link
Contributor

Choose a reason for hiding this comment

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

yes, as long as the user understands what caused it

}

// TODO: the signature is confusing. It switches context but expect controlPlane name as parameter
// NOTE: Perhaps SwitchContext should only switch context to a context name
// NOTE: Create a new function SwitchToControlPlaneContext to find a context using control plane name
Copy link
Contributor

Choose a reason for hiding this comment

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

Agreed - that would be more clear

@rxinui
Copy link
Contributor Author

rxinui commented Jun 9, 2025

1. Since this is a breaking change, it would be helpful adding a script or command to migrate old kubeconfig extensions to the new format, or at least provide documentation about this breaking change and how the user can migrate (even by manually editing the file if no automation is provided)

The migration would be part of the issue #389 - therefore, i would like to favour documentation for a manual change.

- new: kflex prints warning message about breaking changes

Signed-off-by: rxinui <rainui.ly@gmail.com>
@@ -1,5 +1,54 @@
# User's Guide

## Breaking changes
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@pdettori I have added this section to describe the breaking changes what needs to be done by the end-user.

Copy link
Contributor

Choose a reason for hiding this comment

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

looks good, thx

func main() {
// TODO - find a way to inject it using Makefile
common.WarningMessage = "WARNING: current kflex version introduces BREAKING CHANGES related to kflex and your kubeconfig file which may interrupt kflex to function properly.\nSee https://github.com/kubestellar/kubeflex/blob/main/docs/users.md"
Copy link
Contributor Author

@rxinui rxinui Jun 9, 2025

Choose a reason for hiding this comment

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

@pdettori Everytime kflex is ran, a YELLOW WARNING message will be displayed to indicate the user about breaking changes, with a URL pointing to the end-user documentation.

Ideally, I wanted to inject the message within the Makefile but it is rather complicated to do it. So I fallback in Go for now.

Perhaps it is a sign to move to https://taskfile.dev/usage/

Copy link
Contributor

Choose a reason for hiding this comment

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

great, thx

@pdettori
Copy link
Contributor

pdettori commented Jun 9, 2025

/lgtm

Copy link
Contributor

LGTM label has been added.

Git tree hash: 5363a70b42e260c5f6e0f8d9de9ddd4136fc9217

@pdettori
Copy link
Contributor

pdettori commented Jun 9, 2025

/approve

Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: pdettori

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@kubestellar-prow kubestellar-prow bot merged commit 26f7294 into kubestellar:main Jun 9, 2025
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

feature: move away from Preferences to Extensions
2 participants