Yeah, the Quantum UI hasn't been getting a lot of use because of it's broken status. My vote would be to update the UI to support the new Quantum Manager way of doing things instead of trying to support two UI paradigms.
As a good parallel to this discussion the Horizon community has been working on formalizing the design process which spawned a first pass at a Human Interface Guideline (https://github.com/4P/Horizon-HIG/blob/master/OpenStack_HIG.rst). The HIG is a good tool to measure the implementation against. In an ideal world your change suggestions below would be translated into requirements which would then drive a design pass resulting in wireframes that would guide the implementation. Unfortunately the world is often less than ideal so we'll just have to do our best given the tight timeline. We can finish off https://review.openstack.org/3336, which I believe just needs some testing, then we can create bugs for all of your suggestions below and see what we can get nailed down before Folsom. On Jan 31, 2012, at 10:39 AM, Dan Wendlandt wrote: > 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
