Shu,

Thanks for the update! Please see below.

On Tue, Apr 21, 2015 at 11:12 PM, 董舒 <dongs2011@...> wrote:

Actually I posted my progress in slack but it seems that no one was on it, so I will post it here:

Most of the alto-manager code has been done during the last weekend. The code review link: https://git.opendaylight.org/gerrit/18601 . However, the code logic for cost map and endpoint property map is not done yet since currently alto-commons does not support converting from rfc cost-map/endpoint property-map json to the one with yang model encoding, and vice versa (which means it only supports network-map now). Since kai is busy this week, I wrote the converter for the cost-map yesterday by myself but have not tested and pushed the code. I'm expecting to finish the endpoint property map part tonight.

Great!

 

After that I will finalize alto-manger and then help with @xinli to write the test cases with robot framework. I'm expecting to finished all the test cases related to alto-manager this week.

 

Thanks. 

 

Also, I had a long offline discussions with @xinwang about cost field of cost map. Things become a little complicated when it comes to cost field of cost map. If we use augmentation for cost field, alto-commons will depend on the project where the augmentation defined to convert cost-map json string to proper java object, that is to say, here, alto-commons is depending on alto-hosttracker. So could anyone code review and approve the code @xinwang just pushed last weekend so we could use his code?

I will review tomorrow.

 

Also, although using the augmentation, i think defining a default cost field in alto-model is necessary. Currently what we did is just deleting the field from alto-model and defining it in some other projects by augmentation.

Let me understand. What is a goal of defining a default cost field? Or you are suggesting that there is a default cost field, say numerical, and then use augment to change (or add) it into another type, when it is, say, ordinal? My understanding is that augment can only add (https://tools.ietf.org/html/rfc6020#section-7.15). 

For efficient storage, in terms of Java classes, I feel that a possible definition of a cost-map is the following:

Inner level is from string (dst pid name) to the type such as a float (numerical) or int (ordinal) or vector (path-vector): HashMap<String, Integer> or HashMap<String, Double> or HashMap<String, Vector>, ..

Outer level is a hash map from string (src pidname) to the inner level hashmap, e.g.,
HashMap<String, HashMap<String, ValueType>>

A very dumb inheritance based design is is:

class CostMapBase {

  // base field (meta)

}

class CostMapInt extends CostMapBase {

  HashMap<String, Integer> costmap;

}

class CostMapDouble extends CostMapBase {

  HashMap<String, Double> costmap;

}

Or if one uses the containment design:

class CostMap<ValueType> {

  // meta

 HashMap<String, HashMap<String, ValueType>> costmap;

}

I believe that the augment mapping is based on inheritance. Hence, to simulate the first design, the augment defines the whole hashmap of hashmap. Make sense?

Richard 

On Wed, Apr 22, 2015 at 9:15 AM, Y. Richard Yang <yry@...> wrote:

Dear team,

Just in case you are wondering on the quietness of this team, since Kai and Xin Wang are in ODL training, I feel that it is OK to slow down a bit this week. After this week, we will have 2.5 weeks to finalize (Code Free May 14). I am taking advantage of this time to handle a few other issues and read up on ONOS, to see how much of our work can be designed to be general, i.e., portable to ONOS as well, so that we go do a final code refactoring, if needed. 

To avoid to much idle, can one of you (Shu and Xin Li) send out an update on the current status, in particular the missing pieces in terms of finishing T1-T6, so that Wendy and I can start to review the code and help?

Shu/Xin: Could you please send this soon?

Thanks a lot!

Richard