20:00:36 <ying_zuo> #startmeeting horizon
20:00:36 <openstack> Meeting started Wed Dec 13 20:00:36 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:37 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:40 <openstack> The meeting name has been set to 'horizon'
20:00:52 <ying_zuo> Hi everyone o/
20:00:54 <rdopiera> o/
20:01:03 <cshen> hello
20:01:14 <cleong> hi
20:01:18 <e0ne> hi
20:01:43 <ying_zuo> I don’t have any notices this week so we will start the open discussion now
20:01:50 <ying_zuo> #topic Open Discussion
20:02:51 <cshen> e0ne I saw your mail in the mailing list.
20:03:12 <cshen> regarding parallel fetching the data.
20:03:17 <e0ne> cshen: do you have any input on this topic?
20:04:12 <cshen> Actually I'd like to see more test results, meaning a bigger openstack environment.
20:04:42 <e0ne> cshen: unfortunately, I don't have such environment by the hand now
20:05:08 <cshen> the new approach had some improvement, but not so dramatically.
20:05:08 <e0ne> we did some testing on 100 nodes last year, but I failed to find results
20:05:22 <cshen> 100 nodes, meaning VMs or?
20:05:34 <e0ne> I mean 100 compute nodes
20:06:14 <e0ne> I remember that parallel fetching was faster, but I can't prove it atm
20:06:28 <cshen> I see, the cluster my company is setting up, is just about 30-40 computer nodes.
20:06:52 <cshen> in theory, it should be faster, no doubt
20:07:11 <e0ne> I hope it's 	obviously for all that parallel API calls are faster than linear
20:07:28 <cshen> true
20:07:43 <e0ne> it would be good if you are able to test it on your env
20:07:58 <cshen> sure, if I have some results, I would let you know.
20:08:15 <e0ne> thanks
20:08:29 <cshen> np, will get you in contact individually.
20:08:54 <e0ne> we really haven't a lot of time to get it merged in Queens:(
20:09:38 <cshen> during the Christmas holiday, I might have some time to test the patch.
20:09:41 <ying_zuo> that's right. so that's the main reason that this blueprint hasn't been approved
20:10:07 <ying_zuo> one of the main reasons
20:10:28 <cshen> Ok, I understand.
20:10:38 <e0ne> ying_zuo: we already have some parallel API calls merged before blueprint was filed
20:11:39 <ying_zuo> yes, the other thing is that you prefer to use GreenThreadPoolExecutor
20:12:33 <e0ne> yes, that's is a new thing which we're discussing last 2 months
20:12:57 <ying_zuo> I am just saying it's different from what's been merged
20:13:15 <e0ne> sure
20:13:31 <e0ne> you're right
20:13:53 <e0ne> we're blocked now
20:14:31 <ying_zuo> yes, mainly for the testing result for this change.
20:14:36 <e0ne> we don't merge new patches with ThreadPoolExecutor and do not have a decision how to get forward
20:14:56 <ying_zuo> are there other patches using ThreadPoolExecutor?
20:15:10 <e0ne> not yet at the moment
20:15:26 <e0ne> oh, I'm sorry
20:15:42 <e0ne> there are several patches with use ThreadPoolExecutor
20:16:12 <e0ne> #link https://review.openstack.org/#/q/status:open+project:openstack/horizon+branch:master+topic:bp/fetch-resources-in-parallel
20:16:41 <e0ne> #link https://review.openstack.org/#/c/426493/20
20:18:10 <ying_zuo> I thought you think it's better to use GreenThreadPoolExecutor?
20:18:59 <e0ne> 1) it's faster a bit. 2) it consumes less memory. 3) it doesn't relate on apache/uwsgi configuration
20:19:12 <e0ne> so I'm all for GreenThreadPoolExecutor
20:19:37 <ying_zuo> so are you planning to change your patch to use that?
20:20:03 <e0ne> my patches used ThreadPoolExecutor before I did some testing
20:20:26 <e0ne> I'll change them once we decide what pool executor will we use
20:20:57 <ying_zuo> there are some questions about the performance data
20:21:19 <ying_zuo> once we have that, I think we are good to proceed
20:21:38 <e0ne> ying_zuo: what questions do you mean?
20:21:55 <ying_zuo> the question is not from me
20:22:46 <e0ne> I tried to answer amotoki's question in the ML and on the last meeting
20:23:01 <ying_zuo> is he okay with that?
20:23:19 <e0ne> also, I did some more tests as robcresswell asked to do
20:23:38 <e0ne> I'll ask amotoki tomorrow. I didn't get  a lear answer yet:(
20:23:57 <ying_zuo> cool. thanks
20:25:26 <e0ne> I'll update blueprint after discussion with robcresswell  and amotoki
20:25:47 <ying_zuo> +1
20:26:08 <ying_zuo> are there any other questions from anyone?
20:26:22 <rdopiera> have you people seen the 1 year cycle proposal?
20:26:51 <rdopiera> I wonder if we should discuss this?
20:26:56 <e0ne> I saw a thread in a ML but didn't read yet
20:27:10 <ying_zuo> do you have a link?
20:27:50 <rdopiera> http://lists.openstack.org/pipermail/openstack-dev/2017-December/125473.html
20:27:55 <rdopiera> #link http://lists.openstack.org/pipermail/openstack-dev/2017-December/125473.html
20:28:00 <ying_zuo> thanks
20:28:01 <e0ne> #link http://lists.openstack.org/pipermail/openstack-dev/2017-December/125473.html
20:28:15 <e0ne> rdopiera: you're faster :)
20:28:24 <rdopiera> I had it open
20:29:06 <e0ne> there are 38 responses already
20:29:20 <rdopiera> no wonder, it's a very dramatic change
20:29:41 <rdopiera> perhaps it's too early to discuss it yet
20:29:52 <e0ne> I hope, there is no a much of bikeshedding
20:31:57 <ying_zuo> I don't see much gain for making this change
20:32:42 <ying_zuo> I think planning for half year is better for one year
20:32:50 <rdopiera> having just finished my work on downstream Pike, and seeing featurre freeze just as I'm ready to work on features, I would kinda see some sense it that
20:33:15 <rdopiera> but that's probably just me
20:33:17 <ying_zuo> good point
20:33:28 <e0ne> rdopiera: I totally agree with you from vendor's point of view
20:34:07 <e0ne> we still didn't finish all pike-related activities
20:34:11 <ying_zuo> the feature freeze causes some delay
20:34:49 <ying_zuo> would be good to somehow shorten the time of feature freeze
20:35:24 <rdopiera> then there is more risk for the new features to introduce bugs
20:35:28 <rdopiera> and less time to stabilize
20:35:30 <e0ne> 6 months is a very little time for vendors to prepare a new version
20:36:36 <rdopiera> I have to admit that pike was exceptionally disastrous for us in terms of being late for everythin -- it's not normally that bad
20:37:13 <ying_zuo> the vendors will just pick up the latest stable release at the time that they want to upgrade
20:38:23 <e0ne> ying_zuo: it doesn't work in a such way. we do a lot of downstream activities like custom patches, packaging, testing, etc
20:38:38 <e0ne> vendors can't just pick up the latest stable
20:39:07 <ying_zuo> yes, I meant at the time that they want to do the upgrade
20:39:18 <e0ne> especially, when we've got customers with an old-old releases
20:39:27 <rdopiera> I think you two mean different things by "vendors"
20:39:58 <e0ne> I mean OpenStack distro vendors
20:40:17 <ying_zuo> I meant the downstrem
20:40:21 <rdopiera> basically the companies that package and sell openstack
20:40:22 <ying_zuo> downstream
20:40:27 <dklyle> don't you worry about upgrades? 1 full year of API/config drift?
20:40:49 <dklyle> vs having to sync every six months?
20:41:15 <rdopiera> dklyle: the update path would be tested either way
20:41:57 <dklyle> understood, but the closer we stayed to master the easier it was to upgrade
20:42:09 <rdopiera> to be honest, most large users of openstack don't update until a year or two after a release, if ever
20:42:14 <dklyle> take in small chunks rather than large rewrites of downstream code
20:42:20 <e0ne> it could be a nightmare for those, who use master branch in production
20:42:34 <e0ne> rdopiera: +1 :(
20:42:36 <rdopiera> e0ne: that's self-inflicted pain
20:43:01 <e0ne> :)
20:43:03 <dklyle> waiting 1+ year for a feature is another type of pain
20:43:04 <cshen> so far openstack doesn't have a LTS version.
20:43:17 <rdopiera> dklyle: there are backports
20:43:31 <dklyle> for bugs
20:43:41 <rdopiera> dklyle: depending on the vendor
20:43:41 <dklyle> but yes you could carry a backport downstream
20:43:44 <e0ne> dklyle: it depends on feature. we have to wait few years even with a current releases
20:44:14 <dklyle> maybe things are stable enough that absorbing the changes is easier
20:44:19 * e0ne doesn't backport features
20:44:26 * rdopiera sometimes has to
20:44:28 <dklyle> used to be whole packages and libraries would be replaced
20:44:33 <e0ne> rdopiera: :(
20:44:40 <dklyle> when you start combining that for downstream code
20:44:47 <rdopiera> e0ne: yeah, we fight against it every time
20:44:59 <rdopiera> e0ne: and we do have LTS
20:45:13 <e0ne> but project still have ability to do releases more often
20:45:19 <rdopiera> and of course most backports are to LTS
20:45:45 <amotoki> perhaps the points are how long we consider backports and how many releases we support upgrade (one/two/more and/or LTS)
20:45:53 <e0ne> rdopiera: we still have customers with mitaka. but in general, we don't backport features to our distro
20:46:08 <e0ne> amotoki: good morning!
20:46:19 <amotoki> morning
20:46:26 <amotoki> not a small number of operators have their own stable branches
20:47:10 <amotoki> that is one of main motivations of community-driven stable branches (LTS discussion)
20:47:29 <rdopiera> yeah, it would be nice to join forces on that
20:47:36 <rdopiera> spread the effort a bit
20:48:11 <e0ne> rdopiera: do you still work for RedHat?
20:48:17 <rdopiera> e0ne: yes
20:48:40 <amotoki> as you all may know, LTS discussion was split into two discussions: LTS/longer stable branches and longer release cycle
20:48:49 <rdopiera> e0ne: we didn't do a feature backport in a while (our managmenet usually takes our side), but it's always a possibility
20:49:31 <e0ne> rdopiera: understand... we have some customization for customers some times
20:49:45 <rdopiera> that fortunately we don't do :)
20:50:32 <rdopiera> in any case, there are also obvious drawbacks to the longer cycle
20:51:00 <rdopiera> harder to plan for the whole year, for sure
20:51:25 <rdopiera> changes that need api changes in other services will take longer to land
20:51:38 <rdopiera> all the deprecation process will take longer
20:51:44 <e0ne> :(
20:52:19 <e0ne> I think, TC should re-think deprecation policy for annual releases
20:52:49 <amotoki> rdopiera: good list of drawbacks :)
20:52:56 <e0ne> I do not want su support something deprecated for 2-3 years:(
20:53:18 <e0ne> s/su/to
20:54:27 <rdopiera> we have to support it for at least one version
20:54:48 <rdopiera> we can't just remove something fom release to release without any warning
20:55:17 <amotoki> i have another topic: RBAC/policy (if you can), but you can discuss it next or next next ... meetings
20:55:45 <rdopiera> I think it's too early to really discuss the cycle length change now
20:56:12 <ying_zuo> amotoki: can you put that on the agenda of the next meeting?
20:56:15 <rdopiera> I just brought it up because I saw it just now and it was fresh in my mind
20:56:28 <amotoki> ying_zuo: okay, but perhaps I will not be there
20:56:33 <e0ne> amotoki: there're only  5 mins left :(
20:56:56 <amotoki> my point is we have several number of obsolete policies in our code
20:57:04 <amotoki> like https://github.com/openstack/horizon/blob/master/openstack_dashboard/api/keystone.py#L325-L331
20:57:22 <amotoki> my question to you is how we can avoid or detect such things.
20:57:43 <amotoki> it would be nice if you think and/or gather ideas next week
20:57:50 <dklyle> amotoki, those methods are problematic
20:58:23 <dklyle> I had the idea of a proper policy system for horizon, but never got to finish it
20:58:28 <amotoki> after updating keystone_policy.json, i cannot see Modify Quotas action due to a broken is_cloud_admin :(
20:59:05 <amotoki> dklyle: it would be nice if you share your thought
20:59:20 <dklyle> ideally we'd have a horizon specific policy that would create the mappings to other services policies
20:59:27 <dklyle> and not stuff them in code
20:59:34 <dklyle> but rather config
20:59:51 <amotoki> another kind of policy-in-code?
20:59:55 <dklyle> but it's a sizeable rewrite, but the existing system is inflexible
21:00:15 <dklyle> amotoki, more like a horizon policy file, in a policy.json file
21:00:25 <ying_zuo> sorry, we are running out of time. Please continue the discussion in #openstack-horizon.
21:00:32 <amotoki> dklyle: you seem to have nice idea :)
21:00:34 <ying_zuo> #endmeeting