Hi, folks!
So I noticed today that F24 nightly composes are missing Cloud images. This is, I think, because 32-bit Cloud image generation is still enabled for F24, and it's failing due to the known kernel bug preventing 32-bit boot working at all:
http://koji.fedoraproject.org/koji/taskinfo?taskID=13434747 http://koji.fedoraproject.org/koji/taskinfo?taskID=13434766 https://kojipkgs.fedoraproject.org//work/tasks/4766/13434766/screenshot.ppm
I believe when the i386 image build fails the Koji task fails, and when the Koji task fails Pungi just doesn't pull in any of the images - even though the x86_64 subtask succeeded and built images.
Obviously we could consider solving that in Pungi somehow, but it led me to wondering whether we actually want 32-bit image generation enabled at all any more. It seems from this ticket:
https://fedorahosted.org/cloud/ticket/106
and this meeting discussion:
https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2015-09-09/cloud_wg.2...
that the intent was to 'sunset' the i386 images in the F24 cycle. I'm not sure whether that means you still want them built, or not. So can the WG please clarify if they still want i386 Cloud images to be built at all? If not, releng can disable them in the Pungi config.
Thanks!
On 03/23/2016 01:48 PM, Adam Williamson wrote:
Hi, folks!
So I noticed today that F24 nightly composes are missing Cloud images. This is, I think, because 32-bit Cloud image generation is still enabled for F24, and it's failing due to the known kernel bug preventing 32-bit boot working at all:
http://koji.fedoraproject.org/koji/taskinfo?taskID=13434747 http://koji.fedoraproject.org/koji/taskinfo?taskID=13434766 https://kojipkgs.fedoraproject.org//work/tasks/4766/13434766/screenshot.ppm
I believe when the i386 image build fails the Koji task fails, and when the Koji task fails Pungi just doesn't pull in any of the images - even though the x86_64 subtask succeeded and built images.
Obviously we could consider solving that in Pungi somehow, but it led me to wondering whether we actually want 32-bit image generation enabled at all any more. It seems from this ticket:
https://fedorahosted.org/cloud/ticket/106
and this meeting discussion:
https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2015-09-09/cloud_wg.2...
that the intent was to 'sunset' the i386 images in the F24 cycle. I'm not sure whether that means you still want them built, or not. So can the WG please clarify if they still want i386 Cloud images to be built at all? If not, releng can disable them in the Pungi config.
I don't know if it was every properly communicated to the public, but I definitely don't want to see 32 bit images any longer.
Did we ever put a post up on fedmag about this? Can we do one now?
Dusty
On Wed, 2016-03-23 at 14:37 -0400, Dusty Mabe wrote:
On 03/23/2016 01:48 PM, Adam Williamson wrote:
Hi, folks!
So I noticed today that F24 nightly composes are missing Cloud images. This is, I think, because 32-bit Cloud image generation is still enabled for F24, and it's failing due to the known kernel bug preventing 32-bit boot working at all:
http://koji.fedoraproject.org/koji/taskinfo?taskID=13434747 http://koji.fedoraproject.org/koji/taskinfo?taskID=13434766 https://kojipkgs.fedoraproject.org//work/tasks/4766/13434766/screenshot.ppm
I believe when the i386 image build fails the Koji task fails, and when the Koji task fails Pungi just doesn't pull in any of the images - even though the x86_64 subtask succeeded and built images.
Obviously we could consider solving that in Pungi somehow, but it led me to wondering whether we actually want 32-bit image generation enabled at all any more. It seems from this ticket:
https://fedorahosted.org/cloud/ticket/106
and this meeting discussion:
https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2015-09-09/cloud_wg.2...
that the intent was to 'sunset' the i386 images in the F24 cycle. I'm not sure whether that means you still want them built, or not. So can the WG please clarify if they still want i386 Cloud images to be built at all? If not, releng can disable them in the Pungi config.
I don't know if it was every properly communicated to the public, but I definitely don't want to see 32 bit images any longer.
Well no-one else has replied for the last week, so that may be the best we're gonna get...Dennis, maybe we can just go ahead and turn the damn things off now?
Did we ever put a post up on fedmag about this? Can we do one now?
I don't recall ever seeing one.
On 03/30/2016 07:27 PM, Adam Williamson wrote:
Well no-one else has replied for the last week, so that may be the best we're gonna get...Dennis, maybe we can just go ahead and turn the damn things off now?
+1
I can't think of any reason to continue to produce 32 bit images, especially at this late date. As far as I can tell, they only provide user confusion and an unnecessary limitation on scaling, and probably should have been eliminated years ago.
On 23/03/16, Dusty Mabe wrote:
I don't know if it was every properly communicated to the public, but I definitely don't want to see 32 bit images any longer.
Yes, we are supposed to drop the 32 bit images as decided during Flock, how can we go ahead and do this?
Did we ever put a post up on fedmag about this? Can we do one now?
No iirc. We may want to do one.
Kushal
On 03/31/2016 02:17 PM, Kushal Das wrote:
Did we ever put a post up on fedmag about this? Can we do one now?
No iirc. We may want to do one.
Hed: Retiring 32-bit Cloud Images
Body: The Fedora Cloud Working Group has decided to retire the 32-bit Cloud images. As of the __ release, we will no longer produce the 32-bit images. We will, of course, continue to make 64-bit cloud images available.
Why are we doing this? We've been producing 32-bit images for years, and it's a solved problem, right? Surely it's as easy as "just keep doing it," right?
Not so much. There are several reasons we're retiring them. First and foremost, our data suggests that 32-bit images are not that popular. That doesn't mean *no one* uses 32-bit images, but the user community for 32-bit only seems to be passingly small.
The second reason is that 32-bit packages and images require their own testing. If it was as simple as a little bit of CPU time and disk space to produce images, we'd just keep doing it until the number of users hit zero. But it has a human cost in terms of time and opportunity lost doing one thing when we could do another. So we've chosen to focus on 64-bit images, working on making Atomic Host more awesome, and other work.
If you have questions, feel free to ask in #fedora-cloud on Freenode, or ask on cloud@lists.fedoraproject.org.
# # #
Thoughts?
Best,
jzb
On 03/31/2016 12:05 PM, Joe Brockmeier wrote:
On 03/31/2016 02:17 PM, Kushal Das wrote:
Did we ever put a post up on fedmag about this? Can we do one now?
No iirc. We may want to do one.
Hed: Retiring 32-bit Cloud Images
Body: The Fedora Cloud Working Group has decided to retire the 32-bit Cloud images. As of the __ release, we will no longer produce the 32-bit images. We will, of course, continue to make 64-bit cloud images available.
Why are we doing this? We've been producing 32-bit images for years, and it's a solved problem, right? Surely it's as easy as "just keep doing it," right?
Not so much. There are several reasons we're retiring them. First and foremost, our data suggests that 32-bit images are not that popular. That doesn't mean *no one* uses 32-bit images, but the user community for 32-bit only seems to be passingly small.
The second reason is that 32-bit packages and images require their own testing. If it was as simple as a little bit of CPU time and disk space to produce images, we'd just keep doing it until the number of users hit zero. But it has a human cost in terms of time and opportunity lost doing one thing when we could do another. So we've chosen to focus on 64-bit images, working on making Atomic Host more awesome, and other work.
If you have questions, feel free to ask in #fedora-cloud on Freenode, or ask on cloud@lists.fedoraproject.org.
# # #
+1
On 03/31/2016 03:05 PM, Joe Brockmeier wrote:
On 03/31/2016 02:17 PM, Kushal Das wrote:
Did we ever put a post up on fedmag about this? Can we do one now?
No iirc. We may want to do one.
Hed: Retiring 32-bit Cloud Images
Body: The Fedora Cloud Working Group has decided to retire the 32-bit Cloud images. As of the __ release, we will no longer produce the 32-bit images. We will, of course, continue to make 64-bit cloud images available.
Why are we doing this? We've been producing 32-bit images for years, and it's a solved problem, right? Surely it's as easy as "just keep doing it," right?
Not so much. There are several reasons we're retiring them. First and foremost, our data suggests that 32-bit images are not that popular. That doesn't mean *no one* uses 32-bit images, but the user community for 32-bit only seems to be passingly small.
The second reason is that 32-bit packages and images require their own testing. If it was as simple as a little bit of CPU time and disk space to produce images, we'd just keep doing it until the number of users hit zero. But it has a human cost in terms of time and opportunity lost doing one thing when we could do another. So we've chosen to focus on 64-bit images, working on making Atomic Host more awesome, and other work.
If you have questions, feel free to ask in #fedora-cloud on Freenode, or ask on cloud@lists.fedoraproject.org.
# # #Thoughts?
Looks good to me.
Dusty
+1 from me also.
On Thu, Mar 31, 2016 at 2:10 PM, Dusty Mabe dusty@dustymabe.com wrote:
On 03/31/2016 03:05 PM, Joe Brockmeier wrote:
On 03/31/2016 02:17 PM, Kushal Das wrote:
Did we ever put a post up on fedmag about this? Can we do one now?
No iirc. We may want to do one.
Hed: Retiring 32-bit Cloud Images
Body: The Fedora Cloud Working Group has decided to retire the 32-bit Cloud images. As of the __ release, we will no longer produce the 32-bit images. We will, of course, continue to make 64-bit cloud images
available.
Why are we doing this? We've been producing 32-bit images for years, and it's a solved problem, right? Surely it's as easy as "just keep doing it," right?
Not so much. There are several reasons we're retiring them. First and foremost, our data suggests that 32-bit images are not that popular. That doesn't mean *no one* uses 32-bit images, but the user community for 32-bit only seems to be passingly small.
The second reason is that 32-bit packages and images require their own testing. If it was as simple as a little bit of CPU time and disk space to produce images, we'd just keep doing it until the number of users hit zero. But it has a human cost in terms of time and opportunity lost doing one thing when we could do another. So we've chosen to focus on 64-bit images, working on making Atomic Host more awesome, and other
work.
If you have questions, feel free to ask in #fedora-cloud on Freenode, or ask on cloud@lists.fedoraproject.org.
# # #Thoughts?
Looks good to me.
Dusty _______________________________________________ cloud mailing list cloud@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
On 2016-03-31 12:05, Joe Brockmeier wrote:
Body: The Fedora Cloud Working Group has decided to retire the 32-bit Cloud images. As of the __ release, we will no longer produce the 32-bit images. We will, of course, continue to make 64-bit cloud images available.
Why are we doing this? We've been producing 32-bit images for years, and it's a solved problem, right? Surely it's as easy as "just keep doing it," right?
Not so much. There are several reasons we're retiring them. First and foremost, our data suggests that 32-bit images are not that popular. That doesn't mean *no one* uses 32-bit images, but the user community for 32-bit only seems to be passingly small.
I think that announcement sounds great. I am also quite interested in seeing those data -- I didn't think most public clouds published statistics.
On Thu, 2016-03-31 at 23:47 +0530, Kushal Das wrote:
On 23/03/16, Dusty Mabe wrote:
I don't know if it was every properly communicated to the public, but I definitely don't want to see 32 bit images any longer.
Yes, we are supposed to drop the 32 bit images as decided during Flock, how can we go ahead and do this?
Technically speaking all you have to do is tell releng. It's more or less a single switch to flip in the Fedora pungi config. Other good things to do are announce it, and update any relevant documentation / policies / processes; remove the images from the list at https://fedoraproject.org/wiki/Fedora_Program_Management/ReleaseBlockin g/Fedora24 , for instance.
-
Adam Williamson -
Clint Savage -
Dusty Mabe -
Garrett Holmstrom -
Joe Brockmeier -
Josh Berkus -
Kushal Das -
Michael Hampton