[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