Thanks for the feedback.
On Thu, 2009-07-09 at 11:20 +1000, Nathan Scott wrote:
> Looks pretty good to me. One section that seems to be missing
> is "Changes for pmcd", at least for completeness & to give a more
> clear description of the PDU exchanges that'd be involved, maybe?
I could have done a better job of separating what the libpcp caller will
see and what happens behind the scenes in the PMNS_REMOTE case. In
particular extra code is needed in pmcd to use the existing PDU routines
to send the requests to daemon PMDAs and then the am I PMDA_INTERFACE_4
question has to be handled in libpcp_pmda for the PMDA. For DSO PMDAs
the type of the PMDA is known immediately and the additional methods are
called without any PDUs.
Provided the intent is clear and there is no major problem with the
approach I might spend time on implementing rather than tweaking the
design document.
The dameon case does raise a problem I'd not considered. If the PMDA is
linked with libpcp_pmda, then all is well. But there are the Perl PMDAS
(news, kvm, dbping, zimbra, netfilter, bonding, systemtap, vmware,
memcache, oracle, mysql) - Nathan, what needs to happen here as the perl
pmda support seems to be using libpcp_pmda and PMDA_INTERFACE_LATEST? -
nothing bad will happen in the short term as there are no dynamic pmns
nodes associated with the domains for these pmdas, but it is a corner
case where a bogus pmns entry could bring the pmda down unless the perl
pmda support traps and returns something sensible, or stays with
PMDA_INTERFACE_3.
> There's a misconception: "...update global PMNS and send pmcd a
> SIGHUP signal". I also thought that was how it works, but that's
> not what pmdammv actually does.
Indeed this seems to have acquired the status of an urban myth ... there
is no PMDA (not even the old oracle PMDA) that does this, so it must
have been "if you need to do this, this is the only way to make it
work".
I think if a dynamic PMNS works as I plan, then mmv could use this
rather than the NOTREADY-READY approach.
On Thu, 2009-07-09 at 11:03 +1000, Mark Goodwin wrote:
> Looks like a decent well thought out proposal. I'm just wondering
> whether you've captured all the scenarios that might break by the
> introduction of non-leaf nodes that have a pmID?
I think this will be OK. The PMNS node at the root of a dynamic subtree
does have a PMID for the PMNS_LOCAL cases. Fortunately there are only a
small number of operation types on the PMNS, so I'd be surprised if
there was another corner case ... but the implementation and QA shake
down will probably tell another story ... 8^)>
> Since we'll be introducing a pmns syntax change for the new
> dynamic non-leaf nodes, do we know of any scripts that interpret
> the ascii pmns syntax directly, or apps that will not be expecting
> '*' from pmIDStr()?
Good point, hadn't thought of that.
* pmnsadd hands all the parsing to pmnsmerge (a C program that
uses pmLoadASCIINameSpace()
* pmnsdel is a C program that uses pmLoadASCIINameSpace()
* pmdaproc.sh uses pmnsadd and pmnsdel
* genpmda creates a pmns subtree but does not parse the existing
pmns
* Rebuild parses only names (not PMIDs) and then uses pmnsmerge
* ReplacePmnsSubtree uses pmnsadd and pmnsdel
* pmdaproc.sh uses pmnsadd and pmnsdel
* clusterns.pl this one makes me nervous ... I am not sure what it
is doing, but this fragment ... ($rawcluster !~ /^[0-9]+$/) and
die "PMID cluster is not numeric in node '$_'\n"; .... may be a
problem if it is handling pmns nodes for other than the cluster
PMDA at this point ... Mark could you please check this one?
* hotproc/fixpmns.awk generates pmns nodes but does parse the
existing pmns
This did show up one other thing, the static routine output() in
src/pmns/pmnsutil.c needs to be able to _generate_ the *:* format PMID
for a node that is the root of a dynamic subtree ... and it is not
currently using pmIDStr() (sigh!).
> And having a 'pad' field in the middle of a structure seems kind
> of funky, but I can see the reasoning for wanting it there. Maybe
> just use up the two existing pad bits and call it 'flags'? (with
> room for three more flag values in the future, one of which could
> be to flag an extended range of domain values).
There seems to be support for moving to 9 bits of domain and dropping
the pad ... I happy to do that and include it in the QA validation for
the other pmns changes.
|