From rbowen at redhat.com Mon Nov 3 08:55:47 2014 From: rbowen at redhat.com (Rich Bowen) Date: Mon, 03 Nov 2014 09:55:47 +0100 Subject: [Rdo-list] RDO lunchtime meetup, Wednesday by the Red Hat booth Message-ID: <54574313.7020602@redhat.com> It appears that the best option that we have right now is to have our RDO lunchtime meetup in the corner by the Red Hat booth, on Wednesday at lunch time (12:30 - 13:50). Don't feel you need to stay the whole time, just come and go as convenient. I'll put up the RDO sign - see https://www.flickr.com/photos/rbowen/14061083888/ - so it should be easy to spot. -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://openstack.redhat.com/ From bderzhavets at hotmail.com Mon Nov 3 11:33:34 2014 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Mon, 3 Nov 2014 06:33:34 -0500 Subject: [Rdo-list] RDO Juno instances with LVMiSCSI cinder backend don't resume after Controller(LVM Storage) reboot In-Reply-To: References: , Message-ID: Please, view https://ask.openstack.org/en/question/52464/rdo-juno-instances-with-lvmiscsi-cinder-backend-dont-resume-after-controllerlvm-storage-reboot/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From pasik at iki.fi Mon Nov 3 18:58:39 2014 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Mon, 3 Nov 2014 20:58:39 +0200 Subject: [Rdo-list] rdo juno, packstack and multi-host swift Message-ID: <20141103185839.GX12451@reaktio.net> Hello, I found this: https://bugzilla.redhat.com/show_bug.cgi?id=1128303 "From RHOS-5+/RDO Icehouse it is no longer possible to install multi-host Swift." It seems support for CONFIG_SWIFT_STORAGE_HOSTS has been deprecated.. Two questions: - What's the reason for removing multi-host swift support from packstack? - What's the recommended way of doing multi-host swift installations with rdo? Thanks, -- Pasi From contact at progbau.de Tue Nov 4 03:34:50 2014 From: contact at progbau.de (Chris) Date: Tue, 4 Nov 2014 10:34:50 +0700 Subject: [Rdo-list] Second glance server Message-ID: <001901cff7e0$4dd826a0$e98873e0$@progbau.de> Hello, We use OpenStack in one of our DC locations (location A). Now we want to have compute nodes in other locations (location B). In location B we want to have just compute nodes and an additional glance server to prevent image transfers from location A to B. What is the best practice to have two glance servers in OpenStack and what configuration changes needs to be done to let the compute nodes just access the local glance server. Thank you! Cheers Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbowen at redhat.com Tue Nov 4 08:03:17 2014 From: rbowen at redhat.com (Rich Bowen) Date: Tue, 04 Nov 2014 09:03:17 +0100 Subject: [Rdo-list] November RDO Community Newsletter Message-ID: <54588845.5010200@redhat.com> Hi, and thanks for being part of the RDO community. Here's some of what's going on in the RDO world lately, including blog posts, meetups, and the OpenStack Summit in Paris. Quick links: * Quick Start - http://openstack.redhat.com/quickstart * RDO packages - https://repos.fedorapeople.org/repos/openstack/openstack-juno/ * RDO blog - http://rdoproject.org/blog * Open bugs - http://tm3.org/rdobugs-20141030 RDO Juno packages available OpenStack Juno released on October 16th, and it took us a few days to package it up for RDO. We're pleased to announce the availability of RDO packages for OpenStack Juno, for EL7 (RHEL7 and CentOS7) and Fedora 20. Fedora 21 is still in development and running RDO Juno on Fedora 21 is not recommended at this time. A separate announcement will be made when RDO Juno on Fedora 21 is ready. You can get started with RDO Juno via the process described in the Quickstart - http://openstack.redhat.com/Quickstart - and the various packages are available at https://rdo.fedorapeople.org/openstack-juno/ As always, if you have questions, you can bring them here, to the rdo-list mailing list, or to the IRC channel - #rdo on freenode.irc.net. Events This week, many of us are in Paris for the OpenStack 'Kilo' Summit, where the next version of OpenStack will be planned, and many OpenStack technical sessions will cover all aspects of running and developing OpenStack. If you're here in Paris, please drop by the Red Hat booth, at A1, to pick up your Red Hat cap and see demos of OpenStack and related projects. If you're interested in being more involved in the RDO project, join us for at lunch time on Wednesday in the corner by the Red Hat booth. where we'll be discussing how you can participate in packaging, documentation, and testing, among other things. We'd love to hear from you where we can improve and be more welcoming. Look for the RDO sign! And if you drop by today, we have just a few RDO tshirts left. If you're running OpenStack on RHEL, CentOS, or Fedora, the talks you're going to want to catch are listed at http://tm3.org/blog32 Several "must see" sessions are: The Open NFV Organization, Neutron, and OpenDaylight - https://openstacksummitnovember2014paris.sched.org/event/b985d5b656a13007c80f54253b675785 Heat Beyond the Basics - https://openstacksummitnovember2014paris.sched.org/event/34098661017d2fa0252f8b2b0324a516 "Not Invented Here is not an Option": The Importance of Cross-Community Collaboration - https://openstacksummitnovember2014paris.sched.org/event/422da7a1c8842e48447cb03f4157b7e7 OpenDaylight and OpenStack Developers - https://openstacksummitnovember2014paris.sched.org/event/7352eccc0268595ed2274d74a31aa345 Docker: All the OpenStack Services - https://openstacksummitnovember2014paris.sched.org/event/f5a9285d796767b04887eb7af5a3ff52 Meetups If you're not able to make it to Paris this week, remember that there are hundreds of OpenStack meetups every month, and we highlight a few of them every week on the rdo-list mailing list, as well as listing them on the RDO Events page at http://openstack.redhat.com/Events If you're running a Meetup, or attending one, we'd love to hear about it, so that we can help you get the word out. Add them to the events page, and drop me an email. Hangouts Unfortunately, we didn't manage to do a hangout in October, but we are planning to do one this month. If there's a particular topic that you'd like to see us do a hangout about, watch for a thread about this in the coming days on the rdo-list mailing list, where you can speak up. You can watch all of our past hangouts at https://openstack.redhat.com/Hangouts#Past_Hangouts Blog posts Each week, I post a roundup of the week's RDO/OpenStack blogs on the RDO blog at http://rdoproject.org/blog If you blog about RDO or OpenStack, and would like to be included in that update, please be sure to let me know. * Blog posts, week of September 29: http://tm3.org/blog47 * Blog posts, week of October 6: http://tm3.org/blog48 * Blog posts, week of October 13: http://tm3.org/blog49 * Blog posts, week of October 20: http://tm3.org/blog50 In Closing ... Once again, you can always keep up to date a variety of ways: * Follow us on Twitter - http://twitter.com/rdocommunity * Google+ - http://tm3.org/rdogplus * Facebook - http://facebook.com/rdocommunity * 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/ * IRC - #rdo on Freenode.irc.net Thanks again for being part of the RDO community! -- Rich Bowen, OpenStack Community Liaison rbowen at redhat.com http://openstack.redhat.com From kashyapc at fedoraproject.org Tue Nov 4 16:21:15 2014 From: kashyapc at fedoraproject.org (Kashyap Chamarthy) Date: Tue, 4 Nov 2014 17:21:15 +0100 Subject: [Rdo-list] [Test request] Fedora 21 Beta cloud images Message-ID: <20141104162115.GE5146@tesla.redhat.com> Heya, Fedora Project announced[1] the release of Fedora Beta. If you're an advanced tester, you might want to test out the cloud images[2][3] and see if they work okay in your OpenStack/RDO environment. Import into Glance: $ glance image-create --name f21-beta --is-public true \ --disk-format qcow2 --container-format bare \ < Fedora-Cloud-Base-20141029-21_Beta.x86_64.qcow2 Your test/workflow. [1] https://lists.fedoraproject.org/pipermail/devel/2014-November/203950.html [2] http://download.fedoraproject.org/pub/fedora/linux/releases/test/21-Beta/Cloud/Images/x86_64/Fedora-Cloud-Base-20141029-21_Beta.x86_64.raw.xz [3] http://download.fedoraproject.org/pub/fedora/linux/releases/test/21-Beta/Cloud/Images/x86_64/Fedora-Cloud-Base-20141029-21_Beta.x86_64.qcow2 -- /kashyap From pmyers at redhat.com Tue Nov 4 21:29:20 2014 From: pmyers at redhat.com (Perry Myers) Date: Tue, 04 Nov 2014 22:29:20 +0100 Subject: [Rdo-list] RDO lunchtime meetup, Wednesday by the Red Hat booth In-Reply-To: <54574313.7020602@redhat.com> References: <54574313.7020602@redhat.com> Message-ID: <54594530.4050902@redhat.com> On 11/03/2014 09:55 AM, Rich Bowen wrote: > It appears that the best option that we have right now is to have our > RDO lunchtime meetup in the corner by the Red Hat booth, on Wednesday at > lunch time (12:30 - 13:50). Don't feel you need to stay the whole time, > just come and go as convenient. > > I'll put up the RDO sign - see > https://www.flickr.com/photos/rbowen/14061083888/ - so it should be easy > to spot. Sounds like a plan. Looking forward to seeing folks tomorrow :) Cheers, Perry From ak at cloudssky.com Tue Nov 4 22:33:29 2014 From: ak at cloudssky.com (Arash Kaffamanesh) Date: Tue, 4 Nov 2014 23:33:29 +0100 Subject: [Rdo-list] [Test request] Fedora 21 Beta cloud images In-Reply-To: <20141104162115.GE5146@tesla.redhat.com> References: <20141104162115.GE5146@tesla.redhat.com> Message-ID: Hi Kashyap, Thanks for sharing. Added the fedora 21 qcow2 image to glance on RDO Juno 3 node install on CentOS7, fired up an instance, the instance came up after few seconds (like a docker container :-)) and I tried to install RDO Juno allinone on it and I'm getting: .... 20.0.0.7_nova.pp: [ DONE ] Applying 20.0.0.7_neutron.pp 20.0.0.7_neutron.pp: [ ERROR ] Applying Puppet manifests [ ERROR ] ERROR : Error appeared during Puppet run: 20.0.0.7_neutron.pp Notice: /Stage[main]/Main/Exec[neutron-db-manage upgrade]/returns: sqlalchemy.exc.OperationalError: (OperationalError) (1832, "Cannot change column 'l3_agent_id': used in a foreign key constraint 'routerl3agentbindings_ibfk_1'") 'ALTER TABLE routerl3agentbindings ADD CONSTRAINT pk_routerl3agentbindings PRIMARY KEY (router_id, l3_agent_id)' () You will find full trace in log /var/tmp/packstack/20141104-195148-LTIBnb/manifests/20.0.0.7_neutron.pp.log But the core services are running: [root at fedora21 novadocker]# pgrep -l nova 669 nova-cert 670 nova-scheduler 672 nova-consoleaut 676 nova-conductor 683 nova-novncproxy 716 nova-api 1311 nova-conductor 1314 nova-conductor 1354 nova-api 1355 nova-api 1454 nova-api 1455 nova-api 1474 nova-api 1475 nova-api 3927 nova-compute The next test which was important for me was docker, installed docker-io.x86_64 0:1.3.0-1.fc21, pulled my docker images (cloudssky/opencms-stack-cluster and the related mysql docker image), ran 4 containers and all works fine (the same is running on atomic host on top of havana). Pulled also the official Fedora 20 docker image and ran a container successfully and tried to install tomcat in that container, which didn't work somehow: [root at c94a67367bd3 /]# systemctl status tomcat.service Failed to get D-Bus connection: No connection to service manager. Installed tomcat 7 on Fedora 21 and it works fine. The last test was trying to install the nova-docker driver following [1], but nova-copmute doesn't work after changing the nova diver to nova-docker: [root at fedora21 novadocker]# systemctl status openstack-nova-compute ? openstack-nova-compute.service - OpenStack Nova Compute Server Loaded: loaded (/usr/lib/systemd/system/openstack-nova-compute.service; enabled) Active: failed (Result: start-limit) since Tue 2014-11-04 22:06:33 UTC; 13s ago Process: 4207 ExecStart=/usr/bin/nova-compute (code=exited, status=0/SUCCESS) Main PID: 4207 (code=exited, status=0/SUCCESS) Nov 04 22:06:33 fedora21.novalocal systemd[1]: openstack-nova-compute.service holdoff time over, scheduling restart. Nov 04 22:06:33 fedora21.novalocal systemd[1]: Stopping OpenStack Nova Compute Server... Nov 04 22:06:33 fedora21.novalocal systemd[1]: Starting OpenStack Nova Compute Server... Nov 04 22:06:33 fedora21.novalocal systemd[1]: start request repeated too quickly for openstack-nova-compute.service Nov 04 22:06:33 fedora21.novalocal systemd[1]: Failed to start OpenStack Nova Compute Server. journalctl gives me: -- -- Unit UNIT has begun starting up. Nov 04 22:23:02 fedora21.novalocal systemd[4906]: Received SIGRTMIN+24 from PID 4917 (kill). Nov 04 22:23:02 fedora21.novalocal systemd[4908]: pam_unix(systemd-user:session): session closed for user keystone Nov 04 22:23:02 fedora21.novalocal systemd[1]: Stopped User Manager for UID 163. -- Subject: Unit user at 163.service has finished shutting down -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- But I guess this is because keystone is not sourced due to the unfinished installation. [1] http://technodrone.blogspot.com/2014/10/nova-docker-on-juno.html Thanks, -arash On Tue, Nov 4, 2014 at 5:21 PM, Kashyap Chamarthy < kashyapc at fedoraproject.org> wrote: > Heya, > > Fedora Project announced[1] the release of Fedora Beta. > > If you're an advanced tester, you might want to test out the cloud > images[2][3] and see if they work okay in your OpenStack/RDO > environment. > > Import into Glance: > > $ glance image-create --name f21-beta --is-public true \ > --disk-format qcow2 --container-format bare \ > < Fedora-Cloud-Base-20141029-21_Beta.x86_64.qcow2 > > Your test/workflow. > > > [1] > https://lists.fedoraproject.org/pipermail/devel/2014-November/203950.html > [2] > http://download.fedoraproject.org/pub/fedora/linux/releases/test/21-Beta/Cloud/Images/x86_64/Fedora-Cloud-Base-20141029-21_Beta.x86_64.raw.xz > [3] > http://download.fedoraproject.org/pub/fedora/linux/releases/test/21-Beta/Cloud/Images/x86_64/Fedora-Cloud-Base-20141029-21_Beta.x86_64.qcow2 > > -- > /kashyap > > _______________________________________________ > 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 pasik at iki.fi Wed Nov 5 08:42:40 2014 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Wed, 5 Nov 2014 10:42:40 +0200 Subject: [Rdo-list] rdo juno, packstack and multi-host swift In-Reply-To: <20141103185839.GX12451@reaktio.net> References: <20141103185839.GX12451@reaktio.net> Message-ID: <20141105084240.GZ12451@reaktio.net> On Mon, Nov 03, 2014 at 08:58:39PM +0200, Pasi K?rkk?inen wrote: > Hello, > > I found this: > https://bugzilla.redhat.com/show_bug.cgi?id=1128303 > > "From RHOS-5+/RDO Icehouse it is no longer possible to install multi-host Swift." > > It seems support for CONFIG_SWIFT_STORAGE_HOSTS has been deprecated.. > > Two questions: > - What's the reason for removing multi-host swift support from packstack? > - What's the recommended way of doing multi-host swift installations with rdo? > Any comments? Sure I can configure swift manually.. but I was surprised that packstack doesn't support multi-host swift, so I'm wondering if there are other tools/scripts out there to do the job. Thanks, -- Pasi From kchamart at redhat.com Wed Nov 5 09:39:31 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Wed, 5 Nov 2014 10:39:31 +0100 Subject: [Rdo-list] [Test request] Fedora 21 Beta cloud images In-Reply-To: References: <20141104162115.GE5146@tesla.redhat.com> Message-ID: <20141105093931.GA26928@tesla.redhat.com> On Tue, Nov 04, 2014 at 11:33:29PM +0100, Arash Kaffamanesh wrote: > Hi Kashyap, Hi, [/me traveling at the moment, so might not be very responsive on the lists.] > Thanks for sharing. > > > Added the fedora 21 qcow2 image to glance on RDO Juno 3 node install on > CentOS7, fired up an instance, the instance came up after few seconds (like > a docker container :-)) and I tried to install RDO Juno allinone on it and > I'm getting: I think this was caught by one of RDO CI engineers, and I guess is being still investigated. > > .... > 20.0.0.7_nova.pp: [ DONE ] > Applying 20.0.0.7_neutron.pp > 20.0.0.7_neutron.pp: [ ERROR ] > Applying Puppet manifests [ ERROR ] > > ERROR : Error appeared during Puppet run: 20.0.0.7_neutron.pp > Notice: /Stage[main]/Main/Exec[neutron-db-manage upgrade]/returns: > sqlalchemy.exc.OperationalError: (OperationalError) (1832, "Cannot change > column 'l3_agent_id': used in a foreign key constraint > 'routerl3agentbindings_ibfk_1'") 'ALTER TABLE routerl3agentbindings ADD > CONSTRAINT pk_routerl3agentbindings PRIMARY KEY (router_id, l3_agent_id)' () > You will find full trace in log > /var/tmp/packstack/20141104-195148-LTIBnb/manifests/20.0.0.7_neutron.pp.log > > But the core services are running: > > [root at fedora21 novadocker]# pgrep -l nova > 669 nova-cert > 670 nova-scheduler > 672 nova-consoleaut > 676 nova-conductor > 683 nova-novncproxy > 716 nova-api > 1311 nova-conductor > 1314 nova-conductor > 1354 nova-api > 1355 nova-api > 1454 nova-api > 1455 nova-api > 1474 nova-api > 1475 nova-api > 3927 nova-compute > > The next test which was important for me was docker, installed > docker-io.x86_64 0:1.3.0-1.fc21, pulled my docker images > (cloudssky/opencms-stack-cluster and the related mysql docker image), ran 4 > containers and all works fine (the same is running on atomic host on top of > havana). > > Pulled also the official Fedora 20 docker image and ran a container > successfully and tried to install tomcat in that container, which didn't > work somehow: > > [root at c94a67367bd3 /]# systemctl status tomcat.service > Failed to get D-Bus connection: No connection to service manager. > > Installed tomcat 7 on Fedora 21 and it works fine. > > The last test was trying to install the nova-docker driver following [1], > but nova-copmute doesn't work after changing the nova diver to nova-docker: > > [root at fedora21 novadocker]# systemctl status openstack-nova-compute > ? openstack-nova-compute.service - OpenStack Nova Compute Server > Loaded: loaded (/usr/lib/systemd/system/openstack-nova-compute.service; > enabled) > Active: failed (Result: start-limit) since Tue 2014-11-04 22:06:33 UTC; > 13s ago > Process: 4207 ExecStart=/usr/bin/nova-compute (code=exited, > status=0/SUCCESS) > Main PID: 4207 (code=exited, status=0/SUCCESS) > > Nov 04 22:06:33 fedora21.novalocal systemd[1]: > openstack-nova-compute.service holdoff time over, scheduling restart. > Nov 04 22:06:33 fedora21.novalocal systemd[1]: Stopping OpenStack Nova > Compute Server... > Nov 04 22:06:33 fedora21.novalocal systemd[1]: Starting OpenStack Nova > Compute Server... > Nov 04 22:06:33 fedora21.novalocal systemd[1]: start request repeated too > quickly for openstack-nova-compute.service > Nov 04 22:06:33 fedora21.novalocal systemd[1]: Failed to start OpenStack > Nova Compute Server. > > journalctl gives me: > > -- > -- Unit UNIT has begun starting up. > Nov 04 22:23:02 fedora21.novalocal systemd[4906]: Received SIGRTMIN+24 from > PID 4917 (kill). > Nov 04 22:23:02 fedora21.novalocal systemd[4908]: > pam_unix(systemd-user:session): session closed for user keystone > Nov 04 22:23:02 fedora21.novalocal systemd[1]: Stopped User Manager for UID > 163. > -- Subject: Unit user at 163.service has finished shutting down > -- Defined-By: systemd > -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel > -- > > But I guess this is because keystone is not sourced due to the unfinished > installation. If you're able to reproduce this consitently, please file a bug with clear details (bonus points for a reproducer). Thanks for testing! -- /kashyap > [1] http://technodrone.blogspot.com/2014/10/nova-docker-on-juno.html > > Thanks, > -arash > > On Tue, Nov 4, 2014 at 5:21 PM, Kashyap Chamarthy < > kashyapc at fedoraproject.org> wrote: > > > Heya, > > > > Fedora Project announced[1] the release of Fedora Beta. > > > > If you're an advanced tester, you might want to test out the cloud > > images[2][3] and see if they work okay in your OpenStack/RDO > > environment. > > > > Import into Glance: > > > > $ glance image-create --name f21-beta --is-public true \ > > --disk-format qcow2 --container-format bare \ > > < Fedora-Cloud-Base-20141029-21_Beta.x86_64.qcow2 > > > > Your test/workflow. > > > > > > [1] > > https://lists.fedoraproject.org/pipermail/devel/2014-November/203950.html > > [2] > > http://download.fedoraproject.org/pub/fedora/linux/releases/test/21-Beta/Cloud/Images/x86_64/Fedora-Cloud-Base-20141029-21_Beta.x86_64.raw.xz > > [3] > > http://download.fedoraproject.org/pub/fedora/linux/releases/test/21-Beta/Cloud/Images/x86_64/Fedora-Cloud-Base-20141029-21_Beta.x86_64.qcow2 > > -- /kashyap From apevec at gmail.com Wed Nov 5 09:45:04 2014 From: apevec at gmail.com (Alan Pevec) Date: Wed, 5 Nov 2014 10:45:04 +0100 Subject: [Rdo-list] [Test request] Fedora 21 Beta cloud images In-Reply-To: <20141105093931.GA26928@tesla.redhat.com> References: <20141104162115.GE5146@tesla.redhat.com> <20141105093931.GA26928@tesla.redhat.com> Message-ID: >> Notice: /Stage[main]/Main/Exec[neutron-db-manage upgrade]/returns: >> sqlalchemy.exc.OperationalError: (OperationalError) (1832, "Cannot change column 'l3_agent_id': used in a foreign key constraint 'routerl3agentbindings_ibfk_1'") 'ALTER TABLE routerl3agentbindings ADD CONSTRAINT pk_routerl3agentbindings PRIMARY KEY (router_id, l3_agent_id)' () > I think this was caught by one of RDO CI engineers, and I guess is being > still investigated. https://bugs.launchpad.net/neutron/+bug/1384555 From Yaniv.Kaul at emc.com Wed Nov 5 11:39:18 2014 From: Yaniv.Kaul at emc.com (Kaul, Yaniv) Date: Wed, 5 Nov 2014 06:39:18 -0500 Subject: [Rdo-list] Disabling and enabling OpenStack Message-ID: <648473255763364B961A02AC3BE1060D03C7B58868@MX19A.corp.emc.com> Naively, I've executed: root at lgdrm1499 ~]# openstack-service list |xargs openstack-service disable rm '/etc/systemd/system/multi-user.target.wants/openstack-keystone.service' rm '/etc/systemd/system/multi-user.target.wants/openstack-cinder-api.service' rm '/etc/systemd/system/multi-user.target.wants/openstack-cinder-volume.service' rm '/etc/systemd/system/multi-user.target.wants/openstack-cinder-scheduler.service' rm '/etc/systemd/system/multi-user.target.wants/openstack-glance-registry.service' rm '/etc/systemd/system/multi-user.target.wants/openstack-glance-api.service' rm '/etc/systemd/system/multi-user.target.wants/openstack-nova-api.service' rm '/etc/systemd/system/multi-user.target.wants/openstack-nova-novncproxy.service' rm '/etc/systemd/system/multi-user.target.wants/openstack-nova-consoleauth.service' rm '/etc/systemd/system/multi-user.target.wants/openstack-nova-scheduler.service' rm '/etc/systemd/system/multi-user.target.wants/openstack-nova-conductor.service' rm '/etc/systemd/system/multi-user.target.wants/openstack-nova-compute.service' rm '/etc/systemd/system/multi-user.target.wants/openstack-nova-network.service' rm '/etc/systemd/system/multi-user.target.wants/openstack-nova-cert.service' rm '/etc/systemd/system/openstack-cinder-volume.service.requires/openstack-losetup.service' This was fine and dandy, but now: 1. I can't stop the openstack services: [root at lgdrm1499 ~]# openstack-service list |xargs openstack-service stop Too few arguments. [root at lgdrm1499 ~]# openstack-service list [root at lgdrm1499 ~] [root at lgdrm1499 ~]# openstack-status == Nova services == openstack-nova-api: active (disabled on boot) openstack-nova-cert: active (disabled on boot) openstack-nova-compute: active (disabled on boot) openstack-nova-network: active (disabled on boot) openstack-nova-scheduler: active (disabled on boot) openstack-nova-volume: inactive (disabled on boot) openstack-nova-conductor: active (disabled on boot) == Glance services == openstack-glance-api: active (disabled on boot) openstack-glance-registry: active (disabled on boot) == Keystone service == openstack-keystone: active (disabled on boot) == Horizon service == openstack-dashboard: active == Cinder services == openstack-cinder-api: active (disabled on boot) openstack-cinder-scheduler: active (disabled on boot) openstack-cinder-volume: active (disabled on boot) openstack-cinder-backup: inactive (disabled on boot) == Support services == libvirtd: active dbus: active rabbitmq-server: active memcached: active == Keystone users == Warning keystonerc not sourced 2. I can't enable them (for the same reason above). Any better ideas how can I enable/disable OpenStack? Y. From ak at cloudssky.com Wed Nov 5 12:30:42 2014 From: ak at cloudssky.com (Arash Kaffamanesh) Date: Wed, 5 Nov 2014 13:30:42 +0100 Subject: [Rdo-list] RDO-related Meetups in the coming week (October 6, 2014) In-Reply-To: <54368B9C.3030307@rcbowen.com> References: <543301D2.8030400@rcbowen.com> <54368B9C.3030307@rcbowen.com> Message-ID: Hi Rich, We finally got the date for our OpenStack X Meetup on December 11th in Cologne: http://www.meetup.com/OpenStack-X/ That will be a whole day workshop beginning with the RDO hands-on deployment workshop. I tried to get someone from Red Hat to provide a presentation about RHOSP, but as you know on that week there is the "OpenStack Tiger Team" training in Paris and we decided to provide a dedicated meetup for RHOSP and more next year in February. In addition we'll have a praxis workshop on Cologne IT Summit_ on November 24th, where I'm going to show the power of RDO in action at 15:30: http://www.cologne-it-summit.de/programm-2014/ (the page above is unfortunately in German). By the way, I borrowed the RDO Community logo shamelessly and placed our lovely RDO Community as our sponsor on our meetup page, hope that's ok: http://www.meetup.com/OpenStack-X/sponsors/ Enjoy your OpenStack summit! -Thanks, Arash On Thu, Oct 9, 2014 at 3:20 PM, Rich Bowen wrote: > > On 10/09/2014 07:50 AM, Arash Kaffamanesh wrote: > >> Hi Rich, >> >> On October 20th there is this OpenStack Meetup in Frankfurt / Germany: >> http://www.meetup.com/OpenStack-MeetUp-Frankfurt/events/194344152/ >> And I'm going to have a talk about Docker On OpenStack (RDO Juno M3 >> Release) and its eCosystem. >> The final agenda will be announced next week. >> >> There is another OpenStack Meetup in Cologne which is organized by me, >> the OpenStack X Cologne Meetup Group: >> http://www.meetup.com/OpenStack-X/ >> >> Our next meetup will be in December and the agenda is being discussed on >> our meetup page and I'm planing to provide an hands on workshop for RDO >> Packstack and Foreman and possibly live stream the session as an hangout. >> > > > Thanks. I'm adding these to the events page, and look forward to more > information about the December event. > > > -- > Rich Bowen - rbowen at rcbowen.com - @rbowen > http://apachecon.com/ - @apachecon > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrunge at redhat.com Wed Nov 5 13:26:43 2014 From: mrunge at redhat.com (Matthias Runge) Date: Wed, 05 Nov 2014 14:26:43 +0100 Subject: [Rdo-list] Disabling and enabling OpenStack In-Reply-To: <648473255763364B961A02AC3BE1060D03C7B58868@MX19A.corp.emc.com> References: <648473255763364B961A02AC3BE1060D03C7B58868@MX19A.corp.emc.com> Message-ID: <545A2593.3000004@redhat.com> On 05/11/14 12:39, Kaul, Yaniv wrote: > Naively, I've executed: > root at lgdrm1499 ~]# openstack-service list |xargs openstack-service disable > rm '/etc/systemd/system/multi-user.target.wants/openstack-keystone.service' I found systemctl enable openstack-* very useful. The same works for start/stop/disable. Note, as always, neutron is different, since it's not prefixed with openstack-: systemctl stop neutron-* Matthias -- Matthias Runge From Yaniv.Kaul at emc.com Wed Nov 5 13:36:49 2014 From: Yaniv.Kaul at emc.com (Kaul, Yaniv) Date: Wed, 5 Nov 2014 08:36:49 -0500 Subject: [Rdo-list] Disabling and enabling OpenStack In-Reply-To: <545A2593.3000004@redhat.com> References: <648473255763364B961A02AC3BE1060D03C7B58868@MX19A.corp.emc.com> <545A2593.3000004@redhat.com> Message-ID: <648473255763364B961A02AC3BE1060D03C7B588A8@MX19A.corp.emc.com> > -----Original Message----- > From: rdo-list-bounces at redhat.com [mailto:rdo-list-bounces at redhat.com] On > Behalf Of Matthias Runge > Sent: Wednesday, November 05, 2014 3:27 PM > To: rdo-list at redhat.com > Subject: Re: [Rdo-list] Disabling and enabling OpenStack > > On 05/11/14 12:39, Kaul, Yaniv wrote: > > Naively, I've executed: > > root at lgdrm1499 ~]# openstack-service list |xargs openstack-service > > disable rm '/etc/systemd/system/multi-user.target.wants/openstack- > keystone.service' > > I found systemctl enable openstack-* > very useful. > The same works for start/stop/disable. [root at lgdrm1499 ~]# systemctl enable openstack-* Failed to issue method call: No such file or directory [root at lgdrm1499 ~]# systemctl |grep openstack [root at lgdrm1499 ~]# Perhaps I should not have used 'openstack-service disable' in the first place, as I suspect it might have erased them required files? Y. > > Note, as always, neutron is different, since it's not prefixed with > openstack-: > systemctl stop neutron-* > > Matthias > -- > Matthias Runge > > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list From kchamart at redhat.com Wed Nov 5 14:16:02 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Wed, 5 Nov 2014 15:16:02 +0100 Subject: [Rdo-list] Follow up from RDO meetup at Summit: Fedora Project Contributor Agreement Message-ID: <20141105141602.GC26928@tesla.redhat.com> [Copying Matthew Miller from Fedora Project for any other context that he might want to add.] This topic came up at the RDO meetup in Paris OpenStack summit, raised by Tim Bell from CERN. Alan Pevec requested to follow it up with a URL here. Fedora project now has called Fedora Project Contributor Agreement (FPCA) replacing the old Fedora Individual Contributor License Agreement. Here is the official wiki page from the Fedora Project: https://fedoraproject.org/wiki/Legal:Fedora_Project_Contributor_Agreement Quoting a couple of items from the Wiki page: "Q. Why did you change the name from ICLA to FPCA? A. The new text is not really a "Contributor License Agreement" in the traditional sense, as that sort of agreement usually involves copyright assignment and an abandonment of rights to a project. The FPCA exists for one main reason: to ensure that contributions to Fedora have acceptable licensing terms. We chose a name that did not use "CLA" to avoid confusion and to mark it as a distinctly specific license. Q. The FPCA defines "default licenses" of MIT for code, and Creative Commons Attribution ShareAlike 3.0 Unported for content, why not $OTHER_LICENSE? A. These licenses were chosen because of their widespread use and compatibility with most other Free licenses." More details and the exact FPCA text is in the above wiki page (at the bottom). -- /kashyap From mattdm at fedoraproject.org Wed Nov 5 14:48:23 2014 From: mattdm at fedoraproject.org (Matthew Miller) Date: Wed, 5 Nov 2014 09:48:23 -0500 Subject: [Rdo-list] Follow up from RDO meetup at Summit: Fedora Project Contributor Agreement In-Reply-To: <20141105141602.GC26928@tesla.redhat.com> References: <20141105141602.GC26928@tesla.redhat.com> Message-ID: <20141105144823.GA7687@mattdm.org> On Wed, Nov 05, 2014 at 03:16:02PM +0100, Kashyap Chamarthy wrote: > [Copying Matthew Miller from Fedora Project for any other context that > he might want to add.] > This topic came up at the RDO meetup in Paris OpenStack summit, raised > by Tim Bell from CERN. Alan Pevec requested to follow it up with a URL > here. I'd be happy to add context but I'm not sure what the concern is. Probably more advanced topics need to go to Legal. -- Matthew Miller Fedora Project Leader From Brian.Afshar at emc.com Wed Nov 5 17:07:58 2014 From: Brian.Afshar at emc.com (Afshar, Brian) Date: Wed, 5 Nov 2014 12:07:58 -0500 Subject: [Rdo-list] RDO Mailing list Message-ID: <9E8EE5E176B2BD49913B2F69B369AD830210BF89D1@MX02A.corp.emc.com> This email is intended to include my email address as instructed. Brian S. Afshar Pr. Solutions Engineer EMC Corporation [cid:image001.png at 01CFF8D7.FC0448B0][cid:image002.png at 01CFF8D7.FC0448B0] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 10336 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 15371 bytes Desc: image002.png URL: From apevec at gmail.com Thu Nov 6 12:43:55 2014 From: apevec at gmail.com (Alan Pevec) Date: Thu, 6 Nov 2014 13:43:55 +0100 Subject: [Rdo-list] RDO Introduction For Contributors slides from RDO Summit meetup Message-ID: Hi all, here are the slides I presented during RDO meetup: http://apevec.github.io/rdo-intro.html There will be more documentation coming as we execute Next Steps. Cheers, Alan From whayutin at redhat.com Thu Nov 6 13:29:45 2014 From: whayutin at redhat.com (whayutin) Date: Thu, 06 Nov 2014 08:29:45 -0500 Subject: [Rdo-list] RDO Introduction For Contributors slides from RDO Summit meetup In-Reply-To: References: Message-ID: <1415280585.3563.0.camel@localhost.localdomain> On Thu, 2014-11-06 at 13:43 +0100, Alan Pevec wrote: > Hi all, > > here are the slides I presented during RDO meetup: > http://apevec.github.io/rdo-intro.html > Well done! Thanks for sharing the slides. > There will be more documentation coming as we execute Next Steps. > > Cheers, > Alan > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list From rvykunta at zenoss.com Thu Nov 6 15:24:27 2014 From: rvykunta at zenoss.com (Rama Vykunta) Date: Thu, 6 Nov 2014 09:24:27 -0600 Subject: [Rdo-list] Neutron: Configuration and usage patterns Message-ID: OpenStack users and administrators, I would like to get your insight into popular neutron features/configurations from a service provider and/or large scale deployment perspective. What do you use in your openstack environment? anything in particular that stands out across multiple usage scenarios? Any insight that you can provide would be helpful. Regards Regards. -Rama. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kchamart at redhat.com Thu Nov 6 16:44:26 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Thu, 6 Nov 2014 17:44:26 +0100 Subject: [Rdo-list] Neutron: Configuration and usage patterns In-Reply-To: References: Message-ID: <20141106164426.GA19448@tesla> On Thu, Nov 06, 2014 at 09:24:27AM -0600, Rama Vykunta wrote: > OpenStack users and administrators, I would like to get your insight > into popular neutron features/configurations from a service provider > and/or large scale deployment perspective. What do you use in your > openstack environment? anything in particular that stands out across > multiple usage scenarios? Any insight that you can provide would be > helpful. This is a very broad and generic question, there's lot of information available in the OpenStack upstream Neutron documentation and elsewhere on the interwebs for deployment scenarios with Neutron and its quirks. And, if you haven't already stumbled across, you might want to begin by exploring this: http://docs.openstack.org/havana/install-guide/install/yum/content/neutron-deploy-use-cases.html If you have more specific questions, then it's more likely you'll get a more meaningful reponse. -- /kashyap From ludovic.delafontaine at epfl.ch Fri Nov 7 08:35:39 2014 From: ludovic.delafontaine at epfl.ch (Delafontaine Ludovic) Date: Fri, 7 Nov 2014 08:35:39 +0000 Subject: [Rdo-list] Error in the documentation "Adding a compute node" Message-ID: <9666E2C7-75ED-4E84-993A-8C514607FA50@epfl.ch> Hi guys, I?ve found a few errors in the documentation ?Adding a compute node? (https://openstack.redhat.com/Adding_a_compute_node). On my system (RHEL 7), the variables ?CONFIG_NOVA_COMPUTE_HOSTS' and ?CONFIG_NOVA_NETWORK_HOSTS' don?t exist in the answer file. Instead, I have these variables ?CONFIG_COMPUTE_HOSTS? and ?CONFIG_NETWORK_HOSTS?. Here is my system information: [root at cloud63 ~]# cat /etc/*-release NAME="Red Hat Enterprise Linux Server" VERSION="7.0 (Maipo)" ID="rhel" ID_LIKE="fedora" VERSION_ID="7.0" PRETTY_NAME="Red Hat Enterprise Linux" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:redhat:enterprise_linux:7.0:GA:server" HOME_URL="https://www.redhat.com/" BUG_REPORT_URL="https://bugzilla.redhat.com/" REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 7" REDHAT_BUGZILLA_PRODUCT_VERSION=7.0 REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux" REDHAT_SUPPORT_PRODUCT_VERSION=7.0 Red Hat Enterprise Linux Server release 7.0 (Maipo) Red Hat Enterprise Linux Server release 7.0 (Maipo) and my openstack-packstack version: [root at cloud63 ~]# yum info openstack-packstack Failed to set locale, defaulting to C Loaded plugins: priorities, product-id, subscription-manager Installed Packages Name : openstack-packstack Arch : noarch Version : 2014.2 Release : 0.5.dev1316.g733aa73.el7.centos Size : 740 k Repo : installed >From repo : openstack-juno Summary : Openstack Install Utility URL : https://github.com/stackforge/packstack License : ASL 2.0 and GPLv2 Description : Packstack is a utility that uses Puppet modules to install : OpenStack. Packstack can be used to deploy various parts of : OpenStack on multiple pre installed servers over ssh. and my command?s history: 5 subscription-manager register --username= --auto-attach 6 subscription-manager repos --enable rhel-7-server-optional-rpms 7 subscription-manager repos --enable rhel-7-server-extras-rpms 8 subscription-manager repos --enable rhel-server-rhscl-7-rpms 9 wget https://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-2.noarch.rpm 10 yum install wget 11 wget https://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-2.noarch.rpm 12 sudo yum install epel-release-7-2.noarch.rpm 13 yum update -y 14 sudo yum install -y https://rdo.fedorapeople.org/rdo-release.rpm 15 sudo yum install -y openstack-packstack 16 sudo yum repolist 17 packstack ?allinone Thank you for your effort. Have a nice day, Ludovic Delafontaine -------------- next part -------------- An HTML attachment was scrubbed... URL: From docana at ebi.ac.uk Fri Nov 7 10:24:17 2014 From: docana at ebi.ac.uk (David Ocana) Date: Fri, 07 Nov 2014 10:24:17 +0000 Subject: [Rdo-list] Packstack error Message-ID: <545C9DD1.6010203@ebi.ac.uk> Hi everyone, I'm installing the latest juno RDO release and I ran into this problem: # yum -y update # yum install rdo-release-juno-1.noarch.rpm # yum install -y openstack-packstack # packstack --allinone Installing: Clean Up [ DONE ] Setting up ssh keys [ DONE ] Discovering hosts' details [ DONE ] Adding pre install manifest entries [ DONE ] [...] 10.8.6.2_keystone.pp: [ ERROR ] Applying Puppet manifests [ ERROR ] ERROR : Error appeared during Puppet run: 10.8.6.2_keystone.pp Error: /Stage[main]/Neutron::Keystone::Auth/Keystone_service[neutron]: Could not evaluate: Execution of '/usr/bin/keystone --os-endpoint http://127.0.0.1:35357/v2.0/ service-list' returned 1: Service Unavailable (HTTP 503) You will find full trace in log /var/tmp/packstack/20141107-090534-05fJzm/manifests/10.8.6.2_keystone.pp.log Please check log file /var/tmp/packstack/20141107-090534-05fJzm/openstack-setup.log for more information The service seems to be running because you get a 503 response, but I checked it: ------------------- # netstat -putln | grep 35357 tcp 0 0 0.0.0.0:35357 0.0.0.0:* LISTEN 24884/python ------------------- I checked the file /var/tmp/packstack/20141107-090534-05fJzm/manifests/10.8.6.2_keystone.pp.log and this is the most relevant: ----------------- Notice: /Stage[main]/Keystone/Keystone_config[database/idle_timeout]/ensure: created Notice: /Stage[main]/Keystone/Keystone_config[DEFAULT/verbose]/ensure: created Notice: /Stage[main]/Keystone::Db::Sync/Exec[keystone-manage db_sync]: Triggered 'refresh' from 32 events Notice: /Stage[main]/Keystone/Exec[keystone-manage pki_setup]: Triggered 'refresh' from 31 events Notice: /Stage[main]/Keystone::Service/Service[keystone]/ensure: ensure changed 'stopped' to 'running' Error: /Stage[main]/Neutron::Keystone::Auth/Keystone_service[neutron]: Could not evaluate: Execution of '/usr/bin/keystone --os-endpoint http://127.0.0.1:35357/v2.0/ service-list' returned 1: Service Unavailable (HTTP 503) Error: /Stage[main]/Ceilometer::Keystone::Auth/Keystone_service[ceilometer]: Could not evaluate: Execution of '/usr/bin/keystone --os-endpoint http://127.0.0.1:35357/v2.0/ service-list' returned 1: Service Unavailable (HTTP 503) Error: /Stage[main]/Keystone::Roles::Admin/Keystone_tenant[admin]: Could not evaluate: Execution of '/usr/bin/keystone --os-endpoint http://127.0.0.1:35357/v2.0/ tenant-list' returned 1: Service Unavailable (HTTP 503) (from here down it's the same error messages) ------------------ Here is keystone.log, no errors, only info and warning messages: ------------------- 2014-11-07 10:15:31.995 30006 INFO keystone.openstack.common.service [-] Starting 16 workers 2014-11-07 10:15:31.995 30029 INFO eventlet.wsgi.server [-] (30029) wsgi starting up on http://0.0.0.0:35357/ 2014-11-07 10:15:31.997 30006 INFO keystone.openstack.common.service [-] Started child 30030 [...] 2014-11-07 10:16:01.881 30494 WARNING keystone.openstack.common.versionutils [-] Deprecated: keystone.token.backends.sql.Token is deprecated as of Juno in favor of keystone.token.persistence.backends.sql.Token and may be removed in Kilo. 2014-11-07 10:16:01.904 30494 INFO keystone.token.persistence.backends.sql [-] Token expiration batch size: 1000 2014-11-07 10:16:01.908 30494 INFO keystone.token.persistence.backends.sql [-] Total expired tokens removed: 0 ------------------- Has anyone had this problem? Thanks in advance. Cheers, David From lars at redhat.com Fri Nov 7 10:25:42 2014 From: lars at redhat.com (Lars Kellogg-Stedman) Date: Fri, 7 Nov 2014 11:25:42 +0100 Subject: [Rdo-list] Disabling and enabling OpenStack In-Reply-To: <648473255763364B961A02AC3BE1060D03C7B58868@MX19A.corp.emc.com> References: <648473255763364B961A02AC3BE1060D03C7B58868@MX19A.corp.emc.com> Message-ID: <20141107102542.GA24114@redhat.com> On Wed, Nov 05, 2014 at 06:39:18AM -0500, Kaul, Yaniv wrote: > This was fine and dandy, but now: > 1. I can't stop the openstack services: > [root at lgdrm1499 ~]# openstack-service list |xargs openstack-service stop > Too few arguments. "openstack-service list" and other commands only operated on "enabled" services (because you would not want to start services that were disabled). When you disable a service, that means you can no longer operate on it with the openstack-service command. In your situation, I would do this: openstack-service list > /etc/openstack-services openstack-service stop xargs systemctl disable < /etc/openstack-services And then when you want to start things back up: xargs systemctl enable < /etc/openstack-services openstack-service start -- Lars Kellogg-Stedman | larsks @ {freenode,twitter,github} Cloud Engineering / OpenStack | http://blog.oddbit.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From ak at cloudssky.com Fri Nov 7 10:34:54 2014 From: ak at cloudssky.com (Arash Kaffamanesh) Date: Fri, 7 Nov 2014 11:34:54 +0100 Subject: [Rdo-list] Packstack error In-Reply-To: <545C9DD1.6010203@ebi.ac.uk> References: <545C9DD1.6010203@ebi.ac.uk> Message-ID: David, On which OS are you deploying? CentOS 7? I did the AIO and multi node installation several times on CentOS 7 without any problems. By the way, did you set selinux to permissive? Is firewalld running? If yes disable both. -Arash On Fri, Nov 7, 2014 at 11:24 AM, David Ocana wrote: > Hi everyone, > > I'm installing the latest juno RDO release and I ran into this problem: > > # yum -y update > # yum install rdo-release-juno-1.noarch.rpm > # yum install -y openstack-packstack > # packstack --allinone > Installing: > Clean Up [ DONE ] > Setting up ssh keys [ DONE ] > Discovering hosts' details [ DONE ] > Adding pre install manifest entries [ DONE ] > [...] > 10.8.6.2_keystone.pp: [ ERROR ] > Applying Puppet manifests [ ERROR ] > > ERROR : Error appeared during Puppet run: 10.8.6.2_keystone.pp > Error: /Stage[main]/Neutron::Keystone::Auth/Keystone_service[neutron]: > Could not evaluate: Execution of '/usr/bin/keystone --os-endpoint > http://127.0.0.1:35357/v2.0/ service-list' returned 1: Service > Unavailable (HTTP 503) > You will find full trace in log /var/tmp/packstack/20141107- > 090534-05fJzm/manifests/10.8.6.2_keystone.pp.log > Please check log file /var/tmp/packstack/20141107- > 090534-05fJzm/openstack-setup.log for more information > > The service seems to be running because you get a 503 response, but I > checked it: > ------------------- > # netstat -putln | grep 35357 > tcp 0 0 0.0.0.0:35357 0.0.0.0:* LISTEN > 24884/python > ------------------- > > I checked the file /var/tmp/packstack/20141107- > 090534-05fJzm/manifests/10.8.6.2_keystone.pp.log and this is the most > relevant: > ----------------- > Notice: /Stage[main]/Keystone/Keystone_config[database/idle_timeout]/ensure: > created > Notice: /Stage[main]/Keystone/Keystone_config[DEFAULT/verbose]/ensure: > created > Notice: /Stage[main]/Keystone::Db::Sync/Exec[keystone-manage db_sync]: > Triggered 'refresh' from 32 events > Notice: /Stage[main]/Keystone/Exec[keystone-manage pki_setup]: Triggered > 'refresh' from 31 events > Notice: /Stage[main]/Keystone::Service/Service[keystone]/ensure: ensure > changed 'stopped' to 'running' > Error: /Stage[main]/Neutron::Keystone::Auth/Keystone_service[neutron]: > Could not evaluate: Execution of '/usr/bin/keystone --os-endpoint > http://127.0.0.1:35357/v2.0/ service-list' returned 1: Service > Unavailable (HTTP 503) > Error: /Stage[main]/Ceilometer::Keystone::Auth/Keystone_service[ceilometer]: > Could not evaluate: Execution of '/usr/bin/keystone --os-endpoint > http://127.0.0.1:35357/v2.0/ service-list' returned 1: Service > Unavailable (HTTP 503) > Error: /Stage[main]/Keystone::Roles::Admin/Keystone_tenant[admin]: Could > not evaluate: Execution of '/usr/bin/keystone --os-endpoint > http://127.0.0.1:35357/v2.0/ tenant-list' returned 1: Service Unavailable > (HTTP 503) > (from here down it's the same error messages) > ------------------ > > Here is keystone.log, no errors, only info and warning messages: > ------------------- > 2014-11-07 10:15:31.995 30006 INFO keystone.openstack.common.service [-] > Starting 16 workers > 2014-11-07 10:15:31.995 30029 INFO eventlet.wsgi.server [-] (30029) wsgi > starting up on http://0.0.0.0:35357/ > 2014-11-07 10:15:31.997 30006 INFO keystone.openstack.common.service [-] > Started child 30030 > [...] > 2014-11-07 10:16:01.881 30494 WARNING keystone.openstack.common.versionutils > [-] Deprecated: keystone.token.backends.sql.Token is deprecated as of > Juno in favor of keystone.token.persistence.backends.sql.Token and may be > removed in Kilo. > 2014-11-07 10:16:01.904 30494 INFO keystone.token.persistence.backends.sql > [-] Token expiration batch size: 1000 > 2014-11-07 10:16:01.908 30494 INFO keystone.token.persistence.backends.sql > [-] Total expired tokens removed: 0 > ------------------- > > Has anyone had this problem? > > Thanks in advance. > > Cheers, > David > > > > > > _______________________________________________ > 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 swapnil at linux.com Fri Nov 7 10:34:17 2014 From: swapnil at linux.com (Swapnil Jain) Date: Fri, 7 Nov 2014 16:04:17 +0530 Subject: [Rdo-list] Error in the documentation "Adding a compute node" In-Reply-To: <9666E2C7-75ED-4E84-993A-8C514607FA50@epfl.ch> References: <9666E2C7-75ED-4E84-993A-8C514607FA50@epfl.ch> Message-ID: <729A1682-E2D4-4568-9B5D-945412962E0E@Linux.com> > On 07-Nov-2014, at 2:05 pm, Delafontaine Ludovic wrote: > > Hi guys, > > I?ve found a few errors in the documentation ?Adding a compute node? (https://openstack.redhat.com/Adding_a_compute_node). > > On my system (RHEL 7), the variables ?CONFIG_NOVA_COMPUTE_HOSTS' and ?CONFIG_NOVA_NETWORK_HOSTS' don?t exist in the answer file. Instead, I have these variables ?CONFIG_COMPUTE_HOSTS? and ?CONFIG_NETWORK_HOSTS?. > > > Here is my system information: > [root at cloud63 ~]# cat /etc/*-release > NAME="Red Hat Enterprise Linux Server" > VERSION="7.0 (Maipo)" > ID="rhel" > ID_LIKE="fedora" > VERSION_ID="7.0" > PRETTY_NAME="Red Hat Enterprise Linux" > ANSI_COLOR="0;31" > CPE_NAME="cpe:/o:redhat:enterprise_linux:7.0:GA:server" > HOME_URL="https://www.redhat.com/" > BUG_REPORT_URL="https://bugzilla.redhat.com/" > > REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 7" > REDHAT_BUGZILLA_PRODUCT_VERSION=7.0 > REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux" > REDHAT_SUPPORT_PRODUCT_VERSION=7.0 > Red Hat Enterprise Linux Server release 7.0 (Maipo) > Red Hat Enterprise Linux Server release 7.0 (Maipo) > > and my openstack-packstack version: > [root at cloud63 ~]# yum info openstack-packstack > Failed to set locale, defaulting to C > Loaded plugins: priorities, product-id, subscription-manager > Installed Packages > Name : openstack-packstack > Arch : noarch > Version : 2014.2 > Release : 0.5.dev1316.g733aa73.el7.centos > Size : 740 k > Repo : installed > From repo : openstack-juno > Summary : Openstack Install Utility > URL : https://github.com/stackforge/packstack > License : ASL 2.0 and GPLv2 > Description : Packstack is a utility that uses Puppet modules to install > : OpenStack. Packstack can be used to deploy various parts of > : OpenStack on multiple pre installed servers over ssh. > > and my command?s history: > > 5 subscription-manager register --username= --auto-attach > 6 subscription-manager repos --enable rhel-7-server-optional-rpms > 7 subscription-manager repos --enable rhel-7-server-extras-rpms > 8 subscription-manager repos --enable rhel-server-rhscl-7-rpms > 9 wget https://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-2.noarch.rpm > 10 yum install wget > 11 wget https://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-2.noarch.rpm > 12 sudo yum install epel-release-7-2.noarch.rpm > 13 yum update -y > 14 sudo yum install -y https://rdo.fedorapeople.org/rdo-release.rpm > 15 sudo yum install -y openstack-packstack > 16 sudo yum repolist > 17 packstack ?allinone > > Thank you for your effort. > > Have a nice day, > Ludovic Delafontaine > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list Hi, It seems you are doing a allinone installation, and the guide you are referring to is to add an addition compute node to the OpenStack setup. If you have generated an answer file you will find this option "CONFIG_NOVA_COMPUTE_HOSTS". If this is your first installation just follow the quick start guide. https://openstack.redhat.com/Quickstart HTH ? Swapnil Jain | Swapnil at Linux.com RHC{A,DS,E,VA}, CC{DA,NA}, MCSE, CNE From swapnil at linux.com Fri Nov 7 10:38:24 2014 From: swapnil at linux.com (Swapnil Jain) Date: Fri, 7 Nov 2014 16:08:24 +0530 Subject: [Rdo-list] Error in the documentation "Adding a compute node" In-Reply-To: <9666E2C7-75ED-4E84-993A-8C514607FA50@epfl.ch> References: <9666E2C7-75ED-4E84-993A-8C514607FA50@epfl.ch> Message-ID: <3CF658D5-4989-428C-97AC-548BC1E96906@Linux.com> > On 07-Nov-2014, at 2:05 pm, Delafontaine Ludovic wrote: > > Hi guys, > > I?ve found a few errors in the documentation ?Adding a compute node? (https://openstack.redhat.com/Adding_a_compute_node). > > On my system (RHEL 7), the variables ?CONFIG_NOVA_COMPUTE_HOSTS' and ?CONFIG_NOVA_NETWORK_HOSTS' don?t exist in the answer file. Instead, I have these variables ?CONFIG_COMPUTE_HOSTS? and ?CONFIG_NETWORK_HOSTS?. > > > Here is my system information: > [root at cloud63 ~]# cat /etc/*-release > NAME="Red Hat Enterprise Linux Server" > VERSION="7.0 (Maipo)" > ID="rhel" > ID_LIKE="fedora" > VERSION_ID="7.0" > PRETTY_NAME="Red Hat Enterprise Linux" > ANSI_COLOR="0;31" > CPE_NAME="cpe:/o:redhat:enterprise_linux:7.0:GA:server" > HOME_URL="https://www.redhat.com/" > BUG_REPORT_URL="https://bugzilla.redhat.com/" > > REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 7" > REDHAT_BUGZILLA_PRODUCT_VERSION=7.0 > REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux" > REDHAT_SUPPORT_PRODUCT_VERSION=7.0 > Red Hat Enterprise Linux Server release 7.0 (Maipo) > Red Hat Enterprise Linux Server release 7.0 (Maipo) > > and my openstack-packstack version: > [root at cloud63 ~]# yum info openstack-packstack > Failed to set locale, defaulting to C > Loaded plugins: priorities, product-id, subscription-manager > Installed Packages > Name : openstack-packstack > Arch : noarch > Version : 2014.2 > Release : 0.5.dev1316.g733aa73.el7.centos > Size : 740 k > Repo : installed > From repo : openstack-juno > Summary : Openstack Install Utility > URL : https://github.com/stackforge/packstack > License : ASL 2.0 and GPLv2 > Description : Packstack is a utility that uses Puppet modules to install > : OpenStack. Packstack can be used to deploy various parts of > : OpenStack on multiple pre installed servers over ssh. > > and my command?s history: > > 5 subscription-manager register --username= --auto-attach > 6 subscription-manager repos --enable rhel-7-server-optional-rpms > 7 subscription-manager repos --enable rhel-7-server-extras-rpms > 8 subscription-manager repos --enable rhel-server-rhscl-7-rpms > 9 wget https://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-2.noarch.rpm > 10 yum install wget > 11 wget https://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-2.noarch.rpm > 12 sudo yum install epel-release-7-2.noarch.rpm > 13 yum update -y > 14 sudo yum install -y https://rdo.fedorapeople.org/rdo-release.rpm > 15 sudo yum install -y openstack-packstack > 16 sudo yum repolist > 17 packstack ?allinone > > Thank you for your effort. > > Have a nice day, > Ludovic Delafontaine > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list Hi, It seems you are doing a allinone installation, and the guide you are referring to is to add an addition compute node to the OpenStack setup. If you have generated an answer file you will find this option "CONFIG_NOVA_COMPUTE_HOSTS". If this is your first installation just follow the quick start guide. https://openstack.redhat.com/Quickstart HTH ? Swapnil Jain | Swapnil at Linux.com RHC{A,DS,E,VA}, CC{DA,NA}, MCSE, CNE From docana at ebi.ac.uk Fri Nov 7 10:47:27 2014 From: docana at ebi.ac.uk (David Ocana) Date: Fri, 07 Nov 2014 10:47:27 +0000 Subject: [Rdo-list] Packstack error In-Reply-To: References: <545C9DD1.6010203@ebi.ac.uk> Message-ID: <545CA33F.7020407@ebi.ac.uk> Hi Arash, Thanks for the quick reply. Sorry I forgot to mention that the OS is rhel 7, and selinux was not set to permisive.I just changed it but I get the same error: # setenforce permissive # packstack --allinone [...] ERROR : Error appeared during Puppet run: 10.8.6.2_keystone.pp Error: /Stage[main]/Neutron::Keystone::Auth/Keystone_service[neutron]: Could not evaluate: Execution of '/usr/bin/keystone --os-endpoint http://127.0.0.1:35357/v2.0/ service-list' returned 1: Service Unavailable (HTTP 503) Firewalld is not running # systemctl status firewalld firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled) Active: inactive (dead) I'll keep going with this for a little bit, but If CentOs 7 is working I'll probably change the OS and I'll give it a try. Thanks, David On 07/11/14 10:34, Arash Kaffamanesh wrote: > David, > On which OS are you deploying? CentOS 7? > I did the AIO and multi node installation several times on CentOS 7 > without any problems. > By the way, did you set selinux to permissive? Is firewalld running? > If yes disable both. > > -Arash > > > On Fri, Nov 7, 2014 at 11:24 AM, David Ocana > wrote: > > Hi everyone, > > I'm installing the latest juno RDO release and I ran into this > problem: > > # yum -y update > # yum install rdo-release-juno-1.noarch.rpm > # yum install -y openstack-packstack > # packstack --allinone > Installing: > Clean Up [ DONE ] > Setting up ssh keys [ DONE ] > Discovering hosts' details [ DONE ] > Adding pre install manifest entries [ DONE ] > [...] > 10.8.6.2_keystone.pp: [ ERROR ] > Applying Puppet manifests [ ERROR ] > > ERROR : Error appeared during Puppet run: 10.8.6.2_keystone.pp > Error: > /Stage[main]/Neutron::Keystone::Auth/Keystone_service[neutron]: > Could not evaluate: Execution of '/usr/bin/keystone --os-endpoint > http://127.0.0.1:35357/v2.0/ service-list' returned 1: Service > Unavailable (HTTP 503) > You will find full trace in log > /var/tmp/packstack/20141107-090534-05fJzm/manifests/10.8.6.2_keystone.pp.log > Please check log file > /var/tmp/packstack/20141107-090534-05fJzm/openstack-setup.log for > more information > > The service seems to be running because you get a 503 response, > but I checked it: > ------------------- > # netstat -putln | grep 35357 > tcp 0 0 0.0.0.0:35357 > 0.0.0.0:* LISTEN 24884/python > ------------------- > > I checked the file > /var/tmp/packstack/20141107-090534-05fJzm/manifests/10.8.6.2_keystone.pp.log > and this is the most relevant: > ----------------- > Notice: > /Stage[main]/Keystone/Keystone_config[database/idle_timeout]/ensure: > created > Notice: > /Stage[main]/Keystone/Keystone_config[DEFAULT/verbose]/ensure: created > Notice: /Stage[main]/Keystone::Db::Sync/Exec[keystone-manage > db_sync]: Triggered 'refresh' from 32 events > Notice: /Stage[main]/Keystone/Exec[keystone-manage pki_setup]: > Triggered 'refresh' from 31 events > Notice: /Stage[main]/Keystone::Service/Service[keystone]/ensure: > ensure changed 'stopped' to 'running' > Error: > /Stage[main]/Neutron::Keystone::Auth/Keystone_service[neutron]: > Could not evaluate: Execution of '/usr/bin/keystone --os-endpoint > http://127.0.0.1:35357/v2.0/ service-list' returned 1: Service > Unavailable (HTTP 503) > Error: > /Stage[main]/Ceilometer::Keystone::Auth/Keystone_service[ceilometer]: > Could not evaluate: Execution of '/usr/bin/keystone --os-endpoint > http://127.0.0.1:35357/v2.0/ service-list' returned 1: Service > Unavailable (HTTP 503) > Error: /Stage[main]/Keystone::Roles::Admin/Keystone_tenant[admin]: > Could not evaluate: Execution of '/usr/bin/keystone --os-endpoint > http://127.0.0.1:35357/v2.0/ tenant-list' returned 1: Service > Unavailable (HTTP 503) > (from here down it's the same error messages) > ------------------ > > Here is keystone.log, no errors, only info and warning messages: > ------------------- > 2014-11-07 10:15:31.995 30006 INFO > keystone.openstack.common.service [-] Starting 16 workers > 2014-11-07 10:15:31.995 30029 INFO eventlet.wsgi.server [-] > (30029) wsgi starting up on http://0.0.0.0:35357/ > 2014-11-07 10:15:31.997 30006 INFO > keystone.openstack.common.service [-] Started child 30030 > [...] > 2014-11-07 10:16:01.881 30494 WARNING > keystone.openstack.common.versionutils [-] Deprecated: > keystone.token.backends.sql.Token is deprecated as of Juno in > favor of keystone.token.persistence.backends.sql.Token and may be > removed in Kilo. > 2014-11-07 10:16:01.904 30494 INFO > keystone.token.persistence.backends.sql [-] Token expiration batch > size: 1000 > 2014-11-07 10:16:01.908 30494 INFO > keystone.token.persistence.backends.sql [-] Total expired tokens > removed: 0 > ------------------- > > Has anyone had this problem? > > Thanks in advance. > > Cheers, > David > > > > > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > From ak at cloudssky.com Fri Nov 7 10:54:24 2014 From: ak at cloudssky.com (Arash Kaffamanesh) Date: Fri, 7 Nov 2014 11:54:24 +0100 Subject: [Rdo-list] Packstack error In-Reply-To: <545CA33F.7020407@ebi.ac.uk> References: <545C9DD1.6010203@ebi.ac.uk> <545CA33F.7020407@ebi.ac.uk> Message-ID: Hi David, after setting selinux to permissive, the change takes affect after a reboot, or you can force it without reboot with "setenforce 0". In general for evaluation it might be recommendable to go with CentOS 7 first. By the way I wrote this small how to some weeks ago, which could be of help: http://ow.ly/Clrq5 -Arash On Fri, Nov 7, 2014 at 11:47 AM, David Ocana wrote: > Hi Arash, > > Thanks for the quick reply. Sorry I forgot to mention that the OS is rhel > 7, and selinux was not set to permisive.I just changed it but I get the > same error: > > # setenforce permissive > # packstack --allinone > [...] > ERROR : Error appeared during Puppet run: 10.8.6.2_keystone.pp > Error: /Stage[main]/Neutron::Keystone::Auth/Keystone_service[neutron]: > Could not evaluate: Execution of '/usr/bin/keystone --os-endpoint > http://127.0.0.1:35357/v2.0/ service-list' returned 1: Service > Unavailable (HTTP 503) > > Firewalld is not running > > # systemctl status firewalld > firewalld.service - firewalld - dynamic firewall daemon > Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled) > Active: inactive (dead) > > I'll keep going with this for a little bit, but If CentOs 7 is working > I'll probably change the OS and I'll give it a try. > > Thanks, > David > > On 07/11/14 10:34, Arash Kaffamanesh wrote: > >> David, >> On which OS are you deploying? CentOS 7? >> I did the AIO and multi node installation several times on CentOS 7 >> without any problems. >> By the way, did you set selinux to permissive? Is firewalld running? If >> yes disable both. >> >> -Arash >> >> >> On Fri, Nov 7, 2014 at 11:24 AM, David Ocana > docana at ebi.ac.uk>> wrote: >> >> Hi everyone, >> >> I'm installing the latest juno RDO release and I ran into this >> problem: >> >> # yum -y update >> # yum install rdo-release-juno-1.noarch.rpm >> # yum install -y openstack-packstack >> # packstack --allinone >> Installing: >> Clean Up [ DONE ] >> Setting up ssh keys [ DONE ] >> Discovering hosts' details [ DONE ] >> Adding pre install manifest entries [ DONE ] >> [...] >> 10.8.6.2_keystone.pp: [ ERROR ] >> Applying Puppet manifests [ ERROR ] >> >> ERROR : Error appeared during Puppet run: 10.8.6.2_keystone.pp >> Error: >> /Stage[main]/Neutron::Keystone::Auth/Keystone_service[neutron]: >> Could not evaluate: Execution of '/usr/bin/keystone --os-endpoint >> http://127.0.0.1:35357/v2.0/ service-list' returned 1: Service >> Unavailable (HTTP 503) >> You will find full trace in log >> /var/tmp/packstack/20141107-090534-05fJzm/manifests/10.8. >> 6.2_keystone.pp.log >> Please check log file >> /var/tmp/packstack/20141107-090534-05fJzm/openstack-setup.log for >> more information >> >> The service seems to be running because you get a 503 response, >> but I checked it: >> ------------------- >> # netstat -putln | grep 35357 >> tcp 0 0 0.0.0.0:35357 >> 0.0.0.0:* LISTEN 24884/python >> >> ------------------- >> >> I checked the file >> /var/tmp/packstack/20141107-090534-05fJzm/manifests/10.8. >> 6.2_keystone.pp.log >> and this is the most relevant: >> ----------------- >> Notice: >> /Stage[main]/Keystone/Keystone_config[database/idle_timeout]/ensure: >> created >> Notice: >> /Stage[main]/Keystone/Keystone_config[DEFAULT/verbose]/ensure: >> created >> Notice: /Stage[main]/Keystone::Db::Sync/Exec[keystone-manage >> db_sync]: Triggered 'refresh' from 32 events >> Notice: /Stage[main]/Keystone/Exec[keystone-manage pki_setup]: >> Triggered 'refresh' from 31 events >> Notice: /Stage[main]/Keystone::Service/Service[keystone]/ensure: >> ensure changed 'stopped' to 'running' >> Error: >> /Stage[main]/Neutron::Keystone::Auth/Keystone_service[neutron]: >> Could not evaluate: Execution of '/usr/bin/keystone --os-endpoint >> http://127.0.0.1:35357/v2.0/ service-list' returned 1: Service >> Unavailable (HTTP 503) >> Error: >> /Stage[main]/Ceilometer::Keystone::Auth/Keystone_service[ceilometer]: >> Could not evaluate: Execution of '/usr/bin/keystone --os-endpoint >> http://127.0.0.1:35357/v2.0/ service-list' returned 1: Service >> Unavailable (HTTP 503) >> Error: /Stage[main]/Keystone::Roles::Admin/Keystone_tenant[admin]: >> Could not evaluate: Execution of '/usr/bin/keystone --os-endpoint >> http://127.0.0.1:35357/v2.0/ tenant-list' returned 1: Service >> Unavailable (HTTP 503) >> (from here down it's the same error messages) >> ------------------ >> >> Here is keystone.log, no errors, only info and warning messages: >> ------------------- >> 2014-11-07 10:15:31.995 30006 INFO >> keystone.openstack.common.service [-] Starting 16 workers >> 2014-11-07 10:15:31.995 30029 INFO eventlet.wsgi.server [-] >> (30029) wsgi starting up on http://0.0.0.0:35357/ >> 2014-11-07 10:15:31.997 30006 INFO >> keystone.openstack.common.service [-] Started child 30030 >> [...] >> 2014-11-07 10:16:01.881 30494 WARNING >> keystone.openstack.common.versionutils [-] Deprecated: >> keystone.token.backends.sql.Token is deprecated as of Juno in >> favor of keystone.token.persistence.backends.sql.Token and may be >> removed in Kilo. >> 2014-11-07 10:16:01.904 30494 INFO >> keystone.token.persistence.backends.sql [-] Token expiration batch >> size: 1000 >> 2014-11-07 10:16:01.908 30494 INFO >> keystone.token.persistence.backends.sql [-] Total expired tokens >> removed: 0 >> ------------------- >> >> Has anyone had this problem? >> >> Thanks in advance. >> >> Cheers, >> David >> >> >> >> >> >> _______________________________________________ >> 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 Yaniv.Kaul at emc.com Fri Nov 7 11:25:21 2014 From: Yaniv.Kaul at emc.com (Kaul, Yaniv) Date: Fri, 7 Nov 2014 06:25:21 -0500 Subject: [Rdo-list] Disabling and enabling OpenStack In-Reply-To: <20141107102542.GA24114@redhat.com> References: <648473255763364B961A02AC3BE1060D03C7B58868@MX19A.corp.emc.com> <20141107102542.GA24114@redhat.com> Message-ID: <648473255763364B961A02AC3BE1060D03C7C87D5B@MX19A.corp.emc.com> > -----Original Message----- > From: Lars Kellogg-Stedman [mailto:lars at redhat.com] > Sent: Friday, November 07, 2014 12:26 PM > To: Kaul, Yaniv > Cc: rdo-list at redhat.com > Subject: Re: [Rdo-list] Disabling and enabling OpenStack > > On Wed, Nov 05, 2014 at 06:39:18AM -0500, Kaul, Yaniv wrote: > > This was fine and dandy, but now: > > 1. I can't stop the openstack services: > > [root at lgdrm1499 ~]# openstack-service list |xargs openstack-service > > stop Too few arguments. > > "openstack-service list" and other commands only operated on "enabled" > services (because you would not want to start services that were disabled). > When you disable a service, that means you can no longer operate on it with > the openstack-service command. > > In your situation, I would do this: Thanks, I've managed. I find the functionality half-baked. If you have a disable, it's only natural you want an enable action. And you do expect it to work. You also expect 'stop' to work on active service, regardless if they are enabled or disabled (in my case, I've disabled before stopping them). I've opened https://bugzilla.redhat.com/show_bug.cgi?id=1161501 to track the issue. Lastly, I've mentioned but not filed a bug - on secondary compute nodes, openstack-utils RPM is not installed (Packstack-based installation), making stopping/starting the openstack related services a bit different than on the controller node. Y. > > openstack-service list > /etc/openstack-services > openstack-service stop > xargs systemctl disable < /etc/openstack-services > > And then when you want to start things back up: > > xargs systemctl enable < /etc/openstack-services > openstack-service start > > -- > Lars Kellogg-Stedman | larsks @ {freenode,twitter,github} > Cloud Engineering / OpenStack | http://blog.oddbit.com/ From docana at ebi.ac.uk Fri Nov 7 11:36:52 2014 From: docana at ebi.ac.uk (David Ocana) Date: Fri, 07 Nov 2014 11:36:52 +0000 Subject: [Rdo-list] Packstack error In-Reply-To: References: <545C9DD1.6010203@ebi.ac.uk> <545CA33F.7020407@ebi.ac.uk> Message-ID: <545CAED4.1090305@ebi.ac.uk> Hi Arash, Thanks for your help, it did not work, so I'm going to give it a try following your CentOS7 guide. Best regards, David On 07/11/14 10:54, Arash Kaffamanesh wrote: > Hi David, > > after setting selinux to permissive, the change takes affect after a > reboot, or you can force it without reboot with "setenforce 0". > In general for evaluation it might be recommendable to go with CentOS > 7 first. > By the way I wrote this small how to some weeks ago, which could be of > help: > http://ow.ly/Clrq5 > > -Arash > > On Fri, Nov 7, 2014 at 11:47 AM, David Ocana > wrote: > > Hi Arash, > > Thanks for the quick reply. Sorry I forgot to mention that the OS > is rhel 7, and selinux was not set to permisive.I just changed it > but I get the same error: > > # setenforce permissive > # packstack --allinone > [...] > ERROR : Error appeared during Puppet run: 10.8.6.2_keystone.pp > Error: > /Stage[main]/Neutron::Keystone::Auth/Keystone_service[neutron]: > Could not evaluate: Execution of '/usr/bin/keystone --os-endpoint > http://127.0.0.1:35357/v2.0/ service-list' returned 1: Service > Unavailable (HTTP 503) > > Firewalld is not running > > # systemctl status firewalld > firewalld.service - firewalld - dynamic firewall daemon > Loaded: loaded (/usr/lib/systemd/system/firewalld.service; > disabled) > Active: inactive (dead) > > I'll keep going with this for a little bit, but If CentOs 7 is > working I'll probably change the OS and I'll give it a try. > > Thanks, > David > > On 07/11/14 10:34, Arash Kaffamanesh wrote: > > David, > On which OS are you deploying? CentOS 7? > I did the AIO and multi node installation several times on > CentOS 7 without any problems. > By the way, did you set selinux to permissive? Is firewalld > running? If yes disable both. > > -Arash > > > On Fri, Nov 7, 2014 at 11:24 AM, David Ocana >> wrote: > > Hi everyone, > > I'm installing the latest juno RDO release and I ran into this > problem: > > # yum -y update > # yum install rdo-release-juno-1.noarch.rpm > # yum install -y openstack-packstack > # packstack --allinone > Installing: > Clean Up [ DONE ] > Setting up ssh keys [ DONE ] > Discovering hosts' details [ DONE ] > Adding pre install manifest entries [ DONE ] > [...] > 10.8.6.2_keystone.pp: [ ERROR ] > Applying Puppet manifests [ ERROR ] > > ERROR : Error appeared during Puppet run: 10.8.6.2_keystone.pp > Error: > > /Stage[main]/Neutron::Keystone::Auth/Keystone_service[neutron]: > Could not evaluate: Execution of '/usr/bin/keystone > --os-endpoint > http://127.0.0.1:35357/v2.0/ service-list' returned 1: Service > Unavailable (HTTP 503) > You will find full trace in log > > /var/tmp/packstack/20141107-090534-05fJzm/manifests/10.8.6.2_keystone.pp.log > Please check log file > > /var/tmp/packstack/20141107-090534-05fJzm/openstack-setup.log for > more information > > The service seems to be running because you get a 503 > response, > but I checked it: > ------------------- > # netstat -putln | grep 35357 > tcp 0 0 0.0.0.0:35357 > 0.0.0.0:* LISTEN > 24884/python > > ------------------- > > I checked the file > > /var/tmp/packstack/20141107-090534-05fJzm/manifests/10.8.6.2_keystone.pp.log > and this is the most relevant: > ----------------- > Notice: > > /Stage[main]/Keystone/Keystone_config[database/idle_timeout]/ensure: > created > Notice: > > /Stage[main]/Keystone/Keystone_config[DEFAULT/verbose]/ensure: > created > Notice: /Stage[main]/Keystone::Db::Sync/Exec[keystone-manage > db_sync]: Triggered 'refresh' from 32 events > Notice: /Stage[main]/Keystone/Exec[keystone-manage pki_setup]: > Triggered 'refresh' from 31 events > Notice: > /Stage[main]/Keystone::Service/Service[keystone]/ensure: > ensure changed 'stopped' to 'running' > Error: > > /Stage[main]/Neutron::Keystone::Auth/Keystone_service[neutron]: > Could not evaluate: Execution of '/usr/bin/keystone > --os-endpoint > http://127.0.0.1:35357/v2.0/ service-list' returned 1: Service > Unavailable (HTTP 503) > Error: > > /Stage[main]/Ceilometer::Keystone::Auth/Keystone_service[ceilometer]: > Could not evaluate: Execution of '/usr/bin/keystone > --os-endpoint > http://127.0.0.1:35357/v2.0/ service-list' returned 1: Service > Unavailable (HTTP 503) > Error: > /Stage[main]/Keystone::Roles::Admin/Keystone_tenant[admin]: > Could not evaluate: Execution of '/usr/bin/keystone > --os-endpoint > http://127.0.0.1:35357/v2.0/ tenant-list' returned 1: Service > Unavailable (HTTP 503) > (from here down it's the same error messages) > ------------------ > > Here is keystone.log, no errors, only info and warning > messages: > ------------------- > 2014-11-07 10:15:31.995 30006 INFO > keystone.openstack.common.service [-] Starting 16 workers > 2014-11-07 10:15:31.995 30029 INFO eventlet.wsgi.server [-] > (30029) wsgi starting up on http://0.0.0.0:35357/ > 2014-11-07 10:15:31.997 30006 INFO > keystone.openstack.common.service [-] Started child 30030 > [...] > 2014-11-07 10:16:01.881 30494 WARNING > keystone.openstack.common.versionutils [-] Deprecated: > keystone.token.backends.sql.Token is deprecated as of Juno in > favor of keystone.token.persistence.backends.sql.Token and > may be > removed in Kilo. > 2014-11-07 10:16:01.904 30494 INFO > keystone.token.persistence.backends.sql [-] Token > expiration batch > size: 1000 > 2014-11-07 10:16:01.908 30494 INFO > keystone.token.persistence.backends.sql [-] Total expired > tokens > removed: 0 > ------------------- > > Has anyone had this problem? > > Thanks in advance. > > Cheers, > David > > > > > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/rdo-list > > > > From ak at cloudssky.com Fri Nov 7 12:19:47 2014 From: ak at cloudssky.com (Arash Kaffamanesh) Date: Fri, 7 Nov 2014 13:19:47 +0100 Subject: [Rdo-list] Packstack error In-Reply-To: <545CAED4.1090305@ebi.ac.uk> References: <545C9DD1.6010203@ebi.ac.uk> <545CA33F.7020407@ebi.ac.uk> <545CAED4.1090305@ebi.ac.uk> Message-ID: Hi David, here is another easy to follow guide for an allinone install from Derek: http://www.therandomsecurityguy.com/openstack-juno/ -Arash On Fri, Nov 7, 2014 at 12:36 PM, David Ocana wrote: > Hi Arash, > > Thanks for your help, it did not work, so I'm going to give it a try > following your CentOS7 guide. > > Best regards, > David > > On 07/11/14 10:54, Arash Kaffamanesh wrote: > >> Hi David, >> >> after setting selinux to permissive, the change takes affect after a >> reboot, or you can force it without reboot with "setenforce 0". >> In general for evaluation it might be recommendable to go with CentOS 7 >> first. >> By the way I wrote this small how to some weeks ago, which could be of >> help: >> http://ow.ly/Clrq5 >> >> -Arash >> >> On Fri, Nov 7, 2014 at 11:47 AM, David Ocana > docana at ebi.ac.uk>> wrote: >> >> Hi Arash, >> >> Thanks for the quick reply. Sorry I forgot to mention that the OS >> is rhel 7, and selinux was not set to permisive.I just changed it >> but I get the same error: >> >> # setenforce permissive >> # packstack --allinone >> [...] >> ERROR : Error appeared during Puppet run: 10.8.6.2_keystone.pp >> Error: >> /Stage[main]/Neutron::Keystone::Auth/Keystone_service[neutron]: >> Could not evaluate: Execution of '/usr/bin/keystone --os-endpoint >> http://127.0.0.1:35357/v2.0/ service-list' returned 1: Service >> Unavailable (HTTP 503) >> >> Firewalld is not running >> >> # systemctl status firewalld >> firewalld.service - firewalld - dynamic firewall daemon >> Loaded: loaded (/usr/lib/systemd/system/firewalld.service; >> disabled) >> Active: inactive (dead) >> >> I'll keep going with this for a little bit, but If CentOs 7 is >> working I'll probably change the OS and I'll give it a try. >> >> Thanks, >> David >> >> On 07/11/14 10:34, Arash Kaffamanesh wrote: >> >> David, >> On which OS are you deploying? CentOS 7? >> I did the AIO and multi node installation several times on >> CentOS 7 without any problems. >> By the way, did you set selinux to permissive? Is firewalld >> running? If yes disable both. >> >> -Arash >> >> >> On Fri, Nov 7, 2014 at 11:24 AM, David Ocana > > >> >> wrote: >> >> Hi everyone, >> >> I'm installing the latest juno RDO release and I ran into this >> problem: >> >> # yum -y update >> # yum install rdo-release-juno-1.noarch.rpm >> # yum install -y openstack-packstack >> # packstack --allinone >> Installing: >> Clean Up [ DONE ] >> Setting up ssh keys [ DONE ] >> Discovering hosts' details [ DONE ] >> Adding pre install manifest entries [ DONE ] >> [...] >> 10.8.6.2_keystone.pp: [ ERROR ] >> Applying Puppet manifests [ ERROR ] >> >> ERROR : Error appeared during Puppet run: 10.8.6.2_keystone.pp >> Error: >> /Stage[main]/Neutron::Keystone::Auth/Keystone_ >> service[neutron]: >> Could not evaluate: Execution of '/usr/bin/keystone >> --os-endpoint >> http://127.0.0.1:35357/v2.0/ service-list' returned 1: Service >> Unavailable (HTTP 503) >> You will find full trace in log >> /var/tmp/packstack/20141107- >> 090534-05fJzm/manifests/10.8.6.2_keystone.pp.log >> Please check log file >> /var/tmp/packstack/20141107- >> 090534-05fJzm/openstack-setup.log for >> more information >> >> The service seems to be running because you get a 503 >> response, >> but I checked it: >> ------------------- >> # netstat -putln | grep 35357 >> tcp 0 0 0.0.0.0:35357 >> 0.0.0.0:* LISTEN >> 24884/python >> >> ------------------- >> >> I checked the file >> /var/tmp/packstack/20141107- >> 090534-05fJzm/manifests/10.8.6.2_keystone.pp.log >> and this is the most relevant: >> ----------------- >> Notice: >> /Stage[main]/Keystone/Keystone_config[database/idle_ >> timeout]/ensure: >> created >> Notice: >> /Stage[main]/Keystone/Keystone_config[DEFAULT/ >> verbose]/ensure: >> created >> Notice: /Stage[main]/Keystone::Db::Sync/Exec[keystone-manage >> db_sync]: Triggered 'refresh' from 32 events >> Notice: /Stage[main]/Keystone/Exec[keystone-manage >> pki_setup]: >> Triggered 'refresh' from 31 events >> Notice: >> /Stage[main]/Keystone::Service/Service[keystone]/ensure: >> ensure changed 'stopped' to 'running' >> Error: >> /Stage[main]/Neutron::Keystone::Auth/Keystone_ >> service[neutron]: >> Could not evaluate: Execution of '/usr/bin/keystone >> --os-endpoint >> http://127.0.0.1:35357/v2.0/ service-list' returned 1: Service >> Unavailable (HTTP 503) >> Error: >> /Stage[main]/Ceilometer::Keystone::Auth/Keystone_ >> service[ceilometer]: >> Could not evaluate: Execution of '/usr/bin/keystone >> --os-endpoint >> http://127.0.0.1:35357/v2.0/ service-list' returned 1: Service >> Unavailable (HTTP 503) >> Error: >> /Stage[main]/Keystone::Roles::Admin/Keystone_tenant[admin]: >> Could not evaluate: Execution of '/usr/bin/keystone >> --os-endpoint >> http://127.0.0.1:35357/v2.0/ tenant-list' returned 1: Service >> Unavailable (HTTP 503) >> (from here down it's the same error messages) >> ------------------ >> >> Here is keystone.log, no errors, only info and warning >> messages: >> ------------------- >> 2014-11-07 10:15:31.995 30006 INFO >> keystone.openstack.common.service [-] Starting 16 workers >> 2014-11-07 10:15:31.995 30029 INFO eventlet.wsgi.server [-] >> (30029) wsgi starting up on http://0.0.0.0:35357/ >> 2014-11-07 10:15:31.997 30006 INFO >> keystone.openstack.common.service [-] Started child 30030 >> [...] >> 2014-11-07 10:16:01.881 30494 WARNING >> keystone.openstack.common.versionutils [-] Deprecated: >> keystone.token.backends.sql.Token is deprecated as of Juno in >> favor of keystone.token.persistence.backends.sql.Token and >> may be >> removed in Kilo. >> 2014-11-07 10:16:01.904 30494 INFO >> keystone.token.persistence.backends.sql [-] Token >> expiration batch >> size: 1000 >> 2014-11-07 10:16:01.908 30494 INFO >> keystone.token.persistence.backends.sql [-] Total expired >> tokens >> removed: 0 >> ------------------- >> >> Has anyone had this problem? >> >> Thanks in advance. >> >> Cheers, >> David >> >> >> >> >> >> _______________________________________________ >> 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 Brian.Afshar at emc.com Fri Nov 7 18:43:20 2014 From: Brian.Afshar at emc.com (Afshar, Brian) Date: Fri, 7 Nov 2014 13:43:20 -0500 Subject: [Rdo-list] Installing Nova Compute Message-ID: <9E8EE5E176B2BD49913B2F69B369AD830210BF8BFD@MX02A.corp.emc.com> Hello, I wanted to find out if anyone has tried installing OpenStack on two nodes. I have RHEL 7 and have successfully installed the Controller and have the Dashboard working. I want to install the Nova-Compute and I am not having any luck. Any feedback would be greatly appreciated. Regards, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From ak at cloudssky.com Fri Nov 7 18:56:12 2014 From: ak at cloudssky.com (Arash Kaffamanesh) Date: Fri, 7 Nov 2014 19:56:12 +0100 Subject: [Rdo-list] Installing Nova Compute In-Reply-To: <9E8EE5E176B2BD49913B2F69B369AD830210BF8BFD@MX02A.corp.emc.com> References: <9E8EE5E176B2BD49913B2F69B369AD830210BF8BFD@MX02A.corp.emc.com> Message-ID: Hi Brian, For RHEL issues I think you'll get better support bei Red Hat directly. But if you're using packstack, the only thing which you need is to create your answer file and assign the IP of the controller and compute node in that file and run packstack, packstack does the whole work for you. By the way CentOS 7 or Fedora 20 are the better choice for evaluating RDO's OpenStack. Here is a short blog post for a 2 node deployment: http://ow.ly/Clrq5 HTH, -Arash On Fri, Nov 7, 2014 at 7:43 PM, Afshar, Brian wrote: > Hello, > > > > I wanted to find out if anyone has tried installing OpenStack on two > nodes. I have RHEL 7 and have successfully installed the Controller and > have the Dashboard working. I want to install the Nova-Compute and I am > not having any luck. Any feedback would be greatly appreciated. > > > > Regards, > > > > Brian > > _______________________________________________ > 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 Yaniv.Kaul at emc.com Fri Nov 7 18:57:20 2014 From: Yaniv.Kaul at emc.com (Kaul, Yaniv) Date: Fri, 7 Nov 2014 13:57:20 -0500 Subject: [Rdo-list] Installing Nova Compute In-Reply-To: <9E8EE5E176B2BD49913B2F69B369AD830210BF8BFD@MX02A.corp.emc.com> References: <9E8EE5E176B2BD49913B2F69B369AD830210BF8BFD@MX02A.corp.emc.com> Message-ID: <648473255763364B961A02AC3BE1060D03C7C87DEF@MX19A.corp.emc.com> With Packstack, it works OK, provided you give the IP address of the node in CONFIG_COMPUTE_HOSTS= directive. Y. From: rdo-list-bounces at redhat.com [mailto:rdo-list-bounces at redhat.com] On Behalf Of Afshar, Brian Sent: Friday, November 07, 2014 8:43 PM To: rdo-list at redhat.com Subject: [Rdo-list] Installing Nova Compute Hello, I wanted to find out if anyone has tried installing OpenStack on two nodes. I have RHEL 7 and have successfully installed the Controller and have the Dashboard working. I want to install the Nova-Compute and I am not having any luck. Any feedback would be greatly appreciated. Regards, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Brian.Afshar at emc.com Fri Nov 7 19:11:27 2014 From: Brian.Afshar at emc.com (Afshar, Brian) Date: Fri, 7 Nov 2014 14:11:27 -0500 Subject: [Rdo-list] Installing Nova Compute In-Reply-To: <648473255763364B961A02AC3BE1060D03C7C87DEF@MX19A.corp.emc.com> References: <9E8EE5E176B2BD49913B2F69B369AD830210BF8BFD@MX02A.corp.emc.com> <648473255763364B961A02AC3BE1060D03C7C87DEF@MX19A.corp.emc.com> Message-ID: <9E8EE5E176B2BD49913B2F69B369AD830210BF8C0D@MX02A.corp.emc.com> Yaniv, Thanks for getting back to me. I have included the IP Address of my host as you have indicated in the answers.txt file. Also, in the nova.conf file, I have the following information that has been modified; my_ip= vncserver_proxyclient_address=$my_ip vncserver_listen=0.0.0.0 glance_host= I have tried twice to install nova-compute with ERRORs when I run the command "systemctl start openstack-nova-compute" during the install. When I run the command "nova_manage host list", it does not list my host that I try to install the nova-compute. Regards, Brian From: Kaul, Yaniv Sent: Friday, November 07, 2014 10:57 AM To: Afshar, Brian; rdo-list at redhat.com Subject: RE: Installing Nova Compute With Packstack, it works OK, provided you give the IP address of the node in CONFIG_COMPUTE_HOSTS= directive. Y. From: rdo-list-bounces at redhat.com [mailto:rdo-list-bounces at redhat.com] On Behalf Of Afshar, Brian Sent: Friday, November 07, 2014 8:43 PM To: rdo-list at redhat.com Subject: [Rdo-list] Installing Nova Compute Hello, I wanted to find out if anyone has tried installing OpenStack on two nodes. I have RHEL 7 and have successfully installed the Controller and have the Dashboard working. I want to install the Nova-Compute and I am not having any luck. Any feedback would be greatly appreciated. Regards, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Brian.Afshar at emc.com Fri Nov 7 19:19:57 2014 From: Brian.Afshar at emc.com (Afshar, Brian) Date: Fri, 7 Nov 2014 14:19:57 -0500 Subject: [Rdo-list] Installing Nova Compute In-Reply-To: References: <9E8EE5E176B2BD49913B2F69B369AD830210BF8BFD@MX02A.corp.emc.com> Message-ID: <9E8EE5E176B2BD49913B2F69B369AD830210BF8C14@MX02A.corp.emc.com> Hi Arash, At this point I am using the EVAL subscription from RedHat with little support for OpenStack. My answer file contains the information I need to run the packstack. What is the exact command you used to install packstack on a nova-compute node? Regards, Brian From: Arash Kaffamanesh [mailto:ak at cloudssky.com] Sent: Friday, November 07, 2014 10:56 AM To: Afshar, Brian; rdo-list at redhat.com Subject: Re: [Rdo-list] Installing Nova Compute Hi Brian, For RHEL issues I think you'll get better support bei Red Hat directly. But if you're using packstack, the only thing which you need is to create your answer file and assign the IP of the controller and compute node in that file and run packstack, packstack does the whole work for you. By the way CentOS 7 or Fedora 20 are the better choice for evaluating RDO's OpenStack. Here is a short blog post for a 2 node deployment: http://ow.ly/Clrq5 HTH, -Arash On Fri, Nov 7, 2014 at 7:43 PM, Afshar, Brian > wrote: Hello, I wanted to find out if anyone has tried installing OpenStack on two nodes. I have RHEL 7 and have successfully installed the Controller and have the Dashboard working. I want to install the Nova-Compute and I am not having any luck. Any feedback would be greatly appreciated. Regards, Brian _______________________________________________ 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 Yaniv.Kaul at emc.com Fri Nov 7 20:16:45 2014 From: Yaniv.Kaul at emc.com (Kaul, Yaniv) Date: Fri, 7 Nov 2014 15:16:45 -0500 Subject: [Rdo-list] Installing Nova Compute Message-ID: <54aafbca-43e0-4199-96ba-88e2698aa5ae@emc.com> Did installation succeed and it's later, or has installation failed? Can they ssh to each other? All my hosts can ssh to each other via public key auth. and I assume it's needed for successful installation. Y. From: "Afshar, Brian" Sent: Nov 7, 2014 9:11 PM To: "Kaul, Yaniv" ;rdo-list at redhat.com Subject: RE: Installing Nova Compute Yaniv, Thanks for getting back to me. I have included the IP Address of my host as you have indicated in the answers.txt file. Also, in the nova.conf file, I have the following information that has been modified; my_ip= vncserver_proxyclient_address=$my_ip vncserver_listen=0.0.0.0 glance_host= I have tried twice to install nova-compute with ERRORs when I run the command ?systemctl start openstack-nova-compute? during the install. When I run the command ?nova_manage host list?, it does not list my host that I try to install the nova-compute. Regards, Brian From: Kaul, Yaniv Sent: Friday, November 07, 2014 10:57 AM To: Afshar, Brian; rdo-list at redhat.com Subject: RE: Installing Nova Compute With Packstack, it works OK, provided you give the IP address of the node in CONFIG_COMPUTE_HOSTS= directive. Y. From: rdo-list-bounces at redhat.com [mailto:rdo-list-bounces at redhat.com] On Behalf Of Afshar, Brian Sent: Friday, November 07, 2014 8:43 PM To: rdo-list at redhat.com Subject: [Rdo-list] Installing Nova Compute Hello, I wanted to find out if anyone has tried installing OpenStack on two nodes. I have RHEL 7 and have successfully installed the Controller and have the Dashboard working. I want to install the Nova-Compute and I am not having any luck. Any feedback would be greatly appreciated. Regards, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From ak at cloudssky.com Fri Nov 7 21:03:29 2014 From: ak at cloudssky.com (Arash Kaffamanesh) Date: Fri, 7 Nov 2014 22:03:29 +0100 Subject: [Rdo-list] Installing Nova Compute In-Reply-To: <9E8EE5E176B2BD49913B2F69B369AD830210BF8C14@MX02A.corp.emc.com> References: <9E8EE5E176B2BD49913B2F69B369AD830210BF8BFD@MX02A.corp.emc.com> <9E8EE5E176B2BD49913B2F69B369AD830210BF8C14@MX02A.corp.emc.com> Message-ID: Hi Brian, You don't need to run packstack on the compute node, running packstack on the controller will execute the puppet scripts on the compute node which installs the nova-compute package and ovs and neutron, on the compute node you shall get something like this: [root at compute1~]# pgrep -l nova 7476 nova-compute [root at compute1 ~]# pgrep -l neutron 8609 neutron-openvsw 8766 neutron-rootwra Some questions, do you've set in packstack answer-file the CONFIG_SSH_KEY directive?: CONFIG_SSH_KEY=/root/.ssh/id_rsa.pub Can you do a password less ssh from the controller into the compute node? How does your packstack run end? Are you getting any errors? Do you have a keystone_admin file at the end of the installation? Best, Arash On Fri, Nov 7, 2014 at 8:19 PM, Afshar, Brian wrote: > Hi Arash, > > > > At this point I am using the EVAL subscription from RedHat with little > support for OpenStack. My answer file contains the information I need to > run the packstack. What is the exact command you used to install packstack > on a nova-compute node? > > > > Regards, > > > > Brian > > > > *From:* Arash Kaffamanesh [mailto:ak at cloudssky.com] > *Sent:* Friday, November 07, 2014 10:56 AM > *To:* Afshar, Brian; rdo-list at redhat.com > *Subject:* Re: [Rdo-list] Installing Nova Compute > > > > Hi Brian, > > > > For RHEL issues I think you'll get better support bei Red Hat directly. > > But if you're using packstack, the only thing which you need is to create > your answer file and assign the IP of the controller and compute node in > that file and run packstack, packstack does the whole work for you. > > > > By the way CentOS 7 or Fedora 20 are the better choice for evaluating > RDO's OpenStack. > > Here is a short blog post for a 2 node deployment: > > > > http://ow.ly/Clrq5 > > > > HTH, > > -Arash > > > > > > > > On Fri, Nov 7, 2014 at 7:43 PM, Afshar, Brian > wrote: > > Hello, > > > > I wanted to find out if anyone has tried installing OpenStack on two > nodes. I have RHEL 7 and have successfully installed the Controller and > have the Dashboard working. I want to install the Nova-Compute and I am > not having any luck. Any feedback would be greatly appreciated. > > > > Regards, > > > > Brian > > > _______________________________________________ > 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 Brian.Afshar at emc.com Fri Nov 7 21:35:02 2014 From: Brian.Afshar at emc.com (Afshar, Brian) Date: Fri, 7 Nov 2014 16:35:02 -0500 Subject: [Rdo-list] Installing Nova Compute In-Reply-To: <54aafbca-43e0-4199-96ba-88e2698aa5ae@emc.com> References: <54aafbca-43e0-4199-96ba-88e2698aa5ae@emc.com> Message-ID: <9E8EE5E176B2BD49913B2F69B369AD830210BF8C45@MX02A.corp.emc.com> Yaniv, I can ssh into each other, not a problem there! Explain what you mean by public key authentication please. What do you mean? Regards, Brian From: Kaul, Yaniv Sent: Friday, November 07, 2014 12:17 PM To: Afshar, Brian; rdo-list at redhat.com Subject: Re: Installing Nova Compute Did installation succeed and it's later, or has installation failed? Can they ssh to each other? All my hosts can ssh to each other via public key auth. and I assume it's needed for successful installation. Y. From: "Afshar, Brian" > Sent: Nov 7, 2014 9:11 PM To: "Kaul, Yaniv" >;rdo-list at redhat.com Subject: RE: Installing Nova Compute Yaniv, Thanks for getting back to me. I have included the IP Address of my host as you have indicated in the answers.txt file. Also, in the nova.conf file, I have the following information that has been modified; my_ip= vncserver_proxyclient_address=$my_ip vncserver_listen=0.0.0.0 glance_host= I have tried twice to install nova-compute with ERRORs when I run the command "systemctl start openstack-nova-compute" during the install. When I run the command "nova_manage host list", it does not list my host that I try to install the nova-compute. Regards, Brian From: Kaul, Yaniv Sent: Friday, November 07, 2014 10:57 AM To: Afshar, Brian; rdo-list at redhat.com Subject: RE: Installing Nova Compute With Packstack, it works OK, provided you give the IP address of the node in CONFIG_COMPUTE_HOSTS= directive. Y. From: rdo-list-bounces at redhat.com [mailto:rdo-list-bounces at redhat.com] On Behalf Of Afshar, Brian Sent: Friday, November 07, 2014 8:43 PM To: rdo-list at redhat.com Subject: [Rdo-list] Installing Nova Compute Hello, I wanted to find out if anyone has tried installing OpenStack on two nodes. I have RHEL 7 and have successfully installed the Controller and have the Dashboard working. I want to install the Nova-Compute and I am not having any luck. Any feedback would be greatly appreciated. Regards, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From ihrachys at redhat.com Mon Nov 10 10:52:48 2014 From: ihrachys at redhat.com (Ihar Hrachyshka) Date: Mon, 10 Nov 2014 11:52:48 +0100 Subject: [Rdo-list] Compute Node without firewall (iptables) and Linux bridge In-Reply-To: <54522FDA.7020002@redhat.com> References: <006b01cff352$fddada80$f9908f80$@progbau.de> <5450B89D.9000604@redhat.com> <007501cff362$c7642f50$562c8df0$@progbau.de> <54511E0B.60604@redhat.com> <002d01cff430$3b2a01d0$b17e0570$@progbau.de> <54522FDA.7020002@redhat.com> Message-ID: <54609900.5000505@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hey, I've looked closer into the issue. Indeed, neutron does not send proper VIF details flags to disable hybrid bridging on nova side. The issue was fixed with the following patch in master: - - https://review.openstack.org/#/c/104240/ I've requested a backport for the patch for Icehouse and Juno: - - https://review.openstack.org/133421 (Icehouse) - - https://review.openstack.org/132759 (Juno) We'll need to wait for the patch to be merged in corresponding branches and be released to reach RDO repos though. So if you're keen to get the functionality ASAP, you can apply the patch to your setup in the meantime. Cheers, /Ihar On 30/10/14 13:32, Ihar Hrachyshka wrote: > Do you use monolithic OVS plugin or ML2 mechanism? If the latter, > then the file is not involved, and you should instead try to change > the value in: > > /usr/lib/python2.6/site-packages/neutron/plugins/ml2/drivers/mech_openvswitch.py > > That said, removal of .py file is not enough to make sure it's > not involved since .pyc file is still there and is used when there > is no .py counterpart. > > On 30/10/14 11:56, Chris wrote: >> I just found out that the file in the compute node: >> /usr/lib/python2.6/site-packages/neutron/plugins/openvswitch/ovs_neutron_plu > >> > > gin.py >> where I edit the portbindings.OVS_HYBRID_PLUG doesn't has any >> effect. I even can delete the whole file, the bridge is still >> being created and everything works normal. > >> Where I can edit the code to prevent the bridge creation? > >> Cheers Chris > >> -----Original Message----- From: Chris >> [mailto:contact at progbau.de] Sent: Thursday, October 30, 2014 >> 01:28 To: 'Ihar Hrachyshka'; 'rdo-list at redhat.com' Subject: RE: >> [Rdo-list] Compute Node without firewall (iptables) and Linux >> bridge > >> What do you mean with re-plugged? During my testing I always >> delete and create new Instances and every time the Linux >> bridge+interfaces gets deleted and created as well. > >> Cheers Chris > >> -----Original Message----- From: Ihar Hrachyshka >> [mailto:ihrachys at redhat.com] Sent: Thursday, October 30, 2014 >> 00:04 To: Chris; rdo-list at redhat.com Subject: Re: [Rdo-list] >> Compute Node without firewall (iptables) and Linux bridge > >> Have you replugged your instances? VIF objects are persisted in >> db, I guess with flags including the one that control whether a >> bridge should be created. > >> Do you still see those bridges created for new instances? > >> /Ihar > >> On 29/10/14 11:26, Chris wrote: >>> Hello, > >>> 1) we just don't need it, we are using the provider network >>> which includes hardware firewalls. 2) We have huge performance >>> problems regarding TCP_CRR / TCP_RR. The OpenStack VMs can >>> deal just half of TCP connections per second compared to our >>> bare metal installations. Throughput (10Gbit NIC) is fine >>> though. Specs VMs and bare metal are of course equal (RAM, >>> Cores, etc.) > >>> Did a lot of testing regarding the performance issues, it >>> happens "after" the both (br-int/br-ex) openvswitches. Upgraded >>> ovs to version 2.3 just fyi. > >>> Cheers Chris > > >>> -----Original Message----- From: rdo-list-bounces at redhat.com >>> [mailto:rdo-list-bounces at redhat.com] On Behalf Of Ihar >>> Hrachyshka Sent: Wednesday, October 29, 2014 16:51 To: >>> rdo-list at redhat.com Subject: Re: [Rdo-list] Compute Node >>> without firewall (iptables) and Linux bridge > >>> On 29/10/14 09:33, Chris wrote: >>>> Hello > > > >>>> I?m looking for a way to disable any firewall feature in one >>>> of our compute nodes and prevent the creation of the Linux >>>> bridge in the data path inside of this compute node. > >>> Can you elaborate on reasons to disable it? Of course it sounds >>> a bit not optimal, but do you have any performance concerns >>> that you try to address in this way? > > >>>> We using the RDO Icehouse release. > > > >>>> Here is the configuration in the compute node: > >>>> #/etc/neutron/plugin.ini > >>>> [securitygroup] > >>>> #firewall_driver = >>>> neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver > >>>> firewall_driver = neutron.agent.firewall.NoopFirewall > >>>> # enable_security_group = True > >>>> enable_security_group = False > > > >>>> #/etc/nova/nova.conf > >>>> firewall_driver = nova.virt.firewall.NoopFirewallDriver > >>>> #security_group_api = neutron > > > >>>> #/etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini > >>>> [securitygroup] > >>>> firewall_driver = neutron.agent.firewall.NoopFirewallDriver > >>>> enable_security_group = False > > > >>>> The firewall seems to be disabled but the bridge and the >>>> interfaces are being still created. > >>>> I found an older post about it: >>>> http://lists.openstack.org/pipermail/openstack/2014-May/007079.html > >>>> But changing ?portbindings.OVS_HYBRID_PLUG" from a >>>> hard-coded "True" to "False" didn?t change anything. > > > >>>> Please advise! > > > >>>> Cheers > >>>> Chris > > > > > >>>> _______________________________________________ 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 > > > > > > _______________________________________________ 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) iQEcBAEBCgAGBQJUYJkAAAoJEC5aWaUY1u57WZkIAII4LUJWK1dMh1BCM+fnZrJl wKsNXNs7kgIT4rmStz2UsNo6m+nwnwT+OM36Jigi4N7XZEDLMOvujx27Efd3o6M7 F1Tl3Ld/To4te0Ayvd1CF+xV6jW6u/NegSrPSeT7edosi8cBeFlOdh3F5NN6lyJe c6LDspyCh8thX71bSlswMK4uHMlX4N856197r3/tuWpDPcRRy9g9n9+wF0avV3pv j8sf2zZupyR54xJbNdjAbOp/qwBmAEeFG+dapWYg5IvMcfH0g9eatbfGRegEb2XU F5AA0q/yve36FCG5FSZFVZLApwpIp5i4u2Dl7pygSUT5UdY9rsxVsHQhs8DlSkw= =DpTW -----END PGP SIGNATURE----- From rbowen at rcbowen.com Mon Nov 10 15:44:00 2014 From: rbowen at rcbowen.com (Rich Bowen) Date: Mon, 10 Nov 2014 10:44:00 -0500 Subject: [Rdo-list] Writeup: RDO community meetup, OpenStack Summit Message-ID: <5460DD40.3040500@rcbowen.com> Here's my notes from the RDO community meetup at the OpenStack Summit last week. If you have major changes/additions/whatever that you'd like to make, you can do that at https://etherpad.openstack.org/p/rdo_community_meetup_summit and I can re-post it later on. Please forgive any omissions or errors - it was very hard to hear a lot of what was said. -------------------- Notes from RDO community meetup at the OpenStack Summit in paris Please forgive errors - notes taken very quickly, and it was very difficult to hear. In attendance, perhaps 60 people, but most (50?) were from Red Hat. The goal of this meetup was to engage folks from outside of Red Hat. These are some (not all) of the non-RedHat people in attendance: Tim Bell - CERN Francesco - Public Health England Arif Ali - OCF plc Jan Ivan - Universities from Norway - Norcom VNFN (?) Comments from these folks on what we're doing right/wrong Tim: The deployability of what we're producing. Prerequisites handled. Works right away with minimal fiddling. First activity of a new CERN IT employee is to spin up a new OpenStack cloud using RDO. (Same at Norcom.) Would like to have EL6 packages - not of everything, but certain pieces. Would like to see more automated handling (reports, tickets) coming out of the Jenkins instance running on TryStack. This is mostly hidden from the community right now, and we need to do a beter job of exposing that. (ACTION: Dan Radez, Lars Kellog-Stedman, Rich, follow up on this.) What tests are we running there? This needs to be documented (or, at least, what we already have needs to be better publicized. Advertise what scenarios we're covering, and make it easy for people to contribute new scenarios that we can run. Publish links to the Jenkins instance and results. (ACTION: Rich needs to follow up with Dan on this.) Better document what bugs go where. Almost everything goes to upstream. Packstack has upstream ticket tracking. Only things directly related to packaging should come to RDO bugzilla. Document when, how often we trigger a packaging run. What's the "barrier to entry"? Could we enable other folks to package the bits they care about? Need to upstream rdopkg, and have more information about our Delorian effort. It sounds like Delorian is a good place to move a lot of our effort, so that packaging activity is happening on trunk, and is all in the open. Derek Higgins talked about Delorian. It's in the openstack-packaging repo on Github. Delorian builds trunk packages. Can we add .deb packages to this project? Derek says that there's no reason that we wouldn't be able to do this, if someone from the community steps up to do this. Need doc on RDO site on what/where the Delorian project is, and how one might get involved. (ACTION: Rich) Hugh asked that we devote some time to discussing how to converge various deployment methods. A matrix of all of the various methods, and when each is useful, would be hugely helpful. Would also facilitate understanding where we can start to combine and converge into a single project. Arif asked about the Foreman installer for EL7. Existing docs are for EL6 and he's been working on get things documented for EL7, but there's some missing bits. Alan talked about the process of getting involved as a contributor to RDO (See https://www.redhat.com/archives/rdo-list/2014-November/msg00018.html ) Tim expressed concern with having to become a Fedora contributor, since just signing the OpenStack CLA was an 8 month process at CERN. Kashyap says that it's not actually a CLA, and that he's going to look into details on this, and get them to Tim and/or to rdo-list (ACTION: Kashyap?) The CentOS Cloud SIG was briefly mentioned, Karsten Wade suggested that we get Karanbir Singh, Alan Pevec, Kashyap Chamarthy, and other intereste people into a hangout to discuss the way forward on this, now that the packaging picture is more widely understood. (Shoud start another thread on this.) Can do better: Clearly communicate, well in advance, what the gaps are in what we (Red Hat) are able to do, do that the community can step up to fill those gaps. The "Nothing for EL6" announcement took a lot of people by surprise, and people would have done things very differently if we had communicated this earlier. Hugh broght up again - how do we get to one uniified deployment/installer? Derek: Important to settle on one set of Puppet modules, from the many overlapping ones that we're currently using. A glossary/matrix of installers needs to be on the RDO site, with capabilities and scenarios. (ACTION: Rich, Hugh, Perry, Arif collaborate on this?) Some that were mentioned were: Spinal Stack (Emilien Macchi - eNovance) QuickStack Instack (James Slagle) Packstack Things began to wrap up at this point. If you have more notes or commentary, please add to this conversation, and/or spin off a new thread on major topics. -- Rich Bowen - rbowen at rcbowen.com - @rbowen http://apachecon.com/ - @apachecon From rdo-info at redhat.com Mon Nov 10 21:44:39 2014 From: rdo-info at redhat.com (RDO Forum) Date: Mon, 10 Nov 2014 21:44:39 +0000 Subject: [Rdo-list] [RDO] Blog Roundup, weeks of October 27th and November 3rd Message-ID: <000001499baa7291-8ed2f729-6cb3-4675-8021-c0deac8ea2f0-000000@email.amazonses.com> rbowen started a discussion. Blog Roundup, weeks of October 27th and November 3rd --- Follow the link below to check it out: https://openstack.redhat.com/forum/discussion/993/blog-roundup-weeks-of-october-27th-and-november-3rd Have a great day! From contact at progbau.de Tue Nov 11 03:24:01 2014 From: contact at progbau.de (Chris) Date: Tue, 11 Nov 2014 10:24:01 +0700 Subject: [Rdo-list] Compute Node without firewall (iptables) and Linux bridge In-Reply-To: <54609900.5000505@redhat.com> References: <006b01cff352$fddada80$f9908f80$@progbau.de> <5450B89D.9000604@redhat.com> <007501cff362$c7642f50$562c8df0$@progbau.de> <54511E0B.60604@redhat.com> <002d01cff430$3b2a01d0$b17e0570$@progbau.de> <54522FDA.7020002@redhat.com> <54609900.5000505@redhat.com> Message-ID: <019701cffd5e$f215c5a0$d64150e0$@progbau.de> Hello Ihar, Thanks for taking care of this! Let's hope the backport for Icehouse will be available soon. We will use it in our setup! Cheers Chris -----Original Message----- From: rdo-list-bounces at redhat.com [mailto:rdo-list-bounces at redhat.com] On Behalf Of Ihar Hrachyshka Sent: Monday, November 10, 2014 17:53 To: rdo-list at redhat.com Subject: Re: [Rdo-list] Compute Node without firewall (iptables) and Linux bridge -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hey, I've looked closer into the issue. Indeed, neutron does not send proper VIF details flags to disable hybrid bridging on nova side. The issue was fixed with the following patch in master: - - https://review.openstack.org/#/c/104240/ I've requested a backport for the patch for Icehouse and Juno: - - https://review.openstack.org/133421 (Icehouse) - - https://review.openstack.org/132759 (Juno) We'll need to wait for the patch to be merged in corresponding branches and be released to reach RDO repos though. So if you're keen to get the functionality ASAP, you can apply the patch to your setup in the meantime. Cheers, /Ihar On 30/10/14 13:32, Ihar Hrachyshka wrote: > Do you use monolithic OVS plugin or ML2 mechanism? If the latter, then > the file is not involved, and you should instead try to change the > value in: > > /usr/lib/python2.6/site-packages/neutron/plugins/ml2/drivers/mech_open > vswitch.py > > That said, removal of .py file is not enough to make sure it's not > involved since .pyc file is still there and is used when there is no > .py counterpart. > > On 30/10/14 11:56, Chris wrote: >> I just found out that the file in the compute node: >> /usr/lib/python2.6/site-packages/neutron/plugins/openvswitch/ovs_neut >> ron_plu > >> > > gin.py >> where I edit the portbindings.OVS_HYBRID_PLUG doesn't has any effect. >> I even can delete the whole file, the bridge is still being created >> and everything works normal. > >> Where I can edit the code to prevent the bridge creation? > >> Cheers Chris > >> -----Original Message----- From: Chris [mailto:contact at progbau.de] >> Sent: Thursday, October 30, 2014 >> 01:28 To: 'Ihar Hrachyshka'; 'rdo-list at redhat.com' Subject: RE: >> [Rdo-list] Compute Node without firewall (iptables) and Linux bridge > >> What do you mean with re-plugged? During my testing I always delete >> and create new Instances and every time the Linux >> bridge+interfaces gets deleted and created as well. > >> Cheers Chris > >> -----Original Message----- From: Ihar Hrachyshka >> [mailto:ihrachys at redhat.com] Sent: Thursday, October 30, 2014 >> 00:04 To: Chris; rdo-list at redhat.com Subject: Re: [Rdo-list] Compute >> Node without firewall (iptables) and Linux bridge > >> Have you replugged your instances? VIF objects are persisted in db, I >> guess with flags including the one that control whether a bridge >> should be created. > >> Do you still see those bridges created for new instances? > >> /Ihar > >> On 29/10/14 11:26, Chris wrote: >>> Hello, > >>> 1) we just don't need it, we are using the provider network which >>> includes hardware firewalls. 2) We have huge performance problems >>> regarding TCP_CRR / TCP_RR. The OpenStack VMs can deal just half of >>> TCP connections per second compared to our bare metal installations. >>> Throughput (10Gbit NIC) is fine though. Specs VMs and bare metal are >>> of course equal (RAM, Cores, etc.) > >>> Did a lot of testing regarding the performance issues, it happens >>> "after" the both (br-int/br-ex) openvswitches. Upgraded ovs to >>> version 2.3 just fyi. > >>> Cheers Chris > > >>> -----Original Message----- From: rdo-list-bounces at redhat.com >>> [mailto:rdo-list-bounces at redhat.com] On Behalf Of Ihar Hrachyshka >>> Sent: Wednesday, October 29, 2014 16:51 To: >>> rdo-list at redhat.com Subject: Re: [Rdo-list] Compute Node without >>> firewall (iptables) and Linux bridge > >>> On 29/10/14 09:33, Chris wrote: >>>> Hello > > > >>>> I?m looking for a way to disable any firewall feature in one of our >>>> compute nodes and prevent the creation of the Linux bridge in the >>>> data path inside of this compute node. > >>> Can you elaborate on reasons to disable it? Of course it sounds a >>> bit not optimal, but do you have any performance concerns that you >>> try to address in this way? > > >>>> We using the RDO Icehouse release. > > > >>>> Here is the configuration in the compute node: > >>>> #/etc/neutron/plugin.ini > >>>> [securitygroup] > >>>> #firewall_driver = >>>> neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriv >>>> er > >>>> firewall_driver = neutron.agent.firewall.NoopFirewall > >>>> # enable_security_group = True > >>>> enable_security_group = False > > > >>>> #/etc/nova/nova.conf > >>>> firewall_driver = nova.virt.firewall.NoopFirewallDriver > >>>> #security_group_api = neutron > > > >>>> #/etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini > >>>> [securitygroup] > >>>> firewall_driver = neutron.agent.firewall.NoopFirewallDriver > >>>> enable_security_group = False > > > >>>> The firewall seems to be disabled but the bridge and the interfaces >>>> are being still created. > >>>> I found an older post about it: >>>> http://lists.openstack.org/pipermail/openstack/2014-May/007079.html > >>>> But changing ?portbindings.OVS_HYBRID_PLUG" from a hard-coded >>>> "True" to "False" didn?t change anything. > > > >>>> Please advise! > > > >>>> Cheers > >>>> Chris > > > > > >>>> _______________________________________________ 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 > > > > > > _______________________________________________ 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) iQEcBAEBCgAGBQJUYJkAAAoJEC5aWaUY1u57WZkIAII4LUJWK1dMh1BCM+fnZrJl wKsNXNs7kgIT4rmStz2UsNo6m+nwnwT+OM36Jigi4N7XZEDLMOvujx27Efd3o6M7 F1Tl3Ld/To4te0Ayvd1CF+xV6jW6u/NegSrPSeT7edosi8cBeFlOdh3F5NN6lyJe c6LDspyCh8thX71bSlswMK4uHMlX4N856197r3/tuWpDPcRRy9g9n9+wF0avV3pv j8sf2zZupyR54xJbNdjAbOp/qwBmAEeFG+dapWYg5IvMcfH0g9eatbfGRegEb2XU F5AA0q/yve36FCG5FSZFVZLApwpIp5i4u2Dl7pygSUT5UdY9rsxVsHQhs8DlSkw= =DpTW -----END PGP SIGNATURE----- _______________________________________________ Rdo-list mailing list Rdo-list at redhat.com https://www.redhat.com/mailman/listinfo/rdo-list From miguelangel at ajo.es Tue Nov 11 07:21:27 2014 From: miguelangel at ajo.es (Miguel Angel) Date: Tue, 11 Nov 2014 08:21:27 +0100 Subject: [Rdo-list] Compute Node without firewall (iptables) and Linux bridge In-Reply-To: <019701cffd5e$f215c5a0$d64150e0$@progbau.de> References: <006b01cff352$fddada80$f9908f80$@progbau.de> <5450B89D.9000604@redhat.com> <007501cff362$c7642f50$562c8df0$@progbau.de> <54511E0B.60604@redhat.com> <002d01cff430$3b2a01d0$b17e0570$@progbau.de> <54522FDA.7020002@redhat.com> <54609900.5000505@redhat.com> <019701cffd5e$f215c5a0$d64150e0$@progbau.de> Message-ID: Hi Chris, If you care a lot about performance, try to make sure that you either: a) Increase MTU on all your tunneling interfaces to avoid fragmentation. or b) work with VLANs instead of VXLAN/GRE. Best regards. Miguel ?ngel. --- irc: ajo / mangelajo Miguel Angel Ajo Pelayo +34 636 52 25 69 skype: ajoajoajo 2014-11-11 4:24 GMT+01:00 Chris : > Hello Ihar, > > Thanks for taking care of this! Let's hope the backport for Icehouse will > be > available soon. > We will use it in our setup! > > Cheers > Chris > > -----Original Message----- > From: rdo-list-bounces at redhat.com [mailto:rdo-list-bounces at redhat.com] On > Behalf Of Ihar Hrachyshka > Sent: Monday, November 10, 2014 17:53 > To: rdo-list at redhat.com > Subject: Re: [Rdo-list] Compute Node without firewall (iptables) and Linux > bridge > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hey, > > I've looked closer into the issue. Indeed, neutron does not send proper VIF > details flags to disable hybrid bridging on nova side. The issue was fixed > with the following patch in master: > > - - https://review.openstack.org/#/c/104240/ > > I've requested a backport for the patch for Icehouse and Juno: > > - - https://review.openstack.org/133421 (Icehouse) > - - https://review.openstack.org/132759 (Juno) > > We'll need to wait for the patch to be merged in corresponding branches and > be released to reach RDO repos though. So if you're keen to get the > functionality ASAP, you can apply the patch to your setup in the meantime. > > Cheers, > /Ihar > > On 30/10/14 13:32, Ihar Hrachyshka wrote: > > Do you use monolithic OVS plugin or ML2 mechanism? If the latter, then > > the file is not involved, and you should instead try to change the > > value in: > > > > /usr/lib/python2.6/site-packages/neutron/plugins/ml2/drivers/mech_open > > vswitch.py > > > > That said, removal of .py file is not enough to make sure it's not > > involved since .pyc file is still there and is used when there is no > > .py counterpart. > > > > On 30/10/14 11:56, Chris wrote: > >> I just found out that the file in the compute node: > >> /usr/lib/python2.6/site-packages/neutron/plugins/openvswitch/ovs_neut > >> ron_plu > > > >> > > > > gin.py > >> where I edit the portbindings.OVS_HYBRID_PLUG doesn't has any effect. > >> I even can delete the whole file, the bridge is still being created > >> and everything works normal. > > > >> Where I can edit the code to prevent the bridge creation? > > > >> Cheers Chris > > > >> -----Original Message----- From: Chris [mailto:contact at progbau.de] > >> Sent: Thursday, October 30, 2014 > >> 01:28 To: 'Ihar Hrachyshka'; 'rdo-list at redhat.com' Subject: RE: > >> [Rdo-list] Compute Node without firewall (iptables) and Linux bridge > > > >> What do you mean with re-plugged? During my testing I always delete > >> and create new Instances and every time the Linux > >> bridge+interfaces gets deleted and created as well. > > > >> Cheers Chris > > > >> -----Original Message----- From: Ihar Hrachyshka > >> [mailto:ihrachys at redhat.com] Sent: Thursday, October 30, 2014 > >> 00:04 To: Chris; rdo-list at redhat.com Subject: Re: [Rdo-list] Compute > >> Node without firewall (iptables) and Linux bridge > > > >> Have you replugged your instances? VIF objects are persisted in db, I > >> guess with flags including the one that control whether a bridge > >> should be created. > > > >> Do you still see those bridges created for new instances? > > > >> /Ihar > > > >> On 29/10/14 11:26, Chris wrote: > >>> Hello, > > > >>> 1) we just don't need it, we are using the provider network which > >>> includes hardware firewalls. 2) We have huge performance problems > >>> regarding TCP_CRR / TCP_RR. The OpenStack VMs can deal just half of > >>> TCP connections per second compared to our bare metal installations. > >>> Throughput (10Gbit NIC) is fine though. Specs VMs and bare metal are > >>> of course equal (RAM, Cores, etc.) > > > >>> Did a lot of testing regarding the performance issues, it happens > >>> "after" the both (br-int/br-ex) openvswitches. Upgraded ovs to > >>> version 2.3 just fyi. > > > >>> Cheers Chris > > > > > >>> -----Original Message----- From: rdo-list-bounces at redhat.com > >>> [mailto:rdo-list-bounces at redhat.com] On Behalf Of Ihar Hrachyshka > >>> Sent: Wednesday, October 29, 2014 16:51 To: > >>> rdo-list at redhat.com Subject: Re: [Rdo-list] Compute Node without > >>> firewall (iptables) and Linux bridge > > > >>> On 29/10/14 09:33, Chris wrote: > >>>> Hello > > > > > > > >>>> I?m looking for a way to disable any firewall feature in one of our > >>>> compute nodes and prevent the creation of the Linux bridge in the > >>>> data path inside of this compute node. > > > >>> Can you elaborate on reasons to disable it? Of course it sounds a > >>> bit not optimal, but do you have any performance concerns that you > >>> try to address in this way? > > > > > >>>> We using the RDO Icehouse release. > > > > > > > >>>> Here is the configuration in the compute node: > > > >>>> #/etc/neutron/plugin.ini > > > >>>> [securitygroup] > > > >>>> #firewall_driver = > >>>> neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriv > >>>> er > > > >>>> firewall_driver = neutron.agent.firewall.NoopFirewall > > > >>>> # enable_security_group = True > > > >>>> enable_security_group = False > > > > > > > >>>> #/etc/nova/nova.conf > > > >>>> firewall_driver = nova.virt.firewall.NoopFirewallDriver > > > >>>> #security_group_api = neutron > > > > > > > >>>> #/etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini > > > >>>> [securitygroup] > > > >>>> firewall_driver = neutron.agent.firewall.NoopFirewallDriver > > > >>>> enable_security_group = False > > > > > > > >>>> The firewall seems to be disabled but the bridge and the interfaces > >>>> are being still created. > > > >>>> I found an older post about it: > >>>> http://lists.openstack.org/pipermail/openstack/2014-May/007079.html > > > >>>> But changing ?portbindings.OVS_HYBRID_PLUG" from a hard-coded > >>>> "True" to "False" didn?t change anything. > > > > > > > >>>> Please advise! > > > > > > > >>>> Cheers > > > >>>> Chris > > > > > > > > > > > >>>> _______________________________________________ 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 > > > > > > > > > > > > _______________________________________________ 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) > > iQEcBAEBCgAGBQJUYJkAAAoJEC5aWaUY1u57WZkIAII4LUJWK1dMh1BCM+fnZrJl > wKsNXNs7kgIT4rmStz2UsNo6m+nwnwT+OM36Jigi4N7XZEDLMOvujx27Efd3o6M7 > F1Tl3Ld/To4te0Ayvd1CF+xV6jW6u/NegSrPSeT7edosi8cBeFlOdh3F5NN6lyJe > c6LDspyCh8thX71bSlswMK4uHMlX4N856197r3/tuWpDPcRRy9g9n9+wF0avV3pv > j8sf2zZupyR54xJbNdjAbOp/qwBmAEeFG+dapWYg5IvMcfH0g9eatbfGRegEb2XU > F5AA0q/yve36FCG5FSZFVZLApwpIp5i4u2Dl7pygSUT5UdY9rsxVsHQhs8DlSkw= > =DpTW > -----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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abushad at gmail.com Tue Nov 11 09:12:03 2014 From: abushad at gmail.com (Abushad P.A) Date: Tue, 11 Nov 2014 13:12:03 +0400 Subject: [Rdo-list] Openvswitch package error during packstack installation In-Reply-To: References: Message-ID: Hi All, > > Please help in resolving the following error while installation of > openstack in RHEL 7.0. > > openvswitch package is showing dependency with a higher kernel version > which i couldn't find as well. > > ERROR : Error appeared during Puppet run: 10.1x.xx.xx_neutron.pp > Error: Execution of '/usr/bin/yum -d 0 -e 0 -y install openvswitch' > returned 1: Error: Package: openvswitch-2.1.2-2.el7.centos.1.x86_64 (epel7) > You will find full trace in log > /var/tmp/packstack/20141111-123738-kECIdL/manifests/10.1x.xx.xx_neutron.pp.log > > > when i try to install openvswitch i get the following dependency error > > yum install openvswitch > > Error: Package: openvswitch-2.1.2-2.el7.centos.1.x86_64 (epel7) > Requires: kernel >= 3.10.0-123.2.1 > Installed: kernel-3.10.0-123.el7.x86_64 (@anaconda/7.0) > kernel = 3.10.0-123.el7 > Available: kernel-debug-3.10.0-123.el7.x86_64 (localrepo) > kernel = 3.10.0-123.el7 > > > > Regards, > Abushad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbowen at redhat.com Tue Nov 11 14:16:46 2014 From: rbowen at redhat.com (Rich Bowen) Date: Tue, 11 Nov 2014 09:16:46 -0500 Subject: [Rdo-list] Writeup: RDO community meetup, OpenStack Summit In-Reply-To: <5460DD40.3040500@rcbowen.com> References: <5460DD40.3040500@rcbowen.com> Message-ID: <54621A4E.1040100@redhat.com> On 11/10/2014 10:44 AM, Rich Bowen wrote: > Here's my notes from the RDO community meetup at the OpenStack Summit > last week. If you have major changes/additions/whatever that you'd like > to make, you can do that at > https://etherpad.openstack.org/p/rdo_community_meetup_summit and I can > re-post it later on. Please forgive any omissions or errors - it was > very hard to hear a lot of what was said. > > -------------------- > > Notes from RDO community meetup at the OpenStack Summit in paris > > Please forgive errors - notes taken very quickly, and it was very > difficult to hear. > > In attendance, perhaps 60 people, but most (50?) were from Red Hat. The > goal of this meetup was to engage folks from outside of Red Hat. These > are some (not all) of the non-RedHat people in attendance: > > Tim Bell - CERN > Francesco - Public Health England > Arif Ali - OCF plc > Jan Ivan - Universities from Norway - Norcom > VNFN (?) Correction, this was INFN -- Italian National Institute for Research in Nuclear and Subnuclear Physics. Thanks to panda on IRC. -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://openstack.redhat.com/ From 18661640013 at 163.com Tue Nov 11 14:29:05 2014 From: 18661640013 at 163.com (Lester Li) Date: Tue, 11 Nov 2014 22:29:05 +0800 (CST) Subject: [Rdo-list] Sahara in Juno release Message-ID: <5a9f44d2.c642.1499f4208ea.Coremail.18661640013@163.com> Hi All, I just installed Juno smoothly. However, I don't see "Data Processing"(Sahara) section in Juno Dashboard after installation. I thought Sahara was already integrated into Juno release. Can anybody explain why I didn't see it in Juno Dashboard? Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From ltoscano at redhat.com Tue Nov 11 14:39:20 2014 From: ltoscano at redhat.com (Luigi Toscano) Date: Tue, 11 Nov 2014 15:39:20 +0100 Subject: [Rdo-list] Sahara in Juno release In-Reply-To: <5a9f44d2.c642.1499f4208ea.Coremail.18661640013@163.com> References: <5a9f44d2.c642.1499f4208ea.Coremail.18661640013@163.com> Message-ID: <1826268.fd0bsFUmGU@whitebase.usersys.redhat.com> On Tuesday 11 of November 2014 22:29:05 Lester Li wrote: > Hi All, > > I just installed Juno smoothly. However, I don't see "Data > Processing"(Sahara) section in Juno Dashboard after installation. I thought > Sahara was already integrated into Juno release. Can anybody explain why I > didn't see it in Juno Dashboard? Hi, the dashboard section should be enabled if the Sahara service is enabled. Can you please confirm Sahara is correctly worked? For example, packstack does not deploy it and you need to manually configure it. Ciao -- Luigi From rbowen at redhat.com Tue Nov 11 14:39:56 2014 From: rbowen at redhat.com (Rich Bowen) Date: Tue, 11 Nov 2014 09:39:56 -0500 Subject: [Rdo-list] What's coming in Kilo? Message-ID: <54621FBC.6060904@redhat.com> Those of you who attended the Kilo design summit in Paris last week, please take a moment this week to write up your notes of what's planned for the Kilo cycle. Many thanks to Flavio ( http://blog.flaper87.com/post/5460ecf0d987d2c17d9c3238/ ) and Matthias ( http://www.matthias-runge.de/2014/11/10/horizon-kilo-summit/ ) who have already done this. -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://openstack.redhat.com/ From 18661640013 at 163.com Tue Nov 11 22:37:45 2014 From: 18661640013 at 163.com (=?UTF-8?B?5p2O5b+X5by6?=) Date: Wed, 12 Nov 2014 06:37:45 +0800 Subject: [Rdo-list] Sahara in Juno release Message-ID: Thank you. I will try. Is there any doc about how to enable sahara in juno? Luigi Toscano ??? >On Tuesday 11 of November 2014 22:29:05 Lester Li wrote: >> Hi All, >> >> I just installed Juno smoothly. However, I don't see "Data >> Processing"(Sahara) section in Juno Dashboard after installation. I thought >> Sahara was already integrated into Juno release. Can anybody explain why I >> didn't see it in Juno Dashboard? > >Hi, the dashboard section should be enabled if the Sahara service is enabled. >Can you please confirm Sahara is correctly worked? For example, packstack does >not deploy it and you need to manually configure it. > >Ciao >-- >Luigi > From ltoscano at redhat.com Wed Nov 12 00:08:59 2014 From: ltoscano at redhat.com (Luigi Toscano) Date: Tue, 11 Nov 2014 19:08:59 -0500 (EST) Subject: [Rdo-list] Sahara in Juno release In-Reply-To: References: Message-ID: <291386596.9925465.1415750939371.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Thank you. I will try. Is there any doc about how to > enable sahara in juno? The upstream one: http://docs.openstack.org/juno/install-guide/install/yum/content/ch_sahara.html or the Sahara one, but the steps are the same: http://docs.openstack.org/developer/sahara/userdoc/installation.guide.html#to-install-with-rdo Ciao -- Luigi From patrick at laimbock.com Wed Nov 12 00:53:57 2014 From: patrick at laimbock.com (Patrick Laimbock) Date: Wed, 12 Nov 2014 01:53:57 +0100 Subject: [Rdo-list] Packstack Juno with existing external network? Message-ID: <5462AFA5.806@laimbock.com> Hi, Setup: workstation with F20 + libvirt/kvm (nested virt enabled) and several VMs like MariaDB Galera cluster VMs, HAProxy VMs, OpenLDAP cluster VMs, RabbitMQ cluster VMs etc. Each VM gets assigned an IP address via DHCP in the 10.0.0.0/24 range. Goal: packstack to create 1 Controller node and 2 Compute nodes (Juno) on 3 freshly provisioned CentOS 7 VMs. The Cirros instance on any of the 2 Compute nodes should have Internet access and it should be possible to access the Cirros instance on its floating IP from the local 10.0.0.0/24 network. I just read: https://openstack.redhat.com/Neutron_with_existing_external_network and was wondering if there is a way I can get that setup pre-defined in a packstack answer file? If yes, any suggestions which vars need to be defined? Thanks, Patrick From contact at progbau.de Wed Nov 12 08:19:26 2014 From: contact at progbau.de (Chris) Date: Wed, 12 Nov 2014 15:19:26 +0700 Subject: [Rdo-list] Compute Node without firewall (iptables) and Linux bridge In-Reply-To: References: <006b01cff352$fddada80$f9908f80$@progbau.de> <5450B89D.9000604@redhat.com> <007501cff362$c7642f50$562c8df0$@progbau.de> <54511E0B.60604@redhat.com> <002d01cff430$3b2a01d0$b17e0570$@progbau.de> <54522FDA.7020002@redhat.com> <54609900.5000505@redhat.com> <019701cffd5e$f215c5a0$d64150e0$@progbau.de> Message-ID: Hello Miguele, thanks for your input! We avoided VXLAN/GRE, we use multi-flat provider network, so each compute node traffic going directly to the provider network without neutron routers in between. Cheers Chris On 2014-11-11 14:21, Miguel Angel wrote: > Hi Chris,? > > If you care a lot about performance, try to make sure that you either: > > a) Increase MTU on all your tunneling interfaces to avoid > fragmentation. > > or > > b) work with VLANs instead of VXLAN/GRE. > > Best regards. > Miguel ?ngel. > > --- > irc: ajo / mangelajoMiguel Angel Ajo Pelayo > +34 636 52 25 69 > skype: ajoajoajo > > 2014-11-11 4:24 GMT+01:00 Chris : > >> Hello Ihar, >> >> Thanks for taking care of this! Let's hope the backport for >> Icehouse will be >> available soon. >> We will use it in our setup! >> >> Cheers >> Chris >> >> -----Original Message----- >> From: rdo-list-bounces at redhat.com >> [mailto:rdo-list-bounces at redhat.com] On >> Behalf Of Ihar Hrachyshka >> Sent: Monday, November 10, 2014 17:53 >> To: rdo-list at redhat.com >> Subject: Re: [Rdo-list] Compute Node without firewall (iptables) >> and Linux >> bridge >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> Hey, >> >> I've looked closer into the issue. Indeed, neutron does not send >> proper VIF >> details flags to disable hybrid bridging on nova side. The issue >> was fixed >> with the following patch in master: >> >> - - https://review.openstack.org/#/c/104240/ [1] >> >> I've requested a backport for the patch for Icehouse and Juno: >> >> - - https://review.openstack.org/133421 [2] (Icehouse) >> - - https://review.openstack.org/132759 [3] (Juno) >> >> We'll need to wait for the patch to be merged in corresponding >> branches and >> be released to reach RDO repos though. So if you're keen to get the >> functionality ASAP, you can apply the patch to your setup in the >> meantime. >> >> Cheers, >> /Ihar >> >> On 30/10/14 13:32, Ihar Hrachyshka wrote: >>> Do you use monolithic OVS plugin or ML2 mechanism? If the latter, >> then >>> the file is not involved, and you should instead try to change >> the >>> value in: >>> >>> >> > /usr/lib/python2.6/site-packages/neutron/plugins/ml2/drivers/mech_open >>> vswitch.py >>> >>> ? That said, removal of .py file is not enough to make sure it's >> not >>> involved since .pyc file is still there and is used when there is >> no >>> .py counterpart. >>> >>> On 30/10/14 11:56, Chris wrote: >>>> I just found out that the file in the compute node: >>>> >> > /usr/lib/python2.6/site-packages/neutron/plugins/openvswitch/ovs_neut >>>> ron_plu >>> >>>> >>> >>> gin.py >>>> where I edit the portbindings.OVS_HYBRID_PLUG doesn't has any >> effect. >>>> I even can delete the whole file, the bridge is still being >> created >>>> and everything works normal. >>> >>>> Where I can edit the code to prevent the bridge creation? >>> >>>> Cheers Chris >>> >>>> -----Original Message----- From: Chris >> [mailto:contact at progbau.de] >>>> Sent: Thursday, October 30, 2014 >>>> 01:28 To: 'Ihar Hrachyshka'; 'rdo-list at redhat.com' Subject: RE: >>>> [Rdo-list] Compute Node without firewall (iptables) and Linux >> bridge >>> >>>> What do you mean with re-plugged? During my testing I always >> delete >>>> and create new Instances and every time the Linux >>>> bridge+interfaces gets deleted and created as well. >>> >>>> Cheers Chris >>> >>>> -----Original Message----- From: Ihar Hrachyshka >>>> [mailto:ihrachys at redhat.com] Sent: Thursday, October 30, 2014 >>>> 00:04 To: Chris; rdo-list at redhat.com Subject: Re: [Rdo-list] >> Compute >>>> Node without firewall (iptables) and Linux bridge >>> >>>> Have you replugged your instances? VIF objects are persisted in >> db, I >>>> guess with flags including the one that control whether a bridge >>>> should be created. >>> >>>> Do you still see those bridges created for new instances? >>> >>>> /Ihar >>> >>>> On 29/10/14 11:26, Chris wrote: >>>>> Hello, >>> >>>>> 1) we just don't need it, we are using the provider network >> which >>>>> includes hardware firewalls. 2) We have huge performance >> problems >>>>> regarding TCP_CRR / TCP_RR. The OpenStack VMs can deal just >> half of >>>>> TCP connections per second compared to our bare metal >> installations. >>>>> Throughput (10Gbit NIC) is fine though. Specs VMs and bare >> metal are >>>>> of course equal (RAM, Cores, etc.) >>> >>>>> Did a lot of testing regarding the performance issues, it >> happens >>>>> "after" the both (br-int/br-ex) openvswitches. Upgraded ovs to >>>>> version 2.3 just fyi. >>> >>>>> Cheers Chris >>> >>> >>>>> -----Original Message----- From: rdo-list-bounces at redhat.com >>>>> [mailto:rdo-list-bounces at redhat.com] On Behalf Of Ihar >> Hrachyshka >>>>> Sent: Wednesday, October 29, 2014 16:51 To: >>>>> rdo-list at redhat.com Subject: Re: [Rdo-list] Compute Node >> without >>>>> firewall (iptables) and Linux bridge >>> >>>>> On 29/10/14 09:33, Chris wrote: >>>>>> Hello >>> >>> >>> >>>>>> I?m looking for a way to disable any firewall feature in one >> of our >>>>>> compute nodes and prevent the creation of the Linux bridge in >> the >>>>>> data path inside of this compute node. >>> >>>>> Can you elaborate on reasons to disable it? Of course it sounds >> a >>>>> bit not optimal, but do you have any performance concerns that >> you >>>>> try to address in this way? >>> >>> >>>>>> We using the RDO Icehouse release. >>> >>> >>> >>>>>> Here is the configuration in the compute node: >>> >>>>>> #/etc/neutron/plugin.ini >>> >>>>>> [securitygroup] >>> >>>>>> #firewall_driver = >>>>>> >> neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriv >>>>>> er >>> >>>>>> ? firewall_driver = neutron.agent.firewall.NoopFirewall >>> >>>>>> # enable_security_group = True >>> >>>>>> enable_security_group = False >>> >>> >>> >>>>>> #/etc/nova/nova.conf >>> >>>>>> firewall_driver = nova.virt.firewall.NoopFirewallDriver >>> >>>>>> #security_group_api = neutron >>> >>> >>> >>>>>> #/etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini >>> >>>>>> [securitygroup] >>> >>>>>> firewall_driver = neutron.agent.firewall.NoopFirewallDriver >>> >>>>>> enable_security_group = False >>> >>> >>> >>>>>> The firewall seems to be disabled but the bridge and the >> interfaces >>>>>> are being still created. >>> >>>>>> I found an older post about it: >>>>>> >> http://lists.openstack.org/pipermail/openstack/2014-May/007079.html >> [4] >>> >>>>>> ? But changing ?portbindings.OVS_HYBRID_PLUG" from a >> hard-coded >>>>>> "True" to "False" didn?t change anything. >>> >>> >>> >>>>>> Please advise! >>> >>> >>> >>>>>> Cheers >>> >>>>>> Chris >>> >>> >>> >>> >>> >>>>>> _______________________________________________ Rdo-list >> mailing >>>>>> list Rdo-list at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/rdo-list [5] >>> >>> >>>>> _______________________________________________ Rdo-list >> mailing >>>>> list Rdo-list at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/rdo-list [5] >>> >>> >>> >>> >>> >>> _______________________________________________ Rdo-list mailing >> list >>> Rdo-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rdo-list [5] >>> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG/MacGPG2 v2.0.22 (Darwin) >> >> iQEcBAEBCgAGBQJUYJkAAAoJEC5aWaUY1u57WZkIAII4LUJWK1dMh1BCM+fnZrJl >> wKsNXNs7kgIT4rmStz2UsNo6m+nwnwT+OM36Jigi4N7XZEDLMOvujx27Efd3o6M7 >> F1Tl3Ld/To4te0Ayvd1CF+xV6jW6u/NegSrPSeT7edosi8cBeFlOdh3F5NN6lyJe >> c6LDspyCh8thX71bSlswMK4uHMlX4N856197r3/tuWpDPcRRy9g9n9+wF0avV3pv >> j8sf2zZupyR54xJbNdjAbOp/qwBmAEeFG+dapWYg5IvMcfH0g9eatbfGRegEb2XU >> F5AA0q/yve36FCG5FSZFVZLApwpIp5i4u2Dl7pygSUT5UdY9rsxVsHQhs8DlSkw= >> =DpTW >> -----END PGP SIGNATURE----- >> >> _______________________________________________ >> Rdo-list mailing list >> Rdo-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rdo-list [5] >> >> _______________________________________________ >> Rdo-list mailing list >> Rdo-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rdo-list [5] > > > > Links: > ------ > [1] https://review.openstack.org/#/c/104240/ > [2] https://review.openstack.org/133421 > [3] https://review.openstack.org/132759 > [4] http://lists.openstack.org/pipermail/openstack/2014-May/007079.html > [5] https://www.redhat.com/mailman/listinfo/rdo-list From miguelangel at ajo.es Wed Nov 12 10:50:04 2014 From: miguelangel at ajo.es (Miguel Angel) Date: Wed, 12 Nov 2014 11:50:04 +0100 Subject: [Rdo-list] Compute Node without firewall (iptables) and Linux bridge In-Reply-To: References: <006b01cff352$fddada80$f9908f80$@progbau.de> <5450B89D.9000604@redhat.com> <007501cff362$c7642f50$562c8df0$@progbau.de> <54511E0B.60604@redhat.com> <002d01cff430$3b2a01d0$b17e0570$@progbau.de> <54522FDA.7020002@redhat.com> <54609900.5000505@redhat.com> <019701cffd5e$f215c5a0$d64150e0$@progbau.de> Message-ID: Hmm, interesting, can you share a diagram of your topology? (just curious) :) Greetings!!, --- irc: ajo / mangelajo Miguel Angel Ajo Pelayo +34 636 52 25 69 skype: ajoajoajo 2014-11-12 9:19 GMT+01:00 Chris : > Hello Miguele, > > thanks for your input! > > We avoided VXLAN/GRE, we use multi-flat provider network, so each compute > node traffic going directly to the provider network without neutron routers > in between. > > Cheers > Chris > > On 2014-11-11 14:21, Miguel Angel wrote: > >> Hi Chris, >> >> If you care a lot about performance, try to make sure that you either: >> >> a) Increase MTU on all your tunneling interfaces to avoid >> fragmentation. >> >> or >> >> b) work with VLANs instead of VXLAN/GRE. >> >> Best regards. >> Miguel ?ngel. >> >> --- >> irc: ajo / mangelajoMiguel Angel Ajo Pelayo >> >> +34 636 52 25 69 >> skype: ajoajoajo >> >> 2014-11-11 4:24 GMT+01:00 Chris : >> >> Hello Ihar, >>> >>> Thanks for taking care of this! Let's hope the backport for >>> Icehouse will be >>> available soon. >>> We will use it in our setup! >>> >>> Cheers >>> Chris >>> >>> -----Original Message----- >>> From: rdo-list-bounces at redhat.com >>> [mailto:rdo-list-bounces at redhat.com] On >>> Behalf Of Ihar Hrachyshka >>> Sent: Monday, November 10, 2014 17:53 >>> To: rdo-list at redhat.com >>> Subject: Re: [Rdo-list] Compute Node without firewall (iptables) >>> and Linux >>> bridge >>> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA512 >>> >>> Hey, >>> >>> I've looked closer into the issue. Indeed, neutron does not send >>> proper VIF >>> details flags to disable hybrid bridging on nova side. The issue >>> was fixed >>> with the following patch in master: >>> >>> - - https://review.openstack.org/#/c/104240/ [1] >>> >>> I've requested a backport for the patch for Icehouse and Juno: >>> >>> - - https://review.openstack.org/133421 [2] (Icehouse) >>> - - https://review.openstack.org/132759 [3] (Juno) >>> >>> >>> We'll need to wait for the patch to be merged in corresponding >>> branches and >>> be released to reach RDO repos though. So if you're keen to get the >>> functionality ASAP, you can apply the patch to your setup in the >>> meantime. >>> >>> Cheers, >>> /Ihar >>> >>> On 30/10/14 13:32, Ihar Hrachyshka wrote: >>> >>>> Do you use monolithic OVS plugin or ML2 mechanism? If the latter, >>>> >>> then >>> >>>> the file is not involved, and you should instead try to change >>>> >>> the >>> >>>> value in: >>>> >>>> >>>> >>> /usr/lib/python2.6/site-packages/neutron/plugins/ml2/drivers/mech_open >> >>> vswitch.py >>>> >>>> That said, removal of .py file is not enough to make sure it's >>>> >>> not >>> >>>> involved since .pyc file is still there and is used when there is >>>> >>> no >>> >>>> .py counterpart. >>>> >>>> On 30/10/14 11:56, Chris wrote: >>>> >>>>> I just found out that the file in the compute node: >>>>> >>>>> >>> /usr/lib/python2.6/site-packages/neutron/plugins/openvswitch/ovs_neut >> >>> ron_plu >>>>> >>>> >>>> >>>>> >>>> gin.py >>>> >>>>> where I edit the portbindings.OVS_HYBRID_PLUG doesn't has any >>>>> >>>> effect. >>> >>>> I even can delete the whole file, the bridge is still being >>>>> >>>> created >>> >>>> and everything works normal. >>>>> >>>> >>>> Where I can edit the code to prevent the bridge creation? >>>>> >>>> >>>> Cheers Chris >>>>> >>>> >>>> -----Original Message----- From: Chris >>>>> >>>> [mailto:contact at progbau.de] >>> >>>> Sent: Thursday, October 30, 2014 >>>>> 01:28 To: 'Ihar Hrachyshka'; 'rdo-list at redhat.com' Subject: RE: >>>>> [Rdo-list] Compute Node without firewall (iptables) and Linux >>>>> >>>> bridge >>> >>>> >>>> What do you mean with re-plugged? During my testing I always >>>>> >>>> delete >>> >>>> and create new Instances and every time the Linux >>>>> bridge+interfaces gets deleted and created as well. >>>>> >>>> >>>> Cheers Chris >>>>> >>>> >>>> -----Original Message----- From: Ihar Hrachyshka >>>>> [mailto:ihrachys at redhat.com] Sent: Thursday, October 30, 2014 >>>>> 00:04 To: Chris; rdo-list at redhat.com Subject: Re: [Rdo-list] >>>>> >>>> Compute >>> >>>> Node without firewall (iptables) and Linux bridge >>>>> >>>> >>>> Have you replugged your instances? VIF objects are persisted in >>>>> >>>> db, I >>> >>>> guess with flags including the one that control whether a bridge >>>>> should be created. >>>>> >>>> >>>> Do you still see those bridges created for new instances? >>>>> >>>> >>>> /Ihar >>>>> >>>> >>>> On 29/10/14 11:26, Chris wrote: >>>>> >>>>>> Hello, >>>>>> >>>>> >>>> 1) we just don't need it, we are using the provider network >>>>>> >>>>> which >>> >>>> includes hardware firewalls. 2) We have huge performance >>>>>> >>>>> problems >>> >>>> regarding TCP_CRR / TCP_RR. The OpenStack VMs can deal just >>>>>> >>>>> half of >>> >>>> TCP connections per second compared to our bare metal >>>>>> >>>>> installations. >>> >>>> Throughput (10Gbit NIC) is fine though. Specs VMs and bare >>>>>> >>>>> metal are >>> >>>> of course equal (RAM, Cores, etc.) >>>>>> >>>>> >>>> Did a lot of testing regarding the performance issues, it >>>>>> >>>>> happens >>> >>>> "after" the both (br-int/br-ex) openvswitches. Upgraded ovs to >>>>>> version 2.3 just fyi. >>>>>> >>>>> >>>> Cheers Chris >>>>>> >>>>> >>>> >>>> -----Original Message----- From: rdo-list-bounces at redhat.com >>>>>> [mailto:rdo-list-bounces at redhat.com] On Behalf Of Ihar >>>>>> >>>>> Hrachyshka >>> >>>> Sent: Wednesday, October 29, 2014 16:51 To: >>>>>> rdo-list at redhat.com Subject: Re: [Rdo-list] Compute Node >>>>>> >>>>> without >>> >>>> firewall (iptables) and Linux bridge >>>>>> >>>>> >>>> On 29/10/14 09:33, Chris wrote: >>>>>> >>>>>>> Hello >>>>>>> >>>>>> >>>> >>>> >>>> I?m looking for a way to disable any firewall feature in one >>>>>>> >>>>>> of our >>> >>>> compute nodes and prevent the creation of the Linux bridge in >>>>>>> >>>>>> the >>> >>>> data path inside of this compute node. >>>>>>> >>>>>> >>>> Can you elaborate on reasons to disable it? Of course it sounds >>>>>> >>>>> a >>> >>>> bit not optimal, but do you have any performance concerns that >>>>>> >>>>> you >>> >>>> try to address in this way? >>>>>> >>>>> >>>> >>>> We using the RDO Icehouse release. >>>>>>> >>>>>> >>>> >>>> >>>> Here is the configuration in the compute node: >>>>>>> >>>>>> >>>> #/etc/neutron/plugin.ini >>>>>>> >>>>>> >>>> [securitygroup] >>>>>>> >>>>>> >>>> #firewall_driver = >>>>>>> >>>>>>> neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriv >>> >>>> er >>>>>>> >>>>>> >>>> firewall_driver = neutron.agent.firewall.NoopFirewall >>>>>>> >>>>>> >>>> # enable_security_group = True >>>>>>> >>>>>> >>>> enable_security_group = False >>>>>>> >>>>>> >>>> >>>> >>>> #/etc/nova/nova.conf >>>>>>> >>>>>> >>>> firewall_driver = nova.virt.firewall.NoopFirewallDriver >>>>>>> >>>>>> >>>> #security_group_api = neutron >>>>>>> >>>>>> >>>> >>>> >>>> #/etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini >>>>>>> >>>>>> >>>> [securitygroup] >>>>>>> >>>>>> >>>> firewall_driver = neutron.agent.firewall.NoopFirewallDriver >>>>>>> >>>>>> >>>> enable_security_group = False >>>>>>> >>>>>> >>>> >>>> >>>> The firewall seems to be disabled but the bridge and the >>>>>>> >>>>>> interfaces >>> >>>> are being still created. >>>>>>> >>>>>> >>>> I found an older post about it: >>>>>>> >>>>>>> http://lists.openstack.org/pipermail/openstack/2014-May/007079.html >>> [4] >>> >>>> >>>> But changing ?portbindings.OVS_HYBRID_PLUG" from a >>>>>>> >>>>>> hard-coded >>> >>>> "True" to "False" didn?t change anything. >>>>>>> >>>>>> >>>> >>>> >>>> Please advise! >>>>>>> >>>>>> >>>> >>>> >>>> Cheers >>>>>>> >>>>>> >>>> Chris >>>>>>> >>>>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ Rdo-list >>>>>>> >>>>>> mailing >>> >>>> list Rdo-list at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/rdo-list [5] >>>>>>> >>>>>> >>>> >>>> _______________________________________________ Rdo-list >>>>>> >>>>> mailing >>> >>>> list Rdo-list at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/rdo-list [5] >>>>>> >>>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ Rdo-list mailing >>>> >>> list >>> >>>> Rdo-list at redhat.com >>>> >>> https://www.redhat.com/mailman/listinfo/rdo-list [5] >>> >>>> >>>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG/MacGPG2 v2.0.22 (Darwin) >>> >>> iQEcBAEBCgAGBQJUYJkAAAoJEC5aWaUY1u57WZkIAII4LUJWK1dMh1BCM+fnZrJl >>> wKsNXNs7kgIT4rmStz2UsNo6m+nwnwT+OM36Jigi4N7XZEDLMOvujx27Efd3o6M7 >>> F1Tl3Ld/To4te0Ayvd1CF+xV6jW6u/NegSrPSeT7edosi8cBeFlOdh3F5NN6lyJe >>> c6LDspyCh8thX71bSlswMK4uHMlX4N856197r3/tuWpDPcRRy9g9n9+wF0avV3pv >>> j8sf2zZupyR54xJbNdjAbOp/qwBmAEeFG+dapWYg5IvMcfH0g9eatbfGRegEb2XU >>> F5AA0q/yve36FCG5FSZFVZLApwpIp5i4u2Dl7pygSUT5UdY9rsxVsHQhs8DlSkw= >>> =DpTW >>> -----END PGP SIGNATURE----- >>> >>> _______________________________________________ >>> Rdo-list mailing list >>> Rdo-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/rdo-list [5] >>> >>> _______________________________________________ >>> Rdo-list mailing list >>> Rdo-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/rdo-list [5] >>> >> >> >> >> Links: >> ------ >> [1] https://review.openstack.org/#/c/104240/ >> [2] https://review.openstack.org/133421 >> [3] https://review.openstack.org/132759 >> [4] http://lists.openstack.org/pipermail/openstack/2014-May/007079.html >> [5] https://www.redhat.com/mailman/listinfo/rdo-list >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbowen at rcbowen.com Wed Nov 12 20:54:44 2014 From: rbowen at rcbowen.com (Rich Bowen) Date: Wed, 12 Nov 2014 15:54:44 -0500 Subject: [Rdo-list] RDO-related Meetups in the coming week (October 6, 2014) In-Reply-To: References: <543301D2.8030400@rcbowen.com> <54368B9C.3030307@rcbowen.com> Message-ID: <5463C914.8030207@rcbowen.com> On 11/05/2014 07:30 AM, Arash Kaffamanesh wrote: > Hi Rich, > > We finally got the date for our OpenStack X Meetup on December 11th in > Cologne: > http://www.meetup.com/__OpenStack-X/ > That will be a whole day workshop beginning with the RDO hands-on > deployment workshop. > I tried to get someone from Red Hat to provide a presentation about > RHOSP, but as you know on that week there is the "OpenStack Tiger Team" > training in Paris and we decided to provide a dedicated meetup for RHOSP > and more next year in February. > > In addition we'll have a praxis workshop on Cologne IT Summit_ on > November 24th, where I'm going to show the power of RDO in action at 15:30: > http://www.cologne-it-summit.de/programm-2014/ > (the page above is unfortunately in German). > > By the way, I borrowed the RDO Community logo shamelessly and placed our > lovely RDO Community as our sponsor on our meetup page, hope that's ok: > http://www.meetup.com/OpenStack-X/sponsors/ Yes, that's awesome! I'll put this event into the promotion pipeline! --Rich -- Rich Bowen - rbowen at rcbowen.com - @rbowen http://apachecon.com/ - @apachecon From rbowen at redhat.com Wed Nov 12 21:40:12 2014 From: rbowen at redhat.com (Rich Bowen) Date: Wed, 12 Nov 2014 16:40:12 -0500 Subject: [Rdo-list] RDO-related meetups in the coming week (November 12, 2014) Message-ID: <5463D3BC.7040105@redhat.com> The following are the meetups I'm aware of in the coming week where RDO enthusiasts will be gathering. If you know of others, please let me know, and/or add them to http://openstack.redhat.com/Events If you attend any of these meetups, please take pictures, and send me some. If you blog about the events (and you should), please send me that, too. * Tonight, OpenStack networking features, gotchas and best practices, Sunnyvale CA - http://www.meetup.com/openstack/events/211282752/ * Thursday, November 13, 2014, Lets meet at Cloud Conference , Johannesburg - http://www.meetup.com/Cloud-Computing-Johannesburg-Meetup/events/205365232/ * Thursday, November 13, 2014, 3rd SDN Meetup, Amsterdam - http://www.meetup.com/Amsterdam-SDN-Group/events/200920542/ * Thursday, November 13, 2014, Building a Highly-Available OpenStack Cloud, Austin, Texas - http://www.meetup.com/OpenStack-Austin/events/207259062/ * Thursday, November 13, 2014, Ceilometer (Telemetry) OpenBook & Paris Summit Open Mike, Cambridge, MA - http://www.meetup.com/Openstack-Boston/events/207276782/ * Thursday, November 13, 2014, II Meetup OpenStack Spain, Madrid - http://www.meetup.com/OpenStack-Spain/events/216321822/ * Friday, November 14, 2014, OpenStack Workshop en Uruguay, Montevideo - http://www.meetup.com/openstack-argentina/events/218635851/ * Tuesday, November 18, 2014, Introducing IRAN OpenStack Community, Tehran - http://www.meetup.com/Iran-OpenStack/events/217541152/ * Tuesday, November 18, 2014, News from the Kilo Paris Summit, Louisville Colorado - http://www.meetup.com/OpenStack-Colorado/events/213850762/ * Tuesday, November 18, 2014, OpenStack Hungary Meetup, Budapest - http://www.meetup.com/OpenStack-Hungary-Meetup-Group/events/212610682/ -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://openstack.redhat.com/ From lars at redhat.com Thu Nov 13 16:38:49 2014 From: lars at redhat.com (Lars Kellogg-Stedman) Date: Thu, 13 Nov 2014 11:38:49 -0500 Subject: [Rdo-list] EPEL orphaned packages Message-ID: <20141113163849.GG20498@redhat.com> I just ran across this post by kbsingh and figured RDO folks might find it relevant: http://www.karan.org/blog/2014/11/13/epel-orphaned-packages-and-their-dependents-to-be-removed-dec-17th/ The tl;dr is that it looks a number of packages in EPEL are going to disappear in the near future unless they acquire new maintainers. This includes a number of things relied on by the RDO packages (like "python-boto", and "pytz", for example). -- Lars Kellogg-Stedman | larsks @ {freenode,twitter,github} Cloud Engineering / OpenStack | http://blog.oddbit.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From dmartls1 at gmail.com Fri Nov 14 17:40:18 2014 From: dmartls1 at gmail.com (David Martin) Date: Fri, 14 Nov 2014 11:40:18 -0600 Subject: [Rdo-list] live block migration on el7 Message-ID: We are running Havana on EL6, we rely pretty heavily on live storage migrations setup like so: block_migration_flag=VIR_MIGRATE_UNDEFINE_SOURCE,VIR_MIGRATE_PEER2PEER,VIR_MIGRATE_NON_SHARED_INC,VIR_MIGRATE_LIVE and it works great. I am currently building a new stack based on EL7 and Juno, however when I attempt to do a migration (nova live-migration --block-migrate x), i receive the following: libvirtError: internal error: unable to execute QEMU command 'migrate': this feature or command is not currently supported I've found a couple of related BZs: https://bugzilla.redhat.com/show_bug.cgi?id=1022393 https://bugzilla.redhat.com/show_bug.cgi?id=1020495 Am I understanding this correctly that they have completely removed this feature from RHEL7? Unless I'm running the RHEV variant of qemu-kvm?? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kchamart at redhat.com Fri Nov 14 19:23:50 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Fri, 14 Nov 2014 20:23:50 +0100 Subject: [Rdo-list] live block migration on el7 In-Reply-To: References: Message-ID: <20141114192350.GB22924@tesla.redhat.com> [Added Eric Blake and Michal Privoznik of libvirt project, in case if they have more to add or correct me.] On Fri, Nov 14, 2014 at 11:40:18AM -0600, David Martin wrote: > We are running Havana on EL6, we rely pretty heavily on live storage > migrations setup like so: > block_migration_flag=VIR_MIGRATE_UNDEFINE_SOURCE,VIR_MIGRATE_PEER2PEER,VIR_MIGRATE_NON_SHARED_INC,VIR_MIGRATE_LIVE > and it works great. > > I am currently building a new stack based on EL7 and Juno, however when I > attempt to do a migration (nova live-migration --block-migrate x), i > receive the following: > libvirtError: internal error: unable to execute QEMU command 'migrate': > this feature or command is not currently supported > > I've found a couple of related BZs: > https://bugzilla.redhat.com/show_bug.cgi?id=1022393 > https://bugzilla.redhat.com/show_bug.cgi?id=1020495 > > Am I understanding this correctly that they have completely removed this > feature from RHEL7? Unless I'm running the RHEV variant of qemu-kvm?? AIUI, seems like your assessment is correct. Reading the bugs, the summary is, in *EL6 the below QMP (QEMU Machine Protocol) arguments to 'migrate' command "blk": block migration, full disk copy "inc": incremental disk copy were inadvertantly introduced. However, all the live block operations should work with: qemu-kvm-rhev (the variant you allude to, above). If you'd like to rebuild them for *EL variant distributions, the SRPMs should be available at http://ftp.redhat.com. -- /kashyap From apevec at gmail.com Sat Nov 15 08:00:47 2014 From: apevec at gmail.com (Alan Pevec) Date: Sat, 15 Nov 2014 09:00:47 +0100 Subject: [Rdo-list] EPEL orphaned packages In-Reply-To: <20141113163849.GG20498@redhat.com> References: <20141113163849.GG20498@redhat.com> Message-ID: > The tl;dr is that it looks a number of packages in EPEL are going to > disappear in the near future unless they acquire new maintainers. > This includes a number of things relied on by the RDO packages (like > "python-boto", and "pytz", for example). boto and pytz in EPEL5 which do not care about, AFAICT kill lists for epel6 and epel7 don't contain anything we depend. Please double check me! Cheers, Alan From bderzhavets at hotmail.com Sat Nov 15 18:28:21 2014 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Sat, 15 Nov 2014 13:28:21 -0500 Subject: [Rdo-list] Problem with dnsmasq after the most recent `yum update` on RDO Juno CentOS 7 In-Reply-To: References: <20141113163849.GG20498@redhat.com>, Message-ID: https://ask.openstack.org/en/question/53326/dhcp-for-private-networks-stoped-working-after-the-most-recent-update-rdo-juno-two-node-cluster-on-centos-7/ https://ask.openstack.org/en/question/53168/need-help-setting-up-neutron-networking/ https://ask.openstack.org/en/question/53331/rdo-instance-network-issue/ Three users have same symptoms - failure to obtain private IP via DHCP (dnsmasq) Thanks. Boris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From apevec at gmail.com Sat Nov 15 21:10:29 2014 From: apevec at gmail.com (Alan Pevec) Date: Sat, 15 Nov 2014 22:10:29 +0100 Subject: [Rdo-list] Problem with dnsmasq after the most recent `yum update` on RDO Juno CentOS 7 In-Reply-To: References: <20141113163849.GG20498@redhat.com> Message-ID: 2014-11-15 19:28 GMT+01:00 Boris Derzhavets : > > https://ask.openstack.org/en/question/53326/dhcp-for-private-networks-stoped-working-after-the-most-recent-update-rdo-juno-two-node-cluster-on-centos-7/ > > https://ask.openstack.org/en/question/53168/need-help-setting-up-neutron-networking/ > > https://ask.openstack.org/en/question/53331/rdo-instance-network-issue/ > > Three users have same symptoms - failure to obtain private IP via DHCP > (dnsmasq) https://bugzilla.redhat.com/show_bug.cgi?id=1163754 Please try yum downgrade openstack-neutron\* python-neutron or get fixed builds[*] until updates are published, they're going through the release process now. Cheers, Alan [*] "Fixed In Version" field in Bugzilla, links to the builds are in comment 6 From Brian.Afshar at emc.com Mon Nov 17 17:25:55 2014 From: Brian.Afshar at emc.com (Afshar, Brian) Date: Mon, 17 Nov 2014 12:25:55 -0500 Subject: [Rdo-list] How to specify range of IP addresses for Nova Message-ID: <9E8EE5E176B2BD49913B2F69B369AD830210BF9122@MX02A.corp.emc.com> I am trying to provide a set of pre-defined network IP addresses given to me in order to create a floating IP range for the instances/VMs. The following command creates a set of IP addresses; however, when I list the floating IP addresses after running this command "# nova-manage floating list", it creates IP addresses that I cannot use. I need to only specify what is available to me and this command doesn't work # nova floating-ip-bulk-create CORRECT-RANGE. Is there are command that I can use to create internal IP addresses of my choice? Thank you, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From swapnil at linux.com Tue Nov 18 05:13:57 2014 From: swapnil at linux.com (Swapnil Jain) Date: Tue, 18 Nov 2014 10:43:57 +0530 Subject: [Rdo-list] Access FTP installed on icehouse from instance Message-ID: <0194077C-AB15-4DF7-A338-8BC05BD83804@Linux.com> I have a FTP server running on my icehouse server. I want to access this FTP server from my instance. If I flush the IPTables rules on icehouse I am able to access ftp from instance to icehouse. In which Chain should I add this iptables rule. ? Swapnil Jain | Swapnil at Linux.com RHC{A,DS,E,VA}, CC{DA,NA}, MCSE, CNE -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From miguelangel at ajo.es Tue Nov 18 17:49:29 2014 From: miguelangel at ajo.es (Miguel Angel) Date: Tue, 18 Nov 2014 18:49:29 +0100 Subject: [Rdo-list] Access FTP installed on icehouse from instance In-Reply-To: <0194077C-AB15-4DF7-A338-8BC05BD83804@Linux.com> References: <0194077C-AB15-4DF7-A338-8BC05BD83804@Linux.com> Message-ID: Hi Swapnil, First, you need to have access to the network (external?) where your icehouse (AIO?) server is running. Then, you should setup iptables as in any other normal server to allow FTP access, because it will be accessed via normal server IP address. Flushing the iptables in general is not a good idea with openstack, because, iptables is heavily relied on for routing, security groups, etc... But otherwise adding specific ACCEPT rules to INPUT table should be ok. --- irc: ajo / mangelajo Miguel Angel Ajo Pelayo +34 636 52 25 69 skype: ajoajoajo 2014-11-18 6:13 GMT+01:00 Swapnil Jain : > I have a FTP server running on my icehouse server. I want to access this > FTP server from my instance. If I flush the IPTables rules on icehouse I am > able to access ftp from instance to icehouse. > > In which Chain should I add this iptables rule. > > > ? > *Swapnil Jain | Swapnil at Linux.com * > RHC{A,DS,E,VA}, CC{DA,NA}, MCSE, CNE > > > _______________________________________________ > 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 akalambu at cisco.com Tue Nov 18 21:49:38 2014 From: akalambu at cisco.com (Ajay Kalambur (akalambu)) Date: Tue, 18 Nov 2014 21:49:38 +0000 Subject: [Rdo-list] Packstack on Juno Message-ID: Hi Does packstack now support Juno if so where are the latest install instructions? Ajay -------------- next part -------------- An HTML attachment was scrubbed... URL: From Brian.Afshar at emc.com Tue Nov 18 22:18:03 2014 From: Brian.Afshar at emc.com (Afshar, Brian) Date: Tue, 18 Nov 2014 17:18:03 -0500 Subject: [Rdo-list] Packstack on Juno In-Reply-To: References: Message-ID: <9E8EE5E176B2BD49913B2F69B369AD830210BF927F@MX02A.corp.emc.com> All packstack support can be found on docs.openstack.org. Hope this copy provides information you need. Regards From: rdo-list-bounces at redhat.com [mailto:rdo-list-bounces at redhat.com] On Behalf Of Ajay Kalambur (akalambu) Sent: Tuesday, November 18, 2014 1:50 PM To: rdo-list at redhat.com Subject: [Rdo-list] Packstack on Juno Hi Does packstack now support Juno if so where are the latest install instructions? Ajay -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Openstack-Install-guide-yum-juno-11-18-2014.pdf Type: application/pdf Size: 1085068 bytes Desc: Openstack-Install-guide-yum-juno-11-18-2014.pdf URL: From apevec at gmail.com Tue Nov 18 22:24:51 2014 From: apevec at gmail.com (Alan Pevec) Date: Tue, 18 Nov 2014 23:24:51 +0100 Subject: [Rdo-list] Packstack on Juno In-Reply-To: References: Message-ID: > Does packstack now support Juno if so where are the latest install > instructions? http://openstack.redhat.com/Quickstart has been updated for RDO Juno on Oct 27: https://www.redhat.com/archives/rdo-list/2014-October/msg00129.html Cheers, Alan From Arne.Wiebalck at cern.ch Wed Nov 19 09:59:46 2014 From: Arne.Wiebalck at cern.ch (Arne Wiebalck) Date: Wed, 19 Nov 2014 09:59:46 +0000 Subject: [Rdo-list] cinder retype and QoS Message-ID: <8652513D-301B-4978-B1AB-3769FCF41238@cern.ch> Hi, >From what I see, "cinder retype? does not work with different QoS types yet, correct? Thanks! Arne -- Arne Wiebalck CERN IT From kchamart at redhat.com Wed Nov 19 10:33:15 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Wed, 19 Nov 2014 11:33:15 +0100 Subject: [Rdo-list] cinder retype and QoS In-Reply-To: <8652513D-301B-4978-B1AB-3769FCF41238@cern.ch> References: <8652513D-301B-4978-B1AB-3769FCF41238@cern.ch> Message-ID: <20141119103315.GA17567@tesla.redhat.com> On Wed, Nov 19, 2014 at 09:59:46AM +0000, Arne Wiebalck wrote: > Hi, > > >From what I see, "cinder retype? does not work with different QoS > >types yet, correct? I'm not a Cinder expert, but looking at the change[1] that introduced the Cinder volume retype functionality, at end of the commit message, it says: [. . .] This version will cause retype operations to fail if the current and new volume types have different: 1. QoS settings that are enforced by the front-end for in-use volumes. 2. encryption settings. Not sure if that (point 1 there) answers your question. [1] https://review.openstack.org/#/c/44881/ -- Add ability to modify volume type -- /kashyap From Arne.Wiebalck at cern.ch Wed Nov 19 10:42:42 2014 From: Arne.Wiebalck at cern.ch (Arne Wiebalck) Date: Wed, 19 Nov 2014 10:42:42 +0000 Subject: [Rdo-list] cinder retype and QoS In-Reply-To: <20141119103315.GA17567@tesla.redhat.com> References: <8652513D-301B-4978-B1AB-3769FCF41238@cern.ch> <20141119103315.GA17567@tesla.redhat.com> Message-ID: On 19 Nov 2014, at 11:33, Kashyap Chamarthy wrote: > On Wed, Nov 19, 2014 at 09:59:46AM +0000, Arne Wiebalck wrote: >> Hi, >> >>> From what I see, "cinder retype? does not work with different QoS >>> types yet, correct? > > I'm not a Cinder expert, but looking at the change[1] that introduced > the Cinder volume retype functionality, at end of the commit message, it > says: > > [. . .] > This version will cause retype operations to fail if the current and > new volume types have different: > 1. QoS settings that are enforced by the front-end for in-use volumes. > 2. encryption settings. > > Not sure if that (point 1 there) answers your question. > > > [1] https://review.openstack.org/#/c/44881/ -- Add ability to modify > volume type Thanks. I saw that change. This and packstack tells me it does not work, at least for a Ceph based backend :) Also the Cinder code (retype being empty in driver.py and not being overwritten rbd.py points) in that direction. http://redhatstackblog.redhat.com/2014/04/15/whats-new-in-icehouse-storage/ gives a slightly different impression IMHO. Cheers, Arne -- Arne Wiebalck CERN IT From contact at progbau.de Wed Nov 19 10:44:39 2014 From: contact at progbau.de (Chris) Date: Wed, 19 Nov 2014 17:44:39 +0700 Subject: [Rdo-list] Compute Node without firewall (iptables) and Linux bridge In-Reply-To: References: <006b01cff352$fddada80$f9908f80$@progbau.de> <5450B89D.9000604@redhat.com> <007501cff362$c7642f50$562c8df0$@progbau.de> <54511E0B.60604@redhat.com> <002d01cff430$3b2a01d0$b17e0570$@progbau.de> <54522FDA.7020002@redhat.com> <54609900.5000505@redhat.com> <019701cffd5e$f215c5a0$d64150e0$@progbau.de> Message-ID: <181bd6b85aba28cfa01dd5a9564c8e0d@we20c.netcup.net> Hello Sure, its actually part of the documentation: http://docs.openstack.org/havana/install-guide/install/apt/content/figures/7/a/common/figures/UseCase-MultiFlat.png On 2014-11-12 17:50, Miguel Angel wrote: > Hmm, interesting, can you share a diagram of your topology? > (just curious) :) > > Greetings!!, > > --- > irc: ajo / mangelajoMiguel Angel Ajo Pelayo > +34 636 52 25 69 > skype: ajoajoajo > > 2014-11-12 9:19 GMT+01:00 Chris : > >> Hello Miguele, >> >> thanks for your input! >> >> We avoided VXLAN/GRE, we use multi-flat provider network, so each >> compute node traffic going directly to the provider network without >> neutron routers in between. >> >> Cheers >> Chris >> >> On 2014-11-11 14:21, Miguel Angel wrote: >> Hi Chris,? >> >> If you care a lot about performance, try to make sure that you >> either: >> >> a) Increase MTU on all your tunneling interfaces to avoid >> fragmentation. >> >> or >> >> b) work with VLANs instead of VXLAN/GRE. >> >> Best regards. >> Miguel ?ngel. >> >> --- >> irc: ajo / mangelajoMiguel Angel Ajo Pelayo >> >> +34 636 52 25 69 [1] >> skype: ajoajoajo >> >> 2014-11-11 4:24 GMT+01:00 Chris : >> >> Hello Ihar, >> >> Thanks for taking care of this! Let's hope the backport for >> Icehouse will be >> available soon. >> We will use it in our setup! >> >> Cheers >> Chris >> >> -----Original Message----- >> From: rdo-list-bounces at redhat.com >> [mailto:rdo-list-bounces at redhat.com] On >> Behalf Of Ihar Hrachyshka >> Sent: Monday, November 10, 2014 17:53 >> To: rdo-list at redhat.com >> Subject: Re: [Rdo-list] Compute Node without firewall (iptables) >> and Linux >> bridge >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> Hey, >> >> I've looked closer into the issue. Indeed, neutron does not send >> proper VIF >> details flags to disable hybrid bridging on nova side. The issue >> was fixed >> with the following patch in master: >> >> - - https://review.openstack.org/#/c/104240/ [2] [1] >> >> I've requested a backport for the patch for Icehouse and Juno: >> >> - - https://review.openstack.org/133421 [3] [2] (Icehouse) >> - - https://review.openstack.org/132759 [4] [3] (Juno) >> >> We'll need to wait for the patch to be merged in corresponding >> branches and >> be released to reach RDO repos though. So if you're keen to get the >> functionality ASAP, you can apply the patch to your setup in the >> meantime. >> >> Cheers, >> /Ihar >> >> On 30/10/14 13:32, Ihar Hrachyshka wrote: >> Do you use monolithic OVS plugin or ML2 mechanism? If the latter, >> then >> the file is not involved, and you should instead try to change >> the >> value in: > > /usr/lib/python2.6/site-packages/neutron/plugins/ml2/drivers/mech_open > >>> vswitch.py >>> >>> ? That said, removal of .py file is not enough to make sure it's >> not >> >>> involved since .pyc file is still there and is used when there is >> no >> .py counterpart. >> >> On 30/10/14 11:56, Chris wrote: >> I just found out that the file in the compute node: > > /usr/lib/python2.6/site-packages/neutron/plugins/openvswitch/ovs_neut > >> ron_plu >> >> gin.py >> where I edit the portbindings.OVS_HYBRID_PLUG doesn't has any > effect. > >>> I even can delete the whole file, the bridge is still being > created > >>> and everything works normal. >> >>> Where I can edit the code to prevent the bridge creation? >> >>> Cheers Chris >> >>> -----Original Message----- From: Chris > [mailto:contact at progbau.de] > >>> Sent: Thursday, October 30, 2014 >>> 01:28 To: 'Ihar Hrachyshka'; 'rdo-list at redhat.com' Subject: RE: >>> [Rdo-list] Compute Node without firewall (iptables) and Linux > bridge > >>> What do you mean with re-plugged? During my testing I always > delete > >>> and create new Instances and every time the Linux >>> bridge+interfaces gets deleted and created as well. >> >>> Cheers Chris >> >>> -----Original Message----- From: Ihar Hrachyshka >>> [mailto:ihrachys at redhat.com] Sent: Thursday, October 30, 2014 >>> 00:04 To: Chris; rdo-list at redhat.com Subject: Re: [Rdo-list] > Compute > >>> Node without firewall (iptables) and Linux bridge >> >>> Have you replugged your instances? VIF objects are persisted in > db, I > >>> guess with flags including the one that control whether a bridge >>> should be created. >> >>> Do you still see those bridges created for new instances? >> >>> /Ihar >> >> On 29/10/14 11:26, Chris wrote: >> Hello, > >>> 1) we just don't need it, we are using the provider network > which > >> includes hardware firewalls. 2) We have huge performance > problems > >> regarding TCP_CRR / TCP_RR. The OpenStack VMs can deal just > half of > >> TCP connections per second compared to our bare metal > installations. > >> Throughput (10Gbit NIC) is fine though. Specs VMs and bare > metal are > >> of course equal (RAM, Cores, etc.) > >>> Did a lot of testing regarding the performance issues, it > happens > >> "after" the both (br-int/br-ex) openvswitches. Upgraded ovs to >> version 2.3 just fyi. > >>> Cheers Chris > >>> -----Original Message----- From: rdo-list-bounces at redhat.com >>> [mailto:rdo-list-bounces at redhat.com] On Behalf Of Ihar > Hrachyshka > >> Sent: Wednesday, October 29, 2014 16:51 To: >> rdo-list at redhat.com Subject: Re: [Rdo-list] Compute Node > without > >> firewall (iptables) and Linux bridge > >> On 29/10/14 09:33, Chris wrote: >> Hello > >> I?m looking for a way to disable any firewall feature in one > of our > >> compute nodes and prevent the creation of the Linux bridge in > the > >> data path inside of this compute node. > >>> Can you elaborate on reasons to disable it? Of course it sounds > a > >> bit not optimal, but do you have any performance concerns that > you > >> try to address in this way? > >> We using the RDO Icehouse release. > >> Here is the configuration in the compute node: > >> #/etc/neutron/plugin.ini > >> [securitygroup] > >> #firewall_driver = > neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriv > >> er > >> ? firewall_driver = neutron.agent.firewall.NoopFirewall > >> # enable_security_group = True > >> enable_security_group = False > >> #/etc/nova/nova.conf > >> firewall_driver = nova.virt.firewall.NoopFirewallDriver > >> #security_group_api = neutron > >> #/etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini > >> [securitygroup] > >> firewall_driver = neutron.agent.firewall.NoopFirewallDriver > >> enable_security_group = False > >> The firewall seems to be disabled but the bridge and the > interfaces > >> are being still created. > >> I found an older post about it: > http://lists.openstack.org/pipermail/openstack/2014-May/007079.html > [6] > [4] > >> ? But changing ?portbindings.OVS_HYBRID_PLUG" from a > hard-coded > >> "True" to "False" didn?t change anything. > >> Please advise! > >> Cheers > >> Chris > >> _______________________________________________ Rdo-list > mailing > >> list Rdo-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rdo-list [5] [5] > >>> _______________________________________________ Rdo-list > mailing > >> list Rdo-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rdo-list [5] [5] > > _______________________________________________ Rdo-list mailing > list > >> Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list [5] [5] > >> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > > iQEcBAEBCgAGBQJUYJkAAAoJEC5aWaUY1u57WZkIAII4LUJWK1dMh1BCM+fnZrJl > wKsNXNs7kgIT4rmStz2UsNo6m+nwnwT+OM36Jigi4N7XZEDLMOvujx27Efd3o6M7 > F1Tl3Ld/To4te0Ayvd1CF+xV6jW6u/NegSrPSeT7edosi8cBeFlOdh3F5NN6lyJe > c6LDspyCh8thX71bSlswMK4uHMlX4N856197r3/tuWpDPcRRy9g9n9+wF0avV3pv > j8sf2zZupyR54xJbNdjAbOp/qwBmAEeFG+dapWYg5IvMcfH0g9eatbfGRegEb2XU > F5AA0q/yve36FCG5FSZFVZLApwpIp5i4u2Dl7pygSUT5UdY9rsxVsHQhs8DlSkw= > =DpTW > -----END PGP SIGNATURE----- > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list [5] [5] > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list [5] [5] > > Links: > ------ > [1] https://review.openstack.org/#/c/104240/ [2] > [2] https://review.openstack.org/133421 [3] > [3] https://review.openstack.org/132759 [4] > [4] > http://lists.openstack.org/pipermail/openstack/2014-May/007079.html > [6] > [5] https://www.redhat.com/mailman/listinfo/rdo-list [5] > > > > Links: > ------ > [1] tel:%2B34%20636%2052%2025%2069 > [2] https://review.openstack.org/#/c/104240/ > [3] https://review.openstack.org/133421 > [4] https://review.openstack.org/132759 > [5] https://www.redhat.com/mailman/listinfo/rdo-list > [6] http://lists.openstack.org/pipermail/openstack/2014-May/007079.html From kchamart at redhat.com Wed Nov 19 12:51:11 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Wed, 19 Nov 2014 13:51:11 +0100 Subject: [Rdo-list] cinder retype and QoS In-Reply-To: References: <8652513D-301B-4978-B1AB-3769FCF41238@cern.ch> <20141119103315.GA17567@tesla.redhat.com> Message-ID: <20141119125111.GB17567@tesla.redhat.com> On Wed, Nov 19, 2014 at 10:42:42AM +0000, Arne Wiebalck wrote: > > On 19 Nov 2014, at 11:33, Kashyap Chamarthy wrote: > > > On Wed, Nov 19, 2014 at 09:59:46AM +0000, Arne Wiebalck wrote: > >> Hi, > >> > >>> From what I see, "cinder retype? does not work with different QoS > >>> types yet, correct? > > > > I'm not a Cinder expert, but looking at the change[1] that introduced > > the Cinder volume retype functionality, at end of the commit message, it > > says: > > > > [. . .] > > This version will cause retype operations to fail if the current and > > new volume types have different: > > 1. QoS settings that are enforced by the front-end for in-use volumes. > > 2. encryption settings. > > > > Not sure if that (point 1 there) answers your question. > > > > > > [1] https://review.openstack.org/#/c/44881/ -- Add ability to modify > > volume type > > Thanks. I saw that change. This and packstack tells me it does not > work, at least for a Ceph based backend :) Hmm, let's see if any Packstack/Cinder developers will weigh in here. > Also the Cinder code (retype being empty in driver.py and not being > overwritten rbd.py points) in that direction. > > http://redhatstackblog.redhat.com/2014/04/15/whats-new-in-icehouse-storage/ > gives a slightly different impression IMHO. I cannot speak for the author of that post, but probably it's talking about what's in the upstream. :-) -- /kashyap From Arne.Wiebalck at cern.ch Wed Nov 19 14:20:05 2014 From: Arne.Wiebalck at cern.ch (Arne Wiebalck) Date: Wed, 19 Nov 2014 14:20:05 +0000 Subject: [Rdo-list] cinder retype and QoS In-Reply-To: <20141119125111.GB17567@tesla.redhat.com> References: <8652513D-301B-4978-B1AB-3769FCF41238@cern.ch> <20141119103315.GA17567@tesla.redhat.com> <20141119125111.GB17567@tesla.redhat.com> Message-ID: <39075A27-EABC-4140-B7CB-ADD157BDB342@cern.ch> On 19 Nov 2014, at 13:51, Kashyap Chamarthy wrote: [snip] >> Thanks. I saw that change. This and packstack tells me it does not >> work, at least for a Ceph based backend :) > > Hmm, let's see if any Packstack/Cinder developers will weigh in here. > >> Also the Cinder code (retype being empty in driver.py and not being >> overwritten rbd.py points) in that direction. >> >> http://redhatstackblog.redhat.com/2014/04/15/whats-new-in-icehouse-storage/ >> gives a slightly different impression IMHO. > > I cannot speak for the author of that post, but probably it's talking > about what's in the upstream. :-) >From what I understand, retype needs to be implemented on a per driver level, and that?s simply not the case for the rbd driver yet. Below is a small patch to the rbd driver that ?implements? the retype function and subsequently allows for QoS changes of Cinder volumes on Ceph. (Not sure at all if that breaks things elsewhere :) ?> # diff -u /usr/lib/python2.6/site-packages/cinder/volume/drivers/rbd.py.orig /usr/lib/python2.6/site-packages/cinder/volume/drivers/rbd.py --- /usr/lib/python2.6/site-packages/cinder/volume/drivers/rbd.py.orig 2014-11-19 11:44:43.739979396 +0100 +++ /usr/lib/python2.6/site-packages/cinder/volume/drivers/rbd.py 2014-11-19 14:28:27.853345650 +0100 @@ -651,6 +651,29 @@ new_name = "%s.deleted" % (volume_name) self.rbd.RBD().rename(client.ioctx, volume_name, new_name) + def retype(self, ctxt, volume, new_type, diff, host): + """Retype a volume, QoS change only.""" + LOG.info('Retype volume request %(vol)s to be %(type)s ' + '(host: %(host)s), diff %(diff)s.' % + {'vol': volume['name'], + 'type': new_type, + 'host': host, + 'diff': diff}) + + if volume['host'] != host['host']: + LOG.error('Retype with host migration not supported') + return False + + if diff['encryption']: + LOG.error('Retype of encryption type not supported') + return False + + if diff['extra_specs']: + LOG.error('Retype of extra_specs not supported') + return False + + return True + <-- Cheers, Arne -- Arne Wiebalck CERN IT From kchamart at redhat.com Wed Nov 19 17:36:13 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Wed, 19 Nov 2014 12:36:13 -0500 (EST) Subject: [Rdo-list] cinder retype and QoS In-Reply-To: <39075A27-EABC-4140-B7CB-ADD157BDB342@cern.ch> References: <8652513D-301B-4978-B1AB-3769FCF41238@cern.ch> <20141119103315.GA17567@tesla.redhat.com> <20141119125111.GB17567@tesla.redhat.com> <39075A27-EABC-4140-B7CB-ADD157BDB342@cern.ch> Message-ID: <1242747200.5412825.1416418573734.JavaMail.zimbra@redhat.com> [. . .] > From what I understand, retype needs to be implemented on a per driver > level, and that?s simply not the case for the rbd driver yet. > > Below is a small patch to the rbd driver that ?implements? the retype > function > and subsequently allows for QoS changes of Cinder volumes on Ceph. > > (Not sure at all if that breaks things elsewhere :) If you have time, you might want to submit an upstream review request and let the CI infrastructure handle that for you. -- /kashyap > > ?> > # diff -u /usr/lib/python2.6/site-packages/cinder/volume/drivers/rbd.py.orig > /usr/lib/python2.6/site-packages/cinder/volume/drivers/rbd.py > --- /usr/lib/python2.6/site-packages/cinder/volume/drivers/rbd.py.orig > 2014-11-19 11:44:43.739979396 +0100 > +++ /usr/lib/python2.6/site-packages/cinder/volume/drivers/rbd.py 2014-11-19 > 14:28:27.853345650 +0100 > @@ -651,6 +651,29 @@ > new_name = "%s.deleted" % (volume_name) > self.rbd.RBD().rename(client.ioctx, volume_name, new_name) > > + def retype(self, ctxt, volume, new_type, diff, host): > + """Retype a volume, QoS change only.""" > + LOG.info('Retype volume request %(vol)s to be %(type)s ' > + '(host: %(host)s), diff %(diff)s.' % > + {'vol': volume['name'], > + 'type': new_type, > + 'host': host, > + 'diff': diff}) > + > + if volume['host'] != host['host']: > + LOG.error('Retype with host migration not supported') > + return False > + > + if diff['encryption']: > + LOG.error('Retype of encryption type not supported') > + return False > + > + if diff['extra_specs']: > + LOG.error('Retype of extra_specs not supported') > + return False > + > + return True > + > <-- > > Cheers, > Arne > > -- > Arne Wiebalck > CERN IT > > From Arne.Wiebalck at cern.ch Thu Nov 20 07:51:40 2014 From: Arne.Wiebalck at cern.ch (Arne Wiebalck) Date: Thu, 20 Nov 2014 07:51:40 +0000 Subject: [Rdo-list] cinder retype and QoS In-Reply-To: <1242747200.5412825.1416418573734.JavaMail.zimbra@redhat.com> References: <8652513D-301B-4978-B1AB-3769FCF41238@cern.ch> <20141119103315.GA17567@tesla.redhat.com> <20141119125111.GB17567@tesla.redhat.com> <39075A27-EABC-4140-B7CB-ADD157BDB342@cern.ch> <1242747200.5412825.1416418573734.JavaMail.zimbra@redhat.com> Message-ID: On 19 Nov 2014, at 18:36, Kashyap Chamarthy wrote: > [. . .] > >> From what I understand, retype needs to be implemented on a per driver >> level, and that?s simply not the case for the rbd driver yet. >> >> Below is a small patch to the rbd driver that ?implements? the retype >> function >> and subsequently allows for QoS changes of Cinder volumes on Ceph. >> >> (Not sure at all if that breaks things elsewhere :) > > If you have time, you might want to submit an upstream review > request and let the CI infrastructure handle that for you. Done: https://review.openstack.org/#/c/135874/ Cheers, Arne -- Arne Wiebalck CERN IT From kchamart at redhat.com Thu Nov 20 09:54:05 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Thu, 20 Nov 2014 10:54:05 +0100 Subject: [Rdo-list] cinder retype and QoS In-Reply-To: References: <8652513D-301B-4978-B1AB-3769FCF41238@cern.ch> <20141119103315.GA17567@tesla.redhat.com> <20141119125111.GB17567@tesla.redhat.com> <39075A27-EABC-4140-B7CB-ADD157BDB342@cern.ch> <1242747200.5412825.1416418573734.JavaMail.zimbra@redhat.com> Message-ID: <20141120095405.GA21761@tesla.redhat.com> On Thu, Nov 20, 2014 at 07:51:40AM +0000, Arne Wiebalck wrote: > > On 19 Nov 2014, at 18:36, Kashyap Chamarthy wrote: > > > [. . .] > > > >> From what I understand, retype needs to be implemented on a per > >> driver level, and that?s simply not the case for the rbd driver > >> yet. > >> > >> Below is a small patch to the rbd driver that ?implements? the > >> retype function and subsequently allows for QoS changes of Cinder > >> volumes on Ceph. > >> > >> (Not sure at all if that breaks things elsewhere :) > > > > If you have time, you might want to submit an upstream review > > request and let the CI infrastructure handle that for you. > > Done: https://review.openstack.org/#/c/135874/ Nice. It needs a respin -- PEP-8 indentation errors, commented in the review. -- /kashyap From bruno.bompastor at cern.ch Thu Nov 20 10:55:34 2014 From: bruno.bompastor at cern.ch (Bruno Luis Dos Santos Bompastor) Date: Thu, 20 Nov 2014 10:55:34 +0000 Subject: [Rdo-list] Plans for heat-cfntools on EPEL7 Message-ID: Hi everyone, I would like to know what are the plans to include heat-cfntools package in EPEL7 repo? At CERN we want to create our VM images with heat-cfntools but RDO repo comes with a lot of packages that we don?t want? Thanks, Bruno Bompastor. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jan.van.Eldik at cern.ch Thu Nov 20 11:17:42 2014 From: Jan.van.Eldik at cern.ch (Jan van Eldik) Date: Thu, 20 Nov 2014 12:17:42 +0100 Subject: [Rdo-list] Plans for heat-cfntools on EPEL7 In-Reply-To: References: Message-ID: <546DCDD6.9060304@cern.ch> Hi, > I would like to know what are the plans to include heat-cfntools package > in EPEL7 repo? > > At CERN we want to create our VM images with heat-cfntools but RDO repo > comes with a lot of packages that we don?t want? Our problem is: how to create an image that includes heat-cfntools + its dependencies, and make sure that they get updated while also making sure that no other RDO packages get updated. Today that would be possible with a "includepkgs=heat-cfntools" in the RDO yum repo definition, but this might break if future versions of the package would introduce dependencies in other RDO packages. We have had similar concerns for the cloud-init RPM in the past, where we have alternated between EPEL6 and RDO as our upstream. It us not obvious to us how to make that choice, so your thoughts and comments would be much appreciated. thanks, cheers, Jan From gilles at redhat.com Thu Nov 20 11:49:04 2014 From: gilles at redhat.com (Gilles Dubreuil) Date: Thu, 20 Nov 2014 22:49:04 +1100 Subject: [Rdo-list] Follow up from RDO meetup at Summit: Tools consolidation Message-ID: <546DD530.8090207@redhat.com> Hi, Following up from the RDO meeting we had at Kilo Summit in Paris on Wednesday 5 Nov. 2014. Firstly, sorry for this late post, I had a week off after the summit. During the meeting, Hugh Brock opened a discussion about the evolution of the various tools we have for deploying Openstack with RDO, such as Packstack, Quickstack (used by OpenStack Foreman Installer [OFI] and Staypuft). Not to mention Enovance and also maturing TripleO. Meanwhile there is a common denominator for all above tools: the Puppet modules (well this is only partly true for TripleO) This where I've been involved, working lately to provide more automation for testing (CI/CD) around those puppet modules along with Packstack/Quickstack. It turned out that although system management is very important in wide scale production environments, it's not needed for deployment testing. This is possible because the orchestration logic resides in the puppet modules. Moreover, to be able to do so without loosing any functionality is a key factor to speed up tests. Actually Quickstack can be tested without the Foreman or Puppet server, using only a "puppet apply" command on each node. Although in the future, a puppet master might be needed for orchestration, as of today it's not needed and Quickstack HA controllers can be deployed "masterless" and the compute nodes is work in progress. The details are available here: https://github.com/gildub/astapor/blob/Hiera/README%2Bfix1/puppet/modules/quickstack/data/README.md Thank you to provide feedback if interested. Regards, Gilles From hguemar at fedoraproject.org Thu Nov 20 12:11:35 2014 From: hguemar at fedoraproject.org (=?UTF-8?Q?Ha=C3=AFkel?=) Date: Thu, 20 Nov 2014 13:11:35 +0100 Subject: [Rdo-list] Plans for heat-cfntools on EPEL7 In-Reply-To: <546DCDD6.9060304@cern.ch> References: <546DCDD6.9060304@cern.ch> Message-ID: If you want to make sure that no packages is updated from RDO repositories, you may want to use yum-plugin-priorities. As for heat-cfntools, if it introduces new dependencies, it's likely to be self-contained python modules, so I wouldn't worry much about it. Regards, H. From gchamoul at redhat.com Fri Nov 21 13:37:56 2014 From: gchamoul at redhat.com (=?iso-8859-1?Q?Ga=EBl?= Chamoulaud) Date: Fri, 21 Nov 2014 14:37:56 +0100 Subject: [Rdo-list] cinder retype and QoS In-Reply-To: References: <8652513D-301B-4978-B1AB-3769FCF41238@cern.ch> <20141119103315.GA17567@tesla.redhat.com> Message-ID: <20141121133756.GA23339@strider.cdg.redhat.com> On 19/Nov/2014 @ 10:42, Arne Wiebalck wrote: > > On 19 Nov 2014, at 11:33, Kashyap Chamarthy wrote: > > > On Wed, Nov 19, 2014 at 09:59:46AM +0000, Arne Wiebalck wrote: > >> Hi, > >> > >>> From what I see, "cinder retype? does not work with different QoS > >>> types yet, correct? > > > > I'm not a Cinder expert, but looking at the change[1] that introduced > > the Cinder volume retype functionality, at end of the commit message, it > > says: > > > > [. . .] > > This version will cause retype operations to fail if the current and > > new volume types have different: > > 1. QoS settings that are enforced by the front-end for in-use volumes. > > 2. encryption settings. > > > > Not sure if that (point 1 there) answers your question. > > > > > > [1] https://review.openstack.org/#/c/44881/ -- Add ability to modify > > volume type > > Thanks. I saw that change. This and packstack tells me it does not work ... Can you give me more information about this statement ? -- Ga?l Chamoulaud Openstack Engineering Mail: [gchamoul|gael] at redhat dot com IRC: strider/gchamoul (Red Hat), gchamoul (Freenode) GnuPG Key ID: 7F4B301 C75F 15C2 A7FD EBC3 7B2D CE41 0077 6A4B A7F4 B301 Freedom...Courage...Commitment...Accountability -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From viorel at athabascau.ca Sun Nov 23 07:08:26 2014 From: viorel at athabascau.ca (Viorel Tabara) Date: Sun, 23 Nov 2014 00:08:26 -0700 Subject: [Rdo-list] cinder-api[14407]: segfault at 7fc84636f7e0 ip 00007fc84636f7e0 sp 00007fff3110a468 error 15 in multiarray.so[7fc846369000+d000] Message-ID: <547187EA.2040001@athabascau.ca> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I'm hoping that someone can point me into the right direction... Working with packages from: https://repos.fedorapeople.org/repos/openstack/openstack-juno/fedora-20/ the segfault happens on a fresh install, whenever I attempt to create a volume. Here's the abrt info: Directory: /var/tmp/abrt/ccpp-2014-11-22-23:16:22-22114 abrt_version: 2.2.2 analyzer: CCpp architecture: x86_64 cmdline: /usr/bin/python2 /usr/bin/cinder-api --config-file /usr/share/cinder/cinder-dist.conf --config-file /etc/cinder/cinder.conf --logfile /var/log/cinder/api.log component: openstack-cinder count: 1 executable: /usr/bin/python2.7 hostname: stuff.can.local kernel: 3.16.7-200.fc20.x86_64 last_occurrence: 1416723382 os_release: Fedora release 20 (Heisenbug) package: openstack-cinder-2014.2-1.fc22 pid: 22114 pkg_arch: noarch pkg_epoch: 0 pkg_name: openstack-cinder pkg_release: 1.fc22 pkg_version: 2014.2 pwd: / reason: python2.7 killed by SIGSEGV runlevel: N 5 time: Sat 22 Nov 2014 11:16:22 PM MST type: CCpp uid: 165 username: cinder uuid: c9b2d07d3a08e30d5bb602411e7628ac38ac2755 coredump: Binary file, 90284032 bytes dso_list: Text file, 16184 bytes maps: Text file, 74532 bytes cgroup: :10:hugetlb:/ :9:perf_event:/ :8:blkio:/ :7:net_cls,net_prio:/ :6:freezer:/ :5:devices:/system.slice :4:memory:/ :3:cpu,cpuacct:/ :2:cpuset:/ :1:name=systemd:/system.slice/openstack-cinder-api.service core_backtrace: :{ "signal": 11 :, "executable": "/usr/bin/python2.7" :, "stacktrace": : [ { "crash_thread": true : , "frames": : [ { "address": 140452449970144 : , "build_id": "357625781bbad706320b03674e8aef5cc461c5be" : , "build_id_offset": 3446752 : , "file_name": "/usr/lib64/python2.7/site-packages/numpy/core/multiarray.so" : } ] : } ] :} environ: :PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin :LANG=en_US.UTF-8 :HOME=/var/lib/cinder :LOGNAME=cinder :USER=cinder :SHELL=/sbin/nologin limits: :Limit Soft Limit Hard Limit Units :Max cpu time unlimited unlimited seconds :Max file size unlimited unlimited bytes :Max data size unlimited unlimited bytes :Max stack size 8388608 unlimited bytes :Max core file size 0 unlimited bytes :Max resident set unlimited unlimited bytes :Max processes 15325 15325 processes :Max open files 1024 4096 files :Max locked memory 65536 65536 bytes :Max address space unlimited unlimited bytes :Max file locks unlimited unlimited locks :Max pending signals 15325 15325 signals :Max msgqueue size 819200 819200 bytes :Max nice priority 0 0 :Max realtime priority 0 0 :Max realtime timeout unlimited unlimited us open_fds: :0:/dev/null :pos: 0 :flags: 0100000 :mnt_id: 17 :1:socket:[100424744] :pos: 0 :flags: 02 :mnt_id: 7 :2:socket:[100424744] :pos: 0 :flags: 02 :mnt_id: 7 :3:/var/log/cinder/api.log :pos: 2396879 :flags: 0102001 :mnt_id: 36 :4:pipe:[100424546] :pos: 0 :flags: 04000 :mnt_id: 8 :5:anon_inode:[eventpoll] :pos: 0 :flags: 02 :mnt_id: 9 :6:anon_inode:[eventpoll] :pos: 0 :flags: 02 :mnt_id: 9 :tfd: 4 events: 1b data: 276d10000000004 :tfd: 7 events: 1b data: 276d10000000007 :7:socket:[100425820] :pos: 0 :flags: 04002 :mnt_id: 7 :8:socket:[100532334] :pos: 0 :flags: 04002 :mnt_id: 7 :9:/usr/lib/python2.7/site-packages/taskflow/engines/action_engine/engine.py :pos: 0 :flags: 0100000 :mnt_id: 36 :10:socket:[100532371] :pos: 0 :flags: 02 :mnt_id: 7 :11:/usr/lib/python2.7/site-packages/taskflow/engines/action_engine/compiler.py :pos: 0 :flags: 0100000 :mnt_id: 36 :12:/usr/lib/python2.7/site-packages/taskflow/types/graph.py :pos: 0 :flags: 0100000 :mnt_id: 36 :13:/usr/lib/python2.7/site-packages/networkx/__init__.py :pos: 0 :flags: 0100000 :mnt_id: 36 :14:/usr/lib/python2.7/site-packages/networkx/linalg/__init__.py :pos: 0 :flags: 0100000 :mnt_id: 36 :15:/usr/lib/python2.7/site-packages/networkx/linalg/algebraicconnectivity.py :pos: 0 :flags: 0100000 :mnt_id: 36 :16:/usr/lib64/python2.7/site-packages/scipy/linalg/__init__.py :pos: 0 :flags: 0100000 :mnt_id: 36 :17:/usr/lib64/python2.7/site-packages/scipy/linalg/misc.py :pos: 0 :flags: 0100000 :mnt_id: 36 :18:/usr/lib64/python2.7/site-packages/scipy/linalg/blas.py :pos: 0 :flags: 0100000 :mnt_id: 36 :19:/usr/lib64/python2.7/site-packages/scipy/linalg/_fblas.so :pos: 0 :flags: 0100000 :mnt_id: 36 os_info: :NAME=Fedora :VERSION="20 (Heisenbug)" :ID=fedora :VERSION_ID=20 :PRETTY_NAME="Fedora 20 (Heisenbug)" :ANSI_COLOR="0;34" :CPE_NAME="cpe:/o:fedoraproject:fedora:20" :HOME_URL="https://fedoraproject.org/" :BUG_REPORT_URL="https://bugzilla.redhat.com/" :REDHAT_BUGZILLA_PRODUCT="Fedora" :REDHAT_BUGZILLA_PRODUCT_VERSION=20 :REDHAT_SUPPORT_PRODUCT="Fedora" :REDHAT_SUPPORT_PRODUCT_VERSION=20 proc_pid_status: :Name: cinder-api :State: S (sleeping) :Tgid: 22114 :Ngid: 0 :Pid: 22114 :PPid: 21732 :TracerPid: 0 :Uid: 165 165 165 165 :Gid: 165 165 165 165 :FDSize: 64 :Groups: 99 165 :VmPeak: 663440 kB :VmSize: 663440 kB :VmLck: 0 kB :VmPin: 0 kB :VmHWM: 93184 kB :VmRSS: 93184 kB :VmData: 147968 kB :VmStk: 136 kB :VmExe: 4 kB :VmLib: 84544 kB :VmPTE: 1112 kB :VmSwap: 0 kB :Threads: 1 :SigQ: 0/15325 :SigPnd: 0000000000000000 :ShdPnd: 0000000000000000 :SigBlk: 0000000000000000 :SigIgn: 0000000001001002 :SigCgt: 0000000180004001 :CapInh: 0000000000000000 :CapPrm: 0000000000000000 :CapEff: 0000000000000000 :CapBnd: 0000003fffffffff :Seccomp: 0 :Cpus_allowed: f :Cpus_allowed_list: 0-3 :Mems_allowed: 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001 :Mems_allowed_list: 0 :voluntary_ctxt_switches: 480 :nonvoluntary_ctxt_switches: 20 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlRxh+oACgkQ+HucK5lKvV8e4QCgjx98CZ4UI7tm4rtg4yHMcVJ6 qvAAnj2ESN7mV1Vh/cEsTNubaPDGaazn =gv+i -----END PGP SIGNATURE----- -- This communication is intended for the use of the recipient to whom it is addressed, and may contain confidential, personal, and or privileged information. Please contact us immediately if you are not the intended recipient of this communication, and do not copy, distribute, or take action relying on it. Any communications received in error, or subsequent reply, should be deleted or destroyed. --- From kchamart at redhat.com Sun Nov 23 12:09:28 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Sun, 23 Nov 2014 13:09:28 +0100 Subject: [Rdo-list] cinder-api[14407]: segfault at 7fc84636f7e0 ip 00007fc84636f7e0 sp 00007fff3110a468 error 15 in multiarray.so[7fc846369000+d000] In-Reply-To: <547187EA.2040001@athabascau.ca> References: <547187EA.2040001@athabascau.ca> Message-ID: <20141123120928.GA6393@tesla.home> On Sun, Nov 23, 2014 at 12:08:26AM -0700, Viorel Tabara wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > > I'm hoping that someone can point me into the right direction... > > Working with packages from: > > https://repos.fedorapeople.org/repos/openstack/openstack-juno/fedora-20/ > > the segfault happens on a fresh install, whenever I attempt to create a volume. > > Here's the abrt info: > > > Directory: /var/tmp/abrt/ccpp-2014-11-22-23:16:22-22114 > abrt_version: 2.2.2 > analyzer: CCpp > architecture: x86_64 > cmdline: /usr/bin/python2 /usr/bin/cinder-api --config-file /usr/share/cinder/cinder-dist.conf --config-file /etc/cinder/cinder.conf --logfile /var/log/cinder/api.log > component: openstack-cinder > count: 1 > executable: /usr/bin/python2.7 > hostname: stuff.can.local > kernel: 3.16.7-200.fc20.x86_64 > last_occurrence: 1416723382 > os_release: Fedora release 20 (Heisenbug) > package: openstack-cinder-2014.2-1.fc22 Seems like you're using the newest Cinder packages available on Fedora. You might want to file a bug with these details (noting exact CLI you're using might to help reproduce it, I guess you encountered it when you tried '$ cinder create --display-name testvol1 1'), so it can be triaged appropriately by Cinder folks and backport if necessary: https://bugzilla.redhat.com/enter_bug.cgi?product=RDO Component: openstack-cinder Version: Juno > pid: 22114 > pkg_arch: noarch > pkg_epoch: 0 > pkg_name: openstack-cinder > pkg_release: 1.fc22 > pkg_version: 2014.2 > pwd: / > reason: python2.7 killed by SIGSEGV > runlevel: N 5 > time: Sat 22 Nov 2014 11:16:22 PM MST > type: CCpp > uid: 165 > username: cinder > uuid: c9b2d07d3a08e30d5bb602411e7628ac38ac2755 > > coredump: Binary file, 90284032 bytes > dso_list: Text file, 16184 bytes > maps: Text file, 74532 bytes > > cgroup: > :10:hugetlb:/ > :9:perf_event:/ > :8:blkio:/ > :7:net_cls,net_prio:/ > :6:freezer:/ > :5:devices:/system.slice > :4:memory:/ > :3:cpu,cpuacct:/ > :2:cpuset:/ > :1:name=systemd:/system.slice/openstack-cinder-api.service > > core_backtrace: > :{ "signal": 11 > :, "executable": "/usr/bin/python2.7" > :, "stacktrace": > : [ { "crash_thread": true > : , "frames": > : [ { "address": 140452449970144 > : , "build_id": "357625781bbad706320b03674e8aef5cc461c5be" > : , "build_id_offset": 3446752 > : , "file_name": "/usr/lib64/python2.7/site-packages/numpy/core/multiarray.so" > : } ] > : } ] > :} [. . .] -- /kashyap From viorel at athabascau.ca Mon Nov 24 19:22:03 2014 From: viorel at athabascau.ca (Viorel Tabara) Date: Mon, 24 Nov 2014 12:22:03 -0700 Subject: [Rdo-list] cinder-api[14407]: segfault at 7fc84636f7e0 ip 00007fc84636f7e0 sp 00007fff3110a468 error 15 in multiarray.so[7fc846369000+d000] In-Reply-To: <20141123120928.GA6393@tesla.home> References: <547187EA.2040001@athabascau.ca> <20141123120928.GA6393@tesla.home> Message-ID: <5473855B.5040503@athabascau.ca> On Sun Nov 23 2014 05:09:28 GMT-0700 (MST) Kashyap Chamarthy wrote: > You might want to file a bug with these details [...] Thanks Kashyap, I've filed it. What platform have people successfully run Juno on? -- This communication is intended for the use of the recipient to whom it is addressed, and may contain confidential, personal, and or privileged information. Please contact us immediately if you are not the intended recipient of this communication, and do not copy, distribute, or take action relying on it. Any communications received in error, or subsequent reply, should be deleted or destroyed. --- From kchamart at redhat.com Mon Nov 24 20:24:38 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Mon, 24 Nov 2014 21:24:38 +0100 Subject: [Rdo-list] cinder-api[14407]: segfault at 7fc84636f7e0 ip 00007fc84636f7e0 sp 00007fff3110a468 error 15 in multiarray.so[7fc846369000+d000] In-Reply-To: <5473855B.5040503@athabascau.ca> References: <547187EA.2040001@athabascau.ca> <20141123120928.GA6393@tesla.home> <5473855B.5040503@athabascau.ca> Message-ID: <20141124202438.GC25991@tesla.redhat.com> On Mon, Nov 24, 2014 at 12:22:03PM -0700, Viorel Tabara wrote: > On Sun Nov 23 2014 05:09:28 GMT-0700 (MST) Kashyap Chamarthy > wrote: > > You might want to file a bug with these details [...] > > Thanks Kashyap, I've filed it. > > What platform have people successfully run Juno on? I don't deploy much, mostly transient test/development environments. That said, if you prefer stability, probably you're better off with CentOS. If you like latest/greatest, then I'd recommend Fedora (be prepared for debugging sessions). > -- > This communication is intended for the use of the recipient to whom it > is addressed, and may contain confidential, personal, and or privileged > information. Please contact us immediately if you are not the intended > recipient of this communication, and do not copy, distribute, or take > action relying on it. Any communications received in error, or > subsequent reply, should be deleted or destroyed. Just a gentle note -- this kind of legal disclaimers are not enforceable on public mailing lists. You might want to consider using a personal email account for public lists or elide the signature when sending to public mailing lists. -- /kashyap From rbowen at redhat.com Mon Nov 24 21:29:45 2014 From: rbowen at redhat.com (Rich Bowen) Date: Mon, 24 Nov 2014 16:29:45 -0500 Subject: [Rdo-list] Unanswered questions on ask.openstack.org Message-ID: <5473A349.5050405@redhat.com> We've fallen pretty far behind on the unanswered 'RDO' questions on ask.openstack.org over the last month, and we're up to 42, which is, I believe, our all-time high. At Perry's request, I will be getting back into the habit of triaging the unanswered questions at least once a week, and reporting back to rdo-list with the questions categorized by topic in some meaningful way. However, if you have time in the coming day or two, please take a look at the current open question list, at https://ask.openstack.org/en/questions/scope:unanswered/sort:age-asc/page:1/query:rdo/ and see if there's anything there that you can help out with. Remember that even if the OP (Original Poster) has moved on, a well-written answer may help someone asking the same question in the future. Also, if there are questions that should be closed because they are already answered, or are not a real question, or are a duplicate of one already answered, or any other legitimate reason, please let me know, so that I can close it. Thanks. -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://openstack.redhat.com/ From rdo-info at redhat.com Mon Nov 24 21:46:05 2014 From: rdo-info at redhat.com (RDO Forum) Date: Mon, 24 Nov 2014 21:46:05 +0000 Subject: [Rdo-list] [RDO] Blog roundup, weeks of November 10th and 17th Message-ID: <00000149e3c4cbcc-2994ef3d-529a-4c63-91a9-24f3b3aaa1c1-000000@email.amazonses.com> rbowen started a discussion. Blog roundup, weeks of November 10th and 17th --- Follow the link below to check it out: https://openstack.redhat.com/forum/discussion/994/blog-roundup-weeks-of-november-10th-and-17th Have a great day! From contact at progbau.de Sat Nov 29 05:53:04 2014 From: contact at progbau.de (Chris) Date: Sat, 29 Nov 2014 12:53:04 +0700 Subject: [Rdo-list] OpenStack Regions Message-ID: <002301d00b98$c879bba0$596d32e0$@progbau.de> Hello I have a question regarding regions. We have the initial "RegionOne" in our current setup and want to and a second one "RegionTwo". It seems like the shared services between different regions are Keystone and Horizon. The separate services for each region includes Nova (+ database), Neutron etc. Please correct me here if I'm wrong. Should we use the same tenants/users for the second region or create new ones? Second additional question, is the separation in the different regions just for the endpoints or does the "noca.conf" and other configuration files need to be changed as well? Unfortunately I couldn't find any manual how to proper configure a second region, just a bug report, reporting the lack of documentation :) https://bugs.launchpad.net/openstack-manuals/+bug/1340509 Cheers Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: