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 -- [email protected]
>> To unsubscribe send an email to [email protected]
>>
> _______________________________________________
> cloud mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> 
_______________________________________________
cloud mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to