[Starlingx-discuss] Questions related to FM containerization

Tue Mar 19 21:56:02 UTC 2019

Hi Frank,

Yes, I am ready, this Thursday, any time during the morning.

Thanks.

Best regards.
Mario.
________________________________________
From: Miller, Frank [Frank.Miller at windriver.com]
Sent: Monday, March 18, 2019 11:54 AM
To: Arevalo, Mario Alfredo C; Liu, Tao; starlingx-discuss at 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 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