Re: [openstack-dev] [Horizon] eslint without color?

[Jason Rist]

On 02/14/2016 10:45 PM, Richard Jones wrote:
> 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
>
I thought I've seen some color-related characters get parsed incorrectly 
before.  Perhaps it is related to that?

-J

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

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

[openstack-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

[openstack-dev] [Horizon]horizon angular network QoS panel

[masco]

Hello All,

As most of you people knows the 'QoS' feature is added in neutron during 
liberty release.
It will be nice to have this feature in horizon, so I have added a 
'network qos' panel for the same in angularJS.
It will be very helpful if you people reviewing this patches and helping 
to land this feature in horizon.


_gerrit links:_

https://review.openstack.org/#/c/247997/
https://review.openstack.org/#/c/259022/11
https://review.openstack.org/#/c/272928/4
https://review.openstack.org/#/c/277743/3


_To set test env:_
here is some steps how to enable a QoS in neutron.
If you want to test it will help you.

To enable the QoS in devstack please add below two lines in the 
local.conf enable_plugin neutron 
git://git.openstack.org/openstack/neutron enable_service q-qos and 
rebuild your stack (./stack.sh)


Thanks,
Masco.


__
OpenStack Development Mailing 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] Recent integration tests failures

[Timur Sufiev]

Okay, with https://review.openstack.org/#/c/276123/ finally merged tests
should pass more predictably now. Please, recheck and reverify your patches
now. I hope that recheck/reverify alone is enough to consume merged test
fix, if I'm wrong please correct me.

On Thu, Feb 4, 2016 at 5:46 PM Timur Sufiev  wrote:

> That has been a hard week for integration tests, as soon as API-breaking
> change in xvfbwrapper had been worked around, we have been hit by a new
> Selenium release, see https://bugs.launchpad.net/horizon/+bug/1541876
>
> Investigation of a root cause is still in progress.
>
> On Mon, Feb 1, 2016 at 11:31 PM Richard Jones 
> wrote:
>
>> Ugh, dependencies with breaking API changes in minor point releases :/
>>
>> On 2 February 2016 at 04:53, Timur Sufiev  wrote:
>>
>>> Maintainers of outside dependencies continue to break our stuff :(. New
>>> issue is https://bugs.launchpad.net/horizon/+bug/1540495 patch is
>>> currently being checked by Jenkins
>>>
>>> On Sat, Jan 30, 2016 at 2:28 PM Timur Sufiev 
>>> wrote:
>>>
 Problematic Selenium versions have been successfully excluded from
 Horizon test-requirements, if you still experiencing the error described
 above, rebase your patch onto the latest master.
 On Fri, 29 Jan 2016 at 12:36, Itxaka Serrano Garcia 
 wrote:

> Can confirm, had the same issue locally, was fixed after a downgrade to
> selenium 2.48.
>
>
> Good catch!
>
> Itxaka
>
> On 01/28/2016 10:08 PM, Timur Sufiev wrote:
> > According to the results at
> > https://review.openstack.org/#/c/273697/1 capping Selenium to be not
> > greater than 2.49 fixes broken tests. Patch to global-requirements is
> > here: https://review.openstack.org/#/c/273750/
> >
> > On Thu, Jan 28, 2016 at 9:22 PM Timur Sufiev  > > wrote:
> >
> > Hello, Horizoneers
> >
> > You may have noticed recent integration tests failures seemingly
> > unrelated to you patches, with a stacktrace like:
> > http://paste2.org/2Hk9138U I've already filed a bug for that,
> > https://bugs.launchpad.net/horizon/+bug/1539197 Appears to be a
> > Selenium issue, currently investigating it.
> >
> >
> >
> >
> >
> __
> > OpenStack Development Mailing 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

Re: [openstack-dev] [Horizon] Recent integration tests failures

[Timur Sufiev]

That has been a hard week for integration tests, as soon as API-breaking
change in xvfbwrapper had been worked around, we have been hit by a new
Selenium release, see https://bugs.launchpad.net/horizon/+bug/1541876

Investigation of a root cause is still in progress.

On Mon, Feb 1, 2016 at 11:31 PM Richard Jones 
wrote:

> Ugh, dependencies with breaking API changes in minor point releases :/
>
> On 2 February 2016 at 04:53, Timur Sufiev  wrote:
>
>> Maintainers of outside dependencies continue to break our stuff :(. New
>> issue is https://bugs.launchpad.net/horizon/+bug/1540495 patch is
>> currently being checked by Jenkins
>>
>> On Sat, Jan 30, 2016 at 2:28 PM Timur Sufiev 
>> wrote:
>>
>>> Problematic Selenium versions have been successfully excluded from
>>> Horizon test-requirements, if you still experiencing the error described
>>> above, rebase your patch onto the latest master.
>>> On Fri, 29 Jan 2016 at 12:36, Itxaka Serrano Garcia 
>>> wrote:
>>>
 Can confirm, had the same issue locally, was fixed after a downgrade to
 selenium 2.48.


 Good catch!

 Itxaka

 On 01/28/2016 10:08 PM, Timur Sufiev wrote:
 > According to the results at
 > https://review.openstack.org/#/c/273697/1 capping Selenium to be not
 > greater than 2.49 fixes broken tests. Patch to global-requirements is
 > here: https://review.openstack.org/#/c/273750/
 >
 > On Thu, Jan 28, 2016 at 9:22 PM Timur Sufiev  > wrote:
 >
 > Hello, Horizoneers
 >
 > You may have noticed recent integration tests failures seemingly
 > unrelated to you patches, with a stacktrace like:
 > http://paste2.org/2Hk9138U I've already filed a bug for that,
 > https://bugs.launchpad.net/horizon/+bug/1539197 Appears to be a
 > Selenium issue, currently investigating it.
 >
 >
 >
 >
 >
 __
 > OpenStack Development Mailing 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][Monasca] Launching Graphana UI from Monitoring tab in Monasca plugin for Horizon

[Pradip Mukhopadhyay]

Hello,


We followed the https://github.com/openstack/monasca-ui/ to integrate the
plugin for Horizon. The Monitoring tab is coming in left side navigation
perfectly and working as expected. Only problem is: when we're trying to
launch the Graphana UI, it is failing with the following trace:


Page not found (404)
Request Method: GET
Request URL: http://10.74.150.152:8000/grafana/index.html

Using the URLconf defined in openstack_dashboard.urls, Django tried these
URL patterns, in this order:

   1. ^$ [name='splash']
   2. ^api/
   3. ^home/$ [name='user_home']
   4. ^i18n/js/(?P\S+?)/$ [name='jsi18n']
   5. ^i18n/setlang/$ [name='set_language']
   6. ^i18n/
   7. ^jasmine-legacy/$ [name='jasmine_tests']
   8. ^jasmine/.*?$
   9. ^identity/
   10. ^admin/
   11. ^developer/
   12. ^project/
   13. ^settings/
   14. ^monitoring/
   15. ^auth/
   16. ^static\/(?P.*)$
   17. ^media\/(?P.*)$
   18. ^500/$

The current URL, grafana/index.html, didn't match any of these.



Any pointer of how to solve it, if any, would be highly appreciated.




Thanks in advance,
Pradip
__
OpenStack Development Mailing 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] Recent integration tests failures

[Richard Jones]

Ugh, dependencies with breaking API changes in minor point releases :/

On 2 February 2016 at 04:53, Timur Sufiev  wrote:

> Maintainers of outside dependencies continue to break our stuff :(. New
> issue is https://bugs.launchpad.net/horizon/+bug/1540495 patch is
> currently being checked by Jenkins
>
> On Sat, Jan 30, 2016 at 2:28 PM Timur Sufiev  wrote:
>
>> Problematic Selenium versions have been successfully excluded from
>> Horizon test-requirements, if you still experiencing the error described
>> above, rebase your patch onto the latest master.
>> On Fri, 29 Jan 2016 at 12:36, Itxaka Serrano Garcia 
>> wrote:
>>
>>> Can confirm, had the same issue locally, was fixed after a downgrade to
>>> selenium 2.48.
>>>
>>>
>>> Good catch!
>>>
>>> Itxaka
>>>
>>> On 01/28/2016 10:08 PM, Timur Sufiev wrote:
>>> > According to the results at
>>> > https://review.openstack.org/#/c/273697/1 capping Selenium to be not
>>> > greater than 2.49 fixes broken tests. Patch to global-requirements is
>>> > here: https://review.openstack.org/#/c/273750/
>>> >
>>> > On Thu, Jan 28, 2016 at 9:22 PM Timur Sufiev >> > > wrote:
>>> >
>>> > Hello, Horizoneers
>>> >
>>> > You may have noticed recent integration tests failures seemingly
>>> > unrelated to you patches, with a stacktrace like:
>>> > http://paste2.org/2Hk9138U I've already filed a bug for that,
>>> > https://bugs.launchpad.net/horizon/+bug/1539197 Appears to be a
>>> > Selenium issue, currently investigating it.
>>> >
>>> >
>>> >
>>> >
>>> >
>>> __
>>> > OpenStack Development Mailing List (not for usage questions)
>>> > Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] Recent integration tests failures

[Timur Sufiev]

Maintainers of outside dependencies continue to break our stuff :(. New
issue is https://bugs.launchpad.net/horizon/+bug/1540495 patch is currently
being checked by Jenkins

On Sat, Jan 30, 2016 at 2:28 PM Timur Sufiev  wrote:

> Problematic Selenium versions have been successfully excluded from Horizon
> test-requirements, if you still experiencing the error described above,
> rebase your patch onto the latest master.
> On Fri, 29 Jan 2016 at 12:36, Itxaka Serrano Garcia 
> wrote:
>
>> Can confirm, had the same issue locally, was fixed after a downgrade to
>> selenium 2.48.
>>
>>
>> Good catch!
>>
>> Itxaka
>>
>> On 01/28/2016 10:08 PM, Timur Sufiev wrote:
>> > According to the results at
>> > https://review.openstack.org/#/c/273697/1 capping Selenium to be not
>> > greater than 2.49 fixes broken tests. Patch to global-requirements is
>> > here: https://review.openstack.org/#/c/273750/
>> >
>> > On Thu, Jan 28, 2016 at 9:22 PM Timur Sufiev > > > wrote:
>> >
>> > Hello, Horizoneers
>> >
>> > You may have noticed recent integration tests failures seemingly
>> > unrelated to you patches, with a stacktrace like:
>> > http://paste2.org/2Hk9138U I've already filed a bug for that,
>> > https://bugs.launchpad.net/horizon/+bug/1539197 Appears to be a
>> > Selenium issue, currently investigating it.
>> >
>> >
>> >
>> >
>> >
>> __
>> > OpenStack Development Mailing 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] Django

[Pavel Karikh]

Hi Sandeep,

If I understand you correctly, looks like you need to change 'row_actions'
field here:
https://github.com/openstack/horizon/blob/stable/kilo/openstack_dashboard/dashboards/project/networks/subnets/tables.py#L152
and replace UpdateSubnet with your custom action.
You also might be interested in this view:
https://github.com/openstack/horizon/blob/stable/kilo/openstack_dashboard/dashboards/project/networks/subnets/views.py#L57
And in this workflow:
https://github.com/openstack/horizon/blob/stable/kilo/openstack_dashboard/dashboards/project/networks/subnets/workflows.py#L80

On Mon, Feb 1, 2016 at 3:40 PM, Sandeep Makhija <
sandeep.makh...@nectechnologies.in> wrote:

> Hi Matthias,
>
> Thanks for your reply.
>
> As mentioned, I need to change the  'action' attribute of the 'Edit
> Subnet' button.\
>
>
> Regards,
> Sandeep Makhija
>
> -Original Message-
> From: Matthias Runge [mailto:mru...@redhat.com]
> Sent: Monday, February 01, 2016 6:03 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Horizon] Django
>
> On Mon, Feb 01, 2016 at 10:56:14AM +, Sandeep Makhija wrote:
> > Hi,
> >
> > I have been trying to fix a bug in horizon but I am a beginner in Django
> and couldn't get my way through this code.
> >
> > Could somebody please help me with it? Below given are the details of
> what I am looking for.
>
> Since you did not describe, what you would like to change, it's a bit hard
> to set you on track.
>
> Looking at that image, I assume, you would like to change the subnet
> workflow, which is defined in subnets/workflows.py
>
>
> https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/networks/workflows.py#L457
>
>
> Matthias
> --
> Matthias Runge <mru...@redhat.com>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> DISCLAIMER:
>
> ---
> The contents of this e-mail and any attachment(s) are confidential and
> intended
> for the named recipient(s) only.
> It shall not attach any liability on the originator or NEC or its
> affiliates. Any views or opinions presented in
> this email are solely those of the author and may not necessarily reflect
> the
> opinions of NEC or its affiliates.
> Any form of reproduction, dissemination, copying, disclosure, modification,
> distribution and / or publication of
> this message without the prior written consent of the author of this
> e-mail is
> strictly prohibited. If you have
> received this email in error please delete it and notify the sender
> immediately. .
>
> ---
>
> __
> OpenStack Development Mailing 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] Django

[Sandeep Makhija]

Hi Matthias,

Thanks for your reply. 

As mentioned, I need to change the  'action' attribute of the 'Edit 
Subnet' button.\

 
Regards,
Sandeep Makhija

-Original Message-
From: Matthias Runge [mailto:mru...@redhat.com] 
Sent: Monday, February 01, 2016 6:03 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Horizon] Django

On Mon, Feb 01, 2016 at 10:56:14AM +, Sandeep Makhija wrote:
> Hi,
> 
> I have been trying to fix a bug in horizon but I am a beginner in Django and 
> couldn't get my way through this code.
> 
> Could somebody please help me with it? Below given are the details of what I 
> am looking for.

Since you did not describe, what you would like to change, it's a bit hard to 
set you on track.

Looking at that image, I assume, you would like to change the subnet workflow, 
which is defined in subnets/workflows.py

https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/networks/workflows.py#L457


Matthias
--
Matthias Runge <mru...@redhat.com>

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



DISCLAIMER:
---
The contents of this e-mail and any attachment(s) are confidential and
intended
for the named recipient(s) only. 
It shall not attach any liability on the originator or NEC or its
affiliates. Any views or opinions presented in 
this email are solely those of the author and may not necessarily reflect the
opinions of NEC or its affiliates. 
Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of 
this message without the prior written consent of the author of this e-mail is
strictly prohibited. If you have 
received this email in error please delete it and notify the sender
immediately. .
---

__
OpenStack Development Mailing 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] Django

[Matthias Runge]

On Mon, Feb 01, 2016 at 10:56:14AM +, Sandeep Makhija wrote:
> Hi,
> 
> I have been trying to fix a bug in horizon but I am a beginner in Django and 
> couldn't get my way through this code.
> 
> Could somebody please help me with it? Below given are the details of what I 
> am looking for.

Since you did not describe, what you would like to change, it's a bit
hard to set you on track.

Looking at that image, I assume, you would like to change
the subnet workflow, which is defined in subnets/workflows.py

https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/networks/workflows.py#L457


Matthias
-- 
Matthias Runge 

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

Re: [openstack-dev] [Horizon] Django

[Lin Hua Cheng]

Hi Sandeep,

Edit Subnet is a workflow that uses a _workflow.html to generate the HTML.

The form attribute is generated by looking up workflow.attr_string in
https://github.com/openstack/horizon/blob/5ef14e17961a699e5980b98aa7edb2a95a905c1b/horizon/templates/horizon/common/_workflow.html#L6

You can specify the attr_string in the workflow class provided by Matthias
and the additional form attribute should be rendered in the form.

HTH,
Lin



On Mon, Feb 1, 2016 at 4:40 AM, Sandeep Makhija <
sandeep.makh...@nectechnologies.in> wrote:

> Hi Matthias,
>
> Thanks for your reply.
>
> As mentioned, I need to change the  'action' attribute of the 'Edit
> Subnet' button.\
>
>
> Regards,
> Sandeep Makhija
>
> -Original Message-
> From: Matthias Runge [mailto:mru...@redhat.com]
> Sent: Monday, February 01, 2016 6:03 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Horizon] Django
>
> On Mon, Feb 01, 2016 at 10:56:14AM +, Sandeep Makhija wrote:
> > Hi,
> >
> > I have been trying to fix a bug in horizon but I am a beginner in Django
> and couldn't get my way through this code.
> >
> > Could somebody please help me with it? Below given are the details of
> what I am looking for.
>
> Since you did not describe, what you would like to change, it's a bit hard
> to set you on track.
>
> Looking at that image, I assume, you would like to change the subnet
> workflow, which is defined in subnets/workflows.py
>
>
> https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/networks/workflows.py#L457
>
>
> Matthias
> --
> Matthias Runge <mru...@redhat.com>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> DISCLAIMER:
>
> ---
> The contents of this e-mail and any attachment(s) are confidential and
> intended
> for the named recipient(s) only.
> It shall not attach any liability on the originator or NEC or its
> affiliates. Any views or opinions presented in
> this email are solely those of the author and may not necessarily reflect
> the
> opinions of NEC or its affiliates.
> Any form of reproduction, dissemination, copying, disclosure, modification,
> distribution and / or publication of
> this message without the prior written consent of the author of this
> e-mail is
> strictly prohibited. If you have
> received this email in error please delete it and notify the sender
> immediately. .
>
> ---
>
> __
> OpenStack Development Mailing 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] It's already too late for ... Updating XStatic packages

[Thomas Goirand]

On 01/06/2016 06:18 PM, Rob Cresswell (rcresswe) wrote:
> Hi all,
> 
> While the automated system is broken, I’d like to work on manually
> releasing a few of the XStatic packages. This will *only* be the release
> stage; we will still use gerrit to review the package content as usual.
> 
> List of packages current versions, and their upstreams, can be found
> here: https://etherpad.openstack.org/p/horizon-libs
> 
> If anyone has spare time, please consider investigating some of the
> dependencies listed above. To update an XStatic package, propose a
> change to its repo as you would with Horizon; they are all in the
> OpenStack namespace. For example, Xstatic-Angular can be found
> at http://git.openstack.org/cgit/openstack/xstatic-angular/
> 
> Thanks,
> Rob

Guys,

We're now in February, *after* the end of the Beta 2 cycle.

I'd like to remind you that now is *too late already* to update or
change any dependency on Horizon. If you want to do so, please do that
*after* the Mitaka release.

I don't want to suffer spending half of my package maintainer time on
Horizon, in a hurry, at the end of a dev cycle again. These things
should be changed before b1 or at least before b2, not after.

By the way, is there a document where I can see the changes already made?

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

Re: [openstack-dev] [Horizon] Recent integration tests failures

[Timur Sufiev]

