[Starlingx-discuss] openSUSE: High Availability Installation Update
Hi, Please find a preliminary update [0] of our journey to install the created "high availability" packages from our openSUSE StarlingX project space [1]. These procedure will be repeated once the packages are generated using the non-yet merged StarlingX HA Upstream Specfiles [2]. In summary: The following packages were successfully installed, no missing zypper or python dependencies: - sm-common - libsm-db1 - sm The following packages were successfully installed after additional zypper and/or python packages were installed, work in progress to add them into their respective specfile: - sm-tools - sm-client - sm-api You will find in the guide: 1. The openSUSE based Vagrant image 2. The installation of the packages and package binaries execution 3. Output for both installation and package binaries execution [0] https://github.com/xe1gyq/starlingx/blob/master/multios/opensuse_ha_install.... [1] https://build.opensuse.org/project/show/Cloud:StarlingX:2.0 [2] https://review.opendev.org/#/c/679686/
Hello, I have looked at your documentation provided as pointers and I would like to make a few comments : 1) you are mixing repo. The Vagrant image is made on OpenSUSE 15.0 but I notice that you pull some packages from "openSUSE-Tumbleweed-Oss". Mixing repo from different release is a ticket for problem. I guess it's an error. Rather than to ignore key, it's better to import them once for all. 2) dependencies The easier way to manage complex software installation, is to create a meta package in OBS. It's a package that only has "Required:" statement an calls for needed packages. If the called packages are in spread out in directories which are not commonly referenced by default, it can be 'User Friendly' to create aggregate version of the target packages in the same directory than the meta package, to ease the end use life. 3) pip Using pip to upload python module is not the preferred method, as those modules will not be updated when the distro is updated and their release is unknown as it depends of the installation timing. The packages that you are calling are available from OpenSUSE repo in Python2 and 3, so a call from the meta package could be done automatically. S | Name | Summary | Type ---+----------------+-----------------------------------------+-------- i+ | psutils | Tools for Manipulating PostScript Files | package | python2-psutil | A process utilities module for Python | package | python3-psutil | A process utilities module for Python | package Would a package not be available, it would be better to create a virtual package which does the install as part of a simple %post and call it from the meta package. Which such model, to enforce the update, we would just have to increase the version number. 4) DB and various Config file initialisation Rather than to do them by hand, it would be better to trigger them in a %post statement of the meta package. Which such solution, the could be fully automated via a "1 click Install" (works only from Firefox). A special test might be required to not break changes during update. Have a nice day Dominig On 25/09/2019 17:48, Arce Moreno, Abraham wrote:
Hi,
Please find a preliminary update [0] of our journey to install the created "high availability" packages from our openSUSE StarlingX project space [1]. These procedure will be repeated once the packages are generated using the non-yet merged StarlingX HA Upstream Specfiles [2]. In summary:
The following packages were successfully installed, no missing zypper or python dependencies: - sm-commonS | Name | Summary | Type ---+----------------+-----------------------------------------+-------- i+ | psutils | Tools for Manipulating PostScript Files | package | python2-psutil | A process utilities module for Python | package | python3-psutil | A process utilities module for Python | package - libsm-db1 - sm
The following packages were successfully installed after additional zypper and/or python packages were installed, work in progress to add them into their respective specfile: - sm-tools - sm-client - sm-api
You will find in the guide:
1. The openSUSE based Vagrant image 2. The installation of the packages and package binaries execution 3. Output for both installation and package binaries execution
[0] https://github.com/xe1gyq/starlingx/blob/master/multios/opensuse_ha_install.... [1] https://build.opensuse.org/project/show/Cloud:StarlingX:2.0 [2] https://review.opendev.org/#/c/679686/
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
-- Dominig ar Foll Senior Software Architect Intel Open Source Technology Centre
Thanks Dominig for sharing your comments,
I have looked at your documentation provided as pointers and I would like to make a few comments :
1) you are mixing repo. The Vagrant image is made on OpenSUSE 15.0 but I notice that you pull some packages from "openSUSE-Tumbleweed-Oss". Mixing repo from different release is a ticket for problem. I guess it's an error. Rather than to ignore key, it's better to import them once for all.
Agree, my typos. I initially launched a Tumbleweed based Vagrant image and did not remove the content. The steps were finally installed in one Leap 15.0 based. My Documentation needs to be updated.
2) dependencies The easier way to manage complex software installation, is to create a meta package in OBS. It's a package that only has "Required:" statement an calls for needed packages. If the called packages are in spread out in directories which are not commonly referenced by default, it can be 'User Friendly' to create aggregate version of the target packages in the same directory than the meta package, to ease the end use life.
When do you decide this require dependencies should be in the Specfile or in that meta package? In case the meta package is the right option, should we create one per component (ha)? per package (sm-tools)? Can you please point me into the specific documentation to learn about this concept, not a clear result from google. Also a OBS example of some other project? :)
3) pip Using pip to upload python module is not the preferred method, as those modules will not be updated when the distro is updated and their release is unknown as it depends of the installation timing.
Understood, this was an temporal step to be able to use the package binaries (e.g. sm-dump)
The packages that you are calling are available from OpenSUSE repo in Python2 and 3, so a call from the meta package could be done automatically.
S | Name | Summary | Type ---+----------------+-----------------------------------------+-------- i+ | psutils | Tools for Manipulating PostScript Files | package | python2-psutil | A process utilities module for Python | package | python3-psutil | A process utilities module for Python | package
Would a package not be available, it would be better to create a virtual package which does the install as part of a simple %post and call it from the meta package. Which such model, to enforce the update, we would just have to increase the version number.
Work in progress to learn about this meta package concept...
4) DB and various Config file initialisation Rather than to do them by hand, it would be better to trigger them in a %post statement of the meta package.
Agree, same as with pip package dependencies, only a temporal step to be able to finally use package binaries (e.g. sm-tools) I will work in a change proposal.
Which such solution, the could be fully automated via a "1 click Install" (works only from Firefox).
A special test might be required to not break changes during update.
Have a nice day
You too! I am taking vacations for the following 3 days so please bear with me if I do not reply back soon.
Thanks Dominig for sharing your comments, Agree, my typos. I initially launched a Tumbleweed based Vagrant image and did not remove the content.
The steps were finally installed in one Leap 15.0 based. My Documentation needs to be updated. Good. A non issue then.
When do you decide this require dependencies should be in the Specfile or in that meta package? I personally tend to put all the runtime dependency in the Meta package, so all the packages which are called by it have the same set. If you plan to allow individual package installation, then it should be within the package. In case the meta package is the right option, should we create one per component (ha)? per package (sm-tools)? The optimum strategy, is to create 1 meta package for each subsystem
On 25/09/2019 19:23, Arce Moreno, Abraham wrote: that can be installed and run independently. Then we can create a meta package which calls for the sub meta packages.
Can you please point me into the specific documentation to learn about this concept, not a clear result from google. Also a OBS example of some other project? :) Not very well documented feature but you can look at my personal project. https://build.opensuse.org/package/show/Application:Geo:OpenCPN/OpenCPN-5.x I have a meta package that call for the entire installation. You can even force for given version of packages to stop people to break tested configurations. As it's a full package, you can also provide %pre and %post section as desired. You too! I am taking vacations for the following 3 days so please bear with me if I do not reply back soon. Understood.
-- Dominig ar Foll Senior Software Architect Intel Open Source Technology Centre
Dominig,
The steps were finally installed in one Leap 15.0 based. My Documentation needs to be updated. Good. A non issue then.
I have moved to openSUSE 15.1
Not very well documented feature but you can look at my personal project. https://build.opensuse.org/package/show/Application:Geo:OpenCPN/OpenCPN-5.x
Since the missing runtime dependencies were not that many and not common across the different components, I decided to include directly into the specfiles and not use meta package.
participants (2)
-
Arce Moreno, Abraham
-
Dominig ar Foll (Intel Open Source)