Issue #1478

Updated by bmbouter about 8 years ago

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 --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/", line 474, in run 
     exit_code =, args) 
   File "/usr/lib/python2.7/site-packages/okaara/", line 974, in run 
     exit_code = command_or_section.execute(self.prompt, remaining_args) 
   File "/home/vagrant/devel/pulp/client_lib/pulp/client/extensions/", line 210, in execute 
     return self.method(*arg_list, **clean_kwargs) 
   File "/home/vagrant/devel/pulp_rpm/extensions_admin/pulp_rpm/extensions/admin/", 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/", line 171, in run_search 
   File "/home/vagrant/devel/pulp_rpm/extensions_admin/pulp_rpm/extensions/admin/", 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: 

       "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" 

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