Skip to content

Conversation

@jason-fox
Copy link
Contributor

  • Remove config.isCurrentNGSI() clauses from plugins
  • Remove NGSI-v1 Templates
  • Remove V1 options from service
  • Delete NGSI-V1 classes
  • Delete NGSI-V1 tests
  • Convert Keystone and Registry tests to NGSI-v2

- Remove `config.isCurrentNGSI()` clauses from plugins
- Remove NGSI-v1 Templates
- Remove V1 options from service
- Delete NGSI-V1 classes
- Delete  NGSI-V1 tests
- Convert Keystone and Registry tests to NGSI-v2
@jason-fox
Copy link
Contributor Author

Related #966

@jason-fox
Copy link
Contributor Author

@AlvaroVega @fgalan - this is now ready for review. The remaining reduction of 1.5% code coverage may still be NGSI-v1 lava code somewhere or it may be that some additional test cases need to be added (particularly around plugins). Either way I wouldn't feel comfortable modifying the code further as part of this PR.

@fgalan
Copy link
Member

fgalan commented Mar 5, 2021

We are going to start testing on this. To that end, the following (temporal) PRs has been created:

While unit tests have gone fine in the IOTA Manager PR, they are failing in IOTA-UL and IOTA-JSON. Looking at the results, it seems it is not the usual glitch in some AMQP tests, but a massive fail. At least 75 tests are failing in the IOTA-UL case and 80 in the IOTA-JSON case.

Maybe I'm doing something wrong... @jason-fox could you have a look, please?

@mapedraza
Copy link
Collaborator

@AlvaroVega @fgalan - this is now ready for review. The remaining reduction of 1.5% code coverage may still be NGSI-v1 lava code somewhere or it may be that some additional test cases need to be added (particularly around plugins). Either way I wouldn't feel comfortable modifying the code further as part of this PR.

@jason-fox Just to clarify, the idea is to add more test on a separate PR to increase the code coverage that 1.5% or leave it like this?

@jason-fox
Copy link
Contributor Author

jason-fox commented Mar 5, 2021

@mapedraza - leave or add as a subsequent PR. All I've done is delete the NGSI-v1 tests and copied over the obvious tests for non NGSI functionality to use NGSI-v2 requests and responses. I am uncertain where the remaining drop of 1.5% lies - I'm guessing various plugins need to have some NGSI-v1 cleaning to remove dead code, but it could be a coveralls accounting error.

Either way not part of this PR anyway.

@jason-fox
Copy link
Contributor Author

jason-fox commented Mar 5, 2021

At least 75 tests are failing in the IOTA-UL case and 80 in the IOTA-JSON case.
Maybe I'm doing something wrong

The failing tests are provisioned using NGSI-v1. For example

      4) should send one update context per measure group to the Context Broker
time=2021-03-05T10:23:21.547Z | lvl=FATAL | corr=n/a | trans=n/a | op=IoTAgentNGSI.Global | msg=An unexpected exception has been raised. Ignoring: AssertionError [ERR_ASSERTION]: Mocks not yet satisfied:
POST http://192.168.1.1:1026/v1/updateContext

Has a mock which assumes that the IoT Agent upserts a provisioned device using the deprecated /v1/updateContext endpoint. This is no longer occurs since the default configuration is NGSI-v2. Just delete the NGSI-v1 tests and re-run with just the tests in the test/ngsiv2 folder. (I had to do this with the code in the PR as well)

So a 50% failure rate in the Unit Tests is a good thing. 😄

@jason-fox
Copy link
Contributor Author

It should be the case that if the NGSI-v1 tests are deleted for IOTA-JSON and IOT-UL there should not be a significant reduction of coverage. If coverage is reduced then some of the NGSI-v1 tests will need to be converted to NGSI-v2.

@jason-fox
Copy link
Contributor Author

jason-fox commented Mar 5, 2021

Example run for IOTA-JSON with no NGSI-v1 tests : https://github.com/jason-fox/iotagent-json/runs/2041091462?check_suite_focus=true

Deleting all non NGSI-v2 tests. Code coverage drops from 80% to 67%

https://coveralls.io/github/telefonicaid/iotagent-json?branch=master

Some functions such as MQTT Bindings and Config Service are currently extensively tested using NGSI-v1 only using the following tests:

