<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 13, 2015 at 4:54 AM, Ian Wienand <span dir="ltr"><<a href="mailto:iwienand@redhat.com" target="_blank">iwienand@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
With [1] merged, we now have people working on creating external<br>
plugins for devstack.<br></blockquote><div><br></div><div>The devstack plugin concept seems logical and useful to me.<br><br>GlusterFS Cinder CI is probably the first one implementing the plugin.<br></div><div>See <a href="https://review.openstack.org/#/c/146822/">https://review.openstack.org/#/c/146822/</a><br><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I worry about use of arbitrary external locations as plugins for gate<br>
jobs.  If a plugin is hosted externally (github, bitbucket, etc) we<br>
are introducing a whole host of problems when it is used as a gate<br>
job.  Lack of CI testing for proposed changes, uptime of the remote<br>
end, ability to accept contributions, lack of administrative access<br>
and consequent ability to recover from bad merges are a few.<br></blockquote><div><br>+1<br><br></div><div>One suggestion. The doc for creating a new project at stackforge ( <a href="http://docs.openstack.org/infra/manual/creators.html">http://docs.openstack.org/infra/manual/creators.html</a> )<br></div><div>is for a full blown community project, there are few stuff that can be skipped/ignored for the devstack-plugin case.<br><br></div><div>Would it be a good idea to take that doc and trim it to have just enuf details that apply for creating a new devstack-plugin project ?<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I would propose we agree that plugins used for gate testing should be<br>
hosted in stackforge unless there are very compelling reasons<br>
otherwise.<br>
<br>
To that end, I've proposed [2] as some concrete wording.  If we agree,<br>
I could add some sort of lint for this to project-config testing.<br></blockquote><div><br>+1<br><br></div><div>thanx,<br>deepak<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Thanks,<br>
<br>
-i<br>
<br>
[1] <a href="https://review.openstack.org/#/c/142805/" target="_blank">https://review.openstack.org/#/c/142805/</a> (Implement devstack external plugins)<br>
[2] <a href="https://review.openstack.org/#/c/146679/" target="_blank">https://review.openstack.org/#/c/146679/</a> (Document use of plugins for gate jobs)<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>
</blockquote></div><br></div></div>