[openstack-dev] [horizon] PTG Announcements

[Rob Cresswell]

Hey everyone,

I've made a Google Hangouts group for us to catch up at the PTG. Please ping me 
on IRC (robcresswell) or email me if you'd like the link to join. It would be 
great to meet you all in real life :)

Also there will be no IRC meeting next week (13th of September) and I expect 
IRC to be quieter than usual due to PTG attendance.

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] Multi-region support in shared Keystone service deployment

[Rob Cresswell (rcresswe)]

As I mentioned the last time you asked :), we use blueprints, and the template 
is here: https://blueprints.launchpad.net/horizon/+spec/template

Please register a blueprint for discussion / tracking. The change looks 
sensible, although I’d prefer we use a setting name like 
https://docs.openstack.org/horizon/latest/configuration/settings.html#openstack-keystone-domain-choices.
 It’s a bit less ambiguous.

Rob



On 16 Aug 2017, at 23:03, Lingxian Kong 
> wrote:

Hi, Horizon developers,

In our OpenStack based public cloud(Catalyst Cloud), Keystone is a shared 
identity service across 3 regions, our customers have been asking for the 
feature that they could select their preferred region when they log in Horizon, 
rather than switching region each time after login.

Unfortunately, the existing 'AVAILABLE_REGIONS' only works with multi-keystone, 
multi-region environment, so for backward compatibility and getting rid of 
potential confusion, a new config option named 'AVAILABLE_SERVICE_REGIONS' was 
introduced in my patch[1][2], the setting is supposed to be configured by the 
cloud operators and the 'AVAILABLE_REGIONS' setting will take precedence over 
'AVAILABLE_SERVICE_REGIONS'.

I am sending this email to ask for more feedback, and do I need to propose a 
feature spec before the code is actually being reviewed?

[1]: https://review.openstack.org/#/c/494083/
[2]: https://review.openstack.org/#/c/494059/

Cheers,
Lingxian Kong (Larry)
__
OpenStack Development Mailing List (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] Admin dashboard instances index page generated duplicate Glance requests

[Rob Cresswell (rcresswe)]

This may be a bug; I recall it was patched recently and perhaps the same logic 
needs to be applied to the Admin view. It sounds like an oversight.

Rob

> On 14 Aug 2017, at 03:46, Xiong, Huan  wrote:
> 
> Hi,
> 
> I observed accessing Admin dashboard's instance index page generated lots of 
> duplicate requests to Glance for converting instance image id to name, but 
> accessing Project dashboard's instance index page didn't (my system runs 
> Newton, but from what I can tell, Ocata and Pike code seem to have same 
> issue).
> 
> I looked at the code and found the reason. In Project dashboard's instance 
> index view class, it first calls Glance's API to get a list of image objects, 
> then iterates through instance objects and sets each instance's image 
> attribute to corresponding image object. As a result, when instance object's 
> image_name() is called later, it gets name from image object. In Admin 
> dashboard's instance index view class, however, it doesn't do this and hence 
> needs to send request to Glance everytime image_name() is called.
> 
> I wonder why Admin dashboard's instance index view class doesn't use the same 
> approach as Project dashboard? Is it intended?
> 
> Thanks,
> Ray
> 
> 
> 
> This email is intended only for the named addressee. It may contain 
> information that is confidential/private, legally privileged, or 
> copyright-protected, and you should handle it accordingly. If you are not the 
> intended recipient, you do not have legal rights to retain, copy, or 
> distribute this email or its contents, and should promptly delete the email 
> and all electronic copies in your system; do not retain copies in any media. 
> If you have received this email in error, please notify the sender promptly. 
> Thank you.
> 
> 
> 
> __
> OpenStack Development Mailing List (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] [i18n] Horizon RC1 tagged

[Rob Cresswell]

Hi everyone,

We've now tagged Horizon's first Release Candidate for Pike (12.0.0). Please 
test it out, and get back to us ASAP with any critical bugs. This also means 
we've now created a stable/pike branch and master is open for features again; 
however, the immediate focus for the next few weeks will be to ensure a stable 
release.

If you find any critical bugs, please tag them with 'pike-rc-potential' and 
target them to pike-rc2 on launchpad, then ping me (robcresswell), ying_zuo, 
amotoki or rdopiera on IRC so we can evaluate and address the bug if necessary. 
Bug fixes must now follow the standard stable policy, and be merged to master, 
then backported to stable/pike. They also must *not* contain any string changes 
whatsoever, as we are in Hard String Freeze, to let the translators do their 
work.

On Monday I'll remove the -2's blocking blueprint work.

Thanks for the hard work everyone,

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] [Openstack][horizon][ceilometer][gnocchi]Viewing gnocchi statistics on Dashboard

[Rob Cresswell (rcresswe)]

We removed the old Ceilometer content in Horizon a while ago; since then, 
nobody has worked on a new plugin to my knowledge.

Rob

> On 8 Aug 2017, at 15:15, gordon chung  wrote:
> 
> 
> 
> On 08/08/17 02:17 AM, pearl.dsil...@wipro.com wrote:
>> I would like to know if there exists support to view the statistics
>> fetched by gnocchi on Horizon(dashboard). If so, please let me know how
>> to configure it in Newton release.
> 
> i don't know if there's plans for this in Horizon. this definitely does 
> not exist in Newton.
> 
> Gnocchi does have visualisation functionality provided by Grafana:
> http://gnocchi.xyz/grafana.html
> 
> cheers,
> -- 
> gord
> __
> OpenStack Development Mailing List (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]when I access my website, there is '500 internal server error'

[Rob Cresswell]

It looks to me like you're updating dependencies past those that are supported 
in Ocata. When installing / upgrading packages, you should make sure they are 
bound by upper-constraints in the global requirements repo. Does horizon work 
from your AIO *before* you modified it?

Rob

On 8 Aug 2017 2:24 am, "王俊" > 
wrote:
Hi:
the log is here: http://paste.openstack.org/show/617722/ .
I install Ocata in centos by all in one,then I copy Ironic-UI plugin to 
‘enable’,I update some lib which is Ironic-UI based on,when I restart the httpd 
server, the error coming. how can I fix it except reinstall the env?

保密：本函仅供收件人使用，如阁下并非抬头标明的收件人，请您即刻删除本函，勿以任何方式使用及传播，并请您能将此误发情形通知发件人，谢谢！
__
OpenStack Development Mailing 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][Nova] Editing flavor causing instance flavor display error

[Rob Cresswell (rcresswe)]

I’m planning on putting up a patch for this today. My proposal is to add a 
setting that disables it by default, then add a big warning side on the setting 
documentation and release notes. Anyone who then explicitly enables it will see 
the warning. Beyond that, we can deprecate it this cycle, but won’t be able to 
drop it until the R release.

Rob

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

[openstack-dev] [horizon] Pike-3, Feature Freeze, and next steps

[Rob Cresswell]

Hey everyone,

We tagged Horizons Pike-3 milestone about 12 hours, so I wanted to quickly run 
through the next steps for the release. At this point, we are in "Feature 
Freeze" and also "Soft String Freeze".

- Feature Freeze - No new features (blueprints or wishlist bugs) can be merged 
without the PTLs approval. We do this so that we can spend the next few weeks 
focusing on finding and fixing bugs in the existing content, to create a stable 
release.

- Soft String Freeze: No user-facing strings should be altered and new string 
additions in general are discouraged, although not blocked entirely. This is to 
give the translation teams some time to start working through the various 
string additions or changes this cycle. For example, when fixing bugs, try to 
reuse the existing error messages rather than alter them.

In 2 weeks time, around the 10th of August, we will tag RC1 (Release Candidate 
1) and move to "Hard String Freeze". At this point, all new strings are 
blocked, while the translation teams do their work. RC1 will become the new 
stable branch ("stable/pike" in this instance) and master branch will open for 
Queens-1.

Any bug fixes for further Pike RC's must then be merged to master and 
backported, as with standard stable policy. Horizon always has an RC2 for 
translation merges. If you'd like to learn more about the deadlines described 
here, https://releases.openstack.org/pike/schedule.html and 
https://docs.openstack.org/project-team-guide/release-management.html are 
useful references.

If you have any questions, please get in touch by replying here or pinging me 
on IRC (robcresswell) in the #openstack-horizon channel.

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] [horizon-plugin] [requirements] Moving to Django 1.11

[Rob Cresswell]

django_openstack_auth and django-babel have been released, and now the 
generated upper-constraints patch containing Django 1.11.x is here: 
https://review.openstack.org/#/c/486093

If something suddenly starts misbehaving in Horizon or a plugin, there's a good 
chance it's stemmed from this marging and hitting the CI's. The release notes 
are here, as a reference: https://docs.djangoproject.com/en/1.11/releases/1.11/

Please ping me on IRC (robcresswell) in the #openstack-horizon room if you need 
help.

Thanks again to everyone who helped with this effort.

Rob

On 19 July 2017 at 15:38, Rob Cresswell 
<robert.cressw...@outlook.com<mailto:robert.cressw...@outlook.com>> wrote:
Hi everyone,

Django 1.11 support has landed for Django OpenStack Auth [1], which was 
released shortly after [2]. Horizon's Django 1.11 support is just merging [3], 
at which point we will raise the global requirement [4] and make the Horizon / 
DOA tests voting [5].

At that point, we should be able to merge the requirements patches and tag 
Django OpenStack Auths final release for Pike. The only other blocking issue 
that I'm aware of is getting django-babel released (external to openstack) with 
Django 1.11 support; there is a GitHub issue open [6].

Overall, we should (fingers crossed) be able to land this effort on time for 
non-client lib freeze and requirements freeze. Big thanks to everyone that 
contributed towards this.

Cheers,
Rob

1. https://review.openstack.org/#/c/484722/
2. https://review.openstack.org/#/c/484914/
3. https://review.openstack.org/#/c/484277/
4. https://review.openstack.org/#/c/485221/
5. https://review.openstack.org/#/c/485220/
6. https://github.com/python-babel/django-babel/issues/38

__
OpenStack Development Mailing List (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-plugin] [requirements] Moving to Django 1.11

[Rob Cresswell]

Hi everyone,

Django 1.11 support has landed for Django OpenStack Auth [1], which was 
released shortly after [2]. Horizon's Django 1.11 support is just merging [3], 
at which point we will raise the global requirement [4] and make the Horizon / 
DOA tests voting [5].

At that point, we should be able to merge the requirements patches and tag 
Django OpenStack Auths final release for Pike. The only other blocking issue 
that I'm aware of is getting django-babel released (external to openstack) with 
Django 1.11 support; there is a GitHub issue open [6].

Overall, we should (fingers crossed) be able to land this effort on time for 
non-client lib freeze and requirements freeze. Big thanks to everyone that 
contributed towards this.

Cheers,
Rob

1. https://review.openstack.org/#/c/484722/
2. https://review.openstack.org/#/c/484914/
3. https://review.openstack.org/#/c/484277/
4. https://review.openstack.org/#/c/485221/
5. https://review.openstack.org/#/c/485220/
6. https://github.com/python-babel/django-babel/issues/38
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] [horizon-plugin] Raising Django version cap

[Rob Cresswell (rcresswe)]

Awesome, I appreciate the work here. I spoke with a couple Django folk on IRC 
and they didn’t have any other solution than “vendor the code”, so I think your 
approach is probably the most reasonable. I’m fairly annoyed that they dropped 
an interface like that, but oh well.

I’ll take a look at the patch and give some feedback. Hoping to also get some 
feedback on the D_O_A merge this week too, otherwise I’ll probably just go 
ahead and do it.

Rob

On 17 Jul 2017, at 09:12, Adrian Turjak 
<adri...@catalyst.net.nz<mailto:adri...@catalyst.net.nz>> wrote:


Was hoping to play with this much sooner, but here is a quick hack for horizon 
working with django 1.11

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

The main issues are with widgets from Django which are no longer there, and all 
I've done is move them to our repo from django 1.10's code. This is probably 
not a good long term solution.

Then django-babel doesn't yet have a version that has django 1.11 support, 
although the change has been merged to master. Just needs a new release. For 
now a install from source works to test.

And... because it was easier, I did this off the patch that brings 
openstack_auth into horizon. Because of some import order changes in django (I 
assume), there was an issue due to an import that caused a call to 
get_user_model before openstack_auth was fully loaded.

Beyond that, it all 'appears' to work. I launched some instances, created some 
networks, changed my password, managed some projects and users. There is tons 
to actually test, but mostly it just seems to work.

On 05/07/17 22:24, Rob Cresswell (rcresswe) wrote:
If you want to install Django 1.11 and test it, that would be very helpful, 
even if its just to open bugs. I’m in the process of adding a non-voting job 
for 1.11 right now, so we should be able to move quickly.

Rob

On 5 Jul 2017, at 01:36, Adrian Turjak 
<adri...@catalyst.net.nz<mailto:adri...@catalyst.net.nz>> wrote:

Great work!

Is there anything that can be done to help meet that July deadline and get 
1.11.x in? I'm more than happy to help with reviews or even fixes for newer 
Django in Horizon, and we should try and get others involved if it will help as 
I think this is a little urgent.

Running anything less than Django 1.11 leaves us in a weird spot because of the 
point where support ends for any versions below it.

Looking at the release timelines, if we don't get 1.11 in for Pike, we'll have 
released a version of Horizon that will be for an unsupported version of Django 
in about 6 months time (8 if deployers stick with django 1.8):
https://releases.openstack.org/pike/schedule.html
https://www.djangoproject.com/download/

It isn't as bad it could be, but it's an awkward situation to be in. 1.9 is no 
longer supported, 1.10 support stops at 2018, so realistically 1.8 is the only 
version to have Pike 'safe' until Queens thats not particularly great either. 
Getting 1.11 support in would be ideal.


On 05/07/17 03:01, Rob Cresswell wrote:
Hi everyone,

I've put up a patch to global-requirements to raise the Django cap to "<1.11", 
with the upper-constraint at "1.10.7" 
(https://review.openstack.org/#/c/480215). Depending on the remaining time, I'd 
quite like to move us to "1.11.x" before Requirements Freeze, which will fall 
around the 27th of July.

Rob



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<mailto: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<mailto: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<mailto: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<mailto: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] [keystone] [requirements] [rpm-packaging] [deb-packaging] Merging Django OpenStack Auth with Horizon

[Rob Cresswell]

Apologies in advance for so many tags, hoping this is seen by the appropriate 
people.

