15:00:42 <flwang1> #startmeeting zaqar
15:00:43 <openstack> Meeting started Mon Feb  1 15:00:42 2016 UTC and is due to finish in 60 minutes.  The chair is flwang1. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:45 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:48 <openstack> The meeting name has been set to 'zaqar'
15:00:54 <njohnston_> o/
15:01:07 <flaper87> o/
15:01:22 <flwang1> from now on, if you guys can't see msg from me after 5 mins, then i have slept
15:01:27 <ryansb> o/
15:01:30 <flwang1> flaper87: welcome, stranger
15:01:35 <ryansb> flwang1: no worries :)
15:01:45 <vkmc_> o/
15:01:50 * flaper87 hugs everyone
15:01:51 <Eva-i> o/
15:02:34 <flwang1> #topic zaqar client
15:03:26 <flwang1> for client side, could you guys help review https://review.openstack.org/253731 ? the pre-signed url patch
15:03:39 <flwang1> that's the only one function gap for client now
15:04:13 <vkmc_> weee
15:05:32 <flwang1> and this one https://review.openstack.org/265663 the claim support for v2
15:06:36 * ryansb reviewed already
15:07:24 <vkmc_> I'll check it out later
15:08:25 <Eva-i> flwang1: can python-zaqarclient not only create pre-signed urls, but use them?
15:09:28 <ryansb> I don't think so (yet) it's on my todo list
15:09:47 <flwang1> Eva-i: define use? we can discuss it offline
15:09:49 <ryansb> It would pretty much be a different auth backend
15:10:12 <Eva-i> okay, let's discuss it offline
15:10:29 <Eva-i> *lets
15:10:38 <flwang1> anything else for client side?
15:10:46 <ryansb> not from me
15:11:51 <flwang1> #topic zaqar server
15:12:49 <flwang1> we have two patches/blueprints need to discuss
15:13:13 <flwang1> 1. the PUT improvement for pool and flavor
15:13:43 <flwang1> 2. the TTL of subscription, though we have discussed it last week, but it would be nice if we can get some ideas from flaper87
15:14:10 <flwang1> flaper87: any comments for these?
15:15:35 <flwang1> https://review.openstack.org/#/c/238396/15 is a sample
15:16:35 <flwang1> the spec hasn't been approved, and i have a concern about this solution since it's breaking the idempotence of PUT method
15:16:36 * flaper87 clicks
15:16:49 <flwang1> ryansb: vkmc: Eva-i: comments?
15:16:52 <flaper87> I'll have to read through
15:17:53 <flwang1> flaper87: the short story is if we should throw a conflict error, when creating a pool/flavor but the name has been existed
15:18:13 <flaper87> flwang1: what's the current behavior ?
15:18:23 <flaper87> any change to the API that doesn't fix a 500 error is a breaking change
15:19:04 <flwang1> flaper87: current behaviour is always successful,  if there is an existing name, just update it
15:20:03 <flwang1> that said,   when there is an existing name, currently it returns 204/200,  after the change, user will see 409
15:20:06 <Eva-i> flaper87: I don't think we still call our API v2 stable, so we can make this change.
15:20:59 <Eva-i> also see the last paragraph: http://specs.openstack.org/openstack/api-wg/guidelines/http.html#xx-success-codes
15:24:10 <flwang1> i 'm still around... ;)
15:24:22 <Eva-i> Maybe we should make Zaqar behave like it is described in the paragraph. For this we have to check all pool/flavor fields. If the pool/flavor with the name exists, on put operation we should check it's fields. If the fields are same, we should provide 2xx code, else - 409 code.
15:25:43 <flwang1> PUT is not like POST, one of the attribute of PUT is the idempotence
15:25:49 <flwang1> that's my concern
15:28:47 <flwang1> that's why i prefer to fix it from the client side
15:29:07 <flwang1> checking the name conflicts by HEAD first
15:29:26 <flwang1> and throw the conflict error on the client side instead of server side
15:30:05 <flwang1> i don't really worry about the race condition issue since both of them are admin only endpoints
15:30:07 <flwang1> thoughts?
15:30:08 <Eva-i> flwang1: we use PUT method now to create flavor/pools. In this case is the idempotence possible?
15:30:57 <flwang1> based on current implementation, we can guarantee the idempotence
15:31:20 <Eva-i> flwang1: usually put is just for updating resources http://specs.openstack.org/openstack/api-wg/guidelines/http.html#http-methods
15:31:49 <flwang1> Eva-i: but for known name resource, PUT is the preferred way
15:32:57 <ryansb> flwang1: um, what do you mean?
15:32:59 <flwang1> Eva-i: see the link posted, the difference between POST and PUT
15:33:04 <flwang1> PUT should be used for resource creation when the URI to which the request is made and the URI of the resulting resource is the same.
15:33:35 <flwang1> That is, if the id of the resource being created is known, use PUT and PUT to the correct URI of the resource. Otherwise, use POST and POST to a more generic URI which will respond with the new URI of the resource.
15:33:58 <flwang1> --copy from above link :)
15:34:06 <Eva-i> aha, I see
15:37:05 <flaper87> Eva-i: no, we can't. It's not about the API being stable but released and public. It's not experimental anymore
15:38:03 <Eva-i> flaper87: have we released API v2 officially? It is public anyway, we're open-source project.
15:38:32 <flwang1> Eva-i: we did
15:38:43 <flaper87> Eva-i: of course we have, it's been in Zaqar since Kilo
15:39:09 <flwang1> flaper87: so you also prefer to fix it on client side, or just leave it as it's?
15:39:29 <flaper87> no, just leave it as is. clientlibraries shouldn't have any logic
15:40:10 <flwang1> ryansb: vkmc: comments?
15:40:45 <ryansb> flwang1: I agree that we've had the API out there, so changing it like this is probably not the way to go
15:41:41 <flwang1> ok, then we will reject the spec
15:41:59 <flwang1> but we do need a better doc for this
15:42:20 <flaper87> flwang1: lemme go through it and read it in more detail
15:43:04 <flwang1> flaper87: cool, pls leave your comments on this patch or the spec patch, personally, i don't want to change the api
15:43:19 <flwang1> if we would like to fix it, then it should be on the client side
15:44:21 <flwang1> ok, we can discuss more offline
15:44:43 <Eva-i> I think during Mitaka we have made few patches with APIImpact tag. Also I remember one patch was merged APIImpact tag, but it needed it.
15:44:56 <flwang1> another feature we would like to get more feedback is the TTL of subscription
15:45:15 <Eva-i> *was merged without APIImpact tag
15:46:02 <flwang1> flaper87: as u know, we have ttl for subscription. now there is a bug, so the subscription can't be deleted automatically
15:46:25 <ryansb> I'm still in favor of a finite-by-default subscription
15:47:08 <flwang1> flaper87: i have fixed it with patch https://review.openstack.org/270464, but i would like to get your opinion if we still need to support permanent subscription
15:47:14 <flwang1> ryansb: i know i know :D
15:47:48 * ryansb continues grumbling
15:48:01 <Eva-i> I'm okay now with eternal subscriptions, but not by default. I think the user must explicitly define permanent subscriptions.
15:48:07 <ryansb> ^that
15:48:11 * flaper87 clicks
15:48:22 <flaper87> ah, eternal subscription
15:48:27 <flaper87> yeah, definitely not the default
15:49:31 <flwang1> flaper87: the question is do we need it?
15:49:55 <flaper87> If you're asking that question the answer is already No.
15:50:13 <flaper87> Before adding these features or changing existing ones, there must be a use case for it
15:50:27 <flwang1> flaper87: we do
15:50:53 <flaper87> if the use case is not strong enough, then we should probably recommend not having it and re-subscribing whenever the subscription expires
15:50:57 <flwang1> ceilometer/aodh would like to get a permanent subscription until the alarm is deleted
15:51:18 <flaper87> then I think we're good
15:51:20 <flaper87> :D
15:51:32 <flaper87> (sorry, can't load the review, not sure what's going on with my connection)
15:51:38 <flaper87> (freaking third-world problems)
15:52:02 <flwang1> no worries, you got the idea
15:53:58 <flwang1> ok, the good news is the patch can support a very big TTL :)
15:54:11 <ryansb> 1 million year subscriptions, here we come
15:54:42 <flwang1> ryansb: the max date of python is 31/12/9999
15:54:49 <flwang1> now you can get it :D
15:54:50 <ryansb> hahaha
15:55:06 <flwang1> ok
15:55:13 <flwang1> we're running out of time
15:55:26 <flwang1> flaper87: thanks for the comments
15:55:36 <flwang1> #open discussion
15:55:40 <flwang1> anything else?
15:56:19 * ryansb has nothing
15:57:17 <flwang1> cool, thank you guys, leet's back to zaqar channel
15:58:08 <flwang1> #endmeeting