Mailing List Archive: Want to start Keystone support for Quantum Client

Want to start Keystone support for Quantum Client

May 11, 2012, 4:21 PM

Post #1 of 15 (4409 views)

Hi,
I want to start a blueprint to implement the "Keystone support for Quantum Client" listed in http://wiki.openstack.org/QuantumStarterBugs"]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"]https://blueprints.launchpad.net/quantum/+spec/new-cli?

Thanks
Yong Sheng Gong

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

jkoelker at rackspace

May 11, 2012, 4:44 PM

Post #2 of 15 (4362 views)

Permalink

On Sat, 2012-05-12 at 07:21 +0800, Yong Sheng Gong wrote:
> Hi,
> I want to start a blueprint to implement the "Keystone support for
> Quantum Client" listed in http://wiki.openstack.org/QuantumStarterBugs
>
I would recommend helping the common client guys out with their
implementation.

Happy Hacking!

7-11

--
Mailing list: https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp

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

jkoelker at rackspace

May 11, 2012, 5:06 PM

Post #3 of 15 (4366 views)

Permalink

On Fri, 2012-05-11 at 18:44 -0500, Jason KÃ¶lker wrote:
> On Sat, 2012-05-12 at 07:21 +0800, Yong Sheng Gong wrote:
> > Hi,
> > I want to start a blueprint to implement the "Keystone support for
> > Quantum Client" listed in http://wiki.openstack.org/QuantumStarterBugs
> >
> I would recommend helping the common client guys out with their
> implementation.

Finally found the bluprint url
https://blueprints.launchpad.net/python-openstackclient/+spec/quantum-client

It looks to be wide open as far as actual implementation details in the
library side.

Happy Hacking!

7-11

--
Mailing list: https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp

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

gongysh at cn

May 14, 2012, 5:35 AM

Post #4 of 15 (4366 views)

Permalink

Hi,
How can I help with the common openstack client? I think quantum needs its own client to be implemented first and then common openstack client (just as a thin wrapper) can call the client module if we have quantum client designed as nova client.

Thanks

-----netstack-bounces+gongysh=cn.ibm.com@lists.launchpad.net wrote: -----To: netstack@lists.launchpad.net
From: Jason KÃ¶lker
Sent by: netstack-bounces+gongysh=cn.ibm.com@lists.launchpad.net
Date: 05/12/2012 08:06AM
Subject: Re: [Netstack] Want to start Keystone support for Quantum Client

On Fri, 2012-05-11 at 18:44 -0500, Jason KÃ¶lker wrote:
> On Sat, 2012-05-12 at 07:21 +0800, Yong Sheng Gong wrote:
> > Hi,
> > I want to start a blueprint to implement the "Keystone support for
> > Quantum Client" listed in http://wiki.openstack.org/QuantumStarterBugs"]http://wiki.openstack.org/QuantumStarterBugs
> >
> I would recommend helping the common client guys out with their
> implementation.

Finally found the bluprint url
https://blueprints.launchpad.net/python-openstackclient/+spec/quantum-client"]https://blueprints.launchpad.net/python-openstackclient/+spec/quantum-client

It looks to be wide open as far as actual implementation details in the
library side.

Happy Hacking!

7-11

--
Mailing list: https://launchpad.net/%7Enetstack"]https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/%7Enetstack"]https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp"]https://help.launchpad.net/ListHelp
Hi,
I want to start a blueprint to implement the "Keystone support for Quantum Client" listed in http://wiki.openstack.org/QuantumStarterBugs"]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"]https://blueprints.launchpad.net/quantum/+spec/new-cli?

Thanks
Yong Sheng Gong

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

dan at nicira

May 14, 2012, 9:30 AM

Post #5 of 15 (4355 views)

Permalink

Thanks for putting this together Yong!

Comments inline.

On Fri, May 11, 2012 at 4:21 PM, Yong Sheng Gong <gongysh@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
~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

jkoelker at rackspace

May 14, 2012, 1:02 PM

Post #6 of 15 (4356 views)

Permalink

On Mon, 2012-05-14 at 09:30 -0700, Dan Wendlandt wrote:
> I think Jason is cool with this, so I'll reassign that existing
> blueprint
> to you.

I am definitely cool with it ;)

Happy Hacking!

7-11

--
Mailing list: https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp

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

gongysh at cn

May 15, 2012, 7:44 PM

Post #7 of 15 (4353 views)

Permalink

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"]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"]https://blueprints.launchpad.net/quantum/+spec/new-cli?

Thanks
Yong Sheng Gong

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

gkotton at redhat

May 16, 2012, 1:48 AM

Post #8 of 15 (4353 views)

Permalink

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
>

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

gongysh at cn

May 16, 2012, 4:56 AM

Post #9 of 15 (4349 views)

Permalink

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

Thanks

-----netstack-bounces+gongysh=cn.ibm.com@lists.launchpad.net wrote: -----To: netstack@lists.launchpad.net
From: Gary Kotton
Sent by: netstack-bounces+gongysh=cn.ibm.com@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"]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"]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"]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"]https://blueprints.launchpad.net/quantum/+spec/new-cli?

