16:21:23 <danmcd> release-20220922 has been announced.  Folks who serve NFS (zone or global) should make sure their hostname is in name services or else mountd won't start.
17:36:17 <jbk> maybe soon(ish) the zfs alias stuff will be in too :)
17:36:48 <bahamat> Unlikely...
17:37:43 <bahamat> I talked to both Alex and Josh about it, and superficially it seems easy, but the more you use it, the more lies you need to tell in order for things to work.
17:37:56 <jbk> well it'd probably need some plumbing for smartos zones
17:38:01 <bahamat> It's like a fractal of edge cases.
17:38:04 <jbk> but it could be used for the 'data' dataset
17:38:23 <bahamat> But it's not just the dataset. You need to fabricate a pool.
17:38:53 <jbk> and how often does anything run a zpool command inside a zone?
17:39:01 <bahamat> Plenty often.
17:39:22 <jbk> for what? the only thing you can do with _zpool_ in a zone is basically 'list' or 'status'
17:39:51 <bahamat> list shows size, compress ratio, all the properties, etc. What to do with them?
17:40:08 <bahamat> status shows device geometry.
17:40:26 <bahamat> Then there's zpool iostat
17:40:28 <jbk> and why would you be looking at that from within a zone vs. the gz (where none of this applies)
17:40:40 <bahamat> But so many people do.
17:41:04 <bahamat> In JPC we had customers that were monitoring disks, and would open tickets with us if there were errors.
17:41:22 <bahamat> Like, we already knew and were handling it. But they'd open a ticket anyway.
17:42:10 <bahamat> But like what all breaks if we just shut that stuff off inside a zone? No idea, because it's always been there.
17:43:13 <jbk> if it's a new brand (it's not like it does this automatically -- you have to specify an alias in the zonecfg)..
17:43:58 <bahamat> As in vmadm create brand=not-joyent?
17:44:36 <jbk> there's already dones for kvm and bhyve.. could call it 'mnxio' :)
17:44:49 <jbk> (e.g. joyentv2) or such..
17:46:11 <bahamat> Yeah, but if the difference between an mnx brand and joyent brand is that a ton of zfs utilities are broken, nobody will use it.
17:49:13 <bahamat> At any rate, it's extremely unlikely that it'll be in SmartOS first. If it shows up in gate, we'll make it usable in SmartOS.
18:00:18 <jesse_> will a newer platform image show more in 'imgadm avail' or is the list always up-to-date and trying to use images requiring newer platform will just fail?
18:00:52 <nahamu> do you mean 'piadm avail' ?
18:00:52 <jesse_> ...platform just fail
18:00:57 <jesse_> imgadm
18:01:23 <jesse_> there are minimum platform requirements for images
18:01:26 <nahamu> Ah.
18:01:28 <jesse_> not sure how it is used
18:01:37 <nahamu> Probably in Triton for scheduling.
18:01:59 <jesse_> well, if a lx-zone requires more support from the platform...=)
18:31:07 <neuroserve> jesse_ : afaik 'imgadm avail' gives you a current list - including all available images - regardless of minimum platform requirements - those are only checked while provisioning an instance - you will not be able to provision it if your platform is older than the minimum platform required for that image
18:31:56 <jesse_> so... updating the PI won't help me and I'll have to roll my own lx image (urgh)
18:32:25 <jesse_> expect cursing here about the PI built-in scripts for different distros=)
18:32:53 <bahamat> jesse_: What is it that you're wanting?
18:33:07 <jesse_> something new linux
18:33:19 <jesse_> (not feeling like doing updates to it anytime soon)
18:33:49 <bahamat> Is there a distro called literally "something new"?
18:33:59 <jesse_> probably ubuntu 22.04, as I've been using it in other contexts lately (due to native zfs support)
18:34:26 <jesse_> bahamat, not-centos-not-ubuntu-20.04
18:35:03 <bahamat> ubuntu 22 shouldn't be too hard
18:35:13 <jesse_> I wonder if I have the energy to get almalinux running
18:35:29 <jesse_> that's what I'd most likely run on lx in the long run
18:37:04 <jesse_> I had some problems with ubuntu 21.10, but no idea what they were
18:37:21 <jesse_> I assume I'll find out if 22.04 fixed those=)
18:38:18 <jesse_> how is the lx image build repo nowadays? it didn't do something the last time and it was easier to do all manually
18:38:30 <bahamat> There's two parts to it.
18:38:39 <bahamat> First there's this: https://github.com/TritonDataCenter/lx-images
18:39:03 <bahamat> That's a fork of OmniOS's LX image repo, but there's currently no changes in ours.
18:39:11 <bahamat> Then there's this: https://github.com/TritonDataCenter/smartos-lx-img-builder
18:39:34 <bahamat> which takes a tarball produced by the lx-images repo and converts it to a SmartOS image.
18:39:36 <jesse_> it already has ubuntu 22.04, so it'll probably work without much hassle
18:40:01 <bahamat> Yeah, we should be able to just run the conversion and be done.
18:44:08 <jesse_> bahamat, https://github.com/TritonDataCenter/smartos-lx-img-builder: readme should probably tell in what environment to run it (gz/zone?) and steps to get the target/debug/smartos-lx-img-builder?
18:44:33 <bahamat> I agree.
18:44:47 <bahamat> And since I need to re-figure that out, I'll write it down this time :-)
18:44:59 <jesse_> oh, it's rust=)
18:45:00 <bahamat> IIRC, it works fine in a zone
18:45:18 <bahamat> The main requirement is a delegated dataset.
18:46:06 <jesse_> having img-builder as an img wouldn't be a bad idea?
18:46:27 <bahamat> Maybe.
18:47:46 <jesse_> my previous solution used docker (OCI) images as base and just edited their filesystems
18:48:15 <bahamat> Yeah, I think that's what these actually do as well.
18:48:19 <jesse_> easy way to get plenty of application images without re-doing the dockerfiles
18:49:02 <jesse_> last time I checked omnios did get the container tars from the releases and did the base image properly
18:49:43 <jesse_> my solution was the less 'proper' one, as there was no shared parent of OS image
18:50:39 <jesse_> uh, no, and yes
18:50:54 <jesse_> omnios uses dockerfiles to setup the images=)
18:52:01 <jesse_> bahamat, for smartos-lx-img-builder: a description what it does/adds to the images would be nice
18:52:17 <bahamat> Yeah, I'm going to add that.
18:52:19 <jesse_> "adds joyent service to systemd" etc.
18:55:11 <jesse_> smartos really needs native podman support
18:56:52 <jesse_> (I ditched docker-the-runtime-and-command couple of years ago and after using podman for a while all these dockerfile/smartos image systems are a major pita...)
19:13:01 <bahamat> vmadm will always be the primary way to run instances on SmartOS.
19:13:24 <bahamat> It's necessary for Triton
19:13:45 <bahamat> But we've always wanted to make it easier to run lx containers with it.
19:17:06 <bahamat> jesse_: give this a try:
19:17:10 <bahamat> https://us-central.manta.mnx.io/bbennett/public/ex-images/ubuntu-22.04-20220923.json
19:17:24 <bahamat> https://us-central.manta.mnx.io/bbennett/public/ex-images/ubuntu-22.04-20220923.zfs.gz
19:18:00 <bahamat> If that works out for you, I'll publish it.
19:18:16 <bahamat> I haven't tried it at all, I just ran the conversion.
19:19:53 <jesse_> bahamat, not the instace things
19:19:58 <jesse_> bahamat, to build images
19:21:01 <jesse_> *not to instance
19:21:25 <jesse_> basically a little bit better zlogin
19:21:26 <bahamat> Well then podman needs to have a vmadm (or at least zonecfg/adm) backend for running them
19:21:47 <jesse_> yeah, that's why I said "smartos really needs native podman support"=)
19:23:14 <bahamat> What you mean is podman needs native smartos support
19:23:31 <bahamat> It's going to have to be on them to want SmartOS support.
19:23:45 <bahamat> There's no way we can shove it down their throats if they don't want it.
19:24:02 <jesse_> you can "podman create from scratch" that gives you an image with no fs (smartos: /native there?). then just "podman $ctr <any shell command>" to run commands in the context of root-of-that-image without any services running, and "podman mount $ctr" to mount the fs (in smartos just /zones/$ctr/root/)
19:24:39 <jesse_> mostly the second part is thing I miss
19:24:45 <bahamat> Are you saying this works now?
19:24:59 <jesse_> it works in linux with podman
19:25:17 <jesse_> (hence, "smartos really needs native podman support")
19:25:53 <jesse_> I'm seeing myself running more and more bhyve just because the build-an-image tooling is so bad on smartos
19:26:03 <bahamat> So far it doesn't seem like there's anything that SmartOS can do to support podman.
19:26:13 <bahamat> It seems like it's the other way around.
19:26:33 <jesse_> like you said: podman devs won't do anything
19:26:46 <jesse_> so, "smartos really needs native podman support", mentioned here
19:26:48 <bahamat> So I don't really know what you're asking for.
19:27:16 <jesse_> that's probably part of the problem
19:27:20 <jesse_> you don't even see the problem
19:27:36 <jesse_> (that was just a neutral statement)
19:27:50 <bahamat> It's not that I don't see the problem. I don't see how you're suggesting smartos be modified to accommodate podman.
19:29:00 <jesse_> suggesting getting smartos support into podman
19:29:22 <bahamat> How exactly does smartos need to behave differently for that to happen?
19:29:22 <jesse_> it's not 'smartos' development, but then again bhyve wasn't, either?
19:29:55 <bahamat> I don't really think that's the same thing.
19:30:07 <jesse_> smartos devs need to add the support. Possibly have some tuning of being able to run things "in a zone" without the zone being 'running'
19:30:29 <jesse_> it's the same thing, see: bhyve
19:30:37 <jesse_> see: java
19:30:42 <jesse_> see: node
19:30:45 <jesse_> see: ...
19:30:55 <bahamat> Ok, well you're free to send me a pull request any time you want.
19:31:04 <jesse_> ...I was expecting this=)
19:31:21 <bahamat> I can't tell if you're asking me to modify smartos or if you're asking me to modify podman.
19:31:39 <jesse_> if I had the time to do all the runtime support on smartos, I'd start with openjdk
19:31:42 <jesse_> ...which I've done
19:31:48 <jesse_> and I no longer have the time for
19:32:02 <bahamat> I'm not trying to be obstructionist. Like, let's say I agree wholeheartedly and am ready to sit down and write code...what is it supposed to *do*?
19:32:12 <jesse_> I'm asking podman to work on smartos as image-building tooling
19:32:41 <bahamat> Then I think what you're asking for is for the podman developers to add support for running on SmartOS.
19:33:08 <jesse_> I think the first step would be to get podman on some linux and see how it works and do some exploration to see what I'm even talking about
19:33:09 <bahamat> And like I said, even if I went through all the work of adding SmartOS support to podman, I doubt they'd be willing to merge it just because I asked.
19:34:04 <jesse_> there are (at least parts of) podman that are services that can be added
19:34:36 <jesse_> the build thingy probably less so, it's probably married to linux namespaces to some degree
19:34:41 <jesse_> (I haven't looked)
19:35:08 <bahamat> It would need to add zones as a backend.
19:36:25 <jesse_> looking from other angle, zones backend would be need to be added
19:36:41 <bahamat> That's...exactly what I said.
19:36:52 <jesse_> it's from the opposite direction
19:37:17 <jesse_> you said podman needs to add one, I said smartos needs to add one
19:38:11 <bahamat> Smartos already has a zones back end
19:38:31 <jesse_> not with the interface required for podman
19:38:38 <jesse_> if there even exists one yet
19:38:47 <jesse_> if it doesn't it needs to be added
19:38:49 <jesse_> etc.
19:40:16 <bahamat> So you're suggesting zones be modified or replaced with something that's compatible with linux namespaces for the purpose of running podman on SmartOS?
19:40:43 <jesse_> no
19:40:57 <jesse_> in interface glue in between podman and smartos zones
19:41:13 <jesse_> as +
19:41:23 <bahamat> lx brand zones are already that glue.
19:41:36 <jesse_> they are the _runtime_
19:41:38 <bahamat> But, lx doesn't support nesting.
19:41:42 <jesse_> (and not a really good one at that)
19:41:56 <jesse_> what I'm talking about is actually _making_ the zones
19:42:32 <jesse_> this has always (since docker was released) been the achilles heel of smartos
19:42:39 <jesse_> there is no easy way to make the images
19:43:10 <jesse_> (there is a way, but it's not something that's used easily)
19:45:36 <jesse_> in real-life environments I've seen, there are tens of different containers, when zones act more like the hw/virtual machines the containers are deployed on
19:45:54 <jesse_> (real-life linux/container environments)
19:46:29 <bahamat> Well, an image is a zfs dataset.
19:46:41 <bahamat> So it's just a matter of having a dataset and dumping files onto it.
19:46:54 <jesse_> but the tooling is not there
19:47:26 <jesse_> let's take an example, how will you build and image that is this dockerfile: https://github.com/TritonDataCenter/lx-images/blob/master/centos-stream/Dockerfile
19:47:47 <jesse_> that's like 3-4 podman commands
19:49:10 <bahamat> Ok, fine, but modifying the OS so that it behaves like a completely different OS is a tremendous undertaking.
19:49:16 <jesse_> (and yes, the commands _are_ that dockerfile, it's just two different toolings doing the same thing)
19:49:24 <jesse_> it's not about the os
19:49:43 <bahamat> And trying to convince a 3rd party that they should support my OS is also not easy.
19:50:12 <jesse_> because the podman interface is 'instantiate an empty container', 'copy files to a container', and 'run commands like you were in the container'
19:50:30 <jesse_> you're not convincing them
19:50:33 <jesse_> you're doing the work
19:50:54 <jesse_> that's what I call 'adding a native support'
19:51:16 <jesse_> (you being the abstract people developing smartos)
19:52:05 <bahamat> Yes, then I send them a pull request and they say "thanks but no thanks"
19:52:31 <jesse_> then you make the things that they didn't want an interface for support for other platforms
19:52:40 <jesse_> submit that and ship your implementation in the PI
19:53:41 <bahamat> I don't know if you've ever maintained an open source project before, but generally people don't like people who are not part of the project suggesting large new subsystems.
19:53:57 <jesse_> example: you now
19:54:03 <jesse_> yes, I know
19:55:01 <bahamat> You still haven't given any suggestions on how to change SmartOS so that podman just works unmodified.
19:55:12 <jesse_> I've given up on using several oss software because their devs are poondering their own orb instead of looking around what's needed
19:55:50 <jesse_> bahamat, 'left as an exercise for the readers', as in if I did, it'd be in the form of a pull request
19:55:51 <bahamat> All you've said so far is "make it work". Ok, what does that entail?
19:56:06 <jesse_> 'I have not looked into it to give you steps'
19:56:15 <jesse_> I'm not your project manager
19:56:30 <jesse_> I can give you input on what is needed or would be goood
19:56:35 <bahamat> Even "looking into it" is going to take days to weeks at minimum.
19:56:47 <jesse_> hours to days
19:56:49 <jesse_> yes
19:57:11 <jesse_> and it would need someone to either to get approval on it or just do it
19:57:28 <bahamat> Sounds pretty simple, then, why not volunteer for it?
19:57:28 <jesse_> but for to that happen, someone has to give the idea of 'this would be really good'
19:58:14 <jesse_> I'd love to, but my first priority would be to get openjdk to run again
19:58:47 <bahamat> ptribble has taken care of that. We've got working openjdk17 builds.
19:58:50 <jesse_> and the easiest way is to just ditch smartos and use the time to make podman's network stack work even slightly
19:59:05 <jesse_> bahamat, does it have ZGC?
19:59:20 <jesse_> if it doesn't, it's pretty much useless for production use
19:59:38 <jesse_> because a bhyve with linux openjdk will dance around it
19:59:57 <jesse_> (no, it's not easy, did dig into it)
20:00:21 <bahamat> If it's a native part of openjdk, then I think it probably works, but I wasn't involved with that work so I can't say for certain.
20:00:35 <jesse_> it's native part
20:00:46 <jesse_> but there is only win and linux implementations of it
20:01:03 <jesse_> and the whole build system will fight you to do #ifdef implementation
20:01:43 <jesse_> if you copy it, you'll on the hook to manually do every single small commit yourself
20:02:20 <jesse_> so, I know what I'm talking about
20:03:53 <jesse_> podman is just some node(? possibly go?) interfaces implemented
20:04:25 <jesse_> not €"#%€&%//%&€%# memory mappings in-a-hurry magicks
20:08:31 <bahamat> It's go
20:09:46 <jesse_> (and the platform-specific parts of ZGC are not in-a-hurry afaik)
20:10:01 <jesse_> but it was more dramatic to claim that=)
20:11:15 <jesse_> (and most of the openjdk problems are because of how they use c++ and their build system, but there's not much one can do about that)
20:14:32 <jesse_> bahamat, ah, if you have podman-angst, try adding buildah support=)
20:14:41 <jesse_> (it's the build part podman uses)
20:16:42 <jesse_> bahamat, and only now I realize what I should have been using all this time... Obviously I use buildah commands for everything, but I just keep copy-pasting the prefix of the shell lines)
20:17:16 <jesse_> (but podman uses internally buildah to run dockerfiles etc.)
20:17:52 <jesse_> to add to the trinity, adding imgadm support to skopeo...
20:18:40 <jesse_> (podman/buildah/skopeo is the redhat response to docker going pay-to-run-production, afaik)
20:20:57 <jesse_> obviously the lines above were triggered of me copy-pasting lines from existing buildah scripts and realizing the prefix is buildah, not podman...
20:26:41 <neuroserve> https://lists.freebsd.org/archives/freebsd-jail/2022-May/000129.html <- there seems to be an effort to port podman and buildah to freebsd...
20:27:39 <jesse_> it'll still probably need smartos-specific massaging
20:28:20 <blackwood821> In the vmadm man page for "cpu_cap" it says "percentage of a single CPU that can be used by the VM". If a CN has simultaneous multi-threading enabled, does "CPU" refer to a CPU core or a thread on the core?
20:28:23 <jesse_> not sure if the zone model can handle 'run command in zone context without really starting up the zone'
20:28:51 <jesse_> blackwood821, afaik, thread
20:30:02 <blackwood821> jesse_: That's what I was assuming, hoping someone can confirm it
20:30:32 <jesse_> I _think_ I've seen that with zones and bhyves with high load
20:30:55 <jesse_> (monitoring from gz)
20:36:07 <blackwood821> Is there anything in the global I can run to confirm that for a particular zones?
20:36:12 <blackwood821> zone*
20:37:05 <jesse_> prstat -Z?
20:37:20 <jesse_> (and see how much a much-loaded zone gets)
20:37:45 <jesse_> on an idle host... I don't know
20:47:56 <blackwood821> jesse_: `prstat -Z -z <zone_uuid>` gives me one entry for the zone so would the percentage in the "CPU" column be the percentage of CPU of all the CPUs on the system?
20:50:56 <jesse_> just "prstat -Z" will give you all load on the system
20:51:03 <jesse_> may help or not help
20:51:46 <jesse_> but what I remember looking at the numbers is 100% per thread
21:02:54 <jesse_> bahamat, to get back to podman, eventhough that's not what i'm looking for, there are runc and crun implementations of the interface to actually run the container; implement either or see how to add your own=))
21:03:37 <jesse_> (vmadm will do for my needs, most likely, eventhough it sucks like docker in setting bootup-sequence)
21:16:47 <blackwood821> jesse_: Ok thanks. https://docs.tritondatacenter.com/private-cloud/troubleshooting/cpu-usage seems to agree: "The percentage is the total across all CPUs (psrinfo). So, a value of 200 is equivalent to 2 virtual CPUs (a virtual CPU is either a core or a hyper-thread)."
21:17:25 <jesse_> blackwood821, good that my memory agrees =)
21:18:46 <blackwood821> Your memory serves you well
21:30:12 <bahamat> runc is just a very thin wrapper around making a bunch of system calls.
21:30:28 <bahamat> What you're actually proposing is adding linux namespaces to illumos.
21:36:43 <jesse_> no, what I'm proposing is lying about them in relative terms like with lx
21:37:05 <jesse_> and adding support in relation too that
21:37:15 <jesse_> s/too/to/