16:31:11 <dustymabe> #startmeeting fedora_coreos_meeting
16:31:12 <zodbot> Meeting started Wed Sep 30 16:31:11 2020 UTC.
16:31:12 <zodbot> This meeting is logged and archived in a public location.
16:31:12 <zodbot> The chair is dustymabe. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:31:12 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:31:12 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:31:15 <cyberpear> .hello2
16:31:18 <dustymabe> #topic roll call
16:31:18 <zodbot> cyberpear: cyberpear 'James Cassell' <fedoraproject@cyberpear.com>
16:32:06 <bgilbert> .hello2
16:32:06 <zodbot> bgilbert: bgilbert 'Benjamin Gilbert' <bgilbert@backtick.net>
16:32:16 <lucab> .hello2
16:32:18 <zodbot> lucab: lucab 'Luca Bruno' <lucab@redhat.com>
16:33:30 <rtsisyk> hi
16:33:30 <nasirhm1> .hello2
16:33:31 <zodbot> nasirhm1: Sorry, but you don't exist
16:33:44 <nasirhm1> .hello nasirhm
16:33:45 <jlebon> .hello2
16:33:45 <zodbot> nasirhm1: nasirhm 'Nasir Hussain' <nasirhussainm14@gmail.com>
16:33:48 <zodbot> jlebon: jlebon 'None' <jonathan@jlebon.com>
16:34:14 <dustymabe> #chair cyberpear bgilbert lucab rtsisyk nasirhm1 jlebon
16:34:14 <zodbot> Current chairs: bgilbert cyberpear dustymabe jlebon lucab nasirhm1 rtsisyk
16:34:17 <dustymabe> welcome rtsisyk
16:34:41 <nasirhm1> Welcome rtsisyk
16:34:41 <lorbus> .hello2
16:34:42 <zodbot> lorbus: lorbus 'Christian Glombek' <cglombek@redhat.com>
16:34:52 <dustymabe> #chair lorbus
16:34:52 <zodbot> Current chairs: bgilbert cyberpear dustymabe jlebon lorbus lucab nasirhm1 rtsisyk
16:35:01 <dustymabe> also
16:35:03 <skunkerk> .hello sohank2602
16:35:03 <zodbot> skunkerk: sohank2602 'Sohan Kunkerkar' <skunkerk@redhat.com>
16:35:04 <dustymabe> .chair lorbus
16:35:06 <zodbot> lorbus is seated in a chair with a nice view of a placid lake, unsuspecting that another chair is about to be slammed into them.
16:35:23 <dustymabe> 🤣
16:35:28 <lorbus> :D
16:35:30 <nasirhm1> dustymabe: Nice one :P
16:35:52 <cverna> hello o/
16:35:55 <dustymabe> #topic Action items from last meeting
16:35:59 <dustymabe> #chair cverna
16:35:59 <zodbot> Current chairs: bgilbert cverna cyberpear dustymabe jlebon lorbus lucab nasirhm1 rtsisyk
16:36:15 <dustymabe> There were no action items from last meeting so we're good there
16:36:30 <dustymabe> moving on
16:36:37 <cverna> \o/
16:36:37 <dustymabe> #topic Move rpmdb path from /usr/share/rpm to /usr/lib/sysimage/rpm
16:37:08 <dustymabe> This was a follow on from a bug discussion some time ago.
16:37:21 <dustymabe> we recently had the database change in rpm from bdb to sqlite
16:37:40 <dustymabe> and at the same time we also proposed to move the database location, but the rpm maintainer didn't want to mix too many changes at once
16:37:46 <dustymabe> IIRC
16:38:03 <dustymabe> so should we file a change request for Fedora 34 to make that happen in F34 time frame?
16:38:15 <cyberpear> maybe smoothest path is to have rpm-ostree do a fallback to /usr/share/rpm if /usr/lib/sysimage/rpm doesn't exist?
16:38:27 <cyberpear> are we trying to do this at the RPM level?
16:38:40 <nasirhm1> cyberpear: Sounds like a nice idea.
16:38:57 <lucab> #link https://github.com/coreos/fedora-coreos-tracker/issues/639
16:39:34 <dustymabe> lucab: thanks for that. sorry I failed to paste the link
16:39:52 <dustymabe> I think walters was part of the original discussion
16:40:21 <dustymabe> now I'm also trying to find a link to the bug where we were discussing this with the rpm maintainer
16:40:27 <aoei> .hello2
16:40:27 <zodbot> aoei: aoei 'Joanna Doyle' <jjadoyle@gmail.com>
16:40:29 <aoei> sory late
16:40:33 <jlebon> original thread is http://lists.rpm.org/pipermail/rpm-maint/2017-October/006681.html
16:40:41 * dustymabe waves at aoei
16:40:46 <dustymabe> #chair aoei
16:40:47 <zodbot> Current chairs: aoei bgilbert cverna cyberpear dustymabe jlebon lorbus lucab nasirhm1 rtsisyk
16:40:47 <aoei> hey dusty
16:40:55 <dustymabe> #link http://lists.rpm.org/pipermail/rpm-maint/2017-October/006681.html
16:41:06 <lorbus> hey aoei!
16:41:49 <jlebon> dustymabe: https://bugzilla.redhat.com/show_bug.cgi?id=1838691#c24
16:41:56 <jlebon> that one?
16:42:01 <dustymabe> that's it
16:42:50 <aoei> would SUSE be annoyed at me if I told them to use ZFS instead
16:42:55 <aoei> c:
16:43:06 <dustymabe> so.. if we want this to happen we should take some steps to get there I believe. Is it something we want to happen? Should we file a change request for f34?
16:43:51 * dustymabe leans on jlebon and walters for expertise here since they have the most experience
16:44:27 <jlebon> it'd be a nice change, though would be good to have someone from rpm to lead it
16:44:55 <jlebon> as far as rpm-ostree goes, it wouldn't be very hard to adapt. but changing all of fedora clearly will need a lot of thought and discussions
16:45:37 <dustymabe> jlebon: would you be willing to reach out to the rpm maintainers to see if that's something they'd take up. or maybe offer to co-lead if they seem hesitant?
16:46:01 <jlebon> dustymabe: i can do that, sure
16:46:04 <cyberpear> if it goes thru, I'd expect a similar change for /var/lib/dnf
16:46:09 <aoei> ok having read on a bit more maybe the /usr/lib/rpmdb move is slightly more realistic
16:46:13 <jlebon> we can own the "rpm-ostree-based variants" part of the equation
16:46:35 <dustymabe> yeah, that would at least take that off the rpm maintainers "worry-sphere"
16:47:11 <dustymabe> #action jlebon to reach out to the rpm maintainers to see if the relocation of the rpmdb path is something their willing to own for F34
16:47:59 <dustymabe> #topic Add FCOS to AWS Marketplace
16:48:10 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/635
16:48:19 <dustymabe> bgilbert: do you want to intro this one?
16:48:25 <bgilbert> sure
16:48:51 <bgilbert> up to this point, we've considered AWS GovCloud and AWS Marketplace out of scope for Fedora CoreOS
16:49:01 <bgilbert> the main reason is paperwork
16:49:32 <bgilbert> "Fedora" would need to sign agreements etc., "Fedora" isn't an entity that can sign agreements, and then things get messy
16:50:09 <bgilbert> but davdunc from AWS has posted a proposal at the Fedora level which could work around that problem
16:50:19 <bgilbert> #link https://pagure.io/Fedora-Council/tickets/issue/332
16:50:46 <bgilbert> basically, AWS would host Marketplace entries in an account it controls, on behalf of Fedora.
16:51:07 <bgilbert> AWS CI would listen on fedmsg, pick up new AMI builds, copy the AMIs and send them through its publication pipeline.
16:51:29 <bgilbert> once the Marketplace AMIs are updated (which can take a few hours) they'd send back another fedmsg reporting the AMI IDs.
16:52:07 <bgilbert> to connect with this system, we'd need to emit fedmsgs when AMIs are ready, which is
16:52:09 <bgilbert> #link https://github.com/coreos/fedora-coreos-tracker/issues/225
16:52:39 <bgilbert> and we'd presumably want to add the Marketplace AMIs to stream metadata, so we'd want a job that listens for the reply fedmsg and PRs stream metadata.
16:52:48 <bgilbert> there's some additional stuff around rollbacks, but that's the bulk of it.
16:52:51 <bgilbert> what this gains us:
16:53:10 <bgilbert> 1) GovCloud and any other restricted AWS regions
16:53:23 <bgilbert> 2) a nice Marketplace landing page for FCOS
16:53:30 <bgilbert> 3) possibly some additional statistics
16:53:49 <aoei> sounds pretty promising
16:53:50 <bgilbert> 4) easier FCOS access for AWS customers who have compliance requirements satisfied by Marketplace (e.g. its automatic security scans)
16:54:01 <bgilbert> 5) easier for other Marketplace providers to ship their own software on top of FCOS
16:54:46 <bgilbert> I should note that this is still in the proposal phase, but I'm not aware of any opposition at the Fedora level
16:54:48 <dustymabe> sounds great to me. it would be nice if we could retroactively update our metadata to include the marketplace AMIs just for tracking if a user comes to us with an AMI we can't figure out where it came from
16:54:53 <jlebon> huh didn't realize that marketplace AMIs were separate from the AMIs we already upload
16:55:01 <aoei> bgilbert: are there any drawbacks or catches you're aware of ?
16:55:14 <bgilbert> dustymabe: you mean the release metadata?
16:55:24 <bgilbert> presumably we could do that too
16:55:33 <bgilbert> jlebon: yup, Marketplace has always worked that way
16:55:43 <dustymabe> ehh. not even necessarily that.. even if it was just the meta.json
16:55:55 <dustymabe> somewhere where we could look at have that info correlated
16:56:03 <dustymabe> but that's a stretch goal
16:56:09 <jlebon> i guess that means they'll also take care of GC?
16:56:12 <bgilbert> meta.json is an implementation detail IMO, but sure
16:56:23 <dustymabe> so biggest blocker from our end is https://github.com/coreos/fedora-coreos-tracker/issues/225
16:56:27 <dustymabe> ?
16:56:27 <bgilbert> jlebon: hmm, I hadn't thought about GC
16:56:52 <jlebon> it's kinda awkward to have a reference to something in our metadata that we don't actually own
16:56:53 <bgilbert> jlebon: we're not paying for storage, so the only concern there is if we want to actively withdraw old images.  do we?
16:56:54 <lucab> bgilbert: so the stream metadata will contains two sets of AMI, the "normal" one and the marketplace one?
16:57:09 <bgilbert> I think part of the point of Marketplace is that users retain access to old versions; not sure though
16:57:14 <bgilbert> lucab: right
16:57:26 <lucab> (multiplied per each region)
16:57:34 <bgilbert> jlebon: we already have provisions to do that, e.g. for Packet and DO
16:57:43 <bgilbert> jlebon: it's just that those identifiers will be static, not varying per release
16:57:48 <bgilbert> lucab: right
16:57:50 * dustymabe really likes that google just has one image for $global
16:58:03 <bgilbert> aoei: a couple drawbacks
16:58:30 <bgilbert> aoei: we'd be shipping two sets of images per release, which could be confusing
16:59:09 <bgilbert> we wouldn't directly control the Marketplace AMIs (in terms of API access to manipulate them) and there's publishing latency
16:59:18 <aoei> right
16:59:23 <aoei> those don't sound too bad imo
16:59:24 <bgilbert> davdunc expects the latency to be on the order of a couple hours
16:59:26 <lucab> silly question: the marketplace set sounds like a superset of our normal set, won't it obsolete the latter?
16:59:35 <bgilbert> I can tell you that with Container Linux the latency sometimes ran to two weeks
16:59:49 <aoei> bgilbert: i was about to say I don't trust the two hours thing :P
16:59:53 <bgilbert> but this would be much more automated than the pipeline CL was using
17:00:01 <aoei> ah okay
17:00:22 <bgilbert> I think we'd still preferentially recommend the community AMIs for users who can use them
17:00:30 <dustymabe> +1
17:00:32 <bgilbert> but we'd need to be careful to explain the tradeoffs
17:00:41 <aoei> right
17:00:43 <aoei> makes sense
17:00:51 <jlebon> is it one landing page for FCOS in the marketplace or one per marketplace AMI?
17:01:09 <bgilbert> one per 'product', i.e. release stream
17:01:12 <cyberpear> it's a huge win that GovCloud users would be able to use it, though
17:01:19 <jlebon> we could probably just keep publishing the community ones on getfedora.org/coreos, but also link to the marketplace landing page
17:01:25 <bgilbert> here's the old CL landing page: https://aws.amazon.com/marketplace/pp/B01H62FDJM
17:01:38 <bgilbert> jlebon: that's not a bad idea
17:01:49 <bgilbert> jlebon: maybe still list the AMIs in stream metadata though?
17:01:51 <bgilbert> just not on the website
17:01:56 <dustymabe> SGTM
17:02:22 <dustymabe> so we should try to prioritize https://github.com/coreos/fedora-coreos-tracker/issues/225 ? and then they'll do most of the rest of the work?
17:02:34 <jlebon> bgilbert: i think so yeah.  still need to think that part through
17:02:39 <bgilbert> jlebon: +1
17:02:52 <bgilbert> dustymabe: I think that's basically the situation.  with the caveat that I don't know timelines.
17:03:05 <bgilbert> I know davdunc has been working on this for a while already, so it may not move super-fast
17:03:10 <lucab> looping back from fedmsg to github doesn't seem great, maybe we can skip that if there is no actual use of that information?
17:03:26 <jlebon> we definitely want 225 anyway for other purposes
17:03:33 <lucab> sorry, I worded it badly
17:03:39 <bgilbert> lucab: right, IMO we should do that loop only if needed
17:03:55 <dustymabe> where does github come in?
17:04:00 <bgilbert> stream metadata update
17:04:09 <lucab> it is possibly great but with non-negligible additional infra and human involvement
17:04:27 <dustymabe> got ya
17:04:31 <bgilbert> strictly speaking we can always add that part later
17:04:36 * cverna can probably help with infra work
17:05:14 <dustymabe> bgilbert: any particular outcomes we need to end up with from today's discussion?
17:05:42 <bgilbert> dustymabe: I don't think so.  mostly raising awareness.  225 was already something we wanted to do.
17:05:51 <bgilbert> any questions I missed from the scrollback?
17:06:10 <aoei> you answered mine
17:06:11 <lucab> bgilbert: if we plan to being with "linking to marketplace landing page" then yes it seems reasonable to do the "fedmsg-to-PR" part only later and if needed
17:06:18 <lucab> *begin with
17:06:19 <dustymabe> i think everyone is in agreement
17:06:31 <dustymabe> thanks for bringing this up bgilbert!
17:06:43 <aoei> indeed, thanks bgilbert!
17:06:47 <dustymabe> shall we move to the next topic ?
17:06:49 <jlebon> +1 this sounds really nice
17:06:50 <bgilbert> lucab: I think the fedmsg-to-PR part would be a good thing to do, but yeah, we can figure that out
17:06:54 <bgilbert> dustymabe: +1
17:07:04 <dustymabe> #topic Add basic monitoring tools to the base image
17:07:10 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/628
17:07:30 <lucab> bgilbert: I had "why not deprecating the community set" but I think you answered already with "latency could be very high and with variance"
17:07:40 <bgilbert> lucab: +1
17:07:53 <dustymabe> so this topic is a bit open ended
17:08:05 <dustymabe> but it has a general theme
17:08:19 <dustymabe> of generically useful tools that we might want to add to the base image
17:08:28 <dustymabe> i think each one of them would need to be considered individually
17:08:32 <rtsisyk> Re #628. My proposal is to add some essential troubleshoting tools such as `strace`, `tcpdump`, `iotop`, `ioping` and others to the base image.
17:08:44 <rtsisyk> yes, let's discuss this list one by one.
17:09:09 <dustymabe> rtsisyk: we might now have enough time for all of them today. if we don't we can carry the discussion in the ticket
17:09:12 <rtsisyk> - `strace` - starce can be used to troubleshoot the container runtime itself. strace is just 1.5MB, wht don't add it?
17:09:29 <rtsisyk> ok
17:09:40 <rtsisyk> what do you suggest?
17:09:57 <dustymabe> bgilbert: lucab: jlebon: do you have any preference on how we carry forward this discussion?
17:10:08 <bgilbert> in-ticket would be better IMO
17:10:09 <dustymabe> is going through each one ideal, or do you think there would be a better way?
17:10:14 <jlebon> i think one useful criterion is whether the tool can be helpful in debugging container runtime issues
17:10:32 <bgilbert> right, basically if you can get network and run a container without the tool, you should probably run the tool in a container
17:10:35 <jlebon> (mentioned this in https://github.com/coreos/fedora-coreos-tracker/issues/628#issuecomment-697765701)
17:10:56 <dustymabe> bgilbert: yep.
17:11:18 <dustymabe> one example that I use is `dig`.. for example if you can't debug dns you might not be able to download a container in order to debug dns :)
17:11:24 <dustymabe> that's why `dig` is in FCOS
17:11:49 <jlebon> just going to try to advocate for at least one of those right now: strace.  i think we should include it
17:11:55 <rtsisyk> I agree that almost everything can be run via container. But anyway. The primary purpose of a host operating symstem (such as CoreOS) is a work with the underlying hradrware. Tools like `dmidecode`, `smartmontools`, `pciutils`, `usbutils` are needed to troubleshoot the bare metal.
17:12:00 <rtsisyk> tcpdump is needed to debug the network
17:12:05 <lucab> just to set the background, "it's just 1KiB" isn't a focal point. "how can this be abused as a turing complete interpreter" and "did you try running in podman" and "in which case this is needed and can't be layered for debugging" are more interesting IMHO
17:12:19 <rtsisyk> I can't download container without working network, but I have IPMI/BMC and tcpdump to fix the network.
17:12:51 <rtsisyk> dig is extremely useful
17:12:56 <dustymabe> so should we lay out some criterion like jlebon stated in the ticket and then evaluate each one (probably in the time between now and next meeting)?
17:13:16 <aoei> yeah, make clear criteria for the ticket
17:13:20 <aoei> then analyse each case with those
17:13:24 <aoei> dustymade +1
17:13:26 <dustymabe> there are some things that might not meet the criteria, but we still want to include
17:13:27 <bgilbert> we're going to keep having questions about this, so yeah, we probably need formal criteria at this point
17:13:29 <aoei> dustymabe sorry
17:13:47 <jlebon> SGTM
17:13:48 <dustymabe> should we try to work out that criteria now?
17:14:09 <aoei> yup, key one being as you mentioned, is it needed to fix something that might stop you downloading the image
17:14:19 <aoei> like, that's a pretty high priority consideration right
17:14:45 <bgilbert> there are a lot of tools that could conceivably be used to troubleshoot things
17:14:48 <aoei> another would be is it impossible to run in a container?
17:14:57 <bgilbert> gdb would be useful for debugging podman but we shouldn't ship it
17:14:59 <aoei> bgilbert: true, but mayb ewe can limit that
17:15:06 <dustymabe> collaborate hacking doc: https://hackmd.io/3LlGUzYjT-C3sbkIDBquKQ
17:15:10 <rtsisyk> I vote +1 for GDB :)
17:15:10 <aoei> gdb is less likely to fix a networking issue stopping you from getting a container image
17:15:39 <rtsisyk> the only reason I excluded GDB is because it depends on Python
17:16:17 <aoei> dustymabe: should some negative criteria be included too? (like, depends on python)
17:16:20 <misc> I am not sure gdb is useful for golang, and it can be debugged remotely using a static stub
17:16:54 <rtsisyk> gdb can be used for getting the stack traces
17:17:07 <rtsisyk> but anyway, I don't insist
17:17:12 <rtsisyk> tcpdump is really needed
17:17:15 <bgilbert> rtsisyk: a minimal OS is never going to feel as comfortable at a command prompt as a full server OS.  we can't ship everyone's preferred tools (or even anyone's preferred tools) and still be minimal.
17:17:48 <rtsisyk> ok. What do you suggest to do without `lspci`, for example?
17:18:07 <rtsisyk> how to understand that this server has NVIDIA GPU, for example?
17:18:18 <jlebon> shouldn't that work fine in a privileged container?
17:18:28 <dustymabe> yeah I think things like dmidecode and lspci have merit
17:18:30 <rtsisyk> everything can be done in a privilefed container
17:18:33 <jlebon> (just tried it here in my pet container and it's not lying :) )
17:18:44 <rtsisyk> the goal is to make life easier for the ops team
17:18:48 <dustymabe> jlebon: think about the live installer environment if someone is doing hardware discovery
17:18:51 <bgilbert> rtsisyk: that's what toolbox is for
17:19:14 <rtsisyk> do you meen an image which used by OpenShift Console when I press "Console" button?
17:19:56 <aoei> oh lol depends on python is already in there
17:20:01 <rtsisyk> OpenShift has some image used to enter into TTY via web
17:20:11 <rtsisyk> but this image also don't have tools... :)
17:20:23 <bgilbert> rtsisyk: I mean /usr/bin/toolbox
17:20:34 <rtsisyk> let me check
17:20:38 <dustymabe> ahh.. bgilbert yeah we should probably mention toolbox in this list of questions
17:20:52 <dustymabe> do we have a "debugging" container that already exists
17:20:59 * dustymabe vaguely remembers one called 'tools'
17:21:09 <lucab> more generalized: any container image that contains your preferred toolset and can be run by podman in privileged mode
17:21:19 <rtsisyk> /usr/bin/toolbox
17:21:20 <rtsisyk> toolbox: missing command
17:21:20 <rtsisyk> These are some common commands:
17:21:20 <rtsisyk> create    Create a new toolbox container
17:21:20 <rtsisyk> enter     Enter an existing toolbox container
17:21:22 <rtsisyk> list      List all existing toolbox containers and image
17:21:28 <rtsisyk> Download registry.fedoraproject.org/f32/fedora-toolbox:32 (500MB)? [y/N]:
17:21:31 <rtsisyk> hmm
17:21:35 <rtsisyk> I have never seen this feature
17:21:41 <cverna> yeah there is tools container in fedora but it is not really maintain afaik
17:21:56 <cverna> https://src.fedoraproject.org/container/tools
17:22:04 <lucab> rtsisyk: see https://cloud.google.com/container-optimized-os/docs/how-to/toolbox to get an idea of how that flow works
17:22:06 <bgilbert> 'git grep toolbox' in fedora-coreos-docs returns no hits :-(
17:22:24 <rtsisyk> https://src.fedoraproject.org/container/tools/blob/master/f/Dockerfile
17:22:26 <dustymabe> we should maybe flesh that out.. anything that can reasonably be done in there we should maybe point users to and add documentation for
17:22:40 <rtsisyk> this list looks like mine
17:22:49 <rtsisyk> everyone needs the same tools... :-)
17:23:16 <dustymabe> but we shouldn't require things that are needed for debugging the container runtime or network those should go higher in the list than "debugging container"
17:23:20 <lucab> rtsisyk: in a container image, absolutely yes
17:23:34 <aoei> right, now is this toolbox something you still need to pull after firing up an image? looks like that judging from the google page
17:23:34 <rtsisyk> I have to same that  container/tools is almost the same list I have in my Ansible playbooks
17:23:51 <bgilbert> filed https://github.com/coreos/fedora-coreos-docs/issues/187 for toolbox
17:24:05 <dustymabe> thanks bgilbert.. us fleshing out our toolbox story has been long overdue
17:24:08 <rtsisyk> OpenShift also have some `toolbox` image
17:24:09 <dustymabe> this might be the kick we need
17:24:12 <jlebon> to clarify: there's toolbox and tools. the former is very much actively used, though IIRC there were still issues with running it as root on FCOS
17:24:28 <jlebon> but those might have been fixed now
17:24:35 <dustymabe> jlebon: that might be fixed.. we need to investigate
17:24:37 <rtsisyk> in openshift console you can one Compute -> Nodes -> nodename -> Terminal and it will launch a toolbox-like image
17:24:54 <dustymabe> rtsisyk: right. yep. this is a similar concept
17:24:59 <rtsisyk> but tht image has almost nothing
17:25:07 <aoei> would it be acceptable to have the toolbox image already included in the fcos image?
17:25:10 <rtsisyk> even iostat doesn't present
17:25:16 <rtsisyk> everyone needs iostat
17:25:23 <rtsisyk> ask any ops
17:25:24 <rtsisyk> top
17:25:25 <rtsisyk> iostat
17:25:29 <dustymabe> aoei: probably not pre-seeded
17:25:30 <rtsisyk> are must have
17:25:38 <aoei> ok dusty
17:25:55 <jlebon> this came up in RHCOS-land too. i think it'd be cool to have some way to embed container images in the VM/metal images
17:26:01 <aoei> but i guess this is also for more general admin than just fixing network/crun in order to get the container working in the first place
17:26:02 <jlebon> doesn't help the live case though
17:26:20 <cverna> silverblue does that with flatpak I think
17:26:21 <dustymabe> rtsisyk: i think that's fair. there will probably be some we do want to include. we're just thinking generically right now
17:26:32 <rtsisyk> ok
17:26:36 <bgilbert> proposal: let's file a tracker ticket to come up with rough criteria for adding packages
17:26:36 <lucab> jlebon: nor the general case of any cloud image, no?
17:26:51 <bgilbert> I don't think we'll ever reduce it to a mechanical set of rules
17:26:58 <aoei> right, but guidelines i guess
17:27:12 <bgilbert> and then consider proposals for individual packages.
17:27:23 <dustymabe> bgilbert: yeah it's probably not a mechanical set of rules, but a set of "questions" is a good way to start the conversation about $tool
17:27:24 <jlebon> lucab: not those we upload ourselves, but user-uploaded ones sure
17:28:00 <bgilbert> in general, rtsisyk, I don't think adding a large set of tools to the distro is something we're enthusiastic about doing.  we absolutely do need better docs about how to use those tools in a container, though.
17:28:12 <dustymabe> #action we'll file a tracker ticket to come up with rough criteria for adding packages
17:28:24 <aoei> dusty have you actioned the thing about better toolbox docs?
17:28:28 <rtsisyk> @bgilbert, I agree
17:28:42 <aoei> / fleshing them out
17:28:45 <bgilbert> #link https://github.com/coreos/fedora-coreos-docs/issues/187
17:28:47 <bgilbert> aoei: ^
17:28:57 <aoei> ah right thats that one
17:29:05 <aoei> nice bgilbert
17:29:47 <dustymabe> rtsisyk: though each tool will stand on its own merit so don't be afraid to propose any :)
17:29:52 <bgilbert> right
17:29:52 <dustymabe> and thanks for the list you did come up with
17:30:11 <dustymabe> this will help kick us in the right direction to flesh out this part of our user experience
17:30:15 <rtsisyk> no problem, thanks
17:30:22 <lucab> also trying to clear out any possible misunderstanding: including any package in FCOS does not directly result in that ending up in RHCOS/OpenShift
17:30:26 <rtsisyk> I will try to play with priv container.
17:30:41 <rtsisyk> I use OKD
17:30:46 <dustymabe> lucab: correct. It will end up in OKD (since it's based on FCOS)
17:30:59 <dustymabe> but not necessarily RHCOS/OCP
17:31:10 <dustymabe> rtsisyk++
17:31:10 <zodbot> dustymabe: Karma for rtsisyk changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:31:17 <rtsisyk> wow
17:31:32 <dustymabe> ok I did poor time management today
17:31:36 <dustymabe> #topic open floor
17:31:42 <jlebon> indeed, this is good to discuss. thanks rtsisyk!
17:31:48 <rtsisyk> thanks, guys!
17:31:56 <dustymabe> a few other things I wanted to get to but we'll catch them next week
17:32:06 <dustymabe> anyone with anything for open floor?
17:32:37 <dustymabe> for the f33 rebase I'm going to start opening PRs soon to get some of the work to land in testing-devel that will enable f33
17:32:51 <dustymabe> we won't be moving over testing-devel, just prepping it and conditionalizing some logic
17:33:09 <dustymabe> we will flip next-devel when ready. hopefully thursday or friday
17:33:27 <bgilbert> next week's stable release will require PXE booting with the rootfs image
17:33:33 <bgilbert> if anyone hasn't switched over yet, now is the time :-)
17:33:50 <dustymabe> #info next week's stable release will require PXE booting with the rootfs image if anyone hasn't switched over yet, now is the time :-)
17:34:07 <rtsisyk> any details about how to switch to the root image?
17:34:17 <rtsisyk> I'm still on 20200628 or something like that
17:34:19 <bgilbert> yeah, one sec
17:34:58 <bgilbert> #link https://docs.fedoraproject.org/en-US/fedora-coreos/bare-metal/#_pxe_rootfs_image
17:35:02 <aoei> im trying to work out whether or not this matters for my VM - do providers simulate PXE boot for VMs (i doubt this) or is this only an issue for FCOS run on bare metal?
17:35:04 <dustymabe> #link https://docs.fedoraproject.org/en-US/fedora-coreos/bare-metal/#_pxe_rootfs_image
17:35:21 <dustymabe> #undo
17:35:21 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x7fcccb367bd0>
17:35:29 <rtsisyk> providers use cloudinit
17:35:32 <dustymabe> aoei: what provider do you use?
17:35:35 <bgilbert> rtsisyk: nothing uses cloudinit :-)
17:35:35 <aoei> GCP dusty
17:35:42 <dustymabe> aoei: you're good then
17:35:44 <jlebon> aoei: more specifically live environments
17:35:49 <aoei> okay, cool
17:35:59 <bgilbert> aoei: mostly bare metal, but some people PXE boot the live image in e.g. VMware
17:36:05 <bgilbert> you'd know you were doing it though
17:36:06 <aoei> ahh okay
17:36:15 <aoei> yeah i figured but i wanted to just check
17:36:17 <aoei> thanks
17:36:21 <dustymabe> rtsisyk: for FCOS we use the user data mechanism to pass an Ignition config to Ignition
17:36:25 <dustymabe> we don't happen to use cloud-init
17:36:28 <rtsisyk> I will try to update some of my OKD clusters to a new rootfs-based image in the next couple weeks.
17:36:52 <dustymabe> ok i'll close out the meeting soon
17:37:03 <rtsisyk> dustymabe: ok, I misled by my OpenStack background.
17:37:12 <aoei> for first boot I use the gcloud cli stuff and some containers for generating the inition file to fire up my instance
17:37:29 <aoei> updates automatically reboot my VM, I actually missed this in the docs until I saw it happen for real lol
17:37:35 <cverna> thanks for running the meeting dustymabe
17:37:38 <jlebon> bgilbert: slightly off-topic, though i feel like we should blog about the rootfs image and osmet for fun. it's pretty cool stuff
17:37:38 <dustymabe> #endmeeting