Re: [openstack-dev] [Horizon][searchlight] Sharing resource type implementations

[Richard Jones]

I've completed this work. The two patches to migrate the code over and
one additional bug fix are:

Horizon: Copy os-nova-servers from searchlight ui
  https://review.openstack.org/#/c/444095/

Searchlight UI: Remove os-nova-servers resource type
  https://review.openstack.org/#/c/450067/   (depends-on 444095)

Searchlight UI: Resource detail views have moved
  https://review.openstack.org/#/c/450068/

I have tested Searchlight UI and it doesn't break with the additional
resource type registered, however:

1. There is duplication of actions in the action dropdown for instances rows.
2. The details page link is broken, which is addressed in the separate
bug patch above.
3. The Horizon-side instances list is confused when an unmodified
Searchlight UI is installed - table columns are also duplicated.


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

Re: [openstack-dev] [Horizon][searchlight] Sharing resource type implementations

[Richard Jones]

Hi folks,

I've completed the work in Horizon space
(https://review.openstack.org/#/c/444095/) but I've just tried to run
up a devstack with searchlight enabled to test the searchlight-ui side
and put together a patch there, but the devstack plugin for
searchlight appears to be broken at the moment (I think because of bug
https://bugs.launchpad.net/searchlight/+bug/1648255).


 Richard


On 14 March 2017 at 09:43, Richard Jones <r1chardj0...@gmail.com> wrote:
> I'll definitely be looking at getting a searchlight-ui patch up for
> the mirror side of my Horizon patch.
>
> Double registration largely depends on which particular aspect of the
> resource type is being looked at. Most of the resource type
> registration will just be replaced (with identical information) but
> the kicker will be table columns and actions which are added by append
> (via extensible service), so they'll all be duplicated if both
> registrations run. So ideally both searchlight-ui and Horizon would be
> updated at the same time.
>
>
>  Richard
>
> On 11 March 2017 at 04:34, Tripp, Travis S <travis.tr...@hpe.com> wrote:
>> Hi Richard,
>>
>> I’m headed out for vacation so won’t be able to look through it until I get 
>> back.  However, can you also please get an install of searchlight-ui running 
>> so that you can see if anything breaks?  I know you don’t typically use 
>> devstack, but the searchlight devstack plugin installs searchlight UI. [0]
>>
>> The one thing I’m not sure about is how the resource registry handles 
>> potential double registrations.  So, if the resource is registered both code 
>> bases, I don’t know what would get loaded.
>>
>> https://review.openstack.org/#/c/444095/2/openstack_dashboard/static/app/core/instances/instances.module.js
>> https://github.com/openstack/searchlight-ui/blob/master/searchlight_ui/static/resources/os-nova-servers/os-nova-servers.module.js#L57
>>
>> [0] https://github.com/openstack/searchlight/tree/master/devstack
>>
>> Thanks,
>> Travis
>>
>> On 3/9/17, 10:58 PM, "Richard Jones" <r1chardj0...@gmail.com> wrote:
>>
>> Thanks, Steve!
>>
>> I've put together an initial patch
>> https://review.openstack.org/#/c/444095/ which pulls in the
>> os-nova-servers module and a little extra to make it work in Horizon's
>> codebase. I've tried to make minimal edits to the actual code -
>> predominantly just editing module names. I've tested it and it mostly
>> works on Horizon's side \o/
>>
>>
>>  Richard
>>
>> On 10 March 2017 at 14:40, McLellan, Steven <steve.mclel...@hpe.com> 
>> wrote:
>> > My expertise in this area is deeply suspect but as long as we maintain 
>> the
>> > mapping from the resource type names that searchlight uses 
>> (os-nova-servers)
>> > to the modules we'll be OK. If you or Rob put a patch up against 
>> horizon I
>> > (or a willing victim/volunteer) can test a searchlight-ui patch 
>> against it.
>> >
>> >
>> >  Original message 
>> > From: Richard Jones <r1chardj0...@gmail.com>
>> > Date: 3/9/17 21:13 (GMT-06:00)
>> > To: "OpenStack Development Mailing List (not for usage questions)"
>> > <openstack-dev@lists.openstack.org>
>> > Subject: Re: [openstack-dev] [Horizon][searchlight] Sharing resource 
>> type
>> > implementations
>> >
>> > Hey folks,
>> >
>> > Another potential issue is that the searchlight module structure and
>> > Horizon's module structure are different in a couple of respects. I
>> > could just retain the module structure from searchlight
>> > ('resources.os-nova-servers') or, preferably, I could rename those
>> > modules to match the Horizon structure more closely
>> > ('horizon.app.resources.os-nova-servers') or more strictly
>> > ('horizon.app.core.instances').
>> >
>> > As far as I can tell none of the module names are referenced directly
>> > outside of the module (apart from resources.module.js of course) so
>> > moving the modules shouldn't affect any existing usage in searchlight
>> > ui.
>> >
>> > We could bikeshed this for ages, so if I could just get Rob and Steve
>> > to wrestle over it or something, that'd be good. Rob's pretty scrappy.
>> >
>> >
>> >   Richard
>> >
>> >
>

Re: [openstack-dev] [Horizon][searchlight] Sharing resource type implementations

[Richard Jones]

I'll definitely be looking at getting a searchlight-ui patch up for
the mirror side of my Horizon patch.

Double registration largely depends on which particular aspect of the
resource type is being looked at. Most of the resource type
registration will just be replaced (with identical information) but
the kicker will be table columns and actions which are added by append
(via extensible service), so they'll all be duplicated if both
registrations run. So ideally both searchlight-ui and Horizon would be
updated at the same time.


 Richard

On 11 March 2017 at 04:34, Tripp, Travis S <travis.tr...@hpe.com> wrote:
> Hi Richard,
>
> I’m headed out for vacation so won’t be able to look through it until I get 
> back.  However, can you also please get an install of searchlight-ui running 
> so that you can see if anything breaks?  I know you don’t typically use 
> devstack, but the searchlight devstack plugin installs searchlight UI. [0]
>
> The one thing I’m not sure about is how the resource registry handles 
> potential double registrations.  So, if the resource is registered both code 
> bases, I don’t know what would get loaded.
>
> https://review.openstack.org/#/c/444095/2/openstack_dashboard/static/app/core/instances/instances.module.js
> https://github.com/openstack/searchlight-ui/blob/master/searchlight_ui/static/resources/os-nova-servers/os-nova-servers.module.js#L57
>
> [0] https://github.com/openstack/searchlight/tree/master/devstack
>
> Thanks,
> Travis
>
> On 3/9/17, 10:58 PM, "Richard Jones" <r1chardj0...@gmail.com> wrote:
>
> Thanks, Steve!
>
> I've put together an initial patch
> https://review.openstack.org/#/c/444095/ which pulls in the
> os-nova-servers module and a little extra to make it work in Horizon's
> codebase. I've tried to make minimal edits to the actual code -
> predominantly just editing module names. I've tested it and it mostly
> works on Horizon's side \o/
>
>
>  Richard
>
> On 10 March 2017 at 14:40, McLellan, Steven <steve.mclel...@hpe.com> 
> wrote:
> > My expertise in this area is deeply suspect but as long as we maintain 
> the
> > mapping from the resource type names that searchlight uses 
> (os-nova-servers)
> > to the modules we'll be OK. If you or Rob put a patch up against 
> horizon I
>     > (or a willing victim/volunteer) can test a searchlight-ui patch against 
> it.
> >
> >
> >  Original message 
> > From: Richard Jones <r1chardj0...@gmail.com>
> > Date: 3/9/17 21:13 (GMT-06:00)
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > <openstack-dev@lists.openstack.org>
> > Subject: Re: [openstack-dev] [Horizon][searchlight] Sharing resource 
> type
> > implementations
> >
> > Hey folks,
> >
> > Another potential issue is that the searchlight module structure and
> > Horizon's module structure are different in a couple of respects. I
> > could just retain the module structure from searchlight
> > ('resources.os-nova-servers') or, preferably, I could rename those
> > modules to match the Horizon structure more closely
> > ('horizon.app.resources.os-nova-servers') or more strictly
> > ('horizon.app.core.instances').
> >
> > As far as I can tell none of the module names are referenced directly
> > outside of the module (apart from resources.module.js of course) so
> > moving the modules shouldn't affect any existing usage in searchlight
> > ui.
> >
> > We could bikeshed this for ages, so if I could just get Rob and Steve
> > to wrestle over it or something, that'd be good. Rob's pretty scrappy.
> >
> >
> >   Richard
> >
> >
> > On 10 March 2017 at 09:56, Richard Jones <r1chardj0...@gmail.com> wrote:
> >> OK, I will work on a plan that migrates the code into Horizon, thanks
> >> everyone!
> >>
> >> Travis, can the searchlight details page stuff be done through
> >> extending the base resource type in Horizon? If not, is that perhaps a
> >> limitation of the extensible service?
> >>
> >>
> >>  Richard
> >>
> >>
> >> On 10 March 2017 at 02:20, McLellan, Steven <steve.mclel...@hpe.com>
> >> wrote:
> >>> I concur; option 4 is the only one makes sense to me and was what was
> >>> intended originally. As long as we can do it in one fell swoop in

Re: [openstack-dev] [Horizon][searchlight] Sharing resource type implementations

[Richard Jones]

Thanks, Steve!

I've put together an initial patch
https://review.openstack.org/#/c/444095/ which pulls in the
os-nova-servers module and a little extra to make it work in Horizon's
codebase. I've tried to make minimal edits to the actual code -
predominantly just editing module names. I've tested it and it mostly
works on Horizon's side \o/


 Richard

On 10 March 2017 at 14:40, McLellan, Steven <steve.mclel...@hpe.com> wrote:
> My expertise in this area is deeply suspect but as long as we maintain the
> mapping from the resource type names that searchlight uses (os-nova-servers)
> to the modules we'll be OK. If you or Rob put a patch up against horizon I
> (or a willing victim/volunteer) can test a searchlight-ui patch against it.
>
>
>  Original message ----
> From: Richard Jones <r1chardj0...@gmail.com>
> Date: 3/9/17 21:13 (GMT-06:00)
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [Horizon][searchlight] Sharing resource type
> implementations
>
> Hey folks,
>
> Another potential issue is that the searchlight module structure and
> Horizon's module structure are different in a couple of respects. I
> could just retain the module structure from searchlight
> ('resources.os-nova-servers') or, preferably, I could rename those
> modules to match the Horizon structure more closely
> ('horizon.app.resources.os-nova-servers') or more strictly
> ('horizon.app.core.instances').
>
> As far as I can tell none of the module names are referenced directly
> outside of the module (apart from resources.module.js of course) so
> moving the modules shouldn't affect any existing usage in searchlight
> ui.
>
> We could bikeshed this for ages, so if I could just get Rob and Steve
> to wrestle over it or something, that'd be good. Rob's pretty scrappy.
>
>
>   Richard
>
>
> On 10 March 2017 at 09:56, Richard Jones <r1chardj0...@gmail.com> wrote:
>> OK, I will work on a plan that migrates the code into Horizon, thanks
>> everyone!
>>
>> Travis, can the searchlight details page stuff be done through
>> extending the base resource type in Horizon? If not, is that perhaps a
>> limitation of the extensible service?
>>
>>
>>  Richard
>>
>>
>> On 10 March 2017 at 02:20, McLellan, Steven <steve.mclel...@hpe.com>
>> wrote:
>>> I concur; option 4 is the only one makes sense to me and was what was
>>> intended originally. As long as we can do it in one fell swoop in one cyclle
>>> (preferably sooner than later) there should be no issues.
>>>
>>>
>>>
>>>
>>> On 3/9/17, 8:35 AM, "Tripp, Travis S" <travis.tr...@hpe.com> wrote:
>>>
>>>>Let me get Matt B in on this discussion, but basically, option 4 is my
>>>> initial feeling as Rob stated.
>>>>
>>>>One downside we saw with this approach is that we weren’t going to be
>>>> able to take advantage of searchlight capabilities in details pages if
>>>> everything was in native horizon.  Although, I suppose that could be done 
>>>> by
>>>> using the hz-if-services directive [0] if horizon will allow searchlight
>>>> optimized code to be in the horizon repo.
>>>>
>>>>[0]
>>>> https://github.com/openstack/horizon/blob/master/openstack_dashboard/static/app/core/cloud-services/hz-if-services.directive.js
>>>>
>>>>-Travis
>>>>
>>>>On 3/9/17, 5:09 AM, "Rob Cresswell (rcresswe)" <rcres...@cisco.com>
>>>> wrote:
>>>>
>>>>I tried searching the meeting logs but couldn’t find where we
>>>> discussed this in the Searchlight meeting. The conclusion at the time was
>>>> option 4 IIRC. The main thing is to make sure we get it done within one
>>>> cycle, even if it isn’t default. this means searchlight-ui doesn’t have to
>>>> carry some horrible workarounds and can just remove the code from their
>>>> repo.
>>>>
>>>>Basically; start putting the code in the Horizon repo, and when its
>>>> done, Searchlight-UI can remove it from their repo.
>>>>
>>>>Rob
>>>>
>>>>
>>>>> On 9 Mar 2017, at 04:22, Richard Jones <r1chardj0...@gmail.com>
>>>> wrote:
>>>>>
>>>>> Hi Searchlight and Horizon folks,
>>>>>
>>>>> I'd like to re-use the wonderful resource type code from
>>>>   

Re: [openstack-dev] [Horizon][searchlight] Sharing resource type implementations

[Richard Jones]

Hey folks,

Another potential issue is that the searchlight module structure and
Horizon's module structure are different in a couple of respects. I
could just retain the module structure from searchlight
('resources.os-nova-servers') or, preferably, I could rename those
modules to match the Horizon structure more closely
('horizon.app.resources.os-nova-servers') or more strictly
('horizon.app.core.instances').

As far as I can tell none of the module names are referenced directly
outside of the module (apart from resources.module.js of course) so
moving the modules shouldn't affect any existing usage in searchlight
ui.

We could bikeshed this for ages, so if I could just get Rob and Steve
to wrestle over it or something, that'd be good. Rob's pretty scrappy.


  Richard


On 10 March 2017 at 09:56, Richard Jones <r1chardj0...@gmail.com> wrote:
> OK, I will work on a plan that migrates the code into Horizon, thanks 
> everyone!
>
> Travis, can the searchlight details page stuff be done through
> extending the base resource type in Horizon? If not, is that perhaps a
> limitation of the extensible service?
>
>
>  Richard
>
>
> On 10 March 2017 at 02:20, McLellan, Steven <steve.mclel...@hpe.com> wrote:
>> I concur; option 4 is the only one makes sense to me and was what was 
>> intended originally. As long as we can do it in one fell swoop in one cyclle 
>> (preferably sooner than later) there should be no issues.
>>
>>
>>
>>
>> On 3/9/17, 8:35 AM, "Tripp, Travis S" <travis.tr...@hpe.com> wrote:
>>
>>>Let me get Matt B in on this discussion, but basically, option 4 is my 
>>>initial feeling as Rob stated.
>>>
>>>One downside we saw with this approach is that we weren’t going to be able 
>>>to take advantage of searchlight capabilities in details pages if everything 
>>>was in native horizon.  Although, I suppose that could be done by using the 
>>>hz-if-services directive [0] if horizon will allow searchlight optimized 
>>>code to be in the horizon repo.
>>>
>>>[0] 
>>>https://github.com/openstack/horizon/blob/master/openstack_dashboard/static/app/core/cloud-services/hz-if-services.directive.js
>>>
>>>-Travis
>>>
>>>On 3/9/17, 5:09 AM, "Rob Cresswell (rcresswe)" <rcres...@cisco.com> wrote:
>>>
>>>I tried searching the meeting logs but couldn’t find where we discussed 
>>> this in the Searchlight meeting. The conclusion at the time was option 4 
>>> IIRC. The main thing is to make sure we get it done within one cycle, even 
>>> if it isn’t default. this means searchlight-ui doesn’t have to carry some 
>>> horrible workarounds and can just remove the code from their repo.
>>>
>>>Basically; start putting the code in the Horizon repo, and when its 
>>> done, Searchlight-UI can remove it from their repo.
>>>
>>>Rob
>>>
>>>
>>>> On 9 Mar 2017, at 04:22, Richard Jones <r1chardj0...@gmail.com> wrote:
>>>>
>>>> Hi Searchlight and Horizon folks,
>>>>
>>>> I'd like to re-use the wonderful resource type code from
>>>> searchlight-ui (in particular os-nova-servers right now but
>>>> potentially others down the track) and was wondering whether you'd had
>>>> any thoughts about how we might share that code? Off the top of my
>>>> head I see a few options:
>>>>
>>>> 1. We depend on the searchlight-ui as a Horizon requirement; this is
>>>> pretty unlikely to happen (depending on any optional panel means it's
>>>> not really optional any longer ;-)
>>>> 2. We copy the code from searchlight-ui into Horizon; this is pretty 
>>> terrible.
>>>> 3. We move the code from searchlight-ui into a separate project that
>>>> both Horizon and searchlight-ui depend upon; this could be made to
>>>> work, though it's Yet Another Project.
>>>> 4. We move the code from searchlight-ui into Horizon. I think this is
>>>> most likely to work.
>>>>
>>>> What are your thoughts? Have I missed an option in this list that you
>>>> think is a better one? Have I missed the mark in my analysis of the
>>>> options I've presented?
>>>>
>>>>
>>>>  Richard
>>>>
>>>> 
>>> __
>>>> OpenStack Development

Re: [openstack-dev] [Horizon][searchlight] Sharing resource type implementations

[Richard Jones]

OK, I will work on a plan that migrates the code into Horizon, thanks everyone!

Travis, can the searchlight details page stuff be done through
extending the base resource type in Horizon? If not, is that perhaps a
limitation of the extensible service?


 Richard


On 10 March 2017 at 02:20, McLellan, Steven <steve.mclel...@hpe.com> wrote:
> I concur; option 4 is the only one makes sense to me and was what was 
> intended originally. As long as we can do it in one fell swoop in one cyclle 
> (preferably sooner than later) there should be no issues.
>
>
>
>
> On 3/9/17, 8:35 AM, "Tripp, Travis S" <travis.tr...@hpe.com> wrote:
>
>>Let me get Matt B in on this discussion, but basically, option 4 is my 
>>initial feeling as Rob stated.
>>
>>One downside we saw with this approach is that we weren’t going to be able to 
>>take advantage of searchlight capabilities in details pages if everything was 
>>in native horizon.  Although, I suppose that could be done by using the 
>>hz-if-services directive [0] if horizon will allow searchlight optimized code 
>>to be in the horizon repo.
>>
>>[0] 
>>https://github.com/openstack/horizon/blob/master/openstack_dashboard/static/app/core/cloud-services/hz-if-services.directive.js
>>
>>-Travis
>>
>>On 3/9/17, 5:09 AM, "Rob Cresswell (rcresswe)" <rcres...@cisco.com> wrote:
>>
>>I tried searching the meeting logs but couldn’t find where we discussed 
>> this in the Searchlight meeting. The conclusion at the time was option 4 
>> IIRC. The main thing is to make sure we get it done within one cycle, even 
>> if it isn’t default. this means searchlight-ui doesn’t have to carry some 
>> horrible workarounds and can just remove the code from their repo.
>>
>>Basically; start putting the code in the Horizon repo, and when its done, 
>> Searchlight-UI can remove it from their repo.
>>
>>Rob
>>
>>
>>> On 9 Mar 2017, at 04:22, Richard Jones <r1chardj0...@gmail.com> wrote:
>>>
>>> Hi Searchlight and Horizon folks,
>>>
>>> I'd like to re-use the wonderful resource type code from
>>> searchlight-ui (in particular os-nova-servers right now but
>>> potentially others down the track) and was wondering whether you'd had
>>> any thoughts about how we might share that code? Off the top of my
>>> head I see a few options:
>>>
>>> 1. We depend on the searchlight-ui as a Horizon requirement; this is
>>> pretty unlikely to happen (depending on any optional panel means it's
>>> not really optional any longer ;-)
>>> 2. We copy the code from searchlight-ui into Horizon; this is pretty 
>> terrible.
>>> 3. We move the code from searchlight-ui into a separate project that
>>> both Horizon and searchlight-ui depend upon; this could be made to
>>> work, though it's Yet Another Project.
>>> 4. We move the code from searchlight-ui into Horizon. I think this is
>>> most likely to work.
>>>
>>> What are your thoughts? Have I missed an option in this list that you
>>> think is a better one? Have I missed the mark in my analysis of the
>>> options I've presented?
>>>
>>>
>>>  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

__
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][stable][requirements] Modifying global-requirements to cap xstatic package versions

[Richard Jones]

Hi folks,

We've run into some issues with various folks installing Horizon and
its dependencies using just requirements.txt which doesn't limit the
versions of xstatic packages beyond some minimum version. This is a
particular problem for releases prior to Ocata since those are not
compatible with the latest versions of some of the xstatic packages.
So, we believe what's necessary is to:

1. Update current global-requirements.txt to pin the current released
version of each xstatic package. We don't update xstatic packages very
often, so keeping g-r in lock-step with upper-constraints.txt is
reasonable, I think.
2. Update stable versions of global-requirements.txt to restrict them
to the versions we know are compatible based on the versions in
upper-constraints for the particular stable release.


Thoughts?

 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

Re: [openstack-dev] [horizon] PTG Summary

[Richard Jones]

On 28 February 2017 at 20:42, Rob Cresswell
 wrote:
>> - Use [horizon-plugin] mailer tag to keep people up to date
>
> So the idea here is to send an email for changes that are likely to affect
> plugins; new libs for example, or changes to core components, with the
> [horizon-plugin] tag.

OK, thanks!


>> Was there much discussion around project health, and the lack of core
> review capacity?
>
> Other than "this is a thing", not really. We discussed everyone's current
> time/work allocations, but there isn't much more we can do other than
> encourage people to contribute. The idea with narrowing the blueprint focus
> was to make it apparent what will be reviewed and what will be ignored.

Yep, good move. I also just saw your email about single-core, which
I've already indicated to you privately I'm fully behind.


 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

Re: [openstack-dev] [horizon] PTG Summary

[Richard Jones]

On 28 February 2017 at 02:28, Rob Cresswell
 wrote:
> Quick summary of the PTG for those who missed it. Here's the etherpad, with
> notes inline: https://etherpad.openstack.org/p/horizon-ptg-pike

Was there much discussion around project health, and the lack of core
review capacity?


 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

Re: [openstack-dev] [horizon] PTG Summary

[Richard Jones]

On 28 February 2017 at 02:28, Rob Cresswell
 wrote:
> Quick summary of the PTG for those who missed it. Here's the etherpad, with
> notes inline: https://etherpad.openstack.org/p/horizon-ptg-pike

Thanks, Rob!


> - Use [horizon-plugin] mailer tag to keep people up to date

Could you expand on this please? Who is using/consuming this, and what
information is desired?


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-dev] [Horizon] Weekly wrap-up

