From mtaylor at mty.net.au Fri Sep 1 04:32:57 2017 From: mtaylor at mty.net.au (Matthew Taylor) Date: Fri, 1 Sep 2017 14:32:57 +1000 Subject: [rdo-list] RDO Mitaka with Ceph Jewel ? In-Reply-To: <97e9264d-5ac3-603a-88ca-93a10980ce97@tuxette.fr> References: <8c6847e8-803e-e592-1b0a-216cfb879fd8@tuxette.fr> <59e70bb1-60d6-39d6-1e8d-39b02577f175@mty.net.au> <97e9264d-5ac3-603a-88ca-93a10980ce97@tuxette.fr> Message-ID: To be honest, I can't remember the fine details as it was quite some time ago. Although, I don't recall any significant issues. Perhaps it's best for you to evacuate one of your nova-compute node, prior to running updates. And yeah, as David said, sysvinit -> systemd changes came in during Infernalis. Not a real big deal, although it does change how you interact with Ceph when starting, stopping or restarting components. It's worth familiarising yourself with the docs and changelogs before carrying out any upgrades. Matt. On 1/9/17 00:58, Marianne Lombard wrote: > > Yes, but switching to systemd is not a big issue I think. > > CentOS 7 is systemd-ready :) > > My main question is "will it work fine with Mitaka" ? Do I need to > upgrade the compute node ceph packages (for openstack integration) ? > > I hope the answer is yes but I will be reassured if someone has > already try it > > Marianne (aka Jehane on irc) > > Le 31/08/2017 ? 16:31, David Moreau Simard a ?crit?: >> Hammer to Jewel also changed from upstart/sysvinit to systemd if >> memory serves right ? So it's definitely another tricky part. >> >> And Ceph Luminous just came out too ! :) >> >> David Moreau Simard >> Senior Software Engineer | OpenStack RDO >> >> dmsimard = [irc, github, twitter] >> >> >> On Thu, Aug 31, 2017 at 8:39 AM, Matthew Taylor wrote: >>> Hi, >>> >>> I would probably upgrade Ceph first. >>> >>> Hammer to Infernalis was a big jump, mainly looking at the changes with how >>> the daemon runs under 'ceph' user, instead of 'root'. It also has it's own >>> quirks (ie. ulimits) too. >>> >>> I can also confirm that Mitaka + Infernalis works fine (I have that in >>> production). >>> >>> >>> Matt. >>> >>> >>> On 31/8/17 20:07, Marianne Lombard wrote: >>>> I have an Openstack Mitaka cloud with Ceph Hammer at work >>>> >>>> We are planning to upgrade ceph to jewel soon but we need to wait a bit >>>> before upgrading to Newton (or superior) >>>> >>>> Does any of you run Mitaka with Jewel ? (especially for nova, cinder and >>>> glance) >>>> >>>> Thanks >>>> >>>> Marianne >>>> >>> _______________________________________________ >>> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbowen at redhat.com Fri Sep 1 15:46:19 2017 From: rbowen at redhat.com (Rich Bowen) Date: Fri, 1 Sep 2017 11:46:19 -0400 Subject: [rdo-list] RDO Pike released Message-ID: <4ada07fc-b0d8-aa45-8b7b-0024f9898beb@redhat.com> The RDO community is pleased to announce the general availability of the RDO build for OpenStack Pike for RPM-based distributions, CentOS Linux 7 and Red Hat Enterprise Linux. RDO is suitable for building private, public, and hybrid clouds. Pike is the 16th release from the OpenStack project, which is the work of more than 2300 contributors from around the world. The release is making its way out to the CentOS mirror network, and should be on your favorite mirror site momentarily. The RDO community project curates, packages, builds, tests and maintains a complete OpenStack component set for RHEL and CentOS Linux and is a member of the CentOS Cloud Infrastructure SIG. The Cloud Infrastructure SIG focuses on delivering a great user experience for CentOS Linux users looking to build and maintain their own on-premise, public or hybrid clouds. All work on RDO, and on the downstream release, Red Hat OpenStack Platform, is 100% open source, with all code changes going upstream first. New and Improved Interesting things in the Pike release include: * Ironic now supports booting from Cinder volumes, rolling upgrades and Redfish protocol. * We added OVN support to Packstack. * We added support to install the Horizon plugins for several services in Packstack. Added/Updated packages The following packages and services were added or updated in this release: * Kuryr and Kuryr-kubernetes: an integration between OpenStack and Kubernetes networking. * Senlin: a clustering service for OpenStack clouds. * Shade: a simple client library for interacting with OpenStack clouds, used by Ansible among others. * python-pankoclient: a client library for the event storage and REST API for Ceilometer. * python-scciclient: a ServerView Common Command Interface Client Library, for the FUJITSU iRMC S4 - integrated Remote Management Controller. Other additions include: Python Libraries * os-xenapi * ovsdbapp (deps) * python-daiquiri (deps) * python-deprecation (deps) * python-exabgp * python-json-logger (deps) * python-netmiko (deps) * python-os-traits * python-paunch * python-scciclient * python-scrypt (deps) * python-sphinxcontrib-actdiag (deps) (pending) * python-sphinxcontrib-websupport (deps) * python-stestr (deps) * python-subunit2sql (deps) * python-sushy * shade (SDK) * update XStatic packages (update) * update crudini to 0.9 (deps) (update) * upgrade liberasurecode and pyeclib libraries to 1.5.0 (update) (deps) Tempest Plugins * python-barbican-tests-tempest * python-keystone-testst-tempest * python-kuryr-tests-tempest * python-patrole-tests-tempest * python-vmware-nsx-tests-tempest * python-watcher-tests-tempest Puppet-Modules * puppet-murano * puppet-veritas_hyperscale * puppet-vitrage OpenStack Projects * kuryr * kuryr-kubernetes * openstack-glare * openstack-panko * openstack-senlin * OpenStack Clients * mistral-lib * python-glareclient * python-pankoclient * python-senlinclient Contributors During the Pike cycle, we started the EasyFix initiative, which has resulted in several new people joining our ranks. These include: * Christopher Brown * Anthony Chow * T. Nicole Williams * Ricardo Arguello But, we wouldn't want to overlook anyone. Thank you to all 172 contributors who participated in producing this release: Aditya Prakash Vaja, Alan Bishop, Alan Pevec, Alex Schultz, Alexander Stafeyev, Alfredo Moralejo, Andrii Kroshchenko, Anil, Antoni Segura Puimedon, Arie Bregman, Assaf Muller, Ben Nemec, Bernard Cafarelli, Bogdan Dobrelya, Brent Eagles, Brian Haley, Carlos Gon?alves, Chandan Kumar, Christian Schwede, Christopher Brown, Damien Ciabrini, Dan Radez, Daniel Alvarez, Daniel Farrell, Daniel Mellado, David Moreau Simard, Derek Higgins, Doug Hellmann, Dougal Matthews, Edu Alca?iz, Eduardo Gonzalez, Elise Gafford, Emilien Macchi, Eric Harney, Eyal, Feng Pan, Frederic Lepied, Frederic Lepied, Garth Mollett, Ga?l Chamoulaud, Giulio Fidente, Gorka Eguileor, Hanxi Liu, Harry Rybacki, Honza Pokorny, Ian Main, Igor Yozhikov, Ihar Hrachyshka, Jakub Libosvar, Jakub Ruzicka, Janki, Jason E. Rist, Jason Joyce, Javier Pe?a, Jeffrey Zhang, Jeremy Liu, Ji?? Str?nsk?, Johan Guldmyr, John Eckersberg, John Fulton, John R. Dennis, Jon Schlueter, Juan Antonio Osorio, Juan Badia Payno, Julie Pichon, Julien Danjou, Karim Boumedhel, Koki Sanagi, Lars Kellogg-Stedman, Lee Yarwood, Leif Madsen, Lon Hohberger, Lucas Alvares Gomes, Luigi Toscano, Luis Tom?s, Luke Hinds, Martin Andr?, Martin Kopec, Martin M?gr, Matt Young, Matthias Runge, Michal Pryc, Michele Baldessari, Mike Burns, Mike Fedosin, Mohammed Naser, Oliver Walsh, Parag Nemade, Paul Belanger, Petr Kovar, Pradeep Kilambi, Rabi Mishra, Radomir Dopieralski, Raoul Scarazzini, Ricardo Arguello, Ricardo Noriega, Rob Crittenden, Russell Bryant, Ryan Brady, Ryan Hallisey, Sarath Kumar, Spyros Trigazis, Stephen Finucane, Steve Baker, Steve Gordon, Steven Hardy, Suraj Narwade, Sven Anderson, T. Nichole Williams, Telles N?brega, Terry Wilson, Thierry Vignaud, Thomas Herv?, Thomas Morin, Tim Rozet, Tom Barron, Tony Breeds, Tristan Cacqueray, afazekas, danpawlik, dnyanmpawar, hamzy, inarotzk, j-zimnowoda, kamleshp, marios, mdbooth, michaelhenkel, mkolesni, numansiddique, pawarsandeepu, prateek1192, ratailor, shreshtha90, vakwetu, vtas-hyperscale-ci, yrobla, zhangguoqing, Vladislav Odintsov, Xin Wu, XueFengLiu, Yatin Karel, Yedidyah Bar David, adriano petrich, bcrochet, changzhi, diana, djipko, dprince, dtantsur, eggmaster, eglynn, elmiko, flaper87, gpocentek, gregswift, hguemar, jason guiditta, jprovaznik, mangelajo, marcosflobo, morsik, nmagnezi, sahid, sileht, slagle, trown, vkmc, wes hayutin, xbezdick, zaitcev, and zaneb. Getting Started There are three ways to get started with RDO. To spin up a proof of concept cloud, quickly, and on limited hardware, try an All-In-One Packstack installation. You can run RDO on a single node to get a feel for how it works. https://www.rdoproject.org/install/packstack/ For a production deployment of RDO, use the TripleO Quickstart and you'll be running a production cloud in short order. https://www.rdoproject.org/tripleo/ Finally, if you want to try out OpenStack, but don't have the time or hardware to run it yourself, visit TryStack, where you can use a free public OpenStack instance, running RDO packages, to experiment with the OpenStack management interface and API, launch instances, configure networks, and generally familiarize yourself with OpenStack. (TryStack is not, at this time, running Pike, although it is running RDO.) http://packstack.org/ Getting Help The RDO Project participates in a Q&A service at ask.openstack.org, for more developer-oriented content we recommend joining the rdo-list mailing list. Remember to post a brief introduction about yourself and your RDO story. You can also find extensive documentation on the RDO docs site. The #rdo channel on Freenode IRC is also an excellent place to find help and give help. We also welcome comments and requests on the CentOS mailing lists and the CentOS and TripleO IRC channels (#centos, #centos-devel, and #tripleo on irc.freenode.net), however we have a more focused audience in the RDO venues. Getting Involved To get involved in the OpenStack RPM packaging effort, see the RDO community pages and the CentOS Cloud SIG page. See also the RDO packaging documentation. Join us in #rdo on the Freenode IRC network, and follow us at @RDOCommunity on Twitter. If you prefer Facebook, we're there tooi ( http://facebook.com/RDOCommunity ), and also Google+ ( http://tm3.org/rdogplus ) From Kevin.Fox at pnnl.gov Fri Sep 1 15:50:45 2017 From: Kevin.Fox at pnnl.gov (Fox, Kevin M) Date: Fri, 1 Sep 2017 15:50:45 +0000 Subject: [rdo-list] RDO Mitaka with Ceph Jewel ? In-Reply-To: References: <8c6847e8-803e-e592-1b0a-216cfb879fd8@tuxette.fr> <59e70bb1-60d6-39d6-1e8d-39b02577f175@mty.net.au> <97e9264d-5ac3-603a-88ca-93a10980ce97@tuxette.fr>, Message-ID: <1A3C52DFCD06494D8528644858247BF01BFDC6D7@EX10MBOX03.pnnl.gov> We have run RDO Mitaka with Jewel with no ill effects. We upgraded from Infernalis. Just had to follow the upgrade notes closely, and if there is any doubts there are any remaining Infernalis clients, don't finish upgrading the cluster settings related to dropping older client support. Thanks, Kevin ________________________________ From: rdo-list-bounces at redhat.com [rdo-list-bounces at redhat.com] on behalf of Matthew Taylor [mtaylor at mty.net.au] Sent: Thursday, August 31, 2017 9:32 PM To: rdo-list at redhat.com Subject: Re: [rdo-list] RDO Mitaka with Ceph Jewel ? To be honest, I can't remember the fine details as it was quite some time ago. Although, I don't recall any significant issues. Perhaps it's best for you to evacuate one of your nova-compute node, prior to running updates. And yeah, as David said, sysvinit -> systemd changes came in during Infernalis. Not a real big deal, although it does change how you interact with Ceph when starting, stopping or restarting components. It's worth familiarising yourself with the docs and changelogs before carrying out any upgrades. Matt. On 1/9/17 00:58, Marianne Lombard wrote: Yes, but switching to systemd is not a big issue I think. CentOS 7 is systemd-ready :) My main question is "will it work fine with Mitaka" ? Do I need to upgrade the compute node ceph packages (for openstack integration) ? I hope the answer is yes but I will be reassured if someone has already try it Marianne (aka Jehane on irc) Le 31/08/2017 ? 16:31, David Moreau Simard a ?crit : Hammer to Jewel also changed from upstart/sysvinit to systemd if memory serves right ? So it's definitely another tricky part. And Ceph Luminous just came out too ! :) David Moreau Simard Senior Software Engineer | OpenStack RDO dmsimard = [irc, github, twitter] On Thu, Aug 31, 2017 at 8:39 AM, Matthew Taylor wrote: Hi, I would probably upgrade Ceph first. Hammer to Infernalis was a big jump, mainly looking at the changes with how the daemon runs under 'ceph' user, instead of 'root'. It also has it's own quirks (ie. ulimits) too. I can also confirm that Mitaka + Infernalis works fine (I have that in production). Matt. On 31/8/17 20:07, Marianne Lombard wrote: I have an Openstack Mitaka cloud with Ceph Hammer at work We are planning to upgrade ceph to jewel soon but we need to wait a bit before upgrading to Newton (or superior) Does any of you run Mitaka with Jewel ? (especially for nova, cinder and glance) Thanks Marianne _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tim.Bell at cern.ch Fri Sep 1 16:57:03 2017 From: Tim.Bell at cern.ch (Tim Bell) Date: Fri, 1 Sep 2017 16:57:03 +0000 Subject: [rdo-list] RDO Pike released In-Reply-To: <4ada07fc-b0d8-aa45-8b7b-0024f9898beb@redhat.com> References: <4ada07fc-b0d8-aa45-8b7b-0024f9898beb@redhat.com> Message-ID: Congratulations to all. Looking forward to migrating at CERN. Tim -----Original Message----- From: on behalf of Rich Bowen Date: Friday, 1 September 2017 at 18:09 To: "rdo-list at redhat.com" Subject: [rdo-list] RDO Pike released The RDO community is pleased to announce the general availability of the RDO build for OpenStack Pike for RPM-based distributions, CentOS Linux 7 and Red Hat Enterprise Linux. RDO is suitable for building private, public, and hybrid clouds. Pike is the 16th release from the OpenStack project, which is the work of more than 2300 contributors from around the world. The release is making its way out to the CentOS mirror network, and should be on your favorite mirror site momentarily. The RDO community project curates, packages, builds, tests and maintains a complete OpenStack component set for RHEL and CentOS Linux and is a member of the CentOS Cloud Infrastructure SIG. The Cloud Infrastructure SIG focuses on delivering a great user experience for CentOS Linux users looking to build and maintain their own on-premise, public or hybrid clouds. All work on RDO, and on the downstream release, Red Hat OpenStack Platform, is 100% open source, with all code changes going upstream first. New and Improved Interesting things in the Pike release include: * Ironic now supports booting from Cinder volumes, rolling upgrades and Redfish protocol. * We added OVN support to Packstack. * We added support to install the Horizon plugins for several services in Packstack. Added/Updated packages The following packages and services were added or updated in this release: * Kuryr and Kuryr-kubernetes: an integration between OpenStack and Kubernetes networking. * Senlin: a clustering service for OpenStack clouds. * Shade: a simple client library for interacting with OpenStack clouds, used by Ansible among others. * python-pankoclient: a client library for the event storage and REST API for Ceilometer. * python-scciclient: a ServerView Common Command Interface Client Library, for the FUJITSU iRMC S4 - integrated Remote Management Controller. Other additions include: Python Libraries * os-xenapi * ovsdbapp (deps) * python-daiquiri (deps) * python-deprecation (deps) * python-exabgp * python-json-logger (deps) * python-netmiko (deps) * python-os-traits * python-paunch * python-scciclient * python-scrypt (deps) * python-sphinxcontrib-actdiag (deps) (pending) * python-sphinxcontrib-websupport (deps) * python-stestr (deps) * python-subunit2sql (deps) * python-sushy * shade (SDK) * update XStatic packages (update) * update crudini to 0.9 (deps) (update) * upgrade liberasurecode and pyeclib libraries to 1.5.0 (update) (deps) Tempest Plugins * python-barbican-tests-tempest * python-keystone-testst-tempest * python-kuryr-tests-tempest * python-patrole-tests-tempest * python-vmware-nsx-tests-tempest * python-watcher-tests-tempest Puppet-Modules * puppet-murano * puppet-veritas_hyperscale * puppet-vitrage OpenStack Projects * kuryr * kuryr-kubernetes * openstack-glare * openstack-panko * openstack-senlin * OpenStack Clients * mistral-lib * python-glareclient * python-pankoclient * python-senlinclient Contributors During the Pike cycle, we started the EasyFix initiative, which has resulted in several new people joining our ranks. These include: * Christopher Brown * Anthony Chow * T. Nicole Williams * Ricardo Arguello But, we wouldn't want to overlook anyone. Thank you to all 172 contributors who participated in producing this release: Aditya Prakash Vaja, Alan Bishop, Alan Pevec, Alex Schultz, Alexander Stafeyev, Alfredo Moralejo, Andrii Kroshchenko, Anil, Antoni Segura Puimedon, Arie Bregman, Assaf Muller, Ben Nemec, Bernard Cafarelli, Bogdan Dobrelya, Brent Eagles, Brian Haley, Carlos Gon?alves, Chandan Kumar, Christian Schwede, Christopher Brown, Damien Ciabrini, Dan Radez, Daniel Alvarez, Daniel Farrell, Daniel Mellado, David Moreau Simard, Derek Higgins, Doug Hellmann, Dougal Matthews, Edu Alca?iz, Eduardo Gonzalez, Elise Gafford, Emilien Macchi, Eric Harney, Eyal, Feng Pan, Frederic Lepied, Frederic Lepied, Garth Mollett, Ga?l Chamoulaud, Giulio Fidente, Gorka Eguileor, Hanxi Liu, Harry Rybacki, Honza Pokorny, Ian Main, Igor Yozhikov, Ihar Hrachyshka, Jakub Libosvar, Jakub Ruzicka, Janki, Jason E. Rist, Jason Joyce, Javier Pe?a, Jeffrey Zhang, Jeremy Liu, Ji?? Str?nsk?, Johan Guldmyr, John Eckersberg, John Fulton, John R. Dennis, Jon Schlueter, Juan Antonio Osorio, Juan Badia Payno, Julie Pichon, Julien Danjou, Karim Boumedhel, Koki Sanagi, Lars Kellogg-Stedman, Lee Yarwood, Leif Madsen, Lon Hohberger, Lucas Alvares Gomes, Luigi Toscano, Luis Tom?s, Luke Hinds, Martin Andr?, Martin Kopec, Martin M?gr, Matt Young, Matthias Runge, Michal Pryc, Michele Baldessari, Mike Burns, Mike Fedosin, Mohammed Naser, Oliver Walsh, Parag Nemade, Paul Belanger, Petr Kovar, Pradeep Kilambi, Rabi Mishra, Radomir Dopieralski, Raoul Scarazzini, Ricardo Arguello, Ricardo Noriega, Rob Crittenden, Russell Bryant, Ryan Brady, Ryan Hallisey, Sarath Kumar, Spyros Trigazis, Stephen Finucane, Steve Baker, Steve Gordon, Steven Hardy, Suraj Narwade, Sven Anderson, T. Nichole Williams, Telles N?brega, Terry Wilson, Thierry Vignaud, Thomas Herv?, Thomas Morin, Tim Rozet, Tom Barron, Tony Breeds, Tristan Cacqueray, afazekas, danpawlik, dnyanmpawar, hamzy, inarotzk, j-zimnowoda, kamleshp, marios, mdbooth, michaelhenkel, mkolesni, numansiddique, pawarsandeepu, prateek1192, ratailor, shreshtha90, vakwetu, vtas-hyperscale-ci, yrobla, zhangguoqing, Vladislav Odintsov, Xin Wu, XueFengLiu, Yatin Karel, Yedidyah Bar David, adriano petrich, bcrochet, changzhi, diana, djipko, dprince, dtantsur, eggmaster, eglynn, elmiko, flaper87, gpocentek, gregswift, hguemar, jason guiditta, jprovaznik, mangelajo, marcosflobo, morsik, nmagnezi, sahid, sileht, slagle, trown, vkmc, wes hayutin, xbezdick, zaitcev, and zaneb. Getting Started There are three ways to get started with RDO. To spin up a proof of concept cloud, quickly, and on limited hardware, try an All-In-One Packstack installation. You can run RDO on a single node to get a feel for how it works. https://www.rdoproject.org/install/packstack/ For a production deployment of RDO, use the TripleO Quickstart and you'll be running a production cloud in short order. https://www.rdoproject.org/tripleo/ Finally, if you want to try out OpenStack, but don't have the time or hardware to run it yourself, visit TryStack, where you can use a free public OpenStack instance, running RDO packages, to experiment with the OpenStack management interface and API, launch instances, configure networks, and generally familiarize yourself with OpenStack. (TryStack is not, at this time, running Pike, although it is running RDO.) http://packstack.org/ Getting Help The RDO Project participates in a Q&A service at ask.openstack.org, for more developer-oriented content we recommend joining the rdo-list mailing list. Remember to post a brief introduction about yourself and your RDO story. You can also find extensive documentation on the RDO docs site. The #rdo channel on Freenode IRC is also an excellent place to find help and give help. We also welcome comments and requests on the CentOS mailing lists and the CentOS and TripleO IRC channels (#centos, #centos-devel, and #tripleo on irc.freenode.net), however we have a more focused audience in the RDO venues. Getting Involved To get involved in the OpenStack RPM packaging effort, see the RDO community pages and the CentOS Cloud SIG page. See also the RDO packaging documentation. Join us in #rdo on the Freenode IRC network, and follow us at @RDOCommunity on Twitter. If you prefer Facebook, we're there tooi ( http://facebook.com/RDOCommunity ), and also Google+ ( http://tm3.org/rdogplus ) _______________________________________________ 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 rdo-list at dseven.org Fri Sep 1 19:14:46 2017 From: rdo-list at dseven.org (iain MacDonnell) Date: Fri, 1 Sep 2017 12:14:46 -0700 Subject: [rdo-list] RPM (minimum version) dependencies (pike) Message-ID: Experimenting with upgrading RDO Ocata to Pike in my lab, and have run into a couple of RPM minimum version dependency issues. 1) neutron-server and agents fail to start, with: # neutron-server Guru meditation now registers SIGUSR1 and SIGUSR2 by default for backward compatibility. SIGUSR1 will no longer be registered in a future release, so please use SIGUSR2 to generate reports. Traceback (most recent call last): File "/usr/bin/neutron-server", line 6, in from neutron.cmd.eventlet.server import main File "/usr/lib/python2.7/site-packages/neutron/cmd/eventlet/__init__.py", line 15, in eventlet_utils.monkey_patch() File "/usr/lib/python2.7/site-packages/neutron/common/eventlet_utils.py", line 25, in monkey_patch p_c_e = importutils.import_module('pyroute2.config.asyncio') File "/usr/lib/python2.7/site-packages/oslo_utils/importutils.py", line 73, in import_module __import__(import_str) ImportError: No module named asyncio I have: # rpm -q python2-pyroute2 python2-pyroute2-0.4.8-1.el7.noarch which meets the dependency: # rpm -qR python-neutron-11.0.0-1.el7.noarch | grep pyroute2 python-pyroute2 >= 0.4.3 but the latest version (in the openstack-pike repo) is 0.4.19 (and neutron works after explicitly updating to that). Seems that the "Requires" in python-neutron needs to be bumped up. 2) Horizon fails to start due to https://bugs.launchpad.net/horizon/+bug/1701765 Per comments in that bug, python-XStatic-Bootstrap-SCSS >= 3.3.7.1 is required., but we have: # rpm -qR openstack-dashboard-12.0.0-1.el7.noarch | grep SCSS python-XStatic-Bootstrap-SCSS So it seems that the minimum version needs to be added to that "Requires". I can file a bug (or two) on this if it'd be helpful... ? ~iain From hguemar at fedoraproject.org Fri Sep 1 20:10:33 2017 From: hguemar at fedoraproject.org (=?UTF-8?Q?Ha=C3=AFkel?=) Date: Fri, 1 Sep 2017 22:10:33 +0200 Subject: [rdo-list] RPM (minimum version) dependencies (pike) In-Reply-To: References: Message-ID: 2017-09-01 21:14 GMT+02:00 iain MacDonnell : > Experimenting with upgrading RDO Ocata to Pike in my lab, and have run > into a couple of RPM minimum version dependency issues. > Thanks for your quick feedback, it's much appreciated. > 1) neutron-server and agents fail to start, with: > > # neutron-server > Guru meditation now registers SIGUSR1 and SIGUSR2 by default for > backward compatibility. SIGUSR1 will no longer be registered in a > future release, so please use SIGUSR2 to generate reports. > Traceback (most recent call last): > File "/usr/bin/neutron-server", line 6, in > from neutron.cmd.eventlet.server import main > File "/usr/lib/python2.7/site-packages/neutron/cmd/eventlet/__init__.py", > line 15, in > eventlet_utils.monkey_patch() > File "/usr/lib/python2.7/site-packages/neutron/common/eventlet_utils.py", > line 25, in monkey_patch > p_c_e = importutils.import_module('pyroute2.config.asyncio') > File "/usr/lib/python2.7/site-packages/oslo_utils/importutils.py", > line 73, in import_module > __import__(import_str) > ImportError: No module named asyncio > Ok, I need to look into that. asyncio is a py3 thing only, it shouldn't appear at runtime. > > I have: > > # rpm -q python2-pyroute2 > python2-pyroute2-0.4.8-1.el7.noarch > > which meets the dependency: > > # rpm -qR python-neutron-11.0.0-1.el7.noarch | grep pyroute2 > python-pyroute2 >= 0.4.3 > > > but the latest version (in the openstack-pike repo) is 0.4.19 (and > neutron works after explicitly updating to that). Seems that the > "Requires" in python-neutron needs to be bumped up. > Ok, if you have a RDO gerrit account, you may submit the change directly > > 2) Horizon fails to start due to https://bugs.launchpad.net/horizon/+bug/1701765 > > Per comments in that bug, python-XStatic-Bootstrap-SCSS >= 3.3.7.1 is > required., but we have: > > # rpm -qR openstack-dashboard-12.0.0-1.el7.noarch | grep SCSS > python-XStatic-Bootstrap-SCSS > > > So it seems that the minimum version needs to be added to that "Requires". > > I can file a bug (or two) on this if it'd be helpful... ? > > ~iain > Yes, assign me => hguemar AT redhat DOT org You can also submit changes directly where you see fit :) 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 rdo-list at dseven.org Fri Sep 1 21:19:45 2017 From: rdo-list at dseven.org (iain MacDonnell) Date: Fri, 1 Sep 2017 14:19:45 -0700 Subject: [rdo-list] RPM (minimum version) dependencies (pike) In-Reply-To: References: Message-ID: On Fri, Sep 1, 2017 at 1:10 PM, Ha?kel wrote: > 2017-09-01 21:14 GMT+02:00 iain MacDonnell : >> Experimenting with upgrading RDO Ocata to Pike in my lab, and have run >> into a couple of RPM minimum version dependency issues. >> > > Thanks for your quick feedback, it's much appreciated. > >> 1) neutron-server and agents fail to start, with: >> >> # neutron-server >> Guru meditation now registers SIGUSR1 and SIGUSR2 by default for >> backward compatibility. SIGUSR1 will no longer be registered in a >> future release, so please use SIGUSR2 to generate reports. >> Traceback (most recent call last): >> File "/usr/bin/neutron-server", line 6, in >> from neutron.cmd.eventlet.server import main >> File "/usr/lib/python2.7/site-packages/neutron/cmd/eventlet/__init__.py", >> line 15, in >> eventlet_utils.monkey_patch() >> File "/usr/lib/python2.7/site-packages/neutron/common/eventlet_utils.py", >> line 25, in monkey_patch >> p_c_e = importutils.import_module('pyroute2.config.asyncio') >> File "/usr/lib/python2.7/site-packages/oslo_utils/importutils.py", >> line 73, in import_module >> __import__(import_str) >> ImportError: No module named asyncio >> > > Ok, I need to look into that. asyncio is a py3 thing only, it > shouldn't appear at runtime. > >> >> I have: >> >> # rpm -q python2-pyroute2 >> python2-pyroute2-0.4.8-1.el7.noarch >> >> which meets the dependency: >> >> # rpm -qR python-neutron-11.0.0-1.el7.noarch | grep pyroute2 >> python-pyroute2 >= 0.4.3 >> >> >> but the latest version (in the openstack-pike repo) is 0.4.19 (and >> neutron works after explicitly updating to that). Seems that the >> "Requires" in python-neutron needs to be bumped up. >> > > Ok, if you have a RDO gerrit account, you may submit the change directly > >> >> 2) Horizon fails to start due to https://bugs.launchpad.net/horizon/+bug/1701765 >> >> Per comments in that bug, python-XStatic-Bootstrap-SCSS >= 3.3.7.1 is >> required., but we have: >> >> # rpm -qR openstack-dashboard-12.0.0-1.el7.noarch | grep SCSS >> python-XStatic-Bootstrap-SCSS >> >> >> So it seems that the minimum version needs to be added to that "Requires". >> >> I can file a bug (or two) on this if it'd be helpful... ? >> >> ~iain >> > > Yes, assign me => hguemar AT redhat DOT org > You can also submit changes directly where you see fit :) I don't think I have privileges to do either of those things ;) but I've reported the two issues as bugs 1487766 and 1487767 Thanks! ~iain From hguemar at fedoraproject.org Mon Sep 4 15:00:04 2017 From: hguemar at fedoraproject.org (hguemar at fedoraproject.org) Date: Mon, 4 Sep 2017 15:00:04 +0000 (UTC) Subject: [rdo-list] [Fedocal] Reminder meeting : RDO meeting Message-ID: <20170904150004.5F85160005A2@fedocal02.phx2.fedoraproject.org> Dear all, You are kindly invited to the meeting: RDO meeting on 2017-09-06 from 15:00:00 to 16:00:00 UTC At rdo at irc.freenode.net The meeting will be about: RDO IRC meeting [Agenda at https://etherpad.openstack.org/p/RDO-Meeting ](https://etherpad.openstack.org/p/RDO-Meeting) Every Wednesday on #rdo on Freenode IRC Source: https://apps.fedoraproject.org/calendar/meeting/2017/ From adarazs at redhat.com Mon Sep 4 15:58:38 2017 From: adarazs at redhat.com (Attila Darazs) Date: Mon, 4 Sep 2017 17:58:38 +0200 Subject: [rdo-list] Requesting submit rights for rdoproject.org config & ci-config for Gabriele & Sagi Message-ID: We're working on the TripleO promotion pipeline and it would be useful if these two core tripleo-ci/quickstart members could submit changes to the rdoproject config & ci-config repos I'd also like to get explicit permission to submit stuff to "config" as I was previously granted the permission by Alan, but it was only for experimenting on something else a while ago. I think our restrictions on these repos could be "only submit if it's tripleo related". Please let me know what you think. Best regards, Attila From hguemar at redhat.com Mon Sep 4 16:52:30 2017 From: hguemar at redhat.com (=?UTF-8?B?SGHDr2tlbCBHdcOpbWFy?=) Date: Mon, 4 Sep 2017 18:52:30 +0200 Subject: [rdo-list] Requesting submit rights for rdoproject.org config & ci-config for Gabriele & Sagi In-Reply-To: References: Message-ID: <86ab4be2-270b-1666-fee1-6b64543d9b77@redhat.com> On 04/09/17 17:58, Attila Darazs wrote: > We're working on the TripleO promotion pipeline and it would be useful > if these two core tripleo-ci/quickstart members could submit changes to > the rdoproject config & ci-config repos > > I'd also like to get explicit permission to submit stuff to "config" as > I was previously granted the permission by Alan, but it was only for > experimenting on something else a while ago. > > I think our restrictions on these repos could be "only submit if it's > tripleo related". > > Please let me know what you think. > > Best regards, > Attila > > _______________________________________________ > 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 think we should formalize policies on how to add/remove core on the various projects. I will be drafting something for the packaging side but I'd like CI group to work something similar. Regards, H. From chkumar246 at gmail.com Tue Sep 5 01:30:03 2017 From: chkumar246 at gmail.com (chkumar246 at gmail.com) Date: Tue, 5 Sep 2017 01:30:03 +0000 (UTC) Subject: [rdo-list] [Fedocal] Reminder meeting : RDO Office Hours Message-ID: <20170905013003.9104B60005A2@fedocal02.phx2.fedoraproject.org> Dear all, You are kindly invited to the meeting: RDO Office Hours on 2017-09-05 from 13:30:00 to 15:30:00 UTC The meeting will be about: The meeting will be about RDO Office Hour. Aim: To keep up with increasing participation, we'll host office hours to add more easy fixes and provide mentoring to newcomers. [Agenda at RDO Office Hour easyfixes](https://review.rdoproject.org/etherpad/p/rdo-office-hour-easyfixes) Source: https://apps.fedoraproject.org/calendar/meeting/6374/ From peter.kirby at objectstream.com Tue Sep 5 14:52:44 2017 From: peter.kirby at objectstream.com (Peter Kirby) Date: Tue, 5 Sep 2017 09:52:44 -0500 Subject: [rdo-list] Upgrading from Newton to Ocata Message-ID: Hello RDO Team, I'm still fairly new to OpenStack so this may be because I didn't read the documentation closely enough before the upgrade, but I ran into an issue that I was hoping to get some clarification on. I used this page to perform the upgrade [1]. Everything went smoothly until setting up cells for the first time. I had not done this in Newton. I got to step 14: "List registered cells to get their UUIDs:" which worked great. I had cell0 and cell1 created from previous steps, everything seemed to be in place. The next step says: "Pass the UUIDs to the map_instances command to map instances to cells:" with the following command example: "# su -s /bin/sh -c "nova-manage cell_v2 map_instances --cell_uuid " nova" I took this to mean run that command for both cell0 and cell1. So I did. That mapped all my instances to cell0. I then started seeing errors like this in the logs: ERROR nova.api.openstack.extensions DriverLoadFailure: Failed to load transport driver "none": No 'oslo.messaging.drivers' driver found, looking for u'none' After much searching, I found the transport_url for cell0 in the database was set to "none:///" which is what was causing the error. I was able to create new instances, but not run any commands at all on current instances and all new instances were brought up in cell1. So I moved all current instances to cell1 by manually updating the database and all the errors went away and everything is running correctly. So my question is, did I do something else wrong that would cause this not to work properly or should those instructions be clarified a bit to say map instances to cell1, not cell0? In my searching I did find other guides that did all these same things, but specifically said map instances to cell1. Thank you, Peter [1] - https://www.rdoproject.org/install/upgrading-rdo-2/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From chkumar246 at gmail.com Tue Sep 5 15:33:28 2017 From: chkumar246 at gmail.com (Chandan kumar) Date: Tue, 5 Sep 2017 21:03:28 +0530 Subject: [rdo-list] [Minutes] RDO Office Hours - 2017-09-05 Message-ID: =================================== #rdo: RDO Office Hours - 2017-09-05 =================================== Meeting started by chandankumar at 13:32:11 UTC. The full logs are available at http://eavesdrop.openstack.org/meetings/rdo_office_hours___2017_09_05/2017/rdo_office_hours___2017_09_05.2017-09-05-13.32.log.html . Meeting summary --------------- * Roll Call (chandankumar, 13:33:45) * RDO Easyfix reviews comes down to 4 \o/ (chandankumar, 14:24:28) * LINK: https://review.rdoproject.org/r/#/q/status:open+branch:rpm-master+easyfix (chandankumar, 14:24:41) Meeting ended at 15:32:10 UTC. People present (lines said) --------------------------- * chandankumar (26) * rdogerrit (19) * hguemar (13) * jpena (6) * jschlueter (5) * openstack (5) * EmilienM (4) * arxcruz (2) * apevec (2) Generated by `MeetBot`_ 0.1.4 From dms at redhat.com Wed Sep 6 13:10:15 2017 From: dms at redhat.com (David Moreau Simard) Date: Wed, 6 Sep 2017 09:10:15 -0400 Subject: [rdo-list] RDO at the OpenStack PTG In-Reply-To: References: Message-ID: Hi! The RDO community project [1] provides RPM OpenStack packages for deploying on RHEL and CentOS. RDO is analogous to Ubuntu Cloud Archive (UCA) which provides OpenStack packages for installing on Ubuntu. I'm no marketing or sales guy, I'm part of the RDO engineering team in charge of building, packaging, testing and shipping RDO. If you happen to be at the PTG and would like to chat about RDO, please let me know off-thread so we can set aside some time. I'm always excited to talk with users and operators ! Thanks and see you there ! [1]: http://rdoproject.org David Moreau Simard Senior Software Engineer | Openstack RDO dmsimard = [irc, github, twitter] -------------- next part -------------- An HTML attachment was scrubbed... URL: From javier.pena at redhat.com Wed Sep 6 15:47:11 2017 From: javier.pena at redhat.com (Javier Pena) Date: Wed, 6 Sep 2017 11:47:11 -0400 (EDT) Subject: [rdo-list] [Meeting] RDO meeting (2017-09-06) Minutes In-Reply-To: <1525542143.4536211.1504712801997.JavaMail.zimbra@redhat.com> Message-ID: <754835116.4536312.1504712831659.JavaMail.zimbra@redhat.com> ============================== #rdo: RDO meeting - 2017-09-06 ============================== Meeting started by jpena at 15:00:38 UTC. The full logs are available at http://eavesdrop.openstack.org/meetings/rdo_meeting___2017_09_06/2017/rdo_meeting___2017_09_06.2017-09-06-15.00.log.html . Meeting summary --------------- * roll call (jpena, 15:01:01) * rdopkg-0.45.0 (jpena, 15:04:38) * changelog in release commit message: https://softwarefactory-project.io/r/#/c/9503/1//COMMIT_MSG (jruzicka, 15:08:14) * Python 3 support available with python3-rdopkg (jruzicka, 15:08:33) * Fedora review is ready for approval after 2 years \o/ https://bugzilla.redhat.com/show_bug.cgi?id=1246199 (jruzicka, 15:09:19) * Defining core contributors policies (jpena, 15:17:43) * LINK: https://docs.openstack.org/contributor-guide/docs-review.html#achieving-core-reviewer-status (PagliaccisCloud, 15:21:48) * ACTION: hguemar prepare a proposal to define how to become on individual packages and distro (hguemar, 15:24:00) * open floor (jpena, 15:26:23) * Chair for the next meeting (jpena, 15:34:08) * ACTION: chandankumar to chair the next meeting (jpena, 15:36:47) Meeting ended at 15:39:05 UTC. Action items, by person ----------------------- * chandankumar * chandankumar to chair the next meeting * hguemar * hguemar prepare a proposal to define how to become on individual packages and distro People present (lines said) --------------------------- * hguemar (28) * jpena (27) * jruzicka (22) * chandankumar (16) * PagliaccisCloud (10) * openstack (10) * rdogerrit (2) * Duck (2) * rdobot (1) * dmsimard (1) * myoung (1) Generated by `MeetBot`_ 0.1.4 From dms at redhat.com Thu Sep 7 20:05:02 2017 From: dms at redhat.com (David Moreau Simard) Date: Thu, 7 Sep 2017 16:05:02 -0400 Subject: [rdo-list] Outage: RDO Infrastructure Message-ID: Hi, There is currently an infrastructure outage affecting parts of RDO's infrastructure, for example: - logs.rdoproject.org, thirdparty.logs.rdoproject.org & centos.logs.rdoproject.org - review.rdoproject.org - www.rdoproject.org - registry.rdoproject.org - images.rdoproject.org - Parts of third party CI against review.openstack.org Mirrors providing RDO packages such as trunk.rdoproject.org, buildlogs.centos.org and mirror.centos.org are unaffected. However, new trunk package builds are not currently being processed. Engineers are already working on resolving the situation and we'll provide an update ASAP. Thanks, David Moreau Simard Senior Software Engineer | OpenStack RDO dmsimard = [irc, github, twitter] From dms at redhat.com Fri Sep 8 01:04:57 2017 From: dms at redhat.com (David Moreau Simard) Date: Thu, 7 Sep 2017 21:04:57 -0400 Subject: [rdo-list] Outage: RDO Infrastructure In-Reply-To: References: Message-ID: Things have started recovering progressively for the past hour or so. We're currently going through our servers to ensure everything is healthy. David Moreau Simard Senior Software Engineer | OpenStack RDO dmsimard = [irc, github, twitter] On Thu, Sep 7, 2017 at 4:05 PM, David Moreau Simard wrote: > Hi, > > There is currently an infrastructure outage affecting parts of RDO's > infrastructure, for example: > - logs.rdoproject.org, thirdparty.logs.rdoproject.org & > centos.logs.rdoproject.org > - review.rdoproject.org > - www.rdoproject.org > - registry.rdoproject.org > - images.rdoproject.org > - Parts of third party CI against review.openstack.org > > Mirrors providing RDO packages such as trunk.rdoproject.org, > buildlogs.centos.org and mirror.centos.org are unaffected. > However, new trunk package builds are not currently being processed. > > Engineers are already working on resolving the situation and we'll > provide an update ASAP. > > Thanks, > > David Moreau Simard > Senior Software Engineer | OpenStack RDO > > dmsimard = [irc, github, twitter] From dms at redhat.com Fri Sep 8 02:32:48 2017 From: dms at redhat.com (David Moreau Simard) Date: Thu, 7 Sep 2017 22:32:48 -0400 Subject: [rdo-list] Outage: RDO Infrastructure In-Reply-To: References: Message-ID: We confirm that everything is back online and appears to be in order. Please let us know here or on #rdo on freenode if you notice anything unusual. Thanks. David Moreau Simard Senior Software Engineer | OpenStack RDO dmsimard = [irc, github, twitter] On Thu, Sep 7, 2017 at 9:04 PM, David Moreau Simard wrote: > Things have started recovering progressively for the past hour or so. > > We're currently going through our servers to ensure everything is healthy. > > David Moreau Simard > Senior Software Engineer | OpenStack RDO > > dmsimard = [irc, github, twitter] > > > On Thu, Sep 7, 2017 at 4:05 PM, David Moreau Simard wrote: >> Hi, >> >> There is currently an infrastructure outage affecting parts of RDO's >> infrastructure, for example: >> - logs.rdoproject.org, thirdparty.logs.rdoproject.org & >> centos.logs.rdoproject.org >> - review.rdoproject.org >> - www.rdoproject.org >> - registry.rdoproject.org >> - images.rdoproject.org >> - Parts of third party CI against review.openstack.org >> >> Mirrors providing RDO packages such as trunk.rdoproject.org, >> buildlogs.centos.org and mirror.centos.org are unaffected. >> However, new trunk package builds are not currently being processed. >> >> Engineers are already working on resolving the situation and we'll >> provide an update ASAP. >> >> Thanks, >> >> David Moreau Simard >> Senior Software Engineer | OpenStack RDO >> >> dmsimard = [irc, github, twitter] From moreira.belmiro.email.lists at gmail.com Fri Sep 8 09:28:51 2017 From: moreira.belmiro.email.lists at gmail.com (Belmiro Moreira) Date: Fri, 8 Sep 2017 11:28:51 +0200 Subject: [rdo-list] openstack-ec2-api on Pike Message-ID: Hi, I'm starting to look at RDO packages for Pike and noticed that openstack-ec2-api with tag "cloud7-openstack-pike-release" is version 4.1.0. For Pike shouldn't it be 5.0.1? thanks, Belmiro -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbowen at redhat.com Fri Sep 8 12:53:31 2017 From: rbowen at redhat.com (Rich Bowen) Date: Fri, 8 Sep 2017 08:53:31 -0400 Subject: [rdo-list] Outage: RDO Infrastructure In-Reply-To: References: Message-ID: <26fb078d-e861-faea-f46a-1b932cb6c679@redhat.com> Thanks for all the work on this. On 09/07/2017 10:32 PM, David Moreau Simard wrote: > We confirm that everything is back online and appears to be in order. > > Please let us know here or on #rdo on freenode if you notice anything unusual. > > Thanks. > > David Moreau Simard > Senior Software Engineer | OpenStack RDO > > dmsimard = [irc, github, twitter] > > > On Thu, Sep 7, 2017 at 9:04 PM, David Moreau Simard wrote: >> Things have started recovering progressively for the past hour or so. >> >> We're currently going through our servers to ensure everything is healthy. >> >> David Moreau Simard >> Senior Software Engineer | OpenStack RDO >> >> dmsimard = [irc, github, twitter] >> >> >> On Thu, Sep 7, 2017 at 4:05 PM, David Moreau Simard wrote: >>> Hi, >>> >>> There is currently an infrastructure outage affecting parts of RDO's >>> infrastructure, for example: >>> - logs.rdoproject.org, thirdparty.logs.rdoproject.org & >>> centos.logs.rdoproject.org >>> - review.rdoproject.org >>> - www.rdoproject.org >>> - registry.rdoproject.org >>> - images.rdoproject.org >>> - Parts of third party CI against review.openstack.org >>> >>> Mirrors providing RDO packages such as trunk.rdoproject.org, >>> buildlogs.centos.org and mirror.centos.org are unaffected. >>> However, new trunk package builds are not currently being processed. >>> >>> Engineers are already working on resolving the situation and we'll >>> provide an update ASAP. >>> >>> Thanks, >>> >>> David Moreau Simard >>> Senior Software Engineer | OpenStack RDO >>> >>> dmsimard = [irc, github, twitter] > > _______________________________________________ > 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 RDO Community Liaison http://rdoproject.org @RDOCommunity From honza at redhat.com Fri Sep 8 14:15:15 2017 From: honza at redhat.com (Honza Pokorny) Date: Fri, 8 Sep 2017 11:15:15 -0300 Subject: [rdo-list] Outage: RDO Infrastructure In-Reply-To: References: Message-ID: <20170908141515.xbsmn7q7p4ab5dcs@localhost.localdomain> I'm still experiencing issues: When running (which I run regularly, and it usually works for me): $ bash devmode.sh --no-gate --ovb --delete-all-stacks I get the following error: TASK [ovb-manage-stack : Return stack state] *********************************** task path: /home/hpokorny/.quickstart/usr/local/share/ansible/roles/ovb-manage-stack/tasks/ovb-create-stack.yml:68 Friday 08 September 2017 11:12:22 -0300 (0:00:10.345) 0:01:05.262 ****** changed: [localhost] => {"censored": "the output has been hidden due to the fact that 'no_log: true' was specified for this result"} TASK [ovb-manage-stack : Show stack status] ************************************ task path: /home/hpokorny/.quickstart/usr/local/share/ansible/roles/ovb-manage-stack/tasks/ovb-create-stack.yml:92 Friday 08 September 2017 11:13:06 -0300 (0:00:43.858) 0:01:49.120 ****** ok: [localhost] => { "stack_status.stdout_lines": [ "| stack_status | CREATE_FAILED |" ] } TASK [ovb-manage-stack : Fail if stack did not deploy successfully] ************ task path: /home/hpokorny/.quickstart/usr/local/share/ansible/roles/ovb-manage-stack/tasks/ovb-create-stack.yml:96 Friday 08 September 2017 11:13:06 -0300 (0:00:00.086) 0:01:49.207 ****** fatal: [localhost]: FAILED! => {"changed": false, "failed": true, "msg": "Stack oooq-923-hpokorny--stack did not deploy successfully. See the stack status message above."} PLAY RECAP ********************************************************************* localhost : ok=15 changed=5 unreachable=0 failed=1 It's very repeatable. Is that related to the outage? Thanks Honza Pokorny On 2017-09-07 22:32, David Moreau Simard wrote: > We confirm that everything is back online and appears to be in order. > > Please let us know here or on #rdo on freenode if you notice anything unusual. > > Thanks. > > David Moreau Simard > Senior Software Engineer | OpenStack RDO > > dmsimard = [irc, github, twitter] > > > On Thu, Sep 7, 2017 at 9:04 PM, David Moreau Simard wrote: > > Things have started recovering progressively for the past hour or so. > > > > We're currently going through our servers to ensure everything is healthy. > > > > David Moreau Simard > > Senior Software Engineer | OpenStack RDO > > > > dmsimard = [irc, github, twitter] > > > > > > On Thu, Sep 7, 2017 at 4:05 PM, David Moreau Simard wrote: > >> Hi, > >> > >> There is currently an infrastructure outage affecting parts of RDO's > >> infrastructure, for example: > >> - logs.rdoproject.org, thirdparty.logs.rdoproject.org & > >> centos.logs.rdoproject.org > >> - review.rdoproject.org > >> - www.rdoproject.org > >> - registry.rdoproject.org > >> - images.rdoproject.org > >> - Parts of third party CI against review.openstack.org > >> > >> Mirrors providing RDO packages such as trunk.rdoproject.org, > >> buildlogs.centos.org and mirror.centos.org are unaffected. > >> However, new trunk package builds are not currently being processed. > >> > >> Engineers are already working on resolving the situation and we'll > >> provide an update ASAP. > >> > >> Thanks, > >> > >> David Moreau Simard > >> Senior Software Engineer | OpenStack RDO > >> > >> dmsimard = [irc, github, twitter] > > _______________________________________________ > 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 dms at redhat.com Fri Sep 8 16:02:15 2017 From: dms at redhat.com (David Moreau Simard) Date: Fri, 8 Sep 2017 12:02:15 -0400 Subject: [rdo-list] Outage: RDO Infrastructure In-Reply-To: <20170908141515.xbsmn7q7p4ab5dcs@localhost.localdomain> References: <20170908141515.xbsmn7q7p4ab5dcs@localhost.localdomain> Message-ID: Possibly, you would need to open a ticket with the RDO cloud ops team to try and troubleshoot. Reach out to me on IRC if you don't know how, I'll show you. David Moreau Simard Senior Software Engineer | Openstack RDO dmsimard = [irc, github, twitter] On Sep 8, 2017 10:15 AM, "Honza Pokorny" wrote: > I'm still experiencing issues: > > When running (which I run regularly, and it usually works for me): > > $ bash devmode.sh --no-gate --ovb --delete-all-stacks > > I get the following error: > > > > TASK [ovb-manage-stack : Return stack state] ****************************** > ***** > task path: /home/hpokorny/.quickstart/usr/local/share/ansible/roles/ > ovb-manage-stack/tasks/ovb-create-stack.yml:68 > Friday 08 September 2017 11:12:22 -0300 (0:00:10.345) 0:01:05.262 > ****** > changed: [localhost] => {"censored": "the output has been hidden due to > the fact that 'no_log: true' was specified for this result"} > > TASK [ovb-manage-stack : Show stack status] ****************************** > ****** > task path: /home/hpokorny/.quickstart/usr/local/share/ansible/roles/ > ovb-manage-stack/tasks/ovb-create-stack.yml:92 > Friday 08 September 2017 11:13:06 -0300 (0:00:43.858) 0:01:49.120 > ****** > ok: [localhost] => { > "stack_status.stdout_lines": [ > "| stack_status | CREATE_FAILED > > |" > ] > } > > TASK [ovb-manage-stack : Fail if stack did not deploy successfully] > ************ > task path: /home/hpokorny/.quickstart/usr/local/share/ansible/roles/ > ovb-manage-stack/tasks/ovb-create-stack.yml:96 > Friday 08 September 2017 11:13:06 -0300 (0:00:00.086) 0:01:49.207 > ****** > fatal: [localhost]: FAILED! => {"changed": false, "failed": true, "msg": > "Stack oooq-923-hpokorny--stack did not deploy successfully. See the stack > status message above."} > > PLAY RECAP ************************************************************ > ********* > localhost : ok=15 changed=5 unreachable=0 failed=1 > > > > > > > It's very repeatable. Is that related to the outage? > > Thanks > > Honza Pokorny > > On 2017-09-07 22:32, David Moreau Simard wrote: > > We confirm that everything is back online and appears to be in order. > > > > Please let us know here or on #rdo on freenode if you notice anything > unusual. > > > > Thanks. > > > > David Moreau Simard > > Senior Software Engineer | OpenStack RDO > > > > dmsimard = [irc, github, twitter] > > > > > > On Thu, Sep 7, 2017 at 9:04 PM, David Moreau Simard > wrote: > > > Things have started recovering progressively for the past hour or so. > > > > > > We're currently going through our servers to ensure everything is > healthy. > > > > > > David Moreau Simard > > > Senior Software Engineer | OpenStack RDO > > > > > > dmsimard = [irc, github, twitter] > > > > > > > > > On Thu, Sep 7, 2017 at 4:05 PM, David Moreau Simard > wrote: > > >> Hi, > > >> > > >> There is currently an infrastructure outage affecting parts of RDO's > > >> infrastructure, for example: > > >> - logs.rdoproject.org, thirdparty.logs.rdoproject.org & > > >> centos.logs.rdoproject.org > > >> - review.rdoproject.org > > >> - www.rdoproject.org > > >> - registry.rdoproject.org > > >> - images.rdoproject.org > > >> - Parts of third party CI against review.openstack.org > > >> > > >> Mirrors providing RDO packages such as trunk.rdoproject.org, > > >> buildlogs.centos.org and mirror.centos.org are unaffected. > > >> However, new trunk package builds are not currently being processed. > > >> > > >> Engineers are already working on resolving the situation and we'll > > >> provide an update ASAP. > > >> > > >> Thanks, > > >> > > >> David Moreau Simard > > >> Senior Software Engineer | OpenStack RDO > > >> > > >> dmsimard = [irc, github, twitter] > > > > _______________________________________________ > > 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 Sat Sep 9 12:26:38 2017 From: chkumar246 at gmail.com (Chandan kumar) Date: Sat, 9 Sep 2017 17:56:38 +0530 Subject: [rdo-list] Register for Open Source India 2017 Message-ID: Hello, This is to inform you that Open Source India is scheduled for 13-14 October. The 14th edition of Asia's largest open source convention is taking place at NIMHANS Convention Centre in Bengaluru, where a large number of developers, IT managers, and C-level officers are coming together to discuss the past, present, and future of open source. Tracks finalized for Open Source India 2017: Cloud and Big Data Cyber Security Day Open Source and You (Success Stories) Open Stack India (mini-conference) Application Development Container Day Database Day Open Source in IOT Register now and get early bird discounts! Visit https://opensourceindia.in/osidays/osi_registration/osidays_register-new.php to mark your presence. Thanks, Chandan Kumar From hguemar at fedoraproject.org Mon Sep 11 15:00:04 2017 From: hguemar at fedoraproject.org (hguemar at fedoraproject.org) Date: Mon, 11 Sep 2017 15:00:04 +0000 (UTC) Subject: [rdo-list] [Fedocal] Reminder meeting : RDO meeting Message-ID: <20170911150004.15E18600524B@fedocal02.phx2.fedoraproject.org> Dear all, You are kindly invited to the meeting: RDO meeting on 2017-09-13 from 15:00:00 to 16:00:00 UTC At rdo at irc.freenode.net The meeting will be about: RDO IRC meeting [Agenda at https://etherpad.openstack.org/p/RDO-Meeting ](https://etherpad.openstack.org/p/RDO-Meeting) Every Wednesday on #rdo on Freenode IRC Source: https://apps.fedoraproject.org/calendar/meeting/2017/ From adarazs at redhat.com Mon Sep 11 15:37:50 2017 From: adarazs at redhat.com (Attila Darazs) Date: Mon, 11 Sep 2017 17:37:50 +0200 Subject: [rdo-list] RDO Phase2 testing - DLRN API transition Message-ID: Matt Young and I had a conversation about about how to move RDO Phase2 over to use DLRN API seamlessly and we had some unanswered question that Javier helped to answer, so I'm posting the information here for future reference. There's this file here on the DLRN server called "promote.sh": https://github.com/rdo-infra/ci-config/blob/master/jenkins/jobs/scripts/promote-repo-promote.sh#L4 That file is deployed using puppet-dlrn, it's in https://github.com/rdo-infra/puppet-dlrn/blob/master/files/promote.sh The last line is something that Matt relies on when starting new promotion jobs. Once we switch Phase1 to promote using DLRN API call, this file won't be updated. We can probably make a change in the puppet-dlrn role to create cronjob that uses a DLRN API call to periodically update that file with the history of promotions until the Phase2 jobs transitions to trigger by a different method. I suggest to use what Phase1 does and check if the delorean.repo file changes: https://github.com/rdo-infra/ci-config/blob/master/jenkins/jobs/promote-pike-current-tripleo.yml#L56-L61 Best regards, Attila From hguemar at fedoraproject.org Mon Sep 11 22:38:26 2017 From: hguemar at fedoraproject.org (=?UTF-8?Q?Ha=C3=AFkel?=) Date: Tue, 12 Sep 2017 00:38:26 +0200 Subject: [rdo-list] [Heads-up] Do not merge reviews on stable branches. Message-ID: Hi, we're experimenting network failures in CI which fails CBS stable builds merge. In some cases, CBS builds succeed but CI job will fail and do not get merged. If you merge other reviews in-between, it ends up with us having CBS stable builds inconsistent with spec files. So what's the big deal with it? Changes you'd expect to be shipped in CBS stable builds won't as the CBS build will be based on a spec that was never in the pristine git repository. In the end, if there are issues with CBS builds, it will be harder to bisect the commit causing the failure. So before merging anything in stable branches: 1. check if there are any other open reviews. 2. if it has generated a stable build in CBS. If yes, -W your review until we merge the other review. Otherwise -W the other review. 3. If it's confusing, do not merge anything and request input from core packagers. What to do if you merged a review and created an inconsistency? Ping me, because I have to fix it manually (merge reviews, bump package, and do a manual CBS build in short) until CI network failures are fixed. Regards, H. From chkumar246 at gmail.com Tue Sep 12 01:30:04 2017 From: chkumar246 at gmail.com (chkumar246 at gmail.com) Date: Tue, 12 Sep 2017 01:30:04 +0000 (UTC) Subject: [rdo-list] [Fedocal] Reminder meeting : RDO Office Hours Message-ID: <20170912013004.2AA01600524B@fedocal02.phx2.fedoraproject.org> Dear all, You are kindly invited to the meeting: RDO Office Hours on 2017-09-12 from 13:30:00 to 15:30:00 UTC The meeting will be about: The meeting will be about RDO Office Hour. Aim: To keep up with increasing participation, we'll host office hours to add more easy fixes and provide mentoring to newcomers. [Agenda at RDO Office Hour easyfixes](https://review.rdoproject.org/etherpad/p/rdo-office-hour-easyfixes) Source: https://apps.fedoraproject.org/calendar/meeting/6374/ From nusiddiq at redhat.com Tue Sep 12 08:50:05 2017 From: nusiddiq at redhat.com (Numan Siddique) Date: Tue, 12 Sep 2017 14:20:05 +0530 Subject: [rdo-list] OVS 2.7 on rdo In-Reply-To: References: Message-ID: Hi Alan, OVS 2.8 is now availalbe [1] and we would like to have it in RDO. Is it possible to have the OVS 2.8 rpms in candidate repo. I will update the patch [2] and make sure it passes so that we don't see any regressions during update. [1] - https://mail.openvswitch.org/pipermail/ovs-discuss/2017-September/045235.html [2] - https://review.openstack.org/#/c/473191/ Thanks Numan On Fri, Jul 7, 2017 at 3:57 PM, Numan Siddique wrote: > > > On Fri, Jun 16, 2017 at 12:00 PM, Numan Siddique > wrote: > >> >> >> On Jun 16, 2017 11:41 AM, "Alan Pevec" wrote: >> >> On Fri, Jun 16, 2017 at 3:03 AM, Numan Siddique >> wrote: >> > Just an update. The test review [1] is passing for the CI job - >> > gate-tripleo-ci-centos-7-multinode-upgrades-nv. >> > This patch updates the OVS to OVS 2.7 from the repo - >> > http://cbs.centos.org/repos/cloud7-openstack-pike-candidate/x86_64/os >> and >> > restarts it at step0 of the upgrade. >> >> Thanks, double-checking, ovs in overcloud is 2.7: >> http://logs.openstack.org/91/473191/9/check/gate-tripleo-ci- >> centos-7-multinode-upgrades-nv/3307cf8/logs/subnode-2/rpm-qa.txt.gz >> >> In undercloud 2.6.1 is still installed but I'll assume testing in OC >> is good enough. >> I'm moving 2.7 to pike-testing, please watch for any issues in RDO and >> TripleO CI on master/Pike and report here. >> Hopefully we'll get 2.7.1 upstream release soon so we can update the >> package. >> >> >> Thanks Alan. Sure I will watch out for any CI issues. >> ovs 2.7.1 would be released soon. I will update you once it's available. >> > > Hi Alan, > > OVS 2.7.1 is available now. > > I am working on having a CI job for tripleo to enable OVN. I submitted > this patch [1] for that. But it is failing in upgrade job from ML2OVS to > OVN. > > So Emilien suggested to enable OVN first in ocata job [2] and after that > in master, so that upgrade from Ocata to master would be successful since > we would be using OVN here. > > This patch [2] is failing because ocata repos have OVS 2.6. Is it possible > to have OVS 2.7 in ocata testing repo ? > > [1] - https://review.openstack.org/#/c/412831/ > [2] - https://review.openstack.org/#/c/480355/ > > Thanks > Numan > > > > > >> Thanks again >> Numan >> >> >> Cheers, >> Alan >> >> > [1] - https://review.openstack.org/#/c/473191/ >> > >> > http://logs.openstack.org/91/473191/9/check/gate-tripleo-ci- >> centos-7-multinode-upgrades-nv/3307cf8/logs/subnode-2/var/lo >> g/ovs_debug.txt.gz >> > >> > http://logs.openstack.org/91/473191/9/check/gate-tripleo-ci- >> centos-7-multinode-upgrades-nv/3307cf8/logs/subnode-2/var/lo >> g/openvswitch/ovsdb-server.txt.gz >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chkumar246 at gmail.com Wed Sep 13 16:04:45 2017 From: chkumar246 at gmail.com (Chandan kumar) Date: Wed, 13 Sep 2017 21:34:45 +0530 Subject: [rdo-list] [Minutes] RDO meeting - 2017-09-13 Message-ID: ============================== #rdo: RDO meeting - 2017-09-13 ============================== Meeting started by chandankumar at 15:02:00 UTC. The full logs are available at http://eavesdrop.openstack.org/meetings/rdo_meeting___2017_09_13/2017/rdo_meeting___2017_09_13.2017-09-13-15.02.log.html . Meeting summary --------------- * Roll Call (chandankumar, 15:02:12) * dropping patches repositories (chandankumar, 15:05:17) * AGREED: create patches branches on-demand (number80, 15:17:05) * AGREED: abandon patches open reviews for EOL branches (number80, 15:17:15) * ACTION: number80 document that where it fits ^ (number80, 15:17:27) * Fedora worker cleanup in RDO Trunk (chandankumar, 15:18:31) * ACTION: jpena to check inclusion of openstack-macros in RDO Trunk (jpena, 15:27:18) * Using the CentOS extras Ansible (chandankumar, 15:35:10) * rdopkg is now in Fedora 25+ and EPEL 7 (chandankumar, 15:44:26) * ACTION: jruzicka to update website (jruzicka, 15:47:17) * chair for next meeting (chandankumar, 15:51:40) * ACTION: jruzicka to chair for next meeting (chandankumar, 15:53:25) * Open discussion (chandankumar, 15:53:50) Meeting ended at 16:01:34 UTC. Action items, by person ----------------------- * jpena * jpena to check inclusion of openstack-macros in RDO Trunk * jruzicka * jruzicka to update website * jruzicka to chair for next meeting * number80 * number80 document that where it fits ^ * openstack * jpena to check inclusion of openstack-macros in RDO Trunk People present (lines said) --------------------------- * chandankumar (48) * number80 (47) * apevec (43) * jruzicka (31) * snecklifter (25) * jpena (18) * dmsimard (8) * openstack (8) * rbowen (7) * Duck (6) * PagliaccisCloud (2) * rdogerrit (2) * jatanmalde (2) Generated by `MeetBot`_ 0.1.4 From kdreyer at redhat.com Wed Sep 13 16:34:17 2017 From: kdreyer at redhat.com (Ken Dreyer) Date: Wed, 13 Sep 2017 10:34:17 -0600 Subject: [rdo-list] [CentOS-devel] [Minutes] RDO meeting - 2017-09-13 In-Reply-To: References: Message-ID: On Wed, Sep 13, 2017 at 10:04 AM, Chandan kumar wrote: > * Using the CentOS extras Ansible (chandankumar, 15:35:10) There was some discussion here about ceph-ansible requiring Ansible 2.3.2, and how CentOS Extras only includes Ansible 2.3.1. I wasn't aware of the specific Ansible 2.3.2 requirement. Can you share more details? Should we update the "(Build)Requires: ansible >= 2.2.0.0" lines in ceph-ansible.spec? Ye olde Upstream Vendor just shipped Ansible 2.3.2 to RHEL Extras 8 days ago in https://access.redhat.com/errata/RHBA-2017:2606 , so I expect CentOS Extras to catch up in a bit. - Ken From hguemar at redhat.com Wed Sep 13 19:56:28 2017 From: hguemar at redhat.com (=?UTF-8?B?SGHDr2tlbCBHdcOpbWFy?=) Date: Wed, 13 Sep 2017 21:56:28 +0200 Subject: [rdo-list] [CentOS-devel] [Minutes] RDO meeting - 2017-09-13 In-Reply-To: References: Message-ID: <3001b5c9-0383-466e-bbe3-53318b1b3e90@redhat.com> On 13/09/17 18:34, Ken Dreyer wrote: > On Wed, Sep 13, 2017 at 10:04 AM, Chandan kumar wrote: >> * Using the CentOS extras Ansible (chandankumar, 15:35:10) > > There was some discussion here about ceph-ansible requiring Ansible > 2.3.2, and how CentOS Extras only includes Ansible 2.3.1. > RDO can be more aggressive with updates but we try to stay as close as possible from RHEL/CentOS base repositories. 2.3.2 allows us to test against next Ansible release and it will only be in -testing for now. We might decide to stick with 2.3.1 in -release repo. > I wasn't aware of the specific Ansible 2.3.2 requirement. Can you > share more details? Should we update the "(Build)Requires: ansible >= > 2.2.0.0" lines in ceph-ansible.spec? > For now, keep it to 2.3.1, when CentOS extras will get updated 2.3.2 will be fine. > Ye olde Upstream Vendor just shipped Ansible 2.3.2 to RHEL Extras 8 > days ago in https://access.redhat.com/errata/RHBA-2017:2606 , so I > expect CentOS Extras to catch up in a bit. > > - Ken > > _______________________________________________ > 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 Thu Sep 14 17:22:50 2017 From: rbowen at redhat.com (Rich Bowen) Date: Thu, 14 Sep 2017 11:22:50 -0600 Subject: [rdo-list] PTG event Message-ID: <821be8cb-79eb-f47c-470a-bf4f25ced82c@redhat.com> Thanks to everyone who showed up last night at Station 26, at the PTG. I should have photos and video a little later today. --Rich -- Rich Bowen - rbowen at redhat.com RDO Community Liaison http://rdoproject.org @RDOCommunity From majopela at redhat.com Thu Sep 14 18:53:38 2017 From: majopela at redhat.com (Miguel Angel Ajo Pelayo) Date: Thu, 14 Sep 2017 12:53:38 -0600 Subject: [rdo-list] PTG event In-Reply-To: <821be8cb-79eb-f47c-470a-bf4f25ced82c@redhat.com> References: <821be8cb-79eb-f47c-470a-bf4f25ced82c@redhat.com> Message-ID: Thanks a lot for organizing this Rich! :) On Thu, Sep 14, 2017 at 11:22 AM, Rich Bowen wrote: > Thanks to everyone who showed up last night at Station 26, at the PTG. I > should have photos and video a little later today. > > --Rich > > > -- > Rich Bowen - rbowen at redhat.com > RDO Community Liaison > http://rdoproject.org > @RDOCommunity > > _______________________________________________ > 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 miaojc at arraynetworks.com.cn Mon Sep 18 03:28:11 2017 From: miaojc at arraynetworks.com.cn (Jincheng Miao) Date: Mon, 18 Sep 2017 11:28:11 +0800 Subject: [rdo-list] python2-gevent is missing for newton Message-ID: Hi everyone, When I install RDO openstack-neutron, yum reports error, it can not find the python2-gevent. Is there an error in RDO openstack-neutron? Thanks From liujiong at gohighsec.com Mon Sep 18 07:03:04 2017 From: liujiong at gohighsec.com (Jiong Liu) Date: Mon, 18 Sep 2017 15:03:04 +0800 Subject: [rdo-list] Review requests for new rdo projects Message-ID: <001d01d3304c$2d47bc00$87d73400$@gohighsec.com> Hello RDO community, About one month ago, I created three new RDO projects and added initial spec files trying to package an OpenStack project(Karbor). Perhaps it was a bit too late to get them into Pike serial, they got little attention from our community. Now I would like to announce here and hope catching our community's attention, so somebody could take a look at the initial spec files and review them. It would be great to get feedbacks from our community! FYI [1] https://review.rdoproject.org/r/#/c/8671/ [2] https://review.rdoproject.org/r/#/c/8672/ [3] https://review.rdoproject.org/r/#/c/8675/ Thanks, Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: From javier.pena at redhat.com Mon Sep 18 08:21:28 2017 From: javier.pena at redhat.com (Javier Pena) Date: Mon, 18 Sep 2017 04:21:28 -0400 (EDT) Subject: [rdo-list] python2-gevent is missing for newton In-Reply-To: References: Message-ID: <1728194639.7331121.1505722888260.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hi everyone, > > > When I install RDO openstack-neutron, yum reports error, it can not find > the python2-gevent. > > Is there an error in RDO openstack-neutron? > Hi, I can see the package in the RDO repos: http://mirror.centos.org/centos/7/cloud/x86_64/openstack-newton/common/python2-gevent-1.1.2-2.el7.x86_64.rpm . Maybe there was a temporary repo issue when you tried to install it? Regards, Javier > > 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 miaojc at arraynetworks.com.cn Mon Sep 18 08:57:46 2017 From: miaojc at arraynetworks.com.cn (Jincheng Miao) Date: Mon, 18 Sep 2017 16:57:46 +0800 Subject: [rdo-list] python2-gevent is missing for newton In-Reply-To: <1728194639.7331121.1505722888260.JavaMail.zimbra@redhat.com> References: <1728194639.7331121.1505722888260.JavaMail.zimbra@redhat.com> Message-ID: Hi Javier Thanks for your reminder, now I can get this rpm and install it. Thanks Jincheng Miao On 9/18/2017 4:21 PM, Javier Pena wrote: > > ----- Original Message ----- >> Hi everyone, >> >> >> When I install RDO openstack-neutron, yum reports error, it can not find >> the python2-gevent. >> >> Is there an error in RDO openstack-neutron? >> > Hi, > > I can see the package in the RDO repos: http://mirror.centos.org/centos/7/cloud/x86_64/openstack-newton/common/python2-gevent-1.1.2-2.el7.x86_64.rpm . Maybe there was a temporary repo issue when you tried to install it? > > Regards, > Javier > >> 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 hguemar at redhat.com Mon Sep 18 09:32:12 2017 From: hguemar at redhat.com (=?UTF-8?B?SGHDr2tlbCBHdcOpbWFy?=) Date: Mon, 18 Sep 2017 11:32:12 +0200 Subject: [rdo-list] python2-gevent is missing for newton In-Reply-To: References: Message-ID: On 18/09/17 05:28, Jincheng Miao wrote: > Hi everyone, > > > When I install RDO openstack-neutron, yum reports error, it can not find > the python2-gevent. > > Is there an error in RDO openstack-neutron? > > > Thanks > Likely a cache or mirror issue, it is indeed provided. http://mirror.centos.org/centos/7/cloud/x86_64/openstack-newton/common/python2-gevent-1.1.2-2.el7.x86_64.rpm 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 amoralej at redhat.com Mon Sep 18 12:34:20 2017 From: amoralej at redhat.com (Alfredo Moralejo Alonso) Date: Mon, 18 Sep 2017 14:34:20 +0200 Subject: [rdo-list] Upgrading from Newton to Ocata In-Reply-To: References: Message-ID: Thanks for the feedback. On Tue, Sep 5, 2017 at 4:52 PM, Peter Kirby wrote: > Hello RDO Team, > > I'm still fairly new to OpenStack so this may be because I didn't read the > documentation closely enough before the upgrade, but I ran into an issue > that I was hoping to get some clarification on. > > I used this page to perform the upgrade [1]. > > Everything went smoothly until setting up cells for the first time. I had > not done this in Newton. > > I got to step 14: "List registered cells to get their UUIDs:" which worked > great. I had cell0 and cell1 created from previous steps, everything seemed > to be in place. > > The next step says: "Pass the UUIDs to the map_instances command to map > instances to cells:" with the following command example: > "# su -s /bin/sh -c "nova-manage cell_v2 map_instances --cell_uuid UUID>" nova" > > I took this to mean run that command for both cell0 and cell1. So I did. > That mapped all my instances to cell0. > > I then started seeing errors like this in the logs: > ERROR nova.api.openstack.extensions DriverLoadFailure: Failed to load > transport driver "none": No 'oslo.messaging.drivers' driver found, looking > for u'none' > > After much searching, I found the transport_url for cell0 in the database > was set to "none:///" which is what was causing the error. > > I was able to create new instances, but not run any commands at all on > current instances and all new instances were brought up in cell1. > > So I moved all current instances to cell1 by manually updating the database > and all the errors went away and everything is running correctly. > > So my question is, did I do something else wrong that would cause this not > to work properly or should those instructions be clarified a bit to say map > instances to cell1, not cell0? I've sent a PR to the doc in https://github.com/redhat-openstack/website/pull/1071 to specify cell1. Note that documentation changes can be sent following https://www.rdoproject.org/contribute/#write-content. > > In my searching I did find other guides that did all these same things, but > specifically said map instances to cell1. > > Thank you, > Peter > > > [1] - https://www.rdoproject.org/install/upgrading-rdo-2/ > > _______________________________________________ > 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 Sep 18 15:00:03 2017 From: hguemar at fedoraproject.org (hguemar at fedoraproject.org) Date: Mon, 18 Sep 2017 15:00:03 +0000 (UTC) Subject: [rdo-list] [Fedocal] Reminder meeting : RDO meeting Message-ID: <20170918150003.4B0D660005A2@fedocal02.phx2.fedoraproject.org> Dear all, You are kindly invited to the meeting: RDO meeting on 2017-09-20 from 15:00:00 to 16:00:00 UTC At rdo at irc.freenode.net The meeting will be about: RDO IRC meeting [Agenda at https://etherpad.openstack.org/p/RDO-Meeting ](https://etherpad.openstack.org/p/RDO-Meeting) Every Wednesday on #rdo on Freenode IRC Source: https://apps.fedoraproject.org/calendar/meeting/2017/ From kdreyer at redhat.com Mon Sep 18 16:50:19 2017 From: kdreyer at redhat.com (Ken Dreyer) Date: Mon, 18 Sep 2017 10:50:19 -0600 Subject: [rdo-list] [CentOS-devel] [Minutes] RDO meeting - 2017-09-13 In-Reply-To: <3001b5c9-0383-466e-bbe3-53318b1b3e90@redhat.com> References: <3001b5c9-0383-466e-bbe3-53318b1b3e90@redhat.com> Message-ID: On Wed, Sep 13, 2017 at 1:56 PM, Ha?kel Gu?mar wrote: > On 13/09/17 18:34, Ken Dreyer wrote: >> There was some discussion here about ceph-ansible requiring Ansible >> 2.3.2, and how CentOS Extras only includes Ansible 2.3.1. >> > > RDO can be more aggressive with updates but we try to stay as close as > possible from RHEL/CentOS base repositories. > 2.3.2 allows us to test against next Ansible release and it will only be in > -testing for now. We might decide to stick with 2.3.1 in -release repo. Thanks. I'm curious, when you push things to -testing, is it *always* the case that you expect it to go into -release one day? Or are there some things that you know for certain will never go from -testing to -release? >> I wasn't aware of the specific Ansible 2.3.2 requirement. Can you >> share more details? Should we update the "(Build)Requires: ansible >= >> 2.2.0.0" lines in ceph-ansible.spec? >> > > For now, keep it to 2.3.1, when CentOS extras will get updated 2.3.2 will be > fine. Thanks Ha?kel! I've made that change in https://github.com/ceph/ceph-ansible/pull/1901 . It will be in the next release of ceph-ansible after 3.0.0rc7, probably 3.0.0rc8. - Ken From kdreyer at redhat.com Mon Sep 18 17:48:31 2017 From: kdreyer at redhat.com (Ken Dreyer) Date: Mon, 18 Sep 2017 11:48:31 -0600 Subject: [rdo-list] automating auth to CBS Message-ID: Hi Ha?kel, Recently I was looking into automatically building ceph-ansible in CBS, and I was curious how you're doing automatic CBS builds for RDO. I'm guessing you've generated your hguemar CentOS FAS x509 cert with centos-cert, and then you upload that .centos.cert file into some Jenkins instance as a "Global Credential"? Is that ci.centos.org or something else? Do you have to refresh that every three months? - Ken From kdreyer at redhat.com Mon Sep 18 19:10:35 2017 From: kdreyer at redhat.com (Ken Dreyer) Date: Mon, 18 Sep 2017 13:10:35 -0600 Subject: [rdo-list] ceph-ansible auto builds in cbs.centos.org Message-ID: Hi folks, TL;DR new ceph-ansible tags are automatically built in the CentOS Storage SIG. The RDO team members have been building ceph-related RPMs in the CentOS Storage SIG, including ceph-ansible. Specifically this has been handled by Giulio Fidente and John Fulton on the OpenStack (RDO/OSP) team. The reason is that TripleO relies on ceph-ansible to install Ceph, and TripleO expects to install a ceph-ansible RPM. So RDO depends on the ceph-ansible CBS builds. In the past Giulio had been doing these CentOS builds by hand, rebuilding upstream SRPMs from shaman.ceph.com, for example http://cbs.centos.org/koji/buildinfo?buildID=19762 I have a job running in an internal Jenkins instance that now polls https://github.com/ceph/ceph-ansible every hour and builds any new Git tags within CBS. An example is http://cbs.centos.org/koji/taskinfo?taskID=227958 , although that was "scratch = True", and future builds will not be scratch builds. It is using the script at https://github.com/ktdreyer/ceph-ansible-cbs Next steps: - automatically tag new builds into storage7-ceph-luminous-testing - automatically tag new builds into storage7-ceph-luminous-release Anyone in RDO have suggestions for how we should gate these next CBS tagging operations? My simple approach was going to be "tag into -testing immediately, then wait two weeks and tag into -release". If there is a simple way to have safer, automatic gating here, I'm open to that. - Ken From hguemar at redhat.com Mon Sep 18 20:31:04 2017 From: hguemar at redhat.com (=?UTF-8?B?SGHDr2tlbCBHdcOpbWFy?=) Date: Mon, 18 Sep 2017 22:31:04 +0200 Subject: [rdo-list] automating auth to CBS In-Reply-To: References: Message-ID: On 18/09/17 19:48, Ken Dreyer wrote: > Hi Ha?kel, > > Recently I was looking into automatically building ceph-ansible in > CBS, and I was curious how you're doing automatic CBS builds for RDO. > > I'm guessing you've generated your hguemar CentOS FAS x509 cert with > centos-cert, and then you upload that .centos.cert file into some > Jenkins instance as a "Global Credential"? Is that ci.centos.org or > something else? Do you have to refresh that every three months? > > - Ken > Hi, Yes, we uploaded my FAS certificate into review.rdoproject.org Jenkins instance (where they are securely stored thanks to the Jenkins Credentials plugin). I do have to refresh it every 6 months, so I set reminder (early january and july for RDO). Then, we use gerrit reviews to manage distgit and automate builds. Automation is stored in this repo: https://review.rdoproject.org/r/gitweb?p=gating_scripts.git;a=summary The trick is that we detect that NVR changed to initiate a build, we have a two step validation: check will always run a scratch build to verify that build is working in Koji. But only at validate step, we will initiate final build. If you have any more questions, feel free to ask :) Regards, H. From kdreyer at redhat.com Mon Sep 18 20:42:43 2017 From: kdreyer at redhat.com (Ken Dreyer) Date: Mon, 18 Sep 2017 14:42:43 -0600 Subject: [rdo-list] automating auth to CBS In-Reply-To: References: Message-ID: On Mon, Sep 18, 2017 at 2:31 PM, Ha?kel Gu?mar wrote: > Yes, we uploaded my FAS certificate into review.rdoproject.org Jenkins > instance (where they are securely stored thanks to the Jenkins Credentials > plugin). I do have to refresh it every 6 months, so I set reminder (early > january and july for RDO). Thanks, that's helpful to know! I'm wondering how to avoid having to refresh it at all? Could we ask for a long-lived CentOS FAS certificate from the CentOS admins? Seems like many other Fedora teams have this same issue, like Fedora's Bodhi, and Koschei, and OSBS. - Ken From johfulto at redhat.com Mon Sep 18 20:55:43 2017 From: johfulto at redhat.com (John Fulton) Date: Mon, 18 Sep 2017 16:55:43 -0400 Subject: [rdo-list] ceph-ansible auto builds in cbs.centos.org In-Reply-To: References: Message-ID: On Mon, Sep 18, 2017 at 3:10 PM, Ken Dreyer wrote: > Hi folks, > > TL;DR new ceph-ansible tags are automatically built in the CentOS Storage SIG. > > The RDO team members have been building ceph-related RPMs in the > CentOS Storage SIG, including ceph-ansible. Specifically this has been > handled by Giulio Fidente and John Fulton on the OpenStack (RDO/OSP) > team. > > The reason is that TripleO relies on ceph-ansible to install Ceph, and > TripleO expects to install a ceph-ansible RPM. So RDO depends on the > ceph-ansible CBS builds. > > In the past Giulio had been doing these CentOS builds by hand, > rebuilding upstream SRPMs from shaman.ceph.com, for example > http://cbs.centos.org/koji/buildinfo?buildID=19762 > > I have a job running in an internal Jenkins instance that now polls > https://github.com/ceph/ceph-ansible every hour and builds any new Git > tags within CBS. An example is > http://cbs.centos.org/koji/taskinfo?taskID=227958 , although that was > "scratch = True", and future builds will not be scratch builds. It is > using the script at https://github.com/ktdreyer/ceph-ansible-cbs Thanks for working on this Ken. For which repos are you doing this? I.e. what subset of the following is this now the case for? echo ceph-{jewel,luminous}-{release,testing,candidate} TripleO CI uses ceph-ansible from centos-jewel (release) for the voting job scenario001-multinode-oooq-container, so I'd rather we didn't promote from testing to release until we know that scenario001-multinode-oooq-container is passing with the new ceph-ansible (otherwise we could break TripleO CI). One way to test this is to have a submission which varies the line below to use not ceph-jewel but ceph-jewel-testing (though there is no mirror). https://github.com/openstack/tripleo-quickstart/blob/5389b4c44b1e2c1dc30848359f8a415481cc86d1/config/release/tripleo-ci/consistent-master.yml#L74 John > Next steps: > > - automatically tag new builds into storage7-ceph-luminous-testing > - automatically tag new builds into storage7-ceph-luminous-release > > Anyone in RDO have suggestions for how we should gate these next CBS > tagging operations? My simple approach was going to be "tag into > -testing immediately, then wait two weeks and tag into -release". If > there is a simple way to have safer, automatic gating here, I'm open > to that. > > - Ken > > _______________________________________________ > 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 redhat.com Mon Sep 18 23:22:13 2017 From: apevec at redhat.com (Alan Pevec) Date: Tue, 19 Sep 2017 01:22:13 +0200 Subject: [rdo-list] OVS 2.8 in CentOS SIGs WAS Re: OVS 2.7 on rdo Message-ID: On Tue, Sep 12, 2017 at 10:50 AM, Numan Siddique wrote: > Hi Alan, > > OVS 2.8 is now availalbe [1] and we would like to have it in RDO. > > Is it possible to have the OVS 2.8 rpms in candidate repo. I will update the > patch [2] and make sure it passes so that we don't see any regressions > during update. > > [1] - > https://mail.openvswitch.org/pipermail/ovs-discuss/2017-September/045235.html > [2] - https://review.openstack.org/#/c/473191/ Hi Numan, I've rebased two patches we have in RDO [3] rebuilds, on top of Timothy's Fedora 28 RPM [4] and it almost worked, only ppc64le arch build [5] failed with: | /builddir/build/BUILD/openvswitch-2.8.0/dpdk-stable-17.05.1/ppc_64-power8-linuxapp-gcc/lib/librte_eal.a(eal_common_options.o): In function `eal_plugins_init': | /builddir/build/BUILD/openvswitch-2.8.0/dpdk-stable-17.05.1/lib/librte_eal/common/eal_common_options.c:240: undefined reference to `dlopen' | /builddir/build/BUILD/openvswitch-2.8.0/dpdk-stable-17.05.1/lib/librte_eal/common/eal_common_options.c:242: undefined reference to `dlerror' | collect2: error: ld returned 1 exit status ppc64le folks, please help! Cheers, Alan [3] https://github.com/rdo-common/openvswitch/commits/common-rdo-2.8 [4] https://koji.fedoraproject.org/koji/buildinfo?buildID=965729 [5] http://cbs.centos.org/koji/taskinfo?taskID=227978 - first openstack-queens build attempt! From chkumar246 at gmail.com Tue Sep 19 01:30:04 2017 From: chkumar246 at gmail.com (chkumar246 at gmail.com) Date: Tue, 19 Sep 2017 01:30:04 +0000 (UTC) Subject: [rdo-list] [Fedocal] Reminder meeting : RDO Office Hours Message-ID: <20170919013004.3A6AB60005A2@fedocal02.phx2.fedoraproject.org> Dear all, You are kindly invited to the meeting: RDO Office Hours on 2017-09-19 from 13:30:00 to 15:30:00 UTC The meeting will be about: The meeting will be about RDO Office Hour. Aim: To keep up with increasing participation, we'll host office hours to add more easy fixes and provide mentoring to newcomers. [Agenda at RDO Office Hour easyfixes](https://review.rdoproject.org/etherpad/p/rdo-office-hour-easyfixes) Source: https://apps.fedoraproject.org/calendar/meeting/6374/ From nusiddiq at redhat.com Tue Sep 19 08:08:13 2017 From: nusiddiq at redhat.com (Numan Siddique) Date: Tue, 19 Sep 2017 13:38:13 +0530 Subject: [rdo-list] OVS 2.8 in CentOS SIGs WAS Re: OVS 2.7 on rdo In-Reply-To: References: Message-ID: On Tue, Sep 19, 2017 at 4:52 AM, Alan Pevec wrote: > On Tue, Sep 12, 2017 at 10:50 AM, Numan Siddique > wrote: > > Hi Alan, > > > > OVS 2.8 is now availalbe [1] and we would like to have it in RDO. > > > > Is it possible to have the OVS 2.8 rpms in candidate repo. I will update > the > > patch [2] and make sure it passes so that we don't see any regressions > > during update. > > > > [1] - > > https://mail.openvswitch.org/pipermail/ovs-discuss/2017- > September/045235.html > > [2] - https://review.openstack.org/#/c/473191/ > > Hi Numan, > > I've rebased two patches we have in RDO [3] rebuilds, on top of > Timothy's Fedora 28 RPM [4] and it almost worked, only ppc64le arch > build [5] failed with: > > | /builddir/build/BUILD/openvswitch-2.8.0/dpdk-stable- > 17.05.1/ppc_64-power8-linuxapp-gcc/lib/librte_eal.a(eal_common_options.o): > In function `eal_plugins_init': > | /builddir/build/BUILD/openvswitch-2.8.0/dpdk-stable- > 17.05.1/lib/librte_eal/common/eal_common_options.c:240: > undefined reference to `dlopen' > | /builddir/build/BUILD/openvswitch-2.8.0/dpdk-stable- > 17.05.1/lib/librte_eal/common/eal_common_options.c:242: > undefined reference to `dlerror' > | collect2: error: ld returned 1 exit status > > ppc64le folks, please help! > > Thanks Alan. Hope the build would be resolved soon. Numan > Cheers, > Alan > > > > [3] https://github.com/rdo-common/openvswitch/commits/common-rdo-2.8 > [4] https://koji.fedoraproject.org/koji/buildinfo?buildID=965729 > [5] http://cbs.centos.org/koji/taskinfo?taskID=227978 - first > openstack-queens build attempt! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gfidente at redhat.com Tue Sep 19 09:54:18 2017 From: gfidente at redhat.com (Giulio Fidente) Date: Tue, 19 Sep 2017 11:54:18 +0200 Subject: [rdo-list] ceph-ansible auto builds in cbs.centos.org In-Reply-To: References: Message-ID: On 09/18/2017 10:55 PM, John Fulton wrote: > On Mon, Sep 18, 2017 at 3:10 PM, Ken Dreyer wrote: >> Hi folks, >> >> TL;DR new ceph-ansible tags are automatically built in the CentOS Storage SIG. >> >> The RDO team members have been building ceph-related RPMs in the >> CentOS Storage SIG, including ceph-ansible. Specifically this has been >> handled by Giulio Fidente and John Fulton on the OpenStack (RDO/OSP) >> team. >> >> The reason is that TripleO relies on ceph-ansible to install Ceph, and >> TripleO expects to install a ceph-ansible RPM. So RDO depends on the >> ceph-ansible CBS builds. >> >> In the past Giulio had been doing these CentOS builds by hand, >> rebuilding upstream SRPMs from shaman.ceph.com, for example >> http://cbs.centos.org/koji/buildinfo?buildID=19762 >> >> I have a job running in an internal Jenkins instance that now polls >> https://github.com/ceph/ceph-ansible every hour and builds any new Git >> tags within CBS. An example is >> http://cbs.centos.org/koji/taskinfo?taskID=227958 , although that was >> "scratch = True", and future builds will not be scratch builds. It is >> using the script at https://github.com/ktdreyer/ceph-ansible-cbs > > Thanks for working on this Ken. > > For which repos are you doing this? I.e. what subset of the following > is this now the case for? > > echo ceph-{jewel,luminous}-{release,testing,candidate} > > TripleO CI uses ceph-ansible from centos-jewel (release) for the > voting job scenario001-multinode-oooq-container, so I'd rather we > didn't promote from testing to release until we know that > scenario001-multinode-oooq-container is passing with the new > ceph-ansible (otherwise we could break TripleO CI). > > One way to test this is to have a submission which varies the line > below to use not ceph-jewel but ceph-jewel-testing (though there is no > mirror). > > https://github.com/openstack/tripleo-quickstart/blob/5389b4c44b1e2c1dc30848359f8a415481cc86d1/config/release/tripleo-ci/consistent-master.yml#L74 +1 we have a DO-NOT-MERGE submission to test newer versions of ceph-ansible already: https://review.openstack.org/#/c/501987/ this is currently using the -testing repo [1] If I understand correctly, the automated builds are tagged -candidate so I could tag -testing any of them to test it in tripleo/ci At which point, should it pass tripleo/ci, we can give green light to the ceph-ansible tagging and tag the same build -release in cbs too, does it sound a viable plan? On a side note, I think it'd be also useful to have some more coverage in ceph-ansible ci for the parameters which tripleo uses and specifically gate ceph-ansible commits with a job which uses those parameters; do you think it would be feasible? The list of params can be gathered from the tripleo templates; I am adding some links here to the files which are "composed" (depending on the services enabled) to build the full list of params https://github.com/openstack/tripleo-heat-templates/blob/master/docker/services/ceph-ansible/ceph-base.yaml#L198-L294 https://github.com/openstack/tripleo-heat-templates/blob/master/docker/services/ceph-ansible/ceph-mon.yaml#L84-L86 https://github.com/openstack/tripleo-heat-templates/blob/master/docker/services/ceph-ansible/ceph-osd.yaml#L37-L41 https://github.com/openstack/tripleo-heat-templates/blob/master/docker/services/ceph-ansible/ceph-mds.yaml#L81-L83 https://github.com/openstack/tripleo-heat-templates/blob/master/docker/services/ceph-ansible/ceph-rgw.yaml#L74-L77 https://github.com/openstack/tripleo-heat-templates/blob/master/docker/services/ceph-ansible/ceph-external.yaml#L66 Thanks! 1. https://review.openstack.org/#/c/501810/ -- Giulio Fidente GPG KEY: 08D733BA From jwboyer at redhat.com Tue Sep 19 13:46:03 2017 From: jwboyer at redhat.com (Josh Boyer) Date: Tue, 19 Sep 2017 09:46:03 -0400 Subject: [rdo-list] OVS 2.8 in CentOS SIGs WAS Re: OVS 2.7 on rdo In-Reply-To: References: Message-ID: On Tue, Sep 19, 2017 at 4:08 AM, Numan Siddique wrote: > > > On Tue, Sep 19, 2017 at 4:52 AM, Alan Pevec wrote: >> >> On Tue, Sep 12, 2017 at 10:50 AM, Numan Siddique >> wrote: >> > Hi Alan, >> > >> > OVS 2.8 is now availalbe [1] and we would like to have it in RDO. >> > >> > Is it possible to have the OVS 2.8 rpms in candidate repo. I will update >> > the >> > patch [2] and make sure it passes so that we don't see any regressions >> > during update. >> > >> > [1] - >> > >> > https://mail.openvswitch.org/pipermail/ovs-discuss/2017-September/045235.html >> > [2] - https://review.openstack.org/#/c/473191/ >> >> Hi Numan, >> >> I've rebased two patches we have in RDO [3] rebuilds, on top of >> Timothy's Fedora 28 RPM [4] and it almost worked, only ppc64le arch >> build [5] failed with: >> >> | >> /builddir/build/BUILD/openvswitch-2.8.0/dpdk-stable-17.05.1/ppc_64-power8-linuxapp-gcc/lib/librte_eal.a(eal_common_options.o): >> In function `eal_plugins_init': >> | >> /builddir/build/BUILD/openvswitch-2.8.0/dpdk-stable-17.05.1/lib/librte_eal/common/eal_common_options.c:240: >> undefined reference to `dlopen' >> | >> /builddir/build/BUILD/openvswitch-2.8.0/dpdk-stable-17.05.1/lib/librte_eal/common/eal_common_options.c:242: >> undefined reference to `dlerror' >> | collect2: error: ld returned 1 exit status >> >> ppc64le folks, please help! >> > > > Thanks Alan. Hope the build would be resolved soon. I looked at this briefly. The compile error is odd, but we wouldn't even hit that if the initial testcase run completed successfully. There are two unexpected failures: 2355: ovn -- dns lookup : 1 HV, 2 LS, 2 LSPs/LS FAILED (ovn.at:6812) 2364: ovn -- ensure one gw controller restart in HA doesn't bounce the master FAILED (ovn.at:8480) Not sure why those two failed. josh From chkumar246 at gmail.com Tue Sep 19 15:33:57 2017 From: chkumar246 at gmail.com (Chandan kumar) Date: Tue, 19 Sep 2017 21:03:57 +0530 Subject: [rdo-list] [Minutes] RDO Office Hour meeting - 2017-09-19 Message-ID: ============================== #rdo: RDO meeting - 2017-09-19 ============================== Meeting started by chandankumar at 13:31:15 UTC. The full logs are available at http://eavesdrop.openstack.org/meetings/rdo_meeting___2017_09_19/2017/rdo_meeting___2017_09_19.2017-09-19-13.31.log.html . Meeting summary --------------- * Roll Call (chandankumar, 13:32:19) * LINK: https://review.rdoproject.org/etherpad/p/rdo-office-hour-easyfixes (chandankumar, 13:33:08) * Easyfix open review queue >= 175 (chandankumar, 13:35:04) * Keep -W for oslo + clients till openstack-macros is available for fedora (chandankumar, 13:38:01) * LINK: https://review.rdoproject.org/r/#/q/topic:easyfix/23+status:open (snecklifter, 13:42:28) * , rpm-macros related reviews got cleanedup (chandankumar, 15:26:43) Meeting ended at 15:31:50 UTC. People present (lines said) --------------------------- * dmsimard (61) * rdogerrit (36) * jpena (35) * chandankumar (33) * jschlueter (30) * jruzicka (28) * number80 (23) * openstack (14) * aditya_r (12) * adarazs (10) * jatanmalde (10) * snecklifter (7) * trown (7) * amoralej (7) * remix_tj (7) * weshay (4) * sfbender (3) * panda (2) * apevec (2) * pradk (2) * rbowen (1) * rdobot (1) * tvignaud (1) * pabelanger (1) Generated by `MeetBot`_ 0.1.4 From nusiddiq at redhat.com Tue Sep 19 16:36:01 2017 From: nusiddiq at redhat.com (Numan Siddique) Date: Tue, 19 Sep 2017 22:06:01 +0530 Subject: [rdo-list] OVS 2.8 in CentOS SIGs WAS Re: OVS 2.7 on rdo In-Reply-To: References: Message-ID: On Tue, Sep 19, 2017 at 7:16 PM, Josh Boyer wrote: > On Tue, Sep 19, 2017 at 4:08 AM, Numan Siddique > wrote: > > > > > > On Tue, Sep 19, 2017 at 4:52 AM, Alan Pevec wrote: > >> > >> On Tue, Sep 12, 2017 at 10:50 AM, Numan Siddique > >> wrote: > >> > Hi Alan, > >> > > >> > OVS 2.8 is now availalbe [1] and we would like to have it in RDO. > >> > > >> > Is it possible to have the OVS 2.8 rpms in candidate repo. I will > update > >> > the > >> > patch [2] and make sure it passes so that we don't see any regressions > >> > during update. > >> > > >> > [1] - > >> > > >> > https://mail.openvswitch.org/pipermail/ovs-discuss/2017- > September/045235.html > >> > [2] - https://review.openstack.org/#/c/473191/ > >> > >> Hi Numan, > >> > >> I've rebased two patches we have in RDO [3] rebuilds, on top of > >> Timothy's Fedora 28 RPM [4] and it almost worked, only ppc64le arch > >> build [5] failed with: > >> > >> | > >> /builddir/build/BUILD/openvswitch-2.8.0/dpdk-stable- > 17.05.1/ppc_64-power8-linuxapp-gcc/lib/librte_eal.a(eal_common_options.o): > >> In function `eal_plugins_init': > >> | > >> /builddir/build/BUILD/openvswitch-2.8.0/dpdk-stable- > 17.05.1/lib/librte_eal/common/eal_common_options.c:240: > >> undefined reference to `dlopen' > >> | > >> /builddir/build/BUILD/openvswitch-2.8.0/dpdk-stable- > 17.05.1/lib/librte_eal/common/eal_common_options.c:242: > >> undefined reference to `dlerror' > >> | collect2: error: ld returned 1 exit status > >> > >> ppc64le folks, please help! > >> > > > > > > Thanks Alan. Hope the build would be resolved soon. > > I looked at this briefly. The compile error is odd, but we wouldn't > even hit that if the initial testcase run completed successfully. > There are two unexpected failures: > > 2355: ovn -- dns lookup : 1 HV, 2 LS, 2 LSPs/LS FAILED (ovn.at:6812) > 2364: ovn -- ensure one gw controller restart in HA doesn't bounce the > master FAILED (ovn.at:8480) > This is odd. Are the tests failing consistently ? I will have a look. Thanks Numan > > Not sure why those two failed. > > josh > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwboyer at redhat.com Tue Sep 19 17:49:05 2017 From: jwboyer at redhat.com (Josh Boyer) Date: Tue, 19 Sep 2017 13:49:05 -0400 Subject: [rdo-list] OVS 2.8 in CentOS SIGs WAS Re: OVS 2.7 on rdo In-Reply-To: References: Message-ID: On Tue, Sep 19, 2017 at 12:36 PM, Numan Siddique wrote: > > > On Tue, Sep 19, 2017 at 7:16 PM, Josh Boyer wrote: >> >> On Tue, Sep 19, 2017 at 4:08 AM, Numan Siddique >> wrote: >> > >> > >> > On Tue, Sep 19, 2017 at 4:52 AM, Alan Pevec wrote: >> >> >> >> On Tue, Sep 12, 2017 at 10:50 AM, Numan Siddique >> >> wrote: >> >> > Hi Alan, >> >> > >> >> > OVS 2.8 is now availalbe [1] and we would like to have it in RDO. >> >> > >> >> > Is it possible to have the OVS 2.8 rpms in candidate repo. I will >> >> > update >> >> > the >> >> > patch [2] and make sure it passes so that we don't see any >> >> > regressions >> >> > during update. >> >> > >> >> > [1] - >> >> > >> >> > >> >> > https://mail.openvswitch.org/pipermail/ovs-discuss/2017-September/045235.html >> >> > [2] - https://review.openstack.org/#/c/473191/ >> >> >> >> Hi Numan, >> >> >> >> I've rebased two patches we have in RDO [3] rebuilds, on top of >> >> Timothy's Fedora 28 RPM [4] and it almost worked, only ppc64le arch >> >> build [5] failed with: >> >> >> >> | >> >> >> >> /builddir/build/BUILD/openvswitch-2.8.0/dpdk-stable-17.05.1/ppc_64-power8-linuxapp-gcc/lib/librte_eal.a(eal_common_options.o): >> >> In function `eal_plugins_init': >> >> | >> >> >> >> /builddir/build/BUILD/openvswitch-2.8.0/dpdk-stable-17.05.1/lib/librte_eal/common/eal_common_options.c:240: >> >> undefined reference to `dlopen' >> >> | >> >> >> >> /builddir/build/BUILD/openvswitch-2.8.0/dpdk-stable-17.05.1/lib/librte_eal/common/eal_common_options.c:242: >> >> undefined reference to `dlerror' >> >> | collect2: error: ld returned 1 exit status >> >> >> >> ppc64le folks, please help! >> >> >> > >> > >> > Thanks Alan. Hope the build would be resolved soon. >> >> I looked at this briefly. The compile error is odd, but we wouldn't >> even hit that if the initial testcase run completed successfully. >> There are two unexpected failures: >> >> 2355: ovn -- dns lookup : 1 HV, 2 LS, 2 LSPs/LS FAILED (ovn.at:6812) >> 2364: ovn -- ensure one gw controller restart in HA doesn't bounce the >> master FAILED (ovn.at:8480) > > > This is odd. Are the tests failing consistently ? I will have a look. I have no idea. Has anyone tried rebuilds? Timothy noted that this package build successfully for ppc64le in Fedora, so the tests passed there. He's also going to update the rawhide package to use dpdk-stable-17.05.2, but I didn't immediately see anything in .2 that would speak to this. josh From apevec at redhat.com Tue Sep 19 21:32:00 2017 From: apevec at redhat.com (Alan Pevec) Date: Tue, 19 Sep 2017 23:32:00 +0200 Subject: [rdo-list] OVS 2.8 in CentOS SIGs WAS Re: OVS 2.7 on rdo In-Reply-To: References: Message-ID: On Tue, Sep 19, 2017 at 7:49 PM, Josh Boyer wrote: > I have no idea. Has anyone tried rebuilds? Timothy noted that this > package build successfully for ppc64le in Fedora, so the tests passed > there. He's also going to update the rawhide package to use > dpdk-stable-17.05.2, but I didn't immediately see anything in .2 that > would speak to this. -2 worked https://cbs.centos.org/koji/buildinfo?buildID=19946 Numan, you can test it by adding http://cbs.centos.org/repos/cloud7-openstack-queens-candidate/x86_64/os/ repo in the CI job. Cheers, Alan From jruzicka at redhat.com Wed Sep 20 16:07:36 2017 From: jruzicka at redhat.com (Jakub Ruzicka) Date: Wed, 20 Sep 2017 18:07:36 +0200 Subject: [rdo-list] [Meeting] RDO meeting (2017-09-20) Minutes Message-ID: ============================== #rdo: RDO meeting - 2017-09-20 ============================== Meeting started by jruzicka at 15:01:33 UTC. The full logs are available athttp://eavesdrop.openstack.org/meetings/rdo_meeting___2017_09_20/2017/rdo_meeting___2017_09_20.2017-09-20-15.01.log.html . Meeting summary --------------- * Hello #rdo o/ (jruzicka, 15:02:05) * Infrastructure topics (jruzicka, 15:06:35) * rdopkg Release bumping support (jruzicka, 15:16:41) * LINK: https://softwarefactory-project.io/r/#/c/9636/ (jruzicka, 15:23:09) * LINK: https://softwarefactory-project.io/r/#/c/9724 has some of the good behavior from current release (jschlueter, 15:24:06) * LINK: https://softwarefactory-project.io/r/#/c/9724/1/features/fix.feature (jruzicka, 15:27:20) * ACTION: jruzicka to research Release formats in the wilds (jruzicka, 15:36:47) * ACTION: everyone to think about best Trunk Release format (jruzicka, 15:38:58) * ACTION: jschlueter to collect interesting OSP NVR's to jruzicka and pick out interesting cases (jschlueter, 15:39:31) * PTG interviews starting to appear here: http://youtube.com/RDOCommunity (jruzicka, 15:40:37) * Test day schedule for Queens (jruzicka, 15:42:38) * ceph/ceph-ansible and tripleo integration (jruzicka, 15:50:09) * hallway-track discussion at PTG brought up how we can improve ceph/ceph-ansible and tripleo integration and testing (jschlueter, 15:51:47) * Looking for additional feedback and input on how Storage SIG can setup more workflow around ceph/ceph-ansible and tripleo integration (jschlueter, 15:58:36) * Chair for next meetig (jruzicka, 16:01:00) * ACTION: amoralej to chair next meeting (jruzicka, 16:01:40) Meeting ended at 16:01:59 UTC. Action items, by person ----------------------- * amoralej * amoralej to chair next meeting * jruzicka * jruzicka to research Release formats in the wilds * jschlueter to collect interesting OSP NVR's to jruzicka and pick out interesting cases * jschlueter * jschlueter to collect interesting OSP NVR's to jruzicka and pick out interesting cases People present (lines said) --------------------------- * jruzicka (66) * jschlueter (33) * rbowen (29) * amoralej (25) * Duck (24) * apevec (18) * gfidente (12) * fultonj (9) * openstack (9) * jpena (7) * PagliaccisCloud (4) * trown (4) * snecklifter (4) * rdogerrit (3) * chandankumar (2) * flepied (1) * myoung (1) * jatanmalde (1) Generated by `MeetBot`_ 0.1.4 -------------- next part -------------- An HTML attachment was scrubbed... URL: From fboucher at redhat.com Thu Sep 21 09:30:38 2017 From: fboucher at redhat.com (Fabien Boucher) Date: Thu, 21 Sep 2017 11:30:38 +0200 Subject: [rdo-list] RDO Git commits stats Message-ID: Hi everyone, I have built an instance of a tool that compute Git commits statistics for the RDO's repositories. I think it is relevant to mention it on this ML so I'm sharing the URL. You can access RDO stats here: http://38.145.33.181/repoxplorer/project.html?pid=RDO/rdo RDO/rdo is RDO's repositories defined in the rdoinfo/rdo.yml file. Furthermore the instance have an index of the OpenStack Git commits based on the governance/reference/projects.yaml file. Cheers, Fabien Boucher -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbowen at redhat.com Thu Sep 21 13:51:54 2017 From: rbowen at redhat.com (Rich Bowen) Date: Thu, 21 Sep 2017 13:51:54 +0000 Subject: [rdo-list] RDO Git commits stats In-Reply-To: References: Message-ID: Thanks, Fabien! This is really cool stuff, and very useful for the kinds of reports I often get asked for. Is this somewhere that we can count on being there long-term? Do we want to move it to somewhere more permanent, in RDO-Cloud? --Rich On Thu, Sep 21, 2017 at 5:47 AM Fabien Boucher wrote: > Hi everyone, > > I have built an instance of a tool that compute Git commits statistics for > the RDO's repositories. I think it is relevant to mention it on this ML so > I'm sharing the URL. > > You can access RDO stats here: > http://38.145.33.181/repoxplorer/project.html?pid=RDO/rdo > > RDO/rdo is RDO's repositories defined in the rdoinfo/rdo.yml file. > > Furthermore the instance have an index of the OpenStack Git commits based > on the > governance/reference/projects.yaml file. > > Cheers, > > Fabien Boucher > _______________________________________________ > 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 kdreyer at redhat.com Thu Sep 21 15:11:10 2017 From: kdreyer at redhat.com (Ken Dreyer) Date: Thu, 21 Sep 2017 09:11:10 -0600 Subject: [rdo-list] ceph-ansible auto builds in cbs.centos.org In-Reply-To: References: Message-ID: On Mon, Sep 18, 2017 at 2:55 PM, John Fulton wrote: > For which repos are you doing this? I.e. what subset of the following > is this now the case for? > > echo ceph-{jewel,luminous}-{release,testing,candidate} Great question. Currently this is only affecting ceph-{jewel,luminous}-candidate only. The other four, ceph-{jewel,luminous}-{release,testing} are not yet automated. I've made some updates to my script at https://github.com/ktdreyer/ceph-ansible-cbs. The relevant changes: - All new ceph-ansible v3 Git tags are now built in the -jewel CBS build target. - These builds are immediately tagged into the CBS -luminous-candidate tag as well. The next steps I'm interested in implementing: - Automatically tagging builds into -jewel-testing and -luminous-testing too. I have a hunch that rdoinfo could handle some of this, but it's not completely clear to me how that works. I think I will need another "for dummies" walkthrough of that :) - Ken From fboucher at redhat.com Thu Sep 21 15:24:53 2017 From: fboucher at redhat.com (Fabien Boucher) Date: Thu, 21 Sep 2017 17:24:53 +0200 Subject: [rdo-list] RDO Git commits stats In-Reply-To: References: Message-ID: Hi, On Thu, Sep 21, 2017 at 3:51 PM, Rich Bowen wrote: > Thanks, Fabien! This is really cool stuff, and very useful for the kinds > of reports I often get asked for. > Nice ! don't hesitate to ask me for improvements I'll be happy to implement them if any. > Is this somewhere that we can count on being there long-term? Do we want > to move it to somewhere more permanent, in RDO-Cloud? > The instance is hosted on rdo-cloud on my tenant and yes absolutely I'm going to maintain it up and up to date. Actually I don't mind keeping it on my tenant or moving the node elsewhere. > > --Rich > > On Thu, Sep 21, 2017 at 5:47 AM Fabien Boucher > wrote: > >> Hi everyone, >> >> I have built an instance of a tool that compute Git commits statistics >> for the RDO's repositories. I think it is relevant to mention it on this ML >> so I'm sharing the URL. >> >> You can access RDO stats here: http://38.145.33.181/ >> repoxplorer/project.html?pid=RDO/rdo >> >> RDO/rdo is RDO's repositories defined in the rdoinfo/rdo.yml file. >> >> Furthermore the instance have an index of the OpenStack Git commits based >> on the >> governance/reference/projects.yaml file. >> >> Cheers, >> >> Fabien Boucher >> _______________________________________________ >> 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 dms at redhat.com Thu Sep 21 17:15:26 2017 From: dms at redhat.com (David Moreau Simard) Date: Thu, 21 Sep 2017 13:15:26 -0400 Subject: [rdo-list] RDO Git commits stats In-Reply-To: References: Message-ID: I think long term we can host this directly from our software factory instance on review.rdoproject.org (RepoXplorer is part of software factory). I believe the version that Fabien stood up is more up to date than the one we're currently bundling but this won't always be the case. David Moreau Simard Senior Software Engineer | OpenStack RDO dmsimard = [irc, github, twitter] On Thu, Sep 21, 2017 at 11:24 AM, Fabien Boucher wrote: > Hi, > > On Thu, Sep 21, 2017 at 3:51 PM, Rich Bowen wrote: >> >> Thanks, Fabien! This is really cool stuff, and very useful for the kinds >> of reports I often get asked for. > > > Nice ! don't hesitate to ask me for improvements I'll be happy to implement > them if any. > >> >> Is this somewhere that we can count on being there long-term? Do we want >> to move it to somewhere more permanent, in RDO-Cloud? > > > The instance is hosted on rdo-cloud on my tenant and yes absolutely I'm > going to maintain it up and up to date. > Actually I don't mind keeping it on my tenant or moving the node elsewhere. > >> >> >> --Rich >> >> On Thu, Sep 21, 2017 at 5:47 AM Fabien Boucher >> wrote: >>> >>> Hi everyone, >>> >>> I have built an instance of a tool that compute Git commits statistics >>> for the RDO's repositories. I think it is relevant to mention it on this ML >>> so I'm sharing the URL. >>> >>> You can access RDO stats here: >>> http://38.145.33.181/repoxplorer/project.html?pid=RDO/rdo >>> >>> RDO/rdo is RDO's repositories defined in the rdoinfo/rdo.yml file. >>> >>> Furthermore the instance have an index of the OpenStack Git commits based >>> on the >>> governance/reference/projects.yaml file. >>> >>> Cheers, >>> >>> Fabien Boucher >>> _______________________________________________ >>> 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 nusiddiq at redhat.com Thu Sep 21 18:11:53 2017 From: nusiddiq at redhat.com (Numan Siddique) Date: Thu, 21 Sep 2017 23:41:53 +0530 Subject: [rdo-list] OVS 2.8 in CentOS SIGs WAS Re: OVS 2.7 on rdo In-Reply-To: References: Message-ID: On Wed, Sep 20, 2017 at 3:02 AM, Alan Pevec wrote: > On Tue, Sep 19, 2017 at 7:49 PM, Josh Boyer wrote: > > I have no idea. Has anyone tried rebuilds? Timothy noted that this > > package build successfully for ppc64le in Fedora, so the tests passed > > there. He's also going to update the rawhide package to use > > dpdk-stable-17.05.2, but I didn't immediately see anything in .2 that > > would speak to this. > > -2 worked https://cbs.centos.org/koji/buildinfo?buildID=19946 > > Numan, you can test it by adding > http://cbs.centos.org/repos/cloud7-openstack-queens-candidate/x86_64/os/ > repo in the CI job. > > Thank you Alan. I will update the patch to test the update from OVS 2.7 to OVS 2.8 > Cheers, > Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From javier.pena at redhat.com Fri Sep 22 08:07:07 2017 From: javier.pena at redhat.com (Javier Pena) Date: Fri, 22 Sep 2017 04:07:07 -0400 (EDT) Subject: [rdo-list] RDO Git commits stats In-Reply-To: References: Message-ID: <1844921007.9435309.1506067627701.JavaMail.zimbra@redhat.com> ----- Original Message ----- > I think long term we can host this directly from our software factory > instance on review.rdoproject.org (RepoXplorer is part of software > factory). > > I believe the version that Fabien stood up is more up to date than the > one we're currently bundling but this won't always be the case. > Yes, definitely +1 to hosting it as part of review.rdoproject.org, once the version is up to date. One less machine to care about. Regards, Javier > David Moreau Simard > Senior Software Engineer | OpenStack RDO > > dmsimard = [irc, github, twitter] > > > On Thu, Sep 21, 2017 at 11:24 AM, Fabien Boucher wrote: > > Hi, > > > > On Thu, Sep 21, 2017 at 3:51 PM, Rich Bowen wrote: > >> > >> Thanks, Fabien! This is really cool stuff, and very useful for the kinds > >> of reports I often get asked for. > > > > > > Nice ! don't hesitate to ask me for improvements I'll be happy to implement > > them if any. > > > >> > >> Is this somewhere that we can count on being there long-term? Do we want > >> to move it to somewhere more permanent, in RDO-Cloud? > > > > > > The instance is hosted on rdo-cloud on my tenant and yes absolutely I'm > > going to maintain it up and up to date. > > Actually I don't mind keeping it on my tenant or moving the node elsewhere. > > > >> > >> > >> --Rich > >> > >> On Thu, Sep 21, 2017 at 5:47 AM Fabien Boucher > >> wrote: > >>> > >>> Hi everyone, > >>> > >>> I have built an instance of a tool that compute Git commits statistics > >>> for the RDO's repositories. I think it is relevant to mention it on this > >>> ML > >>> so I'm sharing the URL. > >>> > >>> You can access RDO stats here: > >>> http://38.145.33.181/repoxplorer/project.html?pid=RDO/rdo > >>> > >>> RDO/rdo is RDO's repositories defined in the rdoinfo/rdo.yml file. > >>> > >>> Furthermore the instance have an index of the OpenStack Git commits based > >>> on the > >>> governance/reference/projects.yaml file. > >>> > >>> Cheers, > >>> > >>> Fabien Boucher > >>> _______________________________________________ > >>> 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 djc636 at gmail.com Fri Sep 22 14:16:48 2017 From: djc636 at gmail.com (david caughey) Date: Fri, 22 Sep 2017 15:16:48 +0100 Subject: [rdo-list] proxy Message-ID: Hi Folks, I am trying to install Packstack Newton behind a proxy. I recently got the go ahead to build an oVirt environment which went well but I'm having issues getting Openstack Newton installed behind the proxy. There seems to be an issue with Proxy swift server? I have placed the necessary proxy settings in /etc/environment along wit the no_proxy settings and also set firefox to respect the proxy. Everything seems to go fine except proxy swift. Are there any guides or how tos for this type of situation? Or should I create the environment outside and import, /etc/swift/swift.conf [swift-hash] swift_hash_path_suffix = 6201ab08e9d345b7 [swift-constraints] max_header_size=8192 ]# openstack endpoint show swift +--------------+-----------------------------------------------+ | Field | Value | +--------------+-----------------------------------------------+ | adminurl | http://10.20.30.91:8080/v1/AUTH_%(tenant_id)s | | enabled | True | | id | 5ac84270d5cb406eaaf9181cb54ac141 | | internalurl | http://10.20.30.91:8080/v1/AUTH_%(tenant_id)s | | publicurl | http://10.20.30.91:8080/v1/AUTH_%(tenant_id)s | | region | RegionOne | | service_id | 30fbf4a88f8e4ae5bc945e7c4a1db851 | | service_name | swift | | service_type | object-store | +--------------+-----------------------------------------------+ # systemctl status openstack-swift-proxy ? openstack-swift-proxy.service - OpenStack Object Storage (swift) - Proxy Server Loaded: loaded (/usr/lib/systemd/system/openstack-swift-proxy.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Thu 2017-09-21 15:34:21 IST; 23h ago Process: 7123 ExecStart=/usr/bin/swift-proxy-server /etc/swift/proxy-server.conf (code=exited, status=1/FAILURE) Main PID: 7123 (code=exited, status=1/FAILURE) Sep 21 15:34:21 newton-1.eitte.lab swift-proxy-server[7123]: File "/usr/lib/python2.7/site-packages/keystoneauth1/session.py", line 681, in post Sep 21 15:34:21 newton-1.eitte.lab swift-proxy-server[7123]: return self.request(url, 'POST', **kwargs) Sep 21 15:34:21 newton-1.eitte.lab swift-proxy-server[7123]: File "/usr/lib/python2.7/site-packages/positional/__init__.py", line 101, in inner Sep 21 15:34:21 newton-1.eitte.lab swift-proxy-server[7123]: return wrapped(*args, **kwargs) Sep 21 15:34:21 newton-1.eitte.lab swift-proxy-server[7123]: File "/usr/lib/python2.7/site-packages/keystoneauth1/session.py", line 570, in request Sep 21 15:34:21 newton-1.eitte.lab swift-proxy-server[7123]: raise exceptions.from_response(resp, method, url) Sep 21 15:34:21 newton-1.eitte.lab swift-proxy-server[7123]: keystoneauth1.exceptions.http.Unauthorized: The request you have made requires ...35d80) Sep 21 15:34:21 newton-1.eitte.lab systemd[1]: openstack-swift-proxy.service: main process exited, code=exited, status=1/FAILURE Sep 21 15:34:21 newton-1.eitte.lab systemd[1]: Unit openstack-swift-proxy.service entered failed state. Sep 21 15:34:21 newton-1.eitte.lab systemd[1]: openstack-swift-proxy.service failed. Hint: Some lines were ellipsized, use -l to show in full. # tail /var/log/messages Sep 22 15:07:54 newton-1 swift-proxy-server: File "/usr/lib/python2.7/site-packages/keystoneauth1/session.py", line 681, in post Sep 22 15:07:54 newton-1 swift-proxy-server: return self.request(url, 'POST', **kwargs) Sep 22 15:07:54 newton-1 swift-proxy-server: File "/usr/lib/python2.7/site-packages/positional/__init__.py", line 101, in inner Sep 22 15:07:54 newton-1 swift-proxy-server: return wrapped(*args, **kwargs) Sep 22 15:07:54 newton-1 swift-proxy-server: File "/usr/lib/python2.7/site-packages/keystoneauth1/session.py", line 570, in request Sep 22 15:07:54 newton-1 swift-proxy-server: raise exceptions.from_response(resp, method, url) Sep 22 15:07:54 newton-1 swift-proxy-server: keystoneauth1.exceptions.http.Unauthorized: The request you have made requires authentication. (HTTP 401) (Request-ID: req-bfdb735b-36c9-4d42-b071-e79354d3cb9e) Sep 22 15:07:54 newton-1 systemd: openstack-swift-proxy.service: main process exited, code=exited, status=1/FAILURE Sep 22 15:07:54 newton-1 systemd: Unit openstack-swift-proxy.service entered failed state. Sep 22 15:07:54 newton-1 systemd: openstack-swift-proxy.service failed. Keystone logs (only error) 2017-09-22 15:05:23.158 3131 WARNING oslo_log.versionutils [req-87b12ed7-e93d-4dbc-832a-0a7b5e1e7f43 3c6b71072fdf48b0ac3f027b19fc1598 36354e11031a4f1a9676cd52b0b9f288 - default default] Deprecated: get_services of the v2 API is deprecated as of Mitaka in favor of a similar function in the v3 API and may be removed in Q. NetworkManager is disabled firewalld is disabled selinux is disabled httpd access 10.20.30.1 - - [21/Sep/2017:15:31:23 +0100] "GET /dashboard HTTP/1.1" 500 531 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0" 10.20.30.1 - - [21/Sep/2017:15:36:30 +0100] "GET /favicon.ico HTTP/1.1" 404 209 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0" 10.20.30.1 - - [21/Sep/2017:15:36:30 +0100] "GET /favicon.ico HTTP/1.1" 404 209 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0" ]# openstack service list +----------------------------------+------------+----------------+ | ID | Name | Type | +----------------------------------+------------+----------------+ | 08b9cd749a7c4088a51b49184c980549 | glance | image | | 288278e3de374eb59089ee4f2ae351d4 | aodh | alarming | | 298db4cec1ec4d109e11627a1719d7f3 | heat | orchestration | | 30fbf4a88f8e4ae5bc945e7c4a1db851 | swift | object-store | | 421ca271cfb145459c9a668a0a80b0b6 | neutron | network | | 896d90902f4541309595def5eacc60ca | nova | compute | | 8e8c0f9f141344499dfb46f99f01212c | cinderv2 | volumev2 | | a91615f268fa4847a0e180097b6dfb71 | cinderv3 | volumev3 | | ca0f48037e2b4349ba39ffb6fe9b221f | cinder | volume | | defa7e6ded2549c69b6186e3ef5cc94f | ceilometer | metering | | f3af042581654378ade38856bb2d86df | keystone | identity | | f3bd2e15def2481ca83ba5451bd17b01 | heat-cfn | cloudformation | | fe83eba206b446e4812a6c0ba30d16bd | gnocchi | metric | +----------------------------------+------------+----------------+ It seems the only thing not working is the horizon dashboard. Any ideas or hints would be appreciated, BR/David -------------- next part -------------- An HTML attachment was scrubbed... URL: From djc636 at gmail.com Sun Sep 24 15:54:14 2017 From: djc636 at gmail.com (david caughey) Date: Sun, 24 Sep 2017 16:54:14 +0100 Subject: [rdo-list] proxy In-Reply-To: References: Message-ID: Hi, It's ok I figured it out. When using packstack with 7.4 it must be a fresh install and not an update from 7.3. WHen using 7.4 it works fine. On 22 September 2017 at 15:16, david caughey wrote: > Hi Folks, > > I am trying to install Packstack Newton behind a proxy. > I recently got the go ahead to build an oVirt environment which went well > but I'm having issues getting Openstack Newton installed behind the proxy. > There seems to be an issue with Proxy swift server? > I have placed the necessary proxy settings in /etc/environment along wit > the no_proxy settings and also set firefox to respect the proxy. > Everything seems to go fine except proxy swift. > Are there any guides or how tos for this type of situation? > Or should I create the environment outside and import, > > /etc/swift/swift.conf > [swift-hash] > swift_hash_path_suffix = 6201ab08e9d345b7 > > [swift-constraints] > max_header_size=8192 > > ]# openstack endpoint show swift > +--------------+-----------------------------------------------+ > | Field | Value | > +--------------+-----------------------------------------------+ > | adminurl | http://10.20.30.91:8080/v1/AUTH_%(tenant_id)s | > | enabled | True | > | id | 5ac84270d5cb406eaaf9181cb54ac141 | > | internalurl | http://10.20.30.91:8080/v1/AUTH_%(tenant_id)s | > | publicurl | http://10.20.30.91:8080/v1/AUTH_%(tenant_id)s | > | region | RegionOne | > | service_id | 30fbf4a88f8e4ae5bc945e7c4a1db851 | > | service_name | swift | > | service_type | object-store | > +--------------+-----------------------------------------------+ > > # systemctl status openstack-swift-proxy > ? openstack-swift-proxy.service - OpenStack Object Storage (swift) - Proxy > Server > Loaded: loaded (/usr/lib/systemd/system/openstack-swift-proxy.service; > enabled; vendor preset: disabled) > Active: failed (Result: exit-code) since Thu 2017-09-21 15:34:21 IST; > 23h ago > Process: 7123 ExecStart=/usr/bin/swift-proxy-server > /etc/swift/proxy-server.conf (code=exited, status=1/FAILURE) > Main PID: 7123 (code=exited, status=1/FAILURE) > > Sep 21 15:34:21 newton-1.eitte.lab swift-proxy-server[7123]: File > "/usr/lib/python2.7/site-packages/keystoneauth1/session.py", line 681, in > post > Sep 21 15:34:21 newton-1.eitte.lab swift-proxy-server[7123]: return > self.request(url, 'POST', **kwargs) > Sep 21 15:34:21 newton-1.eitte.lab swift-proxy-server[7123]: File > "/usr/lib/python2.7/site-packages/positional/__init__.py", line 101, in > inner > Sep 21 15:34:21 newton-1.eitte.lab swift-proxy-server[7123]: return > wrapped(*args, **kwargs) > Sep 21 15:34:21 newton-1.eitte.lab swift-proxy-server[7123]: File > "/usr/lib/python2.7/site-packages/keystoneauth1/session.py", line 570, in > request > Sep 21 15:34:21 newton-1.eitte.lab swift-proxy-server[7123]: raise > exceptions.from_response(resp, method, url) > Sep 21 15:34:21 newton-1.eitte.lab swift-proxy-server[7123]: > keystoneauth1.exceptions.http.Unauthorized: The request you have made > requires ...35d80) > Sep 21 15:34:21 newton-1.eitte.lab systemd[1]: > openstack-swift-proxy.service: main process exited, code=exited, > status=1/FAILURE > Sep 21 15:34:21 newton-1.eitte.lab systemd[1]: Unit > openstack-swift-proxy.service entered failed state. > Sep 21 15:34:21 newton-1.eitte.lab systemd[1]: > openstack-swift-proxy.service failed. > Hint: Some lines were ellipsized, use -l to show in full. > > # tail /var/log/messages > Sep 22 15:07:54 newton-1 swift-proxy-server: File "/usr/lib/python2.7/site- > packages/keystoneauth1/session.py", line 681, in post > Sep 22 15:07:54 newton-1 swift-proxy-server: return self.request(url, > 'POST', **kwargs) > Sep 22 15:07:54 newton-1 swift-proxy-server: File "/usr/lib/python2.7/site- > packages/positional/__init__.py", line 101, in inner > Sep 22 15:07:54 newton-1 swift-proxy-server: return wrapped(*args, > **kwargs) > Sep 22 15:07:54 newton-1 swift-proxy-server: File "/usr/lib/python2.7/site- > packages/keystoneauth1/session.py", line 570, in request > Sep 22 15:07:54 newton-1 swift-proxy-server: raise > exceptions.from_response(resp, method, url) > Sep 22 15:07:54 newton-1 swift-proxy-server: keystoneauth1.exceptions.http.Unauthorized: > The request you have made requires authentication. (HTTP 401) (Request-ID: > req-bfdb735b-36c9-4d42-b071-e79354d3cb9e) > Sep 22 15:07:54 newton-1 systemd: openstack-swift-proxy.service: main > process exited, code=exited, status=1/FAILURE > Sep 22 15:07:54 newton-1 systemd: Unit openstack-swift-proxy.service > entered failed state. > Sep 22 15:07:54 newton-1 systemd: openstack-swift-proxy.service failed. > > Keystone logs (only error) > 2017-09-22 15:05:23.158 3131 WARNING oslo_log.versionutils > [req-87b12ed7-e93d-4dbc-832a-0a7b5e1e7f43 3c6b71072fdf48b0ac3f027b19fc1598 > 36354e11031a4f1a9676cd52b0b9f288 - default default] Deprecated: > get_services of the v2 API is deprecated as of Mitaka in favor of a similar > function in the v3 API and may be removed in Q. > > NetworkManager is disabled > firewalld is disabled > selinux is disabled > > httpd access > 10.20.30.1 - - [21/Sep/2017:15:31:23 +0100] "GET /dashboard HTTP/1.1" 500 > 531 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 > Firefox/52.0" > 10.20.30.1 - - [21/Sep/2017:15:36:30 +0100] "GET /favicon.ico HTTP/1.1" > 404 209 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 > Firefox/52.0" > 10.20.30.1 - - [21/Sep/2017:15:36:30 +0100] "GET /favicon.ico HTTP/1.1" > 404 209 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 > Firefox/52.0" > > ]# openstack service list > +----------------------------------+------------+----------------+ > | ID | Name | Type | > +----------------------------------+------------+----------------+ > | 08b9cd749a7c4088a51b49184c980549 | glance | image | > | 288278e3de374eb59089ee4f2ae351d4 | aodh | alarming | > | 298db4cec1ec4d109e11627a1719d7f3 | heat | orchestration | > | 30fbf4a88f8e4ae5bc945e7c4a1db851 | swift | object-store | > | 421ca271cfb145459c9a668a0a80b0b6 | neutron | network | > | 896d90902f4541309595def5eacc60ca | nova | compute | > | 8e8c0f9f141344499dfb46f99f01212c | cinderv2 | volumev2 | > | a91615f268fa4847a0e180097b6dfb71 | cinderv3 | volumev3 | > | ca0f48037e2b4349ba39ffb6fe9b221f | cinder | volume | > | defa7e6ded2549c69b6186e3ef5cc94f | ceilometer | metering | > | f3af042581654378ade38856bb2d86df | keystone | identity | > | f3bd2e15def2481ca83ba5451bd17b01 | heat-cfn | cloudformation | > | fe83eba206b446e4812a6c0ba30d16bd | gnocchi | metric | > +----------------------------------+------------+----------------+ > > It seems the only thing not working is the horizon dashboard. > Any ideas or hints would be appreciated, > > > > BR/David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nusiddiq at redhat.com Sun Sep 24 17:11:18 2017 From: nusiddiq at redhat.com (Numan Siddique) Date: Sun, 24 Sep 2017 22:41:18 +0530 Subject: [rdo-list] OVS 2.8 in CentOS SIGs WAS Re: OVS 2.7 on rdo In-Reply-To: References: Message-ID: On Thu, Sep 21, 2017 at 11:41 PM, Numan Siddique wrote: > > > On Wed, Sep 20, 2017 at 3:02 AM, Alan Pevec wrote: > >> On Tue, Sep 19, 2017 at 7:49 PM, Josh Boyer wrote: >> > I have no idea. Has anyone tried rebuilds? Timothy noted that this >> > package build successfully for ppc64le in Fedora, so the tests passed >> > there. He's also going to update the rawhide package to use >> > dpdk-stable-17.05.2, but I didn't immediately see anything in .2 that >> > would speak to this. >> >> -2 worked https://cbs.centos.org/koji/buildinfo?buildID=19946 >> >> Numan, you can test it by adding >> http://cbs.centos.org/repos/cloud7-openstack-queens-candidate/x86_64/os/ >> repo in the CI job. >> >> > Thank you Alan. I will update the patch to test the update from OVS 2.7 to > OVS 2.8 > > Hi Alan, I tested the upgrade from OVS 2.7.2 to OVS 2.8.0-2 (using the queens-candidate repo) in this patch - https://review.openstack.org/#/c/506888/ Please have a look at the job - gate-tripleo-ci-centos-7-containers-multinode-upgrades-nv and the log files. Even though the job status says failed, which I am not sure why, but from the logs I can see that - the overcloud deployment is successful (with OVS 2.7.2) - [1] - overcloud upgrade is aslo successful (with OVS 2.8) - [2] - Ping test validation is also successful - [3] > > [1] - http://logs.openstack.org/88/506888/3/check/gate-tripleo-ci-centos-7-containers-multinode-upgrades-nv/fde3ae5/logs/subnode-2/var/log/openvswitch/ovsdb-server.log.txt.gz http://logs.openstack.org/88/506888/3/check/gate-tripleo-ci-centos-7-containers-multinode-upgrades-nv/fde3ae5/logs/undercloud/home/jenkins/overcloud_deploy.log.txt.gz [2] - http://logs.openstack.org/88/506888/3/check/gate-tripleo-ci-centos-7-containers-multinode-upgrades-nv/fde3ae5/logs/subnode-2/var/log/yum.log.txt.gz http://logs.openstack.org/88/506888/3/check/gate-tripleo-ci-centos-7-containers-multinode-upgrades-nv/fde3ae5/logs/undercloud/home/jenkins/overcloud_upgrade_console.log.txt.gz [3] - http://logs.openstack.org/88/506888/3/check/gate-tripleo-ci-centos-7-containers-multinode-upgrades-nv/fde3ae5/logs/undercloud/home/jenkins/overcloud_validate.log.txt.gz Thanks Numan > Cheers, >> Alan >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hguemar at fedoraproject.org Mon Sep 25 15:00:04 2017 From: hguemar at fedoraproject.org (hguemar at fedoraproject.org) Date: Mon, 25 Sep 2017 15:00:04 +0000 (UTC) Subject: [rdo-list] [Fedocal] Reminder meeting : RDO meeting Message-ID: <20170925150004.EFE9B60005B3@fedocal02.phx2.fedoraproject.org> Dear all, You are kindly invited to the meeting: RDO meeting on 2017-09-27 from 15:00:00 to 16:00:00 UTC At rdo at irc.freenode.net The meeting will be about: RDO IRC meeting [Agenda at https://etherpad.openstack.org/p/RDO-Meeting ](https://etherpad.openstack.org/p/RDO-Meeting) Every Wednesday on #rdo on Freenode IRC Source: https://apps.fedoraproject.org/calendar/meeting/2017/ From chkumar246 at gmail.com Tue Sep 26 01:30:03 2017 From: chkumar246 at gmail.com (chkumar246 at gmail.com) Date: Tue, 26 Sep 2017 01:30:03 +0000 (UTC) Subject: [rdo-list] [Fedocal] Reminder meeting : RDO Office Hours Message-ID: <20170926013003.AF22B60005B3@fedocal02.phx2.fedoraproject.org> Dear all, You are kindly invited to the meeting: RDO Office Hours on 2017-09-26 from 13:30:00 to 15:30:00 UTC The meeting will be about: The meeting will be about RDO Office Hour. Aim: To keep up with increasing participation, we'll host office hours to add more easy fixes and provide mentoring to newcomers. [Agenda at RDO Office Hour easyfixes](https://review.rdoproject.org/etherpad/p/rdo-office-hour-easyfixes) Source: https://apps.fedoraproject.org/calendar/meeting/6374/ From arxcruz at redhat.com Tue Sep 26 14:52:57 2017 From: arxcruz at redhat.com (Arx Cruz) Date: Tue, 26 Sep 2017 16:52:57 +0200 Subject: [rdo-list] RDO-Infra Sprint meeting - Sep 25 Message-ID: Hello, Here?s the highlights from TripleO CI Squad meeting from September 25 As many of you are aware, we are changing the way the team work, and instead of each member work on their own silo, we are now focused on work together to solve one epic task that will involve all the members. In other words, to work as a real team. We are also adopting the Ruck and Rover methodologie, where every week one person will be responsible for monitoring the TripleO and RDO CI and reporting issues, releasing the rest of the team of this duty in order to focus on improvements in our CI. You can read more about Ruck and Rover here: https://en.wikipedia.org/wiki/Ruckman_(Australian_rules_football) We are going to work on sprints of one week each one, however, for this particular sprint, we are going to work on that for two weeks, since this is the first one and we are experimenting how things will go on. - Roles - The Ruck and the Rover will be responsible for any CI problems, so if you have anything related to CI, please contact them. The rest of the team will work on the sprint - Ruck - Wes Hayutin - Gael 9/26 and 9/27 - Rover - John Trowbridge - Team - Arx Cruz - Ronelle Landy - Attila Darazs - Gabriele Cerami - Sagi Shnaidman - Gael Chamoulaud - Matt Young - Scrum - We are going to have daily ?automatic? scrum, where each member of the team will write on https://etherpad.openstack.org/p/tripleo-ci-squad-scrum what they are doing, what they are planning next, and any blocks. We will also have two quickly meetings per week to discuss and review the tasks. - For this sprint - After review the proposed topics from the UA, the team voted to work on utilizing the DLRN api across TripleO and RDO to report job status and promotions. The reason was that this is a good exercise to the whole team get knowledge about DLRN and also the perfect timing since we are between releases, and this will be required for future tasks that we have in queue. - The epic task with more information can be found here https://trello.com/c/5FnfGByl/334-base-the-promotion-pipeline-of-upstream-phase1-and-phase2-on-dlrn-api-dlrn-links-containers-and-images - Tasks can be found in both the trelo card above, or in the TripleO Ci Squad trello board using the filter by label ?Sprint 1 (Sep 25 - Oct 10)? or clicking in this link here https://trello.com/b/U1ITy0cu/tripleo-ci-squad?menu=filter&filter=label:Sprint%201%20%20(Sept%2025%20-%20Oct%2010) If you have any questions, suggestions please let us know. Your feedback is very important to us! Kind regards, Arx Cruz -------------- next part -------------- An HTML attachment was scrubbed... URL: From chkumar246 at gmail.com Tue Sep 26 15:35:59 2017 From: chkumar246 at gmail.com (Chandan kumar) Date: Tue, 26 Sep 2017 21:05:59 +0530 Subject: [rdo-list] [Minutes] RDO Office Hour - 2017-09-26 Message-ID: ================================== #rdo: RDO Office Hour - 2017-09-26 ================================== Meeting started by chandankumar at 13:33:36 UTC. The full logs are available at http://eavesdrop.openstack.org/meetings/rdo_office_hour___2017_09_26/2017/rdo_office_hour___2017_09_26.2017-09-26-13.33.log.html . Meeting summary --------------- * LINK: https://review.rdoproject.org/etherpad/p/rdo-office-hour-easyfixes (chandankumar, 13:34:13) * Roll Call (chandankumar, 13:34:20) * If a package in RDO still in review and Feel free to add Depends flag with RDO Queens Tracker https://bugzilla.redhat.com/show_bug.cgi?id=1486366 (chandankumar, 13:39:36) * rpm-macros reviews depends on https://softwarefactory-project.io/r/9699 and https://review.rdoproject.org/r/#/c/9716/ (chandankumar, 13:43:18) * we have merged almost all reviews related related https://github.com/redhat-openstack/easyfix/issues/23 (chandankumar, 15:29:57) * LINK: https://review.rdoproject.org/r/#/q/topic:easyfix/23 (chandankumar, 15:30:15) Meeting ended at 15:33:01 UTC. People present (lines said) --------------------------- * chandankumar (53) * rdogerrit (37) * alee (12) * openstack (10) * jschlueter (9) * number80 (8) * aditya_r (5) * ykarel (4) * jpena (4) * Duck (2) * panda (2) * amoralej (1) * mrunge (1) * rdobot (1) * shreshtha (1) * openstackgerrit (1) * jatanmalde (1) * EmilienM (1) * sfbender (1) Generated by `MeetBot`_ 0.1.4 From arxcruz at redhat.com Wed Sep 27 12:16:02 2017 From: arxcruz at redhat.com (Arx Cruz) Date: Wed, 27 Sep 2017 14:16:02 +0200 Subject: [rdo-list] DLRN api endpoint for OSP 10|11|12 Message-ID: Hello, In our effort to enable DLRN in RDO, we also would like to enable DLRN api endpoint it in OSP (10|11|12) promote jobs. To do so, we would like to request this for the infra team responsible to that. This is important so we can consolidate one single way to handle the packages, both for Upstream jobs, RDO jobs and OSP. Can someone please help us to enable it? What's the proper way to request this? Kind regards, Arx Cruz -------------- next part -------------- An HTML attachment was scrubbed... URL: From hguemar at fedoraproject.org Wed Sep 27 16:16:36 2017 From: hguemar at fedoraproject.org (=?UTF-8?Q?Ha=C3=AFkel?=) Date: Wed, 27 Sep 2017 18:16:36 +0200 Subject: [rdo-list] [Meeting] RDO meeting (2017-09-27) Minutes Message-ID: ============================== #rdo: RDO meeting - 2017-09-27 ============================== Meeting started by number80 at 15:01:06 UTC. The full logs are available at http://eavesdrop.openstack.org/meetings/rdo_meeting___2017_09_27/2017/rdo_meeting___2017_09_27.2017-09-27-15.01.log.html . Meeting summary --------------- * roll call (number80, 15:01:27) * LINK: https://etherpad.openstack.org/p/RDO-Meeting (number80, 15:03:00) * Can we have DLRN api endpoint for OSP in RDO infrastructure? (number80, 15:05:54) * OSP will start reporting data too dlrn_api via the dlrn hash it was imported from ... soon (trown, 15:24:43) * Mailman3 migration (number80, 15:26:36) * ACTION: Duck ping upstream about LMTP. Request for help if you can (number80, 15:37:39) * LINK: https://github.com/mailman/mailman/issues/152 (Duck, 15:39:12) * open floor (number80, 15:45:56) * amoralej chairing next meeting (number80, 15:46:14) * LINK: https://review.rdoproject.org/etherpad/p/dependencies-management (number80, 15:47:55) * ACTION: * help on brainstorming deps management (number80, 15:48:33) Meeting ended at 15:52:55 UTC. Action items, by person ----------------------- * Duck * Duck ping upstream about LMTP. Request for help if you can People present (lines said) --------------------------- * number80 (66) * Duck (43) * dmsimard (38) * trown (28) * myoung (28) * openstack (13) * arxcruz (10) * jpena (8) * amoralej (5) * rbowen (2) * rdogerrit (2) * jschlueter (2) * jruzicka (2) * PagliaccisCloud (1) * jatanmalde|lunch (1) * chandankumar (1) * jatanmalde (0) Generated by `MeetBot`_ 0.1.4 From hguemar at fedoraproject.org Thu Sep 28 12:56:59 2017 From: hguemar at fedoraproject.org (=?UTF-8?Q?Ha=C3=AFkel?=) Date: Thu, 28 Sep 2017 14:56:59 +0200 Subject: [rdo-list] [Proposal] Improve clients maintenance on Fedora Message-ID: Hi, If you're not aware, RDO is still maintaining OpenStack clients on Fedora. As many developers, end-users of RDO are using Fedora, it is important to provide at least client-side utilities so that more people can use OpenStack. I must admit, I'm doing a poor job as it's still semi-manual and we have to deal with sync issues. To improve that situation, I will be working on improving the tooling but also came up with this proposal to distribute the load. 1. create an OpenStack SIG within Fedora, initial members will be current RDO provenpackagers and volunteers 2. transfer ownership of all OpenStack packages to the SIG. This will enable any SIG member to sync packages. 3. set up more reliable automation to do the sync (will still required to be run by a human to handle manual merges) 4. set up proper CI to test clients on a weekly basis. All development will still happen in RDO gerrit, all discussions will happen during RDO weekly meeting. I plan to submit this + improvements that will be suggested in this thread to the next meeting, so speak up :) Regards, H. From amoralej at redhat.com Thu Sep 28 13:43:29 2017 From: amoralej at redhat.com (Alfredo Moralejo Alonso) Date: Thu, 28 Sep 2017 15:43:29 +0200 Subject: [rdo-list] [Proposal] Improve clients maintenance on Fedora In-Reply-To: References: Message-ID: On Thu, Sep 28, 2017 at 2:56 PM, Ha?kel wrote: > Hi, > > If you're not aware, RDO is still maintaining OpenStack clients on Fedora. > As many developers, end-users of RDO are using Fedora, it is important > to provide at least > client-side utilities so that more people can use OpenStack. > > I must admit, I'm doing a poor job as it's still semi-manual and we have to > deal with sync issues. > > To improve that situation, I will be working on improving the tooling but also > came up with this proposal to distribute the load. > > 1. create an OpenStack SIG within Fedora, initial members will be current > RDO provenpackagers and volunteers > 2. transfer ownership of all OpenStack packages to the SIG. > This will enable any SIG member to sync packages. > 3. set up more reliable automation to do the sync (will still required > to be run by a human > to handle manual merges) > 4. set up proper CI to test clients on a weekly basis. > +1 Sounds as a good plan, it's really something we need. > All development will still happen in RDO gerrit, all discussions will > happen during RDO weekly > meeting. > > I plan to submit this + improvements that will be suggested in this > thread to the next meeting, > so speak up :) > > > > 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 whayutin at redhat.com Thu Sep 28 14:39:25 2017 From: whayutin at redhat.com (Wesley Hayutin) Date: Thu, 28 Sep 2017 10:39:25 -0400 Subject: [rdo-list] static delorean-deps repos Message-ID: Greetings, Had a brief discussion on the release delivery meeting this morning with Jon Schlueter where as the rel-del had a requirement for the CI to constantly execute to retest any potential changes to the delorean-deps yum repo. This is required because it informs the import process. Ideally we don't have to constantly tax both our hardware and people resources because we have have an unpinned repo that can change at any moment. A static delorean-deps repo married to a delorean repo would be more efficient for everyone. How that is achieved is under discussion. This email is only to serve as an entry point for a public discussion around that issue. Thanks all! -------------- next part -------------- An HTML attachment was scrubbed... URL: From snecklifter at gmail.com Thu Sep 28 14:48:55 2017 From: snecklifter at gmail.com (Christopher Brown) Date: Thu, 28 Sep 2017 15:48:55 +0100 Subject: [rdo-list] [Proposal] Improve clients maintenance on Fedora In-Reply-To: References: Message-ID: On 28 September 2017 at 13:56, Ha?kel wrote: > Hi, > > If you're not aware, RDO is still maintaining OpenStack clients on Fedora. > As many developers, end-users of RDO are using Fedora, it is important > to provide at least > client-side utilities so that more people can use OpenStack. > > I must admit, I'm doing a poor job as it's still semi-manual and we have to > deal with sync issues. > > To improve that situation, I will be working on improving the tooling but > also > came up with this proposal to distribute the load. > > 1. create an OpenStack SIG within Fedora, initial members will be current > RDO provenpackagers and volunteers > 2. transfer ownership of all OpenStack packages to the SIG. > This will enable any SIG member to sync packages. > 3. set up more reliable automation to do the sync (will still required > to be run by a human > to handle manual merges) > 4. set up proper CI to test clients on a weekly basis. > > All development will still happen in RDO gerrit, all discussions will > happen during RDO weekly > meeting. > > I plan to submit this + improvements that will be suggested in this > thread to the next meeting, > so speak up :) > Sure, happy to help out with this in whatever way I can. -- Christopher Brown -------------- next part -------------- An HTML attachment was scrubbed... URL: From amoralej at redhat.com Thu Sep 28 16:07:05 2017 From: amoralej at redhat.com (Alfredo Moralejo Alonso) Date: Thu, 28 Sep 2017 18:07:05 +0200 Subject: [rdo-list] static delorean-deps repos In-Reply-To: References: Message-ID: On Thu, Sep 28, 2017 at 4:39 PM, Wesley Hayutin wrote: > Greetings, > > Had a brief discussion on the release delivery meeting this morning with Jon > Schlueter where as the rel-del had a requirement for the CI to constantly > execute to retest any potential changes to the delorean-deps yum repo. > This is required because it informs the import process. > > Ideally we don't have to constantly tax both our hardware and people > resources because we have have an unpinned repo that can change at any > moment. > > A static delorean-deps repo married to a delorean repo would be more > efficient for everyone. How that is achieved is under discussion. > Having static delorean-deps repo for a RDO Trunk hash may be problematic also because centos, virtualization and ceph repos are changing repos and we may need to introduce new dependencies for the same hash. What i'd propose is to have versioned dependencies repos so that jobs can easily report the version of deps used and replay the job with a specific dependencies snapshot if needed. > This email is only to serve as an entry point for a public discussion around > that issue. > > Thanks all! > > _______________________________________________ > 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 javier.pena at redhat.com Thu Sep 28 16:54:40 2017 From: javier.pena at redhat.com (Javier Pena) Date: Thu, 28 Sep 2017 12:54:40 -0400 (EDT) Subject: [rdo-list] [Proposal] Improve clients maintenance on Fedora In-Reply-To: References: Message-ID: <814517812.11461414.1506617680773.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hi, > > If you're not aware, RDO is still maintaining OpenStack clients on Fedora. > As many developers, end-users of RDO are using Fedora, it is important > to provide at least > client-side utilities so that more people can use OpenStack. > > I must admit, I'm doing a poor job as it's still semi-manual and we have to > deal with sync issues. > > To improve that situation, I will be working on improving the tooling but > also > came up with this proposal to distribute the load. > > 1. create an OpenStack SIG within Fedora, initial members will be current > RDO provenpackagers and volunteers > 2. transfer ownership of all OpenStack packages to the SIG. > This will enable any SIG member to sync packages. > 3. set up more reliable automation to do the sync (will still required > to be run by a human > to handle manual merges) > 4. set up proper CI to test clients on a weekly basis. > > All development will still happen in RDO gerrit, all discussions will > happen during RDO weekly > meeting. > > I plan to submit this + improvements that will be suggested in this > thread to the next meeting, > so speak up :) +1. In understand this will also apply to oslo and other required libraries, won't it? Regards, Javier > > > > 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 whayutin at redhat.com Thu Sep 28 17:06:38 2017 From: whayutin at redhat.com (Wesley Hayutin) Date: Thu, 28 Sep 2017 13:06:38 -0400 Subject: [rdo-list] static delorean-deps repos In-Reply-To: References: Message-ID: On Thu, Sep 28, 2017 at 12:07 PM, Alfredo Moralejo Alonso < amoralej at redhat.com> wrote: > On Thu, Sep 28, 2017 at 4:39 PM, Wesley Hayutin > wrote: > > Greetings, > > > > Had a brief discussion on the release delivery meeting this morning with > Jon > > Schlueter where as the rel-del had a requirement for the CI to constantly > > execute to retest any potential changes to the delorean-deps yum repo. > > This is required because it informs the import process. > > > > Ideally we don't have to constantly tax both our hardware and people > > resources because we have have an unpinned repo that can change at any > > moment. > > > > A static delorean-deps repo married to a delorean repo would be more > > efficient for everyone. How that is achieved is under discussion. > > > > Having static delorean-deps repo for a RDO Trunk hash may be > problematic also because centos, virtualization and ceph repos are > changing repos and we may need to introduce new > dependencies for the same hash. > Makes sense > > What i'd propose is to have versioned dependencies repos so that jobs > can easily report the version of deps used and replay the job with a > specific dependencies snapshot if needed. > Knowing if the delorean-deps have changed from one step to the next would certainly be a step in the right direction so thank you! This is a huge improvement over blindly having to rerun ci ALL THE TIME. It still seems like the wrong way to test a thing through a pipeline though. To properly CI/Test software through a chain of tests over time the rpm content should be LOCKED. I'm going to maintain this *is* a requirement. If we were to host a set of rpm that included the Base OS rpms, delorean and delorean deps as a snapshot in time via maybe pulp [1] or the equivilant then we would really be testing properly. I'm not saying this needs to be done right now, however I think this is the long term goal. I would like to discuss this goal further and see it tracked over time. [1] http://pulpproject.org/ > > > This email is only to serve as an entry point for a public discussion > around > > that issue. > > > > Thanks all! > > > > _______________________________________________ > > 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 jlabarre at redhat.com Thu Sep 28 17:21:39 2017 From: jlabarre at redhat.com (James LaBarre) Date: Thu, 28 Sep 2017 13:21:39 -0400 Subject: [rdo-list] Connecting to TripleO horizon (under quickstart) Message-ID: Trying to find how I should be connecting to Horizon as installed in a Quickstart installation. My connection would look like this: *MyLaptop -> vpn -> large-remote-host * on the large-remote-host I have the undercloud (directly accessible from large-remote-host) along with controller0 and novacompute0 (forwarded to large-remote-host through undercloud). How should I be connecting to Horizon, since I have so many layers/redirects in between. For that matter, is there a way to determine if Horizon is working at all ("openstack service list" doesn't show horizon as a service). (undercloud) [stack at undercloud ~]$ openstack service list +----------------------------------+------------------+-------------------------+ | ID | Name | Type | +----------------------------------+------------------+-------------------------+ | 1aa733bdce734d4780b5b5e4ae95b3ae | zaqar-websocket | messaging-websocket | | 40706a02e7cc48ffbe96463899ffc233 | keystone | identity | | 42ec6a4be14e4caebfd966fbb7f5887e | neutron | network | | 4cc628ee478549ada4689f0bc07c2c4c | ironic | baremetal | | 4e8429ec9b67491480f7d61b425a2c0c | heat-cfn | cloudformation | | 7258afcb547d43e0ad4c8d28e91f68a5 | glance | image | | 798a3c89a2f54ca483c302c363d827b1 | zaqar | messaging | | 93161b7459a746f6a9ed96aa4fd896bc | mistral | workflowv2 | | a2b11439cec94045a1c98834809d8cdf | ironic-inspector | baremetal-introspection | | e14d7534fb7d404bb34796dcb8e6ec33 | swift | object-store | | e388a17a1e424c35acb067c5e2065682 | nova | compute | | ec8d9da35b724d50a4f309141d30f331 | heat | orchestration | | f5f02530289b487c90d6c7ef6c1fd73a | placement | placement | +----------------------------------+------------------+-------------------------+ I suspect the quickstart script didn't configure everything (run as bash quickstart.sh --playbook quickstart-extras.yml --bootstrap --no-clone -t all -S overcloud-validate -R master 127.0.0.2) -------------- next part -------------- An HTML attachment was scrubbed... URL: From hguemar at fedoraproject.org Thu Sep 28 17:30:14 2017 From: hguemar at fedoraproject.org (=?UTF-8?Q?Ha=C3=AFkel?=) Date: Thu, 28 Sep 2017 19:30:14 +0200 Subject: [rdo-list] static delorean-deps repos In-Reply-To: References: Message-ID: 2017-09-28 18:07 GMT+02:00 Alfredo Moralejo Alonso : > On Thu, Sep 28, 2017 at 4:39 PM, Wesley Hayutin wrote: >> Greetings, >> >> Had a brief discussion on the release delivery meeting this morning with Jon >> Schlueter where as the rel-del had a requirement for the CI to constantly >> execute to retest any potential changes to the delorean-deps yum repo. >> This is required because it informs the import process. >> >> Ideally we don't have to constantly tax both our hardware and people >> resources because we have have an unpinned repo that can change at any >> moment. >> >> A static delorean-deps repo married to a delorean repo would be more >> efficient for everyone. How that is achieved is under discussion. >> > > Having static delorean-deps repo for a RDO Trunk hash may be > problematic also because centos, virtualization and ceph repos are > changing repos and we may need to introduce new > dependencies for the same hash. > Actually, it can be done for third-party repo (See below). We just need a step to retrieve, save yum metadata. Possibly, we may have to mangle base url but it's easy to do (yum metadata are just sqlite and xml databases). > What i'd propose is to have versioned dependencies repos so that jobs > can easily report the version of deps used and replay the job with a > specific dependencies snapshot if needed. > Just to clarify to the readers, we don't need to version the whole repositories only the yum metadata. By convention, published packages are not removed from public repos, and yum/dnf won't see newer packages that are not in metadata. So it's quite a storage-efficient way to handle the issue mentioned by Wes. >> This email is only to serve as an entry point for a public discussion around >> that issue. >> >> Thanks all! >> >> _______________________________________________ >> 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 Thu Sep 28 17:34:41 2017 From: hguemar at fedoraproject.org (=?UTF-8?Q?Ha=C3=AFkel?=) Date: Thu, 28 Sep 2017 19:34:41 +0200 Subject: [rdo-list] [Proposal] Improve clients maintenance on Fedora In-Reply-To: <814517812.11461414.1506617680773.JavaMail.zimbra@redhat.com> References: <814517812.11461414.1506617680773.JavaMail.zimbra@redhat.com> Message-ID: 2017-09-28 18:54 GMT+02:00 Javier Pena : > > > ----- Original Message ----- >> Hi, >> >> If you're not aware, RDO is still maintaining OpenStack clients on Fedora. >> As many developers, end-users of RDO are using Fedora, it is important >> to provide at least >> client-side utilities so that more people can use OpenStack. >> >> I must admit, I'm doing a poor job as it's still semi-manual and we have to >> deal with sync issues. >> >> To improve that situation, I will be working on improving the tooling but >> also >> came up with this proposal to distribute the load. >> >> 1. create an OpenStack SIG within Fedora, initial members will be current >> RDO provenpackagers and volunteers >> 2. transfer ownership of all OpenStack packages to the SIG. >> This will enable any SIG member to sync packages. >> 3. set up more reliable automation to do the sync (will still required >> to be run by a human >> to handle manual merges) >> 4. set up proper CI to test clients on a weekly basis. >> >> All development will still happen in RDO gerrit, all discussions will >> happen during RDO weekly >> meeting. >> >> I plan to submit this + improvements that will be suggested in this >> thread to the next meeting, >> so speak up :) > > +1. In understand this will also apply to oslo and other required libraries, won't it? > Yes, clients, SDK and oslo libs. H. > Regards, > Javier > >> >> >> >> 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 whayutin at redhat.com Thu Sep 28 17:44:49 2017 From: whayutin at redhat.com (Wesley Hayutin) Date: Thu, 28 Sep 2017 13:44:49 -0400 Subject: [rdo-list] static delorean-deps repos In-Reply-To: References: Message-ID: On Thu, Sep 28, 2017 at 1:30 PM, Ha?kel wrote: > 2017-09-28 18:07 GMT+02:00 Alfredo Moralejo Alonso : > > On Thu, Sep 28, 2017 at 4:39 PM, Wesley Hayutin > wrote: > >> Greetings, > >> > >> Had a brief discussion on the release delivery meeting this morning > with Jon > >> Schlueter where as the rel-del had a requirement for the CI to > constantly > >> execute to retest any potential changes to the delorean-deps yum repo. > >> This is required because it informs the import process. > >> > >> Ideally we don't have to constantly tax both our hardware and people > >> resources because we have have an unpinned repo that can change at any > >> moment. > >> > >> A static delorean-deps repo married to a delorean repo would be more > >> efficient for everyone. How that is achieved is under discussion. > >> > > > > Having static delorean-deps repo for a RDO Trunk hash may be > > problematic also because centos, virtualization and ceph repos are > > changing repos and we may need to introduce new > > dependencies for the same hash. > > > > Actually, it can be done for third-party repo (See below). We just > need a step to retrieve, > save yum metadata. Possibly, we may have to mangle base url but it's easy > to do > (yum metadata are just sqlite and xml databases). > > > What i'd propose is to have versioned dependencies repos so that jobs > > can easily report the version of deps used and replay the job with a > > specific dependencies snapshot if needed. > > > > Just to clarify to the readers, we don't need to version the whole > repositories only the yum > metadata. By convention, published packages are not removed from > public repos, and > yum/dnf won't see newer packages that are not in metadata. > > So it's quite a storage-efficient way to handle the issue mentioned by Wes. > Haikel, Would we be able to version the CentOS base repos as well via metadata? To Alfredo's point, if somethign changes in CentOS that requires a change to the delorean deps then we may have an issue. I'm not sure how often a change in CentOS requires a change to delorean-deps. I suspect if that happens often we will hit a lot failures. Thanks for the comments and feedback thus far! > > >> This email is only to serve as an entry point for a public discussion > around > >> that issue. > >> > >> Thanks all! > >> > >> _______________________________________________ > >> 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 hguemar at fedoraproject.org Thu Sep 28 18:12:39 2017 From: hguemar at fedoraproject.org (=?UTF-8?Q?Ha=C3=AFkel?=) Date: Thu, 28 Sep 2017 20:12:39 +0200 Subject: [rdo-list] static delorean-deps repos In-Reply-To: References: Message-ID: 2017-09-28 19:44 GMT+02:00 Wesley Hayutin : > > > On Thu, Sep 28, 2017 at 1:30 PM, Ha?kel wrote: >> >> 2017-09-28 18:07 GMT+02:00 Alfredo Moralejo Alonso : >> > On Thu, Sep 28, 2017 at 4:39 PM, Wesley Hayutin >> > wrote: >> >> Greetings, >> >> >> >> Had a brief discussion on the release delivery meeting this morning >> >> with Jon >> >> Schlueter where as the rel-del had a requirement for the CI to >> >> constantly >> >> execute to retest any potential changes to the delorean-deps yum repo. >> >> This is required because it informs the import process. >> >> >> >> Ideally we don't have to constantly tax both our hardware and people >> >> resources because we have have an unpinned repo that can change at any >> >> moment. >> >> >> >> A static delorean-deps repo married to a delorean repo would be more >> >> efficient for everyone. How that is achieved is under discussion. >> >> >> > >> > Having static delorean-deps repo for a RDO Trunk hash may be >> > problematic also because centos, virtualization and ceph repos are >> > changing repos and we may need to introduce new >> > dependencies for the same hash. >> > >> >> Actually, it can be done for third-party repo (See below). We just >> need a step to retrieve, >> save yum metadata. Possibly, we may have to mangle base url but it's easy >> to do >> (yum metadata are just sqlite and xml databases). >> >> > What i'd propose is to have versioned dependencies repos so that jobs >> > can easily report the version of deps used and replay the job with a >> > specific dependencies snapshot if needed. >> > >> >> Just to clarify to the readers, we don't need to version the whole >> repositories only the yum >> metadata. By convention, published packages are not removed from >> public repos, and >> yum/dnf won't see newer packages that are not in metadata. >> >> So it's quite a storage-efficient way to handle the issue mentioned by >> Wes. > > > Haikel, > > Would we be able to version the CentOS base repos as well via metadata? I am just pointing that this is possible without affecting RDO jobs (aka phase 1) nor CentOS repo. > To Alfredo's point, if somethign changes in CentOS that requires a change to > the delorean deps then we may have an issue. > No changes is required, we would just save the metadata somewhere and make it consumable for you. E.g : At the beginning of a promotion job, we would save the metadata of all the repositories used, and we could publish it somewhere with the right *.repo file. That does not mean or implies the promotion job would be using it. It can be used for other use-cases than yours but I'd like to keep that as a separate discussion to avoid confusion. In short, we're just adding a new *artefact* to the CI jobs, nothing more, nothing less. > I'm not sure how often a change in CentOS requires a change to > delorean-deps. > I suspect if that happens often we will hit a lot failures. > > Thanks for the comments and feedback thus far! > >> >> >> >> This email is only to serve as an entry point for a public discussion >> >> around >> >> that issue. >> >> >> >> Thanks all! >> >> >> >> _______________________________________________ >> >> 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 tdecacqu at redhat.com Thu Sep 28 18:16:00 2017 From: tdecacqu at redhat.com (Tristan Cacqueray) Date: Thu, 28 Sep 2017 18:16:00 +0000 Subject: [rdo-list] [Proposal] Improve clients maintenance on Fedora In-Reply-To: References: Message-ID: <1506622084.hz932184dp.tristanC@fedora> On September 28, 2017 12:56 pm, Ha?kel wrote: > Hi, > > If you're not aware, RDO is still maintaining OpenStack clients on Fedora. > As many developers, end-users of RDO are using Fedora, it is important > to provide at least > client-side utilities so that more people can use OpenStack. > > I must admit, I'm doing a poor job as it's still semi-manual and we have to > deal with sync issues. > > To improve that situation, I will be working on improving the tooling but also > came up with this proposal to distribute the load. > > 1. create an OpenStack SIG within Fedora, initial members will be current > RDO provenpackagers and volunteers > 2. transfer ownership of all OpenStack packages to the SIG. > This will enable any SIG member to sync packages. > 3. set up more reliable automation to do the sync (will still required > to be run by a human > to handle manual merges) Should we investigate a fedpkg/bodhi/koji integration so that packages are built in fedora once an update is merged on review.rdoproject.org? -Tristan > 4. set up proper CI to test clients on a weekly basis. > > All development will still happen in RDO gerrit, all discussions will > happen during RDO weekly > meeting. > > I plan to submit this + improvements that will be suggested in this > thread to the next meeting, > so speak up :) > > > > 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 > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From tony at bakeyournoodle.com Thu Sep 28 21:32:33 2017 From: tony at bakeyournoodle.com (Tony Breeds) Date: Fri, 29 Sep 2017 07:32:33 +1000 Subject: [rdo-list] [Proposal] Improve clients maintenance on Fedora In-Reply-To: References: Message-ID: <20170928213233.GH28251@thor.bakeyournoodle.com> On Thu, Sep 28, 2017 at 02:56:59PM +0200, Ha?kel wrote: > Hi, > > If you're not aware, RDO is still maintaining OpenStack clients on Fedora. > As many developers, end-users of RDO are using Fedora, it is important > to provide at least > client-side utilities so that more people can use OpenStack. > > I must admit, I'm doing a poor job as it's still semi-manual and we have to > deal with sync issues. > > To improve that situation, I will be working on improving the tooling but also > came up with this proposal to distribute the load. > > 1. create an OpenStack SIG within Fedora, initial members will be current > RDO provenpackagers and volunteers /me volunteers! Yours Tony. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From rbowen at redhat.com Fri Sep 29 16:47:22 2017 From: rbowen at redhat.com (Rich Bowen) Date: Fri, 29 Sep 2017 12:47:22 -0400 Subject: [rdo-list] Photos/Video from RDO @ OpenStack PTG Message-ID: <9ec20c04-23d5-74c3-9557-1c9475db1471@redhat.com> I've posted a few photos, and a video, from the RDO gathering at the OpenStack PTG in Denver. https://www.flickr.com/photos/rbowen/albums/72157687332260303 Thanks to all who attended! --Rich -- Rich Bowen: Community Architect rbowen at redhat.com @rbowen // @RDOCommunity // @CentOSProject 1 859 351 9166