We can finally close this thread out. Now that we are up and running on 2.0.0 and not crashing we have been able to resolve our remaining issues. We are now successfully running an OpenStack environment and are able to deploy instances successfully. Our remaining issue from yesterday was solved when an error was identified on our network controller system. We had mistakenly entered a random character in the quantum metadata configuration file. Removing that extraneous character and restarting the service allowed everything to come online and begin working successfully.
Have a great day all! On Thu, Jan 23, 2014 at 11:13 AM, Travis Wilson <cloudtester1...@gmail.com>wrote: > Okay, good news. I was able to get my br-tun interfaces back online and > can confirm that we are still not crashing. I still can't get my instances > to get IPs yet, but working to get that fixed next. Thank you. > > > On Thu, Jan 23, 2014 at 9:27 AM, Travis Wilson > <cloudtester1...@gmail.com>wrote: > >> Okay, I may have spoken too soon. On further investigation of my >> instances not working issue I discovered this morning that after my >> upgrades yesterday my br-tun instances had been removed from both my >> network and compute nodes. I suspect that is why 1.9.3 and 2.0.0 didn't >> crash initially for me. I'm attempting to get those back online today. Once >> I have them recreated I'll report back on whether the new versions actually >> solved my issues. My apologies, I totally missed the fact that they were >> missing initially. >> >> Thank you. >> >> >> On Wed, Jan 22, 2014 at 3:01 PM, Jesse Gross <je...@nicira.com> wrote: >> >>> Hmm, that's interesting. I'm glad that 1.9.3 fixed the problem >>> although I didn't see any changes from 1.9 that I would expect to >>> resolve this. However, 2.0 has a much simpler tunneling stack so I >>> would expect that to be more reliable. >>> >>> On Wed, Jan 22, 2014 at 11:25 AM, Travis Wilson >>> <cloudtester1...@gmail.com> wrote: >>> > Good day again Jesse. >>> > >>> > I wanted to provide you and the group with an update on our issue. We >>> tried >>> > several times to get a kdump out of the system but never were able to >>> > successfully get that to work. Based on that we decided to take a look >>> at >>> > the newer versions of Open vSwitch as you had mentioned that those >>> might >>> > improve the issue we were seeing. Following this guide >>> > ( >>> https://github.com/mininet/mininet/wiki/Installing-new-version-of-Open-vSwitch >>> ) >>> > I initially downloaded and installed version 1.93 of Open vSwitch. I >>> don't >>> > know what it fixed, but as soon as that version was loaded I was able >>> to >>> > start instances without the network or the compute nodes crashing. I so >>> > still have other deployment issues, but at least the vSwitch issue >>> seemed to >>> > be resolved. >>> > >>> > Since 1.9.3 was working I decided to just go ahead and upgrade both of >>> the >>> > nodes running Open vSwitch to 2.0.0 so that we are running with the >>> latest >>> > and greatest edition on them. So far no additional crashes have >>> occurred. >>> > >>> > As soon as time allows I will load the 1.9.0 edition on my home system >>> and >>> > reproduce the original issue I saw and see if I can get a kdump from >>> it, but >>> > for now the newer editions have solved my immediate issues. >>> > >>> > Thank you again for all of your time investigating and assisting me >>> with >>> > these issues. It is appreciated. >>> > >>> > Have a great week! >>> > >>> > >>> > On Fri, Jan 17, 2014 at 12:09 PM, Jesse Gross <je...@nicira.com> >>> wrote: >>> >> >>> >> Thanks, this is useful. >>> >> >>> >> If you have the binary and can use gdb to find what line is causing >>> the >>> >> problem based on the instruction pointer, that would be very helpful. >>> I >>> >> agree that it seems unlikely that this is memory corruption. >>> >> >>> >> On Fri, Jan 17, 2014 at 5:51 AM, Travis Wilson < >>> cloudtester1...@gmail.com> >>> >> wrote: >>> >>> >>> >>> Good day. >>> >>> >>> >>> So I am working with one of our internal Linux resources trying to >>> get >>> >>> kdump to capture a proper dump. So far we haven't had any luck with >>> getting >>> >>> kdump to capture things properly. I did however get a bit of a >>> different >>> >>> screenshot of a crash today and wanted to share it in case it would >>> be >>> >>> helpful. >>> >>> >>> >>> Here is what we saw today when the crash occurred. >>> > >>> > >>> >> >> >
_______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
