nomon: server resources monitoring & alerting for Cloudron
-
@marcusquinn full-scale for me means threads, calls, rich formatting, notifications management. Guess it's everything that most people found confusing, indeed.
It seems like out experience matches: Rocket.Chat - extremely buggy; Element - specs are not complete, not yet ready for mass production use as team management; Mattermost - looks just right, but quite slow in some of the features and unpredictable with the prices (they managed to change the pricing overnight with no trace of that anywhere at all; twice).
Shall we go back to IRC or XMPP based chats?
-
@potemkin_ai
IRC for the win!I have a funny feeling that's not such an unlikely destination either, given the behaviour of big-tech with our attention.
As I pass through mid-life, I'm starting to think the attention-economy needs and antidote. Everything I do now is choosing once-and-for-all solutions, eliminating or automating as many maintenance needs as possible, and focusing on getting back to enjoying all the free time email was supposed to give from letter post.
-
@potemkin_ai said in nomon: server resources monitoring & alerting for Cloudron:
From what I understand, you package external software from within your GitLab.
Correct, we only want the packaging code to be in our gitlab. For example, you can take the example of recent ctfreak app. The app itself is developed elsewhere (it's closed source) but the packaging code is in our gitlab at https://git.cloudron.io/cloudron/ctfreak-app/ .
Am I right that what you want us to do, it's to publish yml file and some build things, but Docker image could be pushed from GitHub packages? If not, could you please, correct me there?
If you give us the initial Cloudron package for your app, we can take it from there. We don't automate package builds - instead we track upstream releases, make a build and test it. Practically none of the upstream projects I have seen have tests for Docker images. So, that style of publishing doesn't work for us. We have (cloudron specific) tests which test installation, update, configuration, restore, backup etc for every app release. It's quite rigorous and deployment related. It won't make much sense to have all this in your app repos anyway.
The docker image is in docker hub in our org - https://hub.docker.com/r/cloudron/ . This ensures "images" don't disappear (for whatever reason. maybe github goes down, you forgot to pay docker hub, upstream developer went berzerk and made everything private and things like that).
-
@girish thank you and apologies for the delay in getting back to you!
If you give us the initial Cloudron package for your app, we can take it from there.
Would gladly do!
We do have Cloudron manifest file, Dockerfile, and github action to build and push Dockerfile.Please, let me know if there any changes that we can do that would make it easier for you - would it be another push to your Dockerhub, change of license to some of the files, or anything else.
The project is under AGPL to make sure it's development is kept open source and we can license some specific files as Apache 2.0, if required.
The docker image is uploaded to GitHub packages to stay away from Dockerhub uncertainty, but it's not something we will keep tight for.As for the tests - I'm absolutely with you, but we didn't make it... Shall you create them, happy to add them to the main source tree, so that all of the pushes will be verified against them, if you like.
-
@potemkin_ai no worries, thanks. I think we have to think a bit on how to handle this. So far, we have inclined to package widely developed and used apps. This means that the app has users from the get go and it makes sense for us to spend time maintaining the package. In this case, I think you have written an app most likely for your own use. At the same time, you are packaging this only because you think it's probably useful for others as well... Ideas welcome on how to handle such apps
-
@girish thank you for the invitation to think together and direct answer, I understand the logic behind it and I would do the same.
I've been thinking about the options possible and so far I can see the following options:
- separation of platform and app store with adding the ability to subscribe to 3rd party app stores - doesn't seem plausible, as require quite a major rewrite and cooperation with (guess not so many) app-stores developers (think recent case with Redis & PostgreSQL Upgrades) + it's closer to CapRover approach, which feels to be different from yours
- keeping things as is + provide an ability for the users to attach 3rd party app. stores, letting app stores owners and users regulate things on they own - it could be free of charge for some reasons or paid, with billing handled on the app store side
Second approach feels more plausible, as it requires 'not that much' - extend existing apps sideload into a full-scale app store, with listing, install and updates from within the UI.
User access could be restricted by docker's build-in user & password functionality, optionally with IP address limitations.
On the app - it was indeed created from our specific use case, more specifically - lack of monitoring & alerting to the remote endpoints if there are not enough server resources of any kind. If Cloudron could deliver the notifications elsewhere (not only to the notifications dashboard on the interface) - that probably won't be required as such, but I understand it's not at the top of the backlog now, which is something I understand very well.
-
@potemkin_ai thanks for understanding. I think approach 1 is too complicated for us, we rather have one app store with 3rd party apps in it. But to make this happen, we need some development on the appstore side with auth and somehow making sure apps are visible only to specific cloudrons. I don't know when we can find for developing this feature.
-
@girish thanks for the feedback!
Another thing I see from the approach you mentioned, it's that you will have to moderate and manage AppStore and developers - it might be way too complicated for a small team and/or might not be self-sustainable for a big one...
Following up on the only mobile platform with many AppStores - Android - I believe you might want to provide an interface for developers to create their own AppStores or F-Droids or whatever.
-
Given that the Cloudron API already allows to install apps from other sources I think it would already be possible to build something like the f-Droid for Cloudron. like f-droid also only relies on the basic apk install method and not on appstore library listings via playstore.
-
@nebulon right, but that means that I have to:
- do a custom build of cloudron, without the dashboard
- develop and keep extending the dashboard
- maintain & support things
- create my own repository
- gain users
If we speak that Cloudron become a platform, then, I believe, cloudron shall stop developing apps and create everything for the developers to package the apps for you. Few examples could be provided for free, but your main income and way of doing things shall be shifted to get money from appstore and/or licensing your platform to other customers.
I can't see that happening for Cloudron, as nobody cares about the platform and getting proper very careful apps selection and packaging is what, most probably, is driving customers and the cash flow. And if I would be you I wouldn't dare to 'fix' what doesn't seem to be broken.
At the same time, this model could be limiting - you have an ever growing backlog of the apps to be packaged and that is a potential lost business opportunity here (in a good way; business as a service to the people where profit is a way to keep things sustainable and getting better).
I'm not saying I know how to do right - even though it's most probably the way it sound, but I feel the pain and I believe that there must be a good solution, hence keep looking.
My personal stake is that the best way to open the gate - it's to let users to add third party appstores that will act and behave like a first class citizens: they will appear on the appstore dashboard, updates will be rolling, etc.
The only clash I can see there - it's a possibility of the apps or services overlap, but I can see a reasonable agreements that could serve well for both parties. -
@potemkin_ai To be fair, if anyone has packaged an app to Cloudron guidelines, including unit tests, then submission for inclusion in the App Store is fairly trivial.
The bottleneck isn't the allowance or possibility, but the reliance on Cloudron devs to quality control and add unit tests.
Take care of that, as you would likely also want to with your alternative ideas exploration, and you'd have an app App Store ready, already.
The negotiation is only needed when considering changing the platform itself, which is likely always better know by its creators, so pretty good to have their frequent engagement in the debates.
Web Design https://www.evergreen.je
Development https://brandlight.org
Life https://marcusquinn.com -
@marcusquinn it's not packaging, it's support that matters. And without proper incentives, I don't believe there will be anyone willing to get into that.
-
Fascinating conversation. We are looking for Cloudron monitoring @potemkin_ai ourselves.
Ideally you would keep it simple and self-contained enough that it doesn't need access to third-party app stores. In terms of the notifications, it would make sense to build a very simple API which would allow the external services (Rocket.Chat, Mattermost) to pick up nomon's notifications. You could include a sandbox for push notifications along with templates for the major services, and guidance on how to use it.
KIS and focused would be my choice for such an app.
The problem with many open-source people is that we want to cover every need and every possibility and leave every door open. To be everything for everybody doesn't work in the physical world, and to be honest it doesn't work well in the virtual world.
