Re: [openstack-dev] [stable][horizon] Adding Ivan Kolodyazhny to horizon-stable-maint

[David Lyle]

+1
On Mon, Jun 18, 2018 at 9:15 AM Sean McGinnis  wrote:
>
> On Mon, Jun 18, 2018 at 12:03:52PM +1000, Tony Breeds wrote:
> > Hello folks,
> > Recently Ivan became the Horizon PTL and as with past PTLs (Hi Rob)
> > isn't a member of the horizon-stable-maint team.  Ivan is a member of
> > the Cinder stable team and as such has demonstrated an understanding of
> > the stable policy.  Since the Dublin PTG Ivan has been doing consistent
> > high quality reviews on Horizon's stable branches.
> >
> > As such I'm suggesting adding him to the existing stable team.
> >
> > Without strong objections I'll do that on (my) Monday 25th June.
> >
> > Yours Tony.
>
> Speaking with both stable and Cinder hats on, Ivan has been doing good stable
> reviews and I do not have any concerns about him being in any *-stable-maint
> groups.
>
> Sean
>
> __
> 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 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] Blueprint process question

[David Lyle]

There have been a couple of projects that would like some space in the
page header. I think the work in Horizon is to provide an extensible
space in the page header for plugins to post content. The UI plugin
for Vitrage, in this case, would then be responsible for populating
that content if desired. This specific blueprint should really be
targeted at the Vitrage UI plugin and a separate blueprint should be
added to Horizon to create the extension point in the page header.

David

On Wed, May 31, 2017 at 11:06 AM, Waines, Greg
 wrote:
> Hey Rob,
>
>
>
> Just thought I’d check in on whether Horizon team has had a chance to review
> the following blueprint:
>
> https://blueprints.launchpad.net/horizon/+spec/vitrage-alarm-counts-in-topnavbar
>
>
>
> The blueprint in Vitrage which the above Horizon blueprint depends on has
> been approved by Vitrage team.
>
> i.e.   https://blueprints.launchpad.net/vitrage/+spec/alarm-counts-api
>
>
>
> let me know if you’d like to setup a meeting to discuss,
>
> Greg.
>
>
>
> From: Rob Cresswell 
> Reply-To: "openstack-dev@lists.openstack.org"
> 
> Date: Thursday, May 18, 2017 at 11:40 AM
> To: "openstack-dev@lists.openstack.org" 
> Subject: Re: [openstack-dev] [horizon] Blueprint process question
>
>
>
> There isn't a specific time for blueprint review at the moment. It's usually
> whenever I get time, or someone asks via email or IRC. During the weekly
> meetings we always have time for open discussion of bugs/blueprints/patches
> etc.
>
>
>
> Rob
>
>
>
> On 18 May 2017 at 16:31, Waines, Greg  wrote:
>
> A blueprint question for horizon team.
>
>
>
> I registered a new blueprint the other day.
>
> https://blueprints.launchpad.net/horizon/+spec/vitrage-alarm-counts-in-topnavbar
>
>
>
> Do I need to do anything else to get this reviewed?  I don’t think so, but
> wanted to double check.
>
> How frequently do horizon blueprints get reviewed?  once a week?
>
>
>
> Greg.
>
>
>
>
>
> p.s. ... the above blueprint does depend on a Vitrage blueprint which I do
> have in review.
>
>
>
>
> __
> 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 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] Adding Ying Zuo to core team

[David Lyle]

Welcome Ying Zuo!

On Mon, May 1, 2017 at 5:19 AM, Rob Cresswell (rcresswe)
 wrote:
> Hey everyone,
>
> I’m adding Ying Zuo to the Horizon Core team. She’s been contributing many 
> great patches to the code base driven by operator experience, as well as 
> providing solid reviews. Welcome to the team!
>
> 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 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] Proposing Kenji Ishii for core

[David Lyle]

+1

On Tue, Nov 15, 2016 at 5:02 AM, Akira Yoshiyama
 wrote:
> +1
>
> 2016年11月15日(火) 20:47 Rob Cresswell (rcresswe) :
>>
>> Big +1 from me
>>
>> > On 14 Nov 2016, at 00:24, Richard Jones  wrote:
>> >
>> > Hi Horizon core team,
>> >
>> > I propose Kenji Ishii as a new Horizon core reviewer. Kenji has been a
>> > solid Horizon contributor for some time, with thoughtful and helpful
>> > reviews showing good judgment and good knowledge of Horizion and
>> > related systems. Please respond with your votes by Friday.
>> >
>> >
>> > Thanks,
>> >
>> >Richard
>> >
>> >
>> > __
>> > 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 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 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 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] Resigning from horizon core

[David Lyle]

Thank you Matthias for all your contributions over the past several
years. Horizon is much better for having you and I have personally
benefited from your leadership and mentoring.

Thank you,
David

On Wed, Oct 26, 2016 at 5:27 PM, Matthias Runge  wrote:
> Hello,
>
> this has been long due (and thank you Richard for reminding me),
> my job responsibilities changed a while ago, and I don't have the
> time anymore to review patches in Horizon or even to submit new ones.
>
> Please remove my horizon core status (and the horizon-stable-maint as
> well).
>
> Thank you, and best,
> Matthias
> --
> Matthias Runge 
>
> Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
> Commercial register: Amtsgericht Muenchen, HRB 153243,
> Managing Directors: Charles Cachera, Michael Cunningham,
> Michael O'Neill, Eric Shander
>
> __
> 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 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][FFE]Support a param to specify subnet or fixed IP when creating port

[David Lyle]

I agree this seems reasonable and a good addition for users with minimal risk.

David

On Tue, Aug 30, 2016 at 10:29 AM, Rob Cresswell (rcresswe)
 wrote:
> I’m happy to allow this personally, but wanted to get others input and give 
> people the chance to object.
>
> My reasoning for allowing this:
> - It’s high level, doesn’t affect any base horizon lib features.
> - It is mature code, has multiple patch sets and a +2
>
> I’ll give it a few days to allow others a chance speak up, then we can move 
> forward.
>
> Rob
>
>> On 29 Aug 2016, at 07:17, Kenji Ishii  wrote:
>>
>> Hi, horizoners
>>
>> I'd like to request a feature freeze exception for the feature.
>> (This is a bug ticket, but the contents written in this ticket is a new 
>> feature.)
>> https://bugs.launchpad.net/horizon/+bug/1588663
>>
>> This is implemented by the following patch.
>> https://review.openstack.org/#/c/325104/
>>
>> It is useful to be able to create a port with using subnet or IP address 
>> which a user want to use.
>> And this has already reviewed by many reviewers, so I think the risk in this 
>> patch is very few.
>>
>> ---
>> Best regards,
>> Kenji Ishii
>>
>> __
>> 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 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 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] [FFE] Horizon Profiler feature (and openstack/osprofiler integration)

[David Lyle]

As a developer feature, I would vote for merging in early Ocata rather
than as a FFE. Since the potential risk is to users and operators and
they won't generally benefit from the feature, I don't see the upside
outweighing the potential risk.  It's not a localized change either.

That said, I think the profiler work will be extremely valuable in
Ocata and beyond. Thanks for your continued efforts on bringing it to
life.

David

On Wed, Aug 31, 2016 at 6:14 AM, Timur Sufiev  wrote:
> Hello, folks!
>
> I'd like to ask for a feature-freeze exception for a Horizon Profiler
> feature [1], that has been demoed long ago (during Portland midcycle Feb
> 2016) and is finally ready. The actual request applies to the 3 patches [2]
> that provide the bulk of Profiler functionality.
>
> It is a quite useful feature that is aimed mostly to developers, thus it is
> constrained within Developer dashboard and disabled by default - so it
> shouldn't have any impact on User-facing Horizon capabilities.
>
> [1]
> https://blueprints.launchpad.net/horizon/+spec/openstack-profiler-at-developer-dashboard
> [2]
> https://review.openstack.org/#/q/topic:bp/openstack-profiler-at-developer-dashboard+status:open
>
> __
> 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 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] [searchlight] Rick Aulino core nomination

[David Lyle]

+1

On Tue, Jul 26, 2016 at 9:27 AM, McLellan, Steven
 wrote:
> +1 - Rick's done a lot of good reviews over various parts of the codebase.
>
> On 7/25/16, 4:01 PM, "Tripp, Travis S"  wrote:
>
>>Hello!
>>
>>I am nominating Rick Aulino for Searchlight core. Rick has been working
>>on the core indexing engine throughout Mitaka and Newton. He has
>>developed a Neutron plug-in and has reviewed most of the other plugins in
>>Searchlight.  Since the beginning of Mitaka [0] and for the first two
>>Newton milestones [1], Rick is consistently in the top 5 for reviews and
>>commits. He has provided thoughtful feedback and valuable insights
>>throughout his time on Searchlight.
>>
>>[0] http://stackalytics.com/report/contribution/searchlight-group/242
>>[1] http://stackalytics.com/report/contribution/searchlight-group/100
>>
>>Thanks,
>>Travis
>>__
>>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 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 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] Plugin stability, failing tests etc.

[David Lyle]

I think basing the plugins against master is the best solution since
the plugin in development will want to work with the matching horizon
release. Finding issues sooner and hopefully one at a time is a lot
easier to address than a bundle of them at the end of a release cycle.
Hopefully, Horizon doesn't break plugins on a regular basis. If we
are, then we are not being focused enough around supporting plugins by
maintaining compatibility and focused too much around what's easiest
for Horizon in the development process. Horizon is no longer at the
top of the stack, we should develop with that awareness. Of course,
breaking changes will happen, but they should be limited and isolated.

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

Re: [openstack-dev] [magnum-ui][magnum] Proposed Core addition, and removal notice

[David Lyle]

+1 on my account, I've not had time to contribute.

David

On Fri, Jun 10, 2016 at 8:12 AM, Hongbin Lu <hongbin...@huawei.com> wrote:
> +1
>
>> -Original Message-
>> From: Shuu Mutou [mailto:shu-mu...@rf.jp.nec.com]
>> Sent: June-10-16 5:33 AM
>> To: openstack-dev@lists.openstack.org
>> Cc: Haruhiko Katou
>> Subject: [openstack-dev] [magnum-ui][magnum] Proposed Core addition,
>> and removal notice
>>
>> Hi team,
>>
>> I propose the following changes to the magnum-ui core group.
>>
>> + Thai Tran
>>   http://stackalytics.com/report/contribution/magnum-ui/90
>>   I'm so happy to propose Thai as a core reviewer.
>>   His reviews have been extremely valuable for us.
>>   And he is active Horizon core member.
>>   I believe his help will lead us to the correct future.
>>
>> - David Lyle
>>
>> http://stackalytics.com/?metric=marks_type=openstack=al
>> l=magnum-ui_id=david-lyle
>>   No activities for Magnum-UI since Mitaka cycle.
>>
>> - Harsh Shah
>>   http://stackalytics.com/report/users/hshah
>>   No activities for OpenStack in this year.
>>
>> - Ritesh
>>   http://stackalytics.com/report/users/rsritesh
>>   No activities for OpenStack in this year.
>>
>> Please respond with your +1 votes to approve this change or -1 votes to
>> oppose.
>>
>> Thanks,
>> Shu
>>
>>
>> ___
>> ___
>> 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 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 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] [searchlight] Searchlight Core Nomination - Lei Zhang

[David Lyle]

+1

On Tue, May 17, 2016 at 2:58 PM, McLellan, Steven
 wrote:
> +1, Lei's made some great contributions.
>
> On 5/17/16, 3:56 PM, "Brian Rosmaita"  wrote:
>
>>+1
>>
>>I second the motion!
>>
>>On 5/17/16, 3:42 PM, "Tripp, Travis S"  wrote:
>>
>>>I am nominating Lei Zhang from Intel (lei-zh on IRC) to join the
>>>Searchlight core reviewers team. He has been actively participating with
>>>thoughtful patches and reviews demonstrating his depth of understanding
>>>in a variety of areas. He also participates in meetings regularly,
>>>despite a difficult time zone. You may review his Searchlight activity
>>>reports below [0] [1].
>>>
>>>[1] (~Mitaka + Newton)
>>>  http://stackalytics.com/report/contribution/searchlight-group/200
>>>[0] (~Newton)
>>>  
>>> http://stackalytics.com/report/contribution/searchlight-group/40
>>>
>>>Please vote for this change in reply to this message.
>>>
>>>Thank you,
>>>Travis
>>>
>>>
>>>_
>>>_
>>>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 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 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 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] [UX] OpenStack UX core nomination

[David Lyle]

+1

On Thu, May 5, 2016 at 2:11 PM, Kruithof Jr, Pieter
 wrote:
> I would like to nominate Shamail Tahir as a core for the OpenStack UX project.
>
> Shamail has been central to developing a set of personas for the overall 
> community and providing his significant expertise with customers.  In some 
> ways, he has also been our focal to the other community projects.
>
> His nomination supports the goal of OpenStack UX to support cross-project 
> initiatives.
>
> Piet
>
> PTL, OpenStack UX project
>
> Piet Kruithof
>
> Sr User Experience Architect,
> Intel Open Source Technology Group
>
> Project Technical Lead (PTL)
> OpenStack UX project
>
> __
> 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 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][stable] proposing Rob Cresswell for Horizon stable core

