kentonv changed the topic of #sandstorm to: Welcome to #sandstorm: home of all things sandstorm.io. Say hi! | Have a question but no one is here? Try asking in the discussion group: https://groups.google.com/group/sandstorm-dev
TC01 has quit [Ping timeout: 255 seconds]
TC01 has joined #sandstorm
<isd>
sigh if we're going to go to the trouble of all of this upgrade nonsense, I almost wonder if it's better to switch away from mongo entirely, to something that doesn't change its storage format.
<isd>
basically every solution I can think of to this ws is a huge amount of work.
<xet7>
I have found ways to upgrade Wekan. But my tries get even something similar basic functionality for other kanban just get stuck.
<isd>
I dont really put much stock in COCOMO; I've seen it give way too many completely nonsense estimates. But point taken.
<isd>
I kinda really don't want to have to deal with this for meteor-spk either, but I'd prefer not to throw wekan under the bus there.
<xet7>
From https://www.openhub.net/p/wekan/factoids#FactoidActivityStable : Very large, active development team: Over the past twelve months, 54 developers contributed new code to Wekan. This is one of the largest open-source teams in the world, and is in the top 2% of all project teams on Open Hub.
<xet7>
I don't know is it correct, but I like that kind of stats anyway :D
<isd>
Fair enough.
<CaptainCalliope>
<isd "I kinda really don't want to hav"> How would "not dealing with" meteor-spk throw wekan under the bus?
<isd>
It would mean xet7 would be on his own wrt. updating meteor in wekan.
<isd>
...and basically have to deal with the same nonsense I'm wanting to avoid.
<isd>
More broadly I'd rather focus development efforts on supporting tools that are actually a good fit for sandstorm apps, which mongo isn't really. But I also don't want to abandon the maintainer of one of our most popular (and most consistently updated) apps.
<isd>
Right now, meteor-spk apps ship with two versions of mongo, both of which are very out of date.
<isd>
One of them is our own fork of mongo 2.x to get it to not pre-allocate gigabytes of space on startup.
<isd>
I can't get that one to build.
<isd>
The other is mongo 3.x, which I need to patch to get to build.
<isd>
This would be nicer if we could eventually kill old versions of mongo.
<isd>
There's a field in the sandstorm pkgdef that can indicate the oldest version of app that it is possible to upgrade from.
<isd>
I'm tempted to suggest that we ask meter-spk users to set that to some version of their app after the upgrade, and remove the older fork.
<isd>
meteor-spk
<isd>
We probably need to do a couple cycles of updating mongo to get it up to date. I think the version we're shipping now is 3.0, but 4.0 can't upgrade from anything older than 3.6
_whitelogger has joined #sandstorm
<ocdtrekkie>
We've never used that oldest version it's possible to upgrade from field.
<ocdtrekkie>
I am curious if Sandstorm handles the logic for that well/at all. Will it just not let you upgrade a grain? Will it offer you an upgrade to the latest package it can upgrade and then let you upgrade again?
<ocdtrekkie>
I am bad about upgrading older grains (because I get nervous about breaking them), if other people also do that they might find permanent breakage in there.
_whitelogger has joined #sandstorm
<isd>
Should definitely look into that. Ideally we'd try to automatically just do update to latest compatible version.
<isd>
...but I really do not want to have to be building "niscudb" in a year's time.
* isd
looks
<isd>
Yeah, it's not actually used anywhere in the code. We should implement that before we recommend people use it, obviously.
<xet7>
isd: I can deal with Meteor and MongoDB nonsense, you can do something else that is more interesting for you
<xet7>
isd: Well, at least I "think" I can, like I have done with Meteor for 3 years, and somehow got those upgraded
<xet7>
It could also be that sometime I will figure out how to add other database support to Wekan, and do migration automatically
<xet7>
On Docker, Wekan can use newest MongoDB. On Snap, it's still MongoDB 3.2.22, because I have not figured out how to get newest MongoDB running on Snap.
<xet7>
Both Docker and Snap run newest Meteor 1.9.2
<xet7>
with newest Node 12.16.1
<xet7>
At Sandstorm is newest Wekan with old Meteor, Node and MongoDB
<xet7>
In general, at each platform I sometime figure out how to update something
<xet7>
I don't know how critical it is that Wekan on Sandstorm does not have newest Node. Old node does have some vulnerabilities.
<xet7>
Those could be issue if there is public grain
<xet7>
But that depends how those could be exploited
<xet7>
On public grain, non-logged in users can not write to database
<xet7>
Does node vulnerability allow to do something harmful
<xet7>
And if it allows, then it affects that grain
<isd>
I'll probably put meteor-spk on the back burner then.
TC01 has quit [Quit: No Ping reply in 180 seconds.]
TC01 has joined #sandstorm
XgF has joined #sandstorm
XgF has quit [Client Quit]
XgF has joined #sandstorm
<CaptainCalliope>
I'll see missing the call today. The call, which is in 20 minutes.
<CaptainCalliope>
Someone should drop the link.
<CaptainCalliope>
* I'll be missing the call today. The call, which is in 20 minutes.