13:02:18 <hhorak> #startmeeting Env and Stacks (2014-10-14)
13:02:18 <zodbot> Meeting started Tue Oct 14 13:02:18 2014 UTC.  The chair is hhorak. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:02:18 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:02:23 <hhorak> #meetingname env-and-stacks
13:02:23 <zodbot> The meeting name has been set to 'env-and-stacks'
13:02:30 <hhorak> #chair pkovar tjanez samkottler bkabrda hhorak juhp ncoghlan vpavlin sicampbell
13:02:30 <zodbot> Current chairs: bkabrda hhorak juhp ncoghlan pkovar samkottler sicampbell tjanez vpavlin
13:02:39 <hhorak> #topic init process
13:03:16 <hhorak> Hello, who is here? (sorry for being late a bit)
13:03:42 <nphilipp> Hi!
13:03:46 <bkabrda1> hi, sorry I'm late
13:04:04 <pkovar> hi
13:04:06 * ncoghlan waves
13:04:29 * tflink lurks
13:05:15 <hhorak> tflink: Congrats for the Taskotron launch!
13:05:45 <tflink> hhorak: thanks
13:06:09 <hhorak> #topic Docker, Docker, Docker
13:06:32 <[GNU]> dockah?
13:06:42 <ncoghlan> tflink: indeed, congrats - and we may come back to that later :)
13:06:51 * [GNU] is goern in his other incarnation
13:07:21 <ncoghlan> Dockah!
13:07:26 <ncoghlan> #link https://fedoraproject.org/wiki/Docker
13:07:26 <[GNU]> :)
13:07:59 <hhorak> zdover did a good work, did everybody looked ^?
13:09:44 <bkabrda1> hhorak: nice. I'm just thinking if it isn't better to add user to "docker" group and work without "sudo". at least, that's how I do it and it's very convenient
13:10:08 <hhorak> I was thinking about creating more a bit shorter pages (e.g. Installation into one page, Docker commands into a different, ...)
13:10:28 <[GNU]> maybe a link to https://github.com/fedora-cloud/Fedora-Dockerfiles will help getting people up to speed?
13:10:39 <hhorak> (and include all pages related to docker into Category:Docker)
13:11:25 <bkabrda1> hhorak: not sure. I think that we only need a short general tutorial and then fedora-specific info; for the rest, we can point to upstream documentation, I wouldn't want to duplicate it
13:11:27 <hhorak> [GNU]: right, this one should be there, will add in the end in a second..
13:11:35 <nphilipp> bkabrda1: makes sense
13:12:03 <nphilipp> Likewise, not assuming people use sudo :) (like this, or at all)
13:12:06 <ncoghlan> hhorak: +1 for Category:Docker
13:12:42 <hhorak> bkabrda1: right, duplicating upstream doc is not the way, but we will probably need some more pages, that are fedora-related -- like guidelines for docker, etc..
13:14:13 <bkabrda1> hhorak: maybe a stupid question, but what are guidelines for docker supposed to be?
13:14:48 <pkovar> something similar to http://file.rdu.redhat.com/~mgoldman/jboss-docker-docs/best-practice.html perhaps?
13:15:34 <[GNU]> pkovar, ja :)
13:15:58 <ncoghlan> only not on an internal server ;)
13:16:24 <hhorak> bkabrda1: well, we should have some standards for header, identifying source images, some strategy how to implement dockerfiles (move as much to scripts, not do all comands using RUN, etc...)
13:17:06 <bkabrda1> hhorak: I guess the question is more like "Who are this guidelines supposed to be for?"
13:17:10 <ncoghlan> one interesting approach we're exploring internally is using Ansible to build the images
13:17:37 <ncoghlan> so we can share the playbooks between bare metal, VMs and container image builds
13:17:57 <juhp> hhorak: so kind of an extension to packaging guidelines?  fedora docker best practice, sounds right
13:18:12 <ncoghlan> means we're looking more at the "lightweight VM" usage model rather than the "sandboxed process" one, though
13:18:27 <hhorak> juhp: yeah, best practices seem better :)
13:19:09 <ncoghlan> "recommended" or "suggested" might be better
13:19:21 <juhp> sure
13:19:49 <bkabrda1> ah, that makes it much clearer for me
13:19:53 <hhorak> another example might be general tips: how to deal with state files (files that need to be stored somewhere, if putting them into image or mounting them from outside...)
13:20:56 <hhorak> ncoghlan: you're already looking into building layered images?
13:22:32 <ncoghlan> hhorak: nothing beyond the poking around Vaclav and I did last week
13:23:20 <ncoghlan> for now, publishing Dockerfiles seems to be the way to go, and let folks figure out their own approach to building the images
13:23:42 <juhp> maybe it is good to make a list of ideas for potential content first?
13:24:05 <ncoghlan> if you're asking about the Ansible comments above, that's in the context of doing deployment automation
13:24:47 <ncoghlan> and realising that writing an Ansible script for deployment automation and writing a Dockerfile have a lot in common.
13:25:26 <hhorak> ncoghlan: ah, thanks, sounds interesting..
13:28:32 <juhp> I noticed the fedora-docker files tend to use multiple RUN commands.
13:32:37 <hhorak> juhp: yeah, it's probably not totally wrong, I just read several times that too many RUN commands is not a good practice..
13:32:53 <juhp> right my feeling too
13:32:59 <ncoghlan> hhorak: any actions resulting from this part? Perhaps someone transferring some of Marek's guidelines to the wiki?
13:34:08 <hhorak> ncoghlan: if we're allowed to do so (we should ask him) then it would make great sense to me
13:37:49 <hhorak> anybody willing to do that part?
13:38:42 <ncoghlan> I've got some major deadlines this week & next, so I'll be low key on upstream stuff for a bit - sorry
13:38:56 <hhorak> ncoghlan: sure, np
13:40:28 <hhorak> I'm also a bit covered these days, so let's at least add it to the tasklist
13:40:28 <hhorak> #action hhorak will create a new task about preparing dockerfiles recommended tips
13:41:03 <hhorak> #topic dockerfile_lint
13:42:19 <hhorak> this is kind of related topic.. the recommended things could be tracked using dockerfile_lint (if not MUST rules, than only warnings can be reported, for serious issues errors) ... does it make sense?
13:42:22 <ncoghlan> I think dockerfile_lint came up in the same discussion where Marek's guidelines did
13:42:57 <ncoghlan> my thought was to apply it to the fedora-dockerfiles package via Taskotron
13:43:38 <ncoghlan> (along similar lines to the ticket to run rpmgrill, but not as universal)
13:44:09 <hhorak> that makes sense also to me, but I haven't checked yet what it does in practice right now or if it needs some new checks to be usable
13:45:19 <hhorak> but right now it would be unused in Taskotron anyway, since we do not do anything in Fedora with dockefiles, except packaging them in fedora-dockerfiles, do we?
13:45:20 <ncoghlan> #link https://lists.fedoraproject.org/pipermail/env-and-stacks/2014-October/000565.html
13:45:39 <ncoghlan> just getting a link to the mailing list thread into the minutes
13:45:50 <hhorak> thanks
13:46:20 <hhorak> #info checks to dockerfile_lint might be done in parallel with defining some recommended practices to write dockerfiles
13:48:54 <ncoghlan> I'm also going to kick that one in the direction of the folks now maintaining rpmgrill
13:50:33 <ncoghlan> we've learned the hard way what a pain it can be to deal with linters that don't use a defined error catalog from the start
13:51:48 <hhorak> ncoghlan: good point, some reasonable result format is another thing..
13:52:15 <ncoghlan> dockerfile_lint has labelled rules, which should work as well as a numeric error catalog
13:53:15 <hhorak> but still, unless we start to build layered images in Fedora, I don't see where to run dockerfile_lint -- may it be in %check section of fedora-dockerfiles spec?
13:53:38 <ncoghlan> hhorak: yeah, that would be my suggestion at this point
13:54:55 <hhorak> #idea dockerfile_lint could be run in %check section of fedora-dockerfiles package; dockerfile_lint does not seem to be usable in Taskotron unless we start building layered images in Fedora
13:55:07 <ncoghlan> something like rpmgrill is applicable to any build, but this would need to be more selective than that
13:55:33 <ncoghlan> that said, you *can* do something like scan the build for files that look like Docker files, and scan thoughs
13:55:36 <ncoghlan> *those
13:56:24 <ncoghlan> I've seen that done with Coverity (scan everything, but automatically skip the ones without any C/C++ source files)
13:57:31 <ncoghlan> however, that would only make sense if it became common to sjip Dockerfiles as part of arbitrary RPMs
13:57:33 <hhorak> tflink: actually, I asked about it on Flock, but not sure if anybody had time to look at it -- is taskotron able to execute some tasks only for specified components already?
13:58:47 <tflink> hhorak: not sure I understand your question - only for specified components?
13:58:56 <tflink> oh, I'm a bit slow this morning, apparently
13:59:06 <tflink> it depends on what exactly you're looking to do
13:59:12 <tflink> it's possible but requires code changes
13:59:55 <tflink> at the moment, anyways - it'll be more flexible in the future but the current code that handles job triggering is pretty simplistic right now
14:00:47 <ncoghlan> tflink: no worries - I think that confirms hhorak's suggestion above to look at running it from %check for now, and consider other options later
14:01:02 <hhorak> tflink: ok, thanks, so if it is not against the whole taskotron design, do you want me to submit a RFE so we can track this feature? (it makes sense at least)
14:01:06 <tflink> put another way: it can happen right now, but every change to the list of packages requires a code change from us. however, that's not going to be true in the long term
14:02:03 <tflink> if it's a relatively static list of packages, I'm OK with doing it
14:02:27 <ncoghlan> given that the initial package list has length 1, that may work
14:03:19 <ncoghlan> and Taskotron would cope with warnings better than %check + Koji does
14:03:52 <hhorak> tflink: actually I thought of it like a general feature, so I (as maintainer of package A) could be able to define a task that is executed after every build of package A
14:04:20 <tflink> hhorak: yeah, that's the plan eventually but that's not supported yet
14:05:12 <hhorak> tflink: ok, does it have some tracker so I won't ask you every few months? :)
14:05:22 <tflink> not yet, no
14:06:53 <hhorak> tflink: so I'll probably file a ticket for that if that is fine..
14:07:00 <hhorak> (just for tracking)
14:07:04 <juhp> maybe %check is good enough for now anyway?
14:07:08 <tflink> hhorak: sure, would be appreciated
14:07:22 <hhorak> juhp: I think so
14:08:35 <hhorak> #info taskotron will allow to run some tasks for arbitrary components only, but since it does not do it now we should be fine with running dockerfile_lint in %check for now
14:09:28 <tflink> hhorak: it can handle the use case, it's just not changeable through a public interface
14:10:07 <hhorak> tflink: ok, thanks for clarifying
14:13:56 <hhorak> Well, I did not follow the agenda items entirely today, even though everything related to docker :)
14:14:47 <ncoghlan> hhorak: I think we hit them all except new check ideas of dockerfile_lint
14:14:56 <ncoghlan> and those will come as folks start using it more
14:15:31 <hhorak> ncoghlan: some could also come from the recommended practices..
14:16:21 <hhorak> Anyway, we should probably start to think about delivering layered images, but that might be a topic for some of the next meetings..
14:16:29 <hhorak> since it is too complicated :)
14:17:23 <hhorak> #info we should start to think about delivering layered images during some of the next meetings (or on ML)
14:18:04 <ncoghlan> oh, that reminds me
14:18:23 <ncoghlan> I asked dgilmore to consider joining the Env & Stacks mailing list
14:18:41 <ncoghlan> as I think we could benefit from having the RCM perspective around
14:18:52 <hhorak> really good idea
14:18:53 <ncoghlan> (he's here in Brisbane for a couple of months)
14:20:06 <hhorak> #topic Picking chairman for the next meeting
14:21:13 <hhorak> timeout 3 minutes for volunteer :) and let's merge it with ...
14:21:13 <hhorak> #topic OpenFloor
14:21:36 <hhorak> oh, the time is so fast :)
14:22:53 <nphilipp> hhorak: you're on fesco, right?
14:23:58 <hhorak> nphilipp: no, I'm not
14:24:12 <nphilipp> hhorak: I ask becvause you're listed as fesco liaison...
14:24:59 <hhorak> nphilipp: ah, right, I'm the liaison, but not actually member of fesco.. it was kind of said it is not necessary :)
14:26:45 <nphilipp> hhorak: Heh. I'm not sure if this belongs in this meeting, but regarding bootstrapping -- if we were to implement macros to make packages easier bootstrappable (e.g. by not building docs), and we wanted to do that across the board (e.g. minimal or base pkg set), we'd have to get fesco approval for it, right?
14:27:33 <nphilipp> hhorak: still trying to find our which parts of the fedora next tasks I work on relate to you guys, and which to base wg, or both :)
14:28:13 <juhp> nphilip: what hhorak said - Fesco liason does not have to be a Fesco member: it doesn't hurt if they are of course
14:28:43 <hhorak> nphilipp: you mean like defining some standard RPM macros that would allow bootstraping packages in a common way?
14:28:56 <ncoghlan> nphilipp: and which to the specific language lists (hit that recently with Gradle bootstrapping discussions - those are likely to happen on java-devel)
14:28:58 <nphilipp> hhorak: yes.
14:29:30 <nphilipp> ncoghlan: not sure I understand, what's the context?
14:30:46 <ncoghlan> nphilipp: gradle 2 isn't currently in Fedora, since you need an already built version of Gradle to build it
14:30:54 <nphilipp> hhorak: How detailed would such plans need to be before approaching fesco about approval? I mean, it would probably involve some small blurb for the packaging guidelines (thus touching FPC turf) and so on.
14:30:55 <hhorak> nphilipp: so I'd say the most correct way would be to prepare a concrete proposal (ideally discuss it on devel ML) and then let FPC to approve, so it gets to packaging guildelines
14:31:28 <ncoghlan> nphilipp: some folks are trying to figure out how to tackle that, and the discussions are currently planned to be on java-devel
14:31:36 <nphilipp> hhorak: fair enough, thanks
14:32:21 <nphilipp> ncoghlan: that'd basically be a concrete situation, which wouldn't be fleshed out completely. I'd rather leave this open and not restrict this to e.g. only docs.
14:32:22 <ncoghlan> nphilipp: when you mentioned more general bootstrapping macros, I wondered if they might be applicable to that particular case
14:33:12 <nphilipp> ncoghlan: the bootstrapping macros surely won't help 100% -- just make things easier automatable once you have base to start from
14:33:21 <ncoghlan> nphilipp: sounds good
14:33:38 <hhorak> nphilipp: and after having such proposal approved it might be a Change so people notice it :)
14:33:55 <nphilipp> hhorak: duly noted
14:34:15 <juhp> nphilipp: yes
14:34:42 <nphilipp> ncoghlan: for instance, you could use the bootstrap macro to not build a gui (which won't be needed if the package is used as a build dep)
14:34:50 <hhorak> anyway I was thinking about something like this for some time already but have not got into it; but it would definitely be great..
14:35:15 <juhp> yep
14:36:18 <nphilipp> As long as it's understood that it won't be a panacea, there'll still be stuff we'll have to wing
14:36:26 <hhorak> language stacks have usually issues with bootstrapping (python, perl, ...), so you might get in touch with maintainers of those..
14:36:36 <juhp> generally more higher level packaging macros would be good IMHO
14:37:01 <hhorak> yeah, that really makes sense
14:37:57 <nphilipp> hhorak, juhp: as I'm only concerned with introducing this as an official macro which we can flip to make a package easier bootstrappable, how language stacks e.a. use it is a bit beyond my (official) scope :)
14:38:40 <hhorak> nphilipp: all right :)
14:38:45 <juhp> nphilipp: I hope we could use them for Fedora Haskell packaging too
14:39:23 <nphilipp> I mean we can surely suggest examples (and counter examples), but I don't think we can do much more than just document them as we come across them.
14:39:42 <ncoghlan> juhp: oh, that would be nice - trying to bootstrap ghc is a nightmare :)
14:40:42 <ncoghlan> nphilipp: I took hhorak's suggestion as being more a matter of looking at what the language stacks are *already* doing and extracting those patterns
14:41:07 <ncoghlan> rather than providing macros that seem like they *should* be useful
14:41:17 <juhp> ncoghlan: :)
14:41:33 <juhp> +1
14:41:36 <nphilipp> ncoghlan: do you have pointers to what language stacks are doing, in concrete?
14:41:59 <ncoghlan> nphilipp: e.g Python's docs are built with Sphinx, which needs Python to run. bkabrda1 would know more than I do about how that actually works in practice
14:42:46 <ncoghlan> there's bootstrapping baked into Python's own Makefile (we build a crippled binary to compile the import system, which then lets us build the real one)
14:42:57 <juhp> nphilipp: likely most do to a lesser or greater extent I would imagine
14:43:03 <ncoghlan> but you need a real Sphinx to build the docs
14:43:30 <juhp> I can point you at the ghc (Haskell) ones
14:44:26 <ncoghlan> juhp: oh, I remember why we were having such problems with ghc now - it needed some newer base macros that rhel6/centos6 didn't have
14:44:37 <nphilipp> ncoghlan: I see that the current approach of python-docs is to have it as a separate component. Right, it would be good if we could forgo that.
14:44:54 <juhp> ncoghlan: I see
14:45:13 <nphilipp> juhp: I'm interested to see what ghc does
14:45:54 <juhp> okay I will send you some pointers then
14:45:58 <ncoghlan> juhp: (note that this was over a year ago now, and it's approaching 1 in the morning here, so my memory may be faulty)
14:46:21 <ncoghlan> anyway - thanks all, I'm going to head to bed
14:46:27 * ncoghlan waves
14:46:30 <hhorak> #topic standardized macros for bootstrapping packages
14:46:30 <hhorak> #idea packages bootstraps are implemented without any standardization, but with some rules at least for RPM macros names it might be much more easy to bootstrap packages
14:46:34 <hhorak> ncoghlan: bye
14:48:57 <hhorak> All right, it seems to me like we're done for today.. Thanks everybody!
14:50:15 <hhorak> #endmeeting