Re: [Netstack] Want to start Keystone support for Quantum Client

Wed, 16 May 2012 06:01:16 -0700 

On 05/16/2012 02:56 PM, Yong Sheng Gong wrote:

Hi,
https://blueprints.launchpad.net/quantum/+spec/authorization-support-for-quantum is 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?

Not that I am aware of.


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 
<https://launchpad.net/%7Enetstack>

Post to     : netstack@lists.launchpad.net

Unsubscribe : https://launchpad.net/~netstack 
<https://launchpad.net/%7Enetstack>

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






















					Reply via email to