[David Lyle]

+1

On Thu, Apr 7, 2016 at 8:05 PM, Zhenguo Niu  wrote:
> definitely +1
>
> On Fri, Apr 8, 2016 at 12:42 AM, Brad Pokorny 
> wrote:
>>
>> +1. I think Rob will provide good input for stable.
>>
>> Thanks,
>> Brad
>>
>> From: Timur Sufiev 
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Date: Thursday, April 7, 2016 at 4:31 AM
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Subject: Re: [openstack-dev] [Horizon][stable] proposing Rob Cresswell for
>> Horizon stable core
>>
>> +1
>> Чт, 7 апр. 2016 г. в 14:04, Itxaka Serrano Garcia :
>>>
>>> Im still not sure if non-cores (i.e. peasants like me) can vote but I
>>> will do it anyway :D
>>>
>>> A big +1 from me.
>>>
>>> Itxaka
>>>
>>> On 04/07/2016 12:01 PM, Matthias Runge wrote:
>>> > Hello,
>>> >
>>> > I'm proposing Rob Cresswell to become stable core for Horizon. I
>>> > thought, in the past all PTL were in stable team, but this doesn't seem
>>> > to be true any more.
>>> >
>>> > Please chime in with +1/-1
>>> >
>>>
>>>
>>> __
>>> 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 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
>>
>
>
>
> --
> Best Regards,
> Zhenguo Niu
>
> __
> 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 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] [election] [tc] TC Candidacy

[David Lyle]

I would like to announce my candidacy for election to the Technical Committee.

You may know me from being the Horizon PTL for the past five releases and a
member of the OpenStack community since 2012 as an operator, contributor and
PTL. Over my tenure, I helped guide the Horizon team through growth that has
paralleled the growth of OpenStack. During this time, I have become sensitized
to the issues that are facing OpenStack at large and specifically from a
horizontal project perspective. I decided to step away from the PTL role this
cycle as I want to focus my efforts toward addressing these issues. The main
issues I want to see progress on in Newton and Ocata are:

1) Setting and driving technical direction and project vision

I think the Technical Committee should take a more active role in driving the
direction of OpenStack. OpenStack now contains many, many projects. The
unified guiding technical direction for those projects is missing. The
OpenStack mission statement reads:

"to produce the ubiquitous Open Source Cloud Computing platform that will
meet the needs of public and private clouds regardless of size, by being
simple to implement and massively scalable"

I will argue that without a unified direction, OpenStack will be many cloudy
things that, with considerable effort, can be used to deliver a cloud computing
solution. That delivers more toward the first half of the mission, than the
latter half. But the technical direction from the TC needs to be more than make
the mission statement reality. While that is enough for projects to make
progress, it is insufficient for end users and operators.

The current cross-project model is broken. The idea of cross-project
initiatives and specs is correct, the problem arises in getting projects to
a) participate in that process
b) actually have that initiative put items on their roadmap
c) actually implement the change

There is no motivation, carrot or stick at this point for projects on
cross-project initiatives. Currently, any cross-project initiative can
effectively be pocket vetoed by a project in OpenStack that does not find it a
priority. Additionally, the cross-project priorities vary per project. Making
progress currently relies on a few individuals doing the work in all effected
projects. With 54 projects, 36 of which are service related, this can be
a prohibitive task. I commend all those who are driving these efforts.

I propose the Technical Committee, working with the user committee and project
teams define some core objectives per release that define the release goals and
track to those. With 54 projects in OpenStack, there is not another way to move
these efforts forward without a lead time of years. One could argue that this
is the purview of the cross-project liaisons, but the TC is the elected
technical governing body in OpenStack and the only one actually defined in the
OpenStack Bylaws.


2) Addressing Big Tent ramifications

Having moved away from a relatively narrow and focused scope for OpenStack,
it is imperative that we improve at functioning as one project. Looking across
OpenStack, since the big tenting, I see a few issues. First and foremost, the
problem of maintaining consistency across projects went from bad to worse.
Previously, consistency problems were centered on APIs, logging, message
content and structure. Now, we have added items like end user documentation and
the forced proliferation of plugin formats. The large number and variety of
projects also makes it difficult to maintain an overall project vision. I think
that may be the current goal. But if we view OpenStack as a merely a kit, we
will again be pushing undo burden on end users and operators. The TC should
formally state whether OpenStack is meant to be a product or a kit,
understanding that a product can have optional and swappable parts.


3) Growth and organization

Many projects are big and unwieldy including the one I lead. The large scope
of projects and the corresponding number of contributors make these projects
sluggish and makes contributing difficult. Contributions are being shoved
through a narrow funnel where priorities are a strange mix of new feature
development and addressing operator needs. I think we need to reevaluate
project scope and governance. This is one area that the big tent provides some
relief, rather than forcing the franken-projects of yore. Breaking out
separable pieces from larger projects should be a high priority. We started
doing this work in Horizon. The consequences of not breaking the monoliths is
that we continue to frustrate new and old developers alike, drown reviewers and
make little relative forward progress. I believe the TC can help design and
drive this restructuring effort.

I still believe OpenStack has the potential to deliver on our mission
statement. And, I think that diverse views being included in the TC is to
everyone's advantage.

Thank you for your consideration,

Re: [openstack-dev] [all] Maintaining httplib2 python library

[David Lyle]

On Mar 14, 2016 11:32 AM, "Sean McGinnis"  wrote:

> On Mon, Mar 14, 2016 at 10:37:52AM -0400, Sean Dague wrote:
> > On 03/14/2016 10:24 AM, Ian Cordasco wrote:
> > >
> > >
> > > -Original Message-
> > > From: Davanum Srinivas 
> > > Reply: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> > > Date: March 14, 2016 at 09:18:50
> > > To: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> > > Subject:  [openstack-dev] [all] Maintaining httplib2 python library
> > >
> > >> Team,
> > >>
> > >> fyi, http://bitworking.org/news/2016/03/an_update_on_httplib2
> > >>
> > >> We have httplib2 in our global requirements and lots of projects are
> > >> using it[1]. Is there anyone willing to step up?
> > >
> > > Is it really worth our time to dedicate extra resources to that?
> Glance has been discussing (but it's been a low priority) to switing all
> our dependence on httplib2 to requests (and maybe urllib3 directly) as
> necessary.
> > >
> > > We have other tools and libraries we can use without taking over
> maintenance of yet another library.
> > >
> > > I think the better question than "Can people please maintain this for
> the community?" is "What benefits does httplib2 have over something that is
> actively maintained (and has been actively maintaiend) like urllib3,
> requests, etc.?"
> > >
> > > And then we can (and should) also ask "Why have we been using this?
> How much work do cores think it would be to remove this from our global
> requirements?"
>
> Cinder only has it in a new backup driver for Google Cloud Storage. The
> googleapiclient docs actually say to use httplib2 for one of the calls
> "or something that acts like it."
>
> I will see if we can switch this over to an appropriate duck type. I
> would much rather get rid of usage than unnecessarily keep a project on
> life support.
>
> >
> > +1.
> >
> > Here is the non comprehensive list of usages based on what trees I
> > happen to have checked out (which is quite a few, but not all of
> > OpenStack for sure).
> >
> > I think before deciding to take over ownership of an upstream lib (which
> > is a large commitment over space and time), we should figure out the
> > migration cost. All the uses in Tempest come from usage in Glance IIRC
> > (and dealing with chunked encoding).
> >
> > Neutron seems to use it for a couple of proxies, but that seems like
> > requests/urllib3 might be sufficient.
> >
> > In Horizon it's only used for a couple of tests.
>

Horizon only has some out of date test code framework using httplib2. I
will remove shortly.



> >
> > EC2 uses it as a proxy client to the Nova metadata service. Again, I
> > can't imagine that requests wouldn't be sufficient.
> >
> > Trove doesn't seem to actually use it (though it's listed), though maybe
> > wsgi_intercept uses it directly?
> >
> > run_tests.py:from wsgi_intercept.httplib2_intercept import install as
> > wsgi_install
> >
> > python-muranoclient lists it as a requirement, there is no reference in
> > the source tree for it.
> >
> >
> > I suspect Glance is really the lynchpin here (as it actually does some
> > low level stuff with it). If there can be a Glance plan to get off of
> > it, the rest can follow pretty easily.
> >
> >   -Sean
> >
> > --
> > Sean Dague
> > http://dague.net
> >
> >
>

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

Re: [openstack-dev] [horizon] Proposal to add Diana Whitten tohorizon-core

[David Lyle]

Welcome Diana. Thanks for all of your hard work and dedication.

David

On Fri, Mar 11, 2016 at 11:51 AM, Akihiro Motoki <amot...@gmail.com> wrote:
> +1 from me too!
>
> 2016-03-11 17:38 GMT+09:00 Tatiana Ovtchinnikova 
> <t.v.ovtchinnik...@gmail.com>:
>> +1. Thanks for your contribution!
>>
>>
>>
>> 2016-03-11 6:40 GMT+03:00 Zhenguo Niu <niu.zgli...@gmail.com>:
>>>
>>> +1 from me, thanks for all the hard work!
>>>
>>> On Thu, Mar 10, 2016 at 3:27 AM, Michael Krotscheck <krotsch...@gmail.com>
>>> wrote:
>>>>
>>>> +1. Another vote in favor of ditching django altogether is good by me :)
>>>>
>>>> On Wed, Mar 9, 2016 at 11:25 AM Thai Q Tran <tqt...@us.ibm.com> wrote:
>>>>>
>>>>> Big +1 from me, thanks for all the hard work Diana!
>>>>>
>>>>>
>>>>> - Original message -
>>>>> From: David Lyle <dkly...@gmail.com>
>>>>> To: OpenStack Development Mailing List
>>>>> <openstack-dev@lists.openstack.org>
>>>>> Cc:
>>>>> Subject: [openstack-dev] [horizon] Proposal to add Diana Whitten to
>>>>> horizon-core
>>>>> Date: Tue, Mar 8, 2016 2:07 PM
>>>>>
>>>>> I propose adding Diana Whitten[1] to horizon-core.
>>>>>
>>>>> Diana is an active reviewer, contributor and community member. Over
>>>>> the past couple of releases, Diana has driven extensive changes around
>>>>> theme-ability in Horizon and drastically increased the standardization
>>>>> of our use of bootstrap. During this time, Diana has also provided
>>>>> valuable reviews to keep us on the straight and narrow preventing our
>>>>> continued abuse of defenseless web technologies.
>>>>>
>>>>> Please respond with comments, +1s, or objections by Friday.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>> [1]
>>>>> http://stackalytics.com/?module=horizon-group_id=hurgleburgler=all
>>>>>
>>>>>
>>>>> __
>>>>> 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 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 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
>>>>
>>>
>>>
>>>
>>> --
>>> Best Regards,
>>> Zhenguo Niu
>>>
>>> __
>>> 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 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 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 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 noncandidacy

[David Lyle]

After five cycles as PTL of Horizon, I've decided not to run for the
Newton cycle.

I am exceptionally proud of the things we've accomplished over this
time. I'm amazed by how much our project's community has grown and
evolved.

Looking at the community now, I believe we have a tremendous group of
contributors for moving forward. There are several people capable of
becoming great PTLs and overall the community will be healthier with
some turnover in the PTL role. I feel honored to have had your trust
over this time and lucky to have worked with such great people.

I will still be around and will help the next PTL make a smooth
transition where requested.

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

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

[David Lyle]

On Mon, Mar 7, 2016 at 9:52 PM, Richard Jones 
wrote:

> We've solved *most* of the issues around releasing new xstatic packages,
> documented here[1] (and related documentation).
>
> We have one final issue that's blocking us, which is that during the
> xstatic release there will be a point at which Horizon may be broken from
> an integrated point of view - some of the interfaces may not work and fail
> tests. The process goes something like this:
>
> ​Note: this assumes that depends-on can reliably bring in patches from all
> over the place into a gate environment, which is technically possible, but
> not necessarily correct today.
>
> The problem is that because we can't atomically update both
> upper-constraints *and* Horizon at the same time (or upper-constraints
> *and* xstatic-angular, or Horizon *and* xstatic-angular) we run into a
> situation where Horizon will be running against the wrong version of
> xstatic-angular.
>
> So we break one of the basic assumptions of the OpenStack world: that
> every single commit in every repository for the integrated environment will
> pass tests.
>
> In the Python world, we code around this by making Horizon compatible with
> both the X and X1 versions of xstatic-angular (if it was a Python library).
> In Javascript land this is much more difficult - Javascript libraries tend
> to break compatibility in far more interesting ways. Maintaining
> compatibility across CSS and font releases is also a difficult problem,
> though changes here are unlikely to break Horizon enough that gate tests
> would fail. So, solution 1 to the problem is:
>
> SOLUTION 1: always maintain Horizon compatibility across xstatic library
> releases.
>
> This is potentially very difficult to guarantee. So, a second solution has
> been proposed:
>

