Configuration Systems

Mailman List Mirror (Read Only)
1

Lurker speaking... beware...

I have been talking with some folks from various industries about
configuration systems ala Bcfg2, Puppet, Chef, and others. Many of
them care far too much about the current nodes configuration status as
some admin had logged in and changed something. I am authoring a
system called Enablement that uses what ever technology needed (ssh,
telnet over admin vlan, rsh, etc...) to push a planned system/config
to the device. Monitoring and auditing are all the same at the moment
as we need historical data on when a service or port started and
stopped offering its planned or unplanned service. For a meeting
Thursday I am looking forward to the future of configuring systems.
My idea is push + netblock scanning of services. With stacks for
clouds we can startup and shut down nodes easy. Would a bend over
backwards config reader for all the "Configuration Management Systems"
be the best medium ground from the service provider point of view?

Enablement.... Send another man to fight on the front line.

2

Jonathan

That is the exact question I have asked myself many times. All of the
major players in Configuration management have a "client" program that
must run and at times requires some libraries that are newer than the
platforms a company may need to support or that clients may wish
supported. Another issue is the secure communication over a
proprietary or SSH connection and not allowing secured VLANs or other
services like RSH and Telnet over a point to point connection.

Also you will find that the demand for cloud systems and the complex
languages used in the "Configuration Management Systems" do not easily
translate to the existing and developing cloud infrastructure.

and stuff...

3

Jonathan

That is the exact question I have asked myself many times. All of the
major players in Configuration management have a "client" program that
must run and at times requires some libraries that are newer than the
platforms a company may need to support or that clients may wish
supported. Another issue is the secure communication over a
proprietary or SSH connection and not allowing secured VLANs or other
services like RSH and Telnet over a point to point connection.

I would argue that not allowing telnet/rsh in favor of requiring SSH is a good thing.

As to the client program, so long as the system makes the client available via
open source and/or publishes the required client API, you should be able to
work around any library issues or system age issues by developing your own
client component.

Also you will find that the demand for cloud systems and the complex
languages used in the "Configuration Management Systems" do not easily
translate to the existing and developing cloud infrastructure.

This is a hard problem to solve. Not the least of the difficulties is the fact that
if you ask 50 engineers to define "Cloud", you will get at least 100 definitions
many of which are incompatible to the point of mutually exclusive.

Owen

4

"cloud" == "you rented in a colo, but have no clue where".

5

Congratulations of being one of the first in the room to offer a candidate
definition.

So... What's your second definition?

If you don't have a second definition, you're just asking someone else to provide
3 or more.

Owen

6

Only if you're talking IaaS, and that's only a very vague and not necessarily accurate description of that too. When you start describing what cloud is you've also got to go into the realms of private clouds (using, for example, openstack), on your own infrastructure in your own datacenter. That's before you even start delving into PaaS, SaaS "clouds" etc.

"Cloud" is a marketing term, not an engineering one.

Paul

7

what cloud is you've also got to go into the realms of private clouds
(using, for example, openstack), on your own infrastructure in your own
datacenter.

Same definition. The user I've provisioned still has no idea where I provisioned him.

That's before you even start delving into PaaS, SaaS "clouds" etc.

Still the same definition. You have no idea where you're provisioned from.

8

Your original definition: "cloud" == "you rented a colo, but have no clue where". I know exactly where my colo is. I know exactly where my physical servers are. If I run a private cloud on those servers and provision stuff there, I'll still know exactly where my colo is and I'll still know where my "cloud" infrastructure is deployed (http://en.wikipedia.org/wiki/Cloud_computing#Private_cloud) Even that wiki page doesn't quite go far enough in defining cloud, at least compared to stuff people sell as "cloud" (as I said, cloud is a marketing term, not an engineering one. Its accuracy is negligible)

Paul

9

It is like that supreme court judge who defined porn as "i know it
when I see it"

10

By my count, we now have 3 engineers that have chimed in and somewhere between
5 and 6 definitions. Q.E. D.

Owen

11

I posit the thesis that if you know where it is, it's not really a cloud, it's
just a server farm with a severe attack of buzzwords. The whole point of
"cloud" is that you've made "where" Somebody Else's Problem - and if you know
where it is because you're still managing it yourself, it isn't an SEP.

12

It is like that supreme court judge who defined porn as "i know it
when I see it"

a case which is notable in this context for having four differing
majority opinions.

13

On Thursday, 07 June, 2012 12:52, Owen DeLong observed:

This is a hard problem to solve. Not the least of the difficulties is
the fact that if you ask 50 engineers to define "Cloud", you will get
at least 100 definitions many of which are incompatible to the point
of mutually exclusive.

That is *the* definition of "Cloud". The term "Cloud" is a proxy for the expression "under the exclusive control of a third-party over which we have no influence nor control in order to gain plausibile denibility and CYA ptotection if something bad happens".

Eg:

Store you data "in the cloud".
Run a server "in the cloud".
Put your e-mail "in the cloud".
Run your application "in the cloud".

See, 100% accurate!

14

Here is my take on this...

I think that hosting/datacenter admins sat around one day and lamented
about the fact that so many of their clients were buying dedicated
hosting servers and utilizing a very tiny percent of the CPU & storage.
Often, the customer had been burned by "shared hosting" years earlier
because of another shared hosting customer on the same server crashing
the entire server, thus making everyone on that box suffer. So dedicated
hosting became critical for many businesses who outsourced their
hosting. But, again, many of those boxes sat year round utilizing
something like <5% of CPU, and <5% of the available disk space (after OS
installation).

Then "virtual servers" matured, where you could create entire logically
partitioned boxes running on the same server. These were sold as
"virtual dedicated" servers, which was a step up from "shared hosting",
and a step down from getting a dedicated server. But many didn't like
this because they it was inherent that they were stuck on the same box
with other customers. Those with deep pockets didn't take the bait. It
had a niche, but didn't make for a good "sales pitch".

Next, they found a way to leverage virtual servers by making it so that
the virtual server didn't have to reside on one box... but could
dynamically use various resources from a server farm, as needed. (for a
simplified explanation). Thus, the "cloud" was then born.

Now... all those unused CPU cycles and disk space are not wasted any
more... they are dynamically put to use. RESULT>>>the aggregate sum of
all that re-allocatable drive space and CPU cycles is ENORMOUS. It makes
for a massively more efficient leveraging of hardware and software. The
ratio of hardware costs to costumer revenue is massively better for a
hoster/datacenter compared to selling traditional dedicated servers.

That is not necessarily bad because some of the cost savings is passed
back to the consumer in the form of lower prices. So this is not evil.
Plus, there is an ability to "scale up" that exists with the cloud
(where affordable!).

But the funny part about this is that (a) the extent that cost savings
are passed back to the client AND (b) the improved "scale up"
technology.. those are the ONLY 2 benefits of cloud computing.
Everything else is to benefit the hoster/datacenter. That so many
CEOs/CTOs/directors/etc have bought into the hype, and see some kind of
magical benefits seemingly beyond this... is just amazing.

Personally, I prefer paying a little extra for my own dedicated and/or
co-located servers... where I'm in total control of ALL aspects of
hardware/software.

15

Rob McEwen wrote:

Personally, I prefer paying a little extra for my own dedicated and/or
co-located servers... where I'm in total control of ALL aspects of
hardware/software.

You are resisting the lure back to the mainframe paradime [sic], let go of your resistance and let yourself be gently wallowed back into the comfortable cosiness of the wooly dinosaur.