<jfred>
Hmm... I assume this isn't possible now as the docs don't mention it, but how difficult would it be to get vagrant-spk working with libvirt/qemu rather than virtualbox? The distro I currently use doesn't have virtualbox packaged
<jfred>
(doesn't have vagrant packaged either, but I assume that should be easier to get running outside the package manager as it doesn't involve kernel modules and stuff
<isd>
I can't imagine it would be that hard.
<isd>
Try vagrant-spk vm up --provider=libvirt and see how far that gets you.
<jfred>
oh nice, thanks! will give that a try
<jfred>
mmm, appears vagrant-spk doesn't pass that argument through
<isd>
you can probably get around the first problem by doing cd .sandtorm; vagrant up --provider=libvirt.
<JacobWeisz[m]>
libvirt has been used with vagrant-spk before, but some hackery may be necessary.
<JacobWeisz[m]>
The biggest issue with the box used, I think, is that virtualbox shared folders are used for working with the app both inside and outside the VM, I'm not sure how that behaves in the scenario in the above issue.
<isd>
I think the Vagrantfile in the root of the sandstorm repo (not vagrant-spk) has some more portable logic for shared directories; might make sense to see if that can be adapted
<isd>
It's also quite possibly bitrotten; I don't know if anyone actually uses that.
<JacobWeisz[m]>
I recall that one only being intended for testing or hacking on Sandstorm itself. I know I pushed some updates to it from the vagrant-spk Vagrantfile at one point, but I haven't used it.
<jfred>
for the time being I can use the ubuntu desktop that I've just gotten set back up with virtualbox... maybe long-term I'll be the one to package virtualbox for my usual distro haha
<JacobWeisz[m]>
jfred, it's worth asking what your intended use is too. If it's hacking on existing vagrant-spk apps, that may be a good path forward. If you want to develop apps yourself, "raw" spk or docker-spk might be a viable choice.
<JacobWeisz[m]>
vagrant-spk makes a lot of assumptions (Ubuntu as the box, Virtualbox, etc.) but other spk dev tools are often less opinionated.
<jfred>
mostly hacking on existing vagrant-spk apps to start, I think - in particular I'd like to try my hand at adding static site export to the dokuwiki app
<JacobWeisz[m]>
That being said, they will also hold your hand less. Which is great for some people, but less great for others. :)
<JacobWeisz[m]>
Ah, very cool.
<jfred>
my hackerspace is in the middle of a website refresh, and there's a wordpress sandstorm app that we've been using - but not a wiki app with static site export yet
<jfred>
(and our wiki is also badly in need of a refresh :P)
<JacobWeisz[m]>
I love my DokuWiki grain, so I am always excited about development there.
<isd>
One of these days I still want to get together a toolchain built on top of nix or guix.
<jfred>
guix was the distro I was referring to as my daily driver, so... that'd be very appealing to me ;P
<isd>
It'll happen faster if you pitch in ;)
<jfred>
fair :P
<isd>
It is endlessly frustrating that I am only one person.
<jfred>
I really need to actually get somewhere with my programming projects; I have much more of a sysadmin focus, so traditional distro packaging is right up my alley, but guix packaging is also scheme programming (which I like, but also am not super skilled at yet)
<isd>
Building a hypothetical guix-spk seems like the perfect project then :P
<jfred>
I suppose some of the machinery's already there with the 'guix pack' stuff
<jfred>
now, a slightly more... ambitious question: sandstorm seems extremely tailored towards small webapps, and it's great at handling those, but what would it take for it to be able to run long-running non-HTTP services? say, a game server.
<isd>
Presumably the existing support for docker images & such would provide useful examples.
<isd>
I mean, it can do long-running non-http now.
<isd>
I to say more I guess I'd need to pin down more details about requirements
<jfred>
oh, interesting
<isd>
It's possible to request a "wake lock" if you need to stay running for some reason -- though you might not depending on use case, if waking up in response to traffic is an option.
<isd>
And there are ways of requesting direct network access, both inbound and outbound, though it requires being an admin currently.
<jfred>
ah right, I did see network capabilities in the admin panel
<isd>
There are design questions about what non-web apps should look like; I think we'd like to find ways for relatively few apps to need broad privileges, and we have some rough ideas involving "driver apps," but there hasn't been that much actual action on building that infrastructure out, or kicking the tires on what's in there now.
<jfred>
I guess I was assuming that all sandstorm apps would be terminated automatically without an active user (which is easy to determine if they're a human logged in through the sandstorm UI, potentially less easy outside of that) ...but now I'm wondering, if apps can do that, is there any way I as an admin can limit the resources my users might use?
<isd>
Right now, not really. Longer term I'd like to have more options for admins to control this kind of thing.
<jfred>
fair enough
<isd>
It's actually active network traffic that does it, not UI login per se.
<jfred>
oh, huh
<isd>
So you don't necessarily need to keep an app running, as long as it can start quickly enough in response to a request.
<jfred>
(that might actually explain some of the behavior I've seen on ttrss grains that I've left open for long periods of time)
<isd>
depends on the use case. For the IRC bouncer, it obviously needs to maintain an active connection...
<isd>
Oh?
<jfred>
after leaving a ttrss grain open for a while without checking it, sometimes when I come back to it there'll be broken images in the ttrss sidebar
<jfred>
maybe that's a bug and I should report it somewhere :)
<isd>
I've been mostly working on stuff outside of Sandstorm proper. Have a semi-working implementation of the media-csp stuff, but it's not quite ready.
<isd>
I'll probably spend some time on this coming week
<JacobWeisz[m]>
#3497 is there mostly, but we probably need more consistently-failing tests before it can be merged.
<JacobWeisz[m]>
And since it's test related, it's not important towards a release weekend.
<kentonv>
hmm so I have 7 failing tests, is that expected? All I did was update dependencies...
<JacobWeisz[m]>
I know a few, as mentioned in 3497, have been inconsistent.
<kentonv>
seeing a few: `TypeError: window.loginDevAccountFast is not a function`