Open Stack

On 17-01-19 09:09:24, Matt Riedemann wrote:
> On 1/17/2019 6:07 AM, Chris Dent wrote:
> > > Deployment tools:
> > > 
> > > * Lee is working on TripleO support for extracted placement and
> > > estimates 3 more weeks for just deploy (base install) support to be
> > > done, and at least 3 more weeks for upgrade support after that. Read
> > > Lee's status update for details [2].
> > > * If nova were to go ahead and drop placement code and require
> > > extracted placement before TripleO is ready, they would have to pin
> > > nova to a git SHA before that which would delay their Stein release.
> > > * Having the extraction span release boundaries would ease the
> > > upgrade pain for TripleO.
> > 
> > Can you (or Dan?) clarify if spanning the release boundaries is
> > usefully specifically for tooling that chooses to upgrade everything
> > at once and thus is forced to run Stein nova with Stein placement?
> > 
> > And if someone were able/willing to run Rocky nova with Stein
> > placement (briefly) the challenges are less of a concern?
> > 
> > I'm not asking because I disagree with the assertion, I just want to
> > be sure I understand (and by proxy our adoring readers do as well)
> > what "ease" really means in this context as the above bullet doesn't
> > really explain it.
> 
> I didn't go into details on that point because honestly I also could use
> some written words explaining the differences for TripleO in doing the
> upgrade and migration in-step with the Stein upgrade versus upgrading to
> Stein and then upgrading to Train, and how the migration with that is any
> less painful.

AFAIK it wouldn't make the migration itself any less painful but having
an overlap release would provide additional development and validation
time. Time that is currently lacking given the very late breaking way
upgrades are developed by TripleO, often only stabilising after the
official upstream release is out.

Anyway, I think this was Dan's point here but I'm happy to be corrected.

> I know Dan talked about it on the call, but I can't say I followed it
> all well enough to be able to summarize the pros/cons (which is why I
> didn't in my summary email). This might already be something I know
> about, but the lights just aren't turning on right now.

Cheers,

-- 
Lee Yarwood                 A5D1 9385 88CB 7E5F BE64  6618 BCA6 6E33 F672 2D76
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190206/2e0f3cec/attachment.sig>