Hi Juergen,
I think the indentation in our emails play havoc which is confusing me
too. The key point I am making is:
The mapping of what is called intended-config onto data stores would
deserve more detailed discussion. It seems the authors of
draft-kwatsen-netmod-opstate-02.txt had in mind to associate intended-cfg
with the [running] datastore. In my understanding, a failure in applying
[running] to [applied] will update the [running] datastore to reflect
which part is effectively applied. So a fair representation of that case
would be:
[candidate] -> [running] <--> [applied] -> derived state
In the context of intended-configuration however that doesn’t make sense
to me. A failure in applying intended configuration doesn¹t change the
intention and the delta between intended and applied-config is the key
value. A server that would "clean-up" intended-cfg in presence of a
failure to apply would look picture perfect instead of exposing the
problem clearly. Hence the sequence should more look like:
[candidate] -> [intended] ‹-> [running==applied] -> derived state
Whatever we choose, I believe we need to spell out what¹s the data in a
failure case. It¹s probably a bit late to update the requirements draft,
but we can probably find a suitable place.
———
I am also wondring if we have the same understanding related to the
following statement:
I thought the whole point of having an applied config is to be able to
see the difference between intended (oops running) and applied.
The current draft-kwatsen-netmod-opstate-02.txt says:
"Any rollback that may occur will restore both the intended and the
applied configurations to their previous states."
The challenge I have is the term “(oops running)” in the first sentence in
combination with the citation. I reckon that any difference between
intended-config and applied-config shall be visible whereby the
intended-config is provided by the client and never altered by the server.
Applied-config on the other hand represents the state of the server. If a
failure happens in the application phase, it shall be treated accordingly
(rollback-, stop-, continue-on-error). As a result the difference between
intended and applied configuration shall be maintained.
So does this square with the notion "intended=running" and “applied”
config?
- Gert
On 2016-08-02 17:38, "Juergen Schoenwaelder"
<[email protected]> wrote:
>On Mon, Feb 08, 2016 at 02:53:57PM +0000, Gert Grammel wrote:
>>
>>
>> >This is not what is being proposed. We always had
>> >
>> >[candidate] -> [running] -> operational state
>> >
>> >(and I mark configuration data stores in []). Both [candidate] and
>> >[running] have the same configuration data model. Now we are asked
>> >to expose that [running] may not be applied synchronously and hence
>> >
>> >[candidate] -> [running] -> [applied] -> derived state
>> >
>> >seems to make sense.
>
>Why would that be the case? If I configure an interface that is not
>currently present today in running this is just find and running is
>not expected to change arbitrarily.
>
>> The mapping of what is called intended-config onto data stores would
>> deserve more detailed discussion. It seems the authors of this draft had
>> in mind to associate intended-cfg with the [running] datastore. With
>>that
>> mapping, a failure in applying [running] to [applied] will update the
>> [running] datastore to reflect which part is effectively applied. So a
>> fair representation of that case would be:
>> [candidate] -> [running] <--> [applied] -> derived state
>
>What is 'this draft'? I thought the whole point of having an applied
>config is to be able to see the difference between intended (oops
>running) and applied. I am confused now.
>
>> In the context of intended configuration however that doesn¹t make sense
>> to me. A failure in applying intended configuration doesn¹t change the
>> intention and the delta between intended and applied-config is the key
>> value. A server that would "clean-up² intended-cfg in presence of a
>> failure to apply would look picture perfect instead of exposing the
>> problem clearly. Hence the sequence should more look like:
>> [candidate] -> [intended] ‹> [running==applied] -> derived state
>>
>> Whatever we choose, I believe we need to spell out what¹s the data in a
>> failure case. It¹s probably a bit late to update the requirements draft,
>> but we can probably find a suitable place.
>
>There is apparently much less agreement on what the problem is, what
>the terms mean, and how they related to existing technology than I
>thought.
>
>/js
>
>--
>Juergen Schoenwaelder Jacobs University Bremen gGmbH
>Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
