| 00:25.33 | spangborn | I applied there once |
| 00:25.46 | spangborn | they apparently had troubles and closed the position I applied for, lol |
| 00:50.10 | shalkie | Ah, well they seem to be hiring again. |
| 00:56.47 | spangborn | I'm honestly surprised they're still around |
| 01:36.29 | *** join/#utah tristanbob_home (~Tristan@2602:41:82aa:ff00:359c:55d5:ee1c:23eb) |
| 01:39.35 | beelzebob | jlp_znc: yeah, actually I rebooted the router and killed the internet connection :) so now I have bigger fish to fry than dhcp |
| 01:39.42 | jlp_znc | heh |
| 01:39.46 | jlp_znc | well, good luck |
| 01:40.42 | beelzebob | oddly enough, I pinned that down to the port/network configuration having Masquerade / NAT enabled |
| 01:41.14 | beelzebob | it can be set and applied without issue, but if it is set when the router reboots, packets can't get out |
| 01:41.36 | beelzebob | which feels like an ordering issue as well |
| 01:42.22 | jlp_znc | yeah, that doesn't sound right. are you working on this remotely? |
| 01:44.13 | beelzebob | not any more |
| 01:44.21 | jlp_znc | heh |
| 01:44.29 | jlp_znc | I hate it when that happens |
| 03:04.04 | *** join/#utah tristanbob_home (~Tristan@2602:41:82aa:ff00:2027:189:34f9:22c9) |
| 03:26.20 | TodPunk | I see sysadmin style jobs becoming less and less important, and niche specialties like networking specifically becoming more important. |
| 03:27.19 | TodPunk | You'll never get rid of sysadmins altogether, but it's not going to be as valuable for sure, and tooling is getting to the point that you will see it become another layer above where it's at now, just like it has every 20 years or so. Have to learn whatever standards come out of the container orchestration bits |
| 03:28.06 | TodPunk | Stuff like that, anyway |
| 03:31.04 | TodPunk | See also: Systems DBAs |
| 03:32.52 | TodPunk | There's some niches for the level of "I can configure users and config files for an MSSQL database, and I know how to use some tools that integrate with said database" but those niches are something I see as the equivalent as a COBOL programmer |
| 04:14.15 | *** join/#utah tiwula (~lane@174-23-2-196.slkc.qwest.net) |
| 05:30.21 | klys | ~slashdot |
| 07:45.33 | *** join/#utah Jantz (~IceChat9@2407:7000:8d04:100:9c28:371f:3dde:ec98) |
| 10:35.51 | *** join/#utah tristanbob_h (~Tristan@2602:41:82aa:ff00:2027:189:34f9:22c9) |
| 12:36.48 | *** join/#utah nagefire (~nagefire@66-219-236-168.dynamic.ip.veracitynetworks.com) |
| 14:51.51 | *** join/#utah emcnabb (emcnabb@nat/redhat/x-zgcgvqeeumngsdww) |
| 15:30.48 | *** join/#utah josephscott (~josephsco@74.114.153.251) |
| 16:05.12 | *** join/#utah braxtron (~braxtron@216.160.248.178) |
| 16:17.50 | JPaul | TodPunk, sure, I totally get that is the direction things are heading, whether we like it or not. Right now my DC is still setup pretty old school, but we're also a really small company (<20 employees). |
| 16:18.30 | JPaul | i am hoping to bring us more current and flexible though, I've been trying to get Openstack going here for the last 3 years, but time and resources have kept that at the bottom of the pile. |
| 16:20.11 | JPaul | Our setup is also not very conducive to using containers, so even if I wanted to use them (which I'm not convinced they are really a good idea yet) it would be a PITA to implement. |
| 16:21.00 | JPaul | We have probably 30 some odd various clients, each with their own unique needs and length of time being with us (some are twenty years) |
| 16:21.03 | *** join/#utah aeryndunham (~aeryndunh@96.71.45.252) |
| 16:21.42 | JPaul | so that really makes it challenging. I implemented saltstack here shortly after I started, and I'm still trying to figure out how to make it really work in our environment. |
| 16:27.46 | *** join/#utah moccos (~moccos@104.243.62.132) |
| 17:03.30 | *** join/#utah tiwula (~lane@70.89.246.241-Busname-UT.hfc.comcastbusiness.net) |
| 17:28.45 | *** join/#utah aeryndunham (~aeryndunh@96.71.45.252) |
| 17:31.10 | *** join/#utah tiwula (~lane@70.89.246.241-Busname-UT.hfc.comcastbusiness.net) |
| 17:34.18 | youtah | <3's nachos |
| 17:38.57 | jsmith | youtah: But it's Wendysday... you should be eating a burger today... |
| 17:44.27 | *** join/#utah legreathambino (~braxtron@216.160.248.178) |
| 18:22.37 | *** join/#utah keldwud (~keldwud@199.192.164.75) |
| 18:22.37 | *** join/#utah keldwud (~keldwud@unaffiliated/keldwud) |
| 18:33.04 | *** join/#utah SunSparc (~jonathan@45.56.57.85) |
| 18:33.29 | *** join/#utah Jantz (~IceChat9@2407:7000:8d04:100:9c28:371f:3dde:ec98) |
| 18:46.25 | jfindlay | TodPunk: yeah, I keep getting frustrated and think I'll just use paramiko, but then realize that's too low-level |
| 18:47.45 | jfindlay | mainly what I need right now is a low-level remote execution, which fabric gives me, but I couldn't figure out an easy way to get it to install the public key |
| 18:48.04 | jfindlay | I guess I could write that myself actually |
| 18:49.16 | jfindlay | JPaul: have you looked at opennebula or ovirt? |
| 18:50.33 | jfindlay | ~napoleon |
| 18:50.33 | infobot | It's a liger, bred for its skills in magic. |
| 18:52.41 | jfindlay | ~nacho |
| 18:52.41 | infobot | Tonight I wrestle the seven strongest men in town, maybe the world. |
| 18:52.46 | jfindlay | ~nacho youtah |
| 18:52.46 | infobot | ACTION sprays scalding hot nacho cheese sauce all over youtah |
| 18:52.53 | jfindlay | ~youtah nacho |
| 18:52.53 | infobot | ACTION eats nachos with nacho |
| 18:53.04 | jfindlay | ~horse nacho |
| 18:53.04 | infobot | http://nacho.horse/ |
| 18:57.51 | *** join/#utah emcnabb (~emcnabb@hs-nc-1fff767f54-29977-1.tingfiber.com) |
| 19:14.45 | JPaul | jfindlay, I have not seen those. Not thrilled that oVirt uses Gluster, but I guess since it's probably used for the disk images it would be OK |
| 19:18.10 | jfindlay | I tried to use OpenNebula once. It looks impressive and I'm sure many people use it to roll their own cloud or even sell cloud, but I still haven't figured out how to get a windows VM running |
| 19:18.57 | jfindlay | mainly my need for it waned, but I would still probably try to use it over OpenStack without further knowledge |
| 19:45.45 | *** join/#utah keldwud_ (~keldwud@199.192.164.75) |
| 19:49.31 | *** part/#utah keldwud_ (~keldwud@199.192.164.75) |
| 19:50.07 | *** join/#utah keldwud (~keldwud@unaffiliated/keldwud) |
| 22:34.19 | SunSparc | jfindlay: Remote execution: ssh user@host "command" |
| 22:36.59 | jfindlay | SunSparc: try doing that for hundreds of hosts at the same time |
| 22:37.32 | joshh | fabric is fine honestly |
| 22:37.35 | jfindlay | also, ssh key management |
| 22:37.37 | joshh | i assume saltstack is too much? |
| 22:38.00 | SunSparc | jfindlay: I do all the time. Just in a bash script. |
| 22:38.00 | jfindlay | I would use salt if I could. I'm trying to fly under corporate radar for now to get things done |
| 22:38.26 | jfindlay | I try not to program in shell if I can avoid it :-) |
| 22:38.33 | SunSparc | lol |
| 22:38.35 | SunSparc | ok |
| 22:38.40 | SunSparc | fabric is nice |
| 22:38.46 | joshh | can't spin saltstack into a win for corporate recognition and raise/promo? |
| 22:38.51 | SunSparc | I played with salt, works. |
| 22:38.58 | jfindlay | joshh: that's the long game |
| 22:39.14 | SunSparc | Have you played with Consul? |
| 22:40.12 | jfindlay | <PROTECTED> |
| 22:40.23 | jfindlay | I have not yet |
| 22:40.24 | SunSparc | We looked at salt and others several years ago, ended up going with Consul, now moving onto kubernetes. |
| 22:40.53 | joshh | how did you use consul? |
| 22:41.16 | joshh | not for "execution" i assume/ |
| 22:42.26 | SunSparc | joshh: It has execution capabilities, but we mostly used it for cluster management, when new nodes would spin up they would report to consul who would get them into rotation automatially. |
| 22:42.44 | joshh | ok, that makes sense |
| 22:43.48 | jfindlay | we use puppet right now and are trying to move in a kubernetes direction |
| 22:44.23 | SunSparc | I looked into using the consul exec, but boss was not interested in that aspect, so we moved on. https://www.consul.io/docs/commands/exec.html |
| 22:44.32 | joshh | puppet for app deployments or just host level config? |
| 22:44.56 | jfindlay | for config management |
| 22:45.31 | joshh | are you configuring your own kubernetes nodes or something like eks? |
| 22:47.14 | joshh | or like coreos or another way to not care about the hosts |
| 22:47.14 | *** join/#utah Jantz (~IceChat9@2407:7000:8d04:100:9c28:371f:3dde:ec98) |
| 22:50.59 | jfindlay | I don't know what they're doing. I suspect much of the development is merely buzzword-driven |
| 22:51.34 | jfindlay | I work for another team that is mostly isolated from the madness |
| 22:53.13 | jfindlay | personally I've always liked salt's unified approach to event management, orchestration, and configs |
| 22:55.46 | JPaul | I thought kubernetes was a container based system? It also can act as a pure CMS? |
| 22:55.58 | joshh | no |
| 22:56.18 | jfindlay | and I'm skeptical of any natural advantage of containers over VMs, especially if you have to rearchitect your whole system container style |
| 22:56.21 | joshh | but a lot of people stop needing config management for their kube worker nodes, if all they need to do is run apps and be on the network etc |
| 22:56.44 | JPaul | ah |
| 22:57.09 | joshh | or if the only type of node a small company has are "app servers |
| 22:57.19 | SunSparc | +1 |
| 22:57.21 | joshh | then a kube setup with no config management might be possible |
| 22:58.09 | joshh | but config management is still useful for managing long lived server configs, or provisioning images |
| 22:58.16 | SunSparc | We are using Hashicorp Vault for config management on our kubernetes cluster. |
| 22:58.20 | jfindlay | joshh: so what do you do when you need to edit configs: redeploy the container? |
| 22:58.42 | joshh | the container should only be an application instance |
| 22:58.48 | SunSparc | jfindlay: That is what we do. Burn it down and spin up a new one. |
| 22:58.56 | joshh | that gets redeplopyed for new code |
| 22:59.18 | jfindlay | that's a great model if you can get it to work |
| 22:59.21 | SunSparc | Most of our nodes only live for a max of 24 hours. |
| 22:59.44 | jfindlay | it can be hard to crank old systems, and institutionalized processes towards that workflow |
| 22:59.52 | joshh | the host it goes into can be cloud native and abstracted away, or something simple like coreos, or a standard server managed by an infra team configured using puppet/salt/chef/ansible/anything |
| 22:59.53 | SunSparc | so true |
| 23:00.19 | joshh | thats why nobody likes working at stodgy old fashioned companies |
| 23:00.40 | joshh | bad for morale and bad for resume buzzwords |
| 23:00.54 | jfindlay | I've never seen a company that doesn't have some ugly cruft in one place or other |
| 23:00.54 | SunSparc | =) |
| 23:01.16 | jfindlay | that's why I'm depressed all the time |
| 23:01.54 | SunSparc | ~cheer jfindlay |
| 23:01.54 | infobot | Three cheers for jfindlay! Hip hip Hurray! Hip hip Hurray! Hip hip Hurray! |
| 23:02.04 | joshh | just be "that guy" who gets credit for replacing the old system |
| 23:02.11 | SunSparc | +1 |
| 23:02.12 | joshh | instead of the poor sucker left holding the bag |
| 23:02.20 | joshh | after someone else comes in as the new "architect" |
| 23:03.19 | jfindlay | also, container buzzwording of ops processes can thrash your systems so that instead of a few large monoliths, the workings of which nobody comprehends, you chop that magic into several (hundred) pieces of the puzzle |
| 23:04.01 | joshh | but basically the major benefits of containers are packaging, with no host level or systemwide dependencies installed or conflicts to worry about, and scheduling/placement/scaling, which mesos or kubernetes do nicely |
| 23:05.21 | joshh | you never need to send someone a ticket saying "install libfoo2.0 on the app cluster for service y", and then have it turn into a nightmare because some other service needs the older version and they can't easily coexist, etc |
| 23:05.40 | joshh | you just update your own container and thats it |
| 23:05.58 | SunSparc | ~containers++ |
| 23:06.05 | SunSparc | ~karma contaners |
| 23:06.05 | infobot | contaners has neutral karma |
| 23:06.06 | joshh | and you don't need to manage which specific nodes the containers go onto, because kubernetes does it for you |
| 23:07.16 | joshh | so as long as soemone either make sure the kubernetes cluster is big enough (and that kubernetes is working), or that the cloud kube offerings are being paid for, everything is fine |
| 23:07.57 | joshh | of course people need to make sure your containers get built and deployed afte changes, but that's what keeps people employed these days |
| 23:08.01 | jfindlay | and you have developers who understand how to write isolated services that don't have intricate dependencies |
| 23:08.33 | joshh | they can depend on other services, but not any systemwide dependencies |
| 23:08.42 | joshh | other than container mounted volumes or something |
| 23:09.53 | jfindlay | I'm talking about you can't just deploy $service.x 2.0 when $service.y depends on $service.x 1.1 |
| 23:10.06 | joshh | ah, ya |
| 23:10.34 | joshh | so if your services are all in a typical SOA setup, that would be for the service owners/teams to figure out together |
| 23:11.24 | joshh | "hey $service-users, make sure you are using the new api by whatever date, and let us know if you have a problem, etc" |
| 23:12.16 | joshh | or often it's "switch to serviceB since serviceA is now deprecated and unowned and a bunch of new hires built serviceB to replace it" |
| 23:12.57 | joshh | depending on management quality |