✨(dimail) send domain creation request to dimail

[mjeammet]

Purpose

Send domain creation request to dimail when someone creates a domain in people.

Proposal

Description...

• write function in dimail client
• write an all-OK test
• check actual dimail response upon sending only the "name" of the domain (and check which features must be enabled for valid domain)
  ...

[qbey]

Is there a reason, not to use the responses "classic" way? By classic I mean using the test function decorator responses.activate along with

    responses.add(
        responses.POST,
        url=re.compile(r".*/domains/"),
        json={
            "name": domain_name,
        },
        status=status.HTTP_201_CREATED,
    )

which seems (to me) a bit more readable.

[mjeammet]

I haven't had the time to make this PR but I absolutely want to make a fixture to encapsulate these responses !

I don't know responses.activate but will try to investigate soon.

[qbey]

As error is an exception, why don't you use logger.exception?

[mjeammet]

Absolutely, I just didn't know there was a dedicated function but that's even better!

About this very line; I might change it for the error to be logged but the response to be passed as is (without exception).

[Morendil]

Seems that the only thing we need is to spin up the dimail container, so I propose to pick up this PR. @sdemagny if you want to pair on this ?

[Morendil]

Apparently it's not that simple ? I've tried adding the dimail container to the runtime dependencies in docker-compose, but we see the domain creation command failing with this error in the dimail logs: "You need to init the db by giving me a valid URL".

Further, it seems that the dimail image in the registry hasn't been updated in some time, so in CI we are testing against outdated code. @chrnin Any ideas ?

[Morendil]

I think I have a pretty good idea now where this was going wrong. Not one single thing but a bunch of small fixes needed on both Régie and Dimail sides.

• aim to have a "stable" dimail image (as opposed to "latest" which can be too cutting-edge) to code against
• add dimail container to app-dev dependencies in Régie's docker-compose
• use start-dev.sh for the starting command and not entrypoint.sh
• on the Dimail side this start-dev.sh needs to listen on 0.0.0.0 not localhost
• on Régie side, use the more recent schema for the POST /domains request body
• fix the debug logging on Régie side, it's too scarce on details (and breaks owing to trying too hard with UTF-8)
• on the Dimail side the DB was not being fully initialized in FAKE mode

So this needs coordination between an update to this PR and an MR on Dimail.

Stepping back from the nitty-gritty details, a bigger lesson for me is that unless coordination between Régie and Dimail development is more fluid (e.g. by trying cross-team pairing), the lead time for changes of this sort could be intolerably long: weeks to months…

[Morendil]

Fixes for Dimail submitted: https://gitlab.mim-libre.fr/dimail/dimail-api/-/merge_requests/51

[Morendil]

Fixes pushed to this PR for the other points. Waiting on the MR to be merged on dimail side.

[Morendil]

Finally good to go 🎉 after fixing a few remaining tests and changing inter-container communication in CI to use Docker's internal networking between app and Dimail.