I've put up a patch to merge Django OpenStack Auth (DOA) into the Horizon tree: 
https://review.openstack.org/#/c/482561/ There is a blueprint to track any 
further changes / issues here: 
https://blueprints.launchpad.net/horizon/+spec/merge-openstack-auth

This has been suggested for quite a while, but we've only recently got round to 
it. Historically, the design was supposed to allow for multiple auth plugins 
(years ago, we also had Django OpenStack Auth Kerberos).

However, it's currently highly coupled with Horizon (its sole consumer, as far 
as I know) and the separation seems increasingly arbitrary. Almost all new 
features to Keystone / auth support require changes to both repos (with an 
intermerdiary release of DOA) and it causes a good deal of confusion when 
people try and debug issues too. Merging the two would reduce release and 
packaging work, reduce translation overhead, reduce debugging time and cut down 
on review time needed to make changes that affect auth.

I'd like to see if there are any thoughts or concerns from the wider community.

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

[openstack-dev] [horizon] Bug reports and backporting

[Rob Cresswell]

Hey everyone!

Over the past few months there's been an increase in the number of patches 
without bug reports, and a decrease in the number of backports. I wanted to 
take a moment to explain why bug reports are useful, not just bureaucracy, and 
how they link to backports.

Bug reports help in a few ways:
- They can contain logs, images and discussion about the nature of a bug that 
helps reviewers do their job faster. This kind of verbosity is ideal for a bug 
report, but not suited to a commit message. Generally, the bug report should 
provide information about the *problem*, while the commit message provides 
information about the *solution*.
- For most people, bug reports are much easier to search than parsing git logs. 
Remember that not everyone is a git wizard.
- The tagging system allows us to mark things for backporting, with tags like 
"ocata-backport-potential". The tag system is currently how I manage most of 
our backports.
- Bugs that have been correctly closed (i.e. "Fix Released") and targeted to a 
milestone (i.e. "Pike-3") provide helpful metrics for how the project is 
progressing.

In most cases, a bug is *required* on a patch. If the patch is extremely small 
and self-explanatory - things like whitespace cleanup and typos - then we have 
no need to hold them up. Aside from that, I expect cores to please ask for bug 
reports to be added, and where necessary, target them to a milestone and add 
tags for service knowledge, backporting etc. Otherwise, I have to manually go 
through all of the recent merged changes looking for eligible backports, rather 
than just clicking the "ocata-backport-potential" tag.

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

[openstack-dev] [horizon] Progress on feedback from Boston Forum

[Rob Cresswell]

Hi everyone,

I've updated the etherpad tracking progress against feedback provided in the 
Boston Forum. There is a link to the original feedback etherpad inside: 
https://etherpad.openstack.org/p/horizon-pike-feedback-progress

I wanted to highlight this as most of the feedback has now been merged, 
backported, and released; I'm really proud that we've been able to fix most of 
the issues. Furthermore, it serves as a good demonstration that getting in 
touch and providing feedback really does fix things :)

Cheers,
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] [horizon-plugin] Raising Django version cap

[Rob Cresswell (rcresswe)]

If you want to install Django 1.11 and test it, that would be very helpful, 
even if its just to open bugs. I’m in the process of adding a non-voting job 
for 1.11 right now, so we should be able to move quickly.

Rob

On 5 Jul 2017, at 01:36, Adrian Turjak 
<adri...@catalyst.net.nz<mailto:adri...@catalyst.net.nz>> wrote:

Great work!

Is there anything that can be done to help meet that July deadline and get 
1.11.x in? I'm more than happy to help with reviews or even fixes for newer 
Django in Horizon, and we should try and get others involved if it will help as 
I think this is a little urgent.

Running anything less than Django 1.11 leaves us in a weird spot because of the 
point where support ends for any versions below it.

Looking at the release timelines, if we don't get 1.11 in for Pike, we'll have 
released a version of Horizon that will be for an unsupported version of Django 
in about 6 months time (8 if deployers stick with django 1.8):
https://releases.openstack.org/pike/schedule.html
https://www.djangoproject.com/download/

It isn't as bad it could be, but it's an awkward situation to be in. 1.9 is no 
longer supported, 1.10 support stops at 2018, so realistically 1.8 is the only 
version to have Pike 'safe' until Queens thats not particularly great either. 
Getting 1.11 support in would be ideal.


On 05/07/17 03:01, Rob Cresswell wrote:
Hi everyone,

I've put up a patch to global-requirements to raise the Django cap to "<1.11", 
with the upper-constraint at "1.10.7" 
(https://review.openstack.org/#/c/480215). Depending on the remaining time, I'd 
quite like to move us to "1.11.x" before Requirements Freeze, which will fall 
around the 27th of July.

Rob



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<mailto: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<mailto: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-plugin] Raising Django version cap

[Rob Cresswell]

Hi everyone,

I've put up a patch to global-requirements to raise the Django cap to "<1.11", 
with the upper-constraint at "1.10.7" 
(https://review.openstack.org/#/c/480215). Depending on the remaining time, I'd 
quite like to move us to "1.11.x" before Requirements Freeze, which will fall 
around the 27th of July.

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

[openstack-dev] [horizon] Next weekly IRC meeting cancelled

[Rob Cresswell (rcresswe)]

Hey everyone,

The next weekly IRC meeting (2017-06-21) is cancelled, as I’m away for a week.

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] seeing another users panel in Mitaka ?

[Rob Cresswell (rcresswe)]

This isn’t ringing any bells. Do you have any logs you could share?

Rob

On 7 Jun 2017, at 12:15, Waines, Greg 
> wrote:

Has anyone seen the following behavior / issue ?
I am using Mitaka.

Sometimes ... with many users using the OpenStack installation,
I can be logged into Horizon as User-A/Tenant-A, on the Compute-->Instances 
panel showing my running instances.
and then
For a few seconds (~3-4 seconds), my panel will get re-drawn with 
User-B/Tenant-B’s content, i.e. showing ‘his’ running instances !

Anyone seen this ?
Is it fixed in master ?

Greg.
__
OpenStack Development Mailing List (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] [requirements][mistral][tripleo][horizon][nova][releases] release models for projects tracked in global-requirements.txt

[Rob Cresswell (rcresswe)]

[horizon]
django-openstack-auth - blocking django - intermediary

https://review.openstack.org/#/c/469420 is up to release django_openstack_auth. 
Sorry for the delays.

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] Blueprint process question

[Rob Cresswell]

There isn't a specific time for blueprint review at the moment. It's usually 
whenever I get time, or someone asks via email or IRC. During the weekly 
meetings we always have time for open discussion of bugs/blueprints/patches etc.

Rob

On 18 May 2017 at 16:31, Waines, Greg 
> wrote:
A blueprint question for horizon team.

I registered a new blueprint the other day.
https://blueprints.launchpad.net/horizon/+spec/vitrage-alarm-counts-in-topnavbar

Do I need to do anything else to get this reviewed?  I don’t think so, but 
wanted to double check.
How frequently do horizon blueprints get reviewed?  once a week?

Greg.


p.s. ... the above blueprint does depend on a Vitrage blueprint which I do have 
in review.

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

[openstack-dev] [horizon] Next 2 weekly meetings cancelled

[Rob Cresswell]

Hi everyone!

The next two weekly IRC meetings (3rd May, 10th May) are cancelled. I'm away 
this week and next week is the summit. Meetings will resume on the 17th!

For those going to the summit, please read 
http://lists.openstack.org/pipermail/openstack-dev/2017-April/115982.html for 
meetup info.

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

[openstack-dev] [horizon] Adding Ying Zuo to core team

[Rob Cresswell (rcresswe)]

Hey everyone,

I’m adding Ying Zuo to the Horizon Core team. She’s been contributing many 
great patches to the code base driven by operator experience, as well as 
providing solid reviews. Welcome to the team!

Rob


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

[openstack-dev] [horizon] OpenStack Summit meetups

[Rob Cresswell]

Hello!

A couple of notices about summit meetups for Horizon folk:

- I've reserved about 2 hours on the Monday in Hynes, MR 108 from 2:00 -> 4:20. 
This may change if demand for the rooms is high, so keep an eye on 
https://ethercalc.openstack.org/Boston_Forum_Hacking_Rooms. I'll send a 
reminder closer to the time as well. We'll use this time for open discussion on 
priorities and patches, as well as just to meet fellow contributors :) Feel 
free to drop in at any point; the larger time block is an attempt to avoid 
collisions with other sessions.

- At previous summits we've used a Google Hangouts group to sync up; anything 
from session reminders to drinks after the day is over. Hangouts is useful 
because it has a web client (hangouts.google.com), 
only requires an email address and has mobile clients. Please email me (this 
address), or ping on IRC (robcresswell) if you'd like to be added.

- I'll organise a more formal evening meetup over the next couple of days, and 
send out an email with the details.

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] [ptls] Project On-Boarding Rooms

[Rob Cresswell (rcresswe)]

Hi,

Could we take Horizon off the list? That’ll free up some time for other 
projects too.

Rob


On 28 Mar 2017, at 22:59, Kendall Nelson 
> wrote:

Done! Zaqar is on the list

- Kendall

On Tue, Mar 28, 2017 at 4:17 PM Fei Long Wang 
> wrote:
Hi Kendall,

Yep， if you can help reserve a lunch slot, it would be great. Thanks.



On 28/03/17 05:36, Kendall Nelson wrote:
Hello :)

At this point we have a full list, but if you are interested in a lunch slot I 
can put Zaqar down for one of those unless some other project is willing to 
share their space/time?

Thanks for the interest!

-Kendall Nelson(diablo_rojo)

On Tue, Mar 21, 2017 at 4:50 PM Fei Long Wang 
> wrote:

As far as I know, most of Zaqar team members won't be in Boston. But I will be 
there, so pls help put Zaqar on the list if there is one available. Thanks.

On 16/03/17 07:20, Kendall Nelson wrote:
Hello All!

As you may have seen in a previous thread [1] the Forum will offer project 
on-boarding rooms! This idea is that these rooms will provide a place for new 
contributors to a given project to find out more about the project, people, and 
code base. The slots will be spread out throughout the whole Summit and will be 
90 min long.

We have a very limited slots available for interested projects so it will be a 
first come first served process. Let me know if you are interested and I will 
reserve a slot for you if there are spots left.

- Kendall Nelson (diablo_rojo)

[1] http://lists.openstack.org/pipermail/openstack-dev/2017-March/113459.html



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



--
Cheers & Best regards,
Feilong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--

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


--
Cheers & Best regards,
Feilong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--

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

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

Re: [openstack-dev] [keystone][horizon] weekly meeting

[Rob Cresswell]

It's been a week since the original email; I think we should scale back to a 
monthly sync up. No preference on which week of the month it falls in. Thanks!

Rob

On 13 April 2017 at 22:03, Lance Bragstad 
> wrote:
Happy Thursday folks,

Rob and I have noticed that the weekly attendance for the Keystone/Horizon [0] 
meeting has dropped significantly in the last month or two. We contemplated 
changing the frequency of this meeting to be monthly instead of weekly. We 
still think it is important to have a sync point between the two projects, but 
maybe it doesn't need to be as often as we were expecting.

Does anyone have any objections to making this a monthly meeting?

Does anyone have a preference on the week or day of the month (i.e. 3rd 
Thursday of the month)?

Once we have consensus on a time, I'll submit a patch for the meeting agenda.

Thanks and have a great weekend!

[0] http://eavesdrop.openstack.org/#Keystone/Horizon_Collaboration_Meeting

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

[openstack-dev] [horizon] Pike-1 Tagged

[Rob Cresswell]

Hey everyone,

So we've just tagged our first milestone for Pike. I've checked launchpad and 
bumped anything unfinished to pike-2. You can see our progress for pike-1 at 
https://launchpad.net/horizon/+milestone/pike-1

5 blueprints implemented and 73 bugs closed, as well as many minor bugs that 
didn't have attached reports. Great job so far!

I'm away until Tuesday (Friday and Monday are public holidays in the UK) but 
afterwards I'll be reviewing pike-2 and making sure we're on target. I'd also 
like to remind the cores to ensure that patches have bug reports in most cases; 
while its okay to let minor patches through, for the most part we want to be 
able to track milestone and backport progress via launchpad.

Thanks again for everyone's hard work!

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

[openstack-dev] [horizon] [horizon-plugin] Django Updates - Raising upper constraint to 1.9.13

[Rob Cresswell]

Hi everyone,

It's update time and we need to start raising the upper bounds on Django in 
global-requirements. We're currently capped at <1.9, which will shortly be 
raised to <1.10. This will raise the upper-constraint to 1.9.13. See 
https://review.openstack.org/#/c/453482/

Following a couple of weeks of stability testing, we'll move to 1.10.x (<1.11 
in g-r), and eventually 1.11.x (<2.0 in g-r) before the end of the Pike release 
cycle. I'll send out further emails as these patches go up.

If you are maintaining a plugin, please ensure it is functioning on Django 1.9, 
and feel free to leave comments on the requirements patch above.

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][nova][tc] nova-network deprecation in horizon

[Rob Cresswell]

Frankly, it sounds like we can pretty comfortably drop support for nova-net in 
Pike. I'm fine with that, from a Horizon point of view.

Rob

On 28 March 2017 at 21:06, Matt Riedemann 
> wrote:
On 3/28/2017 9:04 AM, Akihiro Motoki wrote:
> Hi,
>
> I would like to raise a topic when horizon nova-network support can be 
> dropped.
> I added [tc] tag as it is related to
> "assert:follows-standard-deprecation" tag in the governance.
>
> Can horizon drop nova-network support based on the deprecation of nova-network
> from the nova team?
> or does horizon need to deprecate nova-network support in horizon explicitly?
>
> Let me summarize the current situation:
> - nova team deprecated nova-network in Newton release. [1]
> - horizon team has not deprecated it so far (just forgot to do it).
> - nova-network security group and floating IP support has been dropped
> from novaclient few days ago [2].
> - When a new release of novaclient comes, horizon security group
> support will be broken (if neutron is not used)
> - Nova microversion also allows to use nova-network but old version of
> novaclient is required for horizon to
>   support it and it is not realistic.

This is the tricky part. You can specify a microversion to use
novaclient with the nova-network behavior. If you're using the python
API bindings in novaclient, which I think Horizon is, then you have to
specify a microversion anyway. The nova-network API bindings in
novaclient will work up until 2.35.

