Ticket #353 (assigned task)

Opened 3 years ago

Last modified 3 years ago

Create Mockups for AutoQA External Dependencies

Reported by: tflink Owned by: jdulaney
Priority: minor Milestone: Self Test
Component: core Keywords:
Cc: athmane Blocked By:
Blocking:

Description (last modified by tflink) (diff)

Description

AutoQA is tightly coupled with Koji and Bobhi. This tight coupling makes it difficult to test AutoQA in isolation.

Mocking up Koji and Bodhi would help to isolate AutoQA and provide a controlled environment to run better tests. By mocking up Bodhi and Koji, we can test without modifying more than the Bodhi and Koji URLs in config files.

This feature includes creating the tools needed to mock up infrastructure but not actually running the tests.

Dependencies

In order to create an effective mock infrastructure, we need to know what we want to test which is covered in #352 (Create AutoQA Functional Test Cases) and #355 (Determine use cases for functional self tests).

The hard dependency is on #355 but #352 is related and will likely be worked in tandem.

Basic Design

Koji can be mocked up through its XML-RPC interface and Bodhi can be mocked up through its RESTful interface.

Both interfaces can be mocked up using Flask and its XML-RPC extension. Both pieces of software are in the Fedora repos.

The interfaces wouldn't be complete - just enough to get AutoQA to work.

Change History

comment:1 Changed 3 years ago by tflink

  • Milestone changed from Future tasks to Self Test

Set proper milestone

comment:2 Changed 3 years ago by jdulaney

  • Owner set to jdulaney
  • Status changed from new to assigned

comment:3 Changed 3 years ago by tflink

  • Priority changed from major to minor
  • Description modified (diff)
  • Milestone changed from Self Test to 0.6.0

Changed description to be a little more clear and to align with discussion in 0.6.0 planning meeting.

Accepted as NTH feature for 0.6.0 - changing milestone and priority to match

comment:4 Changed 3 years ago by jdulaney

Ok, the first step I think is to hash out a standard for modular tests. I think that would allow the most flexibility for dropping in tests.

I'm thinkin a config file along the lines of:

#Description of test in Human form AutoQA test (Depcheck, etc.) TestName? RPMs to pull in for this specific test Any other details that would be helpful

I think that once this gets hashed out, I can really get cranking on the rest of the test mockup.

Any thoughts on this?

comment:5 Changed 3 years ago by athmane

  • Cc athmane added

comment:6 Changed 3 years ago by kparal

  • Milestone changed from 0.6.0 to Self Test

comment:7 follow-up: ↓ 8 Changed 3 years ago by till

FYI: A test instance of Bodhi can be easily run from its SCM: https://fedorahosted.org/bodhi/wiki/Development

comment:8 in reply to: ↑ 7 Changed 3 years ago by tflink

Replying to till:

FYI: A test instance of Bodhi can be easily run from its SCM: https://fedorahosted.org/bodhi/wiki/Development

Thanks for the info. I tried that out a while back and decided that a full bodhi instance was overkill for what we need.

I could be very wrong but setting up full bodhi and koji instances in addition to filling them with the data we need would end up being more work than building the mock infrastructure.

comment:9 Changed 3 years ago by tflink

I've got very crude comment capturing working but this is going to need a lot more work before its done. Bodhi queries are proxied to the production bodhi servers so AutoQA can be configured to use a mock instance as it's bodhi server and only comments will be kept.

Code is available at https://github.com/tflink/mock_fedorainfra

Note: See TracTickets for help on using tickets.