Switch to DuckDuckGo Search
   January 2, 2019
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31

Toggle Join/Part | bottom
[00:03:57] *** jcea <jcea!~Thunderbi@2001:41d0:1:8a82:7670:6e00:7670:6e00> has quit IRC (Remote host closed the connection)
[00:06:37] *** jcea <jcea!~Thunderbi@2001:41d0:1:8a82:7670:6e00:7670:6e00> has joined #smartos
[00:06:51] <Smithx10> Yea, I have seen zones get into that state once in awhile on my deployment
[00:07:48] <Smithx10> I never had it happen to me before until I think the vminfod stuff was added
[00:07:56] <Smithx10> but that is totally a guess / from my memory
[00:12:27] <danderson> I'm still very new to the vm* codebase, but it feels like there's a missing step of running `zonecfg verify`, and unwinding if that verify fails
[00:13:13] <danderson> I suspect triton does an explicit `vmadm validate ...` before doing the create, maybe?
[00:13:39] <danderson> need to dig into that, there's at least one condition I've found that leaves OS zones in a borked half-state that requires care to clean up (trying to lofs-mount a path that doesn't exist)
[00:51:35] <taylorjonl> I can reproduce this pretty easily, I must not be understanding the syntax and validate doesn't warn me
[00:51:37] <taylorjonl> https://pastebin.com/BLXAtnt4
[00:51:51] <taylorjonl> Trying to attach a second data set to a zone at creation
[00:54:08] <taylorjonl> It went back to that bad state, so I tried marking the zone as complete so I could delete it and got this:
[00:54:09] <taylorjonl> https://pastebin.com/B7Bnv7K4
[01:05:15] *** andy_js <andy_js!~andy@94.3.60.133> has quit IRC (Quit: andy_js)
[01:12:54] <rsully> worth a bug report then?
[01:13:55] <m1cr0man> taylorjonl, I've definitely done that successfully, try adding a leading / to your source and set the type to lofs
[01:14:22] <rsully> it should still error out instead of going into a weird state
[01:14:42] <taylorjonl> m1cr0man: I am trying to delegate the dataset
[01:15:00] <m1cr0man> Idk I've had it behave weirdly around storage things similarly rsully
[01:16:29] <rsully> taylorjonl what's your pool layout, do you have 2 pools?
[01:16:44] <m1cr0man> taylorjonl, Do you mean you are trying to delegate the storage/media dataset? Hm. I think you would still want delegate_dataset turned off as it will create a /zones/$uuid/data dataset for that zone
[01:16:46] <rsully> m1cr0man yes I'm just saying it shouldn't be weird :) - a validation issue of sorts
[01:16:47] <taylorjonl> rsully: I have three, zones, storage and backcup
[01:17:41] <m1cr0man> wait..my ansible playbook does this one sec
[01:18:07] <taylorjonl> m1cr0man: I can manually add the second dataset later by doing this https://www.cyber-tec.org/2016/12/21/smartos-add-delegate-dataset-later-to-zone/
[01:18:29] <taylorjonl> Then I can see the data set when I do a vmadm get
[01:18:54] <taylorjonl> I just don't want to have to do the extra step, would like to do it at creation time
[01:19:00] <m1cr0man> yeah...that's actually what I'm doing haha. I'm not sure how to mimic that in the vmadm json file. Would like to know honestly. You definitely don't need delegate_dataset: true though
[01:19:26] <taylorjonl> I want that data set also, I want both
[01:19:53] <m1cr0man> ah ok
[01:20:08] <taylorjonl> It is my plex server where the /data directory will be where incoming media goes and then I will manually move it to the correct location in the storage/media dataset
[01:20:23] <m1cr0man> Yeah that makes sense
[01:20:49] <taylorjonl> I did this at one point of time but I lost all my .json files years ago and switched to freenas for a while
[01:21:11] <taylorjonl> switching back, I don't like how inflexible freenas is with its networking in its jails
[01:21:37] <danderson> taylorjonl: so, I just filed https://github.com/joyent/smartos-live/issues/818
[01:21:51] <danderson> which I think is exactly what you're trying to do - delegate existing datasets to a VM in vmadm
[01:22:42] <danderson> so, assuming I manage to implement it, you might have that capability in vmadm soonish
[01:23:54] <taylorjonl> danderson: I have a message on the console(not in my SSH session) talking about this zone and a log file being missing
[01:24:11] <taylorjonl> that may be why it left it in a 'configured' state
[01:24:23] <taylorjonl> I will post more data when I get back from the pub
[01:30:27] <m1cr0man> I get that message when I delete a zone without stopping it
[01:55:53] *** axonpoet <axonpoet!~axonpoet@fsf/member/axonpoet> has joined #smartos
[02:27:24] *** jellydonut <jellydonut!~jelly@148.122.187.2> has quit IRC (Read error: Connection reset by peer)
[02:37:14] *** v_a_b <v_a_b!~volker@p57A27CBA.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 246 seconds)
[02:39:56] *** axonpoet <axonpoet!~axonpoet@fsf/member/axonpoet> has quit IRC (Ping timeout: 250 seconds)
[03:04:11] <rsully> danderson thanks for that github link, I too would love this :) - but would this be limited to datasets in the zones pool or any pool?
[03:05:42] <rsully> I'd be curious, how the zone stuff handles it if the other pool isn't imported (on say, boot)
[03:08:13] <danderson> rsully: any pool
[03:08:24] <danderson> in my case I only care about zones, because I use a single pool for everything
[03:08:35] <danderson> but the feature is really just "take this string and give it to zonecfg"
[03:08:47] <danderson> so any dataset that the GZ can see, is fine
[03:12:51] <rsully> gotcha, I was just curious if additional validation is needed or if vmadm will just spit out an error from zonecfg (or whatever the command is) when a zone is started and the dataset isn't imported or doesn't exist
[03:13:48] <Smithx10> danderson: Whoa man, keep it up!!! :P
[03:15:39] <danderson> rsully: good questions, I haven't figured that out yet. In general, we have to handle the case where zonecfg doesn't like our config, so I'm hoping I can just hook into that
[03:15:52] <danderson> and also include some pre-validation steps in vmadm (although that's racy code)
[03:16:56] <rsully> yep! definitely going to follow this, as I am in the exact same boat. current I went with your first option of "Create a "zones/tank" dataset in the GZ and lofs-mount it into VMs that provide NAS services like SMB" but definitely not ideal
[03:17:24] <danderson> cool, glad to hear it might be useful :)
[03:17:37] <danderson> my use case is really that I don't want to handle snapshots and backups in the GZ
[03:17:54] <danderson> because I want to someday play with stuff like bacula and tape drives... and I *really* don't want to figure out installing that in the GZ
[03:18:02] <danderson> ... but if it's not in the GZ, I can't manage snapshots, so...
[03:18:21] <rsully> yep, same boat here. currently not doing any backups or snapshots
[03:21:01] <Smithx10> danderson: that is the exact reason we I am trying to get Triton at work
[03:21:18] <Smithx10> giving Snapshots / ZFS send in an the container is priceless
[03:21:56] <Smithx10> currently all of that orchestration has to be done in the orchestrator / gz ....which means errrrrrr
[03:24:09] <danderson> Yup. I only have 1 machine so triton is pointless
[03:24:35] <rsully> danderson just to clarify, your plan here is to use samba inside the zone? or are you interested in using zfs sharesmb or similar?
[03:25:38] <danderson> I'm not sure yet. Originally I wanted this zone delegation thing so I could use kernel SMB in a zone
[03:26:06] <danderson> but now I'm not actually sure if I want to use Samba or kernel SMB. It depends on what SMB features are in kernel SMB, I haven't investigated yet
[03:26:38] <danderson> but either way I definitely want a zone where I can do stuff like periodic snapshots, zfs send, deleting old snapshots, ...
[03:27:05] <danderson> basically do kinda what `zrepl` does, but also have a place where I can play with tape drives and stuff
[03:27:07] <rsully> yeah I would love to experiment with that too (with lofs I am limited to running samba, which works, but I am not seeing the speed I would like). however maybe you could explain to me, since sharesmb is a zfs property, how does zfs react when the zone being delegated to is removed? would the GZ begin to share it, or is there a reason that it doesn't?
[03:27:14] <danderson> (tape drives are ridiculous and impractical, I just like them :D)
[03:27:33] <danderson> so, I'm not 100% sure, but...
[03:27:59] <danderson> when you delegate a dataset to a zone, the dataset gets the zones=true property set on it
[03:28:08] <danderson> which disables a bunch of "automagic" ZFS stuff in the GZ
[03:28:25] <danderson> e.g. the GZ won't automount the dataset, even if the dataset has the `mountpoint` property
[03:28:26] <rsully> is that a smartos-only magic property?
[03:28:58] <danderson> I think that's generic illumos/ZFS
[03:29:26] <rsully> ok that makes sense too I suppose
[03:29:28] <danderson> this behavior is implemented in the lower level zone management tools (zonecfg/zoneadm), and I think that's all shared in upstream illumos?
[03:29:40] <rsully> no clue but I buy it :)
[03:29:50] <danderson> oops, it's zoned=true, not zones=true
[03:30:08] <danderson> but anyway, afaict it's a 1-way thing: when you delegate to a zone, the OS sets zoned=true on the dataset
[03:30:17] <danderson> but it doesn't unset it when you un-delegate
[03:30:43] <rsully> ok so that works perfectly then, I don't think anyone would want the GZ to start touching these datasets just because you want to redo your NAS zone
[03:30:47] <danderson> so if you want to reenable GZ features, you have to manually `zfs set zoned=false my/dataset` (or `zfs inherit`)
[03:30:55] <rsully> yeah that's totally reasonable
[03:31:46] <danderson> yeah, it's consistent: by definition zones are not trusted by the GZ, so you need to manually check what the zone changed on the dataset before you use it again
[03:41:01] *** jcea <jcea!~Thunderbi@2001:41d0:1:8a82:7670:6e00:7670:6e00> has quit IRC (Quit: jcea)
[04:35:38] <taylorjonl> danderson: Are you aware you can do what you want to do(not in vmadm) but with the command line?
[04:48:20] <taylorjonl> danderson: I just commented on your proposal, I think the simplest solution is to add setters for the 'datasets' data instead of a new syntax or node
[05:12:54] *** rsully <rsully!~rsully@unaffiliated/rsully> has quit IRC (Quit: rsully)
[05:20:30] <danderson> yes, I'm aware that I can work around vmadm. I don't have any faith that this won't break in the future though. I want vmadm to know precisely how the VMs its built are configured
[05:22:18] <danderson> as for adding setters - that strongly ties vmadm to today's implementation of zones, which doesn't feel right. Translations from one data format to another are cheap, so my preference would be to construct objects that make sense on their own, without knowledge of the implementation
[05:22:43] <danderson> but, that's just me. We'll see what folks think on the bug :)
[05:28:56] *** barfield <barfield!~barfDaddy@135.84.96.249> has quit IRC (Ping timeout: 250 seconds)
[05:31:44] *** ingenthr <ingenthr!~ingenthr@47.150.213.46> has joined #smartos
[05:35:47] *** ingenthr <ingenthr!~ingenthr@47.150.213.46> has quit IRC (Ping timeout: 240 seconds)
[05:41:28] <taylorjonl> danderson: Not sure how setters tie vmadm to a specific implementation, it ties it to the concept, but that concept is core to ZFS today because I can define for a dataset what its mount point should be. Translations are cheap, but there is something to be said about consistency and simplicity.
[05:57:54] *** Kurlon <Kurlon!~Kurlon@98.13.72.207> has quit IRC (Remote host closed the connection)
[06:09:05] *** ingenthr <ingenthr!~ingenthr@47.150.213.46> has joined #smartos
[06:09:24] *** ingenthr <ingenthr!~ingenthr@47.150.213.46> has quit IRC (Client Quit)
[06:46:01] *** rennj <rennj!~rennj@host-69-146-167-42.static.bresnan.net> has quit IRC (Ping timeout: 244 seconds)
[06:57:10] *** ingenthr <ingenthr!~ingenthr@47.150.213.46> has joined #smartos
[06:59:42] *** ingenthr <ingenthr!~ingenthr@47.150.213.46> has quit IRC (Client Quit)
[08:52:58] *** v_a_b <v_a_b!~volker@p57A27D1D.dip0.t-ipconnect.de> has joined #smartos
[09:06:04] *** mno-hime <mno-hime!~mno-hime@94.142.238.232> has quit IRC (Quit: Leaving)
[09:21:29] *** bens1 <bens1!~bens1@161.122.2.81.in-addr.arpa> has joined #smartos
[09:29:29] *** ingenthr <ingenthr!~ingenthr@47.150.213.46> has joined #smartos
[09:29:42] *** ingenthr <ingenthr!~ingenthr@47.150.213.46> has quit IRC (Client Quit)
[10:26:23] *** mnowak_ <mnowak_!mnowak_@nat/suse/x-fbsdjglelevjhyns> has joined #smartos
[10:32:07] *** andy_js <andy_js!~andy@94.3.60.133> has joined #smartos
[10:51:55] *** man_u <man_u!~manu@manu2.gandi.net> has joined #smartos
[11:07:00] *** rennj <rennj!~rennj@host-69-146-167-42.static.bresnan.net> has joined #smartos
[11:19:22] *** ingenthr <ingenthr!~ingenthr@47.150.213.46> has joined #smartos
[11:19:40] *** ingenthr <ingenthr!~ingenthr@47.150.213.46> has quit IRC (Client Quit)
[12:04:25] *** ingenthr <ingenthr!~ingenthr@47.150.213.46> has joined #smartos
[12:08:34] *** ingenthr <ingenthr!~ingenthr@47.150.213.46> has quit IRC (Ping timeout: 246 seconds)
[12:09:47] *** jellydonut <jellydonut!~jelly@148.122.187.2> has joined #smartos
[12:40:21] *** theandromedan <theandromedan!~pfranz@c-174-59-156-209.hsd1.pa.comcast.net> has quit IRC (Read error: Connection reset by peer)
[12:42:32] *** theandromedan <theandromedan!~pfranz@c-174-59-156-209.hsd1.pa.comcast.net> has joined #smartos
[13:28:51] *** Kurlon <Kurlon!~Kurlon@98.13.72.207> has joined #smartos
[13:33:24] *** Kurlon <Kurlon!~Kurlon@98.13.72.207> has quit IRC (Ping timeout: 250 seconds)
[13:52:03] *** ingenthr <ingenthr!~ingenthr@47.150.213.46> has joined #smartos
[13:53:01] *** ingenthr <ingenthr!~ingenthr@47.150.213.46> has quit IRC (Client Quit)
[14:34:09] *** jellydonut <jellydonut!~jelly@148.122.187.2> has quit IRC (Read error: Connection reset by peer)
[14:46:21] *** Kurlon <Kurlon!~Kurlon@98.13.72.207> has joined #smartos
[14:56:02] *** JeanParpaillon <JeanParpaillon!~jean@176.164.74.121> has joined #smartos
[15:00:45] *** ingenthr <ingenthr!~ingenthr@47.150.213.46> has joined #smartos
[15:06:54] *** gh34 <gh34!~textual@rrcs-162-155-144-114.central.biz.rr.com> has joined #smartos
[15:07:56] *** Kurlon <Kurlon!~Kurlon@98.13.72.207> has quit IRC (Read error: Connection reset by peer)
[15:08:02] *** Kurlon_ <Kurlon_!~Kurlon@98.13.72.207> has joined #smartos
[15:10:28] *** ingenthr <ingenthr!~ingenthr@47.150.213.46> has quit IRC (Ping timeout: 245 seconds)
[15:12:12] *** Kurlon_ <Kurlon_!~Kurlon@98.13.72.207> has quit IRC (Ping timeout: 250 seconds)
[15:40:43] *** ingenthr <ingenthr!~ingenthr@47.150.213.46> has joined #smartos
[15:41:21] *** ingenthr <ingenthr!~ingenthr@47.150.213.46> has quit IRC (Client Quit)
[15:42:44] *** polishdub <polishdub!~polishdub@207.86.38.254> has joined #smartos
[15:54:13] *** Kurlon <Kurlon!~Kurlon@bidd-pub-03.gwi.net> has joined #smartos
[16:12:30] *** JeanParpaillon <JeanParpaillon!~jean@176.164.74.121> has quit IRC (Ping timeout: 268 seconds)
[16:14:05] <nahamu> OS-7392 ... I wonder if that will help me...
[16:14:07] <jinni> https://smartos.org/bugview/OS-7392
[16:19:47] *** ingenthr <ingenthr!~ingenthr@47.150.213.46> has joined #smartos
[16:22:22] *** ingenthr <ingenthr!~ingenthr@47.150.213.46> has quit IRC (Client Quit)
[16:36:13] *** ingenthr <ingenthr!~ingenthr@47.150.213.46> has joined #smartos
[17:16:53] *** jellydonut <jellydonut!~jelly@148.122.187.2> has joined #smartos
[17:17:47] *** richlowe <richlowe!~richlowe@2605:a000:160c:8b5b::bb7> has quit IRC (Ping timeout: 268 seconds)
[17:38:37] *** ahmed89 <ahmed89!~ahmed89@5.36.35.68.dynamic-dsl-ip.omantel.net.om> has joined #smartos
[18:07:39] *** mno-hime <mno-hime!~mno-hime@94.142.238.232> has joined #smartos
[18:14:44] *** Kurlon <Kurlon!~Kurlon@bidd-pub-03.gwi.net> has quit IRC (Ping timeout: 244 seconds)
[18:19:53] *** Teknix <Teknix!~pds@2601:801:101:f429:d8c1:41b5:14bd:2dcc> has quit IRC (Ping timeout: 250 seconds)
[18:21:21] *** Teknix <Teknix!~pds@2601:801:101:f429:ddc1:b595:1e9:6f8> has joined #smartos
[18:31:28] *** rsully <rsully!~rsully@unaffiliated/rsully> has joined #smartos
[18:36:37] *** bens1 <bens1!~bens1@161.122.2.81.in-addr.arpa> has quit IRC (Quit: bens1)
[18:39:51] *** axonpoet <axonpoet!~axonpoet@fsf/member/axonpoet> has joined #smartos
[18:42:15] *** jellydonut <jellydonut!~jelly@148.122.187.2> has quit IRC (Read error: Connection reset by peer)
[18:44:09] *** jellydonut <jellydonut!~jelly@148.122.187.2> has joined #smartos
[18:50:10] *** axonpoet <axonpoet!~axonpoet@fsf/member/axonpoet> has quit IRC (Ping timeout: 250 seconds)
[19:01:52] <Smithx10> mgerdts: with kata containers the containers will be running the docker daemon / some container runtime correct?
[19:02:25] <Smithx10> I was reading through this https://github.com/kata-containers/documentation/blob/master/architecture.md and seeing if I'd hit some of the same pain points as running Mesosphere / K8S
[19:07:35] <mgerdts> kata containers provide kata-runtime that provides the OCI interfaces. It is responsible for creating the VM and making the necessary storage, network, etc. available. It uses a proxy (across a serial port or vsock) to get the agent to create container(s) inside the VM, get logs out, proxy stdio, etc.
[19:09:53] <mgerdts> My initial guess is that Triton would replace the outward facing parts of kata-runtime with things that are more native to SmartOS/Triton. It would interact with guests that use standard kata images and run the native kata agent.
[19:10:32] *** man_u <man_u!~manu@manu2.gandi.net> has quit IRC (Ping timeout: 246 seconds)
[19:12:08] <mgerdts> This is all pie in the sky right now. We have no specific plans to work on it - I'm just looking at it because it seems to have some of the same design as I had rattling around in my head before looking at it.
[19:12:57] <mgerdts> Back when clear containers first came out, it looked quite interesting. This work builds on clear containers.
[19:13:21] *** Kurlon <Kurlon!~Kurlon@bidd-pub-03.gwi.net> has joined #smartos
[19:18:05] <Smithx10> yea, I followed that intel stuff in the beginning too but never understood why I wouldn't just schedule processes :P
[19:18:16] <Smithx10> I guess the use case is the entire "docker" image
[19:18:24] <Smithx10> Portability aspect of the system.
[19:18:47] <Smithx10> THanks for the info :)
[19:42:32] *** ahmed89 <ahmed89!~ahmed89@5.36.35.68.dynamic-dsl-ip.omantel.net.om> has quit IRC (Quit: ahmed89)
[20:06:19] *** ahmed89 <ahmed89!~ahmed89@5.36.35.68.dynamic-dsl-ip.omantel.net.om> has joined #smartos
[20:07:10] *** axonpoet <axonpoet!~axonpoet@fsf/member/axonpoet> has joined #smartos
[20:13:32] *** jessfraz_ <jessfraz_!~jessfraz@unaffiliated/jessfraz> has quit IRC (Remote host closed the connection)
[20:15:21] *** axonpoet <axonpoet!~axonpoet@fsf/member/axonpoet> has quit IRC (Read error: Connection reset by peer)
[20:15:31] *** jessfraz_ <jessfraz_!~jessfraz@unaffiliated/jessfraz> has joined #smartos
[20:18:09] *** gh34 <gh34!~textual@rrcs-162-155-144-114.central.biz.rr.com> has quit IRC (Quit: Textual IRC Client: www.textualapp.com)
[20:31:29] *** gh34 <gh34!~textual@rrcs-162-155-144-114.central.biz.rr.com> has joined #smartos
[20:42:27] *** ahmed89 <ahmed89!~ahmed89@5.36.35.68.dynamic-dsl-ip.omantel.net.om> has quit IRC (Quit: ahmed89)
[21:11:29] *** colstrom <colstrom!sid12858@gateway/web/irccloud.com/x-uvwfroxdvhsejxhk> has joined #smartos
[21:14:12] *** fxhp <fxhp!~fox@138.207.192.33> has joined #smartos
[21:19:10] *** ingenthr <ingenthr!~ingenthr@47.150.213.46> has quit IRC (Quit: Leaving.)
[21:21:37] *** ingenthr <ingenthr!~ingenthr@47.150.213.46> has joined #smartos
[21:22:45] *** axonpoet <axonpoet!~axonpoet@fsf/member/axonpoet> has joined #smartos
[21:34:52] *** ingenthr <ingenthr!~ingenthr@47.150.213.46> has quit IRC (Quit: Leaving.)
[21:36:08] *** ingenthr <ingenthr!~ingenthr@47.150.213.46> has joined #smartos
[21:37:25] *** ingenthr <ingenthr!~ingenthr@47.150.213.46> has quit IRC (Client Quit)
[21:38:48] *** ingenthr <ingenthr!~ingenthr@47.150.213.46> has joined #smartos
[21:41:23] *** ingenthr <ingenthr!~ingenthr@47.150.213.46> has quit IRC (Client Quit)
[21:42:37] *** ingenthr <ingenthr!~ingenthr@47.150.213.46> has joined #smartos
[21:43:38] *** ingenthr <ingenthr!~ingenthr@47.150.213.46> has quit IRC (Client Quit)
[21:45:07] *** ingenthr <ingenthr!~ingenthr@47.150.213.46> has joined #smartos
[21:46:08] *** ingenthr <ingenthr!~ingenthr@47.150.213.46> has quit IRC (Client Quit)
[21:47:37] *** ingenthr <ingenthr!~ingenthr@47.150.213.46> has joined #smartos
[21:49:04] *** ingenthr <ingenthr!~ingenthr@47.150.213.46> has quit IRC (Client Quit)
[21:50:25] *** ingenthr <ingenthr!~ingenthr@47.150.213.46> has joined #smartos
[21:52:00] *** ingenthr <ingenthr!~ingenthr@47.150.213.46> has quit IRC (Client Quit)
[21:53:32] *** ingenthr <ingenthr!~ingenthr@47.150.213.46> has joined #smartos
[22:04:39] *** ingenthr <ingenthr!~ingenthr@47.150.213.46> has quit IRC (Ping timeout: 244 seconds)
[22:28:45] *** ingenthr <ingenthr!~ingenthr@47.150.213.46> has joined #smartos
[23:05:57] *** gh34 <gh34!~textual@rrcs-162-155-144-114.central.biz.rr.com> has quit IRC (Quit: Textual IRC Client: www.textualapp.com)
[23:16:56] *** mmlb <mmlb!~mmlb@76-248-148-178.lightspeed.miamfl.sbcglobal.net> has quit IRC (Ping timeout: 246 seconds)
[23:18:26] *** rsully <rsully!~rsully@unaffiliated/rsully> has quit IRC (Quit: rsully)
[23:25:57] *** Gathis <Gathis!~TheBlack@unaffiliated/gathis> has joined #smartos
[23:26:38] *** Kurlon <Kurlon!~Kurlon@bidd-pub-03.gwi.net> has quit IRC (Ping timeout: 250 seconds)
[23:51:46] *** polishdub <polishdub!~polishdub@207.86.38.254> has quit IRC (Quit: leaving)
[23:59:21] *** taylorjonl_ <taylorjonl_!d871a044@gateway/web/freenode/ip.216.113.160.68> has joined #smartos
top

   January 2, 2019
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31