10:11 <hartan[m]> Hello,

10:11 <hartan[m]> quick question on adding users to CoreOS via butane/ignition: How do I configure a user that can use sudo but still needs to enter their password to authenticate for sudo? Can ignition do this automatically or are there manual steps involved?

13:51 <walters> hartan: our default configuration has: ```## Allows people in group wheel to run all commands

13:51 <walters> %wheelALL=(ALL)ALL

13:51 <walters> ``` so if you add them to that group it will get what you want

13:52 <walters> * hartan: our default configuration has:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/f39796ba1b5c40a4a8d5e81ab4517271f30a2372>)

14:05 <hartan[m]> Has anyone tried unlocking volumes with FIDO2 during boot before?

14:20 <hartan[m]> <hartan[m]> "Has anyone tried unlocking..." <- Problem solvec. For the record: `rpm-ostree initramfs --enable` does the trick.

15:53 <stephanepoq> hartan[m]: have done that: https://deisi.github.io/posts/luks_mi_yubikey/ , but not fido

15:53 <stephanepoq> sudo apt install yubikey-luks

15:54 <stephanepoq> was the debian package

15:56 <hartan[m]> It doesn't require installing an additional package in CoreOS, I used systemd-cryptenroll to register the token. The problem is that (iiuc) all CoreOS systems, by default, boot a pre-generated initramfs which doesn't work with FIDO2 tokens. Regenerating the initramfs locally after adding entries to /etc/crypttab resolves this.

16:10 <dustymabe> walters: is it new that `rpm-ostree install` will prompt user Y/n ?

16:10 <walters> dustymabe: https://github.com/coreos/rpm-ostree/pull/3890

16:11 <walters> found via https://github.com/coreos/rpm-ostree/pulls?q=is%3Apr+is%3Aclosed+prompt

16:12 <dustymabe> cool - thanks

18:17 <marmijo[m]> dustymabe: jlebon: Colin Walters: I created two PRs to resolve https://github.com/coreos/fedora-coreos-tracker/issues/1369, could I get some reviews when you have some time?

18:17 <marmijo[m]> https://github.com/coreos/fedora-coreos-config/pull/2155

18:17 <marmijo[m]> https://github.com/openshift/os/pull/1107

21:41 <dustymabe> jlebon: walters: want to discuss non-async here for a few? https://github.com/coreos/coreos-assembler/pull/3307

21:41 <dustymabe> jlebon: IIUC in that last comment you are arguing for the instance type abstraction?

21:42 <jlebon> not exactly. i added an edit to my comment :)

21:43 <dustymabe> ahh OK

21:43 <dustymabe> though that leaves me a bit confused

21:43 <dustymabe> does Kola even know much about cloud instance types today?

21:44 <dustymabe> I think there's just a default and you can override that

21:44 <jlebon> it doesn't, but it could

21:45 <jlebon> i wonder if there's an AWS API where you give your requirements and it tells you the cheapest instance type that fits your needs

21:45 <jlebon> but barring that, we could hardcode a few based on memory

21:45 <dustymabe> I'm not aware of one

21:47 <daMaestro> https://aws.amazon.com/compute-optimizer/ is what i've used in the past on workloads post rough-math-sizing ;-)

21:48 <daMaestro> find your constraint and then determine the unit (1 vcpu, 1g ram, 1g storage, 1m net, etc, etc) you need to scale -- find the most cost effective way to get that unit scale cost optimized and you've found your instance type

21:52 <daMaestro> https://aws.amazon.com/premiumsupport/knowledge-center/ec2-instance-choose-type-for-workload/ is a good summary

21:52 <daMaestro> also, ask chatgpt, might be good for some entertainment ;-p

21:54 <walters> jlebon: what we really want is spot instances, for which there is tooling built on that

21:55 <dustymabe> walters: but why? simply because it's cheaper?

21:55 <walters> yep

21:56 <dustymabe> meh

21:56 <dustymabe> I illustrated in the ticket that our actual usage (cost) for tests is very minimal since we get charged by the second and the instances are up for short periods of time.

21:57 <dustymabe> I'd much rather spend our time chasing something else (like enabling aarch64 for azure and gcp) than trying to figure out how to use spot instances.

21:58 <walters> yeah

21:58 <dustymabe> if we're concerned about cost I'd also argue that we should pursue actually implementing our Garbage Collection initiative

21:59 <walters> also true

