unblocking the py3 transition
Hi everyone, The transition to python3-only is blocked on three missing python packages in EPEL7: - python36-werkzeug: tracked by https://bugzilla.redhat.com/show_bug.cgi?id=1545888 - python36-pecan: tracked by https://bugzilla.redhat.com/show_bug.cgi?id=1766839 - python36-cherrypy: tracked by https://bugzilla.redhat.com/show_bug.cgi?id=1765032 In order to get these into EPEL, they need to go into Fedora first, which has its own (slow) process. In the meantime, these packages are easy to build manually as one-offs (and may already have been built by David and sitting in a temporary repo). To unblock this, what if we require that temporary repo for centos7 *master* installs, and add it to the teuthology workers via ceph-cm-ansible? The assumption is that by the time we release octopus we will have gotten the dependencies in to the appropriate upstream repos. That means we have until March 2020... 4 months away. Thanks! sage
On Tue, 5 Nov 2019, Sage Weil wrote:
Hi everyone,
The transition to python3-only is blocked on three missing python packages in EPEL7:
- python36-werkzeug: tracked by https://bugzilla.redhat.com/show_bug.cgi?id=1545888 - python36-pecan: tracked by https://bugzilla.redhat.com/show_bug.cgi?id=1766839 - python36-cherrypy: tracked by https://bugzilla.redhat.com/show_bug.cgi?id=1765032
In order to get these into EPEL, they need to go into Fedora first, which has its own (slow) process. In the meantime, these packages are easy to build manually as one-offs (and may already have been built by David and sitting in a temporary repo).
To unblock this, what if we require that temporary repo for centos7 *master* installs, and add it to the teuthology workers via ceph-cm-ansible? The assumption is that by the time we release octopus we will have gotten the dependencies in to the appropriate upstream repos. That means we have until March 2020... 4 months away.
Update: I just talked to Alfredo and the (current) blocker is cherrypy.. there are a zillion dependencies and the maintainer doesn't want to pull them in. So, the current plan is now to drop centos7 support for octopus. That should simplify things drastically! sage
On Wed, Nov 6, 2019 at 10:11 AM Sage Weil <sweil@redhat.com> wrote:
On Tue, 5 Nov 2019, Sage Weil wrote:
Hi everyone,
The transition to python3-only is blocked on three missing python packages in EPEL7:
- python36-werkzeug: tracked by https://bugzilla.redhat.com/show_bug.cgi?id=1545888 - python36-pecan: tracked by https://bugzilla.redhat.com/show_bug.cgi?id=1766839 - python36-cherrypy: tracked by https://bugzilla.redhat.com/show_bug.cgi?id=1765032
In order to get these into EPEL, they need to go into Fedora first, which has its own (slow) process. In the meantime, these packages are easy to build manually as one-offs (and may already have been built by David and sitting in a temporary repo).
To unblock this, what if we require that temporary repo for centos7 *master* installs, and add it to the teuthology workers via ceph-cm-ansible? The assumption is that by the time we release octopus we will have gotten the dependencies in to the appropriate upstream repos. That means we have until March 2020... 4 months away.
Update:
I just talked to Alfredo and the (current) blocker is cherrypy.. there are a zillion dependencies and the maintainer doesn't want to pull them in.
So, the current plan is now to drop centos7 support for octopus. That should simplify things drastically!
Quick update on this, we are working hard on trying to get cherrypy fully available, and we made some progress yesterday. Being able to concentrate on EPEL8 (CentOS8) is going to be a tremendous help. We will follow Sage's suggestion of getting the packages into a self-hosted repo so that we don't have to wait (weeks!) for packages to become available officially.
sage
On 11/7/19 2:02 PM, Alfredo Deza wrote:
Quick update on this, we are working hard on trying to get cherrypy fully available, and we made some progress yesterday. Being able to concentrate on EPEL8 (CentOS8) is going to be a tremendous help.
We will follow Sage's suggestion of getting the packages into a self-hosted repo so that we don't have to wait (weeks!) for packages to become available officially.
Thanks a lot for making this happen, much appreciated! Not having to keep Python2 compatibility in mind when implementing new features will help to increase the code quality. However, there's one catch: backporting code into previous releases may now become more difficult, as it might require tweaking the code to be Python2-compatible as part of the backport, e.g. in a follow-up commit. But that's bearable, I think :) Lenz -- SUSE Software Solutions Germany GmbH - Maxfeldstr. 5 - 90409 Nuernberg GF: Felix Imendörffer, HRB 36809 (AG Nürnberg)
Le jeu. 7 nov. 2019 à 05:02, Alfredo Deza <adeza@redhat.com> a écrit :
On Wed, Nov 6, 2019 at 10:11 AM Sage Weil <sweil@redhat.com> wrote:
On Tue, 5 Nov 2019, Sage Weil wrote:
Hi everyone,
The transition to python3-only is blocked on three missing python
packages
in EPEL7:
- python36-werkzeug: tracked by https://bugzilla.redhat.com/show_bug.cgi?id=1545888 - python36-pecan: tracked by https://bugzilla.redhat.com/show_bug.cgi?id=1766839 - python36-cherrypy: tracked by https://bugzilla.redhat.com/show_bug.cgi?id=1765032
In order to get these into EPEL, they need to go into Fedora first, which has its own (slow) process. In the meantime, these packages are easy to build manually as one-offs (and may already have been built by David and sitting in a temporary repo).
To unblock this, what if we require that temporary repo for centos7 *master* installs, and add it to the teuthology workers via ceph-cm-ansible? The assumption is that by the time we release octopus we will have gotten the dependencies in to the appropriate upstream repos. That means we have until March 2020... 4 months away.
Update:
I just talked to Alfredo and the (current) blocker is cherrypy.. there are a zillion dependencies and the maintainer doesn't want to pull them in.
So, the current plan is now to drop centos7 support for octopus. That should simplify things drastically!
Quick update on this, we are working hard on trying to get cherrypy fully available, and we made some progress yesterday. Being able to
Alfredo, may I learn what progress it was? As I plan to build the python3-cherrypy package(s) on el7 to understand the efforts to ready its dependencies before moving on after returning home. So i am interested in where we are now.
concentrate on EPEL8 (CentOS8) is going to be a tremendous help.
We will follow Sage's suggestion of getting the packages into a self-hosted repo so that we don't have to wait (weeks!) for packages to become available officially.
sage
_______________________________________________ Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io
-- Regards Kefu Chai
On Thu, Nov 7, 2019 at 2:55 PM kefu chai <tchaikov@gmail.com> wrote:
Le jeu. 7 nov. 2019 à 05:02, Alfredo Deza <adeza@redhat.com> a écrit :
On Wed, Nov 6, 2019 at 10:11 AM Sage Weil <sweil@redhat.com> wrote:
On Tue, 5 Nov 2019, Sage Weil wrote:
Hi everyone,
The transition to python3-only is blocked on three missing python packages in EPEL7:
- python36-werkzeug: tracked by https://bugzilla.redhat.com/show_bug.cgi?id=1545888 - python36-pecan: tracked by https://bugzilla.redhat.com/show_bug.cgi?id=1766839 - python36-cherrypy: tracked by https://bugzilla.redhat.com/show_bug.cgi?id=1765032
In order to get these into EPEL, they need to go into Fedora first, which has its own (slow) process. In the meantime, these packages are easy to build manually as one-offs (and may already have been built by David and sitting in a temporary repo).
To unblock this, what if we require that temporary repo for centos7 *master* installs, and add it to the teuthology workers via ceph-cm-ansible? The assumption is that by the time we release octopus we will have gotten the dependencies in to the appropriate upstream repos. That means we have until March 2020... 4 months away.
Update:
I just talked to Alfredo and the (current) blocker is cherrypy.. there are a zillion dependencies and the maintainer doesn't want to pull them in.
So, the current plan is now to drop centos7 support for octopus. That should simplify things drastically!
Quick update on this, we are working hard on trying to get cherrypy fully available, and we made some progress yesterday. Being able to
Alfredo, may I learn what progress it was? As I plan to build the python3-cherrypy package(s) on el7 to understand the efforts to ready its dependencies before moving on after returning home. So i am interested in where we are now.
Ken, Justing Caratzas, and myself are now producing the missing dependencies through the official Fedora/EPEL channels, and will be producing the packages and getting them onto the mirror as that happens. Feel free to ping me directly for more details.
concentrate on EPEL8 (CentOS8) is going to be a tremendous help.
We will follow Sage's suggestion of getting the packages into a self-hosted repo so that we don't have to wait (weeks!) for packages to become available officially.
sage
_______________________________________________ Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io
-- Regards Kefu Chai
The more we are looking into this, the more the dependency chain keeps growing. One thing I want to emphasize is the *tremendous* amount of dependencies Ceph has, which makes this a non-trivial task. One example of this, is that Ceph has a direct dependency on **three** Python web frameworks: Cherrypy, Pecan, and Flask. We surely don't need three. I remember pushing for Pecan usage but others liked Cherrypy more, and I guess some other group really liked Flask so that is where we are today. This sort of dependency proliferation is a bug and it makes maintaining the packages (and their dependencies) a consuming and time-intensive task. The three web frameworks is one example, I am sure there are others. How can we streamline, or reduce this? On Thu, Nov 7, 2019 at 2:55 PM kefu chai <tchaikov@gmail.com> wrote:
Le jeu. 7 nov. 2019 à 05:02, Alfredo Deza <adeza@redhat.com> a écrit :
On Wed, Nov 6, 2019 at 10:11 AM Sage Weil <sweil@redhat.com> wrote:
On Tue, 5 Nov 2019, Sage Weil wrote:
Hi everyone,
The transition to python3-only is blocked on three missing python packages in EPEL7:
- python36-werkzeug: tracked by https://bugzilla.redhat.com/show_bug.cgi?id=1545888 - python36-pecan: tracked by https://bugzilla.redhat.com/show_bug.cgi?id=1766839 - python36-cherrypy: tracked by https://bugzilla.redhat.com/show_bug.cgi?id=1765032
In order to get these into EPEL, they need to go into Fedora first, which has its own (slow) process. In the meantime, these packages are easy to build manually as one-offs (and may already have been built by David and sitting in a temporary repo).
To unblock this, what if we require that temporary repo for centos7 *master* installs, and add it to the teuthology workers via ceph-cm-ansible? The assumption is that by the time we release octopus we will have gotten the dependencies in to the appropriate upstream repos. That means we have until March 2020... 4 months away.
Update:
I just talked to Alfredo and the (current) blocker is cherrypy.. there are a zillion dependencies and the maintainer doesn't want to pull them in.
So, the current plan is now to drop centos7 support for octopus. That should simplify things drastically!
Quick update on this, we are working hard on trying to get cherrypy fully available, and we made some progress yesterday. Being able to
Alfredo, may I learn what progress it was? As I plan to build the python3-cherrypy package(s) on el7 to understand the efforts to ready its dependencies before moving on after returning home. So i am interested in where we are now.
concentrate on EPEL8 (CentOS8) is going to be a tremendous help.
We will follow Sage's suggestion of getting the packages into a self-hosted repo so that we don't have to wait (weeks!) for packages to become available officially.
sage
_______________________________________________ Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io
-- Regards Kefu Chai
On Mon, 11 Nov 2019, Alfredo Deza wrote:
The more we are looking into this, the more the dependency chain keeps growing.
One thing I want to emphasize is the *tremendous* amount of dependencies Ceph has, which makes this a non-trivial task. One example of this, is that Ceph has a direct dependency on **three** Python web frameworks: Cherrypy, Pecan, and Flask.
We surely don't need three. I remember pushing for Pecan usage but others liked Cherrypy more, and I guess some other group really liked Flask so that is where we are today.
This sort of dependency proliferation is a bug and it makes maintaining the packages (and their dependencies) a consuming and time-intensive task.
The three web frameworks is one example, I am sure there are others. How can we streamline, or reduce this?
I did a git grep flask and don't see what is using that one... I don't see the dependency listed either? pecan is used by the restful module. I'm not sure we have many users there or what the long term future for that is.. it may be supplanted by the dashboard's API, in which case pecan could be dropped. OTOH, it's probably the easiest dependency to carry, right? :) sage
On Thu, Nov 7, 2019 at 2:55 PM kefu chai <tchaikov@gmail.com> wrote:
Le jeu. 7 nov. 2019 à 05:02, Alfredo Deza <adeza@redhat.com> a écrit :
On Wed, Nov 6, 2019 at 10:11 AM Sage Weil <sweil@redhat.com> wrote:
On Tue, 5 Nov 2019, Sage Weil wrote:
Hi everyone,
The transition to python3-only is blocked on three missing python packages in EPEL7:
- python36-werkzeug: tracked by https://bugzilla.redhat.com/show_bug.cgi?id=1545888 - python36-pecan: tracked by https://bugzilla.redhat.com/show_bug.cgi?id=1766839 - python36-cherrypy: tracked by https://bugzilla.redhat.com/show_bug.cgi?id=1765032
In order to get these into EPEL, they need to go into Fedora first, which has its own (slow) process. In the meantime, these packages are easy to build manually as one-offs (and may already have been built by David and sitting in a temporary repo).
To unblock this, what if we require that temporary repo for centos7 *master* installs, and add it to the teuthology workers via ceph-cm-ansible? The assumption is that by the time we release octopus we will have gotten the dependencies in to the appropriate upstream repos. That means we have until March 2020... 4 months away.
Update:
I just talked to Alfredo and the (current) blocker is cherrypy.. there are a zillion dependencies and the maintainer doesn't want to pull them in.
So, the current plan is now to drop centos7 support for octopus. That should simplify things drastically!
Quick update on this, we are working hard on trying to get cherrypy fully available, and we made some progress yesterday. Being able to
Alfredo, may I learn what progress it was? As I plan to build the python3-cherrypy package(s) on el7 to understand the efforts to ready its dependencies before moving on after returning home. So i am interested in where we are now.
concentrate on EPEL8 (CentOS8) is going to be a tremendous help.
We will follow Sage's suggestion of getting the packages into a self-hosted repo so that we don't have to wait (weeks!) for packages to become available officially.
sage
_______________________________________________ Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io
-- Regards Kefu Chai
_______________________________________________ Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io
On Mon, Nov 11, 2019 at 5:54 PM Sage Weil <sage@newdream.net> wrote:
On Mon, 11 Nov 2019, Alfredo Deza wrote:
The more we are looking into this, the more the dependency chain keeps growing.
One thing I want to emphasize is the *tremendous* amount of dependencies Ceph has, which makes this a non-trivial task. One example of this, is that Ceph has a direct dependency on **three** Python web frameworks: Cherrypy, Pecan, and Flask.
We surely don't need three. I remember pushing for Pecan usage but others liked Cherrypy more, and I guess some other group really liked Flask so that is where we are today.
This sort of dependency proliferation is a bug and it makes maintaining the packages (and their dependencies) a consuming and time-intensive task.
The three web frameworks is one example, I am sure there are others. How can we streamline, or reduce this?
I did a git grep flask and don't see what is using that one... I don't see the dependency listed either?
Seems like Flask is no longer around for Master but it is around in Luminous: https://github.com/ceph/ceph/blob/luminous/ceph.spec.in#L322
pecan is used by the restful module. I'm not sure we have many users there or what the long term future for that is.. it may be supplanted by the dashboard's API, in which case pecan could be dropped. OTOH, it's probably the easiest dependency to carry, right? :)
Yes it is! Of course it is :D As much as I like/prefer it, would *love* to see more trimming, less adding.
sage
On Thu, Nov 7, 2019 at 2:55 PM kefu chai <tchaikov@gmail.com> wrote:
Le jeu. 7 nov. 2019 à 05:02, Alfredo Deza <adeza@redhat.com> a écrit :
On Wed, Nov 6, 2019 at 10:11 AM Sage Weil <sweil@redhat.com> wrote:
On Tue, 5 Nov 2019, Sage Weil wrote:
Hi everyone,
The transition to python3-only is blocked on three missing python packages in EPEL7:
- python36-werkzeug: tracked by https://bugzilla.redhat.com/show_bug.cgi?id=1545888 - python36-pecan: tracked by https://bugzilla.redhat.com/show_bug.cgi?id=1766839 - python36-cherrypy: tracked by https://bugzilla.redhat.com/show_bug.cgi?id=1765032
In order to get these into EPEL, they need to go into Fedora first, which has its own (slow) process. In the meantime, these packages are easy to build manually as one-offs (and may already have been built by David and sitting in a temporary repo).
To unblock this, what if we require that temporary repo for centos7 *master* installs, and add it to the teuthology workers via ceph-cm-ansible? The assumption is that by the time we release octopus we will have gotten the dependencies in to the appropriate upstream repos. That means we have until March 2020... 4 months away.
Update:
I just talked to Alfredo and the (current) blocker is cherrypy.. there are a zillion dependencies and the maintainer doesn't want to pull them in.
So, the current plan is now to drop centos7 support for octopus. That should simplify things drastically!
Quick update on this, we are working hard on trying to get cherrypy fully available, and we made some progress yesterday. Being able to
Alfredo, may I learn what progress it was? As I plan to build the python3-cherrypy package(s) on el7 to understand the efforts to ready its dependencies before moving on after returning home. So i am interested in where we are now.
concentrate on EPEL8 (CentOS8) is going to be a tremendous help.
We will follow Sage's suggestion of getting the packages into a self-hosted repo so that we don't have to wait (weeks!) for packages to become available officially.
sage
_______________________________________________ Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io
-- Regards Kefu Chai
_______________________________________________ Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io _______________________________________________
Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io
On Mon, 11 Nov 2019, Alfredo Deza wrote:
On Mon, Nov 11, 2019 at 5:54 PM Sage Weil <sage@newdream.net> wrote:
On Mon, 11 Nov 2019, Alfredo Deza wrote:
The more we are looking into this, the more the dependency chain keeps growing.
One thing I want to emphasize is the *tremendous* amount of dependencies Ceph has, which makes this a non-trivial task. One example of this, is that Ceph has a direct dependency on **three** Python web frameworks: Cherrypy, Pecan, and Flask.
We surely don't need three. I remember pushing for Pecan usage but others liked Cherrypy more, and I guess some other group really liked Flask so that is where we are today.
This sort of dependency proliferation is a bug and it makes maintaining the packages (and their dependencies) a consuming and time-intensive task.
The three web frameworks is one example, I am sure there are others. How can we streamline, or reduce this?
I did a git grep flask and don't see what is using that one... I don't see the dependency listed either?
Seems like Flask is no longer around for Master but it is around in Luminous:
https://github.com/ceph/ceph/blob/luminous/ceph.spec.in#L322
That makes it irrelevant for the el8 and py3 work then right? I don't think we don't need to build luminous for el8... sage
pecan is used by the restful module. I'm not sure we have many users there or what the long term future for that is.. it may be supplanted by the dashboard's API, in which case pecan could be dropped. OTOH, it's probably the easiest dependency to carry, right? :)
Yes it is! Of course it is :D
As much as I like/prefer it, would *love* to see more trimming, less adding.
sage
On Thu, Nov 7, 2019 at 2:55 PM kefu chai <tchaikov@gmail.com> wrote:
Le jeu. 7 nov. 2019 à 05:02, Alfredo Deza <adeza@redhat.com> a écrit :
On Wed, Nov 6, 2019 at 10:11 AM Sage Weil <sweil@redhat.com> wrote:
On Tue, 5 Nov 2019, Sage Weil wrote: > Hi everyone, > > The transition to python3-only is blocked on three missing python packages > in EPEL7: > > - python36-werkzeug: tracked by https://bugzilla.redhat.com/show_bug.cgi?id=1545888 > - python36-pecan: tracked by https://bugzilla.redhat.com/show_bug.cgi?id=1766839 > - python36-cherrypy: tracked by https://bugzilla.redhat.com/show_bug.cgi?id=1765032 > > In order to get these into EPEL, they need to go into Fedora first, which > has its own (slow) process. In the meantime, these packages are easy to > build manually as one-offs (and may already have been built by David and > sitting in a temporary repo). > > To unblock this, what if we require that temporary repo for centos7 > *master* installs, and add it to the teuthology workers via > ceph-cm-ansible? The assumption is that by the time we release octopus we > will have gotten the dependencies in to the appropriate upstream repos. > That means we have until March 2020... 4 months away.
Update:
I just talked to Alfredo and the (current) blocker is cherrypy.. there are a zillion dependencies and the maintainer doesn't want to pull them in.
So, the current plan is now to drop centos7 support for octopus. That should simplify things drastically!
Quick update on this, we are working hard on trying to get cherrypy fully available, and we made some progress yesterday. Being able to
Alfredo, may I learn what progress it was? As I plan to build the python3-cherrypy package(s) on el7 to understand the efforts to ready its dependencies before moving on after returning home. So i am interested in where we are now.
concentrate on EPEL8 (CentOS8) is going to be a tremendous help.
We will follow Sage's suggestion of getting the packages into a self-hosted repo so that we don't have to wait (weeks!) for packages to become available officially.
sage
_______________________________________________ Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io
-- Regards Kefu Chai
_______________________________________________ Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io _______________________________________________
Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io
_______________________________________________ Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io
On Thu, Nov 07, 2019 at 08:02:07AM -0500, Alfredo Deza wrote:
On Wed, Nov 6, 2019 at 10:11 AM Sage Weil <sweil@redhat.com> wrote:
On Tue, 5 Nov 2019, Sage Weil wrote:
Hi everyone,
The transition to python3-only is blocked on three missing python packages in EPEL7:
- python36-werkzeug: tracked by https://bugzilla.redhat.com/show_bug.cgi?id=1545888 - python36-pecan: tracked by https://bugzilla.redhat.com/show_bug.cgi?id=1766839 - python36-cherrypy: tracked by https://bugzilla.redhat.com/show_bug.cgi?id=1765032
In order to get these into EPEL, they need to go into Fedora first, which has its own (slow) process. In the meantime, these packages are easy to build manually as one-offs (and may already have been built by David and sitting in a temporary repo).
To unblock this, what if we require that temporary repo for centos7 *master* installs, and add it to the teuthology workers via ceph-cm-ansible? The assumption is that by the time we release octopus we will have gotten the dependencies in to the appropriate upstream repos. That means we have until March 2020... 4 months away.
Update:
I just talked to Alfredo and the (current) blocker is cherrypy.. there are a zillion dependencies and the maintainer doesn't want to pull them in.
So, the current plan is now to drop centos7 support for octopus. That should simplify things drastically!
Quick update on this, we are working hard on trying to get cherrypy fully available, and we made some progress yesterday. Being able to concentrate on EPEL8 (CentOS8) is going to be a tremendous help. The ceph-volume's (vagrant based) functional tests currently rely a lot on centos7 (at least in name, seem like the tests actually download Fedora 22?). While I'd like to replace this testing infrastructure at some point, it works for now and its probably better to move them from Centos7/Fedora22 to Centos8/?. However there don't seem to be Centos8 vagrant images. Any pointers as to what to use instead?
We will follow Sage's suggestion of getting the packages into a self-hosted repo so that we don't have to wait (weeks!) for packages to become available officially.
sage
_______________________________________________ Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io
-- Jan Fajerski Senior Software Engineer Enterprise Storage SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
On Fri, Nov 8, 2019 at 3:09 AM Jan Fajerski <jfajerski@suse.com> wrote:
The ceph-volume's (vagrant based) functional tests currently rely a lot on centos7 (at least in name, seem like the tests actually download Fedora 22?). While I'd like to replace this testing infrastructure at some point, it works for now and its probably better to move them from Centos7/Fedora22 to Centos8/?. However there don't seem to be Centos8 vagrant images. Any pointers as to what to use instead?
The official CentOS 8 vagrant image work is tracked at https://bugs.centos.org/view.php?id=16455 , but there is no ETA for having that in the Vagrant cloud. - Ken
On Fri, Nov 8, 2019 at 5:09 AM Jan Fajerski <jfajerski@suse.com> wrote:
On Thu, Nov 07, 2019 at 08:02:07AM -0500, Alfredo Deza wrote:
On Wed, Nov 6, 2019 at 10:11 AM Sage Weil <sweil@redhat.com> wrote:
On Tue, 5 Nov 2019, Sage Weil wrote:
Hi everyone,
The transition to python3-only is blocked on three missing python packages in EPEL7:
- python36-werkzeug: tracked by https://bugzilla.redhat.com/show_bug.cgi?id=1545888 - python36-pecan: tracked by https://bugzilla.redhat.com/show_bug.cgi?id=1766839 - python36-cherrypy: tracked by https://bugzilla.redhat.com/show_bug.cgi?id=1765032
In order to get these into EPEL, they need to go into Fedora first, which has its own (slow) process. In the meantime, these packages are easy to build manually as one-offs (and may already have been built by David and sitting in a temporary repo).
To unblock this, what if we require that temporary repo for centos7 *master* installs, and add it to the teuthology workers via ceph-cm-ansible? The assumption is that by the time we release octopus we will have gotten the dependencies in to the appropriate upstream repos. That means we have until March 2020... 4 months away.
Update:
I just talked to Alfredo and the (current) blocker is cherrypy.. there are a zillion dependencies and the maintainer doesn't want to pull them in.
So, the current plan is now to drop centos7 support for octopus. That should simplify things drastically!
Quick update on this, we are working hard on trying to get cherrypy fully available, and we made some progress yesterday. Being able to concentrate on EPEL8 (CentOS8) is going to be a tremendous help. The ceph-volume's (vagrant based) functional tests currently rely a lot on centos7 (at least in name, seem like the tests actually download Fedora 22?).
All the tests use official Centos7 machines coming directly from the centos group in Vagrantcloud: https://github.com/ceph/ceph/blob/master/src/ceph-volume/ceph_volume/tests/f... Nothing uses Fedora.
While I'd like to replace this testing infrastructure at some point, it works for now and its probably better to move them from Centos7/Fedora22 to Centos8/?. However there don't seem to be Centos8 vagrant images. Any pointers as to what to use instead?
Like Ken pointed out, the official image is not there yet, once it is I think we can switch to it. There are community-based images (I created the bionic ones we use), so that is always a possibility if there is an urgent need.
We will follow Sage's suggestion of getting the packages into a self-hosted repo so that we don't have to wait (weeks!) for packages to become available officially.
sage
_______________________________________________ Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io
-- Jan Fajerski Senior Software Engineer Enterprise Storage SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
On Wed, Nov 6, 2019 at 4:11 PM Sage Weil <sweil@redhat.com> wrote:
On Tue, 5 Nov 2019, Sage Weil wrote:
Hi everyone,
The transition to python3-only is blocked on three missing python packages in EPEL7:
- python36-werkzeug: tracked by https://bugzilla.redhat.com/show_bug.cgi?id=1545888 - python36-pecan: tracked by https://bugzilla.redhat.com/show_bug.cgi?id=1766839 - python36-cherrypy: tracked by https://bugzilla.redhat.com/show_bug.cgi?id=1765032
In order to get these into EPEL, they need to go into Fedora first, which has its own (slow) process. In the meantime, these packages are easy to build manually as one-offs (and may already have been built by David and sitting in a temporary repo).
To unblock this, what if we require that temporary repo for centos7 *master* installs, and add it to the teuthology workers via ceph-cm-ansible? The assumption is that by the time we release octopus we will have gotten the dependencies in to the appropriate upstream repos. That means we have until March 2020... 4 months away.
Update:
I just talked to Alfredo and the (current) blocker is cherrypy.. there are a zillion dependencies and the maintainer doesn't want to pull them in.
So, the current plan is now to drop centos7 support for octopus. That should simplify things drastically!
Quick side question: I assume this means there will be no octopus centos7 clients either? Do we plan any octopus features that will require min_compat_client = nautilus ? Cheers, Dan
sage _______________________________________________ Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io
participants (8)
-
Alfredo Deza
-
Dan van der Ster
-
Jan Fajerski
-
kefu chai
-
Ken Dreyer
-
Lenz Grimmer
-
Sage Weil
-
Sage Weil