#solum

and docker only works with devstack

?

you can use devstack with no docker, and only use VMs

I need to try out solum in test openstack instance

with Solum.

I have a compute node

If I install docker on that, will solum work as such?

you don't need Docker on the compute node if you don't want it

If I have to save time

since nova does not support docker yet, will this work without devstack?

ok, so in the case where you want to built with docker and deploy using a VM, for that we need additional functionality added. That's a "custom" workflow.

you would do a VM image build during your build process (and optionally a docker build as well)

then when you deploy, you use a Heat template that calls for the VM image rather than the container image.

nova can work with docker if you use the nova-docker driver

our demo environment is set up that way

so when Heat creates an OS::Nova::Server instance, you get a docker container instead of a VM

What do you think? Is it better to move towards docker?

The question is not with respect to solum

yes, I think so. In the case where people want to use VM's for production, we can allow that by using the docker container image within that new VM

In general

oh, well my answer would depend on the intended use case. Particularly the multi-tenancy situation.

in general, I think that short-lived processes should be containerized.

… and how much work an operator would put into a Mandatory Access Control lockdown.

The problem with our gate is we use v3.2 kernel, but docker seems not like it. And I know nova-docker team is using F20 for their gate.

paulmo: yes

long lived processes where multiple workloads share the same server hardware is a better fit for VM's at this point.

until there is sufficient hardening of the host operating systems using a variety of kernel security techniques.

at some point, the practical different in security between VM's and containers will be very close.

and it's at that point where I would begin to endorse general purpose workloads to use containers instead of VM's

are containers less secure today?

noorul: does that point of view make sense?

noorul: the containers themselves are really not the concern

it's the security of the host that runs the containers

It is a security (and the operator work to isolate containers) vs resource efficiency/performance tradeoff.

ok

yes, paulmo. If the operator does a really good job of securing the compute hosts, then they can bring the security level of containers very close to what they enjoy from VM's and be able to pack more workloads onto the same amount of equipment.

It is easier to "escape" a container than it is to escape a VM generally speaking.

if the operator does nothing to secure the compute hosts, then containers will be a disaster from a security perspective

if you mix workloads from neighboring tenants on the same compute nodes.

noorul: The key difference is that containers share a kernel with other containers

with a type-2 hypervisor, each guest has its own kernel

Got it

and the facilities to communicate with the host htrough the hypervisor are very limited and narrow

whereas a container (depending on how the host is set up) may be allowed to have unrestricted access to the kernel

and that's a potential security risk

Got iy

thank you for clarifying

because if you escape into kernel, you can reach into other guests

so all of my qualifying statements are about how the operator sets up what access a host gives to its containers to interact with it

to control and narrow that risk, much like a type-2 hypervisor does

noorul: This is a great writeup by Docker (although I think they paint a bit too good of a picture of container security right now): http://blog.docker.io/2013/08/containers-docker...

but there will never be 100% security parity between a hypervisor and a host running containers

paulmo: Thanks you!

because no matter how much you limit it, the kernel is still a shared resource.

I will also mention that the hypervisor itself is potentially vulnerable in the same way

so even using neighboring VM's on the same host carries some level of risk.

Hypervisor breakouts: http://www.insinuator.net/2013/05/analysis-of-h...

paulmo: I have not studies all of the breakouts, but my understanding is that most of them are DoS attacks by nature

at least the ones that impact XEN

the CVE-2012-0217 looks delicious!

There are several avenues besides DOS (was away from desk for a minute). USB3 DMA was a big issue for a while (might still be) for example.

… and even just plain old coding mistakes enabling exploits.

paulmo: Is someone working on the logging part that you were talking about in the pipeline google-doc?

Well, I'm working on it at the very moment but in a more OpenStack-wide manner...

paulmo: Oh I see

I'm working with the OpenStack Security Group to attempt to put a practice in place to identify confidential data up front (like we are in Solum) and make some standards.

… but you are referring to aggregating and reporting real time logs to users right? No, I don't know of anyone tackling that.

Yes

The question I would have is: Is that an operator problem to solve or a Solum problem to solve?

Isn't reporting important for solum pipleline?

Yes, I very much think so. I'm just not sure where the greater community's mindset is on this topic. Probably a good topic for our next IRC meeting

Hmm

step one is to make flexible workflows

then to add an even stream from them

by workflows do you mean pipleline?

yes

once we have an event stream, expose that to the user

and then expand on that so that various solum components feed their status changes into that stream, including (especially) errors

paulmo: is that how you see it?

At a high level… lots of devil's in the details there. :)

of course

One more thing I just thought of asking. When does solum comes into picture for a developer? When I listed down the user case,I thought a developer will be doing development in a laptop and he only needs solum when he needs a pipeline for gatig

s/user case/use case

noorul: that depends

it's possible to do all your dev/test on a laptop, and generate a container (or VM) image there

and then feed that into Solum when you are ready to deploy.

or, you can have solum do all the build/test and image building remotely.

that's the use case that we expect will be more common

so developers can just commit code to the repo, and the rest happens behind the scenes

what do you mean by image building in this case?

generation of a container image, and uploading that to glance

or generation of a VM image, and uploading that to glance

so this is only for container

you could do either.

This what we were discussing

strictly speaking Solum does not care about the type of image you create

Is solum going to generate a vm image?

because the template just passes the id of the DU image into the heat template, and Heat asks nova for an instance of OS::Nova::Server using that image

so if it's a container image, and you are using nova-docker, then you can get a docker container as the OS::Nova::Server instance

and if not, then you can get a VM

solum *can* generate VM images, yes

we have code for that under contrib/lp-cedarish/vm and contrib/lp-cedarish/vm-slug

ok,

For my use case I think I will not be using that

we need to make use of language packs somehow

you want to build your own images, or you want Solum to build them?

Great, the OSSG is generally very happy with the ideology being proposed for isolating logs (the weekly IRC meeting is happening now).

!! great paulmo !!

I do not want heroku language packs

ok

sorry I have to start packing up to head to an appointment outside the office.

in that case I think I should build my own image

and create a language pack

noorul: that makes sense based on my understanding of how you work today

and I think we need code to use this language pack

as of now we are not using language_packs resource

noorul: I think we do need a new bit of code to allow you to specify your own image to use for a build, yes

right, we have more to do there.

ok,

time to get some sleep

g'night!

nice talkito you paulmo adrian_otto

Same noorul as always :)