I wanted to be certain that everyone has seen this message to OpenStack-docs, and the subsequent conversation at http://lists.openstack.org/pipermail/openstack-docs/2015-October/007622.html This is quite serious, as Lana is basically saying that RDO isn't a viable way to deploy OpenStack in Liberty, and so it's being removed from the docs. It would be helpful if someone closer to Liberty packages, and Delorean, could participate there in a constructive way to bring this to a happy conclusion before the release tomorrow. Thanks. --Rich -------- Forwarded Message -------- Subject: [OpenStack-docs] [install-guide] Status of RDO Date: Wed, 14 Oct 2015 16:22:45 +1000 From: Lana Brindley <openstack(a)lanabrindley.com&gt; To: openstack-docs(a)lists.openstack.org <openstack-docs(a)lists.openstack.org&gt; -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi everyone, We've been unable to obtain good pre-release packages from Red Hat for the Fedora and Red Hat/CentOS repos, despite our best efforts. This has left the RDO Install Guide in a largely untested state, so I don't feel confident publishing it at this stage. As far as we can tell, Fedora are no longer planning on having pre-release packages available, so this might be a permanent change for that OS. For Red Hat/CentOS, it seems to be a temporary problem, so hopefully we can get the packages, complete testing, and publish the book soon. The patch to remove RDO is here, for anyone who cares to comment: https://review.openstack.org/#/c/234584/ Lana - -- Lana Brindley Technical Writer Rackspace Cloud Builders Australia http://lanabrindley.com _______________________________________________ OpenStack-docs mailing list OpenStack-docs(a)lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs _______________________________________________ Rdo-list mailing list Rdo-list(a)redhat.com https://www.redhat.com/mailman/listinfo/rdo-list To unsubscribe: rdo-list-unsubscribe(a)redhat.com

----- Original Message ----- > From: "Rich Bowen" <rbowen(a)redhat.com&gt; > To: rdo-list(a)redhat.com > Sent: Thursday, October 15, 2015 9:01:03 AM > Subject: Re: [Rdo-list] Fwd: [OpenStack-docs] [install-guide] Status of RDO > > Just to follow up: > > http://docs.openstack.org/ > > Installation Guide for Debian 8 (not yet available) > > Installation Guide for Red Hat Enterprise Linux 7, CentOS 7, and Fedora > 22 (not yet available) > > > > --Rich To get this updated what is required is for someone to walk through the draft install guide [1] vetting each procedure on each target distro and updating the test matrix here: https://wiki.openstack.org/wiki/Documentation/LibertyDocTesting We also need to determine which "known issues" need to be resolved, and document + file bugs for any new ones that pop up (and ideally resolve them). In future as part of the RDO test day I think we should: a) Broadcast where the correct packages are more widely (e.g. include openstack-docs(a)lists.openstack.org in the distribution list for the test day). There seems to be a contention that they weren't available or were available but were mixed up with Mitaka packages which was true at a point in time but was quickly resolved (there was an issue with the config files being shipped though). b) Integrate the install guide test matrix into the test day so that we (the RDO community) can help drive vetting it earlier. Thanks, Steve [1] http://docs.openstack.org/draft/install-guide-rdo/ > On 10/14/2015 07:49 AM, Rich Bowen wrote: > > I wanted to be certain that everyone has seen this message to > > OpenStack-docs, and the subsequent conversation at > > http://lists.openstack.org/pipermail/openstack-docs/2015-October/007622.html > > > > > > This is quite serious, as Lana is basically saying that RDO isn't a > > viable way to deploy OpenStack in Liberty, and so it's being removed > > from the docs. > > > > It would be helpful if someone closer to Liberty packages, and Delorean, > > could participate there in a constructive way to bring this to a happy > > conclusion before the release tomorrow. > > > > Thanks. > > > > --Rich > > > > > > -------- Forwarded Message -------- > > Subject: [OpenStack-docs] [install-guide] Status of RDO > > Date: Wed, 14 Oct 2015 16:22:45 +1000 > > From: Lana Brindley <openstack(a)lanabrindley.com&gt; > > To: openstack-docs(a)lists.openstack.org < openstack-docs(a)lists.openstack.org&gt; > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA256 > > > > Hi everyone, > > > > We've been unable to obtain good pre-release packages from Red Hat for > > the Fedora and Red Hat/CentOS repos, despite our best efforts. This has > > left the RDO Install Guide in a largely untested state, so I don't feel > > confident publishing it at this stage. > > > > As far as we can tell, Fedora are no longer planning on having > > pre-release packages available, so this might be a permanent change for > > that OS. For Red Hat/CentOS, it seems to be a temporary problem, so > > hopefully we can get the packages, complete testing, and publish the > > book soon. > > > > The patch to remove RDO is here, for anyone who cares to comment: > > https://review.openstack.org/#/c/234584/ > > > > Lana > > > > - -- Lana Brindley > > Technical Writer > > Rackspace Cloud Builders Australia > > http://lanabrindley.com > > > > _______________________________________________ > > OpenStack-docs mailing list > > OpenStack-docs(a)lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs > > > > > > _______________________________________________ > > Rdo-list mailing list > > Rdo-list(a)redhat.com > > https://www.redhat.com/mailman/listinfo/rdo-list > > > > To unsubscribe: rdo-list-unsubscribe(a)redhat.com > > > -- > Rich Bowen - rbowen(a)redhat.com > OpenStack Community Liaison > http://rdoproject.org/ > > _______________________________________________ > Rdo-list mailing list > Rdo-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe(a)redhat.com > -- Steve Gordon, RHCE Sr. Technical Product Manager, Red Hat Enterprise Linux OpenStack Platform _______________________________________________ Rdo-list mailing list Rdo-list(a)redhat.com https://www.redhat.com/mailman/listinfo/rdo-list To unsubscribe: rdo-list-unsubscribe(a)redhat.com

> On 15 Oct 2015, at 20:31, Matt Kassawara <mkassawara(a)gmail.com&gt; wrote: > > 4) Packages only reference upstream configuration files in standard > locations (e.g., /etc/keystone). Not sure what exactly it means. RDO packages are using neutron-dist.conf that contains RDO specific default configuration located under /usr/share/ for quite a long time.

> On 21 Oct 2015, at 12:02, Alan Pevec <apevec(a)gmail.com&gt; wrote: > > 2015-10-21 10:48 GMT+02:00 Ihar Hrachyshka <ihrachys(a)redhat.com&gt;: >>> On 15 Oct 2015, at 20:31, Matt Kassawara <mkassawara(a)gmail.com&gt; wrote: >>> >>> 4) Packages only reference upstream configuration files in standard >>> locations (e.g., /etc/keystone). >> >> Not sure what exactly it means. RDO packages are using neutron-dist.conf that contains RDO specific default configuration located under /usr/share/ for quite a long time. > > Yes, it's about dist.conf that are unique solution to provide distro > specific default values. > I'm not sure how are other distros solving this if at all, they > probably either rely on upstream defaults or their configuration > management tools? > Thing is that upstream defaults cannot fit all distributions, so I > would expect all distros to pick up our dist.conf solution but we > probably have not been exaplaning and advertising it enough hence > confusion in the upstream docs. I suspect other distros may just modify /etc/neutron/neutron.conf as they fit. It’s obviously not the cleanest solution. I believe enforcing a specific way to configure services upon distributions is not the job of upstream, as long as default upstream way (modifying upstream configuration files located in /etc/<service-name>/*.conf) works. Ihar

The RDO repository doesn't contain a package for PyMySQL.

On 21 Oct 2015, at 15:32, Matt Kassawara <mkassawara(a)gmail.com&gt; wrote: I think packages available for standalone installation (i.e., without a deployment tool) should include complete upstream configuration files in standard locations without modification. In the case of *-dist.conf files with RDO packages, they seldom receive updates leading to deprecation warnings and sometimes override useful upstream default values. For example, most if not all services default to keystone for authentication (auth_strategy), yet the RDO neutron packages revert authentication to "noauth" in the *-dist.conf file. In another example, the RDO keystone package only includes the keystone-paste.ini file as /usr/share/keystone/keystone-dist-paste.ini rather than using the standard location and name which leads to confusion, particularly for new users. The installation guide contains quite a few extra steps and option-value pairs that work around the existence and contents of *-dist.conf files... additions that unnecessarily increase complexity for our audience of new users.

/usr/share/$service directories impacts the following portions in the installation guide: 1) http://docs.openstack.org/draft/install-guide-rdo/keystone-verify.html - The keystone-paste.ini file should reside in the /etc/keystone directory.

Matt Kassawara <mkassawara(a)gmail.com&gt; wrote: Ihar, > > I think distribution packages should bundle upstream source without > alteration to maximize flexibility for authors of deployment tools (or > simple instructions) that choose to use packages. In other words, > distribution packages should include few if any decisions on how to deploy > services. Instead, leave those decisions to authors of deployment tools > including organizations that produce distribution packages. For example, > decisions on how to deploy OpenStack using RDO packages should reside in > products like Packstack and RHEL-OSP. In the meantime, content in > /usr/share/$service directories impacts the following portions in the > installation guide: > You mix things here. RDO *is* a product, and *is* successfully used by companies without paying for RHEL-OSP subscription. Manual installation is still a supported way to deploy RDO, so anything that makes deployer life easier (like reasonable defaults) is beneficial. Below, I will comment on neutron only and will leave other components to respective team members. > 1) http://docs.openstack.org/draft/install-guide-rdo/keystone-verify.html > - The keystone-paste.ini file should reside in the /etc/keystone directory. > > 2) http://docs.openstack.org/draft/install-guide-rdo/glance.html - The > glance-api-dist.conf and glance-registry-dist.conf files contain defunct > options in the [keystone_authtoken] section. Also, the *-paste.ini files > should reside in the /etc/glance directory. > > 3) http://docs.openstack.org/draft/install-guide-rdo/nova.html - The > nova-dist.conf file contains defunct options in the [keystone_authtoken] > section, assumes use of nova-network, and contains several opinions about > libvirt configuration. > > 4) http://docs.openstack.org/draft/install-guide-rdo/neutron.html - The > neutron-dist.conf file specifies a notification driver regardless of a > consumer (e.g., ceilometer) and disables nova-neutron interaction. Also, > the *-paste.ini file should reside in the /etc/neutron directory. > > I agree nova-neutron notifications should not be disabled (I merged a patch for that yesterday: https://review.gerrithub.io/#/c/251171/) For notification driver, I am not sure I follow. The assumption is that DHCP agent is a common piece of neutron setup that is widely used, and since it relies on RPC notifications, we enable it by default. Do you believe it’s better to make everyone using refarch neutron to define it for themselves? For *-paste.ini file, I believe the RDO assumption is that there is no reason to modify it, hence it’s not available for user modifications. Can you show me the exact place where installation guide became more complex due to -paste.ini file located under /usr/share? 5) http://docs.openstack.org/draft/install-guide-rdo/cinder.html - The > cinder-dist.conf file contains defunct options in the [keystone_authtoken] > section. Interestingly, the *-paste.ini files correctly reside in the > /etc/cinder directory. > > 6) http://docs.openstack.org/draft/install-guide-rdo/swift.html - > Interestingly, no /usr/share/swift directory exists. However, the > configuration files in /etc/swift are considerably out of date and easier > to overwrite from upstream source than attempt to fix via procedure. > > 7) http://docs.openstack.org/draft/install-guide-rdo/heat.html - The > heat-dist.conf file contains defunct options in the [keystone_authtoken] > section, contains a defunct database connection option (belongs in > [database]), and enables a defunct message queue (Qpid). Also, the > *-paste.ini file should reside in the /etc/heat directory. > > I haven't looked at the ceilometer packages recently, but I suspect they > involve similar issues. > > Matt > > > > On Mon, Nov 2, 2015 at 4:34 AM, Ihar Hrachyshka <ihrachys(a)redhat.com&gt; > wrote: > > > On 21 Oct 2015, at 15:32, Matt Kassawara <mkassawara(a)gmail.com&gt; wrote: > > > > I think packages available for standalone installation (i.e., without a > deployment tool) should include complete upstream configuration files in > standard locations without modification. In the case of *-dist.conf files > with RDO packages, they seldom receive updates leading to deprecation > warnings and sometimes override useful upstream default values. For > example, most if not all services default to keystone for authentication > (auth_strategy), yet the RDO neutron packages revert authentication to > "noauth" in the *-dist.conf file. In another example, the RDO keystone > package only includes the keystone-paste.ini file as > /usr/share/keystone/keystone-dist-paste.ini rather than using the standard > location and name which leads to confusion, particularly for new users. The > installation guide contains quite a few extra steps and option-value pairs > that work around the existence and contents of *-dist.conf files... > additions that unnecessarily increase complexity for our audience of new > users. > > Can you provide links to the guide pages that are complicated by the > existence of -dist.conf files? > > I agree that some values may not be optimal (f.e. auth_strategy indeed > should not be overridden; I sent a patch [1] to remove it from -dist.conf); > but in principle, there should be a way for distributions to change > defaults, and it should not be expected that all distributions ship > identical configuration files. > > [1]: https://review.gerrithub.io/#/c/251170/ > > Ihar >

Matt Kassawara <mkassawara(a)gmail.com&gt; wrote: I agree that *-paste.ini files should remain static. Keystone contains the > only one that we need to edit (for security reasons) and the patch to move > this configuration out of keystone-paste.ini needs attention from the > keystone project. As for the installation guide, I prefer to unify the > documentation for editing keystone-paste.ini for all distributions. > Furthermore, our audience (mostly new users) likely feels more confident > about editing files that reside in a less "intimidating" location such as > /etc/$service. > > Best I can tell, neutron (and all other services) separate "mandatory" > message queue access (the 'rpc_backend' option) from notification access > because the latter only pertains to deployments with a consumer for > notifications such as ceilometer. Without a consumer, notification queues > pile up and lead to stability problems. Hence, the 'notification_driver' > option defaults to a blank value that essentially disables such > notifications. The upstream configuration file comments this option out and > installation guide doesn't explicitly configure it which means neutron uses > the value of 'notification_driver' from the neutron-dist.conf file and > sends notifications to a queue without a consumer. While I'm thinking about > it, I'm trying to determine the source of a memory leak (or strange > increase in consumption) in my RDO Liberty environment (and prior releases) > and should try disabling the notification driver. In comparison, my Ubuntu > Liberty environment containing the same services and virtual resources has > stable memory usage. > Do you use DHCP agent from neutron? I think it requires notification driver to be enabled. Ihar

Mentioned Bug https://bugs.launchpad.net/neutron/+bug/1494281 contains :- Fix merged to neutron (stable/liberty) Reviewed: https://review.openstack.org/238485 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=10e07503524cc... Submitter: Jenkins Branch: stable/liberty commit 10e07503524cc244d5c8f1f285db4a4f06dd12e7 Author: Thomas Herve <email address hidden> Date: Tue Oct 20 15:42:59 2015 +0200 Properly handle segmentation_id in OVS agent The segmentation_id of a OVS VLAN can be None, but a recent change assumed that it was always an integer. It highlighted the fact that we try to store None in the OVS database, which got stored as a string. This fixes the storage, and handles loading the value while keeping compatibility. Change-Id: I6e7df1406c90ddde254467bb87ff1507a4caaadd Closes-Bug: #1494281 (cherry picked from commit 51f6b2e1c9c2f5f5106b9ae8316e57750f09d7c9) Looking at build http://cbs.centos.org/koji/buildinfo?buildID=7850 I was unable to find patch https://git.openstack.org/cgit/openstack/neutron/patch/?id=10e07503524cc2... I could be wrong and just failed to find patch, otherwise RDO Liberty (stable Release ), having openstack-neutron-7.0.0-2.el7, has still problem originally described in upstream record, i.e. external flat network provider won't work as expected due to original version of neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py, packed into RDO Liberty until now. Thank you. Boris

> Mentioned Bug https://bugs.launchpad.net/neutron/+bug/1494281 contains :- > Fix merged to neutron (stable/liberty) > Reviewed: https://review.openstack.org/238485 > Properly handle segmentation_id in OVS agent

Yes, RDO Liberty is affected (Delorean Liberty is not). Please RDO folks advice: should we backport the patch or wait till rebase?

________________________________________ From: Alan Pevec <apevec(a)gmail.com&gt; Sent: Tuesday, December 1, 2015 12:11 PM To: Ihar Hrachyshka Cc: Boris Derzhavets; rdo-list Subject: Re: [Rdo-list] Current status of RDO Liberty CBS Repos and Bug "neutron-openvswitch-agent is crashing with "invalid literal for int() with base 10" error " 2015-12-01 14:27 GMT+01:00 Ihar Hrachyshka <ihrachys(a)redhat.com&gt;: >> Mentioned Bug https://bugs.launchpad.net/neutron/+bug/1494281 contains :- >> Fix merged to neutron (stable/liberty) >> Reviewed: https://review.openstack.org/238485 >> Properly handle segmentation_id in OVS agent > Yes, RDO Liberty is affected (Delorean Liberty is not). > > Please RDO folks advice: should we backport the patch or wait till rebase? "RDO folks" is all of us :) General rule for RDO builds is stick to vanilla upstream sources unless issue is a total blocker bug, high security fix or solving packaging problem. So question is for openstack-neutron maintainers: - ihrachys(a)redhat.com - majopela(a)redhat.com how to rate this issue. But AFAICT Neutron 7.0.1 should be out any day now[1] so I'd suggest pushing that release upstream then rebase in RDO Liberty. Sorry for stupid question, if 7.0.1 will be pushed to RDO Liberty then commit https://git.openstack.org/cgit/openstack/neutron/commit/?id=f63366e615e2d... would be just in tar ball. Does it mean then in properly configured environment following command would work (as admin ) # neutron router-create --ha True --distributed True --tenant_id demo_id RouterSuper or it becomes possible only in final Mitaka Release.

What means last statement in https://bugs.launchpad.net/neutron/+bug/1365473 Armando Migliaccio (armando-migliaccio) on 2015-11-11 Changed in neutron: importance: High → Wishlist

On 10/15/2015 04:43 PM, Steve Gordon wrote: > To get this updated what is required is for someone to walk through the draft install guide [1] vetting each procedure on each target distro and updating the test matrix here: > > https://wiki.openstack.org/wiki/Documentation/LibertyDocTesting > > We also need to determine which "known issues" need to be resolved, and document + file bugs for any new ones that pop up (and ideally resolve them). In future as part of the RDO test day I think we should: Please add me to bug reports you file for openstack-manuals. I will try to take care of them ASAP. > a) Broadcast where the correct packages are more widely (e.g. include openstack-docs(a)lists.openstack.org in the distribution list for the test day). There seems to be a contention that they weren't available or were available but were mixed up with Mitaka packages which was true at a point in time but was quickly resolved (there was an issue with the config files being shipped though). Which packages should be used for testing Liberty? In the guide we wrote that http://rdo.fedorapeople.org/openstack-liberty/rdo-release-liberty.rpm should be used. This repository is not yet available, so we cannot test with this repository. https://repos.fedorapeople.org/repos/openstack/openstack-liberty/testing/ does not contain any RPM packages. Not sure why this directory is there. > b) Integrate the install guide test matrix into the test day so that we (the RDO community) can help drive vetting it earlier. This is a good idea. Christian. -- Christian Berendt Cloud Solution Architect Mail: berendt(a)b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 _______________________________________________ Rdo-list mailing list Rdo-list(a)redhat.com https://www.redhat.com/mailman/listinfo/rdo-list To unsubscribe: rdo-list-unsubscribe(a)redhat.com

Please add me to bug reports you file for openstack-manuals. I will try to take care of them ASAP.

Which packages should be used for testing Liberty? In the guide we wrote that http://rdo.fedorapeople.org/openstack-liberty/rdo-release-liberty.rpm should be used. This repository is not yet available, so we cannot test with this repository.

https://repos.fedorapeople.org/repos/openstack/openstack-liberty/testing/ does not contain any RPM packages. Not sure why this directory is there.

Packages for Fedora will be also available on Wednesday?

> Which packages should be used for testing Liberty? In the guide we wrote > that > http://rdo.fedorapeople.org/openstack-liberty/rdo-release-liberty.rpm > should be used. This repository is not yet available, so we cannot test > with this repository.