anchor.diff:  ----
   
   === How this works?
  -For the profiles to work, by default a subdirectories will be created in *$HOME/.oc/profiles* with the profile name. A file called *$HOME/.oc/active_profile*
  +For the profiles to work, by default a subdirectory will be created in *$HOME/.oc/profiles* with the profile name. A file called *$HOME/.oc/active_profile*
   will hold also the name of the active profile, if there is a cluster up. Removing the cluster will remove the subdirectory holding all
   the profile data.
   
   We're using --host-data-config and --host-data-dir to retain the configuration of the cluster, as we understand this is basic for daily
   use of the tool. And we use --keep-config to retain this information.
   
  -We're also binding the cluster to 127.0.0.1 as this is the way to make the cluster secure, and reproducible, as ip changes when you move from network
  -to network, and since otherwise, anyone could just log into your running cluster if you had a cluster up, since it's using AnyPasswd identity provider.
  +We're also binding the cluster to 127.0.0.1 as this is the way to make the cluster secure, and reproducible, as the ip address changes when you move from network
  +to network. Also, anyone can log into your running cluster if you had a cluster up, since it's using *AnyPasswd* identity provider.
   
  -We also do 2 really convenient things for developers:
  +We also do two really convenient things for developers:
   
   * We create an *admin/admin* user that will be a *cluster-admin*, so you can login as admin from the web console
  -* We add the *sudoer* role to *system:authenticated* so that any user can do impersonate as *cluster-admin* and there's no need to change user profiles
  +* We add the *sudoer* role to *system:authenticated* so that any user can impersonate *cluster-admin* without needing to change user profiles
   
   
   == Convenience methods for working with persistent volumes
  -As probably any user will need to work with persistent services, we have added 2 convenience methods for working with volumes. One for cluster-specific
  +Most users will need to work with persistent services, so we have added two convenience methods for working with volumes. One for cluster-specific
   volumes, and another for shared volumes (similating NFS server behaviors).
   
   * oc-cluster create-volume volumeName [size|10Gi] [path|/Users/jmorales/.oc/profiles/<profile>/volumes/<volumeName>]
  
positive.code: ----
  
  == Bind to a reproducible IP
  In systems like linux or mac, you can create an link-local interface, with an static ip, that you can reuse in any place you go. There's a system environment variable
  that you can define to use this ip to bind the cluster to. Otherwise it will default to 127.0.0.1
  
  Example: 
  
negative.code: 
  === oc-cluster create-volume
  This command will create a volume in the cluster's profile. That means that if the cluster is removed, the volume and the data stored in the volume
  will be removed as well. This will create a PV of type *hostPath*, with the specified size (or 10Gi by default), on the specified path (or the default for the profile)
  and a *Retain* policy for the data.
  
  === oc-cluster create-shared-volume
  This command will create a volume in a shared location. That means that every cluster will have access to the data, and the data will not be removed if the cluster is
  removed. For the applications to be able to use this data, the created PV will be prebound to a specific project/namespace, with the same name for the volume as for the claim.
  This will create a PV of type *hostPath*, with the specified size (or 10Gi by default), on the specified path (or the default for the profile). 
  With this second mechanism, we can, as an example, share the storage for our nexus deployment between all our clusters, and use nexus for java dependency management in a very
  convenient way.
  
  = Conenience methods for adding common software to your cluster (This will be rewritten to be a plugin like mechanism in the future)
  Right now, as this tool is created to boost my productivity (and one of my colleagues), we have some additional methods (that we will convert into plugins) to
  deploy commons stuff that we use in most of our clusters. In this way, we have a method to deploy nexus in a project called ci, and soon we will have one for gitlab, workshops, etc...
  
  ----
  $ oc-cluster deploy-nexus
  