It's been a while since libvirt-snmp was actively developed. Now it receives only libvirt-ci related commits. The code compiles with net-snmp-5.9.3 but the freshly released net-snmp-5.9.4 [1] breaks compilation [2]. Now, libvirt-snmp has this crazy architecture, where some sources are manually generated from src/LIBVIRT-MIB.txt, then edited (added code to talk to libvirt) and then added to git. This is labor extensive and since I don't think libvirt-snmp is actually used I'd like to sunset it. According to repology [3] only Gentoo (and its clones) has the latest version (released ~5 years ago). And I doubt it has any real users there. Thoughts? 1: https://sourceforge.net/projects/net-snmp/files/net-snmp/5.9.4/ 2: https://bugs.gentoo.org/show_bug.cgi?id=912582 2: https://repology.org/project/libvirt-snmp/versions Michal
On Mon, Aug 21, 2023 at 10:32:42AM +0200, Michal Prívozník wrote:
It's been a while since libvirt-snmp was actively developed. Now it receives only libvirt-ci related commits. The code compiles with net-snmp-5.9.3 but the freshly released net-snmp-5.9.4 [1] breaks compilation [2]. Now, libvirt-snmp has this crazy architecture, where some sources are manually generated from src/LIBVIRT-MIB.txt, then edited (added code to talk to libvirt) and then added to git.
This is labor extensive and since I don't think libvirt-snmp is actually used I'd like to sunset it. According to repology [3] only Gentoo (and its clones) has the latest version (released ~5 years ago). And I doubt it has any real users there.
Thoughts?
1: https://sourceforge.net/projects/net-snmp/files/net-snmp/5.9.4/ 2: https://bugs.gentoo.org/show_bug.cgi?id=912582 2: https://repology.org/project/libvirt-snmp/versions
Michal
Per our private discussion Michal, Peter, and I concluded that archiving the project in GitLab is a harmless operation that can be undone at any point in time, so I went ahead and toggled the flag. Regards, Erik
On Tue, Aug 22, 2023 at 01:26:47PM +0200, Erik Skultety wrote:
On Mon, Aug 21, 2023 at 10:32:42AM +0200, Michal Prívozník wrote:
It's been a while since libvirt-snmp was actively developed. Now it receives only libvirt-ci related commits. The code compiles with net-snmp-5.9.3 but the freshly released net-snmp-5.9.4 [1] breaks compilation [2]. Now, libvirt-snmp has this crazy architecture, where some sources are manually generated from src/LIBVIRT-MIB.txt, then edited (added code to talk to libvirt) and then added to git.
This is labor extensive and since I don't think libvirt-snmp is actually used I'd like to sunset it. According to repology [3] only Gentoo (and its clones) has the latest version (released ~5 years ago). And I doubt it has any real users there.
Thoughts?
1: https://sourceforge.net/projects/net-snmp/files/net-snmp/5.9.4/ 2: https://bugs.gentoo.org/show_bug.cgi?id=912582 2: https://repology.org/project/libvirt-snmp/versions
Michal
Per our private discussion Michal, Peter, and I concluded that archiving the project in GitLab is a harmless operation that can be undone at any point in time, so I went ahead and toggled the flag.
Yes, archiving is the right thing to do in this scenario, and is trivially reversed. We've already got a bunch of other archived repos :-) With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Tue, Aug 22, 2023 at 12:44:16PM +0100, Daniel P. Berrangé wrote:
On Tue, Aug 22, 2023 at 01:26:47PM +0200, Erik Skultety wrote:
On Mon, Aug 21, 2023 at 10:32:42AM +0200, Michal Prívozník wrote:
It's been a while since libvirt-snmp was actively developed. Now it receives only libvirt-ci related commits. The code compiles with net-snmp-5.9.3 but the freshly released net-snmp-5.9.4 [1] breaks compilation [2]. Now, libvirt-snmp has this crazy architecture, where some sources are manually generated from src/LIBVIRT-MIB.txt, then edited (added code to talk to libvirt) and then added to git.
This is labor extensive and since I don't think libvirt-snmp is actually used I'd like to sunset it. According to repology [3] only Gentoo (and its clones) has the latest version (released ~5 years ago). And I doubt it has any real users there.
Thoughts?
Per our private discussion Michal, Peter, and I concluded that archiving the project in GitLab is a harmless operation that can be undone at any point in time, so I went ahead and toggled the flag.
Yes, archiving is the right thing to do in this scenario, and is trivially reversed. We've already got a bunch of other archived repos :-)
We should clean up the container registry for this and other archived repositories too. I'm betting they take up a non-trivial amount of our group's storage quota for no good reason. -- Andrea Bolognani / Red Hat / Virtualization
On Thu, Aug 31, 2023 at 08:09:05AM -0700, Andrea Bolognani wrote:
On Tue, Aug 22, 2023 at 12:44:16PM +0100, Daniel P. Berrangé wrote:
On Tue, Aug 22, 2023 at 01:26:47PM +0200, Erik Skultety wrote:
On Mon, Aug 21, 2023 at 10:32:42AM +0200, Michal Prívozník wrote:
It's been a while since libvirt-snmp was actively developed. Now it receives only libvirt-ci related commits. The code compiles with net-snmp-5.9.3 but the freshly released net-snmp-5.9.4 [1] breaks compilation [2]. Now, libvirt-snmp has this crazy architecture, where some sources are manually generated from src/LIBVIRT-MIB.txt, then edited (added code to talk to libvirt) and then added to git.
This is labor extensive and since I don't think libvirt-snmp is actually used I'd like to sunset it. According to repology [3] only Gentoo (and its clones) has the latest version (released ~5 years ago). And I doubt it has any real users there.
Thoughts?
Per our private discussion Michal, Peter, and I concluded that archiving the project in GitLab is a harmless operation that can be undone at any point in time, so I went ahead and toggled the flag.
Yes, archiving is the right thing to do in this scenario, and is trivially reversed. We've already got a bunch of other archived repos :-)
We should clean up the container registry for this and other archived repositories too. I'm betting they take up a non-trivial amount of our group's storage quota for no good reason.
Turns out you can't delete containers if the project is archived :-) So I've temporarily unarchived it, and am deleting the containers and all the CI pipelines too, which should eliminate all major storage usage. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Mon, Aug 21, 2023 at 10:32:42AM +0200, Michal Prívozník wrote:
It's been a while since libvirt-snmp was actively developed. Now it receives only libvirt-ci related commits. The code compiles with net-snmp-5.9.3 but the freshly released net-snmp-5.9.4 [1] breaks compilation [2]. Now, libvirt-snmp has this crazy architecture, where some sources are manually generated from src/LIBVIRT-MIB.txt, then edited (added code to talk to libvirt) and then added to git.
I'm also strongly inclined to archive the following: * libvirt-cim Similar situation to SNMP binding, CIM is an outdated way to interact with libvirt that hasn't been developed in years and I doubt anyone uses it. * libvirt-appdev-guide-python * libvirt-publican The publican toolchain was removed from Fedora, and the build in Debian is broken. While I can probably fixe the Debian build, I'm not especially inclined to invest in this since we're not actively adding content to this doc. If we ever did take it forward again I'd probably suggest it be ported to Sphinx / RST instead of Docbook. * libvirt-sandbox * libvirt-sandbox-image The Kata and libkrun projects both conceptually overlap with what this tried to do and are actually actively used and developed unlike this. * libvirt-designer This project is dormant as we never put all that much investment into it, and I don't see it being useful to apps in future either With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Thu, Aug 31, 2023 at 04:53:47PM +0100, Daniel P. Berrangé wrote:
I'm also strongly inclined to archive the following:
* libvirt-cim * libvirt-appdev-guide-python * libvirt-publican * libvirt-sandbox * libvirt-sandbox-image * libvirt-designer
Sounds good to me. It will save us some effort if we don't need to keep these repositories up to our standards (mainly in terms of CI) while they're seeing zero actual development. -- Andrea Bolognani / Red Hat / Virtualization
On Fri, Sep 01, 2023 at 02:15:59AM -0700, Andrea Bolognani wrote:
On Thu, Aug 31, 2023 at 04:53:47PM +0100, Daniel P. Berrangé wrote:
I'm also strongly inclined to archive the following:
* libvirt-cim * libvirt-appdev-guide-python * libvirt-publican * libvirt-sandbox * libvirt-sandbox-image * libvirt-designer
Sounds good to me. It will save us some effort if we don't need to keep these repositories up to our standards (mainly in terms of CI) while they're seeing zero actual development.
Fine by me. If you haven't done so yet, I'll unleash https://gitlab.com/eskultety/gitlab_cleaner to clean the pipelines. Erik
On Fri, Sep 01, 2023 at 11:39:34AM +0200, Erik Skultety wrote:
On Fri, Sep 01, 2023 at 02:15:59AM -0700, Andrea Bolognani wrote:
On Thu, Aug 31, 2023 at 04:53:47PM +0100, Daniel P. Berrangé wrote:
I'm also strongly inclined to archive the following:
* libvirt-cim * libvirt-appdev-guide-python * libvirt-publican * libvirt-sandbox * libvirt-sandbox-image * libvirt-designer
Sounds good to me. It will save us some effort if we don't need to keep these repositories up to our standards (mainly in terms of CI) while they're seeing zero actual development.
Fine by me. If you haven't done so yet, I'll unleash https://gitlab.com/eskultety/gitlab_cleaner to clean the pipelines.
Ok, if you run the pipeline cleaner on those 6 repos, I'll purge the container images, then we toggle to archived. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Fri, Sep 01, 2023 at 10:41:26AM +0100, Daniel P. Berrangé wrote:
On Fri, Sep 01, 2023 at 11:39:34AM +0200, Erik Skultety wrote:
On Fri, Sep 01, 2023 at 02:15:59AM -0700, Andrea Bolognani wrote:
On Thu, Aug 31, 2023 at 04:53:47PM +0100, Daniel P. Berrangé wrote:
I'm also strongly inclined to archive the following:
* libvirt-cim * libvirt-appdev-guide-python * libvirt-publican * libvirt-sandbox * libvirt-sandbox-image * libvirt-designer
Sounds good to me. It will save us some effort if we don't need to keep these repositories up to our standards (mainly in terms of CI) while they're seeing zero actual development.
Fine by me. If you haven't done so yet, I'll unleash https://gitlab.com/eskultety/gitlab_cleaner to clean the pipelines.
Ok, if you run the pipeline cleaner on those 6 repos, I'll purge the container images, then we toggle to archived.
Looks like we worked in parallel :), all of the above are now archived. Erik
participants (4)
-
Andrea Bolognani -
Daniel P. Berrangé -
Erik Skultety -
Michal Prívozník