On Fri, Dec 18, 2015 at 12:52 PM, John Menke <jmj...@gmail.com> wrote:
> Alex, > > Thanks for the reply. i was able to get around the issue. I rebooted all > my instances and the mcollective error went away. > > Yes rebooting the node will restart mcollective and cause it to reconnect. So that's one way to fix it. > mco ping from fuel now returns > > 11 time ... > 12 time ... > 13 time... > master tim... > > Now it's complaining that it can't hit some repos from the compute node. > I logged into the compute node and can ping the > repo domains...checking the nailgun and astute logs as it's asking now. > > So do your compute nodes have public access to the internet with your network configuration? If not you may need to use fuel-createmirror to create a local repository mirrors. https://docs.mirantis.com/openstack/fuel/fuel-7.0/operations.html#setting-up-local-mirrors Thanks, -Alex > On Fri, Dec 18, 2015 at 1:29 PM, Alex Schultz <aschu...@mirantis.com> > wrote: > >> Hey John, >> >> >> On Fri, Dec 18, 2015 at 11:15 AM, John Menke <jmj...@gmail.com> wrote: >> >>> >>> >>> >>> 2015-12-17 20:49:36ERR[566] Error running RPC method verify_networks: >>> Network verification not avaliable because nodes ["1"] not avaliable via >>> mcollective, trace: >>> ["/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/orchestrator.rb:196:in >>> `validate_nodes_access'", >>> "/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/orchestrator.rb:148:in >>> `check_dhcp'", >>> "/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/server/dispatcher.rb:121:in >>> `check_dhcp'", >>> "/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/server/dispatcher.rb:109:in >>> `block in verify_networks'", >>> "/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/server/dispatcher.rb:107:in >>> `each'", >>> "/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/server/dispatcher.rb:107:in >>> `verify_networks'", >>> "/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/server/server.rb:146:in >>> `dispatch_message'", >>> "/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/server/server.rb:107:in >>> `block in dispatch'", >>> "/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/server/task_queue.rb:64:in >>> `call'", >>> "/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/server/task_queue.rb:64:in >>> `block in each'", >>> "/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/server/task_queue.rb:56:in >>> `each'", >>> "/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/server/task_queue.rb:56:in >>> `each'", >>> "/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/server/server.rb:105:in >>> `each_with_index'", >>> "/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/server/server.rb:105:in >>> `dispatch'", >>> "/usr/lib64/ruby/gems/2.1.0/gems/astute-7.0.0/lib/astute/server/server.rb:89:in >>> `block in perform_main_job'"] >>> I have a new Fuel 7.0 and I am experiencing this issue when i try to run >>> verify network from the UI. >>> >>> Steps to recreate: >>> >>> 1. Install Fuel 7 via USB - verify it has access to public internet via >>> eth1 >>> 2. PXE boot my servers and they connect and get ips from fuel server >>> over eth0 >>> 3. Login to Fuel UI and create a new Environment - accept all defaults >>> 4. Provision nodes (all nodes found) using Add Node >>> 5. Click Verify Networks on the Network Tab >>> >>> The above message appears. >>> >>> I have checked dockerctl list -l to make sure all the docker instances >>> are running. Have been searching through the log files, but this is the >>> only thing i can find so far. >>> >>> >> What is the output of 'mco ping' from the fuel master? The verification >> process attempts to launch commands on the remote nodes via mcollective. So >> if they aren't responding it will fail like this. You may also want to >> check the mcollective logs on node that is failing to see if it's having >> issues communicating with the master. >> >> Also if you pop in to #fuel on freenode we can help troubleshoot further >> in realtime. >> >> Thanks, >> -Alex >> >> >>> John >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