Problematic Selenium versions have been successfully excluded from Horizon
test-requirements, if you still experiencing the error described above,
rebase your patch onto the latest master.
On Fri, 29 Jan 2016 at 12:36, Itxaka Serrano Garcia 
wrote:

> Can confirm, had the same issue locally, was fixed after a downgrade to
> selenium 2.48.
>
>
> Good catch!
>
> Itxaka
>
> On 01/28/2016 10:08 PM, Timur Sufiev wrote:
> > According to the results at
> > https://review.openstack.org/#/c/273697/1 capping Selenium to be not
> > greater than 2.49 fixes broken tests. Patch to global-requirements is
> > here: https://review.openstack.org/#/c/273750/
> >
> > On Thu, Jan 28, 2016 at 9:22 PM Timur Sufiev  > > wrote:
> >
> > Hello, Horizoneers
> >
> > You may have noticed recent integration tests failures seemingly
> > unrelated to you patches, with a stacktrace like:
> > http://paste2.org/2Hk9138U I've already filed a bug for that,
> > https://bugs.launchpad.net/horizon/+bug/1539197 Appears to be a
> > Selenium issue, currently investigating it.
> >
> >
> >
> >
> >
> __
> > OpenStack Development Mailing 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] Recent integration tests failures

[Itxaka Serrano Garcia]

Can confirm, had the same issue locally, was fixed after a downgrade to 
selenium 2.48.



Good catch!

Itxaka

On 01/28/2016 10:08 PM, Timur Sufiev wrote:

According to the results at
https://review.openstack.org/#/c/273697/1 capping Selenium to be not
greater than 2.49 fixes broken tests. Patch to global-requirements is
here: https://review.openstack.org/#/c/273750/

On Thu, Jan 28, 2016 at 9:22 PM Timur Sufiev > wrote:

Hello, Horizoneers

You may have noticed recent integration tests failures seemingly
unrelated to you patches, with a stacktrace like:
http://paste2.org/2Hk9138U I've already filed a bug for that,
https://bugs.launchpad.net/horizon/+bug/1539197 Appears to be a
Selenium issue, currently investigating it.




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

[David Lyle]

I think that's the sane thing to do.

David

On Thu, Jan 28, 2016 at 2:55 AM, Richard Jones  wrote:
> Hi fellow angular/REST Horizon developers,
>
> I'd like to propose that we handle HTTP 401 responses at the core of the new
> angular code interfacing to our new REST API so that *any* 401 just does
> basically what the Django code used to: redirect to the login page with a
> "from".
>
> What do y'all think?
>
>
> Richard
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [Horizon] Handling 401 in new REST API

[Thai Q Tran]

I am assuming that you meant redirecting on the server side. We already have a similar one in place on the client side. https://github.com/openstack/horizon/blob/master/horizon/static/framework/framework.module.js#L65
 
Currently, you're not able to hit the REST layer directly anyway, You get a "request must be ajax" message. You have to login and then use a REST client if you want data. So here's my noob question of the day, what are we gaining in addition if we redirect on the server side? Totally not meant to be a show stopper, just wondering what the benefits are.
 
- 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] Handling 401 in new REST APIDate: Thu, Jan 28, 2016 8:46 AM 
I think that's the sane thing to do.DavidOn Thu, Jan 28, 2016 at 2:55 AM, Richard Jones <r1chardj0...@gmail.com> wrote:> Hi fellow angular/REST Horizon developers,>> I'd like to propose that we handle HTTP 401 responses at the core of the new> angular code interfacing to our new REST API so that *any* 401 just does> basically what the Django code used to: redirect to the login page with a> "from".>> What do y'all think?>>>     Richard>>> __> OpenStack Development Mailing List (not for usage questions)> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>__OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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] Handling 401 in new REST API

[Richard Jones]

Hmm. That client-side redirect isn't working consistently then. More
investigation required...

On 29 January 2016 at 05:04, Thai Q Tran <tqt...@us.ibm.com> wrote:

> I am assuming that you meant redirecting on the server side. We already
> have a similar one in place on the client side.
> https://github.com/openstack/horizon/blob/master/horizon/static/framework/framework.module.js#L65
>
> Currently, you're not able to hit the REST layer directly anyway, You get
> a "request must be ajax" message. You have to login and then use a REST
> client if you want data. So here's my noob question of the day, what are we
> gaining in addition if we redirect on the server side? Totally not meant to
> be a show stopper, just wondering what the benefits are.
>
>
> - 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] Handling 401 in new REST API
> Date: Thu, Jan 28, 2016 8:46 AM
>
> I think that's the sane thing to do.
>
> David
>
> On Thu, Jan 28, 2016 at 2:55 AM, Richard Jones <r1chardj0...@gmail.com>
> wrote:
> > Hi fellow angular/REST Horizon developers,
> >
> > I'd like to propose that we handle HTTP 401 responses at the core of the
> new
> > angular code interfacing to our new REST API so that *any* 401 just does
> > basically what the Django code used to: redirect to the login page with a
> > "from".
> >
> > What do y'all think?
> >
> >
> > Richard
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>
> __
> OpenStack Development Mailing 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] Recent integration tests failures

[Timur Sufiev]

According to the results at https://review.openstack.org/#/c/273697/1 capping
Selenium to be not greater than 2.49 fixes broken tests. Patch to
global-requirements is here: https://review.openstack.org/#/c/273750/

On Thu, Jan 28, 2016 at 9:22 PM Timur Sufiev  wrote:

> Hello, Horizoneers
>
> You may have noticed recent integration tests failures seemingly unrelated
> to you patches, with a stacktrace like: http://paste2.org/2Hk9138U I've
> already filed a bug for that,
> https://bugs.launchpad.net/horizon/+bug/1539197 Appears to be a Selenium
> issue, currently investigating it.
>
>
>
__
OpenStack Development Mailing 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] Handling 401 in new REST API

[Richard Jones]

Hi fellow angular/REST Horizon developers,

I'd like to propose that we handle HTTP 401 responses at the core of the
new angular code interfacing to our new REST API so that *any* 401 just
does basically what the Django code used to: redirect to the login page
with a "from".

What do y'all think?


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

[openstack-dev] [Horizon] Recent integration tests failures

[Timur Sufiev]

Hello, Horizoneers

You may have noticed recent integration tests failures seemingly unrelated
to you patches, with a stacktrace like: http://paste2.org/2Hk9138U I've
already filed a bug for that,
https://bugs.launchpad.net/horizon/+bug/1539197 Appears to be a Selenium
issue, currently investigating it.
__
OpenStack Development Mailing 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 Views overriding

[Yves-Gwenaël Bourhis]

Hi,

Thanks a lot, that's exactly what I needed :-)

Le 25/01/2016 19:16, Thai Q Tran a écrit :
> Hello,
>  
> When we designed the architecture for the angular work, we had extension
> in mind. We have pretty good support for extending a workflow (see links
> below). We have a bunch of patches that when put together will do what
> you want, but no guide on how to do it. The documentation in Horizon is
> stalling because some of us prefer to nit pick then see any real progress.
>  
> https://review.openstack.org/#/c/252014/
> This patch allows you to declare your columns inside of a
> controller instead of the HTML. It doesn't get you where you want
> yet, it still requires you to modify a static file.
>  
> https://review.openstack.org/#/c/214306/
> This patch has already merged so it is available now. It allows you to
> arbitrarily inject your plugin/extension into a container. See video
> below on how to use it for a workflow. This same architecture can be
> applied to table columns.
>  
> Basically, most of what you want is there, but not currently
> documented. Currently, you will need do a bit more work on your end to
> get it working. Feel free to reach out to me on IRC (tqtran) or email
> (tqt...@us.ibm.com) if you are stuck somewhere.
>  
> Links below provide a more detailed explanation of how to extend a workflow.
>  
> Video tutorial on extending the workflow about 22 minute in:
> https://www.youtube.com/watch?v=Km99BCHfBdk
>  
> And the patch containing the docs for it:
> https://review.openstack.org/#/c/244407/2/doc/source/tutorials/workflow_extend.rst
>  
>  
> 
> - Original message -
> From: Yves-Gwenaël Bourhis <yves-gwenael.bour...@cloudwatt.com>
> To: openstack-dev@lists.openstack.org
> Cc:
> Subject: Re: [openstack-dev] [horizon] Angular Views overriding
> Date: Mon, Jan 25, 2016 7:50 AM
>  
> 
> Le 25/01/2016 12:27, Yves-Gwenaël Bourhis a écrit :
> > Hello All,
> >
> > I have a question regarding Horizon Angular views.
> >
> > My question is "Is there a way (and if so "a doc") of customizing
> (overriding) the current angular views without modifying the current
> static js and html files?"
> > With
> http://docs.openstack.org/developer/horizon/topics/customizing.html people
> who deploy horizon can easily modify some views without touching the
> horizon code, but what I would like to know if there is a provided
> mechanism to add some company specific columns in the angular
> launch-instance form (I want to add the prices of an instance per
> flavor, plus some extra flavor specific info, plus some flavor
> categories, plus category tabs for the images, etc...).
> 
> s/what I would like to know if/what I would like to know is if/
> 
> > For the moment the only method I found was either to be intrusive
> in the horizon code, either I had to have my app come first in
> installed apps and have the same static path and copy + modify all
> the angular specific html... :-/
> >
> > Is there a better way of doing so?
> >
> > If not, maybe a Blue-Print could be welcomed, because it's often
> necessary to have deployment specific overrides of the angular views
> made as easy as the python/django/horizon ones.
> >
> > Thanks all.
> >
> 
> --
> Yves-Gwenaël Bourhis
> 
> __
> OpenStack Development Mailing 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
> 

-- 
Yves-Gwenaël Bourhis

__
OpenStack Development Mailing 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 Views overriding

[Yves-Gwenaël Bourhis]

Le 25/01/2016 12:27, Yves-Gwenaël Bourhis a écrit :
> Hello All,
> 
> I have a question regarding Horizon Angular views.
> 
> My question is "Is there a way (and if so "a doc") of customizing 
> (overriding) the current angular views without modifying the current static 
> js and html files?"
> With http://docs.openstack.org/developer/horizon/topics/customizing.html 
> people who deploy horizon can easily modify some views without touching the 
> horizon code, but what I would like to know if there is a provided mechanism 
> to add some company specific columns in the angular launch-instance form (I 
> want to add the prices of an instance per flavor, plus some extra flavor 
> specific info, plus some flavor categories, plus category tabs for the 
> images, etc...).

s/what I would like to know if/what I would like to know is if/

> For the moment the only method I found was either to be intrusive in the 
> horizon code, either I had to have my app come first in installed apps and 
> have the same static path and copy + modify all the angular specific html... 
> :-/
> 
> Is there a better way of doing so?
> 
> If not, maybe a Blue-Print could be welcomed, because it's often necessary to 
> have deployment specific overrides of the angular views made as easy as the 
> python/django/horizon ones.
> 
> Thanks all.
> 

-- 
Yves-Gwenaël Bourhis

__
OpenStack Development Mailing 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 Views overriding

[Thai Q Tran]

Hello,
 
When we designed the architecture for the angular work, we had extension in mind. We have pretty good support for extending a workflow (see links below). We have a bunch of patches that when put together will do what you want, but no guide on how to do it. The documentation in Horizon is stalling because some of us prefer to nit pick then see any real progress.
 
https://review.openstack.org/#/c/252014/
This patch allows you to declare your columns inside of a controller instead of the HTML. It doesn't get you where you want yet, it still requires you to modify a static file.
 
https://review.openstack.org/#/c/214306/
This patch has already merged so it is available now. It allows you to arbitrarily inject your plugin/extension into a container. See video below on how to use it for a workflow. This same architecture can be applied to table columns.
 
Basically, most of what you want is there, but not currently documented. Currently, you will need do a bit more work on your end to get it working. Feel free to reach out to me on IRC (tqtran) or email (tqt...@us.ibm.com) if you are stuck somewhere.
 
Links below provide a more detailed explanation of how to extend a workflow.
 
Video tutorial on extending the workflow about 22 minute in:
https://www.youtube.com/watch?v=Km99BCHfBdk
 
And the patch containing the docs for it:
https://review.openstack.org/#/c/244407/2/doc/source/tutorials/workflow_extend.rst
 
 
- Original message -From: Yves-Gwenaël Bourhis <yves-gwenael.bour...@cloudwatt.com>To: openstack-dev@lists.openstack.orgCc:Subject: Re: [openstack-dev] [horizon] Angular Views overridingDate: Mon, Jan 25, 2016 7:50 AM 
Le 25/01/2016 12:27, Yves-Gwenaël Bourhis a écrit :> Hello All,>> I have a question regarding Horizon Angular views.>> My question is "Is there a way (and if so "a doc") of customizing (overriding) the current angular views without modifying the current static js and html files?"> With http://docs.openstack.org/developer/horizon/topics/customizing.html people who deploy horizon can easily modify some views without touching the horizon code, but what I would like to know if there is a provided mechanism to add some company specific columns in the angular launch-instance form (I want to add the prices of an instance per flavor, plus some extra flavor specific info, plus some flavor categories, plus category tabs for the images, etc...).s/what I would like to know if/what I would like to know is if/> For the moment the only method I found was either to be intrusive in the horizon code, either I had to have my app come first in installed apps and have the same static path and copy + modify all the angular specific html... :-/>> Is there a better way of doing so?>> If not, maybe a Blue-Print could be welcomed, because it's often necessary to have deployment specific overrides of the angular views made as easy as the python/django/horizon ones.>> Thanks all.>--Yves-Gwenaël Bourhis__OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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 Views overriding

[Yves-Gwenaël Bourhis]

Hello All,

I have a question regarding Horizon Angular views.

My question is "Is there a way (and if so "a doc") of customizing (overriding) 
the current angular views without modifying the current static js and html 
files?"
With http://docs.openstack.org/developer/horizon/topics/customizing.html people 
who deploy horizon can easily modify some views without touching the horizon 
code, but what I would like to know if there is a provided mechanism to add 
some company specific columns in the angular launch-instance form (I want to 
add the prices of an instance per flavor, plus some extra flavor specific info, 
plus some flavor categories, plus category tabs for the images, etc...).

For the moment the only method I found was either to be intrusive in the 
horizon code, either I had to have my app come first in installed apps and have 
the same static path and copy + modify all the angular specific html... :-/

Is there a better way of doing so?

If not, maybe a Blue-Print could be welcomed, because it's often necessary to 
have deployment specific overrides of the angular views made as easy as the 
python/django/horizon ones.

Thanks all.

-- 
Yves-Gwenaël Bourhis

__
OpenStack Development Mailing 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]Back porting code from master to liberty

[Matthias Runge]

On 18/01/16 07:22, Sirisha Guduru wrote:
> Hi,
> 
> ³VolumeTypeList² for admin is enabled in the master release of openstack
> horizon, where an admin can see all the volume types listed in horizon.
> The same is not implemented in liberty. Can we back port the code from
> master to liberty to meet the requirement or should it be implemented
> locally?

Sirisha,

in your local repositories, you can do anything you want.

For official branches there is an official policy:
https://wiki.openstack.org/wiki/StableBranch#Appropriate_Fixes

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

Re: [openstack-dev] [Horizon] Email as User Name on the Horizon login page

[Adrian Turjak]

Updating the label code in django_openstack_auth isn't an option since
it would mean forking and maintaining our own copy of the library for
most likely one line of code.

Diana, any clue how would I go about overriding the label solely with
code placed in Horizon? Ideally we'd like to just place this in our own
theme to make rebasing horizon changes easier, but if needed we can live
with making this a non-theme patch for us to carry.

No clue how much we care about Localization, but if the answer is that
we do, how much work do you think adding "Email" to our Horizon
Localization would be?

Cheers,
-Adrian

