On 02/24/2017 11:27 AM, Micah Abbott wrote: > On 02/23/2017 11:32 PM, Dusty Mabe wrote: >> >> Spent the day chatting with a bunch of Fedora Atomic users today. >> >> Some pain points that came out of todays discussions: >> >> - kubernetes versions >> * sometimes we have lagged behind upstream in Fedora and this has >> caused some pain. They are on board with containerized >> kubernetes as a solution to this problem. >> >> - installing small operating system agents > > Isn't this one of the use cases for system containers? > Yes it is. The problem is that you can get a 250+ MiB container just to deliver a couple hundred KiB of python and a systemd unit. What I propose in bullet point 4 below could still be a system container, it just squats on the hosts software. Whether or not this is "good practice" or not is up for debate. >> * have some small agents that need to run as a daemon on the host >> some solutions: >> ^ build own ostree - more maintenance >> ^ package layer - requires reboot >> ^ run in container - large containers for small agents >> ^ run as container that acutally bind mounts in host directories >> ` very small container with just the agent >> ` when container runs it bind mounts in software from the >> host. i.e. using the hosts python stack. I don't know if >> this will work but just thought of it as we were talking >> today. >> ` i'm sure this may be a bad idea on several levels. >> >> - pre-loading containers on system startup >> * there is a need for being able to load containers on system >> startup into the container runtime. I think jlebon already >> worked on something like this maybe. Either way the idea is that >> we have a service that looks in a certain directory in the >> filesystem for container images and loads them into the runtime >> on startup and then deletes those images (or not depending on >> configuration). One could start a cloud image and mount a volume >> that these images are already loaded into. One could crack open >> the qcow and cp the files in, etc. Doesn't matter how they get >> to the "pre-defined" location, we'll import them. >> >> Dusty >> _______________________________________________ >> cloud mailing list -- cloud@xxxxxxxxxxxxxxxxxxxxxxx >> To unsubscribe send an email to cloud-leave@xxxxxxxxxxxxxxxxxxxxxxx >> > _______________________________________________ > cloud mailing list -- cloud@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to cloud-leave@xxxxxxxxxxxxxxxxxxxxxxx > _______________________________________________ cloud mailing list -- cloud@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to cloud-leave@xxxxxxxxxxxxxxxxxxxxxxx
