On Tue, May 4, 2021 at 5:16 AM Herve Beraud hberaud@redhat.com wrote:
We can consider this context as an exception [1] to switch back this deliverable to the cycle-with-intermediary model [2].
Ultimately it is not a library, it is a set of tools where having a tagged release makes more sense so we can fix breakpoints when integrations in other aspects break on us, such as kernel versioning from distributions where chroot suddenly no longer works as expected.
However, before we start anything, I prefer to discuss that first more deeply to see the possible side effects from a release management point of view, hence, I added this topic to our next meeting (Friday 2pm UTC - May 7). Feel free to join us to discuss it and plan how we will proceed.
I believe there is a contextual disconnect.
The ironic contributor context is we have suffered CI pain over the past year where code handling distributions has broken several times. Largely these breaks have had to be navigated around with specific version pinning, and settings changes, because we were unable to fix something a release or two back inside the tooling, in this case ipa-b. In other words, if we had that capability and those branches/tags, we would have been less in a world of pain because we wouldn't have had to make changes on every job/branch across every repository where we were hitting issues with ipa-b. Reduction of pain is why this change is being proposed.
If the release team would please convey their concerns of possible side effects in writing on this thread, I would greatly appreciate it because I'll be on a flight on Friday during the release team meeting.
Ultimately I see Riccardo trying to do the needful of the lazy consensus that has been obtained within the Ironic community. I don't see this is anything that requires an explicit blessing by the release team, but that perception is based upon my context.
-Julia
[1] https://releases.openstack.org/reference/release_models.html#openstack-relat... [2] https://releases.openstack.org/reference/release_models.html#cycle-with-inte... [3] https://etherpad.opendev.org/p/xena-relmgt-tracking
Le mar. 4 mai 2021 à 09:47, Riccardo Pittau elfosardo@gmail.com a écrit :
Hey Hervé,
Thank you for your reply.
That's correct, ironic-python-agent and ironic-python-agent-builder were originally part of the same repository. We decided to split them at some point, and we'd like to keep them separated, but we realized that it would make sense to keep them synced by branch.
At my knowledge, ipa-builder is also used by TripleO to generate the ipa ramdisks. Current projects can keep using the master branch as usual, it's unlikely this change will break anything. In any case, there should be enough time to adapt to the new branched model during the xena cycle, and I (and the ironic community) will be available to provide help if needed. There were no big changes on ipa-builder since the wallaby release, and of course we will be able to backport any bugfix, so I don't see issues in cutting the stable branch now.
Thanks,
Riccardo
On Mon, May 3, 2021 at 10:19 AM Herve Beraud hberaud@redhat.com wrote:
Hello,
At first glance that makes sense.
If I correctly understand the story, the ironic-python-agent [1] and the ironic-python-agent-builder [2] were within the same repo at the origin, correct?
Does someone else use the ironic-python-agent-builder?
[1] https://opendev.org/openstack/releases/src/branch/master/deliverables/xena/i... [2] https://opendev.org/openstack/releases/src/branch/master/deliverables/_indep...
Le ven. 30 avr. 2021 à 16:34, Iury Gregory iurygregory@gmail.com a écrit :
Hi Riccardo,
Thanks for raising this! I do like the idea of having stable branches for the ipa-builder +1
Em seg., 26 de abr. de 2021 às 12:03, Riccardo Pittau elfosardo@gmail.com escreveu:
Hello fellow openstackers!
During the recent xena ptg, the ironic community had a discussion about the need to move the ironic-python-agent-builder project from an independent model to the standard release model. When we initially split the builder from ironic-python-agent, we decided against it, but considering some problems we encountered during the road, the ironic community seems to be in favor of the change. The reasons for this are mainly to strictly align the image building project to ironic-python-agent releases, and ease dealing with the occasional upgrade of tinycore linux, the base image used to build the "tinyipa" ironic-python-agent ramdisk.
We'd like to involve the release team to ask for advice, not only on the process, but also considering that we need to ask to cut the first branch for the wallaby stable release, and we know we're a bit late for that! :)
Thank you in advance for your help!
Riccardo
-- Att[]'s Iury Gregory Melo Ferreira MSc in Computer Science at UFCG Part of the ironic-core and puppet-manager-core team in OpenStack Software Engineer at Red Hat Czech Social: https://www.linkedin.com/in/iurygregory E-mail: iurygregory@gmail.com
-- 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-----
-- 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-----