Backporting networking-ansible to Queens
We have requested to add ansible-runner and update the version of python-pexpect from 4.3 to 4.5 in the openstack-requirements repository. https://review.openstack.org/#/c/624048 This is in effort to enable the networking-ansible ML2 driver in Queens. It was developed as part of the Rocky development cycle. We understood that this is outside the structure of standard practice and would like to request an exception for this change in light of it's low risk. We have customers that are asking for this ML2 driver to be enabled in our product that is based on Queens. We would like to push these changes to upstream first. This exposes the community to this code and prevents the need to carry patches downstream. This ML2 driver is an add on feature that should carry little to no technical debt for the stable/Queens code base. Python-pexpect need to be updated and we will update Triple-o to enable it to install and configure the new driver. Otherwise the backport consists of adding the ansible-runner dependency and packaging the code for the networking-ansible ML2 driver. End users are impacted only when they choose to install the feature and enable it. Thank you for your consideration, Dan Radez
On 12/12/18 4:44 PM, Dan Radez wrote:
We have requested to add ansible-runner and update the version of python-pexpect from 4.3 to 4.5 in the openstack-requirements repository. https://review.openstack.org/#/c/624048
This is in effort to enable the networking-ansible ML2 driver in Queens. It was developed as part of the Rocky development cycle.
We understood that this is outside the structure of standard practice and would like to request an exception for this change in light of it's low risk.
We have customers that are asking for this ML2 driver to be enabled in our product that is based on Queens. We would like to push these changes to upstream first. This exposes the community to this code and prevents the need to carry patches downstream.
This ML2 driver is an add on feature that should carry little to no technical debt for the stable/Queens code base. Python-pexpect need to be updated and we will update Triple-o to enable it to install and configure the new driver. Otherwise the backport consists of adding the ansible-runner dependency and packaging the code for the networking-ansible ML2 driver. End users are impacted only when they choose to install the feature and enable it.
Thank you for your consideration,
Dan Radez
python-pexpect is used by a small handful of projects. There a chance that pyyaml may have to be bumped one minor version as well. These changes seem to be a fairly low impact for networking-ansible's dependency updates. The community is not being asked to take on any more maintenance or spend extra time as a result of this backport. The requirements update for the backport has passed all of its tests. While this is an unusual request, our hope is the value for us and for queens users can be seen. In light of the low risk and the expected zero additional time/maintenance could an exception be made to approve this update to happen? Dan Radez
On Tue, Dec 18, 2018 at 11:00:39AM -0500, Dan Radez wrote:
python-pexpect is used by a small handful of projects. There a chance that pyyaml may have to be bumped one minor version as well. These changes seem to be a fairly low impact for networking-ansible's dependency updates.
Why would we bump pyyaml? I don't see that covered in the change. There are 56 consumers of pyyaml in stable/queens, depending on the nature of the bump, many or which would need to take some action.
The community is not being asked to take on any more maintenance or spend extra time as a result of this backport. The requirements update for the backport has passed all of its tests.
That's not quite accurate. Merging 624048, would mean generating, merging requirements updates to all consumers of pyexpect: Package : pexpect [pexpect!=3.3,>=3.1] (used by 3 projects) Also affects : 3 projects openstack/rpm-packaging [None] openstack/storlets [None] openstack/trove [None] Which would then force immediate releases of storlets and trove (minor updates) which then means all vendors and operators using those services need to re-generate packages and environments for those services. So the broader developer, vendor and operator community is being asked to do non-zero amounts of work. Now clearly RedHat (our employer) sees value in this work but do SUSE, Canonical, Gentoo and Debian? We could *not* do that work but then those projects would be working by luck rather than design.
While this is an unusual request, our hope is the value for us and for queens users can be seen. In light of the low risk and the expected zero additional time/maintenance could an exception be made to approve this update to happen?
At this point I don't see a compelling reason deviate from from the established norm. Yours Tony.
On 12/12/2018 3:44 PM, Dan Radez wrote:
We have customers that are asking for this ML2 driver to be enabled in our product that is based on Queens. We would like to push these changes to upstream first. This exposes the community to this code and prevents the need to carry patches downstream.
Replaying what I said in the review: "That is not sufficient justification for breaking stable branch policy. We all have customers on older versions of openstack that would like newer features. It is the job of vendors, not the community, to figure out how to satisfy those requests for their customers, either by getting the customer upgraded or carrying internal forks on stable branches." Regardless of impact, I don't want to set a precedent for picking and choosing which features are safe to backport to stable branches based on one vendor's customer demands. -- Thanks, Matt
participants (3)
-
Dan Radez
-
Matt Riedemann
-
Tony Breeds