17:01:32 #startmeeting fedora_atomic_wg 17:01:32 Meeting started Wed Nov 1 17:01:32 2017 UTC. The chair is dustymabe. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:32 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:01:32 The meeting name has been set to 'fedora_atomic_wg' 17:01:40 .hello 17:01:40 ttomecek: (hello ) -- Alias for "hellomynameis $1". 17:01:44 .hello smilner 17:01:45 ashcrow: smilner 'None' 17:01:47 .hello 17:01:51 imcleod: (hello ) -- Alias for "hellomynameis $1". 17:01:56 .hello2 17:01:57 ttomecek: ttomecek 'Tomas Tomecek' 17:02:05 .hello sinnykumari 17:02:06 ksinny: sinnykumari 'Sinny Kumari' 17:02:08 .hello2 17:02:10 puiterwijk: puiterwijk 'Patrick "マルタインアンドレアス" Uiterwijk' 17:02:16 .hello imcleod 17:02:18 imcleod: imcleod 'Ian McLeod' 17:02:53 .hello2 17:02:54 dustymabe: dustymabe 'Dusty Mabe' 17:03:00 .hello2 17:03:01 maxamillion: maxamillion 'Adam Miller' 17:03:03 ttomecek: hiya :) 17:03:19 .hello jasonbrooks 17:03:20 jbrooks: jasonbrooks 'Jason Brooks' 17:03:21 puiterwijk: welcome! 17:03:40 dustymabe: heh, thanks. I decided to hop by for once again after skipping out so often 17:03:57 .hellomynameis kushal 17:03:58 kushal: kushal 'Kushal Das' 17:04:05 puiterwijk: no problem, thank you 17:04:09 kushal: welcome 17:04:39 #chair ttomecek ashcrow imcleod ttomecek ksinny puiterwijk maxamillion jbrooks puiterwijk kushal 17:04:39 Current chairs: ashcrow dustymabe imcleod jbrooks ksinny kushal maxamillion puiterwijk ttomecek 17:05:48 ok will start with a few announcements 17:05:57 #topic new meeting time 17:06:28 #info our meeting time next week will be 16:30 UTC (11:30 EST / 18:30 CEST / 22:00 IST) 17:06:41 This was decided in ticket https://pagure.io/atomic-wg/issue/346 17:06:51 #link https://pagure.io/atomic-wg/issue/346#comment-474667 17:07:06 those times should be the updated times considering daylight savings time 17:07:07 +1 17:07:11 let me know if I'm wrong 17:07:35 DST-- 17:07:50 oh yeah, DST is silly 17:07:58 puiterwijk: yes, it is a sad time of year for me. Loss of daylight in evening is barbaric 17:08:10 but super useful in some jobs I'm sure 17:08:45 dustymabe: not anymore, I have family in the agriculture industry and they say it's a become a myth these days because of modern tech 17:08:53 maxamillion: yup 17:08:56 either way - we'll move on to the next announcement :) 17:09:03 dustymabe: +1 17:09:09 #topic last f26AH release was yesterday 17:09:27 #info The last f26AH release was yesterday 10/31. Future releases will be based on Fedora 27 17:09:36 this should match expectations 17:09:44 any suprises here? 17:09:56 not I 17:09:57 Sounds good to me 17:10:31 cool 17:10:31 Good evening 17:10:35 kurushiyama: welcome 17:10:41 sweet 17:10:44 kurushiyama: do you have a fedora account? 17:10:47 Thank you, Sir! 17:11:00 Not yet. I can set one up, I guess. 17:11:08 if you have one now (or in the future) you can identify yourself like this: 17:11:13 .hello dustymabe 17:11:14 dustymabe: dustymabe 'Dusty Mabe' 17:11:21 just a note for the future :) 17:11:39 just FYI everyone kurushiyama is a user of atomic. I asked kurushiyama to join us 17:11:48 ok moving on to previous meeting action items 17:11:51 Awesome! Welcome kurushiyama! 17:12:01 #topic previous meeting action items 17:12:03 kurushiyama: Hello and welcome! 17:12:30 i'll do my two AI first 17:12:36 * dustymabe to broadcast out new meeting time 17:12:43 .hello davdunc 17:12:44 davdunc: davdunc 'David Duncan' 17:12:56 I'll do that right after this meeting is over. Didn't want to do it before the meeting so as to not confuse anyone on the time for today's meeting 17:13:03 * dustymabe to schedule container-runtimes meeting 17:13:24 we are going to try to have some discussions around crio and docker in AH in the coming weeks 17:13:30 ashcrow has volunteered to run those meetings 17:13:36 i'm going to re-assign my AI to him for now 17:13:39 +1 17:13:54 #action ashcrow to schedule container-runtimes meetings for discussions around cri-o/docker 17:14:08 ok other action items 17:14:10 * jberkus to find place to host editable dockerfiles/readmes for 17:14:12 container submissions 17:14:14 * davdunc to verify whether we're required to use bugzilla for container 17:14:16 submissions 17:14:18 * jbrooks jberkus to test asciibinder rpm 17:14:20 * strigazi jbrooks to document the steps they took for f27 kube upgrade 17:14:53 I haven't done mine yet 17:15:47 * davdunc found no blockers to moving away from bugzilla 17:15:51 jbrooks: for both items? 17:16:39 davdunc: that's good news! 17:16:45 seems as if jberkus is not around 17:16:46 dustymabe, Yeah, I haven't looked at asciibinder at all, and have been working on getting the f27 system containers to test w/ 17:17:00 jbrooks: 10-4 17:17:08 #action jbrooks jberkus to test asciibinder rpm 17:17:16 #action strigazi jbrooks to document the steps they took for f27 kube upgrade 17:17:18 I went directly to RH PMs to ensure we weren't breaking any analytics. 17:17:48 I'll be honest, I don't think RH PMs are a Fedora concern 17:17:57 First of all: Thank you for the invitation and the warm welcome. So that you understand our usage of Atomic: We are a company providing cyber security from layer 1-4 for quite some names and we are using Atomic (RHEL7), Ansible and docker swarm in our cluster. 17:18:01 I'd be more curious about what the Council and FESCo think of it 17:18:04 jbrooks: the documentation for f27 kube stuff is probably going to be important we get that done sooner than later because I'll link to it from one of the posts I am doing 17:18:39 kurushiyama: cool deal 17:18:41 maxamillion: I did include mattdm in my inquiry. 17:18:46 ok one final action item 17:18:52 * Open a ticket to write a blogpost on mutli-arch enablement in F27 17:18:54 Atomic 17:18:58 i think that was for ksinny 17:19:00 davdunc: cool cool 17:19:33 dustymabe: created one at https://pagure.io/atomic-wg/issue/369 . Also Sent PR for post https://github.com/projectatomic/atomic-site/pull/483 17:20:48 #info ksinny opened atomic-wg ticket #369 for mutli-arch blog post 17:21:08 dustymabe: thx 17:21:10 ok let's move to meeting agenda items 17:21:36 #topic proposal to include firewalld in atomic host 17:21:42 #link https://pagure.io/atomic-wg/issue/372 17:22:03 If I may say something about this proposal? 17:22:10 I just created this ticket an hour ago. TL;DR we'd like to include firewalld in atomic host 17:22:12 kurushiyama: sure 17:22:45 kurushiyama: by all means, please do :) 17:23:29 Ok, a bit more detail about our usage first: We provide services for companies which require us to hold a certificate of the BSI (Bundesamt für Sicherheit in der Informationstechnik, Federal Agency for IT Security). 17:23:55 And one of their requirements is actually a multi stage firewall concept. 17:25:04 We had quite a hard time explaining to them why Atomic does not come with an included firewall. Actually, the fact that RHEL is a BSI certified Linux kind of depends on the fact that a firewall is included. 17:25:06 kurushiyama: in short, does that mean firewalld would help you? 17:25:21 Absolutely. 17:25:28 Well, do note that a firewall is still included in the form of iptables 17:25:33 Just not firewalld 17:25:33 kurushiyama: well atomic has the same firewall linux has used forever, iptables 17:25:36 But I guess it is important to explain why. 17:25:37 And, to clarify, the use of iptables isn't enough for the use case? 17:25:58 @puiterwijk Try to explain that to a government official... ;) 17:26:10 kurushiyama: well, iptables is the actual firewall anyway.... :) 17:26:10 kurushiyama: LOL. Good point :-) 17:26:16 firewalld is just a management layer on top of iptables 17:26:17 ashcrow We are _not_ talking of technical requirements. 17:26:38 It is more of a documentation issue. 17:26:44 I see 17:26:51 Kind of like a "check box" type of thing? 17:27:46 ashcrow Sorta. Aside from the fact that I'd love to have firewalld included so that it would be a bit easier to limit access to resources than to fiddle with iptables. 17:27:49 ehh theoretically iptables should be able to click the "check box" too, but if having something called firewalld would help, I'm for it 17:27:58 * davdunc is ducking out. I have LISA booth duty training now. 17:28:07 kurushiyama: yes, that is my main reasoning 17:28:10 davdunc: have fun! 17:28:20 davdunc: talk to people about atomic host! 17:28:25 will do. 17:28:31 dustymabe: yeah, it's easier to convince non technical folks that firewalld is firewall management while iptables (the actual firewall tech) sounds like something else. 17:28:42 dustymabe: we could rename the iptables(8) CLI to firewallctl? :P 17:28:53 :) 17:28:54 mv /bin/iptables /bin/firewallctl <- done! 17:29:04 puiterwijk :D 17:29:14 And you can even do full backwards compat by just "ln -s" instead! 17:29:17 kurushiyama: Thanks for bringing that up. That block never occured to me. 17:29:24 yeah either way I think our technical reasons for wanting to include firewalld are compelling as well 17:29:38 puiterwijk: oh man, that'd be ... rough 17:29:48 can everyone add their opinion in the ticket (including a +1 or -1 based on preference?) 17:29:51 well, my blog runs on atomic. On DO. Without firewall... ;) 17:30:02 The only downside I see to adding it is the size added to the image. However, I have a feeling it won't add as much as I assume it does. 17:30:05 we'll give people who aren't here time to chime in and then probably decide next meeting 17:30:06 dustymabe: good idea, will do. 17:30:43 maxamillion: well, as said, we can be fully backwards compatible by just linking! It'd be so fun! :D 17:30:51 #info don't see any major objections to the idea from meeting attendees today. Will wait a week for people to weigh in on the ticket. 17:31:15 #topic Overhaul list of members, Quorum Rules 17:31:21 #link https://pagure.io/atomic-wg/issue/363 17:31:39 this was proposed by jberkus, he isn't here today 17:32:26 mostly we need to make a more formal structure for making decisions within this working group 17:32:32 My Fedora account is not processed, yet, but I will gladly provide the explanation why it is necessary or at least helpful for security certifications. 17:33:00 we've mostly done lazy concensus so far and we haven't had any hard formal requirements for group members 17:33:13 this ticket aims to more clearly define things 17:33:24 please read the ticket and comment there 17:33:43 kurushiyama: yes please do that if we have time at the end of the meeting in open floor 17:33:56 sure 17:34:04 anyone have anything they want to say on the current topic? 17:34:51 Nothing from me 17:35:01 ok 17:35:03 moving on 17:35:04 I will add something to the ticket. 17:35:11 #topic Overhaul list of members, Quorum Rules 17:35:16 sigh :) 17:35:23 #topic Fedora Docker Images on Docker Hub 17:35:28 #link https://pagure.io/atomic-wg/issue/362 17:35:50 i think we've mostly got agreement in the ticket 17:35:59 dustymabe: very, very strong +1 on nuking and startover from me 17:36:19 #info agreed that we will clear out all images on docker hub under the fedora organization and start fresh 17:36:25 I looked at some of the images on the Fedora space.... They did not make me happy :) 17:36:26 any opposition? 17:36:35 nope 17:36:39 just need to get around to doing it 17:36:55 (note: I'm not an Atomic WG member. This is just my personal opinion as someone who values security) 17:37:09 +1 on nuke 17:37:25 maxamillion: should we convert this ticket into an actionable task to actually do the removal? 17:37:38 Hm, which means that images based on the shasums will be broken 17:37:42 or should we open a new ticket for that? 17:37:55 dustymabe: yeah, make it actionable and assign it to me 17:38:16 kurushiyama: correct. All the hub.docker.io/fedora/* (not the /_/fedora, which is hub.docker.io/fedora:25, those are fine), will be removed 17:38:17 kurushiyama: not sure I understand the question? maybe maxamillion does 17:38:35 thanks puiterwijk 17:38:53 kurushiyama: however, docker hub will likely not remove the bases of any pushed images, so images on the hub that are based on the Fedora images will still work (we can't control that) 17:39:15 that's fine IMHO 17:39:26 prevents at least any future images from getting built 17:39:31 Yep 17:39:38 I guess we should either make sure or make a public announcement, then. 17:40:14 kurushiyama: that's not a bad idea 17:40:22 maxamillion: ^^ can you handle that? 17:40:40 i.e. announce what we are doing with respect to images on docker hub 17:40:52 There's not much to "make sure" - I can guarantee you that all images that have a "FROM fedora/...." *will* break 17:40:56 dustymabe: yeah, I can announce it and then remove them after some time 17:41:05 (note again: "FROM fedora:" will *not* break) 17:41:09 puiterwijk: yes, they will break during builds 17:41:11 puiterwijk: +1 17:41:21 but images that already have been built and are uploaded will work fine 17:41:29 dustymabe: yeah, just trying to make things clear, since there's two different image series that look almost the same :) 17:41:32 Correct 17:41:36 indeed 17:42:06 #action maxamillion to announce to the world that we are planning to remove fedora docker layered images from docker hub and start fresh 17:42:09 good deal 17:42:16 moving to next topic ..... 17:42:47 #topic help.md file for each container 17:42:52 #link https://pagure.io/atomic-wg/issue/354 17:43:02 jberkus tagged this with meeting tag 17:43:25 ttomecek: can you provide us a summary? 17:44:22 * dustymabe thinks we may have lost ttomecek 17:45:10 :-) 17:45:24 maxamillion: opinions? 17:45:57 Quickly looking at the proposal I like the idea of having a standard help file/format for containers 17:46:25 yeah I think we already do. I think tomas was saying that right now it's ambiguous 17:46:45 we mention it in two different places and it's not clear if it's required or not 17:47:20 dustymabe: it's a good idea 17:47:26 I like it for the most part 17:48:24 maxamillion: don't we already require a help file? 17:48:38 what is being proposed that is different from what we already do? 17:48:50 oh, I misunderstood them 17:48:52 then* 17:49:21 I was thinking this would replace the helpfile but me more complete 17:49:39 I think the difference is this proposal adds specific required sections/fields 17:50:01 .hello mwmahlberg 17:50:03 kurushiyama: mwmahlberg 'Markus Wolfgang Mahlberg' 17:50:18 or at least in a specific format (as defined in the proposal) 17:50:21 ashcrow: that's fine with me 17:50:57 the original Fedora proposal is a bit more open ended and can be one of two files 17:51:12 I'll try to add a question or two to the ticket 17:51:18 ashcrow: unless you want to? 17:51:32 basically would be nice to not let this one sit 17:52:22 ok moving on for now 17:52:35 #topic open floor 17:52:46 ksinny: any updates from multi-arch side of the house? 17:52:47 dustymabe: agreed I'll follow up with it on the ticket 17:52:48 nothing here 17:53:11 does anyone have any multi-arch hardware they'd like to start using atomic host on? 17:53:30 @dustymabe Fedora account ready, contributor agreement signed. 17:53:35 masta: ^^ ? 17:53:48 kurushiyama: welcome :) 17:54:01 kurushiyama: did you want to chat more about the requirements now that we are in open floor 17:54:27 If you are interested. I do not want to bore you guys ;) 17:54:31 dustymabe: F27 latest nightly composes has successful Atomic cloudImages and ISOs for aarch64 and ppc64le. They are running fine as well :) 17:55:04 @dustymabe ^ 17:55:26 dustymabe: personally, I think that if we're going to ship multi-arch Atomic Host, we should make sure that those different arches also get tested the same way as x86_64 17:55:38 kurushiyama: in that case maybe we can chat in #atomic after the meeting 17:56:00 dustymabe At your command ;) 17:56:09 puiterwijk: yeah that is a gap 17:56:15 dustymabe: and yes, I totally realize that that is really difficult, and we might not have the hardware. 17:56:37 But I'd suggest that if we cannot test them, we ship them as "alternate" deliverables, with a warning label on the download page 17:56:54 puiterwijk: well at this moment we don't have any plans to update the actual website 17:56:59 although maybe we should 17:57:04 we just haven't thought of it 17:57:12 * ksinny thinks Fedora Atomic CI will good place to have Atomic Host tested on available arches 17:57:16 That's totally fair. Just wanted to point it out 17:57:28 first step was going to be updating the release script to be able to support multi-arch 17:57:42 and thus the text in the email that gets sent out would be updated accordingly 17:58:00 Right. 17:58:02 we could add text in that email to say that these trees haven't been tested in the same way as x86_64 17:58:04 WDYT? 17:58:08 Yep. 17:58:14 ok 17:58:21 Well, maybe "not as extensively as x86_64" rather than "not in the same way" 17:58:38 FYI I opened a ticket for this: https://pagure.io/atomic-wg/issue/362 17:58:42 sigh 17:58:44 wrong link 17:58:45 Since it's not just "not the same way", it's also "way less" (for now, until ksinny can give us all the hardware! :) ) 17:58:47 https://pagure.io/atomic-wg/issue/371 17:59:04 puiterwijk: yep 17:59:10 puiterwijk: haha, I too test on vm :D 17:59:44 dustymabe: if we can get the software updated/written for it, we could do ppc64(le) testing in the FICloud (openstack). 17:59:49 as ksinny stated, i'm hoping that migrating from the autocloud setup and moving towards fedora CI (as discussed in https://pagure.io/atomic-wg/issue/361) will give us multi-arch support too 18:00:09 Okay. I see you have better plans than I do. 18:00:19 puiterwijk: :) well - hopefully 18:00:25 puiterwijk: But, yeah. I can talk with my team if we can have some additional public hardware for tetsing Fedora Atomic host 18:00:32 we still need to do it :) 18:00:43 but we should make it a priority 18:00:50 +1 18:00:52 dustymabe: One question, Where exactly offcial Atomic Host images will be published for aarch64 and ppc64le? 18:01:03 * ashcrow has to run to another meeting 18:01:15 ksinny: at first mostly they will be links in the email we send out 18:01:28 we'll need to figure out a strategy for how/where to host them on our website 18:01:36 dustymabe: sure 18:01:42 and how to get that updated automatically like we do for x86_64 atomic 18:01:47 when we do a new release 18:01:53 right 18:01:55 * dustymabe needs to open more tickets :) 18:02:03 ksinny: how are your web skillz?? :) 18:02:19 * dustymabe looks at the time 18:02:28 dustymabe: So, all arches will follow bi-weekly update, right? 18:02:28 will close the meeting in 2 minuts 18:02:35 ksinny: that's the plan 18:02:39 cool 18:02:52 ksinny: how are your web skillz?? :) 18:02:53 dustymabe: I am assuming that we'd be shipping the same day's image for all arches? 18:02:55 i guess we could have alt arches actually just get updates and not have official releases 18:03:07 Not much I would say 18:03:11 puiterwijk: yeah, that would be preferable 18:03:23 Aka, the ref would (obviously) be different, but the image "generation" should be the same? 18:03:35 the ref would always be different 18:03:39 dustymabe: personally, I would call that a "requirement". But that might be me 18:03:49 dustymabe: will be interested to hear for what you have asked. maybe, I can try and learn while doing 18:03:54 the version 'should' be the same assuming we get the 'smart versioning' set up 18:04:23 puiterwijk: the refs are arch specific 18:04:27 so they would always be different 18:04:38 right? 18:04:43 Correct. 18:04:57 However, the package contents (aka, package NVRs) would be the same in the same image "generation" 18:04:57 the 'version' should be the same for what we release (assuming smart versioning) 18:05:09 puiterwijk: indeed 18:05:15 they would all be built from the same package set 18:05:18 Yep 18:05:23 cool 18:05:30 we are on the same page 18:05:36 ok closing out meeting now 18:05:36 That's guaranteed with the new Bodhi even :) 18:05:44 move any other discussion to #atomic :) 18:05:48 #endmeeting