6:07 a.m.
On Mon, Jul 16, 2018 at 4:48 PM, Paul Belanger <pabelanger(a)redhat.com>
wrote:
On Fri, Jul 13, 2018 at 12:40:37PM +0200, Alfredo Moralejo Alonso
wrote:
> Hi,
>
> A new update about the status of python3 PoC as of today:
>
> 1. Python3 packages for keystone and glance have been added to
> rpm-packaging project and are available in RDO Trunk repo for fedora
stable.
> 2. rdo-fedora-stable image is available in https://softwarefactory-
> project.io nodepool to run python3 related jobs in zuulv3.
> 3. Changes in puppet modules and puppet-openstack-integration are merged
to
> create a scenario to test only python3 enabled services on fedora.
> 4. A third party job has been created in softwarefactory zuul to run the
> python3 only scenario on fedora which is executed for upstream reviews on
> p-o-i, puppet-glance and puppet-keystone.
> 5. tripleo-common has been added to the fedora-stable DLRN builder.
> 6. There is a WIP review to in kolla to build containers based on fedora
> using the python3 packages in https://review.openstack.org/#/c/582290/
>
> With last tasks, RDO part in the PoC for Rocky cycle is mostly done
(there
> are some missing improvements related to promotion of fedora-stable repo
> which we are still working on).
>
> Details about the tasks are in python3 trello tracker card
> https://trello.com/c/ReowuP4z/105-python3
>
> I'd like to arrange a retrospective for this PoC in a couple of weeks.
> Please, let me know if you are interested in participating on it.
>
> Please, let me know if you have any question about it.
>
Thanks for doing this!
Today, we have a 2nd fedora image that is being built by nodepool-builder
in
SF.io. I know we do this because we want to pull from DLRN during the image
build process, but is this a hard requirement? Could use not use the
latest
fedora-28 image, enable the proper DLRN repo, then reboot to ensure we have
correct kernel if need?
The actual problem is that Fedora moves very fast and sometimes latest
Fedora packages are not valid for OpenStack and we need to use builds from
a previous release or even override them with a build we create in copr.
This is the case for eventlet and sphinx.
To avoid this, we maintain a repository which is a subset of Fedora 28 OS
packages controlled with the needed exceptions, overrides, etc... This is a
"Fedora stabilized" repository we use to build and test packages.
If we use Fedora 28 to create the initial image and then replace
repositories, we may get packages which are newer that the ones in the
stabilized repo which would make images bad to test python3 packages.
Reason to do this, it means one less image we need to maintain in
nodepool.
TL;DR: Could you explain again why we need 2 fedora images and not 1 :)
Thanks,
Paul