21:59 <dustymabe> since there is probably a bunch of storage we could prune as part of that

21:59 <dustymabe> +1

21:59 <dustymabe> regarding your proposal for an instance type abstraction in cosa.. I'm not fully opposed, I just would like to understand the value and weigh the maintenance cost of it.

22:00 <walters> but I wrote the PR since I used it for getting a small instance type in qemu conveniently, it's nearly risk free and has no user impact. GC is not that

22:00 <dustymabe> I know the code is easy to write, but is the abstraction helpful over time? i.e. having more than one way to do something can be unhelpful at times

22:02 <walters> I guess I don't really care enough to champion it that much, if you don't like it, feel free to close

22:02 <jlebon> i don't see it so much in terms of cost, but more just efficiently using resources

22:02 <dustymabe> jlebon: you mean spot instances? or what?

22:02 <jlebon> and also it'd be nice to know if our tests no longer fit in e.g. a nano or whatever baseline we land on

22:03 <jlebon> i mean using a smaller instance type by default

22:03 <dustymabe> jlebon: but now you're talking about cloud again?

22:03 <dustymabe> and not qemu tests?

22:04 <jlebon> yeah, cloud instances

22:04 <dustymabe> but that's not what this PR is really

22:04 <dustymabe> well - maybe I don't understand

22:05 <jlebon> i think you're right, but it sounds like the implication is that our default AWS instance type is overkill

22:05 <walters> or we could leave it open, but deferred. In terms of things I do want to get in, https://github.com/coreos/coreos-assembler/pull/3128 is still there

22:06 <dustymabe> IIUC this PR adds an instance type abstraction to cosa and the current implementation just makes it so you can specify an instance type for qemu instances (for tests or cosa run invocations)

22:06 <dustymabe> if we extend that to the cloud tests now we have to convert between the bespoke instance types names that we defined with the instance types available in the cloud and map them

22:07 <jlebon> right, that's where my minMemory suggestion comes in :)

22:07 <dustymabe> and all of it really boils back down into how much memory and CPU you really need (for the most part, I guess you could bundle it with disk size)

22:07 <dustymabe> for which we already have knobs for, right?

22:08 <jlebon> yup. they only work on QEMU currently. i'm arguing for making them work in other clouds, and then we could lower the baseline

22:08 <bgilbert> just looking at this

22:08 <bgilbert> I'm not strongly opposed, but I am concerned that the instance type names are pretty opaque

22:08 <bgilbert> e.g. the sort of thing in https://github.com/coreos/coreos-assembler/pull/3307/files#diff-5edba7506be4ea13294ca49595c634b7653eb189fab3f976f1f9b39c6f2a7bd3 could easily get cargo-culted around

22:09 <walters> I just closed it

22:09 <bgilbert> also, I can imagine someone trying to change the name -> size mappings later, and not being clear what the actual dependencies are on them

22:10 <jlebon> dustymabe: to be clear, i agree it's not really super high priority

22:11 <jlebon> bgilbert: yeah, i'd rather stick with the explicit minMemory knob (and disk size, and... we don't have one for ncpus yet, but could)

22:11 <bgilbert> I used spot instances for some Buildbot-based CI years ago. there were some nice cost savings, but it sometimes added a few minutes of startup delay/weird flakes

22:12 <bgilbert> haven't tried it in 5+ years though

22:12 <dustymabe> walters: ha, sorry. I wasn't trying to kill it per-se, but was interested in the discussion about usefullness (i.e. maybe there was something I was missing)

22:12 <walters> It's not worth the 4 senior engineer bikeshedding time

22:12 <walters> So let's move on

22:13 <bgilbert> 🚲

22:13 <dustymabe> ok cool. maybe we can get around to seriously considering https://github.com/coreos/coreos-assembler/pull/3128 soon too

22:13 <dustymabe> thanks for the discussion walters jlebon bgilbert

22:18 <jlebon> see ya!

22:19 <dustymabe> jlebon: based on https://bugzilla.redhat.com/show_bug.cgi?id=2006063 I just noticed in the current running `testing-devel` build:

22:19 <dustymabe> [2023-01-05T22:12:10.082Z] Removed:

22:20 <dustymabe> [2023-01-05T22:12:10.082Z] cracklib-dicts-2.9.7-30.fc37.x86_64

22:20 <dustymabe> 🎉

22:20 <jlebon> dustymabe: cool! had seen it for rawhide this morning but not yet testing-devel