16:30:01 <bgilbert> #startmeeting fedora_coreos_meeting
16:30:01 <zodbot> Meeting started Wed Apr 10 16:30:01 2019 UTC.
16:30:01 <zodbot> This meeting is logged and archived in a public location.
16:30:01 <zodbot> The chair is bgilbert. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:30:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:30:01 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:30:06 <bgilbert> #topic roll call
16:30:15 <slowrie> .hello2
16:30:19 <zodbot> slowrie: slowrie 'Stephen Lowrie' <slowrie@redhat.com>
16:30:21 <kushal> .hellomynameis kushal
16:30:22 <bgilbert> .hello2
16:30:22 <zodbot> kushal: kushal 'Kushal Das' <mail@kushaldas.in>
16:30:23 <dmabe-webirc> .hellomynameis dustymabe
16:30:25 <zodbot> bgilbert: bgilbert 'Benjamin Gilbert' <bgilbert@backtick.net>
16:30:25 <kaeso> .hello lucab
16:30:26 <jbrooks> .fas jasonbrooks
16:30:27 <zodbot> dmabe-webirc: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:30:29 <rfairley> .hello2
16:30:30 <zodbot> kaeso: lucab 'Luca Bruno' <lucab@redhat.com>
16:30:33 <zodbot> jbrooks: jasonbrooks 'Jason Brooks' <jbrooks@redhat.com>
16:30:36 <jlebon> .hello2
16:30:37 <zodbot> rfairley: rfairley 'None' <rfairley@redhat.com>
16:30:39 <zodbot> jlebon: jlebon 'None' <jonathan@jlebon.com>
16:31:09 <lorbus> .hello2
16:31:10 <zodbot> lorbus: lorbus 'Christian Glombek' <cglombek@redhat.com>
16:31:26 <bgilbert> #chair slowrie kushal dmabe-webirc kaeso jbrooks rfairley jlebon lorbus
16:31:26 <zodbot> Current chairs: bgilbert dmabe-webirc jbrooks jlebon kaeso kushal lorbus rfairley slowrie
16:31:34 <ksinny> .hello sinnykumari
16:31:35 <zodbot> ksinny: sinnykumari 'Sinny Kumari' <ksinny@gmail.com>
16:32:12 <ajeddeloh> .hello2
16:32:13 <zodbot> ajeddeloh: ajeddeloh 'Andrew Jeddeloh' <andrew.jeddeloh@redhat.com>
16:32:57 <bgilbert> #chair ksinny ajeddeloh
16:32:57 <zodbot> Current chairs: ajeddeloh bgilbert dmabe-webirc jbrooks jlebon kaeso ksinny kushal lorbus rfairley slowrie
16:33:25 <bgilbert> #info Please add meeting topics to the etherpad: https://public.etherpad-mozilla.org/p/20190410-FCOS-Meeting
16:33:49 <bgilbert> #topic Action items from last meeting
16:33:50 <mnguyen_> .hello mnguyen
16:33:50 <dustymabe[m]> and here is a test from matrix (since I never got around to trying it before)
16:33:52 <zodbot> mnguyen_: mnguyen 'Michael Nguyen' <mnguyen@redhat.com>
16:34:01 <kushal> dustymabe[m], passed again
16:34:06 <bgilbert> #chair mnguyen_ dustymabe[m]
16:34:06 <zodbot> Current chairs: ajeddeloh bgilbert dmabe-webirc dustymabe[m] jbrooks jlebon kaeso ksinny kushal lorbus mnguyen_ rfairley slowrie
16:34:33 <bgilbert> * jlebon to file tracker issue: figure out storage strategy for FCOS Preview, get access to said storage, redirect CCI pipeline to it
16:34:43 <sayan> .hello sayanchowdhury
16:34:44 <zodbot> sayan: sayanchowdhury 'Sayan Chowdhury' <sayan.chowdhury2012@gmail.com>
16:34:48 <bgilbert> * kaeso open a ticket on coreos-assembler to sort out remote bucket layout for multi-arch artifacts
16:34:53 <bgilbert> #chair sayan
16:34:53 <zodbot> Current chairs: ajeddeloh bgilbert dmabe-webirc dustymabe[m] jbrooks jlebon kaeso ksinny kushal lorbus mnguyen_ rfairley sayan slowrie
16:34:57 <kaeso> that's https://github.com/coreos/coreos-assembler/issues/463
16:35:12 <bgilbert> #info kaeso filed https://github.com/coreos/coreos-assembler/issues/463
16:36:24 <bgilbert> #info jlebon filed https://github.com/coreos/fedora-coreos-tracker/issues/169
16:36:26 <walters> .hello2
16:36:27 <zodbot> walters: walters 'Colin Walters' <walters@redhat.com>
16:36:29 <bgilbert> #chair walters
16:36:29 <zodbot> Current chairs: ajeddeloh bgilbert dmabe-webirc dustymabe[m] jbrooks jlebon kaeso ksinny kushal lorbus mnguyen_ rfairley sayan slowrie walters
16:36:38 <jlebon> #info jlebon filed https://github.com/coreos/fedora-coreos-tracker/issues/169
16:36:52 <jlebon> bgilbert: hah, missed that you already #info'ed it :)
16:37:00 <bgilbert> #undo
16:37:00 <zodbot> Removing item from minutes: INFO by jlebon at 16:36:38 : jlebon filed https://github.com/coreos/fedora-coreos-tracker/issues/169
16:37:04 <bgilbert> :-P
16:37:33 <bgilbert> #topic Implement tooling for release streams
16:37:38 <bgilbert> #link https://github.com/coreos/fedora-coreos-tracker/issues/137
16:37:50 <bgilbert> brief update here:
16:38:23 <bgilbert> a few of us have been bouncing around a draft proposal for the mechanics of how release streams should be handled
16:38:55 <bgilbert> Git branches, rpm-ostree treefiles and lockfiles, promotion processes
16:39:28 <bgilbert> and I think we're about at the point where it seems reasonably coherent
16:40:08 <bgilbert> I didn't quite have it ready for this meeting, but a draft should go up in a fedora-coreos-tracker PR later today.
16:40:18 <bgilbert> please take a look and give feedback!
16:40:26 <jlebon> bgilbert: any particular bits you'd like to discuss in this meeting?
16:41:32 <bgilbert> not in isolation, I think?  I don't think of any specific piece as especially controversial (?)
16:41:56 <dustymabe[m]> I'd like to thank jlebon ksinny and bgilbert  for the hard work helping to draft a plan given our toolset and our desired goals. Can't wait to see the PR later today
16:41:57 <bgilbert> jlebon: anything from your side?
16:42:50 <jlebon> bgilbert: cool with me. let's just wait for for the PR and discuss there!
16:42:53 <bgilbert> +1
16:43:09 <bgilbert> I will point out the releng ticket for a koji tag which is part of this:
16:43:11 <bgilbert> #link https://pagure.io/releng/issue/8165
16:44:05 <bgilbert> let's plan to discuss the PR at next week's meeting and then see where we are
16:44:32 <dustymabe[m]> bgilbert: I think we need a new releng issue to create a new koji tag
16:44:40 <jlebon> haven't had a reply yet on that ticket. i think i may have to pop in #fedora-releng
16:44:51 <bgilbert> dustymabe[m]: for f30, you mean?
16:45:05 <ksinny> jlebon: I was planning to ping today as well for the update
16:45:30 <jlebon> yeah, there are two separate tags we've been discussing: the "build tools" tag, and the "pool" tag from which we ship things
16:45:50 <dustymabe[m]> bgilbert: no the continuous tag was meant for continous builds (i.e. testing out upstream SCM repos (unreleased software))
16:45:53 <jlebon> that ticket is for the former
16:45:56 <bgilbert> whooooops
16:45:58 <bgilbert> #undo
16:45:58 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x7f7e6988bc10>
16:46:02 <bgilbert> O:-)
16:46:05 <jlebon> ksinny: +1
16:46:37 <dustymabe[m]> bgilbert, but yes a new koji tag for this purpose should be easy to get
16:46:43 <bgilbert> thanks for the catch dustymabe[m] jlebon
16:46:45 <jlebon> ahh yes, that object at 0x7f7e6988bc10, i know it well
16:46:56 <ajeddeloh> Someone dropped a *
16:47:14 <bgilbert> #topic continuous builds for build tools that we consume
16:47:18 * dmabe-webirc notes that there is a slight delay on the messages coming into the matrix server :(
16:47:22 <bgilbert> #link https://github.com/coreos/fedora-coreos-tracker/issues/84
16:47:44 <walters> dmabe-webirc: sounds like a glitch
16:47:48 <dustymabe[m]> cool - i wanted to bring this up because I saw jlebon comment on the ticket and wanted to sync
16:48:45 <dustymabe[m]> jlebon beyond what is in the ticket do you have any plans for use ?
16:49:14 <dustymabe[m]> and just noticed I should have pasted this link too: https://pagure.io/releng/issue/8165
16:49:35 <bgilbert> #link https://pagure.io/releng/issue/8165
16:49:51 <jlebon> dustymabe[m]: just what was stated already in those convos; hooking up all the projects we iterate quickly on
16:50:51 <dustymabe[m]> jlebon my initial plans were to at least use this repo to enable us to build/deliver any rpm that we currently are consuming from copr
16:50:54 <jlebon> so do we need an AI for creating a separate ticket for the "pool" tag?
16:51:24 <dustymabe[m]> @jlebon yes I think we do need an AI for a separate tag. we can bikeshed on pool if necessary
16:51:43 <jlebon> dustymabe[m]: agreed, but also at least rpm-ostree
16:52:01 <dustymabe[m]> jlebon: +1 rpm-ostree sounds good to me
16:52:16 <dustymabe[m]> we need to wire up a bot that will trigger builds
16:52:34 <dustymabe[m]> i was also interested in `packit` but haven't had time to fully look into it
16:52:44 <dustymabe[m]> so that might be an option for actually performing builds
16:53:01 <dustymabe[m]> and we also need to take the dist-git branches to FESCO
16:53:43 <jlebon> dustymabe[m]: do we need to ask for a bot account for automating those builds?
16:53:47 <dustymabe[m]> hmm or maybe not - not sure about that one
16:54:08 <dustymabe[m]> jlebon I think tomas tomacek has already got a bot account that all of fedora can use
16:54:34 <ksinny> nice
16:54:43 <jlebon> gotcha. so if we integrate with packit, that part is figured out
16:55:03 <dustymabe[m]> yeah. IOW at least part of the problem of automating this might be solved for us already
16:55:20 <dustymabe[m]> which is nice because right now is when we have got to a point where we can use it
16:55:48 <dustymabe[m]> anybody interested in investigating packit and talking with tomas to see if we can use it ?
16:56:09 <jlebon> sure, i'll look into it
16:56:20 <dustymabe[m]> #link https://github.com/packit-service/packit
16:56:42 <bgilbert> #action jlebon to investigate packit
16:56:51 <bgilbert> other possible AIs: 1) request pool tag, 2) dist-git FESCO query.  any takers?
16:57:31 <ksinny> I can take the request pool tag
16:57:39 <bgilbert> #action ksinny to request pool tag
16:57:57 <dustymabe[m]> 1) - yes definitely an AI there.. might need some thought in how we want the tag set up based on the features we want (i.e. multiple versions of RPM in same tag)
16:58:18 <dustymabe[m]> 2) I think I was confused with the other ticket for backports (not continuous builds)
16:58:41 <dustymabe[m]> depending on how packit works maybe we don't need dist-git branches (probably not)
16:58:41 <bgilbert> dustymabe[m]: yeah, backports is what I thought you meant
16:58:44 <dustymabe[m]> so ignore #2 for now
16:58:45 <bgilbert> okay
16:58:58 <bgilbert> FYI, if we're not using a per-release tag for the pool, I'm going to update the proposal to specify two tags
16:59:08 <ksinny> yeah, good to create pool tag issue once FCOS stream implementation PR is finalized
16:59:09 <bgilbert> prod vs. non-prod
16:59:19 <bgilbert> bikeshed away, once we get there :-)
16:59:30 <dustymabe[m]> bgilbert: i.e. for differing GC policy ?
16:59:30 <bgilbert> good to move on?
16:59:33 <bgilbert> dustymabe[m]: yep
16:59:54 <dustymabe[m]> bgilbert: +1 - though I'd like to bikeshed on the names (later) :)
16:59:58 <bgilbert> sg
17:00:03 <bgilbert> #undo
17:00:03 <zodbot> Removing item from minutes: ACTION by bgilbert at 16:57:39 : ksinny to request pool tag
17:00:19 <bgilbert> #action ksinny to request pool tag(s) once stream implementation PR is finalized
17:00:45 <bgilbert> #topic LVM support in Ignition - how much and when?
17:01:06 <ajeddeloh> Ignition currently does not support LVM. This doesn't mean you can't set it up on first boot with systemd services, but that's kind of hacky
17:01:37 <ajeddeloh> We never really promoted it much from the CL side and I don't know what kind of adoption it has there
17:02:01 <bgilbert> I don't recall hearing of anyone using LVM on CL
17:02:05 <ajeddeloh> seems like FAH and other fedora folks make pretty heavy use of it so it makes sense to support it in Ignition
17:02:24 <ajeddeloh> Big questions are how much to support and when
17:02:32 <jlebon> we shipped with root on LVM by default, so they had no choice :)
17:03:27 <ajeddeloh> LVM is complex, so I don't think we should try to support all of it
17:04:04 <ajeddeloh> and we need a way of doing something similar to the filesystem "dont delete if existing and matching" for PXE
17:04:39 <ajeddeloh> Do people have thoughts on when we want to try to land this either in terms of time or spec version
17:04:45 <bgilbert> yeah, PVs + VGs + basic LVs is already a lot, given the need for state sync
17:05:00 <bgilbert> presumably we start with that and add features later if need be
17:05:33 * ajeddeloh isn't a LVM user so doesn't know more than the basics
17:05:51 * dustymabe[m] wonders if we shouldn't hand this off to some other tool
17:05:54 <bgilbert> handling LVM declaratively could be a massive rabbit hole
17:06:29 <bgilbert> e.g., if the user specifies an existing LV with a different size, I guess we resize?
17:06:41 <bgilbert> dustymabe[m]: how would that work?
17:06:41 <jlebon> i can see LVM being useful as a way to make hairy partitioning decisions easier as mentioned in https://github.com/coreos/fedora-coreos-tracker/issues/18#issuecomment-456124907
17:06:43 <dustymabe[m]> anybody familiar with ****** what is the name of the new storage project that culminates everything ?
17:06:50 <walters> stratis
17:07:20 <ajeddeloh> bgilbert: I dont think we should in that case
17:07:51 <dustymabe[m]> bgilbert: not sure exactly - just trying to think of a way we can let the complexity be somewhere else and throwing out ideas (albeit bad ones probably)
17:08:06 * bgilbert is having flashbacks to sgdisk
17:08:26 <kaeso> I guess most usage ends up in the "root on LVM" case, which I think it's also the hardest to do
17:08:26 <dustymabe[m]> #link https://stratis-storage.github.io/
17:08:27 <dustymabe[m]> thanks walters
17:08:33 <bgilbert> i.e., we tried to hand off partitioning logic to another tool and it was... counterproductive
17:09:05 <walters> kaeso: mmm, I could see having LVM just for /var being useful
17:09:07 <dustymabe[m]> kaeso: i'm not sure if 'root on LVM' gives the user much
17:09:14 <ajeddeloh> haha yeah, handling sgdisk output/logic is a mess
17:09:32 <dustymabe[m]> i.e. we manage the root partition mostly just for the ostree and let other FSs be state data the user manages
17:10:13 <ajeddeloh> I'm wary of introducing too many layer too, just in a KISS / not confuse users type of way
17:10:24 <dustymabe[m]> hmmm "Stratis is implemented as a daemon " -- might be a no go :(
17:10:46 <bgilbert> from a 20-second skim of the FAQ, looks like they're trying to solve a higher-level problem?
17:10:55 <bgilbert> stratis
17:11:04 <dustymabe[m]> so would MVP be a user being able to define a PV/VG/LV for `/var/` ?
17:11:30 <bgilbert> MVP would probably be a random non-system FS
17:12:37 <ajeddeloh> Agreed, though I don't see a reason why they wouldn't be equivilent (wait till implementation to find those reasons I guess)
17:12:41 <bgilbert> sure
17:13:02 <bgilbert> does anyone think this is super-important for the short term?
17:13:11 <dustymabe[m]> +1
17:13:36 <dustymabe[m]> I don't personally for FCOS anyway
17:13:54 <dustymabe[m]> seems like something we could easily do for after Preview Release
17:14:31 <ajeddeloh> +1
17:14:50 <bgilbert> +1
17:15:21 <bgilbert> ajeddeloh: good to move on?
17:15:29 <ajeddeloh> yup
17:15:39 <bgilbert> #topic final call for locksmith2 names
17:15:42 <bgilbert> #link https://github.com/coreos/fedora-coreos-tracker/issues/3#issuecomment-479558870
17:16:28 <kaeso> it sounds like we can proceed with creating the `coreos/airlock` repo?
17:16:43 <lorbus> +1
17:16:46 <bgilbert> +1
17:16:51 <sayan> airlock +1
17:16:53 <slowrie> wfm
17:17:08 <ajeddeloh> +1
17:17:12 <dustymabe[m]> WFM
17:17:39 <kaeso> ack. I think I need either bgilbert or dustymabe[m] for that for proper ACLs on it
17:17:45 <bgilbert> #action bgilbert to create coreos/airlock
17:18:16 <bgilbert> #topic kaeso started writing down the locksmith2 HTTP protocol
17:18:18 <bgilbert> #link https://hackmd.io/gOQigjYORx-DJdvyO1YSTg?view
17:18:41 <kaeso> and that's going to be the first PR for that repo
17:19:04 <kaeso> but if anybody wants an early read, I'm drafting it there
17:19:12 <bgilbert> +1
17:19:14 <lorbus> lucab++
17:19:17 <zodbot> lorbus: Karma for lucab changed to 3 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:19:58 <kaeso> and that's all I guess
17:20:04 <bgilbert> #topic Open Floor
17:20:45 * dustymabe[m] notes that I am mostly AFK these days helping out with new baby care - if you need anything from me please send me an email!
17:21:17 <dustymabe[m]> mixed 1st/3rd person - oh well
17:21:43 <lorbus> greenboot v0.7 is in fedora 30 and can be tested using the flow in https://github.com/LorbusChris/greenboot/blob/master/tests/README.md
17:22:03 <bgilbert> lorbus++
17:22:03 <zodbot> bgilbert: Karma for lorbus changed to 10 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:22:05 <lorbus> (you can leave out the manual download of the rpms)
17:22:08 <dustymabe[m]> lorbus: +1
17:22:15 <ajeddeloh> lorbus++
17:22:16 <ksinny> lorbus++
17:22:20 <dustymabe[m]> I had a separate question
17:22:21 <rfairley> lorbus++
17:22:22 <walters> just for general interest I am working in the background on rebasing Silverblue on FCOS, https://pagure.io/workstation-ostree-config/pull-request/109
17:23:06 <jlebon> lorbus: nice!
17:23:52 <dustymabe[m]> walters: that's just rebasing the configs on top of FCOS?
17:24:15 <walters> well, it also means the install process would change to match, it would support Ignition...
17:24:39 <dustymabe[m]> whoa.. so no anaconda installer ?
17:24:48 <walters> right, you boot straight into gnome-initial-setup
17:24:55 <ajeddeloh> huh, neat
17:24:57 <walters> that's actually how the desktop I'm typing this from was installed
17:25:08 <walters> from an earlier version of that PR
17:25:15 <dustymabe[m]> weird.. but how do you get it on the disk ?
17:25:19 <walters> dd
17:25:51 <dustymabe[m]> I don't think that's the experience we want for our desktop users though?
17:25:54 <walters> (I booted anaconda from USB since I had one lying around and did alt-f2 to get a shell, but you can use any live system of course)
17:26:01 <jlebon> hmm, will the rest of the Fedora community accept not using anaconda for the edition that is set to replace Workstation though?
17:26:21 <walters> oh yeah, clearly we want a live system too
17:26:31 <walters> i think we may be able to support both, I had some ideas on that
17:26:32 <dustymabe[m]> yeah anywho I guess that's a Silverblue topic
17:26:55 <walters> yep, just dropping the note
17:27:02 <dustymabe[m]> I had another question related to FCOS - did we ever figure out if NetworkManager could support being configured/run in the initrd ?
17:27:20 <dustymabe[m]> sorry I haven't read my bajillion GH notifications - the answer is probably in there somewhere already
17:27:35 <dustymabe[m]> walters: +1
17:27:39 <dustymabe[m]> thanks for dropping the note
17:27:40 <bgilbert> last state from my side is that https://developer.gnome.org/NetworkManager/stable/nm-initrd-generator.html exists but the RPM isn't shipping it right now for reasons that may not be relevant to us
17:27:50 <bgilbert> ksinny: have you looked at that at all?
17:27:53 <ksinny> dustymabe[m]: I was trying to look at that issue but I am slow, not much update from me on that
17:28:01 <dustymabe[m]> bgilbert: =1
17:28:05 <dustymabe[m]> grr +1
17:28:05 <bgilbert> ksinny: +1
17:28:26 <dustymabe[m]> if it's just the generator we should be able to just add it in to FCOS ourselves for F30 if we need it
17:28:43 <dustymabe[m]> we can add it to the overlay rpm that gets automatically created
17:29:11 <dustymabe[m]> thanks for the update bgilbert ksinny
17:29:20 <ksinny> I was trying to undersatnd how networkd ignition config currently works in CL and then was looking at FCOS
17:29:43 <dustymabe[m]> ksinny: feel free to ask questions to the experts :)
17:29:53 <ksinny> I have move to SIlverblue which is going slow due to figuring out new workflow :)
17:30:02 <ksinny> dustymabe[m]: yeah, I will
17:30:20 <ksinny> s/move to/moved to/
17:31:10 <bgilbert> looks like we're at time.  anything else for open floor?
17:31:48 <dustymabe[m]> nothing from me - thanks everyone for a fun meeting!
17:32:10 <jlebon> thanks bgilbert for hosting!
17:32:22 <bgilbert> #endmeeting