[tc][release] Networking-midonet current status and Wallaby release
Hi, We have opened release patch for networking-midonet [1] but our concern about that project is that its gate is completly broken since some time thus we don't really know if the project is still working and valid to be released. In Wallaby cycle Neutron for example finished transition to the engine facade, and patch to adjust that in networking-midonet is still opened [2] (and red as there were some unrelated issues with most of the jobs there). In the past we had discussion about networking-midonet project and it's status as the official Neutron stadium project. Then some new folks stepped in to maintain it but now it seems a bit like (again) it lacks of maintainers. I know that it is very late in the cycle now so my question to the TC and release teams is: should we release stable/wallaby with its current state, even if it's broken or should we maybe don't release it at all until its gate will be up and running? [1] https://review.opendev.org/c/openstack/releases/+/781713 [2] https://review.opendev.org/c/openstack/networking-midonet/+/770797 -- Slawek Kaplonski Principal Software Engineer Red Hat
Hello, The main question is, does the previous Victoria version [1] will be compatible with the latest neutron changes and with the latest engine facade introduced during Wallaby? Releasing an unfixed engine facade code is useless, so we shouldn't release a new version of networking-midonet, because the project code won't be compatible with the rest of our projects (AFAIK neutron), unless, the previous version will not compatible either, and, unless, not releasing a Wallaby version leave the project branch uncut and so leave the corresponding series unmaintainable, and so unfixable a posteriori. If we do not release a new version then we will use a previous version of networking-midonet. This version will be the last Victoria version [1]. I suppose that this version (the victoria version) isn't compatible with the new facade engine either, isn't it? So release or not release a new version won't solve the facade engine problem, isn't? You said that neutron evolved and networking-midonet didn't, hence even if we release networking-midonet in the current state it will fail too, isn't it? However, releasing a new version and branching on it can give you the needed maintenance window to allow you to fix the issue later, when your gates will be fixed and then patches backported. git tags are cheap. We should notice that since Victoria some patches have been merged in Wallaby so even if they aren't ground breaking changes they are changes that it is worth to release.
From a release point of view I think it's worth it to release a new version and to cut Wallaby. We are close to the it's deadline. That will land the available delta between Victoria and Wallaby. That will allow to fix the engine facade by opening a maintenance window. If the project is still lacking maintainers in a few weeks / months, this will allow a more smooth deprecation of this one.
Thoughts? [1] https://opendev.org/openstack/releases/src/branch/master/deliverables/victor... Le lun. 29 mars 2021 à 10:32, Slawek Kaplonski <skaplons@redhat.com> a écrit :
Hi,
We have opened release patch for networking-midonet [1] but our concern about that project is that its gate is completly broken since some time thus we don't really know if the project is still working and valid to be released. In Wallaby cycle Neutron for example finished transition to the engine facade, and patch to adjust that in networking-midonet is still opened [2] (and red as there were some unrelated issues with most of the jobs there).
In the past we had discussion about networking-midonet project and it's status as the official Neutron stadium project. Then some new folks stepped in to maintain it but now it seems a bit like (again) it lacks of maintainers. I know that it is very late in the cycle now so my question to the TC and release teams is: should we release stable/wallaby with its current state, even if it's broken or should we maybe don't release it at all until its gate will be up and running?
[1] https://review.opendev.org/c/openstack/releases/+/781713 [2] https://review.opendev.org/c/openstack/networking-midonet/+/770797
-- Slawek Kaplonski Principal Software Engineer Red Hat
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----
Only one comment at the moment. MidoNet itself looks dead as well: https://github.com/midonet/midonet It might make sense to announce that and finally move away. That said, I'm also interested in answers to Hervé's questions below. -yoctozepto On Mon, Mar 29, 2021 at 11:55 AM Herve Beraud <hberaud@redhat.com> wrote:
Hello,
The main question is, does the previous Victoria version [1] will be compatible with the latest neutron changes and with the latest engine facade introduced during Wallaby?
Releasing an unfixed engine facade code is useless, so we shouldn't release a new version of networking-midonet, because the project code won't be compatible with the rest of our projects (AFAIK neutron), unless, the previous version will not compatible either, and, unless, not releasing a Wallaby version leave the project branch uncut and so leave the corresponding series unmaintainable, and so unfixable a posteriori.
If we do not release a new version then we will use a previous version of networking-midonet. This version will be the last Victoria version [1].
I suppose that this version (the victoria version) isn't compatible with the new facade engine either, isn't it?
So release or not release a new version won't solve the facade engine problem, isn't?
You said that neutron evolved and networking-midonet didn't, hence even if we release networking-midonet in the current state it will fail too, isn't it?
However, releasing a new version and branching on it can give you the needed maintenance window to allow you to fix the issue later, when your gates will be fixed and then patches backported. git tags are cheap.
We should notice that since Victoria some patches have been merged in Wallaby so even if they aren't ground breaking changes they are changes that it is worth to release.
From a release point of view I think it's worth it to release a new version and to cut Wallaby. We are close to the it's deadline. That will land the available delta between Victoria and Wallaby. That will allow to fix the engine facade by opening a maintenance window. If the project is still lacking maintainers in a few weeks / months, this will allow a more smooth deprecation of this one.
Thoughts?
[1] https://opendev.org/openstack/releases/src/branch/master/deliverables/victor...
Le lun. 29 mars 2021 à 10:32, Slawek Kaplonski <skaplons@redhat.com> a écrit :
Hi,
We have opened release patch for networking-midonet [1] but our concern about that project is that its gate is completly broken since some time thus we don't really know if the project is still working and valid to be released. In Wallaby cycle Neutron for example finished transition to the engine facade, and patch to adjust that in networking-midonet is still opened [2] (and red as there were some unrelated issues with most of the jobs there).
In the past we had discussion about networking-midonet project and it's status as the official Neutron stadium project. Then some new folks stepped in to maintain it but now it seems a bit like (again) it lacks of maintainers. I know that it is very late in the cycle now so my question to the TC and release teams is: should we release stable/wallaby with its current state, even if it's broken or should we maybe don't release it at all until its gate will be up and running?
[1] https://review.opendev.org/c/openstack/releases/+/781713 [2] https://review.opendev.org/c/openstack/networking-midonet/+/770797
-- Slawek Kaplonski Principal Software Engineer Red Hat
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE-----
wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----
Hi, On Mon, Mar 29, 2021 at 11:52:59AM +0200, Herve Beraud wrote:
Hello,
The main question is, does the previous Victoria version [1] will be compatible with the latest neutron changes and with the latest engine facade introduced during Wallaby?
It won't be compatible. Networking-midonet from Victoria will not work properly with Neutron Wallaby.
Releasing an unfixed engine facade code is useless, so we shouldn't release a new version of networking-midonet, because the project code won't be compatible with the rest of our projects (AFAIK neutron), unless, the previous version will not compatible either, and, unless, not releasing a Wallaby version leave the project branch uncut and so leave the corresponding series unmaintainable, and so unfixable a posteriori.
If we do not release a new version then we will use a previous version of networking-midonet. This version will be the last Victoria version [1].
I suppose that this version (the victoria version) isn't compatible with the new facade engine either, isn't it?
Correct. It's not compatible.
So release or not release a new version won't solve the facade engine problem, isn't?
Yes.
You said that neutron evolved and networking-midonet didn't, hence even if we release networking-midonet in the current state it will fail too, isn't it?
Also yes :)
However, releasing a new version and branching on it can give you the needed maintenance window to allow you to fix the issue later, when your gates will be fixed and then patches backported. git tags are cheap.
We should notice that since Victoria some patches have been merged in Wallaby so even if they aren't ground breaking changes they are changes that it is worth to release.
From a release point of view I think it's worth it to release a new version and to cut Wallaby. We are close to the it's deadline. That will land the available delta between Victoria and Wallaby. That will allow to fix the engine facade by opening a maintenance window. If the project is still lacking maintainers in a few weeks / months, this will allow a more smooth deprecation of this one.
Thoughts?
Based on Your feedback I agree that we should release now what we have. Even if it's broken we can then fix it and backport fixes to stable/wallaby branch. @Akihiro: are You ok with that too?
[1] https://opendev.org/openstack/releases/src/branch/master/deliverables/victor...
Le lun. 29 mars 2021 à 10:32, Slawek Kaplonski <skaplons@redhat.com> a écrit :
Hi,
We have opened release patch for networking-midonet [1] but our concern about that project is that its gate is completly broken since some time thus we don't really know if the project is still working and valid to be released. In Wallaby cycle Neutron for example finished transition to the engine facade, and patch to adjust that in networking-midonet is still opened [2] (and red as there were some unrelated issues with most of the jobs there).
In the past we had discussion about networking-midonet project and it's status as the official Neutron stadium project. Then some new folks stepped in to maintain it but now it seems a bit like (again) it lacks of maintainers. I know that it is very late in the cycle now so my question to the TC and release teams is: should we release stable/wallaby with its current state, even if it's broken or should we maybe don't release it at all until its gate will be up and running?
[1] https://review.opendev.org/c/openstack/releases/+/781713 [2] https://review.opendev.org/c/openstack/networking-midonet/+/770797
-- Slawek Kaplonski Principal Software Engineer Red Hat
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE-----
wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----
-- Slawek Kaplonski Principal Software Engineer Red Hat
On Mon, Mar 29, 2021 at 8:07 PM Slawek Kaplonski <skaplons@redhat.com> wrote:
Hi,
On Mon, Mar 29, 2021 at 11:52:59AM +0200, Herve Beraud wrote:
Hello,
The main question is, does the previous Victoria version [1] will be compatible with the latest neutron changes and with the latest engine facade introduced during Wallaby?
It won't be compatible. Networking-midonet from Victoria will not work properly with Neutron Wallaby.
Releasing an unfixed engine facade code is useless, so we shouldn't release a new version of networking-midonet, because the project code won't be compatible with the rest of our projects (AFAIK neutron), unless, the previous version will not compatible either, and, unless, not releasing a Wallaby version leave the project branch uncut and so leave the corresponding series unmaintainable, and so unfixable a posteriori.
If we do not release a new version then we will use a previous version of networking-midonet. This version will be the last Victoria version [1].
I suppose that this version (the victoria version) isn't compatible with the new facade engine either, isn't it?
Correct. It's not compatible.
So release or not release a new version won't solve the facade engine problem, isn't?
Yes.
You said that neutron evolved and networking-midonet didn't, hence even if we release networking-midonet in the current state it will fail too, isn't it?
Also yes :)
However, releasing a new version and branching on it can give you the needed maintenance window to allow you to fix the issue later, when your gates will be fixed and then patches backported. git tags are cheap.
We should notice that since Victoria some patches have been merged in Wallaby so even if they aren't ground breaking changes they are changes that it is worth to release.
From a release point of view I think it's worth it to release a new version and to cut Wallaby. We are close to the it's deadline. That will land the available delta between Victoria and Wallaby. That will allow to fix the engine facade by opening a maintenance window. If the project is still lacking maintainers in a few weeks / months, this will allow a more smooth deprecation of this one.
Thoughts?
Based on Your feedback I agree that we should release now what we have. Even if it's broken we can then fix it and backport fixes to stable/wallaby branch.
@Akihiro: are You ok with that too?
I was writing another reply and did not notice this mail. While I still have a doubt on releasing the broken code (which we are not sure can be fixed soon or not), I am okay with either decision.
[1] https://opendev.org/openstack/releases/src/branch/master/deliverables/victor...
Le lun. 29 mars 2021 à 10:32, Slawek Kaplonski <skaplons@redhat.com> a écrit :
Hi,
We have opened release patch for networking-midonet [1] but our concern about that project is that its gate is completly broken since some time thus we don't really know if the project is still working and valid to be released. In Wallaby cycle Neutron for example finished transition to the engine facade, and patch to adjust that in networking-midonet is still opened [2] (and red as there were some unrelated issues with most of the jobs there).
In the past we had discussion about networking-midonet project and it's status as the official Neutron stadium project. Then some new folks stepped in to maintain it but now it seems a bit like (again) it lacks of maintainers. I know that it is very late in the cycle now so my question to the TC and release teams is: should we release stable/wallaby with its current state, even if it's broken or should we maybe don't release it at all until its gate will be up and running?
[1] https://review.opendev.org/c/openstack/releases/+/781713 [2] https://review.opendev.org/c/openstack/networking-midonet/+/770797
-- Slawek Kaplonski Principal Software Engineer Red Hat
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE-----
wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----
-- Slawek Kaplonski Principal Software Engineer Red Hat
Out of interest - for networking-calico - what changes are needed to adapt to the new engine facade? On Mon, Mar 29, 2021 at 12:14 PM Akihiro Motoki <amotoki@gmail.com> wrote:
On Mon, Mar 29, 2021 at 8:07 PM Slawek Kaplonski <skaplons@redhat.com> wrote:
Hi,
On Mon, Mar 29, 2021 at 11:52:59AM +0200, Herve Beraud wrote:
Hello,
The main question is, does the previous Victoria version [1] will be compatible with the latest neutron changes and with the latest engine facade introduced during Wallaby?
It won't be compatible. Networking-midonet from Victoria will not work
with Neutron Wallaby.
Releasing an unfixed engine facade code is useless, so we shouldn't
release
a new version of networking-midonet, because the project code won't be compatible with the rest of our projects (AFAIK neutron), unless, the previous version will not compatible either, and, unless, not releasing a Wallaby version leave the project branch uncut and so leave the corresponding series unmaintainable, and so unfixable a posteriori.
If we do not release a new version then we will use a previous version of networking-midonet. This version will be the last Victoria version [1].
I suppose that this version (the victoria version) isn't compatible with the new facade engine either, isn't it?
Correct. It's not compatible.
So release or not release a new version won't solve the facade engine problem, isn't?
Yes.
You said that neutron evolved and networking-midonet didn't, hence
even if
we release networking-midonet in the current state it will fail too, isn't it?
Also yes :)
However, releasing a new version and branching on it can give you the needed maintenance window to allow you to fix the issue later, when
your
gates will be fixed and then patches backported. git tags are cheap.
We should notice that since Victoria some patches have been merged in Wallaby so even if they aren't ground breaking changes they are changes that it is worth to release.
From a release point of view I think it's worth it to release a new version and to cut Wallaby. We are close to the it's deadline. That will land
available delta between Victoria and Wallaby. That will allow to fix
properly the the
engine facade by opening a maintenance window. If the project is still lacking maintainers in a few weeks / months, this will allow a more smooth deprecation of this one.
Thoughts?
Based on Your feedback I agree that we should release now what we have. Even if it's broken we can then fix it and backport fixes to stable/wallaby branch.
@Akihiro: are You ok with that too?
I was writing another reply and did not notice this mail. While I still have a doubt on releasing the broken code (which we are not sure can be fixed soon or not), I am okay with either decision.
[1]
Le lun. 29 mars 2021 à 10:32, Slawek Kaplonski <skaplons@redhat.com> a écrit :
Hi,
We have opened release patch for networking-midonet [1] but our
concern
about that project is that its gate is completly broken since some time
don't really know if the project is still working and valid to be released. In Wallaby cycle Neutron for example finished transition to the engine facade, and patch to adjust that in networking-midonet is still opened [2] (and red as there were some unrelated issues with most of the jobs there).
In the past we had discussion about networking-midonet project and it's status as the official Neutron stadium project. Then some new folks stepped in to maintain it but now it seems a bit like (again) it lacks of
https://opendev.org/openstack/releases/src/branch/master/deliverables/victor... thus we maintainers.
I know that it is very late in the cycle now so my question to the TC and release teams is: should we release stable/wallaby with its current state, even if it's broken or should we maybe don't release it at all until its gate will be up and running?
[1] https://review.opendev.org/c/openstack/releases/+/781713 [2] https://review.opendev.org/c/openstack/networking-midonet/+/770797
-- Slawek Kaplonski Principal Software Engineer Red Hat
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE-----
wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----
-- Slawek Kaplonski Principal Software Engineer Red Hat
Hi, On Mon, Mar 29, 2021 at 11:31:38AM +0000, Neil Jerram wrote:
Out of interest - for networking-calico - what changes are needed to adapt to the new engine facade?
Basically in most cases it is simply do changes like e.g. are done in [1] to use engine facade api to make db transactions. Then You should run Your tests, see what will be broken and fix it :) [1] https://review.opendev.org/c/openstack/networking-midonet/+/770797/3/midonet...
On Mon, Mar 29, 2021 at 12:14 PM Akihiro Motoki <amotoki@gmail.com> wrote:
On Mon, Mar 29, 2021 at 8:07 PM Slawek Kaplonski <skaplons@redhat.com> wrote:
Hi,
On Mon, Mar 29, 2021 at 11:52:59AM +0200, Herve Beraud wrote:
Hello,
The main question is, does the previous Victoria version [1] will be compatible with the latest neutron changes and with the latest engine facade introduced during Wallaby?
It won't be compatible. Networking-midonet from Victoria will not work
with Neutron Wallaby.
Releasing an unfixed engine facade code is useless, so we shouldn't
release
a new version of networking-midonet, because the project code won't be compatible with the rest of our projects (AFAIK neutron), unless, the previous version will not compatible either, and, unless, not releasing a Wallaby version leave the project branch uncut and so leave the corresponding series unmaintainable, and so unfixable a posteriori.
If we do not release a new version then we will use a previous version of networking-midonet. This version will be the last Victoria version [1].
I suppose that this version (the victoria version) isn't compatible with the new facade engine either, isn't it?
Correct. It's not compatible.
So release or not release a new version won't solve the facade engine problem, isn't?
Yes.
You said that neutron evolved and networking-midonet didn't, hence
even if
we release networking-midonet in the current state it will fail too, isn't it?
Also yes :)
However, releasing a new version and branching on it can give you the needed maintenance window to allow you to fix the issue later, when
your
gates will be fixed and then patches backported. git tags are cheap.
We should notice that since Victoria some patches have been merged in Wallaby so even if they aren't ground breaking changes they are changes that it is worth to release.
From a release point of view I think it's worth it to release a new version and to cut Wallaby. We are close to the it's deadline. That will land
available delta between Victoria and Wallaby. That will allow to fix
properly the the
engine facade by opening a maintenance window. If the project is still lacking maintainers in a few weeks / months, this will allow a more smooth deprecation of this one.
Thoughts?
Based on Your feedback I agree that we should release now what we have. Even if it's broken we can then fix it and backport fixes to stable/wallaby branch.
@Akihiro: are You ok with that too?
I was writing another reply and did not notice this mail. While I still have a doubt on releasing the broken code (which we are not sure can be fixed soon or not), I am okay with either decision.
[1]
Le lun. 29 mars 2021 à 10:32, Slawek Kaplonski <skaplons@redhat.com> a écrit :
Hi,
We have opened release patch for networking-midonet [1] but our
concern
about that project is that its gate is completly broken since some time
don't really know if the project is still working and valid to be released. In Wallaby cycle Neutron for example finished transition to the engine facade, and patch to adjust that in networking-midonet is still opened [2] (and red as there were some unrelated issues with most of the jobs there).
In the past we had discussion about networking-midonet project and it's status as the official Neutron stadium project. Then some new folks stepped in to maintain it but now it seems a bit like (again) it lacks of
https://opendev.org/openstack/releases/src/branch/master/deliverables/victor... thus we maintainers.
I know that it is very late in the cycle now so my question to the TC and release teams is: should we release stable/wallaby with its current state, even if it's broken or should we maybe don't release it at all until its gate will be up and running?
[1] https://review.opendev.org/c/openstack/releases/+/781713 [2] https://review.opendev.org/c/openstack/networking-midonet/+/770797
-- Slawek Kaplonski Principal Software Engineer Red Hat
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE-----
wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----
-- Slawek Kaplonski Principal Software Engineer Red Hat
-- Slawek Kaplonski Principal Software Engineer Red Hat
From a release point of view I don't think that it is too late to abandon
Normally at this point we avoid discussing abandoning deliverables so close to the deadline and that aren't already abandoned from a governance point of view. However in this case it seems to be the more sane approach and the more consensual. If the neutron team and the TC agree with that, then we can simply remove the deliverable for Wallaby on the release repo. this deliverable as it follows the `cycle-with-rc` model and it wasn't ever released during Wallaby for now. However we are under pressure to cut all stable/wallaby branches in order to be able to branch requirements / devstack so that should be an immediate decision. Notice that the previously proposed RC1/cut approach [1] avoids the rush and let you have an opportunity to fix things. [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-March/021378.htm... Le lun. 29 mars 2021 à 16:29, Slawek Kaplonski <skaplons@redhat.com> a écrit :
Hi,
On Mon, Mar 29, 2021 at 11:31:38AM +0000, Neil Jerram wrote:
Out of interest - for networking-calico - what changes are needed to adapt to the new engine facade?
Basically in most cases it is simply do changes like e.g. are done in [1] to use engine facade api to make db transactions. Then You should run Your tests, see what will be broken and fix it :)
[1] https://review.opendev.org/c/openstack/networking-midonet/+/770797/3/midonet...
On Mon, Mar 29, 2021 at 12:14 PM Akihiro Motoki <amotoki@gmail.com>
wrote:
On Mon, Mar 29, 2021 at 8:07 PM Slawek Kaplonski <skaplons@redhat.com> wrote:
Hi,
On Mon, Mar 29, 2021 at 11:52:59AM +0200, Herve Beraud wrote:
Hello,
The main question is, does the previous Victoria version [1] will
compatible with the latest neutron changes and with the latest engine facade introduced during Wallaby?
It won't be compatible. Networking-midonet from Victoria will not work properly with Neutron Wallaby.
Releasing an unfixed engine facade code is useless, so we shouldn't
release
a new version of networking-midonet, because the project code won't be compatible with the rest of our projects (AFAIK neutron), unless,
previous version will not compatible either, and, unless, not releasing a Wallaby version leave the project branch uncut and so leave the corresponding series unmaintainable, and so unfixable a posteriori.
If we do not release a new version then we will use a previous version of networking-midonet. This version will be the last Victoria version [1].
I suppose that this version (the victoria version) isn't compatible with the new facade engine either, isn't it?
Correct. It's not compatible.
So release or not release a new version won't solve the facade
engine
problem, isn't?
Yes.
You said that neutron evolved and networking-midonet didn't, hence
even if
we release networking-midonet in the current state it will fail too, isn't it?
Also yes :)
However, releasing a new version and branching on it can give you
needed maintenance window to allow you to fix the issue later, when your gates will be fixed and then patches backported. git tags are cheap.
We should notice that since Victoria some patches have been merged in Wallaby so even if they aren't ground breaking changes they are changes that it is worth to release.
From a release point of view I think it's worth it to release a new version and to cut Wallaby. We are close to the it's deadline. That will land the available delta between Victoria and Wallaby. That will allow to fix the engine facade by opening a maintenance window. If the project is still lacking maintainers in a few weeks / months, this will allow a more smooth deprecation of this one.
Thoughts?
Based on Your feedback I agree that we should release now what we have. Even if it's broken we can then fix it and backport fixes to stable/wallaby branch.
@Akihiro: are You ok with that too?
I was writing another reply and did not notice this mail. While I still have a doubt on releasing the broken code (which we are not sure can be fixed soon or not), I am okay with either decision.
[1]
https://opendev.org/openstack/releases/src/branch/master/deliverables/victor...
Le lun. 29 mars 2021 à 10:32, Slawek Kaplonski <
écrit :
Hi,
We have opened release patch for networking-midonet [1] but our concern about that project is that its gate is completly broken since some time
don't really know if the project is still working and valid to be released. In Wallaby cycle Neutron for example finished transition to the engine facade, and patch to adjust that in networking-midonet is still opened [2] (and red as there were some unrelated issues with most of the jobs there).
In the past we had discussion about networking-midonet project and it's status as the official Neutron stadium project. Then some new folks stepped in to maintain it but now it seems a bit like (again) it lacks of
skaplons@redhat.com> a thus we maintainers.
I know that it is very late in the cycle now so my question to
be the the the
TC and
release teams is: should we release stable/wallaby with its current state, even if it's broken or should we maybe don't release it at all until its gate will be up and running?
[1] https://review.opendev.org/c/openstack/releases/+/781713 [2] https://review.opendev.org/c/openstack/networking-midonet/+/770797
-- Slawek Kaplonski Principal Software Engineer Red Hat
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE-----
wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----
-- Slawek Kaplonski Principal Software Engineer Red Hat
-- Slawek Kaplonski Principal Software Engineer Red Hat
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----
On Mon, Mar 29, 2021 at 3:29 PM Slawek Kaplonski <skaplons@redhat.com> wrote:
Hi,
On Mon, Mar 29, 2021 at 11:31:38AM +0000, Neil Jerram wrote:
Out of interest - for networking-calico - what changes are needed to adapt to the new engine facade?
Basically in most cases it is simply do changes like e.g. are done in [1] to use engine facade api to make db transactions. Then You should run Your tests, see what will be broken and fix it :)
[1] https://review.opendev.org/c/openstack/networking-midonet/+/770797/3/midonet...
Thank you very much Slawek ! Neil
---- On Mon, 29 Mar 2021 06:14:06 -0500 Akihiro Motoki <amotoki@gmail.com> wrote ----
On Mon, Mar 29, 2021 at 8:07 PM Slawek Kaplonski <skaplons@redhat.com> wrote:
Hi,
On Mon, Mar 29, 2021 at 11:52:59AM +0200, Herve Beraud wrote:
Hello,
The main question is, does the previous Victoria version [1] will be compatible with the latest neutron changes and with the latest engine facade introduced during Wallaby?
It won't be compatible. Networking-midonet from Victoria will not work properly with Neutron Wallaby.
Releasing an unfixed engine facade code is useless, so we shouldn't release a new version of networking-midonet, because the project code won't be compatible with the rest of our projects (AFAIK neutron), unless, the previous version will not compatible either, and, unless, not releasing a Wallaby version leave the project branch uncut and so leave the corresponding series unmaintainable, and so unfixable a posteriori.
If we do not release a new version then we will use a previous version of networking-midonet. This version will be the last Victoria version [1].
I suppose that this version (the victoria version) isn't compatible with the new facade engine either, isn't it?
Correct. It's not compatible.
So release or not release a new version won't solve the facade engine problem, isn't?
Yes.
You said that neutron evolved and networking-midonet didn't, hence even if we release networking-midonet in the current state it will fail too, isn't it?
Also yes :)
However, releasing a new version and branching on it can give you the needed maintenance window to allow you to fix the issue later, when your gates will be fixed and then patches backported. git tags are cheap.
We should notice that since Victoria some patches have been merged in Wallaby so even if they aren't ground breaking changes they are changes that it is worth to release.
From a release point of view I think it's worth it to release a new version and to cut Wallaby. We are close to the it's deadline. That will land the available delta between Victoria and Wallaby. That will allow to fix the engine facade by opening a maintenance window. If the project is still lacking maintainers in a few weeks / months, this will allow a more smooth deprecation of this one.
Thoughts?
Based on Your feedback I agree that we should release now what we have. Even if it's broken we can then fix it and backport fixes to stable/wallaby branch.
@Akihiro: are You ok with that too?
I was writing another reply and did not notice this mail. While I still have a doubt on releasing the broken code (which we are not sure can be fixed soon or not), I am okay with either decision.
Yeah, releasing broken code and especially where we do not if there will be maintainer to fix it or not seems risky for me too. One option is to deprecate it for wallaby which means follow the deprecation steps mentioned in project-team-guide[1]. If maintainers show up then it can be un-deprecated. With that, we will not have any compatible wallaby version which I think is a better choice than releasing the broken code. Releasing the broken code now with the hope of someone will come up and fix it with backport makes me a little uncomfortable and if it did not get fix then we will live with broken release forever. [1]https://docs.openstack.org/project-team-guide/repository.html#deprecating-a-... -gmann
[1] https://opendev.org/openstack/releases/src/branch/master/deliverables/victor...
Le lun. 29 mars 2021 à 10:32, Slawek Kaplonski <skaplons@redhat.com> a écrit :
Hi,
We have opened release patch for networking-midonet [1] but our concern about that project is that its gate is completly broken since some time thus we don't really know if the project is still working and valid to be released. In Wallaby cycle Neutron for example finished transition to the engine facade, and patch to adjust that in networking-midonet is still opened [2] (and red as there were some unrelated issues with most of the jobs there).
In the past we had discussion about networking-midonet project and it's status as the official Neutron stadium project. Then some new folks stepped in to maintain it but now it seems a bit like (again) it lacks of maintainers. I know that it is very late in the cycle now so my question to the TC and release teams is: should we release stable/wallaby with its current state, even if it's broken or should we maybe don't release it at all until its gate will be up and running?
[1] https://review.opendev.org/c/openstack/releases/+/781713 [2] https://review.opendev.org/c/openstack/networking-midonet/+/770797
-- Slawek Kaplonski Principal Software Engineer Red Hat
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE-----
wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----
-- Slawek Kaplonski Principal Software Engineer Red Hat
Le lun. 29 mars 2021 à 15:54, Ghanshyam Mann <gmann@ghanshyammann.com> a écrit :
On Mon, Mar 29, 2021 at 8:07 PM Slawek Kaplonski <skaplons@redhat.com> wrote:
Hi,
On Mon, Mar 29, 2021 at 11:52:59AM +0200, Herve Beraud wrote:
Hello,
The main question is, does the previous Victoria version [1] will be compatible with the latest neutron changes and with the latest
engine
facade introduced during Wallaby?
It won't be compatible. Networking-midonet from Victoria will not work properly with Neutron Wallaby.
Releasing an unfixed engine facade code is useless, so we shouldn't
release
a new version of networking-midonet, because the project code won't be compatible with the rest of our projects (AFAIK neutron), unless,
previous version will not compatible either, and, unless, not releasing a Wallaby version leave the project branch uncut and so leave the corresponding series unmaintainable, and so unfixable a posteriori.
If we do not release a new version then we will use a previous version of networking-midonet. This version will be the last Victoria version [1].
I suppose that this version (the victoria version) isn't compatible with the new facade engine either, isn't it?
Correct. It's not compatible.
So release or not release a new version won't solve the facade
engine
problem, isn't?
Yes.
You said that neutron evolved and networking-midonet didn't, hence
even if
we release networking-midonet in the current state it will fail too, isn't it?
Also yes :)
However, releasing a new version and branching on it can give you
---- On Mon, 29 Mar 2021 06:14:06 -0500 Akihiro Motoki <amotoki@gmail.com> wrote ---- the the
needed maintenance window to allow you to fix the issue later, when your gates will be fixed and then patches backported. git tags are cheap.
We should notice that since Victoria some patches have been merged in Wallaby so even if they aren't ground breaking changes they are changes that it is worth to release.
From a release point of view I think it's worth it to release a new version and to cut Wallaby. We are close to the it's deadline. That will land the available delta between Victoria and Wallaby. That will allow to fix the engine facade by opening a maintenance window. If the project is still lacking maintainers in a few weeks / months, this will allow a more smooth deprecation of this one.
Thoughts?
Based on Your feedback I agree that we should release now what we have. Even if it's broken we can then fix it and backport fixes to stable/wallaby branch.
@Akihiro: are You ok with that too?
I was writing another reply and did not notice this mail. While I still have a doubt on releasing the broken code (which we are not sure can be fixed soon or not), I am okay with either decision.
Yeah, releasing broken code and especially where we do not if there will be maintainer to fix it or not seems risky for me too.
One option is to deprecate it for wallaby which means follow the deprecation steps mentioned in project-team-guide[1]. If maintainers show up then it can be un-deprecated. With that, we will not have any compatible wallaby version which I think is a better choice than releasing the broken code.
If the team agrees with that I really prefer this approach.
Releasing the broken code now with the hope of someone will come up and fix it with backport makes me a little uncomfortable and if it did not get fix then we will live with broken release forever.
[1] https://docs.openstack.org/project-team-guide/repository.html#deprecating-a-...
-gmann
[1]
Le lun. 29 mars 2021 à 10:32, Slawek Kaplonski <skaplons@redhat.com>
a
écrit :
Hi,
We have opened release patch for networking-midonet [1] but our concern about that project is that its gate is completly broken since some time
don't really know if the project is still working and valid to be released. In Wallaby cycle Neutron for example finished transition to the engine facade, and patch to adjust that in networking-midonet is still opened [2] (and red as there were some unrelated issues with most of the jobs there).
In the past we had discussion about networking-midonet project and it's status as the official Neutron stadium project. Then some new folks stepped in to maintain it but now it seems a bit like (again) it lacks of
I know that it is very late in the cycle now so my question to
https://opendev.org/openstack/releases/src/branch/master/deliverables/victor... thus we maintainers. the TC and
release teams is: should we release stable/wallaby with its current state, even if it's broken or should we maybe don't release it at all until its gate will be up and running?
[1] https://review.opendev.org/c/openstack/releases/+/781713 [2] https://review.opendev.org/c/openstack/networking-midonet/+/770797
-- Slawek Kaplonski Principal Software Engineer Red Hat
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE-----
wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----
-- Slawek Kaplonski Principal Software Engineer Red Hat
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----
Hi, On Mon, Mar 29, 2021 at 08:53:58AM -0500, Ghanshyam Mann wrote:
---- On Mon, 29 Mar 2021 06:14:06 -0500 Akihiro Motoki <amotoki@gmail.com> wrote ----
On Mon, Mar 29, 2021 at 8:07 PM Slawek Kaplonski <skaplons@redhat.com> wrote:
Hi,
On Mon, Mar 29, 2021 at 11:52:59AM +0200, Herve Beraud wrote:
Hello,
The main question is, does the previous Victoria version [1] will be compatible with the latest neutron changes and with the latest engine facade introduced during Wallaby?
It won't be compatible. Networking-midonet from Victoria will not work properly with Neutron Wallaby.
Releasing an unfixed engine facade code is useless, so we shouldn't release a new version of networking-midonet, because the project code won't be compatible with the rest of our projects (AFAIK neutron), unless, the previous version will not compatible either, and, unless, not releasing a Wallaby version leave the project branch uncut and so leave the corresponding series unmaintainable, and so unfixable a posteriori.
If we do not release a new version then we will use a previous version of networking-midonet. This version will be the last Victoria version [1].
I suppose that this version (the victoria version) isn't compatible with the new facade engine either, isn't it?
Correct. It's not compatible.
So release or not release a new version won't solve the facade engine problem, isn't?
Yes.
You said that neutron evolved and networking-midonet didn't, hence even if we release networking-midonet in the current state it will fail too, isn't it?
Also yes :)
However, releasing a new version and branching on it can give you the needed maintenance window to allow you to fix the issue later, when your gates will be fixed and then patches backported. git tags are cheap.
We should notice that since Victoria some patches have been merged in Wallaby so even if they aren't ground breaking changes they are changes that it is worth to release.
From a release point of view I think it's worth it to release a new version and to cut Wallaby. We are close to the it's deadline. That will land the available delta between Victoria and Wallaby. That will allow to fix the engine facade by opening a maintenance window. If the project is still lacking maintainers in a few weeks / months, this will allow a more smooth deprecation of this one.
Thoughts?
Based on Your feedback I agree that we should release now what we have. Even if it's broken we can then fix it and backport fixes to stable/wallaby branch.
@Akihiro: are You ok with that too?
I was writing another reply and did not notice this mail. While I still have a doubt on releasing the broken code (which we are not sure can be fixed soon or not), I am okay with either decision.
Yeah, releasing broken code and especially where we do not if there will be maintainer to fix it or not seems risky for me too.
One option is to deprecate it for wallaby which means follow the deprecation steps mentioned in project-team-guide[1]. If maintainers show up then it can be un-deprecated. With that, we will not have any compatible wallaby version which I think is a better choice than releasing the broken code.
We were asking about that some time ago already and then some new maintainers stepped in. But as now there is that problem again with networking-midonet I'm fine to deprecate it (or ask about it again at least). But isn't it too late in the cycle now? Last time when we were doing that it was before milestone-2 IIRC. Now we are almost at the end of the cycle. Should we do it still now? If yes, how much time do we really have to e.g. ask for some new maintainers?
Releasing the broken code now with the hope of someone will come up and fix it with backport makes me a little uncomfortable and if it did not get fix then we will live with broken release forever.
[1]https://docs.openstack.org/project-team-guide/repository.html#deprecating-a-...
-gmann
[1] https://opendev.org/openstack/releases/src/branch/master/deliverables/victor...
Le lun. 29 mars 2021 à 10:32, Slawek Kaplonski <skaplons@redhat.com> a écrit :
Hi,
We have opened release patch for networking-midonet [1] but our concern about that project is that its gate is completly broken since some time thus we don't really know if the project is still working and valid to be released. In Wallaby cycle Neutron for example finished transition to the engine facade, and patch to adjust that in networking-midonet is still opened [2] (and red as there were some unrelated issues with most of the jobs there).
In the past we had discussion about networking-midonet project and it's status as the official Neutron stadium project. Then some new folks stepped in to maintain it but now it seems a bit like (again) it lacks of maintainers. I know that it is very late in the cycle now so my question to the TC and release teams is: should we release stable/wallaby with its current state, even if it's broken or should we maybe don't release it at all until its gate will be up and running?
[1] https://review.opendev.org/c/openstack/releases/+/781713 [2] https://review.opendev.org/c/openstack/networking-midonet/+/770797
-- Slawek Kaplonski Principal Software Engineer Red Hat
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE-----
wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----
-- Slawek Kaplonski Principal Software Engineer Red Hat
-- Slawek Kaplonski Principal Software Engineer Red Hat
---- On Mon, 29 Mar 2021 09:26:31 -0500 Slawek Kaplonski <skaplons@redhat.com> wrote ----
Hi,
On Mon, Mar 29, 2021 at 08:53:58AM -0500, Ghanshyam Mann wrote:
---- On Mon, 29 Mar 2021 06:14:06 -0500 Akihiro Motoki <amotoki@gmail.com> wrote ----
On Mon, Mar 29, 2021 at 8:07 PM Slawek Kaplonski <skaplons@redhat.com> wrote:
Hi,
On Mon, Mar 29, 2021 at 11:52:59AM +0200, Herve Beraud wrote:
Hello,
The main question is, does the previous Victoria version [1] will be compatible with the latest neutron changes and with the latest engine facade introduced during Wallaby?
It won't be compatible. Networking-midonet from Victoria will not work properly with Neutron Wallaby.
Releasing an unfixed engine facade code is useless, so we shouldn't release a new version of networking-midonet, because the project code won't be compatible with the rest of our projects (AFAIK neutron), unless, the previous version will not compatible either, and, unless, not releasing a Wallaby version leave the project branch uncut and so leave the corresponding series unmaintainable, and so unfixable a posteriori.
If we do not release a new version then we will use a previous version of networking-midonet. This version will be the last Victoria version [1].
I suppose that this version (the victoria version) isn't compatible with the new facade engine either, isn't it?
Correct. It's not compatible.
So release or not release a new version won't solve the facade engine problem, isn't?
Yes.
You said that neutron evolved and networking-midonet didn't, hence even if we release networking-midonet in the current state it will fail too, isn't it?
Also yes :)
However, releasing a new version and branching on it can give you the needed maintenance window to allow you to fix the issue later, when your gates will be fixed and then patches backported. git tags are cheap.
We should notice that since Victoria some patches have been merged in Wallaby so even if they aren't ground breaking changes they are changes that it is worth to release.
From a release point of view I think it's worth it to release a new version and to cut Wallaby. We are close to the it's deadline. That will land the available delta between Victoria and Wallaby. That will allow to fix the engine facade by opening a maintenance window. If the project is still lacking maintainers in a few weeks / months, this will allow a more smooth deprecation of this one.
Thoughts?
Based on Your feedback I agree that we should release now what we have. Even if it's broken we can then fix it and backport fixes to stable/wallaby branch.
@Akihiro: are You ok with that too?
I was writing another reply and did not notice this mail. While I still have a doubt on releasing the broken code (which we are not sure can be fixed soon or not), I am okay with either decision.
Yeah, releasing broken code and especially where we do not if there will be maintainer to fix it or not seems risky for me too.
One option is to deprecate it for wallaby which means follow the deprecation steps mentioned in project-team-guide[1]. If maintainers show up then it can be un-deprecated. With that, we will not have any compatible wallaby version which I think is a better choice than releasing the broken code.
We were asking about that some time ago already and then some new maintainers stepped in. But as now there is that problem again with networking-midonet I'm fine to deprecate it (or ask about it again at least). But isn't it too late in the cycle now? Last time when we were doing that it was before milestone-2 IIRC. Now we are almost at the end of the cycle. Should we do it still now?
As there is nothing released for Wallaby[1], we can still do this. As per the process, TC can merge the required patches on that repo if no core is available to +A.
If yes, how much time do we really have to e.g. ask for some new maintainers?
I will say asap :) but I think the release team can set the deadline as they have to take care of release things. [1] https://opendev.org/openstack/releases/src/commit/30492c964f5d7eb85d806086c5... -gmann
Releasing the broken code now with the hope of someone will come up and fix it with backport makes me a little uncomfortable and if it did not get fix then we will live with broken release forever.
[1]https://docs.openstack.org/project-team-guide/repository.html#deprecating-a-...
-gmann
[1] https://opendev.org/openstack/releases/src/branch/master/deliverables/victor...
Le lun. 29 mars 2021 à 10:32, Slawek Kaplonski <skaplons@redhat.com> a écrit :
Hi,
We have opened release patch for networking-midonet [1] but our concern about that project is that its gate is completly broken since some time thus we don't really know if the project is still working and valid to be released. In Wallaby cycle Neutron for example finished transition to the engine facade, and patch to adjust that in networking-midonet is still opened [2] (and red as there were some unrelated issues with most of the jobs there).
In the past we had discussion about networking-midonet project and it's status as the official Neutron stadium project. Then some new folks stepped in to maintain it but now it seems a bit like (again) it lacks of maintainers. I know that it is very late in the cycle now so my question to the TC and release teams is: should we release stable/wallaby with its current state, even if it's broken or should we maybe don't release it at all until its gate will be up and running?
[1] https://review.opendev.org/c/openstack/releases/+/781713 [2] https://review.opendev.org/c/openstack/networking-midonet/+/770797
-- Slawek Kaplonski Principal Software Engineer Red Hat
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE-----
wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----
-- Slawek Kaplonski Principal Software Engineer Red Hat
-- Slawek Kaplonski Principal Software Engineer Red Hat
If we decide to follow the depreciation process we can wait until tomorrow or Wednesday early in the morning. Le lun. 29 mars 2021 à 16:52, Ghanshyam Mann <gmann@ghanshyammann.com> a écrit :
Hi,
On Mon, Mar 29, 2021 at 08:53:58AM -0500, Ghanshyam Mann wrote:
---- On Mon, 29 Mar 2021 06:14:06 -0500 Akihiro Motoki < amotoki@gmail.com> wrote ----
On Mon, Mar 29, 2021 at 8:07 PM Slawek Kaplonski < skaplons@redhat.com> wrote:
Hi,
On Mon, Mar 29, 2021 at 11:52:59AM +0200, Herve Beraud wrote:
Hello,
The main question is, does the previous Victoria version [1]
will be
compatible with the latest neutron changes and with the latest engine facade introduced during Wallaby?
It won't be compatible. Networking-midonet from Victoria will not work properly with Neutron Wallaby.
Releasing an unfixed engine facade code is useless, so we
shouldn't release
a new version of networking-midonet, because the project code won't be compatible with the rest of our projects (AFAIK neutron), unless, the previous version will not compatible either, and, unless, not releasing a Wallaby version leave the project branch uncut and so leave the corresponding series unmaintainable, and so unfixable a
If we do not release a new version then we will use a previous
version of
networking-midonet. This version will be the last Victoria version [1].
I suppose that this version (the victoria version) isn't compatible with the new facade engine either, isn't it?
Correct. It's not compatible.
So release or not release a new version won't solve the facade
engine
problem, isn't?
Yes.
You said that neutron evolved and networking-midonet didn't,
hence even if
we release networking-midonet in the current state it will fail too, isn't it?
Also yes :)
However, releasing a new version and branching on it can give
you the
needed maintenance window to allow you to fix the issue later, when your gates will be fixed and then patches backported. git tags are cheap.
We should notice that since Victoria some patches have been merged in Wallaby so even if they aren't ground breaking changes they are changes that it is worth to release.
From a release point of view I think it's worth it to release a new version and to cut Wallaby. We are close to the it's deadline. That will land the available delta between Victoria and Wallaby. That will allow to fix the engine facade by opening a maintenance window. If the project is still lacking maintainers in a few weeks / months, this will allow a more smooth deprecation of this one.
Thoughts?
Based on Your feedback I agree that we should release now what we have. Even if it's broken we can then fix it and backport fixes to stable/wallaby branch.
@Akihiro: are You ok with that too?
I was writing another reply and did not notice this mail. While I still have a doubt on releasing the broken code (which we are not sure can be fixed soon or not), I am okay with either decision.
Yeah, releasing broken code and especially where we do not if there will be maintainer to fix it or not seems risky for me too.
One option is to deprecate it for wallaby which means follow the deprecation steps mentioned in project-team-guide[1]. If maintainers show up then it can be un-deprecated. With that, we will not have any compatible wallaby version which I
choice than releasing the broken code.
We were asking about that some time ago already and then some new
stepped in. But as now there is that problem again with networking-midonet I'm fine to deprecate it (or ask about it again at least). But isn't it too late in the cycle now? Last time when we were doing
---- On Mon, 29 Mar 2021 09:26:31 -0500 Slawek Kaplonski < skaplons@redhat.com> wrote ---- posteriori. think is a better maintainers that it was
before milestone-2 IIRC. Now we are almost at the end of the cycle. Should we do it still now?
As there is nothing released for Wallaby[1], we can still do this. As per the process, TC can merge the required patches on that repo if no core is available to +A.
If yes, how much time do we really have to e.g. ask for some new maintainers?
I will say asap :) but I think the release team can set the deadline as they have to take care of release things.
[1] https://opendev.org/openstack/releases/src/commit/30492c964f5d7eb85d806086c5...
-gmann
Releasing the broken code now with the hope of someone will come up
backport makes me a little uncomfortable and if it did not get fix
with broken release forever.
[1] https://docs.openstack.org/project-team-guide/repository.html#deprecating-a-...
-gmann
[1]
https://opendev.org/openstack/releases/src/branch/master/deliverables/victor...
Le lun. 29 mars 2021 à 10:32, Slawek Kaplonski <
skaplons@redhat.com> a
écrit :
> Hi, > > We have opened release patch for networking-midonet [1] but our concern > about > that project is that its gate is completly broken since some time thus we > don't really know if the project is still working and valid to be released. > In Wallaby cycle Neutron for example finished transition to
> facade, > and patch to adjust that in networking-midonet is still opened [2] (and > red as > there were some unrelated issues with most of the jobs
> > In the past we had discussion about networking-midonet
> status > as the official Neutron stadium project. Then some new folks stepped in to > maintain it but now it seems a bit like (again) it lacks of
and fix it with then we will live the engine there). project and it's maintainers.
> I know that it is very late in the cycle now so my question to the TC and > release teams is: should we release stable/wallaby with its current state, > even if it's broken or should we maybe don't release it at all until its > gate > will be up and running? > > [1] https://review.opendev.org/c/openstack/releases/+/781713 > [2] https://review.opendev.org/c/openstack/networking-midonet/+/770797 > > -- > Slawek Kaplonski > Principal Software Engineer > Red Hat
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE-----
wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+
Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+
RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP
F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G
5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g
glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw
m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ
hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0
qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y
F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3
B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O
v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----
-- Slawek Kaplonski Principal Software Engineer Red Hat
-- Slawek Kaplonski Principal Software Engineer Red Hat
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----
Hi, On Mon, Mar 29, 2021 at 05:07:15PM +0200, Herve Beraud wrote:
If we decide to follow the depreciation process we can wait until tomorrow or Wednesday early in the morning.
I also pinged Sam Morrison and YAMAMOTO Takashi about that today. If I will not have any reply from them until tomorrow morning CEST time, I will propose patches to deprecate it in this cycle.
Le lun. 29 mars 2021 à 16:52, Ghanshyam Mann <gmann@ghanshyammann.com> a écrit :
Hi,
On Mon, Mar 29, 2021 at 08:53:58AM -0500, Ghanshyam Mann wrote:
---- On Mon, 29 Mar 2021 06:14:06 -0500 Akihiro Motoki < amotoki@gmail.com> wrote ----
On Mon, Mar 29, 2021 at 8:07 PM Slawek Kaplonski < skaplons@redhat.com> wrote:
Hi,
On Mon, Mar 29, 2021 at 11:52:59AM +0200, Herve Beraud wrote: > Hello, > > The main question is, does the previous Victoria version [1]
will be
> compatible with the latest neutron changes and with the latest engine > facade introduced during Wallaby?
It won't be compatible. Networking-midonet from Victoria will not work properly with Neutron Wallaby.
> > Releasing an unfixed engine facade code is useless, so we shouldn't release > a new version of networking-midonet, because the project code won't be > compatible with the rest of our projects (AFAIK neutron), unless, the > previous version will not compatible either, and, unless, not releasing a > Wallaby version leave the project branch uncut and so leave the > corresponding series unmaintainable, and so unfixable a
> > If we do not release a new version then we will use a previous version of > networking-midonet. This version will be the last Victoria version [1]. > > I suppose that this version (the victoria version) isn't compatible with > the new facade engine either, isn't it?
Correct. It's not compatible.
> > So release or not release a new version won't solve the facade engine > problem, isn't?
Yes.
> > You said that neutron evolved and networking-midonet didn't, hence even if > we release networking-midonet in the current state it will fail too, isn't > it?
Also yes :)
> > However, releasing a new version and branching on it can give you the > needed maintenance window to allow you to fix the issue later, when your > gates will be fixed and then patches backported. git tags are cheap. > > We should notice that since Victoria some patches have been merged in > Wallaby so even if they aren't ground breaking changes they are changes > that it is worth to release. > > From a release point of view I think it's worth it to release a new version > and to cut Wallaby. We are close to the it's deadline. That will land the > available delta between Victoria and Wallaby. That will allow to fix the > engine facade by opening a maintenance window. If the project is still > lacking maintainers in a few weeks / months, this will allow a more smooth > deprecation of this one. > > Thoughts?
Based on Your feedback I agree that we should release now what we have. Even if it's broken we can then fix it and backport fixes to stable/wallaby branch.
@Akihiro: are You ok with that too?
I was writing another reply and did not notice this mail. While I still have a doubt on releasing the broken code (which we are not sure can be fixed soon or not), I am okay with either decision.
Yeah, releasing broken code and especially where we do not if there will be maintainer to fix it or not seems risky for me too.
One option is to deprecate it for wallaby which means follow the deprecation steps mentioned in project-team-guide[1]. If maintainers show up then it can be un-deprecated. With that, we will not have any compatible wallaby version which I
choice than releasing the broken code.
We were asking about that some time ago already and then some new
stepped in. But as now there is that problem again with networking-midonet I'm fine to deprecate it (or ask about it again at least). But isn't it too late in the cycle now? Last time when we were doing
---- On Mon, 29 Mar 2021 09:26:31 -0500 Slawek Kaplonski < skaplons@redhat.com> wrote ---- posteriori. think is a better maintainers that it was
before milestone-2 IIRC. Now we are almost at the end of the cycle. Should we do it still now?
As there is nothing released for Wallaby[1], we can still do this. As per the process, TC can merge the required patches on that repo if no core is available to +A.
If yes, how much time do we really have to e.g. ask for some new maintainers?
I will say asap :) but I think the release team can set the deadline as they have to take care of release things.
[1] https://opendev.org/openstack/releases/src/commit/30492c964f5d7eb85d806086c5...
-gmann
Releasing the broken code now with the hope of someone will come up
backport makes me a little uncomfortable and if it did not get fix
with broken release forever.
[1] https://docs.openstack.org/project-team-guide/repository.html#deprecating-a-...
-gmann
> > [1] >
https://opendev.org/openstack/releases/src/branch/master/deliverables/victor...
> > Le lun. 29 mars 2021 à 10:32, Slawek Kaplonski < skaplons@redhat.com> a > écrit : > > > Hi, > > > > We have opened release patch for networking-midonet [1] but our concern > > about > > that project is that its gate is completly broken since some time thus we > > don't really know if the project is still working and valid to be released. > > In Wallaby cycle Neutron for example finished transition to
> > facade, > > and patch to adjust that in networking-midonet is still opened [2] (and > > red as > > there were some unrelated issues with most of the jobs
> > > > In the past we had discussion about networking-midonet
> > status > > as the official Neutron stadium project. Then some new folks stepped in to > > maintain it but now it seems a bit like (again) it lacks of
and fix it with then we will live the engine there). project and it's maintainers.
> > I know that it is very late in the cycle now so my question to the TC and > > release teams is: should we release stable/wallaby with its current state, > > even if it's broken or should we maybe don't release it at all until its > > gate > > will be up and running? > > > > [1] https://review.opendev.org/c/openstack/releases/+/781713 > > [2] https://review.opendev.org/c/openstack/networking-midonet/+/770797 > > > > -- > > Slawek Kaplonski > > Principal Software Engineer > > Red Hat > > > > -- > Hervé Beraud > Senior Software Engineer at Red Hat > irc: hberaud > https://github.com/4383/ > https://twitter.com/4383hberaud > -----BEGIN PGP SIGNATURE----- > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > v6rDpkeNksZ9fFSyoY2o > =ECSj > -----END PGP SIGNATURE-----
-- Slawek Kaplonski Principal Software Engineer Red Hat
-- Slawek Kaplonski Principal Software Engineer Red Hat
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE-----
wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----
-- Slawek Kaplonski Principal Software Engineer Red Hat
Excellent! Thank you Slavek. Le lun. 29 mars 2021 à 17:15, Slawek Kaplonski <skaplons@redhat.com> a écrit :
Hi,
On Mon, Mar 29, 2021 at 05:07:15PM +0200, Herve Beraud wrote:
If we decide to follow the depreciation process we can wait until tomorrow or Wednesday early in the morning.
I also pinged Sam Morrison and YAMAMOTO Takashi about that today. If I will not have any reply from them until tomorrow morning CEST time, I will propose patches to deprecate it in this cycle.
Le lun. 29 mars 2021 à 16:52, Ghanshyam Mann <gmann@ghanshyammann.com> a écrit :
---- On Mon, 29 Mar 2021 09:26:31 -0500 Slawek Kaplonski < skaplons@redhat.com> wrote ----
Hi,
On Mon, Mar 29, 2021 at 08:53:58AM -0500, Ghanshyam Mann wrote:
---- On Mon, 29 Mar 2021 06:14:06 -0500 Akihiro Motoki < amotoki@gmail.com> wrote ----
On Mon, Mar 29, 2021 at 8:07 PM Slawek Kaplonski < skaplons@redhat.com> wrote: > > Hi, > > On Mon, Mar 29, 2021 at 11:52:59AM +0200, Herve Beraud wrote: > > Hello, > > > > The main question is, does the previous Victoria version
> > compatible with the latest neutron changes and with the latest engine > > facade introduced during Wallaby? > > It won't be compatible. Networking-midonet from Victoria will not work properly > with Neutron Wallaby. > > > > > Releasing an unfixed engine facade code is useless, so we shouldn't release > > a new version of networking-midonet, because the project code won't be > > compatible with the rest of our projects (AFAIK neutron), unless, the > > previous version will not compatible either, and, unless, not releasing a > > Wallaby version leave the project branch uncut and so leave the > > corresponding series unmaintainable, and so unfixable a
will be posteriori.
> > > > If we do not release a new version then we will use a
version of
> > networking-midonet. This version will be the last Victoria version [1]. > > > > I suppose that this version (the victoria version) isn't compatible with > > the new facade engine either, isn't it? > > Correct. It's not compatible. > > > > > So release or not release a new version won't solve the facade engine > > problem, isn't? > > Yes. > > > > > You said that neutron evolved and networking-midonet didn't, hence even if > > we release networking-midonet in the current state it will fail too, isn't > > it? > > Also yes :) > > > > > However, releasing a new version and branching on it can give you the > > needed maintenance window to allow you to fix the issue later, when your > > gates will be fixed and then patches backported. git tags are cheap. > > > > We should notice that since Victoria some patches have been merged in > > Wallaby so even if they aren't ground breaking changes they are changes > > that it is worth to release. > > > > From a release point of view I think it's worth it to release a new version > > and to cut Wallaby. We are close to the it's deadline. That will land the > > available delta between Victoria and Wallaby. That will allow to fix the > > engine facade by opening a maintenance window. If the
is still
> > lacking maintainers in a few weeks / months, this will allow a more smooth > > deprecation of this one. > > > > Thoughts? > > Based on Your feedback I agree that we should release now what we have. Even if > it's broken we can then fix it and backport fixes to stable/wallaby branch. > > @Akihiro: are You ok with that too?
I was writing another reply and did not notice this mail. While I still have a doubt on releasing the broken code (which we are not sure can be fixed soon or not), I am okay with either decision.
Yeah, releasing broken code and especially where we do not if
maintainer to fix it or not seems risky for me too.
One option is to deprecate it for wallaby which means follow the deprecation steps mentioned in project-team-guide[1]. If maintainers show up then it can be un-deprecated. With that, we will not have any compatible wallaby version which I
choice than releasing the broken code.
We were asking about that some time ago already and then some new
stepped in. But as now there is that problem again with networking-midonet I'm fine to deprecate it (or ask about it again at least). But isn't it too late in the cycle now? Last time when we were doing
will be think is a better maintainers that it was
before milestone-2 IIRC. Now we are almost at the end of the cycle. Should we do it still now?
As there is nothing released for Wallaby[1], we can still do this. As
[1] previous project there per
the process, TC can merge the required patches on that repo if no core is available to +A.
If yes, how much time do we really have to e.g. ask for some new maintainers?
I will say asap :) but I think the release team can set the deadline as they have to take care of release things.
[1]
https://opendev.org/openstack/releases/src/commit/30492c964f5d7eb85d806086c5...
-gmann
Releasing the broken code now with the hope of someone will come
up
backport makes me a little uncomfortable and if it did not get fix
and fix it with then we will live
with broken release forever.
[1]
https://docs.openstack.org/project-team-guide/repository.html#deprecating-a-...
-gmann
> > > > > [1] > >
https://opendev.org/openstack/releases/src/branch/master/deliverables/victor...
> > > > Le lun. 29 mars 2021 à 10:32, Slawek Kaplonski < skaplons@redhat.com> a > > écrit : > > > > > Hi, > > > > > > We have opened release patch for networking-midonet [1] but our concern > > > about > > > that project is that its gate is completly broken since some time thus we > > > don't really know if the project is still working and valid to be released. > > > In Wallaby cycle Neutron for example finished transition to the engine > > > facade, > > > and patch to adjust that in networking-midonet is still opened [2] (and > > > red as > > > there were some unrelated issues with most of the jobs there). > > > > > > In the past we had discussion about networking-midonet project and it's > > > status > > > as the official Neutron stadium project. Then some new folks stepped in to > > > maintain it but now it seems a bit like (again) it lacks of maintainers. > > > I know that it is very late in the cycle now so my question to the TC and > > > release teams is: should we release stable/wallaby with its current state, > > > even if it's broken or should we maybe don't release it at all until its > > > gate > > > will be up and running? > > > > > > [1] https://review.opendev.org/c/openstack/releases/+/781713 > > > [2] https://review.opendev.org/c/openstack/networking-midonet/+/770797 > > > > > > -- > > > Slawek Kaplonski > > > Principal Software Engineer > > > Red Hat > > > > > > > > -- > > Hervé Beraud > > Senior Software Engineer at Red Hat > > irc: hberaud > > https://github.com/4383/ > > https://twitter.com/4383hberaud > > -----BEGIN PGP SIGNATURE----- > > > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > > v6rDpkeNksZ9fFSyoY2o > > =ECSj > > -----END PGP SIGNATURE----- > > -- > Slawek Kaplonski > Principal Software Engineer > Red Hat
-- Slawek Kaplonski Principal Software Engineer Red Hat
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE-----
wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----
-- Slawek Kaplonski Principal Software Engineer Red Hat
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----
Hi, As Takashi told me that he will not have time to work on this anytime soon and I don't get any info from Sam, I just proposed patches to deprecate networking-midonet project [1]. I know that it's very late in the cycle but I think that this will be the best to do based on current circumstances and discussion in this thread. [1] https://review.opendev.org/q/topic:%22deprecate-networking-midonet%22+(statu...) On Mon, Mar 29, 2021 at 05:23:25PM +0200, Herve Beraud wrote:
Excellent! Thank you Slavek.
Le lun. 29 mars 2021 à 17:15, Slawek Kaplonski <skaplons@redhat.com> a écrit :
Hi,
On Mon, Mar 29, 2021 at 05:07:15PM +0200, Herve Beraud wrote:
If we decide to follow the depreciation process we can wait until tomorrow or Wednesday early in the morning.
I also pinged Sam Morrison and YAMAMOTO Takashi about that today. If I will not have any reply from them until tomorrow morning CEST time, I will propose patches to deprecate it in this cycle.
Le lun. 29 mars 2021 à 16:52, Ghanshyam Mann <gmann@ghanshyammann.com> a écrit :
---- On Mon, 29 Mar 2021 09:26:31 -0500 Slawek Kaplonski < skaplons@redhat.com> wrote ----
Hi,
On Mon, Mar 29, 2021 at 08:53:58AM -0500, Ghanshyam Mann wrote:
---- On Mon, 29 Mar 2021 06:14:06 -0500 Akihiro Motoki < amotoki@gmail.com> wrote ---- > On Mon, Mar 29, 2021 at 8:07 PM Slawek Kaplonski < skaplons@redhat.com> wrote: > > > > Hi, > > > > On Mon, Mar 29, 2021 at 11:52:59AM +0200, Herve Beraud wrote: > > > Hello, > > > > > > The main question is, does the previous Victoria version
> > > compatible with the latest neutron changes and with the latest engine > > > facade introduced during Wallaby? > > > > It won't be compatible. Networking-midonet from Victoria will not work properly > > with Neutron Wallaby. > > > > > > > > Releasing an unfixed engine facade code is useless, so we shouldn't release > > > a new version of networking-midonet, because the project code won't be > > > compatible with the rest of our projects (AFAIK neutron), unless, the > > > previous version will not compatible either, and, unless, not releasing a > > > Wallaby version leave the project branch uncut and so leave the > > > corresponding series unmaintainable, and so unfixable a
will be posteriori.
> > > > > > If we do not release a new version then we will use a
version of
> > > networking-midonet. This version will be the last Victoria version [1]. > > > > > > I suppose that this version (the victoria version) isn't compatible with > > > the new facade engine either, isn't it? > > > > Correct. It's not compatible. > > > > > > > > So release or not release a new version won't solve the facade engine > > > problem, isn't? > > > > Yes. > > > > > > > > You said that neutron evolved and networking-midonet didn't, hence even if > > > we release networking-midonet in the current state it will fail too, isn't > > > it? > > > > Also yes :) > > > > > > > > However, releasing a new version and branching on it can give you the > > > needed maintenance window to allow you to fix the issue later, when your > > > gates will be fixed and then patches backported. git tags are cheap. > > > > > > We should notice that since Victoria some patches have been merged in > > > Wallaby so even if they aren't ground breaking changes they are changes > > > that it is worth to release. > > > > > > From a release point of view I think it's worth it to release a new version > > > and to cut Wallaby. We are close to the it's deadline. That will land the > > > available delta between Victoria and Wallaby. That will allow to fix the > > > engine facade by opening a maintenance window. If the
is still
> > > lacking maintainers in a few weeks / months, this will allow a more smooth > > > deprecation of this one. > > > > > > Thoughts? > > > > Based on Your feedback I agree that we should release now what we have. Even if > > it's broken we can then fix it and backport fixes to stable/wallaby branch. > > > > @Akihiro: are You ok with that too? > > I was writing another reply and did not notice this mail. > While I still have a doubt on releasing the broken code (which we are > not sure can be fixed soon or not), > I am okay with either decision.
Yeah, releasing broken code and especially where we do not if
maintainer to fix it or not seems risky for me too.
One option is to deprecate it for wallaby which means follow the deprecation steps mentioned in project-team-guide[1]. If maintainers show up then it can be un-deprecated. With that, we will not have any compatible wallaby version which I
choice than releasing the broken code.
We were asking about that some time ago already and then some new
stepped in. But as now there is that problem again with networking-midonet I'm fine to deprecate it (or ask about it again at least). But isn't it too late in the cycle now? Last time when we were doing
will be think is a better maintainers that it was
before milestone-2 IIRC. Now we are almost at the end of the cycle. Should we do it still now?
As there is nothing released for Wallaby[1], we can still do this. As
[1] previous project there per
the process, TC can merge the required patches on that repo if no core is available to +A.
If yes, how much time do we really have to e.g. ask for some new maintainers?
I will say asap :) but I think the release team can set the deadline as they have to take care of release things.
[1]
https://opendev.org/openstack/releases/src/commit/30492c964f5d7eb85d806086c5...
-gmann
Releasing the broken code now with the hope of someone will come
up
backport makes me a little uncomfortable and if it did not get fix
and fix it with then we will live
with broken release forever.
[1]
https://docs.openstack.org/project-team-guide/repository.html#deprecating-a-...
-gmann
> > > > > > > > > [1] > > >
https://opendev.org/openstack/releases/src/branch/master/deliverables/victor...
> > > > > > Le lun. 29 mars 2021 à 10:32, Slawek Kaplonski < skaplons@redhat.com> a > > > écrit : > > > > > > > Hi, > > > > > > > > We have opened release patch for networking-midonet [1] but our concern > > > > about > > > > that project is that its gate is completly broken since some time thus we > > > > don't really know if the project is still working and valid to be released. > > > > In Wallaby cycle Neutron for example finished transition to the engine > > > > facade, > > > > and patch to adjust that in networking-midonet is still opened [2] (and > > > > red as > > > > there were some unrelated issues with most of the jobs there). > > > > > > > > In the past we had discussion about networking-midonet project and it's > > > > status > > > > as the official Neutron stadium project. Then some new folks stepped in to > > > > maintain it but now it seems a bit like (again) it lacks of maintainers. > > > > I know that it is very late in the cycle now so my question to the TC and > > > > release teams is: should we release stable/wallaby with its current state, > > > > even if it's broken or should we maybe don't release it at all until its > > > > gate > > > > will be up and running? > > > > > > > > [1] https://review.opendev.org/c/openstack/releases/+/781713 > > > > [2] https://review.opendev.org/c/openstack/networking-midonet/+/770797 > > > > > > > > -- > > > > Slawek Kaplonski > > > > Principal Software Engineer > > > > Red Hat > > > > > > > > > > > > -- > > > Hervé Beraud > > > Senior Software Engineer at Red Hat > > > irc: hberaud > > > https://github.com/4383/ > > > https://twitter.com/4383hberaud > > > -----BEGIN PGP SIGNATURE----- > > > > > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > > > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > > > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > > > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > > > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > > > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > > > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > > > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > > > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > > > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > > > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > > > v6rDpkeNksZ9fFSyoY2o > > > =ECSj > > > -----END PGP SIGNATURE----- > > > > -- > > Slawek Kaplonski > > Principal Software Engineer > > Red Hat > >
-- Slawek Kaplonski Principal Software Engineer Red Hat
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE-----
wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----
-- Slawek Kaplonski Principal Software Engineer Red Hat
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE-----
wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----
-- Slawek Kaplonski Principal Software Engineer Red Hat
Accordingly to our choice, I updated the release patch. https://review.opendev.org/c/openstack/releases/+/781713 Thanks Slawek. Le mar. 30 mars 2021 à 09:04, Slawek Kaplonski <skaplons@redhat.com> a écrit :
Hi,
As Takashi told me that he will not have time to work on this anytime soon and I don't get any info from Sam, I just proposed patches to deprecate networking-midonet project [1]. I know that it's very late in the cycle but I think that this will be the best to do based on current circumstances and discussion in this thread.
[1] https://review.opendev.org/q/topic:%22deprecate-networking-midonet%22+(statu...)
Excellent! Thank you Slavek.
Le lun. 29 mars 2021 à 17:15, Slawek Kaplonski <skaplons@redhat.com> a écrit :
Hi,
On Mon, Mar 29, 2021 at 05:07:15PM +0200, Herve Beraud wrote:
If we decide to follow the depreciation process we can wait until tomorrow or Wednesday early in the morning.
I also pinged Sam Morrison and YAMAMOTO Takashi about that today. If I will not have any reply from them until tomorrow morning CEST time, I will
patches to deprecate it in this cycle.
Le lun. 29 mars 2021 à 16:52, Ghanshyam Mann <
gmann@ghanshyammann.com> a
écrit :
---- On Mon, 29 Mar 2021 09:26:31 -0500 Slawek Kaplonski < skaplons@redhat.com> wrote ----
Hi,
On Mon, Mar 29, 2021 at 08:53:58AM -0500, Ghanshyam Mann wrote: > ---- On Mon, 29 Mar 2021 06:14:06 -0500 Akihiro Motoki < amotoki@gmail.com> wrote ---- > > On Mon, Mar 29, 2021 at 8:07 PM Slawek Kaplonski < skaplons@redhat.com> wrote: > > > > > > Hi, > > > > > > On Mon, Mar 29, 2021 at 11:52:59AM +0200, Herve Beraud wrote: > > > > Hello, > > > > > > > > The main question is, does the previous Victoria version [1] will be > > > > compatible with the latest neutron changes and with the latest engine > > > > facade introduced during Wallaby? > > > > > > It won't be compatible. Networking-midonet from Victoria will not work properly > > > with Neutron Wallaby. > > > > > > > > > > > Releasing an unfixed engine facade code is useless, so we shouldn't release > > > > a new version of networking-midonet, because the
> > > > compatible with the rest of our projects (AFAIK neutron), unless, the > > > > previous version will not compatible either, and, unless, not releasing a > > > > Wallaby version leave the project branch uncut and so leave the > > > > corresponding series unmaintainable, and so unfixable a
won't be posteriori.
> > > > > > > > If we do not release a new version then we will use a
code previous
version of
> > > > networking-midonet. This version will be the last Victoria version [1]. > > > > > > > > I suppose that this version (the victoria version) isn't compatible with > > > > the new facade engine either, isn't it? > > > > > > Correct. It's not compatible. > > > > > > > > > > > So release or not release a new version won't solve the facade engine > > > > problem, isn't? > > > > > > Yes. > > > > > > > > > > > You said that neutron evolved and networking-midonet didn't, hence even if > > > > we release networking-midonet in the current state it will fail too, isn't > > > > it? > > > > > > Also yes :) > > > > > > > > > > > However, releasing a new version and branching on it can give you the > > > > needed maintenance window to allow you to fix the issue later, when your > > > > gates will be fixed and then patches backported. git tags are cheap. > > > > > > > > We should notice that since Victoria some patches have been merged in > > > > Wallaby so even if they aren't ground breaking changes
> > > > that it is worth to release. > > > > > > > > From a release point of view I think it's worth it to release a new version > > > > and to cut Wallaby. We are close to the it's deadline. That will land the > > > > available delta between Victoria and Wallaby. That will allow to fix the > > > > engine facade by opening a maintenance window. If the
> > > > lacking maintainers in a few weeks / months, this will allow a more smooth > > > > deprecation of this one. > > > > > > > > Thoughts? > > > > > > Based on Your feedback I agree that we should release now what we have. Even if > > > it's broken we can then fix it and backport fixes to stable/wallaby branch. > > > > > > @Akihiro: are You ok with that too? > > > > I was writing another reply and did not notice this mail. > > While I still have a doubt on releasing the broken code (which we are > > not sure can be fixed soon or not), > > I am okay with either decision. > > Yeah, releasing broken code and especially where we do not if
are changes project is still there will be
> maintainer to fix it or not seems risky for me too. > > One option is to deprecate it for wallaby which means follow
deprecation steps
> mentioned in project-team-guide[1]. If maintainers show up
> With that, we will not have any compatible wallaby version which I
> choice than releasing the broken code.
We were asking about that some time ago already and then some new
stepped in. But as now there is that problem again with networking-midonet I'm fine to deprecate it (or ask about it again at least). But isn't it too late in the cycle now? Last time when we were doing
can be un-deprecated. think is a better maintainers that it was
before milestone-2 IIRC. Now we are almost at the end of the cycle. Should we do it still now?
As there is nothing released for Wallaby[1], we can still do this. As per the process, TC can merge the required patches on that repo if no core is available to +A.
If yes, how much time do we really have to e.g. ask for some new maintainers?
I will say asap :) but I think the release team can set the deadline as they have to take care of release things.
[1]
https://opendev.org/openstack/releases/src/commit/30492c964f5d7eb85d806086c5...
-gmann
> > Releasing the broken code now with the hope of someone will
come up
> backport makes me a little uncomfortable and if it did not get fix
and fix it with then we will live
> with broken release forever. > > > [1]
https://docs.openstack.org/project-team-guide/repository.html#deprecating-a-...
> > -gmann > > > > > > > > > > > > > > [1] > > > >
https://opendev.org/openstack/releases/src/branch/master/deliverables/victor...
> > > > > > > > Le lun. 29 mars 2021 à 10:32, Slawek Kaplonski < skaplons@redhat.com> a > > > > écrit : > > > > > > > > > Hi, > > > > > > > > > > We have opened release patch for networking-midonet [1] but our concern > > > > > about > > > > > that project is that its gate is completly broken since some time thus we > > > > > don't really know if the project is still working and valid to be released. > > > > > In Wallaby cycle Neutron for example finished
On Mon, Mar 29, 2021 at 05:23:25PM +0200, Herve Beraud wrote: propose project they the then it transition
to
> > > > > facade, > > > > > and patch to adjust that in networking-midonet is still opened [2] (and > > > > > red as > > > > > there were some unrelated issues with most of the jobs
> > > > > > > > > > In the past we had discussion about networking-midonet
> > > > > status > > > > > as the official Neutron stadium project. Then some new folks stepped in to > > > > > maintain it but now it seems a bit like (again) it lacks of
the engine there). project and it's maintainers.
> > > > > I know that it is very late in the cycle now so my question to the TC and > > > > > release teams is: should we release stable/wallaby with its current state, > > > > > even if it's broken or should we maybe don't release it at all until its > > > > > gate > > > > > will be up and running? > > > > > > > > > > [1] https://review.opendev.org/c/openstack/releases/+/781713 > > > > > [2] https://review.opendev.org/c/openstack/networking-midonet/+/770797 > > > > > > > > > > -- > > > > > Slawek Kaplonski > > > > > Principal Software Engineer > > > > > Red Hat > > > > > > > > > > > > > > > > -- > > > > Hervé Beraud > > > > Senior Software Engineer at Red Hat > > > > irc: hberaud > > > > https://github.com/4383/ > > > > https://twitter.com/4383hberaud > > > > -----BEGIN PGP SIGNATURE----- > > > > > > > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ > > > > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ > > > > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP > > > > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G > > > > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g > > > > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw > > > > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ > > > > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 > > > > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y > > > > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 > > > > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O > > > > v6rDpkeNksZ9fFSyoY2o > > > > =ECSj > > > > -----END PGP SIGNATURE----- > > > > > > -- > > > Slawek Kaplonski > > > Principal Software Engineer > > > Red Hat > > > > >
-- Slawek Kaplonski Principal Software Engineer Red Hat
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE-----
wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----
-- Slawek Kaplonski Principal Software Engineer Red Hat
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE-----
wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----
-- Slawek Kaplonski Principal Software Engineer Red Hat
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----
Le mar. 30 mars 2021 à 09:04, Slawek Kaplonski <skaplons@redhat.com> a écrit :
Hi,
As Takashi told me that he will not have time to work on this anytime soon and I don't get any info from Sam, I just proposed patches to deprecate networking-midonet project [1]. I know that it's very late in the cycle but I think that this will be the best to do based on current circumstances and discussion in this thread.
[1] https://review.opendev.org/q/topic:%22deprecate-networking-midonet%22+(statu...)
Accordingly to our choice, I updated the release patch. https://review.opendev.org/c/openstack/releases/+/781713 Thanks Slawek. -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----
Hi, On Mon, Mar 29, 2021 at 6:53 PM Herve Beraud <hberaud@redhat.com> wrote:
Hello,
The main question is, does the previous Victoria version [1] will be compatible with the latest neutron changes and with the latest engine facade introduced during Wallaby?
Releasing an unfixed engine facade code is useless, so we shouldn't release a new version of networking-midonet, because the project code won't be compatible with the rest of our projects (AFAIK neutron), unless, the previous version will not compatible either, and, unless, not releasing a Wallaby version leave the project branch uncut and so leave the corresponding series unmaintainable, and so unfixable a posteriori.
If we do not release a new version then we will use a previous version of networking-midonet. This version will be the last Victoria version [1].
I suppose that this version (the victoria version) isn't compatible with the new facade engine either, isn't it?
So release or not release a new version won't solve the facade engine problem, isn't?
You said that neutron evolved and networking-midonet didn't, hence even if we release networking-midonet in the current state it will fail too, isn't it?
Only folks involved in networking-midonet can answer these questions correctly, and other neutron folks do not run networking-midonet (and midonet). On the other hand, we know victoria release of some neutron related projects does not work with wallaby neutron and neutron-lib (at least for neutron-dynamic-routing and networking-bagpipe), so it is not surprising victoria networking-midonet does not work with wallaby neutron.
However, releasing a new version and branching on it can give you the needed maintenance window to allow you to fix the issue later, when your gates will be fixed and then patches backported. git tags are cheap.
It is true to some extent, but I am not sure the merit here is more than releasing the broken code (which we are not sure is not expected to fix soon) as the initial release of Wallaby.
We should notice that since Victoria some patches have been merged in Wallaby so even if they aren't ground breaking changes they are changes that it is worth to release.
No meaningful change happened in the main code after Victoria release. We have only two commits since Victoria. The one is related to the release note build which added stable/victoria. The other is a fix in the devstack plugin. Thus, I do not see a value at least from this point of view.
From a release point of view I think it's worth it to release a new version and to cut Wallaby. We are close to the it's deadline. That will land the available delta between Victoria and Wallaby. That will allow to fix the engine facade by opening a maintenance window. If the project is still lacking maintainers in a few weeks / months, this will allow a more smooth deprecation of this one.
Thoughts?
[1] https://opendev.org/openstack/releases/src/branch/master/deliverables/victor...
Le lun. 29 mars 2021 à 10:32, Slawek Kaplonski <skaplons@redhat.com> a écrit :
Hi,
We have opened release patch for networking-midonet [1] but our concern about that project is that its gate is completly broken since some time thus we don't really know if the project is still working and valid to be released. In Wallaby cycle Neutron for example finished transition to the engine facade, and patch to adjust that in networking-midonet is still opened [2] (and red as there were some unrelated issues with most of the jobs there).
In the past we had discussion about networking-midonet project and it's status as the official Neutron stadium project. Then some new folks stepped in to maintain it but now it seems a bit like (again) it lacks of maintainers. I know that it is very late in the cycle now so my question to the TC and release teams is: should we release stable/wallaby with its current state, even if it's broken or should we maybe don't release it at all until its gate will be up and running?
[1] https://review.opendev.org/c/openstack/releases/+/781713 [2] https://review.opendev.org/c/openstack/networking-midonet/+/770797
-- Slawek Kaplonski Principal Software Engineer Red Hat
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE-----
wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----
participants (6)
-
Akihiro Motoki
-
Ghanshyam Mann
-
Herve Beraud
-
Neil Jerram
-
Radosław Piliszek
-
Slawek Kaplonski