<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 8, 2019 at 10:49 PM Ben Nemec <<a href="mailto:openstack@nemebean.com">openstack@nemebean.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
You can find the raw notes on the etherpad <br>
(<a href="https://etherpad.openstack.org/p/oslo-train-topics" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/oslo-train-topics</a>), but hopefully this <br>
will be an easier to read/understand summary.<br>
<br>
Pluggable Policy<br>
----------------<br>
Spec: <a href="https://review.opendev.org/#/c/578719/" rel="noreferrer" target="_blank">https://review.opendev.org/#/c/578719/</a><br>
<br>
Since this sort of ran out of steam last cycle, we discussed the option <br>
of not actually making it pluggable and just explicitly adding support <br>
for other policy backends. The specific one that seems to be of interest <br>
is Open Policy Agent. To do this we would add an option to enable OPA <br>
mode, where all policy checks would be passed through to OPA by default. <br>
An OPACheck class would also be added to facilitate migration (as a rule <br>
is added to OPA, switch the policy to OPACheck. Once all rules are <br>
present, remove the policy file and just turn on the OPA mode).<br>
<br>
However, after some further investigation by Patrick East, it was not <br>
clear if users were asking for this or if the original spec was more of <br>
a "this might be useful" thing. He's following up with some OPA users to <br>
see if they would use such a feature, but at this point it's not clear <br>
whether there is enough demand to justify spending time on it.<br></blockquote><div><br></div><div>The OPA plugin (and the pluggable plugin spec that came from it) was originally made by me to address the dynamic & centralized policy problem. Unfortunately I won't be able to continue this work; so if nobody steps up, I'd have to agree that this can be discarded.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Image Encryption/Decryption Library<br>
-----------------------------------<br>
I mention this mostly because the current plan is _not_ to create a new <br>
Oslo library to enable the feature. The common code between services is <br>
expected to live in os-brick, and there does not appear to be a need to <br>
create a new encryption library to support this (yay!).<br>
<br>
oslo.service SIGHUP bug<br>
-----------------------<br>
This is a problem a number of people have run into recently and there's <br>
been some ongoing, but spotty, discussion of how to deal with it. In <br>
Denver we were able to have some face-to-face discussions and hammer out <br>
a plan to get this fixed. I think we have a fix identified, and now we <br>
just need to get it proposed and tested so we don't regress this in the <br>
future. Most of the prior discussion and a previously proposed fix are <br>
at <a href="https://review.opendev.org/#/c/641907/" rel="noreferrer" target="_blank">https://review.opendev.org/#/c/641907/</a> so if you want to follow this <br>
that's the place to do it.<br>
<br>
In case anyone is interested, it looks like this is a bug that was <br>
introduced with mutable config. Mutable config requires a different type <br>
of service restart, and that was never implemented. Now that most <br>
services are using mutable config, this is much bigger problem.<br>
<br>
Unified Limits and Policy<br>
-------------------------<br>
I won't try to cover everything in detail here, but good progress was <br>
made on both of these topics. There isn't much to do from the Oslo side <br>
for the policy changes, but we identified a plan for an initial <br>
implementation of oslo.limit. There was general agreement that we don't <br>
necessarily have to get it 100% right on the first attempt, we just need <br>
to get something in the repo that people can start prototyping with. <br>
Until we release a 1.0 we aren't committed to any API, so we have <br>
flexibility to iterate.<br>
<br>
For more details, see: <br>
<a href="https://etherpad.openstack.org/p/ptg-train-xproj-nova-keystone" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/ptg-train-xproj-nova-keystone</a><br>
<br>
oslo.service profiling and pypy<br>
-------------------------------<br>
Oslo has dropped support for pypy in general due to lack of maintainers, <br>
so although the profiling work has apparently broken oslo.service under <br>
pypy this isn't something we're likely to address. Based on our <br>
conversation at the PTG game night, it sounds like this isn't a priority <br>
anymore anyway because pypy didn't have the desired performance improvement.<br>
<br>
oslo.privsep eventlet timeout<br>
-----------------------------<br>
AFAICT, oslo.privsep only uses eventlet at all if monkey-patching is <br>
enabled (and then only to make sure it returns the right type of pipe <br>
for the environment). It's doubtful any eventlet exceptions are being <br>
raised from the privsep code, and even if they are they would go away <br>
once monkey-patching in the calling service is disabled. Privsep is <br>
explicitly not depending on eventlet for any of its functionality so <br>
services should be able to freely move away from eventlet if they wish.<br>
<br>
Retrospective<br>
-------------<br>
In general, we got some major features implemented that unblocked things <br>
either users or services were asking for. We did add two cores during <br>
the cycle, but we also lost a long-time Oslo core and some of the other <br>
cores are being pulled away on other projects. So far this has probably <br>
resulted in a net loss in review capacity.<br>
<br>
As a result, our primary actions out of this were to continue watching <br>
for new candidates to join the Oslo team. We have at least one person we <br>
are working closely with and a number of other people approached me at <br>
the event with interest in contributing to one or more Oslo projects. So <br>
while this cycle was a bit of a mixed bag, I have a cautiously <br>
optimistic view of the future.<br>
<br>
Service Healthchecks and Metrics<br>
--------------------------------<br>
Had some initial hallway track discussions about this. The self-healing <br>
SIG is looking into ways to improve the healthcheck and metric situation <br>
in OpenStack, and some of them may require additions or changes in Oslo. <br>
There is quite a bit of discussion (not all of which I have read yet) <br>
related to this on <a href="https://review.opendev.org/#/c/653707/" rel="noreferrer" target="_blank">https://review.opendev.org/#/c/653707/</a><br>
<br>
On the metrics side, there are some notes on the SIG etherpad (currently <br>
around line 209): <a href="https://etherpad.openstack.org/p/DEN-self-healing-SIG" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/DEN-self-healing-SIG</a><br>
<br>
It's still a bit early days for both of these things so plans may <br>
change, but it seems likely that Oslo will be involved to some extent. <br>
Stay tuned.<br>
<br>
Endgame<br>
-------<br>
No spoilers, I promise. If you made it all the way here then thanks and <br>
congrats. :-)<br>
<br>
I hope this was helpful, and if you have any thoughts about anything <br>
above please let me know.<br>
<br>
Thanks.<br>
<br>
-Ben<br>
<br>
<br>
</blockquote></div></div>