This seems unlikely to go well.


>
> SOLUTION 2: move the upper-constraints information for *the xstatic
> libraries only* from the global upper-constraints file into Horizon's
> repository.
>
> This allows us to atomically update both Horizon and the xstatic library
> version, removing the potential to break because of the version mismatch.
> Unfortunately it means that we have version compatibility issues with
> anything else that wants to install alongside Horizon that also uses
> xstatic packages. For example, Horizon plugins. We could move Horizon
> plugins into the Horizon repository to solve this. /ducks
>

I don't know that you can duck low enough for that.

I'm wondering if since horizon is really the only project consuming these
xstatic libraries and none are likely to venture down this path of madness
with us that it would be safe to manage the xstatic requirements and
upper-constraints locally.

Technically the plugins for horizon depend on this, but they depend via
horizon. If they require specific versions that are not supported by
Horizon, I think all bets are off anyway.


>
> A variation on this solution is:
>
> SOLUTION 3: allow Horizon to locally override upper-constraints for the
> time needed to merge a patch in devstack.
>
> This solution allows Horizon to atomically update itself and the xstatic
> library, but it also means installing Horizon in a CI/CD environment
> becomes more difficult due to the need to always pull down the
> upper-constraints file and edit it. We could code this in to tox, but that
> doesn't help eg. devstack which needs to also do this thing.
>
>
I combined this with #2.


> SOLUTION 4: vendor the javascript
>
> Heh.
>

This makes me sad.


>
> SOLUTION 5: have dependencies on xstatic move from global requirements to
> Horizon
>
> This is similar to 2 & 3 with some of the same drawbacks (multiple users
> of xstatic) but also we'd need a change to global-requirements handling to
> ignore some entries in Horizon's requirements.
>
>
I guess I combined 2, 3 and 5. Just remove the xstatic overhead from the
openstack global mechanism.


> Your thoughts on any and all of the above are requested.
>
>
> Richard
>
> [1] https://review.openstack.org/#/c/289142/
>
>
> __
> 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
>
>
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] Proposal to add Diana Whitten to horizon-core

[David Lyle]

I propose adding Diana Whitten[1] to horizon-core.

Diana is an active reviewer, contributor and community member. Over
the past couple of releases, Diana has driven extensive changes around
theme-ability in Horizon and drastically increased the standardization
of our use of bootstrap. During this time, Diana has also provided
valuable reviews to keep us on the straight and narrow preventing our
continued abuse of defenseless web technologies.

Please respond with comments, +1s, or objections by Friday.

Thanks,
David

[1] 
http://stackalytics.com/?module=horizon-group_id=hurgleburgler=all

__
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] Handling 401 in new REST API

[David Lyle]

I think that's the sane thing to do.

David

On Thu, Jan 28, 2016 at 2:55 AM, Richard Jones  wrote:
> Hi fellow angular/REST Horizon developers,
>
> I'd like to propose that we handle HTTP 401 responses at the core of the new
> angular code interfacing to our new REST API so that *any* 401 just does
> basically what the Django code used to: redirect to the login page with a
> "from".
>
> What do y'all think?
>
>
> Richard
>
>
> __
> 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 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] [searchlight] Nominating Li Yingjun to Searchlight Core

[David Lyle]

+1

On Mon, Jan 25, 2016 at 5:15 AM, Brian Rosmaita
 wrote:
> +1
>
> On 1/22/16, 7:09 PM, "Tripp, Travis S"  wrote:
>
>>I am nominating Li Yingjun (yingjun on IRC) to join the Searchlight core
>>reviewers team. We are a young project and he has already made a
>>noticeable impact with his contributions. You may review his Searchlight
>>[0] and cross-project [1] activity reports below. He has been
>>participating in meetings regularly, despite a difficult timezone. He
>>also has a broad base of exposure in OpenStack in terms of commits (26
>>different projects /repos) and reviews (23 different projects / repos).
>>This cross project knowledge is important to Searchlight¹s charter.
>>
>>[0] http://stackalytics.com/report/contribution/searchlight-group/90
>>[1] http://stackalytics.com/report/users/liyingjun
>>
>>Please vote for this change in reply to this message.
>>
>>Thank you,
>>Travis
>>
>>
>>
>>
>>__
>>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 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 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] Mid-cycle Sprint

[David Lyle]

The Horizon mid-cycle sprint is in Hillsboro, Oregon Feb 23-25 and
hosted at the Intel site in Hillsboro just west of Portland.

The wiki for the mid-cycle sprint is
https://wiki.openstack.org/wiki/Sprints/HorizonMitakaSprint

Please note your intention to attend on the wiki page.

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] Weekly IRC meetings cancelled Dec 23rd and 30th

[David Lyle]

There will be no Horizon and HorizonDrivers meetings on Dec 23rd and Dec 30th.

We will resume on Jan 6th.

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

Re: [openstack-dev] [horizon] Proposal to add Richard Jones tohorizon-core

[David Lyle]

Since the results are unanimous, closing early. Welcome Richard!

David

On Thu, Dec 3, 2015 at 12:08 PM, Thai Q Tran <tqt...@us.ibm.com> wrote:
> An equally BIG +1 from me! Thanks for all the reviews and patches from your
> minions Richard!
>
>
> - Original message -----
> From: David Lyle <dkly...@gmail.com>
> To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org>
> Cc:
> Subject: [openstack-dev] [horizon] Proposal to add Richard Jones to
> horizon-core
> Date: Wed, Dec 2, 2015 10:57 AM
>
> I propose adding Richard Jones[1] to horizon-core.
>
> Over the last several cycles Timur has consistently been providing
> great reviews, actively participating in the Horizon community, and
> making meaningful contributions around angularJS and overall project
> stability and health.
>
> Please respond with comments, +1s, or objections within one week.
>
> Thanks,
> David
>
> [1]
> http://stackalytics.com/?module=horizon-group_id=r1chardj0n3s=all
>
> __
> 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 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 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] Proposal to add Timur Sufiev tohorizon-core

[David Lyle]

Since the results are unanimous, closing early. Welcome Timur!

David

On Thu, Dec 3, 2015 at 12:06 PM, Thai Q Tran <tqt...@us.ibm.com> wrote:
> BIG +1 for me. Thanks for all of the great work Timur!
>
>
> - Original message -----
> From: David Lyle <dkly...@gmail.com>
> To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org>
> Cc:
> Subject: [openstack-dev] [horizon] Proposal to add Timur Sufiev to
> horizon-core
> Date: Wed, Dec 2, 2015 10:54 AM
>
> I propose adding Timur Sufiev[1] to horizon-core.
>
> Over the last several cycles Timur has consistently been providing
> great reviews, actively participating in the Horizon community, and
> making meaningful contributions particularly around testing and
> stability.
>
> Please respond with comments, +1s, or objections within one week.
>
> Thanks,
> David
>
> [1]
> http://stackalytics.com/?module=horizon-group_id=tsufiev-x=all
>
> __
> 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 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 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] Proposal to add Richard Jones to horizon-core

[David Lyle]

I propose adding Richard Jones[1] to horizon-core.

Over the last several cycles Timur has consistently been providing
great reviews, actively participating in the Horizon community, and
making meaningful contributions around angularJS and overall project
stability and health.

Please respond with comments, +1s, or objections within one week.

Thanks,
David

[1] 
http://stackalytics.com/?module=horizon-group_id=r1chardj0n3s=all

__
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] Proposal to add Richard Jones to horizon-core

[David Lyle]

Let's try that again.

I propose adding Richard Jones[1] to horizon-core.

Over the last several cycles Richard has consistently been providing
great reviews, actively participating in the Horizon community, and
making meaningful contributions around angularJS and overall project
stability and health.

Please respond with comments, +1s, or objections within one week.

Thanks,
David

[1] 
http://stackalytics.com/?module=horizon-group_id=r1chardj0n3s=all

On Wed, Dec 2, 2015 at 11:56 AM, David Lyle <dkly...@gmail.com> wrote:
> I propose adding Richard Jones[1] to horizon-core.
>
> Over the last several cycles Timur has consistently been providing
> great reviews, actively participating in the Horizon community, and
> making meaningful contributions around angularJS and overall project
> stability and health.
>
> Please respond with comments, +1s, or objections within one week.
>
> Thanks,
> David
>
> [1] 
> http://stackalytics.com/?module=horizon-group_id=r1chardj0n3s=all

__
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] Proposal to add Timur Sufiev to horizon-core

[David Lyle]

I propose adding Timur Sufiev[1] to horizon-core.

Over the last several cycles Timur has consistently been providing
great reviews, actively participating in the Horizon community, and
making meaningful contributions particularly around testing and
stability.

Please respond with comments, +1s, or objections within one week.

Thanks,
David

[1] http://stackalytics.com/?module=horizon-group_id=tsufiev-x=all

__
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] Meetings Canceled for Nov 4

[David Lyle]

Due to recent summit and many folks being on vacation, both the
Horizon and Horizon Drivers meeting are canceled for Nov 4.  We will
resume on November 11.

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] Mitaka schedule and etherpads

[David Lyle]

The schedule for Horizon is published [1] and the initial etherpads
are linked [2]. Happy typing.

Looking forward to seeing everyone next week.

David

[1] http://mitakadesignsummit.sched.org/overview/type/horizon
[2] https://wiki.openstack.org/wiki/Design_Summit/Mitaka/Etherpads#Horizon

__
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] [all] service catalog: TNG

[David Lyle]

I'm in too.

David

On Fri, Oct 9, 2015 at 8:51 AM, Dean Troyer  wrote:
> On Fri, Oct 9, 2015 at 9:39 AM, Sean Dague  wrote:
>>
>> Lastly, I think it's pretty clear we probably need a dedicated workgroup
>> meeting to keep this ball rolling, come to a reasonable plan that
>> doesn't break any existing deployed code, but lets us get to a better
>> world in a few cycles. annegentle, stevemar, and I have been pushing on
>> that ball so far, however I'd like to know who else is willing to commit
>> a chunk of time over this cycle to this. Once we know that we can try to
>> figure out when a reasonable weekly meeting point would be.
>
>
> Count me in...
>
> dt
>
> --
>
> Dean Troyer
> dtro...@gmail.com
>
> __
> 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 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] [stable][horizon] adding Doug Fish to horizon stable-maint

[David Lyle]

+1

On Thu, Oct 1, 2015 at 3:21 AM, Matthias Runge  wrote:
> Hello,
>
> I would like to propose to add
>
> Doug Fish (doug-fish)
>
> to horizon-stable-maint team.
>
> I'd volunteer and introduce him to stable branch policy.
>
> Matthias
> --
> Matthias Runge 
>
> __
> 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 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] Mitaka Summit Topic Proposals

[David Lyle]

It's time to express your topic proposals for the Mitaka summit. In
order to provide an accessible tool for all geographies, we'll be
compiling session topics on an etherpad again for Mitaka.

https://etherpad.openstack.org/p/horizon-mitaka-summit

Please add your ideas there and follow the brief guidelines at the top.

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

[David Lyle]

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]Let's take care of our integration tests

[David Lyle]

Of course, your question confused me. As you switched to selenium tests.

To run integration tests,
./run_tests.sh --integration

which is also documented in ./run_tests.sh --help

David

On Fri, Sep 11, 2015 at 10:25 AM, David Lyle <dkly...@gmail.com> wrote:
> Oops!
>
> ./run_tests.sh --only-selenium   only skips the non-selenium tests. It
> works as intended.  ./run_tests.sh --with-selenium will run all tests.
> Both of which are documented in the help of run_tests.sh
>
> David
>
> On Fri, Sep 11, 2015 at 10:23 AM, David Lyle <dkly...@gmail.com> wrote:
>> raj
>>
>> On Fri, Sep 11, 2015 at 10:11 AM, Rajat Vig <raj...@thoughtworks.com> wrote:
>>> Is there any documentation to run the tests locally?
>>> Doing ./run_tests.sh --only-selenium skips a lot of tests. Is that the
>>> recommended way?
>>>
>>> -Rajat
>>>
>>> On Thu, Sep 10, 2015 at 3:54 PM, David Lyle <dkly...@gmail.com> wrote:
>>>>
>>>> I completely agree about monitoring for integration test failures and
>>>> blocking until the failure is corrected.
>>>>
>>>> The hope is to make sure we've stabilized the integration testing
>>>> framework a bit before reenabling to vote.
>>>>
>>>> Thanks Timur, I know this has been a considerable undertaking.
>>>>
>>>> David
>>>>
>>>> On Thu, Sep 10, 2015 at 4:26 PM, Douglas Fish <drf...@us.ibm.com> wrote:
>>>> > It looks like we've reached the point where our Horizon integration
>>>> > tests
>>>> > are functional again.  Thanks for your work on this Timur! (Offer for
>>>> > beer/hug at the next summit still stands)
>>>> >
>>>> > I'd like to have these tests voting again ASAP, but I understand that
>>>> > might
>>>> > be a bit risky at this point. We haven't yet proven that these tests
>>>> > will be
>>>> > stable over the long term.
>>>> >
>>>> > I encourage all of the reviewers to keep the integration tests in mind
>>>> > as we
>>>> > are reviewing code. Keep an eye on the status of the
>>>> > gate-horizon-dsvm-integration test. It's failure would be great reason
>>>> > to
>>>> > hand out a -1!
>>>> >
>>>> > Doug
>>>> >
>>>> >
>>>> >
>>>> > __
>>>> > 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 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 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 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]Let's take care of our integration tests

