Open Stack

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 <tres at 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 <tres at 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 at 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~