Graphman: How to rename resources

[Michael Mueller]

Hi Team.

Is it possibly to rename resources like policies, services or even clusterwide properties through graphman.

I got the impression that resources are identified by name only.

If this is true, it might not be possible to change the name, as it is used to find the existing one.

Can you confirm this understanding or let me know, how resources are identified for updates, and how a rename would work?

That said, what is the purpose of option --excludeGoids ? In which scenario would I use this flag?

Thank you

...Michael

[Francois Lascelles]

Yes, cluster properties are unique by their name. In a policy, the name of the cwp is what identifies it, not to goid. Graphman follows the same rule. In graphman, if you want to 'rename' a cwp, you would just delete the old one and set with new name (or the other way around, doesn't matter, they are different cwps). Leave the goid out of the mutation if you want to avoid running into goid conflicts.

WebApiService wont be unique by name, but by resolution path. In that case, you are not creating a new entity but modifying one.

For example if you apply this bundle below, then change the name of the service to Service 2 (but leave resolution path as is) and then apply the bundle again, you just updated the existing service with a new name (there was never a second service created):

{

  "webApiServices": [

    {

      "name": "Service 1",

      "resolutionPath": "/test",

      "enabled": true,

      "folderPath": "/",

      "methodsAllowed": [

         "POST"

       ],

      "tracingEnabled": false,

      "wssProcessingEnabled": false,

      "policy": {

      "xml": "<whatever>\n"

    }

  }

 ]

}

[Raju Gurram]

Renaming entities: as of now, there's no OTB support. I guess, we all knew that renaming the certain entities is not recommended in the production environment (ex: cluster properties, cluster properties, keys, ?). Renaming policies and encasses wouldn't be harmful because they are referenced by GUIDs. I hope, your requirement is confined to stage environments. Let us know more about your use-cases if possible for further considerations.

And, --excludeGoids is an option to strip the goids from entity definitions during the export. This will ensure the entity definitions goid free. Sometimes, goids are unavoidable for all entity types. Ex: custom assertions referring to other entities. This option should be used carefully.