adding intents not mentioned in KryoNamespaces.API

[Hadi Kahraman]

Hi,

We need to write an external intent class and submit to IntentService, which uses a fixed serializer based on KryoNamespaces.API. ONOS version is 1.8.2.

There seems no problem with the corresponding IntentCompiler class; it is not distributed.

Are we missing something?

[Yi Tseng]

Also c.c to northbound brigade

Hello,

Intent store uses KryoNamespace to serialize Intents and stores Intents to distributed data structure (EventuallyConsistentMap)

Is there any error from your ONOS log?

--

Yi

--
You received this message because you are subscribed to the Google Groups "ONOS Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to onos-dev+unsubscribe@onosproject.org.
To post to this group, send email to onos...@onosproject.org.
Visit this group at https://groups.google.com/a/onosproject.org/group/onos-dev/.
To view this discussion on the web visit https://groups.google.com/a/onosproject.org/d/msgid/onos-dev/CAPHQ%2BV%2Bk8G9po7czOJXRa9ZEJYHhSZrrgq%2BLXBjbH639fhubPw%40mail.gmail.com.

[Hadi Kahraman]

Hello Yi,

Kryo does not recognize classes which are not registered with it. The only way to register our intent classes with Kryo serializer of GossipIntentStore is to hardcode them into KryoNamespaces.API or GossipIntentStore itself.

We prefer adding our intent classes intent subsystem dynamically.

I will ask my colleagues for any related log.

[Yi Tseng]

Hello,

I think currently we can't change Intent serializer in the store dynamically.

As you mentioned, now we can only change namespace API or Intent store.

--Yi

[Jordan Halterman]

Unfortunately, it may be difficult to allow serializers to be provided dynamically by applications. Because intents are replicated internally, they have to be registered when internal maps are created to ensure all entries replicated from other nodes can be deserialized.

It actually seems like we need a SerializationService that allows users to register custom types for serialization in these types of cases.

To unsubscribe from this group and stop receiving emails from it, send an email to onos-dev+u...@onosproject.org.

To post to this group, send email to onos...@onosproject.org.
Visit this group at https://groups.google.com/a/onosproject.org/group/onos-dev/.

To view this discussion on the web visit https://groups.google.com/a/onosproject.org/d/msgid/onos-dev/CANbTR4QD5fnahnrK8T%3Dn0mFtgtiZy6wv%3DK2yBCSbrz8ez2AYhw%40mail.gmail.com.

[Hadi Kahraman]

---------- Forwarded message ----------
From: Hadi Kahraman <hadi.k...@gmail.com>
Date: 2017-04-26 8:19 GMT+03:00
Subject: Re: [onos-dev] adding intents not mentioned in KryoNamespaces.API
To: Yi Tseng <y...@onlab.us>

Thanks Yi,

Let me clarify the word "dynamically": I meant "not hardcoded but provided at startup externally".

I examined the code. Serializers cannot be extended after they are created. Distributed map does not allow replacing the serializer with an extended one.

[Hadi Kahraman]

Hi Jordan,

How can we use serialization service for this specific case?

I understand that Kryo registration ids must be consistent across the cluster (interoperability) and through versions (backward compatibility).

Assuming that Kryo class ids can be large and randomly distributed integers, ids can be calculated from full class names instead of assigning manually.

I used this technique successfully 15 years ago (I am 59 now) for both a distributed class registry and a fast serializer replacing java serialization.

Consistent hash codes prevent problems arise from accidental swapping of registration order of classes (class ids swap).

Classes implementing Externalizable are serialized by their own methods.

Thanks

To view this discussion on the web visit https://groups.google.com/a/onosproject.org/d/msgid/onos-dev/CANbTR4QD5fnahnrK8T%3Dn0mFtgtiZy6wv%3DK2yBCSbrz8ez2AYhw%40mail.gmail.com.

[Yi Tseng]

Hi Hadi,

Sorry for late reply,

I understand your idea.

Basically we need to do some modification of current KryoNamespace and IntentStore; allows them register new Intent class in runtime.

One problem is to change serializer for IntentStore, we need to make sure all serializer from all ONOS nodes changed before we submit new Intents.

So we need to design another mechanism to handle it.

--Yi

[Yi Tseng]

Hi Hadi,

I understand your idea, using static hash instead of using an dynamic number is a possible way to make all id of class static.

However, the problem I mentioned in previous mail still not resolve.

If there exists any Intent data in the IntentStore, we need to create new ConsistentMap and move all Intent data to new map.

Also, we need to wait all ONOS nodes finish this process before the application submit new Intent data to the system.

I've create a ticket for this feature:
https://jira.onosproject.org/browse/ONOS-6406

Hi Yuta,

I need some suggestions for his modifications.

Thanks

--Yi

On Wed, May 3, 2017 at 6:27 AM, Hadi Kahraman <hadi.k...@gmail.com> wrote:

Hi Yi,

I was on a short vacation.

I think dynamic type registration usage pattern is something like this:

• Intent subsystem starts with a default set of types
• An application registers its specific intent classes with IntentService when it activates
  
• Application submits its intents

How will things work? Let me describe with a basic pseudo-code below. Does it make sense?

-------------------- EXISTING ---------------------------------

KryoNamespace.Builder.nextId (BASE_ID) // add exisiting types to blocks, then set base id
KryoNamespace.Builder.register (Class<?>...) // add to list of types
...
KryoNamespace.Builder.build():
    add types to list of blocks // each block has a base id
    new KryoNamespace (blocks, ...).populate(1)

KryoNamespace.populate (1):
    release (create()) // 1 instance only

KryoNamespace.create:
    kryo = new Kryo()
    // I don't know how InstantiatorStartegy effects things
    for each block:
        id = block.base
        for each type in block:
            kryo.register (class, serializer, id++)
    return kryo

KryoNamespace.release (kryo):
    kryoPool.release (kryo) // put kryo instance into the pool

-------------------- MODIFIED ---------------------------------

... // blocks are not needed anymore
            kryo.register (class, serializer, crc64(class.getName().getBytes))
...

KryoNamespace.register (Class<?>...) // new method chain: IntentManager -> IntentStore -> KryoNamespace
    loop: // modify all kryo instances in place, serializer automatically recognizes newly registered classes
        kryo = kryoPool.borrow
        kryo.register (class, crc64(class.getName().getBytes))
        stash kryo
    release all kryo instances in the stash back to the pool

[Hadi Kahraman]

Hi Yi,

Thanks for opening an issue.

I saw a minute ago that EventuallyConsistentMapImpl of 1.8.2 creates another KryoNamespace by importing things from the original one given by IntentStore. Therefore registering classes to the original kryo afterwards does not affect the EventuallyConsistentMap.

Idea of registering more classes in place (without creating a new distributed map and importing existing entries) requires touching several infrastructure classes.

Even if this is done, in distributed/clustered mode of operation, race conditions will occur. On node A intent user application X makes its extensions and adds new entries. Meanwhile on node B application X hasn't started yet. Therefore intent map on node B doesn't know classes of X when new entries arrive from node A!

[Yi Tseng]

Hello,

It think the possible way for now is to put your new Intent class into the ONOS code base before we finish new mechanism.

It is very welcome to submit a patch to ONOS project.

--Yi

To view this discussion on the web visit https://groups.google.com/a/onosproject.org/d/msgid/onos-dev/CAPHQ%2BVJrnb_RXvOznd1pKkMnK9ifAEWcyjOwmDKZQ1OSM6rhtA%40mail.gmail.com.