[Richard Jones]

Hi folks,

A quiet week this week as folks gear up for Pike and the PTG next week.

We did get Ocata RC2 out the door this week with those final few bug
fixes and the wonderful translations from the i18n team! Thanks to
everyone who helped make Ocata Horizon happen :-)

If you're going to the PTG, or have something you'd like discussed
there, please get your thoughts about Pike planning into the
etherpad[1].


Cheers, and signing off to hand over to Rob for Pike,

Richard

[1] https://etherpad.openstack.org/p/horizon-ptg-pike

__
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] Meeting at 20:00 UTC this Wednesday, 15th February

[Richard Jones]

Hi folks,

The Horizon team will be having our next meeting at 20:00 UTC this
Wednesday, 15th February in #openstack-meeting-3

Meeting agenda is here: https://wiki.openstack.org/wiki/Meetings/Horizon

Anyone is welcome to to add agenda items and everyone interested in
Horizon is encouraged to attend. As the PTG approaches it'd be great
to get your thoughts about Pike planning into the etherpad[1], and please
feel free to discuss such planning at the weekly meeting!


Cheers,

Richard

[1] https://etherpad.openstack.org/p/horizon-ptg-pike

__
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] Final project mascot

[Richard Jones]

Hi folks,

Here's the final mascot/logo from the Foundation.


Richard

-- Forwarded message --
From: Heidi Joy Tretheway <heidi...@openstack.org>
Date: 14 February 2017 at 08:49
Subject: Horizon project mascot
To: Rob Cresswell <robert.cressw...@outlook.com>, Richard Jones <
r1chardj0...@gmail.com>


Hi Richard and Rob,

I’m excited to finally be able to share final project logo files with you.
Inside this folder, you’ll find full-color and one-color versions of the
logo, plus a mascot-only version, in EPS, JPG and PNG formats. You can use
them on presentations and wherever else you’d like to add some team flair.

https://www.dropbox.com/sh/vyig9h2ko7onkcr/AACRX7ChY3lA0cNYs1OhCGZja?dl=0

At the PWG, we’ll have stickers for your team of the mascot, plus signage
on your room. I’m especially excited for the project teams to see all of
the logos together as one group, because they work beautifully together
stylistically while making each project’s mark distinctive. Feel free to
share this with your team, and thanks to you and to them for the hard work
they put into reaching an agreement on the mascot. Also feel free to direct
any questions my way!


[image: photo]
*Heidi Joy Tretheway*
Senior Marketing Manager, OpenStack Foundation
503 816 9769 | Skype: heidi.tretheway
<https://webapp.wisestamp.com/sig_iframe?origin=mac-mail_id=5499768844845056=0.9726545857097719#>
<http://linkedin.com/in/heiditretheway>  <http://twitter.com/heiditretheway>
  <http://www.openstack.org/>
__
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 wrap-up

[Richard Jones]

Hi folks,

We're well on our way to RC2, which will probably be tagged early next
week unless someone objects.We've got the requirements.txt updates for
the xstatic packages in but just need those last couple of domain
context related patches to get in (poke, poke...)

Use domain_context not effective domain to display domains list
  https://review.openstack.org/#/c/427125/
Disentangle domain context from effective domain
  https://review.openstack.org/#/c/427729/

Once those are definitively in or not, we'll know where RC2 stands.

We had a very brief meeting this week thanks in part to being so close
to the end of cycle, but also thanks to my IRC connection being super
flaky. If you have anything you'd like to discuss (or have discussed)
at the PTG, please add it to:

  https://etherpad.openstack.org/p/horizon-ptg-pike


Have a great weekend,

 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

Re: [openstack-dev] [requirements] [Horizon][Karbor][Magnum] Requesting FFE for xstatic packages

[Richard Jones]

It looks like Magnum-UI only has one xstatic package in their
requirements that isn't already in Horizon's requirements (and
therefore is superfluous), and that's xstatic-magic-search, which has
been replaced in Horizon by pulling magic search into the Horizon tree
(we forked because maintaining our own extensions against the package
was getting out of hand - we'd basically rewritten a large proportion
of the code).

I would recommend that the Magnum-UI project remove all xstatic
packages from requirements.txt


Richard

On 7 February 2017 at 14:17, Tony Breeds <t...@bakeyournoodle.com> wrote:
> On Tue, Feb 07, 2017 at 10:39:41AM +1100, Richard Jones wrote:
>> Hi requirements team,
>>
>> We've had a downstream packager come to us with issues packaging the
>> Horizon RC as described in this bug report:
>>
>>  https://bugs.launchpad.net/horizon/+bug/1662180
>>
>> The issues stems from the requirements file having several xstatic
>> package minimum versions specified that are no longer compatible with
>> Horizon, and the RDO build system honors those minimum version
>> specifications, and boom!
>
> This is a specific case of OpenStack provides poor tools for 
> testing/validating
> minimum requirements.  This is a thing we started trying to fix in Ocata but
> the work is slow going :(   I'm a little confused how this wasn't caught 
> sooner
> by RDO (given they would appear to have been testing the minimums for 
> xstatic-*)
>
>> Rob Cresswell has proposed a patch to bump those minimum versions up
>> to the versions specified in upper-constraints.txt:
>>
>>   https://review.openstack.org/#/c/429753
>
> That review seems to adjust all Xstatic packages where the minimu != the
> constrained version which is probably more than is required but it doesn't
> actually increase the knock-on effects so it seems like a good idea to me :)
>
> Looking at the projects that are affected by Rob's review:
>
> Package  : xstatic-angular [xstatic-angular>=1.3.7] (used by 3 projects)
> Package  : xstatic-angular-bootstrap 
> [xstatic-angular-bootstrap>=0.11.0.2] (used by 3 projects)
> Package  : xstatic-angular-gettext [xstatic-angular-gettext>=2.1.0.2] 
> (used by 3 projects)
> Package  : xstatic-bootstrap-scss [xstatic-bootstrap-scss>=3.1.1.1] (used 
> by 3 projects)
> Package  : xstatic-d3 [xstatic-d3>=3.1.6.2] (used by 3 projects)
> Package  : xstatic-font-awesome [xstatic-font-awesome>=4.3.0] (used by 3 
> projects)
> Package  : xstatic-jasmine [xstatic-jasmine>=2.1.2.0] (used by 3 projects)
> Package  : xstatic-jsencrypt [xstatic-jsencrypt>=2.0.0.2] (used by 3 
> projects)
> Package  : xstatic-rickshaw [xstatic-rickshaw>=1.5.0] (used by 3 projects)
> Package  : xstatic-smart-table [xstatic-smart-table!=1.4.13.0,>=1.4.5.3] 
> (used by 3 projects)
> Package  : xstatic-term-js [xstatic-term-js>=0.0.4.1] (used by 3 projects)
> openstack/horizon [tc:approved-release]
> openstack/karbor-dashboard[]
> openstack/magnum-ui   []
>
>
> Package  : xstatic-bootswatch [xstatic-bootswatch>=3.3.5.3] (used by 1 
> projects)
> openstack/horizon [tc:approved-release]
>
> And obviously RDO
>
> This will mean that Horizon will need an RC2, and any packaging/distro testing
> for horizon (and plugins/dashboards) will need to be restarted (iff said
> testing was done with an xstatic package not listed in 
> upper-constraaints.txt[1])
>
> I tried to determine the impact on magnum-ui and karbor-dashboard and AFAICT
> they're already using constraints.  The next thing to look at is the release
> model which is:
> magnum-ui:
>  type: horizon-plugin
>  model: cycle-with-intermediary
> karbor-dashboard:
>  type:  unknown
>  model: unknown
>
> I think this means it's safe grant this FFE as the affected plugins aren't
> necessarily in a stabilisation phase.
>
> So as far as I can see we have 2 options:
> 1. Do nothing: there will be other cases that minimums are not functional.
>RDO have tools and data to fix this in there own repos so we're not
>actually blocking them
> 2. Take the patch, and accept the knock on effects.
>
> I'm okay with taking this FFE if Karbor and Magnum PTLs sign off here (or on 
> the review)
>
>> Additionally to the above I will be proposing a patch to Horizon's
>> documented processes to ensure that when an xstatic upper-constraints
>> version is bumped we also bump the minimum version in
>> global-requirements to avoid this sort of thing in the future.
>
>

[openstack-dev] [Horizon] Meeting at 20:00 UTC this Wednesday, 8th February

[Richard Jones]

Hi folks,

The Horizon team will be having our next meeting at 20:00 UTC this
Wednesday, 8th February in #openstack-meeting-3

Meeting agenda is here: https://wiki.openstack.org/wiki/Meetings/Horizon

Anyone is welcome to to add agenda items and everyone interested in
Horizon is encouraged to attend. As the PTG approaches it'd be great
to get your thoughts about Pike planning into the etherpad[1], and please
feel free to discuss such planning at the weekly meeting!


Cheers,

Richard

[1] https://etherpad.openstack.org/p/horizon-ptg-pike

__
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] [requirements] [Horizon] Requesting FFE for xstatic packages

[Richard Jones]

Hi requirements team,

We've had a downstream packager come to us with issues packaging the
Horizon RC as described in this bug report:

 https://bugs.launchpad.net/horizon/+bug/1662180

The issues stems from the requirements file having several xstatic
package minimum versions specified that are no longer compatible with
Horizon, and the RDO build system honors those minimum version
specifications, and boom!

Rob Cresswell has proposed a patch to bump those minimum versions up
to the versions specified in upper-constraints.txt:

  https://review.openstack.org/#/c/429753

Additionally to the above I will be proposing a patch to Horizon's
documented processes to ensure that when an xstatic upper-constraints
version is bumped we also bump the minimum version in
global-requirements to avoid this sort of thing in the future.


Thank-you for your consideration,

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

Re: [openstack-dev] [horizon] [neutron] Horizon support for Neutron Trunks - PTL approval needed

[Richard Jones]

That idea has merit, though I don't know what the scope for such a
'neutron-ui' might be. I'm definitely supportive of the Neutron Trunks
UI efforts, but it'd be good to get an answer on this scope question
before rolling along and creating the project.


Richard

On 6 February 2017 at 12:14, Kevin Benton  wrote:
> If the horizon team would like neutron features to live outside, I wonder if
> it would make more sense to create a new 'neutron-ui' repo instead of it
> being trunk specific. That way we don't have to come up with a new repo for
> every new feature that needs a horizon UI.
>
> On Feb 3, 2017 09:26, "Bence Romsics"  wrote:
>>
>> Hi All,
>>
>> I'd like to add support for Neutron Trunks [1][2] into Horizon
>> together with a few colleagues in the Pike cycle. We thought of
>> writing a new Horizon plugin [3] for that purpose. That way I hope to
>> keep it optional for deployment and minimize the maintenance cost for
>> the Horizon core team. Of course we'd welcome all review feedback,
>> especially from the Horizon and Neutron teams.
>>
>> To host the work I'd like create a new project: openstack/neutron-trunk-ui
>>
>> Following the Project Creator's Guide, here's a proposed new project
>> config:
>>
>> https://review.openstack.org/428730
>>
>> And the corresponding governance change:
>>
>> https://review.openstack.org/428796
>>
>> Please review them and if you agree approve. Or guide me to a better
>> change.
>>
>> Thanks in advance,
>> Bence Romsics
>>
>> [1]
>> https://github.com/openstack/openstack-manuals/blob/master/doc/networking-guide/source/config-trunking.rst
>> [2] https://wiki.openstack.org/wiki/Neutron/TrunkPort
>> [3] http://docs.openstack.org/developer/horizon/tutorials/plugin.html
>>
>> __
>> 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] Weekly wrap-up

[Richard Jones]

Hi folks,

The mad rush to RC1 concluded this week with RC1 now tagged and the
stable/ocata branch created. We've got a couple of bugfixes that
should have made the RC1 release but just missed out so we're going to
try to get those in for RC2; otherwise RC1 is a good release, we can
all be happy with it!

This week's meeting covered a few topics beyond the impending RC1 release:

- There was some more talk of the PTG, and sadly a couple of folks
(myself included) won't be making it
- I volunteered to be the new Docs Liaison
- I welcomed our new (and returning) PTL for Pike, Rob Cresswell!


Have a great weekend all,

 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-dev] [Horizon] Meeting at 20:00 UTC this Wednesday, 1st February

[Richard Jones]

Hi folks,

The Horizon team will be having our next meeting at 20:00 UTC this
Wednesday, 1st February in #openstack-meeting-3

Meeting agenda is here: https://wiki.openstack.org/wiki/Meetings/Horizon

Anyone is welcome to to add agenda items and everyone interested in
Horizon is encouraged to attend.


Cheers,

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-dev] [Horizon] PTL non-candidacy

[Richard Jones]

Hi folks,

I won't be standing for PTL for the Pike release.

Ocata has been quite the ride, and I will continue to be a contributor
to Horizon after this release.

Thanks for giving me a go in the big seat, and I look forward to
supporting whoever steps up as PTL for Pike!


 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

Re: [openstack-dev] [horizon] FFE Request

[Richard Jones]

Hi Rob, FFE granted for those two in-flight patches.

On 26 January 2017 at 09:23, Lingxian Kong  wrote:
> Hi, Rob,
>
> First, thanks for your work!
>
> What's your plan for the other two tabs (security group, floatingip)? I
> could see the split is very helpful no matter from performance perspective
> and both useful from end user's perspective.
>
> BTW, a huge +1 for this FFE!
>
>
>
>
> Cheers,
> Lingxian Kong (Larry)
>
> On Thu, Jan 26, 2017 at 9:01 AM, Adrian Turjak 
> wrote:
>>
>> +1
>>
>> We very much need this as the performance of that panel is awful. This
>> solves that problem while being a fairly minor code change which also
>> provides much better UX.
>>
>>
>> On 26/01/2017 8:07 AM, Rob Cresswell  wrote:
>>
>> o/
>>
>> I'd like to request an FFE on
>> https://blueprints.launchpad.net/horizon/+spec/reorganise-access-and-security.
>> This blueprint splits up the access and security tabs into 4 distinct
>> panels. The first two patches are https://review.openstack.org/#/c/408247
>> and https://review.openstack.org/#/c/425345/
>>
>> It's low risk; no API layer changes, mostly just moving code around.
>>
>> 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
>

__
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] feature freeze exception request -- nova simple tenant usages api pagination

[Richard Jones]

[I'm on vacation, so can't look into this too deeply, sorry]

I'm not sure I follow Rob's point here. Does the patch
https://review.openstack.org/#/c/410337 just check the version to see
if it's >= 2.40 and take action appropriately? I don't see how it
changes anything to force requesting 2.40 with every request? Then
again, I've not been able to look into how the current clients'
microversion code is implemented/broken. Is it just that *declaring*
the 2.40 version in https://review.openstack.org/#/c/422642 results in
all requests being forced to use that version?


 Richard

On 23 January 2017 at 23:10, Radomir Dopieralski <openst...@sheep.art.pl> wrote:
> Yes, to do it differently we need to add the microversion support patch that
> you are working on, and make use of it, or write a patch that has equivalent
> functionality.
>
> On Fri, Jan 20, 2017 at 6:57 PM, Rob Cresswell
> <robert.cressw...@outlook.com> wrote:
>>
>> Just a thought: With the way we currently do microversions, wouldnt this
>> request 2.40 for every request ? There's a pretty good chance that would
>> break things.
>>
>> Rob
>>
>> On 20 January 2017 at 00:02, Richard Jones <r1chardj0...@gmail.com> wrote:
>>>
>>> FFE granted for the three patches. We need to support that nova API
>>> change.
>>>
>>> On 20 January 2017 at 01:28, Radomir Dopieralski <openst...@sheep.art.pl>
>>> wrote:
>>> > I would like to request a feature freeze exception for the following
>>> > patch:
>>> >
>>> > https://review.openstack.org/#/c/410337
>>> >
>>> > This patch adds support for retrieving the simple tenant usages from
>>> > Nova in
>>> > chunks, and it is necessary for correct data given that related patches
>>> > have
>>> > been already merged in Nova. Without
>>> > it, the data received will be truncated.
>>> >
>>> > In order to actually use that patch, however, it is necessary to set
>>> > the
>>> > Nova API version to at least
>>> > version 3.40. For this, it's necessary to also add this patch:
>>> >
>>> > https://review.openstack.org/422642
>>> >
>>> > However, that patch will not work, because of a bug in the
>>> > VersionManager,
>>> > which for some reason
>>> > uses floating point numbers for specifying versions, and thus
>>> > understands
>>> > 2.40 as 2.4. To fix that, it
>>> > is also necessary to merge this patch:
>>> >
>>> > https://review.openstack.org/#/c/410688
>>> >
>>> > I would like to request an exception for all those three patches.
>>> >
>>> > An alternative to this would be to finish and merge the microversion
>>> > support, and modify the first patch to make use of it. Then we would
>>> > need
>>> > exceptions for those two patches.
>>> >
>>> >
>>> > __
>>> > 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 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 wrap-up

[Richard Jones]

Hi folks,

We had a relatively brief Horizon meeting this week[1] in which I
announced the (planned) Feature Freeze that took place this week. This
means that all blueprint-related patches are now put on hold until
after the Ocata release of Horizon is done. In the mean time, only bug
patches and those few patches granted a Feature Freeze Exemption (FFE)
will be merged.

The patches granted FFE should be reviewed with the highest priority
where possible:

Keystone to Keystone Federation Drop Down
  https://review.openstack.org/#/c/408435/
Simple tenant usage pagination
  https://review.openstack.org/#/c/410337/
Add version 2.40 to the supported compute API versions
  https://review.openstack.org/#/c/422642/
Properly compare versions in APIVersionManager
  https://review.openstack.org/#/c/410688/

I will be cutting the milestone 3 release next week; the impact of
that is described on the Ocata release schedule page[2].


 Richard

[1] 
http://eavesdrop.openstack.org/meetings/horizon/2017/horizon.2017-01-18-20.03.html
[2] https://releases.openstack.org/ocata/schedule.html

__
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] feature freeze exception request -- nova simple tenant usages api pagination

[Richard Jones]

FFE granted for the three patches. We need to support that nova API change.

On 20 January 2017 at 01:28, Radomir Dopieralski  wrote:
> I would like to request a feature freeze exception for the following patch:
>
> https://review.openstack.org/#/c/410337
>
> This patch adds support for retrieving the simple tenant usages from Nova in
> chunks, and it is necessary for correct data given that related patches have
> been already merged in Nova. Without
> it, the data received will be truncated.
>
> In order to actually use that patch, however, it is necessary to set the
> Nova API version to at least
> version 3.40. For this, it's necessary to also add this patch:
>
> https://review.openstack.org/422642
>
> However, that patch will not work, because of a bug in the VersionManager,
> which for some reason
> uses floating point numbers for specifying versions, and thus understands
> 2.40 as 2.4. To fix that, it
> is also necessary to merge this patch:
>
> https://review.openstack.org/#/c/410688
>
> I would like to request an exception for all those three patches.
>
> An alternative to this would be to finish and merge the microversion
> support, and modify the first patch to make use of it. Then we would need
> exceptions for those two patches.
>
> __
> 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] Weekly wrap-up

[Richard Jones]

Hi folks,

Welcome back from the break - I hope you had a good one!

We kicked off 2017 with our first weekly meeting[1] that covered a few
areas, notably the impending Ocata feature freeze next week.

We also talked a little about the Pike PTG which is just over a month
away, and I've started a planning etherpad[2] for the sessions we'll
have at the PTG. If you're coming, or would like to have something
discussed at the PTG, please contribute to the etherpad.

I'm at a conference next week so most likely won't make the team
meeting, but it should run anyway. If you have anything to discuss at
the weekly meeting please add it to the agenda[3].

In the mean time, let's get those priority reviews[4] going so we can
get as many landed for Ocata!


 Richard

[1] 
http://eavesdrop.openstack.org/meetings/horizon/2017/horizon.2017-01-11-20.00.html
[2] https://etherpad.openstack.org/p/horizon-ptg-pike
[3] https://wiki.openstack.org/wiki/Meetings/Horizon
[4] https://review.openstack.org/#/q/starredby:r1chardj0n3s%20AND%20status: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-dev] Meeting at 20:00UTC this Wednesday, 11th January

[Richard Jones]

Hi folks,

The Horizon team will be having our next meeting at 20:00 UTC this
Wednesday, 11th January in #openstack-meeting-3

Meeting agenda is here: https://wiki.openstack.org/wiki/Meetings/Horizon

If we have spare time this meeting I think we should look into getting some
patches reviewed together.

Anyone is welcome to to add agenda items and everyone interested in
Horizon is encouraged to attend.


Cheers,

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-dev] [Horizon] No meeting this week, and most likely none next week

[Richard Jones]

Hi folks,

I'll be around but since most everyone else won't be, let's skip the
meeting this week.

I won't be around next week, so I won't be able to run the meeting then ether.


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

Re: [openstack-dev] [Horizon] Weekly wrap-up

[Richard Jones]

Yep, Rob's correct, that's the intent. There's also plenty of non-WIP
high priority patches in the starred list :-)

On 16 December 2016 at 23:31, Rob Cresswell (rcresswe)
<rcres...@cisco.com> wrote:
> I think the intent is to get eyes on those patches, to prevent a 1000 line
> rewrite only for a core to say “I think this is a bad idea”. So for
> important patches, its probably good to get earlier feedback.
>
> Rob
>
>
> On 16 Dec 2016, at 08:13, Radomir Dopieralski <openst...@sheep.art.pl>
> wrote:
>
> I wonder if it really makes sense to put WIP patches on the priority list. I
> think it's a bit counter-productive, considering that the prioritizing of
> patches was supposed to make them merge faster -- but we don't want to merge
> WIP patches, do we?
>
> On Fri, Dec 16, 2016 at 5:31 AM, Richard Jones <r1chardj0...@gmail.com>
> wrote:
>>
>> Hi folks,
>>
>> No Horizon meeting next week! I'll be around the week after (28th
>> December) so if anyone else is around we can totally have a meeting
>> then.
>>
>> Things that have happened this week, including in the team meeting[1]
>>
>> Ocata-2 was tagged!
>>
>> xstatic-angular-bootstrap 2.2.0.0 was released, which promptly broke
>> Ocata-2 (and Ocata-1, you're welcome). We knew it was coming, and Rob
>> Cresswell had a compatibility patch in place ready to go, so master
>> was back to working within half an hour of the upper-constraints patch
>> enabling 2.2.0.0! If you notice anything busted in Horizon related to
>> bootstrap please file a bug!
>>
>> I'd like to remind everyone that we have a blueprint in play which
>> describes our approach to API microversions[2]. Rob has a patch which
>> will land imminently that implements the core of the design. Please
>> hold off implementing your own version settings/checks! We've seen a
>> few microversion-related patches appear recently, and that's great to
>> see, we just need to make sure we're all heading in the same
>> direction.
>>
>> I've put up the first patch using ui-router which rather dramatically
>> alters the Swift UI[3], so I'd like some feedback on it please.
>>
>> We've got about five(ish) weeks until Feature Freeze[4], folks, so all
>> the help we can get on the priority patches[5] (reviews or coding
>> help) is appreciated!
>>
>>
>> I hope you all get to have some time off, and have an enjoyable holiday,
>>
>>Richard
>>
>> [1]
>> http://eavesdrop.openstack.org/meetings/horizon/2016/horizon.2016-12-14-20.00.html
>> [2] https://blueprints.launchpad.net/horizon/+spec/microversion-support
>> [3] https://review.openstack.org/#/c/350523
>> [4] https://releases.openstack.org/ocata/schedule.html
>> [5]
>> https://review.openstack.org/#/q/starredby:r1chardj0n3s%20AND%20status: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
>
>
>
> __
> 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] Weekly wrap-up

[Richard Jones]

Hi folks,

No Horizon meeting next week! I'll be around the week after (28th
December) so if anyone else is around we can totally have a meeting
then.

Things that have happened this week, including in the team meeting[1]

Ocata-2 was tagged!

