Converting/Migrating from one Custom Resource to another

[mittachaitu]

Can metac provide a way to convert from one custom resource to another custom resource(Note: Two custom resources have their own controllers) .

Below is just an example for understanding purpose.
Currently I have StoragePoolClaim custom resource and it's looks like below

apiVersion: abc.io/v1alpha1
kind: StoragePoolClaim
metadata:
  name: cstor-storage
  annotations:
    cas.abc.io/config: |
      - name: PoolResourceRequests
        value: |-
            memory: 2Gi
      - name: PoolResourceLimits
        value: |-
            memory: 4Gi
spec:
  name: cstor-storage
  type: disk
  maxPools: 3
  poolSpec:
    poolType: mirrored
  blockDevices:
    blockDeviceList:
    - blockdevice-979c65d8a35ad99710c519ec4db7cd17
    - blockdevice-defda08fd3e67466b38aa48bb5c106a2
    - blockdevice-7ab6d86f35ad9a416eb4e4f2f2cee947
    - blockdevice-f9a4994473e86f7647550aa8bcfef4ea
    - blockdevice-a28f2bcaefea524ee81b83c8aec1ca1b
    - blockdevice-d1270840f212a7082c94e503ea93e7ea

Due to some reason enhanced the above schema and made new CustomResource.
Below is sample YAML

 apiVersion: v1
 items:
 - apiVersion: abc.io/v1alpha1
   kind: CStorPoolCluster
   metadata:
     creationTimestamp: "2019-12-10T00:25:49Z"
     finalizers:
     - cstorpoolcluster.abc.io/finalizer
     generation: 3
     name: cstor-cspc-disk-pool
     namespace: abc
     resourceVersion: "622553"
     uid: 9dd846f2-1ae3-11ea-83b9-42010a800111
   spec:
     auxResources: {}
     pools:
     - nodeSelector:
         kubernetes.io/hostname: gke-giri-default-pool-de28c87d-qtxw
       poolConfig:
         cacheFile: ""
         compression: "off"
         defaultRaidGroupType: mirror
         overProvisioning: false
       raidGroups:
       - blockDevices:
         - blockDeviceName: blockdevice-d1270840f212a7082c94e503ea93e7ea
           capacity: ""
           devLink: ""
         - blockDeviceName: blockdevice-a28f2bcaefea524ee81b83c8aec1ca1b
           capacity: ""
           devLink: ""
         isReadCache: false
         isSpare: false
         isWriteCache: false
         type: mirror
     - nodeSelector:
         kubernetes.io/hostname: gke-giri-default-pool-de28c87d-qt29
       poolConfig:
         cacheFile: ""
         compression: "off"
         defaultRaidGroupType: mirror
         overProvisioning: false
       raidGroups:
       - blockDevices:
         - blockDeviceName: blockdevice-f9a4994473e86f7647550aa8bcfef4ea
           capacity: ""
           devLink: ""
         - blockDeviceName: blockdevice-7ab6d86f35ad9a416eb4e4f2f2cee947
           capacity: ""
           devLink: ""
         isReadCache: false
         isSpare: false
         isWriteCache: false
         type: mirror
     - nodeSelector:
         kubernetes.io/hostname: gke-giri-default-pool-de28c87d-9lwg
       poolConfig:
         cacheFile: ""
         compression: "off"
         defaultRaidGroupType: mirror
         overProvisioning: false
       raidGroups:
       - blockDevices:
         - blockDeviceName: blockdevice-defda08fd3e67466b38aa48bb5c106a2
           capacity: ""
           devLink: ""
         - blockDeviceName: blockdevice-979c65d8a35ad99710c519ec4db7cd17
           capacity: ""
           devLink: ""
         isReadCache: false
         isSpare: false
         isWriteCache: false
         type: mirror
     resources: null
   status:

Can we achieve above migration via metac.

[AmitKumarDas]

Thanks @mittachaitu . Lets see if a sample/example can be implemented at https://github.com/AmitKumarDas/metac/tree/master/examples

[AmitKumarDas]

@mittachaitu Does this mean a migration from one CR to new CR & finally deleting the old CR?

[mittachaitu]

@mittachaitu Does this mean a migration from one CR to new CR & finally deleting the old CR?

Exactly @AmitKumarDas. Once it known that things related to new CR are properly populated then we can delete new CR.