from:"Rob Cresswell \(rcresswe\)"

Re: [openstack-dev] [horizon] Multi-region support in shared Keystone service deployment

2017-08-17 Thread 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

2017-08-17 Thread 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

Re: [openstack-dev] [Openstack][horizon][ceilometer][gnocchi]Viewing gnocchi statistics on Dashboard

2017-08-09 Thread 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][Nova] Editing flavor causing instance flavor display error

2017-08-07 Thread 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

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

2017-07-17 Thread 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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-07-05 Thread 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 
> 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
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] Next weekly IRC meeting cancelled

2017-06-20 Thread 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 ?

2017-06-07 Thread 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

2017-05-31 Thread 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

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

2017-05-01 Thread 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

Re: [openstack-dev] [ptls] Project On-Boarding Rooms

2017-04-21 Thread 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] [ptls] Project On-Boarding Rooms

2017-03-15 Thread 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

2017-03-14 Thread 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

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

2017-03-09 Thread 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

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

2017-02-06 Thread 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

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

2017-01-24 Thread 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  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  
> 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
>>  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  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
>>> 
>> 
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

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

2016-12-16 Thread 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 
> 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 
> wrote:
Hi folks,

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

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

Ocata-2 was tagged!

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

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

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

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

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

   Richard

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

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

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

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

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

2016-12-07 Thread 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

2016-12-06 Thread 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

2016-12-01 Thread 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] [Horizon] Proposing Kenji Ishii for core

2016-11-15 Thread 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] Can not connect to Openstack Dashboard

2016-11-07 Thread 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

Re: [openstack-dev] [Horizon][FFE]Support a param to specify subnet or fixed IP when creating port

2016-08-30 Thread 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

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

2016-05-09 Thread 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

2016-04-29 Thread 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

Re: [openstack-dev] [horizon] - oAuth tab proposal

2016-03-31 Thread Rob Cresswell (rcresswe)

Could you put up a blueprint for discussion? We have a weekly meeting to review 
blueprints: https://wiki.openstack.org/wiki/Meetings/HorizonDrivers

The blueprint template is here: 
https://blueprints.launchpad.net/horizon/+spec/template

Thanks!

Rob

On 31 Mar 2016, at 10:57, Marcos Fermin Lobo 
> wrote:

Hi all,

I would like to propose a new tab in "Access and security" web page.

As you know, keystone offers an OAUTH plugin for authentication. This means 
that third party applications could access to OpenStack cloud resources using 
OAUTH. Now, this is possible using the CLI but there is nothing (AFAIK) in 
Horizon.

I would propose a new tab in "Access and security" web page to manage OAUTH 
credentials. As usual, this new tab would have a list of OAUTH crendentials 
with buttons to approve and remove them.

Please see a simple mockup here 
https://mferminl.web.cern.ch/mferminl/mockups/horizon-oauth-mockup.png

Comments, suggestions... are very welcome!

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

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

Re: [openstack-dev] [Horizon] How to add plugins from outside horizon tree

2016-03-28 Thread Rob Cresswell (rcresswe)

http://docs.openstack.org/developer/horizon/tutorials/plugin.html

This should answer most questions about setting up and installing a plugin. 
Hope it helps!

Rob

On 28 Mar 2016, at 18:33, Mohan Kumar 
> wrote:

Hi Team ,

   Could you please shed light on some steps /configuration/documentation about 
how to add Horizon plugins from outside horizon tree . I can see punch of 
plugins were developed at  " 
http://docs.openstack.org/developer/horizon/plugins.html "  but couldn't able 
to any documentation .

  In my case i need to define Horizon plugin  for  "networking-sfc"  from 
neutron sub-project repo .

Repo path : https://github.com/openstack/networking-sfc

Code Review Link : https://review.openstack.org/#/c/258430/

Thanks.,
Mohankumar.N
__
OpenStack Development Mailing List (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

2016-03-15 Thread Rob Cresswell (rcresswe)

Hi folks,

I'm announcing my candidacy for PTL for Horizon for the Newton release cycle.

My main goals for the cycle are:

- Remove roadblocks from AngularJS development so that the code can
  mature. This means optimistically approving patches in the experimental
  disabled panels, so that it can be rapidly iterated. The Swift rewrite is a
  fantastic example of how focused reviews and dropping the demand for
  absolute perfection allow for a dramatically improved experience via
  AngularJS.

- Work on scale issues, and improve non-performant content. There are a number
  of panels in Horizon that are often unused (especially in the Admin
  dashboard). We need to apply the existing tools available to us such as
  pagination and filtering, as well as investigate other proposals.

- Improve bug management and project organisation. In the past few cycles, the
  bugs and blueprints on launchpad have been quickly growing while triage work
  dwindles. In Mitaka, we've run several bug days as well as holding a Horizon
  Drivers meeting every other week to analyse blueprints as a group. I'd like
  to continue the focus on bringing our tooling back to useable state, so that
  we correctly address current issues and customer needs.

Finally, I believe one of the most important parts of being a PTL is community
engagement, and will continue to build an active and positive developer
community.

Election repo patch: https://review.openstack.org/#/c/293083/

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] Javascript linting and documentation

