Loading…
Please note: This schedule is for OpenStack Active Technical Contributors participating in the Icehouse Design Summit sessions in Hong Kong. These are working sessions to determine the roadmap of the Icehouse release and make decisions across the project. To see the full OpenStack Summit schedule, including presentations, panels and workshops, go to http://openstacksummitnovember2013.sched.org.

Sign up or log in to bookmark your favorites and sync them to your phone or calendar.

Horizon [clear filter]
Tuesday, November 5
 

11:15am

Separate Horizon and OpenStack Dashboard
Horizon is a framework to build UIs using restful services.
OpenStack Dashbaord is just a reference implementation.

I think, we can attract more developers, when promoting horizon unrelated to OpenStack Dashboard.

This session is intended to discuss, what it takes to separate both, does it make sense at all?

(Session proposed by Matthias Runge)


Tuesday November 5, 2013 11:15am - 11:55am
AWE Level 2, Room 201A

12:05pm

Getting Our Heads Around IA
Current information architecture of OpenStack UI is experiencing various issues (horizontal/vertical scaling, usability, etc) and there is common agreement on its improvement.

Thanks to David Lyle's RBAC support [0] which was added to Horizon and there is plan for its extension, we would like to propose new IA to enhance usability and user experience when using OpenStack UI. I would like to have initial proposal for IA enhancements one week before Summit (link should appear in related blueprint).

In this session, I would like to:
* shortly cover current state and explain usability issues,
* introduce initial proposal of IA improvements,
* open discussion and try to find agreement on its future look and regulations when new sections are being added.

[0] https://blueprints.launchpad.net/horizon/+spec/rbac

-- Jarda

(Session proposed by Jaromir Coufal)


Tuesday November 5, 2013 12:05pm - 12:45pm
AWE Level 2, Room 201A
 
Wednesday, November 6
 

11:15am

Scaling Horizon
Components in Horizon, e.g., Admin dashboard, do not scale to be useful in large scale deployments. Let's discuss work required to allow for a scalable user interface that works for administrators.

This topic ties in nicely with pagination, but also involves richer searching and filtering based on context.

(Session proposed by David Lyle)


Wednesday November 6, 2013 11:15am - 11:55am
AWE Level 2, Room 201A

12:05pm

Automated Dashboard Generation
Horizon cannot hope to keep up with the number of new services provided by the continually growing set of projects. Other dashboards (such as the AWS console) use dependency injection and code generation from schemas to allow the burden to be largely automated. Let's discuss how this might work in Horizon and how we can move more of that workload onto the projects creating these features.

A couple of suggested approaches:

* An approach that combines Progressive Enhancement with the automated consumption of simplistic HTML generated by the remote projects would allow the Horizon team to focus on enhancing the user experience.

* The Django admin builds complete admin interfaces based on Django's "Model" classes. If we could consume a specification from each service for their "models" we could do some introspection and code generation and end up with something very powerful and flexible.

NOTE: This session was originally proposed for Keystone, but it really belongs under Horizon. Horizon is going to need to set the standards for the other projects in order to continue to have a workable growing UI.

NOTE 2: This session proposal has been edited by Gabriel Hurley to merge two related topics into one.

(Session proposed by Adam Young)


Wednesday November 6, 2013 12:05pm - 12:45pm
AWE Level 2, Room 201A
 
Thursday, November 7
 

9:00am

Integration testing for Horizon
We mock a lot and end up relying heavily on manual testing to find out when one of the many APIs we depend on has changed in a backwards incompatible way, and other surprises. Horizon would greatly benefit from a wider set of integration tests that also exercises all of our interfaces to other projects.

Suggestions and issues to work through:

* How to write useful, durable tests that won't need to be modified all the time because e.g. a button's location has been adjusted?

* Implementation ideas:

* Separate, self-contained new tests?

* Part of the Django Selenium tests?

* A "mocking" switch that could turn mocking on or off: in e.g. a fully set up devstack environment, run the tests without mocking?

* Other ideas?

* Where should they live: in our tree to be easily modified alongside the main code, in Tempest, elsewhere?

* Tooling: Selenium, PhantomJS, CasperJS, Splinter, other...? Any previous experience to share?

(Session proposed by Julie Pichon)


Thursday November 7, 2013 9:00am - 9:40am
AWE Level 2, Room 201A

9:50am

Openstack dashboard to configure hardware
This will likely tie in to the session proposed by Jeremy about the future direction of Openstack Dashboard and UX, but would like to discuss the following -
1. Give a brief introduction to the new "Router" dashboard and demo how it is used. Find a better permanent solution for this dashboard?
2. What can be done to add new dashboards in future (UX perspective)?
3. Given that we now have a new "Router" dashboard, can we leverage that to add new panels for other hardware? Or will each hardware device require it's own dashboard?
4. Can multiple such dashboards/panels exist at the same time?
5. What can be done to make the operation of these dashboards dynamic - based on plugin detection, config setup?

(Session proposed by Abishek Subramanian)


Thursday November 7, 2013 9:50am - 10:30am
AWE Level 2, Room 201A

11:00am

UX and Future Direction of OpenStack Dashboard
Horizon (OpenStack Dashboard) has a lot of potential for improvements from the look and feel of the UI. In this session I would like to open and discuss:
* How to approach UX related questions and include UX professionals into development processes
* Which parts of Horizon we can attack in the future
* Propose and discuss some ideas for improvements
* Open discussion

(Session proposed by Jaromir Coufal)


Thursday November 7, 2013 11:00am - 11:40am
AWE Level 2, Room 201A

11:50am

Plugin architecture for Horizon
Currently adding stuff to horizon requires to change settings.py. This is nearly impossible in a world of software packages. At least, when using RPM packages, it is absolutely unwanted, to change files at install time, depending if other packages are installed or not. When implemented, this feature would make the life of packagers easier.

The idea would be a directory to place python packages to be added dynamically to the dashboard.

I'd like to hear opinions, ideas, and discussions about managing dynamic plugins, dependencies, etc...
Having such a feature would allow others to have their customization separate from horizon, or to provide software vendors to ship functions on top of horizon.

(Session proposed by Matthias Runge)


Thursday November 7, 2013 11:50am - 12:30pm
AWE Level 2, Room 201A