17:00:25 #startmeeting fedora_atomic_wg 17:00:25 Meeting started Wed Feb 8 17:00:25 2017 UTC. The chair is trishnag. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:25 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:25 The meeting name has been set to 'fedora_atomic_wg' 17:00:35 .hello bowlofeggs 17:00:36 bowlofeggs: bowlofeggs 'Randy Barlow' 17:00:55 #topic Roll Call 17:01:03 .hello maxamillion 17:01:04 maxamillion: maxamillion 'Adam Miller' 17:01:04 .fas jasonbrooks 17:01:06 .hello dustymabe 17:01:07 jbrooks: jasonbrooks 'Jason Brooks' 17:01:07 .hello trishnag 17:01:10 dustymabe: dustymabe 'Dusty Mabe' 17:01:12 .hellomynameis kushal 17:01:13 trishnag: trishnag 'Trishna Guha' 17:01:16 kushal: kushal 'Kushal Das' 17:01:44 * tflink is lurking 17:01:57 #chair bowlofeggs maxamillion jbrooks dustymabe kushal tflink walters 17:01:57 Current chairs: bowlofeggs dustymabe jbrooks kushal maxamillion tflink trishnag walters 17:02:23 .hello miabbott 17:02:24 miabbott: miabbott 'Micah Abbott' 17:02:35 #chair miabbott 17:02:35 Current chairs: bowlofeggs dustymabe jbrooks kushal maxamillion miabbott tflink trishnag walters 17:02:41 .fas rtnpro 17:02:41 rtnpro: rtnpro 'Ratnadeep Debnath' 17:02:44 .hello scollier 17:02:45 scollier: scollier 'Scott Collier' 17:02:58 #chair rtnpro scollier 17:02:58 Current chairs: bowlofeggs dustymabe jbrooks kushal maxamillion miabbott rtnpro scollier tflink trishnag walters 17:04:14 do we have an agenda for today? 17:04:33 .hello roshi 17:04:34 roshi: roshi 'Mike Ruckman' 17:04:46 walters: We usually follow the meeting items in https://pagure.io/atomic-wg/issues 17:04:54 #chair roshi 17:04:54 Current chairs: bowlofeggs dustymabe jbrooks kushal maxamillion miabbott roshi rtnpro scollier tflink trishnag walters 17:05:05 #topic Action items from last meeting 17:05:30 will skip the action items by jberkus since he is not here. 17:05:40 yeah and then we also allow anyone to bring forward any items they like 17:06:12 yeah 17:06:16 * ACTION: jbrooks still to update compose your own tree doc 17:06:26 http://www.projectatomic.io/docs/compose-your-own-tree/ 17:06:28 that's it 17:06:29 yaym I have a chair :) 17:07:06 jbrooks: nice! 17:07:09 * ACTION: more testing on docker-storage-setup patches jbrooks dustymabe jberkus 17:07:36 trishnag: so they decided to rework the patches 17:07:43 and go a different way 17:08:45 dustymabe: okay. 17:08:47 i think the new PR got merged 17:08:58 dustymabe: Can we have link to that? 17:09:01 so basically this work got "held up" but now we can try to test the new patches 17:09:16 It would be useful to link the url. 17:09:40 let me find it 17:09:44 Sure! 17:10:13 I think this is it: https://github.com/projectatomic/docker-storage-setup/pull/181 17:10:32 #link https://github.com/projectatomic/docker-storage-setup/pull/181 17:10:35 Thanks dustymabe 17:11:12 No more Action items left from last meeting. 17:11:54 I have something to say. 17:12:26 go for it 17:12:43 I am working on https://github.com/trishnaguha/build-atomic-host . If someone wants check it out...Feel free to open issues/PR. The aim is convert it all to playbooks and automate all. 17:13:33 I saw this on twitter, I'll give it a runthrough 17:13:56 jbrooks: Awesome! Looking for more eyes :-). 17:14:21 trishnag: is this based off of jlebon's workshop? 17:14:30 is that intended to become the new way for building atomic images in fedora? 17:14:41 so, I didn't know if we as a group wanted to come up with a ansible-best-practices guide for our tests and whatnot 17:14:43 miabbott: Yes that idea came to me after I tried his workshop. 17:14:48 since we'll be producing a lot of playbooks 17:14:49 trishnag: awesome 17:14:58 tflink: I don't think so 17:15:51 tflink: Nope. I am just going for automate it *all*. 17:15:52 what is the goal of this project, then? won't it produce things which are different from the officially released bits? 17:16:00 i'd like at some point to have a more "all in one" high level experience as a single docker image that contains a webserver/jenkins/etc that you can pull down and run in a kube/openshift cluster 17:16:08 Is there a link to jlebon's workshop? 17:16:12 trishnag: I don't understand "automate it all" - what is "it"? 17:16:29 jbrooks: yes http://jlebon.com/devconf/slides.pdf 17:16:41 walters: what's the goal there? doesn't openshift have built-in jenkins magic? 17:16:53 walters: can you write down your requirements for that "all in one" experience? 17:17:07 and post them somewhere? maybe in an atomic-wg issue? 17:17:27 trishnag, this script you use, is that how he builds the images? It's different from how centos and fedora do it 17:17:36 I mean the qcow script 17:17:43 tflink: well I mean the whole process that I don't want to do manually. 17:18:06 dustymabe, start container, web UI has a few questions for what the tree name is, what packages you want to add, and watches for input and auto-recomposes 17:18:29 jbrooks: I am looking forward to convert that shell script to playbook. and include all the playbooks in one single playbook. 17:18:48 so this type of ansible setup would be part of a jenkins job or whatever in this model 17:18:53 trishnag, I think it'd be worthwhile to converge on the toolchain for this 17:19:13 jbrooks: yeah, i agree with you on that 17:19:35 jbrooks: I didn't get you. 17:19:50 it seems to me that building images differently from how releng (fedora, centos, wherever) is doing things could lead to bugs that are difficult if not impossible to reproduce in one of the environments 17:20:01 not that it shouldn't be done, just voicing a concern 17:20:08 trishnag, You're building the qcow in one way, centos does it in another, and fedora does it in a third 17:20:23 jbrooks: does centos not use imagefactor? 17:20:25 I've been meaning to make centos adopt what fedora's using 17:20:54 jbrooks: hmm. I agree as well. 17:21:03 rpm-ostree-toolbox, which does call on imagefactory 17:21:04 jbrooks, +1 to that :) 17:21:28 is what centos uses 17:22:21 cool 17:22:40 okay Let's move to the meeting items. We can have this discussion in the channel later. 17:23:23 #topic Syncing released Fedora container images to Docker Hub https://pagure.io/atomic-wg/issue/202 17:23:41 maxamillion: ^^ 17:23:48 o/ 17:23:52 info in the ticket 17:24:15 same namespace sounds reasonable - do we care at all about versioning? 17:24:28 basically, if we want to keep the namespace there needs to be a hand-off of credentials to either Fedora RelEng or Infra and I don't know who has them 17:24:39 i.e. fedora 25 version of a container image vs fedora 24 version of a container image? 17:24:40 dustymabe: you can just version with tags, no? 17:24:52 we have a whole naming scheme 17:24:54 maxamillion, credentials for the docker hub acct? 17:24:57 scollier: yes 17:25:00 maxamillion, i do 17:25:12 I documented the naming scheme and asked for feedback, there was like a 3 week long thread about this 17:25:17 what do you mean "versioning"? 17:25:46 maxamillion: ignore me 17:25:51 you've got it all handled 17:26:37 dustymabe: we can bring that back up if you like 17:27:00 dustymabe: there was coordination with the modularity folks and factory 2.0 though so if we re-open that can of worms then we need to rope everyone back in 17:27:23 nope. i'm good with it 17:27:39 dustymabe: let me make sure it's all documented on the wiki properly 17:27:53 maxamillion, i'll connect with you later on handing over the creds 17:28:05 dustymabe: yeah -> https://fedoraproject.org/wiki/Container:Guidelines#Registry_Layout 17:28:16 maxamillion: does this solve the "we can't release containers yet" problem? 17:29:03 dustymabe: it does not, but we actually can release containers as of yesterday, we just can't do it fully automated yet ... I'm working on having that done in the next day or two (was hoping to have it done before this meeting, but reality slapped me in the face) 17:29:17 dustymabe: we can release containers, we just can't sync them to the hub yet 17:29:24 k 17:29:31 because we don't have creds? 17:30:00 dustymabe: right, we also need to write the code to do it because docker hub auth is weird 17:30:04 dustymabe: https://paste.fedoraproject.org/551182/48657498/ 17:30:43 maxamillion, btw, do we have ways to handle docker images for other arch (aarch64)? 17:31:19 dustymabe: also, that catalog manifest is partially wrong because I need to clean some of that up due to a bug that was pushing images to the wrong registry ... but that's known 17:31:31 k 17:32:05 kushal: not one implemented yet, but there is a plan in place and the upstream OSBS dev team has started working on it ... we're probably 6 months out from alt-arch container builds in koji 17:32:18 btw are people about to make "epel containers" with our current setup? 17:32:23 there was somebody today that asked about this 17:32:28 maxamillion, Okay, thanks. 17:32:45 kushal: there's a big 40-ish page design doc if you'd like to view it, I can forward it to you 17:33:53 dustymabe: not currently in scope, nobody asked for it ... that gets murky though because the FROM line in the Dockerfile would then need to point to a RHEL image and I don't even want to think about that kind of licensing stuff 17:34:12 maxamillion, thanks, send me that when you have time :) 17:34:41 maxamillion, there was a question asked by the rkt devels about the aarch64 Fedora images, now I have an answer :) 17:34:42 kushal: inbound 17:34:47 maxamillion, Thank you :) 17:34:51 kushal: certainly 17:34:52 maxamillion: well not rhel, but centos, but let's table for later 17:34:58 next topic? 17:35:03 dustymabe: nope, EPEL doesn't build against CentOS in koji 17:35:14 dustymabe: I think there's a policy against it actually 17:35:37 dustymabe: because of some areas where there are ABI inconsistencies and it can cause bugs (it's super rare, but there have been cases in the past) 17:35:46 i mean creating a layered container that is based on centos but installs epel packages 17:36:14 dustymabe: that's a lot of grey area, let's table 17:36:20 yes 17:36:27 okay 17:36:30 all of this is *way* outside the scope of the ticket currently being discussed :) 17:36:44 next topic :) 17:36:44 :) 17:36:49 #topic Planning for the first Atomic VFAD https://pagure.io/atomic-wg/issue/201 17:36:50 trishnag: +1 17:36:59 dustymabe, there's a centos build service, as well 17:37:14 maxamillion: ^^ 17:37:56 for this topic, I was basically going to formally writeup the workflow I sent to the mailing list and then create a bunch of tickets for the VFAD around bring the various Fedora-Dockerfile images into DistGit and suggest tomorrow be the first VFAD (as per the original workflow proposal) 17:38:15 also, should I write that up to the atomic-wg pagure README or should I put it in the wiki somewhere? 17:38:28 maxamillion: +1 17:38:48 and if I do the atomic-wg README, what format do people want? markdown, sphinx reStructuredText, or asciidoc ? 17:38:53 We can put it on atomic-wg README 17:39:02 May be markdown. 17:39:15 markdown 17:39:22 README is for simple things. 17:39:24 I like markdown since I rarely render things before I try to read them :p 17:39:29 I prefer reST but don't care enough if others prefer something else 17:39:30 Markdown is better for that. 17:39:47 alright, looks like markdown is the winner 17:39:49 maxamillion, I prefer reST for real big documentation :) 17:39:57 kushal: I prefer reST for *everything* ;) 17:40:14 * tflink is also in the reST for everything camp but I'm in the peanut gallery here 17:40:21 * roshi is really agnostic 17:40:25 maxamillion, that is cool :) 17:40:32 I wouldn't take issue with either really 17:40:36 I'll write up the workflow in the README.md and send a pull request, I will also spend some of the afternoon gettin tickets filed according to that workflow under a milestone and we'll have a VFAD tomorrow 17:40:39 * kushal does presentations in reST. 17:40:51 Awesome! 17:40:57 kushal: oh yeah? what tool? 17:41:16 maxamillion, will tell you in the other channel (outside of meeting). 17:41:20 kushal: +1 17:41:29 kushal: :) 17:41:34 #topic Planning for interim container releases: To rebuild or not rebuild? https://pagure.io/atomic-wg/issue/200 17:41:38 maxamillion: dustymabe: we do have a policy of building against RHEL 17:41:47 dgilmore: +1 thanks 17:42:13 yes. but i will point out that that's not what I was talking about 17:42:28 wasn't talking about building epel rpms at all 17:42:39 But the base image? 17:42:46 alright, so this ticket is kind of long winded, but the idea here is that the automated rebuild code just isn't ready yet because it keeps getting bumped in priority so we either need to write something in the mean time that will automatically rebuild all container images with updated RPM content before we release or be alright with telling maintainers that they need to do that 17:42:59 jbrooks: what? 17:43:02 sorry 17:43:28 I'm +1 to rebuilding the images automatically to pick up new pkgs 17:43:36 hmm 17:43:43 could it be a two pronged approach? 17:43:58 like automatically rebuild, but then make it go through testing before release? 17:44:09 dustymabe: absolutely 17:44:14 in addition to koji? 17:44:19 I mean bodhi 17:44:20 dustymabe: however, we need to get the testing stuff in place 17:44:39 jbrooks: automated tests, this won't be a human-gating system 17:44:41 oh yeah? why not just do what we do for bodhi now? 17:44:48 noooooope 17:44:49 docker container testing stuff? 17:44:52 maxamillion, OK, automation is fine 17:44:56 what system tests the docker containers? 17:45:08 bodhi handling non-RPM content is like 6-months to a years worth of work 17:45:18 * roshi wasn't aware of anything for that 17:45:21 dustymabe: AFAIK bodhi won't support that for now 17:45:23 that whole system assumes that the one true release artifact is RPMs 17:45:25 I was prepared to expect that if the RPMs worked, the container should work 17:45:34 roshi: tflink wrote it, it's in staging iirc 17:45:38 And to test that case when I give karma in bodhi 17:45:52 ok 17:45:52 afaik the container testing is supposed to happen in taskotron 17:46:00 I'll talk to tflink then :) 17:46:08 it's just shell scripts, honestly 17:46:12 wiring up container testing to provide rpm feedback and help push things through the queue would be awesome 17:46:19 jbrooks: that's not always true though ... "the part itself working doesn't inherently mean the sum of parts will work together" 17:46:24 we never got a coherant answer on how to test containers in an abstractable fashion 17:46:34 tflink: shell scripts :) 17:46:37 * roshi is still getting up to speed on what all is happening 17:46:41 tflink: containers are the wild west 17:46:45 * roshi continues to drink from the firehose 17:46:50 roshi: nothing, we're just making it up as we go 17:46:54 Sure, stuff breaks, we fix it ;) 17:47:19 jbrooks: right, but how do gate that before it goes out the door? 17:48:07 maxamillion: you're always obsessing over the details ... 17:48:10 More testing is cool, if we can manage it -- we could always test everything more 17:48:10 * tflink ducks 17:48:17 And never ship :) 17:48:18 jbrooks, +1 to that. 17:48:19 tflink: thats probably my fault 17:48:20 :) 17:48:41 basically my short-term plan is this .... automatically rebuild (re docker build, not rebuild rpms) all known container images, then release them 17:48:51 dgilmore: there were implicit on that 17:48:59 Sounds good 17:49:01 we'll introduce the automated test component as soon as we have tests in place 17:49:12 which will actually be pretty easy thanks to the magic of fedmsg 17:49:27 this whole thing is wired together around fedmsg at the moment 17:50:24 We can move to the next ticket now. 17:50:27 +1 17:50:28 tflink: :P I know but its still likely my fault. I keep beating maxamillion over the head, details details details 17:50:36 #topic Future of Fedora Dockerfiles https://pagure.io/atomic-wg/issue/180 17:50:37 dgilmore: <3 17:50:57 I think this ticket is more or less answered with the VFAD activities that are planned 17:50:58 I think we can remove *meeting* tag from this ticket 17:51:03 this is what i was going to add: https://github.com/scollier/Fedora-Dockerfiles/tree/readme-update 17:51:15 somethign like that to direct people to the layered image build service 17:51:22 scollier: +1 17:51:22 and drop the cloud mailing list for questions 17:51:33 scollier: +1 17:51:37 k 17:51:44 i'll add that to any remaining PRs as well. 17:51:44 thanks 17:51:52 also, we should discuss what to do with our existing fedora images in docker hub? 17:51:58 scollier: Perfect :). 17:52:58 dustymabe, get them into the build service, I'd say 17:53:11 jbrooks: yeah, at least for the popular ones 17:53:18 jbrooks: +1 17:54:21 there's only like 16, it looks like 17:54:28 dustymabe: that's actually a good point because the docker hub stuff isn't really going to be able to follow our registry naming convention 17:55:02 can we get a list of the ones we want to migrate over tomorrow? that way I'm not making tickets for work to be done for things that nobody really cares about? :) 17:55:08 https://hub.docker.com/u/fedora/?page=1 17:55:34 I hope we will get tests written for each of the containers separately. 17:55:48 kushal: that's the hope/plan 17:56:03 maxamillion, :) 17:56:07 tflink: are the TestGit (naming?) changes in place so we can at least start throwing tests somewhere? 17:56:27 tflink: also, I owe you testing in stage, I'll do that today 17:56:32 maxamillion: I'm writing that up as we speak 17:56:37 tflink: you're the best 17:56:43 Let's discuss this on the channel after the meeting as we do not have much time :). 17:56:46 +1 17:56:52 alright, next ticket 17:56:54 #topic Ship fedora-motd in F24 atomic image https://pagure.io/atomic-wg/issue/160 17:57:12 rtnpro: ^^ 17:57:36 * dustymabe has a few items for open floor 17:57:57 Not sure if rtnpro is around. 17:58:02 #topic design, deploy and document Fedora OpenShift Playground (FOSP) https://pagure.io/atomic-wg/issue/153 17:58:39 Let's move to open floor. 17:59:01 scollier: You can update the ticket :) 17:59:06 #topic Open Floor 17:59:13 dustymabe: There you go. 17:59:24 trishnag, :) 17:59:25 I don't know if this has been dealt with already but has there been movement to make the atomic host image(s) release blocking for Fedora? 17:59:46 so 1 - we are making some changes in releng that make it so that users will only get an "updated" ostree whenever we do a release 17:59:47 last I heard, that process hadn't been started but I could easily be wrong on that 18:00:10 tflink, We can in next release, but Atomic images are following a different release cycle all together. 18:00:15 just a quick note, the next releases of ostree and rpm-ostree are going to be larger; ostree is going to gain an optional libcurl backend, and we're starting to (optionally) use Rust a little bit. rpm-ostree's core is a lot more powerful now 18:00:31 walters, yay to that :) 18:00:45 walters, great to hear the Rust part :) 18:01:14 2 - i had a chat with matt and steven from the server wg 18:01:16 a bit more info in https://github.com/ostreedev/ostree/pull/656 - if it goes well i may look at doing some in rpm-ostree too 18:01:21 larger in the code sense, or in the "it's now a 2.7gb binary!" sense? 18:01:28 walters: plans to rewrite everything in rust? 18:01:35 we are going to leave the cloud base image along for the f26 release 18:01:40 kushal: it's hard for QA to justify focusing on atomic over other things when it's not release blocking. I understand what you're saying but there needs to at least be some conversation around how all that is going to be handled if/as atomic host becomes more important 18:01:41 maxamillion, the great thing is, it can be incremental 18:01:46 walters: because that'd be super cool :) 18:01:51 walters: +1 18:01:56 so it doesn't have to, and won't be everythign 18:02:04 it will remain like it has been in the past. I'm thinking about making another issue tracker for cloud base image issues 18:02:14 i had some worries about alternative architectures but it looks like that's in pretty good shape 18:02:19 walters: +1 18:02:21 cool :) 18:02:28 tflink, correct, that is why I said we can do it in future. 18:02:47 speaking of Alternative Architectures 18:02:54 walters, Now firefox is dependent Rust, so that will help in the alternative archs. 18:02:58 dustymabe: Sounds good. 18:02:59 * dependent on 18:03:01 looks like open floor turned into a free for all 18:03:07 I wanted to see if there was interest in adding some for atomic host in f26/f27 18:03:32 dustymabe: basically 18:03:35 dgilmore: i believe peter did a talk on this :) - I believe there is interest 18:03:38 dgilmore: +1 18:03:48 dustymabe: Would you like to move this conversation to our main channel? 18:03:55 dgilmore, yes, for aarch64 :) 18:03:55 if so a change should get filed 18:03:55 We are running out of time :) 18:04:03 and we can work on the config side 18:04:05 dgilmore: +1 18:04:08 But first we need to be able to use our pine64 :) 18:04:28 5 18:04:30 4 18:04:36 3 18:04:36 2 18:04:36 1 18:04:39 #endmeeting