Dear Oonitarians,
We're about to start testing some mlab-ns integration features on the M-Lab test slice. This will be potentially disruptive because we'll be reinitializing the slice, installing new bits and bobs, and we'll be using our own fork of ooni-support [1] rather than upstream ooni-support [2].
Please let us know if we should *not* do this soon. Today I planned to only poke mlab1.nuq0t.measurement-lab.org [3], but eventually we want to test at least two test slivvers.
Meanwhile, what happens if we deploy some integration glue and it doesn't work, or has unanticipated problems in the future, or M-Lab policies change, etc?
To anticipate those kinds of issues, we want to make sure that it's easy to toggle off the integration stuff. One of our key design goals has been to avoid modifying upstream ooni. We've just realized a new and related design goal: make sure it's easy to turn off the integration glue without requiring slice re-initialization, packages changes, repository changes, etc... So we just added a ticket for that [4].
Note that *while* we are doing this interactive testing, the two slivvers we're using will be pretty unstable, but *after* we reach a stable level of development, we should be able to flip the integration switch to off and the M-Lab test slice should operate as before (except with some extra stuff installed).
If you have any concerns / feedback / comments, etc... feel free to email us, or respond to specific tickets. All of the tickets related to the mlab-ns integration in particular should live in the `ooni-support` issue tracker with the `LeastAuthority D` label [5].
Regards, Nathan
links:
[1] https://github.com/LeastAuthority/ooni-support
[2] https://github.com/m-lab-tools/ooni-support
[3] https://github.com/m-lab-tools/ooni-support/issues/50#issuecomment-50060748
[4] https://github.com/m-lab-tools/ooni-support/issues/54
[5] https://github.com/m-lab-tools/ooni-support/issues?direction=desc&labels...
On 7/24/14, 9:16 PM, Nathan Wilcox wrote:
Dear Oonitarians,
We're about to start testing some mlab-ns integration features on the M-Lab test slice. This will be potentially disruptive because we'll be reinitializing the slice, installing new bits and bobs, and we'll be using our own fork of ooni-support [1] rather than upstream ooni-support [2].
Please let us know if we should *not* do this soon. Today I planned to only poke mlab1.nuq0t.measurement-lab.org [3], but eventually we want to test at least two test slivvers.
I guess it is a little bit late to reply to this, though it should not be a big issue since we have another collector running that is not hosted on mlab.
Meanwhile, what happens if we deploy some integration glue and it doesn't work, or has unanticipated problems in the future, or M-Lab policies change, etc?
I guess the ideal solution would be to have good integration testing so that the risk of this is minimized. From the looks of it you have already done a good job at writing code for this.
Regarding M-Lab policy changes I think this is something that will require human intervention and is not easy to automate.
To anticipate those kinds of issues, we want to make sure that it's easy to toggle off the integration stuff. One of our key design goals has been to avoid modifying upstream ooni. We've just realized a new and related design goal: make sure it's easy to turn off the integration glue without requiring slice re-initialization, packages changes, repository changes, etc... So we just added a ticket for that [4].
It looks like that inside of bouncer-plumbing/mlab-to-bouncer/update-bouncer.sh you have implemented a flag for doing this so this should be sorted out.
Note that *while* we are doing this interactive testing, the two slivvers we're using will be pretty unstable, but *after* we reach a stable level of development, we should be able to flip the integration switch to off and the M-Lab test slice should operate as before (except with some extra stuff installed).
What is the current state of the slivvers? Is the integration logic switched off now? Are you done with interactive testing?
~ Art.
-
Arturo Filastò -
Nathan Wilcox