The Horizon team closed out https://review.openstack.org/3336 which brings the Quantum code inline with the rest of Horizon and should provide a good starting point for the Quantum Manager updates below. AFAIK there are no blueprints or bugs yet for the updates.
On Feb 6, 2012, at 4:58 AM, Michael J Fork wrote: > With the the vif-extension bug noted below being fixed by Vish back during > the bug squash - see https://bugs.launchpad.net/nova/+bug/925682 - our plan > is to move on to specifying the set and order of NICS that are created on a > guest. > > Tres - let me know if there is any overlap with what you planned on working > on. > > Dan - if we remove the "Create Network" button, what is the right way to > create networks for testing purposes? > > Devin - The network selection is part of the Launch Instance flow, but the > space constraints on the dialog make me wonder if this should be placed below > Flavor/Keypair or a new pane as part of a wizard-like flow? Additionally, I > don't see an ordered, multi-select implementation to use as a guide. Do you > have a preferred control or pattern to follow to implement this? > > 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
