What’s the most minimal container config that I need to avoid my customers being hit with a page reload when MDG updates the infrastructure? It seems Galaxy has maintenance periods almost every other day, and having the page reload while a user is working on something is definitely not ideal.
I think they have a “high availability” option which is turned on when you have at least 3 x 1gb containers so the restarts become rolling restarts that don’t interrupt the user experience.
But I’m not sure how and if at all they handle the situations where a user initiated action is awating the result of a server side long running process.
3 containers, I can see. But I don’t see how the 1GB RAM is relevant.
Me neither, but I remember reading somewhere that HA is available to containers starting from 1GB. You should verify that.
Furthermore, this should also provide multi-region availabilty… I think…
Or I am just imagining things and you should hand wavy forget this thread ever happend
1 Like
Haha. No worries. I just wanted to post here before I bug them privately.
1 Like
Ideally all back-end maintenance processes should be set up so that it is seamless and 100% unnoticeable by a user. If that is not possible then it should be announced in advance so that users will know to avoid using the app during the maintenance period. It should be the same when doing your own maintenance (e.g. redeployment after packages updates). During maintenance you may forbid users to log in. Recall how it’s done for internet banking applications.
MDG needs to be mindful of the fact that apps are increasingly making use of monetary transactions, and unannounced reloads when users may be conducting monetary transactions are not acceptable as nobody can guarantee 100% state preservation after reload.
What is the best-practice solution?
My app has a maintenance mode I can enable, and if users want, it’ll even text them when maintenance is over. So right now (I’m in beta), if I get an email from MDG about Galaxy maintenance upcoming, I just set my site to go into maintenance mode at that time, and once I get an email saying Galaxy maintenance is over, I disable my own.
But as I mentioned, Galaxy maintenance/fixes seem to happen pretty often. It’s not practical for me to put my site into maintenance mode every time, I’ll be driving my users away.
2 Likes
That’s an interesting setup for handling maintenance periods. It would be best of course to have everything as automated as possible.
Maybe they should limit their maintenance to a maximum of once per week, and during a usually low utilization period of the week. Though exactly when that should be may vary from one app to another and also in what time zone most users are from. In any case, it’s a serious issue and MDG needs to do something about it.
Yep, I’ve seen that before. But now the big question is, why does the amount of RAM matter?
Perhaps that’s a business decision.
How do you know when galaxy is under going maintenance? We’ve been with them for over a year, but I’ve never heard about any maintenance mode from them.
I’m curious about how you’re implemented your maintenance mode? I want to migrate from mlab to Mongo Atlas, but I don’t have a maintenance mode for my two key apps–(we’ve not had to put them in maintenance mode a single time over the past year).
I’m thinking to just deploy a dummy app (single page with a short message) then after the db migration I can just re-deploy the original apps.
He is using this page: http://status.meteor.com/
You just need to subscribe, and he develop this nice package too: https://atmospherejs.com/ffxsam/galaxy-maintenance
1 Like
Be careful in disabling your app on Galaxy maintenance, sometimes it take hours, so your app is going to be down for hours.
1 Like
What does this galaxy maint package actually do? I see it accepts messages, but does it automatically display a notice or something? If not, what’s the real point of it?
are you guys using uptime monitors for your apps? which one’s work well with Meteor?
No, you handle yourself any warning or action for the user. The package only receives, stores, etc…
The real point is that you don’t need to do the whole wrbhook wiring part of the thing. Which I think is already very cool.
right I see. but how early do they typically issue a maintenance warning? like a day or two?
I don’t really know, to be honest.
To answer some Q’s above:
Correct, the galaxy maintenance package is unopinionated on purpose as far as UI goes. It just handles the API endpoint and dropping the info in your DB, so you can react to it any way you wish.
Correct. But the app knows the date range of the maintenance period, so your app can use that to determine the right time to show a warning.
For instance, in my app’s Meteor container, I pass the following prop into my React component:
incident: GalaxyIncidents.findOne({
$and: [
{ scheduledFor: { $lte: now } }, // now = new Date()
{ scheduledUntil: { $gte: now } },
],
}),
And then in the React component’s render method, I call renderIncident():
renderIncident = () => {
const { incident } = this.props;
if (!incident) return null;
return <div style={styles.incident}>
{i18n.__('maintenance.incident', {
from: moment(incident.scheduledFor).format('LLL'),
to: moment(incident.scheduledUntil).format('LLL'),
})}
</div>
};
1 Like