Thanks
Yong Sheng Gong

--
Mailing list: https://launchpad.net/%7Enetstack"]https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/%7Enetstack"]https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp"]https://help.launchpad.net/ListHelp

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

gkotton at redhat

May 16, 2012, 5:10 AM

Post #10 of 15 (4352 views)

Permalink

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.com@lists.launchpad.net wrote: -----
> To: netstack@lists.launchpad.net
> From: Gary Kotton
> Sent by: netstack-bounces+gongysh=cn.ibm.com@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

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

heckj at me

May 16, 2012, 8:37 AM

Post #11 of 15 (4359 views)

Permalink

Morning Yong,

Glance, Keystone, and Nova are all using the policy mechanism that Termie created in their code bases, and I think it would be exceptionally easy to port it over into Quantum.

within the nova codebase, look at nova/policy.py and etc/nova/policy.json. The nova codebase is also using a simple wrapper called "wrap_check_policy" and a subsidary method check_policy.py (defined in nova/compute/api.py): that uses the api functional name to check against the policy setup to determine if an API is allowed to be called or not.

nova/tests/test_policy.py is exercising it, if you'd like to see the tests that drive it to get a sense of how it does its thing.

I haven't dug into the Quantum API calls, but the same or very similiar mechanism could be used to quickly port this into Quantum and solve your authorization needs using the same methods the other systems are with Keystone.

I'm presuming that you're already using token_auth in the WSGI pipeline to the API, which is setting additional context after verifying access (right now token based with Keystone). The check_policy assumes the context has some specific keys available within it.

If you'd like help with enabling that, or porting it, I'd be happy to offer advice on the code and review any changes. I rather intended to do some of this porting myself, but I found myself under the gun for the F1 milestone within keystone itself and getting some tasks done there. (which is all a rather sheepish apology to Dan for not being able to get this earlier)

-joe (lurking keystone PTL)

On May 16, 2012, at 5:10 AM, Gary Kotton wrote:
> 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.com@lists.launchpad.net wrote: -----
>> To: netstack@lists.launchpad.net
>> From: Gary Kotton
>> Sent by: netstack-bounces+gongysh=cn.ibm.com@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

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

gongysh at cn

May 16, 2012, 5:38 PM

Post #12 of 15 (4348 views)

Permalink

Hi Joseph,
Thanks for the information. I will first make quantum client to support keystone and then go to the server side.
I will ask advice from you about it soon.

Thanks again.

-----Joseph Heck <heckj@me.com> wrote: -----To: Yong Sheng Gong/China/IBM@IBMCN
From: Joseph Heck <heckj@me.com>
Date: 05/16/2012 11:37PM
Cc: netstack@lists.launchpad.net, gkotton@redhat.com
Subject: Re: [Netstack] Want to start Keystone support for Quantum Client

Morning Yong,
Glance, Keystone, and Nova are all using the policy mechanism that Termie created in their code bases, and I think it would be exceptionally easy to port it over into Quantum.
within the nova codebase, look at nova/policy.py and etc/nova/policy.json. The nova codebase is also using a simple wrapper called "wrap_check_policy" and a subsidary method check_policy.py (defined in nova/compute/api.py): that uses the api functional name to check against the policy setup to determine if an API is allowed to be called or not.
nova/tests/test_policy.py is exercising it, if you'd like to see the tests that drive it to get a sense of how it does its thing.
I haven't dug into the Quantum API calls, but the same or very similiar mechanism could be used to quickly port this into Quantum and solve your authorization needs using the same methods the other systems are with Keystone.
I'm presuming that you're already using token_auth in the WSGI pipeline to the API, which is setting additional context after verifying access (right now token based with Keystone). The check_policy assumes the context has some specific keys available within it.
If you'd like help with enabling that, or porting it, I'd be happy to offer advice on the code and review any changes. I rather intended to do some of this porting myself, but I found myself under the gun for the F1 milestone within keystone itself and getting some tasks done there. (which is all a rather sheepish apology to Dan for not being able to get this earlier)
-joe (lurking keystone PTL)
On May 16, 2012, at 5:10 AM, Gary Kotton wrote:

On 05/16/2012 02:56 PM, Yong Sheng Gong wrote:
Hi,
https://blueprints.launchpad.net/quantum/+spec/authorization-support-for-quantum"]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.com@lists.launchpad.net wrote: ----- To: netstack@lists.launchpad.net
From: Gary Kotton
Sent by: netstack-bounces+gongysh=cn.ibm.com@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"]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"]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"]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"]https://blueprints.launchpad.net/quantum/+spec/new-cli?

Thanks
Yong Sheng Gong

--
Mailing list: https://launchpad.net/%7Enetstack"]https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/%7Enetstack"]https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp"]https://help.launchpad.net/ListHelp

