RPM Support

On an empty/fresh pulp system, run the following:

pulp-admin login -u admin -p admin

pulp-admin rpm repo create --repo-id rawhide --feed http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/x86_64/os/ --skip=rpm,drpm,erratum

pulp-admin rpm repo sync run --repo-id rawhide

Now try to search for all units of type distribution by running:

pulp-admin -vv rpm repo content distribution --repo-id rawhide

You'll receive a traceback as pulp-admin tries to parse the results:

Traceback (most recent call last):
  File "/home/vagrant/devel/pulp/client_lib/pulp/client/extensions/core.py", line 474, in run
    exit_code = Cli.run(self, args)
  File "/usr/lib/python2.7/site-packages/okaara/cli.py", line 974, in run
    exit_code = command_or_section.execute(self.prompt, remaining_args)
  File "/home/vagrant/devel/pulp/client_lib/pulp/client/extensions/extensions.py", line 210, in execute
    return self.method(*arg_list, **clean_kwargs)
  File "/home/vagrant/devel/pulp_rpm/extensions_admin/pulp_rpm/extensions/admin/contents.py", line 337, in distribution
    self.run_search([TYPE_DISTRIBUTION], self.write_distro, **kwargs)
  File "/home/vagrant/devel/pulp_rpm/extensions_admin/pulp_rpm/extensions/admin/contents.py", line 171, in run_search
    out_func(units)
  File "/home/vagrant/devel/pulp_rpm/extensions_admin/pulp_rpm/extensions/admin/contents.py", line 356, in write_distro
    'id': distro['id'],
KeyError: 'id'

The issue is not in Pulp admin. The data returned by the server is not correctly transforming the 'distribution_id' field back into the expected 'id' field. See this snip of data returned:

<snip>
      "family": "Fedora", 
      "distribution_id": "ks-Fedora--rawhide-x86_64", 
      "timestamp": 1451988072.6876094, 
      "_last_updated": 1452026990, 
      "packagedir": "", 
      "variant": "", 
      "downloaded": true, 
      "version": "rawhide", 
      "version_sort_index": "$rawhide", 
      "pulp_user_metadata": {}, 
      "_content_type_id": "distribution", 
      "_id": "4432836c-b6f4-45ea-b579-1ae1350a7ff9", 
      "arch": "x86_64", 
      "_ns": "units_distribution"
</snip>

The field renaming occurs with the 2.8.0 release so it is new since then. The fix is the have the server transform the renamed fields correctly.