I have implemented most of the the request below to "use the 
os-create-server API extension in nova to specify the set and order of 
NICs that are to be created on a server,"  allowing the set to be 
specified, but not the order.  The ordering was left off because I could 
not find a suitable Django control (just using forms.MultipleChoiceField 
now).  The flow works great when the tenant has networks defined and one 
or more are selected.  However, before committing, I have a few issues I 
need help with.

The command to invoke the create (change was to add nics=nics):

    return Server(novaclient(request).servers.create(
            name, image, flavor, userdata=user_data,
            security_groups=security_groups,
            key_name=key_name, block_device_mapping=block_device_mapping,
            nics=nics, min_count=instance_count), request)

1) If no networks are selected (either because the tenant does not have 
one defined or they chose not to select) the flow errors out with

(nova.rpc): TRACE: Traceback (most recent call last):
(nova.rpc): TRACE:   File "/opt/stack/nova/nova/rpc/amqp.py", line 249, in 
_process_data
(nova.rpc): TRACE:     rval = node_func(context=ctxt, **node_args)
(nova.rpc): TRACE:   File 
"/opt/stack/nova/nova/network/quantum/manager.py", line 363, in 
allocate_for_instance
(nova.rpc): TRACE:     instance_type_id, host)
(nova.rpc): TRACE:   File 
"/opt/stack/nova/nova/network/quantum/manager.py", line 481, in 
get_instance_nw_info
(nova.rpc): TRACE:     network['uuid']),
(nova.rpc): TRACE:   File 
"/opt/stack/nova/nova/network/quantum/quantum_connection.py", line 68, in 
get_network_name
(nova.rpc): TRACE:     net = self.client.show_network_details(network_id, 
tenant=tenant_id)
(nova.rpc): TRACE:   File 
"/opt/stack/nova/nova/network/quantum/client.py", line 83, in with_params
(nova.rpc): TRACE:     ret = self.func(instance, *args)
(nova.rpc): TRACE:   File 
"/opt/stack/nova/nova/network/quantum/client.py", line 244, in 
show_network_details
(nova.rpc): TRACE:     return self.do_request("GET", self.network_path % 
(network))
(nova.rpc): TRACE:   File 
"/opt/stack/nova/nova/network/quantum/client.py", line 151, in do_request
(nova.rpc): TRACE:     raise Exception(_("Tenant ID not set"))
(nova.rpc): TRACE: Exception: Tenant ID not set
(nova.rpc): TRACE:

2) The unit tests I added to 
horizon/horizon/dashboards/nova/images_and_snapshots/images/tests.py  will 
not run properly.  There are a few errors, but I believe this is the root 
cause:

======================================================================
ERROR: test_launch_post 
(horizon.dashboards.nova.images_and_snapshots.images.tests.ImageViewTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File 
"/home/mjfork/workspace.git/horizon/horizon/horizon/dashboards/nova/images_and_snapshots/images/tests.py",
 
line 80, in test_launch_post
    networks = self.networks
AttributeError: 'ImageViewTests' object has no attribute 'networks'

The added tests were patterned after existing code, e.g. using 
security_group_list and security_groups in same file, but I am not able to 
find where "security_groups" is defined. 

3) Is there a Django control that allows multi-selection + ordering that 
should be used?

4) Should the changes be pushed as-is and let code review flush these out?

Thanks.

Michael

-------------------------------------------------
Michael Fork
Cloud Architect, Emerging Solutions
IBM Systems & Technology Group



From:   Dan Wendlandt <d...@nicira.com>
To:     Tres Henry <t...@treshenry.net>
Cc:     netstack@lists.launchpad.net, Devin Carlen 
<devin.car...@nebula.com>, Michael J Fork/Rochester/IBM@IBMUS
Date:   01/31/2012 01:41 PM
Subject:        Re: [Netstack] updating quantum in horizon



Hi Tres,

Thanks for sending this out.  I'm excited that we have a couple people
interested in fixing things up here!  CC'd is Michael Fork, who also
mentioned that he is interested in working on this.

I will start out with a caveat that all of these comments are targeted
at making Horizon work well with Quantum + the Quantum Manager code in
Nova.  The original Quantum + Horizon code was written back in diablo,
prior to much of the work on Quantum Manager, and thus targeted a more
manual model where the user explicitly created + attached ports,
rather than having QuantumManager do that automatically.  It also was
a model that was not integrated with IP Address management at all.
Given that things seem to have been broken with Quantum + Horizon for
a while, I am assuming that no one has been seriously using the code
in this form, and thus we can move to a model that uses QuantumManager
without worrying about the old model.  If anyone wants to step forward
and support the old model, we'll have to figure out how the two
approaches should co-exist.  Otherwise, I would just push for a model
where QuantumManager is the primary mode of use for Quantum + Horizon.

One error prevents a lot of the code from even working in the first
place, so we should probably tackle that first.  Oddly, it seems to be
an issue with the vif-extension in Nova.

When trying to view the detail page of an individual network does not
work.  I get this error:

Error: Unable to get network details: The server has either erred or
is incapable of performing the requested operation.

Underneath the covers, I see the exception:

[Tue Jan 31 09:53:29 2012] [error]
ERROR:horizon.dashboards.nova.networks.views:Unable to get network
details.
[Tue Jan 31 09:53:29 2012] [error] Traceback (most recent call last):
[Tue Jan 31 09:53:29 2012] [error]   File
"/opt/stack/horizon/horizon/horizon/dashboards/nova/networks/views.py",
line 102, in detail
[Tue Jan 31 09:53:29 2012] [error]     network['ports'] =
_get_port_states(request, network_id)
[Tue Jan 31 09:53:29 2012] [error]   File
"/opt/stack/horizon/horizon/horizon/dashboards/nova/networks/views.py",
line 143, in _get_port_states
[Tue Jan 31 09:53:29 2012] [error]     vifs = api.get_vif_ids(request)
[Tue Jan 31 09:53:29 2012] [error]   File
"/opt/stack/horizon/horizon/horizon/api/quantum.py", line 118, in
get_vif_ids
[Tue Jan 31 09:53:29 2012] [error]     instance_vifs =
nova.virtual_interfaces_list(request, id)
[Tue Jan 31 09:53:29 2012] [error]   File
"/opt/stack/horizon/horizon/horizon/api/nova.py", line 398, in
virtual_interfaces_list
[Tue Jan 31 09:53:29 2012] [error]     return
novaclient(request).virtual_interfaces.list(instance_id)
[Tue Jan 31 09:53:29 2012] [error]   File
"/opt/stack/python-novaclient/novaclient/v1_1/virtual_interfaces.py",
line 33, in list
[Tue Jan 31 09:53:29 2012] [error]     'virtual_interfaces')
[Tue Jan 31 09:53:29 2012] [error]   File
"/opt/stack/python-novaclient/novaclient/base.py", line 69, in _list
[Tue Jan 31 09:53:29 2012] [error]     resp, body = 
self.api.client.get(url)
[Tue Jan 31 09:53:29 2012] [error]   File
"/opt/stack/python-novaclient/novaclient/client.py", line 130, in get
[Tue Jan 31 09:53:29 2012] [error]     return self._cs_request(url,
'GET', **kwargs)
[Tue Jan 31 09:53:29 2012] [error]   File
"/opt/stack/python-novaclient/novaclient/client.py", line 118, in
_cs_request
[Tue Jan 31 09:53:29 2012] [error]     **kwargs)
[Tue Jan 31 09:53:29 2012] [error]   File
"/opt/stack/python-novaclient/novaclient/client.py", line 101, in
request
[Tue Jan 31 09:53:29 2012] [error]     raise
exceptions.from_response(resp, body)
[Tue Jan 31 09:53:29 2012] [error] ClientException: The server has
either erred or is incapable of performing the requested operation.
(HTTP 50

This is because dashboard is trying to build up a dictionary mapping
from server-id to interface-id using the os-virtual-interfaces
extension for nova.  But that extension isn't working.  My best guess
is that this is because of the shift from using ids to uuids within
Nova API calls, but I'm not 100% sure.

If you work around that issue by commenting out the vif-id related
code in network/views.py, you can get the ports page to come up, and
you can more-or-less see the current state of things.

Here are some other suggestions for items to look at:

- on the network detail page, we can get rid of the "create-ports",
"attach", and "detach", and "delete" buttons as well and any
associated dialogs, as Quantum Manager actually does all of the port
creation/attaching/detaching/deletion on behalf of the user.  Leaving
the bottom to put the port in "admin down" or "admin up" state makes
sense.
- We should add a row to the table to show the operational status of a
port, as this is very useful for understanding if the port is working.
 This is only supported in v1.1 of the API, but the dashboard can have
a slot for it, and show N/A if it is not available.
- We should also hide the "create  new network" button on the main
networks page.  This is a longer discussion, but until we can create
not only a quantum network but also an IPAM subnet (e.g., via
melange), we can't actually create networks that are used by Quantum
Manager in nova.  Fixing this will be an important next step.  With
this in mind, deleting the network also should not be possible via the
dashboard.
- on the "network" page, we should get rid of the notion of
"available" and "used" ports, as with Quantum Manager, all ports that
are created are in use, since they are automatically created/destroyed
by Quantum Manager.
- On the networks page, I would probably not show the UUID as the main
name of the network.  Similar to the "instances + volumes" page, I
should show the name of the network, with the UUID only shown on a
details page for that network.

Another big thing that I would like to add is the ability to use the
os-create-server API extension in nova to specify the set and order of
NICs that are to be created on a server (by default, a server gets all
NICs associated with the current project, as well as a NIC on any
"global" network created by the service provider for use by all
tenants).  This is the same capability that is already exposed with
the --nic option in python-novaclient.   (note: quantum manager
currently only specifies setting the network-id, it does not support
selecting a particular IP address for that NIC, even though an IP
address is specified in the API extension schema).  Given that Horizon
already uses the python-novaclient library, leveraging this in Horizon
should be pretty straightforward.

Ok, that was a lot of ideas :)  One last point is how to setup an
environment to develop and test all of this.

