02:02:57 <flwang> #startmeeting Zaqar
02:02:58 <openstack> Meeting started Tue Apr 18 02:02:57 2017 UTC and is due to finish in 60 minutes.  The chair is flwang. Information about MeetBot at http://wiki.debian.org/MeetBot.
02:02:59 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
02:03:01 <openstack> The meeting name has been set to 'zaqar'
02:03:22 <wanghao> hi
02:04:09 <flwang> wanghao: hello
02:04:31 <wanghao> flwang: hello
02:04:43 <wxy> Hi
02:05:05 <flwang> wanghao: wxy: here is the agenda https://etherpad.openstack.org/p/zaqar-meeting-agenda
02:05:43 <flwang> wanghao: wxy: thanks for joining
02:06:16 <flwang> i'd like to take this opportunity to make sure we're on the same page for the two specs and the pooling isues
02:06:25 <flwang> s/isues/issues
02:06:28 <wanghao> okay
02:07:04 <flwang> #topic service queue
02:07:33 <wanghao> I have updated the service spec yesterday. so what's idea about that.
02:07:58 <wxy> what's the main problem now?
02:08:09 <flwang> sorry, i haven't review the latest patch set since i was in holiday yesterday
02:08:27 <wanghao> that's fine
02:08:41 <wanghao> just updated according your comments
02:09:07 <flwang> wxy: i think we have a different opinions where to save the queues and if we allow the other non-admin tenant users access service queues belonged to another project
02:10:06 <flwang> wanghao: am i missing any point?
02:10:19 <wanghao> yeah,  in spec now,  the service queues are saved in the project who created it.
02:11:11 <wanghao> flwang: no, I think.
02:11:55 <flwang> wanghao: ok, let's discuss the first item
02:11:59 <flwang> where to save the queues
02:12:24 <flwang> how the service user access the normal user's project?
02:12:29 <flwang> did you test it?
02:13:15 <wanghao> not yet
02:14:34 <flwang> wanghao: hmm... it would be nice if you can give it a try, like a PoC and post the github link in the spec comments, so that we can review it to make sure it works
02:15:03 <flwang> technically, i don't have a strong preference about where to save, but i would like to make sure it works before we approve the spec
02:15:08 <flwang> wxy: any comments?
02:17:00 <wanghao> flwang: you mean an example like the service user put messages to queue belonged to normal user's project
02:17:01 <wxy> flwang: I should review the spec later then comment there.
02:17:21 <flwang> wanghao: yes
02:17:24 <flwang> wxy: no worries
02:17:52 <wanghao> flwang: okay, will make a patch and post the link in spec comments.
02:19:24 <flwang> wanghao: awesome
02:20:04 <flwang> the 2nd item, if allow non-admin tenant users access service queues belonged to another project
02:20:06 <wanghao> flwang: so this way means we save server queue in normal user's project, right?
02:20:24 <flwang> wanghao: yes, if you really want to do that
02:20:42 <flwang> but IMHO, it's difficult than saving the queue in service tenant
02:21:07 <wxy> I like the 2nd.
02:22:19 <flwang> wxy: what do you mean?
02:23:03 <flwang> you mean saving queues in service tenant or  the 2nd sub topic  "if allow non-admin tenant users access service queues belonged to another project"
02:23:32 <wxy> flwang: saving queues in service tenant
02:23:45 <flwang> wxy: good
02:23:47 <wanghao> flwang: wxy: Can we just save the queues in the project who create it.
02:23:56 <wxy> It is easy for other project to use this feature.
02:24:23 <flwang> wanghao: we can if you can prove it works
02:24:32 <wxy> wanghao: +1
02:24:58 <wanghao> flwang: wxy: okay, seems some codes are necessary.
02:26:27 <wanghao> In my mind,  we don't distinguish the service project or other normal user project
02:26:52 <wanghao> the service queue belongs to who create it, and allow other projects can access it.
02:27:43 <wanghao> so about the 2nd sub topic,  IMO, we should allow non-admin tenant users access the service queue.
02:29:12 <wanghao> any idea?
02:30:46 <wanghao> hello? anyone here?
02:30:49 <flwang> wanghao: as I asked before, 1. do we have any user case for this?  2. is this a simple design? given we may have to introduce a complex ACL for this?
02:32:40 <wanghao> flwang: em, I'm thinking about it. Indeed, there isn't clearly case for this...
02:33:09 <wanghao> flwang: it's a more common way to implement this feature.
02:33:53 <flwang> wanghao: i know it looks a general way. but i don't want over engineering :)
02:34:12 <flwang> and you know, the ACL will be complicated
02:34:40 <wanghao> flwang: So your idea is only service project user can create the service queue, and other admin user in other project can see it, right?
02:34:46 <flwang> besides, we  have to use queue metadata to save the ACL info, that's not really efficient
02:36:01 <wxy> Correct me if i'm wrong, our original purpose is : introduce a way that let other project can use to send out some internal information. These information can be get/claimed by end user. Right?
02:36:03 <flwang> wanghao: personally, i would like to see:  1. service user create service queue in service project  for project A       2. users of project A can access this queue
02:37:04 <wanghao> wxy: get by end user in other project.
02:37:22 <flwang> wxy: the original user case is:   as a project user, I would like to see the notifications of my resource changes
02:37:45 <flwang> those notifications are in rabbitMQ now
02:38:28 <flwang> we need a way to forward these notifications to Zaqar, so that tenant users can consume these notifications for monitoring/auditing
02:38:34 <flwang> does that make sense?
02:38:58 <wxy> flwang:  OK, It's clear now. So I think your idea is a simple and right way at this moment.
02:39:41 <wxy> flwang: wanghao: maybe the generic way is the next step.
02:39:58 <wxy> we don't need it right now.
02:40:11 <wanghao> flwang: wxy: so there is issue:  how we control that only service user can create service queue?
02:40:33 <flwang> wanghao: wxy: I can see wanghao's idea is useful, but i don't want to ship a perfect feature now :)
02:40:53 <flwang> i would like to see a simple design which can be easy to improve when we can see the requirement
02:41:18 <flwang> wanghao: not only user?
02:41:32 <flwang> but the user with 'service' role
02:42:28 <wanghao> flwang: 'service' role?  I think it's 'admin' role in service user.  I'd like to check it.
02:42:29 <flwang> i mean the user belong to service tenant
02:43:48 <wanghao> yes, my concern is if a user with a project_id to create service tenant, Zaqar need to validate it to ensure it's a service tenent.
02:44:16 <flwang> wanghao: yes, it's user in 'services' project with admin role
02:44:51 <flwang> wanghao: yep, either way we need a poc to make sure it works
02:44:56 <flwang> ok, we only have 15 mins
02:44:57 <wanghao> flwang: yes
02:45:00 <wxy> flwang: wanghao: "service" role as well.
02:45:10 <flwang> should we go for next topic?
02:45:14 <wanghao> okay
02:45:36 <flwang> would you  guys mind skipping the 'notificaiton delivery spec'?
02:45:40 <wxy> not all the users in service project has "admin" role by default.
02:45:47 <flwang> because i'd like to discuss the pooling bugs
02:45:54 <flwang> wxy: good to know
02:46:06 <wxy> flwang: yeah, the notificaiton delivery spec is LGTM now.
02:46:13 <wanghao> flwang: sure,  I think it can be merged now, that's clearly.
02:46:50 <flwang> #topic pooling bugs
02:47:24 <flwang> as for the pooling bugs, the background is we moved the queues saving from message store to management store
02:47:37 <flwang> and obviously, it introduces some regression issues
02:48:03 <flwang> based on current design, zaqar is saving queue in management database
02:48:26 <flwang> when pooling enabled
02:48:29 <flwang> but
02:48:51 <flwang> for pooling, there are real pooling and a virtual pooling
02:49:18 <flwang> real pooling means, there is a management db and all messages stores are pools
02:50:11 <flwang> for this case, admin user has to add message store as pool
02:50:42 <flwang> by run openstack pool list, admin user can see all the pools
02:51:06 <flwang> however, for virtual pooling, admin user don't have to create a pool for message store
02:51:31 <flwang> zaqar will get the message store and mgmt store info from the config file
02:51:38 <flwang> that's the design/background
02:51:49 <flwang> hope it's helpful for you guys to review the patches
02:51:56 <wxy> very clear.
02:51:58 <wxy> :)
02:52:04 <wanghao> flwang: got it
02:52:54 <flwang> for a production env, we're expecting it's a real  pooling
02:53:21 <flwang> unfortuantely , almost all our tests are virtual pooling
02:53:30 <flwang> hence why the bugs are there
02:53:48 <wanghao> so for virtual pooling,  it's actually only one pool, right
02:54:25 <flwang> wanghao: yep and no
02:54:43 <flwang> for virtual pooling, you can't see any pool by running 'openstack pool list'
02:54:53 <flwang> because it's a virtual pool
02:55:11 <wanghao> just into the message store according the conf file, right?
02:55:18 <flwang> wanghao: correct
02:55:19 <wanghao> okay, I see
02:55:58 <wxy> flwang: is it possible to create a multi-node CI for pool test?
02:56:16 <flwang> wxy: we even don't really need a multi node CI
02:56:29 <wxy> oh yeah
02:56:31 <flwang> we just need to make sure the pool is added as a real pool
02:56:52 <wanghao> and I saw swift backend didn't support management store now, should we support it?
02:57:01 <flwang> wanghao: no
02:57:03 <flwang> we don't
02:57:06 <flwang> just like redis
02:57:32 <wxy> flwang: I'd like to help you to improve the test.
02:57:39 <wanghao> okay,  I see
02:57:48 <flwang> wxy: it would be super cool
02:58:06 <flwang> wxy: i do need some help on https://review.openstack.org/#/c/453440/
02:58:18 <flwang> the failed tests for swift
02:58:37 <wxy> flwang: sure. leave it to me.
02:59:08 <flwang> wxy: fantastic
02:59:15 <wanghao> flwang: I can help to review those patch, you can add me as reviewer.
02:59:32 <flwang> wxy: and count this https://review.openstack.org/454672
02:59:43 <flwang> swift is a special driver
02:59:50 <flwang> ok, we're running out of time
03:00:00 <wxy> Thomas leaved a good question.
03:00:03 <flwang> let's back to zaqar channel
03:00:08 <flwang> wxy: yep i saw that
03:00:49 <wxy> Ok.
03:02:09 <flwang> thanks, guys
03:02:12 <flwang> #endmeeting