2016-03-09 Thread Rob Cresswell (rcresswe)

If possible, I’d really prefer we left linting work to Newton. It’ll be good to 
get it to a more usable state again, but we ought to be focusing on thoroughly 
checking the new Launch Instance for bugs and edge usage cases, as well as the 
outstanding bugs and blueprints targeted at RC1 
(https://launchpad.net/horizon/+milestone/mitaka-rc1). This is a great 
opportunity to prove that the Angular rewrites are fully capable of providing 
an improved experience, and we should be capitalising on that.

Rob


On 9 Mar 2016, at 02:25, Richard Jones 
> wrote:

Hey all,

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

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

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

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


 Richard


[1] http://governance.openstack.org/reference/cti/javascript-cti.html
[2] https://review.openstack.org/#/c/290235/

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

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

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

2016-03-09 Thread Rob Cresswell (rcresswe)

+1 from me. Diana’s almost single handedly fixed our Bootstrap usage and gives 
lots of great reviews all across Horizon too. The boost to branding, theming 
and potential for accessibility, as well as huge reduction in CSS/HTML 
maintenance overhead, has been brilliant.

Rob


On 9 Mar 2016, at 16:15, Timur Sufiev 
> wrote:

+1, Diana's contribution to the front-end aspect of Horizon during several 
recent release cycles was second to none!

On Wed, Mar 9, 2016 at 2:15 AM Richard Jones 
> wrote:
+1 we need Diana's perspective, knowledge and enthusiasm

On 9 March 2016 at 10:03, Tripp, Travis S 
> wrote:
+1, no questions asked. It is rare to find somebody with the passion that Diana 
has shown.

From: Lin Hua Cheng 
>>
Reply-To: OpenStack List 
>>
Date: Tuesday, March 8, 2016 at 3:48 PM
To: OpenStack List 
>>
Subject: Re: [openstack-dev] [horizon] Proposal to add Diana Whitten to 
horizon-core

big +1 from me.

She made a lot of contribution in making theming better for horizon and also 
prevented potential issues through reviews.
Thanks for all the hard work, Diana.

-Lin

On Tue, Mar 8, 2016 at 2:06 PM, David Lyle 
>>
 wrote:
I propose adding Diana Whitten[1] to horizon-core.

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

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

Thanks,
David

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

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

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

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (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] Bug Day 2

2016-01-11 Thread Rob Cresswell (rcresswe)

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

Rob


On 4 Jan 2016, at 10:54, Rob Cresswell (rcresswe) 
<rcres...@cisco.com<mailto:rcres...@cisco.com>> wrote:

Hi folks,

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

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

Regards,
Rob




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org<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] Bug Day 2

2016-01-04 Thread Rob Cresswell (rcresswe)

Hi folks,

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

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

Regards,
Rob




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

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

2015-12-02 Thread Rob Cresswell (rcresswe)

An equally big +1!

On 02/12/2015 18:56, "David Lyle"  wrote:

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

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

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

2015-12-02 Thread Rob Cresswell (rcresswe)

A big +1 for me!

On 02/12/2015 18:52, "David Lyle"  wrote:

>I propose adding Timur Sufiev[1] to horizon-core.
>
>Over the last several cycles Timur has consistently been providing
>great reviews, actively participating in the Horizon community, and
>making meaningful contributions particularly around testing and
>stability.
>
>Please respond with comments, +1s, or objections within one week.
>
>Thanks,
>David
>
>[1] 
>http://stackalytics.com/?module=horizon-group_id=tsufiev-x=al
>l
>
>__
>OpenStack Development Mailing List (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] Supporting Django 1.9

2015-11-29 Thread Rob Cresswell (rcresswe)

https://blueprints.launchpad.net/horizon/+spec/drop-dj17


This is where changes are currently being tracked. I don’t quite
understand why these would be back ported; they would break Liberty with
1.7. Perhaps we can discuss on IRC tomorrow?

Rob

On 27/11/2015 13:58, "Thomas Goirand" <z...@debian.org> wrote:

>On 11/27/2015 11:18 AM, Rob Cresswell (rcresswe) wrote:
>> Mitaka will support 1.9. I’m already working on it :)
>> Liberty is >= 1.7 and < 1.9, so shouldn’t matter.
>> 
>> Rob
>
>It does mater for me, at least until the final release of Mitaka. Could
>you please make sure that all of these Django 1.9 patches are easily
>identifiable, so that I can later on backport them (even if it never
>reaches the upstream stable/liberty branch)? That would help me a lot.
>I'm not sure how to list them all after the facts though. Maybe opening
>a wiki page? Any suggestion?
>
>Cheers,
>
>Thomas Goirand (zigo)
>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [horizon] Supporting Django 1.9

2015-11-27 Thread Rob Cresswell (rcresswe)

Mitaka will support 1.9. I’m already working on it :)
Liberty is >= 1.7 and < 1.9, so shouldn’t matter.

Rob


On 27/11/2015 09:23, "Thomas Goirand"  wrote:

>Hi,
>
>Django 1.9 is due to be released in early December, and will reach
>Debian Sid soon after that. It'd be nice to have fixes for it ASAP. I
>already have bugs against some of the packages I maintain:
>
>https://bugs.debian.org/806365
>https://bugs.debian.org/806362
>
>Any help (patches sent upstream and/or to the Debian BTS) to fix these
>would be greatly appreciated.
>
>Cheers,
>
>Thomas Goirand (zigo)
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [Horizon] Bug Day: The Aftermath

2015-11-25 Thread Rob Cresswell (rcresswe)

Hi all,

Bug day was great! We categorised around 140 bugs, reducing the Undecided count 
to 466 from ~600, and also removed around 50 bugs that were no longer valid. 
This is a step in the right direction, and I think it would be worth organising 
more bug days in the cycle, spread out so as not to distract too much from dev 
work.

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

[openstack-dev] [Horizon] Bug day! Yeah!

2015-11-24 Thread Rob Cresswell (rcresswe)

Reminder about bug day! Hop on IRC (#openstack-horizon) and help out :)

https://etherpad.openstack.org/p/horizon-bug-day

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] Bug day! Yeah!

2015-11-19 Thread Rob Cresswell (rcresswe)

As requested,
https://etherpad.openstack.org/p/horizon-bug-day

Rob

From: Richard Jones <r1chardj0...@gmail.com<mailto:r1chardj0...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, 19 November 2015 20:39
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] Bug day! Yeah!

Let's do it. I'd like to suggest we use an etherpad to keep track of what 
people have done. If it's not created when I start my day, I'll make one.

     Richard

On 19 November 2015 at 22:19, Rob Cresswell (rcresswe) 
<rcres...@cisco.com<mailto:rcres...@cisco.com>> wrote:
Hey folks,

Our bug list is… rather large. We’ve discussed having a bug day, where as a 
community we all dedicate some time to triaging bugs and discussing in the IRC 
channel as we go.

First off, see the docs about bug triage: 
https://wiki.openstack.org/wiki/BugTriage

Secondly, lets pick a date. I’d suggest next Tuesday (24th November); if that 
doesn’t work for a good number of us, then the following Tuesday (1st 
December). Trying to account for Thanksgiving :)

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] Bug day! Yeah!

2015-11-19 Thread Rob Cresswell (rcresswe)

Hey folks,

Our bug list is… rather large. We’ve discussed having a bug day, where as a 
community we all dedicate some time to triaging bugs and discussing in the IRC 
channel as we go.

First off, see the docs about bug triage: 
https://wiki.openstack.org/wiki/BugTriage

Secondly, lets pick a date. I’d suggest next Tuesday (24th November); if that 
doesn’t work for a good number of us, then the following Tuesday (1st 
December). Trying to account for Thanksgiving :)

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] [ceilometer][vitrage][horizon] ceilometer alarms screen in horizon

2015-11-08 Thread Rob Cresswell (rcresswe)

This blueprint is being revived by a new assignee I believe: 
https://blueprints.launchpad.net/horizon/+spec/ceilometer-alarm-management-page

Rob

From: "ITZIKOWITZ, Noy (Noy)" 
>
Reply-To: 
"openstack-dev@lists.openstack.org" 
>
Date: Sunday, 8 November 2015 14:03
To: 
"openstack-dev@lists.openstack.org" 
>
Subject: [openstack-dev] [ceilometer][vitrage][horizon] ceilometer alarms 
screen in horizon

Hi,
Following our Tokyo meetings and chats around vitrage and ceilometer, we are 
now working on vitrage blueprints for Mitaka.
One of the blueprints is around ‘active alarms’ screen in the horizon dashboard.
Is there any open blueprint for that, or should I open a new one?
Was this discussed in the past?
Thanks,
Noy
__
OpenStack Development Mailing 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] Suggestions for handling new panels and refactors in the future

2015-10-10 Thread Rob Cresswell (rcresswe)

Personally, I¹d still vote for feature branching: I¹d really love to see
an Angular Panels feature branch worked on separately and then merged back
in; effectively, Travis¹ 2nd option. Pick 3(?) panels, like Users, Images,
and the System Information one I¹ve seen around, iterate quickly, merge in
M-1/M-2. There¹s not really any risk there, and it¹s very easy for people
to toggle on or off in their existing workflows. Also, there isn¹t any
spin up time in terms of setting up new repos and adding new core groups
through infra etc. The ideal time to do this would be at the start of the
cycle, too.

New repos sounds like too big a split, and I¹m worried about where that
leaves the community as a whole. Also, I¹m failing to see how mixing the
angular work in with plugin challenges is going to speed to it upŠ sounds
like a bit of a recipe for disaster, IMO. We should keep those concerns
separate for now; there are multiple plugins being written in both
AngularJS and Python already, so I think issues will arise organically as
is.

Rob



On 09/10/2015 21:35, "Tripp, Travis S"  wrote:

>Hi Doug!
>
>I think the is a great discussion topic and you summarize your points
>very nicely!
>
> I wish you¹d responded to this thread, though:
>https://openstack.nimeyo.com/58582/openstack-dev-horizon-patterns-for-angu
>lar-panels, because it is talking about the same problem. This is option
>3 I mentioned there and I do think this is still a viable option to
>consider, but we should discuss all the options.
>
>Please consider that thread as my initial response to your emailŠ and
>let¹s keep discussing!
>
>Thanks,
>Travis
>
>From: Douglas Fish
>Reply-To: OpenStack List
>Date: Friday, October 9, 2015 at 8:42 AM
>To: OpenStack List
>Subject: [openstack-dev] [Horizon] Suggestions for handling new panels
>and refactors in the future
>
>I have two suggestions for handling both new panels and refactoring
>existing panels that I think could benefit us in the future:
>1) When we are creating a panel that's a major refactor of an existing it
>should be a new separate panel, not a direct code replacement of the
>existing panel
>2) New panels (include the refactors of existing panels) should be
>developed in an out of tree gerrit repository.
>
>Why make refactors a separate panel?
>
>I was taken a bit off guard after we merged the Network
>Topology->Curvature improvement: this was a surprise to some people
>outside of the Horizon community (though it had been discussed within
>Horizon for as long as I've been on the project). In retrospect, I think
>it would have been better to keep both the old Network Topology and new
>curvature based topology in our Horizon codebase. Doing so would have
>allowed operators to perform A-B/ Red-Black testing if they weren't
>immediately convinced of the awesomeness of the panel. It also would have
>allowed anyone with a customization of the Network Topology panel to have
>some time to configure their Horizon instance to continue to use the
>Legacy panel while they updated their customization to work with the new
>panel.
>
>Perhaps we should treat panels more like an API element and take them
>through a deprecation cycle before removing them completely. Giving time
>for customizers to update their code is going to be especially important
>as we build angular replacements for python panels. While we have much
>better plugin support for angular there is still a learning curve for
>those developers.
>
>Why build refactors and new panels out of tree?
>
>First off, it appears to me trying to build new panels in tree has been
>fairly painful. I've seen big long lived patches pushed along without
>being merged. It's quite acceptable and expected to quickly merge
>half-complete patches into a brand new repository - but you can't behave
>that way working in tree in Horizon. Horizon needs to be kept
>production/operator ready. External repositories do not. Merging code
>quickly can ease collaboration and avoid this kind of long lived patch
>set.
>
>Secondly, keeping new panels/plugins in a separate repository
>decentralizes decisions about which panels are "ready" and which aren't.
>If one group feels a plugin is "ready" they can make it their default
>version of the panel, and perhaps put resources toward translating it. If
>we develop these panels in-tree we need to make a common decision about
>what "ready" means - and once it's in everyone who wants a translated
>Horizon will need to translate it.
>
>Finally, I believe developing new panels out of tree will help improve
>our plugin support in Horizon. It's this whole "eating your own dog food"
>idea. As soon as we start using our own Horizon plugin mechanism for our
>own development we are going to become aware of it's shortcomings (like
>quotas) and will be sufficiently motivated to fix them.
>
>Looking forward to further discussion and other ideas on this!
>
>Doug Fish
>

[openstack-dev] [horizon] Weekly Bug Report

2015-10-08 Thread Rob Cresswell (rcresswe)

Morning Horizoneers,

https://wiki.openstack.org/wiki/Horizon/WeeklyBugReport


Weekly bug report has been updated! Most of the bugs were solved
(woohoo!), or are stuck at discussion point and have been removed until
better solutions are found. I¹ve added new priority bugs, and there are
still some blueprints to look over.

As usual, if you feel there is something critical please add it (or shout
at me to do my job better).

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] Selenium is now green - please pay attention to it

2015-10-01 Thread Rob Cresswell (rcresswe)

Also, please rebase patches to make sure they are passing selenium and
integration, even if they have been previously verified.
Yes, it¹s a little frustrating, but selenium is still non-voting so it
will not block merges.

Rob


On 01/10/2015 19:34, "Doug Fish"  wrote:

>Thanks for your work on this Richard!
>
>A good place to check this is during code reviews. If you see a patch
>causing these tests to fail, that's a good reason to -1!
>
>Sent from my iPhone
>
>> On Sep 30, 2015, at 10:45 PM, Richard Jones 
>>wrote:
>> 
>> Hi folks,
>> 
>> Selenium tests "gate-horizon-selenium-headless" are now green in master
>>again.
>> 
>> Please pay attention if it goes red. I will probably notice, but if I
>>don't, and you can't figure out what's going on, please feel free to get
>>in touch with me (r1chardj0n3s on IRC in #openstack-horizon, or email).
>>Let's try to keep it green!
>> 
>> 
>> 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] Horizon Productivity Suggestion

