Re: [openstack-dev] [Heat] [Docker] Resource
>This would effectively make Docker another case of "syntactic sugar", >much like OS::SoftwareConfig::Chef would be. >Short term I think this will get Docker onto Heat users' instances >quicker. Agreed. >However I do think that the limitations of this approach are pretty >large, such as how to model the network in such a way where we could >attach a floating IP to a container running in a VM. There's a lot of >extra plumbing that gets shrugged off to user-managed hosts that seems >like a generic nesting interface that would be useful for things like >TripleO too where we want to nest a VM inside the deployment cloud. I do not think limiting the Docker api to listening to a unix socket on a compute instance would stop one from being able to attach a floating ip to a container running in a VM. One would have to start the docker container mapped to a port on the host vm that was not firewalled. Docker already has support for mapping host to container ports, so the software config agent would have to just pass those options along. -Andrew On 5/20/14 4:16 PM, "andrew plunk" wrote: >Excerpts from Andrew Plunk's message of 2014-05-20 13:49:58 -0700: >> No Problem. >> >> As the Docker resource in Heat currently works, it will require Docker >>running on a customer's vm to listen over a network socket. With >>software config you could allow Docker to listen on the instance's local >>unix socket, and communicate with Docker via Heat's in instance software >>config agents. >> > >This would effectively make Docker another case of "syntactic sugar", >much like OS::SoftwareConfig::Chef would be. > >Short term I think this will get Docker onto Heat users' instances >quicker. > >However I do think that the limitations of this approach are pretty >large, such as how to model the network in such a way where we could >attach a floating IP to a container running in a VM. There's a lot of >extra plumbing that gets shrugged off to user-managed hosts that seems >like a generic nesting interface that would be useful for things like >TripleO too where we want to nest a VM inside the deployment cloud. > >Anyway, the local socket is the way to go. The less we teach Heat's >engine to reach out to non-OpenStack API's, the more we can keep it >isolated from hostile entities. > >___ >OpenStack-dev mailing list >OpenStack-dev@lists.openstack.org >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] [Docker] Resource
No Problem. As the Docker resource in Heat currently works, it will require Docker running on a customer's vm to listen over a network socket. With software config you could allow Docker to listen on the instance's local unix socket, and communicate with Docker via Heat's in instance software config agents. -Andrew Plunk From: Eric Windisch mailto:ewindi...@docker.com>> Date: Tuesday, May 20, 2014 3:45 PM To: andrew plunk mailto:andrew.pl...@rackspace.com>> Cc: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>>, "alex.gay...@gmail.com<mailto:alex.gay...@gmail.com>" mailto:alex.gay...@gmail.com>> Subject: Re: [Heat] [Docker] Resource The solution I propose to this problem is to integrate docker with software config, which would allow the Docker api running on a compute instance to listen on an unix socket First, thank you for looking at this. Docker already listens on a unix socket. I'm not as familiar with Heat's 'software config' as I should be, although I attended a couple sessions on it last week. I'm not sure how this solves the problem? Is the plan to have the software-config-agent communicate over the network to/from Heat, and to the instance's local unix socket? -- Regards, Eric Windisch ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Heat] [Docker] Resource
Hello All, The purpose of this email is to document a few discussions from the summit, and to facilitate communication between parties at Docker and the Heat community. The way the Docker resource is currently implemented requires the remote Docker api to be enabled on the compute instances that Heat wants to create containers on. The way Docker suggests securing the remote api is by using tls client certificates signed by a trusted CA used to start up the docker api (http://docs.docker.io/examples/https/). This presents a problem for Heat because certificates would have to be added to Heat for each Docker resource (or per stack) in order to have secure communication, which creates a scalability problem, and requires Heat to store customer secrets. The solution I propose to this problem is to integrate docker with software config, which would allow the Docker api running on a compute instance to listen on an unix socket while still being able to communicate with the Heat engine. I have created a blueprint to capture this proposal: https://blueprints.launchpad.net/heat/+spec/software-config-docker Any input on this proposal is welcome. Thanks everyone! -Andrew Plunk ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [heat] [glance] Heater Proposal
>Excerpts from Randall Burt's message of 2013-12-05 09:05:44 -0800: >> On Dec 5, 2013, at 10:10 AM, Clint Byrum >> wrote: >> >> > Excerpts from Monty Taylor's message of 2013-12-04 17:54:45 -0800: >> >> Why not just use glance? >> >> >> > >> > I've asked that question a few times, and I think I can collate the >> > responses I've received below. I think enhancing glance to do these >> > things is on the table: >> > >> > 1. Glance is for big blobs of data not tiny templates. >> > 2. Versioning of a single resource is desired. >> > 3. Tagging/classifying/listing/sorting >> > 4. Glance is designed to expose the uploaded blobs to nova, not users >> > >> > My responses: >> > >> > 1: Irrelevant. Smaller things will fit in it just fine. >> >> Fitting is one thing, optimizations around particular assumptions about the >> size of data and the frequency of reads/writes might be an issue, but I >> admit to ignorance about those details in Glance. >> > >Optimizations can be improved for various use cases. The design, however, >has no assumptions that I know about that would invalidate storing blobs >of yaml/json vs. blobs of kernel/qcow2/raw image. I think we are getting out into the weeds a little bit here. It is important to think about these apis in terms of what they actually do, before the decision of combining them or not can be made. I think of HeatR as a template storage service, it provides extra data and operations on templates. HeatR should not care about how those templates are stored. Glance is an image storage service, it provides extra data and operations on images (not blobs), and it happens to use swift as a backend. If HeatR and Glance were combined, it would result in taking two very different types of data (template metadata vs image metadata) and mashing them into one service. How would adding the complexity of HeatR benefit Glance, when they are dealing with conceptually two very different types of data? For instance, should a template ever care about the field "minRam" that is stored with an image? Combining them adds a huge development complexity with a very small operations payoff, and so Openstack is already so operationally complex that HeatR as a separate service would be knowledgeable. Only clients of Heat will ever care about data and operations on templates, so I move that HeatR becomes it's own service, or becomes part of Heat. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
