Update README.md

README.md

@@ -1,3 +1,70 @@
-# SIP Cluster
+# SIP Cluster Operator
+
+## Overview
+
+The lifecycle of the VM's and their relationship to Cluster will be managed using two operators: vNode-Operator(ViNO) and the Support Infra Provider Operator (SIP) .
+
+
+## Description
 
 The SIP Cluster Operator helps identity appropriate `BareMetalHost` objects to fulfill a tenant cluster, including initial creation as well as expanding and contracting it over time.  It also helps create supporting *per-cluster* supporting infrastructure such as LoadBalancers, Jump Hosts, and so on as value added cluster services for each cluster.
+
+While ViNO is responsible for setting up VM infrastructure, such as:
+
+- per-node vino pod:
+    * libvirt init, e.g.
+        * setup vm-infra bridge
+        * provisioning tftp/dhcp definition
+    * libvirt launch
+    * sushi pod
+- libvirt domains
+- networking
+- bmh objects, with labels:
+    * location - i.e. `rack: 8` and `node: rdm8r008c002` - should follow k8s semi-standard
+    * vm role - i.e. `node-type: worker` 
+    * vm flavor - i.e `node-flavor: foobar`
+    * networks - i.e. `networks: [foo, bar]`
+and the details for ViNO can be found [here](https://hackmd.io/KSu8p4QeTc2kXIjlrso2eA) 
+
+The Cluster Support Infrastructure Provider, or SIP, is responsible for the lifecycle of:
+- identifying the correct `BareMetalHost` resources to label (or unlabel) based on scheduling constraints. 
+- extract IP address information from `BareMetalHost` objects to use in the creation of supporting infrastructure.
+- creating support infra for the tenant k8s cluster:
+    * load balancers (for tenant k8s api)
+    * jump pod to access the cluster and nodes via ssh
+    * an OIDC provider for the tenant cluster, i.e. Dex
+    * potentially more in the future
+
+## SIP Operator High level Algorithm
+
+::::info
+The expectation is that the operator will only deal with one `SIPCluster` object at a time -- in other words serially. There will be absolutely no concurrency support. This is critical to avoid race conditions. There is an expectation that all of the operations below are idempotent.
+::::
+
+Pseudo Algorithm at a high level after reading the `SIPCluster` CR:
+
+### Gather Phase
+
+#### Identity BMH VM's
+- Gather BMH's that meet the criteria expected for the groups
+- Check for existing labeled BMH's 
+- Complete the expected scheduling contraints :
+    - If master 
+        -  collect into list of bmh's to label
+    - If worker
+        - collect into list of bmh's to label
+#### Extract Info from Identified BMH
+-  identify and extract  the IP address ands other info as needed (***)
+    -  Use it as part of the service infrastucture configuration
+- At this point I have a list of BMH's, and I have the extrapolated data I need for configuring services.
+
+### Service Infrastructure Deploy Phase
+- Create or Updated the [LB|admin pod] with the appropriate configuration
+
+### Label Phase
+- Label the collected hosts.
+- At this point SIPCluster is done processing a given CR, and can move on the next.
+
+
+SIPCluster CR will exists within the Control phase for a Tenant cluster.
+