Cloud Services

Enterprise Marketplace

Day2Ops
Published On Dec 17, 2024 - 1:28 PM

Day2Ops

Learn about Day20ps and initial set up.
After the initial setup, resources are managed by Day Two Operations (Day2Ops). This application lists the resource on inventory, starts it, stops it, and so on. Day2Ops includes these subapps:
  • d2ops agent:
     Takes care of the specification needed to reach the host.
  • d2ops APISs:
     Records the API path to be called by d2ops agent.
Only the Start, Stop, and Reboot functions are available unless your contract with Kyndryl specifies otherwise. If you have any questions, contact your Kyndryl sales representative.
Common Action Services supports other actions and custom actions using Ansible. For more information, see Common Action Services.

Supported operations

For all public providers, the following Standard Ops are supported for the VM resource type: 
  • TurnON
  • TurnOFF
  • Reboot
For Google Cloud Platform (GCP) with Cloud DNS service, the following Custom Operations are supported:
  • Delete Record Set
  • Add Record Set
You can also use Common Action Services to support other actions and custom actions using Ansible. For more information, see Common Action Services.
For Microsoft Azure resources onboarded through Terraform templates, some special rules apply. For more information, see Microsoft Azure Terraform template considerations.

Microsoft Azure Terraform template considerations

Microsoft Azure Day2Ops are supported for resources imported using Terraform. The following resource types are supported:
  • azurerm_linux_virtual_machine
  • azurerm_windows_virtual_machine
  • azurerm_virtual_machine
The following Standard Ops are supported for those resources:
  • TurnON
  • TurnOFF
  • Reboot
Not all resource types are supported for pricing out of the box. For more information about adding pricing information for Microsoft Azure, see Pricing in Enterprise Marketplace.
Before Microsoft Azure services onboarded using Terraform templates can be supported with Day2Ops, the feature needs to set for tenants older than March 2024. Any tenants created after this date will already have the feature enabled. The setup varies whether the tenant uses the new V3 auth model.
For tenant on the old auth model, complete these steps:
  2. Navigate to the
    ./AZURE/StandardOperations
     folder in the cloned repository.
  3. Run the following command on the tenant:
    ./azure_standard_ops.sh {endpoint} {username} {APIkey}
    . The following parameters need to be passed:
    • endpoint:
       The endpoint of tenant to which you want to enable Azure Terraform Day2Ops with
      -api
       added before
      .bridge
      . For example, change
      https://emp-ct9-sid.bridge.kyndryl.com
       to
      https://emp-ct9-sid-api.bridge.kyndryl.com
      .
    • username:
        The user that you want to use to run the command. To get this information, click the
      User
       icon and copy the listed
      User Id
      .
    • APIkey:
       The API key for the tenant. To get this information, click the
      User
       icon and then click
      Developer Console
      . On the
      Developer Console
      , click the
      API Key
       tab. Click the
      Copy
       icon for the existing key or
      Regenerate
       a new one if needed.
For tenants on the V3 auth model, complete these steps:
  2. Navigate to the
    ./AZURE/StandardOperations
     folder in the cloned repository.
  3. Run the following command on the tenant:
    ./azure_standard_ops.sh {endpoint without -api} {bearerToken}
    . The following parameters need to be passed:
    • endpoint:
       The endpoint of tenant to which you want to enable Azure Terraform Day2Ops with the
      -api
       part removed. For example, change
      https://emp-ct9-sid-api.bridge.kyndryl.com
       to
      https://emp-ct9-sid.bridge.kyndryl.com
      .
    • bearerToken:
       The bearer token for the tenant. To get this information, click the
      User
       icon and then click
      Developer Console
      . On the
      Developer Console
      , click the
      Bearer Token
       tab. Click the
      Copy
       icon for the Bearer Token.

Performing Standard Ops on stacks

To turn on, turn off, or reboot a supported stack, complete these steps:
  1. Navigate to the
    Ordered Services
     page. To learn more about navigating to the different services from each tenant, refer to Landing page navigation or Kyndryl Bridge Landing page navigation.
  2. Click the
    Down Chevron
     icon for the stack that contains the resource you want to perform a Standard Op on.
  3. From the list of resources in the stack, click the
    Actions
     icon for the one you want to change and select the action you want to take from the dropdown menu.
    The types of resources that can be affected will have a Status of
    On
     or
    Stopped (deallocated)
    .
  4. On the
    Order Submitted
     window, click
    OK
    .
