There appear to be two sets of images we're concerned with: Reference images (RI), and those images that will be built and deployed by operators in the real world.
I believe our intent is to define a build chain and rules or guidelines that all projects use to build their reference images. As a general model (hopefully not too simplistic), an RI is composed of the following 'logical' layers (not Docker layers): 1. architecture 2. OS 3. libraries (e.g Java, Python, etc) 4. application Layers 1-3 can be 'standardized' for all ONAP projects. A few observations/questions: * we want to support multi-arch images so all RI images are in practice Manifest lists (or equivalent in OCI) - right? * do we standardize on one OS for the purposes of testing within ONAP? (I believe this is what Tal has suggested) * The RI image repo should have images that contain static content for many application environments (layer 3 above), which ameliorates the concerns Micheal identified just above, shortens start-up times, and provides a more uniform baseline for applications - correct? * Once we agree on concrete items on this thread, we should memorialize them on a wiki page. Now for 'real world' images - presumably built from scratch by each operator. These images might not share layers 1-3, but will share layer 4, the ONAP component applications. What can we do to facilitate this build/test/deploy process to make life easier, safer, and less error prone for operators? - Frank -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11931): https://lists.onap.org/g/onap-discuss/message/11931 Mute This Topic: https://lists.onap.org/mt/24242182/21656 Group Owner: [email protected] Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
