CGL and the Linux Foundation

[ikebe.takashi@xxxxxxxxxxxxx (Takashi Ikebe)]

Hello Mario, Dan and others.
> 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
>   
I completely agree that.
Especially, some requirements that relates to performance need to define 
reference hardware, CPU architecture, etc.
> - 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.
>   
I agree that.
Basically CGL is the Linux that applicable on carrier equipment. This 
means the CGL is different from general purpose Linux.
Network equipment typically requires high availability, real time 
capability (response time), serviceability than scalability and total 
throughput.
I think general purpose computing prefer latter.
Therefore I think the acceptance of community is hard because of carrier 
specific functionality. and that's why CGL exists.

> - Mario
>
>
> _______________________________________________
> Lf_carrier mailing list
> Lf_carrier@xxxxxxxxxxxxxxxxxxxxxxxxxx
> https://lists.linux-foundation.org/mailman/listinfo/lf_carrier
>   


-- 
Takashi Ikebe
NTT Network Service Systems Laboratories
9-11, Midori-Cho 3-Chome Musashino-Shi,
Tokyo 180-8585 Japan
Tel : +81 422 59 4246, Fax : +81 422 60 4012
e-mail : ikebe.takashi@xxxxxxxxxxxxx