What is the current policy for Stream ISO's? It seems that it's currently only one week which is problematic when trying to maintain your own packer templates and having to constantly update the filename and checksums. It seems as though long term, this method doesn't bode well for maintainability.
Would it be possible to do one of the following?
1. Offer a filename symlink to the "current" build? 2. Offer an ISO that exists longer than a week? 3. Host archived ISOs on vault (or somewhere else) with some saner retention
Thanks-
+1 for symlink of the most recent build. IMO it's always good idea.
When it comes to the packer templates and checksums, you might be able to do the following:
1. the first option - instead of fixed checksum use the following `file://https://link/to/checksums%60 like in the example at https://www.packer.io /docs/builders/qemu. I have never tried this, but this **might** work
2. the second option is to parse checksum file (probably from URL) manually. Export checksum as an environment variable, add variables block to packer template that maps envs to local variables, then use variables. It could look like:
``` //IN BUILDER "iso_checksum": "sha1:{{user `iso_checksum`}}", "iso_url": "{{user `iso_url`}}", //Variables are in root of packer json "variables": { "iso_checksum": "{{env `ISO_CHECKSUM`}}", "iso_url": "{{env `ISO_NAME`}}", } ```
You might probably simplify this by using `env` instead of `user` and removing variables block. I never thought about this because our packer templates are a little bit more complicated, and using environment variables as the only way to fill template helps us keep build in check.
Best, Alex
On 5/28/21 6:55 PM, Lance Albertson wrote:
What is the current policy for Stream ISO's? It seems that it's currently only one week which is problematic when trying to maintain your own packer templates and having to constantly update the filename and checksums. It seems as though long term, this method doesn't bode well for maintainability.
Would it be possible to do one of the following?
- Offer a filename symlink to the "current" build?
- Offer an ISO that exists longer than a week?
- Host archived ISOs on vault (or somewhere else) with some saner retention
Thanks-
-- Lance Albertson Director Oregon State University | Open Source Lab
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Sat, May 29, 2021 at 7:50 AM aleksander.baranowski via CentOS-devel < centos-devel@centos.org> wrote:
+1 for symlink of the most recent build. IMO it's always good idea.
When it comes to the packer templates and checksums, you might be able to do the following:
- the first option - instead of fixed checksum use the following
`file://https://link/to/checksums%60 like in the example at https://www.packer.io/docs/builders/qemu. I have never tried this, but this **might** work
Oh nice, I hadn't noticed this as a feature before! Of course, this requires having the symlink in place for this to work properly.
CentOS Mirror Admins: Any chance this could happen? Where should I file an issue for this?
- the second option is to parse checksum file (probably from URL)
manually. Export checksum as an environment variable, add variables block to packer template that maps envs to local variables, then use variables. It could look like:
Yeah, this might work but I'm not sure in this specific use case as I'm not the one controlling how the image gets built. Thanks for pointing this out!
//IN BUILDER "iso_checksum": "sha1:{{user `iso_checksum`}}", "iso_url": "{{user `iso_url`}}", //Variables are in root of packer json "variables": { "iso_checksum": "{{env `ISO_CHECKSUM`}}", "iso_url": "{{env `ISO_NAME`}}", }You might probably simplify this by using `env` instead of `user` and removing variables block. I never thought about this because our packer templates are a little bit more complicated, and using environment variables as the only way to fill template helps us keep build in check.
Best, Alex
On 5/28/21 6:55 PM, Lance Albertson wrote:
What is the current policy for Stream ISO's? It seems that it's currently only one week which is problematic when trying to maintain your own packer templates and having to constantly update the filename and checksums. It seems as though long term, this method doesn't bode well for maintainability.
Would it be possible to do one of the following?
- Offer a filename symlink to the "current" build?
- Offer an ISO that exists longer than a week?
- Host archived ISOs on vault (or somewhere else) with some saner
retention
Thanks-
-- Lance Albertson Director Oregon State University | Open Source Lab
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
There isn't a policy per say, we just rsync the ISOs that pungi generates, with the delete flag. It may be tempting to suggest "just don't use the delete flag", but that is unreasonable from a disk space perspective. I just checked the latest compose and the isos directory totals 27GB. We are doing new composes roughly weekly. Generating an extra 27GB worth of files every week, for ourselves and all mirrors, doesn't sound appealing.
Would a "latest" symlink be useful, even if there is only one set of ISOs available? Are you actually interested in getting the previous ISOs, or do you just want a download URL that doesn't change?
On Fri, May 28, 2021 at 11:56 AM Lance Albertson lance@osuosl.org wrote:
What is the current policy for Stream ISO's? It seems that it's currently only one week which is problematic when trying to maintain your own packer templates and having to constantly update the filename and checksums. It seems as though long term, this method doesn't bode well for maintainability.
Would it be possible to do one of the following?
- Offer a filename symlink to the "current" build?
- Offer an ISO that exists longer than a week?
- Host archived ISOs on vault (or somewhere else) with some saner retention
Thanks-
-- Lance Albertson Director Oregon State University | Open Source Lab _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Tue, Jun 1, 2021 at 12:58 PM Carl George carl@redhat.com wrote:
There isn't a policy per say, we just rsync the ISOs that pungi generates, with the delete flag. It may be tempting to suggest "just don't use the delete flag", but that is unreasonable from a disk space perspective. I just checked the latest compose and the isos directory totals 27GB. We are doing new composes roughly weekly. Generating an extra 27GB worth of files every week, for ourselves and all mirrors, doesn't sound appealing.
As a project who mirrors your content, I agree, this would not work in the long run :-)
Would a "latest" symlink be useful, even if there is only one set of ISOs available? Are you actually interested in getting the previous ISOs, or do you just want a download URL that doesn't change?
Yes, I think that would be the best option. It would work for a variety of automation tools as well. Please do the same with the checksum file.
Thanks!
On Fri, May 28, 2021 at 11:56 AM Lance Albertson lance@osuosl.org wrote:
What is the current policy for Stream ISO's? It seems that it's
currently only one week which is problematic when trying to maintain your own packer templates and having to constantly update the filename and checksums. It seems as though long term, this method doesn't bode well for maintainability.
Would it be possible to do one of the following?
- Offer a filename symlink to the "current" build?
- Offer an ISO that exists longer than a week?
- Host archived ISOs on vault (or somewhere else) with some saner
retention
Thanks-
-- Lance Albertson Director Oregon State University | Open Source Lab _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
-- Carl George
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
Please do the same with the checksum file.
I'm not sure I understand. The CHECKSUM file doesn't have a datestamp on it, and thus already is a URL that doesn't change.
On Tue, Jun 1, 2021 at 3:43 PM Lance Albertson lance@osuosl.org wrote:
On Tue, Jun 1, 2021 at 12:58 PM Carl George carl@redhat.com wrote:
There isn't a policy per say, we just rsync the ISOs that pungi generates, with the delete flag. It may be tempting to suggest "just don't use the delete flag", but that is unreasonable from a disk space perspective. I just checked the latest compose and the isos directory totals 27GB. We are doing new composes roughly weekly. Generating an extra 27GB worth of files every week, for ourselves and all mirrors, doesn't sound appealing.
As a project who mirrors your content, I agree, this would not work in the long run :-)
Would a "latest" symlink be useful, even if there is only one set of ISOs available? Are you actually interested in getting the previous ISOs, or do you just want a download URL that doesn't change?
Yes, I think that would be the best option. It would work for a variety of automation tools as well. Please do the same with the checksum file.
Thanks!
On Fri, May 28, 2021 at 11:56 AM Lance Albertson lance@osuosl.org wrote:
What is the current policy for Stream ISO's? It seems that it's currently only one week which is problematic when trying to maintain your own packer templates and having to constantly update the filename and checksums. It seems as though long term, this method doesn't bode well for maintainability.
Would it be possible to do one of the following?
- Offer a filename symlink to the "current" build?
- Offer an ISO that exists longer than a week?
- Host archived ISOs on vault (or somewhere else) with some saner retention
Thanks-
-- Lance Albertson Director Oregon State University | Open Source Lab _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
-- Carl George
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
-- Lance Albertson Director Oregon State University | Open Source Lab _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Tue, Jun 1, 2021 at 3:32 PM Carl George carl@redhat.com wrote:
Please do the same with the checksum file.
I'm not sure I understand. The CHECKSUM file doesn't have a datestamp on it, and thus already is a URL that doesn't change.
My bad, I hadn't noticed that :-)
Thanks!
On Tue, Jun 1, 2021 at 3:40 PM Lance Albertson lance@osuosl.org wrote:
On Tue, Jun 1, 2021 at 3:32 PM Carl George carl@redhat.com wrote:
Please do the same with the checksum file.
I'm not sure I understand. The CHECKSUM file doesn't have a datestamp on it, and thus already is a URL that doesn't change.
My bad, I hadn't noticed that :-)
Actually, let me clarify what I mean. The CHECKSUM file should also list the file(s) with the "latest" name in them for the check to work properly (I think). Otherwise it will fail using packer. Let me test it on my end to confirm that.
On Tue, Jun 1, 2021 at 3:43 PM Lance Albertson lance@osuosl.org wrote:
On Tue, Jun 1, 2021 at 3:40 PM Lance Albertson lance@osuosl.org wrote:
On Tue, Jun 1, 2021 at 3:32 PM Carl George carl@redhat.com wrote:
Please do the same with the checksum file.
I'm not sure I understand. The CHECKSUM file doesn't have a datestamp on it, and thus already is a URL that doesn't change.
My bad, I hadn't noticed that :-)
Actually, let me clarify what I mean. The CHECKSUM file should also list the file(s) with the "latest" name in them for the check to work properly (I think). Otherwise it will fail using packer. Let me test it on my end to confirm that.
Confirmed. This needs to have the "latest" iso file(s) in the CHECKSUM file as well otherwise it will fail.
Would you mind opening a bugzilla for this? It's not something we can implement right away as we're pretty busy with 8.4 stuff, and I don't want to lose track of it.
https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20L...
On Tue, Jun 1, 2021 at 5:54 PM Lance Albertson lance@osuosl.org wrote:
On Tue, Jun 1, 2021 at 3:43 PM Lance Albertson lance@osuosl.org wrote:
On Tue, Jun 1, 2021 at 3:40 PM Lance Albertson lance@osuosl.org wrote:
On Tue, Jun 1, 2021 at 3:32 PM Carl George carl@redhat.com wrote:
Please do the same with the checksum file.
I'm not sure I understand. The CHECKSUM file doesn't have a datestamp on it, and thus already is a URL that doesn't change.
My bad, I hadn't noticed that :-)
Actually, let me clarify what I mean. The CHECKSUM file should also list the file(s) with the "latest" name in them for the check to work properly (I think). Otherwise it will fail using packer. Let me test it on my end to confirm that.
Confirmed. This needs to have the "latest" iso file(s) in the CHECKSUM file as well otherwise it will fail.
-- Lance Albertson Director Oregon State University | Open Source Lab _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Tue, Jun 1, 2021 at 4:18 PM Carl George carl@redhat.com wrote:
Would you mind opening a bugzilla for this? It's not something we can implement right away as we're pretty busy with 8.4 stuff, and I don't want to lose track of it.
https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20L...
Done: https://bugzilla.redhat.com/show_bug.cgi?id=1966812
-
aleksander.baranowski -
Carl George -
Lance Albertson