16:30:46 <dustymabe> #startmeeting fedora_coreos_meeting
16:30:46 <zodbot> Meeting started Wed Dec 19 16:30:46 2018 UTC.
16:30:46 <zodbot> This meeting is logged and archived in a public location.
16:30:46 <zodbot> The chair is dustymabe. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:30:46 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:30:46 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:30:52 <lorbus> .hello2
16:30:53 <zodbot> lorbus: lorbus 'Christian Glombek' <cglombek@redhat.com>
16:30:53 <slowrie> .hello2
16:30:54 <bgilbert> .hello2
16:30:56 <zodbot> slowrie: slowrie 'Stephen Lowrie' <slowrie@redhat.com>
16:30:59 <zodbot> bgilbert: bgilbert 'Benjamin Gilbert' <bgilbert@backtick.net>
16:31:02 <kaeso> .hello lucab
16:31:03 <zodbot> kaeso: lucab 'Luca Bruno' <lucab@redhat.com>
16:31:05 <jlebon> .hello2
16:31:06 <zodbot> jlebon: jlebon 'None' <jonathan@jlebon.com>
16:31:20 * jlebon will have to leave at noon for another mtg today
16:31:29 <jbrooks> .fas jasonbrooks
16:31:30 <zodbot> jbrooks: jasonbrooks 'Jason Brooks' <jbrooks@redhat.com>
16:31:44 <yzhang> .hello2
16:31:45 <zodbot> yzhang: yzhang 'Yu Qi Zhang' <jzehrarnyg@gmail.com>
16:32:08 <sanja> .hello2
16:32:09 <zodbot> sanja: sanja 'Sanja Bonic' <sanja@redhat.com>
16:32:20 <sayan> .hello sayanchowdhury
16:32:21 <zodbot> sayan: sayanchowdhury 'Sayan Chowdhury' <sayan.chowdhury2012@gmail.com>
16:33:45 <dustymabe> .hello2
16:33:47 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:34:09 <dustymabe> #chair lorbus slowrie bgilbert kaeso jlebon jbrooks yzhang sanja sayan
16:34:09 <zodbot> Current chairs: bgilbert dustymabe jbrooks jlebon kaeso lorbus sanja sayan slowrie yzhang
16:34:21 <dustymabe> what a lovely crowd today
16:34:45 <dustymabe> #topic Action items from last meeting
16:35:06 <dustymabe> * jlebon to ask rpm-software-management org on github about name move of
16:35:08 <dustymabe> rpm-ostree repo
16:35:10 <dustymabe> * bgilbert to get functionality requested in
16:35:12 <dustymabe> https://github.com/coreos/mantle/pull/954 into mantle code base
16:35:14 <dustymabe> * bgilbert, dustymabe, ashcrow, walters, slowrie to discuss
16:35:16 <dustymabe> maintenance/review structure for mantle
16:35:18 <dustymabe> * dustymabe to make timeline for Fedora CoreOS work and share it with
16:35:20 <dustymabe> the community on the tracker
16:35:22 <dustymabe> * dustymabe to summarize discussion of toolboxen in #90
16:35:41 <jlebon> dustymabe: ohh whoops, totally did not do my AI
16:35:46 <dustymabe> jlebon: :)
16:35:56 <dustymabe> #action jlebon to ask rpm-software-management org on github about name move of rpm-ostree repo
16:36:04 <bgilbert> #info mantle functionality merged in https://github.com/coreos/mantle/pull/959
16:36:31 <dustymabe> bgilbert++
16:37:04 <bgilbert> #info we're working on getting more folks spun up on doing mantle reviews
16:37:36 <dustymabe> #info dustymabe summarized toolbox discussion from last meeting in #90
16:37:38 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/90#issuecomment-446688395
16:38:05 <dustymabe> #info dustymabe created roadmap for FCOS in https://github.com/coreos/fedora-coreos-tracker/pull/96
16:38:16 <dustymabe> it still needs some work, as suggested by jlebon
16:38:38 <dustymabe> but it has been a good reality check on the work we have remaining
16:38:57 <jlebon> agreed, thanks for putting that together!
16:39:03 <dustymabe> I'll be moving some things around and pushing up a fixup today
16:39:09 <dustymabe> but please do take a look
16:39:29 <dustymabe> anything else for action items before we move to meeting tickets ?
16:40:32 <dustymabe> #topic Garbage collection policy for OS releases
16:40:39 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/99
16:41:20 <bgilbert> so I don't know what the usual policy is for other Fedora editions
16:41:39 <bgilbert> but we should probably decide, up front, how long the various artifacts will live.
16:41:42 <dustymabe> bgilbert: i don't know if he have an official policy
16:41:53 <dustymabe> might be worth asking releng
16:42:30 <dustymabe> in general i think we've tried to keep shipped artifacts and delete non-shipped artifacts
16:42:44 <bgilbert> I _suspect_ that `updates` packages which have been superseded in a particular Fedora release eventually get GC'd, but I don't know
16:43:04 <dustymabe> right. so bodhi creates yum repos every day
16:43:21 <dustymabe> I think it keeps about 2 weeks worth of them
16:43:51 <dustymabe> but if there isn't a new version of a package then it gets added to the yum repo every day
16:43:59 <dustymabe> so it is persisted that way
16:44:14 <kaeso> bgilbert: out of curiosity, why/when are CL images garbage-collected on GCE?
16:44:19 <dustymabe> if there *is* a new version of a package - then the old version of the package will eventually get GCd
16:44:42 <bgilbert> kaeso: `plume release` does it.  I'm not sure why.
16:45:19 <bgilbert> for FCOS, I'd love it if no one ever stayed on an old release, but I don't think we can assume that :-/
16:45:31 <dustymabe> right
16:45:49 <bgilbert> so debuginfo etc. should continue to be available for those releases.
16:45:57 <bgilbert> I'm okay removing them from the mirror network
16:46:09 <bgilbert> if we want to have an archive server somewhere, similar to what Debian does for old releases
16:46:34 <dustymabe> since for FCOS we are getting a little more 'time based' and blurring the line between major releases we could just say we'll delete stuff that is X years old
16:46:45 <bgilbert> alternatively, we could have an explicit policy that old binaries don't live for more than X time (1 year?)
16:46:49 <bgilbert> yeah
16:47:19 <dustymabe> i honestly like keeping old versions of things around, not because I want to use it, but for investigative purposes
16:47:43 <dustymabe> it's really useful sometimes to look at old versions of things to see if the behavior was there then or not
16:47:50 <dustymabe> or to find when a behavior was introduced
16:48:03 <dustymabe> but in practice it's not that useful for much else IMHO
16:48:36 <bgilbert> if we delete all of a release's artifacts at once, including install images, we'll discover that someone hardcoded the use of a particular old install image
16:48:59 <kaeso> indeed
16:49:05 <dustymabe> yeah. generally the process should be to remove access, and then (after some time) delete
16:49:35 <dustymabe> we've done this with AMIs in the past sayan, correct me if I'm wrong
16:49:59 <dustymabe> bgilbert: so. can we safely say something like this
16:50:03 <bgilbert> and in fact, CL GCE image GC has this gem: https://github.com/coreos/mantle/blob/a0b9148227da85a25716833049a7f9ff46445200/cmd/plume/release.go#L301-L306
16:50:31 <jlebon> that's hilarious
16:50:42 <dustymabe> 1. we will not make an effort to keep "development" artifacts for any extended period of time
16:51:17 <dustymabe> 2. we will try to keep non "development" artifacts for X years (or Y months) - time based
16:52:24 <bgilbert> dustymabe: if we have a policy, it should be stronger than "try" :-)
16:52:40 <bgilbert> I mostly wanted to raise this here to see whether folks had opinions about what the policy should be
16:52:43 <dustymabe> agree ~try~
16:53:01 <bgilbert> I think the next step is a conversation with releng to see what's done now and what the technical constraints are
16:53:13 <bgilbert> (done now == in other editions)
16:53:25 <dustymabe> bgilbert: +1
16:53:31 <dustymabe> I can ask mohan to weigh in
16:53:35 <kaeso> I'm on the side of "keeping images forever". Except for storage cost, is there a problem with that?
16:53:49 <sayan> kaeso: cost is the problem
16:53:50 <dustymabe> kaeso: unforunately there is a problem there
16:54:08 <dustymabe> it sounds "easy" but it isn't
16:54:13 <dustymabe> some background
16:54:35 <dustymabe> fedora infra/releng uses a netapp appliance that has a support contract and provides backups for us
16:54:48 <dustymabe> it has a limited capacity and they shuffle things around periodicially
16:54:56 <kaeso> (I'm fine with a link and a RTFM, if we want to cut this quicker)
16:55:05 <dustymabe> no no it's fine. i'm almost done
16:55:12 <kaeso> :)
16:55:23 <dustymabe> so.. for infra today we are under those constraints
16:55:34 <dustymabe> but there is nothing that prevents us from doing what benjamin suggested earlier
16:55:43 <dustymabe> regarding an archive server that is hosted on s3
16:55:54 <dustymabe> and that's where we can put artifacts that we want to keep longer
16:56:02 <dustymabe> and then we free it up from the fedora infra/constraint
16:56:15 <dustymabe> so we'd have to do a little bit of work there, but I think we can solve the problem
16:56:22 <dustymabe> EOM
16:56:30 <kaeso> ack
16:56:52 <dustymabe> bgilbert: do you mind me adding 1/2 from earlier to the ticket and also reach out to releng for input
16:57:01 <kaeso> and using *only* the bucket for all artifacts, so no netapp involved at all?
16:57:36 <dustymabe> kaeso: my proposal included just using it for the 'archive'
16:57:37 <kaeso> (I guess a bit of a lock-in factor problem)
16:57:46 <dustymabe> but we can talk about it possibly
16:58:08 <bgilbert> dustymabe: +1.  could you add the archive-server option also?  I'd like us to explore the infinite option a bit more
16:58:18 <dustymabe> +1
16:58:19 <dustymabe> will do
16:58:30 <kaeso> dustymabe: I think that's what CL does nowadays, with images on gcloud buckets
16:58:35 <dustymabe> #action dusty to summarize GC discussion here today in #99
16:58:42 <dustymabe> #undo
16:58:42 <zodbot> Removing item from minutes: ACTION by dustymabe at 16:58:35 : dusty to summarize GC discussion here today in #99
16:58:49 <dustymabe> #action dustymabe to summarize GC discussion here today in #99
16:59:02 <dustymabe> #topic Firewall Management
16:59:12 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/26
16:59:17 <bgilbert> it'd be nice to not have to _move_ artifacts, but I guess we won't want to allow evading the mirror network for things that it's still hosting
16:59:23 <kaeso> #action lucab to check/document why CL images are garbage-collected on gcloud
16:59:41 <sanja> bringing it up to Fedora and changing the part isn't an option?
16:59:44 <dustymabe> kaeso: posted up a nice summary in the ticket for #26
17:00:28 <kaeso> dustymabe: you tldr is accurate (sorry for the wall of text :)
17:00:34 <dustymabe> np
17:01:14 <dustymabe> is anyone opposed to using kaeso suggestion for the firewall strategy for FCOS ?
17:02:02 <kaeso> if somebody really really like firewalld, it would be nice to experiment running it with podman or portablectl
17:02:13 <kaeso> *likes
17:03:10 <dustymabe> yes. I actually think portable services might be the answer to some of our problems in the future
17:03:20 <dustymabe> :)
17:03:53 <dustymabe> walters: jlebon slowrie sayan jbrooks ^^ any thoughts on the strategy summarized in https://github.com/coreos/fedora-coreos-tracker/issues/26#issuecomment-448347340
17:04:47 <jbrooks> seems good
17:05:21 <dustymabe> the one place where the current strategy differs than what we currently do in Fedora Atomic Host is the lack of firewall on bare metal nodes
17:05:47 <dustymabe> for cloud I think we don't have a firewall setup, but I think we do for nodes installed via ISO (typically bare metal nodes)
17:06:04 <slowrie> works for me
17:06:14 <dustymabe> so that might be something we need to call out in documentation
17:06:32 <dustymabe> everyone please add thoughts to the ticket (or thumbsup emoji) :)
17:07:17 <dustymabe> will wait a minute and then move to open floor unless someone has anything else to add
17:07:40 <dustymabe> actually. I'll ask two more questions
17:07:56 <dustymabe> 1 - luca can we open a PR to the design doc for this?
17:08:19 <dustymabe> 2 - is there anything we need to add to FCOS to deliver on the strategy as outlined
17:09:38 <lorbus> dustymabe: maybe just explicitly: Document everything in a fcos-docs repo
17:10:05 <lorbus> but this is more of an epic, not just for fw mgmt
17:10:23 <dustymabe> lorbus: i feel like we'll probably pull some docs from our design document, right ?
17:10:42 <dustymabe> did we lose kaeso ?
17:10:56 <lorbus> yup that sounds good to me
17:10:57 <kaeso> multitasking, sorry
17:11:04 <dustymabe> np. do you mind checking out 1/2 above?
17:11:48 <lorbus> I have one docs related thing for open floor
17:12:03 * lorbus holds his feet still for a sec while luca catches up
17:12:26 <dustymabe> will move on
17:12:30 <dustymabe> #topic open floor
17:12:52 <lorbus> there is a poll going on over at discourse:
17:12:52 <dustymabe> lorbus: all you
17:12:53 <lorbus> https://discussion.fedoraproject.org/t/move-docs-sources-and-issues-to-github-redirect-subdomain-to-spins-website/799
17:13:21 <lorbus> #info poll on where to move Silverblue docs
17:13:32 <sanja> uh i like that topic
17:13:33 <lorbus> #link https://discussion.fedoraproject.org/t/move-docs-sources-and-issues-to-github-redirect-subdomain-to-spins-website/799
17:13:52 <jbrooks> do we cover silverblue here?
17:13:53 <lorbus> \o/ sanja!
17:14:28 <lorbus> as we don't have our docs repo, yet. we may want to follow that closely to gauge the community
17:14:35 <sanja> it's related to coreos as well jbrooks, if there's something bigger going on for silverblue, doesn't hurt to mention it - especially since fcos isn't released yet and lots of people are waiting for it, silverblue users etc
17:14:38 * miabbott perks up
17:14:48 <sanja> we do have a docs repo we're just not using it yet - but it's on pagure
17:14:56 <sanja> although if silverblue moves to github, so will coreos
17:15:04 <sanja> without another poll because the poll for coreos has already happened
17:15:15 <sanja> and the docs are only on pagure because there was a rule from fedora for me to have the docs on pagure
17:15:19 <sanja> which is not there anymore
17:15:20 <lorbus> we recently created the Fedora Container docs (wip) at https://docs.fedoraproject.org/en-US/containers/
17:15:31 <sanja> yep lorbus++ for that
17:15:38 <lorbus> which I'd like to live in the same place as FCOS's and Silverblue's
17:16:06 <lorbus> lots of potential overlap there, will need some editorial
17:16:15 <sanja> good point
17:17:02 <sanja> let's see how the vote turns out
17:17:05 <dustymabe> thanks lorbus for linking us to that
17:17:14 <dustymabe> any other topics for open floor ?
17:17:15 <sanja> and then discuss further points on the containers side once it's on
17:17:18 <sanja> thanks
17:17:37 <jbrooks> I don't see why we'd not use github for coreos docs
17:17:45 <jbrooks> Since we're already using it
17:17:55 <sanja> jbrooks as I said - because i wasn't "allowed" to
17:18:03 <sanja> and we wanted to host them within the official fedora docs
17:18:09 <jbrooks> sanja, But you said that's changed?
17:18:15 <sanja> so they gave me the restriction that i had to host the docs on pagure
17:18:17 <sanja> yes, it's changed
17:18:30 <sanja> so we're free to have the repo where we like (in this case github for sure for coreos)
17:18:36 <sanja> but it's still going to be the official fedora docs
17:18:44 <sanja> they'll link it from github to weave in with antorra
17:19:06 <sanja> because that restriction fell off, I initiated the github (or gitlab if the community decides so) move for silverblue as well now
17:19:15 <lorbus> I think the move to GitHub is best for user/dev engagement
17:19:30 <lorbus> so +1 to sanja's plan there
17:20:02 <sanja> walters has linked an article on his blog about that as well in the thread, good article about why rpm-ostree is on github
17:20:40 <sanja> any other questions regarding this topic or moving on to next topic/end?
17:20:56 <dustymabe> any other topics for open floor?
17:21:20 <dustymabe> will close out meeting in 1 minute
17:21:37 <lorbus> I'll try to round up all interested parties for a docs discussion next year
17:22:38 <dustymabe> #endmeeting