Conference azur::mcc

835.0. "Upward compatible mgmt models" by COOKIE::KITTELL (Richard - Architected Info Mgmt) Fri Mar 22 1991 15:52

        Help me understand how to deal with upward compatibility of
        management specifications. You've probably got this all
        figured out for the network stuff, but it eludes me. As usual,
        I have a scenario. Say V3.0 of my management spec has an
        Flavor attribute defined as this enumeration:

          TYPE Flavors = nn (Vanilla = 1, Chocolate = 2);

        We ship V3, it's a hit so we ship a bunch, make bags 'o bucks
        and bring DEC stock up $120. For V3.1 we want to add Strawberry:

          TYPE Flavors = nn (Vanilla = 1, Chocolate = 2, Strawberry = 3);

        So we update the management spec and the version returned for the
        implementation of the object. We ship V3.1 and customers start
        installing it.

        Assuming for the moment that only the director (PM/AM) and the
        entity know the details, and that they are both driven from
        the MCC dictionary, we have four possible combinations. Two
        aren't interesting, the ones where both the director and the
        entity are from the same version kit. Of the other two, the
        easy one is where the director is at V3.1 and the entity is at
        V3.0. The V3.0 entity only sends a 1 or a 2 for the Flavor
        attribute value, so the V3.1 director has no trouble with
        that.

        But we've put up the V3.1 kit on node A, which is where the
        entity is running. On node B, which is still running V3.0, we
        fire up MCC and Show the entity. The entity has had its Flavor
        attribute set to Strawberry, so it returns a 3 for the
        attribute integer value. What happens?

        If the AM just passes through the 3 as the attribute value,
        the MCC V1.1 FCL and Iconic PMs will display "%MCC-E-NOENTITY,
        no corresponding entity instance exists", and not display any
        of the other values, the Show fails. I know that it is on the
        list for MCC V1.2 to make that message more meaningful. Have
        any plans been made as to what it will do? For enumerations,
        at least, I'd sure like it to display something like

           Implementation = ({Component = Creamery,
                                Version = V3.1.0})
                   Flavor = Enumeration (3) not in dictionary

        That would assure that a V3.0 director could still display
        info from a V3.1 entity, even if it couldn't translate all the
        enumerations. In addition, we could have the V3.1 release
        notes indicate that the value 3 means Strawberry.

        For MCC V1.1, an option that occurs to me, at least for those
        enumerations I might be able to anticipate extending in the
        future, would be to define the enumerations for V3.0 as

        TYPE Flavors = nn (Vanilla = 1, Chocolate = 2,
                           Unknown Flavor = 99999999);

        The AM would then "sniff" the values coming back from the
        entity, and force anything it didn't recognize to 99999999,
        thus giving the PM something reasonable to display:

           Implementation = ({Component = Creamery,
                                Version = V3.1.0})
                   Flavor = Unknown Flavor

        The difference being that the integer value isn't displayed, so
        there isn't a way to tell which of the new flavors it might
        be.

        Another alternative, of course, is for the V3.0 AM to sample
        the entity version and refuse to do business with an entity
        newer than itself.

        Or have the entity support both management models. Every
        request from the AM would have to include the AM version so
        the entity could decide what to return. But it isn't clear
        what a V3.1 entity whose flavor was Strawberry could tell a
        V3.0 AM without lying to it.

        Which tricks am I missing?

    a bunch of worthwhile ideas...at this time the mcc-noentity error is
    seen as just that an error, it has been qared. I don't know quite yet
    what we are going to do about it yet. The most reqeusted change is to
    simply do a hex dump of the value. Therefore in your strawberry example
    if it isn't a known flavor we would print the number 3.
    
    jill
    

    Fix the PM. Print it as 3. That's what the NCL spec says to do in this
    case. It's the only reasonable choice of the ones Richard listed.