This should be interface Vlan100 ip address 192.168.1.240 255.255.255.0 ip helper-address 192.168.1.1 no shutdown !
On Fri, Dec 18, 2015 at 3:17 PM, Alex Schultz <aschu...@mirantis.com> wrote: > > > 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 > >
__________________________________________________________________________ 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