Default token-expiration of 1 hour causes live-migration failure states
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Keystone Charm |
Triaged
|
High
|
Unassigned |
Bug Description
When performing live host evacuations/
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.
Changed in charm-keystone: | |
status: | New → Triaged |
importance: | Undecided → High |
milestone: | none → 20.05 |
milestone: | 20.05 → 20.02 |
Changed in charm-keystone: | |
milestone: | 20.02 → 20.05 |
Changed in charm-keystone: | |
milestone: | 20.05 → 20.08 |
Changed in charm-keystone: | |
milestone: | 20.08 → none |
This bug may be related to my long-running migration issues: https:/ /bugs.launchpad .net/nova/ +bug/1657774