xstatic-angular-bootstrap 2.2.0.0 was released, which promptly broke
Ocata-2 (and Ocata-1, you're welcome). We knew it was coming, and Rob
Cresswell had a compatibility patch in place ready to go, so master
was back to working within half an hour of the upper-constraints patch
enabling 2.2.0.0! If you notice anything busted in Horizon related to
bootstrap please file a bug!

I'd like to remind everyone that we have a blueprint in play which
describes our approach to API microversions[2]. Rob has a patch which
will land imminently that implements the core of the design. Please
hold off implementing your own version settings/checks! We've seen a
few microversion-related patches appear recently, and that's great to
see, we just need to make sure we're all heading in the same
direction.

I've put up the first patch using ui-router which rather dramatically
alters the Swift UI[3], so I'd like some feedback on it please.

We've got about five(ish) weeks until Feature Freeze[4], folks, so all
the help we can get on the priority patches[5] (reviews or coding
help) is appreciated!


I hope you all get to have some time off, and have an enjoyable holiday,

   Richard

[1] 
http://eavesdrop.openstack.org/meetings/horizon/2016/horizon.2016-12-14-20.00.html
[2] https://blueprints.launchpad.net/horizon/+spec/microversion-support
[3] https://review.openstack.org/#/c/350523
[4] https://releases.openstack.org/ocata/schedule.html
[5] https://review.openstack.org/#/q/starredby:r1chardj0n3s%20AND%20status: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-dev] [Horizon] Meeting at 20:00UTC this Wednesday, 14th December

[Richard Jones]

Hi folks,

The Horizon team will be having our next meeting at 20:00 UTC this
Wednesday, 14th December in #openstack-meeting-3

Meeting agenda is here: https://wiki.openstack.org/wiki/Meetings/Horizon

If we have spare time this meeting I think we should look into getting some
patches reviewed together.

Anyone is welcome to to add agenda items and everyone interested in
Horizon is encouraged to attend.

Since I'm going to be on vacation next week, I won't be holding a team
meeting. If someone else would like to step up to chair it, that'd be nice :-)


Cheers,

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-dev] [Horizon] End of week wrap-up

[Richard Jones]

Hi folks,

Ocata-2 will be released next week and we've had little success
getting the priority patches reviewed, unfortunately. We have had some
wins though, getting the upper-constraints stability patches into
stable Mitaka, which means we can be more confident releasing the
angular-bootstrap 2.2.0 xstatic library, and getting us out of the
dark ages of angular-bootstrap! We've also seen the profiler developer
panel get added, which will help us nail down some of the performance
issues that have been difficult to diagnose.

So yes, we're planning on tagging Horizon Ocata-2 (b2) next week, and
very shortly afterwards we'll be releasing xstatic-angular-bootstrap
2.2.0.0, and rolling in the compatibility patch for that into Horizon.
Horizon will be broken for a few days while compatibility is merged,
appropriate files are released and upper-constraints is updated.
Apologies, but that's just how backwards-incompatibility rolls,
sometimes!

This week's meeting[1] saw us discussing some of the patches under
review, but mostly, we discussed what to do with the languishing
integration test suite. David Lyle, PTL of many cycles, argued
strongly that they were a lost cause, and there was general support
for removing them completely, and migrating UI / full stack level
tests over to tempest. We have a couple of folks who will be looking
into that.

We also talked a little about our microversions approach, and Rob and
I have been nutting through the design of the approach in the
microversions etherherpad[2] to come up with an approach described in
the blueprint[3]. There's some ground-work to be done (pulling in
min/max version information, matching it to the config), and then
patches like instance description support can start using that version
support check facility.

There was also a request to be more fine-grained in attaching
blueprints to patches - the old "angularlise identity panels"
blueprint was widely abused, and it's good to see the individual panel
work being divided up now, thanks everyone!

Finally, we had a short talk about the mascot, and how to send
feedback on it (which you need to do ASAP if you haven't already). The
feedback link is [4]


Have a great weekend!

Richard

[1] 
http://eavesdrop.openstack.org/meetings/horizon/2016/horizon.2016-12-07-20.00.html
[2] https://etherpad.openstack.org/p/horizon-microversion-support
[3] https://blueprints.launchpad.net/horizon/+spec/microversion-support
[4] http://www.tinyurl.com/OSmascot

__
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] [Requirements] [Horizon] upper-constraints shenanigans and development milestones

[Richard Jones]

Hi folks,

We in Horizon land are looking to update to a new version of one of
our dependencies, Angular Bootstrap version 2.2.0. We do this through
xstatic packaging, so the release we'll be making is actually
xstatic-angular-bootstrap 2.2.0.0

This release is backward incompatible and breaks Horizon in many ways.
We already have a compatibility patch in review to get us up to speed
in Ocata, but prior versions of Horizon would break without
upper-constraints protections. We've recently pushed through several
changes to stable Mitaka to get those protections in place - Newton
was already protected.

The problem is that we'll have two Ocata milestone releases out when
2.2.0.0 is released, and those will break because we currently pull in
*master* upper-constraints for the milestone releases, rather than a
stable/ocata branch of upper-constraints - there is no stable/ocata
branch of upper-constraints yet.

Has the idea of branching at development milestones been raised previously?


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

Re: [openstack-dev] [Horizon] Draft team mascot

[Richard Jones]

>> On 6 Dec 2016, at 20:19, Richard Jones <r1chardj0...@gmail.com> wrote:
>> Please let me know what you think (by December 12) of this draft for
>> our Horizon team mascot.
>
On 7 December 2016 at 07:38, Rob Cresswell (rcresswe)
<rcres...@cisco.com> wrote:
> Are we missing an attachment / link ?

Weird! Trying again:
__
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] Draft team mascot

[Richard Jones]

Hi folks,

Please let me know what you think (by December 12) of this draft for
our Horizon team mascot.

__
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] Meeting at 20:00 UTC this Wednesday, 7th December

[Richard Jones]

Hi folks,

The Horizon team will be having our next meeting at 20:00 UTC this
Wednesday, 7th December in #openstack-meeting-3

Meeting agenda is here: https://wiki.openstack.org/wiki/Meetings/Horizon

If we have spare time this meeting I think we should look into getting some
patches reviewed together.

Anyone is welcome to to add agenda items and everyone interested in
Horizon is encouraged to attend.


Cheers,

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-dev] [Horizon] End of week wrap-up

[Richard Jones]

Hi folks,

A bit delayed because of a bonkers conference this weekend, but here's
what went on last week in Horizon land.

During the team meeting[1] I reiterated that there's a priority list
of patches for review that has still been needing attention[2], and
that we'd start looking at pulling some of the angularjs interface
patches from our Ocata-2 list[3] over to that review list also.

We discussed the new README team badges, and discovered that the bug I
noticed has already been patched, so we just need to get the README
structure corrected.

We discussed the (old) pending patch for zaqar / websocket use in
panel updates, and agreed that it makes sense for us to implement such
support in newer angularjs interfaces rather than add functionality to
the legacy panels which will be deprecated.

Finally the tox migration is almost complete, with the patch mentioned
in the meeting[4] now merged. The only remaining task will be to
remove run_tests.sh completely in Queens. Current users of
run_tests.sh should stop doing so ASAP, and will already have noticed
that venv maintenance is slower due to it now pulling in
upper-constraints.


Catch you next week in #openstack-horizon

Richard


[1] 
http://eavesdrop.openstack.org/meetings/horizon/2016/horizon.2016-11-30-20.00.html
[2] https://review.openstack.org/#/q/starredby:r1chardj0n3s%20AND%20status:open
[3] https://etherpad.openstack.org/p/horizon-ocata-priorities
[4] https://review.openstack.org/#/c/391506/

__
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][Keystone] Weekly meeting log (2016/12/1)

[Richard Jones]

Hi folks,

The meeting bot disappeared during the meeting so the record is
incomplete. The last 20 minutes are still in the channel log here:

http://eavesdrop.openstack.org/irclogs/%23openstack-meeting-cp/%23openstack-meeting-cp.2016-12-01.log.html#t2016-12-01T20:42:08


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-dev] [Horizon] [Keystone] cross-project meeting Thursday 1st December 2000UTC

[Richard Jones]

Hi folks,

The next Keystone/Horizon cross-project meeting is this Thursday, 1st
December at 2000UTC in #openstack-meeting-cp

The agenda is https://etherpad.openstack.org/p/ocata-keystone-horizon

Please update that document if you're working on one of the items.


 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-dev] [Horizon] Meeting at 20:00 UTC this Wednesday, 30th November

[Richard Jones]

Hi folks,

The Horizon team will be having our next meeting at 20:00 UTC this
Wednesday, 30th November in #openstack-meeting-3

Meeting agenda is here: https://wiki.openstack.org/wiki/Meetings/Horizon

Anyone is welcome to to add agenda items and everyone interested in
Horizon is encouraged to attend.


Cheers,

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-dev] [Horizon] End of week wrap-up

[Richard Jones]

Hi folks,

This was a bit of a slow-ish week given the number of folks away for
Thanksgiving. We had low-turnout Horizon meeting and cancelled the
Horizon/Keystone cross-project meeting. In the team meeting[1] we
covered:

- The patch priority review list, which looks a lot like last week :-(
- We agreed that we should try not to release xstatic libraries in
release week given compatibility issues.
- We discussed the automatic inclusion of xstatic packages in Horizon,
and upon reflection it's been decided it's a bad idea and we should
stick with an explicit whitelist which should be made easier to extend
if necessary.
- We punted on the question of the Zaqar push-based communication via
websocket patch that's been in play for a very long time. We'll
discuss it again next week when more folks are around.
- Pokemon, and how Thai needs to hand in his Gamer Card.

It really would be super awesome if folks could help us get through
those priority patches[2] so we can turn our focus to the angular work
for O-2! I'll start including the angular panels to be reviewed in
that list next week.

Some of us spent a lot of the week looking to further harden our
master and stable branches against library releases and this resulted
in a few changes, some of which are still up for review. We know some
of y'all have run into issues installing e.g. Mitaka or Newton and
have hit incompatibilities so if you do please hit us up in the
#openstack-horizon IRC channel, or on email, and we'll help you out.

The most important thing to remember is: use upper-constraints:

  pip install -c
http://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt?h=stable/
.


   Richard

[1] 
http://eavesdrop.openstack.org/meetings/horizon/2016/horizon.2016-11-16-20.00.html
[2] https://review.openstack.org/#/q/starredby:r1chardj0n3s%20AND%20status: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-dev] [Horizon][Keystone] No Horizon/Keystone cross-project meeting this week

[Richard Jones]

Hi folks,

Since so many key people are away on vacation, we'll skip this week's
meeting (November 24th).


 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-dev] [Horizon] Meeting at 20:00 UTC this Wednesday, 23rd November

[Richard Jones]

Hi folks,

The Horizon team will be having our next meeting at 20:00 UTC this
Wednesday, 23rd November in #openstack-meeting-3

Meeting agenda is here: https://wiki.openstack.org/wiki/Meetings/Horizon

Anyone is welcome to to add agenda items and everyone interested in
Horizon is encouraged to attend.


Cheers,

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-dev] [Horizon] Zhenguo Niu retiring from Horizon Core Team

[Richard Jones]

Hi folks,

Zhenguo Niu has been a core for many cycles, for which I thank him.
His focus and time has shifted away from UI though, so he's asked to
be removed from the core team.

Thanks again, Zhenguo!


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

Re: [openstack-dev] [Horizon] Proposing Kenji Ishii for core

[Richard Jones]

As a result of the unanimous vote here, I welcome Kenji to the Horizon
Core Team!


Richard

On 19 November 2016 at 12:37, Tripp, Travis S <travis.tr...@hpe.com> wrote:
> +1
>
>
>
> From: Timur Sufiev <tsuf...@mirantis.com>
> Reply-To: OpenStack List <openstack-dev@lists.openstack.org>
> Date: Friday, November 18, 2016 at 1:34 AM
> To: OpenStack List <openstack-dev@lists.openstack.org>
>
>
> Subject: Re: [openstack-dev] [Horizon] Proposing Kenji Ishii for core
>
>
>
> +1
>
>
>
> On Fri, Nov 18, 2016 at 12:35 AM Thai Q Tran <tqt...@us.ibm.com> wrote:
>
> +1 from me. Kenji is also very active in the plugin space.
>
>
>
> - Original message -
> From: David Lyle <dkly...@gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> Cc:
> Subject: Re: [openstack-dev] [Horizon] Proposing Kenji Ishii for core
> Date: Thu, Nov 17, 2016 11:51 AM
>
>
> +1
>
> On Tue, Nov 15, 2016 at 5:02 AM, Akira Yoshiyama
> <akirayoshiy...@gmail.com> wrote:
>> +1
>>
>> 2016年11月15日(火) 20:47 Rob Cresswell (rcresswe) <rcres...@cisco.com>:
>>>
>>> Big +1 from me
>>>
>>> > On 14 Nov 2016, at 00:24, Richard Jones <r1chardj0...@gmail.com> 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
>
>
>
>
> __
> 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] End of week wrap-up

[Richard Jones]

Hi folks,

This week's Horizon goings-on saw several of the priority patches[1]
for O-1 land, though more won't make it into that release. O-1 will be
tagged in a few hours, once we sort out some issues with the npm test
suite introduced with a recent patch.

The team meeting this week[2] was a busy affair, with discussions around:

- the current priority bugs and patches
- nova changing the os-simple-tenant-usage API call
- whether to support ui-cookiecutter as an OpenStack project, and even
whether to include it in Horizon tree
- what on Earth is going on in JS translations :-)

We also had another productive cross-project meeting with the Keystone folks[3]:

- some good progress in a bunch of areas
- the django-openstack-auth-kerberos repos will be retired!
- keystone will look into exposing password strength rules through an
API for us to use in UI (rather than relying on a low-strength
rejection error)
- we will prioritise getting filter-first into all identity
searches/listings to better handle large LDAP stores

Patches supporting the cross-project efforts have been added to the
priority patches list[1]


Have a great weekend,

Richard


[1] https://review.openstack.org/#/q/starredby:r1chardj0n3s%20AND%20status:open
[2] 
http://eavesdrop.openstack.org/meetings/horizon/2016/horizon.2016-11-16-20.00.html
[3] 
http://eavesdrop.openstack.org/meetings/keystone_horizon/2016/keystone_horizon.2016-11-17-20.02.html

__
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] Meeting at 20:00 UTC this Wednesday, 16th November

[Richard Jones]

Hi folks,

The Horizon team will be having our next meeting at 20:00 UTC this
Wednesday, 16th November in #openstack-meeting-3

Meeting agenda is here: https://wiki.openstack.org/wiki/Meetings/Horizon

Anyone is welcome to to add agenda items and everyone interested in
Horizon is encouraged to attend.


Cheers,

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-dev] [Horizon] Proposing Kenji Ishii for core

[Richard Jones]

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-dev] [Horizon] End of week wrap-up

[Richard Jones]

Hi folks,

We had our kickoff Keystone/Horizon cross-project meeting[1] which was
super productive, and we've settled on Thursday 2000UTC as the meeting
time going forward. We'll meet in #openstack-meeting-cp - details
here[2]. The range of topics was broad, both on the Horizon and
Keystone side. We'll be keeping the etherpad created at the summit
updated with our discussions and progress[3].

In our team meeting this week[4] we covered a few topics, notably:

- a status update of the priority patches
- xstatic-angular-ui-router is now an OpenStack project, and in
global-requirements, ready for use O-2 patches
- issues we need to consider around updating angular-bootstrap, and
not breaking stable Horizon
- discussion about the PTG

Ocata-1 will be tagged next week, so if you can it'd be super helpful
to focus reviews on the patches we really need to land in that
release[5].

Catch you next week in #openstack-horizon


 Richard

[1] 
http://eavesdrop.openstack.org/meetings/horizon_keystone/2016/horizon_keystone.2016-11-08-20.01.html
[2] http://eavesdrop.openstack.org/#Keystone/Horizon_Collaboration_Meeting
[3] https://etherpad.openstack.org/p/ocata-keystone-horizon
[4] 
http://eavesdrop.openstack.org/meetings/horizon/2016/horizon.2016-11-09-20.00.html
[5] https://review.openstack.org/#/q/starredby:r1chardj0n3s%20AND%20status: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-dev] [Horizon] Meeting at 20:00 UTC this Wednesday, 9nd November

