16:30:19 <dustymabe> #startmeeting fedora_coreos_meeting
16:30:19 <zodbot> Meeting started Wed Dec 12 16:30:19 2018 UTC.
16:30:19 <zodbot> This meeting is logged and archived in a public location.
16:30:19 <zodbot> The chair is dustymabe. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:30:19 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:30:19 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:30:24 <dustymabe> #topic roll call
16:30:33 <dustymabe> .hello2
16:30:34 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:30:35 <yzhang> .hello2
16:30:37 <zodbot> yzhang: yzhang 'Yu Qi Zhang' <jzehrarnyg@gmail.com>
16:30:38 <rfairley> .hello rfairleyredhat
16:30:40 <zodbot> rfairley: rfairleyredhat 'Robert Fairley' <rfairley@redhat.com>
16:30:40 <jlebon> .hello2
16:30:43 <zodbot> jlebon: jlebon 'None' <jonathan@jlebon.com>
16:30:58 <miabbott> .hello2
16:30:59 <zodbot> miabbott: miabbott 'Micah Abbott' <miabbott@redhat.com>
16:31:13 <rishi> .hello2
16:31:14 <zodbot> rishi: rishi 'Debarshi Ray' <debarshir@redhat.com>
16:31:16 <jbrooks> .fas jasonbrooks
16:31:21 <zodbot> jbrooks: jasonbrooks 'Jason Brooks' <jbrooks@redhat.com>
16:31:49 <slowrie> .hello2
16:31:50 <zodbot> slowrie: slowrie 'Stephen Lowrie' <slowrie@redhat.com>
16:32:24 <dustymabe> walters: are you around today or do you still have a conflict ?
16:32:41 <dustymabe> #chair yzhang rfairley jlebon miabbott rishi jbrooks slowrie
16:32:41 <zodbot> Current chairs: dustymabe jbrooks jlebon miabbott rfairley rishi slowrie yzhang
16:32:50 <walters> .hello2
16:32:51 <zodbot> walters: walters 'Colin Walters' <walters@redhat.com>
16:33:05 <walters> dustymabe: i can be around for about 10 minutes before i need to drive to 🥋
16:33:34 <dustymabe> walters: +1
16:33:43 <mnguyen_> .hello mnguyen
16:33:44 <dustymabe> will try to get to that topic early
16:33:44 <zodbot> mnguyen_: mnguyen 'Michael Nguyen' <mnguyen@redhat.com>
16:33:59 <dustymabe> so we'll do this a bit out of order since walters has to leave soon
16:34:06 <dustymabe> #chair walters mnguyen_
16:34:06 <zodbot> Current chairs: dustymabe jbrooks jlebon miabbott mnguyen_ rfairley rishi slowrie walters yzhang
16:34:27 <dustymabe> will do action items from last meeting here in just a minute
16:34:34 <dustymabe> first..
16:34:42 <dustymabe> #topic where should rpm-ostree project live
16:34:52 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/19
16:35:09 <dustymabe> we discussed this last meeting a bit (after walters had left)
16:35:32 <dustymabe> would be interested to get your input on $topic since walters invented rpm-ostree
16:35:34 <lorbus_> .hello2
16:35:35 <zodbot> lorbus_: Sorry, but you don't exist
16:35:40 <lorbus_> .hello lorbus
16:35:41 <zodbot> lorbus_: lorbus 'Christian Glombek' <cglombek@redhat.com>
16:35:56 <sayan> .hello sayanchowdhury
16:35:57 <zodbot> sayan: sayanchowdhury 'Sayan Chowdhury' <sayan.chowdhury2012@gmail.com>
16:36:09 <dustymabe> I think the current proposals are either 'move to ostreedev org' or 'move to rpm-software-management' org
16:37:05 <walters> i commented in the issue
16:38:15 <dustymabe> walters: thanks! jlebon - would you like to ask rpm-software-management to see what they say?
16:38:28 <jlebon> yup, sure
16:38:31 <dustymabe> thanks!
16:38:44 <lorbus_> +1 walters
16:38:51 <dustymabe> #action jlebon to ask rpm-software-management org on github about name move of rpm-ostree repo
16:39:09 <dustymabe> ok we'll move to action items from last meeting now
16:39:23 <dustymabe> #topic Action items from last meeting
16:39:35 <dustymabe> * jbrooks to create a ticket for deciding on the mechanism for shipping
16:39:37 <dustymabe> kube/okd pieces
16:39:39 <dustymabe> * bgilbert to review https://github.com/coreos/mantle/pull/954
16:39:41 <dustymabe> * bgilbert, dustymabe, ashcrow, walters, slowrie to discuss
16:39:43 <dustymabe> maintenance/review structure for mantle
16:39:45 <dustymabe> * lorbus to convert and bring up to speed the container-best-practices
16:39:47 <dustymabe> repo
16:39:48 <jbrooks> dustymabe, I did this one https://github.com/coreos/fedora-coreos-tracker/issues/93
16:40:12 <dustymabe> #info jbrooks created ticket for discussing machanism for shipping OKD/kube #93
16:40:18 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/93
16:40:31 <lorbus_> https://docs.fedoraproject.org/en-US/containers/ is up already
16:40:54 <dustymabe> #info lorbus_ converted container-best-practices repo and the website is already up
16:41:00 <dustymabe> #link https://docs.fedoraproject.org/en-US/containers/
16:41:07 <dustymabe> do we have bgilbert today ?
16:41:21 <slowrie> doesn't look like it
16:41:29 <lorbus_> I created the structure and started copying over info from best-practices and the Container SIG guidelines, but the content is really raw and definitely WIP
16:41:50 <lorbus_> #link https://docs.fedoraproject.org/en-US/containers/
16:42:19 <lorbus_> if you can, please contribute to the docs by reviewing or writing sections!
16:42:30 <dustymabe> I believe bgilbert was going to work on a new PR to address the mantle PR
16:42:59 <dustymabe> #action bgilbert to get functionality requested in https://github.com/coreos/mantle/pull/954 into mantle code base
16:43:50 <dustymabe> final action item - I know I had a conversation with bgilbert around admin of the mantle codebase but we didn't have a coordinated effort so we might need to re-action
16:44:15 <dustymabe> #action bgilbert, dustymabe, ashcrow, walters, slowrie to discuss maintenance/review structure for mantle
16:44:26 <dustymabe> ok moving on to meeting tickets ?
16:44:40 <dustymabe> well first. one side topic
16:44:52 <bgilbert[1]> .hello bgilbert
16:44:53 <zodbot> bgilbert[1]: bgilbert 'Benjamin Gilbert' <bgilbert@backtick.net>
16:44:54 * dustymabe waves at bgilbert[1]
16:45:03 <dustymabe> #chair bgilbert[1] bgilbert
16:45:03 <zodbot> Current chairs: bgilbert bgilbert[1] dustymabe jbrooks jlebon miabbott mnguyen_ rfairley rishi slowrie walters yzhang
16:45:26 <dustymabe> bgilbert[1]: I re-actioned this item from last meeting: `bgilbert, dustymabe, ashcrow, walters, slowrie to discuss maintenance/review structure for mantle`
16:45:49 <dustymabe> I know we had some side conversations but I don't know if we need a more coordinated effort
16:46:34 <dustymabe> ok moving on to next topic
16:47:00 <dustymabe> #topic high/medium/low priority work items/isues for Fedora CoreOS first release
16:47:09 <bgilbert[1]> yeah, the mantle thing is in process
16:47:35 <dustymabe> So I have started to look at slotting our necessary work for Fedora CoreOS in fedora 30 into weekly/monthly goals
16:47:50 <dustymabe> This morning I came up with a few new items.
16:48:01 <jlebon> dustymabe: nice
16:48:10 <dustymabe> I'd like to ask everyone to take a look at the ones we currently have now and see if anything is missing
16:48:22 <dustymabe> or if there are tickets that exist already that need to be added to a priority label
16:48:43 <ksinny> .hello sinnykumari
16:48:44 <zodbot> ksinny: sinnykumari 'Sinny Kumari' <ksinny@gmail.com>
16:48:51 <dustymabe> #info please everyone take a look at high/medium priority tickets and identify missing items
16:49:03 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues?q=is%3Aissue+is%3Aopen+label%3Apriority%2Fmedium
16:49:08 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues?q=is%3Aissue+is%3Aopen+label%3Apriority%2Fhigh
16:50:06 <dustymabe> #action dustymabe to make timeline for Fedora CoreOS work and share it with the community on the tracker
16:50:36 <dustymabe> I guess this was mostly an FYI unless anyone has any comments
16:51:24 <lorbus_> dustymabe++
16:51:32 <dustymabe> #topic discuss merge of fedora-toolbox and coreos-toolbox efforts
16:51:41 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/90
16:52:39 * rishi looks up
16:53:28 <yzhang> So, from my notes for the existing implementations, it seems that the toolbox's have different flags/mountpoints, base images, build process and sudo/non-sudo needs
16:53:51 <yzhang> I feel like if we do end up merging the two, the "easiest" way seems to be just squashing the two together
16:54:11 <yzhang> i.e. in fedora-toolbox, detect if we're on a *cos system, and if we are, switch to "debug mode"
16:54:19 <yzhang> (run every command slightly differently)
16:54:32 <rishi> yzhang: Yes, that's fine by me.
16:54:38 <yzhang> which... seems kinda ugly but is do-able
16:54:45 <dustymabe> yzhang: what is "debug mode"
16:54:54 <dustymabe> i.e. debug vs dev ?
16:54:54 <yzhang> actually on that note, what would be the use case for fcos?
16:55:12 <rishi> I'd have probably done something myself, but the specific use-cases for CoreOS aren't well known to me.
16:55:31 <bgilbert[1]> do I understand correctly that the question is the toolboxes of CL vs. Fedora*, not Fedora vs. *COS?
16:55:33 <yzhang> dustymabe: yeah, so sudo, mount root, have debug image by default (for rhcos it would be from openshift registry with sosreport etc. built in)
16:56:08 <yzhang> bgilbert[1]: we did do a port from CL->RHCOS, so I think this discussion is Silverblue vs. FCOS vs. RHCOS
16:56:25 <bgilbert[1]> ah, okay
16:56:27 <dustymabe> ok let's bucket these things slightly
16:56:32 <yzhang> the port being: https://github.com/coreos/toolbox/blob/master/rhcos-toolbox
16:56:45 <dustymabe> let's start with Fedora Classic vs Silverblue vs FCOS vs RHCOS
16:56:48 <yzhang> and the silverblue one being: https://github.com/debarshiray/fedora-toolbox
16:56:55 <yzhang> Sure
16:57:04 <dustymabe> so I think we can simplify slightly
16:57:35 <dustymabe> Desktop (Fedora Classic + Silverblue) & Server (FCOS, RHCOS)
16:58:02 <yzhang> Would that be summarizable as "dev" vs. "debug"?
16:58:15 <dustymabe> There is a Fedora Server and Cloud edition so maybe we bucket those into the 2nd bucket
16:58:31 <dustymabe> yzhang: i think so yes.. let me progressively get there
16:58:38 <jlebon> though we should still allow for the opposite use case on each (e.g. "debug" on Silverblue)
16:58:56 <dustymabe> so Desktop (Fedora Workstation + Silverblue) vs Server (Fedora Server, Fedora Cloud, FCOS, RHCOS)
16:59:30 <rishi> *nod*
16:59:33 <dustymabe> so now I think we can simplify into Development (Desktop) vs Debug (Server)
16:59:34 * wa1em lurks
17:00:06 <dustymabe> and I think a proposed simplification we had made was to make Development triggered by non-root user and Debug triggered by root user
17:00:34 <dustymabe> so that we don't have "detect FCOS, do something special", but rather "detect user, do 1 of two things"
17:00:38 <bgilbert[1]> that seems... really non-intuitive
17:00:42 <rishi> dustymabe: Yes, that seemed sensible to me.
17:00:58 <dustymabe> bgilbert[1]: triggering off of user ?
17:01:01 <bgilbert[1]> dustymabe: yeah
17:01:12 <bgilbert[1]> most commands don't behave substantially differently when run root vs. non-root
17:01:14 <dustymabe> bgilbert[1]: what if the tool tells you what it's doing based on your user ?
17:01:22 <rishi> Although, regarding jlebon 's point, is there anything that would prevent the CoreOS toolbox from running with root on a Silverblue system?
17:01:26 <jlebon> or, make it a switch, but just default to a different one on Desktop vs Server
17:01:27 <dustymabe> i.e. detected root user, assuming debug mode
17:01:41 <bgilbert[1]> dustymabe: doesn't help scripts etc.  why not just have a cmdline flag?
17:02:01 <dustymabe> bgilbert[1]: we could do that too, but the "detection" could aid and assume the cmdline flag
17:02:03 <yzhang> The other thing is, I'd assume the user running toolbox in rhcos would be "core"
17:02:14 <bgilbert[1]> jlebon: changing the default will confuse people who use both :-(
17:02:17 <dustymabe> yzhang: why not root ?
17:02:18 <rishi> bgilbert[1]: The command line flag when specified could override the auto-detection.
17:02:33 <rishi> That would help keep scripts predictable, but still aid with typing.
17:02:34 <dustymabe> rishi: right
17:03:00 <jlebon> alternatively, two entrypoints which are just symlinks and key off of $0
17:03:12 <yzhang> dustymabe: the default user you ssh with is "core", I assume it may confuse some admins if they ran that and then it failed since the dev mode doesn't work very well on rhcos
17:03:14 <jlebon> to make it really explicit
17:03:21 <rishi> jlebon: Yeah, or that.
17:03:22 <jlebon> (but still convenient)
17:03:26 <dustymabe> yzhang: sudo toolbox ??
17:03:29 <dustymabe> you would be root
17:03:32 <bgilbert[1]> jlebon: works for me
17:03:48 <rishi> jlebon: That might touch upon the renaming discussion: https://github.com/debarshiray/fedora-toolbox/issues/8
17:04:31 <yzhang> dustymabe: sure I suppose we can document that
17:04:58 <ajeddeloh> .hello2
17:04:59 <zodbot> ajeddeloh: ajeddeloh 'Andrew Jeddeloh' <andrew.jeddeloh@redhat.com>
17:05:19 <dustymabe> bgilbert[1]: so you don't think it would be a good idea to switch mode based on user (but with a nice message explaining that) ?
17:05:27 <yzhang> dustymabe: alternatively we can add a warning or something that says if you're on a rhcos system and not sudo'ing, you shouldn't be?
17:05:35 <dustymabe> part of the point of toolbox is to be able to easily type something and get a sane environment
17:05:55 <bgilbert[1]> dustymabe: I think we'd regret it.
17:05:58 <yzhang> I think a flag would potentially make more sense, just would be slightly harder to use for someone who has never used a rhcos system and wants to see whats wrong
17:06:01 <bgilbert[1]> nice messages are another thing to read / put on the screen
17:06:17 <bgilbert[1]> and people who need to deal with muscle memory on both platforms will just end up always passing the flag
17:06:41 <dustymabe> ok so we need to decide which one is the default then ?
17:06:48 <dustymabe> or we require the user to pass in an option
17:07:26 <bgilbert[1]> default to debug, require developers to pass a flag?
17:07:36 <dustymabe> not sure if I agree with that
17:07:43 <dustymabe> we probably need to think about who would be using it more
17:07:44 <yzhang> set default based on OS type, and override with flag?
17:07:55 <rishi> Question. If we choose the default to be "debug", then would it always be possible to run in "debug" mode as non-root?
17:07:57 <dustymabe> I'd argue developers would be using it more
17:08:09 <dustymabe> but I don't know
17:08:42 <rishi> I don't know either. There's a vague plan to default the Silverblue Terminal to the toolbox.
17:08:42 <yzhang> rishi: good question, for rhcos systems that would be a requirement
17:09:00 <dustymabe> yzhang: what would be a requirement? root ?
17:09:05 <yzhang> yes
17:09:21 <rishi> yzhang: You mean "debug" toolbox should work without root? Right?
17:09:46 <yzhang> rishi: I was thinking that "debug" toolbox would grant root if invoked from non-root user
17:10:02 <yzhang> alternatively, just block debug mode to sudo?
17:10:23 <dustymabe> yeah - we could say --debug (error if not root)
17:10:37 <dustymabe> --debug --force, (are you sure you know what you're doing? OK..)
17:11:04 <rishi> Yeah.
17:11:18 <dustymabe> well. maybe --mode=debug (since debug is a normal argument and people might have expectations there)
17:11:54 <rishi> yzhang: "would grant root if invoked from non-root" ? You mean the toolbox would ask for root credentials and escalate to a real/host root shell?
17:12:25 <yzhang> rishi: yes, so basically the rhcos-toolbox just does everything with "sudo" anyways
17:12:50 <yzhang> so it doesn't check if you're root or not, we assume that on a rhcos system all users should have admin privs
17:13:00 <yzhang> (since normally you wouldn't be ssh'ing in anyways)
17:13:34 <rishi> Otherwise, if you are not root, you get prompted at every step? :)
17:13:39 <dustymabe> yzhang: my personal preference on that is that it wouldn't try to sudo for us, but rather give us a message telling us to run as root
17:13:47 <yzhang> Ok, so to back it up a bit, we're ok with splitting the toolbox into two modes of operations, "debug" and "dev", which may end up having completely different workflows, one major point of discussion now is what to use as default?
17:13:48 <rishi> dustymabe: yes that
17:13:59 <yzhang> dustymabe: yeah we can move to that as well
17:14:06 <yzhang> I'm ok either way
17:14:13 <rishi> Better to error out earlier than block at a prompt where the user might ctrl+c or something.
17:14:32 <bgilbert[1]> rishi: +1
17:14:46 <yzhang> The only thing I would caution against, from a RHCOS (and maybe FCOS) perspective, is to have too many flags for the user to have to set before using
17:14:48 <rishi> The "oh shit" moment where you ran the wrong toolbox and ended up with some weird inconsistent state.
17:15:05 <yzhang> as... that was one of the reqs from ben I think
17:15:19 <yzhang> rishi: alternative, have a cleanup section that nukes everything ;)
17:15:20 <dustymabe> yzhang: i agree - i thought the "detect user" bit might be useful there
17:15:56 <dustymabe> so we have come clear options
17:16:14 <dustymabe> i'll write this up - but one thing I wanted to come back to was this statement from earlier
17:16:40 <dustymabe> yzhang | So, from my notes for the existing implementations, it seems that the toolbox's have different flags/mountpoints, base images, build process and sudo/non-sudo needs
17:17:08 <dustymabe> could we consolidate flags/mountpoints, make base images configurable, and unify build process ?
17:17:20 <dustymabe> we've obviously already been talking about sudo/non-sudo needs
17:17:25 <yzhang> to elaborate a bit more
17:18:01 <yzhang> "build process" I meant by the fedora-toolbox building images on the fly, whereas the rhcos-toolbox wants to use an existing rhel image from openshift registry
17:18:24 <rishi> [ The Silverblue toolbox already has some flags to change images and containers. (there's also a --sudo flag, which probably doesn't do what CoreOS needs) ]
17:18:40 <yzhang> making base images configurable is an option but slightly harder to do on rhcos systems
17:18:58 <yzhang> the existing fedora-toolbox has some flags that is intended to work with dev envrionements
17:19:01 <yzhang> but errors in rhcos
17:19:04 <yzhang> last time I tried
17:19:12 <rishi> yzhang: "the fedora-toolbox building images on the fly" -- you mean the current behaviour of 'fedora-toolbox create' ?
17:19:32 <dustymabe> regarding configurable base images - let's just make it configurable via config file in /etc/ (i.e. you can change the default) and via CLI arg ?
17:19:45 <yzhang> and as for mount points... one option is to have defaults and allow user overrides, but we also cautioned against that when doing the port (I forget where the discussion was)
17:19:57 <yzhang> rishi: yes
17:20:15 <yzhang> but we can probably split that into "image-build" and "container-create" or something like that if you're ok with it
17:20:29 <yzhang> so it's not a major issue, we just likely wouldn't use it in rhcos
17:21:03 <dustymabe> let's chat less about *cos vs Silverblue and more debug vs dev
17:21:06 <rishi> yzhang: Ok. So what 'fedora-toolbox create' does with buildah is tied to Silverblue's objective of blurring the boundary between the host and container.
17:21:15 <rishi> dustymabe: Ok.
17:21:16 <rishi> :)
17:21:19 <yzhang> right sorry :D
17:21:28 <yzhang> s/rhcos/dev/g
17:21:30 <dustymabe> don't be sorry. i'm just trying to get us to think in those terms
17:21:32 <yzhang> debug*
17:21:33 <yzhang> ah
17:21:41 <yzhang> yzhang--
17:21:50 <rishi> So, it takes some OCI image and does some minor customization to suit the user's environment. Things like creating a UID matching $USER and $UID, etc..
17:22:05 <dustymabe> so when fedora-toolbox runs today, will it default to pulling an image from a registry, or building an image locally ?
17:22:15 <rishi> But that's a light tweak on top of the fedora-toolbox image.
17:22:32 <rishi> dustymabe: Pulling registry.fp.o:fedora-toolbox.
17:22:39 <yzhang> right, and debug may need to use a different base image
17:22:42 <yzhang> depending on the system
17:22:48 <dustymabe> yzhang: correct
17:22:55 <rishi> yzhang: dustymabe : So, yes, about the base image.
17:23:09 <dustymabe> so let me see if there is one possible solution
17:23:28 <rishi> I think we can strip the fedora-toolbox image to be a small subset common to both and then do fedora-toolbox-coreos, fedora-toolbox-silverblue, etc.?
17:23:33 <rishi> Or dev, debug?
17:23:45 <dustymabe> there exists and ini file in /etc/  [config.development] [config.debug] where you can override settings for each mode
17:23:57 <dustymabe> base image, mountpoints etc..
17:24:28 <dustymabe> the idea here being.. the user can apply some coniguration and get exactly the `toolbox` command he/she needs
17:24:47 <rishi> *nod*
17:24:53 <dustymabe> for fcos and rhcos we can customize these settings for our users
17:24:58 <yzhang> right
17:25:32 <dustymabe> we could even make the 'mode' default to development or debug
17:25:40 <dustymabe> if we wanted
17:25:44 <rishi> dustymabe: Shouldn't the config have defaults for both modes on all systems? eg., if someone runs the debug mode on Silverblue?
17:25:52 <dustymabe> rishi: it should
17:25:58 <rishi> As in base images, etc..
17:25:58 <rishi> ok
17:26:04 <dustymabe> basically 99% of settings are the same on all systems
17:26:13 <rishi> *nod*
17:26:17 <dustymabe> but there may be some settings a distributor chooses to override
17:26:27 <dustymabe> or a user chooses to override themselves
17:26:33 <yzhang> so to summarize, a lot of customizable configs that should also hopefully work out of the box based on defaults
17:26:43 <rishi> So /etc/toolbox.d/ !
17:26:57 <rishi> yzhang: right
17:27:00 <dustymabe> more or less this allows us to get what each party needs but to re-use the same codebase, which should be better for us in the long run
17:27:12 <dustymabe> rishi: yes, a dropin config file structure would be ideal IMHO
17:27:26 <yzhang> We are definitely making this a lot more complex :p
17:27:35 <yzhang> Not that its a bad thing
17:27:50 <rishi> It might soon outgrow being a shell script.
17:28:07 <dustymabe> yzhang: yeah. I think there is a lot of value in combining efforts though.
17:28:15 <yzhang> Agreed
17:28:20 <dustymabe> and having coreos-toolbox and fedora-toolbox just be `toolbox`
17:28:29 <yzhang> Anyway, sorry for hijacking a large portion of this meeting
17:28:32 <dustymabe> and people don't have to get confused
17:28:51 <rishi> dustymabe: yzhang : One quick thing that we were discussing in Silverblue the other day. Not sure if that's relevant for CoreOS ...
17:29:11 <rishi> Our pitch is that the toolbox lets you hack on OSTree based Fedoras.
17:29:13 <dustymabe> #action dustymabe to summarize discussion of toolboxen in #90
17:29:26 <rishi> Except, once inside the container, you can't really use podman.
17:29:41 <yzhang> I can't really speak very much for FCOS use case
17:29:49 <rishi> So we were considering a bridge that would let you forward such commands to the host.
17:30:00 <yzhang> But for RHCOS that would likely be out of the scope
17:30:07 <rishi> Like you can do from Flatpak containers. "host command"
17:30:14 <dustymabe> rishi: let's pick up that question in #fedora-coreos right after the meeting
17:30:22 <rishi> dustymabe: ok
17:30:25 <dustymabe> #topic open floor
17:30:29 <dustymabe> sorry we are running long
17:30:33 <dustymabe> anyone have anything for open floor ?
17:30:40 <rishi> Not me.
17:30:42 <rishi> :)
17:31:12 <dustymabe> #info we have outlined a strategy for bare metal installer and deliverable artifacts for FCOS in https://github.com/coreos/fedora-coreos-tracker/issues/91
17:31:33 <dustymabe> will try to make progress on proofing those points out in the coming weeks
17:32:24 <dustymabe> ok closing out meeting unless someone had something else for open floor
17:32:47 <dustymabe> #endmeeting