Jira (PUP-1125) Exec checks should be turned into metaparameters
Title: Message Title Moses Mendoza updated an issue Puppet / PUP-1125 Exec checks should be turned into metaparameters Change By: Moses Mendoza Labels: redmine triaged Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-1125) Exec checks should be turned into metaparameters
Title: Message Title Maggie Dreyer updated an issue Puppet / PUP-1125 Exec checks should be turned into metaparameters Change By: Maggie Dreyer Labels: redmine triaged Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-1125) Exec checks should be turned into metaparameters
Title: Message Title Rob Reynolds updated an issue Puppet / PUP-1125 Exec checks should be turned into metaparameters Change By: Rob Reynolds Team: Agent & Platform Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-1125) Exec checks should be turned into metaparameters
Title: Message Title Henrik Lindberg commented on PUP-1125 Re: Exec checks should be turned into metaparameters I think that puppet needs to be able to manage f(s(r)) rather than just s(r) - that is, a function of resource r's state as opposed to just its state. The way to do that now is to compute f(s(r)) as a fact (symbolically defining which state out of a set of possible states for r to use) and sending it to the compiler. The compiler then produces s(r). It would probably be much better if the agent could pick the state s(r) out of multiple s'(r), s''(r) etc. It would also mean that it would potentially be possible to model transitions from one s(r) to s'(r) in one and the same catalog run. (I say probably be better, as it could bloat the catalog with potentially a very large set of alternative states for r that would not be used (even entire trees of states for dependent resources of r) - as opposed to producing a catalog "pruned" from such alternative states via a conditional in the compilation). I am not very much in favor of shoehorning in conditionals as meta parameters... Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-1125) Exec checks should be turned into metaparameters
Title: Message Title Felix Frank commented on PUP-1125 Re: Exec checks should be turned into metaparameters Hi Steve Potter, late reply, I missed your post. Frankly, I don't believe that your use cases necessarily call for these metaparameters. 1) The list of DBvols per server should be part of their Hiera data. Puppet should be your authority for such things. Failing that, this example would warrant a custom fact, I believe. 2) In and of itself, it's tempting to force Puppet to not touch the user once it has been created. Please note the following factors, however: 1. There is a module to manage things only one: https://forge.puppet.com/binford2k/manageonce 2. If you use only_if or manageonce::, all other properties of your user resources will fall out of management as well. This can be undesirable. Granted, the final point is tricky. Off the top of my head, I cannot think of a way to work around it cleanly without falling back to yet another custom fact. Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-1125) Exec checks should be turned into metaparameters
Title: Message Title
Steve Potter commented on PUP-1125
Re: Exec checks should be turned into metaparameters
It doesn't seem like this has request has had any action in a long time. I would like to propose a few other examples that I've run across that would be useful to have onlyif/unless act like metaparameters.
1) I have modules that set up and manage the underlying infrastructure of applications, but not the entirety of their data and usage. For example, databases, and database filesystems. In our environment, we create /d## filesystems and as the databases grow, we add additional filesystems. Because of this, on any individual server, I could have /d01 by itself, /d01 - /d03, /d01 - /d05, or even /d01 - /d99. I would like to have my basic database manifest have
$dbvols = [ "/d01", "/d02", "/d03" , "/d99"] file { $dbvols: owner => 'oracle', group => 'oinstall', mode => '0750', _onlyif_ => exists # for example, not sure how exactly syntax would work }
so that permissions are always correct if the filesystem exists, but it doesn't create a whole bunch of empty directories if they don't already exist.
2) In a similar vein, we create certain local service accounts with default passwords, but the service owners change those passwords once we turn the servers over to them (we have multiple teams that use the same service account name but don't actually manage other servers). It would be useful to be able to do something like:
user { 'oracle': password => , unless => exists }
to create the account and set a default password, but not to change it if the account already exists and has a different password.
Add Comment
This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+u
Jira (PUP-1125) Exec checks should be turned into metaparameters
Title: Message Title
John Bollinger commented on an issue
Re: Exec checks should be turned into metaparameters
Felix Frank wrote:
My reasoning was that a Fact bases solution will likely remove resources conditionally
if $::my_custom_fact { package { "foo": } }
so that such resources cannot be safely required by others. If I understand you correctly, your point is that the require value can depend on the fact value as well. That is true, albeit unwieldy.
My point is twofold:
yes, the require value and/or the entire dependent resource can be guarded by the fact as well, but also
in cases where there are dependencies to worry about, they usually need to be guarded that way.
Consider, for example, a standard package / configuration / service module, where the user wants to accommodate an alternative service instead of the standard one (maybe apache on one hand and nginx on the other). You need to either enable or disable the whole chain together – if nginx is already installed, say, it is not sufficient to avoid managing only Package['httpd'].
On the other hand, if you have a dependency between two resources where the second can tolerate the first being unsynced, then that dependency is either inaccurately modeled or unneeded altogether. The "innaccurately modeled" end is one place defined alternatives could help, for without something like them, some of those cases simply cannot be modeled well.
From a design perspective, it would be consistent to make it possible for the user to require such "conditional" resources and sync the dependent resources even if the condition of the dependency are not met.
Yes, there is room for users to shoot themselves in the foot.
So I do see potential in such a dangerous feature, at least as a design study. Of course, if we add this at any point in time, getting rid of it again would be quite painful (a Puppet 5 kind of retraction).
You are right: it could be implemented that way, and careful puppeteers could put it to use without shooting themselves in the foot much. It might be an interesting experiment if it could be done in a provisional way, maybe like the future parser has been.
Nevertheless, there are alternative ways to approach the issues that would channel users in more effective directions, that would avoid opening new avenues for module incompatibility, and that would put lower demands on support channels, at least in the long run. But maybe I'm peddling betamaxes.
So a much less dangerous compromise could be to forego the onlyif/unless equivalents for now and on
Jira (PUP-1125) Exec checks should be turned into metaparameters
Title: Message Title
Felix Frank commented on an issue
Re: Exec checks should be turned into metaparameters
Puppet 4 sounds reasonable, although it would likely be a non-breaking change, so no sweat. Before the guys chime in, I'd like to respond once more.
John Bollinger, I'm coming around to your view, I guess, but I'd still like to argue some particulars.
Another workaround are Facts, which may not scale to the number of required checks a fact based solution also makes it more difficult to handle dependent resources
Where does that last come from? Surely a fact-based solution makes it easier to deal with dependent resources, because the result of evaluating the condition is embodied in a fact, and can therefore influence multiple resource declarations.
My reasoning was that a Fact bases solution will likely remove resources conditionally
if $::my_custom_fact { package { "foo": } }
so that such resources cannot be safely required by others. If I understand you correctly, your point is that the require value can depend on the fact value as well. That is true, albeit unwieldy.
Because right now it is safe to assume that given a
{ 'foo': require => B['bar'] }
A['foo'] will be applied only if all of B['bar']'s properties are in sync. Implementing option 1 would render that assumption unsafe, and that could lead to a world of pain.
I'm torn on this point - if I add an onlyif equivalent to B[bar], I'm setting myself up for this kind of breakage. Or to put it differently, I apparently only care for the resource's properties under certain conditions.
From a design perspective, it would be consistent to make it possible for the user to require such "conditional" resources and sync the dependent resources even if the condition of the dependency are not met.
Yes, there is room for users to shoot themselves in the foot.
So I do see potential in such a dangerous feature, at least as a design study. Of course, if we add this at any point in time, getting rid of it again would be quite painful (a Puppet 5 kind of retraction).
So a much less dangerous compromise could be to forego the onlyif/unless equivalents for now and only go for a precondition style metaparameter to let resources fail in scriptable circumstances. If I read John's comments correctly, that is what you would prefer as well.
Jira (PUP-1125) Exec checks should be turned into metaparameters
Title: Message Title Kylo Ginsberg commented on an issue Re: Exec checks should be turned into metaparameters Eric Sorenson and/or Charlie Sharpsteen, I believe you two identified this ticket as a 4.0 candidate. Any comments or recommendations on the proposals we're kicking around in this comment thread? Add Comment Puppet / PUP-1125 Exec checks should be turned into metaparameters The 'checks' in Exec -- refreshonly, onlyif and unless -- should be changed into metaparameters, so they're available for all resource types. My guess is that this will require defining a new type of metaparameter, in the same way that the Exec checks are a slightly different type of parameter. This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-1125) Exec checks should be turned into metaparameters
Title: Message Title John Bollinger commented on an issue Re: Exec checks should be turned into metaparameters If at all, it would likely be most acceptable to have the metaparameters behave just like the exec parameters "Acceptable" is an odd choice of words there. So far only one person in this conversation could be construed as finding any of the proposed alternatives unacceptable. And that person thinks mimicing the behavior of Exec's parameters is far and away the worst of the three alternatives. Some of the other comments vaguely in that direction seem premised on the idea that the proposed new metaparameters would be named the same as the Exec parameters, but the names should follow from the chosen behavior, not the other way around. That behavior can be approximated by chaining an actual exec before the resource in question note that in contrast to exec, there would be an error message for a resource that is short-circuited in this fashion there are also implications for dependent resources, because the resource in question effectively fails - from this point of view, the workaround is quite dissimilar from the exec parameter's behavior after all Yes, and that's as it should be, whether the behavior is provided by chaining an Exec or by the proposed metaparameters. A resource must fail if its declared properties are not in sync after Puppet processes it – that's practically a definition of resource failure. On the other hand, it is a viable question whether such failures should be quiet or noisy. Another workaround are Facts, which may not scale to the number of required checks a fact based solution also makes it more difficult to handle dependent resources Where does that last come from? Surely a fact-based solution makes it easier to deal with dependent resources, because the result of evaluating the condition is embodied in a fact, and can therefore influence multiple resource declarations. That goes double if one supposes that the model of Exec.onlyif will be the one chosen for this feature, for that would make it impossible ever to be confident that any given resource was in sync, at least in the sense that we use that term now, anywhere outside that resource instance's provider. All things considered, I believe that we did find possible use cases for the metaparameters. Workarounds exist, but are rather clunky. Also, I don't believe that "a workaround exists" is an adequate reason to deny the implementation of a feature (see nagios config permissions for an example of us walking into that trap before). It was never in doubt that there were use cases; the feature would not have been requested otherwise. The main reason for considering use cases is to evaluate how best to serve those cases. I agree that "a workaround exists" is not an adequate reason to deny implementation, but "Puppet can do that already" is an excellent reason. There is no bright line separating those. Also, there are a host other conceivable reasons for denying implementation in general – just because it can be implemented and some p
Jira (PUP-1125) Exec checks should be turned into metaparameters
Title: Message Title Felix Frank commented on an issue Re: Exec checks should be turned into metaparameters Let's see if I can summarize the discussion so far. If at all, it would likely be most acceptable to have the metaparameters behave just like the exec parameters That behavior can be approximated by chaining an actual exec before the resource in question note that in contrast to exec, there would be an error message for a resource that is short-circuited in this fashion there are also implications for dependent resources, because the resource in question effectively fails - from this point of view, the workaround is quite dissimilar from the exec parameter's behavior after all Another workaround are Facts, which may not scale to the number of required checks a fact based solution also makes it more difficult to handle dependent resources All things considered, I believe that we did find possible use cases for the metaparameters. Workarounds exist, but are rather clunky. Also, I don't believe that "a workaround exists" is an adequate reason to deny the implementation of a feature (see nagios config permissions for an example of us walking into that trap before). John's idea for disjunctive defined types is interesting, but I feel that it is hard to grasp - adding complexity where we're currently trying to make things more simple for the user, if possible. To make some progress, I suggest I try and go forward with what I dubbed "option 1" in the beginning. Make resources appear as synced under circumstances described by commands passed as metaparameters. For dependency resolution, such resources behave as true constants, seeing as they are in sync for all intents and purposes. I realize that this hardly embodies a consensus decision, but I think it's the least painful way forward and doesn't break anyone's assumptions. If this is not the case after all, please veto below Concerning implementation, I seem to remember that Josh Cooper would see this done at the resource_harness level. Sounds legit to me.
Jira (PUP-1125) Exec checks should be turned into metaparameters
Title: Message Title John Bollinger commented on an issue Re: Exec checks should be turned into metaparameters Is a custom fact (or even easier, an external fact) that much harder? And wouldn't an external fact allow for a more DRY approach, e.g. if the same conditional logic was needed in more than one place? I'm not trolling; I think I may be missing some pain point. Indeed, now that external facts are synchronized via plugin-sync, they provide an excellent alternative, almost as easy to create, and more general. And if so, that makes me wonder if we should work on alleviating that pain point, rather than working around it by adding metaparameters. The only functional aspect of any of this that cannot be addressed by facts is one that has not yet been raised: evaluating conditions at the time of the catalog run, in conjunction with syncing a specific resource, rather than beforehand. Beyond that it's on one hand a question of syntax, and on the other a question of the nature of the abstractions Puppet works with. Add Comment Puppet / PUP-1125 Exec checks should be turned into metaparameters The 'checks' in Exec -- refreshonly, onlyif and unless -- should be changed into metaparameters, so they're available for all resource types. My guess is that this will require defining a new type of metaparameter, in the same way that the Exec checks are a slightly different type of parameter.
Jira (PUP-1125) Exec checks should be turned into metaparameters
Title: Message Title Geoffrey Hicks commented on an issue Re: Exec checks should be turned into metaparameters Is a custom fact (or even easier, an external fact) that much harder? And wouldn't an external fact allow for a more DRY approach, e.g. if the same conditional logic was needed in more than one place? I'm not trolling; I think I may be missing some pain point. And if so, that makes me wonder if we should work on alleviating that pain point, rather than working around it by adding metaparameters. The specific example that I'm working on currently is an "application server" profile that will set up an arbitrary number of node.js apps, each one being executed and handled by pm2. I have a defined-type to represent these apps - it takes in things like environment variables, the main script filename, command line parameters, etc., and writes them out to two config files; then it attempts to start the main script using a pm2 command. Within this defined type, it would be extremely easy to add an "onlyif" to each of those two file declarations in the defined-type, so that they're only written if the main script file is found in the directory. I'm basically doing the same thing with the pm2 start command, since that's an exec. Two quick lines of code added, and the problem is gone for all current and future node apps. I haven't done much with custom facts, but it's my impression that to use them I would need to create a different custom fact for each application that is deployed this way, checking its specific directory to see if that app has been deployed yet. For any future apps, a new custom fact would need to be added - something that our Ops group would probably have to do (or teach), since most of the developers don't work directly with Puppet or Ruby. That makes the solution much less self-service - as it is right now, a developer just needs to put their app's name and arguments into Hiera, and Puppet takes care of all the infrastructure needed for deployment. Maybe this is too obscure a case to justify adding metaparameters for. But it seems like similar situations could apply for almost any defined-type that has this problem; the defined type may be used in a hundred different locations that would each require their own custom fact, when instead you could just bake the check into the defined-type itself and handle the problem for all uses. Add Comment
Jira (PUP-1125) Exec checks should be turned into metaparameters
Title: Message Title
John Bollinger commented on an issue
Re: Exec checks should be turned into metaparameters
You cannot get an analog of Felix's option (1) by chaining in in Exec, however, nor in general can you implement groups of alternative resources, such as we discussed earlier, where one resource being in sync is sufficient for the whole group to be synchronized. For such purposes, I find myself imagining a variation on defined types. Consider this syntax:
define package_a_or_b disjunctive () {
package { 'A': ensure => 'latest' }
->
package { 'B': ensure => 'present', noop => true }
}
...
package_a_or_b { 'A unless B': }
An ordinary defined type attempts to ensure that all resources declared within are synchronized, and succeeds if that is achieved. The obscurely-named 'disjunctive' keyword would indicate a different behavior, wherein the define succeeds if any one or more of the resources declared within is or can be synchronized, and it only attempts to sync any resource if none of them are yet synchronized.
In the example code, an instance of the disjunctive 'package_a_or_b' type is in sync if Package['B'] is present on the system, or if Package['A'] is present and at the latest version. If neither, then Puppet will attempt to ensure the latest version of A installed, but in no case will it install or update Package['B'], because that package is declared with noop => true.
Although that would introduce a new keyword, it would be backwards compatible with the current DSL because nothing is currently allowed between defined name and parentheses / body. Disjunctive types would have the nice property that the resources within succeed or fail as a group, with all the attending benefits for declaring relationships, while still relying on Puppet resources as their building blocks, with all the benefits attending that. And judicious use of Exec resources within such a construct could yield everything that 'onlyif' and 'unless' metaparameters might do, and then some.
Add Comment
Puppet / PUP-1125
Jira (PUP-1125) Exec checks should be turned into metaparameters
Title: Message Title Kylo Ginsberg commented on an issue Re: Exec checks should be turned into metaparameters You could probably distill this down to a more general case: resources whose ordering depends on another resource that isn't managed in Puppet. Yes, that seems like the primary abstraction that's being requested. Although Frederik Wagner's "package A unless package B" example earlier on suggests two resource manageable by puppet, so it did make me wonder if there was also a request for conditional relationships between two managed (or noop'd) puppet resources? I'm not quite sure how that would work though It'd be nice to have an easy way to tell Puppet to check whether some outside task has been completed before applying certain parts of the manifest, without having to write a custom fact for every time that this shows up. Is a custom fact (or even easier, an external fact) that much harder? And wouldn't an external fact allow for a more DRY approach, e.g. if the same conditional logic was needed in more than one place? I'm not trolling; I think I may be missing some pain point. And if so, that makes me wonder if we should work on alleviating that pain point, rather than working around it by adding metaparameters. Add Comment Puppet / PUP-1125 Exec checks should be turned into metaparameters The 'checks' in Exec -- refreshonly, onlyif and unless -- should be changed into metaparameters, so they're available for all resource types. My guess is that this will require defining a new type of metaparameter, in the same way that the Exec checks are a slightly different type of parameter.
Jira (PUP-1125) Exec checks should be turned into metaparameters
Title: Message Title
John Bollinger commented on an issue
Re: Exec checks should be turned into metaparameters
If we had "onlyif" available for the file resource type, we could easily tell Puppet that we want the config files to be written only if the main application executable exists. That way, the directory stays empty if the repository hasn't been cloned into it yet; but if the application is there, Puppet will write its config files on the next run.
Ok.
This discussion has lead me to realize that Puppet already has a pretty good approximation of 'onlyif' for all resource types, with this syntax:
exec { '': }
->
type { '': }
That yields roughly Felix's behavior (3) because syncing the Exec will fail if the onlyif command does not return a success result, preventing Puppet from attempting to sync the other resource.
Alternatively, if you prefer something similar to Felix's behavior (2), then I think you can use this variation:
exec { '/bin/true': _onlyif_ => '', noop => true }
->
type { '': }
In that case, Puppet will detect the Exec as out of sync if the onlyif command succeeds, but it will not attempt to sync it because it is marked noop. Because the Exec is not synchronized, Puppet will not (should not) attempt to sync the other resource.
Would one of those serve your requirement adequately?
Add Comment
Puppet / PUP-1125
Exec checks should be turned into metaparameters
Jira (PUP-1125) Exec checks should be turned into metaparameters
Title: Message Title Geoffrey Hicks commented on an issue Re: Exec checks should be turned into metaparameters I have an additional use case that I'd like to submit for this. It may not be a very "good" use of Puppet, and I may be going against Puppet's whole configuration management philosophy by doing it this way, but it's the reality I'm faced with for the time being. Right now, we're using git clone as an ad-hoc way of deploying code to many of our boxes. We intend to move away from it in favor of packages eventually, but even after that we'll probably want to use git for convenience on developer boxes. Certain configuration files for these git-deployed apps are handled by Puppet, as their contents may vary based on what environment the box is in - for example we may want to use Facter to determine whether a box is in the Development environment, and set the log level to DEBUG if that's the case. Or we might want to turn on certain low-resource modes in Development but be greedy about resources on a dedicated Production box. The problem we're running into is that git doesn't allow you to clone into a directory that already has files in it - you either have to do a wonky work-around with git init, or you have to store the config files in a different directory. If we had "onlyif" available for the file resource type, we could easily tell Puppet that we want the config files to be written only if the main application executable exists. That way, the directory stays empty if the repository hasn't been cloned into it yet; but if the application is there, Puppet will write its config files on the next run. You could probably distill this down to a more general case: resources whose ordering depends on another resource that isn't managed in Puppet. The ideal, of course, is to put everything into your configuration management tool, but there will always be cases where that isn't feasible for reasons that aren't in the puppetmaster's control (other development teams, for example). It'd be nice to have an easy way to tell Puppet to check whether some outside task has been completed before applying certain parts of the manifest, without having to write a custom fact for every time that this shows up. Add Comment Puppet / PUP-1125
Jira (PUP-1125) Exec checks should be turned into metaparameters
Title: Message Title John Bollinger commented on an issue Re: Exec checks should be turned into metaparameters Arguments beginning with a definition of what puppet is are not very constructive. Not only does that target move, but your operational model is not mine (hint: it only exists in your mind). Asserting some local notion of forward-looking purity of that vision just asks that we worship your ideal. Unless you have commit rights or otherwise speak for PL as a whole, I'm not on for that ride. Realize that this tool's workplace is often nasty, fiddly, and loaded with inconsistency (you know, like the whole rest of this world). That is nothing new. You won't have a sparkling clean feature set free from ugly beasts and burdens foisted from deep down in POSIX, et al. Theoretical correctness is a luxury and only maybe warrants a mention in passing, just as a reminder. Maybe we can get back to the question at hand now? It depends – are you feeling better now? If indeed the question that you want to discuss is the subject of this feature request, then one constructive way to proceed would be to give examples of how you could use the feature to make life better for you. Some of us call those "use cases". They will help those who ultimately will decide the matter to determine whether to indeed implement the requested feature, or an alternative, or nothing at all, and if a new feature is implemented then the use cases will help guide its design. (my 2 cents...) Felix Frank outlined the three needs well enough to proceed. But the change is maybe large, so I can only echo the suggestion to have it work just as the exec metaparam. On the contrary, Felix outlined three mutually exclusive implementation alternatives, to which some of this discussion has been directed. It remains an open question which would be best, but it is by no means clear that the requested feature would be the best way to serve the perceived need in the first place (since the nature of the need itself is not clear). That is the threshold question, and I will not allow it to be swept under the rug if I can help it. Add Comment Puppet / PUP-1125
Jira (PUP-1125) Exec checks should be turned into metaparameters
Title: Message Title Colin Hudler commented on an issue Re: Exec checks should be turned into metaparameters Arguments beginning with a definition of what puppet is are not very constructive. Not only does that target move, but your operational model is not mine (hint: it only exists in your mind). Asserting some local notion of forward-looking purity of that vision just asks that we worship your ideal. Unless you have commit rights or otherwise speak for PL as a whole, I'm not on for that ride. Realize that this tool's workplace is often nasty, fiddly, and loaded with inconsistency (you know, like the whole rest of this world). That is nothing new. You won't have a sparkling clean feature set free from ugly beasts and burdens foisted from deep down in POSIX, et al. Theoretical correctness is a luxury and only maybe warrants a mention in passing, just as a reminder. Maybe we can get back to the question at hand now? (my 2 cents...) Felix Frank outlined the three needs well enough to proceed. But the change is maybe large, so I can only echo the suggestion to have it work just as the exec metaparam. Obviously you can save us a lot of time by closing the conversation when it is known to violate some community and/or constitutional principle which would outweigh those "particular circumstances" with which we devote so much of our time. Add Comment Puppet / PUP-1125 Exec checks should be turned into metaparameters The 'checks' in Exec -- refreshonly, onlyif and unless -- should be changed into metaparameters, so they're available for all resource types. My guess is that this will require defining a new type of metaparameter, in the same way that the Exec checks are a slightly different type of parameter.
Jira (PUP-1125) Exec checks should be turned into metaparameters
Title: Message Title John Bollinger commented on an issue Re: Exec checks should be turned into metaparameters Yes, the current canonical way to solve the described use case are facts. That can become unwieldy if it affects lots of resources, though. (Facter 2 and structured data may mitigate this somewhat). A site with many such resources therein has bigger problems with its approach. I am not averse to Puppet implicitly channeling people toward practices that will ultimately be more effective for them. On the other hand, the feature would merely introduce yet another means of controlling when a resource is viable for management. Other such means currently include schedules and the noop metaparameter. Perhaps so, and on that basis I could perhaps accept the feature without too much complaint. But I don't think it adequately addresses the alternative package use case. Problems arise when other resources need to depend on one or both of the alternatives, for surely if Package A is not in sync and is prevented from being synchronized by a noop_if parameter, then resources that depend on it must not be synchronized either. What's really wanted for this case is a higher-level abstraction over the pair of packages as alternatives for each other. That would be a lot clearer, and, where appropriate, relationships could then be directed at the pair instead of at one or the other. In some specific Package cases, that can now be done with the new support for virtual packages. For other cases, I think I would be a lot happier with a generic way to express such alternative groups in the DSL than with a way to cobble them together implicitly at catalog application time. Add Comment Puppet / PUP-1125 Exec checks should be turned into metaparameters
Jira (PUP-1125) Exec checks should be turned into metaparameters
Title: Message Title Felix Frank commented on an issue Re: Exec checks should be turned into metaparameters I concur that the feature will not cater to the Puppet model in a strictly constructive fashion. Yes, the current canonical way to solve the described use case are facts. That can become unwieldy if it affects lots of resources, though. (Facter 2 and structured data may mitigate this somewhat). On the other hand, the feature would merely introduce yet another means of controlling when a resource is viable for management. Other such means currently include schedules and the noop metaparameter. From a design perspective, it may at least be interesting to explore the new alleys that such an addition would open up. Good point about possible confusion if the parameters would behave differently than those for exec. Of course, we need not make those parameters into the metaparameters, but invent new ones such as sync_if and ignore_if (if that's the semantics we go for). Add Comment Puppet / PUP-1125 Exec checks should be turned into metaparameters The 'checks' in Exec -- refreshonly, onlyif and unless -- should be changed into metaparameters, so they're available for all resource types. My guess is that this will require defining a new type of metaparameter, in the same way that the Exec checks are a slightly different type of parameter. This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)
Jira (PUP-1125) Exec checks should be turned into metaparameters
Title: Message Title John Bollinger commented on an issue Re: Exec checks should be turned into metaparameters A usecase which I hit multiple times is be for the package type: Install Package A only if Package B ist not installed The Puppet operational model is Puppet evaluates the current state of the machine, it uses that and other information to construct a catalog describing the desired target state, and then it attempts to put the machine into the chosen state. If, as in the case presented, the desired target state depends on whether a given package is installed, then the model demands that that information should be fed in up front (via a custom fact). Often an even better solution is to put the uncertain piece of state – e.g. whether Package B is installed – under management. That is, the best policy with Puppet is frequently "tell; don't ask." Particular circumstances may admit other alternatives. Add Comment Puppet / PUP-1125 Exec checks should be turned into metaparameters The 'checks' in Exec -- refreshonly, onlyif and unless -- should be changed into metaparameters, so they're available for all resource types. My guess is that this will require defining a new type of metaparameter, in the same way that the Exec checks are a slightly
Jira (PUP-1125) Exec checks should be turned into metaparameters
Title: Message Title Frederik Wagner commented on an issue Re: Exec checks should be turned into metaparameters A usecase which I hit multiple times is be for the package type: Install Package A only if Package B ist not installed @John: I agree it's more an imparitive/scriptlike way of using puppet here. Anyway a common usecase (in particular for installation of badly packaged 3rd party vendor software). For now this is easily solved by an exec statement, but then the advantages of the usage of the existing types are lost. Add Comment Puppet / PUP-1125 Exec checks should be turned into metaparameters The 'checks' in Exec -- refreshonly, onlyif and unless -- should be changed into metaparameters, so they're available for all resource types. My guess is that this will require defining a new type of metaparameter, in the same way that the Exec checks are a slightly different type of parameter. This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it
Jira (PUP-1125) Exec checks should be turned into metaparameters
Title: Message Title John Bollinger commented on an issue Re: Exec checks should be turned into metaparameters I know this feature has been requested multiple times, but I am deeply skeptical of it. The 'onlyif' and 'unless' parameters make sense for Exec because, along with 'creates', they provide the basis for determining whether the resource is in sync. There is no other basis for making such a determination, since Execs have only parameters, and no properties. It all hangs together in that case, with Exec representing ad hoc resources built directly out of commands. For other resource types, the general premise that resources are in sync when and only when all their properties are in sync is deeply ingrained in users, modules, docs, and the code itself. Modifying that pillar of Puppetdom cannot help but be disruptive, and certainly cannot be considered "uncontroversial". Furthermore, as I am inclined to say from time to time on the user list, "Puppet is not a script engine." That is not a limitation, it is a strength! I urge you to not slip in (more) scripting through the back door. Useful new features are great, but not when they weaken what Puppet already offers. Promoting 'onlyif' and 'unless' to metaparameters might be less disruptive if instead of the behavior they now have on Execs (for in-syncedness evaluation), they instead set conditions under which resource synchronization would fail. E.g. if an 'onlyif' command were declared, and it failed when executed during the catalog run, then the resource would fail. But then either many erstwhile perfectly good Execs would be broken, or else there would be a confusing difference in behavior between Execs and other resource types. I think it would be wise to collect some proposed use cases for the feature (any implementation flavor) to evaluate how those might best be served. I'm inclined to think that where Puppet's existing facilities are insufficient for those, there will be better directions to go than endowing more resource types with 'onlyif' and 'unless'. Add Comment Puppet / PUP-1125 Exec checks should be turned into metaparameters
Jira (PUP-1125) Exec checks should be turned into metaparameters
Title: Message Title Deepak Giridharagopal commented on an issue Re: Exec checks should be turned into metaparameters Kylo Ginsberg Why wouldn't we just mimic the behavior of those metaparams when used with exec? People are already used to that, and it seems like it would be an uncontroversial place to start. Add Comment Puppet / PUP-1125 Exec checks should be turned into metaparameters The 'checks' in Exec -- refreshonly, onlyif and unless -- should be changed into metaparameters, so they're available for all resource types. My guess is that this will require defining a new type of metaparameter, in the same way that the Exec checks are a slightly different type of parameter. This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-1125) Exec checks should be turned into metaparameters
Title: Message Title Felix Frank commented on an issue Re: Exec checks should be turned into metaparameters Oh good point - I actually see three models then treat the resource as in_sync - it will not stand out in logs or reports if it is out of sync make the behave as if noop => true was specified, making it carp in reports if out of sync make the resource fail Looking at Redmine 651, I found this link: https://groups.google.com/forum/#!topic/puppet-users/iAGZ3GKS-N0 Turns out that discussion was joined by your's truly with a rather uninspired remark. (Hindsight can be a harsh mistress.) From today's point of view, I'd definitely try and solve that with a custom fact and keep the dependent resources (in this case, ssh_authorized_keys) out of the catalog. Many such cases can likely be approached that way. Add Comment Puppet / PUP-1125 Exec checks should be turned into metaparameters The 'checks' in Exec -- refreshonly, onlyif and unless -- should be changed into metaparameters, so they're available for all resource types. My guess is that this will require defining a new type of metaparameter, in the same way that the Exec checks are a slightly different type of parameter.
Jira (PUP-1125) Exec checks should be turned into metaparameters
Title: Message Title Kylo Ginsberg commented on an issue Re: Exec checks should be turned into metaparameters For anyone watching this ticket: can you provide some use cases for unless or onlyif as metaparameters? I ask because we just had a good chat about this at PR triage and it seemed like there might be scenarios where we'd want to treat, say, a failed onlyif as meaning the resource is in-sync and just a no-op, and other scenarios where a failed onlyif would mean the resource couldn't be sync'ed. Adding client-side conditionals is a pretty consequential change for puppet, so we'd want to make sure the use cases are well-understood. Add Comment Puppet / PUP-1125 Exec checks should be turned into metaparameters The 'checks' in Exec -- refreshonly, onlyif and unless -- should be changed into metaparameters, so they're available for all resource types. My guess is that this will require defining a new type of metaparameter, in the same way that the Exec checks are a slightly different type of parameter. This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede) --
Jira (PUP-1125) Exec checks should be turned into metaparameters
Title: Message Title Felix Frank assigned an issue to Felix Frank Puppet / PUP-1125 Exec checks should be turned into metaparameters Change By: Felix Frank Assignee: Felix Frank Add Comment This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-1125) Exec checks should be turned into metaparameters
Title: Message Title Charlie Sharpsteen updated an issue Puppet / PUP-1125 Exec checks should be turned into metaparameters Change By: Charlie Sharpsteen Component/s: Catalog Application Add Comment This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-1125) Exec checks should be turned into metaparameters
Title: Message Title redmine.exporter created an issue Puppet / PUP-1125 Exec checks should be turned into metaparameters Issue Type: New Feature Assignee: Unassigned Created: 17/Dec/13 2:41 AM Labels: redmine Priority: Normal Reporter: redmine.exporter The 'checks' in Exec refreshonly, onlyif and unless should be changed into metaparameters, so they're available for all resource types. My guess is that this will require defining a new type of metaparameter, in the same way that the Exec checks are a slightly different type of parameter. Add Comment
