From Fedora Project Wiki
Release Engineering Meeting :: Monday 2007-12-10
IRC Transcript
| -!- f13 changed the topic of #fedora-meeting to: Fedora Release Engineering meeting | 13:00 | |
| f13 | ping notting jeremy rdieter wwoods spot lmacken poelcat jwb | 13:01 |
|---|---|---|
| * notting is here | 13:01 | |
| jwb | here | 13:01 |
| rdieter | here | 13:01 |
| jeremy | f13: I'll be back in just a minute | 13:01 |
| * poelcat here | 13:02 | |
| * wwoods here | 13:02 | |
| jeremy | ok | 13:03 |
| f13 | alright. | 13:03 |
| f13 | I suspect spot is sleeping off the jet lag | 13:03 |
| f13 | oh warren ping | 13:03 |
| jeremy | I was talking to him before lunch, but perhaps | 13:03 |
| f13 | well, once again not much on the agenda. | 13:04 |
| f13 | FC6 is dead. | 13:04 |
| wwoods | so long, zod | 13:04 |
| f13 | We're going to try reversing the netapp streams next week | 13:04 |
| f13 | (sync from PHX to other places rather than from RDU) | 13:04 |
| f13 | and we have a buildsystem refresh coming | 13:04 |
| f13 | and a glibc/gcc update coming that could use a mass rebuild | 13:05 |
| * poelcat put out a 2nd request for feature pages | 13:05 | |
| wwoods | I'm working on a rawhide dashboard (http://wwoods.fedorapeople.org/rawhide.html) | 13:05 |
| jeremy | wwoods: coolio | 13:06 |
| jwb | f13, update for what? | 13:06 |
| wwoods | need to find a way to get mash and/or the rawhide sync to send a signal to the rawhide monitor thingy | 13:06 |
| jeremy | jwb: gcc 4.3 | 13:06 |
| wwoods | so the top section(s) of that page get updated after rawhide finishes building/syncing | 13:06 |
| jwb | jeremy, and glibc? | 13:06 |
| poelcat | wwoods: will it signal whether it is installable? | 13:06 |
| jeremy | jwb: no big glibc change that I know of | 13:06 |
| wwoods | poelcat: yes | 13:07 |
| jwb | yet | 13:07 |
| f13 | maybe I was mistaken on the glibc | 13:07 |
| wwoods | poelcat: it checks to see if the tree is there, checks the metadata, checks for boot images | 13:07 |
| jwb | wwoods, so does it have a way to query why something went bad? | 13:07 |
| f13 | re-reading the mail it looks like just gcc | 13:07 |
| wwoods | if there's boot images it will (eventually) launch automatic tests and report those results | 13:07 |
| wwoods | well, it links to the logs | 13:07 |
| wwoods | so you can figure it out | 13:07 |
| jwb | it does? | 13:07 |
| poelcat | f13: glibc goes to 2.8 | 13:08 |
| jwb | oh, i see | 13:08 |
| jwb | poelcat, not until the end | 13:08 |
| jwb | wwoods, odd. a 0 log for ppc | 13:08 |
| poelcat | wwoods: why "make the user figure out it"... why not a clear status that says "WORKY" or "NOWORKY" | 13:08 |
| jwb | anyway, this is cool | 13:08 |
| * poelcat has a daily internal rhts job doing the same thing right now | 13:09 | |
| wwoods | poelcat: there *is* clear status | 13:09 |
| * jwb wonders why ppc has a log size of 0 | 13:09 | |
| wwoods | either "no tree", "bad/missing metadata", "no boot images", or "tree OK" | 13:09 |
| wwoods | followed by results of the attempted install test | 13:10 |
| f13 | jwb: because the pungify-ppc didn't actually comlete | 13:10 |
| f13 | complete | 13:10 |
| jwb | f13, i see that | 13:10 |
| wwoods | will will probably be either "OK" or "FAIL" with a link to anaconda logs | 13:10 |
| f13 | due to an nfs mounting error which I have reported to mmcgrath | 13:10 |
| wwoods | err which will .. | 13:10 |
| jwb | f13, i see that too :) | 13:10 |
| f13 | jwb: I'm going to try it again manually in a few minutes. | 13:10 |
| wwoods | I can't magically determine why anaconda failed when it fails | 13:10 |
| jwb | f13, ok cool | 13:10 |
| wwoods | but there should be obvious pass/fail status | 13:10 |
| wwoods | so yeah. | 13:12 |
| jwb | wwoods, we need the doom-o-meter on there | 13:12 |
| jwb | otherwise it's cool | 13:13 |
| jwb | *crickets* | 13:14 |
| wwoods | ah yes, the doom-o-meter! | 13:14 |
| wwoods | yeah that'll come once I have the other bits working | 13:14 |
| jwb | cool | 13:14 |
| wwoods | but yeah, the main thing is working out a way for the rawhide build/sync process to signal that it's ready for smoke testing | 13:15 |
| f13 | and that has some entertaining details if we reverse the stream | 13:17 |
| notting | f13: actually, it's a lot simpler | 13:17 |
| f13 | since we'd just be doing an rsync to $box in phx as part of compose, and relying upon snapmirror to move the bits around. | 13:17 |
| f13 | notting: we can't tell $process when the bits are ready in RDU | 13:18 |
| notting | f13: but we can tell them when they're ready in phx. which is probably 'close enough' | 13:18 |
| notting | as that's public | 13:18 |
| f13 | but not nfs mountable by wwoods' farm. | 13:19 |
| f13 | which is the problem he's going to face | 13:19 |
| wwoods | I don't need nfs mountability | 13:19 |
| f13 | I thought you did for some tests? | 13:19 |
| wwoods | not really. | 13:19 |
| f13 | (well, the obvious one being nfs install test) | 13:19 |
| wwoods | the stuff is designed to use http/ftp for installs, since that seems to be the typical way people get trees and do network installs | 13:20 |
| f13 | sure, that just means we'll miss nfs install bugs until later (: | 13:20 |
| jeremy | f13: the really scary ones are iso based methods... so meh. | 13:21 |
| f13 | heh | 13:21 |
| wwoods | well, I can set up some stuff to wait for the bits to land in RDU to do local nfs-using tests on a local cluster | 13:21 |
| wwoods | but for doing simple smoke tests | 13:21 |
| wwoods | you kind of want that to happen as soon as the bits are built | 13:21 |
| wwoods | NFS is tier2 | 13:22 |
| * jeremy would be quite happy with some ftp/http smoketesting and isn't going to look a gift horse in the mouth :) | 13:22 | |
| wwoods | a simple %packages --default http kickstart install would make a good basic smoketest | 13:22 |
| wwoods | and/or %packages @base | 13:22 |
| * f13 neither | 13:23 | |
| wwoods | %packages --default kickstart install covers a lot of the key codepaths - if that works we're not completely doomed | 13:23 |
| f13 | by all means, do whatever you can for the love of god (: | 13:23 |
| wwoods | so, hm. if I set up something (e.g. an xmlrpc/cgi thing) could you have it be pinged as soon as the bits are baked? | 13:24 |
| f13 | couldn't you set a watch on a file ? | 13:27 |
| f13 | like if we touched a file that said "all done"? | 13:28 |
| poelcat | wwoods: why can't you go off of internal gridtrees (or whatever it is called) | 13:28 |
| f13 | poelcat: that's not used by Fedora | 13:28 |
| wwoods | because gridtrees is a horrible abomination | 13:28 |
| wwoods | that must be stopped | 13:28 |
| poelcat | but it tells you when a new rawhide tree is there | 13:28 |
| wwoods | and also it's internal-only | 13:28 |
| wwoods | just no. | 13:29 |
| f13 | poelcat: I don't recall any current code that touches gridtrees | 13:29 |
| wwoods | if gridtrees is being updated with rawhide info that's a side-effect or a hack | 13:29 |
| wwoods | horrible deprecated | 13:29 |
| wwoods | ugh | 13:29 |
| wwoods | the entire point of having .composeinfo/.treeinfo was to stop using gridtrees | 13:29 |
| f13 | yeah, no rawhide content in gridtrees | 13:29 |
| wwoods | you really really really don't want multiple processes writing the same file over NFS | 13:30 |
| f13 | yes, much doomage | 13:30 |
| f13 | wwoods: so theoretically we can "ping" you in some form. | 13:30 |
| f13 | the most simple way possible would be preferred | 13:30 |
| wwoods | f13: yeah, if you write a given file last | 13:31 |
| wwoods | or atomically move the tree into place after syncing it to a temp location | 13:31 |
| f13 | actually, the repodata files are synced last | 13:31 |
| wwoods | I'd prefer that the signal was a push rather than having to poll | 13:31 |
| f13 | but you're right | 13:31 |
| jwb | thinking generally, it might be nice to have a compose framework | 13:31 |
| f13 | a very simplistic push would be best | 13:31 |
| jwb | ala, koji, but for composes | 13:31 |
| f13 | jwb: and what would it do? | 13:32 |
| jwb | something the secondary arches could plug into to get notification of mashing and send it when they've finished composing | 13:32 |
| wwoods | f13: right. I can set up a .cgi and you can just do something like 'wget ${cgi_url}?newtree=${dirname}' | 13:32 |
| wwoods | or similar | 13:33 |
| f13 | nod | 13:33 |
| wwoods | or just ${cgi_url}?dopoll=true | 13:33 |
| wwoods | whatevs | 13:33 |
| f13 | jwb: ok, yeah, I had at one point evisioned a big communication bus between things like bodhi, koji, composes, etc... that things could subscribe too just for notifications ( police scanner ) , drop messages on, or otherwise react to calls. | 13:34 |
| jwb | yeah | 13:34 |
| wwoods | yeah, we've talked about that in QA-land as well | 13:34 |
| notting | f13: dbus++? | 13:34 |
| wwoods | there's messaging stuff going on in RH (aqmp for example) but those are a bit fancy for us, I think | 13:34 |
| notting | f13: steroiD-bus? | 13:34 |
| jwb | notting, er fbus man | 13:34 |
| wwoods | dbus supports multihost stuff, doesn't it? | 13:35 |
| jwb | does it? | 13:35 |
| wwoods | it has some vestigial support for doing that anyway | 13:35 |
| jwb | where's J5? | 13:35 |
| wwoods | there's a tcp transport for dbus | 13:35 |
| J5 | jwb: here | 13:35 |
| jwb | J5, can dbus do multihost stuff? | 13:35 |
| jwb | easily? | 13:35 |
| jwb | so that a 5 year old could code something up? | 13:35 |
| J5 | multihost? | 13:35 |
| jwb | J5, machine 1 sends an event on the bus and machines 2-5 get it | 13:36 |
| wwoods | it's not very well documented IIRC, but you can do stuff like: <listen>tcp:host=localhost,port=12434</listen> | 13:36 |
| wwoods | in dbus system.conf | 13:36 |
| jwb | wwoods, is there an equivalent broadcast? | 13:36 |
| wwoods | you'd think you could use multicast for that | 13:36 |
| wwoods | but now I'm speculating wildly | 13:37 |
| J5 | jwb: ya, not sure what our tcp support is like | 13:37 |
| notting | maybe amqp is better for this | 13:37 |
| * jwb shrugs | 13:37 | |
| J5 | we are primarily a local bus | 13:37 |
| jwb | that's what i thought | 13:37 |
| J5 | tubes has multicast support I think | 13:37 |
| J5 | we do dbus over tubes on the OLPC | 13:38 |
| wwoods | that sounds like it might be the Right Thing To Do | 13:38 |
| f13 | "tubes" | 13:39 |
| wwoods | oh, so tubes is.. basically dbus over xmpp? | 13:39 |
| J5 | wwoods: tubes abstracts the transport | 13:40 |
| wwoods | well, details aside because.. yeah | 13:40 |
| wwoods | heh | 13:40 |
| J5 | xmpp is one of the transports | 13:40 |
| wwoods | but yeah. sounds like Tubes is the answer for "dbus over network" | 13:40 |
| f13 | so... | 13:41 |
| f13 | we're pretty far off in the weeds | 13:41 |
| wwoods | right. that's like a post-f9/f10 kind of target | 13:41 |
| jwb | sure | 13:41 |
| f13 | wwoods: if you get something simple up that can be poked via urllib or whatnot, let us know and we will update the compose job | 13:41 |
| wwoods | for testing f9 I'll set up some cutely stupid cgi that you can poke | 13:41 |
| f13 | but under a similar topic of 'weeds', who all is going to be at FUDCon? | 13:41 |
| f13 | and if there is a number of us, should we get together and voice some things out? | 13:42 |
| notting | i suppose i can make the trip | 13:42 |
| wwoods | since F9 is going to become RHEL6 when it gets growed up, the RHEL QA guys are going to be working on F9/rawhide testing | 13:42 |
| f13 | notting: now kind of you | 13:42 |
| wwoods | yeah I'll probably be at FUDCon, seeing as it's, y'know, here | 13:42 |
| notting | f13: heh | 13:42 |
| notting | f13: i suspect if i try and expense travel someone will laugh at me | 13:42 |
| f13 | notting: sadly, you could probably get away with it | 13:43 |
| notting | f13: are you coming? | 13:45 |
| f13 | yes | 13:46 |
| f13 | I'm assuming wwoods will be there | 13:48 |
| * jeremy isn't going to be at fudcon | 13:48 | |
| f13 | and j5 will be | 13:48 |
| wwoods | I'll be there, yeah. | 13:49 |
| f13 | well maybe will figure out something to do then. | 13:49 |
| f13 | On the signing server front, I think Mike McGrath is ready for testing new hosted environment, and we're going to be fodder. | 13:49 |
| jwb | cool | 13:50 |
| f13 | so we may ahve a public repo in the next day or 3. Luke and I are going to get together and hash out some of the API stuff, and I think I'm going ot let him work on the server side, and I'll focus on a fedora specific client for it that deals with koji and figuring out /what/ to sign and where to import the signed copy from | 13:50 |
| lmacken | I did a bunch of hacking on the signing server over the weekend | 13:51 |
| f13 | this may need a new koji call, to be able to import from 'relative' location, relative to the koji server. | 13:51 |
| lmacken | it's almost ready for testing | 13:51 |
| f13 | cool | 13:51 |
| f13 | Are there any other topics people would like to discuss? | 13:53 |
| * wwoods sits on hands | 13:54 | |
| jwb | oh, i will not be at FUDCon | 13:55 |
| f13 | darn | 13:55 |
| jwb | no surprise there | 13:55 |
| f13 | jwb: what about the Boston one with RH Summit attached? | 13:55 |
| jwb | when is that? | 13:55 |
| f13 | June 18-20 | 13:56 |
| f13 | although I may not actually be around then, let me check. | 13:56 |
| jwb | i'll try to get to that one | 13:58 |
| f13 | anywho, hours up, seems we're done. Back on your heads! | 13:58 |
| -!- f13 changed the topic of #fedora-meeting to: Channel is used by various Fedora groups and committees for their regular meetings | Note that meetings often get logged | For questions about using Fedora please ask in #fedora | See ttp://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel for meeting schedule | 13:58 | |
| --- Log closed Mon Dec 10 20:53:28 2007 | ||
Generated by irclog2html.py 2.3 by Marius Gedminas - find it at mg.pov.lt!