We found out today that all RC images for Atomic are broken. They are building against a much older yum repo (the beta repos) and thus have a very old systemd, which has some breakages with ostree. dgilmore and maxamillion have done some investigation and believe they have somewhat pinpointed the issue, although I don't know if they know of an exact fix yet.
This would have been caught by tunir/autocloud but tunir skips this test for atomic images. I have submitted a PR for it to not do that [1].
Right now the last booting atomic image is TC11. If we don't do another compose then we won't have an atomic image for release.
Dusty
On Wed, Oct 28, 2015 at 06:45:09PM -0400, Dusty Mabe wrote:
Right now the last booting atomic image is TC11. If we don't do another compose then we won't have an atomic image for release.
Can we release the two-week-atomic autocloud build?
On Wed, Oct 28, 2015, at 08:06 PM, Matthew Miller wrote:
On Wed, Oct 28, 2015 at 06:45:09PM -0400, Dusty Mabe wrote:
Right now the last booting atomic image is TC11. If we don't do another compose then we won't have an atomic image for release.
Can we release the two-week-atomic autocloud build?
My understanding in the state of https://bugzilla.redhat.com/show_bug.cgi?id=1276775#c4 is that F23 Atomic Host will release with the rest of F23, but I don't think it makes sense to do so with this bug.
Can we drop it out of the release set of images and then revisit doing it in two weeks?
On 10/30/2015 05:21 PM, Colin Walters wrote:
On Wed, Oct 28, 2015, at 08:06 PM, Matthew Miller wrote:
On Wed, Oct 28, 2015 at 06:45:09PM -0400, Dusty Mabe wrote:
Right now the last booting atomic image is TC11. If we don't do another compose then we won't have an atomic image for release.
Can we release the two-week-atomic autocloud build?
My understanding in the state of https://bugzilla.redhat.com/show_bug.cgi?id=1276775#c4 is that F23 Atomic Host will release with the rest of F23, but I don't think it makes sense to do so with this bug.
Can we drop it out of the release set of images and then revisit doing it in two weeks?
Question: Will this affect rpm-ostree upgrades?
Will workarounds be too onerous for 2 weeks?
I'm OK with pushing Atomic release out two weeks if we are relatively confident in a release and having this fixed by then. (That would be 17 November, right?)
Best,
jzb
On 10/30/2015 05:28 PM, Joe Brockmeier wrote:
On 10/30/2015 05:21 PM, Colin Walters wrote:
On Wed, Oct 28, 2015, at 08:06 PM, Matthew Miller wrote:
On Wed, Oct 28, 2015 at 06:45:09PM -0400, Dusty Mabe wrote:
Right now the last booting atomic image is TC11. If we don't do another compose then we won't have an atomic image for release.
Can we release the two-week-atomic autocloud build?
My understanding in the state of https://bugzilla.redhat.com/show_bug.cgi?id=1276775#c4 is that F23 Atomic Host will release with the rest of F23, but I don't think it makes sense to do so with this bug.
Can we drop it out of the release set of images and then revisit doing it in two weeks?
Question: Will this affect rpm-ostree upgrades?
I'm also interested in this question. I assume not but I don't know the answer. I say if we can deliver something and pretty soon after have a new tree users can upgrade to then that would be fine.
Dusty
On 10/28/2015 06:45 PM, Dusty Mabe wrote:
We found out today that all RC images for Atomic are broken. They are building against a much older yum repo (the beta repos) and thus have a very old systemd, which has some breakages with ostree. dgilmore and maxamillion have done some investigation and believe they have somewhat pinpointed the issue, although I don't know if they know of an exact fix yet.
This would have been caught by tunir/autocloud but tunir skips this test for atomic images. I have submitted a PR for it to not do that [1].
Right now the last booting atomic image is TC11. If we don't do another compose then we won't have an atomic image for release.
Due to some heroics by dgilmore we worked together last night and figured out how to work around this issue for now. That means we have some images to test and I think they have the right content. I would appreciate it if as many people as possible would grab some of these and test.
http://dl.fedoraproject.org/pub/alt/stage/23_RC9/Cloud_Images/x86_64/Images/
Thanks to imcleod, maxamillion, and roshi for helping out as well!
----- Original Message -----
From: "Dusty Mabe" dusty@dustymabe.com To: cloud@lists.fedoraproject.org Sent: Thursday, October 29, 2015 1:11:45 PM Subject: Re: RC* Atomic images are broken
On 10/28/2015 06:45 PM, Dusty Mabe wrote:
We found out today that all RC images for Atomic are broken. They are building against a much older yum repo (the beta repos) and thus have a very old systemd, which has some breakages with ostree. dgilmore and maxamillion have done some investigation and believe they have somewhat pinpointed the issue, although I don't know if they know of an exact fix yet.
This would have been caught by tunir/autocloud but tunir skips this test for atomic images. I have submitted a PR for it to not do that [1].
Right now the last booting atomic image is TC11. If we don't do another compose then we won't have an atomic image for release.
Due to some heroics by dgilmore we worked together last night and figured out how to work around this issue for now. That means we have some images to test and I think they have the right content. I would appreciate it if as many people as possible would grab some of these and test.
I tested the vagrant-libvirt atomic image. I'm unable to apply a provisioning script from my Vagrantfile. Vagrant can't copy my script to the VM, apparently because /sysroot/tmp has more restrictive permissions here than it did in the f22 image, 755 vs 777.
a bit more info here:
http://fpaste.org/285008/14461527/
Regards, Jason
http://dl.fedoraproject.org/pub/alt/stage/23_RC9/Cloud_Images/x86_64/Images/
Thanks to imcleod, maxamillion, and roshi for helping out as well!
cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
cloud@lists.stg.fedoraproject.org