From hguemar at fedoraproject.org Mon Oct 3 15:00:03 2016 From: hguemar at fedoraproject.org (hguemar at fedoraproject.org) Date: Mon, 3 Oct 2016 15:00:03 +0000 (UTC) Subject: [rdo-list] [Fedocal] Reminder meeting : RDO meeting Message-ID: <20161003150003.3DDE760A3FDC@fedocal02.phx2.fedoraproject.org> Dear all, You are kindly invited to the meeting: RDO meeting on 2016-10-05 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 rbowen at redhat.com Mon Oct 3 15:53:32 2016 From: rbowen at redhat.com (Rich Bowen) Date: Mon, 3 Oct 2016 11:53:32 -0400 Subject: [rdo-list] [Rdo-newsletter] October 2016 RDO Community Newsletter Message-ID: <88a9e5e4-439b-d573-c35f-5412dc948e5f@redhat.com> Having trouble reading the newsletter? You can read it online at https://www.rdoproject.org/newsletter/2016-october/ October 2016 RDO Community Newsletter Quick links: * Quick Start * Mailing Lists * RDO release packages * Review.RDOProject.org * RDO blog * Q&A * Open Tickets * Twitter * Newton release schedule Thanks for being part of the RDO community! Upcoming Events There's several events on the horizon that you should be aware of. LinuxCon Berlin This week, LinuxCon Europe will be held in Berlin, Germany, and RDO will be there. Drop by the Red Hat booth for RDO stickers, and to find out more about RDO and OpenStack. Christian Schwede will be speaking about OpenStack Swift , and will be available at the booth afterwards to answer your questions. If you can't make it to Berlin, you can watch the live video feed of the keynotes. OpenStack Summit and the RDO Community Meetup In just a few weeks, many of us will be in Barcelona for the OpenStack Summit . The summit, which will be held on October 25th through 28th, is where we will celebrate the Newton release, and begin planning for the Ocata release. While there, we'll be having the RDO community meetup, in conjunction with the Ceph community. We'll be gathering at the Barcelona Princess on Tuesday evening, the 25th, from 5pm to 8pm, for presentations about RDO and Ceph, as well as light refreshments and drinks. If you have something you'd like to present on for 5-10 minutes, please get in touch with me as soon as possible. We're also pleased to note that over 40 of our colleagues in the RDO project have talks accepted at the Summit, on a wide variety of topics, many directly related to their work on RDO. And we'll be in the Red Hat booth in the main exhibit hall. Come get your RDO duck . Meetups and other community events Other RDO events, including the many OpenStack meetups around the world, are always listed at http://rdoproject.org/events If you have an RDO-related event, please feel free to add it by submitting a pull request to https://github.com/rbowen/rh-events/blob/master/2016/RDO-Meetups.yml Mailing list catch-up In case you missed it, here's a few highlights from rdo-list that you may have missed. * Improving the test day experience - There was some discussion about how to improve test days, to make them more welcoming to beginners, as well as to existing users looking for a preview of upcoming features. * CentOS Build System - A discussion of the CentOS build system and the Cloud SIG. * RabbitMQ version in RDO * Maintaining os-*-config in Fedora As always, you can look through the history of the discussion in the archives and jump into any thread through that interface. Blog Posts The RDO community has numerous prolific bloggers who keep us updated on the state of development in the OpenStack world. Here's some of the great blog posts over the past month. *Our Cloud in Liberty* by Tim Bell The upgrade to Liberty for the CERN cloud was completed at the end of August. Working with the upstream OpenStack, Puppet and RDO communities, this went pretty smoothly without any issues so there is no significant advice to report. Read more at http://tm3.org/bc *Red Hat OpenStack Platform and Tesora Database-as-a-Service Platform: What?s New* by Rob Young, Principal Product Manager, Red Hat As OpenStack users build or migrate more applications and services for private cloud deployment, users are expanding their plans for how these deployments will be serviced by non-core, emerging components. Read more at http://tm3.org/b6 *Integrating Red Hat Virtualization and Red Hat OpenStack Platform with Neutron Networking* by CaptainKVM As applications are designed, redesigned, or even simply thought about at a high level, we frequently think about technical barriers along side business needs. Read more at http://tm3.org/b7 *Complex data transformations with nested Heat intrinsic functions* by Steve Hardy Disclaimer, what follows is either pretty neat, or pure-evil depending your your viewpoint ;) But it's based on a real use-case and it works, so I'm posting this to document the approach, why it's needed, and hopefully stimulate some discussion around optimizations leading to a improved/simplified implementation in the future. ? read more at http://tm3.org/9y *Red Hat OpenStack Platform 9 is here! So what?s new?* by Marcos Garcia This week we released the latest version of our OpenStack product, Red Hat OpenStack Platform 9. This release contains more than 500 downstream enhancements, bug fixes, documentation changes, and security updates. ? read more at http://tm3.org/9z Follow the http://rdoproject.org/blog/ for weekly updates of our community's blogging. Community meetings Every Wednesday at 15:00 UTC, we have the weekly RDO community meeting on the #RDO channel on Freenode IRC. And at 15:00 UTC Thursdays, we have the CentOS Cloud SIG Meeting on #centos-devel. Keep in touch There's lots of ways to stay in in touch with what's going on in the RDO community. The best ways are ? WWW * RDO * OpenStack Q&A Mailing Lists: * rdo-list mailing list * This newsletter IRC * IRC - #rdo on Freenode.irc.net * Puppet module development - #rdo-puppet Social Media * Follow us on Twitter * Google+ * Facebook Thanks again for being part of the RDO community! -- Rich Bowen - rbowen at redhat.com RDO Community Liaison http://rdoproject.org @RDOCommunity -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Rdo-newsletter mailing list Rdo-newsletter at redhat.com https://www.redhat.com/mailman/listinfo/rdo-newsletter From bderzhavets at hotmail.com Mon Oct 3 17:46:53 2016 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Mon, 3 Oct 2016 17:46:53 +0000 Subject: [rdo-list] Does TripleO Release ( Newton ) coming up (10/06/16) with overcloud HA broken ? In-Reply-To: <20161003150003.3DDE760A3FDC@fedocal02.phx2.fedoraproject.org> References: <20161003150003.3DDE760A3FDC@fedocal02.phx2.fedoraproject.org> Message-ID: Following schema of http://www.anstack.com/blog/2016/07/04/manually-installing-tripleo-recipe.html slightly modified for network isolation http://dbaxps.blogspot.ru/2016/09/tripleo-deployment-of-master-branch-via_27.html Attempt of deploy #!/bin/bash -x source /home/stack/stackrc openstack overcloud deploy \ --libvirt-type qemu \ --ntp-server pool.ntp.org \ --templates /home/stack/tripleo-heat-templates \ -e /home/stack/tripleo-heat-templates/environments/puppet-pacemaker.yaml -e /home/stack/tripleo-heat-templates/environments/network-isolation.yaml \ -e /home/stack/tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml \ -e $HOME/network_env.yaml \ --control-scale 3 --compute-scale 1 constantly crashes Back porting patch https://review.openstack.org/#/c/380665/ via rebuilding puppet-tripleo-5.2.0-0.20160930180021.d6bbf78.el7.centos.src.rpm and re-installing corresponding new rpm just changed exit code from 6 to 9 (rpm re-installed before building overcloud images) far ahead deployment overcloud, which I believe is calling patched puppets. However deployment like :- #!/bin/bash -x source /home/stack/stackrc openstack overcloud deploy \ --libvirt-type qemu \ --ntp-server pool.ntp.org \ --templates /home/stack/tripleo-heat-templates \ -e /home/stack/tripleo-heat-templates/environments/network-isolation.yaml \ -e /home/stack/tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml \ -e $HOME/network_env.yaml \ --control-scale 1 --compute-scale 2 works fine. Thanks. Boris. ________________________________ From: rdo-list-bounces at redhat.com on behalf of hguemar at fedoraproject.org Sent: Monday, October 3, 2016 6:00:03 PM To: rdo-list at redhat.com Subject: [rdo-list] [Fedocal] Reminder meeting : RDO meeting Dear all, You are kindly invited to the meeting: RDO meeting on 2016-10-05 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/ _______________________________________________ rdo-list mailing list rdo-list at redhat.com https://www.redhat.com/mailman/listinfo/rdo-list rdo-list Info Page - Red Hat www.redhat.com The rdo-list mailing list provides a forum for discussions about installing, running, and using OpenStack on Red Hat based distributions. To see the collection of ... To unsubscribe: rdo-list-unsubscribe at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bderzhavets at hotmail.com Mon Oct 3 17:53:44 2016 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Mon, 3 Oct 2016 17:53:44 +0000 Subject: [rdo-list] Does TripleO Release ( Newton ) coming up (10/06/16) with overcloud HA broken ? In-Reply-To: References: <20161003150003.3DDE760A3FDC@fedocal02.phx2.fedoraproject.org>, Message-ID: Sorry for typo ( all required backward slashes "\" are present to continue the raw ) #!/bin/bash -x source /home/stack/stackrc openstack overcloud deploy \ --libvirt-type qemu \ --ntp-server pool.ntp.org \ --templates /home/stack/tripleo-heat-templates \ -e /home/stack/tripleo-heat-templates/environments/puppet-pacemaker.yaml \ -e /home/stack/tripleo-heat-templates/environments/network-isolation.yaml \ -e /home/stack/tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml \ -e $HOME/network_env.yaml \ --control-scale 3 --compute-scale 1 ________________________________ From: rdo-list-bounces at redhat.com on behalf of Boris Derzhavets Sent: Monday, October 3, 2016 8:46 PM To: hguemar at fedoraproject.org; rdo-list at redhat.com Subject: [rdo-list] Does TripleO Release ( Newton ) coming up (10/06/16) with overcloud HA broken ? Following schema of http://www.anstack.com/blog/2016/07/04/manually-installing-tripleo-recipe.html slightly modified for network isolation http://dbaxps.blogspot.ru/2016/09/tripleo-deployment-of-master-branch-via_27.html Attempt of deploy #!/bin/bash -x source /home/stack/stackrc openstack overcloud deploy \ --libvirt-type qemu \ --ntp-server pool.ntp.org \ --templates /home/stack/tripleo-heat-templates \ -e /home/stack/tripleo-heat-templates/environments/puppet-pacemaker.yaml -e /home/stack/tripleo-heat-templates/environments/network-isolation.yaml \ -e /home/stack/tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml \ -e $HOME/network_env.yaml \ --control-scale 3 --compute-scale 1 constantly crashes Back porting patch https://review.openstack.org/#/c/380665/ via rebuilding puppet-tripleo-5.2.0-0.20160930180021.d6bbf78.el7.centos.src.rpm and re-installing corresponding new rpm just changed exit code from 6 to 9 (rpm re-installed before building overcloud images) far ahead deployment overcloud, which I believe is calling patched puppets. However deployment like :- #!/bin/bash -x source /home/stack/stackrc openstack overcloud deploy \ --libvirt-type qemu \ --ntp-server pool.ntp.org \ --templates /home/stack/tripleo-heat-templates \ -e /home/stack/tripleo-heat-templates/environments/network-isolation.yaml \ -e /home/stack/tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml \ -e $HOME/network_env.yaml \ --control-scale 1 --compute-scale 2 works fine. Thanks. Boris. ________________________________ From: rdo-list-bounces at redhat.com on behalf of hguemar at fedoraproject.org Sent: Monday, October 3, 2016 6:00:03 PM To: rdo-list at redhat.com Subject: [rdo-list] [Fedocal] Reminder meeting : RDO meeting Dear all, You are kindly invited to the meeting: RDO meeting on 2016-10-05 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/ _______________________________________________ rdo-list mailing list rdo-list at redhat.com https://www.redhat.com/mailman/listinfo/rdo-list rdo-list Info Page - Red Hat www.redhat.com The rdo-list mailing list provides a forum for discussions about installing, running, and using OpenStack on Red Hat based distributions. To see the collection of ... To unsubscribe: rdo-list-unsubscribe at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbowen at redhat.com Mon Oct 3 18:32:34 2016 From: rbowen at redhat.com (Rich Bowen) Date: Mon, 3 Oct 2016 14:32:34 -0400 Subject: [rdo-list] 28 unanswered 'RDO' questions on ask.openstack.org Message-ID: <9d080824-3ddb-edaa-6584-b8400f45a23b@redhat.com> 28 unanswered questions: is there a safe method of installing identity v3 properly with Liberty or Mitaka? https://ask.openstack.org/en/question/97137/is-there-a-safe-method-of-installing-identity-v3-properly-with-liberty-or-mitaka/ Tags: identity, liberty, mitaka, rdo Murano Requirements https://ask.openstack.org/en/question/96986/murano-requirements/ Tags: murano can not ping internet when launch instance cirros on mitaka https://ask.openstack.org/en/question/96949/can-not-ping-internet-when-launch-instance-cirros-on-mitaka/ Tags: cirros, security-groups, mitaka, mitaka-neutron After adding multiple compute nodes using packstack unable to see the nodes in dashboard https://ask.openstack.org/en/question/96732/after-adding-multiple-compute-nodes-using-packstack-unable-to-see-the-nodes-in-dashboard/ Tags: rdo [trove] mongodb cluster-grow failed https://ask.openstack.org/en/question/96571/trove-mongodb-cluster-grow-failed/ Tags: trove, mongodb, cluster, grow quota show is different from horizon in RDO after update quota with command https://ask.openstack.org/en/question/96244/quota-show-is-different-from-horizon-in-rdo-after-update-quota-with-command/ Tags: rdo "Parameter outiface failed on Firewall" during installation of openstack rdo on centos 7 https://ask.openstack.org/en/question/95657/parameter-outiface-failed-on-firewall-during-installation-of-openstack-rdo-on-centos-7/ Tags: rdo, devstack#mitaka multi nodes provider network ovs config https://ask.openstack.org/en/question/95423/multi-nodes-provider-network-ovs-config/ Tags: rdo, liberty-neutron Adding additional packages to an RDO installation https://ask.openstack.org/en/question/95380/adding-additional-packages-to-an-rdo-installation/ Tags: rdo, mistral RDO TripleO Mitaka HA Overcloud Failing https://ask.openstack.org/en/question/95249/rdo-tripleo-mitaka-ha-overcloud-failing/ Tags: mitaka, tripleo, overcloud, centos7 RDO - is there any fedora package newer than puppet-4.2.1-3.fc24.noarch.rpm https://ask.openstack.org/en/question/94969/rdo-is-there-any-fedora-package-newer-than-puppet-421-3fc24noarchrpm/ Tags: rdo, puppet, install-openstack OpenStack RDO mysqld 100% cpu https://ask.openstack.org/en/question/94961/openstack-rdo-mysqld-100-cpu/ Tags: openstack, mysqld, cpu Failed to set RDO repo on host-packstack-centOS-7 https://ask.openstack.org/en/question/94828/failed-to-set-rdo-repo-on-host-packstack-centos-7/ Tags: openstack-packstack, centos7, rdo how to deploy haskell-distributed in RDO? https://ask.openstack.org/en/question/94785/how-to-deploy-haskell-distributed-in-rdo/ Tags: rdo rdo tripleO liberty undercloud install failing https://ask.openstack.org/en/question/94023/rdo-tripleo-liberty-undercloud-install-failing/ Tags: rdo, rdo-manager, liberty, undercloud, instack Liberty RDO: stack resource topology icons are pink https://ask.openstack.org/en/question/91347/liberty-rdo-stack-resource-topology-icons-are-pink/ Tags: resource, topology, dashboard, horizon, pink No handlers could be found for logger "oslo_config.cfg" while syncing the glance database https://ask.openstack.org/en/question/91169/no-handlers-could-be-found-for-logger-oslo_configcfg-while-syncing-the-glance-database/ Tags: liberty, glance, install-openstack CentOS OpenStack - compute node can't talk https://ask.openstack.org/en/question/88989/centos-openstack-compute-node-cant-talk/ Tags: rdo How to setup SWIFT_PROXY_NODE and SWIFT_STORAGE_NODEs separately on RDO Liberty ? https://ask.openstack.org/en/question/88897/how-to-setup-swift_proxy_node-and-swift_storage_nodes-separately-on-rdo-liberty/ Tags: rdo, liberty, swift, ha VM and container can't download anything from internet https://ask.openstack.org/en/question/88338/vm-and-container-cant-download-anything-from-internet/ Tags: rdo, neutron, network, connectivity Fedora22, Liberty, horizon VNC console and keymap=sv with ; and/ https://ask.openstack.org/en/question/87451/fedora22-liberty-horizon-vnc-console-and-keymapsv-with-and/ Tags: keyboard, map, keymap, vncproxy, novnc OpenStack-Docker driver failed https://ask.openstack.org/en/question/87243/openstack-docker-driver-failed/ Tags: docker, openstack, liberty Routing between two tenants https://ask.openstack.org/en/question/84645/routing-between-two-tenants/ Tags: kilo, fuel, rdo, routing openstack baremetal introspection internal server error https://ask.openstack.org/en/question/82790/openstack-baremetal-introspection-internal-server-error/ Tags: rdo, ironic-inspector, tripleo Installing openstack using packstack (rdo) failed https://ask.openstack.org/en/question/82473/installing-openstack-using-packstack-rdo-failed/ Tags: rdo, packstack, installation-error, keystone VMware Host Backend causes No valid host was found. Bug ??? https://ask.openstack.org/en/question/79738/vmware-host-backend-causes-no-valid-host-was-found-bug/ Tags: vmware, rdo Mutlinode Devstack with two interfaces https://ask.openstack.org/en/question/78615/mutlinode-devstack-with-two-interfaces/ Tags: devstack, vlan, openstack Overcloud deployment on VM fails as IP address from DHCP is not assigned https://ask.openstack.org/en/question/66272/overcloud-deployment-on-vm-fails-as-ip-address-from-dhcp-is-not-assigned/ Tags: overcloud_in_vm -- Rich Bowen - rbowen at redhat.com RDO Community Liaison http://rdoproject.org @RDOCommunity From rbowen at redhat.com Mon Oct 3 20:24:51 2016 From: rbowen at redhat.com (Rich Bowen) Date: Mon, 3 Oct 2016 16:24:51 -0400 Subject: [rdo-list] RDO blogs, week of October 3 Message-ID: Here's what RDO enthusiasts are blogging about lately. Gnocchi 3.0 release by Julien Danjou After a few weeks of hard work with the team, here is the new major version of Gnocchi, stamped 3.0.0. It was very challenging, as we wanted to implement a few big changes in it. Read more at http://tm3.org/bf # of DB connections in OpenStack services by geguileo The other day someone asked me if the SQLAlchemy connections to the DB where per worker or shared among all workers, and what was the number of connections that should be expected from an OpenStack service. Maybe you have also wondered about this at some point, wonder no more, here?s a quick write up summarizing [?] Read more at http://tm3.org/bg Hyperthreading in the cloud by Tim Bell The cloud at CERN is used for a variety of different purposes from running personal VMs for development/test, bulk throughput computing to analyse the data from the Large Hadron Collider to long running services for the experiments and the organisation. Read more at http://tm3.org/bh OVS 2.6 and The First Release of OVN by russellbryant In January of 2015, the Open vSwitch team announced that they planned to start a new project within OVS called OVN (Open Virtual Network). The timing could not have been better for me as I was looking around for a new project. I dove in with a goal of figuring out whether OVN could be a promising next generation of Open vSwitch integration for OpenStack and have been contributing to it ever since. Read more at http://tm3.org/bi Deployment tips for puppet-tripleo changes by Carlos Camacho This post will describe different ways of debugging puppet-tripleo changes. Read more at http://tm3.org/bj Running Tempest on RDO OpenStack Newton by chandankumar Tempest is a set of integration tests to run against an OpenStack cluster. Read more at http://tm3.org/bk -- Rich Bowen - rbowen at redhat.com RDO Community Liaison http://rdoproject.org @RDOCommunity From whayutin at redhat.com Tue Oct 4 00:12:31 2016 From: whayutin at redhat.com (Wesley Hayutin) Date: Mon, 3 Oct 2016 20:12:31 -0400 Subject: [rdo-list] [CI] RDO CI for newton Message-ID: Greetings, FYI, just in case others bump into this. While pulling the centos7-newton delorean.repo file you'll notice the contents of the repo file point to just "centos7" and not "centos7-$release" Looks like the CI is building from the correct yum repo, the delorean file itself is not updated yet and makes it a little more confusing than it has to be atm. I suspect all is well and url in the delorean.repo file will be updated soon. Alan, Javier can you please confirm? Thanks whayutin?/tmp ? wget http://trunk.rdoproject.org/centos7-newton/68/06/68068090ee4e5dc31af126312ce8cbd8074f2545_5fe6110f/delorean.repo thinkdoe ? 20:06:12 --2016-10-03 20:06:14-- http://trunk.rdoproject.org/centos7-newton/68/06/68068090ee4e5dc31af126312ce8cbd8074f2545_5fe6110f/delorean.repo Resolving trunk.rdoproject.org (trunk.rdoproject.org)... 54.81.116.189 Connecting to trunk.rdoproject.org (trunk.rdoproject.org)|54.81.116.189|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 215 Saving to: ?delorean.repo? delorean.repo 100%[=====================================================================================================================>] 215 --.-KB/s in 0s 2016-10-03 20:06:14 (12.1 MB/s) - ?delorean.repo? saved [215/215] whayutin?/tmp ? cat delorean.repo thinkdoe ? 20:06:14 [delorean] name=delorean-openstack-ec2-api-68068090ee4e5dc31af126312ce8cbd8074f2545 baseurl= http://trunk.rdoproject.org/centos7/68/06/68068090ee4e5dc31af126312ce8cbd8074f2545_5fe6110f enabled=1 gpgcheck=0 priority=1% whayutin?/tmp ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From javier.pena at redhat.com Tue Oct 4 08:32:41 2016 From: javier.pena at redhat.com (Javier Pena) Date: Tue, 4 Oct 2016 04:32:41 -0400 (EDT) Subject: [rdo-list] [CI] RDO CI for newton In-Reply-To: References: Message-ID: <1515952102.288706.1475569961893.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Greetings, > FYI, just in case others bump into this. While pulling the centos7-newton > delorean.repo file you'll notice the contents of the repo file point to just > "centos7" and not "centos7-$release" > Looks like the CI is building from the correct yum repo, the delorean file > itself is not updated yet and makes it a little more confusing than it has > to be atm. > I suspect all is well and url in the delorean.repo file will be updated soon. > Alan, Javier can you please confirm? Hi Wes, Yes, this is expected because that repo was generated before switching the DLRN worker. Newer repos already include centos7-newton in the URL, see https://trunk.rdoproject.org/centos7-newton/consistent/delorean.repo Regards, Javier > Thanks > whayutin?/tmp ? wget > http://trunk.rdoproject.org/centos7-newton/68/06/68068090ee4e5dc31af126312ce8cbd8074f2545_5fe6110f/delorean.repo > thinkdoe ? 20:06:12 > --2016-10-03 20:06:14-- > http://trunk.rdoproject.org/centos7-newton/68/06/68068090ee4e5dc31af126312ce8cbd8074f2545_5fe6110f/delorean.repo > Resolving trunk.rdoproject.org ( trunk.rdoproject.org )... 54.81.116.189 > Connecting to trunk.rdoproject.org ( trunk.rdoproject.org > )|54.81.116.189|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 215 > Saving to: ?delorean.repo? > delorean.repo > 100%[=====================================================================================================================>] > 215 --.-KB/s in 0s > 2016-10-03 20:06:14 (12.1 MB/s) - ?delorean.repo? saved [215/215] > whayutin?/tmp ? cat delorean.repo thinkdoe ? 20:06:14 > [delorean] > name=delorean-openstack-ec2-api-68068090ee4e5dc31af126312ce8cbd8074f2545 > baseurl= > http://trunk.rdoproject.org/centos7/68/06/68068090ee4e5dc31af126312ce8cbd8074f2545_5fe6110f > enabled=1 > gpgcheck=0 > priority=1% whayutin?/tmp ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From cems at ebi.ac.uk Tue Oct 4 10:02:01 2016 From: cems at ebi.ac.uk (Charles Short) Date: Tue, 4 Oct 2016 11:02:01 +0100 Subject: [rdo-list] UEFI support Mitaka Message-ID: <4b960f59-8e34-fc14-378b-2169d8183ca8@ebi.ac.uk> Hi, I am using TripleO to deploy Stable Mitaka on HP BL460c Gen9 blades. I set my config up for grub2 (not Elilo) UEFI iPXE mode as per - http://docs.openstack.org/project-install-guide/baremetal/draft/setup-drivers.html In UEFI mode I get a kernel panic on iPXE boot during introspection when I use the pre-built Mitaka CentOS images ( http://buildlogs.centos.org/centos/7/cloud/x86_64/tripleo_images/mitaka/delorean/) If I try building my own images with the latest CentOS cloud image I have the same problem. If I replace the kernel with the latest kernel from ELRepo then all works fine and I can introspect and create a working stack. This thread sort of explains the issue - http://forum.ipxe.org/showthread.php?tid=7813 So It looks like this issue is fixed in a kernel that does not yet ship with CentOS. Has anyone else been struggling with this? I am probably going to revert to HP legacy BIOS mode as I don't want to run my stack on a non standard setup. Thanks Charles -- Charles Short Cloud Engineer Virtualization and Cloud Team European Bioinformatics Institute (EMBL-EBI) Tel: +44 (0)1223 494205 From dtantsur at redhat.com Tue Oct 4 11:47:25 2016 From: dtantsur at redhat.com (Dmitry Tantsur) Date: Tue, 4 Oct 2016 13:47:25 +0200 Subject: [rdo-list] UEFI support Mitaka In-Reply-To: <4b960f59-8e34-fc14-378b-2169d8183ca8@ebi.ac.uk> References: <4b960f59-8e34-fc14-378b-2169d8183ca8@ebi.ac.uk> Message-ID: On 10/04/2016 12:02 PM, Charles Short wrote: > Hi, > > I am using TripleO to deploy Stable Mitaka on HP BL460c Gen9 blades. > > I set my config up for grub2 (not Elilo) UEFI iPXE mode as per - > > http://docs.openstack.org/project-install-guide/baremetal/draft/setup-drivers.html > > In UEFI mode I get a kernel panic on iPXE boot during introspection when I use > the pre-built Mitaka CentOS images ( > http://buildlogs.centos.org/centos/7/cloud/x86_64/tripleo_images/mitaka/delorean/) > If I try building my own images with the latest CentOS cloud image I have the > same problem. > > If I replace the kernel with the latest kernel from ELRepo then all works fine > and I can introspect and create a working stack. > > This thread sort of explains the issue - > > http://forum.ipxe.org/showthread.php?tid=7813 > > So It looks like this issue is fixed in a kernel that does not yet ship with > CentOS. > > Has anyone else been struggling with this? > > I am probably going to revert to HP legacy BIOS mode as I don't want to run my > stack on a non standard setup. > > Thanks > > Charles > Hi! Have you tried raising it to the kernel folks? I see that we need to backport http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=819ab9941c98f18b0f8c7ffb815e4f07186d2a5f From cems at ebi.ac.uk Tue Oct 4 13:32:28 2016 From: cems at ebi.ac.uk (Charles Short) Date: Tue, 4 Oct 2016 14:32:28 +0100 Subject: [rdo-list] UEFI support Mitaka In-Reply-To: References: <4b960f59-8e34-fc14-378b-2169d8183ca8@ebi.ac.uk> Message-ID: Hi, I just did and had a reply from RH - "I've checked as well with my senior kernel colleagues, and the patch you referred is going to be included in the next release of RHEL7.2.z and 7.3 kernels on platform" Many Thanks Charles On 04/10/2016 12:47, Dmitry Tantsur wrote: > Hi! > > Have you tried raising it to the kernel folks? I see that we need to > backport > http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=819ab9941c98f18b0f8c7ffb815e4f07186d2a5f -- Charles Short Cloud Engineer Virtualization and Cloud Team European Bioinformatics Institute (EMBL-EBI) Tel: +44 (0)1223 494205 From ignaziocassano at gmail.com Tue Oct 4 14:31:55 2016 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Tue, 4 Oct 2016 16:31:55 +0200 Subject: [rdo-list] UEFI support Mitaka In-Reply-To: References: <4b960f59-8e34-fc14-378b-2169d8183ca8@ebi.ac.uk> Message-ID: Hello, we have just installed red hat openstack on the same type HP blade and RH suggested to disable UEFI. Regards 2016-10-04 13:47 GMT+02:00 Dmitry Tantsur : > On 10/04/2016 12:02 PM, Charles Short wrote: > >> Hi, >> >> I am using TripleO to deploy Stable Mitaka on HP BL460c Gen9 blades. >> >> I set my config up for grub2 (not Elilo) UEFI iPXE mode as per - >> >> http://docs.openstack.org/project-install-guide/baremetal/ >> draft/setup-drivers.html >> >> In UEFI mode I get a kernel panic on iPXE boot during introspection when >> I use >> the pre-built Mitaka CentOS images ( >> http://buildlogs.centos.org/centos/7/cloud/x86_64/tripleo_im >> ages/mitaka/delorean/) >> If I try building my own images with the latest CentOS cloud image I have >> the >> same problem. >> >> If I replace the kernel with the latest kernel from ELRepo then all works >> fine >> and I can introspect and create a working stack. >> >> This thread sort of explains the issue - >> >> http://forum.ipxe.org/showthread.php?tid=7813 >> >> So It looks like this issue is fixed in a kernel that does not yet ship >> with >> CentOS. >> >> Has anyone else been struggling with this? >> >> I am probably going to revert to HP legacy BIOS mode as I don't want to >> run my >> stack on a non standard setup. >> >> Thanks >> >> Charles >> >> > Hi! > > Have you tried raising it to the kernel folks? I see that we need to > backport http://git.kernel.org/cgit/linux/kernel/git/stable/linux-sta > ble.git/commit/?id=819ab9941c98f18b0f8c7ffb815e4f07186d2a5f > > _______________________________________________ > rdo-list mailing list > rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From whayutin at redhat.com Tue Oct 4 14:33:31 2016 From: whayutin at redhat.com (Wesley Hayutin) Date: Tue, 4 Oct 2016 10:33:31 -0400 Subject: [rdo-list] rdo infra scrum recording Message-ID: Greetings, Here are the notes from the rdo infra weekly scrum. Highlights include nominations for new user advocates, pm, tech leads. Also a good discussion on our development process. Thanks.. https://review.rdoproject.org/etherpad/p/rdo-infra-scrum This week: https://bluejeans.com/s/70YMa/ Last week: https://bluejeans.com/s/pVmm6/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbowen at redhat.com Tue Oct 4 17:22:31 2016 From: rbowen at redhat.com (Rich Bowen) Date: Tue, 4 Oct 2016 13:22:31 -0400 Subject: [rdo-list] DRAFT Newton RDO release message Message-ID: Sorry this is coming kind of late. I have drafted our Newton release blog post at https://github.com/rbowen/rdo-website/blob/master/source/blog/2016-10-04-rdo-newton-released.html.md based on our Mitaka release message. I'd appreciate it if a few people can have a look over it and see what we need to change, what we need to emphasize, and so on. Thanks! --Rich -- Rich Bowen - rbowen at redhat.com RDO Community Liaison http://rdoproject.org @RDOCommunity From dms at redhat.com Tue Oct 4 17:44:15 2016 From: dms at redhat.com (David Moreau Simard) Date: Tue, 4 Oct 2016 13:44:15 -0400 Subject: [rdo-list] DRAFT Newton RDO release message In-Reply-To: References: Message-ID: Hi, I see ~2300 reviewers but almost ~2700 committers for Newton in Stackalytics. We could be generous and mention the close to 2700 contributors. Linking to the rdoinfo yaml file is pretty bad UX IMO. We should have something better somewhere. Even a list of packages straight out of yum would be better but it'd be great to highlight the big tent projects. We mention rdo-list, #centos but no #centos-devel or #rdo. David Moreau Simard Senior Software Engineer | Openstack RDO dmsimard = [irc, github, twitter] On Tue, Oct 4, 2016 at 1:22 PM, Rich Bowen wrote: > Sorry this is coming kind of late. I have drafted our Newton release > blog post at > https://github.com/rbowen/rdo-website/blob/master/source/blog/2016-10-04-rdo-newton-released.html.md > based on our Mitaka release message. I'd appreciate it if a few people > can have a look over it and see what we need to change, what we need to > emphasize, and so on. > > Thanks! > > --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 From dms at redhat.com Tue Oct 4 17:51:20 2016 From: dms at redhat.com (David Moreau Simard) Date: Tue, 4 Oct 2016 13:51:20 -0400 Subject: [rdo-list] DRAFT Newton RDO release message In-Reply-To: References: Message-ID: Here's the list of packages [1] out of our testing (release candidate at this time) repository. I count 1157 :) To reproduce: yum install https://rdoproject.org/repos/openstack-newton/rdo-release-newton.rpm yum --disablerepo="*" --enablerepo="openstack-newton-testing" list available [1]: https://paste.fedoraproject.org/443456/ David Moreau Simard Senior Software Engineer | Openstack RDO dmsimard = [irc, github, twitter] On Tue, Oct 4, 2016 at 1:44 PM, David Moreau Simard wrote: > Hi, > > I see ~2300 reviewers but almost ~2700 committers for Newton in Stackalytics. > We could be generous and mention the close to 2700 contributors. > > Linking to the rdoinfo yaml file is pretty bad UX IMO. We should have > something better somewhere. > Even a list of packages straight out of yum would be better but it'd > be great to highlight the big tent projects. > > We mention rdo-list, #centos but no #centos-devel or #rdo. > > David Moreau Simard > Senior Software Engineer | Openstack RDO > > dmsimard = [irc, github, twitter] > > > On Tue, Oct 4, 2016 at 1:22 PM, Rich Bowen wrote: >> Sorry this is coming kind of late. I have drafted our Newton release >> blog post at >> https://github.com/rbowen/rdo-website/blob/master/source/blog/2016-10-04-rdo-newton-released.html.md >> based on our Mitaka release message. I'd appreciate it if a few people >> can have a look over it and see what we need to change, what we need to >> emphasize, and so on. >> >> Thanks! >> >> --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 From rbowen at redhat.com Tue Oct 4 19:04:36 2016 From: rbowen at redhat.com (Rich Bowen) Date: Tue, 4 Oct 2016 15:04:36 -0400 Subject: [rdo-list] DRAFT Newton RDO release message In-Reply-To: References: Message-ID: <47bb581e-24db-f518-3ee4-4fb9f8c65090@redhat.com> Thanks. I've made several changes based on your remarks. https://github.com/rbowen/rdo-website/blob/master/source/blog/2016-10-04-rdo-newton-released.html.md On 10/04/2016 01:51 PM, David Moreau Simard wrote: > Here's the list of packages [1] out of our testing (release candidate > at this time) repository. > > I count 1157 :) > > To reproduce: > yum install https://rdoproject.org/repos/openstack-newton/rdo-release-newton.rpm > yum --disablerepo="*" --enablerepo="openstack-newton-testing" list available > > [1]: https://paste.fedoraproject.org/443456/ > > David Moreau Simard > Senior Software Engineer | Openstack RDO > > dmsimard = [irc, github, twitter] > > > On Tue, Oct 4, 2016 at 1:44 PM, David Moreau Simard wrote: >> Hi, >> >> I see ~2300 reviewers but almost ~2700 committers for Newton in Stackalytics. >> We could be generous and mention the close to 2700 contributors. >> >> Linking to the rdoinfo yaml file is pretty bad UX IMO. We should have >> something better somewhere. >> Even a list of packages straight out of yum would be better but it'd >> be great to highlight the big tent projects. >> >> We mention rdo-list, #centos but no #centos-devel or #rdo. >> >> David Moreau Simard >> Senior Software Engineer | Openstack RDO >> >> dmsimard = [irc, github, twitter] >> >> >> On Tue, Oct 4, 2016 at 1:22 PM, Rich Bowen wrote: >>> Sorry this is coming kind of late. I have drafted our Newton release >>> blog post at >>> https://github.com/rbowen/rdo-website/blob/master/source/blog/2016-10-04-rdo-newton-released.html.md >>> based on our Mitaka release message. I'd appreciate it if a few people >>> can have a look over it and see what we need to change, what we need to >>> emphasize, and so on. >>> >>> Thanks! >>> >>> --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 -- Rich Bowen - rbowen at redhat.com RDO Community Liaison http://rdoproject.org @RDOCommunity From rbowen at redhat.com Tue Oct 4 20:29:35 2016 From: rbowen at redhat.com (Rich Bowen) Date: Tue, 4 Oct 2016 16:29:35 -0400 Subject: [rdo-list] OpenStack Day Natal (Brazil) Message-ID: If you're considering attending OpenStack Day Natal, Brazil, please let me know. It doesn't appear that they have a website yet, but it's scheduled for 19th November 2016 in the Praiamar Hotel & Convention Center, Natal, Brazil --Rich -- Rich Bowen - rbowen at redhat.com RDO Community Liaison http://rdoproject.org @RDOCommunity From rbowen at redhat.com Tue Oct 4 20:47:02 2016 From: rbowen at redhat.com (Rich Bowen) Date: Tue, 4 Oct 2016 16:47:02 -0400 Subject: [rdo-list] Reminder: test day this week (Sept 29, 30) In-Reply-To: References: <5d4bb0a3-83c4-222b-a745-824fef6d4d19@redhat.com> <7cd7d16e-39ef-5a5c-49cc-47505ee6f6ad@redhat.com> Message-ID: On 09/28/2016 03:14 AM, Luca 'remix_tj' Lorenzetto wrote: > On Tue, Sep 27, 2016 at 10:29 PM, Rich Bowen wrote: >> On 09/27/2016 04:21 PM, Luca 'remix_tj' Lorenzetto wrote: >>> >>> Hi, >>> >>> This could be interesting for our team. Is there any existing test plan? >>> We have a cluster were we are now experimenting mitaka tripleo >>> deployment and is redeployed daily (more or less) for testing. >>> >>> We could also test building images based on rhel 7 and testing. >> >> >> There's a test plan, of sorts, at the URL above - >> https://www.rdoproject.org/testday/newton/testedsetups_rc/ - However, we >> really need help making that test plan both more comprehensive, and more >> accessible - that is, make it so that beginners can come help test, as >> well as experts. > > The link reported for the howto is returning 404 > (https://www.rdoproject.org/testday/newton/milestone_rc#how-to-test) > > Which is the right one? I'm terribly sorry, I did not see this note until now. I've belatedly fixed the link, and will be more careful testing for the next test day. > > >> >> We would love to hear from you on rdo-list about scenarios that you'd >> like to see tested, as well as scenarios you are already testing. > > We're mainly working on deployment with TripleO. Could be interesting for tests? > I see only packstack related tests... Yes, we would very much like to see the test matrix expanded to include TripleO tests for the release test day. -- Rich Bowen - rbowen at redhat.com RDO Community Liaison http://rdoproject.org @RDOCommunity From cbrown2 at ocf.co.uk Tue Oct 4 20:54:18 2016 From: cbrown2 at ocf.co.uk (Christopher Brown) Date: Tue, 4 Oct 2016 21:54:18 +0100 Subject: [rdo-list] DRAFT Newton RDO release message In-Reply-To: References: Message-ID: <1475614458.4435.102.camel@ocf.co.uk> Hello, This release is packed full of things I've been really keen to put into production so congratulations to all involved and look forward to meeting some of you in Barcelona in a few weeks. In terms of wording, I'd prefer to see something like: For a production deployment of RDO, head over to tripleo.org What is the difference between RDO Quickstart and TripleO Quickstart for example? On Tue, 2016-10-04 at 18:22 +0100, Rich Bowen wrote: > Sorry this is coming kind of late. I have drafted our Newton release > blog post at > https://github.com/rbowen/rdo-website/blob/master/source/blog/2016-10 > -04-rdo-newton-released.html.md > based on our Mitaka release message. I'd appreciate it if a few > people > can have a look over it and see what we need to change, what we need > to > emphasize, and so on. > > Thanks! > > --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 -- Regards, Christopher Brown OpenStack Engineer OCF plc Tel: +44 (0)114 257 2200 Web: www.ocf.co.uk Blog: blog.ocf.co.uk Twitter: @ocfplc Please note, any emails relating to an OCF Support request must always be sent to support at ocf.co.uk for a ticket number to be generated or existing support ticket to be updated. Should this not be done then OCF cannot be held responsible for requests not dealt with in a timely manner. OCF plc is a company registered in England and Wales. Registered number 4132533, VAT number GB 780 6803 14. Registered office address: OCF plc, 5 Rotunda Business Centre, Thorncliffe Park, Chapeltown, Sheffield S35 2PG. This message is private and confidential. If you have received this message in error, please notify us immediately and remove it from your system. From bderzhavets at hotmail.com Tue Oct 4 21:58:53 2016 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Tue, 4 Oct 2016 21:58:53 +0000 Subject: [rdo-list] Reminder: test day this week (Sept 29, 30) RDO Newton instak-virt-setup on VIRTHOST In-Reply-To: References: <5d4bb0a3-83c4-222b-a745-824fef6d4d19@redhat.com> <7cd7d16e-39ef-5a5c-49cc-47505ee6f6ad@redhat.com> , Message-ID: ________________________________ From: rdo-list-bounces at redhat.com on behalf of Rich Bowen Sent: Tuesday, October 4, 2016 11:47 PM To: Luca 'remix_tj' Lorenzetto; rdo-list Subject: Re: [rdo-list] Reminder: test day this week (Sept 29, 30) On 09/28/2016 03:14 AM, Luca 'remix_tj' Lorenzetto wrote: > On Tue, Sep 27, 2016 at 10:29 PM, Rich Bowen wrote: >> On 09/27/2016 04:21 PM, Luca 'remix_tj' Lorenzetto wrote: >>> >>> Hi, >>> >>> This could be interesting for our team. Is there any existing test plan? >>> We have a cluster were we are now experimenting mitaka tripleo >>> deployment and is redeployed daily (more or less) for testing. >>> >>> We could also test building images based on rhel 7 and testing. >> >> >> There's a test plan, of sorts, at the URL above - >> https://www.rdoproject.org/testday/newton/testedsetups_rc/ - However, we >> really need help making that test plan both more comprehensive, and more >> accessible - that is, make it so that beginners can come help test, as >> well as experts. > > The link reported for the howto is returning 404 > (https://www.rdoproject.org/testday/newton/milestone_rc#how-to-test) > > Which is the right one? I'm terribly sorry, I did not see this note until now. I've belatedly fixed the link, and will be more careful testing for the next test day. > > >> >> We would love to hear from you on rdo-list about scenarios that you'd >> like to see tested, as well as scenarios you are already testing. > > We're mainly working on deployment with TripleO. Could be interesting for tests? > I see only packstack related tests... Yes, we would very much like to see the test matrix expanded to include TripleO tests for the release test day. I am not sure is it correct approach or no as well is it interesting or no :- http://dbaxps.blogspot.ru/2016/10/rdo-newton-rc2-instack-virt-setup-on.html [https://4.bp.blogspot.com/-uZdQpMz_ue8/V_POhxQfkNI/AAAAAAAAHKU/XYO76ew2ZoY1upwB0Q7Pz_r0Wf7r3G-HACLcB/w1200-h630-p-nu/Screenshot%2Bfrom%2B2016-10-04%2B18-44-07.png] Attempt of RDO Newton instack-virt-setup on CentOS 7.2 VIRTHOST dbaxps.blogspot.ru Following bellow is verification of status Newton DLRN consistent trunks for TripleO undercloud/overcloud deployment based on packages cu... Thanks Boris. -- Rich Bowen - rbowen at redhat.com RDO Community Liaison http://rdoproject.org RDO rdoproject.org RDO is a community of people using and deploying OpenStack on CentOS, Fedora, and Red Hat Enterprise Linux. Try RDO Now ? @RDOCommunity _______________________________________________ rdo-list mailing list rdo-list at redhat.com https://www.redhat.com/mailman/listinfo/rdo-list rdo-list Info Page - Red Hat www.redhat.com The rdo-list mailing list provides a forum for discussions about installing, running, and using OpenStack on Red Hat based distributions. To see the collection of ... To unsubscribe: rdo-list-unsubscribe at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From lorenzetto.luca at gmail.com Wed Oct 5 10:01:17 2016 From: lorenzetto.luca at gmail.com (Luca 'remix_tj' Lorenzetto) Date: Wed, 5 Oct 2016 12:01:17 +0200 Subject: [rdo-list] Reminder: test day this week (Sept 29, 30) In-Reply-To: References: <5d4bb0a3-83c4-222b-a745-824fef6d4d19@redhat.com> <7cd7d16e-39ef-5a5c-49cc-47505ee6f6ad@redhat.com> Message-ID: On Tue, Oct 4, 2016 at 10:47 PM, Rich Bowen wrote: [cut] > > Yes, we would very much like to see the test matrix expanded to include > TripleO tests for the release test day. We can test with this two kinds of setup: 1 controller, 2 compute with ML2 - OVS - VXLAN on RHEL 7 with LVM or with external CEPH 3 controller clustered, 2 compute with ML2 - OVS - VXLAN on RHEL 7 with LVM or with external CEPH If it is interesting for RDO, we can join next test days. Luca -- "E' assurdo impiegare gli uomini di intelligenza eccellente per fare calcoli che potrebbero essere affidati a chiunque se si usassero delle macchine" Gottfried Wilhelm von Leibnitz, Filosofo e Matematico (1646-1716) "Internet ? la pi? grande biblioteca del mondo. Ma il problema ? che i libri sono tutti sparsi sul pavimento" John Allen Paulos, Matematico (1945-vivente) Luca 'remix_tj' Lorenzetto, http://www.remixtj.net , From apevec at redhat.com Wed Oct 5 10:48:13 2016 From: apevec at redhat.com (Alan Pevec) Date: Wed, 5 Oct 2016 12:48:13 +0200 Subject: [rdo-list] Reminder: test day this week (Sept 29, 30) RDO Newton instak-virt-setup on VIRTHOST In-Reply-To: References: <5d4bb0a3-83c4-222b-a745-824fef6d4d19@redhat.com> <7cd7d16e-39ef-5a5c-49cc-47505ee6f6ad@redhat.com> Message-ID: > I am not sure is it correct approach or no as well is it interesting or no :- > http://dbaxps.blogspot.ru/2016/10/rdo-newton-rc2-instack-virt-setup-on.html > Attempt of RDO Newton instack-virt-setup on CentOS 7.2 VIRTHOST > dbaxps.blogspot.ru Thanks for writing this up! The only thing I'd change is to advertise current-passed-ci vs consistent since the latter might not be passing CI. CDN mirror of passed-CI repo is also now included in rdo-release-newton RPM, so repository setup instructions could be: # yum install https://www.rdoproject.org/repos/openstack-newton/rdo-release-newton.rpm # yum-config-manager --enable rdo-trunk-newton-tested Cheers, Alan From ihrachys at redhat.com Wed Oct 5 12:05:12 2016 From: ihrachys at redhat.com (Ihar Hrachyshka) Date: Wed, 5 Oct 2016 14:05:12 +0200 Subject: [rdo-list] No maintainer for networking-arista Message-ID: <35F56E4F-0198-4CEA-8445-4CD54C7688BB@redhat.com> Hi all, current maintainers for the package (me and Miguel) want to step down. Unless someone replaces us, or give us a reason to keep maintaining the package, we may need to drop it from RDO. Anyone interested in keeping it available? Ihar From rbowen at redhat.com Wed Oct 5 13:11:27 2016 From: rbowen at redhat.com (Rich Bowen) Date: Wed, 5 Oct 2016 09:11:27 -0400 Subject: [rdo-list] DRAFT Newton RDO release message In-Reply-To: <1475614458.4435.102.camel@ocf.co.uk> References: <1475614458.4435.102.camel@ocf.co.uk> Message-ID: <78b5451c-62a8-195d-075d-61a0dd439879@redhat.com> On 10/04/2016 04:54 PM, Christopher Brown wrote: > Hello, > > This release is packed full of things I've been really keen to put into > production so congratulations to all involved and look forward to > meeting some of you in Barcelona in a few weeks. > > In terms of wording, I'd prefer to see something like: > > For a production deployment of RDO, head over to tripleo.org The idea with the tripleo quickstart was to make it less intimidating to non-experts than http://tripleo.org/ While thorough, the process on tripleo.org is really quite overwhelming. > > What is the difference between RDO Quickstart and TripleO Quickstart > for example? The RDO quickstart is packstack, and the TripleO quickstart is TripleO. > > On Tue, 2016-10-04 at 18:22 +0100, Rich Bowen wrote: >> Sorry this is coming kind of late. I have drafted our Newton release >> blog post at >> https://github.com/rbowen/rdo-website/blob/master/source/blog/2016-10 >> -04-rdo-newton-released.html.md >> based on our Mitaka release message. I'd appreciate it if a few >> people >> can have a look over it and see what we need to change, what we need >> to >> emphasize, and so on. >> >> Thanks! >> >> --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 > -- > Regards, > > Christopher Brown > OpenStack Engineer > OCF plc > > Tel: +44 (0)114 257 2200 > Web: www.ocf.co.uk > Blog: blog.ocf.co.uk > Twitter: @ocfplc > > Please note, any emails relating to an OCF Support request must always > be sent to support at ocf.co.uk for a ticket number to be generated or > existing support ticket to be updated. Should this not be done then OCF > cannot be held responsible for requests not dealt with in a timely > manner. > > OCF plc is a company registered in England and Wales. Registered number > 4132533, VAT number GB 780 6803 14. Registered office address: OCF plc, > 5 Rotunda Business Centre, Thorncliffe Park, Chapeltown, Sheffield S35 > 2PG. > > This message is private and confidential. If you have received this > message in error, please notify us immediately and remove it from your > system. > -- Rich Bowen - rbowen at redhat.com RDO Community Liaison http://rdoproject.org @RDOCommunity From rbowen at redhat.com Wed Oct 5 14:05:12 2016 From: rbowen at redhat.com (Rich Bowen) Date: Wed, 5 Oct 2016 10:05:12 -0400 Subject: [rdo-list] RDO Newton GA Test Day - October 13, 14 Message-ID: Please join us for the final test day of the Newton cycle. Full details of the test day are at https://www.rdoproject.org/testday/newton/final/ We will be testing on October 13th and 14th. Come to #rdo on the Freenode IRC network for help and discussion. Based on discussion on the list, I've moved the test scenarios document entirely to an etherpad, to make it easier to add test scenarios, as well as easier for people to add their test day notes. Please have a look at the test scenario etherpad prior to test day, and ensure that desired scenarios are listed, and that instructions are there for testers to follow - https://etherpad.openstack.org/p/rdo-newton-ga-testday-testplan -- Rich Bowen - rbowen at redhat.com RDO Community Liaison http://rdoproject.org @RDOCommunity From pkovar at redhat.com Wed Oct 5 15:15:13 2016 From: pkovar at redhat.com (Petr Kovar) Date: Wed, 5 Oct 2016 17:15:13 +0200 Subject: [rdo-list] DRAFT Newton RDO release message In-Reply-To: <78b5451c-62a8-195d-075d-61a0dd439879@redhat.com> References: <1475614458.4435.102.camel@ocf.co.uk> <78b5451c-62a8-195d-075d-61a0dd439879@redhat.com> Message-ID: <20161005171513.b27a50ecab99ffad9524b296@redhat.com> On Wed, 5 Oct 2016 09:11:27 -0400 Rich Bowen wrote: > > > On 10/04/2016 04:54 PM, Christopher Brown wrote: > > Hello, > > > > This release is packed full of things I've been really keen to put into > > production so congratulations to all involved and look forward to > > meeting some of you in Barcelona in a few weeks. > > > > In terms of wording, I'd prefer to see something like: > > > > For a production deployment of RDO, head over to tripleo.org > > The idea with the tripleo quickstart was to make it less intimidating to > non-experts than http://tripleo.org/ While thorough, the process on > tripleo.org is really quite overwhelming. > > > > > What is the difference between RDO Quickstart and TripleO Quickstart > > for example? > > The RDO quickstart is packstack, and the TripleO quickstart is TripleO. Thanks for working on this, Rich. I'd be inclined to refer to RDO Quickstart as the Packstack or All-in-one Quickstart (which is what the front page currently says). As for IRC channels, I'd also mention the tripleo channel. I'll create a PR. pk From rbowen at redhat.com Wed Oct 5 16:03:32 2016 From: rbowen at redhat.com (Rich Bowen) Date: Wed, 5 Oct 2016 12:03:32 -0400 Subject: [rdo-list] DRAFT Newton RDO release message In-Reply-To: References: Message-ID: On 10/04/2016 01:22 PM, Rich Bowen wrote: > Sorry this is coming kind of late. I have drafted our Newton release > blog post at > https://github.com/rbowen/rdo-website/blob/master/source/blog/2016-10-04-rdo-newton-released.html.md > based on our Mitaka release message. I'd appreciate it if a few people > can have a look over it and see what we need to change, what we need to > emphasize, and so on. I will be out Thursday, Friday, and Monday. https://github.com/redhat-openstack/website/blob/master/source/blog/2016-10-04-rdo-newton-released.html.md is the draft blog post about the Newton release. It's already pushed up, but it's not published. Assuming we get a release out Thursday or Friday, can someone change the 'false' to 'true' on that and push it out so that it hits Planet OpenStack? Thanks. --Rich -- Rich Bowen - rbowen at redhat.com RDO Community Liaison http://rdoproject.org @RDOCommunity From javier.pena at redhat.com Wed Oct 5 16:43:42 2016 From: javier.pena at redhat.com (Javier Pena) Date: Wed, 5 Oct 2016 12:43:42 -0400 (EDT) Subject: [rdo-list] [Meeting] RDO meeting (2016-10-05) Minutes In-Reply-To: <458833386.790433.1475685792451.JavaMail.zimbra@redhat.com> Message-ID: <1068654667.790453.1475685822709.JavaMail.zimbra@redhat.com> ============================== #rdo: RDO meeting - 2016-10-05 ============================== Meeting started by jpena at 15:00:53 UTC. The full logs are available at https://meetbot.fedoraproject.org/rdo/2016-10-05/rdo_meeting_-_2016-10-05.2016-10-05-15.00.log.html . Meeting summary --------------- * roll call (jpena, 15:01:27) * DLRN Ocata branch (jpena, 15:04:27) * LINK: http://logs.openstack.org/51/382351/2/check/gate-puppet-openstack-integration-4-scenario001-tempest-centos-7/94511dd/logs/rpm-qa.txt.gz (EmilienM, 15:07:23) * LINK: https://github.com/openstack/instack-undercloud/commits/stable/newton (trown, 15:25:37) * ACTION: trown submit test patch to tripleo-ci to test ocata repo (trown, 15:38:43) * ACTION: jpena to move centos-master to ocata worker as soon as tripleo-ci and puppet ci jobs are ok (jpena, 15:39:03) * Preparation for CentOS outage October 10th (jpena, 15:41:41) * no new packages built by DLRN during the CentOS outage (jpena, 15:46:15) * Preparation for RCIP-DEV move October 17th (jpena, 15:49:14) * GA rebuilds tomorrow (jpena, 15:50:34) * LINK: https://git.openstack.org/cgit/openstack/puppet-heat/commit/?h=9.4.1&id=7c2489b23cc6fbaaff8c486a7fd139afccd9d1b4 is in there (trown, 15:53:03) * ACTION: apevec to make sure puppet 9.4.1 are in newton-testing (apevec, 15:54:15) * Newton GA test day Oct 13/14 - https://www.rdoproject.org/testday/newton/final/ (jpena, 15:57:52) * Announcements (jpena, 15:59:56) * chair for next meeting (jpena, 16:00:55) * ACTION: jruzicka to chair next meeting (jpena, 16:01:54) Meeting ended at 16:02:13 UTC. Action Items ------------ * trown submit test patch to tripleo-ci to test ocata repo * jpena to move centos-master to ocata worker as soon as tripleo-ci and puppet ci jobs are ok * apevec to make sure puppet 9.4.1 are in newton-testing * jruzicka to chair next meeting Action Items, by person ----------------------- * apevec * apevec to make sure puppet 9.4.1 are in newton-testing * jpena * jpena to move centos-master to ocata worker as soon as tripleo-ci and puppet ci jobs are ok * jruzicka * jruzicka to chair next meeting * trown * trown submit test patch to tripleo-ci to test ocata repo * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * apevec (62) * jpena (62) * EmilienM (51) * dmsimard (46) * trown (44) * ihrachys (18) * rbowen (14) * rdogerrit (10) * zodbot (9) * jruzicka (6) * jschlueter (6) * weshay (5) * flepied (3) * openstack (3) * amoralej (3) * Duck (3) * coolsvap (2) * number80 (2) * tosky (1) * rdobot (1) * imcsk8 (1) * mburned (1) * f0o (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot From ihrachys at redhat.com Thu Oct 6 07:17:59 2016 From: ihrachys at redhat.com (Ihar Hrachyshka) Date: Thu, 6 Oct 2016 09:17:59 +0200 Subject: [rdo-list] No maintainer for networking-arista In-Reply-To: References: <35F56E4F-0198-4CEA-8445-4CD54C7688BB@redhat.com> Message-ID: <955C1D48-439E-4189-A7AB-18E798D96180@redhat.com> Hi Sukhdev, I think designating another interested maintainer for the package that would take it over and help solve RDO folks any integration issues with the package will be enough. Ihar Sukhdev Kapur wrote: > Hey Ihar, > We obviously would not want networking-arista be dropped from RDO. What > do you suggest we do to ensure this package does not get dropped? > > Regards > Sukhdev > > >> On Oct 5, 2016, at 5:05 AM, Ihar Hrachyshka wrote: >> >> Hi all, >> >> current maintainers for the package (me and Miguel) want to step down. >> Unless someone replaces us, or give us a reason to keep maintaining the >> package, we may need to drop it from RDO. >> >> Anyone interested in keeping it available? >> Ihar From dtantsur at redhat.com Thu Oct 6 11:03:03 2016 From: dtantsur at redhat.com (Dmitry Tantsur) Date: Thu, 6 Oct 2016 13:03:03 +0200 Subject: [rdo-list] RDO Newton GA Test Day - October 13, 14 In-Reply-To: References: Message-ID: On 10/05/2016 04:05 PM, Rich Bowen wrote: > Please join us for the final test day of the Newton cycle. > > Full details of the test day are at > https://www.rdoproject.org/testday/newton/final/ > > We will be testing on October 13th and 14th. Come to #rdo on the > Freenode IRC network for help and discussion. > > Based on discussion on the list, I've moved the test scenarios document > entirely to an etherpad, to make it easier to add test scenarios, as > well as easier for people to add their test day notes. > > Please have a look at the test scenario etherpad prior to test day, and > ensure that desired scenarios are listed, and that instructions are > there for testers to follow - > https://etherpad.openstack.org/p/rdo-newton-ga-testday-testplan > > May I shamelessly ask folks to give Ironic support in TripleO overcloud a try? This is a new thing in Newton, and I know that a lot of people were excited about it. Here is the rough walk-through for testing it: http://tripleo.org/advanced_deployment/baremetal_overcloud.html Thanks! From dms at redhat.com Thu Oct 6 22:05:41 2016 From: dms at redhat.com (David Moreau Simard) Date: Thu, 6 Oct 2016 18:05:41 -0400 Subject: [rdo-list] Third party DLRN CI and the need for a "-head" builder Message-ID: Hi, So with the help of Paul Belanger, we've identified the issue that prevented the "openstack-check-verified" pipeline from working. The Zuul openstack-check-verified pipeline [1] from review.rdoproject.org can be used to trigger builds on upstream projects on each patchset, only when Jenkins has +1'd it. The goal with this pipeline is to do third party CI with DLRN in order to try and build projects' patches to warn us for failure to build errors ahead of time, even before the change merges. We're not planning on voting on the Gerrit changes, it's solely to check if there are any issues building the project with that particular patch. So we really have two Ocata DLRN instances now, one that is pinned to upper-constraints [2] and one that builds the "master of everything" [3]. I was thinking... If we're able to do third party CI against upstream with DLRN do we need that "head" instance ? The "head" instance exists, as far as I know, to let us know if anything from unpinned projects fails to build. The third party CI will let us know that -- and even before, ahead of time, before the change causing the failure even merges. Thoughts ? [1]: https://review.rdoproject.org/r/gitweb?p=config.git;a=blob;f=zuul/upstream.yaml;h=f4cad72201cf602a06d16ec2d84c23d0dadbae18;hb=HEAD#l22 [2]: https://trunk.rdoproject.org/centos7-master/ [3]: https://trunk.rdoproject.org/centos7-master-head/ David Moreau Simard Senior Software Engineer | Openstack RDO dmsimard = [irc, github, twitter] From apevec at redhat.com Thu Oct 6 22:55:00 2016 From: apevec at redhat.com (Alan Pevec) Date: Fri, 7 Oct 2016 00:55:00 +0200 Subject: [rdo-list] DRAFT Newton RDO release message In-Reply-To: References: Message-ID: > https://github.com/redhat-openstack/website/blob/master/source/blog/2016-10-04-rdo-newton-released.html.md > is the draft blog post about the Newton release. It's already pushed up, > but it's not published. Assuming we get a release out Thursday or > Friday, can someone change the 'false' to 'true' on that and push it out > so that it hits Planet OpenStack? Published - do you also have email formatted text ready or should I just copy md source from this blog? Alan From apevec at redhat.com Fri Oct 7 00:30:48 2016 From: apevec at redhat.com (Alan Pevec) Date: Fri, 7 Oct 2016 02:30:48 +0200 Subject: [rdo-list] DRAFT Newton RDO release message In-Reply-To: References: Message-ID: > Published - do you also have email formatted text ready or should I > just copy md source from this blog? Could not find it so I've converted the email text at https://etherpad.openstack.org/p/newton-rdo-release I'm about to post it here and openstack{-dev} lists. Alan From apevec at redhat.com Fri Oct 7 00:38:28 2016 From: apevec at redhat.com (Alan Pevec) Date: Fri, 7 Oct 2016 02:38:28 +0200 Subject: [rdo-list] [release] RDO Newton packages released Message-ID: The RDO community is pleased to announce the general availability of the RDO build for OpenStack Newton for RPM-based distributions - CentOS Linux 7 and Red Hat Enterprise Linux. RDO is suitable for building private, public, and hybrid clouds. Newton is the 14th release from the OpenStack project ( http://openstack.org ), which is the work of more than 2700 contributors from around the world. (Source http://stackalytics.com/ ) The RDO community project ( https://www.rdoproject.org/ ) 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 ( https://wiki.centos.org/SpecialInterestGroup/Cloud ). 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. At latest count, RDO contains 1157 packages ( https://www.rdoproject.org/documentation/package-list/ ). All work on RDO, and on the downstream release, Red Hat OpenStack Platform, is 100% open source, with all code changes going upstream first. 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 the RDO QuickStart ( http://rdoproject.org/Quickstart ) You can run RDO on a single node to get a feel for how it works. For a production deployment of RDO, use the TripleO Quickstart ( https://www.rdoproject.org/tripleo/ ) and you'll be running a production cloud in short order. Finally, if you want to try out OpenStack, but don't have the time or hardware to run it yourself, visit TryStack ( http://trystack.org/ ), 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 Getting Help The RDO Project participates in a Q&A service at ask.openstack.org ( http://ask.openstack.org ), for more developer oriented content we recommend joining the rdo-list mailing list ( https://www.redhat.com/mailman/listinfo/rdo-list ). Remember to post a brief introduction about yourself and your RDO story. You can also find extensive documentation on the RDO docs site ( https://www.rdoproject.org/documentation ). 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 ( https://lists.centos.org/ ) and the CentOS IRC Channels (#centos, and #centos-devel, 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 ( https://www.rdoproject.org/community/ ) and the CentOS Cloud SIG page ( https://wiki.centos.org/SpecialInterestGroup/Cloud ). See also the RDO packaging documentation ( https://www.rdoproject.org/packaging/ ). Join us in #rdo on the Freenode IRC network, and follow us at @RDOCommunity ( http://twitter.com/rdocommunity ) on Twitter. If you prefer Facebook, we're there too ( http://facebook.com/rdocommunity ), and also Google+ ( http://tm3.org/rdogplus ). And, if you're going to be in Barcelona for the OpenStack Summit ( http://openstack.org/summit/ ) two weeks from now, join us on Tuesday evening at the Barcelona Princess, 5pm - 8pm, for an evening with the RDO and Ceph communities. If you can't make it in person, we'll be streaming it on YouTube ( https://www.youtube.com/watch?v=ji-WqEXZRTY ). Cheers, Alan From pabelanger at redhat.com Fri Oct 7 00:39:32 2016 From: pabelanger at redhat.com (Paul Belanger) Date: Thu, 6 Oct 2016 20:39:32 -0400 Subject: [rdo-list] Third party DLRN CI and the need for a "-head" builder In-Reply-To: References: Message-ID: <20161007003932.GA19337@localhost.localdomain> On Thu, Oct 06, 2016 at 06:05:41PM -0400, David Moreau Simard wrote: > Hi, > > So with the help of Paul Belanger, we've identified the issue that > prevented the "openstack-check-verified" pipeline from working. > Happy to help get this working! I expect it to add some great value for RDO. Here is an example of an upstream patch that passed check, but failed to build downstream[4]. [4] https://www.redhat.com/archives/rdo-infra-list/2016-October/msg00029.html > The Zuul openstack-check-verified pipeline [1] from > review.rdoproject.org can be used to trigger builds on upstream > projects on each patchset, only when Jenkins has +1'd it. > The goal with this pipeline is to do third party CI with DLRN in order > to try and build projects' patches to warn us for failure to build > errors ahead of time, even before the change merges. > > We're not planning on voting on the Gerrit changes, it's solely to > check if there are any issues building the project with that > particular patch. > > So we really have two Ocata DLRN instances now, one that is pinned to > upper-constraints [2] and one that builds the "master of everything" > [3]. > I was thinking... If we're able to do third party CI against upstream > with DLRN do we need that "head" instance ? > > The "head" instance exists, as far as I know, to let us know if > anything from unpinned projects fails to build. > The third party CI will let us know that -- and even before, ahead of > time, before the change causing the failure even merges. > > Thoughts ? > > [1]: https://review.rdoproject.org/r/gitweb?p=config.git;a=blob;f=zuul/upstream.yaml;h=f4cad72201cf602a06d16ec2d84c23d0dadbae18;hb=HEAD#l22 > [2]: https://trunk.rdoproject.org/centos7-master/ > [3]: https://trunk.rdoproject.org/centos7-master-head/ > > 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 bderzhavets at hotmail.com Fri Oct 7 06:38:04 2016 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Fri, 7 Oct 2016 06:38:04 +0000 Subject: [rdo-list] RDO Newton GA Test Day - October 13, 14 In-Reply-To: References: , Message-ID: ________________________________ From: rdo-list-bounces at redhat.com on behalf of Dmitry Tantsur Sent: Thursday, October 6, 2016 2:03 PM To: rdo-list at redhat.com Subject: Re: [rdo-list] RDO Newton GA Test Day - October 13, 14 On 10/05/2016 04:05 PM, Rich Bowen wrote: > Please join us for the final test day of the Newton cycle. > > Full details of the test day are at > https://www.rdoproject.org/testday/newton/final/ > > We will be testing on October 13th and 14th. Come to #rdo on the > Freenode IRC network for help and discussion. > > Based on discussion on the list, I've moved the test scenarios document > entirely to an etherpad, to make it easier to add test scenarios, as > well as easier for people to add their test day notes. > > Please have a look at the test scenario etherpad prior to test day, and > ensure that desired scenarios are listed, and that instructions are > there for testers to follow - > https://etherpad.openstack.org/p/rdo-newton-ga-testday-testplan > > May I shamelessly ask folks to give Ironic support in TripleO overcloud a try? This is a new thing in Newton, and I know that a lot of people were excited about it. Here is the rough walk-through for testing it: http://tripleo.org/advanced_deployment/baremetal_overcloud.html Could you provide a sample of ironic-config.yaml, which is ready to go , then it would not be a problem to make a test via instack-virt-setup install based on "centos7-newton/current-passed-ci" trunk. Thanks. Boris Thanks! _______________________________________________ rdo-list mailing list rdo-list at redhat.com https://www.redhat.com/mailman/listinfo/rdo-list rdo-list Info Page - Red Hat www.redhat.com The rdo-list mailing list provides a forum for discussions about installing, running, and using OpenStack on Red Hat based distributions. To see the collection of ... To unsubscribe: rdo-list-unsubscribe at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From javier.pena at redhat.com Fri Oct 7 07:29:50 2016 From: javier.pena at redhat.com (Javier Pena) Date: Fri, 7 Oct 2016 03:29:50 -0400 (EDT) Subject: [rdo-list] Third party DLRN CI and the need for a "-head" builder In-Reply-To: References: Message-ID: <315305089.1302835.1475825390550.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hi, > > So with the help of Paul Belanger, we've identified the issue that > prevented the "openstack-check-verified" pipeline from working. > > The Zuul openstack-check-verified pipeline [1] from > review.rdoproject.org can be used to trigger builds on upstream > projects on each patchset, only when Jenkins has +1'd it. > The goal with this pipeline is to do third party CI with DLRN in order > to try and build projects' patches to warn us for failure to build > errors ahead of time, even before the change merges. > > We're not planning on voting on the Gerrit changes, it's solely to > check if there are any issues building the project with that > particular patch. > > So we really have two Ocata DLRN instances now, one that is pinned to > upper-constraints [2] and one that builds the "master of everything" > [3]. > I was thinking... If we're able to do third party CI against upstream > with DLRN do we need that "head" instance ? > > The "head" instance exists, as far as I know, to let us know if > anything from unpinned projects fails to build. > The third party CI will let us know that -- and even before, ahead of > time, before the change causing the failure even merges. > I think we still need the "head" instance, even if it's only used to provide a repo for the third party CI to use when building. One example: the current python-openstackclient in head fails to build due to a funny interaction with os-client-config [1][2]. This os-client-config version is not yet in u-c, so if we used the u-c repo to gate, we would never see it in our gate. We might reduce the build frequency to once a day or so, but we still need that instance. Javier [1] https://bugs.launchpad.net/python-openstackclient/+bug/1630694 [2] https://trunk.rdoproject.org/centos7-master-head/ea/7f/ea7f28fb4acd39345bb95809a952e03ed802a9ff_32c5a2ce/rpmbuild.log > Thoughts ? > > [1]: > https://review.rdoproject.org/r/gitweb?p=config.git;a=blob;f=zuul/upstream.yaml;h=f4cad72201cf602a06d16ec2d84c23d0dadbae18;hb=HEAD#l22 > [2]: https://trunk.rdoproject.org/centos7-master/ > [3]: https://trunk.rdoproject.org/centos7-master-head/ > > David Moreau Simard > Senior Software Engineer | Openstack RDO > > dmsimard = [irc, github, twitter] > From me at gbraad.nl Fri Oct 7 08:12:29 2016 From: me at gbraad.nl (Gerard Braad) Date: Fri, 7 Oct 2016 16:12:29 +0800 Subject: [rdo-list] RDO Newton GA Test Day - October 13, 14 In-Reply-To: References: Message-ID: On Fri, Oct 7, 2016 at 2:38 PM, Boris Derzhavets wrote: > May I shamelessly ask folks to give Ironic support in TripleO overcloud a > try? > http://tripleo.org/advanced_deployment/baremetal_overcloud.html > Sure thing. This was on my todo-list for the coming days... -------------- next part -------------- An HTML attachment was scrubbed... URL: From dtantsur at redhat.com Fri Oct 7 10:51:47 2016 From: dtantsur at redhat.com (Dmitry Tantsur) Date: Fri, 7 Oct 2016 12:51:47 +0200 Subject: [rdo-list] RDO Newton GA Test Day - October 13, 14 In-Reply-To: References: Message-ID: <15263666-076c-6b15-6de5-59a5bfe52a47@redhat.com> On 10/07/2016 08:38 AM, Boris Derzhavets wrote: > > > > -------------------------------------------------------------------------------- > *From:* rdo-list-bounces at redhat.com on behalf of > Dmitry Tantsur > *Sent:* Thursday, October 6, 2016 2:03 PM > *To:* rdo-list at redhat.com > *Subject:* Re: [rdo-list] RDO Newton GA Test Day - October 13, 14 > > On 10/05/2016 04:05 PM, Rich Bowen wrote: >> Please join us for the final test day of the Newton cycle. >> >> Full details of the test day are at >> https://www.rdoproject.org/testday/newton/final/ >> >> We will be testing on October 13th and 14th. Come to #rdo on the >> Freenode IRC network for help and discussion. >> >> Based on discussion on the list, I've moved the test scenarios document >> entirely to an etherpad, to make it easier to add test scenarios, as >> well as easier for people to add their test day notes. >> >> Please have a look at the test scenario etherpad prior to test day, and >> ensure that desired scenarios are listed, and that instructions are >> there for testers to follow - >> https://etherpad.openstack.org/p/rdo-newton-ga-testday-testplan >> >> > > May I shamelessly ask folks to give Ironic support in TripleO overcloud a try? > This is a new thing in Newton, and I know that a lot of people were excited > about it. Here is the rough walk-through for testing it: > http://tripleo.org/advanced_deployment/baremetal_overcloud.html > > Could you provide a sample of ironic-config.yaml, which is ready to go , > then it would not be a problem to make a test via instack-virt-setup install > based on "centos7-newton/current-passed-ci" trunk. > > Thanks. > Boris > > Thanks! > This is what I used the last time: parameter_defaults: IronicEnabledDrivers: - pxe_ssh - pxe_ipmitool IronicCleaningDiskErase: 'metadata' ControllerExtraConfig: ironic::drivers::ssh::libvirt_uri: 'qemu:///session' NovaSchedulerDefaultFilters: - RetryFilter - AggregateInstanceExtraSpecsFilter - AvailabilityZoneFilter - RamFilter - DiskFilter - ComputeFilter - ComputeCapabilitiesFilter - ImagePropertiesFilter ControllerCount: 3 ComputeCount: 1 OvercloudControlFlavor: control OvercloudComputeFlavor: compute NtpServer: 'pool.ntp.org' This does not include ironic::conductor::cleaning_network_uuid, which has to be set later. As you see, it assumes HA configuration, and using hybrid BM-VM. It can be used for both virtual and non-virtual environments. Also note that setting ironic::drivers::ssh::libvirt_uri is because I used tripleo-quickstart. Remove it for instack-virt-setup. Overall, I would recommend you start with an easier configuration: parameter_defaults: IronicEnabledDrivers: - pxe_ssh - pxe_ipmitool IronicCleaningDiskErase: 'metadata' ControllerCount: 1 ComputeCount: 0 OvercloudControlFlavor: control NtpServer: 'pool.ntp.org' From lorenzetto.luca at gmail.com Fri Oct 7 16:23:51 2016 From: lorenzetto.luca at gmail.com (Luca 'remix_tj' Lorenzetto) Date: Fri, 7 Oct 2016 18:23:51 +0200 Subject: [rdo-list] RDO Newton GA Test Day - October 13, 14 In-Reply-To: References: Message-ID: Il 6 ott 2016 1:05 PM, "Dmitry Tantsur" ha scritto: >> > > May I shamelessly ask folks to give Ironic support in TripleO overcloud a try? This is a new thing in Newton, and I know that a lot of people were excited about it. Here is the rough walk-through for testing it: http://tripleo.org/advanced_deployment/baremetal_overcloud.html > > Thanks! > Sure. My colleague has reserved a blade for months waiting for the availability of ironic in tripleo overcloud! -------------- next part -------------- An HTML attachment was scrubbed... URL: From bderzhavets at hotmail.com Fri Oct 7 16:30:40 2016 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Fri, 7 Oct 2016 16:30:40 +0000 Subject: [rdo-list] RDO Newton GA Test Day - October 13, 14 In-Reply-To: <15263666-076c-6b15-6de5-59a5bfe52a47@redhat.com> References: , <15263666-076c-6b15-6de5-59a5bfe52a47@redhat.com> Message-ID: The problem I am experiencing in meantime is that :- $ bash quickstart.sh -R newton --config ./cofig/general_config/any-choosen.yml $VIRTHOST doesn't generated on undercloud VM , in ~stack/ folder any script overcloud-deploy.sh Just providing advice referring tripleo.org doc's. Even $ bash quickstart.sh -R newton $VIRTHOST behaves same way. Thanks. Boris ________________________________ From: Dmitry Tantsur Sent: Friday, October 7, 2016 1:51 PM To: Boris Derzhavets; rdo-list at redhat.com Subject: Re: [rdo-list] RDO Newton GA Test Day - October 13, 14 On 10/07/2016 08:38 AM, Boris Derzhavets wrote: > > > > -------------------------------------------------------------------------------- > *From:* rdo-list-bounces at redhat.com on behalf of > Dmitry Tantsur > *Sent:* Thursday, October 6, 2016 2:03 PM > *To:* rdo-list at redhat.com > *Subject:* Re: [rdo-list] RDO Newton GA Test Day - October 13, 14 > > On 10/05/2016 04:05 PM, Rich Bowen wrote: >> Please join us for the final test day of the Newton cycle. >> >> Full details of the test day are at >> https://www.rdoproject.org/testday/newton/final/ >> >> We will be testing on October 13th and 14th. Come to #rdo on the >> Freenode IRC network for help and discussion. >> >> Based on discussion on the list, I've moved the test scenarios document >> entirely to an etherpad, to make it easier to add test scenarios, as >> well as easier for people to add their test day notes. >> >> Please have a look at the test scenario etherpad prior to test day, and >> ensure that desired scenarios are listed, and that instructions are >> there for testers to follow - >> https://etherpad.openstack.org/p/rdo-newton-ga-testday-testplan >> >> > > May I shamelessly ask folks to give Ironic support in TripleO overcloud a try? > This is a new thing in Newton, and I know that a lot of people were excited > about it. Here is the rough walk-through for testing it: > http://tripleo.org/advanced_deployment/baremetal_overcloud.html Bare Metal Instances in Overcloud - tripleo-docs 0.0.1 ... tripleo.org Bare Metal Instances in Overcloud? This documentation explains installing Ironic for providing bare metal instances in the overcloud to end users. > > Could you provide a sample of ironic-config.yaml, which is ready to go , > then it would not be a problem to make a test via instack-virt-setup install > based on "centos7-newton/current-passed-ci" trunk. > > Thanks. > Boris > > Thanks! > This is what I used the last time: parameter_defaults: IronicEnabledDrivers: - pxe_ssh - pxe_ipmitool IronicCleaningDiskErase: 'metadata' ControllerExtraConfig: ironic::drivers::ssh::libvirt_uri: 'qemu:///session' NovaSchedulerDefaultFilters: - RetryFilter - AggregateInstanceExtraSpecsFilter - AvailabilityZoneFilter - RamFilter - DiskFilter - ComputeFilter - ComputeCapabilitiesFilter - ImagePropertiesFilter ControllerCount: 3 ComputeCount: 1 OvercloudControlFlavor: control OvercloudComputeFlavor: compute NtpServer: 'pool.ntp.org' This does not include ironic::conductor::cleaning_network_uuid, which has to be set later. As you see, it assumes HA configuration, and using hybrid BM-VM. It can be used for both virtual and non-virtual environments. Also note that setting ironic::drivers::ssh::libvirt_uri is because I used tripleo-quickstart. Remove it for instack-virt-setup. Overall, I would recommend you start with an easier configuration: parameter_defaults: IronicEnabledDrivers: - pxe_ssh - pxe_ipmitool IronicCleaningDiskErase: 'metadata' ControllerCount: 1 ComputeCount: 0 OvercloudControlFlavor: control NtpServer: 'pool.ntp.org' -------------- next part -------------- An HTML attachment was scrubbed... URL: From jslagle at redhat.com Fri Oct 7 20:00:33 2016 From: jslagle at redhat.com (James Slagle) Date: Fri, 7 Oct 2016 16:00:33 -0400 Subject: [rdo-list] Maintaining os-*-config in Fedora In-Reply-To: References: <20160921164218.GD31467@localhost.localdomain> Message-ID: <20161007200033.GB17487@localhost.localdomain> On Wed, Sep 21, 2016 at 07:00:36PM +0200, Ha?kel wrote: > 2016-09-21 18:42 GMT+02:00 James Slagle : > > os-*-config (apply, cloud, collect, refresh, net) are still maintained in > > Fedora (despite that the maintainers, myself included, have not been doing > > regular builds). > > > > I've been asked by a couple people from Fedora to update these packages to > > build python 3 packages, and some other things like removing outdated Requires > > on python libraries that are now in the stdlib (argparse, etc). > > > > This raised the question for me though if we still want to maintain these > > packages in Fedora at all. Aiui, they were not retired when the rest of the > > core OpenStack packages were retired because os-*-config is useful when using > > Fedora as an instance orchestarted via Heat on OpenStack. > > > > However, we haven't been properly maintaining these packages in Fedora by doing > > updated builds to pick up new releases, not to mention that these packages and > > use case are entirely untested on Fedora to the best of my knowledge. > > > > os-cloud-config I think we can retire from Fedora without any concern since it > > is specific to TripleO. > > > > For the others, is there anyone who wants to take them over to continue to work > > on the "Fedora as an instance orchestrated via Heat" use case? If not, I > > propose to retire the others as well. > > > > Note that diskimage-builder and dib-utls are also still in Fedora but it > > appears that pabelanger has been keeping those updated, so is likely using > > them. > > > > Well as a matter of fact, we can just sync them like we do with clients. > If they're useful to orchestrate Fedora instances with Heat, then I'd > rather keep them around. I did end up talking with Steve Baker about this and he indicated that he'd like to see them still be maintained in Fedora. So, I removed the outdated Requires and did new builds for rawhide for the recently released Newton versions for os-*-config (except for os-cloud-config which is TripleO specific and now retired in Fedora). I made sure the spec file changes are in sync in RDO packaging as well. -- -- James Slagle -- From kdreyer at redhat.com Fri Oct 7 20:35:59 2016 From: kdreyer at redhat.com (Ken Dreyer) Date: Fri, 7 Oct 2016 14:35:59 -0600 Subject: [rdo-list] what is a %{milestone} RPM macro? Message-ID: Hi folks, I see some references to managing %{milestone} macros in rdopkg. What does that macro signify? - Ken From apevec at redhat.com Fri Oct 7 22:00:39 2016 From: apevec at redhat.com (Alan Pevec) Date: Sat, 8 Oct 2016 00:00:39 +0200 Subject: [rdo-list] Maintaining os-*-config in Fedora In-Reply-To: <20161007200033.GB17487@localhost.localdomain> References: <20160921164218.GD31467@localhost.localdomain> <20161007200033.GB17487@localhost.localdomain> Message-ID: > I did end up talking with Steve Baker about this and he indicated that he'd > like to see them still be maintained in Fedora. Thanks - maybe you could take Steve as your co-maintainer in Fedora pkgdb? That would be a way to fast track him as Fedora packager: https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#Become_a_co-maintainer Haikel, would you sponsor Steve? Cheers, Alan From apevec at redhat.com Fri Oct 7 22:02:23 2016 From: apevec at redhat.com (Alan Pevec) Date: Sat, 8 Oct 2016 00:02:23 +0200 Subject: [rdo-list] what is a %{milestone} RPM macro? In-Reply-To: References: Message-ID: > I see some references to managing %{milestone} macros in rdopkg. What > does that macro signify? Used for OpenStack milestone release builds e.g. https://github.com/rdo-packages/keystone-distgit/commit/5fd9a8a125372d3122860a19ba27b2e0375f5ddd From hguemar at fedoraproject.org Fri Oct 7 22:59:47 2016 From: hguemar at fedoraproject.org (=?UTF-8?Q?Ha=C3=AFkel?=) Date: Sat, 8 Oct 2016 00:59:47 +0200 Subject: [rdo-list] Maintaining os-*-config in Fedora In-Reply-To: References: <20160921164218.GD31467@localhost.localdomain> <20161007200033.GB17487@localhost.localdomain> Message-ID: 2016-10-08 0:00 GMT+02:00 Alan Pevec : >> I did end up talking with Steve Baker about this and he indicated that he'd >> like to see them still be maintained in Fedora. > > Thanks - maybe you could take Steve as your co-maintainer in Fedora pkgdb? > That would be a way to fast track him as Fedora packager: > https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#Become_a_co-maintainer > Haikel, would you sponsor Steve? > > Cheers, > Alan Sure, Steve qualifies to the co-maintainership process as upstream maintainer. I'll get to it tomorrow. Regards, H. From hguemar at fedoraproject.org Fri Oct 7 23:18:24 2016 From: hguemar at fedoraproject.org (=?UTF-8?Q?Ha=C3=AFkel?=) Date: Sat, 8 Oct 2016 01:18:24 +0200 Subject: [rdo-list] No maintainer for networking-arista In-Reply-To: <955C1D48-439E-4189-A7AB-18E798D96180@redhat.com> References: <35F56E4F-0198-4CEA-8445-4CD54C7688BB@redhat.com> <955C1D48-439E-4189-A7AB-18E798D96180@redhat.com> Message-ID: 2016-10-06 9:17 GMT+02:00 Ihar Hrachyshka : > Hi Sukhdev, > > I think designating another interested maintainer for the package that would > take it over and help solve RDO folks any integration issues with the > package will be enough. > > Ihar > > Sukhdev Kapur wrote: > >> Hey Ihar, >> We obviously would not want networking-arista be dropped from RDO. What do >> you suggest we do to ensure this package does not get dropped? >> >> Regards >> Sukhdev >> Hi Sukhdev, one requirement to remain in RDO is to have an active maintainer to update/fix issues in packages. We're also looking for upstream developpers to collaborate with us on the release management side. In networking-arista, some issues we had to deal with: - no stable/newton branches - no stable tarballs https://tarballs.openstack.org/networking-arista/ As a release wrangler, I can help maintainers to get things released in time, but if there's no releases, I have no clue on what to ship in our repositories. We're no network experts, we have no networking-arista specific CI jobs running, and we have a whole distro to maintain, so unless someone steps up to maintain it, best choice for us is to drop it rather than shipping half-broken packages. Off couse, we're looking forward working with upstream maintainers to ship OpenStack packages that reflects positively on both downstream/upstream. Regards, H. >> >> >>> On Oct 5, 2016, at 5:05 AM, Ihar Hrachyshka wrote: >>> >>> Hi all, >>> >>> current maintainers for the package (me and Miguel) want to step down. >>> Unless someone replaces us, or give us a reason to keep maintaining the >>> package, we may need to drop it from RDO. >>> >>> Anyone interested in keeping it available? >>> Ihar > > > > _______________________________________________ > 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 Sat Oct 8 22:03:33 2016 From: rbowen at redhat.com (Rich Bowen) Date: Sat, 8 Oct 2016 18:03:33 -0400 Subject: [rdo-list] RDO Newton GA Test Day - October 13, 14 In-Reply-To: <15263666-076c-6b15-6de5-59a5bfe52a47@redhat.com> References: <15263666-076c-6b15-6de5-59a5bfe52a47@redhat.com> Message-ID: It would be really helpful to have this somewhere less ephemeral than email, linked in the test day page. On Oct 7, 2016 06:52, "Dmitry Tantsur" wrote: > On 10/07/2016 08:38 AM, Boris Derzhavets wrote: > >> >> >> >> ------------------------------------------------------------ >> -------------------- >> *From:* rdo-list-bounces at redhat.com on >> behalf of >> Dmitry Tantsur >> *Sent:* Thursday, October 6, 2016 2:03 PM >> *To:* rdo-list at redhat.com >> *Subject:* Re: [rdo-list] RDO Newton GA Test Day - October 13, 14 >> >> On 10/05/2016 04:05 PM, Rich Bowen wrote: >> >>> Please join us for the final test day of the Newton cycle. >>> >>> Full details of the test day are at >>> https://www.rdoproject.org/testday/newton/final/ >>> >>> We will be testing on October 13th and 14th. Come to #rdo on the >>> Freenode IRC network for help and discussion. >>> >>> Based on discussion on the list, I've moved the test scenarios document >>> entirely to an etherpad, to make it easier to add test scenarios, as >>> well as easier for people to add their test day notes. >>> >>> Please have a look at the test scenario etherpad prior to test day, and >>> ensure that desired scenarios are listed, and that instructions are >>> there for testers to follow - >>> https://etherpad.openstack.org/p/rdo-newton-ga-testday-testplan >>> >>> >>> >> May I shamelessly ask folks to give Ironic support in TripleO overcloud a >> try? >> This is a new thing in Newton, and I know that a lot of people were >> excited >> about it. Here is the rough walk-through for testing it: >> http://tripleo.org/advanced_deployment/baremetal_overcloud.html >> >> Could you provide a sample of ironic-config.yaml, which is ready to go , >> then it would not be a problem to make a test via instack-virt-setup >> install >> based on "centos7-newton/current-passed-ci" trunk. >> >> Thanks. >> Boris >> >> Thanks! >> >> > This is what I used the last time: > > parameter_defaults: > IronicEnabledDrivers: > - pxe_ssh > - pxe_ipmitool > IronicCleaningDiskErase: 'metadata' > ControllerExtraConfig: > ironic::drivers::ssh::libvirt_uri: 'qemu:///session' > NovaSchedulerDefaultFilters: > - RetryFilter > - AggregateInstanceExtraSpecsFilter > - AvailabilityZoneFilter > - RamFilter > - DiskFilter > - ComputeFilter > - ComputeCapabilitiesFilter > - ImagePropertiesFilter > ControllerCount: 3 > ComputeCount: 1 > OvercloudControlFlavor: control > OvercloudComputeFlavor: compute > NtpServer: 'pool.ntp.org' > > > This does not include ironic::conductor::cleaning_network_uuid, which has > to be set later. As you see, it assumes HA configuration, and using hybrid > BM-VM. It can be used for both virtual and non-virtual environments. Also > note that setting ironic::drivers::ssh::libvirt_uri is because I used > tripleo-quickstart. Remove it for instack-virt-setup. > > Overall, I would recommend you start with an easier configuration: > > parameter_defaults: > IronicEnabledDrivers: > - pxe_ssh > - pxe_ipmitool > IronicCleaningDiskErase: 'metadata' > ControllerCount: 1 > ComputeCount: 0 > OvercloudControlFlavor: control > NtpServer: 'pool.ntp.org' > > _______________________________________________ > rdo-list mailing list > rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbaker at redhat.com Sun Oct 9 20:02:08 2016 From: sbaker at redhat.com (Steve Baker) Date: Mon, 10 Oct 2016 09:02:08 +1300 Subject: [rdo-list] Maintaining os-*-config in Fedora In-Reply-To: References: <20160921164218.GD31467@localhost.localdomain> <20161007200033.GB17487@localhost.localdomain> Message-ID: On 08/10/16 11:59, Ha?kel wrote: > 2016-10-08 0:00 GMT+02:00 Alan Pevec : >>> I did end up talking with Steve Baker about this and he indicated that he'd >>> like to see them still be maintained in Fedora. >> Thanks - maybe you could take Steve as your co-maintainer in Fedora pkgdb? >> That would be a way to fast track him as Fedora packager: >> https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#Become_a_co-maintainer >> Haikel, would you sponsor Steve? >> >> Cheers, >> Alan > Sure, Steve qualifies to the co-maintainership process as upstream > maintainer. I'll get to it tomorrow. > > Regards, > H. Thanks Ha?kel, my fedora account name is stevebake. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dtantsur at redhat.com Mon Oct 10 09:17:12 2016 From: dtantsur at redhat.com (Dmitry Tantsur) Date: Mon, 10 Oct 2016 11:17:12 +0200 Subject: [rdo-list] RDO Newton GA Test Day - October 13, 14 In-Reply-To: References: <15263666-076c-6b15-6de5-59a5bfe52a47@redhat.com> Message-ID: Sure, what's the best place to put it? On 10/09/2016 12:03 AM, Rich Bowen wrote: > It would be really helpful to have this somewhere less ephemeral than email, > linked in the test day page. > > > On Oct 7, 2016 06:52, "Dmitry Tantsur" > wrote: > > On 10/07/2016 08:38 AM, Boris Derzhavets wrote: > > > > > -------------------------------------------------------------------------------- > *From:* rdo-list-bounces at redhat.com > > on > behalf of > Dmitry Tantsur > > *Sent:* Thursday, October 6, 2016 2:03 PM > *To:* rdo-list at redhat.com > *Subject:* Re: [rdo-list] RDO Newton GA Test Day - October 13, 14 > > On 10/05/2016 04:05 PM, Rich Bowen wrote: > > Please join us for the final test day of the Newton cycle. > > Full details of the test day are at > https://www.rdoproject.org/testday/newton/final/ > > > We will be testing on October 13th and 14th. Come to #rdo on the > Freenode IRC network for help and discussion. > > Based on discussion on the list, I've moved the test scenarios document > entirely to an etherpad, to make it easier to add test scenarios, as > well as easier for people to add their test day notes. > > Please have a look at the test scenario etherpad prior to test day, and > ensure that desired scenarios are listed, and that instructions are > there for testers to follow - > https://etherpad.openstack.org/p/rdo-newton-ga-testday-testplan > > > > > May I shamelessly ask folks to give Ironic support in TripleO overcloud > a try? > This is a new thing in Newton, and I know that a lot of people were excited > about it. Here is the rough walk-through for testing it: > http://tripleo.org/advanced_deployment/baremetal_overcloud.html > > > Could you provide a sample of ironic-config.yaml, which is ready to go , > then it would not be a problem to make a test via instack-virt-setup install > based on "centos7-newton/current-passed-ci" trunk. > > Thanks. > Boris > > Thanks! > > > This is what I used the last time: > > parameter_defaults: > IronicEnabledDrivers: > - pxe_ssh > - pxe_ipmitool > IronicCleaningDiskErase: 'metadata' > ControllerExtraConfig: > ironic::drivers::ssh::libvirt_uri: 'qemu:///session' > NovaSchedulerDefaultFilters: > - RetryFilter > - AggregateInstanceExtraSpecsFilter > - AvailabilityZoneFilter > - RamFilter > - DiskFilter > - ComputeFilter > - ComputeCapabilitiesFilter > - ImagePropertiesFilter > ControllerCount: 3 > ComputeCount: 1 > OvercloudControlFlavor: control > OvercloudComputeFlavor: compute > NtpServer: 'pool.ntp.org ' > > > This does not include ironic::conductor::cleaning_network_uuid, which has to > be set later. As you see, it assumes HA configuration, and using hybrid > BM-VM. It can be used for both virtual and non-virtual environments. Also > note that setting ironic::drivers::ssh::libvirt_uri is because I used > tripleo-quickstart. Remove it for instack-virt-setup. > > Overall, I would recommend you start with an easier configuration: > > parameter_defaults: > IronicEnabledDrivers: > - pxe_ssh > - pxe_ipmitool > IronicCleaningDiskErase: 'metadata' > ControllerCount: 1 > ComputeCount: 0 > OvercloudControlFlavor: control > NtpServer: 'pool.ntp.org ' > > _______________________________________________ > rdo-list mailing list > rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > > To unsubscribe: rdo-list-unsubscribe at redhat.com > > From apevec at redhat.com Mon Oct 10 09:42:36 2016 From: apevec at redhat.com (Alan Pevec) Date: Mon, 10 Oct 2016 11:42:36 +0200 Subject: [rdo-list] RDO Newton GA Test Day - October 13, 14 In-Reply-To: References: <15263666-076c-6b15-6de5-59a5bfe52a47@redhat.com> Message-ID: > Sure, what's the best place to put it? In testcases etherpad linked from https://www.rdoproject.org/testday/newton/final/ Cheers, Alan From dtantsur at redhat.com Mon Oct 10 10:02:38 2016 From: dtantsur at redhat.com (Dmitry Tantsur) Date: Mon, 10 Oct 2016 12:02:38 +0200 Subject: [rdo-list] An Evening of Ceph and RDO, Tuesday, OpenStack Summit In-Reply-To: <4f17d7f6-3584-3a3d-eee6-8df6a0835c3f@redhat.com> References: <001a1144007a4f5b39053c8c5e52@google.com> <4f17d7f6-3584-3a3d-eee6-8df6a0835c3f@redhat.com> Message-ID: <6f14e3d0-dc3c-b15e-d4c7-b406a4c6b498@redhat.com> The invite does not look a great idea. It seems like everyone who puts it in their calendar becomes an organizer of their own event, and the calendar starts sending invites to all people mentioned in the invite. On 09/15/2016 05:53 PM, Rich Bowen wrote: > Here's the details on the evening gathering Tuesday night at OpenStack > Summit, and a handy invite so you can add it to your calendar. > > --Rich > > > > _______________________________________________ > rdo-list mailing list > rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com > From dtantsur at redhat.com Mon Oct 10 10:10:50 2016 From: dtantsur at redhat.com (Dmitry Tantsur) Date: Mon, 10 Oct 2016 12:10:50 +0200 Subject: [rdo-list] RDO Newton GA Test Day - October 13, 14 In-Reply-To: References: <15263666-076c-6b15-6de5-59a5bfe52a47@redhat.com> Message-ID: <2d62b872-c6ed-29f1-6f83-7fda5013d34d@redhat.com> Done, updated https://etherpad.openstack.org/p/rdo-newton-ga-testday-testplan and created https://etherpad.openstack.org/p/rdo-newton-ga-testday-ironic-overcloud. From lorenzetto.luca at gmail.com Mon Oct 10 10:17:14 2016 From: lorenzetto.luca at gmail.com (Luca 'remix_tj' Lorenzetto) Date: Mon, 10 Oct 2016 12:17:14 +0200 Subject: [rdo-list] RDO Newton GA Test Day - October 13, 14 In-Reply-To: References: <15263666-076c-6b15-6de5-59a5bfe52a47@redhat.com> Message-ID: On Mon, Oct 10, 2016 at 11:42 AM, Alan Pevec wrote: >> Sure, what's the best place to put it? > > In testcases etherpad linked from > https://www.rdoproject.org/testday/newton/final/ Hello, which is the difference between "TripleO" and "TripleO baremetal"? Does is simply because in the first case quickstart script is used, and in second one not? -- "E' assurdo impiegare gli uomini di intelligenza eccellente per fare calcoli che potrebbero essere affidati a chiunque se si usassero delle macchine" Gottfried Wilhelm von Leibnitz, Filosofo e Matematico (1646-1716) "Internet ? la pi? grande biblioteca del mondo. Ma il problema ? che i libri sono tutti sparsi sul pavimento" John Allen Paulos, Matematico (1945-vivente) Luca 'remix_tj' Lorenzetto, http://www.remixtj.net , From dba477 at list.ru Mon Oct 10 12:39:05 2016 From: dba477 at list.ru (=?UTF-8?B?Qm9yaXM=?=) Date: Mon, 10 Oct 2016 15:39:05 +0300 Subject: [rdo-list] =?utf-8?q?RDO_Newton_GA_Test_Day_-_October_13=2C_14_Tr?= =?utf-8?q?ipleO_VENV_Testing?= In-Reply-To: <2d62b872-c6ed-29f1-6f83-7fda5013d34d@redhat.com> References: <2d62b872-c6ed-29f1-6f83-7fda5013d34d@redhat.com> Message-ID: <1476103145.543072156@f411.i.mail.ru> Backup e-mail has been used due to local DNS issues with hotmail.com. Follow http://tripleo.org/advanced_deployment/baremetal_overcloud.html with? your sample parameter_defaults: ?????IronicEnabledDrivers: ?????????- pxe_ssh ?????????- pxe_ipmitool ?????IronicCleaningDiskErase: 'metadata' ?????ControllerCount: 1 ?????ComputeCount: 0 ?????OvercloudControlFlavor: control ?????NtpServer: 'pool.ntp.org' via instack-virt-setup with NODE_CPU=2 NODE_COUNT=2 NODE_MEMORY=80000 UNDERCLOUD_MEMORY=12000 on? 32 GB VIRTHOST 4 CORE i7 CPU (Haswell ) Every time get during overcloud deployment ================================================================================================= 2016-10-10 07:35:42Z [overcloud.Controller.0.Controller]: CREATE_FAILED? ResourceInError: resources.Controller: Went to status ERROR due to "Message: No valid host was found. There are not enough hosts available., Code: 500" ================================================================================================== Due to limited experience both cases tested 1. openstack baremetal introspection bulk start -? is skipped <== I guess has to be skipped. 2. openstack baremetal introspection bulk start - ? is done Before overcloud-deploy.sh run. Crashes with same error above. Repos setup (same on VIRTHOST and "instack VM") :- $ sudo yum -y install yum-plugin-priorities $ sudo curl -o /etc/yum.repos.d/delorean-newton.repo \ http://buildlogs.centos.org/centos/7/cloud/x86_64/rdo-trunk-newton-tested/delorean.repo? $ sudo curl -o /etc/yum.repos.d/delorean-deps-newton.repo \ https://trunk.rdoproject.org/centos7-newton/delorean-deps.repo? One other test has been completed OK . RDO Newton Overcloud HA deployment via instack-virt-setup on CentOS 7.2 VIRTHOST http://dbaxps.blogspot.com/2016/10/rdo-newton-overcloud-ha-deployment-via.html Thanks. Boris. Sorry, but current time frame is more suitable for myself. ???????????, 10 ??????? 2016, 13:10 +03:00 ?? Dmitry Tantsur : > >Done, updated https://etherpad.openstack.org/p/rdo-newton-ga-testday-testplan >and created https://etherpad.openstack.org/p/rdo-newton-ga-testday-ironic-overcloud . > >_______________________________________________ >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 ? ?????????, Boris Derzhavets dba477 at list.ru -------------- next part -------------- An HTML attachment was scrubbed... URL: From dtantsur at redhat.com Mon Oct 10 12:42:00 2016 From: dtantsur at redhat.com (Dmitry Tantsur) Date: Mon, 10 Oct 2016 14:42:00 +0200 Subject: [rdo-list] RDO Newton GA Test Day - October 13, 14 TripleO VENV Testing In-Reply-To: <1476103145.543072156@f411.i.mail.ru> References: <2d62b872-c6ed-29f1-6f83-7fda5013d34d@redhat.com> <1476103145.543072156@f411.i.mail.ru> Message-ID: <5d1ffae6-17c2-ddef-6066-afc0950b2c66@redhat.com> Sorry, I think you have to either remove "OvercloudControlFlavor: control" or tweak you flavors (the former is the easiest). https://etherpad.openstack.org/p/rdo-newton-ga-testday-ironic-overcloud has the updated samples. On 10/10/2016 02:39 PM, Boris wrote: > Backup e-mail has been used due to local DNS issues with hotmail.com. > > Follow http://tripleo.org/advanced_deployment/baremetal_overcloud.html > with your sample > > parameter_defaults: > IronicEnabledDrivers: > - pxe_ssh > - pxe_ipmitool > IronicCleaningDiskErase: 'metadata' > ControllerCount: 1 > ComputeCount: 0 > OvercloudControlFlavor: control > NtpServer: 'pool.ntp.org' > > via instack-virt-setup with > > NODE_CPU=2 > NODE_COUNT=2 > NODE_MEMORY=80000 > UNDERCLOUD_MEMORY=12000 > > on 32 GB VIRTHOST 4 CORE i7 CPU (Haswell ) > > Every time get during overcloud deployment > > ================================================================================================= > 2016-10-10 07:35:42Z [overcloud.Controller.0.Controller]: CREATE_FAILED > ResourceInError: resources.Controller: Went to status ERROR due to "Message: No > valid host was found. There are not enough hosts available., Code: 500" > ================================================================================================== > > Due to limited experience both cases tested > > 1. openstack baremetal introspection bulk start - is skipped <== I guess has to > be skipped. > 2. openstack baremetal introspection bulk start - is done > > Before overcloud-deploy.sh run. > > Crashes with same error above. > > Repos setup (same on VIRTHOST and "instack VM") :- > > $ sudo yum -y install yum-plugin-priorities > $ sudo curl -o /etc/yum.repos.d/delorean-newton.repo \ > http://buildlogs.centos.org/centos/7/cloud/x86_64/rdo-trunk-newton-tested/delorean.repo > $ sudo curl -o /etc/yum.repos.d/delorean-deps-newton.repo \ > https://trunk.rdoproject.org/centos7-newton/delorean-deps.repo > > One other test has been completed OK . > > RDO Newton Overcloud HA deployment via instack-virt-setup on CentOS 7.2 VIRTHOST > http://dbaxps.blogspot.com/2016/10/rdo-newton-overcloud-ha-deployment-via.html > > Thanks. > Boris. > Sorry, but current time frame is more suitable for myself. > > ???????????, 10 ??????? 2016, 13:10 +03:00 ?? Dmitry Tantsur : > > > Done, updated https://etherpad.openstack.org/p/rdo-newton-ga-testday-testplan > and created > https://etherpad.openstack.org/p/rdo-newton-ga-testday-ironic-overcloud. > > _______________________________________________ > 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 > > > > > ? ?????????, > Boris Derzhavets > dba477 at list.ru From hguemar at fedoraproject.org Mon Oct 10 15:00:03 2016 From: hguemar at fedoraproject.org (hguemar at fedoraproject.org) Date: Mon, 10 Oct 2016 15:00:03 +0000 (UTC) Subject: [rdo-list] [Fedocal] Reminder meeting : RDO meeting Message-ID: <20161010150003.EDB6960A3FDC@fedocal02.phx2.fedoraproject.org> Dear all, You are kindly invited to the meeting: RDO meeting on 2016-10-12 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 pradeepantil at gmail.com Tue Oct 11 04:14:35 2016 From: pradeepantil at gmail.com (Pradeep Antil) Date: Tue, 11 Oct 2016 09:44:35 +0530 Subject: [rdo-list] Error While Installing Openstack Newton using RDO packstack Message-ID: Hi Folks , I am trying to install 3 node openstack newton on CentOS 7 using packstack. But getting below error. In the answer file i have mentioned that packstack script will create selfsign certificate at the mentioned location. Preparing Nova VNC Proxy entries [ ERROR ] ERROR : [Errno 2] No such file or directory: '/etc/pki/tls/certs/selfcert.crt' ~]# tail -f /var/tmp/packstack/20161008-104443-u_wbaC/openstack-setup.log File "/usr/lib/python2.7/site-packages/packstack/modules/ospluginutils.py", line 101, in generate_ssl_cert ca_file = open(config['CONFIG_SSL_CACERT_FILE'], 'rt').read() IOError: [Errno 2] No such file or directory: '/etc/pki/tls/certs/selfcert.crt' 2016-10-08 10:56:33::INFO::shell::94::root:: [192.168.43.70] Executing script: rm -rf /var/tmp/packstack/8a47dc48454c40a0a8c7856728604812 2016-10-08 10:56:34::INFO::shell::94::root:: [192.168.43.80] Executing script: rm -rf /var/tmp/packstack/844988cf4be74a6cb5b95a22c7eab220 2016-10-08 10:56:34::INFO::shell::94::root:: [192.168.43.90] Executing script: rm -rf /var/tmp/packstack/d2e704b6b353457aac455dca91efc2d6 Any idea how to resolve this issue so that i can latest version of openstack. It also seems to be a bug in the script. -- Best Regards Pradeep Kumar -------------- next part -------------- An HTML attachment was scrubbed... URL: From cems at ebi.ac.uk Tue Oct 11 08:55:34 2016 From: cems at ebi.ac.uk (Charles Short) Date: Tue, 11 Oct 2016 09:55:34 +0100 Subject: [rdo-list] Newton HA galera-ready dependency error Message-ID: Hi, I am installing Newton with TripleO on baremetal HP blades. I can deploy a single controller stack overcloud no problem, however when I choose three controllers the deployment fails (including /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml) . The heat stack error first complains "Dependency Exec[galera-ready] has failures" which in turn causes lots of other errors. I have deployed Liberty and Mitaka successfully in the past on baremetal with three controllers, and this is the first time I have seen this error. Charles -- Charles Short Cloud Engineer Virtualization and Cloud Team European Bioinformatics Institute (EMBL-EBI) Tel: +44 (0)1223 494205 From cems at ebi.ac.uk Tue Oct 11 09:16:04 2016 From: cems at ebi.ac.uk (Charles Short) Date: Tue, 11 Oct 2016 10:16:04 +0100 Subject: [rdo-list] Newton HA galera-ready dependency error In-Reply-To: References: Message-ID: <16532098-169f-0063-ed6f-59531368d955@ebi.ac.uk> To add I built my own image from http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2 as the images in http://buildlogs.centos.org/centos/7/cloud/x86_64/tripleo_images/newton/delorean/ caused sporadic ramdisk loading errors (hung at x% loaded on boot) Does my image now need to be customised in any way for HA to work? Charles On 11/10/2016 09:55, Charles Short wrote: > Hi, > > I am installing Newton with TripleO on baremetal HP blades. > I can deploy a single controller stack overcloud no problem, however > when I choose three controllers the deployment fails (including > /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml) > . > > The heat stack error first complains "Dependency Exec[galera-ready] > has failures" which in turn causes lots of other errors. > > I have deployed Liberty and Mitaka successfully in the past on > baremetal with three controllers, and this is the first time I have > seen this error. > > Charles > -- Charles Short Cloud Engineer Virtualization and Cloud Team European Bioinformatics Institute (EMBL-EBI) Tel: +44 (0)1223 494205 From marius at remote-lab.net Tue Oct 11 11:07:41 2016 From: marius at remote-lab.net (Marius Cornea) Date: Tue, 11 Oct 2016 13:07:41 +0200 Subject: [rdo-list] Newton HA galera-ready dependency error In-Reply-To: <16532098-169f-0063-ed6f-59531368d955@ebi.ac.uk> References: <16532098-169f-0063-ed6f-59531368d955@ebi.ac.uk> Message-ID: Hi Charles, Could you please paste the output of 'pcs status' ? The log in /var/log/mariadb/mariadb.log might also be a good indicator. On Tue, Oct 11, 2016 at 11:16 AM, Charles Short wrote: > To add I built my own image from > > http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2 > > as the images in > http://buildlogs.centos.org/centos/7/cloud/x86_64/tripleo_images/newton/delorean/ > caused sporadic ramdisk loading errors (hung at x% loaded on boot) > > Does my image now need to be customised in any way for HA to work? > > Charles > > > > > On 11/10/2016 09:55, Charles Short wrote: >> >> Hi, >> >> I am installing Newton with TripleO on baremetal HP blades. >> I can deploy a single controller stack overcloud no problem, however when >> I choose three controllers the deployment fails (including >> >> /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml) >> . >> >> The heat stack error first complains "Dependency Exec[galera-ready] has >> failures" which in turn causes lots of other errors. >> >> I have deployed Liberty and Mitaka successfully in the past on baremetal >> with three controllers, and this is the first time I have seen this error. >> >> Charles >> > > -- > Charles Short > Cloud Engineer > Virtualization and Cloud Team > European Bioinformatics Institute (EMBL-EBI) > Tel: +44 (0)1223 494205 > > _______________________________________________ > rdo-list mailing list > rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com From cems at ebi.ac.uk Tue Oct 11 12:16:49 2016 From: cems at ebi.ac.uk (Charles Short) Date: Tue, 11 Oct 2016 13:16:49 +0100 Subject: [rdo-list] Newton HA galera-ready dependency error In-Reply-To: References: <16532098-169f-0063-ed6f-59531368d955@ebi.ac.uk> Message-ID: <6b370c7f-11f1-b850-00ae-89d6348a4e84@ebi.ac.uk> Hi, Here you are - - Heat stack error - http://pastebin.com/E8KZa2vE - PCS status - http://pastebin.com/z34gSLq6 - mariadb.log - http://pastebin.com/APFXPBLc Thanks Charles On 11/10/2016 12:07, Marius Cornea wrote: > Hi Charles, > > Could you please paste the output of 'pcs status' ? The log in > /var/log/mariadb/mariadb.log might also be a good indicator. > > > On Tue, Oct 11, 2016 at 11:16 AM, Charles Short wrote: >> To add I built my own image from >> >> http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2 >> >> as the images in >> http://buildlogs.centos.org/centos/7/cloud/x86_64/tripleo_images/newton/delorean/ >> caused sporadic ramdisk loading errors (hung at x% loaded on boot) >> >> Does my image now need to be customised in any way for HA to work? >> >> Charles >> >> >> >> >> On 11/10/2016 09:55, Charles Short wrote: >>> Hi, >>> >>> I am installing Newton with TripleO on baremetal HP blades. >>> I can deploy a single controller stack overcloud no problem, however when >>> I choose three controllers the deployment fails (including >>> >>> /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml) >>> . >>> >>> The heat stack error first complains "Dependency Exec[galera-ready] has >>> failures" which in turn causes lots of other errors. >>> >>> I have deployed Liberty and Mitaka successfully in the past on baremetal >>> with three controllers, and this is the first time I have seen this error. >>> >>> Charles >>> >> -- >> Charles Short >> Cloud Engineer >> Virtualization and Cloud Team >> European Bioinformatics Institute (EMBL-EBI) >> Tel: +44 (0)1223 494205 >> >> _______________________________________________ >> 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 -- Charles Short Cloud Engineer Virtualization and Cloud Team European Bioinformatics Institute (EMBL-EBI) Tel: +44 (0)1223 494205 From marius at remote-lab.net Tue Oct 11 13:24:01 2016 From: marius at remote-lab.net (Marius Cornea) Date: Tue, 11 Oct 2016 15:24:01 +0200 Subject: [rdo-list] Newton HA galera-ready dependency error In-Reply-To: <6b370c7f-11f1-b850-00ae-89d6348a4e84@ebi.ac.uk> References: <16532098-169f-0063-ed6f-59531368d955@ebi.ac.uk> <6b370c7f-11f1-b850-00ae-89d6348a4e84@ebi.ac.uk> Message-ID: Hi, Could you also please paste the output for 'pcs resource show galera', it looks that all the galera nodes show up as slaves? Master/Slave Set: galera-master [galera] Slaves: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ] Thanks On Tue, Oct 11, 2016 at 2:16 PM, Charles Short wrote: > Hi, > > Here you are - > > - Heat stack error - http://pastebin.com/E8KZa2vE > - PCS status - http://pastebin.com/z34gSLq6 > - mariadb.log - http://pastebin.com/APFXPBLc > > Thanks > > Charles > > > On 11/10/2016 12:07, Marius Cornea wrote: >> >> Hi Charles, >> >> Could you please paste the output of 'pcs status' ? The log in >> /var/log/mariadb/mariadb.log might also be a good indicator. >> >> >> On Tue, Oct 11, 2016 at 11:16 AM, Charles Short wrote: >>> >>> To add I built my own image from >>> >>> >>> http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2 >>> >>> as the images in >>> >>> http://buildlogs.centos.org/centos/7/cloud/x86_64/tripleo_images/newton/delorean/ >>> caused sporadic ramdisk loading errors (hung at x% loaded on boot) >>> >>> Does my image now need to be customised in any way for HA to work? >>> >>> Charles >>> >>> >>> >>> >>> On 11/10/2016 09:55, Charles Short wrote: >>>> >>>> Hi, >>>> >>>> I am installing Newton with TripleO on baremetal HP blades. >>>> I can deploy a single controller stack overcloud no problem, however >>>> when >>>> I choose three controllers the deployment fails (including >>>> >>>> >>>> /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml) >>>> . >>>> >>>> The heat stack error first complains "Dependency Exec[galera-ready] has >>>> failures" which in turn causes lots of other errors. >>>> >>>> I have deployed Liberty and Mitaka successfully in the past on baremetal >>>> with three controllers, and this is the first time I have seen this >>>> error. >>>> >>>> Charles >>>> >>> -- >>> Charles Short >>> Cloud Engineer >>> Virtualization and Cloud Team >>> European Bioinformatics Institute (EMBL-EBI) >>> Tel: +44 (0)1223 494205 >>> >>> _______________________________________________ >>> 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 > > > -- > Charles Short > Cloud Engineer > Virtualization and Cloud Team > European Bioinformatics Institute (EMBL-EBI) > Tel: +44 (0)1223 494205 > From rbowen at redhat.com Tue Oct 11 13:40:04 2016 From: rbowen at redhat.com (Rich Bowen) Date: Tue, 11 Oct 2016 09:40:04 -0400 Subject: [rdo-list] CloudAppHack, Prague Message-ID: As some of you in Brno are probably already aware, there's an upcoming event in Prague called CloudAppHack in March 2017. Details at http://cloudapphack.eu/ In particular, this event is looking for mentors who will help attendees become familiar with OpenStack and help them make their first contribution. There's a pre-event on November 10th. The information about that is at http://labs.cloudapphack.eu/ and will familiarize people with the goals of the later event. We would really like for some people from this community to be involved, if possible. If you need more information, I can put you in touch with the right people. --Rich -- Rich Bowen - rbowen at redhat.com RDO Community Liaison http://rdoproject.org @RDOCommunity From whayutin at redhat.com Tue Oct 11 15:04:18 2016 From: whayutin at redhat.com (Wesley Hayutin) Date: Tue, 11 Oct 2016 11:04:18 -0400 Subject: [rdo-list] rdo infra scrum Message-ID: Greetings, Latest scrum recording and notes https://bluejeans.com/s/FzK_2/ https://review.rdoproject.org/etherpad/p/rdo-infra-scrum Congrats to the new leadership of the RDO Infra team! Product Manager: Fred Lepied User advocate: 50% David Simard, 50% Attila Team Catalyst: Wes Hayutin, Harry will assist and ramp up TripleO Team lead: John Trowbridge RDO Infra Team lead: Javier Pena -------------- next part -------------- An HTML attachment was scrubbed... URL: From marius at remote-lab.net Tue Oct 11 15:35:04 2016 From: marius at remote-lab.net (Marius Cornea) Date: Tue, 11 Oct 2016 17:35:04 +0200 Subject: [rdo-list] Newton HA galera-ready dependency error In-Reply-To: <87a9220e-0541-b83e-9166-b9c63fceaf8b@ebi.ac.uk> References: <16532098-169f-0063-ed6f-59531368d955@ebi.ac.uk> <6b370c7f-11f1-b850-00ae-89d6348a4e84@ebi.ac.uk> <87a9220e-0541-b83e-9166-b9c63fceaf8b@ebi.ac.uk> Message-ID: Did it succeed in bringing the Galera nodes to Master? You can ssh to the nodes and run 'pcs resource show galera' even though the deployment hasn't finished. I'm interested to see how the wsrep_cluster_address is set to see if it's affected by the resource agent issue described in https://bugs.launchpad.net/tripleo/+bug/1628521 On Tue, Oct 11, 2016 at 5:18 PM, Charles Short wrote: > Looks similar to this bug (still waiting on deployment to finish) > > https://bugzilla.redhat.com/show_bug.cgi?id=1368214 > > > On 11/10/2016 15:25, Charles Short wrote: >> >> Sorry for the delay. >> >> >> Just redeploying to make sure I can repeat the same error. Should not be >> long. >> >> Charles >> >> On 11/10/2016 14:24, Marius Cornea wrote: >>> >>> Hi, >>> >>> Could you also please paste the output for 'pcs resource show galera', >>> it looks that all the galera nodes show up as slaves? >>> >>> Master/Slave Set: galera-master [galera] >>> Slaves: [ overcloud-controller-0 overcloud-controller-1 >>> overcloud-controller-2 ] >>> >>> Thanks >>> >>> On Tue, Oct 11, 2016 at 2:16 PM, Charles Short wrote: >>>> >>>> Hi, >>>> >>>> Here you are - >>>> >>>> - Heat stack error - http://pastebin.com/E8KZa2vE >>>> - PCS status - http://pastebin.com/z34gSLq6 >>>> - mariadb.log - http://pastebin.com/APFXPBLc >>>> >>>> Thanks >>>> >>>> Charles >>>> >>>> >>>> On 11/10/2016 12:07, Marius Cornea wrote: >>>>> >>>>> Hi Charles, >>>>> >>>>> Could you please paste the output of 'pcs status' ? The log in >>>>> /var/log/mariadb/mariadb.log might also be a good indicator. >>>>> >>>>> >>>>> On Tue, Oct 11, 2016 at 11:16 AM, Charles Short wrote: >>>>>> >>>>>> To add I built my own image from >>>>>> >>>>>> >>>>>> >>>>>> http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2 >>>>>> >>>>>> as the images in >>>>>> >>>>>> >>>>>> http://buildlogs.centos.org/centos/7/cloud/x86_64/tripleo_images/newton/delorean/ >>>>>> caused sporadic ramdisk loading errors (hung at x% loaded on boot) >>>>>> >>>>>> Does my image now need to be customised in any way for HA to work? >>>>>> >>>>>> Charles >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 11/10/2016 09:55, Charles Short wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I am installing Newton with TripleO on baremetal HP blades. >>>>>>> I can deploy a single controller stack overcloud no problem, however >>>>>>> when >>>>>>> I choose three controllers the deployment fails (including >>>>>>> >>>>>>> >>>>>>> >>>>>>> /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml) >>>>>>> . >>>>>>> >>>>>>> The heat stack error first complains "Dependency Exec[galera-ready] >>>>>>> has >>>>>>> failures" which in turn causes lots of other errors. >>>>>>> >>>>>>> I have deployed Liberty and Mitaka successfully in the past on >>>>>>> baremetal >>>>>>> with three controllers, and this is the first time I have seen this >>>>>>> error. >>>>>>> >>>>>>> Charles >>>>>>> >>>>>> -- >>>>>> Charles Short >>>>>> Cloud Engineer >>>>>> Virtualization and Cloud Team >>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>> Tel: +44 (0)1223 494205 >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>>> >>>> -- >>>> Charles Short >>>> Cloud Engineer >>>> Virtualization and Cloud Team >>>> European Bioinformatics Institute (EMBL-EBI) >>>> Tel: +44 (0)1223 494205 >>>> >> > > -- > Charles Short > Cloud Engineer > Virtualization and Cloud Team > European Bioinformatics Institute (EMBL-EBI) > Tel: +44 (0)1223 494205 > From Milind.Gunjan at sprint.com Tue Oct 11 15:48:47 2016 From: Milind.Gunjan at sprint.com (Gunjan, Milind [CTO]) Date: Tue, 11 Oct 2016 15:48:47 +0000 Subject: [rdo-list] RDO Newton GA Test Day - October 13, 14 In-Reply-To: References: , Message-ID: Hi Guys, I am really interested in participating in RDO Newton GA test day and we have few baremetal (atleast 5) Cisco UCS servers. I have gone through the test cases related to Triple-O on CentOS and we are really interested in testing out the following : 1. UnderCloud VM and Baremetal Overcloud 2. HA deployment with 3 controllers I am also really interested in testing out "Ironic support in TripleO overcloud". I will be joining in the IRC channel on Newton GA Test Day to work with you guys. Also , please let me know if there is anything else has to be done before starting the testing. I have been part of this community for few months now and I would like to help in any way I can, Thanks a lot. Best Regards, Milind From: rdo-list-bounces at redhat.com [mailto:rdo-list-bounces at redhat.com] On Behalf Of Boris Derzhavets Sent: Friday, October 07, 2016 2:38 AM To: Dmitry Tantsur ; rdo-list at redhat.com Subject: Re: [rdo-list] RDO Newton GA Test Day - October 13, 14 ________________________________ From: rdo-list-bounces at redhat.com > on behalf of Dmitry Tantsur > Sent: Thursday, October 6, 2016 2:03 PM To: rdo-list at redhat.com Subject: Re: [rdo-list] RDO Newton GA Test Day - October 13, 14 On 10/05/2016 04:05 PM, Rich Bowen wrote: > Please join us for the final test day of the Newton cycle. > > Full details of the test day are at > https://www.rdoproject.org/testday/newton/final/ > > We will be testing on October 13th and 14th. Come to #rdo on the > Freenode IRC network for help and discussion. > > Based on discussion on the list, I've moved the test scenarios document > entirely to an etherpad, to make it easier to add test scenarios, as > well as easier for people to add their test day notes. > > Please have a look at the test scenario etherpad prior to test day, and > ensure that desired scenarios are listed, and that instructions are > there for testers to follow - > https://etherpad.openstack.org/p/rdo-newton-ga-testday-testplan > > May I shamelessly ask folks to give Ironic support in TripleO overcloud a try? This is a new thing in Newton, and I know that a lot of people were excited about it. Here is the rough walk-through for testing it: http://tripleo.org/advanced_deployment/baremetal_overcloud.html Could you provide a sample of ironic-config.yaml, which is ready to go , then it would not be a problem to make a test via instack-virt-setup install based on "centos7-newton/current-passed-ci" trunk. Thanks. Boris Thanks! _______________________________________________ rdo-list mailing list rdo-list at redhat.com https://www.redhat.com/mailman/listinfo/rdo-list rdo-list Info Page - Red Hat www.redhat.com The rdo-list mailing list provides a forum for discussions about installing, running, and using OpenStack on Red Hat based distributions. To see the collection of ... To unsubscribe: rdo-list-unsubscribe at redhat.com ________________________________ This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbowen at redhat.com Tue Oct 11 16:13:52 2016 From: rbowen at redhat.com (Rich Bowen) Date: Tue, 11 Oct 2016 12:13:52 -0400 Subject: [rdo-list] Unanswered 'RDO' questions, ask.openstack.org Message-ID: <675eac2a-c4d8-7017-a4ae-abfce9e563f8@redhat.com> 26 unanswered questions: br-tun and br-int are not UP but still VMs are pinging https://ask.openstack.org/en/question/97766/br-tun-and-br-int-are-not-up-but-still-vms-are-pinging/ Tags: rdo-kilo-networking RDO Mikata upgrade bugfix and security update https://ask.openstack.org/en/question/97726/rdo-mikata-upgrade-bugfix-and-security-update/ Tags: packstack, rdo can not ping internet when launch instance cirros on mitaka https://ask.openstack.org/en/question/96949/can-not-ping-internet-when-launch-instance-cirros-on-mitaka/ Tags: cirros, security-groups, mitaka, mitaka-neutron [trove] mongodb cluster-grow failed https://ask.openstack.org/en/question/96571/trove-mongodb-cluster-grow-failed/ Tags: trove, mongodb, cluster, grow "Parameter outiface failed on Firewall" during installation of openstack rdo on centos 7 https://ask.openstack.org/en/question/95657/parameter-outiface-failed-on-firewall-during-installation-of-openstack-rdo-on-centos-7/ Tags: rdo, devstack#mitaka multi nodes provider network ovs config https://ask.openstack.org/en/question/95423/multi-nodes-provider-network-ovs-config/ Tags: rdo, liberty-neutron Adding additional packages to an RDO installation https://ask.openstack.org/en/question/95380/adding-additional-packages-to-an-rdo-installation/ Tags: rdo, mistral RDO TripleO Mitaka HA Overcloud Failing https://ask.openstack.org/en/question/95249/rdo-tripleo-mitaka-ha-overcloud-failing/ Tags: mitaka, tripleo, overcloud, centos7 RDO - is there any fedora package newer than puppet-4.2.1-3.fc24.noarch.rpm https://ask.openstack.org/en/question/94969/rdo-is-there-any-fedora-package-newer-than-puppet-421-3fc24noarchrpm/ Tags: rdo, puppet, install-openstack OpenStack RDO mysqld 100% cpu https://ask.openstack.org/en/question/94961/openstack-rdo-mysqld-100-cpu/ Tags: openstack, mysqld, cpu Failed to set RDO repo on host-packstack-centOS-7 https://ask.openstack.org/en/question/94828/failed-to-set-rdo-repo-on-host-packstack-centos-7/ Tags: openstack-packstack, centos7, rdo how to deploy haskell-distributed in RDO? https://ask.openstack.org/en/question/94785/how-to-deploy-haskell-distributed-in-rdo/ Tags: rdo rdo tripleO liberty undercloud install failing https://ask.openstack.org/en/question/94023/rdo-tripleo-liberty-undercloud-install-failing/ Tags: rdo, rdo-manager, liberty, undercloud, instack Liberty RDO: stack resource topology icons are pink https://ask.openstack.org/en/question/91347/liberty-rdo-stack-resource-topology-icons-are-pink/ Tags: resource, topology, dashboard, horizon, pink No handlers could be found for logger "oslo_config.cfg" while syncing the glance database https://ask.openstack.org/en/question/91169/no-handlers-could-be-found-for-logger-oslo_configcfg-while-syncing-the-glance-database/ Tags: liberty, glance, install-openstack CentOS OpenStack - compute node can't talk https://ask.openstack.org/en/question/88989/centos-openstack-compute-node-cant-talk/ Tags: rdo How to setup SWIFT_PROXY_NODE and SWIFT_STORAGE_NODEs separately on RDO Liberty ? https://ask.openstack.org/en/question/88897/how-to-setup-swift_proxy_node-and-swift_storage_nodes-separately-on-rdo-liberty/ Tags: rdo, liberty, swift, ha VM and container can't download anything from internet https://ask.openstack.org/en/question/88338/vm-and-container-cant-download-anything-from-internet/ Tags: rdo, neutron, network, connectivity Fedora22, Liberty, horizon VNC console and keymap=sv with ; and/ https://ask.openstack.org/en/question/87451/fedora22-liberty-horizon-vnc-console-and-keymapsv-with-and/ Tags: keyboard, map, keymap, vncproxy, novnc OpenStack-Docker driver failed https://ask.openstack.org/en/question/87243/openstack-docker-driver-failed/ Tags: docker, openstack, liberty Routing between two tenants https://ask.openstack.org/en/question/84645/routing-between-two-tenants/ Tags: kilo, fuel, rdo, routing openstack baremetal introspection internal server error https://ask.openstack.org/en/question/82790/openstack-baremetal-introspection-internal-server-error/ Tags: rdo, ironic-inspector, tripleo Installing openstack using packstack (rdo) failed https://ask.openstack.org/en/question/82473/installing-openstack-using-packstack-rdo-failed/ Tags: rdo, packstack, installation-error, keystone VMware Host Backend causes No valid host was found. Bug ??? https://ask.openstack.org/en/question/79738/vmware-host-backend-causes-no-valid-host-was-found-bug/ Tags: vmware, rdo Mutlinode Devstack with two interfaces https://ask.openstack.org/en/question/78615/mutlinode-devstack-with-two-interfaces/ Tags: devstack, vlan, openstack Overcloud deployment on VM fails as IP address from DHCP is not assigned https://ask.openstack.org/en/question/66272/overcloud-deployment-on-vm-fails-as-ip-address-from-dhcp-is-not-assigned/ Tags: overcloud_in_vm -- Rich Bowen - rbowen at redhat.com RDO Community Liaison http://rdoproject.org @RDOCommunity From cems at ebi.ac.uk Tue Oct 11 17:42:29 2016 From: cems at ebi.ac.uk (Charles Short) Date: Tue, 11 Oct 2016 18:42:29 +0100 Subject: [rdo-list] Newton HA galera-ready dependency error In-Reply-To: <08ac18f7-4ab2-a627-895a-7f16b82c3a92@ebi.ac.uk> References: <16532098-169f-0063-ed6f-59531368d955@ebi.ac.uk> <6b370c7f-11f1-b850-00ae-89d6348a4e84@ebi.ac.uk> <87a9220e-0541-b83e-9166-b9c63fceaf8b@ebi.ac.uk> <6bc28bc0-80c8-fae8-1b56-90544abf9801@ebi.ac.uk> <08ac18f7-4ab2-a627-895a-7f16b82c3a92@ebi.ac.uk> Message-ID: <2f6338eb-8346-9a79-cedd-0cdf0d4088dc@ebi.ac.uk> Ok install finished with same error The latest pcs status etc http://pastebin.com/ZK683gZe On 11/10/2016 17:35, Charles Short wrote: > Deployment almost finished...so > > > http://pastebin.com/zE9B19XB > > This shows the pcs status as the deployment nears the end, and pcs > resource show galera > > Charles > > On 11/10/2016 16:59, Marius Cornea wrote: >> Great, thanks for checking this. >> >> On Tue, Oct 11, 2016 at 5:58 PM, Charles Short wrote: >>> Currently having more generic deployment issues (no valid host found >>> etc). >>> I can work around/solve these. >>> I don't yet have another stack to analyse, but will do soon. >>> >>> Charles >>> >>> >>> On 11/10/2016 16:35, Marius Cornea wrote: >>>> Did it succeed in bringing the Galera nodes to Master? You can ssh to >>>> the nodes and run 'pcs resource show galera' even though the >>>> deployment hasn't finished. I'm interested to see how the >>>> wsrep_cluster_address is set to see if it's affected by the resource >>>> agent issue described in >>>> https://bugs.launchpad.net/tripleo/+bug/1628521 >>>> >>>> On Tue, Oct 11, 2016 at 5:18 PM, Charles Short wrote: >>>>> Looks similar to this bug (still waiting on deployment to finish) >>>>> >>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1368214 >>>>> >>>>> >>>>> On 11/10/2016 15:25, Charles Short wrote: >>>>>> Sorry for the delay. >>>>>> >>>>>> >>>>>> Just redeploying to make sure I can repeat the same error. Should >>>>>> not be >>>>>> long. >>>>>> >>>>>> Charles >>>>>> >>>>>> On 11/10/2016 14:24, Marius Cornea wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Could you also please paste the output for 'pcs resource show >>>>>>> galera', >>>>>>> it looks that all the galera nodes show up as slaves? >>>>>>> >>>>>>> Master/Slave Set: galera-master [galera] >>>>>>> Slaves: [ overcloud-controller-0 overcloud-controller-1 >>>>>>> overcloud-controller-2 ] >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> On Tue, Oct 11, 2016 at 2:16 PM, Charles Short >>>>>>> wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Here you are - >>>>>>>> >>>>>>>> - Heat stack error - http://pastebin.com/E8KZa2vE >>>>>>>> - PCS status - http://pastebin.com/z34gSLq6 >>>>>>>> - mariadb.log - http://pastebin.com/APFXPBLc >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> Charles >>>>>>>> >>>>>>>> >>>>>>>> On 11/10/2016 12:07, Marius Cornea wrote: >>>>>>>>> Hi Charles, >>>>>>>>> >>>>>>>>> Could you please paste the output of 'pcs status' ? The log in >>>>>>>>> /var/log/mariadb/mariadb.log might also be a good indicator. >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Oct 11, 2016 at 11:16 AM, Charles Short >>>>>>>>> wrote: >>>>>>>>>> To add I built my own image from >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> as the images in >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> http://buildlogs.centos.org/centos/7/cloud/x86_64/tripleo_images/newton/delorean/ >>>>>>>>>> >>>>>>>>>> caused sporadic ramdisk loading errors (hung at x% loaded on >>>>>>>>>> boot) >>>>>>>>>> >>>>>>>>>> Does my image now need to be customised in any way for HA to >>>>>>>>>> work? >>>>>>>>>> >>>>>>>>>> Charles >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 11/10/2016 09:55, Charles Short wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I am installing Newton with TripleO on baremetal HP blades. >>>>>>>>>>> I can deploy a single controller stack overcloud no problem, >>>>>>>>>>> however >>>>>>>>>>> when >>>>>>>>>>> I choose three controllers the deployment fails (including >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml) >>>>>>>>>>> >>>>>>>>>>> . >>>>>>>>>>> >>>>>>>>>>> The heat stack error first complains "Dependency >>>>>>>>>>> Exec[galera-ready] >>>>>>>>>>> has >>>>>>>>>>> failures" which in turn causes lots of other errors. >>>>>>>>>>> >>>>>>>>>>> I have deployed Liberty and Mitaka successfully in the past on >>>>>>>>>>> baremetal >>>>>>>>>>> with three controllers, and this is the first time I have >>>>>>>>>>> seen this >>>>>>>>>>> error. >>>>>>>>>>> >>>>>>>>>>> Charles >>>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Charles Short >>>>>>>>>> Cloud Engineer >>>>>>>>>> Virtualization and Cloud Team >>>>>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>>>>> Tel: +44 (0)1223 494205 >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>>>>>>> >>>>>>>> -- >>>>>>>> Charles Short >>>>>>>> Cloud Engineer >>>>>>>> Virtualization and Cloud Team >>>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>>> Tel: +44 (0)1223 494205 >>>>>>>> >>>>> -- >>>>> Charles Short >>>>> Cloud Engineer >>>>> Virtualization and Cloud Team >>>>> European Bioinformatics Institute (EMBL-EBI) >>>>> Tel: +44 (0)1223 494205 >>>>> >>> -- >>> Charles Short >>> Cloud Engineer >>> Virtualization and Cloud Team >>> European Bioinformatics Institute (EMBL-EBI) >>> Tel: +44 (0)1223 494205 >>> > -- Charles Short Cloud Engineer Virtualization and Cloud Team European Bioinformatics Institute (EMBL-EBI) Tel: +44 (0)1223 494205 From rbowen at redhat.com Tue Oct 11 18:06:56 2016 From: rbowen at redhat.com (Rich Bowen) Date: Tue, 11 Oct 2016 14:06:56 -0400 Subject: [rdo-list] DevConf.cz call for papers open Message-ID: <92d46044-5995-632d-00be-7e7137153e0a@redhat.com> I expect that many of you have already seen this, but, in case you haven't ... DevConf.cz 2017 CfP is now OPEN! Check the DevConf.cz site for more detail! http://devconf.cz/ Important dates: * CFP Due Date: Friday, November 11th 11:59PM CST * Speakers Announced: December 2nd 11:59PM CST * Final Schedule Announced: By Jan 6, 2017 * DevConf.cz 2017 - Friday Jan 27 to Sunday Jan 29, 2017 Help us promote the event: https://www.facebook.com/events/1182179895159116/ https://plus.google.com/events/ct7gur3j5r76kghc7utpjro66m0 Forward this mail to your favorite mailing lists! Have questions or concerns? Have a suggestion for a great keynoter? ping me (cward at redhat.com)! Please note too that devconf.cz has been completely redesigned. If you find any issues with the site or the CfP form... send a pull request or open a new issue to the official DevConf.cz repo. https://github.com/kejbaly2/devconfcz See you at DevConf.cz 2017! -- Rich Bowen - rbowen at redhat.com RDO Community Liaison http://rdoproject.org @RDOCommunity From marius at remote-lab.net Tue Oct 11 18:39:16 2016 From: marius at remote-lab.net (Marius Cornea) Date: Tue, 11 Oct 2016 20:39:16 +0200 Subject: [rdo-list] Newton HA galera-ready dependency error In-Reply-To: <2f6338eb-8346-9a79-cedd-0cdf0d4088dc@ebi.ac.uk> References: <16532098-169f-0063-ed6f-59531368d955@ebi.ac.uk> <6b370c7f-11f1-b850-00ae-89d6348a4e84@ebi.ac.uk> <87a9220e-0541-b83e-9166-b9c63fceaf8b@ebi.ac.uk> <6bc28bc0-80c8-fae8-1b56-90544abf9801@ebi.ac.uk> <08ac18f7-4ab2-a627-895a-7f16b82c3a92@ebi.ac.uk> <2f6338eb-8346-9a79-cedd-0cdf0d4088dc@ebi.ac.uk> Message-ID: I think the issue is caused by the addresses in wsrep_cluster_address not matching the pacemaker node names: wsrep_cluster_address=gcomm://overcloud-controller-0.internalapi.localdomain,overcloud-controller-1.internalapi.localdomain,overcloud-controller-2.internalapi.localdomain Could you please confirm what version of puppet-tripleo you've got installed on the overcloud nodes and if it contains the following patch: https://review.openstack.org/#/c/382883/1/manifests/profile/pacemaker/database/mysql.pp Thanks, Marius On Tue, Oct 11, 2016 at 7:42 PM, Charles Short wrote: > Ok install finished with same error > The latest pcs status etc > > http://pastebin.com/ZK683gZe > > > On 11/10/2016 17:35, Charles Short wrote: >> >> Deployment almost finished...so >> >> >> http://pastebin.com/zE9B19XB >> >> This shows the pcs status as the deployment nears the end, and pcs >> resource show galera >> >> Charles >> >> On 11/10/2016 16:59, Marius Cornea wrote: >>> >>> Great, thanks for checking this. >>> >>> On Tue, Oct 11, 2016 at 5:58 PM, Charles Short wrote: >>>> >>>> Currently having more generic deployment issues (no valid host found >>>> etc). >>>> I can work around/solve these. >>>> I don't yet have another stack to analyse, but will do soon. >>>> >>>> Charles >>>> >>>> >>>> On 11/10/2016 16:35, Marius Cornea wrote: >>>>> >>>>> Did it succeed in bringing the Galera nodes to Master? You can ssh to >>>>> the nodes and run 'pcs resource show galera' even though the >>>>> deployment hasn't finished. I'm interested to see how the >>>>> wsrep_cluster_address is set to see if it's affected by the resource >>>>> agent issue described in >>>>> https://bugs.launchpad.net/tripleo/+bug/1628521 >>>>> >>>>> On Tue, Oct 11, 2016 at 5:18 PM, Charles Short wrote: >>>>>> >>>>>> Looks similar to this bug (still waiting on deployment to finish) >>>>>> >>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1368214 >>>>>> >>>>>> >>>>>> On 11/10/2016 15:25, Charles Short wrote: >>>>>>> >>>>>>> Sorry for the delay. >>>>>>> >>>>>>> >>>>>>> Just redeploying to make sure I can repeat the same error. Should not >>>>>>> be >>>>>>> long. >>>>>>> >>>>>>> Charles >>>>>>> >>>>>>> On 11/10/2016 14:24, Marius Cornea wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Could you also please paste the output for 'pcs resource show >>>>>>>> galera', >>>>>>>> it looks that all the galera nodes show up as slaves? >>>>>>>> >>>>>>>> Master/Slave Set: galera-master [galera] >>>>>>>> Slaves: [ overcloud-controller-0 overcloud-controller-1 >>>>>>>> overcloud-controller-2 ] >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> On Tue, Oct 11, 2016 at 2:16 PM, Charles Short >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Here you are - >>>>>>>>> >>>>>>>>> - Heat stack error - http://pastebin.com/E8KZa2vE >>>>>>>>> - PCS status - http://pastebin.com/z34gSLq6 >>>>>>>>> - mariadb.log - http://pastebin.com/APFXPBLc >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> >>>>>>>>> Charles >>>>>>>>> >>>>>>>>> >>>>>>>>> On 11/10/2016 12:07, Marius Cornea wrote: >>>>>>>>>> >>>>>>>>>> Hi Charles, >>>>>>>>>> >>>>>>>>>> Could you please paste the output of 'pcs status' ? The log in >>>>>>>>>> /var/log/mariadb/mariadb.log might also be a good indicator. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Oct 11, 2016 at 11:16 AM, Charles Short >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> To add I built my own image from >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2 >>>>>>>>>>> >>>>>>>>>>> as the images in >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> http://buildlogs.centos.org/centos/7/cloud/x86_64/tripleo_images/newton/delorean/ >>>>>>>>>>> caused sporadic ramdisk loading errors (hung at x% loaded on >>>>>>>>>>> boot) >>>>>>>>>>> >>>>>>>>>>> Does my image now need to be customised in any way for HA to >>>>>>>>>>> work? >>>>>>>>>>> >>>>>>>>>>> Charles >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 11/10/2016 09:55, Charles Short wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I am installing Newton with TripleO on baremetal HP blades. >>>>>>>>>>>> I can deploy a single controller stack overcloud no problem, >>>>>>>>>>>> however >>>>>>>>>>>> when >>>>>>>>>>>> I choose three controllers the deployment fails (including >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml) >>>>>>>>>>>> . >>>>>>>>>>>> >>>>>>>>>>>> The heat stack error first complains "Dependency >>>>>>>>>>>> Exec[galera-ready] >>>>>>>>>>>> has >>>>>>>>>>>> failures" which in turn causes lots of other errors. >>>>>>>>>>>> >>>>>>>>>>>> I have deployed Liberty and Mitaka successfully in the past on >>>>>>>>>>>> baremetal >>>>>>>>>>>> with three controllers, and this is the first time I have seen >>>>>>>>>>>> this >>>>>>>>>>>> error. >>>>>>>>>>>> >>>>>>>>>>>> Charles >>>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Charles Short >>>>>>>>>>> Cloud Engineer >>>>>>>>>>> Virtualization and Cloud Team >>>>>>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>>>>>> Tel: +44 (0)1223 494205 >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Charles Short >>>>>>>>> Cloud Engineer >>>>>>>>> Virtualization and Cloud Team >>>>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>>>> Tel: +44 (0)1223 494205 >>>>>>>>> >>>>>> -- >>>>>> Charles Short >>>>>> Cloud Engineer >>>>>> Virtualization and Cloud Team >>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>> Tel: +44 (0)1223 494205 >>>>>> >>>> -- >>>> Charles Short >>>> Cloud Engineer >>>> Virtualization and Cloud Team >>>> European Bioinformatics Institute (EMBL-EBI) >>>> Tel: +44 (0)1223 494205 >>>> >> > > -- > Charles Short > Cloud Engineer > Virtualization and Cloud Team > European Bioinformatics Institute (EMBL-EBI) > Tel: +44 (0)1223 494205 > From rbowen at redhat.com Tue Oct 11 18:57:16 2016 From: rbowen at redhat.com (Rich Bowen) Date: Tue, 11 Oct 2016 14:57:16 -0400 Subject: [rdo-list] RDO Newton GA Test Day - October 13, 14 In-Reply-To: References: <15263666-076c-6b15-6de5-59a5bfe52a47@redhat.com> Message-ID: <1e4683d5-072a-bd41-543f-2589131cab22@redhat.com> On 10/10/2016 05:42 AM, Alan Pevec wrote: >> Sure, what's the best place to put it? > > In testcases etherpad linked from > https://www.rdoproject.org/testday/newton/final/ (Sorry, I was out the last few days) Yes, in the etherpad, and then, once the test day is over, we can collect some of these instructions and put them under /testday/ on the RDO site for more permanent reference. -- Rich Bowen - rbowen at redhat.com RDO Community Liaison http://rdoproject.org @RDOCommunity From rbowen at redhat.com Tue Oct 11 19:36:57 2016 From: rbowen at redhat.com (Rich Bowen) Date: Tue, 11 Oct 2016 15:36:57 -0400 Subject: [rdo-list] RDO bloggers, week of October 10th Message-ID: Here's what RDO enthusiasts have been blogging about in the last few days. *RDO Newton Released* by Rich Bowen The RDO community is pleased to announce the general availability of the RDO build for OpenStack Newton for RPM-based distributions, CentOS Linux 7 and Red Hat Enterprise Linux. RDO is suitable for building private, public, and hybrid clouds. Newton is the 14th release from the OpenStack project, which is the work of more than 2700 contributors from around the world (source). Read more at http://tm3.org/bm *How to run Rally on Packstack environment* by mkopec Rally is a benchmarking tool that automates and unifies multi-node OpenStack deployment, cloud verification, benchmarking & profiling. For OpenStack deployment I used packstack tool. Read more at http://tm3.org/bn *TripleO Composable Services 101* by Steve Hardy Over the newton cycle, we've been working very hard on a major refactor of our heat templates and puppet manifiests, such that a much more granular and flexible "Composable Services" pattern is followed throughout our implementation.It's been a lot of work, but it's been a frequently requested feature for some time, so I'm excited to be in a position to say it's complete for Newton (kudos to everyone involved in making that happen!) :)This post aims to provide an introduction to this work, an overview of how it works under the hood, some simple usage examples and a roadmap for some related follow-on work. Read more at http://tm3.org/8b *TripleO composable/custom roles* by Steve Hardy This is a follow-up to my previous post outlining the new composable services interfaces , which covered the basics of the new for Newton composable services model.The final piece of the composability model we've been developing this cycle is the ability to deploy user-defined custom roles, in addition to (or even instead of) the built in TripleO roles (where a role is a group of servers, e.g "Controller", which runs some combination of services).What follows is an overview of this new functionality, the primary interfaces, and some usage examples and a summary of future planned work. Read more at http://tm3.org/bo *Ceph/RDO meetup in Barcelona at OpenStack Summit* by Rich Bowen If you'll be in Barcelona later this month for OpenStack Summit, join us for an evening with RDO and Ceph. Read more at http://tm3.org/bp *Translating Between RDO/RHOS and upstream releases Redux* by Adam Young I posted this once before, but we?ve moved on a bit since then. So, an update. Read more at http://tm3.org/bq -- Rich Bowen - rbowen at redhat.com RDO Community Liaison http://rdoproject.org @RDOCommunity -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbowen at redhat.com Tue Oct 11 19:58:15 2016 From: rbowen at redhat.com (Rich Bowen) Date: Tue, 11 Oct 2016 15:58:15 -0400 Subject: [rdo-list] Upcoming RDO/OpenStack meetups Message-ID: <51d00c23-13ac-d6dc-db6b-e86a8fb4f49f@redhat.com> The following are the meetups I'm aware of in the coming week where OpenStack and/or RDO enthusiasts are likely to be present. If you know of others, please let me know, and/or add them to http://rdoproject.org/events If there's a meetup in your area, please consider attending. If you attend, please consider taking a few photos, and possibly even writing up a brief summary of what was covered. --Rich * Wednesday October 12 in Phoenix, AZ, US: Key Benefits to Deploying OpenStack Cloud & Alleviating Networking Challenges - http://www.meetup.com/OpenStack-Phoenix/events/234268164/ * Wednesday October 12 in Orlando, FL, US: Get up to speed on the Red Hat OpenShift PaaS Cloud - http://www.meetup.com/Orlando-Central-Florida-OpenStack-Meetup/events/233976642/ * Thursday October 13 in Fort Lauderdale, FL, US: Monthly SFOUG Meeting - http://www.meetup.com/South-Florida-OpenStack-Users-Group/events/233148640/ * Thursday October 13 in Canberra, AU: Training on the Shade SDK - http://www.meetup.com/Australian-OpenStack-User-Group/events/234491825/ * Thursday October 13 in San Antonio, TX, US: Managing OpenStack with Python - http://www.meetup.com/SA-Open-Stackers/events/234002370/ * Thursday October 13 in San Antonio, TX, US: SA OpenStackers - Managing OpenStack with Python - http://www.meetup.com/The-Iron-Yard-San-Antonio/events/234619905/ * Thursday October 13 in Sunnyvale, CA, US: Monitoring Analytics for OpenStack Environments: Hype or Help? - http://www.meetup.com/openstack/events/233767316/ * Friday October 14 in Lagos, NG: OpenStack Projects - http://www.meetup.com/OpenStack-User-Group-Nigeria/events/234262810/ -- Rich Bowen - rbowen at redhat.com RDO Community Liaison http://rdoproject.org @RDOCommunity From rbowen at redhat.com Tue Oct 11 20:28:21 2016 From: rbowen at redhat.com (Rich Bowen) Date: Tue, 11 Oct 2016 16:28:21 -0400 Subject: [rdo-list] Demos, booth assistance at OpenStack Summit, Barcelona Message-ID: With OpenStack Summit now less than two weeks away, I want to remind everyone that there's lots of time/space for folks to drop by and help out at the RDO booth in the main exhibit hall. We will be participating again in the community space at the Red Hat booth, sharing this space with Ceph, ManageIQ, and other community projects where Red Hat has a large presence. If you are able and willing to drop by for any of the day, you can find a schedule at https://etherpad.openstack.org/p/rdo-barcelona-summit-booth where you can sign up for a spot. If you want to take more/less time, simply indicate that by editing the schedule accordingly. You may do a demo, if you wish, or you can just hang out to answer questions. Thanks, and I hope to see you in Barcelona. -- Rich Bowen - rbowen at redhat.com RDO Community Liaison http://rdoproject.org @RDOCommunity From cems at ebi.ac.uk Tue Oct 11 22:48:14 2016 From: cems at ebi.ac.uk (Charles Short) Date: Tue, 11 Oct 2016 23:48:14 +0100 Subject: [rdo-list] Newton HA galera-ready dependency error In-Reply-To: References: <16532098-169f-0063-ed6f-59531368d955@ebi.ac.uk> <6b370c7f-11f1-b850-00ae-89d6348a4e84@ebi.ac.uk> <87a9220e-0541-b83e-9166-b9c63fceaf8b@ebi.ac.uk> <6bc28bc0-80c8-fae8-1b56-90544abf9801@ebi.ac.uk> <08ac18f7-4ab2-a627-895a-7f16b82c3a92@ebi.ac.uk> <2f6338eb-8346-9a79-cedd-0cdf0d4088dc@ebi.ac.uk> Message-ID: <959b1b0f-da3a-0827-4d3d-f6239c92a735@ebi.ac.uk> Hi, puppet-tripleo-5.2.0-0.20161007035759.f32e484.el7.centos.noarch The patch seems to be already present - grep short /usr/share/openstack-puppet/modules/tripleo/manifests/profile/pacemaker/database/mysql.pp # short name which is already registered in pacemaker until we get around $galera_node_names_lookup = hiera('mysql_short_node_names', hiera('mysql_node_names', $::hostname)) Charles On 11/10/2016 19:39, Marius Cornea wrote: > I think the issue is caused by the addresses in wsrep_cluster_address > not matching the pacemaker node names: > wsrep_cluster_address=gcomm://overcloud-controller-0.internalapi.localdomain,overcloud-controller-1.internalapi.localdomain,overcloud-controller-2.internalapi.localdomain > > Could you please confirm what version of puppet-tripleo you've got > installed on the overcloud nodes and if it contains the following > patch: https://review.openstack.org/#/c/382883/1/manifests/profile/pacemaker/database/mysql.pp > > Thanks, > Marius > > On Tue, Oct 11, 2016 at 7:42 PM, Charles Short wrote: >> Ok install finished with same error >> The latest pcs status etc >> >> http://pastebin.com/ZK683gZe >> >> >> On 11/10/2016 17:35, Charles Short wrote: >>> Deployment almost finished...so >>> >>> >>> http://pastebin.com/zE9B19XB >>> >>> This shows the pcs status as the deployment nears the end, and pcs >>> resource show galera >>> >>> Charles >>> >>> On 11/10/2016 16:59, Marius Cornea wrote: >>>> Great, thanks for checking this. >>>> >>>> On Tue, Oct 11, 2016 at 5:58 PM, Charles Short wrote: >>>>> Currently having more generic deployment issues (no valid host found >>>>> etc). >>>>> I can work around/solve these. >>>>> I don't yet have another stack to analyse, but will do soon. >>>>> >>>>> Charles >>>>> >>>>> >>>>> On 11/10/2016 16:35, Marius Cornea wrote: >>>>>> Did it succeed in bringing the Galera nodes to Master? You can ssh to >>>>>> the nodes and run 'pcs resource show galera' even though the >>>>>> deployment hasn't finished. I'm interested to see how the >>>>>> wsrep_cluster_address is set to see if it's affected by the resource >>>>>> agent issue described in >>>>>> https://bugs.launchpad.net/tripleo/+bug/1628521 >>>>>> >>>>>> On Tue, Oct 11, 2016 at 5:18 PM, Charles Short wrote: >>>>>>> Looks similar to this bug (still waiting on deployment to finish) >>>>>>> >>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1368214 >>>>>>> >>>>>>> >>>>>>> On 11/10/2016 15:25, Charles Short wrote: >>>>>>>> Sorry for the delay. >>>>>>>> >>>>>>>> >>>>>>>> Just redeploying to make sure I can repeat the same error. Should not >>>>>>>> be >>>>>>>> long. >>>>>>>> >>>>>>>> Charles >>>>>>>> >>>>>>>> On 11/10/2016 14:24, Marius Cornea wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Could you also please paste the output for 'pcs resource show >>>>>>>>> galera', >>>>>>>>> it looks that all the galera nodes show up as slaves? >>>>>>>>> >>>>>>>>> Master/Slave Set: galera-master [galera] >>>>>>>>> Slaves: [ overcloud-controller-0 overcloud-controller-1 >>>>>>>>> overcloud-controller-2 ] >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> >>>>>>>>> On Tue, Oct 11, 2016 at 2:16 PM, Charles Short >>>>>>>>> wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Here you are - >>>>>>>>>> >>>>>>>>>> - Heat stack error - http://pastebin.com/E8KZa2vE >>>>>>>>>> - PCS status - http://pastebin.com/z34gSLq6 >>>>>>>>>> - mariadb.log - http://pastebin.com/APFXPBLc >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> >>>>>>>>>> Charles >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 11/10/2016 12:07, Marius Cornea wrote: >>>>>>>>>>> Hi Charles, >>>>>>>>>>> >>>>>>>>>>> Could you please paste the output of 'pcs status' ? The log in >>>>>>>>>>> /var/log/mariadb/mariadb.log might also be a good indicator. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Tue, Oct 11, 2016 at 11:16 AM, Charles Short >>>>>>>>>>> wrote: >>>>>>>>>>>> To add I built my own image from >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2 >>>>>>>>>>>> >>>>>>>>>>>> as the images in >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> http://buildlogs.centos.org/centos/7/cloud/x86_64/tripleo_images/newton/delorean/ >>>>>>>>>>>> caused sporadic ramdisk loading errors (hung at x% loaded on >>>>>>>>>>>> boot) >>>>>>>>>>>> >>>>>>>>>>>> Does my image now need to be customised in any way for HA to >>>>>>>>>>>> work? >>>>>>>>>>>> >>>>>>>>>>>> Charles >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 11/10/2016 09:55, Charles Short wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> I am installing Newton with TripleO on baremetal HP blades. >>>>>>>>>>>>> I can deploy a single controller stack overcloud no problem, >>>>>>>>>>>>> however >>>>>>>>>>>>> when >>>>>>>>>>>>> I choose three controllers the deployment fails (including >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml) >>>>>>>>>>>>> . >>>>>>>>>>>>> >>>>>>>>>>>>> The heat stack error first complains "Dependency >>>>>>>>>>>>> Exec[galera-ready] >>>>>>>>>>>>> has >>>>>>>>>>>>> failures" which in turn causes lots of other errors. >>>>>>>>>>>>> >>>>>>>>>>>>> I have deployed Liberty and Mitaka successfully in the past on >>>>>>>>>>>>> baremetal >>>>>>>>>>>>> with three controllers, and this is the first time I have seen >>>>>>>>>>>>> this >>>>>>>>>>>>> error. >>>>>>>>>>>>> >>>>>>>>>>>>> Charles >>>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Charles Short >>>>>>>>>>>> Cloud Engineer >>>>>>>>>>>> Virtualization and Cloud Team >>>>>>>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>>>>>>> Tel: +44 (0)1223 494205 >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Charles Short >>>>>>>>>> Cloud Engineer >>>>>>>>>> Virtualization and Cloud Team >>>>>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>>>>> Tel: +44 (0)1223 494205 >>>>>>>>>> >>>>>>> -- >>>>>>> Charles Short >>>>>>> Cloud Engineer >>>>>>> Virtualization and Cloud Team >>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>> Tel: +44 (0)1223 494205 >>>>>>> >>>>> -- >>>>> Charles Short >>>>> Cloud Engineer >>>>> Virtualization and Cloud Team >>>>> European Bioinformatics Institute (EMBL-EBI) >>>>> Tel: +44 (0)1223 494205 >>>>> >> -- >> Charles Short >> Cloud Engineer >> Virtualization and Cloud Team >> European Bioinformatics Institute (EMBL-EBI) >> Tel: +44 (0)1223 494205 >> -- Charles Short Cloud Engineer Virtualization and Cloud Team European Bioinformatics Institute (EMBL-EBI) Tel: +44 (0)1223 494205 From marius at remote-lab.net Wed Oct 12 08:09:26 2016 From: marius at remote-lab.net (Marius Cornea) Date: Wed, 12 Oct 2016 10:09:26 +0200 Subject: [rdo-list] Newton HA galera-ready dependency error In-Reply-To: <959b1b0f-da3a-0827-4d3d-f6239c92a735@ebi.ac.uk> References: <16532098-169f-0063-ed6f-59531368d955@ebi.ac.uk> <6b370c7f-11f1-b850-00ae-89d6348a4e84@ebi.ac.uk> <87a9220e-0541-b83e-9166-b9c63fceaf8b@ebi.ac.uk> <6bc28bc0-80c8-fae8-1b56-90544abf9801@ebi.ac.uk> <08ac18f7-4ab2-a627-895a-7f16b82c3a92@ebi.ac.uk> <2f6338eb-8346-9a79-cedd-0cdf0d4088dc@ebi.ac.uk> <959b1b0f-da3a-0827-4d3d-f6239c92a735@ebi.ac.uk> Message-ID: That's odd. I encountered the same issue and it was caused by missing this patch. What do you get if you do sudo hiera mysql_short_node_names on the controller node? On Wed, Oct 12, 2016 at 12:48 AM, Charles Short wrote: > Hi, > > puppet-tripleo-5.2.0-0.20161007035759.f32e484.el7.centos.noarch > > The patch seems to be already present - > > grep short > /usr/share/openstack-puppet/modules/tripleo/manifests/profile/pacemaker/database/mysql.pp > > # short name which is already registered in pacemaker until we get around > $galera_node_names_lookup = hiera('mysql_short_node_names', > hiera('mysql_node_names', $::hostname)) > > Charles > > On 11/10/2016 19:39, Marius Cornea wrote: >> >> I think the issue is caused by the addresses in wsrep_cluster_address >> not matching the pacemaker node names: >> >> wsrep_cluster_address=gcomm://overcloud-controller-0.internalapi.localdomain,overcloud-controller-1.internalapi.localdomain,overcloud-controller-2.internalapi.localdomain >> >> Could you please confirm what version of puppet-tripleo you've got >> installed on the overcloud nodes and if it contains the following >> patch: >> https://review.openstack.org/#/c/382883/1/manifests/profile/pacemaker/database/mysql.pp >> >> Thanks, >> Marius >> >> On Tue, Oct 11, 2016 at 7:42 PM, Charles Short wrote: >>> >>> Ok install finished with same error >>> The latest pcs status etc >>> >>> http://pastebin.com/ZK683gZe >>> >>> >>> On 11/10/2016 17:35, Charles Short wrote: >>>> >>>> Deployment almost finished...so >>>> >>>> >>>> http://pastebin.com/zE9B19XB >>>> >>>> This shows the pcs status as the deployment nears the end, and pcs >>>> resource show galera >>>> >>>> Charles >>>> >>>> On 11/10/2016 16:59, Marius Cornea wrote: >>>>> >>>>> Great, thanks for checking this. >>>>> >>>>> On Tue, Oct 11, 2016 at 5:58 PM, Charles Short wrote: >>>>>> >>>>>> Currently having more generic deployment issues (no valid host found >>>>>> etc). >>>>>> I can work around/solve these. >>>>>> I don't yet have another stack to analyse, but will do soon. >>>>>> >>>>>> Charles >>>>>> >>>>>> >>>>>> On 11/10/2016 16:35, Marius Cornea wrote: >>>>>>> >>>>>>> Did it succeed in bringing the Galera nodes to Master? You can ssh to >>>>>>> the nodes and run 'pcs resource show galera' even though the >>>>>>> deployment hasn't finished. I'm interested to see how the >>>>>>> wsrep_cluster_address is set to see if it's affected by the resource >>>>>>> agent issue described in >>>>>>> https://bugs.launchpad.net/tripleo/+bug/1628521 >>>>>>> >>>>>>> On Tue, Oct 11, 2016 at 5:18 PM, Charles Short >>>>>>> wrote: >>>>>>>> >>>>>>>> Looks similar to this bug (still waiting on deployment to finish) >>>>>>>> >>>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1368214 >>>>>>>> >>>>>>>> >>>>>>>> On 11/10/2016 15:25, Charles Short wrote: >>>>>>>>> >>>>>>>>> Sorry for the delay. >>>>>>>>> >>>>>>>>> >>>>>>>>> Just redeploying to make sure I can repeat the same error. Should >>>>>>>>> not >>>>>>>>> be >>>>>>>>> long. >>>>>>>>> >>>>>>>>> Charles >>>>>>>>> >>>>>>>>> On 11/10/2016 14:24, Marius Cornea wrote: >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Could you also please paste the output for 'pcs resource show >>>>>>>>>> galera', >>>>>>>>>> it looks that all the galera nodes show up as slaves? >>>>>>>>>> >>>>>>>>>> Master/Slave Set: galera-master [galera] >>>>>>>>>> Slaves: [ overcloud-controller-0 overcloud-controller-1 >>>>>>>>>> overcloud-controller-2 ] >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> >>>>>>>>>> On Tue, Oct 11, 2016 at 2:16 PM, Charles Short >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Here you are - >>>>>>>>>>> >>>>>>>>>>> - Heat stack error - http://pastebin.com/E8KZa2vE >>>>>>>>>>> - PCS status - http://pastebin.com/z34gSLq6 >>>>>>>>>>> - mariadb.log - http://pastebin.com/APFXPBLc >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> >>>>>>>>>>> Charles >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 11/10/2016 12:07, Marius Cornea wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Charles, >>>>>>>>>>>> >>>>>>>>>>>> Could you please paste the output of 'pcs status' ? The log in >>>>>>>>>>>> /var/log/mariadb/mariadb.log might also be a good indicator. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Oct 11, 2016 at 11:16 AM, Charles Short >>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> To add I built my own image from >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2 >>>>>>>>>>>>> >>>>>>>>>>>>> as the images in >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> http://buildlogs.centos.org/centos/7/cloud/x86_64/tripleo_images/newton/delorean/ >>>>>>>>>>>>> caused sporadic ramdisk loading errors (hung at x% loaded on >>>>>>>>>>>>> boot) >>>>>>>>>>>>> >>>>>>>>>>>>> Does my image now need to be customised in any way for HA to >>>>>>>>>>>>> work? >>>>>>>>>>>>> >>>>>>>>>>>>> Charles >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 11/10/2016 09:55, Charles Short wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I am installing Newton with TripleO on baremetal HP blades. >>>>>>>>>>>>>> I can deploy a single controller stack overcloud no problem, >>>>>>>>>>>>>> however >>>>>>>>>>>>>> when >>>>>>>>>>>>>> I choose three controllers the deployment fails (including >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml) >>>>>>>>>>>>>> . >>>>>>>>>>>>>> >>>>>>>>>>>>>> The heat stack error first complains "Dependency >>>>>>>>>>>>>> Exec[galera-ready] >>>>>>>>>>>>>> has >>>>>>>>>>>>>> failures" which in turn causes lots of other errors. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I have deployed Liberty and Mitaka successfully in the past on >>>>>>>>>>>>>> baremetal >>>>>>>>>>>>>> with three controllers, and this is the first time I have seen >>>>>>>>>>>>>> this >>>>>>>>>>>>>> error. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Charles >>>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Charles Short >>>>>>>>>>>>> Cloud Engineer >>>>>>>>>>>>> Virtualization and Cloud Team >>>>>>>>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>>>>>>>> Tel: +44 (0)1223 494205 >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Charles Short >>>>>>>>>>> Cloud Engineer >>>>>>>>>>> Virtualization and Cloud Team >>>>>>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>>>>>> Tel: +44 (0)1223 494205 >>>>>>>>>>> >>>>>>>> -- >>>>>>>> Charles Short >>>>>>>> Cloud Engineer >>>>>>>> Virtualization and Cloud Team >>>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>>> Tel: +44 (0)1223 494205 >>>>>>>> >>>>>> -- >>>>>> Charles Short >>>>>> Cloud Engineer >>>>>> Virtualization and Cloud Team >>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>> Tel: +44 (0)1223 494205 >>>>>> >>> -- >>> Charles Short >>> Cloud Engineer >>> Virtualization and Cloud Team >>> European Bioinformatics Institute (EMBL-EBI) >>> Tel: +44 (0)1223 494205 >>> > > -- > Charles Short > Cloud Engineer > Virtualization and Cloud Team > European Bioinformatics Institute (EMBL-EBI) > Tel: +44 (0)1223 494205 > From cems at ebi.ac.uk Wed Oct 12 08:30:45 2016 From: cems at ebi.ac.uk (Charles Short) Date: Wed, 12 Oct 2016 09:30:45 +0100 Subject: [rdo-list] Newton HA galera-ready dependency error In-Reply-To: References: <16532098-169f-0063-ed6f-59531368d955@ebi.ac.uk> <6b370c7f-11f1-b850-00ae-89d6348a4e84@ebi.ac.uk> <87a9220e-0541-b83e-9166-b9c63fceaf8b@ebi.ac.uk> <6bc28bc0-80c8-fae8-1b56-90544abf9801@ebi.ac.uk> <08ac18f7-4ab2-a627-895a-7f16b82c3a92@ebi.ac.uk> <2f6338eb-8346-9a79-cedd-0cdf0d4088dc@ebi.ac.uk> <959b1b0f-da3a-0827-4d3d-f6239c92a735@ebi.ac.uk> Message-ID: <58d11117-fd6b-fb95-7cf7-006696fd143f@ebi.ac.uk> Hi, We noticed something that may be the reason for this patch not working which may be related to the way the Undercloud built the image? - This is difference between the puppet files in the undercloud and puppet in the image: [stack at hh-extcl05-undercloud ~]$ grep mysql_short_node_names /usr/share/openstack-puppet/modules/tripleo/manifests/profile/pacemaker/database/mysql.pp $galera_node_names_lookup = hiera('mysql_short_node_names', hiera('mysql_node_names', $::hostname)) [root at overcloud-controller-1 puppet]# grep mysql_short_node_names /etc/puppet/modules/tripleo/manifests/profile/pacemaker/database/mysql.pp (nothing found) On 12/10/2016 09:09, Marius Cornea wrote: > That's odd. I encountered the same issue and it was caused by missing > this patch. What do you get if you do sudo hiera > mysql_short_node_names on the controller node? > > On Wed, Oct 12, 2016 at 12:48 AM, Charles Short wrote: >> Hi, >> >> puppet-tripleo-5.2.0-0.20161007035759.f32e484.el7.centos.noarch >> >> The patch seems to be already present - >> >> grep short >> /usr/share/openstack-puppet/modules/tripleo/manifests/profile/pacemaker/database/mysql.pp >> >> # short name which is already registered in pacemaker until we get around >> $galera_node_names_lookup = hiera('mysql_short_node_names', >> hiera('mysql_node_names', $::hostname)) >> >> Charles >> >> On 11/10/2016 19:39, Marius Cornea wrote: >>> I think the issue is caused by the addresses in wsrep_cluster_address >>> not matching the pacemaker node names: >>> >>> wsrep_cluster_address=gcomm://overcloud-controller-0.internalapi.localdomain,overcloud-controller-1.internalapi.localdomain,overcloud-controller-2.internalapi.localdomain >>> >>> Could you please confirm what version of puppet-tripleo you've got >>> installed on the overcloud nodes and if it contains the following >>> patch: >>> https://review.openstack.org/#/c/382883/1/manifests/profile/pacemaker/database/mysql.pp >>> >>> Thanks, >>> Marius >>> >>> On Tue, Oct 11, 2016 at 7:42 PM, Charles Short wrote: >>>> Ok install finished with same error >>>> The latest pcs status etc >>>> >>>> http://pastebin.com/ZK683gZe >>>> >>>> >>>> On 11/10/2016 17:35, Charles Short wrote: >>>>> Deployment almost finished...so >>>>> >>>>> >>>>> http://pastebin.com/zE9B19XB >>>>> >>>>> This shows the pcs status as the deployment nears the end, and pcs >>>>> resource show galera >>>>> >>>>> Charles >>>>> >>>>> On 11/10/2016 16:59, Marius Cornea wrote: >>>>>> Great, thanks for checking this. >>>>>> >>>>>> On Tue, Oct 11, 2016 at 5:58 PM, Charles Short wrote: >>>>>>> Currently having more generic deployment issues (no valid host found >>>>>>> etc). >>>>>>> I can work around/solve these. >>>>>>> I don't yet have another stack to analyse, but will do soon. >>>>>>> >>>>>>> Charles >>>>>>> >>>>>>> >>>>>>> On 11/10/2016 16:35, Marius Cornea wrote: >>>>>>>> Did it succeed in bringing the Galera nodes to Master? You can ssh to >>>>>>>> the nodes and run 'pcs resource show galera' even though the >>>>>>>> deployment hasn't finished. I'm interested to see how the >>>>>>>> wsrep_cluster_address is set to see if it's affected by the resource >>>>>>>> agent issue described in >>>>>>>> https://bugs.launchpad.net/tripleo/+bug/1628521 >>>>>>>> >>>>>>>> On Tue, Oct 11, 2016 at 5:18 PM, Charles Short >>>>>>>> wrote: >>>>>>>>> Looks similar to this bug (still waiting on deployment to finish) >>>>>>>>> >>>>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1368214 >>>>>>>>> >>>>>>>>> >>>>>>>>> On 11/10/2016 15:25, Charles Short wrote: >>>>>>>>>> Sorry for the delay. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Just redeploying to make sure I can repeat the same error. Should >>>>>>>>>> not >>>>>>>>>> be >>>>>>>>>> long. >>>>>>>>>> >>>>>>>>>> Charles >>>>>>>>>> >>>>>>>>>> On 11/10/2016 14:24, Marius Cornea wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Could you also please paste the output for 'pcs resource show >>>>>>>>>>> galera', >>>>>>>>>>> it looks that all the galera nodes show up as slaves? >>>>>>>>>>> >>>>>>>>>>> Master/Slave Set: galera-master [galera] >>>>>>>>>>> Slaves: [ overcloud-controller-0 overcloud-controller-1 >>>>>>>>>>> overcloud-controller-2 ] >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> >>>>>>>>>>> On Tue, Oct 11, 2016 at 2:16 PM, Charles Short >>>>>>>>>>> wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> Here you are - >>>>>>>>>>>> >>>>>>>>>>>> - Heat stack error - http://pastebin.com/E8KZa2vE >>>>>>>>>>>> - PCS status - http://pastebin.com/z34gSLq6 >>>>>>>>>>>> - mariadb.log - http://pastebin.com/APFXPBLc >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> >>>>>>>>>>>> Charles >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 11/10/2016 12:07, Marius Cornea wrote: >>>>>>>>>>>>> Hi Charles, >>>>>>>>>>>>> >>>>>>>>>>>>> Could you please paste the output of 'pcs status' ? The log in >>>>>>>>>>>>> /var/log/mariadb/mariadb.log might also be a good indicator. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Oct 11, 2016 at 11:16 AM, Charles Short >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> To add I built my own image from >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2 >>>>>>>>>>>>>> >>>>>>>>>>>>>> as the images in >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://buildlogs.centos.org/centos/7/cloud/x86_64/tripleo_images/newton/delorean/ >>>>>>>>>>>>>> caused sporadic ramdisk loading errors (hung at x% loaded on >>>>>>>>>>>>>> boot) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Does my image now need to be customised in any way for HA to >>>>>>>>>>>>>> work? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Charles >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 11/10/2016 09:55, Charles Short wrote: >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I am installing Newton with TripleO on baremetal HP blades. >>>>>>>>>>>>>>> I can deploy a single controller stack overcloud no problem, >>>>>>>>>>>>>>> however >>>>>>>>>>>>>>> when >>>>>>>>>>>>>>> I choose three controllers the deployment fails (including >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml) >>>>>>>>>>>>>>> . >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The heat stack error first complains "Dependency >>>>>>>>>>>>>>> Exec[galera-ready] >>>>>>>>>>>>>>> has >>>>>>>>>>>>>>> failures" which in turn causes lots of other errors. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I have deployed Liberty and Mitaka successfully in the past on >>>>>>>>>>>>>>> baremetal >>>>>>>>>>>>>>> with three controllers, and this is the first time I have seen >>>>>>>>>>>>>>> this >>>>>>>>>>>>>>> error. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Charles >>>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Charles Short >>>>>>>>>>>>>> Cloud Engineer >>>>>>>>>>>>>> Virtualization and Cloud Team >>>>>>>>>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>>>>>>>>> Tel: +44 (0)1223 494205 >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Charles Short >>>>>>>>>>>> Cloud Engineer >>>>>>>>>>>> Virtualization and Cloud Team >>>>>>>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>>>>>>> Tel: +44 (0)1223 494205 >>>>>>>>>>>> >>>>>>>>> -- >>>>>>>>> Charles Short >>>>>>>>> Cloud Engineer >>>>>>>>> Virtualization and Cloud Team >>>>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>>>> Tel: +44 (0)1223 494205 >>>>>>>>> >>>>>>> -- >>>>>>> Charles Short >>>>>>> Cloud Engineer >>>>>>> Virtualization and Cloud Team >>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>> Tel: +44 (0)1223 494205 >>>>>>> >>>> -- >>>> Charles Short >>>> Cloud Engineer >>>> Virtualization and Cloud Team >>>> European Bioinformatics Institute (EMBL-EBI) >>>> Tel: +44 (0)1223 494205 >>>> >> -- >> Charles Short >> Cloud Engineer >> Virtualization and Cloud Team >> European Bioinformatics Institute (EMBL-EBI) >> Tel: +44 (0)1223 494205 >> -- Charles Short Cloud Engineer Virtualization and Cloud Team European Bioinformatics Institute (EMBL-EBI) Tel: +44 (0)1223 494205 From cems at ebi.ac.uk Wed Oct 12 08:33:28 2016 From: cems at ebi.ac.uk (Charles Short) Date: Wed, 12 Oct 2016 09:33:28 +0100 Subject: [rdo-list] Newton HA galera-ready dependency error In-Reply-To: References: <16532098-169f-0063-ed6f-59531368d955@ebi.ac.uk> <6b370c7f-11f1-b850-00ae-89d6348a4e84@ebi.ac.uk> <87a9220e-0541-b83e-9166-b9c63fceaf8b@ebi.ac.uk> <6bc28bc0-80c8-fae8-1b56-90544abf9801@ebi.ac.uk> <08ac18f7-4ab2-a627-895a-7f16b82c3a92@ebi.ac.uk> <2f6338eb-8346-9a79-cedd-0cdf0d4088dc@ebi.ac.uk> <959b1b0f-da3a-0827-4d3d-f6239c92a735@ebi.ac.uk> Message-ID: <4871691a-e0b0-4282-2ed6-269b18ed181d@ebi.ac.uk> [heat-admin at overcloud-controller-0 ~]$ sudo hiera mysql_short_node_names ["overcloud-controller-0", "overcloud-controller-1", "overcloud-controller-2"] On 12/10/2016 09:09, Marius Cornea wrote: > That's odd. I encountered the same issue and it was caused by missing > this patch. What do you get if you do sudo hiera > mysql_short_node_names on the controller node? > > On Wed, Oct 12, 2016 at 12:48 AM, Charles Short wrote: >> Hi, >> >> puppet-tripleo-5.2.0-0.20161007035759.f32e484.el7.centos.noarch >> >> The patch seems to be already present - >> >> grep short >> /usr/share/openstack-puppet/modules/tripleo/manifests/profile/pacemaker/database/mysql.pp >> >> # short name which is already registered in pacemaker until we get around >> $galera_node_names_lookup = hiera('mysql_short_node_names', >> hiera('mysql_node_names', $::hostname)) >> >> Charles >> >> On 11/10/2016 19:39, Marius Cornea wrote: >>> I think the issue is caused by the addresses in wsrep_cluster_address >>> not matching the pacemaker node names: >>> >>> wsrep_cluster_address=gcomm://overcloud-controller-0.internalapi.localdomain,overcloud-controller-1.internalapi.localdomain,overcloud-controller-2.internalapi.localdomain >>> >>> Could you please confirm what version of puppet-tripleo you've got >>> installed on the overcloud nodes and if it contains the following >>> patch: >>> https://review.openstack.org/#/c/382883/1/manifests/profile/pacemaker/database/mysql.pp >>> >>> Thanks, >>> Marius >>> >>> On Tue, Oct 11, 2016 at 7:42 PM, Charles Short wrote: >>>> Ok install finished with same error >>>> The latest pcs status etc >>>> >>>> http://pastebin.com/ZK683gZe >>>> >>>> >>>> On 11/10/2016 17:35, Charles Short wrote: >>>>> Deployment almost finished...so >>>>> >>>>> >>>>> http://pastebin.com/zE9B19XB >>>>> >>>>> This shows the pcs status as the deployment nears the end, and pcs >>>>> resource show galera >>>>> >>>>> Charles >>>>> >>>>> On 11/10/2016 16:59, Marius Cornea wrote: >>>>>> Great, thanks for checking this. >>>>>> >>>>>> On Tue, Oct 11, 2016 at 5:58 PM, Charles Short wrote: >>>>>>> Currently having more generic deployment issues (no valid host found >>>>>>> etc). >>>>>>> I can work around/solve these. >>>>>>> I don't yet have another stack to analyse, but will do soon. >>>>>>> >>>>>>> Charles >>>>>>> >>>>>>> >>>>>>> On 11/10/2016 16:35, Marius Cornea wrote: >>>>>>>> Did it succeed in bringing the Galera nodes to Master? You can ssh to >>>>>>>> the nodes and run 'pcs resource show galera' even though the >>>>>>>> deployment hasn't finished. I'm interested to see how the >>>>>>>> wsrep_cluster_address is set to see if it's affected by the resource >>>>>>>> agent issue described in >>>>>>>> https://bugs.launchpad.net/tripleo/+bug/1628521 >>>>>>>> >>>>>>>> On Tue, Oct 11, 2016 at 5:18 PM, Charles Short >>>>>>>> wrote: >>>>>>>>> Looks similar to this bug (still waiting on deployment to finish) >>>>>>>>> >>>>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1368214 >>>>>>>>> >>>>>>>>> >>>>>>>>> On 11/10/2016 15:25, Charles Short wrote: >>>>>>>>>> Sorry for the delay. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Just redeploying to make sure I can repeat the same error. Should >>>>>>>>>> not >>>>>>>>>> be >>>>>>>>>> long. >>>>>>>>>> >>>>>>>>>> Charles >>>>>>>>>> >>>>>>>>>> On 11/10/2016 14:24, Marius Cornea wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Could you also please paste the output for 'pcs resource show >>>>>>>>>>> galera', >>>>>>>>>>> it looks that all the galera nodes show up as slaves? >>>>>>>>>>> >>>>>>>>>>> Master/Slave Set: galera-master [galera] >>>>>>>>>>> Slaves: [ overcloud-controller-0 overcloud-controller-1 >>>>>>>>>>> overcloud-controller-2 ] >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> >>>>>>>>>>> On Tue, Oct 11, 2016 at 2:16 PM, Charles Short >>>>>>>>>>> wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> Here you are - >>>>>>>>>>>> >>>>>>>>>>>> - Heat stack error - http://pastebin.com/E8KZa2vE >>>>>>>>>>>> - PCS status - http://pastebin.com/z34gSLq6 >>>>>>>>>>>> - mariadb.log - http://pastebin.com/APFXPBLc >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> >>>>>>>>>>>> Charles >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 11/10/2016 12:07, Marius Cornea wrote: >>>>>>>>>>>>> Hi Charles, >>>>>>>>>>>>> >>>>>>>>>>>>> Could you please paste the output of 'pcs status' ? The log in >>>>>>>>>>>>> /var/log/mariadb/mariadb.log might also be a good indicator. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Oct 11, 2016 at 11:16 AM, Charles Short >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> To add I built my own image from >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2 >>>>>>>>>>>>>> >>>>>>>>>>>>>> as the images in >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://buildlogs.centos.org/centos/7/cloud/x86_64/tripleo_images/newton/delorean/ >>>>>>>>>>>>>> caused sporadic ramdisk loading errors (hung at x% loaded on >>>>>>>>>>>>>> boot) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Does my image now need to be customised in any way for HA to >>>>>>>>>>>>>> work? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Charles >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 11/10/2016 09:55, Charles Short wrote: >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I am installing Newton with TripleO on baremetal HP blades. >>>>>>>>>>>>>>> I can deploy a single controller stack overcloud no problem, >>>>>>>>>>>>>>> however >>>>>>>>>>>>>>> when >>>>>>>>>>>>>>> I choose three controllers the deployment fails (including >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml) >>>>>>>>>>>>>>> . >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The heat stack error first complains "Dependency >>>>>>>>>>>>>>> Exec[galera-ready] >>>>>>>>>>>>>>> has >>>>>>>>>>>>>>> failures" which in turn causes lots of other errors. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I have deployed Liberty and Mitaka successfully in the past on >>>>>>>>>>>>>>> baremetal >>>>>>>>>>>>>>> with three controllers, and this is the first time I have seen >>>>>>>>>>>>>>> this >>>>>>>>>>>>>>> error. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Charles >>>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Charles Short >>>>>>>>>>>>>> Cloud Engineer >>>>>>>>>>>>>> Virtualization and Cloud Team >>>>>>>>>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>>>>>>>>> Tel: +44 (0)1223 494205 >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Charles Short >>>>>>>>>>>> Cloud Engineer >>>>>>>>>>>> Virtualization and Cloud Team >>>>>>>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>>>>>>> Tel: +44 (0)1223 494205 >>>>>>>>>>>> >>>>>>>>> -- >>>>>>>>> Charles Short >>>>>>>>> Cloud Engineer >>>>>>>>> Virtualization and Cloud Team >>>>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>>>> Tel: +44 (0)1223 494205 >>>>>>>>> >>>>>>> -- >>>>>>> Charles Short >>>>>>> Cloud Engineer >>>>>>> Virtualization and Cloud Team >>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>> Tel: +44 (0)1223 494205 >>>>>>> >>>> -- >>>> Charles Short >>>> Cloud Engineer >>>> Virtualization and Cloud Team >>>> European Bioinformatics Institute (EMBL-EBI) >>>> Tel: +44 (0)1223 494205 >>>> >> -- >> Charles Short >> Cloud Engineer >> Virtualization and Cloud Team >> European Bioinformatics Institute (EMBL-EBI) >> Tel: +44 (0)1223 494205 >> -- Charles Short Cloud Engineer Virtualization and Cloud Team European Bioinformatics Institute (EMBL-EBI) Tel: +44 (0)1223 494205 From marius at remote-lab.net Wed Oct 12 08:44:50 2016 From: marius at remote-lab.net (Marius Cornea) Date: Wed, 12 Oct 2016 10:44:50 +0200 Subject: [rdo-list] Newton HA galera-ready dependency error In-Reply-To: <58d11117-fd6b-fb95-7cf7-006696fd143f@ebi.ac.uk> References: <16532098-169f-0063-ed6f-59531368d955@ebi.ac.uk> <6b370c7f-11f1-b850-00ae-89d6348a4e84@ebi.ac.uk> <87a9220e-0541-b83e-9166-b9c63fceaf8b@ebi.ac.uk> <6bc28bc0-80c8-fae8-1b56-90544abf9801@ebi.ac.uk> <08ac18f7-4ab2-a627-895a-7f16b82c3a92@ebi.ac.uk> <2f6338eb-8346-9a79-cedd-0cdf0d4088dc@ebi.ac.uk> <959b1b0f-da3a-0827-4d3d-f6239c92a735@ebi.ac.uk> <58d11117-fd6b-fb95-7cf7-006696fd143f@ebi.ac.uk> Message-ID: Oh, that explains it. It looks that the overcloud image doesn't contain the patch. I'm not familiar with the image build process but according to the docs[1] I think the packages get installed from the repo specified by export DELOREAN_TRUNK_REPO so maybe you should try to rebuild the image and use the same repo as the one set on the undercloud. [1] http://docs.openstack.org/developer/tripleo-docs/basic_deployment/basic_deployment_cli.html On Wed, Oct 12, 2016 at 10:30 AM, Charles Short wrote: > Hi, > > We noticed something that may be the reason for this patch not working which > may be related to the way the Undercloud built the image? - > > This is difference between the puppet files in the undercloud and > puppet in the image: > > [stack at hh-extcl05-undercloud ~]$ grep mysql_short_node_names > /usr/share/openstack-puppet/modules/tripleo/manifests/profile/pacemaker/database/mysql.pp > > $galera_node_names_lookup = hiera('mysql_short_node_names', > hiera('mysql_node_names', $::hostname)) > > [root at overcloud-controller-1 puppet]# grep mysql_short_node_names > /etc/puppet/modules/tripleo/manifests/profile/pacemaker/database/mysql.pp > > (nothing found) > > > On 12/10/2016 09:09, Marius Cornea wrote: >> >> That's odd. I encountered the same issue and it was caused by missing >> this patch. What do you get if you do sudo hiera >> mysql_short_node_names on the controller node? >> >> On Wed, Oct 12, 2016 at 12:48 AM, Charles Short wrote: >>> >>> Hi, >>> >>> puppet-tripleo-5.2.0-0.20161007035759.f32e484.el7.centos.noarch >>> >>> The patch seems to be already present - >>> >>> grep short >>> >>> /usr/share/openstack-puppet/modules/tripleo/manifests/profile/pacemaker/database/mysql.pp >>> >>> # short name which is already registered in pacemaker until we get >>> around >>> $galera_node_names_lookup = hiera('mysql_short_node_names', >>> hiera('mysql_node_names', $::hostname)) >>> >>> Charles >>> >>> On 11/10/2016 19:39, Marius Cornea wrote: >>>> >>>> I think the issue is caused by the addresses in wsrep_cluster_address >>>> not matching the pacemaker node names: >>>> >>>> >>>> wsrep_cluster_address=gcomm://overcloud-controller-0.internalapi.localdomain,overcloud-controller-1.internalapi.localdomain,overcloud-controller-2.internalapi.localdomain >>>> >>>> Could you please confirm what version of puppet-tripleo you've got >>>> installed on the overcloud nodes and if it contains the following >>>> patch: >>>> >>>> https://review.openstack.org/#/c/382883/1/manifests/profile/pacemaker/database/mysql.pp >>>> >>>> Thanks, >>>> Marius >>>> >>>> On Tue, Oct 11, 2016 at 7:42 PM, Charles Short wrote: >>>>> >>>>> Ok install finished with same error >>>>> The latest pcs status etc >>>>> >>>>> http://pastebin.com/ZK683gZe >>>>> >>>>> >>>>> On 11/10/2016 17:35, Charles Short wrote: >>>>>> >>>>>> Deployment almost finished...so >>>>>> >>>>>> >>>>>> http://pastebin.com/zE9B19XB >>>>>> >>>>>> This shows the pcs status as the deployment nears the end, and pcs >>>>>> resource show galera >>>>>> >>>>>> Charles >>>>>> >>>>>> On 11/10/2016 16:59, Marius Cornea wrote: >>>>>>> >>>>>>> Great, thanks for checking this. >>>>>>> >>>>>>> On Tue, Oct 11, 2016 at 5:58 PM, Charles Short >>>>>>> wrote: >>>>>>>> >>>>>>>> Currently having more generic deployment issues (no valid host found >>>>>>>> etc). >>>>>>>> I can work around/solve these. >>>>>>>> I don't yet have another stack to analyse, but will do soon. >>>>>>>> >>>>>>>> Charles >>>>>>>> >>>>>>>> >>>>>>>> On 11/10/2016 16:35, Marius Cornea wrote: >>>>>>>>> >>>>>>>>> Did it succeed in bringing the Galera nodes to Master? You can ssh >>>>>>>>> to >>>>>>>>> the nodes and run 'pcs resource show galera' even though the >>>>>>>>> deployment hasn't finished. I'm interested to see how the >>>>>>>>> wsrep_cluster_address is set to see if it's affected by the >>>>>>>>> resource >>>>>>>>> agent issue described in >>>>>>>>> https://bugs.launchpad.net/tripleo/+bug/1628521 >>>>>>>>> >>>>>>>>> On Tue, Oct 11, 2016 at 5:18 PM, Charles Short >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Looks similar to this bug (still waiting on deployment to finish) >>>>>>>>>> >>>>>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1368214 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 11/10/2016 15:25, Charles Short wrote: >>>>>>>>>>> >>>>>>>>>>> Sorry for the delay. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Just redeploying to make sure I can repeat the same error. Should >>>>>>>>>>> not >>>>>>>>>>> be >>>>>>>>>>> long. >>>>>>>>>>> >>>>>>>>>>> Charles >>>>>>>>>>> >>>>>>>>>>> On 11/10/2016 14:24, Marius Cornea wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> Could you also please paste the output for 'pcs resource show >>>>>>>>>>>> galera', >>>>>>>>>>>> it looks that all the galera nodes show up as slaves? >>>>>>>>>>>> >>>>>>>>>>>> Master/Slave Set: galera-master [galera] >>>>>>>>>>>> Slaves: [ overcloud-controller-0 >>>>>>>>>>>> overcloud-controller-1 >>>>>>>>>>>> overcloud-controller-2 ] >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Oct 11, 2016 at 2:16 PM, Charles Short >>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> Here you are - >>>>>>>>>>>>> >>>>>>>>>>>>> - Heat stack error - http://pastebin.com/E8KZa2vE >>>>>>>>>>>>> - PCS status - http://pastebin.com/z34gSLq6 >>>>>>>>>>>>> - mariadb.log - http://pastebin.com/APFXPBLc >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> >>>>>>>>>>>>> Charles >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 11/10/2016 12:07, Marius Cornea wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Charles, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Could you please paste the output of 'pcs status' ? The log in >>>>>>>>>>>>>> /var/log/mariadb/mariadb.log might also be a good indicator. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tue, Oct 11, 2016 at 11:16 AM, Charles Short >>>>>>>>>>>>>> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> To add I built my own image from >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> as the images in >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://buildlogs.centos.org/centos/7/cloud/x86_64/tripleo_images/newton/delorean/ >>>>>>>>>>>>>>> caused sporadic ramdisk loading errors (hung at x% loaded on >>>>>>>>>>>>>>> boot) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Does my image now need to be customised in any way for HA to >>>>>>>>>>>>>>> work? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Charles >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 11/10/2016 09:55, Charles Short wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I am installing Newton with TripleO on baremetal HP blades. >>>>>>>>>>>>>>>> I can deploy a single controller stack overcloud no problem, >>>>>>>>>>>>>>>> however >>>>>>>>>>>>>>>> when >>>>>>>>>>>>>>>> I choose three controllers the deployment fails (including >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml) >>>>>>>>>>>>>>>> . >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The heat stack error first complains "Dependency >>>>>>>>>>>>>>>> Exec[galera-ready] >>>>>>>>>>>>>>>> has >>>>>>>>>>>>>>>> failures" which in turn causes lots of other errors. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I have deployed Liberty and Mitaka successfully in the past >>>>>>>>>>>>>>>> on >>>>>>>>>>>>>>>> baremetal >>>>>>>>>>>>>>>> with three controllers, and this is the first time I have >>>>>>>>>>>>>>>> seen >>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>> error. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Charles >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Charles Short >>>>>>>>>>>>>>> Cloud Engineer >>>>>>>>>>>>>>> Virtualization and Cloud Team >>>>>>>>>>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>>>>>>>>>> Tel: +44 (0)1223 494205 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> 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 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Charles Short >>>>>>>>>>>>> Cloud Engineer >>>>>>>>>>>>> Virtualization and Cloud Team >>>>>>>>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>>>>>>>> Tel: +44 (0)1223 494205 >>>>>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Charles Short >>>>>>>>>> Cloud Engineer >>>>>>>>>> Virtualization and Cloud Team >>>>>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>>>>> Tel: +44 (0)1223 494205 >>>>>>>>>> >>>>>>>> -- >>>>>>>> Charles Short >>>>>>>> Cloud Engineer >>>>>>>> Virtualization and Cloud Team >>>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>>> Tel: +44 (0)1223 494205 >>>>>>>> >>>>> -- >>>>> Charles Short >>>>> Cloud Engineer >>>>> Virtualization and Cloud Team >>>>> European Bioinformatics Institute (EMBL-EBI) >>>>> Tel: +44 (0)1223 494205 >>>>> >>> -- >>> Charles Short >>> Cloud Engineer >>> Virtualization and Cloud Team >>> European Bioinformatics Institute (EMBL-EBI) >>> Tel: +44 (0)1223 494205 >>> > > -- > Charles Short > Cloud Engineer > Virtualization and Cloud Team > European Bioinformatics Institute (EMBL-EBI) > Tel: +44 (0)1223 494205 > From dciabrin at redhat.com Wed Oct 12 08:53:26 2016 From: dciabrin at redhat.com (Damien Ciabrini) Date: Wed, 12 Oct 2016 04:53:26 -0400 (EDT) Subject: [rdo-list] Newton HA galera-ready dependency error In-Reply-To: <4871691a-e0b0-4282-2ed6-269b18ed181d@ebi.ac.uk> References: <08ac18f7-4ab2-a627-895a-7f16b82c3a92@ebi.ac.uk> <2f6338eb-8346-9a79-cedd-0cdf0d4088dc@ebi.ac.uk> <959b1b0f-da3a-0827-4d3d-f6239c92a735@ebi.ac.uk> <4871691a-e0b0-4282-2ed6-269b18ed181d@ebi.ac.uk> Message-ID: <563616240.5289490.1476262406262.JavaMail.zimbra@redhat.com> Hi Charles, >From http://pastebin.com/ZK683gZe, I can see that the gcomm address doesn't match pacemaker's node name. Could it be that the initial deployment was done with prior to having the version of puppet-tripleo installed? If you want to unblock the galera resource without reinstalling the stack you could do: pcs resource update galera additional_parameters=--open-files-limit=16384 enable_creation=true wsrep_cluster_address=gcomm://overcloud-controller-0,overcloud-controller-1,overcloud-controller-2 ----- Original Message ----- > [heat-admin at overcloud-controller-0 ~]$ sudo hiera mysql_short_node_names > ["overcloud-controller-0", "overcloud-controller-1", > "overcloud-controller-2"] > > On 12/10/2016 09:09, Marius Cornea wrote: > > That's odd. I encountered the same issue and it was caused by missing > > this patch. What do you get if you do sudo hiera > > mysql_short_node_names on the controller node? > > > > On Wed, Oct 12, 2016 at 12:48 AM, Charles Short wrote: > >> Hi, > >> > >> puppet-tripleo-5.2.0-0.20161007035759.f32e484.el7.centos.noarch > >> > >> The patch seems to be already present - > >> > >> grep short > >> /usr/share/openstack-puppet/modules/tripleo/manifests/profile/pacemaker/database/mysql.pp > >> > >> # short name which is already registered in pacemaker until we get > >> around > >> $galera_node_names_lookup = hiera('mysql_short_node_names', > >> hiera('mysql_node_names', $::hostname)) > >> > >> Charles > >> > >> On 11/10/2016 19:39, Marius Cornea wrote: > >>> I think the issue is caused by the addresses in wsrep_cluster_address > >>> not matching the pacemaker node names: > >>> > >>> wsrep_cluster_address=gcomm://overcloud-controller-0.internalapi.localdomain,overcloud-controller-1.internalapi.localdomain,overcloud-controller-2.internalapi.localdomain > >>> > >>> Could you please confirm what version of puppet-tripleo you've got > >>> installed on the overcloud nodes and if it contains the following > >>> patch: > >>> https://review.openstack.org/#/c/382883/1/manifests/profile/pacemaker/database/mysql.pp > >>> > >>> Thanks, > >>> Marius > >>> > >>> On Tue, Oct 11, 2016 at 7:42 PM, Charles Short wrote: > >>>> Ok install finished with same error > >>>> The latest pcs status etc > >>>> > >>>> http://pastebin.com/ZK683gZe > >>>> > >>>> > >>>> On 11/10/2016 17:35, Charles Short wrote: > >>>>> Deployment almost finished...so > >>>>> > >>>>> > >>>>> http://pastebin.com/zE9B19XB > >>>>> > >>>>> This shows the pcs status as the deployment nears the end, and pcs > >>>>> resource show galera > >>>>> > >>>>> Charles > >>>>> > >>>>> On 11/10/2016 16:59, Marius Cornea wrote: > >>>>>> Great, thanks for checking this. > >>>>>> > >>>>>> On Tue, Oct 11, 2016 at 5:58 PM, Charles Short wrote: > >>>>>>> Currently having more generic deployment issues (no valid host found > >>>>>>> etc). > >>>>>>> I can work around/solve these. > >>>>>>> I don't yet have another stack to analyse, but will do soon. > >>>>>>> > >>>>>>> Charles > >>>>>>> > >>>>>>> > >>>>>>> On 11/10/2016 16:35, Marius Cornea wrote: > >>>>>>>> Did it succeed in bringing the Galera nodes to Master? You can ssh > >>>>>>>> to > >>>>>>>> the nodes and run 'pcs resource show galera' even though the > >>>>>>>> deployment hasn't finished. I'm interested to see how the > >>>>>>>> wsrep_cluster_address is set to see if it's affected by the resource > >>>>>>>> agent issue described in > >>>>>>>> https://bugs.launchpad.net/tripleo/+bug/1628521 > >>>>>>>> > >>>>>>>> On Tue, Oct 11, 2016 at 5:18 PM, Charles Short > >>>>>>>> wrote: > >>>>>>>>> Looks similar to this bug (still waiting on deployment to finish) > >>>>>>>>> > >>>>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1368214 > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On 11/10/2016 15:25, Charles Short wrote: > >>>>>>>>>> Sorry for the delay. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Just redeploying to make sure I can repeat the same error. Should > >>>>>>>>>> not > >>>>>>>>>> be > >>>>>>>>>> long. > >>>>>>>>>> > >>>>>>>>>> Charles > >>>>>>>>>> > >>>>>>>>>> On 11/10/2016 14:24, Marius Cornea wrote: > >>>>>>>>>>> Hi, > >>>>>>>>>>> > >>>>>>>>>>> Could you also please paste the output for 'pcs resource show > >>>>>>>>>>> galera', > >>>>>>>>>>> it looks that all the galera nodes show up as slaves? > >>>>>>>>>>> > >>>>>>>>>>> Master/Slave Set: galera-master [galera] > >>>>>>>>>>> Slaves: [ overcloud-controller-0 overcloud-controller-1 > >>>>>>>>>>> overcloud-controller-2 ] > >>>>>>>>>>> > >>>>>>>>>>> Thanks > >>>>>>>>>>> > >>>>>>>>>>> On Tue, Oct 11, 2016 at 2:16 PM, Charles Short > >>>>>>>>>>> wrote: > >>>>>>>>>>>> Hi, > >>>>>>>>>>>> > >>>>>>>>>>>> Here you are - > >>>>>>>>>>>> > >>>>>>>>>>>> - Heat stack error - http://pastebin.com/E8KZa2vE > >>>>>>>>>>>> - PCS status - http://pastebin.com/z34gSLq6 > >>>>>>>>>>>> - mariadb.log - http://pastebin.com/APFXPBLc > >>>>>>>>>>>> > >>>>>>>>>>>> Thanks > >>>>>>>>>>>> > >>>>>>>>>>>> Charles > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> On 11/10/2016 12:07, Marius Cornea wrote: > >>>>>>>>>>>>> Hi Charles, > >>>>>>>>>>>>> > >>>>>>>>>>>>> Could you please paste the output of 'pcs status' ? The log in > >>>>>>>>>>>>> /var/log/mariadb/mariadb.log might also be a good indicator. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> On Tue, Oct 11, 2016 at 11:16 AM, Charles Short > >>>>>>>>>>>>> > >>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>> To add I built my own image from > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2 > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> as the images in > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> http://buildlogs.centos.org/centos/7/cloud/x86_64/tripleo_images/newton/delorean/ > >>>>>>>>>>>>>> caused sporadic ramdisk loading errors (hung at x% loaded on > >>>>>>>>>>>>>> boot) > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Does my image now need to be customised in any way for HA to > >>>>>>>>>>>>>> work? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Charles > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On 11/10/2016 09:55, Charles Short wrote: > >>>>>>>>>>>>>>> Hi, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I am installing Newton with TripleO on baremetal HP blades. > >>>>>>>>>>>>>>> I can deploy a single controller stack overcloud no problem, > >>>>>>>>>>>>>>> however > >>>>>>>>>>>>>>> when > >>>>>>>>>>>>>>> I choose three controllers the deployment fails (including > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml) > >>>>>>>>>>>>>>> . > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> The heat stack error first complains "Dependency > >>>>>>>>>>>>>>> Exec[galera-ready] > >>>>>>>>>>>>>>> has > >>>>>>>>>>>>>>> failures" which in turn causes lots of other errors. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I have deployed Liberty and Mitaka successfully in the past > >>>>>>>>>>>>>>> on > >>>>>>>>>>>>>>> baremetal > >>>>>>>>>>>>>>> with three controllers, and this is the first time I have > >>>>>>>>>>>>>>> seen > >>>>>>>>>>>>>>> this > >>>>>>>>>>>>>>> error. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Charles > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> -- > >>>>>>>>>>>>>> Charles Short > >>>>>>>>>>>>>> Cloud Engineer > >>>>>>>>>>>>>> Virtualization and Cloud Team > >>>>>>>>>>>>>> European Bioinformatics Institute (EMBL-EBI) > >>>>>>>>>>>>>> Tel: +44 (0)1223 494205 > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>>>> 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 > >>>>>>>>>>>> > >>>>>>>>>>>> -- > >>>>>>>>>>>> Charles Short > >>>>>>>>>>>> Cloud Engineer > >>>>>>>>>>>> Virtualization and Cloud Team > >>>>>>>>>>>> European Bioinformatics Institute (EMBL-EBI) > >>>>>>>>>>>> Tel: +44 (0)1223 494205 > >>>>>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> Charles Short > >>>>>>>>> Cloud Engineer > >>>>>>>>> Virtualization and Cloud Team > >>>>>>>>> European Bioinformatics Institute (EMBL-EBI) > >>>>>>>>> Tel: +44 (0)1223 494205 > >>>>>>>>> > >>>>>>> -- > >>>>>>> Charles Short > >>>>>>> Cloud Engineer > >>>>>>> Virtualization and Cloud Team > >>>>>>> European Bioinformatics Institute (EMBL-EBI) > >>>>>>> Tel: +44 (0)1223 494205 > >>>>>>> > >>>> -- > >>>> Charles Short > >>>> Cloud Engineer > >>>> Virtualization and Cloud Team > >>>> European Bioinformatics Institute (EMBL-EBI) > >>>> Tel: +44 (0)1223 494205 > >>>> > >> -- > >> Charles Short > >> Cloud Engineer > >> Virtualization and Cloud Team > >> European Bioinformatics Institute (EMBL-EBI) > >> Tel: +44 (0)1223 494205 > >> > > -- > Charles Short > Cloud Engineer > Virtualization and Cloud Team > European Bioinformatics Institute (EMBL-EBI) > Tel: +44 (0)1223 494205 > > _______________________________________________ > 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 Wed Oct 12 09:12:24 2016 From: apevec at redhat.com (Alan Pevec) Date: Wed, 12 Oct 2016 11:12:24 +0200 Subject: [rdo-list] networking-cisco in RDO Message-ID: On Sat, Oct 8, 2016 at 1:18 AM, Ha?kel wrote: > one requirement to remain in RDO is to have an active maintainer to > update/fix issues in packages. > We're also looking for upstream developpers to collaborate with us on > the release management side. > > In networking-arista, some issues we had to deal with: > - no stable/newton branches > - no stable tarballs > https://tarballs.openstack.org/networking-arista/ > > As a release wrangler, I can help maintainers to get things released > in time, but if there's no releases, I have no clue on what to ship in > our repositories. > We're no network experts, we have no networking-arista specific CI > jobs running, and we have a whole distro to maintain, so unless > someone steps up to maintain it, best choice for us is to drop it > rather than shipping half-broken packages. Off couse, we're looking > forward working with upstream maintainers to ship OpenStack packages > that reflects positively on both downstream/upstream. We have the similar situation with networking-cisco. We do have designated maintainers in rdoinfo: maintainers: - openstack-networking at cisco.com - brdemers at cisco.com But stable/newton and mitaka branches do not exist and there wasn't a release since June: https://github.com/openstack/networking-cisco/releases Since we didn't get any new input for RDO Newton we are packaging latest git snapshot[1] but that's a blind guess since networking-cisco is not covered in RDO CI. Also since stable/mitaka is missing we had to pin to 3.2.0 in RDO Mitaka[2] We'd welcome guidance from designated maintainers about release plans (is it going to be branchless like Tempest?) and to explore 3rd party CI setup on review.rdoproject.org for networking-cisco reviews. Cheers, Alan [1] https://review.rdoproject.org/r/3233 [2] https://review.rdoproject.org/r/3143 From cems at ebi.ac.uk Wed Oct 12 09:28:18 2016 From: cems at ebi.ac.uk (Charles Short) Date: Wed, 12 Oct 2016 10:28:18 +0100 Subject: [rdo-list] Newton HA galera-ready dependency error In-Reply-To: References: <16532098-169f-0063-ed6f-59531368d955@ebi.ac.uk> <6b370c7f-11f1-b850-00ae-89d6348a4e84@ebi.ac.uk> <87a9220e-0541-b83e-9166-b9c63fceaf8b@ebi.ac.uk> <6bc28bc0-80c8-fae8-1b56-90544abf9801@ebi.ac.uk> <08ac18f7-4ab2-a627-895a-7f16b82c3a92@ebi.ac.uk> <2f6338eb-8346-9a79-cedd-0cdf0d4088dc@ebi.ac.uk> <959b1b0f-da3a-0827-4d3d-f6239c92a735@ebi.ac.uk> <58d11117-fd6b-fb95-7cf7-006696fd143f@ebi.ac.uk> Message-ID: Hi, Ok, I will rebuild using the undercloud repo and report back. Thanks for your help Charles On 12/10/2016 09:44, Marius Cornea wrote: > Oh, that explains it. It looks that the overcloud image doesn't > contain the patch. > > I'm not familiar with the image build process but according to the > docs[1] I think the packages get installed from the repo specified by > export DELOREAN_TRUNK_REPO so maybe you should try to rebuild the > image and use the same repo as the one set on the undercloud. > > [1] http://docs.openstack.org/developer/tripleo-docs/basic_deployment/basic_deployment_cli.html > > On Wed, Oct 12, 2016 at 10:30 AM, Charles Short wrote: >> Hi, >> >> We noticed something that may be the reason for this patch not working which >> may be related to the way the Undercloud built the image? - >> >> This is difference between the puppet files in the undercloud and >> puppet in the image: >> >> [stack at hh-extcl05-undercloud ~]$ grep mysql_short_node_names >> /usr/share/openstack-puppet/modules/tripleo/manifests/profile/pacemaker/database/mysql.pp >> >> $galera_node_names_lookup = hiera('mysql_short_node_names', >> hiera('mysql_node_names', $::hostname)) >> >> [root at overcloud-controller-1 puppet]# grep mysql_short_node_names >> /etc/puppet/modules/tripleo/manifests/profile/pacemaker/database/mysql.pp >> >> (nothing found) >> >> >> On 12/10/2016 09:09, Marius Cornea wrote: >>> That's odd. I encountered the same issue and it was caused by missing >>> this patch. What do you get if you do sudo hiera >>> mysql_short_node_names on the controller node? >>> >>> On Wed, Oct 12, 2016 at 12:48 AM, Charles Short wrote: >>>> Hi, >>>> >>>> puppet-tripleo-5.2.0-0.20161007035759.f32e484.el7.centos.noarch >>>> >>>> The patch seems to be already present - >>>> >>>> grep short >>>> >>>> /usr/share/openstack-puppet/modules/tripleo/manifests/profile/pacemaker/database/mysql.pp >>>> >>>> # short name which is already registered in pacemaker until we get >>>> around >>>> $galera_node_names_lookup = hiera('mysql_short_node_names', >>>> hiera('mysql_node_names', $::hostname)) >>>> >>>> Charles >>>> >>>> On 11/10/2016 19:39, Marius Cornea wrote: >>>>> I think the issue is caused by the addresses in wsrep_cluster_address >>>>> not matching the pacemaker node names: >>>>> >>>>> >>>>> wsrep_cluster_address=gcomm://overcloud-controller-0.internalapi.localdomain,overcloud-controller-1.internalapi.localdomain,overcloud-controller-2.internalapi.localdomain >>>>> >>>>> Could you please confirm what version of puppet-tripleo you've got >>>>> installed on the overcloud nodes and if it contains the following >>>>> patch: >>>>> >>>>> https://review.openstack.org/#/c/382883/1/manifests/profile/pacemaker/database/mysql.pp >>>>> >>>>> Thanks, >>>>> Marius >>>>> >>>>> On Tue, Oct 11, 2016 at 7:42 PM, Charles Short wrote: >>>>>> Ok install finished with same error >>>>>> The latest pcs status etc >>>>>> >>>>>> http://pastebin.com/ZK683gZe >>>>>> >>>>>> >>>>>> On 11/10/2016 17:35, Charles Short wrote: >>>>>>> Deployment almost finished...so >>>>>>> >>>>>>> >>>>>>> http://pastebin.com/zE9B19XB >>>>>>> >>>>>>> This shows the pcs status as the deployment nears the end, and pcs >>>>>>> resource show galera >>>>>>> >>>>>>> Charles >>>>>>> >>>>>>> On 11/10/2016 16:59, Marius Cornea wrote: >>>>>>>> Great, thanks for checking this. >>>>>>>> >>>>>>>> On Tue, Oct 11, 2016 at 5:58 PM, Charles Short >>>>>>>> wrote: >>>>>>>>> Currently having more generic deployment issues (no valid host found >>>>>>>>> etc). >>>>>>>>> I can work around/solve these. >>>>>>>>> I don't yet have another stack to analyse, but will do soon. >>>>>>>>> >>>>>>>>> Charles >>>>>>>>> >>>>>>>>> >>>>>>>>> On 11/10/2016 16:35, Marius Cornea wrote: >>>>>>>>>> Did it succeed in bringing the Galera nodes to Master? You can ssh >>>>>>>>>> to >>>>>>>>>> the nodes and run 'pcs resource show galera' even though the >>>>>>>>>> deployment hasn't finished. I'm interested to see how the >>>>>>>>>> wsrep_cluster_address is set to see if it's affected by the >>>>>>>>>> resource >>>>>>>>>> agent issue described in >>>>>>>>>> https://bugs.launchpad.net/tripleo/+bug/1628521 >>>>>>>>>> >>>>>>>>>> On Tue, Oct 11, 2016 at 5:18 PM, Charles Short >>>>>>>>>> wrote: >>>>>>>>>>> Looks similar to this bug (still waiting on deployment to finish) >>>>>>>>>>> >>>>>>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1368214 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 11/10/2016 15:25, Charles Short wrote: >>>>>>>>>>>> Sorry for the delay. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Just redeploying to make sure I can repeat the same error. Should >>>>>>>>>>>> not >>>>>>>>>>>> be >>>>>>>>>>>> long. >>>>>>>>>>>> >>>>>>>>>>>> Charles >>>>>>>>>>>> >>>>>>>>>>>> On 11/10/2016 14:24, Marius Cornea wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> Could you also please paste the output for 'pcs resource show >>>>>>>>>>>>> galera', >>>>>>>>>>>>> it looks that all the galera nodes show up as slaves? >>>>>>>>>>>>> >>>>>>>>>>>>> Master/Slave Set: galera-master [galera] >>>>>>>>>>>>> Slaves: [ overcloud-controller-0 >>>>>>>>>>>>> overcloud-controller-1 >>>>>>>>>>>>> overcloud-controller-2 ] >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Oct 11, 2016 at 2:16 PM, Charles Short >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Here you are - >>>>>>>>>>>>>> >>>>>>>>>>>>>> - Heat stack error - http://pastebin.com/E8KZa2vE >>>>>>>>>>>>>> - PCS status - http://pastebin.com/z34gSLq6 >>>>>>>>>>>>>> - mariadb.log - http://pastebin.com/APFXPBLc >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>> >>>>>>>>>>>>>> Charles >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 11/10/2016 12:07, Marius Cornea wrote: >>>>>>>>>>>>>>> Hi Charles, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Could you please paste the output of 'pcs status' ? The log in >>>>>>>>>>>>>>> /var/log/mariadb/mariadb.log might also be a good indicator. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Tue, Oct 11, 2016 at 11:16 AM, Charles Short >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> To add I built my own image from >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> as the images in >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> http://buildlogs.centos.org/centos/7/cloud/x86_64/tripleo_images/newton/delorean/ >>>>>>>>>>>>>>>> caused sporadic ramdisk loading errors (hung at x% loaded on >>>>>>>>>>>>>>>> boot) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Does my image now need to be customised in any way for HA to >>>>>>>>>>>>>>>> work? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Charles >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 11/10/2016 09:55, Charles Short wrote: >>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I am installing Newton with TripleO on baremetal HP blades. >>>>>>>>>>>>>>>>> I can deploy a single controller stack overcloud no problem, >>>>>>>>>>>>>>>>> however >>>>>>>>>>>>>>>>> when >>>>>>>>>>>>>>>>> I choose three controllers the deployment fails (including >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml) >>>>>>>>>>>>>>>>> . >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The heat stack error first complains "Dependency >>>>>>>>>>>>>>>>> Exec[galera-ready] >>>>>>>>>>>>>>>>> has >>>>>>>>>>>>>>>>> failures" which in turn causes lots of other errors. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I have deployed Liberty and Mitaka successfully in the past >>>>>>>>>>>>>>>>> on >>>>>>>>>>>>>>>>> baremetal >>>>>>>>>>>>>>>>> with three controllers, and this is the first time I have >>>>>>>>>>>>>>>>> seen >>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>> error. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Charles >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> Charles Short >>>>>>>>>>>>>>>> Cloud Engineer >>>>>>>>>>>>>>>> Virtualization and Cloud Team >>>>>>>>>>>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>>>>>>>>>>> Tel: +44 (0)1223 494205 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Charles Short >>>>>>>>>>>>>> Cloud Engineer >>>>>>>>>>>>>> Virtualization and Cloud Team >>>>>>>>>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>>>>>>>>> Tel: +44 (0)1223 494205 >>>>>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Charles Short >>>>>>>>>>> Cloud Engineer >>>>>>>>>>> Virtualization and Cloud Team >>>>>>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>>>>>> Tel: +44 (0)1223 494205 >>>>>>>>>>> >>>>>>>>> -- >>>>>>>>> Charles Short >>>>>>>>> Cloud Engineer >>>>>>>>> Virtualization and Cloud Team >>>>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>>>> Tel: +44 (0)1223 494205 >>>>>>>>> >>>>>> -- >>>>>> Charles Short >>>>>> Cloud Engineer >>>>>> Virtualization and Cloud Team >>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>> Tel: +44 (0)1223 494205 >>>>>> >>>> -- >>>> Charles Short >>>> Cloud Engineer >>>> Virtualization and Cloud Team >>>> European Bioinformatics Institute (EMBL-EBI) >>>> Tel: +44 (0)1223 494205 >>>> >> -- >> Charles Short >> Cloud Engineer >> Virtualization and Cloud Team >> European Bioinformatics Institute (EMBL-EBI) >> Tel: +44 (0)1223 494205 >> -- Charles Short Cloud Engineer Virtualization and Cloud Team European Bioinformatics Institute (EMBL-EBI) Tel: +44 (0)1223 494205 From cems at ebi.ac.uk Wed Oct 12 09:45:29 2016 From: cems at ebi.ac.uk (Charles Short) Date: Wed, 12 Oct 2016 10:45:29 +0100 Subject: [rdo-list] Newton HA galera-ready dependency error In-Reply-To: References: <6b370c7f-11f1-b850-00ae-89d6348a4e84@ebi.ac.uk> <87a9220e-0541-b83e-9166-b9c63fceaf8b@ebi.ac.uk> <6bc28bc0-80c8-fae8-1b56-90544abf9801@ebi.ac.uk> <08ac18f7-4ab2-a627-895a-7f16b82c3a92@ebi.ac.uk> <2f6338eb-8346-9a79-cedd-0cdf0d4088dc@ebi.ac.uk> <959b1b0f-da3a-0827-4d3d-f6239c92a735@ebi.ac.uk> <58d11117-fd6b-fb95-7cf7-006696fd143f@ebi.ac.uk> Message-ID: <3c790fe4-82b3-7f46-8f94-e8ac3c830e19@ebi.ac.uk> Just checked what I did to build the image previously. I used export DELOREAN_TRUNK_REPO="http://trunk.rdoproject.org/centos7-newton/current/" Which is the same repo I used to install the Undercloud. Maybe I need to do a yum update in the image with libguestfs-tools prior to building the image? I will rebuild again anyway in case I made an error C On 12/10/2016 10:28, Charles Short wrote: > Hi, > > Ok, I will rebuild using the undercloud repo and report back. > > Thanks for your help > > Charles > > On 12/10/2016 09:44, Marius Cornea wrote: >> Oh, that explains it. It looks that the overcloud image doesn't >> contain the patch. >> >> I'm not familiar with the image build process but according to the >> docs[1] I think the packages get installed from the repo specified by >> export DELOREAN_TRUNK_REPO so maybe you should try to rebuild the >> image and use the same repo as the one set on the undercloud. >> >> [1] >> http://docs.openstack.org/developer/tripleo-docs/basic_deployment/basic_deployment_cli.html >> >> On Wed, Oct 12, 2016 at 10:30 AM, Charles Short wrote: >>> Hi, >>> >>> We noticed something that may be the reason for this patch not >>> working which >>> may be related to the way the Undercloud built the image? - >>> >>> This is difference between the puppet files in the undercloud and >>> puppet in the image: >>> >>> [stack at hh-extcl05-undercloud ~]$ grep mysql_short_node_names >>> /usr/share/openstack-puppet/modules/tripleo/manifests/profile/pacemaker/database/mysql.pp >>> >>> >>> $galera_node_names_lookup = hiera('mysql_short_node_names', >>> hiera('mysql_node_names', $::hostname)) >>> >>> [root at overcloud-controller-1 puppet]# grep mysql_short_node_names >>> /etc/puppet/modules/tripleo/manifests/profile/pacemaker/database/mysql.pp >>> >>> >>> (nothing found) >>> >>> >>> On 12/10/2016 09:09, Marius Cornea wrote: >>>> That's odd. I encountered the same issue and it was caused by missing >>>> this patch. What do you get if you do sudo hiera >>>> mysql_short_node_names on the controller node? >>>> >>>> On Wed, Oct 12, 2016 at 12:48 AM, Charles Short >>>> wrote: >>>>> Hi, >>>>> >>>>> puppet-tripleo-5.2.0-0.20161007035759.f32e484.el7.centos.noarch >>>>> >>>>> The patch seems to be already present - >>>>> >>>>> grep short >>>>> >>>>> /usr/share/openstack-puppet/modules/tripleo/manifests/profile/pacemaker/database/mysql.pp >>>>> >>>>> >>>>> # short name which is already registered in pacemaker until we >>>>> get >>>>> around >>>>> $galera_node_names_lookup = hiera('mysql_short_node_names', >>>>> hiera('mysql_node_names', $::hostname)) >>>>> >>>>> Charles >>>>> >>>>> On 11/10/2016 19:39, Marius Cornea wrote: >>>>>> I think the issue is caused by the addresses in >>>>>> wsrep_cluster_address >>>>>> not matching the pacemaker node names: >>>>>> >>>>>> >>>>>> wsrep_cluster_address=gcomm://overcloud-controller-0.internalapi.localdomain,overcloud-controller-1.internalapi.localdomain,overcloud-controller-2.internalapi.localdomain >>>>>> >>>>>> >>>>>> Could you please confirm what version of puppet-tripleo you've got >>>>>> installed on the overcloud nodes and if it contains the following >>>>>> patch: >>>>>> >>>>>> https://review.openstack.org/#/c/382883/1/manifests/profile/pacemaker/database/mysql.pp >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Marius >>>>>> >>>>>> On Tue, Oct 11, 2016 at 7:42 PM, Charles Short >>>>>> wrote: >>>>>>> Ok install finished with same error >>>>>>> The latest pcs status etc >>>>>>> >>>>>>> http://pastebin.com/ZK683gZe >>>>>>> >>>>>>> >>>>>>> On 11/10/2016 17:35, Charles Short wrote: >>>>>>>> Deployment almost finished...so >>>>>>>> >>>>>>>> >>>>>>>> http://pastebin.com/zE9B19XB >>>>>>>> >>>>>>>> This shows the pcs status as the deployment nears the end, and pcs >>>>>>>> resource show galera >>>>>>>> >>>>>>>> Charles >>>>>>>> >>>>>>>> On 11/10/2016 16:59, Marius Cornea wrote: >>>>>>>>> Great, thanks for checking this. >>>>>>>>> >>>>>>>>> On Tue, Oct 11, 2016 at 5:58 PM, Charles Short >>>>>>>>> wrote: >>>>>>>>>> Currently having more generic deployment issues (no valid >>>>>>>>>> host found >>>>>>>>>> etc). >>>>>>>>>> I can work around/solve these. >>>>>>>>>> I don't yet have another stack to analyse, but will do soon. >>>>>>>>>> >>>>>>>>>> Charles >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 11/10/2016 16:35, Marius Cornea wrote: >>>>>>>>>>> Did it succeed in bringing the Galera nodes to Master? You >>>>>>>>>>> can ssh >>>>>>>>>>> to >>>>>>>>>>> the nodes and run 'pcs resource show galera' even though the >>>>>>>>>>> deployment hasn't finished. I'm interested to see how the >>>>>>>>>>> wsrep_cluster_address is set to see if it's affected by the >>>>>>>>>>> resource >>>>>>>>>>> agent issue described in >>>>>>>>>>> https://bugs.launchpad.net/tripleo/+bug/1628521 >>>>>>>>>>> >>>>>>>>>>> On Tue, Oct 11, 2016 at 5:18 PM, Charles Short >>>>>>>>>>> wrote: >>>>>>>>>>>> Looks similar to this bug (still waiting on deployment to >>>>>>>>>>>> finish) >>>>>>>>>>>> >>>>>>>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1368214 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 11/10/2016 15:25, Charles Short wrote: >>>>>>>>>>>>> Sorry for the delay. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Just redeploying to make sure I can repeat the same error. >>>>>>>>>>>>> Should >>>>>>>>>>>>> not >>>>>>>>>>>>> be >>>>>>>>>>>>> long. >>>>>>>>>>>>> >>>>>>>>>>>>> Charles >>>>>>>>>>>>> >>>>>>>>>>>>> On 11/10/2016 14:24, Marius Cornea wrote: >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Could you also please paste the output for 'pcs resource >>>>>>>>>>>>>> show >>>>>>>>>>>>>> galera', >>>>>>>>>>>>>> it looks that all the galera nodes show up as slaves? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Master/Slave Set: galera-master [galera] >>>>>>>>>>>>>> Slaves: [ overcloud-controller-0 >>>>>>>>>>>>>> overcloud-controller-1 >>>>>>>>>>>>>> overcloud-controller-2 ] >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tue, Oct 11, 2016 at 2:16 PM, Charles Short >>>>>>>>>>>>>> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Here you are - >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - Heat stack error - http://pastebin.com/E8KZa2vE >>>>>>>>>>>>>>> - PCS status - http://pastebin.com/z34gSLq6 >>>>>>>>>>>>>>> - mariadb.log - http://pastebin.com/APFXPBLc >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Charles >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 11/10/2016 12:07, Marius Cornea wrote: >>>>>>>>>>>>>>>> Hi Charles, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Could you please paste the output of 'pcs status' ? The >>>>>>>>>>>>>>>> log in >>>>>>>>>>>>>>>> /var/log/mariadb/mariadb.log might also be a good >>>>>>>>>>>>>>>> indicator. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Tue, Oct 11, 2016 at 11:16 AM, Charles Short >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> To add I built my own image from >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> as the images in >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> http://buildlogs.centos.org/centos/7/cloud/x86_64/tripleo_images/newton/delorean/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> caused sporadic ramdisk loading errors (hung at x% >>>>>>>>>>>>>>>>> loaded on >>>>>>>>>>>>>>>>> boot) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Does my image now need to be customised in any way for >>>>>>>>>>>>>>>>> HA to >>>>>>>>>>>>>>>>> work? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Charles >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 11/10/2016 09:55, Charles Short wrote: >>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I am installing Newton with TripleO on baremetal HP >>>>>>>>>>>>>>>>>> blades. >>>>>>>>>>>>>>>>>> I can deploy a single controller stack overcloud no >>>>>>>>>>>>>>>>>> problem, >>>>>>>>>>>>>>>>>> however >>>>>>>>>>>>>>>>>> when >>>>>>>>>>>>>>>>>> I choose three controllers the deployment fails >>>>>>>>>>>>>>>>>> (including >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> . >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The heat stack error first complains "Dependency >>>>>>>>>>>>>>>>>> Exec[galera-ready] >>>>>>>>>>>>>>>>>> has >>>>>>>>>>>>>>>>>> failures" which in turn causes lots of other errors. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I have deployed Liberty and Mitaka successfully in >>>>>>>>>>>>>>>>>> the past >>>>>>>>>>>>>>>>>> on >>>>>>>>>>>>>>>>>> baremetal >>>>>>>>>>>>>>>>>> with three controllers, and this is the first time I >>>>>>>>>>>>>>>>>> have >>>>>>>>>>>>>>>>>> seen >>>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>> error. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Charles >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> Charles Short >>>>>>>>>>>>>>>>> Cloud Engineer >>>>>>>>>>>>>>>>> Virtualization and Cloud Team >>>>>>>>>>>>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>>>>>>>>>>>> Tel: +44 (0)1223 494205 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Charles Short >>>>>>>>>>>>>>> Cloud Engineer >>>>>>>>>>>>>>> Virtualization and Cloud Team >>>>>>>>>>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>>>>>>>>>> Tel: +44 (0)1223 494205 >>>>>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Charles Short >>>>>>>>>>>> Cloud Engineer >>>>>>>>>>>> Virtualization and Cloud Team >>>>>>>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>>>>>>> Tel: +44 (0)1223 494205 >>>>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Charles Short >>>>>>>>>> Cloud Engineer >>>>>>>>>> Virtualization and Cloud Team >>>>>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>>>>> Tel: +44 (0)1223 494205 >>>>>>>>>> >>>>>>> -- >>>>>>> Charles Short >>>>>>> Cloud Engineer >>>>>>> Virtualization and Cloud Team >>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>> Tel: +44 (0)1223 494205 >>>>>>> >>>>> -- >>>>> Charles Short >>>>> Cloud Engineer >>>>> Virtualization and Cloud Team >>>>> European Bioinformatics Institute (EMBL-EBI) >>>>> Tel: +44 (0)1223 494205 >>>>> >>> -- >>> Charles Short >>> Cloud Engineer >>> Virtualization and Cloud Team >>> European Bioinformatics Institute (EMBL-EBI) >>> Tel: +44 (0)1223 494205 >>> > -- Charles Short Cloud Engineer Virtualization and Cloud Team European Bioinformatics Institute (EMBL-EBI) Tel: +44 (0)1223 494205 From marius at remote-lab.net Wed Oct 12 09:56:13 2016 From: marius at remote-lab.net (Marius Cornea) Date: Wed, 12 Oct 2016 11:56:13 +0200 Subject: [rdo-list] Newton HA galera-ready dependency error In-Reply-To: <3c790fe4-82b3-7f46-8f94-e8ac3c830e19@ebi.ac.uk> References: <6b370c7f-11f1-b850-00ae-89d6348a4e84@ebi.ac.uk> <87a9220e-0541-b83e-9166-b9c63fceaf8b@ebi.ac.uk> <6bc28bc0-80c8-fae8-1b56-90544abf9801@ebi.ac.uk> <08ac18f7-4ab2-a627-895a-7f16b82c3a92@ebi.ac.uk> <2f6338eb-8346-9a79-cedd-0cdf0d4088dc@ebi.ac.uk> <959b1b0f-da3a-0827-4d3d-f6239c92a735@ebi.ac.uk> <58d11117-fd6b-fb95-7cf7-006696fd143f@ebi.ac.uk> <3c790fe4-82b3-7f46-8f94-e8ac3c830e19@ebi.ac.uk> Message-ID: I see that in that repo puppet-tripleo got updated on Friday, 2016-10-07. If the repo file is present inside the image you could update puppet-tripleo with virt-customize, then upload the image the the undercloud Glance with 'openstack overcloud image upload --update-existing' and redeploy. On Wed, Oct 12, 2016 at 11:45 AM, Charles Short wrote: > Just checked what I did to build the image previously. > > I used > export > DELOREAN_TRUNK_REPO="http://trunk.rdoproject.org/centos7-newton/current/" > > Which is the same repo I used to install the Undercloud. > Maybe I need to do a yum update in the image with libguestfs-tools prior to > building the image? > > I will rebuild again anyway in case I made an error > > C > > > > On 12/10/2016 10:28, Charles Short wrote: >> >> Hi, >> >> Ok, I will rebuild using the undercloud repo and report back. >> >> Thanks for your help >> >> Charles >> >> On 12/10/2016 09:44, Marius Cornea wrote: >>> >>> Oh, that explains it. It looks that the overcloud image doesn't >>> contain the patch. >>> >>> I'm not familiar with the image build process but according to the >>> docs[1] I think the packages get installed from the repo specified by >>> export DELOREAN_TRUNK_REPO so maybe you should try to rebuild the >>> image and use the same repo as the one set on the undercloud. >>> >>> [1] >>> http://docs.openstack.org/developer/tripleo-docs/basic_deployment/basic_deployment_cli.html >>> >>> On Wed, Oct 12, 2016 at 10:30 AM, Charles Short wrote: >>>> >>>> Hi, >>>> >>>> We noticed something that may be the reason for this patch not working >>>> which >>>> may be related to the way the Undercloud built the image? - >>>> >>>> This is difference between the puppet files in the undercloud and >>>> puppet in the image: >>>> >>>> [stack at hh-extcl05-undercloud ~]$ grep mysql_short_node_names >>>> >>>> /usr/share/openstack-puppet/modules/tripleo/manifests/profile/pacemaker/database/mysql.pp >>>> >>>> $galera_node_names_lookup = hiera('mysql_short_node_names', >>>> hiera('mysql_node_names', $::hostname)) >>>> >>>> [root at overcloud-controller-1 puppet]# grep mysql_short_node_names >>>> >>>> /etc/puppet/modules/tripleo/manifests/profile/pacemaker/database/mysql.pp >>>> >>>> (nothing found) >>>> >>>> >>>> On 12/10/2016 09:09, Marius Cornea wrote: >>>>> >>>>> That's odd. I encountered the same issue and it was caused by missing >>>>> this patch. What do you get if you do sudo hiera >>>>> mysql_short_node_names on the controller node? >>>>> >>>>> On Wed, Oct 12, 2016 at 12:48 AM, Charles Short wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> puppet-tripleo-5.2.0-0.20161007035759.f32e484.el7.centos.noarch >>>>>> >>>>>> The patch seems to be already present - >>>>>> >>>>>> grep short >>>>>> >>>>>> >>>>>> /usr/share/openstack-puppet/modules/tripleo/manifests/profile/pacemaker/database/mysql.pp >>>>>> >>>>>> # short name which is already registered in pacemaker until we get >>>>>> around >>>>>> $galera_node_names_lookup = hiera('mysql_short_node_names', >>>>>> hiera('mysql_node_names', $::hostname)) >>>>>> >>>>>> Charles >>>>>> >>>>>> On 11/10/2016 19:39, Marius Cornea wrote: >>>>>>> >>>>>>> I think the issue is caused by the addresses in wsrep_cluster_address >>>>>>> not matching the pacemaker node names: >>>>>>> >>>>>>> >>>>>>> >>>>>>> wsrep_cluster_address=gcomm://overcloud-controller-0.internalapi.localdomain,overcloud-controller-1.internalapi.localdomain,overcloud-controller-2.internalapi.localdomain >>>>>>> >>>>>>> Could you please confirm what version of puppet-tripleo you've got >>>>>>> installed on the overcloud nodes and if it contains the following >>>>>>> patch: >>>>>>> >>>>>>> >>>>>>> https://review.openstack.org/#/c/382883/1/manifests/profile/pacemaker/database/mysql.pp >>>>>>> >>>>>>> Thanks, >>>>>>> Marius >>>>>>> >>>>>>> On Tue, Oct 11, 2016 at 7:42 PM, Charles Short >>>>>>> wrote: >>>>>>>> >>>>>>>> Ok install finished with same error >>>>>>>> The latest pcs status etc >>>>>>>> >>>>>>>> http://pastebin.com/ZK683gZe >>>>>>>> >>>>>>>> >>>>>>>> On 11/10/2016 17:35, Charles Short wrote: >>>>>>>>> >>>>>>>>> Deployment almost finished...so >>>>>>>>> >>>>>>>>> >>>>>>>>> http://pastebin.com/zE9B19XB >>>>>>>>> >>>>>>>>> This shows the pcs status as the deployment nears the end, and pcs >>>>>>>>> resource show galera >>>>>>>>> >>>>>>>>> Charles >>>>>>>>> >>>>>>>>> On 11/10/2016 16:59, Marius Cornea wrote: >>>>>>>>>> >>>>>>>>>> Great, thanks for checking this. >>>>>>>>>> >>>>>>>>>> On Tue, Oct 11, 2016 at 5:58 PM, Charles Short >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Currently having more generic deployment issues (no valid host >>>>>>>>>>> found >>>>>>>>>>> etc). >>>>>>>>>>> I can work around/solve these. >>>>>>>>>>> I don't yet have another stack to analyse, but will do soon. >>>>>>>>>>> >>>>>>>>>>> Charles >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 11/10/2016 16:35, Marius Cornea wrote: >>>>>>>>>>>> >>>>>>>>>>>> Did it succeed in bringing the Galera nodes to Master? You can >>>>>>>>>>>> ssh >>>>>>>>>>>> to >>>>>>>>>>>> the nodes and run 'pcs resource show galera' even though the >>>>>>>>>>>> deployment hasn't finished. I'm interested to see how the >>>>>>>>>>>> wsrep_cluster_address is set to see if it's affected by the >>>>>>>>>>>> resource >>>>>>>>>>>> agent issue described in >>>>>>>>>>>> https://bugs.launchpad.net/tripleo/+bug/1628521 >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Oct 11, 2016 at 5:18 PM, Charles Short >>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Looks similar to this bug (still waiting on deployment to >>>>>>>>>>>>> finish) >>>>>>>>>>>>> >>>>>>>>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1368214 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 11/10/2016 15:25, Charles Short wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sorry for the delay. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Just redeploying to make sure I can repeat the same error. >>>>>>>>>>>>>> Should >>>>>>>>>>>>>> not >>>>>>>>>>>>>> be >>>>>>>>>>>>>> long. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Charles >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 11/10/2016 14:24, Marius Cornea wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Could you also please paste the output for 'pcs resource show >>>>>>>>>>>>>>> galera', >>>>>>>>>>>>>>> it looks that all the galera nodes show up as slaves? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Master/Slave Set: galera-master [galera] >>>>>>>>>>>>>>> Slaves: [ overcloud-controller-0 >>>>>>>>>>>>>>> overcloud-controller-1 >>>>>>>>>>>>>>> overcloud-controller-2 ] >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Tue, Oct 11, 2016 at 2:16 PM, Charles Short >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Here you are - >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - Heat stack error - http://pastebin.com/E8KZa2vE >>>>>>>>>>>>>>>> - PCS status - http://pastebin.com/z34gSLq6 >>>>>>>>>>>>>>>> - mariadb.log - http://pastebin.com/APFXPBLc >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Charles >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 11/10/2016 12:07, Marius Cornea wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi Charles, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Could you please paste the output of 'pcs status' ? The log >>>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>> /var/log/mariadb/mariadb.log might also be a good >>>>>>>>>>>>>>>>> indicator. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Tue, Oct 11, 2016 at 11:16 AM, Charles Short >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> To add I built my own image from >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> as the images in >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> http://buildlogs.centos.org/centos/7/cloud/x86_64/tripleo_images/newton/delorean/ >>>>>>>>>>>>>>>>>> caused sporadic ramdisk loading errors (hung at x% loaded >>>>>>>>>>>>>>>>>> on >>>>>>>>>>>>>>>>>> boot) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Does my image now need to be customised in any way for HA >>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>> work? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Charles >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 11/10/2016 09:55, Charles Short wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I am installing Newton with TripleO on baremetal HP >>>>>>>>>>>>>>>>>>> blades. >>>>>>>>>>>>>>>>>>> I can deploy a single controller stack overcloud no >>>>>>>>>>>>>>>>>>> problem, >>>>>>>>>>>>>>>>>>> however >>>>>>>>>>>>>>>>>>> when >>>>>>>>>>>>>>>>>>> I choose three controllers the deployment fails >>>>>>>>>>>>>>>>>>> (including >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml) >>>>>>>>>>>>>>>>>>> . >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The heat stack error first complains "Dependency >>>>>>>>>>>>>>>>>>> Exec[galera-ready] >>>>>>>>>>>>>>>>>>> has >>>>>>>>>>>>>>>>>>> failures" which in turn causes lots of other errors. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I have deployed Liberty and Mitaka successfully in the >>>>>>>>>>>>>>>>>>> past >>>>>>>>>>>>>>>>>>> on >>>>>>>>>>>>>>>>>>> baremetal >>>>>>>>>>>>>>>>>>> with three controllers, and this is the first time I have >>>>>>>>>>>>>>>>>>> seen >>>>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>>> error. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Charles >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> Charles Short >>>>>>>>>>>>>>>>>> Cloud Engineer >>>>>>>>>>>>>>>>>> Virtualization and Cloud Team >>>>>>>>>>>>>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>>>>>>>>>>>>> Tel: +44 (0)1223 494205 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> Charles Short >>>>>>>>>>>>>>>> Cloud Engineer >>>>>>>>>>>>>>>> Virtualization and Cloud Team >>>>>>>>>>>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>>>>>>>>>>> Tel: +44 (0)1223 494205 >>>>>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Charles Short >>>>>>>>>>>>> Cloud Engineer >>>>>>>>>>>>> Virtualization and Cloud Team >>>>>>>>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>>>>>>>> Tel: +44 (0)1223 494205 >>>>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Charles Short >>>>>>>>>>> Cloud Engineer >>>>>>>>>>> Virtualization and Cloud Team >>>>>>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>>>>>> Tel: +44 (0)1223 494205 >>>>>>>>>>> >>>>>>>> -- >>>>>>>> Charles Short >>>>>>>> Cloud Engineer >>>>>>>> Virtualization and Cloud Team >>>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>>> Tel: +44 (0)1223 494205 >>>>>>>> >>>>>> -- >>>>>> Charles Short >>>>>> Cloud Engineer >>>>>> Virtualization and Cloud Team >>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>> Tel: +44 (0)1223 494205 >>>>>> >>>> -- >>>> Charles Short >>>> Cloud Engineer >>>> Virtualization and Cloud Team >>>> European Bioinformatics Institute (EMBL-EBI) >>>> Tel: +44 (0)1223 494205 >>>> >> > > -- > Charles Short > Cloud Engineer > Virtualization and Cloud Team > European Bioinformatics Institute (EMBL-EBI) > Tel: +44 (0)1223 494205 > From cems at ebi.ac.uk Wed Oct 12 10:48:36 2016 From: cems at ebi.ac.uk (Charles Short) Date: Wed, 12 Oct 2016 11:48:36 +0100 Subject: [rdo-list] Newton HA galera-ready dependency error In-Reply-To: References: <87a9220e-0541-b83e-9166-b9c63fceaf8b@ebi.ac.uk> <6bc28bc0-80c8-fae8-1b56-90544abf9801@ebi.ac.uk> <08ac18f7-4ab2-a627-895a-7f16b82c3a92@ebi.ac.uk> <2f6338eb-8346-9a79-cedd-0cdf0d4088dc@ebi.ac.uk> <959b1b0f-da3a-0827-4d3d-f6239c92a735@ebi.ac.uk> <58d11117-fd6b-fb95-7cf7-006696fd143f@ebi.ac.uk> <3c790fe4-82b3-7f46-8f94-e8ac3c830e19@ebi.ac.uk> Message-ID: <91dbf9a2-0abb-d72e-5900-8435a762d88c@ebi.ac.uk> Ok, I updated puppet-tripleo as suggested with virt-customize and verified that the patch was indeed updated (using guestmount ) I am now redeploying Charles On 12/10/2016 10:56, Marius Cornea wrote: > I see that in that repo puppet-tripleo got updated on Friday, > 2016-10-07. If the repo file is present inside the image you could > update puppet-tripleo with virt-customize, then upload the image the > the undercloud Glance with 'openstack overcloud image upload > --update-existing' and redeploy. > > On Wed, Oct 12, 2016 at 11:45 AM, Charles Short wrote: >> Just checked what I did to build the image previously. >> >> I used >> export >> DELOREAN_TRUNK_REPO="http://trunk.rdoproject.org/centos7-newton/current/" >> >> Which is the same repo I used to install the Undercloud. >> Maybe I need to do a yum update in the image with libguestfs-tools prior to >> building the image? >> >> I will rebuild again anyway in case I made an error >> >> C >> >> >> >> On 12/10/2016 10:28, Charles Short wrote: >>> Hi, >>> >>> Ok, I will rebuild using the undercloud repo and report back. >>> >>> Thanks for your help >>> >>> Charles >>> >>> On 12/10/2016 09:44, Marius Cornea wrote: >>>> Oh, that explains it. It looks that the overcloud image doesn't >>>> contain the patch. >>>> >>>> I'm not familiar with the image build process but according to the >>>> docs[1] I think the packages get installed from the repo specified by >>>> export DELOREAN_TRUNK_REPO so maybe you should try to rebuild the >>>> image and use the same repo as the one set on the undercloud. >>>> >>>> [1] >>>> http://docs.openstack.org/developer/tripleo-docs/basic_deployment/basic_deployment_cli.html >>>> >>>> On Wed, Oct 12, 2016 at 10:30 AM, Charles Short wrote: >>>>> Hi, >>>>> >>>>> We noticed something that may be the reason for this patch not working >>>>> which >>>>> may be related to the way the Undercloud built the image? - >>>>> >>>>> This is difference between the puppet files in the undercloud and >>>>> puppet in the image: >>>>> >>>>> [stack at hh-extcl05-undercloud ~]$ grep mysql_short_node_names >>>>> >>>>> /usr/share/openstack-puppet/modules/tripleo/manifests/profile/pacemaker/database/mysql.pp >>>>> >>>>> $galera_node_names_lookup = hiera('mysql_short_node_names', >>>>> hiera('mysql_node_names', $::hostname)) >>>>> >>>>> [root at overcloud-controller-1 puppet]# grep mysql_short_node_names >>>>> >>>>> /etc/puppet/modules/tripleo/manifests/profile/pacemaker/database/mysql.pp >>>>> >>>>> (nothing found) >>>>> >>>>> >>>>> On 12/10/2016 09:09, Marius Cornea wrote: >>>>>> That's odd. I encountered the same issue and it was caused by missing >>>>>> this patch. What do you get if you do sudo hiera >>>>>> mysql_short_node_names on the controller node? >>>>>> >>>>>> On Wed, Oct 12, 2016 at 12:48 AM, Charles Short wrote: >>>>>>> Hi, >>>>>>> >>>>>>> puppet-tripleo-5.2.0-0.20161007035759.f32e484.el7.centos.noarch >>>>>>> >>>>>>> The patch seems to be already present - >>>>>>> >>>>>>> grep short >>>>>>> >>>>>>> >>>>>>> /usr/share/openstack-puppet/modules/tripleo/manifests/profile/pacemaker/database/mysql.pp >>>>>>> >>>>>>> # short name which is already registered in pacemaker until we get >>>>>>> around >>>>>>> $galera_node_names_lookup = hiera('mysql_short_node_names', >>>>>>> hiera('mysql_node_names', $::hostname)) >>>>>>> >>>>>>> Charles >>>>>>> >>>>>>> On 11/10/2016 19:39, Marius Cornea wrote: >>>>>>>> I think the issue is caused by the addresses in wsrep_cluster_address >>>>>>>> not matching the pacemaker node names: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> wsrep_cluster_address=gcomm://overcloud-controller-0.internalapi.localdomain,overcloud-controller-1.internalapi.localdomain,overcloud-controller-2.internalapi.localdomain >>>>>>>> >>>>>>>> Could you please confirm what version of puppet-tripleo you've got >>>>>>>> installed on the overcloud nodes and if it contains the following >>>>>>>> patch: >>>>>>>> >>>>>>>> >>>>>>>> https://review.openstack.org/#/c/382883/1/manifests/profile/pacemaker/database/mysql.pp >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Marius >>>>>>>> >>>>>>>> On Tue, Oct 11, 2016 at 7:42 PM, Charles Short >>>>>>>> wrote: >>>>>>>>> Ok install finished with same error >>>>>>>>> The latest pcs status etc >>>>>>>>> >>>>>>>>> http://pastebin.com/ZK683gZe >>>>>>>>> >>>>>>>>> >>>>>>>>> On 11/10/2016 17:35, Charles Short wrote: >>>>>>>>>> Deployment almost finished...so >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> http://pastebin.com/zE9B19XB >>>>>>>>>> >>>>>>>>>> This shows the pcs status as the deployment nears the end, and pcs >>>>>>>>>> resource show galera >>>>>>>>>> >>>>>>>>>> Charles >>>>>>>>>> >>>>>>>>>> On 11/10/2016 16:59, Marius Cornea wrote: >>>>>>>>>>> Great, thanks for checking this. >>>>>>>>>>> >>>>>>>>>>> On Tue, Oct 11, 2016 at 5:58 PM, Charles Short >>>>>>>>>>> wrote: >>>>>>>>>>>> Currently having more generic deployment issues (no valid host >>>>>>>>>>>> found >>>>>>>>>>>> etc). >>>>>>>>>>>> I can work around/solve these. >>>>>>>>>>>> I don't yet have another stack to analyse, but will do soon. >>>>>>>>>>>> >>>>>>>>>>>> Charles >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 11/10/2016 16:35, Marius Cornea wrote: >>>>>>>>>>>>> Did it succeed in bringing the Galera nodes to Master? You can >>>>>>>>>>>>> ssh >>>>>>>>>>>>> to >>>>>>>>>>>>> the nodes and run 'pcs resource show galera' even though the >>>>>>>>>>>>> deployment hasn't finished. I'm interested to see how the >>>>>>>>>>>>> wsrep_cluster_address is set to see if it's affected by the >>>>>>>>>>>>> resource >>>>>>>>>>>>> agent issue described in >>>>>>>>>>>>> https://bugs.launchpad.net/tripleo/+bug/1628521 >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Oct 11, 2016 at 5:18 PM, Charles Short >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> Looks similar to this bug (still waiting on deployment to >>>>>>>>>>>>>> finish) >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1368214 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 11/10/2016 15:25, Charles Short wrote: >>>>>>>>>>>>>>> Sorry for the delay. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Just redeploying to make sure I can repeat the same error. >>>>>>>>>>>>>>> Should >>>>>>>>>>>>>>> not >>>>>>>>>>>>>>> be >>>>>>>>>>>>>>> long. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Charles >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 11/10/2016 14:24, Marius Cornea wrote: >>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Could you also please paste the output for 'pcs resource show >>>>>>>>>>>>>>>> galera', >>>>>>>>>>>>>>>> it looks that all the galera nodes show up as slaves? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Master/Slave Set: galera-master [galera] >>>>>>>>>>>>>>>> Slaves: [ overcloud-controller-0 >>>>>>>>>>>>>>>> overcloud-controller-1 >>>>>>>>>>>>>>>> overcloud-controller-2 ] >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Tue, Oct 11, 2016 at 2:16 PM, Charles Short >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Here you are - >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> - Heat stack error - http://pastebin.com/E8KZa2vE >>>>>>>>>>>>>>>>> - PCS status - http://pastebin.com/z34gSLq6 >>>>>>>>>>>>>>>>> - mariadb.log - http://pastebin.com/APFXPBLc >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Charles >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 11/10/2016 12:07, Marius Cornea wrote: >>>>>>>>>>>>>>>>>> Hi Charles, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Could you please paste the output of 'pcs status' ? The log >>>>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>> /var/log/mariadb/mariadb.log might also be a good >>>>>>>>>>>>>>>>>> indicator. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Tue, Oct 11, 2016 at 11:16 AM, Charles Short >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>> To add I built my own image from >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> as the images in >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> http://buildlogs.centos.org/centos/7/cloud/x86_64/tripleo_images/newton/delorean/ >>>>>>>>>>>>>>>>>>> caused sporadic ramdisk loading errors (hung at x% loaded >>>>>>>>>>>>>>>>>>> on >>>>>>>>>>>>>>>>>>> boot) >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Does my image now need to be customised in any way for HA >>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>> work? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Charles >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 11/10/2016 09:55, Charles Short wrote: >>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I am installing Newton with TripleO on baremetal HP >>>>>>>>>>>>>>>>>>>> blades. >>>>>>>>>>>>>>>>>>>> I can deploy a single controller stack overcloud no >>>>>>>>>>>>>>>>>>>> problem, >>>>>>>>>>>>>>>>>>>> however >>>>>>>>>>>>>>>>>>>> when >>>>>>>>>>>>>>>>>>>> I choose three controllers the deployment fails >>>>>>>>>>>>>>>>>>>> (including >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml) >>>>>>>>>>>>>>>>>>>> . >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> The heat stack error first complains "Dependency >>>>>>>>>>>>>>>>>>>> Exec[galera-ready] >>>>>>>>>>>>>>>>>>>> has >>>>>>>>>>>>>>>>>>>> failures" which in turn causes lots of other errors. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I have deployed Liberty and Mitaka successfully in the >>>>>>>>>>>>>>>>>>>> past >>>>>>>>>>>>>>>>>>>> on >>>>>>>>>>>>>>>>>>>> baremetal >>>>>>>>>>>>>>>>>>>> with three controllers, and this is the first time I have >>>>>>>>>>>>>>>>>>>> seen >>>>>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>>>> error. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Charles >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> Charles Short >>>>>>>>>>>>>>>>>>> Cloud Engineer >>>>>>>>>>>>>>>>>>> Virtualization and Cloud Team >>>>>>>>>>>>>>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>>>>>>>>>>>>>> Tel: +44 (0)1223 494205 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> Charles Short >>>>>>>>>>>>>>>>> Cloud Engineer >>>>>>>>>>>>>>>>> Virtualization and Cloud Team >>>>>>>>>>>>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>>>>>>>>>>>> Tel: +44 (0)1223 494205 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Charles Short >>>>>>>>>>>>>> Cloud Engineer >>>>>>>>>>>>>> Virtualization and Cloud Team >>>>>>>>>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>>>>>>>>> Tel: +44 (0)1223 494205 >>>>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Charles Short >>>>>>>>>>>> Cloud Engineer >>>>>>>>>>>> Virtualization and Cloud Team >>>>>>>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>>>>>>> Tel: +44 (0)1223 494205 >>>>>>>>>>>> >>>>>>>>> -- >>>>>>>>> Charles Short >>>>>>>>> Cloud Engineer >>>>>>>>> Virtualization and Cloud Team >>>>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>>>> Tel: +44 (0)1223 494205 >>>>>>>>> >>>>>>> -- >>>>>>> Charles Short >>>>>>> Cloud Engineer >>>>>>> Virtualization and Cloud Team >>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>> Tel: +44 (0)1223 494205 >>>>>>> >>>>> -- >>>>> Charles Short >>>>> Cloud Engineer >>>>> Virtualization and Cloud Team >>>>> European Bioinformatics Institute (EMBL-EBI) >>>>> Tel: +44 (0)1223 494205 >>>>> >> -- >> Charles Short >> Cloud Engineer >> Virtualization and Cloud Team >> European Bioinformatics Institute (EMBL-EBI) >> Tel: +44 (0)1223 494205 >> -- Charles Short Cloud Engineer Virtualization and Cloud Team European Bioinformatics Institute (EMBL-EBI) Tel: +44 (0)1223 494205 From cems at ebi.ac.uk Wed Oct 12 11:00:26 2016 From: cems at ebi.ac.uk (Charles Short) Date: Wed, 12 Oct 2016 12:00:26 +0100 Subject: [rdo-list] Manila TripleO Newton Message-ID: Hi, I notice that the Manila NetApp template that was missing in Mitaka is now present in TripleO Newton. Does this mean I can deploy it? /usr/share/openstack-tripleo-heat-templates/environments/manila-netapp-config.yaml What is the official status? Thanks Charles -- Charles Short Cloud Engineer Virtualization and Cloud Team European Bioinformatics Institute (EMBL-EBI) Tel: +44 (0)1223 494205 From hguemar at fedoraproject.org Wed Oct 12 12:00:46 2016 From: hguemar at fedoraproject.org (=?UTF-8?Q?Ha=C3=AFkel?=) Date: Wed, 12 Oct 2016 14:00:46 +0200 Subject: [rdo-list] networking-cisco in RDO In-Reply-To: References: Message-ID: Le 12 oct. 2016 11:12 AM, "Alan Pevec" a ?crit : > > On Sat, Oct 8, 2016 at 1:18 AM, Ha?kel wrote: > > one requirement to remain in RDO is to have an active maintainer to > > update/fix issues in packages. > > We're also looking for upstream developpers to collaborate with us on > > the release management side. > > > > In networking-arista, some issues we had to deal with: > > - no stable/newton branches > > - no stable tarballs > > https://tarballs.openstack.org/networking-arista/ > > > > As a release wrangler, I can help maintainers to get things released > > in time, but if there's no releases, I have no clue on what to ship in > > our repositories. > > We're no network experts, we have no networking-arista specific CI > > jobs running, and we have a whole distro to maintain, so unless > > someone steps up to maintain it, best choice for us is to drop it > > rather than shipping half-broken packages. Off couse, we're looking > > forward working with upstream maintainers to ship OpenStack packages > > that reflects positively on both downstream/upstream. > > We have the similar situation with networking-cisco. > We do have designated maintainers in rdoinfo: > maintainers: > - openstack-networking at cisco.com > - brdemers at cisco.com > > But stable/newton and mitaka branches do not exist and there wasn't a > release since June: > https://github.com/openstack/networking-cisco/releases > > Since we didn't get any new input for RDO Newton we are packaging > latest git snapshot[1] but that's a blind guess since networking-cisco > is not covered in RDO CI. > Also since stable/mitaka is missing we had to pin to 3.2.0 in RDO Mitaka[2] > > We'd welcome guidance from designated maintainers about release plans > (is it going to be branchless like Tempest?) and to explore 3rd party > CI setup on review.rdoproject.org for networking-cisco reviews. > > Cheers, > Alan > Actually, Lon told me that there's a new engineer from Cisco taking over bdemers duty. Regards, H. > [1] https://review.rdoproject.org/r/3233 > [2] https://review.rdoproject.org/r/3143 > > _______________________________________________ > 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 apevec at redhat.com Wed Oct 12 12:41:26 2016 From: apevec at redhat.com (Alan Pevec) Date: Wed, 12 Oct 2016 14:41:26 +0200 Subject: [rdo-list] networking-cisco in RDO In-Reply-To: References: Message-ID: > Actually, Lon told me that there's a new engineer from Cisco taking over > bdemers duty. Indeed, we did sync on #rdo and handover is in progress https://review.rdoproject.org/r/3253 Alan From cems at ebi.ac.uk Thu Oct 13 12:45:58 2016 From: cems at ebi.ac.uk (Charles Short) Date: Thu, 13 Oct 2016 13:45:58 +0100 Subject: [rdo-list] Newton HA galera-ready dependency error In-Reply-To: <91dbf9a2-0abb-d72e-5900-8435a762d88c@ebi.ac.uk> References: <87a9220e-0541-b83e-9166-b9c63fceaf8b@ebi.ac.uk> <6bc28bc0-80c8-fae8-1b56-90544abf9801@ebi.ac.uk> <08ac18f7-4ab2-a627-895a-7f16b82c3a92@ebi.ac.uk> <2f6338eb-8346-9a79-cedd-0cdf0d4088dc@ebi.ac.uk> <959b1b0f-da3a-0827-4d3d-f6239c92a735@ebi.ac.uk> <58d11117-fd6b-fb95-7cf7-006696fd143f@ebi.ac.uk> <3c790fe4-82b3-7f46-8f94-e8ac3c830e19@ebi.ac.uk> <91dbf9a2-0abb-d72e-5900-8435a762d88c@ebi.ac.uk> Message-ID: Hi, Just some feedback on my deployment - Overcloud successfully deployed. I ended up updating the Undercloud, and using the latest pre- built images (http://buildlogs.centos.org/centos/7/cloud/x86_64/tripleo_images/newton/delorean/) This all worked well. Thanks again Charles On 12/10/2016 11:48, Charles Short wrote: > Ok, I updated puppet-tripleo as suggested with virt-customize and > verified that the patch was indeed updated (using guestmount ) > I am now redeploying > > Charles > > On 12/10/2016 10:56, Marius Cornea wrote: >> I see that in that repo puppet-tripleo got updated on Friday, >> 2016-10-07. If the repo file is present inside the image you could >> update puppet-tripleo with virt-customize, then upload the image the >> the undercloud Glance with 'openstack overcloud image upload >> --update-existing' and redeploy. >> >> On Wed, Oct 12, 2016 at 11:45 AM, Charles Short wrote: >>> Just checked what I did to build the image previously. >>> >>> I used >>> export >>> DELOREAN_TRUNK_REPO="http://trunk.rdoproject.org/centos7-newton/current/" >>> >>> >>> Which is the same repo I used to install the Undercloud. >>> Maybe I need to do a yum update in the image with libguestfs-tools >>> prior to >>> building the image? >>> >>> I will rebuild again anyway in case I made an error >>> >>> C >>> >>> >>> >>> On 12/10/2016 10:28, Charles Short wrote: >>>> Hi, >>>> >>>> Ok, I will rebuild using the undercloud repo and report back. >>>> >>>> Thanks for your help >>>> >>>> Charles >>>> >>>> On 12/10/2016 09:44, Marius Cornea wrote: >>>>> Oh, that explains it. It looks that the overcloud image doesn't >>>>> contain the patch. >>>>> >>>>> I'm not familiar with the image build process but according to the >>>>> docs[1] I think the packages get installed from the repo specified by >>>>> export DELOREAN_TRUNK_REPO so maybe you should try to rebuild the >>>>> image and use the same repo as the one set on the undercloud. >>>>> >>>>> [1] >>>>> http://docs.openstack.org/developer/tripleo-docs/basic_deployment/basic_deployment_cli.html >>>>> >>>>> >>>>> On Wed, Oct 12, 2016 at 10:30 AM, Charles Short >>>>> wrote: >>>>>> Hi, >>>>>> >>>>>> We noticed something that may be the reason for this patch not >>>>>> working >>>>>> which >>>>>> may be related to the way the Undercloud built the image? - >>>>>> >>>>>> This is difference between the puppet files in the undercloud and >>>>>> puppet in the image: >>>>>> >>>>>> [stack at hh-extcl05-undercloud ~]$ grep mysql_short_node_names >>>>>> >>>>>> /usr/share/openstack-puppet/modules/tripleo/manifests/profile/pacemaker/database/mysql.pp >>>>>> >>>>>> >>>>>> $galera_node_names_lookup = hiera('mysql_short_node_names', >>>>>> hiera('mysql_node_names', $::hostname)) >>>>>> >>>>>> [root at overcloud-controller-1 puppet]# grep mysql_short_node_names >>>>>> >>>>>> /etc/puppet/modules/tripleo/manifests/profile/pacemaker/database/mysql.pp >>>>>> >>>>>> >>>>>> (nothing found) >>>>>> >>>>>> >>>>>> On 12/10/2016 09:09, Marius Cornea wrote: >>>>>>> That's odd. I encountered the same issue and it was caused by >>>>>>> missing >>>>>>> this patch. What do you get if you do sudo hiera >>>>>>> mysql_short_node_names on the controller node? >>>>>>> >>>>>>> On Wed, Oct 12, 2016 at 12:48 AM, Charles Short >>>>>>> wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> puppet-tripleo-5.2.0-0.20161007035759.f32e484.el7.centos.noarch >>>>>>>> >>>>>>>> The patch seems to be already present - >>>>>>>> >>>>>>>> grep short >>>>>>>> >>>>>>>> >>>>>>>> /usr/share/openstack-puppet/modules/tripleo/manifests/profile/pacemaker/database/mysql.pp >>>>>>>> >>>>>>>> >>>>>>>> # short name which is already registered in pacemaker >>>>>>>> until we get >>>>>>>> around >>>>>>>> $galera_node_names_lookup = hiera('mysql_short_node_names', >>>>>>>> hiera('mysql_node_names', $::hostname)) >>>>>>>> >>>>>>>> Charles >>>>>>>> >>>>>>>> On 11/10/2016 19:39, Marius Cornea wrote: >>>>>>>>> I think the issue is caused by the addresses in >>>>>>>>> wsrep_cluster_address >>>>>>>>> not matching the pacemaker node names: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> wsrep_cluster_address=gcomm://overcloud-controller-0.internalapi.localdomain,overcloud-controller-1.internalapi.localdomain,overcloud-controller-2.internalapi.localdomain >>>>>>>>> >>>>>>>>> >>>>>>>>> Could you please confirm what version of puppet-tripleo you've >>>>>>>>> got >>>>>>>>> installed on the overcloud nodes and if it contains the following >>>>>>>>> patch: >>>>>>>>> >>>>>>>>> >>>>>>>>> https://review.openstack.org/#/c/382883/1/manifests/profile/pacemaker/database/mysql.pp >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Marius >>>>>>>>> >>>>>>>>> On Tue, Oct 11, 2016 at 7:42 PM, Charles Short >>>>>>>>> wrote: >>>>>>>>>> Ok install finished with same error >>>>>>>>>> The latest pcs status etc >>>>>>>>>> >>>>>>>>>> http://pastebin.com/ZK683gZe >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 11/10/2016 17:35, Charles Short wrote: >>>>>>>>>>> Deployment almost finished...so >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> http://pastebin.com/zE9B19XB >>>>>>>>>>> >>>>>>>>>>> This shows the pcs status as the deployment nears the end, >>>>>>>>>>> and pcs >>>>>>>>>>> resource show galera >>>>>>>>>>> >>>>>>>>>>> Charles >>>>>>>>>>> >>>>>>>>>>> On 11/10/2016 16:59, Marius Cornea wrote: >>>>>>>>>>>> Great, thanks for checking this. >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Oct 11, 2016 at 5:58 PM, Charles Short >>>>>>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>>> Currently having more generic deployment issues (no valid >>>>>>>>>>>>> host >>>>>>>>>>>>> found >>>>>>>>>>>>> etc). >>>>>>>>>>>>> I can work around/solve these. >>>>>>>>>>>>> I don't yet have another stack to analyse, but will do soon. >>>>>>>>>>>>> >>>>>>>>>>>>> Charles >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 11/10/2016 16:35, Marius Cornea wrote: >>>>>>>>>>>>>> Did it succeed in bringing the Galera nodes to Master? >>>>>>>>>>>>>> You can >>>>>>>>>>>>>> ssh >>>>>>>>>>>>>> to >>>>>>>>>>>>>> the nodes and run 'pcs resource show galera' even though the >>>>>>>>>>>>>> deployment hasn't finished. I'm interested to see how the >>>>>>>>>>>>>> wsrep_cluster_address is set to see if it's affected by the >>>>>>>>>>>>>> resource >>>>>>>>>>>>>> agent issue described in >>>>>>>>>>>>>> https://bugs.launchpad.net/tripleo/+bug/1628521 >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tue, Oct 11, 2016 at 5:18 PM, Charles Short >>>>>>>>>>>>>> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> Looks similar to this bug (still waiting on deployment to >>>>>>>>>>>>>>> finish) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1368214 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 11/10/2016 15:25, Charles Short wrote: >>>>>>>>>>>>>>>> Sorry for the delay. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Just redeploying to make sure I can repeat the same error. >>>>>>>>>>>>>>>> Should >>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>> be >>>>>>>>>>>>>>>> long. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Charles >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 11/10/2016 14:24, Marius Cornea wrote: >>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Could you also please paste the output for 'pcs >>>>>>>>>>>>>>>>> resource show >>>>>>>>>>>>>>>>> galera', >>>>>>>>>>>>>>>>> it looks that all the galera nodes show up as slaves? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Master/Slave Set: galera-master [galera] >>>>>>>>>>>>>>>>> Slaves: [ overcloud-controller-0 >>>>>>>>>>>>>>>>> overcloud-controller-1 >>>>>>>>>>>>>>>>> overcloud-controller-2 ] >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Tue, Oct 11, 2016 at 2:16 PM, Charles Short >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Here you are - >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> - Heat stack error - >>>>>>>>>>>>>>>>>> http://pastebin.com/E8KZa2vE >>>>>>>>>>>>>>>>>> - PCS status - http://pastebin.com/z34gSLq6 >>>>>>>>>>>>>>>>>> - mariadb.log - http://pastebin.com/APFXPBLc >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Charles >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 11/10/2016 12:07, Marius Cornea wrote: >>>>>>>>>>>>>>>>>>> Hi Charles, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Could you please paste the output of 'pcs status' ? >>>>>>>>>>>>>>>>>>> The log >>>>>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>> /var/log/mariadb/mariadb.log might also be a good >>>>>>>>>>>>>>>>>>> indicator. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Tue, Oct 11, 2016 at 11:16 AM, Charles Short >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>> To add I built my own image from >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> as the images in >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> http://buildlogs.centos.org/centos/7/cloud/x86_64/tripleo_images/newton/delorean/ >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> caused sporadic ramdisk loading errors (hung at x% >>>>>>>>>>>>>>>>>>>> loaded >>>>>>>>>>>>>>>>>>>> on >>>>>>>>>>>>>>>>>>>> boot) >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Does my image now need to be customised in any way >>>>>>>>>>>>>>>>>>>> for HA >>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>> work? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Charles >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 11/10/2016 09:55, Charles Short wrote: >>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I am installing Newton with TripleO on baremetal HP >>>>>>>>>>>>>>>>>>>>> blades. >>>>>>>>>>>>>>>>>>>>> I can deploy a single controller stack overcloud no >>>>>>>>>>>>>>>>>>>>> problem, >>>>>>>>>>>>>>>>>>>>> however >>>>>>>>>>>>>>>>>>>>> when >>>>>>>>>>>>>>>>>>>>> I choose three controllers the deployment fails >>>>>>>>>>>>>>>>>>>>> (including >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml) >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> . >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> The heat stack error first complains "Dependency >>>>>>>>>>>>>>>>>>>>> Exec[galera-ready] >>>>>>>>>>>>>>>>>>>>> has >>>>>>>>>>>>>>>>>>>>> failures" which in turn causes lots of other errors. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I have deployed Liberty and Mitaka successfully in >>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>> past >>>>>>>>>>>>>>>>>>>>> on >>>>>>>>>>>>>>>>>>>>> baremetal >>>>>>>>>>>>>>>>>>>>> with three controllers, and this is the first time >>>>>>>>>>>>>>>>>>>>> I have >>>>>>>>>>>>>>>>>>>>> seen >>>>>>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>>>>> error. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Charles >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>> Charles Short >>>>>>>>>>>>>>>>>>>> Cloud Engineer >>>>>>>>>>>>>>>>>>>> Virtualization and Cloud Team >>>>>>>>>>>>>>>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>>>>>>>>>>>>>>> Tel: +44 (0)1223 494205 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> Charles Short >>>>>>>>>>>>>>>>>> Cloud Engineer >>>>>>>>>>>>>>>>>> Virtualization and Cloud Team >>>>>>>>>>>>>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>>>>>>>>>>>>> Tel: +44 (0)1223 494205 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Charles Short >>>>>>>>>>>>>>> Cloud Engineer >>>>>>>>>>>>>>> Virtualization and Cloud Team >>>>>>>>>>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>>>>>>>>>> Tel: +44 (0)1223 494205 >>>>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Charles Short >>>>>>>>>>>>> Cloud Engineer >>>>>>>>>>>>> Virtualization and Cloud Team >>>>>>>>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>>>>>>>> Tel: +44 (0)1223 494205 >>>>>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Charles Short >>>>>>>>>> Cloud Engineer >>>>>>>>>> Virtualization and Cloud Team >>>>>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>>>>> Tel: +44 (0)1223 494205 >>>>>>>>>> >>>>>>>> -- >>>>>>>> Charles Short >>>>>>>> Cloud Engineer >>>>>>>> Virtualization and Cloud Team >>>>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>>>> Tel: +44 (0)1223 494205 >>>>>>>> >>>>>> -- >>>>>> Charles Short >>>>>> Cloud Engineer >>>>>> Virtualization and Cloud Team >>>>>> European Bioinformatics Institute (EMBL-EBI) >>>>>> Tel: +44 (0)1223 494205 >>>>>> >>> -- >>> Charles Short >>> Cloud Engineer >>> Virtualization and Cloud Team >>> European Bioinformatics Institute (EMBL-EBI) >>> Tel: +44 (0)1223 494205 >>> > -- Charles Short Cloud Engineer Virtualization and Cloud Team European Bioinformatics Institute (EMBL-EBI) Tel: +44 (0)1223 494205 From emilien at redhat.com Thu Oct 13 13:52:12 2016 From: emilien at redhat.com (Emilien Macchi) Date: Thu, 13 Oct 2016 09:52:12 -0400 Subject: [rdo-list] rdo infra scrum In-Reply-To: References: Message-ID: On Tue, Oct 11, 2016 at 11:04 AM, Wesley Hayutin wrote: > Greetings, > > Latest scrum recording and notes > > https://bluejeans.com/s/FzK_2/ > https://review.rdoproject.org/etherpad/p/rdo-infra-scrum > > Congrats to the new leadership of the RDO Infra team! > > Product Manager: Fred Lepied > User advocate: 50% David Simard, 50% Attila > Team Catalyst: Wes Hayutin, Harry will assist and ramp up > TripleO Team lead: John Trowbridge What does it mean, "TripleO Team lead" ? I'm confused because OpenStack upstream has also a TripleO Team lead. Did I miss something? > RDO Infra Team lead: Javier Pena > > > _______________________________________________ > 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 -- Emilien Macchi From whayutin at redhat.com Thu Oct 13 13:57:03 2016 From: whayutin at redhat.com (Wesley Hayutin) Date: Thu, 13 Oct 2016 09:57:03 -0400 Subject: [rdo-list] rdo infra scrum In-Reply-To: References: Message-ID: On Thu, Oct 13, 2016 at 9:52 AM, Emilien Macchi wrote: > On Tue, Oct 11, 2016 at 11:04 AM, Wesley Hayutin > wrote: > > Greetings, > > > > Latest scrum recording and notes > > > > https://bluejeans.com/s/FzK_2/ > > https://review.rdoproject.org/etherpad/p/rdo-infra-scrum > > > > Congrats to the new leadership of the RDO Infra team! > > > > Product Manager: Fred Lepied > > User advocate: 50% David Simard, 50% Attila > > Team Catalyst: Wes Hayutin, Harry will assist and ramp up > > TripleO Team lead: John Trowbridge > > What does it mean, "TripleO Team lead" ? > I'm confused because OpenStack upstream has also a TripleO Team lead. > Did I miss something? > That would read that as, the guy on the rdo infra team with enough tripleo and ci experience to be an immediate source of help to other members of the rdo infra team. We would expect this role to have the expertise for design topics. hope that helps > > > RDO Infra Team lead: Javier Pena > > > > > > _______________________________________________ > > 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 > > > > -- > Emilien Macchi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From whayutin at redhat.com Thu Oct 13 15:12:18 2016 From: whayutin at redhat.com (Wesley Hayutin) Date: Thu, 13 Oct 2016 11:12:18 -0400 Subject: [rdo-list] rdo infra scrum In-Reply-To: References: Message-ID: On Thu, Oct 13, 2016 at 9:57 AM, Wesley Hayutin wrote: > > > On Thu, Oct 13, 2016 at 9:52 AM, Emilien Macchi > wrote: > >> On Tue, Oct 11, 2016 at 11:04 AM, Wesley Hayutin >> wrote: >> > Greetings, >> > >> > Latest scrum recording and notes >> > >> > https://bluejeans.com/s/FzK_2/ >> > https://review.rdoproject.org/etherpad/p/rdo-infra-scrum >> > >> > Congrats to the new leadership of the RDO Infra team! >> > >> > Product Manager: Fred Lepied >> > User advocate: 50% David Simard, 50% Attila >> > Team Catalyst: Wes Hayutin, Harry will assist and ramp up >> > TripleO Team lead: John Trowbridge >> >> What does it mean, "TripleO Team lead" ? >> I'm confused because OpenStack upstream has also a TripleO Team lead. >> Did I miss something? >> > > That would read that as, the guy on the rdo infra team with enough tripleo > and ci experience to be an immediate source of help to other members of the > rdo infra team. > We would expect this role to have the expertise for design topics. > And the title of role is technical lead, not team lead.. sorry for the confusion and just a situation where I mispoke. Appologies.. - John Trowbridge (Engineering Tech Lead ) > > hope that helps > > >> >> > RDO Infra Team lead: Javier Pena >> > >> > >> > _______________________________________________ >> > 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 >> >> >> >> -- >> Emilien Macchi >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbowen at redhat.com Thu Oct 13 18:30:54 2016 From: rbowen at redhat.com (Rich Bowen) Date: Thu, 13 Oct 2016 14:30:54 -0400 Subject: [rdo-list] Fwd: An Evening of Ceph and RDO (schedule) In-Reply-To: References: Message-ID: <0bf6fb47-618b-a850-d8ca-31f68a53bb0e@redhat.com> FYI, this is the schedule of talks at the Ceph/RDO event in Barcelona on the 25th. -------- Forwarded Message -------- Subject: An Evening of Ceph and RDO (schedule) Date: Thu, 13 Oct 2016 11:38:10 -0400 From: Patrick McGarry These are all 5-10m lightning talks. Let me know if there are any questions. Thanks! Final Schedule: 0. Welcome and Intro (Patrick/Rich) 1. Jack Zhang, Intel -- 3D Xpoint & 3D NAND with OpenStack and Ceph 2. Ha?kel Gu?mar - RDO release status (aarch64, repos, workflow) 3. George Mihaiescu, Bioinformatics -- Openstack and Ceph used in large scale cancer research projects 4. Javier Pe?a - RDO repos overview (CBS vs Trunk, and what goes where) 5. Lars Marowsky Bree, SUSE -- Ceph at SUSE 6. Gulio Fidente: RDO and Ceph 7. Allen Samuels, Sandisk -- Bluestore Teaser 8. Jeff Chu, ARM -- Ceph on ARM 9. Jakub Ruzicka - quick look at new rpmfactory workflow with rdopkg 10. Dan van der Ster, CERN -- How to replace several petabytes of Ceph hardware without downtime 11. Alfredo Moralej - CI in RDO - what are we testing? 12. Sage Weil, Red Hat - Project Update From rbowen at redhat.com Thu Oct 13 18:40:18 2016 From: rbowen at redhat.com (Rich Bowen) Date: Thu, 13 Oct 2016 14:40:18 -0400 Subject: [rdo-list] FOSDEM: Virtualization and IaaS devroom call for papers Message-ID: Submission deadline: 18 November 2016 Acceptance notifications: 04 December 2016 Final schedule announcement: 11 December 2016 Devroom: 04 February 2017 (one day) Submit Your Proposal All submissions must be made via the Pentabarf event planning site. If you have not used Pentabarf before, you will need to create an account. If you submitted proposals for FOSDEM in previous years, you can use your existing account. After creating the account, select Create Event to start the submission process. Make sure to select Virtualisation and IaaS devroom from the Track list. Please fill out all the required fields, and provide a meaningful abstract and description of your proposed session. More details, and submission form, at http://www.ovirt.org/blog/2016/10/call-for-proposal-fosdem-2017/ -- Rich Bowen - rbowen at redhat.com RDO Community Liaison http://rdoproject.org @RDOCommunity From jtaleric at redhat.com Fri Oct 14 00:19:06 2016 From: jtaleric at redhat.com (Joe Talerico) Date: Thu, 13 Oct 2016 20:19:06 -0400 Subject: [rdo-list] Multiple tools for deploying and testing TripleO In-Reply-To: References: <045FCFDA-D59B-4D0D-B62A-0538980A051A@ltgfederal.com> <1470125532.18770.12.camel@ocf.co.uk> <20160803165119.GC25838@localhost.localdomain> Message-ID: Resurrecting a old thread... On Thu, Aug 4, 2016 at 5:10 AM, Tal Kammer wrote: > Reading this through I can't help but feel that once again we are straying > from the original intent of the discussion. > I also share the same feeling as Emilien and believe we should focus our > efforts on where it matters rather than having each group focus on one part > trying to "win" over the other. > > My concern since day 1 was that no one has asked what are the requirements > of each group and how does the tool serve that requirement. Simply put, the > requirement was "we need a CI tool" while I feel that the question of "what > is a CI tool?" or "what/who does it need to serve?" was never raised and was > left to self interpretation. > The result became that each group started working according to its own > understanding of a "CI tool" and I feel that even now, going over the e-mail > thread, this question is left unanswered. Wouldn't things be better if we as a collective team standardize on a "CI Tool"? > > I believe that in order to achieve a consensus around a tool, we should at > least agree first on the needs. > Some questions that come to mind: (feel free to pitch in more questions) > 1. should the tool provide provisioning? if yes, what type? (virsh? > openstack? foreman? etc..) --> this can be further discussed as it's quite a > subject to cover > 2. should the tool be Ansible based / other language? > 3. where do we push / maintain this tool? (I believe 'upstream' is the > answer but before it can officially accepted, we need a "midstream" place to > hold it) > 4. what other requirements does this tool needs to support? (does it need to > include testing as well? what is the proper "plugin" mechanism to maintain, > etc) > > Once we understand the above, we can ask: > 1. "is oooq the right tool to use/push upstream?" (maybe one of the other > projects like Octario, Weirdo, InfraRed, etc, has a better base / better > suited for the job?) > 2. "what are we looking for in such a tool?" (are we developing a tool for > CI? for Automation? can it be shared across products/projects or dedicated > Openstack tool? etc..) Khaleesi, InfraRed, and OOOQ, what is next? Within the scale and performance team we have been developing performance CI which is integrated with oooq. Since a different group uses InfraRed, they cannot take advantage of the work we have already done with oooq -- and this is much larger then just running tests. We have playbooks to monitor performance metrics of the under/overcloud so you can trend if memory usage is growing with each release/puddle/poodle (or whatever we call them now). >From my view, we are telling the community to choose which "CI tool" to go with. Instead we should converge on a single tool, and improve on that tool - fill whatever gaps exist. > > I propose that all CI groups meet up and present their tool to each other. > After that, we should have an open discussion on the pros and cons of each > tool allowing everyone to comment on the design openly. > Then after everyone shared their thoughts, we can start improving / create a > proper tool from the experience of everyone. > Whether it will be oooq based, InfraRed based or Octario based, it really > doesn't matter, as long as there is an open discussion (ego aside) and an > honest decision between all parties on how we can improve, we can get to > where everyone is aiming, a truly collaborative project by all groups. > > Thoughts? I agree, agenda's aside, egos left at the door. Let's come to some conclusion on what as a community we move forward with. > > On Thu, Aug 4, 2016 at 3:45 AM, Emilien Macchi wrote: >> >> On Wed, Aug 3, 2016 at 7:38 PM, Wesley Hayutin >> wrote: >> > >> > >> > On Wed, Aug 3, 2016 at 6:19 PM, Emilien Macchi >> > wrote: >> >> >> >> On Wed, Aug 3, 2016 at 1:33 PM, Wesley Hayutin >> >> wrote: >> >> > >> >> > >> >> > On Wed, Aug 3, 2016 at 12:51 PM, James Slagle >> >> > wrote: >> >> >> >> >> >> On Wed, Aug 03, 2016 at 11:36:57AM -0400, David Moreau Simard wrote: >> >> >> > Please hear me out. >> >> >> > TL;DR, Let's work upstream and make it awesome so that downstream >> >> >> > can >> >> >> > be awesome. >> >> >> > >> >> >> > I've said this before but I'm going to re-iterate that I do not >> >> >> > understand why there is so much effort spent around testing >> >> >> > TripleO >> >> >> > downstream. >> >> >> > By downstream, I mean anything that isn't in TripleO or TripleO-CI >> >> >> > proper. >> >> >> > >> >> >> > All this work should be done upstream to make TripleO and it's CI >> >> >> > super awesome and this would trickle down for free downstream. >> >> >> > >> >> >> > The RDO Trunk testing pipeline is composed of two tools, today. >> >> >> > The TripleO-Quickstart project [1] is a good example of an >> >> >> > initiative >> >> >> > that started downstream but always had the intention of being >> >> >> > proposed >> >> >> > upstream [2] after being "incubated" and fleshed out. >> >> >> >> >> >> tripleo-quickstart was proposed to upstream TripleO as a replacement >> >> >> for >> >> >> the >> >> >> virtual environment setup done by instack-virt-setup. 3rd party CI >> >> >> would >> >> >> be >> >> >> used to gate tripleo-quickstart so that we'd be sure the virt setup >> >> >> was >> >> >> always >> >> >> working. That was the extent of the CI scope defined in the spec. >> >> >> That >> >> >> work is >> >> >> not yet completed (see work items in the spec). >> >> >> >> >> >> Now it seems it is a much more all encompassing >> >> >> CI/automation/testing >> >> >> project >> >> >> that is competing in scope with tripleo-ci itself. >> >> > >> >> > >> >> > IMHO you are correct here. There has been quite a bit of discussion >> >> > about >> >> > removing the parts >> >> > of oooq that are outside of the original blueprint to replace >> >> > instack-virt-setup w/ oooq. As usual there are many different >> >> > opinions >> >> > here. I think there are a lot of RDO guys that would prefer a lot of >> >> > the >> >> > native oooq roles stay where they are, I think that is short sighted >> >> > imho. >> >> > I agree that anything outside of the blueprint be removed from oooq. >> >> > This >> >> > would hopefully allow the upstream to be more comfortable with oooq >> >> > and >> >> > allow us to really start consolidating tools. >> >> > >> >> > Luckily for the users that still want to use oooq as a full >> >> > end-to-end >> >> > solution the 3rd party roles can be used even after tearing out these >> >> > native >> >> > roles. >> >> > >> >> >> >> >> >> >> >> >> I'm all for consolidation of these types of tools *if* there is >> >> >> interest. >> >> > >> >> > >> >> > Roll call.. is there interest? +1 from me. >> >> > >> >> >> >> >> >> >> >> >> However, IMO, incubating these things downstream and then trying to >> >> >> get >> >> >> them >> >> >> upstream or get upstream to adopt them is not ideal or a good >> >> >> example. >> >> >> The >> >> >> same >> >> >> topic came up and was pushed several times with khaleesi, and it >> >> >> just >> >> >> never >> >> >> happened, it was continually DOA upstream. >> >> > >> >> > >> >> > True, however that could be a result of the downstream perceiving >> >> > barriers ( >> >> > real or not ) in incubating projects in upstream openstack. >> >> > >> >> >> >> >> >> >> >> >> I think it would be fairly difficult to get tripleo-ci to wholesale >> >> >> adopt >> >> >> tripleo-quickstart at this stage. The separate irc channel from >> >> >> #tripleo >> >> >> is not >> >> >> conducive to consolidation on tooling and direction imo. >> >> > >> >> > >> >> > The irc channel is easily addressed. We do seem to generate an awful >> >> > amount >> >> > of chatter though :) >> >> > >> >> >> >> >> >> >> >> >> The scope of quickstart is actually not fully understood by myself. >> >> >> I've >> >> >> also >> >> >> heard from some in the upstream TripleO community as well who are >> >> >> confused >> >> >> by >> >> >> its direction and are facing similar difficulties using its >> >> >> generated >> >> >> bash >> >> >> scripts that they'd be facing if they were just using TripleO >> >> >> documentation >> >> >> instead. >> >> > >> >> > >> >> > The point of the generated bash scripts is to create rst >> >> > documentation >> >> > and >> >> > reusable scripts for the end user. Since the documentation and the >> >> > generated scripts are equivalent I would expect the same errors, >> >> > problems >> >> > and issues. I see this as a good thing really. We *want* the CI to >> >> > hit >> >> > the >> >> > same issues as those who are following the doc. >> >> > >> >> >> >> >> >> >> >> >> I do think that this sort of problem lends itself easily to one off >> >> >> implementations as is quite evidenced in this thread. Everyone/group >> >> >> wants >> >> >> and >> >> >> needs to automate something in a different way. And imo, none of >> >> >> these >> >> >> tools >> >> >> are building end-user or operator facing interfaces, so they're not >> >> >> fully >> >> >> focused on building something that "just works for everyone". Those >> >> >> interfaces >> >> >> should be developed in TripleO user facing tooling anyway >> >> >> (tripleoclient/openstackclient/etc). >> >> >> >> >> >> So, I actually think it's ok in some degree that things have been >> >> >> automated >> >> >> differently in different tools. Anecdotally, I suspect many users of >> >> >> TripleO in >> >> >> production have their own automation tools as well. And none of the >> >> >> implementations mentioned in this thread would likely meet their >> >> >> needs >> >> >> either. >> >> > >> >> > >> >> > This is true.. without a tool in the upstream that addresses ci, >> >> > dev, >> >> > test >> >> > use cases across the development cycle this will continue to be the >> >> > case. I >> >> > suspect even with a perfect tool, it won't ever be perfect for >> >> > everyone. >> >> > >> >> >> >> >> >> >> >> >> However, if there is a desire to focus resources on consolidated >> >> >> tooling >> >> >> and >> >> >> someone to drive it forward, then I definitely agree that the effort >> >> >> needs >> >> >> to >> >> >> start upstream with a singular plan for tripleo-ci. From what I >> >> >> gather, >> >> >> that >> >> >> would be some sort of alignment and reuse of tripleo-quickstart, and >> >> >> then >> >> >> we >> >> >> could build from there. >> >> > >> >> > >> >> > +1 >> >> > >> >> >> >> >> >> >> >> >> That could start as a discussion and plan within that community with >> >> >> some >> >> >> agreed on concensus around that plan. There was an initial thread on >> >> >> openstack-dev related to this topic but it is stalled a bit. It >> >> >> could >> >> >> be >> >> >> continually driven to resolution via specs, the tripleo meeting, >> >> >> email >> >> >> or >> >> >> irc >> >> >> discussion until a plan is formed. >> >> > >> >> > >> >> > +1, I think the first step is to complete the original blueprint and >> >> > move >> >> > on from there. >> >> > I think there has also been interest in having an in person meeting >> >> > at >> >> > summit. >> >> > >> >> > Thanks! >> >> > >> >> >> >> >> >> >> >> >> -- >> >> >> -- James Slagle >> >> >> -- >> >> >> >> >> >> _______________________________________________ >> >> >> 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 >> >> >> >> I like how the discussion goes though I have some personal (and >> >> probably shared) feeling that I would like to share here, more or less >> >> related. >> >> >> >> As a TripleO core developer, I have some frustration to see that a lot >> >> of people are involved in making TripleO Quickstart better, while we >> >> have a few people actually working on tripleo-ci tool and try to >> >> maintain upstream CI stable. >> >> As a reminder, tripleo-ci tool is currently the ONLY ONE thing that >> >> actually gates TripleO, even if we don't like the tool. It is right >> >> now, testing TripleO upstream, everything that is not tested in there >> >> will probably break one day downstream CIs. >> >> Yes we have this tooling discussion here and that's awesome, but words >> >> are words. I would like to see some real engagement to help TripleO CI >> >> to converge into something better and not only everyone working on >> >> their side. >> > >> > >> > You have a valid point and reason to be frustrated. >> > Is the point here that everyone downstream should use tripleo.sh or that >> > everyone should be focused on ci and testing at the tripleo level? >> >> Not everyone should use tripleo.sh. My point is that we should move >> forward with a common tool, and stop enlarging the gap between tools. >> We have created (and are still doing) a technical dept where we have >> multiple tools with a ton of overlap, the more we wait, more difficult >> it will be to clean this up. >> >> >> >> >> >> >> Some examples: >> >> - TripleO Quickstart (downstream) CI has coverage for undercloud & >> >> overcloud upgrades while TripleO CI freshly has a undercloud upgrade >> >> job and used to have a overcloud (minor) upgrade job (disabled now, >> >> for some reasons related to our capacity to run jobs and also some >> >> blockers into code itself). >> >> - TripleO CI has some TripleO Heat templates that could also be re-use >> >> by TripleO Quickstart (I'm working on moving them from tripleo-ci to >> >> THT, WIP here: https://review.openstack.org/350775). >> >> - TripleO CI deploys Ceph Jewel repository, TripleO Quickstart doesn't. >> >> - (...) >> > >> > >> > As others have mentioned, there are at least 5-10 tools in development >> > that >> > are used to deploy tripleo in some CI fashion. Calling out >> > tripleo-quickstart alone is not quite right imho. There are a number >> > of >> > tripleo devs that burn cycles on their own ci tools and maybe that is >> > fine >> > thing to do. >> >> I called quickstart because that's the one I see everyday but my >> frustration is about all our tools in general. >> I'm actually a OOOQ user and I like this tool, really. >> But as you can see, I'm also working on tripleo-ci right now because I >> want TripleO CI better and I haven't seen until now some interest to >> converge. >> James started something cool by trying to deploy an undercloud using >> OOOQ from tripleo-ci. That's a start ! We need things like this, >> prototyping convergence, and see what we can do. >> >> > TripleO-Quickstart is meant to replace instack-virt-setup which it does >> > quite well. The only group that was actually running >> > instack-virt-setup >> > was the RDO CI team, upstream had taken it out of the ci system. I >> > think >> > it's not unfair to say gaps have been left for other teams to fill. >> >> Gotcha. It was just some examples. >> >> >> >> >> >> >> We have been having this discussion for a while now but we're still >> >> not making much progress here, I feel like we're in statu quo. >> >> James mentioned a blueprint, I like it. We need to engage some >> >> upstream discussion about this major CI refactor, like we need with >> >> specs and then we'll decide if whether or not we need to change the >> >> tool, and how. >> > >> > >> > Well, this would take some leadership imho. We need some people that >> > are >> > familiar with the upstream, midstream and downstream requirements of CI. >> > This was addressed at the production chain meetings initially but then >> > pretty much ignored. The leaders responsible at the various stages of >> > a >> > build (upstream -> downstream ) failed to take this issue on. Here we >> > are >> > today. >> > >> > Would it be acceptable by anyone.. IF >> > >> > tripleo-quickstart replaced instack-virt-setup [1] and walked through >> > the >> > undercloud install, then handed off to tripleo.sh to deploy, upgrade, >> > update, scale, validate etc??? >> >> That's something we can try. >> >> > That these two tools *would* in fact be the the official CI tools of >> > tripleo >> > at the upstream, RDO, and at least parts of the downstream? >> >> My opinion on this is that upstream and downstream CI should only differ >> on: >> * the packages (OSP vs RDO) >> * the scenarios (downstream could have customer-specific things) >> And that's it. Tools should remain the same IMHO. >> >> > Would that help to ease the current frustration around CI? Emilien what >> > do >> > you think? >> >> I spent the last months working on composable roles and I have now >> more time to work on CI; $topic is definitely something where I would >> like to help. >> -- >> Emilien Macchi >> >> _______________________________________________ >> 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 > > > > > -- > Tal Kammer > Associate manager, automation and infrastracture, Openstack platform. > Red Hat Israel > Automation group mojo: https://mojo.redhat.com/docs/DOC-1011659 > > _______________________________________________ > 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 emilien at redhat.com Fri Oct 14 00:51:24 2016 From: emilien at redhat.com (Emilien Macchi) Date: Thu, 13 Oct 2016 20:51:24 -0400 Subject: [rdo-list] rdo infra scrum In-Reply-To: References: Message-ID: On Thu, Oct 13, 2016 at 11:12 AM, Wesley Hayutin wrote: > > > On Thu, Oct 13, 2016 at 9:57 AM, Wesley Hayutin wrote: >> >> >> >> On Thu, Oct 13, 2016 at 9:52 AM, Emilien Macchi >> wrote: >>> >>> On Tue, Oct 11, 2016 at 11:04 AM, Wesley Hayutin >>> wrote: >>> > Greetings, >>> > >>> > Latest scrum recording and notes >>> > >>> > https://bluejeans.com/s/FzK_2/ >>> > https://review.rdoproject.org/etherpad/p/rdo-infra-scrum >>> > >>> > Congrats to the new leadership of the RDO Infra team! >>> > >>> > Product Manager: Fred Lepied >>> > User advocate: 50% David Simard, 50% Attila >>> > Team Catalyst: Wes Hayutin, Harry will assist and ramp up >>> > TripleO Team lead: John Trowbridge >>> >>> What does it mean, "TripleO Team lead" ? >>> I'm confused because OpenStack upstream has also a TripleO Team lead. >>> Did I miss something? >> >> >> That would read that as, the guy on the rdo infra team with enough tripleo >> and ci experience to be an immediate source of help to other members of the >> rdo infra team. >> We would expect this role to have the expertise for design topics. > > > And the title of role is technical lead, not team lead.. sorry for the > confusion and just a situation where I mispoke. Appologies.. No need to apology, it was just me wondering how the team is organized versus our upstream model. Thanks for clarifying it! > John Trowbridge (Engineering Tech Lead ) > > > > >> >> >> hope that helps >> >>> >>> >>> > RDO Infra Team lead: Javier Pena >>> > >>> > >>> > _______________________________________________ >>> > 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 >>> >>> >>> >>> -- >>> Emilien Macchi >> >> > -- Emilien Macchi From emilien at redhat.com Fri Oct 14 00:54:06 2016 From: emilien at redhat.com (Emilien Macchi) Date: Thu, 13 Oct 2016 20:54:06 -0400 Subject: [rdo-list] Multiple tools for deploying and testing TripleO In-Reply-To: References: <045FCFDA-D59B-4D0D-B62A-0538980A051A@ltgfederal.com> <1470125532.18770.12.camel@ocf.co.uk> <20160803165119.GC25838@localhost.localdomain> Message-ID: On Thu, Oct 13, 2016 at 8:19 PM, Joe Talerico wrote: > Resurrecting a old thread... > > On Thu, Aug 4, 2016 at 5:10 AM, Tal Kammer wrote: >> Reading this through I can't help but feel that once again we are straying >> from the original intent of the discussion. >> I also share the same feeling as Emilien and believe we should focus our >> efforts on where it matters rather than having each group focus on one part >> trying to "win" over the other. >> >> My concern since day 1 was that no one has asked what are the requirements >> of each group and how does the tool serve that requirement. Simply put, the >> requirement was "we need a CI tool" while I feel that the question of "what >> is a CI tool?" or "what/who does it need to serve?" was never raised and was >> left to self interpretation. >> The result became that each group started working according to its own >> understanding of a "CI tool" and I feel that even now, going over the e-mail >> thread, this question is left unanswered. > > Wouldn't things be better if we as a collective team standardize on a "CI Tool"? > >> >> I believe that in order to achieve a consensus around a tool, we should at >> least agree first on the needs. >> Some questions that come to mind: (feel free to pitch in more questions) >> 1. should the tool provide provisioning? if yes, what type? (virsh? >> openstack? foreman? etc..) --> this can be further discussed as it's quite a >> subject to cover >> 2. should the tool be Ansible based / other language? >> 3. where do we push / maintain this tool? (I believe 'upstream' is the >> answer but before it can officially accepted, we need a "midstream" place to >> hold it) >> 4. what other requirements does this tool needs to support? (does it need to >> include testing as well? what is the proper "plugin" mechanism to maintain, >> etc) >> >> Once we understand the above, we can ask: >> 1. "is oooq the right tool to use/push upstream?" (maybe one of the other >> projects like Octario, Weirdo, InfraRed, etc, has a better base / better >> suited for the job?) >> 2. "what are we looking for in such a tool?" (are we developing a tool for >> CI? for Automation? can it be shared across products/projects or dedicated >> Openstack tool? etc..) > > Khaleesi, InfraRed, and OOOQ, what is next? > > Within the scale and performance team we have been developing > performance CI which is integrated with oooq. Since a different group > uses InfraRed, they cannot take advantage of the work we have already > done with oooq -- and this is much larger then just running tests. We > have playbooks to monitor performance metrics of the under/overcloud > so you can trend if memory usage is growing with each > release/puddle/poodle (or whatever we call them now). > > From my view, we are telling the community to choose which "CI tool" > to go with. Instead we should converge on a single tool, and improve > on that tool - fill whatever gaps exist. > >> >> I propose that all CI groups meet up and present their tool to each other. >> After that, we should have an open discussion on the pros and cons of each >> tool allowing everyone to comment on the design openly. >> Then after everyone shared their thoughts, we can start improving / create a >> proper tool from the experience of everyone. >> Whether it will be oooq based, InfraRed based or Octario based, it really >> doesn't matter, as long as there is an open discussion (ego aside) and an >> honest decision between all parties on how we can improve, we can get to >> where everyone is aiming, a truly collaborative project by all groups. >> >> Thoughts? > > I agree, agenda's aside, egos left at the door. Let's come to some > conclusion on what as a community we move forward with. Joe, you are welcome to: 1) Join our TripleO design session about CI (Barcelona) - https://etherpad.openstack.org/p/ocata-tripleo 2) Contribute to the specs that Wes is proposing about OOOQ: https://review.openstack.org/#/c/386250/ We're all aware about this challenge and we consider it as an essential topic in our roadmap. Thanks for your feedback, > >> >> On Thu, Aug 4, 2016 at 3:45 AM, Emilien Macchi wrote: >>> >>> On Wed, Aug 3, 2016 at 7:38 PM, Wesley Hayutin >>> wrote: >>> > >>> > >>> > On Wed, Aug 3, 2016 at 6:19 PM, Emilien Macchi >>> > wrote: >>> >> >>> >> On Wed, Aug 3, 2016 at 1:33 PM, Wesley Hayutin >>> >> wrote: >>> >> > >>> >> > >>> >> > On Wed, Aug 3, 2016 at 12:51 PM, James Slagle >>> >> > wrote: >>> >> >> >>> >> >> On Wed, Aug 03, 2016 at 11:36:57AM -0400, David Moreau Simard wrote: >>> >> >> > Please hear me out. >>> >> >> > TL;DR, Let's work upstream and make it awesome so that downstream >>> >> >> > can >>> >> >> > be awesome. >>> >> >> > >>> >> >> > I've said this before but I'm going to re-iterate that I do not >>> >> >> > understand why there is so much effort spent around testing >>> >> >> > TripleO >>> >> >> > downstream. >>> >> >> > By downstream, I mean anything that isn't in TripleO or TripleO-CI >>> >> >> > proper. >>> >> >> > >>> >> >> > All this work should be done upstream to make TripleO and it's CI >>> >> >> > super awesome and this would trickle down for free downstream. >>> >> >> > >>> >> >> > The RDO Trunk testing pipeline is composed of two tools, today. >>> >> >> > The TripleO-Quickstart project [1] is a good example of an >>> >> >> > initiative >>> >> >> > that started downstream but always had the intention of being >>> >> >> > proposed >>> >> >> > upstream [2] after being "incubated" and fleshed out. >>> >> >> >>> >> >> tripleo-quickstart was proposed to upstream TripleO as a replacement >>> >> >> for >>> >> >> the >>> >> >> virtual environment setup done by instack-virt-setup. 3rd party CI >>> >> >> would >>> >> >> be >>> >> >> used to gate tripleo-quickstart so that we'd be sure the virt setup >>> >> >> was >>> >> >> always >>> >> >> working. That was the extent of the CI scope defined in the spec. >>> >> >> That >>> >> >> work is >>> >> >> not yet completed (see work items in the spec). >>> >> >> >>> >> >> Now it seems it is a much more all encompassing >>> >> >> CI/automation/testing >>> >> >> project >>> >> >> that is competing in scope with tripleo-ci itself. >>> >> > >>> >> > >>> >> > IMHO you are correct here. There has been quite a bit of discussion >>> >> > about >>> >> > removing the parts >>> >> > of oooq that are outside of the original blueprint to replace >>> >> > instack-virt-setup w/ oooq. As usual there are many different >>> >> > opinions >>> >> > here. I think there are a lot of RDO guys that would prefer a lot of >>> >> > the >>> >> > native oooq roles stay where they are, I think that is short sighted >>> >> > imho. >>> >> > I agree that anything outside of the blueprint be removed from oooq. >>> >> > This >>> >> > would hopefully allow the upstream to be more comfortable with oooq >>> >> > and >>> >> > allow us to really start consolidating tools. >>> >> > >>> >> > Luckily for the users that still want to use oooq as a full >>> >> > end-to-end >>> >> > solution the 3rd party roles can be used even after tearing out these >>> >> > native >>> >> > roles. >>> >> > >>> >> >> >>> >> >> >>> >> >> I'm all for consolidation of these types of tools *if* there is >>> >> >> interest. >>> >> > >>> >> > >>> >> > Roll call.. is there interest? +1 from me. >>> >> > >>> >> >> >>> >> >> >>> >> >> However, IMO, incubating these things downstream and then trying to >>> >> >> get >>> >> >> them >>> >> >> upstream or get upstream to adopt them is not ideal or a good >>> >> >> example. >>> >> >> The >>> >> >> same >>> >> >> topic came up and was pushed several times with khaleesi, and it >>> >> >> just >>> >> >> never >>> >> >> happened, it was continually DOA upstream. >>> >> > >>> >> > >>> >> > True, however that could be a result of the downstream perceiving >>> >> > barriers ( >>> >> > real or not ) in incubating projects in upstream openstack. >>> >> > >>> >> >> >>> >> >> >>> >> >> I think it would be fairly difficult to get tripleo-ci to wholesale >>> >> >> adopt >>> >> >> tripleo-quickstart at this stage. The separate irc channel from >>> >> >> #tripleo >>> >> >> is not >>> >> >> conducive to consolidation on tooling and direction imo. >>> >> > >>> >> > >>> >> > The irc channel is easily addressed. We do seem to generate an awful >>> >> > amount >>> >> > of chatter though :) >>> >> > >>> >> >> >>> >> >> >>> >> >> The scope of quickstart is actually not fully understood by myself. >>> >> >> I've >>> >> >> also >>> >> >> heard from some in the upstream TripleO community as well who are >>> >> >> confused >>> >> >> by >>> >> >> its direction and are facing similar difficulties using its >>> >> >> generated >>> >> >> bash >>> >> >> scripts that they'd be facing if they were just using TripleO >>> >> >> documentation >>> >> >> instead. >>> >> > >>> >> > >>> >> > The point of the generated bash scripts is to create rst >>> >> > documentation >>> >> > and >>> >> > reusable scripts for the end user. Since the documentation and the >>> >> > generated scripts are equivalent I would expect the same errors, >>> >> > problems >>> >> > and issues. I see this as a good thing really. We *want* the CI to >>> >> > hit >>> >> > the >>> >> > same issues as those who are following the doc. >>> >> > >>> >> >> >>> >> >> >>> >> >> I do think that this sort of problem lends itself easily to one off >>> >> >> implementations as is quite evidenced in this thread. Everyone/group >>> >> >> wants >>> >> >> and >>> >> >> needs to automate something in a different way. And imo, none of >>> >> >> these >>> >> >> tools >>> >> >> are building end-user or operator facing interfaces, so they're not >>> >> >> fully >>> >> >> focused on building something that "just works for everyone". Those >>> >> >> interfaces >>> >> >> should be developed in TripleO user facing tooling anyway >>> >> >> (tripleoclient/openstackclient/etc). >>> >> >> >>> >> >> So, I actually think it's ok in some degree that things have been >>> >> >> automated >>> >> >> differently in different tools. Anecdotally, I suspect many users of >>> >> >> TripleO in >>> >> >> production have their own automation tools as well. And none of the >>> >> >> implementations mentioned in this thread would likely meet their >>> >> >> needs >>> >> >> either. >>> >> > >>> >> > >>> >> > This is true.. without a tool in the upstream that addresses ci, >>> >> > dev, >>> >> > test >>> >> > use cases across the development cycle this will continue to be the >>> >> > case. I >>> >> > suspect even with a perfect tool, it won't ever be perfect for >>> >> > everyone. >>> >> > >>> >> >> >>> >> >> >>> >> >> However, if there is a desire to focus resources on consolidated >>> >> >> tooling >>> >> >> and >>> >> >> someone to drive it forward, then I definitely agree that the effort >>> >> >> needs >>> >> >> to >>> >> >> start upstream with a singular plan for tripleo-ci. From what I >>> >> >> gather, >>> >> >> that >>> >> >> would be some sort of alignment and reuse of tripleo-quickstart, and >>> >> >> then >>> >> >> we >>> >> >> could build from there. >>> >> > >>> >> > >>> >> > +1 >>> >> > >>> >> >> >>> >> >> >>> >> >> That could start as a discussion and plan within that community with >>> >> >> some >>> >> >> agreed on concensus around that plan. There was an initial thread on >>> >> >> openstack-dev related to this topic but it is stalled a bit. It >>> >> >> could >>> >> >> be >>> >> >> continually driven to resolution via specs, the tripleo meeting, >>> >> >> email >>> >> >> or >>> >> >> irc >>> >> >> discussion until a plan is formed. >>> >> > >>> >> > >>> >> > +1, I think the first step is to complete the original blueprint and >>> >> > move >>> >> > on from there. >>> >> > I think there has also been interest in having an in person meeting >>> >> > at >>> >> > summit. >>> >> > >>> >> > Thanks! >>> >> > >>> >> >> >>> >> >> >>> >> >> -- >>> >> >> -- James Slagle >>> >> >> -- >>> >> >> >>> >> >> _______________________________________________ >>> >> >> 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 >>> >> >>> >> I like how the discussion goes though I have some personal (and >>> >> probably shared) feeling that I would like to share here, more or less >>> >> related. >>> >> >>> >> As a TripleO core developer, I have some frustration to see that a lot >>> >> of people are involved in making TripleO Quickstart better, while we >>> >> have a few people actually working on tripleo-ci tool and try to >>> >> maintain upstream CI stable. >>> >> As a reminder, tripleo-ci tool is currently the ONLY ONE thing that >>> >> actually gates TripleO, even if we don't like the tool. It is right >>> >> now, testing TripleO upstream, everything that is not tested in there >>> >> will probably break one day downstream CIs. >>> >> Yes we have this tooling discussion here and that's awesome, but words >>> >> are words. I would like to see some real engagement to help TripleO CI >>> >> to converge into something better and not only everyone working on >>> >> their side. >>> > >>> > >>> > You have a valid point and reason to be frustrated. >>> > Is the point here that everyone downstream should use tripleo.sh or that >>> > everyone should be focused on ci and testing at the tripleo level? >>> >>> Not everyone should use tripleo.sh. My point is that we should move >>> forward with a common tool, and stop enlarging the gap between tools. >>> We have created (and are still doing) a technical dept where we have >>> multiple tools with a ton of overlap, the more we wait, more difficult >>> it will be to clean this up. >>> >>> >> >>> >> >>> >> Some examples: >>> >> - TripleO Quickstart (downstream) CI has coverage for undercloud & >>> >> overcloud upgrades while TripleO CI freshly has a undercloud upgrade >>> >> job and used to have a overcloud (minor) upgrade job (disabled now, >>> >> for some reasons related to our capacity to run jobs and also some >>> >> blockers into code itself). >>> >> - TripleO CI has some TripleO Heat templates that could also be re-use >>> >> by TripleO Quickstart (I'm working on moving them from tripleo-ci to >>> >> THT, WIP here: https://review.openstack.org/350775). >>> >> - TripleO CI deploys Ceph Jewel repository, TripleO Quickstart doesn't. >>> >> - (...) >>> > >>> > >>> > As others have mentioned, there are at least 5-10 tools in development >>> > that >>> > are used to deploy tripleo in some CI fashion. Calling out >>> > tripleo-quickstart alone is not quite right imho. There are a number >>> > of >>> > tripleo devs that burn cycles on their own ci tools and maybe that is >>> > fine >>> > thing to do. >>> >>> I called quickstart because that's the one I see everyday but my >>> frustration is about all our tools in general. >>> I'm actually a OOOQ user and I like this tool, really. >>> But as you can see, I'm also working on tripleo-ci right now because I >>> want TripleO CI better and I haven't seen until now some interest to >>> converge. >>> James started something cool by trying to deploy an undercloud using >>> OOOQ from tripleo-ci. That's a start ! We need things like this, >>> prototyping convergence, and see what we can do. >>> >>> > TripleO-Quickstart is meant to replace instack-virt-setup which it does >>> > quite well. The only group that was actually running >>> > instack-virt-setup >>> > was the RDO CI team, upstream had taken it out of the ci system. I >>> > think >>> > it's not unfair to say gaps have been left for other teams to fill. >>> >>> Gotcha. It was just some examples. >>> >>> >> >>> >> >>> >> We have been having this discussion for a while now but we're still >>> >> not making much progress here, I feel like we're in statu quo. >>> >> James mentioned a blueprint, I like it. We need to engage some >>> >> upstream discussion about this major CI refactor, like we need with >>> >> specs and then we'll decide if whether or not we need to change the >>> >> tool, and how. >>> > >>> > >>> > Well, this would take some leadership imho. We need some people that >>> > are >>> > familiar with the upstream, midstream and downstream requirements of CI. >>> > This was addressed at the production chain meetings initially but then >>> > pretty much ignored. The leaders responsible at the various stages of >>> > a >>> > build (upstream -> downstream ) failed to take this issue on. Here we >>> > are >>> > today. >>> > >>> > Would it be acceptable by anyone.. IF >>> > >>> > tripleo-quickstart replaced instack-virt-setup [1] and walked through >>> > the >>> > undercloud install, then handed off to tripleo.sh to deploy, upgrade, >>> > update, scale, validate etc??? >>> >>> That's something we can try. >>> >>> > That these two tools *would* in fact be the the official CI tools of >>> > tripleo >>> > at the upstream, RDO, and at least parts of the downstream? >>> >>> My opinion on this is that upstream and downstream CI should only differ >>> on: >>> * the packages (OSP vs RDO) >>> * the scenarios (downstream could have customer-specific things) >>> And that's it. Tools should remain the same IMHO. >>> >>> > Would that help to ease the current frustration around CI? Emilien what >>> > do >>> > you think? >>> >>> I spent the last months working on composable roles and I have now >>> more time to work on CI; $topic is definitely something where I would >>> like to help. >>> -- >>> Emilien Macchi >>> >>> _______________________________________________ >>> 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 >> >> >> >> >> -- >> Tal Kammer >> Associate manager, automation and infrastracture, Openstack platform. >> Red Hat Israel >> Automation group mojo: https://mojo.redhat.com/docs/DOC-1011659 >> >> _______________________________________________ >> 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 -- Emilien Macchi From jtaleric at redhat.com Fri Oct 14 01:10:51 2016 From: jtaleric at redhat.com (Joe Talerico) Date: Thu, 13 Oct 2016 21:10:51 -0400 Subject: [rdo-list] Multiple tools for deploying and testing TripleO In-Reply-To: References: <045FCFDA-D59B-4D0D-B62A-0538980A051A@ltgfederal.com> <1470125532.18770.12.camel@ocf.co.uk> <20160803165119.GC25838@localhost.localdomain> Message-ID: On Thu, Oct 13, 2016 at 8:54 PM, Emilien Macchi wrote: > On Thu, Oct 13, 2016 at 8:19 PM, Joe Talerico wrote: >> Resurrecting a old thread... >> >> On Thu, Aug 4, 2016 at 5:10 AM, Tal Kammer wrote: >>> Reading this through I can't help but feel that once again we are straying >>> from the original intent of the discussion. >>> I also share the same feeling as Emilien and believe we should focus our >>> efforts on where it matters rather than having each group focus on one part >>> trying to "win" over the other. >>> >>> My concern since day 1 was that no one has asked what are the requirements >>> of each group and how does the tool serve that requirement. Simply put, the >>> requirement was "we need a CI tool" while I feel that the question of "what >>> is a CI tool?" or "what/who does it need to serve?" was never raised and was >>> left to self interpretation. >>> The result became that each group started working according to its own >>> understanding of a "CI tool" and I feel that even now, going over the e-mail >>> thread, this question is left unanswered. >> >> Wouldn't things be better if we as a collective team standardize on a "CI Tool"? >> >>> >>> I believe that in order to achieve a consensus around a tool, we should at >>> least agree first on the needs. >>> Some questions that come to mind: (feel free to pitch in more questions) >>> 1. should the tool provide provisioning? if yes, what type? (virsh? >>> openstack? foreman? etc..) --> this can be further discussed as it's quite a >>> subject to cover >>> 2. should the tool be Ansible based / other language? >>> 3. where do we push / maintain this tool? (I believe 'upstream' is the >>> answer but before it can officially accepted, we need a "midstream" place to >>> hold it) >>> 4. what other requirements does this tool needs to support? (does it need to >>> include testing as well? what is the proper "plugin" mechanism to maintain, >>> etc) >>> >>> Once we understand the above, we can ask: >>> 1. "is oooq the right tool to use/push upstream?" (maybe one of the other >>> projects like Octario, Weirdo, InfraRed, etc, has a better base / better >>> suited for the job?) >>> 2. "what are we looking for in such a tool?" (are we developing a tool for >>> CI? for Automation? can it be shared across products/projects or dedicated >>> Openstack tool? etc..) >> >> Khaleesi, InfraRed, and OOOQ, what is next? >> >> Within the scale and performance team we have been developing >> performance CI which is integrated with oooq. Since a different group >> uses InfraRed, they cannot take advantage of the work we have already >> done with oooq -- and this is much larger then just running tests. We >> have playbooks to monitor performance metrics of the under/overcloud >> so you can trend if memory usage is growing with each >> release/puddle/poodle (or whatever we call them now). >> >> From my view, we are telling the community to choose which "CI tool" >> to go with. Instead we should converge on a single tool, and improve >> on that tool - fill whatever gaps exist. >> >>> >>> I propose that all CI groups meet up and present their tool to each other. >>> After that, we should have an open discussion on the pros and cons of each >>> tool allowing everyone to comment on the design openly. >>> Then after everyone shared their thoughts, we can start improving / create a >>> proper tool from the experience of everyone. >>> Whether it will be oooq based, InfraRed based or Octario based, it really >>> doesn't matter, as long as there is an open discussion (ego aside) and an >>> honest decision between all parties on how we can improve, we can get to >>> where everyone is aiming, a truly collaborative project by all groups. >>> >>> Thoughts? >> >> I agree, agenda's aside, egos left at the door. Let's come to some >> conclusion on what as a community we move forward with. > > Joe, you are welcome to: Thanks for the offer Emilien. > > 1) Join our TripleO design session about CI (Barcelona) - > https://etherpad.openstack.org/p/ocata-tripleo > 2) Contribute to the specs that Wes is proposing about OOOQ: > https://review.openstack.org/#/c/386250/ > > We're all aware about this challenge and we consider it as an > essential topic in our roadmap. Glad to hear that, looking forward to progress being made here. Joe > Thanks for your feedback, > >> >>> >>> On Thu, Aug 4, 2016 at 3:45 AM, Emilien Macchi wrote: >>>> >>>> On Wed, Aug 3, 2016 at 7:38 PM, Wesley Hayutin >>>> wrote: >>>> > >>>> > >>>> > On Wed, Aug 3, 2016 at 6:19 PM, Emilien Macchi >>>> > wrote: >>>> >> >>>> >> On Wed, Aug 3, 2016 at 1:33 PM, Wesley Hayutin >>>> >> wrote: >>>> >> > >>>> >> > >>>> >> > On Wed, Aug 3, 2016 at 12:51 PM, James Slagle >>>> >> > wrote: >>>> >> >> >>>> >> >> On Wed, Aug 03, 2016 at 11:36:57AM -0400, David Moreau Simard wrote: >>>> >> >> > Please hear me out. >>>> >> >> > TL;DR, Let's work upstream and make it awesome so that downstream >>>> >> >> > can >>>> >> >> > be awesome. >>>> >> >> > >>>> >> >> > I've said this before but I'm going to re-iterate that I do not >>>> >> >> > understand why there is so much effort spent around testing >>>> >> >> > TripleO >>>> >> >> > downstream. >>>> >> >> > By downstream, I mean anything that isn't in TripleO or TripleO-CI >>>> >> >> > proper. >>>> >> >> > >>>> >> >> > All this work should be done upstream to make TripleO and it's CI >>>> >> >> > super awesome and this would trickle down for free downstream. >>>> >> >> > >>>> >> >> > The RDO Trunk testing pipeline is composed of two tools, today. >>>> >> >> > The TripleO-Quickstart project [1] is a good example of an >>>> >> >> > initiative >>>> >> >> > that started downstream but always had the intention of being >>>> >> >> > proposed >>>> >> >> > upstream [2] after being "incubated" and fleshed out. >>>> >> >> >>>> >> >> tripleo-quickstart was proposed to upstream TripleO as a replacement >>>> >> >> for >>>> >> >> the >>>> >> >> virtual environment setup done by instack-virt-setup. 3rd party CI >>>> >> >> would >>>> >> >> be >>>> >> >> used to gate tripleo-quickstart so that we'd be sure the virt setup >>>> >> >> was >>>> >> >> always >>>> >> >> working. That was the extent of the CI scope defined in the spec. >>>> >> >> That >>>> >> >> work is >>>> >> >> not yet completed (see work items in the spec). >>>> >> >> >>>> >> >> Now it seems it is a much more all encompassing >>>> >> >> CI/automation/testing >>>> >> >> project >>>> >> >> that is competing in scope with tripleo-ci itself. >>>> >> > >>>> >> > >>>> >> > IMHO you are correct here. There has been quite a bit of discussion >>>> >> > about >>>> >> > removing the parts >>>> >> > of oooq that are outside of the original blueprint to replace >>>> >> > instack-virt-setup w/ oooq. As usual there are many different >>>> >> > opinions >>>> >> > here. I think there are a lot of RDO guys that would prefer a lot of >>>> >> > the >>>> >> > native oooq roles stay where they are, I think that is short sighted >>>> >> > imho. >>>> >> > I agree that anything outside of the blueprint be removed from oooq. >>>> >> > This >>>> >> > would hopefully allow the upstream to be more comfortable with oooq >>>> >> > and >>>> >> > allow us to really start consolidating tools. >>>> >> > >>>> >> > Luckily for the users that still want to use oooq as a full >>>> >> > end-to-end >>>> >> > solution the 3rd party roles can be used even after tearing out these >>>> >> > native >>>> >> > roles. >>>> >> > >>>> >> >> >>>> >> >> >>>> >> >> I'm all for consolidation of these types of tools *if* there is >>>> >> >> interest. >>>> >> > >>>> >> > >>>> >> > Roll call.. is there interest? +1 from me. >>>> >> > >>>> >> >> >>>> >> >> >>>> >> >> However, IMO, incubating these things downstream and then trying to >>>> >> >> get >>>> >> >> them >>>> >> >> upstream or get upstream to adopt them is not ideal or a good >>>> >> >> example. >>>> >> >> The >>>> >> >> same >>>> >> >> topic came up and was pushed several times with khaleesi, and it >>>> >> >> just >>>> >> >> never >>>> >> >> happened, it was continually DOA upstream. >>>> >> > >>>> >> > >>>> >> > True, however that could be a result of the downstream perceiving >>>> >> > barriers ( >>>> >> > real or not ) in incubating projects in upstream openstack. >>>> >> > >>>> >> >> >>>> >> >> >>>> >> >> I think it would be fairly difficult to get tripleo-ci to wholesale >>>> >> >> adopt >>>> >> >> tripleo-quickstart at this stage. The separate irc channel from >>>> >> >> #tripleo >>>> >> >> is not >>>> >> >> conducive to consolidation on tooling and direction imo. >>>> >> > >>>> >> > >>>> >> > The irc channel is easily addressed. We do seem to generate an awful >>>> >> > amount >>>> >> > of chatter though :) >>>> >> > >>>> >> >> >>>> >> >> >>>> >> >> The scope of quickstart is actually not fully understood by myself. >>>> >> >> I've >>>> >> >> also >>>> >> >> heard from some in the upstream TripleO community as well who are >>>> >> >> confused >>>> >> >> by >>>> >> >> its direction and are facing similar difficulties using its >>>> >> >> generated >>>> >> >> bash >>>> >> >> scripts that they'd be facing if they were just using TripleO >>>> >> >> documentation >>>> >> >> instead. >>>> >> > >>>> >> > >>>> >> > The point of the generated bash scripts is to create rst >>>> >> > documentation >>>> >> > and >>>> >> > reusable scripts for the end user. Since the documentation and the >>>> >> > generated scripts are equivalent I would expect the same errors, >>>> >> > problems >>>> >> > and issues. I see this as a good thing really. We *want* the CI to >>>> >> > hit >>>> >> > the >>>> >> > same issues as those who are following the doc. >>>> >> > >>>> >> >> >>>> >> >> >>>> >> >> I do think that this sort of problem lends itself easily to one off >>>> >> >> implementations as is quite evidenced in this thread. Everyone/group >>>> >> >> wants >>>> >> >> and >>>> >> >> needs to automate something in a different way. And imo, none of >>>> >> >> these >>>> >> >> tools >>>> >> >> are building end-user or operator facing interfaces, so they're not >>>> >> >> fully >>>> >> >> focused on building something that "just works for everyone". Those >>>> >> >> interfaces >>>> >> >> should be developed in TripleO user facing tooling anyway >>>> >> >> (tripleoclient/openstackclient/etc). >>>> >> >> >>>> >> >> So, I actually think it's ok in some degree that things have been >>>> >> >> automated >>>> >> >> differently in different tools. Anecdotally, I suspect many users of >>>> >> >> TripleO in >>>> >> >> production have their own automation tools as well. And none of the >>>> >> >> implementations mentioned in this thread would likely meet their >>>> >> >> needs >>>> >> >> either. >>>> >> > >>>> >> > >>>> >> > This is true.. without a tool in the upstream that addresses ci, >>>> >> > dev, >>>> >> > test >>>> >> > use cases across the development cycle this will continue to be the >>>> >> > case. I >>>> >> > suspect even with a perfect tool, it won't ever be perfect for >>>> >> > everyone. >>>> >> > >>>> >> >> >>>> >> >> >>>> >> >> However, if there is a desire to focus resources on consolidated >>>> >> >> tooling >>>> >> >> and >>>> >> >> someone to drive it forward, then I definitely agree that the effort >>>> >> >> needs >>>> >> >> to >>>> >> >> start upstream with a singular plan for tripleo-ci. From what I >>>> >> >> gather, >>>> >> >> that >>>> >> >> would be some sort of alignment and reuse of tripleo-quickstart, and >>>> >> >> then >>>> >> >> we >>>> >> >> could build from there. >>>> >> > >>>> >> > >>>> >> > +1 >>>> >> > >>>> >> >> >>>> >> >> >>>> >> >> That could start as a discussion and plan within that community with >>>> >> >> some >>>> >> >> agreed on concensus around that plan. There was an initial thread on >>>> >> >> openstack-dev related to this topic but it is stalled a bit. It >>>> >> >> could >>>> >> >> be >>>> >> >> continually driven to resolution via specs, the tripleo meeting, >>>> >> >> email >>>> >> >> or >>>> >> >> irc >>>> >> >> discussion until a plan is formed. >>>> >> > >>>> >> > >>>> >> > +1, I think the first step is to complete the original blueprint and >>>> >> > move >>>> >> > on from there. >>>> >> > I think there has also been interest in having an in person meeting >>>> >> > at >>>> >> > summit. >>>> >> > >>>> >> > Thanks! >>>> >> > >>>> >> >> >>>> >> >> >>>> >> >> -- >>>> >> >> -- James Slagle >>>> >> >> -- >>>> >> >> >>>> >> >> _______________________________________________ >>>> >> >> 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 >>>> >> >>>> >> I like how the discussion goes though I have some personal (and >>>> >> probably shared) feeling that I would like to share here, more or less >>>> >> related. >>>> >> >>>> >> As a TripleO core developer, I have some frustration to see that a lot >>>> >> of people are involved in making TripleO Quickstart better, while we >>>> >> have a few people actually working on tripleo-ci tool and try to >>>> >> maintain upstream CI stable. >>>> >> As a reminder, tripleo-ci tool is currently the ONLY ONE thing that >>>> >> actually gates TripleO, even if we don't like the tool. It is right >>>> >> now, testing TripleO upstream, everything that is not tested in there >>>> >> will probably break one day downstream CIs. >>>> >> Yes we have this tooling discussion here and that's awesome, but words >>>> >> are words. I would like to see some real engagement to help TripleO CI >>>> >> to converge into something better and not only everyone working on >>>> >> their side. >>>> > >>>> > >>>> > You have a valid point and reason to be frustrated. >>>> > Is the point here that everyone downstream should use tripleo.sh or that >>>> > everyone should be focused on ci and testing at the tripleo level? >>>> >>>> Not everyone should use tripleo.sh. My point is that we should move >>>> forward with a common tool, and stop enlarging the gap between tools. >>>> We have created (and are still doing) a technical dept where we have >>>> multiple tools with a ton of overlap, the more we wait, more difficult >>>> it will be to clean this up. >>>> >>>> >> >>>> >> >>>> >> Some examples: >>>> >> - TripleO Quickstart (downstream) CI has coverage for undercloud & >>>> >> overcloud upgrades while TripleO CI freshly has a undercloud upgrade >>>> >> job and used to have a overcloud (minor) upgrade job (disabled now, >>>> >> for some reasons related to our capacity to run jobs and also some >>>> >> blockers into code itself). >>>> >> - TripleO CI has some TripleO Heat templates that could also be re-use >>>> >> by TripleO Quickstart (I'm working on moving them from tripleo-ci to >>>> >> THT, WIP here: https://review.openstack.org/350775). >>>> >> - TripleO CI deploys Ceph Jewel repository, TripleO Quickstart doesn't. >>>> >> - (...) >>>> > >>>> > >>>> > As others have mentioned, there are at least 5-10 tools in development >>>> > that >>>> > are used to deploy tripleo in some CI fashion. Calling out >>>> > tripleo-quickstart alone is not quite right imho. There are a number >>>> > of >>>> > tripleo devs that burn cycles on their own ci tools and maybe that is >>>> > fine >>>> > thing to do. >>>> >>>> I called quickstart because that's the one I see everyday but my >>>> frustration is about all our tools in general. >>>> I'm actually a OOOQ user and I like this tool, really. >>>> But as you can see, I'm also working on tripleo-ci right now because I >>>> want TripleO CI better and I haven't seen until now some interest to >>>> converge. >>>> James started something cool by trying to deploy an undercloud using >>>> OOOQ from tripleo-ci. That's a start ! We need things like this, >>>> prototyping convergence, and see what we can do. >>>> >>>> > TripleO-Quickstart is meant to replace instack-virt-setup which it does >>>> > quite well. The only group that was actually running >>>> > instack-virt-setup >>>> > was the RDO CI team, upstream had taken it out of the ci system. I >>>> > think >>>> > it's not unfair to say gaps have been left for other teams to fill. >>>> >>>> Gotcha. It was just some examples. >>>> >>>> >> >>>> >> >>>> >> We have been having this discussion for a while now but we're still >>>> >> not making much progress here, I feel like we're in statu quo. >>>> >> James mentioned a blueprint, I like it. We need to engage some >>>> >> upstream discussion about this major CI refactor, like we need with >>>> >> specs and then we'll decide if whether or not we need to change the >>>> >> tool, and how. >>>> > >>>> > >>>> > Well, this would take some leadership imho. We need some people that >>>> > are >>>> > familiar with the upstream, midstream and downstream requirements of CI. >>>> > This was addressed at the production chain meetings initially but then >>>> > pretty much ignored. The leaders responsible at the various stages of >>>> > a >>>> > build (upstream -> downstream ) failed to take this issue on. Here we >>>> > are >>>> > today. >>>> > >>>> > Would it be acceptable by anyone.. IF >>>> > >>>> > tripleo-quickstart replaced instack-virt-setup [1] and walked through >>>> > the >>>> > undercloud install, then handed off to tripleo.sh to deploy, upgrade, >>>> > update, scale, validate etc??? >>>> >>>> That's something we can try. >>>> >>>> > That these two tools *would* in fact be the the official CI tools of >>>> > tripleo >>>> > at the upstream, RDO, and at least parts of the downstream? >>>> >>>> My opinion on this is that upstream and downstream CI should only differ >>>> on: >>>> * the packages (OSP vs RDO) >>>> * the scenarios (downstream could have customer-specific things) >>>> And that's it. Tools should remain the same IMHO. >>>> >>>> > Would that help to ease the current frustration around CI? Emilien what >>>> > do >>>> > you think? >>>> >>>> I spent the last months working on composable roles and I have now >>>> more time to work on CI; $topic is definitely something where I would >>>> like to help. >>>> -- >>>> Emilien Macchi >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >>> >>> >>> -- >>> Tal Kammer >>> Associate manager, automation and infrastracture, Openstack platform. >>> Red Hat Israel >>> Automation group mojo: https://mojo.redhat.com/docs/DOC-1011659 >>> >>> _______________________________________________ >>> 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 > > > > -- > Emilien Macchi From bderzhavets at hotmail.com Fri Oct 14 08:43:54 2016 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Fri, 14 Oct 2016 08:43:54 +0000 Subject: [rdo-list] RDO Newton GA Test Day - October 13, 14 TripleO VENV Testing In-Reply-To: <5d1ffae6-17c2-ddef-6066-afc0950b2c66@redhat.com> References: <2d62b872-c6ed-29f1-6f83-7fda5013d34d@redhat.com> <1476103145.543072156@f411.i.mail.ru>, <5d1ffae6-17c2-ddef-6066-afc0950b2c66@redhat.com> Message-ID: Finally, using template "Simplest ironic-config.yaml (instack-virt-setup)" parameter_defaults: IronicEnabledDrivers: - pxe_ssh IronicCleaningDiskErase: 'metadata' ControllerCount: 1 ComputeCount: 0 I've got :- [stack at instack ~]$ source overcloudrc [stack at instack ~]$ openstack baremetal driver list WARNING: openstackclient.common.utils is deprecated and will be removed after Jun 2017. Please use osc_lib.utils +------------------------------------+------------------------------------+ | Supported driver(s) | Active host(s) | +---------------------+---------------------------------------------------+ | pxe_ssh | overcloud-controller-0.localdomain | +---------------------+---------------------------------------------------+ However , following schema splitting nodes (NODE_COUNT=2) 1. jq '.nodes[0:1] | {nodes: .}' instackenv.json > undercloud.json 2. jq '.nodes[1:2] | {nodes: map({driver: .pm_type, name: .name, driver_info: {ssh_username: .pm_user, ssh_address: .pm_addr, ssh_key_contents: .pm_password, ssh_virt_type: "virsh"}, properties: {cpus: .cpu, cpu_arch: .arch, local_gb: .disk, memory_mb: .memory}, ports: .mac | map({address: .})})}' instackenv.json > overcloud-nodes.yaml 3. * Then we only register the undercloud.json on the undercloud: * source stackrc; openstack baremetal import undercloud.json causes immediate exit of $ source stackrc $ openstack overcloud deploy --templates \ -e /usr/share/openstack-tripleo-heat-templates/environments/services/ironic.yaml \ -e ironic-config.yaml with message "One node registered, but 2 nodes required" So , to get this running I was forced cancel splitting nodes $ jq '.nodes[0:2] | {nodes: .}' instackenv.json > undercloud.json What in turn results :- [stack at instack ~]$ . stackrc [stack at instack ~]$ openstack baremetal node list WARNING: openstackclient.common.utils is deprecated and will be removed after Jun 2017. Please use osc_lib.utils +-------------------+------+-------------------+-------------+--------------------+-----------------------------------------+ | UUID | Name | Instance UUID | Power State | Provisioning State | Maintenance | +-------------------+------+-------------------+-------------+--------------------+------------------------------------------+ | 66ede001-8a82 | None | None | power off | available | False | | -40df- | | | | | | | 8ee6-22511169a2fa | | | | | | | 376b50bc-8ccd-4ac | None | 8ddbe9d1-f8f9-4f2 | power on | active | False | | 0-8191-ce523a8cc9 | | 8-9562-63b10b0d5c | | | | | 4f | | 9f | | | | +-------------------+------+-------------------+-------------+--------------------+-----------------------------------------+ I missing something here, template suggested above requires registering 2 nodes, but not one. Please, advise. Thanks Boris. _____________________________________________________________________________________________ From: rdo-list-bounces at redhat.com on behalf of Dmitry Tantsur Sent: Monday, October 10, 2016 3:42 PM To: Boris Cc: rdo-list Subject: Re: [rdo-list] RDO Newton GA Test Day - October 13, 14 TripleO VENV Testing Sorry, I think you have to either remove "OvercloudControlFlavor: control" or tweak you flavors (the former is the easiest). https://etherpad.openstack.org/p/rdo-newton-ga-testday-ironic-overcloud has the updated samples. On 10/10/2016 02:39 PM, Boris wrote: > Backup e-mail has been used due to local DNS issues with hotmail.com. > > Follow http://tripleo.org/advanced_deployment/baremetal_overcloud.html Bare Metal Instances in Overcloud ? tripleo-docs 0.0.1 ... tripleo.org Bare Metal Instances in Overcloud? This documentation explains installing Ironic for providing bare metal instances in the overcloud to end users. > with your sample > > parameter_defaults: > IronicEnabledDrivers: > - pxe_ssh > - pxe_ipmitool > IronicCleaningDiskErase: 'metadata' > ControllerCount: 1 > ComputeCount: 0 > OvercloudControlFlavor: control > NtpServer: 'pool.ntp.org' > > via instack-virt-setup with > > NODE_CPU=2 > NODE_COUNT=2 > NODE_MEMORY=80000 > UNDERCLOUD_MEMORY=12000 > > on 32 GB VIRTHOST 4 CORE i7 CPU (Haswell ) > > Every time get during overcloud deployment > > ================================================================================================= > 2016-10-10 07:35:42Z [overcloud.Controller.0.Controller]: CREATE_FAILED > ResourceInError: resources.Controller: Went to status ERROR due to "Message: No > valid host was found. There are not enough hosts available., Code: 500" > ================================================================================================== > > Due to limited experience both cases tested > > 1. openstack baremetal introspection bulk start - is skipped <== I guess has to > be skipped. > 2. openstack baremetal introspection bulk start - is done > > Before overcloud-deploy.sh run. > > Crashes with same error above. > > Repos setup (same on VIRTHOST and "instack VM") :- > > $ sudo yum -y install yum-plugin-priorities > $ sudo curl -o /etc/yum.repos.d/delorean-newton.repo \ > http://buildlogs.centos.org/centos/7/cloud/x86_64/rdo-trunk-newton-tested/delorean.repo > $ sudo curl -o /etc/yum.repos.d/delorean-deps-newton.repo \ > https://trunk.rdoproject.org/centos7-newton/delorean-deps.repo > > One other test has been completed OK . > > RDO Newton Overcloud HA deployment via instack-virt-setup on CentOS 7.2 VIRTHOST > http://dbaxps.blogspot.com/2016/10/rdo-newton-overcloud-ha-deployment-via.html [https://1.bp.blogspot.com/-OuG1rBXIckc/V_ltfZJ54mI/AAAAAAAAHME/4jHIDlJ8bBA7Qt-jAezXlB0eFOmULh_7wCLcB/w1200-h630-p-nu/Screenshot%2Bfrom%2B2016-10-09%2B01-03-24.png] RDO Newton Overcloud HA deployment via instack-virt-setup on CentOS 7.2 VIRTHOST dbaxps.blogspot.com Draft belllow may be considered as POC awaiting release of TripleoO QuickStart along with flexible templates managed by ansible and KSM pa... > > Thanks. > Boris. > Sorry, but current time frame is more suitable for myself. > > ???????????, 10 ??????? 2016, 13:10 +03:00 ?? Dmitry Tantsur : > > > Done, updated https://etherpad.openstack.org/p/rdo-newton-ga-testday-testplan > and created > https://etherpad.openstack.org/p/rdo-newton-ga-testday-ironic-overcloud. > > _______________________________________________ > 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 > > > > > ? ?????????, > Boris Derzhavets > dba477 at list.ru _______________________________________________ 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 dtantsur at redhat.com Fri Oct 14 09:14:56 2016 From: dtantsur at redhat.com (Dmitry Tantsur) Date: Fri, 14 Oct 2016 11:14:56 +0200 Subject: [rdo-list] RDO Newton GA Test Day - October 13, 14 TripleO VENV Testing In-Reply-To: References: <2d62b872-c6ed-29f1-6f83-7fda5013d34d@redhat.com> <1476103145.543072156@f411.i.mail.ru> <5d1ffae6-17c2-ddef-6066-afc0950b2c66@redhat.com> Message-ID: On 10/14/2016 10:43 AM, Boris Derzhavets wrote: > Finally, using template "Simplest ironic-config.yaml (instack-virt-setup)" > > > |parameter_defaults:| > | IronicEnabledDrivers:| > | - pxe_ssh| > | IronicCleaningDiskErase: 'metadata'| > | ControllerCount: 1| > | ComputeCount: 0| > > > I've got :- > > > [stack at instack ~]$ source overcloudrc > [stack at instack ~]$ openstack baremetal driver list > WARNING: openstackclient.common.utils is deprecated and will be removed after > Jun 2017. Please use osc_lib.utils > +------------------------------------+------------------------------------+ > | Supported driver(s) | Active host(s) | > +---------------------+---------------------------------------------------+ > | pxe_ssh | overcloud-controller-0.localdomain | > +---------------------+---------------------------------------------------+ > > > However , following schema splitting nodes (NODE_COUNT=2) > > 1. jq '.nodes[0:1] | {nodes: .}' instackenv.json > undercloud.json > 2. jq '.nodes[1:2] | {nodes: map({driver: .pm_type, name: .name, driver_info: > {ssh_username: .pm_user, ssh_address: .pm_addr, ssh_key_contents: > .pm_password, ssh_virt_type: "virsh"}, properties: {cpus: .cpu, cpu_arch: > .arch, local_gb: .disk, memory_mb: .memory}, ports: .mac | map({address: > .})})}' instackenv.json > overcloud-nodes.yaml > 3. > 2. Then we only register the undercloud.json on the undercloud: > 1. source stackrc; openstack baremetal import undercloud.json > > causes immediate exit of > > $ source stackrc > $ openstack overcloud deploy --templates \ > -e /usr/share/openstack-tripleo-heat-templates/environments/services/ironic.yaml \ > -e ironic-config.yaml > > with message > > "One node registered, but 2 nodes required" Hi! You've faced a bug in the validation code (I've reported it, but don't have the link handy). You can work around it by passing '--compute-scale 0' to your deployment command. > > > So , to get this running I was forced cancel splitting nodes > > $ jq '.nodes[0:2] | {nodes: .}' instackenv.json > undercloud.json > > > What in turn results :- > > [stack at instack ~]$ . stackrc > [stack at instack ~]$ openstack baremetal node list > WARNING: openstackclient.common.utils is deprecated and will be removed after > Jun 2017. Please use osc_lib.utils > +-------------------+------+-------------------+-------------+--------------------+-----------------------------------------+ > | UUID | Name | Instance UUID | Power State | Provisioning > State | Maintenance | > +-------------------+------+-------------------+-------------+--------------------+------------------------------------------+ > | 66ede001-8a82 | None | None | power off | > available | False | > | -40df- | | | > | | | > | 8ee6-22511169a2fa | | | > | | | > | 376b50bc-8ccd-4ac | None | 8ddbe9d1-f8f9-4f2 | power on | active > | False | > | 0-8191-ce523a8cc9 | | 8-9562-63b10b0d5c | | > | | > | 4f | | 9f | > | | | > +-------------------+------+-------------------+-------------+--------------------+-----------------------------------------+ > > I missing something here, template suggested above requires registering 2 nodes, > but not one. > > Please, advise. > > > Thanks > > Boris. From cems at ebi.ac.uk Fri Oct 14 09:25:58 2016 From: cems at ebi.ac.uk (Charles Short) Date: Fri, 14 Oct 2016 10:25:58 +0100 Subject: [rdo-list] Manila TripleO Newton In-Reply-To: References: Message-ID: <5f4446df-de51-8d87-43c2-2a77ff86a1e1@ebi.ac.uk> For info - Posted on openstack-dev on the back of my older Mitaka thread http://lists.openstack.org/pipermail/openstack-dev/2016-October/105717.html On 12/10/2016 12:00, Charles Short wrote: > Hi, > > I notice that the Manila NetApp template that was missing in Mitaka is > now present in TripleO Newton. Does this mean I can deploy it? > > /usr/share/openstack-tripleo-heat-templates/environments/manila-netapp-config.yaml > > > What is the official status? > > Thanks > > Charles > > -- Charles Short Cloud Engineer Virtualization and Cloud Team European Bioinformatics Institute (EMBL-EBI) Tel: +44 (0)1223 494205 From devin at pabstatencio.com Fri Oct 14 15:10:44 2016 From: devin at pabstatencio.com (Devin Acosta) Date: Fri, 14 Oct 2016 08:10:44 -0700 Subject: [rdo-list] Mitaka upgrade to Newton Message-ID: <5800F574.7050408@pabstatencio.com> Last night I shut down my entire RDO Mitaka environment and then did a "yum -y update" to upgrade to the Newton release. I worked on merging a lot of the .rpmnew files for Neutron, Nova, Cinder, to be the latest version of the files. I am a little confused on how I am suppose to upgrade the Database for each of the individual parts, because the openstack-db command is no longer available. I was able to update a few services like Neutron with "neutron-db-manage current", however the one issue i'm noticing right now is that Cinder won't start. I am seeing errors about "ServiceTooOld: One of the services is in Liberty version. We do not provide backward compatibility with Liberty now, you need to upgrade to Mitaka first.". I was running Mitaka just fine before the Newton update, I'm not sure what I need to change in order get get past this error. Anyone that can assist me or provide me a guide on the proper upgrade path when you take down the whole cluster would be appreciate! 2016-10-13 23:17:48.740 1037694 CRITICAL cinder [req-11ed371c-7132-417b-ae55-1c31934b3102 - - - - -] ServiceTooOld: One of the services is in Liberty version. We do not provide backward compatibility with Liberty now, you need to upgrade to Mitaka first. 2016-10-13 23:17:48.740 1037694 ERROR cinder Traceback (most recent call last): 2016-10-13 23:17:48.740 1037694 ERROR cinder File "/usr/bin/cinder-scheduler", line 10, in 2016-10-13 23:17:48.740 1037694 ERROR cinder sys.exit(main()) 2016-10-13 23:17:48.740 1037694 ERROR cinder File "/usr/lib/python2.7/site-packages/cinder/cmd/scheduler.py", line 53, in main 2016-10-13 23:17:48.740 1037694 ERROR cinder server = service.Service.create(binary='cinder-scheduler') 2016-10-13 23:17:48.740 1037694 ERROR cinder File "/usr/lib/python2.7/site-packages/cinder/service.py", line 382, in create 2016-10-13 23:17:48.740 1037694 ERROR cinder cluster=cluster) 2016-10-13 23:17:48.740 1037694 ERROR cinder File "/usr/lib/python2.7/site-packages/cinder/service.py", line 202, in __init__ 2016-10-13 23:17:48.740 1037694 ERROR cinder *args, **kwargs) 2016-10-13 23:17:48.740 1037694 ERROR cinder File "/usr/lib/python2.7/site-packages/cinder/scheduler/manager.py", line 68, in __init__ 2016-10-13 23:17:48.740 1037694 ERROR cinder self.driver = importutils.import_object(scheduler_driver) 2016-10-13 23:17:48.740 1037694 ERROR cinder File "/usr/lib/python2.7/site-packages/oslo_utils/importutils.py", line 44, in import_object 2016-10-13 23:17:48.740 1037694 ERROR cinder return import_class(import_str)(*args, **kwargs) 2016-10-13 23:17:48.740 1037694 ERROR cinder File "/usr/lib/python2.7/site-packages/cinder/scheduler/filter_scheduler.py", line 40, in __init__ 2016-10-13 23:17:48.740 1037694 ERROR cinder super(FilterScheduler, self).__init__(*args, **kwargs) 2016-10-13 23:17:48.740 1037694 ERROR cinder File "/usr/lib/python2.7/site-packages/cinder/scheduler/driver.py", line 85, in __init__ 2016-10-13 23:17:48.740 1037694 ERROR cinder self.volume_rpcapi = volume_rpcapi.VolumeAPI() 2016-10-13 23:17:48.740 1037694 ERROR cinder File "/usr/lib/python2.7/site-packages/cinder/rpc.py", line 194, in __init__ 2016-10-13 23:17:48.740 1037694 ERROR cinder obj_version_cap = self.determine_obj_version_cap() 2016-10-13 23:17:48.740 1037694 ERROR cinder File "/usr/lib/python2.7/site-packages/cinder/rpc.py", line 233, in determine_obj_version_cap 2016-10-13 23:17:48.740 1037694 ERROR cinder cinder.context.get_admin_context(), cls.BINARY) 2016-10-13 23:17:48.740 1037694 ERROR cinder File "/usr/lib/python2.7/site-packages/cinder/objects/service.py", line 188, in get_minimum_obj_version 2016-10-13 23:17:48.740 1037694 ERROR cinder binary) 2016-10-13 23:17:48.740 1037694 ERROR cinder File "/usr/lib/python2.7/site-packages/cinder/objects/service.py", line 173, in _get_minimum_version 2016-10-13 23:17:48.740 1037694 ERROR cinder raise exception.ServiceTooOld(msg) 2016-10-13 23:17:48.740 1037694 ERROR cinder ServiceTooOld: One of the services is in Liberty version. We do not provide backward compatibility with Liberty now, you need to upgrade to Mitaka first. -- Devin Acosta RHCA|LFCE Red Hat Certified Architect, Linux Geek e: devin at linuxguru.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From dms at redhat.com Fri Oct 14 20:12:52 2016 From: dms at redhat.com (David Moreau Simard) Date: Fri, 14 Oct 2016 16:12:52 -0400 Subject: [rdo-list] Review Request: python-marathon - Python client library/interface to the Mesos Marathon REST API Message-ID: Hi rdo-list, Magnum recently added [1] a dependency on the marathon [2] python library which has not yet been packaged. We need to package marathon and add it as a dependency. Here's the review request: https://bugzilla.redhat.com/show_bug.cgi?id=1385105 [1]: https://review.openstack.org/#/c/333188/ [2]: https://pypi.python.org/pypi/marathon/0.8.6 David Moreau Simard Senior Software Engineer | Openstack RDO dmsimard = [irc, github, twitter] From bderzhavets at hotmail.com Sat Oct 15 07:29:08 2016 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Sat, 15 Oct 2016 07:29:08 +0000 Subject: [rdo-list] Failure to deploy overcloud via TripleO StartQuickStart In-Reply-To: References: Message-ID: In meantime indercloud gets created with swift container "overcloud" already been built. It results failure to start Mistral Work-flow by script :- #!/bin/bash -x source /home/stack/stackrc openstack overcloud deploy \ --control-scale 3 --compute-scale 1 \ --libvirt-type qemu \ --ntp-server pool.ntp.org \ --templates /usr/share/openstack-tripleo-heat-templates \ -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml \ -e $HOME/network_env.yaml Attempt `swift delete overcloud` and restart deployment fails to start Mistral work-flow either way. Changes seems to be done a bit latter 10/13/16 (GMT+4) due to 10/12-10/13 old schema still worked experiencing some delay during updating plan and starting mistral work flow. However, command `bash quickstart.sh -R newton --config ./config/general_config/ha.yml $VIRTHOST` still completes with old instructions ################################## Virtual Environment Setup Complete ################################## Access the undercloud by: ssh -F /home/jon/.quickstart/ssh.config.ansible undercloud Follow the documentation in the link below to complete your deployment. http://ow.ly/c44w304begR <== standard instructions from tripleo.org which seems to be outdated at the moment . I cannot proceed with script above when swift container "overcloud" already exists. Thanks. Boris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bderzhavets at hotmail.com Sat Oct 15 08:20:03 2016 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Sat, 15 Oct 2016 08:20:03 +0000 Subject: [rdo-list] Failure to deploy overcloud via TripleO StartQuickStart In-Reply-To: References: , Message-ID: In general, existence swift container "overcloud" is not a issue for deployment. Bug is fixed https://bugs.launchpad.net/tripleo/+bug/1622683 By some reasons it appears to be an issue on QuickStart ( might be due to different design) ________________________________ From: rdo-list-bounces at redhat.com on behalf of Boris Derzhavets Sent: Saturday, October 15, 2016 10:29 AM To: rdo-list; John Trowbridge Subject: [rdo-list] Failure to deploy overcloud via TripleO StartQuickStart In meantime indercloud gets created with swift container "overcloud" already been built. It results failure to start Mistral Work-flow by script :- #!/bin/bash -x source /home/stack/stackrc openstack overcloud deploy \ --control-scale 3 --compute-scale 1 \ --libvirt-type qemu \ --ntp-server pool.ntp.org \ --templates /usr/share/openstack-tripleo-heat-templates \ -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml \ -e $HOME/network_env.yaml Attempt `swift delete overcloud` and restart deployment fails to start Mistral work-flow either way. Changes seems to be done a bit latter 10/13/16 (GMT+4) due to 10/12-10/13 old schema still worked experiencing some delay during updating plan and starting mistral work flow. However, command `bash quickstart.sh -R newton --config ./config/general_config/ha.yml $VIRTHOST` still completes with old instructions ################################## Virtual Environment Setup Complete ################################## Access the undercloud by: ssh -F /home/jon/.quickstart/ssh.config.ansible undercloud Follow the documentation in the link below to complete your deployment. http://ow.ly/c44w304begR <== standard instructions from tripleo.org which seems to be outdated at the moment . I cannot proceed with script above when swift container "overcloud" already exists. Thanks. Boris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bderzhavets at hotmail.com Sun Oct 16 08:54:45 2016 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Sun, 16 Oct 2016 08:54:45 +0000 Subject: [rdo-list] The most recent Newton trunk "centos7-newton/current-passed-ci" and instack-virt-setup issue In-Reply-To: References: Message-ID: Set up repos on VIRTHOST and INSTACK VM sudo yum -y install yum-plugin-priorities sudo curl -o /etc/yum.repos.d/delorean-newton.repo \ http://buildlogs.centos.org/centos/7/cloud/x86_64/rdo-trunk-newton-tested/delorean.repo sudo curl -o /etc/yum.repos.d/delorean-deps-newton.repo \ https://trunk.rdoproject.org/centos7-newton/delorean-deps.repo Register 4 nodes $ openstack baremetal import instackenv.json OK $ openstack baremetal configure boot OK $ openstack baremetal introspection bulk start HANGS Attempt to introspecting a Single Node for each entry entry in `ironic node-list` finally get introspection status "Finished - True" and move to available via 'ironic node-set-provision-state UUID provide` Procedure works for deployment #!/bin/bash -x source /home/stack/stackrc openstack overcloud deploy \ --control-scale 3 --compute-scale 1 \ --libvirt-type qemu \ --ntp-server pool.ntp.org \ --templates /usr/share/openstack-tripleo-heat-templates Then drop all VMs and start from scratch same procedure Attempt to deploy :- Interface vlan10 added && network_env.yaml created in ~stack/ folder #!/bin/bash -x source /home/stack/stackrc openstack overcloud deploy \ --control-scale 3 --compute-scale 1 \ --libvirt-type qemu \ --ntp-server pool.ntp.org \ --templates /usr/share/openstack-tripleo-heat-templates \ -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml \ -e $HOME/network_env.yaml Only 2 VMst boot the other 2 VMs fail to boot . Console reports IPXE failure . Heat session reports "not enough nodes available" error 500 . Deployment fails. Previous Newton trunk "current-passed-ci" ( around 10/11/16 ) worked fine. $ openstack baremetal introspection bulk start Completed OK , no further issues. Redeployment still works fine after reboot to another CentOS 7.2 instance . ( several CentOS 7.2 instances multibooting ) Thanks. Boris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lorenzetto.luca at gmail.com Sun Oct 16 17:28:09 2016 From: lorenzetto.luca at gmail.com (Luca 'remix_tj' Lorenzetto) Date: Sun, 16 Oct 2016 19:28:09 +0200 Subject: [rdo-list] Fwd: An Evening of Ceph and RDO (schedule) In-Reply-To: <0bf6fb47-618b-a850-d8ca-31f68a53bb0e@redhat.com> References: <0bf6fb47-618b-a850-d8ca-31f68a53bb0e@redhat.com> Message-ID: On Thu, Oct 13, 2016 at 8:30 PM, Rich Bowen wrote: > FYI, this is the schedule of talks at the Ceph/RDO event in Barcelona on > the 25th. > Hello, i see on eventbrite that event is full. Is still possible to join the event? Luca -- "E' assurdo impiegare gli uomini di intelligenza eccellente per fare calcoli che potrebbero essere affidati a chiunque se si usassero delle macchine" Gottfried Wilhelm von Leibnitz, Filosofo e Matematico (1646-1716) "Internet ? la pi? grande biblioteca del mondo. Ma il problema ? che i libri sono tutti sparsi sul pavimento" John Allen Paulos, Matematico (1945-vivente) Luca 'remix_tj' Lorenzetto, http://www.remixtj.net , From mnaser at vexxhost.com Sun Oct 16 20:59:51 2016 From: mnaser at vexxhost.com (Mohammed Naser) Date: Sun, 16 Oct 2016 16:59:51 -0400 Subject: [rdo-list] Mitaka upgrade to Newton In-Reply-To: <5800F574.7050408@pabstatencio.com> References: <5800F574.7050408@pabstatencio.com> Message-ID: Hi David, I suspect that you have a running Cinder agent which is running an old code base, or you did not run the database updates. Did you make sure to run this: cinder-manage db sync I strongly suggest you have a look at the upgrade notes too. Thanks Mohammed On Friday, 14 October 2016, Devin Acosta wrote: > Last night I shut down my entire RDO Mitaka environment and then did a > "yum -y update" to upgrade to the Newton release. I worked on merging a lot > of the .rpmnew files for Neutron, Nova, Cinder, to be the latest version of > the files. I am a little confused on how I am suppose to upgrade the > Database for each of the individual parts, because the openstack-db command > is no longer available. I was able to update a few services like Neutron > with "neutron-db-manage current", however the one issue i'm noticing right > now is that Cinder won't start. > > I am seeing errors about "ServiceTooOld: One of the services is in Liberty > version. We do not provide backward compatibility with Liberty now, you > need to upgrade to Mitaka first.". I was running Mitaka just fine before > the Newton update, I'm not sure what I need to change in order get get past > this error. Anyone that can assist me or provide me a guide on the proper > upgrade path when you take down the whole cluster would be appreciate! > > 2016-10-13 23:17:48.740 1037694 CRITICAL cinder > [req-11ed371c-7132-417b-ae55-1c31934b3102 - - - - -] ServiceTooOld: One > of the services is in Liberty version. We do not provide backward > compatibility with Liberty now, you need to upgrade to Mitaka first. > 2016-10-13 23:17:48.740 1037694 ERROR cinder Traceback (most recent call > last): > 2016-10-13 23:17:48.740 1037694 ERROR cinder File > "/usr/bin/cinder-scheduler", line 10, in > 2016-10-13 23:17:48.740 1037694 ERROR cinder sys.exit(main()) > 2016-10-13 23:17:48.740 1037694 ERROR cinder File > "/usr/lib/python2.7/site-packages/cinder/cmd/scheduler.py", line 53, in > main > 2016-10-13 23:17:48.740 1037694 ERROR cinder server = > service.Service.create(binary='cinder-scheduler') > 2016-10-13 23:17:48.740 1037694 ERROR cinder File > "/usr/lib/python2.7/site-packages/cinder/service.py", line 382, in create > 2016-10-13 23:17:48.740 1037694 ERROR cinder cluster=cluster) > 2016-10-13 23:17:48.740 1037694 ERROR cinder File > "/usr/lib/python2.7/site-packages/cinder/service.py", line 202, in > __init__ > 2016-10-13 23:17:48.740 1037694 ERROR cinder *args, **kwargs) > 2016-10-13 23:17:48.740 1037694 ERROR cinder File > "/usr/lib/python2.7/site-packages/cinder/scheduler/manager.py", line 68, > in __init__ > 2016-10-13 23:17:48.740 1037694 ERROR cinder self.driver = > importutils.import_object(scheduler_driver) > 2016-10-13 23:17:48.740 1037694 ERROR cinder File > "/usr/lib/python2.7/site-packages/oslo_utils/importutils.py", line 44, in > import_object > 2016-10-13 23:17:48.740 1037694 ERROR cinder return > import_class(import_str)(*args, **kwargs) > 2016-10-13 23:17:48.740 1037694 ERROR cinder File > "/usr/lib/python2.7/site-packages/cinder/scheduler/filter_scheduler.py", > line 40, in __init__ > 2016-10-13 23:17:48.740 1037694 ERROR cinder super(FilterScheduler, > self).__init__(*args, **kwargs) > 2016-10-13 23:17:48.740 1037694 ERROR cinder File > "/usr/lib/python2.7/site-packages/cinder/scheduler/driver.py", line 85, > in __init__ > 2016-10-13 23:17:48.740 1037694 ERROR cinder self.volume_rpcapi = > volume_rpcapi.VolumeAPI() > 2016-10-13 23:17:48.740 1037694 ERROR cinder File > "/usr/lib/python2.7/site-packages/cinder/rpc.py", line 194, in __init__ > 2016-10-13 23:17:48.740 1037694 ERROR cinder obj_version_cap = > self.determine_obj_version_cap() > 2016-10-13 23:17:48.740 1037694 ERROR cinder File > "/usr/lib/python2.7/site-packages/cinder/rpc.py", line 233, in > determine_obj_version_cap > 2016-10-13 23:17:48.740 1037694 ERROR cinder cinder.context.get_admin_context(), > cls.BINARY) > 2016-10-13 23:17:48.740 1037694 ERROR cinder File > "/usr/lib/python2.7/site-packages/cinder/objects/service.py", line 188, > in get_minimum_obj_version > 2016-10-13 23:17:48.740 1037694 ERROR cinder binary) > 2016-10-13 23:17:48.740 1037694 ERROR cinder File > "/usr/lib/python2.7/site-packages/cinder/objects/service.py", line 173, > in _get_minimum_version > 2016-10-13 23:17:48.740 1037694 ERROR cinder raise > exception.ServiceTooOld(msg) > 2016-10-13 23:17:48.740 1037694 ERROR cinder ServiceTooOld: One of the > services is in Liberty version. We do not provide backward compatibility > with Liberty now, you need to upgrade to Mitaka first. > > -- > > Devin Acosta RHCA|LFCE > Red Hat Certified Architect, Linux Geek > e: devin at linuxguru.co > > > > -- Mohammed Naser ? vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser at vexxhost.com W. http://vexxhost.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dms at redhat.com Mon Oct 17 12:51:12 2016 From: dms at redhat.com (David Moreau Simard) Date: Mon, 17 Oct 2016 08:51:12 -0400 Subject: [rdo-list] (Late) reminder: maintenance on RDO infrastructure, today Oct 17th Message-ID: Hi, At the last RDO meeting [1], we discussed an upcoming maintenance affecting part of the RDO infrastructure. This maintenance is already taking place at time of writing and as such I would like to apologize if you were not notified beforehand. This maintenance affects primarily the review.rdoproject.org server but also some other servers for whom the owners have been personally notified. We are expecting everything to be back online by 3PM UTC. Sorry for any inconveniences. [1]: https://meetbot.fedoraproject.org/rdo/2016-10-12/rdo_meeting_-_2016-10-12.2016-10-12-15.03.log.html David Moreau Simard Senior Software Engineer | Openstack RDO dmsimard = [irc, github, twitter] From jruzicka at redhat.com Mon Oct 17 13:22:16 2016 From: jruzicka at redhat.com (Jakub Ruzicka) Date: Mon, 17 Oct 2016 15:22:16 +0200 Subject: [rdo-list] [Meeting] RDO meeting (2016-10-12) Minutes Message-ID: <87401f42-1726-e351-523a-2103dfed94fd@redhat.com> ============================== #rdo: RDO meeting - 2016-10-12 ============================== Meeting started by jruzicka at 15:03:49 UTC. The full logs are available at https://meetbot.fedoraproject.org/rdo/2016-10-12/rdo_meeting_-_2016-10-12.2016-10-12-15.03.log.html . Meeting summary --------------- * roll call (jruzicka, 15:04:03) * https://etherpad.openstack.org/p/RDO-Meeting (jruzicka, 15:05:58) * Preparation for RCIP-DEV move October 17th (jruzicka, 15:08:51) * ACTION: dmsimard to post a reminder of oct 17th maintenance of rcip-dev to rdo-list (dmsimard, 15:12:46) * Newton GA test day Oct 13/14 - https://www.rdoproject.org/testday/newton/final/ (jruzicka, 15:16:14) * Thank you to all the people who have improved the test day documentation! (jruzicka, 15:17:09) * FYI: ci.centos.org will soon have an OpenStack cloud based on RDO Newton! (jruzicka, 15:23:03) * upcoming rdopkg refactor might break things - let jruzicka know what rdopkg parts do you use (jruzicka, 15:29:05) * Help out at the RDO booth (demos, q&a, or just meet our users) - https://etherpad.openstack.org/p/rdo-barcelona-summit-booth (jruzicka, 15:35:17) * open floor (jruzicka, 15:37:38) Meeting ended at 15:40:18 UTC. Action Items ------------ * dmsimard to post a reminder of oct 17th maintenance of rcip-dev to rdo-list Action Items, by person ----------------------- * dmsimard * dmsimard to post a reminder of oct 17th maintenance of rcip-dev to rdo-list * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * jruzicka (43) * apevec (34) * dmsimard (34) * trown (17) * zodbot (9) * rbowen (8) * jschlueter (7) * leifmadsen (5) * rdogerrit (4) * flepied (3) * openstack (3) * wfoster (3) * jrist (3) * rook (3) * jjoyce (2) * jkilpatr (2) * misc (1) * eggmaster (1) * mengxd (1) * myoung (1) * mburned (1) * Humbedooh (1) * Duck (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot From rbowen at redhat.com Mon Oct 17 13:32:14 2016 From: rbowen at redhat.com (Rich Bowen) Date: Mon, 17 Oct 2016 09:32:14 -0400 Subject: [rdo-list] Fwd: An Evening of Ceph and RDO (schedule) In-Reply-To: References: <0bf6fb47-618b-a850-d8ca-31f68a53bb0e@redhat.com> Message-ID: <58b5a2b7-604a-5dbc-2e22-4e663045eaa8@redhat.com> On 10/16/2016 01:28 PM, Luca 'remix_tj' Lorenzetto wrote: > On Thu, Oct 13, 2016 at 8:30 PM, Rich Bowen wrote: >> FYI, this is the schedule of talks at the Ceph/RDO event in Barcelona on >> the 25th. >> > > Hello, > > > i see on eventbrite that event is full. Is still possible to join the event? The eventbrite page - https://www.eventbrite.com/e/an-evening-of-ceph-and-rdo-tickets-28022550202 - is there primarily for promotion purposes. That is, so that we had a page to link to in tweets and so on. We have ensured that in addition to the registered "tickets", there's room for community attendees. Don't worry, you won't be turned away at the door. -- Rich Bowen - rbowen at redhat.com RDO Community Liaison http://rdoproject.org @RDOCommunity From hguemar at fedoraproject.org Mon Oct 17 15:00:05 2016 From: hguemar at fedoraproject.org (hguemar at fedoraproject.org) Date: Mon, 17 Oct 2016 15:00:05 +0000 (UTC) Subject: [rdo-list] [Fedocal] Reminder meeting : RDO meeting Message-ID: <20161017150005.706C160A3FDC@fedocal02.phx2.fedoraproject.org> Dear all, You are kindly invited to the meeting: RDO meeting on 2016-10-19 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 bderzhavets at hotmail.com Mon Oct 17 16:21:55 2016 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Mon, 17 Oct 2016 16:21:55 +0000 Subject: [rdo-list] The most recent Newton trunk "centos7-newton/current-passed-ci" and instack-virt-setup issue In-Reply-To: References: , Message-ID: Newton trunk "centos7-newton/current-passed-ci" got renewed. Instack-virt-setup works with Network isolation with no problems again. Just nodes are introspected sequentially ( no bulk). I am wondering is there any trigger which initiate building new Newton trunk "centos7-newton/current-passed-ci". Just see new content in http://buildlogs.centos.org/centos/7/cloud/x86_64/rdo-trunk-newton-tested/delorean.repo and understand that trunk "current-passed-ci" has been rebuilt. One more notice I set up KSM and KSMTUNED ( only services started and enabled with default values ) on VIRTHOST running instack-virt-setup. Performance improvement and memory allocation look pretty close to TripleO QuickStart. So far I don't negative drawback from daemon ksmd up and running on VIRTHOST. [cid:d5ccc703-da58-42d2-b7e3-2b001010a8ac] Thanks. Boris ________________________________ From: rdo-list-bounces at redhat.com on behalf of Boris Derzhavets Sent: Sunday, October 16, 2016 11:54 AM To: rdo-list Subject: [rdo-list] The most recent Newton trunk "centos7-newton/current-passed-ci" and instack-virt-setup issue Set up repos on VIRTHOST and INSTACK VM sudo yum -y install yum-plugin-priorities sudo curl -o /etc/yum.repos.d/delorean-newton.repo \ http://buildlogs.centos.org/centos/7/cloud/x86_64/rdo-trunk-newton-tested/delorean.repo sudo curl -o /etc/yum.repos.d/delorean-deps-newton.repo \ https://trunk.rdoproject.org/centos7-newton/delorean-deps.repo Register 4 nodes $ openstack baremetal import instackenv.json OK $ openstack baremetal configure boot OK $ openstack baremetal introspection bulk start HANGS Attempt to introspecting a Single Node for each entry entry in `ironic node-list` finally get introspection status "Finished - True" and move to available via 'ironic node-set-provision-state UUID provide` Procedure works for deployment #!/bin/bash -x source /home/stack/stackrc openstack overcloud deploy \ --control-scale 3 --compute-scale 1 \ --libvirt-type qemu \ --ntp-server pool.ntp.org \ --templates /usr/share/openstack-tripleo-heat-templates Then drop all VMs and start from scratch same procedure Attempt to deploy :- Interface vlan10 added && network_env.yaml created in ~stack/ folder #!/bin/bash -x source /home/stack/stackrc openstack overcloud deploy \ --control-scale 3 --compute-scale 1 \ --libvirt-type qemu \ --ntp-server pool.ntp.org \ --templates /usr/share/openstack-tripleo-heat-templates \ -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml \ -e $HOME/network_env.yaml Only 2 VMst boot the other 2 VMs fail to boot . Console reports IPXE failure . Heat session reports "not enough nodes available" error 500 . Deployment fails. Previous Newton trunk "current-passed-ci" ( around 10/11/16 ) worked fine. $ openstack baremetal introspection bulk start Completed OK , no further issues. Redeployment still works fine after reboot to another CentOS 7.2 instance . ( several CentOS 7.2 instances multibooting ) Thanks. Boris. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot from 2016-10-17 19-17-11.png Type: image/png Size: 232487 bytes Desc: Screenshot from 2016-10-17 19-17-11.png URL: From dms at redhat.com Mon Oct 17 16:52:41 2016 From: dms at redhat.com (David Moreau Simard) Date: Mon, 17 Oct 2016 12:52:41 -0400 Subject: [rdo-list] RDO's cloud slaves are back on ci.centos.org Message-ID: Hi, The three RDO cloud slaves are back online on ci.centos.org after a re-deployment of the OpenStack cloud with the latest Newton release. The current "permanent" slave had 16 threads on 4 cores and ~6GB RAM. The cloud slaves have 2 cores and ~4GB RAM. These are pretty good cores, though, E5-2640 v3s that are not oversubscribed. I've toned down the amount of threads on the permanent slaves down to 10 (it was often struggling) and each cloud slave has 4 threads. We're looking at a total of 22 threads for job execution. If you do not need your jobs to be pinned to a particular jenkins slave, please make sure to use the "rdo" label which is served by all four slaves. Let me know if you have any questions, David Moreau Simard Senior Software Engineer | Openstack RDO dmsimard = [irc, github, twitter] From bderzhavets at hotmail.com Mon Oct 17 17:50:54 2016 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Mon, 17 Oct 2016 17:50:54 +0000 Subject: [rdo-list] Failure to install Controller/Network&&Compute Cluster on RDO Newton with keystone API V3 In-Reply-To: References: Message-ID: Record https://bugzilla.redhat.com/show_bug.cgi?id=1330289 makes me to think RDO Newton is passing final CI with only one version keystone API v2.0 . Keystone API v3 was not tested. Otherwise , how could it happen that simple AIO set up driven by packstack fails running with keystone API v3 Thanks. Boris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From trown at redhat.com Mon Oct 17 17:55:50 2016 From: trown at redhat.com (John Trowbridge) Date: Mon, 17 Oct 2016 13:55:50 -0400 Subject: [rdo-list] The most recent Newton trunk "centos7-newton/current-passed-ci" and instack-virt-setup issue In-Reply-To: References: Message-ID: On 10/17/2016 12:21 PM, Boris Derzhavets wrote: > > Newton trunk "centos7-newton/current-passed-ci" got renewed. > Instack-virt-setup works with Network isolation with no problems again. > Just nodes are introspected sequentially ( no bulk). > > I am wondering is there any trigger which initiate building new Newton trunk "centos7-newton/current-passed-ci". Just see new content in http://buildlogs.centos.org/centos/7/cloud/x86_64/rdo-trunk-newton-tested/delorean.repo and understand that trunk "current-passed-ci" has been rebuilt. Promotion happens via a jenkins multijob[1] which tests the repo with tripleo-quickstart,packstack, and puppet-openstack-integration tests. [1] https://ci.centos.org/view/rdo/view/promotion-pipeline/job/rdo-delorean-promote-newton/ > > One more notice I set up KSM and KSMTUNED ( only services started and enabled with > default values ) on VIRTHOST running instack-virt-setup. Performance improvement and memory allocation look pretty close to TripleO QuickStart. So far I don't negative drawback from daemon ksmd up and running on VIRTHOST. > > [cid:d5ccc703-da58-42d2-b7e3-2b001010a8ac] > > Thanks. > > Boris > > ________________________________ > From: rdo-list-bounces at redhat.com on behalf of Boris Derzhavets > Sent: Sunday, October 16, 2016 11:54 AM > To: rdo-list > Subject: [rdo-list] The most recent Newton trunk "centos7-newton/current-passed-ci" and instack-virt-setup issue > > > Set up repos on VIRTHOST and INSTACK VM > > sudo yum -y install yum-plugin-priorities > sudo curl -o /etc/yum.repos.d/delorean-newton.repo \ > http://buildlogs.centos.org/centos/7/cloud/x86_64/rdo-trunk-newton-tested/delorean.repo > sudo curl -o /etc/yum.repos.d/delorean-deps-newton.repo \ > https://trunk.rdoproject.org/centos7-newton/delorean-deps.repo > > Register 4 nodes > > $ openstack baremetal import instackenv.json > > OK > > $ openstack baremetal configure boot > > OK > > $ openstack baremetal introspection bulk start > > HANGS > > > Attempt to introspecting a Single Node > > for each entry entry in `ironic node-list` finally get > introspection status "Finished - True" and move to available > via 'ironic node-set-provision-state UUID provide` > Procedure works for deployment > > #!/bin/bash -x > source /home/stack/stackrc > openstack overcloud deploy \ > --control-scale 3 --compute-scale 1 \ > --libvirt-type qemu \ > --ntp-server pool.ntp.org \ > --templates /usr/share/openstack-tripleo-heat-templates > > Then drop all VMs and start from scratch same procedure > Attempt to deploy :- > Interface vlan10 added && network_env.yaml created in ~stack/ folder > > #!/bin/bash -x > source /home/stack/stackrc > openstack overcloud deploy \ > --control-scale 3 --compute-scale 1 \ > --libvirt-type qemu \ > --ntp-server pool.ntp.org \ > --templates /usr/share/openstack-tripleo-heat-templates \ > -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml \ > -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \ > -e /usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml \ > -e $HOME/network_env.yaml > > Only 2 VMst boot the other 2 VMs fail to boot . Console reports IPXE failure . > Heat session reports "not enough nodes available" error 500 . Deployment fails. > > Previous Newton trunk "current-passed-ci" ( around 10/11/16 ) worked fine. > $ openstack baremetal introspection bulk start > Completed OK , no further issues. Redeployment still works fine after reboot > to another CentOS 7.2 instance . ( several CentOS 7.2 instances multibooting ) > > Thanks. > Boris. > > > > > > > > > _______________________________________________ > rdo-list mailing list > rdo-list at redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe at redhat.com > From dms at redhat.com Mon Oct 17 17:56:39 2016 From: dms at redhat.com (David Moreau Simard) Date: Mon, 17 Oct 2016 13:56:39 -0400 Subject: [rdo-list] (Late) reminder: maintenance on RDO infrastructure, today Oct 17th In-Reply-To: References: Message-ID: Hi, Everything is back online as of around 3:30PM UTC. Please let us know on the mailing list or on #rdo if you notice something out of the ordinary. Thanks, David Moreau Simard Senior Software Engineer | Openstack RDO dmsimard = [irc, github, twitter] On Mon, Oct 17, 2016 at 8:51 AM, David Moreau Simard wrote: > Hi, > > At the last RDO meeting [1], we discussed an upcoming maintenance > affecting part of the RDO infrastructure. > This maintenance is already taking place at time of writing and as > such I would like to apologize if you were not notified beforehand. > > This maintenance affects primarily the review.rdoproject.org server > but also some other servers for whom the owners have been personally > notified. > > We are expecting everything to be back online by 3PM UTC. > > Sorry for any inconveniences. > > [1]: https://meetbot.fedoraproject.org/rdo/2016-10-12/rdo_meeting_-_2016-10-12.2016-10-12-15.03.log.html > > David Moreau Simard > Senior Software Engineer | Openstack RDO > > dmsimard = [irc, github, twitter] From rbowen at redhat.com Mon Oct 17 18:19:13 2016 From: rbowen at redhat.com (Rich Bowen) Date: Mon, 17 Oct 2016 14:19:13 -0400 Subject: [rdo-list] This week's unanswered RDO questions on ask.openstack.org Message-ID: <3b53cf64-4cc6-a4ed-42ba-e3abd28ccaf3@redhat.com> I think this is actually exactly the same list as last week ... 22 unanswered questions: How how does icmp packet travel across two compute nodes without br-int and br-tun running? https://ask.openstack.org/en/question/97905/how-how-does-icmp-packet-travel-across-two-compute-nodes-without-br-int-and-br-tun-running/ Tags: neutron-ovs-pktflow "Parameter outiface failed on Firewall" during installation of openstack rdo on centos 7 https://ask.openstack.org/en/question/95657/parameter-outiface-failed-on-firewall-during-installation-of-openstack-rdo-on-centos-7/ Tags: rdo, devstack#mitaka multi nodes provider network ovs config https://ask.openstack.org/en/question/95423/multi-nodes-provider-network-ovs-config/ Tags: rdo, liberty-neutron Adding additional packages to an RDO installation https://ask.openstack.org/en/question/95380/adding-additional-packages-to-an-rdo-installation/ Tags: rdo, mistral RDO TripleO Mitaka HA Overcloud Failing https://ask.openstack.org/en/question/95249/rdo-tripleo-mitaka-ha-overcloud-failing/ Tags: mitaka, tripleo, overcloud, centos7 RDO - is there any fedora package newer than puppet-4.2.1-3.fc24.noarch.rpm https://ask.openstack.org/en/question/94969/rdo-is-there-any-fedora-package-newer-than-puppet-421-3fc24noarchrpm/ Tags: rdo, puppet, install-openstack OpenStack RDO mysqld 100% cpu https://ask.openstack.org/en/question/94961/openstack-rdo-mysqld-100-cpu/ Tags: openstack, mysqld, cpu how to deploy haskell-distributed in RDO? https://ask.openstack.org/en/question/94785/how-to-deploy-haskell-distributed-in-rdo/ Tags: rdo rdo tripleO liberty undercloud install failing https://ask.openstack.org/en/question/94023/rdo-tripleo-liberty-undercloud-install-failing/ Tags: rdo, rdo-manager, liberty, undercloud, instack Liberty RDO: stack resource topology icons are pink https://ask.openstack.org/en/question/91347/liberty-rdo-stack-resource-topology-icons-are-pink/ Tags: resource, topology, dashboard, horizon, pink No handlers could be found for logger "oslo_config.cfg" while syncing the glance database https://ask.openstack.org/en/question/91169/no-handlers-could-be-found-for-logger-oslo_configcfg-while-syncing-the-glance-database/ Tags: liberty, glance, install-openstack CentOS OpenStack - compute node can't talk https://ask.openstack.org/en/question/88989/centos-openstack-compute-node-cant-talk/ Tags: rdo How to setup SWIFT_PROXY_NODE and SWIFT_STORAGE_NODEs separately on RDO Liberty ? https://ask.openstack.org/en/question/88897/how-to-setup-swift_proxy_node-and-swift_storage_nodes-separately-on-rdo-liberty/ Tags: rdo, liberty, swift, ha VM and container can't download anything from internet https://ask.openstack.org/en/question/88338/vm-and-container-cant-download-anything-from-internet/ Tags: rdo, neutron, network, connectivity Fedora22, Liberty, horizon VNC console and keymap=sv with ; and/ https://ask.openstack.org/en/question/87451/fedora22-liberty-horizon-vnc-console-and-keymapsv-with-and/ Tags: keyboard, map, keymap, vncproxy, novnc OpenStack-Docker driver failed https://ask.openstack.org/en/question/87243/openstack-docker-driver-failed/ Tags: docker, openstack, liberty Routing between two tenants https://ask.openstack.org/en/question/84645/routing-between-two-tenants/ Tags: kilo, fuel, rdo, routing openstack baremetal introspection internal server error https://ask.openstack.org/en/question/82790/openstack-baremetal-introspection-internal-server-error/ Tags: rdo, ironic-inspector, tripleo Installing openstack using packstack (rdo) failed https://ask.openstack.org/en/question/82473/installing-openstack-using-packstack-rdo-failed/ Tags: rdo, packstack, installation-error, keystone VMware Host Backend causes No valid host was found. Bug ??? https://ask.openstack.org/en/question/79738/vmware-host-backend-causes-no-valid-host-was-found-bug/ Tags: vmware, rdo Mutlinode Devstack with two interfaces https://ask.openstack.org/en/question/78615/mutlinode-devstack-with-two-interfaces/ Tags: devstack, vlan, openstack Overcloud deployment on VM fails as IP address from DHCP is not assigned https://ask.openstack.org/en/question/66272/overcloud-deployment-on-vm-fails-as-ip-address-from-dhcp-is-not-assigned/ Tags: overcloud_in_vm -- Rich Bowen - rbowen at redhat.com RDO Community Liaison http://rdoproject.org @RDOCommunity From rbowen at redhat.com Mon Oct 17 18:23:54 2016 From: rbowen at redhat.com (Rich Bowen) Date: Mon, 17 Oct 2016 14:23:54 -0400 Subject: [rdo-list] RDO Bug Statistics [2016-10-17] Message-ID: # RDO Bugs on 2016-10-17 This email summarizes the active RDO bugs listed in the Red Hat Bugzilla database at . To report a new bug against RDO, go to: ## Summary - Open (NEW, ASSIGNED, ON_DEV): 204 - Fixed (MODIFIED, POST, ON_QA): 57 ## Open bugs This is a list of "open" bugs by component. An "open" bug is in state NEW, ASSIGNED, ON_DEV and has not yet been fixed. (204 bugs) ### dib-utils (1 bug) [1263779 ] http://bugzilla.redhat.com/1263779 (NEW) Component: dib-utils Last change: 2016-04-18 Summary: Packstack Ironic admin_url misconfigured in nova.conf ### distribution (15 bugs) [1079491 ] http://bugzilla.redhat.com/1079491 (ASSIGNED) Component: distribution Last change: 2016-07-26 Summary: Need a way to pass extra arguments to openstack components at startup [1357660 ] http://bugzilla.redhat.com/1357660 (NEW) Component: distribution Last change: 2016-07-18 Summary: python-kombu: rpm package and python/requires.txt has different dependencies [1349665 ] http://bugzilla.redhat.com/1349665 (NEW) Component: distribution Last change: 2016-06-23 Summary: CVE-2016-4972 openstack-murano: RCE via usage of insecure YAML tags [openstack-rdo] [1243533 ] http://bugzilla.redhat.com/1243533 (NEW) Component: distribution Last change: 2016-06-01 Summary: (RDO) Tracker: Review requests for new RDO Liberty packages [1329341 ] http://bugzilla.redhat.com/1329341 (NEW) Component: distribution Last change: 2016-10-03 Summary: Tracker: Blockers and Review requests for new RDO Newton packages [1290163 ] http://bugzilla.redhat.com/1290163 (NEW) Component: distribution Last change: 2016-05-17 Summary: Tracker: Blockers and Review requests for new RDO Mitaka packages [1376642 ] http://bugzilla.redhat.com/1376642 (NEW) Component: distribution Last change: 2016-09-16 Summary: CVE-2016-6519 openstack-manila-ui: persistent XSS in metadata field [openstack-rdo] [1337335 ] http://bugzilla.redhat.com/1337335 (NEW) Component: distribution Last change: 2016-05-25 Summary: Hiera >= 2.x packaging [1346240 ] http://bugzilla.redhat.com/1346240 (ASSIGNED) Component: distribution Last change: 2016-06-21 Summary: Erlang 18.3.3 update fails [1373511 ] http://bugzilla.redhat.com/1373511 (NEW) Component: distribution Last change: 2016-10-05 Summary: New Package Request: virtualbmc [1359919 ] http://bugzilla.redhat.com/1359919 (NEW) Component: distribution Last change: 2016-07-25 Summary: Base url incorrect [1373513 ] http://bugzilla.redhat.com/1373513 (NEW) Component: distribution Last change: 2016-10-17 Summary: Tracker: Blockers and Review requests for new RDO Ocata packages [1349666 ] http://bugzilla.redhat.com/1349666 (NEW) Component: distribution Last change: 2016-06-23 Summary: CVE-2016-4972 python-muranoclient: openstack-murano: RCE via usage of insecure YAML tags [openstack-rdo] [1385086 ] http://bugzilla.redhat.com/1385086 (NEW) Component: distribution Last change: 2016-10-14 Summary: openstack-magnum now requires marathon [1301751 ] http://bugzilla.redhat.com/1301751 (NEW) Component: distribution Last change: 2016-04-18 Summary: Move all logging to stdout/err to allow systemd throttling logging of errors ### Documentation (3 bugs) [1358071 ] http://bugzilla.redhat.com/1358071 (NEW) Component: Documentation Last change: 2016-07-20 Summary: "Adding a compute node" recommends running using sudo with packstack in the final command, however, this causes Packstack to prompt for the user password endlessly, while running without sudo works fine. [1272108 ] http://bugzilla.redhat.com/1272108 (NEW) Component: Documentation Last change: 2016-04-18 Summary: [DOC] External network should be documents in RDO manager installation [1369944 ] http://bugzilla.redhat.com/1369944 (NEW) Component: Documentation Last change: 2016-08-24 Summary: Trunk won't work on RHEL 7 withou changing delorean- deps.repo $releasever to "7" ### instack (1 bug) [1315827 ] http://bugzilla.redhat.com/1315827 (NEW) Component: instack Last change: 2016-05-09 Summary: openstack undercloud install fails with "Element pip- and-virtualenv already loaded." ### instack-undercloud (10 bugs) [1347736 ] http://bugzilla.redhat.com/1347736 (NEW) Component: instack-undercloud Last change: 2016-06-17 Summary: Unable to install undercloud because tripleo-common is missing [1175687 ] http://bugzilla.redhat.com/1175687 (NEW) Component: instack-undercloud Last change: 2016-04-18 Summary: instack is not configued properly to log all Horizon/Tuskar messages in the undercloud deployment [1220509 ] http://bugzilla.redhat.com/1220509 (ASSIGNED) Component: instack-undercloud Last change: 2016-04-18 Summary: wget is missing from qcow2 image fails instack-build- images script [1199637 ] http://bugzilla.redhat.com/1199637 (ASSIGNED) Component: instack-undercloud Last change: 2016-04-18 Summary: [RDO][Instack-undercloud]: harmless ERROR: installing 'template' displays when building the images . [1271200 ] http://bugzilla.redhat.com/1271200 (ASSIGNED) Component: instack-undercloud Last change: 2016-04-18 Summary: Overcloud images contain Kilo repos [1216982 ] http://bugzilla.redhat.com/1216982 (ASSIGNED) Component: instack-undercloud Last change: 2016-04-18 Summary: instack-build-images does not stop on certain errors [1265334 ] http://bugzilla.redhat.com/1265334 (NEW) Component: instack-undercloud Last change: 2016-04-18 Summary: rdo-manager liberty instack undercloud puppet apply fails w/ missing package dep pyinotify [1211800 ] http://bugzilla.redhat.com/1211800 (ASSIGNED) Component: instack-undercloud Last change: 2016-04-18 Summary: Sphinx docs for instack-undercloud have an incorrect network topology [1200081 ] http://bugzilla.redhat.com/1200081 (NEW) Component: instack-undercloud Last change: 2016-04-18 Summary: Installing instack undercloud on Fedora20 VM fails [1369968 ] http://bugzilla.redhat.com/1369968 (NEW) Component: instack-undercloud Last change: 2016-08-28 Summary: Can't successfully install undercloud on mitaka/newton ### openstack-ceilometer (2 bugs) [1348222 ] http://bugzilla.redhat.com/1348222 (NEW) Component: openstack-ceilometer Last change: 2016-08-25 Summary: Unable to start ceilometer-central and gnocchi since redis module is missing on controller [1265741 ] http://bugzilla.redhat.com/1265741 (NEW) Component: openstack-ceilometer Last change: 2016-04-27 Summary: python-redis is not installed with packstack allinone ### openstack-cinder (4 bugs) [1121256 ] http://bugzilla.redhat.com/1121256 (NEW) Component: openstack-cinder Last change: 2016-04-19 Summary: Configuration file in share forces ignore of auth_uri [1382572 ] http://bugzilla.redhat.com/1382572 (NEW) Component: openstack-cinder Last change: 2016-10-07 Summary: CVE-2015-5162 openstack-cinder: openstack-nova: Malicious image causes OOM on the compute host [openstack-rdo] [1356690 ] http://bugzilla.redhat.com/1356690 (NEW) Component: openstack-cinder Last change: 2016-07-14 Summary: Can't attach additional volumes to volume-backed instance [1049535 ] http://bugzilla.redhat.com/1049535 (NEW) Component: openstack-cinder Last change: 2016-04-19 Summary: [RFE] permit cinder to create a volume when root_squash is set to on for gluster storage ### openstack-designate (2 bugs) [1343663 ] http://bugzilla.redhat.com/1343663 (NEW) Component: openstack-designate Last change: 2016-07-07 Summary: openstack-designate are missing dependancies [1361701 ] http://bugzilla.redhat.com/1361701 (NEW) Component: openstack-designate Last change: 2016-07-29 Summary: package and ship openstack-designate-ui rpm package ### openstack-glance (2 bugs) [1312466 ] http://bugzilla.redhat.com/1312466 (NEW) Component: openstack-glance Last change: 2016-04-19 Summary: Support for blueprint cinder-store-upload-download in glance_store [1382573 ] http://bugzilla.redhat.com/1382573 (NEW) Component: openstack-glance Last change: 2016-10-07 Summary: CVE-2015-5162 openstack-glance: openstack-nova: Malicious image causes OOM on the compute host [openstack-rdo] ### openstack-heat (1 bug) [1374183 ] http://bugzilla.redhat.com/1374183 (NEW) Component: openstack-heat Last change: 2016-09-08 Summary: Import Error for python-senlinclient python-zaqarclient python-magnumclient python-mistralclient ### openstack-horizon (1 bug) [1333508 ] http://bugzilla.redhat.com/1333508 (NEW) Component: openstack-horizon Last change: 2016-05-20 Summary: LBaaS v2 Dashboard UI ### openstack-ironic-discoverd (1 bug) [1211069 ] http://bugzilla.redhat.com/1211069 (ASSIGNED) Component: openstack-ironic-discoverd Last change: 2016-02-26 Summary: [RFE] [RDO-Manager] [discoverd] Add possibility to kill node discovery ### openstack-keystone (1 bug) [1337346 ] http://bugzilla.redhat.com/1337346 (NEW) Component: openstack-keystone Last change: 2016-06-01 Summary: CVE-2016-4911 openstack-keystone: Incorrect Audit IDs in Keystone Fernet Tokens can result in revocation bypass [openstack-rdo] ### openstack-neutron (7 bugs) [1065826 ] http://bugzilla.redhat.com/1065826 (ASSIGNED) Component: openstack-neutron Last change: 2016-08-26 Summary: [RFE] [neutron] neutron services needs more RPM granularity [1282403 ] http://bugzilla.redhat.com/1282403 (NEW) Component: openstack-neutron Last change: 2016-06-15 Summary: Errors when running tempest.api.network.test_ports with IPAM reference driver enabled [1372865 ] http://bugzilla.redhat.com/1372865 (NEW) Component: openstack-neutron Last change: 2016-10-17 Summary: mitaka neutron 8.2.0 point release [1147152 ] http://bugzilla.redhat.com/1147152 (NEW) Component: openstack-neutron Last change: 2016-06-07 Summary: Use neutron-sanity-check in CI checks [1353351 ] http://bugzilla.redhat.com/1353351 (NEW) Component: openstack-neutron Last change: 2016-07-06 Summary: vpnaas doesn't work [1349670 ] http://bugzilla.redhat.com/1349670 (NEW) Component: openstack-neutron Last change: 2016-06-23 Summary: CVE-2015-8914 CVE-2016-5362 CVE-2016-5363 openstack- neutron: various flaws [openstack-rdo] [1378989 ] http://bugzilla.redhat.com/1378989 (NEW) Component: openstack-neutron Last change: 2016-09-23 Summary: tempest.api.network.test_ports failures ### openstack-nova (9 bugs) [1228836 ] http://bugzilla.redhat.com/1228836 (NEW) Component: openstack-nova Last change: 2016-04-22 Summary: Is there a way to configure IO throttling for RBD devices via configuration file [1361908 ] http://bugzilla.redhat.com/1361908 (NEW) Component: openstack-nova Last change: 2016-08-02 Summary: nova can't mount instance disk with libguestfs - Permission denied [1382553 ] http://bugzilla.redhat.com/1382553 (NEW) Component: openstack-nova Last change: 2016-10-07 Summary: CVE-2015-5162 openstack-nova: Malicious image causes OOM on the compute host [openstack-rdo] [1381323 ] http://bugzilla.redhat.com/1381323 (NEW) Component: openstack-nova Last change: 2016-10-03 Summary: nova image-create fails with instances booted from volume [1294747 ] http://bugzilla.redhat.com/1294747 (NEW) Component: openstack-nova Last change: 2016-05-16 Summary: Migration fails when the SRIOV PF is not online [1086247 ] http://bugzilla.redhat.com/1086247 (ASSIGNED) Component: openstack-nova Last change: 2016-05-11 Summary: Ensure translations are installed correctly and picked up at runtime [1374727 ] http://bugzilla.redhat.com/1374727 (NEW) Component: openstack-nova Last change: 2016-09-09 Summary: Newly created instances sometimes get two private interfaces assigned [1379829 ] http://bugzilla.redhat.com/1379829 (NEW) Component: openstack-nova Last change: 2016-09-27 Summary: tempest failure: tempest.api.compute.servers.test_server_actions [1123298 ] http://bugzilla.redhat.com/1123298 (ASSIGNED) Component: openstack-nova Last change: 2016-04-22 Summary: logrotate should copytruncate to avoid openstack logging to deleted files ### openstack-packstack (41 bugs) [1194678 ] http://bugzilla.redhat.com/1194678 (NEW) Component: openstack-packstack Last change: 2016-04-18 Summary: On aarch64, nova.conf should default to vnc_enabled=False [1293693 ] http://bugzilla.redhat.com/1293693 (NEW) Component: openstack-packstack Last change: 2016-04-18 Summary: Keystone setup fails on missing required parameter [1286995 ] http://bugzilla.redhat.com/1286995 (NEW) Component: openstack-packstack Last change: 2016-04-18 Summary: PackStack should configure LVM filtering with LVM/iSCSI [1351873 ] http://bugzilla.redhat.com/1351873 (NEW) Component: openstack-packstack Last change: 2016-07-01 Summary: keystone.pp sets unreasonable execution time for keystone_manage token_flush [1371582 ] http://bugzilla.redhat.com/1371582 (NEW) Component: openstack-packstack Last change: 2016-08-30 Summary: dnsmasq-neutron.conf is left unmanaged after installation [1353195 ] http://bugzilla.redhat.com/1353195 (NEW) Component: openstack-packstack Last change: 2016-07-06 Summary: [RFE] enable configuration of cinder lvm volume group name in packstack [1353048 ] http://bugzilla.redhat.com/1353048 (NEW) Component: openstack-packstack Last change: 2016-07-05 Summary: manila is misconfigured after deployment [1297692 ] http://bugzilla.redhat.com/1297692 (ON_DEV) Component: openstack-packstack Last change: 2016-05-19 Summary: Raise MariaDB max connections limit [1361704 ] http://bugzilla.redhat.com/1361704 (NEW) Component: openstack-packstack Last change: 2016-07-29 Summary: [RFE] add support for designate [1188491 ] http://bugzilla.redhat.com/1188491 (ASSIGNED) Component: openstack-packstack Last change: 2016-05-19 Summary: Packstack wording is unclear for demo and testing provisioning. [1201612 ] http://bugzilla.redhat.com/1201612 (ASSIGNED) Component: openstack-packstack Last change: 2016-05-19 Summary: Interactive - Packstack asks for Tempest details even when Tempest install is declined [982035 ] http://bugzilla.redhat.com/982035 (ASSIGNED) Component: openstack-packstack Last change: 2016-04-19 Summary: [RFE] Include Fedora cloud images in some nice way [1061753 ] http://bugzilla.redhat.com/1061753 (NEW) Component: openstack-packstack Last change: 2016-05-16 Summary: [RFE] Create an option in packstack to increase verbosity level of libvirt [903645 ] http://bugzilla.redhat.com/903645 (ASSIGNED) Component: openstack-packstack Last change: 2016-04-18 Summary: RFE: Include the ability in PackStack to support SSL for all REST services and message bus communication [1324070 ] http://bugzilla.redhat.com/1324070 (NEW) Component: openstack-packstack Last change: 2016-04-18 Summary: RFE: PackStack Support for LBaaSv2 [1292271 ] http://bugzilla.redhat.com/1292271 (ASSIGNED) Component: openstack-packstack Last change: 2016-09-08 Summary: Receive Msg 'Error: Could not find user glance' [1097291 ] http://bugzilla.redhat.com/1097291 (NEW) Component: openstack-packstack Last change: 2016-05-18 Summary: [RFE] SPICE support in packstack [1353050 ] http://bugzilla.redhat.com/1353050 (NEW) Component: openstack-packstack Last change: 2016-07-05 Summary: packages openstack-manila-ui and openstack-trove-ui are not installed by packstack [1012382 ] http://bugzilla.redhat.com/1012382 (ON_DEV) Component: openstack-packstack Last change: 2016-04-19 Summary: swift: Admin user does not have permissions to see containers created by glance service [1352980 ] http://bugzilla.redhat.com/1352980 (NEW) Component: openstack-packstack Last change: 2016-09-23 Summary: it's not possible to deploy openstack with keystone api version v3 [1286828 ] http://bugzilla.redhat.com/1286828 (NEW) Component: openstack-packstack Last change: 2016-05-19 Summary: Packstack should have the option to install QoS (neutron) [1382100 ] http://bugzilla.redhat.com/1382100 (ASSIGNED) Component: openstack-packstack Last change: 2016-10-11 Summary: Running packstack with answer file "Error: Error appeared during puppet run: 10.0.2.15_horizon.pp" [1353045 ] http://bugzilla.redhat.com/1353045 (NEW) Component: openstack-packstack Last change: 2016-07-05 Summary: CONFIG_KEYSTONE_REGION is not honoured for all endpoints [1023533 ] http://bugzilla.redhat.com/1023533 (ASSIGNED) Component: openstack-packstack Last change: 2016-04-18 Summary: API services has all admin permission instead of service [1063393 ] http://bugzilla.redhat.com/1063393 (ASSIGNED) Component: openstack-packstack Last change: 2016-05-18 Summary: RFE: Provide option to set bind_host/bind_port for API services [1302766 ] http://bugzilla.redhat.com/1302766 (NEW) Component: openstack-packstack Last change: 2016-05-19 Summary: Add Magnum support using puppet-magnum [1285494 ] http://bugzilla.redhat.com/1285494 (NEW) Component: openstack-packstack Last change: 2016-05-19 Summary: openstack- packstack-7.0.0-0.5.dev1661.gaf13b7e.el7.noarch cripples(?) httpd.conf [1291492 ] http://bugzilla.redhat.com/1291492 (NEW) Component: openstack-packstack Last change: 2016-04-18 Summary: Unfriendly behavior of IP filtering for VXLAN with EXCLUDE_SERVERS [1316222 ] http://bugzilla.redhat.com/1316222 (ASSIGNED) Component: openstack-packstack Last change: 2016-05-18 Summary: Packstack installation failed due to wrong http config [1227298 ] http://bugzilla.redhat.com/1227298 (NEW) Component: openstack-packstack Last change: 2016-08-30 Summary: Packstack should support MTU settings [1269535 ] http://bugzilla.redhat.com/1269535 (NEW) Component: openstack-packstack Last change: 2016-08-29 Summary: packstack script does not test to see if the rc files *were* created. [1005073 ] http://bugzilla.redhat.com/1005073 (NEW) Component: openstack-packstack Last change: 2016-04-19 Summary: [RFE] Please add glance and nova lib folder config [1239027 ] http://bugzilla.redhat.com/1239027 (NEW) Component: openstack-packstack Last change: 2016-04-18 Summary: please move httpd log files to corresponding dirs [1383620 ] http://bugzilla.redhat.com/1383620 (NEW) Component: openstack-packstack Last change: 2016-10-11 Summary: Packstack fails tox py27 unit tests only on RHEL [1168113 ] http://bugzilla.redhat.com/1168113 (ASSIGNED) Component: openstack-packstack Last change: 2016-04-18 Summary: The warning message " NetworkManager is active " appears even when the NetworkManager is inactive [1116019 ] http://bugzilla.redhat.com/1116019 (ASSIGNED) Component: openstack-packstack Last change: 2016-09-07 Summary: AMQP1.0 server configurations needed [1312487 ] http://bugzilla.redhat.com/1312487 (ASSIGNED) Component: openstack-packstack Last change: 2016-04-18 Summary: Packstack with Swift Glance backend does not seem to work [1184806 ] http://bugzilla.redhat.com/1184806 (NEW) Component: openstack-packstack Last change: 2016-04-28 Summary: [RFE] Packstack should support deploying Nova and Glance with RBD images and Ceph as a backend [1172310 ] http://bugzilla.redhat.com/1172310 (ASSIGNED) Component: openstack-packstack Last change: 2016-04-19 Summary: support Keystone LDAP [1385025 ] http://bugzilla.redhat.com/1385025 (NEW) Component: openstack-packstack Last change: 2016-10-14 Summary: Manila image corruted [1200129 ] http://bugzilla.redhat.com/1200129 (ASSIGNED) Component: openstack-packstack Last change: 2016-04-18 Summary: [RFE] add support for ceilometer workload partitioning via tooz/redis ### openstack-puppet-modules (10 bugs) [1318332 ] http://bugzilla.redhat.com/1318332 (NEW) Component: openstack-puppet-modules Last change: 2016-04-19 Summary: Cinder workaround should be removed [1297535 ] http://bugzilla.redhat.com/1297535 (ASSIGNED) Component: openstack-puppet-modules Last change: 2016-04-18 Summary: Undercloud installation fails ::aodh::keystone::auth not found for instack [1107907 ] http://bugzilla.redhat.com/1107907 (NEW) Component: openstack-puppet-modules Last change: 2016-05-18 Summary: Offset Swift ports to 6200 [1289761 ] http://bugzilla.redhat.com/1289761 (NEW) Component: openstack-puppet-modules Last change: 2016-08-29 Summary: PackStack installs Nova crontab that nova user can't run [1371218 ] http://bugzilla.redhat.com/1371218 (ASSIGNED) Component: openstack-puppet-modules Last change: 2016-09-08 Summary: [puppet-ceph] When deploying a large number of OSDs not all OSDs are activated but all are prepared [1382511 ] http://bugzilla.redhat.com/1382511 (NEW) Component: openstack-puppet-modules Last change: 2016-10-06 Summary: Purge support for mitaka missing key patch [1150902 ] http://bugzilla.redhat.com/1150902 (ASSIGNED) Component: openstack-puppet-modules Last change: 2016-04-18 Summary: selinux prevents httpd to write to /var/log/horizon/horizon.log [1316856 ] http://bugzilla.redhat.com/1316856 (NEW) Component: openstack-puppet-modules Last change: 2016-09-24 Summary: packstack fails to configure ovs bridge for CentOS [1240736 ] http://bugzilla.redhat.com/1240736 (NEW) Component: openstack-puppet-modules Last change: 2016-04-18 Summary: trove guestagent config mods for integration testing [1369164 ] http://bugzilla.redhat.com/1369164 (NEW) Component: openstack-puppet-modules Last change: 2016-08-22 Summary: multidomain is not supported in RDO Mitaka ### openstack-sahara (2 bugs) [1305790 ] http://bugzilla.redhat.com/1305790 (NEW) Component: openstack-sahara Last change: 2016-07-13 Summary: Failure to launch Caldera 5.0.4 Hadoop Cluster via Sahara Wizards on RDO Liberty [1357667 ] http://bugzilla.redhat.com/1357667 (NEW) Component: openstack-sahara Last change: 2016-08-16 Summary: tempest.api.data_processing tests failing on newton ### openstack-selinux (7 bugs) [1373321 ] http://bugzilla.redhat.com/1373321 (NEW) Component: openstack-selinux Last change: 2016-09-06 Summary: Can't deploy an overcloud because selinux blocks neutron_t to access unlabeled_t files (nsfs) [1359216 ] http://bugzilla.redhat.com/1359216 (NEW) Component: openstack-selinux Last change: 2016-09-06 Summary: openstack-selinux does not allow neutron to access /proc/self/ns/net (centos) [1353227 ] http://bugzilla.redhat.com/1353227 (NEW) Component: openstack-selinux Last change: 2016-07-06 Summary: openstack-designate AVCs when named/bind tries to read configuration out of /var/lib/designate [1174795 ] http://bugzilla.redhat.com/1174795 (NEW) Component: openstack-selinux Last change: 2016-04-18 Summary: keystone fails to start: raise exception.ConfigFileNotF ound(config_file=paste_config_value) [1362609 ] http://bugzilla.redhat.com/1362609 (NEW) Component: openstack-selinux Last change: 2016-08-03 Summary: glance-registry AVC name_connect when using memcached [1360165 ] http://bugzilla.redhat.com/1360165 (NEW) Component: openstack-selinux Last change: 2016-09-15 Summary: Add a rule to allow a non-ephemeral cluster port for rabbitmq [1341738 ] http://bugzilla.redhat.com/1341738 (NEW) Component: openstack-selinux Last change: 2016-06-01 Summary: AVC: beam.smp tries to write in SSL certificate ### openstack-swift (2 bugs) [1382921 ] http://bugzilla.redhat.com/1382921 (NEW) Component: openstack-swift Last change: 2016-10-11 Summary: swift-object-expirer packaged in wrong package [1352456 ] http://bugzilla.redhat.com/1352456 (NEW) Component: openstack-swift Last change: 2016-07-04 Summary: Swift Liberty reports "%RPMVERSION%" instead of actual version string ### openstack-tripleo (35 bugs) [1056109 ] http://bugzilla.redhat.com/1056109 (NEW) Component: openstack-tripleo Last change: 2016-04-18 Summary: [RFE][tripleo]: Making the overcloud deployment fully HA [1351570 ] http://bugzilla.redhat.com/1351570 (NEW) Component: openstack-tripleo Last change: 2016-06-30 Summary: Failure to deploy 3 Node HA Controller and 2 Compute Nodes via Tripleo QuickStart [1344620 ] http://bugzilla.redhat.com/1344620 (NEW) Component: openstack-tripleo Last change: 2016-06-10 Summary: Nova instance live migration fails: migrateToURI3() got an unexpected keyword argument 'bandwidth' [1056110 ] http://bugzilla.redhat.com/1056110 (NEW) Component: openstack-tripleo Last change: 2016-04-18 Summary: [RFE][tripleo]: Scaling work to do during icehouse [1364789 ] http://bugzilla.redhat.com/1364789 (NEW) Component: openstack-tripleo Last change: 2016-08-17 Summary: Openstack undercloud install ( via instack-virt-setup ) craches on instack VM with error 'ImportError: No module named osc_lib' [1344507 ] http://bugzilla.redhat.com/1344507 (NEW) Component: openstack-tripleo Last change: 2016-06-21 Summary: Nova novnc console doesn't load 2/3 times: Failed to connect to server (code: 1006) [1344495 ] http://bugzilla.redhat.com/1344495 (NEW) Component: openstack-tripleo Last change: 2016-06-09 Summary: Horizon: Error: Unable to retrieve project list and Error: Unable to retrieve domain list. [1329095 ] http://bugzilla.redhat.com/1329095 (NEW) Component: openstack-tripleo Last change: 2016-04-22 Summary: mariadb and keystone down after an upgrade from liberty to mitaka [1365884 ] http://bugzilla.redhat.com/1365884 (NEW) Component: openstack-tripleo Last change: 2016-08-17 Summary: MySQL Galera fails to start [1351547 ] http://bugzilla.redhat.com/1351547 (ASSIGNED) Component: openstack-tripleo Last change: 2016-07-05 Summary: Rabbitmq clone starts on just one node in a HA deploy [1344442 ] http://bugzilla.redhat.com/1344442 (NEW) Component: openstack-tripleo Last change: 2016-06-09 Summary: Ceilometer central fails to start: ImportError: No module named redis [1056106 ] http://bugzilla.redhat.com/1056106 (NEW) Component: openstack-tripleo Last change: 2016-04-18 Summary: [RFE][ironic]: Integration of Ironic in to TripleO [1277980 ] http://bugzilla.redhat.com/1277980 (NEW) Component: openstack-tripleo Last change: 2016-04-18 Summary: missing python-proliantutils [1358083 ] http://bugzilla.redhat.com/1358083 (NEW) Component: openstack-tripleo Last change: 2016-07-20 Summary: openstack-tripleo: /usr/share/instack-undercloud /puppet-stack-config/puppet-stack-config.yaml.template (line 429) misses right curly bracket, this creates misconfigured /httpboot/inspector.ipxe and introspection fails. [1361613 ] http://bugzilla.redhat.com/1361613 (NEW) Component: openstack-tripleo Last change: 2016-07-29 Summary: Deployment of RDO M2, Gnocchi statsd gets configured only on first controller in HA environment and it fails to start on the rest of 2 controllers [1340865 ] http://bugzilla.redhat.com/1340865 (NEW) Component: openstack-tripleo Last change: 2016-06-07 Summary: Tripleo QuickStart HA deployment attempts constantly crash [1056112 ] http://bugzilla.redhat.com/1056112 (NEW) Component: openstack-tripleo Last change: 2016-04-18 Summary: [RFE][tripleo]: Deploying different architecture topologies with Tuskar [1353915 ] http://bugzilla.redhat.com/1353915 (NEW) Component: openstack-tripleo Last change: 2016-07-18 Summary: [RFE] Add to scripts generated by undercloud install - script to replace failed TripleO QuickStart HA Controller [1174776 ] http://bugzilla.redhat.com/1174776 (NEW) Component: openstack-tripleo Last change: 2016-04-18 Summary: User can not login into the overcloud horizon using the proper credentials [1353976 ] http://bugzilla.redhat.com/1353976 (NEW) Component: openstack-tripleo Last change: 2016-07-11 Summary: tripleo ceontos7 images missing linux-firmware package [1303614 ] http://bugzilla.redhat.com/1303614 (NEW) Component: openstack-tripleo Last change: 2016-04-18 Summary: overcloud deployment failed AttributeError: 'Proxy' object has no attribute 'api' [1364129 ] http://bugzilla.redhat.com/1364129 (NEW) Component: openstack-tripleo Last change: 2016-08-05 Summary: Overcloud pacemaker services restart behavior causes downtime [1341093 ] http://bugzilla.redhat.com/1341093 (NEW) Component: openstack-tripleo Last change: 2016-06-01 Summary: Tripleo QuickStart HA deployment attempts constantly crash [1056114 ] http://bugzilla.redhat.com/1056114 (NEW) Component: openstack-tripleo Last change: 2016-04-18 Summary: [RFE][tripleo]: Implement a complete overcloud installation story in the UI [1359911 ] http://bugzilla.redhat.com/1359911 (NEW) Component: openstack-tripleo Last change: 2016-07-25 Summary: Cannot generate overcloud images with liberty [1365545 ] http://bugzilla.redhat.com/1365545 (NEW) Component: openstack-tripleo Last change: 2016-08-09 Summary: Overcloud been set up via instack-virt-setup fails to run `nova keypair-add oskey > oskey.pem` [1380207 ] http://bugzilla.redhat.com/1380207 (NEW) Component: openstack-tripleo Last change: 2016-09-29 Summary: Doing overcloud stack update (package upgrade) fails with error saying can't find resource openstack- keystone [1344398 ] http://bugzilla.redhat.com/1344398 (NEW) Component: openstack-tripleo Last change: 2016-06-09 Summary: SSL enabled undercloud doesn't configure https protocol for several endpoints [1343634 ] http://bugzilla.redhat.com/1343634 (NEW) Component: openstack-tripleo Last change: 2016-06-07 Summary: controller-no-external.yaml template still creates external network and fails to deploy [1350605 ] http://bugzilla.redhat.com/1350605 (NEW) Component: openstack-tripleo Last change: 2016-06-27 Summary: Error regarding the TUN device using quickstart.sh [1344467 ] http://bugzilla.redhat.com/1344467 (NEW) Component: openstack-tripleo Last change: 2016-08-29 Summary: Unable to launch instance: Invalid: Volume sets discard option, qemu (1, 6, 0) or later is required. [1277990 ] http://bugzilla.redhat.com/1277990 (NEW) Component: openstack-tripleo Last change: 2016-04-18 Summary: openstack-ironic-inspector-dnsmasq.service: failed to start during undercloud installation [1344447 ] http://bugzilla.redhat.com/1344447 (NEW) Component: openstack-tripleo Last change: 2016-06-21 Summary: Openstack-gnocchi-statsd fails to start; ImportError: Your rados python module does not support omap feature. Install 'cradox' (recommended) or upgrade 'python- rados' >= 9.1.0 [1344451 ] http://bugzilla.redhat.com/1344451 (NEW) Component: openstack-tripleo Last change: 2016-06-20 Summary: HAProxy logs show up in the os-collect-config journal [1334259 ] http://bugzilla.redhat.com/1334259 (NEW) Component: openstack-tripleo Last change: 2016-05-09 Summary: openstack overcloud image upload fails with "Required file "./ironic-python-agent.initramfs" does not exist." ### openstack-tripleo-heat-templates (3 bugs) [1342145 ] http://bugzilla.redhat.com/1342145 (NEW) Component: openstack-tripleo-heat-templates Last change: 2016-06-02 Summary: Deploying Manila is not possible due to missing template [1364032 ] http://bugzilla.redhat.com/1364032 (NEW) Component: openstack-tripleo-heat-templates Last change: 2016-08-23 Summary: Mixed deployment with UC in Mitaka and OC in Newton scale up fails with sql error [1266027 ] http://bugzilla.redhat.com/1266027 (NEW) Component: openstack-tripleo-heat-templates Last change: 2016-04-18 Summary: TripleO should use pymysql database driver since Liberty ### openstack-tripleo-image-elements (2 bugs) [1303567 ] http://bugzilla.redhat.com/1303567 (NEW) Component: openstack-tripleo-image-elements Last change: 2016-04-18 Summary: Overcloud deployment fails using Ceph [1347652 ] http://bugzilla.redhat.com/1347652 (NEW) Component: openstack-tripleo-image-elements Last change: 2016-06-22 Summary: post-install deletes foreign o-r-c configure.d scripts ### openstack-trove (1 bug) [1327068 ] http://bugzilla.redhat.com/1327068 (NEW) Component: openstack-trove Last change: 2016-05-24 Summary: trove guest agent should create a sudoers entry ### Package Review (19 bugs) [1365932 ] http://bugzilla.redhat.com/1365932 (ASSIGNED) Component: Package Review Last change: 2016-09-20 Summary: import puppet-barbican into OPM [1327635 ] http://bugzilla.redhat.com/1327635 (ASSIGNED) Component: Package Review Last change: 2016-09-07 Summary: Review Request: openstack-congress - OpenStack Congress Service [1344368 ] http://bugzilla.redhat.com/1344368 (NEW) Component: Package Review Last change: 2016-06-09 Summary: Review Request: openstack-ironic-ui - OpenStack Ironic Dashboard [1272513 ] http://bugzilla.redhat.com/1272513 (ASSIGNED) Component: Package Review Last change: 2016-05-20 Summary: Review Request: Murano - is an application catalog for OpenStack [1350974 ] http://bugzilla.redhat.com/1350974 (ASSIGNED) Component: Package Review Last change: 2016-09-21 Summary: Openstack python-watcherclient [1331486 ] http://bugzilla.redhat.com/1331486 (NEW) Component: Package Review Last change: 2016-09-19 Summary: Tracker bugzilla for puppet packages in RDO Newton cycle [1378458 ] http://bugzilla.redhat.com/1378458 (NEW) Component: Package Review Last change: 2016-09-30 Summary: Review Request: openstack-murano-agent - VM-side guest agent that accepts and executes commands from Murano engine [1385604 ] http://bugzilla.redhat.com/1385604 (NEW) Component: Package Review Last change: 2016-10-17 Summary: Add python-networking-vsphere package to rdo [1374800 ] http://bugzilla.redhat.com/1374800 (ASSIGNED) Component: Package Review Last change: 2016-09-16 Summary: Review Request: puppet-magnum [1342227 ] http://bugzilla.redhat.com/1342227 (ASSIGNED) Component: Package Review Last change: 2016-06-06 Summary: Review Request: python-designate-tests-tempest - Tempest Integration of Designate [1279513 ] http://bugzilla.redhat.com/1279513 (ASSIGNED) Component: Package Review Last change: 2016-10-08 Summary: New Package: python-dracclient [1326586 ] http://bugzilla.redhat.com/1326586 (NEW) Component: Package Review Last change: 2016-08-24 Summary: Review request: Sensu [1272524 ] http://bugzilla.redhat.com/1272524 (ASSIGNED) Component: Package Review Last change: 2016-05-19 Summary: Review Request: openstack-mistral - workflow Service for OpenStack cloud [1379786 ] http://bugzilla.redhat.com/1379786 (NEW) Component: Package Review Last change: 2016-10-11 Summary: Review Request: python-vitrage - Python bindings to the Vitrage API [1379646 ] http://bugzilla.redhat.com/1379646 (NEW) Component: Package Review Last change: 2016-10-12 Summary: New package: python-networking-bagpipe [1361959 ] http://bugzilla.redhat.com/1361959 (ASSIGNED) Component: Package Review Last change: 2016-09-01 Summary: Include puppet-ovn in openstack-puppet-modules [1342987 ] http://bugzilla.redhat.com/1342987 (ASSIGNED) Component: Package Review Last change: 2016-10-16 Summary: Review Request: openstack-vitrage - OpenStack RCA (Root Cause Analysis) Engine [1312328 ] http://bugzilla.redhat.com/1312328 (NEW) Component: Package Review Last change: 2016-10-10 Summary: New Package: openstack-ironic-staging-drivers [1376763 ] http://bugzilla.redhat.com/1376763 (NEW) Component: Package Review Last change: 2016-10-17 Summary: New package: python-networking-bgpvpn ### python-fixtures (1 bug) [1379427 ] http://bugzilla.redhat.com/1379427 (NEW) Component: python-fixtures Last change: 2016-09-27 Summary: python-fixtures >= 3 is required for neutron ### python-novaclient (1 bug) [1123451 ] http://bugzilla.redhat.com/1123451 (ASSIGNED) Component: python-novaclient Last change: 2016-05-02 Summary: Missing versioned dependency on python-six ### python-webob (1 bug) [1384058 ] http://bugzilla.redhat.com/1384058 (NEW) Component: python-webob Last change: 2016-10-12 Summary: In Newton python-webob 1.6.1 is required as in upper- constraints.txt ### rdo-manager (15 bugs) [1306350 ] http://bugzilla.redhat.com/1306350 (NEW) Component: rdo-manager Last change: 2016-04-18 Summary: With RDO-manager, if not configured, the first nic on compute nodes gets addresses from dhcp as a default [1272376 ] http://bugzilla.redhat.com/1272376 (NEW) Component: rdo-manager Last change: 2016-04-18 Summary: Duplicate nova hypervisors after rebooting compute nodes [1370653 ] http://bugzilla.redhat.com/1370653 (NEW) Component: rdo-manager Last change: 2016-09-06 Summary: Deploying overcloud fails at step4 of the controllers [1270910 ] http://bugzilla.redhat.com/1270910 (ASSIGNED) Component: rdo-manager Last change: 2016-07-27 Summary: IP address from external subnet gets assigned to br-ex when using default single-nic-vlans templates [1306364 ] http://bugzilla.redhat.com/1306364 (NEW) Component: rdo-manager Last change: 2016-04-18 Summary: With RDO-manager, using bridge mappings, Neutron opensvswitch-agent plugin's config file don't gets populated correctly [1230582 ] http://bugzilla.redhat.com/1230582 (NEW) Component: rdo-manager Last change: 2016-04-18 Summary: there is a newer image that can be used to deploy openstack [1294683 ] http://bugzilla.redhat.com/1294683 (NEW) Component: rdo-manager Last change: 2016-04-18 Summary: instack-undercloud: "openstack undercloud install" throws errors and then gets stuck due to selinux. [1271289 ] http://bugzilla.redhat.com/1271289 (NEW) Component: rdo-manager Last change: 2016-04-18 Summary: overcloud-novacompute stuck in spawning state [1216981 ] http://bugzilla.redhat.com/1216981 (ASSIGNED) Component: rdo-manager Last change: 2016-04-18 Summary: No way to increase yum timeouts when building images [1270370 ] http://bugzilla.redhat.com/1270370 (NEW) Component: rdo-manager Last change: 2016-04-18 Summary: [RDO-Manager] bulk introspection moving the nodes from available to manageable too quickly [getting: NodeLocked:] [1292253 ] http://bugzilla.redhat.com/1292253 (NEW) Component: rdo-manager Last change: 2016-04-18 Summary: Production + EPEL + yum-plugin-priorities results in wrong version of hiera [1273541 ] http://bugzilla.redhat.com/1273541 (NEW) Component: rdo-manager Last change: 2016-04-18 Summary: RDO-Manager needs epel.repo enabled (otherwise undercloud deployment fails.) [1271726 ] http://bugzilla.redhat.com/1271726 (NEW) Component: rdo-manager Last change: 2016-04-18 Summary: 1 of the overcloud VMs (nova) is stack in spawning state [1273680 ] http://bugzilla.redhat.com/1273680 (ASSIGNED) Component: rdo-manager Last change: 2016-04-18 Summary: HA overcloud with network isolation deployment fails [1270805 ] http://bugzilla.redhat.com/1270805 (NEW) Component: rdo-manager Last change: 2016-04-18 Summary: Glance client returning 'Expected endpoint' ### rdopkg (1 bug) [1353406 ] http://bugzilla.redhat.com/1353406 (NEW) Component: rdopkg Last change: 2016-07-07 Summary: Expired SSL for RPM package. ### RFEs (2 bugs) [1193886 ] http://bugzilla.redhat.com/1193886 (ASSIGNED) Component: RFEs Last change: 2016-04-18 Summary: RFE: wait for DB after boot [1158517 ] http://bugzilla.redhat.com/1158517 (NEW) Component: RFEs Last change: 2016-05-20 Summary: [RFE] Provide easy to use upgrade tool ### tempest (1 bug) [1250081 ] http://bugzilla.redhat.com/1250081 (NEW) Component: tempest Last change: 2015-08-06 Summary: test_minimum_basic scenario failed to run on rdo- manager ## Fixed bugs This is a list of "fixed" bugs by component. A "fixed" bug is fixed state MODIFIED, POST, ON_QA and has been fixed. You can help out by testing the fix to make sure it works as intended. (57 bugs) ### distribution (4 bugs) [1328980 ] http://bugzilla.redhat.com/1328980 (MODIFIED) Component: distribution Last change: 2016-04-21 Summary: Log handler repeatedly crashes [1368182 ] http://bugzilla.redhat.com/1368182 (MODIFIED) Component: distribution Last change: 2016-09-02 Summary: Rabbitmq-server has a new version in Fedora that addresses several bugs [1134121 ] http://bugzilla.redhat.com/1134121 (POST) Component: distribution Last change: 2016-04-18 Summary: Tuskar Fails After Remove/Reinstall Of RDO [1344148 ] http://bugzilla.redhat.com/1344148 (ON_QA) Component: distribution Last change: 2016-06-17 Summary: RDO mitaka openstack-tempest build requires updated python-urllib3 ### instack-undercloud (1 bug) [1270033 ] http://bugzilla.redhat.com/1270033 (POST) Component: instack-undercloud Last change: 2016-05-05 Summary: [RDO-Manager] Node inspection fails when changing the default 'inspection_iprange' value in undecloud.conf. ### openstack-ceilometer (2 bugs) [1287252 ] http://bugzilla.redhat.com/1287252 (POST) Component: openstack-ceilometer Last change: 2016-04-18 Summary: openstack-ceilometer-alarm-notifier does not start: unit file is missing [1331510 ] http://bugzilla.redhat.com/1331510 (ON_QA) Component: openstack-ceilometer Last change: 2016-07-29 Summary: Gnocchi 2.0.2-1 release does not have Mitaka default configuration file ### openstack-glance (1 bug) [1074724 ] http://bugzilla.redhat.com/1074724 (POST) Component: openstack-glance Last change: 2016-04-19 Summary: Glance api ssl issue ### openstack-ironic (2 bugs) [1348817 ] http://bugzilla.redhat.com/1348817 (ON_QA) Component: openstack-ironic Last change: 2016-06-23 Summary: CVE-2016-4985 openstack-ironic: Ironic Node information including credentials exposed to unauthenticated users [openstack-rdo] [1373394 ] http://bugzilla.redhat.com/1373394 (MODIFIED) Component: openstack-ironic Last change: 2016-09-09 Summary: wwn_vendor_extension not supported ### openstack-ironic-discoverd (1 bug) [1322892 ] http://bugzilla.redhat.com/1322892 (MODIFIED) Component: openstack-ironic-discoverd Last change: 2016-10-08 Summary: No valid interfaces found during introspection ### openstack-keystone (2 bugs) [1280530 ] http://bugzilla.redhat.com/1280530 (MODIFIED) Component: openstack-keystone Last change: 2016-05-20 Summary: Fernet tokens cannot read key files with SELInux enabled [1341332 ] http://bugzilla.redhat.com/1341332 (POST) Component: openstack-keystone Last change: 2016-06-01 Summary: keystone logrotate configuration should use size configuration ### openstack-nova (2 bugs) [1367696 ] http://bugzilla.redhat.com/1367696 (ON_QA) Component: openstack-nova Last change: 2016-09-23 Summary: Add RPM deps to require install of qemu-kvm-rhev, not qemu-kvm-rhel [1301156 ] http://bugzilla.redhat.com/1301156 (POST) Component: openstack-nova Last change: 2016-04-22 Summary: openstack-nova missing specfile requires on castellan>=0.3.1 ### openstack-packstack (20 bugs) [1335612 ] http://bugzilla.redhat.com/1335612 (MODIFIED) Component: openstack-packstack Last change: 2016-05-31 Summary: CONFIG_USE_SUBNETS=y won't work correctly with VLAN [1028690 ] http://bugzilla.redhat.com/1028690 (POST) Component: openstack-packstack Last change: 2016-04-18 Summary: packstack requires 2 runs to install ceilometer [1288179 ] http://bugzilla.redhat.com/1288179 (POST) Component: openstack-packstack Last change: 2016-04-18 Summary: Mitaka: Packstack image provisioning fails with "Store filesystem could not be configured correctly" [1018900 ] http://bugzilla.redhat.com/1018900 (MODIFIED) Component: openstack-packstack Last change: 2016-05-18 Summary: Packstack fails with "The iptables provider can not handle attribute outiface" [1080369 ] http://bugzilla.redhat.com/1080369 (POST) Component: openstack-packstack Last change: 2016-04-18 Summary: packstack fails with KeyError :CONFIG_PROVISION_DEMO_FLOATRANGE if more compute-hosts are added [1302275 ] http://bugzilla.redhat.com/1302275 (POST) Component: openstack-packstack Last change: 2016-04-18 Summary: neutron-l3-agent does not start on Mitaka-2 when enabling FWaaS [1302256 ] http://bugzilla.redhat.com/1302256 (POST) Component: openstack-packstack Last change: 2016-04-18 Summary: neutron-server does not start on Mitaka-2 when enabling LBaaS [1150652 ] http://bugzilla.redhat.com/1150652 (POST) Component: openstack-packstack Last change: 2016-04-18 Summary: PackStack does not provide an option to register hosts to Red Hat Satellite 6 [1049537 ] http://bugzilla.redhat.com/1049537 (MODIFIED) Component: openstack-packstack Last change: 2016-05-18 Summary: Horizon help url in RDO points to the RHOS documentation [1255369 ] http://bugzilla.redhat.com/1255369 (POST) Component: openstack-packstack Last change: 2016-05-19 Summary: Improve session settings for horizon [1298245 ] http://bugzilla.redhat.com/1298245 (MODIFIED) Component: openstack-packstack Last change: 2016-04-18 Summary: Add possibility to change DEFAULT/api_paste_config in trove.conf [1148949 ] http://bugzilla.redhat.com/1148949 (POST) Component: openstack-packstack Last change: 2016-04-18 Summary: openstack-packstack: installed "packstack --allinone" on Centos7.0 and configured private networking. The booted VMs are not able to communicate with each other, nor ping the gateway. [1172467 ] http://bugzilla.redhat.com/1172467 (POST) Component: openstack-packstack Last change: 2016-09-06 Summary: New user cannot retrieve container listing [1124982 ] http://bugzilla.redhat.com/1124982 (POST) Component: openstack-packstack Last change: 2016-04-18 Summary: Help text for SSL is incorrect regarding passphrase on the cert [1330289 ] http://bugzilla.redhat.com/1330289 (POST) Component: openstack-packstack Last change: 2016-10-17 Summary: Failure to install Controller/Network&&Compute Cluster on RDO Mitaka with keystone API V3 [1385292 ] http://bugzilla.redhat.com/1385292 (ON_QA) Component: openstack-packstack Last change: 2016-10-17 Summary: Packstack mitaka does not work if testing repo is not enabled [1282746 ] http://bugzilla.redhat.com/1282746 (POST) Component: openstack-packstack Last change: 2016-09-09 Summary: Swift's proxy-server is not configured to use ceilometer [1297833 ] http://bugzilla.redhat.com/1297833 (POST) Component: openstack-packstack Last change: 2016-04-19 Summary: VPNaaS should use libreswan driver instead of openswan by default [1187412 ] http://bugzilla.redhat.com/1187412 (POST) Component: openstack-packstack Last change: 2016-04-18 Summary: Script wording for service installation should be consistent [1376769 ] http://bugzilla.redhat.com/1376769 (POST) Component: openstack-packstack Last change: 2016-09-16 Summary: Could not find data item CONFIG_CINDER_VOLUMES_CREATE in any Hiera data file and no default supplied ### openstack-puppet-modules (2 bugs) [1365892 ] http://bugzilla.redhat.com/1365892 (MODIFIED) Component: openstack-puppet-modules Last change: 2016-09-07 Summary: obsolete network_device_mtu configuration persists in configuration files [1385291 ] http://bugzilla.redhat.com/1385291 (POST) Component: openstack-puppet-modules Last change: 2016-10-17 Summary: Expecting to find domain in project - Newton RDO Build ### openstack-selinux (1 bug) [1357961 ] http://bugzilla.redhat.com/1357961 (MODIFIED) Component: openstack-selinux Last change: 2016-07-19 Summary: neutron-openvswitch-agent using of_interface = native triggers AVCs and fails to receive flow updates ### openstack-utils (1 bug) [1211989 ] http://bugzilla.redhat.com/1211989 (POST) Component: openstack-utils Last change: 2016-04-18 Summary: openstack-status shows 'disabled on boot' for the mysqld service ### Package Review (12 bugs) [1374802 ] http://bugzilla.redhat.com/1374802 (POST) Component: Package Review Last change: 2016-09-19 Summary: Review Request: puppet-designate [1347193 ] http://bugzilla.redhat.com/1347193 (MODIFIED) Component: Package Review Last change: 2016-06-24 Summary: Openstack Watcher service [1376887 ] http://bugzilla.redhat.com/1376887 (POST) Component: Package Review Last change: 2016-09-23 Summary: Review Request: puppet-dns [1177361 ] http://bugzilla.redhat.com/1177361 (MODIFIED) Component: Package Review Last change: 2016-09-22 Summary: Review Request: sahara-image-elements - Image creation tools for Openstack Sahara [1376889 ] http://bugzilla.redhat.com/1376889 (POST) Component: Package Review Last change: 2016-09-23 Summary: Review Request: puppet-powerdns [1341687 ] http://bugzilla.redhat.com/1341687 (ON_QA) Component: Package Review Last change: 2016-09-19 Summary: Review request: openstack-neutron-lbaas-ui [1372016 ] http://bugzilla.redhat.com/1372016 (MODIFIED) Component: Package Review Last change: 2016-09-16 Summary: Review Request: openstack-murano-ui - horizon plugin for OpenStack murano [1318765 ] http://bugzilla.redhat.com/1318765 (MODIFIED) Component: Package Review Last change: 2016-09-14 Summary: Review Request: openstack-sahara-tests - Sahara Scenario Test Framework [1361581 ] http://bugzilla.redhat.com/1361581 (ON_QA) Component: Package Review Last change: 2016-09-08 Summary: Review Request: openstack-tripleo-validations [1323219 ] http://bugzilla.redhat.com/1323219 (ON_QA) Component: Package Review Last change: 2016-05-12 Summary: Review Request: openstack-trove-ui - OpenStack Dashboard plugin for Trove project [1361707 ] http://bugzilla.redhat.com/1361707 (POST) Component: Package Review Last change: 2016-09-06 Summary: Review Request: openstack-panko - Event storage and REST API [1376215 ] http://bugzilla.redhat.com/1376215 (MODIFIED) Component: Package Review Last change: 2016-09-16 Summary: Review Request: openstack-tripleo-heat-templates-compat - Heat templates for TripleO old version support ### python-keystoneclient (1 bug) [973263 ] http://bugzilla.redhat.com/973263 (POST) Component: python-keystoneclient Last change: 2016-04-19 Summary: user-get fails when using IDs which are not UUIDs ### rdo-manager (2 bugs) [1268990 ] http://bugzilla.redhat.com/1268990 (POST) Component: rdo-manager Last change: 2016-04-18 Summary: missing from docs Build images fails without : export DIB_YUM_REPO_CONF="/etc/yum.repos.d/delorean.repo /etc/yum.repos.d/delorean-deps.repo" [1271335 ] http://bugzilla.redhat.com/1271335 (POST) Component: rdo-manager Last change: 2016-06-09 Summary: [RFE] Support explicit configuration of L2 population ### rdo-manager-cli (2 bugs) [1273197 ] http://bugzilla.redhat.com/1273197 (POST) Component: rdo-manager-cli Last change: 2016-04-18 Summary: VXLAN should be default neutron network type [1278972 ] http://bugzilla.redhat.com/1278972 (POST) Component: rdo-manager-cli Last change: 2016-04-18 Summary: rdo-manager liberty delorean dib failing w/ "No module named passlib.utils" ### tempest (1 bug) [1342218 ] http://bugzilla.redhat.com/1342218 (MODIFIED) Component: tempest Last change: 2016-06-03 Summary: RDO openstack-tempest RPM should remove requirements.txt from source -- Rich Bowen - rbowen at redhat.com RDO Community Liaison http://rdoproject.org @RDOCommunity From apevec at redhat.com Mon Oct 17 20:10:02 2016 From: apevec at redhat.com (Alan Pevec) Date: Mon, 17 Oct 2016 22:10:02 +0200 Subject: [rdo-list] Failure to install Controller/Network&&Compute Cluster on RDO Newton with keystone API V3 In-Reply-To: References: Message-ID: > https://bugzilla.redhat.com/show_bug.cgi?id=1330289 > makes me to think RDO Newton is passing final CI with only one version > keystone API v2.0 . Keystone API v3 was not tested. correct, v3 is in progress https://review.openstack.org/386976 From jdmarks75080 at gmail.com Tue Oct 18 04:32:53 2016 From: jdmarks75080 at gmail.com (John Marks) Date: Mon, 17 Oct 2016 23:32:53 -0500 Subject: [rdo-list] Adding a vlan to the external network in tripleo Message-ID: I have a lab situation where there are 2 networks. One is in one DMZ and the other is a lab isolated network. I need access to both via the external port. I believe what I need to do is add another port to the bridge on a vlan to the lab network. I created a new external network in Director and assigned the vlan to it. However, I am not sure that will add it to the existing bridge. A bigger question around this is why does Openstack not support modifications after installation to the north/south network? East/west is easy but North/South has to have a lot of modifications made to static files (it seems) like plugin.ini and openvswitch.ini. Any help would be appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bderzhavets at hotmail.com Tue Oct 18 13:37:28 2016 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Tue, 18 Oct 2016 13:37:28 +0000 Subject: [rdo-list] Adding a vlan to the external network in tripleo In-Reply-To: References: Message-ID: I have a lab situation where there are 2 networks. One is in one DMZ and the other is a lab isolated network. I need access to both via the external port. I believe what I need to do is add another port to the bridge on a vlan to the lab network. I created a new external network in Director and assigned the vlan to it. However, I am not sure that will add it to the existing bridge. A bigger question around this is why does Openstack not support modifications after installation to the north/south network? Openstack has no problem with adding one more external network (or even 2) of VLAN type . See for instance https://www.linux.com/blog/rdo-mitaka-several-external-networks-vlan-provider-setup The problem here is the way which was used for deployment, it is TripleO. To have the job done you need to update heat stack "overcloud" which had been built on undercloud Node. So you should be able redeploy overcloud with specific tripleo-heat-template addressing you needs. I would expect your br-ex bridges to have IPs on ctlplane obtained via DHCP. Any manual intervention to overcloud is impossible. You have presumably only one option , which is to ask vendor for support. I am not correct stating the above, RH's technical stuff will point to my mistake for sure. That is why I am so sorry about regression taken place in packstack functionality Boris. East/west is easy but North/South has to have a lot of modifications made to static files (it seems) like plugin.ini and openvswitch.ini. ________________________________ From: rdo-list-bounces at redhat.com on behalf of John Marks Sent: Tuesday, October 18, 2016 7:32:53 AM To: rdo-list at redhat.com Subject: [rdo-list] Adding a vlan to the external network in tripleo I have a lab situation where there are 2 networks. One is in one DMZ and the other is a lab isolated network. I need access to both via the external port. I believe what I need to do is add another port to the bridge on a vlan to the lab network. I created a new external network in Director and assigned the vlan to it. However, I am not sure that will add it to the existing bridge. A bigger question around this is why does Openstack not support modifications after installation to the north/south network? East/west is easy but North/South has to have a lot of modifications made to static files (it seems) like plugin.ini and openvswitch.ini. Any help would be appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bderzhavets at hotmail.com Tue Oct 18 13:43:22 2016 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Tue, 18 Oct 2016 13:43:22 +0000 Subject: [rdo-list] Adding a vlan to the external network in tripleo In-Reply-To: References: , Message-ID: Sorry for typo If I am not correct stating the above, RH's technical stuff will point to my mistake for sure I skipped "if" on first place. ________________________________ From: rdo-list-bounces at redhat.com on behalf of Boris Derzhavets Sent: Tuesday, October 18, 2016 4:37 PM To: John Marks; rdo-list at redhat.com Subject: Re: [rdo-list] Adding a vlan to the external network in tripleo I have a lab situation where there are 2 networks. One is in one DMZ and the other is a lab isolated network. I need access to both via the external port. I believe what I need to do is add another port to the bridge on a vlan to the lab network. I created a new external network in Director and assigned the vlan to it. However, I am not sure that will add it to the existing bridge. A bigger question around this is why does Openstack not support modifications after installation to the north/south network? Openstack has no problem with adding one more external network (or even 2) of VLAN type . See for instance https://www.linux.com/blog/rdo-mitaka-several-external-networks-vlan-provider-setup The problem here is the way which was used for deployment, it is TripleO. To have the job done you need to update heat stack "overcloud" which had been built on undercloud Node. So you should be able redeploy overcloud with specific tripleo-heat-template addressing you needs. I would expect your br-ex bridges to have IPs on ctlplane obtained via DHCP. Any manual intervention to overcloud is impossible. You have presumably only one option , which is to ask vendor for support. I am not correct stating the above, RH's technical stuff will point to my mistake for sure. That is why I am so sorry about regression taken place in packstack functionality Boris. East/west is easy but North/South has to have a lot of modifications made to static files (it seems) like plugin.ini and openvswitch.ini. ________________________________ From: rdo-list-bounces at redhat.com on behalf of John Marks Sent: Tuesday, October 18, 2016 7:32:53 AM To: rdo-list at redhat.com Subject: [rdo-list] Adding a vlan to the external network in tripleo I have a lab situation where there are 2 networks. One is in one DMZ and the other is a lab isolated network. I need access to both via the external port. I believe what I need to do is add another port to the bridge on a vlan to the lab network. I created a new external network in Director and assigned the vlan to it. However, I am not sure that will add it to the existing bridge. A bigger question around this is why does Openstack not support modifications after installation to the north/south network? East/west is easy but North/South has to have a lot of modifications made to static files (it seems) like plugin.ini and openvswitch.ini. Any help would be appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdmarks75080 at gmail.com Tue Oct 18 14:21:31 2016 From: jdmarks75080 at gmail.com (John Marks) Date: Tue, 18 Oct 2016 09:21:31 -0500 Subject: [rdo-list] Adding a vlan to the external network in tripleo In-Reply-To: References: Message-ID: I looked over you scenario in your blog and it is close. I have a single external port that shares the native VLAN and VLAN27. In my case, I configrued the external bridge (br-ex) with the native vlan and am now faced with adding vlan27 to the bridge. RHOSP has a vlan scenario which I used in creating the bridge and vlans under it that carry the storage, etc. It would seem that all I need to do is create a vlan27 port as shown below. The below was generated by the heat OOO heat templates. stack: ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eno1: mtu 1500 qdisc mq state UP qlen 1000 link/ether 14:58:d0:4c:2e:98 brd ff:ff:ff:ff:ff:ff inet 192.0.2.17/24 brd 192.0.2.255 scope global eno1 valid_lft forever preferred_lft forever inet 192.0.2.15/32 brd 192.0.2.255 scope global eno1 valid_lft forever preferred_lft forever inet6 fe80::1658:d0ff:fe4c:2e98/64 scope link valid_lft forever preferred_lft forever 3: ens1f0: mtu 1500 qdisc mq state DOWN qlen 1000 link/ether 8c:dc:d4:b1:8e:b8 brd ff:ff:ff:ff:ff:ff 4: eno2: mtu 1500 qdisc mq master ovs-system state UP qlen 1000 link/ether 14:58:d0:4c:2e:9c brd ff:ff:ff:ff:ff:ff inet6 fe80::1658:d0ff:fe4c:2e9c/64 scope link valid_lft forever preferred_lft forever 5: ens1f1: mtu 1500 qdisc mq state DOWN qlen 1000 link/ether 8c:dc:d4:b1:8e:b9 brd ff:ff:ff:ff:ff:ff 6: eno3: mtu 1500 qdisc mq master ovs-system state UP qlen 1000 link/ether 14:58:d0:4c:2e:99 brd ff:ff:ff:ff:ff:ff inet6 fe80::1658:d0ff:fe4c:2e99/64 scope link valid_lft forever preferred_lft forever 7: eno4: mtu 1500 qdisc mq state DOWN qlen 1000 link/ether 14:58:d0:4c:2e:9d brd ff:ff:ff:ff:ff:ff 8: eno5: mtu 1500 qdisc mq state DOWN qlen 1000 link/ether 14:58:d0:4c:2e:9a brd ff:ff:ff:ff:ff:ff 9: eno6: mtu 1500 qdisc mq state DOWN qlen 1000 link/ether 14:58:d0:4c:2e:9e brd ff:ff:ff:ff:ff:ff 10: eno7: mtu 1500 qdisc noop master ovs-system state DOWN qlen 1000 link/ether 14:58:d0:4c:2e:9b brd ff:ff:ff:ff:ff:ff 11: eno8: mtu 1500 qdisc mq state DOWN qlen 1000 link/ether 14:58:d0:4c:2e:9f brd ff:ff:ff:ff:ff:ff 12: ovs-system: mtu 1500 qdisc noop state DOWN link/ether da:f8:b1:fd:2e:74 brd ff:ff:ff:ff:ff:ff 13: br-ex1: mtu 1500 qdisc noop state DOWN link/ether 14:58:d0:4c:2e:9b brd ff:ff:ff:ff:ff:ff 14: br-tun: mtu 1500 qdisc noop state DOWN link/ether 2a:98:45:ed:fb:4b brd ff:ff:ff:ff:ff:ff 15: vlan203: mtu 1500 qdisc noqueue state UNKNOWN link/ether 0a:5a:9c:28:45:f6 brd ff:ff:ff:ff:ff:ff inet 172.19.0.11/24 brd 172.19.0.255 scope global vlan203 valid_lft forever preferred_lft forever inet 172.19.0.10/32 brd 172.19.0.255 scope global vlan203 valid_lft forever preferred_lft forever inet6 fe80::85a:9cff:fe28:45f6/64 scope link valid_lft forever preferred_lft forever 16: vlan202: mtu 1500 qdisc noqueue state UNKNOWN link/ether 6e:3f:59:63:41:89 brd ff:ff:ff:ff:ff:ff inet 172.18.0.12/24 brd 172.18.0.255 scope global vlan202 valid_lft forever preferred_lft forever inet 172.18.0.10/32 brd 172.18.0.255 scope global vlan202 valid_lft forever preferred_lft forever inet6 fe80::6c3f:59ff:fe63:4189/64 scope link valid_lft forever preferred_lft forever 17: br-ex: mtu 1500 qdisc noqueue state UNKNOWN link/ether 14:58:d0:4c:2e:9c brd ff:ff:ff:ff:ff:ff inet 10.1.62.169/24 brd 10.1.62.255 scope global br-ex valid_lft forever preferred_lft forever inet 10.1.62.168/32 brd 10.1.62.255 scope global br-ex valid_lft forever preferred_lft forever inet6 fcff:1:62:0:1658:d0ff:fe4c:2e9c/64 scope global mngtmpaddr dynamic valid_lft 2591980sec preferred_lft 604780sec inet6 fe80::1658:d0ff:fe4c:2e9c/64 scope link valid_lft forever preferred_lft forever 18: vlan204: mtu 1500 qdisc noqueue state UNKNOWN link/ether ba:76:32:20:c8:1e brd ff:ff:ff:ff:ff:ff inet 172.17.0.11/24 brd 172.17.0.255 scope global vlan204 valid_lft forever preferred_lft forever inet6 fe80::b876:32ff:fe20:c81e/64 scope link valid_lft forever preferred_lft forever 19: vlan201: mtu 1500 qdisc noqueue state UNKNOWN link/ether 96:0b:f7:a1:89:dc brd ff:ff:ff:ff:ff:ff inet 172.16.0.13/24 brd 172.16.0.255 scope global vlan201 valid_lft forever preferred_lft forever inet 172.16.0.10/32 brd 172.16.0.255 scope global vlan201 valid_lft forever preferred_lft forever inet 172.16.0.11/32 brd 172.16.0.255 scope global vlan201 valid_lft forever preferred_lft forever inet6 fe80::940b:f7ff:fea1:89dc/64 scope link valid_lft forever preferred_lft forever 23: br-int: mtu 1500 qdisc noop state DOWN link/ether 12:ec:43:c0:1d:43 brd ff:ff:ff:ff:ff:ff stack: ovs-ctl show 75acb2b-1107-419f-9fed-1b80741aa78a Bridge br-ex Port "vlan202" tag: 202 Interface "vlan202" type: internal Port br-ex Interface br-ex type: internal Port "vlan201" tag: 201 Interface "vlan201" type: internal Port "bond1" Interface "eno2" Interface "eno3" Port phy-br-ex Interface phy-br-ex type: patch options: {peer=int-br-ex} Port "vlan204" tag: 204 Interface "vlan204" type: internal Port "vlan203" tag: 203 Interface "vlan203" type: internal Bridge br-int fail_mode: secure Port "tap485f8aa8-86" tag: 2 Interface "tap485f8aa8-86" type: internal Port patch-tun Interface patch-tun type: patch options: {peer=patch-int} Port "tap62b75cc5-ef" tag: 3 Interface "tap62b75cc5-ef" type: internal Port br-int Interface br-int type: internal Port "tap123c52e6-5d" tag: 1 Interface "tap123c52e6-5d" type: internal Port int-br-ex Interface int-br-ex type: patch options: {peer=phy-br-ex} Bridge br-tun fail_mode: secure Port br-tun Interface br-tun type: internal Port "vxlan-ac11000c" Interface "vxlan-ac11000c" type: vxlan options: {df_default="true", in_key=flow, local_ip="172.17.0.11", out_key=flow, remote_ip="172.17.0.12"} Port "vxlan-ac11000a" Interface "vxlan-ac11000a" type: vxlan options: {df_default="true", in_key=flow, local_ip="172.17.0.11", out_key=flow, remote_ip="172.17.0.10"} Port patch-int Interface patch-int type: patch options: {peer=patch-tun} Port "vxlan-ac11000d" Interface "vxlan-ac11000d" type: vxlan options: {df_default="true", in_key=flow, local_ip="172.17.0.11", out_key=flow, remote_ip="172.17.0.13"} Port "vxlan-ac11000e" Interface "vxlan-ac11000e" type: vxlan options: {df_default="true", in_key=flow, local_ip="172.17.0.11", out_key=flow, remote_ip="172.17.0.14"} On Tue, Oct 18, 2016 at 8:50 AM, John Marks wrote: > Doesn't that make the stack very inflexible? And yes, we have faced this > issue before and talked to RH about it and they said exactly the same > thing. However, if I redeploy, I have found that modifying the network > config does not take affect and I have to delete and redeploy the > overcloud. That would really reak havoc if I had to do that in production. > > Thanks for the reply. > > On Tue, Oct 18, 2016 at 8:43 AM, Boris Derzhavets > wrote: > >> Sorry for typo >> >> If I am not correct stating the above, RH's technical stuff will point >> to my mistake for sure >> >> I skipped "if" on first place. >> >> >> ------------------------------ >> *From:* rdo-list-bounces at redhat.com on >> behalf of Boris Derzhavets >> *Sent:* Tuesday, October 18, 2016 4:37 PM >> *To:* John Marks; rdo-list at redhat.com >> *Subject:* Re: [rdo-list] Adding a vlan to the external network in >> tripleo >> >> >> I have a lab situation where there are 2 networks. One is in one DMZ and >> the other is a lab isolated network. I need access to both via the external >> port. I believe what I need to do is add another port to the bridge on a >> vlan to the lab network. I created a new external network in Director and >> assigned the vlan to it. However, I am not sure that will add it to the >> existing bridge. >> >> A bigger question around this is why does Openstack not support >> modifications after installation to the north/south network? >> >> Openstack has no problem with adding one more external network (or >> even 2) of VLAN type . >> See for instance https://www.linux.com/blog/rdo >> -mitaka-several-external-networks-vlan-provider-setup >> The problem here is the way which was used for deployment, it is >> TripleO. >> To have the job done you need to update heat stack "overcloud" which >> had been built >> on undercloud Node. So you should be able redeploy overcloud with >> specific tripleo-heat-template >> addressing you needs. I would expect your br-ex bridges to have IPs >> on ctlplane obtained via DHCP. >> Any manual intervention to overcloud is impossible. You have >> presumably only one >> option , which is to ask vendor for support. >> I am not correct stating the above, RH's technical stuff will point to >> my mistake for sure. >> That is why I am so sorry about regression taken place in packstack >> functionality >> >> Boris. >> >> >> East/west is easy but North/South has to have a lot of modifications made >> to static files (it seems) like plugin.ini and openvswitch.ini. >> >> >> ------------------------------ >> *From:* rdo-list-bounces at redhat.com on >> behalf of John Marks >> *Sent:* Tuesday, October 18, 2016 7:32:53 AM >> *To:* rdo-list at redhat.com >> *Subject:* [rdo-list] Adding a vlan to the external network in tripleo >> >> I have a lab situation where there are 2 networks. One is in one DMZ and >> the other is a lab isolated network. I need access to both via the external >> port. I believe what I need to do is add another port to the bridge on a >> vlan to the lab network. I created a new external network in Director and >> assigned the vlan to it. However, I am not sure that will add it to the >> existing bridge. >> >> A bigger question around this is why does Openstack not support >> modifications after installation to the north/south network? East/west is >> easy but North/South has to have a lot of modifications made to static >> files (it seems) like plugin.ini and openvswitch.ini. >> >> Any help would be appreciated. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bderzhavets at hotmail.com Tue Oct 18 14:59:21 2016 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Tue, 18 Oct 2016 14:59:21 +0000 Subject: [rdo-list] Adding a vlan to the external network in tripleo In-Reply-To: References: , Message-ID: > It would seem that all I need to do is create a vlan27 port as shown below. The below was generated by the heat OOO heat templates. Doesn't it mean one of original templates ( which were invoked by `openstack overcloud deploy .... ` ) should be updated to create vlan27 as separate network or you have some other way to add vlan27 ? ________________________________ From: John Marks Sent: Tuesday, October 18, 2016 5:21 PM To: Boris Derzhavets; rdo-list at redhat.com Subject: Re: [rdo-list] Adding a vlan to the external network in tripleo I looked over you scenario in your blog and it is close. I have a single external port that shares the native VLAN and VLAN27. In my case, I configrued the external bridge (br-ex) with the native vlan and am now faced with adding vlan27 to the bridge. RHOSP has a vlan scenario which I used in creating the bridge and vlans under it that carry the storage, etc. It would seem that all I need to do is create a vlan27 port as shown below. The below was generated by the heat OOO heat templates. stack: ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eno1: mtu 1500 qdisc mq state UP qlen 1000 link/ether 14:58:d0:4c:2e:98 brd ff:ff:ff:ff:ff:ff inet 192.0.2.17/24 brd 192.0.2.255 scope global eno1 valid_lft forever preferred_lft forever inet 192.0.2.15/32 brd 192.0.2.255 scope global eno1 valid_lft forever preferred_lft forever inet6 fe80::1658:d0ff:fe4c:2e98/64 scope link valid_lft forever preferred_lft forever 3: ens1f0: mtu 1500 qdisc mq state DOWN qlen 1000 link/ether 8c:dc:d4:b1:8e:b8 brd ff:ff:ff:ff:ff:ff 4: eno2: mtu 1500 qdisc mq master ovs-system state UP qlen 1000 link/ether 14:58:d0:4c:2e:9c brd ff:ff:ff:ff:ff:ff inet6 fe80::1658:d0ff:fe4c:2e9c/64 scope link valid_lft forever preferred_lft forever 5: ens1f1: mtu 1500 qdisc mq state DOWN qlen 1000 link/ether 8c:dc:d4:b1:8e:b9 brd ff:ff:ff:ff:ff:ff 6: eno3: mtu 1500 qdisc mq master ovs-system state UP qlen 1000 link/ether 14:58:d0:4c:2e:99 brd ff:ff:ff:ff:ff:ff inet6 fe80::1658:d0ff:fe4c:2e99/64 scope link valid_lft forever preferred_lft forever 7: eno4: mtu 1500 qdisc mq state DOWN qlen 1000 link/ether 14:58:d0:4c:2e:9d brd ff:ff:ff:ff:ff:ff 8: eno5: mtu 1500 qdisc mq state DOWN qlen 1000 link/ether 14:58:d0:4c:2e:9a brd ff:ff:ff:ff:ff:ff 9: eno6: mtu 1500 qdisc mq state DOWN qlen 1000 link/ether 14:58:d0:4c:2e:9e brd ff:ff:ff:ff:ff:ff 10: eno7: mtu 1500 qdisc noop master ovs-system state DOWN qlen 1000 link/ether 14:58:d0:4c:2e:9b brd ff:ff:ff:ff:ff:ff 11: eno8: mtu 1500 qdisc mq state DOWN qlen 1000 link/ether 14:58:d0:4c:2e:9f brd ff:ff:ff:ff:ff:ff 12: ovs-system: mtu 1500 qdisc noop state DOWN link/ether da:f8:b1:fd:2e:74 brd ff:ff:ff:ff:ff:ff 13: br-ex1: mtu 1500 qdisc noop state DOWN link/ether 14:58:d0:4c:2e:9b brd ff:ff:ff:ff:ff:ff 14: br-tun: mtu 1500 qdisc noop state DOWN link/ether 2a:98:45:ed:fb:4b brd ff:ff:ff:ff:ff:ff 15: vlan203: mtu 1500 qdisc noqueue state UNKNOWN link/ether 0a:5a:9c:28:45:f6 brd ff:ff:ff:ff:ff:ff inet 172.19.0.11/24 brd 172.19.0.255 scope global vlan203 valid_lft forever preferred_lft forever inet 172.19.0.10/32 brd 172.19.0.255 scope global vlan203 valid_lft forever preferred_lft forever inet6 fe80::85a:9cff:fe28:45f6/64 scope link valid_lft forever preferred_lft forever 16: vlan202: mtu 1500 qdisc noqueue state UNKNOWN link/ether 6e:3f:59:63:41:89 brd ff:ff:ff:ff:ff:ff inet 172.18.0.12/24 brd 172.18.0.255 scope global vlan202 valid_lft forever preferred_lft forever inet 172.18.0.10/32 brd 172.18.0.255 scope global vlan202 valid_lft forever preferred_lft forever inet6 fe80::6c3f:59ff:fe63:4189/64 scope link valid_lft forever preferred_lft forever 17: br-ex: mtu 1500 qdisc noqueue state UNKNOWN link/ether 14:58:d0:4c:2e:9c brd ff:ff:ff:ff:ff:ff inet 10.1.62.169/24 brd 10.1.62.255 scope global br-ex valid_lft forever preferred_lft forever inet 10.1.62.168/32 brd 10.1.62.255 scope global br-ex valid_lft forever preferred_lft forever inet6 fcff:1:62:0:1658:d0ff:fe4c:2e9c/64 scope global mngtmpaddr dynamic valid_lft 2591980sec preferred_lft 604780sec inet6 fe80::1658:d0ff:fe4c:2e9c/64 scope link valid_lft forever preferred_lft forever 18: vlan204: mtu 1500 qdisc noqueue state UNKNOWN link/ether ba:76:32:20:c8:1e brd ff:ff:ff:ff:ff:ff inet 172.17.0.11/24 brd 172.17.0.255 scope global vlan204 valid_lft forever preferred_lft forever inet6 fe80::b876:32ff:fe20:c81e/64 scope link valid_lft forever preferred_lft forever 19: vlan201: mtu 1500 qdisc noqueue state UNKNOWN link/ether 96:0b:f7:a1:89:dc brd ff:ff:ff:ff:ff:ff inet 172.16.0.13/24 brd 172.16.0.255 scope global vlan201 valid_lft forever preferred_lft forever inet 172.16.0.10/32 brd 172.16.0.255 scope global vlan201 valid_lft forever preferred_lft forever inet 172.16.0.11/32 brd 172.16.0.255 scope global vlan201 valid_lft forever preferred_lft forever inet6 fe80::940b:f7ff:fea1:89dc/64 scope link valid_lft forever preferred_lft forever 23: br-int: mtu 1500 qdisc noop state DOWN link/ether 12:ec:43:c0:1d:43 brd ff:ff:ff:ff:ff:ff stack: ovs-ctl show 75acb2b-1107-419f-9fed-1b80741aa78a Bridge br-ex Port "vlan202" tag: 202 Interface "vlan202" type: internal Port br-ex Interface br-ex type: internal Port "vlan201" tag: 201 Interface "vlan201" type: internal Port "bond1" Interface "eno2" Interface "eno3" Port phy-br-ex Interface phy-br-ex type: patch options: {peer=int-br-ex} Port "vlan204" tag: 204 Interface "vlan204" type: internal Port "vlan203" tag: 203 Interface "vlan203" type: internal Bridge br-int fail_mode: secure Port "tap485f8aa8-86" tag: 2 Interface "tap485f8aa8-86" type: internal Port patch-tun Interface patch-tun type: patch options: {peer=patch-int} Port "tap62b75cc5-ef" tag: 3 Interface "tap62b75cc5-ef" type: internal Port br-int Interface br-int type: internal Port "tap123c52e6-5d" tag: 1 Interface "tap123c52e6-5d" type: internal Port int-br-ex Interface int-br-ex type: patch options: {peer=phy-br-ex} Bridge br-tun fail_mode: secure Port br-tun Interface br-tun type: internal Port "vxlan-ac11000c" Interface "vxlan-ac11000c" type: vxlan options: {df_default="true", in_key=flow, local_ip="172.17.0.11", out_key=flow, remote_ip="172.17.0.12"} Port "vxlan-ac11000a" Interface "vxlan-ac11000a" type: vxlan options: {df_default="true", in_key=flow, local_ip="172.17.0.11", out_key=flow, remote_ip="172.17.0.10"} Port patch-int Interface patch-int type: patch options: {peer=patch-tun} Port "vxlan-ac11000d" Interface "vxlan-ac11000d" type: vxlan options: {df_default="true", in_key=flow, local_ip="172.17.0.11", out_key=flow, remote_ip="172.17.0.13"} Port "vxlan-ac11000e" Interface "vxlan-ac11000e" type: vxlan options: {df_default="true", in_key=flow, local_ip="172.17.0.11", out_key=flow, remote_ip="172.17.0.14"} On Tue, Oct 18, 2016 at 8:50 AM, John Marks > wrote: Doesn't that make the stack very inflexible? And yes, we have faced this issue before and talked to RH about it and they said exactly the same thing. However, if I redeploy, I have found that modifying the network config does not take affect and I have to delete and redeploy the overcloud. That would really reak havoc if I had to do that in production. Thanks for the reply. On Tue, Oct 18, 2016 at 8:43 AM, Boris Derzhavets > wrote: Sorry for typo If I am not correct stating the above, RH's technical stuff will point to my mistake for sure I skipped "if" on first place. ________________________________ From: rdo-list-bounces at redhat.com > on behalf of Boris Derzhavets > Sent: Tuesday, October 18, 2016 4:37 PM To: John Marks; rdo-list at redhat.com Subject: Re: [rdo-list] Adding a vlan to the external network in tripleo I have a lab situation where there are 2 networks. One is in one DMZ and the other is a lab isolated network. I need access to both via the external port. I believe what I need to do is add another port to the bridge on a vlan to the lab network. I created a new external network in Director and assigned the vlan to it. However, I am not sure that will add it to the existing bridge. A bigger question around this is why does Openstack not support modifications after installation to the north/south network? Openstack has no problem with adding one more external network (or even 2) of VLAN type . See for instance https://www.linux.com/blog/rdo-mitaka-several-external-networks-vlan-provider-setup The problem here is the way which was used for deployment, it is TripleO. To have the job done you need to update heat stack "overcloud" which had been built on undercloud Node. So you should be able redeploy overcloud with specific tripleo-heat-template addressing you needs. I would expect your br-ex bridges to have IPs on ctlplane obtained via DHCP. Any manual intervention to overcloud is impossible. You have presumably only one option , which is to ask vendor for support. I am not correct stating the above, RH's technical stuff will point to my mistake for sure. That is why I am so sorry about regression taken place in packstack functionality Boris. East/west is easy but North/South has to have a lot of modifications made to static files (it seems) like plugin.ini and openvswitch.ini. ________________________________ From: rdo-list-bounces at redhat.com > on behalf of John Marks > Sent: Tuesday, October 18, 2016 7:32:53 AM To: rdo-list at redhat.com Subject: [rdo-list] Adding a vlan to the external network in tripleo I have a lab situation where there are 2 networks. One is in one DMZ and the other is a lab isolated network. I need access to both via the external port. I believe what I need to do is add another port to the bridge on a vlan to the lab network. I created a new external network in Director and assigned the vlan to it. However, I am not sure that will add it to the existing bridge. A bigger question around this is why does Openstack not support modifications after installation to the north/south network? East/west is easy but North/South has to have a lot of modifications made to static files (it seems) like plugin.ini and openvswitch.ini. Any help would be appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brandon.james at sunayu.com Tue Oct 18 15:08:02 2016 From: brandon.james at sunayu.com (Brandon James) Date: Tue, 18 Oct 2016 11:08:02 -0400 Subject: [rdo-list] Adding a vlan to the external network in tripleo In-Reply-To: References: Message-ID: All, I truly feel that we should somehow improve the documentation to explain how to do this in detail(Vlans and external networks). I suspect that many people who want to tryout Tripleo/RDO Packstack are really struggling with the networking. I know for myself this alone is the main reason I have not deployed this into production because our external network is very complex and I need to be certain I can integrate this without serious pain. It would be great if users could easily change these settings on the fly because for most admins, networking is never static. Just my 2 cents. Brandon On Tue, Oct 18, 2016 at 10:59 AM, Boris Derzhavets wrote: > > It would seem that all I need to do is create a vlan27 port as shown > below. The below was generated by the heat OOO heat templates. > > > Doesn't it mean one of original templates ( which were invoked by > `openstack overcloud deploy .... ` ) > should be updated to create vlan27 as separate network or you have some > other way to add vlan27 ? > > > > > > ------------------------------ > *From:* John Marks > *Sent:* Tuesday, October 18, 2016 5:21 PM > *To:* Boris Derzhavets; rdo-list at redhat.com > > *Subject:* Re: [rdo-list] Adding a vlan to the external network in tripleo > > I looked over you scenario in your blog and it is close. I have a single > external port that shares the native VLAN and VLAN27. In my case, I > configrued the external bridge (br-ex) with the native vlan and am now > faced with adding vlan27 to the bridge. RHOSP has a vlan scenario which I > used in creating the bridge and vlans under it that carry the storage, etc. > It would seem that all I need to do is create a vlan27 port as shown below. > The below was generated by the heat OOO heat templates. > > stack: ip a > 1: lo: mtu 65536 qdisc noqueue state UNKNOWN > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo > valid_lft forever preferred_lft forever > inet6 ::1/128 scope host > valid_lft forever preferred_lft forever > 2: eno1: mtu 1500 qdisc mq state UP > qlen 1000 > link/ether 14:58:d0:4c:2e:98 brd ff:ff:ff:ff:ff:ff > inet 192.0.2.17/24 brd 192.0.2.255 scope global eno1 > valid_lft forever preferred_lft forever > inet 192.0.2.15/32 brd 192.0.2.255 scope global eno1 > valid_lft forever preferred_lft forever > inet6 fe80::1658:d0ff:fe4c:2e98/64 scope link > valid_lft forever preferred_lft forever > 3: ens1f0: mtu 1500 qdisc mq state > DOWN qlen 1000 > link/ether 8c:dc:d4:b1:8e:b8 brd ff:ff:ff:ff:ff:ff > 4: eno2: mtu 1500 qdisc mq master > ovs-system state UP qlen 1000 > link/ether 14:58:d0:4c:2e:9c brd ff:ff:ff:ff:ff:ff > inet6 fe80::1658:d0ff:fe4c:2e9c/64 scope link > valid_lft forever preferred_lft forever > 5: ens1f1: mtu 1500 qdisc mq state > DOWN qlen 1000 > link/ether 8c:dc:d4:b1:8e:b9 brd ff:ff:ff:ff:ff:ff > 6: eno3: mtu 1500 qdisc mq master > ovs-system state UP qlen 1000 > link/ether 14:58:d0:4c:2e:99 brd ff:ff:ff:ff:ff:ff > inet6 fe80::1658:d0ff:fe4c:2e99/64 scope link > valid_lft forever preferred_lft forever > 7: eno4: mtu 1500 qdisc mq state DOWN > qlen 1000 > link/ether 14:58:d0:4c:2e:9d brd ff:ff:ff:ff:ff:ff > 8: eno5: mtu 1500 qdisc mq state DOWN > qlen 1000 > link/ether 14:58:d0:4c:2e:9a brd ff:ff:ff:ff:ff:ff > 9: eno6: mtu 1500 qdisc mq state DOWN > qlen 1000 > link/ether 14:58:d0:4c:2e:9e brd ff:ff:ff:ff:ff:ff > 10: eno7: mtu 1500 qdisc noop master ovs-system > state DOWN qlen 1000 > link/ether 14:58:d0:4c:2e:9b brd ff:ff:ff:ff:ff:ff > 11: eno8: mtu 1500 qdisc mq state > DOWN qlen 1000 > link/ether 14:58:d0:4c:2e:9f brd ff:ff:ff:ff:ff:ff > 12: ovs-system: mtu 1500 qdisc noop state DOWN > link/ether da:f8:b1:fd:2e:74 brd ff:ff:ff:ff:ff:ff > 13: br-ex1: mtu 1500 qdisc noop state DOWN > link/ether 14:58:d0:4c:2e:9b brd ff:ff:ff:ff:ff:ff > 14: br-tun: mtu 1500 qdisc noop state DOWN > link/ether 2a:98:45:ed:fb:4b brd ff:ff:ff:ff:ff:ff > 15: vlan203: mtu 1500 qdisc noqueue > state UNKNOWN > link/ether 0a:5a:9c:28:45:f6 brd ff:ff:ff:ff:ff:ff > inet 172.19.0.11/24 brd 172.19.0.255 scope global vlan203 > valid_lft forever preferred_lft forever > inet 172.19.0.10/32 brd 172.19.0.255 scope global vlan203 > valid_lft forever preferred_lft forever > inet6 fe80::85a:9cff:fe28:45f6/64 scope link > valid_lft forever preferred_lft forever > 16: vlan202: mtu 1500 qdisc noqueue > state UNKNOWN > link/ether 6e:3f:59:63:41:89 brd ff:ff:ff:ff:ff:ff > inet 172.18.0.12/24 brd 172.18.0.255 scope global vlan202 > valid_lft forever preferred_lft forever > inet 172.18.0.10/32 brd 172.18.0.255 scope global vlan202 > valid_lft forever preferred_lft forever > inet6 fe80::6c3f:59ff:fe63:4189/64 scope link > valid_lft forever preferred_lft forever > 17: br-ex: mtu 1500 qdisc noqueue state > UNKNOWN > link/ether 14:58:d0:4c:2e:9c brd ff:ff:ff:ff:ff:ff > inet 10.1.62.169/24 brd 10.1.62.255 scope global br-ex > valid_lft forever preferred_lft forever > inet 10.1.62.168/32 brd 10.1.62.255 scope global br-ex > valid_lft forever preferred_lft forever > inet6 fcff:1:62:0:1658:d0ff:fe4c:2e9c/64 scope global mngtmpaddr > dynamic > valid_lft 2591980sec preferred_lft 604780sec > inet6 fe80::1658:d0ff:fe4c:2e9c/64 scope link > valid_lft forever preferred_lft forever > 18: vlan204: mtu 1500 qdisc noqueue > state UNKNOWN > link/ether ba:76:32:20:c8:1e brd ff:ff:ff:ff:ff:ff > inet 172.17.0.11/24 brd 172.17.0.255 scope global vlan204 > valid_lft forever preferred_lft forever > inet6 fe80::b876:32ff:fe20:c81e/64 scope link > valid_lft forever preferred_lft forever > 19: vlan201: mtu 1500 qdisc noqueue > state UNKNOWN > link/ether 96:0b:f7:a1:89:dc brd ff:ff:ff:ff:ff:ff > inet 172.16.0.13/24 brd 172.16.0.255 scope global vlan201 > valid_lft forever preferred_lft forever > inet 172.16.0.10/32 brd 172.16.0.255 scope global vlan201 > valid_lft forever preferred_lft forever > inet 172.16.0.11/32 brd 172.16.0.255 scope global vlan201 > valid_lft forever preferred_lft forever > inet6 fe80::940b:f7ff:fea1:89dc/64 scope link > valid_lft forever preferred_lft forever > 23: br-int: mtu 1500 qdisc noop state DOWN > link/ether 12:ec:43:c0:1d:43 brd ff:ff:ff:ff:ff:ff > > stack: ovs-ctl show > 75acb2b-1107-419f-9fed-1b80741aa78a > Bridge br-ex > Port "vlan202" > tag: 202 > Interface "vlan202" > type: internal > Port br-ex > Interface br-ex > type: internal > Port "vlan201" > tag: 201 > Interface "vlan201" > type: internal > Port "bond1" > Interface "eno2" > Interface "eno3" > Port phy-br-ex > Interface phy-br-ex > type: patch > options: {peer=int-br-ex} > Port "vlan204" > tag: 204 > Interface "vlan204" > type: internal > Port "vlan203" > tag: 203 > Interface "vlan203" > type: internal > Bridge br-int > fail_mode: secure > Port "tap485f8aa8-86" > tag: 2 > Interface "tap485f8aa8-86" > type: internal > Port patch-tun > Interface patch-tun > type: patch > options: {peer=patch-int} > Port "tap62b75cc5-ef" > tag: 3 > Interface "tap62b75cc5-ef" > type: internal > Port br-int > Interface br-int > type: internal > Port "tap123c52e6-5d" > tag: 1 > Interface "tap123c52e6-5d" > type: internal > Port int-br-ex > Interface int-br-ex > type: patch > options: {peer=phy-br-ex} > Bridge br-tun > fail_mode: secure > Port br-tun > Interface br-tun > type: internal > Port "vxlan-ac11000c" > Interface "vxlan-ac11000c" > type: vxlan > options: {df_default="true", in_key=flow, > local_ip="172.17.0.11", out_key=flow, remote_ip="172.17.0.12"} > Port "vxlan-ac11000a" > Interface "vxlan-ac11000a" > type: vxlan > options: {df_default="true", in_key=flow, > local_ip="172.17.0.11", out_key=flow, remote_ip="172.17.0.10"} > Port patch-int > Interface patch-int > type: patch > options: {peer=patch-tun} > Port "vxlan-ac11000d" > Interface "vxlan-ac11000d" > type: vxlan > options: {df_default="true", in_key=flow, > local_ip="172.17.0.11", out_key=flow, remote_ip="172.17.0.13"} > Port "vxlan-ac11000e" > Interface "vxlan-ac11000e" > type: vxlan > options: {df_default="true", in_key=flow, > local_ip="172.17.0.11", out_key=flow, remote_ip="172.17.0.14"} > > > > On Tue, Oct 18, 2016 at 8:50 AM, John Marks > wrote: > >> Doesn't that make the stack very inflexible? And yes, we have faced this >> issue before and talked to RH about it and they said exactly the same >> thing. However, if I redeploy, I have found that modifying the network >> config does not take affect and I have to delete and redeploy the >> overcloud. That would really reak havoc if I had to do that in production. >> >> Thanks for the reply. >> >> On Tue, Oct 18, 2016 at 8:43 AM, Boris Derzhavets < >> bderzhavets at hotmail.com> wrote: >> >>> Sorry for typo >>> >>> If I am not correct stating the above, RH's technical stuff will >>> point to my mistake for sure >>> >>> I skipped "if" on first place. >>> >>> >>> ------------------------------ >>> *From:* rdo-list-bounces at redhat.com on >>> behalf of Boris Derzhavets >>> *Sent:* Tuesday, October 18, 2016 4:37 PM >>> *To:* John Marks; rdo-list at redhat.com >>> *Subject:* Re: [rdo-list] Adding a vlan to the external network in >>> tripleo >>> >>> >>> I have a lab situation where there are 2 networks. One is in one DMZ and >>> the other is a lab isolated network. I need access to both via the external >>> port. I believe what I need to do is add another port to the bridge on a >>> vlan to the lab network. I created a new external network in Director and >>> assigned the vlan to it. However, I am not sure that will add it to the >>> existing bridge. >>> >>> A bigger question around this is why does Openstack not support >>> modifications after installation to the north/south network? >>> >>> Openstack has no problem with adding one more external network (or >>> even 2) of VLAN type . >>> See for instance https://www.linux.com/blog/rdo >>> -mitaka-several-external-networks-vlan-provider-setup >>> The problem here is the way which was used for deployment, it is >>> TripleO. >>> To have the job done you need to update heat stack "overcloud" which >>> had been built >>> on undercloud Node. So you should be able redeploy overcloud with >>> specific tripleo-heat-template >>> addressing you needs. I would expect your br-ex bridges to have IPs >>> on ctlplane obtained via DHCP. >>> Any manual intervention to overcloud is impossible. You have >>> presumably only one >>> option , which is to ask vendor for support. >>> I am not correct stating the above, RH's technical stuff will point >>> to my mistake for sure. >>> That is why I am so sorry about regression taken place in packstack >>> functionality >>> >>> Boris. >>> >>> >>> East/west is easy but North/South has to have a lot of modifications >>> made to static files (it seems) like plugin.ini and openvswitch.ini. >>> >>> >>> ------------------------------ >>> *From:* rdo-list-bounces at redhat.com on >>> behalf of John Marks >>> *Sent:* Tuesday, October 18, 2016 7:32:53 AM >>> *To:* rdo-list at redhat.com >>> *Subject:* [rdo-list] Adding a vlan to the external network in tripleo >>> >>> I have a lab situation where there are 2 networks. One is in one DMZ and >>> the other is a lab isolated network. I need access to both via the external >>> port. I believe what I need to do is add another port to the bridge on a >>> vlan to the lab network. I created a new external network in Director and >>> assigned the vlan to it. However, I am not sure that will add it to the >>> existing bridge. >>> >>> A bigger question around this is why does Openstack not support >>> modifications after installation to the north/south network? East/west is >>> easy but North/South has to have a lot of modifications made to static >>> files (it seems) like plugin.ini and openvswitch.ini. >>> >>> Any help would be appreciated. >>> >> >> > > _______________________________________________ > 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 > -- Brandon James CEO & Founding Member Mobile: 240.476-3922 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbowen at redhat.com Tue Oct 18 15:15:26 2016 From: rbowen at redhat.com (Rich Bowen) Date: Tue, 18 Oct 2016 11:15:26 -0400 Subject: [rdo-list] How are you using RDO? (Survey) Message-ID: <9628798b-c560-5962-c73e-6a81b878750d@redhat.com> In the continuing effort to make sure that RDO is filling the needs of the people that are using it, I have a few questions for the RDO operators out there. I know that we all receive a lot of surveys, but I hope that you'll consider taking 5-10 minutes of your day to offer a little insight into how you're using RDO, what you'd like to see done differently, and how you'd like to help out with that process. https://goo.gl/forms/ZolZdgrfREHUs3Vt1 If you'd like to talk more in person, drop by our booth at OpenStack Summit next week, or come talk to us in the #rdo IRC channel on the Freenode network. Thanks! -- Rich Bowen - rbowen at redhat.com RDO Community Liaison http://rdoproject.org @RDOCommunity From bderzhavets at hotmail.com Tue Oct 18 15:26:15 2016 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Tue, 18 Oct 2016 15:26:15 +0000 Subject: [rdo-list] Adding a vlan to the external network in tripleo In-Reply-To: References: , Message-ID: @John Marks Looking at http://docs.openstack.org/developer/tripleo-docs/advanced_deployment/network_isolation.html I see template :- parameter_defaults: # Customize all these values to match the local environment InternalApiNetCidr: 172.17.0.0/24 StorageNetCidr: 172.18.0.0/24 StorageMgmtNetCidr: 172.19.0.0/24 TenantNetCidr: 172.16.0.0/24 ExternalNetCidr: 10.1.2.0/24 # CIDR subnet mask length for provisioning network ControlPlaneSubnetCidr: '24' InternalApiAllocationPools: [{'start': '172.17.0.10', 'end': '172.17.0.200'}] StorageAllocationPools: [{'start': '172.18.0.10', 'end': '172.18.0.200'}] StorageMgmtAllocationPools: [{'start': '172.19.0.10', 'end': '172.19.0.200'}] TenantAllocationPools: [{'start': '172.16.0.10', 'end': '172.16.0.200'}] # Use an External allocation pool which will leave room for floating IPs ExternalAllocationPools: [{'start': '10.1.2.10', 'end': '10.1.2.50'}] # Set to the router gateway on the external network ExternalInterfaceDefaultRoute: 10.1.2.1 # Gateway router for the provisioning network (or Undercloud IP) ControlPlaneDefaultRoute: 192.0.2.254 # Generally the IP of the Undercloud EC2MetadataIp: 192.0.2.1 # Define the DNS servers (maximum 2) for the overcloud nodes DnsServers: ["8.8.8.8","8.8.4.4"] InternalApiNetworkVlanID: 201 StorageNetworkVlanID: 202 StorageMgmtNetworkVlanID: 203 TenantNetworkVlanID: 204 ExternalNetworkVlanID: 100 # May set to br-ex if using floating IPs only on native VLAN on bridge br-ex NeutronExternalNetworkBridge: "''" # Customize bonding options if required (ignored if bonds are not used) BondInterfaceOvsOptions: "lacp=active other-config:lacp-fallback-ab=true" which apparently you have been using. I believe to add vlan27 - similar entries have to be added to each section above for vlan27 the last one :- MyNetworkVlanID 27 ________________________________ From: Brandon James Sent: Tuesday, October 18, 2016 6:08 PM To: Boris Derzhavets Cc: John Marks; rdo-list at redhat.com Subject: Re: [rdo-list] Adding a vlan to the external network in tripleo All, I truly feel that we should somehow improve the documentation to explain how to do this in detail(Vlans and external networks). I suspect that many people who want to tryout Tripleo/RDO Packstack are really struggling with the networking. I know for myself this alone is the main reason I have not deployed this into production because our external network is very complex and I need to be certain I can integrate this without serious pain. It would be great if users could easily change these settings on the fly because for most admins, networking is never static. Just my 2 cents. Brandon On Tue, Oct 18, 2016 at 10:59 AM, Boris Derzhavets > wrote: > It would seem that all I need to do is create a vlan27 port as shown below. The below was generated by the heat OOO heat templates. Doesn't it mean one of original templates ( which were invoked by `openstack overcloud deploy .... ` ) should be updated to create vlan27 as separate network or you have some other way to add vlan27 ? ________________________________ From: John Marks > Sent: Tuesday, October 18, 2016 5:21 PM To: Boris Derzhavets; rdo-list at redhat.com Subject: Re: [rdo-list] Adding a vlan to the external network in tripleo I looked over you scenario in your blog and it is close. I have a single external port that shares the native VLAN and VLAN27. In my case, I configrued the external bridge (br-ex) with the native vlan and am now faced with adding vlan27 to the bridge. RHOSP has a vlan scenario which I used in creating the bridge and vlans under it that carry the storage, etc. It would seem that all I need to do is create a vlan27 port as shown below. The below was generated by the heat OOO heat templates. stack: ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eno1: mtu 1500 qdisc mq state UP qlen 1000 link/ether 14:58:d0:4c:2e:98 brd ff:ff:ff:ff:ff:ff inet 192.0.2.17/24 brd 192.0.2.255 scope global eno1 valid_lft forever preferred_lft forever inet 192.0.2.15/32 brd 192.0.2.255 scope global eno1 valid_lft forever preferred_lft forever inet6 fe80::1658:d0ff:fe4c:2e98/64 scope link valid_lft forever preferred_lft forever 3: ens1f0: mtu 1500 qdisc mq state DOWN qlen 1000 link/ether 8c:dc:d4:b1:8e:b8 brd ff:ff:ff:ff:ff:ff 4: eno2: mtu 1500 qdisc mq master ovs-system state UP qlen 1000 link/ether 14:58:d0:4c:2e:9c brd ff:ff:ff:ff:ff:ff inet6 fe80::1658:d0ff:fe4c:2e9c/64 scope link valid_lft forever preferred_lft forever 5: ens1f1: mtu 1500 qdisc mq state DOWN qlen 1000 link/ether 8c:dc:d4:b1:8e:b9 brd ff:ff:ff:ff:ff:ff 6: eno3: mtu 1500 qdisc mq master ovs-system state UP qlen 1000 link/ether 14:58:d0:4c:2e:99 brd ff:ff:ff:ff:ff:ff inet6 fe80::1658:d0ff:fe4c:2e99/64 scope link valid_lft forever preferred_lft forever 7: eno4: mtu 1500 qdisc mq state DOWN qlen 1000 link/ether 14:58:d0:4c:2e:9d brd ff:ff:ff:ff:ff:ff 8: eno5: mtu 1500 qdisc mq state DOWN qlen 1000 link/ether 14:58:d0:4c:2e:9a brd ff:ff:ff:ff:ff:ff 9: eno6: mtu 1500 qdisc mq state DOWN qlen 1000 link/ether 14:58:d0:4c:2e:9e brd ff:ff:ff:ff:ff:ff 10: eno7: mtu 1500 qdisc noop master ovs-system state DOWN qlen 1000 link/ether 14:58:d0:4c:2e:9b brd ff:ff:ff:ff:ff:ff 11: eno8: mtu 1500 qdisc mq state DOWN qlen 1000 link/ether 14:58:d0:4c:2e:9f brd ff:ff:ff:ff:ff:ff 12: ovs-system: mtu 1500 qdisc noop state DOWN link/ether da:f8:b1:fd:2e:74 brd ff:ff:ff:ff:ff:ff 13: br-ex1: mtu 1500 qdisc noop state DOWN link/ether 14:58:d0:4c:2e:9b brd ff:ff:ff:ff:ff:ff 14: br-tun: mtu 1500 qdisc noop state DOWN link/ether 2a:98:45:ed:fb:4b brd ff:ff:ff:ff:ff:ff 15: vlan203: mtu 1500 qdisc noqueue state UNKNOWN link/ether 0a:5a:9c:28:45:f6 brd ff:ff:ff:ff:ff:ff inet 172.19.0.11/24 brd 172.19.0.255 scope global vlan203 valid_lft forever preferred_lft forever inet 172.19.0.10/32 brd 172.19.0.255 scope global vlan203 valid_lft forever preferred_lft forever inet6 fe80::85a:9cff:fe28:45f6/64 scope link valid_lft forever preferred_lft forever 16: vlan202: mtu 1500 qdisc noqueue state UNKNOWN link/ether 6e:3f:59:63:41:89 brd ff:ff:ff:ff:ff:ff inet 172.18.0.12/24 brd 172.18.0.255 scope global vlan202 valid_lft forever preferred_lft forever inet 172.18.0.10/32 brd 172.18.0.255 scope global vlan202 valid_lft forever preferred_lft forever inet6 fe80::6c3f:59ff:fe63:4189/64 scope link valid_lft forever preferred_lft forever 17: br-ex: mtu 1500 qdisc noqueue state UNKNOWN link/ether 14:58:d0:4c:2e:9c brd ff:ff:ff:ff:ff:ff inet 10.1.62.169/24 brd 10.1.62.255 scope global br-ex valid_lft forever preferred_lft forever inet 10.1.62.168/32 brd 10.1.62.255 scope global br-ex valid_lft forever preferred_lft forever inet6 fcff:1:62:0:1658:d0ff:fe4c:2e9c/64 scope global mngtmpaddr dynamic valid_lft 2591980sec preferred_lft 604780sec inet6 fe80::1658:d0ff:fe4c:2e9c/64 scope link valid_lft forever preferred_lft forever 18: vlan204: mtu 1500 qdisc noqueue state UNKNOWN link/ether ba:76:32:20:c8:1e brd ff:ff:ff:ff:ff:ff inet 172.17.0.11/24 brd 172.17.0.255 scope global vlan204 valid_lft forever preferred_lft forever inet6 fe80::b876:32ff:fe20:c81e/64 scope link valid_lft forever preferred_lft forever 19: vlan201: mtu 1500 qdisc noqueue state UNKNOWN link/ether 96:0b:f7:a1:89:dc brd ff:ff:ff:ff:ff:ff inet 172.16.0.13/24 brd 172.16.0.255 scope global vlan201 valid_lft forever preferred_lft forever inet 172.16.0.10/32 brd 172.16.0.255 scope global vlan201 valid_lft forever preferred_lft forever inet 172.16.0.11/32 brd 172.16.0.255 scope global vlan201 valid_lft forever preferred_lft forever inet6 fe80::940b:f7ff:fea1:89dc/64 scope link valid_lft forever preferred_lft forever 23: br-int: mtu 1500 qdisc noop state DOWN link/ether 12:ec:43:c0:1d:43 brd ff:ff:ff:ff:ff:ff stack: ovs-ctl show 75acb2b-1107-419f-9fed-1b80741aa78a Bridge br-ex Port "vlan202" tag: 202 Interface "vlan202" type: internal Port br-ex Interface br-ex type: internal Port "vlan201" tag: 201 Interface "vlan201" type: internal Port "bond1" Interface "eno2" Interface "eno3" Port phy-br-ex Interface phy-br-ex type: patch options: {peer=int-br-ex} Port "vlan204" tag: 204 Interface "vlan204" type: internal Port "vlan203" tag: 203 Interface "vlan203" type: internal Bridge br-int fail_mode: secure Port "tap485f8aa8-86" tag: 2 Interface "tap485f8aa8-86" type: internal Port patch-tun Interface patch-tun type: patch options: {peer=patch-int} Port "tap62b75cc5-ef" tag: 3 Interface "tap62b75cc5-ef" type: internal Port br-int Interface br-int type: internal Port "tap123c52e6-5d" tag: 1 Interface "tap123c52e6-5d" type: internal Port int-br-ex Interface int-br-ex type: patch options: {peer=phy-br-ex} Bridge br-tun fail_mode: secure Port br-tun Interface br-tun type: internal Port "vxlan-ac11000c" Interface "vxlan-ac11000c" type: vxlan options: {df_default="true", in_key=flow, local_ip="172.17.0.11", out_key=flow, remote_ip="172.17.0.12"} Port "vxlan-ac11000a" Interface "vxlan-ac11000a" type: vxlan options: {df_default="true", in_key=flow, local_ip="172.17.0.11", out_key=flow, remote_ip="172.17.0.10"} Port patch-int Interface patch-int type: patch options: {peer=patch-tun} Port "vxlan-ac11000d" Interface "vxlan-ac11000d" type: vxlan options: {df_default="true", in_key=flow, local_ip="172.17.0.11", out_key=flow, remote_ip="172.17.0.13"} Port "vxlan-ac11000e" Interface "vxlan-ac11000e" type: vxlan options: {df_default="true", in_key=flow, local_ip="172.17.0.11", out_key=flow, remote_ip="172.17.0.14"} On Tue, Oct 18, 2016 at 8:50 AM, John Marks > wrote: Doesn't that make the stack very inflexible? And yes, we have faced this issue before and talked to RH about it and they said exactly the same thing. However, if I redeploy, I have found that modifying the network config does not take affect and I have to delete and redeploy the overcloud. That would really reak havoc if I had to do that in production. Thanks for the reply. On Tue, Oct 18, 2016 at 8:43 AM, Boris Derzhavets > wrote: Sorry for typo If I am not correct stating the above, RH's technical stuff will point to my mistake for sure I skipped "if" on first place. ________________________________ From: rdo-list-bounces at redhat.com > on behalf of Boris Derzhavets > Sent: Tuesday, October 18, 2016 4:37 PM To: John Marks; rdo-list at redhat.com Subject: Re: [rdo-list] Adding a vlan to the external network in tripleo I have a lab situation where there are 2 networks. One is in one DMZ and the other is a lab isolated network. I need access to both via the external port. I believe what I need to do is add another port to the bridge on a vlan to the lab network. I created a new external network in Director and assigned the vlan to it. However, I am not sure that will add it to the existing bridge. A bigger question around this is why does Openstack not support modifications after installation to the north/south network? Openstack has no problem with adding one more external network (or even 2) of VLAN type . See for instance https://www.linux.com/blog/rdo-mitaka-several-external-networks-vlan-provider-setup The problem here is the way which was used for deployment, it is TripleO. To have the job done you need to update heat stack "overcloud" which had been built on undercloud Node. So you should be able redeploy overcloud with specific tripleo-heat-template addressing you needs. I would expect your br-ex bridges to have IPs on ctlplane obtained via DHCP. Any manual intervention to overcloud is impossible. You have presumably only one option , which is to ask vendor for support. I am not correct stating the above, RH's technical stuff will point to my mistake for sure. That is why I am so sorry about regression taken place in packstack functionality Boris. East/west is easy but North/South has to have a lot of modifications made to static files (it seems) like plugin.ini and openvswitch.ini. ________________________________ From: rdo-list-bounces at redhat.com > on behalf of John Marks > Sent: Tuesday, October 18, 2016 7:32:53 AM To: rdo-list at redhat.com Subject: [rdo-list] Adding a vlan to the external network in tripleo I have a lab situation where there are 2 networks. One is in one DMZ and the other is a lab isolated network. I need access to both via the external port. I believe what I need to do is add another port to the bridge on a vlan to the lab network. I created a new external network in Director and assigned the vlan to it. However, I am not sure that will add it to the existing bridge. A bigger question around this is why does Openstack not support modifications after installation to the north/south network? East/west is easy but North/South has to have a lot of modifications made to static files (it seems) like plugin.ini and openvswitch.ini. Any help would be appreciated. _______________________________________________ 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 -- [https://0cac57e6-a-62cb3a1a-s-sites.googlegroups.com/site/brandonajames/hot/SUNAYU_LOGO_SIDE%28NO%20TAGLINE%29.jpg?attachauth=ANoY7craA8YrLTT8x3WhaypAtiXvQ0K-_OS2jZLqGIxlVfggNoilgZ0EphWMvnkHuk2FGCoOAjLIdLUOfDaai4Hb33i4FsnL9TXCfSS4WDRCVQVeKFk3qZU226q_8ZQhEYrPX9OR_Bx3eeOB42Qb9fr6qDvqzgSLcbGWpvI_vaAU8ldioT8VmZIwTFZJ84g6PcdXTG-aKTBGCN0xDfScEkqhERAh8lqvHsOua9a6jYjhY49IRhsfGj-_2V5FUz_p4oBpI1B3qjvK&attredirects=0] Brandon James CEO & Founding Member Mobile: 240.476-3922 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bderzhavets at hotmail.com Tue Oct 18 15:53:28 2016 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Tue, 18 Oct 2016 15:53:28 +0000 Subject: [rdo-list] Adding a vlan to the external network in tripleo In-Reply-To: References: , , Message-ID: Next , I would attempt redeploing ( without `openstack stack delete overcloud` ) to initiate stack update, rather then recreating For the first time I would make testing in VENV (QuickStart or instack-virt-setup ) Just 4 nodes small deployment to make sure stack is supposed to be successfully updated. ________________________________ From: rdo-list-bounces at redhat.com on behalf of Boris Derzhavets Sent: Tuesday, October 18, 2016 6:26 PM To: Brandon James Cc: rdo-list at redhat.com Subject: Re: [rdo-list] Adding a vlan to the external network in tripleo @John Marks Looking at http://docs.openstack.org/developer/tripleo-docs/advanced_deployment/network_isolation.html I see template :- parameter_defaults: # Customize all these values to match the local environment InternalApiNetCidr: 172.17.0.0/24 StorageNetCidr: 172.18.0.0/24 StorageMgmtNetCidr: 172.19.0.0/24 TenantNetCidr: 172.16.0.0/24 ExternalNetCidr: 10.1.2.0/24 # CIDR subnet mask length for provisioning network ControlPlaneSubnetCidr: '24' InternalApiAllocationPools: [{'start': '172.17.0.10', 'end': '172.17.0.200'}] StorageAllocationPools: [{'start': '172.18.0.10', 'end': '172.18.0.200'}] StorageMgmtAllocationPools: [{'start': '172.19.0.10', 'end': '172.19.0.200'}] TenantAllocationPools: [{'start': '172.16.0.10', 'end': '172.16.0.200'}] # Use an External allocation pool which will leave room for floating IPs ExternalAllocationPools: [{'start': '10.1.2.10', 'end': '10.1.2.50'}] # Set to the router gateway on the external network ExternalInterfaceDefaultRoute: 10.1.2.1 # Gateway router for the provisioning network (or Undercloud IP) ControlPlaneDefaultRoute: 192.0.2.254 # Generally the IP of the Undercloud EC2MetadataIp: 192.0.2.1 # Define the DNS servers (maximum 2) for the overcloud nodes DnsServers: ["8.8.8.8","8.8.4.4"] InternalApiNetworkVlanID: 201 StorageNetworkVlanID: 202 StorageMgmtNetworkVlanID: 203 TenantNetworkVlanID: 204 ExternalNetworkVlanID: 100 # May set to br-ex if using floating IPs only on native VLAN on bridge br-ex NeutronExternalNetworkBridge: "''" # Customize bonding options if required (ignored if bonds are not used) BondInterfaceOvsOptions: "lacp=active other-config:lacp-fallback-ab=true" which apparently you have been using. I believe to add vlan27 - similar entries have to be added to each section above for vlan27 the last one :- MyNetworkVlanID 27 ________________________________ From: Brandon James Sent: Tuesday, October 18, 2016 6:08 PM To: Boris Derzhavets Cc: John Marks; rdo-list at redhat.com Subject: Re: [rdo-list] Adding a vlan to the external network in tripleo All, I truly feel that we should somehow improve the documentation to explain how to do this in detail(Vlans and external networks). I suspect that many people who want to tryout Tripleo/RDO Packstack are really struggling with the networking. I know for myself this alone is the main reason I have not deployed this into production because our external network is very complex and I need to be certain I can integrate this without serious pain. It would be great if users could easily change these settings on the fly because for most admins, networking is never static. Just my 2 cents. Brandon On Tue, Oct 18, 2016 at 10:59 AM, Boris Derzhavets > wrote: > It would seem that all I need to do is create a vlan27 port as shown below. The below was generated by the heat OOO heat templates. Doesn't it mean one of original templates ( which were invoked by `openstack overcloud deploy .... ` ) should be updated to create vlan27 as separate network or you have some other way to add vlan27 ? ________________________________ From: John Marks > Sent: Tuesday, October 18, 2016 5:21 PM To: Boris Derzhavets; rdo-list at redhat.com Subject: Re: [rdo-list] Adding a vlan to the external network in tripleo I looked over you scenario in your blog and it is close. I have a single external port that shares the native VLAN and VLAN27. In my case, I configrued the external bridge (br-ex) with the native vlan and am now faced with adding vlan27 to the bridge. RHOSP has a vlan scenario which I used in creating the bridge and vlans under it that carry the storage, etc. It would seem that all I need to do is create a vlan27 port as shown below. The below was generated by the heat OOO heat templates. stack: ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eno1: mtu 1500 qdisc mq state UP qlen 1000 link/ether 14:58:d0:4c:2e:98 brd ff:ff:ff:ff:ff:ff inet 192.0.2.17/24 brd 192.0.2.255 scope global eno1 valid_lft forever preferred_lft forever inet 192.0.2.15/32 brd 192.0.2.255 scope global eno1 valid_lft forever preferred_lft forever inet6 fe80::1658:d0ff:fe4c:2e98/64 scope link valid_lft forever preferred_lft forever 3: ens1f0: mtu 1500 qdisc mq state DOWN qlen 1000 link/ether 8c:dc:d4:b1:8e:b8 brd ff:ff:ff:ff:ff:ff 4: eno2: mtu 1500 qdisc mq master ovs-system state UP qlen 1000 link/ether 14:58:d0:4c:2e:9c brd ff:ff:ff:ff:ff:ff inet6 fe80::1658:d0ff:fe4c:2e9c/64 scope link valid_lft forever preferred_lft forever 5: ens1f1: mtu 1500 qdisc mq state DOWN qlen 1000 link/ether 8c:dc:d4:b1:8e:b9 brd ff:ff:ff:ff:ff:ff 6: eno3: mtu 1500 qdisc mq master ovs-system state UP qlen 1000 link/ether 14:58:d0:4c:2e:99 brd ff:ff:ff:ff:ff:ff inet6 fe80::1658:d0ff:fe4c:2e99/64 scope link valid_lft forever preferred_lft forever 7: eno4: mtu 1500 qdisc mq state DOWN qlen 1000 link/ether 14:58:d0:4c:2e:9d brd ff:ff:ff:ff:ff:ff 8: eno5: mtu 1500 qdisc mq state DOWN qlen 1000 link/ether 14:58:d0:4c:2e:9a brd ff:ff:ff:ff:ff:ff 9: eno6: mtu 1500 qdisc mq state DOWN qlen 1000 link/ether 14:58:d0:4c:2e:9e brd ff:ff:ff:ff:ff:ff 10: eno7: mtu 1500 qdisc noop master ovs-system state DOWN qlen 1000 link/ether 14:58:d0:4c:2e:9b brd ff:ff:ff:ff:ff:ff 11: eno8: mtu 1500 qdisc mq state DOWN qlen 1000 link/ether 14:58:d0:4c:2e:9f brd ff:ff:ff:ff:ff:ff 12: ovs-system: mtu 1500 qdisc noop state DOWN link/ether da:f8:b1:fd:2e:74 brd ff:ff:ff:ff:ff:ff 13: br-ex1: mtu 1500 qdisc noop state DOWN link/ether 14:58:d0:4c:2e:9b brd ff:ff:ff:ff:ff:ff 14: br-tun: mtu 1500 qdisc noop state DOWN link/ether 2a:98:45:ed:fb:4b brd ff:ff:ff:ff:ff:ff 15: vlan203: mtu 1500 qdisc noqueue state UNKNOWN link/ether 0a:5a:9c:28:45:f6 brd ff:ff:ff:ff:ff:ff inet 172.19.0.11/24 brd 172.19.0.255 scope global vlan203 valid_lft forever preferred_lft forever inet 172.19.0.10/32 brd 172.19.0.255 scope global vlan203 valid_lft forever preferred_lft forever inet6 fe80::85a:9cff:fe28:45f6/64 scope link valid_lft forever preferred_lft forever 16: vlan202: mtu 1500 qdisc noqueue state UNKNOWN link/ether 6e:3f:59:63:41:89 brd ff:ff:ff:ff:ff:ff inet 172.18.0.12/24 brd 172.18.0.255 scope global vlan202 valid_lft forever preferred_lft forever inet 172.18.0.10/32 brd 172.18.0.255 scope global vlan202 valid_lft forever preferred_lft forever inet6 fe80::6c3f:59ff:fe63:4189/64 scope link valid_lft forever preferred_lft forever 17: br-ex: mtu 1500 qdisc noqueue state UNKNOWN link/ether 14:58:d0:4c:2e:9c brd ff:ff:ff:ff:ff:ff inet 10.1.62.169/24 brd 10.1.62.255 scope global br-ex valid_lft forever preferred_lft forever inet 10.1.62.168/32 brd 10.1.62.255 scope global br-ex valid_lft forever preferred_lft forever inet6 fcff:1:62:0:1658:d0ff:fe4c:2e9c/64 scope global mngtmpaddr dynamic valid_lft 2591980sec preferred_lft 604780sec inet6 fe80::1658:d0ff:fe4c:2e9c/64 scope link valid_lft forever preferred_lft forever 18: vlan204: mtu 1500 qdisc noqueue state UNKNOWN link/ether ba:76:32:20:c8:1e brd ff:ff:ff:ff:ff:ff inet 172.17.0.11/24 brd 172.17.0.255 scope global vlan204 valid_lft forever preferred_lft forever inet6 fe80::b876:32ff:fe20:c81e/64 scope link valid_lft forever preferred_lft forever 19: vlan201: mtu 1500 qdisc noqueue state UNKNOWN link/ether 96:0b:f7:a1:89:dc brd ff:ff:ff:ff:ff:ff inet 172.16.0.13/24 brd 172.16.0.255 scope global vlan201 valid_lft forever preferred_lft forever inet 172.16.0.10/32 brd 172.16.0.255 scope global vlan201 valid_lft forever preferred_lft forever inet 172.16.0.11/32 brd 172.16.0.255 scope global vlan201 valid_lft forever preferred_lft forever inet6 fe80::940b:f7ff:fea1:89dc/64 scope link valid_lft forever preferred_lft forever 23: br-int: mtu 1500 qdisc noop state DOWN link/ether 12:ec:43:c0:1d:43 brd ff:ff:ff:ff:ff:ff stack: ovs-ctl show 75acb2b-1107-419f-9fed-1b80741aa78a Bridge br-ex Port "vlan202" tag: 202 Interface "vlan202" type: internal Port br-ex Interface br-ex type: internal Port "vlan201" tag: 201 Interface "vlan201" type: internal Port "bond1" Interface "eno2" Interface "eno3" Port phy-br-ex Interface phy-br-ex type: patch options: {peer=int-br-ex} Port "vlan204" tag: 204 Interface "vlan204" type: internal Port "vlan203" tag: 203 Interface "vlan203" type: internal Bridge br-int fail_mode: secure Port "tap485f8aa8-86" tag: 2 Interface "tap485f8aa8-86" type: internal Port patch-tun Interface patch-tun type: patch options: {peer=patch-int} Port "tap62b75cc5-ef" tag: 3 Interface "tap62b75cc5-ef" type: internal Port br-int Interface br-int type: internal Port "tap123c52e6-5d" tag: 1 Interface "tap123c52e6-5d" type: internal Port int-br-ex Interface int-br-ex type: patch options: {peer=phy-br-ex} Bridge br-tun fail_mode: secure Port br-tun Interface br-tun type: internal Port "vxlan-ac11000c" Interface "vxlan-ac11000c" type: vxlan options: {df_default="true", in_key=flow, local_ip="172.17.0.11", out_key=flow, remote_ip="172.17.0.12"} Port "vxlan-ac11000a" Interface "vxlan-ac11000a" type: vxlan options: {df_default="true", in_key=flow, local_ip="172.17.0.11", out_key=flow, remote_ip="172.17.0.10"} Port patch-int Interface patch-int type: patch options: {peer=patch-tun} Port "vxlan-ac11000d" Interface "vxlan-ac11000d" type: vxlan options: {df_default="true", in_key=flow, local_ip="172.17.0.11", out_key=flow, remote_ip="172.17.0.13"} Port "vxlan-ac11000e" Interface "vxlan-ac11000e" type: vxlan options: {df_default="true", in_key=flow, local_ip="172.17.0.11", out_key=flow, remote_ip="172.17.0.14"} On Tue, Oct 18, 2016 at 8:50 AM, John Marks > wrote: Doesn't that make the stack very inflexible? And yes, we have faced this issue before and talked to RH about it and they said exactly the same thing. However, if I redeploy, I have found that modifying the network config does not take affect and I have to delete and redeploy the overcloud. That would really reak havoc if I had to do that in production. Thanks for the reply. On Tue, Oct 18, 2016 at 8:43 AM, Boris Derzhavets > wrote: Sorry for typo If I am not correct stating the above, RH's technical stuff will point to my mistake for sure I skipped "if" on first place. ________________________________ From: rdo-list-bounces at redhat.com > on behalf of Boris Derzhavets > Sent: Tuesday, October 18, 2016 4:37 PM To: John Marks; rdo-list at redhat.com Subject: Re: [rdo-list] Adding a vlan to the external network in tripleo I have a lab situation where there are 2 networks. One is in one DMZ and the other is a lab isolated network. I need access to both via the external port. I believe what I need to do is add another port to the bridge on a vlan to the lab network. I created a new external network in Director and assigned the vlan to it. However, I am not sure that will add it to the existing bridge. A bigger question around this is why does Openstack not support modifications after installation to the north/south network? Openstack has no problem with adding one more external network (or even 2) of VLAN type . See for instance https://www.linux.com/blog/rdo-mitaka-several-external-networks-vlan-provider-setup The problem here is the way which was used for deployment, it is TripleO. To have the job done you need to update heat stack "overcloud" which had been built on undercloud Node. So you should be able redeploy overcloud with specific tripleo-heat-template addressing you needs. I would expect your br-ex bridges to have IPs on ctlplane obtained via DHCP. Any manual intervention to overcloud is impossible. You have presumably only one option , which is to ask vendor for support. I am not correct stating the above, RH's technical stuff will point to my mistake for sure. That is why I am so sorry about regression taken place in packstack functionality Boris. East/west is easy but North/South has to have a lot of modifications made to static files (it seems) like plugin.ini and openvswitch.ini. ________________________________ From: rdo-list-bounces at redhat.com > on behalf of John Marks > Sent: Tuesday, October 18, 2016 7:32:53 AM To: rdo-list at redhat.com Subject: [rdo-list] Adding a vlan to the external network in tripleo I have a lab situation where there are 2 networks. One is in one DMZ and the other is a lab isolated network. I need access to both via the external port. I believe what I need to do is add another port to the bridge on a vlan to the lab network. I created a new external network in Director and assigned the vlan to it. However, I am not sure that will add it to the existing bridge. A bigger question around this is why does Openstack not support modifications after installation to the north/south network? East/west is easy but North/South has to have a lot of modifications made to static files (it seems) like plugin.ini and openvswitch.ini. Any help would be appreciated. _______________________________________________ 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 -- [https://0cac57e6-a-62cb3a1a-s-sites.googlegroups.com/site/brandonajames/hot/SUNAYU_LOGO_SIDE%28NO%20TAGLINE%29.jpg?attachauth=ANoY7craA8YrLTT8x3WhaypAtiXvQ0K-_OS2jZLqGIxlVfggNoilgZ0EphWMvnkHuk2FGCoOAjLIdLUOfDaai4Hb33i4FsnL9TXCfSS4WDRCVQVeKFk3qZU226q_8ZQhEYrPX9OR_Bx3eeOB42Qb9fr6qDvqzgSLcbGWpvI_vaAU8ldioT8VmZIwTFZJ84g6PcdXTG-aKTBGCN0xDfScEkqhERAh8lqvHsOua9a6jYjhY49IRhsfGj-_2V5FUz_p4oBpI1B3qjvK&attredirects=0&retryCount=3] Brandon James CEO & Founding Member Mobile: 240.476-3922 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdmarks75080 at gmail.com Tue Oct 18 16:57:17 2016 From: jdmarks75080 at gmail.com (John Marks) Date: Tue, 18 Oct 2016 11:57:17 -0500 Subject: [rdo-list] Adding a vlan to the external network in tripleo In-Reply-To: References: Message-ID: There are some good docs on RH. The docs for RDHOSP 9 there is a networking guide with a lot of detail. However, the heat templates for tripleo are confusing. The thing is that with RHOSP, there is no "packstack" install so if your hope is to move from RDO to RHOSP, then tripleo is the way to go. But, as I said earlier, the north/south networking in Openstack remains a pain and the RedHat networking docs are very brief. If I knew that I could add north/south as easily as I can east west, I would be done. On Tue, Oct 18, 2016 at 10:08 AM, Brandon James wrote: > All, > > I truly feel that we should somehow improve the documentation to explain > how to do this in detail(Vlans and external networks). I suspect that many > people who want to tryout Tripleo/RDO Packstack are really struggling with > the networking. I know for myself this alone is the main reason I have not > deployed this into production because our external network is very complex > and I need to be certain I can integrate this without serious pain. It > would be great if users could easily change these settings on the fly > because for most admins, networking is never static. Just my 2 cents. > > > Brandon > > On Tue, Oct 18, 2016 at 10:59 AM, Boris Derzhavets < > bderzhavets at hotmail.com> wrote: > >> > It would seem that all I need to do is create a vlan27 port as shown >> below. The below was generated by the heat OOO heat templates. >> >> >> Doesn't it mean one of original templates ( which were invoked by >> `openstack overcloud deploy .... ` ) >> should be updated to create vlan27 as separate network or you have some >> other way to add vlan27 ? >> >> >> >> >> >> ------------------------------ >> *From:* John Marks >> *Sent:* Tuesday, October 18, 2016 5:21 PM >> *To:* Boris Derzhavets; rdo-list at redhat.com >> >> *Subject:* Re: [rdo-list] Adding a vlan to the external network in >> tripleo >> >> I looked over you scenario in your blog and it is close. I have a single >> external port that shares the native VLAN and VLAN27. In my case, I >> configrued the external bridge (br-ex) with the native vlan and am now >> faced with adding vlan27 to the bridge. RHOSP has a vlan scenario which I >> used in creating the bridge and vlans under it that carry the storage, etc. >> It would seem that all I need to do is create a vlan27 port as shown below. >> The below was generated by the heat OOO heat templates. >> >> stack: ip a >> 1: lo: mtu 65536 qdisc noqueue state UNKNOWN >> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 >> inet 127.0.0.1/8 scope host lo >> valid_lft forever preferred_lft forever >> inet6 ::1/128 scope host >> valid_lft forever preferred_lft forever >> 2: eno1: mtu 1500 qdisc mq state UP >> qlen 1000 >> link/ether 14:58:d0:4c:2e:98 brd ff:ff:ff:ff:ff:ff >> inet 192.0.2.17/24 brd 192.0.2.255 scope global eno1 >> valid_lft forever preferred_lft forever >> inet 192.0.2.15/32 brd 192.0.2.255 scope global eno1 >> valid_lft forever preferred_lft forever >> inet6 fe80::1658:d0ff:fe4c:2e98/64 scope link >> valid_lft forever preferred_lft forever >> 3: ens1f0: mtu 1500 qdisc mq state >> DOWN qlen 1000 >> link/ether 8c:dc:d4:b1:8e:b8 brd ff:ff:ff:ff:ff:ff >> 4: eno2: mtu 1500 qdisc mq master >> ovs-system state UP qlen 1000 >> link/ether 14:58:d0:4c:2e:9c brd ff:ff:ff:ff:ff:ff >> inet6 fe80::1658:d0ff:fe4c:2e9c/64 scope link >> valid_lft forever preferred_lft forever >> 5: ens1f1: mtu 1500 qdisc mq state >> DOWN qlen 1000 >> link/ether 8c:dc:d4:b1:8e:b9 brd ff:ff:ff:ff:ff:ff >> 6: eno3: mtu 1500 qdisc mq master >> ovs-system state UP qlen 1000 >> link/ether 14:58:d0:4c:2e:99 brd ff:ff:ff:ff:ff:ff >> inet6 fe80::1658:d0ff:fe4c:2e99/64 scope link >> valid_lft forever preferred_lft forever >> 7: eno4: mtu 1500 qdisc mq state >> DOWN qlen 1000 >> link/ether 14:58:d0:4c:2e:9d brd ff:ff:ff:ff:ff:ff >> 8: eno5: mtu 1500 qdisc mq state >> DOWN qlen 1000 >> link/ether 14:58:d0:4c:2e:9a brd ff:ff:ff:ff:ff:ff >> 9: eno6: mtu 1500 qdisc mq state >> DOWN qlen 1000 >> link/ether 14:58:d0:4c:2e:9e brd ff:ff:ff:ff:ff:ff >> 10: eno7: mtu 1500 qdisc noop master ovs-system >> state DOWN qlen 1000 >> link/ether 14:58:d0:4c:2e:9b brd ff:ff:ff:ff:ff:ff >> 11: eno8: mtu 1500 qdisc mq state >> DOWN qlen 1000 >> link/ether 14:58:d0:4c:2e:9f brd ff:ff:ff:ff:ff:ff >> 12: ovs-system: mtu 1500 qdisc noop state DOWN >> link/ether da:f8:b1:fd:2e:74 brd ff:ff:ff:ff:ff:ff >> 13: br-ex1: mtu 1500 qdisc noop state DOWN >> link/ether 14:58:d0:4c:2e:9b brd ff:ff:ff:ff:ff:ff >> 14: br-tun: mtu 1500 qdisc noop state DOWN >> link/ether 2a:98:45:ed:fb:4b brd ff:ff:ff:ff:ff:ff >> 15: vlan203: mtu 1500 qdisc noqueue >> state UNKNOWN >> link/ether 0a:5a:9c:28:45:f6 brd ff:ff:ff:ff:ff:ff >> inet 172.19.0.11/24 brd 172.19.0.255 scope global vlan203 >> valid_lft forever preferred_lft forever >> inet 172.19.0.10/32 brd 172.19.0.255 scope global vlan203 >> valid_lft forever preferred_lft forever >> inet6 fe80::85a:9cff:fe28:45f6/64 scope link >> valid_lft forever preferred_lft forever >> 16: vlan202: mtu 1500 qdisc noqueue >> state UNKNOWN >> link/ether 6e:3f:59:63:41:89 brd ff:ff:ff:ff:ff:ff >> inet 172.18.0.12/24 brd 172.18.0.255 scope global vlan202 >> valid_lft forever preferred_lft forever >> inet 172.18.0.10/32 brd 172.18.0.255 scope global vlan202 >> valid_lft forever preferred_lft forever >> inet6 fe80::6c3f:59ff:fe63:4189/64 scope link >> valid_lft forever preferred_lft forever >> 17: br-ex: mtu 1500 qdisc noqueue >> state UNKNOWN >> link/ether 14:58:d0:4c:2e:9c brd ff:ff:ff:ff:ff:ff >> inet 10.1.62.169/24 brd 10.1.62.255 scope global br-ex >> valid_lft forever preferred_lft forever >> inet 10.1.62.168/32 brd 10.1.62.255 scope global br-ex >> valid_lft forever preferred_lft forever >> inet6 fcff:1:62:0:1658:d0ff:fe4c:2e9c/64 scope global mngtmpaddr >> dynamic >> valid_lft 2591980sec preferred_lft 604780sec >> inet6 fe80::1658:d0ff:fe4c:2e9c/64 scope link >> valid_lft forever preferred_lft forever >> 18: vlan204: mtu 1500 qdisc noqueue >> state UNKNOWN >> link/ether ba:76:32:20:c8:1e brd ff:ff:ff:ff:ff:ff >> inet 172.17.0.11/24 brd 172.17.0.255 scope global vlan204 >> valid_lft forever preferred_lft forever >> inet6 fe80::b876:32ff:fe20:c81e/64 scope link >> valid_lft forever preferred_lft forever >> 19: vlan201: mtu 1500 qdisc noqueue >> state UNKNOWN >> link/ether 96:0b:f7:a1:89:dc brd ff:ff:ff:ff:ff:ff >> inet 172.16.0.13/24 brd 172.16.0.255 scope global vlan201 >> valid_lft forever preferred_lft forever >> inet 172.16.0.10/32 brd 172.16.0.255 scope global vlan201 >> valid_lft forever preferred_lft forever >> inet 172.16.0.11/32 brd 172.16.0.255 scope global vlan201 >> valid_lft forever preferred_lft forever >> inet6 fe80::940b:f7ff:fea1:89dc/64 scope link >> valid_lft forever preferred_lft forever >> 23: br-int: mtu 1500 qdisc noop state DOWN >> link/ether 12:ec:43:c0:1d:43 brd ff:ff:ff:ff:ff:ff >> >> stack: ovs-ctl show >> 75acb2b-1107-419f-9fed-1b80741aa78a >> Bridge br-ex >> Port "vlan202" >> tag: 202 >> Interface "vlan202" >> type: internal >> Port br-ex >> Interface br-ex >> type: internal >> Port "vlan201" >> tag: 201 >> Interface "vlan201" >> type: internal >> Port "bond1" >> Interface "eno2" >> Interface "eno3" >> Port phy-br-ex >> Interface phy-br-ex >> type: patch >> options: {peer=int-br-ex} >> Port "vlan204" >> tag: 204 >> Interface "vlan204" >> type: internal >> Port "vlan203" >> tag: 203 >> Interface "vlan203" >> type: internal >> Bridge br-int >> fail_mode: secure >> Port "tap485f8aa8-86" >> tag: 2 >> Interface "tap485f8aa8-86" >> type: internal >> Port patch-tun >> Interface patch-tun >> type: patch >> options: {peer=patch-int} >> Port "tap62b75cc5-ef" >> tag: 3 >> Interface "tap62b75cc5-ef" >> type: internal >> Port br-int >> Interface br-int >> type: internal >> Port "tap123c52e6-5d" >> tag: 1 >> Interface "tap123c52e6-5d" >> type: internal >> Port int-br-ex >> Interface int-br-ex >> type: patch >> options: {peer=phy-br-ex} >> Bridge br-tun >> fail_mode: secure >> Port br-tun >> Interface br-tun >> type: internal >> Port "vxlan-ac11000c" >> Interface "vxlan-ac11000c" >> type: vxlan >> options: {df_default="true", in_key=flow, >> local_ip="172.17.0.11", out_key=flow, remote_ip="172.17.0.12"} >> Port "vxlan-ac11000a" >> Interface "vxlan-ac11000a" >> type: vxlan >> options: {df_default="true", in_key=flow, >> local_ip="172.17.0.11", out_key=flow, remote_ip="172.17.0.10"} >> Port patch-int >> Interface patch-int >> type: patch >> options: {peer=patch-tun} >> Port "vxlan-ac11000d" >> Interface "vxlan-ac11000d" >> type: vxlan >> options: {df_default="true", in_key=flow, >> local_ip="172.17.0.11", out_key=flow, remote_ip="172.17.0.13"} >> Port "vxlan-ac11000e" >> Interface "vxlan-ac11000e" >> type: vxlan >> options: {df_default="true", in_key=flow, >> local_ip="172.17.0.11", out_key=flow, remote_ip="172.17.0.14"} >> >> >> >> On Tue, Oct 18, 2016 at 8:50 AM, John Marks >> wrote: >> >>> Doesn't that make the stack very inflexible? And yes, we have faced this >>> issue before and talked to RH about it and they said exactly the same >>> thing. However, if I redeploy, I have found that modifying the network >>> config does not take affect and I have to delete and redeploy the >>> overcloud. That would really reak havoc if I had to do that in production. >>> >>> Thanks for the reply. >>> >>> On Tue, Oct 18, 2016 at 8:43 AM, Boris Derzhavets < >>> bderzhavets at hotmail.com> wrote: >>> >>>> Sorry for typo >>>> >>>> If I am not correct stating the above, RH's technical stuff will >>>> point to my mistake for sure >>>> >>>> I skipped "if" on first place. >>>> >>>> >>>> ------------------------------ >>>> *From:* rdo-list-bounces at redhat.com on >>>> behalf of Boris Derzhavets >>>> *Sent:* Tuesday, October 18, 2016 4:37 PM >>>> *To:* John Marks; rdo-list at redhat.com >>>> *Subject:* Re: [rdo-list] Adding a vlan to the external network in >>>> tripleo >>>> >>>> >>>> I have a lab situation where there are 2 networks. One is in one DMZ >>>> and the other is a lab isolated network. I need access to both via the >>>> external port. I believe what I need to do is add another port to the >>>> bridge on a vlan to the lab network. I created a new external network in >>>> Director and assigned the vlan to it. However, I am not sure that will add >>>> it to the existing bridge. >>>> >>>> A bigger question around this is why does Openstack not support >>>> modifications after installation to the north/south network? >>>> >>>> Openstack has no problem with adding one more external network (or >>>> even 2) of VLAN type . >>>> See for instance https://www.linux.com/blog/rdo >>>> -mitaka-several-external-networks-vlan-provider-setup >>>> The problem here is the way which was used for deployment, it is >>>> TripleO. >>>> To have the job done you need to update heat stack "overcloud" which >>>> had been built >>>> on undercloud Node. So you should be able redeploy overcloud with >>>> specific tripleo-heat-template >>>> addressing you needs. I would expect your br-ex bridges to have >>>> IPs on ctlplane obtained via DHCP. >>>> Any manual intervention to overcloud is impossible. You have >>>> presumably only one >>>> option , which is to ask vendor for support. >>>> I am not correct stating the above, RH's technical stuff will point >>>> to my mistake for sure. >>>> That is why I am so sorry about regression taken place in packstack >>>> functionality >>>> >>>> Boris. >>>> >>>> >>>> East/west is easy but North/South has to have a lot of modifications >>>> made to static files (it seems) like plugin.ini and openvswitch.ini. >>>> >>>> >>>> ------------------------------ >>>> *From:* rdo-list-bounces at redhat.com on >>>> behalf of John Marks >>>> *Sent:* Tuesday, October 18, 2016 7:32:53 AM >>>> *To:* rdo-list at redhat.com >>>> *Subject:* [rdo-list] Adding a vlan to the external network in tripleo >>>> >>>> I have a lab situation where there are 2 networks. One is in one DMZ >>>> and the other is a lab isolated network. I need access to both via the >>>> external port. I believe what I need to do is add another port to the >>>> bridge on a vlan to the lab network. I created a new external network in >>>> Director and assigned the vlan to it. However, I am not sure that will add >>>> it to the existing bridge. >>>> >>>> A bigger question around this is why does Openstack not support >>>> modifications after installation to the north/south network? East/west is >>>> easy but North/South has to have a lot of modifications made to static >>>> files (it seems) like plugin.ini and openvswitch.ini. >>>> >>>> Any help would be appreciated. >>>> >>> >>> >> >> _______________________________________________ >> 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 >> > > > > -- > > > Brandon James > CEO & Founding Member > Mobile: 240.476-3922 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bderzhavets at hotmail.com Tue Oct 18 19:59:59 2016 From: bderzhavets at hotmail.com (Boris Derzhavets) Date: Tue, 18 Oct 2016 19:59:59 +0000 Subject: [rdo-list] Adding a vlan to the external network in tripleo In-Reply-To: References: , Message-ID: ________________________________ From: John Marks Sent: Tuesday, October 18, 2016 7:57 PM To: Brandon James Cc: Boris Derzhavets; rdo-list at redhat.com Subject: Re: [rdo-list] Adding a vlan to the external network in tripleo There are some good docs on RH. The docs for RDHOSP 9 there is a networking guide with a lot of detail. However, the heat templates for tripleo are confusing. The thing is that with RHOSP, there is no "packstack" install so if your hope is to move from RDO to RHOSP, then tripleo is the way to go. But, as I said earlier, the north/south networking in Openstack remains a pain Do you have in overcloud ( RHOSP 9 ) at least one external network ( for cloud VMs ) rout-able in both ingress/egress directions to the Internet . Thank you. Boris and the RedHat networking docs are very brief. If I knew that I could add north/south as easily as I can east west, I would be done. On Tue, Oct 18, 2016 at 10:08 AM, Brandon James > wrote: All, I truly feel that we should somehow improve the documentation to explain how to do this in detail(Vlans and external networks). I suspect that many people who want to tryout Tripleo/RDO Packstack are really struggling with the networking. I know for myself this alone is the main reason I have not deployed this into production because our external network is very complex and I need to be certain I can integrate this without serious pain. It would be great if users could easily change these settings on the fly because for most admins, networking is never static. Just my 2 cents. Brandon On Tue, Oct 18, 2016 at 10:59 AM, Boris Derzhavets > wrote: > It would seem that all I need to do is create a vlan27 port as shown below. The below was generated by the heat OOO heat templates. Doesn't it mean one of original templates ( which were invoked by `openstack overcloud deploy .... ` ) should be updated to create vlan27 as separate network or you have some other way to add vlan27 ? ________________________________ From: John Marks > Sent: Tuesday, October 18, 2016 5:21 PM To: Boris Derzhavets; rdo-list at redhat.com Subject: Re: [rdo-list] Adding a vlan to the external network in tripleo I looked over you scenario in your blog and it is close. I have a single external port that shares the native VLAN and VLAN27. In my case, I configrued the external bridge (br-ex) with the native vlan and am now faced with adding vlan27 to the bridge. RHOSP has a vlan scenario which I used in creating the bridge and vlans under it that carry the storage, etc. It would seem that all I need to do is create a vlan27 port as shown below. The below was generated by the heat OOO heat templates. stack: ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eno1: mtu 1500 qdisc mq state UP qlen 1000 link/ether 14:58:d0:4c:2e:98 brd ff:ff:ff:ff:ff:ff inet 192.0.2.17/24 brd 192.0.2.255 scope global eno1 valid_lft forever preferred_lft forever inet 192.0.2.15/32 brd 192.0.2.255 scope global eno1 valid_lft forever preferred_lft forever inet6 fe80::1658:d0ff:fe4c:2e98/64 scope link valid_lft forever preferred_lft forever 3: ens1f0: mtu 1500 qdisc mq state DOWN qlen 1000 link/ether 8c:dc:d4:b1:8e:b8 brd ff:ff:ff:ff:ff:ff 4: eno2: mtu 1500 qdisc mq master ovs-system state UP qlen 1000 link/ether 14:58:d0:4c:2e:9c brd ff:ff:ff:ff:ff:ff inet6 fe80::1658:d0ff:fe4c:2e9c/64 scope link valid_lft forever preferred_lft forever 5: ens1f1: mtu 1500 qdisc mq state DOWN qlen 1000 link/ether 8c:dc:d4:b1:8e:b9 brd ff:ff:ff:ff:ff:ff 6: eno3: mtu 1500 qdisc mq master ovs-system state UP qlen 1000 link/ether 14:58:d0:4c:2e:99 brd ff:ff:ff:ff:ff:ff inet6 fe80::1658:d0ff:fe4c:2e99/64 scope link valid_lft forever preferred_lft forever 7: eno4: mtu 1500 qdisc mq state DOWN qlen 1000 link/ether 14:58:d0:4c:2e:9d brd ff:ff:ff:ff:ff:ff 8: eno5: mtu 1500 qdisc mq state DOWN qlen 1000 link/ether 14:58:d0:4c:2e:9a brd ff:ff:ff:ff:ff:ff 9: eno6: mtu 1500 qdisc mq state DOWN qlen 1000 link/ether 14:58:d0:4c:2e:9e brd ff:ff:ff:ff:ff:ff 10: eno7: mtu 1500 qdisc noop master ovs-system state DOWN qlen 1000 link/ether 14:58:d0:4c:2e:9b brd ff:ff:ff:ff:ff:ff 11: eno8: mtu 1500 qdisc mq state DOWN qlen 1000 link/ether 14:58:d0:4c:2e:9f brd ff:ff:ff:ff:ff:ff 12: ovs-system: mtu 1500 qdisc noop state DOWN link/ether da:f8:b1:fd:2e:74 brd ff:ff:ff:ff:ff:ff 13: br-ex1: mtu 1500 qdisc noop state DOWN link/ether 14:58:d0:4c:2e:9b brd ff:ff:ff:ff:ff:ff 14: br-tun: mtu 1500 qdisc noop state DOWN link/ether 2a:98:45:ed:fb:4b brd ff:ff:ff:ff:ff:ff 15: vlan203: mtu 1500 qdisc noqueue state UNKNOWN link/ether 0a:5a:9c:28:45:f6 brd ff:ff:ff:ff:ff:ff inet 172.19.0.11/24 brd 172.19.0.255 scope global vlan203 valid_lft forever preferred_lft forever inet 172.19.0.10/32 brd 172.19.0.255 scope global vlan203 valid_lft forever preferred_lft forever inet6 fe80::85a:9cff:fe28:45f6/64 scope link valid_lft forever preferred_lft forever 16: vlan202: mtu 1500 qdisc noqueue state UNKNOWN link/ether 6e:3f:59:63:41:89 brd ff:ff:ff:ff:ff:ff inet 172.18.0.12/24 brd 172.18.0.255 scope global vlan202 valid_lft forever preferred_lft forever inet 172.18.0.10/32 brd 172.18.0.255 scope global vlan202 valid_lft forever preferred_lft forever inet6 fe80::6c3f:59ff:fe63:4189/64 scope link valid_lft forever preferred_lft forever 17: br-ex: mtu 1500 qdisc noqueue state UNKNOWN link/ether 14:58:d0:4c:2e:9c brd ff:ff:ff:ff:ff:ff inet 10.1.62.169/24 brd 10.1.62.255 scope global br-ex valid_lft forever preferred_lft forever inet 10.1.62.168/32 brd 10.1.62.255 scope global br-ex valid_lft forever preferred_lft forever inet6 fcff:1:62:0:1658:d0ff:fe4c:2e9c/64 scope global mngtmpaddr dynamic valid_lft 2591980sec preferred_lft 604780sec inet6 fe80::1658:d0ff:fe4c:2e9c/64 scope link valid_lft forever preferred_lft forever 18: vlan204: mtu 1500 qdisc noqueue state UNKNOWN link/ether ba:76:32:20:c8:1e brd ff:ff:ff:ff:ff:ff inet 172.17.0.11/24 brd 172.17.0.255 scope global vlan204 valid_lft forever preferred_lft forever inet6 fe80::b876:32ff:fe20:c81e/64 scope link valid_lft forever preferred_lft forever 19: vlan201: mtu 1500 qdisc noqueue state UNKNOWN link/ether 96:0b:f7:a1:89:dc brd ff:ff:ff:ff:ff:ff inet 172.16.0.13/24 brd 172.16.0.255 scope global vlan201 valid_lft forever preferred_lft forever inet 172.16.0.10/32 brd 172.16.0.255 scope global vlan201 valid_lft forever preferred_lft forever inet 172.16.0.11/32 brd 172.16.0.255 scope global vlan201 valid_lft forever preferred_lft forever inet6 fe80::940b:f7ff:fea1:89dc/64 scope link valid_lft forever preferred_lft forever 23: br-int: mtu 1500 qdisc noop state DOWN link/ether 12:ec:43:c0:1d:43 brd ff:ff:ff:ff:ff:ff stack: ovs-ctl show 75acb2b-1107-419f-9fed-1b80741aa78a Bridge br-ex Port "vlan202" tag: 202 Interface "vlan202" type: internal Port br-ex Interface br-ex type: internal Port "vlan201" tag: 201 Interface "vlan201" type: internal Port "bond1" Interface "eno2" Interface "eno3" Port phy-br-ex Interface phy-br-ex type: patch options: {peer=int-br-ex} Port "vlan204" tag: 204 Interface "vlan204" type: internal Port "vlan203" tag: 203 Interface "vlan203" type: internal Bridge br-int fail_mode: secure Port "tap485f8aa8-86" tag: 2 Interface "tap485f8aa8-86" type: internal Port patch-tun Interface patch-tun type: patch options: {peer=patch-int} Port "tap62b75cc5-ef" tag: 3 Interface "tap62b75cc5-ef" type: internal Port br-int Interface br-int type: internal Port "tap123c52e6-5d" tag: 1 Interface "tap123c52e6-5d" type: internal Port int-br-ex Interface int-br-ex type: patch options: {peer=phy-br-ex} Bridge br-tun fail_mode: secure Port br-tun Interface br-tun type: internal Port "vxlan-ac11000c" Interface "vxlan-ac11000c" type: vxlan options: {df_default="true", in_key=flow, local_ip="172.17.0.11", out_key=flow, remote_ip="172.17.0.12"} Port "vxlan-ac11000a" Interface "vxlan-ac11000a" type: vxlan options: {df_default="true", in_key=flow, local_ip="172.17.0.11", out_key=flow, remote_ip="172.17.0.10"} Port patch-int Interface patch-int type: patch options: {peer=patch-tun} Port "vxlan-ac11000d" Interface "vxlan-ac11000d" type: vxlan options: {df_default="true", in_key=flow, local_ip="172.17.0.11", out_key=flow, remote_ip="172.17.0.13"} Port "vxlan-ac11000e" Interface "vxlan-ac11000e" type: vxlan options: {df_default="true", in_key=flow, local_ip="172.17.0.11", out_key=flow, remote_ip="172.17.0.14"} On Tue, Oct 18, 2016 at 8:50 AM, John Marks > wrote: Doesn't that make the stack very inflexible? And yes, we have faced this issue before and talked to RH about it and they said exactly the same thing. However, if I redeploy, I have found that modifying the network config does not take affect and I have to delete and redeploy the overcloud. That would really reak havoc if I had to do that in production. Thanks for the reply. On Tue, Oct 18, 2016 at 8:43 AM, Boris Derzhavets > wrote: Sorry for typo If I am not correct stating the above, RH's technical stuff will point to my mistake for sure I skipped "if" on first place. ________________________________ From: rdo-list-bounces at redhat.com > on behalf of Boris Derzhavets > Sent: Tuesday, October 18, 2016 4:37 PM To: John Marks; rdo-list at redhat.com Subject: Re: [rdo-list] Adding a vlan to the external network in tripleo I have a lab situation where there are 2 networks. One is in one DMZ and the other is a lab isolated network. I need access to both via the external port. I believe what I need to do is add another port to the bridge on a vlan to the lab network. I created a new external network in Director and assigned the vlan to it. However, I am not sure that will add it to the existing bridge. A bigger question around this is why does Openstack not support modifications after installation to the north/south network? Openstack has no problem with adding one more external network (or even 2) of VLAN type . See for instance https://www.linux.com/blog/rdo-mitaka-several-external-networks-vlan-provider-setup The problem here is the way which was used for deployment, it is TripleO. To have the job done you need to update heat stack "overcloud" which had been built on undercloud Node. So you should be able redeploy overcloud with specific tripleo-heat-template addressing you needs. I would expect your br-ex bridges to have IPs on ctlplane obtained via DHCP. Any manual intervention to overcloud is impossible. You have presumably only one option , which is to ask vendor for support. I am not correct stating the above, RH's technical stuff will point to my mistake for sure. That is why I am so sorry about regression taken place in packstack functionality Boris. East/west is easy but North/South has to have a lot of modifications made to static files (it seems) like plugin.ini and openvswitch.ini. ________________________________ From: rdo-list-bounces at redhat.com > on behalf of John Marks > Sent: Tuesday, October 18, 2016 7:32:53 AM To: rdo-list at redhat.com Subject: [rdo-list] Adding a vlan to the external network in tripleo I have a lab situation where there are 2 networks. One is in one DMZ and the other is a lab isolated network. I need access to both via the external port. I believe what I need to do is add another port to the bridge on a vlan to the lab network. I created a new external network in Director and assigned the vlan to it. However, I am not sure that will add it to the existing bridge. A bigger question around this is why does Openstack not support modifications after installation to the north/south network? East/west is easy but North/South has to have a lot of modifications made to static files (it seems) like plugin.ini and openvswitch.ini. Any help would be appreciated. _______________________________________________ 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 -- [https://0cac57e6-a-62cb3a1a-s-sites.googlegroups.com/site/brandonajames/hot/SUNAYU_LOGO_SIDE%28NO%20TAGLINE%29.jpg?attachauth=ANoY7craA8YrLTT8x3WhaypAtiXvQ0K-_OS2jZLqGIxlVfggNoilgZ0EphWMvnkHuk2FGCoOAjLIdLUOfDaai4Hb33i4FsnL9TXCfSS4WDRCVQVeKFk3qZU226q_8ZQhEYrPX9OR_Bx3eeOB42Qb9fr6qDvqzgSLcbGWpvI_vaAU8ldioT8VmZIwTFZJ84g6PcdXTG-aKTBGCN0xDfScEkqhERAh8lqvHsOua9a6jYjhY49IRhsfGj-_2V5FUz_p4oBpI1B3qjvK&attredirects=0] Brandon James CEO & Founding Member Mobile: 240.476-3922 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdmarks75080 at gmail.com Wed Oct 19 00:45:47 2016 From: jdmarks75080 at gmail.com (John Marks) Date: Tue, 18 Oct 2016 19:45:47 -0500 Subject: [rdo-list] Broken Heat Message-ID: DEBUG (v2) Making authentication request to http://10.1.62.168:5000/v2.0/tokens DEBUG (connectionpool) "POST /v2.0/tokens HTTP/1.1" 200 1056 WARNING (shell) "heat stack-list" is deprecated, please use "openstack stack list" instead DEBUG (session) REQ: curl -g -i -X GET http://10.1.62.168:8004/v1/7975bd079afc4666851dde121efc933f/stacks? -H "User-Agent: python-heatclient" -H "Accept: application/json" -H "X-Auth-Token: {SHA1}1f1eede4c325481f25f2c799276331b3b6eb53fd" INFO (connectionpool) Starting new HTTP connection (1): 10.1.62.168 DEBUG (connectionpool) "GET /v1/7975bd079afc4666851dde121efc933f/stacks HTTP/1.1" 504 None DEBUG (session) RESP: [504] Cache-Control: no-cache Connection: close Content-Type: text/html RESP BODY:

504 Gateway Time-out

The server didn't respond in time. I am getting the above trying to access heat or load a heat template. Neutron and other services work just fine. BTW, I only have a single controller node so I don't see how pacemaker could be an issue. Are there logs I can check? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hrybacki at redhat.com Wed Oct 19 15:39:48 2016 From: hrybacki at redhat.com (Harry Rybacki) Date: Wed, 19 Oct 2016 11:39:48 -0400 Subject: [rdo-list] RDO-Infra Weekly Scrum Recap: Message-ID: Greetings All, Links to the RDO-Infra team's scrum etherpad[1] and video recording[2] of the meeting are below. Highlights: - Plan to unify owner/group of TripleO-Quickstart roles on GerritHub - Discussion around gating/protecting 3rd party projects e.g. Browbeat - Plan to clean up PoC/stale jobs on ci.centos.org - Reminder that the tean will hold retrospectives every two weeks - ci.centos.org OpenStack cloud is up - Summit next week - reminder to review/comment on relevant etherpads[3][4] - Recent accomplishments: - bkero has deployed TripleO with TripelO-Quickstart via nodepool in rdoproject.org[5] - sagi has deployed TripleO with TripleO-Quickstart with OVB in upstream TripleO CI[6] [1] - https://review.rdoproject.org/etherpad/p/rdo-infra-scrum [2] - https://bluejeans.com/s/a5WO/ [3] - https://etherpad.openstack.org/p/ocata-tripleo [4] - https://etherpad.openstack.org/p/ocata-tripleo-ci [5] - https://review.rdoproject.org/jenkins/job/tripleo-quickstart-deploy/68/console [6] - http://logs.openstack.org/94/381094/20/check-tripleo/gate-tripleo-ci-centos-7-ovb-ha/f0ade02/logs/ /R Harry Rybacki From jruzicka at redhat.com Wed Oct 19 15:56:56 2016 From: jruzicka at redhat.com (Jakub Ruzicka) Date: Wed, 19 Oct 2016 17:56:56 +0200 Subject: [rdo-list] [Meeting] RDO meeting (2016-10-19) Minutes Message-ID: <6cc329bc-3734-2625-d607-bd8c47165cf4@redhat.com> ============================== #rdo: RDO meeting - 2016-10-19 ============================== Meeting started by jruzicka at 15:01:04 UTC. The full logs are available at https://meetbot.fedoraproject.org/rdo/2016-10-19/rdo_meeting_-_2016-10-19.2016-10-19-15.01.log.html . Meeting summary --------------- * roll call (jruzicka, 15:01:31) * unresponsive maintainer procedure in case of FTBFS or unreliable upstream release model (jruzicka, 15:05:10) * LINK: https://review.rdoproject.org/r/#/q/topic:rdo-FTBFS (jruzicka, 15:05:35) * LINK: https://review.rdoproject.org/r/#/q/topic:rdo-FTBFS-newton (jruzicka, 15:05:43) * ACTION: apevec to send formal unresponsive procedure proposal to rdo-list (jruzicka, 15:11:47) * Test day stats (jruzicka, 15:12:14) * 4 tickets, 53 IRC participants (jruzicka, 15:12:45) * 1680 messages (roughly twice the chatter as last time, and much of it actually about testing) (jruzicka, 15:12:48) * LINK: http://rdoproject.org/testday/ (jruzicka, 15:12:59) * test day was very encouraging, one of the better testing days (jruzicka, 15:17:00) * next test day will be even better :D (jruzicka, 15:17:15) * We are running a survey on how the community is using RDO (jruzicka, 15:17:36) * LINK: https://goo.gl/forms/ZolZdgrfREHUs3Vt1 (jruzicka, 15:17:48) * aarch64 (jruzicka, 15:20:57) * enabling arch in CBS build targets (jruzicka, 15:22:42) * do not build openstack-tripleo-ui until new order (it will break until bootstrapping is finished) (jruzicka, 15:22:52) * Skip RDO meeting next week yay/nay? (jruzicka, 15:27:17) * LINK: https://www.youtube.com/watch?v=ji-WqEXZRTY (rbowen, 15:27:46) * Next week's meeting is Tuesday evening in Barcelona, and will be streamed https://www.youtube.com/watch?v=ji-WqEXZRTY (apevec, 15:29:05) * we aim at 500% improvement (jruzicka, 15:32:41) * Announcements (jruzicka, 15:33:38) * LINK: https://etherpad.openstack.org/p/rdo-barcelona-summit-booth (rbowen, 15:33:54) * LINK: https://etherpad.openstack.org/p/rdo-barcelona-summit-booth (rbowen, 15:36:51) * ACTION: everyone signup your slots in https://etherpad.openstack.org/p/rdo-barcelona-summit-booth (apevec, 15:37:16) * rodpkg-0.41 release right now (jruzicka, 15:41:31) * open floor (jruzicka, 15:44:04) * next chair (jruzicka, 15:51:47) * rbowen because we meet in Barcelona (jruzicka, 15:51:57) Meeting ended at 15:52:23 UTC. Action Items ------------ * apevec to send formal unresponsive procedure proposal to rdo-list * everyone signup your slots in https://etherpad.openstack.org/p/rdo-barcelona-summit-booth Action Items, by person ----------------------- * apevec * apevec to send formal unresponsive procedure proposal to rdo-list * **UNASSIGNED** * everyone signup your slots in https://etherpad.openstack.org/p/rdo-barcelona-summit-booth People Present (lines said) --------------------------- * jruzicka (66) * rbowen (51) * apevec (35) * dmsimard (30) * number80 (12) * trown (9) * zodbot (7) * jpena (7) * rdogerrit (5) * dmellado (4) * amoralej (4) * misc (2) * chandankumar (2) * remix_tj (2) * mengxd (1) * myoung (1) * jjoyce (1) * flepied (1) * jschlueter (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot From hguemar at fedoraproject.org Wed Oct 19 21:28:15 2016 From: hguemar at fedoraproject.org (=?UTF-8?Q?Ha=C3=AFkel?=) Date: Wed, 19 Oct 2016 23:28:15 +0200 Subject: [rdo-list] [Cloud SIG] Aarch64 bootstrap status Message-ID: Hi, Many thanks to Thomas who spent his evening merging aarch64 builds (and Fabian for enabling the arch in our CBS tags!) Here's a summary of the bootstrap: https://review.rdoproject.org/etherpad/p/aarch64-bootstrap-current-status Erlang and texlive are still building, but the biggest remaining chunk will be building v8 on aarch64 (and node.js) but overall we're good. Next steps will be fixing broken builds and proper testing on real hardware. Regards, H. From marcin.juszkiewicz at linaro.org Thu Oct 20 07:37:42 2016 From: marcin.juszkiewicz at linaro.org (Marcin Juszkiewicz) Date: Thu, 20 Oct 2016 09:37:42 +0200 Subject: [rdo-list] [CentOS-devel] [Cloud SIG] Aarch64 bootstrap status In-Reply-To: References: Message-ID: <10bd8968-4a48-e865-d13c-09f1ad1db73d@linaro.org> W dniu 19.10.2016 o 23:28, Ha?kel pisze: > Hi, > > Many thanks to Thomas who spent his evening merging aarch64 builds > (and Fabian for enabling the arch in our CBS tags!) > Here's a summary of the bootstrap: > https://review.rdoproject.org/etherpad/p/aarch64-bootstrap-current-status Nice progress! > Erlang and texlive are still building, but the biggest remaining chunk > will be building v8 on aarch64 (and node.js) but overall we're good. MongoDB older than 3.2 would not build on aarch64. And this was main user of v8. Nodejs 4.x should build - ships own copy of v8. > Next steps will be fixing broken builds and proper testing on real hardware. From mengxiandong at gmail.com Fri Oct 21 12:33:20 2016 From: mengxiandong at gmail.com (Xiandong Meng) Date: Fri, 21 Oct 2016 20:33:20 +0800 Subject: [rdo-list] [CentOS-devel] [Cloud SIG] Aarch64 bootstrap status In-Reply-To: <10bd8968-4a48-e865-d13c-09f1ad1db73d@linaro.org> References: <10bd8968-4a48-e865-d13c-09f1ad1db73d@linaro.org> Message-ID: Yes, And based on my experience, MongoDB 3.2.x has a dependency on higher version of boost libraries than the centos 7.x default (1.52). This is another challenge. Regards, Alex Meng mengxiandong at gmail.com On Thu, Oct 20, 2016 at 3:37 PM, Marcin Juszkiewicz < marcin.juszkiewicz at linaro.org> wrote: > W dniu 19.10.2016 o 23:28, Ha?kel pisze: > > Hi, > > > > Many thanks to Thomas who spent his evening merging aarch64 builds > > (and Fabian for enabling the arch in our CBS tags!) > > Here's a summary of the bootstrap: > > https://review.rdoproject.org/etherpad/p/aarch64-bootstrap- > current-status > > Nice progress! > > > Erlang and texlive are still building, but the biggest remaining chunk > > will be building v8 on aarch64 (and node.js) but overall we're good. > > MongoDB older than 3.2 would not build on aarch64. And this was main > user of v8. Nodejs 4.x should build - ships own copy of v8. > > > Next steps will be fixing broken builds and proper testing on real > hardware. > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > https://lists.centos.org/mailman/listinfo/centos-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbowen at redhat.com Sun Oct 23 07:56:51 2016 From: rbowen at redhat.com (Rich Bowen) Date: Sun, 23 Oct 2016 03:56:51 -0400 Subject: [rdo-list] Fwd: CfP Announcement: Virtualization and IaaS Devroom In-Reply-To: References: Message-ID: Here's the more formal announcement with more details. ---------- Forwarded message ---------- From: "Brian Proffitt" Date: Oct 21, 2016 21:24 Subject: CfP Announcement: Virtualization and IaaS Devroom To: , Cc: On behalf of oVirt and the Xen Project, we are excited to announce that the call for proposals is now open for the Virtualization & IaaS devroom at the upcoming FOSDEM 2017, to be hosted on February 4, 2017. This year will mark FOSDEM?s 17th anniversary as one of the longest-running free and open source software developer events, attracting thousands of developers and users from all over the world. FOSDEM will be held once again in Brussels, Belgium, on February 4 & 5, 2017. This devroom is a collaborative effort, and is organized by dedicated folks from projects such as OpenStack, Xen Project, Mesos, oVirt, and Foreman. We would like to invite all those who are involved in these fields to submit your proposals by November 18th, 2016. About the Devroom The Virtualization & IaaS devroom will feature session topics such as open source hypervisors and virtual machine managers such as Xen Project, KVM, bhyve, and VirtualBox, and Infrastructure-as-a-Service projects such as Apache CloudStack, OpenStack, oVirt, OpenNebula, and Ganeti. This devroom will host presentations that focus on topics of shared interest, such as KVM; libvirt; shared storage; virtualized networking; cloud security; clustering and high availability; interfacing with multiple hypervisors; hyperconverged deployments; and scaling across hundreds or thousands of servers. Presentations in this devroom will be aimed at developers working on these platforms who are looking to collaborate and improve shared infrastructure or solve common problems. We seek topics that encourage dialog between projects and continued work post-FOSDEM. Important Dates Submission deadline: 18 November 2016 Acceptance notifications: 04 December 2016 Final schedule announcement: 11 December 2016 Devroom: 04 February 2017 (one day) Submit Your Proposal All submissions must be made via the Pentabarf event planning site[1]. If you have not used Pentabarf before, you will need to create an account. If you submitted proposals for FOSDEM in previous years, you can use your existing account. After creating the account, select Create Event to start the submission process. Make sure to select Virtualisation and IaaS devroom from the Track list. Please fill out all the required fields, and provide a meaningful abstract and description of your proposed session. Submission Guidelines We expect more proposals than we can possibly accept, so it is vitally important that you submit your proposal on or before the deadline. Late submissions are unlikely to be considered. All presentation slots are 45 minutes, with 35 minutes planned for presentations, and 10 minutes for Q&A. All presentations will be recorded and made available under Creative Commons licenses. In the Submission notes field, please indicate that you agree that your presentation will be licensed under the CC-By-SA-4.0 or CC-By-4.0 license and that you agree to have your presentation recorded. For example: "If my presentation is accepted for FOSDEM, I hereby agree to license all recordings, slides, and other associated materials under the Creative Commons Attribution Share-Alike 4.0 International License. Sincerely, ." In the Submission notes field, please also confirm that if your talk is accepted, you will be able to attend FOSDEM and deliver your presentation. We will not consider proposals from prospective speakers who are unsure whether they will be able to secure funds for travel and lodging to attend FOSDEM. (Sadly, we are not able to offer travel funding for prospective speakers.) Speaker Mentoring Program As a part of the rising efforts to grow our communities and encourage a diverse and inclusive conference ecosystem, we're happy to announce that we'll be offering mentoring for new speakers. Our mentors can help you with tasks such as reviewing your abstract, reviewing your presentation outline or slides, or practicing your talk with you. You may apply to the mentoring program as a newcomer speaker if you: Never presented before or Presented only lightning talks or Presented full-length talks at small meetups (<50 ppl) Submission Guidelines Mentored presentations will have 25-minute slots, where 20 minutes will include the presentation and 5 minutes will be reserved for questions. The number of newcomer session slots is limited, so we will probably not be able to accept all applications. You must submit your talk and abstract to apply for the mentoring program, our mentors are volunteering their time and will happily provide feedback but won't write your presentation for you! If you are experiencing problems with Pentabarf, the proposal submission interface, or have other questions, you can email our devroom mailing list[2] and we will try to help you. How to Apply In addition to agreeing to video recording and confirming that you can attend FOSDEM in case your session is accepted, please write "speaker mentoring program application" in the "Submission notes" field, and list any prior speaking experience or other relevant information for your application. Call for Mentors Interested in mentoring newcomer speakers? We'd love to have your help! Please email iaas-virt-devroom at lists.fosdem.org with a short speaker biography and any specific fields of expertise (for example, KVM, OpenStack, storage, etc.) so that we can match you with a newcomer speaker from a similar field. Estimated time investment can be as low as a 5-10 hours in total, usually distributed weekly or bi-weekly. Never mentored a newcomer speaker but interested to try? As the mentoring program coordinator, I will be happy to answer your questions and give you tips on how to optimize the mentoring process. Email Brian Proffitt[3] and he will be happy to answer your questions! Code of Conduct Following the release of the updated code of conduct for FOSDEM, we'd like to remind all speakers and attendees that all of the presentations and discussions in our devroom are held under the guidelines set in the CoC and we expect attendees, speakers, and volunteers to follow the CoC at all times. If you submit a proposal and it is accepted, you will be required to confirm that you accept the FOSDEM CoC. If you have any questions about the CoC or wish to have one of the devroom organizers review your presentation slides or any other content for CoC compliance, please email us and we will do our best to assist you. Call for Volunteers We are also looking for volunteers to help run the devroom. We need assistance watching time for the speakers, and helping with video for the devroom. Please contact me, Brian Proffitt, for more information. Questions? If you have any questions about this devroom, please send your questions to our devroom mailing list. You can also subscribe to the list to receive updates about important dates, session announcements, and to connect with other attendees. See you all at FOSDEM! [1] https://penta.fosdem.org/submission/FOSDEM17 [2] iaas-virt-devroom at lists.fosdem.org [3] bkp at redhat.com -- Brian Proffitt Principal Community Analyst Open Source and Standards @TheTechScribe 574.383.9BKP _______________________________________________ iaas-virt-devroom mailing list iaas-virt-devroom at lists.fosdem.org https://lists.fosdem.org/listinfo/iaas-virt-devroom -------------- next part -------------- An HTML attachment was scrubbed... URL: From alv2412 at googlemail.com Sun Oct 23 19:09:33 2016 From: alv2412 at googlemail.com (Alvaro Aleman) Date: Sun, 23 Oct 2016 21:09:33 +0200 Subject: [rdo-list] State of OVN in RDO? Message-ID: Hello, The docs for networking-ovn[1] suggest there is a package named ' openvswitch-ovn' for ovn in CentOS which I can not find in either Newton or Mitaka. Can anyone tell me about the current state of OVN in RDO? Regards Alvaro Aleman [1]http://docs.openstack.org/developer/networking-ovn/install.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From hguemar at fedoraproject.org Mon Oct 24 15:00:07 2016 From: hguemar at fedoraproject.org (hguemar at fedoraproject.org) Date: Mon, 24 Oct 2016 15:00:07 +0000 (UTC) Subject: [rdo-list] [Fedocal] Reminder meeting : RDO meeting Message-ID: <20161024150007.4733860A3FDC@fedocal02.phx2.fedoraproject.org> Dear all, You are kindly invited to the meeting: RDO meeting on 2016-10-26 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 apevec at redhat.com Mon Oct 24 16:01:20 2016 From: apevec at redhat.com (Alan Pevec) Date: Mon, 24 Oct 2016 18:01:20 +0200 Subject: [rdo-list] [Fedocal] Reminder meeting : RDO meeting In-Reply-To: <20161024150007.4733860A3FDC@fedocal02.phx2.fedoraproject.org> References: <20161024150007.4733860A3FDC@fedocal02.phx2.fedoraproject.org> Message-ID: As discussed at the meeting last week, instead of regular Wednesday IRC meeting we will have live streaming from meetup on Tuesday https://etherpad.openstack.org/p/rdo-barcelona-meetup-schedule Cheers, Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From madko77 at gmail.com Mon Oct 24 16:57:30 2016 From: madko77 at gmail.com (Madko) Date: Mon, 24 Oct 2016 16:57:30 +0000 Subject: [rdo-list] State of OVN in RDO? In-Reply-To: References: Message-ID: Same question here. Is there openvswitch 2.6 in the repositories? Best regards, Edouard Le dim. 23 oct. 2016 21:10, Alvaro Aleman a ?crit : Hello, The docs for networking-ovn[1] suggest there is a package named ' openvswitch-ovn' for ovn in CentOS which I can not find in either Newton or Mitaka. Can anyone tell me about the current state of OVN in RDO? Regards Alvaro Aleman [1]http://docs.openstack.org/developer/networking-ovn/install.html _______________________________________________ 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 rbryant at redhat.com Tue Oct 25 15:16:52 2016 From: rbryant at redhat.com (Russell Bryant) Date: Tue, 25 Oct 2016 11:16:52 -0400 Subject: [rdo-list] State of OVN in RDO? In-Reply-To: References: Message-ID: OVS 2.6 and OVN are not packaged in RDO at this time. Your best bet is to get it from COPR. We've been using: https://copr.fedorainfracloud.org/coprs/leifmadsen/ovs-master/ This is actually based on OVS master, but that's not too far off from OVS 2.6 at this point. On Mon, Oct 24, 2016 at 12:57 PM, Madko wrote: > Same question here. Is there openvswitch 2.6 in the repositories? > > Best regards, > Edouard > > Le dim. 23 oct. 2016 21:10, Alvaro Aleman a > ?crit : > > Hello, > > The docs for networking-ovn[1] suggest there is a package named ' openvswitch-ovn' > for ovn in CentOS which I can not find in either Newton or Mitaka. > > Can anyone tell me about the current state of OVN in RDO? > > Regards > Alvaro Aleman > > > [1]http://docs.openstack.org/developer/networking-ovn/install.html > > > _______________________________________________ > 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 > -- Russell Bryant -------------- next part -------------- An HTML attachment was scrubbed... URL: From madko77 at gmail.com Tue Oct 25 15:44:00 2016 From: madko77 at gmail.com (Madko) Date: Tue, 25 Oct 2016 15:44:00 +0000 Subject: [rdo-list] State of OVN in RDO? In-Reply-To: References: Message-ID: How about neutron support ? Is there a driver for OVN ? is that ready for production ? Le mar. 25 oct. 2016 ? 17:17, Russell Bryant a ?crit : > OVS 2.6 and OVN are not packaged in RDO at this time. Your best bet is to > get it from COPR. We've been using: > > https://copr.fedorainfracloud.org/coprs/leifmadsen/ovs-master/ > > This is actually based on OVS master, but that's not too far off from OVS > 2.6 at this point. > > On Mon, Oct 24, 2016 at 12:57 PM, Madko wrote: > > Same question here. Is there openvswitch 2.6 in the repositories? > > Best regards, > Edouard > > Le dim. 23 oct. 2016 21:10, Alvaro Aleman a > ?crit : > > Hello, > > The docs for networking-ovn[1] suggest there is a package named ' openvswitch-ovn' > for ovn in CentOS which I can not find in either Newton or Mitaka. > > Can anyone tell me about the current state of OVN in RDO? > > Regards > Alvaro Aleman > > > [1]http://docs.openstack.org/developer/networking-ovn/install.html > > > _______________________________________________ > 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 > > > > > -- > Russell Bryant > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbryant at redhat.com Tue Oct 25 15:54:55 2016 From: rbryant at redhat.com (Russell Bryant) Date: Tue, 25 Oct 2016 11:54:55 -0400 Subject: [rdo-list] State of OVN in RDO? In-Reply-To: References: Message-ID: The Neutron driver is "networking-ovn". That is packaged in RDO. We feel that it's ready for early production usage as of OVS 2.6 and OpenStack Newton. I would say that anyone using it is still an early adopter though, since this is effectively our "1.0". There is early TripleO support merged, but after testing in the last week, it seems we may have some issues to fix. On Tue, Oct 25, 2016 at 11:44 AM, Madko wrote: > How about neutron support ? Is there a driver for OVN ? is that ready for > production ? > > Le mar. 25 oct. 2016 ? 17:17, Russell Bryant a > ?crit : > >> OVS 2.6 and OVN are not packaged in RDO at this time. Your best bet is >> to get it from COPR. We've been using: >> >> https://copr.fedorainfracloud.org/coprs/leifmadsen/ovs-master/ >> >> This is actually based on OVS master, but that's not too far off from OVS >> 2.6 at this point. >> >> On Mon, Oct 24, 2016 at 12:57 PM, Madko wrote: >> >> Same question here. Is there openvswitch 2.6 in the repositories? >> >> Best regards, >> Edouard >> >> Le dim. 23 oct. 2016 21:10, Alvaro Aleman a >> ?crit : >> >> Hello, >> >> The docs for networking-ovn[1] suggest there is a package named ' openvswitch-ovn' >> for ovn in CentOS which I can not find in either Newton or Mitaka. >> >> Can anyone tell me about the current state of OVN in RDO? >> >> Regards >> Alvaro Aleman >> >> >> [1]http://docs.openstack.org/developer/networking-ovn/install.html >> >> >> _______________________________________________ >> 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 >> >> >> >> >> -- >> Russell Bryant >> > -- Russell Bryant -------------- next part -------------- An HTML attachment was scrubbed... URL: From lorenzetto.luca at gmail.com Wed Oct 26 06:18:57 2016 From: lorenzetto.luca at gmail.com (Luca 'remix_tj' Lorenzetto) Date: Wed, 26 Oct 2016 08:18:57 +0200 Subject: [rdo-list] Fwd: An Evening of Ceph and RDO (schedule) In-Reply-To: <58b5a2b7-604a-5dbc-2e22-4e663045eaa8@redhat.com> References: <0bf6fb47-618b-a850-d8ca-31f68a53bb0e@redhat.com> <58b5a2b7-604a-5dbc-2e22-4e663045eaa8@redhat.com> Message-ID: On Mon, Oct 17, 2016 at 3:32 PM, Rich Bowen wrote: > Don't worry, you won't be turned away at the door. True :-) It has been a very nice meeting. I would like to congratulate with everyone has contributed and in particular with Patrick and Rich for the organization. It has been a great opportinity for me, which i'm new, to get in touch with the community and with the people that helped me with openstack (and that I'm glad to "help" with my long-running test days). Luca -- "E' assurdo impiegare gli uomini di intelligenza eccellente per fare calcoli che potrebbero essere affidati a chiunque se si usassero delle macchine" Gottfried Wilhelm von Leibnitz, Filosofo e Matematico (1646-1716) "Internet ? la pi? grande biblioteca del mondo. Ma il problema ? che i libri sono tutti sparsi sul pavimento" John Allen Paulos, Matematico (1945-vivente) Luca 'remix_tj' Lorenzetto, http://www.remixtj.net , From me at gbraad.nl Wed Oct 26 06:37:55 2016 From: me at gbraad.nl (Gerard Braad) Date: Wed, 26 Oct 2016 14:37:55 +0800 Subject: [rdo-list] Fwd: An Evening of Ceph and RDO (schedule) In-Reply-To: <0bf6fb47-618b-a850-d8ca-31f68a53bb0e@redhat.com> References: <0bf6fb47-618b-a850-d8ca-31f68a53bb0e@redhat.com> Message-ID: Hi All, On Fri, Oct 14, 2016 at 2:30 AM, Rich Bowen wrote: > These are all 5-10m lightning talks. Let me know if there are any > questions. Thanks! Were these talks recorded? Regards, Gerard -- Gerard Braad | http://gbraad.nl [ Doing Open Source Matters ] From whayutin at redhat.com Wed Oct 26 06:55:51 2016 From: whayutin at redhat.com (Wesley Hayutin) Date: Wed, 26 Oct 2016 02:55:51 -0400 Subject: [rdo-list] [Fedocal] Reminder meeting : RDO meeting In-Reply-To: References: <20161024150007.4733860A3FDC@fedocal02.phx2.fedoraproject.org> Message-ID: Thanks for planning the event last night, it was a geat success and I personally had a great time! Congrats to all the speakers, well done! Thanks! On Mon, Oct 24, 2016 at 12:01 PM, Alan Pevec wrote: > As discussed at the meeting last week, instead of regular Wednesday IRC > meeting we will have live streaming from meetup on Tuesday > https://etherpad.openstack.org/p/rdo-barcelona-meetup-schedule > > Cheers, > Alan > > _______________________________________________ > 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 madko77 at gmail.com Wed Oct 26 09:01:53 2016 From: madko77 at gmail.com (Madko) Date: Wed, 26 Oct 2016 09:01:53 +0000 Subject: [rdo-list] Langage env bug in ovs neutron agent for openvswitch Message-ID: Hi, with newton, manually installed, when I start the neutron agent for openvswitch (on network node and/or compute nodes), the service fails, only saying "uncaught exception". We spent weeks to diagnos this problem. yes weeks... If I override LANG to C in systemd unit files it works !!! Seems a subcommand in some python librairies is waiting for "Exit code" in stdout, but on my system we have "Code de sortie" instead (french here). Is that a known bug ? Best regards, Edouard -------------- next part -------------- An HTML attachment was scrubbed... URL: From lorenzetto.luca at gmail.com Wed Oct 26 09:22:33 2016 From: lorenzetto.luca at gmail.com (Luca 'remix_tj' Lorenzetto) Date: Wed, 26 Oct 2016 11:22:33 +0200 Subject: [rdo-list] Langage env bug in ovs neutron agent for openvswitch In-Reply-To: References: Message-ID: On Wed, Oct 26, 2016 at 11:01 AM, Madko wrote: > Hi, > > with newton, manually installed, when I start the neutron agent for > openvswitch (on network node and/or compute nodes), the service fails, only > saying "uncaught exception". > We spent weeks to diagnos this problem. yes weeks... > > If I override LANG to C in systemd unit files it works !!! > > Seems a subcommand in some python librairies is waiting for "Exit code" in > stdout, but on my system we have "Code de sortie" instead (french here). Is > that a known bug ? Hello, which systemd unit file are you referring to? From which package? Luca -- "E' assurdo impiegare gli uomini di intelligenza eccellente per fare calcoli che potrebbero essere affidati a chiunque se si usassero delle macchine" Gottfried Wilhelm von Leibnitz, Filosofo e Matematico (1646-1716) "Internet ? la pi? grande biblioteca del mondo. Ma il problema ? che i libri sono tutti sparsi sul pavimento" John Allen Paulos, Matematico (1945-vivente) Luca 'remix_tj' Lorenzetto, http://www.remixtj.net , From madko77 at gmail.com Wed Oct 26 09:29:54 2016 From: madko77 at gmail.com (Madko) Date: Wed, 26 Oct 2016 09:29:54 +0000 Subject: [rdo-list] Langage env bug in ovs neutron agent for openvswitch In-Reply-To: References: Message-ID: Hi Luca, The service file from openstack-neutron-openvswitch-9.0.0-1.el7.noarch, by doing a systemctl edit neutron-openvswitch-agent Also switching the whole system to LANG=en_US.UTF-8 works too. Le mer. 26 oct. 2016 ? 11:22, Luca 'remix_tj' Lorenzetto < lorenzetto.luca at gmail.com> a ?crit : > On Wed, Oct 26, 2016 at 11:01 AM, Madko wrote: > > Hi, > > > > with newton, manually installed, when I start the neutron agent for > > openvswitch (on network node and/or compute nodes), the service fails, > only > > saying "uncaught exception". > > We spent weeks to diagnos this problem. yes weeks... > > > > If I override LANG to C in systemd unit files it works !!! > > > > Seems a subcommand in some python librairies is waiting for "Exit code" > in > > stdout, but on my system we have "Code de sortie" instead (french here). > Is > > that a known bug ? > > Hello, > > which systemd unit file are you referring to? From which package? > > Luca > > -- > "E' assurdo impiegare gli uomini di intelligenza eccellente per fare > calcoli che potrebbero essere affidati a chiunque se si usassero delle > macchine" > Gottfried Wilhelm von Leibnitz, Filosofo e Matematico (1646-1716) > > "Internet ? la pi? grande biblioteca del mondo. > Ma il problema ? che i libri sono tutti sparsi sul pavimento" > John Allen Paulos, Matematico (1945-vivente) > > Luca 'remix_tj' Lorenzetto, http://www.remixtj.net , < > lorenzetto.luca at gmail.com> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lorenzetto.luca at gmail.com Wed Oct 26 09:47:42 2016 From: lorenzetto.luca at gmail.com (Luca 'remix_tj' Lorenzetto) Date: Wed, 26 Oct 2016 11:47:42 +0200 Subject: [rdo-list] Langage env bug in ovs neutron agent for openvswitch In-Reply-To: References: Message-ID: Hello, do you have any python traceback to identify better the issue? I found an entry that may be doing what you did, but i need confirmations. You can maybe find it through journalctl. Luca On Wed, Oct 26, 2016 at 11:29 AM, Madko wrote: > Hi Luca, > > The service file from openstack-neutron-openvswitch-9.0.0-1.el7.noarch, by > doing a systemctl edit neutron-openvswitch-agent > Also switching the whole system to LANG=en_US.UTF-8 works too. > > Le mer. 26 oct. 2016 ? 11:22, Luca 'remix_tj' Lorenzetto > a ?crit : >> >> On Wed, Oct 26, 2016 at 11:01 AM, Madko wrote: >> > Hi, >> > >> > with newton, manually installed, when I start the neutron agent for >> > openvswitch (on network node and/or compute nodes), the service fails, >> > only >> > saying "uncaught exception". >> > We spent weeks to diagnos this problem. yes weeks... >> > >> > If I override LANG to C in systemd unit files it works !!! >> > >> > Seems a subcommand in some python librairies is waiting for "Exit code" >> > in >> > stdout, but on my system we have "Code de sortie" instead (french here). >> > Is >> > that a known bug ? >> >> Hello, >> >> which systemd unit file are you referring to? From which package? >> >> Luca >> >> -- >> "E' assurdo impiegare gli uomini di intelligenza eccellente per fare >> calcoli che potrebbero essere affidati a chiunque se si usassero delle >> macchine" >> Gottfried Wilhelm von Leibnitz, Filosofo e Matematico (1646-1716) >> >> "Internet ? la pi? grande biblioteca del mondo. >> Ma il problema ? che i libri sono tutti sparsi sul pavimento" >> John Allen Paulos, Matematico (1945-vivente) >> >> Luca 'remix_tj' Lorenzetto, http://www.remixtj.net , >> -- "E' assurdo impiegare gli uomini di intelligenza eccellente per fare calcoli che potrebbero essere affidati a chiunque se si usassero delle macchine" Gottfried Wilhelm von Leibnitz, Filosofo e Matematico (1646-1716) "Internet ? la pi? grande biblioteca del mondo. Ma il problema ? che i libri sono tutti sparsi sul pavimento" John Allen Paulos, Matematico (1945-vivente) Luca 'remix_tj' Lorenzetto, http://www.remixtj.net , From madko77 at gmail.com Wed Oct 26 10:00:50 2016 From: madko77 at gmail.com (Madko) Date: Wed, 26 Oct 2016 10:00:50 +0000 Subject: [rdo-list] Langage env bug in ovs neutron agent for openvswitch In-Reply-To: References: Message-ID: Yes I do have a traceback, cf attached log file. Le mer. 26 oct. 2016 ? 11:47, Luca 'remix_tj' Lorenzetto < lorenzetto.luca at gmail.com> a ?crit : > Hello, > > do you have any python traceback to identify better the issue? I found > an entry that may be doing what you did, but i need confirmations. > > You can maybe find it through journalctl. > > Luca > > On Wed, Oct 26, 2016 at 11:29 AM, Madko wrote: > > Hi Luca, > > > > The service file from openstack-neutron-openvswitch-9.0.0-1.el7.noarch, > by > > doing a systemctl edit neutron-openvswitch-agent > > Also switching the whole system to LANG=en_US.UTF-8 works too. > > > > Le mer. 26 oct. 2016 ? 11:22, Luca 'remix_tj' Lorenzetto > > a ?crit : > >> > >> On Wed, Oct 26, 2016 at 11:01 AM, Madko wrote: > >> > Hi, > >> > > >> > with newton, manually installed, when I start the neutron agent for > >> > openvswitch (on network node and/or compute nodes), the service fails, > >> > only > >> > saying "uncaught exception". > >> > We spent weeks to diagnos this problem. yes weeks... > >> > > >> > If I override LANG to C in systemd unit files it works !!! > >> > > >> > Seems a subcommand in some python librairies is waiting for "Exit > code" > >> > in > >> > stdout, but on my system we have "Code de sortie" instead (french > here). > >> > Is > >> > that a known bug ? > >> > >> Hello, > >> > >> which systemd unit file are you referring to? From which package? > >> > >> Luca > >> > >> -- > >> "E' assurdo impiegare gli uomini di intelligenza eccellente per fare > >> calcoli che potrebbero essere affidati a chiunque se si usassero delle > >> macchine" > >> Gottfried Wilhelm von Leibnitz, Filosofo e Matematico (1646-1716) > >> > >> "Internet ? la pi? grande biblioteca del mondo. > >> Ma il problema ? che i libri sono tutti sparsi sul pavimento" > >> John Allen Paulos, Matematico (1945-vivente) > >> > >> Luca 'remix_tj' Lorenzetto, http://www.remixtj.net , > >> > > > > -- > "E' assurdo impiegare gli uomini di intelligenza eccellente per fare > calcoli che potrebbero essere affidati a chiunque se si usassero delle > macchine" > Gottfried Wilhelm von Leibnitz, Filosofo e Matematico (1646-1716) > > "Internet ? la pi? grande biblioteca del mondo. > Ma il problema ? che i libri sono tutti sparsi sul pavimento" > John Allen Paulos, Matematico (1945-vivente) > > Luca 'remix_tj' Lorenzetto, http://www.remixtj.net , < > lorenzetto.luca at gmail.com> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ovs.log Type: text/x-log Size: 3612 bytes Desc: not available URL: From lorenzetto.luca at gmail.com Wed Oct 26 10:18:36 2016 From: lorenzetto.luca at gmail.com (Luca 'remix_tj' Lorenzetto) Date: Wed, 26 Oct 2016 12:18:36 +0200 Subject: [rdo-list] Langage env bug in ovs neutron agent for openvswitch In-Reply-To: References: Message-ID: On Wed, Oct 26, 2016 at 12:00 PM, Madko wrote: > Yes I do have a traceback, cf attached log file. > I'm not sure is a problem the text appearing in french, since is traslated through the _ function. In my opinion is the ps command failing (return code is 1). -- "E' assurdo impiegare gli uomini di intelligenza eccellente per fare calcoli che potrebbero essere affidati a chiunque se si usassero delle macchine" Gottfried Wilhelm von Leibnitz, Filosofo e Matematico (1646-1716) "Internet ? la pi? grande biblioteca del mondo. Ma il problema ? che i libri sono tutti sparsi sul pavimento" John Allen Paulos, Matematico (1945-vivente) Luca 'remix_tj' Lorenzetto, http://www.remixtj.net , From madko77 at gmail.com Wed Oct 26 11:36:44 2016 From: madko77 at gmail.com (Madko) Date: Wed, 26 Oct 2016 11:36:44 +0000 Subject: [rdo-list] Langage env bug in ovs neutron agent for openvswitch In-Reply-To: References: Message-ID: is that possible that the ps returns a different code depending of the LANG ? I don't understand why it would be failing if the LANG is changed. Do you know the exact ps command ? Le mer. 26 oct. 2016 ? 12:18, Luca 'remix_tj' Lorenzetto < lorenzetto.luca at gmail.com> a ?crit : > On Wed, Oct 26, 2016 at 12:00 PM, Madko wrote: > > Yes I do have a traceback, cf attached log file. > > > > I'm not sure is a problem the text appearing in french, since is > traslated through the _ function. In my opinion is the ps command > failing (return code is 1). > > -- > "E' assurdo impiegare gli uomini di intelligenza eccellente per fare > calcoli che potrebbero essere affidati a chiunque se si usassero delle > macchine" > Gottfried Wilhelm von Leibnitz, Filosofo e Matematico (1646-1716) > > "Internet ? la pi? grande biblioteca del mondo. > Ma il problema ? che i libri sono tutti sparsi sul pavimento" > John Allen Paulos, Matematico (1945-vivente) > > Luca 'remix_tj' Lorenzetto, http://www.remixtj.net , < > lorenzetto.luca at gmail.com> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brault at redhat.com Wed Oct 26 12:12:58 2016 From: brault at redhat.com (Bertrand Rault) Date: Wed, 26 Oct 2016 08:12:58 -0400 (EDT) Subject: [rdo-list] [Fedocal] Reminder meeting : RDO meeting In-Reply-To: References: <20161024150007.4733860A3FDC@fedocal02.phx2.fedoraproject.org> Message-ID: <346499725.29902476.1477483978737.JavaMail.zimbra@redhat.com> Indeed, thank you very much for the party and the presentations! Is there a compile list URLs where we can revisit what was presented when it comes to Cephs and RDO. Thanks, Bertrand ----- Original Message ----- From: "Wesley Hayutin" To: "Alan Pevec" , "Rich Bowen" Cc: "Rdo-list at redhat.com" Sent: Wednesday, October 26, 2016 8:55:51 AM Subject: Re: [rdo-list] [Fedocal] Reminder meeting : RDO meeting Thanks for planning the event last night, it was a geat success and I personally had a great time! Congrats to all the speakers, well done! Thanks! On Mon, Oct 24, 2016 at 12:01 PM, Alan Pevec < apevec at redhat.com > wrote: As discussed at the meeting last week, instead of regular Wednesday IRC meeting we will have live streaming from meetup on Tuesday https://etherpad.openstack.org/p/rdo-barcelona-meetup-schedule Cheers, Alan _______________________________________________ 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 -- Bertrand Rault Red Hat, Inc. NFV EPM Engineering Partner Management Platform Business Unit bertrand at redhat.com +1 972 892 4514 (Office) +33 07 50 65 55 30 (Mobile) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbowen at redhat.com Wed Oct 26 12:16:16 2016 From: rbowen at redhat.com (Rich Bowen) Date: Wed, 26 Oct 2016 14:16:16 +0200 Subject: [rdo-list] [Fedocal] Reminder meeting : RDO meeting In-Reply-To: <346499725.29902476.1477483978737.JavaMail.zimbra@redhat.com> References: <20161024150007.4733860A3FDC@fedocal02.phx2.fedoraproject.org> <346499725.29902476.1477483978737.JavaMail.zimbra@redhat.com> Message-ID: <660d125f-fe36-3c17-8a50-4e04ba259f7d@redhat.com> Yes, I'm working on gathering all of the presentations/slides/URLs from the event, and will have those to the list ASAP. Also, due to technical difficulties I did *not* stream the event. However, I did record it. I have not yet had a chance to review the recording, so I don't know if the quality is very good, but I should be sharing this soon, also. --Rich On 10/26/2016 02:12 PM, Bertrand Rault wrote: > Indeed, thank you very much for the party and the presentations! > Is there a compile list URLs where we can revisit what was presented > when it comes to Cephs and RDO. > > Thanks, > > Bertrand > > > > ------------------------------------------------------------------------ > *From: *"Wesley Hayutin" > *To: *"Alan Pevec" , "Rich Bowen" > *Cc: *"Rdo-list at redhat.com" > *Sent: *Wednesday, October 26, 2016 8:55:51 AM > *Subject: *Re: [rdo-list] [Fedocal] Reminder meeting : RDO meeting > > Thanks for planning the event last night, it was a geat success and I > personally had a great time! > Congrats to all the speakers, well done! > > Thanks! > > > On Mon, Oct 24, 2016 at 12:01 PM, Alan Pevec > wrote: > > As discussed at the meeting last week, instead of regular Wednesday > IRC meeting we will have live streaming from meetup on Tuesday > https://etherpad.openstack.org/p/rdo-barcelona-meetup-schedule > > Cheers, > Alan > > > _______________________________________________ > 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 > > > > -- > Bertrand Rault > Red Hat, Inc. > NFV EPM > Engineering Partner Management > Platform Business Unit > bertrand at redhat.com > +1 972 892 4514 (Office) > +33 07 50 65 55 30 (Mobile) > > > -- Rich Bowen - rbowen at redhat.com RDO Community Liaison http://rdoproject.org @RDOCommunity From lorenzetto.luca at gmail.com Wed Oct 26 12:20:38 2016 From: lorenzetto.luca at gmail.com (Luca 'remix_tj' Lorenzetto) Date: Wed, 26 Oct 2016 14:20:38 +0200 Subject: [rdo-list] Langage env bug in ovs neutron agent for openvswitch In-Reply-To: References: Message-ID: On Wed, Oct 26, 2016 at 1:36 PM, Madko wrote: > is that possible that the ps returns a different code depending of the LANG > ? I don't understand why it would be failing if the LANG is changed. Do you > know the exact ps command ? ps --ppid pid_of_helper -o pid= I don't know which pid requires (not read all the code yet), but i suggest you to try if there are some differences between executing with your locale or with C or en_US.UTF-8 -- "E' assurdo impiegare gli uomini di intelligenza eccellente per fare calcoli che potrebbero essere affidati a chiunque se si usassero delle macchine" Gottfried Wilhelm von Leibnitz, Filosofo e Matematico (1646-1716) "Internet ? la pi? grande biblioteca del mondo. Ma il problema ? che i libri sono tutti sparsi sul pavimento" John Allen Paulos, Matematico (1945-vivente) Luca 'remix_tj' Lorenzetto, http://www.remixtj.net , From hguemar at fedoraproject.org Wed Oct 26 23:01:58 2016 From: hguemar at fedoraproject.org (=?UTF-8?Q?Ha=C3=AFkel?=) Date: Thu, 27 Oct 2016 01:01:58 +0200 Subject: [rdo-list] [Fedocal] Reminder meeting : RDO meeting In-Reply-To: <660d125f-fe36-3c17-8a50-4e04ba259f7d@redhat.com> References: <20161024150007.4733860A3FDC@fedocal02.phx2.fedoraproject.org> <346499725.29902476.1477483978737.JavaMail.zimbra@redhat.com> <660d125f-fe36-3c17-8a50-4e04ba259f7d@redhat.com> Message-ID: 2016-10-26 14:16 GMT+02:00 Rich Bowen : > Yes, I'm working on gathering all of the presentations/slides/URLs from > the event, and will have those to the list ASAP. > > Also, due to technical difficulties I did *not* stream the event. > However, I did record it. I have not yet had a chance to review the > recording, so I don't know if the quality is very good, but I should be > sharing this soon, also. > > --Rich > Here's mine: "RDO Newton Release Status" https://hguemar.fedorapeople.org/slides/rdo-barcelona-summit-meetup/#1 Thanks to Rich and Patrick for preparing the meetup, it was awesome. > On 10/26/2016 02:12 PM, Bertrand Rault wrote: >> Indeed, thank you very much for the party and the presentations! >> Is there a compile list URLs where we can revisit what was presented >> when it comes to Cephs and RDO. >> >> Thanks, >> >> Bertrand >> >> >> >> ------------------------------------------------------------------------ >> *From: *"Wesley Hayutin" >> *To: *"Alan Pevec" , "Rich Bowen" >> *Cc: *"Rdo-list at redhat.com" >> *Sent: *Wednesday, October 26, 2016 8:55:51 AM >> *Subject: *Re: [rdo-list] [Fedocal] Reminder meeting : RDO meeting >> >> Thanks for planning the event last night, it was a geat success and I >> personally had a great time! >> Congrats to all the speakers, well done! >> >> Thanks! >> >> >> On Mon, Oct 24, 2016 at 12:01 PM, Alan Pevec > > wrote: >> >> As discussed at the meeting last week, instead of regular Wednesday >> IRC meeting we will have live streaming from meetup on Tuesday >> https://etherpad.openstack.org/p/rdo-barcelona-meetup-schedule >> >> Cheers, >> Alan >> >> >> _______________________________________________ >> 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 >> >> >> >> -- >> Bertrand Rault >> Red Hat, Inc. >> NFV EPM >> Engineering Partner Management >> Platform Business Unit >> bertrand at redhat.com >> +1 972 892 4514 (Office) >> +33 07 50 65 55 30 (Mobile) >> >> >> > > -- > 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 From javier.pena at redhat.com Thu Oct 27 07:42:40 2016 From: javier.pena at redhat.com (Javier Pena) Date: Thu, 27 Oct 2016 03:42:40 -0400 (EDT) Subject: [rdo-list] [Fedocal] Reminder meeting : RDO meeting In-Reply-To: References: <20161024150007.4733860A3FDC@fedocal02.phx2.fedoraproject.org> <346499725.29902476.1477483978737.JavaMail.zimbra@redhat.com> <660d125f-fe36-3c17-8a50-4e04ba259f7d@redhat.com> Message-ID: <1768327238.8380997.1477554160018.JavaMail.zimbra@redhat.com> ----- Original Message ----- > 2016-10-26 14:16 GMT+02:00 Rich Bowen : > > Yes, I'm working on gathering all of the presentations/slides/URLs from > > the event, and will have those to the list ASAP. > > > > Also, due to technical difficulties I did *not* stream the event. > > However, I did record it. I have not yet had a chance to review the > > recording, so I don't know if the quality is very good, but I should be > > sharing this soon, also. > > > > --Rich > > > > Here's mine: "RDO Newton Release Status" > https://hguemar.fedorapeople.org/slides/rdo-barcelona-summit-meetup/#1 The slides for my "RDO repos overview" presentation are available at https://jpena.fedorapeople.org/presentations/slides_rdo-repos-overview.zip > > Thanks to Rich and Patrick for preparing the meetup, it was awesome. > +1 !! > > On 10/26/2016 02:12 PM, Bertrand Rault wrote: > >> Indeed, thank you very much for the party and the presentations! > >> Is there a compile list URLs where we can revisit what was presented > >> when it comes to Cephs and RDO. > >> > >> Thanks, > >> > >> Bertrand > >> > >> > >> > >> ------------------------------------------------------------------------ > >> *From: *"Wesley Hayutin" > >> *To: *"Alan Pevec" , "Rich Bowen" > >> > >> *Cc: *"Rdo-list at redhat.com" > >> *Sent: *Wednesday, October 26, 2016 8:55:51 AM > >> *Subject: *Re: [rdo-list] [Fedocal] Reminder meeting : RDO meeting > >> > >> Thanks for planning the event last night, it was a geat success and I > >> personally had a great time! > >> Congrats to all the speakers, well done! > >> > >> Thanks! > >> > >> > >> On Mon, Oct 24, 2016 at 12:01 PM, Alan Pevec >> > wrote: > >> > >> As discussed at the meeting last week, instead of regular Wednesday > >> IRC meeting we will have live streaming from meetup on Tuesday > >> https://etherpad.openstack.org/p/rdo-barcelona-meetup-schedule > >> > >> Cheers, > >> Alan > >> > >> > >> _______________________________________________ > >> 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 > >> > >> > >> > >> -- > >> Bertrand Rault > >> Red Hat, Inc. > >> NFV EPM > >> Engineering Partner Management > >> Platform Business Unit > >> bertrand at redhat.com > >> +1 972 892 4514 (Office) > >> +33 07 50 65 55 30 (Mobile) > >> > >> > >> > > > > -- > > 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 > > _______________________________________________ > 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 Thu Oct 27 08:46:02 2016 From: amoralej at redhat.com (Alfredo Moralejo Alonso) Date: Thu, 27 Oct 2016 10:46:02 +0200 Subject: [rdo-list] [Fedocal] Reminder meeting : RDO meeting In-Reply-To: <1768327238.8380997.1477554160018.JavaMail.zimbra@redhat.com> References: <20161024150007.4733860A3FDC@fedocal02.phx2.fedoraproject.org> <346499725.29902476.1477483978737.JavaMail.zimbra@redhat.com> <660d125f-fe36-3c17-8a50-4e04ba259f7d@redhat.com> <1768327238.8380997.1477554160018.JavaMail.zimbra@redhat.com> Message-ID: Here you have the slides about testing in RDO, https://amoralej.fedorapeople.org/slides/RDO-CI-summit-bcn-final.pdf On Thu, Oct 27, 2016 at 9:42 AM, Javier Pena wrote: > > > ----- Original Message ----- >> 2016-10-26 14:16 GMT+02:00 Rich Bowen : >> > Yes, I'm working on gathering all of the presentations/slides/URLs from >> > the event, and will have those to the list ASAP. >> > >> > Also, due to technical difficulties I did *not* stream the event. >> > However, I did record it. I have not yet had a chance to review the >> > recording, so I don't know if the quality is very good, but I should be >> > sharing this soon, also. >> > >> > --Rich >> > >> >> Here's mine: "RDO Newton Release Status" >> https://hguemar.fedorapeople.org/slides/rdo-barcelona-summit-meetup/#1 > > The slides for my "RDO repos overview" presentation are available at https://jpena.fedorapeople.org/presentations/slides_rdo-repos-overview.zip > >> >> Thanks to Rich and Patrick for preparing the meetup, it was awesome. >> > > +1 !! > > >> > On 10/26/2016 02:12 PM, Bertrand Rault wrote: >> >> Indeed, thank you very much for the party and the presentations! >> >> Is there a compile list URLs where we can revisit what was presented >> >> when it comes to Cephs and RDO. >> >> >> >> Thanks, >> >> >> >> Bertrand >> >> >> >> >> >> >> >> ------------------------------------------------------------------------ >> >> *From: *"Wesley Hayutin" >> >> *To: *"Alan Pevec" , "Rich Bowen" >> >> >> >> *Cc: *"Rdo-list at redhat.com" >> >> *Sent: *Wednesday, October 26, 2016 8:55:51 AM >> >> *Subject: *Re: [rdo-list] [Fedocal] Reminder meeting : RDO meeting >> >> >> >> Thanks for planning the event last night, it was a geat success and I >> >> personally had a great time! >> >> Congrats to all the speakers, well done! >> >> >> >> Thanks! >> >> >> >> >> >> On Mon, Oct 24, 2016 at 12:01 PM, Alan Pevec > >> > wrote: >> >> >> >> As discussed at the meeting last week, instead of regular Wednesday >> >> IRC meeting we will have live streaming from meetup on Tuesday >> >> https://etherpad.openstack.org/p/rdo-barcelona-meetup-schedule >> >> >> >> Cheers, >> >> Alan >> >> >> >> >> >> _______________________________________________ >> >> 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 >> >> >> >> >> >> >> >> -- >> >> Bertrand Rault >> >> Red Hat, Inc. >> >> NFV EPM >> >> Engineering Partner Management >> >> Platform Business Unit >> >> bertrand at redhat.com >> >> +1 972 892 4514 (Office) >> >> +33 07 50 65 55 30 (Mobile) >> >> >> >> >> >> >> > >> > -- >> > 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 >> >> _______________________________________________ >> 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 kdreyer at redhat.com Thu Oct 27 22:18:15 2016 From: kdreyer at redhat.com (Ken Dreyer) Date: Thu, 27 Oct 2016 16:18:15 -0600 Subject: [rdo-list] Fwd: An Evening of Ceph and RDO (schedule) In-Reply-To: References: <0bf6fb47-618b-a850-d8ca-31f68a53bb0e@redhat.com> Message-ID: On Wed, Oct 26, 2016 at 12:37 AM, Gerard Braad wrote: > Hi All, > > On Fri, Oct 14, 2016 at 2:30 AM, Rich Bowen wrote: >> These are all 5-10m lightning talks. Let me know if there are any >> questions. Thanks! > > Were these talks recorded? > I was hoping to watch recordings as well. Sorry I couldn't make it to the live stream that day. - Ken From rbowen at redhat.com Mon Oct 31 14:13:30 2016 From: rbowen at redhat.com (Rich Bowen) Date: Mon, 31 Oct 2016 15:13:30 +0100 Subject: [rdo-list] Fwd: An Evening of Ceph and RDO (schedule) In-Reply-To: References: <0bf6fb47-618b-a850-d8ca-31f68a53bb0e@redhat.com> Message-ID: Well, sort of. I did record them, but a lot of the people presenting weren't on camera, and there's a LOT of background noise. I'm reviewing the recording now, and will be posting it, but can't promise much regarding quality. On Wed, Oct 26, 2016 at 8:37 AM, Gerard Braad wrote: > Hi All, > > On Fri, Oct 14, 2016 at 2:30 AM, Rich Bowen wrote: > > These are all 5-10m lightning talks. Let me know if there are any > > questions. Thanks! > > Were these talks recorded? > > Regards, > > > Gerard > > -- > > Gerard Braad | http://gbraad.nl > [ Doing Open Source Matters ] > -- Rich Bowen - rbowen at redhat.com RDO - OpenStack for CentOS - http://rdoproject.org/ @RDOcommunity -------------- next part -------------- An HTML attachment was scrubbed... URL: From apevec at redhat.com Mon Oct 31 14:47:09 2016 From: apevec at redhat.com (Alan Pevec) Date: Mon, 31 Oct 2016 15:47:09 +0100 Subject: [rdo-list] Fwd: An Evening of Ceph and RDO (schedule) In-Reply-To: References: <0bf6fb47-618b-a850-d8ca-31f68a53bb0e@redhat.com> Message-ID: > and there's a LOT of background noise I think Jakub's presentation might have lower noise level after STFU exception request :) Alan From hguemar at fedoraproject.org Mon Oct 31 15:00:06 2016 From: hguemar at fedoraproject.org (hguemar at fedoraproject.org) Date: Mon, 31 Oct 2016 15:00:06 +0000 (UTC) Subject: [rdo-list] [Fedocal] Reminder meeting : RDO meeting Message-ID: <20161031150006.C58CD60A3FDC@fedocal02.phx2.fedoraproject.org> Dear all, You are kindly invited to the meeting: RDO meeting on 2016-11-02 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 rbowen at redhat.com Mon Oct 31 17:35:25 2016 From: rbowen at redhat.com (Rich Bowen) Date: Mon, 31 Oct 2016 13:35:25 -0400 Subject: [rdo-list] RDO at PTG or OpenStack Summit? Message-ID: <82e2729a-4c1f-c67a-0748-35dc88cbdb73@redhat.com> As you no doubt know by now ... well, I'll just quote from another list: As you probably already know, the OpenStack Foundation is restructuring its events in 2017, splitting the activities that traditionally occurred at the Design Summit event into work sessions (at the "Project Teams Gathering" at the start of the cycle) and open community discussions ("Forum" at the OpenStack Summit in the middle of the cycle). You can learn more about this at http://www.openstack.org/ptg At the last several OpenStack Summits, the RDO community has hosted some kind of meetup, and of course last week, we had an evening gathering that we shared with the Ceph community, where we had 215 people in attendance. With OpenStack Summit splitting in two, I'm left uncertain what, if anything, I should be planning for 2017. Will most of the RDO community attend the PTG, or OpenStack Summit? At which one of these does it make the most sense to try to do an RDO gathering, if at all? I can see good arguments for each, including my personal travel plans ;-) but I would like to hear from the rest of you - if I try to do another event like what we did Tuesday evening in Barcelona, which event makes more sense? Thanks. -- Rich Bowen - rbowen at redhat.com RDO Community Liaison http://rdoproject.org @RDOCommunity From rbowen at redhat.com Mon Oct 31 18:11:21 2016 From: rbowen at redhat.com (Rich Bowen) Date: Mon, 31 Oct 2016 14:11:21 -0400 Subject: [rdo-list] Reminder: RDO Survey Message-ID: A reminder - we are running an RDO survey at http://tm3.org/rdo-survey/ which will hopefully show us how people are using RDO, ways that the community thinks that RDO can improve, and ways that people want to get involved. So far, we have a very small number of responses (30). I'm hoping that the many people I gave the URL to at OpenStack Summmit will in fact come to fill out the survey. Please pass the URL on to people that you know are using RDO. I intend to close the survey after another week or two. I'd like to have a lot more responses, but I also want to be able to share the results with the community without having to wait too much longer. -- Rich Bowen - rbowen at redhat.com RDO Community Liaison http://rdoproject.org @RDOCommunity From rbowen at redhat.com Mon Oct 31 18:40:41 2016 From: rbowen at redhat.com (Rich Bowen) Date: Mon, 31 Oct 2016 14:40:41 -0400 Subject: [rdo-list] Unread RDO questions - ask.openstack.org Message-ID: 32 unanswered questions: Failed to boot instance on Openstack https://ask.openstack.org/en/question/98461/failed-to-boot-instance-on-openstack/ Tags: nova, boot openstack server list always show ERROR status of instance https://ask.openstack.org/en/question/98357/openstack-server-list-always-show-error-status-of-instance/ Tags: nova-newton, neutron RDO packstack centos - installation errors https://ask.openstack.org/en/question/98337/rdo-packstack-centos-installation-errors/ Tags: rdo, packstack, newton, installation neutron packstack installation error - Error: Could not set 'present' on ensure: Cannot allocate memory https://ask.openstack.org/en/question/98336/neutron-packstack-installation-error-error-could-not-set-present-on-ensure-cannot-allocate-memory/ Tags: rdo Live migration failing with qemu error "does not support drive-mirror" https://ask.openstack.org/en/question/98144/live-migration-failing-with-qemu-error-does-not-support-drive-mirror/ Tags: newton, nova, qemu, kvm, block-live-migration error while launching instance in openstack 'newton' using rdo packstack https://ask.openstack.org/en/question/98113/error-while-launching-instance-in-openstack-newton-using-rdo-packstack/ Tags: rdo, newton, packstack How can I add a new region to an installed All-In-One RDO openstack? https://ask.openstack.org/en/question/98111/how-can-i-add-a-new-region-to-an-installed-all-in-one-rdo-openstack/ Tags: rdo, all-in-one, multi-region, region, add-region How to setup solr search engine for openstack swift https://ask.openstack.org/en/question/98093/how-to-setup-solr-search-engine-for-openstack-swift/ Tags: openstack, openstack-swift, newton, rdo Heat fails with 504 error. https://ask.openstack.org/en/question/98092/heat-fails-with-504-error/ Tags: rdo, tripleo, mitaka, heat Devstack and OpenvSwitch v2.3+ https://ask.openstack.org/en/question/98004/devstack-and-openvswitch-v23/ Tags: devstack, openvswitch How how does icmp packet travel across two compute nodes without br-int and br-tun running? https://ask.openstack.org/en/question/97905/how-how-does-icmp-packet-travel-across-two-compute-nodes-without-br-int-and-br-tun-running/ Tags: neutron-ovs-pktflow "Parameter outiface failed on Firewall" during installation of openstack rdo on centos 7 https://ask.openstack.org/en/question/95657/parameter-outiface-failed-on-firewall-during-installation-of-openstack-rdo-on-centos-7/ Tags: rdo, devstack#mitaka multi nodes provider network ovs config https://ask.openstack.org/en/question/95423/multi-nodes-provider-network-ovs-config/ Tags: rdo, liberty-neutron Adding additional packages to an RDO installation https://ask.openstack.org/en/question/95380/adding-additional-packages-to-an-rdo-installation/ Tags: rdo, mistral RDO TripleO Mitaka HA Overcloud Failing https://ask.openstack.org/en/question/95249/rdo-tripleo-mitaka-ha-overcloud-failing/ Tags: mitaka, tripleo, overcloud, centos7 RDO - is there any fedora package newer than puppet-4.2.1-3.fc24.noarch.rpm https://ask.openstack.org/en/question/94969/rdo-is-there-any-fedora-package-newer-than-puppet-421-3fc24noarchrpm/ Tags: rdo, puppet, install-openstack OpenStack RDO mysqld 100% cpu https://ask.openstack.org/en/question/94961/openstack-rdo-mysqld-100-cpu/ Tags: openstack, mysqld, cpu how to deploy haskell-distributed in RDO? https://ask.openstack.org/en/question/94785/how-to-deploy-haskell-distributed-in-rdo/ Tags: rdo rdo tripleO liberty undercloud install failing https://ask.openstack.org/en/question/94023/rdo-tripleo-liberty-undercloud-install-failing/ Tags: rdo, rdo-manager, liberty, undercloud, instack Liberty RDO: stack resource topology icons are pink https://ask.openstack.org/en/question/91347/liberty-rdo-stack-resource-topology-icons-are-pink/ Tags: resource, topology, dashboard, horizon, pink No handlers could be found for logger "oslo_config.cfg" while syncing the glance database https://ask.openstack.org/en/question/91169/no-handlers-could-be-found-for-logger-oslo_configcfg-while-syncing-the-glance-database/ Tags: liberty, glance, install-openstack CentOS OpenStack - compute node can't talk https://ask.openstack.org/en/question/88989/centos-openstack-compute-node-cant-talk/ Tags: rdo How to setup SWIFT_PROXY_NODE and SWIFT_STORAGE_NODEs separately on RDO Liberty ? https://ask.openstack.org/en/question/88897/how-to-setup-swift_proxy_node-and-swift_storage_nodes-separately-on-rdo-liberty/ Tags: rdo, liberty, swift, ha VM and container can't download anything from internet https://ask.openstack.org/en/question/88338/vm-and-container-cant-download-anything-from-internet/ Tags: rdo, neutron, network, connectivity Fedora22, Liberty, horizon VNC console and keymap=sv with ; and/ https://ask.openstack.org/en/question/87451/fedora22-liberty-horizon-vnc-console-and-keymapsv-with-and/ Tags: keyboard, map, keymap, vncproxy, novnc OpenStack-Docker driver failed https://ask.openstack.org/en/question/87243/openstack-docker-driver-failed/ Tags: docker, openstack, liberty Routing between two tenants https://ask.openstack.org/en/question/84645/routing-between-two-tenants/ Tags: kilo, fuel, rdo, routing openstack baremetal introspection internal server error https://ask.openstack.org/en/question/82790/openstack-baremetal-introspection-internal-server-error/ Tags: rdo, ironic-inspector, tripleo Installing openstack using packstack (rdo) failed https://ask.openstack.org/en/question/82473/installing-openstack-using-packstack-rdo-failed/ Tags: rdo, packstack, installation-error, keystone VMware Host Backend causes No valid host was found. Bug ??? https://ask.openstack.org/en/question/79738/vmware-host-backend-causes-no-valid-host-was-found-bug/ Tags: vmware, rdo -- Rich Bowen - rbowen at redhat.com RDO Community Liaison http://rdoproject.org @RDOCommunity From hguemar at fedoraproject.org Mon Oct 31 20:07:29 2016 From: hguemar at fedoraproject.org (=?UTF-8?Q?Ha=C3=AFkel?=) Date: Mon, 31 Oct 2016 21:07:29 +0100 Subject: [rdo-list] RDO at PTG or OpenStack Summit? In-Reply-To: <82e2729a-4c1f-c67a-0748-35dc88cbdb73@redhat.com> References: <82e2729a-4c1f-c67a-0748-35dc88cbdb73@redhat.com> Message-ID: 2016-10-31 18:35 GMT+01:00 Rich Bowen : > As you no doubt know by now ... well, I'll just quote from another list: > > > As you probably already know, the OpenStack Foundation is restructuring > its events in 2017, splitting the activities that traditionally occurred > at the Design Summit event into work sessions (at the "Project Teams > Gathering" at the start of the cycle) and open community discussions > ("Forum" at the OpenStack Summit in the middle of the cycle). You can > learn more about this at http://www.openstack.org/ptg > > > At the last several OpenStack Summits, the RDO community has hosted some > kind of meetup, and of course last week, we had an evening gathering > that we shared with the Ceph community, where we had 215 people in > attendance. > > With OpenStack Summit splitting in two, I'm left uncertain what, if > anything, I should be planning for 2017. Will most of the RDO community > attend the PTG, or OpenStack Summit? At which one of these does it make > the most sense to try to do an RDO gathering, if at all? > > I can see good arguments for each, including my personal travel plans > ;-) but I would like to hear from the rest of you - if I try to do > another event like what we did Tuesday evening in Barcelona, which event > makes more sense? > > Thanks. > Tough question, the attendance will likely be at summits while speakers will go at PTG. > -- > 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 From Tim.Bell at cern.ch Mon Oct 31 20:37:16 2016 From: Tim.Bell at cern.ch (Tim Bell) Date: Mon, 31 Oct 2016 20:37:16 +0000 Subject: [rdo-list] RDO at PTG or OpenStack Summit? In-Reply-To: References: <82e2729a-4c1f-c67a-0748-35dc88cbdb73@redhat.com> Message-ID: <867B880A-6A34-4F4E-85B7-F3F5635D16BD@cern.ch> >From the CERN perspective, I would expect that the majority of our participants would go to the summit. A few of those working closely with upstream would go to the PTG. We would certainly appreciate the opportunity to interact with the RDO community at the summit. The PTG focus would be more on the individual projects such as Magnum or Keystone where we contribute the most. Tim On 31.10.16, 21:07, "rdo-list-bounces at redhat.com on behalf of Ha?kel" wrote: 2016-10-31 18:35 GMT+01:00 Rich Bowen : > As you no doubt know by now ... well, I'll just quote from another list: > > > As you probably already know, the OpenStack Foundation is restructuring > its events in 2017, splitting the activities that traditionally occurred > at the Design Summit event into work sessions (at the "Project Teams > Gathering" at the start of the cycle) and open community discussions > ("Forum" at the OpenStack Summit in the middle of the cycle). You can > learn more about this at http://www.openstack.org/ptg > > > At the last several OpenStack Summits, the RDO community has hosted some > kind of meetup, and of course last week, we had an evening gathering > that we shared with the Ceph community, where we had 215 people in > attendance. > > With OpenStack Summit splitting in two, I'm left uncertain what, if > anything, I should be planning for 2017. Will most of the RDO community > attend the PTG, or OpenStack Summit? At which one of these does it make > the most sense to try to do an RDO gathering, if at all? > > I can see good arguments for each, including my personal travel plans > ;-) but I would like to hear from the rest of you - if I try to do > another event like what we did Tuesday evening in Barcelona, which event > makes more sense? > > Thanks. > Tough question, the attendance will likely be at summits while speakers will go at PTG. > -- > 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 _______________________________________________ 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 jrist at redhat.com Mon Oct 31 20:38:08 2016 From: jrist at redhat.com (Jason Rist) Date: Mon, 31 Oct 2016 14:38:08 -0600 Subject: [rdo-list] RDO at PTG or OpenStack Summit? In-Reply-To: <82e2729a-4c1f-c67a-0748-35dc88cbdb73@redhat.com> References: <82e2729a-4c1f-c67a-0748-35dc88cbdb73@redhat.com> Message-ID: <243216ad-1774-83b4-f5dc-6ee955db72e0@redhat.com> On 10/31/2016 11:35 AM, Rich Bowen wrote: > As you no doubt know by now ... well, I'll just quote from another list: > > > As you probably already know, the OpenStack Foundation is restructuring > its events in 2017, splitting the activities that traditionally occurred > at the Design Summit event into work sessions (at the "Project Teams > Gathering" at the start of the cycle) and open community discussions > ("Forum" at the OpenStack Summit in the middle of the cycle). You can > learn more about this at http://www.openstack.org/ptg > > > At the last several OpenStack Summits, the RDO community has hosted some > kind of meetup, and of course last week, we had an evening gathering > that we shared with the Ceph community, where we had 215 people in > attendance. > > With OpenStack Summit splitting in two, I'm left uncertain what, if > anything, I should be planning for 2017. Will most of the RDO community > attend the PTG, or OpenStack Summit? At which one of these does it make > the most sense to try to do an RDO gathering, if at all? > > I can see good arguments for each, including my personal travel plans > ;-) but I would like to hear from the rest of you - if I try to do > another event like what we did Tuesday evening in Barcelona, which event > makes more sense? > > Thanks. > Based on what I am/was seeing with the way that PTG space is being allocated, it might be best for the primary presence to be at the primary Summit. You might not even be able to get any space at the PTG. -J -- Jason E. Rist Senior Software Engineer OpenStack User Interfaces Red Hat, Inc. openuc: +1.972.707.6408 mobile: +1.720.256.3933 Freenode: jrist github/twitter: knowncitizen From pmyers at redhat.com Mon Oct 31 20:53:29 2016 From: pmyers at redhat.com (Perry Myers) Date: Mon, 31 Oct 2016 21:53:29 +0100 Subject: [rdo-list] RDO at PTG or OpenStack Summit? In-Reply-To: <243216ad-1774-83b4-f5dc-6ee955db72e0@redhat.com> References: <82e2729a-4c1f-c67a-0748-35dc88cbdb73@redhat.com> <243216ad-1774-83b4-f5dc-6ee955db72e0@redhat.com> Message-ID: On Mon, Oct 31, 2016 at 9:38 PM, Jason Rist wrote: > On 10/31/2016 11:35 AM, Rich Bowen wrote: >> As you no doubt know by now ... well, I'll just quote from another list: >> >> >> As you probably already know, the OpenStack Foundation is restructuring >> its events in 2017, splitting the activities that traditionally occurred >> at the Design Summit event into work sessions (at the "Project Teams >> Gathering" at the start of the cycle) and open community discussions >> ("Forum" at the OpenStack Summit in the middle of the cycle). You can >> learn more about this at http://www.openstack.org/ptg >> >> >> At the last several OpenStack Summits, the RDO community has hosted some >> kind of meetup, and of course last week, we had an evening gathering >> that we shared with the Ceph community, where we had 215 people in >> attendance. >> >> With OpenStack Summit splitting in two, I'm left uncertain what, if >> anything, I should be planning for 2017. Will most of the RDO community >> attend the PTG, or OpenStack Summit? At which one of these does it make >> the most sense to try to do an RDO gathering, if at all? >> >> I can see good arguments for each, including my personal travel plans >> ;-) but I would like to hear from the rest of you - if I try to do >> another event like what we did Tuesday evening in Barcelona, which event >> makes more sense? >> >> Thanks. >> > > Based on what I am/was seeing with the way that PTG space is being > allocated, it might be best for the primary presence to be at the > primary Summit. You might not even be able to get any space at the PTG. I agree with what Tim/Jason have said in their emails. That said, perhaps we do a larger event (like we did at Barcelona) at Summit in Boston, but... if there is a desire for some RDO developers to get together to discuss technical/tactical issues while at PTG, why not? Basically... "RDO Community Meetup" at Summit and "RDO Technical Discussions" at the PTG, for those that are around for them. Given what Jason is saying about space at the PTG, maybe the RDO Tech Discussion is just an evening thing and is informal? Perry