Hi - >From: "Einar Nilsen-Nygaard (einarnn)" <[email protected]> >Sent: Oct 20, 2015 5:17 AM >To: Martin Bjorklund <[email protected]> >Cc: "[email protected]" <[email protected]> >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 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
