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