Skip to content
This repository has been archived by the owner on Apr 7, 2022. It is now read-only.

[1LP][RFR] Add test coverage for BZ-1734629 and BZ-1734630 #10281

Merged
merged 1 commit into from
Aug 17, 2020
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
91 changes: 91 additions & 0 deletions cfme/tests/ansible/test_embedded_ansible_automate.py
Original file line number Diff line number Diff line change
Expand Up @@ -487,3 +487,94 @@ def test_import_domain_containing_playbook_method(request, appliance, setup_ansi
f"Playbook 'invalid_1677575.yml' not found in repository '{setup_ansible_repository.name}'"
)
view.flash.assert_message(text=error_msg, partial=True)


@pytest.mark.tier(2)
@pytest.mark.meta(automates=[1734629, 1734630])
@pytest.mark.ignore_stream("5.10")
@pytest.mark.parametrize(
("import_data", "instance"),
([DatastoreImport("bz_1734629.zip", "ansible_set_stat",
None), "CatalogItemInitialization_29"],
[DatastoreImport("bz_1734629.zip", "ansible_set_stat",
None), "CatalogItemInitialization_30"]),
ids=["object_update", "set_service_var"]
)
def test_automate_ansible_playbook_set_stats(request, appliance, setup_ansible_repository,
import_datastore, import_data, instance, dialog, catalog):
"""
Bugzilla:
1734629
1734630

Polarion:
assignee: gtalreja
initialEstimate: 1/4h
caseimportance: high
caseposneg: positive
casecomponent: Automate
startsin: 5.11
setup:
1. Enable EmbeddedAnsible server role
2. Add Ansible repo "test_playbooks_automate"
3. Go to Automation>Automate>Import/Export and import zip file (ansible_set_stats.zip)
5. Click on "Toggle All/None" and hit the submit button
6. Go to Automation>Automate>Explorer and Enable the imported domain
7. Make sure all the playbook methods have all the information (see if Repository,
Playbook and Machine credentials have values), update if needed
testSteps:
1. Create a Generic service catalog using with dialog.
1a. Select instance 'CatalogItemInitialization_29' then order service
1b. Select instance 'CatalogItemInitialization_30' then order service
2. Check automation.log from log directory
expectedResults:
1. Generic service catalog item created
2. For 1a scenario: Playbook should pass with updated status and [:config_info][:active]
and you should get logs like (https://bugzilla.redhat.com/show_bug.cgi?id=1734629#c8)
For 1b scenario: Playbook should pass, verify new value setting to service_var and
should get logs like this(https://bugzilla.redhat.com/show_bug.cgi?id=1734630#c9)
"""
entry_point = (
"Datastore",
f"{import_datastore.name}",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we really need f-string here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@digitronik Yes, it is needed here, as the variable import_datastore.name is from a fixture call import_datastore which set this variable.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think what @digitronik is getting at here is that the name attribute will resolve to a string at this line. Its redundant, but I wouldn't call it a blocker.

"Service",
"Provisioning",
"StateMachines",
"ServiceProvision_Template",
f"{instance}",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same ^^

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@digitronik Same here, as this instance variable is used to iterate two instances [CatalogItemInitialization_29, CatalogItemInitialization_30], passed through pytest parameteres.

)
catalog_item = appliance.collections.catalog_items.create(
appliance.collections.catalog_items.GENERIC,
name=fauxfactory.gen_alphanumeric(15, start="cat_item_"),
description=fauxfactory.gen_alphanumeric(15, start="item_disc_"),
display_in=True,
catalog=catalog,
dialog=dialog,
provisioning_entry_point=entry_point,
)

@request.addfinalizer
def _finalize():
if catalog.exists:
catalog.delete()
catalog_item.catalog = None
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Q: is it required? means manually setting catalog attribute to None.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes @digitronik , It is required too, as catatlog_item will be added to some catalog, and if one is deleting a catalog, then, in that case, a catalog_item has some catalog assigned, so it can't be deleted directly, and in the same way, dialog can't be deleted, because it's assigned to some catalog_item

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Gauravtalreja1 I question that logic, because setting this instance attribute on the framework doesn't change anything on MIQ itself. Its only changing the instance within the pytest session/python context. An update method would have to be called to actually modify MIQ's catalog/catalog item association.

Were you actually finding an exception during test teardown without this line? I don't see anything in the catalog_item.delete method that is checking for catalog associations.

The global fixture for catalog_item in cfme.fixtures.service_fixtures isn't making any modifications to any linked catalogs before it calls delete_if_exists.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mshriver Yes, without this line, it will fail in teardown while deleting a dialog with some AssertionError, I guess there is something, which is checking for catalog/catalog_items associations while deleting a dialog with dialog.delete_if_exists.

E AssertionError: assert_no_error: ['error:Dialog "HbIA5yO3Yr": Error during delete: Dialog cannot be deleted because it is connected to other components: ["ServiceTemplate:1 - cat_item_mjOTMB", "ServiceTemplate:1 - cat_item_mjOTMB"]']

Can you try running this test or maybe this finalizer definition? or suggest anything to workaround?

catalog_item.delete_if_exists()
dialog.delete_if_exists()

if instance == "CatalogItemInitialization_29":
map_pattern = [
'.*status = "Warn".*',
'.*"config_info"=>{"active"=>true}.*'
]
elif instance == "CatalogItemInitialization_30":
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Optional:
I think we are iterating over two instances [CatalogItemInitialization_29, CatalogItemInitialization_30] so just if-else will work.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it will definitely work, but it is intended to use elif to specify a condition to iterate over 2nd instance, as it is optional, can we use elif here?

map_pattern = ['.*:service_vars=>{"ansible_stats_var1"=>"secret"}.*']

with LogValidator(
"/var/www/miq/vmdb/log/automation.log",
matched_patterns=map_pattern
).waiting(timeout=300):
service_catalogs = ServiceCatalogs(appliance, catalog_item.catalog, catalog_item.name)
service_catalogs.order()
req_description = f"Provisioning Service [{catalog_item.name}] from [{catalog_item.name}]"
provision_request = appliance.collections.requests.instantiate(req_description)
provision_request.wait_for_request(method="ui")