Hi David,



Given the current situation, MSB should take the service endpoint registration 
integration with kubernetes implementation as its priority for Amsterdam and 
integration with cloudify implementation as a stretch goal.




As we discussed in the last OOM meeting, we need a repo to accommodate the 
registrator codes for kubernetes service. Can you help to create that repo?  
Please let me know if you have any concerns or question.





Release Components Name

Components Name

Components Repository name

Maven Group ID

Components Description
registratoroom/registratororg.onap.oom.registratorRegister the service 
endpoints to MSB so it can be used for service request routing and load 
balancing. Registrator puts service endpoints info to MSB discovery 
module(Consul as the backend) when an ONAP component is deployed by OOM, and 
update its state along with the life cycle, such as start, stop, scaling, etc.


Resources committed to the Release


Thanks,

Huabing






Original Mail



Sender:  <david.sauvag...@bell.ca>
To:  <jn1...@att.com>
CC: zhaohuabing10201488 <jflu...@research.att.com> <jh2...@att.com> 
<rb2...@att.com> <ht1...@att.com> <roger.maitl...@amdocs.com> 
<j...@research.att.com>MengZhaoXing10024238 <c...@research.att.com> 
<ag1...@att.com> <onap-discuss@lists.onap.org>
Date: 2017/07/26 19:39
Subject: Re: [MSB][OOM]The July Virtual Developers Event Topic :  OOM & MSB 
Interaction






Hi John
 
Let’s recap what was discussed and agreed as a team:

* For Amsterdam release, Kubernetes is the first OOM technical implementation 
to be created. This is the seed code available and what the team agreed to work 
on

* The cloudily implementation has not been demoed yet and no seed code 
available. It was agreed by the team that cloudily would be a stretch target.
 
I want to make sure we align to what the OOM team has agreed to deliver.
 
Comments?
 
On Jul 25, 2017, at 6:39 PM, NG, JOHN <jn1...@att.com> wrote:
 


Huabing,

Ok, let’s focus on Consul integration for the Amsterdam release …

-          In  Day 0 OOM instantiation, Cloudify is the first OOM module to be 
created.


-          Cloudify  creates Consul as the next OOM module.   Cloudify 
registers itself in Consul.


-          Cloudify  then creates the rest of the OOM modules (Postgres, API 
Handler, Dashboard), and registers each module in Consul.  And Consul starts 
performing health checks against them.


-          OOM  instantiation is now complete.


-          OOM  deploys MSB as one of the first ONAP components.  OOM 
provides/configures MSB with the location of the Consul API for access and 
discovery.


-          OOM  then continues to deploy the rest of the ONAP components and 
modules, and registers them with Consul.


Comments?
 
John
 
------------------------------------------------------- John Ng AT&T Labs – D2 
Architecture 200 Laurel Ave, D5-3D16 Middletown, NJ 07748 +1 732 420 3742 +1 
732 310 3253 (mobile) joh...@att.com 
-------------------------------------------------------
 
From: zhao.huab...@zte.com.cn  [mailto:zhao.huab...@zte.com.cn]  Sent: Monday, 
July 24, 2017 9:48 PM To: NG, JOHN <jn1...@att.com> Cc: LUCAS, JACK 
<jflu...@research.att.com> HU, JUN NICOLAS <jh2...@att.com> BENNETT, RICH 
<rb2...@att.com> david.sauvag...@bell.ca TORAB, HABIB M <ht1...@att.com> 
roger.maitl...@amdocs.com MURRAY, JOHN <j...@research.att.com> 
meng.zhaoxi...@zte.com.cn RATH, CHRISTOPHER A <c...@research.att.com> GAULD, 
ANDREW G <ag1...@att.com> onap-discuss@lists.onap.org Subject: Re:RE: 
[MSB][OOM]The July Virtual Developers Event Topic :  OOM & MSB Interaction
 

Hi John,


 


I'm afraid that I can't agree that.


 


