yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #00039
[Blueprint separate-nova-adminapi] Separate Nova Admin API
Blueprint changed by OpenStack Hudson:
Whiteboard changed:
Implementing this by adding rbac checking to extensions so we don't
actually need separate logic for admin extensions.
It looks like the best approach is to break out each piece of admin api
functionality into a separate OpenStack Compute API extension.
Gerrit topic: https://review.openstack.org/#q,topic:bp/separate-nova-
adminapi,n,z
Addressed by: https://review.openstack.org/2354
Creating mechanism that loads Admin API extensions
Is there some info that can be shared on why extensions was chose
instead of a separate api? (maybe just some pros/cons)
(bcwaldon) The driving reason is that I didn't want to duplicate code we
could get for free by stacking extensions on top of the existing compute
api. The extension mechanism is actually designed to handle exactly this
case (implementation-driven functionality).
Addressed by: https://review.openstack.org/2528
Move 'diagnostics' subresource to admin extension
Gerrit topic: https://review.openstack.org/#q,topic:bug/897091,n,z
Addressed by: https://review.openstack.org/2547
Move 'actions' subresource into extension
Addressed by: https://review.openstack.org/2548
Make os-server-diagnostics extension admin-only
Addressed by: https://review.openstack.org/2550
Move createBackup server action into extension
Addressed by: https://review.openstack.org/2584
Converting accounts resource to admin extension
Addressed by: https://review.openstack.org/2585
Convering /users to admin extension
Addressed by: https://review.openstack.org/2610
Converting zones into true extension
Addressed by: https://review.openstack.org/3091
Policy-check admin actions extension
+
+
+ Addressed by: https://review.openstack.org/3236
+ Remove admin_only ext attr in favor of authz
--
Separate Nova Admin API
https://blueprints.launchpad.net/nova/+spec/separate-nova-adminapi