Re: [openstack-dev] [Solum] Git workflow meeting reminder agenda
Hi Ibad, The Solum Git workflow meeting will be on #solum channel on IRC (freenode). —Kr On Dec 18, 2013, at 7:30 AM, iKhan ik.ibadk...@gmail.com wrote: I am newbie here and I am from +5:30 GMT. Can any one direct me how to attend this meeting? On Wed, Dec 18, 2013 at 12:46 PM, Krishna Raman kra...@gmail.com wrote: Hi, The next Git-workflow meeting is tomorrow at 8 AM PST. (http://www.worldtimebuddy.com/?qm=1lid=8,524901,2158177,100h=8date=2013-12-18sln=8-9) Agenda: Administrative: * Skip meetings for next 2 weeks. Reconvene on Jan 8th. Topics: * Krishna and Monty to summarize offline discussion * Use it for git pull/push - DU build flow * Not exposed to user. Access always through authenticated Solum APIs. * Not for generic workflow in rest of Solum - Not used to orchestrate HEAT workflow * Discussion on suggested Zuul workflow * Other workflow suggestions? —Krishna ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Thanks, Ibad Khan 9686594607 ___ 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
[openstack-dev] [Solum] Git workflow meeting reminder agenda
Hi, The next Git-workflow meeting is tomorrow at 8 AM PST. (http://www.worldtimebuddy.com/?qm=1lid=8,524901,2158177,100h=8date=2013-12-18sln=8-9) Agenda: Administrative: * Skip meetings for next 2 weeks. Reconvene on Jan 8th. Topics: * Krishna and Monty to summarize offline discussion * Use it for git pull/push - DU build flow * Not exposed to user. Access always through authenticated Solum APIs. * Not for generic workflow in rest of Solum - Not used to orchestrate HEAT workflow * Discussion on suggested Zuul workflow * Other workflow suggestions? —Krishna___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Using Zuul in the Git-pull blueprint
On Dec 12, 2013, at 1:39 PM, devdatta kulkarni devdatta.kulka...@rackspace.com wrote: We followed on the Zuul question in this week's git-integration working group meeting. mordred has created an etherpad with a high-level description of Zuul and how it might fit with Solum't git integration workflow https://etherpad.openstack.org/p/ZuulSolum The working group seemed to be coming to the consensus that we want to use a single workflow engine, as far as possible, for all of Solum's workflow needs. This brought up the question about, what are really Solum's workflow requirements. Hi I had a long conversation with Monty yesterday and we flushed out a few things I would like to run by the group. I have also included answers to the questions below. At a high-level, I think that Solum has three different kinds of workflows. 1) Workflow around getting user code into Solum - This is the git integration piece being worked out in the git-integration working group. This is possible using the Zuul workflows. Would potentially require a little work in Zuul. 2) Workflow around creating language pack(s). - The main workflow requirement here involves ability to run tests before creating a language pack. There was some discussion in language-pack working group about this requirement. This is also possible using Zuul and in-fact would benefit Solum by providing config file based build workflows that could be customized by ops personelle. For e.g.. one DU might require SVN, another might require git and a jenkins CI based unit test before triggering Langpack, other DUs might wish to leverage gerrit etc. This would be possible through Zuul without having to reinvent it on the other workflow engine. 3) Workflow around deploying created language pack(s) in order to instantiate an assembly. - The deployment may potentially contain several steps, some of which may be long running, such as populating a database. Further, there may be a need to checkpoint intermediate steps and retry the workflow from the failed point. This is probably not a very good fit for Zuul. It can handle simple workflow but won’t be able to do the complex checkpointing, rollback, retry logic etc. mordred mentioned that #1 can be achieved by Zuul (both, push-to-solum and pull-by-solum) We want to know if #2 and #3 can also be achieved by Zuul. If not, we want to know what are the available options. mordred, thanks for the etherpad; looking forward to the digram :) Zuul is workflow engine capable of running simple workflows. It is probably not suitable for all of Solum but would manage the source - DU flow quite nicely. Initially my thoughts were that I wanted to avoid having 2 workflow engines in Solum but there is another way to look at it… During out F2F, we had said that we should have a Solum API where we could just post DU images. This would allow someone to build the DU outside Solum and just provide it. We could use this same API as a clean interface to separated out the DU build flow from the DU deploy flow. Once this is done, the DU build flow (#1, #2 above) could be cleanly handled by Zuul and the DU deploy flow by whatever complex engine the rest of Solum would use. This approach has a few advantages: * Re-uses what Openstack already uses but its build CI process (and potentially makes it better) * Allows operations who deploy Solum to customize their build process without having to change Solum * Allows us to leverage the Zuul/OpenStack-infra team to help us solve the DU build flow instead of having to go alone —Krishna thanks, devkulkarni -Original Message- From: Roshan Agrawal roshan.agra...@rackspace.com Sent: Monday, December 9, 2013 10:57am To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Solum] Using Zuul in the Git-pull blueprint -Original Message- From: Krishna Raman [mailto:kra...@gmail.com] Sent: Sunday, December 08, 2013 11:24 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Solum] Using Zuul in the Git-pull blueprint Hi all, We had a very good meeting last week around the git-pull blueprint. During the discussion, Monty suggested using Zuul to manage the git repository access and workflow. While he is working on sending the group a diagram and description of what he has in mind, I had a couple of other questions which I am hoping the extended group will be able to answer. 1) Zuul is currently an infrastructure project. - Is there anything that prevents us from using it in Solum? - Does it need to be moved to a normal OpenStack project? 2) Zuul provides a sort of workflow engine. This workflow engine could potentially be used to initiate and manage: API Post - git flow - lang pack flow
Re: [openstack-dev] [Solum] Using Zuul in the Git-pull blueprint
On Dec 13, 2013, at 8:56 AM, devdatta kulkarni devdatta.kulka...@rackspace.com wrote: -Original Message- From: Krishna Raman kra...@gmail.com Sent: Friday, December 13, 2013 9:44am To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Solum] Using Zuul in the Git-pull blueprint On Dec 12, 2013, at 1:39 PM, devdatta kulkarni devdatta.kulka...@rackspace.com wrote: We followed on the Zuul question in this week's git-integration working group meeting. mordred has created an etherpad with a high-level description of Zuul and how it might fit with Solum't git integration workflow https://etherpad.openstack.org/p/ZuulSolum The working group seemed to be coming to the consensus that we want to use a single workflow engine, as far as possible, for all of Solum's workflow needs. This brought up the question about, what are really Solum's workflow requirements. Hi I had a long conversation with Monty yesterday and we flushed out a few things I would like to run by the group. I have also included answers to the questions below. At a high-level, I think that Solum has three different kinds of workflows. 1) Workflow around getting user code into Solum - This is the git integration piece being worked out in the git-integration working group. This is possible using the Zuul workflows. Would potentially require a little work in Zuul. 2) Workflow around creating language pack(s). - The main workflow requirement here involves ability to run tests before creating a language pack. There was some discussion in language-pack working group about this requirement. This is also possible using Zuul and in-fact would benefit Solum by providing config file based build workflows that could be customized by ops personelle. For e.g.. one DU might require SVN, another might require git and a jenkins CI based unit test before triggering Langpack, other DUs might wish to leverage gerrit etc. This would be possible through Zuul without having to reinvent it on the other workflow engine. 3) Workflow around deploying created language pack(s) in order to instantiate an assembly. - The deployment may potentially contain several steps, some of which may be long running, such as populating a database. Further, there may be a need to checkpoint intermediate steps and retry the workflow from the failed point. This is probably not a very good fit for Zuul. It can handle simple workflow but won’t be able to do the complex checkpointing, rollback, retry logic etc. mordred mentioned that #1 can be achieved by Zuul (both, push-to-solum and pull-by-solum) We want to know if #2 and #3 can also be achieved by Zuul. If not, we want to know what are the available options. mordred, thanks for the etherpad; looking forward to the digram :) Zuul is workflow engine capable of running simple workflows. It is probably not suitable for all of Solum but would manage the source - DU flow quite nicely. Initially my thoughts were that I wanted to avoid having 2 workflow engines in Solum but there is another way to look at it… During out F2F, we had said that we should have a Solum API where we could just post DU images. This would allow someone to build the DU outside Solum and just provide it. We could use this same API as a clean interface to separated out the DU build flow from the DU deploy flow. Once this is done, the DU build flow (#1, #2 above) could be cleanly handled by Zuul and the DU deploy flow by whatever complex engine the rest of Solum would use. I think this makes sense. If I were to tie this discussion back to the various working groups and blueprints, I think the git-integration and language-pack working groups are targeting the DU build flow (#1 and #2). On the other hand, the work being done as part of 'specify-lang-pack' blueprint and 'pluggable-template-generation' are targeting parts of #3. There would be additional blueprints for other aspects of #3. +1 - Devdatta This approach has a few advantages: * Re-uses what Openstack already uses but its build CI process (and potentially makes it better) * Allows operations who deploy Solum to customize their build process without having to change Solum * Allows us to leverage the Zuul/OpenStack-infra team to help us solve the DU build flow instead of having to go alone —Krishna thanks, devkulkarni -Original Message- From: Roshan Agrawal roshan.agra...@rackspace.com Sent: Monday, December 9, 2013 10:57am To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Solum] Using Zuul in the Git-pull blueprint -Original Message- From: Krishna Raman [mailto:kra...@gmail.com] Sent: Sunday
Re: [openstack-dev] [Solum] Using Zuul in the Git-pull blueprint
On Dec 13, 2013, at 9:32 AM, Georgy Okrokvertskhov gokrokvertsk...@mirantis.com wrote: Hi, After reading the etherpad for Solum\Zuul integration I feel that I need more clarity on this. First of all, what is missed is a positioning of Zuul in overall Solum architecture. Let me explain a bit why I have this question about positioning: 1. I don't see how Solum entities (Application, Plan, Components) related to Zuul workflows. Applications/Plans have multiple DU’s. Each DU can come from 1 of: - User provided DU - Built from user provided binaries - Built from user provided source - from git - from tar etc. The build of the DU is what the Zuul workflow will handle. No more. After the DU is built, the rest of Solum workflow will take it form there. 2. The document describes steps starting from git commit event. It is not clear how workflow appears in Zuul configuration, what are steps which should be performed by user? During F2F discussion we agreed that user will pass some parameters required for build process and deployment process. It is not clear how these parameters will appear in Zuul workflow. Each DU will have its own Zuul configuration. Which can be built based on infer provided by the user about that DU. This does not conflict with what we discussed during F2F. 3. From a security perspective it is not clear how Solum and Zuul will obtain user authentication information if entry point will be a git commit. Should user invoke Solum API somehow before git commit? Should Solum be an entry point? If Zuul will invoke Solum API for actual steps it should pass user authentication parameters too. Zuul would not be exposed to the user. It will be hidden behind Solum APIs. Solum will take care of user auth and can ask Zuul for info it will display back to user. For M1, we had decided that the git repo being accessed would be a publicly visible repo with no auth requirements. But for future flows, I can see Solum gathering the auth info and passing it to Zuul to retrieve the repo as needed. 4. If we have multiple users with multiple Application does that mean that we will have multiple Zuul instances, or we will have multiple workflows configured in Zuul? If it is a single instance will config change trig Zuul service restart? Single Zuul instance with multiple workflows registered. One for each DU. Zuul already supports dynamic configuration changes. HTH —Kr Thanks Georgy On Fri, Dec 13, 2013 at 8:56 AM, devdatta kulkarni devdatta.kulka...@rackspace.com wrote: -Original Message- From: Krishna Raman kra...@gmail.com Sent: Friday, December 13, 2013 9:44am To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Solum] Using Zuul in the Git-pull blueprint On Dec 12, 2013, at 1:39 PM, devdatta kulkarni devdatta.kulka...@rackspace.com wrote: We followed on the Zuul question in this week's git-integration working group meeting. mordred has created an etherpad with a high-level description of Zuul and how it might fit with Solum't git integration workflow https://etherpad.openstack.org/p/ZuulSolum The working group seemed to be coming to the consensus that we want to use a single workflow engine, as far as possible, for all of Solum's workflow needs. This brought up the question about, what are really Solum's workflow requirements. Hi I had a long conversation with Monty yesterday and we flushed out a few things I would like to run by the group. I have also included answers to the questions below. At a high-level, I think that Solum has three different kinds of workflows. 1) Workflow around getting user code into Solum - This is the git integration piece being worked out in the git-integration working group. This is possible using the Zuul workflows. Would potentially require a little work in Zuul. 2) Workflow around creating language pack(s). - The main workflow requirement here involves ability to run tests before creating a language pack. There was some discussion in language-pack working group about this requirement. This is also possible using Zuul and in-fact would benefit Solum by providing config file based build workflows that could be customized by ops personelle. For e.g.. one DU might require SVN, another might require git and a jenkins CI based unit test before triggering Langpack, other DUs might wish to leverage gerrit etc. This would be possible through Zuul without having to reinvent it on the other workflow engine. 3) Workflow around deploying created language pack(s) in order to instantiate an assembly. - The deployment may potentially contain several steps, some of which may be long running, such as populating a database. Further, there may
[openstack-dev] [Solum] Git workgroup meeting 8AM PST Wednesday
Hello, As a reminder, the next git workgroup meeting is tomorrow at 8 AM PST (http://www.worldtimebuddy.com/?qm=1lid=8,524901,2158177,100h=8date=2013-12-11sln=8-9) Agenda: * Topics: * Monty to present idea/diagram about using Zuul for git workflow * QA about Zuul - Process of moving Zuul out to a normal OpenStack project. Volunteer? - Is Zuul required for Solum or is it a pluggable/optional component? - Other questions? * Reserve topics: * Discuss integration with lang-pack workflow * General discussion Thanks Krishna ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Solum] Using Zuul in the Git-pull blueprint
Hi all, We had a very good meeting last week around the git-pull blueprint. During the discussion, Monty suggested using Zuul to manage the git repository access and workflow. While he is working on sending the group a diagram and description of what he has in mind, I had a couple of other questions which I am hoping the extended group will be able to answer. 1) Zuul is currently an infrastructure project. - Is there anything that prevents us from using it in Solum? - Does it need to be moved to a normal OpenStack project? 2) Zuul provides a sort of workflow engine. This workflow engine could potentially be used to initiate and manage: API Post - git flow - lang pack flow. - Have there been any discussion after the F2F where we have discussed using some other workflow engine? - Is Zuul’s engine generic enough to be used in Solum? (Hoping Monty can help with this one) - Perhaps only use it to manage the API post - git flow stages? Thanks —Krishna ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Solum] Git-workgroup recurring weekly meeting doodle poll
Hi all, During our last meeting, it was suggested that the Wed 9am PST meeting time is not suitable for Asia and a few other interested parties were also unable to attend. I have set up a new doodle poll to gather times to reschedule the meeting. Please indicate your availability here: http://doodle.com/b4pktcignhphbhqe I would like to make this a recurring meeting so please make sure it works for future weeks as well and not only for the date noted in the poll. Thanks Krishna___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Solum] git-integration working group meeting reminder
Hi, We will hold our first Git Integration working group meeting on Wednesday, December 4, 2013 1700 UTC / 0900 PST [1]. Since we have about 13 people who wish to participate, Google hangout is no longer an option. Instead we will fall back to IRC and hold the meeting on #solum. I have updated the Solum wiki to indicate the time. Agenda for tomorrows meeting: * Administrative: * Decide if we can reserve this time every week for a recurring meeting of the working group. * Topics: * Git Pull workflow (Required for milestone-1) * https://blueprints.launchpad.net/solum/+spec/solum-git-pull * Integration with existing OpenStack tools and workflow * Integration with GitHub or other external git repositories * Integration with lang-pack workflow * General discussion Please find me on #solum or email the list if you would like other topics added to this discussion. Thanks —Krishna [1] http://www.worldtimebuddy.com/?qm=1lid=8,524901,2158177,100h=8date=2013-12-04sln=9-10 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Introducing the new OpenStack service for Containers
On Thu, Nov 21, 2013 at 11:07 AM, Tim Bell tim.b...@cern.ch wrote: Can we make sure that the costs for the end users are also considered as part of this ? - Configuration management will need further modules - Dashboard confusion as we get multiple tabs - Accounting, Block Storage, Networking, Orchestration confusion as the concepts diverge Is this really a good idea to create another project considering the needs of the whole openstack community ? Hi Tim, We have not made the determination that a new service is necessary yet. All the discussion today will be about is to see what the differences are. After we have that, we will go back to discuss with Nova team and see if the split is even necessary. --kr Tim ___ 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] Introducing the new OpenStack service for Containers
On Thu, Nov 21, 2013 at 9:58 AM, Sam Alba sam.a...@gmail.com wrote: 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-apiand 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? Will go over the options on the table briefly today. As we discussed during the design session, it will be important to figure out the delta between Nova VM API and what is required for containers. After we have the delta, we can decide on which of those 3 options makes sense. --kr 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
Re: [openstack-dev] Introducing the new OpenStack service for Containers
On Nov 22, 2013, at 10:26 AM, Eric Windisch e...@cloudscaling.com wrote: On Fri, Nov 22, 2013 at 11:49 AM, Krishna Raman kra...@gmail.com wrote: Reminder: We are meting in about 15 minutes on #openstack-meeting channel. I wasn't able to make it. Was meeting-bot triggered? Is there a log of today's discussion? Yes. Logs are here: http://eavesdrop.openstack.org/meetings/nova/2013/nova.2013-11-22-17.01.log.html Thank you, Eric Windisch ___ 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
[openstack-dev] [Solum] git-Integration working group
Hello all, I would like to kickoff the Git integration discussion. Goal of this subgroup is to go through the git-integration blueprint [1] and break it up into smaller blueprints that we can execute on. We have to consider 2 workflows: 1) For Milestone 1, pull based git workflow where user uses a public git repository (possibly on github) to trigger the build 2) For later milestones, a push based workflow where the git repository is maintained by Solum Devdatta has created 2 blueprints for consideration: [2] [3] I have set up a doodle to poll for a recurring meeting time for this subgroup: http://doodle.com/7wypkzqe9wep3d33#table (Timezone support is enabled) Currently the plan is to try G+ hangouts to run this meetings and scribe on #solum. This will limit us to a max of 10 participants. If we have more interest, we will need to see how to change the meetings. Thanks Krishna [1] https://blueprints.launchpad.net/solum/+spec/git-integration [2] https://blueprints.launchpad.net/solum/+spec/solum-git-push [3] https://blueprints.launchpad.net/solum/+spec/solum-git-pull___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Introducing the new OpenStack service for Containers
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-apiand 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. --Krishna 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
Re: [openstack-dev] Introducing the new OpenStack service for Containers
-service. I have also set up a doodle poll at http://doodle.com/w7y5qcdvq9i36757 to gather a times when a majority of us are available to discuss on IRC. -- Krishna Raman PS: Sorry if you see this email twice. I am having some issues with list subscription. -- Russell Bryant ___ 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] Introducing the new OpenStack service for Containers
On Nov 18, 2013, at 6:05 PM, Russell Bryant rbry...@redhat.com wrote: On 11/18/2013 07:58 PM, Krishna Raman wrote: I have also set up a doodle poll at http://doodle.com/w7y5qcdvq9i36757 to gather a times when a majority of us are available to discuss on IRC. What time zone are these times in? Sorry forgot to mention. These times are in Pacific time zone. http://www.time.gov/timezone.cgi?Pacific/d/-8 —Krishna -- Russell Bryant ___ 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] [Nova] Mission Statement
On Nov 18, 2013, at 5:52 PM, Russell Bryant rbry...@redhat.com wrote: Greetings, Every OpenStack program is supposed to have a mission statement. The Compute program does not have one yet [1]. Here is a first attempt at it. Let me know what you think. To implement services and associated libraries to provide massively scalable, on demand, self service access to compute resources, including both virtual machines and containers. Hi Russel, Are you including containers here till we settle on the container API and decide to split or not? Thanks —Krishna [1] http://git.openstack.org/cgit/openstack/governance/tree/reference/programs.yaml -- Russell Bryant ___ 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
