13:02:18 #startmeeting Env and Stacks (2014-10-14) 13:02:18 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 13:02:23 #meetingname env-and-stacks 13:02:23 The meeting name has been set to 'env-and-stacks' 13:02:30 #chair pkovar tjanez samkottler bkabrda hhorak juhp ncoghlan vpavlin sicampbell 13:02:30 Current chairs: bkabrda hhorak juhp ncoghlan pkovar samkottler sicampbell tjanez vpavlin 13:02:39 #topic init process 13:03:16 Hello, who is here? (sorry for being late a bit) 13:03:42 Hi! 13:03:46 hi, sorry I'm late 13:04:04 hi 13:04:06 * ncoghlan waves 13:04:29 * tflink lurks 13:05:15 tflink: Congrats for the Taskotron launch! 13:05:45 hhorak: thanks 13:06:09 #topic Docker, Docker, Docker 13:06:32 <[GNU]> dockah? 13:06:42 tflink: indeed, congrats - and we may come back to that later :) 13:06:51 * [GNU] is goern in his other incarnation 13:07:21 Dockah! 13:07:26 #link https://fedoraproject.org/wiki/Docker 13:07:26 <[GNU]> :) 13:07:59 zdover did a good work, did everybody looked ^? 13:09:44 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 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 (and include all pages related to docker into Category:Docker) 13:11:25 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 [GNU]: right, this one should be there, will add in the end in a second.. 13:11:35 bkabrda1: makes sense 13:12:03 Likewise, not assuming people use sudo :) (like this, or at all) 13:12:06 hhorak: +1 for Category:Docker 13:12:42 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 hhorak: maybe a stupid question, but what are guidelines for docker supposed to be? 13:14:48 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 only not on an internal server ;) 13:16:24 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 hhorak: I guess the question is more like "Who are this guidelines supposed to be for?" 13:17:10 one interesting approach we're exploring internally is using Ansible to build the images 13:17:37 so we can share the playbooks between bare metal, VMs and container image builds 13:17:57 hhorak: so kind of an extension to packaging guidelines? fedora docker best practice, sounds right 13:18:12 means we're looking more at the "lightweight VM" usage model rather than the "sandboxed process" one, though 13:18:27 juhp: yeah, best practices seem better :) 13:19:09 "recommended" or "suggested" might be better 13:19:21 sure 13:19:49 ah, that makes it much clearer for me 13:19:53 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 ncoghlan: you're already looking into building layered images? 13:22:32 hhorak: nothing beyond the poking around Vaclav and I did last week 13:23:20 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 maybe it is good to make a list of ideas for potential content first? 13:24:05 if you're asking about the Ansible comments above, that's in the context of doing deployment automation 13:24:47 and realising that writing an Ansible script for deployment automation and writing a Dockerfile have a lot in common. 13:25:26 ncoghlan: ah, thanks, sounds interesting.. 13:28:32 I noticed the fedora-docker files tend to use multiple RUN commands. 13:32:37 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 right my feeling too 13:32:59 hhorak: any actions resulting from this part? Perhaps someone transferring some of Marek's guidelines to the wiki? 13:34:08 ncoghlan: if we're allowed to do so (we should ask him) then it would make great sense to me 13:37:49 anybody willing to do that part? 13:38:42 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 ncoghlan: sure, np 13:40:28 I'm also a bit covered these days, so let's at least add it to the tasklist 13:40:28 #action hhorak will create a new task about preparing dockerfiles recommended tips 13:41:03 #topic dockerfile_lint 13:42:19 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 I think dockerfile_lint came up in the same discussion where Marek's guidelines did 13:42:57 my thought was to apply it to the fedora-dockerfiles package via Taskotron 13:43:38 (along similar lines to the ticket to run rpmgrill, but not as universal) 13:44:09 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 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 #link https://lists.fedoraproject.org/pipermail/env-and-stacks/2014-October/000565.html 13:45:39 just getting a link to the mailing list thread into the minutes 13:45:50 thanks 13:46:20 #info checks to dockerfile_lint might be done in parallel with defining some recommended practices to write dockerfiles 13:48:54 I'm also going to kick that one in the direction of the folks now maintaining rpmgrill 13:50:33 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 ncoghlan: good point, some reasonable result format is another thing.. 13:52:15 dockerfile_lint has labelled rules, which should work as well as a numeric error catalog 13:53:15 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 hhorak: yeah, that would be my suggestion at this point 13:54:55 #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 something like rpmgrill is applicable to any build, but this would need to be more selective than that 13:55:33 that said, you *can* do something like scan the build for files that look like Docker files, and scan thoughs 13:55:36 *those 13:56:24 I've seen that done with Coverity (scan everything, but automatically skip the ones without any C/C++ source files) 13:57:31 however, that would only make sense if it became common to sjip Dockerfiles as part of arbitrary RPMs 13:57:33 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 hhorak: not sure I understand your question - only for specified components? 13:58:56 oh, I'm a bit slow this morning, apparently 13:59:06 it depends on what exactly you're looking to do 13:59:12 it's possible but requires code changes 13:59:55 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 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 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 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 if it's a relatively static list of packages, I'm OK with doing it 14:02:27 given that the initial package list has length 1, that may work 14:03:19 and Taskotron would cope with warnings better than %check + Koji does 14:03:52 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 hhorak: yeah, that's the plan eventually but that's not supported yet 14:05:12 tflink: ok, does it have some tracker so I won't ask you every few months? :) 14:05:22 not yet, no 14:06:53 tflink: so I'll probably file a ticket for that if that is fine.. 14:07:00 (just for tracking) 14:07:04 maybe %check is good enough for now anyway? 14:07:08 hhorak: sure, would be appreciated 14:07:22 juhp: I think so 14:08:35 #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 hhorak: it can handle the use case, it's just not changeable through a public interface 14:10:07 tflink: ok, thanks for clarifying 14:13:56 Well, I did not follow the agenda items entirely today, even though everything related to docker :) 14:14:47 hhorak: I think we hit them all except new check ideas of dockerfile_lint 14:14:56 and those will come as folks start using it more 14:15:31 ncoghlan: some could also come from the recommended practices.. 14:16:21 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 since it is too complicated :) 14:17:23 #info we should start to think about delivering layered images during some of the next meetings (or on ML) 14:18:04 oh, that reminds me 14:18:23 I asked dgilmore to consider joining the Env & Stacks mailing list 14:18:41 as I think we could benefit from having the RCM perspective around 14:18:52 really good idea 14:18:53 (he's here in Brisbane for a couple of months) 14:20:06 #topic Picking chairman for the next meeting 14:21:13 timeout 3 minutes for volunteer :) and let's merge it with ... 14:21:13 #topic OpenFloor 14:21:36 oh, the time is so fast :) 14:22:53 hhorak: you're on fesco, right? 14:23:58 nphilipp: no, I'm not 14:24:12 hhorak: I ask becvause you're listed as fesco liaison... 14:24:59 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 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 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 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 nphilipp: you mean like defining some standard RPM macros that would allow bootstraping packages in a common way? 14:28:56 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 hhorak: yes. 14:29:30 ncoghlan: not sure I understand, what's the context? 14:30:46 nphilipp: gradle 2 isn't currently in Fedora, since you need an already built version of Gradle to build it 14:30:54 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 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 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 hhorak: fair enough, thanks 14:32:21 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 nphilipp: when you mentioned more general bootstrapping macros, I wondered if they might be applicable to that particular case 14:33:12 ncoghlan: the bootstrapping macros surely won't help 100% -- just make things easier automatable once you have base to start from 14:33:21 nphilipp: sounds good 14:33:38 nphilipp: and after having such proposal approved it might be a Change so people notice it :) 14:33:55 hhorak: duly noted 14:34:15 nphilipp: yes 14:34:42 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 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 yep 14:36:18 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 language stacks have usually issues with bootstrapping (python, perl, ...), so you might get in touch with maintainers of those.. 14:36:36 generally more higher level packaging macros would be good IMHO 14:37:01 yeah, that really makes sense 14:37:57 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 nphilipp: all right :) 14:38:45 nphilipp: I hope we could use them for Fedora Haskell packaging too 14:39:23 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 juhp: oh, that would be nice - trying to bootstrap ghc is a nightmare :) 14:40:42 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 rather than providing macros that seem like they *should* be useful 14:41:17 ncoghlan: :) 14:41:33 +1 14:41:36 ncoghlan: do you have pointers to what language stacks are doing, in concrete? 14:41:59 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 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 nphilipp: likely most do to a lesser or greater extent I would imagine 14:43:03 but you need a real Sphinx to build the docs 14:43:30 I can point you at the ghc (Haskell) ones 14:44:26 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 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 ncoghlan: I see 14:45:13 juhp: I'm interested to see what ghc does 14:45:54 okay I will send you some pointers then 14:45:58 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 anyway - thanks all, I'm going to head to bed 14:46:27 * ncoghlan waves 14:46:30 #topic standardized macros for bootstrapping packages 14:46:30 #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 ncoghlan: bye 14:48:57 All right, it seems to me like we're done for today.. Thanks everybody! 14:50:15 #endmeeting