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

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

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

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

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

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

[openstack-dev] [horizon][trunk] forever spinning modalspinner when deleting resource from details page

Hi, I am working on the neutron-trunk-ui, to make the possibility for the user to use trunks via web GUI. For the patch which shows the details for the trunk (https://review.openstack.org/464727) I realized that the Delete action actually seems to be hanging if I delete from the detail page.

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

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:

Re: [openstack-dev] [horizon] Extensible Header Blueprint

:53 AM To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org> Subject: [openstack-dev] [horizon] Extensible Header Blueprint I have registered a new blueprint to address the extensible header functionality discussed below. https://blueprints.launchpad.net/horizon/+

Re: [openstack-dev] [horizon] Approach for bugs in xstatic packages

I can see several possible ways forward with this: * provide a complete fix for the issue that would be more likely to get merged upstream, * instead of adding hacks in the code, actually rename the wrongly named files, * instead of adding hacks, actually fix all the references to use proper

[openstack-dev]  [horizon] Approach for bugs in xstatic packages

Hi everyone, I would like to raise a question about our approach to xstatic packages, more specifically xstatic-roboto-fontface, and its updates/bugfixes. What we have encountered was https://bugs.launchpad.net/horizon/+bug/1671004 what

[openstack-dev] [horizon] Extensible Header Blueprint

uot; <openstack-dev@lists.openstack.org> Date: Thursday, June 1, 2017 at 12:50 PM To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [horizon] Blueprint process question There have been a couple of projects that would like

Re: [openstack-dev] [horizon] seeing another users panel in Mitaka ?

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

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

Re: [openstack-dev] [horizon] Blueprint process question

ack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [horizon] Blueprint process question There have been a couple of projects that would like some space in the page header. I think the work in Horizon is to provide an extensible space in the p

Re: [openstack-dev] [horizon] Blueprint process question

Reply-To: "openstack-dev@lists.openstack.org" > <openstack-dev@lists.openstack.org> > Date: Thursday, May 18, 2017 at 11:40 AM > To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [horizon] Blueprint proces

Re: [openstack-dev] [horizon] Blueprint process question

Date: Thursday, May 18, 2017 at 11:40 AM To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [horizon] Blueprint process question There isn't a specific time for blueprint review at the moment. It's usually whenever I get time, or

Re: [openstack-dev] [horizon][api][docs] Feedback requested on proposed formatting change to API docs

On Fri, May 19, 2017 at 8:00 AM, Sean Dague wrote: > On 05/19/2017 08:36 AM, Monty Taylor wrote: > > On 05/17/2017 10:14 AM, Joe Topjian wrote: > >> > >> > >> On Tue, May 16, 2017 at 4:13 PM, Monty Taylor >> > wrote: > >> > >>

Re: [openstack-dev] [horizon][api][docs] Feedback requested on proposed formatting change to API docs

On 05/19/2017 08:36 AM, Monty Taylor wrote: > On 05/17/2017 10:14 AM, Joe Topjian wrote: >> >> >> On Tue, May 16, 2017 at 4:13 PM, Monty Taylor > > wrote: >> >> Hey all! >> >> I read the API docs A LOT. (thank you to all of you who have

Re: [openstack-dev] [horizon][api][docs] Feedback requested on proposed formatting change to API docs

On 05/17/2017 10:14 AM, Joe Topjian wrote: On Tue, May 16, 2017 at 4:13 PM, Monty Taylor > wrote: Hey all! I read the API docs A LOT. (thank you to all of you who have worked on writing them) As I do, a gotcha I hit up

Re: [openstack-dev] [horizon] Blueprint process question

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

[openstack-dev] [horizon] Blueprint process question

A blueprint question for horizon team. I registered a new blueprint the other day. https://blueprints.launchpad.net/horizon/+spec/vitrage-alarm-counts-in-topnavbar Do I need to do anything else to get this reviewed? I don’t think so, but wanted to double check. How frequently do horizon

Re: [openstack-dev] [horizon][api][docs] Feedback requested on proposed formatting change to API docs

On Tue, May 16, 2017 at 4:13 PM, Monty Taylor wrote: > Hey all! > > I read the API docs A LOT. (thank you to all of you who have worked on > writing them) > > As I do, a gotcha I hit up against a non-zero amount is mapping the > descriptions of the response parameters to

Re: [openstack-dev] [horizon][api][docs] Feedback requested on proposed formatting change to API docs

On 05/17/2017 07:40 AM, Chris Dent wrote: > On Tue, 16 May 2017, Monty Taylor wrote: > >> The questions: >> >> - Does this help, hurt, no difference? >> - servers[].name - servers is a list, containing objects with a name >> field. Good or bad? >> - servers[].addresses.$network-name - addresses

Re: [openstack-dev] [horizon][api][docs] Feedback requested on proposed formatting change to API docs

On Tue, 16 May 2017, Monty Taylor wrote: The questions: - Does this help, hurt, no difference? - servers[].name - servers is a list, containing objects with a name field. Good or bad? - servers[].addresses.$network-name - addresses is an object and the keys of the object are the name of the

Re: [openstack-dev] [horizon][api][docs] Feedback requested on proposed formatting change to API docs

On Tue, May 16, 2017 at 05:13:16PM -0500, Monty Taylor wrote: > Hey all! > > I read the API docs A LOT. (thank you to all of you who have worked > on writing them) > > As I do, a gotcha I hit up against a non-zero amount is mapping the > descriptions of the response parameters to the form of the

[openstack-dev] [horizon][api][docs] Feedback requested on proposed formatting change to API docs

Hey all! I read the API docs A LOT. (thank you to all of you who have worked on writing them) As I do, a gotcha I hit up against a non-zero amount is mapping the descriptions of the response parameters to the form of the response itself. Most of the time there is a top level parameter under

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

Hi everyone! The next two weekly IRC meetings (3rd May, 10th May) are cancelled. I'm away this week and next week is the summit. Meetings will resume on the 17th! For those going to the summit, please read http://lists.openstack.org/pipermail/openstack-dev/2017-April/115982.html for meetup

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

Welcome Ying Zuo! On Mon, May 1, 2017 at 5:19 AM, Rob Cresswell (rcresswe) wrote: > Hey everyone, > > I’m adding Ying Zuo to the Horizon Core team. She’s been contributing many > great patches to the code base driven by operator experience, as well as > providing solid

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

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-dev] [horizon] OpenStack Summit meetups

Hello! A couple of notices about summit meetups for Horizon folk: - I've reserved about 2 hours on the Monday in Hynes, MR 108 from 2:00 -> 4:20. This may change if demand for the rooms is high, so keep an eye on https://ethercalc.openstack.org/Boston_Forum_Hacking_Rooms. I'll send a reminder

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

Hey everyone, So we've just tagged our first milestone for Pike. I've checked launchpad and bumped anything unfinished to pike-2. You can see our progress for pike-1 at https://launchpad.net/horizon/+milestone/pike-1 5 blueprints implemented and 73 bugs closed, as well as many minor bugs that

Re: [openstack-dev] [horizon] Unknown provider resource-type-registry.service test error

Hi! Just as a follow up to my email yesterday, tests are now passing. Many thanks Rob for helping me out with this on IRC! If anyone else comes across this error message developing panels in horizon, my solution was that I wasn’t making the correct modules available with just

Re: [openstack-dev] [horizon][nova][tc] nova-network deprecation in horizon

On 4/10/2017 11:14 AM, Monty Taylor wrote: On 04/10/2017 10:37 AM, Monty Taylor wrote: On 04/10/2017 09:19 AM, Dean Troyer wrote: On Mon, Apr 10, 2017 at 8:58 AM, Akihiro Motoki wrote: (question not directly related to this topic) I am not sure there is a case where users

Re: [openstack-dev] [horizon][nova][tc] nova-network deprecation in horizon

On 4/10/2017 1:51 PM, Dean Troyer wrote: On Mon, Apr 10, 2017 at 10:19 AM, Matt Riedemann wrote: How long are we expected to be carrying this deprecated bridge code? If you need these CLIs/API bindings in the client, then don't upgrade to 8.0.0, or run different versions

Re: [openstack-dev] [horizon][nova][tc] nova-network deprecation in horizon

On Mon, Apr 10, 2017 at 10:19 AM, Matt Riedemann wrote: > How long are we expected to be carrying this deprecated bridge code? If you > need these CLIs/API bindings in the client, then don't upgrade to 8.0.0, or > run different versions of novaclient in venvs or containers if

[openstack-dev] [horizon] Unknown provider resource-type-registry.service test error

Hi all, Thanks very much in advance for any help you are able to offer. I have been working on developing the QoS Policies panel for horizon and have the panel working, however I am struggling with the qos.service.spec.js file. In advance of going into my findings and issues so far, the

Re: [openstack-dev] [horizon][nova][tc] nova-network deprecation in horizon

On 04/10/2017 10:23 AM, Akihiro Motoki wrote: 2017-04-10 23:19 GMT+09:00 Dean Troyer : On Mon, Apr 10, 2017 at 8:58 AM, Akihiro Motoki wrote: (question not directly related to this topic) I am not sure there is a case where users still use API 2.36 for

Re: [openstack-dev] [horizon][nova][tc] nova-network deprecation in horizon

On 04/10/2017 10:24 AM, Sean Dague wrote: On 04/10/2017 11:19 AM, Matt Riedemann wrote: On 4/10/2017 9:19 AM, Dean Troyer wrote: On Mon, Apr 10, 2017 at 8:58 AM, Akihiro Motoki wrote: (question not directly related to this topic) I am not sure there is a case where users

Re: [openstack-dev] [horizon][nova][tc] nova-network deprecation in horizon

On 04/10/2017 10:37 AM, Monty Taylor wrote: On 04/10/2017 09:19 AM, Dean Troyer wrote: On Mon, Apr 10, 2017 at 8:58 AM, Akihiro Motoki wrote: (question not directly related to this topic) I am not sure there is a case where users still use API 2.36 for network management

Re: [openstack-dev] [horizon][nova][tc] nova-network deprecation in horizon

On 04/10/2017 09:19 AM, Dean Troyer wrote: On Mon, Apr 10, 2017 at 8:58 AM, Akihiro Motoki wrote: (question not directly related to this topic) I am not sure there is a case where users still use API 2.36 for network management and newer API versions for other compute

Re: [openstack-dev] [horizon][nova][tc] nova-network deprecation in horizon

On 04/10/2017 11:19 AM, Matt Riedemann wrote: > On 4/10/2017 9:19 AM, Dean Troyer wrote: >> On Mon, Apr 10, 2017 at 8:58 AM, Akihiro Motoki >> wrote: >>> (question not directly related to this topic) >>> I am not sure there is a case where users still use API 2.36 for >>>

Re: [openstack-dev] [horizon][nova][tc] nova-network deprecation in horizon

2017-04-10 23:19 GMT+09:00 Dean Troyer : > On Mon, Apr 10, 2017 at 8:58 AM, Akihiro Motoki wrote: >> (question not directly related to this topic) >> I am not sure there is a case where users still use API 2.36 for >> network management >> and newer API

Re: [openstack-dev] [horizon][nova][tc] nova-network deprecation in horizon

On 4/10/2017 9:19 AM, Dean Troyer wrote: On Mon, Apr 10, 2017 at 8:58 AM, Akihiro Motoki wrote: (question not directly related to this topic) I am not sure there is a case where users still use API 2.36 for network management and newer API versions for other compute

Re: [openstack-dev] [horizon][nova][tc] nova-network deprecation in horizon

On 4/10/2017 8:58 AM, Akihiro Motoki wrote: Is there any deprecation policy in novaclient python binding? I was not aware of deprecation warnings. If novaclient follows nova deprecation, it sounds reasonable to me. Yes we deprecated the CLIs in this change in Newton:

Re: [openstack-dev] [horizon][nova][tc] nova-network deprecation in horizon

On Mon, Apr 10, 2017 at 8:58 AM, Akihiro Motoki wrote: > (question not directly related to this topic) > I am not sure there is a case where users still use API 2.36 for > network management > and newer API versions for other compute operation. This is probably true for

Re: [openstack-dev] [horizon][nova][tc] nova-network deprecation in horizon

I am okay to drop nova-network feature in Pike. More generally, can we horizon team say the following? A feature deprecated in a back-end project is automatically deprecated in Horizon and a feature in horizon will be dropped if a corresponding support is dropped in a back-end project and/or

Re: [openstack-dev] [horizon][nova][tc] nova-network deprecation in horizon

2017-03-29 5:06 GMT+09:00 Matt Riedemann : > On 3/28/2017 9:04 AM, Akihiro Motoki wrote: >> >> Hi, >> >> I would like to raise a topic when horizon nova-network support can be >> dropped. >> I added [tc] tag as it is related to >> "assert:follows-standard-deprecation" tag in

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

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

Re: [openstack-dev] [horizon][nova][tc] nova-network deprecation in horizon

Frankly, it sounds like we can pretty comfortably drop support for nova-net in Pike. I'm fine with that, from a Horizon point of view. Rob On 28 March 2017 at 21:06, Matt Riedemann > wrote: On 3/28/2017 9:04 AM, Akihiro Motoki wrote: > Hi, > > I

Re: [openstack-dev] [horizon][nova][tc] nova-network deprecation in horizon

On 3/28/2017 9:04 AM, Akihiro Motoki wrote: Hi, I would like to raise a topic when horizon nova-network support can be dropped. I added [tc] tag as it is related to "assert:follows-standard-deprecation" tag in the governance. Can horizon drop nova-network support based on the deprecation of

[openstack-dev] [horizon][nova][tc] nova-network deprecation in horizon

Hi, I would like to raise a topic when horizon nova-network support can be dropped. I added [tc] tag as it is related to "assert:follows-standard-deprecation" tag in the governance. Can horizon drop nova-network support based on the deprecation of nova-network from the nova team? or does horizon

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

I've completed this work. The two patches to migrate the code over and one additional bug fix are: Horizon: Copy os-nova-servers from searchlight ui https://review.openstack.org/#/c/444095/ Searchlight UI: Remove os-nova-servers resource type https://review.openstack.org/#/c/450067/

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

t; mapping from the resource type names that searchlight uses >> (os-nova-servers) >> > to the modules we'll be OK. If you or Rob put a patch up against >> horizon I >> > (or a willing victim/volunteer) can test a searchlight-ui patch >> against

Re: [openstack-dev] [horizon] [keystone] [federated auth] [ocata] federated users with "admin" role not authorized for nova, cinder, neutron admin panels

Hi, Oh wow, for some reason my message was not sent to the list. On 03/20/2017 09:03 PM, Evan Bollig PhD wrote: > Hey Boris, > > Any updates on this? > > Cheers, > -E > -- > Evan F. Bollig, PhD > Scientific Computing Consultant, Application Developer | Scientific > Computing Solutions (SCS) >

Re: [openstack-dev] [horizon] [keystone] [federated auth] [ocata] federated users with "admin" role not authorized for nova, cinder, neutron admin panels

Hi, Oh wow, for some reason my message was not sent to the list. On 03/20/2017 09:03 PM, Evan Bollig PhD wrote: > Hey Boris, > > Any updates on this? > > Cheers, > -E > -- > Evan F. Bollig, PhD > Scientific Computing Consultant, Application Developer | Scientific > Computing Solutions (SCS) >

Re: [openstack-dev] [horizon] [keystone] [federated auth] [ocata] federated users with "admin" role not authorized for nova, cinder, neutron admin panels

Hey Boris, Any updates on this? Cheers, -E -- Evan F. Bollig, PhD Scientific Computing Consultant, Application Developer | Scientific Computing Solutions (SCS) Minnesota Supercomputing Institute | msi.umn.edu University of Minnesota | umn.edu boll0...@umn.edu | 612-624-1447 | Walter Lib Rm 556

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

Hey everyone, I'm away for a week, so there'll be no Horizon meeting on the 22nd. Rob __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

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

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

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

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

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

rdj0...@gmail.com> > > Date: 3/9/17 21:13 (GMT-06:00) > > To: "OpenStack Development Mailing List (not for usage questions)" > > <openstack-dev@lists.openstack.org> > > Subject: Re: [openstack-dev] [Horizon][searchlight] Sharing resource

[openstack-dev] [horizon] Weekly meeting

Hey everyone, Reminder that the weekly IRC meeting is 2000 UTC on Wednesday in #openstack-meeting-3. Anyone is welcome to add to the agenda at https://wiki.openstack.org/wiki/Meetings/Horizon Previous logs, ICS files, and other info can be found at

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

iginal message > From: Richard Jones <r1chardj0...@gmail.com> > Date: 3/9/17 21:13 (GMT-06:00) > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [H

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

GMT-06:00) > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [Horizon][searchlight] Sharing resource type > implementations > > Hey folks, > > Another potential

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

against it. Original message From: Richard Jones <r1chardj0...@gmail.com> Date: 3/9/17 21:13 (GMT-06:00) To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [Horizon][searchlight]

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

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

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

OK, I will work on a plan that migrates the code into Horizon, thanks everyone! Travis, can the searchlight details page stuff be done through extending the base resource type in Horizon? If not, is that perhaps a limitation of the extensible service? Richard On 10 March 2017 at 02:20,

Re: [openstack-dev] [horizon] [keystone] [federated auth] [ocata] federated users with "admin" role not authorized for nova, cinder, neutron admin panels

Hey Boris, Which mapping? Hope you were looking for the shibboleth user mapping. Also, hope this is the right way to share the paste (first time using this): http://paste.openstack.org/show/3snCb31GRZfAuQxdRouy/ Cheers, -E -- Evan F. Bollig, PhD Scientific Computing Consultant, Application

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

I concur; option 4 is the only one makes sense to me and was what was intended originally. As long as we can do it in one fell swoop in one cyclle (preferably sooner than later) there should be no issues. On 3/9/17, 8:35 AM, "Tripp, Travis S" wrote: >Let me get Matt B

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

Let me get Matt B in on this discussion, but basically, option 4 is my initial feeling as Rob stated. One downside we saw with this approach is that we weren’t going to be able to take advantage of searchlight capabilities in details pages if everything was in native horizon. Although, I

Re: [openstack-dev] [horizon] [keystone] [federated auth] [ocata] federated users with "admin" role not authorized for nova, cinder, neutron admin panels

Hi, Please paste your mapping to paste.openstack.org On 03/09/2017 02:07 AM, Evan Bollig PhD wrote: > I am on Ocata with Shibboleth auth enabled. I noticed that Federated > users with the admin role no longer have authorization to use the > Admin** panels in Horizon related to Nova, Cinder and

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

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

[openstack-dev] [horizon] [keystone] [federated auth] [ocata] federated users with "admin" role not authorized for nova, cinder, neutron admin panels

I am on Ocata with Shibboleth auth enabled. I noticed that Federated users with the admin role no longer have authorization to use the Admin** panels in Horizon related to Nova, Cinder and Neutron. All regular Identity and Project tabs function, and there are no problems with authorization for

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

Hey everyone, Reminder that the weekly IRC meeting is 2000 UTC on Wednesday (about 10.5 hours from sending this email) in #openstack-meeting-3. Anyone is welcome to add to the agenda at https://wiki.openstack.org/wiki/Meetings/Horizon Previous logs, ICS files, and other info can be found at

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

Hey folks, Great work since the PTG. In Pike so far we've already closed over 30 bugs (28 tracked, with a few minor untracked fixes) and backported several fixes to our stable releases, which we'll tag this week. Several blueprints are well on the way too, but really need reviews. Please check

Re: [openstack-dev] [Horizon][stable][requirements] Modifying global-requirements to cap xstatic package versions

On 03/02/2017 12:57 PM, Doug Hellmann wrote: > Right, friends don't let friends cap dependencies. > > Let's work on getting constraints rolled out where needed instead. This is the basic response I have to this. More specifically it can cause more churn in consuming projects, even if it's done

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

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

Re: [openstack-dev] [Horizon][stable][requirements] Modifying global-requirements to cap xstatic package versions

Excerpts from Clark Boylan's message of 2017-03-02 10:40:39 -0800: > On Wed, Mar 1, 2017, at 07:10 PM, Richard Jones wrote: > > Hi folks, > > > > We've run into some issues with various folks installing Horizon and > > its dependencies using just requirements.txt which doesn't limit the > >

Re: [openstack-dev] [Horizon][stable][requirements] Modifying global-requirements to cap xstatic package versions

On Wed, Mar 1, 2017, at 07:10 PM, Richard Jones wrote: > Hi folks, > > We've run into some issues with various folks installing Horizon and > its dependencies using just requirements.txt which doesn't limit the > versions of xstatic packages beyond some minimum version. This is a > particular

[openstack-dev] [Horizon][stable][requirements] Modifying global-requirements to cap xstatic package versions

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

Re: [openstack-dev] [horizon] Single core review for patch approval

Yep I totally agree that adding cores for the sake of adding cores doesn’t make sense. Just trying to fish for ideas to prevent having to go to a single +2 to merge as that does make me nervous. But I guess for the sake of moving code through it needs to be done at the moment. > On 1 Mar

Re: [openstack-dev] [horizon] Single core review for patch approval

Adding inexperienced cores doesn't really alleviate that issue though, and I don't currently feel that there is anyone with the right balance of experience and activity to be added to the core team. Me and Richard monitor review activity very closely though, and we are actively looking to grow

Re: [openstack-dev] [horizon] Single core review for patch approval

Has there been any consideration of growing the core team to help with review bandwidth? I ask only because that resulting responsibility to the community can drive additional review activity. Just worried that only 1x +2 could cause issues with code being merged on a project this large that

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

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

[openstack-dev] [horizon] Single core review for patch approval

Hey everyone, Horizon is moving to requiring only a single core review for code approval. Note that cores are not obliged to approve on a single +2; if a core would like a second opinion for patches that are complex or high risk, that is also fine. We still require at least one of the core

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

> - Use [horizon-plugin] mailer tag to keep people up to date So the idea here is to send an email for changes that are likely to affect plugins; new libs for example, or changes to core components, with the [horizon-plugin] tag. > Was there much discussion around project health, and the lack

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

On 28 February 2017 at 02:28, Rob Cresswell wrote: > Quick summary of the PTG for those who missed it. Here's the etherpad, with > notes inline: https://etherpad.openstack.org/p/horizon-ptg-pike Was there much discussion around project health, and the lack of core

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

; > --- > Kenji Ishii > > > > -Original Message- > > From: Rob Cresswell [mailto:robert.cressw...@outlook.com] > > Sent: Tuesday, February 28, 2017 12:28 AM > > To: OpenStack Dev Mailer <openstack-dev@lists.openstack.org> > > Subject: [openstack

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

obert.cressw...@outlook.com] > Sent: Tuesday, February 28, 2017 12:28 AM > To: OpenStack Dev Mailer <openstack-dev@lists.openstack.org> > Subject: [openstack-dev] [horizon] PTG Summary > > Hi everyone! > > Quick summary of the PTG for those who missed it. Here's t

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

On 28 February 2017 at 02:28, Rob Cresswell wrote: > Quick summary of the PTG for those who missed it. Here's the etherpad, with > notes inline: https://etherpad.openstack.org/p/horizon-ptg-pike Thanks, Rob! > - Use [horizon-plugin] mailer tag to keep people up to

[openstack-dev] [horizon] PTG Summary

Hi everyone! Quick summary of the PTG for those who missed it. Here's the etherpad, with notes inline: https://etherpad.openstack.org/p/horizon-ptg-pike We spent the first morning discussing plugins, with several plugin devs dropping in to discuss their issues. Several issues were mentioned

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

Hi everyone, A reminder to those at the PTG about a couple of cross project sessions. - Wednesday, 2:30 - 3:30, Horizon / Keystone in Savannah 3 - Thursday 3:00 - 4:00, Horizon / I18n in Savannah 3 These are also listed in our PTG etherpad: https://etherpad.openstack.org/p/horizon-ptg-pike

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

Hi everyone, There will be no meetings this week due to the PTG (https://www.openstack.org/ptg/) Rob __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

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

Hi folks, A quiet week this week as folks gear up for Pike and the PTG next week. We did get Ocata RC2 out the door this week with those final few bug fixes and the wonderful translations from the i18n team! Thanks to everyone who helped make Ocata Horizon happen :-) If you're going to the PTG,

[openstack-dev] [horizon] horizon 11.0.0.0rc2 (ocata)

Hello everyone, A new release candidate for horizon for the end of the Ocata cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/horizon/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be

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

Hey everyone, Quick reminder about the Keystone-Horizon meeting at 2000 UTC (about 1h45 from this email being sent). You can see the details and add it to your calendar via http://eavesdrop.openstack.org/#Keystone/Horizon_Collaboration_Meeting I'd like to keep up these meetings for the

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

Hi folks, The Horizon team will be having our next meeting at 20:00 UTC this Wednesday, 15th February in #openstack-meeting-3 Meeting agenda is here: https://wiki.openstack.org/wiki/Meetings/Horizon Anyone is welcome to to add agenda items and everyone interested in Horizon is encouraged to

[openstack-dev] [Horizon] Final project mascot

Hi folks, Here's the final mascot/logo from the Foundation. Richard -- Forwarded message -- From: Heidi Joy Tretheway Date: 14 February 2017 at 08:49 Subject: Horizon project mascot To: Rob Cresswell , Richard Jones <

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

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

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

Hi folks, The Horizon team will be having our next meeting at 20:00 UTC this Wednesday, 8th February in #openstack-meeting-3 Meeting agenda is here: https://wiki.openstack.org/wiki/Meetings/Horizon Anyone is welcome to to add agenda items and everyone interested in Horizon is encouraged to

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

[mailto:amot...@gmail.com] Sent: Monday, February 6, 2017 5:18 AM To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [horizon] [neutron] Horizon support for Neutron Trunks - PTL approval needed I have the same o

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

> If this is inside the Neutron tree, then support should live in the Horizon > repo This sounds like a conclusion. So I have abandoned the requests on gerrit for the new repo. Instead I just uploaded a Horizon blueprint draft for Pike:

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

I have the same opinion as Kevin, UI support for a feature in the neutron repo should be in the main horizon repo. I believe this improves usability too. If I have a neutron deployment (it is a typical deployment now), I would like to use neutron feature support only after installing the main

<    1   2   3   4   5   6   7   8   9   10   >