On Tue, 29 May 2007, Garrett D'Amore wrote:
> Darren J Moffat wrote:
>> James Carlson wrote:
>>> Darren J Moffat writes:
>>>> We can argue this indefinitely but regardless of what some PSARC members
>>>> think admins, developers on Solaris and other platforms act differently.
>>>
>>> Regardless of how they act, we don't apply any engineering towards
>>> making their actions supportable.
>>
>> and there in lies the problem, we are not meeting customer needs here.
>> Customers and partners really just don't care about that, we know they
>> build stuff on top of syslog. They expect to build stuff ontop of syslog
>> on all platforms not just Solaris. IMO we need to take the fingers out of
>> our ears and stop just saying "la la la la la la" everything this comes up
>> and ignoring what the customers use and we know they use.
>>
>> What I'm saying for *this* case is that a reduction in the information
>> presented is a problem and for me it means that this case doesn't meet its
>> goals.
>>
>
> But for existing customers, the existing information was not provided in
> anything remotely resembling a consistent manner. Each driver did its own
> thing. For a customer/application to have depended on this kind of
> information would have been utterly insane, if they wanted the application to
> work with different NICs, etc.
But that is not the case in a large datacenter environment that I'm
familiar with. The same one where all the ethernet ports are
hard-coded. The good Sys Admins understand the limitations of
hardcoding data in scripts. However, the environment tends to remain
static over long periods of time (for various reasons, including the
hassle of filling in endless electronic forms to make something simple
happen and the implied threat of loosing your job if it does not work
out as planned). A machine will be configured to run an application
(they like one application per machine!) and it will stay on that
machine for 3 to 5 years. Only after an app moves to a
different/upgraded machine will the hard-coded scripts be
re-evaluated. Oh ... and yes ... they are still running Solaris 8!
> I have investigated, and I can provide this information without too much
> pain, but I still disagree with it in principle.
>
> The reason for this is that today the mac layer knows nothing about many of
> these link details, and it really doesn't need to. Furthermore, there are
> reasonable situations where the link speed can change without generating any
> kind of notification. (The typical example being link speed adjustments that
> are done on 802.11 links.)
>
> If folks really really want this information for 802.3 links, we can do it.
> I just don't think its reasonable.
>
> I also think, most tools just want an "up" or "down" notification (not
> details on speed or duplex), so very few are likely to be negatively impacted
> (other than they will have to adjust their scripts/tools to recognize the new
> "up" and "down" messages, but then one format will cover _all_ GLDv3 NIC
> drivers.
>
> Note that some NIC drivers don't even bother to log this at all. For
> example, 802.11 drivers do no link state logging whatsoever. My case would
> add this for those drivers.
>
> -- Garrett
> _______________________________________________
> opensolaris-arc mailing list
> opensolaris-arc at opensolaris.org
>
Al Hopper Logical Approach Inc, Plano, TX. al at logical-approach.com
Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT
OpenSolaris Governing Board (OGB) Member - Apr 2005 to Mar 2007
http://www.opensolaris.org/os/community/ogb/ogb_2005-2007/
