Hi Shake, You can read more details about quantum + horizon in the thread below. If you are able to do any work to fix things, please let us know.
Dan On Tue, Jan 31, 2012 at 4:47 PM, Tres Henry <t...@treshenry.net> wrote: > 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 : netst...@lists.launchpad.net > > Unsubscribe : https://launchpad.net/~netstack > > More help : https://help.launchpad.net/ListHelp > > > > > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Dan Wendlandt > Nicira Networks: www.nicira.com > twitter: danwendlandt > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira Networks: www.nicira.com twitter: danwendlandt ~~~~~~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp