01:01:28 <joehuang> #startmeeting tricircle
01:01:28 <openstack> Meeting started Wed Aug 16 01:01:28 2017 UTC and is due to finish in 60 minutes.  The chair is joehuang. Information about MeetBot at http://wiki.debian.org/MeetBot.
01:01:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
01:01:32 <openstack> The meeting name has been set to 'tricircle'
01:01:41 <joehuang> #topic rollcall
01:01:46 <joehuang> #info joehuang
01:01:47 <xuzhuang> hi
01:01:50 <dongfeng> #info dongfeng
01:01:54 <xuzhuang> #info xuzhuang
01:01:55 <RongHui11> #info ronghui
01:02:02 <hejiawei> #info jiawei
01:02:03 <Yipei> #info Yipei
01:02:03 <RongHui11> hi
01:02:51 <joehuang> hello
01:03:03 <zhiyuan> hi
01:03:10 <joehuang> currently new PTL election is ongoing, and almost done
01:03:36 <joehuang> only one candidate for tricircle project, If I am correctly
01:03:58 <joehuang> so no voting for tricircle project
01:04:47 <joehuang> next week, the chair of the weekly meeting will be handed over to new PTL
01:05:02 <joehuang> is it ok?
01:05:11 <zhiyuan> fine
01:05:12 <RongHui11> no problem
01:05:16 <dongfeng> fine
01:05:49 <Yipei> fine, got it
01:05:55 <joehuang> #topic regression test
01:07:04 <joehuang> As discussed in the maillist, ttx thought that we need to cut stable/pike branch early, so that if there is any critical issue, we have chance to fix it
01:07:58 <joehuang> #link http://lists.openstack.org/pipermail/openstack-dev/2017-August/120946.html
01:08:11 <fredli__> good morning, tricircle team
01:08:22 <joehuang> hello, fred
01:08:47 <joehuang> we had planned to cut stable/pike August 22
01:09:05 <joehuang> We may need to move the cutting earlier this week
01:09:23 <joehuang> have you found any critical issues in regression test?
01:09:28 <dongfeng> I conduct the tests for admin API for tricircle and tricircleclient, the CRUD operation for pods/routing/jobs works well. only job pagination is needed in tricirclelient.
01:10:21 <joehuang> I found two bugs need to be addressed soon
01:10:25 <joehuang> #link https://bugs.launchpad.net/tricircle/+bug/1711001
01:10:25 <openstack> Launchpad bug 1711001 in Tricircle "Job list not filtered by project" [Undecided,New]
01:10:40 <joehuang> #link https://bugs.launchpad.net/tricircle/+bug/1711003
01:10:40 <openstack> Launchpad bug 1711003 in Tricircle "routing list not filtered by project" [Undecided,New]
01:11:12 <joehuang> both these two API processing need to consider the project filtering
01:12:47 <joehuang> would someone help fix these two bugs ASAP, then we can cut the stable/pike branch
01:13:01 <dongfeng> I remember that project is a mandatory filter but later we didn't implement it.
01:13:11 <dongfeng> ok, I will fix it
01:13:45 <zhiyuan> it can be passed via the filter
01:13:50 <dongfeng> yes
01:14:12 <joehuang> could you fix it today? we have to move fast for the stable/pike branch
01:14:27 <zhiyuan> then you need to extract project id in tricircle client
01:14:44 <zhiyuan> or you add a new client option for project id?
01:15:14 <dongfeng> change project id filter from optional to mandatory in tricircle and tricircleclient
01:15:33 <joehuang> support it in tricircle side in pike
01:15:56 <joehuang> because tricricleclient has already cut the stable/pike branch, and no fix will be included in pike
01:16:29 <zhiyuan> so extract the project id in the context and pass it as the filter by default?
01:17:12 <dongfeng> ok. got it. so new command for routings will be  "curl -x get /routings/project-id"?
01:17:51 <joehuang> there is project in the context for the user's request
01:17:52 <dongfeng> so new command for routings will be  "curl -x get /routings?project-id=xxx"?
01:18:32 <zhiyuan> I think asking user to always pass the project-id is not user-friendly
01:19:23 <joehuang> the client side is freeze now, not to change the command, and API format is also freeze, it is very serious to change API
01:19:43 <zhiyuan> what if the project-id is not passed, dongfeng? will you return a bad request error?
01:19:52 <dongfeng> no error.
01:21:24 <dongfeng> how about specifying project_id internally and remove the project_id filter ?
01:22:49 <joehuang> no, by default, you need to filter by the project-id in the request context
01:24:35 <dongfeng> so project_id also serves as filter and can be specify from command line ?
01:26:15 <joehuang> yes, if there is project id specified, then check whether the user has the right to query data from the specified project, if yes, filter by the specified project, otherwise, filter with the project-id in the context by default
01:27:27 <joehuang> if there is project id specified, then check whether the user has the right to query data from the specified project, if yes, filter by the specified project, if not, reject the request. If no project-id is specified, filter with the project-id in the context by default
01:28:21 <zhiyuan> here is a problem, can we directly know from the context whether the user has the "admin" role of another project?
01:29:12 <zhiyuan> context may only contain (userA, projectA, role of userA in projectA)
01:29:48 <zhiyuan> but user may pass projectB as filter
01:33:11 <joehuang> so we have to only use the project id in the context to filter the query data
01:33:58 <dongfeng> then no project id filter ?
01:34:31 <dongfeng> then no project id filter from command line?
01:35:12 <joehuang> not to add currently, and no need indeed
01:36:29 <joehuang> more comment for the filtering?
01:37:09 <zhiyuan> so we do the following changes (1) extract project id from context ans use as filter (2) if project id is passed, check if it match the project id in the context
01:37:19 <zhiyuan> is that right?
01:37:29 <zhiyuan> s/ans/snd
01:37:32 <zhiyuan> s/ans/and
01:38:12 <dongfeng> if only one project id, then no need specify it from cli
01:39:29 <zhiyuan> but user may deliberately pass a project id which doesn't match his/her context
01:39:39 <joehuang> we have to ignore the project-id passed from the cli, because no idea whether the user has enough right to query the project
01:40:04 <joehuang> we only filtering the data the user is authorized
01:40:37 <zhiyuan> oh, just ignore it?
01:40:51 <joehuang> so only using the project-id and role in the context(which is authenticated)
01:41:42 <joehuang> currently just ignore that, and update the API document to stress this
01:43:47 <dongfeng> stress like "project id must be current user" ?
01:45:11 <joehuang> project-id filter will be ignored, and only the project id in which the user is authorized will be used as the filter.
01:45:33 <dongfeng> got it.
01:47:18 <joehuang> project-id filter in URL query string will be ignored, and only the project id in which the user is authorized will be used as the filter.
01:47:42 <joehuang> the last description is better
01:48:07 <dongfeng> got it
01:48:50 <joehuang> so these two bugs are put in "high" importance
01:49:22 <joehuang> and hope it can be fixed today, so that we can cut the stable/pike branch if no high/critical bug is reported today
01:49:38 <dongfeng> en, I will handle asap.
01:49:55 <joehuang> #topic open discussion
01:49:58 <joehuang> other topic?
01:50:40 <Yipei> for lbaas, some modification on get_subnet is needed to adapt lbaas, once it is finished the lbaas is compeleted. since i commented the line of checking whether subnet exists, it works well in both neutron-lbaas api and octavia api
01:51:33 <joehuang> Good, yipei, welcome the LBaaS to land in Queen
01:51:42 <zhiyuan> so next step is trying to modify get_subnet in central_plugin/local_plugin ?
01:51:52 <Yipei> only in local
01:52:16 <Yipei> to joehuang, not in pike?
01:52:45 <joehuang> no, pike is feature freeze, and now it's regression test, no feature is allowd
01:52:45 <RongHui11> for QoS, we pass all the test yesterday and please review it :)
01:53:08 <zhiyuan> modifying get_subnet in local_plugin needs to be careful since get_subnet is also used to handle VM creation
01:53:48 <joehuang> to Ronghui, please include functional test too, just like what zhiyuan did for the smoke test for other features
01:53:49 <Yipei> to zhiyuan, got it, i will discuss the details with you guys
01:54:10 <zhiyuan> so do we plan a PTG for Queens?
01:55:07 <RongHui11> ok
01:55:09 <joehuang> yes
01:55:42 <joehuang> PTG for queens is indeed to be in the table now
01:56:19 <joehuang> other topic?
01:56:31 <RongHui11> no for me
01:56:48 <dongfeng> no for me
01:56:50 <Yipei> no for me
01:56:54 <zhiyuan> no more
01:57:02 <xuzhuang> no
01:57:59 <joehuang> ok
01:58:06 <joehuang> thank you for attending the meeting
01:58:10 <joehuang> #endmeeting