5:40 a.m.
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.
Best regards,
Alfredo
9:48 a.m.
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?
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
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
7:11 a.m.
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.
These are DIB created images, we could enable stabilized repo when building
them?
Alan
10:15 a.m.
On Tue, Jul 17, 2018 at 02:11:14PM +0200, Alan Pevec wrote:
>
> 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.
>
These are DIB created images, we could enable stabilized repo when building
them?
yes, DIB. I think we are doing that today, that is why we have 2 images.
Ideally, if we can do the changes after the image is built, I think we can get
down to a single image in nodepool.
- Paul
10:21 a.m.
On Tue, Jul 17, 2018 at 5:15 PM, Paul Belanger <pabelanger(a)redhat.com>
wrote:
On Tue, Jul 17, 2018 at 02:11:14PM +0200, Alan Pevec wrote:
> >
> > 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.
> >
>
> These are DIB created images, we could enable stabilized repo when
building
> them?
>
yes, DIB. I think we are doing that today, that is why we have 2 images.
Yes, that's what we are doing today.
Ideally, if we can do the changes after the image is built, I think
we can
get
down to a single image in nodepool.
I think having the two separated images is the only way we can ensure we
are not polluting the image in the initial phase with packages newer that
in the stabilized repo.
- Paul
10:38 a.m.
I think having the two separated images is the only way we can ensure
we are not polluting the image in the initial phase with packages newer that in the
stabilized repo.
This should be a small list, are any of those actually included in the
base image?
Alternatively, which jobs use "normal" f28 images, could we switch
them to use "stabilized" f28 ?
Alan
11:16 a.m.
On Tue, Jul 17, 2018 at 5:38 PM, Alan Pevec <apevec(a)redhat.com> wrote:
> I think having the two separated images is the only way we can
ensure we
are not polluting the image in the initial phase with packages newer that
in the stabilized repo.
This should be a small list, are any of those actually included in the
base image?
Yes, the list is small but we can't be sure if it will change at some
point, and analysing if we are having one of those cases on each change is
too error prone, IMO.
Alternatively, which jobs use "normal" f28 images, could we
switch
them to use "stabilized" f28 ?
fedora-stable has the required packages to run and build python3 packages.
Currently it's missing some requirements for the jobs running on fedora 28
image although it's something we could work on.
Alan
Maybe I'm underestimating the cost of maintaining two different images for
fedora, but my understanding is that the resources the extra image uses and
the effort to maintain is workable. Please, correct me if i'm wrong.
3:56 p.m.
On Tue, Jul 17, 2018 at 06:16:04PM +0200, Alfredo Moralejo Alonso wrote:
On Tue, Jul 17, 2018 at 5:38 PM, Alan Pevec <apevec(a)redhat.com>
wrote:
> > I think having the two separated images is the only way we can ensure we
> are not polluting the image in the initial phase with packages newer that
> in the stabilized repo.
>
> This should be a small list, are any of those actually included in the
> base image?
>
Yes, the list is small but we can't be sure if it will change at some
point, and analysing if we are having one of those cases on each change is
too error prone, IMO.
> Alternatively, which jobs use "normal" f28 images, could we switch
> them to use "stabilized" f28 ?
>
fedora-stable has the required packages to run and build python3 packages.
Currently it's missing some requirements for the jobs running on fedora 28
image although it's something we could work on.
>
> Alan
>
Maybe I'm underestimating the cost of maintaining two different images for
fedora, but my understanding is that the resources the extra image uses and
the effort to maintain is workable. Please, correct me if i'm wrong.
I wouldn't say minimal, but there is a cost. With fedora-29 around the corner,
it does mean we have 2 iamges to update now, over one. How long does this image
need to live for? When can we get to a point of just using the default fedora
image?
- Paul
4:17 p.m.
On Tue, Jul 17, 2018 at 4:57 PM Paul Belanger <pabelanger(a)redhat.com> wrote:
On Tue, Jul 17, 2018 at 06:16:04PM +0200, Alfredo Moralejo Alonso
wrote:
> On Tue, Jul 17, 2018 at 5:38 PM, Alan Pevec <apevec(a)redhat.com> wrote:
>
> > > I think having the two separated images is the only way we can
ensure we
> > are not polluting the image in the initial phase with packages newer
that
> > in the stabilized repo.
> >
> > This should be a small list, are any of those actually included in the
> > base image?
> >
>
> Yes, the list is small but we can't be sure if it will change at some
> point, and analysing if we are having one of those cases on each change
is
> too error prone, IMO.
>
>
> > Alternatively, which jobs use "normal" f28 images, could we switch
> > them to use "stabilized" f28 ?
> >
>
> fedora-stable has the required packages to run and build python3
packages.
> Currently it's missing some requirements for the jobs running on fedora
28
> image although it's something we could work on.
>
>
> >
> > Alan
> >
>
> Maybe I'm underestimating the cost of maintaining two different images
for
> fedora, but my understanding is that the resources the extra image uses
and
> the effort to maintain is workable. Please, correct me if i'm wrong.
I wouldn't say minimal, but there is a cost. With fedora-29 around the
corner,
it does mean we have 2 iamges to update now, over one. How long does this
image
need to live for? When can we get to a point of just using the default
fedora
image?
- Paul
Hey guys,
Slight tangent, but wondering how far out we are from the CI team having to
get involved here? Is there any planning required at this point?
Thanks
_______________________________________________
dev mailing list
dev(a)lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev
To unsubscribe: dev-unsubscribe(a)lists.rdoproject.org
--
Wes Hayutin
Associate MANAGER
Red Hat
<https://www.redhat.com/>
w <cclayton@redhat.com>hayutin(a)redhat.com T: +1919 <+19197544114>4232509
IRC: weshay
<https://red.ht/sig>
View my calendar and check my availability for meetings HERE
<https://calendar.google.com/calendar/b/1/embed?src=whayutin@redhat.com&am...
11:11 a.m.
On Tue, Jul 17, 2018 at 11:17 PM, Wesley Hayutin <whayutin(a)redhat.com>
wrote:
On Tue, Jul 17, 2018 at 4:57 PM Paul Belanger <pabelanger(a)redhat.com>
wrote:
> On Tue, Jul 17, 2018 at 06:16:04PM +0200, Alfredo Moralejo Alonso wrote:
> > On Tue, Jul 17, 2018 at 5:38 PM, Alan Pevec <apevec(a)redhat.com> wrote:
> >
> > > > I think having the two separated images is the only way we can
> ensure we
> > > are not polluting the image in the initial phase with packages newer
> that
> > > in the stabilized repo.
> > >
> > > This should be a small list, are any of those actually included in the
> > > base image?
> > >
> >
> > Yes, the list is small but we can't be sure if it will change at some
> > point, and analysing if we are having one of those cases on each change
> is
> > too error prone, IMO.
> >
> >
> > > Alternatively, which jobs use "normal" f28 images, could we
switch
> > > them to use "stabilized" f28 ?
> > >
> >
> > fedora-stable has the required packages to run and build python3
> packages.
> > Currently it's missing some requirements for the jobs running on fedora
> 28
> > image although it's something we could work on.
> >
> >
> > >
> > > Alan
> > >
> >
> > Maybe I'm underestimating the cost of maintaining two different images
> for
> > fedora, but my understanding is that the resources the extra image uses
> and
> > the effort to maintain is workable. Please, correct me if i'm wrong.
>
> I wouldn't say minimal, but there is a cost. With fedora-29 around the
> corner,
> it does mean we have 2 iamges to update now, over one. How long does this
> image
> need to live for? When can we get to a point of just using the default
> fedora
> image?
>
> - Paul
>
Hey guys,
Slight tangent, but wondering how far out we are from the CI team having
to get involved here? Is there any planning required at this point?
AFAIK, before getting CI involved to create a job to build container we
need to get patches merged in kolla to build containers for fedora/python3.
I'm not sure if there is a ETA for it. Adding Martin to CC, he may have
some estimation for it.
Thanks
> _______________________________________________
> dev mailing list
> dev(a)lists.rdoproject.org
> http://lists.rdoproject.org/mailman/listinfo/dev
>
> To unsubscribe: dev-unsubscribe(a)lists.rdoproject.org
>
--
Wes Hayutin
Associate MANAGER
Red Hat
<https://www.redhat.com/>
w <cclayton@redhat.com>hayutin(a)redhat.com T: +1919 <+19197544114>
4232509 IRC: weshay
<https://red.ht/sig>
View my calendar and check my availability for meetings HERE
<https://calendar.google.com/calendar/b/1/embed?src=whayutin@redhat.com&am...
2:10 a.m.
On Tue, Jul 24, 2018 at 6:11 PM, Alfredo Moralejo Alonso <
amoralej(a)redhat.com> wrote:
On Tue, Jul 17, 2018 at 11:17 PM, Wesley Hayutin <whayutin(a)redhat.com>
wrote:
>
>
> On Tue, Jul 17, 2018 at 4:57 PM Paul Belanger <pabelanger(a)redhat.com>
> wrote:
>
>> On Tue, Jul 17, 2018 at 06:16:04PM +0200, Alfredo Moralejo Alonso wrote:
>> > On Tue, Jul 17, 2018 at 5:38 PM, Alan Pevec <apevec(a)redhat.com>
wrote:
>> >
>> > > > I think having the two separated images is the only way we can
>> ensure we
>> > > are not polluting the image in the initial phase with packages newer
>> that
>> > > in the stabilized repo.
>> > >
>> > > This should be a small list, are any of those actually included in
>> the
>> > > base image?
>> > >
>> >
>> > Yes, the list is small but we can't be sure if it will change at some
>> > point, and analysing if we are having one of those cases on each
>> change is
>> > too error prone, IMO.
>> >
>> >
>> > > Alternatively, which jobs use "normal" f28 images, could we
switch
>> > > them to use "stabilized" f28 ?
>> > >
>> >
>> > fedora-stable has the required packages to run and build python3
>> packages.
>> > Currently it's missing some requirements for the jobs running on
>> fedora 28
>> > image although it's something we could work on.
>> >
>> >
>> > >
>> > > Alan
>> > >
>> >
>> > Maybe I'm underestimating the cost of maintaining two different images
>> for
>> > fedora, but my understanding is that the resources the extra image
>> uses and
>> > the effort to maintain is workable. Please, correct me if i'm wrong.
>>
>> I wouldn't say minimal, but there is a cost. With fedora-29 around the
>> corner,
>> it does mean we have 2 iamges to update now, over one. How long does
>> this image
>> need to live for? When can we get to a point of just using the default
>> fedora
>> image?
>>
>> - Paul
>>
>
> Hey guys,
> Slight tangent, but wondering how far out we are from the CI team having
> to get involved here? Is there any planning required at this point?
>
>
AFAIK, before getting CI involved to create a job to build container we
need to get patches merged in kolla to build containers for fedora/python3.
I'm not sure if there is a ETA for it. Adding Martin to CC, he may have
some estimation for it.
There is absolutely no chance this patch [1] merges into kolla as it. It's
a very ugly hack where I'm basically swapping the centos binary distro to
be based on fedora:28. The idea was to prove feasibility and for you to
have a patch you can pull in your build pipeline that allowed you to build
fedora:28 based images. Integrating fedora based images in kolla properly
would require a lot more work, and that's not really something I'm keen to
do since it would send the wrong message that kolla supports fedora base.
Does it sound reasonable?
Martin
[1] https://review.openstack.org/#/c/582290/
> Thanks
>
>
>
>> _______________________________________________
>> dev mailing list
>> dev(a)lists.rdoproject.org
>> http://lists.rdoproject.org/mailman/listinfo/dev
>>
>> To unsubscribe: dev-unsubscribe(a)lists.rdoproject.org
>>
> --
>
> Wes Hayutin
>
> Associate MANAGER
>
> Red Hat
>
> <https://www.redhat.com/>
>
> w <cclayton@redhat.com>hayutin(a)redhat.com T: +1919 <+19197544114>
> 4232509 IRC: weshay
> <https://red.ht/sig>
>
> View my calendar and check my availability for meetings HERE
>
<https://calendar.google.com/calendar/b/1/embed?src=whayutin@redhat.com&am...
>
_______________________________________________
dev mailing list
dev(a)lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev
To unsubscribe: dev-unsubscribe(a)lists.rdoproject.org
4:43 a.m.
On Wed, Jul 25, 2018 at 9:11 AM Martin André <m.andre(a)redhat.com> wrote:
...
> AFAIK, before getting CI involved to create a job to build
container we need to get patches merged in kolla to build containers for fedora/python3.
I'm not sure if there is a ETA for it. Adding Martin to CC, he may have some
estimation for it.
There is absolutely no chance this patch [1] merges into kolla as it. It's a very
ugly hack where I'm basically swapping the centos binary distro to be based on
fedora:28. The idea was to prove feasibility and for you to have a patch you can pull in
your build pipeline that allowed you to build fedora:28 based images. Integrating fedora
based images in kolla properly would require a lot more work, and that's not really
something I'm keen to do since it would send the wrong message that kolla supports
fedora base.
Does it sound reasonable?
That might work for a first PoC iteration, at the same time we need a
complete solution using a pattern you can see in Fedora packaging:
%if 0%{?fedora} || 0%{?rhel} >= 8
i.e. Kolla and other upstream projects need to start preparing for
real using Fedora based packages, taking into account that next RHEL
is based on current Fedora and in before Beta most of the changes are
done directly in Fedora then imported internally. Waiting for CentOS 8
will be too late since it will come out only after RHEL GA,
historically there weren't CentOS Betas.
Cheers,
Alan
Martin
[1] https://review.openstack.org/#/c/582290/
2095
days inactive
2107
days old
12 comments
5 participants
participants (5)
-
Alan Pevec -
Alfredo Moralejo Alonso -
Martin André -
Paul Belanger -
Wesley Hayutin