Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change iSCSI storage connection validation to properly avoid duplications #551

Merged

Conversation

mkemel
Copy link
Member

@mkemel mkemel commented Jul 24, 2022

Currently when adding/updating iSCSI storage server connection, there
is a validation that checks if a duplicate connection exists by iqn,
address, port, portal, username and password. This allows creating
two storage connections with the same iqn, address and port, but with
different portals.

There cannot be two portals with the same iqn-address-port, thus
creating two such connections does not make sense and will lead to
errors connecting the host to storage.

This change fixes the validation to fail add/update request if
connection with the same iqn-address-port combination exists

Bug-Url: https://bugzilla.redhat.com/2079903

AND (connection = v_connection)
AND (
port = v_port
OR (
Copy link
Member

Choose a reason for hiding this comment

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

If port and v_port are NULL, wouldn't the first part port = v_port catch it?
Is this OR required?

Copy link
Member Author

Choose a reason for hiding this comment

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

Good point. I actually copied it from the previously used query, but I can't quite understand what is the purpose of this check. In our case these values should not be null anyway.

connection.getPort(),
connection.getIqn()
);
if (connections != null && !connections.isEmpty()) {
Copy link
Member

Choose a reason for hiding this comment

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

IMHO can be simplified:

if (CollectionUtils.isEmpty(connections)) {
  return null;
}
return connections.get(0);

Copy link
Member

Choose a reason for hiding this comment

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

it can be simplified even further - the result should never be null

@ahadas ahadas added the storage label Jul 24, 2022
@@ -80,7 +80,7 @@ protected String isConnWithSameDetailsExists(StorageServerConnections connection
String connectionField = connection.getConnection();
connections = storageServerConnectionDao.getAllForStorage(connectionField);
} else {
StorageServerConnections sameConnection = iscsiStorageHelper.findConnectionWithSameDetails(connection);
StorageServerConnections sameConnection = iscsiStorageHelper.findConnectionByAddressPortAndIqn(connection);
Copy link
Member

Choose a reason for hiding this comment

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

is there a reason not to change findConnectionWithSameDetails?

Copy link
Member Author

Choose a reason for hiding this comment

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

It is used elsewhere, there's even a comment that warns you from changing it

Copy link
Member

Choose a reason for hiding this comment

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

Another thought: maybe better if findConnectionByAddressPortAndIqn() to simply return the list of all connections as received from storageServerConnectionDao.getStorageConnectionsByConnectionPortAndIqn (that can be or not be an empty list)?
That will simplify the findConnectionByAddressPortAndIqn() method (that just needs to be renamed to plural "Connections"), will simplify this method (just put the result into connections local variable). No need for all those List --> single element --> back to List redundant code.

Copy link
Member Author

Choose a reason for hiding this comment

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

Nice. Done

connection.getPort(),
connection.getIqn()
);
if (connections != null && !connections.isEmpty()) {
Copy link
Member

Choose a reason for hiding this comment

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

it can be simplified even further - the result should never be null

@mkemel mkemel force-pushed the storage_connection_validation_fix branch from 41f92d2 to e903e2b Compare July 24, 2022 14:05
@mkemel mkemel changed the title core: change iSCSI storage connection validation to properly avoid duplications Change iSCSI storage connection validation to properly avoid duplications Jul 25, 2022
@mkemel mkemel force-pushed the storage_connection_validation_fix branch from e903e2b to c4154fa Compare July 26, 2022 05:38
@ahadas
Copy link
Member

ahadas commented Jul 26, 2022

/ost

@@ -207,6 +207,14 @@ public StorageServerConnections findConnectionWithSameDetails(StorageServerConne
return null;
}

public List<StorageServerConnections> findConnectionByAddressPortAndIqn(StorageServerConnections connection) {
Copy link
Member

Choose a reason for hiding this comment

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

Maybe rename to findConnectionsByAddressPortAndIqn?
Add "s" for plural...

Copy link
Member Author

Choose a reason for hiding this comment

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

Ack

Currently when adding/updating iSCSI storage server connection, there
is a validation that checks if duplicate connection exists by iqn,
address, port, portal, username and password. This allows creating
two storage connections with the same iqn, address and port, but with
different portals.

There cannot be two portals with the same iqn-address-port, thus
creating two such connections does not make sense and will lead to
errors connecting the host to storage.

This change fixes the validation to fail add/update request if
connection with the same iqn-address-port combination exists

Bug-Url: https://bugzilla.redhat.com/2079903
@mkemel mkemel force-pushed the storage_connection_validation_fix branch from c4154fa to cfbf20d Compare July 27, 2022 10:55
@barpavel barpavel self-requested a review July 27, 2022 13:30
Copy link
Member

@barpavel barpavel left a comment

Choose a reason for hiding this comment

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

LGTM :)

@michalskrivanek michalskrivanek merged commit 7543e6b into oVirt:master Jul 28, 2022
@mkemel mkemel deleted the storage_connection_validation_fix branch November 27, 2022 10:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants