Thanks for putting this together Yong! Comments inline.
On Fri, May 11, 2012 at 4:21 PM, Yong Sheng Gong <gong...@cn.ibm.com> wrote: > Hi, > I want to start a blueprint to implement the "*Keystone support for > Quantum Client*" listed in http://wiki.openstack.org/QuantumStarterBugs > > Workflows: > My idea is to make an initial workable quantum client with keystone > service support. > Quantum client's workflow will look like: > 1. To send auth request to keystone and get token and related service > catalog and other stuff > 2. To send request to quantum server with X-Auth-Token in header > workflow on Quantum server side: > 1. keystone's authtoken filter will auth and cache this token, and then > will populate the related stuff into http headers > 2. context filter will create context according to the populated http > headers > > Next step is to use this context to check policy. I have not seen any > functions which have context as first parameter just like what we do in > nova project. How will we use the populated context? Use is as a thread > variable or modify all the related functions? Also how about the agent? Do > agents need auth? > > What will happen to quantum client: > present: > [root@robinlinux glance]# quantum > Usage: quantum [OPTIONS] <command> [args] > > Options: > -h, --help show this help message and exit > -H HOST, --host=HOST ip address of api host > -p PORT, --port=PORT api poort > -s, --ssl use ssl > -v, --verbose turn on verbose logging > -f LOGFILE, --logfile=LOGFILE > log file path > -t TOKEN, --token=TOKEN > authentication token > --version=VERSION Accepts 1.1 and 1.0, defaults to > env[QUANTUM_VERSION]. > > Commands: > list_nets <tenant-id> [filterspec ...] > create_net <tenant-id> <net-name> > unplug_iface <tenant-id> <net-id> <port-id> > plug_iface <tenant-id> <net-id> <port-id> <iface-id> > update_port <tenant-id> <net-id> <port-id> <params> > show_port_detail <tenant-id> <net-id> <port-id> > show_net <tenant-id> <net-id> > delete_port <tenant-id> <net-id> <port-id> > delete_net <tenant-id> <net-id> > list_nets_detail <tenant-id> [filterspec ...] > show_net_detail <tenant-id> <net-id> > show_iface <tenant-id> <net-id> <port-id> > update_net <tenant-id> <net-id> <new-name> > show_port <tenant-id> <net-id> <port-id> > list_ports_detail <tenant-id> <net-id> [filterspec ...] > create_port <tenant-id> <net-id> > list_ports <tenant-id> <net-id> [filterspec ...] > > after > we will have > quantum [--debug] [--os_username OS_USERNAME] [--os_password OS_PASSWORD] > [--os_tenant_name OS_TENANT_NAME] [--os_auth_url OS_AUTH_URL] > [--os_region_name OS_REGION_NAME] [--os_auth_token > OS_AUTH_TOKEN] > [--region_name REGION_NAME] > [--endpoint_url url] command args > So the first tenant-id parameter will be replaced by value returned from > keystone. > Yes, that is correct. The credentials specified by the user (either via the env variables or explicit flags) will replace the need to specify <tenant-id> > Question is how to deal with 'default' tenant? The entire notion of a "default" tenant was just a hack for backward compatibility with existing nova-manage commands where no specific tenant was specified. In general, I think it should go away, so I wouldn't worry about it here. The folks working on Authn/Authz ( https://blueprints.launchpad.net/quantum/+spec/authorization-support-for-quantum) will still need to come up with a strategy for how "global" networks (e.g., a cloud's public network) can be shared across tenants, but I would strongly advocate that all Quantum networks are created by a user identified by a real keystone tenant-id. > > > What will happen to quantum server > 1. Context filter is added and can be used as filter > troytoman, heckj, and others are working on the server side of this, so I will leave it to them to comment on their plans here. > > Other question: > If it is ok, should I add one new blueprint or just do it under blueprint > https://blueprints.launchpad.net/quantum/+spec/new-cli? I think Jason is cool with this, so I'll reassign that existing blueprint to you. Dan > > > Thanks > Yong Sheng Gong > > > -- > Mailing list: https://launchpad.net/~netstack > Post to : netstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~netstack > More help : https://help.launchpad.net/ListHelp > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira, Inc: www.nicira.com twitter: danwendlandt ~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
