James

I am on my 4th run now. 1st 2 times as you say with a repeated run. then i deleted the instack vm and started fresh for the 3rd and 4th time.

i believe it is because rabbitmq wasnt running. so between 3rd and 4th run i restarted rabbitmq. i have also discovered that the instack-install-undercloud doesnt keep logs in /var/log so it is a bit difficult to debug and have started to tee the output to log instead

anyways, i am going to undefine the instack vm now and try again

On Mon, Apr 20, 2015 at 6:52 PM, James Slagle <jslagle@redhat.com> wrote:
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@dell.com> 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@redhat.com [mailto:rdo-list-bounces@redhat.com] *On
> > Behalf Of *Mohammed Arafa
> > *Sent:* Monday, April 20, 2015 12:32 PM
> > *To:* rdo-list@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=13D642E995903C076FA394F816CC136539DBA6A32D7305539E4219F5A650358C02CA2ED9F1F26319&AspxAutoDetectCookieSupport=1>
>
>   *805010942448935*
> <https://www.redhat.com/wapps/training/certification/verify.html?certNumber=805010942448935&verify=Verify>
>
> *GR750055912MA*
> <https://candidate.peoplecert.org/ReportsLink.aspx?argType=1&id=13D642E995903C076FA394F816CC136539DBA6A32D7305539E4219F5A650358C02CA2ED9F1F26319&AspxAutoDetectCookieSupport=1>
>
> *Link to me on LinkedIn <http://www.linkedin.com/in/mohammedarafa>*

> _______________________________________________
> Rdo-list mailing list
> Rdo-list@redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list
>
> To unsubscribe: rdo-list-unsubscribe@redhat.com

--
-- James Slagle
--



--