We are finally getting close to deployment of PulseGuardian and the new
security model. PulseGuardian has been updated to create users with the
proper permissions, and the mozillapulse library has been updated with
the new exchange- and queue-name formats (though the new code has not
been released to pypi yet, since it is a breaking change). The
remaining steps are as follows:
1. Deploy PulseGuardian (bug 1015037). Note that PulseGuardian will
replace the static content currently on http://pulse.mozilla.org
info will be missing until bug 1017957 is fixed. This isn't worth
blocking deployment though.
2. Existing consumers need to create users via PulseGuardian. As noted,
at some point after the switchover, the public user will be deleted.
Note that these users won't be useful until the publishers are updated
to use the new mozillapulse library.
3. Release new mozillapulse version.
4. Existing publishers need to upgrade their mozillapulse packages and
be restarted. This will cause them to start writing to the new
exchanges (e.g. exchange/build instead of org.mozilla.exchange.build).
5. Existing consumers will also need to upgrade and restart in order to
start consuming from the new exchanges. This needs to be done after the
publishers are restarted since publishers create the exchanges and
consumers will error out if the target exchange is not present.
Ideally, however, this step should be done as closely following the
previous step as possible.
As mentioned in the original message in this thread, steps 4 and 5 will
potentially cause some messages to be lost. Depending on how the
publishers are written, they may miss whatever events they are listening
for while being restarted. When consumers are restarted, they may miss
messages since they will have to recreate any durable queues to bind to
the new exchanges. This could be worked around by modifying consumer
apps to listen to both the original queue (with the public user) and the
new queue (with the new PulseGuardian-created user), since no messages
will be duplicated between queues, but I imagine this will be more work
than it's worth for most, if not all, apps.
As I also mentioned, my preference is just to pick a single time to
restart everything, if possible and if missing a couple messages is
acceptable to all consumer apps. If you run an app with a Pulse
consumer, please reply and let me know if this is acceptable. I'd like
to pick a day and time to flip the switch very soon (like in a week or two).