16:32:09 <dustymabe> #startmeeting fedora_coreos_meeting
16:32:09 <zodbot> Meeting started Wed Mar  6 16:32:09 2019 UTC.
16:32:09 <zodbot> This meeting is logged and archived in a public location.
16:32:09 <zodbot> The chair is dustymabe. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:32:09 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:32:09 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:32:16 <dustymabe> #topic roll call
16:32:20 <yzhang> .hello2
16:32:20 <slowrie> .hello2
16:32:21 <zodbot> yzhang: yzhang 'Yu Qi Zhang' <jzehrarnyg@gmail.com>
16:32:22 <dustymabe> .hello2
16:32:23 <zodbot> slowrie: slowrie 'Stephen Lowrie' <slowrie@redhat.com>
16:32:26 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:32:30 <bgilbert> .hello2
16:32:32 <zodbot> bgilbert: bgilbert 'Benjamin Gilbert' <bgilbert@backtick.net>
16:32:36 <mnguyen_> .hello mnguyen
16:32:37 <zodbot> mnguyen_: mnguyen 'Michael Nguyen' <mnguyen@redhat.com>
16:32:43 <jbrooks> .fas jasonbrooks
16:32:44 <zodbot> jbrooks: jasonbrooks 'Jason Brooks' <jbrooks@redhat.com>
16:32:59 <ajeddeloh> .hello2
16:33:00 <zodbot> ajeddeloh: ajeddeloh 'Andrew Jeddeloh' <andrew.jeddeloh@redhat.com>
16:33:34 <ksinny> .hello sinnykumari
16:33:34 <zodbot> ksinny: sinnykumari 'Sinny Kumari' <ksinny@gmail.com>
16:34:29 <dustymabe> #chair yzhang slowrie bgilbert mnguyen_ jbrooks ajeddeloh ksinny
16:34:29 <zodbot> Current chairs: ajeddeloh bgilbert dustymabe jbrooks ksinny mnguyen_ slowrie yzhang
16:35:13 <dustymabe> Here is the agenda for today's meeting, please add open floor topics: https://public.etherpad-mozilla.org/p/20190306-FCOS-Meeting
16:35:35 <dustymabe> #topic Action items from last meeting
16:36:00 <dustymabe> we had no action items last meeting \o/
16:37:37 <dustymabe> Ok we don't have any meeting tickets this week
16:37:55 <dustymabe> I'll start going through open floor topics
16:38:12 <dustymabe> #topic open floor: separate 'bugs' tracker
16:38:51 <dustymabe> as we get closer to Fedora CoreOS being a real thing how do we feel about our current decision to keep the tracker as the primary location where people open issues ?
16:39:20 * dustymabe notes that we do now have the ability to 'transfer' issues to other repos, which is nice
16:39:52 <bgilbert> I'm generally in favor of the giant-combined-tracker model
16:40:14 <bgilbert> otherwise bugs end up filed in random places
16:40:23 <ajeddeloh> I could go either way. It's a little cluttered with both, but having one place to do everything is nice, especially with things that kind of sit between bugs and RFEs/design dicsussions
16:40:30 <bgilbert> we can always use labels to distinguish design issues from bugs, etc.
16:40:57 <dustymabe> bgilbert: how do you feel about moving issues to appropriate sub projects (if we can) through github issue transfer ?
16:41:41 <bgilbert> dustymabe: not sure I understand the question
16:41:48 <bgilbert> I've used issue transfer a couple times and it seems to work well
16:42:00 <bgilbert> if there's an upstream Ignition issue filed in the fcos-tracker I think we should move it
16:42:02 <bgilbert> and vice versa
16:42:07 <dustymabe> +1
16:42:13 <dustymabe> that was the question. thanks for answering
16:42:15 <ajeddeloh> +1 to that as well
16:42:16 <bgilbert> +1
16:42:40 <dustymabe> ok we can keep the current model and use labels to filter things out
16:42:56 <bgilbert> we can always change later if it becomes too unwieldy
16:42:59 * dustymabe notes we need to go through old issues and try to clean up things where we can
16:43:08 <bgilbert> dustymabe: +1
16:43:29 <bgilbert> bug gardening is important
16:43:34 <dustymabe> ok i'm just going to keep adding issues to discuss unless someone else adds something to the etherpad: https://public.etherpad-mozilla.org/p/20190306-FCOS-Meeting
16:44:16 <dustymabe> #topic logging the #fedora-coreos channel
16:44:35 <dustymabe> it looks like a community member suggested echelog.com/
16:44:41 <dustymabe> https://github.com/coreos/fedora-coreos-tracker/issues/11#issuecomment-432578436
16:44:55 <ajeddeloh> So I looked at botbot.me yesterday and didn't see an easy way to set a expiry on saved messages
16:44:57 <dustymabe> anyone interested in fleshing out that option to see if it's something we could use?
16:45:35 <dustymabe> ajeddeloh: do you know how botbot.me stores information? if it's in a database then we might just be able to query and droop messages older than X date
16:46:55 <ajeddeloh> Looks like just sql and / or redis (I think redis is just used as a queuing service for things, didn't look too closely)
16:47:04 <dustymabe> kk
16:47:24 <dustymabe> ajeddeloh: WDYT of looking at echelog.com ? we might be able to get them to start indexing us?
16:47:32 <ajeddeloh> +1
16:48:10 <ajeddeloh> I guess we can just request they log us, if we're not running it we don't have the GDPR liability
16:48:16 <dustymabe> right
16:48:35 <dustymabe> want to try?
16:48:47 <ajeddeloh> Yeah, I'll shoot em an email
16:49:25 <dustymabe> #action ajeddeloh to ask echelog.com if they can log our channel
16:49:33 <dustymabe> thanks ajeddeloh!
16:49:35 <ajeddeloh> bgilbert: do you want me to see about logging #coreos while I'm at it?
16:50:20 <bgilbert> ajeddeloh: might as well
16:50:29 <dustymabe> #topic open floor: status on python efforts
16:50:53 <dustymabe> ksinny: thanks for pushing these all along. any updates from the past weeks on this? any blockers?
16:51:05 <ajeddeloh> ksinny++
16:51:06 <zodbot> ajeddeloh: Karma for sinnykumari changed to 8 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:51:18 <ksinny> dustymabe: no blocker, we are good. Few items are left
16:52:00 <dustymabe> should we start cutting items from our configs ?
16:52:10 <ksinny> 1. Getting packages built in Fedora with updated change and getting 1 pr merged. They are waiting on maintainer, taking it slow to give them time
16:52:51 <dustymabe> some of the ones that we are just going to drop completely we can go ahead and drop, right?
16:52:53 <ksinny> 2. Need to verify few packages we are removingwhether they work fine in continer
16:52:56 <dustymabe> like the selinux stuff
16:52:58 <ksinny> other than that we are all set
16:53:49 <dustymabe> +1
16:53:52 <dustymabe> thanks sinny
16:53:58 <ksinny> dustymabe: yeah, we can drop python-policy*
16:54:04 <ksinny> forgot the complete name
16:54:49 <ksinny> I thought of sending a PR once we are done with remaining item, also we will need to wait until we move to build F30 base image
16:55:03 <dustymabe> yeah we should do that soonish
16:55:04 <ksinny> since these changes will be applicable to F30+ packages
16:55:24 <dustymabe> maybe once we get the no anaconda stuff in
16:55:32 <ksinny> +1
16:55:35 <dustymabe> ok moving on to next topic
16:55:49 <dustymabe> #topic open floor: thoughts on disabling various systemd bits
16:56:33 * dustymabe yields floor
16:56:41 <ajeddeloh> So I've been hitting things that we've had disabled at compile time or masked out via INSTALL_MASK (list of files that dont get installed on gentoo) on CL that are in the fedora systemd rpm
16:56:53 <ajeddeloh> What's the approach we want to take here
16:57:08 <bgilbert> ajeddeloh: examples?
16:57:10 <ajeddeloh> a couple examples are the systemd-firstboot.service and systemd-gpt-auto-generator
16:58:12 <ajeddeloh> I don't know off the top of my head if you can mask generators (mask in a systemd sense, not a packaging/install sense)
16:58:25 <ajeddeloh> the systemd-firstboot.service unit can be masked
16:58:37 <ajeddeloh> we can also manually remove files with rpm-ostree
16:59:38 <ajeddeloh> I'm wondering what approach we should take here
16:59:51 <dustymabe> we can remove things we don't need - but probably case by case?
17:00:24 <ajeddeloh> remove as in with rpm-ostree?
17:00:34 <dustymabe> ajeddeloh: either that or effectively remove
17:00:48 <dustymabe> i.e. if we can mask it, maybe that's a better option?
17:01:28 <bgilbert> shipping code that we don't want executed seems suboptimal
17:02:22 <dustymabe> either way works, it's almost always going to be case by case, though right?
17:02:38 <dustymabe> so we should have a nice list of things that we remove and why
17:02:41 <dustymabe> i.e. good comments
17:04:28 <ajeddeloh> +1 things that have no reason to ship (i.e. systemd-firstboot) I'll remove with good comments
17:04:34 <ajeddeloh> looks like you can mask generators
17:04:54 <ajeddeloh> So things that _might_ be useful I'll mask instead
17:05:40 <dustymabe> in general should we sprint to getting something that we then trim the fat from?
17:06:03 <dustymabe> i.e. let's spend more time building up something that we then take a scalpel to?
17:07:15 <ajeddeloh> Sure, in most cases. I think if we see something easy to strip along the way we should do it quickly before we forget though
17:07:56 <dustymabe> +1
17:08:00 <dustymabe> agree with that
17:08:13 <dustymabe> any more comments here before moving on to the next topic?
17:09:39 <dustymabe> #topic open floor: ignition spec3x status
17:10:01 <dustymabe> there's been a lot of good work here from ajeddeloh slowrie jlebon and rfairley
17:10:48 <dustymabe> anybody have a rough estimate for when we think we'll be able to have a first release for Fedora
17:10:49 <ajeddeloh> I need to review jlebons PR, glanced at it yesterday but haven't given it a full review yet
17:11:38 <rfairley> thanks dustymabe!
17:11:46 <slowrie> I think ajeddeloh is still working on two larger issues that need to land first and there's a couple of misc smaller things that are either up for review already or still need to be started
17:11:54 <ajeddeloh> The big outstanding issues are intertwined and are the config dedup/merging
17:12:50 <dustymabe> ajeddeloh: k - are those like a week of working/thinking?
17:12:55 <ajeddeloh> And it ended up pulling in a big refactor that needed to happen anyway
17:13:01 <ajeddeloh> that's probably a good estimate
17:13:01 <dustymabe> refactor++
17:13:18 <ajeddeloh> the refactor is the config/ package refactor
17:13:46 <ajeddeloh> I met with the MCO team yesterday too to make sure the changes aren't painful for them and the new api is better
17:14:07 <dustymabe> ajeddeloh: if i just took ignition and igntion-dracut from master and built it and tried it out on FCOS - would it fail horribly
17:14:19 <ajeddeloh> right now, yes
17:14:20 <dustymabe> or would i be able to legitimately test and open bugs for issues
17:14:27 <ajeddeloh> after jlebon's PR merges no
17:15:03 <dustymabe> ajeddeloh: ok i'll freeze on 2ce015b then
17:15:43 <ajeddeloh> thoughts on me setting up a copr to track both masters?
17:16:21 <dustymabe> ehh - probably not worth it if it's only a week out
17:16:37 <ajeddeloh> yeah, theres still some small stuff that needs to go in too
17:16:45 <dustymabe> this actually leads into another topic which I can have an update on
17:17:00 <ajeddeloh> rfairley has been helping with a lot of that (I owe you a review too)
17:17:18 <dustymabe> rfairley++
17:17:20 <dustymabe> ajeddeloh++
17:17:20 <zodbot> dustymabe: Karma for ajeddeloh changed to 5 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:17:33 <dustymabe> next topic?
17:17:34 <slowrie> We still need someone to pick up the `Default files.overwrite to false` issue as well
17:17:36 <slowrie> if anyone's interested
17:17:41 <dustymabe> slowrie: link ?
17:18:24 <slowrie> #link https://github.com/coreos/ignition/issues/604
17:18:33 <rfairley> mostly to sanity check that the change I made works as expected, I've been building the RPM for a slightly older ignition master, along with the ignition-dracut that gets downloaded ./download-ignition-dracut.sh (in https://src.fedoraproject.org/rpms/ignition/tree/master)
17:18:41 <dustymabe> slowrie: thanks - will try to find someone to help out with that
17:19:12 <dustymabe> #topic open floor: update on continuous builds
17:19:25 <rfairley> thanks ajeddeloh! and thanks those who are reviewing
17:19:33 <dustymabe> so I got releng to create us a `f29-coreos-continuous` koji tag
17:20:12 <dustymabe> the idea here is that we'll be able to build rpms from upstream sources (i.e. ignition) and tag them into this tag and use the resulting yum repos to build/test FCOS
17:20:31 <dustymabe> so kind of like rpmdistro-gitoverlay
17:20:46 <dustymabe> but using koji to build the rpms (+1 for multi-arch)
17:21:06 <dustymabe> there is some tooling that will need to be built around this to make it all work, but it's a first step
17:21:07 <ajeddeloh> will we still need to update the spec files for that
17:21:25 <dustymabe> ajeddeloh: the idea is that it's automated
17:21:28 <ajeddeloh> or will it automatically replaces SOURCEs
17:21:31 <ajeddeloh> gotcha
17:21:53 <dustymabe> i.e. ignition gets new commit to master - then a bot updates things and kicks off a build - then a yum repo is created - then an FCOS is build - then kola tests run
17:21:57 <ajeddeloh> sys-apps/ignition-9999 returns!
17:22:08 <jcajka> dustymabe: are you also thinking about building the cosa container in the koji?
17:22:19 * jcajka is toying with that idea
17:22:26 <dustymabe> jcajka: we don't have any plans to do that right now
17:22:57 <dustymabe> if anything we'd build it in OSBS (accepts a proper Dockerfile)
17:23:03 <dustymabe> but that's a bit off
17:23:10 <dustymabe> if we did decide to do it
17:23:17 <jcajka> dustymabe: IMHO if you are already building the packages, container it self should be basically the same
17:23:34 <jcajka> I mean by koji, OSBS, container build
17:24:03 <dustymabe> yeah, not sure exactly TBH
17:24:10 <dustymabe> haven't thought too much into that
17:24:23 <dustymabe> maybe grab me in #fedora-coreos after and we can chat ?
17:24:29 <dustymabe> or open a ticket on the tracker
17:24:42 <jcajka> sure, I will follow up on it
17:25:08 <dustymabe> #topic open floor: coreos streams and releng integration
17:25:45 <dustymabe> a few of us have been brainstorming ideas on how we integrate the tools that fedora has within releng (i.e. koji) to achieve our goals with our coreos release streams
17:26:06 <dustymabe> defined here: https://github.com/coreos/fedora-coreos-tracker/blob/master/Design.md#release-streams
17:26:31 <dustymabe> we are working through some proposals on how to use koji for this and the related tooling around it that will be needed
17:26:54 <dustymabe> we should have a proposal soon and then we can see if it works
17:27:59 <dustymabe> thanks to ksinny jlebon and bgilbert for helping work on that
17:28:11 <dustymabe> any comments before next topic?
17:29:05 <dustymabe> #topic open floor
17:29:34 <dustymabe> any comments/questions before we close the meeting?
17:30:31 <dustymabe> thanks everyone for coming!
17:30:34 <dustymabe> #endmeeting