Subject: Re: [netmod] opstate-reqs #5: Support for situations when structure of intended configuration is not the same as applied

From: Randy Presuhn <[email-masked]>
Date: Tue, 20 Oct 2015 10:31:07 -0700 (GMT-07:00)

Hi -

>From: "Einar Nilsen-Nygaard (einarnn)" <[email-masked]>
>Sent: Oct 20, 2015 5:17 AM
>To: Martin Bjorklund <[email-masked]>
>Cc: "[email-masked]" <[email-masked]>
>Subject: Re: [netmod] opstate-reqs #5: Support for situations when structure of intended configuration is not the same as applied
...
>To perhaps be a little more precise, I mean that it is the
>server's job to make the information about whether or not
>intended config has been instantiated correctly in a way
>that is really easy to correlate with the intended config
>asserted by the client. In terms of aggregating the status
>of the operational leaves into a ingle value that could,
>for example, be diff'd with the intended config, that would
>meet the criteria of being easy to correlate with the intended
>config.

This discussion seems to conflate three distinct problems.

One, which is a classic configuration management problem and
which was one of the operator requirements going into this work
from the beginning, is the ability to compare two configurations.
A special case of this is comparing a system's actual configuration
with an intended configuration.  Should be incredibly straightforward.

The second problem, which was mentioned more-or-less in passing
at the IAB workshop, is in the realm of intention-based management.
One of the tools needed to implemented intention-based management
is the ability to compare a systems actual *operational* state
with an intended operational state.

The similarity between these two problems is superficial; even
with a deep understanding of the relationship between the two
state spaces (including acknowledgement of the fact that operational
state often depends on factors that are outside the configuration)
it can be very difficult to get from A to B.

The third problem arises from excessive complications in the inter-
relationships between model components, resulting in situations
where one can't fully validate a request without actually
trying to activate it.  This largely avoidable problem is a
question of both system and management interface design.  In
legacy environments, however, it may be intractable.

>What we may find is that thinking about requirements like this may
>make us more mindful of how we define the relationship between
>intended config and how our internal components work together
>to achieve it and how we expose the success or failure of config
>operations in a way that is easier for users to make sense of.

Another way of putting it:
  It *is* possible to design management interfaces in such a way
  as to make both kinds of interactions easier.  However, as long
  as the working assumption is that these technologies will
  essentially serve as a wrapper for legacy CLIs, making this work
  will require vast amounts of duct tape.

>Additionally, I'm not saying that there isn't operational state
>that each of the N internal components have. That still exists,
>and will continue to exist as part of ongoing operational management.

Agreed.  But there's going to be tension between supporting what
one might need to handle a modular system designed from the
outset to be managed using this technology, and supporting the
crufty realities of systems where the management interface has
been cobbled together over many years with short-term expediency
as its guiding principle.

Randy