16:31:51 <dustymabe> #startmeeting fedora_coreos_meeting
16:31:51 <zodbot> Meeting started Wed Oct 28 16:31:51 2020 UTC.
16:31:51 <zodbot> This meeting is logged and archived in a public location.
16:31:51 <zodbot> The chair is dustymabe. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:31:51 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:31:51 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:31:55 <dustymabe> #topic roll call
16:31:58 <dustymabe> .hello2
16:31:59 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:32:01 <red_beard> .hello redbeard
16:32:02 <cyberpear> .hello2
16:32:02 <zodbot> red_beard: redbeard 'Brian 'redbeard' Harrington' <bharring@redhat.com>
16:32:03 <bgilbert> .hello2
16:32:05 <zodbot> cyberpear: cyberpear 'James Cassell' <fedoraproject@cyberpear.com>
16:32:08 <skunkerk> .hello sohank2602
16:32:08 <zodbot> bgilbert: bgilbert 'Benjamin Gilbert' <bgilbert@backtick.net>
16:32:11 <zodbot> skunkerk: sohank2602 'Sohan Kunkerkar' <skunkerk@redhat.com>
16:33:29 <jlebon> .hello2
16:33:30 <zodbot> jlebon: jlebon 'None' <jonathan@jlebon.com>
16:33:46 <dustymabe> #chair red_beard cyberpear bgilbert skunkerk jlebon
16:33:46 <zodbot> Current chairs: bgilbert cyberpear dustymabe jlebon red_beard skunkerk
16:35:10 <dustymabe> #topic Action items from last meeting
16:35:21 <dustymabe> Looks like we didn't carry forward any action items from last meeting
16:35:28 <dustymabe> 🎉
16:35:36 <dustymabe> we'll move right in to meeting topics
16:35:57 <dustymabe> #topic pam_sss.so configured by default
16:36:01 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/653
16:36:31 <davdunc> .hello2.
16:36:33 <davdunc> .hello2
16:36:34 <zodbot> davdunc: davdunc 'David Duncan' <davdunc@amazon.com>
16:36:43 <cyberpear> do we have fcct sugar for `authselect`?
16:36:46 <dustymabe> can anyone parse what's being asked here? I'm not as familiar as I should be with this stack
16:37:19 <red_beard> lemme look at something
16:37:35 <cyberpear> I think we should ship how the other flavors ship, which does have sssd running by default , and in the pam stack.
16:37:38 <dustymabe> cyberpear: I'm not aware of any fcct sugar for this
16:38:05 <dustymabe> #chair davdunc
16:38:05 <zodbot> Current chairs: bgilbert cyberpear davdunc dustymabe jlebon red_beard skunkerk
16:38:07 <cyberpear> (just verified my F33 Server install has it, and it was a bog-standard, all-defaults install)
16:38:28 <jlebon> so... we don't actually ship authselect in FCOS because of https://github.com/authselect/authselect/issues/48
16:39:02 <jlebon> well, clearly nothing pulls it in too so that's why we're not shipping it. but we also *can't* ship it even if we wanted to without some changes there first
16:39:16 <red_beard> well, and that authselect is just a helper
16:39:28 <cyberpear> SSSD-by-default was a Feature (Change?) a while back to allow in-memory caching of user account details
16:40:09 <cyberpear> we should probably default to using the configs that would be put in place by authselect, even w/o authselect itself
16:40:20 <cyberpear> modulo the nss-altfiles we might need
16:41:07 <dustymabe> Anyone want to explain to me what colin means with this statement? https://github.com/authselect/authselect/issues/48#issuecomment-399458362
16:41:14 <red_beard> so this gets us back to the meta question: is the goal of FCOS to provide a platform for folks to manually tweak singletons or to be administered en masse?
16:41:15 <dustymabe> "In the end, we need to do the sysusers switch."
16:41:45 <red_beard> dustymabe: probably something with the r/o partition
16:41:53 <jlebon> dustymabe: once we drop the dep on nss-altfiles, there's no blocker to use authselect
16:42:06 <red_beard> in container linux we had an extra entry in nss.conf which allowed for secondary paths to the databases
16:42:50 <jlebon> red_beard: i think we want both. single node and cluster node are both primary use cases :)
16:43:16 <bgilbert> jlebon: I think that's a different question
16:43:29 <bgilbert> single node is a primary use case, but we still want people to manage via Ignition and not cmdline
16:43:41 <jlebon> oh yeah, definitely
16:43:52 <dustymabe> bgilbert: correct, i.e. not optimizing for manually running commands
16:44:15 <dustymabe> we'd obviously like some fcct sugar if it's complex
16:44:18 <lucab> .hello2
16:44:19 <zodbot> lucab: lucab 'Luca Bruno' <lucab@redhat.com>
16:44:24 <dustymabe> welcome lucab :)
16:44:27 <dustymabe> #chair lucab
16:44:27 <zodbot> Current chairs: bgilbert cyberpear davdunc dustymabe jlebon lucab red_beard skunkerk
16:44:54 <dustymabe> so.. let me try to break down this issue
16:45:08 <dustymabe> 1. this user wants a configuration in place that isn't currently in place
16:45:38 <dustymabe> 2. authselect is a tool that puts configurations in place, but what we'd probably want is some sugar that put configurations in place as well
16:45:58 <dustymabe> 3. we can't pull in authselect until we drop nss-altfiles, (but do we even want to pull in authselect?)
16:46:57 <dustymabe> 4. cyberpear points out we're currently configured differently than other Fedora variants. We can differ from other Fedora variants, but we want differences to be calculated, so we should evaluate.
16:47:26 <dustymabe> does that reflect the current discussion up until this point?
16:47:44 <red_beard> close enough, i believe
16:47:59 <cyberpear> seems accurate to me; I don't know the specifics of 3) nss-altfiles conflict
16:48:18 <dustymabe> do we want to pick one of these numbered points and dig down deeper ?
16:48:19 <jlebon> it shouldn't be too hard to tweak authselect, the maintainers have shown willingness in the past IIRC
16:49:00 <jlebon> silverblue version of that issue: https://bugzilla.redhat.com/show_bug.cgi?id=1751417
16:49:15 <dustymabe> ok let's select #2 to drill down on then
16:49:20 <dustymabe> I'll ask a question
16:49:48 <dustymabe> jlebon: regarding "fcct sugar" for something like this.. do we envision the sugar calling into authselect in order to write out the configs ?
16:50:14 <red_beard> interfaces for the interfaces' interfaces?
16:50:16 * dustymabe notes he is talking about something he has not much knowledge of so please correct him when he's wrong
16:50:46 <bgilbert> we could have a firstboot unit that sets an authselect profile based on a config file written by Ignition
16:50:47 <dustymabe> red_beard: it gets icky, yeah
16:51:15 <jlebon> dustymabe: i'm not sure, the cleanest would probably require OS integration work to just call it before switchroot at all
16:51:55 * dustymabe thinks travier was going to work on the sysusers stuff, might be good to sync with him at some point
16:52:17 <bgilbert> does it need to run before other services start?
16:52:33 <bgilbert> if not, is there any need to run it before switchroot?
16:53:20 <red_beard> it _shouldn't_ since it's (when configured correctly) affecting administrative access
16:53:47 <red_beard> aka contents of the passwd and group databases doesn't change
16:54:00 <red_beard> only layering on additional sources of truth
16:54:17 <red_beard> so i should think it would be fine running late
16:54:34 <red_beard> e.g. last step before network.online
16:54:37 <red_beard> am i incorrect?
16:54:57 <lucab> I don't have a good understanding of authselect, but could we plug our default config as a profile there, and then steer systems via symlinks (via Ignition)?
16:55:14 <red_beard> i.e.  i don't need kerberos access before switchroot
16:55:37 <red_beard> i like luca's idea
16:55:44 <bgilbert> lucab: I guess it's still permissible for Ignition configs to directly write PAM configuration etc.
16:55:50 <bgilbert> which would conflict with that
16:56:29 <jlebon> red_beard: i *think* you're right, yeah. but we should ask an authselect maintainer if we go that route
16:56:34 <red_beard> well, the stated goal of authselect is: "Instead of letting the administrator build the PAM stack with a tool (which may potentially end up with a broken configuration), it would ship several tested stacks (profiles) that solve a use-case and are well tested and supported. "
16:56:57 <red_beard> so... it sounds more like selecting the correct set of configs
16:57:09 <jlebon> lucab: it's not just symlinks though AFAIK
16:57:09 <red_beard> which we would do _in_ ignition with FCCT surgar
16:57:15 <jlebon> it's more like rendering a template
16:57:33 <cyberpear> right, authselect is basically a couple jinja templates you pass options into (not actually jinja, but similar)
16:58:28 <jlebon> so the FCCT sugar could be for selecting a profile, and then options for additional features
16:59:17 <dustymabe> ok sounds like there is a lot of good discussion there. Maybe we could get a volunteer to create a new ticket with some of these details?
17:00:05 <dustymabe> i view the results of this discussion of point #2 as a medium term thing.. shorter term we should probably resolve point 1/4
17:00:37 <dustymabe> which is try to bring our systems more in line with the other variants. Is that something we can do without all of the work for point #2 ?
17:02:12 <dustymabe> 👀
17:02:25 <jlebon> one hack RHCOS once did (which we eventually dropped) was to actually ship authselect just so we could render the templates at compose time, and then deleted the binary :|
17:02:48 <jlebon> the advantage was that we didn't have to maintain a separate copy
17:03:47 <jlebon> not saying we should do that. we could probably start with just baking in the configs for now
17:04:03 <jlebon> and that would unblock the user
17:04:31 <jlebon> and once we get authselect+FCOS working, we can drop the baked-in configs and render them directly
17:04:45 <dustymabe> jlebon: do you mind putting your short term proposal in https://github.com/coreos/fedora-coreos-tracker/issues/653 ?
17:05:00 <dustymabe> and we can open a separate ticket for the medium term bits
17:05:17 <jlebon> yup sure
17:05:40 <dustymabe> #action jlebon to add short term proposal for unblocking user to the ticket https://github.com/coreos/fedora-coreos-tracker/issues/653
17:06:04 <dustymabe> anyone want to volunteer to open that medium term ticket with details? I would but I really feel a bit out of place on this topic
17:06:27 <dustymabe> the alternative is I open it and everyone tells me where I'm wrong :)
17:06:52 * dustymabe looks up next topic
17:07:38 <dustymabe> #action dustymabe to open ticket with design discussion about authselect support+fcct sugar in the future
17:07:40 <dustymabe> #topic next: default hostname now is `fedora`, used to be `localhost`
17:07:47 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/649
17:08:04 <dustymabe> This is one issue that's generating some buzz in the "f33" context
17:08:31 <dustymabe> since I'm trying to drive the f33 change and track potential reasons to block f33 from testing/stable I'd like to check in to see where we are
17:09:19 <dustymabe> lucab: it seems like one solution (maybe not preferred) is to use afterburn and also modify it slightly to handle truncating hostnames.
17:09:38 <lucab> I did open a BZ to see if there is a chance to revert the RPM change and retarget the branding effort at an higher level
17:10:14 <dustymabe> #link https://bugzilla.redhat.com/show_bug.cgi?id=1892235
17:10:55 <jlebon> lucab: can you or darkmuggle give a summary of what the high-level issue is?
17:11:30 <lucab> dustymabe: it can be done in Afterburn and it's possibly the quickest thing, but not the best outcome
17:13:09 <dustymabe> lucab: i share your sentiment
17:13:18 <lucab> jlebon: AFAIUI DHCP on GCP passes FQDN as hostnames, which can be longer than the kernel limit. Thus OKD bypasses that and performs some custom logic, which relies on detecting whether the hostname is unset (i.e. set to 'localhost')
17:14:34 <lucab> I already workaround this once in systemd-networkd at https://github.com/systemd/systemd/pull/7616, but I don't know why NM doesn't do that
17:15:08 <dustymabe> lucab: might be worth making a request to NM team to discuss ?
17:15:43 <lucab> dustymabe: yes, I asked darkmuggle whether there are some background refs/threads on that, but I think there aren't
17:15:52 <dustymabe> +1
17:16:06 <lucab> and I guess there is some relics of the time when initramfs didn't have NM
17:16:26 <dustymabe> ok maybe let's see what those discussions/requests come back with.
17:16:27 <lucab> so possibly it can be solved in a clean way now in NM
17:16:41 <dustymabe> for now whatever we do is probably going to be a hack
17:16:44 <dustymabe> :(
17:17:18 <lucab> the quickest hack is in MCO
17:17:44 <dustymabe> yeah, i think if the upstreams are willing to put in "better fixes" we should just hack MCO for now
17:17:52 <dustymabe> if not then afterburn is probably the best place
17:17:55 <lucab> the second-quickest hack is in Afterburn but I think it requires https://github.com/coreos/afterburn/issues/509 first
17:18:13 <dustymabe> lucab: correct
17:18:51 <dustymabe> lucab: do you agree with the preference of hacks based on upstream discussions with systemd/NM ?
17:19:14 <lucab> my 2 cents is that NM is in a good position to own this logic, and probably we never asked them
17:20:14 <dustymabe> #info we'll try to work with systemd/NM to see if "better fixes" for this issue can be placed upstream in those projects. If agreeable we'll push for a short term hack in MCO, and try to get builds into Fedora soonish. If not agreeable then we'll probably go with supporting this in afterburn.
17:20:24 <dustymabe> look good ^^?
17:20:26 <lucab> dustymabe: I think so, again I think it's fine as well if we decide that Afterburn takes care of that on GCP only
17:20:45 <lucab> dustymabe: ack
17:20:54 <dustymabe> #topic tracker: Fedora 33 rebase work
17:20:59 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/609
17:21:20 <dustymabe> my only item for today is.. we need to figure out when we're going to migrate the `testing` stream
17:21:45 <dustymabe> the only remaining item I know about is the hostname issue we just discussed
17:22:14 <dustymabe> should we hold until that's resolved (though it should be noted it mostly affects OKD and only on GCP)
17:22:29 <dustymabe> or should we try to target moving the `testing` stream over next week?
17:23:16 <dustymabe> also there is a fedora 33 coreos test day scheduled for the 6th of November!
17:23:23 <dustymabe> #info there is a fedora 33 coreos test day scheduled for the 6th of November!
17:23:35 <jlebon> nice!
17:23:50 <jlebon> hmm, should we wait until the outcome of the test day before moving testing?
17:23:51 <davdunc> on the calendar!
17:24:01 <dustymabe> jlebon: that works for me
17:24:26 <dustymabe> it will also give us a little more time to figure out this hostname issue
17:24:38 * dustymabe notes we should probably try to switch COSA to f33 soon
17:24:41 <jlebon> SGTM
17:24:58 <lucab> test-day it's next week, so I think it's a reasonably short delay
17:25:03 <dustymabe> I had started this work a bit ago, but dropped it when we figured out how to run the osmet stuff in the target context
17:25:34 <lucab> also, the hostname thing does not affect plain FCOS, only things like OKD that change the default behavior
17:25:39 <dustymabe> #info we'll target switching over the testing stream to Fedora 33 on Nov 17th
17:26:15 <dustymabe> #topic gather status update for Fedora Council
17:26:21 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/650
17:26:29 <dustymabe> #link https://hackmd.io/1VL24L6sSfG4_f81KdRzwg
17:26:40 <dustymabe> help us fill out the hackmd with all the cool things we've done over the past month
17:27:59 <dustymabe> and while people are helping fill that out.. we'll open it up to see if there are open floor topics
17:28:05 <dustymabe> #topic open floor
17:28:51 <davdunc> just want you to know that the FCOS publication to AWS Marketplace is pending successful completion of the Fedora Cloud Base.
17:28:56 <dustymabe> #info dustymabe doing investigation into adding pipeline tests to run on OpenStack (using Vexxhost as the provider)
17:29:14 <dustymabe> davdunc: fingers crossed fedora cloud base goes well
17:29:23 <dustymabe> oh oh.. I have one
17:29:28 <davdunc> it's looking good right now.
17:31:02 <dustymabe> cverna created a doc to track submissions for devconf.cz
17:31:06 * dustymabe looking for the link '
17:31:44 <dustymabe> #info cverna created a doc to track submissions for devconf.cz https://hackmd.io/1VL24L6sSfG4_f81KdRzwg
17:31:52 <dustymabe> do we have anyone that can submit a talk?
17:32:03 <dustymabe> I'm going to decline this year because I'll be busy with a new baby
17:32:13 <dustymabe> nasirhm: FYI ^^
17:32:46 <bgilbert> davdunc: awesome.  should we wait to sync up on technical details until after Cloud Base goes through?
17:32:49 <dustymabe> jlebon bgilbert I think it would actually be really cool to have a deep dive talk into how we create images that boot on both BIOS and UEFI and also how osmet works
17:33:35 <bgilbert> dustymabe: re the former, we... install GRUB twice?
17:34:04 <dustymabe> i.e. not really that cool?
17:34:12 <lucab> bgilbert: we should aim for three times!
17:34:12 <jlebon> yeah, osmet and the PXE/ISO hack would be cool. though it wouldn't be a very long talk i think
17:34:21 <bgilbert> lucab++
17:34:23 <zodbot> bgilbert: Karma for lucab changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:34:30 <nasirhm> dustymabe: Thanks :)
17:34:34 <bgilbert> yeah, the PXE/ISO mechanism might be more interesting
17:34:49 <dustymabe> +1 - all of it is interesting to me :)
17:35:00 <dustymabe> also keep in mind that the bar for what you find interesting is extremely high
17:35:08 <nasirhm> Hmm, I would like to collaborate on it :)
17:35:26 <dustymabe> there are plenty of people that would find something interesting that you think is not that innovative
17:35:28 <bgilbert> dustymabe: that is true :-)
17:35:56 <lucab> jlebon: a short one on the osmet part would be nice, I reviewed the fiemap_extent part but I still have huge gaps on how the magic actually works
17:36:02 <bgilbert> at least the part about me not finding things interesting :-P
17:36:03 <dustymabe> if someone wants to submit a "lab session" again, that would be nice
17:36:18 <dustymabe> bgilbert: :)
17:36:26 * dustymabe apologizes for the meeting going long
17:36:41 <jlebon> lucab: i'll think about it :)
17:36:54 <davdunc> I'd like to work on a lab session
17:37:18 <nasirhm> dustymabe: If someone's interested on submitting the Lab session , I would love to collaborate on it :)
17:37:23 <dustymabe> davdunc: that would be awesome.
17:37:36 <nasirhm> davdunc: That would be awesome (1)
17:37:40 <dustymabe> davdunc: do you mind working with travier and nasirhm?
17:37:54 <davdunc> I would love to do it with them, yes!
17:38:09 <dustymabe> CFP closes Nov 1, 2020
17:38:38 <dustymabe> ok I'll close out the meeting soon if chatter diminishes
17:38:39 <davdunc> okay. I'll put a skeleton together and travier and nasirhm and I will make it a full submission together.
17:38:56 <nasirhm> davdunc: Sounds Great
17:39:14 <davdunc> crawl walk, then "leave you to run on your own" session.
17:40:07 <dustymabe> #endmeeting