ReleaseEngineering/Meetings/2007-dec-10

From FedoraProject

Jump to: navigation, search

Release Engineering Meeting :: Monday 2007-12-10

IRC Transcript

-!- f13 changed the topic of #fedora-meeting to: Fedora Release Engineering meeting13:00
f13ping notting jeremy rdieter wwoods spot lmacken poelcat jwb13:01
* notting is here13:01
jwbhere13:01
rdieterhere13:01
jeremyf13: I'll be back in just a minute13:01
* poelcat here13:02
* wwoods here13:02
jeremyok13:03
f13alright.13:03
f13I suspect spot is sleeping off the jet lag13:03
f13oh warren ping13:03
jeremyI was talking to him before lunch, but perhaps13:03
f13well, once again not much on the agenda.13:04
f13FC6 is dead.13:04
wwoodsso long, zod13:04
f13We're going to try reversing the netapp streams next week13:04
f13(sync from PHX to other places rather than from RDU)13:04
f13and we have a buildsystem refresh coming13:04
f13and a glibc/gcc update coming that could use a mass rebuild13:05
* poelcat put out a 2nd request for feature pages13:05
wwoodsI'm working on a rawhide dashboard (http://wwoods.fedorapeople.org/rawhide.html)13:05
jeremywwoods: coolio13:06
jwbf13, update for what?13:06
wwoodsneed to find a way to get mash and/or the rawhide sync to send a signal to the rawhide monitor thingy13:06
jeremyjwb: gcc 4.313:06
wwoodsso the top section(s) of that page get updated after rawhide finishes building/syncing13:06
jwbjeremy, and glibc?13:06
poelcatwwoods: will it signal whether it is installable?13:06
jeremyjwb: no big glibc change that I know of13:06
wwoodspoelcat: yes13:07
jwbyet13:07
f13maybe I was mistaken on the glibc13:07
wwoodspoelcat: it checks to see if the tree is there, checks the metadata, checks for boot images13:07
jwbwwoods, so does it have a way to query why something went bad?13:07
f13re-reading the mail it looks like just gcc13:07
wwoodsif there's boot images it will (eventually) launch automatic tests and report those results13:07
wwoodswell, it links to the logs13:07
wwoodsso you can figure it out13:07
jwbit does?13:07
poelcatf13: glibc goes to 2.813:08
jwboh, i see13:08
jwbpoelcat, not until the end13:08
jwbwwoods, odd.  a 0 log for ppc13:08
poelcatwwoods: why "make the user figure out it"... why not a clear status that says "WORKY" or "NOWORKY"13:08
jwbanyway, this is cool13:08
* poelcat has a daily internal rhts job doing the same thing right now13:09
wwoodspoelcat: there *is* clear status13:09
* jwb wonders why ppc has a log size of 013:09
wwoodseither "no tree", "bad/missing metadata", "no boot images", or "tree OK"13:09
wwoodsfollowed by results of the attempted install test13:10
f13jwb: because the pungify-ppc didn't actually comlete13:10
f13complete13:10
jwbf13, i see that13:10
wwoodswill will probably be either "OK" or "FAIL" with a link to anaconda logs13:10
f13due to an nfs mounting error which I have reported to mmcgrath13:10
wwoodserr which will ..13:10
jwbf13, i see that too :)13:10
f13jwb: I'm going to try it again manually in a few minutes.13:10
wwoodsI can't magically determine why anaconda failed when it fails13:10
jwbf13, ok cool13:10
wwoodsbut there should be obvious pass/fail status13:10
wwoodsso yeah.13:12
jwbwwoods, we need the doom-o-meter on there13:12
jwbotherwise it's cool13:13
jwb*crickets*13:14
wwoodsah yes, the doom-o-meter!13:14
wwoodsyeah that'll come once I have the other bits working13:14
jwbcool13:14
wwoodsbut yeah, the main thing is working out a way for the rawhide build/sync process to signal that it's ready for smoke testing13:15
f13and that has some entertaining details if we reverse the stream13:17
nottingf13: actually, it's a lot simpler13:17
f13since 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
f13notting: we can't tell $process when the bits are ready in RDU13:18
nottingf13: but we can tell them when they're ready in phx. which is probably 'close enough'13:18
nottingas that's public13:18
f13but not nfs mountable by wwoods' farm.13:19
f13which is the problem he's going to face13:19
wwoodsI don't need nfs mountability13:19
f13I thought you did for some tests?13:19
wwoodsnot really.13:19
f13(well, the obvious one being nfs install test)13:19
wwoodsthe stuff is designed to use http/ftp for installs, since that seems to be the typical way people get trees and do network installs13:20
f13sure, that just means we'll miss nfs install bugs until later (:13:20
jeremyf13: the really scary ones are iso based methods... so meh.13:21
f13heh13:21
wwoodswell, I can set up some stuff to wait for the bits to land in RDU to do local nfs-using tests on a local cluster13:21
wwoodsbut for doing simple smoke tests13:21
wwoodsyou kind of want that to happen as soon as the bits are built13:21
wwoodsNFS is tier213: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
wwoodsa simple %packages --default http kickstart install would make a good basic smoketest13:22
wwoodsand/or %packages @base13:22
* f13 neither13:23
wwoods%packages --default kickstart install covers a lot of the key codepaths - if that works we're not completely doomed13:23
f13by all means, do whatever you can for the love of god (:13:23
wwoodsso, 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
f13couldn't you set a watch on a file ?13:27
f13like if we touched a file that said "all done"?13:28
poelcatwwoods: why can't you go off of internal gridtrees (or whatever it is called)13:28
f13poelcat: that's not used by Fedora13:28
wwoodsbecause gridtrees is a horrible abomination13:28
wwoodsthat must be stopped13:28
poelcatbut it tells you when a new rawhide tree is there13:28
wwoodsand also it's internal-only13:28
wwoodsjust no.13:29
f13poelcat: I don't recall any current code that touches gridtrees13:29
wwoodsif gridtrees is being updated with rawhide info that's a side-effect or a hack13:29
wwoodshorrible deprecated13:29
wwoodsugh13:29
wwoodsthe entire point of having .composeinfo/.treeinfo was to stop using gridtrees13:29
f13yeah, no rawhide content in gridtrees13:29
wwoodsyou really really really don't want multiple processes writing the same file over NFS13:30
f13yes, much doomage13:30
f13wwoods: so theoretically we can "ping" you in some form.13:30
f13the most simple way possible would be preferred13:30
wwoodsf13: yeah, if you write a given file last13:31
wwoodsor atomically move the tree into place after syncing it to a temp location13:31
f13actually, the repodata files are synced last13:31
wwoodsI'd prefer that the signal was a push rather than having to poll13:31
f13but you're right13:31
jwbthinking generally, it might be nice to have a compose framework13:31
f13a very simplistic push would be best13:31
jwbala, koji, but for composes13:31
f13jwb: and what would it do?13:32
jwbsomething the secondary arches could plug into to get notification of mashing and send it when they've finished composing13:32
wwoodsf13: right. I can set up a .cgi and you can just do something like 'wget ${cgi_url}?newtree=${dirname}'13:32
wwoodsor similar13:33
f13nod13:33
wwoodsor just ${cgi_url}?dopoll=true13:33
wwoodswhatevs13:33
f13jwb: 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
jwbyeah13:34
wwoodsyeah, we've talked about that in QA-land as well13:34
nottingf13: dbus++?13:34
wwoodsthere's messaging stuff going on in RH (aqmp for example) but those are a bit fancy for us, I think13:34
nottingf13: steroiD-bus?13:34
jwbnotting, er fbus man13:34
wwoodsdbus supports multihost stuff, doesn't it?13:35
jwbdoes it?13:35
wwoodsit has some vestigial support for doing that anyway13:35
jwbwhere's J5?13:35
wwoodsthere's a tcp transport for dbus13:35
J5jwb: here13:35
jwbJ5, can dbus do multihost stuff?13:35
jwbeasily?13:35
jwbso that a 5 year old could code something up?13:35
J5multihost?13:35
jwbJ5, machine 1 sends an event on the bus and machines 2-5 get it13:36
wwoodsit's not very well documented IIRC, but you can do stuff like: <listen>tcp:host=localhost,port=12434</listen>13:36
wwoodsin dbus system.conf13:36
jwbwwoods, is there an equivalent broadcast?13:36
wwoodsyou'd think you could use multicast for that13:36
wwoodsbut now I'm speculating wildly13:37
J5jwb: ya, not sure what our tcp support is like13:37
nottingmaybe amqp is better for this13:37
* jwb shrugs13:37
J5we are primarily a local bus13:37
jwbthat's what i thought13:37
J5tubes has multicast support I think13:37
J5we do dbus over tubes on the OLPC13:38
wwoodsthat sounds like it might be the Right Thing To Do13:38
f13"tubes"13:39
wwoodsoh, so tubes is.. basically dbus over xmpp?13:39
J5wwoods: tubes abstracts the transport13:40
wwoodswell, details aside because.. yeah13:40
wwoodsheh13:40
J5xmpp is one of the transports13:40
wwoodsbut yeah. sounds like Tubes is the answer for "dbus over network"13:40
f13so...13:41
f13we're pretty far off in the weeds13:41
wwoodsright. that's like a post-f9/f10 kind of target13:41
jwbsure13:41
f13wwoods: if you get something simple up that can be poked via urllib or whatnot, let us know and we will update the compose job13:41
wwoodsfor testing f9 I'll set up some cutely stupid cgi that you can poke13:41
f13but under a similar topic of 'weeds', who all is going to be at FUDCon?13:41
f13and if there is a number of us, should we get together and voice some things out?13:42
nottingi suppose i can make the trip13:42
wwoodssince F9 is going to become RHEL6 when it gets growed up, the RHEL QA guys are going to be working on F9/rawhide testing13:42
f13notting: now kind of you13:42
wwoodsyeah I'll probably be at FUDCon, seeing as it's, y'know, here13:42
nottingf13: heh13:42
nottingf13: i suspect if i try and expense travel someone will laugh at me13:42
f13notting: sadly, you could probably get away with it13:43
nottingf13: are you coming?13:45
f13yes13:46
f13I'm assuming wwoods will be there13:48
* jeremy isn't going to be at fudcon13:48
f13and j5 will be13:48
wwoodsI'll be there, yeah.13:49
f13well maybe will figure out something to do then.13:49
f13On the signing server front, I think Mike McGrath is ready for testing new hosted environment, and we're going to be fodder.13:49
jwbcool13:50
f13so 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 from13:50
lmackenI did a bunch of hacking on the signing server over the weekend13:51
f13this may need a new koji call, to be able to import from 'relative' location, relative to the koji server.13:51
lmackenit's almost ready for testing13:51
f13cool13:51
f13Are there any other topics people would like to discuss?13:53
* wwoods sits on hands13:54
jwboh, i will not be at FUDCon13:55
f13darn13:55
jwbno surprise there13:55
f13jwb: what about the Boston one with RH Summit attached?13:55
jwbwhen is that?13:55
f13June 18-2013:56
f13although I may not actually be around then, let me check.13:56
jwbi'll try to get to that one13:58
f13anywho, 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 schedule13: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!