Re: [openstack-dev] [Horizon] PTL Candidacy

[Tristan Cacqueray]

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

Re: [openstack-dev] [Horizon] PTL Candidacy

[Tristan Cacqueray]

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

Re: [openstack-dev] [Horizon] PTL Candidacy

[Anita Kuno]

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

[Matthias Runge]

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

[Eoghan Glynn]

> 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

[Gabriel Hurley]

We all agree on the benefits of an event-driven "push" system, but the basis 
for this already exists in OpenStack. The RPC notification code exists in Oslo 
and most of the IaaS projects are using it now. There were (should have been?) 
conversations about how to leverage this data stream in the Horizon sessions in 
Hong Kong.

As I understood it, Marconi has a completely different goal (queuing service a 
la SQS) which operates as a "building block" service for user applications, not 
as a publication channel for the core OpenStack infrastructure.

Anyhow, we agree on the goal and have plans for how to do it already; Marconi 
ought to be an orthogonal concern when it's ready for graduation.

My two cents,

 - Gabriel

> -Original Message-
> From: Clint Byrum [mailto:cl...@fewbar.com]
> Sent: Monday, November 11, 2013 11:02 AM
> To: openstack-dev
> Subject: 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

___
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

[Clint Byrum]

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

[Thierry Carrez]

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

[Matthias Runge]

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

[Matthias Runge]

On 11/10/2013 11:45 PM, Dolph Mathews wrote:
> 
> On Fri, Nov 8, 2013 at 2:38 AM, Matthias Runge  > 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

[John Dickinson]

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



On Nov 10, 2013, at 2:45 PM, Dolph Mathews  wrote:

> 
> On Fri, Nov 8, 2013 at 2:38 AM, Matthias Runge  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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

[Dolph Mathews]

On Fri, Nov 8, 2013 at 2:38 AM, Matthias Runge  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