> On Feb 12, 2014, at 5:45 PM, "Angus Salkeld" <angus.salk...@rackspace.com> > 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" <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 > > > _______________________________________________ > 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 mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev