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

using this?

jperkin: I updated the issue. I have a fresh rebase that didn't seem to misbehave for you to try.

nahamu: great, thanks!

nahamu: is it possible to give the tag a newer date? would make it simpler for packaging

That tag was named for the upstream tag. But I can tag it whatever you want.

I can tag it with today's date if you'd like.

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

I just assumed it was rebased against master

Sorry, I'm just an amateur maintaining a fork that upstream isn

't ready for yet. :(

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

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..

oh, haha

testing now..

ok, looks like their newest tag is still behind the go 1.21 support, still seeing build failures

I think I'll just patch in the newer gvisor dependency manually

:(

or at least I would if go mod worked, sigh..

Can you force the package to build with 1.20.x for now?

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.

unfortunately we don't yet have support for building with alternate go versions in pkgsrc

we provide loads of different versions but packages that depend on go always use the same one

I should probably implement that..

I really can't reproduce the build failure. :-/

yeh don't worry, I implemented GO_VERSION_REQD so it'll be in the next build

jvl: ping

bahamat: I'm here

jvl: Hey, sorry for the delay :-/

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.

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.

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.

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 ...

is it possible to run imgapi on standalone smartos? I don't have the required IPs or hardware to runn headnode and computenodes ...

Yeah. With v2 it requires requesting an auth token first, then retrying the request, and there's a whole lot more involved with it.

You can run imgapi standalone. images.smartos.org is a standalone instance.

would you by any chance have some notes or links to get me started?

thank you!

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.

You can pick apart that script and add the necessary information to the vm on standalone SmartOS.

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?

Yes, that's correct.

I

I'll need to give it a shot first. thanks