< Changes
(→Scope) |
(Add tracker bug) |
||
| (10 intermediate revisions by 2 users not shown) | |||
| Line 55: | Line 55: | ||
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development | CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development | ||
--> | --> | ||
* Tracker bug: | * Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1078776 #1078776] | ||
== Detailed Description == | == Detailed Description == | ||
| Line 75: | Line 75: | ||
Initially the change will be added as a path series to the autofs package, later when an upstream beta is released the source will be updated, finally when autofs-5.1.0 is released the source will updated again. | Initially the change will be added as a path series to the autofs package, later when an upstream beta is released the source will be updated, finally when autofs-5.1.0 is released the source will updated again. | ||
The release schedule has not been decided yet but the plan is to release a beta soon followed by 5.1.0 with the timing dependant on community feedback | The release schedule has not been decided yet but the plan is to release a beta soon followed by 5.1.0 with the timing dependant on community feedback. | ||
* Proposal owners: upstream the change is ready | Not all the changes (planned for 5.1.0 but not the amd parser itself) will be included in 5.1.0, they will be added as time permits via minor version updates. This is because the amd parser is considered an important feature and needs to be made available sooner rather than later. | ||
* Proposal owners: upstream the change is nearly ready to be committed to the master branch and a beta released. If the beta is released soon enough updating the Fedora autofs package source is all that will be needed. If not then the existing patch series can be added to the autofs package in the mean time. | |||
* Other developers: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | |||
<!-- What work do other developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | |||
* Release engineering: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | |||
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)? Is a mass rebuid required? If a rel-eng ticket exists, add a link here. --> | |||
* Policies and guidelines: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | |||
<!-- Do the packaging guidelines or other documents need to be updated for this feature? If so, does it need to happen before or after the implementation is done? If a FPC ticket exists, add a link here. --> | |||
== Upgrade/compatibility impact == | == Upgrade/compatibility impact == | ||
| Line 85: | Line 96: | ||
Existing configurations for people not using the new parser should continue to function as they did previously. | Existing configurations for people not using the new parser should continue to function as they did previously. | ||
Part of the configuration | Part of the configuration change involves splitting the autofs configuration into init configuration and daemon configuration with the daemon configuration moved to the /etc directory. After reading the new autofs configuration the old configuration is read to provide backward compatibility while uses update to the new configuration. One problem is that if a user uses the new functionality and doesn't pay attention to updating their configuration new configuration changes may be overridden by changes in the old configuration. There's no way to maintain backward compatibility and not have this problem but it is much better to not disrupt existing usage and require users pay attention to what needs to be done if they wish to use the new parser. | ||
== How To Test == | == How To Test == | ||
| Line 107: | Line 118: | ||
<!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this change depends? In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel change)? --> | <!-- What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this change depends? In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like the kernel (if this is not a kernel change)? --> | ||
There is one kernel change that is recommended when using the amd parser. | There is one kernel change that is recommended when using the amd parser. | ||
This change has been included in 3.14.0 rc kernel and so should be included in Fedora 21. It is not required for function of the new parser but is strongly recommended. | |||
== Contingency Plan == | == Contingency Plan == | ||
| Line 130: | Line 141: | ||
A summary of the points covered in the package README for use of amd format maps will be sufficient and will be added here as part of adding the functionality to Fedora. | A summary of the points covered in the package README for use of amd format maps will be sufficient and will be added here as part of adding the functionality to Fedora. | ||
[[Category: | [[Category:ChangeAcceptedF21]] | ||
<!-- When your change proposal page is completed and ready for review and announcement --> | <!-- When your change proposal page is completed and ready for review and announcement --> | ||
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | <!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | ||
Latest revision as of 10:23, 20 March 2014
Add amd map parser to autofs
Summary
The am-utils package provides automount services for automount maps that use an amd format. However, the am-utils project has not been actively maintained for quite a while now.
The am-utils package in Fedora has significant problems that are not easily resolved so an amd format parser is to be added to the autofs package.
Owner
- Name: Ian Kent
- Email: raven@themaw.net
- Release notes owner:
Current status
Detailed Description
The am-utils package provides automount services for automount maps that use an amd format. Unfortunately the am-utils project has not been actively maintained for quite a while now.
The am-utils package in Fedora has significant problems that are not easily resolved so an amd format parser is to be added to the autofs package.
The goal is to implement enough of the am-utils amd map parsing functionality to cover a large portion of the use cases provided by the am-utils package. Once this is done it will be up to users to describe the missing am-utils feature they need which will then be considered for addition in the upstream implementation.
Benefit to Fedora
Once there has been exposure to community and additional functionality requests considered, evaluated and perhaps implemented we can consider the need to retain am-utils in the Fedora distribution. The goal being to eliminate the need for inclusion of the largely unmaintained am-utils package.
Scope
The implementation of this functionality is restricted to the autofs package.
Some areas of this change will require changes to code common to the autofs parser and the amd parser and the amd parser will leverage existing autofs functionality but there is a high level of code separation because of the way parse modules are added to autofs.
Initially the change will be added as a path series to the autofs package, later when an upstream beta is released the source will be updated, finally when autofs-5.1.0 is released the source will updated again.
The release schedule has not been decided yet but the plan is to release a beta soon followed by 5.1.0 with the timing dependant on community feedback.
Not all the changes (planned for 5.1.0 but not the amd parser itself) will be included in 5.1.0, they will be added as time permits via minor version updates. This is because the amd parser is considered an important feature and needs to be made available sooner rather than later.
- Proposal owners: upstream the change is nearly ready to be committed to the master branch and a beta released. If the beta is released soon enough updating the Fedora autofs package source is all that will be needed. If not then the existing patch series can be added to the autofs package in the mean time.
- Other developers: N/A (not a System Wide Change)
- Release engineering: N/A (not a System Wide Change)
- Policies and guidelines: N/A (not a System Wide Change)
Upgrade/compatibility impact
There will be significant changes to the autofs configuration sub-system to provide relevant am-utils configuration. Users that want to use this functionality will need to pay attention to this.
Existing configurations for people not using the new parser should continue to function as they did previously.
Part of the configuration change involves splitting the autofs configuration into init configuration and daemon configuration with the daemon configuration moved to the /etc directory. After reading the new autofs configuration the old configuration is read to provide backward compatibility while uses update to the new configuration. One problem is that if a user uses the new functionality and doesn't pay attention to updating their configuration new configuration changes may be overridden by changes in the old configuration. There's no way to maintain backward compatibility and not have this problem but it is much better to not disrupt existing usage and require users pay attention to what needs to be done if they wish to use the new parser.
How To Test
Test examples need to be constructed and and some simple examples will be described here when the change is added to autofs. Most of the maps used during development are private and cannot be released so we will need to develop our own.
Dependencies
There is one kernel change that is recommended when using the amd parser.
This change has been included in 3.14.0 rc kernel and so should be included in Fedora 21. It is not required for function of the new parser but is strongly recommended.
Contingency Plan
- Contingency mechanism: the change is largely done upstream but if it doesn't meet user requirements we will revert back to the autofs-5.0 release. The autofs-5.0 release will continue to be supported for the foreseeable future and simpler new features may also still be added but significant new features probably will only be added to the master branch (autofs-5.1.0).
- Blocks release? N/A
- Blocks product? none
Documentation
One aspect of making this change available in Fedora (and as a beta upstream) is to obtain user review and feedback of the package man pages and the included README for use of amd format maps.
Release Notes
A summary of the points covered in the package README for use of amd format maps will be sufficient and will be added here as part of adding the functionality to Fedora.