[openstack-dev] [horizon] PTL Candidacy for Pike
Hi everyone, I’m announcing my candidacy for PTL of Horizon for the Pike release cycle. Over the next 6 months I’d like to: - Narrow the blueprint/feature scope to ensure we focus on high priority areas, like non-performant panels or buggy user experiences. In previous cycles, our attitude has been to opportunistically accept features as they were developed; however, given the rapid decline in review count I don’t believe this is maintainable going forward. I’d like to follow a similar structure to Neutron, with a smaller feature count that is well understood by core reviewers and other time being spent on addressing bugs. We’ll do this by accepting only a handful of blueprints at a time, and designating a core reviewer to monitor each blueprints progress. - Continue working with Keystone via cross-project meetings to fix key bugs in Identity management. Over the past couple of cycles we’ve closed some long standing Keystone interaction bugs in Horizon, and I’d like to continue this effort. There are several patches still to work on in Horizon and Django OpenStack Auth, and we should make sure we capitalise on the excellent help from the Keystone community to improve the Horizon Identity panels. - Keep up community interaction. Richard has maintained a list of priority patches through Ocata, as well as sending out weekly meeting reminders and progress updates. I’ll continue this work, and hold bug days to highlight key issues to invest our time in. Thanks, Rob __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Horizon] PTL candidacy
I am announcing my candidacy for Horizon PTL. I've been contributing to Horizon since the Juno cycle and have been a core reviewer for the last two cycles. We’ve got a great culture in the Horizon team that I’d like to help continue and thrive. I feel we have made good progress in several areas of Horizon that improve responsiveness and stability, and believe our focus should be on continuing that work. My goals for Ocata are: - Ensure that modernisation of the interface continues with good framework components emerging that are accessible to existing and new developers of Horizon and Horizon plugins. This means continuing to ensure the code is written to good, consistent patterns, but also making sure there is good documentation to accompany it. - Continue to encourage finding better ways to handle scaling in OpenStack, both in our own filtering and use of data but also liaising with other projects to see how they can help us address scaling bottlenecks. Getting the profiling panel integrated into Horizon’s developer interface is a high priority for Ocata. - Improve our rate of addressing bugs; I will look at running more of the successful bug days that we had previously. One aspect of this is putting more effort into keeping our dependency compatibilities up to date, both Python and Django, but also the xstatic packages we rely on. - Improve communication both within the Horizon team and outside so folks can more easily get up to speed or keep up to date with what’s happening in Horizon. Thank you, Richard Jones __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [horizon] PTL candidacy
Hi folks, I'm announcing my candidacy for PTL for Horizon for the Newton release cycle. My main goals for the cycle are: - Remove roadblocks from AngularJS development so that the code can mature. This means optimistically approving patches in the experimental disabled panels, so that it can be rapidly iterated. The Swift rewrite is a fantastic example of how focused reviews and dropping the demand for absolute perfection allow for a dramatically improved experience via AngularJS. - Work on scale issues, and improve non-performant content. There are a number of panels in Horizon that are often unused (especially in the Admin dashboard). We need to apply the existing tools available to us such as pagination and filtering, as well as investigate other proposals. - Improve bug management and project organisation. In the past few cycles, the bugs and blueprints on launchpad have been quickly growing while triage work dwindles. In Mitaka, we've run several bug days as well as holding a Horizon Drivers meeting every other week to analyse blueprints as a group. I'd like to continue the focus on bringing our tooling back to useable state, so that we correctly address current issues and customer needs. Finally, I believe one of the most important parts of being a PTL is community engagement, and will continue to build an active and positive developer community. Election repo patch: https://review.openstack.org/#/c/293083/ Thanks, Rob __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [horizon] PTL Candidacy
I would like to announce my candidacy for Horizon PTL for Mitaka. I've been contributing to Horizon since the Grizzly cycle and I've had the honor of serving as PTL for the past four cycles. Over the past couple of releases, our main goal has been to position Horizon for the future while maintaining a stable, extensible project for current installations and providing a smooth path forward for those installations. Which is proving a delicate balancing act. In Kilo, we added a great deal of toolkit for AngularJS based content and took a first pass at some AngularJS driven content in Horizon. Much of the Liberty cycle was spent applying the lessons we learned from the Kilo work and correcting architectural issues. While the amount of AngularJS based content is not growing quickly in Horizon, we have created a framework that plugins are building on. We've had several successes in the Liberty cycle. We have a more complete plugin framework to allow for an increasing number of projects in the big tent to create Horizon content. The plugin framework works for both Django based and AngularJS based plugins. Theming improvements have continued and is now far more powerful. Many improvements in the AngularJS tooling. Including: sensible localization support for AngularJS code; a more coherent foundation for JavaScript code; better testing support; and an implemented JS coding style. Areas of focus for the Mitaka cycle: Stability. Continue to balance progress and stability. Finding a better way to allow forward progress on AngularJS content inside of Horizon. I've been advocating the use of feature branches for some time and will look to push work there to help establish the patterns for Angular in Horizon. Continue progress in moving separable content out of the Horizon source tree. This will benefit both service teams to make faster progress, while reducing the overall scope of the Horizon project. Focus work on areas of high benefit. There are a several reasons we chose to adopt AngularJS. Most were around scaling, usability and access to data. Let's focus on the areas with the greatest upside first. Provide better guidance for plugins in the form of testing and style guidelines. I'm still driven to continue the challenging work the Horizon community has undertaken to improve and look forward. If you'll have me, I'd like to continue enabling the talented folks doing the heavy lifting while balancing the needs of existing users. I believe if we continue to work through some of these transitional pains, we'll make significant progress in Mitaka. Thanks for your consideration, David Lyle __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] PTL Candidacy
confirmed On 04/03/2015 01:28 PM, David Lyle wrote: I would like to announce my candidacy for Horizon PTL. I have been actively contributing to Horizon since the Grizzly Summit and I've had the pleasure of serving as PTL for the last three cycles. In Kilo, we accelerated Horizon's adoption of AngularJS. We made a great deal of progress, with a near finished replacement of the launch instance workflow, The launch instance workflow was the number one usability issue in Horizon when tested. We've also created a framework to standardize and improve how filtering, pagination and data loading is managed in tables. The utilization of this framework begins in Liberty. We've worked to better incorporate UX design into our process. The UX team is now a part of the feature design process. In Liberty, we'll look to further formalize this workflow. Additionally, we've conducted several usability studies to obtain feedback on designs and information architecture from users and potential users. The results are helping guide design as we move forward. We will continue to test new and existing interfaces and designs. Over the past three cycles, interest in Horizon has grown dramatically, but as with most of OpenStack, we are feeling those growing pains. As a horizontal integration point, Horizon needs to adapt to handle the increasing breadth of services in OpenStack. In Juno and Kilo, we built and refined a plugin system for adding new content into Horizon. In Liberty, we'll see more services utilizing this mechanism and allow service teams to retain greater control of their Horizon content. In Liberty, Horizon needs to focus on existing efforts around improving usability, better support for large deployments and more useful administrative interfaces. We've set the stage to make significant strides in Liberty. I appreciate your consideration for the opportunity to continue enabling our tremendous team of contributors to make it happen. I'm excited by the progress we've made and the prospect of seeing several of our project's long term goals become reality in Liberty. Thanks, David __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Horizon] PTL Candidacy
I would like to announce my candidacy for Horizon PTL. I have been actively contributing to Horizon since the Grizzly Summit and I've had the pleasure of serving as PTL for the last three cycles. In Kilo, we accelerated Horizon's adoption of AngularJS. We made a great deal of progress, with a near finished replacement of the launch instance workflow, The launch instance workflow was the number one usability issue in Horizon when tested. We've also created a framework to standardize and improve how filtering, pagination and data loading is managed in tables. The utilization of this framework begins in Liberty. We've worked to better incorporate UX design into our process. The UX team is now a part of the feature design process. In Liberty, we'll look to further formalize this workflow. Additionally, we've conducted several usability studies to obtain feedback on designs and information architecture from users and potential users. The results are helping guide design as we move forward. We will continue to test new and existing interfaces and designs. Over the past three cycles, interest in Horizon has grown dramatically, but as with most of OpenStack, we are feeling those growing pains. As a horizontal integration point, Horizon needs to adapt to handle the increasing breadth of services in OpenStack. In Juno and Kilo, we built and refined a plugin system for adding new content into Horizon. In Liberty, we'll see more services utilizing this mechanism and allow service teams to retain greater control of their Horizon content. In Liberty, Horizon needs to focus on existing efforts around improving usability, better support for large deployments and more useful administrative interfaces. We've set the stage to make significant strides in Liberty. I appreciate your consideration for the opportunity to continue enabling our tremendous team of contributors to make it happen. I'm excited by the progress we've made and the prospect of seeing several of our project's long term goals become reality in Liberty. Thanks, David __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Horizon] PTL Candidacy
I would like to announce my candidacy for Horizon PTL. I've been actively contributing to Horizon since the Grizzly cycle and I've been a core contributor since the Havana cycle. For the last two cycles, I have had the pleasure of serving as PTL. Horizon is in the midst of some large transitions that we've been laying the foundation for in the past two releases. I would like to continue to help guide those changes through to completion. We've made progress on splitting the horizon repo into logical parts. The vendored 3rd party JavaScript libraries have been extracted. This was a major hurdle to completing the separation. Finishing the split will improve maintainability and extensibility. I believe we can complete this in the Kilo cycle. We've also continued the transition to leveraging AngularJS to improve usability and providing richer client experiences. I would like to see this effort accelerate in Kilo. But, I would like to see it driven by a clear unified strategy rather than numerous uncoordinated efforts. My goal is to leave the Paris Summit with a plan we can work toward together. A richer client side approach is key to addressing many of the usability shortcomings in Horizon. We successfully integrated the Sahara UI components into Horizon in Juno. And in Kilo, we'll look to integrate Ironic support. In Kilo, there is also potential for wider integration requirements on Horizon that may need greater attention and likely a revised repo strategy. Finally, Horizon like most of OpenStack is benefiting from a rapidly growing contributor base. Like other projects, we aren't immune to the stresses such growth creates. We've started taking steps toward improving the blueprint process as well as changes to how we manage bugs. We need to continue to refine these efforts to improve the overall direction of the project. Driven by a terrific community of contributors, reviewers and users, Horizon has made great strides in Juno. I look forward to seeing what this community can accomplish in Kilo. As PTL, my job is to enable this community to continue to flourish. Thank you, David Lyle ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] PTL Candidacy
confirmed On 22/09/14 04:59 AM, David Lyle wrote: I would like to announce my candidacy for Horizon PTL. I've been actively contributing to Horizon since the Grizzly cycle and I've been a core contributor since the Havana cycle. For the last two cycles, I have had the pleasure of serving as PTL. Horizon is in the midst of some large transitions that we've been laying the foundation for in the past two releases. I would like to continue to help guide those changes through to completion. We've made progress on splitting the horizon repo into logical parts. The vendored 3rd party JavaScript libraries have been extracted. This was a major hurdle to completing the separation. Finishing the split will improve maintainability and extensibility. I believe we can complete this in the Kilo cycle. We've also continued the transition to leveraging AngularJS to improve usability and providing richer client experiences. I would like to see this effort accelerate in Kilo. But, I would like to see it driven by a clear unified strategy rather than numerous uncoordinated efforts. My goal is to leave the Paris Summit with a plan we can work toward together. A richer client side approach is key to addressing many of the usability shortcomings in Horizon. We successfully integrated the Sahara UI components into Horizon in Juno. And in Kilo, we'll look to integrate Ironic support. In Kilo, there is also potential for wider integration requirements on Horizon that may need greater attention and likely a revised repo strategy. Finally, Horizon like most of OpenStack is benefiting from a rapidly growing contributor base. Like other projects, we aren't immune to the stresses such growth creates. We've started taking steps toward improving the blueprint process as well as changes to how we manage bugs. We need to continue to refine these efforts to improve the overall direction of the project. Driven by a terrific community of contributors, reviewers and users, Horizon has made great strides in Juno. I look forward to seeing what this community can accomplish in Kilo. As PTL, my job is to enable this community to continue to flourish. Thank you, David Lyle ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Horizon] PTL Candidacy
I would like to announce my candidacy for Horizon PTL. I've been working on and contributing to Horizon for the last three releases and had the pleasure to serve as the PTL for the Icehouse cycle. In the Icehouse cycle, we started a number of changes that I would like to see completed in the Juno cycle: 1) Adding Role Based Access Control support in the user interface for all services across OpenStack. This is an ongoing process as we have support for several services, and many more in progress. Once the changes are completed, Horizon will be able to support users with various cloud operator defined roles beyond just member and admin. This will also allow for a dramatic reduction in duplicate code. 2) Supporting richer client experiences and less custom JavaScript, by adopting AngularJS. In Juno, I would like to see further progress on this transition with effective use of Angular to improve end user experience with items like better client side validation and more responsive workflows. 3) An increased focus on usability. In Icehouse, Horizon added a wizard UI and with the help of the OpenStack-UX team conducted usability testing on Horizon. Horizon needs to work toward not only supporting as much of the OpenStack service APIs as possible, but making sure we do so in a well thought out and user enabling way. In Juno, I would like to see a focus on implementing more intuitive workflows. 4) Breaking horizon into logical pieces. We formulated a plan to split the existing Horizon repo into several repos to separate concerns and improve extensibility and maintainability. In Juno, we need to achieve this split. 5) Support infrastructure management. In Icehouse, tuskar-ui (rename to follow) joined the Horizon Program, I am excited by the future inclusion of greater infrastructure and deployment management into the Horizon framework. We need to help this functionality progress and fill out the Horizon ecosystem. In the Icehouse release, we saw continued growth of the Horizon community. I am very proud of the accomplishments we've made in Icehouse and I'm excited by the opportunities ahead in Juno. Thanks, David Lyle ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] PTL Candidacy
confirmed On 03/31/2014 02:52 PM, Lyle, David wrote: I would like to announce my candidacy for Horizon PTL. I've been working on and contributing to Horizon for the last three releases and had the pleasure to serve as the PTL for the Icehouse cycle. In the Icehouse cycle, we started a number of changes that I would like to see completed in the Juno cycle: 1) Adding Role Based Access Control support in the user interface for all services across OpenStack. This is an ongoing process as we have support for several services, and many more in progress. Once the changes are completed, Horizon will be able to support users with various cloud operator defined roles beyond just member and admin. This will also allow for a dramatic reduction in duplicate code. 2) Supporting richer client experiences and less custom JavaScript, by adopting AngularJS. In Juno, I would like to see further progress on this transition with effective use of Angular to improve end user experience with items like better client side validation and more responsive workflows. 3) An increased focus on usability. In Icehouse, Horizon added a wizard UI and with the help of the OpenStack-UX team conducted usability testing on Horizon. Horizon needs to work toward not only supporting as much of the OpenStack service APIs as possible, but making sure we do so in a well thought out and user enabling way. In Juno, I would like to see a focus on implementing more intuitive workflows. 4) Breaking horizon into logical pieces. We formulated a plan to split the existing Horizon repo into several repos to separate concerns and improve extensibility and maintainability. In Juno, we need to achieve this split. 5) Support infrastructure management. In Icehouse, tuskar-ui (rename to follow) joined the Horizon Program, I am excited by the future inclusion of greater infrastructure and deployment management into the Horizon framework. We need to help this functionality progress and fill out the Horizon ecosystem. In the Icehouse release, we saw continued growth of the Horizon community. I am very proud of the accomplishments we've made in Icehouse and I'm excited by the opportunities ahead in Juno. Thanks, David Lyle ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Horizon PTL candidacy
On 11/10/2013 11:53 PM, John Dickinson wrote: A random off-the-top-of-my-head use case would be to subscribe to events from creating or changing objects in a particular Swift account or container. This would allow much more efficient listings in Horizon for active containers (and may also be consumed by other listeners too). --John yupp. There are many many usecases for this, and we'd get rid of pulling services for status. Sounds reasonable, but just one caveat ... Notifications can either be disabled in the service config (e.g. by setting the notifier_strategy to noop in the glance config) or mis-configured (e.g. by not overriding control_exchange name in the cinder code) such that the notifications are not seen by the consumer. We have a similar potential problem with ceilometer, and no good way currently of detecting the non-flow of notifications, i.e. the old story that the absence of evidence evidence of absence. I'm not sure whether if it would be workable for horizon to detect whether notifications are flowing for each service by probing in some way (e.g. by setting unsetting a random property on an image and then ensuring that the corresponding image.update events are seen). If the absence of notifications were easily reliably detectable, then obviously horizon could simply fallback to polling. Anyhoo, just some food for thought. Cheers, Eoghan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Horizon PTL candidacy
On 11/12/2013 12:09 PM, Eoghan Glynn wrote: Sounds reasonable, but just one caveat ... Notifications can either be disabled in the service config (e.g. by setting the notifier_strategy to noop in the glance config) or mis-configured (e.g. by not overriding control_exchange name in the cinder code) such that the notifications are not seen by the consumer. We have a similar potential problem with ceilometer, and no good way currently of detecting the non-flow of notifications, i.e. the old story that the absence of evidence evidence of absence. I'm not sure whether if it would be workable for horizon to detect whether notifications are flowing for each service by probing in some way (e.g. by setting unsetting a random property on an image and then ensuring that the corresponding image.update events are seen). If the absence of notifications were easily reliably detectable, then obviously horizon could simply fallback to polling. Anyhoo, just some food for thought. Thank you for your input here. That is true, we'd rely on an additional service, whether marconi or some oslo service doesn't matter in first place here. The service may not be accessible or even not reliable; we might miss messages, and simply trusting in getting messages in the right order etc. is probably not a stable approach here. A fallback to pulling again is definitely an option. Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Horizon PTL candidacy
On 11/10/2013 11:45 PM, Dolph Mathews wrote: On Fri, Nov 8, 2013 at 2:38 AM, Matthias Runge mru...@redhat.com mailto:mru...@redhat.com wrote: Those are my primary targets I'd like to see addressed in Horizon during the cycle. Another thing I'd like to see addressed is the lack of listening to a notification service. That's probably an integration point with Marconi, and it might be possible, this won't make it until Icehouse. This bit caught me off guard - what's the use case here? Is there a link to a blueprint? Thanks! E.g when launching an instance, currently, Horizon is repeatedly pulling nova for a status. The same is true for cinder, when building images etc. There is at least one blueprint for this: https://blueprints.launchpad.net/horizon/+spec/realtime-communication but it doesn't use Marconi, but an own solution. Since we'll have marconi available sooner or later, it makes sense to have it there. Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Horizon PTL candidacy
On 11/10/2013 11:53 PM, John Dickinson wrote: A random off-the-top-of-my-head use case would be to subscribe to events from creating or changing objects in a particular Swift account or container. This would allow much more efficient listings in Horizon for active containers (and may also be consumed by other listeners too). --John yupp. There are many many usecases for this, and we'd get rid of pulling services for status. Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Horizon PTL candidacy
The two candidates who nominated themselves in time for this election are: * David Lyle * Matthias Runge The election will be set up tomorrow, and will stay open for voting for a week. -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Horizon PTL candidacy
Excerpts from Matthias Runge's message of 2013-11-11 00:04:52 -0800: On 11/10/2013 11:53 PM, John Dickinson wrote: A random off-the-top-of-my-head use case would be to subscribe to events from creating or changing objects in a particular Swift account or container. This would allow much more efficient listings in Horizon for active containers (and may also be consumed by other listeners too). --John yupp. There are many many usecases for this, and we'd get rid of pulling services for status. Note that Heat can also make use of this, and a need for such things came up during several session discussions. I forget who said this, but it sums up the problem: Polling sucks I'd hope that we keep it a public API of some sorts, so that users can also take advantage of it. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Horizon PTL candidacy
On Fri, Nov 8, 2013 at 2:38 AM, Matthias Runge mru...@redhat.com wrote: Those are my primary targets I'd like to see addressed in Horizon during the cycle. Another thing I'd like to see addressed is the lack of listening to a notification service. That's probably an integration point with Marconi, and it might be possible, this won't make it until Icehouse. This bit caught me off guard - what's the use case here? Is there a link to a blueprint? Thanks! Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- -Dolph ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Horizon PTL candidacy
I would like to announce my candidacy for the Horizon PTL. I have been developing, extending and contributing to Horizon through the Grizzly and Havana releases serving as a core team member in the Havana cycle. And most recently in Icehouse, being interim PTL. At the Havana OpenStack Summit, I led a design session on Keystone v3 and multiple region support in Horizon. During the Havana cycle, I contributed multi-region support, significant parts of Keystone v3 support, and the role based access control engine including enforcement for identity. While consistently reviewing changes: http://russellbryant.net/openstack-stats/horizon-reviewers-30.txt http://russellbryant.net/openstack-stats/horizon-reviewers-180.txt Over the course of the Havana cycle, we've seen significant growth in the number of contributors to Horizon. I would like to see that growth continue and also see significant growth in the number of active reviewers. As PTL, I would enable continued growth by being highly engaged and easily accessible while encouraging greater communication and collaboration across our strong community of contributors. In Icehouse, I would like to see updates to the overall user experience in Horizon to allow for greater extensibility and better overall user experience. This includes: -Improved navigation control -- The current navigation implementation is not very extensible, and could stand some overall improvement regarding context and organization. -Use of role based access control to reduce code redundancy -- We currently have nearly duplicate panels for the end user and administrators, by incorporating role base checks on actions and the methods that load data into the page, we can reduce the duplication and have common panels that work for both classes of user. -Workflows that better and more intuitively support common use cases -- The current UI requires a fair amount of domain knowledge for an end user to be able to create entities in the stack. I want to work to include a general wizard widget into the horizon library that can be leveraged to walk users through common use cases like spinning up their first instance. -Continued support for projects coming out of incubation and active support for new features in existing projects -Greater extensibility -- Horizon really has two purposes, one a library to build other UIs from, and two a working reference UI for OpenStack. While a great deal of effort is spent achieving the second purpose, the former still has great value and we need to continue to make the horizon library work in other UI implementations. -Views for administrators that work in for large installations -- The panels as currently designed provide no meaningful way to filter data. There are a high number of API calls per panel and API calls that are not filtering, but rather calling for every item of a given type. For those who aren't familiar with me from IRC, Horizon meetings or other interactions, I work for HP on Horizon where we use Horizon to manage the HP Public Cloud. Previously, I've held architect, technical lead and project manager positions. Thanks, David Lyle ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Horizon] PTL Candidacy
I hereby declare my candidacy for the Horizon PTL position. My current qualifications: * PTL for the Grizzly and Havana cycles. * Core developer on Horizon since Essex, and Keystone core since Folsom. * Primary architect of the existing Horizon framework. * Core developer for the Django web framework upon which Horizon is built. * Author of the Core Values of Horizon: http://docs.openstack.org/developer/horizon/intro.html * Extensive depth and breadth of knowledge of all of the OpenStack service APIs. * Helped shape the Keystone V3 API and Nova v3 API. * Provided the initial push to internationalize OpenStack as a whole in the Grizzly cycle which has now extended to all projects and dozens of translators. * Ongoing advocate for OpenStack to provide a unified and sensible experience for end users. * Highly engaged in discussions around the future of OpenStack. Things I can't directly take credit for but which happened under my watch (and I'd like to think with my guidance): * Overall contributor base has grown steadily with each release. * Core team expanded significantly in size and diversity. * New OpenStack projects have continued to be represented in each release. * Translation team actively engaged. * UX team formed and steadily becoming an active part of the design and development process. * Essex, Folsom, Grizzly and Havana releases have all been stable, high-quality, on-time, and both forwards and backwards compatible. What I see for Icehouse and beyond: * We have known goals for making Horizon truly event-driven. This is a large job and now is the time. * Downstream distros and large OpenStack providers have given feedback on their pain points; they center around packaging, configuration, and how to alter or remix the OpenStack Dashboard. We can and must improve in these areas. * More projects are entering and graduating from incubation each cycle. We will continue to fulfill our commitment to those projects, and the PTL must engage those projects leaders and their developers to drive their own integrations. * The UX community is giving great insight into how the usability of the dashboard can be improved as it grows. Navigation, user-oriented workflows, and responsive design are low-hanging fruit. * Providing raw data and tools are a base layer, but there are vast green fields for how we can anticipate user questions and needs and provide solutions that cover the 90% cases. * Visualizations and interactivity not only provide better experiences, they also help capture OpenStack mindshare. First impressions matter. * Better integration of help by collaborating with the Docs team connects the end users to the information they need when they need it most. * Multi-region, federation, hybrid public-private, etc. clouds are on the horizon (no pun intended) and we need to start thinking about these issues. All of these lists could go on, but these are the high level items. I want to close by saying that I'm thrilled that someone else in the Horizon community is interested in being PTL, and that the outcome is not a foregone conclusion. It is the highest order of success for a project that there are enough people with passion and vision that there's actually competition for the position. I don't intend to be PTL forever but I believe l have the right experience and vision to guide Horizon through Icehouse. Best of luck to all! - Gabriel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