HTTP_commands_test.js			configuration-api_test.js		subscription-management_test.js
HTTP_get-configuration_test.js		supportThinkingThingModules_test.js
MQTT_get-configuration_test.js		startup-test.js

@fgalan
Copy link
Member

fgalan commented May 13, 2021

Take into account that PR #1034 adds some files related with NGSIv1:

  • test/unit/examples/contextRequests/updateContextExpressionPlugin6.json
  • test/unit/examples/contextRequests/updateContextExpressionPlugin7.json
  • test/unit/examples/contextRequests/updateContextExpressionPlugin8.json

These ones should be removed in this PR upon conflict resolution when updated with master.

# Conflicts:
#	lib/plugins/multiEntity.js
@jason-fox
Copy link
Contributor Author

jason-fox commented Sep 1, 2021

@mapedraza - I don't think there is an equivalent NGSI-v2 request to replicate the missing test in queryDeviceInformationInCb-test.js - With v2, if i make the GET request /v2/entities/light1/attrs?attrs=state,dimming&type=Light and the entity hasstate but not dimming then the response is 200 and only state is returned. This differs from NGSI-v1 where the body would include error information.

The missing ATTRIBUTE_NOT_FOUND constructor can now only be fired by covering line https://github.com/telefonicaid/iotagent-node-lib/blob/master/lib/services/ngsi/entities-NGSI-v2.js#L241 and I'm not sure if that is a legitimate NGSI-v2 response.

All the other tests are complete and the reduction remains at 0.7% - I guess much of this is obscure NGSI-v1 edge cases I wouldn't want to look at.

@fgalan
Copy link
Member

fgalan commented Sep 1, 2021

The missing ATTRIBUTE_NOT_FOUND constructor can now only be fired by covering line https://github.com/telefonicaid/iotagent-node-lib/blob/master/lib/services/ngsi/entities-NGSI-v2.js#L241 and I'm not sure if that is a legitimate NGSI-v2 response.

Maybe a warning in the code should be included about this. I mean something like this:

            } else if (errorField.code && errorField.code === '404') {
                // FIXME: not sure if this is a legitimate case in NGSI-v2. Should be checked and removed if no longer needed
                callback(new errors.AttributeNotFound());
            } else {

@fgalan
Copy link
Member

fgalan commented Sep 1, 2021

All the other tests are complete and the reduction remains at 0.7% - I guess much of this is obscure NGSI-v1 edge cases I wouldn't want to look at.

In the case it can help, this is the current (at b1758c3) breakdown (https://coveralls.io/builds/42573501):

imagen

@jason-fox
Copy link
Contributor Author

I'm fairly positive that the following should work:

entities-NGSI-v2.js

         } else if (response && body && response.statusCode === 404) {
             logger.info(
                 context,
                 'Received the following response from the CB:\n\n%s\n\n',
                 JSON.stringify(body, null, 4)
             );
 
             logger.error(context, 'Operation ' + operationName + ' error connecting to the Context Broker: %j', body);
-
-            const errorField = NGSIUtils.getErrorField(body);
-            if (response.statusCode && response.statusCode === 404 && errorField !== undefined) {
+            if ( NGSIUtils.getErrorField(body) !== undefined) {
                 callback(new errors.DeviceNotFound(entityName));
-            } else if (errorField.code && errorField.code === '404') {
-                callback(new errors.AttributeNotFound());
             } else {
                 callback(new errors.EntityGenericError(entityName, typeInformation.type, body));
             }

entities-NGSI-LD.js

         } else if (response && body && response.statusCode === 404) {
             logger.info(context, 'Received the following response from the CB:\n\n%s\n\n', bodyAsString);
 
             logger.error(context, 'Operation ' + operationName + ' error connecting to the Context Broker: %j', body);
 
-            const errorField = NGSIUtils.getErrorField(body);
-            if (
-                response.statusCode &&
-                response.statusCode === 404 &&
-                errorField.details.includes(typeInformation.type)
-            ) {
+            if ( NGSIUtils.getErrorField(body) !== undefined) {
                 callback(new errors.DeviceNotFound(entityName));
-            } else if (errorField.code && errorField.code === '404') {
-                callback(new errors.AttributeNotFound());
             } else {
                 callback(new errors.EntityGenericError(entityName, typeInformation.type, body));
             }
  • The second check for response.statusCode && response.statusCode === 404 is redundant
  • errorField.code is not defined under NGSI-v2 - hence the clause is unnecessary
  • NGSI-LD changes should align with NGSI-v2 - it looks like they have diverged unnecessarily.

Making this change will not break the tests. Should I add it?

@jason-fox
Copy link
Contributor Author

jason-fox commented Sep 1, 2021

Basically saying:

  • If the broker response is a properly formed NGSI error response, then the device is not found.
  • If the broker response is a really nasty error with some random stack trace or something, log as a generic error.

@fgalan
Copy link
Member

fgalan commented Sep 1, 2021

Making this change will not break the tests. Should I add it?

Maybe after these changes the NGSIUtils.getErrorField() function can be removed? It seems a remanent usage in lib/services/devices/registrationUtils.js stills, but maybe that part can be simplified.

@jason-fox
Copy link
Contributor Author

NGSIUtils.getErrorField() used to be split into v1 and v2 versions and certainly can be refactored out.

@fgalan
Copy link
Member

fgalan commented Sep 2, 2021

Making this change will not break the tests. Should I add it?

Maybe after these changes the NGSIUtils.getErrorField() function can be removed? It seems a remanent usage in lib/services/devices/registrationUtils.js stills, but maybe that part can be simplified.

We (@AlvaroVega @mapedraza @fgalan ) agree in doing your suggested changes, along with the removal/refactoring in NGSIUtils.getErrorField(). Please, @jason-fox go ahead.

Thanks!

@jason-fox
Copy link
Contributor Author

Fixed 2304aae - coverage drop now 0.5% or less. I'm assuming the remaining drop is some NGSI-v1 stuff in the IoTManger and middlewares dealing with attributes.

@fgalan
Copy link
Member

fgalan commented Sep 2, 2021

Fixed 2304aae - coverage drop now 0.5% or less. I'm assuming the remaining drop is some NGSI-v1 stuff in the IoTManger and middlewares dealing with attributes.

Looking to the modifications in b1758c3...2304aae, I see getErrorField() has been removed along with two of its usages, in generateNGSI2OperationHandler() and generateNGSILDOperationHandler().

With regards to the third one I see at master within createRegistrationHandler() (https://github.com/telefonicaid/iotagent-node-lib/blob/master/lib/services/devices/registrationUtils.js#L57) I see you have removed the whole createRegistrationHandler() so that's fine :)

@jason-fox
Copy link
Contributor Author

The one in createRegistrationHandler() would have been for NGSI-v1 and would have called the getErrorField() for NGSI-v1. The other two would have been for NGSI-v2 and originally called getErrorFieldv2() or something. Since v1 had been deleted getErrorFieldv2() was renamed to getErrorField() during the refactor. It has now been deleted.

@mapedraza mapedraza self-requested a review September 2, 2021 09:51
@mapedraza
Copy link
Collaborator

mapedraza commented Sep 2, 2021

Great, all tests seems to be ported to V2. Now it is just pending a couple of pending reviews (related with nomenclature stuff):

After that, I think it is almost ready to merge

@jason-fox
Copy link
Contributor Author

Fixed 3be10f7

Copy link
Collaborator

@mapedraza mapedraza left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@fgalan
Copy link
Member

fgalan commented Sep 2, 2021

The PR is in a good shape to start conducting e2e testing with IOTAs (+ Manager) generated from the following branches:

In the meanwhile, this PR would need a CHANGES_NEXT_RELEASE entry. Suggestion:

- Remove: NGSI-v1 implementation (#966)

@jason-fox
Copy link
Contributor Author

Fixed 4a9fd4c

@fgalan
Copy link
Member

fgalan commented Sep 3, 2021

Good news. The CI e2e pass with the NGSIv1-removed versions went OK last night :)

So I think only this small issue is pending to do the merge: telefonicaid/sigfox-iotagent#111 (comment)

Copy link
Member

@fgalan fgalan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. There is still some drop in coverage (around -0.7%) but it's acceptable (taking into account we come from a higher drop)

This PR will now be merged, followed by all the related ones in the IOTAs repositories. Thanks @jason-fox for this huge amount of work and also thanks to @mapedraza for his review work!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants