April 2019 - openstack-discuss - lists.openstack.org

[horizon] Proposing Vishal Manchanda (vishalmanchanda) for core
by Ivan Kolodyazhny 10 Apr '19

10 Apr '19

Hi everybody, I would like to propose adding vishalmanchanda to the horizon-core team. Vishal did a great contribution during the last six months both with commits [1] and reviews [2],[3]. He fixed a lot of bugs not only in a master branch but in stable branches too. Regular quality reviews during the last cycles show that he's on the same page with the rest of the team and understands the code base well too. If there are no objections, I'll add Vishal to the horizon-core team in a week. [1] https://review.openstack.org/#/q/owner:manchandavishal143%2540gmail.com+sta… [2] https://www.stackalytics.com/report/contribution/horizon-group/90 [3] https://www.stackalytics.com/report/contribution/horizon-group/180 Regards, Ivan Kolodyazhny, http://blog.e0ne.info/

1 1

[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

[Openstack-sigs][publiccloud-wg] Reminder weekly meeting Public Cloud WG
by Tobias Rydberg 10 Apr '19

10 Apr '19

Hi everyone, Time for a new meeting for the Public Cloud WG - tomorrow (11th) 1400 UTC in #openstack-publiccloud! Agenda can be found below and at https://etherpad.openstack.org/p/publiccloud-wg Agenda 1. Expose WGs and SIGs 2. Migrating to SIG 3. Planning Summit and PTG - Meeting room at the PTG - Thursday morning - Update status / content in https://launchpad.net/openstack-publiccloud-wg - Select most important 4. Other topics Talk to you tomorrow! Cheers, Tobias -- Tobias Rydberg Senior Developer Twitter & IRC: tobberydberg www.citynetwork.eu | www.citycloud.com INNOVATION THROUGH OPEN IT INFRASTRUCTURE ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED

1 0

[masakari][Release-job-failures] Tag of openstack/masakari failed
by Sean McGinnis 10 Apr '19

10 Apr '19

There were a couple of release note publish failures today for the masakari and masakari-monitors repos. They were due to these repos still using oslosphinx in their docs and releasenotes jobs. With the release of Sphinx 2.0 last week, oslosphinx no longer compatible. All projects should now be using openstackdocstheme and there are no plans to update oslosphinx to work with the new Sphinx version. The following will need to be merged to get these jobs working again. openstack/masakari https://review.openstack.org/651516 openstack/masakari-monitors https://review.openstack.org/651518 Thanks! Sean ----- Forwarded message from zuul(a)openstack.org ----- Date: Wed, 10 Apr 2019 12:20:14 +0000 From: zuul(a)openstack.org To: release-job-failures(a)lists.openstack.org Subject: [Release-job-failures] Tag of openstack/masakari failed Reply-To: openstack-discuss(a)lists.openstack.org Build failed. - publish-openstack-releasenotes-python3 http://logs.openstack.org/31/3191a411fb823913ddfed43e9c44d4e163992ebb/tag/p… : FAILURE in 4m 38s _______________________________________________ Release-job-failures mailing list Release-job-failures(a)lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures ----- End forwarded message -----

1 0

[all] Removing privacy breaches in doc
by Thomas Goirand 10 Apr '19

10 Apr '19

Hi, In may docs, I can see stuff like this, especially in README.rst: .. image:: http://governance.openstack.org/badges/something.svg :target: http://governance.openstack.org/reference/tags/index.html I'd like to let everyone know that, from a package maintainer perspective, and considering that we do package your Sphinx doc in distros, this is an annoyance. Indeed, I do feel like I must patch it out and remove the external source. The reason is, as a Debian user, I do not expect my browser to do external queries to a website when I'm browsing a local documentation. This one is on openstack.org, it's mildly ok-ish, though, I'm removing the image still. There's other more annoying stuff (think: travis, github, and other spies which we don't control). So, it'd be nice if these images with external resources were completely avoided in OpenStack docs. Either by simply not putting such useless image, replacing it by text only, or by embedding the image itself in the doc (or in openstackdocstheme? I suspect that's not what people want, they want it to be displayed in github... so embedding would be the only solution). Cheers, Thomas Goirand (zigo)

8 19

[placement][nova][ptg] NUMA Topology with placement
by Chris Dent 10 Apr '19

10 Apr '19

>From the cross-project etherpad [1] * Spec: https://review.openstack.org/#/c/552924/ This is probably the biggest topic, in the sense that modeling NUMA in placement and how we do that has a big impact across a large number of other pending features, including several specs that state things like "this would be different if we had NUMA in placement". Similarly, if we do have NUMA in placement, we also end up with questions about and requirements with: * json payload for getting allocation candidates: http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004724.ht… * increased complexity in protecting driver provided traits http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004779.ht… * resource provider - request group mapping http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004819.ht… * resource providers with traits but no resources http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004817.ht… * resource provider (subtree) affinity http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004782.ht… And there's probably cascades over to dedicated cpus, cpu capabilities, network bandwidth mgt, etc etc. >From the placement perspective, the problem isn't representing the NUMA info in placement, it's getting candidates back out in a useful fashion once they are in there, so the resources can be claimed. It would be useful if someone could make explicit and enumerate: * What (if any) ways in which the current handling of nested providers does not support _writing_ NUMA-related info to placement. * What (we know there are some) ways the current handling of allocation candidates and the underlying database queries do not support effective use of NUMA info once it is in placement. Thanks. [1] https://etherpad.openstack.org/p/ptg-train-xproj-nova-placement -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

1 0

[placement][nova][ptg] Testing PlacementFixture effectively
by Chris Dent 10 Apr '19

10 Apr '19

>From the cross project etherpad [1] -=-=- * We've had two instances where nova functional tests have failed from what seems like an unrelated change in placement, but turns out to be something that impacts the behavior of the PlacementFixture, from placement, used by nova. Would be good to decide on a way to make this safer without having to run the entire nova functional test suite (and the functional suite of every other project that eventually uses the Fixture) on every placement change. Maybe a subset somehow? Or some other kind of magic? Another option may be what we've been doing: fixing problems as they come up. That might be OK. * https://bugs.launchpad.net/nova/+bug/1818560 * https://bugs.launchpad.net/nova/+bug/1821092 * (gibi): Currently placement patches trigger grenade-py3 and tempest-full-py3 and both jobs takes around an hour to run. The nova-tox-functional test runs in about 20 minutes. So triggering nova-tox-functional for placement patches does not increase the length of the CI feedback loop. * True but the total cpu cost of testing a single placement patch is a thing we need to keep in mind. Zuul resources are scarce. It's not just how long we have to wait, but how long everyone has to wait for all patches. (Not saying we shouldn't do it, just that we need to consider that impact.) (gibi): I agree that overall cpu cost is a factor here. * [efried] ++ I think this is a solid idea, at least until we implement the next bullet. * (gibi): Both above bug could be detected with some test on the placement side using the PlacementFixture in a way nova is using that fixture. It might not be easy to gather all the relevat usage patterns. * [efried] Agree with this. We don't have any testing of PlacementFixture in placement itself (until the below) * [efried] Started simple unit testing here https://review.openstack.org/#/c/645255/ * This probably doesn't do us much good wrt preventing weird gatebusters like the above. -=-=- This is generally agreed to be an issue we need to address and there are ideas for how to fix it, so the things to resolve here are: * Tuning the ideas to the best combination. * Figuring out who is going to do it. [1] https://etherpad.openstack.org/p/ptg-train-xproj-nova-placement -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

1 0

[tripleo][openstack-ansible] collaboration on os_tempest role update XVIII - Apr 10, 2019
by Chandan kumar 10 Apr '19

10 Apr '19

Hello, Here is the 17th update (Apr 03 to Apr 09, 2019) on collaboration on os_tempest[1] role between TripleO and OpenStack-Ansible projects. Highlights of the week: * os_tempest doc build job was broken and bug in generate test-list file task are got fixed * we have added tempest_services var to automatically enable tempest_service_available_{project_name} var. * os_tempest got support of debian distro. * We have added required os_tempest vars in tripleo CI in order to port periodic rdo third party job to os_tempest. Thanks to Arx for tempest_test_whitelist featureset overrides, mnaser for adding debian support and fixing doc job builds across OSA, jrosser, odyssey4me, noonedeadpunk for helping on tempest_services patch. Things got merged: os_tempest * docs: drop sphinxmark - https://review.openstack.org/649859 * Fix Generate test-list file task - https://review.openstack.org/649604 * debian: add support - https://review.openstack.org/650499 * tempest_services var for setting tempest_service_available_{} - https://review.openstack.org/649577 tripleo * Add tempest_test_whitelist to allowed_override - https://review.openstack.org/#/c/648110/ * Remove the tempest_test_whitelist from playbook - https://review.openstack.org/#/c/648111/ * tempest_services var for setting tempest_service_available_{} - https://review.openstack.org/649577 * Include vars of tempest_services and concurrency in fs override - https://review.openstack.org/649553 Things in Progress: os_tempest: * os_tempest user guide: https://review.openstack.org/#/c/644570/ * Switch to import_task in os_tempest - https://review.openstack.org/650054 tripleo * Update Standalone Periodic jobs in Master to use OS_TEMPEST - https://tree.taiga.io/project/tripleo-ci-board/us/972 What is coming? * We are working on porting standalone periodic jobs to os_tempest on RDO side * FInishing Doc user guide Here is the 17th update [2]. Have queries, Feel free to ping us on #tripleo or #openstack-ansible channel. Links: [1.] http://git.openstack.org/cgit/openstack/openstack-ansible-os_tempest [2.] http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004492.ht… Thanks, Chandan Kumar

1 0

[placement][nova][ptg] Use in_tree getting allocation candidates
by Chris Dent 10 Apr '19

10 Apr '19

>From the (cross-project) etherpad [1]: -=-=- * Spec: https://review.openstack.org/#/c/646029/ * Branch: https://review.openstack.org/#/q/topic:bp/use-placement-in-tree * -> This spec and branch proposes to translate [user specified host/node] into [compute node uuid] internally in nova before asking to placement * Discussion point: What to do when an operator specifies only "forced_host" in VM creation with --availability-zone and multiple nodes are found in the DB 1. We use this optimization only when 1 node is found in the nova side DB. Skip this optimization otherwise. 2. We use this optimization whenever possible passing every found compute node uuids. 3. We use this optimization when smaller amount than N node are found in the nova side DB. Skip this optimization otherwise. 3-1. appropriate N value (or the "default" N value) in terms of <REST query string length> and <DB query with IN clause> 4. Others? * Note: Option 2 and 3 needs a change in placement side REST API to accept multiple uuids in the `in_tree` query * Spec: https://review.openstack.org/#/c/651113/ -=-=- >From a placement perspective the main discussion point here is the placement side spec at [2] which is relatively straightforward and low impact: making an existing query parameter more expressive while keeping existing response format. There's some questions (on the spec) about the details of the syntax. There's also a concern about query string length but that's discussed above. [1] https://etherpad.openstack.org/p/ptg-train-xproj-nova-placement [2] https://review.openstack.org/#/c/651113/ -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

1 0

Test
by M Ranga Swami Reddy 10 Apr '19

10 Apr '19

1 0