#2 Gabriel (cc'd) may be able to help. One thing that might help is to run the tests with --failfast which will terminate the tests after the first failure. You can also change the console log level to debug (from info) in local_settings.py (https://github.com/openstack/horizon/blob/master/openstack-dashboard/local/local_settings.py.example#L78).
#3 What kind of data does the multi-select need to display? If you have multiple columns of data then you should use the DataTable component in horizon/horizon/tables/ (https://github.com/openstack/horizon/blob/master/horizon/horizon/tables/base.py#L583) otherwise maybe just the usual Django multi-select widget (https://docs.djangoproject.com/en/dev/ref/forms/widgets/#selectmultiple). #4 You should not submit a review until the tests pass, however, you can push your changes up to a horizon clone on Github which will make it easier for other folks to help debug the broken tests. On Feb 16, 2012, at 1:21 PM, Michael J Fork wrote: > 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