The messy part about this is when we release novaclient 8.0 then that
code is gone and microversions don't matter. So you'd have to use an
older version, 7.1.0 at this point. To do that, we have to essentially
cap novaclient to 7.1.0 in upper-constraints in the requirements repo
for the rest of Pike since Horizon won't work with 8.0.

I don't want to cap novaclient in upper-constraints for the rest of
Pike, but at the same time, it's not great to just drop features out of
a UI without first telling users they are deprecated first. However,
having said that, isn't Horizon really the portal for the tenant user? I
know admins use it also, but the admin/operator should already know
about the nova-network deprecation. If they are just finding out about
this because their Horizon features all of a sudden don't work in Pike,
that's pretty bad on their part, in my opinion anyway. In this
perspective, I think it might be OK to drop nova-network support without
a deprecation period in Horizon for the things we've removed from
novaclient.

>
> It would be nice that horizon team is allowed to drop some feature
> aligning with feature deprecation
> and drop in backend project(s) (without explicit deprecation notices
> in horizon side).
>
> It is not easy that horizon team is aware of all feature deprecations
> in other projects
> and the horizon team tends to be aware of them when the deprecated features 
> are
> actually dropped.
>
> Thought?
>
> There may be things and solutions I am not aware of. Any feedback
> would be appreciated.

Me too. :)

>
> Best Regards,
> Akihiro
>
> [1] https://docs.openstack.org/releasenotes/nova/newton.html#deprecation-notes
> [2] https://review.openstack.org/#/c/447707/
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


--

Thanks,

Matt

__
OpenStack Development Mailing List (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] [keystone] [horizon] Keystone-Horizon meeting on 2017-03-23 cancelled

[Rob Cresswell]

Hey everyone,

I'm away next week, so the Keystone-Horizon meeting on the 23rd is cancelled

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

[openstack-dev] [horizon] No meeting on 2017-03-22 (next week)

[Rob Cresswell]

Hey everyone,

I'm away for a week, so there'll be no Horizon meeting on the 22nd.

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] [ptls] Project On-Boarding Rooms

[Rob Cresswell (rcresswe)]

Horizon would love the opportunity to baffle newcomers.
This could also be useful for the many plugins that are managed by their 
respective service teams.

Rob

On 15 Mar 2017, at 18:20, Kendall Nelson 
> wrote:

Hello All!

As you may have seen in a previous thread [1] the Forum will offer project 
on-boarding rooms! This idea is that these rooms will provide a place for new 
contributors to a given project to find out more about the project, people, and 
code base. The slots will be spread out throughout the whole Summit and will be 
90 min long.

We have a very limited slots available for interested projects so it will be a 
first come first served process. Let me know if you are interested and I will 
reserve a slot for you if there are spots left.

- Kendall Nelson (diablo_rojo)

[1] http://lists.openstack.org/pipermail/openstack-dev/2017-March/113459.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Horizon] Empty metadata value support

[Rob Cresswell (rcresswe)]

You’d be better off checking each API or tagging Glance in this, since I think 
they originally wrote the metadata stuff. Horizon shouldn’t require anything 
the APIs don’t, but I’d imagine it was there for a reason, at least initially.

Rob

> On 14 Mar 2017, at 13:06, Mateusz Kowalski  wrote:
> 
> Hello everyone,
> 
> This mail is to ask for opinion and/or recommendation regarding inconsistent 
> behaviour between CLI and UI re: support of metadata keys with empty values.
> 
> The current behaviour is as follows: most, if not all, of the backend 
> components fully support custom metadata properties with value = null. At the 
> same time Horizon UI by default in all "Update ... Metadata" requires that 
> for each key value is non-empty (that means null is not a valid input).
> 
> We have a following scenario happening just now for one of our customers -- 
> there is an image X uploaded via CLI with property "custom_x:null". User 
> creates a VM from this image and later creates a snapshot of the VM (these 
> two steps are indifferent for CLI and UI). Next, using UI, he tries to rename 
> the snapshot he has just created using "Edit Image" panel. Apparently the 
> operation is not possible because the metadata tab is marked as "mandatory" 
> with property "custom_x" appearing without any value and tagged as 
> "required". This means our user is forced to either put non-null value to the 
> property or completely remove it in order to be able to rename the snapshot. 
> At the same time renaming it using CLI works without any impact on the 
> metadata. The same applies to changing any other detail like "image 
> description", "visibility", "protection".
> 
> Therefore the question - does anyone have a strong "no" against pushing a 
> patch which will allow null as a valid value for a custom metadata across all 
> Horizon ?
> 
> Mateusz,
> CERN
> __
> OpenStack Development Mailing List (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 meeting

[Rob Cresswell]

Hey everyone,

Reminder that the weekly IRC meeting is 2000 UTC on Wednesday in 
#openstack-meeting-3. Anyone is welcome to add to the agenda at 
https://wiki.openstack.org/wiki/Meetings/Horizon

Previous logs, ICS files, and other info can be found at 
http://eavesdrop.openstack.org/#Horizon_Team_Meeting

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][searchlight] Sharing resource type implementations

[Rob Cresswell (rcresswe)]

I tried searching the meeting logs but couldn’t find where we discussed this in 
the Searchlight meeting. The conclusion at the time was option 4 IIRC. The main 
thing is to make sure we get it done within one cycle, even if it isn’t 
default. this means searchlight-ui doesn’t have to carry some horrible 
workarounds and can just remove the code from their repo.

Basically; start putting the code in the Horizon repo, and when its done, 
Searchlight-UI can remove it from their repo.

Rob


> On 9 Mar 2017, at 04:22, Richard Jones  wrote:
> 
> Hi Searchlight and Horizon folks,
> 
> I'd like to re-use the wonderful resource type code from
> searchlight-ui (in particular os-nova-servers right now but
> potentially others down the track) and was wondering whether you'd had
> any thoughts about how we might share that code? Off the top of my
> head I see a few options:
> 
> 1. We depend on the searchlight-ui as a Horizon requirement; this is
> pretty unlikely to happen (depending on any optional panel means it's
> not really optional any longer ;-)
> 2. We copy the code from searchlight-ui into Horizon; this is pretty terrible.
> 3. We move the code from searchlight-ui into a separate project that
> both Horizon and searchlight-ui depend upon; this could be made to
> work, though it's Yet Another Project.
> 4. We move the code from searchlight-ui into Horizon. I think this is
> most likely to work.
> 
> What are your thoughts? Have I missed an option in this list that you
> think is a better one? Have I missed the mark in my analysis of the
> options I've presented?
> 
> 
>  Richard
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [keystone] [horizon] Keystone - Horizon Cross Project Meeting

[Rob Cresswell]

Hey folks,

Just a reminder about the Keystone-Horizon meeting. It's Thursday, 2000 UTC 
(about 11 hours, 20 mins from sending this email) in #openstack-meeting-cp

Discussion points, calendar links, current progress can be found at 
https://etherpad.openstack.org/p/keystone-horizon

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

[openstack-dev] [horizon] Horizon Weekly IRC Meeting

[Rob Cresswell]

Hey everyone,

Reminder that the weekly IRC meeting is 2000 UTC on Wednesday (about 10.5 hours 
from sending this email) in #openstack-meeting-3. Anyone is welcome to add to 
the agenda at https://wiki.openstack.org/wiki/Meetings/Horizon

Previous logs, ICS files, and other info can be found at 
http://eavesdrop.openstack.org/#Horizon_Team_Meeting

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

[openstack-dev] [horizon] Weekly wrap-up

[Rob Cresswell]

Hey folks,

Great work since the PTG. In Pike so far we've already closed over 30 bugs (28 
tracked, with a few minor untracked fixes) and backported several fixes to our 
stable releases, which we'll tag this week. Several blueprints are well on the 
way too, but really need reviews. Please check out 
https://launchpad.net/horizon/+milestone/pike-1, and get some +/-1's on those 
patches!

I've been doing a lot of patch cleanup this week; if you believe something has 
been abandoned or blocked erroneously, please let me know via email or IRC 
(robcresswell).

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

[openstack-dev] [horizon] [keystone] No Keystone-Horizon cross project meeting today

[Rob Cresswell]

Hey everyone,

Sorry for the late notice, but there will be no Horizon-Keystone cross project 
meeting this week, as we've little to discuss with the PTG so recent. The 
meeting will resume as normal next week.

For those interested in joining, see 
http://eavesdrop.openstack.org/#Keystone/Horizon_Collaboration_Meeting

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] Single core review for patch approval

[Rob Cresswell]

Adding inexperienced cores doesn't really alleviate that issue though, and I 
don't currently feel that there is anyone with the right balance of experience 
and activity to be added to the core team.

Me and Richard monitor review activity very closely though, and we are actively 
looking to grow the team. We just need more activity from reviewers so that 
they can learn, and in turn we can teach them. I don't expect people to know 
everything before being core - I certainly didn't - but I don't think the bar 
is being met just yet.

Rob

On 1 March 2017 at 10:36, Beth Elwell 
<beth.openst...@gmail.com<mailto:beth.openst...@gmail.com>> wrote:
Has there been any consideration of growing the core team to help with review 
bandwidth? I ask only because that resulting responsibility to the community 
can drive additional review activity. Just worried that only 1x +2 could cause 
issues with code being merged on a project this large that could potentially 
break things or clash with other opinions or standards of how it should be 
written/implemented? It concerns me that it makes it easier to overlook larger 
things in more substantial patches. I guess as you say, there needs to be 
accountability re not always going for the single +2 when the patch is of that 
sort of size and you need a second opinion?

Beth

> On 28 Feb 2017, at 10:09, Rob Cresswell 
> <robert.cressw...@outlook.com<mailto:robert.cressw...@outlook.com>> wrote:
>
> Hey everyone,
>
> Horizon is moving to requiring only a single core review for code approval. 
> Note that cores are not obliged to approve on a single +2; if a core would 
> like a second opinion for patches that are complex or high risk, that is also 
> fine.
>
> We still require at least one of the core reviewers or contributor on a patch 
> to be from separate companies however. For example, if a patch is authored by 
> someone from Cisco, then I could not (as a Cisco employee) +2+w the patch by 
> myself; it would require at least another core +2.
>
> This should help us move smaller patches along quicker.
>
> Rob
> __
> 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://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] Single core review for patch approval

[Rob Cresswell]

Hey everyone,

Horizon is moving to requiring only a single core review for code approval. 
Note that cores are not obliged to approve on a single +2; if a core would like 
a second opinion for patches that are complex or high risk, that is also fine.

We still require at least one of the core reviewers or contributor on a patch 
to be from separate companies however. For example, if a patch is authored by 
someone from Cisco, then I could not (as a Cisco employee) +2+w the patch by 
myself; it would require at least another core +2.

This should help us move smaller patches along quicker.

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] PTG Summary

[Rob Cresswell]

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

So the idea here is to send an email for changes that are likely to affect 
plugins; new libs for example, or changes to core components, with the 
[horizon-plugin] tag.

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

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

Rob

On 28 February 2017 at 04:33, Richard Jones 
<r1chardj0...@gmail.com<mailto:r1chardj0...@gmail.com>> wrote:
On 28 February 2017 at 02:28, Rob Cresswell
<robert.cressw...@outlook.com<mailto:robert.cressw...@outlook.com>> wrote:
> Quick summary of the PTG for those who missed it. Here's the etherpad, with
> notes inline: https://etherpad.openstack.org/p/horizon-ptg-pike

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


 Richard

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://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] PTG Summary

[Rob Cresswell]

Hi everyone!

Quick summary of the PTG for those who missed it. Here's the etherpad, with 
notes inline: https://etherpad.openstack.org/p/horizon-ptg-pike

We spent the first morning discussing plugins, with several plugin devs 
dropping in to discuss their issues. Several issues were mentioned that Horizon 
needs to improve upon to help the plugins:

- Functional testing for JS
- Extensible quotas
- Use [horizon-plugin] mailer tag to keep people up to date

Further specifics can be found in the etherpad notes.

The afternoon and following morning were spent analysing specific blueprints, 
and then doing a general blueprint review. This has resulted in a really 
refined blueprint list: https://blueprints.launchpad.net/horizon, which we'll 
be using in place of a priorities etherpad this cycle. That's right, tracking 
tools actually being used for tracking. Huzzah!

If there are any disagreements on blueprints, or you feel I have closed 
something unfairly, please get in touch on IRC (robcresswell) or email me.

Two other cross project sessions are also linked in the etherpad; one with 
keystone and another with i18n. These were really helpful in understanding how 
Horizon can work better with these projects. Please review the etherpads to see 
what work needs to be done.

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

[openstack-dev] [horizon] PTG Cross Project Sessions

[Rob Cresswell]

Hi everyone,

A reminder to those at the PTG about a couple of cross project sessions.

- Wednesday, 2:30 - 3:30, Horizon / Keystone in Savannah 3
- Thursday 3:00 - 4:00, Horizon / I18n in Savannah 3

These are also listed in our PTG etherpad: 
https://etherpad.openstack.org/p/horizon-ptg-pike

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

[openstack-dev] [horizon] No meetings this week

[Rob Cresswell]

Hi everyone,