2015-09-29 Thread Rob Cresswell (rcresswe)

I wasn’t really envisioning a big discussion on the bugs; more like a brief 
notice period to let reviewers know high-priority items. Could definitely spend 
longer over it if that is preferred. Timing aside, the overall idea sounds good 
though?

Lin: That’s a good idea. A wiki page would probably suffice.

Rob

From: Lin Hua Cheng <os.lch...@gmail.com<mailto:os.lch...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, 29 September 2015 04:11
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] Horizon Productivity Suggestion

I agree with Travis that 2-3 minutes is not enough, that may not be even enough 
to talk about one bug. :)

We could save some time if we have someone monitoring the bugs/feature and 
publish the high priority item into a report - something similar to what 
Keystone does [1].  Reviewers can look this up every time if they need to 
prioritize their reviews.

We can rotate this responsibility among cores every month - even non-core if 
someone wants to volunteer.

-Lin

[1] 
https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting#Keystone_Weekly_Bug_Reports

On Mon, Sep 28, 2015 at 7:22 PM, Tripp, Travis S 
<travis.tr...@hpe.com<mailto:travis.tr...@hpe.com>> wrote:
Things always move more quickly at the end of a cycle because people feel 
release pressure, but I do think this is a good idea. 2 - 3 minutes isn’t very 
realistic. It would need to be planned for longer.

On 9/28/15, 3:57 AM, "Rob Cresswell (rcresswe)" 
<rcres...@cisco.com<mailto:rcres...@cisco.com>> wrote:

>Hi folks,
>
>I¹m wondering if we could try marking out a small 2-3 minute slot at the
>start of each weekly meeting to highlight Critical/ High bugs that have
>code up for review, as well as important blueprints that have code up for
>review. These would be blueprints for features that were identified as
>high priority at the summit.
>
>The thought here is that we were very efficient in L-RC1 at moving code
>along, which is nice for productivity, but not really great for stability;
>it would be good to do this kind of targeted work earlier in the cycle.
>I¹ve noticed other projects doing this in their meetings, and it seems
>quite effective.
>
>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] Horizon Productivity Suggestion

2015-09-28 Thread Rob Cresswell (rcresswe)

Hi folks,

I¹m wondering if we could try marking out a small 2-3 minute slot at the
start of each weekly meeting to highlight Critical/ High bugs that have
code up for review, as well as important blueprints that have code up for
review. These would be blueprints for features that were identified as
high priority at the summit.

The thought here is that we were very efficient in L-RC1 at moving code
along, which is nice for productivity, but not really great for stability;
it would be good to do this kind of targeted work earlier in the cycle.
I¹ve noticed other projects doing this in their meetings, and it seems
quite effective.

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] URL Sanity

2015-09-02 Thread Rob Cresswell (rcresswe)

Yeah, the “legacy” thought is what’s making me second guess the effort. We’re 
still in limbo with the language focus, IMO.

Are we nearing a change in routing? I remember work being demo’d at the last 
summit, but I haven’t seen any of it since.

From: Richard Jones <r1chardj0...@gmail.com<mailto:r1chardj0...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, 2 September 2015 00:32
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] URL Sanity

Interesting idea, and in general I'm for consistency. I can't speak directly to 
the network/port question, though it seems to me that if ports must be attached 
to networks then it makes sense for the URL to reflect that.

On the other hand, some could argue that the django URL routing is ... legacy 
... and shouldn't me messed with :)

On the gripping hand, thinking about this could inform future angular routing 
planning...

On 2 September 2015 at 00:39, Rob Cresswell (rcresswe) 
<rcres...@cisco.com<mailto:rcres...@cisco.com>> wrote:
Hi all,

I recently started looking into properly implementing breadcrumbs to make 
navigation clearer, especially around nested resources (Subnets Detail page, 
for example). The idea is to use the request.path to form a logical breadcrumb 
that isn’t dependent on browser history ( 
https://review.openstack.org/#/c/129985/3/horizon/browsers/breadcrumb.py ). 
Unfortunately, this breaks down quite quickly because we use odd patterns like 
`//detail`, and `/` doesn’t 
exist.

This made me realise how much of an inconsistent mess the URL patterns are.  
I’ve started cleaning them up, so we move from these patterns:

`/admin/networks//detail` - Detail page for a Network
`/admin/networks//addsubnet` - Create page for a Subnet

To patterns in line with usual CRUD usages, such as:

`/admin/networks/` - Detail page for a Network
`/admin/networks//subnets/create` - Create page for a Subnet

This is mostly trivial, just removing extraneous words and adding consistency, 
with end goal being every panel following patterns like:

`/` - Index page
`//` - Detail page for a single resource
`//create` - Create new resource
`///update` - Update a resource

This gets a little complex around nested items. Should a Port for example, 
which has a unique ID, be reachable in Horizon by just its ID? Ports must 
always be attached to a network as I understand it. There are multiple ways to 
express this:

`/networks/ports/` - Current implementation
`/networks//ports/` - My preferred structure
`/ports/` - Another option

Does anyone have any opinions on how to handle this structuring, or if it’s 
even necessary?

Regards,
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] URL Sanity