[Richard Jones]

Hi folks,

The Horizon team will be having our next meeting at 20:00 UTC this
Wednesday, 9nd November in #openstack-meeting-3

Meeting agenda is here: https://wiki.openstack.org/wiki/Meetings/Horizon

Anyone is welcome to to add agenda items and everyone interested in
Horizon is encouraged to attend.


Cheers,

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-dev] [Horizon] [Keystone] Inaugural weekly cross-project meeting summary

[Richard Jones]

Hi folks,

Today we had the first of what will be a regular cross-project meeting
series for Horizon and Keystone developers[1].

It was a very productive meeting, and we resolved to continue to keep
our ongoing notes and status summaries in the etherpad[2] while still
ensuring that BPs or bugs cover the actual work being done.

The new, official timeslot will be Thursday at 2000 UTC[3]


 Richard

[1] 
http://eavesdrop.openstack.org/meetings/horizon_keystone/2016/horizon_keystone.2016-11-08-20.01.html
[2] https://etherpad.openstack.org/p/ocata-keystone-horizon
[3] http://eavesdrop.openstack.org/#Keystone/Horizon_Collaboration_Meeting

__
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] End of week (almost) wrap-up

[Richard Jones]

Hi folks,

I'm going to be taking a long weekend, so the end of week wrap-up is
early by a day :-)

Last week was the summit, and I've written up a summary of
Horizon-related design summit goings-on[1].

In our meeting this week[2] we covered a few topics, notably:

- the removal of the Selenium gate tests
- summit recap
- the new weekly Keystone / Horizon meeting
- priority patches for review to get them in Ocata-1
- priority bugs
- some other things like pointers to installing PyPI caches (to speed up tox)

Catch you next week in #openstack-horizon


 Richard

[1] http://lists.openstack.org/pipermail/openstack-dev/2016-November/106520.html
[2] 
http://eavesdrop.openstack.org/meetings/horizon/2016/horizon.2016-11-02-20.00.html

__
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] Meeting at 20:00 UTC this Wednesday, 2nd November

[Richard Jones]

Hi folks,

The Horizon team will be having our next meeting at 20:00 UTC this
Wednesday, 2nd November in #openstack-meeting-3

Meeting agenda is here: https://wiki.openstack.org/wiki/Meetings/Horizon

Anyone is welcome to to add agenda items and everyone interested in
Horizon is encouraged to attend.


Cheers,

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-dev] [Horizon] Summit recap

[Richard Jones]

Hi folks,

We had several very productive Horizon sessions at the summit last
week. Thanks to everyone who was able to contribute, especially the
folks from the Keystone project for the combined session. A summary of
the discussions and outcomes:


== Project Organisation ==

We will be formalising our guidance and processes around project core
team members; how we choose them and their responsibilities once in
the core team. Further messages around those issues will follow this
one.

We also discussed how to improve our use of reno, most notably about
ensuring that reno is included in patches that need it (most
importantly for upgrade information). We considered a gerrit bot that
would monitor large patches to prompt the patch author that a reno
component should be included in the patch; we just need a volunteer to
write the bot :-)

The use of reno is important to both notify operators and deployers of
big (or breaking) changes in Horizon, but also to ensure that that
information is included in stable branch backports. Please keep that
in mind when reviewing patches.

We talked through some improvements to our documentation: most notably
that we need better docs for testing setup and enabled files for
plugins. Also, we still don't generate docs for our Javascript
components. We are starting to get some higher-level documentation
around the Javascript frameworks, which is great to see!


== Testing ==

Our Selenium tests are still broken, but Timur Sufiev has a number of
thoughts on how to address the issues (which all stem from breaking
changes introduced in recent releases of both selenium and firefox).
We also discussed ways to improve reliability (and possibly
performance) of the tests, most likely by using a single browser
process.

Matt Borland also offered to examine the current selenium test suite
to determine which tests are unnecessary or out of date, and also to
look into which UI areas still have no coverage.

Related to testing is the migration from run_tests.sh to tox, which is
90% complete (run_tests.sh now generates a warning that it is
deprecated). Rob Cresswell is working through the last remaining bits
of functionality to allow that transition to complete.


== Keystone cross-project session ==

We met with the Keystone folks to talk through the current areas of
pain. We determined a number of points of action, one of which
(Horizon no longer revoking tokens) is already up as a patch, thanks
Eric Peterson! The two projects will also continue to look into
federation, default project roles, policy issues, k2k and project
listing issues.

We've started up a regular weekly meeting to continue the discussion
around Keystone and Horizon integration issues. The kickoff for these
meetings will be 8th November 2000UTC in #openstack-meeting-cp

(more detail in https://etherpad.openstack.org/p/ocata-keystone-horizon)


== AngularJS ==

We discussed the use of generic service proxies (as opposed to going
through the python clients) and agreed that they could be of use where
it is appropriate (where the python client adds no value). For a lot
of the core services those python clients do add value (especially
when microservices come into the picture - more on that below). We
ended up on the fence about including a generic proxy in Horizon, but
it could offer a good benefit to plugin authors who would then not
need to each write their own.

There was a general consensus to avoid continued refactoring for this
Ocata release, and focus on implementing the replacement panels
instead. To that end we identified a number of in-flight patches and
discussed priorities for the release.

The Launch Instance workflow still needs refinement (absent
functionality and lack of extensibility in a couple of areas) so it
was decided that the deprecation of the Django-based workflow would be
put on hold until the end of Pike. The Django implementation of the
Swift UI is being removed in Ocata though, and David Lyle has a patch
in the works to do that.

We intend to land ui-router support in Ocata-1 to support the Swift UI
and any other view that needs nested routing. Additionally, the
removal of scope usage in actions services should be completed in
Ocata-1 to lay down the pattern for follow-on panel work.

(more in https://etherpad.openstack.org/p/horizon-ocata-angularjs)


== Other bits ==

Eric's going to Make Quotas Great Again, and we're all excited. Some
Glance v2 cleanup (including a view filtering issue for admin users).

We discussed using websockets for view updates (eg. instances list)
but agreed that having Horizon listen to the flood of updates from
services would not be sensible, and rather we would continue to poll
and perhaps use Searchlight as a filtering intermediary.

(more in https://etherpad.openstack.org/p/horizon-ocata-cross-project)


== Microversions ==

We discussed how we would approach microversions, and have a potential
first implementation in mind - instance descriptions (already captured

Re: [openstack-dev] Resigning from horizon core

[Richard Jones]

Thank-you for everything, Matthias! I'll see you around OpenStack land :-)

Richard

Sent from my portable device, please excuse the brevity.

On 26 Oct. 2016 17:30, "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

[openstack-dev] [Horizon] Summit preparation

[Richard Jones]

Hi folks,

Summit's around the corner!

Even if you aren't going to be at the summit, we'd appreciate if you
could go over the etherpads we're going to be using, to add your
valuable input. They're all linked from
https://etherpad.openstack.org/p/horizon-ocata-summit and in
particular if you have any priority work it needs to go in the
priorities etherpad please.

If you are going, please contact me directly if you'd like to be
included in our "Horizon In BCN" Google Hangout.

If you're a core please let me know explicitly whether you're going or
not, as I would like to email you directly about some stuff if you're
not coming.


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

Re: [openstack-dev] [Horizon] Meeting this week cancelled

[Richard Jones]

Oh, and the meeting next week (26th) will also not happen due to the summit.


 Richard

On 19 October 2016 at 14:22, Richard Jones <r1chardj0...@gmail.com> wrote:

> Hi folks,
>
> With the summit almost upon us, and no agenda items or significant
> notices, I'm cancelling this week's team meeting (was scheduled for
> 2016/10/19 20:00UTC).
>
>
> Cheers,
>
>  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-dev] [Horizon] Meeting this week cancelled

[Richard Jones]

Hi folks,

With the summit almost upon us, and no agenda items or significant notices,
I'm cancelling this week's team meeting (was scheduled for 2016/10/19
20:00UTC).


Cheers,

 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-dev] [Horizon] End of week wrap-up

[Richard Jones]

Hi folks,

The kind folks from Keystone have organised to have a shared session at the
summit, thanks to Steve Martinelli for offering.

In our meeting this week[1] we covered a few topics, notably:

- the per-session etherpads for the summit are up now, linked from the main
summit etherpad[2]
- that includes the priorities session etherpad, which I ask you all to
contribute your priorities to[3]

Catch you next week in #openstack-horizon


 Richard

[1]
http://eavesdrop.openstack.org/meetings/horizon/2016/horizon.2016-10-12-20.00.html
[2] https://etherpad.openstack.org/p/horizon-ocata-summit
[3] https://etherpad.openstack.org/p/horizon-ocata-priorities
__
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] keystone/horizon integration session in barcelona

[Richard Jones]

Thanks, Steve, this will be a valuable session!

On 12 October 2016 at 08:14, Steve Martinelli 
wrote:

> The keystone team had a spare fishbowl session, and we decided to use it
> to collaborate with the horizon team on a few long standing issues we've
> had between the two projects.
>
> You can view the session online:
> https://www.openstack.org/summit/barcelona-2016/summit-
> schedule/events/16907
>
> Details here:
> Wed 26, 3:55pm-4:35pm
> Keystone: Keystone/Horizon integration session (Fishbowl)
> https://etherpad.openstack.org/p/ocata-keystone-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
>
>
__
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][stable] Moving stable/mitaka to Phase-II and liberty to Phase-III

[Richard Jones]

On 11 October 2016 at 08:34, Tony Breeds  wrote:

> On Mon, Oct 10, 2016 at 08:42:48AM +0200, Ihar Hrachyshka wrote:
> > I think it would also make sense to *release* on the boundary of the
> switch;
> > so that it’s clear which phase a release followed.
>
> I agree, I don't really have a mechanism for do that though.  I didn't
> state
> this but my plan was to reach out the PTLs that have the
> stable:follows-policy
> tag and ask them to release.  I suppose I could go one step further and
> propose the change in openstack/releases but that seems a little like over
> reach to me.
>
> What do PTLs / stable CPLs think?
>

As long as "boundary" is a generous number of days (a week?) and not a
single point in time, I think this is sensible.


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-dev] [Horizon] Meeting at 20:00 UTC this Wednesday, 12th October

[Richard Jones]

Hi folks,

The Horizon team will be having our next meeting at 20:00 UTC this
Wednesday, 12th October in #openstack-meeting-3

Meeting agenda is here: https://wiki.openstack.org/wiki/Meetings/Horizon

Anyone is welcome to to add agenda items and everyone interested in Horizon
is encouraged to attend.

In case you missed it or would like a refresher, the meeting minutes and
full logs from our last meeting are available:

Minutes:
http://eavesdrop.openstack.org/meetings/horizon/2016/horizon.2016-10-05-20.01.html
Log:
http://eavesdrop.openstack.org/meetings/horizon/2016/horizon.2016-10-05-20.01.log.html


Cheers,

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-dev] [Horizon] End of week wrap-up

[Richard Jones]

Hi folks,

Congratulations to all contributors to the Newton release - a release we
can all be proud of:

  http://docs.openstack.org/releasenotes/horizon/newton.html

Thanks to Rob Cresswell for his leadership through the Newton release. I'm
looking forward to seeing what we can achieve in Ocata.

In our meeting this week[1] we covered a few topics, notably:

- the schedule for Horizon sessions is now available[2]
- whether we as a team wish to participate in the Project Teams Gathering
(yes)
- a discussion regarding how to progress the incorporation of the Profiler
panel

Catch you next week in #openstack-horizon


 Richard

[1] https://wiki.openstack.org/wiki/Meetings/Horizon
[2]
https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Horizon%3A
__
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] gate failures (fragile integrated tests)

[Richard Jones]

This seems to also be a connection issue to Firefox, but just in a
different place:
http://logs.openstack.org/69/375669/1/check/gate-horizon-dsvm-integration-deprecated-ubuntu-xenial/468d333/console.html#_2016-09-23_19_38_05_221999


 Richard


On 23 September 2016 at 22:18, Akihiro Motoki  wrote:

> Hi horizoners,
>
> As you may have noticed, the main fixes have been merged and the horizon
> gate failure rate seems to be recovered.
> There are still some remaining issues around the integration tests, but
> top failure rate problems now have been fixed or have a workaround.
> Thanks for your patience.
>
>
> 2016-09-23 9:30 GMT+09:00 Akihiro Motoki :
>
>> Hi horizoners,
>>
>> The current horizon gate is half broken as both integrated tests are
>> 30-40% failure rate.
>> (See https://bugs.launchpad.net/horizon/+bug/1626536 and
>> https://bugs.launchpad.net/horizon/+bug/1626643)
>> Fixes for these bugs are now under the gate.
>>
>> Please avoid using 'recheck' if one of integrated tests fails.
>>
>> Cores, let these fixes be merged first.
>> Until then, avoid giving +A for others to merge them fast.
>>
>> Thanks,
>> Akihiro
>>
>>
>
> __
> 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] Ocata design summit

[Richard Jones]

Hi folks,

Not long to go before the Ocata summit. We'll devote next week's team
meeting[1] to discussing the design sessions. If you haven't done so
already, please add your thoughts to the planning etherpad[2].


Thanks,

 Richard

[1] https://wiki.openstack.org/wiki/Meetings/Horizon
[2] https://etherpad.openstack.org/p/horizon-ocata-summit
__
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] [Release] [FFE] two xstatic packages to be bumped in upper-constraints, please

[Richard Jones]

Hi folks,

We have two patches to upper-constraints up that we'd like to see merged
for Newton. The package updates in question only changed meta-data, but
they did so in a way that fixes issues for downstream, and it makes sense
to keep upper-constraints in line with what they'll be packaging.

The reviews are:

update constraint for XStatic-Bootstrap-SCSS to new release 3.3.7.1
https://review.openstack.org/#/c/368970/

update constraint for XStatic-smart-table to new release 1.4.13.2
https://review.openstack.org/#/c/366194/


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-dev] [Horizon] PTL candidacy

[Richard Jones]

I am announcing my candidacy for Horizon PTL.

I've been contributing to Horizon since the Juno cycle and have
been a core reviewer for the last two cycles. We’ve got a great
culture in the Horizon team that I’d like to help continue and
thrive.

I feel we have made good progress in several areas of Horizon that
improve responsiveness and stability, and believe our focus should
be on continuing that work.

My goals for Ocata are:

- Ensure that modernisation of the interface continues with good
  framework components emerging that are accessible to existing and
  new developers of Horizon and Horizon plugins. This means
  continuing to ensure the code is written to good, consistent
  patterns, but also making sure there is good documentation to
  accompany it.

- Continue to encourage finding better ways to handle scaling
  in OpenStack, both in our own filtering and use of data but also
  liaising with other projects to see how they can help us address
  scaling bottlenecks. Getting the profiling panel integrated into
  Horizon’s developer interface is a high priority for Ocata.

- Improve our rate of addressing bugs; I will look at running more
  of the successful bug days that we had previously. One aspect
  of this is putting more effort into keeping our dependency
  compatibilities up to date, both Python and Django, but also
  the xstatic packages we rely on.

- Improve communication both within the Horizon team and outside
  so folks can more easily get up to speed or keep up to date with
  what’s happening in Horizon.


Thank you,

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

Re: [openstack-dev] [horizon] [horizon-plugin] AngularJS 1.5.8

[Richard Jones]

Let's do it, yep.

On 3 August 2016 at 20:19, Rob Cresswell 
wrote:

> Hi all,
>
> Angular 1.5.8 is now updated in its XStatic repo:
> https://github.com/openstack/xstatic-angular
>
> I've done some manual testing of the angular content and found no issues
> so far. I'll be checking that the JS tests and integration tests pass too;
> if they do, would it be desirable to release 1.5.8 this week, or wait until
> after N is released? It'd be nice to be in sync with current stable, but I
> don't want to cause unnecessary work a few weeks before plugin FF.
>
> Thoughts?
>
> 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] Angular panel enable/disable not overridable in local_settings

[Richard Jones]

On 3 August 2016 at 00:32, Rob Cresswell 
wrote:

> Hi all,
>
> So we seem to be adopting a pattern of using UPDATE_HORIZON_CONFIG in the
> enabled files to add a legacy/angular toggle to the settings. I don't like
> this, because in settings.py the enabled files are processed *after*
> local_settings.py imports, meaning the angular panel will always be
> enabled, and would require a local/enabled file change to disable it.
>
> My suggestion would be:
>
> - Remove current UPDATE_HORIZON_CONFIG change in the swift panel and
> images panel patch
> - Add equivalents ('angular') to the settings.py HORIZON_CONFIG dict, and
> then the 'legacy' version to the test settings.
>
> I think that should run UTs as expected, and allow the legacy/angular
> panel to be toggled via local_settings.
>
> Was there a reason we chose to use UPDATE_HORIZON_CONFIG, rather than just
> updating the dict in settings.py? I couldn't recall a reason, and the
> original patch ( https://review.openstack.org/#/c/293168/ ) doesn't seem
> to indicate why.
>

It was an attempt to keep the change more self-contained, and since
UPDATE_HORIZON_CONFIG existed, it seemed reasonable to use it. It meant
that all the configuration regarding the visibility of the panel was in one
place, and since it's expected that deployers edit enabled files, I guess
your concern stated above didn't come into it.

I'm ambivalent about the change you propose, would be OK going either way
:-)


 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-dev] [Horizon] ResourceType'ing the Swift UI and a bit of a speed bump

[Richard Jones]

Hi folks,

I've just pushed up an initial patch which implements *some* of the Swift
UI functionality using the ResourceType framework:
https://review.openstack.org/347114

I say *some* because there's an issue in the current code which will
require some refactoring to make it work in a ResourceType world. Funnily
enough, it's related to my other work in de-$scope-ifying the images
actions...

In short, the current containers model service is used for UI state. Kind
of like scope. Either way, it's bad (and I fully own that mistake, and I
apologise for being such a bad person). To make things work properly, the
containers model needs to have its state removed out to the two controllers
(containers and objects). It will retain the interfaces into Swift's object
containers, but those interfaces will require the caller to provide full
context (container and path) rather than relying on the state currently
stored on the model.

The state will be stored on the controllers. Funnily enough I had
implemented things like this in the first iteration of the swift ui, but I
had trouble sharing context between the two controllers. That was before I
used ngRoute. The routing information provides the state information needed
now.

I'm going to look at putting up a new patch to address this and and
hopefully it won't be too horrendous...


 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

Re: [openstack-dev] [Horizon] Angular action services and initScope

[Richard Jones]

Thanks for the response, Thai!

Before I get into addressing your specifics below, I've put up a proof of
concept patch that modifies images create-volume to remove the need for
scope:

  https://review.openstack.org/#/c/345145


On 21 July 2016 at 08:23, Thai Q Tran  wrote:

> You all sort of touched on what I am about to reiterate:
>
> 1. The scope was intended to be used as a way to propagate events up and
> down the chain (from table controller to step controller) since there was
> no real way to share information between controllers (remember that a modal
> dialog launches an entirely different fragment of HTML with no relationship
> to the current controller). Furthermore, we needed to use initScope to
> explicitly set the scope so that $modal does not use the $rootScope (which
> it does by default if scope is not set). As a side bonus, we were also able
> to use events to share data between the steps. The idea behind was to *make
> steps independent* *and reusable* in multiple workflows. The reality is
> that the event propagation required both an $emit and a $broadcast to
> actually share data between steps, this makes it much less desirable.
>

We can definitely still share data between steps, and my proposal makes it
easier, I think: every step has access to the data captured by every other
step (through $scope.stepModels) which they can $watch on or even modify.
There's still a scope encompassing the wizard modal, it's just not tied
back up to the table scope.

As I said previously, I don't believe we should overly complicate things in
the pursuit of making steps reusable, since outside of a potential re-use
of metadata step (still to be proven whether that's even feasible) I
believe YAGNI.



> *The root of the problem is, how does my table know to update once the
> form is submitted?*
>

The table knows through the new ActionResult mechanism (which is
automatically handled by hz-resource-table and manually handled by the
handler provided to hz-dynamic-table ... and even more manually handled if
you don't use either of those ).



>  2. Going with Richards idea of a shared workflow.model idea.
> *...*
> To me there are two questions we should answer before we jump and do
> another rewrite.
> 1. How are we going to glue the various controllers together if we don't
> use scope.
> 2. How is data between the steps going to be shared.
>

I believe I've addressed these questions in my POC patch.


 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

Re: [openstack-dev] [Horizon] On testing...

[Richard Jones]

On 21 July 2016 at 10:13, Timur Sufiev <tsuf...@mirantis.com> wrote:

> I'm not sure if (3) was the thing we agreed upon (and if it will help us
> to detect issues in Horizon) but the rest of options definitely make sense
> to me.
>

I think that's reasonable - moving the tests to tempest will make it more
difficult to run them locally.



> Also there is
>
> 5. Parallelize integration tests.
>

Ah, yep, good catch. I'm not sure whether this will negatively impact our
stability on some of the test nodes though :/


 Richard



> On Wed, Jul 20, 2016 at 4:28 PM Richard Jones <r1chardj0...@gmail.com>
> wrote:
>
>> Hi folks,
>>
>> Sorry I didn't make the meeting this morning :-(
>>
>> We touched on testing at the mid-cycle and again it came up in the
>> meeting this morning. We identified two issues:
>>
>> 1. Our integration test suite cannot grow to too many more tests because
>> they take too long to run (and get auto-killed). We could increase the
>> amount of time allowed for them, but we agreed that we shouldn't do this.
>> 2. We don't have enough higher-level (integration leve) test coverage for
>> our newer angular interfaces.
>>
>> These two are obviously at odds :-)
>>
>> What we agreed on, I think, is that we're going to:
>>
>> 1. Reduce the granularity of the integration tests - use them to broadly
>> test whether an interface works at all when presented to a browser,
>> 2. Replace many single interface tests with a fewer tests that poke at
>> many interfaces (thus removing the significant per-test overhead) - even
>> potentially having a single test that attempts to access every panel (as a
>> guard against gross Javascript incompatibilities or configuration issues
>> breaking panels),
>> 3. Move the integration tests to tempest, and
>> 4. Write some "django unit test suite" functional tests for our angular
>> code that tests more than just the single units we currently test (ie. mock
>> at a more remote level, checking that broader interactions work).
>>
>> Does this sound about right?
>>
>>
>>  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-dev] [Horizon] On testing...

[Richard Jones]

Hi folks,

Sorry I didn't make the meeting this morning :-(

We touched on testing at the mid-cycle and again it came up in the meeting
this morning. We identified two issues:

1. Our integration test suite cannot grow to too many more tests because
they take too long to run (and get auto-killed). We could increase the
amount of time allowed for them, but we agreed that we shouldn't do this.
2. We don't have enough higher-level (integration leve) test coverage for
our newer angular interfaces.

These two are obviously at odds :-)

What we agreed on, I think, is that we're going to:

1. Reduce the granularity of the integration tests - use them to broadly
test whether an interface works at all when presented to a browser,
2. Replace many single interface tests with a fewer tests that poke at many
interfaces (thus removing the significant per-test overhead) - even
potentially having a single test that attempts to access every panel (as a
guard against gross Javascript incompatibilities or configuration issues
breaking panels),
3. Move the integration tests to tempest, and
4. Write some "django unit test suite" functional tests for our angular
code that tests more than just the single units we currently test (ie. mock
at a more remote level, checking that broader interactions work).

Does this sound about right?


 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

Re: [openstack-dev] [Horizon] Angular action services and initScope

[Richard Jones]

On 18 July 2016 at 11:49, Rob Cresswell 
wrote:

> Maybe I'm missing the point, but the schema stuff just defines a model and
> passes it to the schema directive via ctrl; doesn't that remove any issues
> with workflows? ui-bootstraps modal and modalinstance already provides a
> way to pass that data back to the initial location (table etc) again
>

In a nutshell, yes this is the goal I'm aiming for, though some of the
details might vary.


  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

Re: [openstack-dev] [Horizon] Angular action services and initScope

[Richard Jones]

On 18 July 2016 at 11:34, Tripp, Travis S <travis.tr...@hpe.com> wrote:

> TL;DR, I’ll be quite happy to get rid of the need for initScope and like
> exploring a common way to share model other than events.
>
>  |From: Richard Jones <r1chardj0...@gmail.com>
> | Date: Sunday, July 17, 2016 at 6:55 PM
>
> | I think this is a bad idea because in the angular world "factory" means
> singleton
> | (which is totally opposite to what everyone else in the programming
> world [and the rest]
> | thinks "factory" means but hey, angular gonna angular) and we'd be
> changing that, and
> | the potential for confusion would be very high.
>
> | Controllers are already not singletons - I see no reason why mutable
> state shouldn't be |
> | contained in *them*. We don't need to invent something new to hold that
> mutable state.
>
> As FYI, the way I mentioned for factories is *not* inventing something new
> and is how they were intended and even used in angular in that way.  A
> factory is a singleton object whose job is to create instances of objects.
> It is even used that way in angular code. See $cacheFactory [0]
>
> [0]
> https://github.com/angular/angular.js/blob/master/src/ng/cacheFactory.js
>
> The differentiation of .factory vs .service is still obtuse since they are
> both singletons, but the concept of a factory object whether .service or
> .factory still remains.
>

Ah, yep, sorry for the confusion there - what I was getting at is that the
data for doing things is already handled by controllers, so let's use
those, rather than create something new to do it. My grumpiness about
"factory" was a distraction ;-)



> |From: Richard Jones <r1chardj0...@gmail.com>
> | Date: Sunday, July 17, 2016 at 6:55 PM
>
> | But the workflow implementation has no concept of an over-arching model
> for
> | the workflow. If that was changed, I believe all the current $scope
> shenanigans
> |(which are basically about short-circuiting the workflow not doing its
> job ;-) would
> | go away.
>
> The event based mechanism was an attempt originally proposed by Thai to
> get around the essentially hard coded shared model service in launch
> instance where the steps are tightly bound to that model service. There was
> also some idea that some steps could be reusable / recomposable across work
> flows (such as update metadata) if you didn’t tightly bind things.
>

I'd like to call YAGNI here :-)



> |From: Richard Jones <r1chardj0...@gmail.com>
> | Date: Sunday, July 17, 2016 at 6:55 PM
>
> | So, here's my rough thought: workflow.model is an object with properties
> named for
> | each of the workflow steps - using the step formName as the name (hell,
> schema
> | form could probably make this a doddle). The workflow model is passed to
> the
> | controller for each step, which uses its own named model to store the
> data captured
> | by the step - and as a side effect it can poke at (and watch) the data
> captured by other
> | steps, which is often useful. Workflow $modal resolution supplies the
> workflow model
> | for the consumer of the workflow to then to something with all that data.
>
> We’ve roughly talked about a need for something like this for sometime and
> I think it would be great to explore it. It is similar to some of the
> Django workflow concepts.  Effectively, this boils down to steps declaring
> with data they require and which data they provide.  I’d prefer it if we
> can disassociate the step name from the data name.


Quite reasonable to have the data model be named more after the data being
captured in the panel than the step of the panel, yep, but...



> We want to keep the steps from being tightly coupled to each other, but
> rather be declarative about the data they use.  For example, if we later
> want to split out steps (see History of Launch Instance, Chapter 1: Source
> and Details) or want to combine steps (See History of Launch Instance:
> Chapter Boy it would be nice if we could have a quick launch step as the
> first step), it will be easier to do if we don’t couple the model to the
> current presentation.
>

Yeah, this is especially tricky, and I think Launch Instance Quick Launch
is a special snowflake and we shouldn't necessarily make everything else
have to work around it. If we could just define pages of workflows which
have their own model (with SchemaForm models once that lands, but manually
for now) that would solve 80-90% of workflow cases while being much simpler
to implement (not needing a whole separate model definition aside the form
definition).


By the way, yes the ability to watch the data or react to changes in the
> data is definitely useful. For example, in Launch Instance if you increase

Re: [openstack-dev] [Horizon] Angular action services and initScope

[Richard Jones]

TL;DR: we need to fix workflows :-)

On 15 July 2016 at 16:32, Tripp, Travis S <travis.tr...@hpe.com> wrote:

> If we find that there is still a need to send the scope in that can’t be
> reasonably worked around, then the action services could be changed to be a
> factory.


I think this is a bad idea because in the angular world "factory" means
singleton (which is totally opposite to what everyone else in the
programming world [and the rest] thinks "factory" means but hey, angular
gonna angular) and we'd be changing that, and the potential for confusion
would be very high.


The injected action factory should have a factory function called by the
> controller which creates an instance of the action in each controller.


Controllers are already not singletons - I see no reason why mutable state
shouldn't be contained in *them*. We don't need to invent something new to
hold that mutable state.



> Then the init scope could be called on the instance of that action. This
> also would then allow actions to have state that is retained for the
> lifetime of the controller, while not worrying about sharing action state
> with other controllers.
>

I don't believe retaining "init scope" is necessary at all.

As far as I can tell we're already creating an independent context for the
actual meat of the action, we're just not keeping it independent enough. To
demonstrate, I'm going to pull apart one example: images create-volume.

The files for create volume consist of (under
openstack_dashboard/static/app/core/images):

actions/create-volume.service.js
  Is the action fired off when a user hits a "create volume" button.
workflows/create-volume.service.js
  Is the workflow service used in the modal dialog that the above action
service creates.
steps/create-volume/create-volume.html
  Is the single HTML step in the above workflow service.
steps/create-volume/create-volume.controller.js
  Is the controller used in the above HTML step.

Note that the workflow only has one step. I think that's done so plugins
can extend create-volume with additional steps. Regardless, it's the
workflow that's the root of our problems here. Read on... ;-)

The flow through the above code is basically:

1. allow an interface to invoke an action perform() to create a volume
2. open a modal with a form in it to capture the volume details
3. have the service from step 1 invoke an API with the data captured in the
form
4. resolve the action service perform() promise with an ActionResult

The scope usage is needed because the data transfer between the step
controller and the action service is done through an event, VOLUME_CHANGED,
and event passing is done through a scope. Thus the controller and action
service, which are quite independent pieces of code, must have intimate
knowledge of each other's internal operation. I'm not so keen on that ;-)

The event is currently necessary because of the workflow sitting between
the action service and controller. Without it, the controller submit()
handler could resolve the $modal promise with the captured data, which the
action service could consume. What we should be seeing is the workflow
service resolving that $modal promise with the data captured from the
workflow, and that promise resolution going back to the action service.

But the workflow implementation has no concept of an over-arching model for
the workflow. If that was changed, I believe all the current $scope
shenanigans (which are basically about short-circuiting the workflow not
doing its job ;-) would go away.

So, here's my rough thought: workflow.model is an object with properties
named for each of the workflow steps - using the step formName as the name
(hell, schema form could probably make this a doddle). The workflow model
is passed to the controller for each step, which uses its own named model
to store the data captured by the step - and as a side effect it can poke
at (and watch) the data captured by other steps, which is often useful.
Workflow $modal resolution supplies the workflow model for the consumer of
the workflow to then to something with all that data.


 Richard



