On 31/01/12 09:01, Felix Frank wrote:
> Ah, so you'd have the agent verify if all assertions (which need to
> appear as first-class citizens in the catalog) hold true, and otherwise
> fail the catalog?
>
> That strikes me as very elegant indeed.
>
> How will situations be handled where assertions
Hi,
On 01/30/2012 10:28 PM, Nick wrote:
> It did sound similar, yes - but unless I misunderstand it, not identical. For
> example, I don't understand how Constraints would avoid the problems with
> unifying resources that Nan mentioned.
as far as I understand, there is no need to merge anything.
On 30/01/12 17:48, Felix Frank wrote:
> Hi,
>
> thanks for your elaborate design sketch.
>
> Sorry for limiting my quote severely.
>
> On 01/30/2012 06:28 PM, Nick wrote:
>> +package { 'libfoo': ensure => present }
>
> Is this different from John's "constraint" proposal?
It did sound similar
Hi,
thanks for your elaborate design sketch.
Sorry for limiting my quote severely.
On 01/30/2012 06:28 PM, Nick wrote:
> +package { 'libfoo': ensure => present }
Is this different from John's "constraint" proposal?
To me this didn't become clear: Does the manifest still need to declare
an ac
On 27/01/12 18:27, jcbollinger wrote:
>> Anyway, I need to get back to work, I'll try to say more in a later email.
>
>
> That would help me to determine what I think about the idea. As it
> is, I suspect I don't quite understand what you are hoping to
> accomplish with it.
Ok, here's a couple
On Sat, Jan 28, 2012 at 10:39 PM, Brian Gupta wrote:
> Nigel,
>
> It frightens me a bit that I think the "correct" solution, will be to
> replicate what the distros are doing in Puppetforge. Basically turning
> puppetforge into a massive cross distro metadata repo, with very strict
> contribution
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It is annoying to have everything in a single place that defines the state of
your nodes but, as you point out, this seems to be the model if you're
using an ENC and that seems to be the recommended practice across the mailing
list for any sort of sc
Had a bunch more thoughts on this topic, and I feel I agree with
Brian: a forge with one module for every purpose, supported maybe by
library modules (like linux) would be the best. It would mean
consolidating the 17 ssh modules that exist now into one all
encompassing ssh module. In the case of SS
Hi,
On 01/28/2012 04:35 PM, Trevor Vaughan wrote:
> Drawbacks:
>
> * Requires the user to have an explicit working knowledge of all
modules and namespaces
> * Adds a lot of random logic to the code (unless it becomes a
metaparam of some sort)
You skipped the most important drawback: Commitment
Nigel,
I just wanted to add, if we do go this route, we should work to support
private "forges" (module repos) as well.
Cheers,
Brian
On Sun, Jan 29, 2012 at 1:39 AM, Brian Gupta wrote:
> Nigel,
>
> It frightens me a bit that I think the "correct" solution, will be to
> replicate what the distr
On Fri, Jan 27, 2012 at 5:20 AM, Felix Frank
wrote:
> Jeff has made a strong point against using virtual resources in modules
> at all, causing me to shift my own views as well.
> If I understand him correctly, one of the chief problems is the high
> probability of accidental collection/realisatio
Nigel,
It frightens me a bit that I think the "correct" solution, will be to
replicate what the distros are doing in Puppetforge. Basically turning
puppetforge into a massive cross distro metadata repo, with very strict
contribution standards and rules. This would involve strong rules for
curated
I just wanted to post to this thread to primarily encourage you all to keep
brainstorming, and to make it clear that I'm paying close attention. :)
--
Nigel Kersten
Product Manager, Puppet Labs
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've been mulling this over and wanted to get opinions on an, ugly, but
completely functional approach.
We've been talking about people supplying metadata to describe inter-class
dependencies (inter-module dependencies really, but hear me out). With
Hi,
On 01/27/2012 04:22 PM, jcbollinger wrote:
> From a usability perspective, I think this is a far better proposal
> than anything else on the table:
I've thought of another plus. Even though the design proposal adds to
the DSL (and complexity is generally to be avoided), it does so in a
manner
Hi,
On 01/27/2012 02:52 PM, Walter Heck wrote:
> There's something else we need to think about here. Some modules have
> a soft/conditional requirement for other modules. What I mean is that
> if you don't use certain parts of a module, you don't need the module
> that that part of the code refers
On 26/01/12 17:48, jcbollinger wrote:
> In particular, it is useful to recognize that dependencies are not just on a
> particular resource generally -- rather, they are on a particular resource
> having certain specific properties.
Yes.
Also: currently in Puppet one cannot say anything about a re
Hello,
On Fri, Jan 27, 2012 at 15:20, Felix Frank
wrote:
> how I see need for
> explicit module dependencies and a system that can automatically
> download required modules from the forge. I can see this supplementing
> your idea of constraints nicely, but without it, downloading modules
> could
Hi John,
thanks for coming up with such elaborate ideas, your input to this group
adds a lot of meat to many discussions.
I can agree with a lot of what you wrote, barring the following remarks:
On 01/26/2012 06:00 PM, jcbollinger wrote:
> Modules provide definitions of resources that they own.
Glad to hear it worked.
On May 24, 2011, at 11:40 PM, treydock wrote:
> I don't have that directory. However I came across this module
> https://github.com/camptocamp/puppet-sudo which among many things
> enlightened me to the new feature in sudo-1.7.2+ of using includedir
> and /etc/sudoers.d t
On May 24, 2011, at 7:58 PM, treydock wrote:
> I have a similar problem I can't seem to solve...here's what I'm
> trying to do.
>
> I have two modules, backuppc_client and sudo. Right now I have a node
> variable that I assign to each node that is used in the sudo module's
> template to add the
21 matches
Mail list logo
