21:00:27 <flwang1> #startmeeting zaqar
21:00:28 <openstack> Meeting started Mon Nov  9 21:00:27 2015 UTC and is due to finish in 60 minutes.  The chair is flwang1. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:32 <openstack> The meeting name has been set to 'zaqar'
21:00:54 <flwang1> #topic roll call
21:01:01 <ryansb> \o
21:01:27 <flwang1> o/
21:01:32 <Eva-i> hello
21:02:54 <flwang1> ok, let's start. not sure if vkmc and flaper87 can join today
21:03:05 <flwang1> #topic important patch/bug
21:03:20 <flwang1> 1. https://review.openstack.org/209238
21:03:58 <flwang1> we need to get the v2 patch in asap to avoid block the adoption in sahara
21:04:21 <flwang1> ryansb: can you put it on your today-to-list? :)
21:04:33 <ryansb> yeah, I can
21:04:48 <flwang1> ryansb: really appreciate that
21:05:03 <ryansb> though in my tz there isn't a lot of "today" left, so it may be a "in the morning" list
21:05:18 <flwang1> ryansb: it works for me either :)
21:05:46 <jasondotstar> o/
21:05:48 <jasondotstar> hi guys. I've been radio silent since summit. I'm back. :-)
21:05:57 <ryansb> hey there
21:06:08 <flwang1> jasondotstar: hey there
21:06:29 <flwang1> would you mind being the next topic speaker for the puppet work? ;)
21:06:36 <flwang1> 2. https://review.openstack.org/242287
21:07:06 <jasondotstar> well... I'm picking up where I left off this week
21:07:08 <flwang1> it's the dependency of the py34 patch, ryansb has dropped a great comment
21:07:36 <jasondotstar> which is continuing the work on the debian deployment sections of the module
21:07:47 <flwang1> jasondotstar: anything we can help?
21:08:11 <jasondotstar> well the debian packaging
21:08:19 <jasondotstar> has always been something that I wasn't sure about
21:08:42 <jasondotstar> who's handling that part? do we have the latest and greatest out in the deb repos?
21:09:16 <flwang1> jasondotstar: i can't remember the name of the guy, but i'm sure there is a guy working on the debian packaging of openstack
21:09:26 <jasondotstar> ack.
21:09:37 <flwang1> jasondotstar: i will figure out the name and let you know
21:09:41 <jasondotstar> well unless i can nail down the status
21:09:58 <jasondotstar> that part of the module is in a holding pattern :-/
21:10:03 <jasondotstar> flwang1: ack.
21:10:31 <flwang1> #action flwang will help jasondotstar figure out the debian packaging guy
21:11:31 <flwang1> jasondotstar: thanks a lot for working on this
21:12:12 <jasondotstar> no problem. goal is to get this stable during this release cycle.
21:13:58 <flwang1> jasondotstar: i'm so excited for the goal since we(catalyst IT) is keen to deploy it asap
21:14:10 <flwang1> and we need the puppet work
21:14:10 <jasondotstar> cool.!
21:14:57 <flwang1> any other patch/bug we should discuss in this topic?
21:15:30 <Eva-i> Can you look at my comment in the second patch?
21:15:43 <flwang1> Eva-i: yes, i did
21:16:11 <Eva-i> flwang1: so what do you think, is this code needed?
21:18:30 <flwang1> Eva-i: like we did for message database, i think we can init the connection with a default wc value
21:19:34 <flwang1> Eva-i: i will post another patch after figure out where the connection is initialized and see if it works
21:19:53 <Eva-i> flwang1: okay
21:20:07 <flwang1> does that address your question?
21:20:42 <flwang1> i mean using a default wc value instead of checking the None
21:22:16 <Eva-i> flwang1: yes, it's one of the possible solutions
21:22:33 <flwang1> ok, cool
21:24:22 <flwang1> ok, next topic
21:24:26 <Eva-i> flwang1: but "none checking code" can be removed as it affects nothing, I think. No need to modify wc initialization.
21:24:32 <Eva-i> ok, next topic
21:25:07 <flwang1> Eva-i: ok, we can discuss more details offline
21:25:38 <flwang1> #topic create pool/queue/flavor with existing name
21:26:03 <flwang1> this topic is related to https://review.openstack.org/#/c/238396
21:26:11 <flwang1> and https://review.openstack.org/#/c/238006/5
21:27:34 <flwang1> personally, i think it's a good enhancement
21:27:52 <flwang1> since we don't allow duplicated name for those resources
21:28:47 <ryansb> yeah, I'm all about surfacing better errors
21:28:57 <njohnston> I agree
21:29:12 <flwang1> the only reason i'm hesitating is because is breaking the api back compatibility and i'm not sure if there is a corner case we may miss
21:29:36 <flwang1> that's why i would like to get flaper87's feedback
21:29:44 <flwang1> or kurt's comments
21:30:00 <Eva-i> I don't know what to think about these patches because I don't know what backward compatibility for zaqar API is
21:30:23 <flwang1> i even asked why zaqar use PUT instead of POST to create new resources, but i forgot the answer from flaper87 :D
21:31:01 <Eva-i> I tried to make flaper87 answer these questions about backward compatibility https://etherpad.openstack.org/p/zaqar-backwards-compatibility-QA
21:31:28 <flwang1> Eva-i: the backward compatibility means before this patch, when you try to create a new flavor, you may update an existing one
21:31:35 <flwang1> after that, you will get a 409 error
21:32:24 <flwang1> Eva-i: hah, it's great :)
21:32:27 <ryansb> yeah, that is a breaking one
21:33:22 <Eva-i> different people in Zaqar have different vision of what backwards compatibility for API is
21:33:24 <flwang1> ryansb: you know, current behaviour has been existing for several releases, maybe there is a user case we missed
21:33:42 <Eva-i> *for Zaqar API
21:34:14 <flwang1> Eva-i: yep, that's why we need to get feedback from operators instead of just make a decision by developers :)
21:34:55 <flwang1> i will send a mail to kurt the founder of zaqar to get his opinion
21:35:44 <Eva-i> flwang1: wow, ok
21:36:09 <flwang1> awesome :)
21:36:22 <flwang1> Eva-i: thanks for your thinking on zaqar, it's valuable
21:36:40 <flwang1> #topic zaqar client
21:37:21 <flwang1> as i mentioned in the summit summary email, we still have a big gap for the zaqar client vs. server side
21:37:39 <flwang1> for v1, we're still missing the pool and flavor support
21:37:59 <flwang1> for cli
21:38:02 <vkmc> o/
21:38:05 <vkmc> sorry I'm very late
21:38:20 <flwang1> vkmc: hey
21:38:28 <flwang1> we're talking about the zaqar client work
21:38:44 <vkmc> yeah
21:38:45 <vkmc> :)
21:38:46 <vkmc> just in time
21:39:55 <flwang1> for v2, we're missing flavor, pool, subscription and pre-signed url support for library layer after https://review.openstack.org/209238 merged
21:40:16 <vkmc> yeah
21:41:10 <flwang1> vkmc: if you can review https://review.openstack.org/209238 today, you will get another nz chocolate
21:41:28 <vkmc> flwang1, oh that nz chocolate is amazing
21:41:35 <vkmc> I was going to review that anyway
21:41:40 <vkmc> sorry it's taking me so long
21:42:00 <vkmc> I catch up with some reviews today but I had that one pending :)
21:42:02 <flwang1> vkmc: if it can get your +2, i will merge it
21:42:25 <flwang1> vkmc: i see, no worries
21:43:48 <vkmc> thx
21:44:08 <flwang1> so now md is working on the client work and i will give him a hand for subscription
21:44:26 <flwang1> if anybody can take the pre-signed url part, it would be awesome
21:44:42 <vkmc> do we need an spec for that?
21:44:44 <flwang1> our goal is complete the client work in Mitaka-1
21:44:50 <vkmc> +1
21:45:22 <flwang1> vkmc: TBH, i don't think we need a spec for this
21:45:31 <ryansb> Yeah, the spec for server work is up
21:45:40 <ryansb> the client work is (IMO) part of that
21:45:47 <flwang1> ryansb: +1
21:47:20 <flwang1> anything we should discuss for this topic?
21:48:53 <flwang1> #topic horizon + zaqar
21:50:01 <flwang1> we would like to implement a basic filter for subscription to avoid flooding when there are too much messages
21:50:45 <flwang1> with this, the subscriber can subscribe a queue but don't receive all the messages of the queue
21:50:54 <flwang1> does that make any sense for you guys?
21:52:12 <ryansb> I'd disagree with adding that, but not very strongly
21:53:03 <ryansb> because I think that operators/users should partition workloads to multiple queues if subscribers can't keep up
21:53:12 <vkmc> does it make sense to have in Zaqar side?
21:53:15 <vkmc> yeah
21:53:36 <flwang1> yep, in zaqar side
21:53:58 <flwang1> we need it for horizon integration
21:54:36 <Eva-i> flwang1: why is it needed for horizon integration?
21:54:38 <vkmc> yeah
21:54:41 <flwang1> horizon want to be notified by some particular notifications, like from nova instance change, image change or volume change
21:54:46 <flwang1> but not all the notifications
21:54:57 <njohnston> Is there an indication in the server or client side user experience or logs that it has been detected that the subscriber can't keep up?  How do we know that to be true?
21:55:17 <flwang1> so that to trigger horizon  to a on-demand poll for those services
21:55:41 <flwang1> now horizon has to poll per second to get the latest status for instance, images, etc
21:56:51 <ryansb> so is it certain that horizon can't filter clientside?
21:57:09 <flwang1> ryansb: they can, but they don't want i think :)
21:58:06 <ryansb> that doesn't mean it's a feature we should add. I think adding it would get pretty complex, pretty quickly
21:58:40 <flwang1> yep, i can see your point
21:58:53 <flwang1> we can discuss offline
21:58:57 <flwang1> we have 2 minutes left
21:59:09 <flwang1> #topic open disussion
21:59:18 <flwang1> anything we should talk here ?
21:59:26 <ryansb> not from me
21:59:27 <flwang1> or we can go back to zaqar channel
21:59:40 <vkmc> not from me :)
22:00:11 <flwang1> ok, cool
22:00:12 <flwang1> #endmeeting