Friday, 2020-08-28

*** jmlowe has quit IRC00:21
*** jmlowe has joined #openstack-glance00:23
*** whoami-rajat__ has quit IRC00:50
*** jv__ has joined #openstack-glance00:52
*** k_mouza has joined #openstack-glance00:52
*** k_mouza has quit IRC00:56
*** jv__ has quit IRC01:08
*** Liang__ has joined #openstack-glance01:19
*** baojg has joined #openstack-glance01:47
*** baojg has quit IRC01:50
*** gyee has quit IRC01:58
*** rcernin has quit IRC02:56
*** whoami-rajat__ has joined #openstack-glance02:57
*** rcernin has joined #openstack-glance03:04
*** jdillaman has quit IRC03:29
*** baojg has joined #openstack-glance03:31
openstackgerritMerged openstack/glance master: Disable wait_for_fork() kill aggression if expect_exit=True  https://review.opendev.org/74799103:34
*** baojg has quit IRC03:35
*** rcernin has quit IRC03:35
*** Liang__ has quit IRC03:37
*** Liang__ has joined #openstack-glance03:38
*** rcernin has joined #openstack-glance03:39
*** rcernin has quit IRC03:54
*** ratailor has joined #openstack-glance03:58
*** rcernin has joined #openstack-glance04:08
*** rcernin has quit IRC04:18
*** rcernin has joined #openstack-glance04:19
*** evrardjp has quit IRC04:33
*** evrardjp has joined #openstack-glance04:33
*** udesale has joined #openstack-glance05:48
*** Liang__ has quit IRC06:01
*** Liang__ has joined #openstack-glance06:04
*** Liang__ has quit IRC06:57
*** belmoreira has joined #openstack-glance07:01
*** irclogbot_2 has quit IRC07:13
*** Luzi has joined #openstack-glance07:37
*** ralonsoh has joined #openstack-glance07:59
openstackgerritzhufl proposed openstack/glance master: [Trivial]Add missing print parameters in log messages  https://review.opendev.org/74858508:14
*** Luzi has quit IRC08:40
*** Liang__ has joined #openstack-glance09:09
*** ralonsoh_ has joined #openstack-glance09:21
*** ralonsoh_ has quit IRC09:21
*** ratailor has quit IRC09:30
*** k_mouza has joined #openstack-glance09:39
*** Liang__ has quit IRC10:04
*** Liang__ has joined #openstack-glance10:05
*** Liang__ has quit IRC10:07
*** jv__ has joined #openstack-glance11:22
*** udesale has quit IRC11:39
*** udesale has joined #openstack-glance11:43
*** k_mouza has quit IRC11:43
*** udesale has quit IRC11:47
*** udesale has joined #openstack-glance11:48
openstackgerritVladyslav Drok proposed openstack/glance_store master: [RBD] Parallelize writes on image creation  https://review.opendev.org/74860711:55
openstackgerritMerged openstack/glance stable/ussuri: Fix import failure status reporting when all_stores_must_succeed=True  https://review.opendev.org/74801211:56
openstackgerritMerged openstack/glance stable/ussuri: Fix non-deterministic copy_image_revert_lifecycle test  https://review.opendev.org/74823911:56
openstackgerritMerged openstack/glance stable/ussuri: Poll for final state on test_copy_image_revert_lifecycle()  https://review.opendev.org/74824011:56
openstackgerritMerged openstack/glance stable/ussuri: Add context.elevated() helper for getting admin privileges  https://review.opendev.org/74801311:56
openstackgerritMerged openstack/glance stable/ussuri: Implement time-limited import locking  https://review.opendev.org/74801411:56
*** jv__ has quit IRC12:38
*** rcernin has quit IRC12:56
*** jv__ has joined #openstack-glance13:09
*** k_mouza has joined #openstack-glance13:27
*** jv__ has quit IRC13:48
*** k_mouza has quit IRC13:49
*** k_mouza has joined #openstack-glance13:54
*** udesale has quit IRC13:54
dansmithabhishekk: I always thought get_flow() was run synchronously with the API call, but the log I'm looking at makes it seem like that is *not* the case...14:00
*** k_mouza has quit IRC14:18
*** k_mouza has joined #openstack-glance14:20
abhishekkdansmith, right that's not the case14:46
dansmiththat's unfortunate14:47
abhishekkwhy is that, I am still going through your comments on tempest patch14:50
dansmithwell, because there's really no reliable prep work done during the API call, and because you can't even depend on the os_glance_importing_to_stores to have been initialized after the API request is done14:51
dansmithI get that 202 lets you disavow all responsibility for the behavior, and that it makes it easier to not commit to anything,14:51
dansmithbut if people have a hard time writing solid client code for your API because you didn't make any guarantees, it's likely to frustrate everyone14:52
dansmithin a lot of cases, the people writing client code for a cloud service aren't going to be as skilled as those writing the actual service, so making the workflow as predictable and understandable as possible just generally increases the ability for people to consume your service14:53
dansmith(I'm using "you" in the royal sense here, not _you_ specifically)14:53
abhishekk(got it)14:54
dansmith(good :P)14:54
abhishekkSo, I think they have task_id with them at that moment, righjt?14:54
abhishekkcan't they  use that task_id to see the status of task?14:55
dansmithonly now that we've added the lock, and only if you're an admin AFAIK14:55
abhishekkI got your point though how frustrating this will be14:55
dansmithgmann is a pretty skilled api client author, so he's a very good data point on the best you will expect from other people doing it14:57
dansmithand even I thought it was synchronous from writing my own tests for it, and being familiar with the code, despite losing track of the actual task creation through the layers of the onion14:57
abhishekkonion it is, its not that easy as you see14:58
dansmithI do think that maybe making tasks open to the users that created them might be a good thing to work on for W14:58
abhishekk+1, I am going to add that in the discussion list14:59
dansmithI haven't looked at what all would be required for that, but as rosmaita suggested, returning a handle to a task-id directly from the import call without them even having to look at the task lock field would be nice14:59
dansmithcool, because as you saw from some of my synchrinous api tests, I had to use that to keep track of things14:59
dansmith*synchronous14:59
abhishekkYes14:59
gmannyeah, i was checking it from 'store' in initial test writing and then switched to 'os_glance_importing_to_stores' by seeing it from the API response from other import call15:00
dansmithyeah15:01
dansmith202 doesn't mean you can't do anything useful before the API call returns, but I think people too often use 202 as a "I have made no promises so I can make all the stuff after the 202 totally fragile"15:01
gmanncannot we return some 'unknown' or 'empty list' for this field which can be assumed as ' you need to wait for some other status to decide anything on requested operation with 202'15:02
dansmithwell,15:03
dansmiththe way it works on the server side is that an image doesn't even have that key until the first time it's set by an import task15:03
dansmithI thought that the task setup was called synchronously since we get the task_id right away, and that's what creates it,15:03
dansmithbut apparently that can happen async and all we have is the task_id by the time we return15:03
dansmithif we make the API initialize those fields, it needs to do so before the task could start running so we don't race, but after we gain the lock for the image15:04
gmannyeah but 'not-started' or 'empty list' or some more good name can also be interpreted as 'no import started/requested' or 'completed yet'15:05
dansmithso, yeah, we could, but I'm not sure it's better because it'll then just be an empty list and if your code runs until the "in progress" list is empty,15:05
dansmithyou'd exit immediately15:05
dansmithnot really, because ^15:05
dansmiththe change I made this morning uses the "list not even present yet" to indicate we should keep polling15:05
dansmithi.e. "if the list is present *and* it's empty, then we're done"15:05
gmannyeah but that has to be done on client side which many clients/scripts get confused and drop the idea of monitoring this dynamically added field (same you mentioned in initial chat)15:07
dansmiththis was my point about this being hard for the user to reason about, not knowing all the details in the backend.. they have to learn by experimentation that they need to account for all these states" when it appears from the API docs that all they need to do is wait for the store to disappear from the "in progress" list and then check "failed" or "stores" to determine success15:07
gmannexactly15:07
dansmithgmann: yeah, that's why the right fix would be to have the list set properly on API return15:07
gmannyeah.15:11
abhishekkthat's also need to set once lock is acquired15:12
dansmithbut before we start the task,15:13
dansmithwhich we can't really do, AFAIK15:13
dansmithbecause we can't set the lock until we have the task_id,15:13
abhishekkyes, difficult with current design15:14
dansmithbut after we have the task_id, the task could be running, and we don't want to race15:14
abhishekkright15:14
abhishekksmcginnis, when you get some time, please look at this chain https://review.opendev.org/#/c/745566/915:14
*** belmoreira has quit IRC15:17
*** rosmaita has quit IRC15:22
*** rosmaita has joined #openstack-glance15:25
* abhishekk dinner break15:35
* abhishekk back16:18
*** k_mouza has quit IRC16:19
*** k_mouza has joined #openstack-glance16:38
*** ralonsoh has quit IRC16:48
*** k_mouza has quit IRC16:48
*** k_mouza has joined #openstack-glance16:49
*** k_mouza has quit IRC16:53
openstackgerritMohammed Naser proposed openstack/glance_store master: Drop snapshot in use log from ERROR to WARN  https://review.opendev.org/74872317:15
mnaserdansmith: ^ a trivial make-life-easy thing that we started catching since we started logging all errors in openstack servies17:16
dansmithit's about to raise, so error would generally be expected there.. does that get caught and retried somewhere?17:17
abhishekkno17:19
dansmithlooks like it's going to log error anyway on L620 right?17:19
dansmither, no, that's something else17:20
openstackgerritMohammed Naser proposed openstack/glance_store master: Drop snapshot in use log from ERROR to WARN  https://review.opendev.org/74872317:20
dansmithabhishekk: your "no" was for what, retried?17:22
abhishekkdansmith, yes17:22
dansmithabhishekk: does that raise cause a stack trace in the logs?17:22
abhishekkdansmith, No, its caught at glance side17:24
dansmithyeah I see, which logs as warning also17:24
abhishekkwarning is logged there and 409 is raised17:24
abhishekkmnaser, you need to change that message from _LE to _LW as well17:25
mnaserdansmith: yeah it's caught by glance and handled just fine, but it would end up showing up as an error log message (where tbh it should be more of a warning)17:25
mnaserIMHO error should be operator actionable, this usually isn't17:25
dansmithyeah, I see17:26
openstackgerritMohammed Naser proposed openstack/glance_store master: Drop snapshot in use log from ERROR to WARN  https://review.opendev.org/74872317:26
mnaserabhishekk: ^ addressed that there17:26
abhishekkmnaser, ack, thank you17:27
* abhishekk signing out for the day, have a nice weekend all o/17:36
*** whoami-rajat__ has quit IRC18:56
*** whoami-rajat__ has joined #openstack-glance20:17
openstackgerritMerged openstack/glance_store master: Drop snapshot in use log from ERROR to WARN  https://review.opendev.org/74872320:40
-openstackstatus- NOTICE: A zuul server ended up with read only filesystems which caused many jobs to hit retry_limit. The server has been rebooted and appears happy. Jobs can be rechecked.22:13
*** whoami-rajat__ has quit IRC22:46
*** rcernin has joined #openstack-glance23:10
*** rcernin has quit IRC23:15

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!