[openstack-dev] [FUEL] OpenStack patching and FUEL upgrade follow-up meeting minutes

Jesse Pretorius jesse.pretorius at gmail.com
Thu Jun 5 14:52:07 UTC 2014


On 5 June 2014 16:27, Vladimir Kuklin <vkuklin at mirantis.com> wrote:

> 1. We need strict EOS and EOL rules to decide how many maintenance
> releases there will be for each series or our QA team and infrastructure
> will not ever be available to digest it.
>

Agreed. Would it not be prudent to keep with the OpenStack support standard
- support latest version and the -1 version?


> 3. We need to clearly specify the restrictions which patching and upgrade
> process we support:
> a. New environments can only be deployed with the latest version of
> OpenStack and FUEL Library supported
> b. Old environments can only be updated within the only minor release
> (e.g. 5.0.1->5.0.2 is allowed, 5.0.1->5.1 is not)
>

Assuming that the major upgrades will be handled in
https://blueprints.launchpad.net/fuel/+spec/upgrade-major-openstack-environment
then I agree. If not, then we have a sticking point here. I would agree
that this is a good start, but in the medium to long term it is important
to be able to upgrade from perhaps the latest minor version of the platform
to the next available major version.


> 4. We have some devops tasks we need to finish to feel more comfortable in
> the future to make testing of patching much easier:
> a. we need to finish devops bare metal and distributed enviroments setup
> to make CI and testing process easier
> b. we need to implement elastic-recheck like feature to analyze our CI
> results in order to allow developers to retrigger checks in case of
> floating bugs
> c. we need to start using more sophisticated scheduler
>

I find the scheduler statement a curiosity. Can you elaborate?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140605/bbe7395d/attachment.html>


More information about the OpenStack-dev mailing list