16:30:34 #startmeeting fedora_coreos_meeting 16:30:34 Meeting started Wed Oct 31 16:30:34 2018 UTC. 16:30:34 This meeting is logged and archived in a public location. 16:30:34 The chair is lorbus. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:30:34 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:30:34 The meeting name has been set to 'fedora_coreos_meeting' 16:30:44 .hello lucab 16:30:45 kaeso: lucab 'Luca Bruno' 16:30:47 #topic Roll Call 16:30:49 .hello2 16:30:50 .hello2 16:30:50 .hello2 16:30:51 dustymabe: dustymabe 'Dusty Mabe' 16:30:54 slowrie: slowrie 'Stephen Lowrie' 16:30:57 ajeddeloh: ajeddeloh 'Andrew Jeddeloh' 16:31:05 .hello2 16:31:06 bgilbert: bgilbert 'Benjamin Gilbert' 16:31:12 .hello sayanchowdhury 16:31:13 sayan: sayanchowdhury 'Sayan Chowdhury' 16:31:18 .fas jasonbrooks 16:31:20 jbrooks: jasonbrooks 'Jason Brooks' 16:31:23 #chair kaeso dustymabe slowrie bgilbert sayan jbrooks 16:31:23 Current chairs: bgilbert dustymabe jbrooks kaeso lorbus sayan slowrie 16:31:39 .hello mnguyen 16:31:39 #chair ajeddeloh 16:31:40 Current chairs: ajeddeloh bgilbert dustymabe jbrooks kaeso lorbus sayan slowrie 16:31:40 mnguyen_: mnguyen 'Michael Nguyen' 16:31:53 #chair mnguyen_ 16:31:53 Current chairs: ajeddeloh bgilbert dustymabe jbrooks kaeso lorbus mnguyen_ sayan slowrie 16:32:21 #topic Action items from last meeting 16:32:30 * bgilbert to PR the design doc and open tickets for backport-related questions 16:32:30 * ajeddeloh and lorbus to experiment on grubenv + static grub config 16:32:30 * kaeso to add summary of discussion with lennart re: portable services to #37 16:32:30 * dustymabe to open tickets for individual clouds so that we can document gaps/strategy for not shipping cloud agents (#12) 16:34:02 lorbus: I haven't had time to work on that, dunno about you 16:34:22 * lorbus neither 16:34:46 I saw that kaeso added a comment: https://github.com/coreos/fedora-coreos-tracker/issues/37#issuecomment-433889365 16:34:56 ignition+portablectl summary is on GH 16:34:57 yup 16:35:01 #info dustymabe opened tickets #65 -> #71 for cloud agent investigation 16:35:01 #link https://github.com/coreos/fedora-coreos-tracker/issues/37#issuecomment-433889365 16:35:02 so that's done :) 16:35:32 bgilbert, do you have an update, too? 16:35:50 lorbus: want to re-action the grubenv item? 16:36:06 dustymabe: sure 16:36:10 yup, the PR is up in https://github.com/coreos/fedora-coreos-tracker/pull/72 16:36:21 started working on the bugs, then went down a rabbit hole of bug-writing 16:36:28 those should be up later today 16:36:38 #action ajeddeloh and lorbus to experiment on grubenv + static grub config 16:36:58 #info bgilbert opened PR for design doc for release streams discussion decision 16:37:02 #link https://github.com/coreos/fedora-coreos-tracker/pull/72 16:37:22 dustymabe's typing faster 16:37:31 .hello rfairleyredhat 16:37:32 rfairley: rfairleyredhat 'Robert Fairley' 16:37:34 * dustymabe rests keyboard 16:37:42 #chair rfairley 16:37:42 Current chairs: ajeddeloh bgilbert dustymabe jbrooks kaeso lorbus mnguyen_ rfairley sayan slowrie 16:38:03 than me I should've noted :P damn US keyboard 16:38:38 #topic Cloud Agents 16:38:50 dustymabe go 16:39:07 it might make more sense to dive in on a per cloud basis 16:39:42 slowrie: sure. any specific one you have in mind already? 16:40:39 The main ones we probably want discussion around are probably going to be GCE, Azure & VMware 16:40:48 sounds good to me 16:40:57 want to go in that order? 16:41:12 sgtm, ajeddeloh want to chime in on the oslogin stuff? 16:41:21 #topic GCE Cloud Agent 16:41:26 sure 16:41:41 so first, there's more than just oslogin to be on google cloud 16:41:58 #link https://github.com/coreos/fedora-coreos-tracker/issues/67 16:41:59 but I think everything else can be containerized like we do on CL 16:42:22 dustymabe: damn you, again^^ 16:42:32 oslogin is basically just a couple pam and nss modules 16:42:40 and the config files to enable them 16:42:50 oh and an authorizedSSHKeys binary 16:43:33 assuming we're shipping the same image everywhere, that'll mean we'll ship said modules everywhere but only enable them via configuration elsewhere 16:43:39 ajeddeloh: so would we just embed it in the ostree and conditionally enable oslogin? 16:43:45 yeah 16:43:49 got ya 16:44:14 would we propose to create a google-oslogin rpm in fedora then? 16:44:14 anything else here? 16:44:27 And I think we want the ability to disable them if the user wants (via Ignition) 16:44:33 i know there are some that exist but I don't think any in fedora 16:44:47 +1 yeah that makes sense 16:44:54 there a few more non-agent bits on GCP 16:44:56 from the ticket it looks like that's already happening dustymabe 16:44:59 * dustymabe assumes it's open source 16:45:05 it is 16:45:20 what is alredy happening ? 16:45:25 not _too_ bad to package (got a few quirks, otherwise decent, not too many deps) 16:45:31 the creation of a google-oslogin rpm 16:45:36 see jdoss' comment 16:45:53 one other thing 16:46:00 I know that on CL we do something to containerize gsutil 16:46:18 on non-CL distros OSLogin works a little differently 16:46:18 hmm. his comment links to an rpm 16:46:29 i don't know of any specific effor to get that rpm into fedora though 16:46:36 ah 16:46:37 we could ask to see if he's interested 16:46:38 Might have misread 16:46:49 dustymabe: https://pagure.io/fedora-server/issue/5#comment-538460 16:46:59 on "normal" OSs the gce agent is the thing enabling/disabling oslogin 16:47:21 oh nice 16:47:23 ^ Current effort IIRC I have not used it for my GCP deployments 16:47:29 so we just need to finish the package reviews 16:47:31 and it gets a signal from gce to toggle it (so you can toggle it in one place on the cloud side) 16:47:58 .hello2 16:47:59 jdoss: jdoss 'Joe Doss' 16:48:05 #chair jdoss 16:48:05 Current chairs: ajeddeloh bgilbert dustymabe jbrooks jdoss kaeso lorbus mnguyen_ rfairley sayan slowrie 16:48:07 but that's via some bash that manually mangles things like nsswitch.conf 16:48:20 ok so what are the non-agent bits needed for GCP ? 16:49:07 Not sure if gsutil is required but we might want to talk about the inclusion of gsutil/awscli 16:49:16 * ajeddeloh doesn't remember all of them off the top of his head 16:49:25 but there's something for networking, time 16:49:32 I was digging in GH tracker 16:49:44 and we were aiming at just removing that 16:49:47 awscli containerizes nicely, yes? 16:49:51 #link https://github.com/coreos/bugs/issues/2235#issuecomment-344749342 16:49:54 believe it should 16:50:17 gcloud / gsutil should too 16:50:31 well, mostly: https://github.com/coreos/bugs/issues/2235 16:51:00 I'm pretty sure there were other issues too, but I can't find them now 16:51:28 yeah maybe we can open a separate issue for gsutil/awscli (cloud clients) 16:51:33 slowrie: ^^ 16:51:48 works for me 16:52:27 should we action somebody to do it? 16:52:29 sound like an action item 16:52:31 yep 16:52:45 any volunteers? 16:52:54 I'd be for just leaving those to the user, as normal application/utilities 16:53:10 i nominate slowrie :) 16:53:14 I'm fine doing it 16:53:38 (as in, to run in their container runtime of choice) 16:53:39 #action slowrie to open separate issues for gsutil/awscli cloud clients 16:54:16 ok regarding package reviews 16:54:42 anybody interested in doing a package review https://pagure.io/fedora-server/issue/5#comment-538460 ? 16:56:04 which would help us move things along. 16:56:19 #action lorbus to review gce-oslogin rpm https://pagure.io/fedora-server/issue/5#comment-538460 16:56:23 I'm not a sponsor yet, but I'm working on it 16:56:27 thanks lorbus 16:56:28 I'll do it 16:56:48 anything else for GCE? 16:57:20 #topic Azure Cloud Agent 16:57:20 #link https://github.com/coreos/fedora-coreos-tracker/issues/65 16:57:34 I posted a bash script & systemd unit for the checkin in https://github.com/coreos/fedora-coreos-tracker/issues/65#issuecomment-434449560 16:58:17 It assumes the known wireserver IP address, which should always be the case for ARM machines so only ASM & AzureStack should have custom addrs 16:58:40 slowrie: have you seen https://github.com/coreos/coreos-metadata/issues/120 too? 16:59:12 Yeah, that ticket is in reference to where the final version should live 16:59:47 As it needs to run every boot it should live in coreos-metadata, that script is more of a PoC to see what is required to replace waagent 17:00:17 +1 17:00:18 One currently outstanding issue is that there are no nameservers setup post-boot despite them being sent in the DHCP broadcasts 17:00:29 do we think that is a networking bug ? 17:00:58 I'm not sure yet, I need to ensure that it is present in the initramfs and if so it's probably a networking bug 17:01:16 there's probably some other agent functionality we'll need to look into as well; the Azure folks mentioned ephemeral disks 17:01:42 bgilbert: like formatting and mounting them? 17:02:17 at a guess. I don't know any more yet 17:02:40 +1 17:03:24 who'd like to pick up research on this? 17:03:41 I'm going to keep digging on the networking portion for now 17:03:45 slowrie again? 17:03:52 yep. thanks slowrie 17:04:01 we don't necessarily need any action items here 17:04:09 since it's more open ended 17:04:15 ack 17:04:30 bgilbert mind updating the ticket w/ the ephemeral disks info so it doesn't slip off the radar? 17:05:13 slowrie: I'll follow up with the Azure folks first. want to make sure we have a solid understanding of what's needed, rather than fragments 17:05:19 +1 17:05:28 moving on, or anything else to add here? 17:05:45 #topic VMware Cloud Agent 17:05:51 #link https://github.com/coreos/fedora-coreos-tracker/issues/70 17:06:32 VMware is probably one of the agents we're going to just have to include 17:06:42 from my memory of past discussions the agent doesn't containerize nicely 17:06:48 that one IIRC is nasty because it's basically a configuration manager 17:07:51 right. but what are the bare minimum features we actually need? 17:07:51 Do we have an issue for Virtualbox tools for people that want to run Fedora CoreOS in Vagrant with Virtualbox? I know if my dev coworkers don't have the tools installed, time drifts when suspended on OS X and it causes issues. 17:08:07 (maybe this isn't in scope but it's an agent I think) 17:08:09 jdoss: yep https://github.com/coreos/fedora-coreos-tracker/issues/73 17:08:32 kaeso: IOW could we not ship the agent and just implement the bare minimum features 17:08:47 +1 sorry for being behind :) 17:09:21 dustymabe: I don't know. I guess we can start without and start recording things that are missing 17:09:41 yeah. i think that's the point of all of these tickets 17:09:55 i.e. if we try not to ship the guest agent how much pain are we going to have to endure 17:10:06 iirc virtualbox outside of vagrant would require either a nasty UX or changes being made to virtualbox itself to support larger metadata sizes 17:10:29 bgilbert or kaeso might have more context 17:10:48 dustymabe: vmware is the one we are the least familiar I think 17:11:12 slowrie: yeah, more in the ticket ^ 17:11:56 kaeso: IOW we'd need to get some hardware and investigate 17:12:25 hardware == (set up environment) 17:13:20 dustymabe: we can probably test on packet's ESX servers, don't think we need vSphere for basic testing w/out the agent 17:13:34 k 17:13:40 i'll add a note to the ticket 17:13:55 anything I should info for this topic? 17:14:47 There is one more item for this week from our issue tracker: https://github.com/coreos/fedora-coreos-tracker/labels/meeting 17:14:55 #topic Docker Version 17:15:02 #link https://github.com/coreos/fedora-coreos-tracker/issues/64 17:15:23 yep. just wanted to bring this up as a user opened the ticket 17:15:30 and I wanted to make sure we are all on the same page 17:16:06 anybody object to the responses I made in the ticket ? 17:16:50 #info FCOS will default to the moby-engine package which follows upstream 17:17:09 that seems correct 17:17:09 everybody ok with that? 17:17:23 #topic Open Floor 17:17:35 the open questions were related to "which version" and "how to switch version" 17:17:41 (modularity and overlaying?) 17:18:26 kaeso: right. "which version" == whatever is in moby-engine package in fedora 17:18:36 "how to switch" we need another issue for that I think 17:18:54 but yes, modularity and overlaying was what I was thinking 17:18:58 though will require some work 17:18:58 ack. So that ticket is technically correct :) 17:19:30 anybody want to volunteer to add the moby-engine package to FCOS configs ? 17:19:39 that could be a first step anyway 17:20:03 I'll do it 17:20:29 #action lorbus to add moby-engine package to FCOS configs 17:20:38 if we add it to base FCOS, can users overlay a different version later? 17:21:22 yes 17:21:36 yeah, but we'd need to make things "nicer" in the future 17:22:03 this is mainly just a first step and us making a statement that we are including it 17:22:06 Why not just use podman to run moby-engine in a container ??? ;) 17:22:14 ack (it looks like I misunderstood this in the past) 17:22:22 * jdoss is so sorry for the bad joke 17:22:54 anybody got anything for open floor? 17:22:59 lorbus: i do 17:23:00 jdoss: silly as it seems, we actually tried several iterations of that with systemd/rkt/docker and turns out it doesn't really work :) 17:23:15 #info fedora 29 atomic host was released yesterday 17:23:26 ksinny++ 17:23:26 sayan: Karma for sinnykumari changed to 1 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:23:28 haha, you all get points for trying kaeso 17:23:31 dustymabe: yay! 17:23:38 which isn't super relevant for Fedora CoreOS, other than to explicitly call out that I expect FCOS development to pick up now 17:23:39 ksinny++ 17:23:40 lorbus: Karma for sinnykumari changed to 2 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:24:13 mainly fedora 29 is out the door and fedora 30 is the cycle we are targeting for FCOS, so we're going to race to our target 17:24:40 fasten the seatbelts everyone! 17:24:44 :) 17:24:52 also note that big changes we want to make or have happen in other parts of fedora (systemd networkmanager....) need to happen earlier iin the cycle than later 17:25:11 earlier in the cycle means that we have a greater chance of it making whatever devcut the teams have for fedora 30 17:25:15 killing networkmanager and moving to systemd-networkd? 17:25:19 one can dream 17:25:29 *cough*pam*cough* 17:25:41 so if you're working on something that involves other subsystems, working on that before other things might be a good idea 17:25:50 kaeso: killing pam and moving to systemd-networkd? 17:26:02 what did she ever do to you? 17:26:08 pam's a nice lady 17:26:09 Jim is going to be so mad 17:26:14 that's a trip, not a dream :) 17:26:23 :) 17:26:34 i'm trying to think of any other open floor items 17:26:36 anyone else? 17:27:03 the above was https://github.com/linux-pam/linux-pam/pull/69 bts 17:27:05 *btw 17:27:43 kaeso: calling out that it hasn't been reviewed yet ? 17:27:58 :) 17:28:04 rfairleyredhat++ 17:28:04 lorbus: Karma for rfairleyredhat changed to 1 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:28:53 in terms of docker/podman I'm working on podman wrapper (varlink based) which will expose docker api with hope that this will kill need for docker/moby for good 17:29:41 That sounds awesome mskarbek 17:30:10 #info mskarbek working on a varlink based podman wrapper to expose docker api 17:30:16 mskarbek: nice 17:30:28 is that something you've shared with upstream podman maintainers ? 17:30:34 in case they are working on something similar? 17:30:44 this is why I created docker version issue in the first place to make sure that I can focus on newer api versions 17:31:22 it's time! 17:31:27 yep 17:31:31 thank you all for coming! 17:31:42 #endmeeting