upgrading an original soft probe
i have a probe, 1000004, on a deb 10 vm that was installed in the rotterdam hackathon. the detritus looks as if it was built using a deb install of atlasswprobe-5000-1.deb. two days ago, it stopped working in some way; i have not pursued, figuring i was dealing with an antique. is there a path to make it current? randy
Hi Randy, You may try and build a 5080 package, then upgrade from debian. I’d keep a backup of the keys in /var/atlas-probe/etc (top of my head) just in case. Cheers, Michel
On 10 Feb 2023, at 17:27, Randy Bush <randy@psg.com> wrote:
i have a probe, 1000004, on a deb 10 vm that was installed in the rotterdam hackathon. the detritus looks as if it was built using a deb install of atlasswprobe-5000-1.deb.
two days ago, it stopped working in some way; i have not pursued, figuring i was dealing with an antique.
is there a path to make it current?
randy
-- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
michael
You may try and build a 5080 package, then upgrade from debian. I’d keep a backup of the keys in /var/atlas-probe/etc (top of my head) just in case.
is there a path where a simple `apt update; apt upgrade` will work ongoing? building and installing debs is soooo last century. and where are the instructions to find 5080 and build that deb? randy
Am Freitag, 10. Februar 2023, 18:17:23 CET schrieb Randy Bush:
michael
You may try and build a 5080 package, then upgrade from debian. I’d keep a backup of the keys in /var/atlas-probe/etc (top of my head) just in case.
is there a path where a simple `apt update; apt upgrade` will work ongoing? building and installing debs is soooo last century.
did you miss that thread ? https://www.ripe.net/ripe/mail/archives/ripe-atlas/2023-January/ thread.html#5322 A long discussion without results. I would also to be happy to have a repository, so the atlas gets updated, when I update the OS/packages. (apt upgrade, zypper update) Even announcement here doesn't work. Sometimes I see my hw probe has a higher version number than my sw probes and it is not easy to find out why. Regards, Thomas
did you miss that thread ?
https://www.ripe.net/ripe/mail/archives/ripe-atlas/2023-January/thread.html#...
what a a classic bikeshed discussion. i want docker, i want rpm, i want comic sans.
I would also to be happy to have a repository, so the atlas gets updated, when I update the OS/packages.
doh. but that's too simple and obvious. and even worse, it would be useful. sigh. i guess i will just let the soft probe(s) die. randy
Hello Thomas, The code of the software probe is the same as for the hardware probes, however the release process currently involves manual steps. This means that there can be a little while between one platform and the next being released. Sorry about that, we’re working very hard on automating this. Cheers, Michel
On 11 Feb 2023, at 12:21, Thomas Schäfer <tschaefer@t-online.de> wrote:
Am Freitag, 10. Februar 2023, 18:17:23 CET schrieb Randy Bush:
michael
You may try and build a 5080 package, then upgrade from debian. I’d keep a backup of the keys in /var/atlas-probe/etc (top of my head) just in case.
is there a path where a simple `apt update; apt upgrade` will work ongoing? building and installing debs is soooo last century.
did you miss that thread ?
https://www.ripe.net/ripe/mail/archives/ripe-atlas/2023-January/ thread.html#5322
A long discussion without results.
I would also to be happy to have a repository, so the atlas gets updated, when I update the OS/packages. (apt upgrade, zypper update) Even announcement here doesn't work. Sometimes I see my hw probe has a higher version number than my sw probes and it is not easy to find out why.
Regards, Thomas
-- ripe-atlas mailing list ripe-atlas@ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas
Hello Randy, We are currently actually looking at providing packages for other distributions, through the regular repositories of the distribution. However that means we have to work pieces of the software probe to comply to distribution standards. I cannot guarantee right now whether Debian will be provided, but this is something I would personally like to see. You can find the instructions here: https://github.com/RIPE-NCC/ripe-atlas-software-probe/blob/master/INSTALL.rst ripe-atlas-software-probe/INSTALL.rst at master · RIPE-NCC/ripe-atlas-software-probe github.com When checking out, use “git checkout 5080” to checkout the 5080 tag. Let me know how it works! Cheers, Michel
On 10 Feb 2023, at 18:17, Randy Bush <randy@psg.com> wrote:
michael
You may try and build a 5080 package, then upgrade from debian. I’d keep a backup of the keys in /var/atlas-probe/etc (top of my head) just in case.
is there a path where a simple `apt update; apt upgrade` will work ongoing? building and installing debs is soooo last century.
and where are the instructions to find 5080 and build that deb?
randy
Hello Michel, On Sun, 12 Feb 2023 at 22:51, Michel Stam <mstam@ripe.net> wrote:
Hello Randy,
We are currently actually looking at providing packages for other distributions, through the regular repositories of the distribution. However that means we have to work pieces of the software probe to comply to distribution standards. I cannot guarantee right now whether Debian will be provided, but this is something I would personally like to see.
For third party package maintainers and users willing to compile from source: What is the currently released version of the atlas-software-probe? HW probes seem to be running 5080. On the git repository we have the following tags: 2022 Sep 19: 5080 was tagged 2022 Nov 30: 5083 was tagged 2022 Dec 9: 5082 was tagged 2023 Feb 24: 5081 was tagged 2023 Feb 28: 5084 was tagged Is 5080 the current release, which HW probes are running, and the newer tags in the source code repository should be ignored? Is 5084 the current release, but HW probes are lagging behind? Why did we see decreasing versioning tags from November to February? Where can a third party package maintainer (or a user compiling from source) find authoritative information about what the latest atlas SW probe actually is? There is only a single branch in the git repository, which is master. However while the 5080 tag seems to be in the master branch, the newer tags are not, so I guess that means 5080 is indeed the last properly released version. But I really don't like to guess and I don't see how anyone not directly involved in the SW development of the probe would be able to package it considering the ambiguity in the source code repository. Thanks, Lukas
Hi Lukas! Sorry for the delay in response, I was off for a few days and for some reason your mail got buried beneath a pile of other mail. Let me give you a bit of a background; About a year or so ago we set up a CI/CD pipeline for the software and hardware probes. The intent being that the software would be built by a clean platform every single time a commit was tagged for building, or if any of the major branches were updated. This all happens from an internal repository that is not publicly accessible. Somewhere around that time we also started with a new development strategy. A master branch which contains production-ready code. This is the code that users can deploy on their own setup, and it is also the code that the RPMs and the hardware probe firmware will be built on. A testing branch on which the master branch is essentially a pointer. The testing branch contains code that is being readied for the next production release A devel(opment) branch that contains code which is by its nature feature complete, but may not be fully tested yet. This code is merged into the testing branch upon completion and unit testing. Ticket branches that run off the development branch and contain features that may or may not work Out of all of this, only the tags and master branch pointers are automatically synced from the internal repository to the GitHub repository. This is by intent to discourage people from deploying code which is not feature complete. For sake of transparency, as well as convenience, this code is visible. Well spotted! :) The versioning is your next implied question- any number divisible by 10 is a production release (5060, 5070, 5080). Any other number is either a development or a testing release. I would recommend to use the master branch or any tag which is divisible by 10, which in essence would be a (previous) production release. As to decreasing numbers. At the time there were two people working on different features at the same time, some of which we were both testing on different probe platforms simultaneously. One was working on 5083 the other on 5081/2. Ugly, yes. I believe I was restructuring for the version 3 hardware probe at that time. Ideally we would sync only the release tags and not the development tags, but unfortunately that is not how the internal repository (Gitlab) works. The current released version is 5080. I’m working on the next release as we speak, which will include a restructure to accommodate providing packages to the RHEL repositories. I’m interested in talking to debian distribution maintainers who are willing to help do the same for Debian. OpenWRT is also something I’ll be looking at. Short and simple. Master contains the latest production code. Use it in good health :) Cheers, Michel
On 4 Jun 2023, at 20:03, Lukas Tribus <lukas@ltri.eu> wrote:
Hello Michel,
On Sun, 12 Feb 2023 at 22:51, Michel Stam <mstam@ripe.net> wrote:
Hello Randy,
We are currently actually looking at providing packages for other distributions, through the regular repositories of the distribution. However that means we have to work pieces of the software probe to comply to distribution standards. I cannot guarantee right now whether Debian will be provided, but this is something I would personally like to see.
For third party package maintainers and users willing to compile from source:
What is the currently released version of the atlas-software-probe?
HW probes seem to be running 5080.
On the git repository we have the following tags:
2022 Sep 19: 5080 was tagged 2022 Nov 30: 5083 was tagged 2022 Dec 9: 5082 was tagged 2023 Feb 24: 5081 was tagged 2023 Feb 28: 5084 was tagged
Is 5080 the current release, which HW probes are running, and the newer tags in the source code repository should be ignored? Is 5084 the current release, but HW probes are lagging behind? Why did we see decreasing versioning tags from November to February? Where can a third party package maintainer (or a user compiling from source) find authoritative information about what the latest atlas SW probe actually is?
There is only a single branch in the git repository, which is master. However while the 5080 tag seems to be in the master branch, the newer tags are not, so I guess that means 5080 is indeed the last properly released version.
But I really don't like to guess and I don't see how anyone not directly involved in the SW development of the probe would be able to package it considering the ambiguity in the source code repository.
Thanks,
Lukas
Hello Michel, thank you for clarifying. Can we bring those very useful informations (master is production ready; releases are tags based on master divisible by 10, tags non divisible by 10 need to be ignored) into README.rst? Are you accepting PR's or patches? I think what would also help is if you would create a github release with a source tarball. We are only looking at tags because of the absence of GH releases. Formal announcements of new production releases on this mailing list would also help (basically everyone involved with RIPE atlas). It's important to demystify the repository and release process, and for this information not only be in one old mail in the list archives. FWIW OpenWRT is already packaging atlas, it seems to work and the response on packaging related bugs [1] is also very fast [2]. Thanks, Lukas [1] https://github.com/openwrt/packages/issues/20338 [2] https://github.com/openwrt/packages/commit/dc39bbef1452047eb22d78445e30644d2... On Thu, 8 Jun 2023 at 11:29, Michel Stam <mstam@ripe.net> wrote:
Hi Lukas!
Sorry for the delay in response, I was off for a few days and for some reason your mail got buried beneath a pile of other mail.
Let me give you a bit of a background;
About a year or so ago we set up a CI/CD pipeline for the software and hardware probes. The intent being that the software would be built by a clean platform every single time a commit was tagged for building, or if any of the major branches were updated. This all happens from an internal repository that is not publicly accessible.
Somewhere around that time we also started with a new development strategy.
A master branch which contains production-ready code. This is the code that users can deploy on their own setup, and it is also the code that the RPMs and the hardware probe firmware will be built on. A testing branch on which the master branch is essentially a pointer. The testing branch contains code that is being readied for the next production release A devel(opment) branch that contains code which is by its nature feature complete, but may not be fully tested yet. This code is merged into the testing branch upon completion and unit testing. Ticket branches that run off the development branch and contain features that may or may not work
Out of all of this, only the tags and master branch pointers are automatically synced from the internal repository to the GitHub repository. This is by intent to discourage people from deploying code which is not feature complete. For sake of transparency, as well as convenience, this code is visible. Well spotted! :)
The versioning is your next implied question- any number divisible by 10 is a production release (5060, 5070, 5080). Any other number is either a development or a testing release. I would recommend to use the master branch or any tag which is divisible by 10, which in essence would be a (previous) production release.
As to decreasing numbers. At the time there were two people working on different features at the same time, some of which we were both testing on different probe platforms simultaneously. One was working on 5083 the other on 5081/2. Ugly, yes. I believe I was restructuring for the version 3 hardware probe at that time. Ideally we would sync only the release tags and not the development tags, but unfortunately that is not how the internal repository (Gitlab) works.
The current released version is 5080. I’m working on the next release as we speak, which will include a restructure to accommodate providing packages to the RHEL repositories. I’m interested in talking to debian distribution maintainers who are willing to help do the same for Debian. OpenWRT is also something I’ll be looking at.
Short and simple. Master contains the latest production code. Use it in good health :)
Cheers,
Michel
On 4 Jun 2023, at 20:03, Lukas Tribus <lukas@ltri.eu> wrote:
Hello Michel,
On Sun, 12 Feb 2023 at 22:51, Michel Stam <mstam@ripe.net> wrote:
Hello Randy,
We are currently actually looking at providing packages for other distributions, through the regular repositories of the distribution. However that means we have to work pieces of the software probe to comply to distribution standards. I cannot guarantee right now whether Debian will be provided, but this is something I would personally like to see.
For third party package maintainers and users willing to compile from source:
What is the currently released version of the atlas-software-probe?
HW probes seem to be running 5080.
On the git repository we have the following tags:
2022 Sep 19: 5080 was tagged 2022 Nov 30: 5083 was tagged 2022 Dec 9: 5082 was tagged 2023 Feb 24: 5081 was tagged 2023 Feb 28: 5084 was tagged
Is 5080 the current release, which HW probes are running, and the newer tags in the source code repository should be ignored? Is 5084 the current release, but HW probes are lagging behind? Why did we see decreasing versioning tags from November to February? Where can a third party package maintainer (or a user compiling from source) find authoritative information about what the latest atlas SW probe actually is?
There is only a single branch in the git repository, which is master. However while the 5080 tag seems to be in the master branch, the newer tags are not, so I guess that means 5080 is indeed the last properly released version.
But I really don't like to guess and I don't see how anyone not directly involved in the SW development of the probe would be able to package it considering the ambiguity in the source code repository.
Thanks,
Lukas
participants (4)
-
Lukas Tribus -
Michel Stam -
Randy Bush -
Thomas Schäfer