[David Lyle]

raj

On Fri, Sep 11, 2015 at 10:11 AM, Rajat Vig <raj...@thoughtworks.com> wrote:
> Is there any documentation to run the tests locally?
> Doing ./run_tests.sh --only-selenium skips a lot of tests. Is that the
> recommended way?
>
> -Rajat
>
> On Thu, Sep 10, 2015 at 3:54 PM, David Lyle <dkly...@gmail.com> wrote:
>>
>> I completely agree about monitoring for integration test failures and
>> blocking until the failure is corrected.
>>
>> The hope is to make sure we've stabilized the integration testing
>> framework a bit before reenabling to vote.
>>
>> Thanks Timur, I know this has been a considerable undertaking.
>>
>> David
>>
>> On Thu, Sep 10, 2015 at 4:26 PM, Douglas Fish <drf...@us.ibm.com> wrote:
>> > It looks like we've reached the point where our Horizon integration
>> > tests
>> > are functional again.  Thanks for your work on this Timur! (Offer for
>> > beer/hug at the next summit still stands)
>> >
>> > I'd like to have these tests voting again ASAP, but I understand that
>> > might
>> > be a bit risky at this point. We haven't yet proven that these tests
>> > will be
>> > stable over the long term.
>> >
>> > I encourage all of the reviewers to keep the integration tests in mind
>> > as we
>> > are reviewing code. Keep an eye on the status of the
>> > gate-horizon-dsvm-integration test. It's failure would be great reason
>> > to
>> > hand out a -1!
>> >
>> > Doug
>> >
>> >
>> >
>> > __
>> > 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 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 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 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]Let's take care of our integration tests

[David Lyle]

Oops!

./run_tests.sh --only-selenium   only skips the non-selenium tests. It
works as intended.  ./run_tests.sh --with-selenium will run all tests.
Both of which are documented in the help of run_tests.sh

David

On Fri, Sep 11, 2015 at 10:23 AM, David Lyle <dkly...@gmail.com> wrote:
> raj
>
> On Fri, Sep 11, 2015 at 10:11 AM, Rajat Vig <raj...@thoughtworks.com> wrote:
>> Is there any documentation to run the tests locally?
>> Doing ./run_tests.sh --only-selenium skips a lot of tests. Is that the
>> recommended way?
>>
>> -Rajat
>>
>> On Thu, Sep 10, 2015 at 3:54 PM, David Lyle <dkly...@gmail.com> wrote:
>>>
>>> I completely agree about monitoring for integration test failures and
>>> blocking until the failure is corrected.
>>>
>>> The hope is to make sure we've stabilized the integration testing
>>> framework a bit before reenabling to vote.
>>>
>>> Thanks Timur, I know this has been a considerable undertaking.
>>>
>>> David
>>>
>>> On Thu, Sep 10, 2015 at 4:26 PM, Douglas Fish <drf...@us.ibm.com> wrote:
>>> > It looks like we've reached the point where our Horizon integration
>>> > tests
>>> > are functional again.  Thanks for your work on this Timur! (Offer for
>>> > beer/hug at the next summit still stands)
>>> >
>>> > I'd like to have these tests voting again ASAP, but I understand that
>>> > might
>>> > be a bit risky at this point. We haven't yet proven that these tests
>>> > will be
>>> > stable over the long term.
>>> >
>>> > I encourage all of the reviewers to keep the integration tests in mind
>>> > as we
>>> > are reviewing code. Keep an eye on the status of the
>>> > gate-horizon-dsvm-integration test. It's failure would be great reason
>>> > to
>>> > hand out a -1!
>>> >
>>> > Doug
>>> >
>>> >
>>> >
>>> > __
>>> > 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 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 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 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] [UX] Creating acount at Invision

[David Lyle]

Invite sent.

On Fri, Sep 11, 2015 at 2:25 PM, Hossein Zabolzadeh
 wrote:
> Hi,
> I want to have an account at Invision.
> Thanks to someone with right priviledge to create a new account for me
> there.
> I sent a request to Horizon IRC channel, but it yields no result.
>
> __
> 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 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]Let's take care of our integration tests

[David Lyle]

I completely agree about monitoring for integration test failures and
blocking until the failure is corrected.

The hope is to make sure we've stabilized the integration testing
framework a bit before reenabling to vote.

Thanks Timur, I know this has been a considerable undertaking.

David

On Thu, Sep 10, 2015 at 4:26 PM, Douglas Fish  wrote:
> It looks like we've reached the point where our Horizon integration tests
> are functional again.  Thanks for your work on this Timur! (Offer for
> beer/hug at the next summit still stands)
>
> I'd like to have these tests voting again ASAP, but I understand that might
> be a bit risky at this point. We haven't yet proven that these tests will be
> stable over the long term.
>
> I encourage all of the reviewers to keep the integration tests in mind as we
> are reviewing code. Keep an eye on the status of the
> gate-horizon-dsvm-integration test. It's failure would be great reason to
> hand out a -1!
>
> Doug
>
>
> __
> 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 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] [UX] [Keystone] [Horizon] Pagination support for Identity dashboard entities

[David Lyle]

I think we've conveniently been led off track here. The original
request/subject was regarding pagination of projects in the v3 API. Since
this is purely a keystone construct it seems implausible to me that ldap or
the IdP of choice would be limiting the ability to return a paginated list
of all projects. Or groups or domains or roles for that matter.

There is no reason to punt on pagination across the API for one resource
type, which actually would also work with select backends. Give me
something that I can exhaustively list in the API I can build from.

David
On Aug 17, 2015 10:53 AM, Fox, Kevin M kevin@pnnl.gov wrote:

 1. yes, but probably only if its a short list. It may be feasible to show
 it only if there are 5 or less pages, and maybe just load all pages of data
 and paginate it on the client. If too big, ask the user to refine their
 search? Or always paginate to 5, and then the 6th page have a page
 requesting further refinement?

 2. Not sure what the difference between searching and filtering is in this
 context? something like facets? If so, probably the 5 or less thing would
 work here too.

 3. Yes, but again, probably within a smaller set of pages?

 Thanks,
 Kevin
 
 From: Kruithof, Piet [pieter.c.kruithof...@hp.com]
 Sent: Sunday, August 16, 2015 9:41 AM
 To: openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [UX] [Keystone] [Horizon] Pagination support
 for Identity dashboard entities

 I like Michael’s response because it moved the thread towards identifying
 actual user needs before digging into the technical feasibility.  IMHO, it
 would be helpful to have a few people on the list answer his questions:

 1 - Do users want to page through search results?


 2 - Do users want to page through filter results? (do they use filter
 results?)


 3 - If they want to page, do they want to be able to go back a page and/or
 know their current page?


 I understand that even if we answer “yes” to all three questions that
 there could be issues around implementation, but at least we’ll know a gap
 exists.


 Piet Kruithof
 Sr UX Architect, HP Helion Cloud
 PTL, OpenStack UX project

 For every complex problem, there is a solution that is simple, neat and
 wrong.”

 H L Menken


 __
 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 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 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] [Keystone] [Horizon] Pagination support for Identity dashboard entities

[David Lyle]

I understand the reasoning, but there are use cases for indexing (re:
searchlight) and auditing that are completely unsupported in keystone v3.
As from keystone, I have no way to exhaustively list who has accounts in my
cloud using OpenStack APIs. That seems like a hole that should be filled.

Not to mention API consistency, which others have already brought up.

David



On Fri, Aug 14, 2015 at 9:02 AM, Morgan Fainberg morgan.fainb...@gmail.com
wrote:

 For the identity (users and groups) backend as long as we support LDAP
 (and as side note federated users never show up in this list anyway) and
 with the drive towards pushing all user management out of keystone itself
 to ldap or other tools that do it better, I don't see pagination as
 something we should be providing. Providing an inconsistent user experience
 based on leaking underlying implementation details is something I am very
 against. This stance ensures that horizon and other tools like it will not
 need to know underlying implementation details to provide a consistent user
 experience. Unfortunately here we do need to cater to the lowest common
 denominator and filtering/searching/limiting is the clear common mechanism

 With regards to resources (projects, domains, etc) since we no longer
 support using LDAP (deprecated with removal in mitaka) I have less strong
 feelings towards and wouldn't block efforts to implement if it is not
 already available (if not available this is likely a mitaka goal).

 --Morgan

 Sent via mobile

  On Aug 14, 2015, at 07:39, Jay Pipes jaypi...@gmail.com wrote:
 
  On 08/14/2015 09:14 AM, Morgan Fainberg wrote:
  As a quick note the api-ref you are linking to has some gaps/has not
  been kept in sync with the official api specifications.
 
  The official API specification is located at
  http://specs.openstack.org/openstack/keystone-specs/ (v2 and v3
 sections
  at the top) and there is a known open bug to work with the docs team to
  get this in sync (somehow).
 
  Unfortunately there are a number of cases especially with the identity
  backend where pagination just does not work (or works completely
  unreliably) such as utilizing the ldap driver. Either a cursor must be
  maintained (problematic in REST) or the results could be wildly
  different every single request meaning each page is not really
  guaranteed to be the next page it could be the same/show inconsistent
  results. The second issue is that the pagination is not a good UX even
  where it works - the simple question is: if you can filter the results
  how many pages deep do you go before refining the query; think of your
  use of search engines.
 
  In light of these issues Keystone has opted for a filter / limit
  (config). If the results exceed the limit there is a truncation that
  occurs and it is recommended extra filtering be applied to reduce the
  total number of results.
 
  This discussion has gone around a few times, pagination in keystone is
  not currently on the roadmap. In addition to the above doc bug, we
  should work to better socialize this filter-over-paginate methodology.
 
  I understand all the things you write above about the problems that
 Keystone's underlying architecture (driver-based, not always able to do
 pagination in the individual drivers). However, it really does mean that
 Keystone is the only project in OpenStack that behaves this way. All other
 services provide limit/marker paginations, AFAIK, which is efficient and,
 while not the same UX as a filtering methodology, is entirely compatible
 and complementary to filtering.
 
  Best,
  -jay
 
 
 __
  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 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 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] New Horizon blueprint review meeting

[David Lyle]

Last week in the Horizon team meeting, we voted [1] to add a meeting to
address the growing blueprint backlog. To that end, I've scheduled a
regular meeting [2] to review old and new Horizon blueprints to reduce the
clutter and focus ongoing work. We have several blueprints that need to
removed/rejected/approved/asked for more input. I'd like Horizon core and
developers to have a say in this process.

The time is alternating and is the reverse of the existing Horizon team
meetings. The first meeting is 1200 UTC Wednesday. We may get to the point
where one weekly meeting is sufficient again, but for now, I'd like to use
this to reduce the backlog and sharpen focus.

David

[1]
http://eavesdrop.openstack.org/meetings/horizon/2015/horizon.2015-08-05-12.01.html
[2] https://wiki.openstack.org/wiki/Meetings/HorizonDrivers
__
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] [Keystone] [Horizon] Federated Login

[David Lyle]

Forcing Horizon to duplicate Keystone settings just makes everything much
harder to configure and much more fragile. Exposing whitelisted, or all,
IdPs makes much more sense.

On Wed, Aug 5, 2015 at 1:33 PM, Dolph Mathews dolph.math...@gmail.com
wrote:

 On Wed, Aug 5, 2015 at 1:02 PM, Steve Martinelli steve...@ca.ibm.com
 wrote:

 Some folks said that they'd prefer not to list all associated idps, which
 i can understand.

 Why?



 Actually, I like jamie's suggestion of just making horizon a bit smarter,
 and expecting the values in the horizon settings (idp+protocol)

 But, it's already in keystone.



 Thanks,

 Steve Martinelli
 OpenStack Keystone Core

 [image: Inactive hide details for Dolph Mathews ---2015/08/05 01:38:09
 PM---On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick d.w.chadwic]Dolph
 Mathews ---2015/08/05 01:38:09 PM---On Wed, Aug 5, 2015 at 5:39 AM, David
 Chadwick d.w.chadw...@kent.ac.uk wrote:

 From: Dolph Mathews dolph.math...@gmail.com
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Date: 2015/08/05 01:38 PM
 Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login
 --




 On Wed, Aug 5, 2015 at 5:39 AM, David Chadwick *d.w.chadw...@kent.ac.uk*
 d.w.chadw...@kent.ac.uk wrote:



On 04/08/2015 18:59, Steve Martinelli wrote:
 Right, but that API is/should be protected. If we want to list IdPs
 *before* authenticating a user, we either need: 1) a new API for
listing
 public IdPs or 2) a new policy that doesn't protect that API.

Hi Steve

yes this was my understanding of the discussion that took place many
months ago. I had assumed (wrongly) that something had been done about
it, but I guess from your message that we are no further forward on
this
Actually 2) above might be better reworded as - a new policy/engine
that
allows public access to be a bona fide policy rule


 The existing policy simply seems wrong. Why protect the list of IdPs?



regards

David


 Thanks,

 Steve Martinelli
 OpenStack Keystone Core

 Inactive hide details for Lance Bragstad ---2015/08/04 01:49:29
PM---On
 Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish drfish@us.iLance
Bragstad
 ---2015/08/04 01:49:29 PM---On Tue, Aug 4, 2015 at 10:52 AM, Douglas
 Fish *drf...@us.ibm.com* drf...@us.ibm.com wrote:  Hi David,

 From: Lance Bragstad *lbrags...@gmail.com* lbrags...@gmail.com
 To: OpenStack Development Mailing List (not for usage questions)
 *openstack-dev@lists.openstack.org*
openstack-dev@lists.openstack.org
 Date: 2015/08/04 01:49 PM
 Subject: Re: [openstack-dev] [Keystone] [Horizon] Federated Login








 On Tue, Aug 4, 2015 at 10:52 AM, Douglas Fish _drf...@us.ibm.com_
 mailto:*drf...@us.ibm.com* drf...@us.ibm.com wrote:

 Hi David,

 This is a cool looking UI. I've made a minor comment on it in
InVision.

 I'm curious if this is an implementable idea - does keystone
support
 large
 numbers of 3rd party idps? is there an API to retreive the list
of
 idps or
 does this require carefully coordinated configuration between
 Horizon and
 Keystone so they both recognize the same list of idps?


 There is an API call for getting a list of Identity Providers from
Keystone

 _

 *http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-federation-ext.html#list-identity-providers_*

 http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-federation-ext.html#list-identity-providers_



 Doug Fish


 David Chadwick _d.w.chadw...@kent.ac.uk_
 mailto:*d.w.chadw...@kent.ac.uk* d.w.chadw...@kent.ac.uk
wrote on 08/01/2015 06:01:48 AM:

  From: David Chadwick _d.w.chadw...@kent.ac.uk_
 mailto:*d.w.chadw...@kent.ac.uk* d.w.chadw...@kent.ac.uk
  To: OpenStack Development Mailing List
 _openstack-dev@lists.openstack.org_
 mailto:*openstack-dev@lists.openstack.org*
openstack-dev@lists.openstack.org
  Date: 08/01/2015 06:05 AM
  Subject: [openstack-dev]  [Keystone] [Horizon] Federated Login
 
  Hi Everyone
 
  I have a student building a GUI for federated login with
Horizon. The
  interface supports both a drop down list of configured IDPs,
and also
  Type Ahead for massive federations with hundreds of IdPs.
Screenshots
  are visible in InVision here
 
  _*https://invis.io/HQ3QN2123_* https://invis.io/HQ3QN2123_
 
  All comments on the design are appreciated. You can make them
directly
  to the screens via 

Re: [openstack-dev] [horizon] Unified interface for all regions

[David Lyle]

It is certainly possible. And a common request. I have it as a priority to
look into during the latter half of Liberty.

There are two factors that prompted the current model. Taking the example
of the instances page (as it exists today).

1) The resulting page would be making 6 API calls to 3 services multiplied
by the number of regions. With the existing Django tooling, that's all done
serially and in deployments of any size rendering that page server side can
be slow to the point of nearly unusable.

2) When the user decides to create and instance, horizon needs to provide a
filtering of endpoints that make logical sense. Allowing tying of compute,
image, block, and network across regions won't make sense for most of
those. So the existing implementation provides the filtering upfront, when
the region is selected.

In Liberty, the goal is to give an overview page that is cross-region. That
would be written
leveraging JavaScript to make the API calls asynchronously. And trying to
act on a particular instance would filter you down to a region. At least
that's my goal for Liberty.

David

On Fri, Jul 17, 2015 at 12:08 PM, Mathieu Gagné mga...@iweb.com wrote:

 Hi,

 As anyone wondered if it could be possible/feasible to have an unified
 interface where all instances (or resources) are listed in one single
 page for all regions available in the catalog?

 What would be the challenges to make it happen? (so you don't have to
 toggle between regions)

 --
 Mathieu

 __
 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 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] [javascript] [qa] [eslint-config-openstack] Nominating Cindy Lu for eslint-config-openstack-core

[David Lyle]

On Thu, Jul 9, 2015 at 1:33 PM, Michael Krotscheck krotsch...@gmail.com
wrote:

 Hey everyone!

 We've been hard at work getting some solid, shared code style rules in
 place for our javascript code, and nobody's been more diligent about this
 than Cindy Lu. Since we've managed to encapsulate our eslint configuration
 into a separate project (much like hacking), I'd like to nominate Cindy Lu
 as a core!

 This will give her the power to tell you whether spaces or tabs are
 better. So be warned :D

 Michael


+1
__
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] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team

[David Lyle]

I'm happy to provide reviews from the Horizon standpoint.

David

On Thu, Jun 4, 2015 at 12:55 PM, Jason Rist jr...@redhat.com wrote:

 On 06/04/2015 11:58 AM, Steven Dake (stdake) wrote:
  Hey folks,
 
  I think it is critical for self-service needs that we have a Horizon
 dashboard to represent Magnum.  I know the entire Magnum team has no
 experience in UI development, but I have found atleast one volunteer
 Bradley Jones to tackle the work.
 
  I am looking for more volunteers to tackle this high impact effort to
 bring Containers to OpenStack either in the existing Magnum core team or as
 new contributors.   If your interested, please chime in on this thread.
 
  As far as “how to get patches approved”, there are two models we can go
 with.
 
  Option #1:
  We add these UI folks to the magnum-core team and trust them not to
 +2/+A Magnum infrastructure code.  This also preserves us as one team with
 one mission.
 
  Option #2:
  We make a new core team magnum-ui-core.  This presents special problems
 if the UI contributor team isn’t large enough to get reviews in.  I suspect
 Option #2 will be difficult to execute.
 
  Cores, please vote on Option #1, or Option #2, and Adrian can make a
 decision based upon the results.
 
  Regards
  -steve
 
 
 
 
 
 __
  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
 

 I am interested in helping as well.  In my experience, #1 works best,
 but I'm not a core, so I'm not sure my wisdom is counted here.

 -J

 --
 Jason E. Rist
 Senior Software Engineer
 OpenStack Infrastructure Integration
 Red Hat, Inc.
 openuc: +1.972.707.6408
 mobile: +1.720.256.3933
 Freenode: jrist
 github/identi.ca: knowncitizen

 __
 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 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] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team

[David Lyle]

In previous conversations, my understanding was the UI implementation had
to be very scheduler dependent to be very effective. Is my understanding
accurate? If so, the complexity grows with the number supported.

David

On Thu, Jun 4, 2015 at 1:59 PM, Bradley Jones (bradjone) bradj...@cisco.com
 wrote:

  It’s difficult to put a quantifiable figure on how big a work item this
 is but I can try to give an overview of the steps required.

  The first step will be to extend the Horizon API to include CRUD
 operations that we need to perform with Magnum. Assuming that there are no
 issues here and API changes/additions are not required at this point, we
 can begin to flesh out how we would like the UI to look. We will aim to
  reduce the amount of Magnum specific UI code that will need to be
 maintained by reusing components from Horizon. This will also speed up the
 development significantly.

  In version 1 of Magnum UI a user should be able to perform all normal
 interactions with Magnum through the UI with no need for interaction with
 the python client.

  Future versions of Magnum UI would include admin specific views and any
 additional Magnum specific UI components we may want to add (maybe some
 visualisations).

  That is a brief overview of my vision for this effort and I believe that
 version 1 should comfortably be achievable this release cycle.

  Thanks,
 Brad Jones

   On 4 Jun 2015, at 19:49, Brad Topol bto...@us.ibm.com wrote:

 How big a work item is this?


 Brad Topol, Ph.D.
 IBM Distinguished Engineer
 OpenStack
 (919) 543-0646
 Internet:  bto...@us.ibm.com
 Assistant: Kendra Witherspoon (919) 254-0680



 From:Thai Q Tran/Silicon Valley/IBM@IBMUS
 To:OpenStack Development Mailing List \(not for usage
 questions\) openstack-dev@lists.openstack.org
 Date:06/04/2015 02:20 PM
 Subject:Re: [openstack-dev] [magnum][horizon] Making a dashboard
 for Magnum - need a vote from the core team
 --



 I am interested but not sure how much time I have this release cycle. I
 can take on a more hands-off approach and help review to make sure that
 magnum-ui is align with future horizon directions.

 -Steven Dake (stdake) std...@cisco.com wrote: -
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 From: Steven Dake (stdake) std...@cisco.com
 Date: 06/04/2015 11:03AM
 Subject: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum -
 need a vote from the core team

 Hey folks,

 I think it is critical for self-service needs that we have a Horizon
 dashboard to represent Magnum.  I know the entire Magnum team has no
 experience in UI development, but I have found atleast one volunteer
 Bradley Jones to tackle the work.

 I am looking for more volunteers to tackle this high impact effort to
 bring Containers to OpenStack either in the existing Magnum core team or as
 new contributors.   If your interested, please chime in on this thread.

 As far as “how to get patches approved”, there are two models we can go
 with.

 Option #1:
 We add these UI folks to the magnum-core team and trust them not to +2/+A
 Magnum infrastructure code.  This also preserves us as one team with one
 mission.

 Option #2:
 We make a new core team magnum-ui-core.  This presents special problems if
 the UI contributor team isn’t large enough to get reviews in.  I suspect
 Option #2 will be difficult to execute.

 Cores, please vote on Option #1, or Option #2, and Adrian can make a
 decision based upon the results.

 Regards
 -steve

 __
 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*
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 __
 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 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 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 Development Mailing List (not for usage questions)
Unsubscribe: 

Re: [openstack-dev] [keystone] [nova] [oslo] oslo.policy requests from the Nova team

[David Lyle]

The Horizon project also uses the nova policy.json file to do role based
access control (RBAC) on the actions a user can perform. If the defaults
are hidden in the code, that makes those checks a lot more difficult to
perform. Horizon will then get to duplicate all the hard coded defaults in
our code base. Fully understanding UI is not everyone's primary concern, I
will just point out that it's a terrible user experience to have 10 actions
listed on an instance that will only fail when actually attempted by making
the API call.

To accomplish this level of RBAC, Horizon has to maintain a sync'd copy of
the nova policy file. The move to centralized policy is something I am very
excited about. But this seems to be a move in the opposite direction.

I think simply documenting the default values in the policy.json file would
be a simpler and more straight-forward approach. I think the defcore
resolution is also a documentation issue.

David



On Tue, Jun 2, 2015 at 10:31 AM, Ihar Hrachyshka ihrac...@redhat.com
wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 On 06/02/2015 06:22 PM, Sean Dague wrote:
  Nova has a very large API, and during the last release cycle a lot
  of work was done to move all the API checking properly into policy,
  and not do admin context checks at the database level. The result
  is a very large policy file -
  https://github.com/openstack/nova/blob/master/etc/nova/policy.json
 
  This provides a couple of challenges. One of which is in recent
  defcore discussions some deployers have been arguing that the
  existence of policy files means that anything you can do with
  policy.json is valid and shouldn't impact trademark usage, because
  the knobs were given. Nova specifically states this is not ok -
  https://github.com/openstack/nova/blob/master/doc/source/devref/policy
 _enforcement.rst#existed-nova-api-being-restricted
 
 
 however, we'd like to go a step further here.
 
  What we'd really like is sane defaults for policy that come from
  code, not from etc files. So that a Nova deploy with an empty
  policy.json is completely valid, and does a reasonable thing.
 
  Policy.json would then be just a set
  ofhttp://docs.openstack.org/developer/oslo.policy/api.html#rule-check
  overrides for existing policy. That would make it a lot more clear
  what was changed from the existing policy.
 
  We'd also really like the policy system to be able to WARN when
  the server starts if the policy was changed in some way that could
  negatively impact compatibility of the system, i.e. if functions
  that we felt were essential were turned off. Because the default
  policy is in code, we could have a view of the old and new world
  and actually warn the Operator that they did a weird thing.
 
  Lastly, we'd actually really like to redo our policy to look more
  like resource urls instead of extension names, as this should be a
  lot more sensible to the administrators, and hopefully make it
  easier to think about policy. Which I think means an aliasing
  facility in oslo.policy to allow a graceful transition for users.
  (This may exist, I don't know).

 If I understand your aliasing need correctly, you may want to use
 RuleChecks:
 http://docs.openstack.org/developer/oslo.policy/api.html#rule-check

 
  I'm happy to write specs here, but mostly wanted to have the
  discussion on the list first to ensure we're all generally good
  with this direction.
 
  -Sean
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2

 iQEcBAEBCAAGBQJVbdp7AAoJEC5aWaUY1u57/x0H/0G2aGlfNVyUdcflC19sner6
 FobWh/ASS/fBLq2SjDGduieu/voCdvK8XKi4rTncSvcwuKGVkgmJ/G3YiO22ZPyn
 kPFWtQjiSadRdmP3WRmMYU4LeHw090Gxq32lBA7knpqon2f/MTHLPZUsnqdmX5R8
 J7zpGEj+nqe9RiWq4kJzwK8niwZTe4FP5+wvc3A+QYNbHNJB5feY5VnGMuUK/4O/
 svsmuNMyAz93GCZL36f+EJoXXQv7+tGtSuImANq505Ae6sXs+Bl7crZul9lkzHo7
 VB/UCbcxa208iw6tiWBh4qP1Y8vBljNjL8ifNbyXj6Y0z3gekEtoUcBQq3T0w5s=
 =lBtm
 -END PGP 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 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] dashboard-app split in horizon

