16:29:16 <dustymabe> #startmeeting fedora_coreos_meeting
16:29:16 <zodbot> Meeting started Wed Jan  8 16:29:16 2020 UTC.
16:29:16 <zodbot> This meeting is logged and archived in a public location.
16:29:16 <zodbot> The chair is dustymabe. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:29:16 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:29:16 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:29:20 <dustymabe> #topic roll call
16:29:23 <dustymabe> .hello2
16:29:24 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:29:29 <slowrie> .hello2
16:29:30 <zodbot> slowrie: slowrie 'Stephen Lowrie' <slowrie@redhat.com>
16:30:09 * dustymabe waves at slowrie :)
16:30:18 <bgilbert> .hello2
16:30:19 <zodbot> bgilbert: bgilbert 'Benjamin Gilbert' <bgilbert@backtick.net>
16:30:21 <slowrie> hey dusty, hope you had a good holiday break
16:31:56 <dustymabe> slowrie: I did, got a lot of small things done that I've been meaning to do for a while
16:32:09 <dustymabe> #chair slowrie bgilbert
16:32:09 <zodbot> Current chairs: bgilbert dustymabe slowrie
16:32:18 <ajeddeloh> .hello2
16:32:19 <bgilbert> .chair bgilbert
16:32:19 <zodbot> ajeddeloh: ajeddeloh 'Andrew Jeddeloh' <andrew.jeddeloh@redhat.com>
16:32:23 <zodbot> bgilbert 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:32:33 <dustymabe> #chair ajeddeloh
16:32:33 <zodbot> Current chairs: ajeddeloh bgilbert dustymabe slowrie
16:32:52 <kaeso[m]> .hello lucab
16:32:53 <zodbot> kaeso[m]: lucab 'Luca Bruno' <lucab@redhat.com>
16:32:54 <jlebon> .hello2
16:32:56 <zodbot> jlebon: jlebon 'None' <jonathan@jlebon.com>
16:33:02 <mnguyen_> .hello mnguyen
16:33:03 <zodbot> mnguyen_: mnguyen 'Michael Nguyen' <mnguyen@redhat.com>
16:33:06 <dustymabe> #chair jlebon kaeso[m] mnguyen_
16:33:06 <zodbot> Current chairs: ajeddeloh bgilbert dustymabe jlebon kaeso[m] mnguyen_ slowrie
16:33:09 <jdoss> .hello2 jdoss
16:33:10 <zodbot> jdoss: jdoss 'Joe Doss' <joe@solidadmin.com>
16:33:14 <dustymabe> \o/ jdoss
16:33:15 * jdoss waves
16:33:17 <dustymabe> .hello jdoss
16:33:21 <zodbot> dustymabe: jdoss 'Joe Doss' <joe@solidadmin.com>
16:33:29 * bgilbert blinks
16:33:38 <jlebon> woah
16:33:43 <jlebon> call the press, bgilbert is here
16:33:56 <bgilbert> nooooooo, not the press
16:34:06 <dustymabe> #chair jdoss
16:34:06 <zodbot> Current chairs: ajeddeloh bgilbert dustymabe jdoss jlebon kaeso[m] mnguyen_ slowrie
16:34:08 <jdoss> A bgilbert wink is as good as a nudge to a blind bat.
16:34:13 <slowrie> call the NY housing authority instead :P
16:34:25 <slowrie> You'll get an answer sometime in the next 8 months
16:34:27 <dustymabe> is ksinny around? /me misses ksinny
16:34:50 <dustymabe> honorary chair
16:34:51 <jlebon> she's in another meeting right now
16:34:56 <dustymabe> +1
16:35:07 <dustymabe> #topic Action items from last meeting
16:35:27 <dustymabe> * miabbott to help us get the azure image upload/boot tested
16:35:29 <dustymabe> * jlebon to create a separate issue to track the updates needed to the
16:35:31 <dustymabe> websites for the stable stream
16:35:46 <miabbott> .hello miabbott
16:35:47 <zodbot> miabbott: miabbott 'Micah Abbott' <miabbott@redhat.com>
16:35:53 <dustymabe> well howdy!
16:35:57 <dustymabe> #chair miabbott
16:35:57 <zodbot> Current chairs: ajeddeloh bgilbert dustymabe jdoss jlebon kaeso[m] miabbott mnguyen_ slowrie
16:36:11 <miabbott> sorry, never got to the Azure test before the holiday  :(
16:36:17 <lorbus> .hello2
16:36:18 <zodbot> lorbus: lorbus 'Christian Glombek' <cglombek@redhat.com>
16:36:26 <dustymabe> #chair lorbus
16:36:26 <zodbot> Current chairs: ajeddeloh bgilbert dustymabe jdoss jlebon kaeso[m] lorbus miabbott mnguyen_ slowrie
16:36:42 <dustymabe> miabbott: no worries
16:36:50 <dustymabe> #action miabbott to help us get the azure image upload/boot tested
16:36:56 <dustymabe> jlebon: did you create that ticket?
16:36:58 <jlebon> #info jlebon filed https://github.com/coreos/fedora-coreos-tracker/issues/332 for website updates for stable
16:37:03 <dustymabe> perfect!
16:37:35 <dustymabe> i'll check in with alan and see how that is going
16:38:15 <dustymabe> #topic Create stable stream
16:38:20 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/331
16:38:44 <dustymabe> this topic is mostly left over from last meeting, but I figured it would be good to get a status update from various work items that are in flight
16:39:50 <dustymabe> jlebon: kaeso[m]: anything to mention here that's specifically related to the ticket?
16:39:58 <dustymabe> i have an update, tangential to the ticket
16:40:34 <kaeso[m]> there is a cincinnati ticket in there, it's on my radar for this sprint but it doesn't block the first release (it will need to be done to auto-update to the second one though)
16:40:36 <jlebon> so, we have a stable build. aiming to do a stable "release" this week to sanity check everything before we're actually ready to release what we want
16:40:54 <dustymabe> kaeso[m]: jlebon: +1
16:41:39 <dustymabe> regarding the few other things we'd like to do: I've been working on carrying bgilbert's good work on the installer to completion
16:42:01 <dustymabe> we got the systemd service merged (https://github.com/coreos/coreos-installer/pull/119)
16:42:04 <bgilbert> dustymabe: +1, thanks for picking that up!
16:42:27 <dustymabe> and I've done some work to add a coreos-installer-systemd rpm subpackage to the rpm in fedora
16:42:43 <dustymabe> i'm working through the release process for coreos-installer today (so we'll have a new release to package)
16:42:50 <bgilbert> dustymabe: we need rereview for the main package, no?
16:43:10 <dustymabe> bgilbert: rfairley got it into Fedora as 'rust-coreos-installer'
16:43:17 <bgilbert> rfairley++
16:43:17 <zodbot> bgilbert: Karma for rfairley changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:43:20 <dustymabe> so it went through as a new review and got approved
16:43:39 <dustymabe> The PR to update the (new) rpm is at https://src.fedoraproject.org/rpms/rust-coreos-installer/pull-request/1
16:43:52 <kaeso[m]> is it in F31 too already?
16:44:01 <dustymabe> although I need to push up some local changes to that PR
16:44:22 <dustymabe> kaeso[m]: no, it's only been built for rawhide, but I don't know of any blockers for it being built for f31
16:44:34 <kaeso[m]> ack
16:44:35 <dustymabe> of course, there may be some issues that I don't know about
16:44:37 <dustymabe> :)
16:45:10 <dustymabe> any other updates for things related to stable before we move to the next ticket?
16:46:03 <dustymabe> #topic Add Azure to release and stream metadata
16:46:09 <dustymabe> https://github.com/coreos/fedora-coreos-tracker/issues/325
16:46:43 <dustymabe> so there are a few different artifacts (not just azure) that we are building in the pipeline, but we aren't plumbing all the way through the release process
16:47:05 <dustymabe> anybody around that is able to tweak a few places to get that content included?>
16:47:19 <jlebon> i can take a look
16:48:15 <dustymabe> ok, if anyone else is interested i'm sure jlebon would be a good mentor as well :) please reach out
16:48:37 <dustymabe> next topic?
16:49:19 <dustymabe> #topic FCoS versions are not semvers, unable to leverage them inside of more structured systems
16:49:27 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/338
16:49:34 * dustymabe re-reads the issue
16:50:09 <miabbott> the TL;DR (as i remember it) is that OKD wants to be able to report FCOS versions through their tooling, but it is setup for semver format
16:50:25 <miabbott> it being OKD tooling
16:51:17 <lorbus> is that the case for RHCOS versions already? Can we align them?
16:51:20 <bgilbert> my view on this is: with the current state of the art, it's impossible for releases of a Linux distro to adhere to semver compat guarantees, unless every new release bumps the major.
16:51:44 <miabbott> RHCOS is moving to semver format, but without any semver guarantees
16:51:53 <lorbus> I think the requirement was to be pseudo-semver
16:52:00 <lorbus> for FCOS that is.
16:52:04 <dustymabe> bgilbert: correct.
16:52:15 <bgilbert> if we aren't going to actually use semver, why support being parsed by a semver parser?  FCOS versions aren't intended to be parsed at all; they're for debugging/reporting purposes only.  they're strings.
16:52:54 <bgilbert> the changelog use case has some reason to parse, sure, but we shouldn't restructure our versioning only for that case.
16:53:20 <jlebon> kaeso[m]: i'm curious about the interaction with users that were confused. were they angry at compat breaks that somehow weren't publicized enough?
16:53:29 <lorbus> I believe this is so the version plays well with the rest of OpenShift tooling and the CVO. IIRC the only change need was to replace a dot with a dash or something.
16:53:52 <bgilbert> the .dev case given in the ticket is kind of a red herring
16:54:16 <bgilbert> the relevant part is official releases, which are A.B.C.D
16:54:26 <dustymabe> bgilbert: right
16:54:27 <jlebon> bgilbert: well, they're strings to everyone else, they're parsable to us :)
16:54:34 <bgilbert> jlebon: sure
16:54:35 <lorbus> not sure if Clayton documented the exact reqs anywhere. I can follow that up with him if needed.
16:54:52 <lorbus> (nvmd it is in the ticket)
16:55:14 <dustymabe> official releases used to be A.B.C but we recently implemented our versioning scheme that we wanted which is now A.B.C.D
16:55:15 <kaeso[m]> jlebon: docker had a huge storm at the time of 1.1x.y releases, they eventually switched away to calendars to try to avoid confusion
16:55:35 <jlebon> how do we suggest users perform version ordering for FCOS? would we expose the release index to them?
16:56:03 <kaeso[m]> the release-index is source of ordering Cincinnati uses, yes
16:56:07 <bgilbert> jlebon: what are the cases where they'd need to?  Cincinnati will upgrade them, and otherwise, ?
16:56:14 <kaeso[m]> *the source
16:56:23 <slowrie> Shouldn't they just be using stream metadata if they need to know which to launch and the rest is handled automatically
16:57:02 <jlebon> not necessarily for software on the node itself, but higher level client infra
16:57:19 <kaeso[m]> I think we are having X-Y problem discussion
16:58:07 <jlebon> i'm just evaluating whether "they're strings" should indeed be our stance
16:58:28 <bgilbert> jlebon: yeah, it's a bit more nuanced than that
16:58:35 <bgilbert> we defined versions s.t. version-sort will work
16:58:43 <bgilbert> and I think breaking that would be too confusing
16:58:56 <bgilbert> my point was more that nothing should be taking _action_ based on versions
16:59:13 <kaeso[m]> why is semver specifically being discussed? if it is for ordering, the release-index has that. If it is for compatibility decision, FCOS does not follow that.
16:59:32 <dustymabe> bgilbert: is something taking action based on them? seems like OKD wants to display "what changed" info
16:59:48 <adamw> have you considered QA needs here? it is generally useful to QA if things have some kind of sanely parseable versioning scheme
17:00:19 <adamw> it helps to know what this thing that just came out is, how it relates to other things, identify when a thing broke or changed...
17:00:24 <jdoss> What is QA??
17:00:28 * jdoss hides from adamw
17:00:32 <adamw> .fire jdoss
17:00:32 <zodbot> adamw fires jdoss
17:00:35 <jdoss> ahhhhh
17:00:38 <dustymabe> .hire jdoss
17:00:38 <zodbot> adamw hires jdoss
17:00:41 <bgilbert> woah
17:00:45 <jdoss> whew
17:00:52 <dustymabe> #chair adamw
17:00:52 <zodbot> Current chairs: adamw ajeddeloh bgilbert dustymabe jdoss jlebon kaeso[m] lorbus miabbott mnguyen_ slowrie
17:01:40 <adamw> we don't need it to actually follow semver rules or anything, but something where we can at least know vaguely what the version string indicates and parse 'X is newer than Y' is important
17:01:44 <dustymabe> kaeso[m]: I think semver is being discussed because apparently everything in kube uses the semver format for versioning and they're asking if we can do the same so that display tools will show our OS version differences more easliy
17:01:57 <dustymabe> adamw: yep, you'll definitely have that
17:02:03 <bgilbert> adamw: version-sort will work.  the version numbers actually encode a lot of information about what's going on with the release
17:02:06 <dustymabe> we're not going full git hash on you
17:02:09 <adamw> =)
17:02:09 <dustymabe> :)
17:02:12 <adamw> cool, thanks
17:02:24 <slowrie> git hash versioning is the future
17:02:40 <bgilbert> slowrie: or the past.  hard to tell
17:03:05 <dustymabe> ok, so let's see where we are
17:03:09 <kaeso[m]> I'm not even sure that version-sort always work in all cases, we already started a F31 build and then reverted to F30
17:03:29 <jlanda> that's the king of things that adamw loves :)
17:03:33 <dustymabe> kaeso[m]: but we didn't release the F31 build
17:03:33 <jlanda> s/king/kind
17:03:37 * adamw warms up the firin' script again
17:03:42 <jdoss> lol
17:03:42 <bgilbert> kaeso[m]: but we didn't intend anyone to downgrade 31 -> 30, and I can't imagine we would
17:04:20 <dustymabe> let me make a few statements and see if people agree with them
17:04:32 <dustymabe> 1. OKD is not asking us to comply with semver
17:04:44 <kaeso[m]> right, not officially. That's why sticking to release-index order works better (it doesn't contain aborted builds)
17:04:50 <dustymabe> 2. OKD is asking to see if we can make our versioning fit in the semver format
17:05:12 <bgilbert> for context, the original phrasing was: "Is there a strong reason to have the current version format? Would there be significant opposition to changing to be reported in semver?"
17:05:24 <bgilbert> IMO the answers are yes and yes
17:05:42 <bgilbert> "significant" is hard to define of course
17:05:48 <dustymabe> bgilbert: do you agree with 1. 2. ?
17:06:06 <bgilbert> roughly, yeah
17:06:16 <dustymabe> anyone disagree with 1. 2. ?
17:06:20 <slowrie> FWIW: my opinion would be that if it's as simple as not having a 4th '.' and instead using a '-' I don't really think it matters as long as we clearly state it's not semver
17:06:36 <dustymabe> slowrie: i'm getting there
17:07:03 <dustymabe> so the big question is, considering our current versioning, what do we lose if we move to semver? could we adapt it so that we don't lose any fidelity?
17:07:26 <bgilbert> I don't agree with that
17:08:00 <slowrie> Truly moving to semver would require completely re-designing the versioning. Just following the basic convention to allow it to be parseable but unusable would be a different scenario
17:08:11 <bgilbert> the status quo is the default.  I'd like to see a strong argument why we should switch to a format that we've already agreed isn't a semantic fit for us.
17:08:31 <kaeso[m]> (it doesn't matter if it looks like semver and we clearly state it's not semver: folks are already semver parsing it, so it will be semver)
17:08:39 <bgilbert> kaeso[m]: +1
17:09:36 <dustymabe> who on earth expects semver guarantees from an OS, though
17:09:54 <slowrie> users :)
17:10:07 <jdoss> Exactly why I asked what is QA!
17:10:18 <jdoss> (kidding I love guarantees)
17:10:30 <dustymabe> especially because part of our version is a datestamp
17:10:45 <dustymabe> it's not really an incrementing version
17:11:13 <dustymabe> I just don't think anyone would be confused about expecting semver from an OS just because the version is in semver format
17:11:29 <jdoss> I always find a datestamp version more useful than semver for OS images.
17:11:50 <bgilbert> the last paragraph of https://github.com/coreos/fedora-coreos-tracker/issues/338#issue-540477085 also implies that the reporter already has a workaround
17:13:05 <ajeddeloh> stepping back a bit, it seems like okd shouldn't be forcing it's components into its versioning scheme
17:14:09 <dustymabe> ajeddeloh: probably
17:14:46 <bgilbert> we've reserved the right to change the versioning scheme when bumping the major, so we have an opportunity to revisit every 6 months
17:15:01 <ajeddeloh> fcos doesn't seem like the right place to fix the issue
17:15:04 <bgilbert> I'd propose that we keep the status quo for now, and if it creates really serious problems, we can come back to this
17:16:08 <dustymabe> I think keeping the status quo is fine, but I do keep getting stuck on the "people will expect semver guarantees if it's in semver format"
17:16:16 <dustymabe> I just disagree with that last part
17:16:41 <dustymabe> and who cares if they expect semver, it's a community project and we'll point them at documentation
17:16:44 <jlebon> right, i tend to agree with dustymabe
17:17:17 <bgilbert> people tend to do things.  :-)  I agree that that part may not be a major issue, but I don't think it's the core of the argument either
17:17:56 <jlebon> i totally get the idealistic view of not having a semver format because it's not semver, though at a practical level, given that we do want our versions to be somewhat parseable, ISTM the ability to be leveraged by parsers outweighs possibly confusing a small set of people who somehow expected semver from an OS
17:18:29 <dustymabe> bgilbert: which part is the core of the argument? 1. openshift shouldn't enforce requirements here or 2. we'd lose fidelity by using semver
17:18:45 <bgilbert> jlebon: the versions aren't unparseable or anything.  they just have more than three fields.
17:19:24 <kaeso[m]> dustymabe: fair. But again I've already seen an iteration of this mess, so I don't see the point of voluntarily introducing the confusion.
17:19:26 <jlebon> bgilbert: right, but there's lots of code already out there that knows how to parse semver and compare them
17:21:07 <dustymabe> kaeso[m]: +1 - past experience is always useful
17:21:19 <jlebon> kaeso[m]: for an OS though, or a component software?
17:21:32 <bgilbert> dustymabe: IMO the core of the argument is that we should use a system that works well for FCOS, rather than cramming our worldview into three fields to satisfy a parser whose worldview intentionally involves guarantees we can't meet
17:22:16 <kaeso[m]> jlebon: the latter
17:22:18 <dustymabe> bgilbert: wait wait
17:22:27 <dustymabe> who said we had to use just 3 fields?
17:22:48 <bgilbert> dustymabe: with a side of "OKD may sometimes have to deal with external components that don't use semver"
17:22:52 <bgilbert> dustymabe: ...semver does?
17:23:12 <dustymabe> but what about the -
17:23:16 <dustymabe> x.y.z-foo
17:23:46 <ajeddeloh> Why is it such a problem for okd to have non-semver components
17:24:02 <ajeddeloh> not all software is semver
17:24:03 <dustymabe> ajeddeloh: maybe it's not, we haven't really gone there
17:24:30 <jlebon> whatever we decide, we shouldn't do it just for the benefit of OKD
17:24:40 <jlebon> if it comes at a perceived cost to FCOS
17:24:42 <ajeddeloh> I'd be surprised if fcos is the only non-semver thing that okd encounters
17:24:56 <dustymabe> jlebon: i agree, I wouldn't be having this conversation if we had already put out our first stable release
17:25:31 <bgilbert> dustymabe: ugh, yeah, we could do that.  it violates semver semantics ("pre-release version") but we've already agreed we'd be doing that.
17:25:46 <dustymabe> bgilbert: right
17:25:57 <jlebon> bgilbert: check out this diff: https://github.com/coreos/fedora-coreos-releng-automation/pull/67/files
17:25:58 <dustymabe> i don't think anyone was thinking we'd drop a filed
17:26:01 <dustymabe> field*
17:26:12 <bgilbert> blah
17:26:40 <bgilbert> so everything becomes a "prerelease"
17:27:04 <dustymabe> bgilbert: if you are a person who makes assumptions, yes
17:27:06 <dustymabe> :)
17:27:26 <dustymabe> but if we don't make semver guarantees, then it means whatever we say it means
17:27:27 <jlebon> bgilbert: hmm, it's also used for metadata, no?
17:27:41 <bgilbert> jlebon: that's +
17:27:49 <dustymabe> oh, well + works for me too
17:28:00 <jlebon> yup sure :)
17:28:10 <bgilbert> I agree that that makes the change survivable.  I still don't think we should do it.
17:28:51 <bgilbert> the world is not actually semver and we should push back against the assumption that non-semver-parsable strings are malformed.
17:29:41 <dustymabe> #proposed currently our versioning scheme is just a string with encoded bits of information in it. we'd prefer not to change it at this time but we can revisit this on the next major release of Fedora
17:30:10 <lorbus> Coming from the OKD side of things, I am +1 for this change, as I think we wouldnt loose any info encoded in the version, but have the benefit of being able to parse it using any semver parser, instead of needing another implementation for getting that within OKD.
17:30:50 <dustymabe> does anyone have takes on the current proposal?
17:30:58 <bgilbert> I'm +1 ofc
17:31:01 <jlebon> +1
17:31:16 <lorbus> -1
17:31:17 <dustymabe> OR should we make clear two options and have a more formal vote in the GH ticket?
17:31:18 <ajeddeloh> +1
17:31:20 <kaeso[m]> it's unclear why OKD wants to parse it in the first instance
17:31:26 <jlebon> lorbus: that said, the OS is a bit more special than other OKD components :)
17:31:48 <dustymabe> kaeso[m]: because OKD wants to report information about the OS?
17:32:37 <jlebon> can we ask for more info about the constraints?
17:32:41 <bgilbert> lorbus: does OKD need to be using a semver parser at all?
17:32:51 <dustymabe> jlebon: yes, of course
17:32:55 <bgilbert> lorbus: generic version parsers have existed for a long time
17:33:10 <bgilbert> RPM does it, to name one
17:33:32 <dustymabe> jlebon: would you like to ask for more constraints in the ticket?
17:33:40 <dustymabe> bgilbert: are there any questions for openshift that you'd like to ask?
17:34:30 <bgilbert> just the big one: why is this necessary?  are there reasons that a generic version parser wouldn't be adequate?
17:34:50 <dustymabe> jlebon: maybe you can try to incorporate that in your ask
17:35:05 <dustymabe> for now obviously if we don't change anything then the status quo stays.
17:35:08 <lorbus> jlebon: true :) and I could definitely live with it if it doesn't change. It's just if our only reason for not doing it is that we don't want to give the impression of the version following semver (with it only being formatted like it, i.e. pseudo-semver), I dont see that as a very strong argument.
17:35:48 <dustymabe> lorbus: yeah I think we already arrived at that point
17:36:17 <dustymabe> #action jlebon to ask more about the contstraints in #338
17:36:34 <dustymabe> we'll need to circle on this very soon so keep in mind we have a short timeline
17:37:01 <jlebon> i think it'd be super helpful if we had a case where an OS that followed semver caused confusion
17:37:15 <dustymabe> #info we're leaning towards not changing our currently implemented versioning scheme but will ask for more info in the ticket
17:37:19 <dustymabe> #topic open floor
17:37:25 <dustymabe> jdoss: you have the floor!
17:37:28 <jdoss> Sorry if these are kinda long and sorry Dusty it turned into three questions. I can make tickets to track them or follow existing tickets.
17:37:38 <dustymabe> kk
17:37:40 <jdoss> 1) Has there been any end users using FCOS at home on a home servers for personal testing? If not, I am going to work on setting it up on my server at home and I was planning on writing up a blog post on that process/journey. Is FCOS in a state for this kind of usage? Looking at the coreos-installer it seems like it is ready.
17:37:56 <jdoss> 2) Do we have any kind of plans for a FCOS project blog like we did with Project Atomic? It would be nice to try to rally FCOS end users with better documentation/website/blog on building cool stuff with FCOS.
17:38:15 <jdoss> 3) At work we are pushing forward on using OKD 4.x this quarter and we want to use FCOS on AWS and GCP for our nodes. Have other FCOS users done this successfully and if not, I can dedicate some of work resources to figure out what the end user process for using FCOS and OKD is if you folks feel FCOS with OKD is in a stable state where we can be successful here.
17:38:19 <jdoss> The same kind of blog post offer to socialize the usage of FCOS would apply for this epic quest.
17:38:25 <jdoss> sorry in advance!
17:39:09 <dustymabe> 1) there are users using it at home on home servers for personal testing (I have a canary). It should be in a good state for that kind of usage. The installer is in a bit of a re-work, though. So if you are installing from ISO you'll need to wait a week
17:39:21 <jdoss> +1
17:39:54 <dustymabe> 2) projectatomic was an umbrella project with a blog that we could contribute to. we don't have that for FCOS right now and I'm not sure if we should try to do that or just fold posts into Fedora magazine
17:40:26 <dustymabe> we could create a separate blog site, but would take some effort and people wanting to write content
17:40:58 <jdoss> I just feel it would be awesome to have a focus point for socializing the usage of FCOS. It feels like we are missing that.
17:41:02 <dustymabe> 3) that would be great to talk to lorbus about. there are people using the OKD alpha on FCOS
17:41:34 <jdoss> I am not sure what that would look like but I am willing to help write content but I can't do it alone.
17:41:39 <dustymabe> jdoss: I agree, but we lost our community manager, so we don't have anyone organizing that stuff and us engineers are kinda overloaded :)
17:41:58 <jdoss> +1 bother lorbus about OKD and FCOS got it.
17:42:12 <lorbus> yes! The OKD 4 beta is coming soon, hopefully before DevConf.cz in 2 weeks
17:42:17 <dustymabe> I think it's a great idea to have a site like that, but not much in my tank for it right now
17:42:30 <dustymabe> jdoss: any chance you'll be at devconf.cz?
17:42:36 <jdoss> Fair enough. Maybe something later in 2020.
17:42:44 <dustymabe> all: any other topics for open floor? sorry about the meeting running long
17:42:46 <lorbus> the beta will support all platforms that are supported in OCP right now, including AWS and GCP.
17:42:58 <lorbus> for GCP, you still have to upload the FCOS image yourself manually
17:43:03 <jdoss> lorbus: that is awesome news! Heck yes.
17:43:23 * dustymabe will close out the meeting in ~30seconds
17:43:34 <jdoss> dustymabe: no devconf.cz this year. I burned my conf budget on Kubecon.
17:44:21 <dustymabe> +1
17:44:24 <dustymabe> #endmeeting