He has been trying to become an admin for a while since a lot of his work is related to Jira, but the other Jira admins kept insisting that he either create a change request ticket for every request, or sit with them and do the work together.

All the existing admins, including me, typically respond this way to prevent a slippery slope where there are dozens of admins and no oversight over Jira management. We each have our own domain that the others respect, and whenever we need to change something in another admin’s domain or a shared setting we make sure to clearly communicate what we’re changing. This only works if there’s complete trust between the admins and if they all know each other.

So, how did I manage to get into this “admin clique” while my colleague isn’t able to?

Over the past few years, I’ve managed to consistently become an admin of systems that I care about. Partly, this was because I joined the company early - but then most other early employees aren’t currently admins. Other early employees that were admins for various reasons: they either were part of the selection team for the system, or they asked for it before we had clear policies set, or someone made them an admin by mistake in those early days. Eventually, most lost their admin privileges when we started cleaning up our act as a company.

I thought back and compiled this eight-point plan to become and remain an admin of a system at your work:

1. Find a problem with the system or its configuration that the busiest (or laziest) admin wants to fix but doesn’t want to handle on their own. Note: this shouldn’t be something that you care about, but something that they care about.

2. Convince the admin that you can fix the problem and that you’re responsible enough.

3. Become an admin! But wait, this is temporary: you’ll lose your access on the next cleanup.

4. Start making good changes to fix people’s complaints. Still to non-controversial actions so no one tries to revoke your access. Make sure to follow up with people who request changes so that they know you were the one who helped them.

5. Declare that there are too many admins and that there needs to be a stricter policy to define who can be an admin.

6. Take it on yourself to define (or redefine) that policy and present it to the system owner in your organization. Make sure you fit the new definition and make sure that staple admins are also included. Staple admins are those who are either actually doing important work as admins or people who will make a lot of noise if you try to kick them out. Noise means chaos - which means it’s you who might end up on the outside.

7. No one remembers why you’re an admin, but you’re setting the rules now so no one can dispute it. Victory!

8. Make sure to keep helping out anyone who wants to fix problems with the system. If you become a roadblocker, you will allow someone else to do step #1 and you might lose your access when that person reaches step #6.

This sounds like an evil plan for world domination so make sure to remember:

• You’re doing this because you care, not because you want control.

• Leave the system better than you found it: more convenient for users, more secure, and easier to maintain.

• Create trust among admins, and between admins and users, in every step of the process.

The full code from this blog post can be found on GitHub.

In essence, the proxy is a GenServer receiving messages from the client that need to be proxied to a dedicated upstream, and messages from upstreams to their matching clients.

The replies from the upstreams are as simple as using :gen_udp and looking up some state maps:

  defmodule UdpProxy.Server do
    use GenServer
    alias UdpProxy.Upstream

    ...

    def receive_data downstream, data do
      GenServer.cast downstream[:server_pid], {:receive, downstream, data}
    end

    def handle_cast {:receive, downstream, data}, state do
      :ok = :gen_udp.send state[:socket], downstream[:host],
                          downstream[:port], data
      {:noreply, state}
    end

    ...

  end

Sending the messages to the designated upstream (if exists) is pretty simple, and uses the process messages from :gen_udp’s active mode:

  ...

  def handle_info {:udp, _socket, ip, port, data}, state do
    map_key = {ip, port}
    server = self
    upstream = Map.get_lazy state[:map], map_key, fn ->
      downstream = %{server_pid: server,
                     host: ip,
                     port: port}
      {:ok, pid} = Upstream.start_link state[:upstream_host],
                                       state[:upstream_port], downstream
      %{pid: pid}
    end
    map = Map.put state[:map], map_key, upstream
    state = Map.put state, :map, map
    Upstream.send_data upstream[:pid], data
    {:noreply, state}
  end

  ...

Similarly the upstream communicates both with the UdpProxy.Server and with its own connection via :gen_udp.

To make sure that stale connections don’t end up eating too much memory and sockets, I introduced a GC loop that cleans clients that didn’t send messages through the proxy for 5 seconds. Specifically for my use case, extending the connection’s lifetime on replies was not needed. The loop is using Process.send_after self, … and I’m not sure that that’s the correct way to implement this.

This is actually one of the few times I have worked directly with OTP in Elixir, as most of my hobby work with Elixir is either for scripting or CLI applications, or through deep abstractions. I know that there’s a lot of error-detection missing around the Upstream processes, that aren’t supervised at all and won’t be replaced on failure, but it was definitely a fun two-hour exercise with Elixir.