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