ReleaseEngineering/Meetings/2007-dec-10

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!