12:09:52 #startmeeting Env and Stacks (2015-04-09) 12:09:53 Meeting started Thu Apr 9 12:09:52 2015 UTC. The chair is hhorak. Information about MeetBot at http://wiki.debian.org/MeetBot. 12:09:53 Useful Commands: #action #agreed #halp #info #idea #link #topic. 12:09:56 #meetingname env-and-stacks 12:09:56 The meeting name has been set to 'env-and-stacks' 12:10:00 #chair bkabrda hhorak juhp ncoghlan vpavlin sicampbell walters ttomecek phracek 12:10:00 Current chairs: bkabrda hhorak juhp ncoghlan phracek sicampbell ttomecek vpavlin walters 12:10:07 #topic init process 12:10:34 was here anybody patient enough to wait for late start? 12:10:58 yeah, I am here. 12:11:05 hhorak: ^ 12:11:50 hhorak: Hello, sorry for not starting without you..we didn't want to take all that fun from you.. 12:12:28 #topic Dockerfile lint 12:12:43 vpavlin: I know, very nice from you 12:13:37 phracek, did you get any response about your dockerlint question on ML? 12:14:25 hhorak: Sorry I have lost. Which one? 12:14:46 phracek: the non-working openshift deployment.. 12:14:59 .hello langdon 12:15:00 langdon: langdon 'Langdon White' 12:15:14 * langdon here but also distracted 12:15:33 langdon: hi 12:15:41 hhorak: yes, together with thrcka I have built up openshift application 12:15:53 and in current status dockerlint works fine. 12:16:13 phracek: and the web app is part of it or not? 12:16:22 Ufortunately WEB UI is not a part of dockerlint available on GH I guess. 12:16:42 hhorak: No, We or I have to create a some web app. 12:17:37 Ideally on OpenShift too. 12:18:08 hhorak: This is on my TODO list. Together with checking Fedora-Dockerfiles and behave testing. 12:18:24 phracek: yes, that would be great, but it seems to be also worth checking if the author has something already by any chance 12:18:36 hhorak: But I need to priorize it. Web app is first I gues. 12:19:22 Personally I think that Web app is first step for docker.fedoraproject.org. 12:19:27 #link http://docker-phracek.rhcloud.com/ 12:20:41 I am not a web designer and I will talk about it a bit more with ttomecek. But only a talk. he will NOT implemented. I will do it by myself. 12:20:42 #info web app for dockerfile_lint is not part of the dockerfile_lint project, but it may be just tiny web app 12:21:18 phracek: #action phracek to look into implementing some web ui for the dockerfile_lint 12:21:28 #action phracek to look into implementing some web ui for the dockerfile_lint 12:21:46 phracek: Please don't start any work until you ask whether there is anything in work or not:) 12:21:56 hhorak: THX :) 12:22:12 hhorak: Action should be: Check plans about UI with dockerfile_lint authors 12:22:28 #undo 12:22:28 Removing item from minutes: ACTION by hhorak at 12:21:28 : phracek to look into implementing some web ui for the dockerfile_lint 12:22:29 vpavlin: Yes definitely. This should be my first step. 12:22:43 #action phracek to check plans about UI with dockerfile_lint authors 12:23:24 I am planning to contact owner of this application https://access.redhat.com/labs/linterfordockerfile/ 12:23:43 as mentioned ttomecek in ML. 12:24:36 langdon: you wanted to get in touch with dockerfile_lint author to consider moving to atomic project, any udpates? 12:25:19 hhorak: it is under Project Atomic https://github.com/projectatomic/dockerfile_lint/ 12:25:23 * ttomecek1 is here 12:27:42 vpavlin: ah, haven't check, great! 12:28:26 #info dockerfile_lint moved under project atomic 12:28:27 #link https://github.com/projectatomic/dockerfile_lint/ 12:29:25 #topic Fedora-dockerfiles revisiting 12:29:50 Ok, When I will have any information about web ui it can be incorporated to dockerfile_lint on project atomic. 12:29:57 Via pull request of course. 12:30:23 phracek: sounds fine to me, thanks 12:30:36 * vpavlin nods 12:31:10 * ttomecek reads backlog 12:31:30 hhorak, sorry wandered off... yes, update.. it has been moved: https://github.com/projectatomic/dockerfile_lint 12:31:46 langdon: We already figured this out:) 12:31:49 * langdon notices scrollback now.. need moar coffee 12:32:01 langdon: but still thanks! 12:33:01 i have one quick comment about f-dockerfiles when y'all are ready 12:33:43 I have also one thing re dockerfile_lint 12:34:39 #undo 12:34:39 Removing item from minutes: 12:36:32 lol 12:37:03 langdon: yes. ready 12:37:06 ok, guy, this starts to be confusing:) 12:37:09 *guys 12:37:21 langdon: Do you have your caffee? 12:37:25 ttomecek: you wanted to say something about dockerfile_lint? 12:37:27 phracek, just a quick note about dockerfile_lint ui, this guy: https://github.com/lphiri is the current owner, he would be the best contact, I can make an intro if you like 12:37:36 vpavlin, :P 12:37:54 langdon: you are faster then flash:) 12:38:11 hhorak, yep, I was actually waiting for langdon to start first 12:38:17 ok.. so the problem i have with f-df is kinda the same thing as with bash-completion .. the dockerfiles belong in the upstream projects for the eams to maintain 12:38:23 * langdon slow typing today 12:38:54 langdon: true..how to get them there? (The Fedora specific ones?) 12:38:56 re plans ^ I agree what you guys said: get in touch with the author if the existing solution @ access.redhat is open source(able) 12:38:56 so.. I have done a few in "needs_work" but I hesistate to "publish" them w/o the upstream project blessing them.. which is weird in the f-df branch 12:40:12 upstream meaning maintainers and in dist-git? 12:40:18 ttomecek, i think, whether open source or not, it is likely very tightly integrated in to the web-ui of customer-portal (a heavily layered drupal app) so is probably not very portable.. we should definitely discuss it with them, but I don't have great hopes for useful code 12:40:49 ttomecek, f-df: no, like the project that is running in docker.. e.g. i did one for eclipse-orion and one for znc 12:41:05 those projects should "own" them.. not fedora.. per se 12:41:06 langdon: Do you know if we have any other useful web apps? 12:41:18 I do not want to create a new web ui from scratch. 12:41:24 langdon, at least getting fronted would be awesome! implementing backend is ridiculously easy 12:41:34 phracek, lint: don't know.. you would have to ask 12:41:59 langdon: ok, I will ask him. 12:42:13 langdon, okay but we have been doing pretty much the same thing with rpm and specfiles 12:42:14 * langdon thinks "come on, i can support at least 3 convos, bring it on!!" :) 12:42:39 ttomecek, true.. tick tick (thats my brain)... 12:43:40 langdon: I agree that we should talk to upstream about dockerfiles, about the "api" of them (how to run them, what to expect), but the real implementation is really like packaging imho -- distro-specific 12:43:44 ttomecek, with rpms though, isn't there "some" tacit approval? or, sometimes, even a base of the specfile/etc upstream? should this be different because it would be better if they (rpm artifacts) were upstream? 12:43:48 ttomecek: And you consider that a good practice?;) 12:44:15 langdon, anyway: so you would like to get those dockerfiles to upstream projects of the main component running in the container? if so, that makes perfect sense to me! 12:44:19 vpavlin, +1, my question too.. i believe in the fedora patches on them (maybe) ... 12:44:30 ttomecek, right 12:45:39 langdon, aggree; rpm spec & dockerfile wasn't a good comparison 12:45:48 i guess i would argue that the rpm artifacts living in fedora as the primary location is a flaw... and we might have an oppty to "do it right" with dockerfiles... however, we still need a way to aggregate them so we can point people at fedora docker examples 12:46:28 ttomecek, actually thought it was a great comparison.. pkging is pkging.. i just don't know if rpm artifacts "belong" in fedora either.. 12:46:33 what will be the strategy then? (to get the dfs to upstream) 12:46:57 * langdon mutters this is why he is not officially on the WG.. he just brings problems :) 12:47:41 kidding aside, I think we just make the request (like PR) .. i have a "run yeoman in a docker container" dockerfile almost done that i plan to do exactly that with 12:47:44 action: Langdon will prepares master plan for bringing dfs upstream.... 12:47:45 ;) 12:47:57 ttomecek: langdon: I think if upstream agree then why not. But distro issues could be a problem 12:47:59 I don't think it is doable to get rid of dockerfiles from fedora, but we may convince upstream to ship the same dockerfile in their tarball and do not differ from it if possible 12:48:06 however, I want fedora to "be aware of it" though and I am not sure how to make that part happen 12:48:32 trying to do some PRs would be a good start! 12:48:43 hhorak, but, if you were looking for a yeoman or eclipse-orion dockerfile, would you look in fedora land? or in those projects (biases aside) 12:49:14 langdon: what hhorak said makes sense to me ^ - let them carry Dockerfile.fedora in tar 12:49:49 vpavlin, but where is the "source" of that dockerfile? 12:50:12 langdon: I am gonna to contact lphiri about UI. But do you have somebody a mail or GH repository with sources? 12:50:32 phracek, let me look 12:50:46 I am pretty scared how to contact him. 12:50:49 langdon: do you think people will look for dockerfiles actually? maybe the same people who look for spec files but most people will be looking for images already.. but I see your point, if looking to dockerfile itself, the upstream tarball is the first place to look.. 12:50:58 langdon: so you say we should have a git repo with "symlinks" to upstream repo containing DFs 12:51:16 phracek, i definitely have email.. ill make an intro if you like 12:51:28 langdon: awesome. 12:51:40 vpavlin: you know RCM, we need to have everything in-house if we build something official of it.. so no symlinks, real copies.. 12:51:40 langdon: Definitelly I would be glad. 12:52:14 hhorak: Well we can easily pull if from that symlink as part of build.. 12:52:29 hhorak, i believe only crazy people only look for images.. even i, who would never rebuild an rpm, always build from dockerfiles (not pull from hub) because they are so powerful and there is no vetting on the hub.. and dockerfiles are just too easy.. 12:53:24 hhorak, vpavlin we pull from upstream to dist-git all the time.. having a copy of the sources is more than sufficient 12:53:31 langdon: that makes sense, so maybe dockerfiles are not in the same position as spec files.. 12:53:44 vpavlin: yeah, symlink would be fine. 12:53:48 * phracek nods 12:55:34 ok.. so.. i think we agree on the "dockerfiles should live in the projects" .. but, that doesn't solve the other part of the problem, how do we aggregate them (primarily for marketing reasons) in fedora-land? 12:56:15 langdon, some document with mappings? 12:56:16 langdon: by aggregating you mean where dockerfiles will live in fedora? 12:56:17 * phracek thining. 12:56:24 * phracek thinking 12:56:59 * phracek thinks that some of dockerfiles are fedora specific and should be a part of fedora-land. 12:57:06 meaning, every time someone's propose df to upstream and gets merged, puts a line in the document/wiki page 12:57:12 but symlink from upstream make more sense. 12:57:35 ttomecek, right.. exactly.. but prefer something like symlink in git repo.. wiki pages never get update :/ 12:58:04 ttomecek: yes. What about to do it in df main page? 12:58:04 langdon, that would work too 12:58:08 langdon: I am not convinced we need to have real dockerfiles as sources in Fedora (during image build if we ever do that, yes...but just to present them to the world...don'T know..) so maybe sort of list where we state "These projects support Fedora Docker images" 12:58:27 document/wiki page means docker.fedoraproject.org? 12:58:42 or their subpage? 12:58:48 vpavlin, right.. on the last part.. but I am thinking of it being a set of samples too.. 12:58:50 * vpavlin sees a bit of agreement where mapping/linking to upstream wins.. 12:58:55 my other meeting starts in 2 minutes; here's the thing re dockerfile_lint I wanted to point out: let's rewrite it to python! 12:59:04 ttomecek, lol 12:59:16 ttomecek: from NodeJS to python. +1 12:59:17 I am serious 12:59:55 ttomecek: Are you volunteer? 13:00:08 personally, I think effort spent on adding rules and best practices would be a better use of time.. 13:00:10 langdon: I think the list I described can link to upstream repos.. 13:01:06 vpavlin, yeah.. thats cool.. as long as we can make sure it is current.. and, I would just point out, we need to keep in mind 1) it is usually a dir not just one file 2) we want this, probably in the same place, for kube enabled ones too 13:01:39 so.. maybe convert/create a git repo that publishes the website.. so it is still just a PR to add something to the list... 13:02:40 ttomecek: On the other hand with rewriting df_lint to python. Do we want to spent an effort to it? 13:02:44 sorry, had to disconnect 13:03:16 df_lint in python could be used in future Fedora projects I guess. 13:03:49 Any summary would be awesome. After a meeting. 13:04:13 yep, am volunteering; also can work on the rules 13:05:26 ttomecek: I can help you later on (as non Python expert:) ) if you are busy. 13:05:26 #idea to rewrite dockerfile_lint into python, but not sure if the effort is worth since we should also concentrate on writing rules 13:05:33 #idea dockerfiles should live in upstream rather than downstream distro 13:05:53 * langdon notes he is equally bad in node and python :) 13:05:55 phracek, I want; it will take me like an hour or so; and I will also create test suite 13:06:17 ttomecek: Wow. 13:06:21 #idea we need to aggregate dockerfiles in fedora (primarily for marketing reasons), the question is how (wiki considered not ideal, since it never gets updated) 13:06:46 the reason I want to spend effort is that I'm pretty sure we would extend functionality of the tool -- it will be better if it's in python 13:07:16 ttomecek: everything is better if it is in python, right? :) 13:07:28 * langdon notes all the cool kids are doing everything in node :) 13:07:30 hhorak: yeah ;) 13:07:51 hhorak, for me yes :) I even write shell scripts in python 13:08:10 but I see some reason, since number of people who know python a bit is greater than number of people who ever heard about node 13:08:20 (at least people I know) 13:09:55 langdon: so the idea about the aggregation is just have one place where we are able to say "this component offers a dockerfile and these are all dockerfiles available for fedora packages"? 13:10:18 hhorak, yeah.. something like that... 13:11:40 * vpavlin1 whispers: golang 13:11:57 vpavlin1: Crazy man:) 13:12:01 vpavlin1: lol 13:12:53 * phracek see a future. Fedora updates are done by golang :) Wrong dream. 13:13:06 so did we find a good way how to do the aggregation? there were more ideas but I don't see which won.. 13:13:24 dockerfile_lint in python was the first one. 13:13:48 (doesn't have to be perfect, but good enough for start would be fine) 13:14:00 symlink from upstream to dfs, right? 13:15:53 ttomecek: python-dockerfile_lint is going to be a part of projectatomic GitHub? 13:16:22 phracek: I though the symlink was meant to be the opposite way -- from fedora to upstream, right? 13:16:23 Or it will be in your github repository. 13:16:45 hhorak: sure. 13:17:31 anyway, depending where the dockerfiles in fedora will be located (I suppose in a dist-git) -- we should be able to grep all of them and publish periodically (e.g. every hour) 13:18:47 phracek, well, first, we should the original author what he thinks about that 13:19:06 * phracek has to leave. Some colloquial hours in basic school of my kids. 13:19:10 hhorak, i liked the "docker.fp.o" website idea.. or maybe, containers.fp.o ... and make it a git generated website... thoughts on that? 13:20:11 langdon: git generated means the content is stored in git? 13:21:41 hhorak, yeah.. like this: https://github.com/yeoman/yeoman.io 13:22:39 #info docker.fp.o or containers.fp.o may be a good place to keep the aggregation of dockerfiles, the content may be generated from git, similar to https://github.com/yeoman/yeoman.io 13:23:22 It seems to me we've had so many ideas that some of us already ran away, but we can continue the next time, what do you think? 13:23:47 or better idea -- let's use the ML more!! 13:25:53 so thanks guys, see you next time! 13:25:57 #endmeeting