Blueprint changed by OpenStack Hudson: Whiteboard changed: 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
-- Separate Nova Admin API https://blueprints.launchpad.net/nova/+spec/separate-nova-adminapi -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
