15:02:53 <pknirsch> #startmeeting Fedora Base Design Working Group (2014-10-17)
15:02:53 <zodbot> Meeting started Fri Oct 17 15:02:53 2014 UTC.  The chair is pknirsch. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:53 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:03:07 <pknirsch> #meetingname  Fedora Base Design Working Group
15:03:07 <zodbot> The meeting name has been set to 'fedora_base_design_working_group'
15:03:13 <pknirsch> Hello everyone!
15:03:16 <nphilipp> Hi!
15:03:20 <dazo> hi!
15:03:45 <pknirsch> #chair jreznik dgilmore-bne masta vpavlin msekleta
15:03:45 <zodbot> Current chairs: dgilmore-bne jreznik masta msekleta pknirsch vpavlin
15:04:06 <pknirsch> alright, lets jump right into the first topic
15:04:09 <jreznik> hi!
15:04:19 <msekleta> hello!
15:04:21 <pknirsch> #topic Status buildrequires cleanup work (davids & nils!)
15:04:30 <pknirsch> so dazo nphilipp, any news yet?
15:05:06 <nphilipp> so...
15:05:14 <dazo> Not too much.  We've had some discussions with a taskatron guy and looked at possible approaches
15:06:10 <nphilipp> and had a longer phone call where we discussed things in more detail which we didn't get to at the last meeting
15:06:39 <dazo> I think right now we're not convinced taskatron is the best way of implementing it, but taskatron may be modified towards our needs.  But we got aware of koschei, which also does some rebuilds when there are resources available
15:06:52 <nphilipp> I have a machine for anything that needs persisting, e.g. result data
15:07:47 <dazo> koschei is doing something along the same road as buildreq-check, but it tests for "build-ability", while we test if the buildreqs are too invasive
15:07:53 <nphilipp> dazo: if you give me a PW hash and desired username I'll add a user on swirl.str.redhat.com
15:08:13 <dazo> nphilipp: cool!  I'll do that soonish :)
15:08:54 <dazo> Other than that, I've been pondering how to collect and structure the results buildreq-check gives us (from a database model perspective, that is)
15:09:08 <nphilipp> dazo: I'm not quite convinced koschei is the way to go, because some optimization stuff can't be done when using koji vs. local mock.
15:09:16 <nphilipp> dazo: cool, share
15:09:37 <dazo> I don't have anything yet to share ... it's a complete mess in my head currently :)
15:09:47 <nphilipp> DUMP THE BRANE
15:10:05 <dazo> nphilipp: that's probably not safe for a workplace ;-)
15:10:13 <nphilipp> heh
15:11:27 <dazo> I agree that koschei might not implement the optimization we discussed ... but maybe we should see if this could be integrated with buildcheck-reqs anyway, and see if koschei could also benefit from our optimization thoughts
15:11:43 <nphilipp> yes
15:11:46 <dazo> https://github.com/msimacek/koschei
15:11:57 <nphilipp> at least check if we can steal something from it :D
15:12:04 <dazo> yeah :)
15:13:09 <nphilipp> Talking about storing results, I'm not yet sure if and for how long we should retain the raw results like build logs etc. I'm just sure that we shouldn't dump them directly into the database however :).
15:14:04 <nphilipp> Raw result data is probably more interesting for debugging and tuning the buildreq_check tool, rather than using it.
15:14:14 <nphilipp> Maybe.
15:15:37 <dazo> I've also on the side been toying slightly with openshift.redhat.com as a way to present the reports ... and will test if that's a good approach or not.  As Fedora infra doesn't use openshift but prefer RPM packages, it may not be the ideal approach.  But I'd like to ensure that what we build can easily be adopted to fit into an openshift framework (where everything from deployment to day-to-day sysadmin maintenance is automated)
15:16:41 <dazo> Regarding retaining results ... I'd say we don't need it for many weeks.  Probably just a few weeks, unless there's something being broken for a very long time
15:16:57 <nphilipp> Yes
15:17:13 <dazo> (two weeks from the last successful build otherwise 8 weeks maybe?)
15:17:29 <nphilipp> And we can likely reproduce that by just submitting the same builds
15:17:36 <dazo> exactly
15:18:01 <dazo> maybe 2 and 8 weeks is way too much.  Maybe even 1+4 is more than enough
15:18:19 <nphilipp> Or make it be driven by available space. If space goes down, the oldest result sets are deleted.
15:18:29 <dazo> that works too
15:19:12 <dazo> pknirsch: is that enough of an update?
15:19:24 <pknirsch> sounds good!
15:19:48 <pknirsch> when do you think you guys can do a pro-forma test run of the base package set
15:19:51 <nphilipp> dazo: re openshift/docker/containerizing -- someone mentioned and I repeated using Ansible for provisioning. Then it doesn't matter much if you do that on bare metal, in a VM, or whatever.
15:19:51 <pknirsch> just to get a rough feeling
15:20:02 <nphilipp> We might look into that as well.
15:20:45 <nphilipp> pknirsch: Color me ignorant, but where is "base package set" defined? I mean, it originates here, but there must be a document or something...
15:21:44 <dazo> nphilipp: okay, ansible is more useful when work on the infrastructure level (VMs, container management and such).  For openshift, all you need to do is to write code and tell openshift which dependencies you have and need.  Openshift will then do everything from deployment to ensuring the service is running for you completely
15:22:07 <pknirsch> hm, i thought i had linked them from http://fedoraproject.org/wiki/Base
15:22:10 <nphilipp> dazo: what does it do for configuration?
15:22:13 <pknirsch> but seems i forgot the work harald and me did
15:22:19 <pknirsch> let me sublink it from there
15:22:53 <dazo> nphilipp: openshift configures everything for you, based on a few things put into the git repo you push to the openshift instance you use
15:22:57 <nphilipp> pknirsch: re your question, I need to go a bit farther afield.
15:23:02 <nphilipp> dazo: ahh
15:23:05 <pknirsch> basically: http://harald.fedorapeople.org/kernel-br-all.txt
15:24:32 <dazo> nphilipp: that's one of the reasons I'm looking into openshift.  We don't need to think much about sys-admin things at all.  Just need to write the code and push it out, the rest is "magic" and it works :)
15:24:44 <nphilipp> pknirsch: the primary issue why I haven't simply written a script to just chug through such a list (which is what Marcela and Radek would prefer, much ;-) is that we don't have a beefy enough machine for the rebuilds for ourselves and however long it takes to finish that.
15:25:12 <pknirsch> nphilipp: have you talked with karsten about using our p7+ here in STR?
15:25:18 <pknirsch> thats plenty beefy :)
15:26:47 <nphilipp> pknirsch: we talked to tflink (taskotron maint) and he said may have a machine he could spare us, but he needed to check with a colleague first. We haven't heard back from him since Wed and he's on PTO until next Tuesday~Thursday (that wasn't quite clear when we talked).
15:27:26 <pknirsch> nphilipp: so poke karsten on Monday. I know moben used the P7 as well for some of his tests
15:28:13 <nphilipp> pknirsch: We can ask Karsten, but I'm not sure about the influence of doing these tests on Power and getting results that are valid for x86/64 in all cases.
15:28:32 <nphilipp> Anyway getting back to the bed-time story ;-):
15:28:35 <pknirsch> sure, but it's just for getting a test :)
15:28:57 <pknirsch> and a rough guestimate of how long this actually takes
15:29:20 <nphilipp> pknirsch: right, we'd need to take this into account then if we want to reuse the results later
15:29:40 <pknirsch> aye
15:29:59 <pknirsch> but as a test bed/staging/development system for larger tests it's a good start
15:30:22 <pknirsch> ofc having a beefier x86 on permanent loan definitely is better
15:30:23 <pknirsch> :)
15:30:35 <dazo> pknirsch: I believe we need one week to get data models and the required code to process reports, and maybe another 2 weeks to get the buildreq-check process automated ... I'm not sacrificing my soul to this schedule, but I think it's somewhat reasonable
15:31:04 <pknirsch> cool dazo, not nailing you to the wall then with the schedule ;)
15:31:36 <dazo> I'm not 100% sure we need to care too much about arches ... unless there are packages which have arch-specific %if blocks
15:31:37 <nphilipp> pknirsch: yes -- I have in mind something that picks from the list of available "latest builds", making a heuristic guess which should be processed next, depending on when the package was checked last and so forth.
15:31:48 <nphilipp> dazo: there are
15:32:06 <nphilipp> I plan to at least keep that in mind.
15:32:58 <nphilipp> We could e.g. store on which arch a run was conducted for a specific package, then rotate through the arches.
15:33:16 <nphilipp> (For which we have worker machines)
15:33:38 * pknirsch nods at dazo
15:34:00 <dazo> nphilipp: I know we have packages with arch tweaks ... but I don't think we need to care for arches at all which does not do that
15:34:25 <dazo> I meant, we don't need to care for arches on packages which does not do arch tweaks
15:34:53 <nphilipp> dazo: that's an assumption I'm not willing to make lightly
15:35:17 <nphilipp> Or wait a sec.
15:35:20 <nphilipp> Scratch that.
15:35:37 <dazo> :)
15:36:20 <nphilipp> In the light of that actual humans would process the results and nothing happens automatically, simply rotating through arches should eventually find even those build reqs which can be scrapped only on certain architectures.
15:37:21 <nphilipp> My gut reading is that it'll take very long to get all packages processed anyway, it will potentially  just take even longer for these packages.
15:37:49 <nphilipp> As long as we're not talking optima, I can live with that.
15:38:19 <dazo> okay
15:38:45 <nphilipp> Anyhow, back to what I wanted to cram in before this gets too much into detail and pknirsch changes to the next topic:
15:38:51 <pknirsch> :)
15:39:18 <dazo> (harald's list contains 1806 packages, so that'll be a decent enough list to walk through)
15:39:38 * pknirsch nods
15:40:10 <nphilipp> Because we need the DB and processing infra anyway, I'd rather not make this too dumb in order to save work later when we target it for production.
15:41:19 <pknirsch> right
15:41:29 <nphilipp> Still simple -- e.g. the heuristic can simply be "pick a random unprocessed package" -- but a bit more than just for i in $packages; do buildreq_check ... > $i.results; done
15:41:58 <dazo> yupp
15:42:45 <nphilipp> With that, we might be better able to look into the ongoing test run and refine our guesses when this will finish, or make preliminary analysis over the already processed packages.
15:44:15 <nphilipp> And that concludes my scheduled rambling for today. :D
15:44:20 <pknirsch> :)
15:45:26 <pknirsch> alright, lets quickly open the floor
15:45:33 <pknirsch> thanks guys!
15:45:45 <pknirsch> #topic Open Floor
15:46:01 <pknirsch> as i didn't have any other topics for today lets see if anyone else has anything
15:46:24 <pknirsch> msekleta, jreznik, you guys have anything for today?
15:46:51 <jreznik> no, I don't have
15:47:20 <msekleta> pknirsch, I am on Plumbers conf, got some stuff sorted out, will report next week.
15:47:31 <pknirsch> msekleta: cool, thanks!
15:47:53 <msekleta> gotta get out of the venue to the hotel and off to party :)
15:48:05 <pknirsch> have fun!
15:48:17 <msekleta> pknirsch, thanks
15:48:19 <pknirsch> alright, with that, thanks guys!
15:48:24 <pknirsch> have a great weekend!
15:48:32 <dazo> u2!
15:48:37 <nphilipp> bye!
15:48:42 <msekleta> great weekend everyone
15:48:48 <pknirsch> #endmeeting