diff --git a/admin_guide/master_node_configuration.adoc b/admin_guide/master_node_configuration.adoc index 19d714837f2d..6899751cbe26 100644 --- a/admin_guide/master_node_configuration.adoc +++ b/admin_guide/master_node_configuration.adoc @@ -17,16 +17,16 @@ The config files are fully specifying with no defaulting. This means that any e == Create the starting config files The `openshift start` command accepts flags that indicate that it should simply write the config file that it would have used and terminate. This is useful for getting a starting point for the config. You can do this by running -* `openshift start --writeconfig --master-config=master.yaml --node-config=node.yaml` -* `openshift start master --write-config --config=master.yaml` -* `openshift start node --write-config --config=node.yaml` +* `openshift start --write-config=openshift.local.config +* `openshift start master --write-config=openshift.local.config/master` +* `osadm create-node-config --node-dir=openshift.local.config/node-myhost --node=myhost --hostnames=myhost.local,10.0.0.1` == Use the config files Once you have modified the config files to your liking, you can make use of them by specifying them as an argument. Keep in mind that if you specify a config file, *none of the other flags you pass in will be respected*. You can run them like: -* `openshift start --master-config=master.yaml --node-config=node.yaml` -* `openshift start master --config=master.yaml` -* `openshift start node --config=node.yaml` +* `openshift start --master-config=openshift.local.config/master/master-config.yaml --node-config=openshift.local.config/node-/node-config.yaml` +* `openshift start master --config=openshift.local.config/master/master-config.yaml` +* `openshift start node --config=openshift.local.config/node-myhost/node-config.yaml` == Stub for discussion of generating the config for a new node @@ -38,26 +38,24 @@ This is an example at a point in time. You should run `--write-config` to gener --- apiVersion: v1 assetConfig: - kubernetesPublicURL: https://10.0.0.1:8443 logoutURL: "" masterPublicURL: https://10.0.0.1:8443 - publicURL: https://10.0.0.1:8444 + publicURL: https://10.0.0.1:8443/console/ servingInfo: - bindAddress: 0.0.0.0:8444 - certFile: openshift.local.certificates/master/cert.crt - clientCA: openshift.local.certificates/ca/cert.crt - keyFile: openshift.local.certificates/master/key.key + bindAddress: 0.0.0.0:8443 + certFile: master.server.crt + clientCA: "" + keyFile: master.server.key corsAllowedOrigins: -- 10.0.0.1:8444 - 10.0.0.1:8443 -- localhost - 127.0.0.1 +- localhost dnsConfig: bindAddress: 0.0.0.0:53 etcdClientInfo: - ca: openshift.local.certificates/ca/cert.crt - certFile: openshift.local.certificates/master/etcd-client.crt - keyFile: openshift.local.certificates/master/etcd-client.key + ca: ca.crt + certFile: master.etcd-client.crt + keyFile: master.etcd-client.key urls: - https://10.0.0.1:4001 etcdConfig: @@ -65,36 +63,42 @@ etcdConfig: peerAddress: 10.0.0.1:7001 peerServingInfo: bindAddress: 0.0.0.0:7001 - certFile: openshift.local.certificates/etcd/server.crt - clientCA: openshift.local.certificates/ca/cert.crt - keyFile: openshift.local.certificates/etcd/server.key + certFile: etcd.server.crt + clientCA: ca.crt + keyFile: etcd.server.key servingInfo: bindAddress: 0.0.0.0:4001 - certFile: openshift.local.certificates/etcd/server.crt - clientCA: openshift.local.certificates/ca/cert.crt - keyFile: openshift.local.certificates/etcd/server.key + certFile: etcd.server.crt + clientCA: ca.crt + keyFile: etcd.server.key storageDirectory: openshift.local.etcd imageConfig: format: openshift/origin-${component}:${version} latest: false kind: MasterConfig +kubeletClientInfo: + ca: ca.crt + certFile: master.kubelet-client.crt + keyFile: master.kubelet-client.key + port: 10250 kubernetesMasterConfig: masterIP: 10.0.0.1 - servicesSubnet: 172.30.17.0/24 + schedulerConfigFile: "" + servicesSubnet: 172.30.0.0/16 staticNodeNames: - - hostname.example.org + - deads-dev-01 masterClients: - deployerKubeConfig: openshift.local.certificates/openshift-deployer/.kubeconfig - kubernetesKubeConfig: openshift.local.certificates/kube-client/.kubeconfig - openshiftLoopbackKubeConfig: openshift.local.certificates/openshift-client/.kubeconfig + deployerKubeConfig: openshift-deployer.kubeconfig + kubernetesKubeConfig: kube-client.kubeconfig + openshiftLoopbackKubeConfig: openshift-client.kubeconfig oauthConfig: - assetPublicURL: https://10.0.0.1:8444 + assetPublicURL: https://10.0.0.1:8443/console/ grantConfig: method: auto identityProviders: - - name: anypassword - challenge: true + - challenge: true login: true + name: anypassword provider: apiVersion: v1 kind: AllowAllPasswordIdentityProvider @@ -103,46 +107,45 @@ oauthConfig: sessionConfig: sessionMaxAgeSeconds: 300 sessionName: ssn - sessionSecrets: - - authentication: 46b8abfaa1ab450624bef7f4dbb53958 - encryption: d5c11c48c49d56fa955b96c78b9ae48 + sessionSecretsFile: "" tokenConfig: - accessTokenMaxAgeSeconds: 3600 + accessTokenMaxAgeSeconds: 86400 authorizeTokenMaxAgeSeconds: 300 policyConfig: - bootstrapPolicyFile: openshift.local.policy/policy.json + bootstrapPolicyFile: policy.json masterAuthorizationNamespace: master openshiftSharedResourcesNamespace: openshift servingInfo: bindAddress: 0.0.0.0:8443 - certFile: openshift.local.certificates/master/cert.crt - clientCA: openshift.local.certificates/ca/cert.crt - keyFile: openshift.local.certificates/master/key.key + certFile: master.server.crt + clientCA: ca.crt + keyFile: master.server.key projectNodeSelector: "" - --- === Stub for discussion of what the different values actually do == Example node.yaml -This is an example at a point in time. You should run `--write-config` to generate a file of your own. +This is an example at a point in time. You should run `osadm create-node-config` to generate a file of your own. [source] --- -allowDisabledDocker: true +allowDisabledDocker: false apiVersion: v1 dnsDomain: local -dnsIP: 10.0.0.1 +dnsIP: "" +imageConfig: + format: openshift/origin-${component}:${version} + latest: false kind: NodeConfig -masterKubeConfig: openshift.local.certificates/node-hostname.example.org/.kubeconfig -networkContainerImage: openshift/origin-pod:v0.4.1 -nodeName: hostname.example.org -recordEvents: false +masterKubeConfig: node.kubeconfig +networkPluginName: "" +nodeName: myhost servingInfo: bindAddress: 0.0.0.0:10250 - certFile: openshift.local.certificates/node-hostname.example.org/server.crt - clientCA: "" - keyFile: openshift.local.certificates/node-hostname.example.org/server.key + certFile: server.crt + clientCA: node-client-ca.crt + keyFile: server.key volumeDirectory: openshift.local.volumes --- diff --git a/cli_reference/get_started_cli.adoc b/cli_reference/get_started_cli.adoc index 92166d6e175f..449ac9b9a67d 100644 --- a/cli_reference/get_started_cli.adoc +++ b/cli_reference/get_started_cli.adoc @@ -107,13 +107,9 @@ There are multiple methods that you can use to create a configuration file to be used with the CLI. The following rules are observed in order when loading CLI configuration, if the following files exist or options are specified: -. The path provided by the `--config` command line option. -. The path provided by the `*$OPENSHIFTCONFIG*` environment variable. -. The *_.openshiftconfig_* file in the current directory. -. The *_.config_* file inside the *_.config/openshift_* directory in the user's home: *_~/.config/openshift/.config_*. -. The path provided by the `*$KUBECONFIG*` environment variable. -. The *_.kubeconfig_* file in the current directory. -. The *_.kubeconfig_* file inside the *_.kube_* directory in the user's home: `~/.kube/.kubeconfig` +. The path provided by the `--config` command line option +. The paths provided by the `$OPENSHIFTCONFIG` environment variable, merged together +. The `config` file inside the `.config/openshift` directory in the user's home: `~/.config/openshift/config` You can easily link:setup_multiple_cli_profiles.html[configure and manage multiple CLI profiles] using the `osc config` command. diff --git a/cli_reference/setup_multiple_cli_profiles.adoc b/cli_reference/setup_multiple_cli_profiles.adoc index 082cab387895..1c2d26f85ec2 100644 --- a/cli_reference/setup_multiple_cli_profiles.adoc +++ b/cli_reference/setup_multiple_cli_profiles.adoc @@ -17,10 +17,6 @@ Multiple .kubeconfig files are allowed; they are loaded at runtime and merged to == Configuring .kubeconfig Files In order to more easily configure .kubeconfig files, there are a series of helpful subcommands for `openshift ex config`. -==== -The following flags are valid for all of the .kubeconfig operations: --local, --global, and --kubeconfig. -==== - .kubeconfig Operations [cols=".^2,.^5,8",options="header"] |=== @@ -52,7 +48,7 @@ The following flags are valid for all of the .kubeconfig operations: --local, -- |Unsets arbitrary value in the .kubeconfig file. |`openshift ex config view` -|`openshift ex config view --local= --global= --kubeconfig= --merged` +|`openshift ex config view --config=` |Displays the result of the specified .kubeconfig file. |=== @@ -108,18 +104,14 @@ users: auth-path: path/to/my/existing/auth-file ``` == Loading and merging rules -The rules for loading and merging .kubeconfig files are straightforward but numerous. The final config is built in the following order: - -. Merge together the .kubeconfig file. This is done with the following hierarchy and merge rules: -* Empty filenames are ignored; files with non-deserializable content produce errors. -* The first file to set a particular value or map key wins and the value or map key is never changed. As a result, the first file to set [parameter]#CurrentContext# will have its context preserved. Also, if two files specify a "red-user", only values from the first file's red-user are used. Even non-conflicting entries from the second file's "red-user" are discarded. -** CommandLineLocation: the value of the `kubeconfig` command line option. -** EnvVarLocation: the value of $KUBECONFIG -** CurrentDirectoryLocation: ``pwd``/.kubeconfig -** HomeDirectoryLocation: ~/.kube/.kubeconfig +The loading order follows these rules: + 1. If the --config flag is set, then only that file is loaded. The flag may only be set once and no merging takes place. + 2. If $OPENSHIFTCONFIG environment variable is set, then it is used a list of paths (normal path delimitting rules for your system). These paths are merged together. When a value is modified, it is modified in the file that defines the stanza. When a value is created, it is created in the first file that exists. If no files in the chain exist, then it creates the last file in the list. + 3. Otherwise, ${HOME}/.config/openshift/config is used and no merging takes place. + . Determine the context to use based on the first hit in this chain: ** Command line argument - the value of the `context` command line option. -** Current-context from the merged kubeconfig file. +** Current-context from the kubeconfig file. ** Empty is allowed at this stage. . Determine the user and cluster information to use. At this point, you may or may not have a context; they are built based on the first hit in this chain. Hint: Run it twice, once for user, once for cluster. ** Command line argument: `user` for user name and `cluster` for cluster name diff --git a/getting_started/dev_get_started/installation.adoc b/getting_started/dev_get_started/installation.adoc index 6d44c86039ba..aebf202c3740 100644 --- a/getting_started/dev_get_started/installation.adoc +++ b/getting_started/dev_get_started/installation.adoc @@ -51,8 +51,8 @@ $ sudo docker exec -it openshift-origin bash . Because OpenShift services are secured by TLS, clients must accept the server certificates and present their own client certificate. These certificates are generated when the master server is started. You must point `osc` and `curl` at the appropriate CA bundle and client key and certificate to connect to OpenShift. Set the following environment variables: + ---- -# export KUBECONFIG=/var/lib/openshift/openshift.local.certificates/admin/.kubeconfig -# export CURL_CA_BUNDLE=/var/lib/openshift/openshift.local.certificates/admin/root.crt +# export OPENSHIFTCONFIG=/var/lib/openshift/openshift.local.config/master/admin.kubeconfig +# export CURL_CA_BUNDLE=/var/lib/openshift/openshift.local.config/master/ca.crt ---- + NOTE: When running as a user other than `root`, you would also need to make the private client key readable by that user. However, this is just for example purposes; in a production environment, developers would generate their own keys and not have access to the system keys. @@ -107,9 +107,9 @@ $ ./openshift help . Because OpenShift services are secured by TLS, clients must accept the server certificates and present their own client certificate. These certificates are generated when the master server is started. You must point `osc` and `curl` at the appropriate CA bundle and client key and certificate to connect to OpenShift. Set the following environment variables: + ---- -$ export KUBECONFIG=`pwd`/openshift.local.certificates/admin/.kubeconfig -$ export CURL_CA_BUNDLE=`pwd`/openshift.local.certificates/admin/root.crt -$ sudo chmod +r `pwd`/openshift.local.certificates/admin/.kubeconfig +$ export OPENSHIFTCONFIG=`pwd`/openshift.local.config/master/admin.kubeconfig +$ export CURL_CA_BUNDLE=`pwd`/openshift.local.config/master/ca.crt +$ sudo chmod +r `pwd`/openshift.local.config/master/admin.kubeconfig ---- + NOTE: This is just for example purposes; in a production environment, developers would generate their own keys and not have access to the system keys.