cgl compliance

[joe.macdonald@xxxxxxxxxxxxx (Joe MacDonald)]

On Thu, 2008-08-07 at 15:23 -0400, Dave Sullivan wrote:

> Ok, maybe a concrete example would be best.  For the CGL requirement below.
> 
> AVL.5.3 	Process-Level Non-Intrusive Application Monitor 	P1 	OS 
> Community Package 	Daemontools 	V0.76-6rph 	Yes
> 
> 
> A package that is provided by the open source community (daemontools) 
> that can be compiled and run as designed on a distro OS qualifies for 
> compliance.  Is this true?
> 
> As far as how the software package can be bundled on top of the core 
> distro is a different issue
> 
> Thanks for responding.  Does this make sense?


Ah, yeah, okay, I got it now.  Yes it makes sense and yes you have it
right.

There's actually two different ... I don't want to say classes of
qualification, but that's sort of what it is.

For a requirement to reach P1 level (in the CGL 4.0 spec, earlier ones
were before I joined the group, so I don't know and post-4.0 is still
being discussed, so nothing is carved in stone yet) it has to have at
least one package / patch set in the open source community that is well
maintained.  Calling out daemontools in this case is a good example
because it hasn't seen much active development in the last few years,
but it does the job it needs to do, does it well enough to meet the
requirement and is open source, so it meets the criteria the CGL WG
decided to adopt for determining if something could be a P1.

For a distribution vendor, though, there's no requirement that they
choose the open source option that the CGL WG has used as the
proof-of-concept.  There's nothing stopping anyone from writing a
completely different application that implements AVL.5.3 and using that
to meet the requirement.  And there's no requirement that an individual
vendor have an open source solution for a particular requirement, it may
be that the vendor has something they believe is a better solution for
their customers that happens to be closed source.  That level of freedom
is still there if you want to take that route to meet the CGL
requirements.

Does that help?

-J.


> 
> -Dave
> 
> Joe MacDonald wrote:
> > Hi Dave,
> >
> > On Thu, 2008-08-07 at 14:19 -0400, Dave Sullivan wrote:
> >> Hi,
> >>
> >> I have a question in regards to CGL compliance.
> >>
> >> If there is an open source package that provides the functionality as 
> >> described by a CGL requirement.  And that open source package and can be 
> >> compiled and installed on the Registering Linux OS Applicant.  Does that 
> >> count as compliance?
> >>     
> >
> > I'm not quite getting your question, but I think it's just that I'm 
> > missing where you're coming from.
> >
> > Consider a requirement:
> >
> >
> >     RLB.1.0: Five Nines Reliability  P1
> >
> >     LF CGL specifies that carrier grade linux shall experience no more
> >     than five minutes, twenty five seconds of down-time each calendar
> >     year of use other than regularly scheduled maintenance periods.
> >
> >
> > And now Cavendish Farms Linux does not claim CGL compliance, because 
> > they have no way of ensuring they meet RLB.1.0.  Then along comes Bob 
> > Software, who creates an application specifically for CFL that ensures 
> > CFL will be able to meet RLB.1.0, which completes all of the P1 
> > requirements CFL needs.
> >
> > Are you asking "Can CFL now claim CGL compliance even though they 
> > don't ship it?"  Or are you asking "Can Bob Software claim CFL is now 
> > CGL?"  Or is there something else you were wondering about what Bob's 
> > application would mean to CFL and CGL?
> >
> >
> > *Joe MacDonald*, Member of Technical Staff, *Wind River*
> > direct 613.270.5750  mobile 613.291.7421  fax 613.592.2283  
> >
> 


Joe MacDonald, Member of Technical Staff, Wind River
direct 613.270.5750  mobile 613.291.7421  fax 613.592.2283   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/lf_carrier/attachments/20080807/6fb63ae4/attachment.htm