Default token-expiration of 1 hour causes live-migration failure states

When performing live host evacuations/live-migrations, it has been found that if a migration takes longer than the token timeout period, the migration will complete, but the metadata updates such as network-vif-plugged (nova-compute talking to neutron-api upon completion of libvirt live-migration) on the destination host fail due to the token being expired.

I believe that there are three main concerns surrounding token expiration:

1. time limitation reduces exposure for the platform for compromised tokens or compromised workstations. (think horizon auto-logouts, etc)

2. the volume of managed tokens to store in the database is directly related to the amount of time the tokens are valid and the regularity of the keystone_manage token expiration cron cycles, the volume of which can affect keystone response rates for authentication.

3. HR action response (leaving cloud user can potentially still auth if they have a valid token, if all that is done is locking/disabling the user's password)

On a cloud I was recently migrating workloads on, a 2TB vm took roughly 5.5 hours to migrate. This is a common database size that may be landed on local ephemeral storage and need to be maintained when performing maintenance on a hypervisor by live-migration to another hypervisor. With an average environment hosting upwards of 4-10TB of ephemeral storage per node, evacuation of a node using a single authentication token (as in the case of nova host-evacuate-live <hypervisorname>) would require upwards of 24 hours to migrate.

I'd like to suggest for day 2 operations of the cloud that we consider raising the default token-expiration to 1 day from the current 1 hour setting.