On 16/01/16 07:43, Diana Whitten wrote:
> Adrian,
> 
> Changing the label is also possible through overrides, but customizing any
> label that goes through Localization might affect other languages.  Not
> sure if this might be a problem for you.
> 
> If this isn't ideal, we can easily put in hooks to allow customization
> purely through CSS, using pseudo selectors like ':before' or ':after' in
> combination with 'content'.  We just need to wrap the contents of the label
> with an inner span.
> 
> Thoughts?
> 
> - Diana
> 
> 
> 
> On Fri, Jan 15, 2016 at 10:47 AM, Lin Hua Cheng  wrote:
> 
>> It might be simpler to just update the label on the python code. This is
>> where the form label are defined.
>>
>> You can update the label here:
>> https://github.com/openstack/django_openstack_auth/blob/stable/kilo/openstack_auth/forms.py#L51
>>
>> -Lin
>>
>>
>> On Fri, Jan 15, 2016 at 12:54 AM, Itxaka Serrano Garcia >> wrote:
>>
>>>
>>> Looks like the form comes from django_openstack_auth:
>>>
>>> https://github.com/openstack/django_openstack_auth/blob/master/openstack_auth/forms.py#L53
>>>
>>>
>>> But to be honest, no idea how that can be overridden trough the themes,
>>> not sure if its even possible to override anything on that page without
>>> modifying django_openstack_auth directly :(
>>>
>>> Maybe someone else has a better insight on this than me.
>>>
>>>
>>> * Horrible Hack Incoming, read at your own discretion *
>>>
>>> You can override the template here:
>>>
>>> https://github.com/openstack/horizon/blob/master/horizon/templates/horizon/common/_form_field.html#L51
>>>
>>> And change this line:
>>> {{ field.label }}
>>>
>>> For this:
>>> {% if field.label == "User Name" and not
>>> request.user.is_authenticated %}Email{% else %}{{ field.label }}{% endif
>>> %}
>>>
>>>
>>> Which will check if the label is "User Name" and the user is logged out
>>> and directly write "Email" as the field label.
>>>
>>> I know, its horrible and if you update horizon it will be overriden, but
>>> probably works for the time being if you really need it ¯\_(ツ)_/¯
>>>
>>> * Horrible Hack Finished *
>>>
>>>
>>>
>>>
>>> Itxaka
>>>
>>>
>>>
>>>
>>>
>>> On 01/15/2016 05:13 AM, Adrian Turjak wrote:
>>>
 I've run into a weird issue with the Liberty release of Horizon.

 For our deployment we enforce emails as usernames, and thus for Horizon
 we used to have "User Name" on the login page replaced with "Email".
 This used to be a straightforward change in the html template file, and
 with the introduction of themes we assumed it would be the same. When
 one of our designers was migrating our custom CSS and html changes to
 the new theme system they missed that change and I at first it was a
 silly mistake.

 Only on digging through the code myself I found that the "User Name" on
 the login screen isn't in the html file at all, nor anywhere else
 straightforward. The login page form is built on the fly with javascript
 to facilitate different modes of authentication. While a bit annoying
 that didn't seem too bad and I then assumed it might mean a javascript
 change, only that the more I dug, the more I became confused.

 Where exactly is the login form defined? And where exactly is the "User
 Name" text for the login form set?

 I've tried all manner of stuff to change it with no luck and I feel like
 I must have missed something obvious.

 Cheers,
 -Adrian Turjak


 __
 OpenStack Development Mailing 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

Re: [openstack-dev] [Horizon] Email as User Name on the Horizon login page

[Adrian Turjak]

Thanks, as a hack that's not a bad fix.

We maintain our own Horizon repo anyway and rebase often, so it's a 
change we can carry if needed.


I'm just confused as to why these changes were made to work as they are. 
I mean sure having the html populate based on the form details is nice 
in theory, but having that in a place you can't access or customize 
because it's in a secondary library feels like over engineering.


What is the point of themes if we can't change something as basic as a 
form field label?


On 15/01/2016 9:54 p.m., Itxaka Serrano Garcia wrote:


Looks like the form comes from django_openstack_auth:
https://github.com/openstack/django_openstack_auth/blob/master/openstack_auth/forms.py#L53 




But to be honest, no idea how that can be overridden trough the 
themes, not sure if its even possible to override anything on that 
page without modifying django_openstack_auth directly :(


Maybe someone else has a better insight on this than me.


* Horrible Hack Incoming, read at your own discretion *

You can override the template here:
https://github.com/openstack/horizon/blob/master/horizon/templates/horizon/common/_form_field.html#L51 



And change this line:
for="{{ field.auto_id }}">{{ field.label }}


For this:
for="{{ field.auto_id }}">{% if field.label == "User Name" and not 
request.user.is_authenticated %}Email{% else %}{{ field.label }}{% 
endif %}



Which will check if the label is "User Name" and the user is logged 
out and directly write "Email" as the field label.


I know, its horrible and if you update horizon it will be overriden, 
but probably works for the time being if you really need it ¯\_(ツ)_/¯


* Horrible Hack Finished *




Itxaka




On 01/15/2016 05:13 AM, Adrian Turjak wrote:

I've run into a weird issue with the Liberty release of Horizon.

For our deployment we enforce emails as usernames, and thus for Horizon
we used to have "User Name" on the login page replaced with "Email".
This used to be a straightforward change in the html template file, and
with the introduction of themes we assumed it would be the same. When
one of our designers was migrating our custom CSS and html changes to
the new theme system they missed that change and I at first it was a
silly mistake.

Only on digging through the code myself I found that the "User Name" on
the login screen isn't in the html file at all, nor anywhere else
straightforward. The login page form is built on the fly with javascript
to facilitate different modes of authentication. While a bit annoying
that didn't seem too bad and I then assumed it might mean a javascript
change, only that the more I dug, the more I became confused.

Where exactly is the login form defined? And where exactly is the "User
Name" text for the login form set?

I've tried all manner of stuff to change it with no luck and I feel like
I must have missed something obvious.

Cheers,
-Adrian Turjak

__ 


OpenStack Development Mailing 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] Email as User Name on the Horizon login page

[Lin Hua Cheng]

It might be simpler to just update the label on the python code. This is
where the form label are defined.

You can update the label here:
https://github.com/openstack/django_openstack_auth/blob/stable/kilo/openstack_auth/forms.py#L51

-Lin

On Fri, Jan 15, 2016 at 12:54 AM, Itxaka Serrano Garcia 
wrote:

>
> Looks like the form comes from django_openstack_auth:
>
> https://github.com/openstack/django_openstack_auth/blob/master/openstack_auth/forms.py#L53
>
>
> But to be honest, no idea how that can be overridden trough the themes,
> not sure if its even possible to override anything on that page without
> modifying django_openstack_auth directly :(
>
> Maybe someone else has a better insight on this than me.
>
>
> * Horrible Hack Incoming, read at your own discretion *
>
> You can override the template here:
>
> https://github.com/openstack/horizon/blob/master/horizon/templates/horizon/common/_form_field.html#L51
>
> And change this line:
> {{
> field.label }}
>
> For this:
> {% if
> field.label == "User Name" and not request.user.is_authenticated %}Email{%
> else %}{{ field.label }}{% endif %}
>
>
> Which will check if the label is "User Name" and the user is logged out
> and directly write "Email" as the field label.
>
> I know, its horrible and if you update horizon it will be overriden, but
> probably works for the time being if you really need it ¯\_(ツ)_/¯
>
> * Horrible Hack Finished *
>
>
>
>
> Itxaka
>
>
>
>
>
> On 01/15/2016 05:13 AM, Adrian Turjak wrote:
>
>> I've run into a weird issue with the Liberty release of Horizon.
>>
>> For our deployment we enforce emails as usernames, and thus for Horizon
>> we used to have "User Name" on the login page replaced with "Email".
>> This used to be a straightforward change in the html template file, and
>> with the introduction of themes we assumed it would be the same. When
>> one of our designers was migrating our custom CSS and html changes to
>> the new theme system they missed that change and I at first it was a
>> silly mistake.
>>
>> Only on digging through the code myself I found that the "User Name" on
>> the login screen isn't in the html file at all, nor anywhere else
>> straightforward. The login page form is built on the fly with javascript
>> to facilitate different modes of authentication. While a bit annoying
>> that didn't seem too bad and I then assumed it might mean a javascript
>> change, only that the more I dug, the more I became confused.
>>
>> Where exactly is the login form defined? And where exactly is the "User
>> Name" text for the login form set?
>>
>> I've tried all manner of stuff to change it with no luck and I feel like
>> I must have missed something obvious.
>>
>> Cheers,
>> -Adrian Turjak
>>
>> __
>> OpenStack Development Mailing 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] Email as User Name on the Horizon login page

[Diana Whitten]

Adrian,

Changing the label is also possible through overrides, but customizing any
label that goes through Localization might affect other languages.  Not
sure if this might be a problem for you.

If this isn't ideal, we can easily put in hooks to allow customization
purely through CSS, using pseudo selectors like ':before' or ':after' in
combination with 'content'.  We just need to wrap the contents of the label
with an inner span.

Thoughts?

- Diana



On Fri, Jan 15, 2016 at 10:47 AM, Lin Hua Cheng  wrote:

> It might be simpler to just update the label on the python code. This is
> where the form label are defined.
>
> You can update the label here:
> https://github.com/openstack/django_openstack_auth/blob/stable/kilo/openstack_auth/forms.py#L51
>
> -Lin
>
>
> On Fri, Jan 15, 2016 at 12:54 AM, Itxaka Serrano Garcia  > wrote:
>
>>
>> Looks like the form comes from django_openstack_auth:
>>
>> https://github.com/openstack/django_openstack_auth/blob/master/openstack_auth/forms.py#L53
>>
>>
>> But to be honest, no idea how that can be overridden trough the themes,
>> not sure if its even possible to override anything on that page without
>> modifying django_openstack_auth directly :(
>>
>> Maybe someone else has a better insight on this than me.
>>
>>
>> * Horrible Hack Incoming, read at your own discretion *
>>
>> You can override the template here:
>>
>> https://github.com/openstack/horizon/blob/master/horizon/templates/horizon/common/_form_field.html#L51
>>
>> And change this line:
>> {{ field.label }}
>>
>> For this:
>> {% if field.label == "User Name" and not
>> request.user.is_authenticated %}Email{% else %}{{ field.label }}{% endif
>> %}
>>
>>
>> Which will check if the label is "User Name" and the user is logged out
>> and directly write "Email" as the field label.
>>
>> I know, its horrible and if you update horizon it will be overriden, but
>> probably works for the time being if you really need it ¯\_(ツ)_/¯
>>
>> * Horrible Hack Finished *
>>
>>
>>
>>
>> Itxaka
>>
>>
>>
>>
>>
>> On 01/15/2016 05:13 AM, Adrian Turjak wrote:
>>
>>> I've run into a weird issue with the Liberty release of Horizon.
>>>
>>> For our deployment we enforce emails as usernames, and thus for Horizon
>>> we used to have "User Name" on the login page replaced with "Email".
>>> This used to be a straightforward change in the html template file, and
>>> with the introduction of themes we assumed it would be the same. When
>>> one of our designers was migrating our custom CSS and html changes to
>>> the new theme system they missed that change and I at first it was a
>>> silly mistake.
>>>
>>> Only on digging through the code myself I found that the "User Name" on
>>> the login screen isn't in the html file at all, nor anywhere else
>>> straightforward. The login page form is built on the fly with javascript
>>> to facilitate different modes of authentication. While a bit annoying
>>> that didn't seem too bad and I then assumed it might mean a javascript
>>> change, only that the more I dug, the more I became confused.
>>>
>>> Where exactly is the login form defined? And where exactly is the "User
>>> Name" text for the login form set?
>>>
>>> I've tried all manner of stuff to change it with no luck and I feel like
>>> I must have missed something obvious.
>>>
>>> Cheers,
>>> -Adrian Turjak
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] Email as User Name on the Horizon login page

[Itxaka Serrano Garcia]

Looks like the form comes from django_openstack_auth:
https://github.com/openstack/django_openstack_auth/blob/master/openstack_auth/forms.py#L53


But to be honest, no idea how that can be overridden trough the themes, 
not sure if its even possible to override anything on that page without 
modifying django_openstack_auth directly :(


Maybe someone else has a better insight on this than me.


* Horrible Hack Incoming, read at your own discretion *

You can override the template here:
https://github.com/openstack/horizon/blob/master/horizon/templates/horizon/common/_form_field.html#L51

And change this line:
{{ field.label }}


For this:
{% if field.label == "User Name" and not 
request.user.is_authenticated %}Email{% else %}{{ field.label }}{% endif 
%}



Which will check if the label is "User Name" and the user is logged out 
and directly write "Email" as the field label.


I know, its horrible and if you update horizon it will be overriden, but 
probably works for the time being if you really need it ¯\_(ツ)_/¯


* Horrible Hack Finished *




Itxaka




On 01/15/2016 05:13 AM, Adrian Turjak wrote:

I've run into a weird issue with the Liberty release of Horizon.

For our deployment we enforce emails as usernames, and thus for Horizon
we used to have "User Name" on the login page replaced with "Email".
This used to be a straightforward change in the html template file, and
with the introduction of themes we assumed it would be the same. When
one of our designers was migrating our custom CSS and html changes to
the new theme system they missed that change and I at first it was a
silly mistake.

Only on digging through the code myself I found that the "User Name" on
the login screen isn't in the html file at all, nor anywhere else
straightforward. The login page form is built on the fly with javascript
to facilitate different modes of authentication. While a bit annoying
that didn't seem too bad and I then assumed it might mean a javascript
change, only that the more I dug, the more I became confused.

Where exactly is the login form defined? And where exactly is the "User
Name" text for the login form set?

I've tried all manner of stuff to change it with no luck and I feel like
I must have missed something obvious.

Cheers,
-Adrian Turjak

__
OpenStack Development Mailing 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] Email as User Name on the Horizon login page

[Adrian Turjak]

I've run into a weird issue with the Liberty release of Horizon.

For our deployment we enforce emails as usernames, and thus for Horizon
we used to have "User Name" on the login page replaced with "Email".
This used to be a straightforward change in the html template file, and
with the introduction of themes we assumed it would be the same. When
one of our designers was migrating our custom CSS and html changes to
the new theme system they missed that change and I at first it was a
silly mistake.

Only on digging through the code myself I found that the "User Name" on
the login screen isn't in the html file at all, nor anywhere else
straightforward. The login page form is built on the fly with javascript
to facilitate different modes of authentication. While a bit annoying
that didn't seem too bad and I then assumed it might mean a javascript
change, only that the more I dug, the more I became confused.

Where exactly is the login form defined? And where exactly is the "User
Name" text for the login form set?

I've tried all manner of stuff to change it with no luck and I feel like
I must have missed something obvious.

Cheers,
-Adrian Turjak

__
OpenStack Development Mailing 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] Routing in Horizon

[Matthias Runge]

On 12/01/16 11:22, Matthias Runge wrote:

> 
> https://launchpad.net/bugs/1532759
> 
> Unfortunately, that even hasn't been detected by tests.
> 
https://github.com/openstack/horizon/commit/871505c130cf1fd02aae41aeb8f6062af4a5fe88

fixes this issue (another revert).

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

Re: [openstack-dev] [Horizon] Routing in Horizon

[Itxaka Serrano Garcia]

> El 12 ene 2016, a las 11:22, Matthias Runge  escribió:
> 
> On 12/01/16 03:33, Richard Jones wrote:
>> The  tag addition has had to be reverted as it broke other parts
>> of the application (notably lazy loaded tabs like Instance Details), sadly.
>> 
>> Regarding which router to use - I've used the built-in router in the
>> past quite successfully. I think I'd want to see a solid reason for
>> using a 3rd party one. It could be that nested routes are part of that,
>> but I kinda see that as a convenience thing, unless I'm missing
>> something core to how routing is planned to be done. Then again we
>> really haven't had any discussion about how we see routing work. The one
>> patch that's up that uses routing seems perfectly able to do so without
>> needing extended capabilities of 3rd party routers.
> 
> I believe, there has been something else messing up with routing,
> causing pagination to be broken now.
> 
> https://launchpad.net/bugs/1532759
> 
> Unfortunately, that even hasn't been detected by tests.
> 
> 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

Also see https://bugs.launchpad.net/horizon/+bug/1532265

Any link that has an href="#" is probably broken.

If I'm not mistaken, the # is what angular uses as locationprovider?

Itxaka
__
OpenStack Development Mailing 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] Routing in Horizon

[Matthias Runge]

On 12/01/16 03:33, Richard Jones wrote:
> The  tag addition has had to be reverted as it broke other parts
> of the application (notably lazy loaded tabs like Instance Details), sadly.
> 
> Regarding which router to use - I've used the built-in router in the
> past quite successfully. I think I'd want to see a solid reason for
> using a 3rd party one. It could be that nested routes are part of that,
> but I kinda see that as a convenience thing, unless I'm missing
> something core to how routing is planned to be done. Then again we
> really haven't had any discussion about how we see routing work. The one
> patch that's up that uses routing seems perfectly able to do so without
> needing extended capabilities of 3rd party routers.

I believe, there has been something else messing up with routing,
causing pagination to be broken now.

https://launchpad.net/bugs/1532759

Unfortunately, that even hasn't been detected by tests.

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

Re: [openstack-dev] [Horizon] Routing in Horizon

[Tripp, Travis S]

Rajat,

Thanks for starting some discussion here.  I think your target=“_self” is taken 
care of now, right?

Re: ng-route vs ui-router - everything I have ever seen or been told supports 
using ui-router instead of ng-route.  I know a quick google search supports 
that, but let me google that for all of us and give several references:

http://www.funnyant.com/angularjs-ui-router/
http://www.amasik.com/angularjs-ngroute-vs-ui-router/
http://stackoverflow.com/questions/21023763/angularjs-difference-between-angular-route-and-angular-ui-router
http://www.pearpages.com/javascript/angularjs/routing/2015/10/13/ngroute-vs-ui-router.html
http://stackoverflow.com/questions/32523512/ui-router-vs-ngroute-for-sinlge-page-app

So, I’m wondering if there’d been any discussion I missed on why not bring in 
ui-router?

Of course there is question using the new router in angular vs ui-router, but 
finding many pros- cons- on that seems to be a bit more difficult. Since it is 
1.5 / 2.0 and neither are past rc / beta, it doesn’t seem like something we can 
debate too well.

https://angular.github.io/router/getting-started
http://www.angulardaily.com/2015/12/angularintroduction-to-ngnewrouter-vs.html

Thanks,
Travis

From: Rajat Vig <raj...@thoughtworks.com<mailto:raj...@thoughtworks.com>>
Reply-To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, January 7, 2016 at 1:53 AM
To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [Horizon] Routing in Horizon

Hi Everyone

One of my recent patches which enabled HTML5 based routing via Angular merged, 
some interesting things spun out.
I'd to scramble a few patches to get things
​​ back the same way
for all new Angular Panels.

I also realized that getting Horizon to an SPA with Angular requires more 
thought than mere fixing the current burning issue.
This mail's intent is to spur a direction on how we do routing in Angular and 
how do Angular Panels go back/forth between themselves and older Django panels.

The patch https://review.openstack.org/#/c/173885/ is possibly the first of 
many to use Angular based routing.
It currently uses ngRoute as the library was included in the xstatic-angular 
package.

What I'm roughly thinking to solve some of the immediate issues (there's 
possbily much more that I'm not)

1. If we are going to go with the SPA route, then all Panels need to indicate 
that they are Angular based.
For panels that are Angular, they need to declare routes they'd like to manage.

2. All tags on Angular Panels (including header, sidebar, footer) which don't 
route to Angular Panels will need the attribute target="_self" else Angular 
will not allow navigation to those links.

All sidebar links currently have the attribute set but headers and footers 
don't.
Sidebar links for Angular shouldn't have the attribute else SPA like behavior 
will not happen.
This will need to be documen
​tation​
​
​
​
.

3. That implies yet another problem with the Spinner Modal which gets activated 
on all sidebar clicks.
It'll need to be done differently for Angular routing vs hrefs still with 
Django.
The current spinner relies on a browser page refresh to disappear.

Then there's ngRoute.
Routing needs in Angular may need to handle route conflicts and maybe nested 
routes.
There are other, possibly better options that we could consider
1. https://github.com/angular-ui/ui-router
2. https://angular.github.io/router/

I've been part of the community for not long enough yet and I'm not yet 
completely aware of what exists outside the Horizon codebase so I might be 
missing somethings as well.

Regards
Rajat
__
OpenStack Development Mailing 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] Updating XStatic packages

[Richard Jones]

In terms of process, obviously updating the data in the xstatic is
relatively easy (for most packages) but I wonder from a review standpoint
what sort of process we should have here. To approve a merge of an xstatic
package update, I feel like I should have, in order of preference:

