[Puppet Users] Re: Variable scope on sub-defined ressource type
On Tuesday, June 27, 2017 at 3:37:04 PM UTC+2, jcbollinger wrote: > > > > On Monday, June 26, 2017 at 7:57:06 AM UTC-5, Prunk Dump wrote: >> >> Hello puppet Team ! >> >> I have trouble upgrading some code from puppet-3.7 to puppet-4.8. >> >> I have a class, a defined type, and a sub-defined type like this : >> >> > [...] > > > >> So there is two "mainclass::myress" declaration. Each one have a >> different value of $myressvar inside the ressource. And each one declare >> one "mainclass::myress::sub" ressource. In puppet 3.7 everything works just >> like this. And >> >> -> In the "mainclass::myress::sub" déclared by "myressv1" I can access >> the value of the "$myressvar" variable of the "myressv1" ressource just by >> "$myressvar". So using the "$myressvar" variable inside >> "mainclass::myress::sub" I get the value of the parent ressource. >> >> > > That's doubtful. What you describe should not work in Puppet 3.7 at all, > neither with nor without the future parser. I did not even find a bug > report that would explain why it might have seemed to work for you. Puppet > 3.7's scoping rules are documented at > https://docs.puppet.com/puppet/3.7/lang_scope.html. Those docs are > substantially unchanged for all v4 releases so far, and as a matter of > semantic versioning, I expect them to remain substantially unchanged for > all remaining v4 releases. > > Note in particular that > >- "Code inside a class definition or defined type exists in a local >scope." >- "Variables and defaults declared in a local scope are only available >in that scope and its children." >- "Node scope and the local scopes created by defined resources are >anonymous and cannot be directly referenced." >- Although not a direct quote, the parent scope of every defined >type's local scope is *node scope*, regardless of where that instance >is declared. > > I could believe that the behavior you describe was exhibited by Puppet *2*.7, > which had very different scoping rules for variables, but the scope change > was one of the major differences between Puppet 2 and Puppet 3. Not only > should what you describe not work in Puppet 3 (or 4), there is no way at > all in v3 or v4 of the Puppet language to access the local variables of a > defined type instance, though I believe there is a function available from > the stdlib module for accessing their *parameters*. > > All that aside, the easiest solution is probably to give > mainclass::myress::sub a parameter by which the wanted value from a > mainclass::myress instance is provided to it. > Thank you very much jcbollinger ! What you propose worked like a charm ! I don't understand why the code without parameter works on puppet 3.7... maybe a different way to handle the resources default parameters ? In all cases "$mainclass::myress::myressvar" don't works. I seem there is no way in Puppet-4.8 to access the "upper-ressources" variables. Thank again ! Baptiste. -- 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/5d49a1a0-f864-42c6-ab87-beadf8844d53%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Variable scope on sub-defined ressource type
Hello puppet Team !
I have trouble upgrading some code from puppet-3.7 to puppet-4.8.
I have a class, a defined type, and a sub-defined type like this :
define mainclass::myress::sub {
# access to :
# $mainclassvar
# $myressvar
}
define mainclass::myress($arga = $title, $argb) {
#access to $arga, $argb, $mainclassvar
#to compute the value of :
$myressvar =
# and declare a new ressource
mainclass::myress::sub { "$somethingunique":
...
}
class mainclass {
$mainclassvar = "main"
mainclass::myress { 'myressv1':
argb => '1',
}
mainclass::myress { 'myressv2':
argb => '2',
}
}
So there is two "mainclass::myress" declaration. Each one have a different
value of $myressvar inside the ressource. And each one declare one
"mainclass::myress::sub" ressource. In puppet 3.7 everything works just
like this. And
-> In the "mainclass::myress::sub" déclared by "myressv1" I can access the
value of the "$myressvar" variable of the "myressv1" ressource just by
"$myressvar". So using the "$myressvar" variable inside
"mainclass::myress::sub" I get the value of the parent ressource.
In puppet 4.8 this is not allowed so I need to use maybe fully qualified
name. But I don't know the best practice to access the parent ressources
variables and the parent class variables.
I can pass all the variables by parameters. But there is many value to pass
and they are mainly constants. So how can I do ?
In "mainclass::myress::sub" can I access to the main class variables like
this ?
define mainclass::myress::sub {
$mainvar = $mainclass::mainclassvar
}
Or is this preferable to get the variable first in "mainclass::myress" and
after in "mainclass::myress:sub" ?
And how can I access the "$myressvar" value of the parent ressources ? Is
this works ?
define mainclass::myress::sub {
$mainclassvar = $mainclass::mainclassvar
$myressvar = $mainclass::myress::myressvar
}
Is this a good practice ?
If someone can help me.
Thanks !
Baptiste.
--
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/f665082a-3e81-470a-b218-48ff9be94b75%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Declare ressources from another stage
On Wednesday, October 5, 2016 at 4:15:21 PM UTC+2, jcbollinger wrote:
>
>
>
> On Tuesday, October 4, 2016 at 6:55:36 AM UTC-5, Prunk Dump wrote:
>>
>> Hello puppet users !
>>
>> My problem is simple. I use the following classes in three different
>> stages (setup/main/runtime) :
>>
>> class { 'apt::client':
>> stage => 'setup',
>> }
>> ...
>> ...
>> class { 'hostpkg': }
>> ...
>> ...
>> class { 'extrapkg':
>> stage => 'runtime',
>> }
>>
>> The idea is that the "apt::client" class configure the Debian apt tools.
>> Next the "hostpkg" class install and configure the important packages (ex:
>> those needed to allow the connexion of users). And finally the "extrapkg"
>> class install the secondary packages (internet browser etc ...). But
>> sometimes the "hostpkg" or "extrapkg" packages need some extra apt sources,
>> some apt-pinning or the multiarch. So I created three resources/class :
>>
>>
>
> Do take care to distinguish between operational relationships and
> management relationships. Puppet class and resource ordering is about
> satisfying *management* relationships -- that is, situations where Puppet
> can manage resource B only after first ensuring that resource A is in its
> intended target state. Avoid declaring unnecessary relationships, for
> there is no upside at all to having such relationships, and it incurs added
> risk of problems, such dependency cycles. In particular, just because
> package B uses or interacts with package A does not necessarily imply that
> A must be managed before B, or vise versa.
>
> Especially take care with run stages, for they are nothing more than a
> convenient mechanism to apply relationships to many pairs of classes at
> once. Almost inevitably they apply a lot of unneeded relationships, but
> they may nevertheless be the best tool for a select few jobs. Indeed, the
> Puppet docs
> <https://docs.puppet.com/puppet/latest/reference/lang_run_stages.html#limitations-and-known-issues>
>
> say this:
>
> [...] *stages should only be used with the simplest of classes,* and only
>> when absolutely necessary. Mass dependencies like package repositories are
>> effectively the only valid use case.
>>
>
> I'm inclined to suppose that there may be other valid use cases at certain
> sites, and I don't think the docs are saying that stages are always the
> best solution for ensuring that package repositories are managed before all
> packages, but do take the docs' remark in the spirit in which I think it
> was intended: run stages are the wrong tool for almost every job.
>
> In your particular case, it may be that class apt::client is indeed one of
> those rare classes that make sense in a non-default stage, but class
> extrapkg seems very unlikely to be such a class. In the unlikely event
> that you need any puppet-application-ordering relationships between
> resources declared in class extrapkg and (other) classes and resources in
> stage main, I see no barrier to declaring those relationships explicitly.
> Relying on doing so instead of needlessly placing class extrapkg in a
> separate stage may solve some of your problems.
>
>
>
>> define apt::client::pinning( $package = $title, $pin, $priority, $ensure
>> = present)
>> define apt::client::source( $sourcename = $title, $type = 'deb', $uri,
>> $distribution = $apt::client::distribution, $components, $ensure = present)
>> class apt::client::multiarch
>>
>> There three resources are contained in the "apt::client" class as they
>> must be run before "apt-get update" (near "apt::client::end").
>>
>
>
> What resources? I see (definitions of) two resource *types* and one
> class. Class apt::client may declare instances of the two types; those
> *instances* are then contained by the class. It might also declare and
> even also contain (in the relationship sense) class apt::client::multiarch,
> but the declaring and containing are separate considerations. *Under no
> circumstances*, however, should the *definitions* of these types and this
> class be lexically contained within the definition of class apt::client.
> Each definition should appear in its own file.
>
>
>
>> The problem come when a package in "extrapkg" need for example the
>> multiarch :
>>
>> -> From the "extrapkg" class I include the "apt::client::multiarch" class
>> to get the multiarch activated
>>
>
>
> Ok.
>
>
>
[Puppet Users] Declare ressources from another stage
Hello puppet users !
My problem is simple. I use the following classes in three different stages
(setup/main/runtime) :
class { 'apt::client':
stage => 'setup',
}
...
...
class { 'hostpkg': }
...
...
class { 'extrapkg':
stage => 'runtime',
}
The idea is that the "apt::client" class configure the Debian apt tools.
Next the "hostpkg" class install and configure the important packages (ex:
those needed to allow the connexion of users). And finally the "extrapkg"
class install the secondary packages (internet browser etc ...). But
sometimes the "hostpkg" or "extrapkg" packages need some extra apt sources,
some apt-pinning or the multiarch. So I created three resources/class :
define apt::client::pinning( $package = $title, $pin, $priority, $ensure =
present)
define apt::client::source( $sourcename = $title, $type = 'deb', $uri,
$distribution = $apt::client::distribution, $components, $ensure = present)
class apt::client::multiarch
There three resources are contained in the "apt::client" class as they must
be run before "apt-get update" (near "apt::client::end"). The problem come
when a package in "extrapkg" need for example the multiarch :
-> From the "extrapkg" class I include the "apt::client::multiarch" class
to get the multiarch activated
-> As the "extrapkg" class is in the "runtime" stage, the
"apt::client::multiarch" is contained in the stage
-> I get a circular dependency as "apt::client::multiarch" need to be run
before "apt::client::end" and so after the beginning of the runtime stage
as it is included in the "runtime" stage.
How I can declare, inside a stage, a resource or a class that must not be
contained in the stage. It is just "required" and must be run inside it's
corresponding stage.
If anyone can help !
Baptiste.
--
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/86c3ec6e-2c4a-46ac-a348-4cadf332847a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
