DevOps withdrawals!

[Peco]

Fellow DevOpsers,

I am starting to suffer from DevOps withdrawals! I know you all out there are doing cool stuff, post what you are doing and why we should care! Is the DevOps passion fizzling? Or is everyone busy making DevOps profits (or trying to anyway)? Shameless advirtising is ok too if you want to share some of your new cool features that can make our lives easier. Chef and Puppet people we still love you and want to hear what is new and exciting. Come one people jazz it up!

[Brad Knowles]

On Sep 13, 2012, at 8:15 AM, Peco <pecom...@gmail.com> wrote:

> Fellow DevOpsers,
> I am starting to suffer from DevOps withdrawals! I know you all out there are doing cool stuff, post what you are doing and why we should care! Is the DevOps passion fizzling? Or is everyone busy making DevOps profits (or trying to anyway)? Shameless advirtising is ok too if you want to share some of your new cool features that can make our lives easier. Chef and Puppet people we still love you and want to hear what is new and exciting. Come one people jazz it up!

What I've been doing lately is working on implementing Continuous Integration, currently based on Jenkins. Nothing exciting there.

There is an upcoming Jenkins User Conference at the end of September in San Jose, however -- if anyone is interested.


I know that the Erlang-based rewrite of chef has either been released (at least in beta), or will be released soon. That's supposed to provide significant scalability enhancements for the open source version, based on all the experience they've had with Hosted Chef.

That's in addition to the recent release of open-source Chef that included the "whyrun" feature, which is intended to tell you what would be done and why, without actually doing it. This is a little different than Puppet's "dry run" feature, which is based on information in the Directed Acyclic Graph that is built of all the various modules.

Chef doesn't have a DAG, which they believe is an advantage, but that also made implementing anything like a "dry run" feature a more complicated affair.

Speaking only for myself, I definitely lean towards Chef, but I do feel that Puppet may well still have some features or methods that are useful for me to learn from. And I can fully understand why someone else might prefer Puppet instead -- I think there's plenty of room for both tools.


I've also been very interested in seeing all the stuff being reported in the DevOps Weekly announcement list from the page at <http://devopsweekly.com>. Lots of good stuff being reported there.

Oh, and Alan Robertson did an amazingly interesting talk at LinuxCon 2012 recently, on his Assimilation Monitoring project (see <http://assimmon.org/>). I've been helping to edit the video of the talk, and I think the final result will be very good. When the video is finalized, I'll post a link here and you can check it out.

--
Brad Knowles <br...@shub-internet.org>
LinkedIn Profile: <http://tinyurl.com/y8kpxu>

[Adam Jacob]

On 9/13/12 9:25 AM, "Brad Knowles" <br...@shub-internet.org> wrote:
>I know that the Erlang-based rewrite of chef has either been released (at
>least in beta), or will be released soon. That's supposed to provide
>significant scalability enhancements for the open source version, based
>on all the experience they've had with Hosted Chef.

It's awesome. It also has a significant impact on the operating
characteristics - the service itself is so much leaner and easier to
manage. It's delightful, and the team did a great job with it. What's
interesting about this shift from a broader point of view is this: once
the API on the server side was stable, it made sense to start to look at
what would make it truly sing in production.

>That's in addition to the recent release of open-source Chef that
>included the "whyrun" feature, which is intended to tell you what would
>be done and why, without actually doing it. This is a little different
>than Puppet's "dry run" feature, which is based on information in the
>Directed Acyclic Graph that is built of all the various modules.
>
>Chef doesn't have a DAG, which they believe is an advantage, but that
>also made implementing anything like a "dry run" feature a more
>complicated affair.

So, that's not really true. Chef does not have a DAG for the resource
collection, but it's not because graphs are bad. It's because consistency
of ordering matters, and it is very difficult to get consistent ordering
out of a topologically sorted directed graph (which is how you get the
final order of resource to apply in Puppet.) They've done some work making
things more consistent, but there are still degenerate cases where it
isn't. Some people care, some people don't. It's cool. :)

In both cases we're building a collection of resources to manage. Puppet
builds a DAG with explicit dependencies and sorts it. Chef builds an array
and provides tools for manipulation.

Now, as it relates to why-run. The difficulty in implementing a dry-run
style mode in any tool aren't really around how you are modeling the
collection of resources under management. It's in deciding how to report
status to the user, and what assumptions are being made for you. For
example:

package "foo"

service "foo" do
action [ :enable, :start ]
end

What can you say about the system when nothing has ever been done? You can
say that the "foo" package is or is not installed. You can say that the
service "foo" is or is not enabled or running. Taken in isolation, that
may be interesting. But what if we can't query the service at all? What if
the package "foo" doesn't actually install a service named "foo"?

Dan DeLeo was the one who came up with the solution to this sort of
problem, and it was this: we bake in to each resource the pre-conditions
that would need to be met in order for it work. So we say "package foo
would be installed", and "service foo would be enabled and started; but
the service doesn't exist, so we assume it comes from a package". The
result is that we don't just tell you what we would do - we tell you the
assumptions by which we got there, which make the mode as reliable as we
can make it.

Nothing architecturally about Chef made dry run a challenge - it was
getting it to a place where we felt like it would be trustworthy that was
the hard part. Dan, and the rest of the team that built this feature,
knocked this problem out of the park.

If you want to know more about why dry-run modes are hard, and what
why-run does that is neat, check out this mailing list post from btm:

http://lists.opscode.com/sympa/arc/chef/2012-02/msg00257.html


And the why-run announcement:

http://www.opscode.com/blog/2012/09/07/chef-10-14-0-released/


Best,
Adam

[James Turnbull]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Adam Jacob wrote:
> So, that's not really true. Chef does not have a DAG for the
> resource collection, but it's not because graphs are bad. It's
> because consistency of ordering matters, and it is very difficult to
> get consistent ordering out of a topologically sorted directed graph
> (which is how you get the final order of resource to apply in
> Puppet.) They've done some work making things more consistent, but
> there are still degenerate cases where it isn't. Some people care,
> some people don't. It's cool. :)
>

