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

DeploymentConfig replicas should be optional, other fields too #17035

Merged
merged 1 commit into from
Oct 31, 2017

Conversation

smarterclayton
Copy link
Contributor

Make a set of fields truly optional in openapi, and also make replicas a
pointer so we can default it.

Found this when I tried to use --validate - these were a bunch of obvious things.

@openshift-ci-robot openshift-ci-robot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Oct 25, 2017
@openshift-merge-robot openshift-merge-robot added approved Indicates a PR has been approved by an approver from all required OWNERS files. needs-api-review labels Oct 25, 2017
@smarterclayton
Copy link
Contributor Author

@openshift/sig-master

@smarterclayton smarterclayton added kind/bug Categorizes issue or PR as related to a bug. api-approved and removed needs-api-review labels Oct 25, 2017
@smarterclayton
Copy link
Contributor Author

@tnozicka @mfojtik @bparees

@bparees
Copy link
Contributor

bparees commented Oct 25, 2017

imageapi changes lgtm.

Triggers DeploymentTriggerPolicies `json:"triggers" protobuf:"bytes,2,rep,name=triggers"`

// Replicas is the number of desired replicas.
Replicas int32 `json:"replicas" protobuf:"varint,3,opt,name=replicas"`
// +optional
Replicas *int32 `json:"replicas" protobuf:"varint,3,opt,name=replicas"`
Copy link
Contributor

Choose a reason for hiding this comment

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

@smarterclayton how is this not a breaking change?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The value still defaults. No client ever sees this being null. You can make a required field not required as long as you provide a default.

Copy link
Contributor

Choose a reason for hiding this comment

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

It will break everyone using our Go client :/

But I guess on the pure API front the serialization will go fine when we default unless client is able to see the object before defaulting happens (say with GetOptions.IncludeUninitialized) but I think we initialize before storing the object.

Copy link
Contributor

@liggitt liggitt Oct 25, 2017

Choose a reason for hiding this comment

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

it will break everyone using our Go client :/

we don't have a supported go client yet.

But I guess on the pure API front the serialization will go fine when we default

yes

unless client is able to see the object before defaulting happens

it cannot

Copy link
Contributor

Choose a reason for hiding this comment

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

we don't have a supported go client yet.

so we don't "support" client/clientsets in origin codebase? because people use that...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We don't guarantee they don't change. Users have to track updates to code.

@smarterclayton
Copy link
Contributor Author

@liggitt can you sanity check this? trying to be consistent with upstream, i'm fairly certain this is safe but want the double check

@@ -24,6 +26,7 @@ func TestDefaults(t *testing.T) {
original: &DeploymentConfig{},
expected: &DeploymentConfig{
Spec: DeploymentConfigSpec{
Replicas: &one,
Copy link
Contributor

Choose a reason for hiding this comment

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

doesn't this mean the default changed from 0 to 1?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, I suppose there may be people who rely on that. Something we should have fixed during 3.6, but forgot. Going to back this out.

@@ -33,12 +33,13 @@ type DeploymentConfig struct {
Spec DeploymentConfigSpec `json:"spec" protobuf:"bytes,2,opt,name=spec"`

// Status represents the current deployment state.
Status DeploymentConfigStatus `json:"status" protobuf:"bytes,3,opt,name=status"`
Status DeploymentConfigStatus `json:"status,omitempty" protobuf:"bytes,3,opt,name=status"`
Copy link
Contributor

Choose a reason for hiding this comment

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

doesn't do anything on a struct. does that matter?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No, just using it as the canonical optional and "eventually someone will fix go json to not suck"

Make a set of fields truly optional in openapi, and also make replicas a
pointer so we can default it.
@openshift-ci-robot openshift-ci-robot added size/M Denotes a PR that changes 30-99 lines, ignoring generated files. and removed size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Oct 27, 2017
@smarterclayton
Copy link
Contributor Author

/retest

@smarterclayton
Copy link
Contributor Author

Any other comments?

/kind bug

@liggitt
Copy link
Contributor

liggitt commented Oct 30, 2017

/lgtm

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Oct 30, 2017
@openshift-merge-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: liggitt, smarterclayton

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

Needs approval from an approver in each of these OWNERS Files:
  • OWNERS [liggitt,smarterclayton]

You can indicate your approval by writing /approve in a comment
You can cancel your approval by writing /approve cancel in a comment

@openshift-bot
Copy link
Contributor

/retest

Please review the full test history for this PR and help us cut down flakes.

@smarterclayton
Copy link
Contributor Author

/retest

@openshift-merge-robot
Copy link
Contributor

Automatic merge from submit-queue.

@openshift-merge-robot openshift-merge-robot merged commit 2e33f3f into openshift:master Oct 31, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api-approved approved Indicates a PR has been approved by an approver from all required OWNERS files. kind/bug Categorizes issue or PR as related to a bug. lgtm Indicates that a PR is ready to be merged. needs-api-review size/M Denotes a PR that changes 30-99 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants