March 2019 - openstack-discuss - lists.openstack.org

[nova] "future" specs and blueprints
by Eric Fried 10 Apr '19

10 Apr '19

All- It seems like we don't have a great way of looking at a blueprint and saying, "this looks like a good idea, and yes we want to do it, but we're not going to be able to prioritize it for this release." Sometimes we just leave those blueprints "unspecified" and their specs stay open in limbo. And some blueprints we'll approve for the current series, and merge the spec under $current_cycle/approved, but not really intend to get the work completed. And at the end of the release, those pieces muddy our completion stats. It would be nice if those stats reflected only work we got done that we *intended* to get done. I'm not bringing this up just for the sake of making numbers pretty; it would just be nice to have a crisp picture of the work slated for the current release. And also a way for contributors to propose specs they *don't* intend for the current series, but still want to start discussing (I happen to know of at least one example of this for Train). And also a way to keep track of work we know we want to do eventually, just not now. === TL;DR >>> So I'd like to propose that we set up a "future" series in Launchpad, and a corresponding subdirectory in the specs repo. === TL;DR <<< The process would be pretty much as you would expect, including (but not limited to): - If we decide (e.g. at the PTG) that we like a spec that's proposed under $current/approved, but won't have time for it in the current series, we'll ask the author to move it to future/ and make sure the History section includes "$current: proposed and approved for 'future'". - If we decide in mid-release that we want to defer a blueprint, we can propose a patch to move it from $current/approved to future/ (including a redirect). - If a contributor wants to start work on a spec for a future release, they can propose it directly to the future/ path. - Every cycle when setting goals we can skim through the 'future' items to see if any should be pulled in. In which case we propose a patch to move the file from future/ to $current/approved (including a redirect) which we can fast-approve. - If we decide to flush a spec from 'future', we can move it to a 'rejected' (or 'abandoned'? bikeshed away) folder - but we can sort this part of the process out later. How do folks feel about this idea? -efried .

13 28

[PTG][nova][neutron][cyborg][placement][ironic][cinder] Cross-project PTG planning
by Eric Fried 09 Apr '19

09 Apr '19

All- Starting to plan for Denver, I'd like to get a feel for cross-project sessions involving Nova. I made a pass through the Nova etherpad [1] and started extracting the bits that were obvious cross-project topics with Neutron [2], Cyborg [3], and Placement [4]. In a couple of places where I wasn't sure I left `XPROJ?`. We usually also have cross-project sessions with Cinder and Ironic. I saw no obvious topics with which to seed those etherpads yet, but please do so as they arise. Similarly, if other project teams have topics to discuss with Nova, please create an etherpad and link it from the bottom of [1] and the wiki [5]. Looking at the room schedule [6], how do folks feel about earmarking Friday morning for cross-project sessions? As the etherpads fill up we'll hopefully get a better idea of how much time to schedule for each. And doing it relatively early gives us time to prioritize spillover for Saturday if that becomes necessary. <what is going on in Eric's head?> Why granular etherpads? I'm hoping it will be more manageable than the enormous monolithic etherpad we usually end up with. We often tend to split out some pieces on the fly anyway; just trying to anticipate the need. Besides, granular is my middle name. </what> Thanks, efried [1] https://etherpad.openstack.org/p/nova-ptg-train [2] https://etherpad.openstack.org/p/ptg-train-xproj-nova-neutron [3] https://etherpad.openstack.org/p/ptg-train-xproj-nova-cyborg [4] https://etherpad.openstack.org/p/ptg-train-xproj-nova-placement [5] https://wiki.openstack.org/wiki/PTG/Train/Etherpads [6] https://screenshotscdn.firefoxusercontent.com/images/8c880d0a-b41e-4cea-8ff…

6 5

[TC] PTG Lunch Talks
by Kendall Nelson 08 Apr '19

08 Apr '19

Hello! I think you all have already started to discuss this, but if you haven't, here's the lowdown: You can have 15 min or 30 min on Thursday (we will also have lightning talks from the othe projects attending the PTG after you complete your time) and basically however much time you want on Saturday during lunch (keeping in mind that a lot of people are planning to leave Friday night). Friday is going to be the feedback session so there's not time available lunch that day. tldr; Do you want 15min or 30 min on Thursday? :) -Kendall Nelson

5 6

[zun][k8s][tc] OpenStack Zun become the official provider for Virtual Kubelet
by Hongbin Lu 07 Apr '19

07 Apr '19

Hi all, I have a good news to share. Right now, Zun is officially accepted [1] as OpenStack provider for Virtual Kubelet. A brief introduce. Virtual Kubelet is a CNCF sandbox project that allows cloud providers to implement Kubelet equivalent functionality. Existing providers of Virtual Kubelet are AWS Fargate, Azure Container Instance, etc. I think it is quite important for OpenStack to have a provider implementation in Virtual Kubelet, which basically makes OpenStack align with what other proprietary cloud providers in this territory. OpenStack Zun team is committed to enhance and maintain this provider and offer a great k8s integration experience for our users. Please feel free to reach out the Zun team if there is any inquiries. [1] https://github.com/virtual-kubelet/virtual-kubelet/pull/239 Best regards, Hongbin

5 6

[nova] retire a flavor
by Florian Engelmann 06 Apr '19

06 Apr '19

Hi, I would like to retire old flavors we don't want to be use any more. I guess deleting is the wrong way to retire flavors? I was not able to find any documentation about how the life-cycle of a flavor works. Any help is very welcome. All the best, Florian

6 15

Integration with GuardianKey
by Paulo Angelo 06 Apr '19

06 Apr '19

Hi all, We are trying to integrate OpenStack (Horizon or Keystone) with GuardianKey. However, we have doubts related to the best way to do this and the best point in the code for this integration. GuardianKey is a solution to protect systems against authentication attacks. It uses Machine Learning and analyses the user's behavior, threat intelligence and psychometrics (or behavioral biometrics). The protected system (in the concrete case, OpenStack admin interface) must send an event via REST for the GuardianKey on each login attempt. More info at https:// guardiankey.io . The best way to integrate would be on having a hook in the procedure that process the user credentials submission in OpenStack (the script that receives the POST), something such as: if(<POST IN AUTH FORM>) { boolean loginFailed = checkLogin(); GuardianKeyEvent event = createEventForGuardianKey(username,loginFailed); boolean GuardianKeyValidation = checkGuardianKeyViaREST(event); if(GuardianKeyValidation){ // Allow access } else { // Deny access } } Where is the best place to create this integration? Horizon or Keystone? Is there a way to create a hook for this purpose? Should we create an extension? Any help is welcome. Thank you in advance. Best regards, Paulo Angelo

3 2

[$cinder] Cinder Volume Active/Active Support
by vkalaitzis 05 Apr '19

05 Apr '19

I would like to ask if cinder-volume supports active/active setups. I found that there was a blueprint for adding support (https://blueprints.launchpad.net/cinder/+spec/cinder-volume-active-active-s…) but as far as I am concerned, no official documentation of such feature exists so far. Regards, Bill Vasilis Kalaitzis IT Systems Engineer Telefon: E-Mail: vasilis.kalaitzis(a)noris.gr

7 6

[nova][dev] Fixing eventlet monkey patching in Nova
by Matthew Booth 05 Apr '19

05 Apr '19

We're hitting an issue with eventlet monkey patching in OSP15, which uses python 3.6. The issue manifests as infinite recursion when a nova service connects to another openstack service over SSL. The immediate cause is that we import urllib3 before calling eventlet.monkey_patch(). I can't find the precise details now, but the reason for this relates to initialisation done by either the ssl or urllib3 libraries at import time which is therefore not patched by eventlet. The detail isn't that important, in any case. The issue may just be specific to a particular combination of library versions we're using in OSP, or possibly that our default configuration exercises something we're not doing in the gate. Regardless, unless we change where we monkey patch we're going to hit this again in the future with other library quirks. Our own eventlet best practises say: "When using eventlet.monkey_patch, do it first or not at all."[1] We're not doing that for both types of service: * non-wsgi For non-wsgi services we monkey patch in nova/cmd/__init__.py with the call utils.monkey_patch(). At first glance that appears to be very early, but note that this required importing nova.utils first, which in turn imports the world, and all before monkey patching. I believe this was regressed in Stein by change Ie7bf5d012e2ccbcd63c262ddaf739782afcdaf56[2], which was attempting to fix the wsgi case. * wsgi For wsgi services our entry point is nova.api.openstack.wsgi_app, which calls utils.monkey_patch(). This suffers the same problem as the non-wsgi case, but additionally suffers from having loaded nova/api/openstack/__init__.py first, which also imports the world. Incidentally, as noted in change Ie7bf5d012e2ccbcd63c262ddaf739782afcdaf56 we *do* currently require eventlet in at least the nova api service, even when running as a wsgi service. This has not regressed the wsgi case, though, as that would already have been broken due to the libraries imported by nova/api/openstack/__init__.py. Lee Yarwood originally posted (and I took over from him) https://review.openstack.org/#/c/626952/ with the intention of fixing the wsgi case. We semi-abandoned it because, while the fix seemed to make sense, it didn't fix the wsgi case when tested. I now realise that this is due to the libraries loaded by nova/api/openstack/__init__.py. I have resubmitted this patch as it fixes the non-wsgi case, and also updated the commit message to be accurate according to my current understanding. However, fixing the non-wsgi case is more complicated. We can't do the monkey patching in nova.api.openstack.wsgi_app because nova/api/openstack/__init__.py imports the world. I believe we have 3 options: 1. Don't import the world in nova/api/openstack/__init__.py 2. Change the wsgi entry point to, for eg, nova.wsgi_app 3. Do monkey patching in nova/__init__.py Of the above, I haven't investigated either 1 or 2 in any great detail. I suspect (1) would be quite invasive, and (2) would presumably have a deployment impact. I believe that the reason we haven't previously done (3) has been the desire not to monkey patch in certain circumstances. However, as it stands today we always need eventlet, so (3) seems like an expedient route. The code change required is very small. In testing the above I threw up 2 follow on patches: * https://review.openstack.org/643579 This makes a couple of cleanups, but significantly adds an assertion that problem libraries haven't been imported before monkey patching. As expected, this kills nova-api (wsgi): http://logs.openstack.org/79/643579/1/check/tempest-full-py3/94b0156/contro… but not nova-compute (non-wsgi): http://logs.openstack.org/79/643579/1/check/tempest-full-py3/94b0156/contro… Interestingly, I also bumped the minimum eventlet version in that patch to remove some no-longer-required cruft from oslo_service. If I'm reading this failure correctly, we're pinning eventlet to version 0.18.2 in the gate. Why such an old eventlet? I can't see where this pin is coming from, but my (unsubstantiated) guess is that this is the principal difference from OSP, where we're currently installing eventlet 0.24.1: http://logs.openstack.org/79/643579/1/check/requirements-check/fc9f093/job-… * https://review.openstack.org/#/c/643581/ Here I just switched to top-level monkey patching. This is still running, but at first glance the tempest runs don't seem to have failed early, which they would have given that the patch is stacked on top of the the assertions from the prior patch. TL;DR I want to move monkey patching to nova/__init__.py because, for now at least, we always require it anyway. When we eventually remove the requirement for wsgi services to monkey patch we can move monkey patching back to nova/cmd/__init__.py. Matt [1] https://specs.openstack.org/openstack/openstack-specs/specs/eventlet-best-p… [2] https://review.openstack.org/#/c/592285/ -- Matthew Booth Red Hat OpenStack Engineer, Compute DFG Phone: +442070094448 (UK)

10 19

[tc] Feedback on Kata Containers and Zuul pilot projects
by Jeremy Stanley 05 Apr '19

05 Apr '19

Per the confirmation guidelines[0] and foundation mailing list thread[1], the OSF Board of directors is soliciting feedback from representatives of existing confirmed Open Infrastructure Projects (so far that's just OpenStack) when evaluating the Kata Containers and Zuul pilot projects' upcoming applications for OIP confirmation. Particularly worth calling out, guideline #4 "Open collaboration" asserts the following: Project behaves as a good neighbor to other confirmed and pilot projects. If you (our community at large, not just TC members) have any observations/interactions with the Kata Containers and Zuul maintainers or their software which could serve as useful examples for how these projects do or do not meet this and other guidelines, please provide them in the per-project pads[2][3] and if possible include a citation with links to substantiate your feedback. After March 31, 2019 the information there will be assembled into more cohesive documents and posted to the foundation mailing list in preparation for the scheduled OSF Board of Directors meeting[4] on April 8. [0] https://wiki.openstack.org/wiki/Governance/Foundation/OSFProjectConfirmatio… [1] http://lists.openstack.org/pipermail/foundation/2019-March/002721.html [2] https://etherpad.openstack.org/p/openstack-tc-kata-confirmation-feedback [3] https://etherpad.openstack.org/p/openstack-tc-zuul-confirmation-feedback [4] http://lists.openstack.org/pipermail/foundation/2019-March/002733.html -- Jeremy Stanley

1 2

[kolla] IRC meeting time
by Mark Goddard 04 Apr '19

04 Apr '19

Hi, As discussed in the last weekly meeting [1], I'd like to see if there is a meeting time that better suits our contributor base. Our current meeting slot is on Wednesday at 1500 UTC, which isn't good for contributors in APAC. If you are interested in joining the kolla IRC meetings on an at least semi-regular basis (let's say once per month minimum), please respond here with a broad range of UTC times that generally suit you. Feel free to add ideal/if need be annotations. Non-cores are of course welcome. I'll get the ball rolling. Ideal: 0900 - 1800 UTC If need be: 0800 - 2100 UTC Cheers, Mark

4 4