Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
|
|
|
|
Issue-ID: SO-636
Change-Id: Ieb6c3da2c0485585d009bfca1d689f4c485a2879
Signed-off-by: Marcus G K Williams <marcus.williams@intel.com>
|
|
When controllerType is sdnc, it's still using
the appc topic names. Trying this to switch
topic based on controllerType.
Patch 2 changed to match APPCClient in ATT
code base.
Change-Id: I72e7e84720f73ac30d3d28e3387af2d537d301ad
Issue-ID: INT-475
Signed-off-by: Arthur Martella <am153x@att.com>
|
|
Fix ressource looping if AAI response is empty for resource list.
Change-Id: I244d3836beb98ec2689c71df5c61f24f40619d96
Issue-ID: SO-632
Signed-off-by: subhash kumar singh <subhash.kumar.singh@huawei.com>
|
|
Issue-ID: SO-634
Change-Id: Id39f2487d111099abf09330f3f2f089605cbe945
Signed-off-by: guochong <guochong@chinamobile.com>
|
|
but progress is 100 for wrong opertype
Change-Id: Idaa55084f5ecb0dd3636c232cebc14fa5f0643f6
Issue-ID: SO-632
Signed-off-by: Yulian Han <elaine.hanyulian@huawei.com>
|
|
|
|
|
|
Re: https://gerrit.onap.org/r/#/c/48031/1
SO is failing health check because pnfCheckInputs
is not found in dmaap.properties, and
pnf.properties is not being read, since
applicationContext.xml has two
PropertyPlaceholderConfigurer attributes, but
it's only using one.
Moved defaultTimeout to dmaap.properties, where
applicationContext.xml will be able to read it,
and renamed it to pnfDefaultTimeout to make it
clearer what it is.
Change-Id: I6490de472fbf4875e53204f4248c6325787c8af5
Issue-ID: SO-506
Signed-off-by: Arthur Martella <am153x@att.com>
|
|
|
|
|
|
Addition:
- Marcus Williams
- Sanchita Pathak
Removal:
- Tal Liron
- Heliu Zhong
- Yuanwei Yang
Change-Id: I4d5ed58584c387fe180dc2e8d91c9d9fc35ca8ea
Issue-ID: CIMAN-134
Signed-off-by: Jessica Wagantall <jwagantall@linuxfoundation.org>
|
|
|
|
In the integration environment, there's no cloud region named att-aic.
Therefore, try without att-aic first (CLOUD-REGION)
and if that fails, try att-aic (DEFAULT-CLOUD-REGION)
Change-Id: Ie4a4a3924eb6fe1120519e124a7967a62c96428f
Issue-ID: INT-475
Signed-off-by: Arthur Martella <am153x@att.com>
|
|
Fix subcategory population for vnf resource.
Change-Id: Ib9b03a19cc12ed66f552096a9b3a499ac6ef574f
Issue-ID: SO-630
Signed-off-by: subhash kumar singh <subhash.kumar.singh@huawei.com>
|
|
|
|
Fix parsing of VNF resource.
Change-Id: Ib2adfaab1ae9bb5fa9cff195cdecbdea5aea18e1
Issue-ID: SO-630
Signed-off-by: subhash kumar singh <subhash.kumar.singh@huawei.com>
|
|
|
|
Fix resource building logic.
Change-Id: I95064d945a6ff026a0ea10336a550d9bb8af401a
Issue-ID: SO-624
Signed-off-by: subhash kumar singh <subhash.kumar.singh@huawei.com>
|
|
Change-Id: I1a4f4b9704385a17995e76d4b87484c2f588b889
Issue-ID: SO-506
Signed-off-by: biniek <lukasz.biniek@nokia.com>
|
|
|
|
Fix resource population to DB.
Change-Id: Iae25ce2f15fa121a45a55559458fcbbd217f2c7d
Issue-ID: SO-624
Signed-off-by: subhash kumar singh <subhash.kumar.singh@huawei.com>
|
|
Issue-ID: SO-628
Change-Id: I6e9e44d453a72b4e9ec1a0abe99eb8028aa5ba1a
Signed-off-by: Marcus G K Williams <marcus.williams@intel.com>
|
|
Issue-ID: SO-628
Change-Id: I3bd802fc966f466b12556d19e347a130e152a51d
Signed-off-by: Marcus G K Williams <marcus.williams@intel.com>
|
|
Update release notes.
Change-Id: Ie353abb910c752557a99944528a9157c45ce8073
Issue-ID: SO-627
Signed-off-by: subhash kumar singh <subhash.kumar.singh@huawei.com>
|
|
|
|
Change-Id: I41bf2c4d12345d46d8bf008f79d6610592e3b645
Issue-ID: SO-625
Signed-off-by: Arthur Martella <am153x@att.com>
|
|
Change-Id: I526d79d602d27c7c734bd1e38a4733176bd55f15
Issue-ID: SO-619
Signed-off-by: Arthur Martella <am153x@att.com>
|
|
Issue-ID: SO-622
Change-Id: If8260ee70d3c632325939affcbd80258b2602c99
Signed-off-by: Brian Freeman <bf1936@att.com>
|
|
This commit adds some robustness to the interface between the
API-H and BPMN, specifically, in how the response is handled.
I don't have proof, but there appears to be some randomness to
the json provider behavior when used with the jax-rs. Sometimes,
the serializer is adding the root element, and sometimes it
is not. Maybe there's something wrong with the configuration.
Maybe we have competing json providers. I couldn't pin this
down.
I'm almost certain it is the presence of the root element in
the content that causes the API-H code to fail parsing of the
BPMN response. This doesn't kill the request, as you might
expect, but rather, the API-H passes the BPMN response through
to the client (VID, or policy, or whatever).
The original problem (SO-586) was "fixed" by "removing the
wrapper". This "wrapper" is a needed feature of the interface
between BPMN and the API-H. We shouldn't have removed it.
The fact that the "fix" appeared to work is due to the
behavior I described in the previous paragraph. The API-H
chokes on the message, and it passes it through unchanged.
Not really what we want.
So, I don't know why the jackson/json behavior is flaky and
different now, but I can (and did) modify the API-H so it can
parse a json message whether or not it has a root element.
Note that WorkflowResponse.java (in BPMN) and CamundaResponse.java
(in the API-H) are basically the same bean representing the
message format. Seems less than ideal to have two different
classes.
Also note that I changed the name of the "response" attribute
of the WorkflowResponse and CamundaResponse classes to "content".
Got tired of seeing this nonsense everywhere in the code:
response.getResponse()
Change-Id: Icaf70f8457de99e493cf882170fe778c620308c9
Issue-ID: SO-586
Issue-ID: SO-618
Signed-off-by: Rob Daugherty <rd472p@att.com>
|
|
Change-Id: I04144bbd22773dfda08d7b13f16080930b7edb3a
Issue-ID: SO-621
Signed-off-by: Arthur Martella <am153x@att.com>
|
|
Change-Id: I7b28cc713929400b03b7e567bf9823d82631a1e9
Issue-ID: SO-617
Signed-off-by: Lukasz Muszkieta <lukasz.muszkieta@nokia.com>
|
|
Change-Id: I57525e367ddf5bdbbc13f9efa9e93fda4fb6748e
Issue-ID: SO-372
Signed-off-by: Arthur Martella <am153x@att.com>
|
|
|
|
|
|
csar files:
1. resource_Extvl.csar
2. service-ServiceFdnt-csar-0904-2.csar
3. service-ServiceFdnt-with-allotted.csar
4. service_Rg516VmmscSrvc_csar.csar
Change-Id: I9e56bf3beaeeb858d91c4e9928789458ed9ba75f
Issue-ID: SO-611
Signed-off-by: sanchitap <sanchita@techmahindra.com>
|
|
|
|
Fix bugs reported by sonar
Change-Id: I0d3445856eb45533d904443b60d75c8aa03e5881
Issue-ID: SO-580
Signed-off-by: Ethan Lynn <ethanlynnl@vmware.com>
|
|
csar files:
1. resource_Extvl.csar
2. service-ServiceFdnt-csar-0904-2.csar
3. service-ServiceFdnt-with-allotted.csar
4. service_Rg516VmmscSrvc_csar.csar
Change-Id: I8688a8a29508c9332eaa8a0130ff2f79db5308dd
Issue-ID: SO-611
Signed-off-by: sanchitap <sanchita@techmahindra.com>
|
|
Use new variable in convertJsonToCloudOrchestrationRequest,
fix bug reported by sonar.
Change-Id: I3f95bd410d950d4661584c1510a66ce90d6785d5
Issue-ID: SO-580
Signed-off-by: Ethan Lynn <ethanlynnl@vmware.com>
|
|
Invenroty and MultiVIM APIs updated
Change-Id: Ia72eaae208f94f2dff59a833661b181b6df1768b
Issue-ID: SO-413
Signed-off-by: sanchitap <sanchita@techmahindra.com>
|
|
Change-Id: I2f35d1a8cc01f349f791b1bc192f91f5f020f689
Issue-ID: SO-506
Signed-off-by: biniek <lukasz.biniek@nokia.com>
|
|
|
|
When the workflow response succeeds, the requestReferences object is being wrapped by "WorkflowResponse": {"response": {... and all the other fields from the WorkflowResponse object are being included as well. Adding a WorkflowResponseSerializer didn't seem to work since the root node was still included and there was no ObjectMapper in which to set WrapRootValue to false. So this is the next best thing.
Patch 2 fixes most of the broken unit tests.
Change-Id: Ifa5bd02e70b23f41c9042ac207848c8ade77313a
Issue-ID: SO-586
Signed-off-by: Arthur Martella <am153x@att.com>
|
|
Change-Id: Ia38fa1234f7b89c0574c74efe62d7b270c8ff987
Issue-ID: SO-596
Signed-off-by: Lukasz Muszkieta <lukasz.muszkieta@nokia.com>
|
|
UUI APIs, SDC APIs updated
Change-Id: I77a245217197b95b1735e75c8ff0bb09c2772d70
Issue-ID: SO-413
Signed-off-by: sanchitap <sanchita@techmahindra.com>
|
|
This is related to recent CloudConfig fixes. One change was apparently
not submitted in the last batch.
Change-Id: I8dcc49f7d808e0d842af3f568f5815fb48870acc
Issue-ID: SO-584
Signed-off-by: Rob Daugherty <rd472p@att.com>
|