[controller-dev] Any explanation for the concept of Container ?

Giovanni Meo gmeo at cisco.com
Thu Apr 4 10:41:37 UTC 2013


Hi Youcef,

each class returned by the "getImplementations" method in the Activator, will be 
instantiated on every container, however each instance is configured by the call 
"configureInstance" also present in the activator, here one instance can be 
configured differently based on the "containerName" passed as parameter. We are 
not using this feature as of now because of only the default container, but 
there is provision for something more flexible there.

However there is not way currently to prevent an instance of a component on an 
unwanted container, if you implement in the Activator "getImplementations" the 
classes returned by that call will always be instantiated for every container. 
Clearly also this can be enhanced by modifying the 
"org.opendaylight.controller.sal.core.ComponentActivatorAbstractBase" just we 
didn't have a clear case for it, so left to when the need will arise.

Thanks,
Giovanni

On 03-Apr-13 20:00, Youcef Laribi wrote:
> Hi Madhu,
>
> A follow-up question on containers.
>
> Each OSGi module when comes up express its interest in participating in a given
> container and as you can imagine, currently every module express its interest
> for "default" Container in order to make the base Controller to work. All of
> these are handled in the Activator.java of each of the modules. The methods :
> getImplementations()
> and configureInstance() in each of these modules takes care of module level
> functionality needed to participate in a given Container.
>
> In the current code if I read it correctly, it seems that all modules are added
> to all the declared containers (through the call to the module’s
> IContainerAware.containerCreate() by the containerManager for each existing
> container), there doesn’t seem to be a way for a module to choose or express
> interest in only a subset of containers, or am I misreading this logic?
>
> Also, where are containers declared? The ContainerManager.getContainerNames()
> seems to be hardcoded to return only the “default” container.
>
> Thanks
>
> Youcef
>
>
>
> *From:*controller-dev-bounces at lists.opendaylight.org
> [mailto:controller-dev-bounces at lists.opendaylight.org] *On Behalf Of *Madhu
> Venugopal (vmadhu)
> *Sent:* Wednesday, April 3, 2013 5:06 AM
> *To:* Muthukumaran Kothandaraman; controller-dev at lists.opendaylight.org
> *Subject:* Re: [controller-dev] Any explanation for the concept of Container ?
>
> As the name suggests, we have architected a Container to be a self-sufficient
> functional entity that contains component instances of various types that are
> logically grouped together
> to provide specific set of services.  Essentially, we can have multiple
> containers running in the same controller at the same time (identified by its
> unique container name)
> and each runs in its own domain. For example, Each of this container can contain
> its own TopologyManager, ARP Handler, Host Tracker, etc… and form its own
> topology and run
> its own topology algorithm for its domain. Each of the domain can choose to
> control the entire network or part of the network or certain applications in the
> network subset.
> Each module can be configured to participate in any of the containers. Each of
> the Container can have its own administrative and management access.
>
> By default, when the controller comes up, every service you see in the
> controller, such as Topology, ARP, HostTracker, etc all belong to "default"
> Container.
> Each OSGi module when comes up express its interest in participating in a given
> container and as you can imagine, currently every module express its interest
> for "default" Container in order to make the base Controller to work. All of
> these are handled in the Activator.java of each of the modules. The methods :
> getImplementations()
> and configureInstance() in each of these modules takes care of module level
> functionality needed to participate in a given Container.
> ContainerManager will be the place where most of the container administration
> and configuration will be performed. As you can see, the controller has all the
> necessary infrastructure
> and code in place in each of the modules to be participate in containers. But,
> we have to beaf up the ContainerManager to make all of the above explained
> architecture to come true.
> We can add more information on these in the wiki as we make progress on making
> the Container Manager rich and more functional.
>
> Please let us know if you have more questions on this.
>
> Thanks,
> Madhu
>
> --------------------------------------------------------------------------------
>
> *From:*controller-dev-bounces at lists.opendaylight.org
> <mailto:controller-dev-bounces at lists.opendaylight.org>
> [controller-dev-bounces at lists.opendaylight.org] on behalf of Muthukumaran
> Kothandaraman [mkothand at in.ibm.com]
> *Sent:* Wednesday, April 03, 2013 3:21 AM
> *To:* controller-dev at lists.opendaylight.org
> <mailto:controller-dev at lists.opendaylight.org>
> *Subject:* [controller-dev] Any explanation for the concept of Container ?
>
> Hi,
>
> Could anyone explain the concept of container ? What are the type of domain
> entities which has dependency on container (flows, switches (Nodes), etc) ?
>
> I could not locate anything specifically in arch documentation .
>
> Regards
>
> Muthukumaran (Muthu)
> mkothand at in.ibm.com <mailto:mkothand at in.ibm.com>
> M : +91-9845363820
> L  : 080-49141730
>
> P(existence at t) = 1- 1/P(existence at t-1)
>
>
>
> _______________________________________________
> controller-dev mailing list
> controller-dev at lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>

-- 
Giovanni Meo
Via del Serafico, 200                  Telephone: +390651644000
00142, Roma                            Mobile:    +393480700958
Italia                                 Fax:       +390651645917
                                        VOIP:      8-3964000
“The pessimist complains about the wind;
  the optimist expects it to change;
  the realist adjusts the sails.” -- Wm. Arthur Ward
IETF credo: "Rough consensus and running code"


More information about the controller-dev mailing list