1. a link to the change notes for the project in question so I can see what
the impact of the update is, or
2. a list of those changes in the bug or change message for the xstatic
update (i.e. the relevant information from #1), and
3. an explanation of what existing problems are being solved in Horizon
through the update (if any) or what impact there will be on Horizon with
the upgrade (i.e. an examination of #2 in the context of Horizon).

I know that we often need to justify package updates to downstream
packagers, and having this information will certainly help our case. Or is
this all a bit too much burden?


 Richard

On 7 January 2016 at 04:36, Rajat Vig  wrote:

> I did update some of the low hanging packages where the upgrades seemed
> safe to do and noted the patch numbers in the same EtherPad.
>
> I wasn't sure what to mark the effort against. So I created some bugs.
> Should it be a blueprint?
>
> -Rajat
>
> On Wed, Jan 6, 2016 at 2:18 AM, Rob Cresswell (rcresswe) <
> rcres...@cisco.com> wrote:
>
>> Hi all,
>>
>> While the automated system is broken, I’d like to work on manually
>> releasing a few of the XStatic packages. This will *only* be the release
>> stage; we will still use gerrit to review the package content as usual.
>>
>> List of packages current versions, and their upstreams, can be found
>> here: https://etherpad.openstack.org/p/horizon-libs
>>
>> If anyone has spare time, please consider investigating some of the
>> dependencies listed above. To update an XStatic package, propose a change
>> to its repo as you would with Horizon; they are all in the OpenStack
>> namespace. For example, Xstatic-Angular can be found at
>> http://git.openstack.org/cgit/openstack/xstatic-angular/
>>
>> Thanks,
>> Rob
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing 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] Routing in Horizon

[Richard Jones]

The  tag addition has had to be reverted as it broke other parts of
the application (notably lazy loaded tabs like Instance Details), sadly.

Regarding which router to use - I've used the built-in router in the past
quite successfully. I think I'd want to see a solid reason for using a 3rd
party one. It could be that nested routes are part of that, but I kinda see
that as a convenience thing, unless I'm missing something core to how
routing is planned to be done. Then again we really haven't had any
discussion about how we see routing work. The one patch that's up that uses
routing seems perfectly able to do so without needing extended capabilities
of 3rd party routers.


 Richard


On 12 January 2016 at 09:44, Tripp, Travis S <travis.tr...@hpe.com> wrote:

> Rajat,
>
> Thanks for starting some discussion here.  I think your target=“_self” is
> taken care of now, right?
>
> Re: ng-route vs ui-router - everything I have ever seen or been told
> supports using ui-router instead of ng-route.  I know a quick google search
> supports that, but let me google that for all of us and give several
> references:
>
> http://www.funnyant.com/angularjs-ui-router/
> http://www.amasik.com/angularjs-ngroute-vs-ui-router/
>
> http://stackoverflow.com/questions/21023763/angularjs-difference-between-angular-route-and-angular-ui-router
>
> http://www.pearpages.com/javascript/angularjs/routing/2015/10/13/ngroute-vs-ui-router.html
>
> http://stackoverflow.com/questions/32523512/ui-router-vs-ngroute-for-sinlge-page-app
>
> So, I’m wondering if there’d been any discussion I missed on why not bring
> in ui-router?
>
> Of course there is question using the new router in angular vs ui-router,
> but finding many pros- cons- on that seems to be a bit more difficult.
> Since it is 1.5 / 2.0 and neither are past rc / beta, it doesn’t seem like
> something we can debate too well.
>
> https://angular.github.io/router/getting-started
>
> http://www.angulardaily.com/2015/12/angularintroduction-to-ngnewrouter-vs.html
>
> Thanks,
> Travis
>
> From: Rajat Vig <raj...@thoughtworks.com<mailto:raj...@thoughtworks.com>>
> Reply-To: OpenStack List <openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org>>
> Date: Thursday, January 7, 2016 at 1:53 AM
> To: OpenStack List <openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org>>
> Subject: [openstack-dev] [Horizon] Routing in Horizon
>
> Hi Everyone
>
> One of my recent patches which enabled HTML5 based routing via Angular
> merged, some interesting things spun out.
> I'd to scramble a few patches to get things
> ​​ back the same way
> for all new Angular Panels.
>
> I also realized that getting Horizon to an SPA with Angular requires more
> thought than mere fixing the current burning issue.
> This mail's intent is to spur a direction on how we do routing in Angular
> and how do Angular Panels go back/forth between themselves and older Django
> panels.
>
> The patch https://review.openstack.org/#/c/173885/ is possibly the first
> of many to use Angular based routing.
> It currently uses ngRoute as the library was included in the
> xstatic-angular package.
>
> What I'm roughly thinking to solve some of the immediate issues (there's
> possbily much more that I'm not)
>
> 1. If we are going to go with the SPA route, then all Panels need to
> indicate that they are Angular based.
> For panels that are Angular, they need to declare routes they'd like to
> manage.
>
> 2. All tags on Angular Panels (including header, sidebar, footer) which
> don't route to Angular Panels will need the attribute target="_self" else
> Angular will not allow navigation to those links.
>
> All sidebar links currently have the attribute set but headers and footers
> don't.
> Sidebar links for Angular shouldn't have the attribute else SPA like
> behavior will not happen.
> This will need to be documen
> ​tation​
> ​
> ​
> ​
> .
>
> 3. That implies yet another problem with the Spinner Modal which gets
> activated on all sidebar clicks.
> It'll need to be done differently for Angular routing vs hrefs still with
> Django.
> The current spinner relies on a browser page refresh to disappear.
>
> Then there's ngRoute.
> Routing needs in Angular may need to handle route conflicts and maybe
> nested routes.
> There are other, possibly better options that we could consider
> 1. https://github.com/angular-ui/ui-router
> 2. https://angular.github.io/router/
>
> I've been part of the community for not long enough yet and I'm not yet
> completely aware of what exists outside the Horizon codebase so I might 

Re: [openstack-dev] [Horizon] Bug Day 2

[Rob Cresswell (rcresswe)]

Reminder about bug day! Just starting if you’re over in Australia ;)

Rob


On 4 Jan 2016, at 10:54, Rob Cresswell (rcresswe) 
> wrote:

Hi folks,

I think we should have another bug day to continue the good work started last 
time. I’d suggest Tuesday the 12th of January, as most people should be back at 
work by then. We can use the same etherpad too: 
https://etherpad.openstack.org/p/horizon-bug-day

For those not around for the previous one, the bug day is used to review our 
bug reports on Launchpad, and discuss them in IRC. This may be asking for help 
recreating an issue, whether a bug has been fixed etc. The goal is to have an 
organised, prioritised list of valid bug reports. Open new bugs if you stumble 
across them, but bug discovery is not the focus here.

Regards,
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-dev] [horizon] Horizon stable and fast increasing Django releases

[Thomas Goirand]

Hi there!

I maintain the Horizon package in Debian Sid. Sid currently contains
Liberty. It is a constantly reoccurring fact that Django is a too fast
moving target. The last Django 1.9 release broke lots of my (Django
related) packages, Horizon included (see:
https://bugs.debian.org/809575). I have nearly finished fixing all
packages regarding Django 1.9 compatibility, the last of them being
python-jingo (which is an indirect build-dependency).

I know that the Horizon team is constantly also fighting this battle,
though this happens only in the master branch. When django-compressor
has been released with Django 1.9 compatibility, what has been done is
cap it in the Stable gate.

While all of this is very good, this isn't enough for me in Debian Sid.
Best would be if this kind of cap was only a temporary solution until we
really fix the issues. If possible (I perfectly know that in some case
this may be difficult), I'd like to have Horizon stable to contain
backports for Django last release (currently 1.9), instead of just
capping the requirements. Otherwise, Horizon becomes the single piece in
all of OpenStack where I spend all of my maintainer's time, which really
isn't good (there's lots of work to be done in other fields).

Your thoughts? Am I the only one interested by this? Let's say I'm the
only one interested by it (I hope it's not the case), if I do the work,
will the patches be accepted in the Stable branch?

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-dev] [horizon] Problem with FilterAction in a TableTab

[Chad Roberts]

I'm working on streamlining the Sahara UI by reducing the number of panels
and organizing them into tabs rather than individual panels.  I've come
across the following sticking point.  Hopefully, someone can lend a hand.

I now have a group of tabs in a TabbedTableView (each tab is a TableTab).
Some of these tables have a FilterAction that is of type "server" with a
set of field choices.  The filtering worked nicely when they were not in a
TabbedTableView (just a regular DataTableview).  However, the filtering no
longer works in the TabbedTableView.

In my TableTab class, I defined the get__data method, but I
have no natural way to do the filtering there (unless I hack a fair bit to
get the passed-in filters by hacking up a version of
"get_server_filter_info"...which I have done).  The problem remaining is
that after I filter, the values of the field choice and the filter are not
retained (they get reset to ).

I'm still digging through how the FilterAction bits work in a non-tabbed
view, but it seems like something is lacking in the base classes.  Of
course, I'd prefer to have someone say, "duh, just do it like this".

Does this ring a bell for anyone?

Thanks,
Chad
__
OpenStack Development Mailing 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] Problem with FilterAction in a TableTab

[Justin Pomeroy]

Hi Chad,

I wonder if you would benefit from this patch [1] which moves the server 
filtering methods out of DataTableView and into MultiTableMixin.  There 
is also another patch [2] dependent on this that moves the Images table 
into a tab, which sounds similar to what you're doing.


[1] https://review.openstack.org/217020
[2] https://review.openstack.org/218773

- Justin

On 1/8/16 9:10 AM, Chad Roberts wrote:
I'm working on streamlining the Sahara UI by reducing the number of 
panels and organizing them into tabs rather than individual panels.  
I've come across the following sticking point.  Hopefully, someone can 
lend a hand.


I now have a group of tabs in a TabbedTableView (each tab is a 
TableTab).  Some of these tables have a FilterAction that is of type 
"server" with a set of field choices.  The filtering worked nicely 
when they were not in a TabbedTableView (just a regular 
DataTableview).  However, the filtering no longer works in the 
TabbedTableView.


In my TableTab class, I defined the get__data method, but 
I have no natural way to do the filtering there (unless I hack a fair 
bit to get the passed-in filters by hacking up a version of 
"get_server_filter_info"...which I have done).  The problem remaining 
is that after I filter, the values of the field choice and the filter 
are not retained (they get reset to ).


I'm still digging through how the FilterAction bits work in a 
non-tabbed view, but it seems like something is lacking in the base 
classes.  Of course, I'd prefer to have someone say, "duh, just do it 
like this".


Does this ring a bell for anyone?

Thanks,
Chad


__
OpenStack Development Mailing 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] Problem with FilterAction in a TableTab

[Chad Roberts]

Thanks Justin.
That might be just what I'm looking for.  I'll give it a go.

On Fri, Jan 8, 2016 at 11:14 AM, Justin Pomeroy 
wrote:

> Hi Chad,
>
> I wonder if you would benefit from this patch [1] which moves the server
> filtering methods out of DataTableView and into MultiTableMixin.  There is
> also another patch [2] dependent on this that moves the Images table into a
> tab, which sounds similar to what you're doing.
>
> [1] https://review.openstack.org/217020
> [2] https://review.openstack.org/218773
>
> - Justin
>
>
> On 1/8/16 9:10 AM, Chad Roberts wrote:
>
> I'm working on streamlining the Sahara UI by reducing the number of panels
> and organizing them into tabs rather than individual panels.  I've come
> across the following sticking point.  Hopefully, someone can lend a hand.
>
> I now have a group of tabs in a TabbedTableView (each tab is a TableTab).
> Some of these tables have a FilterAction that is of type "server" with a
> set of field choices.  The filtering worked nicely when they were not in a
> TabbedTableView (just a regular DataTableview).  However, the filtering no
> longer works in the TabbedTableView.
>
> In my TableTab class, I defined the get__data method, but I
> have no natural way to do the filtering there (unless I hack a fair bit to
> get the passed-in filters by hacking up a version of
> "get_server_filter_info"...which I have done).  The problem remaining is
> that after I filter, the values of the field choice and the filter are not
> retained (they get reset to ).
>
> I'm still digging through how the FilterAction bits work in a non-tabbed
> view, but it seems like something is lacking in the base classes.  Of
> course, I'd prefer to have someone say, "duh, just do it like this".
>
> Does this ring a bell for anyone?
>
> Thanks,
> Chad
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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] naming of Javascript bits

[Richard Jones]

Yep, thanks folks. Apart from the existing styleguide arguing with my
preferred approach, it seems like we agree on something that should be
pretty consistent. Thanks for putting up that consistency patch Rajat.

On 8 January 2016 at 06:49, Rajat Vig <raj...@thoughtworks.com> wrote:

> I created a patch based off what Richard used as an example to highlight
> inconsistencies and made it consistent.
>
> https://review.openstack.org/#/c/264942/
>
> Have a look and if it feels fine, we can start changing what else exists
> on similar lines.
> Suggestions welcome.
>
> -Rajat
>
> On Thu, Jan 7, 2016 at 10:14 AM Thai Q Tran <tqt...@us.ibm.com> wrote:
>
>> I 2nd that, should rename the file to delete.service.js to match service
>> name.
>>
>>
>> - Original message -
>> From: Rajat Vig <raj...@thoughtworks.com>
>> To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev@lists.openstack.org>
>> Cc:
>> Subject: Re: [openstack-dev] [Horizon] naming of Javascript bits
>> Date: Thu, Jan 7, 2016 12:03 AM
>>
>> Richard
>>
>> My preference is the same as what you've got there.
>> Fully namespaced Services and Controller allow for better reusability and
>> possibly maintainability.
>> If all "deleteService" were named just that, it'll be mighty confusing to
>> use it in other places.
>>
>> With regards to tying the folder path and the Service/Controller I'd
>> mostly go with that as that encourages simpler rules on how to namespace.
>>
>> For the particular patch you mentioned, the namespaces had a bit of churn
>> which is sort of reflected in what exists in the patch now.
>>
>> If we decide a convention, then we can go and change the bits when the
>> files change next.
>>
>> -Rajat
>>
>>
>>
>> On Wed, Jan 6, 2016 at 10:30 PM Richard Jones <r1chardj0...@gmail.com>
>> wrote:
>>
>> Hi Horizon folks,
>>
>> We've been pretty good about namespacing the new angular code (to the
>> extreme of having a bunch of very similar module files littered around, but
>> that's angular/JS for you, so I'm not going to go on about it ).
>>
>> Anyhoo. One thing I've noticed is that the services, factories and
>> controllers inside those modules aren't being consistently named. We have
>> got a mix of:
>>
>> Launch Instance:
>>
>>   .module('horizon.dashboard.project.workflow.launch-instance')
>>   .factory('launchInstanceModel', launchInstanceModel);
>>
>> The new Images panel:
>>
>>   .module('horizon.app.core.images')
>>   .factory('horizon.app.core.images.row-actions.service', rowActions);
>>
>> and in the same patch:
>>
>>   .module('horizon.app.core.images')
>>   .factory('horizon.app.core.images.actions.deleteService',
>> deleteService);
>>
>> I actually prefer the second form because it matches the filename
>> ("row-actions.service.js") even though the module namespace doesn't match
>> the file path ("/static/app/core/images/table/").
>>
>> Your 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
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon][stable] Horizon kilo gate fails due to testrepository dependency

[Tony Breeds]

On Tue, Jan 05, 2016 at 12:26:24PM +1300, Robert Collins wrote:
> On 5 January 2016 at 12:04, Robert Collins  wrote:
> ...
> > Indeed - 
> > https://bitbucket.org/pypa/setuptools/commits/fb35fcade302fa828d34e6aff952ec2398f2c877?at=get_command_list
> > - the failing bit AFAICT is indeed new code :/.
> 
> 
> Ok, so I've paged this all in. Here's whats up, and some thoughts on fixing 
> it.
> 
> Old pbr does indeed have a bug where 'setup.py test' will error with
> that unguarded import of what isn't meant to be a dependency.
> 
> The reason this started failing is that a bugfix to setuptools - so
> that the existing pbr code that wraps commands can wrap commands only
> added by setuptools plugins like 'wheel' was merged and included in a
> setuptools release.
> 
> This causes the pbr testr command to be loaded, which fails in old pbr.
> 
> The right answer is a back port of the import guard to pbr < 1.0.0 and
> a point release - 0.11.1.
> 
> IMO that is :)

I noticed:

http://logs.openstack.org/periodic-stable/periodic-horizon-python27-kilo/45f1797/tox/py27-2.log
so I went to do the back port and found it's already been done #winning!

Sachi King did it here:
 * https://review.openstack.org/#/c/263928/ which is ready to merge BUT it 
depends on
 * https://review.openstack.org/#/c/264010 which needs additional +2 +W's

It's be great if we could get a kilo (0.11.1) release to unblock 
periodic-horizon-python27-kilo

Yours Tony.


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

Re: [openstack-dev] [Horizon] Updating XStatic packages

[Rajat Vig]

I did update some of the low hanging packages where the upgrades seemed
safe to do and noted the patch numbers in the same EtherPad.

I wasn't sure what to mark the effort against. So I created some bugs.
Should it be a blueprint?

-Rajat

On Wed, Jan 6, 2016 at 2:18 AM, Rob Cresswell (rcresswe)  wrote:

> Hi all,
>
> While the automated system is broken, I’d like to work on manually
> releasing a few of the XStatic packages. This will *only* be the release
> stage; we will still use gerrit to review the package content as usual.
>
> List of packages current versions, and their upstreams, can be found here:
> https://etherpad.openstack.org/p/horizon-libs
>
> If anyone has spare time, please consider investigating some of the
> dependencies listed above. To update an XStatic package, propose a change
> to its repo as you would with Horizon; they are all in the OpenStack
> namespace. For example, Xstatic-Angular can be found at
> http://git.openstack.org/cgit/openstack/xstatic-angular/
>
> Thanks,
> Rob
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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] naming of Javascript bits

[Rajat Vig]

Richard

My preference is the same as what you've got there.
Fully namespaced Services and Controller allow for better reusability and
possibly maintainability.
If all "deleteService" were named just that, it'll be mighty confusing to
use it in other places.

With regards to tying the folder path and the Service/Controller I'd mostly
go with that as that encourages simpler rules on how to namespace.

For the particular patch you mentioned, the namespaces had a bit of churn
which is sort of reflected in what exists in the patch now.

If we decide a convention, then we can go and change the bits when the
files change next.

-Rajat



On Wed, Jan 6, 2016 at 10:30 PM Richard Jones 
wrote:

> Hi Horizon folks,
>
> We've been pretty good about namespacing the new angular code (to the
> extreme of having a bunch of very similar module files littered around, but
> that's angular/JS for you, so I'm not going to go on about it ).
>
> Anyhoo. One thing I've noticed is that the services, factories and
> controllers inside those modules aren't being consistently named. We have
> got a mix of:
>
> Launch Instance:
>
>   .module('horizon.dashboard.project.workflow.launch-instance')
>   .factory('launchInstanceModel', launchInstanceModel);
>
> The new Images panel:
>
>   .module('horizon.app.core.images')
>   .factory('horizon.app.core.images.row-actions.service', rowActions);
>
> and in the same patch:
>
>   .module('horizon.app.core.images')
>   .factory('horizon.app.core.images.actions.deleteService', deleteService);
>
> I actually prefer the second form because it matches the filename
> ("row-actions.service.js") even though the module namespace doesn't match
> the file path ("/static/app/core/images/table/").
>
> Your 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
>
__
OpenStack Development Mailing 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][help][angularjs] facing issue with my angularjs patch

[masco]