2015-09-01 Thread Rob Cresswell (rcresswe)

Hi all,

I recently started looking into properly implementing breadcrumbs to make 
navigation clearer, especially around nested resources (Subnets Detail page, 
for example). The idea is to use the request.path to form a logical breadcrumb 
that isn’t dependent on browser history ( 
https://review.openstack.org/#/c/129985/3/horizon/browsers/breadcrumb.py ). 
Unfortunately, this breaks down quite quickly because we use odd patterns like 
`//detail`, and `/` doesn’t 
exist.

This made me realise how much of an inconsistent mess the URL patterns are.  
I’ve started cleaning them up, so we move from these patterns:

`/admin/networks//detail` - Detail page for a Network
`/admin/networks//addsubnet` - Create page for a Subnet

To patterns in line with usual CRUD usages, such as:

`/admin/networks/` - Detail page for a Network
`/admin/networks//subnets/create` - Create page for a Subnet

This is mostly trivial, just removing extraneous words and adding consistency, 
with end goal being every panel following patterns like:

`/` - Index page
`//` - Detail page for a single resource
`//create` - Create new resource
`///update` - Update a resource

This gets a little complex around nested items. Should a Port for example, 
which has a unique ID, be reachable in Horizon by just its ID? Ports must 
always be attached to a network as I understand it. There are multiple ways to 
express this:

`/networks/ports/` - Current implementation
`/networks//ports/` - My preferred structure
`/ports/` - Another option

Does anyone have any opinions on how to handle this structuring, or if it’s 
even necessary?

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

Re: [openstack-dev] [horizon] Minimum Unit Test Coverage

2015-07-23 Thread Rob Cresswell (rcresswe)

I was referring to the HTML reports that the karma-coverage plugin creates for 
now. From my experience with it, it’s fairly relaxed about what counts as 
something being tested, hence the 100% aim. For example, often just checking 
that a value is defined is enough for it to be “tested”, and this is where 
reviewers would have to use their own knowledge to ensure decent tests.

More than happy to discuss tooling though.

Rob

From: Michael Krotscheck krotsch...@gmail.commailto:krotsch...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, 23 July 2015 18:11
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [horizon] Minimum Unit Test Coverage

+1 on coverage of any kind.

From a tooling perspective, are you thinking istanbul?

From an infra perspective, are you thinking a separate job, or to have it 
integrated in with npm run test? FYI- istanbul wraps the unit test invocation, 
e.g. 'istanbul karma start ./karma.config.js' or something similar.

100% code coverage is ambitious. Let's get the tool selected and working first.

Michael

On Wed, Jul 22, 2015 at 11:57 AM Rajat Vig 
raj...@thoughtworks.commailto:raj...@thoughtworks.com wrote:
Hi Rob

I agree. Enforcing a minimum level of coverage as a start is awesome.

I must add though keeping it at 100% and breaking the build has almost never 
worked in practice for me.
Keeping a slightly lower level ~98% is slightly more pragmatic.
Also, the currently low coverages will have to be addressed as well.
Is there a blueprint that can be created to tackle it?

-Rajat


On Wed, Jul 22, 2015 at 6:33 AM, Rob Cresswell (rcresswe) 
rcres...@cisco.commailto:rcres...@cisco.com wrote:
Hi all,

As far as I’m aware, we don’t currently enforce any minimum unit test coverage, 
despite Karma generating reports. I think as part of the review guidelines, it 
would be useful to set a minimum. Since Karma’s detection is fairly relaxed, 
I’d put it at 100% on the automated reports.

I think the biggest drawback is that the tests may not be “valuable”, but 
rather just meet the minimum requirements. I understand this sentiment, but I 
think that “less valuable” is better then “not present” and it gives reviewers 
a clear line to +1/ -1 a patch. Furthermore, it encourages the unit tests to be 
written in the first place, so that reviewers can then ask for improvements, 
rather than miss them.

Rob

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


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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] Minimum Unit Test Coverage

2015-07-22 Thread Rob Cresswell (rcresswe)

Hi all,

As far as I’m aware, we don’t currently enforce any minimum unit test coverage, 
despite Karma generating reports. I think as part of the review guidelines, it 
would be useful to set a minimum. Since Karma’s detection is fairly relaxed, 
I’d put it at 100% on the automated reports.

I think the biggest drawback is that the tests may not be “valuable”, but 
rather just meet the minimum requirements. I understand this sentiment, but I 
think that “less valuable” is better then “not present” and it gives reviewers 
a clear line to +1/ -1 a patch. Furthermore, it encourages the unit tests to be 
written in the first place, so that reviewers can then ask for improvements, 
rather than miss them.

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] [docs] AngularJS in Horizon Docs

