12:03:08 #startmeeting Env and Stacks (2015-09-24) 12:03:08 Meeting started Thu Sep 24 12:03:08 2015 UTC. The chair is hhorak. Information about MeetBot at http://wiki.debian.org/MeetBot. 12:03:08 Useful Commands: #action #agreed #halp #info #idea #link #topic. 12:03:08 #meetingname env-and-stacks 12:03:09 #chair bkabrda hhorak juhp ncoghlan vpavlin jkaluza walters ttomecek phracek 12:03:09 The meeting name has been set to 'env-and-stacks' 12:03:09 Current chairs: bkabrda hhorak jkaluza juhp ncoghlan phracek ttomecek vpavlin walters 12:03:17 hi 12:03:28 hi 12:03:41 Hi! 12:03:46 * ttomecek waves 12:03:52 * vpavlin hides 12:04:30 let me begin with... 12:04:30 #topic Fedora dockerfiles -- versions, size, more involvement from E&S 12:04:41 I guess this should be quick topic... 12:04:59 anybody from us already has commit rights to Fedora-dockerfiles btw? 12:06:02 hhorak: vpavlin has/had 12:06:14 jkaluza: Nope, I haven't:-) 12:06:28 vpavlin: ah, that has been merged than ... sry :) 12:06:31 *then 12:06:44 * vpavlin was just commenting on PRs from time to time 12:07:10 would be nice to get those since it takes some time to merge patches now 12:07:27 not that Scott would be inaccessible but I see PRs like: 12:07:28 #link https://github.com/fedora-cloud/Fedora-Dockerfiles/pull/128 12:07:41 take too long to be merged... as ttomecek said.. 12:08:08 and actually has conflicts, now;) 12:08:12 #info some PRs take too long to be merged in Fedora dockerfiles, let's help Scott with that work.. 12:08:48 I'd like to get involved into Fedora dockerfiles more, so maybe I can try reviewing the PRs to help Scott 12:08:48 Do we also ship images based on those docker files? 12:09:12 jkaluza: the images should be auto-build in docker hub.. 12:09:19 (at least I guess it works that way) 12:09:46 not sure if that's offtopic, but there are some images at dockerhub under fedora namespace which are severely outdated 12:10:04 ttomecek: I just wanted to discuss that too 12:10:08 I don't think so 12:10:24 bkabrda: so why don't just ask for commit? we can always comment, but someone must commit.. :) it would makes great sense to me when at least one of us had the rights.. 12:10:30 Some are autobuilded.. 12:10:32 bkabrda: U volunteering? 12:11:09 ttomecek: that's not off-topic at all, we should care... 12:11:10 if we are going to ship the images somehow, we should probably rebuild them once we update some RPM used by that image 12:11:11 * vpavlin would happily volunteer mr. bkabrda for this :-P 12:11:34 yes, I'm volunteering :) 12:11:54 I'll get in touch with scott tomorrow to see how I can help him 12:12:00 bkabrda: great! thanks 12:12:02 jkaluza: Hmm..what about a service listening on fedmsg and triggering rebuilds? 12:12:13 I wanted to code something like that :) 12:12:15 #action bkabrda to get in touch with scott tomorrow to see how he can help him 12:12:24 jkaluza, vpavlin: tracking the metadata needed for that is something PDC is designed to do 12:12:39 ncoghlan: That's right 12:12:40 looks like I'm wrong; those are indeed built from Fedora-Dockerfiles; see e.g. https://hub.docker.com/r/fedora/python/builds/b22dzq2k3mqvehiqgsk3tsc/ 12:13:37 jkaluza, vpavlin: I know PDC is open source now (https://github.com/release-engineering/product-definition-center), but I'm not sure where they in setting up a Fedora instance 12:13:40 ttomecek: about the outdated images.. we can at least submit issue on github to track that.. 12:14:10 ncoghlan, vpavlin: that was my old idea: https://fedoraproject.org/wiki/User:Jkaluza/Draft/task-fedmsg-poster 12:14:39 but I'm not sure it's still actual with the newer ideas about Fedora :) 12:15:13 I presumed we will use docker hub for the images, which does not have to be true now 12:16:04 jkaluza: i guess docker hub is still the final destination... there will be osbs between only, for testing and stuff... 12:16:12 (somebody correct me if I'm wrong) 12:16:12 jkaluza: I think it does not really matter if it will hit trigger in Docker Hub or in some Fedora infra bits:-) 12:16:47 true, we just need some way to rebuild image once we update the RPM in the image imho 12:17:13 for official Fedora images, Koji either has or is gaining the ability to build layered Docker images 12:17:25 ah, correct..osbs... ttomecek, how far is osb regarding rebuilding on content changes (i.e. RPM updates)? 12:17:32 Isn't some variant /part of dopr supposed to do the Fed msg trigger and building? 12:17:54 dopr is the "build what you want" self-service one 12:17:54 isn't there already a fedora service which is able to do some webhooks based on fedmsg? 12:17:56 * langdon is on the train with dicey signal so may have sent that twice 12:18:00 langdon: I am not aware of such feature 12:18:32 vpavlin, backlog, low prio item, no work done 12:18:54 Well.. Copr build triggers fed msg, which dopr picks up and builds image and puts it in docker hub.. Can't go just send the same/similar message? 12:19:06 S/go/gh 12:19:15 gh? 12:19:21 Github 12:19:26 it would be easy to do with fedmsg (or our internal message bus), but hard to do when we should implement that in koji 12:19:49 langdon: I don't think we can configure github to send anything on fedmsg.. 12:19:51 ttomecek: just the actual build, not the listener 12:21:13 hhorak we just need something to listen for gh web hooks.. Would surprise me if threebean had something like that already 12:21:32 langdon: threebean? 12:22:10 ralph bean 12:22:11 but yes, that should be really small service and very useful I guess 12:22:15 langdon: hm, not sure I understand, but I was thinking about rebuilding the Docker Image (based on F22 for example) once new RPM gets into F22 stable repo 12:22:15 hhorak: Ralph Bean (fedora engineering) 12:22:45 jkaluza: the rebuilding itself could do dock then.. 12:23:00 langdon: so I'm not sure how GH fits into that. Maybe you are thinking about rebuilding the docker image on DockerFile change (which is done in github) 12:24:03 jkaluza: you're right... 12:25:06 Are we still on-topic? (Fedora dockerfiles -- versions, size, more involvement) 12:25:07 so we're more looking for something small that would rebuild images based on the RPM update... until there is working solution inside osbs.. right? 12:25:35 jkaluza yes.. Sorry.. We also need it to respond to the rpm rebuild event(s) in fedmsg.. Sorry about not being clearer about which part I meant 12:25:38 hhorak: that's out of scope for OSBS 12:25:50 hhorak: but in scope for RCM/release engineering 12:25:58 hhorak: I think we closed that one. And we are now on topic like: Fedora Docker images pipeline & workflow 12:26:39 ncoghlan: hm, I thought it was.. but was not right probably. 12:26:44 ncoghlan: I don't think it's out of scope. we have this feature request tracked for OSBS, it's just low prio for us ATM (and pretty hard to implement, too) 12:27:07 bkabrda: I don't think it's implementable without a metadata server like PDC 12:27:21 to track which RPMs go where 12:27:35 I believe there is already a fedmsg for the new rpms..we just need a way to know which rpms are in which image.. Why would that be a part of the build service? 12:27:55 ncoghlan right.. 12:27:56 exactly 12:28:00 ncoghlan: ttomecek, brew has information about rpms installed in the image, right? 12:28:19 vpavlin, yes, not sure how hard is to query that 12:28:19 vpavlin: that's actually where PDC gets the data :) 12:28:36 and then exposes it as a REST API for easy reverse lookup 12:28:48 ncoghlan: let me rephrase: this will have to be standalone service that will monitor RPMs being built and then trigger image rebuilds based on that. it can be part of "OSBS as a larger whole", but it certainly won't be part of any current OSBS component 12:29:01 hopefully that sets it right :) 12:29:29 bkabrda ack 12:29:42 bkabrda: adding something like PDC to OSBS at a later date certainly seems plausible 12:30:00 whether we query that from koji or from image is not that big difference.. but we need to query that on image build and keep it in some DB so we can find it fast on fedmsg about new rpm. 12:30:14 hhorak: yes, this is what PDC does 12:30:37 "rebuild all Red Hat's Docker images when a CVE comes in" is why it was written 12:30:54 ncoghlan: we'll actually be utilizing parts of PDC api for certain pieces of autorebuilds in next version. at least internally; I'm not sure whether we'll be able to use the same approach for Fedora 12:31:41 making it useful for Fedora as well was a primary goal in publishing it as open source 12:31:50 hopefully we will. I saw a proposal for Fedora to use PDC, but I can't find the link and the status of this right now 12:32:03 yeah, I'm not sure either 12:32:12 ncoghlan: just to be sure -- pdc will be just the db part, but firing the rebuild itself will be done by something else? 12:32:18 hhorak: yeah 12:32:26 PDC is a static metadata store by design 12:32:40 ncoghlan: it's open source right now; it's just a part of osbs code that needs a PDC instance running and serving data 12:32:53 bkabrda: oh, cool 12:33:35 so, let's check how far pdc in fedora is... if we find out it's far from being ready, we can create some very lightweight DB.. but we'll still need another part, which will do the rebuilds automatically and this part does not exist anywhere, or does it? 12:33:47 I think we really need someone from Fedora rel-eng attending the Envs & Stacks meetings... 12:34:09 (and it's optional, so even if there's no PDC in Fedora, things can be made adjustable to what Fedora needs) 12:34:17 hhorak: PDC *is* a lightweight DB, so don't reinvent it 12:35:05 it mostly aggregates info from other data sources (like Brew) and exposes them through a standard API 12:35:33 ha, got it https://fedorahosted.org/fedora-infrastructure/ticket/4863 12:36:51 any volunteer to find out what's the fate and current status of PDC in fedora from rel-eng? basically whether we can expect PDC will serve for these purposes any time soon? 12:38:25 I'll follow up on the ticket, if someone in Brno wants to follow up with sochotni directly 12:39:22 I think we should with Fedora rel-eng; sochotni is driving the upstream PDC work, but I think he doesn't do anything about the Fedora deployment 12:39:37 if there's something necessary to discuss with sochotni, I can do that 12:39:50 thx 12:39:58 since I've been talking to him about OSBS's requirements from PDC 12:40:13 but I really think this specific question is for fedora rel-eng 12:40:45 or threebean, who opened that ticket 12:40:48 looking at the ticket, threebean cc'ed Adam Miller (maxamillion) in rel-eng 12:41:00 so I'll just post there, and we can see what response we get 12:41:11 ah, yes. Adam is working on deploying OSBS for Fedora, BTW 12:41:20 ok.. let's go back to fedora-dockerfiles -- what I wanted to touch about versioning was that with current approach we can only provide one version of every packages (e.g. postgresql 9.3 in f22-based images) 12:42:21 I think we should have a way to be able to have more variants -- like postgresql:9.3 image and postgresql:9.4 image 12:42:36 even if every image is based on different fedora version.. 12:43:13 hhorak: won't we have that when the Fedora release containing postgresql 9.4 is released? 12:43:40 bkabrda: imo older images get lost basically.. 12:43:55 ah, I wasn't aware of that 12:44:00 what does "get lost" mean? 12:44:19 one thing is whether we can build it -- it will be possible as soon as we have fedora with that version released.. 12:44:36 hhorak: So what you are proposing is to change structure of Fedor-Dockerfiles to have `project/version/Dockerfile` and use that in automated builds to build and tag specific versions..correct? 12:44:45 another thing is whether we can set labels somehow on docker hub if we build images automatically on github commit 12:44:54 bkabrda, so far, the image is tagged just like 'fedora/postgresql:latest' 12:45:10 vpavlin: or using branches, if that is something what docker hub can 12:45:38 but in both cases we need to set the labels somehow 12:45:41 bkabrda: https://hub.docker.com/r/fedora/python/tags/ - we use only :latest and thus if there is a rebuild, older version gets lost 12:45:51 praiskup: ok, so we just need to figure out a way to properly tag the images built from older fedora releases 12:46:27 bkabrda: not only from older releases, generally for all images.. 12:46:30 bkabrda: We need to reflect that in GH somehow - branches, tags, or paths 12:47:03 vpavlin: yup, I think this is just a matter of organizing things, shouldn't be that hard to achieve 12:47:15 hhorak: First, we need to change this in GH, then automated builds need to be changed accordingly 12:47:18 (but it may be hard to achieve in a maintainable way :)) 12:47:29 I would go with path for versioning 12:47:50 as I said - project/version/Dockerfile 12:48:03 but do we know whether it is even possible on docker hub to set arbitrary tags when we build the images automatically? (I don't know) 12:48:12 hhorak: yes 12:48:20 vpavlin: how? 12:48:33 vpavlin: in dockerfile somehow? 12:48:51 hhorak: give me a sec.. 12:49:27 http://imgur.com/TnpcouY 12:49:47 vpavlin, (as a image maintainer) I would love to be able to control versioning from git repository ... if I could have something like postgresql/docker-tags file, that would be perfect 12:50:26 You can setup automated build based on branch/tag and then path in the checkouted repository 12:50:36 and than assign a tag to this 12:50:44 I tried to start thread here https://lists.fedoraproject.org/pipermail/cloud/2015-September/005748.html but apparently wrongly chosen fedora group :( 12:51:12 praiskup: I am afraid Docker Hub does not support anything like that 12:51:24 I guess it will be possible when OSBS is in place.. 12:51:49 #link http://imgur.com/TnpcouY 12:53:01 "Docker Hub does not support anything like that" this (for a lot of "that"s) 12:53:11 * vpavlin nods.. 12:53:27 i have another meeting in 5, so I've got to run... see you next time 12:53:28 * phracek totally forgot that we have a meeting. 12:53:28 bkabrda: could you ask scott whether it would be possible to become contributor in docker hub as well? 12:53:32 vpavlin, the (auto)re-build for particular tag is created automatically with 'git push --tags'? Or do you have to create it manually? 12:53:46 hhorak: yes, I'll discuss this with him 12:53:51 bkabrda: thx 12:54:24 praiskup: You have to create it manually..like if you tag something in git, you need to go to Docker Hub and set up new Automated Build 12:54:54 vpavlin, thanks for the info 12:55:07 but I guess since this is a temporary solution (until there is osbs ready) we can go with that... 12:55:38 so, branches or paths? (I'd be rather for branches, since content will be very very similar there and git will support it better) 12:56:32 #info it is possible to configure in docker hub what tags should be used for automatically re(build) images (based on github branch and path) 12:56:43 hopefully I summarized it correctly ^ 12:57:09 vpavlin: any particular reason why you prefer paths? 12:57:35 Well..if that's for a Fedora version, then branch is fine 12:57:53 hhorak, yes, I bet that the current situation could be something like 'fedora/postgresql:latest', 'fedora/postgresql:22', ... 12:57:54 I was for some reason thinking about project/packages versions..which would be a mess 12:58:33 So if that's branches like F21, F22, F23, Rawhide..than you have my +1 12:58:54 vpavlin: that makes sense to me 12:59:05 I'd also check with DOPR guys if we could somehow leverage Docker Hub API for that so that we don't have to set all of that manually 12:59:05 * jkaluza has to go for now, sorry 12:59:26 praiskup: I'd rather use postgresql version as tag.. 12:59:59 so, docker hub configuration for postgresql would say: for branch F22 use tag 9.3, for branch master use tag 9.4+latest 13:00:28 hhorak, as I understand it, its not possible right now - as far as we do not create special git branch for it 13:00:43 hhorak +1 13:00:51 praiskup: you mean like branch must be same as tag? 13:01:03 I hope it doesn't have to be.. 13:02:01 praiskup: or why do you think it is not possible? 13:02:24 hhorak, sorry, if we create tag/branch named postgresql_9.4, its OK probably 13:02:25 If you take a look at the image I sent, it will be like: 13:02:25 Push Typ Name Path Tag 13:02:25 Branch F22 /postgres 9.3 13:03:30 vpavlin, you mean 'f22/postgresq_9.3'? 13:04:05 No, I mean branch F22, path /postgress, tag 9.3 13:04:35 vpavlin: that's how I understood.. 13:04:35 vpavlin, but there will clash different projects, postgres versioning with mysql 13:05:07 praiskup: the configuration is for every image separately 13:05:08 praiskup: How? 13:05:23 Would it make more sense to just to demo what you mean hhorak? Or vpavlin? Seems like this will be very had to explain in the abstract 13:06:02 if I tag some git commit with '9.3', what project (directory in git) the tag named '9.3' is related to? 13:06:04 langdon: I can probably record some video:) 13:06:48 (speaking about fedora-dockerfiles) 13:07:12 praiskup: Forget about git tags.. 13:07:51 praiskup: there will be a branch F22 and your Dockerfile for postgress in Fedora-Dockerfiles/postgres directory 13:08:24 vpavlin I actually meant setup a dummy git repo with some files and some docker builds.. 13:08:44 and bkabrda will setup a build from branch F22 and directory /postgres which will be tagged as fedora/postgres:whatever 13:08:58 langdon: Right..and then record a video how to work with that...no?:-) 13:09:34 vpavlin, I see now, basically mapping git-branch to docker-tag, ok 13:09:59 git-branch+path -> docker-tag 13:10:05 vpavlin or just grant everyone commit rights.. So they could look at it directly 13:10:14 langdon: or that... 13:10:56 vpavlin, will I be able to set up this mapping? 13:11:17 (for my component) 13:11:29 praiskup: someone who will be marked as collaborator on docker hub for fedora will be able.. 13:11:54 but I guess this is fine for the temporary solution, ttomecek will safe us soon with osbs :) 13:12:26 praiskup: Unless you have commit rights to git repo and Docker Hub, no 13:12:32 hhorak, vpavlin, would there be problem to do mapping like: git-branch+path -> { docker-tag-a, docker-tag-b }? 13:12:58 halfline, vpavlin, IOW, would that spin multiple rebuilds? 13:13:12 praiskup: yes, it will be separate builds 13:13:24 THat's another missing feature in Docker Hub;) 13:13:45 vpavlin: like every tag needs a separate build? no 2 tags for one build? 13:13:51 hhorak: Correct 13:14:03 vpavlin: grr, funny docker hub.. 13:14:16 vpavlin, hhorak do we have to care, yes? 13:14:39 I wouldn't care as, again, it's a temporary solution 13:15:08 #info every tag will require a new build on docker hub, but we can still set up something like git-branch+path -> { docker-tag-a, docker-tag-b } ... i will just create more builds than we'd expect... 13:15:15 And docker's hardware :) 13:15:22 Great, so will anybody try that on some ad-hoc private repo and share it for documentation purposes? 13:15:48 I can try it but can't promise any deadline... :) 13:16:02 so giving chance for others :) 13:16:38 then we can propose it to scott and fedora-cloud folks as the solution.. 13:16:47 hhorak, does it make sense? (IOW: will we all be marked as collaborators?) 13:17:03 I'm just going to add the PDC link to the minutes, since we forgot to do it earlier 13:17:11 praiskup: No, we will need to throw that on bkabrda;) 13:17:31 hhorak: I can setup the demo and document the process 13:17:41 vpavlin: great! 13:17:45 * vpavlin is going to be useful to env&stacks finally! 13:17:49 #info Product Definition Center is a dependency for triggering Docker rebuilds on RPM updates 13:17:59 #link https://fedorahosted.org/fedora-infrastructure/ticket/4863 13:18:28 #action vpavlin will setup a demo process and document how we can build the versioned dockerfiles in from https://github.com/fedora-cloud/Fedora-Dockerfiles 13:18:36 vpavlin, as you haven't answered my question yet, who is able to mark me as "collaborator" in docker hub? 13:19:05 praiskup: probably no for the fedora namespace... we'll have hopefully someone like bkabrda for that 13:19:28 praiskup: I guess scollier..but I am pretty sure it does not make sense to add all the people therer 13:19:48 or there can be more guys (you) but still that's not something for everybody I guess... 13:20:01 We should rather document "how to request new image tag" in contribution guidelines and make that part of PR 13:20:21 vpavlin, exactly ^^ that is what I was asking for 13:20:37 maybe not everybody will be interested, so adding few folks (bkabrda and praiskup) could be fine... we need to consult this with scott anyway.. 13:21:25 anyway, I had few other topics on the agenda, but we're already way over, so rather opening the floor... 13:21:31 #topic open-floor 13:21:43 I'll try to touch other topics on ML 13:22:00 #action hhorak to touch other topics (not covered today) on ML 13:22:23 I've had a few conversations lately regarding the Software Component Pipeline that were "but what about non-RPM formats?" 13:22:31 so I wrote https://fedoraproject.org/wiki/Env_and_Stacks/Projects/ImageAssemblyRecommendations 13:23:03 pretty sketchy at the moment, but aims to start making it clearer that component creation is only step 1 13:24:13 The "Layered Container Images" part is the main bit that belongs to Env & Stacks 13:24:23 the rest is really Base and RCM 13:24:33 plus the Edition WGs 13:25:18 "Projects" probably isn't the best namespace for it 13:25:36 it only ended up there because I copied the path for the Software Component Pipeline 13:25:56 #link https://fedoraproject.org/wiki/Env_and_Stacks/Projects/ImageAssemblyRecommendations 13:26:01 anyway, I'll lob an email at the mailing list about it 13:26:28 * vpavlin is partly gone already:-) 13:27:26 ncoghlan: by non-RPM you mean images and other composed bits here? 13:27:55 no, I mean upstream formats like gem, maven, Python sdists, etc 13:28:29 ncoghlan: Is that mentioned anywhere in the wiki page? Cause all I noticed was input: RPM, output: blah...:-) 13:28:49 vpavlin: I did say it was sketchy :) 13:28:55 it's in the Layered Image section 13:29:24 ah 13:29:34 Cool, thanks 13:29:42 Layered images are special, since they're the ones that can bring in additional non-RPM bits 13:30:18 ncoghlan: and the current plan with those non-rpm technologies is having 1-to-1 pulp-based mirrors of selected components, right? 13:30:49 hhorak: maybe. I'm not sure any more that's worth the hassle (at least at the Fedora level) 13:31:16 if you look at the PyPI terms and conditions, for example, we've written those such that everything on there should be legal to use 13:31:51 but RepoFunnel building on Pulp gives us that option in the future 13:32:37 so it is mostly about whether we need a middle step for tracking purposes (so we have the content in our repo somewhere) or whether we're fine with depending on upstream repos.. 13:32:37 and there's a fair chance I'll implement it just to stop people asking about it :) 13:32:46 ncoghlan: :) 13:33:03 ncoghlan: \m/ you rebel! 13:33:05 hhorak: for stuff going *into* Fedora, I think we should also convert to RPM, and focus on making that automated 13:33:26 ncoghlan: totally.. 13:33:51 vpavlin: noticing that the Pulp Docker demo already included the Python plugin may have something to do with my change in attitude :) 13:34:05 :-) 13:34:16 when the plugin's already there, and I just have to change the repo type I create... 13:36:25 #info Layered images are special, since they're the ones that can bring in additional non-RPM bits (gem, maven); 1-to-1 mirrors for those could be implemented by RepoFunnel building on Pulp, but it's still not sure whether this middle step is necessary 13:36:46 ncoghlan: thanks for update anyway. 13:36:48 anything else for the topic? anybody? 13:37:08 nope 13:37:10 closing in 1m... 13:38:43 ncoghlan: we are working on being able to build layered images 13:39:43 dgilmore: yeah, a lot of what I say about that I'm actually channelling from Jay Greguske and Adam Miller :) 13:40:26 ncoghlan: okay, just saw you said koji should learn how to do it, just making sure you knew it is underway 13:40:31 I still haven't succeeded in getting any of the JVM folks to join Envs & Stacks though :P 13:40:57 dgilmore: yeah, I knew it was in progress, just couldn't remember if it was "already can" or "will soon" 13:41:07 its will soonish 13:41:33 we plan to build at least the cockpit layered image for f24 13:41:40 and potentially others 13:42:38 #info fedora rel-eng plans to build at least the cockpit layered image for f24 and potentially others 13:43:19 dgilmore: thx for the update as well.. 13:43:33 #endmeeting