[Starlingx-discuss] Questions related to FM containerization

Mon Mar 18 05:11:38 UTC 2019

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