2015-06-26 Thread Rob Cresswell (rcresswe)

Hi all,

Had another pass of the AngularJS documentation: 
https://review.openstack.org/#/c/182243/
My hope here is to merge soon, noting those sections that may change, and 
update as they do change. This may potentially mean short periods of inaccuracy 
between the docs and reality, but otherwise we’ll spend all cycle with no 
information written down, which I feel is a worse situation.

Horizon folks: As always, could use input from those familiar with the Angular 
work to tell me what is wrong, but also those unfamiliar, to point out what 
would be useful to know, and whether the current format is valuable.

Docs folks: Would absolutely love to get some input on the docs validity 
relating to the docs rules, as well as general pointers on format, language, 
styling etc.

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] [javascript] [horizon] [merlin] [refstack] Javascript Linting

2015-06-16 Thread Rob Cresswell (rcresswe)

So my view here is that I don’t particularly mind which plugin/ set of plugins 
Horizon uses, but the biggest deterrent is the workload. We’re already cleaning 
everything up quite productively, so I’m reluctant to swap. That said, the 
cleanup from JSCS/ JSHint should be largely relevant to ESLint. Michael, do you 
have any ideas on the numbers/ workload behind a possible swap?

With regards to licensing, does this mean we must stop using JSHint, or that 
we’re still okay to use it as a dev tool? Seems that if the former is the case, 
then the decision is made for us.

Rob



From: Michael Krotscheck krotsch...@gmail.commailto:krotsch...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, 16 June 2015 00:36
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [javascript] [horizon] [merlin] [refstack] Javascript 
Linting

I'm restarting this thread with a different subject line to get a broader 
audience. Here's the original thread:
http://lists.openstack.org/pipermail/openstack-dev/2015-June/066040.html

The question at hand is What will be OpenStack's javascript equivalent of 
flake8. I'm going to consider the need for common formatting rules to be 
self-evident. Here's the lay of the land so far:

  *   Horizon currently uses JSCS.
  *   Refstack uses Eslint.
  *   Merlin doesn't use anything.
  *   StoryBoard (deprecated) uses eslint.
  *   Nobody agrees on rules.

JSCS
JSCS Stands for JavaScript CodeStyle. Its mission is to enforce a style 
guide, yet it does not check for potential bugs, variable overrides, etc. For 
those tests, the team usually defers to (preferred) JSHint, or ESLint.

JSHint
Ever since JSCS was extracted from JSHint, it has actively removed rules that 
enforce code style, and focused on findbug style tests instead. JSHint still 
contains the Do no evil license, therefore is not an option for OpenStack, 
and has been disqualified.

ESLint
ESLint's original mission was to be an OSI compliant replacement for JSHint, 
before the JSCS split. It wants to be a one-tool solution.

My personal opinion/recommendation: Based on the above, I recommend we use 
ESLint. My reasoning: It's one tool, it's extensible, it does both codestyle 
things and bug finding things, and it has a good license. JSHint is 
disqualified because of the license. JSCS is disqualified because it is too 
focused, and only partially useful on its own.

I understand that this will mean some work by the Horizon team to bring their 
code in line with a new parser, however I personally consider this to be a good 
thing. If the code is good to begin with, it shouldn't be that difficult.

This thread is not there to argue about which rules to enforce. Right now I 
just want to nail down a tool, so that we can (afterwards) have a discussion 
about which rules to activate.

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

2015-05-29 Thread Rob Cresswell (rcresswe)

This was a known bug with the modals, which was fixed yesterday. Update horizon 
master, and you’re good to go :)

Bug: https://bugs.launchpad.net/horizon/+bug/1459115
Patch: https://review.openstack.org/#/c/185927/

Rob


From: lu jander juvenboy1...@gmail.commailto:juvenboy1...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Friday, 29 May 2015 03:14
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Horizon][sahara]

Hi, guys.

I installed latest devstack many times, but it seems there are many issue with 
that,  one snapshot pic below for example, have you ever met recently?

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

Re: [openstack-dev] [Horizon] dashboard-app split in horizon

2015-05-27 Thread Rob Cresswell (rcresswe)

Went through the files myself and I concur. Most of these files define pieces 
specific to our implementation of the dashboard, so should be moved.

I’m not entirely sure on where _messages should sit. As we move forward, won’t 
that file just end up as a toast element and nothing more? Maybe I’m 
misinterpreting it, I’m not familiar with toastService.

Rob


From: Richard Jones r1chardj0...@gmail.commailto:r1chardj0...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, 26 May 2015 01:35
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Cc: Johanson, Tyr H t...@hp.commailto:t...@hp.com
Subject: Re: [openstack-dev] [Horizon] dashboard-app split in horizon

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

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

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

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

Thoughts, anyone who has read this far?


Richard


