On Wed, May 16, 2012 at 4:56 AM, Yong Sheng Gong <gong...@cn.ibm.com> wrote:
> Hi, > > https://blueprints.launchpad.net/quantum/+spec/authorization-support-for-quantumis > for server side. On server side, most of our functions even have no > context as a parameter like other project does. I don't know how we will > deal with it. > > It seems the API design is just at the beginning. Is there a special > blueprint for API? > Blueprint is here ( https://blueprints.launchpad.net/quantum/+spec/melange-integration), but exact API is not locked down enough for you to code against yet. If possible, I would focus more on other areas for client improvement for the next week or so (e.g., doing basic keystone integration), by which point the API work should be concrete enough to code against (though some items may still change). Thanks, Dan > > Thanks > > > -----netstack-bounces+gongysh=cn.ibm....@lists.launchpad.net wrote: ----- > To: netstack@lists.launchpad.net > From: Gary Kotton ** > Sent by: netstack-bounces+gongysh=cn.ibm....@lists.launchpad.net > Date: 05/16/2012 04:48PM > Subject: Re: [Netstack] Want to start Keystone support for Quantum Client > > > Hi, > On the IRC meeting last night the following was discussed - > https://blueprints.launchpad.net/quantum/+spec/authorization-support-for-quantum. > Are these tasks mutually exclusive? > I guess that with the Melange addition the client API may also change - > all I have seen is http://etherpad.openstack.org/quantum-v2-api. Hope > that this helps. > Thanks > Gary > > On 05/16/2012 05:44 AM, Yong Sheng Gong wrote: > > hi, > Do we have a blueprint for quantum api2.0? I think we have no need to > change the old clients for 1.0 and 1.1 api. I will have the new client > based on the new api 2.0. > > Thanks. > > > -----Yong Sheng Gong/China/IBM wrote: ----- > To: netstack@lists.launchpad.net > From: Yong Sheng Gong/China/IBM > Date: 05/12/2012 07:21AM > Subject: Want to start Keystone support for Quantum Client > > 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. > Question is how to deal with 'default' tenant? > > What will happen to quantum server > 1. Context filter is added and can be used as filter > > 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? > > 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 > ** > > -- > 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
