Infrastructure/PackageDatabase/Meeting20060831

From FedoraProject

< Infrastructure | PackageDatabase(Difference between revisions)
Jump to: navigation, search
m (1 revision(s))
m (Categorize)
 
Line 184: Line 184:
 
(14:36:48) c4chris: warren, how does "sometime next week" sound ?
 
(14:36:48) c4chris: warren, how does "sometime next week" sound ?
 
</pre>
 
</pre>
 +
 +
[[Category:Infrastructure]]

Latest revision as of 22:04, 8 January 2010

(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 ?