Paul, On Feb 12, 2014, at 3:44 PM, Paul Czarkowski <paul.czarkow...@rackspace.com> wrote:
> > > On 2/12/14 5:16 PM, "Roshan Agrawal" <roshan.agra...@rackspace.com> 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 This point of view assumes they already have a CI solution. I speak with a lot of folks out there just looking at cloud for the first time, and if you ask them are they using CI, they look at you with a blank stare, and then ask something like "C-what?". We should be prepared to help Application Developers as an entire class, not only the ones that have adopted agile, devops, and know something about CI already. Cheers, Adrian > > > _______________________________________________ > 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