There will be no meetings this week due to the PTG 
(https://www.openstack.org/ptg/)

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

[openstack-dev] [horizon] [keystone] Cross-Project Meeting

[Rob Cresswell]

Hey everyone,

Quick reminder about the Keystone-Horizon meeting at 2000 UTC (about 1h45 from 
this email being sent). You can see the details and add it to your calendar via 
http://eavesdrop.openstack.org/#Keystone/Horizon_Collaboration_Meeting

I'd like to keep up these meetings for the foreseeable future, as they were 
really useful in solving some complex long standing issues in Horizon.

There will also be a Keystone/Horizon cross project session at the PTG; 
Wednesday at 2:30 - 3:20 in Savannah. The details are listed on the Keystone 
PTG etherpad (https://etherpad.openstack.org/p/keystone-pike-ptg) in case this 
changes.

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] Horizon support for Neutron Trunks - PTL approval needed

[Rob Cresswell]

Just caught up with Kevin on IRC. If this is inside the Neutron tree, then 
support should live in the Horizon repo; similar to routers, floating ips etc. 
My initial, incorrect understanding was that it was more akin to lbaas or 
vpnaas.

Rob


On 6 February 2017 at 10:50, Kevin Benton 
<ke...@benton.pub<mailto:ke...@benton.pub>> wrote:
Well the UIs for the extensions inside the main Neutron repo are in the main 
horizon repo so far (e.g. routers, floating IPs, security groups, etc). LBaaS 
is a separate repo with separate devs so it makes sense to me that it would 
have its own UI repo.

Trunks would be the the first extension that lives in the Neutron tree that 
would have its own UI repo living somewhere else. I don't see how we could 
avoid bitrot (or find UI contributors in the first place) if every upstream 
feature will be expected to have its own UI repo, core team, bug tracker, and 
release management. That will be a huge overhead to adding support for new 
neutron features.


On Feb 6, 2017 03:36, "Rob Cresswell (rcresswe)" 
<rcres...@cisco.com<mailto:rcres...@cisco.com>> wrote:
Core Neutron features should be within Horizon, with extensions outside. This 
is a little hazy since even the default behaviour in Neutron is still a plugin, 
but thats the general idea. There are already some features outside, like the 
lbaas dashboard. Personally, I’d keep them in their own repo; makes it much 
easier to manage scope. It’d be a huge pain if one extensions UI holds up 
others at release time due to broken tests etc.

Rob

> On 6 Feb 2017, at 07:02, Richard Jones 
> <r1chardj0...@gmail.com<mailto:r1chardj0...@gmail.com>> wrote:
>
> That idea has merit, though I don't know what the scope for such a
> 'neutron-ui' might be. I'm definitely supportive of the Neutron Trunks
> UI efforts, but it'd be good to get an answer on this scope question
> before rolling along and creating the project.
>
>
>Richard
>
> On 6 February 2017 at 12:14, Kevin Benton <ke...@benton.pub> wrote:
>> If the horizon team would like neutron features to live outside, I wonder if
>> it would make more sense to create a new 'neutron-ui' repo instead of it
>> being trunk specific. That way we don't have to come up with a new repo for
>> every new feature that needs a horizon UI.
>>
>> On Feb 3, 2017 09:26, "Bence Romsics" 
>> <bence.roms...@gmail.com<mailto:bence.roms...@gmail.com>> wrote:
>>>
>>> Hi All,
>>>
>>> I'd like to add support for Neutron Trunks [1][2] into Horizon
>>> together with a few colleagues in the Pike cycle. We thought of
>>> writing a new Horizon plugin [3] for that purpose. That way I hope to
>>> keep it optional for deployment and minimize the maintenance cost for
>>> the Horizon core team. Of course we'd welcome all review feedback,
>>> especially from the Horizon and Neutron teams.
>>>
>>> To host the work I'd like create a new project: openstack/neutron-trunk-ui
>>>
>>> Following the Project Creator's Guide, here's a proposed new project
>>> config:
>>>
>>> https://review.openstack.org/428730
>>>
>>> And the corresponding governance change:
>>>
>>> https://review.openstack.org/428796
>>>
>>> Please review them and if you agree approve. Or guide me to a better
>>> change.
>>>
>>> Thanks in advance,
>>> Bence Romsics
>>>
>>> [1]
>>> https://github.com/openstack/openstack-manuals/blob/master/doc/networking-guide/source/config-trunking.rst
>>> [2] https://wiki.openstack.org/wiki/Neutron/TrunkPort
>>> [3] http://docs.openstack.org/developer/horizon/tutorials/plugin.html
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: 
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://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://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)
> Unsubsc

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

[Rob Cresswell (rcresswe)]

Core Neutron features should be within Horizon, with extensions outside. This 
is a little hazy since even the default behaviour in Neutron is still a plugin, 
but thats the general idea. There are already some features outside, like the 
lbaas dashboard. Personally, I’d keep them in their own repo; makes it much 
easier to manage scope. It’d be a huge pain if one extensions UI holds up 
others at release time due to broken tests etc.

Rob

> On 6 Feb 2017, at 07:02, Richard Jones  wrote:
> 
> That idea has merit, though I don't know what the scope for such a
> 'neutron-ui' might be. I'm definitely supportive of the Neutron Trunks
> UI efforts, but it'd be good to get an answer on this scope question
> before rolling along and creating the project.
> 
> 
>Richard
> 
> On 6 February 2017 at 12:14, Kevin Benton  wrote:
>> If the horizon team would like neutron features to live outside, I wonder if
>> it would make more sense to create a new 'neutron-ui' repo instead of it
>> being trunk specific. That way we don't have to come up with a new repo for
>> every new feature that needs a horizon UI.
>> 
>> On Feb 3, 2017 09:26, "Bence Romsics"  wrote:
>>> 
>>> Hi All,
>>> 
>>> I'd like to add support for Neutron Trunks [1][2] into Horizon
>>> together with a few colleagues in the Pike cycle. We thought of
>>> writing a new Horizon plugin [3] for that purpose. That way I hope to
>>> keep it optional for deployment and minimize the maintenance cost for
>>> the Horizon core team. Of course we'd welcome all review feedback,
>>> especially from the Horizon and Neutron teams.
>>> 
>>> To host the work I'd like create a new project: openstack/neutron-trunk-ui
>>> 
>>> Following the Project Creator's Guide, here's a proposed new project
>>> config:
>>> 
>>> https://review.openstack.org/428730
>>> 
>>> And the corresponding governance change:
>>> 
>>> https://review.openstack.org/428796
>>> 
>>> Please review them and if you agree approve. Or guide me to a better
>>> change.
>>> 
>>> Thanks in advance,
>>> Bence Romsics
>>> 
>>> [1]
>>> https://github.com/openstack/openstack-manuals/blob/master/doc/networking-guide/source/config-trunking.rst
>>> [2] https://wiki.openstack.org/wiki/Neutron/TrunkPort
>>> [3] http://docs.openstack.org/developer/horizon/tutorials/plugin.html
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [horizon] PTL Candidacy for Pike

[Rob Cresswell]

Hi everyone,

I’m announcing my candidacy for PTL of Horizon for the Pike release cycle.

Over the next 6 months I’d like to:

- Narrow the blueprint/feature scope to ensure we focus on high priority areas, 
like non-performant panels or buggy user experiences. In previous cycles, our 
attitude has been to opportunistically accept features as they were developed; 
however, given the rapid decline in review count I don’t believe this is 
maintainable going forward. I’d like to follow a similar structure to Neutron, 
with a smaller feature count that is well understood by core reviewers and 
other time being spent on addressing bugs. We’ll do this by accepting only a 
handful of blueprints at a time, and designating a core reviewer to monitor 
each blueprints progress.

- Continue working with Keystone via cross-project meetings to fix key bugs in 
Identity management. Over the past couple of cycles we’ve closed some long 
standing Keystone interaction bugs in Horizon, and I’d like to continue this 
effort. There are several patches still to work on in Horizon and Django 
OpenStack Auth, and we should make sure we capitalise on the excellent help 
from the Keystone community to improve the Horizon Identity panels.

- Keep up community interaction. Richard has maintained a list of priority 
patches through Ocata, as well as sending out weekly meeting reminders and 
progress updates. I’ll continue this work, and hold bug days to highlight key 
issues to invest our time in.

Thanks,

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

Re: [openstack-dev] [Horizon] [Performance] Gathering quota usage data in Horizon

[Rob Cresswell]

There's quite a lot to this. So, first off, quotas in horizon are not in great 
shape, and it should be one of our priorities next cycle to improve on this. As 
you've pointed out, it seems any check on quotas right now runs multiple serial 
API calls for everything that has quotas; I haven't checked this myself, but 
others have mentioned the same behaviour.

I don't think anyone is actively working on improving quota behaviour, but in 
the past cycle these two efforts spring to mind:
- https://blueprints.launchpad.net/horizon/+spec/make-quotas-great-again
- https://review.openstack.org/#/c/334017/

If there are people with time to work on this effort I'd be happy to review. 
Instances management, quotas, overview pages, Identity work are what I'd 
currently consider the top priorities for improvement.

Rob

On 26 January 2017 at 03:24, Lingxian Kong 
> wrote:
Hi, guys,

Sorry for recalling this thread after 1 year, but we are currently suffering 
from the poor performance issue for our public cloud.

As usage of our customers keeps growing, we are at a stage that should 
seriously pay more attention to horizon performance problem, so Google took me 
to this email after a lot of search.

Currently, when loading a page that may contain some buttons for 
creating/allocating resource (e.g. 'Access & Security'), horizon will check the 
quota usage first to see if a specific button should be disabled or not, and 
the checkings just happen *in sequence*, which makes things even worse.

What's more, the quota usage query in horizon is included in one function[1], 
it will invoke Nova, Cinder, Neutron (perhaps more in future) APIs to get usage 
of bunch of resources, rather than the resource that page is rendering, which 
is another flaw IMHO. I know that this function call is already put in cache, 
but most of our customers' pain just come from the first click.

So, I have a few questions:

1. Does horizon support some config option that could disable quota check? As a 
public cloud, it doesn't make much sense that usage should be limited, and we 
have a monitoring tool that will increase quotas automatically when customer's 
usage will hit the quota limit. So, getting rid of that check will save our 
customers appreciable mass of waiting time.

2. Another option is to support get quota usage for specific resource rather 
than all the resources, e.g. when loading floating ip tab, horizon only get 
floating ip quota usage from Neutron, which has only 2 api calls.

3. I found this FFE[2] which is great (also replied), but splitting tabs is not 
the end, more effort should be put into the performance improvement.

4. Some other trivial improvement like this: https://review.openstack.org/425494

[1]: 
https://github.com/openstack/horizon/blob/master/openstack_dashboard/usage/quotas.py#L396
[2]: 
http://openstack.markmail.org/thread/ra3brm6voo4ouxtx#query:+page:1+mid:oata2tifthnhy5b7+state:results


Cheers,
Lingxian Kong (Larry)

On Wed, Dec 23, 2015 at 9:50 PM, Timur Sufiev 
> wrote:
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 
> 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:
>
>   

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

[Rob Cresswell]

Wow, lots of replies. Thanks for the FFE. I'd request that we proceed with the 
panel separation now, and resolve the final location when any bug fixes have 
merged. I don't really want to hold up a whole chain of patches over a one line 
path change. API Access and Key Pairs are done, and I'll put up Security Groups 
and Floating IPs once they start moving (maintaining huge patch chains is a 
waste of time)

Rob

On 26 January 2017 at 02:09, Adrian Turjak 
<adri...@catalyst.net.nz<mailto:adri...@catalyst.net.nz>> wrote:
I've posted some comments on the API Access patch.


The blueprint was saying that 'API Access' would be both at the Project level, 
but the way panel groups worked meant that setting the 'default' panel group 
didn't work when that dashboard already had panel groups, since the default 
panel group was annoyingly hidden away because of somewhat odd template logic.

I submitted a bug report here:
https://bugs.launchpad.net/horizon/+bug/1659456

And proposed a fix for that here:
https://review.openstack.org/#/c/425486

With that change the default group panels are not hidden, and displayed at the 
same level as the other panel groups. This then allows us to move API Access to 
the top level where the blueprint says. This makes much more sense since API 
Access isn't a compute only thing.


On 26/01/17 12:02, Fox, Kevin M wrote:
Big Thanks! from me too. The old UI here was very unintuitive, so I had to 
field a lot of questions related to it. This is great. :)

Kevin

From: Lingxian Kong [anlin.k...@gmail.com<mailto:anlin.k...@gmail.com>]
Sent: Wednesday, January 25, 2017 2:23 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [horizon] FFE Request

Hi, Rob,

First, thanks for your work!

What's your plan for the other two tabs (security group, floatingip)? I could 
see the split is very helpful no matter from performance perspective and both 
useful from end user's perspective.

BTW, a huge +1 for this FFE!




Cheers,
Lingxian Kong (Larry)

On Thu, Jan 26, 2017 at 9:01 AM, Adrian Turjak 
<adri...@catalyst.net.nz<mailto:adri...@catalyst.net.nz>> wrote:
+1

We very much need this as the performance of that panel is awful. This solves 
that problem while being a fairly minor code change which also provides much 
better UX.


On 26/01/2017 8:07 AM, Rob Cresswell 
<<mailto:robert.cressw...@outlook.com>robert.cressw...@outlook.com<mailto:robert.cressw...@outlook.com>>
 wrote:
o/

I'd like to request an FFE on 
<https://blueprints.launchpad.net/horizon/+spec/reorganise-access-and-security> 
https://blueprints.launchpad.net/horizon/+spec/<http://launchpad.net/horizon/+spec/>reorganise-access-and-security.
 This blueprint splits up the access and security tabs into 4 distinct panels. 
The first two patches are <https://review.openstack.org/#/c/408247> 
https://review.openstack.org/#/c/408247 and 
https://review.openstack.org/#/c/425345/

It's low risk; no API layer changes, mostly just moving code around.

Rob


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://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<mailto: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] FFE Request

[Rob Cresswell]

o/

I'd like to request an FFE on 
https://blueprints.launchpad.net/horizon/+spec/reorganise-access-and-security. 
This blueprint splits up the access and security tabs into 4 distinct panels. 
The first two patches are https://review.openstack.org/#/c/408247 and 
https://review.openstack.org/#/c/425345/

It's low risk; no API layer changes, mostly just moving code around.

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

Re: [openstack-dev] [horizon] feature freeze exception request -- nova simple tenant usages api pagination

[Rob Cresswell (rcresswe)]

As I understand it, if someone configures Nova to use 2.40 via settings, then 
it will use 2.40 for every request. This could likely break Horizon in weird 
ways, which makes it seem risky to try and support it.

What I don’t really understand about this FFE, is why we need to modify the 
behaviour at all; if we keep using an old microversion (I think it defaults to 
2.1?) then shouldn’t behaviour stay exactly the same?

Rob