> From: Richard Jones <r1chardj0...@gmail.com>
> Reply-To: OpenStack List <openstack-dev@lists.openstack.org>
> Date: Friday, July 15, 2016 at 2:28 PM
> To: OpenStack List <openstack-dev@lists.openstack.org>
> Subject: [openstack-dev] [Horizon] Angular action services and initScope
>
> Hi folks,
>
> Something that's been bothering me for a while is that the action services
> break the encapsulation model of Angular Services - that they are
> singletons, and consumable by multiple simultaneous consumers without those
> consumers affecting each other through their use of the Service.
>
> At the moment the initScope() functionality we've included in the action
> services breaks that model - at a minimum it is possible

Re: [openstack-dev] [horizon] Logo

[Richard Jones]

+2 very appropriate

On 17 July 2016 at 11:01, Diana Whitten  wrote:

> Dunno if there have been any suggestions, but I'd like to suggest a Shiba
> Inu for the Horizon logo mascot.
>
> If you unfamiliar with a Shiba Inu, take a look here:
> http://vignette1.wikia.nocookie.net/sanicsource/images/9/97/Doge.jpg/revision/latest?cb=20160112233015
>
> Our Shiba should definitely look shocked too.
>
> - Diana
>
> __
> 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] Angular action services and initScope

[Richard Jones]

Hi folks,

Something that's been bothering me for a while is that the action services
break the encapsulation model of Angular Services - that they are
singletons, and consumable by multiple simultaneous consumers without those
consumers affecting each other through their use of the Service.

At the moment the initScope() functionality we've included in the action
services breaks that model - at a minimum it is possible for multiple
consumers to initScope() with different scopes simultaneously. This is the
reason why I've been arguing (ok, "debating" :-) for the cessation of using
scopes in this way.

I think we need to do two things reasonably soon (before patterns become
more ingrained):

1. Stop passing in $scope to initScope in all cases - the new
ActionResult-enabled pattern should hopefully replace all those
2. Remove all initScope methods altogether. The only other use of initScope
that I see is the pre-loading of data used during the execution of action
allowed() methods. We should move that preloading/caching either into the
creation of the Service object itself, or into the allowed method.

If there is a use-case of initScope that I've missed (something that needs
to be execute *after* the Service is created, not something that needs to
tie the Service to a particular consumer of the service) then please let me
know :-)


 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-dev] [Horizon] xstatic publishing update - broken xstatic-angular-bootstrap

[Richard Jones]

Hi folks,

I released a couple of broken xstatic-angular-bootstrap packages to pypi
yesterday - 0.11.0.4 and 0.11.0.5. There was to be an automated release of
0.11.0.6 through openstack-release, but I've abandoned that as it contained
the same breakage. I've performed an emergency direct upload of 0.11.0.7 to
pypi which fixes the issue, and will propose an automated release of
0.11.0.8 some time this weekend.

Future packages should not run into this sort of issue - the root cause is
a bug in the xstatic-release script, which I'm also going to address and
release as 1.1.2 this weekend.


Sorry for the trouble,

  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-dev] [Horizon] New procedure for releasing xstatic packages

[Richard Jones]

Hi folks,

It's been a lng time coming, but we're almost there. I've put up a BP
outlining the steps we need to get over the line and start releasing those
looong awaited updates of our xstatic packages:

https://blueprints.launchpad.net/horizon/+spec/xstatic-release-process

I'll be working with Tony Breeds and Joshua Hesketh over the next few days
to work through the remaining bits of that BP. Please feel free to review
the BP and the linked changes - in particular the documentation change
which has more detail than the BP:

https://review.openstack.org/#/c/289142

One of the potential gotchas is that we're enforcing that the git tag
version string matches the xstatic package's BUILD version string as part
of the release process (as far as I can tell this is a first for an
OpenStack release process). The downside of this is that you won't know if
it's been rejected unless you sign up to a particular mailing list:

http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures

Well, eventually you'll give up on seeing the package appear in pypi, but
that list is slightly more immediate.


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

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

[Richard Jones]

Thanks, Christopher (and the app-catalog team).

On 21 March 2016 at 08:35, Christopher Aedo <d...@aedo.net> wrote:

> On Sun, Mar 20, 2016 at 1:26 PM, Richard Jones <r1chardj0...@gmail.com>
> wrote:
> > Unfortunately none of this discussion solves the substantive issue which
> is
> > that we cannot release an xstatic package without breaking the gate.
> >
> > We currently have one solution that's a close to viable as we've been
> able
> > to get: move the version pinning for xstatic packages out of
> > upper-constraints and into Horizon's repository, and hope that the
> > app-catalog server and Horizon stay in step or that they're never
> installed
> > on the same debian/redhat system (or if they *are* then one of them is
> > installed in a virtualenv).
>
> The Horizon plugin for the app catalog[1] should have no problem
> staying in step with Horizon.  Ultimately our intention is to make
> this plugin so desirable it becomes a native part of Horizon so
> enabling in a cloud becomes as simple as a config switch.  We're not
> ready for that yet of course, so please don't let that comment
> distract the thread :)  I am looking forward to discussing this with
> more people in Austin though!
>
> Regardless, we will work with you to make sure our efforts proceed to
> be tightly coupled to Horizon.  This approach makes the most sense to
> me.
>
> [1]: http://git.openstack.org/cgit/openstack/app-catalog-ui/
>
> -Christopher
>
> __
> 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] How do we move forward with xstatic releases?

[Richard Jones]

Unfortunately none of this discussion solves the substantive issue which is
that we cannot release an xstatic package without breaking the gate.

We currently have one solution that's a close to viable as we've been able
to get: move the version pinning for xstatic packages out of
upper-constraints and into Horizon's repository, and hope that the
app-catalog server and Horizon stay in step or that they're never installed
on the same debian/redhat system (or if they *are* then one of them is
installed in a virtualenv).


 Richard


On 17 March 2016 at 19:00, Thomas Goirand <z...@debian.org> wrote:

> On 03/17/2016 07:23 AM, Richard Jones wrote:
> > There's a basic difference here though. Your traditional "installed
> > components" are pieces of software and data used *by programs on that
> > system.*
> >
> > The components we're talking about here are, as far as the system is
> > concerned, opaque data to be transmitted over HTTP(S) to a web browser
> > client which then makes use of that data in some manner.
> >
> > There are no cross-program compatibility issues stemming from having
> > multiple different versioned copies of such client-side files on a
> > system
>
> The same way, we could have multiple version of fonts, tzdata, SSL root
> certificates and so on. There wouldn't be any compatibility issues.
> Though it's still not the right thing to do at a distribution level.
>
> Have you noticed also that in the Windows world, each program carries
> its .dll, which are supposed to be shared object, but in fact, they
> aren't shared? Yes, it is easier to do so.
>
> > - this is why the web development world has standardised on
> > tooling that *makes it easy to do so*. Different client-side web
> > applications *should* be able to use different versions of components.
>
> The same was as for shared .so libraries, that's not the correct way to
> do things. Even though the JavaScript objects aren't executed by the
> system (well, if we forget that nodejs exists), there's still potential
> bugs and security problems with them, and they may require maintenance.
>
> > xstatic shoe-horns that freedom of client-side application component
> > usage into a one-size-must-fit-all world that fundamentally only exists
> > because programs on a system can get confused when multiple versions are
> > installed on that system[1].
>
> I wouldn't say it this way. To me, they are just tools which makes it
> easy for us to stop the duplication madness of the same files.
>
> Have a look:
> # apt-file search jquery.js | grep -v doc | wc -l
> 128
>
> This is 127 bugs which should be fixed currently with the embedded
> jquery. I hardly see how one could argue this is a good thing. I hope we
> can be better citizens than this.
>
> Cheers,
>
> Thomas Goirand (zigo)
>
>
> __
> 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] How do we move forward with xstatic releases?

[Richard Jones]

On 13 March 2016 at 07:06, Matthias Runge <mru...@redhat.com> wrote:

> On 10/03/16 08:46, Richard Jones wrote:
> > On 10 March 2016 at 18:23, Matthias Runge <mru...@redhat.com
> > <mailto:mru...@redhat.com>> wrote:
> >
> > 4.alt.2:
> > move to proper packages for static file management. I mean, they
> need to
> > be built anyways.
> >
> >
> > Please define what you mean by "proper packages" here. I *think* you
> > might mean system packages (aka Debian or Red Hat) which is not feasible
> > given other environments that Horizon runs under. Please correct me if
> > I'm wrong!
>
> Exactly. I mean system packages. If there are issues with system
> packages, then let's address the issue rather than re-inventing the wheel.
>

OK, the sticking point is that installation through system packages alone
forces us to make all software on a system work with a single version of
any given library. This has spawned the global-requirements and now
upper-constraints systems in OpenStack, and ultimately leads to the
problematic race condition that resulted in me starting this email thread.
That is, we can update *either* the version of a library being used *or*
the software that is compatible with that version *but not the two at the
same time, atomically*.



> Weren't we just talking about providing dependencies for the gate?


Well, partially, because the reason the problem surfaces is because of the
Continuous Deployment guarantee that OpenStack makes, which is enforced by
the gate, so sure, let's say it's the gate's fault 



> I mean, for production, it's quite the same situation we are at the
> moment. Nobody requires you to install Horizon and dependencies
> especially via rpm, deb or pip: Take what you want.
>

I'm not sure it's this simple, is it? Folks want to be able to install
OpenStack from a single source, and that seems reasonable. They want to be
able to do that "offline" too, so that rules out bower as a source of
packages.



> > It has been mentioned, xstatic packages can block the gate. We
> currently
> > control xstatic package releases, thus we can roll back, if something
> > goes wrong.
> >
> > If we're pulling directly with npm/bower, someone from the outside
> can
> > break us. We already have the situation with pypi packages.
> > With proper packages, we could even use the gate to release those
> > packages and thus verify, we're not breaking anyone.
> >
> >
> > We're going to have potential breakage (gate breakage, in the integrated
> > tests) any time we release a package (regardless of release mechanism)
> > and have to update two separate repositories resulting in out-of-sync
> > version specification and expectation (ie. upper-constraints
> > specification and Horizon's code expectation) as described in my OP. The
> > only solution that we're aware of is to synchronise updating those two
> > things, through one of the mechanisms proposed so far (or possibly
> > through a mechanism not yet proposed.)
> >
>
> Yes, and my proposal to address this is to gate updating/releasing
> dependencies the same way we're currently gating each change in horizon.
>

This is not going to solve the race condition I mention; it's actually
during our work implementing gating these releases that we found we had to
solve this problem.



> > 1. Horizon maintains its own constrained version list for the xstatic
> > packages,
> > 2. Plugins to Horizon must depend on Horizon to supply xstatic packages
> > except where they use additional packages that Horizon does not use, and
> > 3. We avoid installing app-catalog (the system, not the plugin) in the
> > integrated tests (I don't believe doing this is even on the ...
> > "horizon" so to speak) *or* in a Debian / Red Hat (i.e. system-packaged)
> > system that also has Horizon installed. Or we try to convince
> > app-catalog to stay lock-step with Horizon's xstatic versions. I
> > understand the risk of a collision between app-catalog and Horizon in
> > the same system-packaged environment is very low.
>
> I don't really see a chance for app-catalog to require Horizon as a
> dependency and different versions of xstatic packages. This would be an
> immediate show-stopper for app-catalog either on Debian or on RPM based
> systems.
>

I think I used the wrong word above. Where I said "system" I probably
should have said "server". app-catalog the stand-alone server should not
depend on Horizon, just app-catalog the plugin to Horizon should (like all
Horizon plugins should).



> Let me repeat myself: you're free to install dependencies 

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

[Richard Jones]

On 14 March 2016 at 11:08, Thomas Goirand  wrote:
>
> From a distribution package maintainer perspective, the most annoying
> part is that there's no easy way to get the web app use the JS libs from
> the OS, and there's no system wide registry of installed components.
>

There's a basic difference here though. Your traditional "installed
components" are pieces of software and data used *by programs on that
system.*

The components we're talking about here are, as far as the system is
concerned, opaque data to be transmitted over HTTP(S) to a web browser
client which then makes use of that data in some manner.

There are no cross-program compatibility issues stemming from having
multiple different versioned copies of such client-side files on a system -
this is why the web development world has standardised on tooling that
*makes it easy to do so*. Different client-side web applications *should*
be able to use different versions of components.

xstatic shoe-horns that freedom of client-side application component usage
into a one-size-must-fit-all world that fundamentally only exists because
programs on a system can get confused when multiple versions are installed
on that system[1].


Richard

[1] I note that OS X packaging solved that problem too, but let's not go
there 
__
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][infra] revert new gerrit

[Richard Jones]

On 19 March 2016 at 02:35, Monty Taylor  wrote:

> On 03/18/2016 08:31 AM, Andrey Kurilin wrote:
>
>> Hi all!
>>
>> I want to start this thread because I'm tired. I spent a lot of time,
>> but I can't review as easy as it was with old interface. New Gerrit is
>> awful. Here are several issues:
>>
>> * It is not possible to review patches at mobile phone. "New" "modern"
>> theme is not adopted for small screens.
>> * Leaving comments is a hard task. Position of page can jump anytime.
>> * It is impossible to turn off hot-keys. position of page changed->I
>> don't see that comment pop-up is closed->continue type several
>> letters->make unexpected things(open edit mode, modify something, save,
>> exit...)
>> * patch-dependency tree is not user-friendly
>> * summary table doesn't include status of patch(I need list to the end
>> of a page to know if patch is merged or not)
>> * there is no button "Comment"/"Reply" at the end of page(after all
>> comments).
>> * it is impossible to turn off "new" search mechanism
>>
>> Does it possible to return old, classic theme? It was a good time when
>> we have old and new themes together...
>>
>
> Sadly no. Upstream is pretty tied to the new very terrible interface.
> We're not sure why.
>
> If you haven't tried gertty yet, I highly recommend it.
>

I hear good things about it but I've tried to get gertty going and found it
doesn't cope well at all with my very low bandwidth Internet connection, so
it's definitely not a solution for everyone :-(

I hold out hope for a usable web ui some day ;-)


 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

Re: [openstack-dev] [Horizon] Javascript linting and documentation

[Richard Jones]

On 11 March 2016 at 04:37, Michael Krotscheck  wrote:

> On Wed, Mar 9, 2016 at 12:45 PM Tripp, Travis S 
> wrote:
>
>> The problem is that the warnings are so great that is really hard to read.
>>
>
> If all the warnings were fixed - I know Matt Borland's working on that -
> would we be having this conversation?
>

My position was that I didn't want Matt to waste his valuable time editing
a bunch of JSDoc when we might end up having to go through and re-edit it
to some other form. We've busy enough with Mitaka release issues during
these weeks without needing to be bothered by fixing ignorable some jsdoc
lint warnings (and they are ignorable - nothing currently cares about the
syntax of our Javascript comments *except* the linter).


 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

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

[Richard Jones]

On 13 March 2016 at 07:11, Matthias Runge  wrote:

> On 10/03/16 11:48, Beth Elwell wrote:
> > If we will anyway have potential breakage I don’t understand why the
> > better solution here would not be to just use the bower and npm tools
> > which are standardised for JavaScript and would move Horizon more
> > towards using widely recognised tooling from within not just Openstack
> > but the wider development community. Back versions always need to be
> > supported for a time, however I would add that long term this could end
> > up saving time and create a stable longer term solution.
> >
>
> I have a few issues with those "package managers":
> - downloads are not verified, there is a chance of getting a "bad"
> download.
> - they are pointing to the outside world, like to github etc. While they
> appear to work "most of the time", that might not good enough for the gate
> - how often have we been blocked by releases of software not managed by
> OpenStack? Seriously, that happens quite a few times over a release
> cycle, not to mention breakages by releases of our own tools turning out
> to block one or the other sub-project


To be fair to those package managers,  the issues OpenStack has had with
releases of libraries breaking things is a result of us either:

