Skip to content
This repository was archived by the owner on Mar 4, 2024. It is now read-only.

"unsupported operand type" error during unit teardown caused by stale certificates.server.cert.available flag #22

@Vultaire

Description

@Vultaire

If, during removal of a unit using layer:tls-client and interface:tls-certificate, if layer:tls-client's store_server handler gets queued to run before interface:tls-certificate's TlsRequires.joined() method, it can result in errors during teardown under certain circumstances.

This can trigger the following failure:

  File "/var/lib/juju/agents/unit-kubernetes-worker-26/charm/reactive/tls_client.py", line 51, in store_server
    server_cert = server_cert + '\n' + chain
TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'

I have a few units which have hit this issue, which I was attempting to remove from the model when this occurred. They're related to vault, and were formerly related to 3 units, but only one unit remains related. This unit does not have the <unit>.server.cert nor <unit>.server.key values for the unit in question, nor are there any <unit>.processed_requests fields present in the relation either for that unit, and thus TlsRequires.get_server_cert() will return (None, None).

This wouldn't be a problem if layer:tls-client's store_server handler wasn't called. And it shouldn't be called... except that it fires on certificates.server.cert.available, which should be cleared when TlsRequires.joined() is called, except that it won't be called until after store_server is.

Thus, store_server is called, thinking it has a cert to store, when in fact it does not. It pulls get_server_cert, gets a bunch of nothing back, and things blow up as described in the above traceback.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions