Puppet users - Oct 2009 - Relation to DMTF's CIM

I was wondering how Puppet relates to the DMTF''s CIM.  AFAICT there is
a clear connection between the two, but I see very little discussion
on the topic on the list.

Thanks,
Cameron.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

2009/10/27 Cameron <cross@kojeware.com>:
>
> I was wondering how Puppet relates to the DMTF''s CIM.  AFAICT
there is
> a clear connection between the two, but I see very little discussion
> on the topic on the list.
Why do I sense a university dissertation... :)

There are overlaps between the DMTF Common Information Model (or CIM)
- see http://www.dmtf.org/standards/cim/ - and Puppet but the
relationship is probably closer between the CIM and Facter.

Both Facter and CIM are ways of articulating configuration information
about infrastructure.  The CIM schema is designed to standardise
definitions of characteristics of infrastructure with a view to
allowing vendors to develop tools that integrate easily with other
tools and output data in the same format, for example this is the CIM
definition of an NFS mount:

HardMount : boolean
ForegroundMount : boolean
Interrupt : boolean
MountFailureRetries : uint16
RetransmissionAttempts : uint16
RetransmissionTimeout : uint32
ReadBufferSize : uint64 {units}
WriteBufferSize : uint64 {units}
ServerCommunicationPort : uint32
AttributeCaching : boolean
AttributeCachingForRegularFilesMin : uint16 {units}
AttributeCachingForRegularFilesMax : uint16 {units}
AttributeCachingForDirectoriesMin : uint16 {units}
AttributeCachingForDirectoriesMax : uint16 {units}

Facter does a similar thing albeit in a less sophisticated (currently) way.

Regards

James Turnbull

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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi,

In my organization there are several separate teams that manage their own
applications.  For consistency''s sake I want to
''puppetize'' some aspects of the apps.

The problem is, I''m not the one who installs the apps and which apps
exist on which servers is out of my control.  If a specific directory exists, I
want puppet to do certain things, if it does not exist, I want puppet to ignore
it.

In pseudo-code:

if file_exists("/opt/orange_app") {
    # file exists, load the module
    include orange
}

Now, I saw this thread from a while back: 
http://www.mail-archive.com/puppet-users@googlegroups.com/msg01329.html

It suggests creating a custom fact which indicates if the file exists on the
client or not.  Well, frankly I don''t like that idea, for two reasons.

1.  I''d have to create a custom fact for every check, which would
become cumbersome/tedious and is (IMHO) is just a hack/workaround.
2.  The ability to determine whether a file exists via puppet would be a very
useful and powerful feature that many, if not all puppeteers could make use of. 
The mailing lists contain several postings to the effect of ''custom
facts work, just write your own and be quiet'', which frustrates me.  A
wise manager once told me that you should build your systems around the needs of
your business instead of building your business around the capabilities of your
systems.

I searched the open issues and didn''t find anything relating to such a
feature.  I see from the puppet Type Reference that ''exec'' has
an optional ''onlyif'' parameter, which is close to what
I''m looking for.  But instead of the ''onlyif''
applying to a single exec, I''d like it to to apply to an entire block
of code in my puppet manifest.  For example, in pseudo-code:

$orange_exists = "test -e /opt/orange"

if $orange_exists.exitcode = 0 {
    # file exists, load the module
    include orange
}

Thanks.


      

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi
> [...]
> 
> It suggests creating a custom fact which indicates if the file exists
> on the client or not.  Well, frankly I don''t like that idea, for
two
> reasons.
> 
> 1.  I''d have to create a custom fact for every check, which would
> become cumbersome/tedious and is (IMHO) is just a hack/workaround. 2.
> The ability to determine whether a file exists via puppet would be a
> very useful and powerful feature that many, if not all puppeteers
> could make use of.  The mailing lists contain several postings to the
> effect of ''custom facts work, just write your own and be
quiet'',
> which frustrates me.  
the main issue behind that is that all the functions are evaluated on
the server and only there.

And this makes totally sense due to other reasons.

So if you use the client-server setup you''re restricted to that. The
only information the server can get _from_ the client are facts or
information from an external source, which the client would have to feed.

But if you would stay with local execution only I think you''ll easily
able to do what you want.
> A wise manager once told me that you should
> build your systems around the needs of your business instead of
> building your business around the capabilities of your systems.
What I could always observe is that people asking for such things are
trying to get their used script thinking behaviour (to call it like
that) into puppet. But one of the main ideas of puppet is that it
changes the way how you look at your infrastructure and how you manage
your infrastructure. So actually: Yes, puppet changes the way your doing
your business.

cheers pete

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Mon, Oct 26, 2009 at 5:42 PM, James Turnbull <james@lovedthanlost.net>
wrote:
>
> 2009/10/27 Cameron <cross@kojeware.com>:
>>
>> I was wondering how Puppet relates to the DMTF''s CIM.  AFAICT
there is
>> a clear connection between the two, but I see very little discussion
>> on the topic on the list.
>
> Why do I sense a university dissertation... :)
>
You rang? :)

CIM has been a somewht-regular topic at LISA''s Configuration
Management Workshop (although I haven''t attended those since I left my
job as a university professor).  One of the authors of the CIM was at
one of the workshops, and she agreed that CIM could be understood as
an upgrade of certain SNMP MIBs for today''s systems, mostly aimed at
the SNMP/RMON community, not really at the problem Systems
Administrators are usually trying to solve.

I know of no Open Source Configuration Management products that are
significantly influenced by the CIM, although there are some
commercial products that are, primarily because the commercial
products are trying to ''sell to Enterprises'', which already
have an
install base of SNMP-based ''management solutions'', thus
consider CIM
as a Good Thing.  SysAdmins, on the other hand, tend to want a tiny
slice of what SNMP provides (i.e., only certain parts of a very few
MIBs), and want more ability to configure systems than what SNMP was
designed to deliver (i.e., while GET/PUT can certainly be used to
construct interesting systems, it''s too low level to be efficient; and
that''s not even considering many of the well-known issues with SNMP).
In other words, Sysadmins like Puppet. :)  (and cfengine, lcfg,
isconf, quattor, bcfg2, chef, etc -- all of which are tools that deal
with the space and problems that SysAdmins work with).
> There are overlaps between the DMTF Common Information Model (or CIM)
> - see http://www.dmtf.org/standards/cim/ - and Puppet but the
> relationship is probably closer between the CIM and Facter.
>
It''s both Facter and Puppet -- Facter has a Model built into it,
Puppet has a Model built into it, and you''re constructing a Model when
you define classes: when people talk about sharing Puppet recipes,
they are really trying to distill out something that roughly
corresponds to a piece of CIM.  It might help to think of Facter as
the leaf nodes and Puppet as the internal nodes in a CIM-like model.

It would be an interesting exercise (perhaps a decent Master''s project
or Capstone) to take the CIM and Facter+Puppet, do a Gap Analysis,
then modify Facter+Puppet to ''better cover an interesting area of CIM
with Facter+Puppet''.

Steven

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

> > The mailing lists contain
> several postings to the
> > effect of ''custom facts work, just write your own and
> be quiet'',
> > which frustrates me.  
> 
> the main issue behind that is that all the functions are
> evaluated on
> the server and only there.
Hi Peter, perhaps you started writing your response before reading my entire
message.  I suggested a possible solution - behavior similar to the
''onlyif'' option of the exec Type.  Look at the docs, exec only
runs the command on the client if the ''onlyif'' command, which
also runs on the client, returns an exitcode of zero.

http://reductivelabs.com/trac/puppet/wiki/TypeReference#id11

So, obviously some commands can be executed on the client and impact what
happens next.  I''m saying it would be nice to apply such logic to a
block of code instead of an individual exec.
 
> And this makes totally sense due to other reasons.
> 
> So if you use the client-server setup you''re restricted to
> that. The
> only information the server can get _from_ the client are
> facts or
> information from an external source, which the client would
> have to feed.
> 
> But if you would stay with local execution only I think
> you''ll easily
> able to do what you want.
If it''s so easy, please provide an example solution.  And if your
example consists of disparate facts to determine if specific files exist, please
don''t bother because that''s specifically what I said I
wasn''t looking for :-)
> > A wise manager once told me that you should
> > build your systems around the needs of your business
> instead of
> > building your business around the capabilities of your
> systems.
> 
> What I could always observe is that people asking for such
> things are
> trying to get their used script thinking behaviour (to call
> it like
> that) into puppet. But one of the main ideas of puppet is
> that it
> changes the way how you look at your infrastructure and how
> you manage
> your infrastructure. So actually: Yes, puppet changes the
> way your doing
> your business.
What I''m looking for here is nothing extreme.  It''s very
simple.  A set of puppet logic that''s only evaluated if a certain
condition on the client is met.  What''s wrong with that?  It sounds
very reasonable to me.  On the contrary, having the mindset that everything
should be written as a custom fact, or extension or whatever, illustrates the
point I was trying to make.  Sure it works, but it''s a work-around. 
People get used to the extra effort required and consider it old-hat when in
actuality (again, IMHO) it''s not ideal and in many scenarios is a
serious limitation.

If we use such lines of thinking, then let''s just go ahead and get rid
of the conditional operators introduced in 0.24.6.  The only test you need is
true or false!  Of course I''m kidding here, I love the ability to use
more complex expressions.


Anyway, it appears that what I''m looking for may not be possible today
without custom facts.  Ok, fine.  My next question is, why?  If it''s
because such functionality just hasn''t been added yet, that''s
perfectly reasonable.  I''ll be glad to submit a more detailed and
descriptive feature request.  However, if the answer is because people (most
importantly, puppet developers) believe that what I''m looking for
(ability to conditionally process puppet logic based on the result of a command
executed on the client) is unwanted by users, well I don''t believe
that''s true.  I definitely want it and it''s clear others do as
well.

Thank you for your time.


      

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

> Anyway, it appears that what I''m looking for may not be possible
today without custom facts.  Ok, fine.
 >My next question is, why?  If it''s because such functionality just
hasn''t been added yet,
 >that''s perfectly reasonable.  I''ll be glad to submit a
more detailed and descriptive feature request.
 >However, if the answer is because people (most importantly, puppet
developers) believe that what I''m looking for
 >(ability to conditionally process puppet logic based on the result of a
command executed on the client) is unwanted by
users,
 >well I don''t believe that''s true.  I definitely want it
and it''s clear others do as well.

I don''t want to get deeply into the middle of this (and so will leave
my contribution to just this e-mail), but there is
a small point I want to make, that I think Peter touched on, but may not have
gotten across.

Puppet manifests are declarative, not executable.

The manifests are not a script which is executed in order, but rather a
declaration of the state in which the client
node should be.  Kind of like the difference between Imperative programming
(C/Ruby) and Logical programming (PROLOG).
So you are looking at it saying "I want to evaluate this condition, then
execute this bit of code only if the condition
is true".  Puppet wants to look at the state of the node, compare/contrast
to the desired state, then "Make It So".   To
do that, you need to know various "Facts" about the node.

And from there, I think the position of the puppet maintainers/developers
follows.  If you want to apply a certain
resource based on whether a file exists, then make a fact about it and let
Puppet do it''s things from there.

It''s a fairly "purist" approach, and I will leave discussions
of the merit of that up to others, but I hope that makes
it a little clearer where they are coming from.

And if I''ve missed the point completely, someone smack me upside the
head and tell me to be quiet :)

Craig Miskell
Puppet Newbie :)



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

> Puppet manifests are declarative, not executable.
This comes up frequently, and seems quite frustrating. People ask
questions, and often are told their questions are wrong, because puppet
is declarative. While it''s sometimes correct, sometimes it''s
wrong. I''m
pretty far from an expert, but I know I''ve had some my posts
incorrectly
branded as such. And a lot of things are easily transformed from one to
the other.

I can''t speak to the original poster''s goal, but actually
implementing
something that lets me declare what the current state is, really does
require testing what the current state is. Which, presumably, is why the
exec type already supports "onlyif" and "unless". Extending
those to
other things doesn''t seem crazy. And as it stands, several things I do
basically come down to syntactic sugar around an exec.

The first example that comes to mind "This machine should have a
database named Foo" "...Oh, but only create it if it doesn''t
already
exist, otherwise you''ll just get spurious errors"

Managing a bunch of modern software seems to boil down to process like
that. 

seph

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi
> Hi Peter, perhaps you started writing your response before reading  
> my entire message.  I suggested a possible solution - behavior  
> similar to the ''onlyif'' option of the exec Type.  Look at
the docs,
> exec only runs the command on the client if the ''onlyif''
command,
> which also runs on the client, returns an exitcode of zero.
>
> http://reductivelabs.com/trac/puppet/wiki/TypeReference#id11
>
> So, obviously some commands can be executed on the client and impact  
> what happens next.  I''m saying it would be nice to apply such
logic
> to a block of code instead of an individual exec.
Functions and Variables are executed/evaluated on the master,  
resources are applied/evaluated on the client. As onlyif is part of a  
resource it''s clear that this command runs on the client, but you  
shouldn''t see it as a command or a function: Your exec example is part
of the exec-resource to evaluates its state and is not actually meant  
as a condition. Your mixings things which don''t belong to each another.

Maybe you have a look at how puppet internally works [1]. The reason  
for this problem is that things get evaluated at two different places,  
which has its reason and is also correct that it works that way.

>> And this makes totally sense due to other reasons.
I should have added an example here. Maybe have a look at the  
ext_lookup function as an example why it makes sense, that functions  
are evaluated on the master.

Besides that, maybe a problem we have in this discussion is that if  
talk about functions we necessary don''t mean always the same?!
>> So if you use the client-server setup you''re restricted to
>> that. The
>> only information the server can get _from_ the client are
>> facts or
>> information from an external source, which the client would
>> have to feed.
>>
>> But if you would stay with local execution only I think
>> you''ll easily
>> able to do what you want.
>
> If it''s so easy, please provide an example solution.  And if your
> example consists of disparate facts to determine if specific files  
> exist, please don''t bother because that''s specifically
what I said I
> wasn''t looking for :-)
simply use puppet as a standalone tool, then your only on one host and  
everything gets evaluated in the same place. The restriction (in your  
terms) that this can only be satisfied using facts is only due to the  
reason that we''re in a client/server relation and not everything gets  
evaluated on the same host.
>> > A wise manager once told me that you should
>> > build your systems around the needs of your business
>> instead of
>> > building your business around the capabilities of your
>> systems.
>>
>> What I could always observe is that people asking for such
>> things are
>> trying to get their used script thinking behaviour (to call
>> it like
>> that) into puppet. But one of the main ideas of puppet is
>> that it
>> changes the way how you look at your infrastructure and how
>> you manage
>> your infrastructure. So actually: Yes, puppet changes the
>> way your doing
>> your business.
>
> What I''m looking for here is nothing extreme.  It''s very
simple.  A
> set of puppet logic that''s only evaluated if a certain condition
on
> the client is met.  What''s wrong with that?  It sounds very  
> reasonable to me.  On the contrary, having the mindset that  
> everything should be written as a custom fact, or extension or  
> whatever, illustrates the point I was trying to make.  Sure it  
> works, but it''s a work-around.  People get used to the extra
effort
> required and consider it old-hat when in actuality (again, IMHO)  
> it''s not ideal and in many scenarios is a serious limitation.
>
> If we use such lines of thinking, then let''s just go ahead and get
> rid of the conditional operators introduced in 0.24.6.  The only  
> test you need is true or false!  Of course I''m kidding here, I
love
> the ability to use more complex expressions.
>
>
> Anyway, it appears that what I''m looking for may not be possible  
> today without custom facts.  Ok, fine.  My next question is, why?   
> If it''s because such functionality just hasn''t been added
yet,
> that''s perfectly reasonable.  I''ll be glad to submit a
more detailed
> and descriptive feature request.  However, if the answer is because  
> people (most importantly, puppet developers) believe that what I''m
> looking for (ability to conditionally process puppet logic based on  
> the result of a command executed on the client) is unwanted by  
> users, well I don''t believe that''s true.  I definitely
want it and
> it''s clear others do as well.
it''s mainly due to the reason how puppet works. the client sends its  
facts to the master, this one evaluates the manifests with this  
information and executes the functions and sends down the compiled  
catalog to the client. This one, only applies the catalog and does the  
necessary changes to fit into the described state. As mentioned above  
to onlyif is just part of an exec resource to determine its state.

There are many more reasons why this is a good architecture and why  
your problem can be still achieved in the puppet way. Which means not  
in a script style, but in a declarative manner, which is what''s the  
basic idea of puppet.

I hope I could explain things more clear. So the question is now how  
would you like to fit your simple idea into this setup and way how  
puppet works?

Besides that I''m not saying that puppet should never do that. But as  
far as I understood the way puppet works, it has its very own reason  
and I also think that it''s a good way how it is currently.

cheers pete

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

> I don''t want to get deeply into the middle of this (and so will  
> leave my contribution to just this e-mail), but there is
> a small point I want to make, that I think Peter touched on, but may  
> not have gotten across.
>
> Puppet manifests are declarative, not executable.
>
> The manifests are not a script which is executed in order, but  
> rather a declaration of the state in which the client
> node should be.  Kind of like the difference between Imperative  
> programming (C/Ruby) and Logical programming (PROLOG).
> So you are looking at it saying "I want to evaluate this condition,  
> then execute this bit of code only if the condition
> is true".  Puppet wants to look at the state of the node,  
> compare/contrast to the desired state, then "Make It So".   To
> do that, you need to know various "Facts" about the node.
I''d like to second that. Thanks for your explanations.

cheers pete

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

> I can''t speak to the original poster''s goal, but actually
implementing
> something that lets me declare what the current state is, really does
> require testing what the current state is. Which, presumably, is why the
> exec type already supports "onlyif" and "unless".
Extending those to
> other things doesn''t seem crazy. And as it stands, several things
I do
> basically come down to syntactic sugar around an exec.
in my opinion it''s far beyond "syntactic sugar around an
exec".

Your right onlyif is part of the way how to evaluate the state of one  
single resource, but a condition in the manifest is a decision whether  
to manage certain resource(s) at all. This is a decision which is done  
by the master, however the state of one single resource is evaluated  
by the client.

cheers pete

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

> > If it''s so easy, please provide an example
> solution.  And if your  
> > example consists of disparate facts to determine if
> specific files  
> > exist, please don''t bother because that''s
specifically
> what I said I  
> > wasn''t looking for :-)
> 
> simply use puppet as a standalone tool, then your only on
> one host and  
> everything gets evaluated in the same place. The
> restriction (in your  
> terms) that this can only be satisfied using facts is only
> due to the  
> reason that we''re in a client/server relation and not
> everything gets  
> evaluated on the same host.
Peter, sorry if it appears that I''m using you as a target, but you just
put a big bullseye on yourself :-)  If I understand correctly, you suggest
running puppet individually on every single host and having the hosts query
themselves, i.e. no central puppetmaster?  So, if I wanted to make a global
change, I''d have to somehow manually distribute new puppet manifests
out to every single host.  That totally defeats what I see as the purpose of
puppet - centralized management of hosts.
 
> it''s mainly due to the reason how puppet works. the client
> sends its  
> facts to the master, this one evaluates the manifests with
> this  
> information and executes the functions and sends down the
> compiled  
> catalog to the client. This one, only applies the catalog
> and does the  
> necessary changes to fit into the described state. As
> mentioned above  
> to onlyif is just part of an exec resource to determine its
> state.
> 
> There are many more reasons why this is a good architecture
> and why  
> your problem can be still achieved in the puppet way. Which
> means not  
> in a script style, but in a declarative manner, which is
> what''s the  
> basic idea of puppet.
> 
> I hope I could explain things more clear. So the question
> is now how  
> would you like to fit your simple idea into this setup and
> way how  
> puppet works?
As I said earlier, if it involves creating a custom fact for every test, then
I''m not interested.  If there''s some other way, then by all
means please share.



Anyway, I was about to go into a long diatrabe of reasons as to why my request
has merit along with numerous examples.  Then I noticed this thread from January
2008:

http://markmail.org/message/2nrbjwjz3vcuiacl

Nigel from Google asked for the same thing I''m asking for, and Luke
agreed it should be made available.   To quote one of Luke''s responses,
"I guess I should actually get this done".  That''s
justification enough for me!  :-)

I''ll file a formal feature request in the ticketing system and look
forward to seeing it in a future release.  Pretty please? :-)


      

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi
>>> If it''s so easy, please provide an example
>> solution.  And if your
>>> example consists of disparate facts to determine if
>> specific files
>>> exist, please don''t bother because that''s
specifically
>> what I said I
>>> wasn''t looking for :-)
>> simply use puppet as a standalone tool, then your only on one host
>> and everything gets evaluated in the same place. The restriction
>> (in your terms) that this can only be satisfied using facts is only
>>  due to the reason that we''re in a client/server relation and
not
>> everything gets evaluated on the same host.
> 
> Peter, sorry if it appears that I''m using you as a target, but you
> just put a big bullseye on yourself :-)  If I understand correctly,
> you suggest running puppet individually on every single host and
> having the hosts query themselves, i.e. no central puppetmaster?  So,
> if I wanted to make a global change, I''d have to somehow manually
> distribute new puppet manifests out to every single host.  That
> totally defeats what I see as the purpose of puppet - centralized
> management of hosts.
I have been simply arguing that you get your current idea (apply a
''local'' onlyif to a whole block) with this kind of setup.
Nothing more.
And I tried to outline why it will only work with the standalone setup
and why not with the client/master setup.
>> it''s mainly due to the reason how puppet works. the client
sends
>> its facts to the master, this one evaluates the manifests with this
>>  information and executes the functions and sends down the compiled
>>  catalog to the client. This one, only applies the catalog and does
>> the necessary changes to fit into the described state. As mentioned
>> above to onlyif is just part of an exec resource to determine its 
>> state.
>> 
>> There are many more reasons why this is a good architecture and why
>>  your problem can be still achieved in the puppet way. Which means
>> not in a script style, but in a declarative manner, which is
what''s
>> the basic idea of puppet.
>> 
>> I hope I could explain things more clear. So the question is now
>> how would you like to fit your simple idea into this setup and way
>> how puppet works?
> 
> As I said earlier, if it involves creating a custom fact for every
> test, then I''m not interested.  If there''s some other
way, then by
> all means please share.
> 
> 
> 
> Anyway, I was about to go into a long diatrabe of reasons as to why
> my request has merit along with numerous examples.  Then I noticed
> this thread from January 2008:
> 
> http://markmail.org/message/2nrbjwjz3vcuiacl
> 
> Nigel from Google asked for the same thing I''m asking for, and
Luke
> agreed it should be made available.   To quote one of Luke''s
> responses, "I guess I should actually get this done". 
That''s
> justification enough for me!  :-)
well imho what is talked about in this thread is an onlyif parameter for
a resource, so unless/onlyif as a metaparameter. Right?

BUT this won''t be something like:

if File.exist?(''/foo/bar'') {
  package{''foobar'': ensure => present }
}

this will be like:

package{''foobar'':
  ensure => installed,
  onlyif => ''test -f /foo/bar'',
}

but your were suggesting something like:

--- quote ---
In pseudo-code:

if file_exists("/opt/orange_app") {
    # file exists, load the module
    include orange
}
--- /quote ---

or as you stated you like to have: "But instead of the
''onlyif'' applying
to a single exec, I''d like it to to apply to an entire block of code in
my puppet manifest."

Which is something FUNDAMENTAL different to the onlyif metaparameter and
which I was trying to argue is evaluated on a different level, hence it
isn''t that easy and won''t work as you think so.

I have never been and I never intended to argue against an onlyif
metaparameter for resources. I simply tried to outline what is the
difference between an onlyif parameter and a statement in the code,
which you prefered over an onlyif parameter. I somehow think I failed
with that.

Besides that, if we are talking about onlyif/unless as a metaparameter:
There have even been recently some work to provide unless as a
metaparameter. See "possible #651 patch" thread on the puppet-dev list
and maybe also have a look at bug #651.
> I''ll file a formal feature request in the ticketing system and
look
> forward to seeing it in a future release.  Pretty please? :-)
if you really need to get things implemented you are currently missing,
you can always get in touch with reductivelabs and I assume they''ll
happily work things out with you.

cheers pete

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

> well imho what is talked about in this thread is an onlyif
> parameter for
> a resource, so unless/onlyif as a metaparameter. Right?
> 
> BUT this won''t be something like:
> 
> if File.exist?(''/foo/bar'') {
>   package{''foobar'': ensure => present }
> }
> 
> this will be like:
> 
> package{''foobar'':
>   ensure => installed,
>   onlyif => ''test -f /foo/bar'',
> }
> 
> but your were suggesting something like:
> 
> --- quote ---
> In pseudo-code:
> 
> if file_exists("/opt/orange_app") {
>     # file exists, load the module
>     include orange
> }
Yes, you''re right, I mistakenly construed that what they were
discussing would directly solve my problem, which it wouldn''t. 
It''s apples and oranges - both fruits I would enjoy but not the same
fruits.
> Besides that, if we are talking about onlyif/unless as a
> metaparameter:
> There have even been recently some work to provide unless
> as a
> metaparameter. See "possible #651 patch" thread on the
> puppet-dev list
> and maybe also have a look at bug #651.
Ok, I''ll check that out.



But now I''m confused again...

You say that this is possible and may even be implemented soon:

package { ''foobar'':
  ensure => installed,
  onlyif => ''test -f /foo/bar'',
}

But something like this is pretty much out-of-the-question?

$foo_exists = client_exec(''test -f /foo/bar'')
if $foo_exists == 0 {
    # file exists, load the module
    include foobar
}

Both scenarios involve a decision based on output from the client.


Perhaps I just need to approach it a different way: create a new type and put
all my custom logic in there?

homemade_application { ''foobar'':
  ensure => installed,
  onlyif => ''test -f /foo/bar'',
}


      

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

John Philips wrote:
> But now I''m confused again...
> 
> You say that this is possible and may even be implemented soon:
> 
> package { ''foobar'':
>   ensure => installed,
>   onlyif => ''test -f /foo/bar'',
> }
> 
> But something like this is pretty much out-of-the-question?
> 
> $foo_exists = client_exec(''test -f /foo/bar'')
> if $foo_exists == 0 {
>     # file exists, load the module
>     include foobar
> }
> 
> Both scenarios involve a decision based on output from the client.
Based on output from client, but in totally different ways. When the 
client requests a configuration, it sends all known facts to the server. 
The server then computes the list of resources (evaluating functions 
like "include") and sends that back to the client. This is a very 
efficient one-roundtrip request to the server.

Having something like your "client_exec" would require many additional
roundtrips from the server to the client. Besides the fundamental 
ugliness of such an approach, in many environments server->client 
connections are forbidden.



If you still, really, really, really want to implement this today, you 
could create an external node classifier[1], which queries the client 
and creates the proper list of classes. It still incurs the overhead and 
the communications issue, but you isolate your complexity in one 
well-defined place.



Regards, DavidS


[1]http://reductivelabs.com/trac/puppet/wiki/ExternalNodes

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

John Philips wrote:
> Peter, sorry if it appears that I''m using you as a target, but
> you just put a big bullseye on yourself :-)  If I understand
> correctly, you suggest running puppet individually on every
> single host and having the hosts query themselves, i.e. no
> central puppetmaster?  So, if I wanted to make a global change,
>  I''d have to somehow manually distribute new puppet manifests
> out to every single host.  That totally defeats what I see as
> the purpose of puppet - centralized management of hosts.
You would need to distribute the manifests to the hosts in some
way, yes, but that *can* be done automatically.  If you have a
shared filesystem (NFS, Lustre, GPFS, ...), you can put your
manifests there.  I do exactly that on two systems where I run
Puppet.  I know some people who run ''git pull'' on the manifest
repository in the cron job that runs puppet.  Or you could use
rsync in your cron job.


         /Bellman

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Thursday 29 October 2009 05:00:34 John Philips wrote:
> Perhaps I just need to approach it a different way: create a new type and
> put all my custom logic in there?
I think this may indeed be the direction you could explore.  The manifests are 
compiled into resources and their parameters on the server and applied on the 
client.  So if how a resource is applied depends on current environment of 
the client it makes sense to have a custom resource type for this resource 
which would then be able to make decisions when applying itself.

-- 
Michael Gliwinski
Henderson Group Information Services
9-11 Hightown Avenue, Newtownabby, BT36 4RT
Phone: 028 9034 3319

**********************************************************************************************
The information in this email is confidential and may be legally privileged.  It
is intended solely for the addressee and access to the email by anyone else is
unauthorised.
If you are not the intended recipient, any disclosure, copying, distribution or
any action taken or omitted to be taken in reliance on it, is prohibited and may
be unlawful.
When addressed to our clients, any opinions or advice contained in this e-mail
are subject to the terms and conditions expressed  in the governing client
engagement leter or contract.
If you have received this email in error please notify
support@henderson-group.com

John Henderson (Holdings) Ltd
Registered office: 9 Hightown Avenue, Mallusk, County Antrim, Northern Ireland,
BT36 4RT.
Registered in Northern Ireland
Registration Number NI010588
Vat No.: 814 6399 12
*********************************************************************************


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

>> Both scenarios involve a decision based on output from the client.
>
> Based on output from client, but in totally different ways. When the
> client requests a configuration, it sends all known facts to the server.
> The server then computes the list of resources (evaluating functions
> like "include") and sends that back to the client. This is a very
> efficient one-roundtrip request to the server.
>
> Having something like your "client_exec" would require many
additional
> roundtrips from the server to the client. Besides the fundamental
> ugliness of such an approach, in many environments server->client
> connections are forbidden.
And to add, as suggested before you might have a look at puppet  
internals [1] which might help you to understand why the  
parameter-onlyif is evaluated on the client and functions as well  
facts etc. are on the server.

cheers pete

[1] http://reductivelabs.com/trac/puppet/wiki/PuppetInternals

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---