> On 23 Jan 2017, at 21:08, Richard Jones <r1chardj0...@gmail.com> wrote:
> 
> [I'm on vacation, so can't look into this too deeply, sorry]
> 
> I'm not sure I follow Rob's point here. Does the patch
> https://review.openstack.org/#/c/410337 just check the version to see
> if it's >= 2.40 and take action appropriately? I don't see how it
> changes anything to force requesting 2.40 with every request? Then
> again, I've not been able to look into how the current clients'
> microversion code is implemented/broken. Is it just that *declaring*
> the 2.40 version in https://review.openstack.org/#/c/422642 results in
> all requests being forced to use that version?
> 
> 
> Richard
> 
> On 23 January 2017 at 23:10, Radomir Dopieralski <openst...@sheep.art.pl> 
> wrote:
>> Yes, to do it differently we need to add the microversion support patch that
>> you are working on, and make use of it, or write a patch that has equivalent
>> functionality.
>> 
>> On Fri, Jan 20, 2017 at 6:57 PM, Rob Cresswell
>> <robert.cressw...@outlook.com> wrote:
>>> 
>>> Just a thought: With the way we currently do microversions, wouldnt this
>>> request 2.40 for every request ? There's a pretty good chance that would
>>> break things.
>>> 
>>> Rob
>>> 
>>> On 20 January 2017 at 00:02, Richard Jones <r1chardj0...@gmail.com> wrote:
>>>> 
>>>> FFE granted for the three patches. We need to support that nova API
>>>> change.
>>>> 
>>>> On 20 January 2017 at 01:28, Radomir Dopieralski <openst...@sheep.art.pl>
>>>> wrote:
>>>>> I would like to request a feature freeze exception for the following
>>>>> patch:
>>>>> 
>>>>> https://review.openstack.org/#/c/410337
>>>>> 
>>>>> This patch adds support for retrieving the simple tenant usages from
>>>>> Nova in
>>>>> chunks, and it is necessary for correct data given that related patches
>>>>> have
>>>>> been already merged in Nova. Without
>>>>> it, the data received will be truncated.
>>>>> 
>>>>> In order to actually use that patch, however, it is necessary to set
>>>>> the
>>>>> Nova API version to at least
>>>>> version 3.40. For this, it's necessary to also add this patch:
>>>>> 
>>>>> https://review.openstack.org/422642
>>>>> 
>>>>> However, that patch will not work, because of a bug in the
>>>>> VersionManager,
>>>>> which for some reason
>>>>> uses floating point numbers for specifying versions, and thus
>>>>> understands
>>>>> 2.40 as 2.4. To fix that, it
>>>>> is also necessary to merge this patch:
>>>>> 
>>>>> https://review.openstack.org/#/c/410688
>>>>> 
>>>>> I would like to request an exception for all those three patches.
>>>>> 
>>>>> An alternative to this would be to finish and merge the microversion
>>>>> support, and modify the first patch to make use of it. Then we would
>>>>> need
>>>>> exceptions for those two patches.
>>>>> 
>>>>> 
>>>>> __
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe:
>>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>> 
>>>> 
>>>> 
>>>> __
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
>>> 
>>> 
>>> ___

Re: [openstack-dev] [horizon] feature freeze exception request -- nova simple tenant usages api pagination

[Rob Cresswell]

Just a thought: With the way we currently do microversions, wouldnt this 
request 2.40 for every request ? There's a pretty good chance that would break 
things.

Rob

On 20 January 2017 at 00:02, Richard Jones 
> wrote:
FFE granted for the three patches. We need to support that nova API change.

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

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

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

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

[Rob Cresswell (rcresswe)]

I think the intent is to get eyes on those patches, to prevent a 1000 line 
rewrite only for a core to say “I think this is a bad idea”. So for important 
patches, its probably good to get earlier feedback.

Rob


On 16 Dec 2016, at 08:13, Radomir Dopieralski 
<openst...@sheep.art.pl<mailto:openst...@sheep.art.pl>> wrote:

I wonder if it really makes sense to put WIP patches on the priority list. I 
think it's a bit counter-productive, considering that the prioritizing of 
patches was supposed to make them merge faster -- but we don't want to merge 
WIP patches, do we?

On Fri, Dec 16, 2016 at 5:31 AM, Richard Jones 
<r1chardj0...@gmail.com<mailto:r1chardj0...@gmail.com>> wrote:
Hi folks,

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

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

Ocata-2 was tagged!

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

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

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

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


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

   Richard

[1] 
http://eavesdrop.openstack.org/meetings/horizon/2016/horizon.2016-12-14-20.00.html
[2] https://blueprints.launchpad.net/horizon/+spec/microversion-support
[3] https://review.openstack.org/#/c/350523
[4] https://releases.openstack.org/ocata/schedule.html
[5] https://review.openstack.org/#/q/starredby:r1chardj0n3s%20AND%20status:open

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://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<mailto: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] Please avoid blueprint overload

[Rob Cresswell]

Hey all,

So this was discussed at the summit, but its still being done; we keep hugely 
overloading blueprint scope. There are dozens of patches assigned to a vague 
"identity tables" blueprint, which was already marked Obsolete. Several of 
these were just small unrelated features that are nothing to do with Identity 
work, so those should just be wishlist bugs.

Please make new blueprints for each panel (Users, Domains, etc.) so that we can 
accurately track and prioritisework. I've -1'd a handful of the patches that 
were using the old blueprint, too.

I realise this seems like red tape, but its really, really useful for me and 
Richard to track which patches are in flight for which efforts, so that we can 
make sure important features like the Users work get the appropriate attention.

Cheers,
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] Draft team mascot

[Rob Cresswell (rcresswe)]

Radomir’s version has my vote.

On 7 Dec 2016, at 10:11, Radomir Dopieralski 
<openst...@sheep.art.pl<mailto:openst...@sheep.art.pl>> wrote:

Here, fixed.

On Wed, Dec 7, 2016 at 10:54 AM, Radomir Dopieralski 
<openst...@sheep.art.pl<mailto:openst...@sheep.art.pl>>wrote:
That looks kinda like a white baboon. It definitely doesn't look like Doge -- 
wrong color, wrong head. I think the legs are too long too.

On Wed, Dec 7, 2016 at 10:31 AM, Timur Sufiev 
<tsuf...@mirantis.com<mailto:tsuf...@mirantis.com>> wrote:
I still think this one 
https://wtf.jpg.wtf/0c/10/1479414543-0c1052f7c2f9990b6b0c472076594cb1.jpeg is 
the best :).

On Wed, Dec 7, 2016 at 1:07 AM Jason Rist 
<jr...@redhat.com<mailto:jr...@redhat.com>> wrote:
On 12/06/2016 01:48 PM, Richard Jones wrote:
> >> On 6 Dec 2016, at 20:19, Richard Jones 
> >> <r1chardj0...@gmail.com<mailto:r1chardj0...@gmail.com>> wrote:
> >> Please let me know what you think (by December 12) of this draft for
> >> our Horizon team mascot.
> >
> On 7 December 2016 at 07:38, Rob Cresswell (rcresswe)
> <rcres...@cisco.com<mailto:rcres...@cisco.com>> wrote:
> > Are we missing an attachment / link ?
>
> Weird! Trying again:
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
Much UI, such OpenStack, wow.

--
Jason E. Rist
Senior Software Engineer
OpenStack User Interfaces
Red Hat, Inc.
Freenode: jrist
github/twitter: knowncitizen

__
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://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<mailto: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] Draft team mascot

[Rob Cresswell (rcresswe)]

Are we missing an attachment / link ?

:)

> On 6 Dec 2016, at 20:19, Richard Jones  wrote:
> 
> Hi folks,
> 
> Please let me know what you think (by December 12) of this draft for
> our Horizon team mascot.
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing 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] [ptl][release] ocata release management communication

[Rob Cresswell (rcresswe)]

It looks like your email was already replied to:

http://lists.openstack.org/pipermail/openstack-dev/2016-November/108141.html


On 30 Nov 2016, at 18:38, Rob C > 
wrote:

[Resending without the PTLs in CC because it got my mail stuck in the spam 
filters]

I'm struggling to find good info on when the adjusted PTL nomination cycle 
starts.

I've checked here: 
https://releases.openstack.org/ocata/schedule.html#pike-ptls-self-nomination 
but it looks like the 'elections' section was supposed to be added to the table 
and wasn't.

I know from the updates to the charter that the elections should happen on or 
before R-3 but it doesn't provide any clarity on how much before then the 
nominations should be made?

Cheers
-Rob

On Tue, Nov 1, 2016 at 7:45 PM, Doug Hellmann 
> wrote:
PTLs,

As we did for the Mitaka and Newton cycles, I want to start this
cycle by making sure the expectations for communications with the
release team are clear to everyone so there is no confusion or
miscommunication about any of the process or deadlines. This
email is being sent to the openstack-dev mailing list as well as
the PTLs of all official OpenStack projects individually, to
improve the odds that all of the PTLs see it.  I will not be
taking the extra step of CCing individual PTLs or liaisons for
future emails.

(If you were a PTL last cycle, you may want to skip ahead to the
Things for you to do right now section at the end.)

Volunteers filling PTL and liaison positions are responsible for
ensuring communication between project teams happens smoothly. As
a community, we rely on three primary communication
strategies/tools for different purposes:

1. Email, for announcements and for asynchronous communication.

  We will be using the "[release]" topic tag on the openstack-dev
  mailing list for important messages related to release
  management.  Besides special announcements and instructions, I
  will send the countdown emails I sent last cycle, with weekly
  updates on focus, tasks, and upcoming dates. PTLs and release
  liaisons should configure your mailing list subscription and
  email client to ensure that those messages are visible (and
  then read them) so that you are aware of all deadlines, process
  changes, etc.

2. IRC, for time-sensitive interactions.

  There are far too many of you (56) to make it realistic for the
  three members of the release team to track you down
  individually when there is a deadline. We need you to do your
  part by making yourself available by configuring your IRC
  bouncer to listen in #openstack-release. You are, of course,
  welcome to stay in channel all the time, but you need to be
  there at least during deadline periods (the week before and
  week of each deadline).

3. Written documentation, for relatively stable information.

  The release team has published the schedule for the Ocata cycle
  to http://releases.openstack.org/ocata/schedule.html. Although
  I will highlight dates in the countdown emails, you may want to
  add important dates from the schedule to your calendar.

  Some projects have also added their own project-specific
  deadlines to that list. If you have something unique, please
  feel free to update it by patching the openstack/releases
  repository. There is no need to add a project-specific deadline
  that is the same as the global deadline.

The Ocata cycle overlaps with several major holidays, including
the new year. If you are planning time off, please make sure your
duties are being covered by someone else on the team. Its best to
let the release team know in advance so we dont delay approval
for release requests from someone we dont recognize, waiting for
your +1.

Please ensure that the release liaison for your project has the
time and ability to handle the communication necessary to manage
your release.  The release team is here to facilitate, but
finishing the work of preparing the release is ultimately the
responsibility of the project team. Failing to follow through on
a needed process step may block you from successfully meeting
deadlines or releasing.  Our release milestones and deadlines are
date-based, not feature-based.  When the date passes, so does the
milestone. If you miss it, you miss it. A few of you ran into
problems in past cycles because of missed communications. My goal
is to have all teams meet all deadlines during Ocata. We came
very very close for Newton; please help by keeping up to date on
deadlines.


Things for you to do right now:

1. Update your cross-project liaison on
   https://wiki.openstack.org/wiki/CrossProjectLiaisons#Release_management

2. Make sure your IRC nickname and email address listed in
   
http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml
   are correct. The release team, foundation staff, and TC all
   use those contact details to try to reach you at important
   points 

Re: [openstack-dev] [magnum-ui][horizon] use json-schema-form on workflow

[Rob Cresswell]

From a quick scan, it looks like you're using it several times in the same 
workflow? Why not just use the existing tabs type and create a single form? 
Have a look at https://review.openstack.org/#/c/348969/for reference.

Rob

On 25 Nov 2016 08:28, "Shuu Mutou" 
> wrote:
Hi Thai,

We're trying to use json-schema-form in workflow, but 'required' attribute 
doesn't work. So we can push 'create' button without input. Could you check 
following patch?

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

best regards,
Shu Muto


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

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

[Rob Cresswell (rcresswe)]

Big +1 from me

> On 14 Nov 2016, at 00:24, Richard Jones  wrote:
> 
> Hi Horizon core team,
> 
> I propose Kenji Ishii as a new Horizon core reviewer. Kenji has been a
> solid Horizon contributor for some time, with thoughtful and helpful
> reviews showing good judgment and good knowledge of Horizion and
> related systems. Please respond with your votes by Friday.
> 
> 
> Thanks,
> 
>Richard
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [horizon] USE_SSL

[Rob Cresswell]

Was that ever in local_settings? I couldnt find any mention of it. The Django 
docs are probably your best bet for information: 
https://docs.djangoproject.com/en/1.10/topics/security/#ssl-https

Rob

On 9 November 2016 at 13:23, Luke Hinds 
> wrote:
Hi,

I have noted that USE_SSL is no longer in local_settings.py

I have not had any luck in having google find the background of why this was 
removed for first django (if it has?)  and horizon.

From what I can see, it seems related to django views.

Does anyone understand the context of this being removed. I don't require the 
use of the parameter myself, I more want to update the security guide which 
recommends toggling it to true when using SSL.

Thanks,

Luke

__
OpenStack Development Mailing 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] Can not connect to Openstack Dashboard

[Rob Cresswell (rcresswe)]

Hi!

It sounds like there’s nothing wrong with your customisations at all; you’ve 
followed the standard workflow there. I think the final line of the error log 
is key here: "RuntimeError: Unable to create a new session key. It is likely 
that the cache is unavailable.”

Sounds to me something interrupted memcached, or your connection to it. That’s 
where I’d start.

Rob


On 5 Nov 2016, at 10:17, Alioune 
> wrote:

Hi all,

I've installed Openstack Prod env with Fuel and I would like to customize the 
dashboard by using my own logo.png and logo-splash.png.

I've changed all logo and logo-splash in these folders and restarted services 
apache2 and memcached :

/usr/share/openstack-dashboard/openstack_dashboard/themes/vendor/static/img/
/var/lib/openstack-dashboard/static/themes/vendor/img/
/usr/lib/python2.7/dist-packages/openstack_dashboard/static/dashboard/img/
/var/lib/openstack-dashboard/static/dashboard/img/

After that I was able to connect to the dashboard with my customizations but 
few hours after I got the error in [1]. All others openstack services ares 
correctly running in commands lines.

Someone knows what's wrong with my configurations ?
How to customize the horizon to avoid such an error ?

Best Regards,

[1] http://paste.openstack.org/show/588038/

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

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

[openstack-dev] [horizon] Summit Hangout Group

[Rob Cresswell]

Just in case anyone missed this, we have a Google hangouts group for catching 
up at the summit, reminding each other of useful sessions, impromptu tequila, 
etc.

If you'd like an invite, fire over an email address to me or Richard and we'll 
add you to the group.

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]New feature: enable/disable port security

[Rob Cresswell]

Thanks for the patch! For something of this size, a wishlist bug is usually 
adequate, perhaps with an API reference to help us review faster :)

Rob

On 19 October 2016 at 12:19, Gyorgy Szombathelyi 
>
 wrote:
Hi!

After I saw the allowed-address-pair handling is added to Horizon, I felt that 
completely enabling/disabling anti-spoofing rules would be a good addition, 
too, so I've create a patch:
https://review.openstack.org/#/c/388611/

Don't know if it needs a blueprint, or other administration stuff, but the 
patch is very light. Please tell me, what should be done to be accepted.

Br,
György

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

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

Re: [openstack-dev] [keystone][horizon] keystone/horizon integration session in barcelona

[Rob Cresswell]

This sounds great! Thanks for organising, Steve.

Rob

On 11 October 2016 at 22:32, Richard Jones 
> wrote:
Thanks, Steve, this will be a valuable session!

On 12 October 2016 at 08:14, Steve Martinelli 
> wrote:
The keystone team had a spare fishbowl session, and we decided to use it to 
collaborate with the horizon team on a few long standing issues we've had 
between the two projects.

You can view the session online:
https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/16907

Details here:
Wed 26, 3:55pm-4:35pm
Keystone: Keystone/Horizon integration session (Fishbowl)
https://etherpad.openstack.org/p/ocata-keystone-horizon

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



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

Re: [openstack-dev] [horizon] Integration Tests Status

[Rob Cresswell]

Integration tests are now non-voting, so feel free to recheck failing builds.

Rob

On 28 September 2016 at 14:23, Rob Cresswell 
<robert.cressw...@outlook.com<mailto:robert.cressw...@outlook.com>> wrote:
Hi all,

So the integration tests have started failing all over the place again. Given 
the number of failures over the past few weeks I've put up a patch to make them 
non-voting [1]. Please stop rechecking patches until this merges.

Reviewers, please be sure to check the test logs when they fail and be diligent 
about checking the UI.

1. https://review.openstack.org/#/c/378406/

Rob

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

[openstack-dev] [horizon] Integration Tests Status

[Rob Cresswell]

Hi all,

So the integration tests have started failing all over the place again. Given 
the number of failures over the past few weeks I've put up a patch to make them 
non-voting [1]. Please stop rechecking patches until this merges.

Reviewers, please be sure to check the test logs when they fail and be diligent 
about checking the UI.

1. https://review.openstack.org/#/c/378406/

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] Browser Support

[Rob Cresswell]

Agreed. I've created a bug here: https://bugs.launchpad.net/horizon/+bug/1625514

Rob

On 20 September 2016 at 09:40, amot...@gmail.com<mailto:amot...@gmail.com> 
<amot...@gmail.com<mailto:amot...@gmail.com>> wrote:
I think It is time to merge the wiki into horizon devref.
It is not a good situation that we have two contents.

2016-09-20 17:01 GMT+09:00 Rob Cresswell 
<robert.cressw...@outlook.com<mailto:robert.cressw...@outlook.com>>:
> As you've noticed, this doc isn't updated currently. The current browsers
> supported are listed here:
> http://docs.openstack.org/developer/horizon/faq.html (Stable Firefox and
> Chrome, and IE 11+)
>
> Rob
>
> On 20 September 2016 at 08:23, Shinobu Kinjo 
> <ski...@redhat.com<mailto:ski...@redhat.com>> wrote:
>>
>> There are ambiguous definitions like:
>>
>> IE 11 Good?
>>
>> Can we define this description as specific as possible?
>>
>>
>> On Tue, Sep 20, 2016 at 4:15 PM, Radomir Dopieralski
>> <openst...@sheep.art.pl<mailto:openst...@sheep.art.pl>> wrote:
>> > On Tue, Sep 20, 2016 at 3:53 AM, Jason Rist 
>> > <jr...@redhat.com<mailto:jr...@redhat.com>> wrote:
>> >>
>> >> This page hasn't been updated for a while - does anyone know the
>> >> latest?
>> >>
>> >> https://wiki.openstack.org/wiki/Horizon/BrowserSupport
>> >>
>> >
>> > As far as I know, there were no changes to the officially supported
>> > browser
>> > versions.
>> >
>> > The support for very old browsers (like msie 6) is going to deteriorate
>> > slowly, as the libraries that we use for styles and js drop support for
>> > them.
>> >
>> >
>> >
>> > __
>> > 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://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://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://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] Browser Support

[Rob Cresswell]

As you've noticed, this doc isn't updated currently. The current browsers 
supported are listed here: http://docs.openstack.org/developer/horizon/faq.html 
(Stable Firefox and Chrome, and IE 11+)

Rob

On 20 September 2016 at 08:23, Shinobu Kinjo 
> wrote:
There are ambiguous definitions like:

IE 11 Good?

Can we define this description as specific as possible?


On Tue, Sep 20, 2016 at 4:15 PM, Radomir Dopieralski
> wrote:
> On Tue, Sep 20, 2016 at 3:53 AM, Jason Rist 
> > wrote:
>>
>> This page hasn't been updated for a while - does anyone know the latest?
>>
>> https://wiki.openstack.org/wiki/Horizon/BrowserSupport
>>
>
> As far as I know, there were no changes to the officially supported browser
> versions.
>
> The support for very old browsers (like msie 6) is going to deteriorate
> slowly, as the libraries that we use for styles and js drop support for
> them.
>
>
> __
> OpenStack Development Mailing List (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] [all] Timeframe for future elections & "Release stewards"

[Rob Cresswell]

This makes sense to me. I think I'm having a slow day and wasn't connecting the 
dots. Having the next PTL come in and immediately hear feedback and begin 
planning how to address it, rather than coming in shortly before the planning 
event without a feedback loop, sounds like a good move.

+1

Rob

On 9 September 2016 at 12:49, Thierry Carrez 
<thie...@openstack.org<mailto:thie...@openstack.org>> wrote:
Rob Cresswell wrote:
> I've been toying with send this email for a while, but here goes: this
> all feels like overcomplication and changing of a system that doesn't
> really need to change.

Except the proposal here is actually to not change anything, but I see
what you mean.

> I've read the pros and cons, and I still can't really see a convincing
> reason not to move the PTL election to just-before-PTG, so that the new
> PTL is present for one development cycle as before.

Here is mine: it would fail to take into account that preparation for a
development cycle starts a few months /before/ PTG, not a just few weeks
before.

Talking with operators at the recent Ops midcycle, they were pretty
enthusiastic with the idea of having someone take responsibility for a
release cycle from day 0 (when you start collecting priorities) through
the development cycle, to release, up to early stable branch backports
and communication about the work that has been accomplished. The best
way to achieve that is to have that person designated in the middle of
the previous cycle, not just a few weeks before the development branches
open.

--
Thierry Carrez (ttx)

__
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

Re: [openstack-dev] [all] Timeframe for future elections & "Release stewards"

[Rob Cresswell]

I've been toying with send this email for a while, but here goes: this all 
feels like overcomplication and changing of a system that doesn't really need 
to change.

I've read the pros and cons, and I still can't really see a convincing reason 
not to move the PTL election to just-before-PTG, so that the new PTL is present 
for one development cycle as before. If the bigger projects want to have 
"release stewards" (which again, seems to be a fancy term for "current PTL" and 
"stable PTL") then they should be able to do that with the current model 
anyway. I think this preferable because it prevents any disconnect from either 
A) an election mid way through development and B) and election that isn't 
actually in effect until 3 months later.

I think the PTG/Forum change is already generating some confusion amongst 
management and organisations that are outside of core upstream development (as 
in, not 100% upstream work), and I think trying to shake up project 
organisation is just going to make things more confusing. I don't imagine I'm 
the only person reading through this thread and just wondering "why?".

I absolutely agree that encouraging people to take leadership roles and 
responsibility within their community is a great thing, but I don't think this 
really achieves it. That's down to the projects to change their culture, rather 
than just adding new roles and hoping for the best :)

Rob

On 9 September 2016 at 10:00, Thierry Carrez 
> wrote:
Sean Dague wrote:
> [...]
> I'm also not very concerned about delayed authority of the PTL. Peaceful
> handoff should be a pretty basic tenant in projects. Knowing about it
> for a longer time shouldn't be a big deal. If it causes giant strife to
> pass the torch from one PTL to the next there is something else going
> wrong in that project. In the few cases I'm familiar with in which a
> standing PTL lost an election, the relationship between that PTL and the
> PTL-next was fine.
>
> Again, these are personal experiences from the projects I'm actively
> involved with, or collaborate with the most.

I think that we are in alignment in 98% of what's proposed here.
Elections would still be run in the weeks prior to the summit. I'm
saying that there should be release stewards and by default it would be
the PTL. You are saying there should be PTLs with release duties, but
they can still delegate that. That's nearly the same thing.

The two differences are:
- defining "release stewards" as a thing slightly encourages PTLs to
delegate the role.
- the transfer of the ultimate tie-breaking/veto authority of the PTL
happens at election time in my case (as defined in the TC charter),
while you suggest it happens 3 months later, when development on N+1 starts.

One thing to note is that unless someone proposes a TC charter change
during Ocata, the authority of the newly-elected PTL starts at election
time, since the charter only recognizes one PTL at a time.

--
Thierry Carrez (ttx)

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

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

[openstack-dev] [horizon] Summit planning etherpad

[Rob Cresswell]

Hi all,

Etherpad for planning summit sessions: 
https://etherpad.openstack.org/p/horizon-ocata-summit

Please note the sessions have been requested, not scheduled, so the actual 
number we get may not be the same.

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][FFE]Support a param to specify subnet or fixed IP when creating port

[Rob Cresswell (rcresswe)]

I’m happy to allow this personally, but wanted to get others input and give 
people the chance to object.

My reasoning for allowing this:
- It’s high level, doesn’t affect any base horizon lib features.
- It is mature code, has multiple patch sets and a +2

I’ll give it a few days to allow others a chance speak up, then we can move 
forward.

Rob
 
> On 29 Aug 2016, at 07:17, Kenji Ishii  wrote:
> 
> Hi, horizoners
> 
> I'd like to request a feature freeze exception for the feature.
> (This is a bug ticket, but the contents written in this ticket is a new 
> feature.)
> https://bugs.launchpad.net/horizon/+bug/1588663
> 
> This is implemented by the following patch.
> https://review.openstack.org/#/c/325104/
> 
> It is useful to be able to create a port with using subnet or IP address 
> which a user want to use.
> And this has already reviewed by many reviewers, so I think the risk in this 
> patch is very few.
> 
> ---
> Best regards,
> Kenji Ishii
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Heat][Horizon] Any guidelines for naming heat resource type names?

[Rob Cresswell]

This sounds like a bug on the Horizon side. There is/was a patch regarding a 
similar issue with LBaaS v2 resources too. It's likely just an incorrect 
assumption in the logic processing these names.

Rob

On 16 Aug 2016 11:03 p.m., "Zane Bitter" 
> wrote:
On 16/08/16 17:43, Praveen Yalagandula wrote:
> Hi all,
> We have developed some heat resources for our custom API server. We
> followed the instructions in the development guide
> at http://docs.openstack.org/developer/heat/pluginguide.html and got
> everything working. However, the Horizon "Resource Types" panel is
> returning a 500 error with "TemplateSyntaxError: u'resource'" message.
>
> Upon further debugging, we found that the Horizon is expecting all Heat
> resource type names to be of form
> . However, we didn't see this
> requirement in the heat development documents. Some of our resource
> types have just two words (e.g., "Avi::Pool"). Heat itself didn't care
> about these names at all.

Given that Heat has a REST API specifically for validating templates,
it's surprising that Horizon would implement its own, apparently
incorrect, validation.

> Question: Is there a general consensus is to enforce
> the  format for type names?

No. We don't really care what you call them (although using OS:: or
AWS:: as a prefix for your own custom types would be very unwise). In
fact, Heat allows you to specify a URL of a template file as a resource
type, and it sounds like that might run afoul of the same restriction.

> If so, can we please update the heat plugin guide to reflect this?
> If not, we can file it is as a bug in Horizon.

+1 for bug in Horizon.

- ZB

__
OpenStack Development Mailing List (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-plugin] AngularJS 1.5.8

[Rob Cresswell]

Hi all,

Angular 1.5.8 is now updated in its XStatic repo: 
https://github.com/openstack/xstatic-angular

I've done some manual testing of the angular content and found no issues so 
far. I'll be checking that the JS tests and integration tests pass too; if they 
do, would it be desirable to release 1.5.8 this week, or wait until after N is 
released? It'd be nice to be in sync with current stable, but I don't want to 
cause unnecessary work a few weeks before plugin FF.

Thoughts?

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

Re: [openstack-dev] [horizon] Angular panel enable/disable not overridable in local_settings

[Rob Cresswell]

Ah, I see. I think I can understand why that was done initially, but since 
using UPDATE_HORIZON_CONFIG is already going beyond the scope of the enabled 
file since its directly affecting an exposed setting, I think we should just 
use the setting (and document it appropriately in the settings.rst)

Rob

On 2 August 2016 at 23:39, Richard Jones 
<r1chardj0...@gmail.com<mailto:r1chardj0...@gmail.com>> wrote:
On 3 August 2016 at 00:32, Rob Cresswell 
<robert.cressw...@outlook.com<mailto:robert.cressw...@outlook.com>> wrote:
Hi all,

So we seem to be adopting a pattern of using UPDATE_HORIZON_CONFIG in the 
enabled files to add a legacy/angular toggle to the settings. I don't like 
this, because in settings.py the enabled files are processed *after* 
local_settings.py imports, meaning the angular panel will always be enabled, 
and would require a local/enabled file change to disable it.

My suggestion would be:

- Remove current UPDATE_HORIZON_CONFIG change in the swift panel and images 
panel patch
- Add equivalents ('angular') to the settings.py HORIZON_CONFIG dict, and then 
the 'legacy' version to the test settings.

I think that should run UTs as expected, and allow the legacy/angular panel to 
be toggled via local_settings.

