Images created by images context cannot be passed to scenario

Bug #1503744 reported by Chris St. Pierre on 2015-10-07
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Rally
Undecided
Unassigned

Bug Description

If you create a named image with the images context, you cannot use that image name as an argument to a scenario. For instance:

NovaServers.boot_server:
- args:
    flavor:
      name: m1.small
    image:
      name: fedora-22
  context:
    images:
      image_url: http://mirror.us.leaseweb.net/fedora/linux/releases/22/Cloud/x86_64/Images/Fedora-Cloud-Base-22-20150521.x86_64.raw.xz
      image_type: raw
      image_container: bare
      image_name: fedora-22
    context:
      users:
        tenants: 2
        users_per_tenant: 2
  ...

This happens because the image is created as a non-public image in each ephemeral tenant, but ImageResourceType.transform() queries for images as the admin (i.e., in the admin context).

Unfortunately, it won't work to simply make ImageResourceType search all tenants, since the task I described above winds up creating two images named "fedora-22", and each run of the scenario must use the correct image. I think the best solution is to make preprocess() run for each scenario instead of for each task, and pass it the scenario context so that it had the non-admin creds that the scenario was being run with. That's obviously a big change, and it has a huge downside: most of the preprocessed resource types can be run just once for the entire task, not once per run. So we may need to split out two different ResourceType subclasses: one that applies per-task, and one that applies per-run.

Obviously this is a mess.

Boris Pavlovic (boris-42) wrote :

Chris,

Described workflow ahead is not what actually happens in real life.

First of all validation is executed before context classes are actually run. So at the moment of validation you don't have any images at all.

That's why during image validation we are analyzing whatever we use image_context or not. And if we are using we are expecting that we will have such image.

Here is the code:
https://github.com/openstack/rally/blob/master/rally/task/validation.py#L237

Changed in rally:
status: New → Incomplete
Chris St. Pierre (stpierre) wrote :

I've dug into this some more, and I'm not sure we're talking about the same thing. The error I'm hitting isn't in validation, but in the runner. Here's the traceback I'm getting, for instance:

[-] Invalid scenario argument: 'Image with pattern 'rally-f22' not found'
Traceback (most recent call last):
  File "/home/cstpierr/stack/rally/rally/task/engine.py", line 350, in run
    name, context_obj, kw.get("args", {}))
  File "/home/cstpierr/stack/rally/rally/task/runner.py", line 206, in run
    args = types.preprocess(name, context, args)
  File "/home/cstpierr/stack/rally/rally/task/types.py", line 63, in preprocess
    clients=clients, resource_config=resource_cfg)
  File "/home/cstpierr/stack/rally/rally/task/types.py", line 262, in transform
    typename="image")
  File "/home/cstpierr/stack/rally/rally/task/types.py", line 184, in _id_from_name
    return obj_from_name(resource_config, resources, typename).id
  File "/home/cstpierr/stack/rally/rally/task/types.py", line 127, in obj_from_name
    typename=typename.title(), pattern=pattern.pattern))
InvalidScenarioArgument: Invalid scenario argument: 'Image with pattern 'rally-f22' not found'

That's happening in @types decorator processing, and I'm pretty sure that my original explanation is correct. If I kill Rally at the point where it raises that exception (that is, I don't let it clean up), then I can see the image created in the admin user's tenant as a non-public image.

Reviewed: https://review.openstack.org/261116
Committed: https://git.openstack.org/cgit/openstack/rally/commit/?id=013792c458d9c85eebdad02b51963a855615de5c
Submitter: Jenkins
Branch: master

commit 013792c458d9c85eebdad02b51963a855615de5c
Author: Chris St. Pierre <email address hidden>
Date: Wed Dec 23 15:50:40 2015 -0600

    Images context: accept arbitrary image create args

    This deprecates the min_ram and min_disk arguments in favor of
    image_args, which lets the user specify any image creation keyword
    arguments they want.

    This provides a workaround for the bug that prevents images created in
    the images context from actually being used by letting the user
    specify that the image should be public, and thus can be used by
    scenarios running other tenants than the admin user's tenant. Also
    adds a gate job to ensure that images created by the images context
    can be used in a scenario.

    Partial-Bug: 1503744
    Change-Id: I200821f4850073990878c38f04959ecf1ff9c522

Launchpad Janitor (janitor) wrote :

[Expired for Rally because there has been no activity for 60 days.]

Changed in rally:
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers