16:32:07 <bgilbert> #startmeeting fedora_coreos_meeting
16:32:07 <zodbot> Meeting started Wed Jan 16 16:32:07 2019 UTC.
16:32:07 <zodbot> This meeting is logged and archived in a public location.
16:32:07 <zodbot> The chair is bgilbert. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:32:07 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:32:07 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:32:20 <bgilbert> #topic roll call
16:32:20 <lorbus[m]> .hello lorbus
16:32:21 <zodbot> lorbus[m]: lorbus 'Christian Glombek' <cglombek@redhat.com>
16:32:23 <bgilbert> .hello2
16:32:24 <zodbot> bgilbert: bgilbert 'Benjamin Gilbert' <bgilbert@backtick.net>
16:32:34 <ksinny> .hello sinnykumari
16:32:35 <zodbot> ksinny: sinnykumari 'Sinny Kumari' <ksinny@gmail.com>
16:32:36 <rfairley> .hello rfairley
16:32:38 <zodbot> rfairley: rfairley 'None' <rfairley@redhat.com>
16:32:40 <jbrooks> .fas jasonbrooks
16:32:41 <zodbot> jbrooks: jasonbrooks 'Jason Brooks' <jbrooks@redhat.com>
16:32:45 <ajeddeloh> .hello2
16:32:46 <zodbot> ajeddeloh: ajeddeloh 'Andrew Jeddeloh' <andrew.jeddeloh@redhat.com>
16:32:57 <dustymabe> .hello2
16:32:58 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:33:30 <bgilbert> #chair lorbus[m] ksinny rfairley jbrooks ajeddeloh dustymabe
16:33:30 <zodbot> Current chairs: ajeddeloh bgilbert dustymabe jbrooks ksinny lorbus[m] rfairley
16:33:33 <miabbott> .hello2
16:33:34 <zodbot> miabbott: miabbott 'Micah Abbott' <miabbott@redhat.com>
16:33:40 <mnguyen_> .hello mnguyen
16:33:41 <zodbot> mnguyen_: mnguyen 'Michael Nguyen' <mnguyen@redhat.com>
16:34:29 <bgilbert> #chair miabbott mnguyen_
16:34:29 <zodbot> Current chairs: ajeddeloh bgilbert dustymabe jbrooks ksinny lorbus[m] miabbott mnguyen_ rfairley
16:34:59 <bgilbert> #topic Action items from last meeting
16:35:30 <bgilbert> * dustymabe to open design doc PR to close out openstack cloud agent issue #68
16:35:37 <bgilbert> * ajeddeloh to add igntion 3.0.0 spec to roadmap
16:35:42 <bgilbert> * bgilbert to coordinate with mattdm about FCOS metrics
16:35:45 <kaeso> .hello lucab
16:35:46 <zodbot> kaeso: lucab 'Luca Bruno' <lucab@redhat.com>
16:35:46 <sayan> .hello sayanchowdhury
16:35:48 <bgilbert> #info bgilbert is coordinating with mattdm
16:35:49 <zodbot> sayan: sayanchowdhury 'Sayan Chowdhury' <sayan.chowdhury2012@gmail.com>
16:35:58 <bgilbert> #chair kaeso sayan
16:35:58 <zodbot> Current chairs: ajeddeloh bgilbert dustymabe jbrooks kaeso ksinny lorbus[m] miabbott mnguyen_ rfairley sayan
16:35:59 <flexo3001> .hello flexo3001
16:36:00 <zodbot> flexo3001: flexo3001 'Marco Kundt' <flexo3001@pm.me>
16:36:10 <dustymabe> #info dustymabe opened #117 for design doc PR for openstack (#68)
16:36:11 <bgilbert> #chair flexo3001
16:36:11 <zodbot> Current chairs: ajeddeloh bgilbert dustymabe flexo3001 jbrooks kaeso ksinny lorbus[m] miabbott mnguyen_ rfairley sayan
16:36:18 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/pull/117
16:36:27 <ajeddeloh> roadmap is PRd as of literally right now
16:36:31 <ajeddeloh> https://github.com/coreos/fedora-coreos-tracker/pull/119
16:36:46 <bgilbert> #info ajeddeloh PR'd roadmap for Ignition 3.0.0 spec
16:36:53 <bgilbert> #link https://github.com/coreos/fedora-coreos-tracker/pull/119
16:37:01 <mattdm> bgilbert: oh hi i'm actually here :)
16:37:10 <mattdm> sorry for being awol on this
16:37:24 <bgilbert> mattdm: hey, no problem!  and I owe you another email :-)
16:37:27 <bgilbert> #chair mattdm
16:37:27 <zodbot> Current chairs: ajeddeloh bgilbert dustymabe flexo3001 jbrooks kaeso ksinny lorbus[m] mattdm miabbott mnguyen_ rfairley sayan
16:37:35 <mattdm> are you in brno next week?
16:37:49 <jlebon> .hello2
16:37:50 <zodbot> jlebon: jlebon 'None' <jonathan@jlebon.com>
16:38:15 <bgilbert> mattdm: nope, unfortunately
16:38:27 <bgilbert> #chair jlebon
16:38:27 <zodbot> Current chairs: ajeddeloh bgilbert dustymabe flexo3001 jbrooks jlebon kaeso ksinny lorbus[m] mattdm miabbott mnguyen_ rfairley sayan
16:38:45 <mattdm> ah well. I promise to respond to your email as soon as I get it :)
16:38:52 <bgilbert> mattdm: :-)
16:39:16 <bgilbert> #topic Autologin policy for cloud platform consoles
16:39:21 <bgilbert> #link https://github.com/coreos/fedora-coreos-tracker/issues/114
16:39:33 <bgilbert> I just wanted to bounce this around a bit
16:39:50 <bgilbert> several clouds provide authenticated access to the serial or VGA console of a machine
16:39:57 <bgilbert> which is nice for debugging, if you can actually log in.
16:40:02 <bgilbert> FCOS machines will generally not have passwords.
16:40:14 <bgilbert> we could _technically_ autologin on the console, since console access is authenticated
16:40:21 <bgilbert> (by the cloud)
16:40:41 <bgilbert> which provides better UX and worse security.
16:41:04 <bgilbert> in the sense that a) we're very obviously trusting the cloud not to do things on the VM
16:41:21 <bgilbert> and b) users may be surprised that the cloud is granting console access to some set of users
16:41:35 <ajeddeloh> my concern is that users may have different policies for who has access to cloud things and who has access to contents of running machines
16:41:58 <kaeso> bgilbert: didn't we explicitly drop the "autologin" knob few months ago? I remember some previous discussion about that
16:42:10 <bgilbert> kaeso: did we?  I thought it was an oversight
16:42:29 <bgilbert> (and thus filed https://github.com/coreos/fedora-coreos-tracker/issues/112)
16:42:57 <kaeso> bgilbert: let me try to verify my memory on that (and sorry didn't see the ticket this morning)
16:43:18 <bgilbert> kaeso: np
16:43:42 <bgilbert> while he's looking:
16:44:08 <bgilbert> I think we should probably not enable autologin
16:44:13 <bgilbert> of course we'd have docs about how to change that
16:44:23 <bgilbert> but interested in views / use cases
16:44:38 <dustymabe> re: 'Most Fedora CoreOS machines will not enable password-based login'
16:44:42 <jlebon> ajeddeloh: are there clouds that differentiate between console access and e.g. nuking the VM?
16:44:59 <dustymabe> a user could set a password if they want?
16:45:12 <dustymabe> also could make the pw login only valid on serial console (i.e. not via SSH)
16:45:27 <ajeddeloh> I don't know, although GCEs controls are fine tuned enough I wouldn't be surprised
16:46:05 <bgilbert> dustymabe: yes and yes
16:46:11 <ajeddeloh> but my concern is being able to nuke VMs does not necesarily mean you have access to their contents
16:46:35 <ajeddeloh> you could have permissions to spin up/down VMs but not be allowed to look at the data stored on it
16:47:52 <jlebon> disabled by default with instructions on how to turn it on SGTM
16:48:07 <lorbus[m]> +1
16:48:37 <bgilbert> kaeso: any luck?
16:48:51 <dustymabe> so is this what we want?
16:49:01 <ajeddeloh> +1
16:49:02 <dustymabe> 1. implement the feature, disabled by default
16:49:15 <dustymabe> 2. people can set a user pw and disable ssh PW if they want
16:49:22 <dustymabe> 3. people can enable autologin if they want
16:49:24 <kaeso> bgilbert: neither google nor my inbox have anything, so let's just say we didn't do/discuss that on purpose before
16:49:39 <bgilbert> kaeso: sgtm
16:49:59 <jlebon> ok, just read the actual issue. so this is about making it easy on the kernel cmdline vs just documenting something like https://github.com/coreos/coreos-assembler/blob/16763204e836f8682e3ea0034794d8ab3206d3f6/src/cmd-run#L138
16:50:11 <bgilbert> discussion on whether we _should_ have an autologin kernel command line parameter can go in https://github.com/coreos/fedora-coreos-tracker/issues/112, then
16:50:48 <kaeso> jlebon: https://github.com/coreos/init/blob/85a35815c7ffb14d6e398da950502dbabc8f4291/systemd/system-generators/coreos-autologin-generator
16:50:49 <bgilbert> jlebon: #112 is about the kcmdline, #114 is about defaults on the cloud
16:51:06 <bgilbert> we can talk about #112 explicitly if we'd like
16:51:28 <dustymabe> bgilbert: +1 .. didn't realize you had also opened #112
16:51:36 <dustymabe> and it's good to break apart those two topics
16:51:39 <jlebon> gotcha, splitting the discussion makes sense
16:51:47 <bgilbert> dustymabe: +1 to talking about it here?
16:52:15 <kaeso> bgilbert: only speaking about #112, I think it would be valuable to have that mechanism file-based and documented
16:52:46 <jlebon> having a kernel param would be nice. definitely had times when I'd just nuke and reprovision a node with pw auth just to log in on the serial
16:52:49 <kaeso> bgilbert: (even if we don't enable it by default on any cloud)
16:53:01 <bgilbert> #topic Consider adding kernel command-line argument for automatically logging in on console
16:53:08 <bgilbert> #link https://github.com/coreos/fedora-coreos-tracker/issues/112
16:53:09 <bgilbert> :-D
16:53:42 <kaeso> bgilbert: except for historical precedent, any reason for having it on the cmdline instead of a file touched/removed by Ignition?
16:54:04 <bgilbert> kaeso: well
16:54:10 <kaeso> (assuming both are technically feasible, I haven't looked into that)
16:54:21 <bgilbert> kaeso: all it's really doing is creating a dropin, which is technically a "file written by Ignition"
16:54:25 <bgilbert> and we could document that
16:54:47 <bgilbert> (in the usual Container Linux way of documenting little snippets to be written by an Ignition config)
16:54:58 <ajeddeloh> you may want to be able to do it from the kernel command line anyway
16:55:11 <bgilbert> we could provide CT sugar for it, even
16:55:20 <bgilbert> but yes, also, it's convenient for breaking into machines
16:55:27 <bgilbert> to have it on the kcmdline
16:55:28 <ajeddeloh> like if something breaks and its the only way in
16:55:48 <bgilbert> otherwise it's "rd.break" + "touch /sysroot/etc/let_me_in"
16:55:59 <ajeddeloh> for bare metal you may have cases where physical access means you should be able to log in
16:56:08 <bgilbert> "single" doesn't work because there's no root pw
16:56:18 <ajeddeloh> hmm I guess with the rd.break there are other ways in
16:56:29 <kaeso> ajeddeloh: that is scoped to "if something breaks after we switched out of initramfs" no?
16:56:48 <ajeddeloh> yeah
16:56:56 <ajeddeloh> rd.break solves my concern
16:57:19 <bgilbert> ajeddeloh: I was arguing against that, actually
16:57:21 <bgilbert> it's clunky
16:57:47 <kaeso> (as a general trend, I'd like to see less kernel parameters instead of more)
16:58:42 <bgilbert> another approach is to make "single" usable
16:58:46 <bgilbert> by not requiring a pw
16:58:54 <kaeso> I may be wrong, bu my gut feeling is that the coreos-autologin-generator predates ignition
16:59:02 <bgilbert> it has different semantics but is arguably better for emergency repairs
16:59:10 <bgilbert> kaeso: I assume so
16:59:36 <kaeso> if that is true, the generator was needed because cloud-init was running too late for that
16:59:45 <bgilbert> oh
16:59:56 <kaeso> now ignition runs before that generator
17:00:20 <dustymabe> i added some questions to the ticket
17:00:20 <kaeso> and if the generator doesn't run, it means ignition failed
17:00:22 <ajeddeloh> using Ignition has the problem that it only works on first boot, so emergency repairs are clunky
17:01:02 <kaeso> ajeddeloh: fair
17:01:26 <bgilbert> do we agree that the kcmdline version is best for emergency repairs?
17:01:37 <bgilbert> i.e., if someone wants autologin every time, they should use Ignition to configure it
17:01:47 <bgilbert> ("best for" = "mainly useful for")
17:02:04 <bgilbert> because if so, I think there's a good argument for fixing "single" rather than adding a new argument
17:02:10 <ajeddeloh> I'm actualy not against kcmdline args as long as they're namespaces (i.e. ignition.X, coreos.X, etc)
17:03:29 <kaeso> bgilbert: if the main reason for the kcmdline is emergency, then yes it's basically "single" I guess
17:04:49 <kaeso> "single working" + "config-doc snippet to enable autologin" would work for me
17:05:05 <bgilbert> I think historically autologin has also been used on platforms that haven't had functioning cloudinit or Ignition
17:05:50 <bgilbert> but at this point I think it makes sense to call a platform without Ignition support "not actually an FCOS platform"
17:06:04 * bgilbert hides ISO boot under the carpet
17:06:04 <dustymabe> i could see it being useful for spinning up an image in qemu and not wanting to figure out how to provide an ignition config
17:06:42 <dustymabe> we often provide images to (X developer, where X is systemd or selinux or other) and ask them to try to investigate something
17:06:45 <bgilbert> dustymabe: on CL we have the wrapper script, coreos_production_qemu.sh, which wraps that for you
17:06:59 <bgilbert> finds your local SSH key and injects it
17:07:18 <dustymabe> bgilbert: yeah.. typically people already have their own scripts for spinning up VMs and sometimes they balk at things like that
17:07:23 <bgilbert> right
17:07:43 * dustymabe bees quiet now :)
17:08:20 <bgilbert> so it seems like there's interest in dropping the karg but we're not sure if we can?
17:08:56 <kaeso> we can start without and add it later as soon as we find a situation where we really need it?
17:09:02 <bgilbert> kaeso: was just about to say that
17:09:10 <bgilbert> we can add it at any time, but we can ~never remove it
17:09:47 <jlebon> related feature we had in AH: https://www.projectatomic.io/blog/2016/03/introducing-atomic-devmode/
17:10:35 <jlebon> it was directed at folks who just wanted to give it a spin without the cloud-init dance
17:10:37 <bgilbert> jlebon: oh, interesting
17:10:58 <bgilbert> okay, I'm thinking we should move on for time reasons
17:11:19 <bgilbert> proposal: I'll write up the discussion in the bugs and we can continue discussion there?
17:11:29 <kaeso> ack
17:11:43 <jlebon> +1
17:11:45 <kaeso> (and thanks for summarizing)
17:12:57 <bgilbert> #action bgilbert to summarize discussion in #112 and #114
17:13:06 <bgilbert> #topic roadmap
17:13:10 <bgilbert> #link https://github.com/coreos/fedora-coreos-tracker/blob/master/ROADMAP.md
17:13:18 <bgilbert> dustymabe: want to take this?
17:13:55 <dustymabe> yep
17:14:22 <dustymabe> ok I sent in an update earlier today
17:14:31 <dustymabe> let's review this week and then we'll talk about next week
17:14:59 <dustymabe> 2019-01-14
17:15:02 <dustymabe> H - finalize strategy,collaborate Network Management #24
17:15:03 <dustymabe> gaps identified feature work requested
17:15:06 <dustymabe> H - finalize strategy Kubernetes/OKD strategy #93
17:15:08 <dustymabe> M - finalize strategy Collect metrics from Fedora CoreOS machines design #86
17:15:10 <dustymabe> M - complete bare metal installer: POC #91
17:15:12 <dustymabe> Proof of concept complete
17:15:38 <dustymabe> there is one that I marked as already complete with was H - investigate no cloud agents for digital ocean
17:15:44 <dustymabe> thanks bgilbert ^^
17:16:06 <dustymabe> so let's go through them one by one
17:16:20 <dustymabe> minitopic: H - finalize strategy,collaborate Network Management #24, gaps identified feature work requested
17:16:38 <dustymabe> kaeso: did we do any followup with NM team to see where we stand?
17:17:10 <kaeso> not yet
17:17:20 <bgilbert> worth noting that this is starting to block cloud support on some platforms :-(
17:17:49 <kaeso> ok sorry, will do that tomorrow morning
17:18:04 <dustymabe> bgilbert: can you add the 'blocked' label and a comment to any issues that might be blocked?
17:18:15 <dustymabe> kaeso: no need to apologize :)
17:18:23 <bgilbert> dustymabe: sure
17:18:32 <bgilbert> #action bgilbert to add "blocked" label to issues blocked on #24
17:18:53 <dustymabe> minitopic: H - finalize strategy Kubernetes/OKD strategy #93
17:19:09 <dustymabe> I think jbrooks was doing some investigation with systemd portable services
17:19:14 <bgilbert> #action kaeso to follow up with NM team
17:19:56 <jbrooks> That's right, I commented over in the system containers replacement thread https://github.com/coreos/fedora-coreos-tracker/issues/37#issuecomment-454550323
17:20:13 <jbrooks> But the tldr is that I don't think portable services are quite ready for this
17:20:31 <lorbus[m]> kaseo, dustymabe, jbrooks: we should get Lennart to have a quick look at the things that are missing to make it work
17:20:38 <dustymabe> jbrooks: one thing I wonder is if the newer versions of systemd that just came out make any progress there ?
17:20:46 <jbrooks> selinux support is one big thing
17:21:15 <jbrooks> But then there's the bunches of bind mounts and stuff that need to be correct -- this is the sort of thing that made the system container a pain
17:21:28 <jbrooks> It's just a really non-standard way to run the kubelet
17:21:53 <dustymabe> jbrooks: for some reason I thought some of that pain would go away with portable services
17:22:00 <dustymabe> I thought they weren't really "containers"
17:22:10 <jbrooks> Nope, they are still contained
17:22:26 <jbrooks> It's a lot like a more convenient, but less mature system containers
17:22:27 <ajeddeloh> well "contained"
17:22:41 <jbrooks> yeah
17:22:50 <ajeddeloh> it's mostly just a chroot, plus a little extra stuff
17:23:29 <kaeso> ajeddeloh: portables services do all relevant namespacing dances
17:24:02 <ajeddeloh> huh
17:24:22 <dustymabe> yeah i haven't had a chance to play with them myself I guess I should
17:24:36 <dustymabe> jbrooks: can we try to make sure there are issues opened for at least the selinux thing
17:24:36 <jbrooks> I got the kubelet running, but not working
17:24:50 <dustymabe> also maybe try newer systemd
17:24:55 <jbrooks> There's an issue, and lennart was like, I need help w/ that
17:24:58 <dustymabe> i think 240 or 241 just hit rawhide
17:25:07 <kaeso> IIRC, the kubelet "--containerized" flag was going to be deprecated as not really working
17:25:09 <jbrooks> And I tried 240
17:25:10 <dustymabe> so there is an open issue?
17:25:35 <jbrooks> looking for the issue
17:25:53 <dustymabe> thanks.. when you find it please add the link to the comment you alrady made
17:26:06 <dustymabe> ok moving on.. to the next minitopic
17:26:19 <dustymabe> minitopic: M - finalize strategy Collect metrics from Fedora CoreOS machines design #86
17:26:31 <dustymabe> looks like mattdm and bgilbert have some circling to do on this
17:26:40 * bgilbert circles
17:26:49 <dustymabe> which they mentioned in action items topic earlier
17:26:54 <dustymabe> so.. next topic?
17:27:08 <dustymabe> minitopic: M - complete bare metal installer: POC #91, Proof of concept complete
17:27:11 <bgilbert> heh, actually not
17:27:19 <bgilbert> #action bgilbert to email mattdm again
17:27:34 <bgilbert> #undo
17:27:34 <zodbot> Removing item from minutes: ACTION by bgilbert at 17:27:19 : bgilbert to email mattdm again
17:27:39 <bgilbert> #action bgilbert to reply to mattdm's email
17:27:43 <bgilbert> better phrasing is better
17:28:05 <dustymabe> dusty got sidetracked with a coreos-assembler issue last week, so will try to make progress again on #91 this week
17:28:22 <dustymabe> ok so that's all for this week.. some of the topics will move forward (already discussed)
17:28:32 <dustymabe> let's look at next week (which also happens to be devconf)
17:28:50 <dustymabe> 2019-01-21
17:28:51 <dustymabe> Week of Devconf.cz
17:28:54 <dustymabe> H - collaborate fedora releng integration #44
17:28:56 <dustymabe> H - investigate no cloud agents #95
17:28:57 <dustymabe> vmware #70, open new tickets for work items
17:29:00 <dustymabe> M - finalize strategy burndown python dependencies #92
17:29:01 <dustymabe> L - complete merge of fedora-toolbox and coreos-toolbox efforts #90
17:29:04 <dustymabe> H - investigate no cloud agents #95
17:29:06 <dustymabe> gce #67, open new tickets for work items
17:29:07 <dustymabe> H - finalize strategy ostree mirroring for better UX #54
17:29:15 <dustymabe> I moved ostree to next week (sinny will talk to fedora infra to solidify our approach there)
17:29:23 <dustymabe> ksinny: good with that ?
17:29:24 <ksinny> +1
17:29:32 <ksinny> yup
17:29:39 <dustymabe> and ksinny is already working on #92
17:29:50 <dustymabe> I'm going to try to get together with releng for #44
17:30:23 <dustymabe> ajeddeloh: has volunteered to look at #67, but if he gets bogged down we can have someone else that frees up to look at it
17:30:37 <dustymabe> bgilbert: volunteered for the pain that is #70
17:30:52 <bgilbert> hooray
17:31:04 <ajeddeloh> bgilbert and I have a meeting with the gcloud folks today
17:31:05 <dustymabe> i think yzhang was going to look at #90 but he is AFK today
17:31:13 <dustymabe> that is low priority so we can move it if we need to
17:31:27 <ajeddeloh> we can talk about gcloud support for fcos there
17:31:40 <dustymabe> cool cool
17:31:58 <dustymabe> ok any more comments on roadmap?
17:32:10 <dustymabe> sorry bgilbert for running long :(
17:32:20 * dustymabe gives the reins back to bgilbert
17:32:30 <bgilbert> dustymabe: I didn't give you much time :-(
17:32:31 <bgilbert> #topic Open Floor Super-Quick
17:33:09 <bgilbert> closing meeting in 60s
17:33:17 <dustymabe> #info sayan opened a package review for mantle in fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1665480
17:33:28 <dustymabe> i'm working through the review with him
17:33:37 <bgilbert> awesome
17:34:13 <bgilbert> #endmeeting