Was there a reason we chose to use UPDATE_HORIZON_CONFIG, rather than just 
updating the dict in settings.py? I couldn't recall a reason, and the original 
patch ( https://review.openstack.org/#/c/293168/ ) doesn't seem to indicate why.

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

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


 Richard


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

[openstack-dev] [horizon] Angular panel enable/disable not overridable in local_settings

[Rob Cresswell]

Hi all,

So we seem to be adopting a pattern of using UPDATE_HORIZON_CONFIG in the 
enabled files to add a legacy/angular toggle to the settings. I don't like 
this, because in settings.py the enabled files are processed *after* 
local_settings.py imports, meaning the angular panel will always be enabled, 
and would require a local/enabled file change to disable it.

My suggestion would be:

- Remove current UPDATE_HORIZON_CONFIG change in the swift panel and images 
panel patch
- Add equivalents ('angular') to the settings.py HORIZON_CONFIG dict, and then 
the 'legacy' version to the test settings.

I think that should run UTs as expected, and allow the legacy/angular panel to 
be toggled via local_settings.

Was there a reason we chose to use UPDATE_HORIZON_CONFIG, rather than just 
updating the dict in settings.py? I couldn't recall a reason, and the original 
patch ( https://review.openstack.org/#/c/293168/ ) doesn't seem to indicate why.

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

[openstack-dev] [horizon] [horizon-plugin] Xstatic Angular 1.4.x release

[Rob Cresswell]

Hi all,

There is a patch up to release xstatic-angular 1.4.10.1 here: 
https://review.openstack.org/#/c/348254

From our testing, the upgrade required only a single patch to Horizon, found 
here: https://review.openstack.org/#/c/309004

The migration guide can be found here: 
https://docs.angularjs.org/guide/migration#migrating-from-1-3-to-1-4

If you run into any difficulty, please ask in #openstack-horizon on IRC.

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] Midcycle Summary

[Rob Cresswell]

We didn't discuss it explicitly, but I don't believe the decision has changed. 
We can remove it, but last I checked the patches in line to handle testing 
after deprecation still needed work. If they've been updated etc. I can look 
again.

Rob

On 22 July 2016 at 07:52, Matthias Runge 
<mru...@redhat.com<mailto:mru...@redhat.com>> wrote:
On 21/07/16 19:40, Rob Cresswell wrote:
> Hi everyone,
>
> We had the Horizon mid cycle meetup last week, and I wanted to highlight
> some of the discussion and decisions made.
>
> Agenda: https://etherpad.openstack.org/p/horizon-newton-midcycle
> Notes: https://etherpad.openstack.org/p/horizon-newton-midcycle-notes
>
Thanks for sharing this Rob!

Did you also talk about deprecating of ceilometer based metering dashboard?

IIRC, we all agreed at the last summit, this doesn't really work for
large deployments and should be removed or replaced?

Or does anyone still use it?

Matthias

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

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham,
Michael O'Neill, Eric Shander

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

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

Re: [openstack-dev] [horizon] Plugin stability, failing tests etc.

[Rob Cresswell]

The aim wasn't to be focused on what's easiest for Horizon at all; it was a 
suggestion to let plugins keep moving during brief periods of instability when 
people make mistakes. We're aware of the plugins need for stability and correct 
deprecation, but we won't catch everything.

That said, there's been significant enough push back against the suggestion 
that I'll rethink it. I'll make sure we discuss the horizon / 
openstack_dashboard split again at the summit too.

Thanks everyone
Rob

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

David

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

__
OpenStack Development Mailing List (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] Midcycle Summary

[Rob Cresswell]

Hi everyone,

We had the Horizon mid cycle meetup last week, and I wanted to highlight some 
of the discussion and decisions made.

Agenda: https://etherpad.openstack.org/p/horizon-newton-midcycle
Notes: https://etherpad.openstack.org/p/horizon-newton-midcycle-notes

- Deprecation of table inline edit: This was discussed at the summit as a 
potential item for cleanup. Inline edit in tables has only been implemented in 
a few places, but breaks often in both functionality and styling. The 
maintenance overhead was seen as bigger than the small advantages of using it, 
so we're in the process of removing the implementations in the Dashboard code 
and deprecating the framework parts.
https://review.openstack.org/#/c/343861/

- OSProfiler integration: OSProfiler (https://github.com/openstack/osprofiler) 
is a small library that traces requests as they pass through the stack. We're 
working on exposing this as information in a developer dashboard panel so that 
devs can optimise their API calls and discover bottlenecks.

- Angular tables with Django actions: One of the highlighted issues with 
angular adoption is the "all-or-nothing" approach as a panel has really needed 
to be fully angular to feel the benefits in responsiveness. We've investigating 
launching the existing Python actions from Angular tables, so that we can move 
to client side search and pagination faster. The python tables will follow the 
usual deprecation process (minimum of two cycles).

- Glance V2 support: This is a critical requirement for this cycle. We've come 
up against some issues with features differing from V1, and have generally 
resolved to avoid working around missing API calls to reduce any hacks within 
Horizon and use the API as intended.

- Schema form: Angular workflows in their current state represent a nice 
improvement in responsive validation and quicker load times. However, the 
implementation is a quite verbose, has a couple of workarounds we'd like to 
remove, and generally requires quite in depth knowledge of AngularJS to use 
well. This is not ideal, as we'd like to build a system existing Horizon devs 
and plugins can extend quickly without learning a new framework. We're in the 
process of adopting a library that allows us to define complex forms and 
workflows in a JSON structure, which should make it much easier to take 
advantage of the new features. https://review.openstack.org/#/c/332745/

Overall, the mid cycle was a great success, and I'd like to thank everyone for 
attending! If anyone has any questions, please feel free to email or ping me on 
IRC (robcresswell)

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] On testing...

[Rob Cresswell]

Another option is to just run separate test jobs. Like Django tests in one 
runner, and angular in another. As different panels are deprecated and removed, 
and we alter the scope of the tests, two jobs might act as a good stopgap.

Rob

On 21 July 2016 at 01:58, Richard Jones 
> wrote:
On 21 July 2016 at 10:13, Timur Sufiev 
> wrote:
I'm not sure if (3) was the thing we agreed upon (and if it will help us to 
detect issues in Horizon) but the rest of options definitely make sense to me.

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


Also there is

5. Parallelize integration tests.

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


 Richard


On Wed, Jul 20, 2016 at 4:28 PM Richard Jones 
> wrote:
Hi folks,

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

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

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

These two are obviously at odds :-)

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

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

Does this sound about right?


 Richard

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

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



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

Re: [openstack-dev] [horizon] Plugin stability, failing tests etc.

[Rob Cresswell]

Kirill: The failures are just as visible, since the cores still control merging 
anyway. The only difference is that if it takes a few days to fix something in 
upstream Horizon, you needn't block your own content in the meantime. Later in 
the release cycle (around N-3, for example) cores could just not merge failing 
tests. Regardless, this is just a recommendation, and if you're comfortable 
adjusting to issues as they come through, then thats fine to base off master.

Graham:  The "risk" I refer to is in that in any project architecture rewrite 
you can make mistakes and break functionality. So that risk only arises from a 
rewrite.

"It also means that as a plugin I know that the released version of my plugin 
has been tested in my gate with the exact version of the code that the horizon 
team release." - I don't understand this part. If we release a horizon lib, 
we'd still being doing milestone releases to PyPI. So again, whether you 
consume that as a tarball or a PyPI package makes little difference to the day 
to day testing of your plugin. Its the same code.

Ideally - yes, we'd probably split horizon as a separate library, but thats 
something to discuss at the summit and judge demand, because most discussions 
thus far have concluded that its a lower priority issue than others.

Rob



On 20 July 2016 at 17:36, Hayes, Graham 
<graham.ha...@hpe.com<mailto:graham.ha...@hpe.com>> wrote:
On 20/07/2016 15:13, Rob Cresswell wrote:
> Yes, it would mean changing your requirements after a release. So, for
> example you might run two gate tests:
>
> - A voting Horizon-stable/milestone test, (or both)
> - A non-voting Horizon-master test
>
> That gives you a lot of control over making your tests passing (multiple
> patches to make the Horizon-master test pass, or all in one patch set
> alongside the horizon-milestone test bump), rather than random failures
> each week. You'd still be able to track the failures as they come in,
> but they won't break your gate each time.

I don't want control, I want to consume a library in a standard way -
the way we consume libraries from the rest of openstack.

> I don't think where horizon (the library) lives would change how you
> version against it. We don't currently have any plans to separate the
> two; while we realise its a desirable change, weighing the work and risk
> involved in the split architecture vs the end result, we've chosen to
> work on other higher priority items for now (performance, filtering
> improvements, angular work etc.)

Well, if would stop us having a reference to git branch in our
requirements, and allow to use the standard global requirements
process to manage the dependency.

It also means that as a plugin I know that the released version of
my plugin has been tested in my gate with the exact version of the
code that the horizon team release.

We can still do multiple patches to fix any changes in the horizon
library, and in the tip of the chain update the version in requirements.

The risk has just been moved to the plugins, which is not ideal.

It also makes downstream consumption *a lot* easier.

>
>
> On 20 July 2016 at 13:38, Hayes, Graham 
> <graham.ha...@hpe.com<mailto:graham.ha...@hpe.com>
> <mailto:graham.ha...@hpe.com<mailto:graham.ha...@hpe.com>>> wrote:
>
> On 20/07/2016 10:16, Rob Cresswell wrote:
> > Hey all,
> >
> > So we've had a few issues with plugin stability recently, and its
> > apparent that many plugins are building off Horizon master as a
> > dependency. I would really advise against this. A more manageable
> > development process may be to:
> >
> > - Base stable plugins against a stable release of Horizon
> > - Base WIP versions/new plugins off the last Horizon milestone, b2 in
> > this case, and then bump the version and capture issues within the same
> > patch. This should prevent random breakages, and should allow you to
> > just look at the release notes for that milestone.
>
> So this would mean changing tox.ini or requirements files after each
> horizon release?
>
> This dovetails nicely with the other thread about how we should be doing
> cross project interactions.
>
> What would be best, would be having horizon released as a separate
> library on pypi like the clients and oslo libs.
>
> Then openstack-dashboard, and all the plugins could rely on the same
> base library, without hacks like:
>
>deps =
>  -r{toxinidir}/requirements.txt
>  -r{toxinidir}/test-requirements.txt
>  http://tarballs.openstack.org/horizon/horizon-master.tar.gz
>
> in tox.ini or
>
># Testing Requirements
>
>  http://tarballs.opensta

Re: [openstack-dev] [horizon] Plugin stability, failing tests etc.

[Rob Cresswell]

Yes, it would mean changing your requirements after a release. So, for example 
you might run two gate tests:

- A voting Horizon-stable/milestone test, (or both)
- A non-voting Horizon-master test

That gives you a lot of control over making your tests passing (multiple 
patches to make the Horizon-master test pass, or all in one patch set alongside 
the horizon-milestone test bump), rather than random failures each week. You'd 
still be able to track the failures as they come in, but they won't break your 
gate each time.

I don't think where horizon (the library) lives would change how you version 
against it. We don't currently have any plans to separate the two; while we 
realise its a desirable change, weighing the work and risk involved in the 
split architecture vs the end result, we've chosen to work on other higher 
priority items for now (performance, filtering improvements, angular work etc.)

Rob



On 20 July 2016 at 13:38, Hayes, Graham 
<graham.ha...@hpe.com<mailto:graham.ha...@hpe.com>> wrote:
On 20/07/2016 10:16, Rob Cresswell wrote:
> Hey all,
>
> So we've had a few issues with plugin stability recently, and its
> apparent that many plugins are building off Horizon master as a
> dependency. I would really advise against this. A more manageable
> development process may be to:
>
> - Base stable plugins against a stable release of Horizon
> - Base WIP versions/new plugins off the last Horizon milestone, b2 in
> this case, and then bump the version and capture issues within the same
> patch. This should prevent random breakages, and should allow you to
> just look at the release notes for that milestone.

So this would mean changing tox.ini or requirements files after each
horizon release?

This dovetails nicely with the other thread about how we should be doing
cross project interactions.

What would be best, would be having horizon released as a separate
library on pypi like the clients and oslo libs.

Then openstack-dashboard, and all the plugins could rely on the same
base library, without hacks like:

   deps =
 -r{toxinidir}/requirements.txt
 -r{toxinidir}/test-requirements.txt
 http://tarballs.openstack.org/horizon/horizon-master.tar.gz

in tox.ini or

   # Testing Requirements
   http://tarballs.openstack.org/horizon/horizon-master.tar.gz#egg=horizon

in (test-)requirements.txt

Is that on roadmap?

> On the Horizon side, we've moved our FF a week earlier, so I think that
> week combined with the usual RC period should be enough time to fix
> bugs. We'll aim to make sure our release notes are complete with regards
> to breaking issues for plugins, and deprecate appropriately.
>
> Rob


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

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

[openstack-dev] [horizon] Plugin stability, failing tests etc.

[Rob Cresswell]

Hey all,

So we've had a few issues with plugin stability recently, and its apparent that 
many plugins are building off Horizon master as a dependency. I would really 
advise against this. A more manageable development process may be to:

- Base stable plugins against a stable release of Horizon
- Base WIP versions/new plugins off the last Horizon milestone, b2 in this 
case, and then bump the version and capture issues within the same patch. This 
should prevent random breakages, and should allow you to just look at the 
release notes for that milestone.

On the Horizon side, we've moved our FF a week earlier, so I think that week 
combined with the usual RC period should be enough time to fix bugs. We'll aim 
to make sure our release notes are complete with regards to breaking issues for 
plugins, and deprecate appropriately.

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] Angular action services and initScope

[Rob Cresswell]

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

Rob

On 18 July 2016 at 19:34, Tripp, Travis S 
> wrote:
TL;DR, I’ll be quite happy to get rid of the need for initScope and like 
exploring a common way to share model other than events.

 |From: Richard Jones >
| Date: Sunday, July 17, 2016 at 6:55 PM

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

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

As FYI, the way I mentioned for factories is *not* inventing something new and 
is how they were intended and even used in angular in that way.  A factory is a 
singleton object whose job is to create instances of objects.  It is even used 
that way in angular code. See $cacheFactory [0]

[0] https://github.com/angular/angular.js/blob/master/src/ng/cacheFactory.js

The differentiation of .factory vs .service is still obtuse since they are both 
singletons, but the concept of a factory object whether .service or .factory 
still remains.

|From: Richard Jones >
| Date: Sunday, July 17, 2016 at 6:55 PM
|Thus the controller and action service, which are quite independent pieces of 
code,
| must have intimate knowledge of each  other's internal operation. I'm not so 
keen on that ;-)

That is yuck!

|From: Richard Jones >
| Date: Sunday, July 17, 2016 at 6:55 PM

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

The event based mechanism was an attempt originally proposed by Thai to get 
around the essentially hard coded shared model service in launch instance where 
the steps are tightly bound to that model service. There was also some idea 
that some steps could be reusable / recomposable across work flows (such as 
update metadata) if you didn’t tightly bind things.

