fedora_cloud_meeting
LOGS
16:00:45 <davdunc> #startmeeting fedora_cloud_meeting
16:00:45 <zodbot> Meeting started Thu Feb  3 16:00:45 2022 UTC.
16:00:45 <zodbot> This meeting is logged and archived in a public location.
16:00:45 <zodbot> The chair is davdunc. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:00:45 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:45 <zodbot> The meeting name has been set to 'fedora_cloud_meeting'
16:01:01 <davdunc> #topic roll call
16:02:50 <davdunc> looks like it's a busy day for everyone.
16:03:19 <davdunc> gonna wait until 5 minutes after the hour and go for action items.
16:05:15 <davdunc> #topic Action items from last meeting
16:05:33 * davdunc davdunc to create the wiki checklist for launch
16:06:14 <davdunc> We have a wiki checklist page now and it needs populating before we are releasing images for F36
16:06:26 <davdunc> #link https://fedoraproject.org/wiki/Cloud/Release_Checklist
16:07:00 * davdunc mhayden to attempt packaging of gsutil and re-evaluate gcloud after
16:08:28 <davdunc> mhayden is busy today with other responsibilities, but he reported earlier in #fedora-cloud that he was running into legacy python (2.7) requirements and that it was not going as well as hoped. More on this when he frees up.
16:08:52 * davdunc davdunc to follow up with jdoss on driving the adoption on ignition
16:09:51 <davdunc> we have both been busy, so this hasn't come together just yet. It's still on our list of things todo though. We'll follow it in a ticket for now and I won't leave it on the meetings actionable items.
16:10:12 * davdunc davdunc to look at image upload using libcloud
16:11:45 <davdunc> looked into it as an alternative to gcloud. It looks like there is some dependencies here that we need to review. There is really only support right now for the storage side in fedora. We would need to take it on for packaging as well.
16:12:05 <davdunc> okay. on to the meeting items.
16:13:11 <davdunc> #topic 342  Review the product requirements document
16:13:19 <dustymabe> .hi
16:13:20 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:13:28 <davdunc> #chair dustymabe
16:13:28 <zodbot> Current chairs: davdunc dustymabe
16:13:32 <copperi[m]> .hi
16:13:33 <davdunc> hey dustymabe !
16:13:34 <zodbot> copperi[m]: Sorry, but user 'copperi [m]' does not exist
16:13:37 <dustymabe> hey davdunc
16:13:46 <davdunc> #chair copperi[m]
16:13:46 <zodbot> Current chairs: copperi[m] davdunc dustymabe
16:13:55 <davdunc> awesome.
16:14:21 <davdunc> I just wanted to add that this topic is ongoing.
16:14:39 <davdunc> #link https://pagure.io/cloud-sig/issue/342
16:15:06 <davdunc> And that I should probably open this up to broader discussion and modifications on the mailing list.
16:15:25 <dustymabe> +1
16:16:22 <davdunc> probably should also be a blocking issue for the edition status too.
16:16:50 <davdunc> okay. I'll open up a couple of threads on the mailing list for discussion and we can review next meeting time.
16:16:57 <davdunc> next topic.
16:17:12 <davdunc> dustymabe: was there something you wanted to cover ?
16:17:18 <dustymabe> nothing from my side
16:17:30 <davdunc> okay. then I am going to go down the list.
16:18:12 <davdunc> #topic 345 Formally deprecating BIOS boot support (*not* retiring it!)
16:19:08 <davdunc> it's probably too early to think about fully retiring the classic boot, but identifying as deprecated could be helpful to focus the community on next steps.
16:19:32 <davdunc> We have several providers IIRC who are still dependent on classic boot.
16:19:39 <dustymabe> +1
16:20:28 <davdunc> Any ideas on how we should identify that it is deprecated? I am thinking that's the kind of news that warrants a blog post.
16:20:55 <dustymabe> we probably should be careful in how we communicate it
16:21:23 <davdunc> yes. I don't think it should read as an ultimatum. It should read as a request for comments.
16:21:29 <dustymabe> deprecated has a strong connotation might be useful to use another word
16:21:44 <davdunc> that's a great point.
16:21:51 <dustymabe> then we'd need to file a change request and communicate it to the broder community
16:21:56 <dustymabe> i.e. Fedora Magazine
16:22:11 <dustymabe> maybe we should position it as "Moving to UEFI as default" or something
16:22:24 <davdunc> yea. I think an editorial piece that suggests it by argument.
16:22:49 <davdunc> then wait and see what the resulting response looks like.
16:23:23 <davdunc> if there are a lot of users who want to maintain classic boot, then we are already set to support them. There is no reason to leave anyone behind.
16:24:49 <davdunc> okay. I think I'll add that as the next step in the ticket. I'll keep the meeting flag and next meeting, when we have more attendees, I'll look for an author or co-author for the blog post.
16:25:57 <davdunc> #action davdunc to return to the issue 345 in next meeting to secure an author or co-author for blog post for community comment.
16:26:08 <davdunc> okay.
16:27:33 <davdunc> #topic 347 IPv6 endpoints are now available for the Amazon EC2 Instance Metadata Service, Amazon Time Sync Service, and Amazon VPC DNS Server
16:27:46 <davdunc> #link https://pagure.io/cloud-sig/issue/347
16:28:14 <dustymabe> yay ipv6
16:28:17 <davdunc> The Amazon EC2 Instance Metadata Service, Amazon Time Sync Service, and Amazon VPC DNS server can now be accessed over IPv6 endpoints by instances built on the Nitro System.
16:28:17 <davdunc> To use them we need to enable the IPv6 endpoint for IMDS on EC2 ks.cfg, The Amazon Time Sync and Amazon VPC DNS IPv6 endpoints are accessible in every region.
16:29:03 <davdunc> Is this something we might explore as being a cloud-init default?
16:30:06 <dustymabe> "enable the IPv6 endpoint for IMDS on EC2 ks.cfg" - what does that mean?
16:30:20 <davdunc> we can modify the content of the ks.cfg if necessary, but it might be more beneficial if it came from identifying the environment at boot.
16:30:41 <davdunc> dustymabe: I think it means modify the config in the kickstart for the ec2 cloud image.
16:30:57 <davdunc> I don't think I want to be that granular if we don't have to be.
16:31:17 <dustymabe> yeah would be nice if we could inherit that from somewhere else
16:31:24 <dustymabe> i.e. have cloud-init do the right thing
16:31:28 <davdunc> I would rather have it be determined and enabled from a system that is meant to read instance metadata.
16:32:27 <davdunc> okay. I think that's the direction we should explore, i.e., how do we make this work as a result of the ec2 instance metadata support and not in case of the metadata support.
16:33:54 <davdunc> okay. updated. I'll work on determining what the right plan of action is here with the cloud-init team.
16:34:35 <davdunc> #action davdunc work with cloud-init folks to find out how to enable at instance launch using cloud-init.
16:35:09 <davdunc> #topic 355 Add AZURE image testing
16:35:17 <davdunc> #link https://pagure.io/cloud-sig/issue/355
16:35:40 <davdunc> dustymabe: you have this plumbed up in the FCOS testing framework.
16:35:55 <davdunc> is there a way to get this working through Fedora CI as well, you think?
16:36:18 <davdunc> or maybe we should combine forces here?
16:38:03 <davdunc> I'd like to explore what our options are here with the QA team. I'll talk to Sumantro and adamw about what they think the best path forward looks like.
16:38:30 <davdunc> #action davdunc to discuss options for including in the standard QA process.
16:39:23 <davdunc> #action davdunc to discuss Azure testing with QA team to determine how to best plumb the tests and return results effectively.
16:41:40 <davdunc> #topic 365 Please publish AWS aarch64 AMI for Fedora 35
16:41:55 <davdunc> #link https://pagure.io/cloud-sig/issue/365
16:42:00 <davdunc> This is still not working.
16:43:00 <davdunc> #action davdunc to review with the website crew what is missing from their ingestion scripting that prevents the aarch64 images from being populated on the website.
16:43:32 <davdunc> we'll revisit next meeting tiem, but I'll try to have the full story at least, if it's not resolved.
16:44:44 <davdunc> this should also be considered blocking for the F37 cloud edition status.
16:45:03 <davdunc> okay.
16:45:14 <davdunc> That's all I have for the list
16:45:22 <davdunc> #topic Open Floor
16:45:32 <davdunc> The floor is open for additional discussion.
16:45:51 <dustymabe> davdunc: sorry got pulled awa7
16:45:53 <dustymabe> away
16:45:59 <davdunc> understood dustymabe
16:46:08 <davdunc> it's a busy day for everyone today.
16:46:18 <davdunc> I will point out that the awscli-2 is under review.
16:46:26 <dustymabe> interesting
16:46:34 <dustymabe> summary of benefits?
16:46:41 <davdunc> - [ ] [[https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2049382][AWS-C-AUTH]] - bz#2049382
16:46:41 <davdunc> - [ ] [[https://bugzilla.redhat.com/show_bug.cgi?id=2049379][AWS-C-COMMON]] - bz#2049379
16:46:41 <davdunc> - [ ] [[https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2049656][AWS-C-COMPRESSION]] - bz#2049656
16:46:41 <davdunc> - [ ] [[https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2049400][AWS-C-CAL]] - bz#2049400
16:46:41 <davdunc> - [ ] [[https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2049748][AWS-C-EVENT-STREAM]] - bz#2049748
16:46:41 <davdunc> - [ ] [[https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2049662][AWS-C-HTTP]] - bz#2049662
16:46:41 <davdunc> - [ ] [[https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2049644][AWS-C-IO]] - bz#2049644
16:46:42 <davdunc> - [ ] [[https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2049781][AWS-C-MQTT]] - bz#2049781
16:46:42 <davdunc> - [ ] [[https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2049792][AWS-C-S3]] - bz#2049792
16:46:43 <davdunc> - [ ] [[https://bugzilla.redhat.com/show_bug.cgi?id=2049397][AWS-C-SDKUTILS]] - bz#2049397
16:46:43 <davdunc> - [ ] [[https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2049716][AWS-C-CHECKSUMS]] - bz#2049716
16:46:44 <davdunc> - [ ] [[https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2049808][AWSCLI-2]] - bz#2049808
16:46:57 <copperi[m]> ok
16:47:02 <davdunc> sorry. shouldn't have flooded.
16:47:37 <davdunc> dustymabe: to answer your question, the awscli version 1 has been deprecated and is expected to be replaced fully with this version 2.
16:48:01 <dustymabe> good to know
16:48:26 <davdunc> all active development is happening on the v2 so new services and regions and all the bells and whistles are there. There is even a shell that is built in where the version 1 had to rely on an outside tool for that.
16:48:54 <davdunc> on the downstream side, corosync will need it when the version 1 is no longer supported.
16:49:15 <davdunc> so this prepares us for that plus other needs.
16:49:47 <davdunc> just like the others we are working on, like gsutil there were issues all around the way these packages are developed that needed to change.
16:49:54 <davdunc> so it's been a long ride.
16:50:27 <davdunc> Kyle Knapp from the AWS SDK team was a huge help in making modifications across all of these packages and the spec files.
16:50:56 <davdunc> that's my news.. anything else?
16:51:42 <davdunc> oh! also Doug Chamberlain from the s2n-tls team.
16:52:26 <davdunc> okay if there is nothing else. I'll close this week's meeting and we'll meet again in two weeks.
16:53:00 <dustymabe> thanks davdunc
16:53:01 <davdunc> #info the centos-cloud team meets on the 2nd week of the month and that's next week, so just letting everyone know!
16:53:12 <davdunc> thanks for being here dustymabe
16:53:25 <copperi[m]> thanks davdunc
16:54:01 <davdunc> thanks copperi[m] appreciate you being here with us.
16:54:05 <davdunc> #endmeeting