So be clear, we've done more than "some work making things more
consistent". The final resource ordering of Puppet resources will be
consistent every run since the 2.7.0 release. There are no degenerate
cases that I am aware of. But as Adam says some people care, some people
don't.

Regards

James Turnbull

- --
Author of:
* Pro Puppet (http://tinyurl.com/ppuppet)
* Pro Linux System Administration (http://tinyurl.com/linuxadmin)
* Pro Nagios 2.0 (http://tinyurl.com/pronagios)
* Hardening Linux (http://tinyurl.com/hardeninglinux)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQU5H0AAoJECFa/lDkFHAy8hcH/jsXrtikndHQ0QibZlB88mxn
yvpjInI9YR1FHmHjy63bt9FKb9keFeDwPHNv9+Prq/7QchM4xo14QW9Sl3g0jjcq
AUb5ODiDpMmVjwCTws38iRoeek8g/qRHGuFrL2iz73uIZ0GfGw4yc5yEaGGGlaiL
e0iE+D1CCJRcsxKulwipG+Oi3GxauSprmIJGR3GZ4FjAsnu/UvpYp2yV5bBKzp6a
F1JlATH6XT0C7/4qfzUlbu0saVrY5zfraZiR+dnMr+WpOX4kEJ5Blv5Rwp/pAJBG
hleoam0a/euBZHAtlMYva99Wz56WUORVrjgsgwzohKQv94Z3C66LUHx5eKoi8E8=
=yfp1
-----END PGP SIGNATURE-----

[Teyo Tyree]

What have we been up to at Puppet Labs?

We released PuppetDB, a high performance database for storing and querying the data that Puppet generates including the DAG that we produce. This is going to be a key component leveraging the power of our dependency graph for insight and cross node dependency and configuration management. We are already doing a lot of awesome things with PuppetDB, it is super fast and a drop serves as a drop in replacement for Storedconfigs.

http://docs.puppetlabs.com/puppetdb/0.9/index.html

We released Razor, a bare metal provisioning tool built in partnership with EMC. Razor aims to allow you to automatically inventory your hardware using Facter and an in memory kernel. Once inventoried operating systems can be deployed to the inventory via a Restful API. Once the OS is provisioned, Puppet takes over the rest of the configuration.

http://puppetlabs.com/blog/introducing-razor-a-next-generation-provisioning-solution/

We added Windows support to Puppet and Puppet Enterprise.

http://puppetlabs.com/puppet/whats-new/

The Telly release of Puppet is just about out of the door with a big focus on performance and integration of Hiera.

RC6 is available here. 

http://projects.puppetlabs.com/projects/1/wiki/downloading_puppet

Finally, a little promotion, we have PuppetConf coming up in SF Sept 27/28. We are incredibly humbled by the speaker line up and what our customers and community are accomplishing with the Puppet platform. We will have live demos of Razor, new Google Compute Integration (think Cloudformation written in Puppet Lang) and a workshops on device management with Puppet.

http://www.puppetconf.com

Cheers,

Teyo

--

Teyo Tyree ::  www.puppetlabs.com :: +1.503.208.4475 :: http://protocol.by/teyo

[JaimeGago]

On Sep 14, 2012, at 1:42 PM, Teyo Tyree wrote:

> What have we been up to at Puppet Labs?
>
> We released PuppetDB, a high performance database for storing and querying the data that Puppet generates including the DAG that we produce. This is going to be a key component leveraging the power of our dependency graph for insight and cross node dependency and configuration management. We are already doing a lot of awesome things with PuppetDB, it is super fast and a drop serves as a drop in replacement for Storedconfigs.
>
> http://docs.puppetlabs.com/puppetdb/0.9/index.html
>
> We released Razor, a bare metal provisioning tool built in partnership with EMC. Razor aims to allow you to automatically inventory your hardware using Facter and an in memory kernel. Once inventoried operating systems can be deployed to the inventory via a Restful API. Once the OS is provisioned, Puppet takes over the rest of the configuration.
>
> http://puppetlabs.com/blog/introducing-razor-a-next-generation-provisioning-solution/
>
> We added Windows support to Puppet and Puppet Enterprise.
>
> http://puppetlabs.com/puppet/whats-new/
>
> The Telly release of Puppet is just about out of the door with a big focus on performance and integration of Hiera.
>
> RC6 is available here.
>
> http://projects.puppetlabs.com/projects/1/wiki/downloading_puppet
>
> Finally, a little promotion

Hmm "Finally" ?Really? That's a bold one...

[James Turnbull]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

JaimeGago wrote:
>> Finally, a little promotion
> Hmm "Finally" ?Really? That's a bold one...
>

Teyo is very bold... :) It's all open source software so I don't really
see telling people about it as promotion. As many would know I don't
care what tool you use - use the tool that suits you and your
environment best - but I think most of those releases are pretty damn
cool... :)

James

- --
Author of:
* Pro Puppet (http://tinyurl.com/ppuppet)
* Pro Linux System Administration (http://tinyurl.com/linuxadmin)
* Pro Nagios 2.0 (http://tinyurl.com/pronagios)
* Hardening Linux (http://tinyurl.com/hardeninglinux)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQU5zWAAoJECFa/lDkFHAyK0cH/0gE2BIvv1JNjIr34GDfk+NK
PAqCo+PplvUHg3huNzyqUa/HkDSYZBhfA1e1B5VXIGq6ppBlS5ybjISjL85QnRpI
1Bc/3/9+EOcxPz1+xCQ48vxS9IkJ4geLq1QJkgMWf31k6wZOYznm9MjFp8TXe1wN
sLHPYAidOBqOsYSWkP8F8RP1Ro4jBXQPGAqYekBFKNUfs/t+nz9oruTVllP5zDMP
Ud/njExx25E/S2h8JXz4XIoNcMVW07XQyBfT1ozYN3bwdWCThhV/7fQSxjlmiXas
6voknSd4Qcn8m3YX/lTyJwdGuxwzieHNNjETAhz1+v/DStV/+PsLUs756ZWBnG4=
=hsfd
-----END PGP SIGNATURE-----

[Teyo Tyree]

 > Finally, a little promotion

Hmm "Finally" ?Really? That's a bold one...

Jamie, I meant event promotion. The questions in this thread was "what are we up to". Just tried to answer that question. Sorry, if it seemed like marketing to you.

-teyo

[Ranjib Dey]

• Been working on public cloud mostly, with daily releases on j2ee and RoR apps. 
• Cross node orchestration is still an area needs improvement
• Recently finished a knife based user management tool that manages user across openvpn,ssh and chef server (api clients) using a single interface (a single PKI system for everything). It contains some hack though.
• With recent developments in foodcritic, chefspec, minitest-handler and vagrant (pluggable provisioning system) "infrastructure as a code" can now be practiced as TDD. Now we have CI pipeline for that has following stages:
1. cookbook syntax check (knife cookbook test -a)
2. Lint check (foodcritic -f any cookbooks/)
3. Unit tests for modules (libraries that are included in cookbooks, tests are written in raw rspec, rspec-mock)
4. Unit tests for cookbooks (chefpsec based)
5. Functional tests using minitest handler + vagrant (i am creating and destroying vms for each cookbook testing )
6. Idempotent test using vagrant  (runt the cookbook twice, in the second time checking if no resources are updated)
• I am also supplementing these with few nagios checks that tests for certain bad stuff in existing infrastructre, e.g
• Nodes with empty run list
• Nodes under _default environment
• Nodes with direct recipe assigned to them
• Empty environments
• Cookbooks that are applied in production environments but not frozen .
• All these checks are also available as `knife health` set of tools.
• Extending CI server becoming a pain. As we move more towards continuous delivery, `truth` from which system's state can be derived is scattering across the CI server (artifacts primarily) and configuration management system. I suspect in future will see some bridges between configuration management systems and continuous integration system. One will trigger the other, and extensibility will decide which one will be the master and which one will be slave.
• For SaaS or IasS configuration management , new approaches are evolving. Since there are not tied to a particular host/node/server, managing their configuration (like AWS- IAM or Ultradns) is not idiomatically elegant current configuration management systems. I tend to model them as a manifest or recipe and apply it to some meta node (some instance thats not under app services). 

In short,, the entire field is evolving .. momentum of the tool-chain  development as well as devops movement as a whole is picking up. I was going through the usenix publications last week, they too mentioned about devops there, from more ops/sys-admin perspective.

[Adam Jacob]

Is this for every node with an identical dag, or just per host with the same dag? Sorry if I misunderstood - I don't mean to be spreading falsehood.

Best
Adam

Sent from my iPhone

[Teyo Tyree]

Every host with an identical DAG.

[JaimeGago]

No it's my bad the original email was indeed pretty explicit in its body and you were indeed answering the original question, I guess my only excuse if any is that the question wasn't copied in your answer.

Since Puppet and Chef were explicitly called out, maybe we could get someone from CFEngine?

Outside of CM, Vagrant seems everyday more relevant to at least my "devops" environment so it'd be nice to hear about the progress on the different hypervisors integration.

Finally about the withdrawals I'm getting all my devops injections via twitter these days, I like this list http://www.agileweboperations.com/20-devops-guys but there is much more than that in my feed, heck I'll compile one, that'd be my contribution ;-)

J.

[Jonathan Clarke]

On 15/09/12 03:39, JaimeGago wrote:
> No it's my bad the original email was indeed pretty explicit in its body and you were indeed answering the original question, I guess my only excuse if any is that the question wasn't copied in your answer.
>
> Since Puppet and Chef were explicitly called out, maybe we could get someone from CFEngine?

I'm not from the CFEngine *company* myself, but I can fill in with some
updates on what's going on community-wise. I'll also forward this to
Mark Burgess (CFEngine creator and CTO) and ask if he wants to join in
and tell the story from the inside.

So CFEngine has added a lot of features over the summer, mostly related
to the language itself. To list a few: namespaces (variables and classes
are scoped within a namespace), class inheritance for bundles called by
other bundles, default parameters for bundles, metadata type promises...
These will all be in the 3.4 release. For those not (very) familiar with
CFEngine, this may not mean much, but these changes have enabled the
creation of the Design Center.

The CFEngine Design Center (http://github.com/cfengine/design-center) is
a collaborative repository of "sketches" (similar to cookbooks in Chef,
etc) each of which contains the "know-how" to manage some
service/config/whatever. The most awesome thing about sketches are that,
thanks to the new language features, they can be both quick and easy to
start with and at the same time very generic and reusable (think
overridable defaults), meaning you can actually use them and keep
updating to new versions from the source, without changing your own
"configuration code" or having to hack the sketches.

Other various exciting things going: a CFEngine user meetup in San
Francisco last week, running CFEngine on various embedded devices
(Android in particular), deb/yum/zypper package repos online, CFEngine
Enterprise free up to 25 nodes...

Hope this fills in a bit of info about CFEngine, until Mark joins us.

Jonathan

[Jonathan Clarke]

On 15/09/12 12:22, Jonathan Clarke wrote:
> On 15/09/12 03:39, JaimeGago wrote:
>> No it's my bad the original email was indeed pretty explicit in its
>> body and you were indeed answering the original question, I guess my
>> only excuse if any is that the question wasn't copied in your answer.
>>
>> Since Puppet and Chef were explicitly called out, maybe we could get
>> someone from CFEngine?
>
> I'm not from the CFEngine *company* myself, but I can fill in with
> some updates on what's going on community-wise. I'll also forward this
> to Mark Burgess (CFEngine creator and CTO) and ask if he wants to join
> in and tell the story from the inside.

Ah, and since the original question was "what have you been up to?", I
guess I should at least explain why I'm familiar with CFEngine and what
I've been doing too :-)

I've been working on Rudder (http://www.rudder-project.org). Rudder is
based around a web UI that aims to provide a simple workflow around
configuration management, and automatic reporting. A few typical use
cases could be:
* "I've written all this clever config management stuff, and I want my
non-CM-savvy co-workers to use it, but they don't have time to learn it
and sometimes they need to change a couple of settings. I want them to
be able to do that without being able to change the code."
* "I've got to comply to this set of rules that my boss/the company/the
government set. I think CM is the best way to do that, but I also need
an automatically generated report every week/month I can send them to
provide some feedback."
* "I'd like junior sysadmins to be able to look at the configs we use,
not change them quite yet, but still be able to deploy them to new
servers they build and check compliance."

You can clicky-clicky through settings in the web UI, then Rudder
generates a CFEngine config, to send out to the servers to manage. Thus
my involvement with CFEngine, which we use intensely - both to manage
the configs Rudder deploys (via Techniques, similar to the CFEngine
sketches I described in my previous message), and to manage a Rudder
server itself.

I've been working on preparing the very-nearly-ready 2.4 release of
Rudder, and in particular automating tests in the config & packaging
side of the tool. Now, automatic testing is pretty common, but it
becomes harder when you want to test a tool that manages a whole server,
or in fact several, and on several different OS which are very different
from a CM tool's perspective, and of course we have to build different
packages for. So I've been building a test suite that involves
continuously building packages, spawning VMs running different OSes,
installing the packages, running some tests (ie, test this config,
upgrade from version A to version B and check it works, etc), tearing
the VM down, etc, then getting the test results back into Jenkins. That
uses quite a bit of shell script magic and... libvirt.

Vagrant also came as an obvious possibility, but we found it easier to
automate with libvirt. We do have several Vagrant configs though, for
developers to work in a production-like environment, and for quick start
testing of Rudder (http://github.com/Normation/rudder-vagrant).

Guess I'm forgetting loads of things, but that's a start to contribute
to the discussion. Won't be making it to devops days in Rome
unfortunately, but will be at Velocity in London - I'm assuming others
from this list may also be?

Jonathan

[Jeff McCune]

On Fri, Sep 14, 2012 at 3:30 PM, Teyo Tyree <te...@puppetlabs.com> wrote:
> Every host with an identical DAG.

Adam,

It's actually way better than that, and has been for quite some time
now. The DAG's need not be identical, they only need to intersect.
Given two different DAG's, d1 and d2 which intersect on resources r1
and r2, unless otherwise specified by the end user r1 will always be
evaluated in the same order relative to r2, regardless of what node
Puppet is running on.

-Jeff

[Nathaniel Eliot]

I've been hammering the bugs out of the newest version of Ironfan
(https://github.com/infochimps-labs/ironfan), which enables multiple
cloud targets. We have only an EC2 adapter for it at the moment, but
more are in the pipeline: either Virtualbox or Vagrant, and then
VMware's vSphere (they forked Ironfan v3 for Serengeti) and maybe
Rackspace.

We've also got CI/CD in the works, though the specifics of that are
coming together much slower.

--
Nathaniel Eliot
T9 Productions

[Lewis Marshall]

I've been on holiday and doing some blue sky thinking about where DevOps could lead...

Has DevOps got the potential to form "open source IT services"?

Or put another way, could collaroratove DevOps evolve to provide basic pre-configured IT services that are deployed and maintained automatically for multiple organisations?

Check out my ramblings on my blog:

http://blog.deploymentsource.com/2012/09/open-source-it-as-service.html?m=1

It would be great to start a discussion on what services to provide, and to what type of business...

If there's interest I'll start to pull together some high level designs...

On Thursday, September 13, 2012, Peco wrote:

Fellow DevOpsers,

I am starting to suffer from DevOps withdrawals! I know you all out there are doing cool stuff, post what you are doing and why we should care! Is the DevOps passion fizzling? Or is everyone busy making DevOps profits (or trying to anyway)? Shameless advirtising is ok too if you want to share some of your new cool features that can make our lives easier. Chef and Puppet people we still love you and want to hear what is new and exciting. Come one people jazz it up!

--

Lewis

Mobile: 0788 757 3297

My web sites:

blog.deploymentsource.com

uk.linkedin.com/in/lewismarshall

www.itkeys.co.uk