Hello All,
I am I am adding QoS panel in angularjs.
i have submitted a patch for adding panel with delete action button in 
this patch https://review.openstack.org/#/c/247997/ it is working as 
expected.
over that i have added for edit QoS policy action in this patch 
https://review.openstack.org/#/c/259022/

this not working as expected.
the problem is:
when i am clicking the edit policy button the form widget is opening but 
there is no content in that.

no error in console too.
anybody familiar with angularjs can look into this patch and correct me 
where i am wrong.
it is blocking me to add other action buttons for the same. so any help 
will be very much appreciated.

how to test the QoS patch is available in commit message.

Thanks in advance,
Masco.

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

Re: [openstack-dev] [Horizon][stable] Horizon kilo gate fails due to testrepository dependency

[Matthias Runge]

On Tue, Jan 05, 2016 at 12:26:24PM +1300, Robert Collins wrote:
> On 5 January 2016 at 12:04, Robert Collins  wrote:
> ...
> > Indeed - 
> > https://bitbucket.org/pypa/setuptools/commits/fb35fcade302fa828d34e6aff952ec2398f2c877?at=get_command_list
> > - the failing bit AFAICT is indeed new code :/.
> 
> 
> Ok, so I've paged this all in. Here's whats up, and some thoughts on fixing 
> it.
> 
> Old pbr does indeed have a bug where 'setup.py test' will error with
> that unguarded import of what isn't meant to be a dependency.
> 
> The reason this started failing is that a bugfix to setuptools - so
> that the existing pbr code that wraps commands can wrap commands only
> added by setuptools plugins like 'wheel' was merged and included in a
> setuptools release.
> 
> This causes the pbr testr command to be loaded, which fails in old pbr.
> 
> The right answer is a back port of the import guard to pbr < 1.0.0 and
> a point release - 0.11.1.
> 
> IMO that is :)
> 
> I see that a workaround has been committed - installing testrepository
> - but I'd hate for folk to cargo cult the idea that pbr could have a
> runtime dependency on test-only tools like that.

Rob,

thank you for looking deeper into this. Your conclusions sound logical
to me and much saner than just pulling in testrepository.

Matthias
-- 
Matthias Runge 

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

Re: [openstack-dev] [Horizon][stable] Horizon kilo gate fails due to testrepository dependency

[Jordan Pittier]

On Tue, Jan 5, 2016 at 9:16 AM, Matthias Runge  wrote:

> On Tue, Jan 05, 2016 at 12:26:24PM +1300, Robert Collins wrote:
> > On 5 January 2016 at 12:04, Robert Collins 
> wrote:
> > ...
> > > Indeed -
> https://bitbucket.org/pypa/setuptools/commits/fb35fcade302fa828d34e6aff952ec2398f2c877?at=get_command_list
> > > - the failing bit AFAICT is indeed new code :/.
> >
> >
> > Ok, so I've paged this all in. Here's whats up, and some thoughts on
> fixing it.
> >
> > Old pbr does indeed have a bug where 'setup.py test' will error with
> > that unguarded import of what isn't meant to be a dependency.
> >
> > The reason this started failing is that a bugfix to setuptools - so
> > that the existing pbr code that wraps commands can wrap commands only
> > added by setuptools plugins like 'wheel' was merged and included in a
> > setuptools release.
> >
> > This causes the pbr testr command to be loaded, which fails in old pbr.
> >
> > The right answer is a back port of the import guard to pbr < 1.0.0 and
> > a point release - 0.11.1.
>

There's no 0.11 branch in PBR to which we could cherry-pick
https://git.openstack.org/cgit/openstack-dev/pbr/commit/?id=946cf80b750f3735a5d3b0c2173f4eaa7fad4a81
There's only a 0.10 branch.
__
OpenStack Development Mailing 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] Bug Day 2

[Rob Cresswell (rcresswe)]

Hi folks,

I think we should have another bug day to continue the good work started last 
time. I’d suggest Tuesday the 12th of January, as most people should be back at 
work by then. We can use the same etherpad too: 
https://etherpad.openstack.org/p/horizon-bug-day

For those not around for the previous one, the bug day is used to review our 
bug reports on Launchpad, and discuss them in IRC. This may be asking for help 
recreating an issue, whether a bug has been fixed etc. The goal is to have an 
organised, prioritised list of valid bug reports. Open new bugs if you stumble 
across them, but bug discovery is not the focus here.

Regards,
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

Re: [openstack-dev] [Horizon][Neutron] dashboard repository for neutron subprojects

[Ihar Hrachyshka]

Akihiro Motoki  wrote:


[Packaging perspective]

I am not sure how it affects.
There is one concern as a package consumer.

Getting additional packages through distro channels can be surprisingly  
difficult for new packages. :/


How neutron team can answer to this?
I think it is not specific to neutron subproject dashboard discussion.
Neutron stadium mode already has this problem.
Input from packaging side would be appreciated.


Distributions should work on fixing their processes. That’s what RDO  
project is going through right now (f.e. we got rid of Fedora package  
review process [that usually took too much time] as a prerequisite step for  
inclusion). But if you still feel issues with proposing a new package for  
RDO for neutron bits, please talk to me.


Ihar

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

Re: [openstack-dev] [Horizon][stable] Horizon kilo gate fails due to testrepository dependency

[Itxaka Serrano Garcia]

Same issue on django_openstack_auth, kilo branch:

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


And same error too [0]:

2016-01-04 10:47:17.621 | Obtaining file:///opt/stack/new/keystone
2016-01-04 10:47:18.251 | Complete output from command python
setup.py egg_info:
2016-01-04 10:47:18.251 | ERROR:root:Error parsing
2016-01-04 10:47:18.251 | Traceback (most recent call last):
2016-01-04 10:47:18.251 |   File
"/usr/local/lib/python2.7/dist-packages/pbr/core.py", line 109, in pbr
2016-01-04 10:47:18.251 | attrs = util.cfg_to_args(path)
2016-01-04 10:47:18.251 |   File
"/usr/local/lib/python2.7/dist-packages/pbr/util.py", line 261, in
cfg_to_args
2016-01-04 10:47:18.251 | wrap_commands(kwargs)
2016-01-04 10:47:18.251 |   File
"/usr/local/lib/python2.7/dist-packages/pbr/util.py", line 482, in
wrap_commands
2016-01-04 10:47:18.251 | for cmd, _ in dist.get_command_list():
2016-01-04 10:47:18.251 |   File
"/usr/local/lib/python2.7/dist-packages/setuptools/dist.py", line 446,
in get_command_list
2016-01-04 10:47:18.251 | cmdclass = ep.resolve()
2016-01-04 10:47:18.251 |   File
"/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line
2386, in resolve
2016-01-04 10:47:18.251 | module = __import__(self.module_name,
fromlist=['__name__'], level=0)
2016-01-04 10:47:18.251 |   File
"/usr/local/lib/python2.7/dist-packages/pbr/testr_command.py", line 47,
in 
2016-01-04 10:47:18.251 | from testrepository import commands
2016-01-04 10:47:18.251 | ImportError: No module named testrepository
2016-01-04 10:47:18.251 | error in setup command: Error parsing
/opt/stack/new/keystone/setup.cfg: ImportError: No module named
testrepository




[0]
http://logs.openstack.org/78/262778/2/check/gate-tempest-dsvm-neutron-src-django_openstack_auth/01220e8/logs/devstacklog.txt.gz


On 01/04/2016 09:13 AM, Matthias Runge wrote:

Hello,

did we had a recent change in stable tests for Kilo?

Horizon tests for kilo are now failing due to a missing dependency to
testrepository. Horizon never used testrepository (until recently,
where I added testr support, but only in mitaka branch).

As a test, I added a test dependency for kilo branch, but that fails
somewhere else due to missing testrepository:

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

The error is in [1] somewhere at the bottom:

É5-12-30 09:53:27.883 | Obtaining file:///opt/stack/new/keystone
2015-12-30 09:53:28.504 | Complete output from command python
setup.py egg_info:
2015-12-30 09:53:28.504 | ERROR:root:Error parsing
2015-12-30 09:53:28.504 | Traceback (most recent call last):
2015-12-30 09:53:28.504 |   File
"/usr/local/lib/python2.7/dist-packages/pbr/core.py", line 109, in pbr
2015-12-30 09:53:28.504 | attrs = util.cfg_to_args(path)
2015-12-30 09:53:28.504 |   File
"/usr/local/lib/python2.7/dist-packages/pbr/util.py", line 261, in
cfg_to_args
2015-12-30 09:53:28.504 | wrap_commands(kwargs)
2015-12-30 09:53:28.504 |   File
"/usr/local/lib/python2.7/dist-packages/pbr/util.py", line 482, in
wrap_commands
2015-12-30 09:53:28.504 | for cmd, _ in dist.get_command_list():
2015-12-30 09:53:28.504 |   File
"/usr/local/lib/python2.7/dist-packages/setuptools/dist.py", line 446,
in get_command_list
2015-12-30 09:53:28.504 | cmdclass = ep.resolve()
2015-12-30 09:53:28.505 |   File
"/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line
2386, in resolve
2015-12-30 09:53:28.505 | module = __import__(self.module_name,
fromlist=['__name__'], level=0)
2015-12-30 09:53:28.505 |   File
"/usr/local/lib/python2.7/dist-packages/pbr/testr_command.py", line 47,
in 
2015-12-30 09:53:28.505 | from testrepository import commands
2015-12-30 09:53:28.505 | ImportError: No module named
testrepository
2015-12-30 09:53:28.505 | error in setup command: Error parsing
/opt/stack/new/keystone/setup.cfg: ImportError: No module named
testrepository

Any suggestions here?

[1]
http://logs.openstack.org/96/262296/2/check/gate-tempest-dsvm-full/e47e5c6/logs/devstacklog.txt.gz





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

Re: [openstack-dev] [Horizon][stable] Horizon kilo gate fails due to testrepository dependency

[Ihar Hrachyshka]

Matthias Runge  wrote:


Hello,

did we had a recent change in stable tests for Kilo?

Horizon tests for kilo are now failing due to a missing dependency to
testrepository. Horizon never used testrepository (until recently,
where I added testr support, but only in mitaka branch).

As a test, I added a test dependency for kilo branch, but that fails
somewhere else due to missing testrepository:

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

The error is in [1] somewhere at the bottom:

É5-12-30 09:53:27.883 | Obtaining file:///opt/stack/new/keystone
2015-12-30 09:53:28.504 | Complete output from command python
setup.py egg_info:
2015-12-30 09:53:28.504 | ERROR:root:Error parsing
2015-12-30 09:53:28.504 | Traceback (most recent call last):
2015-12-30 09:53:28.504 |   File
"/usr/local/lib/python2.7/dist-packages/pbr/core.py", line 109, in pbr
2015-12-30 09:53:28.504 | attrs = util.cfg_to_args(path)
2015-12-30 09:53:28.504 |   File
"/usr/local/lib/python2.7/dist-packages/pbr/util.py", line 261, in
cfg_to_args
2015-12-30 09:53:28.504 | wrap_commands(kwargs)
2015-12-30 09:53:28.504 |   File
"/usr/local/lib/python2.7/dist-packages/pbr/util.py", line 482, in
wrap_commands
2015-12-30 09:53:28.504 | for cmd, _ in dist.get_command_list():
2015-12-30 09:53:28.504 |   File
"/usr/local/lib/python2.7/dist-packages/setuptools/dist.py", line 446,
in get_command_list
2015-12-30 09:53:28.504 | cmdclass = ep.resolve()
2015-12-30 09:53:28.505 |   File
"/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line
2386, in resolve
2015-12-30 09:53:28.505 | module = __import__(self.module_name,
fromlist=['__name__'], level=0)
2015-12-30 09:53:28.505 |   File
"/usr/local/lib/python2.7/dist-packages/pbr/testr_command.py", line 47,
in 
2015-12-30 09:53:28.505 | from testrepository import commands
2015-12-30 09:53:28.505 | ImportError: No module named
testrepository
2015-12-30 09:53:28.505 | error in setup command: Error parsing
/opt/stack/new/keystone/setup.cfg: ImportError: No module named
testrepository

Any suggestions here?


Seems like pbr importing testrepository, hence the dependency belongs to  
pbr, not horizon (and as a runtime dependency, not just test only).


But note that since pbr 1.1.0, they no longer depend on the package and  
fail gracefully:


https://github.com/openstack-dev/pbr/commit/946cf80b750f3735a5d3b0c2173f4eaa7fad4a81

So the proper way would be indeed to make your package to install testr for  
tests. Not sure why it worked before, but I would bet that some other  
components installed it for you (devstack? devstack-gate? job definition?  
some other component previously installed before keystone? Not that it’s  
too important.)


Ihar

__
OpenStack Development Mailing 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] Horizon kilo gate fails due to testrepository dependency

[Matthias Runge]

Hello,

did we had a recent change in stable tests for Kilo?

Horizon tests for kilo are now failing due to a missing dependency to
testrepository. Horizon never used testrepository (until recently,
where I added testr support, but only in mitaka branch).

As a test, I added a test dependency for kilo branch, but that fails
somewhere else due to missing testrepository:

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

The error is in [1] somewhere at the bottom:

É5-12-30 09:53:27.883 | Obtaining file:///opt/stack/new/keystone
2015-12-30 09:53:28.504 | Complete output from command python
setup.py egg_info:
2015-12-30 09:53:28.504 | ERROR:root:Error parsing
2015-12-30 09:53:28.504 | Traceback (most recent call last):
2015-12-30 09:53:28.504 |   File
"/usr/local/lib/python2.7/dist-packages/pbr/core.py", line 109, in pbr
2015-12-30 09:53:28.504 | attrs = util.cfg_to_args(path)
2015-12-30 09:53:28.504 |   File
"/usr/local/lib/python2.7/dist-packages/pbr/util.py", line 261, in
cfg_to_args
2015-12-30 09:53:28.504 | wrap_commands(kwargs)
2015-12-30 09:53:28.504 |   File
"/usr/local/lib/python2.7/dist-packages/pbr/util.py", line 482, in
wrap_commands
2015-12-30 09:53:28.504 | for cmd, _ in dist.get_command_list():
2015-12-30 09:53:28.504 |   File
"/usr/local/lib/python2.7/dist-packages/setuptools/dist.py", line 446,
in get_command_list
2015-12-30 09:53:28.504 | cmdclass = ep.resolve()
2015-12-30 09:53:28.505 |   File
"/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line
2386, in resolve
2015-12-30 09:53:28.505 | module = __import__(self.module_name,
fromlist=['__name__'], level=0)
2015-12-30 09:53:28.505 |   File
"/usr/local/lib/python2.7/dist-packages/pbr/testr_command.py", line 47,
in 
2015-12-30 09:53:28.505 | from testrepository import commands
2015-12-30 09:53:28.505 | ImportError: No module named
testrepository
2015-12-30 09:53:28.505 | error in setup command: Error parsing
/opt/stack/new/keystone/setup.cfg: ImportError: No module named
testrepository

Any suggestions here?

[1]
http://logs.openstack.org/96/262296/2/check/gate-tempest-dsvm-full/e47e5c6/logs/devstacklog.txt.gz
-- 
Matthias Runge 

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

Re: [openstack-dev] [Horizon][stable] Horizon kilo gate fails due to testrepository dependency

[Robert Collins]

On 5 January 2016 at 11:59, Robert Collins  wrote:
> This is odd indeed. pbr is not meant to have a dep on testrepository,
> and you can see in
> https://git.openstack.org/cgit/openstack-dev/pbr/tree/pbr/testr_command.py#n150
> that we only access it if it is installed and we use latest pbr
> everywhere because otherwise we can't deal with ecosystem changes to
> e.g. setuptools or pip.
>
> http://logs.openstack.org/96/262296/2/check/gate-tempest-dsvm-full/e47e5c6/logs/devstacklog.txt.gz#_2015-12-30_09_53_14_200
> shows that the latest pbr (1.8.1 which would work) is being
> downgraded. Thats when the problem is introduced. However, kilo has
> that special thing where pbr is capped because a lot of dependencies
> error due to version disagreements (not API breaks - pbr is
> compatible!), so this is expected :(.
>
> I'm not sure what has caused testrepository to not be installed in
> this scenario, but thats what I'd be looking at.
>

Further to that, I suspect setuptools may have changed -
https://pypi.python.org/pypi/setuptools - 19.2 was released
suspiciously close to the point errors were reported (25th dec).

Looking now..

-Rob


-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] Mid-cycle Sprint

[Thai Q Tran]

FYI, Cindy and I will put in a request for travel approval. Also, I have spoken to Mariam and would be willing to mentor David.
 
- Original message -From: David Lyle <dkly...@gmail.com>To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org>Cc:Subject: [openstack-dev] [Horizon] Mid-cycle SprintDate: Mon, Dec 28, 2015 11:22 AM 
The Horizon mid-cycle sprint is in Hillsboro, Oregon Feb 23-25 andhosted at the Intel site in Hillsboro just west of Portland.The wiki for the mid-cycle sprint ishttps://wiki.openstack.org/wiki/Sprints/HorizonMitakaSprintPlease note your intention to attend on the wiki page.Thanks,David__OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
 


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

Re: [openstack-dev] [Horizon][stable] Horizon kilo gate fails due to testrepository dependency

[Ihar Hrachyshka]

Matthias Runge  wrote:


On Mon, Jan 04, 2016 at 12:29:27PM +0100, Ihar Hrachyshka wrote:

Matthias Runge  wrote:

testrepository

Any suggestions here?


Seems like pbr importing testrepository, hence the dependency belongs to
pbr, not horizon (and as a runtime dependency, not just test only).

But note that since pbr 1.1.0, they no longer depend on the package and  
fail

gracefully:

https://github.com/openstack-dev/pbr/commit/946cf80b750f3735a5d3b0c2173f4eaa7fad4a81

So the proper way would be indeed to make your package to install testr  
for

tests. Not sure why it worked before, but I would bet that some other
components installed it for you (devstack? devstack-gate? job definition?
some other component previously installed before keystone? Not that it’s  
too

important.)

Ihar


Thank you.

I'm a bit confused, why it worked before e.g Dec 20th last year, but
fails after.
And it's only failing in kilo, not on liberty.

And even when adding testrepository to test-requirements, it fails,
because it's missing?

If pbr uses testrepository at run-time, it should be pulled in as
run-time requirement.


Note that it’s keystone installation that fails, not horizon, and it seems  
that it’s for grenade (I see /opt/stack/new/keystone in the logs). I would  
expect keystone gate to be broken too, so you could add the dep there and  
validate whether it fixes the thing for you.


The best alternative outcome is probably to get a new ‘kilo’ (<1.0) pbr  
release that would pull in the dependency for you.


Ihar

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

Re: [openstack-dev] [Horizon][stable][tempest] Horizon|tempest kilo gate fails due to testrepository dependency

