16:30:16 <ajeddeloh> #startmeeting fedora_coreos_meeting
16:30:16 <zodbot> Meeting started Wed Apr 24 16:30:16 2019 UTC.
16:30:16 <zodbot> This meeting is logged and archived in a public location.
16:30:16 <zodbot> The chair is ajeddeloh. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:30:16 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:30:16 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:30:25 <ajeddeloh> #topic roll call
16:30:38 <dustymab1> .hello2
16:30:40 <zodbot> dustymab1: Sorry, but you don't exist
16:30:41 <ajeddeloh> .hello2
16:30:42 <zodbot> ajeddeloh: ajeddeloh 'Andrew Jeddeloh' <andrew.jeddeloh@redhat.com>
16:30:47 <dustymabe> .hello2
16:30:48 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:30:57 <mnguyen_> .hello mnguyen
16:30:58 <zodbot> mnguyen_: mnguyen 'Michael Nguyen' <mnguyen@redhat.com>
16:31:03 <bgilbert> .hello2
16:31:04 <zodbot> bgilbert: bgilbert 'Benjamin Gilbert' <bgilbert@backtick.net>
16:31:05 <slowrie> .hello2
16:31:07 <miabbott> .hello2
16:31:08 <zodbot> slowrie: slowrie 'Stephen Lowrie' <slowrie@redhat.com>
16:31:11 <zodbot> miabbott: miabbott 'Micah Abbott' <miabbott@redhat.com>
16:31:18 <ajeddeloh> #chair ajeddeloh dustymabe mnguyen_ bgilbert slowrie miabbott
16:31:18 <zodbot> Current chairs: ajeddeloh bgilbert dustymabe miabbott mnguyen_ slowrie
16:31:44 <ajeddeloh> #info please add items to the meeting agenda at https://public.etherpad-mozilla.org/p/20190424-FCOS-Meeting
16:31:52 <rfairley> .hello2
16:31:53 <zodbot> rfairley: rfairley 'None' <rfairley@redhat.com>
16:32:01 <ajeddeloh> #chair rfairley
16:32:01 <zodbot> Current chairs: ajeddeloh bgilbert dustymabe miabbott mnguyen_ rfairley slowrie
16:33:14 <ajeddeloh> #topic Action items from last meeting
16:33:24 <ajeddeloh> * ksinny to request pool tags
16:33:46 <kaeso> .hello lucab
16:33:47 <zodbot> kaeso: lucab 'Luca Bruno' <lucab@redhat.com>
16:33:59 <ajeddeloh> #chair kaeso
16:33:59 <zodbot> Current chairs: ajeddeloh bgilbert dustymabe kaeso miabbott mnguyen_ rfairley slowrie
16:34:05 <jbrooks> .fas jasonbrooks
16:34:05 <zodbot> jbrooks: jasonbrooks 'Jason Brooks' <jbrooks@redhat.com>
16:34:10 <ajeddeloh> is ksinny around?
16:34:16 <ajeddeloh> #chair jbrooks
16:34:16 <zodbot> Current chairs: ajeddeloh bgilbert dustymabe jbrooks kaeso miabbott mnguyen_ rfairley slowrie
16:34:21 * nirik notes we are talking about this in the releng meeting in fedora-meeting-2 right now. ;)
16:34:22 <jlebon> .hello2
16:34:23 <zodbot> jlebon: jlebon 'None' <jonathan@jlebon.com>
16:34:30 <bgilbert> pretty sure ksinny requested tags, looking for the ticket
16:34:31 <ajeddeloh> #chair jlebon
16:34:31 <zodbot> Current chairs: ajeddeloh bgilbert dustymabe jbrooks jlebon kaeso miabbott mnguyen_ rfairley slowrie
16:35:26 <jlebon> #link https://pagure.io/releng/issue/8294
16:35:36 <geoff-> geoff-: Geoff Levand <geoff@infradead.org>
16:35:51 <bgilbert> #info ksinny requested pool tags
16:35:57 <ajeddeloh> cool
16:36:20 <ajeddeloh> That was our only action item from last time
16:37:08 <ajeddeloh> #topic CT for FCOS
16:37:18 <ajeddeloh> #link https://github.com/coreos/fedora-coreos-tracker/issues/129
16:37:26 <ajeddeloh> #link https://github.com/coreos/fedora-coreos-tracker/issues/89
16:38:39 <ajeddeloh> So we want to have CT for fcos. Container Linux had the Container Linux Config Transpiler (CLCT or CT), but its spec was unversioned.
16:38:58 <ajeddeloh> This was problematic since we had no way to break compatibility
16:39:23 <ajeddeloh> I've written up a proposal for how to version the FCOS CT spec here
16:39:31 <ajeddeloh> #link https://github.com/coreos/fedora-coreos-tracker/issues/89#issuecomment-485966453
16:39:47 <ajeddeloh> does anyone have thoughts on that?
16:40:47 <yzhang> just curious, why not couple versions more tightly
16:40:59 <bgilbert> yzhang: example?
16:41:05 <yzhang> e.g. something like "ct v2.0.0 is released with spec v1.1.0 targeting Ignition spec v3.0.0" seems very confusing
16:41:27 <yzhang> why not e.g. have major versions match ignition...?
16:41:46 <bgilbert> AIUI the CT and Ignition semver is semver'd according to Go API compatibility
16:41:53 <slowrie> Major version bumps are typically for backward-compat breaking changes
16:41:54 <ajeddeloh> yzhang: we can't add sugar without an Ignition spec bump then
16:42:42 <ajeddeloh> i.e. if ct spec X matches ignition spec X, we can't add things that aren't in the Ignition spec without waiting for an Ignition spec bump
16:42:43 <yzhang> mm ok
16:43:05 <ajeddeloh> I think this is something we ought to document
16:43:26 <ajeddeloh> and have a table of what spec version emits what ignition spec version
16:43:29 <yzhang> itd be nice to have a matching table or something
16:43:29 <yzhang> yeah
16:44:02 <ajeddeloh> #chair yzhang
16:44:02 <zodbot> Current chairs: ajeddeloh bgilbert dustymabe jbrooks jlebon kaeso miabbott mnguyen_ rfairley slowrie yzhang
16:44:34 <yzhang> eh im more that one heckler standing out in the hallway
16:44:41 <ajeddeloh> this also has the advantage of not needing to translate between ct spec versions in ct (like Ignition does)
16:44:47 <bgilbert> yzhang: please heckle.  feedback is good :-)
16:44:58 <ajeddeloh> do we have a #standing?
16:45:13 <bgilbert> ?
16:45:15 <yzhang> sure, I see where the need is to have all the versioning differences
16:45:18 <ajeddeloh> as opposed to #chair
16:45:31 <bgilbert> #halp
16:45:38 <bgilbert> okay fine
16:45:39 <yzhang> just that for the short time we had ignition spec 3 (v2) in RHCOS
16:45:39 <bgilbert> #help
16:45:45 <yzhang> everyone was confused
16:45:49 <yzhang> as to the naming
16:45:52 <bgilbert> huh
16:46:08 <kaeso> two more ct-related questions:
16:46:22 <bgilbert> ajeddeloh: I think the proposal a good compromise between back-compat and maintainability.  we can always add the translation later if we need it
16:46:25 <kaeso> 1) is the new ct a library too, or only a binary?
16:46:30 <ajeddeloh> yeah, that was probably especially confusing since v2 has spec v3, but v0 had spec v2.x and v1 didn't exist
16:46:49 <ajeddeloh> kaeso: I want to make it a library
16:46:56 <kaeso> 2) does the ct-spec versioning also covers OS-flavors, or is that out of scope?
16:47:08 <kaeso> *cover
16:47:09 <ajeddeloh> and structure it s.t. other distos can import the Ignition bits without the FCOS bits
16:47:24 <bgilbert> yzhang: yeah, several of us started referring to it as Ignition "v2s3" to avoid confusion.  I think in practice people won't actually talk about the Ignition version much, after v2 finishes landing.
16:48:05 <yzhang> yeah, just trying to heckle for a less-confusing versioning scheme ;) but you guys probably would have done it if it were possible
16:48:09 <slowrie> ajeddeloh: For other distros that are importing the spec and adding their own sugar how would they handle versioning their CT?
16:48:10 <ajeddeloh> kaeso: There's another question there which is "do we want to maintain other distro's ct's or just give them the libraries to do it themselveS"
16:48:49 <ajeddeloh> slowrie: if we're not maintaining their CTs the best we could do is encourage them to follow our lead
16:49:04 <ajeddeloh> if we maintain their ct's then we can enforce it
16:49:13 <ajeddeloh> but idk if that's a burden we want to take on
16:49:39 <slowrie> I guess the library parsing wouldn't have anything directly referencing the CT version and that'd be left up to the binary code?
16:50:19 <ajeddeloh> yeah, my thought was to keep each CT spec as its own package
16:50:41 <ajeddeloh> and the ignition bits and the fcos bits as subpackages
16:50:49 <ajeddeloh> then use struct embedding to join them
16:51:24 <ajeddeloh> this would allow third parties to use just the ignition bits of each CT spec they want
16:51:46 <kaeso> I think that makes sense, I guess I was more wondering about how to tag the top-level type
16:52:26 <ajeddeloh> If no one is opposed to this, I'll take an action item to figure out how to do this cleanly in go
16:52:45 <bgilbert> +1
16:53:43 <ajeddeloh> #action ajeddeloh to figure out how to make ct consumable as a library with the proposed versioning
16:54:05 <ajeddeloh> anything else on this topic before we move on?
16:55:24 <ajeddeloh> #topic Open Floor
16:56:03 <kaeso> I have two short heads-up
16:56:18 <ajeddeloh> looks like kaeso started work on airlock: https://github.com/coreos/airlock/pulls
16:56:22 <ajeddeloh> #link https://github.com/coreos/airlock/pulls
16:56:37 <ajeddeloh> #info kaeso started work on airlock
16:56:46 <dustymabe> kaeso++
16:56:59 <kaeso> yup, eyeballs and coding-hands appreciated
16:57:34 <kaeso> it should be also a good/small projects for Go newcomers
16:58:23 <kaeso> and the second one is
16:58:32 <kaeso> #link https://github.com/coreos/fedora-coreos-tracker/issues/83#issuecomment-485896626
16:58:50 <kaeso> cincinnati-client, looking for names suggestions
16:59:23 <yzhang> I vote... cincinnati-client
16:59:36 <kaeso> slowrie, what is `lcm` in the context above?
16:59:55 <slowrie> kaeso: lunar command module :)
17:00:14 <jlebon> kaeso++ awesome
17:00:14 <zodbot> jlebon: Karma for lucab changed to 4 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:00:43 <kaeso> yzhang, probably fina as a name if we split out a protocol-client, the application-binary would benefit from something shorter and less specific
17:00:57 <bgilbert> lunar... command module.
17:01:14 <kaeso> *fine
17:01:23 <ajeddeloh> I think I'm ok with cincianatti-client since this project is much more tightly scoped than say "coreos-metadata"
17:01:40 <bgilbert> ajeddeloh: I'd tend to agree
17:01:54 <kaeso> it is an rpm-ostree client too, and an airlock-client also :)
17:02:04 <bgilbert> \*-client
17:02:22 <yzhang> cin-air-rpo-client
17:02:22 <slowrie> I originally was going to suggest vizier but google already has a project w/ that name
17:02:30 <yzhang> cinaripo
17:02:36 <slowrie> caro
17:02:57 <yzhang> caroc
17:02:57 <ajeddeloh> isn't that spanish for "face"
17:03:18 <slowrie> vizier was a high official in the Ottoman empire
17:03:25 <ajeddeloh> caro is also a city in michigan
17:03:31 <yzhang> caro is italian for "beloved"
17:03:36 <yzhang> according to google translate
17:03:57 <slowrie> Cincinatti Airlock Rpm-Ostree
17:03:58 <dustymabe> . #bikeshed
17:04:00 <dustymabe> :)
17:04:06 <kaeso> yzhang, correct, most common for "expensive" though
17:04:27 <yzhang> sorry for derailing :>
17:04:37 <jlebon> slowrie: SHIPIT
17:05:12 <kaeso> I'll leave this soaking, and wrap up something before the end of the week
17:05:33 <kaeso> do we need a name for ct too?
17:05:34 <ajeddeloh> since it joins three things, maybe a city at the border of three states or countries?
17:05:55 <ajeddeloh> oh yeah, we do
17:06:20 <ajeddeloh> I think FCC and FCCT were floated
17:06:59 <slowrie> Those are still my preferred names
17:07:10 <bgilbert> they're sort of the default names IMO
17:07:18 <ajeddeloh> #action kaeso to pick a name for zincinnati
17:07:26 <bgilbert> we've gotten used to the "CT" name but it's not actually great
17:07:32 <ajeddeloh> I think I'd prefer FCCL and FCCT
17:07:48 <bgilbert> OTOH we've picked several arbitrary names recently.  seems like a lot of... names.
17:07:49 <ajeddeloh> (FCOS Config Langauge)
17:07:56 <jlebon> hmm, kinda don't like FCC since it already stands for something relatively well-known
17:08:27 <ajeddeloh> We can still refer to FCCT as CT like we do with CLCT
17:10:26 <ajeddeloh> anyone have strong opinions on FCC vs FCCT?
17:10:43 <bgilbert> vs FCCL, you mean?
17:11:03 <ajeddeloh> err yeah
17:11:57 * jbrooks thinks about pronouncing FCCL
17:12:06 * bgilbert was thinking about the same thing
17:12:20 <bgilbert> FCCT has a similar thing going on
17:12:21 <slowrie> my best guess on pronunciation is fickle
17:12:30 <jbrooks> might not pass the smell test
17:12:36 <jbrooks> hehr
17:13:13 <bgilbert> FCC and FCCL are actually different things, anyway
17:13:25 <bgilbert> FCCL is the language, FCC is an instance of it
17:13:47 <slowrie> Aren't they both meant as names for the yaml configs accepted by FCCT?
17:14:08 <bgilbert> it's currently hard to express "CLC language" without a separate term
17:14:32 <bgilbert> slowrie: users write CLCs.  what's the language they write them in?
17:14:59 <slowrie> bgilbert: yaml?
17:15:06 <bgilbert> ...yeah
17:15:17 <slowrie> In the end it's just a defined yaml structure
17:15:34 <bgilbert> still hard to talk about though
17:15:36 <ajeddeloh> we could call it "spec" instead of "language"
17:15:43 <ajeddeloh> but then thats FCCS
17:15:47 <slowrie> I'd be worried about adding too many acronyms
17:15:56 <ajeddeloh> which also suffers from the smell test problem
17:16:09 <bgilbert> right, there's a theme developing
17:16:40 <ajeddeloh> Lets churn on this more
17:16:52 <ajeddeloh> I'll see about picking something by next week
17:17:06 <ajeddeloh> we can add more ideas as we have them to https://github.com/coreos/fedora-coreos-tracker/issues/129
17:17:36 <ajeddeloh> #action ajeddeloh to pick names for FCCT FCCL and FCC
17:19:40 <ajeddeloh> on a different note, I checked up on where we are on removing python and we're making good progress: https://github.com/coreos/fedora-coreos-tracker/issues/92
17:20:42 <bgilbert> nice work, all!
17:21:17 <dustymabe> woot woot!
17:21:36 <dustymabe> sorry I've been a bit away this meeting - the releng meeting has a lot of discussion about koji tags that I've been paying attention to
17:21:36 <ajeddeloh> the SELinux ones are still the hard bits
17:23:17 <ajeddeloh> #info we only have xfsprogs, setools-console and policycoreutils-python left for removing python
17:23:39 <ajeddeloh> anyone have anything else for open floor?
17:25:20 <kaeso> aren't the selinux outcomes basically "just drop them from treefile"?
17:26:45 <ksinny_> kaeso: yeah
17:27:03 <kaeso> yay
17:27:26 <ajeddeloh> cool
17:27:27 <ksinny_> few items are pending because one of maintainer is not respeonding on PR
17:27:37 <ajeddeloh> ksinny_: that's just xfsprogs, yes?
17:27:46 <ksinny_> and I need to test few utility in container to make sure it works
17:28:36 <ksinny_> ajeddeloh: don't recall the package name, but correpsonding ticket should have updated content
17:29:04 <ajeddeloh> I think it is then
17:29:23 <ajeddeloh> Anything else before we close out the meeting?
17:29:42 <rfairley> one update: making progress on this https://github.com/coreos/fedora-coreos-tracker/issues/4 - hopefully have a package review out later this or next week (will get some eyes on the specfile first). current WIP at https://github.com/rfairley/rust-afterburn, but that location will change once a repo in Fedora SCM is set up
17:29:43 <ksinny_> yeah, right https://src.fedoraproject.org/rpms/xfsprogs/pull-request/1
17:30:18 <rfairley> we had been trying to package the rust dependencies in Fedora and are close on that (which Sayan was working on)
17:30:42 <rfairley> but will use the vendored deps for now, just so we can get the package up and in FCOS
17:30:55 <dustymabe> rfairley++
17:31:04 <jlebon> rfairley: awesome!
17:31:06 <ajeddeloh> rfairley++
17:31:06 <zodbot> ajeddeloh: Karma for rfairley changed to 6 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:31:33 <ajeddeloh> #info rfairley is making good progress on packaging afterburn
17:31:45 <bgilbert> rfairley++
17:31:46 <zodbot> bgilbert: Karma for rfairley changed to 7 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:32:13 <kaeso> rfairley, I'm somehow skeptical on using rpm dependencies for crates. but well
17:32:28 <ajeddeloh> Any last minute things before we close?
17:32:50 <kaeso> rfairley, I've started noting down digest for both crate and vendor tarball, let me know if that works fine
17:33:22 <rfairley> Right, yeah it does mean the crates are managed elsewhere - can that cause a mismatch in the versioning?
17:33:45 <rfairley> kaeso: thanks, will try those!
17:34:13 <rfairley> Noticed it was noted in the last release
17:34:19 <kaeso> rfairley, it can, but within semver ranges that should be fine
17:34:43 <rfairley> kaeso: +1
17:35:12 <kaeso> rfairley, it's more about trying to align the whole ecosystem on a single crate version, which could be a neverending effort
17:35:32 <ajeddeloh> We're a bit over time, lets continue this discussion in #fedora-coreos?
17:35:38 <kaeso> ack
17:35:48 <ajeddeloh> #endmeeting