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

note that conversion doesn't guarantee a deepcopy #546

Open
DirectXMan12 opened this issue Jul 30, 2019 · 9 comments
Open

note that conversion doesn't guarantee a deepcopy #546

DirectXMan12 opened this issue Jul 30, 2019 · 9 comments
Labels
help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. kind/documentation Categorizes issue or PR as related to documentation. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness.
Milestone

Comments

@DirectXMan12
Copy link
Contributor

The conversion interface currently doesn't say anything about deepcopy vs no deepcopy. We should take a position on this.

cc @droot

/kind documentation

@k8s-ci-robot k8s-ci-robot added the kind/documentation Categorizes issue or PR as related to documentation. label Jul 30, 2019
@mengqiy
Copy link
Member

mengqiy commented Aug 6, 2019

The Convertible interface requires it to be a runtime.Object which implies it implements DeepCopyObject() Object. Did I miss anything?

type Convertible interface {
	runtime.Object
	ConvertTo(dst Hub) error
	ConvertFrom(src Hub) error
}

@droot
Copy link
Contributor

droot commented Aug 7, 2019

@DirectXMan12 can you elaborate more on deepcopy vs no deepcopy ?

@DirectXMan12
Copy link
Contributor Author

Right, but we don't specify if ConvertTo and ConvertFrom need to call DeepCopy themselves. Can ConvertTo and ConvertFrom safely re-use pointers to data from the source object? Is it expected that anyone who calls deepcopy doesn't care what becomes of source (this is true for conversion webhooks, but we should add a note).

TL;DR: in Rust terminology, does ConvertTo take an immutable reference to self, or does it consume self?

@fejta-bot
Copy link

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.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/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 Nov 7, 2019
@DirectXMan12
Copy link
Contributor Author

/remove-lifecycle stale
/good-first-issue

@k8s-ci-robot
Copy link
Contributor

@DirectXMan12:
This request has been marked as suitable for new contributors.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-good-first-issue command.

In response to this:

/remove-lifecycle stale
/good-first-issue

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.

@k8s-ci-robot k8s-ci-robot added good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Dec 3, 2019
DirectXMan12 pushed a commit that referenced this issue Jan 31, 2020
@vincepri vincepri removed the good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. label Feb 21, 2020
@vincepri vincepri added this to the v0.5.x milestone Feb 21, 2020
@vincepri
Copy link
Member

/help

Need to mostly add documentation.

@fejta-bot
Copy link

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.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/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 May 21, 2020
@vincepri
Copy link
Member

/lifecycle frozen

@k8s-ci-robot k8s-ci-robot added lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels May 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. kind/documentation Categorizes issue or PR as related to documentation. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness.
Projects
None yet
Development

No branches or pull requests

6 participants