There is a clear boundary between OOM and MSB and their project scopes are 
totally different. I think these have already been fully discussed in the 
community in the last few months and approved by TSC at the Beijing meeting.


 


Right now our first priority should be the release goal of Amsterdam and we 
should focus on our last agreement - the integration point at Consul. Given 
that MSB is providing Microservice Infrastructure for ONAP components, I hope 
we can do it ASAP.


 


Thanks,


Huabing


 


 




Original Mail





Sender:  <jn1...@att.com>



To: zhaohuabing10201488 <jflu...@research.att.com> <jh2...@att.com>  
<rb2...@att.com> <david.sauvag...@bell.ca>  <ht1...@att.com> 
<roger.maitl...@amdocs.com>  <j...@research.att.com>MengZhaoXing10024238 
<c...@research.att.com>  <ag1...@att.com>



CC:  <onap-discuss@lists.onap.org>



Date: 2017/07/25 07:05



Subject: RE: [MSB][OOM]The July Virtual Developers Event Topic :  OOM & MSB 
Interaction



 




Hi Huabing,

I am not sure whether this topic has been discussed yet.  We have an 
alternative proposal and added Slide 6 on the ppt file you uploaded on the MSB 
page.  Please   review and share your thoughts. 
 
Our proposal is to merge MSB and OOM.  We agree that there should be a common 
software framework and implementation of the service registration and service 
discovery   functions.  We agree that there should be a shared Consul instance 
to support the registration/discovery functions.  We want to avoid any 
potential collisions where multiple parties register services with the same 
names/URIs – so we might need to work out   rules (name spaces) to prevent 
them. 
 
One question we have is whether there is a use case that shows MSB operating 
outside of OOM for microservices/service endpoints?  We could not think of any 
and   so recommend that merging MSB and OOM be considered.  We see that 
microservices and ONAP components being deployed and managed by OOM in a common 
process:

1.      OOM  (Cloudify) creates virtualized infrastructure and 
container/kubernetes cluster via TOSCA based blueprints


2.      OOM  (Cloudify) triggers (via kubernetes) the dockerized image 
(microservice or ONAP component module) to be created


3.      OOM  (Registry) listens for container creation in the pod and registers 
the new container


4.      OOM  (Discovery) updates inventory database and begins to health check 
the new container (microservice or ONAP module)


5.      OOM  (Discovery) updates health status to Internal/External Gateways


6.      OOM  (Gateways) route service requests to healthy service endpoints


7.      OOM  (Cloudify) performs recovery, healing, scale actions based on 
health status

 
Please provide feedback and we would be happy to discuss.
 
John

------------------------------------------------------- John Ng AT&T Labs – D2 
Architecture 200 Laurel Ave, D5-3D16 Middletown, NJ 07748 +1 732 420 3742 +1 
732 310 3253 (mobile) joh...@att.com 
-------------------------------------------------------
 
From: zhao.huab...@zte.com.cn [mailto:zhao.huab...@zte.com.cn]  Sent: Friday, 
July 21, 2017 2:33 AM To: LUCAS, JACK <jflu...@research.att.com>  HU, JUN 
NICOLAS <jh2...@att.com>  BENNETT, RICH <rb2...@att.com> 
david.sauvag...@bell.ca  TORAB, HABIB M <ht1...@att.com> 
roger.maitl...@amdocs.com  MURRAY, JOHN <j...@research.att.com>  NG, JOHN 
<jn1...@att.com>   meng.zhaoxi...@zte.com.cnzhao.huab...@zte.com.cn Cc: 
onap-discuss@lists.onap.org Subject: [MSB][OOM]The July Virtual Developers 
Event Topic :  OOM & MSB Interaction
 

Hi there,


 


Will you be able to attend this topic:  OOM & MSB Interaction? I would 
appreciate it if both OOM team and the AT&T cloudify proposal folks could join 
to discuss it.


https://wiki.onap.org/pages/viewpage.action?pageId=8232264


 


Thanks,


Huabing
_______________________________________________
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Reply via email to