pcp
[Top] [All Lists]

Re: [pcp] QA regressions with cgroup.groups

To: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Subject: Re: [pcp] QA regressions with cgroup.groups
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Thu, 7 Aug 2014 19:43:31 -0400 (EDT)
Cc: PCP <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <53E3E311.2090206@xxxxxxxxxxxxxxxx>
References: <53E2ADCD.6050704@xxxxxxxxxxxxxxxx> <136888626.25471824.1407368239559.JavaMail.zimbra@xxxxxxxxxx> <53E3E311.2090206@xxxxxxxxxxxxxxxx>
Reply-to: Nathan Scott <nathans@xxxxxxxxxx>
Thread-index: Way76WyTc+pCyzG/DdNXAfaDO69XgA==
Thread-topic: QA regressions with cgroup.groups

----- Original Message -----
> [...]
> I think this is a semantic corner case ... the PM_ERR_NAME error is
> probably the most appropriate (indeed if you did not set it in the PMDA,
> the libpcp_pmda routines would set it to that value when the PMNS at the
> dynamic node is NULL).

Yep, that's what is happening here.

> > I notice mmv always does this "pre-populate with a few fixed names"
> > for its dynamic namespace use, and the Linux kernel interrupt names
> > (also dynamic) will always have a starting set... hmmm.
> 
> This approach allows the dynamic node to always have something as a
> descendent in the PMNS and avoids the problem I've seen, but it is not
> required.

OK.  So, sounds like we'll need some QA output filtering?

> So, back to my original question, is there some easy way to force
> population of the cgroup.groups in the PMNS for QA purposes?

Sorry, I forgot this part - see qa/361 for several examples of how to
go about doing this.

cheers.

--
Nathan

<Prev in Thread] Current Thread [Next in Thread>