Error while doing "oc replace -f service.json" for a service

[jorgemoralespou]

When doing an "oc replace -f myservice.json" with a service defined in a json file, I get the following error:

Error from server: Service "example-wildfly-addons" is invalid: spec.clusterIP: Invalid value: "": field is immutable

[jorgemoralespou]

Definition of my service is:

    {
      "kind": "Service",
      "apiVersion": "v1",
      "metadata": {
        "name": "example-wildfly-addons",
        "labels": {
          "app": "example-wildfly-addons"
        }
      },
      "spec": {
        "ports": [
          {
            "name": "8080-tcp",
            "protocol": "TCP",
            "port": 8080,
            "targetPort": 8080
          }
        ],
        "selector": {
          "deploymentconfig": "example-wildfly-addons"
        },
        "type": "ClusterIP",
        "sessionAffinity": "None"
      }
    }

[deads2k]

oc replace is attempting to use the file content for the replacement, but
fields on the resource you created were defaulted and changed by
controllers. That means that directly replacing your object yields a
different object and its running afoul of object validation. If the
validation didn't protect you from changing that field, then you'd end up
with every reference to your previous service by IP suddenly breaking,
which probably isn't what you want.

I think that oc apply was intended for this purpose. oc apply -f <>
should do a create if the object doesn't exist and a replacement of the
fields you set if it does. I will warn you that there have been multiple
issues opened upstream about it, so I don't know how reliable it is.

On Wed, Apr 6, 2016 at 12:31 PM, Jorge Morales Pou <[email protected]

wrote:

Definition of my service is:

{
  "kind": "Service",
  "apiVersion": "v1",
  "metadata": {
    "name": "example-wildfly-addons",
    "labels": {
      "app": "example-wildfly-addons"
    }
  },
  "spec": {
    "ports": [
      {
        "name": "8080-tcp",
        "protocol": "TCP",
        "port": 8080,
        "targetPort": 8080
      }
    ],
    "selector": {
      "deploymentconfig": "example-wildfly-addons"
    },
    "type": "ClusterIP",
    "sessionAffinity": "None"
  }
}

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#8387 (comment)

[deads2k]

Speak of the devil. Looks like some kinds of services are broken when
using apply: kubernetes/kubernetes#23551.

On Wed, Apr 6, 2016 at 1:08 PM, David Eads [email protected] wrote:

oc replace is attempting to use the file content for the replacement,
but fields on the resource you created were defaulted and changed by
controllers. That means that directly replacing your object yields a
different object and its running afoul of object validation. If the
validation didn't protect you from changing that field, then you'd end up
with every reference to your previous service by IP suddenly breaking,
which probably isn't what you want.

I think that oc apply was intended for this purpose. oc apply -f <>
should do a create if the object doesn't exist and a replacement of the
fields you set if it does. I will warn you that there have been multiple
issues opened upstream about it, so I don't know how reliable it is.

On Wed, Apr 6, 2016 at 12:31 PM, Jorge Morales Pou <
[email protected]> wrote:

Definition of my service is:

{
  "kind": "Service",
  "apiVersion": "v1",
  "metadata": {
    "name": "example-wildfly-addons",
    "labels": {
      "app": "example-wildfly-addons"
    }
  },
  "spec": {
    "ports": [
      {
        "name": "8080-tcp",
        "protocol": "TCP",
        "port": 8080,
        "targetPort": 8080
      }
    ],
    "selector": {
      "deploymentconfig": "example-wildfly-addons"
    },
    "type": "ClusterIP",
    "sessionAffinity": "None"
  }
}

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#8387 (comment)

[jorgemoralespou]

@deads2k I guess that "oc replace" should then have better documentation and failure behavior.

I've looked up the docs and there's no usage of oc apply (not even here: https://docs.openshift.org/latest/cli_reference/basic_cli_operations.html), but I've found usages of "oc replace".

• https://docs.openshift.org/latest/install_config/upgrading/manual_upgrades.html#updating-the-default-image-streams-and-templates
• https://docs.openshift.org/latest/install_config/install/docker_registry.html#production-use

[deads2k]

@deads2k I guess that "oc replace" should then have better documentation and failure behavior.

Can you help describe what's missing in the docs for replace? You tried to replace an object by mutating an immutable field and got a message that the field was immutable. The help on replace does mention the --force flag to attempt to "replace-ish at all cost by deleting and recreating the object".

[jorgemoralespou]

@deads2k I used replace as there was no information about apply (which is really what I wanted). There's already an open bug in openshift-docs for it. openshift/openshift-docs#1867 and openshift/openshift-docs#1868.

Also, looking at the json I passed along, I didn't set clusterIp explicitly, so I would look into some documentation stating what you described in your previous answer. That some fields are defaulted, then changed by controllers, and hence the error can be seen. And that --force will delete and recreate the object. An also, I would link to apply as to "Maybe is apply what you want to do".

[0xmichalis]

upstream issue: kubernetes/kubernetes#24040

[0xmichalis]

Copying from upstream:

replace is a full replacement, not a patch. It is invalid to change ClusterIP, and in this case you are changing it from a value to "". To replace a Service you really have to do an R-M-W cycle. Get it, apply mutations, then write it back.

If docs need to be updated, please open an issue in https://github.com/openshift/openshift-docs