From pbrady at redhat.com Sun Jun 1 23:46:30 2014 From: pbrady at redhat.com (=?ISO-8859-1?Q?P=E1draig_Brady?=) Date: Mon, 02 Jun 2014 00:46:30 +0100 Subject: [Rdo-list] [package announce] openstack clients update Message-ID: <538BBB56.6070005@redhat.com> Icehouse RDO client packages have been updated as follows: python-swiftclient-2.0.3 -> 2.1.0 python-novaclient-2.16.0 -> 2.17.0 Also included are backports for server groups support python-cinderclient-1.0.8 -> 1.0.9 From rbryant at redhat.com Mon Jun 2 15:55:33 2014 From: rbryant at redhat.com (Russell Bryant) Date: Mon, 02 Jun 2014 11:55:33 -0400 Subject: [Rdo-list] python-*client packaging In-Reply-To: <5387AFC0.40009@redhat.com> References: <988705872.19052788.1401116665554.JavaMail.zimbra@redhat.com> <53835DFF.9000505@redhat.com> <53836ABA.3050209@redhat.com> <1710698042.22367004.1401401084367.JavaMail.zimbra@redhat.com> <5387AFC0.40009@redhat.com> Message-ID: <538C9E75.4000308@redhat.com> On 05/29/2014 06:08 PM, Dan Smith wrote: >> I guess what I am driving at is that the process of creating a tag in >> the OpenStack client projects occurs at pretty arbitrary points in >> time based on the needs of other OpenStack projects that want to set >> requirements on them rather than anything relating to the needs of >> downstream distributions such as RDO or RHELOSP. Because no other >> OpenStack project needed the particular functionality (and fixes) >> added to python-novaclient in the last three months no new tag was >> requested nor created. In this case it means we're missing some 84 >> odd commits made since the 2.17.0 tag was created. > > Yup, exactly. We've had features that were cross-project that had client > changes required. We'd push the change into nova, then push into > novaclient, tag the novaclient, update requirements for the other > project, push that change, etc. > > On the other hand, we also have "huh, we haven't done a client release > in a while" moments. For examples like nova events, instance groups, > etc, I think it makes plenty of sense to stay current on the client > packages. > >> Given this what I'm wondering is if there is any reason we shouldn't >> move to a model where we rebase the python-*client packages to the >> latest git commit at each milestone (J-1, J-2, J-3, RC, GA), >> regardless of the existence of a tag, to ensure we are always picking >> up the latest changes? > > Assuming proper testing of course, +1 from me. Agreed. It really should be safe to use from any commit. That's certainly the intention. As Dan mentioned, we're completely non-disciplined about when a client actually gets tagged. Practically that's just about getting something uploaded to pypi occasionally, and that's not terribly relevant for us anyway. -- Russell Bryant From dallan at redhat.com Mon Jun 2 16:43:00 2014 From: dallan at redhat.com (Dave Allan) Date: Mon, 2 Jun 2014 12:43:00 -0400 Subject: [Rdo-list] python-*client packaging In-Reply-To: <538C9E75.4000308@redhat.com> References: <988705872.19052788.1401116665554.JavaMail.zimbra@redhat.com> <53835DFF.9000505@redhat.com> <53836ABA.3050209@redhat.com> <1710698042.22367004.1401401084367.JavaMail.zimbra@redhat.com> <5387AFC0.40009@redhat.com> <538C9E75.4000308@redhat.com> Message-ID: <20140602164300.GD17721@redhat.com> On Mon, Jun 02, 2014 at 11:55:33AM -0400, Russell Bryant wrote: > On 05/29/2014 06:08 PM, Dan Smith wrote: > >> I guess what I am driving at is that the process of creating a tag in > >> the OpenStack client projects occurs at pretty arbitrary points in > >> time based on the needs of other OpenStack projects that want to set > >> requirements on them rather than anything relating to the needs of > >> downstream distributions such as RDO or RHELOSP. Because no other > >> OpenStack project needed the particular functionality (and fixes) > >> added to python-novaclient in the last three months no new tag was > >> requested nor created. In this case it means we're missing some 84 > >> odd commits made since the 2.17.0 tag was created. > > > > Yup, exactly. We've had features that were cross-project that had client > > changes required. We'd push the change into nova, then push into > > novaclient, tag the novaclient, update requirements for the other > > project, push that change, etc. > > > > On the other hand, we also have "huh, we haven't done a client release > > in a while" moments. For examples like nova events, instance groups, > > etc, I think it makes plenty of sense to stay current on the client > > packages. > > > >> Given this what I'm wondering is if there is any reason we shouldn't > >> move to a model where we rebase the python-*client packages to the > >> latest git commit at each milestone (J-1, J-2, J-3, RC, GA), > >> regardless of the existence of a tag, to ensure we are always picking > >> up the latest changes? > > > > Assuming proper testing of course, +1 from me. > > Agreed. It really should be safe to use from any commit. That's > certainly the intention. As Dan mentioned, we're completely > non-disciplined about when a client actually gets tagged. Practically > that's just about getting something uploaded to pypi occasionally, and > that's not terribly relevant for us anyway. > > -- > Russell Bryant What about the point that the CI runs on what gets uploaded to pypi and therefore the random commits are not as thoroughly tested? Dave From dansmith at redhat.com Mon Jun 2 16:46:42 2014 From: dansmith at redhat.com (Dan Smith) Date: Mon, 02 Jun 2014 09:46:42 -0700 Subject: [Rdo-list] python-*client packaging In-Reply-To: <20140602164300.GD17721@redhat.com> References: <988705872.19052788.1401116665554.JavaMail.zimbra@redhat.com> <53835DFF.9000505@redhat.com> <53836ABA.3050209@redhat.com> <1710698042.22367004.1401401084367.JavaMail.zimbra@redhat.com> <5387AFC0.40009@redhat.com> <538C9E75.4000308@redhat.com> <20140602164300.GD17721@redhat.com> Message-ID: <538CAA72.6000805@redhat.com> > What about the point that the CI runs on what gets uploaded to pypi > and therefore the random commits are not as thoroughly tested? The commits are tested just like anything else, but projects that *use* the client don't gate on the new code until it is released. So, a commit to novaclient runs a full nova stack just like a nova patch would, and should have anything else that uses it (like neutron) run against it as well, which should prevent merging a patch against novaclient that breaks neutron. It does happen that we occasionally merge a patch that was fine at one point, but races with another change in another project to create a problem once it's released. However, that breaks the world and everyone jumps on it immediately. Infrequent and short-lived. --Dan From dallan at redhat.com Mon Jun 2 16:58:46 2014 From: dallan at redhat.com (Dave Allan) Date: Mon, 2 Jun 2014 12:58:46 -0400 Subject: [Rdo-list] python-*client packaging In-Reply-To: <538CAA72.6000805@redhat.com> References: <988705872.19052788.1401116665554.JavaMail.zimbra@redhat.com> <53835DFF.9000505@redhat.com> <53836ABA.3050209@redhat.com> <1710698042.22367004.1401401084367.JavaMail.zimbra@redhat.com> <5387AFC0.40009@redhat.com> <538C9E75.4000308@redhat.com> <20140602164300.GD17721@redhat.com> <538CAA72.6000805@redhat.com> Message-ID: <20140602165846.GE17721@redhat.com> On Mon, Jun 02, 2014 at 09:46:42AM -0700, Dan Smith wrote: > > What about the point that the CI runs on what gets uploaded to pypi > > and therefore the random commits are not as thoroughly tested? > > The commits are tested just like anything else, but projects that *use* > the client don't gate on the new code until it is released. So, a commit > to novaclient runs a full nova stack just like a nova patch would, and > should have anything else that uses it (like neutron) run against it as > well, which should prevent merging a patch against novaclient that > breaks neutron. > > It does happen that we occasionally merge a patch that was fine at one > point, but races with another change in another project to create a > problem once it's released. However, that breaks the world and everyone > jumps on it immediately. Infrequent and short-lived. > > --Dan > > Fair enough; thanks for the explanation. Dave From shardy at redhat.com Mon Jun 2 17:04:34 2014 From: shardy at redhat.com (Steven Hardy) Date: Mon, 2 Jun 2014 18:04:34 +0100 Subject: [Rdo-list] python-*client packaging In-Reply-To: <538CAA72.6000805@redhat.com> References: <988705872.19052788.1401116665554.JavaMail.zimbra@redhat.com> <53835DFF.9000505@redhat.com> <53836ABA.3050209@redhat.com> <1710698042.22367004.1401401084367.JavaMail.zimbra@redhat.com> <5387AFC0.40009@redhat.com> <538C9E75.4000308@redhat.com> <20140602164300.GD17721@redhat.com> <538CAA72.6000805@redhat.com> Message-ID: <20140602170433.GF32178@t430slt.redhat.com> On Mon, Jun 02, 2014 at 09:46:42AM -0700, Dan Smith wrote: > > What about the point that the CI runs on what gets uploaded to pypi > > and therefore the random commits are not as thoroughly tested? > > The commits are tested just like anything else, but projects that *use* > the client don't gate on the new code until it is released. So, a commit > to novaclient runs a full nova stack just like a nova patch would, and > should have anything else that uses it (like neutron) run against it as > well, which should prevent merging a patch against novaclient that > breaks neutron. Exactly, so by taking a random git version you run a greater risk of regressions/interface changes breaking projects which depend on the client, so it's essential you re-test every client-consuming project, which doesn't happen as part of the *client gate run (but does indirectly after a release, because client-consuming projects have their gates break). Also it's worth pointing out that the gate coverage (unit tests and functional tests via tempest scenario tests) for many *clients is not that great, so relying on the gate check for the client patches is not a good strategy IMO. > It does happen that we occasionally merge a patch that was fine at one > point, but races with another change in another project to create a > problem once it's released. However, that breaks the world and everyone > jumps on it immediately. Infrequent and short-lived. It's true that major regressions normally get attention pretty quickly, but more often what happens is the consuming projects, such as Heat, fix their master to cope with the new client behavior to un-break their gate and move on. Again, this implies that by picking a random git version of a client, you run the risk that various projects will just break in exciting ways. FWIW, it's not that infrequent at all IME, heat regularly gets broken by client releases. Cheers, Steve From dansmith at redhat.com Mon Jun 2 17:08:41 2014 From: dansmith at redhat.com (Dan Smith) Date: Mon, 02 Jun 2014 10:08:41 -0700 Subject: [Rdo-list] python-*client packaging In-Reply-To: <20140602170433.GF32178@t430slt.redhat.com> References: <988705872.19052788.1401116665554.JavaMail.zimbra@redhat.com> <53835DFF.9000505@redhat.com> <53836ABA.3050209@redhat.com> <1710698042.22367004.1401401084367.JavaMail.zimbra@redhat.com> <5387AFC0.40009@redhat.com> <538C9E75.4000308@redhat.com> <20140602164300.GD17721@redhat.com> <538CAA72.6000805@redhat.com> <20140602170433.GF32178@t430slt.redhat.com> Message-ID: <538CAF99.9010908@redhat.com> > It's true that major regressions normally get attention pretty quickly, but > more often what happens is the consuming projects, such as Heat, fix their > master to cope with the new client behavior to un-break their gate and move > on. Again, this implies that by picking a random git version of a client, > you run the risk that various projects will just break in exciting ways. Yeah, it's too bad that you do that. If we don't have any indication that something broke, it's hard to know to fix it :) > FWIW, it's not that infrequent at all IME, heat regularly gets broken by > client releases. Fixing something like that in heat is really the wrong approach, IMHO. You're working around the safety net that is in place, which is: "a project gates on the things it depends on and thus when something in that dependency breaks, we catch it immediately." --Dan From rbryant at redhat.com Mon Jun 2 17:47:46 2014 From: rbryant at redhat.com (Russell Bryant) Date: Mon, 02 Jun 2014 13:47:46 -0400 Subject: [Rdo-list] python-*client packaging In-Reply-To: <20140602170433.GF32178@t430slt.redhat.com> References: <988705872.19052788.1401116665554.JavaMail.zimbra@redhat.com> <53835DFF.9000505@redhat.com> <53836ABA.3050209@redhat.com> <1710698042.22367004.1401401084367.JavaMail.zimbra@redhat.com> <5387AFC0.40009@redhat.com> <538C9E75.4000308@redhat.com> <20140602164300.GD17721@redhat.com> <538CAA72.6000805@redhat.com> <20140602170433.GF32178@t430slt.redhat.com> Message-ID: <538CB8C2.8070101@redhat.com> On 06/02/2014 01:04 PM, Steven Hardy wrote: > On Mon, Jun 02, 2014 at 09:46:42AM -0700, Dan Smith wrote: >>> What about the point that the CI runs on what gets uploaded to pypi >>> and therefore the random commits are not as thoroughly tested? >> >> The commits are tested just like anything else, but projects that *use* >> the client don't gate on the new code until it is released. So, a commit >> to novaclient runs a full nova stack just like a nova patch would, and >> should have anything else that uses it (like neutron) run against it as >> well, which should prevent merging a patch against novaclient that >> breaks neutron. > > Exactly, so by taking a random git version you run a greater risk of > regressions/interface changes breaking projects which depend on the client, > so it's essential you re-test every client-consuming project, which doesn't > happen as part of the *client gate run (but does indirectly after a > release, because client-consuming projects have their gates break). Um, are you sure? I thought clients were installed from the latest git just like everything else. I took a look at a tempest-dsvm-full run from this morning against a heat master patch. http://logs.openstack.org/87/85687/5/check/check-tempest-dsvm-full/885850f/logs/pip-freeze.txt.gz In there you can see that novaclient is installed from a local git tree. -e git+https://git.openstack.org/openstack/python-novaclient at 7a0fe3abf586bba0ad3e2756d343a6d3b9bdd3f0#egg=python_novaclient-origin/HEAD That is the latest commit in master of python-novaclient. -- Russell Bryant From shardy at redhat.com Mon Jun 2 18:35:32 2014 From: shardy at redhat.com (Steven Hardy) Date: Mon, 2 Jun 2014 19:35:32 +0100 Subject: [Rdo-list] python-*client packaging In-Reply-To: <538CAF99.9010908@redhat.com> References: <988705872.19052788.1401116665554.JavaMail.zimbra@redhat.com> <53835DFF.9000505@redhat.com> <53836ABA.3050209@redhat.com> <1710698042.22367004.1401401084367.JavaMail.zimbra@redhat.com> <5387AFC0.40009@redhat.com> <538C9E75.4000308@redhat.com> <20140602164300.GD17721@redhat.com> <538CAA72.6000805@redhat.com> <20140602170433.GF32178@t430slt.redhat.com> <538CAF99.9010908@redhat.com> Message-ID: <20140602183530.GG32178@t430slt.redhat.com> On Mon, Jun 02, 2014 at 10:08:41AM -0700, Dan Smith wrote: > > It's true that major regressions normally get attention pretty quickly, but > > more often what happens is the consuming projects, such as Heat, fix their > > master to cope with the new client behavior to un-break their gate and move > > on. Again, this implies that by picking a random git version of a client, > > you run the risk that various projects will just break in exciting ways. > > Yeah, it's too bad that you do that. If we don't have any indication > that something broke, it's hard to know to fix it :) I never said we don't report the issues, I even linked a novaclient bug earlier in the thread, we always report regressions when we find them :\ Sometimes the issues are bugs in heat, most often coupling between our unit tests and the client, similar issues are sometimes encountered by Horizon, e.g bug #1279907. Arguably we need a better way of stubbing client interfaces to avoid this problem. My point remains that it's preferable to work with upstream to trigger a new release, but if folks want to run bleeding edge clients then fair enough. Steve From shardy at redhat.com Mon Jun 2 18:49:28 2014 From: shardy at redhat.com (Steven Hardy) Date: Mon, 2 Jun 2014 19:49:28 +0100 Subject: [Rdo-list] python-*client packaging In-Reply-To: <538CB8C2.8070101@redhat.com> References: <988705872.19052788.1401116665554.JavaMail.zimbra@redhat.com> <53835DFF.9000505@redhat.com> <53836ABA.3050209@redhat.com> <1710698042.22367004.1401401084367.JavaMail.zimbra@redhat.com> <5387AFC0.40009@redhat.com> <538C9E75.4000308@redhat.com> <20140602164300.GD17721@redhat.com> <538CAA72.6000805@redhat.com> <20140602170433.GF32178@t430slt.redhat.com> <538CB8C2.8070101@redhat.com> Message-ID: <20140602184927.GH32178@t430slt.redhat.com> On Mon, Jun 02, 2014 at 01:47:46PM -0400, Russell Bryant wrote: > On 06/02/2014 01:04 PM, Steven Hardy wrote: > > On Mon, Jun 02, 2014 at 09:46:42AM -0700, Dan Smith wrote: > >>> What about the point that the CI runs on what gets uploaded to pypi > >>> and therefore the random commits are not as thoroughly tested? > >> > >> The commits are tested just like anything else, but projects that *use* > >> the client don't gate on the new code until it is released. So, a commit > >> to novaclient runs a full nova stack just like a nova patch would, and > >> should have anything else that uses it (like neutron) run against it as > >> well, which should prevent merging a patch against novaclient that > >> breaks neutron. > > > > Exactly, so by taking a random git version you run a greater risk of > > regressions/interface changes breaking projects which depend on the client, > > so it's essential you re-test every client-consuming project, which doesn't > > happen as part of the *client gate run (but does indirectly after a > > release, because client-consuming projects have their gates break). > > Um, are you sure? I thought clients were installed from the latest git > just like everything else. I'm referring to the unit tests, which is the most-frequently-broken thing for Heat, the pypi version gets installed in the tox venv, not the git master version. From rbowen at redhat.com Mon Jun 2 18:52:00 2014 From: rbowen at redhat.com (Rich Bowen) Date: Mon, 02 Jun 2014 14:52:00 -0400 Subject: [Rdo-list] TripleO hangout, Friday 1pm Eastern Message-ID: <538CC7D0.6020501@redhat.com> Hugh Brock will present a hangout on #Openstack #TripleO on Friday at 1pm Eastern: https://plus.google.com/events/cp6fpffs4a9maqfn3h92tvvck1o -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://openstack.redhat.com/ From rbowen at redhat.com Mon Jun 2 20:37:07 2014 From: rbowen at redhat.com (Rich Bowen) Date: Mon, 02 Jun 2014 16:37:07 -0400 Subject: [Rdo-list] Reminder: Community IRC meeting, Tuesday 9am Eastern Message-ID: <538CE073.7030605@redhat.com> Reminder that our weekly community IRC meeting will be held tomorrow morning, Tuesday, 9am Eastern, on the #rdo IRC channel on the Freenode network. The agenda for that meeting is at https://etherpad.openstack.org/p/rdo_community_manager_sync The meeting typically takes about 45 minutes, but there's not much on the agenda this week. --Rich -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://openstack.redhat.com/ From brian at brianlee.org Tue Jun 3 13:21:39 2014 From: brian at brianlee.org (brian lee) Date: Tue, 3 Jun 2014 08:21:39 -0500 Subject: [Rdo-list] Setting up Neutron networking for the first time. Message-ID: I am moving from nova networking with Havana to a new install of Icehouse and I'm having problems wrapping my head around neutron networking. I currently have a separate vlan setup from my environment, 10.10.10.x (public) and 192.168.0.x (private). How do I go about connecting to the public vlan? How does the control node talk to it? Is there a guide out there that can help me, I have googled around and since there are many different ways to config this nothing is clicking for me. --Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbowen at redhat.com Tue Jun 3 13:55:00 2014 From: rbowen at redhat.com (Rich Bowen) Date: Tue, 03 Jun 2014 09:55:00 -0400 Subject: [Rdo-list] Reminder: Community IRC meeting, Tuesday 9am Eastern In-Reply-To: <538CE073.7030605@redhat.com> References: <538CE073.7030605@redhat.com> Message-ID: <538DD3B4.9000801@redhat.com> On 06/02/2014 04:37 PM, Rich Bowen wrote: > Reminder that our weekly community IRC meeting will be held tomorrow > morning, Tuesday, 9am Eastern, on the #rdo IRC channel on the Freenode > network. > > The agenda for that meeting is at > https://etherpad.openstack.org/p/rdo_community_manager_sync > > The meeting typically takes about 45 minutes, but there's not much on > the agenda this week. > > --Rich > Minutes: http://meetbot.fedoraproject.org/rdo/2014-06-03/rdo_community_sync.2014-06-03-13.11.html Minutes (text): http://meetbot.fedoraproject.org/rdo/2014-06-03/rdo_community_sync.2014-06-03-13.11.txt Log: http://meetbot.fedoraproject.org/rdo/2014-06-03/rdo_community_sync.2014-06-03-13.11.log.html ============ #rdo Meeting ============ Meeting started by rbowen at 13:11:40 UTC. The full logs are available at http://meetbot.fedoraproject.org/rdo/2014-06-03/rdo_community_sync.2014-06-03-13.11.log.html . Meeting summary --------------- * LINK: https://etherpad.openstack.org/p/rdo_community_manager_sync (rbowen, 13:13:02) * Test day (rbowen, 13:15:12) * LINK: https://wiki.openstack.org/wiki/Juno_Release_Schedule (rbowen, 13:17:35) * First Juno milestone is June 12. We should discuss with QE what kind of test day we want to do around that, if any. (rbowen, 13:18:25) * Also check with packagers to see what the timeline will be for package availability around M1. (rbowen, 13:19:00) * Define "good enough" as allinone works, multinode works with defaults and then announce a public test day. (rbowen, 13:21:26) * ACTION: Start discussion on rdo-list about scheduling test day when M1 packages are "good enough" (rbowen, 13:22:35) * Hangout (rbowen, 13:23:09) * hewbrocca will be doing a hangout THIS FRIDAY on TripleO. (rbowen, 13:23:22) * Newsletter (rbowen, 13:24:51) * Newsletter goes to 2500 - 3000, only 6 responded to survey. (rbowen, 13:27:53) * Need to try to make the newsletter more engaging, more technical content (rbowen, 13:28:07) * Will try to add bug stats, development stats, interesting bugs, etc. (rbowen, 13:28:21) * Events (rbowen, 13:30:58) * OpenStack Israel yesterday (rbowen, 13:31:09) * Cincinnati CentOS dojo tomorrow (rbowen, 13:31:22) * OpenStack Days UK (London) tomorrow (rbowen, 13:31:31) * OSCon end of July (rbowen, 13:31:44) * Flock beginning of August (rbowen, 13:31:56) * Bug triage (rbowen, 13:34:50) * 17-June-2014 bug triage (third Wednesday of the month) (rbowen, 13:40:24) * Nova bug triage day (upstream) tomorrow. (rbowen, 13:40:38) * LINK: http://kashyapc.fedorapeople.org/virt/openstack/bugzilla/rdo-bug-status/all-rdo-bugs-03-06-2014.txt (rbowen, 13:41:03) * That's third Tuesday, not Wednesday. :-) (rbowen, 13:41:25) * Ask.openstack.org (rbowen, 13:41:38) * Unanswered counts have crept back up. Expect me to start bugging you for help in the next week or so. (rbowen, 13:43:00) * CentOS Cloud SIG (rbowen, 13:43:26) * Looking for assistance in getting more engaged with the CentOS community. (rbowen, 13:50:12) Meeting ended at 13:50:18 UTC. -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://openstack.redhat.com/ From eberg at rubensteintech.com Tue Jun 3 14:55:43 2014 From: eberg at rubensteintech.com (Eric Berg) Date: Tue, 03 Jun 2014 10:55:43 -0400 Subject: [Rdo-list] Simplest Icehouse Implementation Architecture In-Reply-To: <5388C085.7080805@rubensteintech.com> References: <53878AFD.4010909@rubensteintech.com> <20140529193912.GC7137@redhat.com> <538792B0.8050500@rubensteintech.com> <5388C085.7080805@rubensteintech.com> Message-ID: <538DE1EF.6050704@rubensteintech.com> I have performed this installation and now have a control host and one compute host, but am not sure of a few things: 1. First, I believe that I need nova-networking running on each compute hosts to avoid routing all traffic through a dedicated network host, but I'm not sure how to check to see that the networking service is running on my compute host. 2. Lars helped me set up a single-host setup, which put my instances on our 192.168.0.0/16 network by using an ovs bridge (br-ex) with the IP of the host on the bridge, which owns eth0, but I'm not sure how that relates to this new setup. Should I create the same type of bridged connection on each compute host? I have done quite a bit of searching and reading, but have yet to find any documents that clearly lay out how this networking shold work. Obviously, with OpenStack in general, there are many different implementations with different needs, but I feel like there's very little to get you through network configuration beyond basic installation. If I'm missing something obvious, I'd appreciate it if anybody could provide pointers. In the mean time, I'm hoping for some help. Thanks. Eric On 5/30/14, 1:31 PM, Eric Berg write: > Thoughts, anyone? > > I'm moving forward with the following: > > packstack --install-hosts=192.168.0.37,192.168.0.39 > > and will add another compute host in the future. Still thinking about > what the network should look like, but I'm probably overthinking it > for a change. > > On 5/29/14, 4:04 PM, Eric Berg wrote: >> Thanks as always, Lars. >> >> By "development environment", I mean several things: >> >> 1) Developers work on these hosts. We're a web shop, and one or more >> developers will spin up dev web servers on these hosts >> 2) Ideally, I'd also want to validate our production cloud >> environment so that when we deploy it in production, we have >> validated the configuration. >> >> For the time being, however, #2 is a nice-to-have and does not at all >> seem to fit in with the fairly aggressive goal of implementing a new >> RDO deployment in 1-3 days (way over that already as you might well >> imagine). >> >> So, basically, I want to migrate from the current set of physical >> hosts on which developers now work to a cloud environment which will >> host no more than 25 VMs. >> >> Since we have two fairly well-endowed hosts targeted for use as >> compute hosts, would it be realistic to use one as the controller, >> while still using it as a compute host? >> >> On a related note, what happens if I lose the controller box in this >> two-compute-hosts-one-as-controller-host scenario? I believe that >> I'm out of business until I can remedy that, and if I wanted to set >> up the two hosts as both compute hosts as well as putting some kind >> of HA in place so that control could pass from one to the other of >> these boxes, would that be possible? Recommended? >> >> Must the control host be separate in order to do (live) migrations? >> >> Is it a requirement that the control host be separate if I want to >> deploy 2 compute hosts? >> >> And, if I choose the two-host solution, how does the network host >> (through which my understanding is that all network access to the >> instances must pass) play into this? >> >> Eric >> >> On 5/29/14, 3:39 PM, Lars Kellogg-Stedman wrote: >>> On Thu, May 29, 2014 at 03:31:09PM -0400, Eric Berg wrote: >>>> So, are either of the following architectures sufficient for a >>>> development >>>> environment? >>> Depending on your definition of "development environment", a *single* >>> host may be sufficient. It really depends on how many instances you >>> expect to support, of what size, and what sort of workloads you'll be >>> hosting. >>> >>> Having a seperate "control" node makes for nice logical separation of >>> roles, which I find helpful in diagnosing problems. >>> >>> Having more than one compute node lets you experiment with things like >>> instance migration, etc, which may be useful if you eventually plan to >>> move to a production configuration. >>> >> > -- Eric Berg Sr. Software Engineer Rubenstein Technology Group 55 Broad Street, 14th Floor New York, NY 10004-2501 (212) 518-6400 (212) 518-6467 fax eberg at rubensteintech.com www.rubensteintech.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From kchamart at redhat.com Tue Jun 3 16:43:17 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Tue, 3 Jun 2014 22:13:17 +0530 Subject: [Rdo-list] Setting up Neutron networking for the first time. In-Reply-To: References: Message-ID: <20140603164317.GH2638@tesla.redhat.com> On Tue, Jun 03, 2014 at 08:21:39AM -0500, brian lee wrote: > I am moving from nova networking with Havana to a new install of Icehouse > and I'm having problems wrapping my head around neutron networking. I > currently have a separate vlan setup from my environment, 10.10.10.x > (public) and 192.168.0.x (private). How do I go about connecting to the > public vlan? How does the control node talk to it? Is there a guide out > there that can help me, I have googled around and since there are many > different ways to config this nothing is clicking for me. There's an older wiki/doc (related to Grizzly) that speaks about OVS with VLANs[1] but doesn't address your specific question. Also, note that if you're just starting with Neutron networking, you may have to be prepared for some deep troubleshooting :-) [1] http://openstack.redhat.com/Neutron_with_OVS_and_VLANs -- /kashyap From rbowen at redhat.com Tue Jun 3 20:02:28 2014 From: rbowen at redhat.com (Rich Bowen) Date: Tue, 03 Jun 2014 16:02:28 -0400 Subject: [Rdo-list] [Rdo-newsletter] June RDO community newsletter Message-ID: <538E29D4.8040308@redhat.com> Thanks for being part of the RDO community! Here's what's going on in RDO, and in the larger OpenStack world, in the coming days. OpenStack Events With the OpenStack Summit behind us, June is a little quieter, but there are still a number of events coming up. OpenStack Israel - http://www.openstack-israel.org/ - is actually already passed - it was held June 2 in Herzliya. You can follow OpenStack Israel on Twitter, at @OpenStackIL, to catch the news coming out of that event over the next few days, and see the videos of the talks you may have missed. In just a few days (June 4) OpenStack UK Day - http://www.eventbooking.uk.com/openstack/home.html - will be held in London. There will be presentations by a number of OpenStack luminaries, including Monty Taylor and Mark McCloughlin, and a great opportunity to meet other OpenStack users and developers. With the Red Hat acquisition of Inktank still very new news, you might want to catch John Spray's talk on Ceph to see what that's all about. On that same day, there will be a CentOS dojo in Cincinnati, Ohio, USA. - http://wiki.centos.org/Events/Dojo/Cincinnati2014 CentOS is the leading platform for deploying RDO, and with the ongoing work on the CentOS Cloud SIG, this will be a great place to come talk about how RDO fits into CentOS, and how we can achieve closer ties between the two communities. On Friday, June 6th, at 13:00 Eastern US time, Hugh Brock will be presenting a Google Hangout on TripleO. You can register your attendance at https://plus.google.com/events/cp6fpffs4a9maqfn3h92tvvck1o On the third Tuesday of every month (That's June 17, this month), we hold a bug triage event. See the latest open ticket list at http://kashyapc.fedorapeople.org/virt/openstack/bugzilla/rdo-bug-stat us/ and join us all through the day on the #rdo channel on the Freenote IRC network. You can always see the upcoming events on the RDO Events calendar, at http://openstack.redhat.com/Events and on the main OpenStack events calendar at http://openstack.org/events New articles, Wiki content The following new docs have been added to the RDO wiki in the past month: * Deploying an RDO Overcloud with Instack - http://openstack.redhat.com/Deploying_an_RDO_Overcloud_with_Instack - part of the larger series on using Instack with RDO - http://openstack.redhat.com/Deploying_RDO_using_Instack * ML2 from OVS - http://openstack.redhat.com/ML2_from_OVS - a tutorial starting from a working OpenStack Icehouse install with the Openvswitch plugin. * Creating CentOS and Fedora images ready for use on OpenStack - http://openstack.redhat.com/Creating_CentOS_and_Fedora_images_ready_for_Openstack * Getting started with GRE on Icehouse - http://openstack.redhat.com/GettingStartedIcehouse_w_GRE We've also had a lot of great articles posted by various RDO engineers in the past month: * Improving libvirt firewall performance - Daniel Berrange: https://www.berrange.com/posts/2014/05/02/improving-libvirt-firewall-performance/ * Integrating Kerberos into Keystone - Adam Young: http://adam.younglogic.com/2014/05/keystone-and-kerberos/ * Keystone Federation - Adam Young: http://adam.younglogic.com/2014/05/keystone-federation-via-mod_lookup_identity/ * User Interface discussion at OpenStack Juno Summit - Liz Blanchard: http://uxd-stackabledesign.rhcloud.com/?p=114 * OpenStack Orchestration and Configuration Management - Zane Bitter: http://www.zerobanana.com/archive/2014/05/08#heat-configuration-management * Flat networks with ML2 and OpenVSwitch - Lars Kellogg-Stedman: http://blog.oddbit.com/2014/05/19/flat-networks-with-ml-and-open * Video: Configuring OpenStack's external bridge on a single-interface system - Lars Kellogg-Stedman: http://blog.oddbit.com/2014/05/27/configuring-openstacks-externa For the latest great articles from OpenStack engineers, be sure to follow http://planet.openstack.org/ OpenStack Summit and Community Survey Results At the OpenStack Summit in Atlanta a few weeks ago, the results from the OpenStack User Survey were announced. The survey was greatly expanded from last time, in terms of what data was being collected, so it's hard to just directly compare last year's results to this year's, but it's fun to try. First of all, here's last year's survey results: http://www.slideshare.net/openstack/openstack-user-survey-october-2013 (and summarized at http://www.openstack.org/blog/2013/11/openstack-user-survey-october-2013/ ) And this year's results: http://www.slideshare.net/ryan-lane/openstack-atlanta-user-survey I was struck by how slowly production deployments of OpenStack move, with substantial numbers of deployments still on Folsom, Essex, or even earlier. Meanwhile, in the proof-of-concept and developer spaces, we see CentOS and RHEL making a big jump on the lead held, for the moment, by Debian and Ubuntu. You can see much of the content from the Summit on the OpenStack Foundation Youtube page at https://www.youtube.com/user/OpenStackFoundation/videos Staying in Touch The best ways to keep up with what's going on in the RDO community are: * Follow us on Twitter - http://twitter.com/rdocommunity * Google+ - http://tm3.org/rdogplus * rdo-list mailing list - http://www.redhat.com/mailman/listinfo/rdo-list * This newsletter - http://www.redhat.com/mailman/listinfo/rdo-newsletter * RDO Q&A - http://ask.openstack.org/ Thanks again for being part of the RDO community! -- Rich Bowen, OpenStack Community Liaison rbowen at redhat.com http://openstack.redhat.com _______________________________________________ Rdo-newsletter mailing list Rdo-newsletter at redhat.com https://www.redhat.com/mailman/listinfo/rdo-newsletter From lars at redhat.com Wed Jun 4 14:12:02 2014 From: lars at redhat.com (Lars Kellogg-Stedman) Date: Wed, 4 Jun 2014 10:12:02 -0400 Subject: [Rdo-list] Simplest Icehouse Implementation Architecture In-Reply-To: <538DE1EF.6050704@rubensteintech.com> References: <53878AFD.4010909@rubensteintech.com> <20140529193912.GC7137@redhat.com> <538792B0.8050500@rubensteintech.com> <5388C085.7080805@rubensteintech.com> <538DE1EF.6050704@rubensteintech.com> Message-ID: <20140604141202.GA25121@redhat.com> On Tue, Jun 03, 2014 at 10:55:43AM -0400, Eric Berg wrote: > I have performed this installation and now have a control host and one > compute host, but am not sure of a few things: > > 1. First, I believe that I need nova-networking running on each compute > hosts to avoid routing all traffic through a dedicated network host, > but I'm not sure how to check to see that the networking service is > running on my compute host. > 2. Lars helped me set up a single-host setup, which put my instances on > our 192.168.0.0/16 network by using an ovs bridge (br-ex) with the > IP of the host on the bridge, which owns eth0, but I'm not sure how > that relates to this new setup. Should I create the same type of > bridged connection on each compute host? Eric, If you're working with the configuration you and I worked on, you're using neutron, so you can't use nova-networking on each compute host, unless you decide to ditch neutron. Neutron does not have an operational model matching nova-network's multi-host mode. You can set up Neutron in an active/passive configuration if you want to have some fault tolerance, but a given external network is always going to route through a single node when using the native Linux layer 3 agent. You can use vendor plugins from Cisco, etc., if you need a more performant configuration (but I don't have any details on what that would look like). -- Lars Kellogg-Stedman | larsks @ irc Cloud Engineering / OpenStack | " " @ twitter -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From kchamart at redhat.com Thu Jun 5 15:08:55 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Thu, 5 Jun 2014 20:38:55 +0530 Subject: [Rdo-list] Notes for (manually) setting up a 2-node minimal IceHouse RDO setup in virtual machines Message-ID: <20140605150855.GG4374@tesla.redhat.com> I've been using this minimal, manually-configured IceHouse virtual setup based on this notes[1] for a few weeks as a virtual test environment reasonably successfully. This may not be issue-free, but if anyone ever dares to try this, comments/feedforward welcome. And, here[2] the resulting configuration files (although, I've posted this here a couple of times, but posting again for completness' sake). [1] http://kashyapc.fedorapeople.org/virt/openstack/rdo/Minimal-OpenStack-IceHouse-setup.rst.txt [2] http://kashyapc.fedorapeople.org/virt/openstack/rdo/IceHouse-Nova-Neutron-ML2-GRE-OVS.txt -- /kashyap From rbowen at redhat.com Fri Jun 6 17:56:51 2014 From: rbowen at redhat.com (Rich Bowen) Date: Fri, 06 Jun 2014 13:56:51 -0400 Subject: [Rdo-list] TripleO hangout, Friday 1pm Eastern In-Reply-To: <538CC7D0.6020501@redhat.com> References: <538CC7D0.6020501@redhat.com> Message-ID: <539200E3.4020801@redhat.com> On 06/02/2014 02:52 PM, Rich Bowen wrote: > Hugh Brock will present a hangout on #Openstack #TripleO on Friday at > 1pm Eastern: https://plus.google.com/events/cp6fpffs4a9maqfn3h92tvvck1o > In case you missed it, the TripleO hangout, featuring Hugh Brock, Angus Thomas, and Charles Crouch, is available on Youtube at https://plus.google.com/events/cp6fpffs4a9maqfn3h92tvvck1o The video that was mentioned in the talk is also on Youtube, at https://www.youtube.com/watch?v=28r1rdjiJM8 Thanks, Hugh, Charles and Angus for a great presentation. --Rich -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://openstack.redhat.com/ From akalambu at cisco.com Sat Jun 7 16:59:12 2014 From: akalambu at cisco.com (Ajay Kalambur (akalambu)) Date: Sat, 7 Jun 2014 16:59:12 +0000 Subject: [Rdo-list] Installation Issue Message-ID: Hi I tried the RDO installation based on instructions at http://openstack.redhat.com/Quickstart With the default config if we spawn off a VM failed because the neutron-openvswitch-agent.service terminated. The reason is the error below which looks like https://bugs.launchpad.net/neutron/+bug/1322139 2014-06-07 02:35:55.311 15597 ERROR neutron.plugins.openvswitch.agent.ovs_neutron_agent [req-aae1a4c5-7b45-42b3-886c-1657b25032e2 None] Agent terminated 2014-06-07 02:35:55.311 15597 TRACE neutron.plugins.openvswitch.agent.ovs_neutron_agent Traceback (most recent call last): 2014-06-07 02:35:55.311 15597 TRACE neutron.plugins.openvswitch.agent.ovs_neutron_agent File "/usr/lib/python2.7/site-packages/neutron/plugins/openvswitch/agent/ovs_neutron_agent.py", line 231, in _check_ovs_version 2014-06-07 02:35:55.311 15597 TRACE neutron.plugins.openvswitch.agent.ovs_neutron_agent ovs_lib.check_ovs_vxlan_version(self.root_helper) 2014-06-07 02:35:55.311 15597 TRACE neutron.plugins.openvswitch.agent.ovs_neutron_agent File "/usr/lib/python2.7/site-packages/neutron/agent/linux/ovs_lib.py", line 551, in check_ovs_vxlan_version 2014-06-07 02:35:55.311 15597 TRACE neutron.plugins.openvswitch.agent.ovs_neutron_agent 'kernel', 'VXLAN') 2014-06-07 02:35:55.311 15597 TRACE neutron.plugins.openvswitch.agent.ovs_neutron_agent File "/usr/lib/python2.7/site-packages/neutron/agent/linux/ovs_lib.py", line 529, in _compare_installed_and_required_version 2014-06-07 02:35:55.311 15597 TRACE neutron.plugins.openvswitch.agent.ovs_neutron_agent raise SystemError(msg) 2014-06-07 02:35:55.311 15597 TRACE neutron.plugins.openvswitch.agent.ovs_neutron_agent SystemError: Unable to determine kernel version for Open vSwitch with VXLAN support. To use VXLAN tunnels with OVS, please ensure that the version is 1.10 or newer! I thought the install would go through with default options. Would it be possible to fix the default answers file so that the default installation passes on some simple tests like VM launcher Ajay -------------- next part -------------- An HTML attachment was scrubbed... URL: From ihrachys at redhat.com Mon Jun 9 09:14:19 2014 From: ihrachys at redhat.com (Ihar Hrachyshka) Date: Mon, 09 Jun 2014 11:14:19 +0200 Subject: [Rdo-list] Installation Issue In-Reply-To: References: Message-ID: <53957AEB.8010306@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Ajay, sorry for the issue, the fix was pushed to git tree, but update to RDO repository was missed for some reason. We'll try to handle the issue ASAP. Miguel, could you please make sure RDO repos are updated with a package that includes the fix. This should be >=2014.1-19 and include the following fix: * Wed May 28 2014 Miguel Angel Ajo 2014.1-19 - - Remove kernel version check for OVS VXLAN, not revelant for RDO bz#1081011 Cheers, /Ihar On 07/06/14 18:59, Ajay Kalambur (akalambu) wrote: > Hi I tried the RDO installation based on instructions at > http://openstack.redhat.com/Quickstart > > > With the default config if we spawn off a VM failed because the > neutron-openvswitch-agent.service terminated. > > The reason is the error below which looks like > https://bugs.launchpad.net/neutron/+bug/1322139 > > > > 2014-06-07 02:35:55.311 15597 ERROR > neutron.plugins.openvswitch.agent.ovs_neutron_agent > [req-aae1a4c5-7b45-42b3-886c-1657b25032e2 None] Agent terminated > 2014-06-07 02:35:55.311 15597 TRACE > neutron.plugins.openvswitch.agent.ovs_neutron_agent Traceback (most > recent call last): 2014-06-07 02:35:55.311 15597 TRACE > neutron.plugins.openvswitch.agent.ovs_neutron_agent File > "/usr/lib/python2.7/site-packages/neutron/plugins/openvswitch/agent/ovs_neutron_agent.py", > line 231, in _check_ovs_version 2014-06-07 02:35:55.311 15597 TRACE > neutron.plugins.openvswitch.agent.ovs_neutron_agent > ovs_lib.check_ovs_vxlan_version(self.root_helper) 2014-06-07 > 02:35:55.311 15597 TRACE > neutron.plugins.openvswitch.agent.ovs_neutron_agent File > "/usr/lib/python2.7/site-packages/neutron/agent/linux/ovs_lib.py", > line 551, in check_ovs_vxlan_version 2014-06-07 02:35:55.311 15597 > TRACE neutron.plugins.openvswitch.agent.ovs_neutron_agent > 'kernel', 'VXLAN') 2014-06-07 02:35:55.311 15597 TRACE > neutron.plugins.openvswitch.agent.ovs_neutron_agent File > "/usr/lib/python2.7/site-packages/neutron/agent/linux/ovs_lib.py", > line 529, in _compare_installed_and_required_version 2014-06-07 > 02:35:55.311 15597 TRACE > neutron.plugins.openvswitch.agent.ovs_neutron_agent raise > SystemError(msg) 2014-06-07 02:35:55.311 15597 TRACE > neutron.plugins.openvswitch.agent.ovs_neutron_agent SystemError: > Unable to determine kernel version for Open vSwitch with VXLAN > support. To use VXLAN tunnels with OVS, please ensure that the > version is 1.10 or newer! > > I thought the install would go through with default options. Would > it be possible to fix the default answers file so that the default > installation passes on some simple tests like VM launcher > > > Ajay > > > > > _______________________________________________ Rdo-list mailing > list Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTlXrrAAoJEC5aWaUY1u57I9EIAMuaCw2UYAhL2V8cWSmKLhBz hQBP8mUiW/y7ZF5xq6X1ZGWwFfW94Tb2hipdO+vkzXEtaFTGAnV++8Pwc8ei/OSq kNPAngbi26btJDsWxgrNEL59mRjhQrzhFE58RGxUhY4+0mx95WHj5AMtE5n6A5de l6py9pBh/lvkiY67W4tVoOyzw9Iyd9CjJH0NbSogRGdiVabioilBiDjxYLW2eIYt UYipRGlH4h0eCkqNFtG8znC5OxYo1TbvOoaII90q2kYEVkGjowG0/zTqPvIogPDu l2/J68RS4UZqaxrXtH7wxEcKTU+BIoUV7YWgiBMRR2p3ClDmurh+nR3aGlFUkss= =d84Z -----END PGP SIGNATURE----- From pbrady at redhat.com Mon Jun 9 09:20:26 2014 From: pbrady at redhat.com (=?ISO-8859-1?Q?P=E1draig_Brady?=) Date: Mon, 09 Jun 2014 10:20:26 +0100 Subject: [Rdo-list] Installation Issue In-Reply-To: <53957AEB.8010306@redhat.com> References: <53957AEB.8010306@redhat.com> Message-ID: <53957C5A.7050004@redhat.com> On 06/09/2014 10:14 AM, Ihar Hrachyshka wrote: > Hi Ajay, > sorry for the issue, the fix was pushed to git tree, but update to RDO > repository was missed for some reason. We'll try to handle the issue ASAP. > > Miguel, > could you please make sure RDO repos are updated with a package that > includes the fix. This should be >=2014.1-19 and include the following > fix: > > * Wed May 28 2014 Miguel Angel Ajo 2014.1-19 > - Remove kernel version check for OVS VXLAN, not revelant for RDO > bz#1081011 The fix is already in testing, but blocked due to issues in other packages. It will bubble out shortly. thanks, P?draig. From mangelajo at redhat.com Mon Jun 9 09:26:20 2014 From: mangelajo at redhat.com (Miguel Angel Ajo Pelayo) Date: Mon, 9 Jun 2014 05:26:20 -0400 (EDT) Subject: [Rdo-list] Installation Issue In-Reply-To: <53957C5A.7050004@redhat.com> References: <53957AEB.8010306@redhat.com> <53957C5A.7050004@redhat.com> Message-ID: <142156224.16449162.1402305980526.JavaMail.zimbra@redhat.com> Hi guys, Sorry about it, I believe Ihar is actually right, and I didn't push the rdo-update properly. I'll do it now for just in case. Best, Miguel ?ngel. ----- Mensaje original ----- > On 06/09/2014 10:14 AM, Ihar Hrachyshka wrote: > > Hi Ajay, > > sorry for the issue, the fix was pushed to git tree, but update to RDO > > repository was missed for some reason. We'll try to handle the issue ASAP. > > > > Miguel, > > could you please make sure RDO repos are updated with a package that > > includes the fix. This should be >=2014.1-19 and include the following > > fix: > > > > * Wed May 28 2014 Miguel Angel Ajo 2014.1-19 > > - Remove kernel version check for OVS VXLAN, not revelant for RDO > > bz#1081011 > > The fix is already in testing, but blocked > due to issues in other packages. > > It will bubble out shortly. > > thanks, > P?draig. > From akalambu at cisco.com Mon Jun 9 16:18:07 2014 From: akalambu at cisco.com (Ajay Kalambur (akalambu)) Date: Mon, 9 Jun 2014 16:18:07 +0000 Subject: [Rdo-list] Installation Issue In-Reply-To: <53957C5A.7050004@redhat.com> References: <53957AEB.8010306@redhat.com> <53957C5A.7050004@redhat.com> Message-ID: Thanks everyone for your help Ajay On 6/9/14, 2:20, "P?draig Brady" wrote: >On 06/09/2014 10:14 AM, Ihar Hrachyshka wrote: >> Hi Ajay, >> sorry for the issue, the fix was pushed to git tree, but update to RDO >> repository was missed for some reason. We'll try to handle the issue >>ASAP. >> >> Miguel, >> could you please make sure RDO repos are updated with a package that >> includes the fix. This should be >=2014.1-19 and include the following >> fix: >> >> * Wed May 28 2014 Miguel Angel Ajo 2014.1-19 >> - Remove kernel version check for OVS VXLAN, not revelant for RDO >> bz#1081011 > >The fix is already in testing, but blocked >due to issues in other packages. > >It will bubble out shortly. > >thanks, >P?draig. > >_______________________________________________ >Rdo-list mailing list >Rdo-list at redhat.com >https://www.redhat.com/mailman/listinfo/rdo-list From akalambu at cisco.com Mon Jun 9 17:43:52 2014 From: akalambu at cisco.com (Ajay Kalambur (akalambu)) Date: Mon, 9 Jun 2014 17:43:52 +0000 Subject: [Rdo-list] Heat installation config Message-ID: Hi The RDO answers_file has a config parameter as follow # Set to 'y' if you would like Packstack to install OpenStack # Orchestration (Heat) CONFIG_HEAT_INSTALL=n Even if this is set to n heat seems to have installed and i can run the heat CLIs What actually is this parameter intended for? Ajay -------------- next part -------------- An HTML attachment was scrubbed... URL: From akalambu at cisco.com Mon Jun 9 17:55:40 2014 From: akalambu at cisco.com (Ajay Kalambur (akalambu)) Date: Mon, 9 Jun 2014 17:55:40 +0000 Subject: [Rdo-list] Tempest with RDO Message-ID: Hi When i ask RDO to configure and install tempest it needs to install dependencies like testtools, fixtures, mock, oslotest module i presumed But all the tests fail because none of these modules are installed by RDO I followed the instructions here to try to get tempest working and it does not work http://openstack.redhat.com/Testing_IceHouse_using_Tempest Because the tempest installation does not install these modules Ajay -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbrady at redhat.com Mon Jun 9 18:39:16 2014 From: pbrady at redhat.com (=?ISO-8859-1?Q?P=E1draig_Brady?=) Date: Mon, 09 Jun 2014 19:39:16 +0100 Subject: [Rdo-list] Tempest with RDO In-Reply-To: References: Message-ID: <5395FF54.4040004@redhat.com> On 06/09/2014 06:55 PM, Ajay Kalambur (akalambu) wrote: > Hi > When i ask RDO to configure and install tempest it needs to install dependencies like testtools, fixtures, mock, oslotest module i presumed > But all the tests fail because none of these modules are installed by RDO > > > I followed the instructions here to try to get tempest working and it does not work > http://openstack.redhat.com/Testing_IceHouse_using_Tempest > > Because the tempest installation does not install these modules That documentation is possibly incomplete or out of date. We're currently working on a new tempest package on Fedora 20 at least: https://bugzilla.redhat.com/1103875 thanks, P?draig. From pbrady at redhat.com Mon Jun 9 18:43:28 2014 From: pbrady at redhat.com (=?ISO-8859-1?Q?P=E1draig_Brady?=) Date: Mon, 09 Jun 2014 19:43:28 +0100 Subject: [Rdo-list] Heat installation config In-Reply-To: References: Message-ID: <53960050.5040906@redhat.com> On 06/09/2014 06:43 PM, Ajay Kalambur (akalambu) wrote: > Hi > The RDO answers_file has a config parameter as follow > # Set to 'y' if you would like Packstack to install OpenStack > # Orchestration (Heat) > CONFIG_HEAT_INSTALL=n > > > Even if this is set to n heat seems to have installed and i can run the heat CLIs > > What actually is this parameter intended for? Not answering your specific question, but FYI improved heat support is coming in the next packstack version: https://bugzilla.redhat.com/1076172 https://bugzilla.redhat.com/1103382 thanks, P?draig. From akalambu at cisco.com Mon Jun 9 18:45:41 2014 From: akalambu at cisco.com (Ajay Kalambur (akalambu)) Date: Mon, 9 Jun 2014 18:45:41 +0000 Subject: [Rdo-list] Tempest with RDO In-Reply-To: <5395FF54.4040004@redhat.com> References: <5395FF54.4040004@redhat.com> Message-ID: Hi P?draig Are these tests different from the existing tempest suites? Is there a list of what all tests would be covered here? Ajay On 6/9/14, 11:39, "P?draig Brady" wrote: >On 06/09/2014 06:55 PM, Ajay Kalambur (akalambu) wrote: >> Hi >> When i ask RDO to configure and install tempest it needs to install >>dependencies like testtools, fixtures, mock, oslotest module i presumed >> But all the tests fail because none of these modules are installed by >>RDO >> >> >> I followed the instructions here to try to get tempest working and it >>does not work >> http://openstack.redhat.com/Testing_IceHouse_using_Tempest >> >> Because the tempest installation does not install these modules > >That documentation is possibly incomplete or out of date. >We're currently working on a new tempest package on Fedora 20 at least: >https://bugzilla.redhat.com/1103875 > >thanks, >P?draig. > From rdo-list at dseven.org Tue Jun 10 05:25:18 2014 From: rdo-list at dseven.org (iain MacDonnell) Date: Mon, 9 Jun 2014 22:25:18 -0700 Subject: [Rdo-list] Separating neutron-server from network node Message-ID: My desired architecture includes a Linux VM which runs the controller parts of OpenStack (including all of the API endpoints), one (for now) bare-metal network node (L3, DHCP and maybe metadata) and many bare-metal compute nodes. I'm trying to install thusly: CONTROLLER=10.0.1.10 NETNODE=10.0.2.10 COMPUTENODES=10.0.2.20,10.0.2.21,10.0.2.22,... TENANT_NET_TYPE=vlan VLAN_RANGES=pubphysnet01,priphysnet01:100:199 BRIDGE_MAPPINGS=priphysnet01:br-bond0 BRIDGE_INTERFACES=br-bond0:bond0 packstack \ --neutron-l2-plugin=ml2 \ --neutron-ml2-type-drivers=flat,${TENANT_NET_TYPE} \ --neutron-ml2-tenant-network-types=${TENANT_NET_TYPE} \ --neutron-ml2-mechanism-drivers=openvswitch \ --neutron-ml2-flat-networks=pubphysnet01 \ --neutron-ml2-vlan-ranges="${VLAN_RANGES}" \ --neutron-ovs-bridge-mappings="${BRIDGE_MAPPINGS}" \ --neutron-ovs-bridge-interfaces="${BRIDGE_INTERFACES}" \ --neutron-l3-hosts=${NETNODE} \ --neutron-dhcp-hosts=${NETNODE} \ --neutron-metadata-hosts=${NETNODE} \ --install-hosts=${CONTROLLER},${COMPUTENODES} This presents two problems: 1) (less intrusive, but annoying) neutron-openvswitch-agent is installed and enabled on the controller VM, which I don't want (I can disable the service, 'neutron agent-delete', and unwind the ovs config that it did) 2) neutron-server gets launched on the network node (10.0.2.10) as well as the controller (10.0.1.10). Curiously, the service is not enabled on the network node (chkconfig --list shows 'off'), but it is running when packstack completes. This causes mass confusion for the agents, as there are two neutron-server's running at the same time. It results in obscure problems, including apparent messaging failures, and agents reporting tables missing from the database (neutron.conf on the network node doesn't have the SQL connection info). Am I doing something wrong here? Should it work as above? I can file a bug or two, but thought I'd check here first.... Tnx, ~iain From whayutin at redhat.com Tue Jun 10 11:10:57 2014 From: whayutin at redhat.com (whayutin) Date: Tue, 10 Jun 2014 07:10:57 -0400 Subject: [Rdo-list] Tempest with RDO In-Reply-To: References: <5395FF54.4040004@redhat.com> Message-ID: <1402398657.3022.2.camel@localhost.localdomain> On Mon, 2014-06-09 at 18:45 +0000, Ajay Kalambur (akalambu) wrote: > Hi P?draig > > Are these tests different from the existing tempest suites? > Is there a list of what all tests would be covered here? > Ajay Hey Ajay.. The default source for tempest in packstack is https://github.com/openstack/tempest. It is configurable in your packstack config file. CONFIG_PROVISION_TEMPEST_REPO_URI=https://github.com/openstack/tempest.git To get the required python modules you can cd into your tempest dir and execute: pip install -r requirements.txt Hope this helps > > On 6/9/14, 11:39, "P?draig Brady" wrote: > > >On 06/09/2014 06:55 PM, Ajay Kalambur (akalambu) wrote: > >> Hi > >> When i ask RDO to configure and install tempest it needs to install > >>dependencies like testtools, fixtures, mock, oslotest module i presumed > >> But all the tests fail because none of these modules are installed by > >>RDO > >> > >> > >> I followed the instructions here to try to get tempest working and it > >>does not work > >> http://openstack.redhat.com/Testing_IceHouse_using_Tempest > >> > >> Because the tempest installation does not install these modules > > > >That documentation is possibly incomplete or out of date. > >We're currently working on a new tempest package on Fedora 20 at least: > >https://bugzilla.redhat.com/1103875 > > > >thanks, > >P?draig. > > > > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list From lars at redhat.com Tue Jun 10 14:23:30 2014 From: lars at redhat.com (Lars Kellogg-Stedman) Date: Tue, 10 Jun 2014 10:23:30 -0400 Subject: [Rdo-list] Separating neutron-server from network node In-Reply-To: References: Message-ID: <20140610142330.GC9921@redhat.com> > Am I doing something wrong here? Should it work as above? I can file a > bug or two, but thought I'd check here first.... I've noticed that the openvswitch agent gets installed (and configured) on the controller. This can actually cause the install to fail if the controller does not have an interface matching CONFIG_NEUTRON_OVS_TUNNEL_IF. I think you should open bugs on both of these issues. -- Lars Kellogg-Stedman | larsks @ irc Cloud Engineering / OpenStack | " " @ twitter -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From eberg at rubensteintech.com Tue Jun 10 22:16:29 2014 From: eberg at rubensteintech.com (Eric Berg) Date: Tue, 10 Jun 2014 18:16:29 -0400 Subject: [Rdo-list] Simplest Icehouse Implementation Architecture In-Reply-To: <20140604141202.GA25121@redhat.com> References: <53878AFD.4010909@rubensteintech.com> <20140529193912.GC7137@redhat.com> <538792B0.8050500@rubensteintech.com> <5388C085.7080805@rubensteintech.com> <538DE1EF.6050704@rubensteintech.com> <20140604141202.GA25121@redhat.com> Message-ID: <539783BD.100@rubensteintech.com> On 6/4/14, 10:12 AM, Lars Kellogg-Stedman wrote: > On Tue, Jun 03, 2014 at 10:55:43AM -0400, Eric Berg wrote: >> I have performed this installation and now have a control host and one >> compute host, but am not sure of a few things: >> >> 1. First, I believe that I need nova-networking running on each compute >> hosts to avoid routing all traffic through a dedicated network host, >> but I'm not sure how to check to see that the networking service is >> running on my compute host. >> 2. Lars helped me set up a single-host setup, which put my instances on >> our 192.168.0.0/16 network by using an ovs bridge (br-ex) with the >> IP of the host on the bridge, which owns eth0, but I'm not sure how >> that relates to this new setup. Should I create the same type of >> bridged connection on each compute host? > Eric, > > If you're working with the configuration you and I worked on, you're > using neutron, so you can't use nova-networking on each compute host, > unless you decide to ditch neutron. > > Neutron does not have an operational model matching nova-network's > multi-host mode. > > You can set up Neutron in an active/passive configuration if you want > to have some fault tolerance, but a given external network is always > going to route through a single node when using the native Linux layer > 3 agent. > > You can use vendor plugins from Cisco, etc., if you need a more > performant configuration (but I don't have any details on what that > would look like). I bailed on neutron. I did a packstack install with CONFIG_NEUTRON_INSTALL=n and got a set-up with one control host and one (so far) compute node from which I can ssh/ping hosts on my network. ...but not all hosts, since there's no easy routing into my private OpenStack network. Lars, I believe that when you suggested that we set up a bridge on the neutron allinone install you helped me through first, we created an ovs bridge with the IP of the primary interface, then made that interface part of the bridge. That was so that packets hitting that interface would traverse the bridge to the private network(s) on which the instances reside, so that they would have general access to my company intranet, thus the internet in general. How do I make my cloud instances visible on my intranet with this configuration? -- Eric Berg Sr. Software Engineer Rubenstein Technology Group From eberg at rubensteintech.com Wed Jun 11 00:38:23 2014 From: eberg at rubensteintech.com (Eric Berg) Date: Tue, 10 Jun 2014 20:38:23 -0400 Subject: [Rdo-list] Simplest Icehouse Implementation Architecture In-Reply-To: <539783BD.100@rubensteintech.com> References: <53878AFD.4010909@rubensteintech.com> <20140529193912.GC7137@redhat.com> <538792B0.8050500@rubensteintech.com> <5388C085.7080805@rubensteintech.com> <538DE1EF.6050704@rubensteintech.com> <20140604141202.GA25121@redhat.com> <539783BD.100@rubensteintech.com> Message-ID: <5397A4FF.6020608@rubensteintech.com> I've done a fresh RDO install and am successfully running instances on my compute host, but, while I can connect out of my instances just fine, I can't get into them from any host but my compute host. I thought that RDO was going to set me up so that each compute host handled the routing directly, but it appears that all of my instance's traffic is routing through a bridge to my control host. My compute and control hosts are on a 192.168.0.0/16 network and are using 192.168.20.0/24 for the instances. How do I get traffic routing into my instance hosts on 192.168.20.0/24 on each compute host? (I only have one now, but will be deploying 2 more once I have OpenStack set up. Eric ps please excuse my having also posted this on the openstack list as well. On 6/10/14, 6:16 PM, Eric Berg wrote: > > On 6/4/14, 10:12 AM, Lars Kellogg-Stedman wrote: >> On Tue, Jun 03, 2014 at 10:55:43AM -0400, Eric Berg wrote: >>> I have performed this installation and now have a control host and one >>> compute host, but am not sure of a few things: >>> >>> 1. First, I believe that I need nova-networking running on each compute >>> hosts to avoid routing all traffic through a dedicated network >>> host, >>> but I'm not sure how to check to see that the networking service is >>> running on my compute host. >>> 2. Lars helped me set up a single-host setup, which put my instances on >>> our 192.168.0.0/16 network by using an ovs bridge (br-ex) with the >>> IP of the host on the bridge, which owns eth0, but I'm not sure how >>> that relates to this new setup. Should I create the same type of >>> bridged connection on each compute host? >> Eric, >> >> If you're working with the configuration you and I worked on, you're >> using neutron, so you can't use nova-networking on each compute host, >> unless you decide to ditch neutron. >> >> Neutron does not have an operational model matching nova-network's >> multi-host mode. >> >> You can set up Neutron in an active/passive configuration if you want >> to have some fault tolerance, but a given external network is always >> going to route through a single node when using the native Linux layer >> 3 agent. >> >> You can use vendor plugins from Cisco, etc., if you need a more >> performant configuration (but I don't have any details on what that >> would look like). > I bailed on neutron. I did a packstack install with > CONFIG_NEUTRON_INSTALL=n and got a set-up with one control host and > one (so far) compute node from which I can ssh/ping hosts on my > network. ...but not all hosts, since there's no easy routing into my > private OpenStack network. > > Lars, I believe that when you suggested that we set up a bridge on the > neutron allinone install you helped me through first, we created an > ovs bridge with the IP of the primary interface, then made that > interface part of the bridge. That was so that packets hitting that > interface would traverse the bridge to the private network(s) on which > the instances reside, so that they would have general access to my > company intranet, thus the internet in general. > > How do I make my cloud instances visible on my intranet with this > configuration? > > > -- Eric Berg Sr. Software Engineer Rubenstein Technology Group 55 Broad Street, 14th Floor New York, NY 10004-2501 (212) 518-6400 (212) 518-6467 fax eberg at rubensteintech.com www.rubensteintech.com From lars at redhat.com Wed Jun 11 01:18:14 2014 From: lars at redhat.com (Lars Kellogg-Stedman) Date: Tue, 10 Jun 2014 21:18:14 -0400 Subject: [Rdo-list] Simplest Icehouse Implementation Architecture In-Reply-To: <539783BD.100@rubensteintech.com> References: <53878AFD.4010909@rubensteintech.com> <20140529193912.GC7137@redhat.com> <538792B0.8050500@rubensteintech.com> <5388C085.7080805@rubensteintech.com> <538DE1EF.6050704@rubensteintech.com> <20140604141202.GA25121@redhat.com> <539783BD.100@rubensteintech.com> Message-ID: <20140611011814.GA1107@redhat.com> On Tue, Jun 10, 2014 at 06:16:29PM -0400, Eric Berg wrote: > How do I make my cloud instances visible on my intranet with this > configuration? I'm not particularly familiar with nova-network (I've been using Neutron exclusively for some time, and I've forgotten most of what I used to know about nova-network), so I'll defer to someone else on this one. -- Lars Kellogg-Stedman | larsks @ irc Cloud Engineering / OpenStack | " " @ twitter -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From bderzhavets at hotmail.com Wed Jun 11 06:40:33 2014 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Wed, 11 Jun 2014 02:40:33 -0400 Subject: [Rdo-list] RDO IceHouse Setup Two Node (Controller+Compute) Neutron ML2&OVS&GRE Cluster on Fedora 20 Message-ID: Two KVMs have been created , each one having 2 virtual NICs (eth0,eth1) for Controller && Compute Nodes setup. Before running `packstack --answer-file=twoNode-answer.txt` SELINUX set to permissive on both nodes. Both eth1's assigned IPs from GRE Libvirts subnet before installation and set to promiscuous mode (192.168.122.127, 192.168.122.137 ). Packstack bind to public IP - eth0 192.169.142.127 , Compute Node 192.169.142.137 Answer file been used by packstack here http://textuploader.com/0ei8 Not sure my answer file is 100% correct, however it successful completion doesn't create file ml2_plugin.ini,/etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini on Controller && Compute Nodes which are required by Neutron ML2 plugin && OVS agent. This files have been manually created under /etc/neutron afterwards and allowed to configure neutron OVS agent on both nodes.Files missing after packstack run were created following http://kashyapc.fedorapeople.org/virt/openstack/rdo/IceHouse-Nova-Neutron-ML2-GRE-OVS.txt -------------- next part -------------- An HTML attachment was scrubbed... URL: From kchamart at redhat.com Wed Jun 11 08:06:58 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Wed, 11 Jun 2014 13:36:58 +0530 Subject: [Rdo-list] RDO IceHouse Setup Two Node (Controller+Compute) Neutron ML2&OVS&GRE Cluster on Fedora 20 In-Reply-To: References: Message-ID: <20140611080658.GT8813@tesla> On Wed, Jun 11, 2014 at 02:40:33AM -0400, Boris Derzhavets wrote: > Two KVMs have been created , each one having 2 virtual NICs (eth0,eth1) for > > Controller > && Compute Nodes setup. Before running `packstack > --answer-file=twoNode-answer.txt` SELINUX set to permissive on both > nodes. > > Both eth1's assigned IPs from GRE Libvirts subnet before installation and set > > to promiscuous mode (192.168.122.127, 192.168.122.137 ). Packstack bind to > > public IP - eth0 192.169.142.127 , Compute Node 192.169.142.137 > > > Answer file been used by packstack here http://textuploader.com/0ei8 > > Not sure my answer file is 100% > correct, however it successful completion doesn't create file > ml2_plugin.ini,/etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini > on Controller && Compute Nodes which are required by Neutron ML2 plugin && OVS agent. > This files have been manually created under /etc/neutron afterwards and > allowed to configure neutron OVS agent on both nodes.Files missing after packstack run were created following http://kashyapc.fedorapeople.org/virt/openstack/rdo/IceHouse-Nova-Neutron-ML2-GRE-OVS.txt I don't know if you have a question here. However, here's my routing info and `ip -a` result of both Controller and Compute nodes: https://gist.github.com/kashyapc/76af65d4040886652cf4 -- /kashyap From bderzhavets at hotmail.com Wed Jun 11 09:32:19 2014 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Wed, 11 Jun 2014 05:32:19 -0400 Subject: [Rdo-list] RDO IceHouse Setup Two Node (Controller+Compute) Neutron ML2&OVS&GRE Cluster on Fedora 20 In-Reply-To: <20140611080658.GT8813@tesla> References: , <20140611080658.GT8813@tesla> Message-ID: No. I just created non admin tenant and verified ability to launch instance by tenant's user. I want to thank you one more time for link http://kashyapc.fedorapeople.org/virt/openstack/rdo/IceHouse-Nova-Neutron-ML2-GRE-OVS.txt Your samples are perfect as always. I have Ubuntu 14.04 (with xorg&fluxbox installed) instance running on Compute node (4GB RAM, 2VCPUS) via nested KVM Boris. > I don't know if you have a question here. > > However, here's my routing info and `ip -a` result of both Controller > and Compute nodes: > > https://gist.github.com/kashyapc/76af65d4040886652cf4 > > -- > /kashyap -------------- next part -------------- An HTML attachment was scrubbed... URL: From eberg at rubensteintech.com Wed Jun 11 14:15:15 2014 From: eberg at rubensteintech.com (Eric Berg) Date: Wed, 11 Jun 2014 10:15:15 -0400 Subject: [Rdo-list] Simplest Icehouse Implementation Architecture In-Reply-To: <20140611011814.GA1107@redhat.com> References: <53878AFD.4010909@rubensteintech.com> <20140529193912.GC7137@redhat.com> <538792B0.8050500@rubensteintech.com> <5388C085.7080805@rubensteintech.com> <538DE1EF.6050704@rubensteintech.com> <20140604141202.GA25121@redhat.com> <539783BD.100@rubensteintech.com> <20140611011814.GA1107@redhat.com> Message-ID: <53986473.806@rubensteintech.com> Thanks, Lars. Sometimes it's just good to have your request/existence acknowledged. Turns out that in this 25th install, I forgot the icmp/ssh rules. That fixed it. I'm in business. (woo f'in hoo!!) Now the real fun begins. Thanks for your help. It's much appreciated. On Tue Jun 10 21:18:14 2014, Lars Kellogg-Stedman wrote: > On Tue, Jun 10, 2014 at 06:16:29PM -0400, Eric Berg wrote: >> How do I make my cloud instances visible on my intranet with this >> configuration? > > I'm not particularly familiar with nova-network (I've been using > Neutron exclusively for some time, and I've forgotten most of what I > used to know about nova-network), so I'll defer to someone else on > this one. > -- Eric Berg Sr. Software Engineer Rubenstein Technology Group 55 Broad Street, 14th Floor New York, NY 10004-2501 (212) 518-6400 (212) 518-6467 fax eberg at rubensteintech.com www.rubensteintech.com From akalambu at cisco.com Thu Jun 12 17:24:45 2014 From: akalambu at cisco.com (Ajay Kalambur (akalambu)) Date: Thu, 12 Jun 2014 17:24:45 +0000 Subject: [Rdo-list] Foreman installation Message-ID: Hi Not sure if this is the right list for RDO/Foreman but i am trying to install RDO/Icehouse with Foreman on fedora and tried to install foreman installer with the following commands I ran the following commands and it cant locate the foreman installer sudo yum install -y http://repos.fedorapeople.org/repos/openstack/openstack-icehouse/rdo-release-icehouse-3.noarch.rpm 2 sudo yum install -y openstack-foreman-installer sudo yum install -y openstack-foreman-installer Loaded plugins: langpacks, refresh-packagekit No package openstack-foreman-installer available. Anyone tried foreman installer on Fedora. If so what is the correct repository the rdo-release-icehouse does not seem to have openstack-foreman-installer Ajay -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbrady at redhat.com Thu Jun 12 19:10:31 2014 From: pbrady at redhat.com (=?ISO-8859-1?Q?P=E1draig_Brady?=) Date: Thu, 12 Jun 2014 20:10:31 +0100 Subject: [Rdo-list] Foreman installation In-Reply-To: References: Message-ID: <5399FB27.9070906@redhat.com> On 06/12/2014 06:24 PM, Ajay Kalambur (akalambu) wrote: > Hi > Not sure if this is the right list for RDO/Foreman but i am trying to install RDO/Icehouse with Foreman on fedora and tried to install foreman installer with the following commands > I ran the following commands and it cant locate the foreman installer > sudo yum install -y http://repos.fedorapeople.org/repos/openstack/openstack-icehouse/rdo-release-icehouse-3.noarch.rpm > 2 sudo yum install -y openstack-foreman-installer > > sudo yum install -y openstack-foreman-installer > Loaded plugins: langpacks, refresh-packagekit > No package openstack-foreman-installer available. > > Anyone tried foreman installer on Fedora. If so what is the correct repository the rdo-release-icehouse does not seem to have openstack-foreman-installer foreman is only supported on el6 currently. sorry, P?draig. From kchamart at redhat.com Fri Jun 13 06:37:08 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Fri, 13 Jun 2014 12:07:08 +0530 Subject: [Rdo-list] Foreman installation In-Reply-To: References: Message-ID: <20140613063708.GN29542@tesla.pnq.redhat.com> On Thu, Jun 12, 2014 at 05:24:45PM +0000, Ajay Kalambur (akalambu) wrote: > Hi > Not sure if this is the right list for RDO/Foreman but i am trying to > install RDO/Icehouse with Foreman on fedora and tried to install > foreman installer with the following commands I ran the following > commands and it cant locate the foreman installer sudo yum install -y > http://repos.fedorapeople.org/repos/openstack/openstack-icehouse/rdo-release-icehouse-3.noarch.rpm > 2 sudo yum install -y openstack-foreman-installer > > sudo yum install -y openstack-foreman-installer Loaded plugins: > langpacks, refresh-packagekit No package openstack-foreman-installer > available. > > Anyone tried foreman installer on Fedora. If so what is the correct > repository the rdo-release-icehouse does not seem to have > openstack-foreman-installer FWIW, I recently checked w/ Foreman upstream, it's yet to arrive in Fedora-20 and above due to Ruby on Rails dependency issues. They indicated Fedora-21 would be a likely candidate where you might see Foreman in Fedora. -- /kashyap From gareth at openstacker.org Fri Jun 13 08:20:22 2014 From: gareth at openstacker.org (Kun Huang) Date: Fri, 13 Jun 2014 16:20:22 +0800 Subject: [Rdo-list] [RDO] how does RDO install package openstack-puppet-module Message-ID: Hi I need apply a very small patch for that package, so I need find the place where RDO install it. It seems here[0]. But when testing it, I find in the line[1], variable deps is [puppet, openssh-clients, tar, rc, rubygem-json] without 'openstack-puppet-module'. So where is the place RDO install the openstack-puppet-module? [0] https://github.com/stackforge/packstack/blob/master/packstack/plugins/puppet_950.py#L131-L152 [1] https://github.com/stackforge/packstack/blob/master/packstack/plugins/puppet_950.py#L150 From pbrady at redhat.com Fri Jun 13 10:51:47 2014 From: pbrady at redhat.com (=?ISO-8859-1?Q?P=E1draig_Brady?=) Date: Fri, 13 Jun 2014 11:51:47 +0100 Subject: [Rdo-list] [RDO] how does RDO install package openstack-puppet-module In-Reply-To: References: Message-ID: <539AD7C3.9090609@redhat.com> On 06/13/2014 09:20 AM, Kun Huang wrote: > Hi > > I need apply a very small patch for that package, so I need find the > place where RDO install it. > > It seems here[0]. But when testing it, I find in the line[1], variable > deps is [puppet, openssh-clients, tar, rc, rubygem-json] without > 'openstack-puppet-module'. So where is the place RDO install the > openstack-puppet-module? > > [0] https://github.com/stackforge/packstack/blob/master/packstack/plugins/puppet_950.py#L131-L152 > [1] https://github.com/stackforge/packstack/blob/master/packstack/plugins/puppet_950.py#L150 I think this is hinted at in: https://github.com/stackforge/packstack/blob/3d92f24c/packstack/plugins/puppet_950.py#L140-145 The openstack-puppet-modules package is a requirement of the packstack package and installed when that rpm is installed automatically. That's on the host packstack is being run from. On other hosts, packstack avoids rom and distributes the (adjusted) puppet modules using ssh I think. So in summary if you regenerate and install the openstack-puppet-modules package on the host packstack is being run from, the distribution should happen automatically on other hosts. thanks, P?draig. From akalambu at cisco.com Fri Jun 13 16:02:15 2014 From: akalambu at cisco.com (Ajay Kalambur (akalambu)) Date: Fri, 13 Jun 2014 16:02:15 +0000 Subject: [Rdo-list] Foreman installation In-Reply-To: <5399FB27.9070906@redhat.com> References: <5399FB27.9070906@redhat.com> Message-ID: Do we have updated instructions for icehouse for RHEL. The instructions on the page are for havana Ajay On 6/12/14, 12:10, "P?draig Brady" wrote: >On 06/12/2014 06:24 PM, Ajay Kalambur (akalambu) wrote: >> Hi >> Not sure if this is the right list for RDO/Foreman but i am trying to >>install RDO/Icehouse with Foreman on fedora and tried to install foreman >>installer with the following commands >> I ran the following commands and it cant locate the foreman installer >> sudo yum install -y >>http://repos.fedorapeople.org/repos/openstack/openstack-icehouse/rdo-rele >>ase-icehouse-3.noarch.rpm >> 2 sudo yum install -y openstack-foreman-installer >> >> sudo yum install -y openstack-foreman-installer >> Loaded plugins: langpacks, refresh-packagekit >> No package openstack-foreman-installer available. >> >> Anyone tried foreman installer on Fedora. If so what is the correct >>repository the rdo-release-icehouse does not seem to have >>openstack-foreman-installer > >foreman is only supported on el6 currently. > >sorry, >P?draig. > From akalambu at cisco.com Fri Jun 13 16:25:13 2014 From: akalambu at cisco.com (Ajay Kalambur (akalambu)) Date: Fri, 13 Jun 2014 16:25:13 +0000 Subject: [Rdo-list] Foreman installation In-Reply-To: References: <5399FB27.9070906@redhat.com> Message-ID: The following wiki documents Foreman install steps http://openstack.redhat.com/Deploying_RDO_using_Foreman Can someone share the commands for Icehouse Foreman release yum-config-manager --enable rhel-6-server-rpms yum-config-manager --enable rhel-6-server-optional-rpmsFor all systems, you will also want the following two repositories: yum install http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.r pm yum install http://repos.fedorapeople.org/repos/openstack/openstack-havana/rdo-release- havana-7.noarch.rpm Ajay On 6/13/14, 9:02, "Ajay Kalambur (akalambu)" wrote: >Do we have updated instructions for icehouse for RHEL. The instructions on >the page are for havana > >Ajay > > > >On 6/12/14, 12:10, "P?draig Brady" wrote: > >>On 06/12/2014 06:24 PM, Ajay Kalambur (akalambu) wrote: >>> Hi >>> Not sure if this is the right list for RDO/Foreman but i am trying to >>>install RDO/Icehouse with Foreman on fedora and tried to install foreman >>>installer with the following commands >>> I ran the following commands and it cant locate the foreman installer >>> sudo yum install -y >>>http://repos.fedorapeople.org/repos/openstack/openstack-icehouse/rdo-rel >>>e >>>ase-icehouse-3.noarch.rpm >>> 2 sudo yum install -y openstack-foreman-installer >>> >>> sudo yum install -y openstack-foreman-installer >>> Loaded plugins: langpacks, refresh-packagekit >>> No package openstack-foreman-installer available. >>> >>> Anyone tried foreman installer on Fedora. If so what is the correct >>>repository the rdo-release-icehouse does not seem to have >>>openstack-foreman-installer >> >>foreman is only supported on el6 currently. >> >>sorry, >>P?draig. >> > From gareth at openstacker.org Sat Jun 14 04:28:20 2014 From: gareth at openstacker.org (Kun Huang) Date: Sat, 14 Jun 2014 12:28:20 +0800 Subject: [Rdo-list] [RDO] how does RDO install package openstack-puppet-module In-Reply-To: <539AD7C3.9090609@redhat.com> References: <539AD7C3.9090609@redhat.com> Message-ID: Thanks Brady, So if I install packstack on node1, and want to install a all-in-one openstack on node2. Are that packstack and openstack-puppet-module only installed on node1? And the method install_deps actually has no relationship with the behavior of installing openstacl-puppet-module. On Fri, Jun 13, 2014 at 6:51 PM, P?draig Brady wrote: > On 06/13/2014 09:20 AM, Kun Huang wrote: >> Hi >> >> I need apply a very small patch for that package, so I need find the >> place where RDO install it. >> >> It seems here[0]. But when testing it, I find in the line[1], variable >> deps is [puppet, openssh-clients, tar, rc, rubygem-json] without >> 'openstack-puppet-module'. So where is the place RDO install the >> openstack-puppet-module? >> >> [0] https://github.com/stackforge/packstack/blob/master/packstack/plugins/puppet_950.py#L131-L152 >> [1] https://github.com/stackforge/packstack/blob/master/packstack/plugins/puppet_950.py#L150 > > I think this is hinted at in: > https://github.com/stackforge/packstack/blob/3d92f24c/packstack/plugins/puppet_950.py#L140-145 > > The openstack-puppet-modules package is a requirement of the packstack package > and installed when that rpm is installed automatically. > That's on the host packstack is being run from. > On other hosts, packstack avoids rom and distributes the (adjusted) puppet modules > using ssh I think. > > So in summary if you regenerate and install the openstack-puppet-modules > package on the host packstack is being run from, the distribution > should happen automatically on other hosts. > > thanks, > P?draig. From pbrady at redhat.com Sat Jun 14 10:57:11 2014 From: pbrady at redhat.com (=?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?=) Date: Sat, 14 Jun 2014 11:57:11 +0100 Subject: [Rdo-list] [RDO] how does RDO install package openstack-puppet-module In-Reply-To: References: <539AD7C3.9090609@redhat.com> Message-ID: <539C2A87.5080207@redhat.com> On 06/14/2014 05:28 AM, Kun Huang wrote: > Thanks Brady, > > So if I install packstack on node1, and want to install a all-in-one > openstack on node2. Are that packstack and openstack-puppet-module > only installed on node1? And the method install_deps actually has no > relationship with the behavior of installing openstack-puppet-module. Yes the puppet modules are distributed separately to rpm thanks, P?draig. From rbowen at redhat.com Mon Jun 16 19:32:06 2014 From: rbowen at redhat.com (Rich Bowen) Date: Mon, 16 Jun 2014 15:32:06 -0400 Subject: [Rdo-list] Ceilometer Hangout coming July 9 Message-ID: <539F4636.3060109@redhat.com> Mark your calendars. On July 9, 15:00 UTC (11 am Eastern US time) Eoghan Glynn will be leading a Google Hangout in which he'll discuss hat's new in Ceilometer in OpenStack Icehouse, and what's coming in Juno. https://plus.google.com/events/c6e8vjjn8klrf78ruhkr95j4tas The presentation will also be available (at that same URL) on Youtube after the event. --Rich -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://openstack.redhat.com/ From gareth at openstacker.org Tue Jun 17 05:57:35 2014 From: gareth at openstacker.org (Kun Huang) Date: Tue, 17 Jun 2014 13:57:35 +0800 Subject: [Rdo-list] [RDO] how does RDO install package openstack-puppet-module In-Reply-To: <539C2A87.5080207@redhat.com> References: <539AD7C3.9090609@redhat.com> <539C2A87.5080207@redhat.com> Message-ID: thanks, your explanations help me fix my issues I just run a "patch /path/to/my/file < mypatch.diff" after "yum install openstack-packstack" On Sat, Jun 14, 2014 at 6:57 PM, P?draig Brady wrote: > On 06/14/2014 05:28 AM, Kun Huang wrote: >> Thanks Brady, >> >> So if I install packstack on node1, and want to install a all-in-one >> openstack on node2. Are that packstack and openstack-puppet-module >> only installed on node1? And the method install_deps actually has no >> relationship with the behavior of installing openstack-puppet-module. > > Yes the puppet modules are distributed separately to rpm > > thanks, > P?draig. > From gareth at openstacker.org Tue Jun 17 06:40:23 2014 From: gareth at openstacker.org (Kun Huang) Date: Tue, 17 Jun 2014 14:40:23 +0800 Subject: [Rdo-list] [RDO] deployment details about neutron Message-ID: hi all I have some questions about using RDO deploy neutron (based on ovs). I need: node1: - neutron server node2 (all others): - dhcp agent - ovs agent - l3 agent Now in my understanding, CONFIG_NEUTRON_SERVER_HOST manages neutron server, CONFIG_NEUTRON_DHCP_HOSTS manages dhcp agent, CONFIG_NEUTRON_L3_HOSTS manages l3 agent, and CONFIG_NEUTRON_OVS_HOST l2/ovs agent. Are those correct? Another question is after reading codes in neutron_350.py, I found CONFIG_NEUTRON_L3_HOSTS may not work, because of [0]. It is same about CONFIG_NEUTRON_OVS_HOST [1]. So are there some principles like "l2 agent must be installed on same host with neutron server" [0] https://github.com/stackforge/packstack/blob/master/packstack/plugins/neutron_350.py#L803-L804 [1] https://github.com/stackforge/packstack/blob/master/packstack/plugins/neutron_350.py#L913-L916 From gareth at openstacker.org Tue Jun 17 08:23:22 2014 From: gareth at openstacker.org (Kun Huang) Date: Tue, 17 Jun 2014 16:23:22 +0800 Subject: [Rdo-list] [RDO] deployment details about neutron In-Reply-To: References: Message-ID: I deployed a new cluster with above variables and l3 agent and dhcp agent exists on expected nodes. But ovs agent is running on each node. So the CONFIG_NEUTRON_OVS_HOST doesn't work. On Tue, Jun 17, 2014 at 2:40 PM, Kun Huang wrote: > hi all > > I have some questions about using RDO deploy neutron (based on ovs). I need: > > node1: > - neutron server > > node2 (all others): > - dhcp agent > - ovs agent > - l3 agent > > Now in my understanding, CONFIG_NEUTRON_SERVER_HOST manages neutron > server, CONFIG_NEUTRON_DHCP_HOSTS manages dhcp agent, > CONFIG_NEUTRON_L3_HOSTS manages l3 agent, and CONFIG_NEUTRON_OVS_HOST > l2/ovs agent. Are those correct? > > Another question is after reading codes in neutron_350.py, I found > CONFIG_NEUTRON_L3_HOSTS may not work, because of [0]. It is same about > CONFIG_NEUTRON_OVS_HOST [1]. > > So are there some principles like "l2 agent must be installed on same > host with neutron server" > > [0] https://github.com/stackforge/packstack/blob/master/packstack/plugins/neutron_350.py#L803-L804 > [1] https://github.com/stackforge/packstack/blob/master/packstack/plugins/neutron_350.py#L913-L916 From kchamart at redhat.com Tue Jun 17 09:07:31 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Tue, 17 Jun 2014 14:37:31 +0530 Subject: [Rdo-list] RDO Bug triage today [17JUN2014] Message-ID: <20140617090731.GF3610@tesla.redhat.com> Heya, [I should have sent out this reminder yesterday, sorry :-(] Althought bug triage is done frequently, we thought we'd do a community bug triage (on #rdo @ Freenode) every 3rd Tuesday of each month. Current state of RDO bugs is here[2]. In short, number of bugs in states: NEW, ASSIGNED, ON_DEV : 183 If you want to help, queries for untriaged bugs (and more details) are here[1] or join us on #rdo channel on Freenode. Triaging bugs and doing root-cause analysis is one of the best ways to learn more about OpenStack, RDO and bugzilla workflow in general. Needless to say, triage help on any other day is equally helpful and welcome :-) [1] http://openstack.redhat.com/RDO-BugTriage [2] http://kashyapc.fedorapeople.org/virt/openstack/bugzilla/rdo-bug-status/all-rdo-bugs-17-06-2014.txt -- /kashyap From ihrachys at redhat.com Tue Jun 17 10:11:24 2014 From: ihrachys at redhat.com (Ihar Hrachyshka) Date: Tue, 17 Jun 2014 12:11:24 +0200 Subject: [Rdo-list] [RDO] deployment details about neutron In-Reply-To: References: Message-ID: <53A0144C.4040000@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Quoting [1], "L2 agent should run on all machines except for the Neutron service machine (unless Neutron service resides with other component in the same machine)." That's what you observe. [1]: http://openstack.redhat.com/Neutron_with_OVS_and_VLANs On 17/06/14 10:23, Kun Huang wrote: > I deployed a new cluster with above variables and l3 agent and > dhcp agent exists on expected nodes. But ovs agent is running on > each node. So the CONFIG_NEUTRON_OVS_HOST doesn't work. > > On Tue, Jun 17, 2014 at 2:40 PM, Kun Huang > wrote: >> hi all >> >> I have some questions about using RDO deploy neutron (based on >> ovs). I need: >> >> node1: - neutron server >> >> node2 (all others): - dhcp agent - ovs agent - l3 agent >> >> Now in my understanding, CONFIG_NEUTRON_SERVER_HOST manages >> neutron server, CONFIG_NEUTRON_DHCP_HOSTS manages dhcp agent, >> CONFIG_NEUTRON_L3_HOSTS manages l3 agent, and >> CONFIG_NEUTRON_OVS_HOST l2/ovs agent. Are those correct? >> >> Another question is after reading codes in neutron_350.py, I >> found CONFIG_NEUTRON_L3_HOSTS may not work, because of [0]. It is >> same about CONFIG_NEUTRON_OVS_HOST [1]. >> >> So are there some principles like "l2 agent must be installed on >> same host with neutron server" >> >> [0] >> https://github.com/stackforge/packstack/blob/master/packstack/plugins/neutron_350.py#L803-L804 >> >> [1] https://github.com/stackforge/packstack/blob/master/packstack/plugins/neutron_350.py#L913-L916 > > _______________________________________________ Rdo-list mailing > list Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJToBRMAAoJEC5aWaUY1u573KQH/3K6Rhu6PbzWfqWvxYje+7O6 FzVeY7AvJDx41ddm6p2WaG1L49EPGBb9y450A4lgMNR8WIR57WD1x9aCJutMgOIm fv0o4S5mxvcPG3MJ0ahcUNbdrmr5oQY3dnYJB/36uh4JXczE7utpDO5W6yxk1pnT ywHXgr7Yy6jeYWj2JIkK6O8zTKNhs6brwQYSD+tatVMzLsI4yH3TbIBpVE6FAVsH jH/988S42W8VKycE4CeoGGKeTXKY2xHphnnsLiL/ptGvQcP8rcOF4oNRZknql2Xf zD0vEN48nqfji6bsTbQE480HtwziDFUcq1IDHnxuC87D1oTei/i9TudKQzhjCOg= =l70v -----END PGP SIGNATURE----- From jonas.hagberg at scilifelab.se Tue Jun 17 10:38:03 2014 From: jonas.hagberg at scilifelab.se (Jonas Hagberg) Date: Tue, 17 Jun 2014 12:38:03 +0200 Subject: [Rdo-list] foreman-installer puppet problems: " Error 400 on SERVER: Must pass admin_password to Class[Quickstack::Nova]" Message-ID: Hej I have installed foreman-installer from yum repo icehouce el6 on Scientific linux 6.5 I got foreman up and running and got hostgroups and smart parameters. But when assigning a node to a hostgroup (Neutron controller or neutron compute) and running puppet I get the following error. err: Could not retrieve catalog from remote server: Error 400 on SERVER: Must pass admin_password to Class[Quickstack::Nova] at /usr/share/openstack-foreman-installer/puppet/modules/quickstack/manifests/nova.pp:65 on "fqdn" admin_password is set in hostgroup. Any tips on where the problem could be? Cheers -- Jonas Hagberg BILS - Bioinformatics Infrastructure for Life Sciences - http://bils.se e-mail: jonas.hagberg at bils.se, jonas.hagberg at scilifelab.se phone: +46-(0)70 6683869 address: SciLifeLab, Box 1031, 171 21 Solna, Sweden -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail-lists at karan.org Tue Jun 17 13:44:04 2014 From: mail-lists at karan.org (Karanbir Singh) Date: Tue, 17 Jun 2014 14:44:04 +0100 Subject: [Rdo-list] RDO status on EL7 Message-ID: <53A04624.3080804@karan.org> hi guys, Just wondering what the status of RDO on EL7 was, the quickstart still only mentions 6.5 as being the supported ( tested ? ) version. - KB -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From ihrachys at redhat.com Tue Jun 17 13:55:04 2014 From: ihrachys at redhat.com (Ihar Hrachyshka) Date: Tue, 17 Jun 2014 15:55:04 +0200 Subject: [Rdo-list] RDO status on EL7 In-Reply-To: <53A04624.3080804@karan.org> References: <53A04624.3080804@karan.org> Message-ID: <53A048B8.7040900@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, RDO for RHEL 7 should be as (community) supported as RDO for RHEL 6.5 is. BTW Quickstart also mentions RHEL7 in 'Step 3', and RHEL 6.5 is claimed to be 'the *minimum* recommended version'. Cheers, /Ihar On 17/06/14 15:44, Karanbir Singh wrote: > hi guys, > > Just wondering what the status of RDO on EL7 was, the quickstart > still only mentions 6.5 as being the supported ( tested ? ) > version. > > - KB > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJToEi3AAoJEC5aWaUY1u57IMMH/jAAl7YvFGjVJ7GnjCtWYKx3 UknVH4Ndo63Wh0lrZNHmDGObNJDIQ5tXypqcnaL1DXDs8pdTZoff7LP5Q0BD35ub zsiM2Zm9DTQJNepNn5oZC5Cm6czFEV5Ipfi4L5jKtQy4P9YAQy8/GBmPtgOgT7mE ilpViQ8618d1szA6ryoYYDNTF88+X66G34bXk8rEqqiz70qd/nau4G1wR4R8wTU1 W9MOp8W3lOvRhgbOHMigRJcYwK+5ybsywplSALmC62z3l+kuHTdeE+pJUNssTXHa EtI6kHoDmohdj6+kdXWoIquNxFKsvy0UYH+nc3WdTe9fyNrXjkmBOSuXTMQQKgI= =mOIV -----END PGP SIGNATURE----- From lars at redhat.com Tue Jun 17 15:10:58 2014 From: lars at redhat.com (Lars Kellogg-Stedman) Date: Tue, 17 Jun 2014 11:10:58 -0400 Subject: [Rdo-list] foreman-installer puppet problems: " Error 400 on SERVER: Must pass admin_password to Class[Quickstack::Nova]" In-Reply-To: References: Message-ID: <20140617151058.GA518@redhat.com> On Tue, Jun 17, 2014 at 12:38:03PM +0200, Jonas Hagberg wrote: > But when assigning a node to a hostgroup (Neutron controller or neutron > compute) and running puppet I get the following error. > > err: Could not retrieve catalog from remote server: Error 400 on SERVER: > Must pass admin_password to Class[Quickstack::Nova] at > /usr/share/openstack-foreman-installer/puppet/modules/quickstack/manifests/nova.pp:65 > on "fqdn" > > admin_password is set in hostgroup. If you haven't already you probably want to open a bug report on this (https://bugzilla.redhat.com/enter_bug.cgi?product=RDO). -- Lars Kellogg-Stedman | larsks @ irc Cloud Engineering / OpenStack | " " @ twitter -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rbowen at redhat.com Tue Jun 17 13:52:45 2014 From: rbowen at redhat.com (Rich Bowen) Date: Tue, 17 Jun 2014 09:52:45 -0400 Subject: [Rdo-list] RDO status on EL7 In-Reply-To: <53A04624.3080804@karan.org> References: <53A04624.3080804@karan.org> Message-ID: <53A0482D.9060605@redhat.com> On 06/17/2014 09:44 AM, Karanbir Singh wrote: > hi guys, > > Just wondering what the status of RDO on EL7 was, the quickstart still > only mentions 6.5 as being the supported ( tested ? ) version. I was planning to install EL7 today and go through the quickstart. I expect that someone else has already done this. (?) -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://openstack.redhat.com/ From rbowen at redhat.com Tue Jun 17 15:54:42 2014 From: rbowen at redhat.com (Rich Bowen) Date: Tue, 17 Jun 2014 11:54:42 -0400 Subject: [Rdo-list] RDO status on EL7 In-Reply-To: <53A0482D.9060605@redhat.com> References: <53A04624.3080804@karan.org> <53A0482D.9060605@redhat.com> Message-ID: <53A064C2.5060200@redhat.com> On 06/17/2014 09:52 AM, Rich Bowen wrote: > > On 06/17/2014 09:44 AM, Karanbir Singh wrote: >> hi guys, >> >> Just wondering what the status of RDO on EL7 was, the quickstart still >> only mentions 6.5 as being the supported ( tested ? ) version. > > I was planning to install EL7 today and go through the quickstart. I > expect that someone else has already done this. (?) > I mean CentOS 7, rather. -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://openstack.redhat.com/ From xzhao at bnl.gov Tue Jun 17 18:42:54 2014 From: xzhao at bnl.gov (Zhao, Xin) Date: Tue, 17 Jun 2014 14:42:54 -0400 Subject: [Rdo-list] question about load balance controller Message-ID: <53A08C2E.1010103@bnl.gov> Hello, I want to put several controllers behind a load balancer (HAProxy or F5). I know the APIs can be load-balanced, but how about the other services, like: 1) nova scheduler; 2) FS for the images of glance services ? I use local disk for storing images of glance. If two glance services are behind VIP, how does it make sure images uploaded to one glance local disk is also known to the other glance ? For nova scheduler, will one scheduler per controller cause any scheduling issue ? Thanks in advance, Xin From whayutin at redhat.com Tue Jun 17 19:18:32 2014 From: whayutin at redhat.com (whayutin) Date: Tue, 17 Jun 2014 15:18:32 -0400 Subject: [Rdo-list] RDO status on EL7 In-Reply-To: <53A04624.3080804@karan.org> References: <53A04624.3080804@karan.org> Message-ID: <1403032712.3723.4.camel@localhost.localdomain> On Tue, 2014-06-17 at 14:44 +0100, Karanbir Singh wrote: > hi guys, > > Just wondering what the status of RDO on EL7 was, the quickstart still > only mentions 6.5 as being the supported ( tested ? ) version. > > - KB > You should expect success w/ RDO on RHEL 7 w/ aio, and multi node configurations. There is an open bug on neutron w/ vxlan networking atm. GRE and ML2 networking should work. https://bugzilla.redhat.com/show_bug.cgi?id=1081011 From akalambu at cisco.com Tue Jun 17 19:28:27 2014 From: akalambu at cisco.com (Ajay Kalambur (akalambu)) Date: Tue, 17 Jun 2014 19:28:27 +0000 Subject: [Rdo-list] RHEL 6.5 Openstack foreman Message-ID: Hi I tried to install openstack-foreman-installer on RHEL 6.5 using steps below sudo yum-config-manager --enable rhel-6-server-rpms sudo yum install yum-config-manager --enable rhel-6-server-optional-rpms sudo yum install http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm sudo yum install -y http://repos.fedorapeople.org/repos/openstack/openstack-icehouse/rdo-release-icehouse-3.noarch.rpm sudo yum install openstack-foreman-installer But i see a lot of missing dependencies when trying to install foreman-installer. Any idea how to fix this? --> Finished Dependency Resolution Error: Package: 1:facter-2.0.2-1.el6.x86_64 (puppetlabs-products) Requires: ruby >= 1.8.7 Error: Package: rubygem-mime-types-1.16-3.el6.noarch (epel) Requires: ruby(abi) = 1.8 Error: Package: ruby193-rubygem-foreigner-1.4.2-1.el6.noarch (foreman) Requires: ruby193-ruby Error: Package: ruby193-rubygem-daemons-1.1.4-7.el6.noarch (foreman) Requires: ruby193-ruby(abi) = 1.9.1 Error: Package: ruby193-rubygem-mysql2-0.3.11-4.el6.x86_64 (foreman) Requires: ruby193-ruby >= 1.8.6 Error: Package: ruby193-rubygem-bundler_ext-0.3.0-3.el6.noarch (foreman) Requires: ruby193-rubygem(bundler) Error: Package: ruby193-rubygem-net-ldap-0.3.1-1.el6.noarch (foreman) Requires: ruby193-ruby(rubygems) Error: Package: rubygem-kafo_parsers-0.0.2-1.el6.noarch (foreman) Requires: rubygems Error: Package: rubygem-powerbar-1.0.11-7.el6.noarch (foreman) Requires: /usr/bin/ruby Error: Package: ruby193-rubygem-audited-activerecord-3.0.0-2.el6.noarch (foreman) Requires: ruby193-ruby(abi) = 1.9.1 Error: Package: ruby193-rubygem-scoped_search-2.7.1-1.el6.noarch (foreman) Requires: ruby193-rubygems Error: Package: ruby193-rubygem-ruby2ruby-2.0.1-7.el6.noarch (foreman) Requires: /opt/rh/ruby193/root/usr/bin/ruby Error: Package: ruby193-rubygem-thin-1.3.1-7.el6.x86_64 (foreman) Requires: ruby193-ruby(rubygems) Error: Package: ruby193-rubygem-safemode-1.2.0-5.el6.noarch (foreman) Requires: ruby193-ruby(abi) = 1.9.1 Error: Package: ruby193-rubygem-apipie-rails-0.1.2-1.el6.noarch (foreman) Requires: ruby193-ruby(abi) = 1.9.1 Error: Package: ruby193-rubygem-ruby_parser-3.1.1-5.el6.noarch (foreman) Requires: ruby193-ruby(abi) = 1.9.1 Error: Package: ruby193-rubygem-rabl-0.9.0-1.el6.noarch (foreman) Requires: ruby193-rubygems Error: Package: ruby-rgen-0.6.5-2.el6.noarch (puppetlabs-deps) Requires: ruby >= 1.8 Error: Package: ruby-augeas-0.4.1-3.el6.x86_64 (puppetlabs-deps) Requires: libaugeas.so.0(AUGEAS_0.11.0)(64bit) Error: Package: rubygem-oauth-0.4.7-5.el6.noarch (foreman) Requires: /usr/bin/ruby Error: Package: ruby-augeas-0.4.1-3.el6.x86_64 (puppetlabs-deps) Requires: libaugeas.so.0()(64bit) Error: Package: rubygem-kafo-0.5.4-1.el6.noarch (foreman) Requires: rubygems Error: Package: ruby-augeas-0.4.1-3.el6.x86_64 (puppetlabs-deps) Requires: libaugeas.so.0(AUGEAS_0.12.0)(64bit) Error: Package: ruby-augeas-0.4.1-3.el6.x86_64 (puppetlabs-deps) Requires: augeas-libs >= 0.8.0 Error: Package: foreman-1.5.0-1.el6.noarch (foreman) Requires: ruby193-rubygems Error: Package: ruby193-rubygem-ancestry-2.0.0-2.el6.noarch (foreman) Requires: ruby193-ruby(abi) = 1.9.1 Error: Package: foreman-1.5.0-1.el6.noarch (foreman) Requires: ruby193-rubygem(json) Error: Package: ruby193-rubygem-po_to_json-0.0.7-2.el6.noarch (foreman) Requires: ruby193-ruby(rubygems) Error: Package: ruby193-rubygem-sass-3.2.13-1.el6.noarch (foreman) Requires: /opt/rh/ruby193/root/usr/bin/ruby Error: Package: puppet-3.6.2-1.el6.noarch (puppetlabs-products) Requires: ruby >= 1.8.7 Error: Package: rubygem-kafo-0.5.4-1.el6.noarch (foreman) Requires: /usr/bin/ruby Error: Package: ruby193-rubygem-nokogiri-1.5.11-1.el6.x86_64 (foreman) Requires: ruby193-ruby(abi) = 1.9.1 Error: Package: rubygem-json-1.5.5-1.el6.x86_64 (puppetlabs-deps) Requires: /usr/bin/ruby Error: Package: puppet-3.6.2-1.el6.noarch (puppetlabs-products) Requires: ruby(selinux) Error: Package: rubygem-rest-client-1.6.1-2.el6.noarch (epel) Requires: ruby(abi) = 1.8 Error: Package: ruby193-rubygem-multi_json-1.8.2-1.el6.noarch (foreman) Requires: ruby193-ruby(abi) = 1.9.1 Error: Package: rubygem-rdoc-3.12-12.el6.x86_64 (foreman) Requires: ruby(abi) = 1.8 Error: Package: rubygem-hashie-2.0.5-0.el6.noarch (foreman) Requires: ruby(abi) = 1.8 Error: Package: ruby193-rubygem-jquery-ui-rails-4.0.2-7.el6.noarch (foreman) Requires: ruby193-rubygem(jquery-rails) Error: Package: ruby193-rubygem-will_paginate-3.0.2-7.el6.noarch (foreman) Requires: ruby193-ruby(abi) = 1.9.1 Error: Package: rubygem-oauth-0.4.7-5.el6.noarch (foreman) Requires: rubygems Error: Package: rubygem-ansi-1.4.3-0.el6.noarch (foreman) Requires: ruby(abi) = 1.8 Error: Package: ruby193-rubygem-apipie-rails-0.1.2-1.el6.noarch (foreman) Requires: ruby193-rubygems Error: Package: ruby193-rubygem-gettext_i18n_rails_js-0.0.8-2.el6.noarch (foreman) Requires: ruby193-rubygem(rails) < 3.3.0 Error: Package: ruby193-rubygem-rest-client-1.6.1-4.el6.noarch (foreman) Requires: /opt/rh/ruby193/root/usr/bin/ruby Error: Package: ruby193-rubygem-multi_json-1.8.2-1.el6.noarch (foreman) Requires: ruby193-ruby Error: Package: ruby193-rubygem-gettext_i18n_rails-0.10.0-3.el6.noarch (foreman) Requires: ruby193-rubygems Error: Package: ruby193-rubygem-i18n_data-0.2.7-2.el6.noarch (foreman) Requires: ruby193-rubygems Error: Package: ruby193-rubygem-rest-client-1.6.1-4.el6.noarch (foreman) Requires: ruby193-rubygems Error: Package: ruby193-rubygem-oauth-0.4.7-5.el6.noarch (foreman) Requires: /opt/rh/ruby193/root/usr/bin/ruby Error: Package: ruby193-rubygem-gettext_i18n_rails_js-0.0.8-2.el6.noarch (foreman) Requires: ruby193-rubygem(rails) >= 3.2.0 Error: Package: ruby193-rubygem-foreman_simplify-0.0.5-1.el6.noarch (foreman-plugins) Requires: ruby193-ruby(abi) >= 1.9.1 Error: Package: openstack-foreman-installer-2.0.0.0-1.el6.noarch (openstack-icehouse) Requires: augeas Error: Package: ruby193-rubygem-uuidtools-2.1.3-3.el6.noarch (foreman) Requires: ruby193-ruby(abi) = 1.9.1 Error: Package: ruby193-rubygem-thin-1.3.1-7.el6.x86_64 (foreman) Requires: /opt/rh/ruby193/root/usr/bin/ruby Error: Package: rubygem-rest-client-1.6.1-2.el6.noarch (epel) Requires: rubygems Error: Package: ruby193-rubygem-jquery-ui-rails-4.0.2-7.el6.noarch (foreman) Requires: ruby193-ruby(rubygems) >= 1.3.6 Error: Package: ruby193-rubygem-foreigner-1.4.2-1.el6.noarch (foreman) Requires: ruby193-ruby(abi) = 1.9.1 Error: Package: rubygem-json-1.5.5-1.el6.x86_64 (puppetlabs-deps) Requires: libruby.so.1.8()(64bit) Error: Package: foreman-1.5.0-1.el6.noarch (foreman) Requires: ruby193-rubygem(jquery-rails) Error: Package: ruby193-rubygem-audited-activerecord-3.0.0-2.el6.noarch (foreman) Requires: ruby193-ruby(rubygems) Error: Package: foreman-1.5.0-1.el6.noarch (foreman) Requires: ruby193-rubygem(rails) >= 3.2.8 Error: Package: galera-25.3.5-2.el6.x86_64 (openstack-icehouse) Requires: libboost_program_options.so.5()(64bit) Error: Package: ruby193-rubygem-jquery-ui-rails-4.0.2-7.el6.noarch (foreman) Requires: ruby193-ruby Error: Package: ruby193-rubygem-foreigner-1.4.2-1.el6.noarch (foreman) Requires: ruby193-rubygem(activerecord) >= 3.0.0 Error: Package: rubygem-rdoc-3.12-12.el6.x86_64 (foreman) Requires: ruby(rubygems) Error: Package: rubygem-multi_json-1.8.2-1.el6.noarch (foreman) Requires: ruby(abi) = 1.8 Error: Package: ruby193-rubygem-i18n_data-0.2.7-2.el6.noarch (foreman) Requires: ruby193-ruby(abi) = 1.9.1 Error: Package: ruby193-rubygem-ruby2ruby-2.0.1-7.el6.noarch (foreman) Requires: ruby193-ruby(rubygems) Error: Package: rubygem-hashie-2.0.5-0.el6.noarch (foreman) Requires: rubygems Error: Package: ruby193-rubygem-ruby_parser-3.1.1-5.el6.noarch (foreman) Requires: ruby193-ruby(rubygems) Error: Package: puppet-3.6.2-1.el6.noarch (puppetlabs-products) Requires: ruby >= 1.8 Error: Package: rubygem-rest-client-1.6.1-2.el6.noarch (epel) Requires: /usr/bin/ruby Error: Package: ruby193-rubygem-bundler_ext-0.3.0-3.el6.noarch (foreman) Requires: ruby193-ruby(rubygems) Error: Package: ruby193-rubygem-scoped_search-2.7.1-1.el6.noarch (foreman) Requires: ruby193-rubygem-activerecord >= 2.1.0 Error: Package: ruby193-rubygem-net-ldap-0.3.1-1.el6.noarch (foreman) Requires: ruby193-ruby(abi) = 1.9.1 Error: Package: ruby193-rubygem-mysql2-0.3.11-4.el6.x86_64 (foreman) Requires: ruby193-rubygems >= 1.8.10 Error: Package: ruby193-rubygem-deface-0.7.2-6.el6.noarch (foreman-plugins) Requires: ruby193-ruby(abi) = 1.9.1 Error: Package: mariadb-galera-server-5.5.36-9.el6.x86_64 (openstack-icehouse) Requires: perl-DBD-MySQL Error: Package: rubygem-kafo-0.5.4-1.el6.noarch (foreman) Requires: ruby(abi) >= 1.8 Error: Package: 1:ruby-shadow-2.2.0-2.el6.x86_64 (puppetlabs-deps) Requires: ruby Error: Package: ruby193-rubygem-fast_gettext-0.8.0-14.el6.noarch (foreman) Requires: ruby193-rubygems Error: Package: ruby193-ruby-wrapper-0.0.2-5.el6.noarch (foreman) Requires: ruby193-rubygems Error: Package: ruby193-rubygem-ancestry-2.0.0-2.el6.noarch (foreman) Requires: ruby193-rubygems Error: Package: ruby193-rubygem-audited-3.0.0-2.el6.noarch (foreman) Requires: ruby193-ruby(rubygems) Error: Package: ruby193-rubygem-ruby2ruby-2.0.1-7.el6.noarch (foreman) Requires: /usr/bin/ruby Error: Package: rubygem-powerbar-1.0.11-7.el6.noarch (foreman) Requires: ruby(abi) = 1.8 Error: Package: foreman-1.5.0-1.el6.noarch (foreman) Requires: ruby193-rubygem(rake) >= 0.8.3 Error: Package: ruby193-rubygem-safemode-1.2.0-5.el6.noarch (foreman) Requires: ruby193-rubygems Error: Package: ruby193-rubygem-thin-1.3.1-7.el6.x86_64 (foreman) Requires: ruby193-rubygem(rack) >= 1.0.0 Error: Package: rubygem-json-1.5.5-1.el6.x86_64 (puppetlabs-deps) Requires: rubygems Error: Package: ruby193-rubygem-ruby_parser-3.1.1-5.el6.noarch (foreman) Requires: /opt/rh/ruby193/root/usr/bin/ruby Error: Package: ruby193-rubygem-rabl-0.9.0-1.el6.noarch (foreman) Requires: ruby193-ruby(abi) = 1.9.1 Error: Package: ruby193-rubygem-nokogiri-1.5.11-1.el6.x86_64 (foreman) Requires: libruby.so.1.9()(64bit) Error: Package: ruby193-rubygem-rest-client-1.6.1-4.el6.noarch (foreman) Requires: ruby193-ruby(abi) = 1.9.1 Error: Package: galera-25.3.5-2.el6.x86_64 (openstack-icehouse) Requires: nc Error: Package: foreman-1.5.0-1.el6.noarch (foreman) Requires: ruby193-rubygem(rails) < 3.3.0 Error: Package: ruby193-rubygem-ancestry-2.0.0-2.el6.noarch (foreman) Requires: ruby193-rubygem-activerecord >= 2.2.2 Error: Package: rubygem-highline-1.6.21-1.el6.noarch (foreman) Requires: ruby(abi) = 1.8 Error: Package: ruby193-rubygem-uuidtools-2.1.3-3.el6.noarch (foreman) Requires: ruby193-ruby(rubygems) Error: Package: rubygem-mime-types-1.16-3.el6.noarch (epel) Requires: ruby(rubygems) Error: Package: ruby193-ruby-wrapper-0.0.2-5.el6.noarch (foreman) Requires: ruby193-ruby Error: Package: ruby193-rubygem-rest-client-1.6.1-4.el6.noarch (foreman) Requires: ruby193-rubygem(mime-types) >= 1.16 Error: Package: ruby193-rubygem-gettext_i18n_rails_js-0.0.8-2.el6.noarch (foreman) Requires: ruby193-ruby(abi) = 1.9.1 Error: Package: hiera-1.3.4-1.el6.noarch (puppetlabs-products) Requires: ruby >= 1.8.5 Error: Package: rubygem-clamp-0.6.2-1.el6.noarch (foreman) Requires: ruby(abi) Error: Package: rubygem-multi_json-1.8.2-1.el6.noarch (foreman) Requires: ruby Error: Package: ruby193-rubygem-oauth-0.4.7-5.el6.noarch (foreman) Requires: ruby193-ruby(abi) Error: Package: ruby193-rubygem-deface-0.7.2-6.el6.noarch (foreman-plugins) Requires: ruby193-rubygems Error: Package: rubygem-logging-1.8.1-25.el6.noarch (foreman) Requires: ruby(rubygems) Error: Package: ruby-augeas-0.4.1-3.el6.x86_64 (puppetlabs-deps) Requires: libaugeas.so.0(AUGEAS_0.8.0)(64bit) Error: Package: ruby193-rubygem-fast_gettext-0.8.0-14.el6.noarch (foreman) Requires: ruby193-ruby(abi) = 1.9.1 Error: Package: ruby193-rubygem-will_paginate-3.0.2-7.el6.noarch (foreman) Requires: ruby193-ruby(rubygems) Error: Package: ruby-augeas-0.4.1-3.el6.x86_64 (puppetlabs-deps) Requires: ruby(abi) = 1.8 Error: Package: ruby193-rubygem-foreigner-1.4.2-1.el6.noarch (foreman) Requires: ruby193-rubygems Error: Package: ruby193-rubygem-audited-3.0.0-2.el6.noarch (foreman) Requires: ruby193-ruby(abi) = 1.9.1 Error: Package: ruby193-rubygem-bundler_ext-0.3.0-3.el6.noarch (foreman) Requires: ruby193-ruby(abi) = 1.9.1 Error: Package: ruby193-rubygem-jquery-ui-rails-4.0.2-7.el6.noarch (foreman) Requires: ruby193-ruby(abi) = 1.9.1 Error: Package: ruby193-rubygem-thin-1.3.1-7.el6.x86_64 (foreman) Requires: ruby193-ruby(abi) = 1.9.1 Error: Package: ruby193-rubygem-mysql2-0.3.11-4.el6.x86_64 (foreman) Requires: libruby.so.1.9()(64bit) Error: Package: ruby193-rubygem-eventmachine-0.12.10-9.el6.x86_64 (foreman) Requires: ruby193-ruby(abi) = 1.9.1 Error: Package: ruby-augeas-0.4.1-3.el6.x86_64 (puppetlabs-deps) Requires: libaugeas.so.0(AUGEAS_0.10.0)(64bit) Error: Package: ruby193-rubygem-rabl-0.9.0-1.el6.noarch (foreman) Requires: ruby193-rubygem(activesupport) >= 2.3.14 Error: Package: rubygem-logging-1.8.1-25.el6.noarch (foreman) Requires: ruby(abi) = 1.8 Error: Package: ruby193-rubygem-gettext_i18n_rails_js-0.0.8-2.el6.noarch (foreman) Requires: ruby193-ruby Error: Package: openstack-foreman-installer-2.0.0.0-1.el6.noarch (openstack-icehouse) Requires: /usr/bin/ruby Error: Package: ruby193-rubygem-scoped_search-2.7.1-1.el6.noarch (foreman) Requires: ruby193-ruby(abi) = 1.9.1 Error: Package: ruby193-rubygem-oauth-0.4.7-5.el6.noarch (foreman) Requires: ruby193-rubygems Error: Package: ruby193-rubygem-eventmachine-0.12.10-9.el6.x86_64 (foreman) Requires: libruby.so.1.9()(64bit) Error: Package: ruby193-rubygem-ruby2ruby-2.0.1-7.el6.noarch (foreman) Requires: ruby193-ruby(abi) = 1.9.1 Error: Package: rubygem-rdoc-3.12-12.el6.x86_64 (foreman) Requires: /usr/bin/ruby Error: Package: ruby193-rubygem-thin-1.3.1-7.el6.x86_64 (foreman) Requires: libruby.so.1.9()(64bit) Error: Package: ruby193-rubygem-sass-3.2.13-1.el6.noarch (foreman) Requires: ruby193-ruby(abi) = 1.9.1 Error: Package: ruby-augeas-0.4.1-3.el6.x86_64 (puppetlabs-deps) Requires: libruby.so.1.8()(64bit) Error: Package: ruby193-rubygem-deep_cloneable-1.6.0-2.el6.noarch (foreman) Requires: ruby193-ruby Error: Package: ruby193-rubygem-po_to_json-0.0.7-2.el6.noarch (foreman) Requires: ruby193-ruby(abi) = 1.9.1 Error: Package: ruby193-rubygem-foreman_simplify-0.0.5-1.el6.noarch (foreman-plugins) Requires: ruby193-rubygems Error: Package: ruby193-rubygem-will_paginate-3.0.2-7.el6.noarch (foreman) Requires: ruby193-rubygem(activerecord) Error: Package: 1:ruby-shadow-2.2.0-2.el6.x86_64 (puppetlabs-deps) Requires: libruby.so.1.8()(64bit) Error: Package: ruby193-rubygem-po_to_json-0.0.7-2.el6.noarch (foreman) Requires: ruby193-ruby Error: Package: foreman-1.5.0-1.el6.noarch (foreman) Requires: ruby193-rubygem(therubyracer) Error: Package: ruby193-rubygem-i18n_data-0.2.7-2.el6.noarch (foreman) Requires: ruby193-rubygem(activesupport) >= 0 Error: Package: rubygem-powerbar-1.0.11-7.el6.noarch (foreman) Requires: rubygems Error: Package: rubygem-json-1.5.5-1.el6.x86_64 (puppetlabs-deps) Requires: ruby(abi) = 1.8 Error: Package: ruby193-rubygem-gettext_i18n_rails-0.10.0-3.el6.noarch (foreman) Requires: ruby193-ruby(abi) = 1.9.1 Error: Package: puppet-3.6.2-1.el6.noarch (puppetlabs-products) Requires: /usr/bin/ruby Error: Package: ruby193-rubygem-audited-activerecord-3.0.0-2.el6.noarch (foreman) Requires: ruby193-rubygem(activerecord) < 4 Error: Package: ruby193-rubygem-bootstrap-sass-3.0.3.0-1.el6.noarch (foreman) Requires: ruby193-ruby(rubygems) Error: Package: ruby193-rubygem-daemons-1.1.4-7.el6.noarch (foreman) Requires: ruby193-rubygems Error: Package: rubygem-little-plugger-1.1.3-17.el6.noarch (foreman) Requires: ruby(abi) = 1.8 Error: Package: rubygem-highline-1.6.21-1.el6.noarch (foreman) Requires: rubygems Error: Package: ruby193-rubygem-sass-3.2.13-1.el6.noarch (foreman) Requires: ruby193-ruby(rubygems) Error: Package: ruby193-rubygem-audited-activerecord-3.0.0-2.el6.noarch (foreman) Requires: ruby193-rubygem(activerecord) >= 3.0 Error: Package: ruby193-rubygem-nokogiri-1.5.11-1.el6.x86_64 (foreman) Requires: /opt/rh/ruby193/root/usr/bin/ruby Error: Package: ruby193-rubygem-multi_json-1.8.2-1.el6.noarch (foreman) Requires: ruby193-ruby(rubygems) Error: Package: ruby193-rubygem-sexp_processor-4.1.3-4.el6.noarch (foreman) Requires: ruby193-rubygems Error: Package: ruby193-rubygem-nokogiri-1.5.11-1.el6.x86_64 (foreman) Requires: ruby193-ruby(rubygems) Error: Package: ruby193-rubygem-bootstrap-sass-3.0.3.0-1.el6.noarch (foreman) Requires: ruby193-ruby(abi) = 1.9.1 Error: Package: 1:facter-2.0.2-1.el6.x86_64 (puppetlabs-products) Requires: /usr/bin/ruby Error: Package: ruby193-rubygem-deep_cloneable-1.6.0-2.el6.noarch (foreman) Requires: ruby193-rubygem-activerecord >= 3.1.0 Error: Package: ruby193-rubygem-sexp_processor-4.1.3-4.el6.noarch (foreman) Requires: ruby193-ruby(abi) = 1.9.1 Error: Package: hiera-1.3.4-1.el6.noarch (puppetlabs-products) Requires: /usr/bin/ruby Error: Package: ruby193-rubygem-jquery-ui-rails-4.0.2-7.el6.noarch (foreman) Requires: ruby193-rubygem(railties) >= 3.1.0 Error: Package: openstack-foreman-installer-2.0.0.0-1.el6.noarch (openstack-icehouse) Requires: ruby Error: Package: mariadb-galera-server-5.5.36-9.el6.x86_64 (openstack-icehouse) Requires: mysql(x86-64) Error: Package: 1:foreman-installer-1.5.0-1.el6.noarch (foreman) Requires: ruby(abi) Error: Package: rubygem-ansi-1.4.3-0.el6.noarch (foreman) Requires: rubygems Error: Package: ruby193-rubygem-deep_cloneable-1.6.0-2.el6.noarch (foreman) Requires: ruby193-ruby(abi) = 1.9.1 Error: Package: rubygem-foreman_api-0.1.11-1.el6.noarch (foreman) Requires: ruby(rubygems) Error: Package: ruby193-rubygem-po_to_json-0.0.7-2.el6.noarch (foreman) Requires: ruby193-rubygem(json) Error: Package: rubygem-kafo_parsers-0.0.2-1.el6.noarch (foreman) Requires: ruby(abi) >= 1.8 Error: Package: foreman-1.5.0-1.el6.noarch (foreman) Requires: ruby193-ruby(abi) = 1.9.1 Error: Package: ruby193-rubygem-bootstrap-sass-3.0.3.0-1.el6.noarch (foreman) Requires: ruby193-ruby Error: Package: ruby193-rubygem-gettext_i18n_rails_js-0.0.8-2.el6.noarch (foreman) Requires: ruby193-ruby(rubygems) Error: Package: ruby193-rubygem-ruby_parser-3.1.1-5.el6.noarch (foreman) Requires: /usr/bin/ruby Error: Package: rubygem-rdoc-3.12-12.el6.x86_64 (foreman) Requires: ruby-irb Error: Package: rubygem-foreman_api-0.1.11-1.el6.noarch (foreman) Requires: ruby(abi) Error: Package: rubygem-oauth-0.4.7-5.el6.noarch (foreman) Requires: ruby(abi) Error: Package: ruby193-ruby-wrapper-0.0.2-5.el6.noarch (foreman) Requires: ruby193-ruby(abi) = 1.9.1 Error: Package: rubygem-little-plugger-1.1.3-17.el6.noarch (foreman) Requires: ruby(rubygems) Error: Package: ruby193-facter-1.6.18-4.el6.x86_64 (foreman) Requires: /opt/rh/ruby193/root/usr/bin/ruby Error: Package: ruby193-rubygem-deface-0.7.2-6.el6.noarch (foreman-plugins) Requires: ruby193-rubygem(rails) Error: Package: ruby-augeas-0.4.1-3.el6.x86_64 (puppetlabs-deps) Requires: libaugeas.so.0(AUGEAS_0.1.0)(64bit) Error: Package: ruby193-rubygem-deep_cloneable-1.6.0-2.el6.noarch (foreman) Requires: ruby193-ruby(rubygems) Error: Package: ruby193-rubygem-eventmachine-0.12.10-9.el6.x86_64 (foreman) Requires: ruby193-ruby(rubygems) Error: Package: ruby193-rubygem-sass-3.2.13-1.el6.noarch (foreman) Requires: ruby193-ruby Error: Package: rubygem-multi_json-1.8.2-1.el6.noarch (foreman) Requires: ruby(rubygems) Error: Package: rubygem-clamp-0.6.2-1.el6.noarch (foreman) Requires: ruby(rubygems) You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew at andrewklau.com Wed Jun 18 00:26:36 2014 From: andrew at andrewklau.com (Andrew Lau) Date: Tue, 17 Jun 2014 20:26:36 -0400 Subject: [Rdo-list] RHEL 6.5 Openstack foreman In-Reply-To: References: Message-ID: I think you're just missing the SCL repo On Tue, Jun 17, 2014 at 3:28 PM, Ajay Kalambur (akalambu) wrote: > Hi > I tried to install openstack-foreman-installer on RHEL 6.5 using steps below > > > sudo yum-config-manager --enable rhel-6-server-rpms > sudo yum install yum-config-manager --enable rhel-6-server-optional-rpms > sudo yum install > http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm > > sudo yum install -y > http://repos.fedorapeople.org/repos/openstack/openstack-icehouse/rdo-release-icehouse-3.noarch.rpm > > sudo yum install openstack-foreman-installer > > > > But i see a lot of missing dependencies when trying to install > foreman-installer. Any idea how to fix this? > > --> Finished Dependency Resolution > Error: Package: 1:facter-2.0.2-1.el6.x86_64 (puppetlabs-products) > Requires: ruby >= 1.8.7 > Error: Package: rubygem-mime-types-1.16-3.el6.noarch (epel) > Requires: ruby(abi) = 1.8 > Error: Package: ruby193-rubygem-foreigner-1.4.2-1.el6.noarch (foreman) > Requires: ruby193-ruby > Error: Package: ruby193-rubygem-daemons-1.1.4-7.el6.noarch (foreman) > Requires: ruby193-ruby(abi) = 1.9.1 > Error: Package: ruby193-rubygem-mysql2-0.3.11-4.el6.x86_64 (foreman) > Requires: ruby193-ruby >= 1.8.6 > Error: Package: ruby193-rubygem-bundler_ext-0.3.0-3.el6.noarch (foreman) > Requires: ruby193-rubygem(bundler) > Error: Package: ruby193-rubygem-net-ldap-0.3.1-1.el6.noarch (foreman) > Requires: ruby193-ruby(rubygems) > Error: Package: rubygem-kafo_parsers-0.0.2-1.el6.noarch (foreman) > Requires: rubygems > Error: Package: rubygem-powerbar-1.0.11-7.el6.noarch (foreman) > Requires: /usr/bin/ruby > Error: Package: ruby193-rubygem-audited-activerecord-3.0.0-2.el6.noarch > (foreman) > Requires: ruby193-ruby(abi) = 1.9.1 > Error: Package: ruby193-rubygem-scoped_search-2.7.1-1.el6.noarch (foreman) > Requires: ruby193-rubygems > Error: Package: ruby193-rubygem-ruby2ruby-2.0.1-7.el6.noarch (foreman) > Requires: /opt/rh/ruby193/root/usr/bin/ruby > Error: Package: ruby193-rubygem-thin-1.3.1-7.el6.x86_64 (foreman) > Requires: ruby193-ruby(rubygems) > Error: Package: ruby193-rubygem-safemode-1.2.0-5.el6.noarch (foreman) > Requires: ruby193-ruby(abi) = 1.9.1 > Error: Package: ruby193-rubygem-apipie-rails-0.1.2-1.el6.noarch (foreman) > Requires: ruby193-ruby(abi) = 1.9.1 > Error: Package: ruby193-rubygem-ruby_parser-3.1.1-5.el6.noarch (foreman) > Requires: ruby193-ruby(abi) = 1.9.1 > Error: Package: ruby193-rubygem-rabl-0.9.0-1.el6.noarch (foreman) > Requires: ruby193-rubygems > Error: Package: ruby-rgen-0.6.5-2.el6.noarch (puppetlabs-deps) > Requires: ruby >= 1.8 > Error: Package: ruby-augeas-0.4.1-3.el6.x86_64 (puppetlabs-deps) > Requires: libaugeas.so.0(AUGEAS_0.11.0)(64bit) > Error: Package: rubygem-oauth-0.4.7-5.el6.noarch (foreman) > Requires: /usr/bin/ruby > Error: Package: ruby-augeas-0.4.1-3.el6.x86_64 (puppetlabs-deps) > Requires: libaugeas.so.0()(64bit) > Error: Package: rubygem-kafo-0.5.4-1.el6.noarch (foreman) > Requires: rubygems > Error: Package: ruby-augeas-0.4.1-3.el6.x86_64 (puppetlabs-deps) > Requires: libaugeas.so.0(AUGEAS_0.12.0)(64bit) > Error: Package: ruby-augeas-0.4.1-3.el6.x86_64 (puppetlabs-deps) > Requires: augeas-libs >= 0.8.0 > Error: Package: foreman-1.5.0-1.el6.noarch (foreman) > Requires: ruby193-rubygems > Error: Package: ruby193-rubygem-ancestry-2.0.0-2.el6.noarch (foreman) > Requires: ruby193-ruby(abi) = 1.9.1 > Error: Package: foreman-1.5.0-1.el6.noarch (foreman) > Requires: ruby193-rubygem(json) > Error: Package: ruby193-rubygem-po_to_json-0.0.7-2.el6.noarch (foreman) > Requires: ruby193-ruby(rubygems) > Error: Package: ruby193-rubygem-sass-3.2.13-1.el6.noarch (foreman) > Requires: /opt/rh/ruby193/root/usr/bin/ruby > Error: Package: puppet-3.6.2-1.el6.noarch (puppetlabs-products) > Requires: ruby >= 1.8.7 > Error: Package: rubygem-kafo-0.5.4-1.el6.noarch (foreman) > Requires: /usr/bin/ruby > Error: Package: ruby193-rubygem-nokogiri-1.5.11-1.el6.x86_64 (foreman) > Requires: ruby193-ruby(abi) = 1.9.1 > Error: Package: rubygem-json-1.5.5-1.el6.x86_64 (puppetlabs-deps) > Requires: /usr/bin/ruby > Error: Package: puppet-3.6.2-1.el6.noarch (puppetlabs-products) > Requires: ruby(selinux) > Error: Package: rubygem-rest-client-1.6.1-2.el6.noarch (epel) > Requires: ruby(abi) = 1.8 > Error: Package: ruby193-rubygem-multi_json-1.8.2-1.el6.noarch (foreman) > Requires: ruby193-ruby(abi) = 1.9.1 > Error: Package: rubygem-rdoc-3.12-12.el6.x86_64 (foreman) > Requires: ruby(abi) = 1.8 > Error: Package: rubygem-hashie-2.0.5-0.el6.noarch (foreman) > Requires: ruby(abi) = 1.8 > Error: Package: ruby193-rubygem-jquery-ui-rails-4.0.2-7.el6.noarch (foreman) > Requires: ruby193-rubygem(jquery-rails) > Error: Package: ruby193-rubygem-will_paginate-3.0.2-7.el6.noarch (foreman) > Requires: ruby193-ruby(abi) = 1.9.1 > Error: Package: rubygem-oauth-0.4.7-5.el6.noarch (foreman) > Requires: rubygems > Error: Package: rubygem-ansi-1.4.3-0.el6.noarch (foreman) > Requires: ruby(abi) = 1.8 > Error: Package: ruby193-rubygem-apipie-rails-0.1.2-1.el6.noarch (foreman) > Requires: ruby193-rubygems > Error: Package: ruby193-rubygem-gettext_i18n_rails_js-0.0.8-2.el6.noarch > (foreman) > Requires: ruby193-rubygem(rails) < 3.3.0 > Error: Package: ruby193-rubygem-rest-client-1.6.1-4.el6.noarch (foreman) > Requires: /opt/rh/ruby193/root/usr/bin/ruby > Error: Package: ruby193-rubygem-multi_json-1.8.2-1.el6.noarch (foreman) > Requires: ruby193-ruby > Error: Package: ruby193-rubygem-gettext_i18n_rails-0.10.0-3.el6.noarch > (foreman) > Requires: ruby193-rubygems > Error: Package: ruby193-rubygem-i18n_data-0.2.7-2.el6.noarch (foreman) > Requires: ruby193-rubygems > Error: Package: ruby193-rubygem-rest-client-1.6.1-4.el6.noarch (foreman) > Requires: ruby193-rubygems > Error: Package: ruby193-rubygem-oauth-0.4.7-5.el6.noarch (foreman) > Requires: /opt/rh/ruby193/root/usr/bin/ruby > Error: Package: ruby193-rubygem-gettext_i18n_rails_js-0.0.8-2.el6.noarch > (foreman) > Requires: ruby193-rubygem(rails) >= 3.2.0 > Error: Package: ruby193-rubygem-foreman_simplify-0.0.5-1.el6.noarch > (foreman-plugins) > Requires: ruby193-ruby(abi) >= 1.9.1 > Error: Package: openstack-foreman-installer-2.0.0.0-1.el6.noarch > (openstack-icehouse) > Requires: augeas > Error: Package: ruby193-rubygem-uuidtools-2.1.3-3.el6.noarch (foreman) > Requires: ruby193-ruby(abi) = 1.9.1 > Error: Package: ruby193-rubygem-thin-1.3.1-7.el6.x86_64 (foreman) > Requires: /opt/rh/ruby193/root/usr/bin/ruby > Error: Package: rubygem-rest-client-1.6.1-2.el6.noarch (epel) > Requires: rubygems > Error: Package: ruby193-rubygem-jquery-ui-rails-4.0.2-7.el6.noarch (foreman) > Requires: ruby193-ruby(rubygems) >= 1.3.6 > Error: Package: ruby193-rubygem-foreigner-1.4.2-1.el6.noarch (foreman) > Requires: ruby193-ruby(abi) = 1.9.1 > Error: Package: rubygem-json-1.5.5-1.el6.x86_64 (puppetlabs-deps) > Requires: libruby.so.1.8()(64bit) > Error: Package: foreman-1.5.0-1.el6.noarch (foreman) > Requires: ruby193-rubygem(jquery-rails) > Error: Package: ruby193-rubygem-audited-activerecord-3.0.0-2.el6.noarch > (foreman) > Requires: ruby193-ruby(rubygems) > Error: Package: foreman-1.5.0-1.el6.noarch (foreman) > Requires: ruby193-rubygem(rails) >= 3.2.8 > Error: Package: galera-25.3.5-2.el6.x86_64 (openstack-icehouse) > Requires: libboost_program_options.so.5()(64bit) > Error: Package: ruby193-rubygem-jquery-ui-rails-4.0.2-7.el6.noarch (foreman) > Requires: ruby193-ruby > Error: Package: ruby193-rubygem-foreigner-1.4.2-1.el6.noarch (foreman) > Requires: ruby193-rubygem(activerecord) >= 3.0.0 > Error: Package: rubygem-rdoc-3.12-12.el6.x86_64 (foreman) > Requires: ruby(rubygems) > Error: Package: rubygem-multi_json-1.8.2-1.el6.noarch (foreman) > Requires: ruby(abi) = 1.8 > Error: Package: ruby193-rubygem-i18n_data-0.2.7-2.el6.noarch (foreman) > Requires: ruby193-ruby(abi) = 1.9.1 > Error: Package: ruby193-rubygem-ruby2ruby-2.0.1-7.el6.noarch (foreman) > Requires: ruby193-ruby(rubygems) > Error: Package: rubygem-hashie-2.0.5-0.el6.noarch (foreman) > Requires: rubygems > Error: Package: ruby193-rubygem-ruby_parser-3.1.1-5.el6.noarch (foreman) > Requires: ruby193-ruby(rubygems) > Error: Package: puppet-3.6.2-1.el6.noarch (puppetlabs-products) > Requires: ruby >= 1.8 > Error: Package: rubygem-rest-client-1.6.1-2.el6.noarch (epel) > Requires: /usr/bin/ruby > Error: Package: ruby193-rubygem-bundler_ext-0.3.0-3.el6.noarch (foreman) > Requires: ruby193-ruby(rubygems) > Error: Package: ruby193-rubygem-scoped_search-2.7.1-1.el6.noarch (foreman) > Requires: ruby193-rubygem-activerecord >= 2.1.0 > Error: Package: ruby193-rubygem-net-ldap-0.3.1-1.el6.noarch (foreman) > Requires: ruby193-ruby(abi) = 1.9.1 > Error: Package: ruby193-rubygem-mysql2-0.3.11-4.el6.x86_64 (foreman) > Requires: ruby193-rubygems >= 1.8.10 > Error: Package: ruby193-rubygem-deface-0.7.2-6.el6.noarch (foreman-plugins) > Requires: ruby193-ruby(abi) = 1.9.1 > Error: Package: mariadb-galera-server-5.5.36-9.el6.x86_64 > (openstack-icehouse) > Requires: perl-DBD-MySQL > Error: Package: rubygem-kafo-0.5.4-1.el6.noarch (foreman) > Requires: ruby(abi) >= 1.8 > Error: Package: 1:ruby-shadow-2.2.0-2.el6.x86_64 (puppetlabs-deps) > Requires: ruby > Error: Package: ruby193-rubygem-fast_gettext-0.8.0-14.el6.noarch (foreman) > Requires: ruby193-rubygems > Error: Package: ruby193-ruby-wrapper-0.0.2-5.el6.noarch (foreman) > Requires: ruby193-rubygems > Error: Package: ruby193-rubygem-ancestry-2.0.0-2.el6.noarch (foreman) > Requires: ruby193-rubygems > Error: Package: ruby193-rubygem-audited-3.0.0-2.el6.noarch (foreman) > Requires: ruby193-ruby(rubygems) > Error: Package: ruby193-rubygem-ruby2ruby-2.0.1-7.el6.noarch (foreman) > Requires: /usr/bin/ruby > Error: Package: rubygem-powerbar-1.0.11-7.el6.noarch (foreman) > Requires: ruby(abi) = 1.8 > Error: Package: foreman-1.5.0-1.el6.noarch (foreman) > Requires: ruby193-rubygem(rake) >= 0.8.3 > Error: Package: ruby193-rubygem-safemode-1.2.0-5.el6.noarch (foreman) > Requires: ruby193-rubygems > Error: Package: ruby193-rubygem-thin-1.3.1-7.el6.x86_64 (foreman) > Requires: ruby193-rubygem(rack) >= 1.0.0 > Error: Package: rubygem-json-1.5.5-1.el6.x86_64 (puppetlabs-deps) > Requires: rubygems > Error: Package: ruby193-rubygem-ruby_parser-3.1.1-5.el6.noarch (foreman) > Requires: /opt/rh/ruby193/root/usr/bin/ruby > Error: Package: ruby193-rubygem-rabl-0.9.0-1.el6.noarch (foreman) > Requires: ruby193-ruby(abi) = 1.9.1 > Error: Package: ruby193-rubygem-nokogiri-1.5.11-1.el6.x86_64 (foreman) > Requires: libruby.so.1.9()(64bit) > Error: Package: ruby193-rubygem-rest-client-1.6.1-4.el6.noarch (foreman) > Requires: ruby193-ruby(abi) = 1.9.1 > Error: Package: galera-25.3.5-2.el6.x86_64 (openstack-icehouse) > Requires: nc > Error: Package: foreman-1.5.0-1.el6.noarch (foreman) > Requires: ruby193-rubygem(rails) < 3.3.0 > Error: Package: ruby193-rubygem-ancestry-2.0.0-2.el6.noarch (foreman) > Requires: ruby193-rubygem-activerecord >= 2.2.2 > Error: Package: rubygem-highline-1.6.21-1.el6.noarch (foreman) > Requires: ruby(abi) = 1.8 > Error: Package: ruby193-rubygem-uuidtools-2.1.3-3.el6.noarch (foreman) > Requires: ruby193-ruby(rubygems) > Error: Package: rubygem-mime-types-1.16-3.el6.noarch (epel) > Requires: ruby(rubygems) > Error: Package: ruby193-ruby-wrapper-0.0.2-5.el6.noarch (foreman) > Requires: ruby193-ruby > Error: Package: ruby193-rubygem-rest-client-1.6.1-4.el6.noarch (foreman) > Requires: ruby193-rubygem(mime-types) >= 1.16 > Error: Package: ruby193-rubygem-gettext_i18n_rails_js-0.0.8-2.el6.noarch > (foreman) > Requires: ruby193-ruby(abi) = 1.9.1 > Error: Package: hiera-1.3.4-1.el6.noarch (puppetlabs-products) > Requires: ruby >= 1.8.5 > Error: Package: rubygem-clamp-0.6.2-1.el6.noarch (foreman) > Requires: ruby(abi) > Error: Package: rubygem-multi_json-1.8.2-1.el6.noarch (foreman) > Requires: ruby > Error: Package: ruby193-rubygem-oauth-0.4.7-5.el6.noarch (foreman) > Requires: ruby193-ruby(abi) > Error: Package: ruby193-rubygem-deface-0.7.2-6.el6.noarch (foreman-plugins) > Requires: ruby193-rubygems > Error: Package: rubygem-logging-1.8.1-25.el6.noarch (foreman) > Requires: ruby(rubygems) > Error: Package: ruby-augeas-0.4.1-3.el6.x86_64 (puppetlabs-deps) > Requires: libaugeas.so.0(AUGEAS_0.8.0)(64bit) > Error: Package: ruby193-rubygem-fast_gettext-0.8.0-14.el6.noarch (foreman) > Requires: ruby193-ruby(abi) = 1.9.1 > Error: Package: ruby193-rubygem-will_paginate-3.0.2-7.el6.noarch (foreman) > Requires: ruby193-ruby(rubygems) > Error: Package: ruby-augeas-0.4.1-3.el6.x86_64 (puppetlabs-deps) > Requires: ruby(abi) = 1.8 > Error: Package: ruby193-rubygem-foreigner-1.4.2-1.el6.noarch (foreman) > Requires: ruby193-rubygems > Error: Package: ruby193-rubygem-audited-3.0.0-2.el6.noarch (foreman) > Requires: ruby193-ruby(abi) = 1.9.1 > Error: Package: ruby193-rubygem-bundler_ext-0.3.0-3.el6.noarch (foreman) > Requires: ruby193-ruby(abi) = 1.9.1 > Error: Package: ruby193-rubygem-jquery-ui-rails-4.0.2-7.el6.noarch (foreman) > Requires: ruby193-ruby(abi) = 1.9.1 > Error: Package: ruby193-rubygem-thin-1.3.1-7.el6.x86_64 (foreman) > Requires: ruby193-ruby(abi) = 1.9.1 > Error: Package: ruby193-rubygem-mysql2-0.3.11-4.el6.x86_64 (foreman) > Requires: libruby.so.1.9()(64bit) > Error: Package: ruby193-rubygem-eventmachine-0.12.10-9.el6.x86_64 (foreman) > Requires: ruby193-ruby(abi) = 1.9.1 > Error: Package: ruby-augeas-0.4.1-3.el6.x86_64 (puppetlabs-deps) > Requires: libaugeas.so.0(AUGEAS_0.10.0)(64bit) > Error: Package: ruby193-rubygem-rabl-0.9.0-1.el6.noarch (foreman) > Requires: ruby193-rubygem(activesupport) >= 2.3.14 > Error: Package: rubygem-logging-1.8.1-25.el6.noarch (foreman) > Requires: ruby(abi) = 1.8 > Error: Package: ruby193-rubygem-gettext_i18n_rails_js-0.0.8-2.el6.noarch > (foreman) > Requires: ruby193-ruby > Error: Package: openstack-foreman-installer-2.0.0.0-1.el6.noarch > (openstack-icehouse) > Requires: /usr/bin/ruby > Error: Package: ruby193-rubygem-scoped_search-2.7.1-1.el6.noarch (foreman) > Requires: ruby193-ruby(abi) = 1.9.1 > Error: Package: ruby193-rubygem-oauth-0.4.7-5.el6.noarch (foreman) > Requires: ruby193-rubygems > Error: Package: ruby193-rubygem-eventmachine-0.12.10-9.el6.x86_64 (foreman) > Requires: libruby.so.1.9()(64bit) > Error: Package: ruby193-rubygem-ruby2ruby-2.0.1-7.el6.noarch (foreman) > Requires: ruby193-ruby(abi) = 1.9.1 > Error: Package: rubygem-rdoc-3.12-12.el6.x86_64 (foreman) > Requires: /usr/bin/ruby > Error: Package: ruby193-rubygem-thin-1.3.1-7.el6.x86_64 (foreman) > Requires: libruby.so.1.9()(64bit) > Error: Package: ruby193-rubygem-sass-3.2.13-1.el6.noarch (foreman) > Requires: ruby193-ruby(abi) = 1.9.1 > Error: Package: ruby-augeas-0.4.1-3.el6.x86_64 (puppetlabs-deps) > Requires: libruby.so.1.8()(64bit) > Error: Package: ruby193-rubygem-deep_cloneable-1.6.0-2.el6.noarch (foreman) > Requires: ruby193-ruby > Error: Package: ruby193-rubygem-po_to_json-0.0.7-2.el6.noarch (foreman) > Requires: ruby193-ruby(abi) = 1.9.1 > Error: Package: ruby193-rubygem-foreman_simplify-0.0.5-1.el6.noarch > (foreman-plugins) > Requires: ruby193-rubygems > Error: Package: ruby193-rubygem-will_paginate-3.0.2-7.el6.noarch (foreman) > Requires: ruby193-rubygem(activerecord) > Error: Package: 1:ruby-shadow-2.2.0-2.el6.x86_64 (puppetlabs-deps) > Requires: libruby.so.1.8()(64bit) > Error: Package: ruby193-rubygem-po_to_json-0.0.7-2.el6.noarch (foreman) > Requires: ruby193-ruby > Error: Package: foreman-1.5.0-1.el6.noarch (foreman) > Requires: ruby193-rubygem(therubyracer) > Error: Package: ruby193-rubygem-i18n_data-0.2.7-2.el6.noarch (foreman) > Requires: ruby193-rubygem(activesupport) >= 0 > Error: Package: rubygem-powerbar-1.0.11-7.el6.noarch (foreman) > Requires: rubygems > Error: Package: rubygem-json-1.5.5-1.el6.x86_64 (puppetlabs-deps) > Requires: ruby(abi) = 1.8 > Error: Package: ruby193-rubygem-gettext_i18n_rails-0.10.0-3.el6.noarch > (foreman) > Requires: ruby193-ruby(abi) = 1.9.1 > Error: Package: puppet-3.6.2-1.el6.noarch (puppetlabs-products) > Requires: /usr/bin/ruby > Error: Package: ruby193-rubygem-audited-activerecord-3.0.0-2.el6.noarch > (foreman) > Requires: ruby193-rubygem(activerecord) < 4 > Error: Package: ruby193-rubygem-bootstrap-sass-3.0.3.0-1.el6.noarch > (foreman) > Requires: ruby193-ruby(rubygems) > Error: Package: ruby193-rubygem-daemons-1.1.4-7.el6.noarch (foreman) > Requires: ruby193-rubygems > Error: Package: rubygem-little-plugger-1.1.3-17.el6.noarch (foreman) > Requires: ruby(abi) = 1.8 > Error: Package: rubygem-highline-1.6.21-1.el6.noarch (foreman) > Requires: rubygems > Error: Package: ruby193-rubygem-sass-3.2.13-1.el6.noarch (foreman) > Requires: ruby193-ruby(rubygems) > Error: Package: ruby193-rubygem-audited-activerecord-3.0.0-2.el6.noarch > (foreman) > Requires: ruby193-rubygem(activerecord) >= 3.0 > Error: Package: ruby193-rubygem-nokogiri-1.5.11-1.el6.x86_64 (foreman) > Requires: /opt/rh/ruby193/root/usr/bin/ruby > Error: Package: ruby193-rubygem-multi_json-1.8.2-1.el6.noarch (foreman) > Requires: ruby193-ruby(rubygems) > Error: Package: ruby193-rubygem-sexp_processor-4.1.3-4.el6.noarch (foreman) > Requires: ruby193-rubygems > Error: Package: ruby193-rubygem-nokogiri-1.5.11-1.el6.x86_64 (foreman) > Requires: ruby193-ruby(rubygems) > Error: Package: ruby193-rubygem-bootstrap-sass-3.0.3.0-1.el6.noarch > (foreman) > Requires: ruby193-ruby(abi) = 1.9.1 > Error: Package: 1:facter-2.0.2-1.el6.x86_64 (puppetlabs-products) > Requires: /usr/bin/ruby > Error: Package: ruby193-rubygem-deep_cloneable-1.6.0-2.el6.noarch (foreman) > Requires: ruby193-rubygem-activerecord >= 3.1.0 > Error: Package: ruby193-rubygem-sexp_processor-4.1.3-4.el6.noarch (foreman) > Requires: ruby193-ruby(abi) = 1.9.1 > Error: Package: hiera-1.3.4-1.el6.noarch (puppetlabs-products) > Requires: /usr/bin/ruby > Error: Package: ruby193-rubygem-jquery-ui-rails-4.0.2-7.el6.noarch (foreman) > Requires: ruby193-rubygem(railties) >= 3.1.0 > Error: Package: openstack-foreman-installer-2.0.0.0-1.el6.noarch > (openstack-icehouse) > Requires: ruby > Error: Package: mariadb-galera-server-5.5.36-9.el6.x86_64 > (openstack-icehouse) > Requires: mysql(x86-64) > Error: Package: 1:foreman-installer-1.5.0-1.el6.noarch (foreman) > Requires: ruby(abi) > Error: Package: rubygem-ansi-1.4.3-0.el6.noarch (foreman) > Requires: rubygems > Error: Package: ruby193-rubygem-deep_cloneable-1.6.0-2.el6.noarch (foreman) > Requires: ruby193-ruby(abi) = 1.9.1 > Error: Package: rubygem-foreman_api-0.1.11-1.el6.noarch (foreman) > Requires: ruby(rubygems) > Error: Package: ruby193-rubygem-po_to_json-0.0.7-2.el6.noarch (foreman) > Requires: ruby193-rubygem(json) > Error: Package: rubygem-kafo_parsers-0.0.2-1.el6.noarch (foreman) > Requires: ruby(abi) >= 1.8 > Error: Package: foreman-1.5.0-1.el6.noarch (foreman) > Requires: ruby193-ruby(abi) = 1.9.1 > Error: Package: ruby193-rubygem-bootstrap-sass-3.0.3.0-1.el6.noarch > (foreman) > Requires: ruby193-ruby > Error: Package: ruby193-rubygem-gettext_i18n_rails_js-0.0.8-2.el6.noarch > (foreman) > Requires: ruby193-ruby(rubygems) > Error: Package: ruby193-rubygem-ruby_parser-3.1.1-5.el6.noarch (foreman) > Requires: /usr/bin/ruby > Error: Package: rubygem-rdoc-3.12-12.el6.x86_64 (foreman) > Requires: ruby-irb > Error: Package: rubygem-foreman_api-0.1.11-1.el6.noarch (foreman) > Requires: ruby(abi) > Error: Package: rubygem-oauth-0.4.7-5.el6.noarch (foreman) > Requires: ruby(abi) > Error: Package: ruby193-ruby-wrapper-0.0.2-5.el6.noarch (foreman) > Requires: ruby193-ruby(abi) = 1.9.1 > Error: Package: rubygem-little-plugger-1.1.3-17.el6.noarch (foreman) > Requires: ruby(rubygems) > Error: Package: ruby193-facter-1.6.18-4.el6.x86_64 (foreman) > Requires: /opt/rh/ruby193/root/usr/bin/ruby > Error: Package: ruby193-rubygem-deface-0.7.2-6.el6.noarch (foreman-plugins) > Requires: ruby193-rubygem(rails) > Error: Package: ruby-augeas-0.4.1-3.el6.x86_64 (puppetlabs-deps) > Requires: libaugeas.so.0(AUGEAS_0.1.0)(64bit) > Error: Package: ruby193-rubygem-deep_cloneable-1.6.0-2.el6.noarch (foreman) > Requires: ruby193-ruby(rubygems) > Error: Package: ruby193-rubygem-eventmachine-0.12.10-9.el6.x86_64 (foreman) > Requires: ruby193-ruby(rubygems) > Error: Package: ruby193-rubygem-sass-3.2.13-1.el6.noarch (foreman) > Requires: ruby193-ruby > Error: Package: rubygem-multi_json-1.8.2-1.el6.noarch (foreman) > Requires: ruby(rubygems) > Error: Package: rubygem-clamp-0.6.2-1.el6.noarch (foreman) > Requires: ruby(rubygems) > You could try using --skip-broken to work around the problem > You could try running: rpm -Va --nofiles --nodigest > > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > From acvelez at vidalinux.com Wed Jun 18 06:24:01 2014 From: acvelez at vidalinux.com (Antonio C. Velez) Date: Wed, 18 Jun 2014 02:24:01 -0400 (AST) Subject: [Rdo-list] Centos 6.5 Staypuft OpenStack Foreman Installer Ruby Error In-Reply-To: <108632499.35997.1403071390022.JavaMail.zimbra@vidalinux.net> Message-ID: <312001956.36005.1403072641357.JavaMail.zimbra@vidalinux.net> Hi All, I'm testing the staypuft project in centos 6.5 x86_64 everything is working correctly using an older version: foreman-installer-staypuft-0.0.12-1.el6.noarch.rpm, but if I try with a newer version got the following error: # staypuft-installer /opt/rh/ruby193/root/usr/share/rubygems/rubygems/custom_require.rb:36:in `require': cannot load such file -- highline/import (LoadError) from /opt/rh/ruby193/root/usr/share/rubygems/rubygems/custom_require.rb:36:in `require' from /usr/sbin/staypuft-installer:3:in `
' Someone you know what I'm missing? Thanks! -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From ihrachys at redhat.com Wed Jun 18 11:08:25 2014 From: ihrachys at redhat.com (Ihar Hrachyshka) Date: Wed, 18 Jun 2014 13:08:25 +0200 Subject: [Rdo-list] RDO status on EL7 In-Reply-To: <1403032712.3723.4.camel@localhost.localdomain> References: <53A04624.3080804@karan.org> <1403032712.3723.4.camel@localhost.localdomain> Message-ID: <53A17329.6020701@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 17/06/14 21:18, whayutin wrote: > On Tue, 2014-06-17 at 14:44 +0100, Karanbir Singh wrote: >> hi guys, >> >> Just wondering what the status of RDO on EL7 was, the quickstart >> still only mentions 6.5 as being the supported ( tested ? ) >> version. >> >> - KB >> > > You should expect success w/ RDO on RHEL 7 w/ aio, and multi node > configurations. There is an open bug on neutron w/ vxlan > networking atm. GRE and ML2 networking should work. > > https://bugzilla.redhat.com/show_bug.cgi?id=1081011 > As far as I know, the bug was fixed as of openstack-neutron-2014.1-19.el7 (which was released on May 28). I've moved the bug to ON_QA. So we expect VXLAN to work correctly too. > _______________________________________________ Rdo-list mailing > list Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJToXMpAAoJEC5aWaUY1u57XqUIAKtJA3QX46z0+e86sOUe6YdG PouOV3ppFMPolpCDtrDsh+jsw2iBD66m7FpmH2OtswvIcauDtPP8BIZhK8l1f6yq foQ0Z5vXqiWcNT4L0VLQm6ukrjS26P8Xoe1JKIHMJHb+C34i6KUy04amHC4CTQ6s 77UqheCoTFjbNtf8ashnKgyXjMnkGRTh21Q9O+s+cIqNwI1MvVWe/fGlWryyTfr3 tvaF4S9zqrWZon8uZU+in+sJMljvATdN8anWn9f+RX8mRFSsfMyiTJ5kfCTeIZP+ +uxsTDWAmjyS6aa1mYh/ngESL6h5cOGADMCn2pd9231QXnwBI2FX+df0D41T/7g= =1/b4 -----END PGP SIGNATURE----- From tarkan.erimer at f-secure.com Wed Jun 18 11:15:45 2014 From: tarkan.erimer at f-secure.com (Erimer, Tarkan) Date: Wed, 18 Jun 2014 11:15:45 +0000 Subject: [Rdo-list] ldap/AD Integration on RDO - Icehouse Message-ID: <1403090145.6960.3.camel@fsdell1407.fi.f-secure.com> Hi, I was trying to integrate our test RDO - Icehouse openstack environment into the AD (Active Directory) in order to pilot user management through the AD. I've read official documentations regarding the topic : http://docs.openstack.org/admin-guide-cloud/content/configuring-keystone-for-ldap-backend.html https://wiki.openstack.org/wiki/HowtoIntegrateKeystonewithAD#Configuration_on_Keystone http://openstack.redhat.com/Keystone_integration_with_IDM All the above docs only explain just the keystone part. But, there is no doc how exactly the AD side should be configured. Even, searching on google didn't return anything useful. Anyway, I've managed to come to a point where having the following error in keystone.log : 2014-06-18 10:52:55.096 1706 INFO eventlet.wsgi.server [-] (1706) wsgi starting up on http://0.0.0.0:35357/ 2014-06-18 10:52:55.096 1706 INFO eventlet.wsgi.server [-] (1706) wsgi starting up on http://0.0.0.0:5000/ 2014-06-18 10:56:35.024 1706 DEBUG keystone.middleware.core [-] Auth token not in the request header. Will not build auth context. process_request /usr/lib/python2.6/site-packages/keystone/middleware/core.py:271 2014-06-18 10:56:35.063 1706 DEBUG keystone.common.wsgi [-] arg_dict: {} __call__ /usr/lib/python2.6/site-packages/keystone/common/wsgi.py:181 2014-06-18 10:56:35.065 1706 DEBUG keystone.common.ldap.core [-] LDAP init: url=ldap://1.x.x.x __init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:491 2014-06-18 10:56:35.066 1706 DEBUG keystone.common.ldap.core [-] LDAP init: use_tls=False tls_cacertfile=None tls_cacertdir=None tls_req_cert=2 tls_avail=1 __init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:501 2014-06-18 10:56:35.069 1706 DEBUG keystone.common.ldap.core [-] LDAP bind: dn=CN=openstack-user,OU=iaas,OU=Other,DC=test,DC=local simple_bind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:561 2014-06-18 10:56:35.076 1706 DEBUG keystone.common.ldap.core [-] LDAP search: dn=OU=iaas,OU=Other,DC=test,DC=local, scope=2, query=(&(sAMAccountName=nova)(objectClass=Person)), attrs=['userPassword', 'userAccountControl', 'sAMAccountName', 'mail'] search_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:592 2014-06-18 10:56:35.079 1706 DEBUG keystone.common.ldap.core [-] LDAP unbind unbind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:565 2014-06-18 10:56:35.081 1706 DEBUG keystone.notifications [-] CADF Event: {'typeURI': 'http://schemas.dmtf.org/cloud/audit/1.0/event', 'initiator': {'typeURI': 'service/security/account/user', 'host': {'agent': 'python-requests/1.1.0 CPython/2.6.6 Linux/2.6.32-431.17.1.el6.x86_64', 'address': '1.x.x.x'}, 'id': 'openstack:3b761d61-1f9c-463c-adc4-cf83a8873aaa', 'name': 'nova'}, 'target': {'typeURI': 'service/security/account/user', 'id': 'openstack:b588a4a4-4537-4a3c-a56e-68d7518bbf69'}, 'observer': {'typeURI': 'service/security', 'id': 'openstack:35c9ba06-17b0-482f-b86a-c7407b698fe2'}, 'eventType': 'activity', 'eventTime': '2014-06-18T10:56:35.080881+0000', 'action': 'authenticate', 'outcome': 'pending', 'id': 'openstack:d4b86103-3dc9-4577-a9c4-74fc2cc4152c'} _send_audit_notification /usr/lib/python2.6/site-packages/keystone/notifications.py:289 2014-06-18 10:56:35.136 1706 DEBUG stevedore.extension [-] found extension EntryPoint.parse('qpid = oslo.messaging._drivers.impl_qpid:QpidDriver') _load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156 2014-06-18 10:56:35.136 1706 DEBUG stevedore.extension [-] found extension EntryPoint.parse('zmq = oslo.messaging._drivers.impl_zmq:ZmqDriver') _load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156 2014-06-18 10:56:35.136 1706 DEBUG stevedore.extension [-] found extension EntryPoint.parse('kombu = oslo.messaging._drivers.impl_rabbit:RabbitDriver') _load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156 2014-06-18 10:56:35.137 1706 DEBUG stevedore.extension [-] found extension EntryPoint.parse('rabbit = oslo.messaging._drivers.impl_rabbit:RabbitDriver') _load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156 2014-06-18 10:56:35.194 1706 DEBUG stevedore.extension [-] found extension EntryPoint.parse('fake = oslo.messaging._drivers.impl_fake:FakeDriver') _load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156 2014-06-18 10:56:35.195 1706 DEBUG stevedore.extension [-] found extension EntryPoint.parse('log = oslo.messaging.notify._impl_log:LogDriver') _load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156 2014-06-18 10:56:35.195 1706 DEBUG stevedore.extension [-] found extension EntryPoint.parse('messagingv2 = oslo.messaging.notify._impl_messaging:MessagingV2Driver') _load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156 2014-06-18 10:56:35.195 1706 DEBUG stevedore.extension [-] found extension EntryPoint.parse('noop = oslo.messaging.notify._impl_noop:NoOpDriver') _load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156 2014-06-18 10:56:35.196 1706 DEBUG stevedore.extension [-] found extension EntryPoint.parse('routing = oslo.messaging.notify._impl_routing:RoutingDriver') _load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156 2014-06-18 10:56:35.196 1706 DEBUG stevedore.extension [-] found extension EntryPoint.parse('test = oslo.messaging.notify._impl_test:TestDriver') _load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156 2014-06-18 10:56:35.196 1706 DEBUG stevedore.extension [-] found extension EntryPoint.parse('messaging = oslo.messaging.notify._impl_messaging:MessagingDriver') _load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156 2014-06-18 10:56:35.196 1706 DEBUG stevedore.extension [-] found extension EntryPoint.parse('cinder.openstack.common.notifier.no_op_notifier = oslo.messaging.notify._impl_noop:NoOpDriver') _load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156 2014-06-18 10:56:35.196 1706 DEBUG stevedore.extension [-] found extension EntryPoint.parse('cinder.openstack.common.notifier.log_notifier = oslo.messaging.notify._impl_log:LogDriver') _load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156 2014-06-18 10:56:35.197 1706 DEBUG stevedore.extension [-] found extension EntryPoint.parse('cinder.openstack.common.notifier.test_notifier = oslo.messaging.notify._impl_test:TestDriver') _load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156 2014-06-18 10:56:35.197 1706 DEBUG stevedore.extension [-] found extension EntryPoint.parse('cinder.openstack.common.notifier.rpc_notifier2 = oslo.messaging.notify._impl_messaging:MessagingV2Driver') _load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156 2014-06-18 10:56:35.197 1706 DEBUG stevedore.extension [-] found extension EntryPoint.parse('cinder.openstack.common.notifier.rpc_notifier = oslo.messaging.notify._impl_messaging:MessagingDriver') _load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156 2014-06-18 10:56:35.197 1706 DEBUG stevedore.extension [-] found extension EntryPoint.parse('nova.openstack.common.notifier.no_op_notifier = oslo.messaging.notify._impl_noop:NoOpDriver') _load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156 2014-06-18 10:56:35.197 1706 DEBUG stevedore.extension [-] found extension EntryPoint.parse('nova.openstack.common.notifier.test_notifier = oslo.messaging.notify._impl_test:TestDriver') _load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156 2014-06-18 10:56:35.197 1706 DEBUG stevedore.extension [-] found extension EntryPoint.parse('nova.openstack.common.notifier.rpc_notifier = oslo.messaging.notify._impl_messaging:MessagingDriver') _load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156 2014-06-18 10:56:35.198 1706 DEBUG stevedore.extension [-] found extension EntryPoint.parse('nova.openstack.common.notifier.log_notifier = oslo.messaging.notify._impl_log:LogDriver') _load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156 2014-06-18 10:56:35.198 1706 DEBUG stevedore.extension [-] found extension EntryPoint.parse('nova.openstack.common.notifier.rpc_notifier2 = oslo.messaging.notify._impl_messaging:MessagingV2Driver') _load_plugins /usr/lib/python2.6/site-packages/stevedore/extension.py:156 2014-06-18 10:56:35.199 1706 DEBUG keystone.common.ldap.core [-] LDAP init: url=ldap://1.x.x.x __init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:491 2014-06-18 10:56:35.200 1706 DEBUG keystone.common.ldap.core [-] LDAP init: use_tls=False tls_cacertfile=None tls_cacertdir=None tls_req_cert=2 tls_avail=1 __init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:501 2014-06-18 10:56:35.200 1706 DEBUG keystone.common.ldap.core [-] LDAP bind: dn=CN=openstack-user,OU=iaas,OU=Other,DC=test,DC=local simple_bind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:561 2014-06-18 10:56:35.205 1706 DEBUG keystone.common.ldap.core [-] LDAP search: dn=OU=iaas,OU=Other,DC=test,DC=local, scope=2, query=(&(cn=nova)(objectClass=Person)), attrs=['mail', 'userPassword', 'userAccountControl', 'sAMAccountName'] search_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:592 2014-06-18 10:56:35.207 1706 DEBUG keystone.common.ldap.core [-] LDAP unbind unbind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:565 2014-06-18 10:56:35.208 1706 DEBUG keystone.common.ldap.core [-] LDAP init: url=ldap://1.x.x.x __init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:491 2014-06-18 10:56:35.209 1706 DEBUG keystone.common.ldap.core [-] LDAP init: use_tls=False tls_cacertfile=None tls_cacertdir=None tls_req_cert=2 tls_avail=1 __init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:501 2014-06-18 10:56:35.210 1706 DEBUG keystone.common.ldap.core [-] LDAP bind: dn=CN=openstack-user,OU=iaas,OU=Other,DC=test,DC=local simple_bind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:561 2014-06-18 10:56:35.215 1706 DEBUG keystone.common.ldap.core [-] LDAP search: dn=OU=iaas,OU=Other,DC=test,DC=local, scope=2, query=(&(cn=nova)(objectclass=Person)), attrs=None search_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:592 2014-06-18 10:56:35.218 1706 DEBUG keystone.common.ldap.core [-] LDAP unbind unbind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:565 2014-06-18 10:56:35.218 1706 DEBUG keystone.common.ldap.core [-] LDAP init: url=ldap://1.x.x.x __init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:491 2014-06-18 10:56:35.219 1706 DEBUG keystone.common.ldap.core [-] LDAP init: use_tls=False tls_cacertfile=None tls_cacertdir=None tls_req_cert=2 tls_avail=1 __init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:501 2014-06-18 10:56:35.220 1706 DEBUG keystone.common.ldap.core [-] LDAP bind: dn=CN=nova,OU=services,OU=Projects,OU=iaas,OU=Other,DC=test,DC=local simple_bind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:561 2014-06-18 10:56:35.224 1706 DEBUG keystone.common.ldap.core [-] LDAP unbind unbind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:565 2014-06-18 10:56:35.226 1706 DEBUG keystone.notifications [-] CADF Event: {'typeURI': 'http://schemas.dmtf.org/cloud/audit/1.0/event', 'initiator': {'typeURI': 'service/security/account/user', 'host': {'agent': 'python-requests/1.1.0 CPython/2.6.6 Linux/2.6.32-431.17.1.el6.x86_64', 'address': '1.x.x.x'}, 'id': 'openstack:3b761d61-1f9c-463c-adc4-cf83a8873aaa', 'name': 'nova'}, 'target': {'typeURI': 'service/security/account/user', 'id': 'openstack:12c5c400-0a51-4477-baf4-b95c91ba60ad'}, 'observer': {'typeURI': 'service/security', 'id': 'openstack:d12b322f-9c1a-493f-ac0d-6727d37cff39'}, 'eventType': 'activity', 'eventTime': '2014-06-18T10:56:35.225896+0000', 'action': 'authenticate', 'outcome': 'success', 'id': 'openstack:aa435cf2-6fd2-4cce-a40e-53753cab55bf'} _send_audit_notification /usr/lib/python2.6/site-packages/keystone/notifications.py:289 2014-06-18 10:56:35.227 1706 DEBUG keystone.common.ldap.core [-] LDAP init: url=ldap://1.x.x.x __init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:491 2014-06-18 10:56:35.228 1706 DEBUG keystone.common.ldap.core [-] LDAP init: use_tls=False tls_cacertfile=None tls_cacertdir=None tls_req_cert=2 tls_avail=1 __init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:501 2014-06-18 10:56:35.229 1706 DEBUG keystone.common.ldap.core [-] LDAP bind: dn=CN=openstack-user,OU=iaas,OU=Other,DC=test,DC=local simple_bind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:561 2014-06-18 10:56:35.234 1706 DEBUG keystone.common.ldap.core [-] LDAP search: dn=OU=Tenants,OU=iaas,OU=Other,DC=test,DC=local, scope=2, query=(&(ou=services)(objectClass=organizationalUnit)), attrs=['description', 'extensionName', 'businessCategory', 'ou'] search_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:592 2014-06-18 10:56:35.237 1706 DEBUG keystone.common.ldap.core [-] LDAP unbind unbind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:565 2014-06-18 10:56:35.237 1706 DEBUG keystone.common.ldap.core [-] LDAP init: url=ldap://1.x.x.x __init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:491 2014-06-18 10:56:35.238 1706 DEBUG keystone.common.ldap.core [-] LDAP init: use_tls=False tls_cacertfile=None tls_cacertdir=None tls_req_cert=2 tls_avail=1 __init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:501 2014-06-18 10:56:35.238 1706 DEBUG keystone.common.ldap.core [-] LDAP bind: dn=CN=openstack-user,OU=iaas,OU=Other,DC=test,DC=local simple_bind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:561 2014-06-18 10:56:35.243 1706 DEBUG keystone.common.ldap.core [-] LDAP search: dn=OU=Tenants,OU=iaas,OU=Other,DC=test,DC=local, scope=2, query=(&(ou=services)(objectClass=organizationalUnit)), attrs=['ou', 'description', 'businessCategory', 'extensionName'] search_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:592 2014-06-18 10:56:35.246 1706 DEBUG keystone.common.ldap.core [-] LDAP unbind unbind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:565 2014-06-18 10:56:35.246 1706 DEBUG keystone.common.ldap.core [-] LDAP init: url=ldap://1.x.x.x __init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:491 2014-06-18 10:56:35.247 1706 DEBUG keystone.common.ldap.core [-] LDAP init: use_tls=False tls_cacertfile=None tls_cacertdir=None tls_req_cert=2 tls_avail=1 __init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:501 2014-06-18 10:56:35.247 1706 DEBUG keystone.common.ldap.core [-] LDAP bind: dn=CN=openstack-user,OU=iaas,OU=Other,DC=test,DC=local simple_bind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:561 2014-06-18 10:56:35.251 1706 DEBUG keystone.common.ldap.core [-] LDAP search: dn=OU=Tenants,OU=iaas,OU=Other,DC=test,DC=local, scope=2, query=(&(ou=services)(objectClass=organizationalUnit)), attrs=['ou', 'description', 'businessCategory', 'extensionName'] search_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:592 2014-06-18 10:56:35.254 1706 DEBUG keystone.common.ldap.core [-] LDAP unbind unbind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:565 2014-06-18 10:56:35.254 1706 DEBUG keystone.common.ldap.core [-] LDAP init: url=ldap://1.x.x.x __init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:491 2014-06-18 10:56:35.255 1706 DEBUG keystone.common.ldap.core [-] LDAP init: use_tls=False tls_cacertfile=None tls_cacertdir=None tls_req_cert=2 tls_avail=1 __init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:501 2014-06-18 10:56:35.256 1706 DEBUG keystone.common.ldap.core [-] LDAP bind: dn=CN=openstack-user,OU=iaas,OU=Other,DC=test,DC=local simple_bind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:561 2014-06-18 10:56:35.261 1706 DEBUG keystone.common.ldap.core [-] LDAP search: dn=OU=Tenants,OU=iaas,OU=Other,DC=test,DC=local, scope=2, query=(&(ou=services)(objectClass=organizationalUnit)), attrs=['ou', 'description', 'businessCategory', 'extensionName'] search_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:592 2014-06-18 10:56:35.263 1706 DEBUG keystone.common.ldap.core [-] LDAP unbind unbind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:565 2014-06-18 10:56:35.264 1706 DEBUG keystone.common.ldap.core [-] LDAP init: url=ldap://1.x.x.x __init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:491 2014-06-18 10:56:35.265 1706 DEBUG keystone.common.ldap.core [-] LDAP init: use_tls=False tls_cacertfile=None tls_cacertdir=None tls_req_cert=2 tls_avail=1 __init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:501 2014-06-18 10:56:35.266 1706 DEBUG keystone.common.ldap.core [-] LDAP bind: dn=CN=openstack-user,OU=iaas,OU=Other,DC=test,DC=local simple_bind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:561 2014-06-18 10:56:35.270 1706 DEBUG keystone.common.ldap.core [-] LDAP search: dn=OU=Tenants,OU=iaas,OU=Other,DC=test,DC=local, scope=2, query=(&(ou=services)(objectclass=organizationalUnit)), attrs=None search_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:592 2014-06-18 10:56:35.273 1706 DEBUG keystone.common.ldap.core [-] LDAP unbind unbind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:565 2014-06-18 10:56:35.273 1706 DEBUG keystone.common.ldap.core [-] LDAP init: url=ldap://1.x.x.x __init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:491 2014-06-18 10:56:35.274 1706 DEBUG keystone.common.ldap.core [-] LDAP init: use_tls=False tls_cacertfile=None tls_cacertdir=None tls_req_cert=2 tls_avail=1 __init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:501 2014-06-18 10:56:35.274 1706 DEBUG keystone.common.ldap.core [-] LDAP bind: dn=CN=openstack-user,OU=iaas,OU=Other,DC=test,DC=local simple_bind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:561 2014-06-18 10:56:35.278 1706 DEBUG keystone.common.ldap.core [-] LDAP search: dn=OU=services,OU=Tenants,OU=iaas,OU=Other,DC=test,DC=local, scope=1, query=(objectClass=organizationalRole), attrs=None search_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:592 2014-06-18 10:56:35.281 1706 DEBUG keystone.common.ldap.core [-] LDAP unbind unbind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:565 2014-06-18 10:56:35.282 1706 DEBUG keystone.common.ldap.core [-] LDAP init: url=ldap://1.x.x.x __init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:491 2014-06-18 10:56:35.283 1706 DEBUG keystone.common.ldap.core [-] LDAP init: use_tls=False tls_cacertfile=None tls_cacertdir=None tls_req_cert=2 tls_avail=1 __init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:501 2014-06-18 10:56:35.284 1706 DEBUG keystone.common.ldap.core [-] LDAP bind: dn=CN=openstack-user,OU=iaas,OU=Other,DC=test,DC=local simple_bind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:561 2014-06-18 10:56:35.289 1706 DEBUG keystone.common.ldap.core [-] LDAP search: dn=OU=iaas,OU=Other,DC=test,DC=local, scope=2, query=(&(cn=nova)(objectClass=Person)), attrs=['mail', 'userPassword', 'userAccountControl', 'sAMAccountName'] search_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:592 2014-06-18 10:56:35.291 1706 DEBUG keystone.common.ldap.core [-] LDAP unbind unbind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:565 2014-06-18 10:56:35.292 1706 DEBUG keystone.common.ldap.core [-] LDAP init: url=ldap://1.x.x.x __init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:491 2014-06-18 10:56:35.292 1706 DEBUG keystone.common.ldap.core [-] LDAP init: use_tls=False tls_cacertfile=None tls_cacertdir=None tls_req_cert=2 tls_avail=1 __init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:501 2014-06-18 10:56:35.293 1706 DEBUG keystone.common.ldap.core [-] LDAP bind: dn=CN=openstack-user,OU=iaas,OU=Other,DC=test,DC=local simple_bind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:561 2014-06-18 10:56:35.297 1706 DEBUG keystone.common.ldap.core [-] LDAP search: dn=OU=iaas,OU=Other,DC=test,DC=local, scope=2, query=(&(cn=nova)(objectclass=Person)), attrs=None search_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:592 2014-06-18 10:56:35.300 1706 DEBUG keystone.common.ldap.core [-] LDAP unbind unbind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:565 2014-06-18 10:56:35.300 1706 DEBUG keystone.common.ldap.core [-] LDAP init: url=ldap://1.x.x.x __init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:491 2014-06-18 10:56:35.302 1706 DEBUG keystone.common.ldap.core [-] LDAP init: use_tls=False tls_cacertfile=None tls_cacertdir=None tls_req_cert=2 tls_avail=1 __init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:501 2014-06-18 10:56:35.303 1706 DEBUG keystone.common.ldap.core [-] LDAP bind: dn=CN=openstack-user,OU=iaas,OU=Other,DC=test,DC=local simple_bind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:561 2014-06-18 10:56:35.307 1706 DEBUG keystone.common.ldap.core [-] LDAP search: dn=ou=UserGroups,dc=test,dc=local, scope=2, query=(&(&(objectClass=groupOfNames)(member=CN=nova,OU=services,OU=Projects,OU=iaas,OU=Other,DC=test,DC=local))(objectClass=groupOfNames)), attrs=['description', 'ou'] search_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:592 2014-06-18 10:56:35.310 1706 DEBUG keystone.common.ldap.core [-] LDAP unbind unbind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:565 2014-06-18 10:56:35.336 1706 DEBUG keystone.openstack.common.db.sqlalchemy.session [-] MySQL server mode set to STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,TRADITIONAL,NO_AUTO_CREATE_USER _mysql_check_effective_sql_mode /usr/lib/python2.6/site-packages/keystone/openstack/common/db/sqlalchemy/session.py:562 2014-06-18 10:56:35.384 1706 DEBUG keystone.common.ldap.core [-] LDAP init: url=ldap://1.x.x.x __init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:491 2014-06-18 10:56:35.385 1706 DEBUG keystone.common.ldap.core [-] LDAP init: use_tls=False tls_cacertfile=None tls_cacertdir=None tls_req_cert=2 tls_avail=1 __init__ /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:501 2014-06-18 10:56:35.386 1706 DEBUG keystone.common.ldap.core [-] LDAP bind: dn=CN=openstack-user,OU=iaas,OU=Other,DC=test,DC=local simple_bind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:561 2014-06-18 10:56:36.391 1706 DEBUG keystone.common.ldap.core [-] LDAP search: dn=OU=Roles,OU=iaas,OU=Other,DC=test,DC=local, scope=2, query=(&(cn=services)(objectClass=organizationalRole)), attrs=['cn'] search_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:592 2014-06-18 10:56:36.393 1706 DEBUG keystone.common.ldap.core [-] LDAP unbind unbind_s /usr/lib/python2.6/site-packages/keystone/common/ldap/core.py:565 2014-06-18 10:56:36.471 1706 INFO eventlet.wsgi.server [-] 1.x.x.x - - [18/Jun/2014 10:56:36] "POST /v2.0/tokens HTTP/1.1" 200 8938 1.447416 2014-06-18 10:56:36.520 1706 DEBUG keystone.middleware.core [-] RBAC: auth_context: {'project_id': u'services', 'user_id': u'nova', 'roles': [u'services']} process_request /usr/lib/python2.6/site-packages/keystone/middleware/core.py:281 2014-06-18 10:56:36.523 1706 DEBUG keystone.common.wsgi [-] arg_dict: {'token_id': u'4dd244aee826e0ea0f1a27e7a9d42885'} __call__ /usr/lib/python2.6/site-packages/keystone/common/wsgi.py:181 2014-06-18 10:56:36.525 1706 DEBUG keystone.common.controller [-] RBAC: Authorizing identity:validate_token(token_id=4dd244aee826e0ea0f1a27e7a9d42885) _build_policy_check_credentials /usr/lib/python2.6/site-packages/keystone/common/controller.py:54 2014-06-18 10:56:36.526 1706 DEBUG keystone.common.controller [-] RBAC: using auth context from the request environment _build_policy_check_credentials /usr/lib/python2.6/site-packages/keystone/common/controller.py:59 2014-06-18 10:56:36.527 1706 DEBUG keystone.policy.backends.rules [-] enforce identity:validate_token: {'project_id': u'services', 'user_id': u'nova', 'roles': [u'services']} enforce /usr/lib/python2.6/site-packages/keystone/policy/backends/rules.py:101 2014-06-18 10:56:36.536 1706 DEBUG keystone.openstack.common.policy [-] Rule identity:validate_token will be now enforced enforce /usr/lib/python2.6/site-packages/keystone/openstack/common/policy.py:258 2014-06-18 10:56:36.537 1706 DEBUG keystone.openstack.common.fileutils [-] Reloading cached file /etc/keystone/policy.json read_cached_file /usr/lib/python2.6/site-packages/keystone/openstack/common/fileutils.py:63 2014-06-18 10:56:36.545 1706 DEBUG keystone.openstack.common.policy [-] Rules successfully reloaded load_rules /usr/lib/python2.6/site-packages/keystone/openstack/common/policy.py:212 2014-06-18 10:56:36.546 1706 WARNING keystone.common.wsgi [-] You are not authorized to perform the requested action, identity:validate_token. 2014-06-18 10:56:36.548 1706 INFO eventlet.wsgi.server [-] 1.x.x.x - - [18/Jun/2014 10:56:36] "GET /v2.0/tokens/4dd244aee826e0ea0f1a27e7a9d42885 HTTP/1.1" 403 277 0.037631 2014-06-18 10:56:36.560 1706 DEBUG keystone.middleware.core [-] RBAC: auth_context: {'project_id': u'services', 'user_id': u'nova', 'roles': [u'services']} process_request /usr/lib/python2.6/site-packages/keystone/middleware/core.py:281 2014-06-18 10:56:36.563 1706 DEBUG keystone.common.wsgi [-] arg_dict: {'token_id': u'4dd244aee826e0ea0f1a27e7a9d42885'} __call__ /usr/lib/python2.6/site-packages/keystone/common/wsgi.py:181 2014-06-18 10:56:36.563 1706 DEBUG keystone.common.controller [-] RBAC: Authorizing identity:validate_token(token_id=4dd244aee826e0ea0f1a27e7a9d42885) _build_policy_check_credentials /usr/lib/python2.6/site-packages/keystone/common/controller.py:54 2014-06-18 10:56:36.564 1706 DEBUG keystone.common.controller [-] RBAC: using auth context from the request environment _build_policy_check_credentials /usr/lib/python2.6/site-packages/keystone/common/controller.py:59 2014-06-18 10:56:36.564 1706 DEBUG keystone.policy.backends.rules [-] enforce identity:validate_token: {'project_id': u'services', 'user_id': u'nova', 'roles': [u'services']} enforce /usr/lib/python2.6/site-packages/keystone/policy/backends/rules.py:101 2014-06-18 10:56:36.565 1706 DEBUG keystone.openstack.common.policy [-] Rule identity:validate_token will be now enforced enforce /usr/lib/python2.6/site-packages/keystone/openstack/common/policy.py:258 2014-06-18 10:56:36.565 1706 WARNING keystone.common.wsgi [-] You are not authorized to perform the requested action, identity:validate_token. 2014-06-18 10:56:36.566 1706 INFO eventlet.wsgi.server [-] 1.x.x.x - - [18/Jun/2014 10:56:36] "GET /v2.0/tokens/4dd244aee826e0ea0f1a27e7a9d42885 HTTP/1.1" 403 277 0.014182 Thus, not letting me in on the WebUI. My keystone.conf ldap configuration is : driver = keystone.identity.backends.ldap.Identity [ldap] query_scope = sub url = ldap://1.x.x.x user = CN=openstack-user,OU=iaas,OU=Other,DC=test,DC=local password = XXXXX suffix = dc=test,dc=local use_dumb_member = True dumb_member = CN=openstack-user,OU=iaas,OU=Other,DC=test,DC=local user_tree_dn = OU=iaas,OU=Other,DC=test,DC=local #user_objectclass = organizationalPerson user_objectclass = Person user_id_attribute = cn user_name_attribute = sAMAccountName user_mail_attribute = mail user_enabled_attribute = userAccountControl user_enabled_mask = 2 user_enabled_default = 512 user_attribute_ignore = password,tenant_id,tenants user_allow_create = True user_allow_update = True user_allow_delete = True tenant_tree_dn = OU=Tenants,OU=iaas,OU=Other,DC=test,DC=local tenant_objectclass = organizationalUnit tenant_id_attribute = ou tenant_member_attribute = member tenant_name_attribute = ou tenant_desc_attribute = description tenant_enabled_attribute = extensionName tenant_attribute_ignore = description,businessCategory,extensionName tenant_allow_create = True tenant_allow_update = True tenant_allow_delete = True role_tree_dn = OU=Roles,OU=iaas,OU=Other,DC=test,DC=local #role_tree_dn = CN=admin,OU=Services,OU=Roles,OU=iaas,OU=Other,DC=test,DC=local role_objectclass = organizationalRole role_id_attribute = cn role_name_attribute = cn role_member_attribute = roleOccupant role_allow_create = True role_allow_update = True role_allow_delete = True Any pointers ? Tarkan From ihrachys at redhat.com Wed Jun 18 12:19:08 2014 From: ihrachys at redhat.com (Ihar Hrachyshka) Date: Wed, 18 Jun 2014 14:19:08 +0200 Subject: [Rdo-list] RDO status on EL7 In-Reply-To: <53A17329.6020701@redhat.com> References: <53A04624.3080804@karan.org> <1403032712.3723.4.camel@localhost.localdomain> <53A17329.6020701@redhat.com> Message-ID: <53A183BC.3030607@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 18/06/14 13:08, Ihar Hrachyshka wrote: > On 17/06/14 21:18, whayutin wrote: >> On Tue, 2014-06-17 at 14:44 +0100, Karanbir Singh wrote: >>> hi guys, >>> >>> Just wondering what the status of RDO on EL7 was, the >>> quickstart still only mentions 6.5 as being the supported ( >>> tested ? ) version. >>> >>> - KB >>> > >> You should expect success w/ RDO on RHEL 7 w/ aio, and multi node >> configurations. There is an open bug on neutron w/ vxlan >> networking atm. GRE and ML2 networking should work. > >> https://bugzilla.redhat.com/show_bug.cgi?id=1081011 > > > As far as I know, the bug was fixed as of > openstack-neutron-2014.1-19.el7 (which was released on May 28). > I've moved the bug to ON_QA. > > So we expect VXLAN to work correctly too. Now people tell me updates haven't reached RDO repos since that long time. So sorry for missunderstanding, but it seems VXLAN is still broken. Cheers, /Ihar -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJToYO8AAoJEC5aWaUY1u57+cwIAJRdBotLlL9D2i+X14pPGen9 /UPHksxda44/d3cVhbRasDoTCUT+t7b+pxvsofdNImQ47kSuqyVDcKWhqd1BhPZS JgYR/YR54fa9HxZFGTm4z47Ewfb/OfRdeILWhzpufGu+mmaO88H9BB8dLKgj7AJ5 dT8eJgCTQIs6Ja6SqItQL5Y6AoIPM1oXSDSMuJdyw9GbOnWXd2wFZlJXH1mHKCe2 c7en3+dRHc8kD3Hh5LqrBeR4COYJcEhkc1NWeMWR6C95wrBIPU5cETj5jUwQzF5X JC6Wpgpk3T3VS0+0Zcta3GiFHgUHsL5tvGdBcWfbRUMV4w9ILu6DCiJyVkWcOJs= =mUGp -----END PGP SIGNATURE----- From rdo-info at redhat.com Wed Jun 18 13:29:37 2014 From: rdo-info at redhat.com (RDO Forum) Date: Wed, 18 Jun 2014 13:29:37 +0000 Subject: [Rdo-list] [RDO] RDO welcomes eNovance to the Red Hat family! Message-ID: <00000146af2b1f25-45e54558-2dd8-42ec-8ab3-f2d92d38e7c4-000000@email.amazonses.com> rbowen started a discussion. RDO welcomes eNovance to the Red Hat family! --- Follow the link below to check it out: http://openstack.redhat.com/forum/discussion/976/rdo-welcomes-enovance-to-the-red-hat-family Have a great day! From rbowen at redhat.com Wed Jun 18 13:40:05 2014 From: rbowen at redhat.com (Rich Bowen) Date: Wed, 18 Jun 2014 09:40:05 -0400 Subject: [Rdo-list] OpenStack 4th Birthday Italy looking for speakers Message-ID: <53A196B5.1070702@redhat.com> Seen on Twitter this morning: https://twitter.com/miumiento/status/479197282425122816 OpenStack 4th BDay Italy: http://goo.gl/nTlpx6 #OpenStack4BDayIT We are looking for speakers @OpenStack @ORCL_Solaris @RDOcommunity @SUSE If you're anywhere near Rome, check out http://www.meetup.com/OpenStack-User-Group-Italia/events/183762562/ for more details. --Rich -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://openstack.redhat.com/ From gfidente at redhat.com Wed Jun 18 13:52:28 2014 From: gfidente at redhat.com (Giulio Fidente) Date: Wed, 18 Jun 2014 15:52:28 +0200 Subject: [Rdo-list] OpenStack 4th Birthday Italy looking for speakers In-Reply-To: <53A196B5.1070702@redhat.com> References: <53A196B5.1070702@redhat.com> Message-ID: <53A1999C.8090000@redhat.com> On 06/18/2014 03:40 PM, Rich Bowen wrote: > Seen on Twitter this morning: > > https://twitter.com/miumiento/status/479197282425122816 I'll be there, ping if youn need a lift or something. -- Giulio Fidente GPG KEY: 08D733BA From mail-lists at karan.org Wed Jun 18 14:49:51 2014 From: mail-lists at karan.org (Karanbir Singh) Date: Wed, 18 Jun 2014 15:49:51 +0100 Subject: [Rdo-list] RDO status on EL7 In-Reply-To: <53A064C2.5060200@redhat.com> References: <53A04624.3080804@karan.org> <53A0482D.9060605@redhat.com> <53A064C2.5060200@redhat.com> Message-ID: <53A1A70F.4040107@karan.org> On 06/17/2014 04:54 PM, Rich Bowen wrote: > > On 06/17/2014 09:52 AM, Rich Bowen wrote: >> >> On 06/17/2014 09:44 AM, Karanbir Singh wrote: >>> hi guys, >>> >>> Just wondering what the status of RDO on EL7 was, the quickstart still >>> only mentions 6.5 as being the supported ( tested ? ) version. >> >> I was planning to install EL7 today and go through the quickstart. I >> expect that someone else has already done this. (?) >> > > I mean CentOS 7, rather. > would be great if someone could run through an install and post ( blog ? ) feedback around rdo on the centos-7publicqa tree. Use the one at http://buildlogs.centos.org/centos/7/os/x86_64-latest/ -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From Lance.Fang at emc.com Wed Jun 18 17:23:20 2014 From: Lance.Fang at emc.com (Fang, Lance) Date: Wed, 18 Jun 2014 13:23:20 -0400 Subject: [Rdo-list] RDO Installation errors Message-ID: <95730731D64285418F19B9129C3BDC3D010E6C8EC762@MX40A.corp.emc.com> Guys, I have been following the direction from http://openstack.redhat.com/Quickstart without success in installing. I have uninstalled (Hammer) and installed with this error. Appreciate any help .. == Applying 10.110.80.64_keystone.pp Applying 10.110.80.64_glance.pp Applying 10.110.80.64_cinder.pp 10.110.80.64_keystone.pp: [ DONE ] 10.110.80.64_glance.pp: [ ERROR ] Applying Puppet manifests [ ERROR ] ERROR : Error appeared during Puppet run: 10.110.80.64_glance.pp Error: Execution of '/usr/bin/yum -d 0 -e 0 -y install openstack-glance' returned 1: Error unpacking rpm package python-crypto-2.6.1-1.el6.x86_64 You will find full trace in log /var/tmp/packstack/20140617-175724-dOGK9d/manifests/10.110.80.64_glance.pp.log Please check log file /var/tmp/packstack/20140617-175724-dOGK9d/openstack-setup.log for more information -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at redhat.com Wed Jun 18 18:36:00 2014 From: lars at redhat.com (Lars Kellogg-Stedman) Date: Wed, 18 Jun 2014 14:36:00 -0400 Subject: [Rdo-list] RDO Installation errors In-Reply-To: <95730731D64285418F19B9129C3BDC3D010E6C8EC762@MX40A.corp.emc.com> References: <95730731D64285418F19B9129C3BDC3D010E6C8EC762@MX40A.corp.emc.com> Message-ID: <20140618183600.GB22737@redhat.com> On Wed, Jun 18, 2014 at 01:23:20PM -0400, Fang, Lance wrote: > Error: Execution of '/usr/bin/yum -d 0 -e 0 -y install openstack-glance' returned 1: Error unpacking rpm package python-crypto-2.6.1-1.el6.x86_64 > You will find full trace in log /var/tmp/packstack/20140617-175724-dOGK9d/manifests/10.110.80.64_glance.pp.log > Please check log file /var/tmp/packstack/20140617-175724-dOGK9d/openstack-setup.log for more information Are you able to install that package manually on host 10.110.80.64 (by running "yum -y install openstack-glance")? -- Lars Kellogg-Stedman | larsks @ irc Cloud Engineering / OpenStack | " " @ twitter -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From Lance.Fang at emc.com Wed Jun 18 20:20:05 2014 From: Lance.Fang at emc.com (Fang, Lance) Date: Wed, 18 Jun 2014 16:20:05 -0400 Subject: [Rdo-list] RDO Installation errors In-Reply-To: <20140618183600.GB22737@redhat.com> References: <95730731D64285418F19B9129C3BDC3D010E6C8EC762@MX40A.corp.emc.com> <20140618183600.GB22737@redhat.com> Message-ID: <95730731D64285418F19B9129C3BDC3D010E6C8EC7DD@MX40A.corp.emc.com> Lar, Thanks for responding. Looks like it is installing ... Should I " packstack --allinone" again? -Lance === [root at sse-durl-ora3 howto]# yum -y install openstack-glance Loaded plugins: priorities, product-id, refresh-packagekit, security, subscription-manager This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register. epel/metalink | 6.8 kB 00:00 epel | 4.4 kB 00:00 epel/primary_db | 6.2 MB 00:06 foreman | 2.9 kB 00:00 foreman/primary_db | 68 kB 00:00 foreman-plugins | 2.9 kB 00:00 openstack-icehouse | 2.9 kB 00:00 public_ol6_UEK_latest | 1.2 kB 00:00 public_ol6_latest | 1.4 kB 00:00 puppetlabs-deps | 2.5 kB 00:00 puppetlabs-products | 2.5 kB 00:00 774 packages excluded due to repository priority protections Setting up Install Process Package openstack-glance-2014.1-2.el6.noarch already installed and latest version Nothing to do [root at sse-durl-ora3 howto]# -----Original Message----- From: Lars Kellogg-Stedman [mailto:lars at redhat.com] Sent: Wednesday, June 18, 2014 11:36 AM To: Fang, Lance Cc: rdo-list at redhat.com Subject: Re: [Rdo-list] RDO Installation errors On Wed, Jun 18, 2014 at 01:23:20PM -0400, Fang, Lance wrote: > Error: Execution of '/usr/bin/yum -d 0 -e 0 -y install > openstack-glance' returned 1: Error unpacking rpm package > python-crypto-2.6.1-1.el6.x86_64 You will find full trace in log > /var/tmp/packstack/20140617-175724-dOGK9d/manifests/10.110.80.64_glanc > e.pp.log Please check log file > /var/tmp/packstack/20140617-175724-dOGK9d/openstack-setup.log for more > information Are you able to install that package manually on host 10.110.80.64 (by running "yum -y install openstack-glance")? -- Lars Kellogg-Stedman | larsks @ irc Cloud Engineering / OpenStack | " " @ twitter From gareth at openstacker.org Thu Jun 19 06:15:49 2014 From: gareth at openstacker.org (Kun Huang) Date: Thu, 19 Jun 2014 14:15:49 +0800 Subject: [Rdo-list] [RDO] deployment details about neutron In-Reply-To: <53A0144C.4040000@redhat.com> References: <53A0144C.4040000@redhat.com> Message-ID: Thanks Ihar It is understandable to split neutron (API) server and L2 agent. But is it necessary to deploy nova-compute and L2 agent on same node? That reference doesn't explain the reason. On Tue, Jun 17, 2014 at 6:11 PM, Ihar Hrachyshka wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Quoting [1], "L2 agent should run on all machines except for the > Neutron service machine (unless Neutron service resides with other > component in the same machine)." That's what you observe. > > [1]: http://openstack.redhat.com/Neutron_with_OVS_and_VLANs > > On 17/06/14 10:23, Kun Huang wrote: >> I deployed a new cluster with above variables and l3 agent and >> dhcp agent exists on expected nodes. But ovs agent is running on >> each node. So the CONFIG_NEUTRON_OVS_HOST doesn't work. >> >> On Tue, Jun 17, 2014 at 2:40 PM, Kun Huang >> wrote: >>> hi all >>> >>> I have some questions about using RDO deploy neutron (based on >>> ovs). I need: >>> >>> node1: - neutron server >>> >>> node2 (all others): - dhcp agent - ovs agent - l3 agent >>> >>> Now in my understanding, CONFIG_NEUTRON_SERVER_HOST manages >>> neutron server, CONFIG_NEUTRON_DHCP_HOSTS manages dhcp agent, >>> CONFIG_NEUTRON_L3_HOSTS manages l3 agent, and >>> CONFIG_NEUTRON_OVS_HOST l2/ovs agent. Are those correct? >>> >>> Another question is after reading codes in neutron_350.py, I >>> found CONFIG_NEUTRON_L3_HOSTS may not work, because of [0]. It is >>> same about CONFIG_NEUTRON_OVS_HOST [1]. >>> >>> So are there some principles like "l2 agent must be installed on >>> same host with neutron server" >>> >>> [0] >>> https://github.com/stackforge/packstack/blob/master/packstack/plugins/neutron_350.py#L803-L804 >>> >>> > [1] > https://github.com/stackforge/packstack/blob/master/packstack/plugins/neutron_350.py#L913-L916 >> >> _______________________________________________ Rdo-list mailing >> list Rdo-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rdo-list >> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBCgAGBQJToBRMAAoJEC5aWaUY1u573KQH/3K6Rhu6PbzWfqWvxYje+7O6 > FzVeY7AvJDx41ddm6p2WaG1L49EPGBb9y450A4lgMNR8WIR57WD1x9aCJutMgOIm > fv0o4S5mxvcPG3MJ0ahcUNbdrmr5oQY3dnYJB/36uh4JXczE7utpDO5W6yxk1pnT > ywHXgr7Yy6jeYWj2JIkK6O8zTKNhs6brwQYSD+tatVMzLsI4yH3TbIBpVE6FAVsH > jH/988S42W8VKycE4CeoGGKeTXKY2xHphnnsLiL/ptGvQcP8rcOF4oNRZknql2Xf > zD0vEN48nqfji6bsTbQE480HtwziDFUcq1IDHnxuC87D1oTei/i9TudKQzhjCOg= > =l70v > -----END PGP SIGNATURE----- > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list From jonas.hagberg at scilifelab.se Thu Jun 19 06:23:01 2014 From: jonas.hagberg at scilifelab.se (Jonas Hagberg) Date: Thu, 19 Jun 2014 08:23:01 +0200 Subject: [Rdo-list] foreman-installer puppet problems: " Error 400 on SERVER: Must pass admin_password to Class[Quickstack::Nova]" In-Reply-To: <20140617151058.GA518@redhat.com> References: <20140617151058.GA518@redhat.com> Message-ID: Hej Now I have reported the bug https://bugzilla.redhat.com/show_bug.cgi?id=1110661 -- Jonas Hagberg BILS - Bioinformatics Infrastructure for Life Sciences - http://bils.se e-mail: jonas.hagberg at bils.se, jonas.hagberg at scilifelab.se phone: +46-(0)70 6683869 address: SciLifeLab, Box 1031, 171 21 Solna, Sweden On 17 June 2014 17:10, Lars Kellogg-Stedman wrote: > On Tue, Jun 17, 2014 at 12:38:03PM +0200, Jonas Hagberg wrote: > > But when assigning a node to a hostgroup (Neutron controller or neutron > > compute) and running puppet I get the following error. > > > > err: Could not retrieve catalog from remote server: Error 400 on SERVER: > > Must pass admin_password to Class[Quickstack::Nova] at > > > /usr/share/openstack-foreman-installer/puppet/modules/quickstack/manifests/nova.pp:65 > > on "fqdn" > > > > admin_password is set in hostgroup. > > If you haven't already you probably want to open a bug report on this > (https://bugzilla.redhat.com/enter_bug.cgi?product=RDO). > > -- > Lars Kellogg-Stedman | larsks @ irc > Cloud Engineering / OpenStack | " " @ twitter > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ihrachys at redhat.com Thu Jun 19 09:04:32 2014 From: ihrachys at redhat.com (Ihar Hrachyshka) Date: Thu, 19 Jun 2014 11:04:32 +0200 Subject: [Rdo-list] [RDO] deployment details about neutron In-Reply-To: References: <53A0144C.4040000@redhat.com> Message-ID: <53A2A7A0.20707@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 If you want any kind of network connectivity for your instances, you will need to have L2 agent deployed. For more info see [1] where L2 agent is referred to as 'Plug-in Agent'. [1]: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/3/html/Installation_and_Configuration_Guide/chap-Installing_the_OpenStack_Networking_Service.html#OpenStack_Networking_Agents On 19/06/14 08:15, Kun Huang wrote: > Thanks Ihar > > It is understandable to split neutron (API) server and L2 agent. > But is it necessary to deploy nova-compute and L2 agent on same > node? That reference doesn't explain the reason. > > On Tue, Jun 17, 2014 at 6:11 PM, Ihar Hrachyshka > wrote: Quoting [1], "L2 agent should run on > all machines except for the Neutron service machine (unless Neutron > service resides with other component in the same machine)." That's > what you observe. > > [1]: http://openstack.redhat.com/Neutron_with_OVS_and_VLANs > > On 17/06/14 10:23, Kun Huang wrote: >>>> I deployed a new cluster with above variables and l3 agent >>>> and dhcp agent exists on expected nodes. But ovs agent is >>>> running on each node. So the CONFIG_NEUTRON_OVS_HOST doesn't >>>> work. >>>> >>>> On Tue, Jun 17, 2014 at 2:40 PM, Kun Huang >>>> wrote: >>>>> hi all >>>>> >>>>> I have some questions about using RDO deploy neutron (based >>>>> on ovs). I need: >>>>> >>>>> node1: - neutron server >>>>> >>>>> node2 (all others): - dhcp agent - ovs agent - l3 agent >>>>> >>>>> Now in my understanding, CONFIG_NEUTRON_SERVER_HOST >>>>> manages neutron server, CONFIG_NEUTRON_DHCP_HOSTS manages >>>>> dhcp agent, CONFIG_NEUTRON_L3_HOSTS manages l3 agent, and >>>>> CONFIG_NEUTRON_OVS_HOST l2/ovs agent. Are those correct? >>>>> >>>>> Another question is after reading codes in neutron_350.py, >>>>> I found CONFIG_NEUTRON_L3_HOSTS may not work, because of >>>>> [0]. It is same about CONFIG_NEUTRON_OVS_HOST [1]. >>>>> >>>>> So are there some principles like "l2 agent must be >>>>> installed on same host with neutron server" >>>>> >>>>> [0] >>>>> https://github.com/stackforge/packstack/blob/master/packstack/plugins/neutron_350.py#L803-L804 >>>>> >>>>> > >>>>> [1] > https://github.com/stackforge/packstack/blob/master/packstack/plugins/neutron_350.py#L913-L916 >>>> >>>> > _______________________________________________ Rdo-list mailing >>>> list Rdo-list at redhat.com >>>> https://www.redhat.com/mailman/listinfo/rdo-list >>>> >> >> _______________________________________________ Rdo-list mailing >> list Rdo-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rdo-list -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJToqegAAoJEC5aWaUY1u571rMIANZtl09voEZ0zhgIQlkagOUo Bcsb2/czHuvHzySEAdE01TOqQl2rdLjv6R56uZO9FvQBTmwx+Hvp3RQa77H1i6NP l9meR2vhfDZwLDKUkM9AcUbKEjEX8h9Jlt3wswIrg5lIjjO8m03HlOwkgTY89kFE ktsg/5zUQ1df5rL8q+4rcz01EyOWvmTu31HbYoUIHiNLLhHVD3JGFjAyXqhFwFuK E2I/7Uqjxi32lUBOFKBAQ+eMDQruiGUKe19tehLveplsBw6f03JEIsK1MDXHTcCP TpnTfx82SXmsZnmMpUkBZXs2T2Zd3Auiu2otLV28KfiSESng8CP0TfniFJkfuwA= =J/sK -----END PGP SIGNATURE----- From ihrachys at redhat.com Thu Jun 19 10:04:14 2014 From: ihrachys at redhat.com (Ihar Hrachyshka) Date: Thu, 19 Jun 2014 12:04:14 +0200 Subject: [Rdo-list] RDO Installation errors In-Reply-To: <95730731D64285418F19B9129C3BDC3D010E6C8EC7DD@MX40A.corp.emc.com> References: <95730731D64285418F19B9129C3BDC3D010E6C8EC762@MX40A.corp.emc.com> <20140618183600.GB22737@redhat.com> <95730731D64285418F19B9129C3BDC3D010E6C8EC7DD@MX40A.corp.emc.com> Message-ID: <53A2B59E.30407@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 This can be some transient failure on RPM mirror side. You may try to rerun packstack again, this may help. /Ihar On 18/06/14 22:20, Fang, Lance wrote: > Lar, > > Thanks for responding. Looks like it is installing ... > > Should I " packstack --allinone" again? > > -Lance > > === > > > [root at sse-durl-ora3 howto]# yum -y install openstack-glance Loaded > plugins: priorities, product-id, refresh-packagekit, security, > subscription-manager This system is not registered to Red Hat > Subscription Management. You can use subscription-manager to > register. epel/metalink > | 6.8 kB 00:00 epel > | 4.4 kB 00:00 epel/primary_db > | 6.2 MB 00:06 foreman > | 2.9 kB 00:00 foreman/primary_db > | 68 kB 00:00 foreman-plugins > | 2.9 kB 00:00 openstack-icehouse > | 2.9 kB 00:00 public_ol6_UEK_latest > | 1.2 kB 00:00 public_ol6_latest > | 1.4 kB 00:00 puppetlabs-deps > | 2.5 kB 00:00 puppetlabs-products > | 2.5 kB 00:00 774 packages excluded due to repository priority > protections Setting up Install Process Package > openstack-glance-2014.1-2.el6.noarch already installed and latest > version Nothing to do [root at sse-durl-ora3 howto]# > > -----Original Message----- From: Lars Kellogg-Stedman > [mailto:lars at redhat.com] Sent: Wednesday, June 18, 2014 11:36 AM > To: Fang, Lance Cc: rdo-list at redhat.com Subject: Re: [Rdo-list] RDO > Installation errors > > On Wed, Jun 18, 2014 at 01:23:20PM -0400, Fang, Lance wrote: >> Error: Execution of '/usr/bin/yum -d 0 -e 0 -y install >> openstack-glance' returned 1: Error unpacking rpm package >> python-crypto-2.6.1-1.el6.x86_64 You will find full trace in log >> >> /var/tmp/packstack/20140617-175724-dOGK9d/manifests/10.110.80.64_glanc >> >> e.pp.log Please check log file >> /var/tmp/packstack/20140617-175724-dOGK9d/openstack-setup.log for >> more information > > Are you able to install that package manually on host 10.110.80.64 > (by running "yum -y install openstack-glance")? > > -- Lars Kellogg-Stedman | larsks @ irc Cloud > Engineering / OpenStack | " " @ twitter > > > _______________________________________________ Rdo-list mailing > list Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTorWeAAoJEC5aWaUY1u57c1AH/1oLEFsz7AyAS7km/gSQ5kMq lziU/hyicfMG7lHA+FveR7AOab8IUpZIykIlTWYpCKK37rB59jBN7xbaLhVjwywl r/Q+MyG/lGOnRGcTQ4pKHC3u9GRovhk5HE18Lp+fmZsVzP7Zm5WLGiIQwu68nJ9+ xWuod5o//h0ELL6MyjomnYbkag68eL4qNid0i0GTYI0ZX0/ARn9mgpY6YlhKj0h5 oJYguwsDUKM67cjKguII5MyXMb3PgkIGqJ2OZYBxYUWaKTVmqdA11H8u9pNYSTB1 AAVRdlfMI9pSem9kGYYZYU3X5bEGSZ7NaiV3+5wqAf94jpQIUrxzcJ98cPazASI= =otiD -----END PGP SIGNATURE----- From whayutin at redhat.com Thu Jun 19 17:43:55 2014 From: whayutin at redhat.com (whayutin) Date: Thu, 19 Jun 2014 13:43:55 -0400 Subject: [Rdo-list] FYI.. CentOS6.5 ( do not install ) Message-ID: <1403199835.3142.17.camel@localhost.localdomain> An update to RDO was recently pushed that prevents mysql restarting on CentOS 6.5. An update with the fix is in the works, until then please use RHEL or Fedora. Thank you! From akalambu at cisco.com Thu Jun 19 18:19:40 2014 From: akalambu at cisco.com (Ajay Kalambur (akalambu)) Date: Thu, 19 Jun 2014 18:19:40 +0000 Subject: [Rdo-list] Foreman web page error In-Reply-To: References: Message-ID: Hi I installed foreman on RHEL 6.5 and ran the foreman_server.sh and set the FOREMAN_GATEWAY and PROVISIONING=true When i launch the web page at https://foremaninstall i see the error below. Any idea what maybe the issue? Web application could not be started Validation failed: Value must be a valid URI (ActiveRecord::RecordInvalid) /opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/validations.rb:56:in `save!' /opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/attribute_methods/dirty.rb:33:in `save!' /opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/transactions.rb:246:in `block in save!' /opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/transactions.rb:295:in `block in with_transaction_returning_status' /opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/connection_adapters/abstract/database_statements.rb:192:in `transaction' /opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/transactions.rb:208:in `transaction' /opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/transactions.rb:293:in `with_transaction_returning_status' /opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/transactions.rb:246:in `save!' /opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/validations.rb:41:in `create!' /usr/share/foreman/app/models/setting.rb:162:in `create!' /usr/share/foreman/app/models/setting/general.rb:25:in `block (2 levels) in load_defaults' /usr/share/foreman/app/models/setting/general.rb:15:in `each' /usr/share/foreman/app/models/setting/general.rb:15:in `block in load_defaults' /opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/connection_adapters/abstract/database_statements.rb:192:in `transaction' /opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/transactions.rb:208:in `transaction' /usr/share/foreman/app/models/setting/general.rb:13:in `load_defaults' /usr/share/foreman/config/initializers/foreman.rb:18:in `each' /usr/share/foreman/config/initializers/foreman.rb:18:in `' /opt/rh/ruby193/root/usr/share/gems/gems/activesupport-3.2.8/lib/active_support/dependencies.rb:245:in `load' /opt/rh/ruby193/root/usr/share/gems/gems/activesupport-3.2.8/lib/active_support/dependencies.rb:245:in `block in load' /opt/rh/ruby193/root/usr/share/gems/gems/activesupport-3.2.8/lib/active_support/dependencies.rb:236:in `load_dependency' /opt/rh/ruby193/root/usr/share/gems/gems/activesupport-3.2.8/lib/active_support/dependencies.rb:245:in `load' /opt/rh/ruby193/root/usr/share/gems/gems/railties-3.2.8/lib/rails/engine.rb:588:in `block (2 levels) in ' /opt/rh/ruby193/root/usr/share/gems/gems/railties-3.2.8/lib/rails/engine.rb:587:in `each' /opt/rh/ruby193/root/usr/share/gems/gems/railties-3.2.8/lib/rails/engine.rb:587:in `block in ' /opt/rh/ruby193/root/usr/share/gems/gems/railties-3.2.8/lib/rails/initializable.rb:30:in `instance_exec' /opt/rh/ruby193/root/usr/share/gems/gems/railties-3.2.8/lib/rails/initializable.rb:30:in `run' /opt/rh/ruby193/root/usr/share/gems/gems/railties-3.2.8/lib/rails/initializable.rb:55:in `block in run_initializers' /opt/rh/ruby193/root/usr/share/gems/gems/railties-3.2.8/lib/rails/initializable.rb:54:in `each' /opt/rh/ruby193/root/usr/share/gems/gems/railties-3.2.8/lib/rails/initializable.rb:54:in `run_initializers' /opt/rh/ruby193/root/usr/share/gems/gems/railties-3.2.8/lib/rails/application.rb:136:in `initialize!' /opt/rh/ruby193/root/usr/share/gems/gems/railties-3.2.8/lib/rails/railtie/configurable.rb:30:in `method_missing' /usr/share/foreman/config/environment.rb:5:in `' /opt/rh/ruby193/root/usr/share/rubygems/rubygems/custom_require.rb:36:in `require' /opt/rh/ruby193/root/usr/share/rubygems/rubygems/custom_require.rb:36:in `require' config.ru:3:in `block in
' /opt/rh/ruby193/root/usr/share/gems/gems/rack-1.4.1/lib/rack/builder.rb:51:in `instance_eval' /opt/rh/ruby193/root/usr/share/gems/gems/rack-1.4.1/lib/rack/builder.rb:51:in `initialize' config.ru:1:in `new' config.ru:1:in `
' /usr/lib/ruby/gems/1.8/gems/passenger-4.0.18/helper-scripts/rack-preloader.rb:105:in `eval' /usr/lib/ruby/gems/1.8/gems/passenger-4.0.18/helper-scripts/rack-preloader.rb:105:in `preload_app' /usr/lib/ruby/gems/1.8/gems/passenger-4.0.18/helper-scripts/rack-preloader.rb:150:in `' /usr/lib/ruby/gems/1.8/gems/passenger-4.0.18/helper-scripts/rack-preloader.rb:29:in `' /usr/lib/ruby/gems/1.8/gems/passenger-4.0.18/helper-scripts/rack-preloader.rb:28:in `
' -------------- next part -------------- An HTML attachment was scrubbed... URL: From Lance.Fang at emc.com Thu Jun 19 22:41:37 2014 From: Lance.Fang at emc.com (Fang, Lance) Date: Thu, 19 Jun 2014 18:41:37 -0400 Subject: [Rdo-list] RDO Installation errors In-Reply-To: <53A2B59E.30407@redhat.com> References: <95730731D64285418F19B9129C3BDC3D010E6C8EC762@MX40A.corp.emc.com> <20140618183600.GB22737@redhat.com> <95730731D64285418F19B9129C3BDC3D010E6C8EC7DD@MX40A.corp.emc.com> <53A2B59E.30407@redhat.com> Message-ID: <95730731D64285418F19B9129C3BDC3D010E6C8ECA07@MX40A.corp.emc.com> All, Any thoughts on this? Here is what I did: sudo yum update -y --skip-broken sudo yum install -y http://rdo.fedorapeople.org/rdo-release.rpm sudo yum install -y openstack-packstack sudo packstack --allinone During "packstack", errors of openstack-glance and python-crypto-2.6.1-1.el6.x86_64 won't go away. When manually trying to yum "openstack-glance", it said it is already installed. I can manually yum install the python-crypto-2.6.1-1.el6.x86_64, but when rerun packstack, it hits some other errors. Any help is appreciated. === 10.110.80.64_glance.pp: [ ERROR ] Applying Puppet manifests [ ERROR ] ERROR : Error appeared during Puppet run: 10.110.80.64_glance.pp Error: Execution of '/usr/bin/yum -d 0 -e 0 -y install openstack-glance' returned 1: Error unpacking rpm package python-crypto-2.6.1-1.el6.x86_64 You will find full trace in log /var/tmp/packstack/20140619-172319-P3OAYN/manifests/10.110.80.64_glance.pp.log Please check log file /var/tmp/packstack/20140619-172319-P3OAYN/openstack-setup.log for more information -----Original Message----- From: rdo-list-bounces at redhat.com [mailto:rdo-list-bounces at redhat.com] On Behalf Of Ihar Hrachyshka Sent: Thursday, June 19, 2014 3:04 AM To: rdo-list at redhat.com Subject: Re: [Rdo-list] RDO Installation errors -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 This can be some transient failure on RPM mirror side. You may try to rerun packstack again, this may help. /Ihar On 18/06/14 22:20, Fang, Lance wrote: > Lar, > > Thanks for responding. Looks like it is installing ... > > Should I " packstack --allinone" again? > > -Lance > > === > > > [root at sse-durl-ora3 howto]# yum -y install openstack-glance Loaded > plugins: priorities, product-id, refresh-packagekit, security, > subscription-manager This system is not registered to Red Hat > Subscription Management. You can use subscription-manager to register. > epel/metalink > | 6.8 kB 00:00 epel > | 4.4 kB 00:00 epel/primary_db > | 6.2 MB 00:06 foreman > | 2.9 kB 00:00 foreman/primary_db > | 68 kB 00:00 foreman-plugins > | 2.9 kB 00:00 openstack-icehouse > | 2.9 kB 00:00 public_ol6_UEK_latest > | 1.2 kB 00:00 public_ol6_latest > | 1.4 kB 00:00 puppetlabs-deps > | 2.5 kB 00:00 puppetlabs-products > | 2.5 kB 00:00 774 packages excluded due to repository priority > protections Setting up Install Process Package > openstack-glance-2014.1-2.el6.noarch already installed and latest > version Nothing to do [root at sse-durl-ora3 howto]# > > -----Original Message----- From: Lars Kellogg-Stedman > [mailto:lars at redhat.com] Sent: Wednesday, June 18, 2014 11:36 AM > To: Fang, Lance Cc: rdo-list at redhat.com Subject: Re: [Rdo-list] RDO > Installation errors > > On Wed, Jun 18, 2014 at 01:23:20PM -0400, Fang, Lance wrote: >> Error: Execution of '/usr/bin/yum -d 0 -e 0 -y install >> openstack-glance' returned 1: Error unpacking rpm package >> python-crypto-2.6.1-1.el6.x86_64 You will find full trace in log >> >> /var/tmp/packstack/20140617-175724-dOGK9d/manifests/10.110.80.64_glan >> c >> >> e.pp.log Please check log file >> /var/tmp/packstack/20140617-175724-dOGK9d/openstack-setup.log for >> more information > > Are you able to install that package manually on host 10.110.80.64 (by > running "yum -y install openstack-glance")? > > -- Lars Kellogg-Stedman | larsks @ irc Cloud > Engineering / OpenStack | " " @ twitter > > > _______________________________________________ Rdo-list mailing list > Rdo-list at redhat.com https://www.redhat.com/mailman/listinfo/rdo-list > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTorWeAAoJEC5aWaUY1u57c1AH/1oLEFsz7AyAS7km/gSQ5kMq lziU/hyicfMG7lHA+FveR7AOab8IUpZIykIlTWYpCKK37rB59jBN7xbaLhVjwywl r/Q+MyG/lGOnRGcTQ4pKHC3u9GRovhk5HE18Lp+fmZsVzP7Zm5WLGiIQwu68nJ9+ xWuod5o//h0ELL6MyjomnYbkag68eL4qNid0i0GTYI0ZX0/ARn9mgpY6YlhKj0h5 oJYguwsDUKM67cjKguII5MyXMb3PgkIGqJ2OZYBxYUWaKTVmqdA11H8u9pNYSTB1 AAVRdlfMI9pSem9kGYYZYU3X5bEGSZ7NaiV3+5wqAf94jpQIUrxzcJ98cPazASI= =otiD -----END PGP SIGNATURE----- _______________________________________________ Rdo-list mailing list Rdo-list at redhat.com https://www.redhat.com/mailman/listinfo/rdo-list From Wilson.Ojwang at alcatel-lucent.com Fri Jun 20 03:07:54 2014 From: Wilson.Ojwang at alcatel-lucent.com (Ojwang, Wilson O (Wilson)) Date: Fri, 20 Jun 2014 03:07:54 +0000 Subject: [Rdo-list] RDO Installation errors In-Reply-To: <95730731D64285418F19B9129C3BDC3D010E6C8ECA07@MX40A.corp.emc.com> References: <95730731D64285418F19B9129C3BDC3D010E6C8EC762@MX40A.corp.emc.com> <20140618183600.GB22737@redhat.com> <95730731D64285418F19B9129C3BDC3D010E6C8EC7DD@MX40A.corp.emc.com> <53A2B59E.30407@redhat.com> <95730731D64285418F19B9129C3BDC3D010E6C8ECA07@MX40A.corp.emc.com> Message-ID: <48D3E8917D735E4F8B8639EC3693D5B898C56BD9@US70UWXCHMBA01.zam.alcatel-lucent.com> Are you behind a firewall? If so, add your proxy server URL (proxy=http://(your proxy server) in /etc/yum.conf file. -----Original Message----- From: rdo-list-bounces at redhat.com [mailto:rdo-list-bounces at redhat.com] On Behalf Of Fang, Lance Sent: Thursday, June 19, 2014 5:42 PM To: Ihar Hrachyshka; rdo-list at redhat.com Subject: Re: [Rdo-list] RDO Installation errors All, Any thoughts on this? Here is what I did: sudo yum update -y --skip-broken sudo yum install -y http://rdo.fedorapeople.org/rdo-release.rpm sudo yum install -y openstack-packstack sudo packstack --allinone During "packstack", errors of openstack-glance and python-crypto-2.6.1-1.el6.x86_64 won't go away. When manually trying to yum "openstack-glance", it said it is already installed. I can manually yum install the python-crypto-2.6.1-1.el6.x86_64, but when rerun packstack, it hits some other errors. Any help is appreciated. === 10.110.80.64_glance.pp: [ ERROR ] Applying Puppet manifests [ ERROR ] ERROR : Error appeared during Puppet run: 10.110.80.64_glance.pp Error: Execution of '/usr/bin/yum -d 0 -e 0 -y install openstack-glance' returned 1: Error unpacking rpm package python-crypto-2.6.1-1.el6.x86_64 You will find full trace in log /var/tmp/packstack/20140619-172319-P3OAYN/manifests/10.110.80.64_glance.pp.log Please check log file /var/tmp/packstack/20140619-172319-P3OAYN/openstack-setup.log for more information -----Original Message----- From: rdo-list-bounces at redhat.com [mailto:rdo-list-bounces at redhat.com] On Behalf Of Ihar Hrachyshka Sent: Thursday, June 19, 2014 3:04 AM To: rdo-list at redhat.com Subject: Re: [Rdo-list] RDO Installation errors -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 This can be some transient failure on RPM mirror side. You may try to rerun packstack again, this may help. /Ihar On 18/06/14 22:20, Fang, Lance wrote: > Lar, > > Thanks for responding. Looks like it is installing ... > > Should I " packstack --allinone" again? > > -Lance > > === > > > [root at sse-durl-ora3 howto]# yum -y install openstack-glance Loaded > plugins: priorities, product-id, refresh-packagekit, security, > subscription-manager This system is not registered to Red Hat > Subscription Management. You can use subscription-manager to register. > epel/metalink > | 6.8 kB 00:00 epel > | 4.4 kB 00:00 epel/primary_db > | 6.2 MB 00:06 foreman > | 2.9 kB 00:00 foreman/primary_db > | 68 kB 00:00 foreman-plugins > | 2.9 kB 00:00 openstack-icehouse > | 2.9 kB 00:00 public_ol6_UEK_latest > | 1.2 kB 00:00 public_ol6_latest > | 1.4 kB 00:00 puppetlabs-deps > | 2.5 kB 00:00 puppetlabs-products > | 2.5 kB 00:00 774 packages excluded due to repository priority > protections Setting up Install Process Package > openstack-glance-2014.1-2.el6.noarch already installed and latest > version Nothing to do [root at sse-durl-ora3 howto]# > > -----Original Message----- From: Lars Kellogg-Stedman > [mailto:lars at redhat.com] Sent: Wednesday, June 18, 2014 11:36 AM > To: Fang, Lance Cc: rdo-list at redhat.com Subject: Re: [Rdo-list] RDO > Installation errors > > On Wed, Jun 18, 2014 at 01:23:20PM -0400, Fang, Lance wrote: >> Error: Execution of '/usr/bin/yum -d 0 -e 0 -y install >> openstack-glance' returned 1: Error unpacking rpm package >> python-crypto-2.6.1-1.el6.x86_64 You will find full trace in log >> >> /var/tmp/packstack/20140617-175724-dOGK9d/manifests/10.110.80.64_glan >> c >> >> e.pp.log Please check log file >> /var/tmp/packstack/20140617-175724-dOGK9d/openstack-setup.log for >> more information > > Are you able to install that package manually on host 10.110.80.64 (by > running "yum -y install openstack-glance")? > > -- Lars Kellogg-Stedman | larsks @ irc Cloud > Engineering / OpenStack | " " @ twitter > > > _______________________________________________ Rdo-list mailing list > Rdo-list at redhat.com https://www.redhat.com/mailman/listinfo/rdo-list > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTorWeAAoJEC5aWaUY1u57c1AH/1oLEFsz7AyAS7km/gSQ5kMq lziU/hyicfMG7lHA+FveR7AOab8IUpZIykIlTWYpCKK37rB59jBN7xbaLhVjwywl r/Q+MyG/lGOnRGcTQ4pKHC3u9GRovhk5HE18Lp+fmZsVzP7Zm5WLGiIQwu68nJ9+ xWuod5o//h0ELL6MyjomnYbkag68eL4qNid0i0GTYI0ZX0/ARn9mgpY6YlhKj0h5 oJYguwsDUKM67cjKguII5MyXMb3PgkIGqJ2OZYBxYUWaKTVmqdA11H8u9pNYSTB1 AAVRdlfMI9pSem9kGYYZYU3X5bEGSZ7NaiV3+5wqAf94jpQIUrxzcJ98cPazASI= =otiD -----END PGP SIGNATURE----- _______________________________________________ Rdo-list mailing list Rdo-list at redhat.com https://www.redhat.com/mailman/listinfo/rdo-list _______________________________________________ Rdo-list mailing list Rdo-list at redhat.com https://www.redhat.com/mailman/listinfo/rdo-list From mhulan at redhat.com Fri Jun 20 08:16:21 2014 From: mhulan at redhat.com (Marek Hulan) Date: Fri, 20 Jun 2014 10:16:21 +0200 Subject: [Rdo-list] Centos 6.5 Staypuft OpenStack Foreman Installer Ruby Error In-Reply-To: <312001956.36005.1403072641357.JavaMail.zimbra@vidalinux.net> References: <312001956.36005.1403072641357.JavaMail.zimbra@vidalinux.net> Message-ID: <16518561.muF02uQNW2@edna> On Wednesday 18 of June 2014 02:24:01 Antonio C. Velez wrote: > Hi All, > > I'm testing the staypuft project in centos 6.5 x86_64 everything is working > correctly using an older version: > foreman-installer-staypuft-0.0.12-1.el6.noarch.rpm, but if I try with a > newer version got the following error: > > # staypuft-installer > /opt/rh/ruby193/root/usr/share/rubygems/rubygems/custom_require.rb:36:in > `require': cannot load such file -- highline/import (LoadError) from > /opt/rh/ruby193/root/usr/share/rubygems/rubygems/custom_require.rb:36:in > `require' from /usr/sbin/staypuft-installer:3:in `
' > > Someone you know what I'm missing? > > Thanks! Hello, just for the records, this was fixed in foreman-installer-staypuft v 0.0.20. As a workaround you should be able to fix shebang of staypuft-installer script to "/usr/bin/env ruby" so it does not try to use SCL ruby. -- Marek From mail-lists at karan.org Fri Jun 20 08:30:04 2014 From: mail-lists at karan.org (Karanbir Singh) Date: Fri, 20 Jun 2014 09:30:04 +0100 Subject: [Rdo-list] FYI.. CentOS6.5 ( do not install ) In-Reply-To: <1403199835.3142.17.camel@localhost.localdomain> References: <1403199835.3142.17.camel@localhost.localdomain> Message-ID: <53A3F10C.2010402@karan.org> On 06/19/2014 06:43 PM, whayutin wrote: > An update to RDO was recently pushed that prevents mysql restarting on > CentOS 6.5. An update with the fix is in the works, until then please > use RHEL or Fedora. keen to know what this problem is that impacts CentOS but not RHEL. Where should I look for details ? -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc From pbrady at redhat.com Fri Jun 20 09:04:21 2014 From: pbrady at redhat.com (=?ISO-8859-1?Q?P=E1draig_Brady?=) Date: Fri, 20 Jun 2014 10:04:21 +0100 Subject: [Rdo-list] FYI.. CentOS6.5 ( do not install ) In-Reply-To: <53A3F10C.2010402@karan.org> References: <1403199835.3142.17.camel@localhost.localdomain> <53A3F10C.2010402@karan.org> Message-ID: <53A3F915.8050108@redhat.com> On 06/20/2014 09:30 AM, Karanbir Singh wrote: > On 06/19/2014 06:43 PM, whayutin wrote: >> An update to RDO was recently pushed that prevents mysql restarting on >> CentOS 6.5. An update with the fix is in the works, until then please >> use RHEL or Fedora. > > keen to know what this problem is that impacts CentOS but not RHEL. > Where should I look for details ? Karanbir I've heard that packstack/puppet/templates/mysql_install.pp needs change from 'Centos' to 'CentOS'. Without having looked it would seem we should be keying on $::osfamily == 'redhat' here rather than a specific $::operatingsystem Anyway it's being fixed up as we speak. thanks, P?draig. From akalambu at cisco.com Fri Jun 20 17:27:11 2014 From: akalambu at cisco.com (Ajay Kalambur (akalambu)) Date: Fri, 20 Jun 2014 17:27:11 +0000 Subject: [Rdo-list] Foreman web page error In-Reply-To: References: Message-ID: Hi Any comments/help on this? Ajay From: AJAY KALAMBUR > Date: Thursday, June 19, 2014 at 11:19 To: "rdo-list at redhat.com" > Subject: Foreman web page error Hi I installed foreman on RHEL 6.5 and ran the foreman_server.sh and set the FOREMAN_GATEWAY and PROVISIONING=true When i launch the web page at https://foremaninstall i see the error below. Any idea what maybe the issue? Web application could not be started Validation failed: Value must be a valid URI (ActiveRecord::RecordInvalid) /opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/validations.rb:56:in `save!' /opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/attribute_methods/dirty.rb:33:in `save!' /opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/transactions.rb:246:in `block in save!' /opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/transactions.rb:295:in `block in with_transaction_returning_status' /opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/connection_adapters/abstract/database_statements.rb:192:in `transaction' /opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/transactions.rb:208:in `transaction' /opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/transactions.rb:293:in `with_transaction_returning_status' /opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/transactions.rb:246:in `save!' /opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/validations.rb:41:in `create!' /usr/share/foreman/app/models/setting.rb:162:in `create!' /usr/share/foreman/app/models/setting/general.rb:25:in `block (2 levels) in load_defaults' /usr/share/foreman/app/models/setting/general.rb:15:in `each' /usr/share/foreman/app/models/setting/general.rb:15:in `block in load_defaults' /opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/connection_adapters/abstract/database_statements.rb:192:in `transaction' /opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/transactions.rb:208:in `transaction' /usr/share/foreman/app/models/setting/general.rb:13:in `load_defaults' /usr/share/foreman/config/initializers/foreman.rb:18:in `each' /usr/share/foreman/config/initializers/foreman.rb:18:in `' /opt/rh/ruby193/root/usr/share/gems/gems/activesupport-3.2.8/lib/active_support/dependencies.rb:245:in `load' /opt/rh/ruby193/root/usr/share/gems/gems/activesupport-3.2.8/lib/active_support/dependencies.rb:245:in `block in load' /opt/rh/ruby193/root/usr/share/gems/gems/activesupport-3.2.8/lib/active_support/dependencies.rb:236:in `load_dependency' /opt/rh/ruby193/root/usr/share/gems/gems/activesupport-3.2.8/lib/active_support/dependencies.rb:245:in `load' /opt/rh/ruby193/root/usr/share/gems/gems/railties-3.2.8/lib/rails/engine.rb:588:in `block (2 levels) in ' /opt/rh/ruby193/root/usr/share/gems/gems/railties-3.2.8/lib/rails/engine.rb:587:in `each' /opt/rh/ruby193/root/usr/share/gems/gems/railties-3.2.8/lib/rails/engine.rb:587:in `block in ' /opt/rh/ruby193/root/usr/share/gems/gems/railties-3.2.8/lib/rails/initializable.rb:30:in `instance_exec' /opt/rh/ruby193/root/usr/share/gems/gems/railties-3.2.8/lib/rails/initializable.rb:30:in `run' /opt/rh/ruby193/root/usr/share/gems/gems/railties-3.2.8/lib/rails/initializable.rb:55:in `block in run_initializers' /opt/rh/ruby193/root/usr/share/gems/gems/railties-3.2.8/lib/rails/initializable.rb:54:in `each' /opt/rh/ruby193/root/usr/share/gems/gems/railties-3.2.8/lib/rails/initializable.rb:54:in `run_initializers' /opt/rh/ruby193/root/usr/share/gems/gems/railties-3.2.8/lib/rails/application.rb:136:in `initialize!' /opt/rh/ruby193/root/usr/share/gems/gems/railties-3.2.8/lib/rails/railtie/configurable.rb:30:in `method_missing' /usr/share/foreman/config/environment.rb:5:in `' /opt/rh/ruby193/root/usr/share/rubygems/rubygems/custom_require.rb:36:in `require' /opt/rh/ruby193/root/usr/share/rubygems/rubygems/custom_require.rb:36:in `require' config.ru:3:in `block in
' /opt/rh/ruby193/root/usr/share/gems/gems/rack-1.4.1/lib/rack/builder.rb:51:in `instance_eval' /opt/rh/ruby193/root/usr/share/gems/gems/rack-1.4.1/lib/rack/builder.rb:51:in `initialize' config.ru:1:in `new' config.ru:1:in `
' /usr/lib/ruby/gems/1.8/gems/passenger-4.0.18/helper-scripts/rack-preloader.rb:105:in `eval' /usr/lib/ruby/gems/1.8/gems/passenger-4.0.18/helper-scripts/rack-preloader.rb:105:in `preload_app' /usr/lib/ruby/gems/1.8/gems/passenger-4.0.18/helper-scripts/rack-preloader.rb:150:in `' /usr/lib/ruby/gems/1.8/gems/passenger-4.0.18/helper-scripts/rack-preloader.rb:29:in `' /usr/lib/ruby/gems/1.8/gems/passenger-4.0.18/helper-scripts/rack-preloader.rb:28:in `
' -------------- next part -------------- An HTML attachment was scrubbed... URL: From morazi at redhat.com Fri Jun 20 20:15:39 2014 From: morazi at redhat.com (Mike Orazi) Date: Fri, 20 Jun 2014 16:15:39 -0400 Subject: [Rdo-list] Foreman web page error In-Reply-To: References: Message-ID: <53A4966B.2070706@redhat.com> What is the value you have set for FOREMAN_GATEWAY? It should be an IP address, probably of the router on the network that you are expecting foreman to be able to provision into. - Mike On 06/20/2014 01:27 PM, Ajay Kalambur (akalambu) wrote: > Hi > Any comments/help on this? > Ajay > > > From: AJAY KALAMBUR > > Date: Thursday, June 19, 2014 at 11:19 > To: "rdo-list at redhat.com " > > > Subject: Foreman web page error > > Hi > I installed foreman on RHEL 6.5 and ran the foreman_server.sh and set > the FOREMAN_GATEWAY and PROVISIONING=true > When i launch the web page at https://foremaninstall i see the error > below. Any idea what maybe the issue? > > > *Web application could not be started* > > *Validation failed: Value must be a valid URI (ActiveRecord::RecordInvalid)* > > /opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/validations.rb:56:in > `save!' > > /opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/attribute_methods/dirty.rb:33:in > `save!' > > /opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/transactions.rb:246:in > `block in save!' > > /opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/transactions.rb:295:in > `block in with_transaction_returning_status' > > /opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/connection_adapters/abstract/database_statements.rb:192:in > `transaction' > > /opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/transactions.rb:208:in > `transaction' > > /opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/transactions.rb:293:in > `with_transaction_returning_status' > > /opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/transactions.rb:246:in > `save!' > > /opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/validations.rb:41:in > `create!' > /usr/share/foreman/app/models/setting.rb:162:in `create!' > /usr/share/foreman/app/models/setting/general.rb:25:in `block (2 > levels) in load_defaults' > /usr/share/foreman/app/models/setting/general.rb:15:in `each' > /usr/share/foreman/app/models/setting/general.rb:15:in `block in > load_defaults' > > /opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/connection_adapters/abstract/database_statements.rb:192:in > `transaction' > > /opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_record/transactions.rb:208:in > `transaction' > /usr/share/foreman/app/models/setting/general.rb:13:in `load_defaults' > /usr/share/foreman/config/initializers/foreman.rb:18:in `each' > /usr/share/foreman/config/initializers/foreman.rb:18:in `' > > /opt/rh/ruby193/root/usr/share/gems/gems/activesupport-3.2.8/lib/active_support/dependencies.rb:245:in > `load' > > /opt/rh/ruby193/root/usr/share/gems/gems/activesupport-3.2.8/lib/active_support/dependencies.rb:245:in > `block in load' > > /opt/rh/ruby193/root/usr/share/gems/gems/activesupport-3.2.8/lib/active_support/dependencies.rb:236:in > `load_dependency' > > /opt/rh/ruby193/root/usr/share/gems/gems/activesupport-3.2.8/lib/active_support/dependencies.rb:245:in > `load' > > /opt/rh/ruby193/root/usr/share/gems/gems/railties-3.2.8/lib/rails/engine.rb:588:in > `block (2 levels) in ' > > /opt/rh/ruby193/root/usr/share/gems/gems/railties-3.2.8/lib/rails/engine.rb:587:in > `each' > > /opt/rh/ruby193/root/usr/share/gems/gems/railties-3.2.8/lib/rails/engine.rb:587:in > `block in ' > > /opt/rh/ruby193/root/usr/share/gems/gems/railties-3.2.8/lib/rails/initializable.rb:30:in > `instance_exec' > > /opt/rh/ruby193/root/usr/share/gems/gems/railties-3.2.8/lib/rails/initializable.rb:30:in > `run' > > /opt/rh/ruby193/root/usr/share/gems/gems/railties-3.2.8/lib/rails/initializable.rb:55:in > `block in run_initializers' > > /opt/rh/ruby193/root/usr/share/gems/gems/railties-3.2.8/lib/rails/initializable.rb:54:in > `each' > > /opt/rh/ruby193/root/usr/share/gems/gems/railties-3.2.8/lib/rails/initializable.rb:54:in > `run_initializers' > > /opt/rh/ruby193/root/usr/share/gems/gems/railties-3.2.8/lib/rails/application.rb:136:in > `initialize!' > > /opt/rh/ruby193/root/usr/share/gems/gems/railties-3.2.8/lib/rails/railtie/configurable.rb:30:in > `method_missing' > /usr/share/foreman/config/environment.rb:5:in `' > > /opt/rh/ruby193/root/usr/share/rubygems/rubygems/custom_require.rb:36:in > `require' > > /opt/rh/ruby193/root/usr/share/rubygems/rubygems/custom_require.rb:36:in > `require' > config.ru:3:in `block in
' > > /opt/rh/ruby193/root/usr/share/gems/gems/rack-1.4.1/lib/rack/builder.rb:51:in > `instance_eval' > > /opt/rh/ruby193/root/usr/share/gems/gems/rack-1.4.1/lib/rack/builder.rb:51:in > `initialize' > config.ru:1:in `new' > config.ru:1:in `
' > > /usr/lib/ruby/gems/1.8/gems/passenger-4.0.18/helper-scripts/rack-preloader.rb:105:in > `eval' > > /usr/lib/ruby/gems/1.8/gems/passenger-4.0.18/helper-scripts/rack-preloader.rb:105:in > `preload_app' > > /usr/lib/ruby/gems/1.8/gems/passenger-4.0.18/helper-scripts/rack-preloader.rb:150:in > `' > > /usr/lib/ruby/gems/1.8/gems/passenger-4.0.18/helper-scripts/rack-preloader.rb:29:in > `' > > /usr/lib/ruby/gems/1.8/gems/passenger-4.0.18/helper-scripts/rack-preloader.rb:28:in > `
' > > > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > From akalambu at cisco.com Fri Jun 20 21:53:02 2014 From: akalambu at cisco.com (Ajay Kalambur (akalambu)) Date: Fri, 20 Jun 2014 21:53:02 +0000 Subject: [Rdo-list] Foreman web page error In-Reply-To: <53A4966B.2070706@redhat.com> References: <53A4966B.2070706@redhat.com> Message-ID: I am doing this with VMs. So its set to the ip address of the Linux bridge with external network connection Ajay On 6/20/14, 13:15, "Mike Orazi" wrote: >What is the value you have set for FOREMAN_GATEWAY? > >It should be an IP address, probably of the router on the network that >you are expecting foreman to be able to provision into. > >- Mike > >On 06/20/2014 01:27 PM, Ajay Kalambur (akalambu) wrote: >> Hi >> Any comments/help on this? >> Ajay >> >> >> From: AJAY KALAMBUR > >> Date: Thursday, June 19, 2014 at 11:19 >> To: "rdo-list at redhat.com " >> > >> Subject: Foreman web page error >> >> Hi >> I installed foreman on RHEL 6.5 and ran the foreman_server.sh and set >> the FOREMAN_GATEWAY and PROVISIONING=true >> When i launch the web page at https://foremaninstall i see the error >> below. Any idea what maybe the issue? >> >> >> *Web application could not be started* >> >> *Validation failed: Value must be a valid URI >>(ActiveRecord::RecordInvalid)* >> >> >>/opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_re >>cord/validations.rb:56:in >> `save!' >> >> >>/opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_re >>cord/attribute_methods/dirty.rb:33:in >> `save!' >> >> >>/opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_re >>cord/transactions.rb:246:in >> `block in save!' >> >> >>/opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_re >>cord/transactions.rb:295:in >> `block in with_transaction_returning_status' >> >> >>/opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_re >>cord/connection_adapters/abstract/database_statements.rb:192:in >> `transaction' >> >> >>/opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_re >>cord/transactions.rb:208:in >> `transaction' >> >> >>/opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_re >>cord/transactions.rb:293:in >> `with_transaction_returning_status' >> >> >>/opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_re >>cord/transactions.rb:246:in >> `save!' >> >> >>/opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_re >>cord/validations.rb:41:in >> `create!' >> /usr/share/foreman/app/models/setting.rb:162:in `create!' >> /usr/share/foreman/app/models/setting/general.rb:25:in `block (2 >> levels) in load_defaults' >> /usr/share/foreman/app/models/setting/general.rb:15:in `each' >> /usr/share/foreman/app/models/setting/general.rb:15:in `block in >> load_defaults' >> >> >>/opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_re >>cord/connection_adapters/abstract/database_statements.rb:192:in >> `transaction' >> >> >>/opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.8/lib/active_re >>cord/transactions.rb:208:in >> `transaction' >> /usr/share/foreman/app/models/setting/general.rb:13:in `load_defaults' >> /usr/share/foreman/config/initializers/foreman.rb:18:in `each' >> /usr/share/foreman/config/initializers/foreman.rb:18:in `>(required)>' >> >> >>/opt/rh/ruby193/root/usr/share/gems/gems/activesupport-3.2.8/lib/active_s >>upport/dependencies.rb:245:in >> `load' >> >> >>/opt/rh/ruby193/root/usr/share/gems/gems/activesupport-3.2.8/lib/active_s >>upport/dependencies.rb:245:in >> `block in load' >> >> >>/opt/rh/ruby193/root/usr/share/gems/gems/activesupport-3.2.8/lib/active_s >>upport/dependencies.rb:236:in >> `load_dependency' >> >> >>/opt/rh/ruby193/root/usr/share/gems/gems/activesupport-3.2.8/lib/active_s >>upport/dependencies.rb:245:in >> `load' >> >> >>/opt/rh/ruby193/root/usr/share/gems/gems/railties-3.2.8/lib/rails/engine. >>rb:588:in >> `block (2 levels) in ' >> >> >>/opt/rh/ruby193/root/usr/share/gems/gems/railties-3.2.8/lib/rails/engine. >>rb:587:in >> `each' >> >> >>/opt/rh/ruby193/root/usr/share/gems/gems/railties-3.2.8/lib/rails/engine. >>rb:587:in >> `block in ' >> >> >>/opt/rh/ruby193/root/usr/share/gems/gems/railties-3.2.8/lib/rails/initial >>izable.rb:30:in >> `instance_exec' >> >> >>/opt/rh/ruby193/root/usr/share/gems/gems/railties-3.2.8/lib/rails/initial >>izable.rb:30:in >> `run' >> >> >>/opt/rh/ruby193/root/usr/share/gems/gems/railties-3.2.8/lib/rails/initial >>izable.rb:55:in >> `block in run_initializers' >> >> >>/opt/rh/ruby193/root/usr/share/gems/gems/railties-3.2.8/lib/rails/initial >>izable.rb:54:in >> `each' >> >> >>/opt/rh/ruby193/root/usr/share/gems/gems/railties-3.2.8/lib/rails/initial >>izable.rb:54:in >> `run_initializers' >> >> >>/opt/rh/ruby193/root/usr/share/gems/gems/railties-3.2.8/lib/rails/applica >>tion.rb:136:in >> `initialize!' >> >> >>/opt/rh/ruby193/root/usr/share/gems/gems/railties-3.2.8/lib/rails/railtie >>/configurable.rb:30:in >> `method_missing' >> /usr/share/foreman/config/environment.rb:5:in `' >> >> /opt/rh/ruby193/root/usr/share/rubygems/rubygems/custom_require.rb:36:in >> `require' >> >> /opt/rh/ruby193/root/usr/share/rubygems/rubygems/custom_require.rb:36:in >> `require' >> config.ru:3:in `block in
' >> >> >>/opt/rh/ruby193/root/usr/share/gems/gems/rack-1.4.1/lib/rack/builder.rb:5 >>1:in >> `instance_eval' >> >> >>/opt/rh/ruby193/root/usr/share/gems/gems/rack-1.4.1/lib/rack/builder.rb:5 >>1:in >> `initialize' >> config.ru:1:in `new' >> config.ru:1:in `
' >> >> >>/usr/lib/ruby/gems/1.8/gems/passenger-4.0.18/helper-scripts/rack-preloade >>r.rb:105:in >> `eval' >> >> >>/usr/lib/ruby/gems/1.8/gems/passenger-4.0.18/helper-scripts/rack-preloade >>r.rb:105:in >> `preload_app' >> >> >>/usr/lib/ruby/gems/1.8/gems/passenger-4.0.18/helper-scripts/rack-preloade >>r.rb:150:in >> `' >> >> >>/usr/lib/ruby/gems/1.8/gems/passenger-4.0.18/helper-scripts/rack-preloade >>r.rb:29:in >> `' >> >> >>/usr/lib/ruby/gems/1.8/gems/passenger-4.0.18/helper-scripts/rack-preloade >>r.rb:28:in >> `
' >> >> >> >> _______________________________________________ >> Rdo-list mailing list >> Rdo-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rdo-list >> > From vimal7370 at gmail.com Sat Jun 21 06:18:42 2014 From: vimal7370 at gmail.com (Vimal Kumar) Date: Sat, 21 Jun 2014 11:48:42 +0530 Subject: [Rdo-list] Adding another public subnet in RDO Message-ID: Hi, I have a dedicated server which has 2 public ip ranges allotted to it by the DC. I am trying out OpenStack RDO on this server (allinone install), and I was able to assign one of the mentioned ranges (let's say 173.xxx.xxx.144/29) and managed to use up all the available ips in this range for a few vms. This floating-ip range is now accessible from outside, and everything is fine. [root at mycloud ~(keystone_admin)]# neutron net-list +--------------------------------------+---------+---------------------------------------------------------+ | id | name | subnets | +--------------------------------------+---------+---------------------------------------------------------+ | 09c8da8e-79d7-49e1-9af8-c2a13a032040 | private | b7eeae38-682a-4397-8b3c-e3dee88527ab 10.0.0.0/24 | | 31956556-c540-4676-9cd4-e618a4f93fc8 | public | 14d4b197-1121-4a4b-80b3-b8d80115f734 173.xxx.xxx.144/29 | +--------------------------------------+---------+---------------------------------------------------------+ [root at yocloud ~(keystone_admin)]# neutron subnet-list +--------------------------------------+----------------+--------------------+--------------------------------------------------------+ | id | name | cidr | allocation_pools | +--------------------------------------+----------------+--------------------+--------------------------------------------------------+ | b7eeae38-682a-4397-8b3c-e3dee88527ab | private_subnet | 10.0.0.0/24 | {"start": "10.0.0.2", "end": "10.0.0.254"} | | 14d4b197-1121-4a4b-80b3-b8d80115f734 | public_subnet | 173.xxx.xxx.144/29 | {"start": "173.xxx.xxx.147", "end": "173.xxx.xxx.150"} | +--------------------------------------+----------------+--------------------+--------------------------------------------------------+ I am now looking to use the second public ip range for next vms and I am not sure how to proceed. I tried to create a subnet (public_subnet2) inside "public" net for the new ip block but fail to get it working. Neutron does not appear to know that it has a few more free floating-ips available, and throws 'No more IP addresses available on network'. Can someone point to the right direction? Is it not possible to add multiple subnets inside a public network? Regards, Vimal -------------- next part -------------- An HTML attachment was scrubbed... URL: From shake.chen at gmail.com Mon Jun 23 09:25:16 2014 From: shake.chen at gmail.com (Shake Chen) Date: Mon, 23 Jun 2014 17:25:16 +0800 Subject: [Rdo-list] how to let cinder not in control node Message-ID: Hi in the past , I can setting different role in different node, like cinder, nagios in different node. Now I try the newest packstack openstack-packstack.noarch 2014.1.1-0.21.dev1157.el6 @icehouse and found the answer file have change, many HOST can not setting, like cinder . why? -- Shake Chen -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbrady at redhat.com Mon Jun 23 10:03:15 2014 From: pbrady at redhat.com (=?ISO-8859-1?Q?P=E1draig_Brady?=) Date: Mon, 23 Jun 2014 11:03:15 +0100 Subject: [Rdo-list] how to let cinder not in control node In-Reply-To: References: Message-ID: <53A7FB63.8080807@redhat.com> On 06/23/2014 10:25 AM, Shake Chen wrote: > Hi > > in the past , I can setting different role in different node, like cinder, nagios in different node. > > Now I try the newest packstack > > openstack-packstack.noarch 2014.1.1-0.21.dev1157.el6 @icehouse > > and found the answer file have change, many HOST can not setting, like cinder . > > why? These new config vars as described in packstack.rst, reflect the uses cases supported by packstack, compared to the more fine grained control provided by the foreman based installer. **CONFIG_CONTROLLER_HOST** The IP address of the server on which to install OpenStack services specific to controller role such as API servers, Horizon, etc. This parameter replaced following deprecated parameters: CONFIG_CEILOMETER_HOST, CONFIG_CINDER_HOST, CONFIG_GLANCE_HOST, CONFIG_HORIZON_HOST, CONFIG_HEAT_HOST, CONFIG_KEYSTONE_HOST, CONFIG_NAGIOS_HOST, CONFIG_NEUTRON_SERVER_HOST, CONFIG_NEUTRON_LBAAS_HOSTS, CONFIG_NOVA_API_HOST, CONFIG_NOVA_CERT_HOST, CONFIG_NOVA_VNCPROXY_HOST, CONFIG_NOVA_SCHED_HOST, CONFIG_OSCLIENT_HOST, CONFIG_SWIFT_PROXY_HOSTS **CONFIG_COMPUTE_HOSTS** The list of IP addresses of the server on which to install the Nova compute service. This parameter replaced following deprecated parameters: CONFIG_NOVA_COMPUTE_HOSTS **CONFIG_NETWORK_HOSTS** The list of IP addresses of the server on which to install the network service such as Nova network or Neutron. This parameter replaced following deprecated parameters: CONFIG_NEUTRON_L3_HOSTS, CONFIG_NEUTRON_DHCP_HOSTS, CONFIG_NEUTRON_METADATA_HOSTS, CONFIG_NOVA_NETWORK_HOSTS The older variables still work for backwards compat. thanks, P?draig. From udaraliyanage at gmail.com Mon Jun 23 12:15:44 2014 From: udaraliyanage at gmail.com (Udara Liyanage) Date: Mon, 23 Jun 2014 17:45:44 +0530 Subject: [Rdo-list] Could not prefetch glance_image provider 'glance' error when installing RDO Message-ID: Hi, tail -200f /var/tmp/packstack/20140623-162100-8hSpBX/manifests/192.168.4.20_provision.pp.log Warning: Could not retrieve fact fqdn Notice: Compiled catalog for openstack01 in environment production in 0.15 seconds Notice: /Stage[main]/Main/Keystone_user[undef]/ensure: created *Error: Could not prefetch glance_image provider 'glance': Execution of '/usr/bin/glance -T services -I glance -K e7894790b6014f3e -N http://192.168.4.20:35357/v2.0/ index' returned 1: Request returned failure status.* Invalid OpenStack Identity credentials. ID Name Disk Format Container Format Size ------------------------------------ ------------------------------ -------------------- -------------------- -------------- Error: Execution of '/usr/bin/glance -T services -I glance -K e7894790b6014f3e -N http://192.168.4.20:35357/v2.0/ image-create --name=cirros --is-public=Yes --container-format=bare --disk-format=qcow2 --copy-from= http://download.cirros-cloud.net/0.3.1/cirros-0.3.1-x86_64-disk.img' returned 1: Request returned failure status. Invalid OpenStack Identity credentials. Error: /Stage[main]/Main/Glance_image[cirros]/ensure: change from absent to present failed: Execution of '/usr/bin/glance -T services -I glance -K e7894790b6014f3e -N http://192.168.4.20:35357/v2.0/ image-create --name=cirros --is-public=Yes --container-format=bare --disk-format=qcow2 --copy-from= http://download.cirros-cloud.net/0.3.1/cirros-0.3.1-x86_64-disk.img' returned 1: Request returned failure status. Invalid OpenStack Identity credentials. Error: Could not prefetch neutron_network provider 'neutron': Execution of '/usr/bin/neutron net-list --format=csv --column=id --quote=none' returned 1: Authentication required Error: Execution of '/usr/bin/neutron net-create --format=shell --tenant_id=a9090a661b6346fda202a8d66519f1d5 --router:external=True public' returned 1: Authentication required Error: /Stage[main]/Main/Neutron_network[public]/ensure: change from absent to present failed: Execution of '/usr/bin/neutron net-create --format=shell --tenant_id=a9090a661b6346fda202a8d66519f1d5 --router:external=True public' returned 1: Authentication required Error: Could not prefetch neutron_subnet provider 'neutron': Execution of '/usr/bin/neutron subnet-list --format=csv --column=id --quote=none' returned 1: Authentication required Notice: /Stage[main]/Main/Neutron_subnet[public_subnet]: Dependency Neutron_network[public] has failures: true Warning: /Stage[main]/Main/Neutron_subnet[public_subnet]: Skipping because of failed dependencies Any Ideas to resolve this? -- Udara S.S Liyanage. Software Engineer at WSO2. Commiter and PPMC Member of Apache Stratos. Blog - http://udaraliyanage.wordpress.com phone: +94 71 443 6897 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at buskey.name Mon Jun 23 18:30:13 2014 From: tom at buskey.name (Tom Buskey) Date: Mon, 23 Jun 2014 14:30:13 -0400 Subject: [Rdo-list] FYI.. CentOS6.5 ( do not install ) :1157 breaks mysql Message-ID: Any update or further link to this? I'm currently installing with packstack to CentOS 6.5. Switching to Fedora or RHEL is not an option. service mysqld start fails. This is due to inno_log_file_size being edited in /etc/my.cnf.d/innodb.cnf without rm /var/lib/mysql/ip_logfile*. service mysqld start now works. You can rerun packstack and it will succeed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbrady at redhat.com Mon Jun 23 21:41:20 2014 From: pbrady at redhat.com (=?ISO-8859-1?Q?P=E1draig_Brady?=) Date: Mon, 23 Jun 2014 22:41:20 +0100 Subject: [Rdo-list] FYI.. CentOS6.5 ( do not install ) :1157 breaks mysql In-Reply-To: References: Message-ID: <53A89F00.5040205@redhat.com> On 06/23/2014 07:30 PM, Tom Buskey wrote: > Any update or further link to this? > > I'm currently installing with packstack to CentOS 6.5. Switching to Fedora or RHEL is not an option. > > service mysqld start fails. > > This is due to inno_log_file_size being edited in /etc/my.cnf.d/innodb.cnf without rm /var/lib/mysql/ip_logfile*. > > service mysqld start now works. > > You can rerun packstack and it will succeed. This is a known issue, with a fix in the works. thanks, P?draig. From udaraliyanage at gmail.com Tue Jun 24 06:15:42 2014 From: udaraliyanage at gmail.com (Udara Liyanage) Date: Tue, 24 Jun 2014 11:45:42 +0530 Subject: [Rdo-list] [RDO] [CentOS] keypair-create hangs Message-ID: Hi, Installed RDO on CentOS. However nova keypair-create test> test.pem keep on hangs and no key pairs are created. What could be the solution? -- Udara S.S Liyanage. Software Engineer at WSO2. Commiter and PPMC Member of Apache Stratos. Blog - http://udaraliyanage.wordpress.com phone: +94 71 443 6897 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kchamart at redhat.com Tue Jun 24 09:23:14 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Tue, 24 Jun 2014 14:53:14 +0530 Subject: [Rdo-list] [RDO] [CentOS] keypair-create hangs In-Reply-To: References: Message-ID: <20140624092314.GF1523@tesla.redhat.com> On Tue, Jun 24, 2014 at 11:45:42AM +0530, Udara Liyanage wrote: > Hi, > > Installed RDO on CentOS. However nova keypair-create test> test.pem > keep on hangs and no key pairs are created. What could be the > solution? Hmm, I'm using Fedora though, I don't see nova 'keypair-create' command from Nova upstream sources. It's 'keypair-add' isn't it? $ nova --help | grep keypair keypair-add Create a new key pair for use with servers. keypair-delete Delete keypair given by its name. keypair-list Print a list of keypairs for a user keypair-show Show details about the given keypair. To use keypair-add, try that: $ nova keypair-add key1 > key1.priv $ chmod 600 oskey1.priv I checked with this version: $ rpm -q openstack-nova openstack-nova-2014.1-2.fc21.noarch -- /kashyap From udaraliyanage at gmail.com Tue Jun 24 09:28:49 2014 From: udaraliyanage at gmail.com (Udara Liyanage) Date: Tue, 24 Jun 2014 14:58:49 +0530 Subject: [Rdo-list] [RDO] [CentOS] keypair-create hangs In-Reply-To: <20140624092314.GF1523@tesla.redhat.com> References: <20140624092314.GF1523@tesla.redhat.com> Message-ID: Oh Sorry I was refering to keypair-add On Tue, Jun 24, 2014 at 2:53 PM, Kashyap Chamarthy wrote: > On Tue, Jun 24, 2014 at 11:45:42AM +0530, Udara Liyanage wrote: > > Hi, > > > > Installed RDO on CentOS. However nova keypair-create test> test.pem > > keep on hangs and no key pairs are created. What could be the > > solution? > > Hmm, I'm using Fedora though, I don't see nova 'keypair-create' command > from Nova upstream sources. > > It's 'keypair-add' isn't it? > > $ nova --help | grep keypair > keypair-add Create a new key pair for use with servers. > keypair-delete Delete keypair given by its name. > keypair-list Print a list of keypairs for a user > keypair-show Show details about the given keypair. > > > To use keypair-add, try that: > > $ nova keypair-add key1 > key1.priv > $ chmod 600 oskey1.priv > > > I checked with this version: > > $ rpm -q openstack-nova > openstack-nova-2014.1-2.fc21.noarch > > > -- > /kashyap > -- Udara S.S Liyanage. Software Engineer at WSO2. Commiter and PPMC Member of Apache Stratos. Blog - http://udaraliyanage.wordpress.com phone: +94 71 443 6897 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kchamart at redhat.com Tue Jun 24 10:19:07 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Tue, 24 Jun 2014 15:49:07 +0530 Subject: [Rdo-list] [RDO] [CentOS] keypair-create hangs In-Reply-To: References: <20140624092314.GF1523@tesla.redhat.com> Message-ID: <20140624101907.GG1523@tesla.redhat.com> On Tue, Jun 24, 2014 at 02:58:49PM +0530, Udara Liyanage wrote: > Oh Sorry I was refering to keypair-add Please check $ nova --debug keypair-add[. . .] If it still hangs, see if you can do some debugging by enabling pdb import pdb; pdb.set_trace() Some notes from a previous Nova Key pairs debugging: http://kashyapc.com/2013/03/27/debugging-nova-a-small-illustration-with-pdb/ > On Tue, Jun 24, 2014 at 2:53 PM, Kashyap Chamarthy > wrote: > > > On Tue, Jun 24, 2014 at 11:45:42AM +0530, Udara Liyanage wrote: > > > Hi, > > > > > > Installed RDO on CentOS. However nova keypair-create test> test.pem > > > keep on hangs and no key pairs are created. What could be the > > > solution? > > > > Hmm, I'm using Fedora though, I don't see nova 'keypair-create' command > > from Nova upstream sources. > > > > It's 'keypair-add' isn't it? > > > > $ nova --help | grep keypair > > keypair-add Create a new key pair for use with servers. > > keypair-delete Delete keypair given by its name. > > keypair-list Print a list of keypairs for a user > > keypair-show Show details about the given keypair. > > > > > > To use keypair-add, try that: > > > > $ nova keypair-add key1 > key1.priv > > $ chmod 600 oskey1.priv > > > > > > I checked with this version: > > > > $ rpm -q openstack-nova > > openstack-nova-2014.1-2.fc21.noarch > > -- /kashyap From kchamart at redhat.com Tue Jun 24 12:21:40 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Tue, 24 Jun 2014 17:51:40 +0530 Subject: [Rdo-list] Could not prefetch glance_image provider 'glance' error when installing RDO In-Reply-To: References: Message-ID: <20140624122140.GA3619@tesla.pnq.redhat.com> On Mon, Jun 23, 2014 at 05:45:44PM +0530, Udara Liyanage wrote: > Hi, > > tail -200f > /var/tmp/packstack/20140623-162100-8hSpBX/manifests/192.168.4.20_provision.pp.log > Warning: Could not retrieve fact fqdn > Notice: Compiled catalog for openstack01 in environment production in 0.15 > seconds > Notice: /Stage[main]/Main/Keystone_user[undef]/ensure: created > *Error: Could not prefetch glance_image provider 'glance': Execution of > '/usr/bin/glance -T services -I glance -K e7894790b6014f3e -N > http://192.168.4.20:35357/v2.0/ index' > returned 1: Request returned failure status.* > Invalid OpenStack Identity credentials. > ID Name Disk > Format Container Format Size > ------------------------------------ ------------------------------ > -------------------- -------------------- -------------- > Error: Execution of '/usr/bin/glance -T services -I glance -K > e7894790b6014f3e -N http://192.168.4.20:35357/v2.0/ image-create > --name=cirros --is-public=Yes --container-format=bare --disk-format=qcow2 > --copy-from= > http://download.cirros-cloud.net/0.3.1/cirros-0.3.1-x86_64-disk.img' > returned 1: Request returned failure status. > Invalid OpenStack Identity credentials. > Error: /Stage[main]/Main/Glance_image[cirros]/ensure: change from absent to > present failed: Execution of '/usr/bin/glance -T services -I glance -K > e7894790b6014f3e -N http://192.168.4.20:35357/v2.0/ image-create > --name=cirros --is-public=Yes --container-format=bare --disk-format=qcow2 > --copy-from= > http://download.cirros-cloud.net/0.3.1/cirros-0.3.1-x86_64-disk.img' > returned 1: Request returned failure status. > Invalid OpenStack Identity credentials. I don't see this happening in my RDO AIO env. on EL7. Also, you've not mentioned what packages you're using, version details etc (apart from saying "installing RDO"). That said, I see an old workdarounds page here[1]. Not sure if it still applies, but it asks you rerun `packstack` with the _same_ previous answers file. It depends on your test environment if that advice still applies or not. [1] http://openstack.redhat.com/Workarounds#Could_not_prefetch_glance_image_provider_.27glance.27 -- /kashyap From jruzicka at redhat.com Tue Jun 24 17:03:49 2014 From: jruzicka at redhat.com (Jakub Ruzicka) Date: Tue, 24 Jun 2014 19:03:49 +0200 Subject: [Rdo-list] FYI.. CentOS6.5 ( do not install ) :1157 breaks mysql In-Reply-To: References: Message-ID: <53A9AF75.2060405@redhat.com> Hey, sorry about that, human error. I just synced hotfix to RDO Icehouse epel-6 repo: openstack-packstack-2014.1.1-0.21.dev1157.1.el6 Cheers Jakub On 23.6.2014 20:30, Tom Buskey wrote: > Any update or further link to this? > > I'm currently installing with packstack to CentOS 6.5. Switching to Fedora > or RHEL is not an option. > > service mysqld start fails. > > This is due to inno_log_file_size being edited in /etc/my.cnf.d/innodb.cnf > without rm /var/lib/mysql/ip_logfile*. > > service mysqld start now works. > > You can rerun packstack and it will succeed. > > > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > From tom at buskey.name Tue Jun 24 17:55:15 2014 From: tom at buskey.name (Tom Buskey) Date: Tue, 24 Jun 2014 13:55:15 -0400 Subject: [Rdo-list] FYI.. CentOS6.5 ( do not install ) :1157 breaks mysql In-Reply-To: <53A9AF75.2060405@redhat.com> References: <53A9AF75.2060405@redhat.com> Message-ID: I noticed that packstack's --gen-answer-file changes many of the variable names from 1068 to 1157. Does 1157.1 revert that? On Tue, Jun 24, 2014 at 1:03 PM, Jakub Ruzicka wrote: > Hey, > > sorry about that, human error. I just synced hotfix to RDO Icehouse > epel-6 repo: > > openstack-packstack-2014.1.1-0.21.dev1157.1.el6 > > > Cheers > Jakub > > On 23.6.2014 20:30, Tom Buskey wrote: > > Any update or further link to this? > > > > I'm currently installing with packstack to CentOS 6.5. Switching to > Fedora > > or RHEL is not an option. > > > > service mysqld start fails. > > > > This is due to inno_log_file_size being edited in > /etc/my.cnf.d/innodb.cnf > > without rm /var/lib/mysql/ip_logfile*. > > > > service mysqld start now works. > > > > You can rerun packstack and it will succeed. > > > > > > > > _______________________________________________ > > Rdo-list mailing list > > Rdo-list at redhat.com > > https://www.redhat.com/mailman/listinfo/rdo-list > > > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbowen at redhat.com Tue Jun 24 18:36:23 2014 From: rbowen at redhat.com (Rich Bowen) Date: Tue, 24 Jun 2014 14:36:23 -0400 Subject: [Rdo-list] FYI.. CentOS6.5 ( do not install ) :1157 breaks mysql In-Reply-To: References: Message-ID: <53A9C527.8010904@redhat.com> On 06/23/2014 02:30 PM, Tom Buskey wrote: > I'm currently installing with packstack to CentOS 6.5. Switching to > Fedora or RHEL is not an option. > > service mysqld start fails. > > This is due to inno_log_file_size being edited in > /etc/my.cnf.d/innodb.cnf without rm /var/lib/mysql/ip_logfile*. > > service mysqld start now works. > > You can rerun packstack and it will succeed. Presumably ib_logfile* rather than ip_logfile*, right? -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://openstack.redhat.com/ From rbowen at redhat.com Tue Jun 24 18:47:01 2014 From: rbowen at redhat.com (Rich Bowen) Date: Tue, 24 Jun 2014 14:47:01 -0400 Subject: [Rdo-list] FYI.. CentOS6.5 ( do not install ) :1157 breaks mysql In-Reply-To: <53A9AF75.2060405@redhat.com> References: <53A9AF75.2060405@redhat.com> Message-ID: <53A9C7A5.8080208@redhat.com> Thanks. This got me past the mysql problem, but now I'm getting "Could not find a suitable provider for cron" from keystone.pp The keystone.pp.log file says: Warning: Config file /etc/puppet/hiera.yaml not found, using Hiera defaults Warning: Scope(Class[Keystone]): token_format parameter is deprecated. Use token_provider instead. Warning: Scope(Class[Nova::Keystone::Auth]): The cinder parameter is deprecated and has no effect. Notice: Compiled catalog for localhost.localdomain in environment production in 1.31 seconds Warning: The package type's allow_virtual parameter will be changing its default value from false to true in a future release. If you do not want to allow virtual packages, please explicitly set allow_virtual to false. (at /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:816:in `set_default') Notice: /Stage[main]/Ceilometer::Keystone::Auth/Keystone_user_role[ceilometer at services]/roles: roles changed ['ResellerAdmin', 'admin'] to 'admin ResellerAdmin' Notice: /Stage[main]/Main/Service[crond]: Dependency Cron[token-flush] has failures: true Warning: /Stage[main]/Main/Service[crond]: Skipping because of failed dependencies Error: Could not find a suitable provider for cron Notice: Finished catalog run in 17.00 seconds Thoughts? --Rich On 06/24/2014 01:03 PM, Jakub Ruzicka wrote: > Hey, > > sorry about that, human error. I just synced hotfix to RDO Icehouse > epel-6 repo: > > openstack-packstack-2014.1.1-0.21.dev1157.1.el6 > > > Cheers > Jakub > > On 23.6.2014 20:30, Tom Buskey wrote: >> Any update or further link to this? >> >> I'm currently installing with packstack to CentOS 6.5. Switching to Fedora >> or RHEL is not an option. >> >> service mysqld start fails. >> >> This is due to inno_log_file_size being edited in /etc/my.cnf.d/innodb.cnf >> without rm /var/lib/mysql/ip_logfile*. >> >> service mysqld start now works. >> >> You can rerun packstack and it will succeed. >> >> >> >> _______________________________________________ >> Rdo-list mailing list >> Rdo-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rdo-list >> > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://openstack.redhat.com/ From vimal7370 at gmail.com Tue Jun 24 18:50:53 2014 From: vimal7370 at gmail.com (Vimal Kumar) Date: Wed, 25 Jun 2014 00:20:53 +0530 Subject: [Rdo-list] FYI.. CentOS6.5 ( do not install ) :1157 breaks mysql In-Reply-To: <53A9C7A5.8080208@redhat.com> References: <53A9AF75.2060405@redhat.com> <53A9C7A5.8080208@redhat.com> Message-ID: # yum install cronie .. is the solution On Wed, Jun 25, 2014 at 12:17 AM, Rich Bowen wrote: > Thanks. This got me past the mysql problem, but now I'm getting "Could not > find a suitable provider for cron" from keystone.pp > > The keystone.pp.log file says: > > Warning: Config file /etc/puppet/hiera.yaml not found, using Hiera defaults > Warning: Scope(Class[Keystone]): token_format parameter is deprecated. Use > token_provider instead. > Warning: Scope(Class[Nova::Keystone::Auth]): The cinder parameter is > deprecated and has no effect. > Notice: Compiled catalog for localhost.localdomain in environment > production in 1.31 seconds > Warning: The package type's allow_virtual parameter will be changing its > default value from false to true in a future release. If you do not want to > allow virtual packages, please explicitly set allow_virtual to false. > (at /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:816:in `set_default') > Notice: /Stage[main]/Ceilometer::Keystone::Auth/Keystone_user_ > role[ceilometer at services]/roles: roles changed ['ResellerAdmin', 'admin'] > to 'admin ResellerAdmin' > Notice: /Stage[main]/Main/Service[crond]: Dependency Cron[token-flush] > has failures: true > Warning: /Stage[main]/Main/Service[crond]: Skipping because of failed > dependencies > Error: Could not find a suitable provider for cron > Notice: Finished catalog run in 17.00 seconds > > > Thoughts? > > --Rich > > > > > On 06/24/2014 01:03 PM, Jakub Ruzicka wrote: > >> Hey, >> >> sorry about that, human error. I just synced hotfix to RDO Icehouse >> epel-6 repo: >> >> openstack-packstack-2014.1.1-0.21.dev1157.1.el6 >> >> >> Cheers >> Jakub >> >> On 23.6.2014 20:30, Tom Buskey wrote: >> >>> Any update or further link to this? >>> >>> I'm currently installing with packstack to CentOS 6.5. Switching to >>> Fedora >>> or RHEL is not an option. >>> >>> service mysqld start fails. >>> >>> This is due to inno_log_file_size being edited in >>> /etc/my.cnf.d/innodb.cnf >>> without rm /var/lib/mysql/ip_logfile*. >>> >>> service mysqld start now works. >>> >>> You can rerun packstack and it will succeed. >>> >>> >>> >>> _______________________________________________ >>> Rdo-list mailing list >>> Rdo-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/rdo-list >>> >>> _______________________________________________ >> Rdo-list mailing list >> Rdo-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rdo-list >> > > -- > Rich Bowen - rbowen at redhat.com > OpenStack Community Liaison > http://openstack.redhat.com/ > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbrady at redhat.com Tue Jun 24 18:56:04 2014 From: pbrady at redhat.com (=?ISO-8859-1?Q?P=E1draig_Brady?=) Date: Tue, 24 Jun 2014 19:56:04 +0100 Subject: [Rdo-list] FYI.. CentOS6.5 ( do not install ) :1157 breaks mysql In-Reply-To: References: <53A9AF75.2060405@redhat.com> Message-ID: <53A9C9C4.7020609@redhat.com> On 06/24/2014 06:55 PM, Tom Buskey wrote: > I noticed that packstack's --gen-answer-file changes many of the variable names from 1068 to 1157. Does 1157.1 revert that? No it doesn't revert that, though the new packstack should be backwards compat with older answer files. These config changes were also mentioned at: https://www.redhat.com/archives/rdo-list/2014-June/msg00092.html thanks, P?draig. From whayutin at redhat.com Tue Jun 24 19:16:08 2014 From: whayutin at redhat.com (whayutin) Date: Tue, 24 Jun 2014 15:16:08 -0400 Subject: [Rdo-list] FYI.. CentOS6.5 ( do not install ) In-Reply-To: <1403199835.3142.17.camel@localhost.localdomain> References: <1403199835.3142.17.camel@localhost.localdomain> Message-ID: <1403637368.3056.10.camel@localhost.localdomain> On Thu, 2014-06-19 at 13:43 -0400, whayutin wrote: > An update to RDO was recently pushed that prevents mysql restarting on > CentOS 6.5. An update with the fix is in the works, until then please > use RHEL or Fedora. > > Thank you! > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list The CentOS packstack install issues around mysql should be resolved now. Please email us back w/ any issues. Thank you! From gareth at openstacker.org Wed Jun 25 06:42:04 2014 From: gareth at openstacker.org (Kun Huang) Date: Wed, 25 Jun 2014 14:42:04 +0800 Subject: [Rdo-list] how to let cinder not in control node In-Reply-To: <53A7FB63.8080807@redhat.com> References: <53A7FB63.8080807@redhat.com> Message-ID: Hi P?draig Is it possible to add a config layer to describe the relationship between role of nodes and services on it. It maybe look like: config_controller_role = nova_api_server, glance_api_server, neutron_api_server .... config_compute_role = nova_computer, ovs, ... and we could also describe the dependency relationship in configure files or rpm spec so that the behaviors in packstack/plugins/*.py could be much easier. On Mon, Jun 23, 2014 at 6:03 PM, P?draig Brady wrote: > On 06/23/2014 10:25 AM, Shake Chen wrote: >> Hi >> >> in the past , I can setting different role in different node, like cinder, nagios in different node. >> >> Now I try the newest packstack >> >> openstack-packstack.noarch 2014.1.1-0.21.dev1157.el6 @icehouse >> >> and found the answer file have change, many HOST can not setting, like cinder . >> >> why? > > These new config vars as described in packstack.rst, > reflect the uses cases supported by packstack, compared to the > more fine grained control provided by the foreman based installer. > > **CONFIG_CONTROLLER_HOST** > The IP address of the server on which to install OpenStack services specific to controller role > such as API servers, Horizon, etc. This parameter replaced following deprecated parameters: > CONFIG_CEILOMETER_HOST, CONFIG_CINDER_HOST, CONFIG_GLANCE_HOST, CONFIG_HORIZON_HOST, > CONFIG_HEAT_HOST, CONFIG_KEYSTONE_HOST, CONFIG_NAGIOS_HOST, CONFIG_NEUTRON_SERVER_HOST, > CONFIG_NEUTRON_LBAAS_HOSTS, CONFIG_NOVA_API_HOST, CONFIG_NOVA_CERT_HOST, CONFIG_NOVA_VNCPROXY_HOST, > CONFIG_NOVA_SCHED_HOST, CONFIG_OSCLIENT_HOST, CONFIG_SWIFT_PROXY_HOSTS > > **CONFIG_COMPUTE_HOSTS** > The list of IP addresses of the server on which to install the Nova compute service. > This parameter replaced following deprecated parameters: CONFIG_NOVA_COMPUTE_HOSTS > > **CONFIG_NETWORK_HOSTS** > The list of IP addresses of the server on which to install the network service such as > Nova network or Neutron. This parameter replaced following deprecated parameters: > CONFIG_NEUTRON_L3_HOSTS, CONFIG_NEUTRON_DHCP_HOSTS, CONFIG_NEUTRON_METADATA_HOSTS, CONFIG_NOVA_NETWORK_HOSTS > > The older variables still work for backwards compat. > > thanks, > P?draig. > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list From udaraliyanage at gmail.com Wed Jun 25 13:57:32 2014 From: udaraliyanage at gmail.com (Udara Liyanage) Date: Wed, 25 Jun 2014 19:27:32 +0530 Subject: [Rdo-list] Can't access instances created - RDO with external network Message-ID: Hi, I followed the instructions on the [1] to configure RDO openstack with existing external network. When an instance is created , a private Ip is assigned and I manually assign a floating Ip. Everything went Ok. However I can not access/ssh/ping instances using any of the Ips, - Private Ip - 10.0.0.2 - Public Ip -192.168.4.52 Routing table of the machine where RDO is installed. [root at Openstack01 neutron(keystone_admin)]# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0 192.168.4.0 0.0.0.0 255.255.252.0 U 0 0 0 br-ex 192.168.4.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0 192.168.4.0 0.0.0.0 255.255.252.0 U 0 0 0 eth1 169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 1003 0 0 eth1 169.254.0.0 0.0.0.0 255.255.0.0 U 1171 0 0 br-ex 0.0.0.0 192.168.4.254 0.0.0.0 UG 0 0 0 br-ex How I created the subnet neutron subnet-create public-udara 192.168.4.0/24 --name vlan --enable_dhcp=False --allocation_pool start=192.168.4.50,end=192.168.4.100 --gateway 192.168.4.254 [1] http://openstack.redhat.com/Neutron_with_existing_external_network -- Udara S.S Liyanage. Software Engineer at WSO2. Commiter and PPMC Member of Apache Stratos. Blog - http://udaraliyanage.wordpress.com phone: +94 71 443 6897 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vimal7370 at gmail.com Wed Jun 25 14:10:43 2014 From: vimal7370 at gmail.com (Vimal Kumar) Date: Wed, 25 Jun 2014 19:40:43 +0530 Subject: [Rdo-list] Can't access instances created - RDO with external network In-Reply-To: References: Message-ID: Hi, Often times everything work well but we get things blocked ourselves, thanks to security groups. Make sure that the secgroup you used has allowed traffic for ping and ssh. Regards, Vimal On Wed, Jun 25, 2014 at 7:27 PM, Udara Liyanage wrote: > Hi, > > I followed the instructions on the [1] to configure RDO openstack with > existing external network. When an instance is created , a private Ip is > assigned and I manually assign a floating Ip. Everything went Ok. > However I can not access/ssh/ping instances using any of the Ips, > > > - Private Ip - 10.0.0.2 > - Public Ip -192.168.4.52 > > > Routing table of the machine where RDO is installed. > [root at Openstack01 neutron(keystone_admin)]# route -n > Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref Use > Iface > 192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 > virbr0 > 192.168.4.0 0.0.0.0 255.255.252.0 U 0 0 0 > br-ex > 192.168.4.0 0.0.0.0 255.255.252.0 U 0 0 0 > eth0 > 192.168.4.0 0.0.0.0 255.255.252.0 U 0 0 0 > eth1 > 169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 > eth0 > 169.254.0.0 0.0.0.0 255.255.0.0 U 1003 0 0 > eth1 > 169.254.0.0 0.0.0.0 255.255.0.0 U 1171 0 0 > br-ex > 0.0.0.0 192.168.4.254 0.0.0.0 UG 0 0 0 > br-ex > > How I created the subnet > neutron subnet-create public-udara 192.168.4.0/24 --name vlan > --enable_dhcp=False --allocation_pool start=192.168.4.50,end=192.168.4.100 > --gateway 192.168.4.254 > > [1] http://openstack.redhat.com/Neutron_with_existing_external_network > > -- > Udara S.S Liyanage. > Software Engineer at WSO2. > Commiter and PPMC Member of Apache Stratos. > Blog - http://udaraliyanage.wordpress.com > phone: +94 71 443 6897 > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From udaraliyanage at gmail.com Wed Jun 25 14:39:36 2014 From: udaraliyanage at gmail.com (Udara Liyanage) Date: Wed, 25 Jun 2014 20:09:36 +0530 Subject: [Rdo-list] Can't access instances created - RDO with external network In-Reply-To: References: Message-ID: Hi, My security groups allows every port. On Wed, Jun 25, 2014 at 7:40 PM, Vimal Kumar wrote: > Hi, > > Often times everything work well but we get things blocked ourselves, > thanks to security groups. Make sure that the secgroup you used has allowed > traffic for ping and ssh. > > Regards, > Vimal > > > On Wed, Jun 25, 2014 at 7:27 PM, Udara Liyanage > wrote: > >> Hi, >> >> I followed the instructions on the [1] to configure RDO openstack with >> existing external network. When an instance is created , a private Ip is >> assigned and I manually assign a floating Ip. Everything went Ok. >> However I can not access/ssh/ping instances using any of the Ips, >> >> >> - Private Ip - 10.0.0.2 >> - Public Ip -192.168.4.52 >> >> >> Routing table of the machine where RDO is installed. >> [root at Openstack01 neutron(keystone_admin)]# route -n >> Kernel IP routing table >> Destination Gateway Genmask Flags Metric Ref Use >> Iface >> 192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 >> virbr0 >> 192.168.4.0 0.0.0.0 255.255.252.0 U 0 0 0 >> br-ex >> 192.168.4.0 0.0.0.0 255.255.252.0 U 0 0 0 >> eth0 >> 192.168.4.0 0.0.0.0 255.255.252.0 U 0 0 0 >> eth1 >> 169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 >> eth0 >> 169.254.0.0 0.0.0.0 255.255.0.0 U 1003 0 0 >> eth1 >> 169.254.0.0 0.0.0.0 255.255.0.0 U 1171 0 0 >> br-ex >> 0.0.0.0 192.168.4.254 0.0.0.0 UG 0 0 0 >> br-ex >> >> How I created the subnet >> neutron subnet-create public-udara 192.168.4.0/24 --name vlan >> --enable_dhcp=False --allocation_pool start=192.168.4.50,end=192.168.4.100 >> --gateway 192.168.4.254 >> >> [1] http://openstack.redhat.com/Neutron_with_existing_external_network >> >> -- >> Udara S.S Liyanage. >> Software Engineer at WSO2. >> Commiter and PPMC Member of Apache Stratos. >> Blog - http://udaraliyanage.wordpress.com >> phone: +94 71 443 6897 >> >> _______________________________________________ >> Rdo-list mailing list >> Rdo-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rdo-list >> >> > -- Udara S.S Liyanage. Software Engineer at WSO2. Commiter and PPMC Member of Apache Stratos. Blog - http://udaraliyanage.wordpress.com phone: +94 71 443 6897 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbowen at redhat.com Wed Jun 25 18:01:06 2014 From: rbowen at redhat.com (Rich Bowen) Date: Wed, 25 Jun 2014 14:01:06 -0400 Subject: [Rdo-list] Demo system recommendations Message-ID: <53AB0E62.8020902@redhat.com> Today I went to a local University and did a "what is OpenStack" presentation. When I got to the demo part, (all in one, on a laptop) I couldn't log in to Horizon, and didn't have time to troubleshoot on-site. Back home again, and everything works perfectly. So, in retrospect, this was a case of poor planning, but I'd like to figure out how to have it not happen again, preferably even if I have to do a demo that is completely off-line. Is it simply a matter of changing 192.168.0.x to 127.0.0.1 in all of my OpenStack configuration files, or is there going to be more to it than that? --Rich -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://openstack.redhat.com/ From lars at redhat.com Wed Jun 25 18:26:02 2014 From: lars at redhat.com (Lars Kellogg-Stedman) Date: Wed, 25 Jun 2014 14:26:02 -0400 Subject: [Rdo-list] Demo system recommendations In-Reply-To: <53AB0E62.8020902@redhat.com> References: <53AB0E62.8020902@redhat.com> Message-ID: <20140625182602.GB2059@redhat.com> On Wed, Jun 25, 2014 at 02:01:06PM -0400, Rich Bowen wrote: > So, in retrospect, this was a case of poor planning, but I'd like to figure > out how to have it not happen again, preferably even if I have to do a demo > that is completely off-line. Rich, It sounds like maybe you had services configured to use an ip address that was attached to your external interface that -- predictably -- changed when booting in a new environment. I like to run OpenStack demos inside virtual machines in my laptop. This makes the network configuration completely independent from my laptop's external interface. I use a MASQUERADE rule on the host to give instances in this environment external access. That is, rather than attaching a physical nic to br-ex, I just give br-ex an ip address and then set up a masquerade rule for anything FROM that address range to eth0; something like: iptables -t nat -A POSTROUTING -s 172.16.0.0/24 -o eth0 -j MASQUERADE -- Lars Kellogg-Stedman | larsks @ irc Cloud Engineering / OpenStack | " " @ twitter -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From jruzicka at redhat.com Wed Jun 25 18:26:50 2014 From: jruzicka at redhat.com (Jakub Ruzicka) Date: Wed, 25 Jun 2014 20:26:50 +0200 Subject: [Rdo-list] [package announce] openstack-packstack icehouse update Message-ID: <53AB146A.2020408@redhat.com> RDO Icehouse packstack has been updated as follows. openstack-packstack-2014.1.1-0.21.dev1157 Changelog: - [MySQL] Fix check for CentOS in mysql_install - [Horizon] Fixes horizon error when neutron disabled (rhbz#1110492) - [Nova] Fix libvirt livemigration (rhbz#1100356) - [SeLinux] Start auditd by default (rhbz#1109250) - [Provision] Provision also on multinode setup (rhbz#1100356) - [Cinder] Moved cinder::volume::iscsi out of main template (rhbz#1106512) - [Neutron] Only setup nova notifications if nova is being installed - [Heat] Set EC2 auth url for Heat (rhbz#1106394) - [Neutron] Handle interface names containing ".", "-" or ":" (rhbz#1105166, rhbz#1057938) - [Packstack] Use openstack-selinux on RHEL-7 (rhbz#1109308) - [Cinder] Add forgotten cinder backend vmdk (rhbz#1109374) - [Nova] Restart libvirtd after Nova Network install (rhbz#1109362) - [Firewall] Make sure firewalld is down before iptables starts - [Packstack] Add special backward compat layer for Swift plugin - [Horizon] Added neutron options for Horizon (rhbz#1103148) - [MySQL] Make innodb tweaking compatible with mysql (rhbz#1023221) - [Packstack] Synced packstack.rst - [Swift] Make sure swift cactch_errors middleware is first in pipeline (rhbz#1023221) - [Neutron] Don't use vs_bridge with provider network (rhbz#1105884) - [Neutron] Fix firewall rules with multiple network hosts (rhbz#1105248) - [Horizon] Refactor horizon ssl setup to use puppet-horizon (rhbz#1104226) - [Neutron] Open VXLAN udp port (rhbz#1100993) - [Heat] Add Keystone domain for Heat support (rhbz#1076172) - [Neutron] Added Neutron FWaaS (rhbz#1098765) - [Nagios] updating nagios checks for cinder and glance to list all items not just the admins - [Packstack] Fixes language parsing problems - [Neutron] Fixed firewall protocols (rhbz#1100993) - [Nagios] Fix {nagios,monitoring}-plugins-ping confusion (rhbz#1100037, rhbz#1096154, rhbz#1101665, rhbz#1103695) Configuration changes: **CONFIG_CONTROLLER_HOST** The IP address of the server on which to install OpenStack services specific to controller role such as API servers, Horizon, etc. This parameter replaced following deprecated parameters: CONFIG_CEILOMETER_HOST, CONFIG_CINDER_HOST, CONFIG_GLANCE_HOST, CONFIG_HORIZON_HOST, CONFIG_HEAT_HOST, CONFIG_KEYSTONE_HOST, CONFIG_NAGIOS_HOST, CONFIG_NEUTRON_SERVER_HOST, CONFIG_NEUTRON_LBAAS_HOSTS, CONFIG_NOVA_API_HOST, CONFIG_NOVA_CERT_HOST, CONFIG_NOVA_VNCPROXY_HOST, CONFIG_NOVA_SCHED_HOST, CONFIG_OSCLIENT_HOST, CONFIG_SWIFT_PROXY_HOSTS **CONFIG_COMPUTE_HOSTS** The list of IP addresses of the server on which to install the Nova compute service. This parameter replaced following deprecated parameters: CONFIG_NOVA_COMPUTE_HOSTS **CONFIG_NETWORK_HOSTS** The list of IP addresses of the server on which to install the network service such as Nova network or Neutron. This parameter replaced following deprecated parameters: CONFIG_NEUTRON_L3_HOSTS, CONFIG_NEUTRON_DHCP_HOSTS, CONFIG_NEUTRON_METADATA_HOSTS, CONFIG_NOVA_NETWORK_HOSTS The older variables still work for backwards compat. From kchamart at redhat.com Thu Jun 26 06:32:41 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Thu, 26 Jun 2014 12:02:41 +0530 Subject: [Rdo-list] Demo system recommendations In-Reply-To: <20140625182602.GB2059@redhat.com> References: <53AB0E62.8020902@redhat.com> <20140625182602.GB2059@redhat.com> Message-ID: <20140626063241.GJ3844@tesla.redhat.com> On Wed, Jun 25, 2014 at 02:26:02PM -0400, Lars Kellogg-Stedman wrote: > On Wed, Jun 25, 2014 at 02:01:06PM -0400, Rich Bowen wrote: > > So, in retrospect, this was a case of poor planning, but I'd like to figure > > out how to have it not happen again, preferably even if I have to do a demo > > that is completely off-line. > > Rich, > > It sounds like maybe you had services configured to use an ip address > that was attached to your external interface that -- predictably -- > changed when booting in a new environment. > > I like to run OpenStack demos inside virtual machines in my laptop. Yep, I'd second the above comment. I do find it quite convenient to have an OpenStack setup in virtual machines. I can even upload them to a remote test machine to reproduce bugs, etc. > This makes the network configuration completely independent from my > laptop's external interface. > > I use a MASQUERADE rule on the host to give instances in this > environment external access. That is, rather than attaching a > physical nic to br-ex, I just give br-ex an ip address and then set up > a masquerade rule for anything FROM that address range to eth0; > something like: > > iptables -t nat -A POSTROUTING -s 172.16.0.0/24 -o eth0 -j MASQUERADE Thanks for this tip, so far I got by w/o adding this rule. -- /kashyap From gareth at openstacker.org Thu Jun 26 08:50:44 2014 From: gareth at openstacker.org (Kun Huang) Date: Thu, 26 Jun 2014 16:50:44 +0800 Subject: [Rdo-list] plan to add a parameter to config glance backend? Message-ID: Hi all Is there such a plan now? Actually it's okay to adjust glance.conf only. Deploying ceph is not necessary. Thanks :) Gareth From stefan.apostoaie at softvision.ro Thu Jun 26 12:55:56 2014 From: stefan.apostoaie at softvision.ro (Stefan Apostoaie) Date: Thu, 26 Jun 2014 15:55:56 +0300 Subject: [Rdo-list] Packstack Icehouse changes Message-ID: <53AC185C.4020801@softvision.ro> Hello, I was working on integrating a neutron plugin in Packstack and successfully done so for the Packstack havana. I then tried porting the changes into Packstack for icehouse and noticed some changes that limit my options: 1. We need to run the metadata agents on all the compute nodes so we previously used the CONFIG_NEUTRON_METADATA_HOSTS option to specify this. In the latest version this was deprecated and replaced by CONFIG_NETWORK_HOSTS so the metadata agent will only be installed on the network node. 2. The CONFIG_CONTROLLER_HOST replaces several other options including CONFIG_HORIZON_HOST. In our setup we need to run horizon on the public network and the other services on the private network. The missing CONFIG_HORIZON_HOST means that the dashboard will only be available on our private network and we need to manually update the horizon and httpd config files. 3. The CONFIG_NOVA_VNCPROXY_HOST was also replaced by CONFIG_CONTROLLER_HOST so the VM console doesn't work outside our private network. 4. An issue that I've encountered when running packstack was a mysql puppet error "service mysqld start failed: my_default_config doesn't take the --mysqld parameter". The mysqld service started when I tried from the command line and after that Packstack worked. Not sure it's related to Packstack or some mysql server issue on our machines. The servers we use have CentOS 6.5 installed. I know that having only three types of hosts (CONTROLLER, NETWORK, and COMPUTE) simplifies things when installing basic Openstack configurations (with the ml2, linux bridge, or ovs plugin), but for us it becomes a lot more complicated to make Packstack do what we need. I believe that these changes affect Packstacks' flexibility. Now we cannot install horizon, cinder, swift, or keystone on a different host because they are tied to the CONFIG_CONTROLLER_HOST option. Is there a way to override the CONFIG_CONTROLLER_HOST, CONFIG_NETWORK_HOSTS, and CONFIG_COMPUTE_HOSTS? Can packstack havana be used to install Openstack icehouse by configuring yum to use the icehouse rdo repository? Regards, Stefan A From shake.chen at gmail.com Thu Jun 26 13:23:39 2014 From: shake.chen at gmail.com (Shake Chen) Date: Thu, 26 Jun 2014 21:23:39 +0800 Subject: [Rdo-list] Packstack Icehouse changes In-Reply-To: <53AC185C.4020801@softvision.ro> References: <53AC185C.4020801@softvision.ro> Message-ID: remove the feature the packstack have been own is not good idea, and would affect many user. On Thu, Jun 26, 2014 at 8:55 PM, Stefan Apostoaie < stefan.apostoaie at softvision.ro> wrote: > Hello, > > I was working on integrating a neutron plugin in Packstack and > successfully done so for the Packstack havana. > I then tried porting the changes into Packstack for icehouse and noticed > some changes that limit my options: > 1. We need to run the metadata agents on all the compute nodes so we > previously used the CONFIG_NEUTRON_METADATA_HOSTS option to specify this. > In the latest version this was deprecated and replaced by > CONFIG_NETWORK_HOSTS so the metadata agent will only be installed on the > network node. > 2. The CONFIG_CONTROLLER_HOST replaces several other options including > CONFIG_HORIZON_HOST. In our setup we need to run horizon on the public > network and the other services on the private network. The missing > CONFIG_HORIZON_HOST means that the dashboard will only be available on our > private network and we need to manually update the horizon and httpd config > files. > 3. The CONFIG_NOVA_VNCPROXY_HOST was also replaced by > CONFIG_CONTROLLER_HOST so the VM console doesn't work outside our private > network. > 4. An issue that I've encountered when running packstack was a mysql > puppet error "service mysqld start failed: my_default_config doesn't take > the --mysqld parameter". The mysqld service started when I tried from the > command line and after that Packstack worked. Not sure it's related to > Packstack or some mysql server issue on our machines. > The servers we use have CentOS 6.5 installed. > > I know that having only three types of hosts (CONTROLLER, NETWORK, and > COMPUTE) simplifies things when installing basic Openstack configurations > (with the ml2, linux bridge, or ovs plugin), but for us it becomes a lot > more complicated to make Packstack do what we need. I believe that these > changes affect Packstacks' flexibility. Now we cannot install horizon, > cinder, swift, or keystone on a different host because they are tied to the > CONFIG_CONTROLLER_HOST option. > > Is there a way to override the CONFIG_CONTROLLER_HOST, > CONFIG_NETWORK_HOSTS, and CONFIG_COMPUTE_HOSTS? > Can packstack havana be used to install Openstack icehouse by configuring > yum to use the icehouse rdo repository? > > Regards, > Stefan A > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > -- Shake Chen -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmyers at redhat.com Thu Jun 26 13:33:42 2014 From: pmyers at redhat.com (Perry Myers) Date: Thu, 26 Jun 2014 09:33:42 -0400 Subject: [Rdo-list] Packstack Icehouse changes In-Reply-To: References: <53AC185C.4020801@softvision.ro> Message-ID: <53AC2136.1090105@redhat.com> On 06/26/2014 09:23 AM, Shake Chen wrote: > remove the feature the packstack have been own is not good idea, and > would affect many user. Part of the reason for the reduction in scope of Packstack is due to resource constraints for the team that is working on Packstack, Puppet and Foreman. If we could get some folks outside of Red Hat to become upstream contributors and more importantly maintainers of Packstack, then that would alleviate some of the scope creep concerns and perhaps Packstack could be expanded a bit. But right now with the majority of the effort solely coming from a handful of Red Hatters, we just don't have the bandwidth and hence the scope of Packstack was reduced to be purely an all-in-one/demo tool. We are more focused on building out Foreman as the tool for doing more complex and realistic deployments with our direct team members. So... Any volunteers to ramp up on Packstack from the community with the aim of becoming maintainers? :) (This is a long winded way of saying the usual: patches welcome) Perry > > On Thu, Jun 26, 2014 at 8:55 PM, Stefan Apostoaie > > > wrote: > > Hello, > > I was working on integrating a neutron plugin in Packstack and > successfully done so for the Packstack havana. > I then tried porting the changes into Packstack for icehouse and > noticed some changes that limit my options: > 1. We need to run the metadata agents on all the compute nodes so we > previously used the CONFIG_NEUTRON_METADATA_HOSTS option to specify > this. In the latest version this was deprecated and replaced by > CONFIG_NETWORK_HOSTS so the metadata agent will only be installed on > the network node. > 2. The CONFIG_CONTROLLER_HOST replaces several other options > including CONFIG_HORIZON_HOST. In our setup we need to run horizon > on the public network and the other services on the private network. > The missing CONFIG_HORIZON_HOST means that the dashboard will only > be available on our private network and we need to manually update > the horizon and httpd config files. > 3. The CONFIG_NOVA_VNCPROXY_HOST was also replaced by > CONFIG_CONTROLLER_HOST so the VM console doesn't work outside our > private network. > 4. An issue that I've encountered when running packstack was a mysql > puppet error "service mysqld start failed: my_default_config doesn't > take the --mysqld parameter". The mysqld service started when I > tried from the command line and after that Packstack worked. Not > sure it's related to Packstack or some mysql server issue on our > machines. > The servers we use have CentOS 6.5 installed. > > I know that having only three types of hosts (CONTROLLER, NETWORK, > and COMPUTE) simplifies things when installing basic Openstack > configurations (with the ml2, linux bridge, or ovs plugin), but for > us it becomes a lot more complicated to make Packstack do what we > need. I believe that these changes affect Packstacks' flexibility. > Now we cannot install horizon, cinder, swift, or keystone on a > different host because they are tied to the CONFIG_CONTROLLER_HOST > option. > > Is there a way to override the CONFIG_CONTROLLER_HOST, > CONFIG_NETWORK_HOSTS, and CONFIG_COMPUTE_HOSTS? > Can packstack havana be used to install Openstack icehouse by > configuring yum to use the icehouse rdo repository? > > Regards, > Stefan A From jruzicka at redhat.com Thu Jun 26 14:44:45 2014 From: jruzicka at redhat.com (Jakub Ruzicka) Date: Thu, 26 Jun 2014 16:44:45 +0200 Subject: [Rdo-list] Packstack Icehouse changes In-Reply-To: <53AC2136.1090105@redhat.com> References: <53AC185C.4020801@softvision.ro> <53AC2136.1090105@redhat.com> Message-ID: <53AC31DD.8080802@redhat.com> On 26.6.2014 15:33, Perry Myers wrote: > On 06/26/2014 09:23 AM, Shake Chen wrote: >> remove the feature the packstack have been own is not good idea, and >> would affect many user. > > Part of the reason for the reduction in scope of Packstack is due to > resource constraints for the team that is working on Packstack, Puppet > and Foreman. > > If we could get some folks outside of Red Hat to become upstream > contributors and more importantly maintainers of Packstack, then that > would alleviate some of the scope creep concerns and perhaps Packstack > could be expanded a bit. > > But right now with the majority of the effort solely coming from a > handful of Red Hatters, we just don't have the bandwidth and hence the > scope of Packstack was reduced to be purely an all-in-one/demo tool. Well, it was created as a proof-of-concept/demo tool in the first place. If you want sophisticated multi-node installer, packstack isn't the right tool for that job. Cheers Jakub From madko77 at gmail.com Thu Jun 26 14:52:34 2014 From: madko77 at gmail.com (Madko) Date: Thu, 26 Jun 2014 16:52:34 +0200 Subject: [Rdo-list] Packstack Icehouse changes In-Reply-To: <53AC31DD.8080802@redhat.com> References: <53AC185C.4020801@softvision.ro> <53AC2136.1090105@redhat.com> <53AC31DD.8080802@redhat.com> Message-ID: 2014-06-26 16:44 GMT+02:00 Jakub Ruzicka : > On 26.6.2014 15:33, Perry Myers wrote: > > On 06/26/2014 09:23 AM, Shake Chen wrote: > >> remove the feature the packstack have been own is not good idea, and > >> would affect many user. > > > > Part of the reason for the reduction in scope of Packstack is due to > > resource constraints for the team that is working on Packstack, Puppet > > and Foreman. > > > > If we could get some folks outside of Red Hat to become upstream > > contributors and more importantly maintainers of Packstack, then that > > would alleviate some of the scope creep concerns and perhaps Packstack > > could be expanded a bit. > > > > But right now with the majority of the effort solely coming from a > > handful of Red Hatters, we just don't have the bandwidth and hence the > > scope of Packstack was reduced to be purely an all-in-one/demo tool. > > Well, it was created as a proof-of-concept/demo tool in the first place. > > If you want sophisticated multi-node installer, packstack isn't the > right tool for that job. > > Good to know, what is the right tool for that job? I mean multi-node installer. > Cheers > Jakub > > > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > Best regards, -- Edouard Bourguignon -------------- next part -------------- An HTML attachment was scrubbed... URL: From juanfra.rodriguez.cardoso at gmail.com Thu Jun 26 14:59:31 2014 From: juanfra.rodriguez.cardoso at gmail.com (JuanFra Rodriguez Cardoso) Date: Thu, 26 Jun 2014 16:59:31 +0200 Subject: [Rdo-list] Packstack Icehouse changes In-Reply-To: References: <53AC185C.4020801@softvision.ro> <53AC2136.1090105@redhat.com> <53AC31DD.8080802@redhat.com> Message-ID: Foreman is the right tool! ;) Red Hat has great docs about it: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/4/html/Installation_and_Configuration_Guide/part-Deploying_OpenStack_with_Foreman.html Regards --- JuanFra Rodriguez Cardoso 2014-06-26 16:52 GMT+02:00 Madko : > > > > 2014-06-26 16:44 GMT+02:00 Jakub Ruzicka : > > On 26.6.2014 15:33, Perry Myers wrote: >> > On 06/26/2014 09:23 AM, Shake Chen wrote: >> >> remove the feature the packstack have been own is not good idea, and >> >> would affect many user. >> > >> > Part of the reason for the reduction in scope of Packstack is due to >> > resource constraints for the team that is working on Packstack, Puppet >> > and Foreman. >> > >> > If we could get some folks outside of Red Hat to become upstream >> > contributors and more importantly maintainers of Packstack, then that >> > would alleviate some of the scope creep concerns and perhaps Packstack >> > could be expanded a bit. >> > >> > But right now with the majority of the effort solely coming from a >> > handful of Red Hatters, we just don't have the bandwidth and hence the >> > scope of Packstack was reduced to be purely an all-in-one/demo tool. >> >> Well, it was created as a proof-of-concept/demo tool in the first place. >> >> If you want sophisticated multi-node installer, packstack isn't the >> right tool for that job. >> >> > Good to know, what is the right tool for that job? I mean multi-node > installer. > > >> Cheers >> Jakub >> >> >> >> _______________________________________________ >> Rdo-list mailing list >> Rdo-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rdo-list >> > > > Best regards, > -- > Edouard Bourguignon > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From madko77 at gmail.com Thu Jun 26 15:09:53 2014 From: madko77 at gmail.com (Madko) Date: Thu, 26 Jun 2014 17:09:53 +0200 Subject: [Rdo-list] Packstack Icehouse changes In-Reply-To: References: <53AC185C.4020801@softvision.ro> <53AC2136.1090105@redhat.com> <53AC31DD.8080802@redhat.com> Message-ID: Thanks, I will give it a try. I hope with more luck than packstack. 2014-06-26 16:59 GMT+02:00 JuanFra Rodriguez Cardoso < juanfra.rodriguez.cardoso at gmail.com>: > Foreman is the right tool! ;) > Red Hat has great docs about it: > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/4/html/Installation_and_Configuration_Guide/part-Deploying_OpenStack_with_Foreman.html > > Regards > --- > JuanFra Rodriguez Cardoso > > > 2014-06-26 16:52 GMT+02:00 Madko : > > >> >> >> 2014-06-26 16:44 GMT+02:00 Jakub Ruzicka : >> >> On 26.6.2014 15:33, Perry Myers wrote: >>> > On 06/26/2014 09:23 AM, Shake Chen wrote: >>> >> remove the feature the packstack have been own is not good idea, and >>> >> would affect many user. >>> > >>> > Part of the reason for the reduction in scope of Packstack is due to >>> > resource constraints for the team that is working on Packstack, Puppet >>> > and Foreman. >>> > >>> > If we could get some folks outside of Red Hat to become upstream >>> > contributors and more importantly maintainers of Packstack, then that >>> > would alleviate some of the scope creep concerns and perhaps Packstack >>> > could be expanded a bit. >>> > >>> > But right now with the majority of the effort solely coming from a >>> > handful of Red Hatters, we just don't have the bandwidth and hence the >>> > scope of Packstack was reduced to be purely an all-in-one/demo tool. >>> >>> Well, it was created as a proof-of-concept/demo tool in the first place. >>> >>> If you want sophisticated multi-node installer, packstack isn't the >>> right tool for that job. >>> >>> >> Good to know, what is the right tool for that job? I mean multi-node >> installer. >> >> >>> Cheers >>> Jakub >>> >>> >>> >>> _______________________________________________ >>> Rdo-list mailing list >>> Rdo-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/rdo-list >>> >> >> >> Best regards, >> -- >> Edouard Bourguignon >> >> _______________________________________________ >> Rdo-list mailing list >> Rdo-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rdo-list >> >> > -- Edouard Bourguignon -------------- next part -------------- An HTML attachment was scrubbed... URL: From gareth at openstacker.org Thu Jun 26 16:03:35 2014 From: gareth at openstacker.org (Kun Huang) Date: Fri, 27 Jun 2014 00:03:35 +0800 Subject: [Rdo-list] Packstack Icehouse changes In-Reply-To: References: <53AC185C.4020801@softvision.ro> <53AC2136.1090105@redhat.com> <53AC31DD.8080802@redhat.com> Message-ID: btw, the lastest reference should be this one? https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/5/html/Installation_and_Configuration_Guide/part-Deploy_OpenStack_with_Foreman.html On Thu, Jun 26, 2014 at 11:09 PM, Madko wrote: > Thanks, I will give it a try. I hope with more luck than packstack. > > > 2014-06-26 16:59 GMT+02:00 JuanFra Rodriguez Cardoso > : > >> Foreman is the right tool! ;) >> Red Hat has great docs about it: >> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/4/html/Installation_and_Configuration_Guide/part-Deploying_OpenStack_with_Foreman.html >> >> Regards >> --- >> JuanFra Rodriguez Cardoso >> >> >> 2014-06-26 16:52 GMT+02:00 Madko : >> >>> >>> >>> >>> 2014-06-26 16:44 GMT+02:00 Jakub Ruzicka : >>> >>>> On 26.6.2014 15:33, Perry Myers wrote: >>>> > On 06/26/2014 09:23 AM, Shake Chen wrote: >>>> >> remove the feature the packstack have been own is not good idea, and >>>> >> would affect many user. >>>> > >>>> > Part of the reason for the reduction in scope of Packstack is due to >>>> > resource constraints for the team that is working on Packstack, Puppet >>>> > and Foreman. >>>> > >>>> > If we could get some folks outside of Red Hat to become upstream >>>> > contributors and more importantly maintainers of Packstack, then that >>>> > would alleviate some of the scope creep concerns and perhaps Packstack >>>> > could be expanded a bit. >>>> > >>>> > But right now with the majority of the effort solely coming from a >>>> > handful of Red Hatters, we just don't have the bandwidth and hence the >>>> > scope of Packstack was reduced to be purely an all-in-one/demo tool. >>>> >>>> Well, it was created as a proof-of-concept/demo tool in the first place. >>>> >>>> If you want sophisticated multi-node installer, packstack isn't the >>>> right tool for that job. >>>> >>> >>> Good to know, what is the right tool for that job? I mean multi-node >>> installer. >>> >>>> >>>> Cheers >>>> Jakub >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rdo-list mailing list >>>> Rdo-list at redhat.com >>>> https://www.redhat.com/mailman/listinfo/rdo-list >>> >>> >>> >>> Best regards, >>> -- >>> Edouard Bourguignon >>> >>> _______________________________________________ >>> Rdo-list mailing list >>> Rdo-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/rdo-list >>> >> > > > > -- > Edouard Bourguignon > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > From udaraliyanage at gmail.com Fri Jun 27 05:47:25 2014 From: udaraliyanage at gmail.com (Udara Liyanage) Date: Fri, 27 Jun 2014 11:17:25 +0530 Subject: [Rdo-list] RDO instances can ssh/ping each other. But not from outside Message-ID: Hi, I installed RDO openstack on my machine as described in [1]. I was able to spawn a instance and associate a floating ip too. I created two instances and log into them via provided VNC . Instances can ping./ssh each other. However instances can not be accessed from external, neither from controller node nor from outside. What could be the reason for this issue? [1]http://openstack.redhat.com/Neutron_with_existing_external_network -- Udara S.S Liyanage. Software Engineer at WSO2. Commiter and PPMC Member of Apache Stratos. Blog - http://udaraliyanage.wordpress.com phone: +94 71 443 6897 -------------- next part -------------- An HTML attachment was scrubbed... URL: From madko77 at gmail.com Fri Jun 27 07:30:57 2014 From: madko77 at gmail.com (Madko) Date: Fri, 27 Jun 2014 09:30:57 +0200 Subject: [Rdo-list] Packstack Icehouse changes In-Reply-To: References: <53AC185C.4020801@softvision.ro> <53AC2136.1090105@redhat.com> <53AC31DD.8080802@redhat.com> Message-ID: No more luck :( I can't even install foreman due to this bug => https://bugzilla.redhat.com/show_bug.cgi?id=1091564 any idea how to make it work? 2014-06-26 18:03 GMT+02:00 Kun Huang : > btw, the lastest reference should be this one? > > > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/5/html/Installation_and_Configuration_Guide/part-Deploy_OpenStack_with_Foreman.html > > On Thu, Jun 26, 2014 at 11:09 PM, Madko wrote: > > Thanks, I will give it a try. I hope with more luck than packstack. > > > > > > 2014-06-26 16:59 GMT+02:00 JuanFra Rodriguez Cardoso > > : > > > >> Foreman is the right tool! ;) > >> Red Hat has great docs about it: > >> > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/4/html/Installation_and_Configuration_Guide/part-Deploying_OpenStack_with_Foreman.html > >> > >> Regards > >> --- > >> JuanFra Rodriguez Cardoso > >> > >> > >> 2014-06-26 16:52 GMT+02:00 Madko : > >> > >>> > >>> > >>> > >>> 2014-06-26 16:44 GMT+02:00 Jakub Ruzicka : > >>> > >>>> On 26.6.2014 15:33, Perry Myers wrote: > >>>> > On 06/26/2014 09:23 AM, Shake Chen wrote: > >>>> >> remove the feature the packstack have been own is not good idea, > and > >>>> >> would affect many user. > >>>> > > >>>> > Part of the reason for the reduction in scope of Packstack is due to > >>>> > resource constraints for the team that is working on Packstack, > Puppet > >>>> > and Foreman. > >>>> > > >>>> > If we could get some folks outside of Red Hat to become upstream > >>>> > contributors and more importantly maintainers of Packstack, then > that > >>>> > would alleviate some of the scope creep concerns and perhaps > Packstack > >>>> > could be expanded a bit. > >>>> > > >>>> > But right now with the majority of the effort solely coming from a > >>>> > handful of Red Hatters, we just don't have the bandwidth and hence > the > >>>> > scope of Packstack was reduced to be purely an all-in-one/demo tool. > >>>> > >>>> Well, it was created as a proof-of-concept/demo tool in the first > place. > >>>> > >>>> If you want sophisticated multi-node installer, packstack isn't the > >>>> right tool for that job. > >>>> > >>> > >>> Good to know, what is the right tool for that job? I mean multi-node > >>> installer. > >>> > >>>> > >>>> Cheers > >>>> Jakub > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Rdo-list mailing list > >>>> Rdo-list at redhat.com > >>>> https://www.redhat.com/mailman/listinfo/rdo-list > >>> > >>> > >>> > >>> Best regards, > >>> -- > >>> Edouard Bourguignon > >>> > >>> _______________________________________________ > >>> Rdo-list mailing list > >>> Rdo-list at redhat.com > >>> https://www.redhat.com/mailman/listinfo/rdo-list > >>> > >> > > > > > > > > -- > > Edouard Bourguignon > > > > _______________________________________________ > > Rdo-list mailing list > > Rdo-list at redhat.com > > https://www.redhat.com/mailman/listinfo/rdo-list > > > -- Edouard Bourguignon -------------- next part -------------- An HTML attachment was scrubbed... URL: From juanfra.rodriguez.cardoso at gmail.com Fri Jun 27 07:41:57 2014 From: juanfra.rodriguez.cardoso at gmail.com (JuanFra Rodriguez Cardoso) Date: Fri, 27 Jun 2014 09:41:57 +0200 Subject: [Rdo-list] Packstack Icehouse changes In-Reply-To: References: <53AC185C.4020801@softvision.ro> <53AC2136.1090105@redhat.com> <53AC31DD.8080802@redhat.com> Message-ID: Have you installed centos-SCL repo? Regards, --- JuanFra Rodriguez Cardoso 2014-06-27 9:30 GMT+02:00 Madko : > No more luck :( > I can't even install foreman due to this bug => > https://bugzilla.redhat.com/show_bug.cgi?id=1091564 > any idea how to make it work? > > > 2014-06-26 18:03 GMT+02:00 Kun Huang : > >> btw, the lastest reference should be this one? >> >> >> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/5/html/Installation_and_Configuration_Guide/part-Deploy_OpenStack_with_Foreman.html >> >> On Thu, Jun 26, 2014 at 11:09 PM, Madko wrote: >> > Thanks, I will give it a try. I hope with more luck than packstack. >> > >> > >> > 2014-06-26 16:59 GMT+02:00 JuanFra Rodriguez Cardoso >> > : >> > >> >> Foreman is the right tool! ;) >> >> Red Hat has great docs about it: >> >> >> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/4/html/Installation_and_Configuration_Guide/part-Deploying_OpenStack_with_Foreman.html >> >> >> >> Regards >> >> --- >> >> JuanFra Rodriguez Cardoso >> >> >> >> >> >> 2014-06-26 16:52 GMT+02:00 Madko : >> >> >> >>> >> >>> >> >>> >> >>> 2014-06-26 16:44 GMT+02:00 Jakub Ruzicka : >> >>> >> >>>> On 26.6.2014 15:33, Perry Myers wrote: >> >>>> > On 06/26/2014 09:23 AM, Shake Chen wrote: >> >>>> >> remove the feature the packstack have been own is not good idea, >> and >> >>>> >> would affect many user. >> >>>> > >> >>>> > Part of the reason for the reduction in scope of Packstack is due >> to >> >>>> > resource constraints for the team that is working on Packstack, >> Puppet >> >>>> > and Foreman. >> >>>> > >> >>>> > If we could get some folks outside of Red Hat to become upstream >> >>>> > contributors and more importantly maintainers of Packstack, then >> that >> >>>> > would alleviate some of the scope creep concerns and perhaps >> Packstack >> >>>> > could be expanded a bit. >> >>>> > >> >>>> > But right now with the majority of the effort solely coming from a >> >>>> > handful of Red Hatters, we just don't have the bandwidth and hence >> the >> >>>> > scope of Packstack was reduced to be purely an all-in-one/demo >> tool. >> >>>> >> >>>> Well, it was created as a proof-of-concept/demo tool in the first >> place. >> >>>> >> >>>> If you want sophisticated multi-node installer, packstack isn't the >> >>>> right tool for that job. >> >>>> >> >>> >> >>> Good to know, what is the right tool for that job? I mean multi-node >> >>> installer. >> >>> >> >>>> >> >>>> Cheers >> >>>> Jakub >> >>>> >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> Rdo-list mailing list >> >>>> Rdo-list at redhat.com >> >>>> https://www.redhat.com/mailman/listinfo/rdo-list >> >>> >> >>> >> >>> >> >>> Best regards, >> >>> -- >> >>> Edouard Bourguignon >> >>> >> >>> _______________________________________________ >> >>> Rdo-list mailing list >> >>> Rdo-list at redhat.com >> >>> https://www.redhat.com/mailman/listinfo/rdo-list >> >>> >> >> >> > >> > >> > >> > -- >> > Edouard Bourguignon >> > >> > _______________________________________________ >> > Rdo-list mailing list >> > Rdo-list at redhat.com >> > https://www.redhat.com/mailman/listinfo/rdo-list >> > >> > > > > -- > Edouard Bourguignon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From madko77 at gmail.com Fri Jun 27 07:44:57 2014 From: madko77 at gmail.com (Madko) Date: Fri, 27 Jun 2014 09:44:57 +0200 Subject: [Rdo-list] Packstack Icehouse changes In-Reply-To: References: <53AC185C.4020801@softvision.ro> <53AC2136.1090105@redhat.com> <53AC31DD.8080802@redhat.com> Message-ID: just installed the centos-SCL repo and now the installation is fine. Thanks :) 2014-06-27 9:41 GMT+02:00 JuanFra Rodriguez Cardoso < juanfra.rodriguez.cardoso at gmail.com>: > Have you installed centos-SCL repo? > > Regards, > --- > JuanFra Rodriguez Cardoso > > > 2014-06-27 9:30 GMT+02:00 Madko : > > No more luck :( >> I can't even install foreman due to this bug => >> https://bugzilla.redhat.com/show_bug.cgi?id=1091564 >> any idea how to make it work? >> >> >> 2014-06-26 18:03 GMT+02:00 Kun Huang : >> >>> btw, the lastest reference should be this one? >>> >>> >>> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/5/html/Installation_and_Configuration_Guide/part-Deploy_OpenStack_with_Foreman.html >>> >>> On Thu, Jun 26, 2014 at 11:09 PM, Madko wrote: >>> > Thanks, I will give it a try. I hope with more luck than packstack. >>> > >>> > >>> > 2014-06-26 16:59 GMT+02:00 JuanFra Rodriguez Cardoso >>> > : >>> > >>> >> Foreman is the right tool! ;) >>> >> Red Hat has great docs about it: >>> >> >>> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/4/html/Installation_and_Configuration_Guide/part-Deploying_OpenStack_with_Foreman.html >>> >> >>> >> Regards >>> >> --- >>> >> JuanFra Rodriguez Cardoso >>> >> >>> >> >>> >> 2014-06-26 16:52 GMT+02:00 Madko : >>> >> >>> >>> >>> >>> >>> >>> >>> >>> 2014-06-26 16:44 GMT+02:00 Jakub Ruzicka : >>> >>> >>> >>>> On 26.6.2014 15:33, Perry Myers wrote: >>> >>>> > On 06/26/2014 09:23 AM, Shake Chen wrote: >>> >>>> >> remove the feature the packstack have been own is not good idea, >>> and >>> >>>> >> would affect many user. >>> >>>> > >>> >>>> > Part of the reason for the reduction in scope of Packstack is due >>> to >>> >>>> > resource constraints for the team that is working on Packstack, >>> Puppet >>> >>>> > and Foreman. >>> >>>> > >>> >>>> > If we could get some folks outside of Red Hat to become upstream >>> >>>> > contributors and more importantly maintainers of Packstack, then >>> that >>> >>>> > would alleviate some of the scope creep concerns and perhaps >>> Packstack >>> >>>> > could be expanded a bit. >>> >>>> > >>> >>>> > But right now with the majority of the effort solely coming from a >>> >>>> > handful of Red Hatters, we just don't have the bandwidth and >>> hence the >>> >>>> > scope of Packstack was reduced to be purely an all-in-one/demo >>> tool. >>> >>>> >>> >>>> Well, it was created as a proof-of-concept/demo tool in the first >>> place. >>> >>>> >>> >>>> If you want sophisticated multi-node installer, packstack isn't the >>> >>>> right tool for that job. >>> >>>> >>> >>> >>> >>> Good to know, what is the right tool for that job? I mean multi-node >>> >>> installer. >>> >>> >>> >>>> >>> >>>> Cheers >>> >>>> Jakub >>> >>>> >>> >>>> >>> >>>> >>> >>>> _______________________________________________ >>> >>>> Rdo-list mailing list >>> >>>> Rdo-list at redhat.com >>> >>>> https://www.redhat.com/mailman/listinfo/rdo-list >>> >>> >>> >>> >>> >>> >>> >>> Best regards, >>> >>> -- >>> >>> Edouard Bourguignon >>> >>> >>> >>> _______________________________________________ >>> >>> Rdo-list mailing list >>> >>> Rdo-list at redhat.com >>> >>> https://www.redhat.com/mailman/listinfo/rdo-list >>> >>> >>> >> >>> > >>> > >>> > >>> > -- >>> > Edouard Bourguignon >>> > >>> > _______________________________________________ >>> > Rdo-list mailing list >>> > Rdo-list at redhat.com >>> > https://www.redhat.com/mailman/listinfo/rdo-list >>> > >>> >> >> >> >> -- >> Edouard Bourguignon >> > > -- Edouard Bourguignon -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrunge at redhat.com Fri Jun 27 09:22:06 2014 From: mrunge at redhat.com (Matthias Runge) Date: Fri, 27 Jun 2014 11:22:06 +0200 Subject: [Rdo-list] Demo system recommendations In-Reply-To: <53AB0E62.8020902@redhat.com> References: <53AB0E62.8020902@redhat.com> Message-ID: <20140627092205.GI25663@turing.berg.ol> On Wed, Jun 25, 2014 at 02:01:06PM -0400, Rich Bowen wrote: > Is it simply a matter of changing 192.168.0.x to 127.0.0.1 in all of my > OpenStack configuration files, or is there going to be more to it than that? That's, what I regularly do in my packstack config. Saves me lots of headaches, as I have OpenStack directly installed on my laptop. -- Matthias Runge From udaraliyanage at gmail.com Fri Jun 27 09:23:50 2014 From: udaraliyanage at gmail.com (Udara Liyanage) Date: Fri, 27 Jun 2014 14:53:50 +0530 Subject: [Rdo-list] RDO instances can ssh/ping each other. But not from outside In-Reply-To: References: Message-ID: Any help is appriciated. On Fri, Jun 27, 2014 at 11:17 AM, Udara Liyanage wrote: > Hi, > > I installed RDO openstack on my machine as described in [1]. I was able to > spawn a instance and associate a floating ip too. I created two instances > and log into them via provided VNC . Instances can ping./ssh each other. > However instances can not be accessed from external, neither from > controller node nor from outside. > What could be the reason for this issue? > > [1]http://openstack.redhat.com/Neutron_with_existing_external_network > > > -- > Udara S.S Liyanage. > Software Engineer at WSO2. > Commiter and PPMC Member of Apache Stratos. > Blog - http://udaraliyanage.wordpress.com > phone: +94 71 443 6897 > -- Udara S.S Liyanage. Software Engineer at WSO2. Commiter and PPMC Member of Apache Stratos. Blog - http://udaraliyanage.wordpress.com phone: +94 71 443 6897 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbowen at redhat.com Fri Jun 27 15:31:06 2014 From: rbowen at redhat.com (Rich Bowen) Date: Fri, 27 Jun 2014 11:31:06 -0400 Subject: [Rdo-list] Save the date: OpenStack Trove Day, August 19th in Cambridge MA Message-ID: <53AD8E3A.7090203@redhat.com> If you're involved with, or interested in, the Trove project, save August 19th for the OpenStacck Trove Day, hosted by Tesora in Cambridge, MA. Details are available at http://www.tesora.com/event/openstack-trove-day -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://openstack.redhat.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfv at eurotux.com Fri Jun 27 17:43:46 2014 From: dfv at eurotux.com (Diogo Vieira) Date: Fri, 27 Jun 2014 18:43:46 +0100 Subject: [Rdo-list] Swift generating thousands of rsyncs per second on a small cluster Message-ID: <563C0963-8180-4D9C-ABB5-B5372508C672@eurotux.com> Hello, I have a small cluster consisting on a physical machine running a Proxy and a Storage Node and 4 virtual machines running one Storage node each. Each Storage Node has only one device and the cluster has 5 zones and 3 replicas all configured with packstack. Between the real machine (Proxy Node) and the virtual machines I have a firewall that logs all the traffic. I ran out of disk space in the firewall and came to the conclusion that the problem was the traffic generated between the Proxy Nodes and the virtual machines in port 6000 (which is of the object-server if I'm not mistaken). The problem is that the traffic being generated is on the order of a thousand or 2 rsyncs per second which seems a bit excessive. Is this behaviour normal? How much traffic should I be getting with this setup, with several (probably thousands) very small objects and less than 10 containers since it is not being accessed at all (right now we're not using the cluster)? Can someone help me understand where the problem is? Assuming this is a problem, I tried to lower the concurrency on the object/container/account replicators and the number of workers in the proxy-server without any success. Thank you in advance, Diogo Vieira Programador Eurotux Inform?tica, S.A. | www.eurotux.com (t) +351 253 680 300 -------------- next part -------------- An HTML attachment was scrubbed... URL: From avattathil at gmail.com Sat Jun 28 02:17:26 2014 From: avattathil at gmail.com (Anthony Vattathil) Date: Fri, 27 Jun 2014 19:17:26 -0700 Subject: [Rdo-list] RDO instances can ssh/ping each other. But not from outside In-Reply-To: References: Message-ID: Udara, You probably need to configure your security groups to allow ssh inbound Make sure that the public/floating ip network was created properly (with external access) --Tony On Friday, June 27, 2014, Udara Liyanage wrote: > Any help is appriciated. > > > On Fri, Jun 27, 2014 at 11:17 AM, Udara Liyanage > wrote: > >> Hi, >> >> I installed RDO openstack on my machine as described in [1]. I was able >> to spawn a instance and associate a floating ip too. I created two >> instances and log into them via provided VNC . Instances can ping./ssh each >> other. However instances can not be accessed from external, neither from >> controller node nor from outside. >> What could be the reason for this issue? >> >> [1]http://openstack.redhat.com/Neutron_with_existing_external_network >> >> >> -- >> Udara S.S Liyanage. >> Software Engineer at WSO2. >> Commiter and PPMC Member of Apache Stratos. >> Blog - http://udaraliyanage.wordpress.com >> phone: +94 71 443 6897 >> > > > > -- > Udara S.S Liyanage. > Software Engineer at WSO2. > Commiter and PPMC Member of Apache Stratos. > Blog - http://udaraliyanage.wordpress.com > phone: +94 71 443 6897 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amuller at redhat.com Sun Jun 29 09:28:53 2014 From: amuller at redhat.com (Assaf Muller) Date: Sun, 29 Jun 2014 05:28:53 -0400 (EDT) Subject: [Rdo-list] Adding another public subnet in RDO In-Reply-To: References: Message-ID: <148652076.340147.1404034133720.JavaMail.zimbra@redhat.com> Hi Vimal, Answers inline. ----- Original Message ----- > Hi, > > I have a dedicated server which has 2 public ip ranges allotted to it by the > DC. I am trying out OpenStack RDO on this server (allinone install), and I > was able to assign one of the mentioned ranges (let's say > 173.xxx.xxx.144/29) and managed to use up all the available ips in this > range for a few vms. This floating-ip range is now accessible from outside, > and everything is fine. > > [root at mycloud ~(keystone_admin)]# neutron net-list > +--------------------------------------+---------+---------------------------------------------------------+ > | id | name | subnets | > +--------------------------------------+---------+---------------------------------------------------------+ > | 09c8da8e-79d7-49e1-9af8-c2a13a032040 | private | > | b7eeae38-682a-4397-8b3c-e3dee88527ab 10.0.0.0/24 | > | 31956556-c540-4676-9cd4-e618a4f93fc8 | public | > | 14d4b197-1121-4a4b-80b3-b8d80115f734 173.xxx.xxx.144/29 | > +--------------------------------------+---------+---------------------------------------------------------+ > > [root at yocloud ~(keystone_admin)]# neutron subnet-list > +--------------------------------------+----------------+--------------------+--------------------------------------------------------+ > | id | name | cidr | allocation_pools | > +--------------------------------------+----------------+--------------------+--------------------------------------------------------+ > | b7eeae38-682a-4397-8b3c-e3dee88527ab | private_subnet | 10.0.0.0/24 | > | {"start": "10.0.0.2", "end": "10.0.0.254"} | > | 14d4b197-1121-4a4b-80b3-b8d80115f734 | public_subnet | 173.xxx.xxx.144/29 | > | {"start": "173.xxx.xxx.147", "end": "173.xxx.xxx.150"} | > +--------------------------------------+----------------+--------------------+--------------------------------------------------------+ > > I am now looking to use the second public ip range for next vms and I am not > sure how to proceed. > > I tried to create a subnet (public_subnet2) inside "public" net for the new > ip block but fail to get it working. Neutron does not appear to know that it > has a few more free floating-ips available, and throws 'No more IP addresses > available on network'. > > Can someone point to the right direction? Is it not possible to add multiple > subnets inside a public network? When exactly do you fail? When I run neutron floatingip-create it successfully creates floating IPs from the first subnet, then when that runs out it starts creating FIPs on the second subnet. > > Regards, > Vimal > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > From vimal7370 at gmail.com Sun Jun 29 15:14:04 2014 From: vimal7370 at gmail.com (Vimal Kumar) Date: Sun, 29 Jun 2014 20:44:04 +0530 Subject: [Rdo-list] Adding another public subnet in RDO In-Reply-To: <148652076.340147.1404034133720.JavaMail.zimbra@redhat.com> References: <148652076.340147.1404034133720.JavaMail.zimbra@redhat.com> Message-ID: Hi Assaf, Thank you for responding. This was a single node install (packstack --allinone) with only 1 eth (eth0). So eth0 is already assigned a public ip address (which is later moved to br-ex as required during Openstack installation). The initial IP range allotted by Datacenter was: 173.xxx.xxx.144/29, so 173.xxx.xxx.146 is eth0. Now, the free ips that can be assigned are: 173.xxx.xxx.147-.150. These ips were used up by the few VMs (and a ovs router). So next, the DC assigned another block of ips which is of an entirely different subnet, **and making the second ip range work in a single node install was a pain for me** I asked about this particular error in the OpenStack list with no response, so maybe I was doing something really stupid. http://lists.openstack.org/pipermail/openstack/2014-June/007987.html .. and.. http://lists.openstack.org/pipermail/openstack/2014-June/007992.html Even after adding another public subnet (neutron subnet-create ..), I was unable to "interface-attach", with error saying that no free IPs are available, where as in reality: 1. private network has lot of ips available 2. First public subnet is full 3. Second subnet is already added in public net, and it has free ips available. >From logs it was evident that "Interface-attach" action was complaining about a public subnet being full (Shouldn't it simply create eth1 and assign a private IP? Why the heck should it complain about a public subnet being full?) I was hitting some kind of port-limit there but I do not recollect what I did to fix it (apparently I spent a couple of days testing things out so not sure what eventually fixed it). I finally added one ip from the second public subnet to br-ex, and then created a public subnet with the rest of the ips on that range with gateway set to this ip on br-ex and it worked. I hope this is how it can be done. Also, your blog on Openvswitch and Openstack networking is undoubtedly the best ever explanation of how networking works in OpenStack. I noted down every word and pic from your blog (on topics: ovs & gre) in my notebook, read and re-read them some 10-15 times and I can confidently say I have a better understanding on these things now than when I posted this query (a week ago, that is). Do keep writing, please! I successfully tested out a 3-node OpenStack install earlier today, and your notes on GRE helped me in troubleshooting like a pro :-) Regards, Vimal On Sun, Jun 29, 2014 at 2:58 PM, Assaf Muller wrote: > Hi Vimal, > > Answers inline. > > ----- Original Message ----- > > Hi, > > > > I have a dedicated server which has 2 public ip ranges allotted to it by > the > > DC. I am trying out OpenStack RDO on this server (allinone install), and > I > > was able to assign one of the mentioned ranges (let's say > > 173.xxx.xxx.144/29) and managed to use up all the available ips in this > > range for a few vms. This floating-ip range is now accessible from > outside, > > and everything is fine. > > > > [root at mycloud ~(keystone_admin)]# neutron net-list > > > +--------------------------------------+---------+---------------------------------------------------------+ > > | id | name | subnets | > > > +--------------------------------------+---------+---------------------------------------------------------+ > > | 09c8da8e-79d7-49e1-9af8-c2a13a032040 | private | > > | b7eeae38-682a-4397-8b3c-e3dee88527ab 10.0.0.0/24 | > > | 31956556-c540-4676-9cd4-e618a4f93fc8 | public | > > | 14d4b197-1121-4a4b-80b3-b8d80115f734 173.xxx.xxx.144/29 | > > > +--------------------------------------+---------+---------------------------------------------------------+ > > > > [root at yocloud ~(keystone_admin)]# neutron subnet-list > > > +--------------------------------------+----------------+--------------------+--------------------------------------------------------+ > > | id | name | cidr | allocation_pools | > > > +--------------------------------------+----------------+--------------------+--------------------------------------------------------+ > > | b7eeae38-682a-4397-8b3c-e3dee88527ab | private_subnet | 10.0.0.0/24 | > > | {"start": "10.0.0.2", "end": "10.0.0.254"} | > > | 14d4b197-1121-4a4b-80b3-b8d80115f734 | public_subnet | > 173.xxx.xxx.144/29 | > > | {"start": "173.xxx.xxx.147", "end": "173.xxx.xxx.150"} | > > > +--------------------------------------+----------------+--------------------+--------------------------------------------------------+ > > > > I am now looking to use the second public ip range for next vms and I am > not > > sure how to proceed. > > > > I tried to create a subnet (public_subnet2) inside "public" net for the > new > > ip block but fail to get it working. Neutron does not appear to know > that it > > has a few more free floating-ips available, and throws 'No more IP > addresses > > available on network'. > > > > Can someone point to the right direction? Is it not possible to add > multiple > > subnets inside a public network? > > When exactly do you fail? When I run neutron floatingip-create network> > it successfully creates floating IPs from the first subnet, then when that > runs > out it starts creating FIPs on the second subnet. > > > > > Regards, > > Vimal > > > > _______________________________________________ > > Rdo-list mailing list > > Rdo-list at redhat.com > > https://www.redhat.com/mailman/listinfo/rdo-list > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amuller at redhat.com Sun Jun 29 15:36:27 2014 From: amuller at redhat.com (Assaf Muller) Date: Sun, 29 Jun 2014 11:36:27 -0400 (EDT) Subject: [Rdo-list] Adding another public subnet in RDO In-Reply-To: References: <148652076.340147.1404034133720.JavaMail.zimbra@redhat.com> Message-ID: <1108378514.356912.1404056187459.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hi Assaf, > > Thank you for responding. > > This was a single node install (packstack --allinone) with only 1 eth > (eth0). So eth0 is already assigned a public ip address (which is later > moved to br-ex as required during Openstack installation). The initial IP > range allotted by Datacenter was: 173.xxx.xxx.144/29, so 173.xxx.xxx.146 is > eth0. > > Now, the free ips that can be assigned are: 173.xxx.xxx.147-.150. These ips > were used up by the few VMs (and a ovs router). So next, the DC assigned > another block of ips which is of an entirely different subnet, **and making > the second ip range work in a single node install was a pain for me** > > I asked about this particular error in the OpenStack list with no response, > so maybe I was doing something really stupid. > > http://lists.openstack.org/pipermail/openstack/2014-June/007987.html .. > and.. > http://lists.openstack.org/pipermail/openstack/2014-June/007992.html > > Even after adding another public subnet (neutron subnet-create ..), I was > unable to "interface-attach", with error saying that no free IPs are > available, where as in reality: 1. private network has lot of ips available > 2. First public subnet is full 3. Second subnet is already added in public > net, and it has free ips available. > > From logs it was evident that "Interface-attach" action was complaining > about a public subnet being full (Shouldn't it simply create eth1 and > assign a private IP? Why the heck should it complain about a public subnet > being full?) > > I was hitting some kind of port-limit there but I do not recollect what I > did to fix it (apparently I spent a couple of days testing things out so > not sure what eventually fixed it). > > I finally added one ip from the second public subnet to br-ex, and then > created a public subnet with the rest of the ips on that range with gateway > set to this ip on br-ex and it worked. I hope this is how it can be done. > I'm glad it works now. > Also, your blog on Openvswitch and Openstack networking is undoubtedly the > best ever explanation of how networking works in OpenStack. I noted down > every word and pic from your blog (on topics: ovs & gre) in my notebook, > read and re-read them some 10-15 times and I can confidently say I have a > better understanding on these things now than when I posted this query (a > week ago, that is). Do keep writing, please! > Wow, thank you :) I hope I can keep writing around a post a month. > I successfully tested out a 3-node OpenStack install earlier today, and > your notes on GRE helped me in troubleshooting like a pro :-) > > Regards, > Vimal > > On Sun, Jun 29, 2014 at 2:58 PM, Assaf Muller wrote: > > > Hi Vimal, > > > > Answers inline. > > > > ----- Original Message ----- > > > Hi, > > > > > > I have a dedicated server which has 2 public ip ranges allotted to it by > > the > > > DC. I am trying out OpenStack RDO on this server (allinone install), and > > I > > > was able to assign one of the mentioned ranges (let's say > > > 173.xxx.xxx.144/29) and managed to use up all the available ips in this > > > range for a few vms. This floating-ip range is now accessible from > > outside, > > > and everything is fine. > > > > > > [root at mycloud ~(keystone_admin)]# neutron net-list > > > > > +--------------------------------------+---------+---------------------------------------------------------+ > > > | id | name | subnets | > > > > > +--------------------------------------+---------+---------------------------------------------------------+ > > > | 09c8da8e-79d7-49e1-9af8-c2a13a032040 | private | > > > | b7eeae38-682a-4397-8b3c-e3dee88527ab 10.0.0.0/24 | > > > | 31956556-c540-4676-9cd4-e618a4f93fc8 | public | > > > | 14d4b197-1121-4a4b-80b3-b8d80115f734 173.xxx.xxx.144/29 | > > > > > +--------------------------------------+---------+---------------------------------------------------------+ > > > > > > [root at yocloud ~(keystone_admin)]# neutron subnet-list > > > > > +--------------------------------------+----------------+--------------------+--------------------------------------------------------+ > > > | id | name | cidr | allocation_pools | > > > > > +--------------------------------------+----------------+--------------------+--------------------------------------------------------+ > > > | b7eeae38-682a-4397-8b3c-e3dee88527ab | private_subnet | 10.0.0.0/24 | > > > | {"start": "10.0.0.2", "end": "10.0.0.254"} | > > > | 14d4b197-1121-4a4b-80b3-b8d80115f734 | public_subnet | > > 173.xxx.xxx.144/29 | > > > | {"start": "173.xxx.xxx.147", "end": "173.xxx.xxx.150"} | > > > > > +--------------------------------------+----------------+--------------------+--------------------------------------------------------+ > > > > > > I am now looking to use the second public ip range for next vms and I am > > not > > > sure how to proceed. > > > > > > I tried to create a subnet (public_subnet2) inside "public" net for the > > new > > > ip block but fail to get it working. Neutron does not appear to know > > that it > > > has a few more free floating-ips available, and throws 'No more IP > > addresses > > > available on network'. > > > > > > Can someone point to the right direction? Is it not possible to add > > multiple > > > subnets inside a public network? > > > > When exactly do you fail? When I run neutron floatingip-create > network> > > it successfully creates floating IPs from the first subnet, then when that > > runs > > out it starts creating FIPs on the second subnet. > > > > > > > > Regards, > > > Vimal > > > > > > _______________________________________________ > > > Rdo-list mailing list > > > Rdo-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/rdo-list > > > > > > From adam.huffman at gmail.com Sun Jun 29 21:41:59 2014 From: adam.huffman at gmail.com (Adam Huffman) Date: Sun, 29 Jun 2014 22:41:59 +0100 Subject: [Rdo-list] Keystone w/Apache MySQL problem Message-ID: I'm in the middle of changing my Icehouse Keystone to use Apache with SSL. After implementing this change, I'm seeing a strange MySQL error when I submit a keystone query e.g. 'endpoint-list': 2014-06-29 22:38:41.172 30284 TRACE keystone.common.wsgi OperationalError: (OperationalError) (1045, "Access denied for user 'keystone'@'localhost' (using password: YES)") None None The weird thing is that the user defined in /etc/keystone/keystone.conf is in fact 'keystone_admin', as created when this cloud was setup originally using RDO. From where is it picking up that username? I created a new MySQL user 'keystone' with the same privileges as 'keystone_admin' but that didn't make any difference. Adam From avattathil at gmail.com Sun Jun 29 23:05:09 2014 From: avattathil at gmail.com (Anthony Vattathil) Date: Sun, 29 Jun 2014 16:05:09 -0700 Subject: [Rdo-list] Keystone w/Apache MySQL problem In-Reply-To: References: Message-ID: Adam, Look at the keystone.conf search for connection parameter. Verify that you can login directly into mysql using those credentials and that you can access the database with that user. Also another thing make sure that the upgrade didn't put a default entry above the connection string. Hope that helps --Tony tonyv at redhat.com On Sunday, June 29, 2014, Adam Huffman wrote: > I'm in the middle of changing my Icehouse Keystone to use Apache with > SSL. After implementing this change, I'm seeing a strange MySQL error > when I submit a keystone query e.g. 'endpoint-list': > > 2014-06-29 22:38:41.172 30284 TRACE keystone.common.wsgi > OperationalError: (OperationalError) (1045, "Access denied for user > 'keystone'@'localhost' (using password: YES)") None None > > The weird thing is that the user defined in > /etc/keystone/keystone.conf is in fact 'keystone_admin', as created > when this cloud was setup originally using RDO. From where is it > picking up that username? > > I created a new MySQL user 'keystone' with the same privileges as > 'keystone_admin' but that didn't make any difference. > > Adam > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.huffman at gmail.com Mon Jun 30 10:24:57 2014 From: adam.huffman at gmail.com (Adam Huffman) Date: Mon, 30 Jun 2014 11:24:57 +0100 Subject: [Rdo-list] Keystone w/Apache MySQL problem In-Reply-To: References: Message-ID: Hi Anthony, Yes, the credentials in keystone.conf do work. As I say, the problem is that Keystone doesn't seem to be using those credentials now I've converted it to use Apache/mod_wsgi. The username it's using is different, and it may be the password it's using is different. What's not clear to me is where it's picking up those non-working credentials. Cheers, Adam On Mon, Jun 30, 2014 at 12:05 AM, Anthony Vattathil wrote: > Adam, > > Look at the keystone.conf search for connection parameter. > > Verify that you can login directly into mysql using those credentials and > that you can access the database with that user. > > Also another thing make sure that the upgrade didn't put a default entry > above the connection string. > > > Hope that helps > --Tony > > tonyv at redhat.com > > > On Sunday, June 29, 2014, Adam Huffman wrote: >> >> I'm in the middle of changing my Icehouse Keystone to use Apache with >> SSL. After implementing this change, I'm seeing a strange MySQL error >> when I submit a keystone query e.g. 'endpoint-list': >> >> 2014-06-29 22:38:41.172 30284 TRACE keystone.common.wsgi >> OperationalError: (OperationalError) (1045, "Access denied for user >> 'keystone'@'localhost' (using password: YES)") None None >> >> The weird thing is that the user defined in >> /etc/keystone/keystone.conf is in fact 'keystone_admin', as created >> when this cloud was setup originally using RDO. From where is it >> picking up that username? >> >> I created a new MySQL user 'keystone' with the same privileges as >> 'keystone_admin' but that didn't make any difference. >> >> Adam >> >> _______________________________________________ >> Rdo-list mailing list >> Rdo-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rdo-list From rbowen at redhat.com Mon Jun 30 14:22:51 2014 From: rbowen at redhat.com (Rich Bowen) Date: Mon, 30 Jun 2014 10:22:51 -0400 Subject: [Rdo-list] Fwd: [OpenStack Marketing] OpenStack Paris Summit Hotel Room Block In-Reply-To: <576E2DDF-6BAF-4164-A83E-A191C5002686@openstack.org> References: <576E2DDF-6BAF-4164-A83E-A191C5002686@openstack.org> Message-ID: <53B172BB.3020805@redhat.com> FYI - If you're planning to go to the OpenStack Paris Summit, the discount hotel room block is now available. Also, the call for papers will be available this week, so it's time to start thinking of what talk(s) you might submit. --Rich -------- Original Message -------- Subject: [OpenStack Marketing] OpenStack Paris Summit Hotel Room Block Date: Mon, 30 Jun 2014 10:03:59 -0400 From: Claire Massey To: marketing at lists.openstack.org Hi everyone, The hotel room block at Le Meridien is now open for the OpenStack Summit in Paris. You can reserve rooms via the direct URL here: https://www.openstack.org/summit/openstack-paris-summit-2014/hotels/ A second room block will soon be made available at the Hyatt Regency hotel. We will post the URL for that block as soon as it is available. Please stay tuned. The Call for Speakers portal will also be made available this week at openstack.org/summit . Please encourage your colleagues to submit a presentation for the Paris Summit. Thanks! Claire -------------- next part -------------- An HTML attachment was scrubbed... URL: