[openstack-dev] [tripleo] Newton End-Of-Life (EOL) next month (reminder #1)

Alex Schultz aschultz at redhat.com
Wed Sep 27 16:39:13 UTC 2017


On Tue, Sep 26, 2017 at 11:57 PM, Tony Breeds <tony at bakeyournoodle.com> wrote:
> On Tue, Sep 26, 2017 at 10:31:59PM -0700, Emilien Macchi wrote:
>> On Tue, Sep 26, 2017 at 10:17 PM, Tony Breeds <tony at bakeyournoodle.com> wrote:
>> > With that in mind I'd suggest that your review isn't appropriate for
>>
>> If we have to give up backports that help customers to get
>> production-ready environments, I would consider giving up stable
>> policy tag which probably doesn't fit for projects like installers. In
>> a real world, users don't deploy master or Pike (even not Ocata) but
>> are still on Liberty, and most of the time Newton.
>
> I agree the stable policy doesn't map very well to deployment projects
> and that's something I'd like to address.  I admit I'm not certain *how*
> to address it but it almost certainly starts with a discussion like this
> ;P
>
> I've proposed a forum session to further this discussion, even if that
> doesn't happen there's always the hall-way track :)
>

One idea would be to allow trailing projects additional trailing on
the phases as well.  Honestly 2 weeks for trailing for just GA is hard
enough. Let alone the fact that the actual end-users are 18+ months
behind.  For some deployment project like tripleo, there are sections
that should probably follow stable-policy as it exists today but
elements where there's 3rd party integration or upgrade implications
(in the case of tripleo, THT/puppet-tripleo) and they need to be more
flexible to modify things as necessary.  The word 'feature' isn't
necessarily the same for these projects than something like
nova/neutron/etc.

>> What proposing Giulio probably comes from the real world, the field,
>> who actually manage OpenStack at scale and on real environments (not
>> in devstack from master). If we can't have this code in-tree, we'll
>> probably carry this patch downstream (which is IMHO bad because of
>> maintenance and lack of CI). In that case, I'll vote to give up
>> stable:follows-policy so we can do what we need.
>
> Rather than give up on the stable:follows policy tag it is possibly
> worth looking at which portions of tripleo make that assertion.
>
> In this specific case, there isn't anything in the bug that indicates
> it comes from a user report which is all the stable team has to go on
> when making these types of decisions.
>

We'll need to re-evaulate what stable-policy means for tripleo.  We
don't want to allow the world for backporting but we also want to
reduce the patches carried downstream for specific use cases.  I think
in the case of 3rd party integrations we need a better definition of
what that means and perhaps creating a new repository like THT-extras
that doesn't follow stable-policy while the main one does.

Thanks,
-Alex

> Yours Tony.
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



More information about the OpenStack-dev mailing list