<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Dec 13, 2013, at 9:32 AM, Georgy Okrokvertskhov <<a href="mailto:gokrokvertskhov@mirantis.com">gokrokvertskhov@mirantis.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">Hi,<div><br></div><div>After reading the etherpad for Solum\Zuul integration I feel that I need more clarity on this. First of all, what is missed is a positioning of Zuul in overall Solum architecture. Let me explain a bit why I have this question about positioning:</div>

<div><br></div><div>1. I don't see how Solum entities (Application, Plan, Components) related to Zuul workflows.</div></div></blockquote><div><br></div><div>Applications/Plans have multiple DU’s. Each DU can come from 1 of:</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- User provided DU</div><div><span class="Apple-tab-span" style="white-space:pre">   </span>- Built from user provided binaries</div><div><span class="Apple-tab-span" style="white-space:pre">  </span>- Built from user provided source</div><div><span class="Apple-tab-span" style="white-space:pre">            </span>- from git</div><div><span class="Apple-tab-span" style="white-space:pre">           </span>- from tar etc.</div><div><br></div><div>The build of the DU is what the Zuul workflow will handle. No more. After the DU is built, the rest of Solum workflow will take it form there.</div><br><blockquote type="cite"><div dir="ltr"><div><br></div><div>2. The document describes steps starting from git commit event. It is not clear how workflow appears in Zuul configuration, what are steps which should be performed by user? During F2F discussion we agreed that user will pass some parameters required for build process and deployment process. It is not clear how these parameters will appear in Zuul workflow. </div></div></blockquote><div><br></div><div>Each DU will have its own Zuul configuration. Which can be built based on infer provided by the user about that DU.</div><div>This does not conflict with what we discussed during F2F.</div><br><blockquote type="cite"><div dir="ltr">

<div><br></div><div>3. From a security perspective it is not clear how Solum and Zuul will obtain user authentication information if entry point will be a git commit. Should user invoke Solum API somehow before git commit? Should Solum be an entry point? If Zuul will invoke Solum API for actual steps it should pass user authentication parameters too.</div></div></blockquote><div><br></div><div>Zuul would not be exposed to the user. It will be hidden behind Solum APIs. Solum will take care of user auth and can ask Zuul for info it will display back to user.</div><div>For M1, we had decided that the git repo being accessed would be a publicly visible repo with no auth requirements. But for future flows, I can see Solum gathering</div><div>the auth info and passing it to Zuul to retrieve the repo as needed.</div><br><blockquote type="cite"><div dir="ltr">

<div><br></div><div>4. If we have multiple users with multiple Application does that mean that we will have multiple Zuul instances, or we will have multiple workflows configured in Zuul? If it is a single instance will config change trig Zuul service restart? </div></div></blockquote><div><br></div><div>Single Zuul instance with multiple workflows registered. One for each DU. Zuul already supports dynamic configuration changes.</div><div><br></div><div>HTH</div><div>—Kr</div><br><blockquote type="cite"><div dir="ltr">

<div><br></div><div>Thanks</div><div>Georgy</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Dec 13, 2013 at 8:56 AM, devdatta kulkarni <span dir="ltr"><<a href="mailto:devdatta.kulkarni@rackspace.com" target="_blank">devdatta.kulkarni@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">-----Original Message-----<br>
From: "Krishna Raman" <<a href="mailto:kraman@gmail.com">kraman@gmail.com</a>><br>
Sent: Friday, December 13, 2013 9:44am<br>
To: "OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Solum] Using Zuul in the Git-pull blueprint<br>
<br>
</div><div><div class="h5">On Dec 12, 2013, at 1:39 PM, devdatta kulkarni <<a href="mailto:devdatta.kulkarni@rackspace.com">devdatta.kulkarni@rackspace.com</a>> wrote:<br>
<br>
> We followed on the Zuul question in this week's git-integration working group meeting.<br>
><br>
> mordred has created an etherpad with a high-level description of Zuul and how it might<br>
> fit with Solum't git integration workflow<br>
><br>
> <a href="https://etherpad.openstack.org/p/ZuulSolum" target="_blank">https://etherpad.openstack.org/p/ZuulSolum</a><br>
><br>
> The working group seemed to be coming to the consensus that we want to use a single workflow<br>
> engine, as far as possible, for all of Solum's workflow needs.<br>
> This brought up the question about, what are really Solum's workflow requirements.<br>
<br>
Hi<br>
<br>
I had a long conversation with Monty yesterday and we flushed out a few things I would like to run by the group.<br>
I have also included answers to the questions below.<br>
<br>
><br>
> At a high-level, I think that Solum has three different kinds of workflows.<br>
><br>
> 1) Workflow around getting user code into Solum<br>
>   - This is the git integration piece being worked out in the git-integration<br>
>     working group.<br>
<br>
This is possible using the Zuul workflows. Would potentially require a little work in Zuul.<br>
<br>
><br>
> 2) Workflow around creating language pack(s).<br>
>   - The main workflow requirement here involves ability to run tests before creating a language pack.<br>
>     There was some discussion in language-pack working group about this requirement.<br>
<br>
This is also possible using Zuul and in-fact would benefit Solum by providing config file based build workflows<br>
that could be customized by ops personelle. For e.g.. one DU might require SVN, another might require git<br>
and a jenkins CI based unit test before triggering Langpack, other DUs might wish to leverage gerrit etc.<br>
This would be possible through Zuul without having to reinvent it on the other workflow engine.<br>
<br>
><br>
> 3) Workflow around deploying created language pack(s) in order to instantiate an assembly.<br>
>   - The deployment may potentially contain several steps, some of which may be long running, such as<br>
>   populating a database. Further, there may be a need to checkpoint intermediate steps<br>
>   and retry the workflow from the failed point.<br>
<br>
This is probably not a very good fit for Zuul. It can handle simple workflow but won’t be able to do the<br>
complex checkpointing, rollback, retry logic etc.<br>
<br>
><br>
><br>
> mordred mentioned that #1 can be achieved by Zuul (both, push-to-solum and pull-by-solum)<br>
> We want to know if #2 and #3 can also be achieved by Zuul.<br>
> If not, we want to know what are the available options.<br>
><br>
> mordred, thanks for the etherpad; looking forward to the digram :)<br>
<br>
<br>
Zuul is workflow engine capable of running simple workflows. It is probably not suitable for all of Solum but would<br>
manage the source -> DU flow quite nicely. Initially my thoughts were that I wanted to avoid having 2 workflow<br>
engines in Solum but there is another way to look at it…<br>
<br>
During out F2F, we had said that we should have a Solum API where we could just post DU images. This would<br>
allow someone to build the DU outside Solum and just provide it. We could use this same API as a clean interface to<br>
separated out the DU build flow from the DU deploy flow. Once this is done, the DU build flow (#1, #2 above)<br>
could be cleanly handled by Zuul and the DU deploy flow by whatever complex engine the rest of Solum would<br>
use.<br>
<br>
</div></div>>> I think this makes sense.<br>
<br>
If I were to tie this discussion back to the various working groups and blueprints, I think<br>
the git-integration and language-pack working groups are targeting the "DU build flow" (#1 and #2).<br>
On the other hand, the work being done as part of 'specify-lang-pack' blueprint and 'pluggable-template-generation'<br>
are targeting parts of #3. There would be additional blueprints for other aspects of #3.<br>
<span class="HOEnZb"><font color="#888888"><br>
- Devdatta<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
This approach has a few advantages:<br>
        * Re-uses what Openstack already uses but its build & CI process (and potentially makes it better)<br>
        * Allows operations who deploy Solum to customize their build process without having to change Solum<br>
        * Allows us to leverage the Zuul/OpenStack-infra team to help us solve the DU build flow instead of having<br>
          to go alone<br>
<br>
—Krishna<br>
<br>
><br>
><br>
> thanks,<br>
> devkulkarni<br>
><br>
><br>
> -----Original Message-----<br>
> From: "Roshan Agrawal" <<a href="mailto:roshan.agrawal@RACKSPACE.COM">roshan.agrawal@RACKSPACE.COM</a>><br>
> Sent: Monday, December 9, 2013 10:57am<br>
> To: "OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
> Subject: Re: [openstack-dev] [Solum] Using Zuul in the Git-pull blueprint<br>
><br>
><br>
>> -----Original Message-----<br>
>> From: Krishna Raman [mailto:<a href="mailto:kraman@gmail.com">kraman@gmail.com</a>]<br>
>> Sent: Sunday, December 08, 2013 11:24 PM<br>
>> To: OpenStack Development Mailing List (not for usage questions)<br>
>> Subject: [openstack-dev] [Solum] Using Zuul in the Git-pull blueprint<br>
>><br>
>> Hi all,<br>
>><br>
>> We had a very good meeting last week around the git-pull blueprint. During<br>
>> the discussion, Monty suggested using Zuul to manage the git repository<br>
>> access and workflow.<br>
>> While he is working on sending the group a diagram and description of what<br>
>> he has in mind, I had a couple of other questions which I am hoping the<br>
>> extended group will be able to answer.<br>
>><br>
>> 1) Zuul is currently an infrastructure project.<br>
>>      - Is there anything that prevents us from using it in Solum?<br>
>>      - Does it need to be moved to a normal OpenStack project?<br>
>><br>
>> 2) Zuul provides a sort of workflow engine. This workflow engine could<br>
>> potentially be used to initiate and manage: API Post -> git flow -> lang pack<br>
>> flow.<br>
>>      - Have there been any discussion after the F2F where we have<br>
>> discussed using some other workflow engine?<br>
><br>
> There hasn't been further discussion since F2F.<br>
> Most of the processes in Solum will really be customizable workflows, and use of a generic workflow engine is definitely worth discussing. We may still use to leverage Zuul for the gerrit/git/checkin piece, but Solum will have workflow needs beyond that.<br>

><br>
>>      - Is Zuul's engine generic enough to be used in Solum? (Hoping<br>
>> Monty can help with this one)<br>
>>              - Perhaps only use it to manage the API post -> git flow<br>
>> stages?<br>
>><br>
>> Thanks<br>
>> -Krishna<br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">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>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">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>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">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>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">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>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">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><br clear="all"><div><br></div>-- <br>Georgy Okrokvertskhov<br>
Technical Program Manager,<br>Cloud and Infrastructure Services,<br>
Mirantis<br>
<a href="http://www.mirantis.com/" target="_blank">http://www.mirantis.com</a><br>
Tel. +1 650 963 9828<br>
Mob. +1 650 996 3284<br>
</div>
_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br></blockquote></div><br></body></html>