Age | Commit message (Collapse) | Author | Files | Lines |
|
The following changes aim to have a quicker start of the drools container:
1. For both amsterdam (and the experimental beijing) controllers
dependencies are pre-installed, so the loading of 3rd party
dependencies are faster.
2. Further enhancements in installation.
3. Make sure that the naming of the generated control loop
artifacts have a "control loop" label associated with it,
so in the future, if other applications are added (non
control loop related) do not conflict and is clear.
Change-Id: Iecb84d186fcc34069aa5c4a175a8a4521b38499d
Issue-ID: POLICY-534
Signed-off-by: Jorge Hernandez <jh1730@att.com>
|
|
The create-cl-beijing script will now allow the user to create a rules
jar that does not need to be expanded and also generate test files that
can be used to insert facts for all the supported beijing use cases. The
yaml for each policy is provisioned by the user in case custom yaml is
desired.
In addition to this, a new script is included that will extract the
needed data from the controller properties file to insert facts for all
the supported use cases. This script can be used to insert
ControlLoopParams facts after the create-cl-beijing script is used to
generate the rules artifact. No provisioning necessary other than
specifying where the controller properties file is located.
Issue-ID: POLICY-692
Change-Id: I42f0a08fba133ca36fb1be588a720e4f9598d79f
Signed-off-by: Daniel Cruz <dc443y@att.com>
|
|
The naming of Maven modules in drools-applications was not
aligned with the directory structure in the git repository
of drools-applications. Therefore it was difficult to
see the strucutre of the repository in Eclipse and other
IDEs. This change amends the Maven module IDs to
reflect the repository directory structure.
This patch reset fixes the previos patch set, where many
references to maven modules internally in drools-applciations
were missed. See also changes in engine and docker repos.
Updated to reflect repo directory structure in maven
artifact groups.
Issue-ID: POLICY-238
Change-Id: I8ab1a7ecdb664045222bbbfda269135e3e449109
Signed-off-by: liamfallon <liam.fallon@ericsson.com>
|
|
Bump minor version in preparation for Amsterdam
branching.
Change-Id: Ia7e97a72053a2d1cd10c0b9d5c179817c3ac7e23
Issue-ID: CIMAN-120
Signed-off-by: Jessica Wagantall <jwagantall@linuxfoundation.org>
|
|
Released 1.1.1, now must bump patch by 1
Issue-ID: POLICY-436
Change-Id: I3f5e4c369575f6fe1fa06cabb96a5bd43cb11087
Signed-off-by: Pamela Dragosh <pdragosh@research.att.com>
|
|
Change-Id: I84cf9fe9e954a9ee9bac8eaff56169e44154e9c5
Issue-ID: POLICY-446
Signed-off-by: Jorge Hernandez <jh1730@att.com>
|
|
Releasing v1.1.0 so need to update version to 1.1.1
Issue-ID: POLICY-436
Change-Id: I8b85de39bb3a32f5f4faeeb4fcdfb5d95291ae31
Signed-off-by: Pamela Dragosh <pdragosh@research.att.com>
|
|
Change-Id: I61c8d698f8cf984c648e510997498d41e7d9744a
Issue-ID: POLICY-433
Signed-off-by: Jorge Hernandez <jh1730@att.com>
|
|
Change-Id: I05c577e8760f5b4b8e6375f50a327c9dde575e06
Issue-ID: POLICY-260
Signed-off-by: Jorge Hernandez <jh1730@att.com>
|
|
This allows the user to disable or enable guard
through the .properties.environment file. Verified
and tested in a pdp. Properties were added to the
simulators properties file for the simulators to
work out of the box.
Issue-ID: POLICY-259
Change-Id: I0027a5d28f1b30e81bdbe42fa17621b36a61c850
Signed-off-by: Daniel Cruz <dc443y@att.com>
|
|
Change-Id: I9bcbaf50e802fceb07c0db3bf13df8f8403a6dea
Issue-ID: POLICY-265
Signed-off-by: Jorge Hernandez <jh1730@att.com>
|
|
Change-Id: I23d2e8d16abe6ccbfda6f7d1a3e3d69b209d5b20
Issue-ID: POLICY-260
Signed-off-by: Jorge Hernandez <jh1730@att.com>
|
|
run successully vcpe case in lab in 2 steps:
1. docker-install load
2. run create-cl-amsterdam (with defaults)
3. injecting dcae.onset and appc.success packaged
with archetypes
Change-Id: Idb20c0078228da962510dbf36dae96aceb43546c
Issue-ID: POLICY-162
Signed-off-by: Jorge Hernandez <jh1730@att.com>
|
|
Clean up a few "mso" references.
Disable 1.0.0 template build for now (note that some
references are still pointing to old mso).
Ie., see
https://git.onap.org/policy/drools-applications/tree/controlloop
/templates/template.demo.v1.0.0/template.demo
/src/test/java/org/onap/policy/template/demo/TestSO.java
Since this
is going away, rather than maintaining it, and changing this
code, disabling it for the build.
It will be deleted within the next few days.
Issue-ID: POLICY-162
Change-Id: Ibb819a318fbbb2b7f3aa14cdf76155bdec321024
Signed-off-by: Jorge Hernandez <jh1730@att.com>
|
|
Issue-ID: POLICY-162
Change-Id: Ieb0952379cd854e0ed8e4a3b068b7e29f3b93770
Signed-off-by: Hockla, Ali (ah999m) <ah999m@att.com>
|
|
This is work in progress, the official pom.xml with dependencies,
drl template, and support files for controller deployment
are maintained here. In the near future the junit template
should be consolidated with this one.
Added controlloop.properties.environment, this environment file
will be populated at installation time with the lab's aai url,
etc .. and will be accessible by any drools application such as
control loops through the PolicyEngine interface. Note that PDP-D
server already supports these environment files, so it is just natural.
Therefore, this is the default mechanism to provide to applications, the url, username,
and passwords to use at runtime by the control loops for the time being.
In the future MSB could set them globally here through existing APIs,
or it can be queried by any drools application using MSB library,
doesn't matter.
There's been some trouble playing nicely with the dependencies used
by a control loop application classsloader, and the pdp-d middleware one,
causing issues between dependencies version of libraries. Specifically,
the snakeyaml library does not play well across classloader when using
constructor functionality, note that the snakeyaml libraries are pulled
also from jackson parsers used in the pdp-d. I made a change in ControlLoopProcessor
to specifically tell the "Yaml" object which classloader to use in order to
find the class with the constructor that is intended to be built, otherwise,
yaml libraries use a different classloader that does not have visibility
into the ControlLoopPolicy that is trying to construct, and fails. This also
should respect junits that use the same classloader I pressume and does not
give issues.
Change-Id: I36271d29cdbf8ff861f9c03ff91cf7116927906a
Issue-ID: POLICY-162
Signed-off-by: Jorge Hernandez <jh1730@att.com>
|
|
removes pom warnings on versionn duplication from parent pom.
Change-Id: I7b218d6d72bf4db2692370ecc637dbd74e96290f
Issue-ID: POLICY-162
Signed-off-by: Jorge Hernandez <jh1730@att.com>
|
|
Two changes:
- remove hardcoding of the DMaaP hosts, and DCAE topic to
make it configurable.
- rename archetype to better name.
Change-Id: Ic50b9d1f06a138230c76cc6c50ca8072dc5da148
Issue-ID: POLICY-159
Signed-off-by: Jorge Hernandez <jh1730@att.com>
|
|
Change-Id: Iac032aa8f379cc8d614ec7913b41a68cbda9674d
Issue-ID: POLICY-162
Signed-off-by: Jorge Hernandez <jh1730@att.com>
|