<div dir="ltr">OSTF was designed to be a post-deployment test framework. We may introduce pre- and post-deployment tests in Fuel, but from an implementation point of view the "pre-" should be done by Nailgun/Astute and the "post-" by OSTF. I don't think we should mix both in OSTF.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 29, 2015 at 10:02 AM, Samuel Bartel <span dir="ltr"><<a href="mailto:samuel.bartel.pro@gmail.com" target="_blank">samuel.bartel.pro@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>it makes sense.<br></div>We have two intersting use cases here:<br></div>-to extend sanity test to validate plugins (see example in my previous email)<br></div>-to extend OSTF test to add pre-deployment check. verify network tests are not enough to ensure that a deployment will be successfull or not. there are lot of other external parameters which can impact the deployment. VMWare credentials as mentionned by sheena is a good example but there is also check DNS, NTP, Netapp credentials , Netapp or NFS server ip is reachable, external Elasticsearch or Influxdb server is reachable (in case of using  external servers for LMA) and so one. It would be very interesting to be able to add those tests for core components and plugins. it would help us to ensure user that if your tests are ok so no external elements would interfere with you deployment. it can be a verify settings test as the verify network one<br><br><br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2015-09-28 11:06 GMT+02:00 Sheena Gregson <span dir="ltr"><<a href="mailto:sgregson@mirantis.com" target="_blank">sgregson@mirantis.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div link="blue" vlink="purple" lang="EN-US"><div><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Cambria",serif;color:#1f497d">I just realized I missed this thread when Andrey responded to it – apologies!</span></p><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Cambria",serif;color:#1f497d"> </span></p><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Cambria",serif;color:#1f497d">I was thinking of things like – confirming VMware username and password are accurate, confirming that SSL certificate chain is valid, etc. – some of these are not plugin based, but I think there is value in enabling both core components and plugins to specify tests that can be run prior to deployment that will help ensure the deployment will not fail.</span></p><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Cambria",serif;color:#1f497d"> </span></p><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Cambria",serif;color:#1f497d">Does that make sense?  In this case, it is not confirming the deployment was successful (post-deployment), it is checking known parameters for validity prior to attempting to deploy (pre-deployment).</span></p><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Cambria",serif;color:#1f497d"> </span></p><p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Samuel Bartel [mailto:<a href="mailto:samuel.bartel.pro@gmail.com" target="_blank">samuel.bartel.pro@gmail.com</a>] <br><b>Sent:</b> Monday, September 28, 2015 11:13 AM</span></p><div><div><br><b>To:</b> OpenStack Development Mailing List (not for usage questions) <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br><b>Subject:</b> Re: [openstack-dev] [Fuel][Plugins] add health check for plugins</div></div><p></p><div><div><p class="MsoNormal"> </p><div><div><div><div><div><div><div><div><div><div><div><p class="MsoNormal" style="margin-bottom:12.0pt">Hi,</p></div><p class="MsoNormal">Totally agree with you Andrey,</p></div><p class="MsoNormal">other use cases could be :</p></div><p class="MsoNormal">-for Ironic plugin, add test to validate that Ironic is properly deploy</p></div><p class="MsoNormal">-for LMA plugin check that metric and log are properly collect, that elk, nagios or grafana dashboard are accessible</p></div><p class="MsoNormal">-for cinder netapp multi backend, check that different type of backend can be crreated</p></div><p class="MsoNormal" style="margin-bottom:12.0pt">and so on</p></div><p class="MsoNormal">So it would be very intersting to have enxtensibility ofr OSTF test</p></div><p class="MsoNormal"> </p></div><p class="MsoNormal"> </p></div><p class="MsoNormal">Samuel</p></div><div><p class="MsoNormal"> </p><div><p class="MsoNormal">2015-09-08 0:05 GMT+02:00 Andrey Danin <<a href="mailto:adanin@mirantis.com" target="_blank">adanin@mirantis.com</a>>:</p><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt"><div><div><div><div><div><div><p class="MsoNormal">Hi.<br><br>Sorry for bringing this thread back from the grave but it look quite interesting to me.<br><br>Sheena, could you please explain how pre-deployment sanity checks should look like? I don't get what it is.<br><br>From the Health Check point of view plugins may be divided to two groups:</p></div></div><p class="MsoNormal"><br>1) A plugin that doesn't change an already covered functionality thus doesn't require extra tests implemented. Such plugins may be Contrail and almost all SDN plugins, Glance or Cinder backend plugins, and others which don't bring any changes in OSt API or any extra OSt components.</p></div><p class="MsoNormal" style="margin-bottom:12.0pt"><br>2) A plugin that adds new elements into OSt or changes API or a standard behavior. Such plugins may be Contrail (because it actually adds Contrail Controller which may be covered by Health Check too), Cisco ASR plugin (because it always creates HA routers), some Swift plugins (we don't have Swift/S3 API covered by Health Check now at all), SR-IOV plugins (because they require special network preparation and extra drivers to be presented in an image), when a combination of different ML2 plugins or hypervisors deployed (because you need to test all network underlayers or HVs).</p></div><p class="MsoNormal" style="margin-bottom:12.0pt">So, all that means we need to make OSTF extendible by Fuel plugin's tests eventually.</p></div></div><div><div><div><p class="MsoNormal"> </p><div><p class="MsoNormal">On Mon, Aug 10, 2015 at 5:17 PM, Sheena Gregson <<a href="mailto:sgregson@mirantis.com" target="_blank">sgregson@mirantis.com</a>> wrote:</p><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt"><div><div><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Cambria",serif;color:#1f497d">I like that idea a lot – I also think there would be value in adding pre-deployment sanity checks that could be called from the Health Check screen prior to deployment.  Thoughts?</span></p><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Cambria",serif;color:#1f497d"> </span></p><p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Simon Pasquier [mailto:</span><a href="mailto:spasquier@mirantis.com" target="_blank"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">spasquier@mirantis.com</span></a><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">] <br><b>Sent:</b> Monday, August 10, 2015 9:00 AM<br><b>To:</b> OpenStack Development Mailing List (not for usage questions) <</span><a href="mailto:openstack-dev@lists.openstack.org" target="_blank"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">openstack-dev@lists.openstack.org</span></a><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">><br><b>Subject:</b> Re: [openstack-dev] [Fuel][Plugins] add health check for plugins</span></p><div><div><p class="MsoNormal"> </p><div><div><div><p class="MsoNormal">Hello Samuel,</p></div><p class="MsoNormal">This looks like an interesting idea. Do you have any concrete example to illustrate your point (with one of your plugins maybe)?</p></div><div><p class="MsoNormal">BR,</p></div><p class="MsoNormal">Simon</p></div><div><p class="MsoNormal"> </p><div><p class="MsoNormal">On Mon, Aug 10, 2015 at 12:04 PM, Samuel Bartel <<a href="mailto:samuel.bartel.pro@gmail.com" target="_blank">samuel.bartel.pro@gmail.com</a>> wrote:</p><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt"><div><div><p class="MsoNormal">Hi all,</p></div><div><p class="MsoNormal"> </p></div><div><p class="MsoNormal">actually with fuel plugins there are test for the plugins used by the CICD, but after a deployment it is not possible for the user to easily test if a plugin is crrectly deploy or not.</p></div><div><p class="MsoNormal">I am wondering if it could be interesting to improve the fuel plugin framework in order to be able to define test for each plugin which would ba dded to the health Check. the user would be able to test the plugin when testing the deployment test.</p></div><div><p class="MsoNormal"> </p></div><div><p class="MsoNormal">What do you think about that?</p></div><div><p class="MsoNormal"> </p></div><div><p class="MsoNormal"> </p></div><div><p class="MsoNormal">Kind regards</p></div><div><p class="MsoNormal"><span style="color:#888888"> </span></p></div><div><p class="MsoNormal"><span style="color:#888888">Samuel</span></p></div></div><p class="MsoNormal" style="margin-bottom:12.0pt"><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></p></blockquote></div><p class="MsoNormal"> </p></div></div></div></div></div><p class="MsoNormal" style="margin-bottom:12.0pt"><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></p></blockquote></div><p class="MsoNormal"><br><br clear="all"></p></div></div><p class="MsoNormal"><span><span style="color:#888888">-- </span></span></p><div><p class="MsoNormal"><span style="color:#888888">Andrey Danin<br></span><a href="mailto:adanin@mirantis.com" target="_blank">adanin@mirantis.com</a><span style="color:#888888"><br>skype: gcon.monolake</span></p></div></div><p class="MsoNormal" style="margin-bottom:12.0pt"><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></p></blockquote></div><p class="MsoNormal"> </p></div></div></div></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">Andrey Danin<br><a href="mailto:adanin@mirantis.com" target="_blank">adanin@mirantis.com</a><br>skype: gcon.monolake<br></div>
</div>