Back on topic, let's not make this thread a support group for disenfranchised CF users. That can be it's own thread, right next to the zmanda aroma-therapy thread. ;-)
Education, LOPSA keeps coming back to this as a root problem. We ask ourselves what good is DevOps? We have no clue as a group, because there's little group consensus on what DevOps means. Can I DevOps a bunch of Windows 8 clients? Or is DevOps strictly related to build-and-release? Or is it just a warm fuzzy cultural standard? Is it possible to even hire a DevOps like I can a system administrator? Can I DevOps without specific tools? We need to come to common terms first within our own Body of Knowledge before we can even decide if we want to change it or add DevOps to an ever growing list of vague terms. Where do we start? Do we make a list of things we all do everyday and find the most common elements? Do we list frameworks and multi-level abstractions that are worth knowing? Do we list worthwhile certifications (there are at least two)? Is there no need to do any of this? These threads go round and round without resolution. Once we define the map, the territory will become easier to navigate. So ... do we need to have a LOPSA committee on building a BOK? What are they supposed to create? What do they get out of it? "But lo! men have become the tools of their tools." On Tue, Jul 2, 2013 at 8:58 PM, Lawrence K. Chen, P.Eng. <[email protected]>wrote: > > > ----- Original Message ----- > > On Mon, 1 Jul 2013, Corey Quinn wrote: > > > > > Agreed-- but the counterpoint is that ops folks have to get better > > > at > > > development than they currently are to continue to thrive in this > > > kind > > > of environment. > > > > As a former developer, I have this covered. I sometimes forget there > > are > > a number of sysadmins who aren't so good at writing code. > > > > I'm a former developer too...and been dabbling on the side again > recently... > > > > Whether it's easier to train an ops person to be better at > > > development, > > > or to instill an ops mentality in a developer, is left as an > > > exercise > > > for the reader. > > > > I wound up being a sysadmin because I was always the guy on the team > > making sure all the little details were covered. I was the guy who > > made > > sure ALL of the stanza in a Makefile worked correctly. I was the guy > > who > > made sure the sandbox setups were completely correct, etc. > > > > I was detail oriented, etc...but there was also a void that led me to wear > the sysadmin hat. Until I found myself doing just sysadmin (and wanting to > do more, there was a time that I wanted to know all areas here.... still > would like to get to know our SAN, which is back to only one person know > it....the original person, who has moved up where he's both coach and > player $boss...he's asked a few times whether the sysadmin position he had > before he became manager is available or not.) > > > > …but you can butter my biscuits and call me Sally if you think I'm > > > about > > > to sit and quietly take criticism of LOPSA from the guy who brought > > > us > > > the trainwreck that is CFengine (at least through version 2, > > > haven't > > > looked into 3). The picture he paints of the uninvolved sysadmin > > > who > > > forms the "Department of No" is *exactly* the kind of admins I've > > > known > > > in my career who recommend CFengine for deployment. > > > > > > The folks who "get it," the folks who are more disciplined in their > > > approach, who learned to adapt? They're all deploying > > > Chef/Puppet/Salt/Ansible and run screaming from CFengine. I'm not > > > saying > > > it's a causal relationship, but the correlation is definitely > > > there. > > > > Most of the environments I've worked in have refused to even look at > > any > > kind of configuration management systems, including CFengine. I've > > been > > fighting for something in many of my previous jobs. Those are are > > where a > > lot of sysadmins we need to convert are working. Ones who think > > "I've got > > some Perl scripts. Why change?" > > > Our previous $boss had taking this stand....kept saying it would destroy > systems. Which sure enough, it has. But, though all of them could've been > avoid if the $admin causing it had paid better attention to the details. > > IE: add existing servers to firewall class, should come after ensuring > firewall definitions are on policy server for existing servers. Replacing > everything with generic firewall (closes everything except enough to do > initial configuration from our admin range.) Which we discovered years > later that he had cleaned up by disabling firewalls on a lot of > hosts...which in one case had a server exposed that shouldn't have been, > and where somebody had developed an app in his private VPS somewhere based > on it being exposed (which he continued to maintain after he had > left)....which I then got into trouble for breaking because I fixed the > firewall. They eventually granted a policy exception for it to continue to > work...before it was moved into the datacenter. It should never have been > externally hosted, though for HIPPA reasons.... > > > > I'm most interested in Chef. Salt looks worth watching, but I > > wouldn't > > deploy it in production yet. On the other hand, many of the > > developers I > > know are going nuts over Salt since it's the new shiney... > > That was how our $boss sold that he's scraping all the work in upgrading > from CF2 to CF3, to go with Chef....even though he said right away, that a > couple of key features in CFEngine that we depend on heavily aren't > available in Chef. > > He had looked at Salt, but guess he never got it to go on Solaris. > > -- > Who: Lawrence K. Chen, P.Eng. - W0LKC - Senior Unix Systems Administrator > For: Enterprise Server Technologies (EST) -- & SafeZone Ally > Snail: Computing and Telecommunications Services (CTS) > Kansas State University, 109 East Stadium, Manhattan, KS 66506-3102 > Phone: (785) 532-4916 - Fax: (785) 532-3515 - Email: [email protected] > Web: http://www-personal.ksu.edu/~lkchen - Where: 11 Hale Library > _______________________________________________ > Discuss mailing list > [email protected] > https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss > This list provided by the League of Professional System Administrators > http://lopsa.org/ > -- Joseph A Kern [email protected]
_______________________________________________ Discuss mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
