Puppet/Kilo


 * Original session proposal: https://etherpad.openstack.org/p/puppet-paris-summit-proposal
 * Etherpad of the session: https://etherpad.openstack.org/p/puppet-openstack-paris-agenda
 * Session information: http://kilodesignsummit.sched.org/event/f9ed6b21149364e38fa4ab03b80a7d74#.VFY4__TF9lU
 * integration testing: https://groups.google.com/a/puppetlabs.com/forum/#!topic/puppet-openstack/Mr2wNC4HuZU
 * Ops session: https://etherpad.openstack.org/p/juno-summit-ops-puppet

= Agenda =
 * 1) Integration testing
 * HA
 * 1) Other topics
 * 2) OpenStackLib
 * 3) Deprection policy
 * 4) Composition Module
 * 5) Sharara Module
 * 6) Trove Module
 * 7) Unit testing (mock)
 * 8) 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
 * https://review.openstack.org/#/c/126458/
 * 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
 * multistring options (https://review.openstack.org/#/c/94112/ patch requires multistropt in nova_config)
 * need support in providers
 * or ignore it
 * action: dprince will try to :) fix upstream
 * One approach under review (adds a new provider for multiline, has some issues at present): https://review.openstack.org/#/c/129360

= Other Topics =

Other features for openstacklib/openstack_extras

 * WIP notify/{rabbitmq,qpid}.pp https://review.openstack.org/#/c/131213/
 * kill nova::rabbitmq - setting up rabbitmq server goes in a composition layer
 * creating users, vhosts goes in lib
 * WIP keystone/auth.pp https://review.openstack.org/#/c/132487/
 * ACTION: keep going! :D

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

 * mock - ability to mock classes and resources
 * http://www.slideshare.net/PuppetLabs/carlos-sanchez-25547313 begins at page 20
 * I don't see anything about mocking in this preso?
 * (http://blog.csanchez.org/2013/10/01/testing-puppet-and-hiera/)
 * expose puppet at the rspec level
 * For example, I want to mock a class or a resource that has a large number of parameters with default values - I want to be able to tell rspec-puppet to load a .pp file and give me a list of all of the classes/resources from that file, and for each class/resource, a list/hash of all of the parameters with default values

Swift

 * 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
 * action: monitor this
 * https://github.com/pandemicsyn/swift-ring-master
 * Swift 2 implemented storage policies which boils down to actually managing multiple rings. Thoughts ?

Upstream

 * 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