Creation of Multiple service templates was possible all along. The code allowed to define a unique name and version to create and store multiple tosca service templates in the DB. The issue comes from handling the data that has been created with a unique name and version instead of the default one. 

You can currently remove the default concept by calling the public deleteServiceTemplate(PfDao dao, String name, String version) method in the AuthorativeToscaProvider class. The given concept name and concept version are ignored and replaced with the default name and version. There is no additional verification of the relationship between the concepts. 

This makes it hard to delete uniquely named tosca service templates using rest methods, and can only interact with them using a DB.

we should modify AuthorativeToscaProvider to allow interaction with the created policy template.


The proposed change should:

  • take into account the given name and version
  • check if the concept with the given name and version has no child concepts
  • check if the given name and concept version is not listed as a parent for other concepts
  • check if the policy is not deployed.

Verification:

  1. It would be simpler to check if the policy is implemented in PAP. So at this level there are only concepts with undeployed policies.
  2. Checking the relationship between the concepts should be in Dao or SimpleToscaServiceTemplateProvider. If there is any parent-child relationship, then PfModelException with a corresponding code will be thrown, and no database change will be made.



  • No labels

2 Comments

  1. Jim Hahn

    It appears that we do not need to add deleteByConceptName() to PfDao, as deleteByConceptKey() can be used instead.

    Regarding the various provider classes, I don't see the need for methods that only take the name, as methods that take both the name and version should be used instead.  Other than that, I totally agree that the existing methods must be modified to actually use the name and version, rather than discarding them in lieu of the default name and version.

    1. Liam Fallon

      Just on the referential checks, i can't see any nice way of doing a referential check other than a brute force check of the entire database using the getKeys() methods on the concepts, let's discuss this a bit more.

      On the deployment, we will also have this problem in the TOSCA control loop side. If a concept is being used in an instance that's deployed somewhere  (Be it policy or control loop) then it shold not be deleted. However, how can policy-models go and check this? Maybe we should introduce an isDeployed flag on the concept instances that the applications (PAP or CLAMP) set when they deploy a concept.