CGL and the Linux Foundation

[CMS063@xxxxxxxxxxxx (Smarduch Mario-CMS063)]

Q. Isn't the LSB just a "bottom-feeding" standard that describes what
everyone has already agreed on?  Isn't it totally unsuited for CGL,
which is defining new requirements?

No, just because the LSB isn't required for all CGL work, doesn't mean
that it can't be useful.  The LSB supports the concept of optional
modules, where new functionality can be specified that is not yet "best
practice" -- i.e., is not yet shipping in the major distros.  This is
described in the LSB Charter <http://www.linux-
foundation.org/en/LSB_Charter>.

-----Original Message-----

Hi Dan,

LSB conformance is primarily concerned with Application
run-time interoperability between LSB compliant distros
(i.e generic and arch) which lends itself to run-time 
certifiable tests. CGL is that + behavior conformance
(high resolution timers, precise process accounting,
hardware error detection) features may behave differently based on
the distro and hw combo. That's why to some extent we
kept mainline reqs to keep track of that fact - a CGL 
distro run-time behavior differs from generic Linux distros 
and for that matter other OSs.

In addition CGL maintains requirements which provide
guidance to the industry but are really not certifiable.
This has worked well in the past, it has moved vendors to
deliver reference projects, for example TIPC, kdb, 
middleware, clustering - you can only generalize about the attributes 
of the solution. These requirements are valuable. 

IMO what would really help both LF and CGL are gap analysis 
of CGL reqs and what can be converted into run-time verifiable 
tests to see what fits into the LSB optional modules in future
and  what doesn't. From the quick scan I did it appears
that Performance, Availability, Security are best fit either
through existing tests or developing new ones. Development
of such optional modules would be extremely beneficial to CGL since
now I can run a combination of OS/HW and characterize
behavior before development of deployment. I've been debugging 
field issues for 18 years and IMO this is the most important
issue in CG environments, that where I see most issues and
wrong assumptions made by developers. That's why even for 
baseline features I still want to make sure it behaves the 
same as it did before, if these features are critical to CG env.
Which doesn't always hold as new code rolls into mainline. 
We have done this for few  patches - it is proving extremely 
useful. But of course that model may not work for everything, 
and registration-conformance (instead of run-time conformance) may 
still be needed. All reqs seem to fall under one of these buckets.
(i) run-time certifiable 
(ii) maybe run-time certifiable but too much effort/cost both 
      in developing tests, env and hw but a checklist may apply 
(iii) beyond run-time certifiable - can only certify through 
      inspection. 

Above are based one or several  characteristics of CGL reqs.

- Some requirements are programmatically verifiable, similar to
  LSB.

- Some requirements provide a broad overview of a feature, 
  specific  checklist is needed to narrow in on what functionality 
  needs to be certified. The certification may preceed through
  inspection or ran manually. This is similar to what DoD does 
  for STIG compliance - (http://iase.disa.mil/stigs/index.html)

- Some requirements will require manual involvement and 
  interpretation to validate, i.e., pulling hardware, checking 
  the state of the system 

- Some requirements (ATCA, cPCI, IPMI, CMP, ...) would 
  require reference hardware to validate compliance

- Some requirements will require external hardware (iSCSI, remote 
  boot) to verify compliance

- Some requirements will require vendor support to validate - 
  for example test environmental sensors like fan speed or 
  temperature sensors or memory error inducing hardware. In
  somce cases the tools may be as simple as a hair dryer or
  pencil :)

- There will still remain reqs that can only be verified
  through inspection of the documentation supplied - for example
  allot of these fall in the Cluster area.

- Some requirements may need unique changes to firmware or other
  platform layers. 

Lastly dropping features that are not accepted into mainline is not
an option, huge chunk of the value a CG distro offers comes from 
such features. There are some product groups that run stock
kernels and don't use distros, its hard to do in CG environments
the feature set required is too complex.

- Mario