Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04)

From: Randy Presuhn <[email-masked]>
Date: Thu, 29 Aug 2013 10:53:12 -0700 (GMT-07:00)

Hi -

>From: ietfdbh <[email-masked]>
>Sent: Aug 29, 2013 7:02 AM
...
>Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re:	Comments	on	draft-asai-vmm-mib-04)
>
>> >> I really don't like the idea of standards prohibiting potentially
>> >> useful functionality.
...
>I would like a better understanding of the benefits that might lead some
>implementers to have persistent values in their implementations; what
>possible useful functionality could we be prohibiting by making this a MUST
>NOT?

As I understand it, the objects vmMinCpuNumber, vmMaxCpuNumber,
vmMinMem, and vmMaxMem, have a potentially significant impact
on the capability of both the VM and the performance of the
hosting system, something that might well be of interest in,
for example, an SLA.  As such, it would seem useful to not
be required to "forget" the settings.

I think accepting the line of reasoning that "since this
MIB is not about configuration" that configuration should
therefor be *prohibited* would set a very bad precedent.
If folks are truly concerned about violating the principle of
least astonishment, then the correct answer, in my opinion,
would be to add a StorageType.

Indeed, if these objects end up being required to *not*
persist, then I could well imagine a vendor creating another
MIB module to model the data that *can* persist.  The semantic
relationship between those objects and these would almost
certainly end up being "astonishing" to operators.

Randy

---

From: "ietfdbh" <[email-masked]>
Date: Thu, 29 Aug 2013 14:24:11 -0400

> I think accepting the line of reasoning that "since this MIB is not about
> configuration" that configuration should therefore be *prohibited* would
set
> a very bad precedent.

+1

David Harrington
[email-masked]
+1-603-828-1401

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Randy Presuhn
> Sent: Thursday, August 29, 2013 1:53 PM
> To: [email-masked]
> >I would like a better understanding of the benefits that might lead
> >some implementers to have persistent values in their implementations;
> >what possible useful functionality could we be prohibiting by making
> >this a MUST NOT?
> 
> vmMinMem, and vmMaxMem, have a potentially significant impact on the
> capability of both the VM and the performance of the hosting system,
> something that might well be of interest in, for example, an SLA.  As
such, it
> would seem useful to not be required to "forget" the settings.
> 
> I think accepting the line of reasoning that "since this MIB is not about
> configuration" that configuration should therefor be *prohibited* would
set
> a very bad precedent.
> If folks are truly concerned about violating the principle of least
> astonishment, then the correct answer, in my opinion, would be to add a
> StorageType.
> 
> Indeed, if these objects end up being required to *not* persist, then I
could
> well imagine a vendor creating another MIB module to model the data that
> *can* persist.  The semantic relationship between those objects and these
> would almost certainly end up being "astonishing" to operators.
> 
> Randy
> 
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: Joe Marcus Clarke <[email-masked]>
Date: Thu, 29 Aug 2013 15:29:36 -0400

> certainly end up being "astonishing" to operators.

My comments stem from what the draft says in that this MIB is not trying
to address config management or persistence to what a vendor may
implement.  I'm also seeing more users shy away from SNMP for
configuration management due to lack of change management hooks (I
realize there is an RFC for SNMP and AAA, but I haven't seen wide
adoption).

Would it not be better to implement something like NETCONF for the
configuration side of things if I really wanted to offer configuration?
 then this MIB could really be left for monitoring.

Joe

-- 
Joe Marcus Clarke, CCIE #5384,         |          |
SCJP, SCSA, SCNA, SCSECA, VCP        |||||      |||||
Distinguished Services Engineer ..:|||||||||::|||||||||:..
Phone: +1 (919) 392-2867         c i s c o  S y s t e m s
Email: [email-masked]

----------------------------------------------------------------------------

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 29 Aug 2013 12:45:36 -0700

Hi -

> From: "Joe Marcus Clarke" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, August 29, 2013 12:29 PM
...
>  then this MIB could really be left for monitoring.

Punting the configuration problem to Netconf doesn't reduce the
modeling (or operational) complexity presented by read-write objects
like these.  If you argue instead that they should be read-only, that's
another matter (though still fraught with complexity, given the ways
Netconf can work) but doing so also, for me at least, raises the "why
bother" question regarding this MIB module.  If these objects would
merely reflect the current configuration data, then they'd add no value,
and there'd be no point in having them at all.

Randy

---

From: Michael MacFaden <[email-masked]>
Date: Thu, 29 Aug 2013 14:16:01 -0700 (PDT)

> and there'd be no point in having them at all.

For any given managed object in this mib module it should be shown how 
this is useful for monitoring purposes otherwise should not be added.

If it duplicates configuration data so be it -- so long as its 
value has been shown.

Regards,
Mike MacFaden Staff Engineer R&D Apps VMware, Inc Palo Alto CA

---

From: Joe Marcus Clarke <[email-masked]>
Date: Thu, 29 Aug 2013 19:11:22 -0400

> and there'd be no point in having them at all.

I would be happy with read-only objects that showed the operational
values.  But there was a use case for changing the operational
parameters via SNMP SET.  In either case, I think the values and
operations should reflect the operational state.

Joe

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 29 Aug 2013 17:00:02 -0700

Hi -

> Sent: Thursday, August 29, 2013 4:11 PM
...
> parameters via SNMP SET.

In my book, that's a configuration change.  It might be made with the
intention of reverting to some previous configuration at some time in
the future, but a configuration change nonetheless.

It sounds like the claim here is that there are knobs whose initial 
settings are presumed to persist as part of system configuration,
but for which any "tweaks" are forgotten.  Those are two different
knobs, should be clearly identified as such, and their relationship
formally spelled out.  Depending on the complexity of their relationship,
it sounds like you may be asking for THREE objects (not all in MIB
modules, of course):
   - the persistent configuration parameter, Netconf or whatever
   - the writable "tweak" knob, whose values might potentially
     be constrained by persistent configuration
   - the read-only operational value, which would be some
     function of the configuration, the tweak knob, and heaven-knows-what
     else.

Randy