Re: [openstack-dev] Introducing the new OpenStack service for Containers
On Thu, Nov 21, 2013 at 9:39 AM, Krishna Raman kra...@gmail.com wrote: On Thu, Nov 21, 2013 at 8:57 AM, Sam Alba sam.a...@gmail.com wrote: I wish we can make a decision during this meeting. Is it confirmed for Friday 9am pacific? Friday 9am Pacific seems to be the best time for this meeting. Can we use the #openstack-meeting channel for this? If not, then I can find another channel. For the agenda, I propose - going through https://etherpad.openstack.org/p/containers-service-api and understand capabilities of all container technologies + would like the experts on each of those technologies to fill us in - go over the API proposal and see what we need to change. I think it's too early to go through the API. Let's first go through all options discussed before to support containers in openstack compute: #1 Have this new compute service for containers (other than Nova) #2 Extend Nova virt API to support containers #3 Support containers API as a third API for Nova Depending how it goes, then it makes sense to do an overview of the API I think. What do you guys think? On Thu, Nov 21, 2013 at 8:24 AM, Chuck Short chuck.sh...@canonical.com wrote: Hi Has a decision happened when this meeting is going to take place, assuming it is still taking place tomorrow. Regards chuck On Mon, Nov 18, 2013 at 7:58 PM, Krishna Raman kra...@gmail.com wrote: On Nov 18, 2013, at 4:30 PM, Russell Bryant rbry...@redhat.com wrote: On 11/18/2013 06:30 PM, Dan Smith wrote: Not having been at the summit (maybe the next one), could somebody give a really short explanation as to why it needs to be a separate service? It sounds like it should fit within the Nova area. It is, after all, just another hypervisor type, or so it seems. But it's not just another hypervisor. If all you want from your containers is lightweight VMs, then nova is a reasonable place to put that (and it's there right now). If, however, you want to expose the complex and flexible attributes of a container, such as being able to overlap filesystems, have fine-grained control over what is shared with the host OS, look at the processes within a container, etc, then nova ends up needing quite a bit of change to support that. I think the overwhelming majority of folks in the room, after discussing it, agreed that Nova is infrastructure and containers is more of a platform thing. Making it a separate service lets us define a mechanism to manage these that makes much more sense than treating them like VMs. Using Nova to deploy VMs that run this service is the right approach, IMHO. Clayton put it very well, I think: If the thing you want to deploy has a kernel, then you need Nova. If your thing runs on a kernel, you want $new_service_name. I agree. Note that this is just another service under the compute project (or program, or whatever the correct terminology is this week). The Compute program is correct. That is established terminology as defined by the TC in the last cycle. So while distinct from Nova in terms of code, development should be tightly integrated until (and if at some point) it doesn't make sense. And it may share a whole bunch of the code. Another way to put this: The API requirements people have for containers include a number of features considered outside of the current scope of Nova (short version: Nova's scope stops before going *inside* the servers it creates, except file injection, which we plan to remove anyway). That presents a problem. A new service is one possible solution. My view of the outcome of the session was not it *will* be a new service. Instead, it was, we *think* it should be a new service, but let's do some more investigation to decide for sure. The action item from the session was to go off and come up with a proposal for what a new service would look like. In particular, we needed a proposal for what the API would look like. With that in hand, we need to come back and ask the question again of whether a new service is the right answer. I see 3 possible solutions here: 1) Expand the scope of Nova to include all of the things people want to be able to do with containers. This is my least favorite option. Nova is already really big. We've worked to split things out (Networking, Block Storage, Images) to keep it under control. I don't think a significant increase in scope is a smart move for Nova's future. 2) Declare containers as explicitly out of scope and start a new project with its own API. That is what is being proposed here. 3) Some middle ground that is a variation of #2. Consider Ironic. The idea is that Nova's API will still be used for basic provisioning, which Nova will implement by talking to Ironic. However, there are a lot of baremetal management things that don't fit in Nova at all
Re: [openstack-dev] Introducing the new OpenStack service for Containers
I wish we can make a decision during this meeting. Is it confirmed for Friday 9am pacific? On Thu, Nov 21, 2013 at 8:24 AM, Chuck Short chuck.sh...@canonical.com wrote: Hi Has a decision happened when this meeting is going to take place, assuming it is still taking place tomorrow. Regards chuck On Mon, Nov 18, 2013 at 7:58 PM, Krishna Raman kra...@gmail.com wrote: On Nov 18, 2013, at 4:30 PM, Russell Bryant rbry...@redhat.com wrote: On 11/18/2013 06:30 PM, Dan Smith wrote: Not having been at the summit (maybe the next one), could somebody give a really short explanation as to why it needs to be a separate service? It sounds like it should fit within the Nova area. It is, after all, just another hypervisor type, or so it seems. But it's not just another hypervisor. If all you want from your containers is lightweight VMs, then nova is a reasonable place to put that (and it's there right now). If, however, you want to expose the complex and flexible attributes of a container, such as being able to overlap filesystems, have fine-grained control over what is shared with the host OS, look at the processes within a container, etc, then nova ends up needing quite a bit of change to support that. I think the overwhelming majority of folks in the room, after discussing it, agreed that Nova is infrastructure and containers is more of a platform thing. Making it a separate service lets us define a mechanism to manage these that makes much more sense than treating them like VMs. Using Nova to deploy VMs that run this service is the right approach, IMHO. Clayton put it very well, I think: If the thing you want to deploy has a kernel, then you need Nova. If your thing runs on a kernel, you want $new_service_name. I agree. Note that this is just another service under the compute project (or program, or whatever the correct terminology is this week). The Compute program is correct. That is established terminology as defined by the TC in the last cycle. So while distinct from Nova in terms of code, development should be tightly integrated until (and if at some point) it doesn't make sense. And it may share a whole bunch of the code. Another way to put this: The API requirements people have for containers include a number of features considered outside of the current scope of Nova (short version: Nova's scope stops before going *inside* the servers it creates, except file injection, which we plan to remove anyway). That presents a problem. A new service is one possible solution. My view of the outcome of the session was not it *will* be a new service. Instead, it was, we *think* it should be a new service, but let's do some more investigation to decide for sure. The action item from the session was to go off and come up with a proposal for what a new service would look like. In particular, we needed a proposal for what the API would look like. With that in hand, we need to come back and ask the question again of whether a new service is the right answer. I see 3 possible solutions here: 1) Expand the scope of Nova to include all of the things people want to be able to do with containers. This is my least favorite option. Nova is already really big. We've worked to split things out (Networking, Block Storage, Images) to keep it under control. I don't think a significant increase in scope is a smart move for Nova's future. 2) Declare containers as explicitly out of scope and start a new project with its own API. That is what is being proposed here. 3) Some middle ground that is a variation of #2. Consider Ironic. The idea is that Nova's API will still be used for basic provisioning, which Nova will implement by talking to Ironic. However, there are a lot of baremetal management things that don't fit in Nova at all, and those only exist in Ironic's API. I wanted to mention this option for completeness, but I don't actually think it's the right choice here. With Ironic you have a physical resource (managed by Ironic), and then instances of an image running on these physical resources (managed by Nova). With containers, there's a similar line. You have instances of containers (managed either by Nova or the new service) running on servers (managed by Nova). I think there is a good line for separating concerns, with a container service on top of Nova. Let's ask ourselves: How much overlap is there between the current compute API and a proposed containers API? Effectively, what's the diff? How much do we expect this diff to change in the coming years? The current diff demonstrates a significant clash with the current scope of Nova. I also expect a lot of innovation around containers in the next few years, which will result in wanting to do new cool things in the API. I feel that all of this justifies a new API service to best position ourselves for the long term. +1 We need to come up with
Re: [openstack-dev] Introducing the new OpenStack service for Containers
On Tue, Nov 19, 2013 at 6:45 AM, Chuck Short chuck.sh...@canonical.com wrote: Hi I am excited to see containers getting such traction in the openstack project. On Mon, Nov 18, 2013 at 7:30 PM, Russell Bryant rbry...@redhat.com wrote: On 11/18/2013 06:30 PM, Dan Smith wrote: Not having been at the summit (maybe the next one), could somebody give a really short explanation as to why it needs to be a separate service? It sounds like it should fit within the Nova area. It is, after all, just another hypervisor type, or so it seems. But it's not just another hypervisor. If all you want from your containers is lightweight VMs, then nova is a reasonable place to put that (and it's there right now). If, however, you want to expose the complex and flexible attributes of a container, such as being able to overlap filesystems, have fine-grained control over what is shared with the host OS, look at the processes within a container, etc, then nova ends up needing quite a bit of change to support that. I think the overwhelming majority of folks in the room, after discussing it, agreed that Nova is infrastructure and containers is more of a platform thing. Making it a separate service lets us define a mechanism to manage these that makes much more sense than treating them like VMs. Using Nova to deploy VMs that run this service is the right approach, IMHO. Clayton put it very well, I think: If the thing you want to deploy has a kernel, then you need Nova. If your thing runs on a kernel, you want $new_service_name. I agree. Note that this is just another service under the compute project (or program, or whatever the correct terminology is this week). The Compute program is correct. That is established terminology as defined by the TC in the last cycle. So while distinct from Nova in terms of code, development should be tightly integrated until (and if at some point) it doesn't make sense. And it may share a whole bunch of the code. Another way to put this: The API requirements people have for containers include a number of features considered outside of the current scope of Nova (short version: Nova's scope stops before going *inside* the servers it creates, except file injection, which we plan to remove anyway). That presents a problem. A new service is one possible solution. My view of the outcome of the session was not it *will* be a new service. Instead, it was, we *think* it should be a new service, but let's do some more investigation to decide for sure. The action item from the session was to go off and come up with a proposal for what a new service would look like. In particular, we needed a proposal for what the API would look like. With that in hand, we need to come back and ask the question again of whether a new service is the right answer. I see 3 possible solutions here: 1) Expand the scope of Nova to include all of the things people want to be able to do with containers. This is my least favorite option. Nova is already really big. We've worked to split things out (Networking, Block Storage, Images) to keep it under control. I don't think a significant increase in scope is a smart move for Nova's future. This is my least favorite option. Like a lot of other responses already I see a lot of code duplication because Nova and the new nova container's project. This just doesn't include the scheduler but things like config driver, etc. Can we dig into this option? Honestly, I'd be glad to find a way to avoid reimplementing everything again (a new compute service with Keystone, Glance, Horizon integration, etc...). But I do understand the limitation of changing Nova to improve containers support. Can someone bring more details (maybe in the spec etherpad, in a new section) about this 3rd option? Since the API (in the front) and the virt API (in the back) have to be different, I barely see how we can reuse most of Nova's code. 2) Declare containers as explicitly out of scope and start a new project with its own API. That is what is being proposed here. 3) Some middle ground that is a variation of #2. Consider Ironic. The idea is that Nova's API will still be used for basic provisioning, which Nova will implement by talking to Ironic. However, there are a lot of baremetal management things that don't fit in Nova at all, and those only exist in Ironic's API. This is my preferred choice as well. If we could leverage the existing nova API and extend it to include containers and features that users who use containers in their existing production environment wants. I wanted to mention this option for completeness, but I don't actually think it's the right choice here. With Ironic you have a physical resource (managed by Ironic), and then instances of an image running on these physical resources (managed by Nova). With containers, there's a similar line. You have
[openstack-dev] Introducing the new OpenStack service for Containers
Hello everyone, As some of you already know - in Hong-Kong during the last OpenStack Summit - we ran a design session in the Nova topic titled Docker support in OpenStack. The session concluded in developing a new OpenStack service for supporting containers instead of modifying Nova to support both VMs and containers. As said earlier, I am proposing a first draft of the spec for the service. I've explicitly CC'ed all people who signed up at the end of the design session. Here is it: https://etherpad.openstack.org/p/containers-service Once we agree on the HTTP API and on the plugin API, the idea is to implement a first simple version that would support mono-host. Then it would evolve in multi-host really quickly by adding a scheduler and a messaging layer (more details in the etherpad). Please have a look if you're interested in using Containers (and Docker) in OpenStack. Thanks Russell for giving some early feedback. Also, Krishna Raman from RedHat already gave a first shot at drafting the Rest API: https://etherpad.openstack.org/p/containers-service-api Sam -- @sam_alba ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum/Heat] Is Solum really necessary?
Hi Jay, I think Heat is an ingredient for Solum. When you build a PaaS, you need to control the app at different levels: #1 describing your app (basically your stack) #2 Pushing your code #3 Deploying it #4 Controlling the runtime (restart, get logs, scale, changing resources allocation, etc...) I think Heat is a major component for step 3. But I think Heat's job ends at the end of the deployment (the status of the stack is COMPLETED in Heat after processing the template correctly). It's nice though to rely on Heat's template generation for describing the stack, it's one more thing to delegate to Heat. In other words, I see Heat as an engine for deployment (at least in the context of Solum) and have something on top to manage the other steps. - Sam On Thu, Nov 14, 2013 at 10:41 AM, Jay Pipes jaypi...@gmail.com wrote: So while I have been on vacation, I've been thinking about Solum and Heat. And I have some lingering questions in my mind that make me question whether a new server project is actually necessary at all, and whether we really should just be targeting innovation and resources towards the Heat project. What exactly is Solum's API going to control that is not already represented in Heat's API and the HOT templating language? At this point, I'm really not sure, and I'm hoping that we can discuss this important topic before going any further with Solum. Right now, I see so much overlap that I'm questioning where the differences really are. Thoughts? -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- @sam_alba ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Heat] Plugin to use Docker containers a resources in a template
Hi all, I've been recently working on a Docker plugin for Heat that makes it possible to use Docker containers as resources. I've just opened the repository: https://github.com/dotcloud/openstack-heat-docker It's now possible to do that via Nova (since there is now a Docker driver for it). But the idea here is not to replace the Nova driver with this Heat plugin, the idea is just to propose a different path. Basically, Docker itself has a Rest API[1] with all features needed to deploy and manage containers, the Nova driver uses this API. However having the Nova API in front of it makes it hard to bring all Docker features to the user, basically everything has to fit into the Nova API. For instance, docker commit/push are mapped to nova snapshots, etc... And a lot of Docker features are not available yet; I admit that some of them will be hard to support (docker Env variables, Volumes, etc... how should they fit in Nova?). The idea of this Docker plugin for Heat is to use the whole Docker API directly from a template. All possible parameters for creating a container from the Docker API[2] can be defined from the template. This allows more flexibility. Since this approach is a bit different from the normal OpenStack workflow (for instance, Nova's role is to abstract all computing units right now), I am interested to get feedback on this. Obviously, I'll keep maintaining the Docker driver for Nova and I'm also working on putting together some new features I'll propose for the next release. [1] http://docs.docker.io/en/latest/api/docker_remote_api_v1.5/ [2] http://docs.docker.io/en/latest/api/docker_remote_api_v1.5/#create-a-container -- @sam_alba ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Plugin to use Docker containers a resources in a template
On Thu, Oct 17, 2013 at 6:33 PM, Russell Bryant rbry...@redhat.com wrote: On 10/17/2013 09:06 PM, Sam Alba wrote: Hi all, I've been recently working on a Docker plugin for Heat that makes it possible to use Docker containers as resources. I've just opened the repository: https://github.com/dotcloud/openstack-heat-docker It's now possible to do that via Nova (since there is now a Docker driver for it). But the idea here is not to replace the Nova driver with this Heat plugin, the idea is just to propose a different path. Basically, Docker itself has a Rest API[1] with all features needed to deploy and manage containers, the Nova driver uses this API. However having the Nova API in front of it makes it hard to bring all Docker features to the user, basically everything has to fit into the Nova API. For instance, docker commit/push are mapped to nova snapshots, etc... And a lot of Docker features are not available yet; I admit that some of them will be hard to support (docker Env variables, Volumes, etc... how should they fit in Nova?). But we haven't talked about any of this yet, have we? :-) Hehe :-) No I hope we will. I'll be in Honk-Kong in November. I don't know if it's worth submitting a new topic for the design session? If you want to tackle the subject before the summit, let me know, I'd be glad to contribute on that. The idea of this Docker plugin for Heat is to use the whole Docker API directly from a template. All possible parameters for creating a container from the Docker API[2] can be defined from the template. This allows more flexibility. Since this approach is a bit different from the normal OpenStack workflow (for instance, Nova's role is to abstract all computing units right now), I am interested to get feedback on this. Obviously, I'll keep maintaining the Docker driver for Nova and I'm also working on putting together some new features I'll propose for the next release. [1] http://docs.docker.io/en/latest/api/docker_remote_api_v1.5/ [2] http://docs.docker.io/en/latest/api/docker_remote_api_v1.5/#create-a-container The way Nova uses the docker API is that each nova-compute service is managing docker locally. So, Nova allows you to utilize docker through a single API across many nodes, right? How does this work with this plugin? You're right. With the plugin, you can map each resource on different DockerEndpoint (which is an attribute), then have a multi-host orchestration. I think my biggest piece of feedback is that I would like to talk about how we can evolve Nova to better support containers instead of just assuming it's hard and that another direction has to be taken. It could be that the combination of some Nova enhancements and some docker-specific Heat features makes sense. I don't know yet. Can we get into some more details about what drove you to think you needed to bypass Nova? The initial goal was to orchestrate containers with Heat. Since passing information between containers rely on environment variables generated during the deploy process, and since the driver does not support yet, I wanted to take a shortcut. Let's call this an experiment. Again the goal is not to make this the official way of using Docker in OpenStack. Docker does not (and will not) implement features that Nova brings for free like quota, and especially a deep integration with all other OpenStack services. -- @sam_alba ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Plugin to use Docker containers a resources in a template
On Thu, Oct 17, 2013 at 7:47 PM, Steven Dake sd...@redhat.com wrote: On 10/17/2013 06:06 PM, Sam Alba wrote: Hi all, I've been recently working on a Docker plugin for Heat that makes it possible to use Docker containers as resources. I've just opened the repository: https://github.com/dotcloud/openstack-heat-docker It's now possible to do that via Nova (since there is now a Docker driver for it). But the idea here is not to replace the Nova driver with this Heat plugin, the idea is just to propose a different path. Basically, Docker itself has a Rest API[1] with all features needed to deploy and manage containers, the Nova driver uses this API. However having the Nova API in front of it makes it hard to bring all Docker features to the user, basically everything has to fit into the Nova API. For instance, docker commit/push are mapped to nova snapshots, etc... And a lot of Docker features are not available yet; I admit that some of them will be hard to support (docker Env variables, Volumes, etc... how should they fit in Nova?). The idea of this Docker plugin for Heat is to use the whole Docker API directly from a template. All possible parameters for creating a container from the Docker API[2] can be defined from the template. This allows more flexibility. Since this approach is a bit different from the normal OpenStack workflow (for instance, Nova's role is to abstract all computing units right now), I am interested to get feedback on this. Obviously, I'll keep maintaining the Docker driver for Nova and I'm also working on putting together some new features I'll propose for the next release. [1] http://docs.docker.io/en/latest/api/docker_remote_api_v1.5/ [2] http://docs.docker.io/en/latest/api/docker_remote_api_v1.5/#create-a-container Why not submit the resource plugin as a patch against heat using the standard OpenStack workflow vs a separate repository? I don't know if it makes sense at this stage. But at some point why not, I am not against submitting this upstream... What do you think? -- @sam_alba ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Plugin to use Docker containers a resources in a template
On Thu, Oct 17, 2013 at 8:29 PM, Clint Byrum cl...@fewbar.com wrote: Excerpts from Sam Alba's message of 2013-10-17 18:06:04 -0700: Hi all, I've been recently working on a Docker plugin for Heat that makes it possible to use Docker containers as resources. I've just opened the repository: https://github.com/dotcloud/openstack-heat-docker It's now possible to do that via Nova (since there is now a Docker driver for it). But the idea here is not to replace the Nova driver with this Heat plugin, the idea is just to propose a different path. Basically, Docker itself has a Rest API[1] with all features needed to deploy and manage containers, the Nova driver uses this API. However having the Nova API in front of it makes it hard to bring all Docker features to the user, basically everything has to fit into the Nova API. For instance, docker commit/push are mapped to nova snapshots, etc... And a lot of Docker features are not available yet; I admit that some of them will be hard to support (docker Env variables, Volumes, etc... how should they fit in Nova?). Agreed, I never thought docker was an excellent fit at the nova driver level. It certainly seems useful, but not necessarily excellent. Well, having a first version of the driver merged into nova core is the best way to improve it over the next releases! The idea of this Docker plugin for Heat is to use the whole Docker API directly from a template. All possible parameters for creating a container from the Docker API[2] can be defined from the template. This allows more flexibility. I just looked through the README and examples quickly, and it is fantastic. I think this is a nice example of how to integrate a non-OpenStack component into a Heat template. I have some thoughts on next steps: 1) Consider moving it to Heat's contrib directory. Being gated and wrapped in OpenStack procedures means you will get more OpenStack contribution. Of course, if your community is more at home where the repo is, then leave it there. We don't _need_ plugins to be in contrib. Being gated and wrapped in OpenStack procedures makes sense. 2) Docker.handle_delete will fail in glorious fashion if you have deleted the container already from outside. We follow a general paradigm where if the underlying components of the resource are not found, consider that success and exit the handle_delete method. This also helps if a delete failed in some other way and you are retrying the delete. glorious fashion is the right term :-). It's true that the plugin does not prevent the user to keep using docker directly (which is a good point actually). Then the plugin has to be tolerant as you describe. 3) Would be really cool to also have a traditional Heat template that one can nest for deploying docker itself on an OS::Nova::Server. Combine that with the random string generator for passwords and you can have a fully automatic Heat controlled deployment of docker things. Taking notes :-) Since this approach is a bit different from the normal OpenStack workflow (for instance, Nova's role is to abstract all computing units right now), I am interested to get feedback on this. This isn't all that far off from what an OS::Trove::Database resource would be. You are encapsulating another management tool that simplifies a common task and gives it an API into a resource to relieve people of the need to repeat all of the API orchestration that they would have to do in-server. -- @sam_alba ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Plugin packaging
On Tue, Oct 15, 2013 at 2:31 AM, Zane Bitter zbit...@redhat.com wrote: On 15/10/13 02:18, Sam Alba wrote: Hello, I am working on a Heat plugin that makes a new resource available in a template. It's working great and I will opensource it this week if I can get the packaging right... Awesome! :) Right now, I am linking my module.py file in /usr/lib/heat to get it loaded when heat-engine starts. But according to the doc, I am supposed to be able to make the plugin discoverable by heat-engine if the module appears in the package heat.engine.plugins[1] I think the documentation may be leading you astray here; it's the other way around: once the plugin is discovered by the engine, it will appear in the package heat.engine.plugins. So you should be able to do: import heat.engine.resources heat.engine.resources.initialise() from heat.engine.plugins import module print module.resource_mapping() (FWIW this is working for me on latest master of Heat.) As far as making the plugin discoverable is concerned, all you should have to do is install the module in /usr/lib/heat/. I looked into the plugin_loader module in the Heat source code and it looks like it should work. However I was unable to get a proper Python package. Has anyone been able to make this packaging right for an external Heat plugin? I've never tried to do this with a Python package, the mechanism is really designed more for either dropping the module in there manually, or installing it from a Debian or RPM package. It sounds like what you're doing is trying to install the package in /usr/lib/python2.7/site-packages/ (or in a venv) in the package heat.engine.plugins and get the engine to recognise it that way? I don't think there's a safe way to make that work, because the plugin loader creates its own heat.engine.plugins package that will replace anything that exists on that path (see line 41 of plugin_loader.py). Heat (in fact, all of OpenStack) is designed as a system service, so the normal rules of Python _application_ packaging don't quite fit. e.g. If you want to use a plugin locally (for a single user) rather than install it globally, the way to do it is to specify a local plugin directory when running heat-engine, rather than have the plugin installed in a venv. Hope that helps. Thanks Zane, it helps. -- @sam_alba ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Heat] Plugin packaging
Hello, I am working on a Heat plugin that makes a new resource available in a template. It's working great and I will opensource it this week if I can get the packaging right... Right now, I am linking my module.py file in /usr/lib/heat to get it loaded when heat-engine starts. But according to the doc, I am supposed to be able to make the plugin discoverable by heat-engine if the module appears in the package heat.engine.plugins[1] I looked into the plugin_loader module in the Heat source code and it looks like it should work. However I was unable to get a proper Python package. Has anyone been able to make this packaging right for an external Heat plugin? Thanks in advance, [1] https://wiki.openstack.org/wiki/Heat/Plugins#Installation_and_Configuration -- @sam_alba ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] New Nova hypervisor: Docker
Hi Jaume, On Thu, Aug 29, 2013 at 5:11 AM, Jaume Devesa devv...@gmail.com wrote: Hi Sam, that's a great work and it will be for sure my default driver for my development environment. Thanks! I have a question: once the review will be approved and the code merged into master, do you plan to create a driver nova subteam as Xen, HyperV and others do? I would be glad to cooperate on it. Yes, being merged is the step 0 but there is much more to do after that. Docker is moving quickly and I aim to improve this driver along the releases. Some other people at dotCloud will be involved in this work and obviously anyone else is more than welcome to join the effort like it happened with Brian and Dean. The work has been shipped by the 3 of us so far. On 29 August 2013 07:54, Sam Alba sam.a...@gmail.com wrote: On Wed, Aug 28, 2013 at 9:12 AM, Sam Alba sam.a...@gmail.com wrote: Thanks a lot everyone for the nice feedback. I am going to work hard to get all those new comments addressed to be able to re-submit a new patchset today or tomorrow (the later). On Wed, Aug 28, 2013 at 7:02 AM, Russell Bryant rbry...@redhat.com wrote: On 08/28/2013 05:18 AM, Daniel P. Berrange wrote: On Wed, Aug 28, 2013 at 06:00:50PM +1000, Michael Still wrote: On Wed, Aug 28, 2013 at 4:18 AM, Sam Alba sam.a...@gmail.com wrote: Hi all, We've been working hard during the last couple of weeks with some people. Brian Waldon helped a lot designing the Glance integration and driver testing. Dean Troyer helped a lot on bringing Docker support in Devstack[1]. On top of that, we got several feedback on the Nova code review which definitely helped to improve the code. The blueprint[2] explains what Docker brings to Nova and how to use it. I have to say that this blueprint is a fantastic example of how we should be writing design documents. It addressed almost all of my questions about the integration. Yes, Sam ( any of the other Docker guys involved) have been great at responding to reviewers' requests to expand their design document. The latest update has really helped in understanding how this driver works in the context of openstack from an architectural and functional POV. They've been great in responding to my requests, as well. The biggest thing was that I wanted to see devstack support so that it's easily testable, both by developers and by CI. They delivered. So, in general, I'm good with this going in. It's just a matter of getting the code review completed in the next week before feature freeze. I'm going to try to help with it this week. If someone wants to take another look at https://review.openstack.org/#/c/32960/, we answered/fixed all previous comments. -- @sam_alba ___ 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 -- @sam_alba ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] New Nova hypervisor: Docker
Thanks a lot everyone for the nice feedback. I am going to work hard to get all those new comments addressed to be able to re-submit a new patchset today or tomorrow (the later). On Wed, Aug 28, 2013 at 7:02 AM, Russell Bryant rbry...@redhat.com wrote: On 08/28/2013 05:18 AM, Daniel P. Berrange wrote: On Wed, Aug 28, 2013 at 06:00:50PM +1000, Michael Still wrote: On Wed, Aug 28, 2013 at 4:18 AM, Sam Alba sam.a...@gmail.com wrote: Hi all, We've been working hard during the last couple of weeks with some people. Brian Waldon helped a lot designing the Glance integration and driver testing. Dean Troyer helped a lot on bringing Docker support in Devstack[1]. On top of that, we got several feedback on the Nova code review which definitely helped to improve the code. The blueprint[2] explains what Docker brings to Nova and how to use it. I have to say that this blueprint is a fantastic example of how we should be writing design documents. It addressed almost all of my questions about the integration. Yes, Sam ( any of the other Docker guys involved) have been great at responding to reviewers' requests to expand their design document. The latest update has really helped in understanding how this driver works in the context of openstack from an architectural and functional POV. They've been great in responding to my requests, as well. The biggest thing was that I wanted to see devstack support so that it's easily testable, both by developers and by CI. They delivered. So, in general, I'm good with this going in. It's just a matter of getting the code review completed in the next week before feature freeze. I'm going to try to help with it this week. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- @sam_alba ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] New Nova hypervisor: Docker
On Wed, Aug 28, 2013 at 9:12 AM, Sam Alba sam.a...@gmail.com wrote: Thanks a lot everyone for the nice feedback. I am going to work hard to get all those new comments addressed to be able to re-submit a new patchset today or tomorrow (the later). On Wed, Aug 28, 2013 at 7:02 AM, Russell Bryant rbry...@redhat.com wrote: On 08/28/2013 05:18 AM, Daniel P. Berrange wrote: On Wed, Aug 28, 2013 at 06:00:50PM +1000, Michael Still wrote: On Wed, Aug 28, 2013 at 4:18 AM, Sam Alba sam.a...@gmail.com wrote: Hi all, We've been working hard during the last couple of weeks with some people. Brian Waldon helped a lot designing the Glance integration and driver testing. Dean Troyer helped a lot on bringing Docker support in Devstack[1]. On top of that, we got several feedback on the Nova code review which definitely helped to improve the code. The blueprint[2] explains what Docker brings to Nova and how to use it. I have to say that this blueprint is a fantastic example of how we should be writing design documents. It addressed almost all of my questions about the integration. Yes, Sam ( any of the other Docker guys involved) have been great at responding to reviewers' requests to expand their design document. The latest update has really helped in understanding how this driver works in the context of openstack from an architectural and functional POV. They've been great in responding to my requests, as well. The biggest thing was that I wanted to see devstack support so that it's easily testable, both by developers and by CI. They delivered. So, in general, I'm good with this going in. It's just a matter of getting the code review completed in the next week before feature freeze. I'm going to try to help with it this week. If someone wants to take another look at https://review.openstack.org/#/c/32960/, we answered/fixed all previous comments. -- @sam_alba ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] New Nova hypervisor: Docker
Hi all, We've been working hard during the last couple of weeks with some people. Brian Waldon helped a lot designing the Glance integration and driver testing. Dean Troyer helped a lot on bringing Docker support in Devstack[1]. On top of that, we got several feedback on the Nova code review which definitely helped to improve the code. The blueprint[2] explains what Docker brings to Nova and how to use it. Before getting it merged into Nova core, the code lives on github[3]. Our goal right now is to have everything ready to get merged for the Havana release. We need help for getting the code reviewed[4] on time. [1] https://review.openstack.org/#/c/40759/ [2] https://github.com/dotcloud/openstack-docker/blob/master/docs/nova_blueprint.md [3] https://github.com/dotcloud/openstack-docker [4] https://review.openstack.org/#/c/32960/ -- @sam_alba ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