a) not pinning releases (upper-constraints now fixes that for *things that
use it*, which isn't everything, sadly) or
b) the system that tests upper-constraints changes not having broad enough
testing across OpenStack for us to notice when a new library release breaks
things. I would like to increase the inclusion of Horizon's test suite in
the constraints testing for this reason. At least, it's on my TODO :-)

Horizon, for example, currently does *not* use the upper-constraints
pinning in its test suite or installation, so we're vulnerable to, say, a
python-*client release that's not compatible. I have a patch in the works
to address this, but it kinda depends on us moving over from run_tests.sh
to tox, which is definitely something to wait until N for.


 Richard

ps. as for "unverified downloads" ... they're verified precisely as much as
pypi packages are, and we install a whole buncha those :-)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] PTL noncandidacy

[Richard Jones]

Thanks for everything David. My involvement and engagement with the project
would not be what it is without your leadership. I look forward to
continuing to work with and learn from you!


   Richard

On 12 March 2016 at 04:19, David Lyle  wrote:

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

[Richard Jones]

On 10 March 2016 at 21:48, Beth Elwell <e.r.elw...@gmail.com> wrote:
>
> On 10 Mar 2016, at 07:46, Richard Jones <r1chardj0...@gmail.com> wrote:
>
>> It has been mentioned, xstatic packages can block the gate. We currently
>> control xstatic package releases, thus we can roll back, if something
>> goes wrong.
>>
>> If we're pulling directly with npm/bower, someone from the outside can
>> break us. We already have the situation with pypi packages.
>> With proper packages, we could even use the gate to release those
>> packages and thus verify, we're not breaking anyone.
>>
>
> We're going to have potential breakage (gate breakage, in the integrated
> tests) any time we release a package (regardless of release mechanism) and
> have to update two separate repositories resulting in out-of-sync version
> specification and expectation (ie. upper-constraints specification and
> Horizon's code expectation) as described in my OP. The only solution that
> we're aware of is to synchronise updating those two things, through one of
> the mechanisms proposed so far (or possibly through a mechanism not yet
> proposed.)
>
> If we will anyway have potential breakage I don’t understand why the
> better solution here would not be to just use the bower and npm tools which
> are standardised for JavaScript and would move Horizon more towards using
> widely recognised tooling from within not just Openstack but the wider
> development community. Back versions always need to be supported for a
> time, however I would add that long term this could end up saving time and
> create a stable longer term solution.
>

I (and others) have argued several times for this, for a number of reasons,
and it remains my preferred solution, but it has been shot down many times
:-(

There are three major hurdles that I recall (sorry if I forgot any, it's
getting late here):

1. system packaging; installers using Debian or Red Hat (completely
offline) installation will not be able to install Horizon. We don't have a
solution for this though various caching mechanisms have been proposed.
2. security; the bower installation mechanism is seen as being very
insecure - not that I would call the current xstatic mechanism secure. It's
all down to degrees, I suppose.
3. installation in the gate; I believe that currently installation from
bower would not be possible in the gate. This is pretty closely related to
#1.

I think I recall licensing came up at one point too, but I might be
mis-remembering.


  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

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

[Richard Jones]

On 10 March 2016 at 18:23, Matthias Runge  wrote:
>
> 4.alt.2:
> move to proper packages for static file management. I mean, they need to
> be built anyways.
>

Please define what you mean by "proper packages" here. I *think* you might
mean system packages (aka Debian or Red Hat) which is not feasible given
other environments that Horizon runs under. Please correct me if I'm wrong!



> It has been mentioned, xstatic packages can block the gate. We currently
> control xstatic package releases, thus we can roll back, if something
> goes wrong.
>
> If we're pulling directly with npm/bower, someone from the outside can
> break us. We already have the situation with pypi packages.
> With proper packages, we could even use the gate to release those
> packages and thus verify, we're not breaking anyone.
>

We're going to have potential breakage (gate breakage, in the integrated
tests) any time we release a package (regardless of release mechanism) and
have to update two separate repositories resulting in out-of-sync version
specification and expectation (ie. upper-constraints specification and
Horizon's code expectation) as described in my OP. The only solution that
we're aware of is to synchronise updating those two things, through one of
the mechanisms proposed so far (or possibly through a mechanism not yet
proposed.)


I think that David's proposal is the only really feasible approach at this
time:

1. Horizon maintains its own constrained version list for the xstatic
packages,
2. Plugins to Horizon must depend on Horizon to supply xstatic packages
except where they use additional packages that Horizon does not use, and
3. We avoid installing app-catalog (the system, not the plugin) in the
integrated tests (I don't believe doing this is even on the ... "horizon"
so to speak) *or* in a Debian / Red Hat (i.e. system-packaged) system that
also has Horizon installed. Or we try to convince app-catalog to stay
lock-step with Horizon's xstatic versions. I understand the risk of a
collision between app-catalog and Horizon in the same system-packaged
environment is very low.


 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

Re: [openstack-dev] [Horizon] Javascript linting and documentation

[Richard Jones]

On 10 March 2016 at 06:49, Michael Krotscheck  wrote:

> I guess I don't see what problems is being solved by turning the rule off,
> and I also don't see the harm in having more check. It does generate a lot
> of warnings, but invoking `npm run lint -- --quiet` gets rid of those.
>

We already have a "lintq" npm task that does this, which most of us use.
The problem is that we then ignore all the legitimate code linting warnings.


Also, from my experience, sphinx-based doc builds are notoriously
> permissive about bad formatting. Eslint's stricter jsdoc checks would add
> an additional safety net.
>

My perspective on this is if the documentation builder can produce
documentation that is useful then it's enforcing exactly enough checks on
the input. For example, the jsdoc linter currently forces us to write
@returns statements in our docs for angular methods that have no return
value, and never will (i.e. module.config()) or is otherwise not exposed to
developers and not interesting (i.e. the return from service or controller
construction). I mentioned this in passing in the meeting, but most of our
JS documentation has been written to ngdoc syntax, and that's potentially a
good thing since it provides much greater hinting to the doc generators
about how to present and organise the output, but also influences things
like @returns usefulness. We just have to find the right tool (or, more
likely, create, since I've been looking for a while and haven't found a
suitable tool) that uses the information we're coding into our comments.



> However, if you're working on this with the docs team, then the result
> should be applicable to the entirety of openstack - meaning that once your
> work is complete, it may make sense to turn the rule off globally.
>

Yep!


 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

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

[Richard Jones]

Hi Serg,

There's a crucial difference: getting the solution to this wrong for
Horizon will break the gate for all OpenStack projects. Updating an xstatic
package that a plugin uses has no side-effect outside of the plugin.


  Richard

On 10 March 2016 at 02:43, Serg Melikyan  wrote:

> >This is exactly my first thought. The plugins *must* depend on Horizon,
> and they have to use the same versions of XStatic packages anyways, so why
> specify the dependencies twice?
>
> Plugins may require different xstatic library, which is not even used
> by Horizon. Issue raised by Richard exists for plugins too, not only
> for Horizon itself.
>
>
> On Wed, Mar 9, 2016 at 12:24 AM, Radomir Dopieralski
>  wrote:
> > On 03/08/2016 11:43 PM, David Lyle wrote:
> >
> >> 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.
> >
> >
> > This is exactly my first thought. The plugins *must* depend on Horizon,
> > and they have to use the same versions of XStatic packages anyways, so
> > why specify the dependencies twice? If the changes between versions are
> > so big as to be breaking, then the plugins have to be updated to work
> > with the new Horizon anyways.
> >
> > --
> > Radomir Dopieralski
> >
> >
> >
> >
> __
> > 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
>
>
>
> --
> Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
> http://mirantis.com | smelik...@mirantis.com
>
> +1 (650) 440-8979
>
> __
> 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] Javascript linting and documentation

[Richard Jones]

Hey all,

I started looking into fixing the wall of "npm run lint" warnings today and
quickly noticed that about 85% of the "linting" warnings were about jsdoc.
We have significant issues around jsdoc anyway and we're supposed to be
using Sphinx anyway[1].

Some Horizon folks will know that I've been investigating generating
publishable documentation for our Javascript code for some time. Most of
the tools either don't work (dgeni) or produce pretty unusable output for a
project our size (jsdoc and grunt-ngdocs). I am about to investigate Sphinx
in collaboration with the docs team.

Regardless, I believe that the documentation generation should generate
errors about that documentation, not the code linter. Once we actually get
a documentation generator going. Until then, we don't even know what syntax
the documentation should follow.

I've proposed a change which just turns jsdoc "linting" off[2]. At the
moment, it is less than useful (the noise drowns out any other, legitimate
linting).


 Richard


[1] http://governance.openstack.org/reference/cti/javascript-cti.html
[2] https://review.openstack.org/#/c/290235/
__
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?

[Richard Jones]

But Jeremy: Atomic Zuul. How cool is that name.


So I know I'm going to potentially get yelled at for voicing this, but what
are the chances that app-catalog and Horizon are ever installed on the same
system? That is, could it have its own xstatic constraints, with the
promise that the two constraints will never meet in a dark alley behind
some VM somewhere? app-catalog isn't in the integrated tests, so it's never
going to break the gate like Horizon will...


On 9 March 2016 at 11:07, Jeremy Stanley <fu...@yuggoth.org> wrote:

> On 2016-03-08 17:25:41 +1100 (+1100), Richard Jones wrote:
> [...]
> > SOLUTION 6 - make zuul capable of performing atomic cross-repository
> > commits.
>
> This seems unlikely to happen, as it's very much counter to Zuul's
> designed-in reliance on serializing changes to test before merging
> them.
> --
> Jeremy Stanley
>
> __
> 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 Diana Whitten to horizon-core

[Richard Jones]

+1 we need Diana's perspective, knowledge and enthusiasm

On 9 March 2016 at 10:03, Tripp, Travis S  wrote:

> +1, no questions asked. It is rare to find somebody with the passion that
> Diana has shown.
>
> From: Lin Hua Cheng >
> Reply-To: OpenStack List >
> Date: Tuesday, March 8, 2016 at 3:48 PM
> To: OpenStack List >
> Subject: Re: [openstack-dev] [horizon] Proposal to add Diana Whitten to
> horizon-core
>
> big +1 from me.
>
> She made a lot of contribution in making theming better for horizon and
> also prevented potential issues through reviews.
> Thanks for all the hard work, Diana.
>
> -Lin
>
> On Tue, Mar 8, 2016 at 2:06 PM, David Lyle > wrote:
> 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

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

[Richard Jones]

Two things I forgot to mention:

Currently there is another break point in the diagram of releases when X1
is released. Currently Horizon does not use upper-constraints and thus will
immediately pick up the new xstatic release file, potentially breaking
things. This is easy to fix - I will be proposing a patch soon.

SOLUTION 6 - make zuul capable of performing atomic cross-repository
commits.

Richard

Sent from my portable device, please excuse the brevity.
On 8 Mar 2016 15:52, "Richard Jones" <r1chardj0...@gmail.com> 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:
>
> 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
>
> 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.
>
> SOLUTION 4: vendor the javascript
>
> Heh.
>
> 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.
>
> 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

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

[Richard Jones]

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:

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

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.

SOLUTION 4: vendor the javascript

Heh.

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.

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

Re: [openstack-dev] [Horizon] Blueprints for Outreachy internship

[Richard Jones]

Hi Sayali,

Sorry I missed your original message, and thanks Matthias for responding.
Indeed the new Swift UI is currently being merged. Some of those blueprints
you list are things I'd like to see once the basic reimplementation is
landed. Select-all is already in the new version though (though we'd like
to see hotkey support in there). There's also a bunch of good work done by
the OpenStack UX team on the interface - changes that we'll look at rolling
in during the N cycle. My wishlist (also my TODO list), which doesn't have
blueprints yet, includes:

- https://github.com/chieffancypants/angular-hotkeys for cmd/ctrl-a
select-all
- https://github.com/danialfarid/ng-file-upload
- Recursive delete of folders
- replacing SimpleModals with bootstrap modals
- Support for >10k objects, most likely requiring Searchlight
- Support for >1k containers (filtering)
- Switch to action registry
- Implement UX’s design ideas
- Copy / rename of objects


  Richard

On 2 March 2016 at 00:07, Matthias Runge  wrote:

> On 29/02/16 12:41, Sayali Lunkad wrote:
> > Hi Matthias,
> >
> > Thanks for the links to the blueprints. I in fact did checkout the list
> > of bps earlier but I found many of them have not been approved yet. I
> > can give you a list of bps I would like to mentor for, from which we
> > could perhaps select one or two for the internship program depending on
> > which of these can be approved.
>
>
> Hey Sayali,
>
> >
> > Here is the list:
> >
> https://blueprints.launchpad.net/horizon/+spec/enable-download-multiple-objects
> > 
>
>
> Swift interface is currently changing quite quickly, see
> https://review.openstack.org/#/c/258769/ and related.
>
>
>
> >
> https://blueprints.launchpad.net/horizon/+spec/horizon-multiple-objects-uploading
> > 
>
> Same here, it's Horizon's swift interface, which changes right now.
> >
> https://blueprints.launchpad.net/horizon/+spec/horizon-reports-in-different-formats
> > 
>
> This is something, which still requires discussion; I strongly believe,
> Horizon is not a reporting tool at all.
>
> > https://blueprints.launchpad.net/horizon/+spec/swift-direct-upload
> > 
> Swift, same as above
>
>
> > https://blueprints.launchpad.net/horizon/+spec/instance-backup
> > 
>
> I'd support the idea, the blueprint is a bit thin, I would expect this
> to be implemented quickly.
>
>
> >
> https://blueprints.launchpad.net/horizon/+spec/select-all-checkbox-object-containers
>
> Swift, see above
>
>
> > https://blueprints.launchpad.net/horizon/+spec/per-user-limit-summary
>
> This is something, one could implement, yes. Still the blueprint is a
> bit thin though.
>
> Best,
> Matthias
>
> __
> 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] Testing of angular promise based code paths

[Richard Jones]

Hi all,

I've just added a comment to a review and I think I'd like to ask for a
broader discussion of whether I'm correct.

The review is here: https://review.openstack.org/#/c/284857/2

It boils down to: when testing code that uses a promise, should we *use* a
promise to have the follow-on callback invoked, or should we mock/spy and
then manually perform the same action the promise would if resolved?

The two forms are, broadly, pretending that a promise fired:

  it('successful submit calls the successCallback', function() {
*var successFunc = {success: angular.noop};*
*spyOn(successFunc, 'success');*
spyOn(nova, 'createKeypair')*.and.returnValue(successFunc);*
spyOn(toastService, 'add').and.returnValue({ add: angular.noop });
ctrl.submit();
*var successCallback = successFunc.success.calls.argsFor(0)[0];*
*var data = {name: 'newKeypair'};*
*successCallback(data);*
expect(toastService.add).toHaveBeenCalledWith(
'success',
'Successfully imported key pair newKeypair.'
);
  });

or actually using a promise and making it fire:

it('should load container contents', function test() {
  *var deferred = $q.defer();*
  spyOn(swiftAPI, 'getObjects')*.and.returnValue(deferred.promise);*
  service.selectContainer('spam');
  expect(service.containerName).toEqual('spam');
  expect(swiftAPI.getObjects).toHaveBeenCalledWith('spam', {delimiter:
'/'});
  *deferred.resolve({data: {items: ['two', 'items']}});*
  *$rootScope.$apply();*
  expect(service.objects).toEqual(['two', 'items']);
  expect(service.pseudo_folder_hierarchy).toEqual([]);
});


 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-dev] [Horizon] eslint without color?

[Richard Jones]

I'm just curious why our eslint configuration (in packages.json) specifies
--no-color. It's much harder to spot the errors without color, and I always
end up running it manually to get the color. Also, karma output has color,
so why one and not the other?

In short, would anyone object to turning color on for eslint?


 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