[Matthias Runge]

On Mon, Jan 04, 2016 at 01:32:53PM +0100, Ihar Hrachyshka wrote:
> Note that it’s keystone installation that fails, not horizon, and it seems
> that it’s for grenade (I see /opt/stack/new/keystone in the logs). I would
> expect keystone gate to be broken too, so you could add the dep there and
> validate whether it fixes the thing for you.
> 
> The best alternative outcome is probably to get a new ‘kilo’ (<1.0) pbr
> release that would pull in the dependency for you.
> 

keystone fails after adding testrepository to horizons test
requirements.

Horizon failed before, if we don't add it. Horizon does not use testr at
all.
http://logs.openstack.org/periodic-stable/periodic-horizon-python27-kilo/3fc703b/tox/py27-2.log

It looks like keystone does not fail,
but tempest fails in the same way as horizon does:
http://logs.openstack.org/periodic-stable/periodic-tempest-dsvm-full-kilo/a33736f/logs/devstacklog.txt.gz
-- 
Matthias Runge 

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

Re: [openstack-dev] [Horizon][stable][tempest] Horizon|tempest kilo gate fails due to testrepository dependency

[Ihar Hrachyshka]

Matthias Runge  wrote:


On Mon, Jan 04, 2016 at 01:32:53PM +0100, Ihar Hrachyshka wrote:

Note that it’s keystone installation that fails, not horizon, and it seems
that it’s for grenade (I see /opt/stack/new/keystone in the logs). I would
expect keystone gate to be broken too, so you could add the dep there and
validate whether it fixes the thing for you.

The best alternative outcome is probably to get a new ‘kilo’ (<1.0) pbr
release that would pull in the dependency for you.


keystone fails after adding testrepository to horizons test
requirements.


But have you tried to add the dep to keystone test reqs?

Ihar

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

Re: [openstack-dev] [Horizon][stable] Horizon kilo gate fails due to testrepository dependency

[Matthias Runge]

On Mon, Jan 04, 2016 at 12:29:27PM +0100, Ihar Hrachyshka wrote:
> Matthias Runge  wrote:
> >testrepository
> >
> >Any suggestions here?
> 
> Seems like pbr importing testrepository, hence the dependency belongs to
> pbr, not horizon (and as a runtime dependency, not just test only).
> 
> But note that since pbr 1.1.0, they no longer depend on the package and fail
> gracefully:
> 
> https://github.com/openstack-dev/pbr/commit/946cf80b750f3735a5d3b0c2173f4eaa7fad4a81
> 
> So the proper way would be indeed to make your package to install testr for
> tests. Not sure why it worked before, but I would bet that some other
> components installed it for you (devstack? devstack-gate? job definition?
> some other component previously installed before keystone? Not that it’s too
> important.)
> 
> Ihar

Thank you.

I'm a bit confused, why it worked before e.g Dec 20th last year, but
fails after.
And it's only failing in kilo, not on liberty.

And even when adding testrepository to test-requirements, it fails,
because it's missing?

If pbr uses testrepository at run-time, it should be pulled in as
run-time requirement.
-- 
Matthias Runge 

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

Re: [openstack-dev] [Horizon][stable] Horizon kilo gate fails due to testrepository dependency

[Matthias Runge]

On 04/01/16 15:41, Ihar Hrachyshka wrote:
> UPD: Turns out it breaks Liberty gate too, f.e. for Neutron. It’s
> interesting that it did not break the thing for e.g. Neutron master.
> 
> Matthias Runge  wrote:
> 
>> Hello,
>>

Horizon in Kilo *only* fails since Dec 26th. Horizon liberty seems to be
fine.

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

Re: [openstack-dev] [Horizon][stable] Horizon kilo gate fails due to testrepository dependency

[Ihar Hrachyshka]

UPD: Turns out it breaks Liberty gate too, f.e. for Neutron. It’s  
interesting that it did not break the thing for e.g. Neutron master.


Matthias Runge  wrote:


Hello,

did we had a recent change in stable tests for Kilo?

Horizon tests for kilo are now failing due to a missing dependency to
testrepository. Horizon never used testrepository (until recently,
where I added testr support, but only in mitaka branch).

As a test, I added a test dependency for kilo branch, but that fails
somewhere else due to missing testrepository:

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

The error is in [1] somewhere at the bottom:

É5-12-30 09:53:27.883 | Obtaining file:///opt/stack/new/keystone
2015-12-30 09:53:28.504 | Complete output from command python
setup.py egg_info:
2015-12-30 09:53:28.504 | ERROR:root:Error parsing
2015-12-30 09:53:28.504 | Traceback (most recent call last):
2015-12-30 09:53:28.504 |   File
"/usr/local/lib/python2.7/dist-packages/pbr/core.py", line 109, in pbr
2015-12-30 09:53:28.504 | attrs = util.cfg_to_args(path)
2015-12-30 09:53:28.504 |   File
"/usr/local/lib/python2.7/dist-packages/pbr/util.py", line 261, in
cfg_to_args
2015-12-30 09:53:28.504 | wrap_commands(kwargs)
2015-12-30 09:53:28.504 |   File
"/usr/local/lib/python2.7/dist-packages/pbr/util.py", line 482, in
wrap_commands
2015-12-30 09:53:28.504 | for cmd, _ in dist.get_command_list():
2015-12-30 09:53:28.504 |   File
"/usr/local/lib/python2.7/dist-packages/setuptools/dist.py", line 446,
in get_command_list
2015-12-30 09:53:28.504 | cmdclass = ep.resolve()
2015-12-30 09:53:28.505 |   File
"/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line
2386, in resolve
2015-12-30 09:53:28.505 | module = __import__(self.module_name,
fromlist=['__name__'], level=0)
2015-12-30 09:53:28.505 |   File
"/usr/local/lib/python2.7/dist-packages/pbr/testr_command.py", line 47,
in 
2015-12-30 09:53:28.505 | from testrepository import commands
2015-12-30 09:53:28.505 | ImportError: No module named
testrepository
2015-12-30 09:53:28.505 | error in setup command: Error parsing
/opt/stack/new/keystone/setup.cfg: ImportError: No module named
testrepository

Any suggestions here?

[1]
http://logs.openstack.org/96/262296/2/check/gate-tempest-dsvm-full/e47e5c6/logs/devstacklog.txt.gz
--
Matthias Runge 

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



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

Re: [openstack-dev] [Horizon][stable] Horizon kilo gate fails due to testrepository dependency

[Michał Dulko]

On 01/04/2016 03:41 PM, Ihar Hrachyshka wrote:
> UPD: Turns out it breaks Liberty gate too, f.e. for Neutron. It’s
> interesting that it did not break the thing for e.g. Neutron master.
>
> Matthias Runge  wrote:

We observe this on Cinder's stable/liberty in Grenade tests (e.g. [1])
and on stable/kilo in whole Tempest (e.g. [2]).

[1] https://review.openstack.org/#/c/262162/
[2] https://review.openstack.org/#/c/246646/

__
OpenStack Development Mailing 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][infra] django.pot hardcoded or not?

[Andreas Jaeger]

On 12/30/2015 11:27 PM, Clark Boylan wrote:

The problem with using a tox target is that we use privileged Jenkins
machines to do the extraction and don't want arbitrary code to run on
them. It would be possible to run arbitrary code if we used a tox
target.


Clark, we run already "run_messages.sh --makemessages", isn't that 
already a problem?


Andreas
--
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
OpenStack Development Mailing 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][infra] django.pot hardcoded or not?

[Andreas Jaeger]

I'm currently looking into simplifying and consolidation of translation 
setup for projects (draft spec at [1]) and have a question for dashboard 
translations. Right now, horizon uses django.pot and djangojs.pot - and 
most *-dashboard projects use the same names. Are these names enforced 
by the django framework and thus cannot be changed or are they setup in 
our repositories this way and thus could be changed?


I prefer to rename them to make it clearer which project they belong to 
as part of my spec and would like your input on whether that's feasible.


Note: Once the spec is fleshed out, I'll send another email asking for 
review...


Andreas

References:
[1] https://review.openstack.org/262545

--
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
OpenStack Development Mailing 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][infra] django.pot hardcoded or not?

[Akihiro Motoki]

I haven't looked into the code detail, but as far as I read
https://docs.djangoproject.com/en/1.9/topics/i18n/translation/#specialties-of-django-translation
it is enforced by django framework.

How django searches message catalogs is described at
https://docs.djangoproject.com/en/1.9/topics/i18n/translation/#how-django-discovers-translations.
In addition, django requires separate string domains for python part
and JavaScript part.

I don't think it is easy to change this.

I think it is better to define a tox target to extract message catalogs
instead of using "tox -e venv - ".

Akihiro


2015-12-31 0:42 GMT+09:00 Andreas Jaeger :
> I'm currently looking into simplifying and consolidation of translation
> setup for projects (draft spec at [1]) and have a question for dashboard
> translations. Right now, horizon uses django.pot and djangojs.pot - and most
> *-dashboard projects use the same names. Are these names enforced by the
> django framework and thus cannot be changed or are they setup in our
> repositories this way and thus could be changed?
>
> I prefer to rename them to make it clearer which project they belong to as
> part of my spec and would like your input on whether that's feasible.
>
> Note: Once the spec is fleshed out, I'll send another email asking for
> review...
>
> Andreas
>
> References:
> [1] https://review.openstack.org/262545
>
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [Horizon] Mid-cycle Sprint

[David Lyle]

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

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

Please note your intention to attend on the wiki page.

Thanks,
David

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

Re: [openstack-dev] [Horizon][Neutron] dashboard repository for neutron subprojects

[Fawad Khaliq]

On Wed, Dec 23, 2015 at 9:16 PM, Akihiro Motoki  wrote:

> Are there no comment after I added more detail?
> No inputs from both horizon and neutron side.
>
> Although Horizon team is tackling to address some problems around
> horizon plugin mechanism
> such as translations, I think option (c) requires neutron subprojects
> to do some extra efforts
> around infra scripts. They are specific to neutron subproject
> directory structure and neutron
> subprojects should be responsible to deal with them as option (c) is a
> choice of neutron side.
> please check the details of my previous post.
>
> I am not sure it is okay to neutron suboprojects?
>
I think option (c) would work fine. My vote would be to go with it. Would
be best if someone could capture a devref around this similar to what
HenryG did around DB and alembic for subprojects.

>
> Akihiro
>
>
> 2015-12-02 17:23 GMT+09:00 Akihiro Motoki :
> > Thanks all.
> > All comments so far are from neutron side. I would like to wait inputs
> > from horizon side, especially David.
> >
> > Option (c) is what we do in neutron sub-projects under neutron stadium
> model and
> > I agree it makes sense and sounds natural to neutron folks.
> >
> > My initial mail just did not cover technical points or horizon
> > developer perspective
> > if we go to option (c). Let me share them.
> >
> > [Horizon developer perspective]
> >
> > I think we need some collaboration points between neutron subprojects
> > and horizon team (+ UX team).
> > to share knowledge or conventions in the dashboard development.
> > Not so many neutron developers are aware of horizon side changes, so I
> > think Horizon side
> > needs to care of these repositories to some extent for better UX
> > consistency or framework changes.
> >
> > We are going to the self-management models in individual repos, so I
> believe
> > each team watches horizon side changes to some extent, and keep their
> > dashboard up-to-date.
> >
> > From Horizon point of view, it seems good to me if the following are
> done:
> >
> > - Use a consistent directory name for a dashboard support in each
> > repository (e.g., "dashboard")
> >   Gerrit support filename based query, so it allows horizon developers
> > can reach dashboard related reviews.
> > - Keep up-to-date Horizon plugin registry
> > http://docs.openstack.org/developer/horizon/plugins.html
> > - Use horizon plugin model rather than adhoc approach
> > - Documentation on config options (at now, horizon does not support
> > oslo.config generator)
> >
> > [Technical topics]
> >
> > - We need to have two testing setup for both neutron and horizon.
> >   I think most dashboard tests depend on Horizon (or at least Django)
> >
> > - Does (test-)requirements.txt contain neutron and horizon dependencies?
> >   For horizon itself, perhaps no. Our test tool chains should install
> horizon
> >   as we do for neutron dependency.
> >   For other requirements, I am not sure at this moment.
> >
> > - Separate translation support for dashboard and server code.
> >   Django and oslo.i18n (python gettext) use different approach to find
> > translation catalog,
> >   so we need to prepare a separate tool chain for both translation
> catalog.
> >   It requires the infra script change.
> >
> >   # Normal Horizon plugin translation support is an ongoing effort,
> >   # but option (c) needs extra effort.
> >
> > [Packaging perspective]
> >
> > I am not sure how it affects.
> > There is one concern as a package consumer.
> >
> >> Getting additional packages through distro channels can be surprisingly
> difficult for new packages. :/
> >
> > How neutron team can answer to this?
> > I think it is not specific to neutron subproject dashboard discussion.
> > Neutron stadium mode already has this problem.
> > Input from packaging side would be appreciated.
> >
> > Thanks,
> > Akihiro
> >
> > 2015-11-25 14:46 GMT+09:00 Akihiro Motoki :
> >> Hi,
> >>
> >> Neutron has now various subprojects and some of them would like to
> >> implement Horizon supports. Most of them are additional features.
> >> I would like to start the discussion where we should have horizon
> support.
> >>
> >> [Background]
> >> Horizon team introduced a plugin mechanism and we can add horizon panels
> >> from external repositories. Horizon team is recommending external repos
> for
> >> additional services for faster iteration and features.
> >> We have various horizon related repositories now [1].
> >>
> >> In Neutron related world, we have neutron-lbaas-dashboard and
> >> horizon-cisco-ui repos.
> >>
> >> [Possible options]
> >> There are several possible options for neutron sub-projects.
> >> My current vote is (b), and the next is (a). It looks a good balance to
> me.
> >> I would like to gather broader opinions,
> >>
> >> (a) horizon in-tree repo
> >> - [+] It was a legacy approach and there is no initial effort to setup
> a repo.
> >> - [+] Easy to share code 

Re: [openstack-dev] [Horizon] [Cinder] [Nova] [Neutron] Gathering quota usage data in Horizon

[Timur Sufiev]

Duncan,

Thank you for the suggestion, will do.
On Wed, 23 Dec 2015 at 10:55, Duncan Thomas  wrote:

> On a cloud with a large number of tenants, this is going to involve a
> large number of API calls. I'd suggest you put a spec into cinder to add an
> API call for getting the totals straight out of the DB - it should be easy
> enough to add.
>
> On 18 December 2015 at 20:35, Timur Sufiev  wrote:
>
>> Matt,
>>
>> actually Ivan (Ivan, thanks a lot!) showed me the exact cinderclient call
>> that I needed. Now I know how to retrieve Cinder quota usage info
>> per-tenant, seems that to retrieve the same info cloud-wide I should sum up
>> all the available tenant usages.
>>
>> With Cinder quota usages being sorted out, my next goal is Nova and
>> Neutron. As for Neutron, there are plenty of quota-related calls I'm going
>> to play with next week, perhaps there is something suitable for my use
>> case. But as for Nova, I haven't found something similar to 'usage' of
>> cinderclient call, so help from someone familiar with Nova is very
>> appreciated :).
>>
>> [0]
>> https://github.com/openstack/python-cinderclient/blob/master/cinderclient/v2/quotas.py#L36
>>
>> On Fri, Dec 18, 2015 at 5:17 PM Matt Riedemann <
>> mrie...@linux.vnet.ibm.com> wrote:
>>
>>>
>>>
>>> On 12/17/2015 2:40 PM, Ivan Kolodyazhny wrote:
>>> > Hi Timur,
>>> >
>>> > Did you try this Cinder API [1]?  Here [2] is cinderclient output.
>>> >
>>> >
>>> >
>>> > [1]
>>> >
>>> https://github.com/openstack/python-cinderclient/blob/master/cinderclient/v2/quotas.py#L33
>>> > [2] http://paste.openstack.org/show/482225/
>>> >
>>> > Regards,
>>> > Ivan Kolodyazhny,
>>> > http://blog.e0ne.info/
>>> >
>>> > On Thu, Dec 17, 2015 at 8:41 PM, Timur Sufiev >> > > wrote:
>>> >
>>> > Hello, folks!
>>> >
>>> > I'd like to initiate a discussion of the feature request I'm going
>>> > to make on behalf of Horizon to every core OpenStack service which
>>> > supports Quota feature, namely Cinder, Nova and Neutron.
>>> >
>>> > Although all three services' APIs support special calls to get
>>> > current quota limitations (Nova and Cinder allows to get and update
>>> > both per-tenant and default cloud-wide limitations, Neutron allows
>>> > to do it only for per-tenant limitations), there is no special call
>>> > in any of these services to get current per-tenant usage of quota.
>>> > Because of that Horizon needs to get, say for 'volumes' quota, a
>>> > list of Cinder volumes in the current tenant and then just
>>> calculate
>>> > its length [1]. When there are really a lot of entities in tenant -
>>> > instances/volumes/security groups/whatever - all this calls sum up
>>> > and make rendering pages in Horizon much more slower than it could
>>> > be. Is it possible to provide special API calls to alleviate this?
>>> >
>>> > [1]
>>> >
>>> https://github.com/openstack/horizon/blob/9.0.0.0b1/openstack_dashboard/usage/quotas.py#L350
>>> >
>>> >
>>>  __
>>> > OpenStack Development Mailing List (not for usage questions)
>>> > Unsubscribe:
>>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> > <
>>> http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>> >
>>> >
>>> >
>>> >
>>> __
>>> > OpenStack Development Mailing List (not for usage questions)
>>> > Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>>
>>> I think Timur is asking for a way to filter on only certain resources
>>> for quota usage/limits, like volumes in cinder or instances in nova,
>>> rather than getting back all resource usage/limits per tenant.
>>>
>>> Is that correct, Timur?
>>>
>>> While it's possible to add this, I'm not sure how much time it's
>>> actually going to save in the DB query time to get the quota information
>>> for a tenant.
>>>
>>> Anyway, it's an API change so it would require a spec for nova which
>>> means we wouldn't be getting to that until at least N since we're in
>>> spec freeze for mitaka.
>>>
>>> --
>>>
>>> Thanks,
>>>
>>> Matt Riedemann
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> 

Re: [openstack-dev] [Horizon] [Cinder] [Nova] [Neutron] Gathering quota usage data in Horizon

[Duncan Thomas]

On a cloud with a large number of tenants, this is going to involve a large
number of API calls. I'd suggest you put a spec into cinder to add an API
call for getting the totals straight out of the DB - it should be easy
enough to add.

On 18 December 2015 at 20:35, Timur Sufiev  wrote:

