May 2019 - openstack-discuss - lists.openstack.org

OpenStack User Survey 2019
by Jimmy Mcarthur 16 May '19

16 May '19

It's time for the OpenStack User Survey <https://www.openstack.org/user-survey> [1]! In an effort to create less work for our community, in 2018 we moved to an annual, rather than a bi-annual report. If you run an OpenStack deployment, now is the time to share details about how you run the software and your thoughts on ways that the community can improve the software. Your feedback matters and it's shared directly with the PTLs and community leaders that work to build OpenStack! We had some good community feedback on the last survey and ended up with only minor updates from 2018. Below you can see a list of changes that we've incorporated: * "Which new/emerging technologies are you interested in using or seeing integrated with OpenStack?" o Added options for "AI/ML" and "5G" * Deleted the question "Are you interested in helping our interoperability efforts by using RefStack to test your cloud capabilities?" * "Which tools are you using to deploy / manage this cluster?" o Added the word "manage" to the question as tools can be used for both o Add "TripleO" and "Container-based orchestration" as options o Created a new "Please specify" if "Other tools" is chosen * "Which container orchestration or Platform-as-a-Service (PaaS) tools are you using to manage applications on this OpenStack deployment?" o Added "container orchestration or " to question * "Which OpenStack Network (Neutron) drivers are you using?" o Add Calico as an answer * "Which compatibility APIs does this deployment support?" o Added the option "This deployment doesn't use compatibility APIs" * Please note: This year, we will not be including the hardware and software vendor questions in the report or analytics dashboard due to the potential for the data to be misinterpreted. * *In addition to the question modifications above, we reached out to PTLs to ask for their feedback and guidance on the project specific questions of the survey. We've modified or added those questions as noted below: *Keystone* This will be a question where respondents can rank their choices and will follow their existing question: * Which of the following initiatives would be most beneficial for your deployment? You can rank items by priority with items at the top being most important and items at the bottom being least important. o Improved performance o Better support for synchronizing multiple keystone regions o Read-only RBAC roles o More flexible federated mappings o Improved fine-grained access control o Better support for domain administrators o Improved usability of keystone outside of an OpenStack environment Glance Changed existing question to: * "Multi back-ends feature will stay Experimental in Stein release. How badly this affect your deployment plans? Any details how you’re planning to use it would be helpful.” *Ironic* Changed existing question to: * "What would you find most useful if it was part of Ironic?" *Swift* Changed existing question to: * What features of Swift are you currently using (or have plans to use in the next 12 months)? (select all that apply o S3 compatibility o Dynamic Large Objects o Static Large Objects o Temporary URLs o Data-at-rest encryption o Multiple storage policies o Multi-region clusters o Explicit data placement (composite rings) o Container sync o Static websites or CORS o Symlinks o Quotas o Object versioning If you have further questions, concerns, please let us know. Cheers, Jimmy and Allison [1] https://www.openstack.org/user-survey

7 14

[devstack][tempest][neutron][ironic] Trouble debugging networking issues with devstack/lib/tempest
by Michael Turek 16 May '19

16 May '19

Hey all, We've been having networking issues with our ironic CI job and I'm a bit blocked. Included is a sample run of the job failing [0]. Our job creates a single flat public network at [1]. Everything goes fine until we hit 'lib/tempest'. The job fails trying to create a network [2]. At first I thought this could be because we configure a single physnet which is used by the 'public' network, however I've tried jumping on the node, deleting the 'public' network and creating the network mentioned in lib/tempest and it still fails with: Error while executing command: HttpException: 503, Unable to create the network. No tenant network is available for allocation. Does anyone have any insight into what we're not configuring properly? Any help would be greatly appreciated! Thanks! Mike Turek <mjturek on freenode> [0] https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-1… [1] https://github.com/openstack/devstack/blob/master/stack.sh#L1348 [2] https://github.com/openstack/devstack/blob/master/lib/tempest#L256

2 2

[Tacker][dev] Scaling and auto-healing functions for VNFFG
by Hochan Lee 15 May '19

15 May '19

Hello tacker team and all, I'm hochan lee and graduate student from korea univ. Our team is interested in SFC and VNFFG, especially HA of VNFFG. We are intereseted in scaling and auto-healing functions for VNFFG proposed in Tacker Pike Specifications. https://specs.openstack.org/openstack/tacker-specs/specs/pike/vnffg-scaling… https://specs.openstack.org/openstack/tacker-specs/specs/pike/vnffg-autohea… We think these functions hadn't been developed yet. Are these features currently being developed? If not, can we go on developing these features for contribution? We wanna join next tacker weekly meeting and discuss them. Thanks,

3 2

[all] [TC] [elections] Proposed Dates
by Kendall Nelson 15 May '19

15 May '19

Hello Everyone! So, basically if we follow the usual formulas for when to hold the TC and PTL elections, they overlap a bit but not nicely. You can see what the dates would be if we exactly followed the usual timeline in this etherpad[1]. The proposal from the election officials is that we move the PTL nominations 1 week early and that gives them 1-week idle time in which we *could* do campaigning for PTLs the same way we do campaigning for TC seats. We definitely don't have to do campaigning, it could just be a week of idle time while TC campaigning happens. Setting Combined Election Summit is at: 2019-11-04 Release is at: 2019-10-14 Latest possible completion is at: 2019-09-23 Moving back to Tuesday: 2019-09-17 TC Election from 2019-09-10T23:45 to 2019-09-17T23:45 PTL Election from 2019-09-10T23:45 to 2019-09-17T23:45 TC Campaigning from 2019-09-03T23:45 to 2019-09-10T23:45 TC Nominations from 2019-08-27T23:45 to 2019-09-03T23:45 PTL Nominations from 2019-08-27T23:45 to 2019-09-03T23:45 Set email_deadline to 2019-09-03T00:00 Setting TC timeframe end to email_deadline Beginning of Stein Cycle @ 2018-08-10 00:00:00+00:00 End of Train cycle @ 2019-09-03 00:00:00+00:00 Election timeframe: 389 days, 0:00:00s This format makes it easier for election officials since we would only need to generate the electorate once for both elections. We can create whatever polls we need to for PTL elections at the same time we make the TC election poll. All in all less confusing for the electorate as well (hopefully). Thanks! -Kendall Nelson (diablo_rojo) & the election officials [1] https://etherpad.openstack.org/p/election-train-ptg

4 4

[Cinder][Tempest] All-plugin is deprecated, what do we do now?
by Matt Smith 15 May '19

15 May '19

Hey Folks, First time posting to the mailing list, so hopefully I got this right. Anyways, Tempest complains when I use 'all-plugin' and says it's deprecated. Cinder has Tempest plugins that were triggered by using 'all-plugin' instead of 'all' and now I don't know how I'm supposed to run those plugins as well. My guess is that 'all' now includes plugins? Or maybe there's an alternative for running plugins? Regards, Matt --- Matthew Smith Software Engineer mss(a)datera.io 214-223-0887

2 1

[magnum] Magnum support Fedora coreOS plan
by 黄向东 15 May '19

15 May '19

Hi, All Fedora Atomic 29 released on 29 April and it's the last release of Fedora Atomic, Fedora community launched Fedora CoreOS as a replacement of Fedora Atomic, Does Magnum have bp to supoort Fedora Core + k8s ? Regardsxiangdong

2 1

[magnum] Magnum support Fedora coreOS plan
by 黄向东 15 May '19

15 May '19

Hi, All Fedora Atomic 29 released on 29 April and it's the last release of Fedora Atomic, Fedora community launched Fedora CoreOS as a t

1 0

[dev] [tacker] Prometheus Plugin for VNF Monitoring Cover
by Jaewook Oh 15 May '19

15 May '19

Hello Tacker team, and Trinh. As I said in the vPTG, I want to cover the blueprint "*Prometheus Plugin for VNF Monitoring in Tacker VNF Manager*" ( https://blueprints.launchpad.net/tacker/+spec/prometheus-plugin) This blueprint is not updated for long time, and also no development is not in progress. So Trinh, can I update the spec and develop that plugin if you don't mind? Best Regards, Jaewook. ================================================ *Jaewook Oh* (오재욱) IISTRC - Internet Infra System Technology Research Center 369 Sangdo-ro, Dongjak-gu, 06978, Seoul, Republic of Korea Tel : +82-2-820-0841 | Mobile : +82-10-9924-2618 E-mail : jwoh95(a)dcn.ssu.ac.kr ================================================

2 5

[watcher] Compute CDM builder issues (mostly perf related)
by Matt Riedemann 15 May '19

15 May '19

Hi all, I was looking over the NovaClusterDataModelCollector code today and trying to learn more about how watcher builds the nova CDM (and when) and got digging into this change from Stein [1] where I noted what appear to be several issues. I'd like to enumerate a few of those issues here and then figure out how to proceed. 1. In general, a lot of this code for building the compute node model is based on at least using the 2.53 microversion (Pike) in nova where the hypervisor.id is a UUID - this is actually necessary for a multi-cell environment like CERN. The nova_client.api_version config option already defaults to 2.56 which was in Queens. I'm not sure what the compatibility matrix looks like for Watcher, but would it be possible for us to say that Watcher requires nova at least at Queens level API (so nova_client.api_version >= 2.60), add a release note and a "watcher-status upgrade check" if necessary. This might make things a bit cleaner in the nova CDM code to know we can rely on a given minimum version. 2. I had a question about when the nova CDM gets built now [2]. It looks like the nova CDM only gets built when there is an audit? But I thought the CDM was supposed to get built on start of the decision-engine service and then refreshed every hour (by default) on a periodic task or as notifications are processed that change the model. Does this mean the nova CDM is rebuilt fresh whenever there is an audit even if the audit is not scoped? If so, isn't that potentially inefficient (and an unnecessary load on the compute API every time an audit runs?). 3. The host_aggregates and availability_zone compute audit scopes don't appear to be documented in the docs or the API reference, just the spec [3]. Should I open a docs bug about what are the supported audit scopes and how they work (it looks like the host_aggregates scope works for aggregate ids or names and availability_zone scope works for AZ names). 4. There are a couple of issues with how the unscoped compute nodes are retrieved from nova [4]. a) With microversion 2.33 there is a server-side configurable limit applied when listing hypervisors (defaults to 1000). In a large cloud this could be a problem since the watch client-side code is not paging. b) The code is listing hypervisors with details, but then throwing away those details to just get the hypervisor_hostname, then iterating over each of those node names and getting the details per hypervisor again. I see why this is done because of the scope vs unscoped cases, but we could still optimize this I think (we might need some changes to python-novaclient for this though, which should be easy enough to add). 5. For each server on a node, we get the details of the server in separate API calls to nova [5]. Why can't we just do a GET /servers/detail and filter on "host" or "node" so it's a single API call to nova per hypervisor? I'm happy to work on any of this but if there are any reasons things need to be done this way please let me know before I get started. Also, how would the core team like these kinds of improvements tracked? With bugs? [1] https://review.opendev.org/#/c/640585/ [2] https://review.opendev.org/#/c/640585/10/watcher/decision_engine/model/coll… [3] https://specs.openstack.org/openstack/watcher-specs/specs/stein/implemented… [4] https://review.opendev.org/#/c/640585/10/watcher/decision_engine/model/coll… [5] https://review.opendev.org/#/c/640585/10/watcher/decision_engine/model/coll… -- Thanks, Matt

2 9

[OSC][PTG] Summary: many things to do!
by Dean Troyer 15 May '19

15 May '19

OpenStackClient held a session at the Denver PTG and despite not having much planned had plenty to talk about. Some of the highlights from the etherpad[0] are: * Aretm is working on changing the Image commands to use OpenStackSDK. This is the work described in the cycle goal proposal[1] that he is planning to do anyway. I support going ahead with this even without an SDK 1.0 release as it lets us remove glanceclient and some of its unique dependencies. * There was some discussion about image encryption and where the client-side bits of that may land. One option was to put it into os-brick; if that is where it winds up OSC will make that an optional dependency de to the number of other dependencies that will introduce. (ie, OSC currently uses very little of oslo, some of which brings in a number of things not otherwise needed client-side). * Doug brought up the problems with load times due to scanning the entire import path on every invocation. I found in my notes almost exactly 2 years ago where we discussed this same topic. AS we did then, the idea of skipping entry points entirely for commands in the OSC repo is the best solution we have found. This would help some common cases but still leave all plugins with slow load times. * Nate Johnston asked about supporting bulk create APIs, such as Neutron's bulk port create. After kicking around a couple of options the rough consensus is around using a YAML file (or JSON or both?) to define the resources to be created and giving it to a new top-level 'create' command (yes, verb only, the resource names will be in the YAML file). APIs that allow bulk creates will get a single call with the entire list, for other APIs we can loop and feed them one at a time. This would be very similar to using interactive mode and feeding in a list of commands, stopping at the first failure. Note that delete commands already take multiple resource identifiers, adding the ability to source that list from YAML would be an easy addition. * OSC4 has been waiting in a feature branch for over 2 years (where has that PTL been???). I recently tried to merge master in to see how far off it was, it was enough that I think we should just cherry-pick the commites in that branch to master and move forward. So the current plan is to: * do one more release in the 3.x series to clean up outstanding things * switch to OSC4 development, cherry pick in amotoki's existing commits[2] (mostly changes to output formatting) * refresh and merge other reviews in the osc4 topic * remove all of the backward-compatibility code in the OSC authentication process so OSC will now work like all other pure keystoneauth- and sdk-using code. Also relevant to OSC but covered in a Nova Forum session[3,4], highlights: * boot-from-volume: Support type=image for the --block-device-mapping, and Add a --boot-from-volume option which will translate to a root --block-device-mapping using the provided --image value * server migrate --live: deprecate the --live option and add a new --live-migration option and a --host option * compute migration: begin exposing this resource in the CLI dt [0] https://etherpad.openstack.org/p/train-ptg-osc [1] https://review.opendev.org/#/c/639376/ [2] this series starts at https://review.opendev.org/#/c/657907/ [3] https://etherpad.openstack.org/p/DEN-osc-compute-api-gaps [4] http://lists.openstack.org/pipermail/openstack-discuss/2019-May/005783.html -- Dean Troyer dtroyer(a)gmail.com

8 12