From Fedora Project Wiki
(13:41:10) abadger1999: c4chris, dgilmore: Do you want to meet here for packageDB talk or elsewhere? (13:41:24) dgilmore: abadger1999: here is great (13:42:01) mmcgrath: warren: can you send me an encrypted version of the file pick sent you? He didn't encrypt it with my key (13:42:06) abadger1999: Okay. I started looking at implementing something in TurboGears working from Elliot's schema. (13:42:30) abadger1999: TurboGears is a good framework. (13:42:30) warren: mmcgrath, console access didn't change since the old console.txt.asc (13:42:34) warren: mmcgrath, sending the rest (13:42:40) abadger1999: The schema seems a little complex. (13:42:50) abadger1999: Here's how I've modified it so far http://www.fedoraproject.org/wiki/Infrastructure/PackageDatabase/Schema (13:42:52) pick: mmcgrath, I must be sniffing glue (13:42:53) mmcgrath: oh, k. (13:42:55) pick: thought I did (13:43:00) mmcgrath: pick: its cool ;-) (13:43:23) warren: mmcgrath, gpgkeyid? (13:44:18) abadger1999: I'm not sure if we want to track each Package Version in the packageDB or not. (13:44:33) mmcgrath: C505F685 (13:45:00) warren: mmcgrath, could you please walk me through this? i really need to get more familiar with this (13:45:03) dgilmore: abadger1999: perhaps for now lets just use SQL create statements with comments (13:45:35) dgilmore: abadger1999: we need to track branches (13:45:39) abadger1999: We could, but this is already written... (13:45:55) abadger1999: dgilmore: Yep -- I think Elliot's Collections handles branches. (13:46:17) f13: abadger1999: yes, we want to track versions. (13:46:18) ***c4chris looks ar Schema now... (13:46:18) dgilmore: abadger1999: each branch could possibly have different or multiple maintainers (13:46:31) abadger1999: I changed how it was setup though. He just had name in collection, so it would have had to be Core4 Core5, etc. (13:46:35) dgilmore: the versions inside the branches we donet cae about (13:46:39) f13: abadger1999: we should be able to use the packageDB to handle 'collections' in which certain versions are tagged for certain collection. (13:47:27) dgilmore: abadger1999: it would be nice to track upgrade paths maybe (13:47:27) mmcgrath: warren: sure, do you just want to do it? (13:47:33) mmcgrath: Reboot the box, hit f12 (13:47:51) Locnar [n=workin] entered the room. (13:47:53) warren: mmcgrath, gnome-terminal wont interfere? (13:48:16) mmcgrath: once you ge tto a boot prompt (I think its boot:) just type cvs and hit enter (13:48:26) mmcgrath: warren: not sure, I'm a kde man :) (13:48:33) mmcgrath: there is an escape character for f12 too. (13:48:44) mmcgrath: it'll get printed to the screen at first reboot but it'll dissappear quick. (13:48:45) Locnar: You folks still swapping servers? (13:49:09) warren: CVS is still down, working on it (13:49:36) abadger1999: f13: But packages get updated. So my question is there value in knowing that foo-1.0-1 foo-1.0-2 foo-.1.1-1 were shipped for "Core 4" and foo-1.0-2 foo-1.1-1 foo-1.1-2 were shipped for "Core 5"? (13:49:42) abadger1999: Which there may be. (13:49:55) abadger1999: Just asking if you have a use case already. (13:49:57) pick: warren mgalgoci is going to check the kvm and find my problem (13:50:08) warren: pick, mgalgoci, thanks (13:51:25) c4chris: abadger1999, I think we should have some sort of package group thing (13:51:33) abadger1999: dgilmore: True -- upgrade path or lack thereof. So then, the nagmail scripts can query the db directly... c4chris c4chris|w (13:51:51) dgilmore: abadger1999: yeah might make them quicker (13:51:57) abadger1999: c4chris: Like comps groupings or..? (13:51:59) c4chris: and some sort of groups in people too (13:52:11) warren: mmcgrath, hm, where is the login info for PDU? (13:52:16) c4chris: abadger1999, more like perl, python, etc (13:52:23) c4chris: games (13:52:36) abadger1999: Yah. People starts to intersect with the new accounts system... (13:52:41) dgilmore: c4chris: kde :D c4chris c4chris|w (13:52:55) c4chris: then if we also have sig groups in people, we can pretty easily matching groups to make edits/builds (13:53:00) abadger1999: c4chris: So like SIGs (13:53:07) dgilmore: abadger1999: we need ways to assign sigs blobs of packages (13:53:09) c4chris: abadger1999, yes (13:54:25) c4chris: abadger1999, I don't see an owner either ? (13:54:37) abadger1999: There could be multiple groups per package then. Wonder if we should key off the Package or PackageVersion. c4chris c4chris|w (13:54:46) dgilmore: abadger1999: co-maintainers should be able to do a few things depending on how they want to work (13:54:52) ja8sun left the room (quit: "Leaving"). (13:55:11) dgilmore: for instance you and I could work on al branches of a package together (13:55:18) abadger1999: c4chris: In Elliot's model, you use PackageInterest to associate people to package. (13:55:25) c4chris: probably more like a package/OS-release thing (13:55:27) abadger1999: But that's something I'm not sure I like. (13:55:31) dgilmore: or you work on FC5 and devel and I work on FC-3 FC-4 (13:55:45) c4chris: abadger1999, oh, right. Not so intuitive... (13:55:57) c4chris: dgilmore, yes (13:56:42) dgilmore: c4chris: probably more likely i do FC and you do RHEL (13:57:20) abadger1999: Right PeopleInterest associates People -> packageListing (which is associating package to collection) (13:57:22) c4chris: dgilmore, yes. Might even be tied to arch: you do sparc, and I do alpha ;-) (13:57:28) dgilmore: but we need to be flexible in how we assign people/group - package/branch matchups (13:57:55) dgilmore: c4chris: yep that is if we get sparc in and i get to maintain them all still :D (13:58:06) c4chris: there probably needs to be a group of people with global write/build privs (13:58:32) dgilmore: c4chris: the security SIG and admins should have full access (13:58:42) c4chris: dgilmore, exactly (13:58:54) dgilmore: we should also have a flag to disable acls on a branch totally when it goes EOL (13:59:12) abadger1999: Yep. SIGs should be entered into the accountsDB somehow. (13:59:23) dgilmore: so that we lock up a branch totally (13:59:30) abadger1999: A question would be how do we want to pull that information into the PackageDB. (14:00:08) dgilmore: abadger1999: SIGS are the groups we have been talking about (14:00:18) abadger1999: Yes. (14:00:29) abadger1999: But to me group information belongs in the accountsDB (14:01:14) abadger1999: When I sign up and remove myself from the groups that data should be entered into the accountsDB. (14:01:19) dgilmore: say we have a group table gid INT, GroupName Varchar (14:01:52) dgilmore: group matching table gid INT, BranchID INT, PackageID INT (14:03:08) abadger1999: Sending notifications or asking for authorization in the packageDB needs to query the accountsdb for the info or send it through the accountsDB for further processing. (14:04:14) dgilmore: abadger1999: i wuld think the link to accounts db is only a userid (14:05:08) abadger1999: dgilmore: User-Groups are pretty plainly an accounting function though... (14:05:23) abadger1999: Err... Unless your talking about package-groups... (14:05:40) dgilmore: abadger1999: user auth is all in accounts (14:06:02) dgilmore: package-groups is what i mean when im saying groups (14:06:37) abadger1999: dgilmore: Ah. There's our confusion. We'll have to deal with both, in the packageDB, though... (14:06:45) dgilmore: abadger1999: i see the package db as controlling the ACLs on the VCS (14:06:55) c4chris: so we nedd a group db (14:07:00) dgilmore: the VCS will do user auth (14:07:46) c4chris: dgilmore, that'll get tricky then (14:08:03) dgilmore: c4chris: how so? (14:08:23) c4chris: package db will say package A is in group G (14:08:24) dgilmore: abadger1999: we assign users to packages or package groups (14:08:48) c4chris: and group table will say user U is part of group G (14:09:17) c4chris: so VCS needs to query group table, no? (14:09:42) abadger1999: I think the package DB should be querying the group table. (14:09:45) dgilmore: a package can have multiple "owners" the main maintainer admins, Security SIG, other sig (14:09:53) abadger1999: And then setting ACLs in the VCS appropriately. (14:10:28) c4chris: Oh, I see, and the the PackageDB is used to set ACLs ? (14:10:39) dgilmore: c4chris: yep (14:10:43) abadger1999: Unless someone thinks that's a bad idea :-) (14:11:08) dgilmore: the maintainer might not be part of a sig and therefore have no access to other packages in that "group" (14:11:10) c4chris: Dunno (14:11:27) c4chris: Each time the Package DB is updated, all ACLs need to be checked... (14:11:35) c4chris: Is that OK? (14:12:11) abadger1999: Hmmm... not all ACLs each time. (14:12:32) abadger1999: Unless I'm missing something. (14:12:40) dgilmore: c4chris: the app that maintains the package db shuold only set ones needed (14:12:49) c4chris: abadger1999, yes, depends what's changed (14:13:24) c4chris: ok, that should work (14:14:30) c4chris: Once we start with a schema, how hard is it to add things (14:14:52) c4chris: like rpmlint exceptions, excluded arches, ... (14:14:58) dgilmore: c4chris: hopefully fairly easily who nows how much we will want to extend it (14:15:53) c4chris: I have zero experience with TorboGears (14:16:05) dgilmore: c4chris: me either (14:16:15) c4chris: does this create a DB from the schema ? (14:16:27) c4chris: and provides tools ? (14:16:49) dgilmore: c4chris: not sure what do you use? (14:16:52) abadger1999: Yes. This component of TurboGears is from SQLObject. (sqlobject.org) (14:17:20) ***c4chris uses flatfiles mostly... (14:17:36) c4chris: (and perl) (14:17:55) abadger1999: You can write an SQL schema or write it in python. TurboGears has an init type script which will create the db from the python objects. (14:18:35) c4chris: and then provides nice management via a web interface ? (14:19:15) abadger1999: I've seen the screencasts for 0.9 (which lmacken is packaging up) and it has some nice web interfaces. (14:19:44) c4chris: abadger1999, k I guess I've got some reading to do... (14:19:51) abadger1999: 0.8 which we have in Extras and I'm using now is great for programmers but doesn't have all the bells and whistles extra admin apps. c4chris c4chris|w (14:19:55) dgilmore: abadger1999: and it can execute system commands? c4chris c4chris|w (14:20:47) abadger1999: c4chris: There's two nice screencasts on turbogears.org. (14:21:12) c4chris: abadger1999, do you have somewhere to setup a mock PackageDB we could check and play with a bit ? (14:21:15) abadger1999: One is "The 20 Minute Wiki" which is pretty awesome. (14:21:57) abadger1999: dgilmore: It's just python. So yes, system commands are possible c4chris c4chris|w (14:22:20) dgilmore: abadger1999: cool cause we will need to set facl's etc (14:23:00) c4chris: abadger1999, k, will download and have a look later (14:23:01) abadger1999: c4chris: I don't :-( I can convert it into SQL creates if you want but otherwise I don't have a server on the internet to host stuff. (14:23:13) abadger1999: Maybe we can put it into one of the xen guests? (14:23:36) c4chris: abadger1999, ask warren. (14:23:53) c4chris: abadger1999, otherwise, I can prolly setup something (14:24:10) warren: sure we can, after we have it online... (14:24:38) abadger1999: warren: :-D Cool. c4chris c4chris|w (14:25:56) abadger1999: c4chris, dgilmore: Are either of you python people? (14:26:10) dgilmore: abadger1999: nope i do perl and php (14:26:15) warren: scaly and without limbs? (14:26:25) c4chris: abadger1999, unfortunately not... but I plan to learn (14:26:45) dgilmore: abadger1999: i have done a little python but i wouldnt say im proficient (14:26:53) abadger1999: Hmmm.... This'll make development interesting :-) (14:27:02) c4chris: :-) (14:27:26) abadger1999: dgilmore: Ah okay. A little python goes a long way. (14:28:02) c4chris: I'll have to read the python for perl programmers thing (14:28:14) c4chris: (or python for C programmers) (14:28:39) abadger1999: Dive into Python is good too. (14:28:50) c4chris: abadger1999, k (14:29:59) abadger1999: Well, we should probably concentrate on the db for now, then. (14:30:09) c4chris: abadger1999, will you look into getting some kind of SIG idea into teh schema (14:31:32) abadger1999: Definitely. Do we agree that we have SIG groups that users are members of and SIG-groups that packages are members of and we want to match those up in the pkgDB somehow? (14:31:47) c4chris: abadger1999, yes (14:32:42) c4chris: (somehow, that reminds me: I wanted to file bugs about the %ghost .pyo thing) (14:33:09) c4chris: (so I can start hacking some python code... :-) ) (14:33:17) dgilmore: abadger1999: yum (14:33:19) dgilmore: yup (14:33:20) abadger1999: Would it be helpful if I convert the schema to SQL create statements or is the python/SQL readable enough? (14:33:45) c4chris: abadger1999, for me it's fine as it is now on the wiki page (14:33:52) mspevack left the room (quit: "Leaving"). (14:34:36) dgilmore: abadger1999: how it is is ok (14:35:21) c4chris: warren, any ETA for the xen hosting a sandbox ? (14:35:52) abadger1999: Okay. I'll work on merging the ideas we had here and posting them over the weekend. (14:36:11) c4chris: abadger1999, great! thx. (14:36:16) warren: c4chris, box is running now, just not installed. We're still trying to figure out the console, KVM and other access details. And fixing the CVS server is the top priority. (14:36:33) c4chris: warren, sure (14:36:48) c4chris: warren, how does "sometime next week" sound ?