Age | Commit message (Collapse) | Author | Files | Lines |
|
Issue-ID: SO-634
Change-Id: Id39f2487d111099abf09330f3f2f089605cbe945
Signed-off-by: guochong <guochong@chinamobile.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>
|
|
|
|
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>
|
|
Change-Id: I1a4f4b9704385a17995e76d4b87484c2f588b889
Issue-ID: SO-506
Signed-off-by: biniek <lukasz.biniek@nokia.com>
|
|
Change-Id: I41bf2c4d12345d46d8bf008f79d6610592e3b645
Issue-ID: SO-625
Signed-off-by: Arthur Martella <am153x@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: I2f35d1a8cc01f349f791b1bc192f91f5f020f689
Issue-ID: SO-506
Signed-off-by: biniek <lukasz.biniek@nokia.com>
|
|
|
|
|
|
Set operation type value, to reflect in DB entries.
Change-Id: I2f56bf5f33912645d17bbed2fc759f9354a0ba7b
Issue-ID: SO-422
Signed-off-by: subhash kumar singh <subhash.kumar.singh@huawei.com>
|
|
Fix warning in DoDeleteE2E bpmn file.
Change-Id: I50b1ad5502fc08692775d2f5d9050c3796dd32b1
Issue-ID: SO-422
Signed-off-by: subhash kumar singh <subhash.kumar.singh@huawei.com>
|
|
Change-Id: I0a166b867dcacad4133c8fc679606c381cb5389a
Issue-ID: SO-602
Signed-off-by: Bancala, Ben (bb3476) <bb3476@att.com>
|
|
Change-Id: I3e27ec0d1487eb68e8c54d27508b58233bf49808
Issue-ID: SO-602
Signed-off-by: Bancala, Ben (bb3476) <bb3476@att.com>
|
|
Change-Id: I05f4648ff898a54e7a00d899d97129746172cdb4
Issue-ID: SO-603
Signed-off-by: Arthur Martella <am153x@att.com>
|
|
|
|
deleteResource bugs fix
Change-Id: Idaa55084f5ecb0dd3636c232cebc14fa5f06430a
Issue-ID: SO-578
Signed-off-by: Yulian Han <elaine.hanyulian@huawei.com>
|
|
Change to sdncadapter for service call
Change-Id: I9011e69fba20d4d0f83705455791b7357e2f5bb0
Issue-ID: SO-587
Signed-off-by: c00149107 <chenchuanyu@huawei.com>
|
|
|
|
Add NS relationship delete for E2E service
Change-Id: Ia58308dae0fef38b32098d1e92c0871617a86ed2
Issue-ID: SO-422
Signed-off-by: subhash kumar singh <subhash.kumar.singh@huawei.com>
|
|
Fix value for VFC sync response.
Change-Id: Ie663f9080c051b9302dd4729aea5640c5289e14c
Issue-ID: SO-422
Signed-off-by: subhash kumar singh <subhash.kumar.singh@huawei.com>
|
|
Remove operation status set in api-handler
Change-Id: I579d25044130b0701231c0a2d42534e8c63e3ebd
Issue-ID: SO-587
Signed-off-by: c00149107 <chenchuanyu@huawei.com>
|
|
|
|
|
|
Fix VFCNS termination invocation
Change-Id: Ib30f0a3e4365e215f6da0a693f78825d5a2d32c9
Issue-ID: SO-422
Signed-off-by: subhash kumar singh <subhash.kumar.singh@huawei.com>
|
|
Add service operation initialtion in request db
Change-Id: I2aed78e5cda753b5424b8a8c39e9997a7a7dd61c
Issue-ID: SO-422
Signed-off-by: subhash kumar singh <subhash.kumar.singh@huawei.com>
|
|
|
|
|
|
|
|
|
|
Add sync response for VFCNS delete
Change-Id: I4917f0a83fc0c33d51b9b90d91f10dbdc023e690
Issue-ID: SO-422
Signed-off-by: subhash kumar singh <subhash.kumar.singh@huawei.com>
|
|
Change-Id: Ic8d5814c555bad436bfcbe1b4e212637a6800947
Issue-ID: SO-466
Signed-off-by: Lukasz Muszkieta <lukasz.muszkieta@nokia.com>
|
|
Fix request body for service topology deletion.
Issue-ID: SO-422
Change-Id: Ic2e7cc74dd45dbc4b4a190a159f3ebb852e02b84
Signed-off-by: subhash kumar singh <subhash.kumar.singh@huawei.com>
|
|
Set Resource Recipe Time Out Val
Change-Id: I7f304465c71837ee37e5fa99a48ca14d97d8f91f
Issue-ID: SO-587
Signed-off-by: c00149107 <chenchuanyu@huawei.com>
|
|
Change-Id: Idaa55084f5ecb0dd3636c232cebc14fa5f064309
Issue-ID: SO-578
Signed-off-by: Yulian Han <elaine.hanyulian@huawei.com>
|
|
|
|
Update Delete Resource Flow
Change-Id: Ie6270d954fc1c703de4bdd0c8f1e543a155060d1
Issue-ID: SO-587
Signed-off-by: c00149107 <chenchuanyu@huawei.com>
|
|
There are multiple issues here.
1) The LCM healthcheck and config-scale-out should be made
conditional upon the VNF orchestration status being Active
or Activated. I'm not going to do that with this commit,
since the logic will probably need to be moved to the
DoCreateVfModule flow. What I will do is bypass the LCM
operations to unblock testing. Another ticket will need
to address the real solution.
2) APP-C gave us an API where the controller type is configured
in their client object, which is NOT what we wanted. As a
result, we have to keep a client object for each controller
type. Our implementation did not do this.
3) Need to support the APP-C client configuration properties
for specifying the SDN-C topic names. I'm refactoring the
APP-C client urn mapping names to make it clear that they
are for configuring the APP-C *client* and not necessarily
for APP-C itself.
Change-Id: I588f3b98b4ee44ba53b4931f9f1a7938ee70bebf
Issue-ID: SO-577
Signed-off-by: Rob Daugherty <rd472p@att.com>
|
|
Fix to get the resource from ordered list
Change-Id: I43a7a33a7d2464d7580f175807a1b42d2dce94f2
Issue-ID: SO-422
Signed-off-by: subhash kumar singh <subhash.kumar.singh@huawei.com>
|
|
Fix SDNC resource deletion for E2E service.
Change-Id: I954c39044b4e4384a7941b6b6c5a0cccc57cf9b3
Issue-ID: SO-422
Signed-off-by: subhash kumar singh <subhash.kumar.singh@huawei.com>
|
|
Fix the variables in delete E2E workflow.
Change-Id: I23973d475ebc634f30bbb913d51b581c1222be7a
Issue-ID: SO-422
Signed-off-by: subhash kumar singh <subhash.kumar.singh@huawei.com>
|
|
|
|
|
|
|
|
Fix request header for SDNC resource request.
Change-Id: I254d7139fcbeec00a98f44c8db3661da0425f8c7
Issue-ID: SO-422
Signed-off-by: subhash kumar singh <subhash.kumar.singh@huawei.com>
|
|
Add generic workflow for delete NS.
Change-Id: I2bc1fe01aec3066e7ec6d8627c8bdcb79ce262fc
Issue-ID: SO-422
Signed-off-by: subhash kumar singh <subhash.kumar.singh@huawei.com>
|
|
Update resourceinstanceid for Decomposed service
Change-Id: Iaadd8b6d3fb861058eed56cbf33b3a0dc6a060d0
Issue-ID: SO-587
Signed-off-by: c00149107 <chenchuanyu@huawei.com>
|
|
|
|
|