1) Create sync plan 2) Disable said sync plan 3) Create new product, set sync plan from step (1) to the product. 4) Try to create docker/yum repository in the product it will fail with error - undefined method `iso8601' for nil:NilClass I see that an incomplete repo get created in the database, after above error it does not allow to create repo with same name. Under Repositories tab for the product we can not see any repo listed. This issue is because the sync plan is disabled. "Sync Enabled - No "
Created redmine issue http://projects.theforeman.org/issues/18036 from this bug
Hi Mike, I was not able to reproduce the error with the scenario described on Satellite 6.2.6 or upstream. Would it be possible to get a foreman-debug that includes the reproducer? Thanks!
Brad, I reproduced it easily on 6.2.6: 2017-01-16 18:37:55 [app] [I] Started POST "/katello/api/v2/repositories?organization_id=30" for 10.10.116.61 at 2017-01-16 18:37:55 -0500 2017-01-16 18:37:55 [app] [I] Processing by Katello::Api::V2::RepositoriesController#create as JSON 2017-01-16 18:37:55 [app] [I] Parameters: {"product_id"=>"547", "unprotected"=>true, "checksum_type"=>nil, "download_policy"=>"", "mirror_on_sync"=>true, "name"=>"docker-6", "label"=>"docker-6", "content_type"=>"docker", "url"=>"https://registry-1.docker.io", "docker_upstream_name"=>"busybox", "organization_id"=>"30", "api_version"=>"v2", "repository"=>{"name"=>"docker-6", "label"=>"docker-6", "url"=>"https://registry-1.docker.io", "unprotected"=>true, "content_type"=>"docker", "product_id"=>"547", "checksum_type"=>nil, "docker_upstream_name"=>"busybox", "mirror_on_sync"=>true, "download_policy"=>""}} 2017-01-16 18:37:55 [foreman-tasks/action] [E] undefined method `iso8601' for nil:NilClass (NoMethodError) | /opt/theforeman/tfm/root/usr/share/gems/gems/katello-3.0.0.90/app/models/katello/sync_plan.rb:57:in `schedule_format' | /opt/theforeman/tfm/root/usr/share/gems/gems/katello-3.0.0.90/app/lib/actions/pulp/repos/update.rb:14:in `block in plan' | /opt/rh/rh-ror41/root/usr/share/gems/gems/activerecord-4.1.5/lib/active_record/relation/delegation.rb:46:in `each' | /opt/rh/rh-ror41/root/usr/share/gems/gems/activerecord-4.1.5/lib/active_record/relation/delegation.rb:46:in `each' | /opt/theforeman/tfm/root/usr/share/gems/gems/katello-3.0.0.90/app/lib/actions/pulp/repos/update.rb:8:in `plan' | /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-0.8.16/lib/dynflow/action.rb:461:in `block (3 levels) in execute_plan' | /opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-0.8.16/lib/dynflow/middleware/stack.rb:26:in `call'
*** Bug 1413777 has been marked as a duplicate of this bug. ***
I am attaching a hotfix that will prevent from the nil pointer exception. Usage (tarball extraction): tar -xzf satellite-hotfix-20170101-abcdef1.tar.gz cd satellite-hotfix-20170101-abcdef1 Usage (dry run): ./satellite-hotfix -n 1415073 Usage: ./satellite-hotfix 1415073 Revert a hotfix: ./satellite-hotfix -r 1415073 List all avaiable hotfixes: ./satellite-hotfix The numbers are real Red Hat Bugzilla numbers. All backup and reject files are save in backups/ sub-directory. Please keep the tarball for possible reverting of the change in the future. If patching fails, revert immediately and send us back the output. After each Satellite update, this hotfix process must be repeated if the updated does not include the bugfix yet. If system-wide Ruby is not installed for some reason, use Satellite Foreman Ruby software collection: scl enable rh-ruby22 -- ./satellite-hotfix -h To find out Ruby versions available do: ls /opt/*/*ruby* -d
Created attachment 1243856 [details] Hotfix patch tarball
@Beat, this is interesting (multiple directories), there must be some files left after upgrade, can you please share output of: find /opt/theforeman/tfm/root/usr/share/gems/gems/katello-3* thanks!
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/18036 has been resolved.
Please add verifications steps for this bug to help QE verify
Created attachment 1257214 [details] Hotfix - updated version Usage (tarball extraction): tar -xzf satellite-hotfix-20170101-abcdef1.tar.gz cd satellite-hotfix-20170101-abcdef1 Usage (dry run): ./satellite-hotfix -n 1234567 Usage: ./satellite-hotfix 1234567 Revert a hotfix: ./satellite-hotfix -r 1234567 List all available hotfixes: ./satellite-hotfix The numbers are real Red Hat Bugzilla numbers. All backup and reject files are save in backups/ sub-directory. Please keep the tarball for possible reverting of the change in the future. If patching fails, revert immediately and report the output. After each Satellite update, this hotfix process must be repeated if the updated does not include the bugfix yet, search in errata notes for bugzilla numbers to confirm. Hotfixes are distributed in tarballs with date timestamps, new tarball obsoletes the old one and includes all previous patches. If system-wide Ruby is not installed for some reason, use Satellite Foreman Ruby software collection: scl enable rh-ruby22 -- ./satellite-hotfix -h To find out Ruby versions available do: ls /opt/*/*ruby* -d
Hi Partha, I'm not able to verify on 6.2.9-1 as an attempt to disable a sync plan fails for me with "An error occurred saving the Sync Plan: base Start Date and Time can't be blank". The Start Date turns to "Invalid Date" when trying to disable sync (see attached image). Could this be caused by changes made for this bug, or do we need to file separate one? Will attach a production log.
Created attachment 1266865 [details] screenshot-syncplan
Created attachment 1266866 [details] prodlog
By setting the user timezone to EDT I'm able to work around the issue from comment #7. Checked on satellite-6.2.9-2.0, it is now possible to create both yum and docker repository in product associated with disabled syncplan.
(In reply to Peter Ondrejka from comment #30) > By setting the user timezone to EDT I'm able to work around the issue from > comment #7. I mean comment #27
I have filed a new bz to address the issue in comment 27 https://bugzilla.redhat.com/show_bug.cgi?id=1438845 since its not a regression, Temporary Workaround for any one encountering this Goto "<Username> -> My Accounts" and temporarily change the language to English. Seems to remedy this issue.
moving to verified as per comment #30
More proper Temporary work around is change the time zone preferences to use UTC.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:1191