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

Andrey Danin adanin at mirantis.com
Tue Jun 24 20:32:44 UTC 2014

I think, Vladimir means, that we need to improve our scheduling of the CI
jobs over available CI resources. As I know, now we have a dedicated server
groups for separate tests and we cannot use free resources of other server
groups in case of overbalanced load.

On Thu, Jun 5, 2014 at 6:52 PM, Jesse Pretorius <jesse.pretorius at gmail.com>

> 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?
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Andrey Danin
adanin at mirantis.com
skype: gcon.monolake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140625/8b4de4d6/attachment.html>

More information about the OpenStack-dev mailing list