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

OpenStackMachineSpec.ServerMetadata should not be a map #1684

Closed
mdbooth opened this issue Sep 26, 2023 · 5 comments · Fixed by #1828
Closed

OpenStackMachineSpec.ServerMetadata should not be a map #1684

mdbooth opened this issue Sep 26, 2023 · 5 comments · Fixed by #1828
Labels
kind/feature Categorizes issue or PR as related to a new feature.
Milestone

Comments

@mdbooth
Copy link
Contributor

mdbooth commented Sep 26, 2023

/kind feature

OpenStackMachineSpec.ServerMetadata should not be a map. To comply with k8s API conventions it should be a list of name/value pairs with listType=map.

@mdbooth mdbooth added this to the v1beta1 milestone Sep 26, 2023
@k8s-ci-robot k8s-ci-robot added the kind/feature Categorizes issue or PR as related to a new feature. label Sep 26, 2023
@EmilienM
Copy link
Contributor

EmilienM commented Nov 1, 2023

@mdbooth I was about to look at this one but I have a doubt. Should we still try to improve the API here, while in Gophercloud this is exposed as Metadata map[string]string ?

@mdbooth
Copy link
Contributor Author

mdbooth commented Nov 1, 2023

How would you improve it?

This is a breaking chance, btw, so it depends on another version bump. We're going to have to do that eventually, and before long, but we may not want to do it immediately.

@EmilienM
Copy link
Contributor

EmilienM commented Nov 1, 2023

How would you improve it?

By doing the Key Value thing, like we know of.
But my question was more on the fact that the Gophercloud interface is a map[string]string, and I wonder if I should changed that too for consistency or if we're fine with a convert here.

This is a breaking chance, btw, so it depends on another version bump. We're going to have to do that eventually, and before long, but we may not want to do it immediately.

I know and that's why I started to look at this one :-)

@k8s-triage-robot
Copy link

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

  • After 90d of inactivity, lifecycle/stale is applied
  • After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
  • After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

  • Mark this issue as fresh with /remove-lifecycle stale
  • Close this issue with /close
  • Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jan 31, 2024
@EmilienM
Copy link
Contributor

/remove-lifecycle stale
this is getting merged

@k8s-ci-robot k8s-ci-robot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jan 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants