Closed kkroo closed 9 years ago
Can you add a barebones integration test for this? That module kind of encapsulates all of the functionality of the package.
In line with the change in endaga/openbts#19, for our purposes we only care about the # of seconds since last accessed, rather than the timestamp of accessed/created itself. Should we consider adding this time to the result here? I am not sure whether it makes more sense to add that value here in postprocessing, or have OpenBTS provide that itself, or leave that responsibility to the caller.
My concern here comes from the fact that in other NM responses that contain timestamps I've seen the timestamp just be very incorrect (PhysicalStatus comes to mind), so we should at least test that to make sure we can get the right value from the caller if we're going down that route.
Good point, we could just leave OpenBTS to handle computing time differences rather than giving the epoch in endaga/openbts#19
So I changed the way that this is pulling the TMSIs (See endaga/openbts#23) but now we can at least filter out subscribers who are not on our network in SQL. This should save us from having to send over the entire TMSI table over zmq on checkin.
Added integration test as requested @yosemitebandit, but it is a pretty silly one for now
PTAL
We should update the OpenBTS depends on this one if it's depending on new NodeManager API behavior...
Yeah I forgot the version bump
is it true that this will only work on our fork of OpenBTS? If so, can you add a comment to that effect?
I take it this is ready for review too? Sorry this has been so delayed :(
Yes, PTAL :)
LGTM, LMK when I should push to pypi
We can push this to pypi once endaga/openbts#23 is live. Sry bout the chain dependencies!
Alrighty, this is ready for pypi!
alrighty, 0.1.1 is released to pypi
Allows you to make calls to
tmsis
, a command that already exists in openbts's nodemanager interface