You can follow the progress of the order on the
Order History
 page. Standard Ops are automatically approved. When the order is completed, the status of the resource on the
Ordered Services
 page will be updated.

Modifying a catalog

Catalog template modification can be done by making changes in the template and then re-uploading it using the
readTemplates
 script. For example, if changes are to be made to the AWS template version, the value can be changed against the field for template version. Similarly, if modifications are to be made in terms of adding/removing/updating parameters or resources, those can be done by making desired changes and then running the
readTemplates
 script. The values for all the fields get modified and are reflected in the respective couchDB table after the script is successfully executed.

Deleting a catalog

You can delete a catalog by using the Postman API, or by manually from the Couch database.

Deleting a catalog using the Postman API

A catalog can be removed from Enterprise Marketplace using the following API:
  • API: https://<gateway_host_and_port>/catalog/content/admin/sl/v1/services/<service_id>/
  • Method: DELETE
  • Headers:
    • cb-user-provider-account: <softlayer provider account added on Consume>
    • username: <Consume login user>
    • Apikey: <Apikey generated from Consume>
    • Content-Type: application/json
Example: 
curl -v -k -H "cb-user-provider-account:my_provider_account" -H "Content-Type:application/json" -H "username:[email protected]" -H "apikey:my_apikey" -X DELETE https://mytestenv.gravitant.net:8443/catalog/content/admin/sl/v1/services/FILE_STORAGE_SERVICE

Deleting a catalog manually from Couch DB

To delete a catalog manually, you need to delete files that are stored in different databases, in this example Azure and catalog. The following example shows deleting a VN catalog manually. To do so, complete these steps:
  1. Navigate to the Azure database in the Couch DB UI and search for files using following query: 
    {
"selector": {
"serviceId": "CB_AZ_ARM_VN_S00"
}
  2. Select all the files that are listed and delete them.
  3. Navigate to the Catalog database and repeat the same steps as above. 
    {
"selector": {
"serviceId": "CB_AZ_ARM_VN_S00"

Making a catalog editable

To make any catalog editable, first you need to enable the “Edit” functionality for the specific provider.
This example assumes that the below configuration saved as the
d2op_agent_api.json
 file. 
{
"configurationkey":"d2ops_agent_api",
"configurationvalue": {
     "cmdb": {
         "enabled": "true"
     },
     "importSOI": {
         "overwrite": "false"
     },
     "notification": {
         "duration": "20000"
     },
 "catalog": {
         "refresh_interval": "120"
     },
         "softlayer" :{
         "ACCESS_COMPONENT": "",
         "SERVICE_COMPONENTS" : "/adapter/sl/v2.0/serviceOfferingComponents",
         "OPERATION": "/softlayeradapter/v1/day2ops",
         "ACTION_STATUS": "",
         "RESOURCE_STATUS": "/softlayeradapter/v1/day2ops/status/{id}",
         "TRACKINGINFO_ID": "trackingId, otherKey",
         "DELETE_SERVICE":"/v2/api/services/deleteservices",
         "ADDITIONALINFO_ID": "",
         "EDIT_ENABLED":"true"
     }
 }
}
Execute the API to enable edit for IBM Cloud provider:
  • API: https://<gateway_host_and_port>/core/configuration/v1/configvalues
  • Request Body: logo.jpeg
  • Method: POST
  • Headers:
    • username: <Consume login user>
    • Apikey: <Apikey generated from Consume>
    • Content-Type:application/json
Example: 
curl -v -k -H "Content-Type:application/json" -H "username:[email protected]" -H "apikey:my_apikey" -X POST -F "@d2op_agent_api.json" https://mytestenv.gravitant.net:8443/core/configuration/v1/configvalues
After the above process is successful, edit your catalogs to include fields that can be modified. Each catalog config definition has an “editable” attribute, which when set to true allows you to edit the resource provisioned in inventory (provided that the backend Terraform provider supports it). 
"iops": {
"configName": "Storage Package",
"inputType": "selectOne",
"type": "numeric",
"editable":true,
"hidden": false,
"sequence": 5,
"required": true,
"binding": "iops",
"group": "Volume Specification",
"groupsequence": "2",
"allowedValues": {
"type": "on-view",
"resource-path": "storage/storage-services.getIopsDetails"
},
"description": "Provides the list of Storage Packages available IOPS per GB."
},
If none of the configurations of the catalog have “editable” attribute set to true, the stacks in inventory would have “Edit Service” option disabled for it.
Do you have two minutes for a quick survey?
Take Survey