Hi, I haven't played with it yet, but I would like to know what happens to overcloud nodes when you reboot/loose or break your undercloud node. Do overcloud nodes loose ip connectivity? My understanding is that overcloud nodes get dhcp from Neutron. Or do I need to have some HA for undercloud in place?

Thanks, Pedro Sousa On Mon, Apr 20, 2015 at 6:31 PM, Mohammed Arafa <mohammed.arafa(a)gmail.com&gt; wrote: > Hello all. I am currently transitioning and have 10 days available to run > with testing rdo manager. > I am offering my help with testing and documenting as needed. > > What do you guys need? > > _______________________________________________ > Rdo-list mailing list > Rdo-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe(a)redhat.com >

_______________________________________________ Rdo-list mailing list Rdo-list(a)redhat.com https://www.redhat.com/mailman/listinfo/rdo-list To unsubscribe: rdo-list-unsubscribe(a)redhat.com

On Mon, Apr 20, 2015 at 03:17:44PM -0400, Mohammed Arafa wrote: > Hello > > Currently, I am still setting up my environment. Once it is setup properly, > I will get around to your requests. > > At this very moment, I have this problem on instack-install-undercloud > > + setup-neutron -n /tmp/tmp.Kuen3PhqAF > /usr/lib/python2.7/site-packages/novaclient/v1_1/__init__.py:30: > UserWarning: Module novaclient.v1_1 is deprecated (taken as a basis for > novaclient.v2). The preferable way to get client class or object you can > find in novaclient.client module. > warnings.warn("Module novaclient.v1_1 is deprecated (taken as a basis for > " > 2015-04-20 19:00:03 - root - ERROR - Unexpected error during command > execution > Traceback (most recent call last): > File > "/usr/lib/python2.7/site-packages/os_cloud_config/cmd/setup_neutron.py", > line 77, in main > keystone_client=keystone_client) > File "/usr/lib/python2.7/site-packages/os_cloud_config/neutron.py", line > 46, in initialize_neutron > net = _create_net(neutron_client, network_desc, network_type, > admin_tenant) > File "/usr/lib/python2.7/site-packages/os_cloud_config/neutron.py", line > 95, in _create_net > return neutron.create_network({'network': network}) > File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", > line 102, in with_params > ret = self.function(instance, *args, **kwargs) > File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", > line 571, in create_network > return self.post(self.networks_path, body=body) > File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", > line 298, in post > headers=headers, params=params) > File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", > line 211, in do_request > self._handle_fault_response(status_code, replybody) > File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", > line 185, in _handle_fault_response > exception_handler_v20(status_code, des_error_body) > File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", > line 70, in exception_handler_v20 > status_code=status_code) > Conflict: Unable to create the flat network. Physical network ctlplane is > in use. > [2015-04-20 19:00:03,079] (os-refresh-config) [ERROR] during post-configure > phase. [Command '['dib-run-parts', > '/usr/libexec/os-refresh-config/post-configure.d']' returned non-zero exit > status 1] > > [2015-04-20 19:00:03,079] (os-refresh-config) [ERROR] Aborting... > > > I am using the generic instack.answers file. > > my network devices: > [stack@instack ~]$ ip addr show > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo > valid_lft forever preferred_lft forever > inet6 ::1/128 scope host > valid_lft forever preferred_lft forever > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state > UP qlen 1000 > link/ether 52:54:00:e2:71:1b brd ff:ff:ff:ff:ff:ff > inet 192.168.122.243/24 brd 192.168.122.255 scope global dynamic eth0 > valid_lft 3318sec preferred_lft 3318sec > inet6 fe80::5054:ff:fee2:711b/64 scope link > valid_lft forever preferred_lft forever > 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master > ovs-system state UP qlen 1000 > link/ether 00:0c:63:21:8e:8c brd ff:ff:ff:ff:ff:ff > 4: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN > link/ether ba:52:30:e2:e4:9f brd ff:ff:ff:ff:ff:ff > 5: br-ctlplane: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue > state UNKNOWN > link/ether 00:0c:63:21:8e:8c brd ff:ff:ff:ff:ff:ff > inet 192.0.2.1/24 brd 192.0.2.255 scope global br-ctlplane > valid_lft forever preferred_lft forever > inet6 fe80::20c:63ff:fe21:8e8c/64 scope link > valid_lft forever preferred_lft forever > 6: br-int: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN > link/ether f6:a8:58:76:12:43 brd ff:ff:ff:ff:ff:ff > 7: br-tun: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN > link/ether 76:78:4c:9e:71:4d brd ff:ff:ff:ff:ff:ff > > any help is appreciated Hi Mohammed, Thanks for offering some time to try out rdo-manager. I take it you've found the documentation[1] given the progress you've made so far. It looks like you made it through the virt-setup based on the network device output. As for the setup-neutron error, the first thing that comes to mind is if this is a clean install on the instack vm? The only reason I can think of right off as to why the ctlplane network would be in use is if neutron ports were allocated on the assigned subnet. So, I'm wondering if this a 2nd run through of instack-install-undercloud perhaps after a failed deployment? [1] https://repos.fedorapeople.org/repos/openstack-m/instack-undercloud/html/ > > On Mon, Apr 20, 2015 at 2:43 PM, <Arkady_Kanevsky(a)dell.com&gt; wrote: > > > *Dell - Internal Use - Confidential * > > > > Mohammed, > > > > Can you also test what happens when a single node undercloud comes back? > > > > Start with simple case when overcloud is fully deployed and functions. > > > > Then try restarting services in overcloud when undercloud is not there, > > > > When it is coming up, and finally when it is fully running again. > > > > For undercloud start with simple shutdown, then boot case. > > > > > > > > Then we can dive into what happens with sensu which is monitoring > > overcloud nodes, then tempest for testing overcloud, and finally ceph > > monitoring of overcloud. > > > > > > > > Thanks, > > > > Arkady > > > > > > > > *From:* rdo-list-bounces(a)redhat.com [mailto: rdo-list-bounces(a)redhat.com] *On > > Behalf Of *Mohammed Arafa > > *Sent:* Monday, April 20, 2015 12:32 PM > > *To:* rdo-list(a)redhat.com > > *Subject:* [Rdo-list] 10 days of rdo manager > > > > > > > > Hello all. I am currently transitioning and have 10 days available to run > > with testing rdo manager. > > I am offering my help with testing and documenting as needed. > > > > What do you guys need? > > > > > > -- > > > < https://candidate.peoplecert.org/ReportsLink.aspx?argType=1&id=13D642... > > > *805010942448935* > < https://www.redhat.com/wapps/training/certification/verify.html?certNumbe... > > > *GR750055912MA* > < https://candidate.peoplecert.org/ReportsLink.aspx?argType=1&id=13D642... > > > *Link to me on LinkedIn <http://www.linkedin.com/in/mohammedarafa>* > _______________________________________________ > Rdo-list mailing list > Rdo-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe(a)redhat.com -- -- James Slagle --