On March 18, 2016 at 19:12:08, Rob Nelson ([email protected]) wrote:
Happy Friday, everyone! This morning I had some semi-intelligible thoughts about feature deprecation in Puppet, specifically because I got bit with an upgrade issue last night. We do user stories a lot at work, so I'm going to frame it that way. I was curious what other opinions people have on this problem and how it can best be addressed. Thanks! Problem When a user updates puppet components (server, agent, puppetdb, etc.), a number of new features and options are typically made available, in addition to the default location of some files being changed. Older features, options, and file locations (collectively 'features' for simplicity) are considered deprecated, to be removed in some future version. Alerting the user of this is challenging for a few reasons. 1. Deprecation messages in puppet runs are noisy and most users disable them as quickly as possible, never to be seen again. The proposed solution for this is already to add the strict mode. So you can basically opt in/out of deprecation warnings. 2. Moving the messages to the component's log results in a bunch of needles being added to the needlestack. IMHO the deprecation warnings aren't visible enough. Most of them are just logged on the puppetmaster side. So there is no way for a user to see them (on the agent side). This is one of the major pros of masterless at the moment in my opinion, that you can easily see the log messages from the compilation as well. It would be really good if the puppetmaster could ship them to the agent as well. 3. At the time of deprecation, it is usually impossible to determine what future version will have no longer support the deprecated feature, so users cannot plan for a timely removal of the feature. Isn't this always the next major version? That is kind of the point of semantic versioning to make it easy to know which versions are breaking compatibility. 4. When upgrades occur, deprecated or changed features often result in failure to start/run, failure to properly apply entire catalogs due to the loss of some components of it, poor or confusing logging about what caused the issue, etc. Well, that depends on how often you do major version upgrades. Solution Deprecated features can each be given an identifier (ID, String, etc). Use of a deprecated feature can go to a specific log within the component or general puppet logs that includes the timestamp, identifier, and relevant identifying information such as catalog or configuration file name and line. An additional tool can be provided for users to review this log and provide the number of and last timestamp indicating usage of the deprecated feature, along with the entirety of that log entry. Each deprecated feature identifier can easily be searched for in Puppet Labs documentation, Jira tickets, and search engines to help determine how a user may address the issue prior to upgrades. After an upgrade where a deprecated feature is removed, the identifier can be displayed directly to a user in addition to the log, and any interactive upgrade can review the recent logs (i.e. 24 or 48 hours) and highlight features removed in the the last MAJOR or MINOR update. It is understood that newer versions that do not support a feature will also no longer be able to detect the deprecated feature and provide accurate logging of the missing feature that is causing the fault. By separating out the deprecated messages into a separate log and providing a simple tool to search the logs, the user is empowered to easily find the use of the deprecated features and can correlate the IDs with release notes and such as well as the time of upgrades. Rob Nelson [email protected] -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAC76iT90BqJTQHxga8nzTHTLoyV%3DjpLJ5BOOgDOjXHcN9dpiMw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout. -- Erik Dalén -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/etPan.56f169f4.400880f1.2e3%40C02QT1YNFVH8. For more options, visit https://groups.google.com/d/optout.
