Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Code Block
languagejava
titlePersistence Model
collapsetrue
@Data
@EqualsAndHashCode(callSuper = true)
public class DocToscaServiceTemplate extends DocToscaEntity<ToscaServiceTemplate> {

    @SerializedName("data_types")
    private Map<String, @Valid DocToscaDataType> dataTypes;

    -------

    public DocToscaServiceTemplate(ToscaServiceTemplate authorativeConcept) {
        this.fromAuthorativesuper(authorativeConcept);
    }

    @Override
setName(DEFAULT_NAME);
      public ToscaServiceTemplate toAuthorativesetVersion(DEFAULT_VERSION);
 {
        final var toscaServiceTemplate = new ToscaServiceTemplate();
        super.setToscaEntity(toscaServiceTemplate);-------
     }
 
    public DocToscaServiceTemplate(ToscaServiceTemplate authorativeConcept) {
        superthis.toAuthorativefromAuthorative(authorativeConcept);

    }

    ifpublic DocToscaServiceTemplate(dataTypesfinal !=DocToscaServiceTemplate nullcopyConcept) {
        super(copyConcept);
        this.toscaDefinitionsVersion = copyConcept.toscaDefinitionsVersion;
      toscaServiceTemplate.setDataTypes(  this.dataTypes = DocUtil.docMapMapdocMapToMap(copyConcept.dataTypes, DocToscaDataType::toAuthorativenew, new LinkedHashMap<>());
 
       }
     -------
 
        return toscaServiceTemplate;}
    }

      @Override
    public voidToscaServiceTemplate fromAuthorativetoAuthorative(ToscaServiceTemplate toscaServiceTemplate) {
        super.fromAuthorative(toscaServiceTemplate);
 final var toscaServiceTemplate = new ToscaServiceTemplate();
        if super.setToscaEntity(toscaServiceTemplate.getDataTypes();
 != null) {
      super.toAuthorative();

      dataTypes = DocUtiltoscaServiceTemplate.mapDocMapsetDataTypes(toscaServiceTemplateDocUtil.getDataTypesdocMapToMap()dataTypes, DocToscaDataType::newtoAuthorative));
          }   -------
 
        ------- return toscaServiceTemplate;
    }
}

In the example below the implementation of JpaToscaServiceTemplate for PostgreSQL/MariaDB (full implementation could be found here: https://gerrit.nordix.org/c/onap/policy/clamp/+/13642)

Code Block
languagejava
titlePersistence Model
collapsetrue
@Entity
@Table(name = "ToscaServiceTemplate")
@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
@Data
@EqualsAndHashCode(callSuper = false)
public class JpaToscaServiceTemplate extends PfConcept implements PfAuthorative<ToscaServiceTemplate> {

    @EmbeddedId
    @VerifyKey
    @NotNull
    private PfConceptKey key;

    @Lob
    @Convert(converter = StringToServiceTemplateConverter.class)
    @NotNull
    @Valid
    private DocToscaServiceTemplate serviceTemplate;

         @Override
    public void fromAuthorative(ToscaServiceTemplate toscaServiceTemplate) {
        super.fromAuthorative(toscaServiceTemplate);
 
        if (toscaServiceTemplate.getDataTypes() != null) {
            dataTypes = DocUtil.mapDocMap(toscaServiceTemplate.getDataTypes(), DocToscaDataType::new);
        }
 
        ------- 
    }

    @Override
    public ToscaServiceTemplateint toAuthorativecompareTo(DocToscaEntity<ToscaServiceTemplate> otherConcept) {
        int result return= serviceTemplate.toAuthorativecompareToWithoutEntities(otherConcept);
    }

    @Override
if (result   public void fromAuthorative(ToscaServiceTemplate authorativeConcept!= 0) {
        serviceTemplate   = new DocToscaServiceTemplate(authorativeConcept)return result;
        setKey(serviceTemplate.getKey().asIdentifier().asConceptKey());
    }}
        final DocToscaServiceTemplate other = (DocToscaServiceTemplate) otherConcept;

         ------- 
        return ObjectUtils.compare(toscaTopologyTemplate, other.toscaTopologyTemplate);
    }
}


In the example below the implementation of JpaToscaServiceTemplate for MongoDB PostgreSQL/MariaDB (full implementation could be found here: https://gerrit.nordix.org/c/onap/policy/clamp/+/1361513642)

Code Block
languagejava
titlePersistence Model
collapsetrue
@Document@Entity
@Table(collectionname = "ToscaServiceTemplate")
@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
@Data
@EqualsAndHashCode(callSuper = false)
public class JpaToscaServiceTemplate extends PfConcept implements PfAuthorative<ToscaServiceTemplate> {

    @Id@EmbeddedId
    @VerifyKey
    @NonNull@NotNull
    private PfConceptKey key;

    @NonNull@Lob
    @Convert(converter = StringToServiceTemplateConverter.class)
    @NotNull
    @Valid
    private DocToscaServiceTemplate serviceTemplate;

     ------- 
 
    @Override
    public ToscaServiceTemplate toAuthorative() {
        return serviceTemplate.toAuthorative();
    }

    @Override
    public void fromAuthorative(ToscaServiceTemplate authorativeConcept) {
        serviceTemplate = new DocToscaServiceTemplate(authorativeConcept);
        setKey(serviceTemplate.getKey().asIdentifier().asConceptKey());
    }
         ------- 
 }

Converters

...


In the example below the implementation of JpaToscaServiceTemplate for MongoDB (full implementation could be found here: https://gerrit.nordix.org/c/onap/policy/clamp/+/13615)

Code Block
languagejava
titleConvertersPersistence Model
collapsetrue
@Converter(autoApply@Document(collection = "ToscaServiceTemplate")
@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
@Data
@EqualsAndHashCode(callSuper = truefalse)
public class JpaToscaServiceTemplate extends StringToServiceTemplateConverterPfConcept implements AttributeConverter<DocToscaServiceTemplate, String>PfAuthorative<ToscaServiceTemplate> {

    private@Id
  static final Coder@VerifyKey
 coder = new StandardCoder();

@NonNull
    private PfConceptKey @Overridekey;

    public@NonNull
 String convertToDatabaseColumn(DocToscaServiceTemplate serviceTemplate) {@Valid
    private DocToscaServiceTemplate serviceTemplate;

   try {  ------- 
 
    @Override
    public ToscaServiceTemplate toAuthorative() {
  return serviceTemplate == null ? null :return coderserviceTemplate.encodetoAuthorative(serviceTemplate);
    }

    } catch (CoderException e@Override
    public void fromAuthorative(ToscaServiceTemplate authorativeConcept) {
        serviceTemplate = new DocToscaServiceTemplate(authorativeConcept);
   throw    new PfModelRuntimeExceptionsetKey(Response.Status.BAD_REQUEST, e.getMessage(), eserviceTemplate.getKey().asIdentifier().asConceptKey());
    }
       }
  ------- 
 }

Converters

Jakarta and Spring do no support json Type, but we can use Converters to convert DocToscaServiceTemplate  to a Json String.

Code Block
languagejava
titleConverters
collapsetrue
@Converter(autoApply =   @Overridetrue)
public class StringToServiceTemplateConverter implements publicAttributeConverter<DocToscaServiceTemplate, DocToscaServiceTemplate convertToEntityAttribute(String dbData) String> {

    private static final Coder ifcoder (dbData= ==new null) {StandardCoder();

    @Override
    public String convertToDatabaseColumn(DocToscaServiceTemplate serviceTemplate) return{
 new DocToscaServiceTemplate();
      try  }{
        try {
   return serviceTemplate == null ? null  :  return coder.decode(dbData, DocToscaServiceTemplate.classencode(serviceTemplate);
        } catch (CoderException e) {
            throw new PfModelRuntimeException(Response.Status.BAD_REQUEST, e.getMessage(), e);
        }
    }
}

Note: Serialization and deserialization in Json is already used in policy-model (Un example could be found here [JpaToscaPolicy.java]). @Converter is just an elegant way to do the same thing.

ToscaServiceTemplate Table


    @Override
    public DocToscaServiceTemplate convertToEntityAttribute(String dbData) {
        if (dbData == null) {
            return new DocToscaServiceTemplate();
        }
        try {
            return coder.decode(dbData, DocToscaServiceTemplate.class);
        } catch (CoderException e) {
            throw new PfModelRuntimeException(Response.Status.BAD_REQUEST, e.getMessage(), e);
        }
    }
}

Note: Serialization and deserialization in Json is already used in policy-model (Un example could be found here [JpaToscaPolicy.java]). @Converter is just an elegant way to do the same thing.

ToscaServiceTemplate Table

clampacm=# \d ToscaServiceTemplateclampacm=# \d ToscaServiceTemplate
                    Table "public.toscaservicetemplate"
     Column      |          Type          | Collation | Nullable | Default
-----------------+------------------------+-----------+----------+---------
 name            | character varying(120) |           | not null |
 version         | character varying(20)  |           | not null |
 servicetemplate | text                   |           |          |
Indexes:
    "toscaservicetemplate_pkey" PRIMARY KEY, btree (name, version)
clampacm=# select * from public.ToscaServiceTemplate;
        name            Table "public.toscaservicetemplate"
     Column      |          Type          | Collation | versionNullable | servicetemplate
Default
-----------------+------------------------+-----------+----------+---------
 PMSH_Test_Instance | 1.0.0 name            | character varying(120) |           | not null 16505
(1 row)
clampacm=# select convert_from(lo_get(servicetemplate::oid), 'UTF8') from toscaservicetemplate;
{"tosca_definitions_version":"tosca_simple_yaml_1_3", ...

Proposals

|
 version         | character varying(20)  |           | not null |
 servicetemplate | text                   |           |          |
Indexes:
    "toscaservicetemplate_pkey" PRIMARY KEY, btree (name, version)


clampacm=# select * from public.ToscaServiceTemplate;
        name        | version | servicetemplate
--------------------+---------+-----------------
 PMSH_Test_Instance | 1.0.0   | 16505
(1 row)


clampacm=# select convert_from(lo_get(servicetemplate::oid), 'UTF8') from toscaservicetemplate;
{"tosca_definitions_version":"tosca_simple_yaml_1_3", ...

Proposals

The new ORM layer will be implemented into an additional package and the old layer will be not changed. My propose options are shown belowThe new ORM layer will be implemented into an additional package and the old layer will be not changed. My propose options are shown below:

  1. Save ToscaServiceTemplace as Json String in a single Entity:
    • Each Service Template is stored as a JSON "LOB"
    • It is compatible with H2, MariaDB and PostgreSQL
    • It is an additional code for policy-models and a medium impact for all applications that are using it
    • That solution is compatible with Applications not implemented in Spring
  2. MongoDB/Cassandra
    • Document oriented approach full supported by SpringBoot (not needs Converters)
    • Compatible only with MongoDB/Cassandra (MongoDB and Cassandra are not compatible to each other)
    • It is an additional code for policy-models and a huge impact for all applications that are using it (all repositories and persistence classes have to change to a Document oriented classes)
    • Unit tests need an Embedded Server (example for cassandra: EmbeddedCassandraServerHelper or CassandraContainer)
    • Spring Boot has own annotations for Documents. Eventually for application not in Spring Boot, it needs additional dao style implementation

...

Current Api in policy-apiApi in policy-api with namespace support

POST /nodetemplates
PUT /nodetemplates
DELETE /nodetemplates/{name}/versions/{version}
GET /nodetemplates/{name}/versions/{version}
GET /nodetemplates

GET /policytypes
GET /policytypes/{policyTypeId}
GET /policytypes/{policyTypeId}/versions/{versionId}
GET /policytypes/{policyTypeId}/versions/latest
POST /policytypes
DELETE /policytypes/{policyTypeId}/versions/{versionId}
GET /policytypes/{policyTypeId}/versions/{policyTypeVersion}/policies
GET /policytypes/{policyTypeId}/versions/{policyTypeVersion}/policies/{policyId}
GET /policytypes/{policyTypeId}/versions/{policyTypeVersion}/policies/{policyId}/versions/{policyVersion}
GET /policytypes/{policyTypeId}/versions/{policyTypeVersion}/policies/{policyId}/versions/latest
POST /policytypes/{policyTypeId}/versions/{policyTypeVersion}/policies
DELETE /policytypes/{policyTypeId}/versions/{policyTypeVersion}/policies/{policyId}/versions/{policyVersion}
GET /policies
GET /policies/{policyId}/versions/{policyVersion}
POST /policies
DELETE /policies/{policyId}/versions/{policyVersion}

POST /servicetemplates/{st_name}/versions/{st_version}/nodetemplates
PUT /servicetemplates/{st_name}/versions/{st_version}/nodetemplates
DELETE /servicetemplates/{st_name}/versions/{st_version}/nodetemplates/{name}/versions/{version}
GET /servicetemplates/{st_name}/versions/{st_version}/nodetemplates/{name}/versions/{version}
GET /servicetemplates/{st_name}/versions/{st_version}/nodetemplates

GET /servicetemplates/{st_name}/versions/{st_version}/policytypes
GET /servicetemplates/{st_name}/versions/{st_version}/policytypes/{policyTypeId}
GET /servicetemplates/{st_name}/versions/{st_version}/policytypes/{policyTypeId}/versions/{versionId}
GET /servicetemplates/{st_name}/versions/{st_version}/policytypes/{policyTypeId}/versions/latest
POST /servicetemplates/{st_name}/versions/{st_version}/policytypes
DELETE /servicetemplates/{st_name}/versions/{st_version}/policytypes/{policyTypeId}/versions/{versionId}
GET /servicetemplates/{st_name}/versions/{st_version}/policytypes/{policyTypeId}/versions/{policyTypeVersion}/policies
GET /servicetemplates/{st_name}/versions/{st_version}/policytypes/{policyTypeId}/versions/{policyTypeVersion}/policies/{policyId}
GET /servicetemplates/{st_name}/versions/{st_version}/policytypes/{policyTypeId}/versions/{policyTypeVersion}/policies/{policyId}/versions/{policyVersion}
GET /servicetemplates/{st_name}/versions/{st_version}/policytypes/{policyTypeId}/versions/{policyTypeVersion}/policies/{policyId}/versions/latest
POST /servicetemplates/{st_name}/versions/{st_version}/policytypes/{policyTypeId}/versions/{policyTypeVersion} /policies
DELETE /servicetemplates/{st_name}/versions/{st_version}/policytypes/{policyTypeId}/versions/{policyTypeVersion}/policies/{policyIdpolicyTypeId}/versions/{policyVersionpolicyTypeVersion}/policies
GET DELETE /servicetemplates/{st_name}/versions/{st_version}/policies
GET policytypes/servicetemplates/{st_namepolicyTypeId}/versions/{st_versionpolicyTypeVersion}/policies/{policyId}/versions/{policyVersion}
POST GET /servicetemplates/{st_name}/versions/{st_version}/policies
DELETE GET /servicetemplates/{st_name}/versions/{st_version}/policies/{policyId}/versions/{policyVersion}

Update functionality (second and third step of Roadmap)

There are two kind of update:

  • values (example "description", "metadata", ...)
  • data structure (example Create or Delete of a ToscaEntity, or Update a reference as "type", "type_version" or "host_namespace")

Open questions about participants

POST /servicetemplates/{st_name}/versions/{st_version}/policies
DELETE /servicetemplates/{st_name}/versions/{st_version}/policies/{policyId}/versions/{policyVersion}

Update functionality (second and third step of Roadmap)

There are two kind of update:

  • values (example "description", "metadata", ...)
  • data structure (example Create or Delete of a ToscaEntity, or Update a reference as "type", "type_version" or "host_namespace"
  • Case scenario: we have two custom service template, a common service template and two automation composition. participant-policy creates and deletes policies and policy types connecting to policy-api.
    • Could we have that scenario?
    • Should participant-policy receive a full service template (custom and common service template)?
    • Should participant policy collect all policies and policy types by GET policy-api, to know if them are already created?
    • How participant policy know if can delete a policy and policy type if it could be used to other automation composition?
  • Case scenario: we have two custom service template. A participant is defined in only one of them.
  • Could we have that scenario?
  • Should participant receive only the custom service template related? (A table to save relations between service templates and participants)

Proposals

  • We could consider Service templates references to each other as a DAG ( directed acyclic graph), where Service templates are nodes, and a references as edges. Cyclic references are not allowed.
  • Should be available a functionality to load a full version of the service template that contains own tosca entities and also all tosca entities referenced from other service templates (this functionality in for validation or business logic purpose and will be not visible to the end user)
  • A service template cannot be deleted if there are references to it
  • Any Tosca Entity in a common service template cannot be deleted if there are references to that service template
  • Any Tosca Entity in a common service template cannot change "host_namespace", "type" and "type_version" if there are references to that service template
  • Any Tosca Entity in a common service template cannot change values if there are automation compositions referenced to that service template (and references to that service template?)
  • A Tosca Entity cannot be add in a common service template if there are automation compositions referenced to that service template
  • Functionality as create, update and delete of a ToscaEntity in a service template should be validated and restricted to the service template itself. (Example: update property values of a service template should never update property values from other service templates referenced)
  • To reduce the complexity, could be useful to save additional information about the service template:
    • A full version of the service template that contains own tosca entities and also all tosca entities referenced from other service templates. it will be used in read-only for business logic purpose
    • A table to save relations between service templates
    • A table to save relations between service templates and automation compositions (with all service templates referenced)

Conclusion

  • the service template that contains own tosca entities and also all tosca entities referenced from other service templates (this functionality in for validation or business logic purpose and will be not visible to the end user)
  • A service template cannot be deleted if there are references to it
  • Any Tosca Entity in a common service template cannot be deleted if there are references to that service template
  • Any Tosca Entity in a common service template cannot change "host_namespace", "type" and "type_version" if there are references to that service template
  • Any Tosca Entity in a common service template cannot change values if there are automation compositions referenced to that service template (and references to that service template?)
  • A Tosca Entity cannot be add in a common service template if there are automation compositions referenced to that service template
  • Functionality as create, update and delete of a ToscaEntity in a service template should be validated and restricted to the service template itself. (Example: update property values of a service template should never update property values from other service templates referenced)
  • To reduce the complexity, could be useful to save additional information about the service template:
    • A full version of the service template that contains own tosca entities and also all tosca entities referenced from other service templates. it will be used in read-only for business logic purpose
    • A table to save relations between service templates
    • A table to save relations between service templates and automation compositions (with all service templates referenced)

Conclusion

  • Move to document storage does not change the functionality of the application. Example if clampacm move to document storage, and policyadmin not yet, those applications will continue to work fine.
  • Enable namespace and enable to handle more than one service template, impacts functionalities and applications dependency. Example if clampacm has namespace enabled, and policyadmin not yet, due the dependency, they could have some issues.
  • Document storage Optional?: using SpringBoot profiles and interfaces it could be possible to have a double implementation and run only one, (based on parameter in properties file), but it does not make sense due the second point.

    Work in progress