Open Stack

You have applied an incorrect solution to the problem which is caused by
something else, and you've hit other problems further on - I'd expect
something like this.

On Tue, Apr 4, 2017 at 5:06 PM, Konstantin Raskoshnyi <konrasko at gmail.com>
wrote:

> Hm, that's weird...There's no 192.168.0.4 host in the network, after I
> added it on the router and added msqr from network 192.168.0.0/24 - all
> network checks passed, but ctrl failed on All nodes are finished. Failed
> tasks: Task[conntrackd/11] Stopping the deployment process!
>
> On Tue, Apr 4, 2017 at 4:26 PM Dmitry Sutyagin <dsutyagin at mirantis.com>
> wrote:
>
>> Konstantin,
>>
>> No, you should not need to do this, I believe something else is wrong
>> with your configuration. There potentially may be a bug in Fuel 11 though,
>> I have not tried this release, all my knowledge comes from Fuel 9 and
>> below. I'd recommend trying 9.0 release to see if the same problem shows up
>> - if not then you should file a bug here, https://bugs.launchpad.net/fuel,
>> if you get the same issue on 9.0 then it is most likely a problem with your
>> configuration for either Fuel during it's installation or for the
>> environment. Also, if your deployment got stuck at some point, then you've
>> changed some configurations and you try to continue - sometimes the state
>> of the deployment can be incorrect for continuation and you may need to
>> reset the environment before proceeding.
>>
>> On Tue, Apr 4, 2017 at 3:27 PM, Konstantin Raskoshnyi <konrasko at gmail.com
>> > wrote:
>>
>> Hi Dmitry,
>> 192.168.0.4 is inaccessible, because none of member has this Ip address,
>> that means I need to set up this ip on my router under mgmt Vlan?
>>
>> Thanks
>>
>> On Tue, Apr 4, 2017 at 3:22 PM, Dmitry Sutyagin <dsutyagin at mirantis.com>
>> wrote:
>>
>> Hi Konstantin,
>>
>> - Anyone knows why fuel slaves during deployment get 192.168.0.4 as def
>> gw?
>>
>> AFAIK this is by design - by default after deployment all nodes which
>> have public IP will use public GW to access internet; all nodes without a
>> public IP (which is the case when "Assign public network to all nodes"is
>> not selected in Networks -> Other) will use management "virtual" gateway
>> which is in turn hosted on one of the controllers as a vrouter namespace,
>> and controlled via pacemaker. So at some point during deployment the
>> gateway on the nodes changes. Controllers can have either public ip gw or
>> Fuel as their gateway, but other nodes are supposed to access internet
>> through controllers. This was introduced around MOS 6.1 or 7.0 I believe.
>>
>> - So should I manually attach interfaces in ubuntu to each node or just
>> allow internet traffic on routers from management network for example?
>> No. The error you've encountered may indicate that there is no network
>> connectivity via management network between these nodes and controllers,
>> but I'm not 100% sure, I don't remember exactly through which interface the
>> nodes try to access internet during pre-deployment network checks, but
>> logically it should be the same as when nodes are completely deployed.
>>
>> On Mon, Apr 3, 2017 at 12:15 AM, Konstantin Raskoshnyi <
>> konrasko at gmail.com> wrote:
>>
>> Hi Vidal,
>>
>> Yes, eventually I found the problem. But that's weird, actually my def
>> route to fuel server. But, at some point default gw becomes mgmt
>> 192.168.0.4 - I don't know why. So if I manually change def gw to fuel
>> master - everything works fine.
>>
>> Anyone knows why fuel slaves during deployment get 192.168.0.4 as def gw?
>>
>> Thanks
>>
>> On Mon, Apr 3, 2017 at 12:01 AM Vimal Kumar <vimal7370 at gmail.com> wrote:
>>
>> Hi,
>>
>> I faced the same issue few weeks ago while setting up a similar
>> environment. The issue then was that during the installation Fuel master
>> node ( https://docs.openstack.org/developer/fuel-docs/userdocs/fuel
>> -install-guide/install/install_set_up_fuel.html ), I had incorrectly set
>> up DHCP Gateway to the actual network gateway (see option 'c' in the table
>> in that url). It should in fact be the IP address (in PXE network) of Fuel
>> Master so that Fuel Master can forward traffic to the Internet.
>>
>> Long story short, had to reinstall Fuel Master again, and this time set
>> the DHCP Gateway correctly to the Fuel Master and this step was successful.
>>
>> On Mon, Apr 3, 2017 at 7:47 AM, Konstantin Raskoshnyi <konrasko at gmail.com
>> > wrote:
>>
>> Hi, Guys, I'm pretty new for OpenStack but,
>>
>> I set up a simple 3 node OS, Fuel tells me that I can't attach public
>> interface to Nova & Cider nodes, but after the first stage of deployment
>> Fuel just hangs up with error:
>>
>>
>> *Repo availability verification failed on following nodes Untitled
>> (dc:f6), Untitled (e4:43).*
>>
>> Of course, Nova & Cider nodes don't have any internet access since Fuel
>> explicitly denied me to attach public interfaces to my nodes
>>
>> So should I manually attach interfaces in ubuntu to each node or just
>> allow internet traffic on routers from management network for example?
>>
>> All hosts can communicate with each other via management and storage
>> networks.
>>
>> Thanks
>>
>> _______________________________________________
>> Mailing list: http://lists.openstack.org/cgi
>> -bin/mailman/listinfo/openstack
>> Post to     : openstack at lists.openstack.org
>> Unsubscribe : http://lists.openstack.org/cgi
>> -bin/mailman/listinfo/openstack
>>
>>
>>
>> _______________________________________________
>> Mailing list: http://lists.openstack.org/cgi
>> -bin/mailman/listinfo/openstack
>> Post to     : openstack at lists.openstack.org
>> Unsubscribe : http://lists.openstack.org/cgi
>> -bin/mailman/listinfo/openstack
>>
>>
>>
>>
>> --
>> Yours sincerely,
>> Dmitry Sutyagin
>> OpenStack Escalations Engineer
>> Mirantis, Inc.
>>
>>
>>
>>
>>
>> --
>> Yours sincerely,
>> Dmitry Sutyagin
>> OpenStack Escalations Engineer
>> Mirantis, Inc.
>>
>


-- 
Yours sincerely,
Dmitry Sutyagin
OpenStack Escalations Engineer
Mirantis, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20170404/90d95fe4/attachment.html>