handle flattening of cert-dir

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-name>/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,63 +38,67 @@ 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:
   address: 10.0.0.1:4001
   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
 ---
 

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.

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=<true> --global=<false> --kubeconfig=<specific_filename> --merged`
+|`openshift ex config view --config=<specific_filename>`
 |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

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.