Wednesday, 2022-04-27

kata-irc-bot<meng.mobile> We need to separate different users and look from different perspective here. For a cluster admin, yes. Kata-deploy is good to go, since it setup everything. For normal cluster user, it is not that feasible. he/she might have not access to host, not allow to call systemd service to  restart on host.  But we still make sense allow he/her run workload with special resource, GPU,  for example.05:18
kata-irc-bot<meng.mobile> If my suggestion is taken. Admin can use kata-deploy to setup cluster for once and only once. Other user get the freedom to run their workload as needed, no need to bother admin.05:20
kata-irc-bot<meng.mobile> @fidencio have a valid point though. Admin might not want to allow any kernel run in the cluster, since kernel might be tainted.  I don't know how much risk is there. Kernel will be run in hypervisor, not in host directly. Not sure if a tainted kernel could harm the host in anyway. This is totally out of my knowledge because I know little in this area.05:24
kata-irc-bot<meng.mobile> I also if possible to rip off the agent from guest rootfs, have it mounted from host into guestfs at runtime.05:25
kata-irc-bot<meng.mobile> This will continue on my road even further.05:26
kata-irc-bot<meng.mobile> Make guestos even more flexible, no need update even runtime want a new version of agent to work05:26
kata-irc-bot<meng.mobile> I am going crazy, I guest. ,:)05:27
kata-irc-bot<eric.ernst> hehe.  I think some of the flexibility can add concern too, from attack perspective, especially depending on the host configuration (ie, hack guest kernel to probe into host).14:48

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!