I’m new to plugin creation and am wondering if there are any ways to store additional persistent information that pertain to my plugin integration on Cloud or computeServer objects?
Imagine a plugin that interacts with 3rd party monitoring tool that assigns unique Ids to Cloud/computeServer objects when my plugin would add such object into the 3rd party tool. My plugin would need to use these unique Ids when further interacting with that 3rd party tool for change and remove operations. I’d like to keep those unique Ids with the Cloud or computerServer object and even be able to show that special information on a custom tab in the Cloud or ComputeServer object.
Are the MorpheusModel class getConfig(), setConfig(), getConfigProperty() and setConfigProperty() inherited methods intended/usable for adding such information to a Cloud or computeServer object?
If they are, when to use the associated dirty/clean method calls when setting properties?
If not, are there any other ways to accomplish this apart from maintaining a separate backend DB tying Cloud/computeServer object information to the 3rd party tool unique IDs?
The MorpheusReferenceData service can be used to store reference data for arbitrary objects. You can link the reference data to the morpheus object you want to relate it too.
The setConfig method could also be used for this purpose. I have worked with a user who uses setConfig for a similar purpose, however they had to be careful to enforce sequential read/write to the config properties from the application logic, and so they took advantage of the acquireLock method within the MorpheusContext to control concurrency when reading/writing to config for a specific resource. You could also take advantage of some of the properties of a ComputeServer object, such as internalId, depending on what your Plugin does.
Looking at the API page of MorpheusReferenceDataService and it’s methods doesn’t give me a good understanding of how I can/must use, for example, it’s create() method and what fields in the list given as an argument are mandatory (InternalId, account, code, etc.?). Is there a piece of example code floating around some place?
acquireLock(): Ah, I can see why that would be important indeed. How does the isDirty/markDirty/markClean methods factor in with calls to setConfig()? Do I have to worry about doing a markDirty() after (before?) a setConfig() for example?
I have not used this yet for my own Plugins and a quick search has not yielded any examples. Time permitting I will try and get you an example. Thanks.
You should not need to manually markDirty for the abstract setConfig method.
Thank you Chris for your explanations so far.