Analysis Template

The Analysis Template is used to trigger the analysis while deploying the application. After creating the template you have to save it in the repository. This Analysis Template name should be specified in the Rollouts.yaml manifest file to trigger the analysis. For more information about Analysis Template in Argo Rollouts, refer here.
You can either create a new Analysis template or you can use the existing template as instructed below.
Create Analysis Template
Follow the procedure below to create an Analysis Template which can be specified in Rollouts.yaml manifest file.
Pre-requisites:
User needs to create the following:
​OpsMx Profile​
​OpsMx Provider Configmap​
​Service Account​
OpsMx Profile
You must create OpsMx Profile as a secret in the argo-rollouts namespace as shown below. Sample “OpsMx Profile” yaml file is available here.
Note that the values of the parameters in the data dictionary are expected to be in the base64 encoded format, as shown in the secret below.
apiVersion: v1
kind: Secret
metadata:
  name: opsmx-profile
type: Opaque
data:
  cd-integration: ZmFsc2U=
  source-name: YXJnb3JvbGxvdXRzLXByb2Q=
  gate-url: aHR0cHM6Ly9pc2QtcHJvZC5vcHNteC5uZXQ=
  user: YWRtaW4=
In the above secret update the following parameters:
Cd-integration: It can be set to either true or false.
True indicates that the environment is integrated with argo cd. 
False indicates that the environment is integrated with a standalone rollout without ArgoCD. 
source-name: It is a unique identifier of the source of the analysis execution request. The value must be kept unique among installations of argo-rollouts.
Note: If Cd-integration flag is set to true, the source name must be the same as the integration name configured in ISD. In case you are using “argocd6” as cdIntegration you would need to enter the base64 encoded value of argocd6 as the value of source-name so that the ISD instance would know the source of the request.

Refer to the image below:
gate-url: It refers to the ISD API endpoint base URL for accessing analysis services which are responsible for performing analysis. 
user: It refers to the ISD user to authorize the analysis request.
To create base64 encoded value for any parameter in the above secret, use the command below:
>>echo -n "string" | base64
For example, to create base64 encoded value for gate URL parameter “https://isd-prod.opsmx.net”, use the command below.
>>echo -n "https://isd-prod.opsmx.net" | base64
aHR0cHM6Ly9pc2QtcHJvZC5vcHNteC5uZXQ=
Apply the secret to Argo Rollouts namespace using the command below. Replace the namespace as per the environment and manifest name as per the file created.
kubectl apply -f opsmx-profile.yaml -n argo-rollouts
OpsMx Provider Configmap
You must create the “OpsMx Provider Configmap” before creating an Analysis template. To create “OpsMx Provider Configmap”, refer here.
Service Account
You must create a Service Account for the job as shown below:
For publishing the result score and report link, the job requires a basic set of permissions over Kubernetes resources in the namespace. The required structure is as follows. Sample “Service Account” yaml file is available here.
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: opsmx-provider-account 
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: opsmx-provider-account
rules:
  - apiGroups:
      - "batch"
    resources:
      - jobs/status
    verbs:
      - get
      - list
      - patch
  - apiGroups:	
      - ""	
    resources:	
      - pods	
    verbs:	
      - get	
      - list
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: opsmx-provider-account
subjects:
  - kind: ServiceAccount
    name: opsmx-provider-account
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: opsmx-provider-account
Steps to create Analysis Template:
Create the Analysis template as shown below. Specify the “OpsMx Provider Configmap” under the job section in the Analysis template. Sample “Analysis Template” is available here.
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: opsmx-analysis
spec:
  args:
    - name: canary-hash
    - name: baseline-hash
  metrics:
    - name: opsmx-analysis
      provider:
        job:
          spec:
            backoffLimit: 2
            template:
              spec:
                serviceAccountName: opsmx-provider-account
                containers:
                - name: opsmx-analysis
                  image: 'quay.io/opsmxpublic/argo-isd-metric-provider-job:v2' 
                  imagePullPolicy: Always
                  env:
                    - name: MY_POD_NAME
                      valueFrom:
                        fieldRef:
                          fieldPath: metadata.name
                    - name: STABLE_POD_HASH
                      value: "{{args.baseline-hash}}"
                    - name: LATEST_POD_HASH
                      value: "{{args.canary-hash}}"
                  volumeMounts:
                    - name: provider-config-volume
                      mountPath: /etc/config/provider
                    - name: metric-config-volume
                      mountPath: /etc/config/templates
                    - name: secret-config-volume
                      mountPath: /etc/config/secrets
                      readOnly: true
                restartPolicy: Never
                volumes:
                - name: provider-config-volume
                  configMap:
                    name: opsmx-provider-config
                - name: metric-config-volume
                  configMap:
                    name: metrixtemplates
                - name: secret-config-volume
                  secret:
                    secretName: opsmx-profile
                    optional: false
Update the following parameters in the above Analysis template:
backoffLimit: In case of any error the job will retry the specified number of times.
serviceAccountName: Name of the service account.
imagePullSecrets: Secrets in namespace to pull the image
Containers: Location of image.
env: Three mandatory environment variables are to be passed to the job pod. The ‘STABLE_POD_HASH’ and ‘CANARY_POD_HASH’ are derived from arguments passed to AnalysisTemplate. To make this configuration work, you need to pick values from podTemplateHashValue in rollout as shown below:
- analysis:
            templates:
              - templateName: opsmx-analysis
            args:
              - name: canary-hash
                valueFrom:
                  podTemplateHashValue: Latest
              - name: baseline-hash
                valueFrom:
                  podTemplateHashValue: Stable
volumeMounts:
provider-config-volume at path /etc/config/provider from Config Map. 
template-config-volume at path /etc/config/templates from Config Map.
secret-config-volume at path /etc/config/secrets from Secret.
Note: If you want to load the Log and Metric templates from ISD, do not specify the following parameters in the Analysis template.
​
     volumeMounts:
      - name: metric-config-volume
        mountPath: /etc/config/templates
​
     volumes:
      - name: metric-config-volume
        configMap:
          name: metrixtemplates
After creating the Analysis template, save this template in the repository where the Rollouts.yaml manifest file is stored. Then, you can specify the newly created template name in the Rollouts.yaml manifest file to trigger the analysis.
Use existing Analysis Template 
You can use an existing Analysis template to trigger the Analysis. The existing Analysis template will be available in the repository where the Rollouts.yaml manifest file is stored. If you want to modify the existing Analysis template, you can do the necessary changes in the existing template.
After modifying the Analysis template, save it in the repository where the Rollouts.yaml manifest file is stored.Then, specify it in the Rollouts.yaml manifest file to trigger the analysis.
Create Metric Template in Git
Deployments
Last modified 5mo ago