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!
On Sep 13, 2012, at 8:15 AM, Peco <pecomeis...@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.
On 9/13/12 9:25 AM, "Brad Knowles" <b...@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:
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.
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.
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.
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.
> 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.
> 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.
> , 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.
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... :)
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.
- 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.
On Sat, Sep 15, 2012 at 2:42 AM, Teyo Tyree <t...@puppetlabs.com> wrote:
> > 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.
> 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.
On Fri, Sep 14, 2012 at 3:23 PM, Adam Jacob <a...@opscode.com> wrote:
> 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
> On Sep 14, 2012, at 1:22 PM, "James Turnbull" <ja...@lovedthanlost.net>
> wrote:
> > -----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.
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 ;-)
> > 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.
> 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.
> 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?
On Fri, Sep 14, 2012 at 3:30 PM, Teyo Tyree <t...@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.
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.
On Thu, Sep 13, 2012 at 10:15 AM, Peco <pecomeis...@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!
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?
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!