--
Mailing list: https://launchpad.net/%7Enetstack"]https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/%7Enetstack"]https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp"]https://help.launchpad.net/ListHelp

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

dan at nicira

May 17, 2012, 8:55 AM

Post #13 of 15 (4331 views)

Permalink

On Wed, May 16, 2012 at 4:56 AM, Yong Sheng Gong <gongysh@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.com@lists.launchpad.net wrote: -----
> To: netstack@lists.launchpad.net
> From: Gary Kotton **
> Sent by: netstack-bounces+gongysh=cn.ibm.com@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
~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

gongysh at cn

May 20, 2012, 5:25 AM

Post #14 of 15 (4341 views)

Permalink

Hi Joseph,
I have got the quantum client ready. So Next step is to get the server support for keystone.
For policy, Is there still a need for local server to define a policy.json file? I think we have a plan to move all the policies into keystone server. right?

After comparing all other policy check way, I like the nova's one which uses decorator.

For now, Quantum server has no a API layer just like nova. In quantum server, the routes's controllers will call quantum plugin to do job. I think we have to apply the policy check on(decorator) or in(method call) controllers' methods. This is the way glance is adopting.

Thanks
Yong Sheng Gong

-----Joseph Heck <heckj@me.com> wrote: -----To: Yong Sheng Gong/China/IBM@IBMCN
From: Joseph Heck <heckj@me.com>
Date: 05/16/2012 11:37PM
Cc: netstack@lists.launchpad.net, gkotton@redhat.com
Subject: Re: [Netstack] Want to start Keystone support for Quantum Client

Morning Yong,
Glance, Keystone, and Nova are all using the policy mechanism that Termie created in their code bases, and I think it would be exceptionally easy to port it over into Quantum.
within the nova codebase, look at nova/policy.py and etc/nova/policy.json. The nova codebase is also using a simple wrapper called "wrap_check_policy" and a subsidary method check_policy.py (defined in nova/compute/api.py): that uses the api functional name to check against the policy setup to determine if an API is allowed to be called or not.
nova/tests/test_policy.py is exercising it, if you'd like to see the tests that drive it to get a sense of how it does its thing.
I haven't dug into the Quantum API calls, but the same or very similiar mechanism could be used to quickly port this into Quantum and solve your authorization needs using the same methods the other systems are with Keystone.
I'm presuming that you're already using token_auth in the WSGI pipeline to the API, which is setting additional context after verifying access (right now token based with Keystone). The check_policy assumes the context has some specific keys available within it.
If you'd like help with enabling that, or porting it, I'd be happy to offer advice on the code and review any changes. I rather intended to do some of this porting myself, but I found myself under the gun for the F1 milestone within keystone itself and getting some tasks done there. (which is all a rather sheepish apology to Dan for not being able to get this earlier)
-joe (lurking keystone PTL)
On May 16, 2012, at 5:10 AM, Gary Kotton wrote:

On 05/16/2012 02:56 PM, Yong Sheng Gong wrote:
Hi,
https://blueprints.launchpad.net/quantum/+spec/authorization-support-for-quantum"]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.com@lists.launchpad.net wrote: ----- To: netstack@lists.launchpad.net
From: Gary Kotton
Sent by: netstack-bounces+gongysh=cn.ibm.com@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"]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"]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"]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"]https://blueprints.launchpad.net/quantum/+spec/new-cli?

Thanks
Yong Sheng Gong

--
Mailing list: https://launchpad.net/%7Enetstack"]https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/%7Enetstack"]https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp"]https://help.launchpad.net/ListHelp

--
Mailing list: https://launchpad.net/%7Enetstack"]https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/%7Enetstack"]https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp"]https://help.launchpad.net/ListHelp

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

heckj at me

May 20, 2012, 3:37 PM

Post #15 of 15 (4338 views)

Permalink

We plan to have keystone support CRUD operations for those policy files with the next API, but that API hasn't yet been nailed down. Regardless of where the policy.json file comes from, I'd recommend creating one for quantum under etc/policy.json (like nova does) that defines a set of actions, rules, and roles for quantum.

Additionally, the services are all expected to be doing enforcement of the policies locally - the idea being that quantum (or glance, nova, etc) should not need to make a (relatively heavy) HTTP API call back to Keystone to check each time to determine if a user is allowed to do "X" action.

Given that the routes in quantum call directly to plugins in Quantum, wrapping the controllers methods sounds like a good plan.

-joe

On May 20, 2012, at 5:25 AM, Yong Sheng Gong wrote:
> Hi Joseph,
> I have got the quantum client ready. So Next step is to get the server support for keystone.
> For policy, Is there still a need for local server to define a policy.json file? I think we have a plan to move all the policies into keystone server. right?
>
> After comparing all other policy check way, I like the nova's one which uses decorator.
>
> For now, Quantum server has no a API layer just like nova. In quantum server, the routes's controllers will call quantum plugin to do job. I think we have to apply the policy check on(decorator) or in(method call) controllers' methods. This is the way glance is adopting.