Menu
▾
▴
acd-devel
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(11) |
|---|
|
From: Matt D. <di...@ec...> - 2004-12-16 15:03:31
|
Scott Michael Koch wrote: > On Thu, Dec 16, 2004 at 12:01:01AM -0500, Matt Disney wrote: >>So I think those tables should basically just look like we currently >>have them: >> >>network_interfaces >> interface_device >> hardware_addres >> netmask >> ip >> instance_id >> >>I understand that leaves us simply with a different but still somewhat >>undesirable database design, but I don't see another way. Anyone have >>other ideas or oppose this one? >> >>MD >> >> > > > One idea that comes to mind is to store the unique info such as IP's, serials, > etc. in flat files or using some other method. The way I see it is > combining the disk serials, IP, etc.. with the type of info that is currently > in the acd_manual_info files into a single file stored on the server for each > host. > > I think this would solve/clean-up our database issue, but is there a way to > do this without losing functionality? The only problem I forsee is keeping > historical information on the data in these files efficiently. There is > something else to thing about. > > -Scott Yeah, it does seem like history would be hard. Another concern is querying the data that's stored in files. For example, maybe you want to find all the hosts that are on a certain subnet. Or maybe you want to find all WD Raptor hard drives because you suspect a pattern of failures. In general, I have to say I'm not terribly fond of combining file and database usage like this. But if it solves a big problem for us, we certainly can't dismiss it outright. MD |
|
From: Scott M. K. <ko...@cs...> - 2004-12-16 06:13:57
|
On Thu, Dec 16, 2004 at 12:01:01AM -0500, Matt Disney wrote: > > > >I guess we still face the fundamental deficiency previously mentioned > >with the schema originally proposed by Josh and Scott: how to deal with > >things like disks that have serial numbers? > > > >MD > > Josh and I briefly discussed the possibility of not supporting disk > serial numbers. But aren't network interfaces the same kind of thing? > Assuming they are, I think we're stuck having to support that kind of > non-repetitive data. Well, you could make the case that we should also > ignore the IP and subnet of the net interfaces, but I would disagree > since knowing what networks a box is on is a big win for ACD. > > So I think those tables should basically just look like we currently > have them: > > network_interfaces > interface_device > hardware_addres > netmask > ip > instance_id > > I understand that leaves us simply with a different but still somewhat > undesirable database design, but I don't see another way. Anyone have > other ideas or oppose this one? > > MD > > One idea that comes to mind is to store the unique info such as IP's, serials, etc. in flat files or using some other method. The way I see it is combining the disk serials, IP, etc.. with the type of info that is currently in the acd_manual_info files into a single file stored on the server for each host. I think this would solve/clean-up our database issue, but is there a way to do this without losing functionality? The only problem I forsee is keeping historical information on the data in these files efficiently. There is something else to thing about. -Scott |
|
From: Matt D. <di...@ec...> - 2004-12-16 05:01:05
|
Matt Disney wrote: > > I guess we still face the fundamental deficiency previously mentioned > with the schema originally proposed by Josh and Scott: how to deal with > things like disks that have serial numbers? > > MD Josh and I briefly discussed the possibility of not supporting disk serial numbers. But aren't network interfaces the same kind of thing? Assuming they are, I think we're stuck having to support that kind of non-repetitive data. Well, you could make the case that we should also ignore the IP and subnet of the net interfaces, but I would disagree since knowing what networks a box is on is a big win for ACD. So I think those tables should basically just look like we currently have them: network_interfaces interface_device hardware_addres netmask ip instance_id I understand that leaves us simply with a different but still somewhat undesirable database design, but I don't see another way. Anyone have other ideas or oppose this one? MD |
|
From: Scott M. K. <ko...@cs...> - 2004-12-15 01:32:29
|
I have posted the notes I took during the meeting today, mostly what was written on the board, at www.cs.utk.edu/~koch/12142004-meeting -Scott |
|
From: Matt D. <di...@ec...> - 2004-12-15 00:13:37
|
Josh wrote: > instance_ids > hostname > instance_id >---\ > cpu | > speed | > architecture | > model | > cpu_id >------- | > cpus | | > instance_id <-|-- > cpu_id <------ | > custom | > type | > attribute | > custom_id ----| | > customs | | > instance_id <-|-/ > custom_id <---| > I guess we still face the fundamental deficiency previously mentioned with the schema originally proposed by Josh and Scott: how to deal with things like disks that have serial numbers? MD |
|
From: Josh <jos...@el...> - 2004-12-14 23:56:28
|
So, Matt proposed this on the way home. What do you all think of having
a set of "standard" data that is organized in well-normalized tables.
So, for example (best viewed in a monospace font);
instance_ids
hostname
instance_id >---\
cpu |
speed |
architecture |
model |
cpu_id >------- |
cpus | |
instance_id <-|--
cpu_id <------ |
custom |
type |
attribute |
custom_id ----| |
customs | |
instance_id <-|-/
custom_id <---|
Hope that makes sense. So we define a core set of data that ACD
will gather. Then any additional data will appear as custom types and
attributes. I really like this idea - we get the best of both worlds.
Most data is normalized and well-designed. If something additional is
added, no biggie. Perhaps the XML input would look like this:
<machine>
<hostname>mookie</hostname>
<cpu>
<speed>30GHz</speed>
<architecture>iJLO</arch>
<model>Wicked</model>
</cpu>
<custom>
<name>location</name>
<value>outta sight</value>
</custom>
<custom>
<name>form_factor</name>
<value>mini_itx</name>
</custom>
</machine>
quick and dirty. some of it probablyt needs to be though through a
bit more. for example, this still doesn't really take into account
"static" fields or tables...
-jkl
|
|
From: Josh <jos...@el...> - 2004-12-13 21:21:51
|
On Mon, Dec 13, 2004 at 04:07:38PM -0500, Matt Disney wrote: > > Are we still on for 2:30 Tuesday? If so, I can find us a room somewhere > if you want. hukt on fonix werked for me. |
|
From: Matt D. <di...@ec...> - 2004-12-13 21:07:45
|
Are we still on for 2:30 Tuesday? If so, I can find us a room somewhere if you want. MD |
|
From: Matt D. <di...@ec...> - 2004-12-07 22:13:29
|
Matt Disney wrote: > ko...@cs... wrote: > >> >> Thursday is no good for me. I vote for after finals are over, but I >> am not sure what everyone elses schedule is. >> -Scott > > > How about next Tuesday at 10:00 AM? I'll be out of the office this > Friday and I believe you CS folks may already have enough meeting > quantity on Mondays? > > MD Abort, abort! I was just alerted to an 11:30 meeting that day and I'd rather not push it. How about 2:30 Tuesday? MD |
|
From: Matt D. <di...@ec...> - 2004-12-07 21:24:04
|
ko...@cs... wrote: > > Thursday is no good for me. I vote for after finals are over, but I > am not sure what everyone elses schedule is. > > -Scott How about next Tuesday at 10:00 AM? I'll be out of the office this Friday and I believe you CS folks may already have enough meeting quantity on Mondays? MD |
|
From: <ko...@cs...> - 2004-12-01 20:45:31
|
On (11/30/04 16:28), Matt Disney wrote: > Shall we meet to discuss ACD? I suggest this Thursday morning at > 9:30, or anytime next week (someone else can pick). > > We should leave this meeting with task assignments and timelines. > What do you think? > > MD > Thursday is no good for me. I vote for after finals are over, but I am not sure what everyone elses schedule is. -Scott |
|
From: Matt D. <di...@ec...> - 2004-11-30 21:28:21
|
Shall we meet to discuss ACD? I suggest this Thursday morning at 9:30, or anytime next week (someone else can pick). We should leave this meeting with task assignments and timelines. What do you think? MD |
