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