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

Implement v1beta3 api #1519

Closed
16 of 20 tasks
smarterclayton opened this issue Sep 30, 2014 · 17 comments
Closed
16 of 20 tasks

Implement v1beta3 api #1519

smarterclayton opened this issue Sep 30, 2014 · 17 comments
Assignees
Labels
area/api Indicates an issue on api area. area/client-libraries area/usability kind/design Categorizes issue or PR as related to design. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery.
Milestone

Comments

@smarterclayton
Copy link
Contributor

With #1225 merged, we can now move forward to v1beta3

Others?

@bgrant0607
Copy link
Member

We'll need a massive API doc overhaul, so I think we should resolve #1052, as well as the more specific API doc issues (#1501, #1110, #705).

@bgrant0607
Copy link
Member

Another oversight: type Container should be ContainerSpec.

@smarterclayton
Copy link
Contributor Author

Captured both in the checklist.

@bgrant0607 bgrant0607 added this to the v0.8 milestone Oct 2, 2014
@bgrant0607
Copy link
Member

Added this and related issues to milestone v0.8.

Related discussion thread: https://groups.google.com/forum/#!topic/kubernetes-dev/Y3p_fPOajWg

@smarterclayton
Copy link
Contributor Author

Should have a first chunk ready for Monday of the internal update and tests.

On Oct 4, 2014, at 5:17 PM, bgrant0607 [email protected] wrote:

Added this and related issues to milestone v0.8.

Related discussion thread: https://groups.google.com/forum/#!topic/kubernetes-dev/Y3p_fPOajWg


Reply to this email directly or view it on GitHub.

@smarterclayton
Copy link
Contributor Author

As a consequence of this change to simplify implementation, we may want to add the attributes UID and Annotations to JSONBase to allow round tripping those to the DB on older storage versions.

@smarterclayton
Copy link
Contributor Author

The serialization round tripping testing code is woefully unprepared to handle scenarios where data that is fuzzed will be lost. In general to have certainty of when / where data is lost, we need to test that the loss is detected (internal -> lossy external -> internal loses data, then clear certain fields and try again and it should not lose data).

@smarterclayton
Copy link
Contributor Author

@lavalamp fyi will add a predesign write up here on how to bulk convert objects across 1/2 - 3 in a not insane way. Will want your feedback

@smarterclayton
Copy link
Contributor Author

Changes starting to occur in #1600, still very rough.

@smarterclayton
Copy link
Contributor Author

Things I'm going to split off or farm off beforehand:

That'll reduce the total scope of the internal migration.

@smarterclayton
Copy link
Contributor Author

v1beta3 is now available in master by enabling --runtime_config=api/v1beta3 on the apiserver command line (or is on by default in the test environments). The remaining items will be covered here.

@bgrant0607
Copy link
Member

I'm willing to punt on s/Container/ContainerSpec/g. None of our subobjects (Volume, VolumeSource, ...) adhere to this convention. The status objects do/will. Maybe that's good enough.

@bgrant0607
Copy link
Member

Re.: Solve merging a v1beta1 PUT on an existing v1beta3 object

I'm willing to call this user error for now. I'd like to get rid of v1beta1.

Longer term, I like the idea of storing fields that are unrepresented in a particular API version in annotations.

@smarterclayton
Copy link
Contributor Author

Fine with me.

----- Original Message -----

Re.: Solve merging a v1beta1 PUT on an existing v1beta3 object

I'm willing to call this user error for now. I'd like to get rid of v1beta1.

Longer term, I like the idea of storing fields that are unrepresented in a
particular API version in annotations.


Reply to this email directly or view it on GitHub:
#1519 (comment)

@bgrant0607 bgrant0607 added the sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. label Feb 5, 2015
@goltermann goltermann removed this from the v0.8 milestone Feb 6, 2015
@smarterclayton smarterclayton removed this from the v0.8 milestone Feb 6, 2015
@bgrant0607 bgrant0607 modified the milestone: v1.0 Feb 6, 2015
@bgrant0607 bgrant0607 mentioned this issue Mar 14, 2015
16 tasks
@bgrant0607
Copy link
Member

I'm going to close this. v1beta3 has been implemented. Pod templates are not blocking. More specific issues have been filed for the cleanup, tracked by #5475 and #6584.

@bgrant0607
Copy link
Member

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/api Indicates an issue on api area. area/client-libraries area/usability kind/design Categorizes issue or PR as related to design. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery.
Projects
None yet
Development

No branches or pull requests

3 participants