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