[David Lyle]

On Mon, May 25, 2015 at 5:35 PM, Richard Jones r1chardj0...@gmail.com
wrote:

 As a follow-up to this [in the misguided hope that anyone will actually
 read this conversation with myself ;-)] I've started looking at the
 base.html split. At the summit last week, we agreed to:

 1. move base.html over from the framework to the dashboard, and
 2. move the _conf.html and _scripts.html over as well, since they
 configure the application (dashboard).

 Upon starting the work it occurs to me that all of the other files
 referenced by base.html should also move. So, here's the complete list of
 base.html components and whether they should move over in my opinion:

 - horizon/_custom_meta.html
   Yep, is an empty file in horizon, intended as an extension point in
 dashboard. The empty file (plus an added comment) should move.
   - horizon/_stylesheets.html
   Is just a dummy in horizon anyway, should move.
 - horizon/_conf.html
   Yep, should move.
 - horizon/client_side/_script_loader.html
   Looks to be a framework component not intended for override, so we
 should leave it there.
 - horizon/_custom_head_js.html
   Yep, is an empty file in horizon, intended as an extension point in
 dashboard. Move, with a comment added.
 - horizon/_header.html
   There is a basic implementation in framework but the real (used)
 implementation is in dashboard, so should move.
 - horizon/_messages.html
   This is a framework component, so I think should stay there. I'm not
 sure whether anyone would ever wish to override this. Also the bulk of it
 is probably going to be replaced by the toast implementation anyway...
 hmm...
 - horizon/common/_sidebar.html
   This is an overridable component that I think should move.
 - horizon/common/_page_header.html
   This is an overridable component that I think should move.
 - horizon/_scripts.html
   Yep, should move.

 Thoughts, anyone who has read this far?


 Richard


 On Sat, 23 May 2015 at 11:46 Richard Jones r1chardj0...@gmail.com wrote:

 As part of the ongoing Horizon project code reorganisation, we today
 agreed to clean up the Horizon-the-Framework and OpenStack Dashboard
 separation issue by doing a couple of things:

 1. nuke (the recently-created) horizon dashboard-app by moving the
 angular app over to dashboard and the other contents to appropriate places
 (mostly under the heading of tech-debt :)
 2. move base.html, _conf.html and _scripts.html from horizon over to
 dashboard.

 Thanks to Cindy, Sean and Thai for the pair (er triple?) programming
 keeping me honest today.

 The first step is done and captured in several linked patches based off
 your leaf patch ngReorg - Create dashboard-app 
 https://review.openstack.org/#/c/184597/ (yes, I am nuking the thing
 created by your patch).

 I've not done the second step, but might find some time since I have 6
 hours to waste in LAX tomorrow.


  Richard


 __
 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


This all sounds reasonable to me. We have better extension mechanisms than
in the past so direct reuse of the horizon toolkit part is not necessary
and we have little interest in maintaining the horizon toolkit as a
generally reusable toolkit now. Moving the application pieces into
openstack_dashboard (the actual application) makes sense.

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] No meeting this week

[David Lyle]

There are no items on the agenda and with the summit just completing, I'm
canceling the horizon IRC meeting for May 27.

We will resume next week on June 3 at 20:00 UTC.

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

Re: [openstack-dev] [horizon][keystone][heat] Are AVAILABLE_REGIONS and multi-region service catalog mutually exclusive?

[David Lyle]

On Wed, May 13, 2015 at 3:24 PM, Mathieu Gagné mga...@iweb.com wrote:

 When using AVAILABLE_REGIONS, you get a dropdown at login time to choose
 your region which is in fact your keystone endpoint.

 Once logged in, you get a new dropdown at the top right to switch
 between the keystone endpoints. This means you can configure an
 Horizon installation to login to multiple independent OpenStack
 installations.

 So I don't fully understand what enhancing the multi-region support in
 Keystone would mean. Would you be able to configure Horizon to login to
 multiple independent OpenStack installations?

 Mathieu

 On 2015-05-13 5:06 PM, Geoff Arnold wrote:
  Further digging suggests that we might consider deprecating
  AVAILABLE_REGIONS in Horizon and enhancing the multi-region support in
  Keystone. It wouldn’t take a lot; the main points:
 
* Implement the Regions API discussed back in the Havana time period
  -
 https://etherpad.openstack.org/p/havana-availability-zone-and-region-management
 -
  but with full CRUD
* Enhance the Endpoints API to allow filtering by region
 
  Supporting two different multi region models is problematic if we’re
  serious about things like multi-region Heat.
 
  Thoughts?
 
  Geoff
 
  On May 13, 2015, at 12:01 PM, Geoff Arnold ge...@geoffarnold.com
  mailto:ge...@geoffarnold.com wrote:
 
  I’m looking at implementing dynamically-configured multi-region
  support for service federation, and the prior art on multi-region
  support in Horizon is pretty sketchy. This thread:
  http://lists.openstack.org/pipermail/openstack/2014-January/004372.html
  is the only real discussion I’ve found, and it’s pretty inconclusive.
 
  More precisely, if I configure a single Horizon with AVAILABLE_REGIONS
  pointing at two different Keystones with region names “X” and “Y, and
  each of those Keystones returns a service catalog with multiple
  regions (“A” and “B” for one, “P”, “Q”, and “R” for the other), what’s
  Horizon going to do? Or rather, what’s it expected to do?
 
  Yes, I’m being lazy: I could actually configure this to see what
  happens, but hopefully it was considered during the design.
 
  Geoff
 
  PS I’ve added Heat to the subject, because from a quick read of
 
 https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat
  it looks as if Heat won’t support the AVAILABLE_REGIONS model. That
  seems like an unfortunate disconnect.
 
 
 


Horizon only supports authenticating to one keystone endpoint at a time,
specifically to one of the entries in AVAILABLE_REGIONS as defined in
settings.py. Once you have an authenticated session in Horizon, the region
selection support is merely for filtering between regions registered with
the keystone endpoint you authenticated to, where the list of regions is
determined by parsing the service catalog returned to you with your token.

What's really unclear to me is what you are intending to ask.

AVAILABLE_REGIONS is merely a list of keystone endpoints. They can be
backed by a different IdP per endpoint and thus not share a token store.
Or, they can just be keystone endpoints that are geographically different
but backed by the same IdP, which may or may not share a token store. The
funny thing is, for Horizon, it doesn't matter. They are all supported.
But as one keystone endpoint may not know about another, unless nested,
this has to be done with settings as it's not typically discoverable.

If you are asking about token sharing between keystones which the thread
you linked seems to indicate. Then yes, you can have a synced token store.
But that is an exercise left to the operator.

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] Core Reviewer Update

[David Lyle]

I am pleased to announce the addition of Doug Fish, Rob Cresswell and
Travis Tripp to the Horizon Core Reviewer team.

Doug Fish has been an active reviewer and participant in Horizon for a few
releases now. He represents a strong customer focus and has provided high
quality reviews.

Rob Cresswell has been providing a high number of quality reviews, an
active contributor and an active participant in the community.

Travis Tripp has been contributing to Horizon for the past couple of
releases, an active participant in the community, a critical angularJS
reviewer, and played a significant role in driving the angular based launch
instance work in Kilo.

Thank you all for your contributions and welcome to the team!

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

Re: [openstack-dev] [all] Question for the TC candidates

[David Lyle]

On Thu, Apr 23, 2015 at 10:14 AM, Chris Dent chd...@redhat.com wrote:



 What can and should the TC at large, and you specifically, do to ensure
 quality improves for the developers, end-users and operators of
 OpenStack as a full system, both as a project being developed and a
 product being used?



Thank you for your question.

I think the largest hurdle for quality is a lack of a unified vision and
direction for OpenStack. Without coordinated objectives for releases we
have now 19+ projects driving in scattered directions. This effects quality
on all levels. If we have a documented set of common release goals, we can
better coordinate progress and deliver on the largest pain points for
end-users and deployers. This was my hope for the Cross-Project Sessions at
the summits, but it has not been realized. The TC should drive this
coordination.

A growing ecosystem provides choice for deployers, but it also creates more
questions and uncertainty. We need to provide some guidance to deployers as
to what components are considered ready for production use and which pieces
work complimentary together. The integrated release previously served that
goal. We don't have a concrete plan moving forward to provide this
guidance. To improve quality for deployers we need to make choosing which
services to install simpler and the process to deploy and configure those
services simpler. Additionally for horizontal projects rapid ecosystem
growth creates a very difficult situation where either those horizontal
projects attempt to provide that function for all, or leave it wide open
which creates inconsistencies. This effects quality for end-users and
deployers. The TC needs to stop hand-waiving here and concretely address
the implications of this growth.

Improving the experience for developers means driving our ability to
effectively scale the development process. Progress around excising tests
from the coordinated gate begins to improve how well the gate works for
individual projects. The other central component of this is scaling the
review process. Too much frustration faces developers submitting specs and
patches. The TC needs to push targeting less bureaucracy for developers and
more toward allowing developers to contribute.

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

Re: [openstack-dev] [Horizon] Outreachy call for mentor

[David Lyle]

I added my name to an openstack wiki page for this express purpose some
time ago, apparently the wrong one, which I can find no reference to now.

That said, I am willing to be a mentor for a Horizon focused intern, if
inability to find the correct wiki pages isn't a limiting factor.

David

On Wed, Apr 22, 2015 at 6:31 PM, Victoria Martínez de la Cruz 
victo...@vmartinezdelacruz.com wrote:

 Hi all,

 Horizon folks, we have a really good Outreachy candidate interested in
 working with you. The internship is from May 25th to August 25th, and
 interns are expected to work full time on their projects. Being a mentor
 should not be time consuming, we expect interns to be able to do their
 tasks independently and to solve the blockers they might find with the help
 of the community. I will be mentoring an applicant this round and, if time
 is a problem, I offer to help with this applicant as well.

 The announcement of accepted participants is soon, so this is a real last
 minute call.

 Outreachy is an internship targeted to anyone who identifies as a woman
 and OpenStack has been participating on it for about two years now. We had
 really good participants and many important features had been added as part
 of this program. For more details on OpenStack participation on Outreachy,
 check out the OpenStack Outreachy wiki page [0] and the Outreachy official
 site [1].

 If you decide you want to mentor, please reach me and I'll guide you
 through the process.

 Please, let me know if you have any doubt or concern.

 Thanks all,

 Victoria

 [0] https://wiki.openstack.org/wiki/Outreachy
 [1] https://wiki.gnome.org/Outreachy

 __
 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 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] TC Candidacy

[David Lyle]

I'm announcing my candidacy for the Technical Committee elections.

I have been contributing to OpenStack since Grizzly primarily in Horizon. I
have also had the privilege to serve as Horizon PTL since Icehouse.

Why I'm running:

I believe there should be broader representation on the TC. We are growing
the OpenStack ecosystem. Let's make sure horizontal teams and diverse parts
of the ecosystem are represented more directly. I understand concerns of
scaling were the reason for moving from the TC made up of all PTLs (I
question that assertion), but the sacrifice so far has been diversity. I
feel current TC members are exceptionally capable and take a broad
viewpoint, but there are limits of how well that works. Let's represent
broader swaths of our ecosystem in the technical leadership.

I think growing the OpenStack ecosystem is fantastic. As a developer and
the PTL of a project that tries to span across most of that ecosystem it
also worries me a bit too. I think we need to focus on how the newer and
older parts of our ecosystem work together. How do we manage all the
horizontal needs this introduces without going to the extremes of just
scaling existing horizontal efforts because that won't work. And pushing
all horizontal work on the individual projects is not appropriate because
that yields chaos.

Finally, I believe the TC needs to be more active in guiding overall
direction of OpenStack and problem resolution. I'm not suggesting a
dictatorship of course. But let's set a direction, overall release goals
for OpenStack and help enable and drive them.

I'm really proud to be a part of the OpenStack developer community, but I
think we're facing some real challenges. We need to address some primary
issues or this community will struggle to remain the vibrant, supportive
place it is now.

Thank you,
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] [all] django_openstack_auth potential release

[David Lyle]

django_openstack_auth is a library solely consumed by Horizon in OpenStack.
We've run into a potential requirements.txt issue.

Horizon recently added support for Django 1.7 (1.8 released in the last
week, but let's ignore that). The reasoning was that Django 1.6 the
previous cap is no longer supported by Django at all, even for security
fixes. After adding support, the global-requirements were updated [1] to
support an upper end cap of Django 1.7. All is good. Or maybe not.

So the global requirement and horizon repos now match:

Django=1.4.2,1.8

The current released version of django_openstack_auth is 1.1.9. And the
requirements.txt for that version states

Django=1.4.2,1.7

The worry that arose is what dependency problems does this raise for
deployers and distros? The 1.1.9 released version of django_openstack_auth
code actually supports Django 1.7 even though the requirements don't
include that version. But dependency negotiation may result in only 1.6
being used.

So we have a couple of options. First, leave django_openstack_auth at 1.1.9
and let deployers and distros rationalize which version of Django they want
to use and negotiate the dependency issues independently. Or second,
release a new version of django_openstack_auth and determine if we want to
fix the version django_openstack_auth in global-requirements.txt or leave
the upper cap unbound.

Given the late stage of the release I'm reluctant to release, but would
like to better understand the downstream implications of not doing so.

David

[1] https://review.openstack.org/#/c/155353/
__
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

[David Lyle]

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

Re: [openstack-dev] [Sahara][Horizon] Can't open Data Processing panel after update sahara horizon

[David Lyle]

If you are not seeing the horizon panels for Sahara, I believe you are
seeing https://bugs.launchpad.net/horizon/+bug/1429987

The fix for that was merged on March 9
https://review.openstack.org/#/c/162736/

There are several bugs and fixes around the switch of the endpoint type
from data_processing to data-processing. Seems like you may have got caught
in the middle of the change. All should work now.

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

Re: [openstack-dev] [Horizon] [swift] dependency on non-standardized, private APIs

[David Lyle]

I agree that Horizon should not be requiring optional headers. Changing
status of bug.

On Tue, Mar 3, 2015 at 5:51 PM, Jay Pipes jaypi...@gmail.com wrote:

 Added [swift] to topic.

 On 03/03/2015 07:41 AM, Matthew Farina wrote:

 Radoslaw,

 Unfortunately the documentation for OpenStack has some holes. What you
 are calling a private API may be something missed in the documentation.
 Is there a documentation bug on the issue? If not one should be created.


 There is no indication that the X-Timestamp or X-Object-Meta-Mtime HTTP
 headers are part of the public Swift API:

 http://developer.openstack.org/api-ref-objectstorage-v1.html

 I don't believe this is a bug in the Swift API documentation, either. John
 Dickinson (cc'd) mentioned that the X-Timestamp HTTP header is required for
 the Swift implementation of container replication (John, please do correct
 me if wrong on that).

 But that is the private implementation and not part of the public API.

  In practice OpenStack isn't a specification and implementation. The
 documentation has enough missing information you can't treat it this
 way. If you want to contribute to improving the documentation I'm sure
 the documentation team would appreciate it. The last time I looked there
 were a number of undocumented public swift API details.


 The bug here is not in the documentation. The bug is that Horizon is coded
 to rely on HTTP headers that are not in the Swift API. Horizon should be
 fixed to use DICT.get('X-Timestamp') instead of doing
 DICT['X-Timestamp'] in its view pages for container details. There are
 already patches up that the Horizon developers have, IMO erroneously,
 rejected stating this is a problem in Ceph RadosGW for not properly
 following the Swift API).

 Best,
 -jay

  Best of luck,
 Matt Farina

 On Tue, Mar 3, 2015 at 9:59 AM, Radoslaw Zarzynski
 rzarzyn...@mirantis.com mailto:rzarzyn...@mirantis.com wrote:

 Guys,

 I would like discuss a problem which can be seen in Horizon: breaking
 the boundaries of public, well-specified Object Storage API in favour
 of utilizing a Swift-specific extensions. Ticket #1297173 [1] may
 serve
 as a good example of such violation. It is about relying on
 non-standard (in the terms of OpenStack Object Storage API v1) and
 undocumented HTTP header provided by Swift. In order to make
 Ceph RADOS Gateway work correctly with Horizon, developers had to
 inspect sources of Swift and implement the same behaviour.

  From my perspective, that practise breaks the the mission of
 OpenStack
 which is much more than delivering yet another IaaS/PaaS
 implementation.
 I think its main goal is to provide a universal set of APIs covering
 all
 functional areas relevant for cloud computing, and to place that set
 of APIs in front as many implementations as possible. Having an open
 source reference implementation of a particular API is required to
 prove
 its viability, but is secondary to having an open and documented API.

 I have full understanding that situations where the public OpenStack
 interfaces are insufficient to get the work done might exist.
 However, introduction of dependency on implementation-specific feature
 (especially without giving the users a choice via e.g. some
 configuration option) is not the proper way to deal with the problem.
  From my point of view, such cases should be handled with adoption of
 new, carefully designed and documented version of the given API.

 In any case I think that Horizon, at least basic functionality, should
 work with any storage which provides Object Storage API.
 That being said, I'm willing to contribute such patches, if we decide
 to go that way.

 Best regards,
 Radoslaw Zarzynski

 [1] https://bugs.launchpad.net/horizon/+bug/1297173

 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 
 __
 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 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 Development Mailing List (not for usage questions)
Unsubscribe: 

Re: [openstack-dev] [horizon]

[David Lyle]

Feedback on security is of the utmost concern. However, due to the short
time left in Kilo, we are going to hold the sprint beginning Wed at 20:00
UTC--23:30 UTC. All code will still go through the standard review process.

On Wednesday, we will judge the demand/usefulness of a repeat on Thursday.

The sprint will be held in #openstack-sprint

David

On Mon, Feb 16, 2015 at 3:46 PM, Gabriel Hurley gabriel.hur...@nebula.com
wrote:

  FWIW, this week conflicts with the OpenStack Security Group midcycle
 meetup. I’ll be attending that, so I thought I’d point it out in case it
 affects anyone else.



 Having some cross-pollination between Security and Horizon on this
 significant shift in the codebase and architecture would probably be
 advisable.



 -  Gabriel



 *From:* David Lyle [mailto:dkly...@gmail.com]
 *Sent:* Monday, February 16, 2015 10:19 AM
 *To:* OpenStack Development Mailing List
 *Subject:* [openstack-dev] [horizon]



 A couple of high priority items for Horizon's Kilo release could use some
 targeted attention to drive progress forward. These items are related to
 angularJS based UX improvements, especially Launch Instance and the
 conversion of the Identity Views.



 These efforts are suffering from a few issues, education, consensus on
 direction, working through blockers and drawn out dev and review cycles. In
 order to help insure these high priority issues have the best possible
 chance to land in Kilo, I have proposed a virtual sprint to happen this
 week. I created an etherpad [1] with proposed dates and times. Anyone who
 is interested is welcome to participate, please register your intent in the
 etherpad and availability.



 David



 [1] https://etherpad.openstack.org/p/horizon-kilo-virtual-sprint

 __
 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 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]

[David Lyle]

A couple of high priority items for Horizon's Kilo release could use some
targeted attention to drive progress forward. These items are related to
angularJS based UX improvements, especially Launch Instance and the
conversion of the Identity Views.

These efforts are suffering from a few issues, education, consensus on
direction, working through blockers and drawn out dev and review cycles. In
order to help insure these high priority issues have the best possible
chance to land in Kilo, I have proposed a virtual sprint to happen this
week. I created an etherpad [1] with proposed dates and times. Anyone who
is interested is welcome to participate, please register your intent in the
etherpad and availability.

David

[1] https://etherpad.openstack.org/p/horizon-kilo-virtual-sprint
__
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] Stepping down as a Horizon core reviewer

[David Lyle]

On Fri, Feb 13, 2015 at 6:14 AM, Thierry Carrez thie...@openstack.org
wrote:

 Julie Pichon wrote:
  In the spirit of stepping down considerately [1], I'd like to ask to be
  removed from the core and drivers team for Horizon and associated
  projects. I'm embarking on some fun adventures far far away and won't
  have any time to spare for OpenStack for a while.

 Aw. Sad to hear that. Please come back to us when said adventures start
 to become unfun!

 --
 Thierry Carrez (ttx)


Thank you Julie for all of your contributions. You've been an integral part
of the Horizon team. We will miss you.

We'll always have room for you, if you ever want to take us back.

Best wishes on your next adventures.

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

Re: [openstack-dev] [horizon] packaging problem production build question

[David Lyle]

Bower is not for use in production environments. There will continue to be
two environment setup procedures, as there are today. For production,
deploy Horizon and its dependencies via system packages. For development
and testing leverage bower to pull the javascript resources, much as pip is
used today and continue to use pip for python dependencies.

For those running CI environments, remote access will likely be required
for bower to work. Although, it seems something like private-bower [1]
could be utilized to leverage a local mirror where access or network
performance are issues.

David

[1] https://www.npmjs.com/package/private-bower


On Thu, Jan 8, 2015 at 2:28 PM, Matthew Farina m...@mattfarina.com wrote:

 I've been going over the packaging problem in an effort to see how we can
 move to something better. Given the current proposal around bower I'm still
 left with a production deployment question.

 For a build environment sitting in isolation, unable to download from the
 Internet including Github, how would they be able to get all the bower
 controlled packages to create a system horizon package (e.g., rpm or deb)?

 These build environments currently use mirrors and controlled packages.
 For example, someone might have a pypi mirror with copies of the xstatic
 packages. This is tightly controlled. If bower is managing packages where,
 in theory, would it get them from for an environment like this?

 I may have missed something. If this has already been answered please
 excuse me and point me in the right direction.

 Thanks,
 Matt

 ___
 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] Moving _conf and _scripts to dashboard

[David Lyle]

Not entirely sure why they both exist either.

So by move, you meant override (nuance). That's different and I have no
issue with that.

I'm also fine with attempting to consolidate _conf and _scripts.

David

On Thu, Dec 11, 2014 at 1:22 PM, Thai Q Tran tqt...@us.ibm.com wrote:


 It would not create a circular dependency, dashboard would depend on
 horizon - not the latter.
 Scripts that are library specific will live in horizon while scripts that
 are panel specific will live in dashboard.
 Let me draw a more concrete example.

 In Horizon
 We know that _script and _conf are included in the base.html
 We create a _script and _conf placeholder file for project overrides
 (similar to _stylesheets and _header)
 In Dashboard
 We create a _script and _conf file with today's content
 It overrides the _script and _conf file in horizon
 Now we can include panel specific scripts without causing circular
 dependency.

 In fact, I would like to go further and suggest that _script and _conf be
 combine into a single file.
 Not sure why we need two places to include scripts.


 -David Lyle dkly...@gmail.com wrote: -
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 From: David Lyle dkly...@gmail.com
 Date: 12/11/2014 09:23AM
 Subject: Re: [openstack-dev] [Horizon] Moving _conf and _scripts to
 dashboard


 I'm probably not understanding the nuance of the question but moving the
 _scripts.html file to openstack_dashboard creates some circular
 dependencies, does it not? templates/base.html in the horizon side of the
 repo includes _scripts.html and insures that the javascript needed by the
 existing horizon framework is present.

 _conf.html seems like a better candidate for moving as it's more closely
 tied to the application code.

 David


 On Wed, Dec 10, 2014 at 7:20 PM, Thai Q Tran tqt...@us.ibm.com wrote:

 Sorry for duplicate mail, forgot the subject.

 -Thai Q Tran/Silicon Valley/IBM wrote: -
 To: OpenStack Development Mailing List \(not for usage questions\) 
 openstack-dev@lists.openstack.org
 From: Thai Q Tran/Silicon Valley/IBM
 Date: 12/10/2014 03:37PM
 Subject: Moving _conf and _scripts to dashboard

 The way we are structuring our javascripts today is complicated. All of
 our static javascripts reside in /horizon/static and are imported through
 _conf.html and _scripts.html. Notice that there are already some panel
 specific javascripts like: horizon.images.js, horizon.instances.js,
 horizon.users.js. They do not belong in horizon. They belong in
 openstack_dashboard because they are specific to a panel.

 Why am I raising this issue now? In Angular, we need controllers written
 in javascript for each panel. As we angularize more and more panels, we
 need to store them in a way that make sense. To me, it make sense for us to
 move _conf and _scripts to openstack_dashboard. Or if this is not possible,
 then provide a mechanism to override them in openstack_dashboard.

 Thoughts?
 Thai



 ___
 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

 ___
 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] Proposal to add IPMI meters from Ceilometer in Horizon

