20:00:38 <ying_zuo> #startmeeting horizon
20:00:39 <openstack> Meeting started Wed Dec 20 20:00:38 2017 UTC and is due to finish in 60 minutes.  The chair is ying_zuo. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:40 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:43 <openstack> The meeting name has been set to 'horizon'
20:00:57 <ying_zuo> Hi everyone o/
20:01:54 <david-lyle> o/
20:01:55 <e0ne> hi
20:02:33 <ying_zuo> #topic Welcome Ivan Kolodyazhny to the core team
20:02:39 <ying_zuo> #link http://lists.openstack.org/pipermail/openstack-dev/2017-December/125647.html
20:02:51 <david-lyle> congrats e0ne
20:02:57 <rdopiera> welcome!
20:03:03 <ying_zuo> lol
20:03:08 <e0ne> thanks everybody!
20:03:23 <ying_zuo> e0ne: thanks for your contribution to Horizon :)
20:03:28 <david-lyle> +1
20:03:56 <ying_zuo> #topic Keystone policy: is_cloud_admin and is_domain are broken with the latest keystone policy (amotoki)
20:04:05 <ying_zuo> #link https://bugs.launchpad.net/horizon/+bug/1739108
20:04:06 <openstack> Launchpad bug 1739108 in OpenStack Dashboard (Horizon) "api.keystone.is_cloud_admin/is_domain_admin do not work with the latest policy from keystone repo" [Critical,New]
20:05:20 <ying_zuo> some of you have discussed about this
20:05:40 <ying_zuo> the discussion seems to be for a more general case
20:05:57 <ying_zuo> I think for this bug, using the admin_required as default is fine
20:06:02 <david-lyle> for this particular one, I think maintaining the default rule is correct
20:06:12 <david-lyle> yup
20:07:09 <ying_zuo> is there a volunteer to pick this up?
20:07:25 <david-lyle> not really sure where the default rule is called
20:07:38 <david-lyle> the way policy works is allows unless the rule says no
20:07:41 <ying_zuo> just "default" I think
20:07:49 <david-lyle> if the rule is not present, it allows
20:08:05 <david-lyle> but there may be something funky about these two specific checks
20:08:11 <david-lyle> they were always wrong
20:08:32 <ying_zuo> I think that's right
20:08:39 <rdopiera> might break some stuff people rely on if we "fix" it?
20:10:19 <ying_zuo> the default is set to admin_required rule before
20:10:34 <david-lyle> looks like is_cloud_admin is only used in the projects views
20:11:01 <david-lyle> and around showing quota information, so that's not it
20:12:41 <david-lyle> I'm not sure this is the root of whatever problem is being seen
20:13:05 <david-lyle> is_domain_admin is also used in the standard way
20:13:07 <ying_zuo> maybe more than these two rules were affected
20:14:32 <ying_zuo> #topic Supported Django versions (amotoki)
20:14:38 <ying_zuo> #link https://blueprints.launchpad.net/horizon/+spec/django2-support
20:15:03 <ying_zuo> pasting what amotoki put on the meeting note below:
20:15:26 <ying_zuo> https://www.irccloud.com/pastebin/CHwGEsMN/
20:16:43 <e0ne> I'm all for supporting at least last LTS and django2.0 as experimental
20:17:44 <ying_zuo> yes for supporting LTS and 2.0
20:17:51 <e0ne> #link currently supported versions https://www.djangoproject.com/download/
20:18:00 <cshen_> me +1
20:18:05 <rdopiera> same here
20:18:24 <ying_zuo> if we can complete this blueprint in Queens, it will give the plugins some time to catch up
20:18:51 <ying_zuo> considering Django 1.8 LTS ends in April 2018
20:18:51 <e0ne> from the operator's perspective, I want to have at lease security fixes for django
20:19:28 <e0ne> so 1.9 and 1.10 are not good for security
20:19:46 <e0ne> I'm afraid, we can't support both 1.8 and 2.0
20:20:01 <ying_zuo> that's right
20:20:15 <ying_zuo> there seems to be some conflicts
20:20:28 <e0ne> ying_zuo: it's not a good option to release Queens with 1.8 end-of-life, IMO
20:21:19 <cshen_> then bump to 1.11 LTS?
20:21:26 <e0ne> +1
20:21:45 <ying_zuo> 1.11 is not a problem
20:21:59 <e0ne> we can leave 1.10 jobs too
20:22:28 <e0ne> does anybody know which versions are available in debian/ubuntu and rhel/centos repos?
20:23:09 <cshen_> you meant ubuntu 16.04 LTS?
20:23:12 <rdopiera> we will upgrade to 1.11 in this cycle in rhel/centos
20:23:32 <rdopiera> IIRC
20:23:40 <david-lyle> Maybe push 2.0 to next release
20:24:04 <rdopiera> 2.0 is going to be a bit of pain because of python3
20:24:08 <e0ne> david-lyle: we can leave 2.0 as experimental for Queens
20:24:25 <david-lyle> as long as it doesn't break 1.8?
20:24:25 <cshen_> 1.8.7-1ubuntu5.5 for ubuntu 16.04
20:24:45 <david-lyle> ying_zuo, when is release date for queens
20:24:49 <e0ne> david-lyle: yes:(
20:24:55 <e0ne> #link https://review.openstack.org/#/c/528493/
20:25:14 <e0ne> david-lyle: https://releases.openstack.org/queens/schedule.html
20:25:26 <ying_zuo> Jan 22 - Jan 26 Queens-3
20:25:48 <david-lyle> Mar 2
20:25:50 <david-lyle> looks like
20:26:09 <david-lyle> so 1.8 is supported for > 1 month after release
20:26:17 <e0ne> :(
20:26:22 <ying_zuo> feature freeze starts after Queens-3
20:26:32 <david-lyle> I think there is likely to be more problems dropping 1.8 than not adding 2.0
20:26:40 <david-lyle> for queens at least
20:27:11 <e0ne> david-lyle: it means, vendors could probably ship horizon with outdated 1.8
20:27:32 <david-lyle> hopefully vendors ship 1.11
20:27:40 <e0ne> david-lyle: what problems do you mean? something with plugins?
20:27:48 <david-lyle> but people not using a vendor can not be forced to upgrade
20:28:48 <e0ne> we can force upgrade bumping min version in requirements.txt
20:29:50 <ying_zuo> can we drop 1.8 in Queens and move to 2.0 in R?
20:30:05 <david-lyle> ying_zuo, why drop an active LTS?
20:30:14 <david-lyle> that's my question over all
20:30:16 <ying_zuo> 1.8 is conflicting with 2.0
20:30:26 <david-lyle> we can't really support 2.0 anyway
20:30:30 <ying_zuo> so before we move to 2.0, will need to drop 1.8
20:30:53 <ying_zuo> would be good if we can break it down into a few steps
20:31:07 <david-lyle> I'll stop, but I'm not sure what you are gaining to drop an active LTS
20:31:36 <ying_zuo> as you mentioned, we should have 1 month for 1.8 after release
20:31:49 <ying_zuo> isn't it better to switch now?
20:32:47 <ying_zuo> 1.11 is also LTS
20:32:57 <david-lyle> the verbiage on django site is at least until April 2018
20:33:08 <david-lyle> *until at least April 2018
20:33:17 <ying_zuo> :p
20:33:20 <david-lyle> 2.0 is not a LTS
20:33:27 <ying_zuo> yes
20:33:34 <david-lyle> although that's not overly important
20:34:36 <e0ne> but we can't be sure that 1.8 will be supported after April 2018
20:35:13 <e0ne> I like amotoki proposal:
20:35:25 <david-lyle> my thought is more people will want to stick with an old python 2.7 compatible LTS of django than jump ahead to a partial support from horizon release that is python 3 only
20:35:25 <e0ne> we must support the latest LTS
20:35:51 <e0ne> we could experimental support any others non-LTS releases
20:35:52 <david-lyle> but I promised to stop :)
20:36:11 <ying_zuo> :)
20:36:40 <ying_zuo> I think you are saying it's more important to keep 1.8 than moving to 2.0
20:36:46 <ying_zuo> that's a good point
20:36:54 <e0ne> david-lyle: we're not talking about dropping python2 support at all. we just want to drop django 1.8 and support 1.11
20:37:06 <david-lyle> e0ne, I understand the proposal
20:39:29 <ying_zuo> so I read the blueprint again
20:39:37 <ying_zuo> 1.8 is conflicting with 1.11 too
20:39:51 <ying_zuo> so we can't keep 1.8 even if we don't move to 2.0
20:40:15 <david-lyle> we support 1.8 and 1.11 now
20:41:18 <e0ne> +1
20:41:19 <david-lyle> nothing in the bp claims conflict between 1.8 and 1.11
20:41:21 <ying_zuo> my bad, I read it wrong. 1.8 is only conflicting with 2.0
20:41:27 <david-lyle> ok
20:42:00 <ying_zuo> okay, I think it's fine that we don't merge the patches that break 1.8
20:42:17 <amotoki> morinig
20:42:22 <ying_zuo> it's good to have them ready so we can merge right after the release
20:42:23 <david-lyle> I'm absentee, so I can only express an opinion. Take whatever course you feel appropriate
20:42:40 <ying_zuo> good morning amotoki
20:43:03 <amotoki> seems django version discussion
20:43:08 <ying_zuo> yes
20:43:11 <ying_zuo> great timing :)
20:43:20 <amotoki> many-many if-else allows us to support 1.8, 1.11 and 2.0 :p
20:43:45 <ying_zuo> yes, I think the main concern is dropping 1.8 in Queens
20:44:01 <amotoki> this topic was originally raised by zigo related Debian support in the next debian release
20:45:14 <amotoki> personally I like Debian so I would like to have horizon in the next release of Debian, but it is my personal motivation
20:45:55 <amotoki> I thought we plan to drop django 1.8 support in Queens but I might misunderstand it
20:45:56 <rdopiera> when is that next release?
20:46:03 <rdopiera> of Debian
20:46:07 <amotoki> i don't know it
20:46:20 <rdopiera> if we are talking about a year from now...
20:47:19 <amotoki> zerga[m]: do you have any information if you are here?
20:47:30 <amotoki> http://eavesdrop.openstack.org/meetings/horizon/2017/horizon.2017-11-29-20.00.log.html#l-137
20:47:49 <amotoki> "I'm not sure when, but "soon" django 2.x will replace 1.11 in Sid. When this happens, horizon wont work anymore in Debian."
20:48:29 <amotoki> Sid means a development version, so it seems okay to have djnago 2.0 support in the early stage of rocky
20:50:19 <david-lyle> are we talking "stretch" or "buster" ?
20:50:33 <ying_zuo> it's probably better to keep 1.8 for Queens since we are in the middle of the last milestone...
20:50:54 <amotoki> david-lyle: "buster". "stretch" has been shipped.
20:50:56 <david-lyle> no release date is set for buster
20:51:13 <david-lyle> per https://www.debian.org/releases/
20:51:34 <rdopiera> "when it's ready"
20:51:50 <david-lyle> but it's usually years
20:52:03 <david-lyle> wnat stretch was just release in June
20:52:11 <david-lyle> *and stretch
20:52:53 <david-lyle> rushing things for an unstable release branch seems hasty :)
20:53:31 <rdopiera> but everyone run Sid...
20:53:48 <rdopiera> the stable releases are *ancient*
20:54:01 <amotoki> it's true for debian :p
20:54:20 * david-lyle shrug
20:54:52 <ying_zuo> 5 minutes left
20:55:25 <amotoki> any conclusion on the policy stuff (is_cloud_admin)?
20:55:27 <ying_zuo> do we agree on supporting 1.8 and 1.11 for Queens and 1.11 and 2.0 in R?
20:55:50 <rdopiera> that seems like the prudent course of action
20:56:04 <david-lyle> amotoki, I commented on your bugg
20:56:13 <amotoki> david-lyle: thanks
20:56:18 <david-lyle> I'm not sure I agree with the root cause analysis
20:56:53 <david-lyle> it could point to a regression in the policy engine in horizon
20:58:03 <amotoki> david-lyle: I haven't investigated the detail. at least you cannot see "Modify Quotas" menu after applying https://review.openstack.org/#/c/527668/
20:58:19 <amotoki> ying_zuo: I agree DJango 1.8/1.11 in Queens and bump the minimum for Rocky
20:58:19 <e0ne> ying_zuo: will we have meetings next two weeks?
20:58:31 <ying_zuo> #topic No Meeting on 12/27
20:58:39 <david-lyle> amotoki, that would point to the policy check returning False
20:58:41 <ying_zuo> e0ne: ^^^ :)
20:58:47 <e0ne> :)
20:59:03 <ying_zuo> Happy Holidays to everyone!
20:59:11 <david-lyle> defaults are only applied if the rule is there but empty on the right hand side
20:59:25 <ying_zuo> thank you all for your contribution to Horizon in 2017 :)
20:59:38 <ying_zuo> david-lyle: amotoki: running out of time again
20:59:43 <david-lyle> :)
20:59:48 <amotoki> :)
20:59:52 <ying_zuo> please continue in openstack-horizon :)
21:00:14 <ying_zuo> #endmeeting