08:52:51 <gonzosysadm[m]1> dumb question, someone posted a link to my.mnx.io the other day and i opened it, is that the open source interface for triton? is the open-source version feature-complete? i'm more of a ssh+vmadm guy :p
10:52:41 <zizzy> gonzosysadm[m]1: this is probably the customer end portal that is available for paid support subscriptions, but I'm just guessing
11:36:27 <b-rex> i yelled "hi mnx people" on my way down 75 yesterday
15:56:00 <neirac> tsoome seems that in the latest smartos image things look better I see the nblocks property on the device but the install still fails https://termbin.com/owfvx
15:57:04 <neirac> I compiled ipxe again but in omnios, and with a couple of changes smartos boots successfully using ipxe now I  we just need to find out the disk issue 
15:57:35 <neirac> is the ipxe version or the new smartos image, but now it works in oracle cloud
16:54:48 <barfield> Just checking to see if github issues, are the correct place for bug reports from the OSS community, I saw the last triton bug was opened by me in 2019. 
18:59:28 <bahamat> barfield: They are usually opened in their respective repos. So like in TritonDataCenter/sdc-vmadm, not just in TritonDataCenter/triton.
19:04:45 <barfield> That makes sense. So would I open an sdc-migrate issue under sdc-vmapi then? Or under tritondatacenter/sdc?
19:04:51 <bahamat> gonzosysadm[m]1: The only difference between open source Triton and paid support Triton is whether you're paying for support.
19:05:01 <bahamat> Yes, sdc-vmapi.
19:05:05 <barfield> cool
19:11:23 <bahamat> barfield: With migration issues, I'll need exact reproducible steps. "something weird happened one time" isn't really something that can be diagnosed.
19:13:17 <bahamat> Any time a vm is altered outside of triton itself, it makes it an outlier and things can go wrong.
19:14:22 <bahamat> And by "outside of Triton", that is really more like outside of cloudapi. Calling the APIs directly can change a vm in a lot of ways that sdc-migrate might not expect.
19:15:52 <bahamat> Also stuff like "cn panic'd partway through and now it's wedged" isn't considered a bug, because that's what the rollback stuff is for.
19:16:59 <barfield> https://github.com/TritonDataCenter/sdc-vmapi/issues/89
19:17:16 <barfield> This can be reproduced on a fresh VM provisioned from cloudapi
19:17:42 <bahamat> Ah, so that happens any time indestructable root is set?
19:17:49 <barfield> yes sir
19:17:58 <barfield> I've encountered this numerous times
19:18:04 <barfield> So I finally decided to report it lol
19:18:08 <bahamat> Cool, that's a perfect example of a good bug with migration.
19:18:12 <barfield> Do you need version info?
19:18:33 <bahamat> Nah.
19:18:53 <bahamat> So next Triton release is Feb 9. I'll try to get this in for that.
19:19:02 <bahamat> It should be fairly simple.
19:19:05 <barfield> awesome! Thanks man
19:19:32 <barfield> Yeah I kind of thought and in looking at the source I didn't see any functionality pertaining to the indestructible setting, so I didn't really think that this was currently version specific
19:20:15 <bahamat> So the migration works, but it leaves a mess on the source, right?
19:20:20 <barfield> I'll look at it again, if I think I could fix easy enough I'll shoot over a PR unless you want me to leave it alone and let you guys handle
19:20:23 <barfield> That is correct
19:20:29 <barfield> And it also cannot start on the destination
19:20:32 <barfield> Sorry
19:20:36 <barfield> let me clarify
19:20:36 <bahamat> And because it leaves a mess, it considers that the finalization failed.
19:20:39 <barfield> It does not start
19:20:43 <barfield> right
19:20:47 <bahamat> Ok, yeah, that makes sense.
19:20:57 <bahamat> Does the new copy have deletion protection?
19:21:04 <barfield> I didn't verify though, let me do this now, if it does set the boolean on the destination cn
19:21:07 <barfield> LAMO
19:21:11 <barfield> checking that now
19:22:07 <bahamat> It might inherit it from the zfs send.
19:22:19 <barfield> I was wodnering since its just a snapshot basically
19:22:45 <barfield> from my command history it appears to fail on the "switch" step
19:23:34 <barfield> It does set the value to true on the destination node
19:24:42 <barfield> Also oddly the error that I saw was "unable to `zfs set quota=0`" I didn't copy the error though so I am not sure where it was claiming that error to be true. 
19:25:06 <barfield> That seemed buggy as well, since zfs set quota=0 doesn't work, syntax is zfs set quota=none
19:25:27 <bahamat> Yeah, that sounds weird.
19:25:51 <bahamat> TRITON-2127
19:25:51 <jinni> Sorry, TRITON-2127 is not public.
19:26:01 <barfield> All good, I figured its your own jira
19:26:01 <bahamat> Well let's fix that.
19:26:14 <barfield> Should I update those details in the github issue?
19:26:23 <bahamat> TRITON-2127
19:26:23 <jinni> https://smartos.org/bugview/TRITON-2127
19:26:55 <barfield> oh hell, thats an old bug haha
19:27:05 <barfield> regression maybe?
19:27:15 <bahamat> So...yeah, your version info may be relevant here :-)
19:27:19 <barfield> I see a fix appears to have been merged in
19:27:31 <barfield> I'm only like 2 releases behind current
19:27:36 <barfield> which is like June 2022 I think
19:27:57 <bahamat> There's fixes in both sdc-vmapi and cn-agent.
19:28:01 <bahamat> You need both for it to work.
19:28:04 <barfield> Is jinni a user or is that like joybot haha
19:28:20 <barfield> Do you know which Triton release those were in?
19:28:24 <bahamat> It's a bot
19:28:31 <barfield> cool
19:29:12 <barfield> 9e1d678a-5686-474f-9b98-14c98626dc9c
19:29:14 <bahamat> release-20200521 and later
19:29:33 <barfield> sorry
19:29:42 <neirac> bahamat is there documentation on how to setup a netboot server for smartos? I need to test some changes in smartos and the only way to test them is through ipxe (is faster really)
19:29:49 <barfield> I thought that sdcadm services is where versions were at
19:30:33 <barfield> oh I found it `sdcadm insts`
19:30:53 <barfield> release-20220825-20220825T003215Z-g6ac7d1c
19:31:15 <barfield> This is a bhyve VM BTW
19:32:10 <bahamat> neirac: Mostly it's just clone the repo and run `tools/setup.sh`, though it makes some assumptions about our own deployment (e.g., cert names).
19:32:45 <barfield> ^release is vmapi
19:33:24 <barfield> cn-agent 2.14.7
19:34:46 <barfield> I'll update the issue with the rest of these details, I know you're probably slammed
19:35:52 <bahamat> I'm also on vacation right now :-)
19:36:07 <barfield> so youre an addict or a masochist? haha
19:36:18 <barfield> I'm on PTO too lol
19:36:50 <bahamat> Well, today is the SmartOS office hours, so I was checking in just on my own.
19:37:30 <barfield> I had thought for a bit that maybe you were taking an IRC break and I wouldn't blame you a bit if you did
19:38:15 <bahamat> Mostly, yes.
19:40:57 <barfield> Are the details that I added enough? I think that I got everything. Will stop bothering you. Hopefully you're near a beach and a beach-bar :)
19:56:12 <barfield> okay done spamming you with github edits
20:21:57 <barfield> danmcd: I saw something on the illumos developers list discussing kernel memory exaustion with i40e NIC when dladm generates VNIC's. I was actually hitting this issue on a compute node the other day that had 3 VM's provisioned and I think around 24G of free RSS on the compute node. the PI is from 202206, but I am wondering if anything has been updated in the driver since June to enhance memory 
20:22:03 <barfield> management, to determine if I should do some PI updates on Triton. 
20:22:50 <barfield> I haven't found anything specifically in release notes yet...thought you might be aware of something that I wasn't was all
20:58:06 <neirac> using the triton repo for creating netboot server worked, thanks bahamat.