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