16:31:31 <dustymabe> #startmeeting fedora_coreos_meeting
16:31:31 <zodbot> Meeting started Wed Feb 20 16:31:31 2019 UTC.
16:31:31 <zodbot> This meeting is logged and archived in a public location.
16:31:31 <zodbot> The chair is dustymabe. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:31:31 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:31:31 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:31:37 <dustymabe> #topic roll call
16:31:41 <jbrooks> .fas jasonbrooks
16:31:42 <dustymabe> .hello2
16:31:42 <zodbot> jbrooks: jasonbrooks 'Jason Brooks' <jbrooks@redhat.com>
16:31:42 <lorbus> oh :P
16:31:45 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:31:46 <ajeddeloh> .hello2
16:31:46 <lorbus> .hello2
16:31:47 <ksinny> .hello sinnykumari
16:31:48 <strigazi> .hello2
16:31:48 <rfairley> .hello2
16:31:50 <bgilbert> .hello2
16:31:51 <zodbot> ajeddeloh: ajeddeloh 'Andrew Jeddeloh' <andrew.jeddeloh@redhat.com>
16:31:53 <kaeso> .hello lucab
16:31:54 <zodbot> lorbus: lorbus 'Christian Glombek' <cglombek@redhat.com>
16:31:57 <slowrie> .hello2
16:31:57 <zodbot> ksinny: sinnykumari 'Sinny Kumari' <ksinny@gmail.com>
16:32:00 <zodbot> strigazi: strigazi 'Spyros Trigazis' <strigazi@gmail.com>
16:32:02 <dustymabe> DDOS zodbot
16:32:03 <zodbot> rfairley: rfairley 'None' <rfairley@redhat.com>
16:32:06 <zodbot> bgilbert: bgilbert 'Benjamin Gilbert' <bgilbert@backtick.net>
16:32:09 <zodbot> kaeso: lucab 'Luca Bruno' <lucab@redhat.com>
16:32:12 <zodbot> slowrie: slowrie 'Stephen Lowrie' <slowrie@redhat.com>
16:32:14 <miabbott> .hello miabbott
16:32:15 <zodbot> miabbott: miabbott 'Micah Abbott' <miabbott@redhat.com>
16:32:42 <yzhang> .hello2
16:32:43 <zodbot> yzhang: yzhang 'Yu Qi Zhang' <jzehrarnyg@gmail.com>
16:33:46 <jlebon> .hello2
16:33:46 <sayan> .hello sayanchowdhury
16:33:46 <zodbot> jlebon: jlebon 'None' <jonathan@jlebon.com>
16:33:49 <zodbot> sayan: sayanchowdhury 'Sayan Chowdhury' <sayan.chowdhury2012@gmail.com>
16:34:02 <dustymabe> #chair jbrooks lorbus ajeddeloh ksinny strigazi rfairley bgilbert kaeso slowrie miabbott yzhang sayan
16:34:02 <zodbot> Current chairs: ajeddeloh bgilbert dustymabe jbrooks kaeso ksinny lorbus miabbott rfairley sayan slowrie strigazi yzhang
16:34:07 <dustymabe> nice crowd today :)
16:34:49 <dustymabe> #topic Action items from last meeting
16:34:52 <dustymabe> * dustymabe to update ticket #122 with results where we are going to try
16:34:55 <dustymabe> to exclude setools-console package and see where we land
16:35:33 <dustymabe> #info dustymabe updated #122 with results of discussion from last meeting
16:35:44 <dustymabe> sinny has agreed to explore kaeso request
16:35:50 <dustymabe> thanks sinny
16:35:59 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/122#issuecomment-463298821
16:37:11 <ksinny> yeah, I haven't get time to do that yet. Planning to do it soon
16:38:27 <dustymabe> ok here is the agenda for today: https://public.etherpad-mozilla.org/p/20190220-FCOS-Meeting
16:38:37 <dustymabe> add topics in there for open floor items
16:38:45 <sanja> .hello2
16:38:46 <zodbot> sanja: sanja 'Sanja Bonic' <sanja@redhat.com>
16:38:53 <dustymabe> welcome sanja
16:38:57 <dustymabe> #chair sanja
16:38:57 <zodbot> Current chairs: ajeddeloh bgilbert dustymabe jbrooks kaeso ksinny lorbus miabbott rfairley sanja sayan slowrie strigazi yzhang
16:39:08 <dustymabe> #topic Keep/Remove Python dependent package: authconfig
16:39:21 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/123
16:39:30 <kaeso> agenda is: python <3
16:39:32 <sanja> the car I'm currently driving which isn't mine broke down and I was at the garage today - guess what the problem was...drumroll..ignition
16:40:11 <dustymabe> sanja: nice
16:40:15 <ajeddeloh> sanja hahahahaha
16:40:20 <lorbus> sanja++ xD
16:40:20 <zodbot> lorbus: Karma for sanja changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:40:23 <dustymabe> ksinny: I think this topic was you
16:40:25 <sanja> I thought it's rather hilarious
16:40:42 <ajeddeloh> when I go look up the ignition spec I always have to ad "coreos" or else I hit "Ignition coil specificiations"
16:40:52 <sanja> :D
16:41:07 <ksinny> authconfig tool is written in Python, so if we want tio use it we will need Python
16:41:47 <ksinny> There was an alternative suggested by lorbus which is to use authselect but that also requires at some point authselect-compat
16:41:55 <ksinny> which also needs Python
16:42:22 <bgilbert> these are interactive tools?  do we need them?
16:42:29 <mnguyen_> .hello mnguyen
16:42:30 <zodbot> mnguyen_: mnguyen 'Michael Nguyen' <mnguyen@redhat.com>
16:42:37 <ksinny> also authselect provides a script /usr/lib/rpm/python-macro-helper which needs python
16:42:50 <lorbus> ksinny: yeah I think rpm-ostree isn't ready for authselect either
16:42:52 <dustymabe> #chair mnguyen_
16:42:52 <zodbot> Current chairs: ajeddeloh bgilbert dustymabe jbrooks kaeso ksinny lorbus miabbott mnguyen_ rfairley sanja sayan slowrie strigazi yzhang
16:42:53 <ajeddeloh> bgilbert: that was my question as well
16:42:56 <ksinny> so, in the end there are lots of python involved in both cases
16:43:06 <dustymabe> is authconfig interactive ?
16:43:25 <dustymabe> i always have just run it as a single command or as part of a script
16:43:40 <dustymabe> is jlebon around today?
16:43:50 <ajeddeloh> the other question: is authconfig doing things that should be done by just editing the config files for the parts it interacts with
16:43:58 <ksinny> bgilbert: did CL users used authconif/authselect it?
16:44:01 <jlebon> dustymabe: here, but was distracted :)
16:44:08 <ajeddeloh> I don't think CL shipped it
16:44:15 <bgilbert> ksinny: nope
16:44:29 <dustymabe> jlebon: we're discussing authselect/authconfig
16:44:47 <jlebon> ahhh yes
16:45:03 <jlebon> in theory, we could move to authselect once we move to systemd-sysusers
16:45:16 <ajeddeloh> do we need it at all though
16:45:39 <ksinny> jlebon: even authselect has some dependency on Python like /usr/lib/rpm/python-macro-helper script which authselect provides
16:45:42 <jlebon> that's a good question :)
16:46:00 <ajeddeloh> we're explicitly including it in the treefile so I
16:46:04 <dustymabe> ksinny: /usr/lib/rpm/python-macro-helper looks like something we could easily get rid of maybe
16:46:14 <ajeddeloh> 'm guessing that its not a dep of other packages
16:46:29 <ksinny> dustymabe: yeah but only if maintainers agree
16:46:54 <jlebon> AIUI, authselect just sets some configurations based on profiles, so we could get rid of it
16:47:14 <ajeddeloh> It looks like it also reads from a config file in /etc/sysconfig to do it
16:47:15 <jlebon> it basically has this concept of profiles to make switching between configsets easier
16:47:53 <bgilbert> well, it's easier to add later than to remove later, right?
16:48:02 <bgilbert> and presumably we'd rather have users write configs directly via Ignition
16:48:22 <jlebon> yeah, that's what i was going to suggest. we can start without, and if the profile stuff is appealing, we can reconsider/discuss with upstream
16:49:22 <ksinny> +1
16:49:23 <ajeddeloh> adding later++
16:49:24 <dustymabe> yeah so here's one thing I'd like to get more input on
16:50:01 <dustymabe> i'm cool with ripping it out but I think we should try to talk to more people to get input on if it's used and where so that we can plan for the implications
16:50:14 <dustymabe> i.e. authconfig (if we can move to authselect yet) requires python
16:50:27 <bgilbert> dustymabe: if it's used by other packages, you mean?
16:50:56 <dustymabe> bgilbert: or perhaps for configuration, which I know is a bit of an anti-pattern for FCOS
16:51:04 <bgilbert> we don't have users yet :-)
16:51:29 <ajeddeloh> I don't like what authconfig does on principle (for fcos that is)
16:51:44 <dustymabe> bgilbert: but we do have users of AH - would like to at least get some more feedbck
16:51:48 <ajeddeloh> from what I understand /etc/sysconfig/* is a redhattism
16:52:32 <bgilbert> dustymabe: fair
16:52:43 <dm0> Would removing authconfig be blocked on removing Anaconda from coreos-assembler?  Last I recall, it was one of those annoying packages like firewalld where pykickstart won't work without it being installed on the target file system.  (I haven't looked into the implementation details, so maybe it's a nonissue here.)
16:53:10 <ajeddeloh> one of the things that made CL great imo is that it was pretty much just upstream bits, users were expected to configure each bit
16:53:12 <dustymabe> #proposed we will try to go without authconfig/authselect and also try to raise the awareness of this move to get feedback from potential users
16:53:21 <dustymabe> ack/nack
16:53:25 <ajeddeloh> ack
16:53:26 <jlebon> dm0: good point, that's possible. will have to check the anaconda logic there
16:53:34 <jlebon> ack
16:53:35 <slowrie> ack
16:53:37 <bgilbert> ack
16:53:49 <ksinny> ack
16:53:52 <dustymabe> dm0: hopefully we'll be out of anaconda soon so that won't be an issue
16:53:53 <bgilbert> ajeddeloh: +1
16:54:01 <dustymabe> but dm0++ for bringing that up
16:54:01 <zodbot> dustymabe: Karma for dm0 changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:54:06 <ksinny> we can get user's feedback when FCOS preview is there and then we will know if users compain about it and act accordingly?
16:54:24 <ksinny> s/compain/complain/
16:54:53 <dustymabe> #agreed we will try to go without authconfig/authselect and also try to raise the awareness of this move to get feedback from potential users #123
16:55:10 <dustymabe> #topic Keep/Remove Python dependent package: policycoreutils-python
16:55:17 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/126
16:56:10 <dustymabe> so we have several binaries provided by policycoreutils-python-utils
16:56:18 <dustymabe> of those I think the biggest one is `semanage`
16:57:02 <dustymabe> any thoughts here?
16:57:21 <ajeddeloh> we don't know if that behaves in a container, correct?
16:57:27 <ksinny> we need selinux expert here :)
16:57:56 <dustymabe> we can try to ask for feedback from dan walsh in the ticket
16:58:17 <ksinny> +1
16:58:17 <dustymabe> other than that, anyone have any comments?
16:58:33 <jlebon> semanage is used for a bunch of stuff, including file contexts, and sebools
16:58:50 <dustymabe> yeah and file context equivalencies
16:59:04 <ksinny> This is the trickiest package, if we can get workaround for this, we will be closer to no Python in FCOS
16:59:31 <jlebon> would be interesting to see if it could run in a container, though it'd require mounting the host's /etc too
16:59:50 <emv_> hello late, in and out! looking forward to seeing the transcript
16:59:53 <dustymabe> #info will ask dan walsh for feedback on feasibility of shipping without `semanage` in FCOS #126
17:00:02 <kaeso> do sebools have multiple managers? I seem to recall one which is run by post-insts scripts
17:00:04 <dustymabe> welcome emv_
17:00:15 <emv_> this is ed@packet for reference
17:00:19 <dustymabe> kaeso: there is `setsebool`
17:00:30 <jlebon> yeah, it's kinda confusing
17:00:31 * bgilbert waves at emv_
17:00:49 <dustymabe> emv_: if you have any topics for open floor you can add them to https://public.etherpad-mozilla.org/p/20190220-FCOS-Meeting
17:01:03 <jlebon> i think `semanage` was meant to be the higher level tool users interact with?
17:01:08 <dustymabe> this is for anyone else too ^^ jcajka
17:01:20 <kaeso> just wondering (like last time) if we will get this package back via dependencies
17:01:55 <ksinny> kaeso: don't think so
17:02:02 <miabbott> dustymabe: `semanage` is pretty useful...we just had that PR to tweak the booleans in RHCOS
17:02:27 <dustymabe> yeah so I think that leads us into the next ticket
17:02:38 <dustymabe> #topic Short term Python: Restrict Python to only execute OSTree provided files
17:02:41 <miabbott> i've seen its usage pop up in the context of RHELAH users, too
17:02:48 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/152
17:03:02 <dustymabe> just created this ticket before the meeting
17:03:30 <jcajka> dustymabe: just lurking atm, on other meeting, otherwise swamped with forward porting the hacks for assembler
17:03:50 <bgilbert> I'm +1 to working on restricting Python in parallel with removing it
17:03:52 <dustymabe> basically in one of our other tickets colin had the idea of (in the short term) making python only execute scripts provided by us
17:04:07 <ajeddeloh> same +1 as a stopgap
17:04:24 <jlebon> miabbott: though we could've used setsebool for that too
17:04:37 <kaeso> dustymabe: does that mean forking and maintaining our own python packages? 2 / 3?
17:04:41 <dustymabe> jlebon, not in that case we couldn't because of the upstream bug
17:04:53 <jlebon> ahh gotcha
17:04:56 <ajeddeloh> short term it prevents the expectation of python, long term it's either work that needs to be done (if we fail at removing python) or will go away when we remove python
17:05:01 <dustymabe> kaeso: i'm not sure what it would mean exactly - we'd need to investigate
17:05:14 * sanja has to go unfortunately, kid stuff.
17:05:28 <lorbus> bye sanja!
17:05:31 <dustymabe> kaeso: i think there are a few ways we could pull it off and we should discuss possible implementation details in that ticket
17:05:31 <miabbott> jlebon: setsebool covers booleans, but what about file contexts etc
17:05:32 * bgilbert waves at sanja
17:05:59 <dustymabe> so I created the ticket to foster discussion and also talk about how we would do it
17:06:04 <jlebon> miabbott: one can write to /etc for those :)
17:06:13 <miabbott> jlebon: fair
17:06:16 <jlebon> miabbott: not arguing it's more foolproof/convenient with a cmdline tool though
17:07:17 <dustymabe> anyone opposed to trying this out?
17:08:39 <kaeso> I'm not opposed in principle, just worried that it could be another case where POCing is the easy part, but the hidden cost is in maintenance
17:09:01 <dustymabe> kaeso: agree. so we have incentive to not get rid of pythong and not maintain it forever :)
17:09:30 <bgilbert> kaeso: ongoing friction around maintaining Python sgtm :-)
17:09:31 <bgilbert> yes
17:09:59 <dustymabe> #proposed We are willing to try a 'restricted python' approach while we burndown python dependencies in parallel which could take a while #152
17:10:01 <dustymabe> ack/nack
17:10:08 <bgilbert> s/which could take a while//?
17:10:22 <bgilbert> no need to set timeframe expectations here
17:10:37 <dustymabe> #proposed We are willing to try a 'restricted python' approach while we burndown python dependencies in parallel
17:10:58 <slowrie> ack
17:11:03 <mnguyen_> ack
17:11:16 <ksinny> neutral
17:11:20 <ajeddeloh> ack
17:11:22 <bgilbert> ack
17:11:39 <miabbott> ack
17:12:00 <dustymabe> #agreed We are willing to try a 'restricted python' approach while we burndown python dependencies in parallel
17:12:24 * dustymabe looks at agenda
17:12:57 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/152
17:13:04 <dustymabe> #link https://github.com/orgs/coreos/projects/83
17:13:09 <dustymabe> #link https://github.com/orgs/coreos/projects/83
17:13:12 <dustymabe> #unfo
17:13:15 <dustymabe> #undo
17:13:15 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x7fc464bea510>
17:13:29 <dustymabe> sign
17:13:36 <dustymabe> #fail
17:13:38 <bgilbert> #link https://github.com/orgs/coreos/projects/82
17:13:39 <bgilbert> #link https://github.com/orgs/coreos/projects/84
17:13:59 <dustymabe> copy and paste from etherpad is acting up for me
17:14:01 <dustymabe> weird
17:14:07 <dustymabe> thanks bgilbert :)
17:14:19 <bgilbert> we've put together some project boards for tracking progress toward Fedora CoreOS preview and stable releases
17:14:32 <bgilbert> and a third one for "papercuts" - small things that need fixing
17:14:54 <bgilbert> the latter is a mix of preview release and post-preview release
17:15:00 <bgilbert> mostly to keep small things off the main boards.
17:15:17 <bgilbert> these will perpetually be a WIP, and probably a bit approximate
17:15:23 <dustymabe> thanks bgilbert I think I'll update ROADMAP.md to point to these boards that get dynamically updated
17:15:27 <bgilbert> dustymabe: +1
17:15:42 <kaeso> bgilbert: what's the `==== Major ====` note?
17:16:00 <bgilbert> but the idea is to have a public place with live tracking of all the large and small bits we'll need.
17:16:13 <bgilbert> kaeso: those are just dividers.  there's a `==== Minor ====` further down.
17:16:14 <kaeso> ah, a separator
17:16:22 <dustymabe> kaeso: yep
17:16:41 <kaeso> I hadn't scrolled that further
17:16:57 <bgilbert> for those who haven't used GH project boards before, they're nicely cross-linked from GH issues and PRs
17:17:19 <dustymabe> please all take a look at the boards and let us know what is missing or misplaced
17:17:39 <bgilbert> for folks with access to the github/coreos org, you should be able to add a project within the issue/PR and it'll automatically go into the Proposed column
17:17:56 <bgilbert> yes, please nominate things for the boards as needed!
17:18:02 <bgilbert> EOF
17:18:13 <strigazi> Will there be qcow2 images? i see issues in progress for iso and pxe
17:18:30 <dustymabe> strigazi: yep we actually already have qcow2 images
17:18:36 <dustymabe> for qemu anyway
17:19:07 <strigazi> there is an issue for that?
17:19:15 <dustymabe> https://ci.centos.org/artifacts/fedora-coreos/prod/builds/latest/
17:19:45 <dustymabe> strigazi: I don't think there is but I can fold it into https://github.com/coreos/fedora-coreos-tracker/issues/146
17:20:14 <dustymabe> #action dustymabe to create tickets for platform artifact creation
17:20:14 <strigazi> excellent, I'll give feedback there when I test
17:20:33 <bgilbert> artifact creation is already folded into the previous tracker issue
17:20:55 <dustymabe> bgilbert: do we have one for each platform we're targetting?
17:21:03 <bgilbert> #link https://github.com/coreos/fedora-coreos-tracker/issues/95
17:21:24 <bgilbert> nope, other than the "no cloud agents" tickets
17:21:37 <dustymabe> ahh yes looks like that ticket does have subcheckboxes for that
17:21:42 <dustymabe> i may break some of that out
17:21:46 <dustymabe> either way we'll cover it
17:22:10 <dustymabe> #topic open_floor: to what degree should we avoid "RedHat-isms"
17:22:26 <dustymabe> ajeddeloh: was this you?
17:22:30 <ajeddeloh> yeah
17:22:38 <ajeddeloh> I added this mid meeting when discussing authconfig
17:22:59 <ajeddeloh> I want to bring it up as something we should actively think about
17:23:38 <ajeddeloh> there's a lot of cases where fedora/rhel adds its own layer of abstraction on top of upstream projects (usually in the form of something in /etc/sysconfig)
17:24:06 <ajeddeloh> I personally don't think those really fit in FCOS, but I wanted to bring it up for broader discussion
17:24:09 <dustymabe> and why do you think fedora/rhel does that?
17:24:25 <ajeddeloh> it's exactly what authconfig is for example
17:24:38 <ajeddeloh> it came up with nfs-utils as well
17:25:09 <ajeddeloh> I'm not saying that abstraction is bad in the general sense, I'm saying I don't think it fits with what FCOS is
17:25:46 <dustymabe> There is a very fine line here
17:26:06 <dustymabe> abstraction/convenience are nice sometimes and get in the way other times
17:26:08 <jlebon> it's hard to give a blanket statement when maybe some of those abstractions are indeed really useful
17:26:53 <bgilbert> depends what the thing is, though.  nice TUIs, or even nice command-line tools, aren't necessarily great if they encourage users to SSH in and change things.
17:27:05 <jlebon> though i don't have examples offhand. i agree with the general sentiment of "let's be conscious of those and make sure it makes sense for FCOS, rather than mindlessly inheriting them"
17:27:21 <ajeddeloh> but do they fit in a minimal OS like fcos, especially since by definition the upstream isn't carrying them (obvious in some cases like authconfig htere isn't one upstream)
17:27:35 <bgilbert> if there's a systemd unit that translates a high-level config to a lower-level one, that might make sense if the abstraction levels are substantially different
17:27:49 <bgilbert> though in many cases CT is probably the right place to do that translation
17:27:51 <dustymabe> we'll probably have to take it on a case by case basis
17:28:21 <bgilbert> but ideally users won't be SSHing in at all, except for debugging.
17:28:24 <dustymabe> yeah bgilbert if someone wrote a systemd unit using ignition that calls authconfig to do all the work, is that an antipattern or not?
17:28:36 <ajeddeloh> but I'd like to flip the thinking of "lets include it unless we have a reason not to" to "lets exclude it unless we have a reason to"
17:28:44 <bgilbert> I'd say so.  we should be providing really good sugar in CT to do that work.
17:28:50 <bgilbert> dustymabe: ^
17:29:34 <dustymabe> bgilbert: that's pretty ambitious IMHO - especially for the short term
17:29:43 <dustymabe> but I don't disagree with you
17:29:50 <bgilbert> the systemd unit is kind of awkward and indirect, may race with things that read the config (unless the user is careful), and really only needs to run once
17:30:02 <bgilbert> dustymabe: it is, yeah.  CT will get better over time.
17:30:09 <dustymabe> we also have to consider who manages what and how much the FCOS group/community can take on
17:30:29 <bgilbert> from the CL perspective, of course, we'd tend to document Ignition config fragments that configure things, when CT sugar wasn't available
17:30:49 * dustymabe notes time
17:30:59 <dustymabe> ajeddeloh: agree to revisit on case by case basis?
17:31:11 <bgilbert> personally I'd tend to prefer having things be awkward at first, rather than taking on a compat constraint to ship a tool for multiple years.  we can always change our minds later.
17:31:24 <ajeddeloh> bgilbert++
17:31:32 <bgilbert> dustymabe: fwiw I think it'll always be case-by-case, just good to have some goals in mind
17:31:43 <dustymabe> fair
17:31:48 <dustymabe> and in general, I agree
17:31:51 <ajeddeloh> dustymabe: yeah, but again, I want to switch the thinking more to "default off" rather than "default on"
17:32:01 <dustymabe> #topic open_floor: iPXE OCSP bug https://github.com/ipxe/ipxe/pull/90 and impact on PXE testing
17:32:09 <dustymabe> emv_: ^^
17:32:32 <dustymabe> background?
17:32:56 <dustymabe> \o/
17:33:06 <ksinny> heh
17:33:06 <dustymabe> will give him 15 seconds to re-join
17:33:40 <ajeddeloh> haha
17:33:51 <dustymabe> #topic open_floor: [kaeso] multiarch: node arch-label introspection
17:33:57 <dustymabe> kaeso: \o/
17:34:36 <dustymabe> maybe we lost kaeso too
17:34:43 <kaeso> over time, do we maybe want to bring this to the tracker and to next meeting?
17:34:57 <jlebon> +1
17:35:10 <dustymabe> not sure what the problem is exactly, but +1 for a ticket if you want to discuss
17:35:25 <jcajka> kaeso: please cc me
17:35:58 <kaeso> tldr is: if we have multi-arch, node may need to introspect on their arch. This currently requires calling into librpm, while in CL it used to be part of os-release.
17:35:59 <dustymabe> kaeso: should we move on?
17:36:03 <kaeso> yep
17:36:16 <dustymabe> +1
17:36:30 <dustymabe> ajeddeloh: did we cover that final topic above?
17:36:45 <ajeddeloh> kind of
17:36:53 <kaeso> #action kaeso to create ticket for node arch-label introspection
17:37:04 <dustymabe> #topic open_floor: to what degree should we avoid configuration helpers (i.e. authconfig)
17:37:08 <ajeddeloh> they're seperable, since this covers non-redhat specific bits
17:37:48 <dustymabe> yeah - probably case-by-case on this as well
17:37:50 <ajeddeloh> but basically in general I'd like to avoid things that read one config and write another at runtime
17:38:16 <ajeddeloh> that goes against the whole "immutable os" idea (even if it's the os that doing the mututation)
17:38:37 <dustymabe> so ignition goes away :)
17:38:49 <dustymabe> ^ not serious
17:38:49 <ajeddeloh> haha, I meant in the real root, every boot
17:38:50 <bgilbert> Ignition runs before the OS starts :-)
17:38:59 <bgilbert> yeah, in the limit, this is coreos-cloudinit
17:39:03 <ajeddeloh> so coreos-metadata goes away :D
17:39:07 <ajeddeloh> (I kid)
17:39:49 <dustymabe> I'd say it's good as a general approach but case-by-case
17:40:10 <ksinny> +1
17:40:11 <jlebon> yeah, that sounds reasonable +1
17:40:22 <bgilbert> +1 to case-by-case, hopefully with a pretty high bar
17:40:31 <ajeddeloh> +1 to high bars
17:41:01 <dustymabe> ajeddeloh: want to open some tickets (for awareness) and design doc PRs to record this?
17:41:07 <bgilbert> (to be clear, case-by-case with the general principle behind it)
17:41:10 <ajeddeloh> dustymabe: sure
17:41:34 <dustymabe> #action ajeddeloh to open a few tickets and design doc PRs for discussed open floor topics on philosophy
17:41:39 <dustymabe> #topic open floor
17:41:45 <dustymabe> ok one #info from sanja
17:42:07 <dustymabe> #info the submissions for china kubecon and cloudnative are deadlining on february 22nd so please submit!
17:42:20 <dustymabe> so whoever wants to go to china and give a talk - submit submit submit
17:42:40 <dustymabe> will close out meeting in 30 seconds unless we have more discussion/topics
17:43:11 <dustymabe> #endmeeting