Use the common etcd client in etos-iut

[andmat900]

Applicable Issues

• ETOS API: etos-iut should use the generic etcd client etos#283

Description of the Change

This change migrates the generic ETOS IUT Provider to the common etcd client of ETOS API.

Alternate Designs

Possible Drawbacks

Sign-off

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or

(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or

(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.

(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.

Signed-off-by: Andrei Matveyeu, [email protected]

[fredjn]

Why is this added? and why in the write function?

[andmat900]

This client shall implement the io.ReadWriter interface. The ETOS API applications are designed in a way that a database client shall be easily swapped with any other client which implements this common interface.

[t-persson]

I think the question is why are we adding delete in the write function. A question I also have

[andmat900]

If all potential database clients are supposed to conform to io.ReadWriter interface and be swappable, we have no other choice.

The io.ReadWriter interface seems to be more-suitable for a storage like a binary file, but here it requires workarounds to fit it into a key-value pair storage like etcd.

[t-persson]

I would rather we write a null value into the database rather than having this function do things that it shouldn't do.

If deletion is required then we should have a separate interface for that and in the Stop function cast the database to that interface to see if it is possible to delete.

client := h.database.Open(r.Context(), identifier)
c, canDelete := client.(database.Deleter)
if canDelete {
  err := c.Delete()
} else {
  _, err = client.Write(nil)
}

[fredjn]

Are we really doing a lookup here?

[andmat900]

In line 190 we do a look up by reading from the database.

[t-persson]

The only function that needs Delete is the stop function which only needs a struct implementing Delete.
Why not just do a DatabaseDelete interface (or Deleter) and then do a simple type-case to that interface in the only case we need it?

var err error
client, ok := h.database.Open(r.Context(), identifier).(Deleter)
if !ok {
    logger.Warning("the database does not support delete, writing nil")
    err = client.Write(nil)  // Write a nil value to the database, don't delete.
} else {
    err = client.Delete()
}
if err != nil {
    // blabla
}

This way our databases don't need to support Delete all the time.

[andmat900]

I don't think this is better than the suggested interface solution. Your code includes an if-statement in the client, a cast and a warning.

Delete() is reasonable to have for any database as an extension on top of io.ReadWriter which is originally for binary fields.

[t-persson]

Correct that we add more code with my suggestion.
The casting is not really a problem because it is a check to see whether 'Delete' exists in this database implementation. The warning is not necessary.

The reason I don't want to force all databases to have Delete is because I can see us adding a "FileDatabase" for testing which does not necessarily have the delete capability.

[andmat900]

If one implementation does not support deleting, the Delete() method can be left empty. But generally databases will have some kind of deleting.