[Starlingx-discuss] Questions related to FM containerization

Mon Mar 18 18:54:28 UTC 2019

Mario:

I took the action last week to set up a review this week to discuss a proposal and/or answer further questions in order to get to a proposal.  Are you ready for me to set up the meeting?  If you need more time please suggest a day for us to meet.

Frank

-----Original Message-----
From: Arevalo, Mario Alfredo C [mailto:mario.alfredo.c.arevalo at intel.com] 
Sent: Monday, March 18, 2019 1:12 AM
To: Liu, Tao; starlingx-discuss at lists.starlingx.io
Cc: Rowsell, Brent
Subject: Re: [Starlingx-discuss] Questions related to FM containerization

Hi Tao, thanks for your answer, I think, it sounds as a good plan, however I would also like to complement this with the input from Brent. This is in order to define in a granularity way, the rest of the missing parts to update the storyboard with the needed requirements to accomplish this task (e.g. fm-fault 1 pod, connected through mysql in the same pod? consuming mariadb from x port?, add POST/PUT methods etc).

Thanks.
Best regards.
Mario. 

[0] https://storyboard.openstack.org/#!/story/2004008

> -----Original Message-----
> From: Liu, Tao [mailto:Tao.Liu at windriver.com]
> Sent: Thursday, March 14, 2019 2:54 PM
> To: starlingx-discuss at lists.starlingx.io
> Subject: Re: [Starlingx-discuss] Questions related to FM 
> containerization
> 
> Hi Mario,
> 
>  I think it would simplify the implementation significantly if we only 
> containerize the FM rest API service.
> 
>  You will need to add POST and PUT support in the API server and VIM 
> will use the rest APIs to raise the instance alarms/logs.
> The alarm POST / PUT request handler will need to add alarm history 
> entries to the event log database table.
> 
> The rest API service interfaces with the configured database backend directly.
> Currently postgres is configured as the backend.
> You will need to configure mysql as the database backend for the 
> containerized FM rest API service.
> Openstack Horizon will also interface with containerized FM rest API 
> service and retrieve the instances alarm and event logs.
> 
> I think the alarm suppression should still be managed through the 
> platform fm cli and horizon.
> For the current release, we will not suppress the instance alarms nor 
> would raise SNMP traps inside the containerized services.
> 
> Regards,
> Tao Liu
> 
> ------------------------------
> 
> Message: 2
> Date: Wed, 13 Mar 2019 21:52:12 +0000
> From: "Arevalo, Mario Alfredo C" <mario.alfredo.c.arevalo at intel.com>
> To: "starlingx-discuss at lists.starlingx.io"
> 	<starlingx-discuss at lists.starlingx.io>
> Cc: "brent.rowsell at windriver.com" <brent.rowsell at windriver.com>
> Subject: [Starlingx-discuss] Questions related to FM containerization
> Message-ID:
> 	<6594B51DBE477C48AAE23675314E6C46645994B3 at fmsmsx107.am
> r.corp.intel.com>
> 
> Content-Type: text/plain; charset="us-ascii"
> 
> Hi Brent and team,
> 
> This mail plans to interchange information in order to get more 
> granularity about the "Fault Manager"
> Containerization process where the final objective is to deploy a pod 
> or pods which make completely match with the design of containerization architecture.
> 
> According from the feedback received yesterday in our meeting and 
> taking a look to the source code and the processes which are running 
> in a deployed environment I can understand the possible missing parts.
> 
> This is my understanding about the full picture and some questions 
> about it, please let me know if something is wrong or deviates from 
> the original objective/result. The storyboard [1] related to FM chart 
> will be finished when the FM restful API and the FM manager main 
> services are containerized and work correctly with the rest of the StarlingX components:
> 
> -    I think the best approach is to run a container per service and both containers
> should live in the same pod.
> -    Both services should consume the same Docker image in order to reduce the
> memory foot print.
> -    According the previous shared information and my code exploring I
> understand the FM manager (fmManager
>      binary) is a service which listens in the port 8001 and executes 
> requests. It is launched by an script called "fminit".
>      At this point I have a pair of questions, is this the service 
> which the storyboard [1] makes reference of,
>      intended to have an instance in bare metal and another one 
> exposed by a container?
>      If the last questions is yes, we will have 2 instances of the 
> same service then they should be exposed in a
>      different port, and how about fm rest api service, it will just 
> exist in a container?
>      FM manager service has interaction with a PostgreSQL data base, 
> then I wonder how this will be handled.
>      Does this containerized service point to the bare metal database? 
> Should we add a new chart which exposes
>      a PostgreSQL due to the current chart tarball or just include one for MariaDB.
>      Then the task 28876 makes reference to modify nfv_vim[2] in order 
> to get the alarms information from
>      the container?
> -    Surfing in a deployed image I saw that is possible to remove alarms from the
> web interface provided by
>      horizon, then the task 28878 makes reference to points to the FM 
> manager containerized service from
>      horizon, however it is not clear for me the task 28877 described 
> in the chart storyboard[1].
> 
> These are some points and questions which will give a better 
> understanding for the rest of tasks, however, possibly, I will get 
> more questions during this process I will be in contact with all of you.
> 
> Thank you for your help.
> 
> Best Regards.
> Mario.
> 
> References:
> 
> [1] https://storyboard.openstack.org/#!/story/2004008
> [2] https://git.starlingx.io/cgit/stx-nfv/tree/nfv/nfv-vim/nfv_vim
> 
> 
> 
> 
> -------------- next part -------------- An HTML attachment was 
> scrubbed...
> URL: <http://lists.starlingx.io/pipermail/starlingx-
> discuss/attachments/20190313/a63da701/attachment.html>
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> Starlingx-discuss mailing list
> Starlingx-discuss at lists.starlingx.io
> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
> 
> 
> ------------------------------
> 
> End of Starlingx-discuss Digest, Vol 10, Issue 64
> *************************************************
> _______________________________________________
> Starlingx-discuss mailing list
> Starlingx-discuss at lists.starlingx.io
> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
_______________________________________________
Starlingx-discuss mailing list
Starlingx-discuss at lists.starlingx.io
http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss