Mastodon: provision actor

[jernst]

We don't want hard-coded actors if we can avoid it.

Use tootctl accounts create { new_username } --approve to create them on UBOS. (There does not seem to be a way that can be automated on non-UBOS)

This needs to be invoked when tests attempt to obtain Actors in roles that haven't been used yet.

We should use some kind of predictable username creator for new_username above.

[steve-bate]

There does not seem to be a way that can be automated on non-UBOS

A UBOS alternative is a (e.g., Docker) container that has the actors already provisioned. In my experience, several (5) pre-provisioned actors were sufficient for AP tests. I currently don't understand the benefit of the dynamically-provisioned actors.

[jernst]

I see a bunch of advantages to avoid restoring from a previously saved state (as we already do with the .ubos-backup file for WordPress due to a lack of other alternatives to get the plugins activated):

• The workflow to maintain them is separate from the code release process and involves manual steps
• Harder to put under configuration control
• The configuration is dependent on the application version, so we potentially need to redo it for each version, and that adds further complexity
• if we used this mechanism for something like pre-provisioning actors, the cost of doing so grows linearly with the number of actors
• I think UBOS handles restore-to-Mastodon correctly even if the hostname to which the backup is restored is different from where Mastodon runs now (which we need to be able to run constellations with more than one Mastodon instance in them) but it adds further potential brittleness.

[jernst]

Done in #252.