Jump to: navigation, search


< Puppet(Redirected from Puppet-openstack/Kilo)


  1. Integration testing
  2. HA
  3. Other topics
    1. OpenStackLib
    2. Deprection policy
    3. Composition Module
    4. Sharara Module
    5. Trove Module
    6. Unit testing (mock)
    7. Swift Module

Integration testing

Decide testing framework

  • Beaker-rspec
    • first patch in puppet-nova https://review.openstack.org/#/c/102020/
    • infra movement toward beaker-rspec
    • beaker-rspec wraps
    • beaker-rspec can do multi-node, can integrate with nodepool
    • about dox, rspec-beaker support another hypervisor like (docker, solaris, blimpy, vsphere, fusion, aix, vcloud or vagrant)
    • Action: use beaker-rspec
    • Note: desire to test for idempotency
  • Serverspec
  • Smokestack like thing
  • Rspec-system
    • puppet-ceph uses rspec-system already but rspec-system is deprecated in favor of beaker-rspec. CI is also provided by third party, not openstack-infra.
  • OpenStack tools
    • Integration with openstack community tools (tempest, grenade, smoketests, tripleO)?
    • tempest: takes too long? run subset of tests?
      • tempest is adjustable

Create test plan and decide testing policies + (unit test vs functional test)

  • Does every new change need an integration test?
  • What tests should be written for the existing code?
  • Just smoke testing?
  • What to test:
    • catalogue compilation (accross class)
    • idempotency
    • service is running
    • nova list works
  • Testing using upstream packages
    • ongoing effort
  • Validation vs Integration
  • Integration takes too long?
    • Jenkins won't report back until all tests have completed running
    • (Antoine M. could make Zuul to skip some tests and report earlier on failure, also Zuul supports retrieving tests results for a specific change before they are completed, thus they can be displayed directly in Gerrit as they run. Should be filled as feature requests to Zuul/infra folks)
    • Idea of running integration tests during the gate tests (final step)
    • better to check on more than you gate on
    • parallelize rspec run!
  • ACTION: continue work on beaker-rspec in nova, implement catalog compilation validation and idempotency validation
  • ACTION: continue work on validation in lib: https://review.openstack.org/#/c/132735/

High Availbility

  • What are current strategies/workarounds for the lack of HA support in the modules?
  • Active/Passive vs Active/Active
    • Active/Passive: Pacemaker/Corosync (blueprint: https://review.openstack.org/#/c/104861/ )
    • Wrapping HA services or adding special parameters to manifests
    • Active/Active: Galera/(controllered by pacemaker), RabbitMQ (by itself/or pacemaker), HAProxy (be aware of the select for update issue)
    • Removing nova::generic_services +1
  • Design considerations
    • How to notify service which is under arbitrary control (pacemaker)
  • Different definitions of HA for different services
  • code goes in openstack_extras
  • ACTION: mirantis will push stuff to extras
  • Beaker for HA or any other framework for testing HA

Other Topics

Other features for openstacklib/openstack_extras

Deprecation policy

  • currently when we "deprecate" we're not actually keeping old functionality which is bad
  • idea: use warn() and deprecate if possible, use fail() if there isn't a good way to deprecate without removing functionality
  • idea: use release cycle in warning so we know when to deprecate
    • A function/resource can be written to standardize the message/search string +100 (moar openstacklib!)
  • action: document deprecation policy (bodepd)

Composition module

  • successor for stackforge/puppet-openstack
  • stackforge/puppet_openstack_builder, enovance/puppet-openstack-cloud, puppetlabs/openstack, Mylezeem/Puppeels, something new?
  • what to do with puppet-openstack module
    • replace code with README saying this is deprecated, and point to existing implementations (note: the gates have been broken on this module for months, so this patch may be challenging =p. Suggest disabling the gates as we deprecate?)
    • action: make a spec for replacement (michchap)

Sahara module brought up parity with other modules

  • action: hogepodge will start pushing code
  • ubuntu not packaging sahara, but debian yes =)
  • look at merging back from fuel ? --hogepodge, xarses, holser

Trove guest-agent configuration

  • Integration with cloud-init?
  • disk-image-builder?
  • pressure trove devs to make image with trove agent available?

Unit testing


  • We probably still want to find a way to manage the ring without exported resources. Any work on that ? (fuel has something that doesn't use exported configs implmented by alex_didenko, might be worth looking at)
  • swift devs might be making swift deployable without exported resources
  • Swift 2 implemented storage policies which boils down to actually managing multiple rings. Thoughts ?


  • how to better stay in sync with upstream - new features, deprecated features, bug fixes that need to be reflected in puppet
    • e.g. keystone ports vs. urls - keystone v2.0 vs. v3 apis
    • no way to get upstream packages atm
      • how do we feed this back to the openstack dev community and distros? (release mgmt session later ... don't remember the etherpad link. ..)
    • fuel will start building packages from source shortly, the tools are in stackforge/fuel-main as part of our community CI commitment - Xarses
    • meetings now in #openstack-meeting so easier to talk to upstream devs