1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 <2024> | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 <2024> |
<== Date ==> | <== Thread ==> |
---|
Subject: | Generic EPICS IOCs |
From: | "Knap, Giles \(DLSLtd,RAL,LSCI\) via Tech-talk" <tech-talk at aps.anl.gov> |
To: | EPICS Tech Talk <tech-talk at aps.anl.gov> |
Date: | Mon, 15 Jan 2024 11:36:17 +0000 |
Good day All,
I would like to canvas opinion on the viability of the concept of Generic IOCs.
At DLS, we have been working on moving our IOCs to Kubernetes for a while. Part of our approach is to use the concept of Generic IOCs for our container images as follows:
For a more detailed description see
https://epics-containers.github.io/main/user/explanations/introduction.html#generic-iocs-and-instances.
So this means that we have a
generic version of epics base built into a container image and then one generic IOC container image based upon that for each device. In none of these are any site specific changes made, all the source we use is upstream and untouched (with one or two small
exceptions for compilers to work in our base OS).
The intention is that these Generic IOCs are viable for use in any facility that chooses
to use containers to deploy its IOCs (using any container runtime that is OCI compliant).
Is this a bad idea? are there site specific options that cannot be avoided, and cannot
be applied at runtime?
Any thoughts much appreciated.
Regards,
giles
-- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. |