Wednesday, 2019-08-28

*** larainema has joined #openstack-oslo01:00
*** threestrands has joined #openstack-oslo01:39
*** ianychoi has quit IRC03:29
*** ianychoi has joined #openstack-oslo03:30
*** njohnston has quit IRC04:35
*** dave-mccowan has quit IRC04:40
*** jhesketh has quit IRC05:34
*** jhesketh has joined #openstack-oslo05:42
*** Luzi has joined #openstack-oslo05:46
*** lpetrut has joined #openstack-oslo06:00
*** trident has quit IRC07:08
*** rcernin has quit IRC07:12
*** trident has joined #openstack-oslo07:17
*** tosky has joined #openstack-oslo07:40
*** ralonsoh has joined #openstack-oslo08:24
*** jaosorior has quit IRC08:28
*** jaosorior has joined #openstack-oslo08:29
*** jaosorior has quit IRC08:46
*** jaosorior has joined #openstack-oslo09:31
*** tesseract has joined #openstack-oslo11:12
*** boden has joined #openstack-oslo11:42
*** jaosorior has quit IRC11:58
openstackgerritMerged openstack/oslo.utils master: Add digestmod when using hmac  https://review.opendev.org/67777012:09
*** jaosorior has joined #openstack-oslo12:11
openstackgerritMerged openstack/oslo.service master: Move doc related modules to doc/requirements.txt  https://review.opendev.org/66940812:19
*** larainema has quit IRC12:30
*** kgiusti has joined #openstack-oslo12:44
*** dkehn has quit IRC12:53
*** boden has quit IRC12:58
*** dave-mccowan has joined #openstack-oslo13:10
*** boden has joined #openstack-oslo13:20
*** tosky has quit IRC13:30
*** tosky has joined #openstack-oslo13:30
*** openstackgerrit has quit IRC14:22
*** amotoki_ has quit IRC14:34
*** tosky_ has joined #openstack-oslo14:34
*** tosky has quit IRC14:34
*** tosky_ is now known as tosky14:35
*** amotoki has joined #openstack-oslo14:35
*** Luzi has quit IRC14:40
*** lpetrut has quit IRC14:52
*** lpetrut has joined #openstack-oslo15:15
efriedbnemec: Okay, so what is the expected behavior if I'm blasting a ton of messages to the privsep daemon and it shuts down?15:17
efriedI would think15:18
efrieda) any messages I had already sent, but had not yet been processed by the time the daemon is gone, should legitimately raise this IOError; and15:18
efriedb) any messages I send after that should trigger the new behavior and restart the daemon.15:18
efriedIn other words, seeing that IOError for a) is legit as currently written... no?15:19
* efried has idea...15:19
bnemecefried: I agree, if the daemon dies while a message is being processed the client wil have to get an error back.15:21
bnemecAlthough in the SIGHUP case it might be nice to have a graceful shutdown that stops accepting new connections and finishes any existing work.15:21
efriedbnemec: I'm thinking ^ ...unless our _wrap traps IOError and retries, recreating the daemon.15:22
efriedwell *that* didn't work at all.15:23
bnemecYeah, that was kind of my intent with the retry in https://review.opendev.org/#/c/678653/4/oslo_privsep/priv_context.py15:23
efriedbnemec: but you're retrying on OSError -- what were you trying to catch there, the EPIPE?15:24
bnemecI think I saw two different cases, one plain OSError and something that inherited from OSError.15:24
efriedI was thinking we should make a wrapper around IOError (so we can tell it apart from an IOError raised by the actual priv'd function) and raise that instead of plain IOError in ClientChannel._reader_main when the loop breaks.15:25
bnemecBut I think it would be reasonable to expand what we retry on. There's little harm in making another call.15:25
efriedat that point are we guaranteed that we didn't actually attempt the privileged function?15:25
efried...yeah, looks like it.15:26
bnemecJust for kicks, I tried to change the except OSError to an except Exception and it seems to make the functional tests pass in parallel.15:28
efriedheh15:29
efriedbnemec: won't that also mask any exception from the privileged command itself?15:30
bnemecYeah, we don't want to actually do that.15:30
efriedum, worse than mask, cause us to retry it indefinitely15:30
bnemecI just wanted to see if it would work.15:30
efriedIn fact, even the OSError could conceivably do that, no?15:30
bnemecThe retry isn't a loop though, so it will only ever retry once.15:30
efriedmm15:31
efriedbnemec: Looking at this guy https://opendev.org/openstack/oslo.privsep/src/branch/master/oslo_privsep/daemon.py#L467-L48915:37
efried...we can't tell the difference between IOError from channel.send() and IOError from result.result(). I think that's bad.15:37
efriedwhat I'm trying to work towards is a way for the privsep framework itself to raise unique exceptions when things like comm go wrong, so that we can do your retry thing in all and only those, without worrying about accidentally retrying a privileged command that actually ran already.15:39
*** niceplace_ has joined #openstack-oslo15:39
bnemecBleh15:42
efriedbleh which?15:44
efriedbleh "can't tell the difference"15:44
efriedor are you hatin on my unique-exceptions idea?15:44
*** openstackgerrit has joined #openstack-oslo15:46
openstackgerritBen Nemec proposed openstack/oslo.i18n master: Allow Message.translate to handle unhashable inputs  https://review.opendev.org/67909215:46
efriedbnemec: this https://opendev.org/openstack/oslo.privsep/src/branch/master/oslo_privsep/daemon.py#L502-L51115:49
efriedlooks to me like it's possible we *did* execute the privileged function, and just have no way to send the result back.15:49
efriedSo if the client channel dies between sending a command and receiving the result, the caller can't actually know whether their thing was run or not.15:49
efriedWhich I guess is an acceptable limitation.15:49
efriedRight now we're worried about the daemon dying, not the client channel15:50
efriedBUT15:50
efriedwe need to be careful not to shut down the client channel before we've drained the message queue from the daemon.15:50
bnemec(the bleh was for the can't tell the difference problem)16:00
bnemecDoes the socket buffer? Because if it doesn't then there's no chance of reading anything from it after the daemon dies anyway.16:00
*** tesseract has quit IRC16:08
*** bobh has joined #openstack-oslo16:11
efriedlike the socket socket? or the message queue in oslo.privsep code itself? The latter yes; the former... no idea.16:12
bnemecHmm, actually except Exception in the retry didn't fix the problem.16:12
* bnemec hates heisenbugs16:12
efriedbnemec: I need to run for a bit, but I'd like to put this thought in your head:16:14
efriedMy patch as written fixes the SIGHUP problem in an actual running nova.16:14
efriedAnd I can't see how it could make any issues with high concurrency/parallelism *worse* than they already are16:14
efriedso16:14
efriedCould we consider merging the fix, and trying to nail down some of these races "later"?16:14
*** bobh has quit IRC16:15
*** efried is now known as efried_rollin16:16
*** bobh has joined #openstack-oslo16:16
*** bobh has quit IRC16:20
bnemecefried_rollin: Yeah, perfect being the enemy of good and all that.16:21
*** tosky_ has joined #openstack-oslo17:45
*** tosky has quit IRC17:45
*** tosky_ is now known as tosky17:45
*** mmethot has quit IRC17:58
*** zbitter has joined #openstack-oslo17:58
*** mmethot has joined #openstack-oslo17:58
*** zaneb has quit IRC17:58
openstackgerritBen Nemec proposed openstack/oslo.cache stable/rocky: Use upper constraints from opendev.org  https://review.opendev.org/65563718:13
sean-k-mooneybnemec: o/ i noticed a bug in oslo utils last night. i still need to write it up but can that be fixed fater friday is the feature freeze well just for features18:38
bnemecsean-k-mooney: Yeah, Friday is just for features. We have a bit more time for bugfixes.18:39
sean-k-mooneyok. oslo_utiles.imageutils is parsing some direct output of the qemu image info command18:39
sean-k-mooneyi think that output has chagned or we just had a latent bug18:39
sean-k-mooneyin any case its trying to do int('12.1') which is not allowed18:40
sean-k-mooneyso i need to figure out if we shoudl do int(float(raw_vaule))18:40
sean-k-mooneyor maybe do ceil(float(raw_value))18:41
sean-k-mooneyto round up18:41
sean-k-mooneybut its fairly trivial once i confirm what the correct behaivor is18:41
sean-k-mooneythe corect behavior might just be use float instead of int18:42
sean-k-mooneyill file the bug when i get time and propose a patch this week18:42
bnemecSounds good, thanks.18:45
*** tosky has quit IRC18:56
*** lpetrut has quit IRC19:02
*** efried_rollin is now known as efried19:22
*** ralonsoh has quit IRC19:42
*** kgiusti has left #openstack-oslo20:35
openstackgerritEric Fried proposed openstack/oslo.privsep master: Self-resetting PrivContext  https://review.opendev.org/67832320:35
efriedbnemec: Tweaked and un WIPed ^20:37
*** boden has quit IRC21:08
efriedthanks bnemec. Now, who's oslo-core-ish that we can pester to get both of those merged so we can put this bug to bed?21:11
bnemecefried: stephenfin is probably your man, given that this is relevant to his interests on both sides.21:12
efriedHeh, just yesterday for an unrelated reason stephenfin disclaimed understanding of oslo.service and oslo.privsep21:13
bnemecAnd FTR I would consider zane's +2 on https://review.opendev.org/#/c/641907/ still valid since there was only a commit message change since then.21:13
efriedcool. Does zaneb review privsep?21:13
bnemecNobody understands them, that's no excuse. :-P21:13
efried<chuckle>21:13
bnemecOh, he's zbitter here.21:14
bnemecBut yeah, he's full oslo-core now too.21:14
bnemecAlthough he mostly sticks to oslo.service and related stuff.21:14
efriedhey look, dhellmann is specifically an oslo-privsep-core...21:14
bnemecYeah, he's not doing much oslo these days though. :-(21:15
bnemecUnfortunately we only have about 3 active cores in oslo right now and one of them is on extended PTO.21:18
*** jbadiapa has quit IRC21:52
*** adriant has quit IRC23:17
*** adriant has joined #openstack-oslo23:18
*** adriant3 has joined #openstack-oslo23:19
*** rcernin has joined #openstack-oslo23:21
*** adriant3 has quit IRC23:21
*** adriant4 has joined #openstack-oslo23:22
*** adriant has quit IRC23:23
*** adriant49 has joined #openstack-oslo23:24
*** adriant49 has quit IRC23:24
*** adriant4 has quit IRC23:28
*** adriant has joined #openstack-oslo23:48

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!