Here are instructions for running devstack with Quantum, which is what
I use:  http://wiki.openstack.org/QuantumDevstack

With devstack, the useful Horizon code is mainly in:
- /opt/stack/horizon/horizon/horizon/dashboards/nova/networks  :
fetches data for network pages
- /opt/stack/horizon/horizon/horizon/api  : contains libraries for
talking to nova + quantum.

I also have a script, pasted below, that I use to setup some
interesting networks + hosts across two users "demo1" and "demo2".
After stack.sh completes, I run this script, which is much faster than
setting things up manually.

Would be great to have people volunteer to create bugs and work on any
of the above issues.  Let me know how I can help out!

Dan



DEMO1_ID=`keystone-manage -c /opt/stack/keystone/etc/keystone.conf
tenant list | grep demo1 | awk '{ print $1 }'`
DEMO2_ID=`keystone-manage -c /opt/stack/keystone/etc/keystone.conf
tenant list | grep demo2 | awk '{ print $1 }'`

nova-manage --flagfile=/opt/stack/nova/bin/nova.conf  network create
--label=demo1-net1 --fixed_range_v4=11.0.0.0/24 --project_id=$DEMO1_ID
--priority=1
nova-manage --flagfile=/opt/stack/nova/bin/nova.conf  network create
--label=demo1-net2 --fixed_range_v4=12.0.0.0/24 --project_id=$DEMO1_ID
--priority=2
nova-manage --flagfile=/opt/stack/nova/bin/nova.conf  network create
--label=demo2-net1 --fixed_range_v4=13.0.0.0/24 --project_id=$DEMO2_ID
--priority=1
nova-manage --flagfile=/opt/stack/nova/bin/nova.conf  network create
--label=demo2-net2 --fixed_range_v4=14.0.0.0/24 --project_id=$DEMO2_ID
--priority=2

TENANT=demo1
. openrc

IMAGE_UUID=`nova image-list | grep ACTIVE | awk '{ print $2 }'`
echo "Image ID: $IMAGE_UUID"

nova boot --flavor 1 --image $IMAGE_UUID demo1-test1 > /dev/null
nova boot --flavor 1 --image $IMAGE_UUID demo1-test2 > /dev/null

TENANT=demo2
. openrc

nova boot --flavor 1 --image $IMAGE_UUID demo2-test1 > /dev/null

DEMO2_NET1_UUID=`nova-manage --flagfile=/opt/stack/nova/bin/nova.conf
network quantum_list | grep "13.0.0.0/24" | awk '{print$1}'`

nova boot --flavor 1 --image $IMAGE_UUID --nic net-id=$DEMO2_NET1_UUID
demo2-test2 > /dev/null










On Tue, Jan 24, 2012 at 3:02 PM, Tres Henry <t...@treshenry.net> wrote:
> Yo! Looks like Quantum support in Horizon has been languishing a bit. 
The
> good news is that we have a much better story for extensibility now 
(versus
> the mess you had to deal with for the first cut of the Quantum UI) 
including
> encapsulated dashboards/panels and support for some common controls like 
a
> fancy new datatable that makes wiring up a table view with actions 
trivial.
> The quantum UI has already been moved to a panel
> (
https://github.com/openstack/horizon/tree/master/horizon/horizon/dashboards/nova/networks
)
> and we have done some of the work to convert Quantum's tables to the new
> table component (https://review.openstack.org/3336). However, that 
review
> still needs some work (unit test failures and pep8 issues).
>
> From what I understand there are essentially three areas that need
> eyeballs/work:
>
> 1) Horizon API needs to be updated to support new python-quantumclient 
(Joe
> has a review open: https://review.openstack.org/3375)
> 2) Pull request 3336 needs to be finished to bring the network UI inline
> with the rest of Horizon
> 3) Recent changes in Quantum need to be reflected in the UI
>
> On #2 it would be great if we could get some help from the Quantum 
team. I'm
> not really sure of the scope on #3 but would be good to get some 
blueprints
> and/or cases in Horizon's launchpad to provide some visibility into what
> needs to be updated/added to the UI.
>
> Thoughts?
>
>
>
> --
> 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 Networks: 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

Reply via email to