Time Machine Troubleshooting Guide ---------------------------------- ---------------------------------- How is the license key for Time Machine operand (custom resource) obtained ? ---------------------------------------------------------------------------- Time Machine Floating License Server (TMFLS) needs to be used to provide licenses for each Time Machine operand (custom resource) created. It is a supplementary product that can be installed outside the cluster (but if you prefer so, it can be deployed on any of the nodes/master as well, since it is supported on both Windows and Linux OS). You can read more about this in the Time Machine Quick Start Guide, section "Application Installation". I have successfully installed Time Machine Operator. What parameters need to be updated in the yaml and what can be left as default when creating a operand (custom resource)? ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ When creating a operand (custom resource) from Time Machine operator, you are supposed to update the following in the custom resource yaml file: 1. Three environment variables as parameters pointing to Time Machine Floating License Server (TMFLS) you previously installed and licensed (as mentioned above): TM_LICHOST – IP address of the host on which TMFLS is running. TM_LICPORT – TCP port number* on which TMFLS listens for requests - by default it is 57777, if not configured otherwise. TM_LICPASS – Security Key* that must match the value configured in TMFLS. * The values for the security key and the listening port number can be configured in the TMFLS configuration file that’s located on the TMFLS host under: opt/solutionsoft/tmlicserver/conf/licserver.cf Please note that the default values for these three parameters offered in the sample yaml file (for creating a custom resource), are pointing to an actual Solution-Soft managed TMFLS in AWS cloud, which can be used for trial purposes. This TMFLS is not running by default, but can be made available upon request to support@solution-soft.com When contacting Solution-Soft to choose this option, please specify that you're using a Time Machine Operator trial offered on the Red Hat Marketplace, and provide basic information about your company. 2. Storage class – a suitable storage class that will be used for persistence volume claim creation and later adding of a shared storage to the deployment you want to be affected by virtual time. Please check with your OpenShift Cluster Administrators (cluster-admin) or Storage Administrators (storage-admin) which StorageClass objects are available to you for this purpose. The Persistence Volume Claim which will be created during the operator installation will request 50 MB of available space, and it will have ReadWriteMany access mode. You can read more about this in the Time Machine Quick Start Guide, section "Application Installation". I have licensed Time Machine operand (custom resource), how do I create virtual clocks? ------------------------------------------------------------------------------------------------------------------------------------------- In order to manage a licensed Time Machine operand (custom resource), you will need to use Time Machine Enterprise Console (TMEMC). It is a supplementary product, a Java based GUI that will allow you to create and remove virtual clocks from the desired pods/deployments, and it needs to be installed outside the cluster (on a Windows system). You can read more about this in the Time Machine Quick Start Guide, section "Application Installation". After you have TMEMC installed and licensed, you need to create a new connection in TMEMC, where the type of connection will be TMAgent, and for the connection string you need to specify the route named 'timemachine-route' generated during the custom resource creation (just copy/paste the route from the OpenShift Web Console to Connection String field in TMEMC). Once you connect to Time Machine running inside the custom resource pod, you can create/remove virtual clocks. You can read more about this in the Time Machine Quick Start Guide, section "Creating Virtual Clocks within a Namespace". I am successfully creating a virtual clock, but my application does not see virtual time. ----------------------------------------------------------------------------------------- A deployment/pod that you want to be affected by virtual clocks needs to be configured to see virtual time through the following steps: 1. Add Storage to the deployment, using the persistence volume claim created during Time Machine Operator installation (named 'timemachine-pvc'). The mount path should be: /opt/ssstm 2. Mount a ConfigMap created during Time Machine Operator installation (named 'timemachine-configmap') to the deployment. The mount path should be: /etc/ld.so.preload The subPath should be: ld.so.preload 3. Add Environment variable to the deployment, as shown below: NAME: TM_SERVER_INFO VALUE: server-info..svc.cluster.local:5777 where is the actual namespace where the deployment/pods you want affected by virtual time are. You can read more about this in the Time Machine Quick Start Guide, section "Configuring a Target Deployment to be affected by Virtual Time". How do I simultaneously time travel multiple namespaces (multiple Time Machine operands running in different namespaces)? ------------------------------------------------------------------------------------------------------------------------- If there is a need to simultaneously time travel pods across different namespaces, or to be more precise, different Time Machine deployments and the target pods configured to get virtual time from them (be it in the different or same namespace), you need to use Time Machine Sync Server (TMSS), as explained in the Time Machine Quick Start Guide, section ”Application Installation”. Please note that Time Machine Operator is installed in a specific namespace, and not on all namespaces on the cluster. If you need Time Machine Operator installed in multiple namespaces, please repeat the installation process to each of the desired namespaces. A single Time Machine operand is created in the namespace where Time Machine operator is installed, which will provide virtual time to all configured deployments in the same namespace. You can read more about this in the Time Machine Quick Start Guide, section "Simultaneously Time Travelling Multiple Namespaces and/or Automating Time Travelling via URL API". Is there an API available which I can use to automate time travelling process? ------------------------------------------------------------------------------ Time Machine Sync Server (TMSS) offers the possibility of fully automating time traveling via the built-in URL API, using any programming language that can make simple web service calls (via http or https), and automation frameworks of your choice. This also means that TMSS can be utilized even if you need to time travel deployments/pods in only one namespace, but need to automate the process. TMSS can be utilized even if you need to time travel deployments/pods in only one namespace, but need to automate the process. For more details on TMSS API, please refer to the TMSS Manual, available in TMSS installation folder, or upon request from the Solution-Soft team. Also, you can read more about this in the Time Machine Quick Start Guide. I have a question that is not covered by any of the available documents. ----------------------------------------------------------------------- Please contact Solution-Soft at support@solution-soft.com with any question you might have, regardless of wheteher you are just using a trial of Time Machine Operator, or being subscribed. Your question will asnswered promptly.