On Sep 25, 2014:6:12 AM, at 6:12 AM, Joel M. Halpern <[email protected]> wrote:
> Separate ephemeral data stores for distinct I2RS clients would seem a very
> bad idea.
> It is perfectly acceptable for one client to read information being
> manipulated by another cleitn. And if so, the reader should see the results
> of that other clients activity.
I agree with Joel here. I was quite surprised by Dean's first note
making this statement. This seems like undue complication to the whole
situation. Making this work can be quite straight-forward. The problem with
having a store per-client is that well, clients can be ephemeral too. People
need to remember that the i2rs clients are probably going to be applications
that might come and go, and as such should a device have to keep around a lot
of state for everyone that talks to it via its Rest/i2rs API? That does not
sound like a good idea to me, even if we time it out.
> Also, separate stores would not produce the error results required in the
> case of collision.
Yes, that is precisely another issue that came to mind - besides the
scale of having one per client, do we really want to place the burden on the
device to let all clients know of collisions when merging? What if those
clients have "gone away"?
> So no, I do not see a use case from I2RS for multiple ephemeral data stores.
Agree %100.
--Tom
>
> Yours,
> Joel
>
> On 9/24/14, 9:48 PM, Dean Bogdanovic wrote:
>>
>> On Sep 24, 2014, at 5:19 PM, Andy Bierman <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>>
>>>
>>> On Wed, Sep 24, 2014 at 2:00 PM, Dean Bogdanovic <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>>
>>> On Sep 24, 2014, at 12:54 PM, Thomas D. Nadeau
>>> <[email protected] <mailto:[email protected]>> wrote:
>>>
>>> >
>>> > On Sep 24, 2014:11:34 AM, at 11:34 AM, Jeffrey Haas
>>> <[email protected] <mailto:[email protected]>> wrote:
>>> >
>>> >> On Wed, Sep 24, 2014 at 07:35:47AM -0400, Thomas D. Nadeau wrote:
>>> >>> On Sep 24, 2014:3:10 AM, at 3:10 AM, Juergen Schoenwaelder
>>> <[email protected]
>>> <mailto:[email protected]>> wrote:
>>> >> [...]
>>> >>>>
>>> >>>> +-----------------+
>>> >>>> | |
>>> >>>> +--- (+) ---+ |
>>> >>>> ^ ^ v
>>> >>>> +---+ +---+ +---+
>>> >>>> | | | | | |
>>> >>>> |(1)| | | | |
>>> >>>> | | | | | |
>>> >>>> +---+ +---+ +---+
>>> >>>>
>>> >>>> NC config ephemeral operational
>>> >>>> datastore datastore state
>>> >>>>
>>> >>>> (1) The complete NC config datastore is at certain
>>> synchronization
>>> >>>> points made persistent
>>> >>>>
>>> >>>> (+) Priority resolution, priorities may be per datastore or per
>>> >>>> user or per 'application' or even per data node
>>> >>>
>>> >>> These are precisely the qualities I and some others were
>>> thinking of when we started i2rs. The idea is quite simple, as you
>>> have said above and really needs not be complicated more.
>>> >>
>>> >> It has its own complications.
>>> >>
>>> >> Do we permit more than one ephemeral datastore? If so, this
>>> simplifies data
>>> >> object priority when resolving the operational state. But this
>>> also
>>> >> complicates operational state integrity when you have multiple
>>> cross
>>> >
>>> > I vote for keeping this simple for starters. Lets get an
>>> implementation or two of a single ephemeral data store. This
>>> avoids having multiple priorities too; its just 1.
>>> >
>>> > --Tom
>>> We can allow multiple ephemeral data stores, but the only
>>> dependency can be with the NC config datastore. Example:
>>>
>>> residential services
>>> business services
>>>
>>>
>>>
>>> What does this really mean?
>>> I did not understand the details at the interim.
>>> Does this mean each datastore has separate data models?
>>
>> yes, each data store has separate data models
>>
>>> Does this mean each service represent separate I2RS clients?
>>
>> each ephemeral datastore represents separate I2RS clients.
>>
>>>
>>> The only real reason to have multiple ephemeral datastores
>>> would be to create the same instances of 1 or more data nodes
>>> in multiple datastores. (multiple concurrent overlays).
>>
>> I view it differently. In subscriber management different data models
>> are used for residential and business subscribers. Some service data
>> models can be very unique for business customers. So separating them in
>> different data stores makes sense, as they there are no overlaps with
>> each other, only with NC config store. In this case, we can get better
>> performance.
>>>
>>> IMO this sort of complexity should be left out of the agent.
>>>
>>>
>>> each of the configuration sits in their own ephemeral datastore,
>>> but only dependency is on NC config store.
>>>
>>> As we are still keeping 1 to 1 overlay, not many to 1.
>>>
>>>
>>> Dean
>>>
>>>
>>>
>>> Andy
>>>
>>> >
>>> >
>>> >> references.
>>> >>
>>> >> -- Jeff
>>> >>
>>> >
>>> > _______________________________________________
>>> > netmod mailing list
>>> > [email protected] <mailto:[email protected]>
>>> > https://www.ietf.org/mailman/listinfo/netmod
>>>
>>> _______________________________________________
>>> i2rs mailing list
>>> [email protected] <mailto:[email protected]>
>>> https://www.ietf.org/mailman/listinfo/i2rs
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> i2rs mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/i2rs
>>
>
> _______________________________________________
> i2rs mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/i2rs
>
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
