|
|
|
|
|
|
|
|
|
|
|
|
# ELT Platform Lifecycle
|
|
# ELT Platform Lifecycle
|
|
|
|
|
|
|
|
## Release schedule
|
|
## Initial discussion minutes
|
|
|
|
|
|
|
|
* Platform 24
|
|
```
|
|
|
* Platform 25
|
|
Dear All,
|
|
|
|
|
Thank you for participating to the meeting! If you weren't able to participate, we recorded the meeting and this is available in the Teams group of the meeting.
|
|
|
## Phases and Update Policy
|
|
|
|
|
|
|
I wanted to put a short recap, call them minutes if you want, here for everyone:
|
|
|
* Unstable
|
|
|
|
|
* Stabilizing
|
|
- With DevEnv 5 we moved, using the OBS packaging tool, to a rolling release philosophy: this gives the possibility to push new updates very fast and reduce overhead in releases management. Pushed updates of course are first validated using unit tests at RPM packaging and using Jenkins CI pipelines on top of RPMs. Only when these validation steps are successful will new packages be pushed to the updates stream.
|
|
|
* Stable
|
|
|
|
|
|
|
- All software, so not just DevEnv and ECOS but all projects, are part of this and can therefore profit from the fast delivery cycle when desired.
|
|
|
## Stakeholders
|
|
|
|
|
|
|
- It is always programmed that two versions are maintained in parallel: the current development one and the previously released one. To external Consortia realistically only the release should be delivered, so they work on a stable and not moving target. They will be able of course to receive patches should there be needed.
|
|
|
* Andrés Ramírez - M1 LSV, M2 LSV
|
|
|
|
|
* Bogdan Jeram - RTCTK
|
|
- The fast delivery of course can potentially pose for some an unwanted situation where software is changing under their feet while working on their focused project. It is clear that projects do not immediately need to acquire the latest updates but can delay this depending on their needs, at an extreme staying on the initial release. It is anyhow highly recommended to update regularly to profit from all the fixes and patches as they come in the other projects that may be in use and give their feedback for bugs. As explained as well, all the Jenkins test pipelines are executed only on the head of the stable release.
|
|
|
* Carlos Diaz Cano - MELT
|
|
|
|
|
* Federico Pellegrin - ELTDEV
|
|
- It is defined that there are a few phases in the timeline of the various projects: unstable, stabilizing and stable. During unstable phase projects can introduce breaking changes and new features. In the stabilizing phase they can still introduce breaking changes if this is needed, for example, due to fixing problems, but they are not originally planned and new features are still being introduced. During the stable phase only bugs will be fixed, albeit also bugfixes will be agreed together as they may incidentally cause other unplanned consequences, and no new features or breaking changes are permitted. Of course in special cases, with the agreement of everyone, these rules could have exceptions.
|
|
|
* Gianluca Chiozzi - HLCC
|
|
|
|
|
* Javier Argomedo - MS LSV
|
|
- A Wiki page will be created where projects can present and keep up-to-date expected dates for the various stages. This can then be used by downstream projects to better program their activities. This timeline will naturally have as a base the CCS Development Plan (ESO-562141) document. For each project one/a few responsible will be indicated to act as main contact points for approving package releases. The link for the page, which at the moment is of course very limited and will be under heavy construction in the next weeks, has been prepared and is the following: https://gitlab.eso.org/ecos/eltsw-docs/-/wikis/ELT-Platform
|
|
|
* Luigi Andolfato - M1
|
|
|
|
|
* Marcos Suárez Valles - WFRTC
|
|
- Via the DevEnv mailing list announcements will be made when any new packages are pushed into the stable stream so everyone can be immediately aware of new packages available and decide what is best for them from the upgrade point of view.
|
|
|
* Marcus Schilling - CII
|
|
|
|
|
* Mario Kiekebusch - IFW
|
|
- For exceptions and bug fixes discussions, it is agreed that the best and already existing CCS & Co. biweekly meeting can be used. Should a discussion be more urgent, a dedicated meeting will be organized by the project wanting to introduce changes to discuss with others.
|
|
|
* Nick Kornweibel - ECM
|
|
|
|
|
* Nicolas Benes - ECOS
|
|
- It is clarified also that the INTROOT usage is not anyhow affected by the packaging: users, especially while doing development and fast iterations, can continue to use their INTROOT facilities as in the past to combine and customize projects and subprojects as they please. But of course it is not recommended to use INTROOTs in the long term, as that implies maintaining and rebuilding packages by hand (and one should build all downstream packages to be on the safe side) which can be error prone and is for sure very time consuming.
|
|
|
* Robert Frahm - TREx
|
|
|
|
|
|
|
- For the specific issue of kernel versions, mostly affecting performance-tight systems such as M1LCS and WFRTC, it is clarified that for DevEnv5 there will be no further upgrades to the current 6.8.9. For the future, it is agreed to see in detail the topic when we begin with DevEnv6 with some proposals already on the table such as usage of a LTS kernel, pinning of kernel version via DNF configuration facilities on those systems or other TBD strategy.
|
|
|
|
|
|
|
|
## FAQ
|
|
- For compatibility of communications between systems (ie. communication between machines based on different releases) the topic is fully understood and agreed. But this topic is fully in the hands of CII and interface developers and should therefore be enforced and tested there. As DevEnv we can just suggest, and possibly help support infrastructure, to create and maintain test suites that constantly test for backward compatibility of all the common services.
|
|
|
|
|
|
|
|
* Pinning the kernel version
|
|
|
|
|
* Reverting dnf transactions
|
|
For any doubts please let us know and in case, if needed and time allows, we can also spend some time at tomorrow's CCS&co meeting!
|
|
|
|
|
|
|
|
|
|
|
|
Cheers,
|
|
|
|
Federico
|
|
|
|
```
|
|
|
|
|
|
|
|
## Release schedule
|
|
|
|
|
|
|
|
* Platform 24
|
|
|
|
* Platform 25
|
|
|
|
|
|
|
|
## Phases and Update Policy
|
|
|
|
|
|
|
|
* Unstable
|
|
|
|
* Stabilizing
|
|
|
|
* Stable
|
|
|
|
|
|
|
|
## Stakeholders
|
|
|
|
|
|
|
|
* Andrés Ramírez - M1 LSV, M2 LSV
|
|
|
|
* Bogdan Jeram - RTCTK
|
|
|
|
* Carlos Diaz Cano - MELT
|
|
|
|
* Federico Pellegrin - ELTDEV
|
|
|
|
* Gianluca Chiozzi - HLCC
|
|
|
|
* Javier Argomedo - MS LSV
|
|
|
|
* Luigi Andolfato - M1
|
|
|
|
* Marcos Suárez Valles - WFRTC
|
|
|
|
* Marcus Schilling - CII
|
|
|
|
* Mario Kiekebusch - IFW
|
|
|
|
* Nick Kornweibel - ECM
|
|
|
|
* Nicolas Benes - ECOS
|
|
|
|
* Robert Frahm - TREx
|
|
|
|
|
|
|
|
|
|
|
|
## FAQ
|
|
|
|
|
|
|
|
* Pinning the kernel version
|
|
|
|
* Reverting dnf transactions
|
|
|
* Installing a specific snapshot |
|
* Installing a specific snapshot |
|
|
|
\ No newline at end of file |
