Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Design how CM should handle properties

Description

Design how CM should handle properties.

Acceptance / Success Criteria

the design should address the following:

  1. How CM will validate configuration from property file?

  2. How Liquibase script should look like for properties files?

  3. Define interface of the CM for properties management

Lucidchart Diagrams

Activity

Show:

Patrick Schweizer October 12, 2021 at 1:41 PM

We made the following decisions:

  • We will use openapi as internal schema model for validation

  • no incremental change to a schema definition via liquibase. We always provide the full schema.

  • conversion from XSD => Openapi happens in liquibase layer, CM thinks only in Openapi

Patrick Schweizer October 7, 2021 at 10:12 AM

On 1. How CM will validate configuration from property file?
I see 2 ways:
1. Each schema type (e.g. xml and properties) defines their own way to deal with validation
2. We create a unified internal representation of schemas and validate against that. This could be
2.a XSDs (we would have to create internally a XSD from the Liquibase input)
2.b some other form of schema representation

Patrick Schweizer October 7, 2021 at 10:02 AM
Edited

Suggestion how the liquibase handling of properties could look like:

<changeSet author="pschweizer" id="define schema"> <cm:registerSchema id="myPropertySchema" type="properties"> <cm:put key="myFirstKey" defaultValue="aa" type="string" match-regex="[\d]+" /> <cm:put key="mySecondKey" defaultValue="5" type="number" min="0", max="10" /> </cm:registerSchema> <cm:importConfig schemaId="myPropertySchema" configId="default" filePath="myProperties.properties"/> </changeset> <changeSet author="pschweizer" id="modify schema"> <cm:replaceSchema id="myPropertySchema"> <cm:put schemaId="myPropertySchema" key="myFirstKey" defaultValue="aa" type="string" match-regex="[\d]+" /> <cm:put schemaId="myPropertySchema" key="mySecondKey" defaultValue="6" type="number" min="0", max="10" /> </cm:modifySchema> </changeSet>

Assumptions

  • The property key is unique within the schema

  • Each property is mandatory (otherwise we can't show it in the GUI), therefore

  • Each property has a default value

  • When a property is removed from the schema we remove it from all configuration instances

 

Patrick Schweizer October 7, 2021 at 9:35 AM

Food for thoughts:

In the POC we envisioned defining a properties schema as following:

https://github.com/opennms-forge/notconfd/blob/main/liquib/src/main/resources/changelog.xml

https://github.com/OpenNMS/opennms/blob/1975dbbb5ac2d1e34780414f73830cd2a46744f1/core/cm/changelog-29.0.0.xml#L22

<changeSet author="jwhite" id="29.0.0-init-blueprint-amqp-forwarder"> <cm:registerConfiguration configId="org.opennms.features.amqp.eventforwarder" schema="key-value-map"/> <cm:put configId="org.opennms.features.amqp.eventforwarder" path="/map"/> <cm:put configId="org.opennms.features.amqp.eventforwarder" path="/map/connectionUrl">amqp://localhost:5672</cm:put> <cm:put configId="org.opennms.features.amqp.eventforwarder" path="/map/username">guest</cm:put> <cm:put configId="org.opennms.features.amqp.eventforwarder" path="/map/password">guest</cm:put> <cm:put configId="org.opennms.features.amqp.eventforwarder" path="/map/destination">amqp:topic:opennms-events</cm:put> <cm:put configId="org.opennms.features.amqp.eventforwarder" path="/map/processorName">default-event-forwarder-processor</cm:put> <cm:put configId="org.opennms.features.amqp.eventforwarder" path="/map/propertyWeDontLikeAnymore">blah</cm:put> <cm:remove configId="org.opennms.features.amqp.eventforwarder" path="/map/propertyWeDontLikeAnymore"/> </changeSet>
<changeSet author="jwhite" id="29.0.0-init-sysprops"> <systemProperty name="org.opennms.ipc.sink.aggregation.stripes" type="int" min-max="1" max-val="123"></systemProperty> <systemProperty name="org.opennms.instance.id" type="string" match-regex="[\d]+"></systemProperty> </changeSet>
Fixed

Details

Assignee

Reporter

Labels

Sprint

Priority

Parent

PagerDuty

Created October 6, 2021 at 1:57 PM
Updated June 7, 2022 at 4:51 PM
Resolved December 3, 2022 at 1:32 AM

Flag notifications