On Sat, 23 May 2015 at 11:46 Richard Jones 
r1chardj0...@gmail.commailto:r1chardj0...@gmail.com wrote:
As part of the ongoing Horizon project code reorganisation, we today agreed to 
clean up the Horizon-the-Framework and OpenStack Dashboard separation issue by 
doing a couple of things:

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

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

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

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


 Richard

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

Re: [openstack-dev] [horizon] [ux] Changing how the modals are closed in Horizon

2014-12-04 Thread Rob Cresswell (rcresswe)

While clicking off the modal is relatively easy to do my accident, hitting Esc 
or ‘X’ are fairly distinct actions. I don’t personally think there is any need 
to warn the user in that instance :)

Rob


On 3 Dec 2014, at 22:30, Aaron Sahlin 
asah...@linux.vnet.ibm.commailto:asah...@linux.vnet.ibm.com wrote:

I would be happy with either the two proposed solutions (both improvements over 
the what we have now).
Any thoughts on combining them?   Only close if esc or 'x' is clicked, but also 
warn them if data was entered.



On 12/3/2014 7:21 AM, Rob Cresswell (rcresswe) wrote:
+1 to changing the behaviour to ‘static'. Modal inside a modal is potentially 
slightly more useful, but looks messy and inconsistent, which I think outweighs 
the functionality.

Rob


On 2 Dec 2014, at 12:21, Timur Sufiev 
tsuf...@mirantis.commailto:tsuf...@mirantis.com wrote:

Hello, Horizoneers and UX-ers!

The default behavior of modals in Horizon (defined in turn by Bootstrap 
defaults) regarding their closing is to simply close the modal once user clicks 
somewhere outside of it (on the backdrop element below and around the modal). 
This is not very convenient for the modal forms containing a lot of input - 
when it is closed without a warning all the data the user has already provided 
is lost. Keeping this in mind, I've made a patch [1] changing default Bootstrap 
'modal_backdrop' parameter to 'static', which means that forms are not closed 
once the user clicks on a backdrop, while it's still possible to close them by 
pressing 'Esc' or clicking on the 'X' link at the top right border of the form. 
Also the patch [1] allows to customize this behavior (between 'true'-current 
one/'false' - no backdrop element/'static') on a per-form basis.

What I didn't know at the moment I was uploading my patch is that David Lyle 
had been working on a similar solution [2] some time ago. It's a bit more 
elaborate than mine: if the user has already filled some some inputs in the 
form, then a confirmation dialog is shown, otherwise the form is silently 
dismissed as it happens now.

The whole point of writing about this in the ML is to gather opinions which 
approach is better:
* stick to the current behavior;
* change the default behavior to 'static';
* use the David's solution with confirmation dialog (once it'll be rebased to 
the current codebase).

What do you think?

[1] https://review.openstack.org/#/c/113206/
[2] https://review.openstack.org/#/c/23037/

P.S. I remember that I promised to write this email a week ago, but better late 
than never :).

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




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


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

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

Re: [openstack-dev] [horizon] [ux] Changing how the modals are closed in Horizon

2014-12-03 Thread Rob Cresswell (rcresswe)

+1 to changing the behaviour to ‘static'. Modal inside a modal is potentially 
slightly more useful, but looks messy and inconsistent, which I think outweighs 
the functionality.

Rob


On 2 Dec 2014, at 12:21, Timur Sufiev 
tsuf...@mirantis.commailto:tsuf...@mirantis.com wrote:

Hello, Horizoneers and UX-ers!

The default behavior of modals in Horizon (defined in turn by Bootstrap 
defaults) regarding their closing is to simply close the modal once user clicks 
somewhere outside of it (on the backdrop element below and around the modal). 
This is not very convenient for the modal forms containing a lot of input - 
when it is closed without a warning all the data the user has already provided 
is lost. Keeping this in mind, I've made a patch [1] changing default Bootstrap 
'modal_backdrop' parameter to 'static', which means that forms are not closed 
once the user clicks on a backdrop, while it's still possible to close them by 
pressing 'Esc' or clicking on the 'X' link at the top right border of the form. 
Also the patch [1] allows to customize this behavior (between 'true'-current 
one/'false' - no backdrop element/'static') on a per-form basis.

What I didn't know at the moment I was uploading my patch is that David Lyle 
had been working on a similar solution [2] some time ago. It's a bit more 
elaborate than mine: if the user has already filled some some inputs in the 
form, then a confirmation dialog is shown, otherwise the form is silently 
dismissed as it happens now.

The whole point of writing about this in the ML is to gather opinions which 
approach is better:
* stick to the current behavior;
* change the default behavior to 'static';
* use the David's solution with confirmation dialog (once it'll be rebased to 
the current codebase).

What do you think?

[1] https://review.openstack.org/#/c/113206/
[2] https://review.openstack.org/#/c/23037/

P.S. I remember that I promised to write this email a week ago, but better late 
than never :).

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

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

56 matches

Mail list logo