[EPEL-devel] Re: Upgrade to rdiff-backup in EPEL-7
On Mon, Apr 20, 2020 at 6:55 PM Frank Crawford wrote: > Lance, > > Just to add a bit more on some of Kevin's comments, this does not break > any of your backups and existing backups are both readable and writable > with both versions. What is broken is the backup process in some cases, as > a Python3 master cannot talk to a Python2 slave, and visa-versa. > Thanks for that clarification! That's kind of what I assumed based on what you said. > It would not be as simple as having both installed, as you also need to > select which version you are attempting to talk to on the remote machine, > and the default configuration assumes that the name is the same on the > remote machine, although this is changeable, if you know the full command > syntax. > Noted > I will probably make a special version of rdiff-backup v1.2.8 that can be > parallel installed available on COPR, but it won't be part of EPEL, as, for > example EPEL-8 will only have rdiff-backup v2. I'm just in discussion with > packagers for other distributions to get some common naming for such a > package, and it is generally agree that we need the latest version to be > rdiff-backup. > Sounds good and that makes sense as well. > Also, it is only on a master server, i.e. one invoking remote backups, > that you would need have two versions, and some method of selection which > one you want to run based on the slave's version. This could be as simple > as two separate backup jobs or a much more complicate script. > > Regards > Frank > > On Mon, 2020-04-20 at 09:59 -0700, Lance Albertson wrote: > > What does the upgrade path look like from if folks are currently creating > backups using 1.x and they suddenly switch to 2.x? Is there an upgrade > path? Is there a way in EPEL to allow for both versions to exist to ease > migration? i.e. maybe by creating rdiff-backup2 which > supercedes rdiff-backup. > > Ideally, it would be nice to have some kind of an upgrade path so we don't > end up breaking all of our backups. > > I went ahead and added 'rdiff-backup-2*' to our excludes to be safe until we're ready for the upgrade globally. Thanks for all the hard work! I'm looking forward to getting all of our systems upgraded. > Thanks- > > On Mon, Apr 20, 2020 at 6:33 AM Frank Crawford > wrote: > > We have pushed into testing and intend to eventually release a new version > of rdiff-backup which has a significant incompatibly with the current > distributed version, when used in client-server mode. > > The current version is v1.2.8 and written in Python2, while the new > version is v2.0.0 and written in Python3, and the language change breaks > client-server mode, due to incompatible data representations between > Python2 and Python3. In all other respects the two versions are compatible > including the ability to read and write existing backup repositories. > > It should be noted that the v1.2.8 was released over 11 years ago and > while a small number of bug fixes have been added by the community, there > has been no co-ordinated work for a number of years, and no further > development will occur on the Python2 version. All future work, > enhancements and bugfixes, including security bugfixes, will be to the > Python3 version. > > If it is necessary to stay with the Python2 version, it is recommended > that you exclude rdiff-backup from future updates. > > Also, if you are testing the Python3 update in EPEL-7 (and EPEL-8) some of > the dependencies (python3-pyxattr and py3libacl) are also in the testing > repositories. > > If you have any questions about the update, please contact me. > > Frank Crawford > FAS: frankcrawford > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org > > > > ___ > > epel-devel mailing list -- > > epel-devel@lists.fedoraproject.org > > > To unsubscribe send an email to > > epel-devel-le...@lists.fedoraproject.org > > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > > List Guidelines: > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > > List Archives: > > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org > > > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/a
[EPEL-devel] Re: Upgrade to rdiff-backup in EPEL-7
Lance, Just to add a bit more on some of Kevin's comments, this does not break any of your backups and existing backups are both readable and writable with both versions. What is broken is the backup process in some cases, as a Python3 master cannot talk to a Python2 slave, and visa- versa. It would not be as simple as having both installed, as you also need to select which version you are attempting to talk to on the remote machine, and the default configuration assumes that the name is the same on the remote machine, although this is changeable, if you know the full command syntax. I will probably make a special version of rdiff-backup v1.2.8 that can be parallel installed available on COPR, but it won't be part of EPEL, as, for example EPEL-8 will only have rdiff-backup v2. I'm just in discussion with packagers for other distributions to get some common naming for such a package, and it is generally agree that we need the latest version to be rdiff-backup. Also, it is only on a master server, i.e. one invoking remote backups, that you would need have two versions, and some method of selection which one you want to run based on the slave's version. This could be as simple as two separate backup jobs or a much more complicate script. RegardsFrank On Mon, 2020-04-20 at 09:59 -0700, Lance Albertson wrote: > What does the upgrade path look like from if folks are currently > creating backups using 1.x and they suddenly switch to 2.x? Is there > an upgrade path? Is there a way in EPEL to allow for both versions to > exist to ease migration? i.e. maybe by creating rdiff-backup2 which > supercedes rdiff-backup. > > Ideally, it would be nice to have some kind of an upgrade path so we > don't end up breaking all of our backups. > > Thanks- > > On Mon, Apr 20, 2020 at 6:33 AM Frank Crawford < > fr...@crawford.emu.id.au> wrote: > > We have pushed into testing and intend to eventually release a new > > version of rdiff-backup which has a significant incompatibly with > > the current distributed version, when used in client-server mode. > > > > The current version is v1.2.8 and written in Python2, while the new > > version is v2.0.0 and written in Python3, and the language change > > breaks client-server mode, due to incompatible data representations > > between Python2 and Python3. In all other respects the two > > versions are compatible including the ability to read and write > > existing backup repositories. > > > > It should be noted that the v1.2.8 was released over 11 years ago > > and while a small number of bug fixes have been added by the > > community, there has been no co-ordinated work for a number of > > years, and no further development will occur on the Python2 > > version. All future work, enhancements and bugfixes, including > > security bugfixes, will be to the Python3 version. > > > > If it is necessary to stay with the Python2 version, it is > > recommended that you exclude rdiff-backup from future updates. > > > > Also, if you are testing the Python3 update in EPEL-7 (and EPEL-8) > > some of the dependencies (python3-pyxattr and py3libacl) are also > > in the testing repositories. > > > > If you have any questions about the update, please contact me. > > > > Frank Crawford > > FAS: frankcrawford > > ___ > > > > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > > > > To unsubscribe send an email to > > epel-devel-le...@lists.fedoraproject.org > > > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > > > List Guidelines: > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > > > List Archives: > > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org > > > > > ___epel-devel mailing > list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to > epel-devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Upgrade to rdiff-backup in EPEL-7
On Mon, Apr 20, 2020 at 09:59:17AM -0700, Lance Albertson wrote: > What does the upgrade path look like from if folks are currently creating > backups using 1.x and they suddenly switch to 2.x? Is there an upgrade > path? Is there a way in EPEL to allow for both versions to exist to ease > migration? i.e. maybe by creating rdiff-backup2 which > supercedes rdiff-backup. > > Ideally, it would be nice to have some kind of an upgrade path so we don't > end up breaking all of our backups. You can stay on the old 1.2 version on all machines and keep on the way you have been. Of course it won't get any updates or fixes, but thats pretty much been the case for the last N years anyhow. Just 'exclude=rdiff-backup-2*' in your yum.conf. For new installs you can get it from koji or from Frank's copr. If you upgrade to 2.0, you need to do so on all clients and servers at the same time so they can talk to each other. The existing backups you have on disk will work with either version. Does that help clarify any? kevin -- > > Thanks- > > On Mon, Apr 20, 2020 at 6:33 AM Frank Crawford > wrote: > > > We have pushed into testing and intend to eventually release a new version > > of rdiff-backup which has a significant incompatibly with the current > > distributed version, when used in client-server mode. > > > > The current version is v1.2.8 and written in Python2, while the new > > version is v2.0.0 and written in Python3, and the language change breaks > > client-server mode, due to incompatible data representations between > > Python2 and Python3. In all other respects the two versions are compatible > > including the ability to read and write existing backup repositories. > > > > It should be noted that the v1.2.8 was released over 11 years ago and > > while a small number of bug fixes have been added by the community, there > > has been no co-ordinated work for a number of years, and no further > > development will occur on the Python2 version. All future work, > > enhancements and bugfixes, including security bugfixes, will be to the > > Python3 version. > > > > If it is necessary to stay with the Python2 version, it is recommended > > that you exclude rdiff-backup from future updates. > > > > Also, if you are testing the Python3 update in EPEL-7 (and EPEL-8) some of > > the dependencies (python3-pyxattr and py3libacl) are also in the testing > > repositories. > > > > If you have any questions about the update, please contact me. > > > > Frank Crawford > > FAS: frankcrawford > > ___ > > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org > > > > > -- > Lance Albertson > Director > Oregon State University | Open Source Lab > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Upgrade to rdiff-backup in EPEL-7
What does the upgrade path look like from if folks are currently creating backups using 1.x and they suddenly switch to 2.x? Is there an upgrade path? Is there a way in EPEL to allow for both versions to exist to ease migration? i.e. maybe by creating rdiff-backup2 which supercedes rdiff-backup. Ideally, it would be nice to have some kind of an upgrade path so we don't end up breaking all of our backups. Thanks- On Mon, Apr 20, 2020 at 6:33 AM Frank Crawford wrote: > We have pushed into testing and intend to eventually release a new version > of rdiff-backup which has a significant incompatibly with the current > distributed version, when used in client-server mode. > > The current version is v1.2.8 and written in Python2, while the new > version is v2.0.0 and written in Python3, and the language change breaks > client-server mode, due to incompatible data representations between > Python2 and Python3. In all other respects the two versions are compatible > including the ability to read and write existing backup repositories. > > It should be noted that the v1.2.8 was released over 11 years ago and > while a small number of bug fixes have been added by the community, there > has been no co-ordinated work for a number of years, and no further > development will occur on the Python2 version. All future work, > enhancements and bugfixes, including security bugfixes, will be to the > Python3 version. > > If it is necessary to stay with the Python2 version, it is recommended > that you exclude rdiff-backup from future updates. > > Also, if you are testing the Python3 update in EPEL-7 (and EPEL-8) some of > the dependencies (python3-pyxattr and py3libacl) are also in the testing > repositories. > > If you have any questions about the update, please contact me. > > Frank Crawford > FAS: frankcrawford > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org > -- Lance Albertson Director Oregon State University | Open Source Lab ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