[David Lyle]

Please submit the blueprint and set the target for the milestone you are
targeting. That will add it the the blueprint review process for Horizon.

Seems like a minor change, so at this time, I don't foresee any issues with
approving it.

David

On Thu, Dec 11, 2014 at 12:34 AM, Xin, Xiaohui xiaohui@intel.com
wrote:

  Hi,

 In Juno Release, the IPMI meters in Ceilometer have been implemented.

 We know that most of the meters implemented in Ceilometer can be observed
 in Horizon side.

 User admin can use the “Admin” dashboard - “System” Panel Group -
 “Resource Usage” Panel to show the “Resources Usage Overview”.

 There are a lot of Ceilometer Metrics there now, each metric can be
 metered.

 Since IPMI meters have already been there, we’d like to add such Metric
 items for it in Horizon to get metered information.



 Is there anyone who oppose this proposal? If not, we’d like to add a
 blueprint in Horizon for it soon.



 Thanks

 Xiaohui

 ___
 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] Moving _conf and _scripts to dashboard

[David Lyle]

I'm probably not understanding the nuance of the question but moving the
_scripts.html file to openstack_dashboard creates some circular
dependencies, does it not? templates/base.html in the horizon side of the
repo includes _scripts.html and insures that the javascript needed by the
existing horizon framework is present.

_conf.html seems like a better candidate for moving as it's more closely
tied to the application code.

David


On Wed, Dec 10, 2014 at 7:20 PM, Thai Q Tran tqt...@us.ibm.com wrote:

 Sorry for duplicate mail, forgot the subject.

 -Thai Q Tran/Silicon Valley/IBM wrote: -
 To: OpenStack Development Mailing List \(not for usage questions\) 
 openstack-dev@lists.openstack.org
 From: Thai Q Tran/Silicon Valley/IBM
 Date: 12/10/2014 03:37PM
 Subject: Moving _conf and _scripts to dashboard

 The way we are structuring our javascripts today is complicated. All of
 our static javascripts reside in /horizon/static and are imported through
 _conf.html and _scripts.html. Notice that there are already some panel
 specific javascripts like: horizon.images.js, horizon.instances.js,
 horizon.users.js. They do not belong in horizon. They belong in
 openstack_dashboard because they are specific to a panel.

 Why am I raising this issue now? In Angular, we need controllers written
 in javascript for each panel. As we angularize more and more panels, we
 need to store them in a way that make sense. To me, it make sense for us to
 move _conf and _scripts to openstack_dashboard. Or if this is not possible,
 then provide a mechanism to override them in openstack_dashboard.

 Thoughts?
 Thai



 ___
 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] proposal: alternating weekly meeting time [doodle poll created]

[David Lyle]

Thanks Richard for setting up the poll.

Today, we finalized on the new meeting times. The decision is to meet at
alternating times, 2000 UTC and 1200 UTC, on Weds. The meetings will remain
in openstack-meeting-3.

A schedule of upcoming meeting times has been added to
https://wiki.openstack.org/wiki/Meetings/Horizon

The next Horizon meeting will be on Wed Dec 3 at 2000 UTC in
openstack-meeting-3. I'll also send out a reminder.

David

On Tue, Nov 25, 2014 at 2:23 PM, Richard Jones r1chardj0...@gmail.com
wrote:

 Thanks!


 On Tue Nov 25 2014 at 3:15:49 AM Yves-Gwenaël Bourhis 
 yves-gwenael.bour...@cloudwatt.com wrote:



 Le 24/11/2014 04:20, Richard Jones a écrit :
  Thanks everyone, I've closed the poll. I'm sorry to say that there's no
  combination of two timeslots which allows everyone to attend a meeting.
  Of the 25 respondents, the best we can do is cater for 24 of you.
 
  Optimising for the maximum number of attendees, the potential meeting
  times are 2000 UTC Tuesday and 1000 UTC on one of Monday, Wednesday or
  Friday. In all three cases the only person who has indicated they cannot
  attend is Lifeless.
 
  Unfortunately, David has indicated that he can't be present at the
  Tuesday 2000 UTC slot. Optimising for him as a required attendee for
  both meetings means we lose an additional attendee, and gives us the
  Wednesday 2000 UTC slot and a few options:
 
  - Monday, Wednesday and Thursday at 1200 UTC (Lifeless and ygbo miss)

 1200 UTC is perfect for me.
 The doodle was proposing 1200 UTC to 1400 UTC and in the 2 hours
 bandwidth I can not be sure to be there. but if it's 1200 on the spot
 I can for sure :-)
 Since I couldn't precise this on the doodle I didn't select this slot. A
 one hour bandwidth would have allowed more precision but I understand
 you concern that the doodle would have been to long to scroll.

 --
 Yves-Gwenaël Bourhis

 ___
 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


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Horizon]

[David Lyle]

I am pleased to nominate Thai Tran and Cindy Lu to horizon-core.

Both Thai and Cindy have been contributing significant numbers of high
quality reviews during Juno and Kilo cycles. They are consistently among
the top non-core reviewers. They are also responsible for a significant
number of patches to Horizon. Both have a strong understanding of the
Horizon code base and the direction of the project.

Horizon core team members please vote +1 or -1 to the nominations either in
reply or by private communication. Voting will close on Friday unless I
hear from everyone before that.

Thanks,
David
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] Changing Host marked for maintenance BP target milestone

[David Lyle]

The first review was actually the implementation for a separate blueprint.
https://blueprints.launchpad.net/horizon/+spec/evacuate-host

The content for this blueprint should follow the horizon blueprint process
for Kilo. See: https://blueprints.launchpad.net/horizon/+spec/template

Once the blueprint contains the appropriate information, I'd be happy to
consider it for Kilo.

David

On Mon, Nov 17, 2014 at 8:46 AM, Fic, Bartosz bartosz@intel.com wrote:

  Hi guys,

 I've start working on this BP:
 https://blueprints.launchpad.net/horizon/+spec/mark-host-down-for-maintenance

 One of the reviews from this BP has been already merged (in juno).

 Another one has to be finalized.



 So I have a question: is it possible to change milestone target for this
 BP feature into Kilo release?



 - Bart

 ___
 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

[openstack-dev] [Horizon] [Devstack]

[David Lyle]

In order to help ease an ongoing struggle with session size limit issues,
Horizon is planning on changing the default session store from signed
cookie to simple server side session storage using sqlite. The size limit
for cookie based sessions is 4K and when this value is overrun, the result
is truncation of the session data in the cookie or a complete lack of
session data updates.

Operators will have the flexibility to replace the sqlite backend with the
DB of their choice, or memcached.

We gain: support for non-trivial service catalogs, support for higher
number of regions, space for holding multiple tokens (domain scoped and
project scoped), better support for PKI and PKIZ tokens, and frees up
cookie space for user preferences.

The drawbacks are we lose HA as a default, a slightly more complicated
configuration. Once the cookie size limit is removed, cookie based storage
would no longer be supported.

Additionally, this will require a few config changes to devstack to
configure the session store DB and clean it up periodically.

Concerns?

David
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] TC Candidacy

[David Lyle]

I would like to announce my candidacy for the Technical Committee.

I have been working on OpenStack since the beginning of the Grizzly cycle.
I started working on OpenStack as part of HP's Public Cloud effort. I spent
two years working to make Horizon work in that scale of environment and
making Horizon the user facing interface of HP's Public Cloud. I have
served as a Horizon core reviewer since the Havana cycle and I am starting
my third release as Horizon PTL. Currently, I am employed by Intel in their
Open Source Technology Center.

I have been a regular observer of the Technical Committee during my time as
PTL. The role of the TC is large and difficult. I appreciate the efforts of
all those that have served during that time and I would like to thank them
for their dedication. One takeaway from those observations in the very
heavy representation on the TC by infrastructure and core services. I think
the TC would be benefit from more representation higher up the stack. I
think Heat, Horizon, Solum, TripleO have a unique perspective into
cross-project issues and the TC would benefit from such representation.

In my opinion, the fundamental problems the TC needs to address in the Kilo
cycle are handling growth and cross-project alignment. I'll be honest, I
don't have a master plan to address these, but I think I'm well equipped
and motivated to help develop that plan with other members of the TC.

Thanks for your consideration,
David Lyle


Topic: OpenStack Mission: How do you feel the technical community is doing
in meeting the OpenStack Mission?


To produce the ubiquitous OpenSource Cloud Computing platform that will
meet the needs of public and private clouds regardless of size, by being
simple to implement and massively scalable.

I think this is a very broad mission. Breadth is not a problem, but there
are a few implications in here. One OpenStack needs to be inclusive, to
accomplish ubiquity we need to strive to allow deployers to meet their
widely varied needs. So we need to support a large ecosystem. The ecosystem
around OpenStack is certainly large, but there is a fairly sharp dichotomy
between OpenStack and not OpenStack, recognizing larger parts of the
ecosystem is important for ecosystem health. As to public vs private and
massively scalable aspects, I think we have room for growth. Running a
public cloud on OpenStack requires not insignificant changes, and OpenStack
has room for improvement on the scalability front. We need greater feedback
from the very large deployers to make sure we meet those scalability needs.

Topic: Technical Committee Mission: How do you feel the technical committee
is doing in meeting the technical committee mission?


The Technical Committee (TC) is tasked with providing the technical
leadership for OpenStack as a whole (all official programs, as defined
below). It enforces OpenStack ideals (Openness, Transparency, Commonality,
Integration, Quality...), decides on issues affecting multiple programs,
forms an ultimate appeals board for technical decisions, and generally has
oversight over all the OpenStack project.

The technical committee has spent much of the last cycle acting as gate
keeper. I would like to see it take a larger role in overall architectural
direction in OpenStack. I believe one of the greatest challenges we face is
coherency of vision and direction. I think this should be the province of
the technical committee to act as an arbitrar and architectural board. I
don't hold that overall technical direction is to be dictated by the TC,
rather the TC merely helps unify that direction and insures consistency.
Obviously this is a herculean task, but I believe OpenStack needs more
clearness in direction.

Topic: Contributor Motivation: How would you characterize the various
facets of contributor motivation?


Contributors are motivated to contribute for various reasons. People
contribute for personal interest, corporate interest, academic interest,
and any mix of all three. Corporate interest covers a lot, from users to
operators, vendors to consumers. Many ideas from our great community of
diverse contributors helps drive us forward and keeps us honest and
progressing.

At the end of the day, OpenStack is cloud software that should be usable.
We do need to temper the wouldn't it be neat if, with how will this work in
real world application ranging from small test clouds to large public
clouds. Services should strive to work across this spectrum. The difficulty
is focusing these disparate motivations into a cohesive effort.

Topic: Rate of Growth

[openstack-dev] [Horizon] PTL Candidacy

[David Lyle]

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] [all] Deprecating exceptions

[David Lyle]

The larger problem here is that this breaks running Horizon unit tests on
all existing installs of Horizon including Havana, Icehouse and Juno if
those installations update to the newest python-ceilometerclient. I'm not
sure how to handle that type of deprecation other than forcing all existing
installs to pull a new patch to be able to continue development on Horizon.

David

On Mon, Sep 22, 2014 at 9:32 AM, Sean Dague s...@dague.net wrote:

 On 09/22/2014 11:24 AM, Ihar Hrachyshka wrote:
  On 22/09/14 17:07, Radomir Dopieralski wrote:
  Horizon's tests were recently broken by a change in the Ceilometer
  client that removed a deprecated exception. The exception was
  deprecated for a while already, but as it often is, nobody did the
  work of removing all references to it from Horizon before it was
  too late. Sure, in theory we should all be reading the release
  notes of all versions of all dependencies and acting upon things
  like this. In practice, if there is no warning generated in the
  unit tests, nobody is going to do anything about it.
 
  So I sat down and started thinking about how to best generate a
  warning when someone is trying to catch a deprecated exception. I
  came up with this code:
 
  http://paste.openstack.org/show/114170/
 
  It's not pretty -- it is based on the fact that the `except`
  statement has to do a subclass check on the exceptions it is
  catching. It requires a metaclass and a class decorator to work,
  and it uses a global variable. I'm sure it would be possible to do
  it in a little bit cleaner way. But at least it gives us the
  warning (sure, only if an exception is actually being thrown, but
  that's test coverage problem).
 
  I propose to do exception deprecating in this way in the future.
 
 
  Aren't clients supposed to be backwards compatible? Isn't it the exact
  reason why we don't maintain stable branches for client modules?
 
  So, another reason to actually start maintaining those stable branches
  for clients. We already do it in RDO (Red Hat backed Openstack
  distribution) anyway.

 I think the real question is how much warning was given on the removal
 of the exception. Was there a release out for 6 months with the
 deprecation? That's about our normal time for delete threshold.
 Honestly, I have no idea.

 If ceilometer client did the right thing and gave enough deprecation
 time before the remove, it's an issue about why horizon didn't respond
 to the deprecation sooner.

 -Sean

 --
 Sean Dague
 http://dague.net


 ___
 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