[openstack-dev] Heat, High Availability and Keystone

Ian Main imain at redhat.com
Thu Aug 30 19:40:46 UTC 2012


Howdy folks,

So I've been doing some research lately into how to best support high
availability (HA) in heat-api.  The crux of the issue is that we need to
be able to perform operations on instances, volumes etc. some time after
we initially create them in order to perform restorative actions.  This
creates an issue with the authentication needed to perform these
operations.  I am posting to the list in the hope that we can get some
better ideas or hash out a good solution to this problem.

Our current solution is to store the user credentials (either
ec2 access/secret key or keystone user/pass etc) in the database
(symmetrically encrypted) and use them to reauthenticate at a later date.
This could get hairy if the user was removed or changed tenants etc.

The good:
- It's easy for admins.
- It works today.
- With encryption it's not too terribly insecure.
- Quota and billing is as it should be.

Cons:
- Encryption passwd is in the config file.
- If a user state changes the stack (instances) could lose HA abilities
  unexpectedly.

There are other options we could persue as well such as having an
'admin' user with a role in each tenant allowing us to perform
operations in that tenant as admin so we do not lose billing & quota
info.  This however requires the admin to add a role for each new tenant
and could be error prone.

Pros:
- HA operations are performed by an 'admin' in the tenant and should
  always be available.
- Billing and quota info is still available although the billing may
  get odd as the user id could change on VM restart.
- It could work today.

Cons:
- Requires more setup by the admin.  The scary part being everything
  would seem to work fine until HA was needed.  Although we could
  verify HA authentication when creating the stack.
- If custom billing app used user_id it could confuse someone.

Another proposal was to possibly extend keystone with the ability to
'sign' HA operations so they can be performed at a later time with a
signature or token.

Pros:
- Quite possibly very secure.
- Probably could be built so it doesn't matter if the user is gone?
- Would preserve billing/quotas.

Cons:
- Not in existence. :)
- Possibly rather complex.

I see also that there is a proposal for domains to be added to keystone:

https://blueprints.launchpad.net/keystone/+spec/keystone-domains

However I couldn't tell what the status of that was or if that would
clearly provide a solution to our HA needs.

So that is the background of the present situation.  I am hoping that
this thread can lead to some new ideas or possibly some clear direction
going forward.

Thanks!

    Ian




More information about the OpenStack-dev mailing list