From d8cecd41241fc152a0b711519eb7ef052656fb06 Mon Sep 17 00:00:00 2001 From: Sergey Kraynev Date: Tue, 22 Dec 2015 09:54:13 -0500 Subject: [PATCH] Stop ignoring kilo release directory in tests Change-Id: I3a8044fd8f68442055dcf34e4c9b5079a91c51da --- specs/kilo/ceilometer-gnocchi-alarm.rst | 6 +++--- specs/kilo/cinder-scheduler-hints.rst | 2 +- specs/kilo/cinder-volume-type.rst | 2 +- specs/kilo/convergence-check-workflow.rst | 5 +++++ .../kilo/convergence-concurrent-workflow.rst | 5 +++++ specs/kilo/convergence-graph-progress.rst | 5 +++++ specs/kilo/convergence-prepare-traversal.rst | 5 +++++ .../kilo/convergence-resource-replacement.rst | 5 +++++ specs/kilo/convergence-resource-table.rst | 5 +++++ specs/kilo/convergence-rollback.rst | 5 +++++ specs/kilo/convergence-simulator-tests.rst | 5 +++++ specs/kilo/convergence-stack-data.rst | 5 +++++ specs/kilo/decouple-aws-os-resources.rst | 14 ++++++++----- specs/kilo/detailed-resource-show.rst | 18 +++++++++++++---- specs/kilo/digest-intrinsic-function.rst | 6 +++--- specs/kilo/environment-enhancements.rst | 7 ++++--- ...lement-instanceid-for-autoscalinggroup.rst | 20 ++++++++++--------- ...ent-instanceid-for-launchconfiguration.rst | 11 +++++----- specs/kilo/mistral-resources.rst | 7 +++++-- specs/kilo/nova-custom-constraints.rst | 4 ++-- specs/kilo/rich-network-prop.rst | 5 +++++ specs/kilo/software-config-progress.rst | 5 +++++ specs/kilo/software-config-trigger.rst | 7 ++++++- specs/kilo/software-config-zaqar.rst | 7 ++++++- specs/kilo/stack-update-restrict.rst | 10 +++++----- specs/kilo/support-cinder-api-v2.rst | 2 +- specs/kilo/trove-cluster-resource.rst | 2 +- specs/kilo/versioned-objects.rst | 8 +++++--- specs/kilo/vnc-console.rst | 6 +++++- tests/test_titles.py | 3 +-- 30 files changed, 144 insertions(+), 53 deletions(-) diff --git a/specs/kilo/ceilometer-gnocchi-alarm.rst b/specs/kilo/ceilometer-gnocchi-alarm.rst index 54a73cd6..f8c60470 100644 --- a/specs/kilo/ceilometer-gnocchi-alarm.rst +++ b/specs/kilo/ceilometer-gnocchi-alarm.rst @@ -81,7 +81,7 @@ None Usage Scenario -============== +-------------- I want to create a autoscaling group that scale down when a statistics against cpu_util of a group of vm computed by Gnocchi, reach a certain threshold:: @@ -130,7 +130,7 @@ Dependencies None -Links -===== +References +---------- * https://review.openstack.org/#/c/153291/ diff --git a/specs/kilo/cinder-scheduler-hints.rst b/specs/kilo/cinder-scheduler-hints.rst index 8adf0d74..6db212a0 100644 --- a/specs/kilo/cinder-scheduler-hints.rst +++ b/specs/kilo/cinder-scheduler-hints.rst @@ -38,7 +38,7 @@ None Usage Scenario -============== +-------------- For instance, request creation of `volume-A` on a different back-end than `volume-B` using the different_host scheduler hint:: diff --git a/specs/kilo/cinder-volume-type.rst b/specs/kilo/cinder-volume-type.rst index 0a686e82..95fcaa42 100644 --- a/specs/kilo/cinder-volume-type.rst +++ b/specs/kilo/cinder-volume-type.rst @@ -48,7 +48,7 @@ None Usage Scenario -============== +-------------- For volume creation take the volume_type to specific the lvm-driver:: diff --git a/specs/kilo/convergence-check-workflow.rst b/specs/kilo/convergence-check-workflow.rst index debf705e..ff14b8c0 100644 --- a/specs/kilo/convergence-check-workflow.rst +++ b/specs/kilo/convergence-check-workflow.rst @@ -43,6 +43,11 @@ trigger a check on any which now contain their full complement of inputs. The SyncPoint for the stack works similarly, except that when complete we notify the stack itself to mark the update as complete. +Alternatives +------------ + +None + Implementation ============== diff --git a/specs/kilo/convergence-concurrent-workflow.rst b/specs/kilo/convergence-concurrent-workflow.rst index 0c008af6..bab4f1eb 100644 --- a/specs/kilo/convergence-concurrent-workflow.rst +++ b/specs/kilo/convergence-concurrent-workflow.rst @@ -56,6 +56,11 @@ An exception to all of this is the case where the graph node is of the update type and the resource status is DELETE_IN_PROGRESS. In that case, we should simply create a replacement resource. +Alternatives +------------ + +None + Implementation ============== diff --git a/specs/kilo/convergence-graph-progress.rst b/specs/kilo/convergence-graph-progress.rst index 91920f0e..52cd6481 100644 --- a/specs/kilo/convergence-graph-progress.rst +++ b/specs/kilo/convergence-graph-progress.rst @@ -62,6 +62,11 @@ http://www.joinfu.com/2015/01/understanding-reservations-concurrency-locking-in- - which probably means adding an extra integer field that is incremented on every write (since we can't really query on a text field). +Alternatives +------------ + +None + Implementation ============== diff --git a/specs/kilo/convergence-prepare-traversal.rst b/specs/kilo/convergence-prepare-traversal.rst index 8ae1d264..86a0f299 100644 --- a/specs/kilo/convergence-prepare-traversal.rst +++ b/specs/kilo/convergence-prepare-traversal.rst @@ -56,6 +56,11 @@ row with its own newly-generated traversal ID. In this case it should roll back the database changes, by deleting any newly-created Resource rows that it added as well as all of the SyncPoints. +Alternatives +------------ + +None + Implementation ============== diff --git a/specs/kilo/convergence-resource-replacement.rst b/specs/kilo/convergence-resource-replacement.rst index 4005b605..4b979762 100644 --- a/specs/kilo/convergence-resource-replacement.rst +++ b/specs/kilo/convergence-resource-replacement.rst @@ -50,6 +50,11 @@ dependent resources will update their dependency lists. The previous resource will be visited again in the clean-up phase of the graph, at which point it will be deleted. +Alternatives +------------ + +None + Implementation ============== diff --git a/specs/kilo/convergence-resource-table.rst b/specs/kilo/convergence-resource-table.rst index b7f48304..ffd59433 100644 --- a/specs/kilo/convergence-resource-table.rst +++ b/specs/kilo/convergence-resource-table.rst @@ -45,6 +45,11 @@ https://github.com/zaneb/heat-convergence-prototype/blob/resumable/converge/reso - but those are too confusing. Once we settle on names, we should update the simulator code as well.) +Alternatives +------------ + +None + Implementation ============== diff --git a/specs/kilo/convergence-rollback.rst b/specs/kilo/convergence-rollback.rst index 86bb8138..6c1cf45f 100644 --- a/specs/kilo/convergence-rollback.rst +++ b/specs/kilo/convergence-rollback.rst @@ -45,6 +45,11 @@ successfully complete (if any) alongside the ID of the current target template the stored template IDs are overwritten in such a way that we will no longer refer to a particular Template, delete that Template from the database. +Alternatives +------------ + +None + Implementation ============== diff --git a/specs/kilo/convergence-simulator-tests.rst b/specs/kilo/convergence-simulator-tests.rst index 6d6a606e..f2408912 100644 --- a/specs/kilo/convergence-simulator-tests.rst +++ b/specs/kilo/convergence-simulator-tests.rst @@ -51,6 +51,11 @@ using testtools primitives and passing the wrappers above as globals, rather than those defined in https://github.com/zaneb/heat-convergence-prototype/blob/resumable/converge/__init__.py#L24-L41 +Alternatives +------------ + +None + Implementation ============== diff --git a/specs/kilo/convergence-stack-data.rst b/specs/kilo/convergence-stack-data.rst index f5e8db19..ec39afa9 100644 --- a/specs/kilo/convergence-stack-data.rst +++ b/specs/kilo/convergence-stack-data.rst @@ -42,6 +42,11 @@ previous traversals should stop updating the stack data. This should be achieved using the "UPDATE ... WHERE ..." form as discussed in http://www.joinfu.com/2015/01/understanding-reservations-concurrency-locking-in-nova/ +Alternatives +------------ + +None + Implementation ============== diff --git a/specs/kilo/decouple-aws-os-resources.rst b/specs/kilo/decouple-aws-os-resources.rst index 73879f03..e5cd81bf 100644 --- a/specs/kilo/decouple-aws-os-resources.rst +++ b/specs/kilo/decouple-aws-os-resources.rst @@ -23,8 +23,9 @@ Problem description The code structure of the resources folder is in some confusion. https://blueprints.launchpad.net/heat/+spec/reorganize-resources-code-structure -There is too much coupling between AWS and OS resources for reorganizing to be possible, -for example modules: wait_condition.py, instance.py, user.py and volume.py. +There is too much coupling between AWS and OS resources for reorganizing to be +possible, for example modules: wait_condition.py, instance.py, user.py and +volume.py. Proposed change =============== @@ -36,14 +37,17 @@ The new code structure will be:: |----resources |----aws |----wait_condition.py(AWS::CloudFormation::WaitCondition) - |----wait_condition_handle.py(AWS::CloudFormation::WaitConditionHandle) - |----volume.py(AWS::EC2::Volume and AWS::EC2::VolumeAttachment) + |----wait_condition_handle.py + (AWS::CloudFormation::WaitConditionHandle) + |----volume.py + (AWS::EC2::Volume and AWS::EC2::VolumeAttachment) |----user.py(AWS::IAM::User and AWS::IAM::AccessKey) |----instance.py(AWS::EC2::Instance) |----openstack |----wait_condition.py(OS::Heat::WaitCondition) |----wait_condition_handle.py(OS::Heat::WaitConditionHandle) - |----volume.py(OS::Cinder::Volume and OS::Cinder::VolumeAttachment) + |----volume.py + (OS::Cinder::Volume and OS::Cinder::VolumeAttachment) |----access_policy.py(OS::Heat::AccessPolicy) |----ha_restarter.py(OS::Heat::HARestarter) |----wait_condition.py(base module) diff --git a/specs/kilo/detailed-resource-show.rst b/specs/kilo/detailed-resource-show.rst index 9b82af31..ae84907c 100644 --- a/specs/kilo/detailed-resource-show.rst +++ b/specs/kilo/detailed-resource-show.rst @@ -46,7 +46,8 @@ and be able to look up attributes after creating their stacks even if the template author didn't think about them beforehand. Because these attributes can be retrieved either by the resource's client or by -changing the template and adding them to the outputs section, this should not pose +changing the template and adding them to the outputs section, this should not +pose any more risk of revealing sensitive data than what is already possible. This can be achieved by changing the API response to also include attributes @@ -68,9 +69,12 @@ For such resources, the API can be extended to accept a query param that will hold the names of the attributes to be retrived. Something like: # API - //stacks///resources/?with_attr=foo&with_attr=bar + + //stacks///resources/ + ?with_attr=foo&with_attr=bar # heatclient + resource-show --with-attr foo --with-attr bar However, certain clients or scripts may want to consume a given attribute @@ -79,11 +83,17 @@ things RESTful and return only the discoverable attributes of a resource; and another one that would only return the value of the requested attribute. # API - //stacks///resources//attributes - //stacks///resources//attributes/ + + //stacks///resources// + attributes + + //stacks///resources// + attributes/ # heatclient + heat resource-attributes + heat resource-attributes Alternatives diff --git a/specs/kilo/digest-intrinsic-function.rst b/specs/kilo/digest-intrinsic-function.rst index 691a976a..edd30b78 100644 --- a/specs/kilo/digest-intrinsic-function.rst +++ b/specs/kilo/digest-intrinsic-function.rst @@ -36,9 +36,9 @@ Add another class to run existing digest algorithms (e.g. MD5, SHA-512, etc) on user provided data and expose it in the HOT functions list. The class would take the name of the digest algortihm and the value to be hashed. -Python's ``hashlib`` natively supports md5, sha1 and sha2 (sha224, 256, 384, 512) -on most platforms and this will be documented as being the supported list of -algorithms. But the cloud provider may go beyond and support more algortihms +Python's ``hashlib`` natively supports md5, sha1 and sha2 (sha224, 256, 384, +512) on most platforms and this will be documented as being the supported list +of algorithms. But the cloud provider may go beyond and support more algortihms as well, since, depending on the way Python was built, ``hashlib`` can also use algorithms supported by OpenSSL. diff --git a/specs/kilo/environment-enhancements.rst b/specs/kilo/environment-enhancements.rst index 694df7fa..4b75b846 100644 --- a/specs/kilo/environment-enhancements.rst +++ b/specs/kilo/environment-enhancements.rst @@ -62,8 +62,8 @@ attributes in the outputs so they can be referenced outside of the nested stack. We should generate these attributes dynamically. -Proposed changes -================ +Proposed change +=============== 1. Add the concept of parameter_defaults to the environment. This will look like the following:: @@ -75,7 +75,8 @@ Proposed changes The behaviour of these parameters will be as follows: - if there is no parameter definition for it, it will be ignored. - these will be passed into all nested templates - - they will only be used as a default so that they can be explicitly overridden in the "parameters" section. + - they will only be used as a default so that they can be explicitly + overridden in the "parameters" section. 2. Support a specially named output to Template resources that is used for references. diff --git a/specs/kilo/implement-instanceid-for-autoscalinggroup.rst b/specs/kilo/implement-instanceid-for-autoscalinggroup.rst index a5bd6b38..0d8aace5 100644 --- a/specs/kilo/implement-instanceid-for-autoscalinggroup.rst +++ b/specs/kilo/implement-instanceid-for-autoscalinggroup.rst @@ -10,8 +10,8 @@ Implement 'InstanceId' for AutoScalingGroup https://blueprints.launchpad.net/heat/+spec/implement-instanceid-for-autoscalinggroup -We should support the 'InstanceId' for AWS::AutoScaling::AutoScalingGroup resource -to be compatible with AWSCloudFormation. +We should support the 'InstanceId' for AWS::AutoScaling::AutoScalingGroup +resource to be compatible with AWSCloudFormation. Problem description =================== @@ -31,17 +31,19 @@ Proposed change =============== 1. Change 'LaunchConfigurationName' to be an optional property 2. Add 'InstanceId' property, optional and non-updatable -3. Add validate for AWS::AutoScaling::AutoScalingGroup resource, make sure choose - one of the two properties +3. Add validate for AWS::AutoScaling::AutoScalingGroup resource, make sure + choose one of the two properties 4. Modify the _get_conf_properties() function - * if specify 'InstanceId', to get the attributes of the instance, and to make a temporary - launch config resource, and then return the resource and its properties. + * if specify 'InstanceId', to get the attributes of the instance, and + to make a temporary launch config resource, and then return the resource + and its properties. - Note that the attributes include ImageId, InstanceType, KeyName, SecurityGroups. + Note that the attributes include ImageId, InstanceType, KeyName, + SecurityGroups. - * if without 'InstanceId', using the old way to get the launch config resource and - its properties. + * if without 'InstanceId', using the old way to get the launch config + resource and its properties. Alternatives ------------ diff --git a/specs/kilo/implement-instanceid-for-launchconfiguration.rst b/specs/kilo/implement-instanceid-for-launchconfiguration.rst index 9bf89eb4..e81b5124 100644 --- a/specs/kilo/implement-instanceid-for-launchconfiguration.rst +++ b/specs/kilo/implement-instanceid-for-launchconfiguration.rst @@ -10,8 +10,8 @@ Implement 'InstanceId' for LaunchConfiguration https://blueprints.launchpad.net/heat/+spec/implement-instanceid-for-launchconfiguration -We should support the 'InstanceId' for AWS::AutoScaling::LaunchConfiguration resource -to be compatible with AWSCloudFormation. +We should support the 'InstanceId' for AWS::AutoScaling::LaunchConfiguration +resource to be compatible with AWSCloudFormation. Problem description =================== @@ -22,7 +22,8 @@ launch configuration to use settings from an existing instance, see: http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-launchconfig.html http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/create-lc-with-instanceID.html -Will be good to implement 'InstanceId' property to be compatible with AWSCloudFormation. +Will be good to implement 'InstanceId' property to be compatible with +AWSCloudFormation. Proposed change @@ -33,8 +34,8 @@ Proposed change specify 'InstanceId', the other two properties are required 4. According to the aws developer guide and implementation, allows three cases: - * Without 'InstanceId', should specify 'ImageId' and 'InstanceType' properties, - using the old way to create the new launch configuration. + * Without 'InstanceId', should specify 'ImageId' and 'InstanceType' + properties, using the old way to create the new launch configuration. * Specify 'InstanceId' only, the new launch configuration has 'ImageId', 'InstanceType', 'KeyName', and 'SecurityGroups' diff --git a/specs/kilo/mistral-resources.rst b/specs/kilo/mistral-resources.rst index be2eabd0..5fa3bd1b 100644 --- a/specs/kilo/mistral-resources.rst +++ b/specs/kilo/mistral-resources.rst @@ -98,7 +98,8 @@ There is some use cases, which should be described: When stack will created, to execute workflow run next command:: - heat resource-signal stack_name workflow_name -D 'Json-type execution input' + heat resource-signal stack_name workflow_name \ + -D 'Json-type execution input' Execution state will be available in 'executions' attribute as a dict. @@ -160,7 +161,9 @@ There is some use cases, which should be described: vm_id: $.vm_id tasks: create_server: - action: nova.servers_create name={$.vm_name} image={$.image_ref} flavor={$.flavor_ref} + action: > + nova.servers_create name={$.vm_name} image={$.image_ref} + flavor={$.flavor_ref} publish: vm_id: $.id on-success: diff --git a/specs/kilo/nova-custom-constraints.rst b/specs/kilo/nova-custom-constraints.rst index 5420dc99..c2973699 100644 --- a/specs/kilo/nova-custom-constraints.rst +++ b/specs/kilo/nova-custom-constraints.rst @@ -25,8 +25,8 @@ and apply nova flavor constraint. Problem description =================== -1. Many resources have property InstanceId/Server which related with nova server, - but until now we haven't support nova server constraints. +1. Many resources have property InstanceId/Server which related with nova + server, but until now we haven't support nova server constraints. 2. Just define nova flavor custom constraint, but not to apply it. diff --git a/specs/kilo/rich-network-prop.rst b/specs/kilo/rich-network-prop.rst index ed6f334b..d31211a7 100644 --- a/specs/kilo/rich-network-prop.rst +++ b/specs/kilo/rich-network-prop.rst @@ -161,6 +161,11 @@ Milestones Target Milestone for completion: Kilo-2 +Work Items +---------- + +Steps mentioned in section Proposed change describes the list of work items. + Dependencies ============ diff --git a/specs/kilo/software-config-progress.rst b/specs/kilo/software-config-progress.rst index 28a3c65b..1002da50 100644 --- a/specs/kilo/software-config-progress.rst +++ b/specs/kilo/software-config-progress.rst @@ -96,6 +96,11 @@ can be achieved by the hooks checking for the input ``deploy_status_aware`` being set to ``true``. Only new heat will set this input value to ``true`` so the hook can check this input and behave accordingly. +Alternatives +------------ + +None + Implementation ============== diff --git a/specs/kilo/software-config-trigger.rst b/specs/kilo/software-config-trigger.rst index 145cdeb2..733cccf4 100644 --- a/specs/kilo/software-config-trigger.rst +++ b/specs/kilo/software-config-trigger.rst @@ -85,6 +85,11 @@ This could also be an appropriate umbrella blueprint to switch to using RPC instead of full REST calls for when config and deployment resources call config and deployment APIs. +Alternatives +------------ + +None + Implementation ============== @@ -146,4 +151,4 @@ that their config trigger has started. If it is deemed inappropriate to modify EngineService.resource_signal then some alternative external polling based signaling would be required, as provided by blueprint software-config-swift-signal or blueprint -software-config-zaqar. \ No newline at end of file +software-config-zaqar. diff --git a/specs/kilo/software-config-zaqar.rst b/specs/kilo/software-config-zaqar.rst index f6956fc2..c47a64fc 100644 --- a/specs/kilo/software-config-zaqar.rst +++ b/specs/kilo/software-config-zaqar.rst @@ -55,6 +55,11 @@ that it is not necessary to create the stack users. signal_transport:AUTO will be modified so that ZAQAR_MESSAGE is the preferred method if there is a configured messaging endpoint. +Alternatives +------------ + +None + Implementation ============== @@ -96,4 +101,4 @@ heat-templates heat-config element. This could be done after blueprint software-config-trigger since that includes some refactoring which includes moving signal_transport logic from the -resource to the deployments REST API. \ No newline at end of file +resource to the deployments REST API. diff --git a/specs/kilo/stack-update-restrict.rst b/specs/kilo/stack-update-restrict.rst index 5dbe8e11..73cc6b3b 100644 --- a/specs/kilo/stack-update-restrict.rst +++ b/specs/kilo/stack-update-restrict.rst @@ -28,8 +28,8 @@ Problem description Users can (and do) worry about stack update doing wonky things. The update-preview endpoint addresses this partially by showing what will probably happen. The limitation of the preview function is that resources can raise -UpdateReplace exceptions at any time, making it impossible to be *certain* of the -results of an update until it is performed. +UpdateReplace exceptions at any time, making it impossible to be *certain* of +the results of an update until it is performed. Proposed change =============== @@ -48,9 +48,9 @@ preferences, which are nested into the keys "AutoScalingScheduledAction" and "AutoScalingRollingUpdate". CFN preferences would be unaffected by the HOT version of update policies. -A user would specify per-resource how aggressive an update can be with a resource. -The restrictions could be on updating the resource at all, or just on -destroying the resource (including UpdateReplace). +A user would specify per-resource how aggressive an update +can be with a resource. The restrictions could be on updating the resource at +all, or just on destroying the resource (including UpdateReplace). The base cases here are: diff --git a/specs/kilo/support-cinder-api-v2.rst b/specs/kilo/support-cinder-api-v2.rst index 45d2104d..f664d3a8 100644 --- a/specs/kilo/support-cinder-api-v2.rst +++ b/specs/kilo/support-cinder-api-v2.rst @@ -104,7 +104,7 @@ None References -========== +---------- * [1]: https://wiki.openstack.org/wiki/CinderAPIv2 * [2]: https://github.com/openstack/nova-specs/blob/master/specs/juno/support-cinderclient-v2.rst diff --git a/specs/kilo/trove-cluster-resource.rst b/specs/kilo/trove-cluster-resource.rst index ae67ee8b..53bf65f1 100644 --- a/specs/kilo/trove-cluster-resource.rst +++ b/specs/kilo/trove-cluster-resource.rst @@ -48,7 +48,7 @@ None Usage Scenario -============== +-------------- Create the OS::Trove::Cluster resource like this:: diff --git a/specs/kilo/versioned-objects.rst b/specs/kilo/versioned-objects.rst index 27601cf7..621f1f6e 100644 --- a/specs/kilo/versioned-objects.rst +++ b/specs/kilo/versioned-objects.rst @@ -24,9 +24,11 @@ https://blueprints.launchpad.net/heat/+spec/versioned-objects Problem description =================== -We are looking to improve the way we deal with versioning (of all sorts db/rpc/rest/templates/plugins). -Nova has come up with the idea of versioned objects, that Ironic has also now used. -This has now been proposed as an oslo library: https://review.openstack.org/#/c/127532/ +We are looking to improve the way we deal with versioning (of all sorts +db/rpc/rest/templates/plugins). +Nova has come up with the idea of versioned objects, that Ironic has also now +used. This has now been proposed as an oslo library: +https://review.openstack.org/#/c/127532/ https://etherpad.openstack.org/p/kilo-crossproject-upgrades-and-versioning diff --git a/specs/kilo/vnc-console.rst b/specs/kilo/vnc-console.rst index f0ae8f1d..f7a91266 100644 --- a/specs/kilo/vnc-console.rst +++ b/specs/kilo/vnc-console.rst @@ -29,7 +29,7 @@ We should provide a way for template developers to show console url(for example, vnc, rdp and spice) in stack outputs. Usage Scenario -============== +-------------- Get novnc console url:: @@ -92,6 +92,10 @@ to this attribute, or URLs for all supported types when no key is provided. Gracefully deal with the case when the type of the console being asked for is not available in current deployment. +Alternatives +------------ + +None Implementation ============== diff --git a/tests/test_titles.py b/tests/test_titles.py index fce8110b..8a23714f 100644 --- a/tests/test_titles.py +++ b/tests/test_titles.py @@ -20,7 +20,7 @@ import testtools def create_scenarios(): # create a set of excluded from testing directories - exclude_dirs = {'templates', 'kilo'} + exclude_dirs = {'templates', } # get whole list of sub-directories in specs directory release_names = [x.split('/')[1] for x in glob.glob('specs/*/')] # generate a list of scenarious (1 scenario - for each release) @@ -119,7 +119,6 @@ class TestTitles(testscenarios.WithScenarios, testtools.TestCase): template = f.read() base_spec = docutils.core.publish_doctree(template) expected_template_titles = self._get_titles(base_spec) - for filename, data in self._iterate_files(): spec = docutils.core.publish_doctree(data) titles = self._get_titles(spec)