So the 'canonical' list of release blocking images:
https://fedoraproject.org/wiki/Fedora_Program_Management/ReleaseBlocking/Fed...
has a 'yes' for the Cloud x86_64 network install image.
This seems suspicious to me. Who does network installs of the Cloud tree? Why would you want to do that? Why would it be a release-blocking deliverable?
I can't find a paper trail that explicitly indicates that people actually sat down and said "uh huh, yup, we're blocking on the netinst". https://fedorahosted.org/cloud/ticket/118%C2%A0is where the Cloud WG "signed off" on the blocking list for F23, but there's no specific discussion of the netinst there. Nor do I see any in https://meetbot.fedoraproject.org/fedora-meeting-1/2015-09-09/cloud_wg.2015-... .
I'm interested for the purpose of the daily check for missing images (right now this is done in my 'check-compose' tool and uses a list I made up myself called "expected images", which is not quite the same as the list of "release blocking deliverables"; but I want to move it into compose-utils and make it strictly a check for the canonical list of release-blocking images.)
On 1 Apr 2016 23:39, "Adam Williamson" adamwill@fedoraproject.org wrote:
So the 'canonical' list of release blocking images:
https://fedoraproject.org/wiki/Fedora_Program_Management/ReleaseBlocking/Fed...
has a 'yes' for the Cloud x86_64 network install image.
This seems suspicious to me. Who does network installs of the Cloud tree? Why would you want to do that? Why would it be a release-blocking deliverable?
Well I believe it's what's used to then install the qemu cloud and docker images so if it fails then all that use it in the creation process would fail which would make it release blocking due to dependency chains wouldn't it?
In terms of end users when I was looking at the primary mirror the other day I don't believe we even ship the cloud network installer.
Peter
On Sat, 2016-04-02 at 06:17 +0100, Peter Robinson wrote:
On 1 Apr 2016 23:39, "Adam Williamson" adamwill@fedoraproject.org wrote:
So the 'canonical' list of release blocking images:
https://fedoraproject.org/wiki/Fedora_Program_Management/ReleaseBlocking/Fed...
has a 'yes' for the Cloud x86_64 network install image.
This seems suspicious to me. Who does network installs of the Cloud tree? Why would you want to do that? Why would it be a release-blocking deliverable?
Well I believe it's what's used to then install the qemu cloud and docker images so if it fails then all that use it in the creation process would fail which would make it release blocking due to dependency chains wouldn't it?
That's an implementation detail. The 'release blocking images' list is (or ought to be) a higher level list: it's the images that *in and of themselves* we require to be present and meeting the various release criteria for a release to be shippable. In other words, I don't think the 'release blocking image' list should be transitive, that doesn't help anything. It just means we keep blocking on the netinst for no reason if the way we build the images we actually care about changes.
So the 'canonical' list of release blocking images:
https://fedoraproject.org/wiki/Fedora_Program_Management/ReleaseBlocking/Fed...
has a 'yes' for the Cloud x86_64 network install image.
This seems suspicious to me. Who does network installs of the Cloud tree? Why would you want to do that? Why would it be a release-blocking deliverable?
Well I believe it's what's used to then install the qemu cloud and docker images so if it fails then all that use it in the creation process would fail which would make it release blocking due to dependency chains wouldn't it?
That's an implementation detail. The 'release blocking images' list is (or ought to be) a higher level list: it's the images that *in and of themselves* we require to be present and meeting the various release criteria for a release to be shippable. In other words, I don't think the 'release blocking image' list should be transitive, that doesn't help anything. It just means we keep blocking on the netinst for no reason if the way we build the images we actually care about changes.
I completely agree with you, I wasn't trying to justify it being on the release blocking list, but rather explain how it might have got on the list.
Peter
On Saturday, April 2, 2016 6:17:54 AM CDT Peter Robinson wrote:
On 1 Apr 2016 23:39, "Adam Williamson" adamwill@fedoraproject.org wrote:
So the 'canonical' list of release blocking images:
https://fedoraproject.org/wiki/Fedora_Program_Management/ReleaseBlocking/Fed ora24
has a 'yes' for the Cloud x86_64 network install image.
This seems suspicious to me. Who does network installs of the Cloud tree? Why would you want to do that? Why would it be a release-blocking deliverable?
Well I believe it's what's used to then install the qemu cloud and docker images so if it fails then all that use it in the creation process would fail which would make it release blocking due to dependency chains wouldn't it?
It is what is used, to make the cloud images. if it by itself is release blocking, I am not sure, but if it does not work we have no cloud images. So it does have to work
In terms of end users when I was looking at the primary mirror the other day I don't believe we even ship the cloud network installer.
We do ship it, it goes into alt space along with Labs, it is not a primary cloud deliverable.
http://dl.fedoraproject.org/pub/alt/releases/test/24_Alpha/Cloud/
Dennis
On Mon, 2016-04-04 at 10:20 -0500, Dennis Gilmore wrote:
Well I believe it's what's used to then install the qemu cloud and docker images so if it fails then all that use it in the creation process would fail which would make it release blocking due to dependency chains wouldn't it?
It is what is used, to make the cloud images. if it by itself is release blocking, I am not sure, but if it does not work we have no cloud images. So it does have to work
Once again, this is an implementation detail that can change. The blocking image list is not a technical list but a policy list. So this alone does not justify the image's inclusion in the blocking image list.
It seems to me like we should ask jkurik to amend the list, because no- one seems to actually consider the image to be blocking in itself.
On Friday, April 8, 2016 12:47:37 PM CDT Adam Williamson wrote:
On Mon, 2016-04-04 at 10:20 -0500, Dennis Gilmore wrote:
Well I believe it's what's used to then install the qemu cloud and docker images so if it fails then all that use it in the creation process would fail which would make it release blocking due to dependency chains wouldn't it?
It is what is used, to make the cloud images. if it by itself is release blocking, I am not sure, but if it does not work we have no cloud images. So it does have to work
Once again, this is an implementation detail that can change. The blocking image list is not a technical list but a policy list. So this alone does not justify the image's inclusion in the blocking image list.
It seems to me like we should ask jkurik to amend the list, because no- one seems to actually consider the image to be blocking in itself.
his list os incomplete and wrong. we need something taht automatically tracks things as they change
Dennis
On Sat, 2016-04-09 at 16:08 -0500, Dennis Gilmore wrote:
his list os incomplete and wrong. we need something taht automatically tracks things as they change
I don't think it's possible to 'automate' the release blocking image list, because it's ultimately an entirely subjective, human decision whether a given image is 'release blocking' or not. But I think the idea of tracking it on an ornately-formatted wiki page is silly. Still, as long as that's the way we're doing it, I'm trying to ensure it's kept as up to date and accurate as possible.
Ultimately I think the canonical list should be in some kind of easily machine-readable format and any kind of human list should be produced from that. https://pagure.io/pungi/issue/249%C2%A0is one way of going about that, I guess.
On Sat, Apr 9, 2016 at 11:08 PM, Dennis Gilmore dennis@ausil.us wrote:
On Friday, April 8, 2016 12:47:37 PM CDT Adam Williamson wrote:
On Mon, 2016-04-04 at 10:20 -0500, Dennis Gilmore wrote:
Well I believe it's what's used to then install the qemu cloud and docker images so if it fails then all that use it in the creation process would fail which would make it release blocking due to dependency chains wouldn't it?
It is what is used, to make the cloud images. if it by itself is release blocking, I am not sure, but if it does not work we have no cloud images. So it does have to work
Once again, this is an implementation detail that can change. The blocking image list is not a technical list but a policy list. So this alone does not justify the image's inclusion in the blocking image list.
It seems to me like we should ask jkurik to amend the list, because no- one seems to actually consider the image to be blocking in itself.
his list os incomplete and wrong. we need something taht automatically tracks things as they change
I guess we talk about this page https://fedoraproject.org/wiki/Fedora_Program_Management/ReleaseBlocking/Fed... May I ask you Dennis to share with me (not necessary on this mailing list) what is wrong and what is missing ? The list on this page is what we have agreed with FESCo for F23 and I am not aware of any Change in the scope of F24 which made any significant changes.
Regards, Jan
Dennis _______________________________________________ cloud mailing list cloud@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
On Mon, 2016-04-11 at 10:31 +0200, Jan Kurik wrote:
On Sat, Apr 9, 2016 at 11:08 PM, Dennis Gilmore dennis@ausil.us wrote:
On Friday, April 8, 2016 12:47:37 PM CDT Adam Williamson wrote:
On Mon, 2016-04-04 at 10:20 -0500, Dennis Gilmore wrote:
Well I believe it's what's used to then install the qemu cloud and docker images so if it fails then all that use it in the creation process would fail which would make it release blocking due to dependency chains wouldn't it?
It is what is used, to make the cloud images. if it by itself is release blocking, I am not sure, but if it does not work we have no cloud images. So it does have to work
Once again, this is an implementation detail that can change. The blocking image list is not a technical list but a policy list. So this alone does not justify the image's inclusion in the blocking image list.
It seems to me like we should ask jkurik to amend the list, because no- one seems to actually consider the image to be blocking in itself.
his list os incomplete and wrong. we need something taht automatically tracks things as they change
I guess we talk about this page https://fedoraproject.org/wiki/Fedora_Program_Management/ReleaseBlocking/Fed... May I ask you Dennis to share with me (not necessary on this mailing list) what is wrong and what is missing ? The list on this page is what we have agreed with FESCo for F23 and I am not aware of any Change in the scope of F24 which made any significant changes.
The specific thing we're discussing is this line:
Cloud/x86_64/iso/Fedora-Cloud-netinst-x86_64-_RELEASE_MILESTONE_.iso yes Cloud WG
I'm suggesting that should say 'no', not 'yes'. I believe the fact that it was signed off with 'yes' was essentially an oversight, because I don't think Cloud's ever actually demonstrated any interest in making the Cloud network install image some kind of primary deliverable. It is not available *in any way at all* from https://getfedora.org/en/cloud/download/%C2%A0, for instance - not even stuck off to the side under 'Other Downloads'. It just isn't there.
As it happens, in our *current* image building process, that image has to build before we can build several of the images that the Cloud WG really does care about. But that's simply an implementation detail. The 'release blocking image list' is a *policy* thing, not a representation of the current implementation details of our release engineering processes. Saying the Cloud network install image is a 'release blocking image' suggests that it's something we really care about *in itself*, that it's something we expect people to use a lot and we care a lot if they try and use it and it doesn't. AIUI, that is not at all true.
For a thought experiment, say we were to change the image build process tomorrow so that all the Cloud images we actually care about - the qcows and the raws and the AMIs and the whatevers - could be built without first building the Cloud network install image, and then we did a compose where all those images showed up, but the Cloud network install image did not. Would anyone care? Would anyone shed a tear? Would we hold up the release in order to try and do a compose where the Cloud network image actually showed up?
If the answer to that question is 'no', then the image should not be listed as 'release blocking'.
On Tue, Apr 12, 2016 at 9:11 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Mon, 2016-04-11 at 10:31 +0200, Jan Kurik wrote:
On Sat, Apr 9, 2016 at 11:08 PM, Dennis Gilmore dennis@ausil.us wrote:
On Friday, April 8, 2016 12:47:37 PM CDT Adam Williamson wrote:
On Mon, 2016-04-04 at 10:20 -0500, Dennis Gilmore wrote:
Well I believe it's what's used to then install the qemu cloud and docker images so if it fails then all that use it in the creation process would fail which would make it release blocking due to dependency chains wouldn't it?
It is what is used, to make the cloud images. if it by itself is release blocking, I am not sure, but if it does not work we have no cloud images. So it does have to work
Once again, this is an implementation detail that can change. The blocking image list is not a technical list but a policy list. So this alone does not justify the image's inclusion in the blocking image list.
It seems to me like we should ask jkurik to amend the list, because no- one seems to actually consider the image to be blocking in itself.
his list os incomplete and wrong. we need something taht automatically tracks things as they change
I guess we talk about this page https://fedoraproject.org/wiki/Fedora_Program_Management/ReleaseBlocking/Fed... May I ask you Dennis to share with me (not necessary on this mailing list) what is wrong and what is missing ? The list on this page is what we have agreed with FESCo for F23 and I am not aware of any Change in the scope of F24 which made any significant changes.
The specific thing we're discussing is this line:
Cloud/x86_64/iso/Fedora-Cloud-netinst-x86_64-_RELEASE_MILESTONE_.iso yes Cloud WG
I'm suggesting that should say 'no', not 'yes'. I believe the fact that it was signed off with 'yes' was essentially an oversight, because I don't think Cloud's ever actually demonstrated any interest in making the Cloud network install image some kind of primary deliverable. It is not available *in any way at all* from https://getfedora.org/en/cloud/download/ , for instance - not even stuck off to the side under 'Other Downloads'. It just isn't there.
As it happens, in our *current* image building process, that image has to build before we can build several of the images that the Cloud WG really does care about. But that's simply an implementation detail. The 'release blocking image list' is a *policy* thing, not a representation of the current implementation details of our release engineering processes. Saying the Cloud network install image is a 'release blocking image' suggests that it's something we really care about *in itself*, that it's something we expect people to use a lot and we care a lot if they try and use it and it doesn't. AIUI, that is not at all true.
For a thought experiment, say we were to change the image build process tomorrow so that all the Cloud images we actually care about - the qcows and the raws and the AMIs and the whatevers - could be built without first building the Cloud network install image, and then we did a compose where all those images showed up, but the Cloud network install image did not. Would anyone care? Would anyone shed a tear? Would we hold up the release in order to try and do a compose where the Cloud network image actually showed up?
If the answer to that question is 'no', then the image should not be listed as 'release blocking'.
I have removed the image from the list of blocking deliverables. I also have requested a review by FESCo to make sure we are aligned https://fedorahosted.org/fesco/ticket/1566 .
Regards, Jan
-- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ cloud mailing list cloud@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
On Fri, Apr 8, 2016 at 9:47 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Mon, 2016-04-04 at 10:20 -0500, Dennis Gilmore wrote:
Well I believe it's what's used to then install the qemu cloud and docker images so if it fails then all that use it in the creation process would fail which would make it release blocking due to dependency chains wouldn't it?
It is what is used, to make the cloud images. if it by itself is release blocking, I am not sure, but if it does not work we have no cloud images. So it does have to work
Once again, this is an implementation detail that can change. The blocking image list is not a technical list but a policy list. So this alone does not justify the image's inclusion in the blocking image list.
It seems to me like we should ask jkurik to amend the list, because no- one seems to actually consider the image to be blocking in itself.
I can do this. Do we need to get FESCo attention here, as the scope of deliverables is typically part of Change process.
Regards, Jan
-- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ cloud mailing list cloud@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/cloud@lists.fedoraproject.org
On Fri, Apr 01, 2016 at 03:39:03PM -0700, Adam Williamson wrote:
So the 'canonical' list of release blocking images: https://fedoraproject.org/wiki/Fedora_Program_Management/ReleaseBlocking/Fed... has a 'yes' for the Cloud x86_64 network install image. This seems suspicious to me. Who does network installs of the Cloud tree? Why would you want to do that? Why would it be a release-blocking deliverable?
I think there was some discussion here a few years ago about people using the installer to create their own customized cloud images. Either way, it's probably good to revisit that.
-
Adam Williamson -
Dennis Gilmore -
Jan Kurik -
Matthew Miller -
Peter Robinson