Eric & John!
Emacs is the best! Get over it! =)
Anyway,
I do think John is correct, I really was trying to avoid what is clearly
the "Puppet" way of things by treating resources as executable things and
trying to order them as such. I think the idea of organizing the manifest
into classes and applying ordering to those classes (not using --ordering)
might be the way to go.
John, do you think this is actually a bug-worthy event that i'm seeing?
Thanks all!
On Monday, November 24, 2014 7:56:34 AM UTC-7, jcbollinger wrote:
>
>
>
> On Friday, November 21, 2014 4:33:48 PM UTC-6, Eric Sorenson wrote:
>>
>> Hi Kyle --
>>
>> On Friday, November 21, 2014 1:46:19 PM UTC-8, Kyle Purdon wrote:
>>>
>>> TL:DR Using the --ordering = manifest option does not seem to apply to
>>> module commands.
>>>
>>> Using this parameter I would expect puppet to apply my manifest
>>> (site.pp) in the order it is written (script like execution).
>>>
>>
>
> I would advise you to avoid that thought process. Puppet is not a script
> engine, and puppet manifests are not scripts. Wishing that they were, and
> using the --ordering = manifest option to try to make it so, is likely to
> lead to grief (as indeed it seems to have done in this case). I've never
> much seen the point of that option, actually. People who are clueful
> enough to know about it and to know why it might be useful are also clueful
> enough to write their manifests so that they don't rely on it. It is
> better for your manifest set to be self-contained than for its correctness
> to depend on the options with which puppet is run.
>
> Note, too, that the 'ordering' parameter is a *fallback*, not absolute.
> It affects only the relative order of resources whose relative order is not
> otherwise directed.
>
>
>>
>>> It appears to do so for everything except module commands. The following
>>> commands get executed after "all done" even though they are commands in the
>>> middle of the manifest. Both are module commands.
>>>
>>
>
> I see it's going to be some work to break you of script-think. Those are
> *not* commands. Puppet DSL doesn't have any commands. In fact, nothing
> in your manifests is executable in the sense that you are thinking.
>
>
>
>>
>>> rbenv::plugin { "sstephenson/ruby-build": latest => true }
>>> rbenv::build { $EDB_RUBY_VERSION: global => true }
>>>
>>> nsidc_nfs::sharemount { "/disks/backups": project => "backups", options
>>> => "ro" }
>>>
>>>
>>
>
> Those are all resource declarations. Specifically, declarations of
> resources of defined types, whose definitions happen to be in modules.
>
>
>
>> Hmm, I think you need to use the 'contain' function in conjunction with
>> the ordering so that these classes work the way you expect.
>>
>
>
> Nope, because they are not classes. The 'contain' function (and the need
> for it) does not apply to them. Moreover, the manifest provided contains
> only top-level declarations. Containment is only applicable to class
> contexts.
>
> That may, in fact, be the key issue here, because everything else aside, I
> don't see any reason why Puppet should not behave as Kyle expects. It may
> be that the --ordering = manifest option does not work correctly for
> declarations at top scope. I would file a bug report.
>
> The good thing is that there are workarounds available, which generally
> boil down to producing a superior manifest. Recommendations (choose ALL of
> the following):
>
> 1. Don't sweat the relative order in which resources are applied where
> it doesn't actually matter. For example, if neither postgres nor SQLite
> is
> initially installed, it surely doesn't matter which is installed first.
> 2. Where it *does* matter that one resource is managed before another,
> express it in your manifests. That's what the chaining arrows and the
> 'require' family of metaparameters are for. (See the resource
> ordering docs <https://docs.puppetlabs.com/learning/ordering.html>.)
> 3. Organize your code into classes, and keep top-scope declarations to
> a minimum.
>
>
>
>>
>>
>>>
>>> # INSTALL EMACS BECAUSE IT'S THE BEST EDITOR
>>> notify { "installing emacs": }
>>> if str2bool("$INSTALL_EMACS") {
>>> package { ["emacs24"]: ensure => "present" }
>>> }
>>>
>>>
>> Aha, here's your real problem :)
>>
>>
> But I think Eric's onto something there. :)
>
>
> John
>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/076692ef-2d19-4ddc-b896-39d49e7f0845%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
