From rbowen at redhat.com Fri Jan 3 15:01:33 2014 From: rbowen at redhat.com (Rich Bowen) Date: Fri, 03 Jan 2014 10:01:33 -0500 Subject: [Rdo-list] Reminder: Test day next week Message-ID: <52C6D0CD.70405@redhat.com> Next week (January 7/8) we'll be doing our first Icehouse test day, and we'd appreciate it if you could help us out with an hour or two of your time. Details on the test day can be found at http://openstack.redhat.com/RDO_test_day_January_2014 and a matrix of what we'd like to test is at http://openstack.redhat.com/TestedSetups_2014_01 For the live backchannel, please join the #rdo channel on the Freenode IRC network, where many of us will be all day to answer questions, help work through problems, and for just general chat. Thanks for any time you can contribute to this testing effort, to help make RDO as solid as possible. -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://openstack.redhat.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdo-info at redhat.com Fri Jan 3 15:09:26 2014 From: rdo-info at redhat.com (RDO Forum) Date: Fri, 3 Jan 2014 15:09:26 +0000 Subject: [Rdo-list] [RDO] Reminder - RDO test day next week Message-ID: <0000014358a6db4b-b6b9f3e2-b236-4010-b6fa-4a0c090a295c-000000@email.amazonses.com> rbowen started a discussion. Reminder - RDO test day next week --- Follow the link below to check it out: http://openstack.redhat.com/forum/discussion/962/reminder-rdo-test-day-next-week Have a great day! From pmyers at redhat.com Fri Jan 3 16:16:26 2014 From: pmyers at redhat.com (Perry Myers) Date: Fri, 03 Jan 2014 11:16:26 -0500 Subject: [Rdo-list] http://openstack.redhat.com/DeveloperTips Message-ID: <52C6E25A.2030703@redhat.com> Was talking to kashyap and he gave me some handy pointers that I thought were very useful and I thought that it would make sense to start a page where we could collect snippets of usefulness like this. So I created: http://openstack.redhat.com/DeveloperTips Thanks to kashyap for the tips, and please feel free to add add'l info and tips to this page. For reference, the page is indexed under: http://openstack.redhat.com/Docs/Misc Cheers, Perry From gfidente at redhat.com Fri Jan 3 17:04:01 2014 From: gfidente at redhat.com (Giulio Fidente) Date: Fri, 03 Jan 2014 18:04:01 +0100 Subject: [Rdo-list] test day storage testables Message-ID: <52C6ED81.3000806@redhat.com> hi, in preparation for the RDO test day we've added a few storage related scenarios to the TestedSetups_2014_01 page. More specifically, there is now here: http://openstack.redhat.com/TestedSetups_2014_01 a Packstack based section to test the following: - AIO with Cinder/GlusterFS - AIO with Cinder/ThinLVM - AIO with Glance/Swift - Semi distributed (one is remote) - Fully distributed (all are remote) We've also created (and linked) a few wiki pages with the instructions to configure RDO for those scenarios: http://openstack.redhat.com/Docs/Storage Feedback is more than welcomed about both the scenarios and the instructions! :) -- Giulio Fidente GPG KEY: 08D733BA | IRC: giulivo From dron at redhat.com Fri Jan 3 18:14:19 2014 From: dron at redhat.com (Dafna Ron) Date: Fri, 03 Jan 2014 18:14:19 +0000 Subject: [Rdo-list] test day storage testables In-Reply-To: <52C6ED81.3000806@redhat.com> References: <52C6ED81.3000806@redhat.com> Message-ID: <52C6FDFB.5040009@redhat.com> Please note: the table is temporary and may change before test day. thanks, Dafna On 01/03/2014 05:04 PM, Giulio Fidente wrote: > hi, > > in preparation for the RDO test day we've added a few storage related > scenarios to the TestedSetups_2014_01 page. > > More specifically, there is now here: > > http://openstack.redhat.com/TestedSetups_2014_01 > > a Packstack based section to test the following: > > - AIO with Cinder/GlusterFS > - AIO with Cinder/ThinLVM > - AIO with Glance/Swift > - Semi distributed (one is remote) > - Fully distributed (all are remote) > > We've also created (and linked) a few wiki pages with the instructions > to configure RDO for those scenarios: > > http://openstack.redhat.com/Docs/Storage > > Feedback is more than welcomed about both the scenarios and the > instructions! :) -- Dafna Ron From kaushalshriyan at gmail.com Fri Jan 3 18:50:12 2014 From: kaushalshriyan at gmail.com (Kaushal Shriyan) Date: Fri, 3 Jan 2014 11:50:12 -0700 Subject: [Rdo-list] RDO Full form Message-ID: Hi What is the full form of RDO in http://openstack.redhat.com/Main_Page Regards, Kaushal -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmyers at redhat.com Fri Jan 3 19:09:56 2014 From: pmyers at redhat.com (Perry Myers) Date: Fri, 03 Jan 2014 14:09:56 -0500 Subject: [Rdo-list] RDO Full form In-Reply-To: References: Message-ID: <52C70B04.3030403@redhat.com> On 01/03/2014 01:50 PM, Kaushal Shriyan wrote: > Hi > > What is the full form of RDO in http://openstack.redhat.com/Main_Page I'm not sure what you mean by 'full form'. Can you ask the question in a different way? From kaushalshriyan at gmail.com Fri Jan 3 19:15:10 2014 From: kaushalshriyan at gmail.com (Kaushal Shriyan) Date: Fri, 3 Jan 2014 12:15:10 -0700 Subject: [Rdo-list] RDO Full form In-Reply-To: <52C70B04.3030403@redhat.com> References: <52C70B04.3030403@redhat.com> Message-ID: On Fri, Jan 3, 2014 at 12:09 PM, Perry Myers wrote: > On 01/03/2014 01:50 PM, Kaushal Shriyan wrote: > > Hi > > > > What is the full form of RDO in http://openstack.redhat.com/Main_Page > > I'm not sure what you mean by 'full form'. Can you ask the question in > a different way? > I mean is RDO an acronym or any abbreviation? Regards, Kaushal -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmyers at redhat.com Fri Jan 3 19:19:08 2014 From: pmyers at redhat.com (Perry Myers) Date: Fri, 03 Jan 2014 14:19:08 -0500 Subject: [Rdo-list] RDO Full form In-Reply-To: References: <52C70B04.3030403@redhat.com> Message-ID: <52C70D2C.1010307@redhat.com> On 01/03/2014 02:15 PM, Kaushal Shriyan wrote: > On Fri, Jan 3, 2014 at 12:09 PM, Perry Myers > wrote: > > On 01/03/2014 01:50 PM, Kaushal Shriyan wrote: > > Hi > > > > What is the full form of RDO in http://openstack.redhat.com/Main_Page > > I'm not sure what you mean by 'full form'. Can you ask the question in > a different way? > > > I mean is RDO an acronym or any abbreviation? Ah, ok. RDO has no expansion or longer name, officially. It is not an acronym or abbreviation for anything. However, RDO does focus on building a distribution of OpenStack specific to Red Hat operating systems (and clones of Red Hat operating systems). So, in some sense you can think of RDO as being a project started by Red Hat to build a distribution of OpenStack. The 3 letter meaningless acronym sort of comes from that line of thinking. From rbowen at redhat.com Fri Jan 3 19:23:52 2014 From: rbowen at redhat.com (Rich Bowen) Date: Fri, 03 Jan 2014 14:23:52 -0500 Subject: [Rdo-list] test day storage testables In-Reply-To: <52C6ED81.3000806@redhat.com> References: <52C6ED81.3000806@redhat.com> Message-ID: <52C70E48.2060102@redhat.com> Thank you very much! --Rich On 01/03/2014 12:04 PM, Giulio Fidente wrote: > hi, > > in preparation for the RDO test day we've added a few storage related > scenarios to the TestedSetups_2014_01 page. > > More specifically, there is now here: > > http://openstack.redhat.com/TestedSetups_2014_01 > > a Packstack based section to test the following: > > - AIO with Cinder/GlusterFS > - AIO with Cinder/ThinLVM > - AIO with Glance/Swift > - Semi distributed (one is remote) > - Fully distributed (all are remote) > > We've also created (and linked) a few wiki pages with the instructions > to configure RDO for those scenarios: > > http://openstack.redhat.com/Docs/Storage > > Feedback is more than welcomed about both the scenarios and the > instructions! :) -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://openstack.redhat.com/ From bderzhavets at hotmail.com Sat Jan 4 14:23:42 2014 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Sat, 4 Jan 2014 09:23:42 -0500 Subject: [Rdo-list] Does cinder (havana 2013.2.1-1) work with native qemu-libgfapi driver on CentOS 6.5 ? Message-ID: I am not quite sure that this bugs are related with Grizzly :- https://bugzilla.redhat.com/show_bug.cgi?id=1045047 https://bugzilla.redhat.com/show_bug.cgi?id=1020979 . I can create cinder volume (on glusterfs) via glance image on Havana 2013.2.1 & CentOS 6.5 (like on F19). I can load cloud instance F20, Ubuntu 13.10, Win2012 Server via cinder volume (on glusterfs) prepared on Havana 2013.2.1 & CentOS 6.5 (like on F19) with Grizzly on F19 it was not possible. Boris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bderzhavets at hotmail.com Sat Jan 4 18:04:38 2014 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Sat, 4 Jan 2014 13:04:38 -0500 Subject: [Rdo-list] Does cinder (havana 2013.2.1-1) work with native qemu-libgfapi driver on CentOS 6.5 ? In-Reply-To: References: Message-ID: On the other hand per https://bugzilla.redhat.com/show_bug.cgi?id=956919 it seems to be done. From: bderzhavets at hotmail.com To: rdo-list at redhat.com Date: Sat, 4 Jan 2014 09:23:42 -0500 Subject: [Rdo-list] Does cinder (havana 2013.2.1-1) work with native qemu-libgfapi driver on CentOS 6.5 ? I am not quite sure that this bugs are related with Grizzly :- https://bugzilla.redhat.com/show_bug.cgi?id=1045047 https://bugzilla.redhat.com/show_bug.cgi?id=1020979 . I can create cinder volume (on glusterfs) via glance image on Havana 2013.2.1 & CentOS 6.5 (like on F19). I can load cloud instance F20, Ubuntu 13.10, Win2012 Server via cinder volume (on glusterfs) prepared on Havana 2013.2.1 & CentOS 6.5 (like on F19) with Grizzly on F19 it was not possible. Boris. _______________________________________________ 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 dneary at redhat.com Sun Jan 5 16:01:23 2014 From: dneary at redhat.com (Dave Neary) Date: Sun, 05 Jan 2014 17:01:23 +0100 Subject: [Rdo-list] RDO Full form In-Reply-To: <52C70D2C.1010307@redhat.com> References: <52C70B04.3030403@redhat.com> <52C70D2C.1010307@redhat.com> Message-ID: <52C981D3.6060106@redhat.com> Hi, On 01/03/2014 08:19 PM, Perry Myers wrote: > On 01/03/2014 02:15 PM, Kaushal Shriyan wrote: >> I mean is RDO an acronym or any abbreviation? > > RDO has no expansion or longer name, officially. It is not an acronym > or abbreviation for anything. > > However, RDO does focus on building a distribution of OpenStack specific > to Red Hat operating systems (and clones of Red Hat operating systems). > So, in some sense you can think of RDO as being a project started by > Red Hat to build a distribution of OpenStack. > > The 3 letter meaningless acronym sort of comes from that line of thinking. By way of explanation, we do not use "Red Hat" in the name of community supported projects for trademark reasons. Cheers, Dave. -- Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13 From kchamart at redhat.com Mon Jan 6 14:56:58 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Mon, 06 Jan 2014 15:56:58 +0100 Subject: [Rdo-list] http://openstack.redhat.com/DeveloperTips In-Reply-To: <52C6E25A.2030703@redhat.com> References: <52C6E25A.2030703@redhat.com> Message-ID: <52CAC43A.1060307@redhat.com> On 01/03/2014 05:16 PM, Perry Myers wrote: > Was talking to kashyap and he gave me some handy pointers that I thought > were very useful and I thought that it would make sense to start a page > where we could collect snippets of usefulness like this. > > So I created: > http://openstack.redhat.com/DeveloperTips Thanks. > > Thanks to kashyap for the tips, and please feel free to add add'l info > and tips to this page. Added a couple more things re: tags, sub-packages.g > > For reference, the page is indexed under: > http://openstack.redhat.com/Docs/Misc > -- /kashyap From rbowen at redhat.com Mon Jan 6 20:19:06 2014 From: rbowen at redhat.com (Rich Bowen) Date: Mon, 06 Jan 2014 15:19:06 -0500 Subject: [Rdo-list] Reminder: RDO Icehouse test days TOMORROW Message-ID: <52CB0FBA.9050005@redhat.com> A reminder that we'll be doing the Icehouse Milestone 1 RDO test days starting tomorrow, January 7th and 8th. We'd really appreciate it if you could give us an hour or two of your time, to try to ferret out any problems with the RDO packages. The Icehouse Milestone 1 package set is available for Fedora 20, and RHEL 6, and derivatives. To prepare for testing, have a look at http://openstack.redhat.com/RDO_test_day_January_2014 and add your name to the list if you're going to be able to participate. The tests that we'd like to do are listed at http://openstack.redhat.com/TestedSetups_2014_01 so if you're unable to participate during the designated time, but are able to do some testing at another time, please go ahead and put your results and notes there. Join us on #rdo, on the Freenode IRC network, for questions and conversation during the event. See you there! --Rich -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://openstack.redhat.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sthaha at redhat.com Tue Jan 7 02:12:03 2014 From: sthaha at redhat.com (Sunil Thaha) Date: Mon, 6 Jan 2014 21:12:03 -0500 (EST) Subject: [Rdo-list] Removed F19 from the Tested-Setups page In-Reply-To: <1649675781.11697395.1389060300113.JavaMail.root@redhat.com> Message-ID: <408328308.11698033.1389060723067.JavaMail.root@redhat.com> Hi, I have removed the Fedora 19 entries from the TestedSetup page[1] since I didn't find rpms generated for f19 here[2]. Please feel free to revert back the change should you feel that Fedora-20 rpms may be used on F19. The 'Prerequisite for Test Day' section of the test-day page[3] will also need to be updated to reflect F19 as suitable platform. Thanks, Sunil [1] http://openstack.redhat.com/TestedSetups_2014_01 [2] http://repos.fedorapeople.org/repos/openstack/openstack-icehouse/ [3] http://openstack.redhat.com/RDO_test_day_January_2014 From whayutin at redhat.com Tue Jan 7 03:14:05 2014 From: whayutin at redhat.com (whayutin) Date: Mon, 06 Jan 2014 22:14:05 -0500 Subject: [Rdo-list] Reminder: RDO Icehouse test days TOMORROW In-Reply-To: <52CB0FBA.9050005@redhat.com> References: <52CB0FBA.9050005@redhat.com> Message-ID: <1389064445.2970.9.camel@localhost.localdomain> On Mon, 2014-01-06 at 15:19 -0500, Rich Bowen wrote: > A reminder that we'll be doing the Icehouse Milestone 1 RDO test days > starting tomorrow, January 7th and 8th. We'd really appreciate it if > you could give us an hour or two of your time, to try to ferret out > any problems with the RDO packages. > > The Icehouse Milestone 1 package set is available for Fedora 20, and > RHEL 6, and derivatives. > > To prepare for testing, have a look at > http://openstack.redhat.com/RDO_test_day_January_2014 and add your > name to the list if you're going to be able to participate. > > The tests that we'd like to do are listed at > http://openstack.redhat.com/TestedSetups_2014_01 so if you're unable > to participate during the designated time, but are able to do some > testing at another time, please go ahead and put your results and > notes there. FYI.. The rdo-ci team has a few of the most basic icehouse installs setup in our CI system, it may help to see the install console output and logs from those runs. The results are public and available here [1]. To view the console output of a job, click on the name -> build number -> Console Output. You can also download the log files and view the tempest test results for each job. Scenarios: RHEL, CentOS, and Fedora AIO configuration RHEL, Fedora OVS Multinode configuration [1] https://prod-rdojenkins.rhcloud.com/ Thanks > > Join us on #rdo, on the Freenode IRC network, for questions and > conversation during the event. See you there! > > --Rich > > -- > Rich Bowen - rbowen at redhat.com > OpenStack Community Liaison > http://openstack.redhat.com/ > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list From kchamart at redhat.com Tue Jan 7 07:54:52 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Tue, 07 Jan 2014 08:54:52 +0100 Subject: [Rdo-list] Heads up: openstack-neutron-agent fails to start w/o python-psutil Message-ID: <52CBB2CC.4030002@redhat.com> Heya, I just upgraded my Fedora 20 Havana setup to IceHouse, and, restarting openstack-neutron-agent fails with the below: ================================= $ systemctl start neutron-openvswitch-agent $ systemctl status neutron-openvswitch-agent [. . .] Jan 07 02:45:15 node2-compute neutron-openvswitch-agent[3471]: from neutron.agent.linux import polling Jan 07 02:45:15 node2-compute neutron-openvswitch-agent[3471]: File "/usr/lib/python2.7/site-packages/neutron/agent/linux/polling.py", line 2...odule> Jan 07 02:45:15 node2-compute neutron-openvswitch-agent[3471]: from neutron.agent.linux import ovsdb_monitor Jan 07 02:45:15 node2-compute neutron-openvswitch-agent[3471]: File "/usr/lib/python2.7/site-packages/neutron/agent/linux/ovsdb_monitor.py", ...odule> Jan 07 02:45:15 node2-compute neutron-openvswitch-agent[3471]: from neutron.agent.linux import async_process Jan 07 02:45:15 node2-compute neutron-openvswitch-agent[3471]: File "/usr/lib/python2.7/site-packages/neutron/agent/linux/async_process.py", ...odule> Jan 07 02:45:15 node2-compute neutron-openvswitch-agent[3471]: import psutil Jan 07 02:45:15 node2-compute neutron-openvswitch-agent[3471]: ImportError: No module named psutil Jan 07 02:45:15 node2-compute systemd[1]: neutron-openvswitch-agent.service: main process exited, code=exited, status=1/FAILURE Jan 07 02:45:15 node2-compute systemd[1]: Unit neutron-openvswitch-agent.service entered failed state. Hint: Some lines were ellipsized, use -l to show in full. [root at node2-compute ~]# systemctl status neutron-openvswitch-agent -l neutron-openvswitch-agent.service - OpenStack Quantum Open vSwitch Agent Loaded: loaded (/usr/lib/systemd/system/neutron-openvswitch-agent.service; enabled) Active: failed (Result: exit-code) since Mon 2012-12-10 02:45:15 EST; 20s ago Process: 3471 ExecStart=/usr/bin/neutron-openvswitch-agent --config-file /usr/share/neutron/neutron-dist.conf --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini --log-file /var/log/neutron/openvswitch-agent.log (code=exited, status=1/FAILURE) Main PID: 3471 (code=exited, status=1/FAILURE) ================================= Workaround for now - explicitly install python-psutil: $ yum install python-psutil.x86_64 $ systemctl start neutron-openvswitch-agent $ systemctl status neutron-openvswitch-agent -l neutron-openvswitch-agent.service - OpenStack Quantum Open vSwitch Agent Loaded: loaded (/usr/lib/systemd/system/neutron-openvswitch-agent.service; enabled) Active: active (running) since Mon 2012-12-10 18:23:13 EST; 1 years 0 months ago Main PID: 3515 (neutron-openvsw) CGroup: /system.slice/neutron-openvswitch-agent.service ??3515 /usr/bin/python /usr/bin/neutron-openvswitch-agent --config-file /usr/share/neutron/neutron-dist.conf --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini --log-file /var/log/neutron/openvswitch-agent.log [. . .] Not sure if others are encountering this too? -- /kashyap From kchamart at redhat.com Tue Jan 7 10:52:20 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Tue, 07 Jan 2014 11:52:20 +0100 Subject: [Rdo-list] Heads up: openstack-neutron-agent fails to start w/o python-psutil In-Reply-To: <52CBB2CC.4030002@redhat.com> References: <52CBB2CC.4030002@redhat.com> Message-ID: <52CBDC64.9020101@redhat.com> Filed this, so we can track - https://bugzilla.redhat.com/show_bug.cgi?id=1049235 If it turns out NOTABUG, it can be closed w/ a rationale. -- /kashyap From rdo-info at redhat.com Tue Jan 7 14:39:43 2014 From: rdo-info at redhat.com (RDO Forum) Date: Tue, 7 Jan 2014 14:39:43 +0000 Subject: [Rdo-list] [RDO] RDO test day today Message-ID: <000001436d2514c0-b613ea97-2898-46d5-8d3a-019545621a91-000000@email.amazonses.com> rbowen started a discussion. RDO test day today --- Follow the link below to check it out: http://openstack.redhat.com/forum/discussion/963/rdo-test-day-today Have a great day! From whayutin at redhat.com Tue Jan 7 15:30:02 2014 From: whayutin at redhat.com (whayutin) Date: Tue, 07 Jan 2014 10:30:02 -0500 Subject: [Rdo-list] [RDO] RDO test day today In-Reply-To: <000001436d2514c0-b613ea97-2898-46d5-8d3a-019545621a91-000000@email.amazonses.com> References: <000001436d2514c0-b613ea97-2898-46d5-8d3a-019545621a91-000000@email.amazonses.com> Message-ID: <1389108602.2876.0.camel@localhost.localdomain> On Tue, 2014-01-07 at 14:39 +0000, RDO Forum wrote: > rbowen started a discussion. > > RDO test day today > > --- > Follow the link below to check it out: > http://openstack.redhat.com/forum/discussion/963/rdo-test-day-today > > Have a great day! > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list FYI.. The rdo-ci team has created a doc on how to test rdo w/ tempest http://openstack.redhat.com/Testing_IceHouse_using_Tempest Thanks! From kchamart at redhat.com Tue Jan 7 17:34:04 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Tue, 07 Jan 2014 18:34:04 +0100 Subject: [Rdo-list] Quick tip: while logging/investigating SELinux issues Message-ID: <52CC3A8C.4020104@redhat.com> I usually try these when I hit SELinux issues, thought I'd quickly share here. # Enable SELinux $ setenforce 1 # Clear the audit log (so only relevant messages can be analysed later) $ > /var/log/audit/audit.log [Perform your offending test] # Show a reference policy $ cat /var/log/audit/audit.log | audit2allow -R And, if you're feeling more adventurous, you can even generate an SELinux reference policy and re-test it: e.g. If you see Neutron issues from the previous command, you can try # Generate an SELinux loadable module package $ audit2allow -a -M neutron # Install the Policy Package $ semodule -i neutron.pp # Restart neutron-dhcp-agent again $ systemctl restart neutron-dhcp-agent See if it alleviates your problem. Ref: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Fixing_Problems-Allowing_Access_audit2allow.html -- /kashyap From bderzhavets at hotmail.com Tue Jan 7 21:37:09 2014 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Tue, 7 Jan 2014 16:37:09 -0500 Subject: [Rdo-list] Attempt to enable LBaaS on two node Havana 2 Cluster (Controller+Compute) CentOS 6.5 In-Reply-To: <52B477E2.5070309@redhat.com> References: <5D7F9996EA547448BC6C54C8C5AAF4E5D98BF093@CERNXCHG02.cern.ch>, <52B440FA.9030404@redhat.com> <52B4451E.307@redhat.com>,<52B477E2.5070309@redhat.com> Message-ID: Follow http://openstack.redhat.com/forum/discussion/comment/2178 and http://openstack.redhat.com/Load_Balance_OpenStack_API#HAProxy Edit /etc/neutron/neutron.conf and add the following in the default section: [DEFAULT] service_plugins = neutron.services.loadbalancer.plugin.LoadBalancerPlugin Already there Then edit the /etc/openstack-dashboard/local_settings file and search for enable_lb and set it to true: OPENSTACK_NEUTRON_NETWORK = { 'enable_lb': True } Done # yum install haproxy - already installed # vi /etc/neutron/lbaas_agent.ini - already done no changes device_driver=neutron.services.loadbalancer.drivers.haproxy.namespace_driver.HaproxyNSDriver interface_driver=neutron.agent.linux.interface.OVSInterfaceDriver user_group=haproxy Comment out the line in the service_providers section: service_provider=LOADBALANCER:Haproxy:neutron.services.loadbalancer.drivers.haproxy.plugin_driver.HaproxyOnHostPluginDriver:default Nothing to remove service neutron-lbaas-agent start - already running , restarted chkconfig neutron-lbaas-agent on - skipped service neutron-server restart - done service httpd restart - done HA enabled via keepalived , Virtual IP 192.168.1.132. Follow http://openstack.redhat.com/Load_Balance_OpenStack_API#HAProxy and http://openstack.redhat.com/forum/discussion/798/enabling-lbaas-in-havana-and-why-is-it-not-on-by-default#Item_4 replacing "quantum" by "neutron" and using virirtual IP for one server creating /etc/haproxy/haproxy.cfg. Haproxy fails to start reporting: Starting haproxy: [ALERT] 006/135903 (12988) : Starting frontend keystone-admin-vip: cannot bind socket [ALERT] 006/135903 (12988) : Starting frontend keystone-public-vip: cannot bind socket . . . . . . . Really , for any port mentioned in haproxy.cfg :- # netstat -lnp | grep 35357 tcp 0 0 0.0.0.0:35357 0.0.0.0:* LISTEN 4189/python # netstat -lnp | grep 5000 tcp 0 0 0.0.0.0:5000 0.0.0.0:* LISTEN 4189/python . . . . . . Haproxy may be started ahead of openstack services, but in this case openstack services fail to start. I am missing something here -------------- next part -------------- An HTML attachment was scrubbed... URL: From rohara at redhat.com Wed Jan 8 10:42:04 2014 From: rohara at redhat.com (Ryan O'Hara) Date: Wed, 8 Jan 2014 04:42:04 -0600 Subject: [Rdo-list] Attempt to enable LBaaS on two node Havana 2 Cluster (Controller+Compute) CentOS 6.5 In-Reply-To: References: <5D7F9996EA547448BC6C54C8C5AAF4E5D98BF093@CERNXCHG02.cern.ch> <52B440FA.9030404@redhat.com> <52B4451E.307@redhat.com> <52B477E2.5070309@redhat.com> Message-ID: <20140108104204.GA10746@redhat.com> On Tue, Jan 07, 2014 at 04:37:09PM -0500, Boris Derzhavets wrote: > > > Follow http://openstack.redhat.com/forum/discussion/comment/2178 > and http://openstack.redhat.com/Load_Balance_OpenStack_API#HAProxy The first link is a discussion about LBaaS and the second is a write-up about how to setup HAProxy to load balancer OpenStack API services. These are two entirely different things. > Edit /etc/neutron/neutron.conf and add the following in the default section: > > [DEFAULT] > service_plugins = neutron.services.loadbalancer.plugin.LoadBalancerPlugin > > Already there > > Then edit the /etc/openstack-dashboard/local_settings file and search for enable_lb and set it to true: > > OPENSTACK_NEUTRON_NETWORK = { > 'enable_lb': True > } > > Done > > # yum install haproxy - already installed > # vi /etc/neutron/lbaas_agent.ini - already done no changes > > device_driver=neutron.services.loadbalancer.drivers.haproxy.namespace_driver.HaproxyNSDriver > interface_driver=neutron.agent.linux.interface.OVSInterfaceDriver > user_group=haproxy > > Comment out the line in the service_providers section: > > service_provider=LOADBALANCER:Haproxy:neutron.services.loadbalancer.drivers.haproxy.plugin_driver.HaproxyOnHostPluginDriver:default > > Nothing to remove > > service neutron-lbaas-agent start - already running , restarted > chkconfig neutron-lbaas-agent on - skipped > service neutron-server restart - done > service httpd restart - done So far you've setup LBaaS and everything looks fine. > HA enabled via keepalived , Virtual IP 192.168.1.132. Keepalived has nothing to do with LBaaS, so we've diverged a bit here. > Follow http://openstack.redhat.com/Load_Balance_OpenStack_API#HAProxy > and http://openstack.redhat.com/forum/discussion/798/enabling-lbaas-in-havana-and-why-is-it-not-on-by-default#Item_4 replacing "quantum" by "neutron" and using virirtual IP for one server creating /etc/haproxy/haproxy.cfg. Haproxy fails to start reporting: > > > Starting haproxy: > > [ALERT] 006/135903 (12988) : Starting frontend keystone-admin-vip: cannot bind socket > > [ALERT] 006/135903 (12988) : Starting frontend keystone-public-vip: cannot bind socket > Where are you starting haproxy? I am guessing that you're starting this on the controller, which will be a problem since the OpenStack services themselves are setup to listen on 0.0.0.0: which means haproxy cannot also listen on that port on the same node. > > Really , for any port mentioned in haproxy.cfg :- > > # netstat -lnp | grep 35357 tcp 0 0 0.0.0.0:35357 0.0.0.0:* LISTEN 4189/python > # netstat -lnp | grep 5000 tcp 0 0 0.0.0.0:5000 0.0.0.0:* LISTEN 4189/python > . . . . . . > > Haproxy may be started ahead of openstack services, but in this case > openstack services fail to start. I am missing something here First, what is it you want to do? If you want to setup LBaaS, you were on the right track. Once LBaaS is configured and the agent is running, use the Neutron API to create a load-balancer. This will load-balancer traffic to your virtual machines. The write-up you referenced on the RDO page describes how to use haproxy and keepalived to achieve a highly-available load-balancer for your OpenStack services. For example, you might have many controllers, each running neutron, keystone, nova API services, etc. and you can put a load-balancer in front of these services for scalability and availability. Let me know if you have questions. Ryan From bderzhavets at hotmail.com Wed Jan 8 11:43:28 2014 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Wed, 8 Jan 2014 06:43:28 -0500 Subject: [Rdo-list] Attempt to enable LBaaS on two node Havana 2 Cluster (Controller+Compute) CentOS 6.5 In-Reply-To: <20140108104204.GA10746@redhat.com> References: <5D7F9996EA547448BC6C54C8C5AAF4E5D98BF093@CERNXCHG02.cern.ch>, <52B440FA.9030404@redhat.com>, <52B4451E.307@redhat.com>, <52B477E2.5070309@redhat.com>, , <20140108104204.GA10746@redhat.com> Message-ID: Thank you very much. I got it. > Date: Wed, 8 Jan 2014 04:42:04 -0600 > From: rohara at redhat.com > To: bderzhavets at hotmail.com > CC: pbrady at redhat.com; rdo-list at redhat.com > Subject: Re: [Rdo-list] Attempt to enable LBaaS on two node Havana 2 Cluster (Controller+Compute) CentOS 6.5 > > On Tue, Jan 07, 2014 at 04:37:09PM -0500, Boris Derzhavets wrote: > > > > > > Follow http://openstack.redhat.com/forum/discussion/comment/2178 > > and http://openstack.redhat.com/Load_Balance_OpenStack_API#HAProxy > > The first link is a discussion about LBaaS and the second is a > write-up about how to setup HAProxy to load balancer OpenStack API > services. These are two entirely different things. > > > Edit /etc/neutron/neutron.conf and add the following in the default section: > > > > [DEFAULT] > > service_plugins = neutron.services.loadbalancer.plugin.LoadBalancerPlugin > > > > Already there > > > > Then edit the /etc/openstack-dashboard/local_settings file and search for enable_lb and set it to true: > > > > OPENSTACK_NEUTRON_NETWORK = { > > 'enable_lb': True > > } > > > > Done > > > > # yum install haproxy - already installed > > # vi /etc/neutron/lbaas_agent.ini - already done no changes > > > > device_driver=neutron.services.loadbalancer.drivers.haproxy.namespace_driver.HaproxyNSDriver > > interface_driver=neutron.agent.linux.interface.OVSInterfaceDriver > > user_group=haproxy > > > > Comment out the line in the service_providers section: > > > > service_provider=LOADBALANCER:Haproxy:neutron.services.loadbalancer.drivers.haproxy.plugin_driver.HaproxyOnHostPluginDriver:default > > > > Nothing to remove > > > > service neutron-lbaas-agent start - already running , restarted > > chkconfig neutron-lbaas-agent on - skipped > > service neutron-server restart - done > > service httpd restart - done > > So far you've setup LBaaS and everything looks fine. > > > HA enabled via keepalived , Virtual IP 192.168.1.132. > > Keepalived has nothing to do with LBaaS, so we've diverged a bit here. > > > Follow http://openstack.redhat.com/Load_Balance_OpenStack_API#HAProxy > > and http://openstack.redhat.com/forum/discussion/798/enabling-lbaas-in-havana-and-why-is-it-not-on-by-default#Item_4 replacing "quantum" by "neutron" and using virirtual IP for one server creating /etc/haproxy/haproxy.cfg. Haproxy fails to start reporting: > > > > > > Starting haproxy: > > > > [ALERT] 006/135903 (12988) : Starting frontend keystone-admin-vip: cannot bind socket > > > > [ALERT] 006/135903 (12988) : Starting frontend keystone-public-vip: cannot bind socket > > > > Where are you starting haproxy? I am guessing that you're starting > this on the controller, which will be a problem since the OpenStack > services themselves are setup to listen on 0.0.0.0: which means > haproxy cannot also listen on that port on the same node. > > > > > Really , for any port mentioned in haproxy.cfg :- > > > > # netstat -lnp | grep 35357 tcp 0 0 0.0.0.0:35357 0.0.0.0:* LISTEN 4189/python > > # netstat -lnp | grep 5000 tcp 0 0 0.0.0.0:5000 0.0.0.0:* LISTEN 4189/python > > . . . . . . > > > > Haproxy may be started ahead of openstack services, but in this case > > openstack services fail to start. I am missing something here > > First, what is it you want to do? If you want to setup LBaaS, you were > on the right track. Once LBaaS is configured and the agent is running, > use the Neutron API to create a load-balancer. This will load-balancer > traffic to your virtual machines. > > The write-up you referenced on the RDO page describes how to use > haproxy and keepalived to achieve a highly-available load-balancer for > your OpenStack services. For example, you might have many controllers, > each running neutron, keystone, nova API services, etc. and you can > put a load-balancer in front of these services for scalability and > availability. > > Let me know if you have questions. > > Ryan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kchamart at redhat.com Wed Jan 8 14:37:48 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Wed, 08 Jan 2014 15:37:48 +0100 Subject: [Rdo-list] [Quick update] SELinux package w/ Neutron fixes for Fedora 20 Message-ID: <52CD62BC.2060505@redhat.com> If you're are testing Icehouse on Fedora 20 and facing a SELinux issues like below: https://bugzilla.redhat.com/show_bug.cgi?id=1024330 https://bugzilla.redhat.com/show_bug.cgi?id=1049817 Please update to build selinux-policy-3.13.1-11.fc21 It's here: http://koji.fedoraproject.org/koji/buildinfo?buildID=488941 Or you can fetch it from CLI (for x86_64 arch) $ yum install koji -y $ koji download-build --arch=noarch selinux-policy-3.12.1-113.fc20 Thanks to Miroslav Grepl for the quick response & making the build. -- /kashyap From kchamart at redhat.com Wed Jan 8 15:58:09 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Wed, 08 Jan 2014 16:58:09 +0100 Subject: [Rdo-list] [Quick update] SELinux package w/ Neutron fixes for Fedora 20 In-Reply-To: <52CD62BC.2060505@redhat.com> References: <52CD62BC.2060505@redhat.com> Message-ID: <52CD7591.9070706@redhat.com> On 01/08/2014 03:37 PM, Kashyap Chamarthy wrote: > If you're are testing Icehouse on Fedora 20 and facing a SELinux issues > like below: > > https://bugzilla.redhat.com/show_bug.cgi?id=1024330 > https://bugzilla.redhat.com/show_bug.cgi?id=1049817 > > > Please update to build selinux-policy-3.13.1-11.fc21 Typo (thanks P?draig!), that was meant to be: selinux-policy-3.12.1-113.fc20 which is in the build system. So, if you're testing with this version, and find more SELinux issues, please post them here. The above build is not yet in Fedora updates testing; hence the below instruction to fetch it directly from the Koji > > It's here: http://koji.fedoraproject.org/koji/buildinfo?buildID=488941 > > Or you can fetch it from CLI (for x86_64 arch) > > $ yum install koji -y > $ koji download-build --arch=noarch selinux-policy-3.12.1-113.fc20 > > > Thanks to Miroslav Grepl for the quick response & making the build. > > -- /kashyap From lars at redhat.com Wed Jan 8 18:53:13 2014 From: lars at redhat.com (Lars Kellogg-Stedman) Date: Wed, 8 Jan 2014 13:53:13 -0500 Subject: [Rdo-list] [Quick update] SELinux package w/ Neutron fixes for Fedora 20 In-Reply-To: <52CD7591.9070706@redhat.com> References: <52CD62BC.2060505@redhat.com> <52CD7591.9070706@redhat.com> Message-ID: <20140108185313.GL26471@redhat.com> On Wed, Jan 08, 2014 at 04:58:09PM +0100, Kashyap Chamarthy wrote: > which is in the build system. So, if you're testing with this version, > and find more SELinux issues, please post them here. For a "packstack --allinone" install I'm still getting a bunch of errors; I've updated the bz with details: https://bugzilla.redhat.com/show_bug.cgi?id=1049817 -- Lars Kellogg-Stedman | larsks @ irc Cloud Engineering / OpenStack | " " @ twitter -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From kchamart at redhat.com Wed Jan 8 19:12:19 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Wed, 08 Jan 2014 20:12:19 +0100 Subject: [Rdo-list] [Quick update] SELinux package w/ Neutron fixes for Fedora 20 In-Reply-To: <20140108185313.GL26471@redhat.com> References: <52CD62BC.2060505@redhat.com> <52CD7591.9070706@redhat.com> <20140108185313.GL26471@redhat.com> Message-ID: <52CDA313.4000401@redhat.com> On 01/08/2014 07:53 PM, Lars Kellogg-Stedman wrote: > On Wed, Jan 08, 2014 at 04:58:09PM +0100, Kashyap Chamarthy wrote: >> which is in the build system. So, if you're testing with this version, >> and find more SELinux issues, please post them here. > > For a "packstack --allinone" install I'm still getting a bunch of > errors; I've updated the bz with details: > > https://bugzilla.redhat.com/show_bug.cgi?id=1049817 Thanks for this, Lars. Just to note, the above bug is for selinux-policy component which /blocks/ (and is a clone of) the bug with 'openstack-neutron' component: https://bugzilla.redhat.com/show_bug.cgi?id=1049807#c3 I also see some more of them & posted them to the 'openstack-neutron' above bug. [CCing Miroslav Grepl, one of the Fedora SELinux maintainers) -- /kashyap From rdo-info at redhat.com Wed Jan 8 21:59:34 2014 From: rdo-info at redhat.com (RDO Forum) Date: Wed, 8 Jan 2014 21:59:34 +0000 Subject: [Rdo-list] [RDO] Congratulations to the CentOS project, from RDO Message-ID: <0000014373de2471-a4a91502-aaab-4d17-b400-4c5d04a16855-000000@email.amazonses.com> rbowen started a discussion. Congratulations to the CentOS project, from RDO --- Follow the link below to check it out: http://openstack.redhat.com/forum/discussion/964/congratulations-to-the-centos-project-from-rdo Have a great day! From kchamart at redhat.com Wed Jan 8 22:31:07 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Wed, 08 Jan 2014 23:31:07 +0100 Subject: [Rdo-list] RDO bug triage recurring IRC meeting on #rdo Message-ID: <52CDD1AB.1090706@redhat.com> Heya, I'm writing this to see if we can have a rough consensus on a recurring day/timing (of course we may not satisfy everyone) for a recurring RDO bug triage on #rdo channel on Freenode. We can make initial agenda, etc on a wiki page. Convenience info ---------------- Bugs ~~~~ - List of un-triaged bugs (NEW state) -- http://goo.gl/NqW2LN - List of all ASSIGNED bugs (with and without Keyword 'Triaged') -- http://goo.gl/oFY9vX - List of all ON_QA bugs -- http://goo.gl/CZX92r We may have to write a few more queries (e.g. upstream launchpad) The above info is also here -- http://openstack.redhat.com/RDO-BugTriage Meetbot ~~~~~~~ Useful commands while running an IRC meeting: http://fedoraproject.org/wiki/Zodbot#Meeting_Functions Other info ~~~~~~~~~~ - Upstream OpenStack bug triage procedure https://wiki.openstack.org/wiki/BugTriage - Some existing community projects which use Red Hat bugzilla, and its work-flows for bug triage: http://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow http://fedoraproject.org/wiki/BugZappers/StockBugzillaResponses https://fedoraproject.org/wiki/BugZappers/How_to_Triage - Time-zones info -- https://fedoraproject.org/wiki/Infrastructure/UTCHowto Comments/thoughts? And, when can we have the first 'official' (so to speak) IRC bug triage day? PS: /me's availability will be bleak next week due to some personal commitments. (And, also won't be available on 20/21 JAN). So, please co-ordinate here/IRC & proceed w/ triaging if things work out for rest of the folks. -- /kashyap From kchamart at redhat.com Thu Jan 9 07:41:26 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Thu, 09 Jan 2014 08:41:26 +0100 Subject: [Rdo-list] RDO test day (7,8-JAN-2014) -- IRC meeting minutes log Message-ID: <52CE52A6.8000302@redhat.com> ================================ #rdo: RDO test day; 7,8-JAN-2014 ================================ Thanks everyone for participating in the test day, here's the summary (& URL to full logs) of MeetBot-generated IRC meeting minutes over the last 2 days. The full logs are available at: http://meetbot.fedoraproject.org/rdo/2014-01-07/rdo-test-day-jan2014.2014-01-07-11.24.log.html . (We're currently using Fedora infrastructure's meetbot; hence the name the URL.) Meeting summary --------------- * LINK: http://www.fpaste.org/66374/90963731/ (afazekas, 12:06:21) * LINK: http://pastebin.com/qQXgL7hF (ohochman, 12:15:38) * LINK: http://www.fpaste.org/66388/90983821/ (afazekas, 12:39:55) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1020954 (rlandy, 13:19:44) * LINK: http://openstack.redhat.com/Workarounds#Could_not_enable_mysqld (flaper87, 13:49:08) * LINK: http://openstack.redhat.com/Workarounds_2014_01 (giulivo, 14:06:07) * LINK: http://openstack.redhat.com/Testing_IceHouse_using_Tempest#configure_and_run_nosetest_.28_RHEL.2FCentOS_.29 (weshay, 14:34:06) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1049235 (majopela, 15:02:17) * LINK: http://www.redhat.com/archives/libvir-list/2013-November/msg00967.html , https://bugzilla.redhat.com/show_bug.cgi?id=1033039 (afazekas, 15:35:42) * LINK: http://www.fpaste.org/66440/13891090/ n-net f20 (afazekas, 15:38:01) * LINK: http://fpaste.org/66476/13891181/ (shardy, 18:13:54) * LINK: http://www.fpaste.org/66498/91217481/ do I need to enable something to get the dhcp agent bindings ? (afazekas, 19:12:40) * LINK: http://www.fpaste.org/66503/12312313/ (afazekas, 19:32:28) * LINK: https://github.com/openstack/cinder/commit/bb06ebd0f6a75a6ba55a7c022de96a91e3750d20 (abaron, 06:53:11) * LINK: http://openstack.redhat.com/Adding_a_compute_node (kashyap, 08:56:44) * LINK: http://repos.fedorapeople.org/repos/openstack/openstack-icehouse/epel-7/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found (afazekas, 11:28:51) * ACTION: Kashyap/larsks to bring up the issue of modularized SELinux policies for OpenStack on the list (kashyap, 14:21:37) Meeting ended at 07:22:49 UTC. Action Items ------------ * Kashyap/larsks to bring up the issue of modularized SELinux policies for OpenStack on the list Action Items, by person ----------------------- * larsks * Kashyap/larsks to bring up the issue of modularized SELinux policies for OpenStack on the list * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * ndipanov (227) * kashyap (199) * ohochman (150) * Dafna (114) * giulivo (95) * larsks (91) * pixelb (77) * majopela (63) * afazekas (55) * morazi (35) * jbernard (34) * ayoung (32) * mbourvin (29) * shardy (25) * paul__ (24) * yfried (24) * abaron (23) * Dominic (21) * rlandy (19) * yrabl (18) * DrBacchus (13) * zaitcev (13) * flaper87 (12) * weshay (12) * nmagnezi (11) * pradeep (11) * mrunge (11) * eglynn (11) * vladan (10) * tshefi_ (10) * jistr (10) * Egyptian[Laptop] (6) * jruzicka (6) * mpavlase (6) * dneary (5) * japerry (4) * kwhitney (4) * oblaut (3) * zodbot (3) * anand_ (3) * bcrochet (3) * panda (2) * mbourvin1 (2) * tshefi (2) * nlevinki (2) * psedlak (1) * jpich (1) * TVR_ (1) * mmagr (1) * misterr (1) * ukalifon (1) -- /kashyap From kchamart at redhat.com Thu Jan 9 10:56:40 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Thu, 09 Jan 2014 11:56:40 +0100 Subject: [Rdo-list] List of RDO bugs found during test days Message-ID: <52CE8068.1050308@redhat.com> Heya, Here are the bugs (48) posted during the test days (Jan 7, 8) -- http://goo.gl/1RuoWS (Thanks to Yaniv Eylon for the bugzilla query.) Posted them here in plain text if you don't want to click on URLs: ========================================================================= 1049235 openstack-neutron https://bugzilla.redhat.com/show_bug.cgi?id=1049235 neutron-openvswitch-agent service restart fails; reason: fails to pull dependency - python-psutil 1049246 openstack-nova https://bugzilla.redhat.com/show_bug.cgi?id=1049246 RDO: instance hangs in "scheduling" forever - topic: "conductor", RPC method: "object_class_action" info: "" 1049319 python-django-horizon https://bugzilla.redhat.com/show_bug.cgi?id=1049319 Sometimes it takes a lot of time to open the window for "Launch Instance" 1049362 openstack-packstack https://bugzilla.redhat.com/show_bug.cgi?id=1049362 the glusterFS's default share file is created with writing permissions for root only 1049369 openstack-packstack https://bugzilla.redhat.com/show_bug.cgi?id=1049362 new ceilometer-agent-notification service needs to be started alongside the other ceilometer services 1049380 openstack-cinder https://bugzilla.redhat.com/show_bug.cgi?id=1049380 openstack-cinder: cinder fails to copy an image a volume with GlusterFS backend 1049382 openstack-cinder https://bugzilla.redhat.com/show_bug.cgi?id=1049382 EMC: fails to create volume from Glance image 1049388 openstack-glance https://bugzilla.redhat.com/show_bug.cgi?id=1049388 Creating an image caused disk trashing and non-responsive browser. 1049391 openstack-nova https://bugzilla.redhat.com/show_bug.cgi?id=1049391 openstack-nova-compute service fails with - libvirtError: internal error: CPU feature `avx' specified more than once 1049394 openstack-glance https://bugzilla.redhat.com/show_bug.cgi?id=1049394 Creating an image from CLI without --container format queued the image and fails with 400. 1049457 openstack-cinder https://bugzilla.redhat.com/show_bug.cgi?id=1049457 A qcow2 image is converted to raw when a volume is created from. 1049480 openstack-neutron https://bugzilla.redhat.com/show_bug.cgi?id=1049480 Neutron installed via packstack breaks NetworkManager 1049484 python-django-horizon https://bugzilla.redhat.com/show_bug.cgi?id=1049484 horizon: when checking the "Name" check box in the instance view none of the instances are selected 1049488 distribution https://bugzilla.redhat.com/show_bug.cgi?id=1049488 Services can't connect to qpid after reboot 1049493 openstack-ceilometer https://bugzilla.redhat.com/show_bug.cgi?id=1049493 ceilometer-agent-notification service name inconsistant with other ceilometer service names 1049503 openstack-selinux https://bugzilla.redhat.com/show_bug.cgi?id=1049503 Fedora 20 rdo-icehouse selinux issues with rootwrap 1049511 openstack-cinder https://bugzilla.redhat.com/show_bug.cgi?id=1049511 EMC: fails to boot instances from volumes with "TypeError: Unsupported parameter type" 1049519 openstack-neutron https://bugzilla.redhat.com/show_bug.cgi?id=1049519 Nova 500 error: Connection to neutron failed: Maximum attempts reached 1049535 openstack-cinder https://bugzilla.redhat.com/show_bug.cgi?id=1049535 cinder: cannot create a volume when root squash is set to on for gluster storage 1049537 openstack-packstack https://bugzilla.redhat.com/show_bug.cgi?id=1049537 Horizon help url in RDO points to the RHOS documentation 1049597 openstack-packstack https://bugzilla.redhat.com/show_bug.cgi?id=1049597 packstack disable EPEL upon CONFIG_USE_EPEL=n 1049775 openstack-cinder https://bugzilla.redhat.com/show_bug.cgi?id=1049775 Volume (Thin LVM) creation from image (qcow2) never ends 1049785 openstack-cinder https://bugzilla.redhat.com/show_bug.cgi?id=1049785 A redundant image copy is created when creating a volume from a glance image. (All-in-One) 1049786 openstack-cinder https://bugzilla.redhat.com/show_bug.cgi?id=1049786 openstack-cinder: failed to delete the volume in glusterFS 1049861 openstack-cinder https://bugzilla.redhat.com/show_bug.cgi?id=1049861 openstack-cinder: fail to delete snapshot on an "in-use" volume using --force true 1049864 openstack-cinder https://bugzilla.redhat.com/show_bug.cgi?id=1049864 Creating a 99G volume on 100G cinder-volume succeeded, but deleting it failed (no space left) 1049872 openstack-packstack https://bugzilla.redhat.com/show_bug.cgi?id=1049872 RFE]: set backup_swift_url in cinder.conf is swift is installed 1049877 openstack-cinder https://bugzilla.redhat.com/show_bug.cgi?id=1049877 cinder: data is not saved on a volume created from an image after instance termination 1049895 openstack-selinux https://bugzilla.redhat.com/show_bug.cgi?id=1049895 [RDO][OpenStack-SELinux): AVCs left in messages after deployment of neutron-controller / neutron-compute using foreman. 1049915 python-django-horizon https://bugzilla.redhat.com/show_bug.cgi?id=1049915 Horizon no longer displays Security Groups related quotas. 1049944 openstack-cinder https://bugzilla.redhat.com/show_bug.cgi?id=1049944 ThinLVM: volumes and snaps created outside the thin pool 1049947 openstack-cinder https://bugzilla.redhat.com/show_bug.cgi?id=1049947 ThinLVM: creation of volumes from volumes (cloning) fails 1049982 python-novaclient https://bugzilla.redhat.com/show_bug.cgi?id=1049982 The output of security group rules does not include egress rules. 1049983 python-django-horizon https://bugzilla.redhat.com/show_bug.cgi?id=1049983 No option in Horizon to create a volume from an existing volume (like: cinder create --source-volid) 1049985 openstack-nova https://bugzilla.redhat.com/show_bug.cgi?id=1049985 RDO: Instance hangs in 'Deleting' state ... multi node (using GRE tenant networks) 1049995 openstack-cinder https://bugzilla.redhat.com/show_bug.cgi?id=1049995 cinder: two volumes are created instead of one when we try to boot an instance with create new volume option 1050025 python-django-horizon https://bugzilla.redhat.com/show_bug.cgi?id=1050025 NeutronError API internals are shown in Horizon UI on error 1050029 python-django-horizon https://bugzilla.redhat.com/show_bug.cgi?id=1050029 horizon: flood of error messages when failing to launch an instance with create new volume option 1050052 openstack-utils https://bugzilla.redhat.com/show_bug.cgi?id=1050052 openstack-status should show the status of the openstack-cinder-backup' service 1050140 openstack-packstack https://bugzilla.redhat.com/show_bug.cgi?id=1050140 SequenceError: execute() got an unexpected keyword argument 'maskList' 1050158 openstack-cinder https://bugzilla.redhat.com/show_bug.cgi?id=1050158 cinder: volume is not deleted on instance destroy when we we fail to boot an instance using a create volume + delete on terminate 1050202 python-django-horizon https://bugzilla.redhat.com/show_bug.cgi?id=1050202 Hours of disks 1050205 openstack-packstack https://bugzilla.redhat.com/show_bug.cgi?id=1050205 Dashboard port firewall rule is not permanent 1050842 openstack-neutron https://bugzilla.redhat.com/show_bug.cgi?id=1050842 neutron authentication issues ========================================================================= -- /kashyap From kchamart at redhat.com Thu Jan 9 11:48:21 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Thu, 09 Jan 2014 12:48:21 +0100 Subject: [Rdo-list] Time-based mass bug update w/ stock responses for RDO bugs? (like Fedora) Message-ID: <52CE8C85.3060107@redhat.com> We're (pbrady, mrunge, me) having this discussion on IRC, just wanted to post it to wider audience who're asleep/just waking up. I was thinking (in future) if it makes sense to mass update RDO bugs with stock responses (like please try w/ blah version, etc) when we move from one version to another (e.g. how Fedora does) to humanly keep up2date with stale bugs, unresponsive reporters, etc. Points of view (slightly edited for readability) -------------- - mrunge: "I like the idea on auto-updating or closing bugs. It's not ideal, but helps to reduce the number of bugs, which were forgotten for whatever reason." - pbrady: "kashyap, I think your suggestion of more involved RDO/Fedora bug triage would obviate the need for that. We kinda got that (auto-updating) automatically when the bugs were in Fedora bugzilla, and since openstack release cadence matched Fedora's. But with the move to separate RDO product (in bugzilla, i.e.) and with the diverging OpenStack and Fedora release cadence, a similar separate mechanism would be useful Re: non openstack project bugs, I suppose fortnightly we could do half the "packaging" call on #rdo to triage distro bugs" Any other constructive opinions? mrunge, pbrady: Don't hesitate to yell if I misrepresented your comments. -- /kashyap From lars at redhat.com Thu Jan 9 14:05:35 2014 From: lars at redhat.com (Lars Kellogg-Stedman) Date: Thu, 9 Jan 2014 09:05:35 -0500 Subject: [Rdo-list] RDO bug triage recurring IRC meeting on #rdo In-Reply-To: <52CDD1AB.1090706@redhat.com> References: <52CDD1AB.1090706@redhat.com> Message-ID: <20140109140535.GE15539@redhat.com> On Wed, Jan 08, 2014 at 11:31:07PM +0100, Kashyap Chamarthy wrote: > I'm writing this to see if we can have a rough consensus on a recurring > day/timing (of course we may not satisfy everyone) for a recurring RDO > bug triage on #rdo channel on Freenode. Do you have any thoughts as to frequency? I don't have a sense right now of how frequently new bugs are coming in. I'm tempted to say something like "the third Wednesday of every month". > Comments/thoughts? And, when can we have the first 'official' (so to > speak) IRC bug triage day? Well, next Wednesday (1/22) would be the third Wednesday of this month, if that works for anybody but me :). > PS: /me's availability will be bleak next week due to some personal > commitments. (And, also won't be available on 20/21 JAN). So, please > co-ordinate here/IRC & proceed w/ triaging if things work out for rest > of the folks. It would be nice if you were around for the first one just to start things rolling. -- Lars Kellogg-Stedman | larsks @ irc Cloud Engineering / OpenStack | " " @ twitter -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From kchamart at redhat.com Thu Jan 9 15:02:43 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Thu, 09 Jan 2014 16:02:43 +0100 Subject: [Rdo-list] RDO bug triage recurring IRC meeting on #rdo In-Reply-To: <20140109140535.GE15539@redhat.com> References: <52CDD1AB.1090706@redhat.com> <20140109140535.GE15539@redhat.com> Message-ID: <52CEBA13.4020901@redhat.com> On 01/09/2014 03:05 PM, Lars Kellogg-Stedman wrote: > On Wed, Jan 08, 2014 at 11:31:07PM +0100, Kashyap Chamarthy wrote: >> I'm writing this to see if we can have a rough consensus on a recurring >> day/timing (of course we may not satisfy everyone) for a recurring RDO >> bug triage on #rdo channel on Freenode. > > Do you have any thoughts as to frequency? Given the amount of churn, maybe twice/thrice a month would be fine? (of-course, we're flexible). And, there's per-component bug triage going on every week anyway too. > I don't have a sense right > now of how frequently new bugs are coming in. I don't have full statistics at hand. A guesstimate: 708 / week (sometimes more - like test days, last 2 days, we had like 48 bugs) > I'm tempted to say > something like "the third Wednesday of every month". Works for me. Re: timing, currently can I propose UTC 14:00? That translates to: EST: $ date -d '2014-01-22 14:00 UTC' Wed Jan 22 09:00:00 EST 2014 CET: $ date -d '2014-01-22 14:00 UTC' Wed Jan 22 15:00:00 CET 2014 IST: (/me will be here soon for sometime) $ date -d '2014-01-22 14:00 UTC' Wed Jan 22 19:30:00 IST 2014 Does that work for most folks? >> Comments/thoughts? And, when can we have the first 'official' (so to >> speak) IRC bug triage day? > > Well, next Wednesday (1/22) would be the third Wednesday of this > month, if that works for anybody but me :). Works for me :-) > >> PS: /me's availability will be bleak next week due to some personal >> commitments. (And, also won't be available on 20/21 JAN). So, please >> co-ordinate here/IRC & proceed w/ triaging if things work out for rest >> of the folks. > > It would be nice if you were around for the first one just to start > things rolling. Sure, will try to be around, if it's 22JAN. And, there are many experienced folks on this list (including yourself :-) ) And, I know folks would anyway be doing impromptu triaging in the meantime. Thanks. -- /kashyap From rbowen at redhat.com Thu Jan 9 15:07:43 2014 From: rbowen at redhat.com (Rich Bowen) Date: Thu, 09 Jan 2014 10:07:43 -0500 Subject: [Rdo-list] Bitergia RDO stats Message-ID: <52CEBB3F.3050902@redhat.com> A few months ago we talked with Bitergia about providing some statistics around RDO. I expect that most of you are familiar with Bitergia. For those of you who aren't, they're the people who do the stats for Stackalytics - http://www.stackalytics.com/ The RDO stats are now available at *http://openstack.redhat.com/stats/* and are updated every morning. Bitergia has asked that we run this by you, the RDO community, and get any comments you may have. They asked me to particularly ask: * Check your company affiliation, if you have commits or ticket activity, to ensure that we are attributing correctly. (This can be hard depending on what email address you use in your various interactions.) * Check that the stats seem to make sense, and correspond with what you think they *should* look like. * Tell us whether the information is presented clearly, or if there's something that can be done better/differently to communicate what things mean. Thanks! -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://openstack.redhat.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbowen at redhat.com Thu Jan 9 15:19:47 2014 From: rbowen at redhat.com (Rich Bowen) Date: Thu, 09 Jan 2014 10:19:47 -0500 Subject: [Rdo-list] Time-based mass bug update w/ stock responses for RDO bugs? (like Fedora) In-Reply-To: <52CE8C85.3060107@redhat.com> References: <52CE8C85.3060107@redhat.com> Message-ID: <52CEBE13.4050903@redhat.com> I definitely like the idea of auto-updating tickets in this way. I'm not keen on auto-closing tickets, but if we bump a ticket (like, with a "please try the new release" message) and there's no response in N weeks, then it may make sense to do this. We have a lot of cases of people posting to ask.openstack and simultaneously opening a ticket, and it's not clear, from following both, which one they're actually tracking. --Rich On 01/09/2014 06:48 AM, Kashyap Chamarthy wrote: > We're (pbrady, mrunge, me) having this discussion on IRC, just wanted to > post it to wider audience who're asleep/just waking up. > > I was thinking (in future) if it makes sense to mass update RDO bugs > with stock responses (like please try w/ blah version, etc) when we move > from one version to another (e.g. how Fedora does) to humanly keep > up2date with stale bugs, unresponsive reporters, etc. > > > Points of view (slightly edited for readability) > -------------- > > - mrunge: "I like the idea on auto-updating or closing bugs. It's not > ideal, but helps to reduce the number of bugs, which were forgotten > for whatever reason." > > - pbrady: "kashyap, I think your suggestion of more > involved RDO/Fedora bug triage would obviate the need for that. > > We kinda got that (auto-updating) automatically when the bugs were > in Fedora bugzilla, and since openstack release cadence matched > Fedora's. But with the move to separate RDO product > (in bugzilla, i.e.) and with the diverging OpenStack > and Fedora release cadence, a similar separate mechanism > would be useful > > Re: non openstack project bugs, I suppose fortnightly we could do > half the "packaging" call on #rdo to triage distro bugs" > > > Any other constructive opinions? > > mrunge, pbrady: Don't hesitate to yell if I misrepresented your comments. > > -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://openstack.redhat.com/ From rbowen at redhat.com Thu Jan 9 15:56:57 2014 From: rbowen at redhat.com (Rich Bowen) Date: Thu, 09 Jan 2014 10:56:57 -0500 Subject: [Rdo-list] HostingCon RFP closes tomorrow Message-ID: <52CEC6C9.40700@redhat.com> For the conference speakers among you, I wanted to remind you that the RFP for HostinCon closes *TOMORROW*: HostingCon, event date June 16-18 in Miami Beach, FL. Please submit talks at http://www.hostingcon.com/speakers/speaking-proposal-guidelines/, by January 10. The HostingCon audience tends to be very interested in OpenStack content,and the conference speaker list tends to include speakers from across the OpenStack ecosystem. It's a great place to get the message out about RDO, or to learn what is going on with OpenStack in the hosting space. --Rich -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://openstack.redhat.com/ From rbowen at redhat.com Thu Jan 9 16:04:25 2014 From: rbowen at redhat.com (Rich Bowen) Date: Thu, 09 Jan 2014 11:04:25 -0500 Subject: [Rdo-list] RDO test day: Thanks! Message-ID: <52CEC889.3040405@redhat.com> Thanks so much to all of you who found time to help us test RDO. You can see some of what was accomplished at http://openstack.redhat.com/TestedSetups_2014_01 and you've already seen Kashyap's list of the 48 (!!) tickets that were opened over the last two days. Once again, thanks for your help with this. And a reminder that test day isn't the only time you're allowed to test, it's just the time when there's the most people doing it. If you missed the test day, or if you just want to spend some additional time testing, please continue to use the above TestedSetups page as a reference, and let's see if we can get through everything. Meanwhile, we're already looking towards the next test day, and hope to have dates and information for you in the coming weeks. -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://openstack.redhat.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From morazi at redhat.com Thu Jan 9 17:14:47 2014 From: morazi at redhat.com (Mike Orazi) Date: Thu, 09 Jan 2014 12:14:47 -0500 Subject: [Rdo-list] RDO bug triage recurring IRC meeting on #rdo In-Reply-To: <52CEBA13.4020901@redhat.com> References: <52CDD1AB.1090706@redhat.com> <20140109140535.GE15539@redhat.com> <52CEBA13.4020901@redhat.com> Message-ID: <52CED907.705@redhat.com> On 01/09/2014 10:02 AM, Kashyap Chamarthy wrote: > On 01/09/2014 03:05 PM, Lars Kellogg-Stedman wrote: >> On Wed, Jan 08, 2014 at 11:31:07PM +0100, Kashyap Chamarthy wrote: >>> I'm writing this to see if we can have a rough consensus on a recurring >>> day/timing (of course we may not satisfy everyone) for a recurring RDO >>> bug triage on #rdo channel on Freenode. >> >> Do you have any thoughts as to frequency? > > Given the amount of churn, maybe twice/thrice a month would be fine? > (of-course, we're flexible). And, there's per-component bug triage going > on every week anyway too. > >> I don't have a sense right >> now of how frequently new bugs are coming in. > > I don't have full statistics at hand. A guesstimate: 708 / week > (sometimes more - like test days, last 2 days, we had like 48 bugs) > >> I'm tempted to say >> something like "the third Wednesday of every month". > > Works for me. > > Re: timing, currently can I propose UTC 14:00? > > That translates to: > > EST: > > $ date -d '2014-01-22 14:00 UTC' > Wed Jan 22 09:00:00 EST 2014 > > CET: > > $ date -d '2014-01-22 14:00 UTC' > Wed Jan 22 15:00:00 CET 2014 > > IST: (/me will be here soon for sometime) > > $ date -d '2014-01-22 14:00 UTC' > Wed Jan 22 19:30:00 IST 2014 > > > Does that work for most folks? > This overlaps with another standing call I'm on, but I can likely keep an eye on irc during the call. If I'm one of the few that is unavailable, I'd say go for it and push it forward. I'd rather get things on the book in a time that a majority of people can work with. Thanks, Mike > >>> Comments/thoughts? And, when can we have the first 'official' (so to >>> speak) IRC bug triage day? >> >> Well, next Wednesday (1/22) would be the third Wednesday of this >> month, if that works for anybody but me :). > > Works for me :-) > >> >>> PS: /me's availability will be bleak next week due to some personal >>> commitments. (And, also won't be available on 20/21 JAN). So, please >>> co-ordinate here/IRC & proceed w/ triaging if things work out for rest >>> of the folks. >> >> It would be nice if you were around for the first one just to start >> things rolling. > > Sure, will try to be around, if it's 22JAN. And, there are many > experienced folks on this list (including yourself :-) ) > > And, I know folks would anyway be doing impromptu triaging in the meantime. > > Thanks. > From kchamart at redhat.com Thu Jan 9 17:21:51 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Thu, 09 Jan 2014 18:21:51 +0100 Subject: [Rdo-list] RDO bug triage recurring IRC meeting on #rdo In-Reply-To: <52CEBA13.4020901@redhat.com> References: <52CDD1AB.1090706@redhat.com> <20140109140535.GE15539@redhat.com> <52CEBA13.4020901@redhat.com> Message-ID: <52CEDAAF.6070708@redhat.com> [. . .] >> Do you have any thoughts as to frequency? > > Given the amount of churn, maybe twice/thrice a month would be fine? > (of-course, we're flexible). And, there's per-component bug triage going > on every week anyway too. > >> I don't have a sense right >> now of how frequently new bugs are coming in. > > I don't have full statistics at hand. A guesstimate: 708 / week Gah, glaring typo, that was meant to be: 7 or 8 > (sometimes more - like test days, last 2 days, we had like 48 bugs) > -- /kashyap From mburns at redhat.com Thu Jan 9 17:47:47 2014 From: mburns at redhat.com (Mike Burns) Date: Thu, 09 Jan 2014 12:47:47 -0500 Subject: [Rdo-list] RDO bug triage recurring IRC meeting on #rdo In-Reply-To: <52CEBA13.4020901@redhat.com> References: <52CDD1AB.1090706@redhat.com> <20140109140535.GE15539@redhat.com> <52CEBA13.4020901@redhat.com> Message-ID: <52CEE0C3.1000906@redhat.com> On 01/09/2014 10:02 AM, Kashyap Chamarthy wrote: > On 01/09/2014 03:05 PM, Lars Kellogg-Stedman wrote: >> On Wed, Jan 08, 2014 at 11:31:07PM +0100, Kashyap Chamarthy wrote: >>> I'm writing this to see if we can have a rough consensus on a recurring >>> day/timing (of course we may not satisfy everyone) for a recurring RDO >>> bug triage on #rdo channel on Freenode. >> >> Do you have any thoughts as to frequency? > > Given the amount of churn, maybe twice/thrice a month would be fine? > (of-course, we're flexible). And, there's per-component bug triage going > on every week anyway too. > >> I don't have a sense right >> now of how frequently new bugs are coming in. > > I don't have full statistics at hand. A guesstimate: 708 / week > (sometimes more - like test days, last 2 days, we had like 48 bugs) > >> I'm tempted to say >> something like "the third Wednesday of every month". > > Works for me. > > Re: timing, currently can I propose UTC 14:00? > > That translates to: > > EST: > > $ date -d '2014-01-22 14:00 UTC' > Wed Jan 22 09:00:00 EST 2014 > > CET: > > $ date -d '2014-01-22 14:00 UTC' > Wed Jan 22 15:00:00 CET 2014 > > IST: (/me will be here soon for sometime) > > $ date -d '2014-01-22 14:00 UTC' > Wed Jan 22 19:30:00 IST 2014 > > > Does that work for most folks? > > >>> Comments/thoughts? And, when can we have the first 'official' (so to >>> speak) IRC bug triage day? >> >> Well, next Wednesday (1/22) would be the third Wednesday of this >> month, if that works for anybody but me :). > > Works for me :-) Time works for me. > >> >>> PS: /me's availability will be bleak next week due to some personal >>> commitments. (And, also won't be available on 20/21 JAN). So, please >>> co-ordinate here/IRC & proceed w/ triaging if things work out for rest >>> of the folks. >> >> It would be nice if you were around for the first one just to start >> things rolling. > > Sure, will try to be around, if it's 22JAN. And, there are many > experienced folks on this list (including yourself :-) ) > > And, I know folks would anyway be doing impromptu triaging in the meantime. > > Thanks. I think we should have it next week. Let's plan on 3rd Wednesday in general and see how things go to determine whether we need to meet more often. Mike > From rbowen at redhat.com Thu Jan 9 18:30:37 2014 From: rbowen at redhat.com (Rich Bowen) Date: Thu, 09 Jan 2014 13:30:37 -0500 Subject: [Rdo-list] RDO bug triage recurring IRC meeting on #rdo In-Reply-To: <20140109140535.GE15539@redhat.com> References: <52CDD1AB.1090706@redhat.com> <20140109140535.GE15539@redhat.com> Message-ID: <52CEEACD.7030204@redhat.com> On 01/09/2014 09:05 AM, Lars Kellogg-Stedman wrote: > On Wed, Jan 08, 2014 at 11:31:07PM +0100, Kashyap Chamarthy wrote: >> I'm writing this to see if we can have a rough consensus on a recurring >> day/timing (of course we may not satisfy everyone) for a recurring RDO >> bug triage on #rdo channel on Freenode. > Do you have any thoughts as to frequency? I don't have a sense right > now of how frequently new bugs are coming in. I'm tempted to say > something like "the third Wednesday of every month". Twice a month sounds like a good cadence. Perhaps doing something like "third wednesday and first tuesday" or something like that would give more people the opportunity to attend once a month if the other time is a conflict. In general, I love the idea of doing more of these meetings in public view rather than on the phone other less public venues. -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://openstack.redhat.com/ From mburns at redhat.com Thu Jan 9 19:32:58 2014 From: mburns at redhat.com (Mike Burns) Date: Thu, 09 Jan 2014 14:32:58 -0500 Subject: [Rdo-list] RDO Live Image available for testing Message-ID: <52CEF96A.8090701@redhat.com> A new RDO LiveCD image is now available for testing[1]. This image is essentially CentOS 6.5 + RDO Havana using a standard AllInOne installation. A README file has been posted alongside the ISO image[2] which details issues that I'm aware of right now. Let me know if you have any issues Mike [1] http://repos.fedorapeople.org/repos/openstack/openstack-havana/Live/RDO-CentOS-Live-20140109.0.iso [2] http://repos.fedorapeople.org/repos/openstack/openstack-havana/Live/README From rbowen at redhat.com Thu Jan 9 21:00:41 2014 From: rbowen at redhat.com (Rich Bowen) Date: Thu, 09 Jan 2014 16:00:41 -0500 Subject: [Rdo-list] FOSDEM and Infrastructure.next Message-ID: <52CF0DF9.2090902@redhat.com> I'll be at FOSDEM ( https://fosdem.org/2014/) in a few weeks, and wondered if any of you folks will be there. It would be cool to meet some of you and maybe grab a few of the famed Belgian beers with you. Also, in the days right after FOSDEM, there's going to be an event in Ghent - a short train ride away - called Infrastructure.Next From the blog post ( http://community.redhat.com/blog/2013/12/announcing-infrastructure-next/): Infrastructure.Next is the event for people interested in the evolving tools and projects for managing large-scale IT infrastructure. From storage to configuration management to virtualization infrastructure, all the way to Infrastructure-as-a-Service (IaaS). So if you're interested in the "Virtualization and Iaas" track at FOSDEM, you may also be interested in sticking around for a few more days for Infrastructure.Next. And, just as importantly, if you want to speak at Infrastructure.next, please get in touch either with me, or with jzb at redhat.com -- Rich Bowen -rbowen at redhat.com OpenStack Community Liaison http://openstack.redhat.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From morazi at redhat.com Fri Jan 10 00:47:07 2014 From: morazi at redhat.com (Mike Orazi) Date: Thu, 09 Jan 2014 19:47:07 -0500 Subject: [Rdo-list] RDO Live Image available for testing In-Reply-To: <52CEF96A.8090701@redhat.com> References: <52CEF96A.8090701@redhat.com> Message-ID: <52CF430B.10702@redhat.com> On 01/09/2014 02:32 PM, Mike Burns wrote: > A new RDO LiveCD image is now available for testing[1]. This image is > essentially CentOS 6.5 + RDO Havana using a standard AllInOne installation. > > A README file has been posted alongside the ISO image[2] which details > issues that I'm aware of right now. > > Let me know if you have any issues > > Mike > > [1] > http://repos.fedorapeople.org/repos/openstack/openstack-havana/Live/RDO-CentOS-Live-20140109.0.iso > > [2] > http://repos.fedorapeople.org/repos/openstack/openstack-havana/Live/README > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list I'm looking forward to digging into this and trying it out. Thanks for putting this together! - Mike From kchamart at redhat.com Fri Jan 10 12:14:15 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Fri, 10 Jan 2014 13:14:15 +0100 Subject: [Rdo-list] RDO bug triage recurring IRC meeting on #rdo In-Reply-To: <52CEE0C3.1000906@redhat.com> References: <52CDD1AB.1090706@redhat.com> <20140109140535.GE15539@redhat.com> <52CEBA13.4020901@redhat.com> <52CEE0C3.1000906@redhat.com> Message-ID: <52CFE417.5080200@redhat.com> [. . .] >> Does that work for most folks? >> >> >>>> Comments/thoughts? And, when can we have the first 'official' (so to >>>> speak) IRC bug triage day? >>> >>> Well, next Wednesday (1/22) would be the third Wednesday of this >>> month, if that works for anybody but me :). >> >> Works for me :-) > > Time works for me. >> >>> >>>> PS: /me's availability will be bleak next week due to some personal >>>> commitments. (And, also won't be available on 20/21 JAN). So, please >>>> co-ordinate here/IRC & proceed w/ triaging if things work out for rest >>>> of the folks. >>> >>> It would be nice if you were around for the first one just to start >>> things rolling. >> >> Sure, will try to be around, if it's 22JAN. And, there are many >> experienced folks on this list (including yourself :-) ) >> >> And, I know folks would anyway be doing impromptu triaging in the >> meantime. >> >> Thanks. > > I think we should have it next week. Sure (if UTC 14:00 is works for most folks here). Just to be clear - I'm not holding up anyone. I'll try my best to be around, but cannot promise as I already mentioned in my previous email. > Let's plan on 3rd Wednesday in > general and see how things go to determine whether we need to meet more > often. -- /kashyap From whayutin at redhat.com Fri Jan 10 13:41:25 2014 From: whayutin at redhat.com (whayutin) Date: Fri, 10 Jan 2014 08:41:25 -0500 Subject: [Rdo-list] RDO bug triage recurring IRC meeting on #rdo In-Reply-To: <52CFE417.5080200@redhat.com> References: <52CDD1AB.1090706@redhat.com> <20140109140535.GE15539@redhat.com> <52CEBA13.4020901@redhat.com> <52CEE0C3.1000906@redhat.com> <52CFE417.5080200@redhat.com> Message-ID: <1389361285.2846.7.camel@localhost.localdomain> When a time is finalized, please send an email out. I'd love to get this on my calendar. Thanks!! From lars at redhat.com Fri Jan 10 14:15:10 2014 From: lars at redhat.com (Lars Kellogg-Stedman) Date: Fri, 10 Jan 2014 09:15:10 -0500 Subject: [Rdo-list] F20 networking refuses to start on boot In-Reply-To: <20140109222237.130db91e@lembas.zaitcev.lan> References: <20140109133454.696de62c@lembas.zaitcev.lan> <20140109204013.GG28799@redhat.com> <20140109222237.130db91e@lembas.zaitcev.lan> Message-ID: <20140110141510.GA24304@redhat.com> [I'm redirecting this to rdo-list for wider exposure.] On Thu, Jan 09, 2014 at 10:22:36PM -0700, Pete Zaitcev wrote: > On Thu, 9 Jan 2014 15:40:13 -0500 > Lars Kellogg-Stedman wrote: > > > On Thu, Jan 09, 2014 at 01:34:54PM -0700, Pete Zaitcev wrote: > > > > It feels like something simple enough, but... I installed RDO on F20 > > > as a part of Test Day on Tuesday. Then I added a flat network to it, > > > and I found no better way to do it than to take the main Ethernet > > > out of the control of NetworkManager by adding NM_CONTROLLED=no to > > > ifcfg-br-ex and ifcfg-p4p1. Ever since, the box has no network on boot. > > > I have to log in on console and do "ifdown br-ex; ifup br-ex". > > > > Have you installed and activate the "network" service? > > > > chkconfig network on > > > > This is the legacy /etc/init.d/network script that brings up > > networking in the absence of NetworkManager. > > I have done it and it makes no difference: Actually, it looks like I'm experiencing the same issue with br-ex on my F20 openstack install. Given an interface configuration file /etc/sysconfig/network-scripts/ifcfg-br-ex that looks like this: DEVICE=br-ex DEVICETYPE=ovs TYPE=OVSBridge BOOTPROTO=static IPADDR=172.24.4.225 NETMASK=255.255.255.240 ONBOOT=yes After I boot the interface looks like this: br-ex: flags=67 mtu 1500 inet6 fe80::888c:81ff:febd:d8b8 prefixlen 64 scopeid 0x20 ether 3a:69:08:00:0f:40 txqueuelen 0 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 8 bytes 648 (648.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 Running ifdown/ifup as Pete describes correctly configures the interface. I'm starting up another F20 system right now to see if this is a general problem with OVS bridges or if there's something peculiar on my install. -- Lars Kellogg-Stedman | larsks @ irc Cloud Engineering / OpenStack | " " @ twitter -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From kchamart at redhat.com Fri Jan 10 14:43:18 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Fri, 10 Jan 2014 15:43:18 +0100 Subject: [Rdo-list] RDO Bug triage: 15JAN2014; UTC 14:00 Message-ID: <52D00706.5080400@redhat.com> Since there are no real objections to the proposed time and there's a rough consensus, we'll go ahead with the first bug triage day on 15-JAN-2014, UTC 14:00 in #rdo channel. Please drop by if you have some spare cycles and participate in triaging with your expertise area. Convenience info ---------------- - List of un-triaged bugs (NEW state) -- http://goo.gl/NqW2LN - List of all ASSIGNED bugs (with and without Keyword 'Triaged') -- http://goo.gl/oFY9vX - List of all ON_QA bugs -- http://goo.gl/CZX92r The above info is also here -- http://openstack.redhat.com/RDO-BugTriage If I missed to note something, please free to add here. Thanks. -- /kashyap From lars at redhat.com Fri Jan 10 16:35:05 2014 From: lars at redhat.com (Lars Kellogg-Stedman) Date: Fri, 10 Jan 2014 11:35:05 -0500 Subject: [Rdo-list] F20 networking refuses to start on boot In-Reply-To: <20140110141510.GA24304@redhat.com> References: <20140109133454.696de62c@lembas.zaitcev.lan> <20140109204013.GG28799@redhat.com> <20140109222237.130db91e@lembas.zaitcev.lan> <20140110141510.GA24304@redhat.com> Message-ID: <20140110163505.GA24956@redhat.com> On Fri, Jan 10, 2014 at 09:15:10AM -0500, Lars Kellogg-Stedman wrote: > I'm starting up another F20 system right now to see if this is a > general problem with OVS bridges or if there's something peculiar on > my install. So this appears to be a general problem with OVS bridges on F20. I've opened https://bugzilla.redhat.com/show_bug.cgi?id=1051593 against initscripts. If I start with the F20 cloud image and install OpenVswitch: yum install openvswitch And enable openvswitch: systemctl enable openvswtich And create a bridge device: ovs-vsctl add-br br0 And add an interface configuration file that looks like this: DEVICE=br0 DEVICETYPE=ovs TYPE=OVSBridge BOOTPROTO=static IPADDR=172.24.4.225 NETMASK=255.255.255.240 ONBOOT=yes And reboot, I end up with: # ip addr show dev br0 4: br0: mtu 1500 qdisc noqueue state UNKNOWN group default link/ether ce:ac:68:75:a2:4d brd ff:ff:ff:ff:ff:ff inet6 fe80::e8ec:8aff:fe03:dd51/64 scope link valid_lft forever preferred_lft forever If I run: # ifdown br0 # ifup br0 I get what I expect: # ip addr show dev br0 5: br0: mtu 1500 qdisc noqueue state UNKNOWN group default link/ether 0a:49:24:10:dc:4d brd ff:ff:ff:ff:ff:ff inet 172.24.4.225/28 brd 172.24.4.239 scope global br0 valid_lft forever preferred_lft forever inet6 fe80::cc6c:9cff:fef1:d32a/64 scope link valid_lft forever preferred_lft forever -- Lars Kellogg-Stedman | larsks @ irc Cloud Engineering / OpenStack | " " @ twitter -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From zaitcev at redhat.com Fri Jan 10 18:14:20 2014 From: zaitcev at redhat.com (Pete Zaitcev) Date: Fri, 10 Jan 2014 11:14:20 -0700 Subject: [Rdo-list] F20 networking refuses to start on boot In-Reply-To: <20140110163505.GA24956@redhat.com> References: <20140109133454.696de62c@lembas.zaitcev.lan> <20140109204013.GG28799@redhat.com> <20140109222237.130db91e@lembas.zaitcev.lan> <20140110141510.GA24304@redhat.com> <20140110163505.GA24956@redhat.com> Message-ID: <20140110111420.0fc804f1@lembas.zaitcev.lan> On Fri, 10 Jan 2014 11:35:05 -0500 Lars Kellogg-Stedman wrote: > So this appears to be a general problem with OVS bridges on F20. I've > opened https://bugzilla.redhat.com/show_bug.cgi?id=1051593 against > initscripts. Thanks for taking care of bz. I'm still open to the alternative, using NM, if anyone knows how to do that. -- Pete From kchamart at redhat.com Fri Jan 10 23:13:36 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Sat, 11 Jan 2014 00:13:36 +0100 Subject: [Rdo-list] F20 networking refuses to start on boot In-Reply-To: <20140110163505.GA24956@redhat.com> References: <20140109133454.696de62c@lembas.zaitcev.lan> <20140109204013.GG28799@redhat.com> <20140109222237.130db91e@lembas.zaitcev.lan> <20140110141510.GA24304@redhat.com> <20140110163505.GA24956@redhat.com> Message-ID: <52D07EA0.40103@redhat.com> On 01/10/2014 05:35 PM, Lars Kellogg-Stedman wrote: > On Fri, Jan 10, 2014 at 09:15:10AM -0500, Lars Kellogg-Stedman wrote: >> I'm starting up another F20 system right now to see if this is a >> general problem with OVS bridges or if there's something peculiar on >> my install. > > So this appears to be a general problem with OVS bridges on F20. I've > opened https://bugzilla.redhat.com/show_bug.cgi?id=1051593 against > initscripts. IIRC, I've noticed something like that among the various issues I was trying to note down over the course of test days. Thanks for chasing this down, Lars! > > If I start with the F20 cloud image and install OpenVswitch: > > yum install openvswitch > > And enable openvswitch: > > systemctl enable openvswtich > > And create a bridge device: > > ovs-vsctl add-br br0 > > And add an interface configuration file that looks like this: > > DEVICE=br0 > DEVICETYPE=ovs > TYPE=OVSBridge > BOOTPROTO=static > IPADDR=172.24.4.225 > NETMASK=255.255.255.240 > ONBOOT=yes > > And reboot, I end up with: > > # ip addr show dev br0 > 4: br0: mtu 1500 qdisc noqueue state UNKNOWN group default > link/ether ce:ac:68:75:a2:4d brd ff:ff:ff:ff:ff:ff > inet6 fe80::e8ec:8aff:fe03:dd51/64 scope link > valid_lft forever preferred_lft forever > > If I run: > > # ifdown br0 > # ifup br0 > > I get what I expect: > > # ip addr show dev br0 > 5: br0: mtu 1500 qdisc noqueue state UNKNOWN group default > link/ether 0a:49:24:10:dc:4d brd ff:ff:ff:ff:ff:ff > inet 172.24.4.225/28 brd 172.24.4.239 scope global br0 > valid_lft forever preferred_lft forever > inet6 fe80::cc6c:9cff:fef1:d32a/64 scope link > valid_lft forever preferred_lft forever > > > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > -- /kashyap From bderzhavets at hotmail.com Sat Jan 11 18:07:43 2014 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Sat, 11 Jan 2014 13:07:43 -0500 Subject: [Rdo-list] Neutron stops to work on F20 at certain point of time In-Reply-To: <20140110111420.0fc804f1@lembas.zaitcev.lan> References: <20140109133454.696de62c@lembas.zaitcev.lan>, <20140109204013.GG28799@redhat.com>, <20140109222237.130db91e@lembas.zaitcev.lan>, <20140110141510.GA24304@redhat.com>, <20140110163505.GA24956@redhat.com>, <20140110111420.0fc804f1@lembas.zaitcev.lan> Message-ID: At the beginning instances created could not be connected by ssh and did not respond to ping. Then Neutron became unable to connect to AMQP server. Server.log attached. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: server.log URL: From bderzhavets at hotmail.com Sat Jan 11 18:12:56 2014 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Sat, 11 Jan 2014 13:12:56 -0500 Subject: [Rdo-list] =?utf-8?q?Neutron_stops_to_work_on_F20_at_certain_poin?= =?utf-8?b?dCBvZiB0aW1lIOKAjyAy?= In-Reply-To: <20140110111420.0fc804f1@lembas.zaitcev.lan> References: <20140109133454.696de62c@lembas.zaitcev.lan>, <20140109204013.GG28799@redhat.com>, <20140109222237.130db91e@lembas.zaitcev.lan>, <20140110141510.GA24304@redhat.com>, <20140110163505.GA24956@redhat.com>, <20140110111420.0fc804f1@lembas.zaitcev.lan> Message-ID: [root at openstack1 ~(keystone_admin)]# neutron net-list Connection to neutron failed: Maximum attempts reached [root at openstack1 ~(keystone_admin)]# service neutron-server status Redirecting to /bin/systemctl status neutron-server.service neutron-server.service - OpenStack Quantum Server Loaded: loaded (/usr/lib/systemd/system/neutron-server.service; enabled) Active: active (running) since Sat 2014-01-11 21:41:02 VOLT; 13min ago Main PID: 1664 (neutron-server) CGroup: /system.slice/neutron-server.service ??1664 /usr/bin/python /usr/bin/neutron-server --config-file /usr/share/neutron/neutron-dis... Jan 11 21:44:36 openstack1.localdomain neutron-server[1664]: 2014-01-11 21:44:36.106 1664 ERROR neut...ds Jan 11 21:45:36 openstack1.localdomain neutron-server[1664]: 2014-01-11 21:45:36.163 1664 ERROR neut...ds Jan 11 21:46:36 openstack1.localdomain neutron-server[1664]: 2014-01-11 21:46:36.223 1664 ERROR neut...ds Jan 11 21:47:36 openstack1.localdomain neutron-server[1664]: 2014-01-11 21:47:36.247 1664 ERROR neut...ds Jan 11 21:48:36 openstack1.localdomain neutron-server[1664]: 2014-01-11 21:48:36.306 1664 ERROR neut...ds Jan 11 21:49:36 openstack1.localdomain neutron-server[1664]: 2014-01-11 21:49:36.364 1664 ERROR neut...ds Jan 11 21:50:36 openstack1.localdomain neutron-server[1664]: 2014-01-11 21:50:36.410 1664 ERROR neut...ds Jan 11 21:51:36 openstack1.localdomain neutron-server[1664]: 2014-01-11 21:51:36.431 1664 ERROR neut...ds Jan 11 21:52:36 openstack1.localdomain neutron-server[1664]: 2014-01-11 21:52:36.491 1664 ERROR neut...ds Jan 11 21:53:36 openstack1.localdomain neutron-server[1664]: 2014-01-11 21:53:36.550 1664 ERROR neut...ds Hint: Some lines were ellipsized, use -l to show in full. -------------- next part -------------- An HTML attachment was scrubbed... URL: From yeylon at redhat.com Sun Jan 12 15:19:35 2014 From: yeylon at redhat.com (Yaniv Eylon) Date: Sun, 12 Jan 2014 10:19:35 -0500 (EST) Subject: [Rdo-list] RDO Bug triage: 15JAN2014; UTC 14:00 In-Reply-To: <52D00706.5080400@redhat.com> References: <52D00706.5080400@redhat.com> Message-ID: <1879393080.96726.1389539975248.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Kashyap Chamarthy" > To: "rdo-list" > Sent: Friday, January 10, 2014 4:43:18 PM > Subject: [Rdo-list] RDO Bug triage: 15JAN2014; UTC 14:00 > > Since there are no real objections to the proposed time and there's a > rough consensus, we'll go ahead with the first bug triage day on > 15-JAN-2014, UTC 14:00 in #rdo channel. Please drop by if you have some > spare cycles and participate in triaging with your expertise area. Kashyap, can you please send an invitation. (if it is not in a calendar it'll probably be missed) 10x. > > > Convenience info > ---------------- > > - List of un-triaged bugs (NEW state) -- http://goo.gl/NqW2LN > > - List of all ASSIGNED bugs (with and without Keyword 'Triaged') > -- http://goo.gl/oFY9vX > > - List of all ON_QA bugs -- http://goo.gl/CZX92r > > > The above info is also here -- http://openstack.redhat.com/RDO-BugTriage > > If I missed to note something, please free to add here. > > Thanks. > > -- > /kashyap > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > > From bderzhavets at hotmail.com Sun Jan 12 19:05:48 2014 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Sun, 12 Jan 2014 14:05:48 -0500 Subject: [Rdo-list] Neutron fails to connect to AMQP Server on Fedora 20 ( at startup) 3 Message-ID: Next fresh install F20 & Havana via native repo. Issue seems to be related to https://bugzilla.redhat.com/show_bug.cgi?id=1051593 Straight forward `packstack --alinone` install via native Havana repo with no problems. Openstack-status is fine immediately after RDO setup Recreating external network, OVS bridge "br-ex" and p37p1 as OVS port for "br-ex" Reboot. Openstack-status reports server errors 1.) [root at openstack1 neutron(keystone_admin)]# nova net-list reports server error 2) [root at openstack1 neutron(keystone_admin)]# nova service-list shows state down every where 3) /var/log/neutron/server.log.gz is attached. I believe to fix it , but it's just a hack [boris at openstack1 ~]$ sudo su - [sudo] password for boris: Last login: Sun Jan 12 17:35:21 MSK 2014 on pts/0 [root at openstack1 ~]# ls -l /etc/neutron/neutron.conf -rw-r-----. 1 root neutron 14386 Jan 12 16:15 /etc/neutron/neutron.conf [root at openstack1 ~]# vi /etc/neutron/neutron.conf Uncommented : # Paste configuration file api_paste_config = api-paste.ini Updated /etc/rc.d/rc.local :- [root at openstack1 neutron(keystone_admin)]# cat /etc/rc.d/rc.local #!/bin/sh losetup -f /var/lib/cinder/cinder-volumes && vgchange -a y cinder-volumes && systemctl restart openstack-cinder-volume.service ifdown br-ex ; ifup br-ex ; service network restart ; # Three times would be enough in general , but may be less systemctl restart qpidd.service ; systemctl restart qpidd.service ; systemctl restart qpidd.service ; service openstack-nova-compute restart ; exit 0 Then in openstack-status report instead of server errors I get :- [root at openstack1 neutron(keystone_admin)]# nova service-list +------------------+------------------------+----------+---------+-------+----------------------------+-----------------+ | Binary | Host | Zone | Status | State | Updated_at Disabled Reason | +------------------+------------------------+----------+---------+-------+----------------------------+-----------------+ | nova-consoleauth | openstack1.localdomain | internal | enabled | up | 2014-01-12T14:01:20.000000 | None | | nova-scheduler | openstack1.localdomain | internal | enabled | up | 2014-01-12T14:01:20.000000 | None | | nova-conductor | openstack1.localdomain | internal | enabled | up | 2014-01-12T14:01:21.000000 | None | | nova-cert | openstack1.localdomain | internal | enabled | up | 2014-01-12T14:01:20.000000 | None | | nova-compute | openstack1.localdomain | nova | enabled | up | 2014-01-12T14:01:19.000000 | None | +------------------+------------------------+----------+---------+-------+----------------------------+-----------------+ [root at openstack1 neutron(keystone_admin)]# nova net-list +--------------------------------------+---------+------+ | ID | Label | CIDR | +--------------------------------------+---------+------+ | 54aa7248-072d-4d2d-a953-916894946c23 | private | None | | d8760dfb-0619-4cd1-a033-51bb04eeb402 | public | None | +--------------------------------------+---------+------+ Neutron brought back to life [root at openstack1 neutron(keystone_admin)]# neutron net-list +--------------------------------------+---------+-----------------------------------------------------+ | id | name | subnets | +--------------------------------------+---------+-----------------------------------------------------+ | 54aa7248-072d-4d2d-a953-916894946c23 | private | ec123834-0cae-43b7-b85a-b6329dcc5e88 10.0.0.0/24 | | d8760dfb-0619-4cd1-a033-51bb04eeb402 | public | 87c37096-1186-4c67-8548-fb6c88839636 192.168.1.0/24 | +--------------------------------------+---------+-----------------------------------------------------+ [root at openstack1 neutron(keystone_admin)]# neutron subnet-list +--------------------------------------+----------------+----------------+--------------------------------------------------+ | id | name | cidr | allocation_pools | +--------------------------------------+----------------+----------------+--------------------------------------------------+ | ec123834-0cae-43b7-b85a-b6329dcc5e88 | private_subnet | 10.0.0.0/24 | {"start": "10.0.0.2", "end": "10.0.0.254"} | | 87c37096-1186-4c67-8548-fb6c88839636 | public_subnet | 192.168.1.0/24 | {"start": "192.168.1.57", "end": "192.168.1.97"} | +--------------------------------------+----------------+----------------+--------------------------------------------------+ [root at openstack1 neutron(keystone_admin)]# ovs-vsctl show d3454efb-b3d9-42d2-a277-913d5cf755fe Bridge br-ex Port br-ex Interface br-ex type: internal Port "qg-ce79686e-b8" Interface "qg-ce79686e-b8" type: internal Port "p37p1" Interface "p37p1" Bridge br-int Port "qvo10bf42f7-82" tag: 1 Interface "qvo10bf42f7-82" Port "qr-01bdcf4b-05" tag: 1 Interface "qr-01bdcf4b-05" type: internal Port "tapf8c3475f-f0" tag: 1 Interface "tapf8c3475f-f0" type: internal Port br-int Interface br-int type: internal Port "qvofee768e5-64" tag: 1 Interface "qvofee768e5-64" ovs_version: "2.0.0" -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: server.log.gz Type: application/x-gzip Size: 11511 bytes Desc: not available URL: From mrunge at redhat.com Mon Jan 13 07:53:04 2014 From: mrunge at redhat.com (Matthias Runge) Date: Mon, 13 Jan 2014 08:53:04 +0100 Subject: [Rdo-list] Neutron fails to connect to AMQP Server on Fedora 20 ( at startup) 3 In-Reply-To: References: Message-ID: <52D39B60.1030601@redhat.com> On 01/12/2014 08:05 PM, Boris Derzhavets wrote: > Next fresh install F20 & Havana via native repo. > > Issue seems to be related to > https://bugzilla.redhat.com/show_bug.cgi?id=1051593 > I think this is due https://bugzilla.redhat.com/show_bug.cgi?id=1050842 (with workaround) Matthias From bderzhavets at hotmail.com Mon Jan 13 08:53:03 2014 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Mon, 13 Jan 2014 03:53:03 -0500 Subject: [Rdo-list] Neutron fails to connect to AMQP Server on Fedora 20 ( at startup) 3 In-Reply-To: <52D39B60.1030601@redhat.com> References: , <52D39B60.1030601@redhat.com> Message-ID: Original /etc/neutron/neutron.conf already has # signing_dir = $state_path/keystone-signing auth_uri=http://192.168.1.145:5000/ and I am still experiencing this problem. It looks like repeating # service qpidd restart gives neutron option to reconnect to AMQP server Thanks. Boris. > Date: Mon, 13 Jan 2014 08:53:04 +0100 > From: mrunge at redhat.com > To: rdo-list at redhat.com > Subject: Re: [Rdo-list] Neutron fails to connect to AMQP Server on Fedora 20 ( at startup) 3 > > On 01/12/2014 08:05 PM, Boris Derzhavets wrote: > > Next fresh install F20 & Havana via native repo. > > > > Issue seems to be related to > > https://bugzilla.redhat.com/show_bug.cgi?id=1051593 > > > I think this is due > > https://bugzilla.redhat.com/show_bug.cgi?id=1050842 > > (with workaround) > > Matthias > > _______________________________________________ > 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 kchamart at redhat.com Mon Jan 13 09:01:12 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Mon, 13 Jan 2014 10:01:12 +0100 Subject: [Rdo-list] RDO Bug triage: 15JAN2014; UTC 14:00 In-Reply-To: <1879393080.96726.1389539975248.JavaMail.root@redhat.com> References: <52D00706.5080400@redhat.com> <1879393080.96726.1389539975248.JavaMail.root@redhat.com> Message-ID: <52D3AB58.2020504@redhat.com> On 01/12/2014 04:19 PM, Yaniv Eylon wrote: > > > ----- Original Message ----- >> From: "Kashyap Chamarthy" >> To: "rdo-list" >> Sent: Friday, January 10, 2014 4:43:18 PM >> Subject: [Rdo-list] RDO Bug triage: 15JAN2014; UTC 14:00 >> >> Since there are no real objections to the proposed time and there's a >> rough consensus, we'll go ahead with the first bug triage day on >> 15-JAN-2014, UTC 14:00 in #rdo channel. Please drop by if you have some >> spare cycles and participate in triaging with your expertise area. > > Kashyap, can you please send an invitation. (if it is not in a calendar it'll probably be missed) I'm afraid, as of now I don't think (maybe I'm wrong) there's a sensible way to send calendar invitations to public list. For now, I AFAIK, upstream OpenStack doesn't use invitations either (people use a combination of Wiki page + Google Calendar, etc, but manually) for public IRC meetings. However, there's a discussion started by Thierry Carrez (OpenStack release team) on Infra list about a potential Week-end project of "Gerrit-powered meetings agenda" : http://lists.openstack.org/pipermail/openstack-infra/2013-December/000517.html I looked at Fedora Project, they just recently started using a calendaring server: https://apps.fedoraproject.org/calendar -- /kashyap From rohara at redhat.com Mon Jan 13 15:03:30 2014 From: rohara at redhat.com (Ryan O'Hara) Date: Mon, 13 Jan 2014 09:03:30 -0600 Subject: [Rdo-list] New RDO page for LBaaS Message-ID: <20140113150328.GC24385@redhat.com> I've written a guide for deploying LBaaS with RDO Havana, which also covers some simple tests. The guide can be found here: http://openstack.redhat.com/LBaaS Comments and questions are encouraged. Ryan From kchamart at redhat.com Mon Jan 13 15:06:11 2014 From: kchamart at redhat.com (Kashyap Chamarthy) Date: Mon, 13 Jan 2014 16:06:11 +0100 Subject: [Rdo-list] RDO Bug triage: 15JAN2014; UTC 14:00 In-Reply-To: <52D3AB58.2020504@redhat.com> References: <52D00706.5080400@redhat.com> <1879393080.96726.1389539975248.JavaMail.root@redhat.com> <52D3AB58.2020504@redhat.com> Message-ID: <52D400E3.6080402@redhat.com> [. . .] >> Kashyap, can you please send an invitation. (if it is not in a calendar it'll probably be missed) > > I'm afraid, as of now I don't think (maybe I'm wrong) there's a sensible > way to send calendar invitations to public list. For now, I Oops, truncated sentence, I meant - For now, I hope mailing list invite would do & folks who are interested to participate would just remember. > > AFAIK, upstream OpenStack doesn't use invitations either (people use a > combination of Wiki page + Google Calendar, etc, but manually) for > public IRC meetings. > > However, there's a discussion started by Thierry Carrez (OpenStack > release team) on Infra list about a potential Week-end project of > "Gerrit-powered meetings agenda" : > http://lists.openstack.org/pipermail/openstack-infra/2013-December/000517.html > > > I looked at Fedora Project, they just recently started using a > calendaring server: > > https://apps.fedoraproject.org/calendar -- /kashyap From rohara at redhat.com Mon Jan 13 15:55:53 2014 From: rohara at redhat.com (Ryan O'Hara) Date: Mon, 13 Jan 2014 09:55:53 -0600 Subject: [Rdo-list] Formatting tip for RDO wiki pages Message-ID: <20140113155553.GD24385@redhat.com> In the recent LBaaS wiki page I wrote, I need to show output from various command-line clients. The problem I ran into is that the wiki page will wrap anything enclosed in 
 tags, so I ended up with the
following solution:


...



This will add a horizontal scrollbar to the bottom of the preformatted
text box, which is the best solution I could come up with for handling
wide blocks of text. I've tested this with Firefox, IE, and Chrome and
it seems to render correctly on each.

Ryan



From rbowen at redhat.com  Mon Jan 13 17:29:47 2014
From: rbowen at redhat.com (Rich Bowen)
Date: Mon, 13 Jan 2014 12:29:47 -0500
Subject: [Rdo-list] RDO Bug triage: 15JAN2014; UTC 14:00
In-Reply-To: <52D400E3.6080402@redhat.com>
References: <52D00706.5080400@redhat.com>	<1879393080.96726.1389539975248.JavaMail.root@redhat.com>	<52D3AB58.2020504@redhat.com>
	<52D400E3.6080402@redhat.com>
Message-ID: <52D4228B.40509@redhat.com>


On 01/13/2014 10:06 AM, Kashyap Chamarthy wrote:
>>> Kashyap, can you please send an invitation. (if it is not in a calendar it'll probably be missed)
>> >
>> >I'm afraid, as of now I don't think (maybe I'm wrong) there's a sensible
>> >way to send calendar invitations to public list. For now, I
> Oops, truncated sentence, I meant - For now, I hope mailing list invite
> would do & folks who are interested to participate would just remember.
>
One possibility is to create the event in Google Calendar, and send an 
invite from there to the list. I can moderate it through from there.

--Rich

-- 
Rich Bowen - rbowen at redhat.com
OpenStack Community Liaison
http://openstack.redhat.com/



From lars at redhat.com  Mon Jan 13 18:07:03 2014
From: lars at redhat.com (Lars Kellogg-Stedman)
Date: Mon, 13 Jan 2014 13:07:03 -0500
Subject: [Rdo-list] New RDO page for LBaaS
In-Reply-To: <20140113150328.GC24385@redhat.com>
References: <20140113150328.GC24385@redhat.com>
Message-ID: <20140113180703.GA30987@redhat.com>

On Mon, Jan 13, 2014 at 09:03:30AM -0600, Ryan O'Hara wrote:
> I've written a guide for deploying LBaaS with RDO Havana, which also
> covers some simple tests. The guide can be found here:

That looks like a really nice guide.  Thanks!

-- 
Lars Kellogg-Stedman  | larsks @ irc
Cloud Engineering / OpenStack          | "   "  @ twitter

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 

From pbrady at redhat.com  Tue Jan 14 00:14:26 2014
From: pbrady at redhat.com (=?ISO-8859-1?Q?P=E1draig_Brady?=)
Date: Tue, 14 Jan 2014 00:14:26 +0000
Subject: [Rdo-list] Formatting tip for RDO wiki pages
In-Reply-To: <20140113155553.GD24385@redhat.com>
References: <20140113155553.GD24385@redhat.com>
Message-ID: <52D48162.1010008@redhat.com>

On 01/13/2014 03:55 PM, Ryan O'Hara wrote:
> 
> In the recent LBaaS wiki page I wrote, I need to show output from
> various command-line clients. The problem I ran into is that the wiki
> page will wrap anything enclosed in 
 tags, so I ended up with the
> following solution:
> 
> 
> ...
> 

> 
> This will add a horizontal scrollbar to the bottom of the preformatted
> text box, which is the best solution I could come up with for handling
> wide blocks of text. I've tested this with Firefox, IE, and Chrome and
> it seems to render correctly on each.

Thanks for the attention to detail Ryan.

Can the powers that be, set that as the default 
 style.

Personally can never deal with wrapping and use the following
in my .bashrc to leverage less' support of horizontal scrolling,
as less is used as the default pager by many commands:

  export LESS="-iRS"

"S" is the pertinent option here.
"R" enables less to display colors.
"i" uses case insensitive search.

cheers,
P?draig.



From sgordon at redhat.com  Tue Jan 14 14:04:56 2014
From: sgordon at redhat.com (Steve Gordon)
Date: Tue, 14 Jan 2014 09:04:56 -0500 (EST)
Subject: [Rdo-list] Enabling 'ovs_use_veth' for DHCP/L3 agents breaks
 Neutron on recent versions of RHEL/CentOS
In-Reply-To: <2017250449.1845559.1389708177483.JavaMail.root@redhat.com>
Message-ID: <925877507.1847003.1389708296298.JavaMail.root@redhat.com>

Hi all,

I was asked to take a look at this bug for the openstack-manuals project - "Enabling 'ovs_use_veth' for DHCP/L3 agents breaks Neutron on recent versions of CentOS":

    https://bugs.launchpad.net/openstack-manuals/+bug/1268806

"After assisting someone with troubleshooting networking, I determined that setting 'ovs_use_veth = True' in dhcp_agent.ini and l3_agent.ini breaks Neutron (at least with GRE) on recent versions of CentOS... perhaps because the kernel seems to fully support namespaces. This issue probably also affects Scientific Linux. Can anyone confirm whether recent RHEL kernels fully support namespaces? I would like to clarify this step and similar steps in other sections for all distributions."

Questions I have are:

a) Is it likely/expected that enabling ovs_use_veth = True will cause issues when using a kernel that supports netns?

b) Is there any downside at this point to setting ovs_use_veth = False?

Thanks,

Steve



From rbowen at redhat.com  Tue Jan 14 15:06:49 2014
From: rbowen at redhat.com (Rich Bowen)
Date: Tue, 14 Jan 2014 10:06:49 -0500
Subject: [Rdo-list] First IRC RDO community meeting
Message-ID: <52D55289.6050307@redhat.com>

Mike Burns and I have been meeting by phone for a few months to discuss 
various things around the RDO community. This call has grown, and this 
morning we moved it to IRC both to accommodate that growth and to make 
what we're working on a little more transparent to the community. We're 
going to do this regularly, 9am eastern time, on the #rdo channel on 
Freenode.

The notes from this morning's chat are at 
http://meetbot.fedoraproject.org/rdo/2014-01-14/rdo_community_meeting.2014-01-14-14.02.html 
... however, it appears that we didn't do the log bot commands 
correctly, so I'll try to post a followup with the notes a little more 
coherent. A full log is at 
http://meetbot.fedoraproject.org/rdo/2014-01-14/rdo_community_meeting.2014-01-14-14.02.log.html 
but I don't expect anybody wants to read through that.

--Rich

-- 
Rich Bowen - rbowen at redhat.com
OpenStack Community Liaison
http://openstack.redhat.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rbowen at redhat.com  Tue Jan 14 15:35:06 2014
From: rbowen at redhat.com (Rich Bowen)
Date: Tue, 14 Jan 2014 10:35:06 -0500
Subject: [Rdo-list] First IRC RDO community meeting
In-Reply-To: <52D55289.6050307@redhat.com>
References: <52D55289.6050307@redhat.com>
Message-ID: <52D5592A.8040307@redhat.com>


On 01/14/2014 10:06 AM, Rich Bowen wrote:
> Mike Burns and I have been meeting by phone for a few months to 
> discuss various things around the RDO community. This call has grown, 
> and this morning we moved it to IRC both to accommodate that growth 
> and to make what we're working on a little more transparent to the 
> community. We're going to do this regularly, 9am eastern time, on the 
> #rdo channel on Freenode.
>
> The notes from this morning's chat are at 
> http://meetbot.fedoraproject.org/rdo/2014-01-14/rdo_community_meeting.2014-01-14-14.02.html 
> ... however, it appears that we didn't do the log bot commands 
> correctly, so I'll try to post a followup with the notes a little more 
> coherent. A full log is at 
> http://meetbot.fedoraproject.org/rdo/2014-01-14/rdo_community_meeting.2014-01-14-14.02.log.html 
> but I don't expect anybody wants to read through that.

Ok, here's the more coherent meeting summary. Meanwhile, we'll figure 
out the log bot before the next time.

*#topic RDO Community meeting**
**Ether pad at: https://etherpad.openstack.org/p/rdo_community_manager_sync*

Test Day:

M2 release is scheduled for January 23rd. Although an initial date of 
the 30th was suggested for the next test day, we want to be sure that we 
have packages for all of the relevant platforms, and that QA has had a 
chance to test them so that folks don't all run into the same issues. 
February 4th and 5th have been suggested for possible test days. (Dates 
are NOT final.)

Action: Rich will follow up on rdo-list with email about proposed dates 
to see if this works for everyone.
Action: Rich will also write up a blog post for RedHatStack for wider 
publicity.
Action: Flavio said he'd try to get Marconi packaged up for the test day.

Hangouts:

I'd like to start doing the hangouts again. We had a good start, and 
then I dropped it. So I need to start bugging people about doing some 
more. If you'd like to volunteer for a 30-60 minute presentation on what 
you're working on, please speak up.

February Newsletter:

I'm starting to gather items to write about in the February RDO newsletter.

https://etherpad.openstack.org/p/rdo_newsletter_2014_02

We send this out to about 2000 people every month. If you're not on 
there, you can join at 
http://www.redhat.com/mailman/listinfo/rdo-newsletter  If you have 
anything you'd like to have mentioned in the newsletter, please add it 
to that etherpad. If you'd like to write something for the newsletter, 
please contact rbowen at redhat.com.

Current topics include:

     IRC meetings
     FOSDEM
     Infrastructure.Next
     SCALE
     CentOS Cloud SIG
     RDO bug triage meeting

FOSDEM

FOSDEM is February 1-2 in Brussels. Rich is planning to do (audio) 
interviews (10 minutes roughly) with anybody and everybody that's 
involved in RDO. These might be used on the RDO site, or on Joe 
Brockmeier's new 'Cloud Forecast' podcast. See 
http://drbacchus.com/flavio-percoco-on-openstack-marconi for an example 
of the ones that I did at OpenStack Summit. If you'd like to talk to the 
world about what you're doing on OpenStack, and you'll be at FOSDEM, 
just come talk to me. I'll have my recorder in my pocket.

If you'd like to talk about what you're doing on OpenStack and you won't 
be at FOSDEM, email rbowen at redhat.com and we'll set up a phone/skype thing.

The schedule for the Virtualization/IaaS devroom at FOSDEM has been 
posted. https://fosdem.org/2014/schedule/track/virtualisation_and_iaas/

After FOSDEM, there's a second event called Infrastructure.next. I 
posted to rdo-list about it last week: 
http://community.redhat.com/blog/2013/12/announcing-infrastructure-next/

If you'd like to speak at infrastructure.next contact jzb at redhat.com

Bitergia Stats

http://openstack.redhat.com/stats/

Not much to say here, other than, we have cool stats, done by the same 
folks that do Stackalytics - Bitergia.  They're interesting and 
informative, and if you haven't looked yet, have a look. They're pretty 
awesome, particularly if you're a stats geek like me.

CentOS Cloud SIG

If you're not on the centos-devel mailing list, it would be a good thing 
to join if you're interested in RDO on CentOS. 
http://lists.centos.org/mailman/listinfo/centos-devel

mburned, and many other people, have started "Let's have a Cloud SIG" 
thread. There's an organizational kickoff meeting for the CentOS Cloud 
SIG on a Google hangout on 23-Jan.

The consensus is, I think, coming around to let's have one unified cloud 
sig with variants for each cloud platform (openstack, eucalyptus, 
opennebula, cloudstack, and so on) There's clearly a lot of energy, and 
people wanting to see this happen. So jump in and speak up.

Bug triage meeting

A bug triage meeting has been organized for the 3rd Wednesday of each 
month here on IRC. First meeting set for tomorrow 15-Jan at the same 
time as this meeting.

We'll review the current open issues and bugs during this meeting. We'll 
also re-evaluate the recurrence of this meeting if we find that it's too 
much or not enough.

https://etherpad.openstack.org/p/RDO-BugTriage

Anyone interested in participating can just show up.

Open Forum Questions

(See list in etherpad)

People have been incredibly responsive when I've bugged them about 
answering questions. There are, however, a handful of questions - 
probably the first 4 in the list - that have been open a long time and 
could use some love. I also need to figure out how to filter questions 
that are answered, but the answer hasn't been accepted. I don't know how 
many folks actually bother to accept/agree the answer - it's not very 
many. So there's actually a lot of questions where someone has posted an 
answer, but it's not really an answer, it's more of a comment.

Proposal: Add a "solution-proposed" flag or similar. But we need people 
to have enough karma to convert comments to answers and vice versa, and 
to add tags.

https://ask.openstack.org/en/questions/scope:unanswered/sort:answers-asc/page:1/query:rdo/ 
is the unanswered RDO list. 17 this morning. We've been holding at 
around 9 for the last few weeks.

I also need to work some with the API to get some reports of things that 
have been unanswered and/or without activity for a long time.



-- 
Rich Bowen - rbowen at redhat.com
OpenStack Community Liaison
http://openstack.redhat.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From walter.derezinski at ericsson.com  Tue Jan 14 16:04:02 2014
From: walter.derezinski at ericsson.com (Walter Derezinski)
Date: Tue, 14 Jan 2014 16:04:02 +0000
Subject: [Rdo-list] Rdo-list Digest, Vol 10, Issue 17
In-Reply-To: 
References: 
Message-ID: 

unsubscribe
-- 
WALTER DEREZINSKI 
System Manager

Ericsson Television Inc.
Solution Area Media
4500 River Green Pkwy
Duluth, GA 30096, USA
Phone +1-678-404-1432
walter.derezinski at ericsson.com
www.ericsson.com

 
This Communication is Confidential. We only send and receive email on the
basis of the terms set out atwww.ericsson.com/email_disclaimer







On 1/14/14, 10:35 AM, "rdo-list-request at redhat.com"
 wrote:

>Send Rdo-list mailing list submissions to
>	rdo-list at redhat.com
>
>To subscribe or unsubscribe via the World Wide Web, visit
>	https://www.redhat.com/mailman/listinfo/rdo-list
>or, via email, send a message with subject or body 'help' to
>	rdo-list-request at redhat.com
>
>You can reach the person managing the list at
>	rdo-list-owner at redhat.com
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Rdo-list digest..."
>
>
>Today's Topics:
>
>   1. Re: RDO Bug triage: 15JAN2014; UTC 14:00 (Rich Bowen)
>   2. Re: New RDO page for LBaaS (Lars Kellogg-Stedman)
>   3. Re: Formatting tip for RDO wiki pages (P?draig Brady)
>   4. Enabling 'ovs_use_veth' for DHCP/L3 agents breaks Neutron on
>      recent versions of RHEL/CentOS (Steve Gordon)
>   5. First IRC RDO community meeting (Rich Bowen)
>   6. Re: First IRC RDO community meeting (Rich Bowen)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Mon, 13 Jan 2014 12:29:47 -0500
>From: Rich Bowen 
>To: rdo-list at redhat.com
>Subject: Re: [Rdo-list] RDO Bug triage: 15JAN2014; UTC 14:00
>Message-ID: <52D4228B.40509 at redhat.com>
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>
>On 01/13/2014 10:06 AM, Kashyap Chamarthy wrote:
>>>> Kashyap, can you please send an invitation. (if it is not in a
>>>>calendar it'll probably be missed)
>>> >
>>> >I'm afraid, as of now I don't think (maybe I'm wrong) there's a
>>>sensible
>>> >way to send calendar invitations to public list. For now, I
>> Oops, truncated sentence, I meant - For now, I hope mailing list invite
>> would do & folks who are interested to participate would just remember.
>>
>One possibility is to create the event in Google Calendar, and send an
>invite from there to the list. I can moderate it through from there.
>
>--Rich
>
>-- 
>Rich Bowen - rbowen at redhat.com
>OpenStack Community Liaison
>http://openstack.redhat.com/
>
>
>
>------------------------------
>
>Message: 2
>Date: Mon, 13 Jan 2014 13:07:03 -0500
>From: Lars Kellogg-Stedman 
>To: "Ryan O'Hara" 
>Cc: rdo-list at redhat.com
>Subject: Re: [Rdo-list] New RDO page for LBaaS
>Message-ID: <20140113180703.GA30987 at redhat.com>
>Content-Type: text/plain; charset="us-ascii"
>
>On Mon, Jan 13, 2014 at 09:03:30AM -0600, Ryan O'Hara wrote:
>> I've written a guide for deploying LBaaS with RDO Havana, which also
>> covers some simple tests. The guide can be found here:
>
>That looks like a really nice guide.  Thanks!
>
>-- 
>Lars Kellogg-Stedman  | larsks @ irc
>Cloud Engineering / OpenStack          | "   "  @ twitter
>
>-------------- next part --------------
>A non-text attachment was scrubbed...
>Name: not available
>Type: application/pgp-signature
>Size: 819 bytes
>Desc: not available
>URL: 
>tachment.bin>
>
>------------------------------
>
>Message: 3
>Date: Tue, 14 Jan 2014 00:14:26 +0000
>From: P?draig Brady 
>To: "Ryan O'Hara" 
>Cc: rdo-list at redhat.com
>Subject: Re: [Rdo-list] Formatting tip for RDO wiki pages
>Message-ID: <52D48162.1010008 at redhat.com>
>Content-Type: text/plain; charset=ISO-8859-1
>
>On 01/13/2014 03:55 PM, Ryan O'Hara wrote:
>> 
>> In the recent LBaaS wiki page I wrote, I need to show output from
>> various command-line clients. The problem I ran into is that the wiki
>> page will wrap anything enclosed in 
 tags, so I ended up with the
>> following solution:
>> 
>> 
>> ...
>> 

>> 
>> This will add a horizontal scrollbar to the bottom of the preformatted
>> text box, which is the best solution I could come up with for handling
>> wide blocks of text. I've tested this with Firefox, IE, and Chrome and
>> it seems to render correctly on each.
>
>Thanks for the attention to detail Ryan.
>
>Can the powers that be, set that as the default 
 style.
>
>Personally can never deal with wrapping and use the following
>in my .bashrc to leverage less' support of horizontal scrolling,
>as less is used as the default pager by many commands:
>
>  export LESS="-iRS"
>
>"S" is the pertinent option here.
>"R" enables less to display colors.
>"i" uses case insensitive search.
>
>cheers,
>P?draig.
>
>
>
>------------------------------
>
>Message: 4
>Date: Tue, 14 Jan 2014 09:04:56 -0500 (EST)
>From: Steve Gordon 
>To: rdo-list at redhat.com
>Subject: [Rdo-list] Enabling 'ovs_use_veth' for DHCP/L3 agents breaks
>	Neutron on recent versions of RHEL/CentOS
>Message-ID: <925877507.1847003.1389708296298.JavaMail.root at redhat.com>
>Content-Type: text/plain; charset=utf-8
>
>Hi all,
>
>I was asked to take a look at this bug for the openstack-manuals project
>- "Enabling 'ovs_use_veth' for DHCP/L3 agents breaks Neutron on recent
>versions of CentOS":
>
>    https://bugs.launchpad.net/openstack-manuals/+bug/1268806
>
>"After assisting someone with troubleshooting networking, I determined
>that setting 'ovs_use_veth = True' in dhcp_agent.ini and l3_agent.ini
>breaks Neutron (at least with GRE) on recent versions of CentOS...
>perhaps because the kernel seems to fully support namespaces. This issue
>probably also affects Scientific Linux. Can anyone confirm whether recent
>RHEL kernels fully support namespaces? I would like to clarify this step
>and similar steps in other sections for all distributions."
>
>Questions I have are:
>
>a) Is it likely/expected that enabling ovs_use_veth = True will cause
>issues when using a kernel that supports netns?
>
>b) Is there any downside at this point to setting ovs_use_veth = False?
>
>Thanks,
>
>Steve
>
>
>
>------------------------------
>
>Message: 5
>Date: Tue, 14 Jan 2014 10:06:49 -0500
>From: Rich Bowen 
>To: rdo-list at redhat.com
>Subject: [Rdo-list] First IRC RDO community meeting
>Message-ID: <52D55289.6050307 at redhat.com>
>Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
>
>Mike Burns and I have been meeting by phone for a few months to discuss
>various things around the RDO community. This call has grown, and this
>morning we moved it to IRC both to accommodate that growth and to make
>what we're working on a little more transparent to the community. We're
>going to do this regularly, 9am eastern time, on the #rdo channel on
>Freenode.
>
>The notes from this morning's chat are at
>http://meetbot.fedoraproject.org/rdo/2014-01-14/rdo_community_meeting.2014
>-01-14-14.02.html 
>... however, it appears that we didn't do the log bot commands
>correctly, so I'll try to post a followup with the notes a little more
>coherent. A full log is at
>http://meetbot.fedoraproject.org/rdo/2014-01-14/rdo_community_meeting.2014
>-01-14-14.02.log.html
>but I don't expect anybody wants to read through that.
>
>--Rich
>
>-- 
>Rich Bowen - rbowen at redhat.com
>OpenStack Community Liaison
>http://openstack.redhat.com/
>
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: 
>tachment.html>
>
>------------------------------
>
>Message: 6
>Date: Tue, 14 Jan 2014 10:35:06 -0500
>From: Rich Bowen 
>To: rdo-list at redhat.com
>Subject: Re: [Rdo-list] First IRC RDO community meeting
>Message-ID: <52D5592A.8040307 at redhat.com>
>Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
>
>
>On 01/14/2014 10:06 AM, Rich Bowen wrote:
>> Mike Burns and I have been meeting by phone for a few months to
>> discuss various things around the RDO community. This call has grown,
>> and this morning we moved it to IRC both to accommodate that growth
>> and to make what we're working on a little more transparent to the
>> community. We're going to do this regularly, 9am eastern time, on the
>> #rdo channel on Freenode.
>>
>> The notes from this morning's chat are at
>> 
>>http://meetbot.fedoraproject.org/rdo/2014-01-14/rdo_community_meeting.201
>>4-01-14-14.02.html
>> ... however, it appears that we didn't do the log bot commands
>> correctly, so I'll try to post a followup with the notes a little more
>> coherent. A full log is at
>> 
>>http://meetbot.fedoraproject.org/rdo/2014-01-14/rdo_community_meeting.201
>>4-01-14-14.02.log.html
>> but I don't expect anybody wants to read through that.
>
>Ok, here's the more coherent meeting summary. Meanwhile, we'll figure
>out the log bot before the next time.
>
>*#topic RDO Community meeting**
>**Ether pad at: 
>https://etherpad.openstack.org/p/rdo_community_manager_sync*
>
>Test Day:
>
>M2 release is scheduled for January 23rd. Although an initial date of
>the 30th was suggested for the next test day, we want to be sure that we
>have packages for all of the relevant platforms, and that QA has had a
>chance to test them so that folks don't all run into the same issues.
>February 4th and 5th have been suggested for possible test days. (Dates
>are NOT final.)
>
>Action: Rich will follow up on rdo-list with email about proposed dates
>to see if this works for everyone.
>Action: Rich will also write up a blog post for RedHatStack for wider
>publicity.
>Action: Flavio said he'd try to get Marconi packaged up for the test day.
>
>Hangouts:
>
>I'd like to start doing the hangouts again. We had a good start, and
>then I dropped it. So I need to start bugging people about doing some
>more. If you'd like to volunteer for a 30-60 minute presentation on what
>you're working on, please speak up.
>
>February Newsletter:
>
>I'm starting to gather items to write about in the February RDO
>newsletter.
>
>https://etherpad.openstack.org/p/rdo_newsletter_2014_02
>
>We send this out to about 2000 people every month. If you're not on
>there, you can join at
>http://www.redhat.com/mailman/listinfo/rdo-newsletter  If you have
>anything you'd like to have mentioned in the newsletter, please add it
>to that etherpad. If you'd like to write something for the newsletter,
>please contact rbowen at redhat.com.
>
>Current topics include:
>
>     IRC meetings
>     FOSDEM
>     Infrastructure.Next
>     SCALE
>     CentOS Cloud SIG
>     RDO bug triage meeting
>
>FOSDEM
>
>FOSDEM is February 1-2 in Brussels. Rich is planning to do (audio)
>interviews (10 minutes roughly) with anybody and everybody that's
>involved in RDO. These might be used on the RDO site, or on Joe
>Brockmeier's new 'Cloud Forecast' podcast. See
>http://drbacchus.com/flavio-percoco-on-openstack-marconi for an example
>of the ones that I did at OpenStack Summit. If you'd like to talk to the
>world about what you're doing on OpenStack, and you'll be at FOSDEM,
>just come talk to me. I'll have my recorder in my pocket.
>
>If you'd like to talk about what you're doing on OpenStack and you won't
>be at FOSDEM, email rbowen at redhat.com and we'll set up a phone/skype
>thing.
>
>The schedule for the Virtualization/IaaS devroom at FOSDEM has been
>posted. https://fosdem.org/2014/schedule/track/virtualisation_and_iaas/
>
>After FOSDEM, there's a second event called Infrastructure.next. I
>posted to rdo-list about it last week:
>http://community.redhat.com/blog/2013/12/announcing-infrastructure-next/
>
>If you'd like to speak at infrastructure.next contact jzb at redhat.com
>
>Bitergia Stats
>
>http://openstack.redhat.com/stats/
>
>Not much to say here, other than, we have cool stats, done by the same
>folks that do Stackalytics - Bitergia.  They're interesting and
>informative, and if you haven't looked yet, have a look. They're pretty
>awesome, particularly if you're a stats geek like me.
>
>CentOS Cloud SIG
>
>If you're not on the centos-devel mailing list, it would be a good thing
>to join if you're interested in RDO on CentOS.
>http://lists.centos.org/mailman/listinfo/centos-devel
>
>mburned, and many other people, have started "Let's have a Cloud SIG"
>thread. There's an organizational kickoff meeting for the CentOS Cloud
>SIG on a Google hangout on 23-Jan.
>
>The consensus is, I think, coming around to let's have one unified cloud
>sig with variants for each cloud platform (openstack, eucalyptus,
>opennebula, cloudstack, and so on) There's clearly a lot of energy, and
>people wanting to see this happen. So jump in and speak up.
>
>Bug triage meeting
>
>A bug triage meeting has been organized for the 3rd Wednesday of each
>month here on IRC. First meeting set for tomorrow 15-Jan at the same
>time as this meeting.
>
>We'll review the current open issues and bugs during this meeting. We'll
>also re-evaluate the recurrence of this meeting if we find that it's too
>much or not enough.
>
>https://etherpad.openstack.org/p/RDO-BugTriage
>
>Anyone interested in participating can just show up.
>
>Open Forum Questions
>
>(See list in etherpad)
>
>People have been incredibly responsive when I've bugged them about
>answering questions. There are, however, a handful of questions -
>probably the first 4 in the list - that have been open a long time and
>could use some love. I also need to figure out how to filter questions
>that are answered, but the answer hasn't been accepted. I don't know how
>many folks actually bother to accept/agree the answer - it's not very
>many. So there's actually a lot of questions where someone has posted an
>answer, but it's not really an answer, it's more of a comment.
>
>Proposal: Add a "solution-proposed" flag or similar. But we need people
>to have enough karma to convert comments to answers and vice versa, and
>to add tags.
>
>https://ask.openstack.org/en/questions/scope:unanswered/sort:answers-asc/p
>age:1/query:rdo/ 
>is the unanswered RDO list. 17 this morning. We've been holding at
>around 9 for the last few weeks.
>
>I also need to work some with the API to get some reports of things that
>have been unanswered and/or without activity for a long time.
>
>
>
>-- 
>Rich Bowen - rbowen at redhat.com
>OpenStack Community Liaison
>http://openstack.redhat.com/
>
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: 
>tachment.html>
>
>------------------------------
>
>_______________________________________________
>Rdo-list mailing list
>Rdo-list at redhat.com
>https://www.redhat.com/mailman/listinfo/rdo-list
>
>
>End of Rdo-list Digest, Vol 10, Issue 17
>****************************************




From rbowen at redhat.com  Tue Jan 14 16:26:31 2014
From: rbowen at redhat.com (Rich Bowen)
Date: Tue, 14 Jan 2014 11:26:31 -0500
Subject: [Rdo-list] Formatting tip for RDO wiki pages
In-Reply-To: <52D48162.1010008@redhat.com>
References: <20140113155553.GD24385@redhat.com> <52D48162.1010008@redhat.com>
Message-ID: <52D56537.6060001@redhat.com>

I'll see if I can figure out how to do that.


On 01/13/2014 07:14 PM, P?draig Brady wrote:
> On 01/13/2014 03:55 PM, Ryan O'Hara wrote:
>> In the recent LBaaS wiki page I wrote, I need to show output from
>> various command-line clients. The problem I ran into is that the wiki
>> page will wrap anything enclosed in 
 tags, so I ended up with the
>> following solution:
>>
>> 
>> ...
>> 

>>
>> This will add a horizontal scrollbar to the bottom of the preformatted
>> text box, which is the best solution I could come up with for handling
>> wide blocks of text. I've tested this with Firefox, IE, and Chrome and
>> it seems to render correctly on each.
> Thanks for the attention to detail Ryan.
>
> Can the powers that be, set that as the default 
 style.
>
> Personally can never deal with wrapping and use the following
> in my .bashrc to leverage less' support of horizontal scrolling,
> as less is used as the default pager by many commands:
>
>    export LESS="-iRS"
>
> "S" is the pertinent option here.
> "R" enables less to display colors.
> "i" uses case insensitive search.
>
> cheers,
> P?draig.
>

-- 
Rich Bowen - rbowen at redhat.com
OpenStack Community Liaison
http://openstack.redhat.com/



From rbowen at redhat.com  Wed Jan 15 14:17:58 2014
From: rbowen at redhat.com (Rich Bowen)
Date: Wed, 15 Jan 2014 09:17:58 -0500
Subject: [Rdo-list] OpenStack Summit call for papers closes Feb 14
Message-ID: <52D69896.2000605@redhat.com>

In case you missed it, the OpenStack Summit call for papers is closes on 
February 14th, so you have about a month to get your submissions in.

http://www.openstack.org/summit/openstack-summit-atlanta-2014/call-for-speakers/#! 


The conference will be in Atlanta, May 12-16.

-- 
Rich Bowen - rbowen at redhat.com
OpenStack Community Liaison
http://openstack.redhat.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From kchamart at redhat.com  Wed Jan 15 16:26:31 2014
From: kchamart at redhat.com (Kashyap Chamarthy)
Date: Wed, 15 Jan 2014 17:26:31 +0100
Subject: [Rdo-list] Summary/Minutes from today's RDO bug triage [15-JAN-2014]
Message-ID: <52D6B6B7.6040203@redhat.com>

Thanks all, for your participation.

Synopsis: 23 bugs out of 61 triaged (thanks larsks for looking up the
number!)

Notes from etherpad
-------------------

============
 - Many PackStack issues - beginning to go stale, not sure
   how much  effort Packstack maintainers are will to put
   given Foreman/Astopher (in near future) are  being
   driven as future installers
    - But note that packstack is still maintained and bugs that
      prevent successful installs should be addressed
    - Foreman is not currently available for Fedora20
    - Fedora OpenStack supports arches other than x86_64 just supported
      by RDO but theforeman.org only seems to have x86_64 packages.
      So we may put an exclusive arch in the RDO
      openstack-foreman package.

 - Need rotating volunteers to keep notes/chair the meeting.

 - There's a rough consensus of triaging twice/month cadence.
============


============
#rdo Meeting
============


Meeting started by kashyap at 14:00:08 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/rdo/2014-01-15/rdobugtriage.2014-01-15-14.00.log.html
.



Meeting summary
---------------
* LINK: https://etherpad.openstack.org/p/RDO-BugTriage   (kashyap,
  14:00:43)
* LINK: List of un-triaged bugs (NEW state) -- http://goo.gl/NqW2LN
  (kashyap, 14:01:10)
* http://openstack.redhat.com/DeveloperTips  (kashyap, 14:17:57)
* bug 1052311 assigned to jruzicka and marked triaged  (mburned,
  14:23:06)
* LINK: https://review.openstack.org/#/c/27251/   (larsks, 14:25:56)
* bug 958411 has patch merged in https://review.openstack.org/#/c/27251/
  (mburned, 14:30:36)
* asked reported to try with latest packages  (mburned, 14:30:47)
* LINK:
  http://repos.fedorapeople.org/repos/openstack/openstack-havana/epel-6/
  (mburned, 14:33:59)
* LINK: https://bugzilla.redhat.com/show_bug.cgi?id=995570 is an RFE
  from pixelb  (kashyap, 14:59:20)
* LINK:

http://jenkins.rhev.lab.eng.brq.redhat.com:8080/view/RDO-Havana/job/packstack-rdo-havana-neutron-rhel-production/121/consoleFull
  (weshay, 15:16:47)
* LINK:

https://prod-rdojenkins.rhcloud.com/view/RDO-Havana/job/packstack-rdo-havana-neutron-rhel-production/111/consoleText
  (kashyap, 15:19:47)
* LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1014627 is also an
  upstream bug.  I'm going to reuse your verbage...  (larsks, 15:54:29)
* 23 out of 61 bugs addressed  (kashyap, 16:07:54)
* IDEA: We can have a rotating volunteers to keep notes/run the zodbot
  commands?  (kashyap, 16:08:24)

Meeting ended at 16:12:23 UTC.




Action Items
------------





Action Items, by person
-----------------------
* **UNASSIGNED**
  * (none)




People Present (lines said)
---------------------------
* kashyap (164)
* larsks (113)
* mburned (55)
* weshay (35)
* russellb (11)
* xqueralt (7)
* jruzicka (6)
* ndipanov (5)
* zodbot (5)
* pixelb (5)
* bcrochet (1)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot



-- 
/kashyap



From lars at redhat.com  Wed Jan 15 17:18:57 2014
From: lars at redhat.com (Lars Kellogg-Stedman)
Date: Wed, 15 Jan 2014 12:18:57 -0500
Subject: [Rdo-list] Summary/Minutes from today's RDO bug triage
 [15-JAN-2014]
In-Reply-To: <52D6B6B7.6040203@redhat.com>
References: <52D6B6B7.6040203@redhat.com>
Message-ID: <20140115171857.GB28482@redhat.com>

On Wed, Jan 15, 2014 at 05:26:31PM +0100, Kashyap Chamarthy wrote:
> Synopsis: 23 bugs out of 61 triaged (thanks larsks for looking up the
> number!)

Well, it was hard work, but somebody had to do it. ;)

-- 
Lars Kellogg-Stedman  | larsks @ irc
Cloud Engineering / OpenStack          | "   "  @ twitter

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 

From mrunge at redhat.com  Thu Jan 16 10:43:40 2014
From: mrunge at redhat.com (Matthias Runge)
Date: Thu, 16 Jan 2014 11:43:40 +0100
Subject: [Rdo-list] Neutron fails to connect to AMQP Server on Fedora 20
 ( at startup) 3
In-Reply-To: 
References: ,
	<52D39B60.1030601@redhat.com>
	
Message-ID: <52D7B7DC.3020706@redhat.com>

On 01/13/2014 09:53 AM, Boris Derzhavets wrote:
> Original
> 
> /etc/neutron/neutron.conf  already has 
> 
> # signing_dir = $state_path/keystone-signing
> auth_uri=http://192.168.1.145:5000/
> 
> and I am still experiencing this problem. It looks like repeating 
> 

>> >
>> I think this is due
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1050842
>>
>> (with workaround)

Yes, the workaround in the listed bug said:

remove
signing_dir = $state_path/keystone-signing

from /usr/share/neutron/neutron-dist.conf

and restart neutron-server.

Matthias



From bderzhavets at hotmail.com  Thu Jan 16 12:21:12 2014
From: bderzhavets at hotmail.com (Boris Derzhavets)
Date: Thu, 16 Jan 2014 07:21:12 -0500
Subject: [Rdo-list] Neutron fails to connect to AMQP Server on Fedora 20
 ( at startup) 4
In-Reply-To: <52D7B7DC.3020706@redhat.com>
References: ,
	<52D39B60.1030601@redhat.com>
	,
	<52D7B7DC.3020706@redhat.com>
Message-ID: 

> Yes, the workaround in the listed bug said:
 
> remove
> signing_dir = $state_path/keystone-signing
 
> from /usr/share/neutron/neutron-dist.conf 
> and restart neutron-server.

I've tried remove this line from /usr/share/neutron/neutron-dist.conf ,
commented  out `service qpidd restart` in /etc/rc.d/rc.local and rebooted.

Still no luck.

Thanks.
Boris.



 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From pbrady at redhat.com  Thu Jan 16 12:58:27 2014
From: pbrady at redhat.com (=?ISO-8859-1?Q?P=E1draig_Brady?=)
Date: Thu, 16 Jan 2014 12:58:27 +0000
Subject: [Rdo-list] Enabling 'ovs_use_veth' for DHCP/L3 agents breaks
 Neutron on recent versions of RHEL/CentOS
In-Reply-To: <925877507.1847003.1389708296298.JavaMail.root@redhat.com>
References: <925877507.1847003.1389708296298.JavaMail.root@redhat.com>
Message-ID: <52D7D773.3050001@redhat.com>

On 01/14/2014 02:04 PM, Steve Gordon wrote:
> Hi all,
> 
> I was asked to take a look at this bug for the openstack-manuals project - "Enabling 'ovs_use_veth' for DHCP/L3 agents breaks Neutron on recent versions of CentOS":
> 
>     https://bugs.launchpad.net/openstack-manuals/+bug/1268806
> 
> "After assisting someone with troubleshooting networking, I determined that setting 'ovs_use_veth = True' in dhcp_agent.ini and l3_agent.ini breaks Neutron (at least with GRE) on recent versions of CentOS... perhaps because the kernel seems to fully support namespaces. This issue probably also affects Scientific Linux. Can anyone confirm whether recent RHEL kernels fully support namespaces? I would like to clarify this step and similar steps in other sections for all distributions."

As I understand it, the 6.5 kernels (or the RDO provided 6.4 kernel updates),
provide enough namespace support as required by neutron.
Due to kernel ABI issues there isn't full support, like for example
supporting the `ip netns` command.

> Questions I have are:
> 
> a) Is it likely/expected that enabling ovs_use_veth = True will cause issues when using a kernel that supports netns?
> 
> b) Is there any downside at this point to setting ovs_use_veth = False?




From tgraf at redhat.com  Thu Jan 16 14:44:42 2014
From: tgraf at redhat.com (Thomas Graf)
Date: Thu, 16 Jan 2014 15:44:42 +0100
Subject: [Rdo-list] Enabling 'ovs_use_veth' for DHCP/L3 agents breaks
 Neutron on recent versions of RHEL/CentOS
In-Reply-To: <52D7D773.3050001@redhat.com>
References: <925877507.1847003.1389708296298.JavaMail.root@redhat.com>
	<52D7D773.3050001@redhat.com>
Message-ID: <52D7F05A.2080700@redhat.com>

On 01/16/2014 01:58 PM, P?draig Brady wrote:
> On 01/14/2014 02:04 PM, Steve Gordon wrote:
>> Hi all,
>>
>> I was asked to take a look at this bug for the openstack-manuals project - "Enabling 'ovs_use_veth' for DHCP/L3 agents breaks Neutron on recent versions of CentOS":
>>
>>      https://bugs.launchpad.net/openstack-manuals/+bug/1268806
>>
>> "After assisting someone with troubleshooting networking, I determined that setting 'ovs_use_veth = True' in dhcp_agent.ini and l3_agent.ini breaks Neutron (at least with GRE) on recent versions of CentOS... perhaps because the kernel seems to fully support namespaces. This issue probably also affects Scientific Linux. Can anyone confirm whether recent RHEL kernels fully support namespaces? I would like to clarify this step and similar steps in other sections for all distributions."
>
> As I understand it, the 6.5 kernels (or the RDO provided 6.4 kernel updates),
> provide enough namespace support as required by neutron.

Correct

> Due to kernel ABI issues there isn't full support, like for example
> supporting the `ip netns` command.

Correct

>
>> Questions I have are:
>>
>> a) Is it likely/expected that enabling ovs_use_veth = True will cause issues when using a kernel that supports netns?

Aside from kernel support you will also require a recent enough
iproute2 package to support specifying the netns upon device creation.

The log should report the error in response to the veth creation.
Assuming it is the failing veth creation that causes Neutron to break.

>> b) Is there any downside at this point to setting ovs_use_veth = False?

I'll leave this for the Neutron guys.



From pbrady at redhat.com  Thu Jan 16 16:35:03 2014
From: pbrady at redhat.com (=?ISO-8859-1?Q?P=E1draig_Brady?=)
Date: Thu, 16 Jan 2014 16:35:03 +0000
Subject: [Rdo-list] [package announce] openstack-packstack update
Message-ID: <52D80A37.9080007@redhat.com>

Havana and Icehouse RDO packstack has been updated as follows.

openstack-packstack-2013.2.1-0.29.dev956
- Fix qpid SSL installation errors (rhbz#1052163, rhbz#1048705)
- Open Keystone port for ALL (rhbz#1041560)
- Move to the upstream puppet-vswitch module
- Add missing example options (rhbz#971745)
- Install php only with nagios (rhbz#1039660)
- Change puppet-qpid module to upstream (rhbz#1029576)
- Update puppet-neutron to stable/havana which contains fixes for Puppet 3.4+ (lp#1267488)
- Updat puppet-swift to stable/havana (rhbz#1039981)
- Don't set libvirt_vif_driver nova config, deprecated by Havana and disallowed by Icehose (rhbz#1048315)



From pbrady at redhat.com  Thu Jan 16 16:43:43 2014
From: pbrady at redhat.com (=?ISO-8859-1?Q?P=E1draig_Brady?=)
Date: Thu, 16 Jan 2014 16:43:43 +0000
Subject: [Rdo-list] [package announce] openstack clients update
Message-ID: <52D80C3F.9020501@redhat.com>

Havana and Icehouse RDO client packages have been updated as follows:

  python-cinderclient-1.0.7-2
    Add search_opts into the method list() for VolumeTypeManager (rhbz#1048326)
  python-openstackclient-0.3.0-1
    Update to upstream 0.3.0
    New dependencies: python-six, python-requests
    Restore compatibility with old EPEL python-keyring
  python-heatclient-0.2.6-2
    Add support for resource_types

In addition there have been these upstream rebases in the Icehouse repositories:

  python-keystoneclient-0.4.1 -> 0.4.2
  python-neutronclient-2.3.1 -> 2.3.3



From pbrady at redhat.com  Thu Jan 16 16:46:53 2014
From: pbrady at redhat.com (=?ISO-8859-1?Q?P=E1draig_Brady?=)
Date: Thu, 16 Jan 2014 16:46:53 +0000
Subject: [Rdo-list] [package announce] New package: openstack-heat-templates
Message-ID: <52D80CFD.3020709@redhat.com>

Havana and Icehouse RDO repositories were updated with this new package

openstack-heat-templates
  Heat example templates and image building elements



From bderzhavets at hotmail.com  Thu Jan 16 19:48:31 2014
From: bderzhavets at hotmail.com (Boris Derzhavets)
Date: Thu, 16 Jan 2014 14:48:31 -0500
Subject: [Rdo-list] Attempt to reproduce Getting Started with Multi-Node
 OpenStack RDO Havana + Gluster Backend + Neutron VLAN by Andrew Lau on F20
 (2)
In-Reply-To: <52BD4D8C.1080805@redhat.com>
References: 
	<52B8C15A.9080806@redhat.com>,
	,
	
	,
	<52BD4D8C.1080805@redhat.com>
Message-ID: 

Trying to reproduce :
 http://kashyapc.fedorapeople.org/virt/openstack/Two-node-Havana-setup.txt   
 
I stopped at following point :

  $ systemctl start openvswitch.service
  $ systemctl enable openvswitch.service

  $ systemctl enable neutron-ovs-cleanup.service

  $ ovs-vsctl add-br br-int

  $ cat < /etc/sysconfig/network-scripts/ifcfg-eth1
  DEVICE=eth1
  BOOTPROTO=static
  NM_CONTROLLED=no
  ONBOOT=yes
  TYPE=Ethernet
  EOF    

  $ cat < /etc/sysconfig/network-scripts/ifcfg-br-ex
  DEVICE=br-ex
  BOOTPROTO=static
  ONBOOT=yes
  IPADDR=192.169.142.140
  NETMASK=255.255.255.0
  GATEWAY=192.168.122.1
  EOF

  $ ovs-vsctl add-br br-ex
  $ ovs-vsctl add-port br-ex eth0
  $ 
  
  $ systemctl stop NetworkManager
  $ systemctl disable NetworkManager
  $ systemctl restart network
  $ systemct status network   # must be running

  > here

  Action (itself) :-
   
  $ cat < /etc/sysconfig/network-scripts/ifcfg-eth1
  DEVICE=eth1
  BOOTPROTO=static
  NM_CONTROLLED=no
  ONBOOT=yes
  TYPE=Ethernet
  EOF    

  won't create second interface on VM. Something else supposed to be done.

  Otherwise, eth1 won't appear in ifconfig report as well as it
  won't appear in routing table.

Attempt `ifup eth1` reports error : device is not known to system .

[root at ip-192-169-142-140 ~]# ifconfig

br-eth1: flags=67  mtu 1500
        inet6 fe80::3497:35ff:fed5:e59f  prefixlen 64  scopeid 0x20
        ether 26:b7:3f:05:ca:42  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 8  bytes 648 (648.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

br-ex: flags=67  mtu 1500
        inet 192.169.142.140  netmask 255.255.255.0  broadcast 192.169.142.255
        inet6 fe80::a8bb:c8ff:fe10:ba7b  prefixlen 64  scopeid 0x20
        ether 46:5a:28:79:5d:4e  txqueuelen 0  (Ethernet)
        RX packets 9  bytes 730 (730.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 12  bytes 816 (816.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

br-int: flags=67  mtu 1500
        inet6 fe80::c53:4cff:fef3:8a84  prefixlen 64  scopeid 0x20
        ether 36:44:69:dc:21:44  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 8  bytes 648 (648.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4163  mtu 1500
        inet6 fe80::5054:ff:fe32:e91e  prefixlen 64  scopeid 0x20
        ether 52:54:00:32:e9:1e  txqueuelen 1000  (Ethernet)
        RX packets 45  bytes 2602 (2.5 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 8  bytes 648 (648.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10
        loop  txqueuelen 0  (Local Loopback)
        RX packets 18  bytes 940 (940.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 18  bytes 940 (940.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

virbr0: flags=4099  mtu 1500
        inet 192.168.122.1  netmask 255.255.255.0  broadcast 192.168.122.255
        ether 3e:cb:01:7a:51:ff  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[root at ip-192-169-142-140 ~]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1005   0        0 br-ex
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0
192.169.142.0   0.0.0.0         255.255.255.0   U     0      0        0 br-ex


[root at ip-192-169-142-140 ~]# ifup eth1
ERROR    : [/etc/sysconfig/network-scripts/ifup-eth] Device eth1 does not seem 
to be present, delaying initialization.

Boris
> Date: Fri, 27 Dec 2013 10:51:08 +0100
> From: kchamart at redhat.com
> To: bderzhavets at hotmail.com
> CC: andrew at andrewklau.com; rdo-list at redhat.com
> Subject: Re: [Rdo-list] Attempt to reproduce Getting Started with Multi-Node OpenStack RDO Havana + Gluster Backend + Neutron VLAN by Andrew Lau on F19
> 
> [. . .]
> 
> > 
> > View also http://kashyapc.wordpress.com/tag/fedora/
> > Set up a bit different from yours , but with same idea Controller + Compute,  is done
> > manually not via packstack with f20 core ( no Ethernet interfaces renaming just ifcfg-eth0 and etc )
> 
> 
> Here are more updated configurations:
> 
>   http://kashyapc.fedorapeople.org/virt/openstack/neutron-configs-GRE-OVS-two-node.txt
> 
> 
> That's the manual configuration details (not *fully* polished, but should
> give you an idea.
> 
>   http://kashyapc.fedorapeople.org/virt/openstack/Two-node-Havana-setup.txt
> 
> 
> And, that's the set-up:
> 
>   - Controller node: Nova, Keystone, Cinder, Glance, Neutron (using Open
>     vSwitch plugin and GRE tunneling).
> 
>   - Compute node: Nova (nova-compute), Neutron (openvswitch-agent)
> 
> 
> Hope that helps.
> 
> -- 
> /kashyap
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From bderzhavets at hotmail.com  Thu Jan 16 20:29:43 2014
From: bderzhavets at hotmail.com (Boris Derzhavets)
Date: Thu, 16 Jan 2014 15:29:43 -0500
Subject: [Rdo-list] Attempt to reproduce Getting Started with Multi-Node
 OpenStack RDO Havana + Gluster Backend + Neutron VLAN by Andrew Lau on F20
 (3)
In-Reply-To: <52BD4D8C.1080805@redhat.com>
References: 
	<52B8C15A.9080806@redhat.com>,
	,
	
	,
	<52BD4D8C.1080805@redhat.com>
Message-ID: 

I believe instruction is missing "virsh attach-interface" :- 

[root at openstack2 ~]# virsh list --all

 Id    Name                           State
----------------------------------------------------
 -     fedora20                       shut off
 -     instance-00000007              shut off

[root at openstack2 ~]# virsh attach-interface --domain fedora20 --type bridge \
> --source virbr0 --model virtio --mac 52:54:00:3b:65:6f --config

Interface attached successfully


Then inside VM ( fedora20) :-

[root at ip-192-169-142-140 ~]# ifconfig
br-eth1: flags=67  mtu 1500
        inet6 fe80::c49f:64ff:fe07:d84e  prefixlen 64  scopeid 0x20
        ether 26:b7:3f:05:ca:42  txqueuelen 0  (Ethernet)
        RX packets 9  bytes 730 (730.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 8  bytes 648 (648.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

br-ex: flags=67  mtu 1500
        inet 192.169.142.140  netmask 255.255.255.0  broadcast 192.169.142.255
        inet6 fe80::a0dd:efff:fe38:1b1b  prefixlen 64  scopeid 0x20
        ether 46:5a:28:79:5d:4e  txqueuelen 0  (Ethernet)
        RX packets 9  bytes 730 (730.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 12  bytes 816 (816.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

br-int: flags=67  mtu 1500
        inet6 fe80::b8de:ccff:fec2:5b09  prefixlen 64  scopeid 0x20
        ether 36:44:69:dc:21:44  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 8  bytes 648 (648.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4163  mtu 1500
        inet6 fe80::5054:ff:fe32:e91e  prefixlen 64  scopeid 0x20
        ether 52:54:00:32:e9:1e  txqueuelen 1000  (Ethernet)
        RX packets 43  bytes 2498 (2.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 10  bytes 760 (760.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth1: flags=4163  mtu 1500
        inet6 fe80::5054:ff:fe3b:656f  prefixlen 64  scopeid 0x20
        ether 52:54:00:3b:65:6f  txqueuelen 1000  (Ethernet)
        RX packets 43  bytes 2498 (2.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 9  bytes 718 (718.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10
        loop  txqueuelen 0  (Local Loopback)
        RX packets 22  bytes 1140 (1.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 22  bytes 1140 (1.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

virbr0: flags=4099  mtu 1500
        inet 192.168.122.1  netmask 255.255.255.0  broadcast 192.168.122.255
        ether d6:f9:2a:47:81:6a  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[root at ip-192-169-142-140 ~]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1003   0        0 eth1
169.254.0.0     0.0.0.0         255.255.0.0     U     1006   0        0 br-ex
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0
192.169.142.0   0.0.0.0         255.255.255.0   U     0      0        0 br-ex

Again routings tables don't match.

Boris.

 


> Date: Fri, 27 Dec 2013 10:51:08 +0100
> From: kchamart at redhat.com
> To: bderzhavets at hotmail.com
> CC: andrew at andrewklau.com; rdo-list at redhat.com
> Subject: Re: [Rdo-list] Attempt to reproduce Getting Started with Multi-Node OpenStack RDO Havana + Gluster Backend + Neutron VLAN by Andrew Lau on F19
> 
> [. . .]
> 
> > 
> > View also http://kashyapc.wordpress.com/tag/fedora/
> > Set up a bit different from yours , but with same idea Controller + Compute,  is done
> > manually not via packstack with f20 core ( no Ethernet interfaces renaming just ifcfg-eth0 and etc )
> 
> 
> Here are more updated configurations:
> 
>   http://kashyapc.fedorapeople.org/virt/openstack/neutron-configs-GRE-OVS-two-node.txt
> 
> 
> That's the manual configuration details (not *fully* polished, but should
> give you an idea.
> 
>   http://kashyapc.fedorapeople.org/virt/openstack/Two-node-Havana-setup.txt
> 
> 
> And, that's the set-up:
> 
>   - Controller node: Nova, Keystone, Cinder, Glance, Neutron (using Open
>     vSwitch plugin and GRE tunneling).
> 
>   - Compute node: Nova (nova-compute), Neutron (openvswitch-agent)
> 
> 
> Hope that helps.
> 
> -- 
> /kashyap
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From whayutin at redhat.com  Thu Jan 16 21:47:42 2014
From: whayutin at redhat.com (whayutin)
Date: Thu, 16 Jan 2014 16:47:42 -0500
Subject: [Rdo-list] fyi.. f20  rpm/selinux issue
Message-ID: <1389908862.2810.12.camel@localhost.localdomain>

F20 w/ the latest updates has rpm scriplet errors

The following will resolve the issue.
setenforce 0; yum --enablerepo=updates-testing update selinux-policy ;
setenforce 1

Thanks!



From whayutin at redhat.com  Thu Jan 16 21:56:12 2014
From: whayutin at redhat.com (whayutin)
Date: Thu, 16 Jan 2014 16:56:12 -0500
Subject: [Rdo-list] fyi.. f20  rpm/selinux issue
In-Reply-To: <1389908862.2810.12.camel@localhost.localdomain>
References: <1389908862.2810.12.camel@localhost.localdomain>
Message-ID: <1389909372.2810.13.camel@localhost.localdomain>

On Thu, 2014-01-16 at 16:47 -0500, whayutin wrote:
> F20 w/ the latest updates has rpm scriplet errors
> 
> The following will resolve the issue.
> setenforce 0; yum --enablerepo=updates-testing update selinux-policy ;
> setenforce 1
> 
> Thanks!
> 
bz# https://bugzilla.redhat.com/show_bug.cgi?id=1054350

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




From kchamart at redhat.com  Fri Jan 17 15:00:12 2014
From: kchamart at redhat.com (Kashyap Chamarthy)
Date: Fri, 17 Jan 2014 16:00:12 +0100
Subject: [Rdo-list] Attempt to reproduce Getting Started with Multi-Node
 OpenStack RDO Havana + Gluster Backend + Neutron VLAN by Andrew Lau on F20
 (2)
In-Reply-To: 
References: 
	<52B8C15A.9080806@redhat.com>,
	,
	
	,
	<52BD4D8C.1080805@redhat.com>
	
Message-ID: <52D9457C.1080504@redhat.com>

On 01/16/2014 08:48 PM, Boris Derzhavets wrote:
> Trying to reproduce :
>  http://kashyapc.fedorapeople.org/virt/openstack/Two-node-Havana-setup.txt   

Please note: this guide needs some more editing, it's more handy if one
is at-least moderately aware what's going under the hood and can
diagnose any network/routing problems.

Also I was experimenting w/ Neutron/GRE when I wrote the above - which
doesn't require two interfaces.


-- 
/kashyap



From mburns at redhat.com  Fri Jan 17 17:59:44 2014
From: mburns at redhat.com (Mike Burns)
Date: Fri, 17 Jan 2014 12:59:44 -0500
Subject: [Rdo-list] CentOS 6.5 Guest image file available now
Message-ID: <52D96F90.6060207@redhat.com>

Thanks to Joey Boggs for putting this together.

A prebuilt guest-image for CentOS 6.5 has been posted to the RDO yum 
repository along with the kickstart used to generate it. [1]  This was 
done in response to the conversation on IRC earlier.

The eventual plan would be to have this image owned and generated by the 
CentOS community, perhaps as part of the Cloud SIG.  This is just a 
stopgap measure until the SIG is up and running.

Let us know if you find any issues with it.

Thanks

Mike

[1] http://repos.fedorapeople.org/repos/openstack/guest-images/



From mail-lists at karan.org  Fri Jan 17 22:20:36 2014
From: mail-lists at karan.org (Karanbir Singh)
Date: Fri, 17 Jan 2014 22:20:36 +0000
Subject: [Rdo-list] CentOS 6.5 Guest image file available now
In-Reply-To: <52D96F90.6060207@redhat.com>
References: <52D96F90.6060207@redhat.com>
Message-ID: <52D9ACB4.50604@karan.org>

hi Guys,

Worth noting that we are going to be pushing OpenStack specific images
in a few days as well from the centos.org side; These are also the
images we will work with vendors to upstream into various public
openstack offerings.

One big difference is that we push an etc/cloud snippet to disable
cloud-user and enable root logins ( without passwords ).

These images ( for c5/c6 on 32bit/64bit ) are due to be pushed on the
22nd Jan, and will go via the regular distribution channels.


- KB


On 01/17/2014 05:59 PM, Mike Burns wrote:
> Thanks to Joey Boggs for putting this together.
> 
> A prebuilt guest-image for CentOS 6.5 has been posted to the RDO yum
> repository along with the kickstart used to generate it. [1]  This was
> done in response to the conversation on IRC earlier.
> 
> The eventual plan would be to have this image owned and generated by the
> CentOS community, perhaps as part of the Cloud SIG.  This is just a
> stopgap measure until the SIG is up and running.
> 
> Let us know if you find any issues with it.
> 
> Thanks
> 
> Mike
> 
> [1] http://repos.fedorapeople.org/repos/openstack/guest-images/
> 



-- 
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc



From mail-lists at karan.org  Fri Jan 17 22:23:02 2014
From: mail-lists at karan.org (Karanbir Singh)
Date: Fri, 17 Jan 2014 22:23:02 +0000
Subject: [Rdo-list] CentOS 6.5 Guest image file available now
In-Reply-To: <52D9ACB4.50604@karan.org>
References: <52D96F90.6060207@redhat.com> <52D9ACB4.50604@karan.org>
Message-ID: <52D9AD46.7000907@karan.org>

On 01/17/2014 10:20 PM, Karanbir Singh wrote:
> hi Guys,
> 
> Worth noting that we are going to be pushing OpenStack specific images
> in a few days as well from the centos.org side; These are also the
> images we will work with vendors to upstream into various public
> openstack offerings.
> 
> One big difference is that we push an etc/cloud snippet to disable
> cloud-user and enable root logins ( without passwords ).
> 
> These images ( for c5/c6 on 32bit/64bit ) are due to be pushed on the
> 22nd Jan, and will go via the regular distribution channels.

and I also noticed there is no growroot suport in this image, is that by
design ?


-- 
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc



From pmyers at redhat.com  Fri Jan 17 22:32:24 2014
From: pmyers at redhat.com (Perry Myers)
Date: Fri, 17 Jan 2014 17:32:24 -0500
Subject: [Rdo-list] CentOS 6.5 Guest image file available now
In-Reply-To: <52D9ACB4.50604@karan.org>
References: <52D96F90.6060207@redhat.com> <52D9ACB4.50604@karan.org>
Message-ID: <52D9AF78.8030400@redhat.com>

On 01/17/2014 05:20 PM, Karanbir Singh wrote:
> hi Guys,
> 
> Worth noting that we are going to be pushing OpenStack specific images
> in a few days as well from the centos.org side; These are also the
> images we will work with vendors to upstream into various public
> openstack offerings.

Thanks, that's where we want the image to end up anyhow :)

Are they really OpenStack specific though, or are they more 'Cloud
Enabled CentOS images'?

For Fedora/RHEL, we just have one qcow2 image that works across a
variety of Cloud platforms.

> One big difference is that we push an etc/cloud snippet to disable
> cloud-user and enable root logins ( without passwords ).

Isn't that a potential security issue?  On RHEL guest images we
explicitly disable root passwords and recommend folks who want to use
root passwords in their image to set them explicitly after downloading
an image via a tool like virt-sysprep.

> These images ( for c5/c6 on 32bit/64bit ) are due to be pushed on the
> 22nd Jan, and will go via the regular distribution channels.

Thanks!

Perry



From mail-lists at karan.org  Sat Jan 18 00:21:17 2014
From: mail-lists at karan.org (Karanbir Singh)
Date: Sat, 18 Jan 2014 00:21:17 +0000
Subject: [Rdo-list] CentOS 6.5 Guest image file available now
In-Reply-To: <52D9AF78.8030400@redhat.com>
References: <52D96F90.6060207@redhat.com> <52D9ACB4.50604@karan.org>
	<52D9AF78.8030400@redhat.com>
Message-ID: <52D9C8FD.7050906@karan.org>

On 01/17/2014 10:32 PM, Perry Myers wrote:
> Are they really OpenStack specific though, or are they more 'Cloud
> Enabled CentOS images'?
> 
> For Fedora/RHEL, we just have one qcow2 image that works across a
> variety of Cloud platforms.

How do you contextualise for cloudstack / opennebula / brightbox etc ?
Even the AWS images dont quite work as-is all the time everywhere else
down to the xvda -> xvde farkage and how that maps to /dev/sda foo under
kvm.

given enough cycles, its possible for an instance to workout what
controller its running under and then adapt the context scripts to do
the right thing, hopefully with the added bandwidth of community we can
get there.

>> One big difference is that we push an etc/cloud snippet to disable
>> cloud-user and enable root logins ( without passwords ).
> 
> Isn't that a potential security issue?  On RHEL guest images we
> explicitly disable root passwords and recommend folks who want to use
> root passwords in their image to set them explicitly after downloading
> an image via a tool like virt-sysprep.

So, no password access; its by key only. Plus, on firstboot we set a
random root password.

- KB

-- 
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc



From pmyers at redhat.com  Sat Jan 18 00:30:32 2014
From: pmyers at redhat.com (Perry Myers)
Date: Fri, 17 Jan 2014 19:30:32 -0500
Subject: [Rdo-list] CentOS 6.5 Guest image file available now
In-Reply-To: <52D9C8FD.7050906@karan.org>
References: <52D96F90.6060207@redhat.com>
	<52D9ACB4.50604@karan.org>	<52D9AF78.8030400@redhat.com>
	<52D9C8FD.7050906@karan.org>
Message-ID: <52D9CB28.4010407@redhat.com>

On 01/17/2014 07:21 PM, Karanbir Singh wrote:
> On 01/17/2014 10:32 PM, Perry Myers wrote:
>> Are they really OpenStack specific though, or are they more 'Cloud
>> Enabled CentOS images'?
>>
>> For Fedora/RHEL, we just have one qcow2 image that works across a
>> variety of Cloud platforms.
> 
> How do you contextualise for cloudstack / opennebula / brightbox etc ?
> Even the AWS images dont quite work as-is all the time everywhere else
> down to the xvda -> xvde farkage and how that maps to /dev/sda foo under
> kvm.

Actually, I take part of my statement back... In RHEL/Fedora we have two
types of images.  AMIs for AWS and qcow2 for kvm in general, which also
works under OpenStack and oVirt/RHEV.

But, tbh, I'm not sure what add'l contextualization would need to be
done for cloudstack/opennebula/brightbox.  So perhaps those all do
require separate images.

But maybe we can get away with a single image for use in both vanilla
kvm, oVirt/RHEV and OpenStack, since we have done that for RHEL/Fedora,
it should be possible to do it for CentOS as well.

> given enough cycles, its possible for an instance to workout what
> controller its running under and then adapt the context scripts to do
> the right thing, hopefully with the added bandwidth of community we can
> get there.
> 
>>> One big difference is that we push an etc/cloud snippet to disable
>>> cloud-user and enable root logins ( without passwords ).
>>
>> Isn't that a potential security issue?  On RHEL guest images we
>> explicitly disable root passwords and recommend folks who want to use
>> root passwords in their image to set them explicitly after downloading
>> an image via a tool like virt-sysprep.
> 
> So, no password access; its by key only. Plus, on firstboot we set a
> random root password.

Ah ok.  When you said you enabled root logins without passwords, I
interpreted that differently (i.e. empty password, just hit enter to
login). :)

No worries then.

Perry



From mail-lists at karan.org  Sat Jan 18 00:38:39 2014
From: mail-lists at karan.org (Karanbir Singh)
Date: Sat, 18 Jan 2014 00:38:39 +0000
Subject: [Rdo-list] CentOS 6.5 Guest image file available now
In-Reply-To: <52D9CB28.4010407@redhat.com>
References: <52D96F90.6060207@redhat.com>
	<52D9ACB4.50604@karan.org>	<52D9AF78.8030400@redhat.com>
	<52D9C8FD.7050906@karan.org> <52D9CB28.4010407@redhat.com>
Message-ID: <52D9CD0F.1040003@karan.org>

On 01/18/2014 12:30 AM, Perry Myers wrote:
> Actually, I take part of my statement back... In RHEL/Fedora we have two
> types of images.  AMIs for AWS and qcow2 for kvm in general, which also
> works under OpenStack and oVirt/RHEV.

while i know this is OT here, and there are more focused lists for this
question - but how does ovirt/rhev contexutalise the images ? does it
also export the metadata service on the 169 ip that cloud-init can walk
to get keys etc ?

- K
-- 
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc



From mattdm at fedoraproject.org  Sat Jan 18 01:02:54 2014
From: mattdm at fedoraproject.org (Matthew Miller)
Date: Fri, 17 Jan 2014 20:02:54 -0500
Subject: [Rdo-list] CentOS 6.5 Guest image file available now
In-Reply-To: <52D9CB28.4010407@redhat.com>
References: <52D96F90.6060207@redhat.com> <52D9ACB4.50604@karan.org>
	<52D9AF78.8030400@redhat.com> <52D9C8FD.7050906@karan.org>
	<52D9CB28.4010407@redhat.com>
Message-ID: <20140118010253.GA8255@disco.bu.edu>

On Fri, Jan 17, 2014 at 07:30:32PM -0500, Perry Myers wrote:
> Actually, I take part of my statement back... In RHEL/Fedora we have two
> types of images.  AMIs for AWS and qcow2 for kvm in general, which also
> works under OpenStack and oVirt/RHEV.

For Fedora, the AMI and the qcow2 contain exactly the same bits. We haven't
done much testing under anything but EC2 and OpenStack, though -- to a
lesser extent Eucalyptus. And, we don't do hvm on EC2, so that simplifies
things.

As we grow into covering more targets we may need to split things up more.
We definitely intend to at least cover CloudStack better.

-- 
Matthew Miller    --   Fedora Project    --    



From mattdm at mattdm.org  Sat Jan 18 01:03:41 2014
From: mattdm at mattdm.org (Matthew Miller)
Date: Fri, 17 Jan 2014 20:03:41 -0500
Subject: [Rdo-list] CentOS 6.5 Guest image file available now
In-Reply-To: <52D9CD0F.1040003@karan.org>
References: <52D96F90.6060207@redhat.com> <52D9ACB4.50604@karan.org>
	<52D9AF78.8030400@redhat.com> <52D9C8FD.7050906@karan.org>
	<52D9CB28.4010407@redhat.com> <52D9CD0F.1040003@karan.org>
Message-ID: <20140118010340.GB8255@disco.bu.edu>

On Sat, Jan 18, 2014 at 12:38:39AM +0000, Karanbir Singh wrote:
> while i know this is OT here, and there are more focused lists for this
> question - but how does ovirt/rhev contexutalise the images ? does it
> also export the metadata service on the 169 ip that cloud-init can walk
> to get keys etc ?

It has its own metadata service that cloud-init knows about --
http://cloudinit.readthedocs.org/en/latest/topics/datasources.html#alt-cloud


-- 
Matthew Miller           mattdm at mattdm.org          



From shake.chen at gmail.com  Sat Jan 18 02:50:51 2014
From: shake.chen at gmail.com (Shake Chen)
Date: Sat, 18 Jan 2014 10:50:51 +0800
Subject: [Rdo-list] CentOS 6.5 Guest image file available now
In-Reply-To: <52D9AD46.7000907@karan.org>
References: <52D96F90.6060207@redhat.com> <52D9ACB4.50604@karan.org>
	<52D9AD46.7000907@karan.org>
Message-ID: 

I also have same question, whether support root disk resize?


On Sat, Jan 18, 2014 at 6:23 AM, Karanbir Singh wrote:

> On 01/17/2014 10:20 PM, Karanbir Singh wrote:
> > hi Guys,
> >
> > Worth noting that we are going to be pushing OpenStack specific images
> > in a few days as well from the centos.org side; These are also the
> > images we will work with vendors to upstream into various public
> > openstack offerings.
> >
> > One big difference is that we push an etc/cloud snippet to disable
> > cloud-user and enable root logins ( without passwords ).
> >
> > These images ( for c5/c6 on 32bit/64bit ) are due to be pushed on the
> > 22nd Jan, and will go via the regular distribution channels.
>
> and I also noticed there is no growroot suport in this image, is that by
> design ?
>
>
> --
> Karanbir Singh
> +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
> GnuPG Key : http://www.karan.org/publickey.asc
>
> _______________________________________________
> Rdo-list mailing list
> Rdo-list at redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list
>



-- 
Shake Chen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From pmyers at redhat.com  Sat Jan 18 02:59:55 2014
From: pmyers at redhat.com (Perry Myers)
Date: Fri, 17 Jan 2014 21:59:55 -0500
Subject: [Rdo-list] CentOS 6.5 Guest image file available now
In-Reply-To: 
References: <52D96F90.6060207@redhat.com>
	<52D9ACB4.50604@karan.org>	<52D9AD46.7000907@karan.org>
	
Message-ID: <52D9EE2B.6010707@redhat.com>

On 01/17/2014 09:50 PM, Shake Chen wrote:
> I also have same question, whether support root disk resize?

In the RHEL qcow2 images we did not have the right dependencies packaged
up to provide disk resize/growroot.

Because the image jboggs created was based on the same kickstart recipe
as our RHEL qcow2 image, that is why that was omitted.

There's no reason the CentOS image shouldn't have those utilities
though, since there are packages available.  From a RHEL perspective
we're still working on importing those packages to be able to create
RHEL images with that functionality.

Lars, you were working on this, right?

Perry



From lars at redhat.com  Sat Jan 18 03:11:54 2014
From: lars at redhat.com (Lars Kellogg-Stedman)
Date: Fri, 17 Jan 2014 22:11:54 -0500
Subject: [Rdo-list] CentOS 6.5 Guest image file available now
In-Reply-To: <52D9EE2B.6010707@redhat.com>
References: <52D96F90.6060207@redhat.com> <52D9ACB4.50604@karan.org>
	<52D9AD46.7000907@karan.org>
	
	<52D9EE2B.6010707@redhat.com>
Message-ID: <20140118031154.GC16191@redhat.com>

On Fri, Jan 17, 2014 at 09:59:55PM -0500, Perry Myers wrote:
> Lars, you were working on this, right?

Are, at least for RHEL.  I'm just waiting for rel-eng to finish
getting brew and dist-git set up.  The spec files are here:

- https://github.com/larsks-packages/cloud-utils-growpart
- https://github.com/larsks-packages/dracut-modules-growroot

And a tracking bug for everything related to this is here:

- https://bugzilla.redhat.com/show_bug.cgi?id=1052453

For CentOS, the necessary packages are already in EPEL (cloud-init is
a little long in the tooth, but it does work.  There was some talk on
centos-devel recently of bringing it up to parity with what's in LPC).

-- 
Lars Kellogg-Stedman  | larsks @ irc
Cloud Engineering / OpenStack          | "   "  @ twitter

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 

From shake.chen at gmail.com  Sat Jan 18 03:28:41 2014
From: shake.chen at gmail.com (Shake Chen)
Date: Sat, 18 Jan 2014 11:28:41 +0800
Subject: [Rdo-list] CentOS 6.5 Guest image file available now
In-Reply-To: <20140118031154.GC16191@redhat.com>
References: <52D96F90.6060207@redhat.com> <52D9ACB4.50604@karan.org>
	<52D9AD46.7000907@karan.org>
	
	<52D9EE2B.6010707@redhat.com> <20140118031154.GC16191@redhat.com>
Message-ID: 

the package whether support LVM partition?

I have test the https://github.com/flegmatik/linux-rootfs-resize

but lvm seem not working. and non lvm is working well.




On Sat, Jan 18, 2014 at 11:11 AM, Lars Kellogg-Stedman wrote:

> On Fri, Jan 17, 2014 at 09:59:55PM -0500, Perry Myers wrote:
> > Lars, you were working on this, right?
>
> Are, at least for RHEL.  I'm just waiting for rel-eng to finish
> getting brew and dist-git set up.  The spec files are here:
>
> - https://github.com/larsks-packages/cloud-utils-growpart
> - https://github.com/larsks-packages/dracut-modules-growroot
>
> And a tracking bug for everything related to this is here:
>
> - https://bugzilla.redhat.com/show_bug.cgi?id=1052453
>
> For CentOS, the necessary packages are already in EPEL (cloud-init is
> a little long in the tooth, but it does work.  There was some talk on
> centos-devel recently of bringing it up to parity with what's in LPC).
>
> --
> Lars Kellogg-Stedman  | larsks @ irc
> Cloud Engineering / OpenStack          | "   "  @ twitter
>
>


-- 
Shake Chen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From lars at redhat.com  Sat Jan 18 03:40:07 2014
From: lars at redhat.com (Lars Kellogg-Stedman)
Date: Fri, 17 Jan 2014 22:40:07 -0500
Subject: [Rdo-list] CentOS 6.5 Guest image file available now
In-Reply-To: 
References: <52D96F90.6060207@redhat.com> <52D9ACB4.50604@karan.org>
	<52D9AD46.7000907@karan.org>
	
	<52D9EE2B.6010707@redhat.com> <20140118031154.GC16191@redhat.com>
	
Message-ID: <20140118034007.GE16191@redhat.com>

On Sat, Jan 18, 2014 at 11:28:41AM +0800, Shake Chen wrote:
> the package whether support LVM partition?

LVM is not supported by these tools.  If you're using LVM, you can
dynamically expand your storage space while the system is running
without too much effort, whereas with a traditional partitioned image
this is much more difficult.

Using LVM, you should be able to create a new partition spanning the
unused space on the disk image and add that to your existing volume
group.

-- 
Lars Kellogg-Stedman  | larsks @ irc
Cloud Engineering / OpenStack          | "   "  @ twitter

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 

From mail-lists at karan.org  Sat Jan 18 03:48:57 2014
From: mail-lists at karan.org (Karanbir Singh)
Date: Sat, 18 Jan 2014 03:48:57 +0000
Subject: [Rdo-list] CentOS 6.5 Guest image file available now
In-Reply-To: <20140118031154.GC16191@redhat.com>
References: <52D96F90.6060207@redhat.com> <52D9ACB4.50604@karan.org>
	<52D9AD46.7000907@karan.org>
	
	<52D9EE2B.6010707@redhat.com> <20140118031154.GC16191@redhat.com>
Message-ID: <52D9F9A9.8060908@karan.org>

On 01/18/2014 03:11 AM, Lars Kellogg-Stedman wrote:
> On Fri, Jan 17, 2014 at 09:59:55PM -0500, Perry Myers wrote:
>> Lars, you were working on this, right?
> 
> Are, at least for RHEL.  I'm just waiting for rel-eng to finish
> getting brew and dist-git set up.  The spec files are here:
> 
> - https://github.com/larsks-packages/cloud-utils-growpart
> - https://github.com/larsks-packages/dracut-modules-growroot
> 
> And a tracking bug for everything related to this is here:
> 
> - https://bugzilla.redhat.com/show_bug.cgi?id=1052453
> 
> For CentOS, the necessary packages are already in EPEL (cloud-init is
> a little long in the tooth, but it does work.  There was some talk on
> centos-devel recently of bringing it up to parity with what's in LPC).
> 

Thanks, I will look at what you guys have here and make sure that what I
have in the centos builds is either in line or easily adapted to be in sync.

-- 
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc



From sdake at redhat.com  Sat Jan 18 23:43:05 2014
From: sdake at redhat.com (Steven Dake)
Date: Sat, 18 Jan 2014 16:43:05 -0700
Subject: [Rdo-list] CentOS 6.5 Guest image file available now
In-Reply-To: <52D9ACB4.50604@karan.org>
References: <52D96F90.6060207@redhat.com> <52D9ACB4.50604@karan.org>
Message-ID: <52DB1189.2090308@redhat.com>

On 01/17/2014 03:20 PM, Karanbir Singh wrote:
> hi Guys,
>
> Worth noting that we are going to be pushing OpenStack specific images
> in a few days as well from the centos.org side; These are also the
> images we will work with vendors to upstream into various public
> openstack offerings.
Karanbir,

Would you be opposed to adding the heat-cfntools RPM in the pre-built 
CentOS image that is OpenStack specific?  We do this for Fedora 20+ as 
well as RHEL 6.5.  The RPM is very small and has only one dependency 
IIRC and has no init scripts or any default startup that would result in 
breakage of the software.

Also, I'm unclear if your planning to add cloud-init to the image, but I 
would highly recommend cloud-init for your default images and this is 
mandatory to have Heat + CentOS + OpenStack integration.

The heat_cfntools package is necessary for using Heat with Openstack 
guest images.

If your not opposed, I've copied Jeff Peeler (Heat Core developer) to 
sort out the implementation details from an engineering perspective.

Regards
-steve

> One big difference is that we push an etc/cloud snippet to disable
> cloud-user and enable root logins ( without passwords ).
>
> These images ( for c5/c6 on 32bit/64bit ) are due to be pushed on the
> 22nd Jan, and will go via the regular distribution channels.
>
>
> - KB
>
>
> On 01/17/2014 05:59 PM, Mike Burns wrote:
>> Thanks to Joey Boggs for putting this together.
>>
>> A prebuilt guest-image for CentOS 6.5 has been posted to the RDO yum
>> repository along with the kickstart used to generate it. [1]  This was
>> done in response to the conversation on IRC earlier.
>>
>> The eventual plan would be to have this image owned and generated by the
>> CentOS community, perhaps as part of the Cloud SIG.  This is just a
>> stopgap measure until the SIG is up and running.
>>
>> Let us know if you find any issues with it.
>>
>> Thanks
>>
>> Mike
>>
>> [1] http://repos.fedorapeople.org/repos/openstack/guest-images/
>>
>
>



From mattdm at fedoraproject.org  Sun Jan 19 04:04:32 2014
From: mattdm at fedoraproject.org (Matthew Miller)
Date: Sat, 18 Jan 2014 23:04:32 -0500
Subject: [Rdo-list] CentOS 6.5 Guest image file available now
In-Reply-To: <52DB1189.2090308@redhat.com>
References: <52D96F90.6060207@redhat.com> <52D9ACB4.50604@karan.org>
	<52DB1189.2090308@redhat.com>
Message-ID: <20140119040432.GA1556@disco.bu.edu>

On Sat, Jan 18, 2014 at 04:43:05PM -0700, Steven Dake wrote:
> Would you be opposed to adding the heat-cfntools RPM in the
> pre-built CentOS image that is OpenStack specific?  We do this for
> Fedora 20+ as well as RHEL 6.5.  The RPM is very small and has only
> one dependency IIRC and has no init scripts or any default startup
> that would result in breakage of the software.

python-boto and python-psutil -- both are in epel. Python-boto is kinda big
(7MB on disk) but is already required by cloud-init so is in practice a
no-op.

-- 
Matthew Miller    --   Fedora Project    --    



From rjones at redhat.com  Mon Jan 20 13:06:10 2014
From: rjones at redhat.com (Richard W.M. Jones)
Date: Mon, 20 Jan 2014 13:06:10 +0000
Subject: [Rdo-list] RDO on Fedora 20
Message-ID: <20140120130610.GA32175@redhat.com>


I decided to update my RDO (packstack) server to Fedora 20 today.
Possibly that was naive:

http://yum.theforeman.org/releases/1.3/f20/x86_64/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found

and if I disable the above:

http://repos.fedorapeople.org/repos/openstack/openstack-havana/fedora-20/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found

There seem to be plenty of other people using RDO on F20 judging by
questions posted on this list.  Is there something I'm doing wrong here?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v



From rjones at redhat.com  Mon Jan 20 13:09:14 2014
From: rjones at redhat.com (Richard W.M. Jones)
Date: Mon, 20 Jan 2014 13:09:14 +0000
Subject: [Rdo-list] RDO on Fedora 20
In-Reply-To: <20140120130610.GA32175@redhat.com>
References: <20140120130610.GA32175@redhat.com>
Message-ID: <20140120130914.GB32175@redhat.com>

On Mon, Jan 20, 2014 at 01:06:10PM +0000, Richard W.M. Jones wrote:
> 
> I decided to update my RDO (packstack) server to Fedora 20 today.
> Possibly that was naive:
> 
> http://yum.theforeman.org/releases/1.3/f20/x86_64/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found
> 
> and if I disable the above:
> 
> http://repos.fedorapeople.org/repos/openstack/openstack-havana/fedora-20/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found

Reading this page more closely: http://openstack.redhat.com/Quickstart
it does say "If on Fedora 20, please skip to step 2".

The Foreman repo is still missing however.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW



From dneary at redhat.com  Mon Jan 20 13:24:01 2014
From: dneary at redhat.com (Dave Neary)
Date: Mon, 20 Jan 2014 14:24:01 +0100
Subject: [Rdo-list] RDO on Fedora 20
In-Reply-To: <20140120130610.GA32175@redhat.com>
References: <20140120130610.GA32175@redhat.com>
Message-ID: <52DD2371.5070601@redhat.com>

Hi Richard,

The Foreman is not supported on Fedora 20 because of the Ruby 3 dependency.

And we do not package RPMs for OpenStack on Fedora if the version is
already packaged in Fedora upstream. So if you want to install Havana on
F20 you install the packages direct from Fedora, you don't need the RDO
repo.

Hope that helps,
Dave.

On 01/20/2014 02:06 PM, Richard W.M. Jones wrote:
> 
> I decided to update my RDO (packstack) server to Fedora 20 today.
> Possibly that was naive:
> 
> http://yum.theforeman.org/releases/1.3/f20/x86_64/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found
> 
> and if I disable the above:
> 
> http://repos.fedorapeople.org/repos/openstack/openstack-havana/fedora-20/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found
> 
> There seem to be plenty of other people using RDO on F20 judging by
> questions posted on this list.  Is there something I'm doing wrong here?
> 
> Rich.
> 

-- 
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13



From pmyers at redhat.com  Mon Jan 20 13:30:22 2014
From: pmyers at redhat.com (Perry Myers)
Date: Mon, 20 Jan 2014 08:30:22 -0500
Subject: [Rdo-list] RDO on Fedora 20
In-Reply-To: <52DD2371.5070601@redhat.com>
References: <20140120130610.GA32175@redhat.com> <52DD2371.5070601@redhat.com>
Message-ID: <52DD24EE.2020909@redhat.com>

On 01/20/2014 08:24 AM, Dave Neary wrote:
> Hi Richard,
> 
> The Foreman is not supported on Fedora 20 because of the Ruby 3 dependency.
> 
> And we do not package RPMs for OpenStack on Fedora if the version is
> already packaged in Fedora upstream. So if you want to install Havana on
> F20 you install the packages direct from Fedora, you don't need the RDO
> repo.

Also... I think at some point we made a decision that Fedora focus would
be on development, not on production deployments.  Given that Foreman is
more meant for production deployments (over Packstack), there isn't
really any focus on getting RDO + Foreman working on Fedora.

Fedora should work with Packstack and with devstack at all times though.

I know that Alvaro just got a patch for F20 into Devstack upstream, so
hopefully it should work now.

And if you find any issues w/ Packstack on F20 definitely let folks know

Rich/Mike, perhaps we need to make it clearer on the web site that we're
not supporting the combination of Foreman and Fedora for the time being?

Perry

> Hope that helps,
> Dave.
> 
> On 01/20/2014 02:06 PM, Richard W.M. Jones wrote:
>>
>> I decided to update my RDO (packstack) server to Fedora 20 today.
>> Possibly that was naive:
>>
>> http://yum.theforeman.org/releases/1.3/f20/x86_64/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found
>>
>> and if I disable the above:
>>
>> http://repos.fedorapeople.org/repos/openstack/openstack-havana/fedora-20/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found
>>
>> There seem to be plenty of other people using RDO on F20 judging by
>> questions posted on this list.  Is there something I'm doing wrong here?
>>
>> Rich.
>>
> 



From dneary at redhat.com  Mon Jan 20 14:00:54 2014
From: dneary at redhat.com (Dave Neary)
Date: Mon, 20 Jan 2014 15:00:54 +0100
Subject: [Rdo-list] RDO on Fedora 20
In-Reply-To: <52DD24EE.2020909@redhat.com>
References: <20140120130610.GA32175@redhat.com> <52DD2371.5070601@redhat.com>
	<52DD24EE.2020909@redhat.com>
Message-ID: <52DD2C16.7060005@redhat.com>

CCing Sam Kottler just to get an update on the Foreman in Fedora, for
those interested.

Sam, see conversation below re Foreman missing from F20, causing issue
for some OpenStack users.

Thanks,
Dave.

On 01/20/2014 02:30 PM, Perry Myers wrote:
> On 01/20/2014 08:24 AM, Dave Neary wrote:
>> Hi Richard,
>>
>> The Foreman is not supported on Fedora 20 because of the Ruby 3 dependency.
>>
>> And we do not package RPMs for OpenStack on Fedora if the version is
>> already packaged in Fedora upstream. So if you want to install Havana on
>> F20 you install the packages direct from Fedora, you don't need the RDO
>> repo.
> 
> Also... I think at some point we made a decision that Fedora focus would
> be on development, not on production deployments.  Given that Foreman is
> more meant for production deployments (over Packstack), there isn't
> really any focus on getting RDO + Foreman working on Fedora.
> 
> Fedora should work with Packstack and with devstack at all times though.
> 
> I know that Alvaro just got a patch for F20 into Devstack upstream, so
> hopefully it should work now.
> 
> And if you find any issues w/ Packstack on F20 definitely let folks know
> 
> Rich/Mike, perhaps we need to make it clearer on the web site that we're
> not supporting the combination of Foreman and Fedora for the time being?
> 
> Perry
> 
>> Hope that helps,
>> Dave.
>>
>> On 01/20/2014 02:06 PM, Richard W.M. Jones wrote:
>>>
>>> I decided to update my RDO (packstack) server to Fedora 20 today.
>>> Possibly that was naive:
>>>
>>> http://yum.theforeman.org/releases/1.3/f20/x86_64/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found
>>>
>>> and if I disable the above:
>>>
>>> http://repos.fedorapeople.org/repos/openstack/openstack-havana/fedora-20/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found
>>>
>>> There seem to be plenty of other people using RDO on F20 judging by
>>> questions posted on this list.  Is there something I'm doing wrong here?
>>>
>>> Rich.
>>>
>>
> 

-- 
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13



From rjones at redhat.com  Mon Jan 20 14:11:30 2014
From: rjones at redhat.com (Richard W.M. Jones)
Date: Mon, 20 Jan 2014 14:11:30 +0000
Subject: [Rdo-list] RDO on Fedora 20
In-Reply-To: <52DD2C16.7060005@redhat.com>
References: <20140120130610.GA32175@redhat.com> <52DD2371.5070601@redhat.com>
	<52DD24EE.2020909@redhat.com> <52DD2C16.7060005@redhat.com>
Message-ID: <20140120141130.GM4802@redhat.com>

On Mon, Jan 20, 2014 at 03:00:54PM +0100, Dave Neary wrote:
> CCing Sam Kottler just to get an update on the Foreman in Fedora, for
> those interested.
> 
> Sam, see conversation below re Foreman missing from F20, causing issue
> for some OpenStack users.

Just an update:

Basically this is fine and packstack *does* install everythink on F20
OK (after one failure to get mongodb working which seemed to be
transient).

The Foreman repo was installed as a side-effect of installing
rdo-release, so once I removed that I didn't need Foreman for F20.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v



From pmyers at redhat.com  Mon Jan 20 14:15:46 2014
From: pmyers at redhat.com (Perry Myers)
Date: Mon, 20 Jan 2014 09:15:46 -0500
Subject: [Rdo-list] RDO on Fedora 20
In-Reply-To: <20140120141130.GM4802@redhat.com>
References: <20140120130610.GA32175@redhat.com>
	<52DD2371.5070601@redhat.com>	<52DD24EE.2020909@redhat.com>
	<52DD2C16.7060005@redhat.com> <20140120141130.GM4802@redhat.com>
Message-ID: <52DD2F92.8050303@redhat.com>

On 01/20/2014 09:11 AM, Richard W.M. Jones wrote:
> On Mon, Jan 20, 2014 at 03:00:54PM +0100, Dave Neary wrote:
>> CCing Sam Kottler just to get an update on the Foreman in Fedora, for
>> those interested.
>>
>> Sam, see conversation below re Foreman missing from F20, causing issue
>> for some OpenStack users.
> 
> Just an update:
> 
> Basically this is fine and packstack *does* install everythink on F20
> OK (after one failure to get mongodb working which seemed to be
> transient).
> 
> The Foreman repo was installed as a side-effect of installing
> rdo-release, so once I removed that I didn't need Foreman for F20.

P?draig, do we need to fix rdo-release for Fedora so that it omits the
Foreman repos for the time being?



From pbrady at redhat.com  Mon Jan 20 14:43:16 2014
From: pbrady at redhat.com (=?ISO-8859-1?Q?P=E1draig_Brady?=)
Date: Mon, 20 Jan 2014 14:43:16 +0000
Subject: [Rdo-list] RDO on Fedora 20
In-Reply-To: <52DD2F92.8050303@redhat.com>
References: <20140120130610.GA32175@redhat.com>
	<52DD2371.5070601@redhat.com>	<52DD24EE.2020909@redhat.com>
	<52DD2C16.7060005@redhat.com> <20140120141130.GM4802@redhat.com>
	<52DD2F92.8050303@redhat.com>
Message-ID: <52DD3604.1090402@redhat.com>

On 01/20/2014 02:15 PM, Perry Myers wrote:
> On 01/20/2014 09:11 AM, Richard W.M. Jones wrote:
>> On Mon, Jan 20, 2014 at 03:00:54PM +0100, Dave Neary wrote:
>>> CCing Sam Kottler just to get an update on the Foreman in Fedora, for
>>> those interested.
>>>
>>> Sam, see conversation below re Foreman missing from F20, causing issue
>>> for some OpenStack users.
>>
>> Just an update:
>>
>> Basically this is fine and packstack *does* install everythink on F20
>> OK (after one failure to get mongodb working which seemed to be
>> transient).
>>
>> The Foreman repo was installed as a side-effect of installing
>> rdo-release, so once I removed that I didn't need Foreman for F20.
> 
> P?draig, do we need to fix rdo-release for Fedora so that it omits the
> Foreman repos for the time being?

That's already done for rdo-release-icehouse.rpm
https://github.com/redhat-openstack/rdo-release/commits/master

It doesn't need to be done for Fedora 20 havana as noted above
and as per the quickstart instructions.

thanks,
P?draig.



From rbowen at redhat.com  Mon Jan 20 14:49:05 2014
From: rbowen at redhat.com (Rich Bowen)
Date: Mon, 20 Jan 2014 09:49:05 -0500
Subject: [Rdo-list] Fwd: [openstack-community] Athens OpenStack User Group
	meeting
In-Reply-To: <52D90D43.1090006@stackmasters.eu>
References: <52D90D43.1090006@stackmasters.eu>
Message-ID: <52DD3761.3090407@redhat.com>

FYI, for those of you in the Athens area.


-------- Original Message --------
Subject: 	[openstack-community] Athens OpenStack User Group meeting
Date: 	Fri, 17 Jan 2014 13:00:19 +0200
From: 	Thanassis Parathyras 
To: 	community at lists.openstack.org



*Athens OpenStack User Group meeting
*

Join us on Wednesday 29th January, 7PM


@OpenStack  #OSATH

The Athens OpenStack User Group invites you to attend the sixth meeting 
for OpenStack in Greece.?
*
Athens OpenStack User Group meeting on Thursday 29th January, 7PM at 
CoLab Athens, Petraki 28, Syntagma.**
*

*User Story: vLab at TEI Piraeus using OpenStack*

Department of Electronics at TEI Piraeus is one interesting OpenStack 
user story. Stefanos as the leader of the laboratory team selected 
OpenStack to address needs like rapid deployment for course labs, single 
point of control for the infrastructure resources and easily share 
resources and operations among different teams. All the above and 
related *technical detail* along with a *live demo* of the installation 
are going to be covered during the #OSATH presentation.

RSVP via http://www.meetup.com/Athens-OpenStack-User-Group/events/160875952/

More updates via @parathyras @colabathens

with my best regards,
Thanassis Parathyras


-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
_______________________________________________
Community mailing list
Community at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/community


From rbowen at redhat.com  Mon Jan 20 14:49:23 2014
From: rbowen at redhat.com (Rich Bowen)
Date: Mon, 20 Jan 2014 09:49:23 -0500
Subject: [Rdo-list] Fwd: [openstack-community] Openstack Amsterdam January
	Meetup
In-Reply-To: 
References: 
Message-ID: <52DD3773.2050906@redhat.com>

FYI, for those of you in the Amsterdam area.


-------- Original Message --------
Subject: 	[openstack-community] Openstack Amsterdam January Meetup
Date: 	Fri, 17 Jan 2014 13:39:46 +0100
From: 	Alessandro Vozza 
To: 	Community at lists.openstack.org



Dutch community alive and well! Here comes the next meetup, less than a 
week to go:

http://www.meetup.com/Openstack-Amsterdam/events/155266692/

Feel free to bring your favourite presentation device and give a 
lightning talk.

-- 

______________

*Openstack Amsterdam Meetup*

http://www.meetup.com/Openstack-Amsterdam/



-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
_______________________________________________
Community mailing list
Community at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/community


From pbrady at redhat.com  Mon Jan 20 15:26:26 2014
From: pbrady at redhat.com (=?ISO-8859-1?Q?P=E1draig_Brady?=)
Date: Mon, 20 Jan 2014 15:26:26 +0000
Subject: [Rdo-list] RDO on Fedora 20
In-Reply-To: <52DD3604.1090402@redhat.com>
References: <20140120130610.GA32175@redhat.com>
	<52DD2371.5070601@redhat.com>	<52DD24EE.2020909@redhat.com>
	<52DD2C16.7060005@redhat.com> <20140120141130.GM4802@redhat.com>
	<52DD2F92.8050303@redhat.com> <52DD3604.1090402@redhat.com>
Message-ID: <52DD4022.8020000@redhat.com>

On 01/20/2014 02:43 PM, P?draig Brady wrote:
> On 01/20/2014 02:15 PM, Perry Myers wrote:
>> On 01/20/2014 09:11 AM, Richard W.M. Jones wrote:
>>> On Mon, Jan 20, 2014 at 03:00:54PM +0100, Dave Neary wrote:
>>>> CCing Sam Kottler just to get an update on the Foreman in Fedora, for
>>>> those interested.
>>>>
>>>> Sam, see conversation below re Foreman missing from F20, causing issue
>>>> for some OpenStack users.
>>>
>>> Just an update:
>>>
>>> Basically this is fine and packstack *does* install everythink on F20
>>> OK (after one failure to get mongodb working which seemed to be
>>> transient).
>>>
>>> The Foreman repo was installed as a side-effect of installing
>>> rdo-release, so once I removed that I didn't need Foreman for F20.
>>
>> P?draig, do we need to fix rdo-release for Fedora so that it omits the
>> Foreman repos for the time being?
> 
> That's already done for rdo-release-icehouse.rpm
> https://github.com/redhat-openstack/rdo-release/commits/master
> 
> It doesn't need to be done for Fedora 20 havana as noted above
> and as per the quickstart instructions.

BTW I've just linked the Icehouse install instructions
http://openstack.redhat.com/QuickStartDevelRelease
(which does need the rdo-release.rpm installed on Fedora 20)
from the main quick start.

thanks,
P?draig.



From rbowen at redhat.com  Mon Jan 20 15:58:26 2014
From: rbowen at redhat.com (Rich Bowen)
Date: Mon, 20 Jan 2014 10:58:26 -0500
Subject: [Rdo-list] RDO Icehouse Milestone 2 test day: February 4-5
Message-ID: <52DD47A2.3070302@redhat.com>

With the Icehouse milestone 2 due on January 23rd, we're planning to do 
another RDO test day on February 4-5, by which time we'll have produced 
RDO packages for all the relevant platforms, and had a chance to do some 
initial testing.

As with the last test day, we'll be testing deployment on various 
platforms, as well as more complex scenarios. You can see 
http://openstack.redhat.com/TestedSetups_2014_01 for some idea of the 
kinds of things we did last time, and we'd like to see more of the list 
tested this time around.

The page at 
http://openstack.redhat.com/RDO_test_day_Icehouse_milestone_2 will have 
more information as we get closer to the date, including a table of 
things we'd like to get tested, and instructions on how to test them and 
record your results.

Thanks!

--rcb

-- 
Rich Bowen - rbowen at redhat.com
OpenStack Community Liaison
http://openstack.redhat.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From shake.chen at gmail.com  Mon Jan 20 17:19:20 2014
From: shake.chen at gmail.com (Shake Chen)
Date: Tue, 21 Jan 2014 01:19:20 +0800
Subject: [Rdo-list] ceilometer in single host problem
Message-ID: 

Hi

Now I try to install ceilometer in single host, and report the error

ERROR : Error appeared during Puppet run: 172.18.1.18_ceilometer.pp
Error: Could not set groups on user[ceilometer]: Execution of
'/usr/sbin/usermod -G ceilometer,nobody,nova ceilometer' returned 6:
usermod: group 'nova' does not exist
You will find full trace in log
/var/tmp/packstack/20140121-012827-4t48Fn/manifests/172.18.1.18_ceilometer.pp.log

I check the log show

^[[1;31mError: Could not set groups on user[ceilometer]: Execution of
'/usr/sbin/usermod -G ceilometer,nobody,nova ceilometer
' returned 6: usermod: group 'nova' does not exist
^[[0m
^[[1;31mError: /Stage[main]/Ceilometer/User[ceilometer]/groups: change from
nobody,ceilometer to ceilometer,nobody,nova faile
d: Could not set groups on user[ceilometer]: Execution of
'/usr/sbin/usermod -G ceilometer,nobody,nova ceilometer' returned 6
: usermod: group 'nova' does not exist

seem this is RDO bug ?



-- 
Shake Chen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From pbrady at redhat.com  Mon Jan 20 17:41:54 2014
From: pbrady at redhat.com (=?ISO-8859-1?Q?P=E1draig_Brady?=)
Date: Mon, 20 Jan 2014 17:41:54 +0000
Subject: [Rdo-list] ceilometer in single host problem
In-Reply-To: 
References: 
Message-ID: <52DD5FE2.8050802@redhat.com>

On 01/20/2014 05:19 PM, Shake Chen wrote:
> usermod: group 'nova' does not exist

That looks like a puppet module issue, and this looks like a fix upstream:
https://github.com/stackforge/puppet-ceilometer/commit/d064997c

I've logged this bug to the appropriate component in RDO:
https://bugzilla.redhat.com/1055661

thanks,
P?draig.



From lars at redhat.com  Mon Jan 20 18:35:57 2014
From: lars at redhat.com (Lars Kellogg-Stedman)
Date: Mon, 20 Jan 2014 13:35:57 -0500
Subject: [Rdo-list] RDO on Fedora 20
In-Reply-To: <20140120141130.GM4802@redhat.com>
References: <20140120130610.GA32175@redhat.com> <52DD2371.5070601@redhat.com>
	<52DD24EE.2020909@redhat.com> <52DD2C16.7060005@redhat.com>
	<20140120141130.GM4802@redhat.com>
Message-ID: <20140120183556.GB14416@redhat.com>

On Mon, Jan 20, 2014 at 02:11:30PM +0000, Richard W.M. Jones wrote:
> Basically this is fine and packstack *does* install everythink on F20
> OK (after one failure to get mongodb working which seemed to be
> transient).

Probably that was https://bugzilla.redhat.com/show_bug.cgi?id=1028690.

-- 
Lars Kellogg-Stedman  | larsks @ irc
Cloud Engineering / OpenStack          | "   "  @ twitter

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 

From jpeeler at redhat.com  Mon Jan 20 18:52:56 2014
From: jpeeler at redhat.com (Jeff Peeler)
Date: Mon, 20 Jan 2014 13:52:56 -0500
Subject: [Rdo-list] CentOS 6.5 Guest image file available now
In-Reply-To: <52DB1189.2090308@redhat.com>
References: <52D96F90.6060207@redhat.com> <52D9ACB4.50604@karan.org>
	<52DB1189.2090308@redhat.com>
Message-ID: <20140120185256.GE28994@jbp-laptop.localdomain>

On Sat, Jan 18, 2014 at 04:43:05PM -0700, Steven Dake wrote:
> On 01/17/2014 03:20 PM, Karanbir Singh wrote:
> >hi Guys,
> >
> >Worth noting that we are going to be pushing OpenStack specific images
> >in a few days as well from the centos.org side; These are also the
> >images we will work with vendors to upstream into various public
> >openstack offerings.
> Karanbir,
> 
> Would you be opposed to adding the heat-cfntools RPM in the pre-built CentOS
> image that is OpenStack specific?  We do this for Fedora 20+ as well as RHEL
> 6.5.  The RPM is very small and has only one dependency IIRC and has no init
> scripts or any default startup that would result in breakage of the
> software.
> 
> Also, I'm unclear if your planning to add cloud-init to the image, but I
> would highly recommend cloud-init for your default images and this is
> mandatory to have Heat + CentOS + OpenStack integration.
> 
> The heat_cfntools package is necessary for using Heat with Openstack guest
> images.
> 
> If your not opposed, I've copied Jeff Peeler (Heat Core developer) to sort
> out the implementation details from an engineering perspective.

heat-cfntools seems to be in the kickstart file already (as well as
cloud-init), is there anything else that needs to be done?

http://repos.fedorapeople.org/repos/openstack/guest-images/centos6.ks

> >One big difference is that we push an etc/cloud snippet to disable
> >cloud-user and enable root logins ( without passwords ).
> >
> >These images ( for c5/c6 on 32bit/64bit ) are due to be pushed on the
> >22nd Jan, and will go via the regular distribution channels.
> >
> >
> >- KB
> >
> >
> >On 01/17/2014 05:59 PM, Mike Burns wrote:
> >>Thanks to Joey Boggs for putting this together.
> >>
> >>A prebuilt guest-image for CentOS 6.5 has been posted to the RDO yum
> >>repository along with the kickstart used to generate it. [1]  This was
> >>done in response to the conversation on IRC earlier.
> >>
> >>The eventual plan would be to have this image owned and generated by the
> >>CentOS community, perhaps as part of the Cloud SIG.  This is just a
> >>stopgap measure until the SIG is up and running.
> >>
> >>Let us know if you find any issues with it.
> >>
> >>Thanks
> >>
> >>Mike
> >>
> >>[1] http://repos.fedorapeople.org/repos/openstack/guest-images/
> >>
> >
> >
> 



From sdake at redhat.com  Mon Jan 20 18:58:58 2014
From: sdake at redhat.com (Steven Dake)
Date: Mon, 20 Jan 2014 11:58:58 -0700
Subject: [Rdo-list] CentOS 6.5 Guest image file available now
In-Reply-To: <20140120185256.GE28994@jbp-laptop.localdomain>
References: <52D96F90.6060207@redhat.com> <52D9ACB4.50604@karan.org>
	<52DB1189.2090308@redhat.com>
	<20140120185256.GE28994@jbp-laptop.localdomain>
Message-ID: <52DD71F2.3050708@redhat.com>

On 01/20/2014 11:52 AM, Jeff Peeler wrote:
> On Sat, Jan 18, 2014 at 04:43:05PM -0700, Steven Dake wrote:
>> On 01/17/2014 03:20 PM, Karanbir Singh wrote:
>>> hi Guys,
>>>
>>> Worth noting that we are going to be pushing OpenStack specific images
>>> in a few days as well from the centos.org side; These are also the
>>> images we will work with vendors to upstream into various public
>>> openstack offerings.
>> Karanbir,
>>
>> Would you be opposed to adding the heat-cfntools RPM in the pre-built CentOS
>> image that is OpenStack specific?  We do this for Fedora 20+ as well as RHEL
>> 6.5.  The RPM is very small and has only one dependency IIRC and has no init
>> scripts or any default startup that would result in breakage of the
>> software.
>>
>> Also, I'm unclear if your planning to add cloud-init to the image, but I
>> would highly recommend cloud-init for your default images and this is
>> mandatory to have Heat + CentOS + OpenStack integration.
>>
>> The heat_cfntools package is necessary for using Heat with Openstack guest
>> images.
>>
>> If your not opposed, I've copied Jeff Peeler (Heat Core developer) to sort
>> out the implementation details from an engineering perspective.
> heat-cfntools seems to be in the kickstart file already (as well as
> cloud-init), is there anything else that needs to be done?
>
> http://repos.fedorapeople.org/repos/openstack/guest-images/centos6.ks
>
Guess I should RTFS :)  Thanks Jeff - I think we are ready to roll 
although verifying the image works in Heat would be helpful :).

Regards
-steve

>>> One big difference is that we push an etc/cloud snippet to disable
>>> cloud-user and enable root logins ( without passwords ).
>>>
>>> These images ( for c5/c6 on 32bit/64bit ) are due to be pushed on the
>>> 22nd Jan, and will go via the regular distribution channels.
>>>
>>>
>>> - KB
>>>
>>>
>>> On 01/17/2014 05:59 PM, Mike Burns wrote:
>>>> Thanks to Joey Boggs for putting this together.
>>>>
>>>> A prebuilt guest-image for CentOS 6.5 has been posted to the RDO yum
>>>> repository along with the kickstart used to generate it. [1]  This was
>>>> done in response to the conversation on IRC earlier.
>>>>
>>>> The eventual plan would be to have this image owned and generated by the
>>>> CentOS community, perhaps as part of the Cloud SIG.  This is just a
>>>> stopgap measure until the SIG is up and running.
>>>>
>>>> Let us know if you find any issues with it.
>>>>
>>>> Thanks
>>>>
>>>> Mike
>>>>
>>>> [1] http://repos.fedorapeople.org/repos/openstack/guest-images/
>>>>
>>>



From kit.plummer at airgapit.com  Mon Jan 20 20:08:47 2014
From: kit.plummer at airgapit.com (Kit Plummer)
Date: Mon, 20 Jan 2014 13:08:47 -0700
Subject: [Rdo-list] openstack-foreman-installer and an 'all-in-one'.
Message-ID: 

Hey guys. ?I caught a comment in IRC that PackStack was being deprecated in favor of a Foreman managed setup - so I?m curious if it is possible to create an ?all-in-one? environment using Foreman. ?Any ideas/thoughts?

Thanks in advance.
Kit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mail-lists at karan.org  Mon Jan 20 23:03:34 2014
From: mail-lists at karan.org (Karanbir Singh)
Date: Mon, 20 Jan 2014 23:03:34 +0000
Subject: [Rdo-list] CentOS 6.5 Guest image file available now
In-Reply-To: <52DD71F2.3050708@redhat.com>
References: <52D96F90.6060207@redhat.com> <52D9ACB4.50604@karan.org>
	<52DB1189.2090308@redhat.com>
	<20140120185256.GE28994@jbp-laptop.localdomain>
	<52DD71F2.3050708@redhat.com>
Message-ID: <52DDAB46.1000804@karan.org>

Hi,

How 'production' is this repo :
http://repos.fedorapeople.org/repos/openstack/cloud-init/epel-6

wouldnt it be worth upgrading the cloud-init in EPEL ?

Also, the ks the CentOS images are built from looks quite different from
this one, I'm going to try and get the work finished to get that stuff
into git so we can start colaborating on that.

the  Cloud Instance SIG is definitely ready to kick off in CentOS-devel

-- 
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc



From rbowen at redhat.com  Tue Jan 21 00:39:38 2014
From: rbowen at redhat.com (Rich Bowen)
Date: Mon, 20 Jan 2014 19:39:38 -0500
Subject: [Rdo-list] RDO community sync: 9am EST on #rdo
Message-ID: <52DDC1CA.4070604@redhat.com>

Sorry, I forgot to send out a reminder earlier.

We'll be doing the RDO community sync tomorrow morning at 9 EST on #rdo, 
on the Freenode IRC network.

The agenda/notes can be found at 
https://etherpad.openstack.org/p/rdo_community_manager_sync


-- 
Rich Bowen - rbowen at redhat.com
OpenStack Community Liaison
http://openstack.redhat.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From bderzhavets at hotmail.com  Tue Jan 21 11:01:24 2014
From: bderzhavets at hotmail.com (Boris Derzhavets)
Date: Tue, 21 Jan 2014 06:01:24 -0500
Subject: [Rdo-list] Attempt to reproduce Kashyap Setup (Controller+Compute)
 on F20 is almost done
In-Reply-To: <52D9457C.1080504@redhat.com>
References: 
	<52B8C15A.9080806@redhat.com>,
	,
	
	,
	<52BD4D8C.1080805@redhat.com>
	,
	<52D9457C.1080504@redhat.com>
Message-ID: 

I am pretty close. I can load Cirros instance on Compute and run nslookup inside it. Everything is fine with IP's and routing. However , i cannot connect via ssh to both Cirros and Fedora 19 instances. Might it be gre tunnelling issue ? Details :-

On Controller :-

[root at ip-192-169-142-57 ~(keystone_admin)]$ neutron security-group-rule-create --protocol tcp \
>   --port-range-min 22 --port-range-max 22 \
>   --direction ingress --remote-ip-prefix 0.0.0.0/0 default
Multiple security_group matches found for name 'default', use an ID to be more specific.

[root at ip-192-169-142-57 ~(keystone_admin)]$ neutron security-group-list

+--------------------------------------+---------+-------------+
| id                                   | name    | description |
+--------------------------------------+---------+-------------+
| a085748d-92c0-40e0-a4c1-bc86935ec0ee | default | default     |
| b6203882-561d-4f7b-9e2e-441c57e83419 | default | default     |
| c70b80d3-f060-4002-af22-6603c745a6cf | default | default     |
+--------------------------------------+---------+-------------+

[root at ip-192-169-142-57 ~(keystone_admin)]$ neutron security-group-rule-create --protocol tcp   --port-range-min 22 --port-range-max 22   --direction ingress --remote-ip-prefix 0.0.0.0/0  a085748d-92c0-40e0-a4c1-bc86935ec0ee
409-{u'NeutronError': {u'message': u'Security group rule already exists. Group id is 6d15d6cc-ed13-4c26-89ff-7ff10e6c4656.', u'type': u'SecurityGroupRuleExists', u'detail': u''}}

[root at ip-192-169-142-57 ~(keystone_admin)]$ neutron security-group-rule-create --protocol tcp   --port-range-min 22 --port-range-max 22   --direction ingress --remote-ip-prefix 0.0.0.0/0  b6203882-561d-4f7b-9e2e-441c57e83419
Created a new security_group_rule:

+-------------------+--------------------------------------+
| Field             | Value                                |
+-------------------+--------------------------------------+
| direction         | ingress                              |
| ethertype         | IPv4                                 |
| id                | 97232fb3-6ba1-46a3-a8e3-2f25ba0c70dc |
| port_range_max    | 22                                   |
| port_range_min    | 22                                   |
| protocol          | tcp                                  |
| remote_group_id   |                                      |
| remote_ip_prefix  | 0.0.0.0/0                            |
| security_group_id | b6203882-561d-4f7b-9e2e-441c57e83419 |
| tenant_id         | 751cda6ede504ccd9562edd233b32b34     |
+-------------------+--------------------------------------+

[root at ip-192-169-142-57 ~(keystone_admin)]$ neutron floatingip-show \
3d40ed62-ad78-4042-8342-9f76c419c8c1

+---------------------+--------------------------------------+
| Field               | Value                                |
+---------------------+--------------------------------------+
| fixed_ip_address    | 10.0.0.2                             |
| floating_ip_address | 192.169.142.105                      |
| floating_network_id | 8e2df372-544d-4921-ad58-e164e5128410 |
| id                  | 3d40ed62-ad78-4042-8342-9f76c419c8c1 |
| port_id             | 41da6b37-dfd8-49a2-8dae-45d9a99ef7d7 |
| router_id           | ba157037-747e-4a44-84d5-13d7d30e88ac |
| tenant_id           | 751cda6ede504ccd9562edd233b32b34     |
+---------------------+--------------------------------------+



[root at ip-192-169-142-57 ~(keystone_admin)]$ ssh -l fedora -i oskey1.priv 192.169.142.105

Hangs

I double checked iptables on compute  node . It's OK



> Date: Fri, 17 Jan 2014 16:00:12 +0100
> From: kchamart at redhat.com
> To: bderzhavets at hotmail.com
> CC: rdo-list at redhat.com
> Subject: Re: [Rdo-list] Attempt to reproduce Getting Started with Multi-Node OpenStack RDO Havana + Gluster Backend + Neutron VLAN by Andrew Lau on F20 (2)
> 
> On 01/16/2014 08:48 PM, Boris Derzhavets wrote:
> > Trying to reproduce :
> >  http://kashyapc.fedorapeople.org/virt/openstack/Two-node-Havana-setup.txt   
> 
> Please note: this guide needs some more editing, it's more handy if one
> is at-least moderately aware what's going under the hood and can
> diagnose any network/routing problems.
> 
> Also I was experimenting w/ Neutron/GRE when I wrote the above - which
> doesn't require two interfaces.
> 
> 
> -- 
> /kashyap
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From kchamart at redhat.com  Tue Jan 21 16:13:30 2014
From: kchamart at redhat.com (Kashyap Chamarthy)
Date: Tue, 21 Jan 2014 17:13:30 +0100
Subject: [Rdo-list] openstack-foreman-installer and an 'all-in-one'.
In-Reply-To: 
References: 
Message-ID: <52DE9CAA.7050707@redhat.com>

On 01/20/2014 09:08 PM, Kit Plummer wrote:
> Hey guys.  I caught a comment in IRC that PackStack was being deprecated in favor of a Foreman managed setup 

AFAIK, it won't be right away.

> - so I?m curious if it is possible to create an ?all-in-one? environment using Foreman.  Any ideas/thoughts?

I'm not a Foreman developer, but you can take a look at some work in
progress here re: configuring OpenStack with Foreman:

  https://github.com/redhat-openstack/astapor/



-- 
/kashyap



From kchamart at redhat.com  Tue Jan 21 17:25:13 2014
From: kchamart at redhat.com (Kashyap Chamarthy)
Date: Tue, 21 Jan 2014 18:25:13 +0100
Subject: [Rdo-list] Attempt to reproduce Kashyap Setup
 (Controller+Compute) on F20 is almost done
In-Reply-To: 
References: 
	<52B8C15A.9080806@redhat.com>,
	,
	
	,
	<52BD4D8C.1080805@redhat.com>
	,
	<52D9457C.1080504@redhat.com>
	
Message-ID: <52DEAD79.3090008@redhat.com>

[Please don't top-post on technical lists.]

On 01/21/2014 12:01 PM, Boris Derzhavets wrote:
> I am pretty close. I can load Cirros instance on Compute and run nslookup inside it. Everything is fine with IP's and routing. However , i cannot connect via ssh to both Cirros and Fedora 19 instances. Might it be gre tunnelling issue ? Details :-

If it's GRE tunnelling issues, ensure you have the GRE related iptables
rules on both Controller and Compute nodes:

  -A INPUT -p gre -j ACCEPT
  -A OUTPUT -p gre -j ACCEPT

(You said - "double checked iptables", but didn't mention specifics.)


Here's my working Neutron configs w/ F20+Havana set-up (might need some
tiny tweaking if you have latest RDO Ice House packages).


http://kashyapc.fedorapeople.org/virt/openstack/neutron-configs-GRE-OVS-two-node.txt


> 
> On Controller :-
> 
> [root at ip-192-169-142-57 ~(keystone_admin)]$ neutron security-group-rule-create --protocol tcp \
>>   --port-range-min 22 --port-range-max 22 \
>>   --direction ingress --remote-ip-prefix 0.0.0.0/0 default
> Multiple security_group matches found for name 'default', use an ID to be more specific.
> 
> [root at ip-192-169-142-57 ~(keystone_admin)]$ neutron security-group-list
> 
> +--------------------------------------+---------+-------------+
> | id                                   | name    | description |
> +--------------------------------------+---------+-------------+
> | a085748d-92c0-40e0-a4c1-bc86935ec0ee | default | default     |
> | b6203882-561d-4f7b-9e2e-441c57e83419 | default | default     |
> | c70b80d3-f060-4002-af22-6603c745a6cf | default | default     |
> +--------------------------------------+---------+-------------+
> 
> [root at ip-192-169-142-57 ~(keystone_admin)]$ neutron security-group-rule-create --protocol tcp   --port-range-min 22 --port-range-max 22   --direction ingress --remote-ip-prefix 0.0.0.0/0  a085748d-92c0-40e0-a4c1-bc86935ec0ee
> 409-{u'NeutronError': {u'message': u'Security group rule already exists. Group id is 6d15d6cc-ed13-4c26-89ff-7ff10e6c4656.', u'type': u'SecurityGroupRuleExists', u'detail': u''}}
> 
> [root at ip-192-169-142-57 ~(keystone_admin)]$ neutron security-group-rule-create --protocol tcp   --port-range-min 22 --port-range-max 22   --direction ingress --remote-ip-prefix 0.0.0.0/0  b6203882-561d-4f7b-9e2e-441c57e83419
> Created a new security_group_rule:
> 
> +-------------------+--------------------------------------+
> | Field             | Value                                |
> +-------------------+--------------------------------------+
> | direction         | ingress                              |
> | ethertype         | IPv4                                 |
> | id                | 97232fb3-6ba1-46a3-a8e3-2f25ba0c70dc |
> | port_range_max    | 22                                   |
> | port_range_min    | 22                                   |
> | protocol          | tcp                                  |
> | remote_group_id   |                                      |
> | remote_ip_prefix  | 0.0.0.0/0                            |
> | security_group_id | b6203882-561d-4f7b-9e2e-441c57e83419 |
> | tenant_id         | 751cda6ede504ccd9562edd233b32b34     |
> +-------------------+--------------------------------------+
> 
> [root at ip-192-169-142-57 ~(keystone_admin)]$ neutron floatingip-show \
> 3d40ed62-ad78-4042-8342-9f76c419c8c1
> 
> +---------------------+--------------------------------------+
> | Field               | Value                                |
> +---------------------+--------------------------------------+
> | fixed_ip_address    | 10.0.0.2                             |
> | floating_ip_address | 192.169.142.105                      |
> | floating_network_id | 8e2df372-544d-4921-ad58-e164e5128410 |
> | id                  | 3d40ed62-ad78-4042-8342-9f76c419c8c1 |
> | port_id             | 41da6b37-dfd8-49a2-8dae-45d9a99ef7d7 |
> | router_id           | ba157037-747e-4a44-84d5-13d7d30e88ac |
> | tenant_id           | 751cda6ede504ccd9562edd233b32b34     |
> +---------------------+--------------------------------------+
> 
> 
> 
> [root at ip-192-169-142-57 ~(keystone_admin)]$ ssh -l fedora -i oskey1.priv 192.169.142.105
> 
> Hangs

> 
> I double checked iptables on compute  node . It's OK

-- 
/kashyap



From bderzhavets at hotmail.com  Tue Jan 21 14:16:12 2014
From: bderzhavets at hotmail.com (Boris Derzhavets)
Date: Tue, 21 Jan 2014 09:16:12 -0500
Subject: [Rdo-list] Attempt to reproduce Kashyap Setup
 (Controller+Compute) on F20 is almost done
In-Reply-To: <52DEAD79.3090008@redhat.com>
References: 
	<52B8C15A.9080806@redhat.com>,
	,
	
	,
	<52BD4D8C.1080805@redhat.com>
	,
	<52D9457C.1080504@redhat.com>
	,
	<52DEAD79.3090008@redhat.com>
Message-ID: 

It's there. I checked one more time. I work with native f20 repos.

> Date: Tue, 21 Jan 2014 18:25:13 +0100
> From: kchamart at redhat.com
> To: bderzhavets at hotmail.com
> CC: rdo-list at redhat.com
> Subject: Re: Attempt to reproduce Kashyap Setup (Controller+Compute) on F20 is almost done
> 
> [Please don't top-post on technical lists.]
> 
> On 01/21/2014 12:01 PM, Boris Derzhavets wrote:
> > I am pretty close. I can load Cirros instance on Compute and run nslookup inside it. Everything is fine with IP's and routing. However , i cannot connect via ssh to both Cirros and Fedora 19 instances. Might it be gre tunnelling issue ? Details :-
> 
> If it's GRE tunnelling issues, ensure you have the GRE related iptables
> rules on both Controller and Compute nodes:
> 
>   -A INPUT -p gre -j ACCEPT
>   -A OUTPUT -p gre -j ACCEPT
> 
> (You said - "double checked iptables", but didn't mention specifics.)
> 
> 
> Here's my working Neutron configs w/ F20+Havana set-up (might need some
> tiny tweaking if you have latest RDO Ice House packages).
> 
> 
> http://kashyapc.fedorapeople.org/virt/openstack/neutron-configs-GRE-OVS-two-node.txt
> 
> 
> > 
> > On Controller :-
> > 
> > [root at ip-192-169-142-57 ~(keystone_admin)]$ neutron security-group-rule-create --protocol tcp \
> >>   --port-range-min 22 --port-range-max 22 \
> >>   --direction ingress --remote-ip-prefix 0.0.0.0/0 default
> > Multiple security_group matches found for name 'default', use an ID to be more specific.
> > 
> > [root at ip-192-169-142-57 ~(keystone_admin)]$ neutron security-group-list
> > 
> > +--------------------------------------+---------+-------------+
> > | id                                   | name    | description |
> > +--------------------------------------+---------+-------------+
> > | a085748d-92c0-40e0-a4c1-bc86935ec0ee | default | default     |
> > | b6203882-561d-4f7b-9e2e-441c57e83419 | default | default     |
> > | c70b80d3-f060-4002-af22-6603c745a6cf | default | default     |
> > +--------------------------------------+---------+-------------+
> > 
> > [root at ip-192-169-142-57 ~(keystone_admin)]$ neutron security-group-rule-create --protocol tcp   --port-range-min 22 --port-range-max 22   --direction ingress --remote-ip-prefix 0.0.0.0/0  a085748d-92c0-40e0-a4c1-bc86935ec0ee
> > 409-{u'NeutronError': {u'message': u'Security group rule already exists. Group id is 6d15d6cc-ed13-4c26-89ff-7ff10e6c4656.', u'type': u'SecurityGroupRuleExists', u'detail': u''}}
> > 
> > [root at ip-192-169-142-57 ~(keystone_admin)]$ neutron security-group-rule-create --protocol tcp   --port-range-min 22 --port-range-max 22   --direction ingress --remote-ip-prefix 0.0.0.0/0  b6203882-561d-4f7b-9e2e-441c57e83419
> > Created a new security_group_rule:
> > 
> > +-------------------+--------------------------------------+
> > | Field             | Value                                |
> > +-------------------+--------------------------------------+
> > | direction         | ingress                              |
> > | ethertype         | IPv4                                 |
> > | id                | 97232fb3-6ba1-46a3-a8e3-2f25ba0c70dc |
> > | port_range_max    | 22                                   |
> > | port_range_min    | 22                                   |
> > | protocol          | tcp                                  |
> > | remote_group_id   |                                      |
> > | remote_ip_prefix  | 0.0.0.0/0                            |
> > | security_group_id | b6203882-561d-4f7b-9e2e-441c57e83419 |
> > | tenant_id         | 751cda6ede504ccd9562edd233b32b34     |
> > +-------------------+--------------------------------------+
> > 
> > [root at ip-192-169-142-57 ~(keystone_admin)]$ neutron floatingip-show \
> > 3d40ed62-ad78-4042-8342-9f76c419c8c1
> > 
> > +---------------------+--------------------------------------+
> > | Field               | Value                                |
> > +---------------------+--------------------------------------+
> > | fixed_ip_address    | 10.0.0.2                             |
> > | floating_ip_address | 192.169.142.105                      |
> > | floating_network_id | 8e2df372-544d-4921-ad58-e164e5128410 |
> > | id                  | 3d40ed62-ad78-4042-8342-9f76c419c8c1 |
> > | port_id             | 41da6b37-dfd8-49a2-8dae-45d9a99ef7d7 |
> > | router_id           | ba157037-747e-4a44-84d5-13d7d30e88ac |
> > | tenant_id           | 751cda6ede504ccd9562edd233b32b34     |
> > +---------------------+--------------------------------------+
> > 
> > 
> > 
> > [root at ip-192-169-142-57 ~(keystone_admin)]$ ssh -l fedora -i oskey1.priv 192.169.142.105
> > 
> > Hangs
> 
> > 
> > I double checked iptables on compute  node . It's OK
> 
> -- 
> /kashyap
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rbowen at redhat.com  Tue Jan 21 14:48:25 2014
From: rbowen at redhat.com (Rich Bowen)
Date: Tue, 21 Jan 2014 09:48:25 -0500
Subject: [Rdo-list] RDO community meeting, minutes
Message-ID: <52DE88B9.4080307@redhat.com>

This morning we had a IRC meeting about some of the things going on in 
the RDO community. You can read the notes from that meeting at 
http://meetbot.fedoraproject.org/rdo/2014-01-21/rdo_community_sync.2014-01-21-14.03.html 
and the full meeting log at 
http://meetbot.fedoraproject.org/rdo/2014-01-21/rdo_community_sync.2014-01-21-14.03.log.html

Please respond here if you have any further comments on what was 
discussed this morning. Thanks!

--rcb

-- 
Rich Bowen - rbowen at redhat.com
OpenStack Community Liaison
http://openstack.redhat.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From daniel at speichert.pl  Tue Jan 21 15:15:11 2014
From: daniel at speichert.pl (Daniel Speichert)
Date: Tue, 21 Jan 2014 16:15:11 +0100 (CET)
Subject: [Rdo-list] Installing Heat from RDO - dependency error
In-Reply-To: <9721549.57.1390317203412.JavaMail.Daniel@Daniel-PC>
Message-ID: <31154292.58.1390317254001.JavaMail.Daniel@Daniel-PC>

Hello,
I am installing Heat service according to the guide from RDO website:http://openstack.redhat.com/Deploy_Heat_and_launch_your_first_Application

All packages install fine except for the last one: openstack-heat-templates. The package it depends on is just not in any repositories (CentOS, EPEL or OpenStack Havana RDO).

Error: Package: openstack-heat-templates-0-0.1.20140106git.el6.noarch (openstack-havana)
           Requires: libvirt-daemon

Does anybody know how to fix this issue?

OS: CentOS release 6.5 (Final)
REPO LIST:
repo id                               repo name                            
base                                  CentOS-6 - Base                    
ceph                                  Ceph Repos
ceph-extras                           Ceph Extra Packages and Backports x86_64
ceph-extras-noarch                    Ceph Extra Packages and Backports noarch
ceph-extras-source                    Ceph Extra Packages and Backports Sources
epel                                  Extra Packages for Enterprise Linux 6 - x86_64
extras                                CentOS-6 - Extras        
foreman                               Foreman stable                    
foreman-plugins                       Foreman stable - plugins             
openstack-havana                      OpenStack Havana Repository     
puppetlabs-deps                       Puppet Labs Dependencies El 6 - x86_64       
puppetlabs-products                   Puppet Labs Products El 6 - x86_64       
updates                               CentOS-6 - Updates

Thanks!

Daniel



From pbrady at redhat.com  Tue Jan 21 15:39:58 2014
From: pbrady at redhat.com (=?ISO-8859-1?Q?P=E1draig_Brady?=)
Date: Tue, 21 Jan 2014 15:39:58 +0000
Subject: [Rdo-list] Installing Heat from RDO - dependency error
In-Reply-To: <31154292.58.1390317254001.JavaMail.Daniel@Daniel-PC>
References: <31154292.58.1390317254001.JavaMail.Daniel@Daniel-PC>
Message-ID: <52DE94CE.9030306@redhat.com>

On 01/21/2014 03:15 PM, Daniel Speichert wrote:
> Hello,
> I am installing Heat service according to the guide from RDO website:http://openstack.redhat.com/Deploy_Heat_and_launch_your_first_Application
> 
> All packages install fine except for the last one: openstack-heat-templates. The package it depends on is just not in any repositories (CentOS, EPEL or OpenStack Havana RDO).
> 
> Error: Package: openstack-heat-templates-0-0.1.20140106git.el6.noarch (openstack-havana)
>            Requires: libvirt-daemon

That is a bug in the package.
It should depend on libvirt on el6 branches.

> Does anybody know how to fix this issue?

I would ensure that libvirt is installed and install the templates using the rpm --nodeps option.
We'll regenerate an el6 rpm with the correct dependencies now.

thanks for the report,
P?draig.



From morazi at redhat.com  Tue Jan 21 15:46:03 2014
From: morazi at redhat.com (Mike Orazi)
Date: Tue, 21 Jan 2014 10:46:03 -0500
Subject: [Rdo-list] openstack-foreman-installer and an 'all-in-one'.
In-Reply-To: 
References: 
Message-ID: <52DE963B.2060807@redhat.com>

On 01/20/2014 03:08 PM, Kit Plummer wrote:
> Hey guys.  I caught a comment in IRC that PackStack was being deprecated
> in favor of a Foreman managed setup - so I?m curious if it is possible
> to create an ?all-in-one? environment using Foreman.  Any ideas/thoughts?
> 
> Thanks in advance.
> Kit
> 
> 
> _______________________________________________
> Rdo-list mailing list
> Rdo-list at redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list
> 

Kit,

A tracker bug exists:  https://bugzilla.redhat.com/show_bug.cgi?id=1047277

I tentatively put it in the A3 bucket, but I think it really needs to be
part of a larger PM discussion in terms of prioritization so it might
shift around.

Thanks,
Mike



From lars at redhat.com  Tue Jan 21 16:27:05 2014
From: lars at redhat.com (Lars Kellogg-Stedman)
Date: Tue, 21 Jan 2014 11:27:05 -0500
Subject: [Rdo-list] CentOS 6.5 Guest image file available now
In-Reply-To: <52DDAB46.1000804@karan.org>
References: <52D96F90.6060207@redhat.com> <52D9ACB4.50604@karan.org>
	<52DB1189.2090308@redhat.com>
	<20140120185256.GE28994@jbp-laptop.localdomain>
	<52DD71F2.3050708@redhat.com> <52DDAB46.1000804@karan.org>
Message-ID: <20140121162704.GA8216@redhat.com>

On Mon, Jan 20, 2014 at 11:03:34PM +0000, Karanbir Singh wrote:
> How 'production' is this repo :
> http://repos.fedorapeople.org/repos/openstack/cloud-init/epel-6
> 
> wouldnt it be worth upgrading the cloud-init in EPEL ?

There's is talk on centos-devel (and irc, right now, in #fedora-cloud)
about trying to bring sanity to cloud-init across the various
distributions (and about bumping the cloud-init version in EPEL).

-- 
Lars Kellogg-Stedman  | larsks @ irc
Cloud Engineering / OpenStack          | "   "  @ twitter

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 

From rbowen at redhat.com  Tue Jan 21 16:51:53 2014
From: rbowen at redhat.com (Rich Bowen)
Date: Tue, 21 Jan 2014 11:51:53 -0500
Subject: [Rdo-list] RDO community events - Google calendar
Message-ID: <52DEA5A9.8000902@redhat.com>

For those of you who run your life via Google calendar (or other 
calendar software), I've created an RDO Community Google calendar.

If you use Google Calendar, you can paste the following into the entry 
box under "Other calendars" where it says "Add a friend's calendar" -  
6m0up994frfg2td6dpmubtn31s at group.calendar.google.com

If you use some other calendaring software, you can subscribe using the 
ICS address: 
http://www.google.com/calendar/ical/6m0up994frfg2td6dpmubtn31s%40group.calendar.google.com/public/basic.ics

At the moment, there's very little in there, but I'll be adding things 
over the next few days.

Thanks!


-- 
Rich Bowen - rbowen at redhat.com
OpenStack Community Liaison
http://openstack.redhat.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mburns at redhat.com  Wed Jan 22 17:05:01 2014
From: mburns at redhat.com (Mike Burns)
Date: Wed, 22 Jan 2014 12:05:01 -0500
Subject: [Rdo-list] RDO Bug triage efforts
Message-ID: <52DFFA3D.5040606@redhat.com>

As part of the effort to triage bugs filed against RDO components, we're 
trying come up with sane default assignees for each component. 
Currently, most bugs get assigned to "RHOS Maint" by default which means 
that the right people aren't getting notified automatically.

We do have other efforts going to try to get a consistent process for 
RDO bugs in place, but that will come a little later.

What we would like to do is have people update a wiki page[1] with a 
default contact for each component and anyone you want to get cc'ed on 
bug updates.  Once we have contacts for each component, I'll coordinate 
with the bugzilla team to apply the changes to bugzilla.

Thanks in advance for helping to fill out this page.

Mike

[1] http://openstack.redhat.com/Bugzilla_ownership



From mburns at redhat.com  Wed Jan 22 17:12:25 2014
From: mburns at redhat.com (Mike Burns)
Date: Wed, 22 Jan 2014 12:12:25 -0500
Subject: [Rdo-list] CentOS Cloud Sig efforts
Message-ID: <52DFFBF9.1060508@redhat.com>

There is a meeting scheduled with the CentOS community on Thursday this 
week to work out some of the details of the new Cloud SIG.  Anyone 
interested is welcome to attend (meeting details are below).  Rich and I 
will be representing the RDO community, and we wanted to reach out to 
make sure we cover everything that we want to get out of the new SIG. 
Current things we know we want:

* place to deliver common packages like kernel, kvm, etc
* variant that includes RDO packages
* ability to build and deliver CentOS based LiveCD images that contain 
RDO code
* ability to build and deliver CentOS based guest images
* ability to build and deliver RDO packages
* Ability to produce custom install media with RDO branding

Please let us know if there are any other things that I'm missing or 
that you think should be included.

Thanks

Mike


-- 

Meeting details:

I'd like to invite everyone wanting to contribute to the Cloud SIG and
representing a project outside centos.org to come along for a chat on
google hangout at the CentOS OfficeHours 23rd Jan 2014 @ 16:00 UTC.

Because we only have a few slots for people to talk, I've shortlisted
these folks:

OpenStack: Mike Burns, Dave Neary, Rich Bowen
Eucalyptus: Greg DK
OpenNebula: Jaime Melis
CloudStack: Sebastien Goasguen
oVirt: Doron Fediuck

If you want to be on this list, please get in touch. If you are on this
list but cant make it at that date/time, please nominate someone else in
your place and let me know their email address so I can notify them of
the url to join.

This will be a video/audio session and will be publicly broadcast over
youtube/hangouts on air; the recording of the session will be available
immediately after. Bonus cookies for everyone who turns up in their
project tshirts!

You can see what time that is on your local timezone at this url :
http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140123T16&am=30

About the session:
- Plan on an hour
- Every project should do a few minutes worth of a pitch about what they
would like to see as a good first goal and a good longer term goal.
- We can then discuss delivery mechanis, and how the forward maintenance
of the projects payload is going to work ( essentially, workout how the
rpms will map to os/ and updates/ )
- Consider the workflow from git.centos.org ( KB to do a 5 min demo )



From Tim.Bell at cern.ch  Wed Jan 22 17:21:22 2014
From: Tim.Bell at cern.ch (Tim Bell)
Date: Wed, 22 Jan 2014 17:21:22 +0000
Subject: [Rdo-list] CentOS Cloud Sig efforts
In-Reply-To: <52DFFBF9.1060508@redhat.com>
References: <52DFFBF9.1060508@redhat.com>
Message-ID: <5D7F9996EA547448BC6C54C8C5AAF4E5D995EEF8@CERNXCHG02.cern.ch>


Will it also include the good levels of mongodb and the various python libraries ?

It would also be great to have images that could be used inside RDO (i.e. RDO on RDO).

Is CentOS also planning on producing an OpenStack compatible image which can just be uploaded to Glance as part of their standard deliverable?

Tim

> -----Original Message-----
> From: rdo-list-bounces at redhat.com [mailto:rdo-list-bounces at redhat.com] On Behalf Of Mike Burns
> Sent: 22 January 2014 18:12
> To: rdo-list
> Subject: [Rdo-list] CentOS Cloud Sig efforts
> 
> There is a meeting scheduled with the CentOS community on Thursday this week to work out some of the details of the new Cloud SIG.
> Anyone interested is welcome to attend (meeting details are below).  Rich and I will be representing the RDO community, and we wanted
> to reach out to make sure we cover everything that we want to get out of the new SIG.
> Current things we know we want:
> 
> * place to deliver common packages like kernel, kvm, etc
> * variant that includes RDO packages
> * ability to build and deliver CentOS based LiveCD images that contain RDO code
> * ability to build and deliver CentOS based guest images
> * ability to build and deliver RDO packages
> * Ability to produce custom install media with RDO branding
> 
> Please let us know if there are any other things that I'm missing or that you think should be included.
> 
> Thanks
> 
> Mike
> 
> 
> --
> 
> Meeting details:
> 
> I'd like to invite everyone wanting to contribute to the Cloud SIG and representing a project outside centos.org to come along for a chat on
> google hangout at the CentOS OfficeHours 23rd Jan 2014 @ 16:00 UTC.
> 
> Because we only have a few slots for people to talk, I've shortlisted these folks:
> 
> OpenStack: Mike Burns, Dave Neary, Rich Bowen
> Eucalyptus: Greg DK
> OpenNebula: Jaime Melis
> CloudStack: Sebastien Goasguen
> oVirt: Doron Fediuck
> 
> If you want to be on this list, please get in touch. If you are on this list but cant make it at that date/time, please nominate someone else in
> your place and let me know their email address so I can notify them of the url to join.
> 
> This will be a video/audio session and will be publicly broadcast over youtube/hangouts on air; the recording of the session will be
> available immediately after. Bonus cookies for everyone who turns up in their project tshirts!
> 
> You can see what time that is on your local timezone at this url :
> http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140123T16&am=30
> 
> About the session:
> - Plan on an hour
> - Every project should do a few minutes worth of a pitch about what they would like to see as a good first goal and a good longer term
> goal.
> - We can then discuss delivery mechanis, and how the forward maintenance of the projects payload is going to work ( essentially, workout
> how the rpms will map to os/ and updates/ )
> - Consider the workflow from git.centos.org ( KB to do a 5 min demo )
> 
> _______________________________________________
> Rdo-list mailing list
> Rdo-list at redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list



From mburns at redhat.com  Wed Jan 22 17:25:39 2014
From: mburns at redhat.com (Mike Burns)
Date: Wed, 22 Jan 2014 12:25:39 -0500
Subject: [Rdo-list] CentOS Cloud Sig efforts
In-Reply-To: <5D7F9996EA547448BC6C54C8C5AAF4E5D995EEF8@CERNXCHG02.cern.ch>
References: <52DFFBF9.1060508@redhat.com>
	<5D7F9996EA547448BC6C54C8C5AAF4E5D995EEF8@CERNXCHG02.cern.ch>
Message-ID: <52DFFF13.30804@redhat.com>

On 01/22/2014 12:21 PM, Tim Bell wrote:
>
> Will it also include the good levels of mongodb and the various
> python libraries ?

I would assume that if there is desire for these across other projects 
it would land in the same place as things like a newer/more functional 
kernel.  If it's RDO specific, then it would probably have to go in our 
variant, but I'll make a note to include python libs and mongodb in my 
list of packages.

>
> It would also be great to have images that could be used inside RDO
> (i.e. RDO on RDO).

Is this the triple-O stuff? or something else.

>
> Is CentOS also planning on producing an OpenStack compatible image
> which can just be uploaded to Glance as part of their standard
> deliverable?

That's a goal in my mind.  We've produced a 6.5 CentOS image that can be 
used in OpenStack now [1], but we hope to have the SIG take ownership of 
that image longterm.

Mike

[1] http://repos.fedorapeople.org/repos/openstack/guest-images/

>
> Tim
>
>> -----Original Message----- From: rdo-list-bounces at redhat.com
>> [mailto:rdo-list-bounces at redhat.com] On Behalf Of Mike Burns Sent:
>> 22 January 2014 18:12 To: rdo-list Subject: [Rdo-list] CentOS Cloud
>> Sig efforts
>>
>> There is a meeting scheduled with the CentOS community on Thursday
>> this week to work out some of the details of the new Cloud SIG.
>> Anyone interested is welcome to attend (meeting details are below).
>> Rich and I will be representing the RDO community, and we wanted to
>> reach out to make sure we cover everything that we want to get out
>> of the new SIG. Current things we know we want:
>>
>> * place to deliver common packages like kernel, kvm, etc * variant
>> that includes RDO packages * ability to build and deliver CentOS
>> based LiveCD images that contain RDO code * ability to build and
>> deliver CentOS based guest images * ability to build and deliver
>> RDO packages * Ability to produce custom install media with RDO
>> branding
>>
>> Please let us know if there are any other things that I'm missing
>> or that you think should be included.
>>
>> Thanks
>>
>> Mike
>>
>>
>> --
>>
>> Meeting details:
>>
>> I'd like to invite everyone wanting to contribute to the Cloud SIG
>> and representing a project outside centos.org to come along for a
>> chat on google hangout at the CentOS OfficeHours 23rd Jan 2014 @
>> 16:00 UTC.
>>
>> Because we only have a few slots for people to talk, I've
>> shortlisted these folks:
>>
>> OpenStack: Mike Burns, Dave Neary, Rich Bowen Eucalyptus: Greg DK
>> OpenNebula: Jaime Melis CloudStack: Sebastien Goasguen oVirt: Doron
>> Fediuck
>>
>> If you want to be on this list, please get in touch. If you are on
>> this list but cant make it at that date/time, please nominate
>> someone else in your place and let me know their email address so I
>> can notify them of the url to join.
>>
>> This will be a video/audio session and will be publicly broadcast
>> over youtube/hangouts on air; the recording of the session will be
>> available immediately after. Bonus cookies for everyone who turns
>> up in their project tshirts!
>>
>> You can see what time that is on your local timezone at this url :
>> http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140123T16&am=30
>>
>>
>>
About the session:
>> - Plan on an hour - Every project should do a few minutes worth of
>> a pitch about what they would like to see as a good first goal and
>> a good longer term goal. - We can then discuss delivery mechanis,
>> and how the forward maintenance of the projects payload is going to
>> work ( essentially, workout how the rpms will map to os/ and
>> updates/ ) - Consider the workflow from git.centos.org ( KB to do a
>> 5 min demo )
>>
>> _______________________________________________ Rdo-list mailing
>> list Rdo-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/rdo-list
>
> _______________________________________________ Rdo-list mailing
> list Rdo-list at redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list
>



From Tim.Bell at cern.ch  Wed Jan 22 18:09:54 2014
From: Tim.Bell at cern.ch (Tim Bell)
Date: Wed, 22 Jan 2014 18:09:54 +0000
Subject: [Rdo-list] CentOS Cloud Sig efforts
In-Reply-To: <52DFFF13.30804@redhat.com>
References: <52DFFBF9.1060508@redhat.com>
	<5D7F9996EA547448BC6C54C8C5AAF4E5D995EEF8@CERNXCHG02.cern.ch>
	<52DFFF13.30804@redhat.com>
Message-ID: <5D7F9996EA547448BC6C54C8C5AAF4E5D995F251@CERNXCHG02.cern.ch>


> -----Original Message-----
> From: Mike Burns [mailto:mburns at redhat.com]
> Sent: 22 January 2014 18:26
> To: Tim Bell; rdo-list
> Subject: Re: [Rdo-list] CentOS Cloud Sig efforts
> >
> > It would also be great to have images that could be used inside RDO
> > (i.e. RDO on RDO).
> 
> Is this the triple-O stuff? or something else.
> 

This is much simpler .. we do lots of work at CERN by running RDO on top of our OpenStack instance. However, thinking it through a bit, this doesn't work as different parameters are needed for packstack. Please ignore this item.

Tim



From rbowen at redhat.com  Thu Jan 23 14:28:50 2014
From: rbowen at redhat.com (Rich Bowen)
Date: Thu, 23 Jan 2014 09:28:50 -0500
Subject: [Rdo-list] CentOS Cloud Sig efforts
In-Reply-To: <5D7F9996EA547448BC6C54C8C5AAF4E5D995EEF8@CERNXCHG02.cern.ch>
References: <52DFFBF9.1060508@redhat.com>
	<5D7F9996EA547448BC6C54C8C5AAF4E5D995EEF8@CERNXCHG02.cern.ch>
Message-ID: <52E12722.9060506@redhat.com>


On 01/22/2014 12:21 PM, Tim Bell wrote:
> Will it also include the good levels of mongodb and the various python libraries ?

We need mongodb for ceilometer, so, yeah, that should be in there.


>
> It would also be great to have images that could be used inside RDO (i.e. RDO on RDO).
>
> Is CentOS also planning on producing an OpenStack compatible image which can just be uploaded to Glance as part of their standard deliverable?
>
> Tim
>
>> -----Original Message-----
>> From: rdo-list-bounces at redhat.com [mailto:rdo-list-bounces at redhat.com] On Behalf Of Mike Burns
>> Sent: 22 January 2014 18:12
>> To: rdo-list
>> Subject: [Rdo-list] CentOS Cloud Sig efforts
>>
>> There is a meeting scheduled with the CentOS community on Thursday this week to work out some of the details of the new Cloud SIG.
>> Anyone interested is welcome to attend (meeting details are below).  Rich and I will be representing the RDO community, and we wanted
>> to reach out to make sure we cover everything that we want to get out of the new SIG.
>> Current things we know we want:
>>
>> * place to deliver common packages like kernel, kvm, etc
>> * variant that includes RDO packages
>> * ability to build and deliver CentOS based LiveCD images that contain RDO code
>> * ability to build and deliver CentOS based guest images
>> * ability to build and deliver RDO packages
>> * Ability to produce custom install media with RDO branding
>>
>> Please let us know if there are any other things that I'm missing or that you think should be included.
>>
>> Thanks
>>
>> Mike
>>
>>
>> --
>>
>> Meeting details:
>>
>> I'd like to invite everyone wanting to contribute to the Cloud SIG and representing a project outside centos.org to come along for a chat on
>> google hangout at the CentOS OfficeHours 23rd Jan 2014 @ 16:00 UTC.
>>
>> Because we only have a few slots for people to talk, I've shortlisted these folks:
>>
>> OpenStack: Mike Burns, Dave Neary, Rich Bowen
>> Eucalyptus: Greg DK
>> OpenNebula: Jaime Melis
>> CloudStack: Sebastien Goasguen
>> oVirt: Doron Fediuck
>>
>> If you want to be on this list, please get in touch. If you are on this list but cant make it at that date/time, please nominate someone else in
>> your place and let me know their email address so I can notify them of the url to join.
>>
>> This will be a video/audio session and will be publicly broadcast over youtube/hangouts on air; the recording of the session will be
>> available immediately after. Bonus cookies for everyone who turns up in their project tshirts!
>>
>> You can see what time that is on your local timezone at this url :
>> http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140123T16&am=30
>>
>> About the session:
>> - Plan on an hour
>> - Every project should do a few minutes worth of a pitch about what they would like to see as a good first goal and a good longer term
>> goal.
>> - We can then discuss delivery mechanis, and how the forward maintenance of the projects payload is going to work ( essentially, workout
>> how the rpms will map to os/ and updates/ )
>> - Consider the workflow from git.centos.org ( KB to do a 5 min demo )
>>
>> _______________________________________________
>> Rdo-list mailing list
>> Rdo-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/rdo-list
> _______________________________________________
> Rdo-list mailing list
> Rdo-list at redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list

-- 
Rich Bowen - rbowen at redhat.com
OpenStack Community Liaison
http://openstack.redhat.com/



From mburns at redhat.com  Thu Jan 23 15:49:45 2014
From: mburns at redhat.com (Mike Burns)
Date: Thu, 23 Jan 2014 10:49:45 -0500
Subject: [Rdo-list] CentOS Cloud Sig efforts
In-Reply-To: <52DFFBF9.1060508@redhat.com>
References: <52DFFBF9.1060508@redhat.com>
Message-ID: <52E13A19.3090801@redhat.com>

On 01/22/2014 12:12 PM, Mike Burns wrote:
> There is a meeting scheduled with the CentOS community on Thursday this
> week to work out some of the details of the new Cloud SIG.  Anyone
> interested is welcome to attend (meeting details are below).  Rich and I
> will be representing the RDO community, and we wanted to reach out to
> make sure we cover everything that we want to get out of the new SIG.
> Current things we know we want:
>
> * place to deliver common packages like kernel, kvm, etc
> * variant that includes RDO packages
> * ability to build and deliver CentOS based LiveCD images that contain
> RDO code
> * ability to build and deliver CentOS based guest images
> * ability to build and deliver RDO packages
> * Ability to produce custom install media with RDO branding
>
> Please let us know if there are any other things that I'm missing or
> that you think should be included.
>

Update on the meeting:

To view the meeting:

http://www.youtube.com/watch?v=VKKYY_5SOWw

To ask questions or comment, please see #centos-devel on Freenode

> Thanks
>
> Mike
>
>



From rbowen at redhat.com  Thu Jan 23 18:54:33 2014
From: rbowen at redhat.com (Rich Bowen)
Date: Thu, 23 Jan 2014 13:54:33 -0500
Subject: [Rdo-list] RDO Hangouts: Suggestions/Speakers needed
Message-ID: <52E16569.9070507@redhat.com>

Last year we had two RDO hangouts, both on networking, and these were 
very well received.

We'd like to get this started up again, with hangouts on a variety of 
topics. We've had some suggestions in past threads, but nobody 
volunteering to do the content.

If you're willing to speak for anywhere from 30 to 45 minutes on any 
OpenStack-related topic, please let me know.

Things I'd like to see us do hangouts on include:

* Reporting/Alarming with Ceilometer
* Deploying apps with heat
* Using TryStack
* More stuff about networking, as this continues to be a common pain point
* Icehouse: What's coming
* More advanced deployments with packstack
* ...

I'd also be interested in doing one-on-one hangouts/chats on shorter 
topics (10-15 minutes) if that's more your speed than a broadcast type 
event.

-- 
Rich Bowen - rbowen at redhat.com
OpenStack Community Liaison
http://openstack.redhat.com/



From rdo-info at redhat.com  Thu Jan 23 20:18:08 2014
From: rdo-info at redhat.com (RDO Forum)
Date: Thu, 23 Jan 2014 20:18:08 +0000
Subject: [Rdo-list] [RDO]  Icehouse milestone 2 test day - Feb 4-5
Message-ID: <00000143c0c0aa25-cfd125ed-05aa-4401-9577-1b696ccb0378-000000@email.amazonses.com>

rbowen started a discussion.

Icehouse milestone 2 test day - Feb 4-5

---
Follow the link below to check it out:
http://openstack.redhat.com/forum/discussion/965/icehouse-milestone-2-test-day-feb-4-5

Have a great day!



From rbowen at redhat.com  Thu Jan 23 20:22:07 2014
From: rbowen at redhat.com (Rich Bowen)
Date: Thu, 23 Jan 2014 15:22:07 -0500
Subject: [Rdo-list] Speaker needed: http://colug.net/
Message-ID: <52E179EF.3080000@redhat.com>

CoLUG - http://colug.net/ - the Columbus Linux User Group - is looking 
for someone in the area to come give a talk/presentation/demo of 
OpenStack. Is anyone available to do that?

--Rich

-- 
Rich Bowen - rbowen at redhat.com
OpenStack Community Liaison
http://openstack.redhat.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From pmyers at redhat.com  Thu Jan 23 21:00:08 2014
From: pmyers at redhat.com (Perry Myers)
Date: Thu, 23 Jan 2014 16:00:08 -0500
Subject: [Rdo-list] Speaker needed: http://colug.net/
In-Reply-To: <52E179EF.3080000@redhat.com>
References: <52E179EF.3080000@redhat.com>
Message-ID: <52E182D8.1000401@redhat.com>

On 01/23/2014 03:22 PM, Rich Bowen wrote:
> CoLUG - http://colug.net/ - the Columbus Linux User Group - is looking
> for someone in the area to come give a talk/presentation/demo of
> OpenStack. Is anyone available to do that?

Ah, I'm only 3 hours from Columbus (based in Pittsburgh), but will be
out of town traveling that day.  So the timing doesn't quite work...



From rbowen at redhat.com  Thu Jan 23 21:08:24 2014
From: rbowen at redhat.com (Rich Bowen)
Date: Thu, 23 Jan 2014 16:08:24 -0500
Subject: [Rdo-list] Speaker needed: http://colug.net/
In-Reply-To: <52E182D8.1000401@redhat.com>
References: <52E179EF.3080000@redhat.com> <52E182D8.1000401@redhat.com>
Message-ID: <52E184C8.2000306@redhat.com>


On 01/23/2014 04:00 PM, Perry Myers wrote:
> On 01/23/2014 03:22 PM, Rich Bowen wrote:
>> CoLUG - http://colug.net/ - the Columbus Linux User Group - is looking
>> for someone in the area to come give a talk/presentation/demo of
>> OpenStack. Is anyone available to do that?
> Ah, I'm only 3 hours from Columbus (based in Pittsburgh), but will be
> out of town traveling that day.  So the timing doesn't quite work...
They're actually looking for a speaker for late February - I should have 
mentioned that. January is already covered.

--Rich

-- 
Rich Bowen - rbowen at redhat.com
OpenStack Community Liaison
http://openstack.redhat.com/



From lars at redhat.com  Thu Jan 23 21:34:21 2014
From: lars at redhat.com (Lars Kellogg-Stedman)
Date: Thu, 23 Jan 2014 16:34:21 -0500
Subject: [Rdo-list] RDO Hangouts: Suggestions/Speakers needed
In-Reply-To: <52E16569.9070507@redhat.com>
References: <52E16569.9070507@redhat.com>
Message-ID: <20140123213421.GA11134@redhat.com>

On Thu, Jan 23, 2014 at 01:54:33PM -0500, Rich Bowen wrote:
> If you're willing to speak for anywhere from 30 to 45 minutes on any
> OpenStack-related topic, please let me know.

I would be happy to do something on:

- debugging neutron
- deploying things with heat
- a walk-through of a multinode deployment with packstack
- working with cloud-init
- ...and probably other topics.

Sort of depends on what people are interested in, I guess.

-- 
Lars Kellogg-Stedman  | larsks @ irc
Cloud Engineering / OpenStack          | "   "  @ twitter

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 

From pmyers at redhat.com  Thu Jan 23 22:26:26 2014
From: pmyers at redhat.com (Perry Myers)
Date: Thu, 23 Jan 2014 17:26:26 -0500
Subject: [Rdo-list] Speaker needed: http://colug.net/
In-Reply-To: <52E184C8.2000306@redhat.com>
References: <52E179EF.3080000@redhat.com> <52E182D8.1000401@redhat.com>
	<52E184C8.2000306@redhat.com>
Message-ID: <52E19712.2000904@redhat.com>

On 01/23/2014 04:08 PM, Rich Bowen wrote:
> 
> On 01/23/2014 04:00 PM, Perry Myers wrote:
>> On 01/23/2014 03:22 PM, Rich Bowen wrote:
>>> CoLUG - http://colug.net/ - the Columbus Linux User Group - is looking
>>> for someone in the area to come give a talk/presentation/demo of
>>> OpenStack. Is anyone available to do that?
>> Ah, I'm only 3 hours from Columbus (based in Pittsburgh), but will be
>> out of town traveling that day.  So the timing doesn't quite work...
> They're actually looking for a speaker for late February - I should have
> mentioned that. January is already covered.

Ah, when is it?  (I'm also traveling a fair bit in Feb too, but who
knows, perhaps the timing could work)



From flavio at redhat.com  Fri Jan 24 09:28:15 2014
From: flavio at redhat.com (Flavio Percoco)
Date: Fri, 24 Jan 2014 10:28:15 +0100
Subject: [Rdo-list] RDO Hangouts: Suggestions/Speakers needed
In-Reply-To: <52E16569.9070507@redhat.com>
References: <52E16569.9070507@redhat.com>
Message-ID: <20140124092815.GB18638@redhat.com>

On 23/01/14 13:54 -0500, Rich Bowen wrote:
>Last year we had two RDO hangouts, both on networking, and these were 
>very well received.
>
>We'd like to get this started up again, with hangouts on a variety of 
>topics. We've had some suggestions in past threads, but nobody 
>volunteering to do the content.
>
>If you're willing to speak for anywhere from 30 to 45 minutes on any 
>OpenStack-related topic, please let me know.
>
>Things I'd like to see us do hangouts on include:
>
>* Reporting/Alarming with Ceilometer
>* Deploying apps with heat
>* Using TryStack
>* More stuff about networking, as this continues to be a common pain point
>* Icehouse: What's coming
>* More advanced deployments with packstack
>* ...

Marconi?
    * What it is
    * Where it is standing
    * Where it is headed
    * How to play with it

>
>I'd also be interested in doing one-on-one hangouts/chats on shorter 
>topics (10-15 minutes) if that's more your speed than a broadcast type 
>event.

+1

>
>-- 
>Rich Bowen - rbowen at redhat.com
>OpenStack Community Liaison
>http://openstack.redhat.com/
>
>_______________________________________________
>Rdo-list mailing list
>Rdo-list at redhat.com
>https://www.redhat.com/mailman/listinfo/rdo-list

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 

From kchamart at redhat.com  Fri Jan 24 11:43:59 2014
From: kchamart at redhat.com (Kashyap Chamarthy)
Date: Fri, 24 Jan 2014 17:13:59 +0530
Subject: [Rdo-list] RDO Hangouts: Suggestions/Speakers needed
In-Reply-To: <52E16569.9070507@redhat.com>
References: <52E16569.9070507@redhat.com>
Message-ID: <52E251FF.70503@redhat.com>

[Adding a few upstream folks (who work on KVM/QEMU/Block-layer
Libugestfs) who expressed interest in improving collaboration between
projects that overlap in OpenStack.]


On 01/24/2014 12:24 AM, Rich Bowen wrote:
> Last year we had two RDO hangouts, both on networking, and these were
> very well received.
> 
> We'd like to get this started up again, with hangouts on a variety of
> topics. We've had some suggestions in past threads, but nobody
> volunteering to do the content.
> 
> If you're willing to speak for anywhere from 30 to 45 minutes on any
> OpenStack-related topic, please let me know.
> 
> Things I'd like to see us do hangouts on include:
> 
> * Reporting/Alarming with Ceilometer
> * Deploying apps with heat
> * Using TryStack
> * More stuff about networking, as this continues to be a common pain point
> * Icehouse: What's coming
> * More advanced deployments with packstack
> * ...
> 
> I'd also be interested in doing one-on-one hangouts/chats on shorter
> topics (10-15 minutes) if that's more your speed than a broadcast type
> event.
> 


-- 
/kashyap



From amit.shah at redhat.com  Fri Jan 24 11:54:44 2014
From: amit.shah at redhat.com (Amit Shah)
Date: Fri, 24 Jan 2014 17:24:44 +0530
Subject: [Rdo-list] RDO Hangouts: Suggestions/Speakers needed
In-Reply-To: <52E251FF.70503@redhat.com>
References: <52E16569.9070507@redhat.com>
 <52E251FF.70503@redhat.com>
Message-ID: <20140124115444.GA26965@grmbl.mre>

On (Fri) 24 Jan 2014 [17:13:59], Kashyap Chamarthy wrote:
> [Adding a few upstream folks (who work on KVM/QEMU/Block-layer
> Libugestfs) who expressed interest in improving collaboration between
> projects that overlap in OpenStack.]

Thanks, Kashyap.

> On 01/24/2014 12:24 AM, Rich Bowen wrote:
> > Last year we had two RDO hangouts, both on networking, and these were
> > very well received.
> > 
> > We'd like to get this started up again, with hangouts on a variety of
> > topics. We've had some suggestions in past threads, but nobody
> > volunteering to do the content.
> > 
> > If you're willing to speak for anywhere from 30 to 45 minutes on any
> > OpenStack-related topic, please let me know.
> > 
> > Things I'd like to see us do hangouts on include:
> > 
> > * Reporting/Alarming with Ceilometer
> > * Deploying apps with heat
> > * Using TryStack
> > * More stuff about networking, as this continues to be a common pain point
> > * Icehouse: What's coming
> > * More advanced deployments with packstack
> > * ...
> > 
> > I'd also be interested in doing one-on-one hangouts/chats on shorter
> > topics (10-15 minutes) if that's more your speed than a broadcast type
> > event.

One of the things I noticed at the last KVM Forum / LinuxCon EU was
the KVM, libvirt and OpenStack devels don't talk enough.  There were a
few places where we saw suboptimal (or even deprecated) settings /
options being used for the QEMU command line being generated for VMs.

One of the ideas suggested was to have these hangouts-like sessions,
where a developer from openstack, or gluster, or kvm, or libvirt teams
would come and talk about their work, or how to best utilize the
infrastructure, what are the various options available, and tradeoffs
in them, etc., the overall stack would be better documented, and we'd
have more interaction amongst the various people involved.

I realise this is much broader in scope than what you have here, but
if there's interest in such a thing, we can discuss ways in which we
can go about this.  I'm also interested to hear if people have more
ideas in this regard (collaboration among people in various parts of
the stack).

Thanks,


		Amit



From bderzhavets at hotmail.com  Fri Jan 24 13:06:01 2014
From: bderzhavets at hotmail.com (Boris Derzhavets)
Date: Fri, 24 Jan 2014 08:06:01 -0500
Subject: [Rdo-list] Attempt to reproduce Getting Started with Multi-Node
 OpenStack RDO Havana + Gluster Backend + Neutron VLAN by Andrew Lau on F19
 (2)
In-Reply-To: <52BD4D8C.1080805@redhat.com>
References: 
	<52B8C15A.9080806@redhat.com>,
	,
	
	,
	<52BD4D8C.1080805@redhat.com>
Message-ID: 

It started to work after yesterday `yum -y update` 7 p.m MSK time.  In general, I followed your Instructions on physical boxes F20 . Details here :-

http://bderzhavets.blogspot.com/2014/01/setting-up-two-physical-node-openstack.html



> Date: Fri, 27 Dec 2013 10:51:08 +0100
> From: kchamart at redhat.com
> To: bderzhavets at hotmail.com
> CC: andrew at andrewklau.com; rdo-list at redhat.com
> Subject: Re: [Rdo-list] Attempt to reproduce Getting Started with Multi-Node OpenStack RDO Havana + Gluster Backend + Neutron VLAN by Andrew Lau on F19
> 
> [. . .]
> 
> > 
> > View also http://kashyapc.wordpress.com/tag/fedora/
> > Set up a bit different from yours , but with same idea Controller + Compute,  is done
> > manually not via packstack with f20 core ( no Ethernet interfaces renaming just ifcfg-eth0 and etc )
> 
> 
> Here are more updated configurations:
> 
>   http://kashyapc.fedorapeople.org/virt/openstack/neutron-configs-GRE-OVS-two-node.txt
> 
> 
> That's the manual configuration details (not *fully* polished, but should
> give you an idea.
> 
>   http://kashyapc.fedorapeople.org/virt/openstack/Two-node-Havana-setup.txt
> 
> 
> And, that's the set-up:
> 
>   - Controller node: Nova, Keystone, Cinder, Glance, Neutron (using Open
>     vSwitch plugin and GRE tunneling).
> 
>   - Compute node: Nova (nova-compute), Neutron (openvswitch-agent)
> 
> 
> Hope that helps.
> 
> -- 
> /kashyap
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From kchamart at redhat.com  Fri Jan 24 13:11:30 2014
From: kchamart at redhat.com (Kashyap Chamarthy)
Date: Fri, 24 Jan 2014 18:41:30 +0530
Subject: [Rdo-list] Attempt to reproduce Getting Started with Multi-Node
 OpenStack RDO Havana + Gluster Backend + Neutron VLAN by Andrew Lau on F19
 (2)
In-Reply-To: 
References: 
	<52B8C15A.9080806@redhat.com>,
	,
	
	,
	<52BD4D8C.1080805@redhat.com>
	
Message-ID: <52E26682.2030202@redhat.com>

On 01/24/2014 06:36 PM, Boris Derzhavets wrote:
> It started to work after yesterday `yum -y update` 7 p.m MSK time.  
> In general, I followed your Instructions on physical boxes F20 . Details here :-
> 
> http://bderzhavets.blogspot.com/2014/01/setting-up-two-physical-node-openstack.html

Nice, you got it working. I see that you're using XEN there.


-- 
/kashyap



From jonathan.creasy at contegix.com  Fri Jan 24 13:50:15 2014
From: jonathan.creasy at contegix.com (jonathan.creasy)
Date: Fri, 24 Jan 2014 07:50:15 -0600 (CST)
Subject: [Rdo-list] RDO Hangouts: Suggestions/Speakers needed
Message-ID: 

Ceilometer is of particular interest to our organization (contegix.com). I would be very interested in diving into that.

We would be happy if someone else had the content for us to learn from or if no such person exists we can work on content.

I am also encouraging someone from our team to contribute upstrean and know that component thoroughly.

-------- Original message --------
From: Rich Bowen  
Date: 01/23/2014  12:54 PM  (GMT-06:00) 
To: rdo-list at redhat.com 
Subject: [Rdo-list] RDO Hangouts: Suggestions/Speakers needed 
 
Last year we had two RDO hangouts, both on networking, and these were 
very well received.

We'd like to get this started up again, with hangouts on a variety of 
topics. We've had some suggestions in past threads, but nobody 
volunteering to do the content.

If you're willing to speak for anywhere from 30 to 45 minutes on any 
OpenStack-related topic, please let me know.

Things I'd like to see us do hangouts on include:

* Reporting/Alarming with Ceilometer
* Deploying apps with heat
* Using TryStack
* More stuff about networking, as this continues to be a common pain point
* Icehouse: What's coming
* More advanced deployments with packstack
* ...

I'd also be interested in doing one-on-one hangouts/chats on shorter 
topics (10-15 minutes) if that's more your speed than a broadcast type 
event.

-- 
Rich Bowen - rbowen at redhat.com
OpenStack Community Liaison
http://openstack.redhat.com/

_______________________________________________
Rdo-list mailing list
Rdo-list at redhat.com
https://www.redhat.com/mailman/listinfo/rdo-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From pbrady at redhat.com  Fri Jan 24 14:42:24 2014
From: pbrady at redhat.com (=?ISO-8859-1?Q?P=E1draig_Brady?=)
Date: Fri, 24 Jan 2014 14:42:24 +0000
Subject: [Rdo-list] Installing Heat from RDO - dependency error
In-Reply-To: <52DE94CE.9030306@redhat.com>
References: <31154292.58.1390317254001.JavaMail.Daniel@Daniel-PC>
	<52DE94CE.9030306@redhat.com>
Message-ID: <52E27BD0.5090108@redhat.com>

On 01/21/2014 03:39 PM, P?draig Brady wrote:
> On 01/21/2014 03:15 PM, Daniel Speichert wrote:
>> Hello,
>> I am installing Heat service according to the guide from RDO website:http://openstack.redhat.com/Deploy_Heat_and_launch_your_first_Application
>>
>> All packages install fine except for the last one: openstack-heat-templates. The package it depends on is just not in any repositories (CentOS, EPEL or OpenStack Havana RDO).
>>
>> Error: Package: openstack-heat-templates-0-0.1.20140106git.el6.noarch (openstack-havana)
>>            Requires: libvirt-daemon
> 
> That is a bug in the package.
> It should depend on libvirt on el6 branches.
> 
>> Does anybody know how to fix this issue?
> 
> I would ensure that libvirt is installed and install the templates using the rpm --nodeps option.
> We'll regenerate an el6 rpm with the correct dependencies now.

An rpm with the correct dependencies is now in the RDO el6 repos.

thanks,
P?draig.



From rbowen at redhat.com  Fri Jan 24 14:46:14 2014
From: rbowen at redhat.com (Rich Bowen)
Date: Fri, 24 Jan 2014 09:46:14 -0500
Subject: [Rdo-list] Speaker needed: http://colug.net/
In-Reply-To: <52E19712.2000904@redhat.com>
References: <52E179EF.3080000@redhat.com> <52E182D8.1000401@redhat.com>
	<52E184C8.2000306@redhat.com> <52E19712.2000904@redhat.com>
Message-ID: <52E27CB6.7070500@redhat.com>


On 01/23/2014 05:26 PM, Perry Myers wrote:
> On 01/23/2014 04:08 PM, Rich Bowen wrote:
>> On 01/23/2014 04:00 PM, Perry Myers wrote:
>>> On 01/23/2014 03:22 PM, Rich Bowen wrote:
>>>> CoLUG - http://colug.net/ - the Columbus Linux User Group - is looking
>>>> for someone in the area to come give a talk/presentation/demo of
>>>> OpenStack. Is anyone available to do that?
>>> Ah, I'm only 3 hours from Columbus (based in Pittsburgh), but will be
>>> out of town traveling that day.  So the timing doesn't quite work...
>> They're actually looking for a speaker for late February - I should have
>> mentioned that. January is already covered.
> Ah, when is it?  (I'm also traveling a fair bit in Feb too, but who
> knows, perhaps the timing could work)

Not sure. All he said was late February. I can make the introductions, 
and let you work it out with him?

-- 
Rich Bowen - rbowen at redhat.com
OpenStack Community Liaison
http://openstack.redhat.com/



From pmyers at redhat.com  Fri Jan 24 16:16:34 2014
From: pmyers at redhat.com (Perry Myers)
Date: Fri, 24 Jan 2014 11:16:34 -0500
Subject: [Rdo-list] Speaker needed: http://colug.net/
In-Reply-To: <52E27CB6.7070500@redhat.com>
References: <52E179EF.3080000@redhat.com>
	<52E182D8.1000401@redhat.com>	<52E184C8.2000306@redhat.com>
	<52E19712.2000904@redhat.com> <52E27CB6.7070500@redhat.com>
Message-ID: <52E291E2.9020007@redhat.com>

On 01/24/2014 09:46 AM, Rich Bowen wrote:
> 
> On 01/23/2014 05:26 PM, Perry Myers wrote:
>> On 01/23/2014 04:08 PM, Rich Bowen wrote:
>>> On 01/23/2014 04:00 PM, Perry Myers wrote:
>>>> On 01/23/2014 03:22 PM, Rich Bowen wrote:
>>>>> CoLUG - http://colug.net/ - the Columbus Linux User Group - is looking
>>>>> for someone in the area to come give a talk/presentation/demo of
>>>>> OpenStack. Is anyone available to do that?
>>>> Ah, I'm only 3 hours from Columbus (based in Pittsburgh), but will be
>>>> out of town traveling that day.  So the timing doesn't quite work...
>>> They're actually looking for a speaker for late February - I should have
>>> mentioned that. January is already covered.
>> Ah, when is it?  (I'm also traveling a fair bit in Feb too, but who
>> knows, perhaps the timing could work)
> 
> Not sure. All he said was late February. I can make the introductions,
> and let you work it out with him?

Sounds good.  /me wonders how useful he'll be doing a hands on demo, but
hey, it should be fun regardless :)




From stefanha at redhat.com  Fri Jan 24 16:35:59 2014
From: stefanha at redhat.com (Stefan Hajnoczi)
Date: Fri, 24 Jan 2014 10:35:59 -0600
Subject: [Rdo-list] RDO Hangouts: Suggestions/Speakers needed
In-Reply-To: <52E251FF.70503@redhat.com>
References: <52E16569.9070507@redhat.com>
 <52E251FF.70503@redhat.com>
Message-ID: <20140124163559.GD5529@stefanha-thinkpad.redhat.com>

On Fri, Jan 24, 2014 at 05:13:59PM +0530, Kashyap Chamarthy wrote:
> [Adding a few upstream folks (who work on KVM/QEMU/Block-layer
> Libugestfs) who expressed interest in improving collaboration between
> projects that overlap in OpenStack.]
> 
> 
> On 01/24/2014 12:24 AM, Rich Bowen wrote:
> > Last year we had two RDO hangouts, both on networking, and these were
> > very well received.
> > 
> > We'd like to get this started up again, with hangouts on a variety of
> > topics. We've had some suggestions in past threads, but nobody
> > volunteering to do the content.
> > 
> > If you're willing to speak for anywhere from 30 to 45 minutes on any
> > OpenStack-related topic, please let me know.
> > 
> > Things I'd like to see us do hangouts on include:
> > 
> > * Reporting/Alarming with Ceilometer
> > * Deploying apps with heat
> > * Using TryStack
> > * More stuff about networking, as this continues to be a common pain point
> > * Icehouse: What's coming
> > * More advanced deployments with packstack
> > * ...
> > 
> > I'd also be interested in doing one-on-one hangouts/chats on shorter
> > topics (10-15 minutes) if that's more your speed than a broadcast type
> > event.

Nice!  From the QEMU and especially block layer perspective I'd like to
start doing hangouts for new features (e.g. image fleecing, I/O
throttling) so we can communicate them to people working on the higher
layers of the stack.

Stefan



From daniel at speichert.pl  Fri Jan 24 21:02:04 2014
From: daniel at speichert.pl (Daniel Speichert)
Date: Fri, 24 Jan 2014 22:02:04 +0100 (CET)
Subject: [Rdo-list] Glance - missing dependencies
In-Reply-To: <654319.982.1390597235358.JavaMail.Daniel@Daniel-PC>
Message-ID: <26266171.983.1390597259780.JavaMail.Daniel@Daniel-PC>

Hello,

I was installing OpenStack from RDO today and had to install two extra packages beside openstack-glance, for Glance to work:
python-anyjson python-amqplib

Shouldn't these two be installed as dependencies?

Regards,
Daniel Speichert



From lars at redhat.com  Fri Jan 24 21:17:44 2014
From: lars at redhat.com (Lars Kellogg-Stedman)
Date: Fri, 24 Jan 2014 16:17:44 -0500
Subject: [Rdo-list] Glance - missing dependencies
In-Reply-To: <26266171.983.1390597259780.JavaMail.Daniel@Daniel-PC>
References: <654319.982.1390597235358.JavaMail.Daniel@Daniel-PC>
	<26266171.983.1390597259780.JavaMail.Daniel@Daniel-PC>
Message-ID: <20140124211744.GA32214@redhat.com>

On Fri, Jan 24, 2014 at 10:02:04PM +0100, Daniel Speichert wrote:
> I was installing OpenStack from RDO today and had to install two extra packages beside openstack-glance, for Glance to work:
> python-anyjson python-amqplib
> 
> Shouldn't these two be installed as dependencies?

Anything required for RDO to function should be installed as a
dependency, yes.  On which platform are you installing RDO
(Fedora/CentOS/etc)?  What specifically required those two packages?

Thanks,

-- 
Lars Kellogg-Stedman  | larsks @ irc
Cloud Engineering / OpenStack          | "   "  @ twitter

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 

From daniel at speichert.pl  Fri Jan 24 21:21:13 2014
From: daniel at speichert.pl (Daniel Speichert)
Date: Fri, 24 Jan 2014 22:21:13 +0100 (CET)
Subject: [Rdo-list] Glance - missing dependencies
In-Reply-To: <20140124211744.GA32214@redhat.com>
References: <654319.982.1390597235358.JavaMail.Daniel@Daniel-PC>
	<26266171.983.1390597259780.JavaMail.Daniel@Daniel-PC>
	<20140124211744.GA32214@redhat.com>
Message-ID: <30279150.999.1390598408544.JavaMail.Daniel@Daniel-PC>

----- Original Message -----
> From: "Lars Kellogg-Stedman" 
> To: "Daniel Speichert" 
> Cc: rdo-list at redhat.com
> Sent: Friday, January 24, 2014 4:17:44 PM
> Subject: Re: [Rdo-list] Glance - missing dependencies
 
> Anything required for RDO to function should be installed as a
> dependency, yes.  On which platform are you installing RDO
> (Fedora/CentOS/etc)?  What specifically required those two packages?
> 

CentOS 6.5, using Rabbit instead of QPID for notifications.

Regards,
Daniel Speichert



From mburns at redhat.com  Fri Jan 24 22:21:43 2014
From: mburns at redhat.com (Mike Burns)
Date: Fri, 24 Jan 2014 17:21:43 -0500
Subject: [Rdo-list] CentOS Cloud Sig
Message-ID: <52E2E777.9030602@redhat.com>

We had a planning meeting to try to figure out the path forward for the 
CentOS cloud sig.

Some of the highlights of the meeting:

* A single SIG that provides a number of dependencies makes sense, 
possibly with variants for different projects to deliver specific 
packages that apply only to them.
* Need to develop a process where certain versions are agreed upon for 
common packages -- not decided yet
* Branding -- conversation is deferred to some other group/place/time
* Java packaging issues need to be worked out (doesn't impact RDO much, 
but might apply to python as well)
* Discussion about whether projects would want a lot of anaconda changes 
-- response was that getting content installed was sufficient and 
projects would depend on things like puppet/chef/etc to configure/deploy
* What types of changes over base CentOS:  java packaging, java itself, 
tomcat.  There is interest in other things like qemu, libvirt, etc
* Ability to work with other projects is important (Ceph, Xen, other Sigs)

Next Steps:

*  figure out common ground and dependencies
* projects to nominate people who will do this work
* Sig will be primarily meritocracy.  initial seeding will be based on 
project nominations
* need to decide what projects will be included in the SIG

Mike



From pmyers at redhat.com  Fri Jan 24 22:43:22 2014
From: pmyers at redhat.com (Perry Myers)
Date: Fri, 24 Jan 2014 17:43:22 -0500
Subject: [Rdo-list] [rhos-list] instances with ephemeral disk can't
	start ?
In-Reply-To: <52E2E63F.8040305@bnl.gov>
References: <52E2E63F.8040305@bnl.gov>
Message-ID: <52E2EC8A.1010808@redhat.com>

On 01/24/2014 05:16 PM, Xin Zhao wrote:
> Hello,
> 
> In our grizzly openstack testbed, instances that use ephemeral disk fail
> to run, in the scheduler log there is the following errors:
> 
> scheduler.log:2014-01-24 16:43:55.772 ERROR
> nova.scheduler.filter_scheduler
> [req-32173fb7-8d49-4d17-8490-4a6ddaf18a67
> 45a137d469c940cab24655ce65a8455e 614dfb1842824ded94893d0e4c2525dc]
> [instance: 799b985a-eba5-49ef-80b9-c515fa0523c2] Error from last host:
> cldh0195.cloud.local (node cldh0195.cloud.local): [u'Traceback (most
> recent call last):\n', u'  File
> "/usr/lib/python2.6/site-packages/nova/compute/manager.py", line 864, in
> _run_instance\n    set_access_ip=set_access_ip)\n', u'  File
> "/usr/lib/python2.6/site-packages/nova/compute/manager.py", line 1123,
> in _spawn\n    LOG.exception(_(\'Instance failed to spawn\'),
> instance=instance)\n', u'  File "/usr/lib64/python2.6/contextlib.py",
> line 23, in __exit__\n    self.gen.next()\n', u'  File
> "/usr/lib/python2.6/site-packages/nova/compute/manager.py", line 1119,
> in _spawn\n    block_device_info)\n', u'  File
> "/usr/lib/python2.6/site-packages/nova/virt/libvirt/driver.py", line
> 1540, in spawn\n    admin_pass=admin_password)\n', u'  File
> "/usr/lib/python2.6/site-packages/nova/virt/libvirt/driver.py", line
> 1842, in _create_image\n    ephemeral_size=ephemeral_gb)\n', u'  File
> "/usr/lib/python2.6/site-packages/nova/virt/libvirt/imagebackend.py",
> line 158, in cache\n    *args, **kwargs)\n', u'  File
> "/usr/lib/python2.6/site-packages/nova/virt/libvirt/imagebackend.py",
> line 291, in create_image\n    prepare_template(target=base,
> max_size=size, *args, **kwargs)\n', u'  File
> "/usr/lib/python2.6/site-packages/nova/openstack/common/lockutils.py",
> line 228, in inner\n    retval = f(*args, **kwargs)\n', u'  File
> "/usr/lib/python2.6/site-packages/nova/virt/libvirt/imagebackend.py",
> line 146, in call_if_not_exists\n    fetch_func(target=target, *args,
> **kwargs)\n', u"/TypeError: _create_ephemeral() got an unexpected
> keyword argument 'max_size'/\n"]
> 
> I see a bug report like this :
> https://bugzilla.redhat.com/show_bug.cgi?id=1044562, I wonder if this
> bug is fixed in grizzly or not?

This bug is currently being QA'd for an async release of RHOS 3.0/Grizzly.

It is not yet released for RHOS 3.0 since it is still in testing.  It
should be updated soon on our content mirrors (Red Hat Network)

If it is not a candidate for the stable branch of Grizzly, then it
wouldn't be in RDO Grizzly as RDO follows the upstream stable branches.

Vladan, since you are working on this, did it get proposed for the
stable branch or is it RHOS only backport?

> I am using grizzly rpms from the RDO repo:
> 
> $> rpm -qf
> /usr/lib/python2.6/site-packages/nova/virt/libvirt/imagebackend.py
> python-nova-2013.1.4-1.el6.noarch

Since this is RDO related, I'm going to move this thread over to rdo-list.

Cheers,

Perry



From pbrady at redhat.com  Sat Jan 25 15:08:21 2014
From: pbrady at redhat.com (=?ISO-8859-1?Q?P=E1draig_Brady?=)
Date: Sat, 25 Jan 2014 15:08:21 +0000
Subject: [Rdo-list] [rhos-list] instances with ephemeral disk can't
 start ?
In-Reply-To: <52E2EC8A.1010808@redhat.com>
References: <52E2E63F.8040305@bnl.gov> <52E2EC8A.1010808@redhat.com>
Message-ID: <52E3D365.8020507@redhat.com>

On 01/24/2014 10:43 PM, Perry Myers wrote:
> On 01/24/2014 05:16 PM, Xin Zhao wrote:
>> Hello,
>>
>> In our grizzly openstack testbed, instances that use ephemeral disk fail
>> to run, in the scheduler log there is the following errors:

>> **kwargs)\n', u"/TypeError: _create_ephemeral() got an unexpected
>> keyword argument 'max_size'/\n"]
>>
>> I see a bug report like this :
>> https://bugzilla.redhat.com/show_bug.cgi?id=1044562, I wonder if this
>> bug is fixed in grizzly or not?
> 
> This bug is currently being QA'd for an async release of RHOS 3.0/Grizzly.
> 
> It is not yet released for RHOS 3.0 since it is still in testing.  It
> should be updated soon on our content mirrors (Red Hat Network)
> 
> If it is not a candidate for the stable branch of Grizzly, then it
> wouldn't be in RDO Grizzly as RDO follows the upstream stable branches.
> 
> Vladan, since you are working on this, did it get proposed for the
> stable branch or is it RHOS only backport?
> 
>> I am using grizzly rpms from the RDO repo:
>>
>> $> rpm -qf
>> /usr/lib/python2.6/site-packages/nova/virt/libvirt/imagebackend.py
>> python-nova-2013.1.4-1.el6.noarch

Note python-nova-2013.1.4-2.el6 should be the first version with
this issue. Anyway...

> Since this is RDO related, I'm going to move this thread over to rdo-list.

This fix in already on upstream stable:
  https://review.openstack.org/#/c/57821/
and was already ported to RDO grizzly in version python-nova-2013.1.4-5.el6
This unfortunately wasn't placed in testing and in the meantime 2013.1.4-6
became available (which contains an additional CVE fix).
So I've synced 2013.1.4-6 to the RDO repos now.

thanks,
P?draig.



From pmyers at redhat.com  Sun Jan 26 05:01:21 2014
From: pmyers at redhat.com (Perry Myers)
Date: Sun, 26 Jan 2014 00:01:21 -0500
Subject: [Rdo-list] Fedora 20 / Devstack Networking Issues
Message-ID: <52E496A1.20807@redhat.com>

Ok, I've been chasing down some networking issues along with some other
folks.  Here's what I'm seeing:

Starting with a vanilla F20 cloud image running on a F20 host, clone
devstack into it and run stack.sh.

First thing is that the RabbitMQ server issue I noted a few weeks ago is
still intermittently there.  So during the step where rabbitmqctl is run
to set the password of the rabbit admin user, it might fail and all
subsequent AMQP communication fails which makes a lot of the nova
commands in devstack also fail.

But... if you get past this error (since it is intermittent), then
devstack seems to complete successfully.  Standard commands like nova
list, keystone user-list, etc all work fine.

I did note though that access to Horizon does not work.  I need to
investigate this further.

But worse than that is when you run nova boot, the host to guest
networking (remember this is devstack running in a VM) immediately gets
disconnected.  This issue is 100% reproducible and multiple users are
reporting it (tsedovic, eharney, bnemec cc'd)

I did some investigation when this happens and here's what I found...

If I do:

$ brctl delif br100 eth0

I was immediately able to ping the guest from the host and vice versa.

If I reattach eth0 back to br100, networking stops again

Another thing... I notice that on the system br100 does not have an ip
address, but eth0 does.  I thought when doing bridged networking like
this, the bridge should have the ip address and the physical iface that
is attached to the bridge does not get an ip addr.

So... I tweaked /etc/sysconfig/network-scripts/ifcfg-eth0 to remove the
dhcp from the bootproto line and I copied ifcfg-eth0 to ifcfg-br100
allowing it to use bootproto dhcp

I brought both ifaces down and then brought them both up.  eth0 first
and br100 second

This time, br100 got the dhcp address from the host and networking
worked fine.

So is this just an issue with how nova is setting up bridges?

Since this network disconnect didn't happen until nova launched a vm, I
imagine this isn't a problem with devstack itself, but is likely an
issue with Nova Networking somehow.

Russell/DanS, is there any chance that all of the refactoring you did in
Nova Networking very recently introduce a regression?

Perry



From bderzhavets at hotmail.com  Sun Jan 26 14:47:49 2014
From: bderzhavets at hotmail.com (Boris Derzhavets)
Date: Sun, 26 Jan 2014 09:47:49 -0500
Subject: [Rdo-list] CentOS 6.5 Guest image file available now
In-Reply-To: <52D96F90.6060207@redhat.com>
References: <52D96F90.6060207@redhat.com>
Message-ID: 

>Let us know if you find any issues with it.

RDO Havana fails to create cinder volume via provided image

Thanks
Boris.


> Date: Fri, 17 Jan 2014 12:59:44 -0500
> From: mburns at redhat.com
> To: rdo-list at redhat.com
> Subject: [Rdo-list] CentOS 6.5 Guest image file available now
> 
> Thanks to Joey Boggs for putting this together.
> 
> A prebuilt guest-image for CentOS 6.5 has been posted to the RDO yum 
> repository along with the kickstart used to generate it. [1]  This was 
> done in response to the conversation on IRC earlier.
> 
> The eventual plan would be to have this image owned and generated by the 
> CentOS community, perhaps as part of the Cloud SIG.  This is just a 
> stopgap measure until the SIG is up and running.
> 
> Let us know if you find any issues with it.
> 
> Thanks
> 
> Mike
> 
> [1] http://repos.fedorapeople.org/repos/openstack/guest-images/
> 
> _______________________________________________
> 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 flavio at redhat.com  Mon Jan 27 09:06:16 2014
From: flavio at redhat.com (Flavio Percoco)
Date: Mon, 27 Jan 2014 10:06:16 +0100
Subject: [Rdo-list] Glance - missing dependencies
In-Reply-To: <30279150.999.1390598408544.JavaMail.Daniel@Daniel-PC>
References: <654319.982.1390597235358.JavaMail.Daniel@Daniel-PC>
	<26266171.983.1390597259780.JavaMail.Daniel@Daniel-PC>
	<20140124211744.GA32214@redhat.com>
	<30279150.999.1390598408544.JavaMail.Daniel@Daniel-PC>
Message-ID: <20140127090616.GA3785@redhat.com>

On 24/01/14 22:21 +0100, Daniel Speichert wrote:
>----- Original Message -----
>> From: "Lars Kellogg-Stedman" 
>> To: "Daniel Speichert" 
>> Cc: rdo-list at redhat.com
>> Sent: Friday, January 24, 2014 4:17:44 PM
>> Subject: Re: [Rdo-list] Glance - missing dependencies
>
>> Anything required for RDO to function should be installed as a
>> dependency, yes.  On which platform are you installing RDO
>> (Fedora/CentOS/etc)?  What specifically required those two packages?
>>
>
>CentOS 6.5, using Rabbit instead of QPID for notifications.
>

These are dependencies required for kombu which is not shipped as the
default driver for glance / oslo.messaging in RDO. The hard dependency
on python-kombu was dropped intentionally.

Thanks for noticing and bringing this up,
Cheers,
FF

>Regards,
>Daniel Speichert
>
>_______________________________________________
>Rdo-list mailing list
>Rdo-list at redhat.com
>https://www.redhat.com/mailman/listinfo/rdo-list

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 

From pbrady at redhat.com  Mon Jan 27 09:21:59 2014
From: pbrady at redhat.com (=?ISO-8859-1?Q?P=E1draig_Brady?=)
Date: Mon, 27 Jan 2014 09:21:59 +0000
Subject: [Rdo-list] Glance - missing dependencies
In-Reply-To: <20140127090616.GA3785@redhat.com>
References: <654319.982.1390597235358.JavaMail.Daniel@Daniel-PC>
	<26266171.983.1390597259780.JavaMail.Daniel@Daniel-PC>
	<20140124211744.GA32214@redhat.com>
	<30279150.999.1390598408544.JavaMail.Daniel@Daniel-PC>
	<20140127090616.GA3785@redhat.com>
Message-ID: <52E62537.40401@redhat.com>

On 01/27/2014 09:06 AM, Flavio Percoco wrote:
> On 24/01/14 22:21 +0100, Daniel Speichert wrote:
>> ----- Original Message -----
>>> From: "Lars Kellogg-Stedman" 
>>> To: "Daniel Speichert" 
>>> Cc: rdo-list at redhat.com
>>> Sent: Friday, January 24, 2014 4:17:44 PM
>>> Subject: Re: [Rdo-list] Glance - missing dependencies
>>
>>> Anything required for RDO to function should be installed as a
>>> dependency, yes.  On which platform are you installing RDO
>>> (Fedora/CentOS/etc)?  What specifically required those two packages?
>>>
>>
>> CentOS 6.5, using Rabbit instead of QPID for notifications.
>>
> 
> These are dependencies required for kombu which is not shipped as the
> default driver for glance / oslo.messaging in RDO. The hard dependency
> on python-kombu was dropped intentionally.
> 
> Thanks for noticing and bringing this up,

Nova and Neutron at least have these (small) dependencies in RDO
to easily allow using rabbit as an option:

Requires:         python-kombu
Requires:         python-amqplib
Requires:         python-anyjson

Other services should too.
In future we may push these dependencies to the python-oslo-messaging package.

Note glance only used these libs when notifications were configured,
which wasn't previously done by default. So either that is configured
or there is new glance logic requiring such messaging in place.

thanks,
P?draig.



From flavio at redhat.com  Mon Jan 27 09:51:24 2014
From: flavio at redhat.com (Flavio Percoco)
Date: Mon, 27 Jan 2014 10:51:24 +0100
Subject: [Rdo-list] Glance - missing dependencies
In-Reply-To: <52E62537.40401@redhat.com>
References: <654319.982.1390597235358.JavaMail.Daniel@Daniel-PC>
	<26266171.983.1390597259780.JavaMail.Daniel@Daniel-PC>
	<20140124211744.GA32214@redhat.com>
	<30279150.999.1390598408544.JavaMail.Daniel@Daniel-PC>
	<20140127090616.GA3785@redhat.com> <52E62537.40401@redhat.com>
Message-ID: <20140127095124.GB3785@redhat.com>

On 27/01/14 09:21 +0000, P?draig Brady wrote:
>On 01/27/2014 09:06 AM, Flavio Percoco wrote:
>> On 24/01/14 22:21 +0100, Daniel Speichert wrote:
>>> ----- Original Message -----
>>>> From: "Lars Kellogg-Stedman" 
>>>> To: "Daniel Speichert" 
>>>> Cc: rdo-list at redhat.com
>>>> Sent: Friday, January 24, 2014 4:17:44 PM
>>>> Subject: Re: [Rdo-list] Glance - missing dependencies
>>>
>>>> Anything required for RDO to function should be installed as a
>>>> dependency, yes.  On which platform are you installing RDO
>>>> (Fedora/CentOS/etc)?  What specifically required those two packages?
>>>>
>>>
>>> CentOS 6.5, using Rabbit instead of QPID for notifications.
>>>
>>
>> These are dependencies required for kombu which is not shipped as the
>> default driver for glance / oslo.messaging in RDO. The hard dependency
>> on python-kombu was dropped intentionally.
>>
>> Thanks for noticing and bringing this up,
>
>Nova and Neutron at least have these (small) dependencies in RDO
>to easily allow using rabbit as an option:
>
>Requires:         python-kombu
>Requires:         python-amqplib
>Requires:         python-anyjson
>
>Other services should too.
>In future we may push these dependencies to the python-oslo-messaging package.

Agreed, I think this is the way to go. They used to be part of Glance
because it had its own implementation for notifications. As of
Icehouse, this is not the case anymore.

>
>Note glance only used these libs when notifications were configured,
>which wasn't previously done by default. So either that is configured
>or there is new glance logic requiring such messaging in place.
>

This hasn't changed in Glance. Notification's are still optional (the
default is noop) and the above dependencies are required just when
rabbit is enabled.

Cheers,
FF

>thanks,
>P?draig.

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 

From stefano.zilli at cern.ch  Mon Jan 27 10:51:32 2014
From: stefano.zilli at cern.ch (Stefano Zilli)
Date: Mon, 27 Jan 2014 10:51:32 +0000
Subject: [Rdo-list] pythonclients completion scripts raise errors on zsh
Message-ID: <2DDF0FACD8B3CB4193010D75BFA894736DCC8286@CERNXCHG12.cern.ch>

Hello,

We are currently testing Havana python-{cinder,nova,keystone}client rpms and we noticed that completion files have been moved to /etc/profile.d.
This is causing the following errors in zsh shells and, as a consequence, it's blocking the deployment in production.

/etc/profile.d/cinder.sh:15: command not found: complete
/etc/profile.d/keystone.sh:27: command not found: complete
/etc/profile.d/nova.sh:27: command not found: complete

Wouldn't be better to have some kind of guard at the beginning of those files like "[ -z "$BASH_VERSION" ] && return" to avoid the execution on non-bash shells?

Regards,
Stefano Zilli

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From bderzhavets at hotmail.com  Mon Jan 27 12:56:18 2014
From: bderzhavets at hotmail.com (Boris Derzhavets)
Date: Mon, 27 Jan 2014 07:56:18 -0500
Subject: [Rdo-list] CentOS 6.5 Guest image file available now
In-Reply-To: 
References: <52D96F90.6060207@redhat.com>,
	
Message-ID: 

Sorry, I want to clarify :-

It's possible to create glance image and load instance CentOS 6.5 via `nova boot --image ...`
However , `cinder create --image-id xxxxxxxxxxxxxx  --display_name CentOS65 10`
gives me ERROR status in `cinder list`. So it makes impossible create cinder volume for CentOS 6.5 on glusterfs replicated volume for Compute nodes. What makes instance slow
as openstack cloud instance vs systems available for cinder volumes creation.

From: bderzhavets at hotmail.com
To: mburns at redhat.com; rdo-list at redhat.com
Date: Sun, 26 Jan 2014 09:47:49 -0500
Subject: Re: [Rdo-list] CentOS 6.5 Guest image file available now




>Let us know if you find any issues with it.

RDO Havana fails to create cinder volume via provided image

Thanks
Boris.


> Date: Fri, 17 Jan 2014 12:59:44 -0500
> From: mburns at redhat.com
> To: rdo-list at redhat.com
> Subject: [Rdo-list] CentOS 6.5 Guest image file available now
> 
> Thanks to Joey Boggs for putting this together.
> 
> A prebuilt guest-image for CentOS 6.5 has been posted to the RDO yum 
> repository along with the kickstart used to generate it. [1]  This was 
> done in response to the conversation on IRC earlier.
> 
> The eventual plan would be to have this image owned and generated by the 
> CentOS community, perhaps as part of the Cloud SIG.  This is just a 
> stopgap measure until the SIG is up and running.
> 
> Let us know if you find any issues with it.
> 
> Thanks
> 
> Mike
> 
> [1] http://repos.fedorapeople.org/repos/openstack/guest-images/
> 
> _______________________________________________
> 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 rbryant at redhat.com  Mon Jan 27 14:32:52 2014
From: rbryant at redhat.com (Russell Bryant)
Date: Mon, 27 Jan 2014 09:32:52 -0500
Subject: [Rdo-list] Fedora 20 / Devstack Networking Issues
In-Reply-To: <52E496A1.20807@redhat.com>
References: <52E496A1.20807@redhat.com>
Message-ID: <52E66E14.5070707@redhat.com>

On 01/26/2014 12:01 AM, Perry Myers wrote:
> Ok, I've been chasing down some networking issues along with some other
> folks.  Here's what I'm seeing:
> 
> Starting with a vanilla F20 cloud image running on a F20 host, clone
> devstack into it and run stack.sh.
> 
> First thing is that the RabbitMQ server issue I noted a few weeks ago is
> still intermittently there.  So during the step where rabbitmqctl is run
> to set the password of the rabbit admin user, it might fail and all
> subsequent AMQP communication fails which makes a lot of the nova
> commands in devstack also fail.
> 
> But... if you get past this error (since it is intermittent), then
> devstack seems to complete successfully.  Standard commands like nova
> list, keystone user-list, etc all work fine.
> 
> I did note though that access to Horizon does not work.  I need to
> investigate this further.
> 
> But worse than that is when you run nova boot, the host to guest
> networking (remember this is devstack running in a VM) immediately gets
> disconnected.  This issue is 100% reproducible and multiple users are
> reporting it (tsedovic, eharney, bnemec cc'd)
> 
> I did some investigation when this happens and here's what I found...
> 
> If I do:
> 
> $ brctl delif br100 eth0
> 
> I was immediately able to ping the guest from the host and vice versa.
> 
> If I reattach eth0 back to br100, networking stops again
> 
> Another thing... I notice that on the system br100 does not have an ip
> address, but eth0 does.  I thought when doing bridged networking like
> this, the bridge should have the ip address and the physical iface that
> is attached to the bridge does not get an ip addr.
> 
> So... I tweaked /etc/sysconfig/network-scripts/ifcfg-eth0 to remove the
> dhcp from the bootproto line and I copied ifcfg-eth0 to ifcfg-br100
> allowing it to use bootproto dhcp
> 
> I brought both ifaces down and then brought them both up.  eth0 first
> and br100 second
> 
> This time, br100 got the dhcp address from the host and networking
> worked fine.
> 
> So is this just an issue with how nova is setting up bridges?
> 
> Since this network disconnect didn't happen until nova launched a vm, I
> imagine this isn't a problem with devstack itself, but is likely an
> issue with Nova Networking somehow.
> 
> Russell/DanS, is there any chance that all of the refactoring you did in
> Nova Networking very recently introduce a regression?

I suppose it's possible.  You could try going back to before any of the
nova-network-objects patches went in.  The first one to merge was:

commit a8c73c7d3298589440579d67e0c5638981dd7718
Merge: a1f6e85 aa40c8f
Author: Jenkins 
Date:   Wed Jan 15 18:38:37 2014 +0000

    Merge "Make nova-network use Service object"

Try going back to before that and see if you get a different result.  If
so, try using "git bisect" to find the offending commit.

-- 
Russell Bryant



From tsedovic at redhat.com  Mon Jan 27 14:34:19 2014
From: tsedovic at redhat.com (Tomas Sedovic)
Date: Mon, 27 Jan 2014 15:34:19 +0100
Subject: [Rdo-list] Fedora 20 / Devstack Networking Issues
In-Reply-To: <52E496A1.20807@redhat.com>
References: <52E496A1.20807@redhat.com>
Message-ID: <52E66E6B.8050505@redhat.com>

On 26/01/14 06:01, Perry Myers wrote:
> Ok, I've been chasing down some networking issues along with some other
> folks.  Here's what I'm seeing:
>

> I did note though that access to Horizon does not work.  I need to
> investigate this further.

Regarding Horizon, try switching SElinux to Permissive and restarting 
Apache.

I seem to remember an issue where SElinux blocked httpd from writing 
some files Horizon needs (file locks, compiled assets, etc.).

I completely forgot about that and it's quite possible this has been 
fixed already. If not, we should probably raise that as a separate issue.

>
> But worse than that is when you run nova boot, the host to guest
> networking (remember this is devstack running in a VM) immediately gets
> disconnected.  This issue is 100% reproducible and multiple users are
> reporting it (tsedovic, eharney, bnemec cc'd)
>
> I did some investigation when this happens and here's what I found...
>
> If I do:
>
> $ brctl delif br100 eth0
>
> I was immediately able to ping the guest from the host and vice versa.
>
> If I reattach eth0 back to br100, networking stops again
>
> Another thing... I notice that on the system br100 does not have an ip
> address, but eth0 does.  I thought when doing bridged networking like
> this, the bridge should have the ip address and the physical iface that
> is attached to the bridge does not get an ip addr.
>
> So... I tweaked /etc/sysconfig/network-scripts/ifcfg-eth0 to remove the
> dhcp from the bootproto line and I copied ifcfg-eth0 to ifcfg-br100
> allowing it to use bootproto dhcp
>
> I brought both ifaces down and then brought them both up.  eth0 first
> and br100 second
>
> This time, br100 got the dhcp address from the host and networking
> worked fine.
>
> So is this just an issue with how nova is setting up bridges?
>
> Since this network disconnect didn't happen until nova launched a vm, I
> imagine this isn't a problem with devstack itself, but is likely an
> issue with Nova Networking somehow.
>
> Russell/DanS, is there any chance that all of the refactoring you did in
> Nova Networking very recently introduce a regression?
>
> Perry
>



From kchamart at redhat.com  Mon Jan 27 14:45:07 2014
From: kchamart at redhat.com (Kashyap Chamarthy)
Date: Mon, 27 Jan 2014 20:15:07 +0530
Subject: [Rdo-list] pythonclients completion scripts raise errors on zsh
In-Reply-To: <2DDF0FACD8B3CB4193010D75BFA894736DCC8286@CERNXCHG12.cern.ch>
References: <2DDF0FACD8B3CB4193010D75BFA894736DCC8286@CERNXCHG12.cern.ch>
Message-ID: <52E670F3.9050902@redhat.com>

[Adding Jakub Ruzicka who intially pointed this issue.]

On 01/27/2014 04:21 PM, Stefano Zilli wrote:
> Hello,
> 
> We are currently testing Havana python-{cinder,nova,keystone}client rpms and we noticed that completion files have been moved to /etc/profile.d.
> This is causing the following errors in zsh shells and, as a consequence, it's blocking the deployment in production.
> 
> /etc/profile.d/cinder.sh:15: command not found: complete
> /etc/profile.d/keystone.sh:27: command not found: complete
> /etc/profile.d/nova.sh:27: command not found: complete
> 
> Wouldn't be better to have some kind of guard at the beginning of those files like "[ -z "$BASH_VERSION" ] && return" to avoid the execution on non-bash shells?

Right, sane thing to do is to place them in /etc/bash_completion.d,
which requires bash-completion package, to avoid such errors.



-- 
/kashyap



From jruzicka at redhat.com  Mon Jan 27 14:55:34 2014
From: jruzicka at redhat.com (Jakub Ruzicka)
Date: Mon, 27 Jan 2014 15:55:34 +0100
Subject: [Rdo-list] pythonclients completion scripts raise errors on zsh
In-Reply-To: <52E670F3.9050902@redhat.com>
References: <2DDF0FACD8B3CB4193010D75BFA894736DCC8286@CERNXCHG12.cern.ch>
	<52E670F3.9050902@redhat.com>
Message-ID: <52E67366.5010705@redhat.com>



On 27.1.2014 15:45, Kashyap Chamarthy wrote:
> [Adding Jakub Ruzicka who intially pointed this issue.]
> 
> On 01/27/2014 04:21 PM, Stefano Zilli wrote:
>> Hello,
>>
>> We are currently testing Havana python-{cinder,nova,keystone}client rpms and we noticed that completion files have been moved to /etc/profile.d.
>> This is causing the following errors in zsh shells and, as a consequence, it's blocking the deployment in production.
>>
>> /etc/profile.d/cinder.sh:15: command not found: complete
>> /etc/profile.d/keystone.sh:27: command not found: complete
>> /etc/profile.d/nova.sh:27: command not found: complete
>>
>> Wouldn't be better to have some kind of guard at the beginning of those files like "[ -z "$BASH_VERSION" ] && return" to avoid the execution on non-bash shells?
> 
> Right, sane thing to do is to place them in /etc/bash_completion.d,
> which requires bash-completion package, to avoid such errors.

For RDO/Fedora, these are put into /etc/bash_completion.d, but since
RHEL doesn't have bash-completion package, they're put to /etc/profile.d
for RDO/epel-6.

I planned to move them to /etc/bash-completion.d with RHEL 7 which will
include bash-completion package but if this is causing troubles already,
I can make even epel-6 RDO packages use bash-completion because RDO
already requires epel which provides bash-completion.

This is about RDO Havana, right?


Jakub



From stefano.zilli at cern.ch  Mon Jan 27 14:59:11 2014
From: stefano.zilli at cern.ch (Stefano Zilli)
Date: Mon, 27 Jan 2014 14:59:11 +0000
Subject: [Rdo-list] pythonclients completion scripts raise errors on zsh
In-Reply-To: <52E67366.5010705@redhat.com>
References: <2DDF0FACD8B3CB4193010D75BFA894736DCC8286@CERNXCHG12.cern.ch>
	<52E670F3.9050902@redhat.com> <52E67366.5010705@redhat.com>
Message-ID: <2DDF0FACD8B3CB4193010D75BFA894736DCC85FE@CERNXCHG12.cern.ch>

Yes, it's about RDO/epel-6 Havana.

Stefano

-----Original Message-----
From: Jakub Ruzicka [mailto:jruzicka at redhat.com] 
Sent: 27 January 2014 15:56
To: Kashyap Chamarthy; Stefano Zilli
Cc: rdo-list at redhat.com
Subject: Re: [Rdo-list] pythonclients completion scripts raise errors on zsh



On 27.1.2014 15:45, Kashyap Chamarthy wrote:
> [Adding Jakub Ruzicka who intially pointed this issue.]
> 
> On 01/27/2014 04:21 PM, Stefano Zilli wrote:
>> Hello,
>>
>> We are currently testing Havana python-{cinder,nova,keystone}client rpms and we noticed that completion files have been moved to /etc/profile.d.
>> This is causing the following errors in zsh shells and, as a consequence, it's blocking the deployment in production.
>>
>> /etc/profile.d/cinder.sh:15: command not found: complete
>> /etc/profile.d/keystone.sh:27: command not found: complete
>> /etc/profile.d/nova.sh:27: command not found: complete
>>
>> Wouldn't be better to have some kind of guard at the beginning of those files like "[ -z "$BASH_VERSION" ] && return" to avoid the execution on non-bash shells?
> 
> Right, sane thing to do is to place them in /etc/bash_completion.d, 
> which requires bash-completion package, to avoid such errors.

For RDO/Fedora, these are put into /etc/bash_completion.d, but since RHEL doesn't have bash-completion package, they're put to /etc/profile.d for RDO/epel-6.

I planned to move them to /etc/bash-completion.d with RHEL 7 which will include bash-completion package but if this is causing troubles already, I can make even epel-6 RDO packages use bash-completion because RDO already requires epel which provides bash-completion.

This is about RDO Havana, right?


Jakub



From daniel at speichert.pl  Mon Jan 27 15:35:05 2014
From: daniel at speichert.pl (Daniel Speichert)
Date: Mon, 27 Jan 2014 16:35:05 +0100 (CET)
Subject: [Rdo-list] Glance - missing dependencies
In-Reply-To: <20140127095124.GB3785@redhat.com>
References: <654319.982.1390597235358.JavaMail.Daniel@Daniel-PC>
	<26266171.983.1390597259780.JavaMail.Daniel@Daniel-PC>
	<20140124211744.GA32214@redhat.com>
	<30279150.999.1390598408544.JavaMail.Daniel@Daniel-PC>
	<20140127090616.GA3785@redhat.com> <52E62537.40401@redhat.com>
	<20140127095124.GB3785@redhat.com>
Message-ID: <11968608.1383.1390836884558.JavaMail.Daniel@Daniel-PC>


----- Original Message -----
> From: "Flavio Percoco" 
> To: "P?draig Brady" 
> Cc: "Daniel Speichert" , rdo-list at redhat.com
> Sent: Monday, January 27, 2014 4:51:24 AM
> Subject: Re: [Rdo-list] Glance - missing dependencies
> 
> >
> >Note glance only used these libs when notifications were configured,
> >which wasn't previously done by default. So either that is
> >configured
> >or there is new glance logic requiring such messaging in place.
> >
> 
> This hasn't changed in Glance. Notification's are still optional (the
> default is noop) and the above dependencies are required just when
> rabbit is enabled.
> 
> Cheers,
> FF
> 

Does that mean that these packages (python-amqplib python-anyjson) will not be added as dependencies?

Regards,
Daniel Speichert



From daniel at speichert.pl  Mon Jan 27 15:40:01 2014
From: daniel at speichert.pl (Daniel Speichert)
Date: Mon, 27 Jan 2014 16:40:01 +0100 (CET)
Subject: [Rdo-list] Glance does not save properties of images
Message-ID: <13085627.1386.1390837182915.JavaMail.Daniel@Daniel-PC>

Hello,

On the stable release of Havana installed through RDO, when I create images, their properties (disk_format, container_format, is_public) are lost even when set (they must be set, otherwise glance-api wouldn't accept the request).

However, they are not saved to the database. When I modify database manually, they are visible correctly, but it is still not possible to modify them through Glance.

Do you have any idea if that might be some configuration error or maybe a bug in RDO packaging?

Any help will be very much appreciated.

Best Regards,
Daniel Speichert



From lars at redhat.com  Mon Jan 27 16:15:56 2014
From: lars at redhat.com (Lars Kellogg-Stedman)
Date: Mon, 27 Jan 2014 11:15:56 -0500
Subject: [Rdo-list] Glance does not save properties of images
In-Reply-To: <13085627.1386.1390837182915.JavaMail.Daniel@Daniel-PC>
References: <13085627.1386.1390837182915.JavaMail.Daniel@Daniel-PC>
Message-ID: <20140127161555.GA7651@redhat.com>

On Mon, Jan 27, 2014 at 04:40:01PM +0100, Daniel Speichert wrote:
> However, they are not saved to the database. When I modify database
> manually, they are visible correctly, but it is still not possible
> to modify them through Glance.

Is glance logging any errors (to /var/log/glance.log) when you create
images?

Also, on what distribution are you running OpenStack --
RHEL/CentOS/Fedora?  And can you confirm the version of glance you are
using?  In theory:

    rpm -q openstack-glance

Thanks,

-- 
Lars Kellogg-Stedman  | larsks @ irc
Cloud Engineering / OpenStack          | "   "  @ twitter

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 

From daniel at speichert.pl  Mon Jan 27 16:26:11 2014
From: daniel at speichert.pl (Daniel Speichert)
Date: Mon, 27 Jan 2014 17:26:11 +0100 (CET)
Subject: [Rdo-list] Glance does not save properties of images
In-Reply-To: <20140127161555.GA7651@redhat.com>
References: <13085627.1386.1390837182915.JavaMail.Daniel@Daniel-PC>
	<20140127161555.GA7651@redhat.com>
Message-ID: <31213435.1409.1390839949745.JavaMail.Daniel@Daniel-PC>

----- Original Message -----
> From: "Lars Kellogg-Stedman" 
> To: "Daniel Speichert" 
> Cc: rdo-list at redhat.com
> Sent: Monday, January 27, 2014 11:15:56 AM
> Subject: Re: [Rdo-list] Glance does not save properties of images
>
> Is glance logging any errors (to /var/log/glance.log) when you create
> images?
> 
> Also, on what distribution are you running OpenStack --
> RHEL/CentOS/Fedora?  And can you confirm the version of glance you
> are
> using?  In theory:
> 
>     rpm -q openstack-glance
> 
> Thanks,
> 
> --
> Lars Kellogg-Stedman  | larsks @ irc
> Cloud Engineering / OpenStack          | "   "  @ twitter
> 

It's CentOS 6.5.
Glance version: openstack-glance-2013.2-1.el6.noarch

Absolutely no errors in the log. Debug log doesn't show anything meaningful to me, I also tried sqlalchemy_debug but no errors there either.
It does however pass empty attributes in the SQL query:

/var/log/glance/registry.log:
2014-01-27 15:31:29.137 28699 INFO sqlalchemy.engine.base.Engine [-] INSERT INTO images (created_at, updated_at, deleted_at, deleted, id, name, disk_format, container_format, size, status, is_public, checksum, min_disk, min_ram, owner, protected) VALUES (%s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s)
2014-01-27 15:31:29.137 28699 INFO sqlalchemy.engine.base.Engine [-] (datetime.datetime(2014, 1, 27, 15, 31, 29, 136383), datetime.datetime(2014, 1, 27, 15, 31, 29, 136401), None, 0, 'e4856dce-67ba-4185-8871-3433400ba3c6', 'Ubuntu Server 13.10 1', None, None, 0, 'queued', 0, None, 0, 0, 'a8643be6b41f4e35950b1cc78f39e93a', 0)

Best Regards,
Daniel Speichert 



From xzhao at bnl.gov  Mon Jan 27 19:30:46 2014
From: xzhao at bnl.gov (Xin Zhao)
Date: Mon, 27 Jan 2014 14:30:46 -0500
Subject: [Rdo-list] [rhos-list] instances with ephemeral disk can't
	start ?
In-Reply-To: <52E2EC8A.1010808@redhat.com>
References: <52E2E63F.8040305@bnl.gov> <52E2EC8A.1010808@redhat.com>
Message-ID: <52E6B3E6.9050509@bnl.gov>

Hello,

Thanks for the info. Is there an ETA on this? We need to have this 
feature working in order for our users to continue their
testing. Is there patches I can apply myself ?

Thanks,
Xin

On 1/24/2014 5:43 PM, Perry Myers wrote:
> On 01/24/2014 05:16 PM, Xin Zhao wrote:
>> Hello,
>>
>> In our grizzly openstack testbed, instances that use ephemeral disk fail
>> to run, in the scheduler log there is the following errors:
>>
>> scheduler.log:2014-01-24 16:43:55.772 ERROR
>> nova.scheduler.filter_scheduler
>> [req-32173fb7-8d49-4d17-8490-4a6ddaf18a67
>> 45a137d469c940cab24655ce65a8455e 614dfb1842824ded94893d0e4c2525dc]
>> [instance: 799b985a-eba5-49ef-80b9-c515fa0523c2] Error from last host:
>> cldh0195.cloud.local (node cldh0195.cloud.local): [u'Traceback (most
>> recent call last):\n', u'  File
>> "/usr/lib/python2.6/site-packages/nova/compute/manager.py", line 864, in
>> _run_instance\n    set_access_ip=set_access_ip)\n', u'  File
>> "/usr/lib/python2.6/site-packages/nova/compute/manager.py", line 1123,
>> in _spawn\n    LOG.exception(_(\'Instance failed to spawn\'),
>> instance=instance)\n', u'  File "/usr/lib64/python2.6/contextlib.py",
>> line 23, in __exit__\n    self.gen.next()\n', u'  File
>> "/usr/lib/python2.6/site-packages/nova/compute/manager.py", line 1119,
>> in _spawn\n    block_device_info)\n', u'  File
>> "/usr/lib/python2.6/site-packages/nova/virt/libvirt/driver.py", line
>> 1540, in spawn\n    admin_pass=admin_password)\n', u'  File
>> "/usr/lib/python2.6/site-packages/nova/virt/libvirt/driver.py", line
>> 1842, in _create_image\n    ephemeral_size=ephemeral_gb)\n', u'  File
>> "/usr/lib/python2.6/site-packages/nova/virt/libvirt/imagebackend.py",
>> line 158, in cache\n    *args, **kwargs)\n', u'  File
>> "/usr/lib/python2.6/site-packages/nova/virt/libvirt/imagebackend.py",
>> line 291, in create_image\n    prepare_template(target=base,
>> max_size=size, *args, **kwargs)\n', u'  File
>> "/usr/lib/python2.6/site-packages/nova/openstack/common/lockutils.py",
>> line 228, in inner\n    retval = f(*args, **kwargs)\n', u'  File
>> "/usr/lib/python2.6/site-packages/nova/virt/libvirt/imagebackend.py",
>> line 146, in call_if_not_exists\n    fetch_func(target=target, *args,
>> **kwargs)\n', u"/TypeError: _create_ephemeral() got an unexpected
>> keyword argument 'max_size'/\n"]
>>
>> I see a bug report like this :
>> https://bugzilla.redhat.com/show_bug.cgi?id=1044562, I wonder if this
>> bug is fixed in grizzly or not?
> This bug is currently being QA'd for an async release of RHOS 3.0/Grizzly.
>
> It is not yet released for RHOS 3.0 since it is still in testing.  It
> should be updated soon on our content mirrors (Red Hat Network)
>
> If it is not a candidate for the stable branch of Grizzly, then it
> wouldn't be in RDO Grizzly as RDO follows the upstream stable branches.
>
> Vladan, since you are working on this, did it get proposed for the
> stable branch or is it RHOS only backport?
>
>> I am using grizzly rpms from the RDO repo:
>>
>> $> rpm -qf
>> /usr/lib/python2.6/site-packages/nova/virt/libvirt/imagebackend.py
>> python-nova-2013.1.4-1.el6.noarch
> Since this is RDO related, I'm going to move this thread over to rdo-list.
>
> Cheers,
>
> Perry



From pbrady at redhat.com  Mon Jan 27 20:37:42 2014
From: pbrady at redhat.com (=?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?=)
Date: Mon, 27 Jan 2014 20:37:42 +0000
Subject: [Rdo-list] Glance - missing dependencies
In-Reply-To: <11968608.1383.1390836884558.JavaMail.Daniel@Daniel-PC>
References: <654319.982.1390597235358.JavaMail.Daniel@Daniel-PC>
	<26266171.983.1390597259780.JavaMail.Daniel@Daniel-PC>
	<20140124211744.GA32214@redhat.com>
	<30279150.999.1390598408544.JavaMail.Daniel@Daniel-PC>
	<20140127090616.GA3785@redhat.com> <52E62537.40401@redhat.com>
	<20140127095124.GB3785@redhat.com>
	<11968608.1383.1390836884558.JavaMail.Daniel@Daniel-PC>
Message-ID: <52E6C396.4030708@redhat.com>

On 01/27/2014 03:35 PM, Daniel Speichert wrote:
> 
> ----- Original Message -----
>> From: "Flavio Percoco" 
>> To: "P?draig Brady" 
>> Cc: "Daniel Speichert" , rdo-list at redhat.com
>> Sent: Monday, January 27, 2014 4:51:24 AM
>> Subject: Re: [Rdo-list] Glance - missing dependencies
>>
>>>
>>> Note glance only used these libs when notifications were configured,
>>> which wasn't previously done by default. So either that is
>>> configured
>>> or there is new glance logic requiring such messaging in place.
>>>
>>
>> This hasn't changed in Glance. Notification's are still optional (the
>> default is noop) and the above dependencies are required just when
>> rabbit is enabled.
>>
>> Cheers,
>> FF
> 
> Does that mean that these packages (python-amqplib python-anyjson) will not be added as dependencies?

If you have notifications enabled then we probably should add these dependencies.
If you do not have notifications enabled then we should definitely add them.

thanks,
P?draig.



From pbrady at redhat.com  Mon Jan 27 20:40:52 2014
From: pbrady at redhat.com (=?ISO-8859-1?Q?P=E1draig_Brady?=)
Date: Mon, 27 Jan 2014 20:40:52 +0000
Subject: [Rdo-list] [rhos-list] instances with ephemeral disk can't
 start ?
In-Reply-To: <52E6B3E6.9050509@bnl.gov>
References: <52E2E63F.8040305@bnl.gov> <52E2EC8A.1010808@redhat.com>
	<52E6B3E6.9050509@bnl.gov>
Message-ID: <52E6C454.10702@redhat.com>

On 01/27/2014 07:30 PM, Xin Zhao wrote:
> Hello,
> 
> Thanks for the info. Is there an ETA on this? We need to have this feature working in order for our users to continue their
> testing. Is there patches I can apply myself ?

2013.1.4-6 available through the RDO grizzly repos 2 days ago,
should have this fix in place.

thanks,
P?draig.



From daniel at speichert.pl  Mon Jan 27 20:43:38 2014
From: daniel at speichert.pl (Daniel Speichert)
Date: Mon, 27 Jan 2014 21:43:38 +0100 (CET)
Subject: [Rdo-list] Glance - missing dependencies
In-Reply-To: <52E6C396.4030708@redhat.com>
References: <654319.982.1390597235358.JavaMail.Daniel@Daniel-PC>
	<20140124211744.GA32214@redhat.com>
	<30279150.999.1390598408544.JavaMail.Daniel@Daniel-PC>
	<20140127090616.GA3785@redhat.com> <52E62537.40401@redhat.com>
	<20140127095124.GB3785@redhat.com>
	<11968608.1383.1390836884558.JavaMail.Daniel@Daniel-PC>
	<52E6C396.4030708@redhat.com>
Message-ID: <26603588.1461.1390855394765.JavaMail.Daniel@Daniel-PC>

----- Original Message -----
> From: "P?draig Brady" 
> To: "Daniel Speichert" 
> Cc: "Flavio Percoco" , rdo-list at redhat.com
> Sent: Monday, January 27, 2014 3:37:42 PM
> Subject: Re: [Rdo-list] Glance - missing dependencies
> 
> If you have notifications enabled then we probably should add these
> dependencies.
> If you do not have notifications enabled then we should definitely
> add them.
> 
> thanks,
> P?draig.
 
Yes, I do have notifications enabled. That is the only way to have Ceilometer working with Glance, so quite useful feature.
Please add the dependencies :)

Best Regards,
Daniel Speichert



From xzhao at bnl.gov  Mon Jan 27 21:47:57 2014
From: xzhao at bnl.gov (Xin Zhao)
Date: Mon, 27 Jan 2014 16:47:57 -0500
Subject: [Rdo-list] [rhos-list] instances with ephemeral disk can't
 start ?
In-Reply-To: <52E6C454.10702@redhat.com>
References: <52E2E63F.8040305@bnl.gov> <52E2EC8A.1010808@redhat.com>
	<52E6B3E6.9050509@bnl.gov> <52E6C454.10702@redhat.com>
Message-ID: <52E6D40D.60102@bnl.gov>

Yes, the new version does fix the problem.

Thanks!
Xin

On 1/27/2014 3:40 PM, P?draig Brady wrote:
> On 01/27/2014 07:30 PM, Xin Zhao wrote:
>> Hello,
>>
>> Thanks for the info. Is there an ETA on this? We need to have this feature working in order for our users to continue their
>> testing. Is there patches I can apply myself ?
> 2013.1.4-6 available through the RDO grizzly repos 2 days ago,
> should have this fix in place.
>
> thanks,
> P?draig.



From pbrady at redhat.com  Mon Jan 27 22:19:01 2014
From: pbrady at redhat.com (=?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?=)
Date: Mon, 27 Jan 2014 22:19:01 +0000
Subject: [Rdo-list] [package announce] Updated foreman installer
Message-ID: <52E6DB55.9070308@redhat.com>

RDO Havana and Icehouse provide the foreman openstack installer for EL6 derivatives,
and this has been updated to version 1.0.3 which includes:

- BZ #1047653 - Cinder LVM setup broken
- BZ #1053729 - Add missed parameter name change
- BZ #1048922 - Package name cannot have array for newer puppet
- BZ #1050182 - remove the Gluster Storage Host Group
- BZ #1049688 - Quickstack manifest parameter renaming
- BZ #1046120 - Remove unused parameter bridge_keep_ip
- BZ #1015625 - Add selinux support for glusterfs config
- BZ #1043964 - Fix to move neutron setup after db setup
- BZ #1048922 - Fix horizon packages install with puppet-3.4
- BZ #1045132 - l3 external_network_bridge now configurable
- BZ #1045137 - Ensure physical ports added to ovs bridge on networker
- BZ #1042933 - neutron-server fails to start (stamp issue)
- BZ #1040610 - Open Ceilometer API port on controller node
- BZ #1042862 - Update RHEL OS description
- BZ #1043634 - Swift Storage manifest uses incorrect variable
- BZ #1039661 - Fix manifests to work with updated puppet modules
- BZ #1039698 - add IPAPPEND 2 to pxe template
- BZ #1040021 - Fix enable/disable of heat_cfg and heat_cloudwatch



From flavio at redhat.com  Tue Jan 28 08:37:27 2014
From: flavio at redhat.com (Flavio Percoco)
Date: Tue, 28 Jan 2014 09:37:27 +0100
Subject: [Rdo-list] Glance does not save properties of images
In-Reply-To: <31213435.1409.1390839949745.JavaMail.Daniel@Daniel-PC>
References: <13085627.1386.1390837182915.JavaMail.Daniel@Daniel-PC>
	<20140127161555.GA7651@redhat.com>
	<31213435.1409.1390839949745.JavaMail.Daniel@Daniel-PC>
Message-ID: <20140128083727.GA13030@redhat.com>

On 27/01/14 17:26 +0100, Daniel Speichert wrote:
>----- Original Message -----
>> From: "Lars Kellogg-Stedman" 
>> To: "Daniel Speichert" 
>> Cc: rdo-list at redhat.com
>> Sent: Monday, January 27, 2014 11:15:56 AM
>> Subject: Re: [Rdo-list] Glance does not save properties of images
>>
>> Is glance logging any errors (to /var/log/glance.log) when you create
>> images?
>>
>> Also, on what distribution are you running OpenStack --
>> RHEL/CentOS/Fedora?  And can you confirm the version of glance you
>> are
>> using?  In theory:
>>
>>     rpm -q openstack-glance
>>
>> Thanks,
>>
>> --
>> Lars Kellogg-Stedman  | larsks @ irc
>> Cloud Engineering / OpenStack          | "   "  @ twitter
>>
>
>It's CentOS 6.5.
>Glance version: openstack-glance-2013.2-1.el6.noarch
>
>Absolutely no errors in the log. Debug log doesn't show anything meaningful to me, I also tried sqlalchemy_debug but no errors there either.
>It does however pass empty attributes in the SQL query:
>
>/var/log/glance/registry.log:
>2014-01-27 15:31:29.137 28699 INFO sqlalchemy.engine.base.Engine [-] INSERT INTO images (created_at, updated_at, deleted_at, deleted, id, name, disk_format, container_format, size, status, is_public, checksum, min_disk, min_ram, owner, protected) VALUES (%s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s)
>2014-01-27 15:31:29.137 28699 INFO sqlalchemy.engine.base.Engine [-] (datetime.datetime(2014, 1, 27, 15, 31, 29, 136383), datetime.datetime(2014, 1, 27, 15, 31, 29, 136401), None, 0, 'e4856dce-67ba-4185-8871-3433400ba3c6', 'Ubuntu Server 13.10 1', None, None, 0, 'queued', 0, None, 0, 0, 'a8643be6b41f4e35950b1cc78f39e93a', 0)
>


Could you please share the commands your using?

    - How are you adding the properties?
    - How are you reading the propoerties?

You're sharing your registry.log configurations which means you've
configured the registry. Could you share how you did that?

Thanks,
flaper

>Best Regards,
>Daniel Speichert
>
>_______________________________________________
>Rdo-list mailing list
>Rdo-list at redhat.com
>https://www.redhat.com/mailman/listinfo/rdo-list

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 

From kchamart at redhat.com  Tue Jan 28 13:35:04 2014
From: kchamart at redhat.com (Kashyap Chamarthy)
Date: Tue, 28 Jan 2014 19:05:04 +0530
Subject: [Rdo-list] If you're running into - 1049391 (openstack-nova-compute
 service fails) on Fedora 20/IceHouse. . .
Message-ID: <52E7B208.2020501@redhat.com>

Heya,

If this Libvirt bug[1] is blocking you from getting Nova Compute service
start, there's a yet-to-be reviewed patch upstream libvirt[2], I made a
scratch build w/ that fix here(*only for testing*, official build will
be made once the fix is in the upstream libvirt maintenance branches):

  http://koji.fedoraproject.org/koji/taskinfo?taskID=6462663

I tested it on my IceHouse, Fedora-20 setup and the said bug is fixed,
for me.

Once you apply the RPMs, restart libvirtd and Compute service:

    $ systemctl restart libvirtd
    $ systemctl restart openstack-nova-compute

Ensure Compute service cam up sanely:

    $ systemctl status openstack-nova-compute



[1] https://bugzilla.redhat.com/show_bug.cgi?id=1049391 --
openstack-nova-compute service fails with - libvirtError: internal
error: CPU feature `avx' specified more than once

[2] https://www.redhat.com/archives/libvir-list/2014-January/msg01313.html


-- 
/kashyap



From rbowen at redhat.com  Tue Jan 28 14:48:08 2014
From: rbowen at redhat.com (Rich Bowen)
Date: Tue, 28 Jan 2014 09:48:08 -0500
Subject: [Rdo-list] RDO community IRC meeting summary, 2014-01-28
Message-ID: <52E7C328.3020507@redhat.com>

For those who missed it, here's the notes from this morning's RDO IRC 
sync. Please send any questions or comments to this mailing list. Thanks!

Minutes: 
http://meetbot.fedoraproject.org/rdo/2014-01-28/rdo.2014-01-28-14.03.html
Log: 
http://meetbot.fedoraproject.org/rdo/2014-01-28/rdo.2014-01-28-14.03.log.html

--rcb

-- 
Rich Bowen - rbowen at redhat.com
OpenStack Community Liaison
http://openstack.redhat.com/



From bnemec at redhat.com  Tue Jan 28 15:56:43 2014
From: bnemec at redhat.com (Ben Nemec)
Date: Tue, 28 Jan 2014 10:56:43 -0500 (EST)
Subject: [Rdo-list] Fedora 20 / Devstack Networking Issues
In-Reply-To: <52E66E14.5070707@redhat.com>
References: <52E496A1.20807@redhat.com> <52E66E14.5070707@redhat.com>
Message-ID: <265473075.6391595.1390924603943.JavaMail.root@redhat.com>



----- Original Message -----
> On 01/26/2014 12:01 AM, Perry Myers wrote:
> > Ok, I've been chasing down some networking issues along with some other
> > folks.  Here's what I'm seeing:
> > 
> > Starting with a vanilla F20 cloud image running on a F20 host, clone
> > devstack into it and run stack.sh.
> > 
> > First thing is that the RabbitMQ server issue I noted a few weeks ago is
> > still intermittently there.  So during the step where rabbitmqctl is run
> > to set the password of the rabbit admin user, it might fail and all
> > subsequent AMQP communication fails which makes a lot of the nova
> > commands in devstack also fail.
> > 
> > But... if you get past this error (since it is intermittent), then
> > devstack seems to complete successfully.  Standard commands like nova
> > list, keystone user-list, etc all work fine.
> > 
> > I did note though that access to Horizon does not work.  I need to
> > investigate this further.
> > 
> > But worse than that is when you run nova boot, the host to guest
> > networking (remember this is devstack running in a VM) immediately gets
> > disconnected.  This issue is 100% reproducible and multiple users are
> > reporting it (tsedovic, eharney, bnemec cc'd)
> > 
> > I did some investigation when this happens and here's what I found...
> > 
> > If I do:
> > 
> > $ brctl delif br100 eth0
> > 
> > I was immediately able to ping the guest from the host and vice versa.
> > 
> > If I reattach eth0 back to br100, networking stops again
> > 
> > Another thing... I notice that on the system br100 does not have an ip
> > address, but eth0 does.  I thought when doing bridged networking like
> > this, the bridge should have the ip address and the physical iface that
> > is attached to the bridge does not get an ip addr.
> > 
> > So... I tweaked /etc/sysconfig/network-scripts/ifcfg-eth0 to remove the
> > dhcp from the bootproto line and I copied ifcfg-eth0 to ifcfg-br100
> > allowing it to use bootproto dhcp
> > 
> > I brought both ifaces down and then brought them both up.  eth0 first
> > and br100 second
> > 
> > This time, br100 got the dhcp address from the host and networking
> > worked fine.
> > 
> > So is this just an issue with how nova is setting up bridges?
> > 
> > Since this network disconnect didn't happen until nova launched a vm, I
> > imagine this isn't a problem with devstack itself, but is likely an
> > issue with Nova Networking somehow.
> > 
> > Russell/DanS, is there any chance that all of the refactoring you did in
> > Nova Networking very recently introduce a regression?
> 
> I suppose it's possible.  You could try going back to before any of the
> nova-network-objects patches went in.  The first one to merge was:
> 
> commit a8c73c7d3298589440579d67e0c5638981dd7718
> Merge: a1f6e85 aa40c8f
> Author: Jenkins 
> Date:   Wed Jan 15 18:38:37 2014 +0000
> 
>     Merge "Make nova-network use Service object"
> 
> Try going back to before that and see if you get a different result.  If
> so, try using "git bisect" to find the offending commit.
> 
> --
> Russell Bryant
> 

I am still unable to reproduce the networking issue in my environment.  I booted a stock Fedora 20 cloud image, installed git, cloned devstack and ran it with a minimal localrc configuration (so using the defaults of nova-network and rabbitmq).  Other than the rabbitmq race issue that always makes my first stack.sh run on a new VM fail, I had no problem completing stack.sh and booting a nova instance.  The instance's IP was correctly moved to the bridge for me.  If this is a regression in nova network then it only presents in combination with some other circumstance that isn't present for me.

As I mentioned in our off-list discussion of this, I run my development VM's in a local OpenStack installation I have, so maybe there's some difference in the way the networking works there.  In any case, while I don't have an answer hopefully another data point will help in figuring this out.

-Ben



From rbowen at redhat.com  Tue Jan 28 21:28:26 2014
From: rbowen at redhat.com (Rich Bowen)
Date: Tue, 28 Jan 2014 16:28:26 -0500
Subject: [Rdo-list] RDO Icehouse Milestone 2 test day: February 4-5
In-Reply-To: <52DD47A2.3070302@redhat.com>
References: <52DD47A2.3070302@redhat.com>
Message-ID: <52E820FA.7030508@redhat.com>

A reminder, that next week we'll be doing the RDO Icehouse milestone 2 
test day. If you're able to participate, please let us know by signing 
up on the wiki page at 
http://openstack.redhat.com/RDO_test_day_Icehouse_milestone_2

Thanks!

--Rich

On 01/20/2014 10:58 AM, Rich Bowen wrote:
> With the Icehouse milestone 2 due on January 23rd, we're planning to 
> do another RDO test day on February 4-5, by which time we'll have 
> produced RDO packages for all the relevant platforms, and had a chance 
> to do some initial testing.
>
> As with the last test day, we'll be testing deployment on various 
> platforms, as well as more complex scenarios. You can see 
> http://openstack.redhat.com/TestedSetups_2014_01 for some idea of the 
> kinds of things we did last time, and we'd like to see more of the 
> list tested this time around.
>
> The page at 
> http://openstack.redhat.com/RDO_test_day_Icehouse_milestone_2 will 
> have more information as we get closer to the date, including a table 
> of things we'd like to get tested, and instructions on how to test 
> them and record your results.
>
> Thanks!
>
> --rcb
>
> -- 
> Rich Bowen -rbowen at redhat.com
> OpenStack Community Liaison
> http://openstack.redhat.com/
>
>
> _______________________________________________
> Rdo-list mailing list
> Rdo-list at redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list

-- 
Rich Bowen - rbowen at redhat.com
OpenStack Community Liaison
http://openstack.redhat.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From imcleod at redhat.com  Tue Jan 28 23:06:35 2014
From: imcleod at redhat.com (Ian McLeod)
Date: Tue, 28 Jan 2014 17:06:35 -0600
Subject: [Rdo-list] Fedora 20 / Devstack Networking Issues
In-Reply-To: <265473075.6391595.1390924603943.JavaMail.root@redhat.com>
References: <52E496A1.20807@redhat.com> <52E66E14.5070707@redhat.com>
	<265473075.6391595.1390924603943.JavaMail.root@redhat.com>
Message-ID: <1390950395.8426.71.camel@localhost.localdomain>

On Tue, 2014-01-28 at 10:56 -0500, Ben Nemec wrote:
> 
> ----- Original Message -----
> > On 01/26/2014 12:01 AM, Perry Myers wrote:
> > > Ok, I've been chasing down some networking issues along with some other
> > > folks.  Here's what I'm seeing:
> > > 
> > > Starting with a vanilla F20 cloud image running on a F20 host, clone
> > > devstack into it and run stack.sh.
> > > 
> > > First thing is that the RabbitMQ server issue I noted a few weeks ago is
> > > still intermittently there.  So during the step where rabbitmqctl is run
> > > to set the password of the rabbit admin user, it might fail and all
> > > subsequent AMQP communication fails which makes a lot of the nova
> > > commands in devstack also fail.
> > > 
> > > But... if you get past this error (since it is intermittent), then
> > > devstack seems to complete successfully.  Standard commands like nova
> > > list, keystone user-list, etc all work fine.
> > > 
> > > I did note though that access to Horizon does not work.  I need to
> > > investigate this further.
> > > 
> > > But worse than that is when you run nova boot, the host to guest
> > > networking (remember this is devstack running in a VM) immediately gets
> > > disconnected.  This issue is 100% reproducible and multiple users are
> > > reporting it (tsedovic, eharney, bnemec cc'd)
> > > 
> > > I did some investigation when this happens and here's what I found...
> > > 
> > > If I do:
> > > 
> > > $ brctl delif br100 eth0
> > > 
> > > I was immediately able to ping the guest from the host and vice versa.
> > > 
> > > If I reattach eth0 back to br100, networking stops again
> > > 
> > > Another thing... I notice that on the system br100 does not have an ip
> > > address, but eth0 does.  I thought when doing bridged networking like
> > > this, the bridge should have the ip address and the physical iface that
> > > is attached to the bridge does not get an ip addr.
> > > 
> > > So... I tweaked /etc/sysconfig/network-scripts/ifcfg-eth0 to remove the
> > > dhcp from the bootproto line and I copied ifcfg-eth0 to ifcfg-br100
> > > allowing it to use bootproto dhcp
> > > 
> > > I brought both ifaces down and then brought them both up.  eth0 first
> > > and br100 second
> > > 
> > > This time, br100 got the dhcp address from the host and networking
> > > worked fine.
> > > 
> > > So is this just an issue with how nova is setting up bridges?
> > > 
> > > Since this network disconnect didn't happen until nova launched a vm, I
> > > imagine this isn't a problem with devstack itself, but is likely an
> > > issue with Nova Networking somehow.
> > > 
> > > Russell/DanS, is there any chance that all of the refactoring you did in
> > > Nova Networking very recently introduce a regression?
> > 
> > I suppose it's possible.  You could try going back to before any of the
> > nova-network-objects patches went in.  The first one to merge was:
> > 
> > commit a8c73c7d3298589440579d67e0c5638981dd7718
> > Merge: a1f6e85 aa40c8f
> > Author: Jenkins 
> > Date:   Wed Jan 15 18:38:37 2014 +0000
> > 
> >     Merge "Make nova-network use Service object"
> > 
> > Try going back to before that and see if you get a different result.  If
> > so, try using "git bisect" to find the offending commit.
> > 
> > --
> > Russell Bryant
> > 
> 
> I am still unable to reproduce the networking issue in my environment.  I booted a stock Fedora 20 cloud image, installed git, cloned devstack and ran it with a minimal localrc configuration (so using the defaults of nova-network and rabbitmq).  Other than the rabbitmq race issue that always makes my first stack.sh run on a new VM fail, I had no problem completing stack.sh and booting a nova instance.  The instance's IP was correctly moved to the bridge for me.  If this is a regression in nova network then it only presents in combination with some other circumstance that isn't present for me.
> 
> As I mentioned in our off-list discussion of this, I run my development VM's in a local OpenStack installation I have, so maybe there's some difference in the way the networking works there.  In any case, while I don't have an answer hopefully another data point will help in figuring this out.

OK.  I can provide a data point that may or may not be useful.

I am getting the same behavior Perry reported.  Install is successful,
first VM launch kills the network.  After much head bashing and
experimentation I found that everything worked correctly if I assigned
the FLAT_INTERFACE in my localrc file to a second, unused NIC on my test
system.  e.g.

FLAT_INTERFACE=p4p2

Prior to that I'd had all of the various localrc interface variables
pointing to the single primary NIC. e.g.

HOST_IP_IFACE=p4p1
PUBLIC_INTERFACE=p4p1
VLAN_INTERFACE=p4p1
FLAT_INTERFACE=p4p1

This style of config (everything on one NIC) is advocated in the single
node getting started guide:

http://devstack.org/guides/single-machine.html

I observed this while testing on commit:

3f5250fff3007dfd1e5992c0cf229be9033a5726

-Ian

> 
> -Ben
> 
> _______________________________________________
> Rdo-list mailing list
> Rdo-list at redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list




From Jan.van.Eldik at cern.ch  Wed Jan 29 04:31:53 2014
From: Jan.van.Eldik at cern.ch (Jan van Eldik)
Date: Wed, 29 Jan 2014 05:31:53 +0100
Subject: [Rdo-list] pythonclients completion scripts raise errors on zsh
In-Reply-To: <52E67366.5010705@redhat.com>
References: <2DDF0FACD8B3CB4193010D75BFA894736DCC8286@CERNXCHG12.cern.ch>	<52E670F3.9050902@redhat.com>
	<52E67366.5010705@redhat.com>
Message-ID: <52E88439.7010103@cern.ch>

Hi Jakub,

> I planned to move them to /etc/bash-completion.d with RHEL 7 which will
> include bash-completion package but if this is causing troubles already,
> I can make even epel-6 RDO packages use bash-completion because RDO
> already requires epel which provides bash-completion.

That would be great. Our workaround is to remove the /etc/profile.d 
files, but a proper fox would be much better.

This concerns the 4 RPMs python-{cinder,nova,keystone,neutron}client 
(possibly more).

             tia, cheers, Jan



From daniel at speichert.pl  Wed Jan 29 14:30:56 2014
From: daniel at speichert.pl (Daniel Speichert)
Date: Wed, 29 Jan 2014 15:30:56 +0100 (CET)
Subject: [Rdo-list] Glance does not save properties of images
In-Reply-To: <20140128083727.GA13030@redhat.com>
References: <13085627.1386.1390837182915.JavaMail.Daniel@Daniel-PC>
	<20140127161555.GA7651@redhat.com>
	<31213435.1409.1390839949745.JavaMail.Daniel@Daniel-PC>
	<20140128083727.GA13030@redhat.com>
Message-ID: <8751501.1837.1391005828950.JavaMail.Daniel@Daniel-PC>

----- Original Message -----
> From: "Flavio Percoco" 
> To: "Daniel Speichert" 
> Cc: "Lars Kellogg-Stedman" , rdo-list at redhat.com
> Sent: Tuesday, January 28, 2014 3:37:27 AM
> Subject: Re: [Rdo-list] Glance does not save properties of images
> 
> 
> Could you please share the commands your using?
> 
>     - How are you adding the properties?
>     - How are you reading the propoerties?
> 
> You're sharing your registry.log configurations which means you've
> configured the registry. Could you share how you did that?
> 
> Thanks,
> flaper
> 

These are required properties when adding any Glance image (disk_format and container_format). I was trying to set is_public through 'glance image-edit' and Horizon. The change seems to be accepted (no error) but on subsequent image-show it's just not there.

Registry and API are set up almost by defaults:
glance-registry.conf: http://pastebin.com/M7Ybjnf9
glance-api.conf: http://pastebin.com/5sPXr3mG

Regards,
Daniel Speichert



From pmyers at redhat.com  Wed Jan 29 18:43:47 2014
From: pmyers at redhat.com (Perry Myers)
Date: Wed, 29 Jan 2014 13:43:47 -0500
Subject: [Rdo-list] [rhos-list] hi I have question(Loaded plugins:
	product-id.....)
In-Reply-To: <20140129094451.HM.F000000000GQdUx@wook-k.wwl1552.hanmail.net>
References: <20140129094451.HM.F000000000GQdUx@wook-k.wwl1552.hanmail.net>
Message-ID: <52E94BE3.602@redhat.com>

On 28/01/14 19:44, ?? wrote:
> I hope to install openstack allinone
> 
>  
> 
> # sudo yum install -y htt://rdo.fedorapeople.org/rdo-release.rpm

Hi,

Since you are asking about RDO, I'm going to move this thread over to
rdo-list instead of it being on rhos-list.

>  
> 
> so below message is showed
> 
>  
> 
> *Loaded plugins: product-id, security, subscription-manager*
> 
> *This system is not registered to Red Hat Subscription Management. You
> can use subscription-manager to register*
> 
> *Setting up Install Process*
> 
> *Cannot open : **http://rdo.fedorapeople.org/rdo-release.rpm**. Skipping.*

I just tried this exact command and it worked for me.  Is there a chance
your computer can't access the rdo.fedorapeople.org site?

The command I ran was:
> sudo yum install -y http://rdo.fedorapeople.org/rdo-release.rpm

Perry



From lars at redhat.com  Wed Jan 29 18:56:52 2014
From: lars at redhat.com (Lars Kellogg-Stedman)
Date: Wed, 29 Jan 2014 13:56:52 -0500
Subject: [Rdo-list] hi I have question(Loaded plugins: product-id.....)
In-Reply-To: <20140129094451.HM.F000000000GQdUx@wook-k.wwl1552.hanmail.net>
References: <20140129094451.HM.F000000000GQdUx@wook-k.wwl1552.hanmail.net>
Message-ID: <20140129185652.GB25659@redhat.com>

On Wed, Jan 29, 2014 at 09:44:51AM +0900, ?? wrote:
>    # sudo yum install -y htt://rdo.fedorapeople.org/rdo-release.rpm           

This may just be a typo in your email, but you're missing the "p" in
"http://" here.

>    Cannot open : http://rdo.fedorapeople.org/rdo-release.rpm. Skipping.       

You can try to download this package using another tool to see if that
gives you better diagnostic messages.  For example:

  wget http://rdo.fedorapeople.org/rdo-release.rpm

-- 
Lars Kellogg-Stedman  | larsks @ irc
Cloud Engineering / OpenStack          | "   "  @ twitter

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 

From jguiditt at redhat.com  Wed Jan 29 18:59:03 2014
From: jguiditt at redhat.com (Jason Guiditta)
Date: Wed, 29 Jan 2014 13:59:03 -0500
Subject: [Rdo-list] [rhos-list] hi I have question(Loaded plugins:
 product-id.....)
In-Reply-To: <52E94BE3.602@redhat.com>
References: <20140129094451.HM.F000000000GQdUx@wook-k.wwl1552.hanmail.net>
	<52E94BE3.602@redhat.com>
Message-ID: <20140129185903.GA4414@redhat.com>

On 29/01/14 13:43 -0500, Perry Myers wrote:
>On 28/01/14 19:44, ?? wrote:
>> I hope to install openstack allinone
>>
>>
>>
>> # sudo yum install -y htt://rdo.fedorapeople.org/rdo-release.rpm
>
Not sure if this is just a typo in the email, but the above command is
missing the 'p' in 'http'.

-j



From rbowen at redhat.com  Wed Jan 29 20:49:35 2014
From: rbowen at redhat.com (Rich Bowen)
Date: Wed, 29 Jan 2014 15:49:35 -0500
Subject: [Rdo-list] Call for Papers - OSCON and OpenStack Day at LinuxTag
	Berlin
In-Reply-To: <1391020987.81123010@webmail.emailsrvr.com>
References: <1391020987.81123010@webmail.emailsrvr.com>
Message-ID: <52E9695F.9040301@redhat.com>

FYI: Two more venues for getting the word out about RDO and OpenStack


-------- Original Message --------
Subject: 	[openstack-community] Call for Papers - OSCON and OpenStack 
Day at LinuxTag Berlin
Date: 	Wed, 29 Jan 2014 12:43:07 -0600 (CST)
From: 	Kathy Cacciatore 
To: 	community at lists.openstack.org, marketing at lists.openstack.org



Just a reminder that the OSCON (Open Source Conference, July 20-24 in 
Portland, OR) CFP submissions are due tomorrow, *January 30*.  Please 
submit DevOps topics of interest to 
http://www.oscon.com/oscon2014/public/cfp/308.  We'd love to have a long 
list of OpenStack sessions there this year, for OpenStack's 4th 
birthday.  We'll help drive attendees to all accepted sessions.

Also, just out, is the Call for Papers for the OpenStack Day at LinuxTag 
in Berlin on May 9.  Florian Haas and Martin Loschwitz of hastexo are 
organizing the track titled "OpenStack: One IaaS platform for all 
needs".  This is the Friday prior to the Atlanta OpenStack Summit; 
speaker submissions are very much appreciated.  Please use the LinuxTag 
CFP submission process  *by February 
7*, and also drop an email to Florian and Martin at florian at hastexo.com 
and martin at hastexo.com. They welcome your inquiries as well.

Thank you for your support.

-- 
Regards,

Kathy Cacciatore
OpenStack Industry Event Planner
1-512-970-2807 (mobile)
Part time: Monday - Thursday, 9am - 2pm US CT
kathyc at openstack.org



-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From kchamart at redhat.com  Thu Jan 30 05:15:29 2014
From: kchamart at redhat.com (Kashyap Chamarthy)
Date: Thu, 30 Jan 2014 10:45:29 +0530
Subject: [Rdo-list] Neutron configuration files for a two node
	Neutron+GRE+OVS
Message-ID: <52E9DFF1.7020301@redhat.com>

Heya,

Just in case if it's useful for someone, here are my working Neutron
configuration files (and iptables rules) for a two node set-up based on
IceHouse-M2 on Fedora-20,

  - Controller node: Nova, Keystone (token-based auth), Cinder,
    Glance, Neutron (using Open vSwitch plugin and GRE tunneling).

  - Compute node: Nova (nova-compute), Neutron (openvswitch-agent)


Controller node Neutron configurations
======================================

1. neutron.conf
---------------

    $ cat /etc/neutron/neutron.conf | grep -v ^$ | grep -v ^#
    [DEFAULT]
    core_plugin
=neutron.plugins.openvswitch.ovs_neutron_plugin.OVSNeutronPluginV2
    rpc_backend = neutron.openstack.common.rpc.impl_qpid
    control_exchange = neutron
    qpid_hostname = 192.169.142.49
    auth_strategy = keystone
    allow_overlapping_ips = True
    dhcp_lease_duration = 120
    allow_bulk = True
    qpid_port = 5672
    qpid_heartbeat = 60
    qpid_protocol = tcp
    qpid_tcp_nodelay = True
    qpid_reconnect_limit=0
    qpid_reconnect_interval_max=0
    qpid_reconnect_timeout=0
    qpid_reconnect=True
    qpid_reconnect_interval_min=0
    qpid_reconnect_interval=0
    debug = False
    verbose = False
    [quotas]
    [agent]
    [keystone_authtoken]
    admin_tenant_name = services
    admin_user = neutron
    admin_password = fedora
    auth_host = 192.169.142.49
    auth_port = 35357
    auth_protocol = http
    auth_uri=http://192.169.142.49:5000/
    [database]
    [service_providers]
    [AGENT]
    root_helper = sudo neutron-rootwrap /etc/neutron/rootwrap.conf

2. (OVS) plugin.ini
-------------------

    $ cat /etc/neutron/plugin.ini | grep -v ^$ | grep -v ^#
    [ovs]
    tenant_network_type = gre
    tunnel_id_ranges = 1:1000
    enable_tunneling = True
    integration_bridge = br-int
    tunnel_bridge = br-tun
    local_ip = 192.169.142.49
    [agent]
    [securitygroup]
    [DATABASE]
    sql_connection = mysql://neutron:fedora at node1-controller/ovs_neutron
    sql_max_retries=10
    reconnect_interval=2
    sql_idle_timeout=3600
    [SECURITYGROUP]
    firewall_driver =
neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver

3. dhcp_agent.ini
-----------------

    $ cat /etc/neutron/dhcp_agent.ini | grep -v ^$ | grep -v ^#
    [DEFAULT]
    interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver
    handle_internal_only_routers = TRUE
    external_network_bridge = br-ex
    use_namespaces = True
    dnsmasq_config_file = /etc/neutron/dnsmasq.conf

4. l3_agent.ini
---------------

    $ cat /etc/neutron/dhcp_agent.ini | grep -v ^$ | grep -v ^#
    [DEFAULT]
    interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver
    handle_internal_only_routers = TRUE
    external_network_bridge = br-ex
    use_namespaces = True
    dnsmasq_config_file = /etc/neutron/dnsmasq.conf

5. dnsmasq.conf
---------------

This logs dnsmasq output is to a file, instead of journalctl):

    $ cat /etc/neutron/dnsmasq.conf | grep -v ^$ | grep -v ^#
    log-facility = /var/log/neutron/dnsmasq.log
    log-dhcp

6. api-paste.ini
----------------

    $ cat /etc/neutron/api-paste.ini | grep -v ^$ | grep -v ^#
    [composite:neutron]
    use = egg:Paste#urlmap
    /: neutronversions
    /v2.0: neutronapi_v2_0
    [composite:neutronapi_v2_0]
    use = call:neutron.auth:pipeline_factory
    noauth = extensions neutronapiapp_v2_0
    keystone = authtoken keystonecontext extensions neutronapiapp_v2_0
    [filter:keystonecontext]
    paste.filter_factory = neutron.auth:NeutronKeystoneContext.factory
    [filter:authtoken]
    paste.filter_factory =
keystoneclient.middleware.auth_token:filter_factory
    admin_user=neutron
    auth_port=35357
    admin_password=fedora
    auth_protocol=http
    auth_uri=http://192.169.142.49:5000/
    admin_tenant_name=services
    auth_host = 192.169.142.49
    [filter:extensions]
    paste.filter_factory =
neutron.api.extensions:plugin_aware_extension_middleware_factory
    [app:neutronversions]
    paste.app_factory = neutron.api.versions:Versions.factory
    [app:neutronapiapp_v2_0]
    paste.app_factory = neutron.api.v2.router:APIRouter.factory

7. metadata_agent.ini
---------------------

    $ cat /etc/neutron/metadata_agent.ini | grep -v ^$ | grep -v ^#
    [DEFAULT]
    auth_url = http://192.169.142.49:35357/v2.0/
    auth_region = regionOne
    admin_tenant_name = services
    admin_user = neutron
    admin_password = fedora
    nova_metadata_ip = 192.168.142.49
    nova_metadata_port = 8775
    metadata_proxy_shared_secret = fedora


Compute node Neutron configurations
===================================

1. neutron.conf
---------------

    $ cat /etc/neutron/neutron.conf | grep -v ^$ | grep -v ^#
    [DEFAULT]
    core_plugin
=neutron.plugins.openvswitch.ovs_neutron_plugin.OVSNeutronPluginV2
    rpc_backend = neutron.openstack.common.rpc.impl_qpid
    qpid_hostname = 192.169.142.49
    auth_strategy = keystone
    allow_overlapping_ips = True
    qpid_port = 5672
    debug = True
    verbose = True
    [quotas]
    [agent]
    [keystone_authtoken]
    admin_tenant_name = services
    admin_user = neutron
    admin_password = fedora
    auth_host = 192.169.142.49
    [database]
    [service_providers]
    [AGENT]
    root_helper = sudo neutron-rootwrap /etc/neutron/rootwrap.conf

2. (OVS) plugin.ini
-------------------

    $ cat plugin.ini | grep -v ^$ | grep -v ^#
    [ovs]
    tenant_network_type = gre
    tunnel_id_ranges = 1:1000
    enable_tunneling = True
    integration_bridge = br-int
    tunnel_bridge = br-tun
    local_ip = 192.169.142.57
    [DATABASE]
    sql_connection = mysql://neutron:fedora at node1-controller/ovs_neutron
    [SECURITYGROUP]
    firewall_driver =
neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
    [agent]
    [securitygroup]

3. metadata_agent.ini
---------------------

    $ cat metadata_agent.ini | grep -v ^$ | grep -v ^#
    [DEFAULT]
    auth_url = http://localhost:5000/v2.0
    auth_region = RegionOne
    admin_tenant_name = %SERVICE_TENANT_NAME%
    admin_user = %SERVICE_USER%
    admin_password = %SERVICE_PASSWORD%


iptables rules on both Controller and Compute nodes
===================================================

iptables on Controller node
---------------------------

    $ cat /etc/sysconfig/iptables
    *filter
    :INPUT ACCEPT [0:0]
    :FORWARD ACCEPT [0:0]
    :OUTPUT ACCEPT [0:0]
    -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
    -A INPUT -p icmp -j ACCEPT
    -A INPUT -i lo -j ACCEPT
    -A INPUT -p tcp -m multiport --dports 3260 -m comment --comment "001
cinder incoming" -j ACCEPT
    -A INPUT -p tcp -m multiport --dports 80 -m comment --comment "001
horizon incoming" -j ACCEPT
    -A INPUT -p tcp -m multiport --dports 9292 -m comment --comment "001
glance incoming" -j ACCEPT
    -A INPUT -p tcp -m multiport --dports 5000,35357 -m comment
--comment "001 keystone incoming" -j ACCEPT
    -A INPUT -p tcp -m multiport --dports 3306 -m comment --comment "001
mariadb incoming" -j ACCEPT
    -A INPUT -p tcp -m multiport --dports 6080 -m comment --comment "001
novncproxy incoming" -j ACCEPT
    -A INPUT -p tcp -m multiport --dports 8770:8780 -m comment --comment
"001 novaapi incoming" -j ACCEPT
    -A INPUT -p tcp -m multiport --dports 9696 -m comment --comment "001
neutron incoming" -j ACCEPT
    -A INPUT -p tcp -m multiport --dports 5672 -m comment --comment "001
qpid incoming" -j ACCEPT
    -A INPUT -p tcp -m multiport --dports 8700 -m comment --comment "001
metadata incoming" -j ACCEPT
    -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
    -A INPUT -m state --state NEW -m tcp -p tcp --dport 5900:5999 -j ACCEPT
    -A INPUT -j REJECT --reject-with icmp-host-prohibited
    -A INPUT -p gre -j ACCEPT
    -A OUTPUT -p gre -j ACCEPT
    -A FORWARD -j REJECT --reject-with icmp-host-prohibited
    COMMIT

iptables on Compute node
------------------------

    $ cat /etc/sysconfig/iptables
    *filter
    :INPUT ACCEPT [0:0]
    :FORWARD ACCEPT [0:0]
    :OUTPUT ACCEPT [0:0]
    -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
    -A INPUT -p icmp -j ACCEPT
    -A INPUT -i lo -j ACCEPT
    -A INPUT -m state --state NEW -m tcp -p tcp --dport 5900:5999 -j ACCEPT
    -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
    -A INPUT -p gre -j ACCEPT
    -A INPUT -j REJECT --reject-with icmp-host-prohibited
    -A OUTPUT -p gre -j ACCEPT
    -A FORWARD -j REJECT --reject-with icmp-host-prohibited
    COMMIT



[1] Also here --
http://kashyapc.fedorapeople.org/virt/openstack/neutron-configs-GRE-OVS-two-node.txt


-- 
/kashyap



From bderzhavets at hotmail.com  Thu Jan 30 07:43:01 2014
From: bderzhavets at hotmail.com (Boris Derzhavets)
Date: Thu, 30 Jan 2014 02:43:01 -0500
Subject: [Rdo-list] Neutron configuration files for a two node
 Neutron+GRE+OVS
In-Reply-To: <52E9DFF1.7020301@redhat.com>
References: <52E9DFF1.7020301@redhat.com>
Message-ID: 

How to surf internet via Neutron GRE tunnel (Fedora 20) ?

https://ask.openstack.org/en/question/11122/how-to-surf-internet-via-neutron-gre-tunnel-fedora-20/

I've also tried to set MTU to 1400 on F20 (KDE desktop) & CentOS 6.5 (Gnome) instances along with p37p1 on Compute Node (real host ) and br-ex on Controller Node ( real host) . I cannot touch outgoing router ( not Cisco model). No luck.  I just can open only fedoraproject.org and yandex.ru.
Native F20 repos have been used for reproducing your setup on real F20 nodes ( Controller - 192.168.1.127, Compute - 192.168.1.137)

Boris

> Date: Thu, 30 Jan 2014 10:45:29 +0530
> From: kchamart at redhat.com
> To: rdo-list at redhat.com
> Subject: [Rdo-list] Neutron configuration files for a two node	Neutron+GRE+OVS
> 
> Heya,
> 
> Just in case if it's useful for someone, here are my working Neutron
> configuration files (and iptables rules) for a two node set-up based on
> IceHouse-M2 on Fedora-20,
> 
>   - Controller node: Nova, Keystone (token-based auth), Cinder,
>     Glance, Neutron (using Open vSwitch plugin and GRE tunneling).
> 
>   - Compute node: Nova (nova-compute), Neutron (openvswitch-agent)
> 
> 
> Controller node Neutron configurations
> ======================================
> 
> 1. neutron.conf
> ---------------
> 
>     $ cat /etc/neutron/neutron.conf | grep -v ^$ | grep -v ^#
>     [DEFAULT]
>     core_plugin
> =neutron.plugins.openvswitch.ovs_neutron_plugin.OVSNeutronPluginV2
>     rpc_backend = neutron.openstack.common.rpc.impl_qpid
>     control_exchange = neutron
>     qpid_hostname = 192.169.142.49
>     auth_strategy = keystone
>     allow_overlapping_ips = True
>     dhcp_lease_duration = 120
>     allow_bulk = True
>     qpid_port = 5672
>     qpid_heartbeat = 60
>     qpid_protocol = tcp
>     qpid_tcp_nodelay = True
>     qpid_reconnect_limit=0
>     qpid_reconnect_interval_max=0
>     qpid_reconnect_timeout=0
>     qpid_reconnect=True
>     qpid_reconnect_interval_min=0
>     qpid_reconnect_interval=0
>     debug = False
>     verbose = False
>     [quotas]
>     [agent]
>     [keystone_authtoken]
>     admin_tenant_name = services
>     admin_user = neutron
>     admin_password = fedora
>     auth_host = 192.169.142.49
>     auth_port = 35357
>     auth_protocol = http
>     auth_uri=http://192.169.142.49:5000/
>     [database]
>     [service_providers]
>     [AGENT]
>     root_helper = sudo neutron-rootwrap /etc/neutron/rootwrap.conf
> 
> 2. (OVS) plugin.ini
> -------------------
> 
>     $ cat /etc/neutron/plugin.ini | grep -v ^$ | grep -v ^#
>     [ovs]
>     tenant_network_type = gre
>     tunnel_id_ranges = 1:1000
>     enable_tunneling = True
>     integration_bridge = br-int
>     tunnel_bridge = br-tun
>     local_ip = 192.169.142.49
>     [agent]
>     [securitygroup]
>     [DATABASE]
>     sql_connection = mysql://neutron:fedora at node1-controller/ovs_neutron
>     sql_max_retries=10
>     reconnect_interval=2
>     sql_idle_timeout=3600
>     [SECURITYGROUP]
>     firewall_driver =
> neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
> 
> 3. dhcp_agent.ini
> -----------------
> 
>     $ cat /etc/neutron/dhcp_agent.ini | grep -v ^$ | grep -v ^#
>     [DEFAULT]
>     interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver
>     handle_internal_only_routers = TRUE
>     external_network_bridge = br-ex
>     use_namespaces = True
>     dnsmasq_config_file = /etc/neutron/dnsmasq.conf
> 
> 4. l3_agent.ini
> ---------------
> 
>     $ cat /etc/neutron/dhcp_agent.ini | grep -v ^$ | grep -v ^#
>     [DEFAULT]
>     interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver
>     handle_internal_only_routers = TRUE
>     external_network_bridge = br-ex
>     use_namespaces = True
>     dnsmasq_config_file = /etc/neutron/dnsmasq.conf
> 
> 5. dnsmasq.conf
> ---------------
> 
> This logs dnsmasq output is to a file, instead of journalctl):
> 
>     $ cat /etc/neutron/dnsmasq.conf | grep -v ^$ | grep -v ^#
>     log-facility = /var/log/neutron/dnsmasq.log
>     log-dhcp
> 
> 6. api-paste.ini
> ----------------
> 
>     $ cat /etc/neutron/api-paste.ini | grep -v ^$ | grep -v ^#
>     [composite:neutron]
>     use = egg:Paste#urlmap
>     /: neutronversions
>     /v2.0: neutronapi_v2_0
>     [composite:neutronapi_v2_0]
>     use = call:neutron.auth:pipeline_factory
>     noauth = extensions neutronapiapp_v2_0
>     keystone = authtoken keystonecontext extensions neutronapiapp_v2_0
>     [filter:keystonecontext]
>     paste.filter_factory = neutron.auth:NeutronKeystoneContext.factory
>     [filter:authtoken]
>     paste.filter_factory =
> keystoneclient.middleware.auth_token:filter_factory
>     admin_user=neutron
>     auth_port=35357
>     admin_password=fedora
>     auth_protocol=http
>     auth_uri=http://192.169.142.49:5000/
>     admin_tenant_name=services
>     auth_host = 192.169.142.49
>     [filter:extensions]
>     paste.filter_factory =
> neutron.api.extensions:plugin_aware_extension_middleware_factory
>     [app:neutronversions]
>     paste.app_factory = neutron.api.versions:Versions.factory
>     [app:neutronapiapp_v2_0]
>     paste.app_factory = neutron.api.v2.router:APIRouter.factory
> 
> 7. metadata_agent.ini
> ---------------------
> 
>     $ cat /etc/neutron/metadata_agent.ini | grep -v ^$ | grep -v ^#
>     [DEFAULT]
>     auth_url = http://192.169.142.49:35357/v2.0/
>     auth_region = regionOne
>     admin_tenant_name = services
>     admin_user = neutron
>     admin_password = fedora
>     nova_metadata_ip = 192.168.142.49
>     nova_metadata_port = 8775
>     metadata_proxy_shared_secret = fedora
> 
> 
> Compute node Neutron configurations
> ===================================
> 
> 1. neutron.conf
> ---------------
> 
>     $ cat /etc/neutron/neutron.conf | grep -v ^$ | grep -v ^#
>     [DEFAULT]
>     core_plugin
> =neutron.plugins.openvswitch.ovs_neutron_plugin.OVSNeutronPluginV2
>     rpc_backend = neutron.openstack.common.rpc.impl_qpid
>     qpid_hostname = 192.169.142.49
>     auth_strategy = keystone
>     allow_overlapping_ips = True
>     qpid_port = 5672
>     debug = True
>     verbose = True
>     [quotas]
>     [agent]
>     [keystone_authtoken]
>     admin_tenant_name = services
>     admin_user = neutron
>     admin_password = fedora
>     auth_host = 192.169.142.49
>     [database]
>     [service_providers]
>     [AGENT]
>     root_helper = sudo neutron-rootwrap /etc/neutron/rootwrap.conf
> 
> 2. (OVS) plugin.ini
> -------------------
> 
>     $ cat plugin.ini | grep -v ^$ | grep -v ^#
>     [ovs]
>     tenant_network_type = gre
>     tunnel_id_ranges = 1:1000
>     enable_tunneling = True
>     integration_bridge = br-int
>     tunnel_bridge = br-tun
>     local_ip = 192.169.142.57
>     [DATABASE]
>     sql_connection = mysql://neutron:fedora at node1-controller/ovs_neutron
>     [SECURITYGROUP]
>     firewall_driver =
> neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
>     [agent]
>     [securitygroup]
> 
> 3. metadata_agent.ini
> ---------------------
> 
>     $ cat metadata_agent.ini | grep -v ^$ | grep -v ^#
>     [DEFAULT]
>     auth_url = http://localhost:5000/v2.0
>     auth_region = RegionOne
>     admin_tenant_name = %SERVICE_TENANT_NAME%
>     admin_user = %SERVICE_USER%
>     admin_password = %SERVICE_PASSWORD%
> 
> 
> iptables rules on both Controller and Compute nodes
> ===================================================
> 
> iptables on Controller node
> ---------------------------
> 
>     $ cat /etc/sysconfig/iptables
>     *filter
>     :INPUT ACCEPT [0:0]
>     :FORWARD ACCEPT [0:0]
>     :OUTPUT ACCEPT [0:0]
>     -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>     -A INPUT -p icmp -j ACCEPT
>     -A INPUT -i lo -j ACCEPT
>     -A INPUT -p tcp -m multiport --dports 3260 -m comment --comment "001
> cinder incoming" -j ACCEPT
>     -A INPUT -p tcp -m multiport --dports 80 -m comment --comment "001
> horizon incoming" -j ACCEPT
>     -A INPUT -p tcp -m multiport --dports 9292 -m comment --comment "001
> glance incoming" -j ACCEPT
>     -A INPUT -p tcp -m multiport --dports 5000,35357 -m comment
> --comment "001 keystone incoming" -j ACCEPT
>     -A INPUT -p tcp -m multiport --dports 3306 -m comment --comment "001
> mariadb incoming" -j ACCEPT
>     -A INPUT -p tcp -m multiport --dports 6080 -m comment --comment "001
> novncproxy incoming" -j ACCEPT
>     -A INPUT -p tcp -m multiport --dports 8770:8780 -m comment --comment
> "001 novaapi incoming" -j ACCEPT
>     -A INPUT -p tcp -m multiport --dports 9696 -m comment --comment "001
> neutron incoming" -j ACCEPT
>     -A INPUT -p tcp -m multiport --dports 5672 -m comment --comment "001
> qpid incoming" -j ACCEPT
>     -A INPUT -p tcp -m multiport --dports 8700 -m comment --comment "001
> metadata incoming" -j ACCEPT
>     -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
>     -A INPUT -m state --state NEW -m tcp -p tcp --dport 5900:5999 -j ACCEPT
>     -A INPUT -j REJECT --reject-with icmp-host-prohibited
>     -A INPUT -p gre -j ACCEPT
>     -A OUTPUT -p gre -j ACCEPT
>     -A FORWARD -j REJECT --reject-with icmp-host-prohibited
>     COMMIT
> 
> iptables on Compute node
> ------------------------
> 
>     $ cat /etc/sysconfig/iptables
>     *filter
>     :INPUT ACCEPT [0:0]
>     :FORWARD ACCEPT [0:0]
>     :OUTPUT ACCEPT [0:0]
>     -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
>     -A INPUT -p icmp -j ACCEPT
>     -A INPUT -i lo -j ACCEPT
>     -A INPUT -m state --state NEW -m tcp -p tcp --dport 5900:5999 -j ACCEPT
>     -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
>     -A INPUT -p gre -j ACCEPT
>     -A INPUT -j REJECT --reject-with icmp-host-prohibited
>     -A OUTPUT -p gre -j ACCEPT
>     -A FORWARD -j REJECT --reject-with icmp-host-prohibited
>     COMMIT
> 
> 
> 
> [1] Also here --
> http://kashyapc.fedorapeople.org/virt/openstack/neutron-configs-GRE-OVS-two-node.txt
> 
> 
> -- 
> /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 sandro at mathys.io  Thu Jan 30 10:54:04 2014
From: sandro at mathys.io (Sandro Mathys)
Date: Thu, 30 Jan 2014 19:54:04 +0900
Subject: [Rdo-list] OpenStack Days Tokyo 2014 - Meetup?
Message-ID: 

It seems there's no official Red Hat / RDO presence at OpenStack Days
Tokyo 2014, but I was nevertheless wondering whether other people will
be there? If so, maybe we could have a small meetup sometime (beer or
dinner after the first day?). Not sure there's other RDO people in
Japan, though. ;)

Here's the details for the event for those who haven't heard about it.
You'll notice all the other big names (that have business in Japan)
are listed in some way or another:

http://openstackdays.com/en/

Cheers,
Sandro



From tshefi at redhat.com  Thu Jan 30 12:22:58 2014
From: tshefi at redhat.com (Tzach Shefi)
Date: Thu, 30 Jan 2014 07:22:58 -0500 (EST)
Subject: [Rdo-list] Glance does not save properties of images
In-Reply-To: <8751501.1837.1391005828950.JavaMail.Daniel@Daniel-PC>
References: <13085627.1386.1390837182915.JavaMail.Daniel@Daniel-PC>
	<20140127161555.GA7651@redhat.com>
	<31213435.1409.1390839949745.JavaMail.Daniel@Daniel-PC>
	<20140128083727.GA13030@redhat.com>
	<8751501.1837.1391005828950.JavaMail.Daniel@Daniel-PC>
Message-ID: <699972937.6658373.1391084578489.JavaMail.root@redhat.com>

Hello Daniel, 

On your posted glance-api.con noticed default_store = rbd, assuming Glance back end is CEPH (correct?). 

Just installed AIO RDO Havana on RHEL 6.5. 
Is_public updated successfully via Horizon\CLI, image shows up as public on Horizon\image-show. 


I'm assuming (the obvious..) that you checked this on more than just that one image, eliminates a single bad image as source of this problem.  
BTW what type\source of image was used\checked? 

Another difference in setups mine notifier_strategy =QPID your's uses rabbit. 

Regards,
Tzach

----- Original Message -----
From: "Daniel Speichert" 
To: "Flavio Percoco" 
Cc: rdo-list at redhat.com
Sent: Wednesday, January 29, 2014 4:30:56 PM
Subject: [Rdo-list] Glance does not save properties of images

----- Original Message -----
> From: "Flavio Percoco" 
> To: "Daniel Speichert" 
> Cc: "Lars Kellogg-Stedman" , rdo-list at redhat.com
> Sent: Tuesday, January 28, 2014 3:37:27 AM
> Subject: Re: [Rdo-list] Glance does not save properties of images
> 
> 
> Could you please share the commands your using?
> 
>     - How are you adding the properties?
>     - How are you reading the propoerties?
> 
> You're sharing your registry.log configurations which means you've
> configured the registry. Could you share how you did that?
> 
> Thanks,
> flaper
> 

These are required properties when adding any Glance image (disk_format and container_format). I was trying to set is_public through 'glance image-edit' and Horizon. The change seems to be accepted (no error) but on subsequent image-show it's just not there.

Registry and API are set up almost by defaults:
glance-registry.conf: http://pastebin.com/M7Ybjnf9
glance-api.conf: http://pastebin.com/5sPXr3mG

Regards,
Daniel Speichert

_______________________________________________
Rdo-list mailing list
Rdo-list at redhat.com
https://www.redhat.com/mailman/listinfo/rdo-list



From bderzhavets at hotmail.com  Thu Jan 30 13:57:10 2014
From: bderzhavets at hotmail.com (Boris Derzhavets)
Date: Thu, 30 Jan 2014 08:57:10 -0500
Subject: [Rdo-list] Neutron configuration files for a two node
 Neutron+GRE+OVS
In-Reply-To: 
References: <52E9DFF1.7020301@redhat.com>,
	
Message-ID: 

Sorry for noise. I am done with it.

From: bderzhavets at hotmail.com
To: kchamart at redhat.com; rdo-list at redhat.com
Date: Thu, 30 Jan 2014 02:43:01 -0500
Subject: Re: [Rdo-list] Neutron configuration files for a two node Neutron+GRE+OVS




How to surf internet via Neutron GRE tunnel (Fedora 20) ?

https://ask.openstack.org/en/question/11122/how-to-surf-internet-via-neutron-gre-tunnel-fedora-20/

I've also tried to set MTU to 1400 on F20 (KDE desktop) & CentOS 6.5 (Gnome) instances along with p37p1 on Compute Node (real host ) and br-ex on Controller Node ( real host) . I cannot touch outgoing router ( not Cisco model). No luck.  I just can open only fedoraproject.org and yandex.ru.
Native F20 repos have been used for reproducing your setup on real F20 nodes ( Controller - 192.168.1.127, Compute - 192.168.1.137)

Boris
_____________
> 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 daniel at speichert.pl  Thu Jan 30 16:01:26 2014
From: daniel at speichert.pl (Daniel Speichert)
Date: Thu, 30 Jan 2014 17:01:26 +0100 (CET)
Subject: [Rdo-list] Glance does not save properties of images
In-Reply-To: <699972937.6658373.1391084578489.JavaMail.root@redhat.com>
References: <13085627.1386.1390837182915.JavaMail.Daniel@Daniel-PC>
	<20140127161555.GA7651@redhat.com>
	<31213435.1409.1390839949745.JavaMail.Daniel@Daniel-PC>
	<20140128083727.GA13030@redhat.com>
	<8751501.1837.1391005828950.JavaMail.Daniel@Daniel-PC>
	<699972937.6658373.1391084578489.JavaMail.root@redhat.com>
Message-ID: <24471429.2142.1391097660295.JavaMail.Daniel@Daniel-PC>

Yes, Ceph is working well as backend (images are uploaded there successfully and retrieved as well).
The same problem occurs also when the image is kept locally (default_store = file).

We have checked multiple images and the problem is the same. Interestingly, we had the same setup before (we reinstalled last week) and it was working fine. That makes me think that something might be different in the package.

We use rabbit and it seems to be working fine - ceilometer is getting these notifications.

Do you have any other ideaas? I'm running the latest package version form RDO.

Thanks,
Daniel Speichert

----- Original Message -----
> From: "Tzach Shefi" 
> To: "Daniel Speichert" 
> Cc: "Flavio Percoco" , rdo-list at redhat.com
> Sent: Thursday, January 30, 2014 7:22:58 AM
> Subject: Re: [Rdo-list] Glance does not save properties of images
> 
> Hello Daniel,
> 
> On your posted glance-api.con noticed default_store = rbd, assuming
> Glance back end is CEPH (correct?).
> 
> Just installed AIO RDO Havana on RHEL 6.5.
> Is_public updated successfully via Horizon\CLI, image shows up as
> public on Horizon\image-show.
> 
> 
> I'm assuming (the obvious..) that you checked this on more than just
> that one image, eliminates a single bad image as source of this
> problem.
> BTW what type\source of image was used\checked?
> 
> Another difference in setups mine notifier_strategy =QPID your's uses
> rabbit.
> 
> Regards,
> Tzach
> 
> ----- Original Message -----
> From: "Daniel Speichert" 
> To: "Flavio Percoco" 
> Cc: rdo-list at redhat.com
> Sent: Wednesday, January 29, 2014 4:30:56 PM
> Subject: [Rdo-list] Glance does not save properties of images
> 
> ----- Original Message -----
> > From: "Flavio Percoco" 
> > To: "Daniel Speichert" 
> > Cc: "Lars Kellogg-Stedman" , rdo-list at redhat.com
> > Sent: Tuesday, January 28, 2014 3:37:27 AM
> > Subject: Re: [Rdo-list] Glance does not save properties of images
> > 
> > 
> > Could you please share the commands your using?
> > 
> >     - How are you adding the properties?
> >     - How are you reading the propoerties?
> > 
> > You're sharing your registry.log configurations which means you've
> > configured the registry. Could you share how you did that?
> > 
> > Thanks,
> > flaper
> > 
> 
> These are required properties when adding any Glance image
> (disk_format and container_format). I was trying to set is_public
> through 'glance image-edit' and Horizon. The change seems to be
> accepted (no error) but on subsequent image-show it's just not
> there.
> 
> Registry and API are set up almost by defaults:
> glance-registry.conf: http://pastebin.com/M7Ybjnf9
> glance-api.conf: http://pastebin.com/5sPXr3mG
> 
> Regards,
> Daniel Speichert
> 
> _______________________________________________
> Rdo-list mailing list
> Rdo-list at redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list
> 



From bnemec at redhat.com  Thu Jan 30 16:27:55 2014
From: bnemec at redhat.com (Ben Nemec)
Date: Thu, 30 Jan 2014 11:27:55 -0500 (EST)
Subject: [Rdo-list] Proposed workaround for rabbitmq problem in new F20 VM
In-Reply-To: <2060452753.7419384.1391099047287.JavaMail.root@redhat.com>
Message-ID: <550907552.7420680.1391099275839.JavaMail.root@redhat.com>

Hi,

I pushed a proposed workaround for the rabbitmq problem running devstack on Fedora 20.  Ideally it would be best to fix the problem with rabbitmq, but in the meantime this change shouldn't hurt anything when rabbit behaves and it made devstack complete successfully again for me on the first try.

https://review.openstack.org/#/c/70156/

Let me know if you have any feedback.  Thanks.

-Ben



From whayutin at redhat.com  Thu Jan 30 16:52:00 2014
From: whayutin at redhat.com (whayutin)
Date: Thu, 30 Jan 2014 11:52:00 -0500
Subject: [Rdo-list] openstack-nova-common in icehouse requires
 python-oslo-rootwrap for installation which is not available
Message-ID: <1391100720.5753.1.camel@localhost.localdomain>

FYI
the latest icehouse install via packstack fails w/
https://bugzilla.redhat.com/show_bug.cgi?id=1059693



From xqueralt at redhat.com  Thu Jan 30 17:12:18 2014
From: xqueralt at redhat.com (Xavier Queralt-Mateu)
Date: Thu, 30 Jan 2014 12:12:18 -0500 (EST)
Subject: [Rdo-list] Fedora 20 / Devstack Networking Issues
In-Reply-To: <1390950395.8426.71.camel@localhost.localdomain>
References: <52E496A1.20807@redhat.com> <52E66E14.5070707@redhat.com>
	<265473075.6391595.1390924603943.JavaMail.root@redhat.com>
	<1390950395.8426.71.camel@localhost.localdomain>
Message-ID: <1305465224.7441867.1391101938157.JavaMail.root@redhat.com>

I've just proposed a fix in nova that, in my case, fixes the networking issues you mentioned: https://review.openstack.org/70164

The interfaces in my F20 VMs get the 'dynamic' address flag set, which didn't happen in previously in F19. This extra string is not understood by the "ip addr del" command and crashes without configuring the bridge properly and leaving the interface in a bad shape.

--
xqm

----- Original Message -----
> From: "Ian McLeod" 
> To: "Ben Nemec" 
> Cc: "Brent Eagles" , "Perry Myers" , "rdo-list" 
> Sent: Wednesday, January 29, 2014 12:06:35 AM
> Subject: Re: [Rdo-list] Fedora 20 / Devstack Networking Issues
> 
> On Tue, 2014-01-28 at 10:56 -0500, Ben Nemec wrote:
> > 
> > ----- Original Message -----
> > > On 01/26/2014 12:01 AM, Perry Myers wrote:
> > > > Ok, I've been chasing down some networking issues along with some other
> > > > folks.  Here's what I'm seeing:
> > > > 
> > > > Starting with a vanilla F20 cloud image running on a F20 host, clone
> > > > devstack into it and run stack.sh.
> > > > 
> > > > First thing is that the RabbitMQ server issue I noted a few weeks ago
> > > > is
> > > > still intermittently there.  So during the step where rabbitmqctl is
> > > > run
> > > > to set the password of the rabbit admin user, it might fail and all
> > > > subsequent AMQP communication fails which makes a lot of the nova
> > > > commands in devstack also fail.
> > > > 
> > > > But... if you get past this error (since it is intermittent), then
> > > > devstack seems to complete successfully.  Standard commands like nova
> > > > list, keystone user-list, etc all work fine.
> > > > 
> > > > I did note though that access to Horizon does not work.  I need to
> > > > investigate this further.
> > > > 
> > > > But worse than that is when you run nova boot, the host to guest
> > > > networking (remember this is devstack running in a VM) immediately gets
> > > > disconnected.  This issue is 100% reproducible and multiple users are
> > > > reporting it (tsedovic, eharney, bnemec cc'd)
> > > > 
> > > > I did some investigation when this happens and here's what I found...
> > > > 
> > > > If I do:
> > > > 
> > > > $ brctl delif br100 eth0
> > > > 
> > > > I was immediately able to ping the guest from the host and vice versa.
> > > > 
> > > > If I reattach eth0 back to br100, networking stops again
> > > > 
> > > > Another thing... I notice that on the system br100 does not have an ip
> > > > address, but eth0 does.  I thought when doing bridged networking like
> > > > this, the bridge should have the ip address and the physical iface that
> > > > is attached to the bridge does not get an ip addr.
> > > > 
> > > > So... I tweaked /etc/sysconfig/network-scripts/ifcfg-eth0 to remove the
> > > > dhcp from the bootproto line and I copied ifcfg-eth0 to ifcfg-br100
> > > > allowing it to use bootproto dhcp
> > > > 
> > > > I brought both ifaces down and then brought them both up.  eth0 first
> > > > and br100 second
> > > > 
> > > > This time, br100 got the dhcp address from the host and networking
> > > > worked fine.
> > > > 
> > > > So is this just an issue with how nova is setting up bridges?
> > > > 
> > > > Since this network disconnect didn't happen until nova launched a vm, I
> > > > imagine this isn't a problem with devstack itself, but is likely an
> > > > issue with Nova Networking somehow.
> > > > 
> > > > Russell/DanS, is there any chance that all of the refactoring you did
> > > > in
> > > > Nova Networking very recently introduce a regression?
> > > 
> > > I suppose it's possible.  You could try going back to before any of the
> > > nova-network-objects patches went in.  The first one to merge was:
> > > 
> > > commit a8c73c7d3298589440579d67e0c5638981dd7718
> > > Merge: a1f6e85 aa40c8f
> > > Author: Jenkins 
> > > Date:   Wed Jan 15 18:38:37 2014 +0000
> > > 
> > >     Merge "Make nova-network use Service object"
> > > 
> > > Try going back to before that and see if you get a different result.  If
> > > so, try using "git bisect" to find the offending commit.
> > > 
> > > --
> > > Russell Bryant
> > > 
> > 
> > I am still unable to reproduce the networking issue in my environment.  I
> > booted a stock Fedora 20 cloud image, installed git, cloned devstack and
> > ran it with a minimal localrc configuration (so using the defaults of
> > nova-network and rabbitmq).  Other than the rabbitmq race issue that
> > always makes my first stack.sh run on a new VM fail, I had no problem
> > completing stack.sh and booting a nova instance.  The instance's IP was
> > correctly moved to the bridge for me.  If this is a regression in nova
> > network then it only presents in combination with some other circumstance
> > that isn't present for me.
> > 
> > As I mentioned in our off-list discussion of this, I run my development
> > VM's in a local OpenStack installation I have, so maybe there's some
> > difference in the way the networking works there.  In any case, while I
> > don't have an answer hopefully another data point will help in figuring
> > this out.
> 
> OK.  I can provide a data point that may or may not be useful.
> 
> I am getting the same behavior Perry reported.  Install is successful,
> first VM launch kills the network.  After much head bashing and
> experimentation I found that everything worked correctly if I assigned
> the FLAT_INTERFACE in my localrc file to a second, unused NIC on my test
> system.  e.g.
> 
> FLAT_INTERFACE=p4p2
> 
> Prior to that I'd had all of the various localrc interface variables
> pointing to the single primary NIC. e.g.
> 
> HOST_IP_IFACE=p4p1
> PUBLIC_INTERFACE=p4p1
> VLAN_INTERFACE=p4p1
> FLAT_INTERFACE=p4p1
> 
> This style of config (everything on one NIC) is advocated in the single
> node getting started guide:
> 
> http://devstack.org/guides/single-machine.html
> 
> I observed this while testing on commit:
> 
> 3f5250fff3007dfd1e5992c0cf229be9033a5726
> 
> -Ian
> 
> > 
> > -Ben
> > 
> > _______________________________________________
> > Rdo-list mailing list
> > Rdo-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/rdo-list
> 
> 
> _______________________________________________
> Rdo-list mailing list
> Rdo-list at redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list
> 



From whayutin at redhat.com  Thu Jan 30 17:59:11 2014
From: whayutin at redhat.com (whayutin)
Date: Thu, 30 Jan 2014 12:59:11 -0500
Subject: [Rdo-list] FYI.. nova.conf install error in latest icehouse
Message-ID: <1391104751.5753.7.camel@localhost.localdomain>

Error: 87 lines match pattern '\[DEFAULT\]' in file
'/etc/nova/nova.conf'.

https://bugzilla.redhat.com/show_bug.cgi?id=1059815





From daniel at speichert.pl  Thu Jan 30 19:39:48 2014
From: daniel at speichert.pl (Daniel Speichert)
Date: Thu, 30 Jan 2014 20:39:48 +0100 (CET)
Subject: [Rdo-list] Neutron VPNaaS
In-Reply-To: <17881517.2200.1391110322392.JavaMail.Daniel@Daniel-PC>
Message-ID: <15696573.2203.1391110762194.JavaMail.Daniel@Daniel-PC>

Hello,

Did anyone get VPNaaS to work using RDO packages? Is there any good tutorial for that like the one on LBaaS?
I couldn't find any on RDO website and my attempts to create VPN always ended with PENDING_CREATE.

I'd appreciate if someone could share some tested recipe for getting VPNaaS to work on RDO

Thanks,
Daniel Speichert



From whayutin at redhat.com  Fri Jan 31 20:23:10 2014
From: whayutin at redhat.com (whayutin)
Date: Fri, 31 Jan 2014 15:23:10 -0500
Subject: [Rdo-list] FYI: f20 icehouse install fails w/ openstack-dashboard
	install error
Message-ID: <1391199790.2775.6.camel@localhost.localdomain>

https://bugzilla.redhat.com/show_bug.cgi?id=1060334





From whayutin at redhat.com  Fri Jan 31 20:34:38 2014
From: whayutin at redhat.com (whayutin)
Date: Fri, 31 Jan 2014 15:34:38 -0500
Subject: [Rdo-list] bz's that may impact the next RDO test day
Message-ID: <1391200478.2775.8.camel@localhost.localdomain>

FYI

http://openstack.redhat.com/Workarounds_2014_02





From lars at redhat.com  Fri Jan 31 21:21:20 2014
From: lars at redhat.com (Lars Kellogg-Stedman)
Date: Fri, 31 Jan 2014 16:21:20 -0500
Subject: [Rdo-list] bz's that may impact the next RDO test day
In-Reply-To: <1391200478.2775.8.camel@localhost.localdomain>
References: <1391200478.2775.8.camel@localhost.localdomain>
Message-ID: <20140131212120.GB7537@redhat.com>

On Fri, Jan 31, 2014 at 03:34:38PM -0500, whayutin wrote:
> http://openstack.redhat.com/Workarounds_2014_02

I went through all of http://openstack.redhat.com/Workarounds_2014_01
earlier this week.  Several of those issues have seen activity and
either have fix released or will soon.  Here's a quick summary of
where things stand:

  - packstack requires 2 runs to install ceilometer

    BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1028690
    State: POST

    While this is marked POST, subsequent discussion in bugzilla makes
    it unclear whether or not the issue has been resolved.

  - neutron-openvswitch-agent service restart fails; reason: fails to
    pull dependency

    BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1049235
    State: MODIFIED
    
  - nstack-nova-compute service fails with - libvirtError: internal
    error: CPU feature `avx' specified more than once

    BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1049391
    State: MODIFIED

  - packstack fails with mysql-server dependency as a result of Fedora's
    switch to mariadb-server

    BZ: https://bugzilla.redhat.com/show_bug.cgi?id=981116
    State: ASSIGNED

    A fix for this has been submitted upstream, and mmagr says, "updated
    puppet-tempest will be in next fc20 build".

For a few it's not immediately clear what state things are in:

  - Fedora 20 rdo-icehouse selinux issues with rootwrap

    BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1049503
    State: NEW

  - mongodb fails to start on the very first run on a slow environment

    BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1040573
    State: NEW

And one does not yet appear to have been addressed in bugzilla:

  - new ceilometer-agent-notification service needs to be started
    alongside the other ceilometer services

    BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1049369
    State: ASSIGNED

    There appears to be a fixed package in rawhide, but not yet in the
    RDO openstack-icehouse repository.

-- 
Lars Kellogg-Stedman  | larsks @ irc
Cloud Engineering / OpenStack          | "   "  @ twitter

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: