nova-manage network create + Essex-3 + Quantum : not working

Hi Alejandro!

The Quantum Manager in nova does not support keystone authentication
right now. Keystone is mainly needed for when an API is exposed
directly to tenants, which is currently not supported with Quantum
Manager (all networks and ports are created by Quantum Manager, which
is a "trusted" part of the infrastructure). Enabling keystone with
Quantum is only experimental right now anyway, as we have not yet
implemented Authz. We're hoping to tackle this in Essex-4, but are
running short on resources.We obviously want to expand on this in the
future though, so if you have resources to improve the Quantum +
Keystone + Nova functionality, we'd welcome the help. It would also
be helpful to understand the use case you are looking to achieve using
keystone + quantum.

Below is the relevant text from the Quantum Admin Guide:

Dan

"Requests to the Quantum API can be authenticated with the OpenStack
Keystone identity
service using a token-based authentication protocol. This is optional,
and is only needed for
production deployments that expose the Quantum API directly to
tenants. Deployments
where tenants only contact the Nova API, and Nova communicates with
Quantum using
the Quantum Manager (see above), do not require Quantum to use Keystone.
Keystone integration is disabled by default, as Quantum does not yet provide
authorization, meaning that NOTHING IS DONE with existing Keystone identities by
Quantum. We expect this to change in future Essex Milestones, but for
the time being this
portion of the document is purely experimental."

On Wed, Feb 1, 2012 at 10:41 AM, Alejandro Comisario
<email address hidden> wrote:
> New question #186541 on quantum:
> https://answers.launchpad.net/quantum/+question/186541
>
> Hi guys.
> After integrating quantum E-3 with keystone successfully, and installing quantum agent (with openVS 1.3) on Nova Essex E-3, we get the next error when creating a network from the nova side :
>
> ---------------------------------------------------------------------------------
> root@nova-controller:~# nova-manage --verbose network create private --fixed_range_v4=4.4.4.0/24 --num_networks=1 --network_size=256 --bridge=br100 --bridge_interface=eth0 --multi_host=T --project_id=af8c8592c9994edba7a53151d010460f
>
> 2012-02-01 13:29:52,698 DEBUG nova.network.quantum.quantum_connection [dcbffae1-ae01-4271-84de-3ca25fd58b33 None None] Quantum Client Request:
> POST /v1.0/tenants/af8c8592c9994edba7a53151d010460f/networks.json
>  from (pid=18871) do_request /usr/lib/python2.6/dist-packages/nova/network/quantum/client.py:178
> 2012-02-01 13:29:52,698 DEBUG nova.network.quantum.quantum_connection [dcbffae1-ae01-4271-84de-3ca25fd58b33 None None] {"network": {"name": "private", "nova_id": "nova"}} from (pid=18871) do_request /usr/lib/python2.6/dist-packages/nova/network/quantum/client.py:180
> 2012-02-01 13:29:52,702 DEBUG nova.network.quantum.quantum_connection [dcbffae1-ae01-4271-84de-3ca25fd58b33 None None] Quantum Client Reply (code = 401) :
>  401 Unauthorized
>
> This server could not verify that you are authorized to access the document you requested. Either you supplied the wrong credentials (e.g., bad password), or your browser does not understand how to supply the credentials required.
>
>  Authentication required   from (pid=18871) do_request /usr/lib/python2.6/dist-packages/nova/network/quantum/client.py:189
> Command failed, please check log for more info
> 2012-02-01 13:29:52,703 CRITICAL nova [dcbffae1-ae01-4271-84de-3ca25fd58b33 None None] Server 401 error: 401 Unauthorized
>
> This server could not verify that you are authorized to access the document you requested. Either you supplied the wrong credentials (e.g., bad password), or your browser does not understand how to supply the credentials required.
>
>  Authentication required
> (nova): TRACE: Traceback (most recent call last):
> (nova): TRACE:   File "/usr/bin/nova-manage", line 2336, in <module>
> (nova): TRACE:     main()
> (nova): TRACE:   File "/usr/bin/nova-manage", line 2324, in main
> (nova): TRACE:     fn(*fn_args, **fn_kwargs)
> (nova): TRACE:   File "/usr/bin/nova-manage", line 823, in create
> (nova): TRACE:     uuid=uuid)
> (nova): TRACE:   File "/usr/lib/python2.6/dist-packages/nova/network/quantum/manager.py", line 141, in create_networks
> (nova): TRACE:     nova_id=nova_id)
> (nova): TRACE:   File "/usr/lib/python2.6/dist-packages/nova/network/quantum/quantum_connection.py", line 62, in create_network
> (nova): TRACE:     resdict = self.client.create_network(data, tenant=tenant_id)
> (nova): TRACE:   File "/usr/lib/python2.6/dist-packages/nova/network/quantum/client.py", line 83, in with_params
> (nova): TRACE:     ret = self.func(instance, *args)
> (nova): TRACE:   File "/usr/lib/python2.6/dist-packages/nova/network/quantum/client.py", line 250, in create_network
> (nova): TRACE:     return self.do_request("POST", self.networks_path, body=body)
> (nova): TRACE:   File "/usr/lib/python2.6/dist-packages/nova/network/quantum/client.py", line 204, in do_request
> (nova): TRACE:     % locals()))
> (nova): TRACE: QuantumServerException: Server 401 error: 401 Unauthorized
> (nova): TRACE:
> (nova): TRACE: This server could not verify that you are authorized to access the document you requested. Either you supplied the wrong credentials (e.g., bad password), or your browser does not understand how to supply the credentials required.
> (nova): TRACE:
> (nova): TRACE:  Authentication required
> (nova): TRACE:
> ---------------------------------------------------------------------------------
>
> And from the quantum server side, we get this logs :
>
> ---------------------------------------------------------------------------------
> 2012-02-01 13:29:40    DEBUG [keystone.middleware.quantum_auth_token] entering AuthProtocol.__call__
> 2012-02-01 13:29:40    DEBUG [keystone.middleware.quantum_auth_token] start response:<function start_response at 0x26ed9b0>
> 2012-02-01 13:29:40    DEBUG [keystone.middleware.quantum_auth_token] Looking for authentication claims
> 2012-02-01 13:29:40    DEBUG [keystone.middleware.quantum_auth_token] No claims provided
> 2012-02-01 13:29:40    DEBUG [eventlet.wsgi.server] 172.16.167.24 - - [01/Feb/2012 13:29:40] "POST /v1.0/tenants/af8c8592c9994edba7a53151d010460f/networks.json HTTP/1.1" 401 466 0.001098
> ----------------------------------------------------------------------------------
>
> Are the networks in Quantum+Nova E-3 still being created from the "nova-manage" command, and we are just missing maybe environment variables / configuration flags to execute the command ?
> Or it is some kind of bug ?
>
> In that case, how can we create a network that is being replicated in nova and quantum for a tenant when integration with keystone is enabled ?
>
> Best.
> Alejandro.
>
> --
> You received this question notification because you are an answer
> contact for quantum.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira Networks: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~

