Re: Meeting with Openstack magnum team today

2017-02-24 Thread Dusty Mabe


On 02/24/2017 12:22 PM, Jonathan Lebon wrote:
>> - 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.
> 
> Yup, that's:
> https://github.com/jlebon/atomic-preload

cool. seems like we got most of the way there but never integrated it
into atomic host? Is it in any shipped version of atomic host that we
produce? 

> 
> You can also configure the containers to be started once
> they're loaded.

sweet, even better

> 
> It's a rough design, but it does work. The workflow there
> was more centered around injecting from a kickstart, though
> yeah, it should work with any other injection method.

Yeah. I think the goal is to use a baked image that someone
else gives you but be able to either boot the instance and
mount a volume at /var/lib/atomic/preload/ before the service
runs or maybe we provide a small script that will crack open an
atomic qcow2 and store a few tar files into /var/lib/atomic/preload.

> 
> Though the type of containers you'd want to preload (e.g
> daemons, network/cloud agents) would be better fit for
> system containers, which last I tried works if you just
> install as usual in the %post.
> 
> You'd still need something like atomic-preload though for
> regular docker containers. There might be a use case for
> system containers as well if dynamic configuration is needed
> via e.g. cloud-init.
___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org


Re: Meeting with Openstack magnum team today

2017-02-24 Thread Micah Abbott

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?


* 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@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org


___
cloud mailing list -- cloud@lists.fedoraproject.org
To unsubscribe send an email to cloud-le...@lists.fedoraproject.org