Re: [openstack-dev] [Solum] Question about Zuul's role in Solum
A very well thought out response. Thank you. So long as the user interface for enabling additional major functionality is very simple like " enable gating", and so long as a defaulted off instance can be quickly "upgraded", defaulting to off wouldn't be too bad. I also like the plan of using the battle/scale tested zuul and turning off the parts we don't need. One reason I chose OpenStack up front was I knew it would scale way past anything I would need it for, because it was already running at huge scale. Knowing zuul/solum could handle the really complex workloads even if I don't use it all at first is comforting. Thanks, Kevin From: Adrian Otto [adrian.o...@rackspace.com] Sent: Sunday, February 16, 2014 3:47 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum] Question about Zuul's role in Solum On Feb 16, 2014, at 2:31 AM, Robert Collins wrote: > On 16 February 2014 17:57, Jay Pipes wrote: > >> Personally, I believe having Gerrit and Jenkins as the default will turn >> more people off Solumn than attract them to it. >> >> Just because we in the OpenStack community love our gating workflow and >> think it's all groovy does not mean that view is common, wanted, or >> understood by the vast majority of users of Heroku-like solutions. > > There are quite a number of such solutions; do we want to write yet > another? What makes solum special ? Is it supporting OpenStack? [If so > - I'd argue that our success elsewhere will guarantee other such > platforms support OpenStack - and e.g. OpenShift already do AFAIK]. > Why are we writing Solum? Excellent focusing question. We are focused on the Application Developer persona as a class. We want clouds to be easier to use, and more accessible for them. We'd like to offer streamlined experiences that help them focus on application development, and worry less about how to get their applications to run on the cloud. We expect to be able to achieve this goal by letting the developers connect their code repositories with Solum enabled clouds, and use development best practices to automate the building, testing, and deploying of code. Why? Because Application Developers have enough to worry about, without contemplating all of the above in a DIY approach. We'd like to address this focus area in a way that offers the developers a sense of "insurance" that when their application becomes successful one day (and they want to begin focusing on the details and potentially customizing the various aspects of how code is handled and deployed, and what environments it it run in) that they will not need to forklift their code from one cloud to another, but can begin to use a wider variety of control system API's to tap into what's already there. Cloud operators (public and private alike) want to offer these streamlined user experiences to the Application Developers that use their clouds. They want to do so without bringing in the operational complexity and overhead of running a PaaS system that largely overlaps with numerous aspects of what's already offered in OpenStack. By selecting Solum, they leverage what's here already, and add in additional ease of use, and the ability to abstract and simplify a variety of complexity relating to the code->app lifecycle, and gradually adding in new capabilities for managing apps once they are on the cloud. >> Who is the audience here? It is not experienced developers who already >> understand things like Gerrit and Jenkins. It's developers who just want >> to simplify the process of pushing code up to some system other than >> Github or their workstation. Adding the awkwardness of Gerrit's code > > If thats all, then I don't think we should be writing Solum. We should > just pick some of the existing tooling for that and say 'use that'. If we do a good job of offering a sensible set of defaults, balanced with a compelling set of features, then Solum will be very useful. We're not aiming to replace or re-invent every CI tool that was ever invented. To the contrary, we want to allow sophisticated dev shops who have investments in CI infrastructure already an opportunity to use Solum as a CD tool (submit a plan file and a container image to the Solum API by using a simple Git post-commit hook trigger). However, we also want to provide developers who possibly have never seen a comprehensive CI/CD setup an opportunity to access one that works for general use, and a place where the existing tool makers can integrate and offer their value-added software and solutions to make those experiences even better. This is where we are right now, deicing how to take an iterative approach to making
Re: [openstack-dev] [Solum] Question about Zuul's role in Solum
On Feb 16, 2014, at 2:31 AM, Robert Collins wrote: > On 16 February 2014 17:57, Jay Pipes wrote: > >> Personally, I believe having Gerrit and Jenkins as the default will turn >> more people off Solumn than attract them to it. >> >> Just because we in the OpenStack community love our gating workflow and >> think it's all groovy does not mean that view is common, wanted, or >> understood by the vast majority of users of Heroku-like solutions. > > There are quite a number of such solutions; do we want to write yet > another? What makes solum special ? Is it supporting OpenStack? [If so > - I'd argue that our success elsewhere will guarantee other such > platforms support OpenStack - and e.g. OpenShift already do AFAIK]. > Why are we writing Solum? Excellent focusing question. We are focused on the Application Developer persona as a class. We want clouds to be easier to use, and more accessible for them. We'd like to offer streamlined experiences that help them focus on application development, and worry less about how to get their applications to run on the cloud. We expect to be able to achieve this goal by letting the developers connect their code repositories with Solum enabled clouds, and use development best practices to automate the building, testing, and deploying of code. Why? Because Application Developers have enough to worry about, without contemplating all of the above in a DIY approach. We'd like to address this focus area in a way that offers the developers a sense of "insurance" that when their application becomes successful one day (and they want to begin focusing on the details and potentially customizing the various aspects of how code is handled and deployed, and what environments it it run in) that they will not need to forklift their code from one cloud to another, but can begin to use a wider variety of control system API's to tap into what's already there. Cloud operators (public and private alike) want to offer these streamlined user experiences to the Application Developers that use their clouds. They want to do so without bringing in the operational complexity and overhead of running a PaaS system that largely overlaps with numerous aspects of what's already offered in OpenStack. By selecting Solum, they leverage what's here already, and add in additional ease of use, and the ability to abstract and simplify a variety of complexity relating to the code->app lifecycle, and gradually adding in new capabilities for managing apps once they are on the cloud. >> Who is the audience here? It is not experienced developers who already >> understand things like Gerrit and Jenkins. It's developers who just want >> to simplify the process of pushing code up to some system other than >> Github or their workstation. Adding the awkwardness of Gerrit's code > > If thats all, then I don't think we should be writing Solum. We should > just pick some of the existing tooling for that and say 'use that'. If we do a good job of offering a sensible set of defaults, balanced with a compelling set of features, then Solum will be very useful. We're not aiming to replace or re-invent every CI tool that was ever invented. To the contrary, we want to allow sophisticated dev shops who have investments in CI infrastructure already an opportunity to use Solum as a CD tool (submit a plan file and a container image to the Solum API by using a simple Git post-commit hook trigger). However, we also want to provide developers who possibly have never seen a comprehensive CI/CD setup an opportunity to access one that works for general use, and a place where the existing tool makers can integrate and offer their value-added software and solutions to make those experiences even better. This is where we are right now, deicing how to take an iterative approach to making this default CI/CD setup useful and interesting. >> review system -- and the associated pain of trying to understand how to >> define Jenkins jobs -- is something that I don't think the *default* >> Solum experience should invite. >> >> The default experience should be a simple push code, run merge tests, > > What are merge tests? How are they defined? What about that definition > makes it impossible for us to run them in Jenkins or similar? What > makes it impossible to run them before the merge? Excellent questions again. There's no reason you could not use any variety of existing applications to do this. There is value in allowing developers to start simple with reduced effort, and start to use more advanced CI features when they are ready to opt into them. Focusing on ease of use is key. >> and deploy into the deployment unit (whatever that is called in Solum >> nowadays). There should be well-documented ways to add commit hooks into >> this workflow, but having a complex Gerrit and Jenkins gated workflow is >> just overkill for the default experience. We can all agree that we are not aiming to offer
Re: [openstack-dev] [Solum] Question about Zuul's role in Solum
On 16 February 2014 17:57, Jay Pipes wrote: > Personally, I believe having Gerrit and Jenkins as the default will turn > more people off Solumn than attract them to it. > > Just because we in the OpenStack community love our gating workflow and > think it's all groovy does not mean that view is common, wanted, or > understood by the vast majority of users of Heroku-like solutions. There are quite a number of such solutions; do we want to write yet another? What makes solum special ? Is it supporting OpenStack? [If so - I'd argue that our success elsewhere will guarantee other such platforms support OpenStack - and e.g. OpenShift already do AFAIK]. Why are we writing Solum? > Who is the audience here? It is not experienced developers who already > understand things like Gerrit and Jenkins. It's developers who just want > to simplify the process of pushing code up to some system other than > Github or their workstation. Adding the awkwardness of Gerrit's code If thats all, then I don't think we should be writing Solum. We should just pick some of the existing tooling for that and say 'use that'. > review system -- and the associated pain of trying to understand how to > define Jenkins jobs -- is something that I don't think the *default* > Solum experience should invite. > > The default experience should be a simple push code, run merge tests, What are merge tests? How are they defined? What about that definition makes it impossible for us to run them in Jenkins or similar? What makes it impossible to run them before the merge? > and deploy into the deployment unit (whatever that is called in Solum > nowadays). There should be well-documented ways to add commit hooks into > this workflow, but having a complex Gerrit and Jenkins gated workflow is > just overkill for the default experience. Even in small teams - 4-5 people - gated workflow and CI/CD is a game changer for velocity. If your point is 'doing the sophisticated thing OpenStack does is hard and we shouldn't try to sell people on working hard' - I agree. But your point currently sounds like 'there's no way we can make this stuff easy, discoverable, and straight forward, so we should focus on something much less capable'. Perhaps thats not what you mean? I think there is a spectrum here. We need to aim high, or we achieve low. We also need to deliver incrementally, and we need to provide a -really- gentle onramp for users. Make the first basic steps easy and simple: but thats not in any way incompatible with gating by default. It *might* be incompatible with Jenkins and zuul: but thats a slightly different discussion- my +1, which you replied to, was about /gating/ by default, not about the implementation thereof. -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Question about Zuul's role in Solum
On Sat, 2014-02-15 at 17:20 +1300, Robert Collins wrote: > On 15 February 2014 14:34, Fox, Kevin M wrote: > > I think a lot of projects don't bother to gate, because its far to much > > work to set up a workable system. > > > > I can think of several projects I've worked on that would benefit from it > > but haven't because of time/cost of setting it up. > > > > If I could just say "solum create project foo" and get it, I'm sure it > > would be much more used. > > > > The same has been said of Unit tests and CI in the past. "We don't need > > it". When you give someone a simple to use system though, they see its > > value pretty quickly. > > > > Yeah, gerrit and jenkins are a pain to setup. Thats one of the things that > > might make solum great. That it removes that pain. > > Gating is hard, so we should do more of it. > > +1 on gating by default, rather than being nothing more than a remote > git checkout - there are lots of those systems already, and being one > won't make solum stand out,. Personally, I believe having Gerrit and Jenkins as the default will turn more people off Solumn than attract them to it. Just because we in the OpenStack community love our gating workflow and think it's all groovy does not mean that view is common, wanted, or understood by the vast majority of users of Heroku-like solutions. Who is the audience here? It is not experienced developers who already understand things like Gerrit and Jenkins. It's developers who just want to simplify the process of pushing code up to some system other than Github or their workstation. Adding the awkwardness of Gerrit's code review system -- and the associated pain of trying to understand how to define Jenkins jobs -- is something that I don't think the *default* Solum experience should invite. The default experience should be a simple push code, run merge tests, and deploy into the deployment unit (whatever that is called in Solum nowadays). There should be well-documented ways to add commit hooks into this workflow, but having a complex Gerrit and Jenkins gated workflow is just overkill for the default experience. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Question about Zuul's role in Solum
On 15 February 2014 14:34, Fox, Kevin M wrote: > I think a lot of projects don't bother to gate, because its far to much work > to set up a workable system. > > I can think of several projects I've worked on that would benefit from it but > haven't because of time/cost of setting it up. > > If I could just say "solum create project foo" and get it, I'm sure it would > be much more used. > > The same has been said of Unit tests and CI in the past. "We don't need it". > When you give someone a simple to use system though, they see its value > pretty quickly. > > Yeah, gerrit and jenkins are a pain to setup. Thats one of the things that > might make solum great. That it removes that pain. Gating is hard, so we should do more of it. +1 on gating by default, rather than being nothing more than a remote git checkout - there are lots of those systems already, and being one won't make solum stand out,. -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Question about Zuul's role in Solum
I think a lot of projects don't bother to gate, because its far to much work to set up a workable system. I can think of several projects I've worked on that would benefit from it but haven't because of time/cost of setting it up. If I could just say "solum create project foo" and get it, I'm sure it would be much more used. The same has been said of Unit tests and CI in the past. "We don't need it". When you give someone a simple to use system though, they see its value pretty quickly. Yeah, gerrit and jenkins are a pain to setup. Thats one of the things that might make solum great. That it removes that pain. Kevin From: Jay Pipes [jaypi...@gmail.com] Sent: Friday, February 14, 2014 2:51 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Solum] Question about Zuul's role in Solum On Thu, 2014-02-13 at 14:18 +0100, Julien Vey wrote: > I agree gating is a great feature but it is not useful for every > project and as Adrian said, not understood by everyone. > I think many Solum users, and PaaS users in general, are > single-project/single-build/simple git worklow and do not care about > gating. This is 100% correct. > I see 2 drawbacks with Zuul : > - Tenant Isolation : How do we allow access on zuul (and jenkins) for > a specific tenant in isolation to the others tenants using Solum. > - Build customization : One of the biggest advantage of Jenkins is its > ecosystem and the many build customization it offers. Using zuul will > prohibit this. Not sure I understand this part... Zuul works *with* Jenkins. It does not replace it. > About Gerrit, I think it is also a little too much. Many users have > their own reviewing system, Pull requests with github, bitbucket or > stash, their own instance of gerrit, or even a custom git workflow. > Gerrit would be a great feature for future versions of Solum. but only > as an optionnal one, we should not force people into it. Completely agreed. Frankly, both Gerrit and Jenkins are a giant pain in the ass to install, maintain, and configure (hmm, which Java/Prolog programs aren't, I wonder?). Basing Solum's *default* workflow on these tools would be a mistake IMO. Best, -jay ___ 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] [Solum] Question about Zuul's role in Solum
On Thu, 2014-02-13 at 14:18 +0100, Julien Vey wrote: > I agree gating is a great feature but it is not useful for every > project and as Adrian said, not understood by everyone. > I think many Solum users, and PaaS users in general, are > single-project/single-build/simple git worklow and do not care about > gating. This is 100% correct. > I see 2 drawbacks with Zuul : > - Tenant Isolation : How do we allow access on zuul (and jenkins) for > a specific tenant in isolation to the others tenants using Solum. > - Build customization : One of the biggest advantage of Jenkins is its > ecosystem and the many build customization it offers. Using zuul will > prohibit this. Not sure I understand this part... Zuul works *with* Jenkins. It does not replace it. > About Gerrit, I think it is also a little too much. Many users have > their own reviewing system, Pull requests with github, bitbucket or > stash, their own instance of gerrit, or even a custom git workflow. > Gerrit would be a great feature for future versions of Solum. but only > as an optionnal one, we should not force people into it. Completely agreed. Frankly, both Gerrit and Jenkins are a giant pain in the ass to install, maintain, and configure (hmm, which Java/Prolog programs aren't, I wonder?). Basing Solum's *default* workflow on these tools would be a mistake IMO. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Question about Zuul's role in Solum
On Thu, 2014-02-13 at 00:05 +, Adrian Otto wrote: > If they want something more comprehensive, including a full set of open > source best practices by default, such as entrance and exit gating, hosted > code review and collaboration, It would be really nice to have a full > Zuul+Nodepool+Jenkins+Gerrit setup with some integration points where they > could potentially customize it. You might be interested in a couple articles I recently wrote around this very topic! :) http://www.joinfu.com/2014/01/understanding-the-openstack-ci-system/ http://www.joinfu.com/2014/02/setting-up-an-external-openstack-testing-system/ Cheers, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Question about Zuul's role in Solum
> -Original Message- > From: Clayton Coleman [mailto:ccole...@redhat.com] > Sent: Thursday, February 13, 2014 4:34 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Solum] Question about Zuul's role in Solum > > > > - Original Message - > > From: Julien Vey < vey.jul...@gmail.com > > > Reply-To: "OpenStack Development Mailing List (not for usage > > questions)" < openstack-dev@lists.openstack.org > > > Date: Thursday, February 13, 2014 7:18 AM > > To: "OpenStack Development Mailing List (not for usage questions)" < > > openstack-dev@lists.openstack.org > > > Subject: Re: [openstack-dev] [Solum] Question about Zuul's role in > > Solum > > > > > > > > > > Hi, > > > > I have some concerns about using Zuul in Solum > > > > > > > > > > I agree gating is a great feature but it is not useful for every > > project and as Adrian said, not understood by everyone. > > I think many Solum users, and PaaS users in general, are > > single-project/single-build/simple git worklow and do not care about > gating. > > > > Agreed, this is my major concern, I also think majority of users will > > be after quick app creation from a single git repository. For those > > people having to jump through any additional hoops around gating will > > give them a barrier that will cause them to evaluate if this is the > > right solution for them. > > > > > > > > > > > > I see 2 drawbacks with Zuul : > > - Tenant Isolation : How do we allow access on zuul (and jenkins) for > > a specific tenant in isolation to the others tenants using Solum. > > > > Tenant isolation is a big problem for service providers, but maybe not > > for enterprises running their own Openstack/Solum. > > > > > > > > > > - Build customization : One of the biggest advantage of Jenkins is its > > ecosystem and the many build customization it offers. Using zuul will > > prohibit this. > > > > > > Agreed. If we make CI/CD pluggable and provide two reference > > implementations showing both use cases ( which should be achievable with > M1 workflow ). > > > > * `if it builds its good` and provide example code repos that use > > travisCI we can show external tooling CI/CD workflow. [1] > > * full code gating functionality of Gerrit->Zuul->Solum. I see this as > > external to the core of Solum with the user's source control being the > > middleware, but could be something that solum could assist with > > building ( provide heat template ). [2] > > > > [1] attached Solum-M1.png > > [2] attached Solum-Gerrit.png > > > > > > > > > > > > About Gerrit, I think it is also a little too much. Many users have > > their own reviewing system, Pull requests with github, bitbucket or > > stash, their own instance of gerrit, or even a custom git workflow. > > Gerrit would be a great feature for future versions of Solum. but only > > as an optionnal one, we should not force people into it. > > > > Agreed. The M1 workflow should make it easy to provide examples of > > plugging in common external CI/CD tooling, or running your own > Gerrit+Zuul. > > > > Using a gating system like Gerrit/Zuul could make for some very > > interesting advanced testing, for example one of the tests run could > > be to hit the solum API and deploy the application to it and provide > > the URL to reviewers, then when the code is merged it can kill that > > test. But this is just as doable as an pluggable integration as it is > > tightly > coupling Zuul to solum. > > I think it's worth noting that the things Zuul can do (outside of gating or > being > dependent on Gerrit) is allow a reasonable extensible workflow solution for > source -> outcome flows. We should be careful to separate the value zuul > brings as part of a Solum/OpenStack deployment (not inventing an > extensible workflow story for source) out from gating. > > I agree with the statement that we should not tightly couple Zuul to Solum. > The M1 workflow does not necessarily need to require zuul if the right > interaction points (which Zuul would require anyway) are exposed for a > much simpler solution. However, it would be a mistake to build a simple > service now and then to continue to expand it until it looks a lot like Zuul > without making effort to improve Zuul's multi tenancy, customizability, and > extensibility stories. There are
Re: [openstack-dev] [Solum] Question about Zuul's role in Solum
- Original Message - > From: Julien Vey < vey.jul...@gmail.com > > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org > > Date: Thursday, February 13, 2014 7:18 AM > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org > > Subject: Re: [openstack-dev] [Solum] Question about Zuul's role in Solum > > > > > Hi, > > I have some concerns about using Zuul in Solum > > > > > I agree gating is a great feature but it is not useful for every project and > as Adrian said, not understood by everyone. > I think many Solum users, and PaaS users in general, are > single-project/single-build/simple git worklow and do not care about gating. > > Agreed, this is my major concern, I also think majority of users will be > after quick app creation from a single git repository. For those people > having to jump through any additional hoops around gating will give them a > barrier that will cause them to evaluate if this is the right solution for > them. > > > > > > I see 2 drawbacks with Zuul : > - Tenant Isolation : How do we allow access on zuul (and jenkins) for a > specific tenant in isolation to the others tenants using Solum. > > Tenant isolation is a big problem for service providers, but maybe not for > enterprises running their own Openstack/Solum. > > > > > - Build customization : One of the biggest advantage of Jenkins is its > ecosystem and the many build customization it offers. Using zuul will > prohibit this. > > > Agreed. If we make CI/CD pluggable and provide two reference implementations > showing both use cases ( which should be achievable with M1 workflow ). > > * `if it builds its good` and provide example code repos that use travisCI we > can show external tooling CI/CD workflow. [1] > * full code gating functionality of Gerrit->Zuul->Solum. I see this as > external to the core of Solum with the user's source control being the > middleware, but could be something that solum could assist with building ( > provide heat template ). [2] > > [1] attached Solum-M1.png > [2] attached Solum-Gerrit.png > > > > > > About Gerrit, I think it is also a little too much. Many users have their own > reviewing system, Pull requests with github, bitbucket or stash, their own > instance of gerrit, or even a custom git workflow. > Gerrit would be a great feature for future versions of Solum. but only as an > optionnal one, we should not force people into it. > > Agreed. The M1 workflow should make it easy to provide examples of plugging > in common external CI/CD tooling, or running your own Gerrit+Zuul. > > Using a gating system like Gerrit/Zuul could make for some very interesting > advanced testing, for example one of the tests run could be to hit the solum > API and deploy the application to it and provide the URL to reviewers, then > when the code is merged it can kill that test. But this is just as doable as > an pluggable integration as it is tightly coupling Zuul to solum. I think it's worth noting that the things Zuul can do (outside of gating or being dependent on Gerrit) is allow a reasonable extensible workflow solution for source -> outcome flows. We should be careful to separate the value zuul brings as part of a Solum/OpenStack deployment (not inventing an extensible workflow story for source) out from gating. I agree with the statement that we should not tightly couple Zuul to Solum. The M1 workflow does not necessarily need to require zuul if the right interaction points (which Zuul would require anyway) are exposed for a much simpler solution. However, it would be a mistake to build a simple service now and then to continue to expand it until it looks a lot like Zuul without making effort to improve Zuul's multi tenancy, customizability, and extensibility stories. There are certainly pieces of Zuul that don't apply to most Solum workflows - it's just that we have to resist the temptation to create a standalone solution for source -> outcome flows outside of Zuul. Simple, practical, example solution for M1 without gating? Good. Building a zuul equivalent? Bad. Demonstrating a simple integration with Solum build flows that proves out Solum endpoints for receiving updates about new deployment units being available? Good. > > This also gives service providers a good way to productize Solum to different > ( or learning ) audiences. Assuming a service provider creates a product > based off Solum called 'Bananas' they could offer > > * 'Banana Lite' which will simply deploy an app (
Re: [openstack-dev] [Solum] Question about Zuul's role in Solum
Excerpts from Julien Vey's message of 2014-02-13 05:18:19 -0800: > Hi, > > I have some concerns about using Zuul in Solum > > I agree gating is a great feature but it is not useful for every project > and as Adrian said, not understood by everyone. > I think many Solum users, and PaaS users in general, are > single-project/single-build/simple git worklow and do not care about gating. > The gate can be a noop. Easier to insert more gate tests when it matters than it is to swap out technologies at that time. > I see 2 drawbacks with Zuul : > - Tenant Isolation : How do we allow access on zuul (and jenkins) for a > specific tenant in isolation to the others tenants using Solum. Same way Trove has a mysql database per tenant I presume. > - Build customization : One of the biggest advantage of Jenkins is its > ecosystem and the many build customization it offers. Using zuul will > prohibit this. Nobody is saying you can't use Jenkins. People are saying use Zuul and get more than Jenkins. But go on and use Jenkins as well. > > About Gerrit, I think it is also a little too much. Many users have their > own reviewing system, Pull requests with github, bitbucket or stash, their > own instance of gerrit, or even a custom git workflow. > Gerrit would be a great feature for future versions of Solum. but only as > an optionnal one, we should not force people into it. Agreed on that. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Question about Zuul's role in Solum
Julien Vey wrote: >About Gerrit, I think it is also a little too much. Many users have their > own reviewing system, Pull requests with github, bitbucket or stash, >their own instance of gerrit, or even a custom git workflow. >Gerrit would be a great feature for future versions of Solum. but only >as an optionnal one, we should not force people into it. I'm just an observer since I haven't managed to negotiate the CLA hurdle with my employer yet, but Gerrit seems to me to work fantastically well. If there are better options than Gerrit that people are using I'd be interested in hearing about them. I'm always interested in learning who has the best in class tool for any particular task. However I think that having multiple tools for the same job within OpenStack is going to be a bad idea that results in confusion and difficulty in cooperation. Now, if the intention is for Solum to NOT be an OpenStack project that's fine. OpenStack can use and be used by lots of projects that aren't part of it. But if someone learns the tools and processes for one OpenStack project they ought to be able to jump right into any other OpenStack project without having to worry about what code review tool, or other tools or processes are different from one to the next. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Question about Zuul's role in Solum
Hi, I have some concerns about using Zuul in Solum I agree gating is a great feature but it is not useful for every project and as Adrian said, not understood by everyone. I think many Solum users, and PaaS users in general, are single-project/single-build/simple git worklow and do not care about gating. I see 2 drawbacks with Zuul : - Tenant Isolation : How do we allow access on zuul (and jenkins) for a specific tenant in isolation to the others tenants using Solum. - Build customization : One of the biggest advantage of Jenkins is its ecosystem and the many build customization it offers. Using zuul will prohibit this. About Gerrit, I think it is also a little too much. Many users have their own reviewing system, Pull requests with github, bitbucket or stash, their own instance of gerrit, or even a custom git workflow. Gerrit would be a great feature for future versions of Solum. but only as an optionnal one, we should not force people into it. Julien 2014-02-13 5:47 GMT+01:00 Clark Boylan : > On Wed, Feb 12, 2014 at 7:25 PM, Noorul Islam K M > wrote: > > "devdatta kulkarni" writes: > > > >> Hi, > >> > >> I have been looking at Zuul for last few days and had a question > >> about its intended role within Solum. > >> > >> From what I understand, Zuul is a code gating system. > >> > >> I have been wondering if code gating is something we are considering as > a feature > >> to be provided in Solum? If yes, then Zuul is a perfect fit. > >> But if not, then we should discuss what benefits do we gain by using > Zuul > >> as an integral part of Solum. > >> > >> It feels to me that right now we are treating Zuul as a conduit for > triggering job(s) > >> that would do the following: > >> - clone/download source > >> - run tests > >> - create a deployment unit (DU) if tests pass > >> - upload DU to glance > >> - trigger the DU deployment workflow > >> > >> In the language-pack working group we have talked about being able to do > >> CI on the submitted code and building the DUs only after tests pass. > >> Now, there is a distinction between doing CI on merged code vs. > >> doing it before code is permanently merged to master/stable branches. > >> The latter is what a 'code gating' system does, and Zuul is a perfect > fit for this. > >> For the former though, using a code gating system is not be needed. > >> We can achieve the former with an API endpoint, a queue, > >> and a mechanism to trigger job(s) that perform above mentioned steps. > >> > >> I guess it comes down to Solum's vision. If the vision includes > supporting, among other things, code gating > >> to ensure that Solum-managed code is never broken, then Zuul is a > perfect fit. > >> Of course, in that situation we would want to ensure that the gating > functionality is pluggable > >> so that operators can have a choice of whether to use Zuul or something > else. > >> But if the vision is to be that part of an overall application > lifecycle management flow which deals with > >> creation and scaling of DUs/plans/assemblies but not necessarily be a > code gate, then we should re-evaluate Zuul's role > >> as an integral part of Solum. > >> > >> Thoughts? > >> > > > > Is Zuul tightly couple with launchpad? I see that most of the > > information that it displays is coming from launchpad. > > > > If it is, is it a good idea to force launchpad on users? > > > > Regards, > > Noorul > > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > I can't think of any places that Zuul requires launchpad (or displays > launchpad info for that matter). It is a bit coupled to Gerrit on one > end and Gearman on the other, but not in an extreme way (the use of > Gearman makes a bunch of sense imo, but having additional triggers > instead of just Gerrit sounds great to me). > > Clark > > ___ > 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] [Solum] Question about Zuul's role in Solum
On Wed, Feb 12, 2014 at 7:25 PM, Noorul Islam K M wrote: > "devdatta kulkarni" writes: > >> Hi, >> >> I have been looking at Zuul for last few days and had a question >> about its intended role within Solum. >> >> From what I understand, Zuul is a code gating system. >> >> I have been wondering if code gating is something we are considering as a >> feature >> to be provided in Solum? If yes, then Zuul is a perfect fit. >> But if not, then we should discuss what benefits do we gain by using Zuul >> as an integral part of Solum. >> >> It feels to me that right now we are treating Zuul as a conduit for >> triggering job(s) >> that would do the following: >> - clone/download source >> - run tests >> - create a deployment unit (DU) if tests pass >> - upload DU to glance >> - trigger the DU deployment workflow >> >> In the language-pack working group we have talked about being able to do >> CI on the submitted code and building the DUs only after tests pass. >> Now, there is a distinction between doing CI on merged code vs. >> doing it before code is permanently merged to master/stable branches. >> The latter is what a 'code gating' system does, and Zuul is a perfect fit >> for this. >> For the former though, using a code gating system is not be needed. >> We can achieve the former with an API endpoint, a queue, >> and a mechanism to trigger job(s) that perform above mentioned steps. >> >> I guess it comes down to Solum's vision. If the vision includes supporting, >> among other things, code gating >> to ensure that Solum-managed code is never broken, then Zuul is a perfect >> fit. >> Of course, in that situation we would want to ensure that the gating >> functionality is pluggable >> so that operators can have a choice of whether to use Zuul or something else. >> But if the vision is to be that part of an overall application lifecycle >> management flow which deals with >> creation and scaling of DUs/plans/assemblies but not necessarily be a code >> gate, then we should re-evaluate Zuul's role >> as an integral part of Solum. >> >> Thoughts? >> > > Is Zuul tightly couple with launchpad? I see that most of the > information that it displays is coming from launchpad. > > If it is, is it a good idea to force launchpad on users? > > Regards, > Noorul > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I can't think of any places that Zuul requires launchpad (or displays launchpad info for that matter). It is a bit coupled to Gerrit on one end and Gearman on the other, but not in an extreme way (the use of Gearman makes a bunch of sense imo, but having additional triggers instead of just Gerrit sounds great to me). Clark ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Question about Zuul's role in Solum
> On Feb 12, 2014, at 5:45 PM, "Angus Salkeld" > wrote: > > Excuse top post (web mail :() > > Can't we change our proposed workflow to match what Gerrit/Zuul are > doing? So endorse the gating workflow as "the official solum workflow". That's my preference so far. > Pros: > - we just use the current Gerrit/Zuul as-is. > - great gating system for little effort > - lots of people already helping maintain it. > - maybe infra can use solum at some point All good reasons. The last one is worth further exploration too. > Cons: > - slightly more complex workflow (we could have an option to > autoapprove?) I think with some noop techniques it his can be just as streamlined as the alternative approach. I would list an additional con: - Installation complexity and resource requirements may be bigger using this approach. It might be nice to validate and quantify this trade off to make sure it is not a showstopper. > I am not sure if the flexibility of the plan matches the reality of > gerrit/zuul. > 1 just run an assembly > (review and test are a noop, straight to merge/and run) > 2 build an image and run an assembly > 3 bulld an image, test then run an assembly > 4 review, bulld an image, test then run an assembly > > So can we short cut the workflow of our current Gerrit/Zuul to do > that? The parts that perform image builds can be jobs that Zuul initiates. I struggle to imagine that noop jobs (#1) would be difficult, and that could be our first default to keep things simple to begin with. Adding in reviews to the workflow (#4) makes complete sense, but will definitely be addressed in later milestones. If we start with Zuul to begin with, we have a good working example of how to set this up when we get to that point. Are there alternate viewpoints to consider? Thanks, Adrian > -Angus > > > From: Paul Czarkowski [paul.czarkow...@rackspace.com] > Sent: Thursday, February 13, 2014 9:44 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Solum] Question about Zuul's role in Solum > >> On 2/12/14 5:16 PM, "Roshan Agrawal" wrote: >> >> >>> -Original Message- >>> From: devdatta kulkarni [mailto:devdatta.kulka...@rackspace.com] >>> Sent: Wednesday, February 12, 2014 3:26 PM >>> To: OpenStack Development Mailing List (not for usage questions) >>> Subject: [openstack-dev] [Solum] Question about Zuul's role in Solum >>> >>> Hi, >>> >>> I have been looking at Zuul for last few days and had a question about >>> its >>> intended role within Solum. >>> >>> From what I understand, Zuul is a code gating system. >>> >>> I have been wondering if code gating is something we are considering as >>> a >>> feature to be provided in Solum? If yes, then Zuul is a perfect fit. >>> But if not, then we should discuss what benefits do we gain by using >>> Zuul as >>> an integral part of Solum. >>> >>> It feels to me that right now we are treating Zuul as a conduit for >>> triggering >>> job(s) that would do the following: >>> - clone/download source >>> - run tests >>> - create a deployment unit (DU) if tests pass >>> - upload DU to glance >>> - trigger the DU deployment workflow >>> >>> In the language-pack working group we have talked about being able to >>> do CI >>> on the submitted code and building the DUs only after tests pass. >>> Now, there is a distinction between doing CI on merged code vs. >>> doing it before code is permanently merged to master/stable branches. >>> The latter is what a 'code gating' system does, and Zuul is a perfect >>> fit for this. >>> For the former though, using a code gating system is not be needed. >>> We can achieve the former with an API endpoint, a queue, and a mechanism >>> to trigger job(s) that perform above mentioned steps. >>> >>> I guess it comes down to Solum's vision. If the vision includes >>> supporting, >>> among other things, code gating to ensure that Solum-managed code is >>> never broken, then Zuul is a perfect fit. >>> Of course, in that situation we would want to ensure that the gating >>> functionality is pluggable so that operators can have a choice of >>> whether to >>> use Zuul or something else. >>> But if the vision is to be that part of an overall application lifecycle >>> management flow which deals wi
Re: [openstack-dev] [Solum] Question about Zuul's role in Solum
"devdatta kulkarni" writes: > Hi, > > I have been looking at Zuul for last few days and had a question > about its intended role within Solum. > > From what I understand, Zuul is a code gating system. > > I have been wondering if code gating is something we are considering as a > feature > to be provided in Solum? If yes, then Zuul is a perfect fit. > But if not, then we should discuss what benefits do we gain by using Zuul > as an integral part of Solum. > > It feels to me that right now we are treating Zuul as a conduit for > triggering job(s) > that would do the following: > - clone/download source > - run tests > - create a deployment unit (DU) if tests pass > - upload DU to glance > - trigger the DU deployment workflow > > In the language-pack working group we have talked about being able to do > CI on the submitted code and building the DUs only after tests pass. > Now, there is a distinction between doing CI on merged code vs. > doing it before code is permanently merged to master/stable branches. > The latter is what a 'code gating' system does, and Zuul is a perfect fit for > this. > For the former though, using a code gating system is not be needed. > We can achieve the former with an API endpoint, a queue, > and a mechanism to trigger job(s) that perform above mentioned steps. > > I guess it comes down to Solum's vision. If the vision includes supporting, > among other things, code gating > to ensure that Solum-managed code is never broken, then Zuul is a perfect fit. > Of course, in that situation we would want to ensure that the gating > functionality is pluggable > so that operators can have a choice of whether to use Zuul or something else. > But if the vision is to be that part of an overall application lifecycle > management flow which deals with > creation and scaling of DUs/plans/assemblies but not necessarily be a code > gate, then we should re-evaluate Zuul's role > as an integral part of Solum. > > Thoughts? > Is Zuul tightly couple with launchpad? I see that most of the information that it displays is coming from launchpad. If it is, is it a good idea to force launchpad on users? Regards, Noorul ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Question about Zuul's role in Solum
Excuse top post (web mail :() Can't we change our proposed workflow to match what Gerrit/Zuul are doing? So endorse the gating workflow as "the official solum workflow". Pros: - we just use the current Gerrit/Zuul as-is. - great gating system for little effort - lots of people already helping maintain it. - maybe infra can use solum at some point Cons: - slightly more complex workflow (we could have an option to autoapprove?) I am not sure if the flexibility of the plan matches the reality of gerrit/zuul. 1 just run an assembly (review and test are a noop, straight to merge/and run) 2 build an image and run an assembly 3 bulld an image, test then run an assembly 4 review, bulld an image, test then run an assembly So can we short cut the workflow of our current Gerrit/Zuul to do that? -Angus From: Paul Czarkowski [paul.czarkow...@rackspace.com] Sent: Thursday, February 13, 2014 9:44 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum] Question about Zuul's role in Solum On 2/12/14 5:16 PM, "Roshan Agrawal" wrote: > >> -Original Message- >> From: devdatta kulkarni [mailto:devdatta.kulka...@rackspace.com] >> Sent: Wednesday, February 12, 2014 3:26 PM >> To: OpenStack Development Mailing List (not for usage questions) >> Subject: [openstack-dev] [Solum] Question about Zuul's role in Solum >> >> Hi, >> >> I have been looking at Zuul for last few days and had a question about >>its >> intended role within Solum. >> >> From what I understand, Zuul is a code gating system. >> >> I have been wondering if code gating is something we are considering as >>a >> feature to be provided in Solum? If yes, then Zuul is a perfect fit. >> But if not, then we should discuss what benefits do we gain by using >>Zuul as >> an integral part of Solum. >> >> It feels to me that right now we are treating Zuul as a conduit for >>triggering >> job(s) that would do the following: >> - clone/download source >> - run tests >> - create a deployment unit (DU) if tests pass >> - upload DU to glance >> - trigger the DU deployment workflow >> >> In the language-pack working group we have talked about being able to >>do CI >> on the submitted code and building the DUs only after tests pass. >> Now, there is a distinction between doing CI on merged code vs. >> doing it before code is permanently merged to master/stable branches. >> The latter is what a 'code gating' system does, and Zuul is a perfect >>fit for this. >> For the former though, using a code gating system is not be needed. >> We can achieve the former with an API endpoint, a queue, and a mechanism >> to trigger job(s) that perform above mentioned steps. >> >> I guess it comes down to Solum's vision. If the vision includes >>supporting, >> among other things, code gating to ensure that Solum-managed code is >> never broken, then Zuul is a perfect fit. >> Of course, in that situation we would want to ensure that the gating >> functionality is pluggable so that operators can have a choice of >>whether to >> use Zuul or something else. >> But if the vision is to be that part of an overall application lifecycle >> management flow which deals with creation and scaling of >> DUs/plans/assemblies but not necessarily be a code gate, then we should >>re- >> evaluate Zuul's role as an integral part of Solum. > >The question is: is Zuul the right tool for the code deployment workflow >you outlined above? The code deployment workflow is the higher order >need. > >The code gating functionality is also useful and potentially something we >would want to implement in Solum at some point, but the decision criteria >on what tool we use to implement the code deployment workflow depends on >how good is Zuul in helping us with the deployment workflow. > >> Thoughts? >> >> Thanks, >> Devdatta >> >> >> >> ___ >> 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 The current proposed workflow for Solum (m1) is shorthanded to be something like this 1. User writes code 2. User pushes to master branch in github 3. a github hook fires against the solum API. 4. Solum coordinates the testing/building and deplo
Re: [openstack-dev] [Solum] Question about Zuul's role in Solum
Paul, On Feb 12, 2014, at 3:44 PM, Paul Czarkowski wrote: > > > On 2/12/14 5:16 PM, "Roshan Agrawal" wrote: > >> >>> -Original Message- >>> From: devdatta kulkarni [mailto:devdatta.kulka...@rackspace.com] >>> Sent: Wednesday, February 12, 2014 3:26 PM >>> To: OpenStack Development Mailing List (not for usage questions) >>> Subject: [openstack-dev] [Solum] Question about Zuul's role in Solum >>> >>> Hi, >>> >>> I have been looking at Zuul for last few days and had a question about >>> its >>> intended role within Solum. >>> >>> From what I understand, Zuul is a code gating system. >>> >>> I have been wondering if code gating is something we are considering as >>> a >>> feature to be provided in Solum? If yes, then Zuul is a perfect fit. >>> But if not, then we should discuss what benefits do we gain by using >>> Zuul as >>> an integral part of Solum. >>> >>> It feels to me that right now we are treating Zuul as a conduit for >>> triggering >>> job(s) that would do the following: >>> - clone/download source >>> - run tests >>> - create a deployment unit (DU) if tests pass >>> - upload DU to glance >>> - trigger the DU deployment workflow >>> >>> In the language-pack working group we have talked about being able to >>> do CI >>> on the submitted code and building the DUs only after tests pass. >>> Now, there is a distinction between doing CI on merged code vs. >>> doing it before code is permanently merged to master/stable branches. >>> The latter is what a 'code gating' system does, and Zuul is a perfect >>> fit for this. >>> For the former though, using a code gating system is not be needed. >>> We can achieve the former with an API endpoint, a queue, and a mechanism >>> to trigger job(s) that perform above mentioned steps. >>> >>> I guess it comes down to Solum's vision. If the vision includes >>> supporting, >>> among other things, code gating to ensure that Solum-managed code is >>> never broken, then Zuul is a perfect fit. >>> Of course, in that situation we would want to ensure that the gating >>> functionality is pluggable so that operators can have a choice of >>> whether to >>> use Zuul or something else. >>> But if the vision is to be that part of an overall application lifecycle >>> management flow which deals with creation and scaling of >>> DUs/plans/assemblies but not necessarily be a code gate, then we should >>> re- >>> evaluate Zuul's role as an integral part of Solum. >> >> The question is: is Zuul the right tool for the code deployment workflow >> you outlined above? The code deployment workflow is the higher order >> need. >> >> The code gating functionality is also useful and potentially something we >> would want to implement in Solum at some point, but the decision criteria >> on what tool we use to implement the code deployment workflow depends on >> how good is Zuul in helping us with the deployment workflow. >> >>> Thoughts? >>> >>> Thanks, >>> Devdatta >>> >>> >>> >>> ___ >>> 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 > > > The current proposed workflow for Solum (m1) is shorthanded to be something > like this > > 1. User writes code > 2. User pushes to master branch in github > 3. a github hook fires against the solum API. > 4. Solum coordinates the testing/building and deployment of the app > > None of this seems overly suitable for zuul to me ( not without a > significant > amount of work that will be needed to customize zuul to work for us ), and > can be easily ( for certain values of easy ) achieved with solum > forking a thread to do the build ( m1 implementation ? ) or solum > sending messages to a set of worker nodes watching a queue ( marconi? Post > m1, pluggable so operator could use their existing jenkins, etc ). > > If an enterprise or provider wanted to implement code gating it would slip > in before option 1, and would be relativel
Re: [openstack-dev] [Solum] Question about Zuul's role in Solum
Dev, Thanks for raising this discussion. This is an important decision point for us. On Feb 12, 2014, at 1:25 PM, devdatta kulkarni wrote: > Hi, > > I have been looking at Zuul for last few days and had a question > about its intended role within Solum. > > From what I understand, Zuul is a code gating system. > > I have been wondering if code gating is something we are considering as a > feature > to be provided in Solum? If yes, then Zuul is a perfect fit. Although this feature is not currently scoped for our earliest milestones, it is part of our long term vision under the umbrella of "CI" and developer automation, and we should think about how to get there. > But if not, then we should discuss what benefits do we gain by using Zuul > as an integral part of Solum. > > It feels to me that right now we are treating Zuul as a conduit for > triggering job(s) > that would do the following: > - clone/download source > - run tests > - create a deployment unit (DU) if tests pass > - upload DU to glance > - trigger the DU deployment workflow > > In the language-pack working group we have talked about being able to do > CI on the submitted code and building the DUs only after tests pass. > Now, there is a distinction between doing CI on merged code vs. > doing it before code is permanently merged to master/stable branches. > The latter is what a 'code gating' system does, and Zuul is a perfect fit for > this. > For the former though, using a code gating system is not be needed. > We can achieve the former with an API endpoint, a queue, > and a mechanism to trigger job(s) that perform above mentioned steps. > > I guess it comes down to Solum's vision. If the vision includes supporting, > among other things, code gating > to ensure that Solum-managed code is never broken, then Zuul is a perfect fit. > Of course, in that situation we would want to ensure that the gating > functionality is pluggable > so that operators can have a choice of whether to use Zuul or something else. > But if the vision is to be that part of an overall application lifecycle > management flow which deals with > creation and scaling of DUs/plans/assemblies but not necessarily be a code > gate, then we should re-evaluate Zuul's role > as an integral part of Solum. I see code gating as a best practice for CI. As we begin to offer a CI experience as a default for Solum, we will want to employ a set of best practices to help those who are just starting out, and do not yet have any automation of this sort. Gating is well understood by OpenStack developers, but it's not well understood by all developers. It's actually pretty tricky to set up a complete CI system that does enter+exit gating, integrates with a review system, and leverages a build job runner like Jenkins. Because Solum is targeting the persona of "Application Developers" we want an experience that will feel natural to them. I do think there are areas where the current openstack-ci system may be streamlined for general purpose use. Gerrit has various user interface quirks, for example. We should be willing to contribute to the various projects to improve them so they are more pleasant to use. I'm reluctant to endorse an approach that involves re-creating functionality that Zuul already offers. I'd rather just leverage it. If Zuul has more features and capabilities than we need, then we should explore the possibility of turning off those features for now, and activating them when we are ready for them. If there are any tools that's are *better* fit with our long term vision compared to Zuul, then we should be willing to evaluate those. I think that if people just want generic ALM, they can stand up Jenkins (or some equivalent), and have a set of build scripts that burp out a container image and a plan file at the end, and feed that into Solum. If they are Github lovers, they can configure the post commit webhook to trigger Solum, and have Solum pick up and build the container image, and send it through the CD process. Any variety of CI systems from a long list of awesome software vendors can fit here. If they want something more comprehensive, including a full set of open source best practices by default, such as entrance and exit gating, hosted code review and collaboration, It would be really nice to have a full Zuul+Nodepool+Jenkins+Gerrit setup with some integration points where they could potentially customize it. > Thoughts? In summary, I'd prefer that we consider using Zuul from the beginning, and turn of any parts we don't need for our early releases. I'm willing to consider alternatives if they can be shown to be superior. Thanks, Adrian > > Thanks, > Devdatta > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mail
Re: [openstack-dev] [Solum] Question about Zuul's role in Solum
On 2/12/14 5:16 PM, "Roshan Agrawal" wrote: > >> -Original Message- >> From: devdatta kulkarni [mailto:devdatta.kulka...@rackspace.com] >> Sent: Wednesday, February 12, 2014 3:26 PM >> To: OpenStack Development Mailing List (not for usage questions) >> Subject: [openstack-dev] [Solum] Question about Zuul's role in Solum >> >> Hi, >> >> I have been looking at Zuul for last few days and had a question about >>its >> intended role within Solum. >> >> From what I understand, Zuul is a code gating system. >> >> I have been wondering if code gating is something we are considering as >>a >> feature to be provided in Solum? If yes, then Zuul is a perfect fit. >> But if not, then we should discuss what benefits do we gain by using >>Zuul as >> an integral part of Solum. >> >> It feels to me that right now we are treating Zuul as a conduit for >>triggering >> job(s) that would do the following: >> - clone/download source >> - run tests >> - create a deployment unit (DU) if tests pass >> - upload DU to glance >> - trigger the DU deployment workflow >> >> In the language-pack working group we have talked about being able to >>do CI >> on the submitted code and building the DUs only after tests pass. >> Now, there is a distinction between doing CI on merged code vs. >> doing it before code is permanently merged to master/stable branches. >> The latter is what a 'code gating' system does, and Zuul is a perfect >>fit for this. >> For the former though, using a code gating system is not be needed. >> We can achieve the former with an API endpoint, a queue, and a mechanism >> to trigger job(s) that perform above mentioned steps. >> >> I guess it comes down to Solum's vision. If the vision includes >>supporting, >> among other things, code gating to ensure that Solum-managed code is >> never broken, then Zuul is a perfect fit. >> Of course, in that situation we would want to ensure that the gating >> functionality is pluggable so that operators can have a choice of >>whether to >> use Zuul or something else. >> But if the vision is to be that part of an overall application lifecycle >> management flow which deals with creation and scaling of >> DUs/plans/assemblies but not necessarily be a code gate, then we should >>re- >> evaluate Zuul's role as an integral part of Solum. > >The question is: is Zuul the right tool for the code deployment workflow >you outlined above? The code deployment workflow is the higher order >need. > >The code gating functionality is also useful and potentially something we >would want to implement in Solum at some point, but the decision criteria >on what tool we use to implement the code deployment workflow depends on >how good is Zuul in helping us with the deployment workflow. > >> Thoughts? >> >> Thanks, >> Devdatta >> >> >> >> ___ >> 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 The current proposed workflow for Solum (m1) is shorthanded to be something like this 1. User writes code 2. User pushes to master branch in github 3. a github hook fires against the solum API. 4. Solum coordinates the testing/building and deployment of the app None of this seems overly suitable for zuul to me ( not without a significant amount of work that will be needed to customize zuul to work for us ), and can be easily ( for certain values of easy ) achieved with solum forking a thread to do the build ( m1 implementation ? ) or solum sending messages to a set of worker nodes watching a queue ( marconi? Post m1, pluggable so operator could use their existing jenkins, etc ). If an enterprise or provider wanted to implement code gating it would slip in before option 1, and would be relatively simple for an operator to plug in their existing code gating/review tooling (github PRs,CodeCollaborator,Crucible+Bamboo) or set up Gerrit/Zuul system: 1. User writes code 2. User runs `git review` 3. Gerrit calls zuul to run automated tests 4. Core reviewers +2 the code 5. Gerrit merges code to master branch in github 6. a github hook fires against the solum API 7. Solum coordinates the testing/building and deployment of the app ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Question about Zuul's role in Solum
> -Original Message- > From: devdatta kulkarni [mailto:devdatta.kulka...@rackspace.com] > Sent: Wednesday, February 12, 2014 3:26 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: [openstack-dev] [Solum] Question about Zuul's role in Solum > > Hi, > > I have been looking at Zuul for last few days and had a question about its > intended role within Solum. > > From what I understand, Zuul is a code gating system. > > I have been wondering if code gating is something we are considering as a > feature to be provided in Solum? If yes, then Zuul is a perfect fit. > But if not, then we should discuss what benefits do we gain by using Zuul as > an integral part of Solum. > > It feels to me that right now we are treating Zuul as a conduit for triggering > job(s) that would do the following: > - clone/download source > - run tests > - create a deployment unit (DU) if tests pass > - upload DU to glance > - trigger the DU deployment workflow > > In the language-pack working group we have talked about being able to do CI > on the submitted code and building the DUs only after tests pass. > Now, there is a distinction between doing CI on merged code vs. > doing it before code is permanently merged to master/stable branches. > The latter is what a 'code gating' system does, and Zuul is a perfect fit for > this. > For the former though, using a code gating system is not be needed. > We can achieve the former with an API endpoint, a queue, and a mechanism > to trigger job(s) that perform above mentioned steps. > > I guess it comes down to Solum's vision. If the vision includes supporting, > among other things, code gating to ensure that Solum-managed code is > never broken, then Zuul is a perfect fit. > Of course, in that situation we would want to ensure that the gating > functionality is pluggable so that operators can have a choice of whether to > use Zuul or something else. > But if the vision is to be that part of an overall application lifecycle > management flow which deals with creation and scaling of > DUs/plans/assemblies but not necessarily be a code gate, then we should re- > evaluate Zuul's role as an integral part of Solum. The question is: is Zuul the right tool for the code deployment workflow you outlined above? The code deployment workflow is the higher order need. The code gating functionality is also useful and potentially something we would want to implement in Solum at some point, but the decision criteria on what tool we use to implement the code deployment workflow depends on how good is Zuul in helping us with the deployment workflow. > Thoughts? > > Thanks, > Devdatta > > > > ___ > 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] Question about Zuul's role in Solum
Hi, I have been looking at Zuul for last few days and had a question about its intended role within Solum. >From what I understand, Zuul is a code gating system. I have been wondering if code gating is something we are considering as a feature to be provided in Solum? If yes, then Zuul is a perfect fit. But if not, then we should discuss what benefits do we gain by using Zuul as an integral part of Solum. It feels to me that right now we are treating Zuul as a conduit for triggering job(s) that would do the following: - clone/download source - run tests - create a deployment unit (DU) if tests pass - upload DU to glance - trigger the DU deployment workflow In the language-pack working group we have talked about being able to do CI on the submitted code and building the DUs only after tests pass. Now, there is a distinction between doing CI on merged code vs. doing it before code is permanently merged to master/stable branches. The latter is what a 'code gating' system does, and Zuul is a perfect fit for this. For the former though, using a code gating system is not be needed. We can achieve the former with an API endpoint, a queue, and a mechanism to trigger job(s) that perform above mentioned steps. I guess it comes down to Solum's vision. If the vision includes supporting, among other things, code gating to ensure that Solum-managed code is never broken, then Zuul is a perfect fit. Of course, in that situation we would want to ensure that the gating functionality is pluggable so that operators can have a choice of whether to use Zuul or something else. But if the vision is to be that part of an overall application lifecycle management flow which deals with creation and scaling of DUs/plans/assemblies but not necessarily be a code gate, then we should re-evaluate Zuul's role as an integral part of Solum. Thoughts? Thanks, Devdatta ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