> Matt,
>
> actually Ivan (Ivan, thanks a lot!) showed me the exact cinderclient call
> that I needed. Now I know how to retrieve Cinder quota usage info
> per-tenant, seems that to retrieve the same info cloud-wide I should sum up
> all the available tenant usages.
>
> With Cinder quota usages being sorted out, my next goal is Nova and
> Neutron. As for Neutron, there are plenty of quota-related calls I'm going
> to play with next week, perhaps there is something suitable for my use
> case. But as for Nova, I haven't found something similar to 'usage' of
> cinderclient call, so help from someone familiar with Nova is very
> appreciated :).
>
> [0]
> https://github.com/openstack/python-cinderclient/blob/master/cinderclient/v2/quotas.py#L36
>
> On Fri, Dec 18, 2015 at 5:17 PM Matt Riedemann 
> wrote:
>
>>
>>
>> On 12/17/2015 2:40 PM, Ivan Kolodyazhny wrote:
>> > Hi Timur,
>> >
>> > Did you try this Cinder API [1]?  Here [2] is cinderclient output.
>> >
>> >
>> >
>> > [1]
>> >
>> https://github.com/openstack/python-cinderclient/blob/master/cinderclient/v2/quotas.py#L33
>> > [2] http://paste.openstack.org/show/482225/
>> >
>> > Regards,
>> > Ivan Kolodyazhny,
>> > http://blog.e0ne.info/
>> >
>> > On Thu, Dec 17, 2015 at 8:41 PM, Timur Sufiev > > > wrote:
>> >
>> > Hello, folks!
>> >
>> > I'd like to initiate a discussion of the feature request I'm going
>> > to make on behalf of Horizon to every core OpenStack service which
>> > supports Quota feature, namely Cinder, Nova and Neutron.
>> >
>> > Although all three services' APIs support special calls to get
>> > current quota limitations (Nova and Cinder allows to get and update
>> > both per-tenant and default cloud-wide limitations, Neutron allows
>> > to do it only for per-tenant limitations), there is no special call
>> > in any of these services to get current per-tenant usage of quota.
>> > Because of that Horizon needs to get, say for 'volumes' quota, a
>> > list of Cinder volumes in the current tenant and then just calculate
>> > its length [1]. When there are really a lot of entities in tenant -
>> > instances/volumes/security groups/whatever - all this calls sum up
>> > and make rendering pages in Horizon much more slower than it could
>> > be. Is it possible to provide special API calls to alleviate this?
>> >
>> > [1]
>> >
>> https://github.com/openstack/horizon/blob/9.0.0.0b1/openstack_dashboard/usage/quotas.py#L350
>> >
>> >
>>  __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > <
>> http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> >
>> >
>> >
>> >
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> I think Timur is asking for a way to filter on only certain resources
>> for quota usage/limits, like volumes in cinder or instances in nova,
>> rather than getting back all resource usage/limits per tenant.
>>
>> Is that correct, Timur?
>>
>> While it's possible to add this, I'm not sure how much time it's
>> actually going to save in the DB query time to get the quota information
>> for a tenant.
>>
>> Anyway, it's an API change so it would require a spec for nova which
>> means we wouldn't be getting to that until at least N since we're in
>> spec freeze for mitaka.
>>
>> --
>>
>> Thanks,
>>
>> Matt Riedemann
>>
>>
>> __
>> OpenStack Development Mailing 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
>
>


-- 
-- 
Duncan Thomas
__
OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [Horizon] [Cinder] [Nova] [Neutron] Gathering quota usage data in Horizon

[Timur Sufiev]

Hello, Matt

Just checked it, nova quota-show command just shows current quota limits
for a given tenant, below is an output for may Devstack admin tenant:

timur@devstack:~/devstack$ nova quota-show --tenant
9f6cc244fd9d41668d49c00f12b70219
+-+---+
| Quota   | Limit |
+-+---+
| instances   | 10|
| cores   | 20|
| ram | 51200 |
| floating_ips| 10|
| fixed_ips   | -1|
| metadata_items  | 128   |
| injected_files  | 5 |
| injected_file_content_bytes | 10240 |
| injected_file_path_bytes| 255   |
| key_pairs   | 100   |
| security_groups | 10|
| security_group_rules| 20|
| server_groups   | 10|
| server_group_members| 10|
+-+---+


On Sat, Dec 19, 2015 at 5:58 PM Matt Riedemann 
wrote:

>
>
> On 12/18/2015 12:35 PM, Timur Sufiev wrote:
> > Matt,
> >
> > actually Ivan (Ivan, thanks a lot!) showed me the exact cinderclient
> > call that I needed. Now I know how to retrieve Cinder quota usage info
> > per-tenant, seems that to retrieve the same info cloud-wide I should sum
> > up all the available tenant usages.
> >
> > With Cinder quota usages being sorted out, my next goal is Nova and
> > Neutron. As for Neutron, there are plenty of quota-related calls I'm
> > going to play with next week, perhaps there is something suitable for my
> > use case. But as for Nova, I haven't found something similar to 'usage'
> > of cinderclient call, so help from someone familiar with Nova is very
> > appreciated :).
> >
> > [0]
> >
> https://github.com/openstack/python-cinderclient/blob/master/cinderclient/v2/quotas.py#L36
> >
> > On Fri, Dec 18, 2015 at 5:17 PM Matt Riedemann
> > > wrote:
> >
> >
> >
> > On 12/17/2015 2:40 PM, Ivan Kolodyazhny wrote:
> >  > Hi Timur,
> >  >
> >  > Did you try this Cinder API [1]?  Here [2] is cinderclient output.
> >  >
> >  >
> >  >
> >  > [1]
> >  >
> >
> https://github.com/openstack/python-cinderclient/blob/master/cinderclient/v2/quotas.py#L33
> >  > [2] http://paste.openstack.org/show/482225/
> >  >
> >  > Regards,
> >  > Ivan Kolodyazhny,
> >  > http://blog.e0ne.info/
> >  >
> >  > On Thu, Dec 17, 2015 at 8:41 PM, Timur Sufiev
> > 
> >  > >>
> wrote:
> >  >
> >  > Hello, folks!
> >  >
> >  > I'd like to initiate a discussion of the feature request I'm
> > going
> >  > to make on behalf of Horizon to every core OpenStack service
> > which
> >  > supports Quota feature, namely Cinder, Nova and Neutron.
> >  >
> >  > Although all three services' APIs support special calls to get
> >  > current quota limitations (Nova and Cinder allows to get and
> > update
> >  > both per-tenant and default cloud-wide limitations, Neutron
> > allows
> >  > to do it only for per-tenant limitations), there is no
> > special call
> >  > in any of these services to get current per-tenant usage of
> > quota.
> >  > Because of that Horizon needs to get, say for 'volumes'
> quota, a
> >  > list of Cinder volumes in the current tenant and then just
> > calculate
> >  > its length [1]. When there are really a lot of entities in
> > tenant -
> >  > instances/volumes/security groups/whatever - all this calls
> > sum up
> >  > and make rendering pages in Horizon much more slower than it
> > could
> >  > be. Is it possible to provide special API calls to alleviate
> > this?
> >  >
> >  > [1]
> >  >
> >
> https://github.com/openstack/horizon/blob/9.0.0.0b1/openstack_dashboard/usage/quotas.py#L350
> >  >
> >  >
> >
>  __
> >  > OpenStack Development Mailing List (not for usage questions)
> >  > Unsubscribe:
> >  > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > <
> http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
> >  >
> >   <
> http://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
> > <
> 

Re: [openstack-dev] [Horizon] [Cinder] [Nova] [Neutron] Gathering quota usage data in Horizon

[Matt Riedemann]

On 12/18/2015 12:35 PM, Timur Sufiev wrote:

Matt,

actually Ivan (Ivan, thanks a lot!) showed me the exact cinderclient
call that I needed. Now I know how to retrieve Cinder quota usage info
per-tenant, seems that to retrieve the same info cloud-wide I should sum
up all the available tenant usages.

With Cinder quota usages being sorted out, my next goal is Nova and
Neutron. As for Neutron, there are plenty of quota-related calls I'm
going to play with next week, perhaps there is something suitable for my
use case. But as for Nova, I haven't found something similar to 'usage'
of cinderclient call, so help from someone familiar with Nova is very
appreciated :).

[0]
https://github.com/openstack/python-cinderclient/blob/master/cinderclient/v2/quotas.py#L36

On Fri, Dec 18, 2015 at 5:17 PM Matt Riedemann
> wrote:



On 12/17/2015 2:40 PM, Ivan Kolodyazhny wrote:
 > Hi Timur,
 >
 > Did you try this Cinder API [1]?  Here [2] is cinderclient output.
 >
 >
 >
 > [1]
 >

https://github.com/openstack/python-cinderclient/blob/master/cinderclient/v2/quotas.py#L33
 > [2] http://paste.openstack.org/show/482225/
 >
 > Regards,
 > Ivan Kolodyazhny,
 > http://blog.e0ne.info/
 >
 > On Thu, Dec 17, 2015 at 8:41 PM, Timur Sufiev

 > >> wrote:
 >
 > Hello, folks!
 >
 > I'd like to initiate a discussion of the feature request I'm
going
 > to make on behalf of Horizon to every core OpenStack service
which
 > supports Quota feature, namely Cinder, Nova and Neutron.
 >
 > Although all three services' APIs support special calls to get
 > current quota limitations (Nova and Cinder allows to get and
update
 > both per-tenant and default cloud-wide limitations, Neutron
allows
 > to do it only for per-tenant limitations), there is no
special call
 > in any of these services to get current per-tenant usage of
quota.
 > Because of that Horizon needs to get, say for 'volumes' quota, a
 > list of Cinder volumes in the current tenant and then just
calculate
 > its length [1]. When there are really a lot of entities in
tenant -
 > instances/volumes/security groups/whatever - all this calls
sum up
 > and make rendering pages in Horizon much more slower than it
could
 > be. Is it possible to provide special API calls to alleviate
this?
 >
 > [1]
 >

https://github.com/openstack/horizon/blob/9.0.0.0b1/openstack_dashboard/usage/quotas.py#L350
 >
 >
  __
 > OpenStack Development Mailing 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
 >

I think Timur is asking for a way to filter on only certain resources
for quota usage/limits, like volumes in cinder or instances in nova,
rather than getting back all resource usage/limits per tenant.

Is that correct, Timur?

While it's possible to add this, I'm not sure how much time it's
actually going to save in the DB query time to get the quota information
for a tenant.

Anyway, it's an API change so it would require a spec for nova which
means we wouldn't be getting to that until at least N since we're in
spec freeze for mitaka.

--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing 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



The 

Re: [openstack-dev] [Horizon] [Cinder] [Nova] [Neutron] Gathering quota usage data in Horizon

[Matt Riedemann]

On 12/17/2015 2:40 PM, Ivan Kolodyazhny wrote:

Hi Timur,

Did you try this Cinder API [1]?  Here [2] is cinderclient output.



[1]
https://github.com/openstack/python-cinderclient/blob/master/cinderclient/v2/quotas.py#L33
[2] http://paste.openstack.org/show/482225/

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/

On Thu, Dec 17, 2015 at 8:41 PM, Timur Sufiev > wrote:

Hello, folks!

I'd like to initiate a discussion of the feature request I'm going
to make on behalf of Horizon to every core OpenStack service which
supports Quota feature, namely Cinder, Nova and Neutron.

Although all three services' APIs support special calls to get
current quota limitations (Nova and Cinder allows to get and update
both per-tenant and default cloud-wide limitations, Neutron allows
to do it only for per-tenant limitations), there is no special call
in any of these services to get current per-tenant usage of quota.
Because of that Horizon needs to get, say for 'volumes' quota, a
list of Cinder volumes in the current tenant and then just calculate
its length [1]. When there are really a lot of entities in tenant -
instances/volumes/security groups/whatever - all this calls sum up
and make rendering pages in Horizon much more slower than it could
be. Is it possible to provide special API calls to alleviate this?

[1]

https://github.com/openstack/horizon/blob/9.0.0.0b1/openstack_dashboard/usage/quotas.py#L350

__
OpenStack Development Mailing 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



I think Timur is asking for a way to filter on only certain resources 
for quota usage/limits, like volumes in cinder or instances in nova, 
rather than getting back all resource usage/limits per tenant.


Is that correct, Timur?

While it's possible to add this, I'm not sure how much time it's 
actually going to save in the DB query time to get the quota information 
for a tenant.


Anyway, it's an API change so it would require a spec for nova which 
means we wouldn't be getting to that until at least N since we're in 
spec freeze for mitaka.


--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing 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] [Cinder] [Nova] [Neutron] Gathering quota usage data in Horizon

[Salvatore Orlando]

The point raised by Matt for Nova applies to Neutron as well.
Neutron does not have strict deadlines for blueprint approval; however even
if in theory it would still be possible to achieve this for Mitaka, it is
rather unlikely since the number of blueprints already in the pipeline is
way more than what can reasonably be implemented in this release cycle.

Anyway, it would be a matter of resuscitate the blueprint [1] and pretty
much rework it in light of the discussion we had around "usage APIs" with
the API working group [2]
I will be happy to assist with design and implementations. so if you have
any requirement from the horizon side, like the ability of filtering either
by tenant or resource just let me know.

Salvatore

[1] https://review.openstack.org/#/c/102199/
[2]
http://lists.openstack.org/pipermail/openstack-dev/2014-November/051152.html

On 18 December 2015 at 15:12, Matt Riedemann 
wrote:

>
>
> On 12/17/2015 2:40 PM, Ivan Kolodyazhny wrote:
>
>> Hi Timur,
>>
>> Did you try this Cinder API [1]?  Here [2] is cinderclient output.
>>
>>
>>
>> [1]
>>
>> https://github.com/openstack/python-cinderclient/blob/master/cinderclient/v2/quotas.py#L33
>> [2] http://paste.openstack.org/show/482225/
>>
>> Regards,
>> Ivan Kolodyazhny,
>> http://blog.e0ne.info/
>>
>> On Thu, Dec 17, 2015 at 8:41 PM, Timur Sufiev > > wrote:
>>
>> Hello, folks!
>>
>> I'd like to initiate a discussion of the feature request I'm going
>> to make on behalf of Horizon to every core OpenStack service which
>> supports Quota feature, namely Cinder, Nova and Neutron.
>>
>> Although all three services' APIs support special calls to get
>> current quota limitations (Nova and Cinder allows to get and update
>> both per-tenant and default cloud-wide limitations, Neutron allows
>> to do it only for per-tenant limitations), there is no special call
>> in any of these services to get current per-tenant usage of quota.
>> Because of that Horizon needs to get, say for 'volumes' quota, a
>> list of Cinder volumes in the current tenant and then just calculate
>> its length [1]. When there are really a lot of entities in tenant -
>> instances/volumes/security groups/whatever - all this calls sum up
>> and make rendering pages in Horizon much more slower than it could
>> be. Is it possible to provide special API calls to alleviate this?
>>
>> [1]
>>
>> https://github.com/openstack/horizon/blob/9.0.0.0b1/openstack_dashboard/usage/quotas.py#L350
>>
>>
>> __
>> OpenStack Development Mailing 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
>>
>>
> I think Timur is asking for a way to filter on only certain resources for
> quota usage/limits, like volumes in cinder or instances in nova, rather
> than getting back all resource usage/limits per tenant.
>
> Is that correct, Timur?
>
> While it's possible to add this, I'm not sure how much time it's actually
> going to save in the DB query time to get the quota information for a
> tenant.
>
> Anyway, it's an API change so it would require a spec for nova which means
> we wouldn't be getting to that until at least N since we're in spec freeze
> for mitaka.
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
>
> __
> OpenStack Development Mailing 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] [Cinder] [Nova] [Neutron] Gathering quota usage data in Horizon

[Timur Sufiev]

Matt,

actually Ivan (Ivan, thanks a lot!) showed me the exact cinderclient call
that I needed. Now I know how to retrieve Cinder quota usage info
per-tenant, seems that to retrieve the same info cloud-wide I should sum up
all the available tenant usages.

With Cinder quota usages being sorted out, my next goal is Nova and
Neutron. As for Neutron, there are plenty of quota-related calls I'm going
to play with next week, perhaps there is something suitable for my use
case. But as for Nova, I haven't found something similar to 'usage' of
cinderclient call, so help from someone familiar with Nova is very
appreciated :).

[0]
https://github.com/openstack/python-cinderclient/blob/master/cinderclient/v2/quotas.py#L36

On Fri, Dec 18, 2015 at 5:17 PM Matt Riedemann 
wrote:

>
>
> On 12/17/2015 2:40 PM, Ivan Kolodyazhny wrote:
> > Hi Timur,
> >
> > Did you try this Cinder API [1]?  Here [2] is cinderclient output.
> >
> >
> >
> > [1]
> >
> https://github.com/openstack/python-cinderclient/blob/master/cinderclient/v2/quotas.py#L33
> > [2] http://paste.openstack.org/show/482225/
> >
> > Regards,
> > Ivan Kolodyazhny,
> > http://blog.e0ne.info/
> >
> > On Thu, Dec 17, 2015 at 8:41 PM, Timur Sufiev  > > wrote:
> >
> > Hello, folks!
> >
> > I'd like to initiate a discussion of the feature request I'm going
> > to make on behalf of Horizon to every core OpenStack service which
> > supports Quota feature, namely Cinder, Nova and Neutron.
> >
> > Although all three services' APIs support special calls to get
> > current quota limitations (Nova and Cinder allows to get and update
> > both per-tenant and default cloud-wide limitations, Neutron allows
> > to do it only for per-tenant limitations), there is no special call
> > in any of these services to get current per-tenant usage of quota.
> > Because of that Horizon needs to get, say for 'volumes' quota, a
> > list of Cinder volumes in the current tenant and then just calculate
> > its length [1]. When there are really a lot of entities in tenant -
> > instances/volumes/security groups/whatever - all this calls sum up
> > and make rendering pages in Horizon much more slower than it could
> > be. Is it possible to provide special API calls to alleviate this?
> >
> > [1]
> >
> https://github.com/openstack/horizon/blob/9.0.0.0b1/openstack_dashboard/usage/quotas.py#L350
> >
> >
>  __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > <
> http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> I think Timur is asking for a way to filter on only certain resources
> for quota usage/limits, like volumes in cinder or instances in nova,
> rather than getting back all resource usage/limits per tenant.
>
> Is that correct, Timur?
>
> While it's possible to add this, I'm not sure how much time it's
> actually going to save in the DB query time to get the quota information
> for a tenant.
>
> Anyway, it's an API change so it would require a spec for nova which
> means we wouldn't be getting to that until at least N since we're in
> spec freeze for mitaka.
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
> OpenStack Development Mailing 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] [Cinder] [Nova] [Neutron] Gathering quota usage data in Horizon

