Galaxy status monitor package

announce
1

Hey all!

I recently released this package to allow for really simple handling of Galaxy maintenance statuses, and integrating them into your app.

Feel free to contribute any improvements!

6 Likes
2

So interesting! Are you using this to tell people when the app might have issues due to Galaxy maintenance?

3

Yep, exactly! So you just subscribe to galaxyIncidents, pass it either “EU” or “US” for region (optional), and you can reactively grab status updates. I just verified (in production) the other day that it works; the most recent maintenance schedule for US kicked in, and my app displayed a notice during that time frame.

1 Like
4

Hm, this is indeed quite nice.

But it is only relevant for single-instance apps, right? Since afaik you get guaranteed high availability from galaxy as long as you have two or more large instances.

That also makes me think if it is at all possible that your app still has not rebooted when the status complete message is diapatched to webhooks, causing the app to think that maintenance is not over yet.

1 Like
5

High availability only means that your app is represented in three unique regions, so if there’s an Amazon AWS outage, you’re covered. But Galaxy maintenance still causes all three containers to reboot.

Good point! The thing is, it’s not aware of the details of the maintenance, so I can’t really assume that after one reboot, the maintenance for that particular server/container is done. What if there’s a second reboot coming?

It’s a start, at least. :slight_smile: If anyone has any brilliant ideas to make it better, PRs are welcome!

1 Like
6

It’s definitely a very cool package.

I would like to help you. We could also:

  • Make it compatible with Picker.
  • Allow the server to execute a function (hook) when new incident is delivered (if you don’t want to handle it via subscription, but via email, for example).
  • Check the argument passed on the publication (via check or validated publications, for security purposes).

What do you think?

2 Likes
7

Thanks Raphael!

  • Picker: That’s a possibility. I actually was thinking of using Picker, but decided to use Meteor’s built-in webapp to reduce the number of dependencies. I do want to figure out why this package stops working when Picker is used in a project, though. Plus, switching from webapp to Picker may not solve the problem: what if someone is using simple:rest? Will there be collisions between Picker and simple:rest? I’m not sure how to address this issue.
  • That’s a great idea!
  • Good catch. Though it’s a very specific switch statement looking for only “US” or “EU”, and looks pretty airtight. Did I miss something? Or are you just talking about neatly throwing an error if the user passes a number instead of a string?

Feel free to continue the conversation here.

1 Like