Open Stack

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.

On Tue, Sep 29, 2015 at 10:02 AM, Samuel Bartel <samuel.bartel.pro at gmail.com
> wrote:

> it makes sense.
> We have two intersting use cases here:
> -to extend sanity test to validate plugins (see example in my previous
> email)
> -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
>
>
>
> 2015-09-28 11:06 GMT+02:00 Sheena Gregson <sgregson at mirantis.com>:
>
>> I just realized I missed this thread when Andrey responded to it –
>> apologies!
>>
>>
>>
>> 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.
>>
>>
>>
>> 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).
>>
>>
>>
>> *From:* Samuel Bartel [mailto:samuel.bartel.pro at gmail.com]
>> *Sent:* Monday, September 28, 2015 11:13 AM
>>
>> *To:* OpenStack Development Mailing List (not for usage questions) <
>> openstack-dev at lists.openstack.org>
>> *Subject:* Re: [openstack-dev] [Fuel][Plugins] add health check for
>> plugins
>>
>>
>>
>> Hi,
>>
>> Totally agree with you Andrey,
>>
>> other use cases could be :
>>
>> -for Ironic plugin, add test to validate that Ironic is properly deploy
>>
>> -for LMA plugin check that metric and log are properly collect, that elk,
>> nagios or grafana dashboard are accessible
>>
>> -for cinder netapp multi backend, check that different type of backend
>> can be crreated
>>
>> and so on
>>
>> So it would be very intersting to have enxtensibility ofr OSTF test
>>
>>
>>
>>
>>
>> Samuel
>>
>>
>>
>> 2015-09-08 0:05 GMT+02:00 Andrey Danin <adanin at mirantis.com>:
>>
>> Hi.
>>
>> Sorry for bringing this thread back from the grave but it look quite
>> interesting to me.
>>
>> Sheena, could you please explain how pre-deployment sanity checks should
>> look like? I don't get what it is.
>>
>> From the Health Check point of view plugins may be divided to two groups:
>>
>>
>> 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.
>>
>>
>> 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).
>>
>> So, all that means we need to make OSTF extendible by Fuel plugin's tests
>> eventually.
>>
>>
>>
>> On Mon, Aug 10, 2015 at 5:17 PM, Sheena Gregson <sgregson at mirantis.com>
>> wrote:
>>
>> 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?
>>
>>
>>
>> *From:* Simon Pasquier [mailto:spasquier at mirantis.com]
>> *Sent:* Monday, August 10, 2015 9:00 AM
>> *To:* OpenStack Development Mailing List (not for usage questions) <
>> openstack-dev at lists.openstack.org>
>> *Subject:* Re: [openstack-dev] [Fuel][Plugins] add health check for
>> plugins
>>
>>
>>
>> Hello Samuel,
>>
>> This looks like an interesting idea. Do you have any concrete example to
>> illustrate your point (with one of your plugins maybe)?
>>
>> BR,
>>
>> Simon
>>
>>
>>
>> On Mon, Aug 10, 2015 at 12:04 PM, Samuel Bartel <
>> samuel.bartel.pro at gmail.com> wrote:
>>
>> Hi all,
>>
>>
>>
>> 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.
>>
>> 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.
>>
>>
>>
>> What do you think about that?
>>
>>
>>
>>
>>
>> Kind regards
>>
>>
>>
>> Samuel
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> --
>>
>> Andrey Danin
>> adanin at mirantis.com
>> skype: gcon.monolake
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Andrey Danin
adanin at mirantis.com
skype: gcon.monolake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151006/f693fcc9/attachment.html>