<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; ">
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Julien Vey <<a href="mailto:vey.julien@gmail.com">vey.julien@gmail.com</a>><br>
<span style="font-weight:bold">Reply-To: </span>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Date: </span>Thursday, February 13, 2014 7:18 AM<br>
<span style="font-weight:bold">To: </span>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [openstack-dev] [Solum] Question about Zuul's role in Solum<br>
</div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div>
<div dir="ltr">Hi,
<div><br>
</div>
<div>I have some concerns about using Zuul in Solum</div>
</div>
</div>
</div>
</blockquote>
</span><span id="OLK_SRC_BODY_SECTION">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div>
<div dir="ltr">
<div><br>
</div>
<div>I agree gating is a great feature but it is not useful for every project and as Adrian said, not understood by everyone.</div>
<div>I think many Solum users, and PaaS users in general, are single-project/single-build/simple git worklow and do not care about gating.</div>
</div>
</div>
</div>
</blockquote>
</span>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div>
<div dir="ltr">
<div><br>
</div>
<div>I see 2 drawbacks with Zuul :</div>
<div>- Tenant Isolation : How do we allow access on zuul (and jenkins) for a specific tenant in isolation to the others tenants using Solum.</div>
</div>
</div>
</div>
</blockquote>
</span>
<div><br>
</div>
<div>Tenant isolation is a big problem for service providers, but maybe not for enterprises running their own Openstack/Solum.</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div>
<div dir="ltr">
<div>- Build customization : One of the biggest advantage of Jenkins is its ecosystem and the many build customization it offers. Using zuul will prohibit this.</div>
</div>
</div>
</div>
</blockquote>
</span>
<div><br>
</div>
<div><br>
</div>
<div>Agreed. If we make CI/CD pluggable and provide two reference implementations showing both use cases ( which should be achievable with M1 workflow ).</div>
<div><br>
</div>
<div>* `if it builds its good` and provide example code repos that use travisCI we can show external tooling CI/CD workflow. [1]</div>
<div>* 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]</div>
<div><br>
</div>
<div>[1] attached Solum-M1.png</div>
<div>[2] attached Solum-Gerrit.png</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div>
<div dir="ltr">
<div><br>
</div>
<div>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.</div>
<div>Gerrit would be a great feature for future versions of Solum. but only as an optionnal one, we should not force people into it.</div>
</div>
</div>
</div>
</blockquote>
</span>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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 </div>
<div><br>
</div>
<div>* 'Banana Lite' which will simply deploy an app ( single instance free, pay for more ) from a git-push/git-pull. Only gating is 'did the build succeed'</div>
<div>* 'Banana Pro' Adds basic CI/CD flow ( Solum calls into a test framework as part of the Build )</div>
<div>* 'Banana Enterprise' Provides full code review, git hosting, automated testing (via Gerrit+github Enterprise), deploy to test instance, deploy App.</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div>
<div dir="ltr">
<div><br>
</div>
<div>Julien</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2014-02-13 5:47 GMT+01:00 Clark Boylan <span dir="ltr"><<a href="mailto:clark.boylan@gmail.com" target="_blank">clark.boylan@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div>On Wed, Feb 12, 2014 at 7:25 PM, Noorul Islam K M <<a href="mailto:noorul@noorul.com" target="_blank">noorul@noorul.com</a>> wrote:<br>
> "devdatta kulkarni" <<a href="mailto:devdatta.kulkarni@rackspace.com" target="_blank">devdatta.kulkarni@rackspace.com</a>> writes:<br>
><br>
>> Hi,<br>
>><br>
>> I have been looking at Zuul for last few days and had a question<br>
>> about its intended role within Solum.<br>
>><br>
>> From what I understand, Zuul is a code gating system.<br>
>><br>
>> I have been wondering if code gating is something we are considering as a feature<br>
>> to be provided in Solum? If yes, then Zuul is a perfect fit.<br>
>> But if not, then we should discuss what benefits do we gain by using Zuul<br>
>> as an integral part of Solum.<br>
>><br>
>> It feels to me that right now we are treating Zuul as a conduit for triggering job(s)<br>
>> that would do the following:<br>
>> - clone/download source<br>
>> - run tests<br>
>> - create a deployment unit (DU) if tests pass<br>
>> - upload DU to glance<br>
>> - trigger the DU deployment workflow<br>
>><br>
>> In the language-pack working group we have talked about being able to do<br>
>> CI on the submitted code and building the DUs only after tests pass.<br>
>> Now, there is a distinction between doing CI on merged code vs.<br>
>> doing it before code is permanently merged to master/stable branches.<br>
>> The latter is what a 'code gating' system does, and Zuul is a perfect fit for this.<br>
>> For the former though, using a code gating system is not be needed.<br>
>> We can achieve the former with an API endpoint, a queue,<br>
>> and a mechanism to trigger job(s) that perform above mentioned steps.<br>
>><br>
>> I guess it comes down to Solum's vision. If the vision includes supporting, among other things, code gating<br>
>> to ensure that Solum-managed code is never broken, then Zuul is a perfect fit.<br>
>> Of course, in that situation we would want to ensure that the gating functionality is pluggable<br>
>> so that operators can have a choice of whether to use Zuul or something else.<br>
>> But if the vision is to be that part of an overall application lifecycle management flow which deals with<br>
>> creation and scaling of DUs/plans/assemblies but not necessarily be a code gate, then we should re-evaluate Zuul's role<br>
>> as an integral part of Solum.<br>
>><br>
>> Thoughts?<br>
>><br>
><br>
> Is Zuul tightly couple with launchpad? I see that most of the<br>
> information that it displays is coming from launchpad.<br>
><br>
> If it is, is it a good idea to force launchpad on users?<br>
><br>
> Regards,<br>
> Noorul<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</div>
</div>
I can't think of any places that Zuul requires launchpad (or displays<br>
launchpad info for that matter). It is a bit coupled to Gerrit on one<br>
end and Gearman on the other, but not in an extreme way (the use of<br>
Gearman makes a bunch of sense imo, but having additional triggers<br>
instead of just Gerrit sounds great to me).<br>
<span><font color="#888888"><br>
Clark<br>
</font></span>
<div>
<div><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</blockquote>
</span>
<div><br>
</div>
<div><br>
</div>
</body>
</html>