From whayutin at redhat.com Wed Jul 1 00:18:37 2015 From: whayutin at redhat.com (whayutin) Date: Tue, 30 Jun 2015 20:18:37 -0400 Subject: [Rdo-list] [CI] any port changes in kilo? Message-ID: <1435709917.2910.29.camel@redhat.com> Greetings, I see that the latest kilo bugs were fixed w/ the latest delorean builds, but I did hit an error. 14:55:37 TASK: [packstack/runner | Wait for openstack port 35357 to open] ************** 14:55:37 [[ previous task time: 0:00:00.025562 = 0.03s / 3622.74s ]] 14:55:37 <127.0.0.1> REMOTE_MODULE wait_for host=66.187.224.52 port=35357 delay=10 timeout=120 14:55:37 failed: [rdo-pksk-4mdt2-rhos-ci-21-controller -> 127.0.0.1] => {"elapsed": 124, "failed": true} 14:55:37 msg: Timeout when waiting for 66.187.224.52:35357 14:55:37 14:55:37 msg: 14:55:37 Timeout when waiting for 66.187.224.52:35357 Are there any changes to the ports that the controller is exposing? From javier.pena at redhat.com Wed Jul 1 11:16:10 2015 From: javier.pena at redhat.com (Javier Pena) Date: Wed, 1 Jul 2015 07:16:10 -0400 (EDT) Subject: [Rdo-list] [CI] any port changes in kilo? In-Reply-To: <1435709917.2910.29.camel@redhat.com> References: <1435709917.2910.29.camel@redhat.com> Message-ID: <2023582708.30099570.1435749370501.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Greetings, > I see that the latest kilo bugs were fixed w/ the latest delorean > builds, but I did hit an error. > > > 14:55:37 TASK: [packstack/runner | Wait for openstack port 35357 to > open] ************** > 14:55:37 [[ previous task time: 0:00:00.025562 = > 0.03s / 3622.74s ]] > 14:55:37 <127.0.0.1> REMOTE_MODULE wait_for host=66.187.224.52 > port=35357 delay=10 timeout=120 > 14:55:37 failed: [rdo-pksk-4mdt2-rhos-ci-21-controller -> 127.0.0.1] => > {"elapsed": 124, "failed": true} > 14:55:37 msg: Timeout when waiting for 66.187.224.52:35357 > 14:55:37 > 14:55:37 msg: > 14:55:37 Timeout when waiting for 66.187.224.52:35357 > > > Are there any changes to the ports that the controller is exposing? > Hi Wes, I'm not aware of any port changes, maybe there is a change in the security group that made port 35357 unavailable? Regards, Javier > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com > From rbowen at redhat.com Wed Jul 1 14:13:58 2015 From: rbowen at redhat.com (Rich Bowen) Date: Wed, 01 Jul 2015 10:13:58 -0400 Subject: [Rdo-list] [Rdo-newsletter] RDO Community Newsletter - July 2015 Message-ID: <5593F5A6.1070107@redhat.com> Thanks for being part of the RDO community! Quick links: * Quick Start - http://rdoproject.org/quickstart * Mailing Lists - http://rdoproject.org/Mailing_lists * RDO packages - http://rdoproject.org/repos/ * RDO blog - http://rdoproject.org/blog * Q&A - http://ask.openstack.org/ * Open Tickets - http://tm3.org/rdobugs * Twitter - http://twitter.com/rdocommunity Mailing List Update =================== Here's what's been going on in the RDO world since you last heard from me. It's pretty common to want to integrate an OpenStack deployment with your existing external network. The documentation for how to accomplish this has been updated to reflect the current state of OpenStack. That document is at https://www.rdoproject.org/Neutron_with_existing_external_network and we welcome your feedback and corrections to that doc. With the conversation happening in upstream OpenStack about the 'Big Tent' (See more about this idea at http://tm3.org/big-tent), it's worth discussing what this means to RDO. Specifically, what do we want to package in RDO? While the simple answer to this is "whatever the community makes happen", there are other things to consider. You can read this conversation in the archives at https://www.redhat.com/archives/rdo-list/2015-June/msg00044.html and https://www.redhat.com/archives/rdo-list/2015-May/msg00284.html Also, out of this conversation has come a document - still a work in progress - that documents what's in RDO right now. That's at https://www.rdoproject.org/ProjectsInRDO The folks from Trystack gave an update on their plans for the near future. In particular, there was discussion of moving off of Facebook-based authenticaion to openstack.org-based authentication. You can read that conversation at https://www.redhat.com/archives/rdo-list/2015-June/msg00045.html As of this writing, x86.trystack.org is offline due to DC/network issues. You can check in #trystack, on the Freenode IRC network, for updates. Boris Derzhavets did a nice writeup of switching to Spice console in RDO Kilo, which you read at http://tm3.org/spice There was further discussion of this on the list, which you can read at https://www.redhat.com/archives/rdo-list/2015-June/msg00064.html The RDO-Manager team announced that work on HA support had been completed: https://www.redhat.com/archives/rdo-list/2015-June/msg00070.html You can see more about RDO-Manager at https://www.rdoproject.org/RDO-Manager In response to conversations in the upstream about packaging, Mark McLoughlin wrote a blog post discussing his ideas about upstream packaging, and how it would affect the RDO project. That post is at https://blogs.gnome.org/markmc/2015/06/12/rdo-and-upstream-packaging/ and the ensuing discussion may be found at https://www.redhat.com/archives/rdo-list/2015-June/msg00062.html Jakub drew up a diagram to explain the packaging workflow, which you can see at https://www.rdoproject.org/packaging/rdo-packaging.html And there was a little discussion at https://www.redhat.com/archives/rdo-list/2015-June/msg00081.html One of the CentOS Google Summer of Code projects is closely related to RDO. GSoC student Asad asked some questions about how to handle his Cloud In A Box project, and got some good advice. We look forward to seeing his end product. You can read that conversation at https://www.redhat.com/archives/rdo-list/2015-June/msg00090.html And Jakub also posted about the new rdopkg requirements management documentation which you can see at the following places in the packaging doc: * https://www.rdoproject.org/packaging/rdopkg/rdopkg-adv-requirements.7.html * https://www.rdoproject.org/packaging/rdopkg/rdopkg.1.html#_action_query * https://www.rdoproject.org/packaging/rdo-packaging.html#_requirements_management This discussion may be seen at https://www.redhat.com/archives/rdo-list/2015-June/msg00157.html You can always find the archives at https://www.redhat.com/archives/rdo-list/, or join the list yourself at https://www.redhat.com/mailman/listinfo/rdo-list Packaging updates ================= Remember that every week there are two IRC meetings on the topic of packaging. The RDO-specific meeting is every Wednesday at 15:00 UTC. And on Thursdays at 15:00 UTC, the CentOS Cloud SIG discusses issues related to the CentOS CI and packaging infrastructure, as well as other cloud projects that are using those resources. We welcome your participation in either (or both!) of these meetings. The meetings from the latest RDO packaging meeting may be found at https://www.redhat.com/archives/rdo-list/2015-June/msg00087.html and the minutes from the latest Cloud SIG meeting are at https://www.redhat.com/archives/rdo-list/2015-June/msg00100.html Meetups and Events ================== Each week we post the upcoming OpenStack meetups to the rdo-list mailing list, and also on the RDO website at http://rdoproject.org/Events If you have events that you'd like for us to help you publicize, please let me know at rbowen at redhat.com Last week, RDO had a presence at the Red Hat Summit in Boston, where we gave out hundreds of RDO tshirts and demoed RDO, RDO-Manager, ManageIQ, and various other related things. https://plus.google.com/+RichBowen/posts/6bSD6p3x35G There were several presentations in the Community Theater about RDO, which will be on YouTube very soon. Watch @rdocommunity on Twitter to see them when they're available. In the coming months, RDO will have a presence at several other events: * OSCon in Portland - July 20-24 - http://www.oscon.com/open-source-2015 * LinuxCon in Seattle - August 17-19 - http://events.linuxfoundation.org/events/linuxcon-north-america * LinuxCon in Dublin - October 5-7 - http://events.linuxfoundation.org/events/linuxcon-europe * OpenStack Summit in Tokyo - October 27-30 - https://www.openstack.org/summit/tokyo-2015/ If you're going to be at any of these events, please drop by and see us. Keep in touch ============= There's lots of ways to stay in in touch with what's going on in the RDO community. The best ways are ... WWW * RDO - http://rdoproject.org/ * OpenStack Q&A - http://ask.openstack.org/ Mailing Lists: * rdo-list mailing list - http://www.redhat.com/mailman/listinfo/rdo-list * This newsletter - http://www.redhat.com/mailman/listinfo/rdo-newsletter IRC * IRC - #rdo on Freenode.irc.net * Puppet module development - #rdo-puppet Social Media: * Follow us on Twitter - http://twitter.com/rdocommunity * Google+ - http://tm3.org/rdogplus * Facebook - http://facebook.com/rdocommunity Thanks again for being part of the RDO community! -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://rdoproject.org/ _______________________________________________ Rdo-newsletter mailing list Rdo-newsletter at redhat.com https://www.redhat.com/mailman/listinfo/rdo-newsletter From Yaniv.Kaul at emc.com Wed Jul 1 15:10:42 2015 From: Yaniv.Kaul at emc.com (Kaul, Yaniv) Date: Wed, 1 Jul 2015 11:10:42 -0400 Subject: [Rdo-list] Should openstack-packstack be in Delorean repos? Message-ID: <648473255763364B961A02AC3BE1060D03DDB5BD83@MX19A.corp.emc.com> It's missing from it. I found it @ https://repos.fedorapeople.org/repos/openstack/openstack-kilo/el7/ , installed and things look OK when installing from Delorean in that sense (failed on Maria DB, investigating). Y. -------------- next part -------------- An HTML attachment was scrubbed... URL: From javier.pena at redhat.com Wed Jul 1 15:33:10 2015 From: javier.pena at redhat.com (Javier Pena) Date: Wed, 1 Jul 2015 11:33:10 -0400 (EDT) Subject: [Rdo-list] Should openstack-packstack be in Delorean repos? In-Reply-To: <648473255763364B961A02AC3BE1060D03DDB5BD83@MX19A.corp.emc.com> References: <648473255763364B961A02AC3BE1060D03DDB5BD83@MX19A.corp.emc.com> Message-ID: <169758133.30278505.1435764790375.JavaMail.zimbra@redhat.com> ----- Original Message ----- > It?s missing from it. > I found it @ > https://repos.fedorapeople.org/repos/openstack/openstack-kilo/el7/ , > installed and things look OK when installing from Delorean in that sense > (failed on Maria DB, investigating). Hi Yaniv, I can find the package in the Delorean repos, (http://trunk.rdoproject.org/centos7/current/openstack-packstack-2015.1-dev1594.ga6e1aef.el7.centos.noarch.rpm). In some cases, I have had to install the yum-plugin-priorities rpm to make sure the Delorean packages have priority over the kilo ones. Can you check if this works for you? Regards, Javier > Y. > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > To unsubscribe: rdo-list-unsubscribe at redhat.com From hguemar at fedoraproject.org Wed Jul 1 16:31:40 2015 From: hguemar at fedoraproject.org (=?UTF-8?Q?Ha=C3=AFkel?=) Date: Wed, 1 Jul 2015 18:31:40 +0200 Subject: [Rdo-list] [meeting] RDO packaging meeting minutes (2015-07-01) Message-ID: ======================================== #rdo: RDO packaging meeting (2015-07-01) ======================================== Meeting started by number80 at 15:04:05 UTC. The full logs are available at http://meetbot.fedoraproject.org/rdo/2015-07-01/rdo.2015-07-01-15.04.log.html . Meeting summary --------------- * roll call (number80, 15:04:11) * LINK: https://etherpad.openstack.org/p/RDO-Packaging (number80, 15:04:21) * LINK: https://trello.com/b/HhXlqdiu/rdo (number80, 15:04:26) * Icehouse 2014.1.5 rebase status (number80, 15:07:02) * ACTION: hguemar rebuild remaining 2014.1.5 rebases (number80, 15:07:55) * CI status (number80, 15:08:47) * new CI running on http://prod-rdojenkins.rhcloud.com/ (number80, 15:09:42) * delorean (sdist failure) (number80, 15:14:35) * latest master builds fail in delorean due to changes in requirements.txt (number80, 15:15:02) * LINK: https://review.gerrithub.io/#/c/238178/ (number80, 15:15:44) * newer pbr required (> 0.11) (number80, 15:17:34) * python3 (number80, 15:17:43) * ACTION: hguemar start pushing python3 builds in delorean for clients (number80, 15:18:37) * ACTION: all remove unversioned python macros in master packaging (number80, 15:19:50) * minor stuff (number80, 15:22:04) * LINK: https://fedorahosted.org/fesco/ticket/1457 (number80, 15:22:13) * fedora is moving to system-packaged jquery (number80, 15:22:22) * liberty-1 (number80, 15:25:07) * apevec pushing rpm-liberty-1 branches at github/openstack-packages repos (number80, 15:25:42) * open floor (number80, 15:26:36) Meeting ended at 15:31:36 UTC. Action Items ------------ * hguemar rebuild remaining 2014.1.5 rebases * hguemar start pushing python3 builds in delorean for clients * all remove unversioned python macros in master packaging Action Items, by person ----------------------- * **UNASSIGNED** * hguemar rebuild remaining 2014.1.5 rebases * hguemar start pushing python3 builds in delorean for clients * all remove unversioned python macros in master packaging People Present (lines said) --------------------------- * number80 (59) * jpena (8) * rbowen (4) * zodbot (3) * nmagnezi (3) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot From Yaniv.Kaul at emc.com Wed Jul 1 18:39:16 2015 From: Yaniv.Kaul at emc.com (Kaul, Yaniv) Date: Wed, 1 Jul 2015 14:39:16 -0400 Subject: [Rdo-list] Can't get Liberty installed: mariaDB issues (via packstack) Message-ID: <648473255763364B961A02AC3BE1060D03DDB5BDA3@MX19A.corp.emc.com> Using packstack, with the same answer file as I've used in Kilo: 10.103.234.197_amqp.pp: [ DONE ] 10.103.234.197_mariadb.pp: [ ERROR ] Applying Puppet manifests [ ERROR ] ERROR : Error appeared during Puppet run: 10.103.234.197_mariadb.pp Error: mysql_install_db --basedir=/usr --defaults-extra-file=/etc/my.cnf.d/server.cnf --datadir=/var/lib/mysql --user=mysql returned 1 instead of one of [0] You will find full trace in log /var/tmp/packstack/20150701-213316-XWrcs4/manifests/10.103.234.197_mariadb.pp.log Please check log file /var/tmp/packstack/20150701-213316-XWrcs4/openstack-setup.log for more information And in /var/tmp/packstack/20150701-213316-XWrcs4/manifests/10.103.234.197_mariadb.pp.log : ESC[1;31mWarning: Scope(Class[Galera::Server]): DEPRECATED: wsrep_bind_address is deprecated, you should use bind_address of mysql moduleESC[0m ESC[mNotice: Compiled catalog for lgdrm432.xiodrm.lab.emc.com in environment production in 2.31 secondsESC[0m ESC[1;31mWarning: The package type's allow_virtual parameter will be changing its default value from false to true in a future release. If you do not want to allow virtual packages, please explicitly set allow_virtual to false. (at /usr/share/ruby/vendor_ruby/puppet/type/package.rb:430:in `block (3 levels) in ')ESC[0m ESC[mNotice: /Stage[main]/Mysql::Server::Install/Package[mysql-server]/ensure: createdESC[0m ESC[mNotice: /Stage[main]/Mysql::Server::Config/File[mysql-config-file]/content: content changed '{md5}5c85b8ca651bdc927fe5f4beceaaf5e0' to '{md5}65831083ed4c4c034682d37823ae489d'ESC[0m ESC[mNotice: /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: ESC[0m ESC[mNotice: /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: FATAL ERROR: Could not find fill_help_tables.sqlESC[0m ESC[mNotice: /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: ESC[0m ESC[mNotice: /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: The following directories were searched:ESC[0m ESC[mNotice: /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: ESC[0m ESC[mNotice: /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: /usr/shareESC[0m ESC[mNotice: /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: /usr/share/mysqlESC[0m ESC[mNotice: /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: ESC[0m ESC[mNotice: /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: If you compiled from source, you need to run 'make install' toESC[0m ESC[mNotice: /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: copy the software into the correct location ready for operation.ESC[0m ESC[mNotice: /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: ESC[0m ESC[mNotice: /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: If you are using a binary release, you must either be at the topESC[0m ESC[mNotice: /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: level of the extracted archive, or pass the --basedir optionESC[0m ESC[mNotice: /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: pointing to that location.ESC[0m ESC[mNotice: /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: ESC[0m I don't mind trying Postgresql of course. Not sure Packstack already supports it? Y. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hguemar at fedoraproject.org Wed Jul 1 19:58:51 2015 From: hguemar at fedoraproject.org (=?UTF-8?Q?Ha=C3=AFkel?=) Date: Wed, 1 Jul 2015 21:58:51 +0200 Subject: [Rdo-list] Can't get Liberty installed: mariaDB issues (via packstack) In-Reply-To: <648473255763364B961A02AC3BE1060D03DDB5BDA3@MX19A.corp.emc.com> References: <648473255763364B961A02AC3BE1060D03DDB5BDA3@MX19A.corp.emc.com> Message-ID: postgresql is sadly not yet supported by Packstack. From whayutin at redhat.com Thu Jul 2 02:45:44 2015 From: whayutin at redhat.com (whayutin) Date: Wed, 01 Jul 2015 22:45:44 -0400 Subject: [Rdo-list] Can't get Liberty installed: mariaDB issues (via packstack) In-Reply-To: <648473255763364B961A02AC3BE1060D03DDB5BDA3@MX19A.corp.emc.com> References: <648473255763364B961A02AC3BE1060D03DDB5BDA3@MX19A.corp.emc.com> Message-ID: <1435805144.11499.16.camel@redhat.com> Which delorean server are you using? Also it looks like we've had successful installs w/ selinux in permissive on CentOS7 Delorean repo used in this case was: http://209.132.178.14/centos7/79/54/795476e0132a5028447a69cc6165bc81c33 a6312_d889a4c5/ On Wed, 2015-07-01 at 14:39 -0400, Kaul, Yaniv wrote: > Using packstack, with the same answer file as I?ve used in Kilo: > > 10.103.234.197_amqp.pp: [ DONE ] > > 10.103.234.197_mariadb.pp: [ ERROR ] > Applying Puppet manifests [ ERROR ] > > ERROR : Error appeared during Puppet run: 10.103.234.197_mariadb.pp > Error: mysql_install_db --basedir=/usr --defaults-extra > -file=/etc/my.cnf.d/server.cnf --datadir=/var/lib/mysql --user=mysql > returned 1 instead of one of [0] > You will find full trace in log /var/tmp/packstack/20150701-213316 > -XWrcs4/manifests/10.103.234.197_mariadb.pp.log > Please check log file /var/tmp/packstack/20150701-213316 > -XWrcs4/openstack-setup.log for more information > > And in /var/tmp/packstack/20150701-213316 > -XWrcs4/manifests/10.103.234.197_mariadb.pp.log : > > ESC[1;31mWarning: Scope(Class[Galera::Server]): DEPRECATED: > wsrep_bind_address is deprecated, you should use bind_address of > mysql moduleESC[0m > ESC[mNotice: Compiled catalog for lgdrm432.xiodrm.lab.emc.com in > environment production in 2.31 secondsESC[0m > ESC[1;31mWarning: The package type's allow_virtual parameter will be > changing its default value from false to true in a future release. If > you do not want to allow virtual packages, please explicitly set > allow_virtual to false. > (at /usr/share/ruby/vendor_ruby/puppet/type/package.rb:430:in > `block (3 levels) in ')ESC[0m > ESC[mNotice: /Stage[main]/Mysql::Server::Install/Package[mysql > -server]/ensure: createdESC[0m > ESC[mNotice: /Stage[main]/Mysql::Server::Config/File[mysql-config > -file]/content: content changed > '{md5}5c85b8ca651bdc927fe5f4beceaaf5e0' to > '{md5}65831083ed4c4c034682d37823ae489d'ESC[0m > ESC[mNotice: > /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: > ESC[0m > ESC[mNotice: > /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: > FATAL ERROR: Could not find fill_help_tables.sqlESC[0m > ESC[mNotice: > /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: > ESC[0m > ESC[mNotice: > /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: > The following directories were searched:ESC[0m > ESC[mNotice: > /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: > ESC[0m > ESC[mNotice: > /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: > /usr/shareESC[0m > ESC[mNotice: > /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: > /usr/share/mysqlESC[0m > ESC[mNotice: > /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: > ESC[0m > ESC[mNotice: > /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: > If you compiled from source, you need to run 'make install' toESC[0m > ESC[mNotice: > /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: > copy the software into the correct location ready for > operation.ESC[0m > ESC[mNotice: > /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: > ESC[0m > ESC[mNotice: > /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: > If you are using a binary release, you must either be at the > topESC[0m > ESC[mNotice: > /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: > level of the extracted archive, or pass the --basedir optionESC[0m > ESC[mNotice: > /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: > pointing to that location.ESC[0m > ESC[mNotice: > /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: > ESC[0m > > > I don?t mind trying Postgresql of course. Not sure Packstack already > supports it? > Y. > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Yaniv.Kaul at emc.com Thu Jul 2 06:06:15 2015 From: Yaniv.Kaul at emc.com (Kaul, Yaniv) Date: Thu, 2 Jul 2015 02:06:15 -0400 Subject: [Rdo-list] Can't get Liberty installed: mariaDB issues (via packstack) In-Reply-To: <1435805144.11499.16.camel@redhat.com> References: <648473255763364B961A02AC3BE1060D03DDB5BDA3@MX19A.corp.emc.com> <1435805144.11499.16.camel@redhat.com> Message-ID: <648473255763364B961A02AC3BE1060D03DDB5BDB6@MX19A.corp.emc.com> [root at lgdrm432 yum.repos.d]# cat delorean.repo [delorean] name=delorean-python-django-horizon-3b4a428cfb3a9c9f8af564d85e9cb0b0848f67fe baseurl=http://trunk.rdoproject.org/centos70/3b/4a/3b4a428cfb3a9c9f8af564d85e9cb0b0848f67fe_69675e98 enabled=1 gpgcheck=0 which is what I?ve wget from http://trunk.rdoproject.org/centos70/current/delorean.repo Y. From: whayutin [mailto:whayutin at redhat.com] Sent: Thursday, July 02, 2015 5:46 AM To: Kaul, Yaniv; rdo-list at redhat.com Subject: Re: [Rdo-list] Can't get Liberty installed: mariaDB issues (via packstack) Which delorean server are you using? Also it looks like we've had successful installs w/ selinux in permissive on CentOS7 Delorean repo used in this case was: http://209.132.178.14/centos7/79/54/795476e0132a5028447a69cc6165bc81c33a6312_d889a4c5/ On Wed, 2015-07-01 at 14:39 -0400, Kaul, Yaniv wrote: Using packstack, with the same answer file as I?ve used in Kilo: 10.103.234.197_amqp.pp: [ DONE ] 10.103.234.197_mariadb.pp: [ ERROR ] Applying Puppet manifests [ ERROR ] ERROR : Error appeared during Puppet run: 10.103.234.197_mariadb.pp Error: mysql_install_db --basedir=/usr --defaults-extra-file=/etc/my.cnf.d/server.cnf --datadir=/var/lib/mysql --user=mysql returned 1 instead of one of [0] You will find full trace in log /var/tmp/packstack/20150701-213316-XWrcs4/manifests/10.103.234.197_mariadb.pp.log Please check log file /var/tmp/packstack/20150701-213316-XWrcs4/openstack-setup.log for more information And in /var/tmp/packstack/20150701-213316-XWrcs4/manifests/10.103.234.197_mariadb.pp.log : ESC[1;31mWarning: Scope(Class[Galera::Server]): DEPRECATED: wsrep_bind_address is deprecated, you should use bind_address of mysql moduleESC[0m ESC[mNotice: Compiled catalog for lgdrm432.xiodrm.lab.emc.com in environment production in 2.31 secondsESC[0m ESC[1;31mWarning: The package type's allow_virtual parameter will be changing its default value from false to true in a future release. If you do not want to allow virtual packages, please explicitly set allow_virtual to false. (at /usr/share/ruby/vendor_ruby/puppet/type/package.rb:430:in `block (3 levels) in ')ESC[0m ESC[mNotice: /Stage[main]/Mysql::Server::Install/Package[mysql-server]/ensure: createdESC[0m ESC[mNotice: /Stage[main]/Mysql::Server::Config/File[mysql-config-file]/content: content changed '{md5}5c85b8ca651bdc927fe5f4beceaaf5e0' to '{md5}65831083ed4c4c034682d37823ae489d'ESC[0m ESC[mNotice: /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: ESC[0m ESC[mNotice: /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: FATAL ERROR: Could not find fill_help_tables.sqlESC[0m ESC[mNotice: /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: ESC[0m ESC[mNotice: /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: The following directories were searched:ESC[0m ESC[mNotice: /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: ESC[0m ESC[mNotice: /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: /usr/shareESC[0m ESC[mNotice: /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: /usr/share/mysqlESC[0m ESC[mNotice: /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: ESC[0m ESC[mNotice: /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: If you compiled from source, you need to run 'make install' toESC[0m ESC[mNotice: /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: copy the software into the correct location ready for operation.ESC[0m ESC[mNotice: /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: ESC[0m ESC[mNotice: /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: If you are using a binary release, you must either be at the topESC[0m ESC[mNotice: /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: level of the extracted archive, or pass the --basedir optionESC[0m ESC[mNotice: /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: pointing to that location.ESC[0m ESC[mNotice: /Stage[main]/Mysql::Server::Installdb/Exec[mysql_install_db]/returns: ESC[0m I don?t mind trying Postgresql of course. Not sure Packstack already supports it? Y. _______________________________________________ Rdo-list mailing list Rdo-list at redhat.com https://www.redhat.com/mailman/listinfo/rdo-list To unsubscribe: rdo-list-unsubscribe at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From javier.pena at redhat.com Thu Jul 2 11:24:02 2015 From: javier.pena at redhat.com (Javier Pena) Date: Thu, 2 Jul 2015 07:24:02 -0400 (EDT) Subject: [Rdo-list] [CI] any port changes in kilo? In-Reply-To: <2023582708.30099570.1435749370501.JavaMail.zimbra@redhat.com> References: <1435709917.2910.29.camel@redhat.com> <2023582708.30099570.1435749370501.JavaMail.zimbra@redhat.com> Message-ID: <643369456.30840340.1435836242023.JavaMail.zimbra@redhat.com> ----- Original Message ----- > > > ----- Original Message ----- > > Greetings, > > I see that the latest kilo bugs were fixed w/ the latest delorean > > builds, but I did hit an error. > > > > > > 14:55:37 TASK: [packstack/runner | Wait for openstack port 35357 to > > open] ************** > > 14:55:37 [[ previous task time: 0:00:00.025562 = > > 0.03s / 3622.74s ]] > > 14:55:37 <127.0.0.1> REMOTE_MODULE wait_for host=66.187.224.52 > > port=35357 delay=10 timeout=120 > > 14:55:37 failed: [rdo-pksk-4mdt2-rhos-ci-21-controller -> 127.0.0.1] => > > {"elapsed": 124, "failed": true} > > 14:55:37 msg: Timeout when waiting for 66.187.224.52:35357 > > 14:55:37 > > 14:55:37 msg: > > 14:55:37 Timeout when waiting for 66.187.224.52:35357 > > > > > > Are there any changes to the ports that the controller is exposing? > > > > Hi Wes, > > I'm not aware of any port changes, maybe there is a change in the security > group that made port 35357 unavailable? > Hi Wes, After some more thinking about it, I'm quite sure it's a firewall issue. The tester machine is trying to access the controller's floating IP, so it is either the external firewall denying access to port 35357, or the security group not including port 35357. Regards, Javier > Regards, > Javier > > > _______________________________________________ > > Rdo-list mailing list > > Rdo-list at redhat.com > > https://www.redhat.com/mailman/listinfo/rdo-list > > > > To unsubscribe: rdo-list-unsubscribe at redhat.com > > > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com > From cems at ebi.ac.uk Mon Jul 6 13:41:52 2015 From: cems at ebi.ac.uk (Charles Short) Date: Mon, 06 Jul 2015 14:41:52 +0100 Subject: [Rdo-list] Manila configuration Kilo Message-ID: <559A85A0.3070604@ebi.ac.uk> Hi, I have installed the latest RDO Kilo release with two compute nodes and one controller. This all works. I have an external NFS Linux server that currently provides NFS for Cinder. I want to provide another NFS export from the same server directly to an instance with Manila. I can't seem to find any guidance on how to configure a backend in the manila.conf file for this purpose. I need to know how I configure the export server ip, path etc. The only example I can find online is how to configure a backend for NetApp. http://netapp.github.io/openstack-deploy-ops-guide/kilo/content/manila.examples.manila_conf.single_svm.html I need a backend for a generic Linux NFS server Thanks From hguemar at fedoraproject.org Mon Jul 6 13:57:42 2015 From: hguemar at fedoraproject.org (=?UTF-8?Q?Ha=C3=AFkel?=) Date: Mon, 6 Jul 2015 15:57:42 +0200 Subject: [Rdo-list] Manila configuration Kilo In-Reply-To: <559A85A0.3070604@ebi.ac.uk> References: <559A85A0.3070604@ebi.ac.uk> Message-ID: 2015-07-06 15:41 GMT+02:00 Charles Short : > Hi, > > I have installed the latest RDO Kilo release with two compute nodes and one > controller. This all works. > > I have an external NFS Linux server that currently provides NFS for Cinder. > > I want to provide another NFS export from the same server directly to an > instance with Manila. I can't seem to find any guidance on how to configure > a backend in the manila.conf file for this purpose. I need to know how I > configure the export server ip, path etc. The only example I can find online > is how to configure a backend for NetApp. > > http://netapp.github.io/openstack-deploy-ops-guide/kilo/content/manila.examples.manila_conf.single_svm.html > > I need a backend for a generic Linux NFS server > You may use the glusterfs backend http://docs.openstack.org/developer/manila/devref/glusterfs_driver.html Packstack doesn't configure it yet (though puppet-manila has already glusterfs support) H. > Thanks > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com From cems at ebi.ac.uk Mon Jul 6 14:13:01 2015 From: cems at ebi.ac.uk (Charles Short) Date: Mon, 06 Jul 2015 15:13:01 +0100 Subject: [Rdo-list] Manila configuration Kilo In-Reply-To: References: <559A85A0.3070604@ebi.ac.uk> Message-ID: <559A8CED.90704@ebi.ac.uk> Hi, Thank you for the quick reply. That sounds useful for testing general Manila functionality. In an ideal world I would like the backend I use to support a multi-tenacy segmented network, this one does not - "The driver does not support network segmented multi-tenancy model, but instead works over a flat network, where the tenants share a network" I am using vxlan in the tenant network, and so would like to create a Manila share network with a vxlan segmentation id. Is there another backend that would support this, or am I bound to NetApp for this sort of support? Thanks On 06/07/2015 14:57, Ha?kel wrote: > 2015-07-06 15:41 GMT+02:00 Charles Short : >> Hi, >> >> I have installed the latest RDO Kilo release with two compute nodes and one >> controller. This all works. >> >> I have an external NFS Linux server that currently provides NFS for Cinder. >> >> I want to provide another NFS export from the same server directly to an >> instance with Manila. I can't seem to find any guidance on how to configure >> a backend in the manila.conf file for this purpose. I need to know how I >> configure the export server ip, path etc. The only example I can find online >> is how to configure a backend for NetApp. >> >> http://netapp.github.io/openstack-deploy-ops-guide/kilo/content/manila.examples.manila_conf.single_svm.html >> >> I need a backend for a generic Linux NFS server >> > You may use the glusterfs backend > http://docs.openstack.org/developer/manila/devref/glusterfs_driver.html > > Packstack doesn't configure it yet (though puppet-manila has already > glusterfs support) > > H. > >> Thanks >> >> _______________________________________________ >> Rdo-list mailing list >> Rdo-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rdo-list >> >> To unsubscribe: rdo-list-unsubscribe at redhat.com From jason.dobies at redhat.com Mon Jul 6 14:26:55 2015 From: jason.dobies at redhat.com (Jay Dobies) Date: Mon, 06 Jul 2015 10:26:55 -0400 Subject: [Rdo-list] Manila configuration Kilo In-Reply-To: <559A8CED.90704@ebi.ac.uk> References: <559A85A0.3070604@ebi.ac.uk> <559A8CED.90704@ebi.ac.uk> Message-ID: <559A902F.70108@redhat.com> Manila integration with RDO Manager is currently in progress and pretty close to being finished. You can track the upstream review here: https://review.openstack.org/#/c/188137/ We're still working on the documentation for how to enable it. On 07/06/2015 10:13 AM, Charles Short wrote: > Hi, > > Thank you for the quick reply. > > That sounds useful for testing general Manila functionality. > > In an ideal world I would like the backend I use to support a > multi-tenacy segmented network, this one does not - > > "The driver does not support network segmented multi-tenancy model, but > instead works over a flat network, where the tenants share a network" > > I am using vxlan in the tenant network, and so would like to create a > Manila share network with a vxlan segmentation id. > > Is there another backend that would support this, or am I bound to > NetApp for this sort of support? > > Thanks > > > On 06/07/2015 14:57, Ha?kel wrote: >> 2015-07-06 15:41 GMT+02:00 Charles Short : >>> Hi, >>> >>> I have installed the latest RDO Kilo release with two compute nodes >>> and one >>> controller. This all works. >>> >>> I have an external NFS Linux server that currently provides NFS for >>> Cinder. >>> >>> I want to provide another NFS export from the same server directly to an >>> instance with Manila. I can't seem to find any guidance on how to >>> configure >>> a backend in the manila.conf file for this purpose. I need to know how I >>> configure the export server ip, path etc. The only example I can find >>> online >>> is how to configure a backend for NetApp. >>> >>> http://netapp.github.io/openstack-deploy-ops-guide/kilo/content/manila.examples.manila_conf.single_svm.html >>> >>> >>> I need a backend for a generic Linux NFS server >>> >> You may use the glusterfs backend >> http://docs.openstack.org/developer/manila/devref/glusterfs_driver.html >> >> Packstack doesn't configure it yet (though puppet-manila has already >> glusterfs support) >> >> H. >> >>> Thanks >>> >>> _______________________________________________ >>> Rdo-list mailing list >>> Rdo-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/rdo-list >>> >>> To unsubscribe: rdo-list-unsubscribe at redhat.com > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com From hguemar at fedoraproject.org Mon Jul 6 15:00:03 2015 From: hguemar at fedoraproject.org (hguemar at fedoraproject.org) Date: Mon, 6 Jul 2015 15:00:03 +0000 (UTC) Subject: [Rdo-list] [Fedocal] Reminder meeting : RDO packaging meeting Message-ID: <20150706150003.9A1C360A957D@fedocal02.phx2.fedoraproject.org> Dear all, You are kindly invited to the meeting: RDO packaging meeting on 2015-07-08 from 15:00:00 to 16:00:00 UTC At rdo at irc.freenode.net The meeting will be about: RDO packaging irc meeting ([agenda](https://etherpad.openstack.org/p/RDO-Packaging)) Every week on #rdo on freenode Source: https://apps.fedoraproject.org/calendar/meeting/2017/ From Yaniv.Kaul at emc.com Mon Jul 6 15:08:17 2015 From: Yaniv.Kaul at emc.com (Kaul, Yaniv) Date: Mon, 6 Jul 2015 11:08:17 -0400 Subject: [Rdo-list] Will openstack-tempest RPM be built and put under trunk? Message-ID: <648473255763364B961A02AC3BE1060D03DDB5C222@MX19A.corp.emc.com> http://trunk.rdoproject.org/centos70/current/ specifically? TIA, Y. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbowen at redhat.com Mon Jul 6 17:18:44 2015 From: rbowen at redhat.com (Rich Bowen) Date: Mon, 06 Jul 2015 13:18:44 -0400 Subject: [Rdo-list] OpenStack Meetups, week of July 6, 2015 Message-ID: <559AB874.7020205@redhat.com> The following are the meetups I'm aware of in the coming week where OpenStack and/or RDO enthusiasts are likely to be present. If you know of others, please let me know, and/or add them to http://rdoproject.org/Events If there's a meetup in your area, please consider attending. If you attend, please consider taking a few photos, and possibly even writing up a brief summary of what was covered. --Rich * Mon Jul 6 in Tel Aviv-Yafo, IL: [ONLINE MEETUP] OpenStack & Beyond Podcast Ep 3 - High Availability in OpenStack - http://www.meetup.com/OpenStack-Israel/events/223699736/ * Tue Jul 7 in Tehran, IR: Mastering OpenStack - Step 3 - Simple Architectures - http://www.meetup.com/Iran-OpenStack/events/223709847/ * Tue Jul 7 in Reston, VA, US: OpenStack's 5th Birthday Celebration! - http://www.meetup.com/OpenStack-Nova/events/222455987/ * Wed Jul 8 in Portland, OR, US: Kilo to Liberty: The Vancouver Summit - http://www.meetup.com/OpenStack-Northwest/events/221371151/ * Thu Jul 9 in Porto Alegre, BR: IV Encontro de usu?rios do Openstack Brasil no FISL - http://www.meetup.com/Openstack-Brasil/events/223407121/ * Thu Jul 9 in Tokyo, JP: Upstream Training in Japan #3 - http://www.meetup.com/Japan-OpenStack-User-Group/events/223005607/ * Thu Jul 9 in Tokyo, JP: 2nd Tokyo OpenStack Meetup at VMware - http://www.meetup.com/Tokyo-OpenStack-Meetup/events/222733111/ * Thu Jul 9 in M?nchen, DE: OpenStack Munich - Summer "Stammtisch" Meetup - http://www.meetup.com/OpenStack-Munich/events/223708798/ * Sat Jul 11 in Bangalore, IN: OpenStack's 5th Birthday Party "Bangalore Chapter" - http://www.meetup.com/Indian-OpenStack-User-Group/events/223513171/ * Sat Jul 11 in Xian, CN: ??openstack meetup???? - http://www.meetup.com/Xian-OpenStack-Meetup/events/223734784/ * Sat Jul 11 in Nairobi, KE: OpenStack 5th B-Day - http://www.meetup.com/OpenStack-Nairobi/events/223306780/ * Sat Jul 11 in Bangalore, IN: OpenStack's 5th Birthday Party "New Delhi Chapter" - http://www.meetup.com/Indian-OpenStack-User-Group/events/223255677/ * Sun Jul 12 in Shenzhen, CN: OpenStack 5th Birthday Party - http://www.meetup.com/Shenzhen-openstack-usergroup/events/223058933/ * Sun Jul 12 in Beijing, CN: OpenStack Translators Meet Up - http://www.meetup.com/China-OpenStack-User-Group/events/223569622/ * Mon Jul 13 in Tokyo, JP: 5?????? OpenStack Summit???? - http://www.meetup.com/Japan-OpenStack-User-Group/events/223104697/ -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://rdoproject.org/ From dradez at redhat.com Mon Jul 6 17:51:31 2015 From: dradez at redhat.com (Dan Radez) Date: Mon, 6 Jul 2015 13:51:31 -0400 Subject: [Rdo-list] RDO Manager & OPNFV Demo Message-ID: <559AC023.1090109@redhat.com> We gave a preso to the OPNFV testing project Octopus today to explain making a move to using RDO manager as the installation base for one of the installation options in OPNFV. Much of the preso is explaining the OOO paradigm for installation to the group. Within the OPNFV community it's being called project Apex. It's an effort to move from the foreman based installation that was released in Release 1 named Arno to RDO manager for Release 2 named Brahmaputra. For the B release later this year we plan to have made the switch to RDO Manager and have OpenDaylight Lithium integrated into the installation. Here's a link to the demo we gave today for those that are interested in seeing where we are in the process. https://bluejeans.com/s/8o1U/ If you just want a quick summary there are two main points. 1. We have ODL working and are working on generating a patch to send up stream for the RDO community to review. 2. We are wrapping up much of the installation process into a set of OPNFV's build and deployment requirments. These requirements are to automate testing the ODL integration and to pre build as much as possible. We plan to package up as much of the images as possible during build time. If you have questions contact Tim or me and we're happy to chat about it. Dan Radez freenode: radez Tim Rozet: freenode: trozet From rdo-info at redhat.com Mon Jul 6 19:38:24 2015 From: rdo-info at redhat.com (RDO Forum) Date: Mon, 6 Jul 2015 19:38:24 +0000 Subject: [Rdo-list] [RDO] Blog roundup, week of July 6, 2015 Message-ID: <0000014e64e06351-a57b5100-1393-4b22-95c0-c672af0e927f-000000@email.amazonses.com> rbowen started a discussion. Blog roundup, week of July 6, 2015 --- Follow the link below to check it out: https://www.rdoproject.org/forum/discussion/1024/blog-roundup-week-of-july-6-2015 Have a great day! From cems at ebi.ac.uk Tue Jul 7 15:41:00 2015 From: cems at ebi.ac.uk (Charles Short) Date: Tue, 07 Jul 2015 16:41:00 +0100 Subject: [Rdo-list] Manila configuration Kilo In-Reply-To: <559A8CED.90704@ebi.ac.uk> References: <559A85A0.3070604@ebi.ac.uk> <559A8CED.90704@ebi.ac.uk> Message-ID: <559BF30C.30205@ebi.ac.uk> Hi, I have managed to get our storage team here to give me access to a NetApp. So I started reading this in detail - http://netapp.github.io/openstack-deploy-ops-guide/kilo/content/section_manila-key-concepts.html and it became quickly apparent that there appears to be no mention of a particular functionality we may need.... To elaborate - We have existing NFS exports containing files that we would like to make available to instances directly with Manila. All the documentation I have read both from NetApp and Openstack concentrates on creating new Manila shares, in NetApp speak this means the NetApp Manila backend acting on an API call to create a new FlexVol (Manila share) on the NetApp NFS filer. So how do you import existing FlexVols (NFS exports) into Manila? I looks briefly at the code and only came up with this Class that looked promising (but equally may be a red herring)- >> grep -ir -B 1 -A5 "existing" /usr/lib/python2.7/site-packages/manila/api/contrib/share_manage.py class Share_manage(extensions.ExtensionDescriptor): """Allows existing share to be 'managed' by Manila.""" name = 'ShareManage' alias = 'os-share-manage' updated = '2015-02-17T00:00:00+00:00' >> Am I missing something here (which is entirely possible) or does the API not yet expose this functionality? Thanks On 06/07/2015 15:13, Charles Short wrote: > Hi, > > Thank you for the quick reply. > > That sounds useful for testing general Manila functionality. > > In an ideal world I would like the backend I use to support a > multi-tenacy segmented network, this one does not - > > "The driver does not support network segmented multi-tenancy model, > but instead works over a flat network, where the tenants share a network" > > I am using vxlan in the tenant network, and so would like to create a > Manila share network with a vxlan segmentation id. > > Is there another backend that would support this, or am I bound to > NetApp for this sort of support? > > Thanks > > > On 06/07/2015 14:57, Ha?kel wrote: >> 2015-07-06 15:41 GMT+02:00 Charles Short : >>> Hi, >>> >>> I have installed the latest RDO Kilo release with two compute nodes >>> and one >>> controller. This all works. >>> >>> I have an external NFS Linux server that currently provides NFS for >>> Cinder. >>> >>> I want to provide another NFS export from the same server directly >>> to an >>> instance with Manila. I can't seem to find any guidance on how to >>> configure >>> a backend in the manila.conf file for this purpose. I need to know >>> how I >>> configure the export server ip, path etc. The only example I can >>> find online >>> is how to configure a backend for NetApp. >>> >>> http://netapp.github.io/openstack-deploy-ops-guide/kilo/content/manila.examples.manila_conf.single_svm.html >>> >>> >>> I need a backend for a generic Linux NFS server >>> >> You may use the glusterfs backend >> http://docs.openstack.org/developer/manila/devref/glusterfs_driver.html >> >> Packstack doesn't configure it yet (though puppet-manila has already >> glusterfs support) >> >> H. >> >>> Thanks >>> >>> _______________________________________________ >>> Rdo-list mailing list >>> Rdo-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/rdo-list >>> >>> To unsubscribe: rdo-list-unsubscribe at redhat.com > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com From rbowen at redhat.com Wed Jul 8 15:45:50 2015 From: rbowen at redhat.com (Rich Bowen) Date: Wed, 08 Jul 2015 11:45:50 -0400 Subject: [Rdo-list] Fwd: First Trove Day speakers announced: Looking for more expert panelist In-Reply-To: <1585593932.41953310.1436367462043.JavaMail.zimbra@redhat.com> References: <1585593932.41953310.1436367462043.JavaMail.zimbra@redhat.com> Message-ID: <559D45AE.3050001@redhat.com> For those of you involved in Trove, you might be interested in the following. Tesora is doing another Trove event, and is looking for speakers. --Rich ----- Forwarded Message ----- From: "Brian Otis" Subject: First Trove Day speakers announced: Looking for more expert panelist ... We are excited to announce our first round of speakers for Trove Day 2015 (http://www.tesora.com/troveday/2015-openstack-trove-day/ ) , including individuals from the Foundation, HP, IBM, SwiftStack, BlueBox, and SolidFire. We are actively working on filling the panels with enthusiastic speakers that are top minds in the OpenStack and database worlds. Think you have what it takes? Contact us (http://www.tesora.com/contact-us/ ) to be considered for a panel slot! Registration is free but space is limited, so be sure to register today (http://www.eventbrite.com/e/trove-day-2015-tickets-16502193505 ) . Brian Otis VP of Sales and Business Development P.S. Want to learn more about Trove Day. Check out the videos from last year's event http://tesora.com/troveday From hguemar at fedoraproject.org Wed Jul 8 16:08:28 2015 From: hguemar at fedoraproject.org (=?UTF-8?Q?Ha=C3=AFkel?=) Date: Wed, 8 Jul 2015 18:08:28 +0200 Subject: [Rdo-list] [meeting] RDO packaging meeting minutes (2015-07-08) Message-ID: ======================================== #rdo: RDO packaging meeting (2015-07-08) ======================================== Meeting started by number80 at 15:02:16 UTC. The full logs are available at http://meetbot.fedoraproject.org/rdo/2015-07-08/rdo.2015-07-08-15.02.log.html . Meeting summary --------------- * roll call (number80, 15:02:21) * LINK: https://etherpad.openstack.org/p/RDO-Packaging (number80, 15:02:28) * LINK: https://trello.com/b/HhXlqdiu/rdo (number80, 15:02:35) * 2014.1.5 rebase status (number80, 15:04:23) * all the builds were done, reviews are blocked by CI failures (number80, 15:04:44) * delorean in OS1 status (number80, 15:05:44) * OS1 delorean is ready for the switch (number80, 15:06:34) * ACTION: jpena to send relevant information so that rbowen could make the DNS change (number80, 15:07:40) * ACTION: host trunk.rdoproject.org homepage sources on github (number80, 15:09:26) * Fedora reviews needed for new Liberty packages (number80, 15:10:19) * ACTION: alphacc will be packaging keystoneauth (number80, 15:12:58) * LINK: https://wiki.openstack.org/wiki/Liberty_Release_Schedule (rbowen, 15:14:34) * Barbican inclusion in RDO (number80, 15:15:45) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1190269 (elmiko, 15:16:05) * LINK: https://www.rdoproject.org/packaging/rdo-packaging.html#_how_to_add_a_new_package_to_rdo_master_packaging (number80, 15:24:30) * RDO Manager status (number80, 15:27:16) * open floor (number80, 15:28:03) Meeting ended at 15:30:10 UTC. Action Items ------------ * jpena to send relevant information so that rbowen could make the DNS change * host trunk.rdoproject.org homepage sources on github * alphacc will be packaging keystoneauth Action Items, by person ----------------------- * alphacc * alphacc will be packaging keystoneauth * jpena * jpena to send relevant information so that rbowen could make the DNS change * rbowen * jpena to send relevant information so that rbowen could make the DNS change * **UNASSIGNED** * host trunk.rdoproject.org homepage sources on github People Present (lines said) --------------------------- * number80 (77) * elmiko (17) * xaeth (16) * rbowen (9) * jpena (7) * zodbot (6) * jruzicka (3) * mburned (2) * alee (2) * alphacc (1) * weshay (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot From phaurep at gmail.com Thu Jul 9 07:33:10 2015 From: phaurep at gmail.com (pauline phaure) Date: Thu, 9 Jul 2015 09:33:10 +0200 Subject: [Rdo-list] [Heat ]unauthorized to use heat Message-ID: Hey there, can anyone please help me. when I try to use heat I have this error pumping out: ERROR: Authentication required when I check the heat-api.log I found the errors below By the way I'm using the kilo version of packstack Thank you in advance for your response 2015-07-08 17:48:43.485 9954 INFO eventlet.wsgi.server [-] (9954) accepted ('192.168.5.34', 47989) 2015-07-08 17:48:43.486 9954 DEBUG heat.api.middleware.version_negotiation [-] Processing request: POST /v1/b6b814fb67b74c0c94ef7a008a953a3a/stacks Accept: application/json process_request /usr/lib/python2.7/site-packages/heat/api/middleware/version_negotiation.py:50 2015-07-08 17:48:43.487 9954 DEBUG heat.api.middleware.version_negotiation [-] Matched versioned URI. Version: 1.0 process_request /usr/lib/python2.7/site-packages/heat/api/middleware/version_negotiation.py:65 2015-07-08 17:48:43.487 9954 DEBUG keystoneclient.auth.identity.v2 [-] Making authentication request to http://192.168.5.34:35357/v2.0/tokens get_auth_ref /usr/lib/python2.7/site-packages/keystoneclient/auth/identity/v2.py:76 2015-07-08 17:48:43.551 9954 DEBUG keystoneclient.session [-] Request returned failure status: 401 request /usr/lib/python2.7/site-packages/keystoneclient/session.py:396 2015-07-08 17:48:43.552 9954 WARNING keystonemiddleware.auth_token [-] Identity response: {"error": {"message": "The request you have made requires authentication.", "code": 401, "title": "Unauthorized"}} 2015-07-08 17:48:43.552 9954 DEBUG keystoneclient.auth.identity.v2 [-] Making authentication request to http://192.168.5.34:35357/v2.0/tokens get_auth_ref /usr/lib/python2.7/site-packages/keystoneclient/auth/identity/v2.py:76 2015-07-08 17:48:43.616 9954 DEBUG keystoneclient.session [-] Request returned failure status: 401 request /usr/lib/python2.7/site-packages/keystoneclient/session.py:396 2015-07-08 17:48:43.617 9954 WARNING keystonemiddleware.auth_token [-] Identity response: {"error": {"message": "The request you have made requires authentication.", "code": 401, "title": "Unauthorized"}} 2015-07-08 17:48:43.617 9954 WARNING keystonemiddleware.auth_token [-] Authorization failed for token 2015-07-08 17:48:43.618 9954 INFO eventlet.wsgi.server [-] 192.168.5.34 - - [08/Jul/2015 17:48:43] "POST /v1/b6b814fb67b74c0c94ef7a008a953a3a/stacks HTTP/1.1" 401 290 0.131893 2015-07-08 17:48:43.724 9954 DEBUG heat.api.middleware.version_negotiation [-] Processing request: POST /v1/b6b814fb67b74c0c94ef7a008a953a3a/stacks Accept: application/json process_request /usr/lib/python2.7/site-packages/heat/api/middleware/version_negotiation.py:50 2015-07-08 17:48:43.724 9954 DEBUG heat.api.middleware.version_negotiation [-] Matched versioned URI. Version: 1.0 process_request /usr/lib/python2.7/site-packages/heat/api/middleware/version_negotiation.py:65 2015-07-08 17:48:43.724 9954 DEBUG keystoneclient.auth.identity.v2 [-] Making authentication request to http://192.168.5.34:35357/v2.0/tokens get_auth_ref /usr/lib/python2.7/site-packages/keystoneclient/auth/identity/v2.py:76 2015-07-08 17:48:43.792 9954 DEBUG keystoneclient.session [-] Request returned failure status: 401 request /usr/lib/python2.7/site-packages/keystoneclient/session.py:396 2015-07-08 17:48:43.793 9954 WARNING keystonemiddleware.auth_token [-] Identity response: {"error": {"message": "The request you have made requires authentication.", "code": 401, "title": "Unauthorized"}} 2015-07-08 17:48:43.793 9954 DEBUG keystoneclient.auth.identity.v2 [-] Making authentication request to http://192.168.5.34:35357/v2.0/tokens get_auth_ref /usr/lib/python2.7/site-packages/keystoneclient/auth/identity/v2.py:76 2015-07-08 17:48:43.859 9954 DEBUG keystoneclient.session [-] Request returned failure status: 401 request /usr/lib/python2.7/site-packages/keystoneclient/session.py:396 2015-07-08 17:48:43.859 9954 WARNING keystonemiddleware.auth_token [-] Identity response: {"error": {"message": "The request you have made requires authentication.", "code": 401, "title": "Unauthorized"}} 2015-07-08 17:48:43.860 9954 WARNING keystonemiddleware.auth_token [-] Authorization failed for token 2015-07-08 17:48:43.861 9954 INFO eventlet.wsgi.server [-] 192.168.5.34 - - [08/Jul/2015 17:48:43] "POST /v1/b6b814fb67b74c0c94ef7a008a953a3a/stacks HTTP/1.1" 401 290 0.138049 -------------- next part -------------- An HTML attachment was scrubbed... URL: From stdake at cisco.com Thu Jul 9 19:24:39 2015 From: stdake at cisco.com (Steven Dake (stdake)) Date: Thu, 9 Jul 2015 19:24:39 +0000 Subject: [Rdo-list] Odd networking behavior with fedora mirrors Message-ID: Folks, Occasionally during Kolla's gating builds of RDO, we have the following errors: http://logs.openstack.org/13/198213/7/check/check-kolla-functional-f21/8775312/console.html#_2015-07-09_17_02_34_580 This use if IPv6 seems new ? I don?t recall it being used prior. It appears it is not without bugs. Could someone have a look or send to the appropriate people? Thanks -steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From apevec at gmail.com Thu Jul 9 21:32:07 2015 From: apevec at gmail.com (Alan Pevec) Date: Thu, 9 Jul 2015 23:32:07 +0200 Subject: [Rdo-list] Odd networking behavior with fedora mirrors In-Reply-To: References: Message-ID: > Occasionally during Kolla's gating builds of RDO, we have the following errors: Does it happen in both RAX and HP clouds, maybe one of them doesn't support IPv6 ? > http://logs.openstack.org/13/198213/7/check/check-kolla-functional-f21/8775312/console.html#_2015-07-09_17_02_34_580 Error is: http://repos.fedorapeople.org/repos/openstack/openstack-kilo/el7/repodata/repomd.xml: [Errno 14] curl#7 - "Failed to connect to 2610:28:3090:3001:5054:ff:feb9:6ae0: Network is unreachable" repos.fedorapeople.org resolves to: repos.fedorapeople.org has address 152.19.134.196 repos.fedorapeople.org has IPv6 address 2610:28:3090:3001:5054:ff:feb9:6ae0 I don't have IPv6 network available to test, but as a silly workaround you could replace repos.fedorapeople.org with 152.19.134.196 in rdo-release.repo after installing rdo-release.rpm ... Cheers, Alan From asadxflow at gmail.com Fri Jul 10 00:37:35 2015 From: asadxflow at gmail.com (sad man) Date: Fri, 10 Jul 2015 02:37:35 +0200 Subject: [Rdo-list] Manually Install RDO packages Message-ID: Hi, as I've mentioned that I am working on a RDO-Fedora remix for my GSoC. I have a problem regarding PackStack "yum". My idea is to install RDO packages during OS installation (when other system packages are being installed) and then PackStack at first boot. (I am writing an Anaconda add-on to do so). But the problem is that even if all packages are already installed packstack still tries to run: yum install -y puppet hiera .... which results in an error on a system that is offline (I use a VM with no internet connectivity so that install is totally offline). ?Is there a solution to this?? PS: PackStack works if I place RDO rpms in yum cache and direct repo url to this cache folder. -- Cheers, Asadullah Hussain -------------- next part -------------- An HTML attachment was scrubbed... URL: From contact at progbau.de Fri Jul 10 03:23:39 2015 From: contact at progbau.de (Chris) Date: Fri, 10 Jul 2015 10:23:39 +0700 Subject: [Rdo-list] Neutron notifiers error on instance delete Message-ID: <004601d0babf$d2459600$76d0c200$@progbau.de> Hello, When deleting a instance by the openstack API (DELETE? {tenant_id}?/servers/?{server_id}) we see the following error on the neutron server, the instance isn?t deleted and change to error status: 2015-07-06 13:00:31.084 45873 ERROR neutron.notifiers.nova [req-7cf6c8a7-15a2-4c7e-8a84-97e173697ab0 None] Failed to notify nova on events: [{'status': 'completed', 'tag': u'267d2fc6-8ccb-4e6a-b88b-9caa3f09ba83', 'name': 'network-vif-unplugged', 'server_uuid': u'1eb1b855-e8fd-4df0-840e-d5fae0b69dda'}] 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova Traceback (most recent call last): 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova File "/usr/lib/python2.6/site-packages/neutron/notifiers/nova.py", line 187, in send_events 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova batched_events) 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova File "/usr/lib/python2.6/site-packages/novaclient/v1_1/contrib/server_external_events.py", line 39, in create 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova return_raw=True) 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova File "/usr/lib/python2.6/site-packages/novaclient/base.py", line 152, in _create 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova _resp, body = self.api.client.post(url, body=body) 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova File "/usr/lib/python2.6/site-packages/novaclient/client.py", line 312, in post 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova return self._cs_request(url, 'POST', **kwargs) 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova File "/usr/lib/python2.6/site-packages/novaclient/client.py", line 298, in _cs_request 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova method, **kwargs) 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova File "/usr/lib/python2.6/site-packages/novaclient/client.py", line 268, in _time_request 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova resp, body = self.request(url, method, **kwargs) 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova File "/usr/lib/python2.6/site-packages/novaclient/client.py", line 262, in request 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova raise exceptions.from_response(resp, body, url, method) 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova NotFound: No instances found for any event (HTTP 404) (Request-ID: req-63a9ba3f-f1d3-4c5f-ae94-e6a7b4e6bb15) 2015-07-06 13:00:31.084 45873 TRACE neutron.notifiers.nova 2015-07-06 13:00:31.130 45873 INFO neutron.wsgi [-] (45873) accepted ('10.121.36.25', 49882) Any help appreciated! Cheers, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Fri Jul 10 04:15:32 2015 From: ayoung at redhat.com (Adam Young) Date: Fri, 10 Jul 2015 00:15:32 -0400 Subject: [Rdo-list] [Heat ]unauthorized to use heat In-Reply-To: References: Message-ID: <559F46E4.1070707@redhat.com> On 07/09/2015 03:33 AM, pauline phaure wrote: > Hey there, can anyone please help me. In order to use any service, you need a scoped token. I suspect taht the Heat API is limited to Admin users, and maybe you are using the demo user token? http://git.openstack.org/cgit/openstack/heat/tree/etc/heat/policy.json You don't say What API you are trying to call. Most of the Heat APIs look like they are: |"deny_stack_user": "not role:heat_stack_user",| But a few are |"role:admin",| |"stacks:global_index": is deny everybody| > > when I try to use heat I have this error pumping out: > > ERROR: Authentication required > > when I check the heat-api.log I found the errors below > > By the way I'm using the kilo version of packstack > > Thank you in advance for your response > > 2015-07-08 17:48:43.485 9954 INFO eventlet.wsgi.server [-] (9954) > accepted ('192.168.5.34', 47989) > 2015-07-08 17:48:43.486 9954 DEBUG > heat.api.middleware.version_negotiation [-] Processing request: POST > /v1/b6b814fb67b74c0c94ef7a008a953a3a/stacks Accept: application/json > process_request > /usr/lib/python2.7/site-packages/heat/api/middleware/version_negotiation.py:50 > 2015-07-08 17:48:43.487 9954 DEBUG > heat.api.middleware.version_negotiation [-] Matched versioned URI. > Version: 1.0 process_request > /usr/lib/python2.7/site-packages/heat/api/middleware/version_negotiation.py:65 > 2015-07-08 17:48:43.487 9954 DEBUG keystoneclient.auth.identity.v2 [-] > Making authentication request to http://192.168.5.34:35357/v2.0/tokens > get_auth_ref > /usr/lib/python2.7/site-packages/keystoneclient/auth/identity/v2.py:76 > 2015-07-08 17:48:43.551 9954 DEBUG keystoneclient.session [-] Request > returned failure status: 401 request > /usr/lib/python2.7/site-packages/keystoneclient/session.py:396 > 2015-07-08 17:48:43.552 9954 WARNING keystonemiddleware.auth_token [-] > Identity response: {"error": {"message": "The request you have made > requires authentication.", "code": 401, "title": "Unauthorized"}} > 2015-07-08 17:48:43.552 9954 DEBUG keystoneclient.auth.identity.v2 [-] > Making authentication request to http://192.168.5.34:35357/v2.0/tokens > get_auth_ref > /usr/lib/python2.7/site-packages/keystoneclient/auth/identity/v2.py:76 > 2015-07-08 17:48:43.616 9954 DEBUG keystoneclient.session [-] Request > returned failure status: 401 request > /usr/lib/python2.7/site-packages/keystoneclient/session.py:396 > 2015-07-08 17:48:43.617 9954 WARNING keystonemiddleware.auth_token [-] > Identity response: {"error": {"message": "The request you have made > requires authentication.", "code": 401, "title": "Unauthorized"}} > 2015-07-08 17:48:43.617 9954 WARNING keystonemiddleware.auth_token [-] > Authorization failed for token > 2015-07-08 17:48:43.618 9954 INFO eventlet.wsgi.server [-] > 192.168.5.34 - - [08/Jul/2015 17:48:43] "POST > /v1/b6b814fb67b74c0c94ef7a008a953a3a/stacks HTTP/1.1" 401 290 0.131893 > 2015-07-08 17:48:43.724 9954 DEBUG > heat.api.middleware.version_negotiation [-] Processing request: POST > /v1/b6b814fb67b74c0c94ef7a008a953a3a/stacks Accept: application/json > process_request > /usr/lib/python2.7/site-packages/heat/api/middleware/version_negotiation.py:50 > 2015-07-08 17:48:43.724 9954 DEBUG > heat.api.middleware.version_negotiation [-] Matched versioned URI. > Version: 1.0 process_request > /usr/lib/python2.7/site-packages/heat/api/middleware/version_negotiation.py:65 > 2015-07-08 17:48:43.724 9954 DEBUG keystoneclient.auth.identity.v2 [-] > Making authentication request to http://192.168.5.34:35357/v2.0/tokens > get_auth_ref > /usr/lib/python2.7/site-packages/keystoneclient/auth/identity/v2.py:76 > 2015-07-08 17:48:43.792 9954 DEBUG keystoneclient.session [-] Request > returned failure status: 401 request > /usr/lib/python2.7/site-packages/keystoneclient/session.py:396 > 2015-07-08 17:48:43.793 9954 WARNING keystonemiddleware.auth_token [-] > Identity response: {"error": {"message": "The request you have made > requires authentication.", "code": 401, "title": "Unauthorized"}} > 2015-07-08 17:48:43.793 9954 DEBUG keystoneclient.auth.identity.v2 [-] > Making authentication request to http://192.168.5.34:35357/v2.0/tokens > get_auth_ref > /usr/lib/python2.7/site-packages/keystoneclient/auth/identity/v2.py:76 > 2015-07-08 17:48:43.859 9954 DEBUG keystoneclient.session [-] Request > returned failure status: 401 request > /usr/lib/python2.7/site-packages/keystoneclient/session.py:396 > 2015-07-08 17:48:43.859 9954 WARNING keystonemiddleware.auth_token [-] > Identity response: {"error": {"message": "The request you have made > requires authentication.", "code": 401, "title": "Unauthorized"}} > 2015-07-08 17:48:43.860 9954 WARNING keystonemiddleware.auth_token [-] > Authorization failed for token > 2015-07-08 17:48:43.861 9954 INFO eventlet.wsgi.server [-] > 192.168.5.34 - - [08/Jul/2015 17:48:43] "POST > /v1/b6b814fb67b74c0c94ef7a008a953a3a/stacks HTTP/1.1" 401 290 0.138049 > > > > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From chkumar246 at gmail.com Fri Jul 10 07:04:05 2015 From: chkumar246 at gmail.com (Chandan kumar) Date: Fri, 10 Jul 2015 12:34:05 +0530 Subject: [Rdo-list] [Package Review] python-oslo-cache - Cache storage for Openstack Message-ID: Hello, Below is my package review request: [1.] Python-oslo-cache - https://bugzilla.redhat.com/show_bug.cgi?id=1241808 Please review it. Thanks, Chandan Kumar -------------- next part -------------- An HTML attachment was scrubbed... URL: From shardy at redhat.com Fri Jul 10 09:43:13 2015 From: shardy at redhat.com (Steven Hardy) Date: Fri, 10 Jul 2015 10:43:13 +0100 Subject: [Rdo-list] [Heat ]unauthorized to use heat In-Reply-To: <559F46E4.1070707@redhat.com> References: <559F46E4.1070707@redhat.com> Message-ID: <20150710094313.GB25120@t430slt.redhat.com> On Fri, Jul 10, 2015 at 12:15:32AM -0400, Adam Young wrote: > On 07/09/2015 03:33 AM, pauline phaure wrote: > > Hey there, can anyone please help me. > > In order to use any service, you need a scoped token. I suspect taht the > Heat API is limited to Admin users, and maybe you are using the demo user > token? Nearly all heat API paths should be accessible to non-admin users. > http://git.openstack.org/cgit/openstack/heat/tree/etc/heat/policy.json > > You don't say What API you are trying to call. Most of the Heat APIs look > like they are: > > "deny_stack_user": "not role:heat_stack_user", This is a common mistake, "real" users accessing the heat service should *not* have the heat_stack_user role - this role is reserved for internal use inside heat, and is used to limit the API surface available to in-instance agents. > But a few are "role:admin", > > "stacks:global_index": is deny everybody Yeah, these are a couple of things like this, but all API operations required for normal usage of heat should be accessible to non-admin users. The "deny everybody" one is a special case, designed to disable a global lookup which the community felt was unsafe to enable by default, e.g to force deployers to secure it with their own role/policy. Steve From stdake at cisco.com Fri Jul 10 16:58:18 2015 From: stdake at cisco.com (Steven Dake (stdake)) Date: Fri, 10 Jul 2015 16:58:18 +0000 Subject: [Rdo-list] Delorean repos appear down Message-ID: Hi folks, I try to download Delorean from here: http://trunk.rdoproject.org/ And get a link not found. Could someone take a look please? Thanks -steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From Pascal.Bernier at ormuco.com Fri Jul 10 17:09:44 2015 From: Pascal.Bernier at ormuco.com (Pascal Bernier) Date: Fri, 10 Jul 2015 17:09:44 +0000 Subject: [Rdo-list] FW: Delorean repos appear down References: Message-ID: <78da0028a2b8492e8ddda8ecdffc967d@exchange1.ormuco.lcl> Hi Steve, The links on the website are wrong, here are the good ones for centos 7 : http://trunk.rdoproject.org/centos7/current/ http://trunk.rdoproject.org/centos7/current/delorean.repo Posting on the list so the maintainer is aware and fix it. Regards -Pascal From: rdo-list-bounces at redhat.com [mailto:rdo-list-bounces at redhat.com] On Behalf Of Steven Dake (stdake) Sent: Friday, July 10, 2015 12:58 PM To: rdo-list at redhat.com Subject: [Rdo-list] Delorean repos appear down Hi folks, I try to download Delorean from here: http://trunk.rdoproject.org/ And get a link not found. Could someone take a look please? Thanks -steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbowen at redhat.com Fri Jul 10 18:39:58 2015 From: rbowen at redhat.com (Rich Bowen) Date: Fri, 10 Jul 2015 14:39:58 -0400 Subject: [Rdo-list] FW: Delorean repos appear down In-Reply-To: <78da0028a2b8492e8ddda8ecdffc967d@exchange1.ormuco.lcl> References: <78da0028a2b8492e8ddda8ecdffc967d@exchange1.ormuco.lcl> Message-ID: <55A0117E.30908@redhat.com> We just switched to a new host for trunk.rdoproject.org and it looks like the symlink is to centos7 rather than centos70. It appears that my ssh key is not yet on the new server, so I'm waiting for that to happen so that I can fix the link. I'm very sorry for the outage. Looks like I didn't adequately test before making the DNS change. --Rich On 07/10/2015 01:09 PM, Pascal Bernier wrote: > Hi Steve, > > The links on the website are wrong, here are the good ones for centos 7 : > > http://trunk.rdoproject.org/centos7/current/ > > http://trunk.rdoproject.org/centos7/current/delorean.repo > > Posting on the list so the maintainer is aware and fix it. > > Regards > > -Pascal > > *From:*rdo-list-bounces at redhat.com > [mailto:rdo-list-bounces at redhat.com] *On Behalf Of *Steven Dake (stdake) > *Sent:* Friday, July 10, 2015 12:58 PM > *To:* rdo-list at redhat.com > *Subject:* [Rdo-list] Delorean repos appear down > > Hi folks, > > I try to download Delorean from here: > > http://trunk.rdoproject.org/ > > And get a link not found. Could someone take a look please? > > Thanks > > -steve > > > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com > -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://rdoproject.org/ From hguemar at fedoraproject.org Fri Jul 10 22:40:25 2015 From: hguemar at fedoraproject.org (=?UTF-8?Q?Ha=C3=AFkel?=) Date: Sat, 11 Jul 2015 00:40:25 +0200 Subject: [Rdo-list] FW: Delorean repos appear down In-Reply-To: <55A0117E.30908@redhat.com> References: <78da0028a2b8492e8ddda8ecdffc967d@exchange1.ormuco.lcl> <55A0117E.30908@redhat.com> Message-ID: 2015-07-10 20:39 GMT+02:00 Rich Bowen : > We just switched to a new host for trunk.rdoproject.org and it looks like > the symlink is to centos7 rather than centos70. It appears that my ssh key > is not yet on the new server, so I'm waiting for that to happen so that I > can fix the link. I'm very sorry for the outage. Looks like I didn't > adequately test before making the DNS change. > > --Rich > I just fixed it. Good thing, I asked Javier to give me access to the new host last week. btw, we don't expose the stable/kilo delorean repo. Regards, H. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bderzhavets at hotmail.com Sun Jul 12 12:17:39 2015 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Sun, 12 Jul 2015 08:17:39 -0400 Subject: [Rdo-list] What happens to RDO Kilo on Fedora 22 ? In-Reply-To: References: <5567511B.2050109@berendt.io>, , Message-ID: To enable packstack on F22 there is a hack :- # dnf install -y https://rdoproject.org/repos/rdo-release.rpm # dnf install -y openstack-packstack # dnf install -y fedora-repos-rawhide # dnf --enablerepo=rawhide update openstack-packstack along with disabling Neutron verification section in provision_demo.pp it allows AIO and Two node "Controller&&Network and Compute" RDO Kilo packstack installs on F22 VMs and bare metal boxes. However, splitting Controller and Network Nodes, e.g. three node packstack install appears not to be able to work in meantime, regardless successful packstack completion. What, actually, happens ? I am able to create external net and sub-net only via CLI (as admin) and change status to shared. Attempt to launch VM results qrouter-namespace to loose qg-xxxx, qr-yyyy interfaces. Outbound/inbound packets forwarding gets broken as soon as VM gets started. Only when nova and neutron services are running on the same node it doesn't happen. It's just my personal experience. RDO Kilo Three node deployment on CentOS 7.1 works fine. Thanks. Boris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From amuller at redhat.com Sun Jul 12 19:45:26 2015 From: amuller at redhat.com (Assaf Muller) Date: Sun, 12 Jul 2015 15:45:26 -0400 (EDT) Subject: [Rdo-list] What happens to RDO Kilo on Fedora 22 ? In-Reply-To: References: <5567511B.2050109@berendt.io> Message-ID: <111239091.41150137.1436730326608.JavaMail.zimbra@redhat.com> Can you paste openvswitch agent and L3 agent logs on the network node when you spawn a VM and the router loses its qr/qg interfaces? ----- Original Message ----- > To enable packstack on F22 there is a hack :- > > # dnf install -y https://rdoproject.org/repos/rdo-release.rpm > # dnf install -y openstack-packstack > # dnf install -y fedora-repos-rawhide > # dnf --enablerepo=rawhide update openstack-packstack > > along with disabling Neutron verification section in provision_demo.pp it > allows AIO and > Two node "Controller&&Network and Compute" RDO Kilo packstack installs on F22 > VMs and bare metal boxes. > However, splitting Controller and Network Nodes, e.g. three node packstack > install appears not to be able to work > in meantime, regardless successful packstack completion. > What, actually, happens ? I am able to create external net and sub-net only > via CLI (as admin) and change status to shared. > > Attempt to launch VM results qrouter-namespace to loose qg-xxxx, qr-yyyy > interfaces. > Outbound/inbound packets forwarding gets broken as soon as VM gets started. > Only when nova and neutron > services are running on the same node it doesn't happen. It's just my > personal experience. > RDO Kilo Three node deployment on CentOS 7.1 works fine. > > Thanks. > Boris. > > > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com From bderzhavets at hotmail.com Sun Jul 12 20:04:30 2015 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Sun, 12 Jul 2015 16:04:30 -0400 Subject: [Rdo-list] What happens to RDO Kilo on Fedora 22 ? In-Reply-To: <111239091.41150137.1436730326608.JavaMail.zimbra@redhat.com> References: <5567511B.2050109@berendt.io> , <111239091.41150137.1436730326608.JavaMail.zimbra@redhat.com> Message-ID: > Date: Sun, 12 Jul 2015 15:45:26 -0400 > From: amuller at redhat.com > To: bderzhavets at hotmail.com > CC: apevec at gmail.com; rdo-list at redhat.com > Subject: Re: [Rdo-list] What happens to RDO Kilo on Fedora 22 ? > > > > Can you paste openvswitch agent and L3 agent logs on the network node > when you spawn a VM and the router loses its qr/qg interfaces? In meantime I don't have this 3 VMs alive, if it's important I will build all configuration again. It might take a couple of days. > > ----- Original Message ----- > > To enable packstack on F22 there is a hack :- > > > > # dnf install -y https://rdoproject.org/repos/rdo-release.rpm > > # dnf install -y openstack-packstack > > # dnf install -y fedora-repos-rawhide > > # dnf --enablerepo=rawhide update openstack-packstack > > > > along with disabling Neutron verification section in provision_demo.pp it > > allows AIO and > > Two node "Controller&&Network and Compute" RDO Kilo packstack installs on F22 > > VMs and bare metal boxes. > > However, splitting Controller and Network Nodes, e.g. three node packstack > > install appears not to be able to work > > in meantime, regardless successful packstack completion. > > What, actually, happens ? I am able to create external net and sub-net only > > via CLI (as admin) and change status to shared. > > > > Attempt to launch VM results qrouter-namespace to loose qg-xxxx, qr-yyyy > > interfaces. > > Outbound/inbound packets forwarding gets broken as soon as VM gets started. > > Only when nova and neutron > > services are running on the same node it doesn't happen. It's just my > > personal experience. > > RDO Kilo Three node deployment on CentOS 7.1 works fine. > > > > Thanks. > > Boris. > > > > > > > > _______________________________________________ > > Rdo-list mailing list > > Rdo-list at redhat.com > > https://www.redhat.com/mailman/listinfo/rdo-list > > > > To unsubscribe: rdo-list-unsubscribe at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From 90.suman at gmail.com Mon Jul 13 05:51:05 2015 From: 90.suman at gmail.com (saurabh suman) Date: Mon, 13 Jul 2015 01:51:05 -0400 Subject: [Rdo-list] packstack --allinone error in fedora 21 Message-ID: Hi, I am following https://www.rdoproject.org/Quickstart to install openstack on fedora 21. While all the commands ran successfully the last command packstack --allinone gave error [image: Inline image 1] Can anyone help me out here. Regards, Saurav -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 78846 bytes Desc: not available URL: From 90.suman at gmail.com Mon Jul 13 12:01:31 2015 From: 90.suman at gmail.com (saurabh suman) Date: Mon, 13 Jul 2015 17:31:31 +0530 Subject: [Rdo-list] packstack --allinone error in fedora 21 Message-ID: Hi, I am following https://www.rdoproject.org/Quickstart to install openstack on fedora 21. While all the commands ran successfully the last command packstack --allinone gave error [image: Inline image 1] Can anyone help me out here. Regards, Saurav -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 78846 bytes Desc: not available URL: From bderzhavets at hotmail.com Mon Jul 13 13:37:15 2015 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Mon, 13 Jul 2015 09:37:15 -0400 Subject: [Rdo-list] RE(2): What happens to RDO Kilo on Fedora 22 ? In-Reply-To: <111239091.41150137.1436730326608.JavaMail.zimbra@redhat.com> References: <5567511B.2050109@berendt.io> , <111239091.41150137.1436730326608.JavaMail.zimbra@redhat.com> Message-ID: > Date: Sun, 12 Jul 2015 15:45:26 -0400 > From: amuller at redhat.com > To: bderzhavets at hotmail.com > CC: apevec at gmail.com; rdo-list at redhat.com > Subject: Re: [Rdo-list] What happens to RDO Kilo on Fedora 22 ? > > Can you paste openvswitch agent and L3 agent logs on the network node > when you spawn a VM and the router loses its qr/qg interfaces? I've rebuild via packstack 3 F22 VMs hosting Controller,Network,Compute Node Libvirt subnet for emulating external sub-net was as follows # cat public.xml public d0e9965b-f92c-40c1-b749-b609aed42cf2 Attempt to create public sub-net via dashboard failed with message, that 172.24.4.225 is incorrect gateway dor 172.24.4.224/28 Then I created this sub-net via CLI as admin. This time ( more powerful box ) qrouter-namespace kept staying in normal shape (ifconfig) , but I was unable to ping gateway 172.24.4.225 from Network Node with qg-xxxxx (172.24.4.226) and br-ex 172.24.4.232 # source keystonerc_admin # ip netns exec qrouter-namespace ping -c 3 172.24.4.225 hanged Same results I got for Network 174.24.4.192 / 26 gateway 174.24.4.193 Then I rebuilt external (neutron) and corresponding libvirt sub-net in way it always been used for AIO and two node installs (network XXX.XXX.XXX.0/24 , gateway XXX.XXX.XXX.1) . # cat public.xml public d0e9965b-f92c-40c1-b749-b609aed42cf2 In other words used 192.168.174.0/24 as external sub-net. This time I succeeded with sub-net creation via Dashboard. I became able to ping 192.168.174.1 via both qrouter or qdhcp namespaces Outbound/inbound connectivity was tested OK for Cirros 0.3.4 and F22 cloud VMs. In meantime I believe that network calculator invoked for creating sub-nets is broken. Another issue is creating ext net via CLI which allows to create unreachable gateway. > > ----- Original Message ----- > > To enable packstack on F22 there is a hack :- > > > > # dnf install -y https://rdoproject.org/repos/rdo-release.rpm > > # dnf install -y openstack-packstack > > # dnf install -y fedora-repos-rawhide > > # dnf --enablerepo=rawhide update openstack-packstack > > > > along with disabling Neutron verification section in provision_demo.pp it > > allows AIO and > > Two node "Controller&&Network and Compute" RDO Kilo packstack installs on F22 > > VMs and bare metal boxes. > > However, splitting Controller and Network Nodes, e.g. three node packstack > > install appears not to be able to work > > in meantime, regardless successful packstack completion. > > What, actually, happens ? I am able to create external net and sub-net only > > via CLI (as admin) and change status to shared. > > > > Attempt to launch VM results qrouter-namespace to loose qg-xxxx, qr-yyyy > > interfaces. > > Outbound/inbound packets forwarding gets broken as soon as VM gets started. > > Only when nova and neutron > > services are running on the same node it doesn't happen. It's just my > > personal experience. > > RDO Kilo Three node deployment on CentOS 7.1 works fine. > > > > Thanks. > > Boris. > > > > > > > > _______________________________________________ > > Rdo-list mailing list > > Rdo-list at redhat.com > > https://www.redhat.com/mailman/listinfo/rdo-list > > > > To unsubscribe: rdo-list-unsubscribe at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bderzhavets at hotmail.com Mon Jul 13 14:55:27 2015 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Mon, 13 Jul 2015 10:55:27 -0400 Subject: [Rdo-list] packstack --allinone error in fedora 21 In-Reply-To: References: Message-ID: From: 90.suman at gmail.com Date: Mon, 13 Jul 2015 01:51:05 -0400 To: rdo-list at redhat.com; openstack at lists.openstack.org Subject: [Rdo-list] packstack --allinone error in fedora 21 Hi, I am following https://www.rdoproject.org/Quickstart to install openstack on fedora 21. While all the commands ran successfully the last command packstack --allinone gave error > Can anyone help me out here. I guess you are not the first person raising up this question. View for instance :- https://ask.openstack.org/en/question/69069/fedora-21kilo-install-could-not-prefetch-keystone_service-provider-openstack/?answer=78357#post-id-78357>Regards, >Saurav _______________________________________________ Rdo-list mailing list Rdo-list at redhat.com https://www.redhat.com/mailman/listinfo/rdo-list To unsubscribe: rdo-list-unsubscribe at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 78846 bytes Desc: not available URL: From hguemar at fedoraproject.org Mon Jul 13 15:00:03 2015 From: hguemar at fedoraproject.org (hguemar at fedoraproject.org) Date: Mon, 13 Jul 2015 15:00:03 +0000 (UTC) Subject: [Rdo-list] [Fedocal] Reminder meeting : RDO packaging meeting Message-ID: <20150713150003.8266D60A957D@fedocal02.phx2.fedoraproject.org> Dear all, You are kindly invited to the meeting: RDO packaging meeting on 2015-07-15 from 15:00:00 to 16:00:00 UTC At rdo at irc.freenode.net The meeting will be about: RDO packaging irc meeting ([agenda](https://etherpad.openstack.org/p/RDO-Packaging)) Every week on #rdo on freenode Source: https://apps.fedoraproject.org/calendar/meeting/2017/ From rbowen at redhat.com Mon Jul 13 15:52:15 2015 From: rbowen at redhat.com (Rich Bowen) Date: Mon, 13 Jul 2015 11:52:15 -0400 Subject: [Rdo-list] OpenStack Meetups, week of July 13th Message-ID: <55A3DEAF.7040409@redhat.com> The following are the meetups I'm aware of in the coming week where OpenStack and/or RDO enthusiasts are likely to be present. If you know of others, please let me know, and/or add them to http://rdoproject.org/Events If there's a meetup in your area, please consider attending. If you attend, please consider taking a few photos, and possibly even writing up a brief summary of what was covered. --Rich * Mon Jul 13 in Tel Aviv-Yafo, IL: OpenStack 5th Birthday Celebration! - http://www.meetup.com/OpenStack-Israel/events/223471823/ * Tue Jul 14 in Roma, RM, IT: OpenStack Birthday - http://www.meetup.com/OpenStack-User-Group-Italia/events/223738450/ * Tue Jul 14 in Hong Kong, HK: Last Call for the OpenStack 5th Birthday Celebration cum OpenStackers Meetup - http://www.meetup.com/Hong-Kong-OpenStack-User-Group/events/223330325/ * Wed Jul 15 in Buenos Aires, AR: OpenStack 5th Birthday - http://www.meetup.com/openstack-argentina/events/223037923/ * Wed Jul 15 in Sydney, AU: Newbie OpenStack Contribution & 5th Birthday Celebration - Sydney Meetup - http://www.meetup.com/Australian-OpenStack-User-Group/events/223343830/ * Wed Jul 15 in New York, NY, US: OpenStack Fifth Anniversary Celebration - http://www.meetup.com/OpenStack-New-York-Meetup/events/223640922/ * Wed Jul 15 in Phoenix, AZ, US: Cloud Foundry, Docker, or OpenStack - Why Choose? - http://www.meetup.com/Big-Data-Developers-in-Phoenix/events/223477030/ * Wed Jul 15 in Stuttgart, DE: OpenStack 5th Birthday Celebration Party - http://www.meetup.com/OpenStack-Baden-Wuerttemberg/events/223278479/ * Thu Jul 16 in Whittier, CA, US: Ceph Day Los Angeles - http://www.meetup.com/Southern-California-Red-Hat-User-Group-RHUG/events/222946299/ * Thu Jul 16 in Vancouver, BC, CA: OpenStack's 5th Birthday (PARTY!) - http://www.meetup.com/Vancouver-OpenStack-Meetup/events/223361407/ * Thu Jul 16 in Philadelphia, PA, US: OpenStack Fifth Anniversary Celebration - http://www.meetup.com/Philly-OpenStack-Meetup-Group/events/223640952/ * Thu Jul 16 in Sydney, AU: 'Tales from the Trenches' & OpenStack 5th Birthday - Melbourne Meetup - http://www.meetup.com/Australian-OpenStack-User-Group/events/223344122/ * Thu Jul 16 in Seattle, WA, US: Go Back to the Future for OpenStack's 5th Birthday - http://www.meetup.com/OpenStack-Seattle/events/220287130/ * Thu Jul 16 in Portland, OR, US: OpenStack PDX Meetup - http://www.meetup.com/openstack-pdx/events/223202614/ * Thu Jul 16 in Fort Collins, CO, US: OpenStack 5th Birthday Celebration - http://www.meetup.com/OpenStack-Colorado/events/223495998/ * Thu Jul 16 in Budapest, HU: OpenStack's 5th Birthday party Budapest - http://www.meetup.com/OpenStack-Hungary-Meetup-Group/events/223514252/ * Thu Jul 16 in Austin, TX, US: July meetup to get after OpenStack Monasca - http://www.meetup.com/OpenStack-Austin/events/223068769/ * Thu Jul 16 in Littleton, CO, US: OpenStack 5th Birthday Celebration - http://www.meetup.com/OpenStack-Denver/events/223494384/ * Thu Jul 16 in Herriman, UT, US: Murano: Choose Your Adventure App Catalog for Openstack - http://www.meetup.com/openstack-utah/events/222859152/ * Thu Jul 16 in Sydney, AU: Developing on OpenDaylight: lessons learned - http://www.meetup.com/Australian-SDN-Meetup/events/223780427/ * Thu Jul 16 in Pasadena, CA, US: DigitalFilm Tree/OpenStack 5th Birthday Gala. The July OpenStack L.A. Meetup - http://www.meetup.com/OpenStack-LA/events/223611083/ * Thu Jul 16 in Atlanta, GA, US: OpenStack birthday party & Introduction to Swift Object Store - http://www.meetup.com/openstack-atlanta/events/223011563/ * Thu Jul 16 in Boston, MA, US: OpenStack Networking: L4-L7 Services Deep-dive and KeyStone apolloza! - http://www.meetup.com/Openstack-Boston/events/222147153/ * Thu Jul 16 in San Francisco, CA, US: SFBay OpenStack Advanced #OSSFO Topic: Rally ... details TBD - http://www.meetup.com/openstack/events/215648062/ * Fri Jul 17 in Z?rich, CH: 5th OpenStack Birthday Celebration 2015 - http://www.meetup.com/openstack-ch/events/222183011/ * Sat Jul 18 in Bangalore, IN: Take you first step towards " OpenStack " Cloud Learning - http://www.meetup.com/Cloud-Enabled-Meetup/events/223760288/ * Sat Jul 18 in Hyderabad, IN: Discuss the latest and the happening on the Openstack Platform - http://www.meetup.com/Hyderabad-OpenStack-Users-Group/events/223806078/ * Sun Jul 19 in Tel Aviv-Yafo, IL: Openstack Neutron Latest SDN Trends - http://www.meetup.com/OpenStack-Israel/events/223786538/ -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://rdoproject.org/ From rbowen at redhat.com Mon Jul 13 16:31:08 2015 From: rbowen at redhat.com (Rich Bowen) Date: Mon, 13 Jul 2015 12:31:08 -0400 Subject: [Rdo-list] Fwd: BoF proposal accepted for OSCON 2015 In-Reply-To: <55a3e6f9b8b8b_2aa2b22a1c4386@en-prod2.mail> References: <55a3e6f9b8b8b_2aa2b22a1c4386@en-prod2.mail> Message-ID: <55A3E7CC.50703@redhat.com> I've just received this from OSCON - we will have a room for an RDO BOF on one of the evenings of the conference. Of course, the OpenStack Foundation birthday party is on Wednesday, so if they give us a Wednesday slot it'll be difficult. I've requested that we NOT be scheduled on Wednesday. If you will beat OSCON, please let me know, so that I can have some idea of what kind of turnout we might have. Thanks. --Rich -------- Forwarded Message -------- Subject: BoF proposal accepted for OSCON 2015 Date: Mon, 13 Jul 2015 16:27:37 +0000 From: Audra Montenegro To: Rich Bowen (To respond to this message, use the web page link at the bottom.) We are pleased to accept the following proposal for OSCON 2015. * RDO: Community OpenStack Packaging Please confirm that you have received this acceptance and can deliver this BoF presentation. You can do this by /clicking the link at the bottom of this email/. BoFs will be held on the evenings of Monday July 20, Wednesday July 22, and Thursday July 23. They are an hour each, and will be held at the following times: * 7:00pm - 8:00pm * 8:00pm - 9:00pm * 9:00pm - 10:00pm We will email you with your BoF room and time as soon as you confirm your acceptance. To send us your response, please click on this link: http://www.oscon.com/open-source-2015/user/request/resp/f1e241bedd67a27b67e0191c7693a886 Thank you, Audra Montenegro ------------------------------------------------------------------------ OSCON 2015 -- http://oscon.com Portland, OR -- July 20 - July 24, 2015 17th Annual O'Reilly Open Source Convention From rdo-info at redhat.com Mon Jul 13 17:36:59 2015 From: rdo-info at redhat.com (RDO Forum) Date: Mon, 13 Jul 2015 17:36:59 +0000 Subject: [Rdo-list] [RDO] RDO blog roundup, week of July 13, 2015 Message-ID: <0000014e887dc10f-2d307669-3cee-4a02-b564-86768f55a7f2-000000@email.amazonses.com> rbowen started a discussion. RDO blog roundup, week of July 13, 2015 --- Follow the link below to check it out: https://www.rdoproject.org/forum/discussion/1025/rdo-blog-roundup-week-of-july-13-2015 Have a great day! From stdake at cisco.com Tue Jul 14 04:11:05 2015 From: stdake at cisco.com (Steven Dake (stdake)) Date: Tue, 14 Jul 2015 04:11:05 +0000 Subject: [Rdo-list] Permission denied accessing delorean repo Message-ID: Please fix: Open a web page to: http://trunk.rdoproject.org/centos70/current/delorean.repo Receive permission denied errors. Regards -steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From javier.pena at redhat.com Tue Jul 14 09:00:19 2015 From: javier.pena at redhat.com (Javier Pena) Date: Tue, 14 Jul 2015 05:00:19 -0400 (EDT) Subject: [Rdo-list] Permission denied accessing delorean repo In-Reply-To: References: Message-ID: <1340152101.35853571.1436864419238.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Please fix: > Open a web page to: > http://trunk.rdoproject.org/centos70/current/delorean.repo > Receive permission denied errors. Hi Steven, It is fixed now. Sorry for the inconveniences. Regards, Javier > Regards > -steve > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > To unsubscribe: rdo-list-unsubscribe at redhat.com From dtantsur at redhat.com Tue Jul 14 11:07:40 2015 From: dtantsur at redhat.com (Dmitry Tantsur) Date: Tue, 14 Jul 2015 13:07:40 +0200 Subject: [Rdo-list] [Package Review] 2 new packages for ironic-inspector (former ironic-discoverd) Message-ID: <55A4ED7C.8040209@redhat.com> Hi everyone! Could you please review 2 new packages that are going to eventually replace older openstack-ironic-discoverd? https://bugzilla.redhat.com/show_bug.cgi?id=1242886 https://bugzilla.redhat.com/show_bug.cgi?id=1242896 Also previously discoverd/inspector packaging were kind of independent of the remaining RDO. What should I do this time to sync efforts? Cheers, Dmitry From rbowen at redhat.com Tue Jul 14 14:01:42 2015 From: rbowen at redhat.com (Rich Bowen) Date: Tue, 14 Jul 2015 10:01:42 -0400 Subject: [Rdo-list] Fwd: [openstack-community] July 15 Deadline Call for Speakers - OpenStack Summit Tokyo In-Reply-To: <5201C31C-E47C-42AF-BE19-7CB9E1334352@openstack.org> References: <5201C31C-E47C-42AF-BE19-7CB9E1334352@openstack.org> Message-ID: <55A51646.2000108@redhat.com> Remember, folks, the CFP for OpenStack Summit Tokyo closes TOMORROW! -------- Forwarded Message -------- Subject: [openstack-community] July 15 Deadline Call for Speakers - OpenStack Summit Tokyo Date: Mon, 6 Jul 2015 12:06:48 -0500 From: Kendall Waters To: Community at lists.openstack.org Hi everyone, *Next Wednesday, July 15 at 11:59pm PDT *is the deadline to submit a talk for the upcoming OpenStack Summit taking place in Tokyo, October 27-30. Hurry and submit a talk now! *Submit your speaking session proposals **HERE* *!**//* Get advice and tips on creating a successful talk for the Tokyo Summit in this webinar held by the Women of OpenStack.*//* */ /* The visa application process for the OpenStack Summit Tokyo is different than previous Summits. Please review this information to see if you require a visa, the documents you need, as well as upcoming deadlines. All Tokyo Summit details including hotel room blocks, will soon be made available at OpenStack.org/summit . Please continue to check back for updates! If you are a contributor to OpenStack and need financial assistance in order to travel to Tokyo to attend the Summit - you can apply for a grant through the Travel Support Program .*//* If you have any questions, email summit at openstack.org . We look forward to seeing you in Tokyo! Cheers, The OpenStack Summit team -------------- next part -------------- _______________________________________________ Community mailing list Community at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/community From cems at ebi.ac.uk Wed Jul 15 07:58:45 2015 From: cems at ebi.ac.uk (Charles Short) Date: Wed, 15 Jul 2015 08:58:45 +0100 Subject: [Rdo-list] Manila configuration Kilo In-Reply-To: <559BF30C.30205@ebi.ac.uk> References: <559A85A0.3070604@ebi.ac.uk> <559A8CED.90704@ebi.ac.uk> <559BF30C.30205@ebi.ac.uk> Message-ID: <55A612B5.8000307@ebi.ac.uk> Hi, Just an update. As nobody here seems to know the answer to this I have asked NetApp the same question as they clearly are an early adopter of Manila and will understand how it works. I will post back with any answers I get. On 07/07/2015 16:41, Charles Short wrote: > Hi, > > I have managed to get our storage team here to give me access to a > NetApp. > > So I started reading this in detail - > > http://netapp.github.io/openstack-deploy-ops-guide/kilo/content/section_manila-key-concepts.html > > > and it became quickly apparent that there appears to be no mention of > a particular functionality we may need.... > > To elaborate - > > We have existing NFS exports containing files that we would like to > make available to instances directly with Manila. > > All the documentation I have read both from NetApp and Openstack > concentrates on creating new Manila shares, in NetApp speak this means > the NetApp Manila backend acting on an API call to create a new > FlexVol (Manila share) on the NetApp NFS filer. > > So how do you import existing FlexVols (NFS exports) into Manila? > > I looks briefly at the code and only came up with this Class that > looked promising (but equally may be a red herring)- > >> > grep -ir -B 1 -A5 "existing" > /usr/lib/python2.7/site-packages/manila/api/contrib/share_manage.py > > class Share_manage(extensions.ExtensionDescriptor): > """Allows existing share to be 'managed' by Manila.""" > > name = 'ShareManage' > alias = 'os-share-manage' > updated = '2015-02-17T00:00:00+00:00' > >> > > Am I missing something here (which is entirely possible) or does the > API not yet expose this functionality? > > Thanks > > > > > > On 06/07/2015 15:13, Charles Short wrote: >> Hi, >> >> Thank you for the quick reply. >> >> That sounds useful for testing general Manila functionality. >> >> In an ideal world I would like the backend I use to support a >> multi-tenacy segmented network, this one does not - >> >> "The driver does not support network segmented multi-tenancy model, >> but instead works over a flat network, where the tenants share a >> network" >> >> I am using vxlan in the tenant network, and so would like to create a >> Manila share network with a vxlan segmentation id. >> >> Is there another backend that would support this, or am I bound to >> NetApp for this sort of support? >> >> Thanks >> >> >> On 06/07/2015 14:57, Ha?kel wrote: >>> 2015-07-06 15:41 GMT+02:00 Charles Short : >>>> Hi, >>>> >>>> I have installed the latest RDO Kilo release with two compute nodes >>>> and one >>>> controller. This all works. >>>> >>>> I have an external NFS Linux server that currently provides NFS for >>>> Cinder. >>>> >>>> I want to provide another NFS export from the same server directly >>>> to an >>>> instance with Manila. I can't seem to find any guidance on how to >>>> configure >>>> a backend in the manila.conf file for this purpose. I need to know >>>> how I >>>> configure the export server ip, path etc. The only example I can >>>> find online >>>> is how to configure a backend for NetApp. >>>> >>>> http://netapp.github.io/openstack-deploy-ops-guide/kilo/content/manila.examples.manila_conf.single_svm.html >>>> >>>> >>>> I need a backend for a generic Linux NFS server >>>> >>> You may use the glusterfs backend >>> http://docs.openstack.org/developer/manila/devref/glusterfs_driver.html >>> >>> Packstack doesn't configure it yet (though puppet-manila has already >>> glusterfs support) >>> >>> H. >>> >>>> Thanks >>>> >>>> _______________________________________________ >>>> Rdo-list mailing list >>>> Rdo-list at redhat.com >>>> https://www.redhat.com/mailman/listinfo/rdo-list >>>> >>>> To unsubscribe: rdo-list-unsubscribe at redhat.com >> >> _______________________________________________ >> Rdo-list mailing list >> Rdo-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rdo-list >> >> To unsubscribe: rdo-list-unsubscribe at redhat.com > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com From ihrachys at redhat.com Wed Jul 15 08:06:32 2015 From: ihrachys at redhat.com (Ihar Hrachyshka) Date: Wed, 15 Jul 2015 10:06:32 +0200 Subject: [Rdo-list] neutron packages for review Message-ID: <55A61488.8040703@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi all, I have three Fedora reviews pending for a month already, for *aas repos: - - vpnaas: https://bugzilla.redhat.com/show_bug.cgi?id=1228106 - - fwaas: https://bugzilla.redhat.com/show_bug.cgi?id=1228118 - - lbaas: https://bugzilla.redhat.com/show_bug.cgi?id=1228115 I am not the one who supports the idea that we should maintain those packages in Fedora, but since we insist it's part of the process, I wonder whether someone tracks reviews actively. Ihar -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVphSIAAoJEC5aWaUY1u57/y4H/iH68fwjmmpS+NGsbJQNcA2w Tdz4LthDLnT+93HucHHr2ZsXdcQ7tWeCn89C3MzZBtfjCvNCCm3VEv7JhITusXyW 9dtnvC71yHgnKDfUAlYxoGIa9faARJO1oY2S/e8qgWBgfoBzjpRQ0TdKMi/9HVoH DjWI0QgJ4SV8isSnGHosajp6sjv3/zW6BU2x6WB4AnMhKSP2/lrftwErFLfkqOsl Gf9+R9W4UvfOAgRFVXW3QsEwE66UpC84sU2qYuQYqX7A3IWOc5KjW02bmChIo6MM PzxDNtynf7HQJs//2KSOJONY1fo9BYE1h1twiU3YGyG7CT7hzlm/pwccOTCV+Z4= =8W4W -----END PGP SIGNATURE----- From ihrachys at redhat.com Wed Jul 15 08:23:50 2015 From: ihrachys at redhat.com (Ihar Hrachyshka) Date: Wed, 15 Jul 2015 10:23:50 +0200 Subject: [Rdo-list] Fwd: Re: Octavia Packaging - spec review needed In-Reply-To: <559BA642.9010506@redhat.com> References: <559BA642.9010506@redhat.com> Message-ID: <55A61896.5060905@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi all, this email was sent to the author of the openstack-octavia package, but now I think I should have shared it with broader community, since it highlights some issues in our new packages process. As you will see below, there are a lot of issues in the package that we happily allowed in Delorean. I think those could be easily spotted by anyone who would look into the contents of proposed repo. I suspect we just blindly allowed it in. This once more time highlights we need our own strict review process in Delorean, that would spot those issues before we get official Delorean packages built. Postponing it till Fedora review (if it's even perceived by authors of new packages, which I'm not really sure they do) is wrong. And after we get our own Delorean review process, we should consider the need of Fedora reviews too. ;) === Issues I identified in openstack-octavia package without even running it : - - amphora agent reads /etc/neutron/conf.d/octavia-api... And it logs into octavia-api.log??? And why is octavia-dist.conf located in /usr/share/neutron?.. - - Can we have log file to be api.log instead of octavia-api.log? It's located under /var/log/octavia/, so there is no big reason to repeat it again in the file name? - - octavia-dist.conf: do we really need most of those conf values? like verbose = True? notification_driver - does it even have reasonable value?.. etc. etc. We should walk thru each entry there and determine whether it's a must to have it, or whether it's a reasonable default. - - octavia-health-manager.service: it reads /usr/share/octavia/octavia-health-manager. I don't think it's even created, and it's probably not needed at all; - - in .spec file, I don't see where conf.d files are created. - - octavia-housekeeping.service: why does it refer to health manager??? - - for all .service files, have we checked that all declarative values we use are reasonable? NotifyAccess=all? KillMode=process? - - there is no need to have 'Epoch: 1' there since we haven't packaged anything with 201x.* versions for octavia before. - - "Summary: OpenStack LBaaSv2 Service" What's the difference from LBaaSv2 service plugin then? - - I think Group: is now not needed. - - what do you use "Requires: openstack-utils" for? Not sure it's needed. - - I assume requirements are all as per in upstream... - - I think the service for amphora agent should have octavia- in its name (same as its package). Ihar -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVphiWAAoJEC5aWaUY1u5799MIAL073tmQ9/PLWqakYsiKdrdm oxWZwT027foztwFM3E2J775UC9CC5Efj/PuxLK1hr/AjcHXSfUijOjVcntIZcLHe 8g4KtPVG3tbzCFg3dmrr4oy2iXakvi/Wy4sjkJV8fjbLM/tCVquuGinHTtv5QgNo A0AWShinu7ap5hYPGp8DsC+NdjF4BGuPSnu7OxAeT26DC2gJAQ3D9Ud1Fpnhz81s lVcvJ2ajiA/545/NDdqaE/b1LBxJRsXGk+OXaSlWHqNzdTAPJJFXAVQS3nxD7vmu PA8/zQ6D95tP9Fd4pqnNq3VZaXqQliBmtGGUCD658AoNWdfyFl96s4C/aoXVCzw= =1QmH -----END PGP SIGNATURE----- From apevec at gmail.com Wed Jul 15 08:41:24 2015 From: apevec at gmail.com (Alan Pevec) Date: Wed, 15 Jul 2015 10:41:24 +0200 Subject: [Rdo-list] neutron packages for review In-Reply-To: <55A61488.8040703@redhat.com> References: <55A61488.8040703@redhat.com> Message-ID: > I have three Fedora reviews pending for a month already, for *aas repos: > > - - vpnaas: https://bugzilla.redhat.com/show_bug.cgi?id=1228106 > - - fwaas: https://bugzilla.redhat.com/show_bug.cgi?id=1228118 > - - lbaas: https://bugzilla.redhat.com/show_bug.cgi?id=1228115 Those are shame on me category :( I've fedora-review results sitting on my laptop for weeks, I'll get them wrapped up today. Cheers, Alan From cems at ebi.ac.uk Wed Jul 15 11:02:01 2015 From: cems at ebi.ac.uk (Charles Short) Date: Wed, 15 Jul 2015 12:02:01 +0100 Subject: [Rdo-list] Manila configuration Kilo In-Reply-To: <55A612B5.8000307@ebi.ac.uk> References: <559A85A0.3070604@ebi.ac.uk> <559A8CED.90704@ebi.ac.uk> <559BF30C.30205@ebi.ac.uk> <55A612B5.8000307@ebi.ac.uk> Message-ID: <55A63DA9.5010201@ebi.ac.uk> Hi, As promised an answer from NetApp - "This functionality is called Manila manage/unmanage. It is targeted for Liberty Milestone 2 and not yet available. https://blueprints.launchpad.net/manila/+spec/netapp-cdot-driver-manage-unmanage-share Currently, existing files would need to be copied over from an existing share to a newly created Manila managed share." HTH On 15/07/2015 08:58, Charles Short wrote: > Hi, > > Just an update. As nobody here seems to know the answer to this I > have asked NetApp the same question as they clearly are an early > adopter of Manila and will understand how it works. > > I will post back with any answers I get. > > > > > > On 07/07/2015 16:41, Charles Short wrote: >> Hi, >> >> I have managed to get our storage team here to give me access to a >> NetApp. >> >> So I started reading this in detail - >> >> http://netapp.github.io/openstack-deploy-ops-guide/kilo/content/section_manila-key-concepts.html >> >> >> and it became quickly apparent that there appears to be no mention of >> a particular functionality we may need.... >> >> To elaborate - >> >> We have existing NFS exports containing files that we would like to >> make available to instances directly with Manila. >> >> All the documentation I have read both from NetApp and Openstack >> concentrates on creating new Manila shares, in NetApp speak this >> means the NetApp Manila backend acting on an API call to create a new >> FlexVol (Manila share) on the NetApp NFS filer. >> >> So how do you import existing FlexVols (NFS exports) into Manila? >> >> I looks briefly at the code and only came up with this Class that >> looked promising (but equally may be a red herring)- >> >> >> grep -ir -B 1 -A5 "existing" >> /usr/lib/python2.7/site-packages/manila/api/contrib/share_manage.py >> >> class Share_manage(extensions.ExtensionDescriptor): >> """Allows existing share to be 'managed' by Manila.""" >> >> name = 'ShareManage' >> alias = 'os-share-manage' >> updated = '2015-02-17T00:00:00+00:00' >> >> >> >> Am I missing something here (which is entirely possible) or does the >> API not yet expose this functionality? >> >> Thanks >> >> >> >> >> >> On 06/07/2015 15:13, Charles Short wrote: >>> Hi, >>> >>> Thank you for the quick reply. >>> >>> That sounds useful for testing general Manila functionality. >>> >>> In an ideal world I would like the backend I use to support a >>> multi-tenacy segmented network, this one does not - >>> >>> "The driver does not support network segmented multi-tenancy model, >>> but instead works over a flat network, where the tenants share a >>> network" >>> >>> I am using vxlan in the tenant network, and so would like to create >>> a Manila share network with a vxlan segmentation id. >>> >>> Is there another backend that would support this, or am I bound to >>> NetApp for this sort of support? >>> >>> Thanks >>> >>> >>> On 06/07/2015 14:57, Ha?kel wrote: >>>> 2015-07-06 15:41 GMT+02:00 Charles Short : >>>>> Hi, >>>>> >>>>> I have installed the latest RDO Kilo release with two compute >>>>> nodes and one >>>>> controller. This all works. >>>>> >>>>> I have an external NFS Linux server that currently provides NFS >>>>> for Cinder. >>>>> >>>>> I want to provide another NFS export from the same server directly >>>>> to an >>>>> instance with Manila. I can't seem to find any guidance on how to >>>>> configure >>>>> a backend in the manila.conf file for this purpose. I need to know >>>>> how I >>>>> configure the export server ip, path etc. The only example I can >>>>> find online >>>>> is how to configure a backend for NetApp. >>>>> >>>>> http://netapp.github.io/openstack-deploy-ops-guide/kilo/content/manila.examples.manila_conf.single_svm.html >>>>> >>>>> >>>>> I need a backend for a generic Linux NFS server >>>>> >>>> You may use the glusterfs backend >>>> http://docs.openstack.org/developer/manila/devref/glusterfs_driver.html >>>> >>>> >>>> Packstack doesn't configure it yet (though puppet-manila has already >>>> glusterfs support) >>>> >>>> H. >>>> >>>>> Thanks >>>>> >>>>> _______________________________________________ >>>>> Rdo-list mailing list >>>>> Rdo-list at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/rdo-list >>>>> >>>>> To unsubscribe: rdo-list-unsubscribe at redhat.com >>> >>> _______________________________________________ >>> Rdo-list mailing list >>> Rdo-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/rdo-list >>> >>> To unsubscribe: rdo-list-unsubscribe at redhat.com >> >> _______________________________________________ >> Rdo-list mailing list >> Rdo-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rdo-list >> >> To unsubscribe: rdo-list-unsubscribe at redhat.com > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com From mrunge at redhat.com Wed Jul 15 12:23:15 2015 From: mrunge at redhat.com (Matthias Runge) Date: Wed, 15 Jul 2015 14:23:15 +0200 Subject: [Rdo-list] delorean ci not working (permission denied) Message-ID: <55A650B3.4090601@redhat.com> hello, I just stumbled upon a missing dep in python-oslo-utils causing horizon not to build any more.[1] Unfortunately, jenkins fails with: RAN: '/usr/bin/docker run --env DELOREAN_DEV=1 -t --volume=/home/fedora/workspace/delorean-ci/delorean/data:/data --volume=/home/fedora/workspace/delorean-ci/delorean/scripts:/scripts --name builder-fedora delorean/fedora /scripts/build_rpm_wrapper.sh python-oslo-utils /data/repos/6c/45/6c4509587a9494a015c4b482429ae3268d33864d_dev 1000 1000' STDOUT: /bin/bash: /scripts/build_rpm_wrapper.sh: Permission denied STDERR: Does anybody has a clue or an insight, how to fix this? Matthias [1] https://review.gerrithub.io/#/c/239941/ From hguemar at fedoraproject.org Wed Jul 15 13:13:47 2015 From: hguemar at fedoraproject.org (=?UTF-8?Q?Ha=C3=AFkel?=) Date: Wed, 15 Jul 2015 15:13:47 +0200 Subject: [Rdo-list] delorean ci not working (permission denied) In-Reply-To: <55A650B3.4090601@redhat.com> References: <55A650B3.4090601@redhat.com> Message-ID: Does not look like from the OS1 instance :/ I have no access to the older one. H. -------------- next part -------------- An HTML attachment was scrubbed... URL: From derekh at redhat.com Wed Jul 15 13:54:33 2015 From: derekh at redhat.com (Derek Higgins) Date: Wed, 15 Jul 2015 14:54:33 +0100 Subject: [Rdo-list] delorean ci not working (permission denied) In-Reply-To: <55A650B3.4090601@redhat.com> References: <55A650B3.4090601@redhat.com> Message-ID: <55A66619.8080103@redhat.com> On 15/07/15 13:23, Matthias Runge wrote: > hello, > > I just stumbled upon a missing dep in python-oslo-utils causing horizon > not to build any more.[1] > > > Unfortunately, jenkins fails with: > > RAN: '/usr/bin/docker run --env DELOREAN_DEV=1 -t > --volume=/home/fedora/workspace/delorean-ci/delorean/data:/data > --volume=/home/fedora/workspace/delorean-ci/delorean/scripts:/scripts > --name builder-fedora delorean/fedora /scripts/build_rpm_wrapper.sh > python-oslo-utils > /data/repos/6c/45/6c4509587a9494a015c4b482429ae3268d33864d_dev 1000 1000' > > STDOUT: > /bin/bash: /scripts/build_rpm_wrapper.sh: Permission denied The instance running the CI was rebooted yesterday (for reasons unknown) which flipped selinux to enforcing, I've switched it back to permissive and re-triggered your job, it now fails CI for some other probably legitimate reason. I am pretty sure I know what needs to change so it runs with enforcing, so I'll work on a patch to get us back to working with enforcing. > > > STDERR: > > > > Does anybody has a clue or an insight, how to fix this? > > Matthias > > > > [1] https://review.gerrithub.io/#/c/239941/ > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com From derekh at redhat.com Wed Jul 15 13:55:54 2015 From: derekh at redhat.com (Derek Higgins) Date: Wed, 15 Jul 2015 14:55:54 +0100 Subject: [Rdo-list] delorean ci not working (permission denied) In-Reply-To: References: <55A650B3.4090601@redhat.com> Message-ID: <55A6666A.20400@redhat.com> On 15/07/15 14:13, Ha?kel wrote: > Does not look like from the OS1 instance :/ > I have no access to the older one. This was not one of the delorean servers its a instance that acts as a jenkins slave to run delorean CI on. Send me on a key and I'll add it to the server. Thanks, Derek > > H. > > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com > From apevec at gmail.com Wed Jul 15 15:43:37 2015 From: apevec at gmail.com (Alan Pevec) Date: Wed, 15 Jul 2015 17:43:37 +0200 Subject: [Rdo-list] [meeting] RDO packaging meeting minutes (2015-07-15) Message-ID: ======================================== #rdo: RDO packaging meeting (2015-07-15) ======================================== Meeting started by apevec at 15:02:32 UTC. The full logs are available at http://meetbot.fedoraproject.org/rdo/2015-07-15/rdo.2015-07-15-15.02.log.html . Meeting summary --------------- * roll call (apevec, 15:02:44) * liberty reviews (apevec, 15:04:35) * ACTION: number80 to create tracker bug for openstack reviews (apevec, 15:06:10) * f23 has branched so Liberty work, can be imported to Fedora master (apevec, 15:09:46) * make a decision on https://trello.com/c/wzdl1IlZ/52-openstack-in-fedora (apevec, 15:11:11) * AGREED: F24 will not have openstack-* (apevec, 15:19:04) * ACTION: retire openstack-* in Rawhide before EOY 2015 (apevec, 15:19:33) * rpm packaging as an upstream project (apevec, 15:20:28) * rpm-packaging upstream meetings https://etherpad.openstack.org/p/openstack-rpm-packaging (apevec, 15:21:10) * ACTION: number80 push an example of organization for rdo packaging (number80, 15:25:52) * open floor (apevec, 15:29:47) Meeting ended at 15:34:49 UTC. Action Items ------------ * number80 to create tracker bug for openstack reviews * retire openstack-* in Rawhide before EOY 2015 * number80 push an example of organization for rdo packaging Action Items, by person ----------------------- * number80 * number80 to create tracker bug for openstack reviews * number80 push an example of organization for rdo packaging * **UNASSIGNED** * retire openstack-* in Rawhide before EOY 2015 People Present (lines said) --------------------------- * apevec (78) * number80 (26) * mrunge (7) * alphacc (6) * rbowen (6) * zodbot (4) * derekh (3) * ryansb (1) * xaeth (1) * chandankumar (1) * jschlueter (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot From ichavero at redhat.com Wed Jul 15 17:35:18 2015 From: ichavero at redhat.com (Ivan Chavero) Date: Wed, 15 Jul 2015 13:35:18 -0400 (EDT) Subject: [Rdo-list] Manually Install RDO packages In-Reply-To: References: Message-ID: <663019033.33516691.1436981718187.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "sad man" > To: rdo-list at redhat.com > Sent: Thursday, July 9, 2015 6:37:35 PM > Subject: [Rdo-list] Manually Install RDO packages > > Hi, as I've mentioned that I am working on a RDO-Fedora remix for my GSoC. I > have a problem regarding PackStack "yum". > > My idea is to install RDO packages during OS installation (when other system > packages are being installed) and then PackStack at first boot. (I am > writing an Anaconda add-on to do so). > > But the problem is that even if all packages are already installed packstack > still tries to run: > > yum install -y puppet hiera .... > > which results in an error on a system that is offline (I use a VM with no > internet connectivity so that install is totally offline). > > ?Is there a solution to this?? > > PS: PackStack works if I place RDO rpms in yum cache and direct repo url to > this cache folder. I think one solution is to add the RDO packages to the installation, another solution would be to make internet connection mandatory which is not that crazy since this is not a general purpouse remix it's a cloud computing remix. > > -- > Cheers, > > Asadullah Hussain > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com From tom at buskey.name Wed Jul 15 19:05:41 2015 From: tom at buskey.name (Tom Buskey) Date: Wed, 15 Jul 2015 15:05:41 -0400 Subject: [Rdo-list] Manually Install RDO packages In-Reply-To: References: Message-ID: I had to do an internetless install but still wanted to use yum. Roughly: - 1st, I installed a minimal OS - set yum to cache everything. - install packstack, etc w/ internet access. - copy the yum cache off - 2nd, install a new minimal OS - disable existing yum repos - use the yum cache copy to create a repo - Use yum repo priorities to make your local repo 1st. - Install all the repos from before - disable all the repos except yours - Use yum priorities to make all the other repos lower than yours - install packstack, etc. Yum will go to your repo 1st. - disable all repos except your local again Packstack installs some repos. It will also enable repos that you have disabled. They's why the priorities are needed. If you connect up the the internet and there are newer versions in the packstack enabled repos, they will be found and installed during packstack. You might need to go back & recreate your local repo in this case. On Thu, Jul 9, 2015 at 8:37 PM, sad man wrote: > Hi, as I've mentioned that I am working on a RDO-Fedora remix for my GSoC. > I have a problem regarding PackStack "yum". > > My idea is to install RDO packages during OS installation (when other > system packages are being installed) and then PackStack at first boot. (I > am writing an Anaconda add-on to do so). > > But the problem is that even if all packages are already installed > packstack still tries to run: > > yum install -y puppet hiera .... > > which results in an error on a system that is offline (I use a VM with no > internet connectivity so that install is totally offline). > > ?Is there a solution to this?? > > PS: PackStack works if I place RDO rpms in yum cache and direct repo url > to this cache folder. > > -- > Cheers, > > Asadullah Hussain > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ihrachys at redhat.com Wed Jul 15 20:37:36 2015 From: ihrachys at redhat.com (Ihar Hrachyshka) Date: Wed, 15 Jul 2015 22:37:36 +0200 Subject: [Rdo-list] [meeting] RDO packaging meeting minutes (2015-07-15) In-Reply-To: References: Message-ID: <55A6C490.2070207@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 07/15/2015 05:43 PM, Alan Pevec wrote: > * make a decision on > https://trello.com/c/wzdl1IlZ/52-openstack-in-fedora (apevec, > 15:11:11) * AGREED: F24 will not have openstack-* (apevec, > 15:19:04) * ACTION: retire openstack-* in Rawhide before EOY 2015 > (apevec, 15:19:33) > I want to thank anyone who seriously considered dropping openstack-* from Fedora dist-git completely. I believe replacing point release based stable RDO repos with Delorean stable repos is the right call too since it will make the process more straight for new contributors, and there won't be any questions on why a package added to Delorean is not available in RDO repos. Well done, and I look forward to see it happen. Ihar -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVpsSOAAoJEC5aWaUY1u57nMgH/jptFdtyb3k5Q70UWwCZNUcZ rEdRmNXCYTelmfdJmx1GKzmv+AV2jH5OVtfcCAmhUAYm58Ett8nMQ3+s0bF9eOHN abXB5kaGO1kNEZErfTqgZBCcg7Sa/DnXlf4wtkJhxH6cerd7nGmMLgx/FoI6qE0a nWB7Ia6Pu7AcuFn9FsLB9O8tU/xdFUxVlVVf4v7GqF1stbzprJmW8oX4NhelGzD+ 2UYWLCJVSnA/DoLdRf3S57pfzShW+a2nyNhV7is4gZj68JJTzZAMBpXDRgw/JQ1m KHGWEnixB9EBcdy0euQeghZTaW8saKkXZOzF7G4BGwT0qVTmQ0vwmvqmAKfwmVw= =aHdq -----END PGP SIGNATURE----- From hguemar at fedoraproject.org Thu Jul 16 12:58:27 2015 From: hguemar at fedoraproject.org (=?UTF-8?Q?Ha=C3=AFkel?=) Date: Thu, 16 Jul 2015 14:58:27 +0200 Subject: [Rdo-list] [meeting] RDO packaging meeting minutes (2015-07-15) In-Reply-To: <55A6C490.2070207@redhat.com> References: <55A6C490.2070207@redhat.com> Message-ID: 2015-07-15 22:37 GMT+02:00 Ihar Hrachyshka : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 07/15/2015 05:43 PM, Alan Pevec wrote: > > * make a decision on > > https://trello.com/c/wzdl1IlZ/52-openstack-in-fedora (apevec, > > 15:11:11) * AGREED: F24 will not have openstack-* (apevec, > > 15:19:04) * ACTION: retire openstack-* in Rawhide before EOY 2015 > > (apevec, 15:19:33) > > > > I want to thank anyone who seriously considered dropping openstack-* > from Fedora dist-git completely. > > I believe replacing point release based stable RDO repos with Delorean > stable repos is the right call too since it will make the process more > straight for new contributors, and there won't be any questions on why > a package added to Delorean is not available in RDO repos. > > We're still packaging python dependencies, oslo and *clients* in Fedora repositories. And we'll still do package reviews, though it's likely to be a simplified and more interactive process (bugzilla sucks for package reviews). I still believe that delorean builds are not suitable for production deployments. As most of production is done on RHEL/CentOS, it makes sense to focus our efforts on these platforms and switch to delorean-only builds for Fedora. Fedora's current model does not play well with OpenStack release schedule. If they happen to allow layered products, it may change but it's unlikely to happen any sooner. This is the best way to provide high-quality support on Fedora, as we'll keep curating delorean builds and stand with every commit done in stable branches and a shorter delivery time. H. > Well done, and I look forward to see it happen. > > Ihar > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQEcBAEBCAAGBQJVpsSOAAoJEC5aWaUY1u57nMgH/jptFdtyb3k5Q70UWwCZNUcZ > rEdRmNXCYTelmfdJmx1GKzmv+AV2jH5OVtfcCAmhUAYm58Ett8nMQ3+s0bF9eOHN > abXB5kaGO1kNEZErfTqgZBCcg7Sa/DnXlf4wtkJhxH6cerd7nGmMLgx/FoI6qE0a > nWB7Ia6Pu7AcuFn9FsLB9O8tU/xdFUxVlVVf4v7GqF1stbzprJmW8oX4NhelGzD+ > 2UYWLCJVSnA/DoLdRf3S57pfzShW+a2nyNhV7is4gZj68JJTzZAMBpXDRgw/JQ1m > KHGWEnixB9EBcdy0euQeghZTaW8saKkXZOzF7G4BGwT0qVTmQ0vwmvqmAKfwmVw= > =aHdq > -----END PGP SIGNATURE----- > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ihrachys at redhat.com Thu Jul 16 14:06:53 2015 From: ihrachys at redhat.com (Ihar Hrachyshka) Date: Thu, 16 Jul 2015 16:06:53 +0200 Subject: [Rdo-list] [meeting] RDO packaging meeting minutes (2015-07-15) In-Reply-To: References: <55A6C490.2070207@redhat.com> Message-ID: <55A7BA7D.5030101@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 07/16/2015 02:58 PM, Ha?kel wrote: >> We're still packaging python dependencies, oslo and *clients* in >> Fedora repositories. Sure. Meaning, we are still enforcing everyone who contributes e.g. a neutron plugin to go thru Fedora review process and then maintain the package there. It's not optimal. > >> And we'll still do package reviews, though it's likely to be a >> simplified and more interactive process (bugzilla sucks for >> package reviews). YES! > >> I still believe that delorean builds are not suitable for >> production deployments. Upstream does not agree with you: they are going to drop point releases since Mitaka. Obviously, there should be some kind of validation to add assurance it's not broken. >> As most of production is done on RHEL/CentOS, it makes sense to >> focus our efforts on these platforms and switch to delorean-only >> builds for Fedora. Fedora's current model does not play well with >> OpenStack release schedule. If they happen to allow layered >> products, it may change but it's unlikely to happen any sooner. > >> This is the best way to provide high-quality support on Fedora, >> as we'll keep curating delorean builds and stand with every >> commit done in stable branches and a shorter delivery time. > All good. One point that I don't see addressed by you is ease of contribution. It's my belief that enforcing contributors to pass new package review process twice is hostile to new comers (and oldies who need to explain that weirdness to the former). Ihar -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVp7p6AAoJEC5aWaUY1u57ZJYIAKjCmfr/1mOcgELyE7QKfwd0 VDClOlFEW9f9LIxTDKc6rWP2FAZTIvjlq9J7J5J/MLlpKLfQOZ/dYUrefy2mtgsp fBnTkR6Lp0yUfyH/xhMMBe2VAbM9KIwarEUgZgiqNbgonOYjZolGtFPpUwQRU1v9 LU4GVgDYsY1zUrG8TUQcZ/9nXkVSAtqJpl9y4rc+SOiKI9aWe9veIq+/vSbLoj3m /oNAfAL0OH9rJPn6RQEUWvqGuzLqOiOX2wyaRq254J/6pBuow1Z9Tj5Nu3oHtNEG oILIBo980MadmRFCxMIRx77neSxloD8/Yu75kSiU0S74wNGEMEBobV2UkQhCPzc= =h6Tl -----END PGP SIGNATURE----- From ross.annetts at digitalpacific.com.au Sun Jul 19 13:04:56 2015 From: ross.annetts at digitalpacific.com.au (Ross Annetts) Date: Sun, 19 Jul 2015 23:04:56 +1000 Subject: [Rdo-list] keystone v3 api policy.json Message-ID: <55ABA078.5060001@digitalpacific.com.au> Hi, Has anyone got a working keystone v3 api with Horizon? I have created a cloud_admin user as part of admin_domain, with project admin_project and set role as admin on both domain and project. I then created /etc/keystone/policy.json based on: openstack-keystone-2015.1.0-1.el7.noarch /usr/share/keystone/policy.v3cloudsample.json Replacing admin_domain_id with the actual id of the admin_domain. But when logging in as the cloud_admin user and navigating the identity section: 2015-07-19 13:00:48.833 12337 WARNING keystone.common.wsgi [-] You are not authorized to perform the requested action: identity:list_domains (Disable debug mode to suppress these details.) 2015-07-19 13:00:51.297 12333 WARNING keystone.common.wsgi [-] You are not authorized to perform the requested action: identity:list_users (Disable debug mode to suppress these details.) 2015-07-19 13:00:55.062 12334 WARNING keystone.common.wsgi [-] You are not authorized to perform the requested action: identity:list_projects (Disable debug mode to suppress these details.) -- Regards, Ross Annetts From asadxflow at gmail.com Mon Jul 20 09:36:55 2015 From: asadxflow at gmail.com (sad man) Date: Mon, 20 Jul 2015 11:36:55 +0200 Subject: [Rdo-list] Adding RDO to CentOS ISO Message-ID: Hi, I am trying to add RDO packages to CentOS ISO for my GSoC project but the installer fails at "starting package installation". I would be grateful if someone can identify the error in my method. My steps (I copy contents from CentOS minimal DVD to folder "ISO"): 1. Copy all RPMs (+ dependencies) from CentOS mirror into "Packages" folder of minimal CentOS ISO. ?2. Edit "comps.xml"? from repodata folder on ISO and add my custom group "Cloud" with all the packages (there are 671 packages for Cloud, whose names I get from filelist.xml from cloud's repodata folder). I also add this group to category "minimal install". 3. Create new repo: createrepo -g /root/comps.xml -o / //Packages/ This creates a repodata folder in . 4. Create new ISO using geniso. ?I am attaching my comps.xml file. ? ?Error: The installer gets stuck at package installation and then gives an error: "error populating transaction after 10 retries, failure erlang-sd.rpm from anaconda, no more mirrors to try?" ?PS: I gather RPMs and dependencies following Tom Buskey's guidelines .? -- Cheers, Asadullah Hussain -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: comp.xml Type: text/xml Size: 780009 bytes Desc: not available URL: From asadxflow at gmail.com Mon Jul 20 10:34:03 2015 From: asadxflow at gmail.com (sad man) Date: Mon, 20 Jul 2015 12:34:03 +0200 Subject: [Rdo-list] Adding RDO to CentOS ISO In-Reply-To: References: Message-ID: Using "--update" option on existing repodata folder (from ISO) seems to work (with an error in anaconda shell i.e., rpmdb bad file descriptor). I run the following command from within /Packages folder: createrepo --update -g /root/comp.xml -o // . contains the repodata folder from DVD with old repo files. The system installs fine (all openstack rpms are installed). Still I would appreciate suggestions on doing it properly. On 20 July 2015 at 11:36, sad man wrote: > Hi, I am trying to add RDO packages to CentOS ISO for my GSoC project but > the installer fails at "starting package installation". I would be grateful > if someone can identify the error in my method. > > My steps (I copy contents from CentOS minimal DVD to folder "ISO"): > 1. Copy all RPMs (+ dependencies) from CentOS mirror > into > "Packages" folder of minimal CentOS ISO. > ?2. Edit "comps.xml"? from repodata folder on ISO and add my custom group > "Cloud" with all the packages (there are 671 packages for Cloud, whose > names I get from filelist.xml from cloud's repodata folder). I also add > this group to category "minimal install". > 3. Create new repo: > createrepo -g /root/comps.xml -o / //Packages/ > > This creates a repodata folder in . > > 4. Create new ISO using geniso. > > ?I am attaching my comps.xml file. > ? > ?Error: The installer gets stuck at package installation and then gives an > error: > "error populating transaction after 10 retries, failure erlang-sd.rpm from > anaconda, no more mirrors to try?" > > ?PS: I gather RPMs and dependencies following Tom Buskey's guidelines > .? > > -- > Cheers, > > Asadullah Hussain > -- Cheers, Asadullah Hussain -------------- next part -------------- An HTML attachment was scrubbed... URL: From hguemar at fedoraproject.org Mon Jul 20 15:00:02 2015 From: hguemar at fedoraproject.org (hguemar at fedoraproject.org) Date: Mon, 20 Jul 2015 15:00:02 +0000 (UTC) Subject: [Rdo-list] [Fedocal] Reminder meeting : RDO packaging meeting Message-ID: <20150720150002.F401260A957D@fedocal02.phx2.fedoraproject.org> Dear all, You are kindly invited to the meeting: RDO packaging meeting on 2015-07-22 from 15:00:00 to 16:00:00 UTC At rdo at irc.freenode.net The meeting will be about: RDO packaging irc meeting ([agenda](https://etherpad.openstack.org/p/RDO-Packaging)) Every week on #rdo on freenode Source: https://apps.fedoraproject.org/calendar/meeting/2017/ From pradhanparas at gmail.com Mon Jul 20 17:31:04 2015 From: pradhanparas at gmail.com (Paras pradhan) Date: Mon, 20 Jul 2015 12:31:04 -0500 Subject: [Rdo-list] [Rdo-manager] deploy error Message-ID: When I run openstack overcloud deploy I get the following error. The host and the undercloud is uptodate Centos7 Any recommendations? [stack at instack ~]$ openstack overcloud deploy --plan overcloud /usr/lib/python2.7/site-packages/novaclient/v1_1/__init__.py:30: UserWarning: Module novaclient.v1_1 is deprecated (taken as a basis for novaclient.v2). The preferable way to get client class or object you can find in novaclient.client module. warnings.warn("Module novaclient.v1_1 is deprecated (taken as a basis for " ERROR: openstack 'PlanManager' object has no attribute 'find' Thanks Paras. -------------- next part -------------- An HTML attachment was scrubbed... URL: From geertj at gmail.com Sat Jul 18 15:39:58 2015 From: geertj at gmail.com (Geert Jansen) Date: Sat, 18 Jul 2015 11:39:58 -0400 Subject: [Rdo-list] [PATCH] --plan argument to "overcloud deploy" doesn't work Message-ID: I am using the latest RDO, which defines both a --plan and a --plan-uuid option for "overcloud deploy". Using the --plan option results in an exception "PlanManager does not have .find attribute". The patch below to python-tuskarclient fixes this: --- tuskarclient/v2/plans.py.orig 2015-07-18 15:37:29.160220339 +0000 +++ tuskarclient/v2/plans.py 2015-07-18 15:20:51.886095272 +0000 @@ -36,7 +36,7 @@ """ -class PlanManager(base.BaseManager): +class PlanManager(base.ManagerWithFind): """PlanManager interacts with the Tuskar API and provides CRUD operations for the Plan type. """ Regards, Geert From brian at brianlee.org Mon Jul 20 21:42:22 2015 From: brian at brianlee.org (brian lee) Date: Mon, 20 Jul 2015 16:42:22 -0500 Subject: [Rdo-list] Kilo not working with nova networking Message-ID: Hi everyone, I just did a install of RDO Kilo with nova networking. But I can not get it to work. I followed the same pattern that I have done in the past with Icehouse. It does not seem to start the br100 interface, or my secondary network device either. Then also is not starting Cirros image, it fails saying that failed to find the compute node. Has anyone dealt with something like this before? --Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From thbeh at thbeh.com Tue Jul 21 01:18:22 2015 From: thbeh at thbeh.com (Teik Hooi Beh) Date: Tue, 21 Jul 2015 13:18:22 +1200 Subject: [Rdo-list] how to install heat-config-scripts into existing centos image Message-ID: Hi, I have built a customized centos6.6 image using packer for my requirement in OpenStack but notice that it does not work with heat SoftwareConfig and SoftwareDeploy. Investigation further, I found that I have to include heat-config heat-config-script, etc during image image build. As I am using packer instead of diskimage-builder, how can i include heat related files during the build? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruno.bompastor at cern.ch Tue Jul 21 09:52:58 2015 From: bruno.bompastor at cern.ch (Bruno Bompastor) Date: Tue, 21 Jul 2015 09:52:58 +0000 Subject: [Rdo-list] Kilo not working with nova networking In-Reply-To: References: Message-ID: <815C546A-363A-4580-9F4B-C2B1CBEFE981@cern.ch> Hi, Yes, I even opened a bug (https://bugs.launchpad.net/nova/+bug/1376596 and https://bugzilla.redhat.com/show_bug.cgi?id=1153128 ) but people don?t seem to care? Fix: http://sethanil.blogspot.ch/2014/11/openstack-nova-compute-fails-to-start.html Cheers, Bruno Bompastor. > On Jul 20, 2015, at 11:42 PM, brian lee wrote: > > Hi everyone, > > I just did a install of RDO Kilo with nova networking. But I can not get it to work. I followed the same pattern that I have done in the past with Icehouse. > > It does not seem to start the br100 interface, or my secondary network device either. Then also is not starting Cirros image, it fails saying that failed to find the compute node. > > Has anyone dealt with something like this before? > > --Brian > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5460 bytes Desc: not available URL: From whayutin at redhat.com Tue Jul 21 18:18:52 2015 From: whayutin at redhat.com (whayutin) Date: Tue, 21 Jul 2015 14:18:52 -0400 Subject: [Rdo-list] delorean may be down Message-ID: <1437502732.31384.20.camel@redhat.com> Greetings, I'm unable to access http://209.132.178.14/centos7-kilo/ Thanks! From derekh at redhat.com Tue Jul 21 18:24:04 2015 From: derekh at redhat.com (Derek Higgins) Date: Tue, 21 Jul 2015 19:24:04 +0100 Subject: [Rdo-list] delorean may be down In-Reply-To: <1437502732.31384.20.camel@redhat.com> References: <1437502732.31384.20.camel@redhat.com> Message-ID: <55AE8E44.4080000@redhat.com> On 21/07/15 19:18, whayutin wrote: > Greetings, > > I'm unable to access http://209.132.178.14/centos7-kilo/ Yup, seeing the same here $ curl http://trunk.rdoproject.org/f21/current/delorean.repo curl: (7) Failed to connect to trunk.rdoproject.org port 80: No route to host > > Thanks! > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com > From stdake at cisco.com Tue Jul 21 19:31:22 2015 From: stdake at cisco.com (Steven Dake (stdake)) Date: Tue, 21 Jul 2015 19:31:22 +0000 Subject: [Rdo-list] trunk.rdorpoject.org is down Message-ID: I get an err address unreachable. We use this to build kolla containers. Could someone please rectify this problem? Thanks -steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From aortega at redhat.com Tue Jul 21 19:58:20 2015 From: aortega at redhat.com (Alvaro Lopez Ortega) Date: Tue, 21 Jul 2015 21:58:20 +0200 Subject: [Rdo-list] delorean may be down In-Reply-To: <55AE8E44.4080000@redhat.com> References: <1437502732.31384.20.camel@redhat.com> <55AE8E44.4080000@redhat.com> Message-ID: Dan, It seems something went wrong with the reboot 5 hours ago. I don?t think there is anybody in my side who could investigate it now. Could you please give us a hand to figure what happened with the VM? Thanks in advance!! Best, Alvaro > On 21 Jul 2015, at 20:24, Derek Higgins wrote: > > On 21/07/15 19:18, whayutin wrote: >> Greetings, >> >> I'm unable to access http://209.132.178.14/centos7-kilo/ > > Yup, seeing the same here > > $ curl http://trunk.rdoproject.org/f21/current/delorean.repo > curl: (7) Failed to connect to trunk.rdoproject.org port 80: No route to host > > > >> >> Thanks! >> >> _______________________________________________ >> Rdo-list mailing list >> Rdo-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rdo-list >> >> To unsubscribe: rdo-list-unsubscribe at redhat.com >> > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com From ibravo at ltgfederal.com Tue Jul 21 20:40:11 2015 From: ibravo at ltgfederal.com (Bravo, Ignacio) Date: Tue, 21 Jul 2015 16:40:11 -0400 Subject: [Rdo-list] Install openstack in c7000 Blade servers Message-ID: Hi, Has anyone performed a production deployment into a c7000/c3000 HP enclosure? I am looking for information on how to better configure the networking piece of the servers to take advantage of the 10Gb Nics. Thanks, IB -- *Ignacio Bravo* *LTG Federal* ibravo at ltgfederal.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ihrachys at redhat.com Wed Jul 22 12:51:44 2015 From: ihrachys at redhat.com (Ihar Hrachyshka) Date: Wed, 22 Jul 2015 14:51:44 +0200 Subject: [Rdo-list] new packages needed for python-networking-vmware-nsx Message-ID: <55AF91E0.1080506@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi all, I'm working on a new package for neutron vmware NSX mechanism driver for Delorean, and here is the list of dependencies that are missing in repos used by Delorean: Error: No Package found for python-eventlet >= 0.17.4 Error: No Package found for python-fixtures >= 1.3.1 Error: No Package found for python-mock >= 1.1 Error: No Package found for python-testtools >= 1.4.0 Error: No Package found for python-tooz >= 0.16.0 I've checked some of those on fed pkgdb, and it seems most (all?) of them are not even in koji. Some of them are test only, like mock or fixtures or testtools. But for tooz and eventlet, those are runtime dependencies. Some questions: - - which repos does delorean use? - - do we have any instructions on how to get updated deps in fedora? Or are we just going to each maintainer and ask him to bump? Ihar -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVr5HWAAoJEC5aWaUY1u57noUH/1FNaKsQx4zD4qOiECA/leqD Jf6RqhBoIUh5ISOjGO4Swtxv/8qnO3Z+8rQe8rVgH4Dh5M+XppQISws9OWn4eZl3 5R4D2g9n4PpnOeyM/XVjdhojyVQfZhNhpjd0WwjM5wsUoEcTwsjaTQCg6/0oqxy5 /rwt6TcHAhnGeFNXcwqCBC8uSoH8MjsZs+vJewzFqQraL1ofk7fMQdBy455Mjyyy u+n1etJpI7Q/PDcdEHzpwkfZ6VtiAhqVR2h3HtL3/KT78EhGE/8J+lwzs4DYn7Y8 MUiTtI7U+CWvZ5cMAICsIUuAvQe3aEYBTl1caRlt3yICa8ByYK6s6u4gkrQilzw= =hxAj -----END PGP SIGNATURE----- From apevec at gmail.com Wed Jul 22 15:36:19 2015 From: apevec at gmail.com (Alan Pevec) Date: Wed, 22 Jul 2015 17:36:19 +0200 Subject: [Rdo-list] [meeting] RDO packaging meeting minutes (2015-07-22) Message-ID: ======================================== #rdo: RDO packaging meeting (2015-07-22) ======================================== Meeting started by apevec at 15:00:36 UTC. The full logs are available at http://meetbot.fedoraproject.org/rdo/2015-07-22/rdo.2015-07-22-15.00.log.html . Meeting summary --------------- * roll call (apevec, 15:00:49) * agenda at https://etherpad.openstack.org/p/RDO-Packaging (apevec, 15:00:56) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1243533 (number80, 15:03:01) * liberty reviews (apevec, 15:04:20) * ACTION: apevec start tracking package reviews more closely (apevec, 15:09:37) * various clients issues raised (apevec, 15:12:13) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1244291 (number80, 15:12:40) * please forward clients issues to hguemar if they're not processed (apevec, 15:12:54) * ACTION: chandankumar to take over RDO bz reports from larsks (apevec, 15:16:17) * open floor (apevec, 15:17:01) * LINK: https://github.com/gregswift/barbican-spec/commit/46acd1998c7bb890acecd8a5f1913bc2816b8f2d (xaeth, 15:25:33) Meeting ended at 15:30:55 UTC. Action Items ------------ * apevec start tracking package reviews more closely * chandankumar to take over RDO bz reports from larsks Action Items, by person ----------------------- * apevec * apevec start tracking package reviews more closely * chandankumar * chandankumar to take over RDO bz reports from larsks * larsks * chandankumar to take over RDO bz reports from larsks * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * apevec (52) * number80 (26) * ktdreyer (7) * elmiko (5) * zodbot (5) * chandankumar (5) * alphacc (4) * xaeth (4) * larsks (3) * jruzicka (3) * ayoung (3) * pixelbeat_ (2) * eggmaste` (1) * dtantsur (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot From aragonx at dcsnow.com Wed Jul 22 17:46:46 2015 From: aragonx at dcsnow.com (Will Yonker) Date: Wed, 22 Jul 2015 17:46:46 -0000 Subject: [Rdo-list] Juno on Fedora 22 Message-ID: <79b1f8b4612fbceb3d4e4d8dbe58a7a0.squirrel@www.dcsnow.com> Hi, I'm trying to install on Fedora 22 and ran into a few issues. My first question is if I should be trying for Juno or Kilo. I haven't been able to get Kilo working so I switched to Juno. In order to get Juno to go, I had to edit the rdo-release.repo file and point the baseurl to http://repos.fedorapeople.org/repos/openstack/openstack-juno/epel-7/. Is that the correct way to do it? I'm installing useing: packstack --allinone So, I get an error from mysql (MariaDB) that looks like: Error: Evaluation Error: Comparison of: String >= Integer, is not possible. Caused by 'A String is not comparable to a non String'. at /var/tmp/packstack/8e5b1411ef25462dad1e216ac75fb2ab/modules/mysql/manifests/params.pp:35:82 on node The file that it is point to nolonger exists so I didn't dig any further. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From bderzhavets at hotmail.com Wed Jul 22 18:21:20 2015 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Wed, 22 Jul 2015 14:21:20 -0400 Subject: [Rdo-list] Juno on Fedora 22 In-Reply-To: <79b1f8b4612fbceb3d4e4d8dbe58a7a0.squirrel@www.dcsnow.com> References: <79b1f8b4612fbceb3d4e4d8dbe58a7a0.squirrel@www.dcsnow.com> Message-ID: > Date: Wed, 22 Jul 2015 17:46:46 +0000 > From: aragonx at dcsnow.com > To: rdo-list at redhat.com > Subject: [Rdo-list] Juno on Fedora 22 > > Hi, > > I'm trying to install on Fedora 22 and ran into a few issues. My first > question is if I should be trying for Juno or Kilo. I haven't been able > to get Kilo working so I switched to Juno. In order to get Juno to go, I > had to edit the rdo-release.repo file and point the baseurl to > http://repos.fedorapeople.org/repos/openstack/openstack-juno/epel-7/. > > Is that the correct way to do it? ******************************* Setup RDO KIlo (AIO) on Fedora 22 ******************************* # dnf install -y https://rdoproject.org/repos/rdo-release.rpm # dnf install -y openstack-packstack # dnf install fedora-repos-rawhide # dnf --enablerepo=rawhide update openstack-packstack # dnf install python3-pyOpenSSL.noarch python-service-identity.noarch python-ndg_httpsclient.noarch ********************** At this point run :- ********************** # packstack --gen-answer-file answer-file-aio.txt and set CONFIG_KEYSTONE_SERVICE_NAME=httpd I also commented out second line in /etc/httpd/conf.d/mod_dnssd.conf # cd /usr/lib/python2.7/site-packages/packstack/puppet/templates and apply third patc from http://textuploader.com/yn0v It will disable provision_demo.pp. Then run # packstack --answer-file=./answer-file-aio.txt > > I'm installing useing: > > packstack --allinone > > So, I get an error from mysql (MariaDB) that looks like: > > Error: Evaluation Error: Comparison of: String >= Integer, is not > possible. Caused by 'A String is not comparable to a non String'. at > /var/tmp/packstack/8e5b1411ef25462dad1e216ac75fb2ab/modules/mysql/manifests/params.pp:35:82 > on node > > The file that it is point to nolonger exists so I didn't dig any further. > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From aragonx at dcsnow.com Wed Jul 22 20:41:35 2015 From: aragonx at dcsnow.com (Will Yonker) Date: Wed, 22 Jul 2015 20:41:35 -0000 Subject: [Rdo-list] Juno on Fedora 22 In-Reply-To: References: <79b1f8b4612fbceb3d4e4d8dbe58a7a0.squirrel@www.dcsnow.com> Message-ID: <0c57d424c21d5f0e6bf978882556a4fb.squirrel@www.dcsnow.com> > I also commented out second line in /etc/httpd/conf.d/mod_dnssd.conf I do not have this file. > # cd /usr/lib/python2.7/site-packages/packstack/puppet/templates > > and apply third patc from http://textuploader.com/yn0v > It will disable provision_demo.pp. I tried using patch but it failed. Looks like my file doesn't have the ipv6 check so the lines are different. I deleted that whole block manually. Was that correct? > Then run > > # packstack --answer-file=./answer-file-aio.txt I had to edit /usr/share/openstack-puppet/modules/apache/templates/httpd.conf.erb and insert Include conf.modules.d/*.conf right after IncludeOptional "<%= @confd_dir %>/*.conf" But I still got an error at: neutron.pp Error: Could not autoload puppet/provider/vs_port/ovs_redhat_el6: Could not find parent provider ovs_redhat of ovs_redhat_el6 The error file contained: Error: Could not autoload puppet/provider/vs_port/ovs_redhat_el6: Could not find parent provider ovs_redhat of ovs_redhat_el6^[[0m Error: Could not autoload puppet/type/vs_port: Could not autoload puppet/provider/vs_port/ovs_redhat_el6: Could not find parent provider ovs_redhat of ovs_redhat_el6^[[0m Error: Evaluation Error: Error while evaluating a Virtual Query, Could not autoload puppet/type/vs_port: Could not autoload puppet/provider/vs_port/ovs_redhat_el6: Could not find parent provider ovs_redhat of ovs_redhat_el6 at /var/tmp/packstack/bc47df3faa1e4c0e9a87dbeb02d13c8e/modules/vswitch/manifests/ovs.pp:84:29 on node Again, thank you very much for the help! -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From brian at brianlee.org Wed Jul 22 22:05:21 2015 From: brian at brianlee.org (brian lee) Date: Wed, 22 Jul 2015 17:05:21 -0500 Subject: [Rdo-list] VM instance will not start Message-ID: I have a fresh 2 node install of Kilo, maybe working with Nova networking (I dont know yet). When I try to start a VM I get this error in Horizon: Error: No valid host was found. There are not enough hosts available. There is nothing really telling in the logs beside this in the scheduler: 2015-07-22 19:57:56.232 22843 ERROR oslo_messaging._drivers.impl_rabbit [-] Failed to consume message from queue: 2015-07-22 19:59:19.465 997 WARNING oslo_config.cfg [req-d19b6788-9f3b-49e6-9124-b945f4c3e3e6 - - - - -] Option "sql_connection" from group "DEFAULT" is deprecated. Use option "connection" from group "database". 2015-07-22 19:59:20.739 997 WARNING oslo_config.cfg [req-d19b6788-9f3b-49e6-9124-b945f4c3e3e6 - - - - -] Option "lock_path" from group "DEFAULT" is deprecated. Use option "lock_path" from group "oslo_concurrency". 2015-07-22 19:59:20.785 997 INFO nova.service [-] Starting scheduler node (version 2015.1.0-3.el7) 2015-07-22 19:59:20.959 997 INFO oslo_messaging._drivers.impl_rabbit [req-0d6a61c6-54eb-42df-a2a2-596d535a8ac5 - - - - -] Connecting to AMQP server on 10.32.97.133:5672 2015-07-22 19:59:20.976 997 ERROR oslo_messaging._drivers.impl_rabbit [req-0d6a61c6-54eb-42df-a2a2-596d535a8ac5 - - - - -] AMQP server on 10.32.97.133:5672 is unreachable: [Errno 111] ECONNREFUSED. Trying again in 1 seconds. I am not seeing any other errors in the log files, any idea what else to check? --Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at brianlee.org Wed Jul 22 22:23:11 2015 From: brian at brianlee.org (brian lee) Date: Wed, 22 Jul 2015 17:23:11 -0500 Subject: [Rdo-list] VM instance will not start In-Reply-To: References: Message-ID: The compute node can ping the controller. I did just find this error in the compute log file: 2015-07-22 21:30:36.756 18880 ERROR nova.compute.manager [-] Instance failed network setup after 1 attempt(s) 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager Traceback (most recent call last): 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 1770, in _allocate_network_async 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager dhcp_options=dhcp_options) 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/nova/network/api.py", line 49, in wrapped 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager return func(self, context, *args, **kwargs) 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/nova/network/base_api.py", line 64, in wrapper 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager res = f(self, context, *args, **kwargs) 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/nova/network/api.py", line 281, in allocate_for_instance 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager nw_info = self.network_rpcapi.allocate_for_instance(context, **args) 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/nova/network/rpcapi.py", line 152, in allocate_for_instance 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager macs=jsonutils.to_primitive(macs)) 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/client.py", line 156, in call 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager retry=self.retry) 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/oslo_messaging/transport.py", line 90, in _send 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager timeout=timeout, retry=retry) 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 350, in send 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager retry=retry) 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 339, in _send 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager result = self._waiter.wait(msg_id, timeout) 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 243, in wait 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager message = self.waiters.get(msg_id, timeout=timeout) 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 149, in get 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager 'to message ID %s' % msg_id) 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager MessagingTimeout: Timed out waiting for a reply to message ID 63bcf088157e44b592913f7245249d07 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager 2015-07-22 21:30:36.761 18880 ERROR nova.compute.manager [req-3c3ddcae-0f6a-4aed-9f72-2ec3fd8ac073 - - - - -] [instance: 5e4d609c-0139-44cd-94e3-ecb765209b1e] Instance failed to spawn --Brian On Wed, Jul 22, 2015 at 5:20 PM, Kevin Tibi wrote: > Hi, > > I see error for rabbitmq. The compute node can ping the controller ? > > Kevin Tibi > Le 23 juil. 2015 00:07, "brian lee" a ?crit : > >> I have a fresh 2 node install of Kilo, maybe working with Nova networking >> (I dont know yet). When I try to start a VM I get this error in Horizon: >> Error: No valid host was found. There are not enough hosts available. >> >> There is nothing really telling in the logs beside this in the scheduler: >> >> 2015-07-22 19:57:56.232 22843 ERROR oslo_messaging._drivers.impl_rabbit >> [-] Failed to consume message from queue: >> 2015-07-22 19:59:19.465 997 WARNING oslo_config.cfg >> [req-d19b6788-9f3b-49e6-9124-b945f4c3e3e6 - - - - -] Option >> "sql_connection" from group "DEFAULT" is deprecated. Use option >> "connection" from group "database". >> 2015-07-22 19:59:20.739 997 WARNING oslo_config.cfg >> [req-d19b6788-9f3b-49e6-9124-b945f4c3e3e6 - - - - -] Option "lock_path" >> from group "DEFAULT" is deprecated. Use option "lock_path" from group >> "oslo_concurrency". >> 2015-07-22 19:59:20.785 997 INFO nova.service [-] Starting scheduler node >> (version 2015.1.0-3.el7) >> 2015-07-22 19:59:20.959 997 INFO oslo_messaging._drivers.impl_rabbit >> [req-0d6a61c6-54eb-42df-a2a2-596d535a8ac5 - - - - -] Connecting to AMQP >> server on 10.32.97.133:5672 >> 2015-07-22 19:59:20.976 997 ERROR oslo_messaging._drivers.impl_rabbit >> [req-0d6a61c6-54eb-42df-a2a2-596d535a8ac5 - - - - -] AMQP server on >> 10.32.97.133:5672 is unreachable: [Errno 111] ECONNREFUSED. Trying again >> in 1 seconds. >> >> I am not seeing any other errors in the log files, any idea what else to >> check? >> >> --Brian >> >> >> _______________________________________________ >> Rdo-list mailing list >> Rdo-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rdo-list >> >> To unsubscribe: rdo-list-unsubscribe at redhat.com >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevintibi at hotmail.com Wed Jul 22 22:20:09 2015 From: kevintibi at hotmail.com (Kevin Tibi) Date: Thu, 23 Jul 2015 00:20:09 +0200 Subject: [Rdo-list] VM instance will not start In-Reply-To: References: Message-ID: Hi, I see error for rabbitmq. The compute node can ping the controller ? Kevin Tibi Le 23 juil. 2015 00:07, "brian lee" a ?crit : > I have a fresh 2 node install of Kilo, maybe working with Nova networking > (I dont know yet). When I try to start a VM I get this error in Horizon: > Error: No valid host was found. There are not enough hosts available. > > There is nothing really telling in the logs beside this in the scheduler: > > 2015-07-22 19:57:56.232 22843 ERROR oslo_messaging._drivers.impl_rabbit > [-] Failed to consume message from queue: > 2015-07-22 19:59:19.465 997 WARNING oslo_config.cfg > [req-d19b6788-9f3b-49e6-9124-b945f4c3e3e6 - - - - -] Option > "sql_connection" from group "DEFAULT" is deprecated. Use option > "connection" from group "database". > 2015-07-22 19:59:20.739 997 WARNING oslo_config.cfg > [req-d19b6788-9f3b-49e6-9124-b945f4c3e3e6 - - - - -] Option "lock_path" > from group "DEFAULT" is deprecated. Use option "lock_path" from group > "oslo_concurrency". > 2015-07-22 19:59:20.785 997 INFO nova.service [-] Starting scheduler node > (version 2015.1.0-3.el7) > 2015-07-22 19:59:20.959 997 INFO oslo_messaging._drivers.impl_rabbit > [req-0d6a61c6-54eb-42df-a2a2-596d535a8ac5 - - - - -] Connecting to AMQP > server on 10.32.97.133:5672 > 2015-07-22 19:59:20.976 997 ERROR oslo_messaging._drivers.impl_rabbit > [req-0d6a61c6-54eb-42df-a2a2-596d535a8ac5 - - - - -] AMQP server on > 10.32.97.133:5672 is unreachable: [Errno 111] ECONNREFUSED. Trying again > in 1 seconds. > > I am not seeing any other errors in the log files, any idea what else to > check? > > --Brian > > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roxenham at redhat.com Wed Jul 22 23:02:29 2015 From: roxenham at redhat.com (Rhys Oxenham) Date: Thu, 23 Jul 2015 00:02:29 +0100 Subject: [Rdo-list] VM instance will not start In-Reply-To: References: Message-ID: <30A26EBB-381A-4ADF-8BC9-2D935F9D8884@redhat.com> On your controller node, do you have RabbitMQ running? # systemctl status rabbitmq-server I suspect that this isn?t running, yet the firewall port is open, hence the connection refused message. Cheers Rhys > On 22 Jul 2015, at 23:23, brian lee wrote: > > The compute node can ping the controller. > > I did just find this error in the compute log file: > > 2015-07-22 21:30:36.756 18880 ERROR nova.compute.manager [-] Instance failed network setup after 1 attempt(s) > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager Traceback (most recent call last): > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 1770, in _allocate_network_async > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager dhcp_options=dhcp_options) > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/nova/network/api.py", line 49, in wrapped > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager return func(self, context, *args, **kwargs) > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/nova/network/base_api.py", line 64, in wrapper > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager res = f(self, context, *args, **kwargs) > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/nova/network/api.py", line 281, in allocate_for_instance > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager nw_info = self.network_rpcapi.allocate_for_instance(context, **args) > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/nova/network/rpcapi.py", line 152, in allocate_for_instance > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager macs=jsonutils.to_primitive(macs)) > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/client.py", line 156, in call > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager retry=self.retry) > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/oslo_messaging/transport.py", line 90, in _send > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager timeout=timeout, retry=retry) > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 350, in send > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager retry=retry) > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 339, in _send > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager result = self._waiter.wait(msg_id, timeout) > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 243, in wait > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager message = self.waiters.get(msg_id, timeout=timeout) > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 149, in get > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager 'to message ID %s' % msg_id) > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager MessagingTimeout: Timed out waiting for a reply to message ID 63bcf088157e44b592913f7245249d07 > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager > 2015-07-22 21:30:36.761 18880 ERROR nova.compute.manager [req-3c3ddcae-0f6a-4aed-9f72-2ec3fd8ac073 - - - - -] [instance: 5e4d609c-0139-44cd-94e3-ecb765209b1e] Instance failed to spawn > > > --Brian > > On Wed, Jul 22, 2015 at 5:20 PM, Kevin Tibi wrote: > Hi, > > I see error for rabbitmq. The compute node can ping the controller ? > > Kevin Tibi > > Le 23 juil. 2015 00:07, "brian lee" a ?crit : > I have a fresh 2 node install of Kilo, maybe working with Nova networking (I dont know yet). When I try to start a VM I get this error in Horizon: > Error: No valid host was found. There are not enough hosts available. > > There is nothing really telling in the logs beside this in the scheduler: > > 2015-07-22 19:57:56.232 22843 ERROR oslo_messaging._drivers.impl_rabbit [-] Failed to consume message from queue: > 2015-07-22 19:59:19.465 997 WARNING oslo_config.cfg [req-d19b6788-9f3b-49e6-9124-b945f4c3e3e6 - - - - -] Option "sql_connection" from group "DEFAULT" is deprecated. Use option "connection" from group "database". > 2015-07-22 19:59:20.739 997 WARNING oslo_config.cfg [req-d19b6788-9f3b-49e6-9124-b945f4c3e3e6 - - - - -] Option "lock_path" from group "DEFAULT" is deprecated. Use option "lock_path" from group "oslo_concurrency". > 2015-07-22 19:59:20.785 997 INFO nova.service [-] Starting scheduler node (version 2015.1.0-3.el7) > 2015-07-22 19:59:20.959 997 INFO oslo_messaging._drivers.impl_rabbit [req-0d6a61c6-54eb-42df-a2a2-596d535a8ac5 - - - - -] Connecting to AMQP server on 10.32.97.133:5672 > 2015-07-22 19:59:20.976 997 ERROR oslo_messaging._drivers.impl_rabbit [req-0d6a61c6-54eb-42df-a2a2-596d535a8ac5 - - - - -] AMQP server on 10.32.97.133:5672 is unreachable: [Errno 111] ECONNREFUSED. Trying again in 1 seconds. > > I am not seeing any other errors in the log files, any idea what else to check? > > --Brian > > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com From brian at brianlee.org Wed Jul 22 23:02:28 2015 From: brian at brianlee.org (brian lee) Date: Wed, 22 Jul 2015 18:02:28 -0500 Subject: [Rdo-list] VM instance will not start In-Reply-To: <30A26EBB-381A-4ADF-8BC9-2D935F9D8884@redhat.com> References: <30A26EBB-381A-4ADF-8BC9-2D935F9D8884@redhat.com> Message-ID: Yes rabbitmq is running, and the firewall ports are open: ACCEPT tcp -- 10.32.97.133 0.0.0.0/0 multiport dports 5671,5672 /* 001 amqp incoming amqp_10.32.97.133 */ ACCEPT tcp -- 10.32.97.137 0.0.0.0/0 multiport dports 5671,5672 /* 001 amqp incoming amqp_10.32.97.137 */ .133 is the controller, .137 is the compute node. --Brian On Wed, Jul 22, 2015 at 6:02 PM, Rhys Oxenham wrote: > On your controller node, do you have RabbitMQ running? > > # systemctl status rabbitmq-server > > I suspect that this isn?t running, yet the firewall port is open, hence > the connection refused message. > > Cheers > Rhys > > > On 22 Jul 2015, at 23:23, brian lee wrote: > > > > The compute node can ping the controller. > > > > I did just find this error in the compute log file: > > > > 2015-07-22 21:30:36.756 18880 ERROR nova.compute.manager [-] Instance > failed network setup after 1 attempt(s) > > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager Traceback (most > recent call last): > > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File > "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 1770, in > _allocate_network_async > > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager > dhcp_options=dhcp_options) > > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File > "/usr/lib/python2.7/site-packages/nova/network/api.py", line 49, in wrapped > > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager return > func(self, context, *args, **kwargs) > > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File > "/usr/lib/python2.7/site-packages/nova/network/base_api.py", line 64, in > wrapper > > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager res = > f(self, context, *args, **kwargs) > > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File > "/usr/lib/python2.7/site-packages/nova/network/api.py", line 281, in > allocate_for_instance > > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager nw_info = > self.network_rpcapi.allocate_for_instance(context, **args) > > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File > "/usr/lib/python2.7/site-packages/nova/network/rpcapi.py", line 152, in > allocate_for_instance > > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager > macs=jsonutils.to_primitive(macs)) > > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File > "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/client.py", line 156, > in call > > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager > retry=self.retry) > > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File > "/usr/lib/python2.7/site-packages/oslo_messaging/transport.py", line 90, in > _send > > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager > timeout=timeout, retry=retry) > > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File > "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", > line 350, in send > > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager retry=retry) > > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File > "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", > line 339, in _send > > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager result = > self._waiter.wait(msg_id, timeout) > > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File > "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", > line 243, in wait > > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager message = > self.waiters.get(msg_id, timeout=timeout) > > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File > "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", > line 149, in get > > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager 'to message > ID %s' % msg_id) > > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager > MessagingTimeout: Timed out waiting for a reply to message ID > 63bcf088157e44b592913f7245249d07 > > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager > > 2015-07-22 21:30:36.761 18880 ERROR nova.compute.manager > [req-3c3ddcae-0f6a-4aed-9f72-2ec3fd8ac073 - - - - -] [instance: > 5e4d609c-0139-44cd-94e3-ecb765209b1e] Instance failed to spawn > > > > > > --Brian > > > > On Wed, Jul 22, 2015 at 5:20 PM, Kevin Tibi > wrote: > > Hi, > > > > I see error for rabbitmq. The compute node can ping the controller ? > > > > Kevin Tibi > > > > Le 23 juil. 2015 00:07, "brian lee" a ?crit : > > I have a fresh 2 node install of Kilo, maybe working with Nova > networking (I dont know yet). When I try to start a VM I get this error in > Horizon: > > Error: No valid host was found. There are not enough hosts available. > > > > There is nothing really telling in the logs beside this in the scheduler: > > > > 2015-07-22 19:57:56.232 22843 ERROR oslo_messaging._drivers.impl_rabbit > [-] Failed to consume message from queue: > > 2015-07-22 19:59:19.465 997 WARNING oslo_config.cfg > [req-d19b6788-9f3b-49e6-9124-b945f4c3e3e6 - - - - -] Option > "sql_connection" from group "DEFAULT" is deprecated. Use option > "connection" from group "database". > > 2015-07-22 19:59:20.739 997 WARNING oslo_config.cfg > [req-d19b6788-9f3b-49e6-9124-b945f4c3e3e6 - - - - -] Option "lock_path" > from group "DEFAULT" is deprecated. Use option "lock_path" from group > "oslo_concurrency". > > 2015-07-22 19:59:20.785 997 INFO nova.service [-] Starting scheduler > node (version 2015.1.0-3.el7) > > 2015-07-22 19:59:20.959 997 INFO oslo_messaging._drivers.impl_rabbit > [req-0d6a61c6-54eb-42df-a2a2-596d535a8ac5 - - - - -] Connecting to AMQP > server on 10.32.97.133:5672 > > 2015-07-22 19:59:20.976 997 ERROR oslo_messaging._drivers.impl_rabbit > [req-0d6a61c6-54eb-42df-a2a2-596d535a8ac5 - - - - -] AMQP server on > 10.32.97.133:5672 is unreachable: [Errno 111] ECONNREFUSED. Trying again > in 1 seconds. > > > > I am not seeing any other errors in the log files, any idea what else to > check? > > > > --Brian > > > > > > _______________________________________________ > > Rdo-list mailing list > > Rdo-list at redhat.com > > https://www.redhat.com/mailman/listinfo/rdo-list > > > > To unsubscribe: rdo-list-unsubscribe at redhat.com > > > > _______________________________________________ > > Rdo-list mailing list > > Rdo-list at redhat.com > > https://www.redhat.com/mailman/listinfo/rdo-list > > > > To unsubscribe: rdo-list-unsubscribe at redhat.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jweber at cofront.net Thu Jul 23 01:21:54 2015 From: jweber at cofront.net (Jeff Weber) Date: Wed, 22 Jul 2015 21:21:54 -0400 Subject: [Rdo-list] kilo centos versus rdo repos Message-ID: As an upstream user which set of repos are the recommended target to obtain rpms for installing an running kilo? I believe a few months back a message had indicated that the centos repos would be the preferred target, but monitoring both it seems newer packages which aren't in the centos repos have made it into the rdo hosted repos. Which of the two are recommended? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bderzhavets at hotmail.com Thu Jul 23 07:29:48 2015 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Thu, 23 Jul 2015 03:29:48 -0400 Subject: [Rdo-list] Juno on Fedora 22 In-Reply-To: <0c57d424c21d5f0e6bf978882556a4fb.squirrel@www.dcsnow.com> References: <79b1f8b4612fbceb3d4e4d8dbe58a7a0.squirrel@www.dcsnow.com>, , <0c57d424c21d5f0e6bf978882556a4fb.squirrel@www.dcsnow.com> Message-ID: > Date: Wed, 22 Jul 2015 20:41:35 +0000 > Subject: RE: [Rdo-list] Juno on Fedora 22 > From: aragonx at dcsnow.com > To: rdo-list at redhat.com > CC: bderzhavets at hotmail.com > > > I also commented out second line in /etc/httpd/conf.d/mod_dnssd.conf > > I do not have this file. > > > # cd /usr/lib/python2.7/site-packages/packstack/puppet/templates > > > > and apply third patc from http://textuploader.com/yn0v > > It will disable provision_demo.pp. > > I tried using patch but it failed. Looks like my file doesn't have the > ipv6 check so the lines are different. I deleted that whole block > manually. Was that correct? Yes. > > > > Then run > > > > # packstack --answer-file=./answer-file-aio.txt > > I had to edit > /usr/share/openstack-puppet/modules/apache/templates/httpd.conf.erb and > insert > Include conf.modules.d/*.conf > right after > IncludeOptional "<%= @confd_dir %>/*.conf" > > But I still got an error at: neutron.pp > Error: Could not autoload puppet/provider/vs_port/ovs_redhat_el6: Could > not find parent provider ovs_redhat of ovs_redhat_el6 > > The error file contained: > > Error: Could not autoload puppet/provider/vs_port/ovs_redhat_el6: Could > not find parent provider ovs_redhat of ovs_redhat_el6^[[0m > Error: Could not autoload puppet/type/vs_port: Could not autoload > puppet/provider/vs_port/ovs_redhat_el6: Could not find parent provider > ovs_redhat of ovs_redhat_el6^[[0m > Error: Evaluation Error: Error while evaluating a Virtual Query, Could not > autoload puppet/type/vs_port: Could not autoload > puppet/provider/vs_port/ovs_redhat_el6: Could not find parent provider > ovs_redhat of ovs_redhat_el6 at > /var/tmp/packstack/bc47df3faa1e4c0e9a87dbeb02d13c8e/modules/vswitch/manifests/ovs.pp:84:29 > on node Insert this line as first into ovs_redhat_el6.rbFile.expand_path(File.join(File.dirname(__FILE__), '.','ovs_redhat.rb') See https://bugzilla.redhat.com/show_bug.cgi?id=1234042 comment 6 > > Again, thank you very much for the help! > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bderzhavets at hotmail.com Thu Jul 23 07:37:39 2015 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Thu, 23 Jul 2015 03:37:39 -0400 Subject: [Rdo-list] RE(2): Juno on Fedora 22 In-Reply-To: <0c57d424c21d5f0e6bf978882556a4fb.squirrel@www.dcsnow.com> References: <79b1f8b4612fbceb3d4e4d8dbe58a7a0.squirrel@www.dcsnow.com>, , <0c57d424c21d5f0e6bf978882556a4fb.squirrel@www.dcsnow.com> Message-ID: > Date: Wed, 22 Jul 2015 20:41:35 +0000 > Subject: RE: [Rdo-list] Juno on Fedora 22 > From: aragonx at dcsnow.com > To: rdo-list at redhat.com > CC: bderzhavets at hotmail.com > > > I also commented out second line in /etc/httpd/conf.d/mod_dnssd.conf > > I do not have this file. > > > # cd /usr/lib/python2.7/site-packages/packstack/puppet/templates > > > > and apply third patc from http://textuploader.com/yn0v > > It will disable provision_demo.pp. > > I tried using patch but it failed. Looks like my file doesn't have the > ipv6 check so the lines are different. I deleted that whole block > manually. Was that correct? > > > > Then run > > > > # packstack --answer-file=./answer-file-aio.txt > > I had to edit > /usr/share/openstack-puppet/modules/apache/templates/httpd.conf.erb and > insert > Include conf.modules.d/*.conf > right after > IncludeOptional "<%= @confd_dir %>/*.conf" > > But I still got an error at: neutron.pp > Error: Could not autoload puppet/provider/vs_port/ovs_redhat_el6: Could > not find parent provider ovs_redhat of ovs_redhat_el6 > > The error file contained: > > Error: Could not autoload puppet/provider/vs_port/ovs_redhat_el6: Could > not find parent provider ovs_redhat of ovs_redhat_el6^[[0m > Error: Could not autoload puppet/type/vs_port: Could not autoload > puppet/provider/vs_port/ovs_redhat_el6: Could not find parent provider > ovs_redhat of ovs_redhat_el6^[[0m > Error: Evaluation Error: Error while evaluating a Virtual Query, Could not > autoload puppet/type/vs_port: Could not autoload > puppet/provider/vs_port/ovs_redhat_el6: Could not find parent provider > ovs_redhat of ovs_redhat_el6 at > /var/tmp/packstack/bc47df3faa1e4c0e9a87dbeb02d13c8e/modules/vswitch/manifests/ovs.pp:84:29 > on node Sorry for typo https://bugzilla.redhat.com/show_bug.cgi?id=1234042 In meantime on any box IP_neutron.pp fails due to failure auto load parent ovs_redhat, corresponding fix is inserting as first line:- require File.expand_path(File.join(File.dirname(__FILE__), '.','ovs_redhat.rb') into ovs_redhat_el6.rb> > Again, thank you very much for the help! > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ltoscano at redhat.com Thu Jul 23 10:10:25 2015 From: ltoscano at redhat.com (Luigi Toscano) Date: Thu, 23 Jul 2015 06:10:25 -0400 (EDT) Subject: [Rdo-list] Juno on Fedora 22 In-Reply-To: <79b1f8b4612fbceb3d4e4d8dbe58a7a0.squirrel@www.dcsnow.com> References: <79b1f8b4612fbceb3d4e4d8dbe58a7a0.squirrel@www.dcsnow.com> Message-ID: <1346705338.2681904.1437646225683.JavaMail.zimbra@redhat.com> ----- Original Message ----- > I'm trying to install on Fedora 22 and ran into a few issues. My first > question is if I should be trying for Juno or Kilo. I haven't been able > to get Kilo working so I switched to Juno. In order to get Juno to go, I > had to edit the rdo-release.repo file and point the baseurl to > http://repos.fedorapeople.org/repos/openstack/openstack-juno/epel-7/. > > Is that the correct way to do it? I don't think RDO Juno was ever tested (or intended to be used) on Fedora 22. There are not even repositories for it: https://repos.fedorapeople.org/repos/openstack/openstack-juno/ I would focus the efforts on RDO Kilo (which could have still some troubles on Fedora 22, but at least it meant to be working there), or switch back to Fedora 21, or use CentOS 7 which has a less changing base environments. Ciao -- Luigi From ltoscano at redhat.com Thu Jul 23 10:15:20 2015 From: ltoscano at redhat.com (Luigi Toscano) Date: Thu, 23 Jul 2015 06:15:20 -0400 (EDT) Subject: [Rdo-list] kilo centos versus rdo repos In-Reply-To: References: Message-ID: <1983750699.2683133.1437646520068.JavaMail.zimbra@redhat.com> ----- Original Message ----- > As an upstream user which set of repos are the recommended target to obtain > rpms for installing an running kilo? The instruction highlighted in the quick-start guide should always be the reference one: https://www.rdoproject.org/Quickstart rdo-release.rpm mentioned there right now points to: https://repos.fedorapeople.org/repos/openstack/openstack-kilo/rdo-release-kilo-1.noarch.rpm which installs the correct repo file. Is it not working for you? Ciao -- Luigi From jweber at cofront.net Thu Jul 23 12:54:10 2015 From: jweber at cofront.net (Jeff Weber) Date: Thu, 23 Jul 2015 08:54:10 -0400 Subject: [Rdo-list] kilo centos versus rdo repos In-Reply-To: <1983750699.2683133.1437646520068.JavaMail.zimbra@redhat.com> References: <1983750699.2683133.1437646520068.JavaMail.zimbra@redhat.com> Message-ID: This does work for me, there just happen to be two upstream sources which were both announced on the list related to RDO and Kilo and I'm looking to see which one is preferred or recommended. Previously I believe there was discussion that the CentOS distribution of RDO would be preferred for EL7 long term, but I didn't see anything further to that. Looks like the guidance is to continue to use the content hosted on the rdo specific release page based on your reply. On Thu, Jul 23, 2015 at 6:15 AM, Luigi Toscano wrote: > ----- Original Message ----- > > As an upstream user which set of repos are the recommended target to > obtain > > rpms for installing an running kilo? > > The instruction highlighted in the quick-start guide should always be the > reference one: > https://www.rdoproject.org/Quickstart > > rdo-release.rpm mentioned there right now points to: > > https://repos.fedorapeople.org/repos/openstack/openstack-kilo/rdo-release-kilo-1.noarch.rpm > > which installs the correct repo file. Is it not working for you? > > Ciao > -- > Luigi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at brianlee.org Thu Jul 23 13:09:36 2015 From: brian at brianlee.org (brian lee) Date: Thu, 23 Jul 2015 08:09:36 -0500 Subject: [Rdo-list] VM instance will not start In-Reply-To: References: <30A26EBB-381A-4ADF-8BC9-2D935F9D8884@redhat.com> Message-ID: I just found this error in my compute log file: oslo_messaging._drivers.impl_rabbit [-] Failed to consume message from queue: 'NoneType' object has no attribute '__getitem__' It keeps happening, and in horizon the instance build is staying in scheduling. --Brian On Wed, Jul 22, 2015 at 6:02 PM, brian lee wrote: > Yes rabbitmq is running, and the firewall ports are open: > > ACCEPT tcp -- 10.32.97.133 0.0.0.0/0 multiport > dports 5671,5672 /* 001 amqp incoming amqp_10.32.97.133 */ > ACCEPT tcp -- 10.32.97.137 0.0.0.0/0 multiport > dports 5671,5672 /* 001 amqp incoming amqp_10.32.97.137 */ > > .133 is the controller, .137 is the compute node. > > --Brian > > On Wed, Jul 22, 2015 at 6:02 PM, Rhys Oxenham wrote: > >> On your controller node, do you have RabbitMQ running? >> >> # systemctl status rabbitmq-server >> >> I suspect that this isn?t running, yet the firewall port is open, hence >> the connection refused message. >> >> Cheers >> Rhys >> >> > On 22 Jul 2015, at 23:23, brian lee wrote: >> > >> > The compute node can ping the controller. >> > >> > I did just find this error in the compute log file: >> > >> > 2015-07-22 21:30:36.756 18880 ERROR nova.compute.manager [-] Instance >> failed network setup after 1 attempt(s) >> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager Traceback >> (most recent call last): >> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File >> "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 1770, in >> _allocate_network_async >> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager >> dhcp_options=dhcp_options) >> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File >> "/usr/lib/python2.7/site-packages/nova/network/api.py", line 49, in wrapped >> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager return >> func(self, context, *args, **kwargs) >> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File >> "/usr/lib/python2.7/site-packages/nova/network/base_api.py", line 64, in >> wrapper >> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager res = >> f(self, context, *args, **kwargs) >> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File >> "/usr/lib/python2.7/site-packages/nova/network/api.py", line 281, in >> allocate_for_instance >> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager nw_info = >> self.network_rpcapi.allocate_for_instance(context, **args) >> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File >> "/usr/lib/python2.7/site-packages/nova/network/rpcapi.py", line 152, in >> allocate_for_instance >> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager >> macs=jsonutils.to_primitive(macs)) >> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File >> "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/client.py", line 156, >> in call >> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager >> retry=self.retry) >> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File >> "/usr/lib/python2.7/site-packages/oslo_messaging/transport.py", line 90, in >> _send >> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager >> timeout=timeout, retry=retry) >> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File >> "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", >> line 350, in send >> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager >> retry=retry) >> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File >> "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", >> line 339, in _send >> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager result = >> self._waiter.wait(msg_id, timeout) >> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File >> "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", >> line 243, in wait >> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager message = >> self.waiters.get(msg_id, timeout=timeout) >> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File >> "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", >> line 149, in get >> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager 'to >> message ID %s' % msg_id) >> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager >> MessagingTimeout: Timed out waiting for a reply to message ID >> 63bcf088157e44b592913f7245249d07 >> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager >> > 2015-07-22 21:30:36.761 18880 ERROR nova.compute.manager >> [req-3c3ddcae-0f6a-4aed-9f72-2ec3fd8ac073 - - - - -] [instance: >> 5e4d609c-0139-44cd-94e3-ecb765209b1e] Instance failed to spawn >> > >> > >> > --Brian >> > >> > On Wed, Jul 22, 2015 at 5:20 PM, Kevin Tibi >> wrote: >> > Hi, >> > >> > I see error for rabbitmq. The compute node can ping the controller ? >> > >> > Kevin Tibi >> > >> > Le 23 juil. 2015 00:07, "brian lee" a ?crit : >> > I have a fresh 2 node install of Kilo, maybe working with Nova >> networking (I dont know yet). When I try to start a VM I get this error in >> Horizon: >> > Error: No valid host was found. There are not enough hosts available. >> > >> > There is nothing really telling in the logs beside this in the >> scheduler: >> > >> > 2015-07-22 19:57:56.232 22843 ERROR >> oslo_messaging._drivers.impl_rabbit [-] Failed to consume message from >> queue: >> > 2015-07-22 19:59:19.465 997 WARNING oslo_config.cfg >> [req-d19b6788-9f3b-49e6-9124-b945f4c3e3e6 - - - - -] Option >> "sql_connection" from group "DEFAULT" is deprecated. Use option >> "connection" from group "database". >> > 2015-07-22 19:59:20.739 997 WARNING oslo_config.cfg >> [req-d19b6788-9f3b-49e6-9124-b945f4c3e3e6 - - - - -] Option "lock_path" >> from group "DEFAULT" is deprecated. Use option "lock_path" from group >> "oslo_concurrency". >> > 2015-07-22 19:59:20.785 997 INFO nova.service [-] Starting scheduler >> node (version 2015.1.0-3.el7) >> > 2015-07-22 19:59:20.959 997 INFO oslo_messaging._drivers.impl_rabbit >> [req-0d6a61c6-54eb-42df-a2a2-596d535a8ac5 - - - - -] Connecting to AMQP >> server on 10.32.97.133:5672 >> > 2015-07-22 19:59:20.976 997 ERROR oslo_messaging._drivers.impl_rabbit >> [req-0d6a61c6-54eb-42df-a2a2-596d535a8ac5 - - - - -] AMQP server on >> 10.32.97.133:5672 is unreachable: [Errno 111] ECONNREFUSED. Trying again >> in 1 seconds. >> > >> > I am not seeing any other errors in the log files, any idea what else >> to check? >> > >> > --Brian >> > >> > >> > _______________________________________________ >> > Rdo-list mailing list >> > Rdo-list at redhat.com >> > https://www.redhat.com/mailman/listinfo/rdo-list >> > >> > To unsubscribe: rdo-list-unsubscribe at redhat.com >> > >> > _______________________________________________ >> > Rdo-list mailing list >> > Rdo-list at redhat.com >> > https://www.redhat.com/mailman/listinfo/rdo-list >> > >> > To unsubscribe: rdo-list-unsubscribe at redhat.com >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at brianlee.org Thu Jul 23 21:26:08 2015 From: brian at brianlee.org (brian lee) Date: Thu, 23 Jul 2015 16:26:08 -0500 Subject: [Rdo-list] VM instance will not start In-Reply-To: References: <30A26EBB-381A-4ADF-8BC9-2D935F9D8884@redhat.com> Message-ID: So I have made headway on this problem. It was related to my networking. In order to get nova networking working you have to install the openstack-nova-network and openstack-nova-api packages on your compute nodes as well. You did not have to do this in Icehouse. Once that is installed, you then need to configure the nova.conf per the doc: http://docs.openstack.org/kilo/install-guide/install/yum/content/nova-networking-compute-node.html Once I have done that I am now able to get the instances started. On the compute node it does create the br100 bridge device. But it does not create it on the controller. Now I am stuck where I can get the instance up, but I can not ping it from the conrtoller/outside network. Any idea what needs to be done to get the controller to start its bridge so they can talk together? --Brian On Thu, Jul 23, 2015 at 8:09 AM, brian lee wrote: > I just found this error in my compute log file: > oslo_messaging._drivers.impl_rabbit [-] Failed to consume message from > queue: 'NoneType' object has no attribute '__getitem__' > > It keeps happening, and in horizon the instance build is staying in > scheduling. > > --Brian > > On Wed, Jul 22, 2015 at 6:02 PM, brian lee wrote: > >> Yes rabbitmq is running, and the firewall ports are open: >> >> ACCEPT tcp -- 10.32.97.133 0.0.0.0/0 multiport >> dports 5671,5672 /* 001 amqp incoming amqp_10.32.97.133 */ >> ACCEPT tcp -- 10.32.97.137 0.0.0.0/0 multiport >> dports 5671,5672 /* 001 amqp incoming amqp_10.32.97.137 */ >> >> .133 is the controller, .137 is the compute node. >> >> --Brian >> >> On Wed, Jul 22, 2015 at 6:02 PM, Rhys Oxenham >> wrote: >> >>> On your controller node, do you have RabbitMQ running? >>> >>> # systemctl status rabbitmq-server >>> >>> I suspect that this isn?t running, yet the firewall port is open, hence >>> the connection refused message. >>> >>> Cheers >>> Rhys >>> >>> > On 22 Jul 2015, at 23:23, brian lee wrote: >>> > >>> > The compute node can ping the controller. >>> > >>> > I did just find this error in the compute log file: >>> > >>> > 2015-07-22 21:30:36.756 18880 ERROR nova.compute.manager [-] Instance >>> failed network setup after 1 attempt(s) >>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager Traceback >>> (most recent call last): >>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File >>> "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 1770, in >>> _allocate_network_async >>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager >>> dhcp_options=dhcp_options) >>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File >>> "/usr/lib/python2.7/site-packages/nova/network/api.py", line 49, in wrapped >>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager return >>> func(self, context, *args, **kwargs) >>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File >>> "/usr/lib/python2.7/site-packages/nova/network/base_api.py", line 64, in >>> wrapper >>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager res = >>> f(self, context, *args, **kwargs) >>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File >>> "/usr/lib/python2.7/site-packages/nova/network/api.py", line 281, in >>> allocate_for_instance >>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager nw_info = >>> self.network_rpcapi.allocate_for_instance(context, **args) >>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File >>> "/usr/lib/python2.7/site-packages/nova/network/rpcapi.py", line 152, in >>> allocate_for_instance >>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager >>> macs=jsonutils.to_primitive(macs)) >>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File >>> "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/client.py", line 156, >>> in call >>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager >>> retry=self.retry) >>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File >>> "/usr/lib/python2.7/site-packages/oslo_messaging/transport.py", line 90, in >>> _send >>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager >>> timeout=timeout, retry=retry) >>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File >>> "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", >>> line 350, in send >>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager >>> retry=retry) >>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File >>> "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", >>> line 339, in _send >>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager result = >>> self._waiter.wait(msg_id, timeout) >>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File >>> "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", >>> line 243, in wait >>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager message = >>> self.waiters.get(msg_id, timeout=timeout) >>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File >>> "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", >>> line 149, in get >>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager 'to >>> message ID %s' % msg_id) >>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager >>> MessagingTimeout: Timed out waiting for a reply to message ID >>> 63bcf088157e44b592913f7245249d07 >>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager >>> > 2015-07-22 21:30:36.761 18880 ERROR nova.compute.manager >>> [req-3c3ddcae-0f6a-4aed-9f72-2ec3fd8ac073 - - - - -] [instance: >>> 5e4d609c-0139-44cd-94e3-ecb765209b1e] Instance failed to spawn >>> > >>> > >>> > --Brian >>> > >>> > On Wed, Jul 22, 2015 at 5:20 PM, Kevin Tibi >>> wrote: >>> > Hi, >>> > >>> > I see error for rabbitmq. The compute node can ping the controller ? >>> > >>> > Kevin Tibi >>> > >>> > Le 23 juil. 2015 00:07, "brian lee" a ?crit : >>> > I have a fresh 2 node install of Kilo, maybe working with Nova >>> networking (I dont know yet). When I try to start a VM I get this error in >>> Horizon: >>> > Error: No valid host was found. There are not enough hosts available. >>> > >>> > There is nothing really telling in the logs beside this in the >>> scheduler: >>> > >>> > 2015-07-22 19:57:56.232 22843 ERROR >>> oslo_messaging._drivers.impl_rabbit [-] Failed to consume message from >>> queue: >>> > 2015-07-22 19:59:19.465 997 WARNING oslo_config.cfg >>> [req-d19b6788-9f3b-49e6-9124-b945f4c3e3e6 - - - - -] Option >>> "sql_connection" from group "DEFAULT" is deprecated. Use option >>> "connection" from group "database". >>> > 2015-07-22 19:59:20.739 997 WARNING oslo_config.cfg >>> [req-d19b6788-9f3b-49e6-9124-b945f4c3e3e6 - - - - -] Option "lock_path" >>> from group "DEFAULT" is deprecated. Use option "lock_path" from group >>> "oslo_concurrency". >>> > 2015-07-22 19:59:20.785 997 INFO nova.service [-] Starting scheduler >>> node (version 2015.1.0-3.el7) >>> > 2015-07-22 19:59:20.959 997 INFO oslo_messaging._drivers.impl_rabbit >>> [req-0d6a61c6-54eb-42df-a2a2-596d535a8ac5 - - - - -] Connecting to AMQP >>> server on 10.32.97.133:5672 >>> > 2015-07-22 19:59:20.976 997 ERROR oslo_messaging._drivers.impl_rabbit >>> [req-0d6a61c6-54eb-42df-a2a2-596d535a8ac5 - - - - -] AMQP server on >>> 10.32.97.133:5672 is unreachable: [Errno 111] ECONNREFUSED. Trying >>> again in 1 seconds. >>> > >>> > I am not seeing any other errors in the log files, any idea what else >>> to check? >>> > >>> > --Brian >>> > >>> > >>> > _______________________________________________ >>> > Rdo-list mailing list >>> > Rdo-list at redhat.com >>> > https://www.redhat.com/mailman/listinfo/rdo-list >>> > >>> > To unsubscribe: rdo-list-unsubscribe at redhat.com >>> > >>> > _______________________________________________ >>> > Rdo-list mailing list >>> > Rdo-list at redhat.com >>> > https://www.redhat.com/mailman/listinfo/rdo-list >>> > >>> > To unsubscribe: rdo-list-unsubscribe at redhat.com >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at brianlee.org Fri Jul 24 12:04:37 2015 From: brian at brianlee.org (brian lee) Date: Fri, 24 Jul 2015 07:04:37 -0500 Subject: [Rdo-list] VM instance will not start In-Reply-To: References: <30A26EBB-381A-4ADF-8BC9-2D935F9D8884@redhat.com> Message-ID: So is there anyone around that can help with nova networking? --Brian On Thu, Jul 23, 2015 at 4:26 PM, brian lee wrote: > So I have made headway on this problem. It was related to my networking. > In order to get nova networking working you have to install the > openstack-nova-network and openstack-nova-api packages on your compute > nodes as well. You did not have to do this in Icehouse. > > Once that is installed, you then need to configure the nova.conf per the > doc: > http://docs.openstack.org/kilo/install-guide/install/yum/content/nova-networking-compute-node.html > > Once I have done that I am now able to get the instances started. On the > compute node it does create the br100 bridge device. But it does not create > it on the controller. > > Now I am stuck where I can get the instance up, but I can not ping it from > the conrtoller/outside network. Any idea what needs to be done to get the > controller to start its bridge so they can talk together? > > --Brian > > On Thu, Jul 23, 2015 at 8:09 AM, brian lee wrote: > >> I just found this error in my compute log file: >> oslo_messaging._drivers.impl_rabbit [-] Failed to consume message from >> queue: 'NoneType' object has no attribute '__getitem__' >> >> It keeps happening, and in horizon the instance build is staying in >> scheduling. >> >> --Brian >> >> On Wed, Jul 22, 2015 at 6:02 PM, brian lee wrote: >> >>> Yes rabbitmq is running, and the firewall ports are open: >>> >>> ACCEPT tcp -- 10.32.97.133 0.0.0.0/0 multiport >>> dports 5671,5672 /* 001 amqp incoming amqp_10.32.97.133 */ >>> ACCEPT tcp -- 10.32.97.137 0.0.0.0/0 multiport >>> dports 5671,5672 /* 001 amqp incoming amqp_10.32.97.137 */ >>> >>> .133 is the controller, .137 is the compute node. >>> >>> --Brian >>> >>> On Wed, Jul 22, 2015 at 6:02 PM, Rhys Oxenham >>> wrote: >>> >>>> On your controller node, do you have RabbitMQ running? >>>> >>>> # systemctl status rabbitmq-server >>>> >>>> I suspect that this isn?t running, yet the firewall port is open, hence >>>> the connection refused message. >>>> >>>> Cheers >>>> Rhys >>>> >>>> > On 22 Jul 2015, at 23:23, brian lee wrote: >>>> > >>>> > The compute node can ping the controller. >>>> > >>>> > I did just find this error in the compute log file: >>>> > >>>> > 2015-07-22 21:30:36.756 18880 ERROR nova.compute.manager [-] Instance >>>> failed network setup after 1 attempt(s) >>>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager Traceback >>>> (most recent call last): >>>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File >>>> "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 1770, in >>>> _allocate_network_async >>>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager >>>> dhcp_options=dhcp_options) >>>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File >>>> "/usr/lib/python2.7/site-packages/nova/network/api.py", line 49, in wrapped >>>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager return >>>> func(self, context, *args, **kwargs) >>>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File >>>> "/usr/lib/python2.7/site-packages/nova/network/base_api.py", line 64, in >>>> wrapper >>>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager res = >>>> f(self, context, *args, **kwargs) >>>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File >>>> "/usr/lib/python2.7/site-packages/nova/network/api.py", line 281, in >>>> allocate_for_instance >>>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager nw_info >>>> = self.network_rpcapi.allocate_for_instance(context, **args) >>>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File >>>> "/usr/lib/python2.7/site-packages/nova/network/rpcapi.py", line 152, in >>>> allocate_for_instance >>>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager >>>> macs=jsonutils.to_primitive(macs)) >>>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File >>>> "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/client.py", line 156, >>>> in call >>>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager >>>> retry=self.retry) >>>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File >>>> "/usr/lib/python2.7/site-packages/oslo_messaging/transport.py", line 90, in >>>> _send >>>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager >>>> timeout=timeout, retry=retry) >>>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File >>>> "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", >>>> line 350, in send >>>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager >>>> retry=retry) >>>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File >>>> "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", >>>> line 339, in _send >>>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager result = >>>> self._waiter.wait(msg_id, timeout) >>>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File >>>> "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", >>>> line 243, in wait >>>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager message >>>> = self.waiters.get(msg_id, timeout=timeout) >>>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager File >>>> "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", >>>> line 149, in get >>>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager 'to >>>> message ID %s' % msg_id) >>>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager >>>> MessagingTimeout: Timed out waiting for a reply to message ID >>>> 63bcf088157e44b592913f7245249d07 >>>> > 2015-07-22 21:30:36.756 18880 TRACE nova.compute.manager >>>> > 2015-07-22 21:30:36.761 18880 ERROR nova.compute.manager >>>> [req-3c3ddcae-0f6a-4aed-9f72-2ec3fd8ac073 - - - - -] [instance: >>>> 5e4d609c-0139-44cd-94e3-ecb765209b1e] Instance failed to spawn >>>> > >>>> > >>>> > --Brian >>>> > >>>> > On Wed, Jul 22, 2015 at 5:20 PM, Kevin Tibi >>>> wrote: >>>> > Hi, >>>> > >>>> > I see error for rabbitmq. The compute node can ping the controller ? >>>> > >>>> > Kevin Tibi >>>> > >>>> > Le 23 juil. 2015 00:07, "brian lee" a ?crit : >>>> > I have a fresh 2 node install of Kilo, maybe working with Nova >>>> networking (I dont know yet). When I try to start a VM I get this error in >>>> Horizon: >>>> > Error: No valid host was found. There are not enough hosts available. >>>> > >>>> > There is nothing really telling in the logs beside this in the >>>> scheduler: >>>> > >>>> > 2015-07-22 19:57:56.232 22843 ERROR >>>> oslo_messaging._drivers.impl_rabbit [-] Failed to consume message from >>>> queue: >>>> > 2015-07-22 19:59:19.465 997 WARNING oslo_config.cfg >>>> [req-d19b6788-9f3b-49e6-9124-b945f4c3e3e6 - - - - -] Option >>>> "sql_connection" from group "DEFAULT" is deprecated. Use option >>>> "connection" from group "database". >>>> > 2015-07-22 19:59:20.739 997 WARNING oslo_config.cfg >>>> [req-d19b6788-9f3b-49e6-9124-b945f4c3e3e6 - - - - -] Option "lock_path" >>>> from group "DEFAULT" is deprecated. Use option "lock_path" from group >>>> "oslo_concurrency". >>>> > 2015-07-22 19:59:20.785 997 INFO nova.service [-] Starting scheduler >>>> node (version 2015.1.0-3.el7) >>>> > 2015-07-22 19:59:20.959 997 INFO oslo_messaging._drivers.impl_rabbit >>>> [req-0d6a61c6-54eb-42df-a2a2-596d535a8ac5 - - - - -] Connecting to AMQP >>>> server on 10.32.97.133:5672 >>>> > 2015-07-22 19:59:20.976 997 ERROR oslo_messaging._drivers.impl_rabbit >>>> [req-0d6a61c6-54eb-42df-a2a2-596d535a8ac5 - - - - -] AMQP server on >>>> 10.32.97.133:5672 is unreachable: [Errno 111] ECONNREFUSED. Trying >>>> again in 1 seconds. >>>> > >>>> > I am not seeing any other errors in the log files, any idea what else >>>> to check? >>>> > >>>> > --Brian >>>> > >>>> > >>>> > _______________________________________________ >>>> > Rdo-list mailing list >>>> > Rdo-list at redhat.com >>>> > https://www.redhat.com/mailman/listinfo/rdo-list >>>> > >>>> > To unsubscribe: rdo-list-unsubscribe at redhat.com >>>> > >>>> > _______________________________________________ >>>> > Rdo-list mailing list >>>> > Rdo-list at redhat.com >>>> > https://www.redhat.com/mailman/listinfo/rdo-list >>>> > >>>> > To unsubscribe: rdo-list-unsubscribe at redhat.com >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sandro at mathys.io Fri Jul 24 13:46:14 2015 From: sandro at mathys.io (Sandro Mathys) Date: Fri, 24 Jul 2015 22:46:14 +0900 Subject: [Rdo-list] Fwd: [MidoNet] RDO MidoNet integration guide updated to Kilo & MidoNet 2015.06 Message-ID: FYI ---------- Forwarded message ---------- From: Fernando Moreno Date: Fri, Jul 24, 2015 at 10:34 PM Subject: [MidoNet] RDO MidoNet integration guide updated to Kilo & MidoNet 2015.06 To: midonet at lists.midonet.org Hello, The RDO MidoNet integration guide has been updated to Openstack Kilo and MidoNet 2015.06: https://www.rdoproject.org/MidoNet_integration Feedback is welcome, for reference MidoNet 2015.06 release notes can be found here: http://blog.midonet.org/midonet-2015-06-release/ Also as a reminder we have several communication channels to get in touch with MidoNet community, please visit https://github.com/midonet/midonet/wiki/Communication for more info. Regards, Fernando _______________________________________________ MidoNet mailing list MidoNet at lists.midonet.org http://lists.midonet.org/listinfo/midonet From beagles at redhat.com Fri Jul 24 17:26:18 2015 From: beagles at redhat.com (Brent Eagles) Date: Fri, 24 Jul 2015 14:56:18 -0230 Subject: [Rdo-list] VM instance will not start In-Reply-To: References: <30A26EBB-381A-4ADF-8BC9-2D935F9D8884@redhat.com> Message-ID: <20150724172618.GA3518@b3ntpin.localdomain> On Thu, Jul 23, 2015 at 04:26:08PM -0500, brian lee wrote: > So I have made headway on this problem. It was related to my networking. In > order to get nova networking working you have to install the > openstack-nova-network and openstack-nova-api packages on your compute > nodes as well. You did not have to do this in Icehouse. > > Once that is installed, you then need to configure the nova.conf per the > doc: > http://docs.openstack.org/kilo/install-guide/install/yum/content/nova-networking-compute-node.html Note that if you are using multi-host networks then each compute node is also a network controller, so nova-network and nova-api will be required on each compute node. > Once I have done that I am now able to get the instances started. On the > compute node it does create the br100 bridge device. But it does not create > it on the controller. You can check if openstack-nova-network running on the controller - but if you are using multi-host networking this is probably irrelevant. > Now I am stuck where I can get the instance up, but I can not ping it from > the conrtoller/outside network. Any idea what needs to be done to get the > controller to start its bridge so they can talk together? > > --Brian IIRC, if you are using multi-host networks you need to keep in mind that while each compute node is a network controller - the reverse is also true. i.e. a node is only a network controller for an instance's tenant network IF that node has an instance for that tenant running on it. If there isn't an instance for a particular tenant on a given node, there may be no bridge for that tenant network, etc. on it. This has to do with how the networks are provisioned - the bridges are setup where a tenant network is required, i.e. where an instance has been booted. Also of course, there is no standalone network-controller. To get access to your guest, try going through the multi-host node instead of the "controller" (which isn't a network controller in this case). If you *don't* use multi-host then you the network service should only be required on one host. Cheers, Brent -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From brian at brianlee.org Fri Jul 24 17:59:01 2015 From: brian at brianlee.org (brian lee) Date: Fri, 24 Jul 2015 12:59:01 -0500 Subject: [Rdo-list] VM instance will not start In-Reply-To: <20150724172618.GA3518@b3ntpin.localdomain> References: <30A26EBB-381A-4ADF-8BC9-2D935F9D8884@redhat.com> <20150724172618.GA3518@b3ntpin.localdomain> Message-ID: Thanks for the follow up. I think I am getting it. When you say multi host, you are refereing to the setting in nova.conf multi_host, correct? If I want the traffic to be routed through the controller, I should set that to false, and not install the nova-network on the compute hosts. --Brian On Fri, Jul 24, 2015 at 12:26 PM, Brent Eagles wrote: > On Thu, Jul 23, 2015 at 04:26:08PM -0500, brian lee wrote: > > So I have made headway on this problem. It was related to my networking. > In > > order to get nova networking working you have to install the > > openstack-nova-network and openstack-nova-api packages on your compute > > nodes as well. You did not have to do this in Icehouse. > > > > Once that is installed, you then need to configure the nova.conf per the > > doc: > > > http://docs.openstack.org/kilo/install-guide/install/yum/content/nova-networking-compute-node.html > > Note that if you are using multi-host networks then each compute > node is also a network controller, so nova-network and nova-api will be > required on each compute node. > > > Once I have done that I am now able to get the instances started. On the > > compute node it does create the br100 bridge device. But it does not > create > > it on the controller. > > You can check if openstack-nova-network running on the controller - but > if you are using multi-host networking this is probably irrelevant. > > > Now I am stuck where I can get the instance up, but I can not ping it > from > > the conrtoller/outside network. Any idea what needs to be done to get the > > controller to start its bridge so they can talk together? > > > > --Brian > > IIRC, if you are using multi-host networks you need to keep in mind that > while each compute node is a network controller - the reverse is also > true. i.e. a node is only a network controller for an instance's tenant > network IF that node has an instance for that tenant running on it. If > there isn't an instance for a particular tenant on a given node, there > may be no bridge for that tenant network, etc. on it. This has to do > with how the networks are provisioned - the bridges are setup where a > tenant network is required, i.e. where an instance has been booted. Also > of course, there is no standalone network-controller. > > To get access to your guest, try going through the multi-host node > instead of the "controller" (which isn't a network controller in this > case). > > If you *don't* use multi-host then you the network service should only > be required on one host. > > Cheers, > > Brent > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From beagles at redhat.com Fri Jul 24 18:20:30 2015 From: beagles at redhat.com (Brent Eagles) Date: Fri, 24 Jul 2015 15:50:30 -0230 Subject: [Rdo-list] VM instance will not start In-Reply-To: References: <30A26EBB-381A-4ADF-8BC9-2D935F9D8884@redhat.com> <20150724172618.GA3518@b3ntpin.localdomain> Message-ID: <20150724182030.GB3518@b3ntpin.localdomain> Hi, On Fri, Jul 24, 2015 at 12:59:01PM -0500, brian lee wrote: > Thanks for the follow up. I think I am getting it. When you say multi host, > you are refereing to the setting in nova.conf multi_host, correct? > > If I want the traffic to be routed through the controller, I should set > that to false, and not install the nova-network on the compute hosts. > > --Brian Yes, that's right. An additional caveat: any networks that have already been created have a field in the database that indicates that it is for multi-host and IIRC won't work any more. You can try logging into the database and tweaking the appropriate field to N (or whatever constitutes false in that case). Alternatively, you have to redeploy. Yeah.. changing network configs in nova-network can be a pain. Cheers, Brent -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From brian at brianlee.org Fri Jul 24 19:18:48 2015 From: brian at brianlee.org (brian lee) Date: Fri, 24 Jul 2015 14:18:48 -0500 Subject: [Rdo-list] VM instance will not start In-Reply-To: <20150724182030.GB3518@b3ntpin.localdomain> References: <30A26EBB-381A-4ADF-8BC9-2D935F9D8884@redhat.com> <20150724172618.GA3518@b3ntpin.localdomain> <20150724182030.GB3518@b3ntpin.localdomain> Message-ID: Could I use the nova commands to remove the network, then add it again? i.e. nova network-delete ; nova network-add --Brian On Fri, Jul 24, 2015 at 1:20 PM, Brent Eagles wrote: > Hi, > > On Fri, Jul 24, 2015 at 12:59:01PM -0500, brian lee wrote: > > Thanks for the follow up. I think I am getting it. When you say multi > host, > > you are refereing to the setting in nova.conf multi_host, correct? > > > > If I want the traffic to be routed through the controller, I should set > > that to false, and not install the nova-network on the compute hosts. > > > > --Brian > > Yes, that's right. An additional caveat: any networks that have already > been created have a field in the database that indicates that it is for > multi-host and IIRC won't work any more. You can try logging into the > database and tweaking the appropriate field to N (or whatever > constitutes false in that case). Alternatively, you have to redeploy. > Yeah.. changing network configs in nova-network can be a pain. > > Cheers, > > Brent > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From beagles at redhat.com Fri Jul 24 19:23:03 2015 From: beagles at redhat.com (Brent Eagles) Date: Fri, 24 Jul 2015 16:53:03 -0230 Subject: [Rdo-list] VM instance will not start In-Reply-To: References: <30A26EBB-381A-4ADF-8BC9-2D935F9D8884@redhat.com> <20150724172618.GA3518@b3ntpin.localdomain> <20150724182030.GB3518@b3ntpin.localdomain> Message-ID: <20150724192303.GC3518@b3ntpin.localdomain> On Fri, Jul 24, 2015 at 02:18:48PM -0500, brian lee wrote: > Could I use the nova commands to remove the network, then add it again? > i.e. nova network-delete ; nova network-add > > > --Brian Hah.. of course yes, that would be the most sensible option :) More coffee is needed I guess. Cheers, Brent -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From mohammed.arafa at gmail.com Fri Jul 24 19:23:30 2015 From: mohammed.arafa at gmail.com (Mohammed Arafa) Date: Fri, 24 Jul 2015 15:23:30 -0400 Subject: [Rdo-list] VM instance will not start In-Reply-To: References: <30A26EBB-381A-4ADF-8BC9-2D935F9D8884@redhat.com> <20150724172618.GA3518@b3ntpin.localdomain> <20150724182030.GB3518@b3ntpin.localdomain> Message-ID: i didnt read the entire thread but nova networking is either depreciated or deprecated. neutron is the networking component of openstack now. On Fri, Jul 24, 2015 at 3:18 PM, brian lee wrote: > Could I use the nova commands to remove the network, then add it again? > i.e. nova network-delete ; nova network-add > > > --Brian > > On Fri, Jul 24, 2015 at 1:20 PM, Brent Eagles wrote: > >> Hi, >> >> On Fri, Jul 24, 2015 at 12:59:01PM -0500, brian lee wrote: >> > Thanks for the follow up. I think I am getting it. When you say multi >> host, >> > you are refereing to the setting in nova.conf multi_host, correct? >> > >> > If I want the traffic to be routed through the controller, I should set >> > that to false, and not install the nova-network on the compute hosts. >> > >> > --Brian >> >> Yes, that's right. An additional caveat: any networks that have already >> been created have a field in the database that indicates that it is for >> multi-host and IIRC won't work any more. You can try logging into the >> database and tweaking the appropriate field to N (or whatever >> constitutes false in that case). Alternatively, you have to redeploy. >> Yeah.. changing network configs in nova-network can be a pain. >> >> Cheers, >> >> Brent >> >> > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com > -- *805010942448935* *GR750055912MA* *Link to me on LinkedIn * -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at brianlee.org Fri Jul 24 19:28:34 2015 From: brian at brianlee.org (brian lee) Date: Fri, 24 Jul 2015 14:28:34 -0500 Subject: [Rdo-list] VM instance will not start In-Reply-To: References: <30A26EBB-381A-4ADF-8BC9-2D935F9D8884@redhat.com> <20150724172618.GA3518@b3ntpin.localdomain> <20150724182030.GB3518@b3ntpin.localdomain> Message-ID: Thanks Brent. Mohammed: Nova networking has not been deprecated yet. There still are some issues with neutron not completely replacing it, from my understanding: http://docs.openstack.org/openstack-ops/content/nova-network-deprecation.html --Brian On Fri, Jul 24, 2015 at 2:23 PM, Mohammed Arafa wrote: > i didnt read the entire thread but nova networking is either depreciated > or deprecated. neutron is the networking component of openstack now. > > On Fri, Jul 24, 2015 at 3:18 PM, brian lee wrote: > >> Could I use the nova commands to remove the network, then add it again? >> i.e. nova network-delete ; nova network-add >> >> >> --Brian >> >> On Fri, Jul 24, 2015 at 1:20 PM, Brent Eagles wrote: >> >>> Hi, >>> >>> On Fri, Jul 24, 2015 at 12:59:01PM -0500, brian lee wrote: >>> > Thanks for the follow up. I think I am getting it. When you say multi >>> host, >>> > you are refereing to the setting in nova.conf multi_host, correct? >>> > >>> > If I want the traffic to be routed through the controller, I should set >>> > that to false, and not install the nova-network on the compute hosts. >>> > >>> > --Brian >>> >>> Yes, that's right. An additional caveat: any networks that have already >>> been created have a field in the database that indicates that it is for >>> multi-host and IIRC won't work any more. You can try logging into the >>> database and tweaking the appropriate field to N (or whatever >>> constitutes false in that case). Alternatively, you have to redeploy. >>> Yeah.. changing network configs in nova-network can be a pain. >>> >>> Cheers, >>> >>> Brent >>> >>> >> >> _______________________________________________ >> Rdo-list mailing list >> Rdo-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rdo-list >> >> To unsubscribe: rdo-list-unsubscribe at redhat.com >> > > > > -- > > > > > *805010942448935* > > > *GR750055912MA* > > > *Link to me on LinkedIn * > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hguemar at fedoraproject.org Mon Jul 27 11:01:25 2015 From: hguemar at fedoraproject.org (=?UTF-8?Q?Ha=C3=AFkel?=) Date: Mon, 27 Jul 2015 13:01:25 +0200 Subject: [Rdo-list] kilo centos versus rdo repos In-Reply-To: References: <1983750699.2683133.1437646520068.JavaMail.zimbra@redhat.com> Message-ID: Hi, Yes, long-term plans are to completely switch to CentOS repositories for EL, but we still have to plug our CI to the CentOS infrastructure. So we still officially recommend our own repos until then. As a matter of fact, we ship the same packages in both repositories albeit RDO repos are not synced with latest builds. If you use CentOS repositories, you can expect the same level of support as with RDO repositories. If you have any examples of packages out of sync on CentOS mirrors, please ping me directly (on #rdo, I'm number80) It's still a manual process (and I don't have signing privileges so I have to ask CentOS releng for that) Regards, H. From ichi.sara at gmail.com Mon Jul 27 12:14:16 2015 From: ichi.sara at gmail.com (ICHIBA Sara) Date: Mon, 27 Jul 2015 14:14:16 +0200 Subject: [Rdo-list] [heat] assign securitu group to an autoscaling group Message-ID: Hey there. When trying to assign a security group to an autoscaling groups i get some errors. I would really appreciate if you can help me. please find below the part of the template which describes the security groups and its usage + the associated logs. =======cassandra_scaling_up_down2.yaml resources: security_groups: type: OS::Neutron::SecurityGroup properties: name: security_groups rules: - protocol: tcp port_range_min: 8888 port_range_max: 8888 - protocol: tcp port_range_min: 7000 port_range_max: 7000 - protocol: tcp port_range_min: 7001 port_range_max: 7001 - protocol: icmp - protocol: tcp port_range_min: 22 port_range_max: 22 - protocol: tcp port_range_min: 7199 port_range_max: 7199 - protocol: tcp port_range_min: 9042 port_range_max: 9042 - protocol: tcp port_range_min: 9160 port_range_max: 9160 db_port: type: OS::Neutron::Port properties: network_id: { get_param: network } fixed_ips: - subnet_id: { get_param: subnet_id } security_groups: - {get_resource: security_groups} group: type: OS::Heat::AutoScalingGroup properties: cooldown: 60 desired_capacity: 1 max_size: 5 min_size: 1 resource: type: OS::Nova::Server::Cassandra properties: flavor: {get_param: flavor} image: {get_param: image} key_name: {get_param: key_name} networks: - port: {get_resource: db_port} ===========environment.cassandra.yaml resource_registry: "OS::Nova::Server::Cassandra": "cassandra_envir.yaml" ==========cassandra_envir.yaml resources: server: type: OS::Nova::Server properties: image: {get_param: image} flavor: {get_param: flavor} key_name: {get_param: key_name} networks: - port: { get_param: db_port } metadata: {get_param: metadata} user_data: {get_param: user_data} user_data_format: RAW ========/var/log/heat/heat- engine.log 2015-07-27 13:59:08.423 4665 INFO heat.engine.environment [req-ca831d72-de65-459e-b330-8d89646f522a None] Registering OS::Nova::Server::Cassandra -> file:///etc/heat/templates/cassandra_envir.yaml 2015-07-27 13:59:08.449 4665 INFO heat.engine.environment [req-f6dfcf2b-1936-4be1-b93f-c5cd151207e5 None] Registering OS::Nova::Server::Cassandra -> file:///etc/heat/templates/cassandra_envir.yaml 2015-07-27 13:59:10.678 4665 INFO heat.engine.service [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Creating stack cassandra_up_down_lb2 2015-07-27 13:59:10.695 4665 INFO heat.engine.environment [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Registering OS::Nova::Server::Cassandra -> file:///etc/heat/templates/cassandra_envir.yaml 2015-07-27 13:59:10.710 4665 INFO heat.engine.resource [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Validating HealthMonitor "monitor" 2015-07-27 13:59:10.711 4665 INFO heat.engine.resource [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Validating SecurityGroup "security_groups" 2015-07-27 13:59:10.714 4665 INFO heat.engine.resource [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Validating Port "lb_vip_port" 2015-07-27 13:59:10.715 4665 INFO heat.engine.resource [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Validating FloatingIP "lb_vip_floating_ip" 2015-07-27 13:59:10.715 4665 INFO heat.engine.resource [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Validating Port "db_port" 2015-07-27 13:59:10.716 4665 INFO heat.engine.resource [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Validating Pool "pool" 2015-07-27 13:59:10.717 4665 INFO heat.engine.resource [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Validating LoadBalancer "lb" 2015-07-27 13:59:10.718 4665 INFO heat.engine.resource [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Validating AutoScalingResourceGroup "group" 2015-07-27 13:59:10.719 4665 INFO heat.engine.resource [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Validating AutoScalingPolicy "scaledown_policy" 2015-07-27 13:59:10.719 4665 INFO heat.engine.resource [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Validating AutoScalingPolicy "scaleup_policy" 2015-07-27 13:59:10.720 4665 INFO heat.engine.resource [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Validating CeilometerAlarm "cpu_alarm_high" 2015-07-27 13:59:10.721 4665 INFO heat.engine.resource [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Validating CeilometerAlarm "cpu_alarm_low" 2015-07-27 13:59:10.722 4665 INFO heat.engine.resource [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Validating FloatingIPAssociation "lb_pool_vip" 2015-07-27 13:59:10.909 4665 INFO heat.engine.environment [req-7417820d-085c-4e8f-b135-3ce1242b2c94 None] Registering OS::Nova::Server::Cassandra -> file:///etc/heat/templates/cassandra_envir.yaml 2015-07-27 13:59:10.913 4665 INFO heat.engine.environment [req-7417820d-085c-4e8f-b135-3ce1242b2c94 None] Registering OS::Nova::Server::Cassandra -> file:///etc/heat/templates/cassandra2.yaml 2015-07-27 13:59:10.916 4665 INFO heat.engine.environment [req-7417820d-085c-4e8f-b135-3ce1242b2c94 None] Registering OS::Nova::Server::Cassandra -> file:///etc/heat/templates/single_instance.yaml 2015-07-27 13:59:11.014 4665 INFO heat.engine.stack [-] Stack CREATE IN_PROGRESS (cassandra_up_down_lb2): Stack CREATE started 2015-07-27 13:59:11.015 4665 INFO heat.engine.resource [-] creating HealthMonitor "monitor" Stack "cassandra_up_down_lb2" [fe2a4224-a82d-4da1-8b97-a0bf02a9bffd] 2015-07-27 13:59:11.129 4665 INFO heat.engine.resource [-] creating SecurityGroup "security_groups" Stack "cassandra_up_down_lb2" [fe2a4224-a82d-4da1-8b97-a0bf02a9bffd] 2015-07-27 13:59:11.645 4665 INFO heat.engine.resource [-] creating Port "lb_vip_port" Stack "cassandra_up_down_lb2" [fe2a4224-a82d-4da1-8b97-a0bf02a9bffd] 2015-07-27 13:59:12.831 4665 INFO heat.engine.environment [req-fcb6678c-bd7f-4edc-b257-234f1dd3d7b1 None] Registering OS::Nova::Server::Cassandra -> file:///etc/heat/templates/cassandra_envir.yaml 2015-07-27 13:59:12.835 4665 INFO heat.engine.environment [req-fcb6678c-bd7f-4edc-b257-234f1dd3d7b1 None] Registering OS::Nova::Server::Cassandra -> file:///etc/heat/templates/cassandra2.yaml 2015-07-27 13:59:12.838 4665 INFO heat.engine.environment [req-fcb6678c-bd7f-4edc-b257-234f1dd3d7b1 None] Registering OS::Nova::Server::Cassandra -> file:///etc/heat/templates/single_instance.yaml 2015-07-27 13:59:13.024 4665 INFO heat.engine.resource [-] creating FloatingIP "lb_vip_floating_ip" Stack "cassandra_up_down_lb2" [fe2a4224-a82d-4da1-8b97-a0bf02a9bffd] 2015-07-27 13:59:13.225 4665 INFO heat.engine.resource [-] creating Port "db_port" Stack "cassandra_up_down_lb2" [fe2a4224-a82d-4da1-8b97-a0bf02a9bffd] 2015-07-27 13:59:13.480 4665 INFO heat.engine.resource [-] creating Pool "pool" Stack "cassandra_up_down_lb2" [fe2a4224-a82d-4da1-8b97-a0bf02a9bffd] 2015-07-27 13:59:13.619 4665 INFO heat.engine.environment [req-263836d3-bdd3-4bc8-a990-af7dca34fbea None] Registering OS::Nova::Server::Cassandra -> file:///etc/heat/templates/cassandra_envir.yaml 2015-07-27 13:59:13.646 4665 INFO heat.engine.environment [req-d6dd8afd-e6a5-4224-8fea-993bdbc14609 None] Registering OS::Nova::Server::Cassandra -> file:///etc/heat/templates/cassandra_envir.yaml 2015-07-27 13:59:16.243 4665 INFO heat.engine.environment [req-43937ec1-9155-4c67-b511-0426efa89d2a None] Registering OS::Nova::Server::Cassandra -> file:///etc/heat/templates/cassandra_envir.yaml 2015-07-27 13:59:16.269 4665 INFO heat.engine.environment [req-e2fc1337-86a7-4b45-b6c1-f6a2f8265462 None] Registering OS::Nova::Server::Cassandra -> file:///etc/heat/templates/cassandra_envir.yaml 2015-07-27 13:59:18.318 4665 INFO heat.engine.resource [-] creating LoadBalancer "lb" Stack "cassandra_up_down_lb2" [fe2a4224-a82d-4da1-8b97-a0bf02a9bffd] 2015-07-27 13:59:18.331 4665 INFO heat.engine.resource [-] creating AutoScalingResourceGroup "group" Stack "cassandra_up_down_lb2" [fe2a4224-a82d-4da1-8b97-a0bf02a9bffd] 2015-07-27 13:59:18.345 4665 INFO heat.engine.environment [-] Registering OS::Heat::ScaledResource -> AWS::EC2::Instance 2015-07-27 13:59:18.347 4665 INFO heat.common.urlfetch [-] Fetching data from file:///etc/heat/templates/cassandra_envir.yaml 2015-07-27 13:59:18.351 4665 INFO heat.engine.resource [-] Validating OS::Nova::Server::Cassandra "fespxephgvg2" 2015-07-27 13:59:18.352 4665 INFO heat.engine.stack [-] Property error : fespxephgvg2: Property db_port not assigned 2015-07-27 13:59:18.352 4665 INFO heat.engine.resource [-] CREATE: AutoScalingResourceGroup "group" Stack "cassandra_up_down_lb2" [fe2a4224-a82d-4da1-8b97-a0bf02a9bffd] 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource Traceback (most recent call last): 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource File "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line 439, in _action_recorder 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource yield 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource File "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line 509, in _do_action 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource yield self.action_handler_task(action, args=handler_args) 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource File "/usr/lib/python2.7/site-packages/heat/engine/scheduler.py", line 286, in wrapper 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource step = next(subtask) 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource File "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line 480, in action_handler_task 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource handler_data = handler(*args) 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource File "/usr/lib/python2.7/site-packages/heat/engine/resources/autoscaling.py", line 573, in handle_create 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource self._environment()) 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource File "/usr/lib/python2.7/site-packages/heat/engine/stack_resource.py", line 203, in create_with_template 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource adopt_data) 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource File "/usr/lib/python2.7/site-packages/heat/engine/stack_resource.py", line 165, in _parse_nested_stack 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource nested.validate() 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource File "/usr/lib/python2.7/site-packages/heat/engine/stack.py", line 461, in validate 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource raise ex 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource StackValidationFailed: Property error : fespxephgvg2: Property db_port not assigned 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource 2015-07-27 13:59:19.389 4665 INFO heat.engine.stack [-] Stack CREATE FAILED (cassandra_up_down_lb2): Resource CREATE failed: StackValidationFailed: Property error : fespxephgvg2: Property db_port not assigned 2015-07-27 13:59:19.389 4665 INFO heat.engine.service [-] Stack create failed, status FAILED b.regards, Sara -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kevin.Fox at pnnl.gov Mon Jul 27 13:16:30 2015 From: Kevin.Fox at pnnl.gov (Fox, Kevin M) Date: Mon, 27 Jul 2015 13:16:30 +0000 Subject: [Rdo-list] [heat] assign securitu group to an autoscaling group In-Reply-To: References: Message-ID: <1A3C52DFCD06494D8528644858247BF01A2ADE15@EX10MBOX03.pnnl.gov> I dont think you can share one port across multiple servers. Usually its easiest to make the group a nested stack and pass things like security groups to it. Thanks, Kevin ________________________________ From: rdo-list-bounces at redhat.com on behalf of ICHIBA Sara Sent: Monday, July 27, 2015 5:14:16 AM To: rdo-list at redhat.com Subject: [Rdo-list] [heat] assign securitu group to an autoscaling group Hey there. When trying to assign a security group to an autoscaling groups i get some errors. I would really appreciate if you can help me. please find below the part of the template which describes the security groups and its usage + the associated logs. =======cassandra_scaling_up_down2.yaml resources: security_groups: type: OS::Neutron::SecurityGroup properties: name: security_groups rules: - protocol: tcp port_range_min: 8888 port_range_max: 8888 - protocol: tcp port_range_min: 7000 port_range_max: 7000 - protocol: tcp port_range_min: 7001 port_range_max: 7001 - protocol: icmp - protocol: tcp port_range_min: 22 port_range_max: 22 - protocol: tcp port_range_min: 7199 port_range_max: 7199 - protocol: tcp port_range_min: 9042 port_range_max: 9042 - protocol: tcp port_range_min: 9160 port_range_max: 9160 db_port: type: OS::Neutron::Port properties: network_id: { get_param: network } fixed_ips: - subnet_id: { get_param: subnet_id } security_groups: - {get_resource: security_groups} group: type: OS::Heat::AutoScalingGroup properties: cooldown: 60 desired_capacity: 1 max_size: 5 min_size: 1 resource: type: OS::Nova::Server::Cassandra properties: flavor: {get_param: flavor} image: {get_param: image} key_name: {get_param: key_name} networks: - port: {get_resource: db_port} ===========environment.cassandra.yaml resource_registry: "OS::Nova::Server::Cassandra": "cassandra_envir.yaml" ==========cassandra_envir.yaml resources: server: type: OS::Nova::Server properties: image: {get_param: image} flavor: {get_param: flavor} key_name: {get_param: key_name} networks: - port: { get_param: db_port } metadata: {get_param: metadata} user_data: {get_param: user_data} user_data_format: RAW ========/var/log/heat/heat- engine.log 2015-07-27 13:59:08.423 4665 INFO heat.engine.environment [req-ca831d72-de65-459e-b330-8d89646f522a None] Registering OS::Nova::Server::Cassandra -> file:///etc/heat/templates/cassandra_envir.yaml 2015-07-27 13:59:08.449 4665 INFO heat.engine.environment [req-f6dfcf2b-1936-4be1-b93f-c5cd151207e5 None] Registering OS::Nova::Server::Cassandra -> file:///etc/heat/templates/cassandra_envir.yaml 2015-07-27 13:59:10.678 4665 INFO heat.engine.service [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Creating stack cassandra_up_down_lb2 2015-07-27 13:59:10.695 4665 INFO heat.engine.environment [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Registering OS::Nova::Server::Cassandra -> file:///etc/heat/templates/cassandra_envir.yaml 2015-07-27 13:59:10.710 4665 INFO heat.engine.resource [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Validating HealthMonitor "monitor" 2015-07-27 13:59:10.711 4665 INFO heat.engine.resource [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Validating SecurityGroup "security_groups" 2015-07-27 13:59:10.714 4665 INFO heat.engine.resource [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Validating Port "lb_vip_port" 2015-07-27 13:59:10.715 4665 INFO heat.engine.resource [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Validating FloatingIP "lb_vip_floating_ip" 2015-07-27 13:59:10.715 4665 INFO heat.engine.resource [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Validating Port "db_port" 2015-07-27 13:59:10.716 4665 INFO heat.engine.resource [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Validating Pool "pool" 2015-07-27 13:59:10.717 4665 INFO heat.engine.resource [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Validating LoadBalancer "lb" 2015-07-27 13:59:10.718 4665 INFO heat.engine.resource [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Validating AutoScalingResourceGroup "group" 2015-07-27 13:59:10.719 4665 INFO heat.engine.resource [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Validating AutoScalingPolicy "scaledown_policy" 2015-07-27 13:59:10.719 4665 INFO heat.engine.resource [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Validating AutoScalingPolicy "scaleup_policy" 2015-07-27 13:59:10.720 4665 INFO heat.engine.resource [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Validating CeilometerAlarm "cpu_alarm_high" 2015-07-27 13:59:10.721 4665 INFO heat.engine.resource [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Validating CeilometerAlarm "cpu_alarm_low" 2015-07-27 13:59:10.722 4665 INFO heat.engine.resource [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Validating FloatingIPAssociation "lb_pool_vip" 2015-07-27 13:59:10.909 4665 INFO heat.engine.environment [req-7417820d-085c-4e8f-b135-3ce1242b2c94 None] Registering OS::Nova::Server::Cassandra -> file:///etc/heat/templates/cassandra_envir.yaml 2015-07-27 13:59:10.913 4665 INFO heat.engine.environment [req-7417820d-085c-4e8f-b135-3ce1242b2c94 None] Registering OS::Nova::Server::Cassandra -> file:///etc/heat/templates/cassandra2.yaml 2015-07-27 13:59:10.916 4665 INFO heat.engine.environment [req-7417820d-085c-4e8f-b135-3ce1242b2c94 None] Registering OS::Nova::Server::Cassandra -> file:///etc/heat/templates/single_instance.yaml 2015-07-27 13:59:11.014 4665 INFO heat.engine.stack [-] Stack CREATE IN_PROGRESS (cassandra_up_down_lb2): Stack CREATE started 2015-07-27 13:59:11.015 4665 INFO heat.engine.resource [-] creating HealthMonitor "monitor" Stack "cassandra_up_down_lb2" [fe2a4224-a82d-4da1-8b97-a0bf02a9bffd] 2015-07-27 13:59:11.129 4665 INFO heat.engine.resource [-] creating SecurityGroup "security_groups" Stack "cassandra_up_down_lb2" [fe2a4224-a82d-4da1-8b97-a0bf02a9bffd] 2015-07-27 13:59:11.645 4665 INFO heat.engine.resource [-] creating Port "lb_vip_port" Stack "cassandra_up_down_lb2" [fe2a4224-a82d-4da1-8b97-a0bf02a9bffd] 2015-07-27 13:59:12.831 4665 INFO heat.engine.environment [req-fcb6678c-bd7f-4edc-b257-234f1dd3d7b1 None] Registering OS::Nova::Server::Cassandra -> file:///etc/heat/templates/cassandra_envir.yaml 2015-07-27 13:59:12.835 4665 INFO heat.engine.environment [req-fcb6678c-bd7f-4edc-b257-234f1dd3d7b1 None] Registering OS::Nova::Server::Cassandra -> file:///etc/heat/templates/cassandra2.yaml 2015-07-27 13:59:12.838 4665 INFO heat.engine.environment [req-fcb6678c-bd7f-4edc-b257-234f1dd3d7b1 None] Registering OS::Nova::Server::Cassandra -> file:///etc/heat/templates/single_instance.yaml 2015-07-27 13:59:13.024 4665 INFO heat.engine.resource [-] creating FloatingIP "lb_vip_floating_ip" Stack "cassandra_up_down_lb2" [fe2a4224-a82d-4da1-8b97-a0bf02a9bffd] 2015-07-27 13:59:13.225 4665 INFO heat.engine.resource [-] creating Port "db_port" Stack "cassandra_up_down_lb2" [fe2a4224-a82d-4da1-8b97-a0bf02a9bffd] 2015-07-27 13:59:13.480 4665 INFO heat.engine.resource [-] creating Pool "pool" Stack "cassandra_up_down_lb2" [fe2a4224-a82d-4da1-8b97-a0bf02a9bffd] 2015-07-27 13:59:13.619 4665 INFO heat.engine.environment [req-263836d3-bdd3-4bc8-a990-af7dca34fbea None] Registering OS::Nova::Server::Cassandra -> file:///etc/heat/templates/cassandra_envir.yaml 2015-07-27 13:59:13.646 4665 INFO heat.engine.environment [req-d6dd8afd-e6a5-4224-8fea-993bdbc14609 None] Registering OS::Nova::Server::Cassandra -> file:///etc/heat/templates/cassandra_envir.yaml 2015-07-27 13:59:16.243 4665 INFO heat.engine.environment [req-43937ec1-9155-4c67-b511-0426efa89d2a None] Registering OS::Nova::Server::Cassandra -> file:///etc/heat/templates/cassandra_envir.yaml 2015-07-27 13:59:16.269 4665 INFO heat.engine.environment [req-e2fc1337-86a7-4b45-b6c1-f6a2f8265462 None] Registering OS::Nova::Server::Cassandra -> file:///etc/heat/templates/cassandra_envir.yaml 2015-07-27 13:59:18.318 4665 INFO heat.engine.resource [-] creating LoadBalancer "lb" Stack "cassandra_up_down_lb2" [fe2a4224-a82d-4da1-8b97-a0bf02a9bffd] 2015-07-27 13:59:18.331 4665 INFO heat.engine.resource [-] creating AutoScalingResourceGroup "group" Stack "cassandra_up_down_lb2" [fe2a4224-a82d-4da1-8b97-a0bf02a9bffd] 2015-07-27 13:59:18.345 4665 INFO heat.engine.environment [-] Registering OS::Heat::ScaledResource -> AWS::EC2::Instance 2015-07-27 13:59:18.347 4665 INFO heat.common.urlfetch [-] Fetching data from file:///etc/heat/templates/cassandra_envir.yaml 2015-07-27 13:59:18.351 4665 INFO heat.engine.resource [-] Validating OS::Nova::Server::Cassandra "fespxephgvg2" 2015-07-27 13:59:18.352 4665 INFO heat.engine.stack [-] Property error : fespxephgvg2: Property db_port not assigned 2015-07-27 13:59:18.352 4665 INFO heat.engine.resource [-] CREATE: AutoScalingResourceGroup "group" Stack "cassandra_up_down_lb2" [fe2a4224-a82d-4da1-8b97-a0bf02a9bffd] 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource Traceback (most recent call last): 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource File "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line 439, in _action_recorder 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource yield 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource File "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line 509, in _do_action 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource yield self.action_handler_task(action, args=handler_args) 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource File "/usr/lib/python2.7/site-packages/heat/engine/scheduler.py", line 286, in wrapper 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource step = next(subtask) 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource File "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line 480, in action_handler_task 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource handler_data = handler(*args) 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource File "/usr/lib/python2.7/site-packages/heat/engine/resources/autoscaling.py", line 573, in handle_create 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource self._environment()) 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource File "/usr/lib/python2.7/site-packages/heat/engine/stack_resource.py", line 203, in create_with_template 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource adopt_data) 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource File "/usr/lib/python2.7/site-packages/heat/engine/stack_resource.py", line 165, in _parse_nested_stack 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource nested.validate() 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource File "/usr/lib/python2.7/site-packages/heat/engine/stack.py", line 461, in validate 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource raise ex 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource StackValidationFailed: Property error : fespxephgvg2: Property db_port not assigned 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource 2015-07-27 13:59:19.389 4665 INFO heat.engine.stack [-] Stack CREATE FAILED (cassandra_up_down_lb2): Resource CREATE failed: StackValidationFailed: Property error : fespxephgvg2: Property db_port not assigned 2015-07-27 13:59:19.389 4665 INFO heat.engine.service [-] Stack create failed, status FAILED b.regards, Sara -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdo-info at redhat.com Mon Jul 27 14:47:43 2015 From: rdo-info at redhat.com (RDO Forum) Date: Mon, 27 Jul 2015 14:47:43 +0000 Subject: [Rdo-list] [RDO] RDO blog roundup, week of July 27, 2015 Message-ID: <0000014ecffbcede-a2f4ebf7-2893-4e44-9f38-30aaf1826c36-000000@email.amazonses.com> rbowen started a discussion. RDO blog roundup, week of July 27, 2015 --- Follow the link below to check it out: https://www.rdoproject.org/forum/discussion/1026/rdo-blog-roundup-week-of-july-27-2015 Have a great day! From hguemar at fedoraproject.org Mon Jul 27 15:00:03 2015 From: hguemar at fedoraproject.org (hguemar at fedoraproject.org) Date: Mon, 27 Jul 2015 15:00:03 +0000 (UTC) Subject: [Rdo-list] [Fedocal] Reminder meeting : RDO packaging meeting Message-ID: <20150727150003.4FCB060A4009@fedocal02.phx2.fedoraproject.org> Dear all, You are kindly invited to the meeting: RDO packaging meeting on 2015-07-29 from 15:00:00 to 16:00:00 UTC At rdo at irc.freenode.net The meeting will be about: RDO packaging irc meeting ([agenda](https://etherpad.openstack.org/p/RDO-Packaging)) Every week on #rdo on freenode Source: https://apps.fedoraproject.org/calendar/meeting/2017/ From rdo-info at redhat.com Mon Jul 27 19:44:36 2015 From: rdo-info at redhat.com (RDO Forum) Date: Mon, 27 Jul 2015 19:44:36 +0000 Subject: [Rdo-list] [RDO] Vote for OpenStack Summit Sessions Message-ID: <0000014ed10b9f88-5b3e06da-a260-4c49-bc1c-f9b8bcc98102-000000@email.amazonses.com> rbowen started a discussion. Vote for OpenStack Summit Sessions --- Follow the link below to check it out: https://www.rdoproject.org/forum/discussion/1027/vote-for-openstack-summit-sessions Have a great day! From sandro at mathys.io Tue Jul 28 05:49:53 2015 From: sandro at mathys.io (Sandro Mathys) Date: Tue, 28 Jul 2015 14:49:53 +0900 Subject: [Rdo-list] Integration of MidoNet into RDO Manager Message-ID: Dear all, We, the MidoNet Community [0], would like to integrate MidoNet into RDO Manager. Our resources are limited, so this won't happen over night - but we have to begin somewhere. Let's start with a few basics and questions. In case you haven't heard yet: MidoNet is a network virtualization software that plugs into OpenStack Neutron. While OpenStack is currently our main focus, it's not our only use case - but obviously the one we'll focus on here. Our packages are currently hosted in our very own repository [1]. Are packages hosted on the developer's repositories acceptable for integration into RDO Manager? We need to unbundle a couple of things (or maybe more than just a couple) before we can package them for inclusion into the proper repository. Speaking of repositories, once we're ready to package them properly for inclusion, which repository would be the (most?) proper one for RDO Manager? RDO? CentOS (wherever Cloud SIG packages go)? EPEL? So, are there any guidelines or such on how to get the integration process started? What (first) steps are necessary? What do we need to prepare? ... Cheers, Sandro MidoNet Community Manager [0] https://www.midonet.org/ [1] http://repo.midonet.org/ From ichi.sara at gmail.com Tue Jul 28 09:04:00 2015 From: ichi.sara at gmail.com (ICHIBA Sara) Date: Tue, 28 Jul 2015 11:04:00 +0200 Subject: [Rdo-list] [heat] assign securitu group to an autoscaling group In-Reply-To: References: <1A3C52DFCD06494D8528644858247BF01A2ADE15@EX10MBOX03.pnnl.gov> <1A3C52DFCD06494D8528644858247BF01A2ADFF8@EX10MBOX03.pnnl.gov> Message-ID: When I use the type OS::Heat::Stack inside of the OS::Heat:AutoScalingGroup I get the error Unknown type OS::Heat::Stack. By the way I'm using the version juno of RDO. Is there any other way to make this work?? If there is anyone else who can help please don't hesitate. You can find my templates attached. B.regards, Sara 2015-07-28 9:31 GMT+02:00 ICHIBA Sara : > Ok. I see. Thank you very much. I'll try it :) > > B.regards, > Sara > > 2015-07-27 18:37 GMT+02:00 Fox, Kevin M : > >> No, I mean, use the an OS::Heat::Stack as the type inside the >> AutoScaling group. >> >> http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Heat::Stack >> >> You can pass in params in like the security group, and inside the nested >> template, you can put the OS::Nova::Server, OS::Neutron::Port, any >> SoftwareConfig's, etc. >> >> Thanks, >> Kevin >> >> ------------------------------ >> *From:* ICHIBA Sara [ichi.sara at gmail.com] >> *Sent:* Monday, July 27, 2015 8:59 AM >> *To:* Fox, Kevin M >> *Subject:* Re: [Rdo-list] [heat] assign securitu group to an autoscaling >> group >> >> thank you Kevin for your response, >> What do you mean by making the group a nested stack ? if you suggest >> that I use a server of type OS::Nova::Server rather than an autoscaling >> group it won't be intersting for me any more as I'm looking for a method to >> scale cassandra. and I despperatly need a working method to configure the >> related security group and associate it with each server at the creation. >> >> thanks, >> sara >> >> 2015-07-27 15:16 GMT+02:00 Fox, Kevin M : >> >>> I dont think you can share one port across multiple servers. >>> >>> Usually its easiest to make the group a nested stack and pass things >>> like security groups to it. >>> >>> Thanks, >>> Kevin >>> >>> ------------------------------ >>> *From:* rdo-list-bounces at redhat.com on behalf of ICHIBA Sara >>> *Sent:* Monday, July 27, 2015 5:14:16 AM >>> *To:* rdo-list at redhat.com >>> *Subject:* [Rdo-list] [heat] assign securitu group to an autoscaling >>> group >>> >>> Hey there. When trying to assign a security group to an autoscaling >>> groups i get some errors. I would really appreciate if you can help me. >>> please find below the part of the template which describes the security >>> groups and its usage + the associated logs. >>> >>> >>> =======cassandra_scaling_up_down2.yaml >>> resources: >>> security_groups: >>> type: OS::Neutron::SecurityGroup >>> properties: >>> name: security_groups >>> rules: >>> - protocol: tcp >>> port_range_min: 8888 >>> port_range_max: 8888 >>> - protocol: tcp >>> port_range_min: 7000 >>> port_range_max: 7000 >>> - protocol: tcp >>> port_range_min: 7001 >>> port_range_max: 7001 >>> - protocol: icmp >>> - protocol: tcp >>> port_range_min: 22 >>> port_range_max: 22 >>> - protocol: tcp >>> port_range_min: 7199 >>> port_range_max: 7199 >>> - protocol: tcp >>> port_range_min: 9042 >>> port_range_max: 9042 >>> - protocol: tcp >>> port_range_min: 9160 >>> port_range_max: 9160 >>> db_port: >>> type: OS::Neutron::Port >>> properties: >>> network_id: { get_param: network } >>> fixed_ips: >>> - subnet_id: { get_param: subnet_id } >>> security_groups: >>> - {get_resource: security_groups} >>> >>> group: >>> type: OS::Heat::AutoScalingGroup >>> properties: >>> cooldown: 60 >>> desired_capacity: 1 >>> max_size: 5 >>> min_size: 1 >>> resource: >>> type: OS::Nova::Server::Cassandra >>> properties: >>> flavor: {get_param: flavor} >>> image: {get_param: image} >>> key_name: {get_param: key_name} >>> networks: >>> - port: {get_resource: db_port} >>> >>> >>> >>> >>> >>> ===========environment.cassandra.yaml >>> resource_registry: >>> "OS::Nova::Server::Cassandra": "cassandra_envir.yaml" >>> >>> >>> ==========cassandra_envir.yaml >>> resources: >>> server: >>> type: OS::Nova::Server >>> properties: >>> image: {get_param: image} >>> flavor: {get_param: flavor} >>> key_name: {get_param: key_name} >>> networks: >>> - port: { get_param: db_port } >>> metadata: {get_param: metadata} >>> user_data: {get_param: user_data} >>> user_data_format: RAW >>> >>> >>> ========/var/log/heat/heat- >>> engine.log >>> 2015-07-27 13:59:08.423 4665 INFO heat.engine.environment >>> [req-ca831d72-de65-459e-b330-8d89646f522a None] Registering >>> OS::Nova::Server::Cassandra -> >>> file:///etc/heat/templates/cassandra_envir.yaml >>> 2015-07-27 13:59:08.449 4665 INFO heat.engine.environment >>> [req-f6dfcf2b-1936-4be1-b93f-c5cd151207e5 None] Registering >>> OS::Nova::Server::Cassandra -> >>> file:///etc/heat/templates/cassandra_envir.yaml >>> 2015-07-27 13:59:10.678 4665 INFO heat.engine.service >>> [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Creating stack >>> cassandra_up_down_lb2 >>> 2015-07-27 13:59:10.695 4665 INFO heat.engine.environment >>> [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Registering >>> OS::Nova::Server::Cassandra -> >>> file:///etc/heat/templates/cassandra_envir.yaml >>> 2015-07-27 13:59:10.710 4665 INFO heat.engine.resource >>> [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Validating HealthMonitor >>> "monitor" >>> 2015-07-27 13:59:10.711 4665 INFO heat.engine.resource >>> [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Validating SecurityGroup >>> "security_groups" >>> 2015-07-27 13:59:10.714 4665 INFO heat.engine.resource >>> [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Validating Port >>> "lb_vip_port" >>> 2015-07-27 13:59:10.715 4665 INFO heat.engine.resource >>> [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Validating FloatingIP >>> "lb_vip_floating_ip" >>> 2015-07-27 13:59:10.715 4665 INFO heat.engine.resource >>> [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Validating Port "db_port" >>> 2015-07-27 13:59:10.716 4665 INFO heat.engine.resource >>> [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Validating Pool "pool" >>> 2015-07-27 13:59:10.717 4665 INFO heat.engine.resource >>> [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Validating LoadBalancer "lb" >>> 2015-07-27 13:59:10.718 4665 INFO heat.engine.resource >>> [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Validating >>> AutoScalingResourceGroup "group" >>> 2015-07-27 13:59:10.719 4665 INFO heat.engine.resource >>> [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Validating >>> AutoScalingPolicy "scaledown_policy" >>> 2015-07-27 13:59:10.719 4665 INFO heat.engine.resource >>> [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Validating >>> AutoScalingPolicy "scaleup_policy" >>> 2015-07-27 13:59:10.720 4665 INFO heat.engine.resource >>> [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Validating CeilometerAlarm >>> "cpu_alarm_high" >>> 2015-07-27 13:59:10.721 4665 INFO heat.engine.resource >>> [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Validating CeilometerAlarm >>> "cpu_alarm_low" >>> 2015-07-27 13:59:10.722 4665 INFO heat.engine.resource >>> [req-d240c68d-3be5-4254-b6bf-fc9dbca09bb6 None] Validating >>> FloatingIPAssociation "lb_pool_vip" >>> 2015-07-27 13:59:10.909 4665 INFO heat.engine.environment >>> [req-7417820d-085c-4e8f-b135-3ce1242b2c94 None] Registering >>> OS::Nova::Server::Cassandra -> >>> file:///etc/heat/templates/cassandra_envir.yaml >>> 2015-07-27 13:59:10.913 4665 INFO heat.engine.environment >>> [req-7417820d-085c-4e8f-b135-3ce1242b2c94 None] Registering >>> OS::Nova::Server::Cassandra -> file:///etc/heat/templates/cassandra2.yaml >>> 2015-07-27 13:59:10.916 4665 INFO heat.engine.environment >>> [req-7417820d-085c-4e8f-b135-3ce1242b2c94 None] Registering >>> OS::Nova::Server::Cassandra -> >>> file:///etc/heat/templates/single_instance.yaml >>> 2015-07-27 13:59:11.014 4665 INFO heat.engine.stack [-] Stack CREATE >>> IN_PROGRESS (cassandra_up_down_lb2): Stack CREATE started >>> 2015-07-27 13:59:11.015 4665 INFO heat.engine.resource [-] creating >>> HealthMonitor "monitor" Stack "cassandra_up_down_lb2" >>> [fe2a4224-a82d-4da1-8b97-a0bf02a9bffd] >>> 2015-07-27 13:59:11.129 4665 INFO heat.engine.resource [-] creating >>> SecurityGroup "security_groups" Stack "cassandra_up_down_lb2" >>> [fe2a4224-a82d-4da1-8b97-a0bf02a9bffd] >>> 2015-07-27 13:59:11.645 4665 INFO heat.engine.resource [-] creating Port >>> "lb_vip_port" Stack "cassandra_up_down_lb2" >>> [fe2a4224-a82d-4da1-8b97-a0bf02a9bffd] >>> 2015-07-27 13:59:12.831 4665 INFO heat.engine.environment >>> [req-fcb6678c-bd7f-4edc-b257-234f1dd3d7b1 None] Registering >>> OS::Nova::Server::Cassandra -> >>> file:///etc/heat/templates/cassandra_envir.yaml >>> 2015-07-27 13:59:12.835 4665 INFO heat.engine.environment >>> [req-fcb6678c-bd7f-4edc-b257-234f1dd3d7b1 None] Registering >>> OS::Nova::Server::Cassandra -> file:///etc/heat/templates/cassandra2.yaml >>> 2015-07-27 13:59:12.838 4665 INFO heat.engine.environment >>> [req-fcb6678c-bd7f-4edc-b257-234f1dd3d7b1 None] Registering >>> OS::Nova::Server::Cassandra -> >>> file:///etc/heat/templates/single_instance.yaml >>> 2015-07-27 13:59:13.024 4665 INFO heat.engine.resource [-] creating >>> FloatingIP "lb_vip_floating_ip" Stack "cassandra_up_down_lb2" >>> [fe2a4224-a82d-4da1-8b97-a0bf02a9bffd] >>> 2015-07-27 13:59:13.225 4665 INFO heat.engine.resource [-] creating Port >>> "db_port" Stack "cassandra_up_down_lb2" >>> [fe2a4224-a82d-4da1-8b97-a0bf02a9bffd] >>> 2015-07-27 13:59:13.480 4665 INFO heat.engine.resource [-] creating Pool >>> "pool" Stack "cassandra_up_down_lb2" [fe2a4224-a82d-4da1-8b97-a0bf02a9bffd] >>> 2015-07-27 13:59:13.619 4665 INFO heat.engine.environment >>> [req-263836d3-bdd3-4bc8-a990-af7dca34fbea None] Registering >>> OS::Nova::Server::Cassandra -> >>> file:///etc/heat/templates/cassandra_envir.yaml >>> 2015-07-27 13:59:13.646 4665 INFO heat.engine.environment >>> [req-d6dd8afd-e6a5-4224-8fea-993bdbc14609 None] Registering >>> OS::Nova::Server::Cassandra -> >>> file:///etc/heat/templates/cassandra_envir.yaml >>> 2015-07-27 13:59:16.243 4665 INFO heat.engine.environment >>> [req-43937ec1-9155-4c67-b511-0426efa89d2a None] Registering >>> OS::Nova::Server::Cassandra -> >>> file:///etc/heat/templates/cassandra_envir.yaml >>> 2015-07-27 13:59:16.269 4665 INFO heat.engine.environment >>> [req-e2fc1337-86a7-4b45-b6c1-f6a2f8265462 None] Registering >>> OS::Nova::Server::Cassandra -> >>> file:///etc/heat/templates/cassandra_envir.yaml >>> 2015-07-27 13:59:18.318 4665 INFO heat.engine.resource [-] creating >>> LoadBalancer "lb" Stack "cassandra_up_down_lb2" >>> [fe2a4224-a82d-4da1-8b97-a0bf02a9bffd] >>> 2015-07-27 13:59:18.331 4665 INFO heat.engine.resource [-] creating >>> AutoScalingResourceGroup "group" Stack "cassandra_up_down_lb2" >>> [fe2a4224-a82d-4da1-8b97-a0bf02a9bffd] >>> 2015-07-27 13:59:18.345 4665 INFO heat.engine.environment [-] >>> Registering OS::Heat::ScaledResource -> AWS::EC2::Instance >>> 2015-07-27 13:59:18.347 4665 INFO heat.common.urlfetch [-] Fetching data >>> from file:///etc/heat/templates/cassandra_envir.yaml >>> 2015-07-27 13:59:18.351 4665 INFO heat.engine.resource [-] Validating >>> OS::Nova::Server::Cassandra "fespxephgvg2" >>> 2015-07-27 13:59:18.352 4665 INFO heat.engine.stack [-] Property error : >>> fespxephgvg2: Property db_port not assigned >>> 2015-07-27 13:59:18.352 4665 INFO heat.engine.resource [-] CREATE: >>> AutoScalingResourceGroup "group" Stack "cassandra_up_down_lb2" >>> [fe2a4224-a82d-4da1-8b97-a0bf02a9bffd] >>> 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource Traceback (most >>> recent call last): >>> 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource File >>> "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line 439, in >>> _action_recorder >>> 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource yield >>> 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource File >>> "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line 509, in >>> _do_action >>> 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource yield >>> self.action_handler_task(action, args=handler_args) >>> 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource File >>> "/usr/lib/python2.7/site-packages/heat/engine/scheduler.py", line 286, in >>> wrapper >>> 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource step = >>> next(subtask) >>> 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource File >>> "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line 480, in >>> action_handler_task >>> 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource handler_data >>> = handler(*args) >>> 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource File >>> "/usr/lib/python2.7/site-packages/heat/engine/resources/autoscaling.py", >>> line 573, in handle_create >>> 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource >>> self._environment()) >>> 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource File >>> "/usr/lib/python2.7/site-packages/heat/engine/stack_resource.py", line 203, >>> in create_with_template >>> 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource adopt_data) >>> 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource File >>> "/usr/lib/python2.7/site-packages/heat/engine/stack_resource.py", line 165, >>> in _parse_nested_stack >>> 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource >>> nested.validate() >>> 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource File >>> "/usr/lib/python2.7/site-packages/heat/engine/stack.py", line 461, in >>> validate >>> 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource raise ex >>> 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource >>> StackValidationFailed: Property error : fespxephgvg2: Property db_port not >>> assigned >>> 2015-07-27 13:59:18.352 4665 TRACE heat.engine.resource >>> 2015-07-27 13:59:19.389 4665 INFO heat.engine.stack [-] Stack CREATE >>> FAILED (cassandra_up_down_lb2): Resource CREATE failed: >>> StackValidationFailed: Property error : fespxephgvg2: Property db_port not >>> assigned >>> 2015-07-27 13:59:19.389 4665 INFO heat.engine.service [-] Stack create >>> failed, status FAILED >>> >>> b.regards, >>> Sara >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cassandra_envir.yaml Type: application/octet-stream Size: 2646 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: heat_stack_cassandra.yaml Type: application/octet-stream Size: 3526 bytes Desc: not available URL: From ayoung at redhat.com Tue Jul 28 13:59:36 2015 From: ayoung at redhat.com (Adam Young) Date: Tue, 28 Jul 2015 09:59:36 -0400 Subject: [Rdo-list] Integration of MidoNet into RDO Manager In-Reply-To: References: Message-ID: <55B78AC8.2080905@redhat.com> On 07/28/2015 01:49 AM, Sandro Mathys wrote: > Dear all, > > We, the MidoNet Community [0], would like to integrate MidoNet into > RDO Manager. Our resources are limited, so this won't happen over > night - but we have to begin somewhere. Let's start with a few basics > and questions. > > In case you haven't heard yet: MidoNet is a network virtualization > software that plugs into OpenStack Neutron. While OpenStack is > currently our main focus, it's not our only use case - but obviously > the one we'll focus on here. Our packages are currently hosted in our > very own repository [1]. Looks like an APT repo; I see no SRPMS in http://repo.midonet.org/openstack-kilo/RHEL/7/unstable/SRPMS/ I don't see sources for the .debs either. You probably want to get those published; just linking to the git repo is not sufficient as people need to be able to rebuild the binary packages. > > Are packages hosted on the developer's repositories acceptable for > integration into RDO Manager? We need to unbundle a couple of things > (or maybe more than just a couple) before we can package them for > inclusion into the proper repository. Typically, using a COPR is just a transition step to getting packages into Fedora; RDO very much follows the Fedora model. The individual packages themselves must be submitted, reviewed, and maintained. RDO manager is the last step of the process, and will only work with RDOmanaged packages. > > Speaking of repositories, once we're ready to package them properly > for inclusion, which repository would be the (most?) proper one for > RDO Manager? RDO? CentOS (wherever Cloud SIG packages go)? EPEL? Its usually easiest to start with Fedora for all packaging. Once they are accepted into Fedora, figuring out how to get them into the appropriate other locations will follow. Thus far, RDO manager has been focused on upstream OpenStack and the necessary pieces from the base OS that need to be updated to support it. While it should be possible to have an add-on like MidoNet, I don't know how the rest of the community would feel about it being required to be part of RDO. My thought is that, so long as it A) is under a sufficient license and B) provides real value beyond what is available from Neutron, it should be possible to include, so long as including it does not impact people currently developing and deploying RDO. Is there any move to get MidoNet into upstream OpenStack? > > So, are there any guidelines or such on how to get the integration > process started? What (first) steps are necessary? What do we need to > prepare? ... > > Cheers, > Sandro > MidoNet Community Manager > > [0] https://www.midonet.org/ > [1] http://repo.midonet.org/ > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com From sgordon at redhat.com Tue Jul 28 15:27:52 2015 From: sgordon at redhat.com (Steve Gordon) Date: Tue, 28 Jul 2015 11:27:52 -0400 (EDT) Subject: [Rdo-list] Integration of MidoNet into RDO Manager In-Reply-To: <55B78AC8.2080905@redhat.com> References: <55B78AC8.2080905@redhat.com> Message-ID: <887285868.1756758.1438097272315.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Adam Young" > To: rdo-list at redhat.com > > On 07/28/2015 01:49 AM, Sandro Mathys wrote: > > Dear all, > > > > We, the MidoNet Community [0], would like to integrate MidoNet into > > RDO Manager. Our resources are limited, so this won't happen over > > night - but we have to begin somewhere. Let's start with a few basics > > and questions. > > > > In case you haven't heard yet: MidoNet is a network virtualization > > software that plugs into OpenStack Neutron. While OpenStack is > > currently our main focus, it's not our only use case - but obviously > > the one we'll focus on here. Our packages are currently hosted in our > > very own repository [1]. > Looks like an APT repo; I see no SRPMS in > > http://repo.midonet.org/openstack-kilo/RHEL/7/unstable/SRPMS/ > > I don't see sources for the .debs either. You probably want to get > those published; just linking to the git repo is not sufficient as > people need to be able to rebuild the binary packages. > > > > > Are packages hosted on the developer's repositories acceptable for > > integration into RDO Manager? We need to unbundle a couple of things > > (or maybe more than just a couple) before we can package them for > > inclusion into the proper repository. > Typically, using a COPR is just a transition step to getting packages > into Fedora; RDO very much follows the Fedora model. > > The individual packages themselves must be submitted, reviewed, and > maintained. RDO manager is the last step of the process, and will only > work with RDOmanaged packages. > > > > > > Speaking of repositories, once we're ready to package them properly > > for inclusion, which repository would be the (most?) proper one for > > RDO Manager? RDO? CentOS (wherever Cloud SIG packages go)? EPEL? > Its usually easiest to start with Fedora for all packaging. Once they > are accepted into Fedora, figuring out how to get them into the > appropriate other locations will follow. > > > Thus far, RDO manager has been focused on upstream OpenStack and the > necessary pieces from the base OS that need to be updated to support > it. While it should be possible to have an add-on like MidoNet, I don't > know how the rest of the community would feel about it being required to > be part of RDO. My thought is that, so long as it A) is under a > sufficient license and B) provides real value beyond what is available > from Neutron, it should be possible to include, so long as including it > does not impact people currently developing and deploying RDO. > > > Is there any move to get MidoNet into upstream OpenStack? Aren't we talking about the midonet neutron plug-in which was already part of neutron-proper but as a result of the plug-in decomposition effort now has it's own repo under the openstack namespace ( http://git.openstack.org/cgit/openstack/networking-midonet/ ). I'm really unclear on what the issue is here versus other RDO-Manager integration efforts - perhaps you can clarify? Thanks, Steve From rbowen at redhat.com Tue Jul 28 16:53:11 2015 From: rbowen at redhat.com (Rich Bowen) Date: Tue, 28 Jul 2015 12:53:11 -0400 Subject: [Rdo-list] OpenStack Meetups this week Message-ID: <55B7B377.6030307@redhat.com> The following are the meetups I'm aware of in the coming week where OpenStack and/or RDO enthusiasts are likely to be present. If you know of others, please let me know, and/or add them to http://rdoproject.org/Events If there's a meetup in your area, please consider attending. If you attend, please consider taking a few photos, and possibly even writing up a brief summary of what was covered. --Rich * Tue Jul 28 in Austin, TX, US: OpenStack 5th Birthday & BoD Mingle - http://www.meetup.com/OpenStack-Austin/events/223604418/ * Wed Jul 29 in Vancouver, BC, CA: PaaS and Cloud Foundry on OpenStack + demo! - http://www.meetup.com/Vancouver-OpenStack-Meetup/events/223943406/ * Wed Jul 29 in San Francisco, CA, US: SFBay OpenStack #OSSFO Topic: Continuous Infrastructure Insights - http://www.meetup.com/openstack/events/223909078/ * Wed Jul 29 in Santa Ana, CA, US: Come learn about Cloud-Native Apps with Cloud Foundry and OpenStack. - http://www.meetup.com/Orange-County-Cloud-Foundry-Meetup/events/223460422/ * Wed Jul 29 in Frederick, MD, US: Work to help people or businesses understand Openstack and Cloud services - http://www.meetup.com/Frederick-MD-OpenStack-Meetup/events/223318157/ * Wed Jul 29 in Taipei, TW: OpenStack Operation Guide ??? - http://www.meetup.com/OpenStack-Taiwan-User-Group/events/224224125/ * Sat Aug 1 in Beijing, CN: ?OpenStack+??????? ???????? ?Hosted by EasyStack? - http://www.meetup.com/China-OpenStack-User-Group/events/224145242/ * Sun Aug 2 in Sydney, AU: OpenStack UnSummit onSummit = SKI TIME! - http://www.meetup.com/Australian-OpenStack-User-Group/events/222951377/ -- Rich Bowen - rbowen at redhat.com OpenStack Community Liaison http://rdoproject.org/ From hguemar at fedoraproject.org Tue Jul 28 18:35:21 2015 From: hguemar at fedoraproject.org (=?UTF-8?Q?Ha=C3=AFkel?=) Date: Tue, 28 Jul 2015 20:35:21 +0200 Subject: [Rdo-list] Integration of MidoNet into RDO Manager In-Reply-To: <887285868.1756758.1438097272315.JavaMail.zimbra@redhat.com> References: <55B78AC8.2080905@redhat.com> <887285868.1756758.1438097272315.JavaMail.zimbra@redhat.com> Message-ID: I don't know much about MidoNet, but in order to get accepted in RDO 1. licensing should be compatible with RDO 2. it has to be an upstreamed effort 3. an identified maintainer (RDO Eng. will focus on maintaining "core" projects, and we won't be maintaining all neutron drivers) 4. provide packages conforming Fedora guidelines 5. take responsibility for CI As far as these conditions are respected, there should be no problems in accepting MidoNet in RDO. In brief, what we require is commitment and taking responsibility of contributed packages. Sandro, we'll both be at Flock in few weeks, so I'll be glad to discuss with you about it. Regards, H. From ichi.sara at gmail.com Wed Jul 29 13:42:01 2015 From: ichi.sara at gmail.com (ICHIBA Sara) Date: Wed, 29 Jul 2015 15:42:01 +0200 Subject: [Rdo-list] [Heat] scaledown action Message-ID: Hey there, is there anyway I can hand over a script to heat to do some cleaning after a scaledown action? Thank you for your response, Sara -------------- next part -------------- An HTML attachment was scrubbed... URL: From apevec at gmail.com Wed Jul 29 15:38:01 2015 From: apevec at gmail.com (Alan Pevec) Date: Wed, 29 Jul 2015 17:38:01 +0200 Subject: [Rdo-list] [meeting] RDO packaging meeting minutes (2015-07-29) Message-ID: ======================================== #rdo: RDO packaging meeting (2015-07-29) ======================================== Meeting started by apevec at 15:03:01 UTC. The full logs are available at http://meetbot.fedoraproject.org/rdo/2015-07-29/rdo.2015-07-29-15.03.log.html . Meeting summary --------------- * roll call (apevec, 15:03:13) * Agenda at https://etherpad.openstack.org/p/RDO-Packaging (apevec, 15:03:59) * LINK: https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting#Chair_rotation (apevec, 15:05:47) * Delorean Liberty CI status (apevec, 15:10:23) * manual testing revealed missing dependencies (apevec, 15:10:31) * ACTION: apevec to ask help from nova folks to debug compute cannot connect to conductor issue in delorean liberty repo (apevec, 15:12:22) * ACTION: gchamoul to rebase puppet 4.2.1 in f23 (apevec, 15:17:08) * ACTION: gchamoul to decide rebase vs backport for puppet in f22 (apevec, 15:17:24) * LINK: http://paste.fedoraproject.org/249432/14381830 (social, 15:17:49) * RDO-update CI failures (apevec, 15:20:42) * ACTION: apevec to followup w/ weshay and eggmaster re. move rdo-update CI to public jenkins (apevec, 15:22:51) * open floor (apevec, 15:23:05) Meeting ended at 15:25:45 UTC. Action Items ------------ * apevec to ask help from nova folks to debug compute cannot connect to conductor issue in delorean liberty repo * gchamoul to rebase puppet 4.2.1 in f23 * gchamoul to decide rebase vs backport for puppet in f22 * apevec to followup w/ weshay and eggmaster re. move rdo-update CI to public jenkins Action Items, by person ----------------------- * apevec * apevec to ask help from nova folks to debug compute cannot connect to conductor issue in delorean liberty repo * apevec to followup w/ weshay and eggmaster re. move rdo-update CI to public jenkins * gchamoul * gchamoul to rebase puppet 4.2.1 in f23 * gchamoul to decide rebase vs backport for puppet in f22 * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * apevec (57) * social (10) * zodbot (7) * rbowen (5) * gchamoul (2) * trown (1) * dtantsur (1) * chandankumar (1) * jruzicka (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot From sandro at mathys.io Thu Jul 30 09:44:05 2015 From: sandro at mathys.io (Sandro Mathys) Date: Thu, 30 Jul 2015 18:44:05 +0900 Subject: [Rdo-list] Integration of MidoNet into RDO Manager In-Reply-To: References: <55B78AC8.2080905@redhat.com> <887285868.1756758.1438097272315.JavaMail.zimbra@redhat.com> Message-ID: Thanks for your replies. On Wed, Jul 29, 2015 at 12:27 AM, Steve Gordon wrote: > ----- Original Message ----- >> From: "Adam Young" >> To: rdo-list at redhat.com >> >> On 07/28/2015 01:49 AM, Sandro Mathys wrote: >> > Dear all, >> > >> > We, the MidoNet Community [0], would like to integrate MidoNet into >> > RDO Manager. Our resources are limited, so this won't happen over >> > night - but we have to begin somewhere. Let's start with a few basics >> > and questions. >> > >> > In case you haven't heard yet: MidoNet is a network virtualization >> > software that plugs into OpenStack Neutron. While OpenStack is >> > currently our main focus, it's not our only use case - but obviously >> > the one we'll focus on here. Our packages are currently hosted in our >> > very own repository [1]. >> Looks like an APT repo; I see no SRPMS in >> >> http://repo.midonet.org/openstack-kilo/RHEL/7/unstable/SRPMS/ >> >> I don't see sources for the .debs either. You probably want to get >> those published; just linking to the git repo is not sufficient as >> people need to be able to rebuild the binary packages. It's combined APT and RPM, but you're right, there's currently no source packages for either. Out of curiosity, why do people need to be able to rebuild them (in the scenario we're discussing - integrating MidoNet with RDO Manager)? >> > >> > Are packages hosted on the developer's repositories acceptable for >> > integration into RDO Manager? We need to unbundle a couple of things >> > (or maybe more than just a couple) before we can package them for >> > inclusion into the proper repository. >> Typically, using a COPR is just a transition step to getting packages >> into Fedora; RDO very much follows the Fedora model. >> >> The individual packages themselves must be submitted, reviewed, and >> maintained. RDO manager is the last step of the process, and will only >> work with RDOmanaged packages. So all our packages would have to be part of the RDO repository (which I trust follows the EPEL/Fedora Guidelines)? >> > Speaking of repositories, once we're ready to package them properly >> > for inclusion, which repository would be the (most?) proper one for >> > RDO Manager? RDO? CentOS (wherever Cloud SIG packages go)? EPEL? >> Its usually easiest to start with Fedora for all packaging. Once they >> are accepted into Fedora, figuring out how to get them into the >> appropriate other locations will follow. Well, for our packages, Fedora and EL would be fairly different. The MidoNet core is written in Java/Scala, so much more (tools, deps) is missing from EL, e.g. gradle and of course lots of artifacts. So we should target EPEL, I guess. >> Thus far, RDO manager has been focused on upstream OpenStack and the >> necessary pieces from the base OS that need to be updated to support >> it. While it should be possible to have an add-on like MidoNet, I don't >> know how the rest of the community would feel about it being required to >> be part of RDO. My thought is that, so long as it A) is under a >> sufficient license and B) provides real value beyond what is available >> from Neutron, it should be possible to include, so long as including it >> does not impact people currently developing and deploying RDO. >> >> >> Is there any move to get MidoNet into upstream OpenStack? > > Aren't we talking about the midonet neutron plug-in which was already part of neutron-proper but as a result of the plug-in decomposition effort now has it's own repo under the openstack namespace ( http://git.openstack.org/cgit/openstack/networking-midonet/ ). I'm really unclear on what the issue is here versus other RDO-Manager integration efforts - perhaps you can clarify? Yes, that's what we're talking about, thanks for providing the reference :) However, I'm a bit confused now - surely, integration would not just include the plugin but also the SDN solution the plugin is leveraging, right? > Thanks, > > Steve > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com On Wed, Jul 29, 2015 at 3:35 AM, Ha?kel wrote: > I don't know much about MidoNet, but in order to get accepted in RDO > > 1. licensing should be compatible with RDO Apache Software License 2.0 > 2. it has to be an upstreamed effort Like with most Neutron plugins, the plugin itself is upstream but the rest isn't. Neutron MidoNet Plugin (as shared by Steve above already): http://git.openstack.org/cgit/openstack/networking-midonet/ MidoNet: https://github.com/midonet/midonet/ > 3. an identified maintainer (RDO Eng. will focus on maintaining "core" > projects, and we won't be maintaining all neutron drivers) That should be no problem. Does this have to be a single person or can it be a team? > 4. provide packages conforming Fedora guidelines Okay, so - as Adam and Steve already hinted - non-conforming packages (hosted on our own repo) are not acceptable then? Our biggest headache right now (like with any Java software) in terms of the Fedora Packaging Guidelines are tons of bundled jars - so that would be a no-go, right? > 5. take responsibility for CI Of course. > As far as these conditions are respected, there should be no problems > in accepting MidoNet in RDO. Getting all these deps packaged will really be a major effort so if that's required, it will take a while. Otherwise, I see no obstacles :) > In brief, what we require is commitment and taking responsibility of > contributed packages. Sure, that's in our best interest anyway :) > Sandro, we'll both be at Flock in few weeks, so I'll be glad to > discuss with you about it. Sure, let's do that :) Cheers, Sandro > Regards, > H. > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com From hguemar at fedoraproject.org Thu Jul 30 10:39:15 2015 From: hguemar at fedoraproject.org (=?UTF-8?Q?Ha=C3=AFkel?=) Date: Thu, 30 Jul 2015 12:39:15 +0200 Subject: [Rdo-list] Integration of MidoNet into RDO Manager In-Reply-To: References: <55B78AC8.2080905@redhat.com> <887285868.1756758.1438097272315.JavaMail.zimbra@redhat.com> Message-ID: > That should be no problem. Does this have to be a single person or can it be a team? fine with me > Our biggest headache right now (like with any Java software) in terms of the Fedora Packaging Guidelines are tons of bundled jars - so that would be a no-go, right? Currently, yes, but it'll change in the near future. Starting Mitaka, we're considering to switch over CentOS dist-git as our main source for packaging and we'll be able to provide bundling libraries exception for RDO packages. I plan to discuss at Flock with bstinson and kbsingh about our plans, and how to enable contributors to have access to git & build system safely. We don't have yet a reviewing process for such packages but it's mostly a matter of timing. Only clients and oslo libraries will be shipped in Fedora 24, Fedora users could still use RDO Delorean packages (which are unsigned). Regards, H. From pmyers at redhat.com Thu Jul 30 11:14:54 2015 From: pmyers at redhat.com (Perry Myers) Date: Thu, 30 Jul 2015 07:14:54 -0400 Subject: [Rdo-list] Integration of MidoNet into RDO Manager In-Reply-To: References: <55B78AC8.2080905@redhat.com> <887285868.1756758.1438097272315.JavaMail.zimbra@redhat.com> Message-ID: <55BA072E.4000807@redhat.com> > It's combined APT and RPM, but you're right, there's currently no > source packages for either. > > Out of curiosity, why do people need to be able to rebuild them (in > the scenario we're discussing - integrating MidoNet with RDO Manager)? I don't think they strictly need this ability. Providing packages that are rebuildable by the community is a nice thing to do, but it shouldn't be a strict requirement in a case like this, I believe. If anything I'd focus on providing a rebuildable RPM for the Neutron plugin itself, but perhaps skip that for the SDN solution that is paired with it. >>>> >>>> Are packages hosted on the developer's repositories acceptable for >>>> integration into RDO Manager? We need to unbundle a couple of things >>>> (or maybe more than just a couple) before we can package them for >>>> inclusion into the proper repository. >>> Typically, using a COPR is just a transition step to getting packages >>> into Fedora; RDO very much follows the Fedora model. >>> >>> The individual packages themselves must be submitted, reviewed, and >>> maintained. RDO manager is the last step of the process, and will only >>> work with RDOmanaged packages. > > So all our packages would have to be part of the RDO repository (which > I trust follows the EPEL/Fedora Guidelines)? I think having the packages part of a repo available on RDO would make the end user experience a lot easier, but I don't think there is/should be a strict requirement that anything integrated with RDO and RDO Manager _must_ be hosted on the RDO site. We might want to differentiate between (for example) the Neutron plugin packages and the SDN solution, for that. I also want to make sure folks understand that I don't think that getting packages like this 'into Fedora' should be a requirement. Right now we are tied to getting things into Fedora since we don't have another place to host spec files, etc, but we're working on decoupling from this so that we can move to a model where we are 'on Fedora' instead of 'in Fedora' But to the extent that we can, we try to follow Fedora packaging guidelines as a best practice, but can/will make exceptions where it makes sense. >>>> Speaking of repositories, once we're ready to package them properly >>>> for inclusion, which repository would be the (most?) proper one for >>>> RDO Manager? RDO? CentOS (wherever Cloud SIG packages go)? EPEL? >>> Its usually easiest to start with Fedora for all packaging. Once they >>> are accepted into Fedora, figuring out how to get them into the >>> appropriate other locations will follow. > > Well, for our packages, Fedora and EL would be fairly different. The > MidoNet core is written in Java/Scala, so much more (tools, deps) is > missing from EL, e.g. gradle and of course lots of artifacts. So we > should target EPEL, I guess. I wouldn't follow Adam's advice here (starting with Fedora). Especially for the SDN solution which is Java based. That would lead to a lot of pain and overhead. >>> Thus far, RDO manager has been focused on upstream OpenStack and the >>> necessary pieces from the base OS that need to be updated to support >>> it. While it should be possible to have an add-on like MidoNet, I don't >>> know how the rest of the community would feel about it being required to >>> be part of RDO. My thought is that, so long as it A) is under a >>> sufficient license and B) provides real value beyond what is available >>> from Neutron, it should be possible to include, so long as including it >>> does not impact people currently developing and deploying RDO. >>> >>> >>> Is there any move to get MidoNet into upstream OpenStack? >> >> Aren't we talking about the midonet neutron plug-in which was already part of neutron-proper but as a result of the plug-in decomposition effort now has it's own repo under the openstack namespace ( http://git.openstack.org/cgit/openstack/networking-midonet/ ). I'm really unclear on what the issue is here versus other RDO-Manager integration efforts - perhaps you can clarify? > > Yes, that's what we're talking about, thanks for providing the reference :) > > However, I'm a bit confused now - surely, integration would not just > include the plugin but also the SDN solution the plugin is leveraging, > right? That's actually a good question. I think typically we've been thinking about integration of the plugin only, because that is co-located on compute nodes and there might be controller node software that needs to be bundled for certain SDN solutions as well. But I can see where deployment of the SDN solution itself by RDO Manager could be very useful and would make the end user experience much easier. But I'd have to defer to folks on that team as to how and if this could be done :) >> Thanks, >> >> Steve >> > > On Wed, Jul 29, 2015 at 3:35 AM, Ha?kel wrote: >> I don't know much about MidoNet, but in order to get accepted in RDO >> >> 1. licensing should be compatible with RDO > > Apache Software License 2.0 > >> 2. it has to be an upstreamed effort > > Like with most Neutron plugins, the plugin itself is upstream but the > rest isn't. > > Neutron MidoNet Plugin (as shared by Steve above already): > http://git.openstack.org/cgit/openstack/networking-midonet/ > > MidoNet: > https://github.com/midonet/midonet/ > > >> 3. an identified maintainer (RDO Eng. will focus on maintaining "core" >> projects, and we won't be maintaining all neutron drivers) > > That should be no problem. Does this have to be a single person or can > it be a team? A single person can be a team :) >> 4. provide packages conforming Fedora guidelines > > Okay, so - as Adam and Steve already hinted - non-conforming packages > (hosted on our own repo) are not acceptable then? Our biggest headache > right now (like with any Java software) in terms of the Fedora > Packaging Guidelines are tons of bundled jars - so that would be a > no-go, right? I think we need to relax the requirements on #4 here. For the Neutron plugin, I think we can/should conform to Fedora packaging guidelines, and definitely get that package hosted on RDO directly. For the SDN solution in Java, I think we should either allow: * Relaxed packaging guidelines, recognizing that this is an SDN solution, and we host Midonet RPMs on RDO site (i.e. allow jar bundling for this) * Or allow RDO Manager to pull packages from your repos, not hosted on RDO site I think either path should be acceptable. >> 5. take responsibility for CI > > Of course. With assistance from the CI team in RDO, of course, to get you started. >> As far as these conditions are respected, there should be no problems >> in accepting MidoNet in RDO. > > Getting all these deps packaged will really be a major effort so if > that's required, it will take a while. Otherwise, I see no obstacles > :) > >> In brief, what we require is commitment and taking responsibility of >> contributed packages. > > Sure, that's in our best interest anyway :) > >> Sandro, we'll both be at Flock in few weeks, so I'll be glad to >> discuss with you about it. > > Sure, let's do that :) Sounds like a plan. Sandro, glad to see you engaging with us in the community here, and looking forward to seeing how this integration works! Thanks, Perry From hbrock at redhat.com Thu Jul 30 11:22:11 2015 From: hbrock at redhat.com (Hugh O. Brock) Date: Thu, 30 Jul 2015 13:22:11 +0200 Subject: [Rdo-list] Integration of MidoNet into RDO Manager In-Reply-To: <55BA072E.4000807@redhat.com> References: <55B78AC8.2080905@redhat.com> <887285868.1756758.1438097272315.JavaMail.zimbra@redhat.com> <55BA072E.4000807@redhat.com> Message-ID: <20150730112211.GE15385@redhat.com> On Thu, Jul 30, 2015 at 07:14:54AM -0400, Perry Myers wrote: > > It's combined APT and RPM, but you're right, there's currently no > > source packages for either. > > > > Out of curiosity, why do people need to be able to rebuild them (in > > the scenario we're discussing - integrating MidoNet with RDO Manager)? > > I don't think they strictly need this ability. Providing packages that > are rebuildable by the community is a nice thing to do, but it shouldn't > be a strict requirement in a case like this, I believe. > > If anything I'd focus on providing a rebuildable RPM for the Neutron > plugin itself, but perhaps skip that for the SDN solution that is paired > with it. > > >>>> > >>>> Are packages hosted on the developer's repositories acceptable for > >>>> integration into RDO Manager? We need to unbundle a couple of things > >>>> (or maybe more than just a couple) before we can package them for > >>>> inclusion into the proper repository. > >>> Typically, using a COPR is just a transition step to getting packages > >>> into Fedora; RDO very much follows the Fedora model. > >>> > >>> The individual packages themselves must be submitted, reviewed, and > >>> maintained. RDO manager is the last step of the process, and will only > >>> work with RDOmanaged packages. > > > > So all our packages would have to be part of the RDO repository (which > > I trust follows the EPEL/Fedora Guidelines)? > > I think having the packages part of a repo available on RDO would make > the end user experience a lot easier, but I don't think there is/should > be a strict requirement that anything integrated with RDO and RDO > Manager _must_ be hosted on the RDO site. > > We might want to differentiate between (for example) the Neutron plugin > packages and the SDN solution, for that. > > I also want to make sure folks understand that I don't think that > getting packages like this 'into Fedora' should be a requirement. > > Right now we are tied to getting things into Fedora since we don't have > another place to host spec files, etc, but we're working on decoupling > from this so that we can move to a model where we are 'on Fedora' > instead of 'in Fedora' > > But to the extent that we can, we try to follow Fedora packaging > guidelines as a best practice, but can/will make exceptions where it > makes sense. > > >>>> Speaking of repositories, once we're ready to package them properly > >>>> for inclusion, which repository would be the (most?) proper one for > >>>> RDO Manager? RDO? CentOS (wherever Cloud SIG packages go)? EPEL? > >>> Its usually easiest to start with Fedora for all packaging. Once they > >>> are accepted into Fedora, figuring out how to get them into the > >>> appropriate other locations will follow. > > > > Well, for our packages, Fedora and EL would be fairly different. The > > MidoNet core is written in Java/Scala, so much more (tools, deps) is > > missing from EL, e.g. gradle and of course lots of artifacts. So we > > should target EPEL, I guess. > > I wouldn't follow Adam's advice here (starting with Fedora). Especially > for the SDN solution which is Java based. That would lead to a lot of > pain and overhead. > > >>> Thus far, RDO manager has been focused on upstream OpenStack and the > >>> necessary pieces from the base OS that need to be updated to support > >>> it. While it should be possible to have an add-on like MidoNet, I don't > >>> know how the rest of the community would feel about it being required to > >>> be part of RDO. My thought is that, so long as it A) is under a > >>> sufficient license and B) provides real value beyond what is available > >>> from Neutron, it should be possible to include, so long as including it > >>> does not impact people currently developing and deploying RDO. > >>> > >>> > >>> Is there any move to get MidoNet into upstream OpenStack? > >> > >> Aren't we talking about the midonet neutron plug-in which was already part of neutron-proper but as a result of the plug-in decomposition effort now has it's own repo under the openstack namespace ( http://git.openstack.org/cgit/openstack/networking-midonet/ ). I'm really unclear on what the issue is here versus other RDO-Manager integration efforts - perhaps you can clarify? > > > > Yes, that's what we're talking about, thanks for providing the reference :) > > > > However, I'm a bit confused now - surely, integration would not just > > include the plugin but also the SDN solution the plugin is leveraging, > > right? > > That's actually a good question. I think typically we've been thinking > about integration of the plugin only, because that is co-located on > compute nodes and there might be controller node software that needs to > be bundled for certain SDN solutions as well. > > But I can see where deployment of the SDN solution itself by RDO Manager > could be very useful and would make the end user experience much easier. > But I'd have to defer to folks on that team as to how and if this could > be done :) I think we would be anxious to help with this. We want RDO Manager to be a one-stop shop for all kinds of deployments -- the more participation we have, the better. > >> Thanks, > >> > >> Steve > >> > > > > On Wed, Jul 29, 2015 at 3:35 AM, Ha?kel wrote: > >> I don't know much about MidoNet, but in order to get accepted in RDO > >> > >> 1. licensing should be compatible with RDO > > > > Apache Software License 2.0 > > > >> 2. it has to be an upstreamed effort > > > > Like with most Neutron plugins, the plugin itself is upstream but the > > rest isn't. > > > > Neutron MidoNet Plugin (as shared by Steve above already): > > http://git.openstack.org/cgit/openstack/networking-midonet/ > > > > MidoNet: > > https://github.com/midonet/midonet/ > > > > > >> 3. an identified maintainer (RDO Eng. will focus on maintaining "core" > >> projects, and we won't be maintaining all neutron drivers) > > > > That should be no problem. Does this have to be a single person or can > > it be a team? > > A single person can be a team :) > > >> 4. provide packages conforming Fedora guidelines > > > > Okay, so - as Adam and Steve already hinted - non-conforming packages > > (hosted on our own repo) are not acceptable then? Our biggest headache > > right now (like with any Java software) in terms of the Fedora > > Packaging Guidelines are tons of bundled jars - so that would be a > > no-go, right? > > I think we need to relax the requirements on #4 here. For the Neutron > plugin, I think we can/should conform to Fedora packaging guidelines, > and definitely get that package hosted on RDO directly. > > For the SDN solution in Java, I think we should either allow: > * Relaxed packaging guidelines, recognizing that this is an SDN > solution, and we host Midonet RPMs on RDO site > (i.e. allow jar bundling for this) > * Or allow RDO Manager to pull packages from your repos, not hosted on > RDO site > > I think either path should be acceptable. Yes, this is exactly right. We want the neutron plugin to be packaged such that we can build it into the overcloud images, but the SDN solution can easily be added post-build with virt-customize or equivalent. I would never recommend anyone go through the full java un-bundling process without a very, very good reason. > >> 5. take responsibility for CI > > > > Of course. > > With assistance from the CI team in RDO, of course, to get you started. > > >> As far as these conditions are respected, there should be no problems > >> in accepting MidoNet in RDO. > > > > Getting all these deps packaged will really be a major effort so if > > that's required, it will take a while. Otherwise, I see no obstacles > > :) > > > >> In brief, what we require is commitment and taking responsibility of > >> contributed packages. > > > > Sure, that's in our best interest anyway :) > > > >> Sandro, we'll both be at Flock in few weeks, so I'll be glad to > >> discuss with you about it. > > > > Sure, let's do that :) > > Sounds like a plan. > > Sandro, glad to see you engaging with us in the community here, and > looking forward to seeing how this integration works! > > Thanks, > > Perry +1 from me, we're really looking forward to getting Midonet into RDO Manager! --Hugh -- == Hugh Brock, hbrock at redhat.com == == Senior Engineering Manager, Cloud Engineering == == RDO Manager: Install, configure, and scale OpenStack == == http://rdoproject.org == "I know that you believe you understand what you think I said, but I?m not sure you realize that what you heard is not what I meant." --Robert McCloskey From hguemar at fedoraproject.org Thu Jul 30 11:26:31 2015 From: hguemar at fedoraproject.org (=?UTF-8?Q?Ha=C3=AFkel?=) Date: Thu, 30 Jul 2015 13:26:31 +0200 Subject: [Rdo-list] Integration of MidoNet into RDO Manager In-Reply-To: <20150730112211.GE15385@redhat.com> References: <55B78AC8.2080905@redhat.com> <887285868.1756758.1438097272315.JavaMail.zimbra@redhat.com> <55BA072E.4000807@redhat.com> <20150730112211.GE15385@redhat.com> Message-ID: Since this topic interests a lot of people here, I take notes to send a report when I'll come back from Rochester :) Regards, H. From sandro at mathys.io Thu Jul 30 12:17:19 2015 From: sandro at mathys.io (Sandro Mathys) Date: Thu, 30 Jul 2015 21:17:19 +0900 Subject: [Rdo-list] Integration of MidoNet into RDO Manager In-Reply-To: <20150730112211.GE15385@redhat.com> References: <55B78AC8.2080905@redhat.com> <887285868.1756758.1438097272315.JavaMail.zimbra@redhat.com> <55BA072E.4000807@redhat.com> <20150730112211.GE15385@redhat.com> Message-ID: On Thu, Jul 30, 2015 at 7:39 PM, Ha?kel wrote: >> That should be no problem. Does this have to be a single person or can > it be a team? > > fine with me > >> Our biggest headache right now (like with any Java software) in terms of the Fedora > Packaging Guidelines are tons of bundled jars - so that would be a no-go, right? > > Currently, yes, but it'll change in the near future. > Starting Mitaka, we're considering to switch over CentOS dist-git as > our main source > for packaging and we'll be able to provide bundling libraries > exception for RDO packages. > I plan to discuss at Flock with bstinson and kbsingh about our plans, > and how to enable > contributors to have access to git & build system safely. To be honest, we were hoping to be integrated before Mitaka - but then again, unbundling everything would be such a huge effort that it would probably take us much longer. So this would still be great news for us. Just let me know when and where you guys meet if you want me to join you so I can maybe weigh in with an outside view. > We don't have yet a reviewing process for such packages but it's > mostly a matter of timing. > > Only clients and oslo libraries will be shipped in Fedora 24, Fedora > users could still use > RDO Delorean packages (which are unsigned). > > Regards, > H. > On Thu, Jul 30, 2015 at 8:22 PM, Hugh O. Brock wrote: > On Thu, Jul 30, 2015 at 07:14:54AM -0400, Perry Myers wrote: >> > It's combined APT and RPM, but you're right, there's currently no >> > source packages for either. >> > >> > Out of curiosity, why do people need to be able to rebuild them (in >> > the scenario we're discussing - integrating MidoNet with RDO Manager)? >> >> I don't think they strictly need this ability. Providing packages that >> are rebuildable by the community is a nice thing to do, but it shouldn't >> be a strict requirement in a case like this, I believe. To be clear: we do plan to release source packages but our current build process does not allow for it, so it will take a while to get there - which is why we were hoping it was not strictly necessary. >> If anything I'd focus on providing a rebuildable RPM for the Neutron >> plugin itself, but perhaps skip that for the SDN solution that is paired >> with it. That should be absolutely no problem at all, the plugin has different processes, etc. and the package is in quite good shape. >> >>>> >> >>>> Are packages hosted on the developer's repositories acceptable for >> >>>> integration into RDO Manager? We need to unbundle a couple of things >> >>>> (or maybe more than just a couple) before we can package them for >> >>>> inclusion into the proper repository. >> >>> Typically, using a COPR is just a transition step to getting packages >> >>> into Fedora; RDO very much follows the Fedora model. >> >>> >> >>> The individual packages themselves must be submitted, reviewed, and >> >>> maintained. RDO manager is the last step of the process, and will only >> >>> work with RDOmanaged packages. >> > >> > So all our packages would have to be part of the RDO repository (which >> > I trust follows the EPEL/Fedora Guidelines)? >> >> I think having the packages part of a repo available on RDO would make >> the end user experience a lot easier, but I don't think there is/should >> be a strict requirement that anything integrated with RDO and RDO >> Manager _must_ be hosted on the RDO site. Agreed. Basically, we'd like to first use our external repo until we're ready for inclusion in the RDO repo (with bundled jars). >> We might want to differentiate between (for example) the Neutron plugin >> packages and the SDN solution, for that. >> >> I also want to make sure folks understand that I don't think that >> getting packages like this 'into Fedora' should be a requirement. >> >> Right now we are tied to getting things into Fedora since we don't have >> another place to host spec files, etc, but we're working on decoupling >> from this so that we can move to a model where we are 'on Fedora' >> instead of 'in Fedora' That makes sense. So I guess this would work well with what I said above: use an external repo at first until 1) our packages (or rather build processes) are in a better shape (i.e. use packaging tools) and 2) RDO is not "in Fedora" anymore. >> But to the extent that we can, we try to follow Fedora packaging >> guidelines as a best practice, but can/will make exceptions where it >> makes sense. I really hope we won't need any other exception than "bundled (fat)jars", and don't think we will. >> >>>> Speaking of repositories, once we're ready to package them properly >> >>>> for inclusion, which repository would be the (most?) proper one for >> >>>> RDO Manager? RDO? CentOS (wherever Cloud SIG packages go)? EPEL? >> >>> Its usually easiest to start with Fedora for all packaging. Once they >> >>> are accepted into Fedora, figuring out how to get them into the >> >>> appropriate other locations will follow. >> > >> > Well, for our packages, Fedora and EL would be fairly different. The >> > MidoNet core is written in Java/Scala, so much more (tools, deps) is >> > missing from EL, e.g. gradle and of course lots of artifacts. So we >> > should target EPEL, I guess. >> >> I wouldn't follow Adam's advice here (starting with Fedora). Especially >> for the SDN solution which is Java based. That would lead to a lot of >> pain and overhead. >> >> >>> Thus far, RDO manager has been focused on upstream OpenStack and the >> >>> necessary pieces from the base OS that need to be updated to support >> >>> it. While it should be possible to have an add-on like MidoNet, I don't >> >>> know how the rest of the community would feel about it being required to >> >>> be part of RDO. My thought is that, so long as it A) is under a >> >>> sufficient license and B) provides real value beyond what is available >> >>> from Neutron, it should be possible to include, so long as including it >> >>> does not impact people currently developing and deploying RDO. >> >>> >> >>> >> >>> Is there any move to get MidoNet into upstream OpenStack? >> >> >> >> Aren't we talking about the midonet neutron plug-in which was already part of neutron-proper but as a result of the plug-in decomposition effort now has it's own repo under the openstack namespace ( http://git.openstack.org/cgit/openstack/networking-midonet/ ). I'm really unclear on what the issue is here versus other RDO-Manager integration efforts - perhaps you can clarify? >> > >> > Yes, that's what we're talking about, thanks for providing the reference :) >> > >> > However, I'm a bit confused now - surely, integration would not just >> > include the plugin but also the SDN solution the plugin is leveraging, >> > right? >> >> That's actually a good question. I think typically we've been thinking >> about integration of the plugin only, because that is co-located on >> compute nodes and there might be controller node software that needs to >> be bundled for certain SDN solutions as well. >> >> But I can see where deployment of the SDN solution itself by RDO Manager >> could be very useful and would make the end user experience much easier. >> But I'd have to defer to folks on that team as to how and if this could >> be done :) Well, one of our main differences e.g. from the default plugin/SDN solution (ovs) is, that we don't have a central network node but instead an agent on all compute nodes. So I'm not sure I would fully agree with that. > I think we would be anxious to help with this. We want RDO Manager to be > a one-stop shop for all kinds of deployments -- the more participation > we have, the better. Cool, thanks! :) >> >> Thanks, >> >> >> >> Steve >> >> >> > >> > On Wed, Jul 29, 2015 at 3:35 AM, Ha?kel wrote: >> >> I don't know much about MidoNet, but in order to get accepted in RDO >> >> >> >> 1. licensing should be compatible with RDO >> > >> > Apache Software License 2.0 >> > >> >> 2. it has to be an upstreamed effort >> > >> > Like with most Neutron plugins, the plugin itself is upstream but the >> > rest isn't. >> > >> > Neutron MidoNet Plugin (as shared by Steve above already): >> > http://git.openstack.org/cgit/openstack/networking-midonet/ >> > >> > MidoNet: >> > https://github.com/midonet/midonet/ >> > >> > >> >> 3. an identified maintainer (RDO Eng. will focus on maintaining "core" >> >> projects, and we won't be maintaining all neutron drivers) >> > >> > That should be no problem. Does this have to be a single person or can >> > it be a team? >> >> A single person can be a team :) >> >> >> 4. provide packages conforming Fedora guidelines >> > >> > Okay, so - as Adam and Steve already hinted - non-conforming packages >> > (hosted on our own repo) are not acceptable then? Our biggest headache >> > right now (like with any Java software) in terms of the Fedora >> > Packaging Guidelines are tons of bundled jars - so that would be a >> > no-go, right? >> >> I think we need to relax the requirements on #4 here. For the Neutron >> plugin, I think we can/should conform to Fedora packaging guidelines, >> and definitely get that package hosted on RDO directly. >> >> For the SDN solution in Java, I think we should either allow: >> * Relaxed packaging guidelines, recognizing that this is an SDN >> solution, and we host Midonet RPMs on RDO site >> (i.e. allow jar bundling for this) >> * Or allow RDO Manager to pull packages from your repos, not hosted on >> RDO site >> >> I think either path should be acceptable. > > Yes, this is exactly right. We want the neutron plugin to be packaged > such that we can build it into the overcloud images, but the SDN > solution can easily be added post-build with virt-customize or > equivalent. I would never recommend anyone go through the full java > un-bundling process without a very, very good reason. Right, as mentioned above, I think both the plugin and the MidoNet Agent should be included in the overcloud images as nova-compute will require the agent - unless there's some workaround for that but I'd rather avoid workarounds. I had to ask one of our tech guys, but he agrees the that the rest can be added post-build. >> >> 5. take responsibility for CI >> > >> > Of course. >> >> With assistance from the CI team in RDO, of course, to get you started. Great, I'm sure our CI guys will appreciate that very much. >> >> As far as these conditions are respected, there should be no problems >> >> in accepting MidoNet in RDO. >> > >> > Getting all these deps packaged will really be a major effort so if >> > that's required, it will take a while. Otherwise, I see no obstacles >> > :) >> > >> >> In brief, what we require is commitment and taking responsibility of >> >> contributed packages. >> > >> > Sure, that's in our best interest anyway :) >> > >> >> Sandro, we'll both be at Flock in few weeks, so I'll be glad to >> >> discuss with you about it. >> > >> > Sure, let's do that :) >> >> Sounds like a plan. >> >> Sandro, glad to see you engaging with us in the community here, and >> looking forward to seeing how this integration works! >> >> Thanks, >> >> Perry > > +1 from me, we're really looking forward to getting Midonet into RDO Manager! +1, and likewise! Glad you're open to this :) Thanks, Sandro From ichi.sara at gmail.com Thu Jul 30 12:26:07 2015 From: ichi.sara at gmail.com (ICHIBA Sara) Date: Thu, 30 Jul 2015 14:26:07 +0200 Subject: [Rdo-list] [heat][autoscaling][cleaning before scale down] Message-ID: Hey there, I'm working on the autoscaling of cassandra with heat and ceilometer. I'm one step away from finishing my template. Now, I'm looking for a way to hand a script over to every cassandra server just before its removal by heat ( scaledown action). By doing this, I'm sure that the rest of the cluster won't try anymore to reach that cluster and that the load will be rebalanced again. Thank you for your response, B.regards Sara -------------- next part -------------- An HTML attachment was scrubbed... URL: From Arkady_Kanevsky at dell.com Thu Jul 30 13:47:02 2015 From: Arkady_Kanevsky at dell.com (Arkady_Kanevsky at dell.com) Date: Thu, 30 Jul 2015 08:47:02 -0500 Subject: [Rdo-list] Integration of MidoNet into RDO Manager In-Reply-To: <20150730112211.GE15385@redhat.com> References: <55B78AC8.2080905@redhat.com> <887285868.1756758.1438097272315.JavaMail.zimbra@redhat.com> <55BA072E.4000807@redhat.com> <20150730112211.GE15385@redhat.com> Message-ID: <336424C1A5A44044B29030055527AA7504BEC43EC4@AUSX7MCPS301.AMER.DELL.COM> Agree with Hugh. We need to be careful how we expose midonet option to user. Best if we can expose midonet option for neutron under tuscar. By default midonet will run on controller nodes with agents on each compute node. There are a few other things that need to be done outside packages. BGP network will be needed separate from public one. (separation of external API from floating IP one). Tons of details on dependencies including Java. Finally midonet manager GUI. But that is the last step that maybe outside RDO. Thanks, Arkady -----Original Message----- From: rdo-list-bounces at redhat.com [mailto:rdo-list-bounces at redhat.com] On Behalf Of Hugh O. Brock Sent: Thursday, July 30, 2015 6:22 AM To: Perry Myers Cc: rdo-list at redhat.com Subject: Re: [Rdo-list] Integration of MidoNet into RDO Manager On Thu, Jul 30, 2015 at 07:14:54AM -0400, Perry Myers wrote: > > It's combined APT and RPM, but you're right, there's currently no > > source packages for either. > > > > Out of curiosity, why do people need to be able to rebuild them (in > > the scenario we're discussing - integrating MidoNet with RDO Manager)? > > I don't think they strictly need this ability. Providing packages that > are rebuildable by the community is a nice thing to do, but it > shouldn't be a strict requirement in a case like this, I believe. > > If anything I'd focus on providing a rebuildable RPM for the Neutron > plugin itself, but perhaps skip that for the SDN solution that is > paired with it. > > >>>> > >>>> Are packages hosted on the developer's repositories acceptable > >>>> for integration into RDO Manager? We need to unbundle a couple of > >>>> things (or maybe more than just a couple) before we can package > >>>> them for inclusion into the proper repository. > >>> Typically, using a COPR is just a transition step to getting > >>> packages into Fedora; RDO very much follows the Fedora model. > >>> > >>> The individual packages themselves must be submitted, reviewed, > >>> and maintained. RDO manager is the last step of the process, and > >>> will only work with RDOmanaged packages. > > > > So all our packages would have to be part of the RDO repository > > (which I trust follows the EPEL/Fedora Guidelines)? > > I think having the packages part of a repo available on RDO would make > the end user experience a lot easier, but I don't think there > is/should be a strict requirement that anything integrated with RDO > and RDO Manager _must_ be hosted on the RDO site. > > We might want to differentiate between (for example) the Neutron > plugin packages and the SDN solution, for that. > > I also want to make sure folks understand that I don't think that > getting packages like this 'into Fedora' should be a requirement. > > Right now we are tied to getting things into Fedora since we don't > have another place to host spec files, etc, but we're working on > decoupling from this so that we can move to a model where we are 'on Fedora' > instead of 'in Fedora' > > But to the extent that we can, we try to follow Fedora packaging > guidelines as a best practice, but can/will make exceptions where it > makes sense. > > >>>> Speaking of repositories, once we're ready to package them > >>>> properly for inclusion, which repository would be the (most?) > >>>> proper one for RDO Manager? RDO? CentOS (wherever Cloud SIG packages go)? EPEL? > >>> Its usually easiest to start with Fedora for all packaging. Once > >>> they are accepted into Fedora, figuring out how to get them into > >>> the appropriate other locations will follow. > > > > Well, for our packages, Fedora and EL would be fairly different. The > > MidoNet core is written in Java/Scala, so much more (tools, deps) is > > missing from EL, e.g. gradle and of course lots of artifacts. So we > > should target EPEL, I guess. > > I wouldn't follow Adam's advice here (starting with Fedora). > Especially for the SDN solution which is Java based. That would lead > to a lot of pain and overhead. > > >>> Thus far, RDO manager has been focused on upstream OpenStack and > >>> the necessary pieces from the base OS that need to be updated to > >>> support it. While it should be possible to have an add-on like > >>> MidoNet, I don't know how the rest of the community would feel > >>> about it being required to be part of RDO. My thought is that, so > >>> long as it A) is under a sufficient license and B) provides real > >>> value beyond what is available from Neutron, it should be possible > >>> to include, so long as including it does not impact people currently developing and deploying RDO. > >>> > >>> > >>> Is there any move to get MidoNet into upstream OpenStack? > >> > >> Aren't we talking about the midonet neutron plug-in which was already part of neutron-proper but as a result of the plug-in decomposition effort now has it's own repo under the openstack namespace ( http://git.openstack.org/cgit/openstack/networking-midonet/ ). I'm really unclear on what the issue is here versus other RDO-Manager integration efforts - perhaps you can clarify? > > > > Yes, that's what we're talking about, thanks for providing the > > reference :) > > > > However, I'm a bit confused now - surely, integration would not just > > include the plugin but also the SDN solution the plugin is > > leveraging, right? > > That's actually a good question. I think typically we've been thinking > about integration of the plugin only, because that is co-located on > compute nodes and there might be controller node software that needs > to be bundled for certain SDN solutions as well. > > But I can see where deployment of the SDN solution itself by RDO > Manager could be very useful and would make the end user experience much easier. > But I'd have to defer to folks on that team as to how and if this > could be done :) I think we would be anxious to help with this. We want RDO Manager to be a one-stop shop for all kinds of deployments -- the more participation we have, the better. > >> Thanks, > >> > >> Steve > >> > > > > On Wed, Jul 29, 2015 at 3:35 AM, Ha?kel wrote: > >> I don't know much about MidoNet, but in order to get accepted in > >> RDO > >> > >> 1. licensing should be compatible with RDO > > > > Apache Software License 2.0 > > > >> 2. it has to be an upstreamed effort > > > > Like with most Neutron plugins, the plugin itself is upstream but > > the rest isn't. > > > > Neutron MidoNet Plugin (as shared by Steve above already): > > http://git.openstack.org/cgit/openstack/networking-midonet/ > > > > MidoNet: > > https://github.com/midonet/midonet/ > > > > > >> 3. an identified maintainer (RDO Eng. will focus on maintaining "core" > >> projects, and we won't be maintaining all neutron drivers) > > > > That should be no problem. Does this have to be a single person or > > can it be a team? > > A single person can be a team :) > > >> 4. provide packages conforming Fedora guidelines > > > > Okay, so - as Adam and Steve already hinted - non-conforming > > packages (hosted on our own repo) are not acceptable then? Our > > biggest headache right now (like with any Java software) in terms of > > the Fedora Packaging Guidelines are tons of bundled jars - so that > > would be a no-go, right? > > I think we need to relax the requirements on #4 here. For the Neutron > plugin, I think we can/should conform to Fedora packaging guidelines, > and definitely get that package hosted on RDO directly. > > For the SDN solution in Java, I think we should either allow: > * Relaxed packaging guidelines, recognizing that this is an SDN > solution, and we host Midonet RPMs on RDO site > (i.e. allow jar bundling for this) > * Or allow RDO Manager to pull packages from your repos, not hosted on > RDO site > > I think either path should be acceptable. Yes, this is exactly right. We want the neutron plugin to be packaged such that we can build it into the overcloud images, but the SDN solution can easily be added post-build with virt-customize or equivalent. I would never recommend anyone go through the full java un-bundling process without a very, very good reason. > >> 5. take responsibility for CI > > > > Of course. > > With assistance from the CI team in RDO, of course, to get you started. > > >> As far as these conditions are respected, there should be no > >> problems in accepting MidoNet in RDO. > > > > Getting all these deps packaged will really be a major effort so if > > that's required, it will take a while. Otherwise, I see no obstacles > > :) > > > >> In brief, what we require is commitment and taking responsibility > >> of contributed packages. > > > > Sure, that's in our best interest anyway :) > > > >> Sandro, we'll both be at Flock in few weeks, so I'll be glad to > >> discuss with you about it. > > > > Sure, let's do that :) > > Sounds like a plan. > > Sandro, glad to see you engaging with us in the community here, and > looking forward to seeing how this integration works! > > Thanks, > > Perry +1 from me, we're really looking forward to getting Midonet into RDO Manager! --Hugh -- == Hugh Brock, hbrock at redhat.com == == Senior Engineering Manager, Cloud Engineering == == RDO Manager: Install, configure, and scale OpenStack == == http://rdoproject.org == "I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant." --Robert McCloskey _______________________________________________ Rdo-list mailing list Rdo-list at redhat.com https://www.redhat.com/mailman/listinfo/rdo-list To unsubscribe: rdo-list-unsubscribe at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmyers at redhat.com Thu Jul 30 14:34:23 2015 From: pmyers at redhat.com (Perry Myers) Date: Thu, 30 Jul 2015 10:34:23 -0400 Subject: [Rdo-list] Integration of MidoNet into RDO Manager In-Reply-To: References: <55B78AC8.2080905@redhat.com> <887285868.1756758.1438097272315.JavaMail.zimbra@redhat.com> <55BA072E.4000807@redhat.com> <20150730112211.GE15385@redhat.com> Message-ID: <55BA35EF.8060501@redhat.com> >>> But I can see where deployment of the SDN solution itself by RDO Manager >>> could be very useful and would make the end user experience much easier. >>> But I'd have to defer to folks on that team as to how and if this could >>> be done :) > > Well, one of our main differences e.g. from the default plugin/SDN > solution (ovs) is, that we don't have a central network node but > instead an agent on all compute nodes. So I'm not sure I would fully > agree with that. Ah, I didn't know that. Yes, then even more important that the SDN solution is included tightly integrated with RDO Manager From morazi at redhat.com Thu Jul 30 15:16:11 2015 From: morazi at redhat.com (Mike Orazi) Date: Thu, 30 Jul 2015 11:16:11 -0400 Subject: [Rdo-list] Integration of MidoNet into RDO Manager In-Reply-To: References: <55B78AC8.2080905@redhat.com> <887285868.1756758.1438097272315.JavaMail.zimbra@redhat.com> <55BA072E.4000807@redhat.com> <20150730112211.GE15385@redhat.com> Message-ID: <55BA3FBB.8020906@redhat.com> On 07/30/2015 08:17 AM, Sandro Mathys wrote: > On Thu, Jul 30, 2015 at 7:39 PM, Ha?kel wrote: >>> That should be no problem. Does this have to be a single person or can >> it be a team? >> >> fine with me >> >>> Our biggest headache right now (like with any Java software) in terms of the Fedora >> Packaging Guidelines are tons of bundled jars - so that would be a no-go, right? >> >> Currently, yes, but it'll change in the near future. >> Starting Mitaka, we're considering to switch over CentOS dist-git as >> our main source >> for packaging and we'll be able to provide bundling libraries >> exception for RDO packages. >> I plan to discuss at Flock with bstinson and kbsingh about our plans, >> and how to enable >> contributors to have access to git & build system safely. > > To be honest, we were hoping to be integrated before Mitaka - but then > again, unbundling everything would be such a huge effort that it would > probably take us much longer. So this would still be great news for > us. > > Just let me know when and where you guys meet if you want me to join > you so I can maybe weigh in with an outside view. > >> We don't have yet a reviewing process for such packages but it's >> mostly a matter of timing. >> >> Only clients and oslo libraries will be shipped in Fedora 24, Fedora >> users could still use >> RDO Delorean packages (which are unsigned). >> >> Regards, >> H. >> > On Thu, Jul 30, 2015 at 8:22 PM, Hugh O. Brock wrote: >> On Thu, Jul 30, 2015 at 07:14:54AM -0400, Perry Myers wrote: >>>> It's combined APT and RPM, but you're right, there's currently no >>>> source packages for either. >>>> >>>> Out of curiosity, why do people need to be able to rebuild them (in >>>> the scenario we're discussing - integrating MidoNet with RDO Manager)? >>> >>> I don't think they strictly need this ability. Providing packages that >>> are rebuildable by the community is a nice thing to do, but it shouldn't >>> be a strict requirement in a case like this, I believe. > > To be clear: we do plan to release source packages but our current > build process does not allow for it, so it will take a while to get > there - which is why we were hoping it was not strictly necessary. > >>> If anything I'd focus on providing a rebuildable RPM for the Neutron >>> plugin itself, but perhaps skip that for the SDN solution that is paired >>> with it. > > That should be absolutely no problem at all, the plugin has different > processes, etc. and the package is in quite good shape. > >>>>>>> >>>>>>> Are packages hosted on the developer's repositories acceptable for >>>>>>> integration into RDO Manager? We need to unbundle a couple of things >>>>>>> (or maybe more than just a couple) before we can package them for >>>>>>> inclusion into the proper repository. >>>>>> Typically, using a COPR is just a transition step to getting packages >>>>>> into Fedora; RDO very much follows the Fedora model. >>>>>> >>>>>> The individual packages themselves must be submitted, reviewed, and >>>>>> maintained. RDO manager is the last step of the process, and will only >>>>>> work with RDOmanaged packages. >>>> >>>> So all our packages would have to be part of the RDO repository (which >>>> I trust follows the EPEL/Fedora Guidelines)? >>> >>> I think having the packages part of a repo available on RDO would make >>> the end user experience a lot easier, but I don't think there is/should >>> be a strict requirement that anything integrated with RDO and RDO >>> Manager _must_ be hosted on the RDO site. > > Agreed. Basically, we'd like to first use our external repo until > we're ready for inclusion in the RDO repo (with bundled jars). > >>> We might want to differentiate between (for example) the Neutron plugin >>> packages and the SDN solution, for that. >>> >>> I also want to make sure folks understand that I don't think that >>> getting packages like this 'into Fedora' should be a requirement. >>> >>> Right now we are tied to getting things into Fedora since we don't have >>> another place to host spec files, etc, but we're working on decoupling >>> from this so that we can move to a model where we are 'on Fedora' >>> instead of 'in Fedora' > > That makes sense. So I guess this would work well with what I said > above: use an external repo at first until 1) our packages (or rather > build processes) are in a better shape (i.e. use packaging tools) and > 2) RDO is not "in Fedora" anymore. > >>> But to the extent that we can, we try to follow Fedora packaging >>> guidelines as a best practice, but can/will make exceptions where it >>> makes sense. > > I really hope we won't need any other exception than "bundled > (fat)jars", and don't think we will. > >>>>>>> Speaking of repositories, once we're ready to package them properly >>>>>>> for inclusion, which repository would be the (most?) proper one for >>>>>>> RDO Manager? RDO? CentOS (wherever Cloud SIG packages go)? EPEL? >>>>>> Its usually easiest to start with Fedora for all packaging. Once they >>>>>> are accepted into Fedora, figuring out how to get them into the >>>>>> appropriate other locations will follow. >>>> >>>> Well, for our packages, Fedora and EL would be fairly different. The >>>> MidoNet core is written in Java/Scala, so much more (tools, deps) is >>>> missing from EL, e.g. gradle and of course lots of artifacts. So we >>>> should target EPEL, I guess. >>> >>> I wouldn't follow Adam's advice here (starting with Fedora). Especially >>> for the SDN solution which is Java based. That would lead to a lot of >>> pain and overhead. >>> >>>>>> Thus far, RDO manager has been focused on upstream OpenStack and the >>>>>> necessary pieces from the base OS that need to be updated to support >>>>>> it. While it should be possible to have an add-on like MidoNet, I don't >>>>>> know how the rest of the community would feel about it being required to >>>>>> be part of RDO. My thought is that, so long as it A) is under a >>>>>> sufficient license and B) provides real value beyond what is available >>>>>> from Neutron, it should be possible to include, so long as including it >>>>>> does not impact people currently developing and deploying RDO. >>>>>> >>>>>> >>>>>> Is there any move to get MidoNet into upstream OpenStack? >>>>> >>>>> Aren't we talking about the midonet neutron plug-in which was already part of neutron-proper but as a result of the plug-in decomposition effort now has it's own repo under the openstack namespace ( http://git.openstack.org/cgit/openstack/networking-midonet/ ). I'm really unclear on what the issue is here versus other RDO-Manager integration efforts - perhaps you can clarify? >>>> >>>> Yes, that's what we're talking about, thanks for providing the reference :) >>>> >>>> However, I'm a bit confused now - surely, integration would not just >>>> include the plugin but also the SDN solution the plugin is leveraging, >>>> right? >>> >>> That's actually a good question. I think typically we've been thinking >>> about integration of the plugin only, because that is co-located on >>> compute nodes and there might be controller node software that needs to >>> be bundled for certain SDN solutions as well. >>> >>> But I can see where deployment of the SDN solution itself by RDO Manager >>> could be very useful and would make the end user experience much easier. >>> But I'd have to defer to folks on that team as to how and if this could >>> be done :) > > Well, one of our main differences e.g. from the default plugin/SDN > solution (ovs) is, that we don't have a central network node but > instead an agent on all compute nodes. So I'm not sure I would fully > agree with that. > I think this is probably a good opportunity for us to think about how to represent alternate deployment architectures. I added a few folks explicitly to the cc: who I think likely already have some ideas on this front. >> I think we would be anxious to help with this. We want RDO Manager to be >> a one-stop shop for all kinds of deployments -- the more participation >> we have, the better. > > Cool, thanks! :) > >>>>> Thanks, >>>>> >>>>> Steve >>>>> >>>> >>>> On Wed, Jul 29, 2015 at 3:35 AM, Ha?kel wrote: >>>>> I don't know much about MidoNet, but in order to get accepted in RDO >>>>> >>>>> 1. licensing should be compatible with RDO >>>> >>>> Apache Software License 2.0 >>>> >>>>> 2. it has to be an upstreamed effort >>>> >>>> Like with most Neutron plugins, the plugin itself is upstream but the >>>> rest isn't. >>>> >>>> Neutron MidoNet Plugin (as shared by Steve above already): >>>> http://git.openstack.org/cgit/openstack/networking-midonet/ >>>> >>>> MidoNet: >>>> https://github.com/midonet/midonet/ >>>> >>>> >>>>> 3. an identified maintainer (RDO Eng. will focus on maintaining "core" >>>>> projects, and we won't be maintaining all neutron drivers) >>>> >>>> That should be no problem. Does this have to be a single person or can >>>> it be a team? >>> >>> A single person can be a team :) >>> >>>>> 4. provide packages conforming Fedora guidelines >>>> >>>> Okay, so - as Adam and Steve already hinted - non-conforming packages >>>> (hosted on our own repo) are not acceptable then? Our biggest headache >>>> right now (like with any Java software) in terms of the Fedora >>>> Packaging Guidelines are tons of bundled jars - so that would be a >>>> no-go, right? >>> >>> I think we need to relax the requirements on #4 here. For the Neutron >>> plugin, I think we can/should conform to Fedora packaging guidelines, >>> and definitely get that package hosted on RDO directly. >>> >>> For the SDN solution in Java, I think we should either allow: >>> * Relaxed packaging guidelines, recognizing that this is an SDN >>> solution, and we host Midonet RPMs on RDO site >>> (i.e. allow jar bundling for this) >>> * Or allow RDO Manager to pull packages from your repos, not hosted on >>> RDO site >>> >>> I think either path should be acceptable. >> >> Yes, this is exactly right. We want the neutron plugin to be packaged >> such that we can build it into the overcloud images, but the SDN >> solution can easily be added post-build with virt-customize or >> equivalent. I would never recommend anyone go through the full java >> un-bundling process without a very, very good reason. > > Right, as mentioned above, I think both the plugin and the MidoNet > Agent should be included in the overcloud images as nova-compute will > require the agent - unless there's some workaround for that but I'd > rather avoid workarounds. I had to ask one of our tech guys, but he > agrees the that the rest can be added post-build. > Agreed. I'm happy to help with the virt-customize steps when we get to that part. I'll likely have something banged together on the rdo wiki by then that can serve as a simple scenario-based guide to adding small bits of content into the overcloud images. >>>>> 5. take responsibility for CI >>>> >>>> Of course. >>> >>> With assistance from the CI team in RDO, of course, to get you started. > > Great, I'm sure our CI guys will appreciate that very much. > >>>>> As far as these conditions are respected, there should be no problems >>>>> in accepting MidoNet in RDO. >>>> >>>> Getting all these deps packaged will really be a major effort so if >>>> that's required, it will take a while. Otherwise, I see no obstacles >>>> :) >>>> >>>>> In brief, what we require is commitment and taking responsibility of >>>>> contributed packages. >>>> >>>> Sure, that's in our best interest anyway :) >>>> >>>>> Sandro, we'll both be at Flock in few weeks, so I'll be glad to >>>>> discuss with you about it. >>>> >>>> Sure, let's do that :) >>> >>> Sounds like a plan. >>> >>> Sandro, glad to see you engaging with us in the community here, and >>> looking forward to seeing how this integration works! >>> >>> Thanks, >>> >>> Perry >> >> +1 from me, we're really looking forward to getting Midonet into RDO Manager! > > +1, and likewise! Glad you're open to this :) > > Thanks, > Sandro > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com > I'm really excited about this as well! If you would like some more real time interaction particularly on the rdo-manager front I'd be happy to chat on #rdo on freenode (nick == morazi). If I don't have answers for you, I'm pretty sure I'll be able to find folks that can help out. Thanks in advance, - Mike From apevec at gmail.com Thu Jul 30 15:27:48 2015 From: apevec at gmail.com (Alan Pevec) Date: Thu, 30 Jul 2015 17:27:48 +0200 Subject: [Rdo-list] Integration of MidoNet into RDO Manager In-Reply-To: <20150730112211.GE15385@redhat.com> References: <55B78AC8.2080905@redhat.com> <887285868.1756758.1438097272315.JavaMail.zimbra@redhat.com> <55BA072E.4000807@redhat.com> <20150730112211.GE15385@redhat.com> Message-ID: >> I also want to make sure folks understand that I don't think that >> getting packages like this 'into Fedora' should be a requirement. >> >> Right now we are tied to getting things into Fedora since we don't have >> another place to host spec files, etc, but we're working on decoupling >> from this so that we can move to a model where we are 'on Fedora' >> instead of 'in Fedora' >> >> But to the extent that we can, we try to follow Fedora packaging >> guidelines as a best practice, but can/will make exceptions where it >> makes sense. ACK - I want to emphasize that part: Fedora packaging guidlines actually do make sense and we want to stick to them even when we'll have separate review process. Exceptions should be reviewed carefully and added as written guidelines in RDO packaging documentation. >> For the SDN solution in Java, I think we should either allow: >> * Relaxed packaging guidelines, recognizing that this is an SDN >> solution, and we host Midonet RPMs on RDO site >> (i.e. allow jar bundling for this) >> * Or allow RDO Manager to pull packages from your repos, not hosted on >> RDO site > > Yes, this is exactly right. We want the neutron plugin to be packaged > such that we can build it into the overcloud images, but the SDN > solution can easily be added post-build with virt-customize or > equivalent. I would never recommend anyone go through the full java > un-bundling process without a very, very good reason. Very good reason for un-bundling is security updates, bundling is like static linking e.g. security fix in glibc would require distribution rebuild if it not were a dynamic library... So before allowing bundling we need to come up with the process to track all bundled libraries so that we know which packages need to be rebuilt and how, when CVE fixes come around. It could be that security response team already has tools for that, AFAIK golang packages need to be rebuild when there are library changes? Cheers, Alan From sandro at mathys.io Thu Jul 30 15:52:37 2015 From: sandro at mathys.io (Sandro Mathys) Date: Fri, 31 Jul 2015 00:52:37 +0900 Subject: [Rdo-list] Integration of MidoNet into RDO Manager In-Reply-To: <336424C1A5A44044B29030055527AA7504BEC43EC4@AUSX7MCPS301.AMER.DELL.COM> References: <55B78AC8.2080905@redhat.com> <887285868.1756758.1438097272315.JavaMail.zimbra@redhat.com> <55BA072E.4000807@redhat.com> <20150730112211.GE15385@redhat.com> <336424C1A5A44044B29030055527AA7504BEC43EC4@AUSX7MCPS301.AMER.DELL.COM> Message-ID: On Thu, Jul 30, 2015 at 10:47 PM, wrote: > Agree with Hugh. > > We need to be careful how we expose midonet option to user. > > Best if we can expose midonet option for neutron under tuscar. > > By default midonet will run on controller nodes with agents on each compute > node. There are a few other things that need to be done outside packages. > > BGP network will be needed separate from public one. (separation of external > API from floating IP one). Tons of details on dependencies including Java. > > Finally midonet manager GUI. But that is the last step that maybe outside > RDO. Just one correction (and maybe clarification): MidoNet Manager is non-open and exclusive part of Midokura Enterprise MidoNet (MEM). We're talking about the open-source/"community edition" MidoNet here. -- Sandro > Thanks, > > Arkady > > -----Original Message----- > From: rdo-list-bounces at redhat.com [mailto:rdo-list-bounces at redhat.com] On > Behalf Of Hugh O. Brock > Sent: Thursday, July 30, 2015 6:22 AM > To: Perry Myers > Cc: rdo-list at redhat.com > Subject: Re: [Rdo-list] Integration of MidoNet into RDO Manager > > On Thu, Jul 30, 2015 at 07:14:54AM -0400, Perry Myers wrote: >> > It's combined APT and RPM, but you're right, there's currently no >> > source packages for either. >> > >> > Out of curiosity, why do people need to be able to rebuild them (in >> > the scenario we're discussing - integrating MidoNet with RDO Manager)? >> >> I don't think they strictly need this ability. Providing packages that >> are rebuildable by the community is a nice thing to do, but it >> shouldn't be a strict requirement in a case like this, I believe. >> >> If anything I'd focus on providing a rebuildable RPM for the Neutron >> plugin itself, but perhaps skip that for the SDN solution that is >> paired with it. >> >> >>>> >> >>>> Are packages hosted on the developer's repositories acceptable >> >>>> for integration into RDO Manager? We need to unbundle a couple of >> >>>> things (or maybe more than just a couple) before we can package >> >>>> them for inclusion into the proper repository. >> >>> Typically, using a COPR is just a transition step to getting >> >>> packages into Fedora; RDO very much follows the Fedora model. >> >>> >> >>> The individual packages themselves must be submitted, reviewed, >> >>> and maintained. RDO manager is the last step of the process, and >> >>> will only work with RDOmanaged packages. >> > >> > So all our packages would have to be part of the RDO repository >> > (which I trust follows the EPEL/Fedora Guidelines)? >> >> I think having the packages part of a repo available on RDO would make >> the end user experience a lot easier, but I don't think there >> is/should be a strict requirement that anything integrated with RDO >> and RDO Manager _must_ be hosted on the RDO site. >> >> We might want to differentiate between (for example) the Neutron >> plugin packages and the SDN solution, for that. >> >> I also want to make sure folks understand that I don't think that >> getting packages like this 'into Fedora' should be a requirement. >> >> Right now we are tied to getting things into Fedora since we don't >> have another place to host spec files, etc, but we're working on >> decoupling from this so that we can move to a model where we are 'on >> Fedora' >> instead of 'in Fedora' >> >> But to the extent that we can, we try to follow Fedora packaging >> guidelines as a best practice, but can/will make exceptions where it >> makes sense. >> >> >>>> Speaking of repositories, once we're ready to package them >> >>>> properly for inclusion, which repository would be the (most?) >> >>>> proper one for RDO Manager? RDO? CentOS (wherever Cloud SIG packages >> >>>> go)? EPEL? >> >>> Its usually easiest to start with Fedora for all packaging. Once >> >>> they are accepted into Fedora, figuring out how to get them into >> >>> the appropriate other locations will follow. >> > >> > Well, for our packages, Fedora and EL would be fairly different. The >> > MidoNet core is written in Java/Scala, so much more (tools, deps) is >> > missing from EL, e.g. gradle and of course lots of artifacts. So we >> > should target EPEL, I guess. >> >> I wouldn't follow Adam's advice here (starting with Fedora). >> Especially for the SDN solution which is Java based. That would lead >> to a lot of pain and overhead. >> >> >>> Thus far, RDO manager has been focused on upstream OpenStack and >> >>> the necessary pieces from the base OS that need to be updated to >> >>> support it. While it should be possible to have an add-on like >> >>> MidoNet, I don't know how the rest of the community would feel >> >>> about it being required to be part of RDO. My thought is that, so >> >>> long as it A) is under a sufficient license and B) provides real >> >>> value beyond what is available from Neutron, it should be possible >> >>> to include, so long as including it does not impact people currently >> >>> developing and deploying RDO. >> >>> >> >>> >> >>> Is there any move to get MidoNet into upstream OpenStack? >> >> >> >> Aren't we talking about the midonet neutron plug-in which was already >> >> part of neutron-proper but as a result of the plug-in decomposition effort >> >> now has it's own repo under the openstack namespace ( >> >> http://git.openstack.org/cgit/openstack/networking-midonet/ ). I'm really >> >> unclear on what the issue is here versus other RDO-Manager integration >> >> efforts - perhaps you can clarify? >> > >> > Yes, that's what we're talking about, thanks for providing the >> > reference :) >> > >> > However, I'm a bit confused now - surely, integration would not just >> > include the plugin but also the SDN solution the plugin is >> > leveraging, right? >> >> That's actually a good question. I think typically we've been thinking >> about integration of the plugin only, because that is co-located on >> compute nodes and there might be controller node software that needs >> to be bundled for certain SDN solutions as well. >> >> But I can see where deployment of the SDN solution itself by RDO >> Manager could be very useful and would make the end user experience much >> easier. >> But I'd have to defer to folks on that team as to how and if this >> could be done :) > > I think we would be anxious to help with this. We want RDO Manager to be a > one-stop shop for all kinds of deployments -- the more participation we > have, the better. > >> >> Thanks, >> >> >> >> Steve >> >> >> > >> > On Wed, Jul 29, 2015 at 3:35 AM, Ha?kel wrote: >> >> I don't know much about MidoNet, but in order to get accepted in >> >> RDO >> >> >> >> 1. licensing should be compatible with RDO >> > >> > Apache Software License 2.0 >> > >> >> 2. it has to be an upstreamed effort >> > >> > Like with most Neutron plugins, the plugin itself is upstream but >> > the rest isn't. >> > >> > Neutron MidoNet Plugin (as shared by Steve above already): >> > http://git.openstack.org/cgit/openstack/networking-midonet/ >> > >> > MidoNet: >> > https://github.com/midonet/midonet/ >> > >> > >> >> 3. an identified maintainer (RDO Eng. will focus on maintaining "core" >> >> projects, and we won't be maintaining all neutron drivers) >> > >> > That should be no problem. Does this have to be a single person or >> > can it be a team? >> >> A single person can be a team :) >> >> >> 4. provide packages conforming Fedora guidelines >> > >> > Okay, so - as Adam and Steve already hinted - non-conforming >> > packages (hosted on our own repo) are not acceptable then? Our >> > biggest headache right now (like with any Java software) in terms of >> > the Fedora Packaging Guidelines are tons of bundled jars - so that >> > would be a no-go, right? >> >> I think we need to relax the requirements on #4 here. For the Neutron >> plugin, I think we can/should conform to Fedora packaging guidelines, >> and definitely get that package hosted on RDO directly. >> >> For the SDN solution in Java, I think we should either allow: >> * Relaxed packaging guidelines, recognizing that this is an SDN >> solution, and we host Midonet RPMs on RDO site >> (i.e. allow jar bundling for this) >> * Or allow RDO Manager to pull packages from your repos, not hosted on >> RDO site >> >> I think either path should be acceptable. > > Yes, this is exactly right. We want the neutron plugin to be packaged such > that we can build it into the overcloud images, but the SDN solution can > easily be added post-build with virt-customize or equivalent. I would never > recommend anyone go through the full java un-bundling process without a > very, very good reason. > >> >> 5. take responsibility for CI >> > >> > Of course. >> >> With assistance from the CI team in RDO, of course, to get you started. >> >> >> As far as these conditions are respected, there should be no >> >> problems in accepting MidoNet in RDO. >> > >> > Getting all these deps packaged will really be a major effort so if >> > that's required, it will take a while. Otherwise, I see no obstacles >> > :) >> > >> >> In brief, what we require is commitment and taking responsibility >> >> of contributed packages. >> > >> > Sure, that's in our best interest anyway :) >> > >> >> Sandro, we'll both be at Flock in few weeks, so I'll be glad to >> >> discuss with you about it. >> > >> > Sure, let's do that :) >> >> Sounds like a plan. >> >> Sandro, glad to see you engaging with us in the community here, and >> looking forward to seeing how this integration works! >> >> Thanks, >> >> Perry > > +1 from me, we're really looking forward to getting Midonet into RDO > Manager! > > --Hugh > > -- > == Hugh Brock, hbrock at redhat.com == > == Senior Engineering Manager, Cloud Engineering == > == RDO Manager: Install, configure, and scale OpenStack == > == http://rdoproject.org == > > "I know that you believe you understand what you think I said, but I?m not > sure you realize that what you heard is not what I meant." > --Robert McCloskey > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com > > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com From ayoung at redhat.com Thu Jul 30 16:17:02 2015 From: ayoung at redhat.com (Adam Young) Date: Thu, 30 Jul 2015 12:17:02 -0400 Subject: [Rdo-list] Integration of MidoNet into RDO Manager In-Reply-To: <55BA072E.4000807@redhat.com> References: <55B78AC8.2080905@redhat.com> <887285868.1756758.1438097272315.JavaMail.zimbra@redhat.com> <55BA072E.4000807@redhat.com> Message-ID: <55BA4DFE.7040304@redhat.com> On 07/30/2015 07:14 AM, Perry Myers wrote: >> >Well, for our packages, Fedora and EL would be fairly different. The >> >MidoNet core is written in Java/Scala, so much more (tools, deps) is >> >missing from EL, e.g. gradle and of course lots of artifacts. So we >> >should target EPEL, I guess. > I wouldn't follow Adam's advice here (starting with Fedora). Especially > for the SDN solution which is Java based. That would lead to a lot of > pain and overhead. > Heh...I still stand by it. But, to be clear: make sure the parts that you want to ship with RDO are build able on Fedora; We want to be able to test against as far upstream as possible. I tend to develop on Fedora and then test against Centos and RHEL. For the Java stuff....yeah, it can be a lot of work, but ultimately is worth the effort. We went through a lot of packaging pain for Dogtag, whcih is part of Barbican...Dogtag was, I think, the first Tomcat Application that got into Fedora. WIth JPackage etc, getting RPMs for the Software you have is manageable. But all that is is beyond the string need for the Neutron Plugin. SO, it depends on how far you want to go. If you only care about getting the plugin into RDO, yeah, you don't need to package the Java code. If you want to participate in the RDO and Fedora communities, I'd recommend getting the packages done correctly, but that can be done over time. I'd recommend looking into hosting COPR for the components you want to build. You can start with the easy ones. The Fedora Java team has done a lot of work on getting Maven builds to be able to select only packages that are themselves part of Fedora. You might be surprised at how much packaging you don't actually have to write today. As an added benefit, you get code that will help you installing the rest of MidoNet on a RHEL system. From sandro at mathys.io Thu Jul 30 16:38:57 2015 From: sandro at mathys.io (Sandro Mathys) Date: Fri, 31 Jul 2015 01:38:57 +0900 Subject: [Rdo-list] Integration of MidoNet into RDO Manager In-Reply-To: <55BA4DFE.7040304@redhat.com> References: <55B78AC8.2080905@redhat.com> <887285868.1756758.1438097272315.JavaMail.zimbra@redhat.com> <55BA072E.4000807@redhat.com> <55BA4DFE.7040304@redhat.com> Message-ID: On Fri, Jul 31, 2015 at 1:17 AM, Adam Young wrote: > On 07/30/2015 07:14 AM, Perry Myers wrote: >>> >>> >Well, for our packages, Fedora and EL would be fairly different. The >>> >MidoNet core is written in Java/Scala, so much more (tools, deps) is >>> >missing from EL, e.g. gradle and of course lots of artifacts. So we >>> >should target EPEL, I guess. >> >> I wouldn't follow Adam's advice here (starting with Fedora). Especially >> for the SDN solution which is Java based. That would lead to a lot of >> pain and overhead. >> > Heh...I still stand by it. But, to be clear: make sure the parts that you > want to ship with RDO are build able on Fedora; We want to be able to test > against as far upstream as possible. I tend to develop on Fedora and then > test against Centos and RHEL. Personally, I would also do it that way - but I can't guarantee that everyone involved will follow that approach. > For the Java stuff....yeah, it can be a lot of work, but ultimately is worth > the effort. We went through a lot of packaging pain for Dogtag, whcih is > part of Barbican...Dogtag was, I think, the first Tomcat Application that > got into Fedora. WIth JPackage etc, getting RPMs for the Software you have > is manageable. But all that is is beyond the string need for the Neutron > Plugin. > > > SO, it depends on how far you want to go. If you only care about getting > the plugin into RDO, yeah, you don't need to package the Java code. If you > want to participate in the RDO and Fedora communities, I'd recommend getting > the packages done correctly, but that can be done over time. I agree, but it will take a very long time to achieve this. > I'd recommend looking into hosting COPR for the components you want to > build. You can start with the easy ones. > > The Fedora Java team has done a lot of work on getting Maven builds to be > able to select only packages that are themselves part of Fedora. You might > be surprised at how much packaging you don't actually have to write today. > As an added benefit, you get code that will help you installing the rest of > MidoNet on a RHEL system. Well, we currently use gradle, not maven - but as of F22 gradle and gradle-local are available as well. However, trying to build MidoNet, I didn't even get past the build dependencies (gradle plugins, I think). Having packaged ant and maven based stuff for Fedora before, I was rather surprised how fast it failed ;) But I get your point :) -- Sandro > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com From pmyers at redhat.com Thu Jul 30 17:24:22 2015 From: pmyers at redhat.com (Perry Myers) Date: Thu, 30 Jul 2015 13:24:22 -0400 Subject: [Rdo-list] Integration of MidoNet into RDO Manager In-Reply-To: <55BA4DFE.7040304@redhat.com> References: <55B78AC8.2080905@redhat.com> <887285868.1756758.1438097272315.JavaMail.zimbra@redhat.com> <55BA072E.4000807@redhat.com> <55BA4DFE.7040304@redhat.com> Message-ID: <55BA5DC6.5020702@redhat.com> On 07/30/2015 12:17 PM, Adam Young wrote: > On 07/30/2015 07:14 AM, Perry Myers wrote: >>> >Well, for our packages, Fedora and EL would be fairly different. The >>> >MidoNet core is written in Java/Scala, so much more (tools, deps) is >>> >missing from EL, e.g. gradle and of course lots of artifacts. So we >>> >should target EPEL, I guess. >> I wouldn't follow Adam's advice here (starting with Fedora). Especially >> for the SDN solution which is Java based. That would lead to a lot of >> pain and overhead. >> > Heh...I still stand by it. But, to be clear: make sure the parts that > you want to ship with RDO are build able on Fedora; We want to be able > to test against as far upstream as possible. I tend to develop on > Fedora and then test against Centos and RHEL. agree with buildable on fedora, but don't think they need to be buildable in fedora. > For the Java stuff....yeah, it can be a lot of work, but ultimately is > worth the effort. Do I hear you volunteering for the effort here? :) > We went through a lot of packaging pain for Dogtag, > whcih is part of Barbican...Dogtag was, I think, the first Tomcat > Application that got into Fedora. WIth JPackage etc, getting RPMs for > the Software you have is manageable. But all that is is beyond the > string need for the Neutron Plugin. > > SO, it depends on how far you want to go. If you only care about > getting the plugin into RDO, yeah, you don't need to package the Java > code. If you want to participate in the RDO and Fedora communities, I'd > recommend getting the packages done correctly, but that can be done over > time. You can absolutely participate in the RDO community without doing what you're suggesting. The only issue would be participating in the Fedora community. > I'd recommend looking into hosting COPR for the components you want to > build. You can start with the easy ones. > > The Fedora Java team has done a lot of work on getting Maven builds to > be able to select only packages that are themselves part of Fedora. You > might be surprised at how much packaging you don't actually have to > write today. As an added benefit, you get code that will help you > installing the rest of MidoNet on a RHEL system. From sandro at mathys.io Thu Jul 30 18:01:14 2015 From: sandro at mathys.io (Sandro Mathys) Date: Fri, 31 Jul 2015 03:01:14 +0900 Subject: [Rdo-list] Integration of MidoNet into RDO Manager In-Reply-To: <55BA5DC6.5020702@redhat.com> References: <55B78AC8.2080905@redhat.com> <887285868.1756758.1438097272315.JavaMail.zimbra@redhat.com> <55BA072E.4000807@redhat.com> <55BA4DFE.7040304@redhat.com> <55BA5DC6.5020702@redhat.com> Message-ID: On Fri, Jul 31, 2015 at 2:24 AM, Perry Myers wrote: > On 07/30/2015 12:17 PM, Adam Young wrote: >> On 07/30/2015 07:14 AM, Perry Myers wrote: >>>> >Well, for our packages, Fedora and EL would be fairly different. The >>>> >MidoNet core is written in Java/Scala, so much more (tools, deps) is >>>> >missing from EL, e.g. gradle and of course lots of artifacts. So we >>>> >should target EPEL, I guess. >>> I wouldn't follow Adam's advice here (starting with Fedora). Especially >>> for the SDN solution which is Java based. That would lead to a lot of >>> pain and overhead. >>> >> Heh...I still stand by it. But, to be clear: make sure the parts that >> you want to ship with RDO are build able on Fedora; We want to be able >> to test against as far upstream as possible. I tend to develop on >> Fedora and then test against Centos and RHEL. > > agree with buildable on fedora, but don't think they need to be > buildable in fedora. > >> For the Java stuff....yeah, it can be a lot of work, but ultimately is >> worth the effort. > > Do I hear you volunteering for the effort here? :) > >> We went through a lot of packaging pain for Dogtag, >> whcih is part of Barbican...Dogtag was, I think, the first Tomcat >> Application that got into Fedora. WIth JPackage etc, getting RPMs for >> the Software you have is manageable. But all that is is beyond the >> string need for the Neutron Plugin. >> >> SO, it depends on how far you want to go. If you only care about >> getting the plugin into RDO, yeah, you don't need to package the Java >> code. If you want to participate in the RDO and Fedora communities, I'd >> recommend getting the packages done correctly, but that can be done over >> time. > > You can absolutely participate in the RDO community without doing what > you're suggesting. The only issue would be participating in the Fedora > community. FWIW, I'm a long-standing (8+ years) Fedora contributor myself and I've hold many roles during that time, including that of a Fedora Packager - and most of the software I packages was written in Java and built using ant or maven. So I do understand all these points, etc. But for the MidoNet community, Fedora is not currently a priority. Let's focus on RDO only here, alright? :) >> I'd recommend looking into hosting COPR for the components you want to >> build. You can start with the easy ones. >> >> The Fedora Java team has done a lot of work on getting Maven builds to >> be able to select only packages that are themselves part of Fedora. You >> might be surprised at how much packaging you don't actually have to >> write today. As an added benefit, you get code that will help you >> installing the rest of MidoNet on a RHEL system. I should probably mention that we use gradle, not maven. But I get your point. Nevertheless, lots is missing, e.g. Apache Cassandra... -- Sandro > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com From pmyers at redhat.com Thu Jul 30 18:03:45 2015 From: pmyers at redhat.com (Perry Myers) Date: Thu, 30 Jul 2015 14:03:45 -0400 Subject: [Rdo-list] Integration of MidoNet into RDO Manager In-Reply-To: References: <55B78AC8.2080905@redhat.com> <887285868.1756758.1438097272315.JavaMail.zimbra@redhat.com> <55BA072E.4000807@redhat.com> <55BA4DFE.7040304@redhat.com> <55BA5DC6.5020702@redhat.com> Message-ID: <55BA6701.8080801@redhat.com> > FWIW, I'm a long-standing (8+ years) Fedora contributor myself and > I've hold many roles during that time, including that of a Fedora > Packager - and most of the software I packages was written in Java and > built using ant or maven. So I do understand all these points, etc. > But for the MidoNet community, Fedora is not currently a priority. > Let's focus on RDO only here, alright? :) Yep, in complete agreement with you there From Arkady_Kanevsky at dell.com Thu Jul 30 19:03:30 2015 From: Arkady_Kanevsky at dell.com (Arkady_Kanevsky at dell.com) Date: Thu, 30 Jul 2015 14:03:30 -0500 Subject: [Rdo-list] Integration of MidoNet into RDO Manager In-Reply-To: References: <55B78AC8.2080905@redhat.com> <887285868.1756758.1438097272315.JavaMail.zimbra@redhat.com> <55BA072E.4000807@redhat.com> <20150730112211.GE15385@redhat.com> <336424C1A5A44044B29030055527AA7504BEC43EC4@AUSX7MCPS301.AMER.DELL.COM> Message-ID: <336424C1A5A44044B29030055527AA7504BEC4402B@AUSX7MCPS301.AMER.DELL.COM> Dell - Internal Use - Confidential Correct! -----Original Message----- From: Sandro Mathys [mailto:sandro at mathys.io] Sent: Thursday, July 30, 2015 10:53 AM To: Kanevsky, Arkady Cc: Hugh O. Brock; Perry Myers; rdo-list at redhat.com; Perryman, Randy Subject: Re: [Rdo-list] Integration of MidoNet into RDO Manager On Thu, Jul 30, 2015 at 10:47 PM, wrote: > Agree with Hugh. > > We need to be careful how we expose midonet option to user. > > Best if we can expose midonet option for neutron under tuscar. > > By default midonet will run on controller nodes with agents on each > compute node. There are a few other things that need to be done outside packages. > > BGP network will be needed separate from public one. (separation of > external API from floating IP one). Tons of details on dependencies including Java. > > Finally midonet manager GUI. But that is the last step that maybe > outside RDO. Just one correction (and maybe clarification): MidoNet Manager is non-open and exclusive part of Midokura Enterprise MidoNet (MEM). We're talking about the open-source/"community edition" MidoNet here. -- Sandro > Thanks, > > Arkady > > -----Original Message----- > From: rdo-list-bounces at redhat.com [mailto:rdo-list-bounces at redhat.com] > On Behalf Of Hugh O. Brock > Sent: Thursday, July 30, 2015 6:22 AM > To: Perry Myers > Cc: rdo-list at redhat.com > Subject: Re: [Rdo-list] Integration of MidoNet into RDO Manager > > On Thu, Jul 30, 2015 at 07:14:54AM -0400, Perry Myers wrote: >> > It's combined APT and RPM, but you're right, there's currently no >> > source packages for either. >> > >> > Out of curiosity, why do people need to be able to rebuild them (in >> > the scenario we're discussing - integrating MidoNet with RDO Manager)? >> >> I don't think they strictly need this ability. Providing packages >> that are rebuildable by the community is a nice thing to do, but it >> shouldn't be a strict requirement in a case like this, I believe. >> >> If anything I'd focus on providing a rebuildable RPM for the Neutron >> plugin itself, but perhaps skip that for the SDN solution that is >> paired with it. >> >> >>>> >> >>>> Are packages hosted on the developer's repositories acceptable >> >>>> for integration into RDO Manager? We need to unbundle a couple >> >>>> of things (or maybe more than just a couple) before we can >> >>>> package them for inclusion into the proper repository. >> >>> Typically, using a COPR is just a transition step to getting >> >>> packages into Fedora; RDO very much follows the Fedora model. >> >>> >> >>> The individual packages themselves must be submitted, reviewed, >> >>> and maintained. RDO manager is the last step of the process, and >> >>> will only work with RDOmanaged packages. >> > >> > So all our packages would have to be part of the RDO repository >> > (which I trust follows the EPEL/Fedora Guidelines)? >> >> I think having the packages part of a repo available on RDO would >> make the end user experience a lot easier, but I don't think there >> is/should be a strict requirement that anything integrated with RDO >> and RDO Manager _must_ be hosted on the RDO site. >> >> We might want to differentiate between (for example) the Neutron >> plugin packages and the SDN solution, for that. >> >> I also want to make sure folks understand that I don't think that >> getting packages like this 'into Fedora' should be a requirement. >> >> Right now we are tied to getting things into Fedora since we don't >> have another place to host spec files, etc, but we're working on >> decoupling from this so that we can move to a model where we are 'on >> Fedora' >> instead of 'in Fedora' >> >> But to the extent that we can, we try to follow Fedora packaging >> guidelines as a best practice, but can/will make exceptions where it >> makes sense. >> >> >>>> Speaking of repositories, once we're ready to package them >> >>>> properly for inclusion, which repository would be the (most?) >> >>>> proper one for RDO Manager? RDO? CentOS (wherever Cloud SIG >> >>>> packages go)? EPEL? >> >>> Its usually easiest to start with Fedora for all packaging. Once >> >>> they are accepted into Fedora, figuring out how to get them into >> >>> the appropriate other locations will follow. >> > >> > Well, for our packages, Fedora and EL would be fairly different. >> > The MidoNet core is written in Java/Scala, so much more (tools, >> > deps) is missing from EL, e.g. gradle and of course lots of >> > artifacts. So we should target EPEL, I guess. >> >> I wouldn't follow Adam's advice here (starting with Fedora). >> Especially for the SDN solution which is Java based. That would lead >> to a lot of pain and overhead. >> >> >>> Thus far, RDO manager has been focused on upstream OpenStack and >> >>> the necessary pieces from the base OS that need to be updated to >> >>> support it. While it should be possible to have an add-on like >> >>> MidoNet, I don't know how the rest of the community would feel >> >>> about it being required to be part of RDO. My thought is that, so >> >>> long as it A) is under a sufficient license and B) provides real >> >>> value beyond what is available from Neutron, it should be >> >>> possible to include, so long as including it does not impact >> >>> people currently developing and deploying RDO. >> >>> >> >>> >> >>> Is there any move to get MidoNet into upstream OpenStack? >> >> >> >> Aren't we talking about the midonet neutron plug-in which was >> >> already part of neutron-proper but as a result of the plug-in >> >> decomposition effort now has it's own repo under the openstack >> >> namespace ( >> >> http://git.openstack.org/cgit/openstack/networking-midonet/ ). I'm >> >> really unclear on what the issue is here versus other RDO-Manager integration efforts - perhaps you can clarify? >> > >> > Yes, that's what we're talking about, thanks for providing the >> > reference :) >> > >> > However, I'm a bit confused now - surely, integration would not >> > just include the plugin but also the SDN solution the plugin is >> > leveraging, right? >> >> That's actually a good question. I think typically we've been >> thinking about integration of the plugin only, because that is >> co-located on compute nodes and there might be controller node >> software that needs to be bundled for certain SDN solutions as well. >> >> But I can see where deployment of the SDN solution itself by RDO >> Manager could be very useful and would make the end user experience >> much easier. >> But I'd have to defer to folks on that team as to how and if this >> could be done :) > > I think we would be anxious to help with this. We want RDO Manager to > be a one-stop shop for all kinds of deployments -- the more > participation we have, the better. > >> >> Thanks, >> >> >> >> Steve >> >> >> > >> > On Wed, Jul 29, 2015 at 3:35 AM, Ha?kel wrote: >> >> I don't know much about MidoNet, but in order to get accepted in >> >> RDO >> >> >> >> 1. licensing should be compatible with RDO >> > >> > Apache Software License 2.0 >> > >> >> 2. it has to be an upstreamed effort >> > >> > Like with most Neutron plugins, the plugin itself is upstream but >> > the rest isn't. >> > >> > Neutron MidoNet Plugin (as shared by Steve above already): >> > http://git.openstack.org/cgit/openstack/networking-midonet/ >> > >> > MidoNet: >> > https://github.com/midonet/midonet/ >> > >> > >> >> 3. an identified maintainer (RDO Eng. will focus on maintaining "core" >> >> projects, and we won't be maintaining all neutron drivers) >> > >> > That should be no problem. Does this have to be a single person or >> > can it be a team? >> >> A single person can be a team :) >> >> >> 4. provide packages conforming Fedora guidelines >> > >> > Okay, so - as Adam and Steve already hinted - non-conforming >> > packages (hosted on our own repo) are not acceptable then? Our >> > biggest headache right now (like with any Java software) in terms >> > of the Fedora Packaging Guidelines are tons of bundled jars - so >> > that would be a no-go, right? >> >> I think we need to relax the requirements on #4 here. For the Neutron >> plugin, I think we can/should conform to Fedora packaging guidelines, >> and definitely get that package hosted on RDO directly. >> >> For the SDN solution in Java, I think we should either allow: >> * Relaxed packaging guidelines, recognizing that this is an SDN >> solution, and we host Midonet RPMs on RDO site (i.e. allow jar >> bundling for this) >> * Or allow RDO Manager to pull packages from your repos, not hosted >> on RDO site >> >> I think either path should be acceptable. > > Yes, this is exactly right. We want the neutron plugin to be packaged > such that we can build it into the overcloud images, but the SDN > solution can easily be added post-build with virt-customize or > equivalent. I would never recommend anyone go through the full java > un-bundling process without a very, very good reason. > >> >> 5. take responsibility for CI >> > >> > Of course. >> >> With assistance from the CI team in RDO, of course, to get you started. >> >> >> As far as these conditions are respected, there should be no >> >> problems in accepting MidoNet in RDO. >> > >> > Getting all these deps packaged will really be a major effort so if >> > that's required, it will take a while. Otherwise, I see no >> > obstacles >> > :) >> > >> >> In brief, what we require is commitment and taking responsibility >> >> of contributed packages. >> > >> > Sure, that's in our best interest anyway :) >> > >> >> Sandro, we'll both be at Flock in few weeks, so I'll be glad to >> >> discuss with you about it. >> > >> > Sure, let's do that :) >> >> Sounds like a plan. >> >> Sandro, glad to see you engaging with us in the community here, and >> looking forward to seeing how this integration works! >> >> Thanks, >> >> Perry > > +1 from me, we're really looking forward to getting Midonet into RDO > Manager! > > --Hugh > > -- > == Hugh Brock, hbrock at redhat.com == > == Senior Engineering Manager, Cloud Engineering == == RDO Manager: > Install, configure, and scale OpenStack == == http://rdoproject.org == > > "I know that you believe you understand what you think I said, but I'm > not sure you realize that what you heard is not what I meant." > --Robert McCloskey > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com > > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From kupo at linuxdigital.net Thu Jul 30 23:14:40 2015 From: kupo at linuxdigital.net (Tyler Wilson) Date: Thu, 30 Jul 2015 16:14:40 -0700 Subject: [Rdo-list] EL7 python-oslo-vmware/python-request dependency failure Message-ID: Hello All, I'm currently getting a dependency error on installing python-oslo-vmware from http://repos.fedorapeople.org/repos/openstack/openstack-juno/epel-7/; --> Finished Dependency Resolution Error: Package: python-oslo-vmware-0.7.0-1.el7.noarch (openstack-juno) Requires: python-request You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest I've searched for this package but it seems only python-requests is available, is this as it should be? # yum search python-request Loaded plugins: fastestmirror, langpacks, priorities, rhnplugin This system is receiving updates from RHN Classic or Red Hat Satellite. Loading mirror speeds from cached hostfile * base: mirror.lax.hugeserver.com * elrepo: ftp.osuosl.org * epel: mirror.sfo12.us.leaseweb.net * extras: mirrors.psychz.net * updates: centos.unixheads.org 135 packages excluded due to repository priority protections ======================================================================================= N/S matched: python-request ======================================================================================== python-requests-kerberos.noarch : A Kerberos authentication handler for python-requests python-requests-toolbelt.noarch : A utility belt for advanced users of python-requests python-requests.noarch : HTTP library, written in Python, for human beings python-requests-oauthlib.noarch : OAuthlib authentication support for Requests. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hguemar at fedoraproject.org Fri Jul 31 08:15:57 2015 From: hguemar at fedoraproject.org (=?UTF-8?Q?Ha=C3=AFkel?=) Date: Fri, 31 Jul 2015 10:15:57 +0200 Subject: [Rdo-list] EL7 python-oslo-vmware/python-request dependency failure In-Reply-To: References: Message-ID: My apologies, it's a legitimate issue. I'm currently rebuilding this package, and we'll push it asap. As an hotfix, direct link to the newer build: https://cbs.centos.org/koji/taskinfo?taskID=16692 Regards, H. From apevec at gmail.com Fri Jul 31 08:36:21 2015 From: apevec at gmail.com (Alan Pevec) Date: Fri, 31 Jul 2015 10:36:21 +0200 Subject: [Rdo-list] EL7 python-oslo-vmware/python-request dependency failure In-Reply-To: References: Message-ID: > I'm currently rebuilding this package, and we'll push it asap. Pushed live https://repos.fedorapeople.org/repos/openstack/openstack-juno/epel-7/python-oslo-vmware-0.7.0-2.el7.noarch.rpm https://repos.fedorapeople.org/repos/openstack/openstack-juno/fedora-21/python-oslo-vmware-0.7.0-2.fc22.noarch.rpm Cheers, Alan From Yaniv.Kaul at emc.com Fri Jul 31 09:47:03 2015 From: Yaniv.Kaul at emc.com (Kaul, Yaniv) Date: Fri, 31 Jul 2015 09:47:03 +0000 Subject: [Rdo-list] http://trunk.rdoproject.org/centos7/current/ missing openstack-selinux package Message-ID: <7C4C6F8AC2A31A439365FF37F60AE9DC09AC34@MX202CL03.corp.emc.com> Execution of '/usr/bin/yum -d 0 -e 0 -y list openstack-selinux' returned 1: Error: No matching Packages to list Is there some CI testing of basic installation of this repo? I could not install it for quite some time now, with various failures. [root at lgdrm432 yum.repos.d]# cat /etc/yum.repos.d/delorean.repo [delorean] name=delorean-python-futurist-d03cc4f05f85b7818deb4da181b6024ef10c62cb baseurl=http://trunk.rdoproject.org/centos7/d0/3c/d03cc4f05f85b7818deb4da181b6024ef10c62cb_762e039c enabled=1 gpgcheck=0 Y. -------------- next part -------------- An HTML attachment was scrubbed... URL: From whayutin at redhat.com Fri Jul 31 12:01:48 2015 From: whayutin at redhat.com (whayutin) Date: Fri, 31 Jul 2015 08:01:48 -0400 Subject: [Rdo-list] http://trunk.rdoproject.org/centos7/current/ missing openstack-selinux package In-Reply-To: <7C4C6F8AC2A31A439365FF37F60AE9DC09AC34@MX202CL03.corp.emc.com> References: <7C4C6F8AC2A31A439365FF37F60AE9DC09AC34@MX202CL03.corp.emc.com> Message-ID: <1438344108.3380.1.camel@redhat.com> On Fri, 2015-07-31 at 09:47 +0000, Kaul, Yaniv wrote: > Execution of '/usr/bin/yum -d 0 -e 0 -y list openstack-selinux' > returned 1: Error: No matching Packages to list > > Is there some CI testing of basic installation of this repo? > I could not install it for quite some time now, with various > failures. Yes, rdo liberty w/ the above delorean repo is just now starting to succeed in the last day. Your experience matches CI results https://prod-rdojenkins.rhcloud.com/view/RDO-Liberty-Delorean-Trunk/ > > > > [root at lgdrm432 yum.repos.d]# cat /etc/yum.repos.d/delorean.repo > > > [delorean] > > name=delorean-python-futurist-d03cc4f05f85b7818deb4da181b6024ef10c62cb > > baseurl=http://trunk.rdoproject.org/centos7/d0/3c/d03cc4f05f85b7818deb4da181b6024ef10c62cb_762e039c > > enabled=1 > > gpgcheck=0 > > > > > > Y. > > _______________________________________________ > Rdo-list mailing list > Rdo-list at redhat.com> https://www.redhat.com/mailman/listinfo/rdo-list > > > To unsubscribe: rdo-list-unsubscribe at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From whayutin at redhat.com Fri Jul 31 12:02:19 2015 From: whayutin at redhat.com (whayutin) Date: Fri, 31 Jul 2015 08:02:19 -0400 Subject: [Rdo-list] liberty missing dep unicodecsv Message-ID: <1438344139.3380.2.camel@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=1249035 From apevec at gmail.com Fri Jul 31 15:23:12 2015 From: apevec at gmail.com (Alan Pevec) Date: Fri, 31 Jul 2015 17:23:12 +0200 Subject: [Rdo-list] http://trunk.rdoproject.org/centos7/current/ missing openstack-selinux package In-Reply-To: <7C4C6F8AC2A31A439365FF37F60AE9DC09AC34@MX202CL03.corp.emc.com> References: <7C4C6F8AC2A31A439365FF37F60AE9DC09AC34@MX202CL03.corp.emc.com> Message-ID: > Execution of '/usr/bin/yum -d 0 -e 0 -y list openstack-selinux' returned 1: > Error: No matching Packages to list Delorean repos are add on to the latest RDO repo, you need to install rdo-release-kilo.rpm in addition to delorean.repo. Cheers, Alan