On 17/11/23 04:35, Takashi Kajinami wrote:
Hi,
As I mentioned in the heat patch, I have some concerns about this, and now I disagree with the exception request as a heat core.
1. The proposed change is a new feature, not a bug fix. Heat have asserted that we follow the stable branch policy.[1] IMO we should not accept its backport unless - TC updates the stable policy - Heat decides to abandon following the global stable policy and use own one
I can't speak for TC, but from my view as a heat core, I'd prefer not changing our project maintenance policy after we've followed the global stable maintenance policy for long period. If we accept this exception then there can be others, and we may eventually accept all feature backports. This changes the expectation for stable branches and can confuse users.
[1] https://docs.openstack.org/project-team-guide/stable-branches.html
2. Heat exposes the version a specific resource was added, deprecated or removed. However this interface does not explain a backported feature. The feature was merged after Bobcat release so the support information should look like version >= 21.1.0 or (version < 21.0.0 and version >= 20.1.0( but this does not fit the schema we currently use.
3. This is similar to 2, but heat would be broken in case a user attemptes upgrade from 20.1.0 (antelope with the feature backported) to 21.0.0 (bobcat without the feature), after the new resource is created. We need a proper block to prohibit this upgrade path.
4. The feature was added quite recently, and has never been tested in upstream due to lack of jobs with prometheus. Even if we backport the feature, we should have a proper test coverage in CI or at least manual testing done, to avoid backportimg multiple bug fixes later.
I'm open for feedback from the other cores.
FWIW I completely agree with Takashi here.
Thank you, Takashi
On 11/14/23 00:58, Martin Magr wrote:
On Mon, Nov 13, 2023 at 4:50 PM Martin Magr <mmagr@redhat.com> wrote:
Adding more folks from requirements core to CC.
And also correct mailing list. I'm sorry for the noise.
On Mon, Nov 13, 2023 at 4:32 PM Martin Magr <mmagr@redhat.com> wrote:
Greetings,
we have introduced new feature to Aodh [1][2] (which introduced new dependency [3]) and Heat [4] recently. The changes to both projects are relatively small, it just added new respective resources and did not change existing logic. Also the new dependency is providing functionality to those new resources.
We are building our product on stable/antelope and so ideal state for us would be to have those changes included in this branch also on upstream side. I'm aware that Heat follows stable branch policy and it's written in requirements documentation, that new dependency cannot be added in stable ranches, but before we are going to start building workarounds on this I'd like to ask if there is any chance of getting exception (given the fact that changes are pretty safe) on backporting the Heat patch down to stable/antelope and(or at least) including the new dependency in stable/antelope.
Thanks for answer in advance, Martin
[1] https://review.opendev.org/c/openstack/aodh/+/890529 [2] https://review.opendev.org/c/openstack/python-aodhclient/+/893319 [3] https://review.opendev.org/c/openstack/requirements/+/891291 [4] https://review.opendev.org/c/openstack/heat/+/893673
-- Martin Mágr Principal Software Engineer - Service Telemetry Framework Red Hat Czech
-- Martin