Skip to content
Snippets Groups Projects
New look: Off

Triggerable controller event

    • Closed Issue created by Damian Johnson @atagar

    Stem's integ tests presently use tor's BW events to check its ability to receive asynchronous events. This is because BW events are reliably emitted each second, and as far as I'm aware it's the only way to reliably get an event.

    This is essentially a sleep in our tests. Better would be to have an event we can trigger on demand. This would speed up our tests a little and improve their reliability...

    https://gitweb.torproject.org/stem.git/tree/test/integ/control/controller.py#n36

    Sebastian had the neat idea for new PING event type that can be triggered by calling a controller method. But perhaps we already have a triggerable event I'm overlooking?

    To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information

    Child items 0

    • No child items are currently assigned. Use child items to break down this issue into smaller parts.

    Activity

    • Damian Johnson added component::archived/stem easy owner::atagar priority::low resolution::fixed severity::normal status::closed testing type::enhancement labels

      added component::archived/stem easy owner::atagar priority::low resolution::fixed severity::normal status::closed testing type::enhancement labels

    • A
      Damian Johnson @atagar ·
      Author

      Reassigning this to Stem. Turns out there's indeed several options. Best so far sounds to be listening for CONF_CHANGED then triggering SETCONF events (don't forget the corresponding RESETCONF so tests don't leave tor in a changed state!).

      09:21 < Sebastian> atagar wants an asynch controller command that just replies with something
09:21 < nickm> hmmm
09:21 < Sebastian> I could implement a ping
09:21 < Sebastian> but do we have something that already does that?
09:21 < Sebastian> (The idea is to reply just once)
09:22 < nickm> Sebastian: what's the application?
09:23 < atagar> I described it in the ticket - one sec...
09:23 < Sebastian> It would make the tests a lot faster
09:23 < Sebastian> currently atagar uses bw events for taht
09:23 < Sebastian> that*
09:23 < atagar> Not a lot, but a few seconds.
09:23 < nickm> oh, easy
09:23 < nickm> SETEVENTS ADDRMAP
09:23 < nickm> 250 OK
09:23 < nickm> RESOLVE 127.0.0.1
09:23 < nickm> 650 ADDRMAP 127.0.0.1 127.0.0.1 "2015-02-19 12:21:25" EXPIRES="2015-02-19 17:21:25" CACHED="NO"
09:23 < Sebastian> thanks for correcting that, atagar. I had hoped for a lot
09:23 < nickm> 250 OK
09:23 < atagar> ah, there it is - https://trac.torproject.org/projects/tor/ticket/14943
09:23 < nickm> probably there's other stuff too
09:24 < nickm> note that if you resolve something that is already an IP, it doesn't hit the network
09:24 < atagar> If you don't have network connectivity does that work? I'd expect RESOLVE to fail, so suspect it wouldn't emit an event.
09:24 < nickm> I bet it will succeed if you tell it 127.0.0.1
09:24 < Sebastian> easy to test
09:25 < Sebastian> just disablenetwork
09:25 < nickm> works for me with disablenetwork set
09:25 < nickm> haven't tried it with no internet connectivity
09:25 < atagar> Also the tests shouldn't touch the network if running without the online target - if it doesn't then perfect.
09:25 < nickm> it shouldn't.
09:25 < atagar> great - thanks!
09:25 < Sebastian> ok, thankss. Will have to find something else to implement then :)
09:26 < Sebastian> I'll write the stem patch if you don't want to do it atagar?
09:26 < nickm> another option is listen for SIGNAL then send a SIGNAL CLEARDNSCACHE
09:26 < nickm> maybe
09:26 < nickm> let me check
09:26 < atagar> Sebastian: I was just about to ask that. :P
09:26 < nickm> yup, that works too
09:26 < atagar> Have quite a few other things on my plate so if you're up for writing it that would be appreciated.
09:27 < nickm> Or listen for CONF_CHANGED and then set Contact or something
09:27 < Sebastian> atagar: ok cool. I am in a train so no real computer and no real network
09:27 < Sebastian> Can you file a bug and assign it?
09:27 < atagar> oooh, CONF_CHANGED sounds like the best so far
09:27 < atagar> thanks nickm
09:27 < Sebastian> I'll implement it
09:27 < Sebastian> thanks both of you :)
09:27  * nickm is just breezing through control-spec.txt
09:27 < atagar> Sebastian: Will do. I'll reassign the existing ticket and add this backlog.
09:27 < Sebastian> (the great thing about this is that it doesn't even need a feature-gate)

      Trac:
      Owner: N/A to atagar
      Component: Tor to Stem

    • A
      Damian Johnson @atagar ·
      Author

      Trac:
      Keywords: N/A deleted, testing, easy added

    • S
      Sebastian Hahn @sebastian ·

      Branch controller_event in my stem repo

      Trac:
      Status: new to needs_review

    • A
      Damian Johnson @atagar ·
      Author

      Thanks Sebastian, looks great! Pushed with just a few minor tweaks...

      Trac:
      Status: needs_review to closed
      Resolution: N/A to implemented

    • A
      Damian Johnson @atagar ·
      Author

      Reopening since I had to revert part of this due to Jenkins failures. grumble, grumble, concurrency, grumble.

      Trac:
      Status: closed to reopened
      Resolution: implemented to N/A

    • A
      Damian Johnson @atagar ·
      Author

      I've been looking into test runtimes and as part of that changed the controller test to use CONF_CHANGED. Jenkins seems happy with the changes.

      Trac:
      Resolution: N/A to fixed
      Sponsor: N/A to N/A
      Status: reopened to closed
      Severity: N/A to Normal
      Reviewer: N/A to N/A

    • Trac closed

      closed

    Please register or sign in to reply