Hi Frank, Yes, I am ready, this Thursday, any time during the morning. Thanks. Best regards. Mario. ________________________________________ From: Miller, Frank [Frank.Miller@windriver.com] Sent: Monday, March 18, 2019 11:54 AM To: Arevalo, Mario Alfredo C; Liu, Tao; starlingx-discuss@lists.starlingx.io Cc: Rowsell, Brent Subject: RE: Questions related to FM containerization 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@intel.com] Sent: Monday, March 18, 2019 1:12 AM To: Liu, Tao; starlingx-discuss@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@windriver.com] Sent: Thursday, March 14, 2019 2:54 PM To: starlingx-discuss@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@intel.com> To: "starlingx-discuss@lists.starlingx.io" <starlingx-discuss@lists.starlingx.io> Cc: "brent.rowsell@windriver.com" <brent.rowsell@windriver.com> Subject: [Starlingx-discuss] Questions related to FM containerization Message-ID: <6594B51DBE477C48AAE23675314E6C46645994B3@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@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@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss