16:29:41 <dustymabe> #startmeeting fedora_coreos_meeting
16:29:41 <zodbot> Meeting started Wed Jan 23 16:29:41 2019 UTC.
16:29:41 <zodbot> This meeting is logged and archived in a public location.
16:29:41 <zodbot> The chair is dustymabe. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:29:41 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:29:41 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:29:47 <dustymabe> #topic roll call
16:29:51 <slowrie> .hello2
16:29:52 <dustymabe> .hello2
16:29:52 <zodbot> slowrie: slowrie 'Stephen Lowrie' <slowrie@redhat.com>
16:29:55 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:29:59 <rfairley> .hello2
16:30:00 <zodbot> rfairley: rfairley 'None' <robertthomasfairley@gmail.com>
16:31:40 <lorbus[m]> .hello lorbus
16:31:41 <zodbot> lorbus[m]: lorbus 'Christian Glombek' <cglombek@redhat.com>
16:32:15 <bgilbert> .hello2
16:32:16 <zodbot> bgilbert: bgilbert 'Benjamin Gilbert' <bgilbert@backtick.net>
16:33:13 * lorbus[m] is on a Brno-bound train, internet connection may vary
16:33:26 <dustymabe> #chair slowrie rfairley lorbus[m] bgilbert
16:33:26 <zodbot> Current chairs: bgilbert dustymabe lorbus[m] rfairley slowrie
16:33:36 <dustymabe> lorbus[m]: i love trains :)
16:34:11 <lorbus[m]> dustymabe: I concur
16:34:24 <geoff-> geoff-: 'Geoff Levand'  <geoff@infradead.org>
16:35:03 <dbenoit> .hello2
16:35:04 <zodbot> dbenoit: dbenoit 'David Benoit' <dbenoit@redhat.com>
16:35:23 <dustymabe> #chair geoff- dbenoit
16:35:23 <zodbot> Current chairs: bgilbert dbenoit dustymabe geoff- lorbus[m] rfairley slowrie
16:35:26 <dustymabe> welcome!
16:35:51 <dustymabe> #topic Action items from last meeting
16:36:01 <dustymabe> ok we had a few actions from last meeting
16:36:08 <dustymabe> * bgilbert to summarize discussion in #112 and #114
16:36:09 <dustymabe> * bgilbert to add "blocked" label to issues blocked on #24
16:36:11 <dustymabe> * kaeso to follow up with NM team
16:36:13 <dustymabe> * bgilbert to reply to mattdm's email
16:36:27 <dustymabe> bgilbert: usually people only get that many action items if they missed the meeting and we volunteered them for all the work
16:36:29 <dustymabe> :)
16:37:26 <bgilbert> dustymabe: cool, I get a compensatory get-out-of-meeting card :-)
16:37:40 <bgilbert> #info bgilbert added "blocked" label to issues blocked on #24
16:38:10 <bgilbert> #info bgilbert summarized discussion in #112 and #114
16:38:20 <bgilbert> #link https://github.com/coreos/fedora-coreos-tracker/issues/112#issuecomment-456683191
16:38:29 <bgilbert> #link https://github.com/coreos/fedora-coreos-tracker/issues/114#issuecomment-456686037
16:38:40 <dustymabe> since kaeso isn't here I can provide an update for him
16:38:53 <bgilbert> #info bgilbert replied to mattdm's email
16:39:03 <dustymabe> #info kaeso added a followup on Network Management issue (#24)
16:39:21 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/24#issuecomment-456150685
16:39:32 <bgilbert> there's a bit more context to the metrics thing:
16:40:14 <bgilbert> when the DNF UUID proposal was discussed on devel@, Lennart proposed dropping the UUID in favor of the client managing its own checkin cycle
16:40:16 <sayan> .hello sayanchowdhury
16:40:17 <zodbot> sayan: sayanchowdhury 'Sayan Chowdhury' <sayan.chowdhury2012@gmail.com>
16:40:24 <dustymabe> #chair sayan
16:40:24 <zodbot> Current chairs: bgilbert dbenoit dustymabe geoff- lorbus[m] rfairley sayan slowrie
16:40:41 <bgilbert> i.e., the first checkin of a week would have a special URL parameter
16:40:55 <bgilbert> so that aggregation didn't need to happen server-side and there didn't need to be a unique client ID.
16:41:25 <dustymabe> so basically the client is programmed to manage checkins so that the server doesn't have to dedup entries
16:41:25 <bgilbert> that will work for us too.  the UUID idea for FCOS metrics came from how CoreUpdate handles client checkins now
16:41:32 <bgilbert> dustymabe: right
16:41:41 <dustymabe> seems cool to me
16:41:54 <bgilbert> I don't see any reason we actually _need_ UUIDs here
16:41:56 <dustymabe> and the client side is "more trustworthy/transparent"
16:42:10 <bgilbert> yup
16:42:11 <bgilbert> #link https://github.com/coreos/fedora-coreos-tracker/issues/86#issuecomment-456671991
16:42:42 <lorbus[m]> bgilbert++
16:42:50 <dustymabe> that's a cool idea. I guess theoretically someone could fiddle with a client and make someone report things over and over and throw off our data
16:43:02 <bgilbert> dustymabe: that's true no matter what we do, though
16:43:06 <dustymabe> indeed
16:43:21 <dustymabe> thanks for the report bgilbert, for some reason that makes me a bit excited
16:43:35 <bgilbert> yeah, I had the same reaction
16:43:45 <dustymabe> I liked the idea of metrics before, but always figured we'd be giving up something, some trust
16:43:54 <dustymabe> i think the new approach helps
16:44:02 <bgilbert> +1
16:44:04 <bgilbert> it does depend on the stability of client clocks, but there's ways around that if it turns out to be a problem
16:45:04 <slowrie> is this for a separate metrics check-in or part of the update call which is just counting nodes?
16:45:18 <bgilbert> I think I'm in favor of starting with the simplest thing, and then evolving the system as needed
16:45:31 <bgilbert> slowrie: we're not going to be doing any counting in the updates system
16:45:40 <bgilbert> slowrie: in the broader Fedora ecosystem, dnf will be
16:45:49 <slowrie> +1, wanted to make sure we weren't tying it to that so we didn't have the same issue we do with CL
16:45:56 <bgilbert> slowrie: +1
16:46:16 <dustymabe> ok i think that's it for action items
16:46:26 <dustymabe> and we don't have any `meeting` tickets this week
16:46:37 <dustymabe> bgilbert: any topic we should follow up on before moving to roadmap ?
16:47:22 <bgilbert> I don't think so
16:48:25 <dustymabe> #topic roadmap: this week
16:48:57 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/blob/master/ROADMAP.md
16:49:19 <dustymabe> reminder this is the week of devconf so we are missing quite a few contributors due to travel
16:49:29 <dustymabe> some of them have joined us from train - lorbus[m] :)
16:49:45 <dustymabe> there are a few items we had scheduled that are already completed
16:49:56 <dustymabe> H - finalize strategy,collaborate Network Management #24
16:49:57 <dustymabe> gaps identified feature work requested
16:49:59 <dustymabe> H - finalize strategy ostree mirroring for better UX
16:50:17 <dustymabe> as mentioned earlier kaeso posted a follow up to the Network Management strategy in #24
16:50:49 <dustymabe> it looks like we are converging on a solution there using network manager for FCOS, but still requires some work to be completed by the NM team
16:51:10 <dustymabe> Sinny also was able to sync with the Fedora Infra team in Brno
16:51:29 <dustymabe> and it looks like our plans for ostree mirroring for better UX are going to be approved
16:52:08 <dustymabe> the final proposal is that we continue to use CDN, but have a more optimized setup so that we don't allow thousands of HTTP redirects to kill our performance
16:52:40 <dustymabe> we'll also list our CDNs in a mirrorlist so that we can add more than one CDN to the mix if we get volunteered more resources from other providers
16:53:16 <slowrie> dustymabe: is there a standard used in Fedora or would it be worthwhile to just throw it on cloudfront?
16:53:25 <lorbus[m]> choo choo the CoreOS train is on track ^^)
16:53:35 <dustymabe> slowrie: "standard"?
16:54:18 <dustymabe> we are using cloudfront already as the CDN, thanks to davdunc
16:54:30 <slowrie> gotcha
16:54:43 <dustymabe> the problem with our current setup is that the way it is implemented causes the clients to follow a redirect for every file
16:54:53 <dustymabe> in the future with the new setup, they won't have to do that
16:55:03 <dustymabe> the performance difference has showed promise
16:55:43 <dustymabe> any questions before I move on to the rest of the items for this week?
16:56:17 <dustymabe> M - finalize strategy burndown python dependencies #92
16:56:19 <dustymabe> H - investigate no cloud agents #95
16:56:21 <dustymabe> gce #67, open new tickets for work items
16:56:23 <dustymabe> M - complete bare metal installer: POC #91
16:56:25 <dustymabe> Proof of concept complete
16:56:54 <dustymabe> sinny is working on tracking down our python deps and has opened a ticket for each one so we can focus the investigation
16:57:14 <dustymabe> we also modified the original description of #92 to show checkboxes
16:57:27 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/92
16:58:13 <dustymabe> I saw that colin had a comment in a closed ticket as well, which bgilbert responded to
16:58:21 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/32#issuecomment-455579535
16:59:05 <dustymabe> which could have implications here if we aren't manage to rid our selves of all python deps
16:59:24 <dustymabe> "aren't manage" - where did I learn english?
16:59:25 <bgilbert> I'm super-excited about that proposal btw.  :-D
17:00:37 <dustymabe> bgilbert: what about an option where we just list replace /usr/bin/python3 with a script that checks the calling program against a whitelist and then execs `/usr/libexec/python` ?
17:00:50 <dustymabe> s/list//
17:00:53 <slowrie> To me that seems more like a stop-gap until we could fully remove python; it makes it obvious we don't want users to touch it and should be something we could rip out once we finish removing all the dependencies
17:00:56 <bgilbert> well, the point is to prevent users from invoking it
17:01:13 <bgilbert> if they can call /usr/libexec/python directly, then we don't achieve that
17:01:29 <dustymabe> bgilbert: ahh yeah
17:01:32 <bgilbert> and if we have /usr/libexec/python, we don't need the one in /usr/bin; we just update all the #! lines
17:02:15 <dustymabe> ok. so maybe we investigate colin's proposal at some point
17:02:42 <dustymabe> next up in the list for this week is gce
17:03:03 <dustymabe> i know andrew had volunteered for that. he is travelling this week and i think AFK next week
17:03:07 <bgilbert> right
17:03:16 <dustymabe> anybody else interested in picking that one up? if not it can wait
17:03:40 <slowrie> I was going to pick it up but ended up starting a different task that I think is more important
17:04:03 <bgilbert> Andrew handled the OS Login integration for CL and has been dug into their agent as well
17:04:11 <bgilbert> I think it makes the most sense to wait
17:04:26 <bgilbert> s/been //
17:04:35 <slowrie> +1, from what I remember hearing it was non-trivial to get OS login integrated
17:04:55 <dustymabe> +1
17:05:06 <dustymabe> SGTM - /me needs to learn GCE more too
17:05:15 <dustymabe> all the clouds - all the time :)
17:05:26 <dustymabe> ok final one is #91 - for bare metal
17:05:56 <dustymabe> I'm continuing to work on that - i may go absent from IRC this afternoon so I can get some dedicated time to investigate
17:06:35 <dustymabe> any more comments for roadmap items for this week before we move to next week?
17:07:38 <dustymabe> #topic roadmap: next week
17:07:42 <dustymabe> M - finalize strategy Collect metrics from Fedora CoreOS machines design #86
17:07:44 <dustymabe> M - complete Host Installer for Fedora CoreOS (bare metal) #50
17:07:46 <dustymabe> Action items, gaps identified from POC (#91) have been fixed
17:07:48 <dustymabe> H - finalize strategy Kubernetes/OKD strategy #93
17:07:50 <dustymabe> H - collaborate fedora releng integration #44
17:07:52 <dustymabe> L - complete merge of fedora-toolbox and coreos-toolbox efforts #90
17:07:54 <dustymabe> here is what we have on the agenda for next week
17:08:05 <dustymabe> it looks like from our earlier discussion the metrics strategy has been making progress already
17:08:26 <bgilbert> +1
17:08:33 <dustymabe> i'm working on #91, which carries into #50
17:08:58 <dustymabe> also #44 is on me - working to set up some time for us to meet with releng
17:09:16 <dustymabe> #93 we may have to punt for a little while
17:09:43 <dustymabe> #90 - i'm not sure if jerry has made progress on this recently, but will ask
17:10:01 <slowrie> bgilbert: should we add #129 to the roadmap soon-ish?
17:10:28 <bgilbert> slowrie: +1
17:11:00 <dustymabe> yes. there are definitely things missing from the roadmap right now
17:11:12 <dustymabe> a few things identified recently by bgilbert for cloud platform work
17:11:16 <dustymabe> that need to be added
17:11:41 <dustymabe> also discussion/decisions regarding update frameworks and how that integrates with rpm-ostree
17:12:02 <dustymabe> it's a brave new world :)
17:12:33 <dustymabe> #topic open floor
17:12:47 <dustymabe> yay.. some actual time for open floor today
17:13:05 * lorbus[m] is approaching Brno, drops from mtg
17:13:15 <dustymabe> #info sayan's code review for mantle rpm passed review
17:13:27 <dustymabe> #link https://src.fedoraproject.org/rpms/mantle
17:13:32 <dustymabe> new dist-git repo ^^
17:14:23 <rfairley> sayan++ nice!
17:14:23 <zodbot> rfairley: Karma for sayanchowdhury changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:14:59 <dustymabe> bgilbert: are you interested in discussing https://github.com/coreos/fedora-coreos-tracker/issues/129 here?
17:16:11 <bgilbert> we can.  detailed discussion should wait for ajeddeloh though
17:16:40 <dustymabe> +1
17:16:56 <bgilbert> anything in particular?
17:16:57 <dustymabe> i am interested to know if you think a 'plugin' model could work
17:17:04 <dustymabe> https://github.com/coreos/fedora-coreos-tracker/issues/129#issuecomment-456840108
17:17:09 <bgilbert> ah, yeah, I have a draft reply written up
17:17:18 <bgilbert> we've talked about that sort of thing before
17:17:19 <dustymabe> ah cool. it can wait
17:17:31 <bgilbert> I think it's a good idea in the medium term.
17:17:45 <bgilbert> for now, we should probably avoid major refactoring while we're trying to get FCOS out the door
17:18:17 <dustymabe> I see. for some reason I thought FCOSCT was going to be a re-write
17:18:34 <bgilbert> maybe eventually.  (in Rust?)  but for time reasons, not at first.
17:18:50 <dustymabe> +1 - in that case we shouldn't re-architect it
17:18:59 <bgilbert> the original model was that every distro implement their own CT, but that seems highly suboptimal.  so a distro-independent framework sounds great to me.
17:19:01 <bgilbert> yeah
17:19:10 <dustymabe> awesome :)
17:19:49 <dustymabe> we've already got some interest/contributions from Suse on ignition so a cross platform CT with platform specific plugins seems like it might be of interest to them too
17:19:58 <bgilbert> +1
17:20:14 <dustymabe> anyone else with anything for open floor?
17:20:26 <dustymabe> geoff-: dbenoit - good to see you here today
17:20:39 <dustymabe> anything of particular interest to you?
17:21:14 <geoff-> I came to the office early today...
17:21:22 <dbenoit> just sitting in today, thanks!
17:21:37 <dustymabe> cool deal.. welcome to all. tell your friends :-P
17:22:18 <geoff-> btw, I'm always getting kicked off #fedora-coreos
17:22:20 <dustymabe> I'll leave the meeting open a minute or two for any new topics.. if not I'll close out
17:22:37 <dustymabe> geoff-: actually kicked out? or disconnected?
17:23:01 <geoff-> sent to the unregistered channel
17:23:28 <dustymabe> so we had a period of time where spammers were pretty bad
17:23:42 <dustymabe> so we made 'registered user' a requirement
17:24:00 <dustymabe> is your nick registered with freenode?
17:24:26 <geoff-> the problem is that it sends me over there before my irc client has registered me
17:24:53 <dustymabe> so during your IRC client startup ?
17:25:24 <geoff-> then and at various times while I am connected and loged into the channel
17:26:14 <dustymabe> geoff-: that's odd. does anyone else have a problem of periodically getting kicked the the unregistered channel from #fedora-coreos ?
17:26:26 <dustymabe> s/the the/to the/
17:27:07 <slowrie> I haven't seen it
17:27:20 <dbenoit> I have the same issue of my client trying to join before registering me, but I don't usually get kicked after joining.  It happens on any channel with a user registration requirement
17:27:23 <slowrie> And my client is always idling
17:27:42 <dustymabe> geoff-: do you connect from a transient machine (like a laptop that suspends all the time)?
17:27:54 <dustymabe> i connect from a persistent machine, so that could explain why I don't see the behavior
17:28:37 <jbrooks> I got kicked like that from a bunch of channels on freenode yesterday or the day before
17:28:44 <slowrie> might be worthwhile filing a bug with the IRC client if it's connecting to channels before finishing connecting / registering
17:29:12 <geoff-> dustymabe: no, from my desk machine at work.
17:29:39 <dustymabe> geoff-: hmm - ok let's carry this over to #fedora-coreos
17:29:40 <slowrie> stepping out for lunch, thanks for running the meeting dustymabe
17:29:43 <dustymabe> I'll close out the meeting
17:29:47 <dustymabe> #endmeeting