You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ian Holsman <Ia...@cnet.com> on 2001/06/11 23:06:39 UTC
[PATCH] mgmt_get_vars hook (was RE: Hooks for management reportin
g)
Ok..
Part 1.. adding the hook
once this gets approved/commited
I'll work on implementing the hook in scoreboard and the mpm's
> -----Original Message-----
> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: Monday, June 11, 2001 2:36 AM
> To: new-httpd@apache.org
> Subject: Re: Hooks for management reporting
>
>
> On Sun, Jun 10, 2001 at 09:36:34PM -0700, Ian Holsman wrote:
> > how about this prototype?
> >
> > it registers a 'test' hook which generates somes values,
> > I envison that this would be similliar to how the this would work
> > for the 'get/walk' type commands
>
> Looks good to me. It's got the flexibility of typing info
> that allows us to
> do structured data. The dotted naming is also a nice way to
> ask for specific
> bits, groups, or everything.
>
> +1 on concept.
>
> I believe a patch would only define the hook (and
> corresponding header doc).
> Note that I think the mgmt_line_t would be part of the
> system, so it would
> be in the patch, too. The C code would probably go into
> server/core.c since
> this is independent of MPMs (yes, they can use it, but all
> kinds of stuff in
> the server can use it).
>
> A second patch round can consider how this might be integrated into
> mod_status, and a third round for switching the scoreboard
> <-> mod_status
> communication channel.
>
> >...
> > > From: Harrie Hazewinkel [mailto:harrie@lisanza.net]
> > > Sent: Sunday, June 10, 2001 11:35 AM
> > > To: new-httpd@apache.org
> > > Subject: Re: Hooks for management reporting (was RE:New Hook)
> >...
> > > > #2 I usually need to see more generic stuff, and will
> probably shove the
> > > > values in a database/rrd so I can make pretty reports
> > >
> > > IMHO, making pretty reports is part of the management
> application and
> > > should not be done on an operational system. The only
> thing you need
> > > is enough information to create the report.
>
> Just had to respond to this one point...
>
> The reporting *can* be done on an operational system. That
> isn't for us to
> decide for users. This hook allows for the info to be
> offloaded from the
> box, or to generate the info right within the server process.
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>
Re: [PATCH] mgmt_get_vars hook (was RE: Hooks for management reporting)
Posted by "William A. Rowe, Jr." <ad...@rowe-clan.net>.
From: "Ian Holsman" <Ia...@cnet.com>
Sent: Monday, June 11, 2001 4:06 PM
> Ok..
> Part 1.. adding the hook
>
> once this gets approved/commited
> I'll work on implementing the hook in scoreboard and the mpm's
Let me understand 100%, we are _not_ using a hook to populate, only to retrieve
data, and that will not be heavily string intensive, so we won't laden the server
with unnecessary cpu. Yes?
Bill
Re: [PATCH] mgmt_get_vars hook
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Jun 12, 2001 at 06:47:14AM -0700, rbb@covalent.net wrote:
>
> [... type issue answered by Ian (and the posted patch :-) ...]
>
> > > 3) Why is this a RUN_FIRST instead of a RUN_ALL?
> >
> > If the mgmt function runs the hooks and askes for "apache.dav.*", then
> > mod_dav can satisfy the hook and terminate the scan.
>
> How is this going to help mod_status? If it asks for "*", then it will
> not get everything,
You return DECLINED if you didn't completely satisfy the request for info.
{
int just_me;
just_me = strncmp(which, "apache.dav.", 11) == 0;
if (!just_me && strcmp(which, "*") != 0)
return DECLINED;
/* add items to the hash */
return just_me ? OK : DECLINED;
}
But a RUN_ALL is also fine. I don't believe this hook needs to execute
super-speedily.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: [PATCH] mgmt_get_vars hook
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Jun 12, 2001 at 10:59:42AM -0700, Harrie Hazewinkel wrote:
> I am trying to understand as well the new module code
> mod_mgmt.c and mod_mgmt.h as well the patch.
Those two files haven't been submitted for addition. I think it is a
separate question.
However...
>...
> 1) Is the approach you have based upon handling a request??
> At the moment a request is handled you execute this hook??
mod_mgmt runs the hook in response to an HTTP request. Yes.
> 2) Can I only get management data via the new hook??
> I.E. do I always have to run thru this hook and get everything??
>
> If these 2 questions are answered YES. It will create a problem
> for management applications which are not HTTP-request based
> and this solution will not work with SNMP.
Anybody can run the hook at any time. It doesn't have to be in response to
an HTTP request. mod_mgmt is a particular user of the hook. mod_snmp could
also run the hook.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: [PATCH] mgmt_get_vars hook
Posted by Harrie Hazewinkel <ha...@covalent.net>.
HI all,
I am trying to understand as well the new module code
mod_mgmt.c and mod_mgmt.h as well the patch.
I have two questions:
1) Is the approach you have based upon handling a request??
At the moment a request is handled you execute this hook??
2) Can I only get management data via the new hook??
I.E. do I always have to run thru this hook and get everything??
If these 2 questions are answered YES. It will create a problem
for management applications which are not HTTP-request based
and this solution will not work with SNMP.
Harrie
--
address: Covalent Technologies, 645 Howard St, San Francisco, CA - 94105
phone: +1-415-536-5221 fax:+1-415-536-5210
personal website: http://www.lisanza.net/
Re: [PATCH] mgmt_get_vars hook
Posted by rb...@covalent.net.
> > 2) Why are we using a hash instead of a table? If this is all string
> > based, I believe a table will be much easier to deal with, plus we can
> > iterate through a table.
>
> It was initially a table. I asked for it to be a hash. The hash is faster
> and (yes) we can iterate through it. The mgmt/status data will not be purely
> string-based; the hash allows us to put integers, substructures, etc, into
> the hash table. A plain table cannot do that.
>
> (consider some module implementing counters of some kind; nicer to just pass
> integers rather than having to convert them to strings all the time; and
> substructures just couldn't be done)
How are you going to know what type it is? If mod_dav puts an integer
into the table, how is mod_status going to know to treat it as an integer
instead of as a string? Please don't say it just has to know, because
that means that this model isn't flexible at all, and I seriously dislike
that.
> > 3) Why is this a RUN_FIRST instead of a RUN_ALL?
>
> If the mgmt function runs the hooks and askes for "apache.dav.*", then
> mod_dav can satisfy the hook and terminate the scan.
How is this going to help mod_status? If it asks for "*", then it will
not get everything, and AFAICT, it won't be able to get everything, unless
we put a special hack into all of the hooks to have them return DECLINED
sometimes, even though they returned data. IMHO, this should be a
RUN_ALL, because otherwise you aren't going to get all the information you
want.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: [PATCH] mgmt_get_vars hook
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Jun 11, 2001 at 03:46:29PM -0700, rbb@covalent.net wrote:
>
> A few things:
>
> 1) Can you post patches in-line please, it makes them much easier to
> reply to.
Agreed. Or at *least* mark them as text/plain rather than application/*
> 2) Why are we using a hash instead of a table? If this is all string
> based, I believe a table will be much easier to deal with, plus we can
> iterate through a table.
It was initially a table. I asked for it to be a hash. The hash is faster
and (yes) we can iterate through it. The mgmt/status data will not be purely
string-based; the hash allows us to put integers, substructures, etc, into
the hash table. A plain table cannot do that.
(consider some module implementing counters of some kind; nicer to just pass
integers rather than having to convert them to strings all the time; and
substructures just couldn't be done)
> 3) Why is this a RUN_FIRST instead of a RUN_ALL?
If the mgmt function runs the hooks and askes for "apache.dav.*", then
mod_dav can satisfy the hook and terminate the scan.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: [PATCH] mgmt_get_vars hook (was RE: Hooks for management reportin
g)
Posted by rb...@covalent.net.
A few things:
1) Can you post patches in-line please, it makes them much easier to
reply to.
2) Why are we using a hash instead of a table? If this is all string
based, I believe a table will be much easier to deal with, plus we can
iterate through a table.
3) Why is this a RUN_FIRST instead of a RUN_ALL?
Ryan
On Mon, 11 Jun 2001, Ian Holsman wrote:
> Ok..
> Part 1.. adding the hook
>
> once this gets approved/commited
> I'll work on implementing the hook in scoreboard and the mpm's
>
> > -----Original Message-----
> > From: Greg Stein [mailto:gstein@lyra.org]
> > Sent: Monday, June 11, 2001 2:36 AM
> > To: new-httpd@apache.org
> > Subject: Re: Hooks for management reporting
> >
> >
> > On Sun, Jun 10, 2001 at 09:36:34PM -0700, Ian Holsman wrote:
> > > how about this prototype?
> > >
> > > it registers a 'test' hook which generates somes values,
> > > I envison that this would be similliar to how the this would work
> > > for the 'get/walk' type commands
> >
> > Looks good to me. It's got the flexibility of typing info
> > that allows us to
> > do structured data. The dotted naming is also a nice way to
> > ask for specific
> > bits, groups, or everything.
> >
> > +1 on concept.
> >
> > I believe a patch would only define the hook (and
> > corresponding header doc).
> > Note that I think the mgmt_line_t would be part of the
> > system, so it would
> > be in the patch, too. The C code would probably go into
> > server/core.c since
> > this is independent of MPMs (yes, they can use it, but all
> > kinds of stuff in
> > the server can use it).
> >
> > A second patch round can consider how this might be integrated into
> > mod_status, and a third round for switching the scoreboard
> > <-> mod_status
> > communication channel.
> >
> > >...
> > > > From: Harrie Hazewinkel [mailto:harrie@lisanza.net]
> > > > Sent: Sunday, June 10, 2001 11:35 AM
> > > > To: new-httpd@apache.org
> > > > Subject: Re: Hooks for management reporting (was RE:New Hook)
> > >...
> > > > > #2 I usually need to see more generic stuff, and will
> > probably shove the
> > > > > values in a database/rrd so I can make pretty reports
> > > >
> > > > IMHO, making pretty reports is part of the management
> > application and
> > > > should not be done on an operational system. The only
> > thing you need
> > > > is enough information to create the report.
> >
> > Just had to respond to this one point...
> >
> > The reporting *can* be done on an operational system. That
> > isn't for us to
> > decide for users. This hook allows for the info to be
> > offloaded from the
> > box, or to generate the info right within the server process.
> >
> > Cheers,
> > -g
> >
> > --
> > Greg Stein, http://www.lyra.org/
> >
>
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------