I am wondering how mup is perceived in the community right now. From my end, I am relying 100% on it, because I have to host our Meteor-based research software on our own infrastructure.
I know that mup is not @zodern 's #1 project right now and I don’t want to be alarming but I am investigating alternatives, which I don’t see. At the same time I feel totally useless in contributing to the project as I am still totally under-experienced in the whole container landscape.
Are there any efforts to support mup in the future by @zodern and does it make sense to - in the meantime - continue to work on mup on a community fork?
We host bigger apps on Galaxy b/c of the support and built in DevOos. But for many smaller apps and microservices, Mup is mission critical and if it were not available, I’m not sure we’d use Meteor.
It’s exciting to see so much interest in Meteor Up still.
I also heavily use Meteor Up, but have gotten behind on maintenance. 4 years ago I was working on a major improvement (I gave a presentation at Meteor Impact about what I was working on, but somehow it wasn’t uploaded to youtube like the other presentations that year). While working on it, I realized there were fundamental issues with how plugins work. Basically, mup is a cli tool for loading and running plugins, which is good, but the specifics of how plugins and the config work prevents a number of improvements, or requires hacky implementations.
I have ideas on how to fix it, and have been occasionally looking at it, but haven’t dedicated enough time to find the path forward. Also, I had been working on Monti Deploy at the time, which was a deployment service built on top of Meteor Up, but instead of adding resources to mup, it instead became a distraction from mup and Monti APM (I’m planning to eventually open source it as a dashboard for Meteor Up).
It would be great to have more people involved in the project. I would love to add maintainers; I don’t think a fork is necessary. This might also be a good time to create an organization for Meteor Up, since there’s quite a few repositories involved, and document the triage process and principles the project follows, since we found doing things a little differently makes more sense for this type of project.
I use the beanstalk plugin for AWS and will be looking to do some updates soon.
We do as well, actually IIRC we have a fork of a fork you made, so thanks @paulishca. We’d like to move away from using EB though and switch to containers of some flavour in the near future. But still use MUP.
(I’m planning to eventually open source it as a dashboard for Meteor Up)
Exciting!!
It would be great to have more people involved in the project. I would love to add maintainers; I don’t think a fork is necessary. This might also be a good time to create an organization for Meteor Up, since there’s quite a few repositories involved, and document the triage process and principles the project follows, since we found doing things a little differently makes more sense for this type of project.
This would be great. We’d definitely be interested in helping out, either through submitting PRs or sponsoring work.
@zodern this is great! How would you proceed from here? I could start triaging issues so we can craft a potential roadmap. What do you think? Anyone else who is willing to work on mup?
I have upgrades to ESM and up-to-date libraries for mup and the aws beanstalk plugin. The beanstalk plugin now supports launch templates instead of the old launch configuration.
I pushed with them already, and they seem to work fine, but I would need more real-life testing and more diversity of configurations. I now use it from here:
Do you know about a way to run the AWS beanstalk plugin in combination with Redis? I tried this quite some time ago but learned that they were not compatible. Which basically left us without any load balancing or zero downtime protection in place.
I created an issue for tracking the next release, Mup 1.6: Mup 1.6 Roadmap - attempt 2 · Issue #1382 · zodern/meteor-up · GitHub. I’ve started some of the initial work, and I’ll push it this week. If you want to triage and start a roadmap, that would be great. There is a roadmap file in the repository, but it is very outdated.
@paulishca those changes look good. I’ve been working on similar changes with updating mup to ESM. After I push the latest code, if you want to open PR’s for any improvements, I would really appreciate it.
For mup-aws-beanstalk, there’s a number of people that have been working on forks. I would love to see if anyone using it would be interested in working together and maintaining the original, instead of all of the improvements being spread between the different forks.
The mup plugin for redis isn’t compatible with aws beanstalk (same with the mup mongo plugin), but there are a number of hosted redis services, or you can run redis yourself on EC2 which should work with beanstalk. The main thing preventing the mup database plugins from working with aws beanstalk (or with any app that runs on multiple servers) is mup currently is unable to manage a firewall, so the database plugins are limited to when it can run on the same server as the app which we can secure.
