James Carlson wrote:
> Kais Belgaied writes:
>
>> 4.3 EOF of the VLAN PPA Hack
>> Although the committee members and reviewers agreed on the benefit of
>> obsoleting the VLAN PPA hack, they debated the proper timing of the
>> removal of the hack from OpenSolaris.
>> A member noted the possible disruption to users of this visible
>> feature, even though the release binding is minor. He suggested
>> considering a phased approach, with an announcement of the EOF as part
>> of this project, followed by another fast-track to finish the actual
>> removal of the feature. The project team, while open to the idea of a
>> two-step approach, argued that the co-existence of the old hack with
>> the new architecture was problematic. The project re-designed the
>> VLANs to be created as VNICS, which are MAC level datalinks, so that
>> obeservability features and resource controls can be applied to them.
>> Keeping the old hack will perpetuate the ambiguous behavior when
>> plumbing a non existing interface, result in a duplication of code in
>> the MAC and DLS layers. The answer was satisfactory to the committee.
>>
>
> I wasn't available for the review, and this is obviously a late time
> to bring this up, but the answers above sound insufficient to me.
>
> Removal of support for the VLAN PPA hack in the kernel itself sounds
> feasible, but I don't agree that this should be taken as license to be
> deliberately incompatible on upgrade. Doing so will break machines
> like jurassic.sfbay and many of our internal boot servers unless the
> administrators of those systems take deliberate -- and, per the
> opinion, apparently undocumented -- action prior to upgrade.
>
> Alternative plans that would allow removal of the kernel components
> and still preserve compatibility include at least these two
> approaches:
>
> a) Running a one-time conversion that checks for /etc/hostname.* and
> /etc/hostname6.* names that specify a VLAN, and automatically
> running the necessary dladm command to create the VLAN first.
> The scripting work in the net-physical script to accomplish this
> is trivial, and looks something like:
>
> while [ $# -gt 0 ]; do
> case $1 in
> *[0-9][0-9][0-9][0-9])
> base=`expr $1 : '\(.*[^0-9]\)'`
> ppa=`expr $1 : '.*\([0-9][0-9][0-9]\)$' + 0`
> vid=`expr $1 : '.*[^0-9]\([0-9]*\)[0-9][0-9][0-9]$'`
> dladm show-link $1 >/dev/null 2>&1 || \
> dladm create-vlan -l $base$ppa -v $vid $1
> esac
> /sbin/ifconfig $1 plumb
>
> (There are other places this could be done, and it's unclear to
> me how this interacts with exclusive IP stack zones.)
>
> b) Modify ifconfig itself to recognize the VLAN naming pattern and,
> if the device named doesn't exist, use libdladm to create it
> first.
>
> These are cheap, easy to specify, implement, and test, and would avoid
> breaking most running systems using VLANs today. It would leave out
> only ad-hoc snooping on unplumbed VLANs and non-IP protocols run over
> VLANs.
>
> Is there any reason to avoid at least that level of compatibility?
>
>
ISTR that we had agreed the team would use an upgrade path akin to
option a, during review. I know that this topic was discussed for more
than just a minute or two during the meeting.
-- Garrett