[Timur Sufiev]

Hello, folks!

I'd like to initiate a discussion of the feature request I'm going to make
on behalf of Horizon to every core OpenStack service which supports Quota
feature, namely Cinder, Nova and Neutron.

Although all three services' APIs support special calls to get current
quota limitations (Nova and Cinder allows to get and update both per-tenant
and default cloud-wide limitations, Neutron allows to do it only for
per-tenant limitations), there is no special call in any of these services
to get current per-tenant usage of quota. Because of that Horizon needs to
get, say for 'volumes' quota, a list of Cinder volumes in the current
tenant and then just calculate its length [1]. When there are really a lot
of entities in tenant - instances/volumes/security groups/whatever - all
this calls sum up and make rendering pages in Horizon much more slower than
it could be. Is it possible to provide special API calls to alleviate this?

[1]
https://github.com/openstack/horizon/blob/9.0.0.0b1/openstack_dashboard/usage/quotas.py#L350
__
OpenStack Development Mailing 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] [Cinder] [Nova] [Neutron] Gathering quota usage data in Horizon

[Ivan Kolodyazhny]

Hi Timur,

Did you try this Cinder API [1]?  Here [2] is cinderclient output.



[1]
https://github.com/openstack/python-cinderclient/blob/master/cinderclient/v2/quotas.py#L33
[2] http://paste.openstack.org/show/482225/

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/

On Thu, Dec 17, 2015 at 8:41 PM, Timur Sufiev  wrote:

> Hello, folks!
>
> I'd like to initiate a discussion of the feature request I'm going to make
> on behalf of Horizon to every core OpenStack service which supports Quota
> feature, namely Cinder, Nova and Neutron.
>
> Although all three services' APIs support special calls to get current
> quota limitations (Nova and Cinder allows to get and update both per-tenant
> and default cloud-wide limitations, Neutron allows to do it only for
> per-tenant limitations), there is no special call in any of these services
> to get current per-tenant usage of quota. Because of that Horizon needs to
> get, say for 'volumes' quota, a list of Cinder volumes in the current
> tenant and then just calculate its length [1]. When there are really a lot
> of entities in tenant - instances/volumes/security groups/whatever - all
> this calls sum up and make rendering pages in Horizon much more slower than
> it could be. Is it possible to provide special API calls to alleviate this?
>
> [1]
> https://github.com/openstack/horizon/blob/9.0.0.0b1/openstack_dashboard/usage/quotas.py#L350
>
> __
> OpenStack Development Mailing 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 IRC meetings cancelled Dec 23rd and 30th

[David Lyle]

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

We will resume on Jan 6th.

Thanks,
David

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

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

[David Lyle]

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

David

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

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

Re: [openstack-dev] [horizon] Proposal to add Timur Sufiev tohorizon-core

[David Lyle]

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

David

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

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

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

[Richard Jones]

Thank you all!

On 9 December 2015 at 04:23, David Lyle <dkly...@gmail.com> wrote:

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

Re: [openstack-dev] [horizon] Proposal to add Timur Sufiev tohorizon-core

[Timur Sufiev]

David and all the fellow Horizoneers,

Thank you very much for the trust you put in me :). I'll do my best to be
up to it!

On Tue, 8 Dec 2015 at 22:47, David Lyle <dkly...@gmail.com> wrote:

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

[Diana Whitten]

Hi All,

I am currently working on updating the OpenStack logo being used in the
*alternate* theme of Horizon to show that Horizon can easily support both
PNG and SVG logos.

I have found the correct logo assets for our Splash screen, however, I do
not see a corresponding high definition asset to replace our current top
nav .png, as seen in the top left corner here:
https://www.dropbox.com/s/20xw1bvim4sv629/Screenshot%202015-11-21%2014.54.57.png?dl=0

I've used the High Definition assets given on the
http://www.openstack.org/brand/openstack-logo/ site to replace the matching
logo on our Splash page, but I was unable to find a logo that matches the
Horizontal logo used in our Top Nav on the public site.

I've been provided an asset for the horizontal logo, but I was wondering
who I need to get permission from to update / use it?

I only ask because the ‘Terms and Conditions’ state: "You agree that you
will not (i) alter or modify the OpenStack Logo as provided by the
OpenStack Foundation;"

Thanks!
Diana Whitten
__
OpenStack Development Mailing 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]

[Lin Hua Cheng]

The most efficient way to do this for Swift to do this is to implement Form
Post[1] (upload) and tempUrl[2] (download). With this setup, the user will
be directly uploading/downloading from Swift endpoint rather than passing
the files through horizon.

The caveat for this to work, you need to be able to associate access keys
to users.

-Lin

[1] http://docs.openstack.org/developer/swift/api/form_post_middleware.html
[2]
http://docs.openstack.org/kilo/config-reference/content/object-storage-tempurl.html

On Thu, Dec 3, 2015 at 3:20 PM, Kyrylo Galanov 
wrote:

> Hello,
>
> When a file is uploaded to Glance, Swift through Horizon it is stored
> locally in a temporary directory in Horizon server. This is inefficient
> approach especially for big files.
>
> I would suggest to implement 'proxy' upload to Glance, Swift using chunk
> buffer instead of storing a file locally. It would eliminate such drawbacks
> as potential free space exhaustion.
>
> It would be awesome to add upload progress bar as well.
>
> I look forward to your constructive replies.
>
> Best regards,
> Kyrylo
>
> __
> OpenStack Development Mailing 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][release][infra] New xstatic package release proposal

[Richard Jones]

TL;DR: "Releasing xstatic packages" https://review.openstack.org/#/c/253296/

xstatic  is an existing standard for packaging up
static resources for web development (HTML, Javascript and CSS) as Python
modules. Horizon makes use of two dozen xstatic packages.

We need a better-organised method of releasing those packages. Currently
those packages are maintained and released in an ad-hoc manner by
individuals who come and go in the community, with differing release
processes, requiring maintenance handovers, sometimes with people who go
quiet. This does not scale to the dozens of xstatic packages Horizon wishes
to consume.

We therefore wish to use OpenStack's existing release pipeline, handing
over upload to PyPI to that system, while also allowing review of updates
to the packages.

A problem arises in doing so: xstatic packages version themselves using the
three-digit version of the static package they bundle (eg. JQuery-1.2.3)
with an added build number (eg. xstatic-jquery-1.2.3.4) to allow
re-building if the packaging goes wrong. Currently we cannot release these
packages through the OpenStack release pipeline because pbr (a requirement
of that pipeline) does not allow 4 digit version strings. A proposal to
extend pbr to allow 4 digit versions was abandoned today:
https://review.openstack.org/#/c/205623/ (in short, we are only using the
version git tag extraction facility of pbr, and even then not all of that,
and pbr would become more complex with the special-casing required to ...
special-case xstatic packaging).

We will look to use setuptools_scm instead of pbr. Some support work will
be required to make the proposal above happen. This is outlined in
"Releasing xstatic packages" https://review.openstack.org/#/c/253296/

Also, a patch has been submitted to a sample xstatic package implementing
the proposed new workflow: https://review.openstack.org/#/c/252752/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Zhenguo Niu]

+1 for both

On Thu, Dec 3, 2015 at 2:57 AM, David Lyle  wrote:

> Let's try that again.
>
> I propose adding Richard Jones[1] to horizon-core.
>
> Over the last several cycles Richard has consistently been providing
> great reviews, actively participating in the Horizon community, and
> making meaningful contributions around angularJS and overall project
> stability and health.
>
> Please respond with comments, +1s, or objections within one week.
>
> Thanks,
> David
>
> [1]
> http://stackalytics.com/?module=horizon-group_id=r1chardj0n3s=all
>
> On Wed, Dec 2, 2015 at 11:56 AM, David Lyle  wrote:
> > I propose adding Richard Jones[1] to horizon-core.
> >
> > Over the last several cycles Timur has consistently been providing
> > great reviews, actively participating in the Horizon community, and
> > making meaningful contributions around angularJS and overall project
> > stability and health.
> >
> > Please respond with comments, +1s, or objections within one week.
> >
> > Thanks,
> > David
> >
> > [1]
> http://stackalytics.com/?module=horizon-group_id=r1chardj0n3s=all
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

[openstack-dev] [horizon] [QA] Improving Horizon Integration Tests

[Timur Sufiev]

Hello, folks!

As you probably already know, integration tests were recently made voting
again in Horizon. Next logical step in ensuring Horizon/OpenStack stability
is increasing their coverage. I've reworked initial GoogleDoc version of
tests breakdown (wasn't very popular due to the restricted access) as an
etherpad doc [1].

First I suggest to discuss it inline,
* leaving your '+1' marks (if the test case seems really important to you)
inline -> this will help us to prioritize the further work (in a manner
similar we usually prioritize topics for summit)
* or making comments about some tests being excessive/ unnecessary/ missing

Then, once we consider the tests breakdown mature enough, it will be used
for coordination of work, so developers won't write the same test
simultaneously. Finally, this will be used for reviewing purposes (what
test should I review first? - again, as we already do with release cycle
priorities in Horizon), embedding the bug/ review link into the general
document.

In the meantime, I'm going to write additional docs about writing
integration tests.  There is already a good starting section [2], but it's
more aimed for experienced developers, who need debugging clues. So, that
is another area where your feedback is greatly appreciated. If you ever
have tried writing an integration test in Horizon and went away feeling
confused and lost, please describe what was the greatest source of your
confusion.

[1] https://etherpad.openstack.org/p/horizon-integration-tests
[2] https://review.openstack.org/#/c/238959/
__
OpenStack Development Mailing 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]

[Timur Sufiev]

Please take a look at
https://blueprints.launchpad.net/horizon/+spec/horizon-glance-large-image-upload

On Thu, Dec 3, 2015 at 5:21 PM Kyrylo Galanov  wrote:

> Hello,
>
> When a file is uploaded to Glance, Swift through Horizon it is stored
> locally in a temporary directory in Horizon server. This is inefficient
> approach especially for big files.
>
> I would suggest to implement 'proxy' upload to Glance, Swift using chunk
> buffer instead of storing a file locally. It would eliminate such drawbacks
> as potential free space exhaustion.
>
> It would be awesome to add upload progress bar as well.
>
> I look forward to your constructive replies.
>
> Best regards,
> Kyrylo
> __
> OpenStack Development Mailing 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]

[Kyrylo Galanov]

Hello,

When a file is uploaded to Glance, Swift through Horizon it is stored
locally in a temporary directory in Horizon server. This is inefficient
approach especially for big files.

I would suggest to implement 'proxy' upload to Glance, Swift using chunk
buffer instead of storing a file locally. It would eliminate such drawbacks
as potential free space exhaustion.

It would be awesome to add upload progress bar as well.

I look forward to your constructive replies.

Best regards,
Kyrylo
__
OpenStack Development Mailing 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]

[Kyrylo Galanov]

Looks great. What is the estimated date / release for this feature to be
delivered?

On Thu, Dec 3, 2015 at 4:40 PM, Timur Sufiev  wrote:

> Please take a look at
> https://blueprints.launchpad.net/horizon/+spec/horizon-glance-large-image-upload
>
> On Thu, Dec 3, 2015 at 5:21 PM Kyrylo Galanov 
> wrote:
>
>> Hello,
>>
>> When a file is uploaded to Glance, Swift through Horizon it is stored
>> locally in a temporary directory in Horizon server. This is inefficient
>> approach especially for big files.
>>
>> I would suggest to implement 'proxy' upload to Glance, Swift using chunk
>> buffer instead of storing a file locally. It would eliminate such drawbacks
>> as potential free space exhaustion.
>>
>> It would be awesome to add upload progress bar as well.
>>
>> I look forward to your constructive replies.
>>
>> Best regards,
>> Kyrylo
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Thai Q Tran]

An equally BIG +1 from me! Thanks for all the reviews and patches from your minions Richard!
 
- Original message -From: David Lyle <dkly...@gmail.com>To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org>Cc:Subject: [openstack-dev] [horizon] Proposal to add Richard Jones to horizon-coreDate: Wed, Dec 2, 2015 10:57 AM 
I propose adding Richard Jones[1] to horizon-core.Over the last several cycles Timur has consistently been providinggreat reviews, actively participating in the Horizon community, andmaking meaningful contributions around angularJS and overall projectstability and health.Please respond with comments, +1s, or objections within one week.Thanks,David[1] http://stackalytics.com/?module=horizon-group_id=r1chardj0n3s=all__OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
 


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

Re: [openstack-dev] [horizon] Proposal to add Timur Sufiev tohorizon-core

[Thai Q Tran]

BIG +1 for me. Thanks for all of the great work Timur!
 
- Original message -From: David Lyle <dkly...@gmail.com>To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org>Cc:Subject: [openstack-dev] [horizon] Proposal to add Timur Sufiev to horizon-coreDate: Wed, Dec 2, 2015 10:54 AM 
I propose adding Timur Sufiev[1] to horizon-core.Over the last several cycles Timur has consistently been providinggreat reviews, actively participating in the Horizon community, andmaking meaningful contributions particularly around testing andstability.Please respond with comments, +1s, or objections within one week.Thanks,David[1] http://stackalytics.com/?module=horizon-group_id=tsufiev-x=all__OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
 


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

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

[Cindy Lu]

+1 from me for Richard!!

 - Original message -
 From: David Lyle <dkly...@gmail.com>
 To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org>
 Cc:
 Subject: [openstack-dev] [horizon] Proposal to add Timur Sufiev to
 horizon-core
 Date: Wed, Dec 2, 2015 10:54 AM

 Let's try that again.

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

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

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

 Thanks,
 David

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


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

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

[openstack-dev] [horizon] Proposal to add Timur Sufiev to horizon-core

[Cindy Lu]

+1 from me for Timur!

 - Original message -
 From: David Lyle <dkly...@gmail.com>
 To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org>
 Cc:
 Subject: [openstack-dev] [horizon] Proposal to add Timur Sufiev to
 horizon-core
 Date: Wed, Dec 2, 2015 10:54 AM

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

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

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

 Thanks,
 David

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


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

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

[openstack-dev] [Horizon][Trove] Horizon-Trove External Repository

[Thai Q Tran]

Hello Trovers and Horizoneers,
 
The intention of this email is to get everyone on the same page so we are all aware of what is going on. As many of you are probably already aware, Horizon is moving toward the plugin model for all of its dashboards (including existing dashboards). This release cycle, we are aiming to move Sahara and Trove into their own repository with joint ownership of the respective project. I have spoken to interested parties, Craig, and David about it and we are all in agreement. Ideally, this should help speed up the review process for Trove, as you now own part of the code and ownership.
 
Horizon still have some things we need to tidy up on our end to make sure we have full support for testing and localization for external plugins. We expect this to get resolve within the next few weeks. Work on excising the Trove code will begin this week so expect a patch for that soon! It would be ideal if we can merge existing Trove code before the excision happens. David has agreed to let these patches merge with one core vote if we have enough Trovers reviewing/reverifying them. So please help us help you.
 
David and Craig, if I left anything else out, feel free add to this. Otherwise, have a good xmas everyone. Looking to working with you all in the coming weeks.
 
Regard,
Thai (tqtran)
 


__
OpenStack Development Mailing 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]

[Timur Sufiev]

It all depends on Glance support, you'd better ask them.

On Thu, Dec 3, 2015 at 7:08 PM Kyrylo Galanov  wrote:

> Looks great. What is the estimated date / release for this feature to be
> delivered?
>
> On Thu, Dec 3, 2015 at 4:40 PM, Timur Sufiev  wrote:
>
>> Please take a look at
>> https://blueprints.launchpad.net/horizon/+spec/horizon-glance-large-image-upload
>>
>> On Thu, Dec 3, 2015 at 5:21 PM Kyrylo Galanov 
>> wrote:
>>
>>> Hello,
>>>
>>> When a file is uploaded to Glance, Swift through Horizon it is stored
>>> locally in a temporary directory in Horizon server. This is inefficient
>>> approach especially for big files.
>>>
>>> I would suggest to implement 'proxy' upload to Glance, Swift using chunk
>>> buffer instead of storing a file locally. It would eliminate such drawbacks
>>> as potential free space exhaustion.
>>>
>>> It would be awesome to add upload progress bar as well.
>>>
>>> I look forward to your constructive replies.
>>>
>>> Best regards,
>>> Kyrylo
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Douglas Fish]

+1 for both Richard and Timur. Great additions to the team!
Doug Fish
 
 
- Original message -From: "Chen, Shaoquan" <sean.ch...@hpe.com>To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>Cc:Subject: Re: [openstack-dev] [horizon] Proposal to add Richard Jones to horizon-coreDate: Wed, Dec 2, 2015 2:03 PM 
+1 for both Timur and Richard!On 12/2/15, 10:57 AM, "David Lyle" <dkly...@gmail.com> wrote:>Let's try that again.>>I propose adding Richard Jones[1] to horizon-core.>>Over the last several cycles Richard has consistently been providing>great reviews, actively participating in the Horizon community, and>making meaningful contributions around angularJS and overall project>stability and health.>>Please respond with comments, +1s, or objections within one week.>>Thanks,>David>>[1]>http://stackalytics.com/?module=horizon-group_id=r1chardj0n3s>=all>>On Wed, Dec 2, 2015 at 11:56 AM, David Lyle <dkly...@gmail.com> wrote:>> I propose adding Richard Jones[1] to horizon-core.>>>> Over the last several cycles Timur has consistently been providing>> great reviews, actively participating in the Horizon community, and>> making meaningful contributions around angularJS and overall project>> stability and health.>>>> Please respond with comments, +1s, or objections within one week.>>>> Thanks,>> David>>>> [1]>>http://stackalytics.com/?module=horizon-group_id=r1chardj0n3s>>e=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:unsubscribehttp://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 Richard Jones to horizon-core

[Timur Sufiev]

Well, I'm not sure if I'm eligible to chime in (yet), but IMO Richard is
the first candidate here (and me is the second one) :).

On Wed, Dec 2, 2015 at 9:59 PM Rob Cresswell (rcresswe) 
wrote:

> An equally big +1!
>
> On 02/12/2015 18:56, "David Lyle"  wrote:
>
> >I propose adding Richard Jones[1] to horizon-core.
> >
> >Over the last several cycles Timur has consistently been providing
> >great reviews, actively participating in the Horizon community, and
> >making meaningful contributions around angularJS and overall project
> >stability and health.
> >
> >Please respond with comments, +1s, or objections within one week.
> >
> >Thanks,
> >David
> >
> >[1]
> >
> http://stackalytics.com/?module=horizon-group_id=r1chardj0n3s
> >=all
> >
> >__
> >OpenStack Development Mailing List (not for usage questions)
> >Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[David Lyle]

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

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

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

Thanks,
David

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

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