Added docs for Config and Auth & update doc workflow

Author: Bobbins228

.github/workflows/release.yaml

@@ -53,7 +53,7 @@ jobs:
             - name: Run poetry build
               run: poetry build
             - name: Create new documentation
-              run: poetry run pdoc --html -o docs src/codeflare_sdk && pushd docs && rm -rf cluster job utils && mv codeflare_sdk/* . && rm -rf codeflare_sdk && popd && find docs -type f -name "*.html" -exec bash -c "echo '' >> {}" \;
+              run: poetry run pdoc --html -o docs/detailed-documentation src/codeflare_sdk && pushd docs/detailed-documentation && rm -rf cluster job utils && mv codeflare_sdk/* . && rm -rf codeflare_sdk && popd && find docs/detailed-documentation -type f -name "*.html" -exec bash -c "echo '' >> {}" \;
 
             - name: Commit changes in docs
               uses: stefanzweifel/git-auto-commit-action@v4

README.md

@@ -17,31 +17,6 @@ Full documentation can be found [here](https://project-codeflare.github.io/codef
 
 Can be installed via `pip`: `pip install codeflare-sdk`
 
-## CodeFlare SDK in a Kubernetes environment
-To create a Ray Cluster using the CodeFlare SDK in a Kubernetes environment an `ingress_domain` must be passed in the Cluster Configuration.
-This is used for the creation of the Ray Dashboard and Client ingresses.
-
-`ingress_options` can be passed to create a custom Ray Dashboard ingress, `ingress_domain` is still a required variable for the Client ingress.
-An example of `ingress_options` would look like this.
-
-```
-ingress_options = {
-  "ingresses": [
-    {
-      "ingressName": "<ingress_name>",
-      "port": <port_number>,
-      "pathType": "<path_type>",
-      "path": "<path>",
-      "host":"<host>",
-      "annotations": {
-        "foo": "bar",
-        "foo": "bar",
-      }
-    }
-  ]
-}
-```
-
 ## Development
 
 ### Prerequisites

docs/authentication.md

@@ -0,0 +1,40 @@
+# Authentication via the CodeFlare SDK
+Currently there are four ways of authenticating to your cluster via the SDK.<br>
+Authenticating with your cluster allows you to perform actions such as creating Ray Clusters and Job Submission.
+
+## Method 1 Token Authentication
+This is how a typical user would authenticate to their cluster using `TokenAuthentication`.
+```
+from codeflare_sdk.cluster.auth import TokenAuthentication
+
+auth = TokenAuthentication(
+    token = "XXXXX",
+    server = "XXXXX",
+    skip_tls=False,
+    # ca_cert_path="/path/to/cert
+)
+auth.login()
+# log out with auth.logout()
+```
+Setting `skip_tls=True` allows interaction with an HTTPS server bypassing the server certificate checks although this is not secure.<br>
+You can pass a custom certificate to `TokenAuthentication` by using `ca_cert_path="/path/to/cert"` when authenticating provided `skip_tls=False`.
+
+## Method 2 Kubernetes Config File Authentication (Default location)
+If a user has authenticated to their cluster by alternate means e.g. run a login command like `oc login --token=<token> --server=<server>` their kubernetes config file should have updated.<br>
+If the user has not specifically authenticated through the SDK by other means such as `TokenAuthentication` then the SDK will try to use their default Kubernetes config file located at `"/HOME/.kube/config"`.
+
+## Method 3 Specifying a Kubernetes Config File
+A user can specify a config file via a different authentication class `KubeConfigFileAuthentication` for authenticating with the SDK.<br>
+This is what loading a custom config file would typically look like.
+```
+from codeflare_sdk.cluster.auth import KubeConfigFileAuthentication
+
+auth = KubeConfigFileAuthentication(
+    kube_config_path="/path/to/config",
+)
+auth.load_kube_config()
+# log out with auth.logout()
+```
+
+## Method 4 In-Cluster Authentication
+If a user does not authenticate by any of the means detailed above and does not have a config file at `"/HOME/.kube/config"` the SDK will try to authenticate with the in-cluster configuration file.

docs/cluster-configuration.md

@@ -0,0 +1,58 @@
+# Ray Cluster Configuration
+
+To create Ray Clusters using the CodeFlare SDK a cluster configuration needs to be created first.<br>
+This is what a typical cluster configuration would look like; Note: The values for CPU and Memory are at the minimum requirements for creating the Ray Cluster.
+
+```
+from codeflare_sdk.cluster.cluster import Cluster, ClusterConfiguration
+
+cluster = Cluster(ClusterConfiguration(
+    name='ray-example', # Mandatory Field
+    namespace='default', # Default None
+    head_cpus=1, # Default 2
+    head_memory=1, # Default 8
+    head_gpus=0, # Default 0
+    num_workers=1, # Default 1
+    min_cpus=1, # Default 1
+    max_cpus=1, # Default 1
+    min_memory=2, # Default 2
+    max_memory=2, # Default 2
+    num_gpus=0, # Default 0
+    mcad=True, # Default True
+    image="quay.io/project-codeflare/ray:latest-py39-cu118", # Mandatory Field
+    instascale=False, # Default False
+    machine_types=["m5.xlarge", "g4dn.xlarge"],
+    ingress_domain="example.com" # Default None, Mandatory for Kubernetes Clusters
+))
+```
+
+Upon creating a cluster configuration with `mcad=True` an appwrapper will be created featuring the Ray Cluster and any Routes, Ingresses or Secrets that are needed to be created along side it.<br>
+From there a user can call `cluster.up()` and `cluster.down()` to create and remove the appwrapper thus creating and removing the Ray Cluster.
+
+In cases where `mcad=False` a yaml file will be created with the individual Ray Cluster, Route/Ingress and Secret included.<br>
+The Ray Cluster and service will be created by KubeRay directly and the other components will be individually created.
+
+## Ray Cluster Configuration in a Kubernetes environment
+To create a Ray Cluster using the CodeFlare SDK in a Kubernetes environment an `ingress_domain` must be passed in the Cluster Configuration.
+This is used for the creation of the Ray Dashboard and Client ingresses.
+
+`ingress_options` can be passed to create a custom Ray Dashboard ingress, `ingress_domain` is still a required variable for the Client ingress.
+An example of `ingress_options` would look like this.
+
+```
+ingress_options = {
+  "ingresses": [
+    {
+      "ingressName": "<ingress_name>",
+      "port": <port_number>,
+      "pathType": "<path_type>",
+      "path": "<path>",
+      "host":"<host>",
+      "annotations": {
+        "foo": "bar",
+        "foo": "bar",
+      }
+    }
+  ]
+}
+```