|From: Richard Jones >
| Date: Sunday, July 17, 2016 at 6:55 PM

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

We’ve roughly talked about a need for something like this for sometime and I 
think it would be great to explore it. It is similar to some of the Django 
workflow concepts.  Effectively, this boils down to steps declaring with data 
they require and which data they provide.  I’d prefer it if we can disassociate 
the step name from the data name. We want to keep the steps from being tightly 
coupled to each other, but rather be declarative about the data they use.  For 
example, if we later want to split out steps (see History of Launch Instance, 
Chapter 1: Source and Details) or want to combine steps (See History of Launch 
Instance: Chapter Boy it would be nice if we could have a quick launch step as 
the first step), it will be easier to do if we don’t couple the model to the 
current presentation.

By the way, yes the ability to watch the data or react to changes in the data 
is definitely useful. For example, in Launch Instance if you increase the 
number of instances, this may mean that the flavor you’ve chosen will now go 
over your quota (select smaller), which is a different step.


__
OpenStack Development Mailing 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] [OPENSTACK] [HORIZON] Changing theme

[Rob Cresswell]

Which version of Horizon are you running? Those look like Liberty settings to 
me, so wanted to check.

Rob

On 18 July 2016 at 07:49, 
ansh.ansh20...@gmail.com 
> wrote:
Hi,

I am unable to change the theme for my openstack horizon. I tried with the this 
and various other tutorial but i am still unable to achieve my goal.

I also want to have a custom "splash" (a complete custom login) and i am unable 
to find any good tutorial.

I tried "local_settings.py" with following
CUSTOM_THEME_PATH="static/themes/production"
CUSTOM_THEME_PATH="themes/production"
CUSTOM_THEME_PATH="static/production"

"production" directory is present in 
"/usr/share/openstack-dashboard/openstack_dashboard/static/themes" as well as 
"/usr/share/openstack-dashboard/openstack_dashboard/static/custom" directories.

Also i tried deleting the "i/usr/share/openstack-dashboard-ubuntu-theme" and 
"/usr/share/openstack-dashboard/openstack_dashboard/local/ubuntu_theme.py" and 
still no use.

No matter what i do, horizon is loading images from "static/themes/ubuntu " 
directory 
("http://controller/static/themes/ubuntu/image-background-pattern.png;).

Kindly point me to anything i am doing wrong or/and any well-documented 
tutorial or docs.

Also i have run collectstatic after each modifications.

Also after deleting "/us/share/openstack-dashboard-ubuntu-theme" if i run 
collectstatic then it is giving error with 
"/us/share/openstack-dashboard-ubuntu-theme/static/themes/ubuntu" not found

NOTE: I want to have the above changes in an already running setup by 
manipulating files.

Thanks and Regards,
Bikramaditya Sahoo

__
OpenStack Development Mailing List (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] Next weeks meeting cancelled (2016-07-13)

[Rob Cresswell]

Next weeks meeting is cancelled due to the midcycle. Meetings will resume as 
normal on the 20th of July.

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] Keep / Remove 800 UTC Meeting time

[Rob Cresswell]

There doesn't seem to have been any responses here, so I've gone ahead and 
proposed a patch to alter the meeting times: 
https://review.openstack.org/#/c/338130/

Rob


On 30 June 2016 at 09:29, Rob Cresswell 
<robert.cressw...@outlook.com<mailto:robert.cressw...@outlook.com>> wrote:
Hi everyone,

I've mentioned in the past few meetings that attendance for the 800 UTC meeting 
time has been dwindling. As it stands, there are really only 3 regular 
attendees (myself included). I think we should consider scrapping it, and just 
use the 2000 UTC slot each week as a combined Horizon / Drivers meeting.

Does anyone have any strong objections to this? I'm more than happy to run the 
meeting if people would like to attend, but it seems wasteful to drag people 
into it each week if its empty.

Rob

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

[openstack-dev] [horizon] The bug list - how to use it, and how to triage

[Rob Cresswell]

Hello!

I just wanted to talk through Horizons bug list ( 
https://bugs.launchpad.net/horizon/ ), and how to use it to find issues you can 
help solve or review, as well as how to help triage bugs if you have time to 
help out.

Using the bug list:

- The "Tags" section on the right hand side is your friend. We have a whole 
bunch of tags related to language (like "angularjs"), the bug content 
("integration-tests" or "ux") or the type of service knowledge that may be 
useful in solving the bug ("nova", "neutron" etc). If you're just starting out, 
checking out the "low-hanging-fruit" tag, which is used to indicate 
straightforward bugs for your first couple of contributions.

- If you're looking for code to review, try using the Advanced Search to filter 
for Critical/High priority bugs that are In Progress. This means they are 
important to us, and have a patch up on Gerrit. Alternatively, scroll down and 
select the next milestone ("newton-2" in this case) from the 
"Milestone-targeted bugs" on the right hand side. These are bugs that have been 
triaged and we'd like to have complete for this milestone.

- Don't be intimidated by bugs marked High/Critical. Priority is often not 
linked to complexity, so its worth looking in to.

- If you assign yourself to a bug, but are unable to complete it, remember to 
remove yourself as an assignee and set the status back to "Confirmed" or "New"; 
this makes it much easier for us to track which bugs are being actively worked 
on.

Triaging the bug list:

- https://wiki.openstack.org/wiki/BugTriage This is a great step by step piece 
of documentation on triage, and definitely worth reading through to understand 
the prioritisation system.

- Target bugs to the "Next" milestone by default. This makes it easy to see 
whether bugs have been triaged or not. If a bug is important for this 
milestone, or looks close to completion, just target it to the next milestone 
right away.

- Remember to use tags, but be careful how you use them. Generally, we use the 
service name tags, like "nova", "swift" etc. to indicate that specific 
knowledge of the service may be useful for this bug. Just because a bug is on 
the Instances panel, does not mean it should immediately be tagged with "nova"; 
consider whether it is actually service specific, or is really a UI or other 
code issue.

- You don't need to be on the bug team to triage; if there's something you're 
unable to do, just ping a member of the bug team: 
https://launchpad.net/~horizon-bugs

Hope this helps! If anyone has any other questions, reply here or ping me on 
IRC (robcresswell)

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

[openstack-dev] [horizon] Keep / Remove 800 UTC Meeting time

[Rob Cresswell]

Hi everyone,

I've mentioned in the past few meetings that attendance for the 800 UTC meeting 
time has been dwindling. As it stands, there are really only 3 regular 
attendees (myself included). I think we should consider scrapping it, and just 
use the 2000 UTC slot each week as a combined Horizon / Drivers meeting.

Does anyone have any strong objections to this? I'm more than happy to run the 
meeting if people would like to attend, but it seems wasteful to drag people 
into it each week if its empty.

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

[openstack-dev] [horizon] 800 UTC Meeting Cancelled on 15/06

[Rob Cresswell]

Hi all,

I'm away next week so won't be able to run the 800 UTC meeting. The 2000 UTC 
meeting will be chaired by David Lyle.

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

[openstack-dev] [horizon] Horizon Midcycle

[Rob Cresswell]

Hi all,

Horizon midcycle will be at Cisco HQ, Building 15 in San Jose, July 12th - 14th.

Registration and topics etherpad: 
https://wiki.openstack.org/wiki/Sprints/HorizonNewtonSprint

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

[openstack-dev] [horizon] Midcycle Dates Poll

[Rob Cresswell]

Hi all,

Quick poll to get a preferred date for the Newton midcycle:

http://doodle.com/poll/xvchsbbs4qz9tzr7

If you'd like a reference point, the release schedule is here: 
http://releases.openstack.org/newton/schedule.html. Planning should be 
finalised within the next week, so please respond promptly.

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

[openstack-dev] [horizon] Feature Freeze one week earlier in Newton.

[Rob Cresswell (rcresswe)]

Hi all,

As requested we’ll be moving our feature freeze in Newton to R-6 
(http://releases.openstack.org/newton/schedule.html). This is one week earlier 
than in previous cycles, to give plugins a chance to finalise their own 
features for Newton without risk of breaking changes. The FFE process remains 
the same.

The patch documenting this change is here: 
https://review.openstack.org/#/c/314075/

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][release] freeze timelines for horizon in newton

[Rob Cresswell]

Thanks Amrith. I'm referring to the release timeline when I said expectation; 
previously every plugin had been on an independent release, rather than being 
the same as Horizon. Several plugins have changed this without any 
communication; it would've been better to let us know at the time so we 
could've discussed earlier, or during the summit for example.

Rob

On 1 May 2016 11:26 p.m., "Amrith Kumar" 
<amr...@tesora.com<mailto:amr...@tesora.com>> wrote:
From: Rob Cresswell (rcresswe) 
[mailto:rcres...@cisco.com<mailto:rcres...@cisco.com>]
Sent: Friday, April 29, 2016 4:28 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [horizon][release] freeze timelines for horizon in 
newton

This has been discussed (just now) in the release management plan 
(https://etherpad.openstack.org/p/newton-relmgt-plan) See point 8 under 
Communication/Governance Changes. From an immediate standpoint, the RC phase of 
this cycle will be much stricter to prevent late breakages. Going forward, 
we’re likely going to establish an earlier feature freeze too, pending 
community discussion.
[amrith] Thanks Rob, I’ve updated the etherpad with a link to this mail thread.

On a separate note, this email prompted me to scan the governance for the 
dashboard plugins and it became apparent that several have changed their 
release tags, without informing Horizon of this release cadence expectation via 
IRC, email, or our plugin feedback fishbowl. If we are to continue building a 
good plugin ecosystem, the plugins *must* communicate their expectations to us 
upstream; we do not have the time to monitor every plugin.
[amrith] I’m unsure what this expectation is. I tried to google it but came up 
empty.

I assume that you are asking that we let you know when we release a new version 
of the dashboard, is that right? Or is it something else? In any event, would 
you provide me a link to something describing this expectation and I’ll make 
sure that we try and stay true to it.

Rob


On 29 Apr 2016, at 11:26, Amrith Kumar 
<amr...@tesora.com<mailto:amr...@tesora.com>> wrote:

In the Trove review of the release schedule this morning, and in the 
retrospective of the mitaka release process, one question which was raised was 
the linkage between projects like Trove and Horizon.

This came up in the specific context of the fact that projects like Trove (in 
the form of the trove-dashboard repository) late in the Mitaka cycle[3]. Late 
in the Mitaka cycle, a change in Horizon caused Trove to break very close to 
the feature freeze date.

So the question is whether we can assume that projects like Horizon will freeze 
in R-6 to ensure that (for example) Trove will freeze in R-5.

Thanks,

-amrith

[1] http://releases.openstack.org/newton/schedule.html
[2] https://review.openstack.org/#/c/311123/
[3] https://review.openstack.org/#/c/307221/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org<mailto: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][release] freeze timelines for horizon in newton

[Rob Cresswell (rcresswe)]

This has been discussed (just now) in the release management plan 
(https://etherpad.openstack.org/p/newton-relmgt-plan) See point 8 under 
Communication/Governance Changes. From an immediate standpoint, the RC phase of 
this cycle will be much stricter to prevent late breakages. Going forward, 
we’re likely going to establish an earlier feature freeze too, pending 
community discussion.

On a separate note, this email prompted me to scan the governance for the 
dashboard plugins and it became apparent that several have changed their 
release tags, without informing Horizon of this release cadence expectation via 
IRC, email, or our plugin feedback fishbowl. If we are to continue building a 
good plugin ecosystem, the plugins *must* communicate their expectations to us 
upstream; we do not have the time to monitor every plugin.

Rob


On 29 Apr 2016, at 11:26, Amrith Kumar 
> wrote:

In the Trove review of the release schedule this morning, and in the 
retrospective of the mitaka release process, one question which was raised was 
the linkage between projects like Trove and Horizon.

This came up in the specific context of the fact that projects like Trove (in 
the form of the trove-dashboard repository) late in the Mitaka cycle[3]. Late 
in the Mitaka cycle, a change in Horizon caused Trove to break very close to 
the feature freeze date.

So the question is whether we can assume that projects like Horizon will freeze 
in R-6 to ensure that (for example) Trove will freeze in R-5.

Thanks,

-amrith

[1] http://releases.openstack.org/newton/schedule.html
[2] https://review.openstack.org/#/c/311123/
[3] https://review.openstack.org/#/c/307221/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [horizon] Summit next week - Meetings cancelled

[Rob Cresswell]

Hi all,

Due to the summit next week, both of the usual Wednesday meetings are cancelled.

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

[openstack-dev] [horizon] 1200 UTC meeting changed to 800 UTC

[Rob Cresswell]

Hi all,

The 1200 UTC meeting time has been changed to 800 UTC. You can find the ICS 
files for the team meetings and drivers meetings in the links below.

http://eavesdrop.openstack.org/#Horizon_Team_Meeting
http://eavesdrop.openstack.org/#Horizon_Drivers_Meeting

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][all] How to properly depend on Horizon

[Rob Cresswell]

When you refer to publishing horizon on PyPI, did you mean the entire service 
(horizon + openstack_dashboard), or just the horizon package?

My advice would be to add the horizon tarball to requirements.txt rather than 
test-requirements, and just use stable-* tarball when creating stable plugin 
releases. I'm not sure what the tox method achieves; it seems like it obscures 
the dependency to me.

Rob

On 4 April 2016 at 02:37, Serg Melikyan 
> wrote:
Hi folks,

while I was working on bug [0] with incorrect dependency to horizon in
stable/mitaka I discovered at least three different ways how people
add such dependency:

1. tarball dependency in tox.ini [1]
2. tarball dependency in test-requirements.txt [2]
3. git repo dependency in  test-requirements.txt [3]

Question: How to properly depend on horizon?

P.S. Looks like update.py in openstack/requirements simply ignores #2
and #3 and don't count as extra dependency.

P.P.S Why we can't publish horizon to 
pypi.openstack.org?

Reference:
[0] https://bugs.launchpad.net/bugs/1565577
[1] 
https://github.com/openstack/designate-dashboard/blob/dfa2fc6660467da2f1c53e12aeb7d7aab5d7531e/tox.ini#L20
[2] 
https://github.com/openstack/monasca-ui/blob/8861bede7e06d19b265d3425208b4865c480eb69/test-requirements.txt#L25
[3] 
https://github.com/openstack/manila-ui/blob/bf382083b281a77f77df9e0bd51376df49d53b2e/test-requirements.txt#L5

--
Serg Melikyan, Development Manager at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.com

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

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