[Starlingx-discuss] [Containers] Background info on helm
Arevalo, Mario Alfredo C
mario.alfredo.c.arevalo at intel.com
Thu Feb 7 22:54:54 UTC 2019
Hi Tao,
That is correct, I was making reference to "/stx/stx-fault/fm-api", and yeah
I am containerizing FM rest api, thanks for your answer.
Best regards.
Mario.
________________________________________
From: Liu, Tao [Tao.Liu at windriver.com]
Sent: Thursday, February 07, 2019 2:20 PM
To: starlingx-discuss at lists.starlingx.io
Subject: Re: [Starlingx-discuss] [Containers] Background info on helm
Hi Mario,
With regards to issues # 2, FM rest api (located under stx/stx-fault/fm-rest-api) does not use a shared object called “libfmcommon.so”.
Unless you are referring to FM application API (located under /stx/stx-fault/fm-api), correct me if I am wrong.
The application API is provided as a python package and it is used by the platform applications to raise/clear alarms, or generate logs.
The rest API provides client interfaces, and a API server for communicating with other applications(both internal and external) that request to review alarms/logs, or suppress alarms (from viewing).
In the pre-k8s world, VIM uses the application API to raise/clear alarms, and generates logs; this api is imported as a python package.
For orchestration, VIM uses the rest api to monitor system alarms/logs.
With regards to the issue #1, you are referring to FM rest api paste config file.
I assume that you are containerizing FM rest api, since the application API is not a message-based interface .
Regards,
Tao
-----------------------------------------------------------------------------------------------------------------------------------------------------
Message: 3
Date: Thu, 7 Feb 2019 20:12:46 +0000
From: "Arevalo, Mario Alfredo C" <mario.alfredo.c.arevalo at intel.com>
To: "Penney, Don" <Don.Penney at windriver.com>, "Wold, Saul"
<saul.wold at intel.com>, "al.bailey at windriver.com"
<al.bailey at windriver.com>, "Troyer, Dean" <dean.troyer at intel.com>
Cc: "starlingx-discuss at lists.starlingx.io"
<starlingx-discuss at lists.starlingx.io>
Subject: Re: [Starlingx-discuss] [Containers] Background info on helm
charts
Message-ID:
<6594B51DBE477C48AAE23675314E6C466456A983 at fmsmsx107.amr.corp.intel.com>
Content-Type: text/plain; charset="Windows-1252"
Hi team,
There is a pair of issues which needs to be solved in order to create a “fm rest api” docker
image that can work correctly.
Issue 1:
=======
The fm-rest-api requires a configuration file called "api-paste.ini"[0]. It seems that this file
is created in the deployment process in this section by puppet:
https://git.starlingx.io/cgit/stx-config/tree/puppet-modules-wrs/puppet-fm/src/fm/manifests/init.pp#n109
proposal: I noticed how devstack process deal with this, firstly the “api-paste.ini” file was added manually
inside devstack/files directory[1], then during the devstack execution process, the plugin just makes a
copy to the environment:
https://git.starlingx.io/cgit/stx-fault/tree/devstack/lib/stx-fault#n173
I wonder if it is the best approach to do something similar using the variable “CUSTOMIZATION” of loci with
something like this: “cat > /etc/fm/api-paste.ini << EOF config lines EOF” or maybe cloning the stx-fault repository
and copying the available file in the devstack directory[0] to “/etc/fm”.
Issue 2:
=======
The “fm rest api” requires a shared object called “libfmcommon.so”, this library is created in fm-common project,
however it is not available in any wheel package.
Proposal: I am not sure if something like this should be enough:
data_files=[('/usr/lib64', ['libfmcommon.so'])], inside the setup.py[2]
Furthermore I tried to add it from the specfile:
https://git.starlingx.io/cgit/stx-fault/tree/fm-common/centos/fm-common.spec#n54
however I think this is not a good option.
What do you think is the best approach to tackle these issues?
Any comments are welcome.
Best regards.
Mario.
[0] https://git.starlingx.io/cgit/stx-fault/tree/devstack/files/api-paste.ini
[1] https://git.starlingx.io/cgit/stx-fault/tree/devstack/files
[2] https://git.starlingx.io/cgit/stx-fault/tree/fm-common/sources/setup.py
________________________________________
From: Arevalo, Mario Alfredo C [mario.alfredo.c.arevalo at intel.com]
Sent: Friday, February 01, 2019 7:54 PM
To: Penney, Don; Miller, Frank
Cc: starlingx-discuss at lists.starlingx.io
Subject: Re: [Starlingx-discuss] [Containers] Background info on helm charts
Hi Folks,
This a short update about this task (I will be in holiday for our next containerization meeting).
During this week I have been exploring the scripts and tools involved in the containerization
building process. This activity and the wiki page shared by Don Penny have allowed me to
get a better understating of the work-flow. I have sent a PR[1] with the required files to create an
image for fm-rest-api service. At this moment it is WIP due to I need to do testing. Possibly
it will require more dependencies which are not available in the wheels.cfg/tarball, I will continue
working on this.
During the building tools exploration I had some issues related to network due to I am working
behind a proxy, I sent a patch[2] to set it in the docker build/run commands and avoid manually
modification efforts.
Any comments, feel free to contact me.
[1] https://review.openstack.org/#/c/634540/
[2] https://review.openstack.org/#/c/634542/
Best regards.
Mario.
________________________________________
From: Penney, Don [Don.Penney at windriver.com]
Sent: Wednesday, January 30, 2019 7:24 AM
To: Arevalo, Mario Alfredo C; Miller, Frank
Cc: Saul Wold; starlingx-discuss at lists.starlingx.io
Subject: RE: [Containers] Background info on helm charts
https://wiki.openstack.org/wiki/StarlingX/Containers/BuildingImages
-----Original Message-----
From: Penney, Don
Sent: Tuesday, January 29, 2019 10:34 AM
To: 'Arevalo, Mario Alfredo C'; Miller, Frank
Cc: Saul Wold; starlingx-discuss at lists.starlingx.io
Subject: RE: [Containers] Background info on helm charts
Hi Mario,
I'm making "writing a wiki" one of my top priorities. I'm hoping to get started on it today, and try to get something published in the next couple of days, barring other issues coming along.
Cheers,
Don.
-----Original Message-----
From: Arevalo, Mario Alfredo C [mailto:mario.alfredo.c.arevalo at intel.com]
Sent: Monday, January 28, 2019 4:15 PM
To: Miller, Frank
Cc: Saul Wold; starlingx-discuss at lists.starlingx.io; Penney, Don
Subject: RE: [Containers] Background info on helm charts
Hi Frank,
Thank you for the information, however my doubts are oriented more to the work-flow
than the Dockerfile/helm/chart/ tools. Even I created a dockerfile[1] for FM service in the
last week, nevertheless, the starlingx work-flow includes some parts which I have not digested
completely yet. Don Penny have helped me sending useful information related to this (Thanks for that),
the interaction between OpenStack/loci system and python/wheels. However I have some gaps,
for example, as staring point I have to create the docker image which will be consumed by the
chart. There are some build scripts and notes that talks about this, but precisely, there are a pair of lines
in the build-tools/README which makes reference to a exposed service that is not specified [2,3].
For that reason I asked for a little more detailed information about the work-flow during our meeting today.
Thanks for your attention.
Best regards.
Mario.
[1] https://github.com/MarioCarrilloA/chart-playground
[2] https://github.com/openstack/stx-root/blob/master/build-tools/build-docker-images/README#L4
[3] https://github.com/openstack/stx-root/blob/master/build-tools/build-docker-images/README#L9
From: Miller, Frank [Frank.Miller at windriver.com]
Sent: Monday, January 28, 2019 11:19 AM
To: Arevalo, Mario Alfredo C
Cc: Saul Wold; starlingx-discuss at lists.starlingx.io
Subject: [Containers] Background info on helm charts
Mario:
On the containers community call this morning we took an action to identify information about helm charts. Irina Mihai identified four references that she used when working on the cinder helm chart overrides. See [1] to [4] below.
Also as you work on creating a helm chart for the FM service, you should look at examples of existing helm charts for a reference. 2 good examples are:
*
Cinder helm chart which is available in the upstream openstack-helm project [5] and uses certain defaults. We have added StarlingX specific overrides which are generated from code we added [6].
*
Nova-api-proxy which is a StarlingX specific service and hence was created from scratch [7,8]
Frank
[1]
https://docs.helm.sh/developing_charts/
[2] https://medium.com/containerum/how-to-make-and-share-your-own-helm-package-50ae40f6c221
[3] https://docs.bitnami.com/kubernetes/how-to/create-your-first-helm-chart/
[4] Helm chart install order https://github.com/helm/helm/blob/release-2.10/pkg/tiller/kind_sorter.go#L29
[5] Cinder helm chart in upstream openstack-helm:
https://git.openstack.org/cgit/openstack/openstack-helm/tree/cinder
[6] StarlingX cinder overrides: See cinder.py in
https://github.com/openstack/stx-config/tree/master/sysinv/sysinv/sysinv/sysinv/helm
[7] Helm chart for nova_api_proxy:
https://git.openstack.org/cgit/openstack/stx-config/tree/kubernetes/applications/stx-openstack/stx-openstack-helm/stx-openstack-helm/nova-api-proxy
[8] nova_api_proxy override code: See nova_api_proxy.py
in
https://github.com/openstack/stx-config/tree/master/sysinv/sysinv/sysinv/sysinv/helm
_______________________________________________
Starlingx-discuss mailing list
Starlingx-discuss at lists.starlingx.io
http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
------------------------------
Message: 4
Date: Thu, 7 Feb 2019 20:37:59 +0000
From: "Bailey, Henry Albert (Al)" <Al.Bailey at windriver.com>
To: "Arevalo, Mario Alfredo C" <mario.alfredo.c.arevalo at intel.com>,
"Penney, Don" <Don.Penney at windriver.com>, "Wold, Saul"
<saul.wold at intel.com>, "Troyer, Dean" <dean.troyer at intel.com>
Cc: "starlingx-discuss at lists.starlingx.io"
<starlingx-discuss at lists.starlingx.io>
Subject: Re: [Starlingx-discuss] [Containers] Background info on helm
charts
Message-ID:
<A676AEEEEBCF9D498E699A04DE4E83189E19C53F at ALA-MBD.corp.ad.wrs.com>
Content-Type: text/plain; charset="us-ascii"
For issue 1)
Other openstack components write the paste like this
Here's the template for writing the api-paste.ini
https://github.com/openstack/openstack-helm/blob/master/heat/templates/configmap-etc.yaml#L139
Here's example data being written to it:
https://github.com/openstack/openstack-helm/blob/master/heat/values.yaml#L275
For issue 2)
You should be able to include the wheel for fm_core, which is defined here
https://github.com/openstack/stx-fault/blob/master/fm-common/sources/setup.py
it's in fm-common folder, but its called fm_core and it is included in the wheels tarball
http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/latest_docker_image_build/outputs/wheels/
fm_core-1.0-cp27-cp27mu-linux_x86_64.whl
The wheel contains C code, so it is an architecture specific wheel
Al
-----Original Message-----
From: Arevalo, Mario Alfredo C [mailto:mario.alfredo.c.arevalo at intel.com]
Sent: Thursday, February 07, 2019 3:13 PM
To: Penney, Don; Wold, Saul; Bailey, Henry Albert (Al); Troyer, Dean
Cc: starlingx-discuss at lists.starlingx.io
Subject: RE: [Containers] Background info on helm charts
Hi team,
There is a pair of issues which needs to be solved in order to create a "fm rest api" docker
image that can work correctly.
Issue 1:
=======
The fm-rest-api requires a configuration file called "api-paste.ini"[0]. It seems that this file
is created in the deployment process in this section by puppet:
https://git.starlingx.io/cgit/stx-config/tree/puppet-modules-wrs/puppet-fm/src/fm/manifests/init.pp#n109
proposal: I noticed how devstack process deal with this, firstly the "api-paste.ini" file was added manually
inside devstack/files directory[1], then during the devstack execution process, the plugin just makes a
copy to the environment:
https://git.starlingx.io/cgit/stx-fault/tree/devstack/lib/stx-fault#n173
I wonder if it is the best approach to do something similar using the variable "CUSTOMIZATION" of loci with
something like this: "cat > /etc/fm/api-paste.ini << EOF config lines EOF" or maybe cloning the stx-fault repository
and copying the available file in the devstack directory[0] to "/etc/fm".
Issue 2:
=======
The "fm rest api" requires a shared object called "libfmcommon.so", this library is created in fm-common project,
however it is not available in any wheel package.
Proposal: I am not sure if something like this should be enough:
data_files=[('/usr/lib64', ['libfmcommon.so'])], inside the setup.py[2]
Furthermore I tried to add it from the specfile:
https://git.starlingx.io/cgit/stx-fault/tree/fm-common/centos/fm-common.spec#n54
however I think this is not a good option.
What do you think is the best approach to tackle these issues?
Any comments are welcome.
Best regards.
Mario.
[0] https://git.starlingx.io/cgit/stx-fault/tree/devstack/files/api-paste.ini
[1] https://git.starlingx.io/cgit/stx-fault/tree/devstack/files
[2] https://git.starlingx.io/cgit/stx-fault/tree/fm-common/sources/setup.py
________________________________________
From: Arevalo, Mario Alfredo C [mario.alfredo.c.arevalo at intel.com]
Sent: Friday, February 01, 2019 7:54 PM
To: Penney, Don; Miller, Frank
Cc: starlingx-discuss at lists.starlingx.io
Subject: Re: [Starlingx-discuss] [Containers] Background info on helm charts
Hi Folks,
This a short update about this task (I will be in holiday for our next containerization meeting).
During this week I have been exploring the scripts and tools involved in the containerization
building process. This activity and the wiki page shared by Don Penny have allowed me to
get a better understating of the work-flow. I have sent a PR[1] with the required files to create an
image for fm-rest-api service. At this moment it is WIP due to I need to do testing. Possibly
it will require more dependencies which are not available in the wheels.cfg/tarball, I will continue
working on this.
During the building tools exploration I had some issues related to network due to I am working
behind a proxy, I sent a patch[2] to set it in the docker build/run commands and avoid manually
modification efforts.
Any comments, feel free to contact me.
[1] https://review.openstack.org/#/c/634540/
[2] https://review.openstack.org/#/c/634542/
Best regards.
Mario.
________________________________________
From: Penney, Don [Don.Penney at windriver.com]
Sent: Wednesday, January 30, 2019 7:24 AM
To: Arevalo, Mario Alfredo C; Miller, Frank
Cc: Saul Wold; starlingx-discuss at lists.starlingx.io
Subject: RE: [Containers] Background info on helm charts
https://wiki.openstack.org/wiki/StarlingX/Containers/BuildingImages
-----Original Message-----
From: Penney, Don
Sent: Tuesday, January 29, 2019 10:34 AM
To: 'Arevalo, Mario Alfredo C'; Miller, Frank
Cc: Saul Wold; starlingx-discuss at lists.starlingx.io
Subject: RE: [Containers] Background info on helm charts
Hi Mario,
I'm making "writing a wiki" one of my top priorities. I'm hoping to get started on it today, and try to get something published in the next couple of days, barring other issues coming along.
Cheers,
Don.
-----Original Message-----
From: Arevalo, Mario Alfredo C [mailto:mario.alfredo.c.arevalo at intel.com]
Sent: Monday, January 28, 2019 4:15 PM
To: Miller, Frank
Cc: Saul Wold; starlingx-discuss at lists.starlingx.io; Penney, Don
Subject: RE: [Containers] Background info on helm charts
Hi Frank,
Thank you for the information, however my doubts are oriented more to the work-flow
than the Dockerfile/helm/chart/ tools. Even I created a dockerfile[1] for FM service in the
last week, nevertheless, the starlingx work-flow includes some parts which I have not digested
completely yet. Don Penny have helped me sending useful information related to this (Thanks for that),
the interaction between OpenStack/loci system and python/wheels. However I have some gaps,
for example, as staring point I have to create the docker image which will be consumed by the
chart. There are some build scripts and notes that talks about this, but precisely, there are a pair of lines
in the build-tools/README which makes reference to a exposed service that is not specified [2,3].
For that reason I asked for a little more detailed information about the work-flow during our meeting today.
Thanks for your attention.
Best regards.
Mario.
[1] https://github.com/MarioCarrilloA/chart-playground
[2] https://github.com/openstack/stx-root/blob/master/build-tools/build-docker-images/README#L4
[3] https://github.com/openstack/stx-root/blob/master/build-tools/build-docker-images/README#L9
From: Miller, Frank [Frank.Miller at windriver.com]
Sent: Monday, January 28, 2019 11:19 AM
To: Arevalo, Mario Alfredo C
Cc: Saul Wold; starlingx-discuss at lists.starlingx.io
Subject: [Containers] Background info on helm charts
Mario:
On the containers community call this morning we took an action to identify information about helm charts. Irina Mihai identified four references that she used when working on the cinder helm chart overrides. See [1] to [4] below.
Also as you work on creating a helm chart for the FM service, you should look at examples of existing helm charts for a reference. 2 good examples are:
*
Cinder helm chart which is available in the upstream openstack-helm project [5] and uses certain defaults. We have added StarlingX specific overrides which are generated from code we added [6].
*
Nova-api-proxy which is a StarlingX specific service and hence was created from scratch [7,8]
Frank
[1]
https://docs.helm.sh/developing_charts/
[2] https://medium.com/containerum/how-to-make-and-share-your-own-helm-package-50ae40f6c221
[3] https://docs.bitnami.com/kubernetes/how-to/create-your-first-helm-chart/
[4] Helm chart install order https://github.com/helm/helm/blob/release-2.10/pkg/tiller/kind_sorter.go#L29
[5] Cinder helm chart in upstream openstack-helm:
https://git.openstack.org/cgit/openstack/openstack-helm/tree/cinder
[6] StarlingX cinder overrides: See cinder.py in
https://github.com/openstack/stx-config/tree/master/sysinv/sysinv/sysinv/sysinv/helm
[7] Helm chart for nova_api_proxy:
https://git.openstack.org/cgit/openstack/stx-config/tree/kubernetes/applications/stx-openstack/stx-openstack-helm/stx-openstack-helm/nova-api-proxy
[8] nova_api_proxy override code: See nova_api_proxy.py
in
https://github.com/openstack/stx-config/tree/master/sysinv/sysinv/sysinv/sysinv/helm
_______________________________________________
Starlingx-discuss mailing list
Starlingx-discuss at lists.starlingx.io
http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
------------------------------
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 9, Issue 34
************************************************
_______________________________________________
Starlingx-discuss mailing list
Starlingx-discuss at lists.starlingx.io
http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
More information about the Starlingx-discuss
mailing list