We do have some plans to renovate the way we've modeled user (for example, to use a primary key instead of username as an internal identifier).
However, it will not cover re-using usernames. Usernames must be unique for several reasons - non-repudiation and audit being some of them. Reinventing and inventing unique usernames are standard practice everywhere: if you have 2 employees that want the same username, they are generally forced to append a number or some similar tactic.
So given that:
1. we will not physically delete a user from our database (only logical deletes take place);
2. you as an operator want to re-use usernames from 'logically deleted' users;
3. we will be using user's primary key to link Juju components such as user permissions on models, etc...
then we can allow you to re-user a username as long as all other occurrences of this username are associated with 'logically deleted' users.
We do have some plans to renovate the way we've modeled user (for example, to use a primary key instead of username as an internal identifier).
However, it will not cover re-using usernames. Usernames must be unique for several reasons - non-repudiation and audit being some of them. Reinventing and inventing unique usernames are standard practice everywhere: if you have 2 employees that want the same username, they are generally forced to append a number or some similar tactic.
So given that:
1. we will not physically delete a user from our database (only logical deletes take place);
2. you as an operator want to re-use usernames from 'logically deleted' users;
3. we will be using user's primary key to link Juju components such as user permissions on models, etc...
then we can allow you to re-user a username as long as all other occurrences of this username are associated with 'logically deleted' users.