15:59:37 #startmeeting fedora_cloud_meeting 15:59:37 Meeting started Tue Sep 1 15:59:37 2020 UTC. 15:59:37 This meeting is logged and archived in a public location. 15:59:37 The chair is dustymabe. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:59:37 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:59:37 The meeting name has been set to 'fedora_cloud_meeting' 15:59:43 #topic roll call 15:59:46 .hello2 15:59:47 dustymabe: dustymabe 'Dusty Mabe' 16:00:31 .hello2 16:00:32 jdoss: jdoss 'Joe Doss' 16:00:32 .hello2 16:00:35 cyberpear: cyberpear 'James Cassell' 16:01:24 #chair jdoss cyberpear 16:01:24 Current chairs: cyberpear dustymabe jdoss 16:01:30 welcome :) 16:01:40 Hi Dusty :) 16:01:55 .hello2 16:01:56 darkmuggle: darkmuggle 'None' 16:02:02 #chair darkmuggle 16:02:02 Current chairs: cyberpear darkmuggle dustymabe jdoss 16:02:42 .hello2 16:02:43 mgugino: Sorry, but you don't exist 16:02:48 #chair mgugino 16:02:48 Current chairs: cyberpear darkmuggle dustymabe jdoss mgugino 16:02:56 ok let's get started 16:03:03 .hello2 16:03:04 michaelgugino: michaelgugino 'Michael Gugino' 16:03:30 #topic Action items from last meeting 16:03:42 * King_InuYasha to engage mhayden to see if the cloud base images might 16:03:44 be a good candidate for Image Builder 16:03:46 * King_InuYasha and michaelgugino to work together to see if mash is a 16:03:48 viable avenue for uploading disk images to the clouds 16:03:51 .hello ngompa 16:03:52 King_InuYasha: ngompa 'Neal Gompa' 16:04:03 hey everyone 16:04:07 sorry I'm a bit late 16:04:10 work meeting ran over 16:04:12 no worries 16:04:15 #chair King_InuYasha 16:04:15 Current chairs: King_InuYasha cyberpear darkmuggle dustymabe jdoss mgugino 16:04:36 no updates from me at this time. 16:05:02 should we re-action or let it linger ? 16:05:12 probably reaction for the mash thing 16:05:24 * King_InuYasha and michaelgugino to work together to see if mash is a viable avenue for uploading disk images to the clouds 16:05:44 as for the image builder thing, I sent an email to Major this morning 16:06:36 cool let's see what comes back from that 16:06:50 ok we don't have any meeting topics labeled but I have a few things I want to bring up 16:07:13 #topic rewrite kickstart files - remove cruft 16:07:20 #link https://pagure.io/cloud-sig/issue/311 16:07:27 I started working on this this morning 16:07:46 quite a bit of cruft we can remove 16:07:49 nice 16:07:57 I'm thinking mostly just remove it all and add back what we need as we find things 16:08:06 i'm trying to keep the package set relatively unchanced 16:08:16 but other than that, most of the "tweaks" i'm just going through one by one 16:08:20 and inspecting them 16:08:26 hopefully will have a PR up later today 16:08:49 and maybe later this week we can push that to f33 so we'll be able to test these changes for beta 16:08:50 cool 16:09:51 This was mostly needed for general maintenance, but also we want a cleaner slate to start with for the GCP addition (https://pagure.io/cloud-sig/issue/310) 16:10:05 right 16:10:30 any comments for this topic or should I move on? 16:10:36 at Nest, dgilmore had some ideas of how to hybridize a cloud image even with imgfac based images, so it might be worth following up with him for the GCP add 16:10:50 so since you're doing that work now, you might want to get in touch with him for that 16:11:01 k 16:11:23 if you could summarize and put it in a ticket that would be good too 16:11:44 I don't remember, hence suggesting you talk to him :) 16:11:55 it was bad of me to not put it in three weeks ago :( 16:12:00 Are we using GCP's startup tool, or did cloud-init start working on GCP again? 16:12:05 it happens 16:12:22 #topic publish a cloud image for GCP 16:12:27 cloud-init works there, but I need to update gcp packages to new stuff 16:12:29 #link https://pagure.io/cloud-sig/issue/310 16:12:47 King_InuYasha: how much work do you think that would be to update the gcp packages to the new stuff ? 16:13:02 well, they changed from C and Python to Go... :( 16:13:15 The google engineer is interested in making that happen, but needs a mentor 16:13:40 well, then put that person in touch with me and we can figure it out 16:14:08 when I was working on this a year or so ago, the guest-agent team wasn't interested in my fixes, so I stopped updating it 16:14:16 perfect - some sort of co-maintainership would be nice where he/they do most of the work and you help make sure they do the right things 16:14:16 seems like the situation has changed now 16:14:55 indeed 16:15:13 ok I think I'll break it out into a new ticket so we can have a focused discussion there 16:15:17 cool 16:15:36 #topic welcome darkmuggle 16:15:44 hey darkmuggle! 16:15:48 Maybe we patch and maintain the packages ourselves if the source is available? 16:15:49 Everybody 👋 to darkmuggle 16:15:56 howdy :) 16:16:17 michaelgugino: yeah it would be a package in fedora, so open source and in dist-git 16:16:32 darkmuggle is looking to get more involved in the cloud WG 16:16:38 awesome 16:16:56 I've been meaning to play in the Fedora Cloud space for a while. I'm looking for some things to work on...but not clear where my energy can be directed. 16:17:08 he's got quite a "cloud"y background so his skills will be put to good use 16:17:40 welcome. 16:17:44 * jdoss waves 16:18:02 can we think of any particular item that would be good for him to put some attention on first? 16:18:13 do we want to do ignition for cloud images? 16:18:18 ooooo 16:18:20 if we do, that might be a good starting place 16:18:29 That would be pretty slick 16:18:45 That sounds like an interesting place to cut my teeth 16:18:57 King_InuYasha: I think it would be nice to support either cloud-init or ignition at the same time, but honestly I think we've got other foundational pieces we probably need to do first 16:19:14 the only other thing would be getting the tools we need for testing and uploading cloud images packaged 16:19:16 for example.. if fedimg goes down today, I have no idea how to fix it 16:19:30 `img-mash` and `img-proof` 16:19:37 we really need to get https://pagure.io/cloud-sig/issue/301 sorted out 16:20:56 so yeah I think the highest priority issues we have are: 16:21:12 1. replacing fedimg (https://pagure.io/cloud-sig/issue/301) 16:21:32 hack day friday. I'm going to push hard to get something actually uploading something to somewhere on the accounts I have access to Friday. 16:21:33 2. possibly replacing the imagefactory/os stack with something newer (Image builder maybe) 16:21:51 s/os/oz/ 16:22:11 michaelgugino: +1 16:22:24 maybe you can darkmuggle and King_InuYasha could all work together on it 16:22:29 :) 16:22:30 s/can/and/ 16:23:04 King_InuYasha: does "ignition support" sound like a good f34 goal maybe? 16:23:10 yeah 16:23:19 Sure. We can hang out in #fedora-cloud on Friday. I'm on US East coast time, FYI. 16:23:24 same 16:23:40 That sounds agreeable to me, although I'm US Mountain time. 16:24:31 Cool. I'm going to try to dedicate as much of Friday as I can to this. So I'll be around all day. 16:24:35 well, I'm free after 12pm EDT 16:24:39 cool. I'm really excited to get more people involved here 16:24:54 so that should work fine for darkmuggle being in MDT 16:25:36 I am in CDT and should be around this Friday too. 16:26:17 🎉 16:26:23 welcome again darkmuggle 16:26:32 #topic open floor 16:26:36 any topics for open floor ? 16:27:19 well back to the Cloud-init and Ignition support....if there's interest we could easily provide dual use images without breaking each other. 16:27:48 I think having one image with it being able to support Cloud-init or Ignition is ideal. 16:28:06 same ^^ - of course only if it's not super super hard to do 16:28:11 if dual-use is possible, we should do that 16:28:20 I am not sure how that will technically however but we should give it a solid try. 16:28:27 I don't think it will be that hard TBH 16:28:29 how tightly tied is ignition to ostree? 16:28:33 not very 16:28:37 yeah, not at all 16:28:39 (or not at all?) 16:28:43 The key is where cloud-init and ignition run 16:28:46 That is great to hear. 16:28:48 ignition is used by SUSE for their btrfs-based system 16:29:08 There's a sentiment downstream that ignition isn't going to non-immutable distros. Maybe there's a reason for that, IDK. I'm not personally a fan of ignition, but that's me. 16:29:40 since ignition can't do software management, it's a slightly better fit for "immutable" platforms 16:29:57 but that is definitely not a thing that can't be fixed 16:30:07 The advantage to dual support is that we can let the user choose. 16:30:34 ignition is like kickstart, but at first boot time instead of install time 16:30:37 I'm personally seeing the machine-config-daemon adapted to more purposes. It's like an immutable puppet. 16:30:41 oh yeah, definitely not going to be removing cloud-init support 16:30:56 MCD is not particularly useful in most cases 16:31:19 Recent innovations in ignition gives a path to detecting the user's intend. 16:31:28 Having MCD as a centralized configuration server for immutable systems I think is an interesting use case. 16:31:36 Well, MCD and MCS and other components. 16:31:38 MCD takes an ignition and applies it at times other than first boot? 16:31:43 I'll file an issue with the thinking and we can debate whether the idea has merit and weight the risk/rewards. 16:31:54 s/weight/weigh/ 16:31:59 cyberpear: more or less. It's technically ignition embedded into a different object. 16:31:59 I expect that if we wanted to drive ignition to be used more on regular platforms, extending it to have a software management task wouldn't be difficult 16:32:13 that's pretty much the only hole it has relative to cloud-init 16:32:38 Software management via ignition might be a tough sell to the ignition maintainers 16:32:46 King_InuYasha: there's some debate on that. 16:32:53 on what belongs in ignition 16:33:04 generally we like to keep the primitives low 16:33:13 and then have things like fcct build on top of it 16:33:19 if it's being used in a non-immutable platform, we cannot expect everything we need to be present in the base 16:33:28 that's sort of the point 16:33:41 Right. I wouldn't try to teach ignition about dnf/yum/.... 16:33:41 immutable platforms work because we provide enough to do a particular primary purpose 16:33:57 that doesn't fly for regular Fedora Cloud 16:33:59 right, but is it Ignition that knows how to install things or is it fcct that generates instructions for Ignition 16:34:05 does that matter? 16:34:12 yes. 16:34:17 not to the user, it doesn't 16:34:17 Another idea I had was for non os-tree systems, you could vendor all the RPMs you want for a given 'release' of your system into a container, and MCD (or something else) applies the packages from that container. This would include whatever system updates and applications you want installed. 16:34:22 if fcct has a software management task that does a thing to make ignition able to do it, then who cares? 16:34:36 we already tell people to not write ign files directly 16:34:37 King_InuYasha: the people building Ignition and fcct care 16:34:55 i'm just trying to explain the difference to help understanding 16:35:07 ah sure 16:35:12 I have to agree with King_InuYasha 100% 16:35:29 when I think of ignition to people, I'm thinking of the ignition interface, ie fcct 16:35:55 fair, just be careful what conversations you start.. make sure you're on the same page with the audience 16:35:58 I honestly don't care how ignition _itself_ does it as long as the sane interface to handle the task is in the thing people use 16:36:11 👍 16:36:12 with cloud-init, everyone hand-writes cloud-configs 16:36:22 with ignition, everyone handwrites fcct yamls 16:36:27 not ign json 16:37:06 I think the only time I've cared about ignition itself is when there's no way to do something 16:37:17 like with setting up a system with a btrfs rootfs 16:38:49 any other topics for open floor ? 16:39:39 not atm 16:40:44 I'll close it out in a few minutes if no more topics. 16:42:51 #endmeeting