On 4/16/16, 3:24 PM, "Doug Hellmann" <d...@doughellmann.com> wrote:
>Excerpts from Steven Dake (stdake)'s message of 2016-04-15 21:39:17 +0000: >> Hey fellow OpenStackers, >> >> Kolla 1.0.0 has a fatal flaw in its design related to data containers. >>The details are outlined here: >> >>http://docs.openstack.org/developer/kolla/liberty-deployment-warning.html >> >> Our plan to rectify this involves taking what is in stable/mitaka and >>making it stable/liberty and placing 1-3 patches on top of >>stable/liberty to make it deploy the liberty version of openstack. >>These 1-3 patches include metadata like repo locations, upstream tarball >>locations, etc. No actual code. This is a one time thing; in the >>future we will be following a strict bug-backport only policy. >> >> Our options include: >> 1. make a megapatch diff of liberty vs mitaka and merge that, with a >>patch on top to fix the repos >> Example here: >> https://review.openstack.org/#/c/306625/ >> >> 2. Tag the tip of stable/liberty with liberty-early-demise, delete the >>liberty branch, then create a new stable/liberty branch from the tip of >>stable/mitaka >> >> 3. Tag the tip of stable/liberty with liberty-early-demise, and run git >>reset -hard origin/stable/mitaka outside of gerrit. Tonyb says our >>setup prevents non-fast-forwarded pushes so this might not be viable. > >We discussed an option 4, which is make the mitaka version of kolla able >to install liberty versions of OpenStack. Can you remind me why that >wouldn't work? Was it because of dependency conflicts? > >Doug Doug, I don't recall the exact technical details however there are also policy decisions in play. Michal (cc) is responsible for our backporting of Liberty. I believe the technical objection had something to do with making upgrades from one to another not viable. We also have a long-standing policy decision that one repo should only deploy one version of OpenStack. We at this point are not ready to take on the concept of deploying N and N-1 from one repository. The reasons are complex but I could expand if you like. I'll let Michal respond though with his own thoughts, as I don't know his precise technical objection. >From a project policy perspective, we have made past decisions we don't want to have n and n-1 deploy and operational implementations in one repository. I'd have to trigger a vote to change that policy if that is the only path forward acceptable to the release team. All kolla policy changes require a majority vote (7 +1 votes) of the core review team within a 1 week window. If you indicate option 2 is a non-starter and option 4 is our only path forward, I'll trigger a vote and hope for the best :) Option 2 is what we as a community want. Option #4 is not what we as a community want at this time, although that may change in the future as our project becomes more mature. With option #4 would come the requirement that we delete the stable/liberty branch, because as it stands now, this branch has a fatal flaw which cannot be fixed as enumerated at length in this thread. Regards -steve > >> >> This was tonyb's work here: >> http://paste.openstack.org/raw/494295/ >> >> What we want to avoid is jamming 1k+ patches through our CI system and >>having the core reviewers have to deal with acking all those patches, or >>overloading gerrit and breaking things there. >> >> I am far from a git wizard, and don't really know the best way to >>proceed, other than we must have a liberty 1.1.0 deliverable with our >>mitaka bits + liberty repo pointers. I'd really like to preserve >>history. What we need is for stable/liberty to be an exact duplicate of >>stable/mitaka codwise, while also preserving history (which option 1 >>doesn't do). >> >> Can the Kolla community get an ack on the options from the >>Infrastructure team one way or another, so I can get the ball rolling on >>our end and sync up with Doug on the plan? >> >> Thanks! >> -steve > >_______________________________________________ >OpenStack-Infra mailing list >OpenStack-Infra@lists.openstack.org >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra _______________________________________________ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
