Thursday, 2018-12-13

*** mriedem has quit IRC00:01
*** bobh has joined #openstack-sdks00:19
*** tosky has quit IRC00:55
*** dave-mccowan has joined #openstack-sdks01:18
*** dave-mccowan has quit IRC02:14
*** Blotis has joined #openstack-sdks02:36
*** bobh has quit IRC02:37
*** bobh has joined #openstack-sdks02:38
*** bobh has quit IRC02:42
*** Blotis has left #openstack-sdks02:57
*** bobh has joined #openstack-sdks03:38
*** bobh has quit IRC03:39
*** bobh has joined #openstack-sdks03:40
*** bobh has quit IRC03:40
*** bobh has joined #openstack-sdks03:41
*** bobh has quit IRC03:57
*** jkulik has quit IRC04:02
openstackgerritRajat Dhasmana proposed openstack/python-openstackclient master: Fix: Restore operation returns 'VolumeBackupsRestore' object is not iterable
*** slaweq has joined #openstack-sdks06:57
*** Luzi has joined #openstack-sdks07:33
openstackgerritmachunnan proposed openstack/js-openstack-lib master: change http:// to https://
openstackgerritmachunnan proposed openstack/js-openstack-lib master: change http:// to https://
openstackgerritmachunnan proposed openstack/js-openstack-lib master: change http:// to https://
openstackgerritmachunnan proposed openstack/js-openstack-lib master: change http:// to https://
openstackgerritmachunnan proposed openstack/js-openstack-lib master: change http:// to https://
openstackgerritmachunnan proposed openstack/js-openstack-lib master: change http:// to https://
openstackgerritRajat Dhasmana proposed openstack/python-openstackclient master: Fix: Restore operation returns 'VolumeBackupsRestore' object is not iterable
openstackgerritmachunnan proposed openstack/js-openstack-lib master: change http:// to https://
openstackgerritmachunnan proposed openstack/js-openstack-lib master: change http:// to https://
openstackgerritmachunnan proposed openstack/js-openstack-lib master: change http:// to https://
openstackgerritmachunnan proposed openstack/js-openstack-lib master: change http:// to https://
openstackgerritmachunnan proposed openstack/js-openstack-lib master: Capitalizes the first letter -- should to Should
openstackgerritmachunnan proposed openstack/js-openstack-lib master: Capitalizes the first letter -- should to Should
*** jpena|off is now known as jpena09:04
*** ttsiouts has joined #openstack-sdks09:18
*** jpich has joined #openstack-sdks09:19
*** gtema has joined #openstack-sdks09:25
*** ttsiouts has quit IRC09:28
*** ttsiouts has joined #openstack-sdks09:29
*** ttsiouts has quit IRC09:33
*** noama has joined #openstack-sdks09:35
*** tosky has joined #openstack-sdks09:37
*** ttsiouts has joined #openstack-sdks09:40
*** e0ne has joined #openstack-sdks09:41
*** markvoelker has joined #openstack-sdks09:46
*** gtema has quit IRC10:01
*** cdent has joined #openstack-sdks10:42
*** ttsiouts has quit IRC10:51
*** ttsiouts has joined #openstack-sdks10:52
*** dtantsur|afk is now known as dtantsur10:53
*** ttsiouts has quit IRC10:57
*** tobias-urdin is now known as tobias-urdin_afk11:41
*** tobias-urdin_afk is now known as tobias-urdin11:42
*** tobias-urdin is now known as tobias-urdin_afk11:43
fricklermordred: Shrews: is there any news regarding the dogpile.cache issue to fix broken nodepool jobs?11:53
*** markvoelker has quit IRC12:24
*** gtema has joined #openstack-sdks12:36
*** mriedem has joined #openstack-sdks12:42
*** e0ne has quit IRC12:51
*** tobias-urdin_afk is now known as tobias-urdin12:53
Shrewsfrickler: mordred has a review up to requirements to limit the version. and morgan is going to look into the actual dogpile.cache change for us12:59
Shrewsthat's all i know before coffee13:00
*** gtema has quit IRC13:00
*** jpena is now known as jpena|lunch13:01
*** bobh has joined #openstack-sdks13:04
fricklerShrews: thx, found the reqs patch, seems that it needs a bug report/story attached. do we have a simple reproducer yet?13:09
*** markvoelker has joined #openstack-sdks13:10
Shrewsfrickler: i have one. 1 sec13:12
*** bobh has quit IRC13:18
fricklerShrews: thx, created!/story/2004605 from that and will add to the reqs patch13:30
fricklermordred: morgan: ^^ fyi13:31
*** e0ne has joined #openstack-sdks13:35
*** e0ne has quit IRC13:49
*** irclogbot_2 has quit IRC13:50
*** tosky has quit IRC13:56
*** e0ne has joined #openstack-sdks13:57
*** bobh has joined #openstack-sdks13:58
*** tosky has joined #openstack-sdks14:00
*** markvoelker has quit IRC14:03
*** irclogbot_2 has joined #openstack-sdks14:10
*** irclogbot_2 has quit IRC14:19
*** bobh has quit IRC14:27
*** ttsiouts has joined #openstack-sdks14:28
elmikoedleafe: ack, thanks14:33
*** irclogbot_2 has joined #openstack-sdks14:33
edleafeelmiko: it's brief14:33
elmikoyeah, but also contains good info imo14:34
cdentI thought it was elegantly sufficient14:34
elmikome too14:34
elmikoi like it, no objections here edleafe14:34
*** markvoelker has joined #openstack-sdks14:36
edleafeokie dokie14:38
elmikoedleafe: reading it over again, i think the only thing that might make me a tad nervous is that it sounds like we could answer all api related issues that come up. i wonder if that gives the impression that any project-specific api issues are fair game to ask the sig? (maybe i'm reading too much, maybe this isn't a concern)14:42
*** dayou has quit IRC14:43
cdentelmiko: to some extent that's supposed to be what SIG means14:44
cdentwe are a house for people who care about APIs14:44
elmikoi guess i meant more like, "hey this call to service X isn't working for me, why not? (insert arcane curl command here)"14:44
elmikoand i imagine we would definitely point that person in the right direction14:45
cdent"hey caller, it looks like you're using nova, you might want to talk to ..."14:45
* cdent puts on his paperclip costume14:45
elmikoanyways, it was just a thought. i don't think it's a concern, but if i pushed to make a critique.14:45
elmikoi still don't have an objection, i was just trying to go deeper with due diligence =)14:45
edleafeelmiko: Sorry, was afk14:51
edleafeI can see what you mean, but I kinda think that's a good thing. The more interest in the SIG, the better14:51
elmikoi like that attitude =)14:52
edleafeLike cdent said, we may not have the answers, but we might help point people to better resources14:52
elmikothanks for indulging me ;)14:56
*** dayou has joined #openstack-sdks15:00
cdentelmiko: speaking of indulgences, how did your aqua vit settle in at home. did it even make it home?15:11
elmikohaha, yes! it made it home15:12
elmikoit's been a big hit =)15:12
elmikopeople are becoming scared at the volume of clear liquors i am pushing on them when they visit XD15:13
cdenthere, try this mysterious thing!15:13
elmikoat least with the eau de vie they kinda get it, but when i start digging out stuff slike slivovice and awamori things get /interesting/ =D15:24
elmikothe liquor cabinet is starting to look a little nuts though, like "does this guy have a problem?" haha15:25
*** markvoelker has quit IRC15:38
*** Luzi has quit IRC15:52
*** bobh has joined #openstack-sdks15:53
*** ttsiouts has quit IRC15:56
*** ttsiouts has joined #openstack-sdks15:57
* elmiko sets down coffee mug16:00
edleafeAPI-SIG Office Hour has begun16:00
* elmiko rests feet on table16:00
edleafeGet your feet off the table!! Were you raised in a barn?16:00
* elmiko pulls feet down16:01
elmikosadly no, just a normal house16:01
edleafedtantsur: around? Wanted to get your feedback on
edleafeIt's the little blurb for the OpenStack Foundation Annual Report about our SIG16:03
* dtantsur reads16:03
dtantsuredleafe: sounds perfect to me16:03
edleafeThe only other issue I had was whether to freeze
dtantsuralso JFYI I'm off starting tomorrow, back in Jan16:04
edleafelucky you!16:05
edleafeI'm around all next week, then back 2nd week of Jan16:05
elmikoi'll be around next week as well16:05
* dtantsur has stated his opinion re 61661016:06
edleafedtantsur: so you would prefer to interpret DELETE as "find this resource, and then delete it"16:07
edleafeinstead of "make sure this resource doesn't exist"16:07
dtantsuredleafe: "delete this resource", yes16:07
*** jpena|lunch is now known as jpena16:08
dtantsurI think if somebody is actually going to follow this guideline, it's going to be confusing for users16:09
dtantsure.g. `rm /foo` actually errors out16:09
*** morgan is now known as kmalloc16:09
edleafeSo consider this scenario: resource `foo` exists. Two users call DELETE /rsrc/foo. One should get 204, and the other 404?16:10
elmikoi think the only weird part to me is how long should that behavior persist after the delete?16:14
kmallocShrews: now that my massive headache of doom has passed, i should be able to look at dogpile and the other issues outstanding16:14
elmikolike, if i delete a resources ages ago, when should the server respond with a 404?16:15
kmallocShrews, mordred: ^ thanks for bearing with me yesterday.16:15
elmikoor should it ever? which implies keeping track of delete resources for the purposes of delete responses16:15
edleafeRFC 7231 says that DELETE is idempotent:
dtantsurtracking deleting resources is quite a change to many database models16:15
*** ttsiouts has quit IRC16:16
dtantsuredleafe: that's one of the reasons HTTP is not a great match for API..16:16
* dtantsur shrugs16:16
kmallocedleafe: oh good to know.16:17
kmallocedleafe: also... damn that means keystone has messed up a bunch.16:17
* kmalloc makes note for v4.. when that comes.16:17
elmikoedleafe: such a weird knot this is, it should be idempotent, but does that mean it should always return some 2XX for a previously deleted resource?16:18
elmikoi mean, i know that's what we are proposing i'm just exploring the idea a little more16:18
dtantsuryeah, this is a weird point16:18
edleafeThe impetus for adding this guideline is that it is assumed that an API has one implementation, but many, many consumers. Attempting to delete a resource that doesn't exist requires an exception handler. If you can return a 404 from the API, every single consumer of that API has to build code to handle that16:19
edleafeelmiko: why not?16:19
edleafe"I don't want resource foo to exist" "OK, it doesn't exist"16:19
dtantsur"In effect, this method is similar to the rm command16:20
dtantsur   in UNIX: it expresses a deletion operation on the URI mapping of the16:20
dtantsur   origin server rather than an expectation that the previously16:20
dtantsur   associated information be deleted.16:20
dtantsurI don't know how to interpret it..16:20
elmikoedleafe: it just makes me wonder what the impl starts to look like, for example do i need to keep a database table of delete resources to properly respond to all future delete requests?16:20
edleafeelmiko: why?16:20
dtantsuredleafe: the "very single customer" is simply incorrect16:20
elmikoif i delete some resource /foo/bar16:20
dtantsurI personally very rarely catch 404 from deletions because I *want* to know that something went south16:21
elmikothen later a request comes in to DELETE /foo/bar, then i need to respond 2XX if it has been deleted. is that accurate?16:21
edleafeelmiko: if you call DELETE /foo/bar, and `foo` is a valid resouce class, you return 204 whether or not you had to delete resource `bar` or not. You don't need to confirm that `bar` ever existed.16:22
edleafedtantsur: that's very different than "I want this resource gone"16:23
edleafedtantsur: if you care that it's there and getting deleted, do a GET/HEAD on it first16:23
dtantsurwell, "I want this resource gone" is not the semantic I use, so no wonder :)16:23
elmikoedleafe: what if "bar" never existed as a foo?16:23
elmikoshouldn't that be a 404?16:23
edleafeelmiko: No16:23
dtantsuredleafe: so instead of handling 404 by some consumers, some other consumers have to make 2 requests?16:23
elmikoah, i misunderstood you then16:24
edleafeif you interpret delete as "I don't want resource bar to exist"16:24
*** noama has quit IRC16:24
dtantsurthen we should allow 'DELETE /some/nonsense' :)16:24
dtantsurhalf-kidding, but the same logic can be applied to invalid URLs16:24
edleafeIf you care about the existence of a resource, you call GET or HEAD16:24
kmallocit's fine to say DELETE X and if the path is unrouted, get a 40416:24
dtantsurkmalloc: why? I want it to be gone, and it's gone16:25
edleafedtantsur: cdent clarified that. Just what kmalloc said16:25
kmallocthat would be a method not allowed16:25
kmallocsorry, wrong error16:25
dtantsuredleafe: not for me16:25
kmallocnot 404, 40.. 405?16:25
elmikokmalloc: if it's possible that the resource _could_ have existed, then it should 404. if i understand edleafe's point16:25
elmikoer should not!16:25
kmallocelmiko: right16:25
* dtantsur starts leaning toward a proper -1 now16:26
kmallocelmiko: it should be .. 200/204/2XX (not 201)16:26
edleafeGenerally 204 is returned from DELETE16:26
kmallocif delete is not allowed, e.g. the whole path is unrouted in an api16:26
edleafeThere is no response body16:26
kmallocXXXX/<resource> -> where XXXX is not a thing at all16:26
kmallocthat should be 40516:26
kmallocas DELETE is not supported16:27
kmallocbut if XXXX is a thing, and there could be a resource under it16:27
edleafekmalloc: according to cdent, it's 40416:27
dtantsurwhat about GET XXXX?16:27
* edleafe keeps hoping to invoke the spirit of cdent with these repeated incantation16:27
kmallocedleafe: in most of openstack 404 is a thing.16:27
cdentsorry, I'm debugging a gate failure16:27
kmallocmost of openstack is wrong16:27
kmallocfrom a standpoint of the RFC16:27
edleafedtantsur: GET /XXXX should also be 40416:28
cdentonly if XXXXX/<resource> has any methods at all should it ever be a 405 on delete16:28
cdentif it simply does not exist then it should be 40416:28
kmalloci could see that interpretation16:28
dtantsurkmalloc: well, we're talking of taking an RFC designed for hypertext and applying it to API16:28
kmallocorder of precidence on routing16:28
cdentkmalloc: that interpretation is right :)16:28
edleafeFrom the front page of our guidelines: "Note Where this guidance is incomplete or ambiguous, refer to the HTTP RFCs—RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, and RFC 7235—as the ultimate authority."16:28
dtantsurthis has gone wrong many times, this is no exception16:28
cdentthe URI is the primary thing16:28
kmallocXXX is checked before XXXX/YYYY16:29
kmallocso, XXX hits 40416:29
cdentif there is _nothing_ that has that URI, then 40416:29
cdentif you can GET it, but can't delete it, then 40516:29
kmallocbut a 404 on a delete where a resource could exist is explictly wrong16:29
kmallocit's always a success if delete could work16:30
*** e0ne has quit IRC16:30
kmalloccdent: ++ don't have to convince me too hard on that front :P16:30
cdentthat's effectively what ed's thing say16:30
edleafekmalloc: that's what the point of is16:30
cdentif this is a valid uri, and there might have been a thing here, or ever will be, respond 204 on delete when it is not there, or has just been removed16:30
cdentbut if the url is invalid because you can't even GET there, then 40416:30
*** e0ne has joined #openstack-sdks16:30
kmalloci could see that, i'll have to go poke and see how flask handles it16:31
kmalloci think it does it the correct way16:31
kmallocwhat you just described16:31
kmallocbecause if not, i have some bugs to go open/fix16:31
elmikoedleafe: fwiw, i'm still +1 on the review16:31
* edleafe wipes brow16:31
elmikoseems like dtantsur will be the -116:31
edleafeOne thing to keep in mind before you -1:16:32
edleafeThis is a guideline; it says what projects should ideally follow16:32
edleafeWe are trying to encourage new projects to follow them. Existing projects do not have to change16:33
kmalloci know if we iterate on the keystone api like I want to, we'll get to where we're more closely following the guidelines16:34
kmallocwe just have a ton of history that... well we can't "just fix"16:34
edleafekmalloc: sure, that's reasonable.16:34
elmikokmalloc: totally understandable16:34
elmikoto echo edleafe, these are guidelines and not laws16:34
kmallocalso we don't have (and doesn't look like we will in the near-to-medium term) microversions :)16:34
kmallocalso +1 on that change. I like the guidelines16:35
edleafekmalloc: the other purpose of the guidelines is to "settle arguments". If a change is being considered, and there are differing views, the guidelines can be used as an arbiter16:35
elmikoimo, microversions seem less contentious. but i'm just one person16:35
edleafeelmiko: lol16:35
elmikoedleafe ++16:35
kmalloci'd like to really outline the use of 405 in that doc.16:35
kmallocbecause it is useful.16:35
kmallocbut that is a bigger bundle of "lots of comments"16:35
dtantsurmicroversions are not contentious at all, just do them16:35
* dtantsur ducks16:35
elmikodtantsur: LOL16:36
kmallocdtantsur: ok, go implement it for keystone, i think you just volunteered :) :P :P :P16:36
dtantsurhow many years it took us to implement proper negotiation in OSC? oh wait, it's still not there? :)16:36
edleafeThere is a paragraph there on 40516:36
kmallocedleafe: yes, but i think that needs some expansion16:36
edleafepatches welcome!  :)16:37
kmallocyes, it's on my long long long list16:37
dtantsurkmalloc: I'll switch keystone to SOAP16:37
kmallocdtantsur: if you can get people to approve it... and not break our API contracts, go for it16:37
kmallocdtantsur: i'll even volunteer to not -2 that change16:37
kmallocor even -1 it.16:37
edleafeI think we should add a guideline that recommends abandoning the term "microversions", and replaces it with "every change is a major version"16:37
dtantsurSOAP never greaks contracts, it's enterprise-grade16:37
dtantsuredleafe: /me imagines $ curl
dtantsurit's mostly kidding again, but I do feel bad that we break RESTfulness with microversions16:38
* elmiko shudders at the mention of SOAP16:40
elmikobut then i am a smelly hippy, so there is that XD16:40
dtantsurI got some funny experience with it16:40
elmikoif you had "fun" anywhere near SOAP then you are doing better than most ;)16:40
dtantsurIt's supposed to be interoperable, but in fact I could not make a SOAP client in Java talk to a SOAP server in Python16:40
dtantsurthey had different SOAPs apparently16:40
edleafeI made a python SOAP server talk with a .NET client16:41
* edleafe remembers when XML was going to solve all our problems16:42
dtantsuryeah, except for the problem "how to serialize a list". this one is unsolvable. something between "what's the point of life" and "where is my 2nd sock".16:42
cdentdtantsur: which of many aspect of REST do we break with microversions. I suspect we could come up with several depending on which rules we wanted follow16:42
cdentdtantsur: also I'm pleased to see you sticking to your guns with -1 the DELETE thing. I think it is important to get it not just right but agreed on and you raise some good points.16:43
dtantsurcdent: the one where a URI points to a resource. with microversions a URL can mean anything (or nothing at all) depending on a header16:43
*** tosky has quit IRC16:43
dtantsure.g. I cannot say /v1/portgroups/<UUID> is a representation of a portgroup <UUID>16:43
dtantsurbecause it's only the case if microversion>=1.<something>16:44
*** tosky has joined #openstack-sdks16:44
* edleafe dislikes versions in both URI and header16:44
elmikoedleafe: heh, xml actually /solving/ problems... XD16:44
dtantsurthis defeats e.g. the "Location" header to a degree, since "Location" is meaningless without a microversion to use it with16:45
dtantsuredleafe: I guess from the pure RESTful point of view we had to put them in the URL somewhere.. I know that it has other problems :)16:45
cdentdtantsur: yeah, I feel really bad about URIs that exist in microversion N+1 but not N. It's dirty.16:46
edleafeI believe that the original practice of using /v1-type URLs was because the original OpenStack devs always did it that way, and so continued the practice. It was never debated16:46
cdenttheir existence has allowed us to get away with some things that we would have considered much more strongly if they didn't16:47
cdentuntil placement, yo16:47
* cdent tried to resist microversions in placement too16:47
edleafecdent: that's why I really hate the term "microversion". It's anything but micro16:47
edleafeor, you know, "version"16:48
dtantsurif we were less hipster, we would just use "API version"16:48
elmikocdent: lol16:48
edleafethe only difference with microversions is that we simultaneously support many, many possible versions16:48
elmikoi like "really-hugeo-version", it has a nice ring to it. would make debates much more lively16:49
elmikobut, i am a fan of absurdism16:50
dtantsurthen we also have to be creative with numbers themselves16:51
elmikoooh, nice16:52
edleafewe should use random integers for our versions.16:53
dtantsurwhat about multiplying 3.14 by 1.X where X is a number of changed strings in the patch introducing the microversion?16:53
edleafedtantsur: too much work16:53
edleafeWe could just follow git's lead and make the version a hash of the codebase16:54
*** jpich has quit IRC16:54
elmikoedleafe: haha, <3 random integers16:55
dtantsurnice! it will add a pleasant task of figuring out how to put a hash in the file being hashed16:55
dtantsuror we could get boring and use the current date and time16:55
elmikoi love it, we can have a new middle to handle to upgrade that all projects must follow to become compliant with the new randoversions16:55
edleafedtantsur: no problem. Internally you do a 'git checkout {hash}' and then run the request through that16:55
elmikoreally randoversioning is an upgrade, because it helps project maintainers know who is _really_ following the project16:56
elmiko"i'm using the latest, version 3831923", "ah ah, didn't you know the latest is actually 92359841?!?"16:57
edleafeSo not only could we replace 'latest' with 'HEAD', we now have access to 'HEAD^', 'HEAD^^', etc16:58
dtantsurfolks, you keep forgetting that in year 2018 we *must* be mobile-friendly16:58
dtantsurso I recommend we start using smiles in versions16:58
dtantsur* smileys16:59
edleafeBetter yet: animojis!16:59
elmikohaha, perfect17:00
elmikodtantsur: micromoji-versioning?17:00
edleafeI guess our office hour is up.17:00
elmikoah well17:00
elmikohave a good weekend y'all =)17:01
dtantsursee you in January :)17:01
dtantsurhappy holidays17:01
elmikoenjoy dtantsur !17:01
edleafeelmiko: mobile devices are getting bigger, so let's not use 'micro'17:01
elmikoedleafe: good point17:01
edleafeSee ya, dtantsur! Enjoy your time off!17:01
*** bobh has quit IRC17:01
* cdent blinks17:02
edleafecdent: So are you on board with replacing versions with git hashes?17:03
cdentonly if we do the git checkout bit internally, and only from a remote repo17:04
*** bobh has joined #openstack-sdks17:05
edleafeIf we put versions in the URI, we could have GET /v91b735fddedbeb9d1cc241dadc753ff2f3b86a4b/foo/bar17:05
edleafeUsers would love that!17:06
cdentthat looks suspiciously similar to user/project/tenant/whatever it was in URIs17:06
cdentwhich was an equally bad idea17:06
elmikoi'm gonna grab some lunch, catch you gents later o/17:07
*** bobh has quit IRC17:10
*** bobh has joined #openstack-sdks17:12
*** bobh has quit IRC17:16
*** dtantsur is now known as dtantsur|afk17:27
*** bobh has joined #openstack-sdks17:51
*** e0ne has quit IRC18:11
*** e0ne has joined #openstack-sdks18:15
*** e0ne has quit IRC18:16
*** jpena is now known as jpena|off18:38
*** e0ne has joined #openstack-sdks19:53
*** tosky has quit IRC19:56
*** tosky has joined #openstack-sdks19:57
*** e0ne has quit IRC19:58
*** gtema has joined #openstack-sdks20:12
*** bobh has quit IRC20:28
*** bobh has joined #openstack-sdks20:48
*** bobh has quit IRC20:52
*** mriedem has quit IRC21:02
openstackgerritThomas Bechtold proposed openstack/openstacksdk master: Drop self.conn from base.TestCase
*** markvoelker has joined #openstack-sdks21:11
*** gtema has quit IRC21:11
*** mriedem has joined #openstack-sdks21:26
*** tobias-urdin has quit IRC21:32
*** bobh has joined #openstack-sdks21:54
*** bobh has quit IRC22:00
*** markvoelker has quit IRC22:06
*** bobh has joined #openstack-sdks22:15
*** lbragstad has quit IRC22:37
kmallocmordred: the SDK issue, are you seeing that on master or on pip isntalled?23:08
kmallocmordred: because i can't duplicate it on the current release23:08
kmallocmordred: the discovery bit23:08
kmallocmordred: i just tried with vexxhost:23:09
kmallocmordred: using pretty much your code:23:10
kmallocmordred: i omitted the auth request.23:10
kmallocmaybe you're hitting the unversioned URL?23:11
kmallocnope, also not seeing that there.23:11
Shrewskmalloc: you gotta enable the cache part23:12
kmallocShrews: bah.23:13
Shrewskmalloc: steps to reproduce are here:!/story/200460523:13
Shrewskmalloc: unless there is a different issue you are talking about  :)23:13
kmallocno different thing23:13
Shrewsoh, sorry23:13
kmallocShrews: i was looking at the duplicate discovery bit first23:13
kmallocShrews: and i can't duplicate that.23:13
kmallocsince that one might be something wrong in KSA.23:13
Shrewskmalloc: i am no help there23:14
kmallocyeah, will need mordred to weigh in on duplication, it just isn't happening for me.23:14
kmallocon to the dogpile thing.23:14
ianwkmalloc: yeah, i'm taking a look at it too ... wow it's hairy23:18
ianwthe change is
ianwi can sort of replicate it.  i think in the unit tests, somehow it's getting eaten23:20
ianwbut if you put more failures in there, you see it23:20
kmallocShrews: on another unrelated note23:22
kmallocShrews: ^ hehehe 3x portrait mode monitors = win for code!23:23
kmallocianw: yeah it's weird.23:24
Shrewskmalloc: sick23:25
*** tosky has quit IRC23:27
kmallocShrews: i'm not able to duplicate that issue23:33
kmallocwith dogpile 0.7.0 or 0.7.123:33
kmalloci must have something broken in my clouds.yaml23:33
kmallocooh wait.23:34
kmallocnope. hmmm.23:35
kmallocthere we go23:37
kmallochmm. this is why i usually use settr() instead of = for setting values, especially on python structures.23:39
*** slaweq has quit IRC23:40
*** mriedem has quit IRC23:41
ianwso the original decorator wrapped the function, which is actually in this case a bound method23:45
ianwnow it uses "decorate"23:45
kmallocwhich means that __get__ is looking at .. i think something else here.23:45
kmallocyeah, i'm not super familiar with decoratte, that might eat things.23:45
ianwi think the __get__ is right -- that's returning the bound method23:46
ianwe.g. if we're calling self.list_users()23:46
ianwit's the list_users() method of self23:46
kmallocright. but we're failing when it comes to doing the .set = set_23:46
ianwthen it's essentially calling "cache_on_arguments(self.list_users)"23:47
kmallocso, with decorate module we might be getting something else back from the __get__ that is resulting on the failure.23:47
ianwwell it hasn't got to that point yet23:47
ianwit's assuming it can set "func.set = ... something"23:47
kmallocthe traceback i see is23:47
ianwwhich you can't do on a bound method23:47
kmallochmm.. i wonder.23:48
ianwok, we're talking about the same traceback at least :)23:48
ianwsplitting it up helps i think23:49
kmalloci think i see what is going on23:50
ianwin the old decorator, it would use @wraps(fn) on the incoming user function23:50
kmallocdogpile makes the broad assumption it is  doing the wrapping23:50
kmallocnot getting magic instantiated things23:51
kmallocbound methods.23:51
ianwyes ... probably a fair assumption :)23:51
kmallocwe're probably doing it wrong.23:51
ianwsorry i've got to step out for about 30 minutes for a meeting.  i'll be back23:52
kmallocyeah np.23:52
kmallocianw: the solutions are pretty straightforward (cc Shrews, mordred): 1) dogpile reverts, 2) we stop wrapping on-demand, and we lean on something similar to a "should_cache_fn", or always wrap and just lean on the null backend by default, 3) same as 2, but we use should_cache_fn to control if caching is enabled.23:54
kmalloci think dogpile is probably making the sane assumption it should be allowed to control wrapping.23:55
kmalloci think we should just always wrap, and let dogpile do that, instead of wrap the bound method.23:56

Generated by 2.15.3 by Marius Gedminas - find it at!