Hi Dan, and thanks for the quick response as allways !
Maybe we are confusing something, i think you are right for us to give you our desired use case.

Today we have an experimental lab composed by 3 nova E-3 zones ( today they are standalone, next month, hopefully linked by the new multiZone service), one keystone server E-3, and one quantum server E-3.
This 3 zones, are pointing to the "same" Quantum Server via "nova.conf", so, since nova is integrated with nova already, the advantage is that the tenant ID, regarding the users ( zone1admin, zone2admin, zone3admin ) is the same, they all are part of the "testTENANT".

So, we wanted to try that, if creating a network for "testTENANT" we can take advantage that the ID of the tenant is the same thru all the zones, and for that we wanted to define just one big network for that thenant, in a way that, spawning an instance in zone1, zone2 or zone3, the same network is gonan be used, and the ip addresses of vms are not gonna be duplicated.

Is a possible use case ? or do we have to define 3 different network in this 3 different zones ?
If our use case is possible, then, do you recommend that we disable keystone authentication with keystone, since the quantum API is actually not exposed to tenants ? but to nova only ?

Im sorry in advance if we are mistaking the use case of keystone with quantum + nova.

Regards.
Alejandro.

Sorry, in this paragraph, i wanted to say :

This 3 zones, are pointing to the "same" Quantum Server via "nova.conf", so, since kesytone(<- correction) is integrated with nova already, the advantage is that the tenant ID, regarding the users ( zone1admin, zone2admin, zone3admin ) is the same, they all are part of the "testTENANT".

And in this paragraph i wanted to say :

Is a possible use case ? or do we have to define 3 different network in this 3 different zones ?
If our use case is possible, then, do you recommend that we disable keystone authentication with quantum(<-correction), since the quantum API is actually not exposed to tenants ? but to nova only ?

A lot of things changer in quantum manager on Essex E4, so its closed.

Hi Alejandro. Sorry, I have a whole backlog of quantum emails/issue to get to.

The issue still remains that because Quantum Manager stores networks in the Nova networks table, these networks are limited to a single zone. We're looking at working on this in E-4, but I'm not sure whether it will make it.

Great Dan!

Lets hope you guys can make it to E4 ! crossing networks across zones would be fantastic!