I forgot to add one more info.. The PR for the working group has been already opened https://github.com/opencontainers/tob/pull/128. Going through the conversations and the document there will also help to get a better idea of the whole thing. Regards, Marcin czw., 21 wrz 2023 o 15:58 Marcin Franczyk <marcin0franczyk at gmail.com> napisał(a): > Hi, > > > Hmm; you're talking about changing the host OS depending on what gets > scheduled to it? That'd make everything kind of loopy =) Normally one > instead schedules workloads to compatible hosts, requiring the hosts to be > prepared out of band. > > No. I am not saying to reconfigure a node every time you have a different > container with a different set of requirements. > What I am saying is that we will be working on a data source that can be > used by different models to configure/provision worker nodes, and that > could be used on a running cluster. > It would be up to you to decide how and when you should feed Machine > Config operator with this. It doesn't even have to be automatic. > The data could be used to identify a specific group of applications with > similar compatibility requirements (like enablement of SR-IOV) to configure > a target group of nodes. > > > What's the expected time commitment from the working group? > > Join the meeting once a week and express your ideas/concerns. > How much time you would like to spend on tools implementation is up to you. > For now the most important thing is to collect feedback/opinions/ideas > from the various stakeholders. > > > Let me see if I can find others at Red Hat who may be interested in this > too. > > Thanks. > > Regards, > Marcin > > > > > czw., 21 wrz 2023 o 14:52 Colin Walters <walters at verbum.org> napisał(a): > >> Hi, >> >> On Tue, Sep 5, 2023, at 9:26 AM, Marcin Franczyk wrote: >> > Hello, >> > >> > I am writing to ask if at Red Hat you would be interested to >> > collaborate on container image standard improvements under Open >> > Container Initiative (https://opencontainers.org/). >> > >> > At Huawei we identified that container image specification lacks >> > compatibility requirements. >> > For instance if you run a container that requires an NVIDIA GPU then >> > you have to make sure that CUDA library in the container matches the >> > CUDA driver on the host. The required version of the driver could be >> > expressed in the container image. There are plenty of similar use cases >> > when it comes to kernel configuration, boot args, modules or >> > out-of-tree drivers. >> > >> > More details could be found here: >> > >> https://docs.google.com/document/d/1lzwh8DGMu5vXXHwJmnewYIMffkcOEvH8owX4UYjRcw0/edit?usp=sharing >> >> I added a comment in >> https://docs.google.com/document/d/1lzwh8DGMu5vXXHwJmnewYIMffkcOEvH8owX4UYjRcw0/edit?disco=AAAA5kwp_40 >> > >> > I think OpenShift and its Machine Config operator could benefit from >> > this by influencing worker node configuration based on the image >> > specification, which would mean that customers would also benefit. >> >> Hmm; you're talking about changing the host OS depending on what gets >> scheduled to it? That'd make everything kind of loopy =) Normally one >> instead schedules workloads to compatible hosts, requiring the hosts to be >> prepared out of band. >> >> > I am forming a working group under OCI and believe this initiative >> > should not come only from one company since that will be a global >> > standard. >> >> Right. >> >> > >> > I prepared a template for a working group that will be voted on by the >> > Technical Oversight Board (https://github.com/opencontainers/tob). >> > >> https://docs.google.com/document/d/1WZbr7xEpUohvyIiSvJEgCCxhAVMM9DmgXBsk1q1MtVU/edit?usp=sharing >> > >> > The voting will take place once I create a PR. >> > I think, after the working group is approved, we would need 2-3 months >> > to come up with the first standard and a client tool to build and >> > validate the specification. >> >> What's the expected time commitment from the working group? >> >> Let me see if I can find others at Red Hat who may be interested in this >> too. >> _______________________________________________ >> CentOS-devel mailing list >> CentOS-devel at centos.org >> https://lists.centos.org/mailman/listinfo/centos-devel >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20230921/2100be46/attachment.html>