Tuesday, 2017-04-18

*** dharinic has quit IRC00:04
*** hongbin has quit IRC00:15
*** ihrachys has joined #openstack-oslo00:37
*** ihrachys has quit IRC00:37
*** ansmith has quit IRC00:46
*** tovin07_ has joined #openstack-oslo01:02
*** ihrachys has joined #openstack-oslo01:04
*** ihrachys has quit IRC01:17
*** ihrachys has joined #openstack-oslo01:17
*** zhangguoqing has joined #openstack-oslo01:19
openstackgerritMerged openstack/tooz master: etcd3: add etcd3 coordination driver  https://review.openstack.org/44722301:20
*** zhangguoqing has quit IRC01:33
*** zhangguoqing has joined #openstack-oslo01:34
*** gcb has joined #openstack-oslo01:39
*** yamahata has quit IRC02:14
*** eliqiao has joined #openstack-oslo02:48
*** zhangguoqing has quit IRC03:01
*** tonyb has quit IRC03:04
*** dave-mccowan has quit IRC03:05
*** nicolasbock has quit IRC03:05
*** tonyb has joined #openstack-oslo03:09
*** ihrachys has quit IRC03:09
*** tonyb has quit IRC03:12
*** tonyb has joined #openstack-oslo03:13
*** zhangguoqing has joined #openstack-oslo03:13
*** amotoki has joined #openstack-oslo03:22
*** tonyb has quit IRC03:28
*** tonyb has joined #openstack-oslo03:28
*** links has joined #openstack-oslo03:40
*** Dinesh_Bhor has joined #openstack-oslo03:44
*** zhangguoqing has quit IRC03:45
*** eliqiao has quit IRC03:50
*** zhangguoqing has joined #openstack-oslo04:39
*** zhangguoqing has quit IRC04:41
*** zhangguoqing has joined #openstack-oslo04:57
*** jamielennox is now known as jamielennox|away05:12
*** jamielennox|away is now known as jamielennox05:17
*** mhickey has joined #openstack-oslo05:26
*** gcb has quit IRC05:33
*** gcb has joined #openstack-oslo05:46
*** rcernin has joined #openstack-oslo06:06
*** hjensas has quit IRC06:18
*** tesseract has joined #openstack-oslo06:40
*** pooja_jadhav has joined #openstack-oslo06:46
pooja_jadhavgcb:Hi06:59
gcbpooja_jadhav, hi06:59
*** pcaruana has joined #openstack-oslo06:59
pooja_jadhavgcb: I want to discuss about this bug https://bugs.launchpad.net/nova/+bug/168013006:59
openstackLaunchpad bug 1680130 in OpenStack Compute (nova) "Attaching a volume w/ an invalid (too long) UUID results in HTTP 500." [Undecided,In progress] - Assigned to Pooja Jadhav (poojajadhav)06:59
pooja_jadhavgcb: If we passed invalid long volume uuid (includes hyphen) to "attach-volume" API then it returns 500 because it is trying to insert that volume uuid in to the table and volume uuid column having size 36. If more than 36 characters tries to add for volume uuid then it returns DBDataError.07:04
pooja_jadhavgcb: so my concern we should fix this issue in the central place that is "is_uuid_like" method that removes hyphen and return true or false respectively.07:06
pooja_jadhavwe should check uuid size, if its more than 36 we should return false.07:06
*** shardy has joined #openstack-oslo07:09
gcbpooja_jadhav, i'm in a meeting, will check this later07:09
pooja_jadhavgcb: Fine thanks07:18
gcbI'm back, checking the bug ...07:18
pooja_jadhavgcb: ok07:19
gcbpooja_jadhav,  do you mean https://github.com/openstack/oslo.utils/blob/master/oslo_utils/uuidutils.py#L45 ?07:23
pooja_jadhavgcb: yes07:24
gcbpooja_jadhav,  valid uuid with hyphen has 36 characters,  and '11111111-2222-4f9d-5555--666666666666' pass the check now ,right ?07:27
gcbyes, we need check string's size which equals 3607:28
pooja_jadhavgcb: yes07:29
gcbthat makes sense ,  uuidutils.is_uuid_like('11111111-2222-4f9d-5555--666666666666') should return False07:30
pooja_jadhavgcb: most of the projects uses this method to check uuid string format for validation so can we make validation of uuid in "is_uuid_like"07:31
gcbyes, please add the length check, and I will help review07:33
gcbor I can post the patch07:34
*** jamielennox is now known as jamielennox|away07:34
pooja_jadhavgcb: yes, I will fix this as early as possible.. thanks for your opinion and time :)07:34
gcbpooja_jadhav,  thanks for raising this, please add me as reviewer :-)07:36
pooja_jadhavgcb: sure, I will add:-)07:38
*** lucas-afk is now known as lucasagomes07:59
*** zzzeek has quit IRC08:00
*** zzzeek has joined #openstack-oslo08:00
*** jaosorior has joined #openstack-oslo08:03
*** hjensas has joined #openstack-oslo08:22
*** jamielennox|away is now known as jamielennox08:28
*** openstackgerrit has quit IRC08:33
*** mhickey has quit IRC08:34
*** pblaho has joined #openstack-oslo08:55
*** cdent has joined #openstack-oslo09:09
*** sambetts|afk is now known as sambetts09:19
*** e0ne has joined #openstack-oslo09:24
*** openstackgerrit has joined #openstack-oslo09:37
openstackgerritStephen Finucane proposed openstack-dev/pbr master: trivial: Add note about multiple builders support  https://review.openstack.org/43954509:37
*** zhangguoqing has quit IRC09:40
*** mhickey has joined #openstack-oslo09:49
*** boden has joined #openstack-oslo09:58
*** nicolasbock has joined #openstack-oslo10:04
*** shardy has quit IRC10:06
sileht110:08
*** tovin07_ has quit IRC10:13
*** zhangguoqing has joined #openstack-oslo10:19
*** zhangguoqing has quit IRC10:26
*** sdague has joined #openstack-oslo10:26
*** shardy has joined #openstack-oslo10:29
*** zhangguoqing has joined #openstack-oslo10:33
*** zhangguoqing has quit IRC10:42
*** jaosorior has quit IRC10:55
*** zhangguoqing has joined #openstack-oslo10:57
*** geekinutah has quit IRC10:58
*** geekinutah has joined #openstack-oslo10:58
*** jaosorior has joined #openstack-oslo11:01
*** shardy is now known as shardy_lunch11:06
*** lucasagomes is now known as lucas-hungry11:14
*** geguileo has joined #openstack-oslo11:18
geguileogus: ping - oslo.privsep question11:24
geguileoAnybody around willing to answer a privsep question?11:37
geguileore-reading that it sounded bad, by willing I meant that had the knowledge and the time.  lol11:40
*** eck`gone is now known as eck`11:40
*** jamielennox has left #openstack-oslo11:49
*** jamielennox has joined #openstack-oslo11:49
*** yassine has joined #openstack-oslo11:53
*** yassine is now known as Guest8617011:53
*** Guest15696 has quit IRC11:54
*** dave-mccowan has joined #openstack-oslo12:09
*** shardy_lunch is now known as shardy12:16
*** salv-orlando has joined #openstack-oslo12:19
*** ansmith has joined #openstack-oslo12:22
*** lucas-hungry is now known as lucasagomes12:24
*** gordc has joined #openstack-oslo12:28
gusgeguileo: ?12:32
geguileogus: Hi12:33
geguileogus: I would like to check, is an privsep entrypoint only able to have 1 simultatenous call?12:33
gus"don't ask to ask, just ask"12:33
geguileo:-)12:34
gus(trying to remember the code ;)12:34
geguileothanks  :-)12:34
gusYes, only one simultaneous call iirc.12:34
gusmultiple threads can make calls, but they get serialised by some locks.12:35
geguileoooooooh, that's bad  :-(12:35
geguileoAny way to work around that?12:35
* geguileo was actually hoping he had read the code wrong12:37
gusMake Daemon.loop fancier: https://github.com/openstack/oslo.privsep/blob/master/oslo_privsep/daemon.py#L43312:38
gusCurrently it reads messages from the communication channel and calls functions (see _process_cmd)12:39
geguileoI read the code, I was just hoping that I missed something or there was some kind of workaround for it12:39
geguileo:'-(12:39
geguileogus thanks for the confirmation12:40
gusYou'd need to change it to use a worker thread pool or something instead of just a naive function call.  The downside of course is that things that *are* just short function calls would now be slower.12:40
gusThe communication protocol has everything tagged by message id, so you can return messages out of order just fine.12:41
gusgeguileo: what long-lived thing do you need to do?12:42
geguileogus: well, in os-brick we do calls to iscsiadm and multipath12:43
geguileoAnd if there are network issues those can take a very long time, for example a login to iSCSI when there are errors can take up to 2 minutes12:43
geguileoto fail12:43
gusah :(12:43
geguileoSo that means that there can be no other call at the same time12:43
geguileoAnd I had just created a patch that refactored the connect so it was done in parallel12:44
gusyeah sorry :(12:44
geguileoSo if we wanted to create 4 sessions and 3 were down it would only take 2 minutes and not 3*212:44
gusmost of the hard work is done - the communication protocol supports out of order messages, and multiplexing onto the channel is protected with a lock.12:45
gusYou just need to actually invoke the privileged functions asynchronously on the server side.12:45
geguileoI'll try to finish with the work I'm doing and see if I can poke at it12:46
geguileothank you for your time12:46
*** kgiusti has joined #openstack-oslo12:46
gusiirc I had plans to support slow generator functions too, that would be tagged with a different message type (not Message.CALL) and could dribble results back intermixed with responses from other functions.12:47
gusthat's a bit more work though (not that much).12:47
*** dimtruck is now known as zz_dimtruck12:49
*** gcb has quit IRC13:00
geguileothe think is that these call can take 1 second or take 2 minutes, we don't know beforehand  :-(13:03
*** dougshelley66 has left #openstack-oslo13:06
*** jaosorior has quit IRC13:06
*** jaosorior has joined #openstack-oslo13:14
*** pcaruana has quit IRC13:27
*** hjensas has quit IRC13:35
*** links has quit IRC13:35
*** hongbin has joined #openstack-oslo13:50
*** pcaruana has joined #openstack-oslo14:10
*** zz_dimtruck is now known as dimtruck14:11
*** dave-mccowan has quit IRC14:24
*** zhangguoqing has quit IRC14:36
*** dave-mccowan has joined #openstack-oslo14:44
*** efried has joined #openstack-oslo14:46
efriedharlowja yt?14:47
*** shyama has joined #openstack-oslo14:52
efriedharlowja - shyama discovered a TaskFlow behavior we'd like to ask you about.  It reduces to something like this: https://pastebin.com/3veV7w5E14:53
efriedharlowja The behavior is that we get the exception from the revert, but the exception from the execute is lost.14:54
efriedIs this something we have to code around by explicitly swallowing exceptions in revert, and/or explicitly printing stack traces in execute?14:54
efriedOr is there some other option?14:54
*** dharinic has joined #openstack-oslo14:59
*** ianychoi has quit IRC15:00
*** dharinic has quit IRC15:04
*** rcernin has quit IRC15:09
*** Guest86170 has quit IRC15:21
*** Guest86170 has joined #openstack-oslo15:25
openstackgerritGage Hugo proposed openstack-dev/pbr master: Fix missing comment from previous change  https://review.openstack.org/45769215:26
*** pcaruana has quit IRC15:41
*** e0ne has quit IRC15:42
*** salv-orl_ has joined #openstack-oslo15:49
*** ihrachys has joined #openstack-oslo15:51
*** salv-orlando has quit IRC15:51
*** salv-orl_ has quit IRC16:14
*** lucasagomes is now known as lucas-afk16:15
*** mhickey has quit IRC16:30
*** dave-mccowan has quit IRC16:41
*** jaosorior has quit IRC16:43
*** dave-mccowan has joined #openstack-oslo16:45
*** harlowja_ has joined #openstack-oslo16:50
*** harlowja has quit IRC16:52
*** amotoki has quit IRC16:57
efriedharlowja_ Can you see backscroll from ~2h15m ago?17:03
harlowja_ya, will get around to that in a few :)17:03
efriedharlowja_ Thanks!17:04
*** cdent has quit IRC17:07
harlowja_np17:09
*** yamahata has joined #openstack-oslo17:09
*** gnarld_ is now known as cFouts17:17
*** shyama_ has joined #openstack-oslo17:18
*** shyama has quit IRC17:20
*** shyama_ is now known as shyama17:20
*** ihrachys_ has joined #openstack-oslo17:23
*** ihrachys has quit IRC17:25
*** shardy has quit IRC17:30
*** dougshelley66 has joined #openstack-oslo17:41
openstackgerritMerged openstack-dev/pbr master: Fix missing comment from previous change  https://review.openstack.org/45769217:41
*** shyama has quit IRC17:41
*** shyama has joined #openstack-oslo17:42
openstackgerritAndy Smith proposed openstack/oslo.messaging master: Add get_rpc_transport call  https://review.openstack.org/45419417:51
*** nicolasbock has quit IRC18:01
harlowja_efried hmmmm18:08
harlowja_i thought it retained both18:08
*** sambetts is now known as sambetts|afk18:08
harlowja_but u might be right18:08
efriedharlowja_ It might "retain" - but doesn't print AFAICT18:08
harlowja_efried something to see if is logged18:11
harlowja_https://github.com/openstack/taskflow/blob/master/taskflow/engines/action_engine/builder.py#L24418:11
efriedharlowja_ Would require taskflow logging at debug level, nah?18:12
harlowja_ya18:12
harlowja_also efried https://github.com/openstack/taskflow/blob/master/taskflow/engines/action_engine/engine.py#L334-L340 looks like it should capture both18:16
harlowja_but let's see18:17
efriedharlowja_ I tried the script in that paste with debug logging enabled (I think) and just got the one error.18:17
harlowja_kk18:17
efriedwanna see it?18:17
harlowja_nah, i got it :-P18:17
efriedk18:17
harlowja_ya, hmmm, ok, am thinking something not capturing an exception somewhere18:18
efriedshyama ^^ FYI18:19
*** tesseract has quit IRC18:22
*** nicolasbock has joined #openstack-oslo18:27
harlowja_efried so i think i know what to change18:38
harlowja_the question is what do we want to happen :)18:38
efriedWell.18:38
efriedshyama Feel free to chime in here.18:39
efriedharlowja_ I think we should log the revert exception, and raise the execute exception.18:39
efriedQuestion: if one revert fails, do we continue with other reverts?18:39
harlowja_ya, that's ^ the bigger question :-P18:39
openstackgerritJoshua Harlow proposed openstack/taskflow master: Allow gathering + continutation of successive REVERT_FAILURES  https://review.openstack.org/45776418:40
harlowja_efried ^ does continue with other reverts18:40
efriedI'd say yes.  It's pretty probable they'll fail, but they should at least be given a shot.18:40
efriedCan reverts 'provide' things for other reverts?18:40
harlowja_nope18:41
efriedThen definitely yes, keep trying 'em.18:41
efriedharlowja_ Want me to patch that up and try it?18:42
efriedor did you already do that?18:43
harlowja_ya, i'm trying with little sample18:44
harlowja_import logging18:45
harlowja_logging.basicConfig(level=5)18:46
harlowja_btw that will show u more of the decisions being made ;)18:46
efriedharlowja_ Is LOG.isEnabledFor(DEBUG) really necessary?  That logic exists in LOG.debug... oh, it's so you don't do the get_atom_intention processing huh?18:47
harlowja_ya18:47
efrieddig18:47
harlowja_which may be somewhat expensive18:47
harlowja_and may happen to often if left just to happen18:47
harlowja_and therefore suck18:48
harlowja_lol18:48
efriedYuh, gotcha.18:48
efriedOh, look, that's what your comment says.18:48
efriedWasn't immediately obvious to me that "making any intention request to storage" == get_atom_intention()18:49
harlowja_ya, fair, gotta get the data from somewhere :-p18:49
harlowja_and if that goes out to zookeeper or something, that'd suck18:49
openstackgerritJoshua Harlow proposed openstack/taskflow master: Allow gathering + continutation of successive REVERT_FAILURES  https://review.openstack.org/45776418:51
harlowja_ok, made one small other change18:51
harlowja_we may want to make this an engine option18:51
harlowja_because its slightly hard to tell if people are depending on what exists18:51
harlowja_example i am running https://gist.github.com/harlowja/1151348e065c3156d62d4870cee3471e18:53
openstackgerritElancheran S proposed openstack/oslo.messaging master: Retry support for oslo_messaging_notifications driver  https://review.openstack.org/43767318:53
harlowja_code @ https://gist.github.com/harlowja/aeec4ca758f69e9c27c821d71b00a86018:53
harlowja_efried  shyama  ^18:53
harlowja_the logging is pretty useful when needed :-p18:54
harlowja_but can be freaking noisy, lol18:54
harlowja_u now get a `taskflow.exceptions.WrappedFailure: WrappedFailure: [Failure: ValueError: foo, Failure: ValueError: bar]`18:55
harlowja_which is both exceptions18:55
harlowja_if other reverts also bork, then they will all get wrapped up18:56
*** cdent has joined #openstack-oslo18:58
efriedharlowja_ Hm, okay.  In my albeit limited experience, WrappedFailure has to be expected and dissected very carefully if I want to log the independent stack traces.18:58
harlowja_yup18:58
harlowja_eventually all that will move to https://github.com/harlowja/failure18:59
harlowja_along with oslo.messaging (which has similar wrapping code)18:59
harlowja_^ for remote exceptions (from some RPC channel)18:59
harlowja_but yes, u can access the indiviudal failure from engine.storage.get_execute_failures or engine.storage.get_revert_failures19:00
harlowja_if u so desire19:00
efriedharlowja_ You mean with the already-existing code?19:00
harlowja_well revert_failures i believe are causing engine stop19:01
harlowja_*currently19:01
harlowja_so u won't get X of them19:02
harlowja_but u should be able to get the individual forward failure and backwards (revert) failure from those methods right now19:02
efriedharlowja_ Not having the revert failures after the first one ain't as bad as not having the execute failure.19:02
harlowja_ya19:02
*** JayF has left #openstack-oslo19:03
harlowja_ engine.storage.get_execute_failures should have the forward one right now19:03
harlowja_(forward == execute)19:03
efriedharlowja_ But how would I use that?19:04
efriedIf I wrap my engine.run in a try/except, can I tell (without string scraping) that the exception I caught was from revert vs execute?19:04
efriedI guess I can compare them19:05
efriedtry: engine.run(); except e: if e is not engine.get_execute_failures()[0]: LOG.exception(e); raise engine.get_execute_failures()[0]19:06
efriedor something.19:06
*** dave-mccowan has quit IRC19:06
efriedLose the original context that way, though.19:07
efriedI suppose we should really use a philosophy of "reverts shall not fail", though.19:09
efriedReverts, if defined, should be robust enough to go through no matter what.19:09
efriedOtherwise we're begging to have incomplete cleanup.19:09
efriedshyama I think that's our answer, really.  Your revert should be coded so it doesn't fail.19:10
efried(I guess it's _my_ revert in this case)19:10
efriedharlowja_ Presumably your new proposal only creates WrappedFailure if there's more than one exception in play?19:16
efriedSo if a) using linear, and b) my reverts never fail, it'll still act just like the old way.19:17
efriedCause looking at our code, most of our reverts do indeed try/except and log (but don't raise) on the except path.19:18
efriedThis one was missed.19:18
harlowja_efried yup19:21
harlowja_in general if u can not have reverts fail, that'd be super19:22
harlowja_cause it starts to get hairy with what do u want to do with such failures19:23
harlowja_same kind of question usually happens with except blocks that also raise19:23
harlowja_do u drop the new one, drop the old one, log both, do somethign else :-P19:24
harlowja_i've seen a mix19:24
harlowja_python 3.x has chained exception, so u'll get something akin to wrapped failures in it19:24
harlowja_*chained exceptions19:24
harlowja_* https://www.python.org/dev/peps/pep-3134/19:24
harlowja_its just still hard to decide what to do with those imho :-19:25
harlowja_:-P19:25
harlowja_efried  ^19:25
harlowja_wrapped failures (and failure objects in general) try to approximate some of pep-313419:25
efriedharlowja_ Cool man.  Thanks a bunch for the talk here.  I think we're going to move forward with "reverts shall not fail".  But please keep me in the loop about these changes.19:26
harlowja_sure19:26
efriedharlowja_ While we're on the subject of WrappedFailure, though...19:26
efriedIt would be neat if WrappedFailure had a one-stop method to produce some kind of comprehensive message containing the stack traces for its constituent exceptions.19:27
efriedharlowja_ It would do something like this: https://github.com/powervm/pypowervm/blob/develop/pypowervm/utils/transaction.py#L788-L79319:27
harlowja_ya, closest i got is looping over them and doing https://github.com/openstack/taskflow/blob/master/taskflow/types/failure.py#L42719:27
efriedThough better, hopefully, cause we've had trouble with that.19:27
harlowja_ah, ya, u found that19:28
harlowja_kk19:28
harlowja_u should be able to get the tracebacks btw19:28
harlowja_LOG.exception afaik takes in a exc_info tuple19:28
harlowja_https://github.com/openstack/taskflow/blob/master/taskflow/types/failure.py#L30819:28
harlowja_for fail in wfail:19:29
harlowja_   LOG.error("Something broke", exc_info=fail.exc_info)19:29
harlowja_but sure i could see a method on wrapped failure being helpful there19:30
efriedfo sho19:30
*** dave-mccowan has joined #openstack-oslo19:32
*** e0ne has joined #openstack-oslo19:36
*** e0ne has quit IRC19:42
*** e0ne has joined #openstack-oslo19:43
*** david-lyle has joined #openstack-oslo19:53
dkehnoslo.db question: does anyone know how oslo.db can connect to two separate mysql instances from the same project, obviously assuming two session, config.database.connection and config.database.connect2?20:03
*** e0ne has quit IRC20:05
dkehndims: ^^^20:07
*** ildikov is now known as hypothermic_cat20:22
*** dimtruck is now known as zz_dimtruck20:27
*** ihrachys_ is now known as ihrachys20:30
*** openstackgerrit has quit IRC20:33
*** salv-orlando has joined #openstack-oslo20:45
*** zz_dimtruck is now known as dimtruck20:48
*** david-lyle has quit IRC20:49
*** dkehn_ has joined #openstack-oslo20:50
*** kgiusti has quit IRC20:59
*** dkehn_ has quit IRC21:00
*** dkehn_ has joined #openstack-oslo21:01
*** sdague has quit IRC21:04
*** cdent has quit IRC21:07
*** david-lyle has joined #openstack-oslo21:10
*** dkehn_ has quit IRC21:15
*** salv-orl_ has joined #openstack-oslo21:48
*** salv-orlando has quit IRC21:50
*** david-lyle has quit IRC21:55
*** boden has quit IRC22:00
*** amotoki has joined #openstack-oslo22:13
*** dkehn_ has joined #openstack-oslo22:43
*** salv-orl_ has quit IRC22:48
*** david-lyle has joined #openstack-oslo22:53
*** david-lyle has quit IRC22:56
*** ianychoi has joined #openstack-oslo23:14
*** gordc has quit IRC23:21
dimsdkehn : i don't think so, but rpodolyaka and zzzeek may know for sure23:29
*** d0ugal has quit IRC23:32
dkehndims: rpodolyaka: zzzeek: thanks, I'm wondering if you implement an separate project.db.sqlalchemy.api.py you can get away with it?23:36
dkehnfor example23:36
*** amotoki has quit IRC23:37
*** gordc has joined #openstack-oslo23:37
*** gordc has quit IRC23:38
*** d0ugal has joined #openstack-oslo23:41
*** Nakato has quit IRC23:45
*** Nakato has joined #openstack-oslo23:46
*** amotoki has joined #openstack-oslo23:50
*** hongbin has quit IRC23:55

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