Jira (PUP-4627) Storeconfigs unusable with Puppetserver
Title: Message Title Christopher Barbour commented on PUP-4627 Re: Storeconfigs unusable with Puppetserver This particular client is too large to continue using exported resources the way they currently are. Continued use of Active Record store configs is a stop-gap measure prior to moving to something else. So, this bug is less a question of Do we continue using Active Record or migrate to PuppetDB? and more a question of Do we continue using Apache/Passenger/Rails/MRI Ruby or move to Puppetserver/Jruby? Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) -- 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-4627) Storeconfigs unusable with Puppetserver
Title: Message Title Christopher Barbour created an issue Puppet / PUP-4627 Storeconfigs unusable with Puppetserver Issue Type: Bug Affects Versions: PUP 3.8.0 Assignee: Unassigned Created: 2015/05/18 11:58 AM Priority: Normal Reporter: Christopher Barbour The MySQL ruby gem will not compile for Jruby. As a result, current users of Active Record storeconfigs cannot upgrade to Puppetserver. The fix for this appears to be relatively straightforward; add jdbcmysql to the list of mysql connectors in the Puppet Rails library, and update the spec tests. The Active Record ORM should handle most of the complexity of using JDBC drivers, and the change poses no risk to users of the mysql and mysql2 connectors. https://github.com/puppetlabs/puppet/blob/3.x/lib/puppet/rails.rb https://github.com/puppetlabs/puppet/blob/3.x/lib/puppet/rails/database/schema.rb While storeconfigs are deprecated, this issue does block current users from moving away from Apache/Passenger/Rails. The requested change is simple, and extremely low risk.
Jira (PUP-4627) Storeconfigs unusable with Puppetserver
Title: Message Title Christopher Barbour commented on PUP-4627 Re: Storeconfigs unusable with Puppetserver We'd be more than happy to supply a PR and update spec tests for the change, but before investing the effort I'd like to see if Puppet Labs is receptive to accepting a PR for Active Record against the 3.x or 3.8 branch. Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) -- 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-4459) Authoritative ENC Environments should be optional
Title: Message Title Christopher Barbour commented on PUP-4459 Re: Authoritative ENC Environments should be optional Can you link me to the client authoritative environment PR you mentioned? I'd like to take a look. I understand the security implications; i absolutely feel that this is something that should be configurable, especially given that it would change the current behavior. The feature is that it should be possible to invoke puppet agent using the --environment and --noop flags even with a server specified environment. Any other component of this request is simply an implementation detail. Again, we don't need the ability to set enforcement of environments on a per node basis via the ENC; that's just one possible implementation of the original request. Perhaps it would make sense to explain this in terms of a workflow? I want to deploy new code to my production infrastructure. I am currently building a feature branch. Prior to deploying this code, I wish to invoke a --noop run to determine what would change with the new branch. Current workflow with enc specified: 1. Put the node into noop mode, or disable Puppet on the node. 2. Set the node to use user-specified environment in the PE console (note that not all consoles support this.) 3. Invoke puppet on the node, using --environment to specify the new environment. 4. Return the node to its original environment in the console. 5. Return the node to enforcing mode, or re-enable puppet. If I forget to perform step 1 before changing the environment in step 2, I may cause the wrong branch of code to be enforced on the node. This could potentially break the node. If I fail to enable user-specified environments in step 2, the master will reject my environment request. If I fail to return the node to it's original environment in step 4, puppet may be invoked with the wrong environment, potentially breaking the node. If I fail to re-enable puppet in step 5, the node's configuration will no longer be enforced, potentially breaking production. Other notes: The overhead of performing this process will discourage simulation of changes prior to release. There are few ways to mitigate these risks using automation. Disabling ENC specified environments globally is not an option in this scenario for the reasons mentioned in my previous post.
Jira (PUP-4459) Authoritative ENC Environments should be optional
Title: Message Title Christopher Barbour commented on PUP-4459 Re: Authoritative ENC Environments should be optional Thanks for digging that up. Yes, I think that PR is unrelated. Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) -- 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-4459) Authoritative ENC Environments should be optional
Title: Message Title Christopher Barbour commented on PUP-4459 Re: Authoritative ENC Environments should be optional The Puppet Catalog Preview feature sounds very powerful, and I'm excited to see it. Any chance it will require changes similar to what I've requested here? Noop mode of course has some real benefits over catalog diff. A big one is that it can be used to develop 'rollback' releases, which can be very difficult to implement otherwise. I'm hoping for a more generic solution that can be used without the PE console; I have a lot of clients running OS Puppet, and I did a lot of PE deploys without the console prior to PE 3.7. Run this node now in noop-mode in environment x The PE Orchestration console in PE already gives us this ability, and the PE console provides a great reporting engine to see the results. The combination is very powerful and very flexible. The only missing piece is the ability to use agent specified environments even with ENC specified environments. Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) -- 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-4459) Authoritative ENC Environments should be optional
Title: Message Title Christopher Barbour commented on PUP-4459 Re: Authoritative ENC Environments should be optional For that, I think the solution is to write an ENC implementation Possibly one that delegates to another already existing ENC. To the best of my understanding, the ENC has no knowledge of the client specified environment. Thus, there's no way to determine whether or not the client specified an environment, and to react accordingly. Whatever solution is provided, simplicity is key. There's already a lot of stuff in puppet that's difficult to understand. I don't feel that a best practices workflow should require writing a custom ENC or an ENC wrapper. Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) -- 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-4459) Authoritative ENC Environments should be optional
Title: Message Title Christopher Barbour commented on PUP-4459 Re: Authoritative ENC Environments should be optional Determining whether or not a node is permitted to change it's own environment is trivial using a custom ENC and a node parameter; that's not the problem I'm trying to solve. What's needed is a way to determine whether or not the agent specified an environment, and based on that condition determine whether to return the ENC specified environment or not. Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) -- 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-4459) Authoritative ENC Environments should be optional
Title: Message Title Christopher Barbour commented on PUP-4459 Re: Authoritative ENC Environments should be optional I see, thanks for clarifying. I assume that this is the logic you've been referring to: https://github.com/puppetlabs/puppet/blob/15c4ffdc5415b1ee8c701a956ec0c5cefaf7af41/lib/puppet/indirector/node/exec.rb#L24 This solves the problem. The only remaining issue is to determine whether the agent specified environment is the default environment, or if it's been over-ridden on the command line. I think your original conclusion is correct; this logic can be indirector specific, and doesn't need to be a puppet.conf setting. So, this can be closed as wont-fix. Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) -- 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-4459) Authoritative ENC Environments should be optional
Title: Message Title Christopher Barbour commented on PUP-4459 Re: Authoritative ENC Environments should be optional This doesn't resolve the issue. The requirement is that the ENC should always supply an environment, but the agent's environment should take precedence if specified. This requirement is the opposite of the current behavior. I'm not suggesting that the current behavior should be changed; just that it should be be configurable to allow a choice between control and flexibility. This requirement exists because of two design patterns: Design pattern one: Release branches using R10k. Many sites currently maintain a production and a development branch. In those cases, it's fairly trivial to set a default environment in the node's puppet.conf file, to be overridden on the command line. However, in many cases it's more powerful to be able to fork release branches from a master branch. E.g. rather than having dev and production, I might have master, 1.0, 1.1, 1.2, etc. each branched from master at different points in time. In these cases, we could potentially have dozens of available release branches, and several active release branches assigned to various hostgroups. ENC specified environments are the best and most practical way to assign nodes to environments in this example. Design pattern two: Noop simulation runs prior to release/merge. With R10k, it's trivial to deploy new code as a feature branch. E.g. 'cbarbour/potentially_breaking_change.' Changes can be simulated using --test --noop and --environment to perform a one-time test against the feature branch. This requires an agent specified environment. While it might be possible to put a node into --noop mode and temporarily change the ENC specified environment, doing so dramatically increases the risk of performing a no-noop run against a non-production branch, and impedes the simulation process. The two patterns are currently impractical to combine on the same site. No one is asking Puppet to provide another classifier layer; I brought it up based on your comments, with the reservation that it adds a lot of complexity that probably would only benefit a few sites. This request is simply to make the behavior discussed in https://projects.puppetlabs.com/issues/3910 user configurable, just like many of the other environment behaviors. I'm currently unaware of a way to test for the node specified environment inside an ENC script. $::environment is set by the master. Even if I was able to do this, an ENC wrapper script is a hack, and not something I would prefer to recommend to clients. I've already had to disable ENC specified environments at several sites because of the current behavior. This change would help to emphasize Puppet's simulation mode, without reducing the functionality of an ENC. Add Comment
Jira (PUP-4459) Authoritative ENC Environments should be optional
Title: Message Title Christopher Barbour commented on PUP-4459 Re: Authoritative ENC Environments should be optional FWIW, this may not be a trivial request, based on a review of https://projects.puppetlabs.com/issues/3910 https://github.com/puppetlabs/puppet/pull/691/files Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) -- 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-4459) Authoritative ENC Environments should be optional
Title: Message Title Christopher Barbour commented on PUP-4459 Re: Authoritative ENC Environments should be optional Agreed, that is the ideal solution. Whether or not a node is allowed to override the ENC defined environment should probably be a property of the node, and managing node properties is the domain of the node classifier. The benefits of your approach is that we could use the PE rules classifier to define which group of nodes may override their environment. E.g. allow development nodes to change environment, but not production nodes. Or if supporting multiple tenants, we could control the setting on a per client basis. This would also open the possibility of building an 'approved environment list' feature into the ENC. My only reservation of including this feature in the ENC is that we'd have to wait for the various classifiers to supply the appropriate setting. Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) -- 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-4459) Authoritative ENC Environments should be optional
Title: Message Title Christopher Barbour assigned an issue to Henrik Lindberg Puppet / PUP-4459 Authoritative ENC Environments should be optional Change By: Christopher Barbour Assignee: ChristopherBarbour HenrikLindberg Add Comment This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) -- 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-4459) Authoritative ENC Environments should be optional
Title: Message Title Christopher Barbour created an issue Puppet / PUP-4459 Authoritative ENC Environments should be optional Issue Type: New Feature Affects Versions: PUP 3.7.5 Assignee: Henrik Lindberg Components: Server Created: 2015/04/23 4:19 PM Priority: Normal Reporter: Christopher Barbour When the puppet master and puppet agent both specify an environment, it should be possible to configure which environment will be used. In Puppet 3.7.5, the node classifier supplied environment is absolutely authoritative; if the ENC specifies one environment and the agent another the ENC specified environment always wins. This approach breaks workflows where we wish to use the ENC to specify a default environment, while still allowing a user to invoke Puppet using an alternative environment. This workflow is very common when combined with the --noop argument to simulate how a change will affect a node without actually applying the change. In such a workflow, the ENC would supply the environment for normal operation, and the user may wish to over-ride the default environment on a one-off basis. Could we add an `authoratative_environment` or similar configuration option for the [master] configuration block?
Jira (HI-125) Can't interpolate hash or array members with %{} tokens
Title: Message Title
Christopher Barbour commented on HI-125
Re: Can't interpolate hash or array members with %{} tokens
Inability to access the trusted hash is a major concern, especially when using hiera-eyaml or hiera as an ENC with hiera_include().
A workaround in the mean time is to define trusted variables as key/value pairs in site.pp, or in the case of clientcert, set it as a property in your ENC script.
Add Comment
This message was sent by Atlassian JIRA (v6.3.10#6340-sha1:7ea293a)
--
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-3328) tidy should follow symlinks
Title: Message Title Christopher Barbour commented on PUP-3328 Re: tidy should follow symlinks If this is added, it needs to be configurable. Otherwise, it would be pretty trivial for a malicious user to purge arbitrary data from the filesystem using this feature. Add Comment This message was sent by Atlassian JIRA (v6.3.10#6340-sha1:7ea293a) -- 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-3861) Pull request #2670 will break yum provider with long package names
Title: Message Title Christopher Barbour commented on PUP-3861 Re: Pull request #2670 will break yum provider with long package names You can probably reproduce this issue by giving your CentOS base repository an extremely long name. If no one else can test, I can spin up a new OEL VM (which is where I originally encountered the issue.) In my case, I ran into the problem while developing an extremely customized version of the YUM provider based on the code in HEAD. Add Comment This message was sent by Atlassian JIRA (v6.3.10#6340-sha1:7ea293a) -- 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-3861) Pull request #2670 will break yum provider with long package names
Title: Message Title Christopher Barbour created an issue Puppet / PUP-3861 Pull request #2670 will break yum provider with long package names Issue Type: Bug Affects Versions: PUP M Assignee: Kylo Ginsberg Components: Types and Providers Created: 2015/01/17 10:36 PM Priority: Normal Reporter: Christopher Barbour Pull request #2670 replaces yumhelper with a direct call to yum check-update. The output is then parsed line by line for package update information. https://github.com/puppetlabs/puppet/commit/8b18639427dbeb17c262f9a459f4d1b6c0380b40#diff-d66f8a2f004447ff56ddba30c0b9161d Unfortunately, YUM the yum binary performs line wrapping on all output at 80 characters when piped to an external command. Lines may not contain the expected fields if any long package names are present on the system. This can result in a parse error when the provider is invoked. While this is not in keeping with the unix philosophy, the YUM authors have no plans to change the behavior. https://bugzilla.redhat.com/show_bug.cgi?id=584525 The workaround is either to invoke YUM using the Python API calls, or to use repoquery instead. Repoquery is part of the yum-utils package, which may or
Jira (PUP-1927) Yum package Provider ignores Source parameter
Title: Message Title Christopher Barbour created an issue Puppet / PUP-1927 Yum package Provider ignores Source parameter Issue Type: Bug Affects Versions: 3.4.3 Assignee: Kylo Ginsberg Components: Types and Providers Created: 13/Mar/14 12:57 AM Priority: Normal Reporter: Christopher Barbour The YUM provider for the package type ignores the source parameter, and instead uses the name parameter for all package installation tasks. This behavior is somewhat inconsistent with other providers for this resource type. For example, with the RPM provider, the name parameter is compared against the packages instances list. If the defined package is not installed but should be, the provider will then download the package supplied by the source parameter and install it. With the yum provider, in the same conditions, puppet will kick off a yum installation of the named package, not the package supplied by the source parameter. This is okay if the desired package happens to be in a configured yum repository, but not so great otherwise. YUM fully supports installation from a source path; on older releases using the localinstall command, and on newer systems using the install command. This behavior is useful for multi-platform support and for module testing. In testing, I may wish to pass a explicit source for
Jira (PUP-1927) Yum Package Provider Ignores Source Parameter
Title: Message Title Christopher Barbour updated an issue Puppet / PUP-1927 Yum Package Provider Ignores Source Parameter Change By: Christopher Barbour Summary: Yum package Package Provider ignores Ignores Source parameter Parameter 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-1927) Yum Package Provider Ignores Source Parameter
Title: Message Title Christopher Barbour updated an issue Puppet / PUP-1927 Yum Package Provider Ignores Source Parameter Change By: Christopher Barbour Labels: wf001 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.
