12:24:51 <jplmoreira> hey! I have a database that does a lot r/w running on a Debian VM. I've been having performance issues and I haven't been able to pinpoint the cause. the volume being used is in ext4. what I find odd is, when I run the VM on a host with ZFS mirror I have better performance (with same issues) than when it is running on a host with RAIDZ3. it seems to me that this might be a virtualization issue? does anyone have any idea what might be c
12:24:51 <jplmoreira> using this?
14:23:12 <nahamu> jperkin: I updated the issue. I have a fresh rebase that didn't seem to misbehave for you to try.
14:33:19 <jperkin> nahamu: great, thanks!
14:36:01 <jperkin> nahamu: is it possible to give the tag a newer date? would make it simpler for packaging
14:36:26 <nahamu> That tag was named for the upstream tag. But I can tag it whatever you want.
14:36:55 <nahamu> I can tag it with today's date if you'd like.
14:38:11 <nahamu> https://github.com/nshalman/wireguard-go/releases/tag/sunos-20231115
14:38:42 <jperkin> oh ok, no if it's based on that version then it should retain it, I'll have to deal with the package version going backwards
14:38:51 <jperkin> I just assumed it was rebased against master
14:39:33 <nahamu> Sorry, I'm just an amateur maintaining a fork that upstream isn
14:39:38 <nahamu> 't ready for yet. :(
14:41:12 <jperkin> no problem - if it's rebased against 0.0.20230223 then it should retain that, if it's rebased against master then the date of the latest commit would be reasonable to use
14:42:14 <jperkin> also ignore me about any version numbers going backwards, I was looking at a modified version of my Makefile where I'd already bumped it..
14:42:43 <nahamu> oh, haha
14:43:23 <jperkin> testing now..
14:47:53 <jperkin> ok, looks like their newest tag is still behind the go 1.21 support, still seeing build failures
14:51:45 <jperkin> I think I'll just patch in the newer gvisor dependency manually
15:15:13 <nahamu> :(
15:15:52 <jperkin> or at least I would if go mod worked, sigh..
15:15:57 <nahamu> Can you force the package to build with 1.20.x for now?
15:16:42 <nahamu> I wasn't able to reproduce the build failure in my current work zone for that stuff. I'll create a new one and see if I can recreate the issue.
15:17:40 <jperkin> unfortunately we don't yet have support for building with alternate go versions in pkgsrc
15:17:57 <jperkin> we provide loads of different versions but packages that depend on go always use the same one
15:18:09 <jperkin> I should probably implement that..
16:17:15 <nahamu> I really can't reproduce the build failure. :-/
16:21:34 <jperkin> yeh don't worry, I implemented GO_VERSION_REQD so it'll be in the next build
19:52:45 <bahamat> jvl: ping
19:59:48 <jvl> bahamat: I'm here
20:43:16 <bahamat> jvl: Hey, sorry for the delay :-/
20:44:17 <bahamat> jvl: So, about docker repos on SmartOS standalone. The situation is that it's never worked with V2 repos and the work/plumbing to get that working with v2 is fairly significant.
20:44:55 <bahamat> So v1 support with stay, but we're not going to mention it in the documentation anymore. I'm not really sure how long v1 repos will stay around, there seem to be fewer of them all the time.
20:46:10 <bahamat> Docker image support will continue indefinitely (because it's part of Triton), but the best way to get them from a v2 server is via an imgapi server rather than directly.
20:48:14 <jvl> bahamat: no worries. I remember some drama around docker wanting opensource projects start paying couple of months ago, I have no idea how that ended.So some "change" was expected ... 
20:48:44 <jvl> is it possible to run imgapi on standalone smartos? I don't have the required IPs or hardware to runn headnode and computenodes ...
20:49:05 <bahamat> Yeah. With v2 it requires requesting an auth token first, then retrying the request, and there's a whole lot more involved with it.
20:49:20 <bahamat> You can run imgapi standalone. images.smartos.org is a standalone instance.
20:49:44 <jvl> would you by any chance have some notes or links to get me started?
20:50:26 <bahamat> https://github.com/TritonDataCenter/sdc-imgapi/blob/master/docs/operator-guide.md#standalone-setup
20:50:43 <jvl> thank you!
20:51:08 <bahamat> The script that we use to launch the instance is intended to be run by operators of a Triton installation, but that's not required.
20:51:28 <bahamat> You can pick apart that script and add the necessary information to the vm on standalone SmartOS.
20:57:24 <jvl> I've skimmed through, it seems that I can use local storage and wouldn't need manta. Is that correct? And also, what is the workflow? I would pull docker image from docker hub and upload it myself to imgapi or can it work as sort of proxy to docker hub?
20:57:35 <bahamat> Yes, that's correct.
20:59:16 <jvl> I
20:59:28 <jvl> I'll need to give it a shot first. thanks