<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I can’t see <div class=""><br class=""></div><div class=""><a href="https://docs.google.com/presentation/d/e/2PACX-1vQpaSSm7Amk9q4sBEAUi_IpyJ4l07qd3t5T_BPZkdLWfYbtSpSmF7obSB1qRGA65wjiiq2Sb7H2ylJo/pub?start=false&loop=false&delayms=3000&slide=id.p" class="">https://docs.google.com/presentation/d/e/2PACX-1vQpaSSm7Amk9q4sBEAUi_IpyJ4l07qd3t5T_BPZkdLWfYbtSpSmF7obSB1qRGA65wjiiq2Sb7H2ylJo/pub?start=false&loop=false&delayms=3000&slide=id.p</a></div><div class=""><br class=""></div><div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Mar 12, 2018, at 11:39 AM, Ken Giusti <<a href="mailto:kgiusti@gmail.com" class="">kgiusti@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi Josh - I'm able to view all of them, but I probably have special<br class="">google powers ;)<br class=""><br class="">Which links are broken for you?<br class=""><br class="">thanks,<br class=""><br class="">On Thu, Mar 8, 2018 at 3:53 PM, Joshua Harlow <<a href="mailto:harlowja@fastmail.com" class="">harlowja@fastmail.com</a>> wrote:<br class=""><blockquote type="cite" class=""><br class="">Can we get some of those doc links opened.<br class=""><br class="">'You need permission to access this published document.' I am getting for a<br class="">few of them :(<br class=""><br class=""><br class="">Ben Nemec wrote:<br class=""><blockquote type="cite" class=""><br class="">Hi,<br class=""><br class="">Here's my summary of the discussions we had in the Oslo room at the PTG.<br class="">Please feel free to reply with any additions if I missed something or<br class="">correct anything I've misrepresented.<br class=""><br class="">oslo.config drivers for secret management<br class="">-----------------------------------------<br class=""><br class="">The oslo.config implementation is in progress, while the Castellan<br class="">driver still needs to be written. We want to land this early in Rocky as<br class="">it is a significant change in architecture for oslo.config and we want<br class="">it to be well-exercised before release.<br class=""><br class="">There are discussions with the TripleO team around adding support for<br class="">this feature to its deployment tooling and there will be a functional<br class="">test job for the Castellan driver with Custodia.<br class=""><br class="">There is a weekly meeting in #openstack-meeting-3 on Tuesdays at 1600<br class="">UTC for discussion of this feature.<br class=""><br class="">oslo.config driver implementation: <a href="https://review.openstack.org/#/c/513844" class="">https://review.openstack.org/#/c/513844</a><br class="">spec:<br class=""><br class=""><a href="https://specs.openstack.org/openstack/oslo-specs/specs/queens/oslo-config-drivers.html" class="">https://specs.openstack.org/openstack/oslo-specs/specs/queens/oslo-config-drivers.html</a><br class=""><br class="">Custodia key management support for Castellan:<br class="">https://review.openstack.org/#/c/515190/<br class=""><br class="">"stable" libraries<br class="">------------------<br class=""><br class="">Some of the Oslo libraries are in a mature state where there are very<br class="">few, if any, meaningful changes to them. With the removal of the<br class="">requirements sync process in Rocky, we may need to change the release<br class="">process for these libraries. My understanding was that there were no<br class="">immediate action items for this, but it was something we need to be<br class="">aware of.<br class=""><br class="">dropping support for mox3<br class="">-------------------------<br class=""><br class="">There was some concern that no one from the Oslo team is actually in a<br class="">position to support mox3 if something were to break (such as happened in<br class="">some libraries with Python 3.6). Since there is a community goal to<br class="">remove mox from all OpenStack projects in Rocky this will hopefully not<br class="">be a long-term problem, but there was some discussion that if projects<br class="">needed to keep mox for some reason that they would be asked to provide a<br class="">maintainer for mox3. This topic is kind of on hold pending the outcome<br class="">of the community goal this cycle.<br class=""><br class="">automatic configuration migration on upgrade<br class="">--------------------------------------------<br class=""><br class="">There is a desire for oslo.config to provide a mechanism to<br class="">automatically migrate deprecated options to their new location on<br class="">version upgrades. This is a fairly complex topic that I can't cover<br class="">adequately in a summary email, but there is a spec proposed at<br class="">https://review.openstack.org/#/c/520043/ and POC changes at<br class="">https://review.openstack.org/#/c/526314/ and<br class="">https://review.openstack.org/#/c/526261/<br class=""><br class="">One outcome of the discussion was that in the initial version we would<br class="">not try to handle complex migrations, such as the one that happened when<br class="">we combined all of the separate rabbit connection opts into a single<br class="">connection string. To start with we will just raise a warning to the<br class="">user that they need to handle those manually, but a templated or<br class="">hook-based method of automating those migrations could be added as a<br class="">follow-up if there is sufficient demand.<br class=""><br class="">oslo.messaging plans<br class="">--------------------<br class=""><br class="">There was quite a bit discussed under this topic. I'm going to break it<br class="">down into sub-topics for clarity.<br class=""><br class="">oslo.messaging heartbeats<br class="">=========================<br class=""><br class="">Everyone seemed to be in favor of this feature, so we anticipate<br class="">development moving forward in Rocky. There is an initial patch proposed<br class="">at https://review.openstack.org/546763<br class=""><br class="">We felt that it should be possible to opt in and out of the feature, and<br class="">that the configuration should be done at the application level. This<br class="">should _not_ be an operator decision as they do not have the knowledge<br class="">to make it sanely.<br class=""><br class="">There was also a desire to have a TTL for messages.<br class=""><br class="">bug cleanup<br class="">===========<br class=""><br class="">There are quite a few launchpad bugs open against oslo.messaging that<br class="">were reported against old, now unsupported versions. Since we have the<br class="">launchpad bug expirer enabled in Oslo the action item proposed for such<br class="">bugs was to mark them incomplete and ask the reporter to confirm that<br class="">they still occur against a supported version. This way bugs that don't<br class="">reproduce or where the reporter has lost interest will eventually be<br class="">closed automatically, but bugs that do still exist can be updated with<br class="">more current information.<br class=""><br class="">deprecations<br class="">============<br class=""><br class="">The Pika driver will be deprecated in Rocky. To our knowledge, no one<br class="">has ever used it and there are no known benefits over the existing<br class="">Rabbit driver.<br class=""><br class="">Once again, the ZeroMQ driver was proposed for deprecation as well. The<br class="">CI jobs for ZMQ have been broken for a while, and there doesn't seem to<br class="">be much interest in maintaining them. Furthermore, the breakage seems to<br class="">be a fundamental problem with the driver that would require non-trivial<br class="">work to fix.<br class=""><br class="">Given that ZMQ has been a consistent pain point in oslo.messaging over<br class="">the past few years, it was proposed that if someone does step forward<br class="">and want to maintain it going forward then we should split the driver<br class="">off into its own library which could then have its own core team and<br class="">iterate independently of oslo.messaging. However, at this time the plan<br class="">is to propose the deprecation and start that discussion first.<br class=""><br class="">CI<br class="">==<br class=""><br class="">Need to migrate oslo.messaging to zuulv3 native jobs. The<br class="">openstackclient library was proposed as a good example of how to do so.<br class=""><br class="">We also want to have voting hybrid messaging jobs (where the<br class="">notification and rpc messages are sent via different backends). We will<br class="">define a devstack job variant that other projects can turn on if desired.<br class=""><br class="">We also want to add amqp1 support to pifpaf for functional testing.<br class=""><br class="">Low level messaging API<br class="">=======================<br class=""><br class="">A proposal for a new oslo.messaging API to expose lower level messaging<br class="">functionality was proposed. There is a presentation at<br class=""><br class="">https://docs.google.com/presentation/d/1mCOGwROmpJvsBgCTFKo4PnK6s8DkDVCp1qnRnoKL_Yo/edit?usp=sharing<br class=""><br class=""><br class="">This seemed to generally be well-received by the room, and dragonflow<br class="">and neutron reviewers were suggested for the spec.<br class=""><br class="">Kafka<br class="">=====<br class=""><br class="">Andy Smith gave an update on the status of the Kafka driver. Currently<br class="">it is still experimental, and intended to be used for notifications<br class="">only. There is a presentation with more details in<br class=""><br class="">https://docs.google.com/presentation/d/e/2PACX-1vQpaSSm7Amk9q4sBEAUi_IpyJ4l07qd3t5T_BPZkdLWfYbtSpSmF7obSB1qRGA65wjiiq2Sb7H2ylJo/pub?start=false&loop=false&delayms=3000&slide=id.p<br class=""><br class=""><br class="">testing for Edge/FEMDC use cases<br class="">================================<br class=""><br class="">Matthieu Simonin gave a presentation about the testing he has done<br class="">related to messaging in the Edge/FEMDC scenario where messaging targets<br class="">might be widely distributed. The slides can be found at<br class=""><br class="">https://docs.google.com/presentation/d/1LcF8WcihRDOGmOPIU1aUlkFd1XkHXEnaxIoLmRN4iXw/edit#slide=id.p3<br class=""><br class=""><br class="">In short, there is a desire to build clouds that have widely distributed<br class="">nodes such that content can be delivered to users from a location as<br class="">close as possible. This puts a lot of pressure on the messaging layer as<br class="">compute nodes (for example) could be halfway around the world from the<br class="">control nodes, which is problematic for a broker-based system such as<br class="">Rabbit. There is some very interesting data comparing Rabbit with a more<br class="">distributed AMQP1 system based on qpid-dispatch-router. In short, the<br class="">distributed system performed much better for this use case, although<br class="">there was still some concern raised about the memory usage on the client<br class="">side with both drivers. Some followup is needed on the oslo.messaging<br class="">side to make sure we aren't leaking/wasting resources in some messaging<br class="">scenarios.<br class=""><br class="">For further details I suggest taking a look at the presentation.<br class=""><br class="">mutable configuration<br class="">---------------------<br class=""><br class="">This is also a community goal for Rocky, and Chang Bo is driving its<br class="">adoption. There was some discussion of how to test it, and also that we<br class="">should provide an example of turning on mutability for the debug option<br class="">since that is the target of the community goal. The cinder patch can be<br class="">found here: https://review.openstack.org/#/c/464028/ Turns out it's<br class="">really simple!<br class=""><br class="">Nova is also using this functionality for more complex options related<br class="">to upgrades, so that would be a good place to look for more advanced use<br class="">cases.<br class=""><br class="">Full documentation for the mutable config options is at<br class="">https://docs.openstack.org/oslo.config/latest/reference/mutable.html<br class=""><br class="">The goal status is being tracked in<br class="">https://storyboard.openstack.org/#!/story/2001545<br class=""><br class="">Chang Bo was also going to talk to Lance about possibly coming up with a<br class="">burndown chart like the one he had for the policy in code work.<br class=""><br class="">oslo healthcheck middleware<br class="">---------------------------<br class=""><br class="">As this ended up being the only major topic for the afternoon, the<br class="">session was unfortunately lightly attended. However, the self-healing<br class="">SIG was talking about related topics at the same time so we ended up<br class="">moving to that room and had a good discussion.<br class=""><br class="">Overall the feature seemed to be well-received. There is some security<br class="">concern with exposing service information over an un-authenticated<br class="">endpoint, but because there is no authentication supported by the health<br class="">checking functionality in things like Kubernetes or HAProxy this is<br class="">unavoidable. The feature won't be mandatory, so if this exposure is<br class="">unacceptable it can be turned off (with a corresponding loss of<br class="">functionality, of course).<br class=""><br class="">There was also some discussion of dropping the asynchronous nature of<br class="">the checks in the initial version in order to keep the complexity to a<br class="">minimum. Asynchronous testing can always be added later if it proves<br class="">necessary.<br class=""><br class="">The full spec is at https://review.openstack.org/#/c/531456<br class=""><br class="">oslo.config strict validation<br class="">-----------------------------<br class=""><br class="">I actually had discussions with multiple people about this during the<br class="">week. In both cases, they were just looking for a minimal amount of<br class="">validation that would catch an error such at "devug=True". Such a<br class="">validation might be fairly simple to write now that we have the<br class="">YAML-based sample config with (ideally) information about all the<br class="">options available to set in a project. It should be possible to compare<br class="">the options set in the config file with the ones listed in the sample<br class="">config and raise warnings for any that don't exist.<br class=""><br class="">There is also a more complete validation spec at<br class=""><br class="">http://specs.openstack.org/openstack/oslo-specs/specs/ocata/oslo-validator.html<br class="">and a patch proposed at https://review.openstack.org/#/c/384559/<br class=""><br class="">Unfortunately there has been little movement on that as of late, so it<br class="">might be worthwhile to implement something more minimalist initially and<br class="">then build from there. The existing patch is quite significant and<br class="">difficult to review.<br class=""><br class="">Conclusion<br class="">----------<br class=""><br class="">I feel like there were a lot of good discussions at the PTG and we have<br class="">plenty of work to keep the small Oslo team busy for the Rocky cycle. :-)<br class=""><br class="">Thanks to everyone who participated and I look forward to seeing how<br class="">much progress we've made at the next Summit and PTG.<br class=""><br class="">-Ben<br class=""><br class="">__________________________________________________________________________<br class="">OpenStack Development Mailing List (not for usage questions)<br class="">Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br class=""></blockquote><br class=""><br class="">__________________________________________________________________________<br class="">OpenStack Development Mailing List (not for usage questions)<br class="">Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" class="">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br class=""><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class=""></blockquote><br class=""><br class=""><br class="">-- <br class="">Ken Giusti (<a href="mailto:kgiusti@gmail.com" class="">kgiusti@gmail.com</a>)<br class=""><br class="">__________________________________________________________________________<br class="">OpenStack Development Mailing List (not for usage questions)<br class="">Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" class="">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br class=""><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class=""></div></div></blockquote></div><br class=""></div></body></html>