August 2019 - openstack-discuss - lists.openstack.org

[tc] weekly update
by Mohammed Naser 26 Aug '19

26 Aug '19

Hi everyone, Here’s the update for what happened in the OpenStack TC this week. You can get more information by checking for changes in openstack/governance repository. # New projects - ansible-role-uwsgi (under openstack-ansible-roles): https://review.opendev.org/#/c/676193/ # General changes - Updated list of extra-atcs for Train (I18n): https://review.opendev.org/#/c/674049/ - Update of goal selection retrospective (unowned goals in etherpad and owned goals in repository): https://review.opendev.org/#/c/667932/ Thanks for tuning in! Regards, Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

1 0

[all][tc] A web tool which helps administrators in managing openstack clusters
by Douglas Zhang 26 Aug '19

26 Aug '19

Hello everyone, To help users interact with openstack, we’re currently developing a client-side web tool which enables administrators to manage their openstack cluster in a more efficient and convenient way. (Since we have not named it officially yet, I’m going to call it openstack-admin) *# Introduction* Some may ask, “Why do we need an extra web-based user interface since we have horizon?” Well, although horizon is a mature and powerful dashboard, it is far not efficient enough on big clusters (a simple list operation could take seconds to complete). What’s more, its flexibility of searching could not match our requirements. To overcome obstacles above, a more efficient tool is urgently required, that’s why we started to develop openstack-admin. *# Highlights* Comparing with the current user interface, openstack-admin has following advantages: - *Fast*: openstack-admin gets data straightly from SQL databases instead of calling standard openstack API, which accelerates the querying period to a large extent (especially when we’re dealing with a large amount of data). - *Flexible*: openstack-admin supports the fuzzy search for any important field(e.g. display_name/uuid/ip_address/project_name of an instance), which enables users to locate a particular object in no time. - *User-friendly*: the backend of openstack-admin gets necessary messages from the message queue used by nova, and send them to the frontend using websocket. This way, not only more realistic progress bars could be implemented, but more detailed information could be provided to users as well. *# Issues* To make this tool more efficient and provide better support for concurrency, we chose Golang to implement openstack-admin. As I’ve asked before (truly appreciate advises from Jeremy and Ghanshyam), a project written by an unofficial language may be accepted only if existing languages have been proven to not meet the technical requirements, so we’re considering re-implementing openstack-admin using python if we can’t come to an agreement on the language issue. So that’s all. How do you guys think of this project? Thanks, Douglas Zhang

10 9

[horizon] No meeting this week
by Ivan Kolodyazhny 26 Aug '19

26 Aug '19

Hi team, As mentioned during the last meeting, I can't chair the meeting this week. Let's skip it or you can make it without my presence. Regards, Ivan Kolodyazhny, http://blog.e0ne.info/

1 0

[uc]The UC Special Election Nomination Period is now open!
by Ed Leafe 26 Aug '19

26 Aug '19

The recent election for the two open seats on the User Committee had only one nomination, so one seat remains open. The UC decided to hold a second, special election to fill that seat. The nomination period for this special election is now open, and will remain open until August 30 at 05:59 UTC. If there is more than one candidate, the voting period will begin September 1 at 11:59 UTC, and close on September 4 at 11:59 UTC. Any individual member of the Foundation who is an Active User Contributor (AUC) can propose their candidacy (except the 4 sitting UC members). Self-nomination is common; no third party nomination is required. They do so by sending an email to the user-committee(a)lists.openstack.orgmailing-list, with the subject: “UC candidacy” by August 30, 05:59 UTC. Please note that you must be a subscriber to the user-committee list for your nomination to be posted. Subscribing is free, and can be done on this page [0]. The email can include a description of the candidate platform. The candidacy is then confirmed by one of the election officials, after verification of the electorate status of the candidate. [0] http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee -- Ed Leafe

1 0

[Telemetry][PTL]Lingxian Kong & Zhu Rong as co-PTLs for U release
by Trinh Nguyen 26 Aug '19

26 Aug '19

Hi team, As the PTL election period is coming up. I would like to discuss the PTL role for Telemetry in the U cycle. As I changed job recently, I don't think I have enough time budget for the 2 projects (Searchlight and Telemetry) so I talked to Lingxinan Kong (lxkong) and Zhu Rong (zhurong) and they agreed to share the responsibility as co-PTLs for Telemetry for next release. lxkong and zhurong has been very actively contributing to Telemetry in Train and being very helpful as core-reviewers. So I would like to endorse and nominate the two as co-PTLs for Telemetry for the U release. Though I will not be the PTL for Telemetry in the next cycle, I will still be around helping when needed. The next step for lxkong and zhurong is submitting a patchset nominating for the PTLs. Bests, -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

2 2

[nova][glance][cinder] How to do consistent snapshots with quemu-guest-agent
by Teckelmann, Ralf, NMU-OIP 26 Aug '19

26 Aug '19

Hello, Working me through documentation and articles I am totally lost on the matter. All I want to know is: - if issueing "openstack snapshot create ...." - if klicking "create Snaphost" in Horizon for an instance will secure a consistent snapshot (of all volumes in question). With "consistent", I mean that all the data in memory are written to the disc before starting a snapshot. I hope someone can clear up, if using the setup described in the following is sufficient to achieve this goal or if I have to do something in addition. If you have any question I am eager to answer as fast as possible. Setup: We have a Stein-based OpenStack deployment with cinder backed by ceph. Instances are created with cinder volumes. Boot volumes are based on an image having the properties: - hw_qemu_guest_agent='yes' - os_require_quiesce='yes' The image is ubuntu 16.04 or 18.04 with quemu-guest-agent package installed and service running (no additional configuration besides distro-default): qemu-guest-agent.service - LSB: QEMU Guest Agent startup script Loaded: loaded (/etc/init.d/qemu-guest-agent; bad; vendor preset: enabled) Active: active (running) since Wed 2019-08-14 07:42:21 UTC; 9min ago Docs: man:systemd-sysv-generator(8) CGroup: /system.slice/qemu-guest-agent.service └─2300 /usr/sbin/qemu-ga --daemonize -m virtio-serial -p /dev/virtio-ports/org.qemu.guest_agent.0 Aug 14 07:42:21 ulthwe systemd[1]: Starting LSB: QEMU Guest Agent startup script... Aug 14 07:42:21 ulthwe systemd[1]: Started LSB: QEMU Guest Agent startup script. I can see the socket on the compute node and send pings successfully: ~# ls /var/lib/libvirt/qemu/*.sock /var/lib/libvirt/qemu/org.qemu.guest_agent.0.instance-0000248e.sock root@pcevh2404:~# virsh qemu-agent-command instance-0000248e '{"execute":"guest-ping"}' {"return":{}} I can also send freeze and thaw successfully: ~# virsh qemu-agent-command instance-0000248e '{"execute":"guest-fsfreeze-freeze"}' {"return":1} ~# virsh qemu-agent-command instance-0000248e '{"execute":"guest-fsfreeze-thaw"}' {"return":1} Sending a simple write (echo "bla" > blub.file) in the "frozen" state will be blocked until "thaw" as expected. Best regards Ralf T.

2 3

[tc] Release naming process
by corvus＠inaugust.com 26 Aug '19

26 Aug '19

Hi, In the previous thread about the U release name, we discussed how the actual process for selecting the name has diverged from the written process. I think it's important that we follow our own processes, so we should reconcile those. We should change our actions or change the process. Based on the previous discussion, I've proposed 6 changes to openstack/governance for some initial feedback. We can, of course, tweak these options, eliminate them, or add new ones. Ultimately, we're aiming for the TC to formally vote on one or a small number of changes similar to these. I'd like for anyone interested in this to review these options and leave feedback on the changes themselves, or here on the mailing list. Either is fine, and all will be considered. Leaving "code-review" votes on the changes themselves will help us gauge relative support for the different options. In a week, I'll collect the feedback and propose a next step. https://review.opendev.org/675788 - Stop naming releases https://review.opendev.org/677745 - Name releases after major cities https://review.opendev.org/677746 - Name releases after the ICAO alphabet https://review.opendev.org/677747 - Ask the Foundation to name releases https://review.opendev.org/677748 - Name releases after random words https://review.opendev.org/677749 - Clarify the existing release naming process The last one is worth particular mention -- it keeps the current process with some minor clarifications. -Jim

6 6

[ops] technical agenda for upcoming ops meetup, NYC
by Chris Morgan 25 Aug '19

25 Aug '19

We are still looking for topics and topic feebdack for the ops meetup. The planning sheet is here https://etherpad.openstack.org/p/NYC19-OPS-MEETUP Please if you are coming +1 topics you like or add more. More detail on this such as links and descriptions of the sessions we've already planned is tweeted on the ops meetups notification twitter account : https://twitter.com/osopsmeetup Chris -- Chris Morgan <mihalis68(a)gmail.com>

1 0

[all] PTG Attendance
by Kendall Nelson 25 Aug '19

25 Aug '19

Hello Everyone! This is the list of groups that are plannning on attending the PTG. Thank you PTLs/Chairs/Leads that responded on time :) I hesitate to say it's the 'final' list since I had a few groups respond with a 'Maybe', but it's probably pretty close. Please also note that the tentative activities at the PTG vary by group. Some groups are planning on only doing onboarding for example. Without further ado, here is the list! Airship Auto-Scaling SIG Barbican Blazar CInder Cyborg Edge Computing Group Fenix First Contact SIG Gitea Glance Heat Horizon I18n Ironic K8s SIG Karbor Kata Containers Keystone Loci Manila Meta SIG Monasca Neutron Nova Octavia OpenStack Charms OpenStack Infra / OpenDev OpenStack TC Openstack-helm OpenStack Operators (Ops Docs SIG and Meetup group) Oslo Public Cloud SIG Quality Assurance Release Management Scientific SIG Self-healing SIG Storlets StoryBoard Swift Tacker StarlingX If your team is missing from the list, please let me know ASAP as we are starting to put together a draft schedule. -Kendall Nelson(diablo_rojo)

2 3

[ansible] 2.9 feature freeze is on 2019-08-29
by Sorin Sbarnea 25 Aug '19

25 Aug '19

I just wanted to note for those using Ansible that the feature freeze is in 2019-08-29 which means that if you have any changes you want to make, that's the last date when you will be able to merge them. After this date there will be only be bugfixes and the Ansible team policy is very strict about what counts as a feature. For example not passing some arguments counts as new feature, not a bug fix. https://docs.ansible.com/ansible/latest/roadmap/ROADMAP_2_9.html I wanted to highlight this because recently I wanted to add support for etc_hosts on docker_image (build) (it was only on docker_container / run) and the change got merged into 2.8 but backporting the fix was denied as it counted as new feature. If you are aware about other similar changes that do affect openstack, lets try to make them happen now, or we will be delayed 4 months for sure. Thanks Sorin Sbarnea

1 0

[goals][IPv6-Only Deployments and Testing] Week R-8 Update
by Ghanshyam Mann 25 Aug '19

25 Aug '19

Hello Everyone, Below is the progress on Ipv6 goal during R8 week. I have finished with the project having zuulv3 jobs. The projects having zuulv2 jobs will be my next take (I have not explored the difficulties/complexity yet). Summary: * Number of Ipv6 jobs proposed Projects: 28 * Number of pass projects: 17 ** Number of project merged out of pass project: 11 * Number of failing projects: 11 Storyboard: ========= - https://storyboard.openstack.org/#!/story/2005477 Current status: ============ 1. Cinder fix is merged[1], Thanks Gorka. We need to merge the devstack patch now. 2. Configuring the tempest test regex to run only smoke tests which can be extended to include future IPv6 tests also. Running all test is not actually required as such in IPv6 job but if any project wants to run all then also fine. Example: [1] 3. Murano, zun, solumn, cloudkitty are merged. 4. Murano default dns is also on IPv6 env. 5. For Monasca, kafka was not working for IPv6 but witek is upgrading the Kafka version in Monasca. I will rebase IPv6 job patch on top of that and check the result. 6. This week new projects ipv6 jobs patch and status: - Zun: link: https://review.opendev.org/#/c/677496/ status: job is passed with few devstack plugin fixes and patch is merged. - Searchlight: links: https://review.opendev.org/#/c/678391/ status: There are no integration tests in searchlight as of now so after talking to Trinh (PTL), I am just adding a no-test job to verify that searchlight can be deployed on IPv6 or not. Later when we will have tests then those can be added in this job. IPv6 missing support found: ===================== 1. https://review.opendev.org/#/c/673397/ 2. https://review.opendev.org/#/c/673449/ 3. https://review.opendev.org/#/c/677524/ How you can help: ============== - Each project needs to look for and review the ipv6 job patch. - Verify it works fine on ipv6 and no ipv4 used in conf etc - Any other specific scenario needs to be added as part of project IPv6 verification. - Help on debugging and fix the bug in IPv6 job is failing. Everything related to this goal can be found under this topic: Topic: https://review.opendev.org/#/q/topic:ipv6-only-deployment-and-testing+(stat… How to define and run new IPv6 Job on project side: ======================================= - I prepared a wiki page to describe this section - https://wiki.openstack.org/wiki/Goal-IPv6-only-deployments-and-testing Review suggestion: ============== - Main goal of these jobs will be whether your service is able to listen on IPv6 and can communicate to any other services either OpenStack or DB or rabbitmq etc on IPv6 or not. So check your proposed job with that point of view. If anything missing, comment on patch. - One example was - I missed to configure novnc address to IPv6- https://review.opendev.org/#/c/672493/ - base script as part of 'devstack-tempest-ipv6' will do basic checks for endpoints on IPv6 and some devstack var setting. But if your project needs more specific verification then it can be added in project side job as post-run playbooks as described in wiki page[3]. [1] https://review.opendev.org/#/c/677524/ [1] https://zuul.opendev.org/t/openstack/build/5b7b823d6faa4f5393b4c46d36e15d80… [2] https://review.opendev.org/#/c/676857/ [3] https://review.opendev.org/#/c/676900/ [4] https://wiki.openstack.org/wiki/Goal-IPv6-only-deployments-and-testing -gmann

1 0

[nova] critical bug around reload/upgrades
by Mohammed Naser 24 Aug '19

24 Aug '19

Hello: I've discussed this for quite sometime with Dan over IRC and a bit with Zane as well, but basically, Nova thinks that when it gets a reload (aka SIGHUP), nothing else has occurred. However, oslo.service actually calls stop(), reload() then start() again, which potentially kills all RPC. This has caused a pretty big issue in our gates and it also means that the whole idea behind 'reload nova-compute while upgrading to refresh info' concept is fundamentally broken. I tried to do some work on this here, however, I wasn't really able to get to the bottom of it. There seems to be a decision that needs to be taken in terms of .. do we change what reload() actually means in oslo_service (it actually is more like a restart, not a reload) or does Nova (and other projects) change their implementation in assuming what reload() does? https://review.openstack.org/#/c/641907/ This seems to have been floating around for a really long time, so I'd be happy to work with someone to find the fix (and we can totally test it inside OpenStack Ansible by reloading instead of restarting). Thanks! Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

4 4

[keystone] Keystone Team Update - Week of 19 August 2019
by Colleen Murphy 24 Aug '19

24 Aug '19

# Keystone Team Update - Week of 19 August 2019 ## News ### Development focus Feature freeze as well as a number of other deadlines are fast approaching. The development focus for the next three weeks should be: * reviews for changes implementing specs: - app cred access rules[1] - resource options for all resources[2] - immutable resources[3] - renewable group membership[4] * finish implementing and reviewing remaining system-scope[5]/default roles[6] migrations (deadline is feature freeze, Sept 9-13) * reviews for keystonemiddleware and keystoneauth[7] (final release Sept 2-6) * reviews for python-keystoneclient[8] (final release Sept 9-13) * helping the requirements team with any requirements issues[9] before requirements freeze (Sept 9-13) * completing community goals (follow the PDF generation news[10]) Additionally, we're still facing issues with instability of our unit test jobs. Improving the efficiency of our unit tests in order to avoid frequent timeouts would go a long way to helping avoid the feature freeze gate crunch. [1] https://review.opendev.org/#/q/is:open+topic:bp/whitelist-extension-for-app… [2] https://review.opendev.org/678322 [3] https://review.opendev.org/#/q/is:open+topic:immutable-resources [4] https://review.opendev.org/677469 [5] https://bugs.launchpad.net/keystone/+bugs?field.tag=system-scope [6] https://bugs.launchpad.net/keystone/+bugs?field.tag=default-roles [7] https://review.opendev.org/#/q/is:open+(project:openstack/keystoneauth+OR+p… [8] https://review.opendev.org/#/q/is:open+project:openstack/python-keystonecli… [9] https://bugs.launchpad.net/keystone/+bug/1839393 [10] http://lists.openstack.org/pipermail/openstack-discuss/2019-August/008506.h… ### keystoneauth session retries The heat team reported an issue in keystoneauth[11] where the way in which heat currently uses keystoneauth sessions is unable to take advantage of the request retry logic that is currently exposed only in the adapter. The proposal to fix the issue[12] exposes one of the retry options (connect_retries) in the session object. We've been in discussions on the bug report, on the patch, and in IRC[13][14] about whether this is the best approach and whether it would be better to change the way heat uses keystoneauth (would require a massive rewrite) or to expose the request retry options on the auth plugin in order to localize it to keystone requests (but that's an awkward home for it too). We've also been in disagreement about whether this change constitutes a feature or a bugfix with regards to backportability. [11] https://bugs.launchpad.net/keystoneauth/+bug/1840235 [12] https://review.opendev.org/676648 [13] http://eavesdrop.openstack.org/irclogs/%23openstack-sdks/%23openstack-sdks.… [14] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-k… ## Action Items * Vishakha to look into oauthlib requirements issue[15] * Kristi to propose spec to backlog about merging federation and identity backends [16] https://bugs.launchpad.net/keystone/+bug/1839393 ## Office Hours When there are topics to cover, the keystone team holds office hours on Tuesdays at 17:00 UTC. There will be no office hours this week or next week. Add topics you would like to see covered during office hours to the etherpad: https://etherpad.openstack.org/p/keystone-office-hours-topics ## Open Specs Train specs: https://bit.ly/2uZ2tRl Ongoing specs: https://bit.ly/2OyDLTh ## Recently Merged Changes Search query: https://bit.ly/2pquOwT We merged 13 changes this week, including changes to implement system scope for the endpoint groups API. ## Changes that need Attention Search query: https://bit.ly/2tymTje There are 68 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. ### Priority Reviews * Train Roadmap Stories - System scope/default roles (https://trello.com/c/ERo50T7r , https://trello.com/c/RlYyb4DU) + https://review.opendev.org/#/q/status:open+topic:implement-default-roles+la… + https://review.opendev.org/#/q/status:open+topic:trust-policies + https://review.opendev.org/#/q/topic:bug/1805409 - Federated attributes for users (https://trello.com/c/dEmSumDQ) + https://review.opendev.org/#/q/status:open+topic:bp/support-federated-attr - Application credential access rules (https://trello.com/c/dJsWMI4W) + https://review.opendev.org/#/q/status:open+topic:bp/whitelist-extension-for… - Immutable resources (https://trello.com/c/clIb4qMq) + https://review.opendev.org/#/q/topic:immutable-resources - Resource options for all (https://trello.com/c/8ML6kvig) + https://review.opendev.org/678322 * Needs Discussion - Allow initializing session with connection retries https://review.opendev.org/676648 * Oldest - OpenID Connect improved support (spec) https://review.opendev.org/373983 * Closes bugs - Cleanup session on delete https://review.opendev.org/674139 ## Bugs This week we opened 1 new bugs and closed 2. Bugs opened (1) Bug #1840647 (keystone:Undecided) opened by Nikita Kalyanov https://bugs.launchpad.net/keystone/+bug/1840647 ) Bugs fixed (2) Bug #1840291 (keystone:Medium) fixed by Rabi Mishra https://bugs.launchpad.net/keystone/+bug/1840291 Bug #1818734 (keystone:Low) fixed by Colleen Murphy https://bugs.launchpad.net/keystone/+bug/1818734 ## Milestone Outlook https://releases.openstack.org/train/schedule.html Final release for non-client libraries (keystoneauth, keystonemiddleware) is in two weeks. Feature freeze and final client release is in three weeks. ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter

1 0

[goal][python3] Train unit tests weekly update (goal-3)
by Corey Bryant 23 Aug '19

23 Aug '19

This is the goal-3 weekly update for the "Update Python 3 test runtimes for Train" goal [1]. There are 3 weeks remaining for completion of Train community goals [2]. == How can you help? == If your project has failing tests please take a look and help fix. Python 3.7 unit tests will be self-testing in Zuul. Failing patches: https://review.openstack.org/#/q/topic:python3-train +status:open+(+label:Verified-1+OR+label:Verified-2+) If your project has patches with successful tests please help get them merged. Open patches needing reviews: https://review.openstack.org/#/q/topic:python3 -train+is:open Patch automation scripts needing review: https://review.opendev.org/#/c/666934 == Ongoing Work == Thank you to all who have contributed their time and fixes to enable patches to land. We're down to 15 projects with failing tests. == Completed Work == All patches have been submitted to all applicable projects for this goal. Merged patches: https://review.openstack.org/#/q/topic:python3-train +is:merged == What's the Goal? == To ensure (in the Train cycle) that all official OpenStack repositories with Python 3 unit tests are exclusively using the 'openstack-python3-train-jobs' Zuul template or one of its variants (e.g. 'openstack-python3-train-jobs-neutron') to run unit tests, and that tests are passing. This will ensure that all official projects are running py36 and py37 unit tests in Train. For complete details please see [1]. == Reference Material == [1] Goal description: https://governance.openstack.org/tc/goals/train/ python3-updates.html [2] Train release schedule: https://releases.openstack.org/train /schedule.html (see R-5 for "Train Community Goals Completed") Storyboard: https://storyboard.openstack.org/#!/story/2005924 Porting to Python 3.7: https://docs.python.org/3/whatsnew/3.7.html#porting-to-python-3-7 Python Update Process: https://opendev.org/openstack/governance/src/branch/master/resolutions/2018… Train runtimes: https://opendev.org/openstack/governance/src/branch/master/reference/runtim… train.rst Thanks,

1 0

[nova] The pros/cons for libvirt persistent assignment and DB persistent assignment.
by Alex Xu 23 Aug '19

23 Aug '19

We get a lot of discussion on how to do the claim for the vpmem. There are a few points we are trying to match: * Avoid race problem. (the current VGPU assignment has been found having race issue https://launchpad.net/bugs/1836204) * Avoid the device assignment management to be virt driver and platform-specific. * Keep it simple. Currently, we go through two solutions here. This email is going to summary the pros/cons of these two solutions. #1 Without Nova DB persistent for the assignment info, depends on hypervisor persistent it. The idea is adding VirtDriver.claim/unclaim_for_instance(instance_uuid, flavor_id) interface. The assignment info is populated from hypervisor when nova-compute startup. And keep in the memory of VirtDriver. The instance_uuid is used to distinguish the claim from the different instance. The flavor_id is used for the same host resize, to distinguish the claim for source and target. This virt driver method is being invoked inside ResourceTracker to avoid the race problem. There is no any nova DB persistent for the assignment info. https://review.opendev.org/#/q/status:open+project:openstack/nova+branch:ma… pros: * Hidden all the device detail and virt driver detail inside the virt driver. * Less upgrade issue in the future since it doesn't involve any nova DB model change * Expecting as simple implementation since everything inside virt driver. cons: * Two cases are being found, the domain XML being lost for Libvirt virt driver. And we don't know other hypervisor behavior yet. * For the same host resize, the source and target instance are sharing single one domain XML. After the libvirt virt driver updated the domain XML to the target instance, the source instance's assignment information will be lost when a nova-compute restart happened. That means the resized instance can't be revert, the only choice for the user is to confirm the resize. * For live migration, the target host's domain XML will be cleanup by libvirt after a host restart. The assignment information is lost before nova-compute startup and doing a cleanup. * Can not support the same host cold migration. Since we need a way to identify the source and target instance's assignment in memory. But the same host cold migration means the same instance UUID and same flavor ID, there isn't another else can be used to distinguish the assignment. * There are workarounds added for above points, the code becomes fragile. #2 With nova DB persistent, but using virt driver specific blob to store virt driver specific info. The idea is persistent the assignment for instance into DB. The resource tracker gets available resources from virt driver. The resource tracker will calculate on the fly based on available resources and assigned resources from instance DB. The new field ·instance.resources· is designed for supporting virt driver specific metadata, then hidden the virt driver and platform detail from RT. https://etherpad.openstack.org/p/vpmems-non-virt-driver-specific-new pros: * Persistent assignment into instance object. Avoid the corner case we lost the assignment. * The ResourceTracker is responsible for doing the claim job. This is more reliable and no race problem, since ResourceTracker works very well for a long time. * The virt driver specific json-blob hidden the virt driver/platform detail from the ResourceTracker. * The free resource is calculated on the fly, keeping the implementation simple. Actually, the RT just provides a point to do the claim, needn't involve the complex of RT.update_available_resources cons: * Doesn't like PCIManager which has both instance side and host side persistent info. On the fly calculation should take care of the orphaned instance(the instance is deleted from DB, but still existing on the host), so actually, it isn't unresolvable issue. And it isn't too hard to upgrade to have host side persistent info in the future if we want. * Data model change for the original proposal. Need review to decide the data model enough generic Currently, Sean, Eric and I prefer the #2 now since the #1 has flaws for the same host resize and live migration can't be skipped by design. Looking for more feedback, and will appreciate it! Thanks Alex

4 5

[openstack-helm] k8s endpoints disappear sometimes
by 김하건 23 Aug '19

23 Aug '19

1 0

[openstack-dev][magnum] Nominating brtknr for Magnum core
by Feilong Wang 23 Aug '19

23 Aug '19

Hi team, I would like to propose adding Bharat Kunwar(brtknr) for the Magnum core team. He has been an awesome contributor since joining the Magnum team. And now he is currently the most active non-core reviewer on Magnum projects for the last 180 days[1]. Bharat has great technical expertise and contributed many high quality patches/reviews. I'm sure he would be an excellent addition to the team. If no one objects, I'll proceed and add him in a week from now. Thanks. [1] https://www.stackalytics.com/report/contribution/magnum-group/180 -- Cheers & Best regards, Feilong Wang (王飞龙) -------------------------------------------------------------------------- Head of R&D Catalyst Cloud - Cloud Native New Zealand Tel: +64-48032246 Email: flwang(a)catalyst.net.nz Level 6, Catalyst House, 150 Willis Street, Wellington --------------------------------------------------------------------------

2 1

[all][elections] Combined PTL/TC Election Season
by Jeremy Stanley 23 Aug '19

23 Aug '19

Election details: https://governance.openstack.org/election/ The nomination period officially begins Aug 27, 2019 23:45 UTC. Please read the stipulations and timelines for candidates and electorate contained in this governance documentation. Due to circumstances of timing, PTL and TC elections for the coming cycle will run concurrently; deadlines for their nomination and voting activities are synchronized but will still use separate ballots. Please note, if only one candidate is nominated as PTL for a project team during the PTL nomination period, that candidate will win by acclaim, and there will be no poll. There will only be a poll if there is more than one candidate stepping forward for a project team's PTL position. There will be further announcements posted to the mailing list as action is required from the electorate or candidates. This email is for information purposes only. If you have any questions which you feel affect others please reply to this email thread. If you have any questions that you which to discuss in private please email any of the election officials[1] so that we may address your concerns. Thank you, [1] https://governance.openstack.org/election/#election-officials -- Jeremy Stanley, on behalf of the technical election officials

1 0

Nova causes MySQL timeouts
by Albert Braden 23 Aug '19

23 Aug '19

It looks like nova is keeping mysql connections open until they time out. Is there a way to stop these error messages? Aborted connection 10726 to db: 'nova' user: 'nova' host: 'asdf' (Got timeout reading communication packets)

1 0

[nova][ops] What should the compute service delete behavior be wrt resource providers with allocations?
by Matt Riedemann 23 Aug '19

23 Aug '19

Before [1] when deleting a compute service in the API we did not check to see if the compute service was hosting any instances and just blindly deleted the service and related compute_node(s) records which orphaned the resource provider(s) for those nodes. With [2] we built on that and would cleanup the (first [3]) compute node resource provider by first deleting any allocations for instances still on that host - which because of the check in [1] should be none - and then deleted the resource provider itself. [2] forgot about ironic where a single compute service can be managing multiple (hundreds or even thousands) of baremetal compute nodes so I wrote [3] to delete *all* resource providers for compute nodes tied to the service - again barring there being any instances running on the service because of the check added in [1]. What we've failed to realize until recently is that there are cases where deleting the resource provider can still fail because there are allocations we haven't cleaned up, namely: 1. Residual allocations for evacuated instances from a source host. 2. Allocations held by a migration record for an unconfirmed (or not yet complete) migration. Because the delete_resource_provider method isn't checking for those, we can get ResourceProviderInUse errors which are then ignored [4]. Since that error is ignored, we continue on to delete the compute service record [5], effectively orphaning the providers (which is what [2] was meant to fix). I have recreated the evacuate scenario in a functional test here [6]. The question is what should we do about the fix? I'm getting lost thinking about this in a vacuum so trying to get some others to help think about it. Clearly with [1] we said you shouldn't be able to delete a compute service that has instances on it because that corrupts our resource tracking system. If we extend that to any allocations held against providers for that compute service, then the fix might be as simple as not ignoring the ResourceProviderInUse error and fail if we can't delete the provider(s). The question I'm struggling with is what does an operator do for the two cases mentioned above, not-yet-complete migrations and evacuated instances? For migrations, that seems pretty simple - wait for the migration to complete and confirm it (reverting a cold migration or resize would put the instance back on the compute service host you're trying to delete). The nastier thing is the allocations tied to an evacuated instance since those don't get cleaned up until the compute service is restarted [7]. If the operator never intends on restarting that compute service and just wants to clear the data, then they have to manually delete the allocations for the resource providers associated with that host before they can delete the compute service, which kind of sucks. What are our options? 1. Don't delete the compute service if we can't cleanup all resource providers - make sure to not orphan any providers. Manual cleanup may be necessary by the operator. 2. Change delete_resource_provider cascade=True logic to remove all allocations for the provider before deleting it, i.e. for not-yet-complete migrations and evacuated instances. For the evacuated instance allocations this is likely OK since restarting the source compute service is going to do that cleanup anyway. Also, if you delete the source compute service during a migration, confirming or reverting the resize later will likely fail since we'd be casting to something that is gone (and we'd orphan those allocations). Maybe we need a functional recreate test for the unconfirmed migration scenario before deciding on this? 3. Other things I'm not thinking of? Should we add a force parameter to the API to allow the operator to forcefully delete (#2 above) if #1 fails? Force parameters are hacky and usually seem to cause more problems than they solve, but it does put the control in the operators hands. If we did remove allocations for an instance when deleting it's compute service host, the operator should be able to get them back by running the "nova-manage placement heal_allocations" CLI - assuming they restart the compute service on that host. This would have to be tested of course. Help me Obi-Wan Kenobi. You're my only hope. [1] https://review.opendev.org/#/q/I0bd63b655ad3d3d39af8d15c781ce0a45efc8e3a [2] https://review.opendev.org/#/q/I7b8622b178d5043ed1556d7bdceaf60f47e5ac80 [3] https://review.opendev.org/#/c/657016/ [4] https://github.com/openstack/nova/blob/cb0cfc90e1e03e82c42187ec60f46fb8fd59… [5] https://github.com/openstack/nova/blob/cb0cfc90e1e03e82c42187ec60f46fb8fd59… [6] https://review.opendev.org/#/c/663737/ [7] https://github.com/openstack/nova/blob/cb0cfc90e1e03e82c42187ec60f46fb8fd59… -- Thanks, Matt

6 16

[research][code-review][software-dev] Design Discussions During OpenStack Code Reviews
by farida el-zanaty 23 Aug '19

23 Aug '19

Hi! I am Farida El-Zanaty from McGill University. Under the supervision of Prof. Shane McIntosh, my research aims to study design discussions that occur between developers during code reviews. Last year, we published a study about the frequency and types of such discussions that occur in OpenStack Nova and Neutron (http://rebels.ece.mcgill.ca/papers/esem2018_elzanaty.pdf) We are reaching out to OpenStack developers to better understand their perspectives on design discussions during code reviews. Those who are interested can start by participating in our 10-minute survey about their experiences as both the code reviewer and author. Survey participants will be entered into a raffle for a $50 Amazon gift card. Survey: https://forms.gle/Hhn191f6cxF5hVgG8 Thanks for your time, Farida El-Zanaty

1 0

[openstack-dev] [neutron] Cancelling Neutron Drivers meeting on August 23rd
by Miguel Lavalle 23 Aug '19

23 Aug '19

Dear Neutrinos, 3 out of 5 members of the drivers team are off on vacation this week, so we won't have quorum for the meeting. As a consequence, I am cancelling it this week. We will resume next week. Best regards Miguel

1 0

[tc] Naming releases after people
by Jeremy Freudberg 22 Aug '19

22 Aug '19

Hi, There is currently ongoing discussion about a new process for selecting release names. I would like to draw attention to one proposal in particular: "Name releases after ATCs" [0]. This is currently the only proposal which explicitly prefers names 'telling the story of OpenStack' like the current process based on the location of the summit does. For this reason I personally favor this proposal above all others currently proposed. There are some areas of the proposal to smooth out (and I mention these areas on the review), but I before I proceed, I would like to gather feedback from the community about the mere idea of naming releases after people. If such an idea strikes you one way or the other, please leave a comment on the review; I'd appreciate it greatly. Thanks, Jeremy [0] https://review.opendev.org/#/c/677827/

1 0

[TC] [UC] Shanghai Forum Selection Committee: Help Needed
by Jimmy McArthur 22 Aug '19

22 Aug '19

Hi everyone! The Forum in Shanghai is coming up. We require 2 volunteers from the TC and 2 from the UC for the Forum Selection Committee. For more information, please see:https://wiki.openstack.org/wiki/Forum Please reach out to myself orknelson(a)openstack.org if you're interested. Volunteers should respond on or before September 2, 2019. Note: volunteers are required to be currently serving on either the UC or the TC. Cheers, Jimmy

4 3

[nova] API updates week 19-34
by Ghanshyam Mann 22 Aug '19

22 Aug '19

Hello Everyone, Please find the Nova API updates of this week. API Related BP : ============ COMPLETED: 1. Support adding description while locking an instance: - https://blueprints.launchpad.net/nova/+spec/add-locked-reason 2. Add host and hypervisor_hostname flag to create server - https://blueprints.launchpad.net/nova/+spec/add-host-and-hypervisor-hostnam… 3. Nova API cleanup - https://blueprints.launchpad.net/nova/+spec/api-consistency-cleanup 4. Add 'power-update' external event: - https://blueprints.launchpad.net/nova/+spec/nova-support-instance-power-upd… Code Ready for Review: ------------------------------ 1. Specifying az when restore shelved server - Topic: https://review.opendev.org/#/q/topic:bp/support-specifying-az-when-restore-… - Weekly Progress: Under Review and in runway also. 2. Show Server numa-topology - Topic: https://review.opendev.org/#/q/topic:bp/show-server-numa-topology+(status:o… - Weekly Progress: Alex is +2 on nova change, but this might conflict with above one on Microvision number(depends on which one gets first). 3. Nova API policy improvement - Topic: https://review.openstack.org/#/q/topic:bp/policy-default-refresh+(status:op… - Weekly Progress: First set of os-service policy changs has Kenichi +2. Need more feedback and +A to start modifying the other policies. review guide over ML - http://lists.openstack.org/pipermail/openstack-discuss/2019-August/008504.h… 4. Add User-id field in migrations table - Topic: https://review.opendev.org/#/q/topic:bp/add-user-id-field-to-the-migrations… - Weekly Progress: Changes are up for review but with microversion 2.77. We can rebase the microverison number later and not blocking for review. 5. Support delete_on_termination in volume attach api -Spec: https://review.opendev.org/#/q/topic:bp/support-delete-on-termination-in-se… - Weekly Progress: Ready for review and rebase on available microversion number can be done later. Specs are merged and code in-progress: ------------------------------ ------------------ 1. Detach and attach boot volumes: - Topic: https://review.openstack.org/#/q/topic:bp/detach-boot-volume+(status:open+O… - Weekly Progress: No Progress. Patches are in merge conflict. Spec Ready for Review: ----------------------------- 1. Support for changing deleted_on_termination after boot -Spec: https://review.openstack.org/#/c/580336/ - Weekly Progress: This has been added in backlog. Previously approved Spec needs to be re-proposed for Train: --------------------------------------------------------------------------- 1. Servers Ips non-unique network names : - https://blueprints.launchpad.net/nova/+spec/servers-ips-non-unique-network-… - https://review.openstack.org/#/q/topic:bp/servers-ips-non-unique-network-na… - I remember I planned this to re-propose but could not get time. If anyone would like to help on this please repropose. otherwise I will start this in U cycle. 2. Volume multiattach enhancements: - https://blueprints.launchpad.net/nova/+spec/volume-multiattach-enhancements - https://review.openstack.org/#/q/topic:bp/volume-multiattach-enhancements+(… - This also need volutneer - http://lists.openstack.org/pipermail/openstack-discuss/2019-June/007411.html Others: 1. Add API ref guideline for body text - 2 api-ref are left to fix. Bugs: ==== No progress report in this week. NOTE- There might be some bug which is not tagged as 'api' or 'api-ref', those are not in the above list. Tag such bugs so that we can keep our eyes. -gmann

1 0

[storyboard] email notification on stories/tasks of subscribed projects
by Akihiro Motoki 22 Aug '19

22 Aug '19

Hi, Is there a way to get email notification on stories/tasks of subscribed projects in storyboard? In launchpad, I configure launchpad bug notifications of all bug changes in interested projects. After migration to storyboard (for example, openstackclient), I failed to find a similar way. Thanks, Akihiro Motoki (irc: amotoki)

5 8

[qa] QA Office Hour New Time: 0 UTC
by Ghanshyam Mann 22 Aug '19

22 Aug '19

Hello Everyone, Please note the QA office hour new time which is 0 UTC(which will include the Asia TZ members also) on every Thursday. I have updated the wiki page [1] also for that. I have cleaned up the PING LIST which was old, feel free to add yourself in the PING list on wiki if you want the IRC notification. [1] https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Agenda_for_next_Offi… -gmann

1 0

More upgrade issues with PCPUs - input wanted
by Stephen Finucane 22 Aug '19

22 Aug '19

tl;dr: Is breaking booting of pinned instances on Stein compute nodes in a Train deployment an acceptable thing to do, and if not, how do we best handle the VCPU->PCPU migration in Train? I've been working through the cpu-resources spec [1] and have run into a tricky issue I'd like some input on. In short, this spec means that pinned instances (i.e. 'hw:cpu_policy=dedicated') will now start consuming a new resources type, PCPU, instead of VCPU. Many things need to change to make this happen but the key changes are: 1. The scheduler needs to start modifying requests for pinned instances to request PCPU resources instead of VCPU resources 2. The libvirt driver needs to start reporting PCPU resources 3. The libvirt driver needs to do a reshape, moving all existing allocations of VCPUs to PCPUs, if the instance holding that allocation is pinned The first two of these steps presents an issue for which we have a solution, but the solutions we've chosen are now resulting in this new issue. * For (1), the translation of VCPU to PCPU in the scheduler means compute nodes must now report PCPU in order for a pinned instance to land on that host. Since controllers are upgraded before compute nodes and all compute nodes aren't necessarily upgraded in one go (particularly for edge or other large or multi-cell deployments), this can mean there will be a period of time where there are very few or no hosts available on which to schedule pinned instances. * For (2), we're hampered by the fact that there is no clear way to determine if a host is used for pinned instances or not. Because of this, we can't determine if a host should be reporting PCPU or VCPU inventory. The solution we have for the issues with (1) is to add a workaround option that would disable this translation, allowing operators time to upgrade all their compute nodes to report PCPU resources before anything starts using them. For (2), we've decided to temporarily (i.e. for one release or until configuration is updated) report both, in the expectation that everyone using pinned instances has followed the long- standing advice to separate hosts intended for pinned instances from those intended for unpinned instances using host aggregates (e.g. even if we started reporting PCPUs on a host, nothing would consume that due to 'pinned=False' aggregate metadata or similar). These actually benefit each other, since if instances are still consuming VCPUs then the hosts need to continue reporting VCPUs. However, both interfere with our ability to do the reshape. Normally, a reshape is a one time thing. The way we'd planned to determine if a reshape was necessary was to check if PCPU inventory was registered against the host and, if not, whether there were any pinned instances on the host. If PCPU inventory was not available and there were pinned instances, we would update the allocations for these instances so that they would be consuming PCPUs instead of VCPUs and then update the inventory. This is problematic though, because our solution for the issue with (1) means pinned instances can continue to request VCPU resources, which in turn means we could end up with some pinned instances on a host consuming PCPU and other consuming VCPU. That obviously can't happen, so we need to change tacks slightly. The two obvious solutions would be to either (a) remove the workaround option so the scheduler would immediately start requesting PCPUs and just advise operators to upgrade their hosts for pinned instances asap or (b) add a different option, defaulting to True, that would apply to both the scheduler and compute nodes and prevent not only translation of flavors in the scheduler but also the reporting PCPUs and reshaping of allocations until disabled. I'm currently leaning towards (a) because it's a *lot* simpler, far more robust (IMO) and lets us finish this effort in a single cycle, but I imagine this could make upgrades very painful for operators if they can't fast track their compute node upgrades. (b) is more complex and would have some constraints, chief among them being that the option would have to be disabled at some point post-release and would have to be disabled on the scheduler first (to prevent the mismash or VCPU and PCPU resource allocations) above. It also means this becomes a three cycle effort at minimum, since this new option will default to True in Train, before defaulting to False and being deprecated in U and finally being removed in V. As such, I'd like some input, particularly from operators using pinned instances in larger deployments. What are your thoughts, and are there any potential solutions that I'm missing here? Cheers, Stephen [1] https://specs.openstack.org/openstack/nova-specs/specs/train/approved/cpu-r…

4 5

[election] Coordination + Prep
by Kendall Nelson 22 Aug '19

22 Aug '19

Hello Election Officials! (and anyone else curious about running elections :) ) Next week we are set to get this party started. Things that need to happen before then: 1. Election season email to the ML-- we have a template for this, but it and all the other emails this run will need to be tweaked (or we add new ones for this combined election type <-- I'm in favor of this approach in case we do this again in the future). 2. Patch to set up U nominations directories-- We don't have the next release name settled so I guess we just go for 'U' and we can update it later. 3. Patch to update officials list on site-- I will need to be removed because I won't be able to help with the actual election this round, but I am here to advise if you need anything. ...I could be missing things, but that's for sure what I know we need to accomplish before the start date and the actual nominations kickoff email. For reference, here is the general process that we run though[1]. That being said, things are a bit different this time since we are running the elections simultaneously. We should probably add a section for what happens when we have to run them in parallel (same vein as writing new email templates for the combined election). -Kendall (diablo_rojo) [1]https://opendev.org/openstack/election/src/branch/master/README.rst

2 1

[ALL][UC] Train EC Election - nomination results, and what is going on
by Ian Y. Choi 21 Aug '19

21 Aug '19

Hello all, As announced [1-2], the UC nomination period was from August 5 - August 16, 2019, and as the election officials, we would like to share the result, as well as the next steps. This was discussed by the User Committee yesterday [3]: - There was one UC candidacy [4]. The candicacy has been validated and election official announce that "Mohamed Elsakhawy" will serve on the UC. Congratulations! - There will be no election since there was only one candicate out of two positions for this election. - There were discussions during the UC meeting [3] yesterday, and the UC decided to have a second, special election for another seat within the timeframe spelled out in the charter. The same election officials will work, and the officials and UC members are discussing a feasible time frame for the election. As mentioned, the upcoming election is *special*, so please pay attention for more election information. The election officials will post an email soon with more details on upcoming special UC election. Thank you, - Ed & Ian [1] http://lists.openstack.org/pipermail/user-committee/2019-July/002862.html [2] http://lists.openstack.org/pipermail/user-committee/2019-August/002864.html [3] http://eavesdrop.openstack.org/meetings/uc/2019/uc.2019-08-19-15.04.log.htm… [4] http://lists.openstack.org/pipermail/user-committee/2019-August/002866.html

3 2

[sahara] Cancelling Sahara meeting August 22
by Jeremy Freudberg 21 Aug '19

21 Aug '19

Hi all, There will be no Sahara meeting 2019-08-22, the reason being that Luigi is not around and I myself will most likely not be around either. Holler if you need anything. Thanks, Jeremy

1 0

[cinder] Not Weekly Meeting Today ...
by Jay Bryant 21 Aug '19

21 Aug '19

Team, Just a reminder that we will not have our weekly meeting this week due to our mid-cycle meeting going on. If you are able to join the mid-cycle please check the #openstack-cinder channel for details. Thanks! Jay (irc: jungleboyj)

1 0

[cinder] [3rd party ci] Deadline Has Past for Python3 Migration
by Jay Bryant 21 Aug '19

21 Aug '19

All, This e-mail has multiple purposes. First, I have expanded the mail audience to go beyond just openstack-discuss to a mailing list I have created for all 3rd Party CI Maintainers associated with Cinder. I apologize to those of you who are getting this as a duplicate e-mail. For all 3rd Party CI maintainers who have already migrated your systems to using Python3.7...Thank you! We appreciate you keeping up-to-date with Cinder's requirements and maintaining your CI systems. If this is the first time you are hearing of the Python3.7 requirement please continue reading. It has been decided by the OpenStack TC that support for Py2.7 would be deprecated [1]. The Train development cycle is the last cycle that will support Py2.7 and therefore all vendor drivers need to demonstrate support for Py3.7. It was discussed at the Train PTG that we would require all 3rd Party CIs to be running using Python3 by the Train milestone 2: [2] We have been communicating the importance of getting 3rd Party CI running with py3 in meetings and e-mail for quite some time now, but it still appears that nearly half of all vendors are not yet running with Python 3. [3] If you are a vendor who has not yet moved to using Python 3 please take some time to review this document [4] as it has guidance on how to get your CI system updated. It also includes some additional details as to why this requirement has been set and the associated background. Also, please update the py3-ci-review etherpad with notes indicating that you are working on adding py3 support. I would also ask all vendors to review the etherpad I have created as it indicates a number of other drivers that have been marked unsupported due to CI systems not running properly. If you are not planning to continue to support a driver adding such a note in the etherpad would be appreciated. Thanks! Jay [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-August/008255.h… [2] https://wiki.openstack.org/wiki/CinderTrainSummitandPTGSummary#3rd_Party_CI [3] https://etherpad.openstack.org/p/cinder-py3-ci-review [4] https://wiki.openstack.org/wiki/Cinder/3rdParty-drivers-py3-update

3 4

[all][tc] U release naming poll result
by Rico Lin 21 Aug '19

21 Aug '19

Dear all OpenStackers, First, we got 298 voters to participate in the poll, so thank you for your vote. And here is the poll result: 1. Ussuri [乌苏里江 https://en.wikipedia.org/wiki/Ussuri_River] (Condorcet winner: wins contests with all other choices) 2. Uma [http://www.fallingrain.com/world/CH/20/Uma.html] 3. Ula [Miocene Baogeda Ula] 4. Urad [乌拉特中旗 https://en.wikipedia.org/wiki/Urad_Middle_Banner] 5. Ulansu [乌兰苏海组 Ulansu sea] 6. Ulanhot [乌兰浩特市 https://en.wikipedia.org/wiki/Ulanhot] 7. Ulanqab [乌兰察布市 https://en.wikipedia.org/wiki/Ulanqab] 8. Ujimqin [东/西乌珠穆沁旗 https://en.wikipedia.org/wiki/Ujimqin] Here is result in detail: https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_19e5119b14f86294&rkey=3…

2 1

[goals][IPv6-Only Deployments and Testing] Week R-9 Update
by Ghanshyam Mann 21 Aug '19

21 Aug '19

Hello Everyone, Below is the progress on Ipv6 goal during R9 week. At the first step, I am preparing the ipv6 jobs for the projects having zuulv3 jobs. The projects having zuulv2 jobs will be my second take. Summary: * Number of Ipv6 jobs proposed Projects: 25 * Number of pass projects: 11 ** Number of project merged: 6 * Number of failing projects: 14 Storyboard: ========= - https://storyboard.openstack.org/#!/story/2005477 Current status: ============ 1. Cinder is error when configuring the conder's my_ip as IPv6. iscsi is not able to _connect_single_volume [1]. 2. Configuring the tempest test regex to run only smoke tests which can be extended to include future IPv6 tests also. Running all test is not actually required as such in IPv6 job but if any project wants to run all then also fine. Example: [1] 3. Fixing the Murano's MURANO_DEFAULT_DNS to set as IPv6 for IPv6 env[2]. 4. Solum job need Zun to configure the host_ip properly for IPv6. I will make the dependent patch. 5. For Monasca, kafka was not working for IPv6 but witek is upgrading the Kafka version in Monasca. I will rebase IPv6 job patch on top of that and check the result. 6. This week new projects ipv6 jobs patch and status: - Tacker: link: https://review.opendev.org/#/c/671908/ status: job is failing, I need to properly configure the job. - Senlin: links: https://review.opendev.org/#/c/676910/ status: jobs are failing. In same patch I have fixed the devstack plugin to deploy the Selin service on IPv6 which was hardcoded to HOST_IP(ipv4). But it seems Senlin endpoint is not created in keystone. Need to debug more for the root cause. - Solum: links: https://review.opendev.org/#/c/676912/ Status: job is failing. Fixed the devstack plugin for 'host' for IPv6 env. It also need fix on Zun side to configure the host_ip properly for IPv6. - Trove: link: https://review.opendev.org/#/c/677015/ status: job is passing and it is good to merge. - Watcher: link: https://review.opendev.org/#/c/677017/ status: job is passing and it is good to merge. In same patch, I have fixed the devstack plugin for 'host' for IPv6 env. - Sahara link: https://review.opendev.org/#/c/676903/ status: Job is failing to start the sahara service. I could not find the logs for sahara service(it shows empty log under apache). Need help from sahara team. IPv6 missing support found: ===================== 1. https://review.opendev.org/#/c/673397/ 2. https://review.opendev.org/#/c/673449/ How you can help: ============== - Each project needs to look for and review the ipv6 job patch. - Verify it works fine on ipv6 and no ipv4 used in conf etc - Any other specific scenario needs to be added as part of project IPv6 verification. - Help on debugging and fix the bug in IPv6 job is failing. Everything related to this goal can be found under this topic: Topic: https://review.opendev.org/#/q/topic:ipv6-only-deployment-and-testing+(stat… How to define and run new IPv6 Job on project side: ======================================= - I prepared a wiki page to describe this section - https://wiki.openstack.org/wiki/Goal-IPv6-only-deployments-and-testing Review suggestion: ============== - Main goal of these jobs will be whether your service is able to listen on IPv6 and can communicate to any other services either OpenStack or DB or rabbitmq etc on IPv6 or not. So check your proposed job with that point of view. If anything missing, comment on patch. - One example was - I missed to configure novnc address to IPv6- https://review.opendev.org/#/c/672493/ - base script as part of 'devstack-tempest-ipv6' will do basic checks for endpoints on IPv6 and some devstack var setting. But if your project needs more specific varification then it can be added in project side job as post-run playbooks as described in wiki page[3]. [1] https://zuul.opendev.org/t/openstack/build/5b7b823d6faa4f5393b4c46d36e15d80… [2] https://review.opendev.org/#/c/676857/ [3] https://review.opendev.org/#/c/676900/ [4] https://wiki.openstack.org/wiki/Goal-IPv6-only-deployments-and-testing -gmann

2 3

[public-cloud-sig] Debian Cloud Sprint
by Jeremy Stanley 21 Aug '19

21 Aug '19

Just a heads-up, there was a suggestion[*] on the debian-cloud mailing list that it would be nice if some representatives from public OpenStack service providers are able to attend/participate in the upcoming Debian Cloud Sprint[**], October 14-16 on MIT campus in Cambridge, Massachusetts, USA. I too think it would be awesome for OpenStack to have a seat at the table alongside representatives of the usual closed-source clouds when it comes time to talk about (among other things) what Debian's official "cloud" image builds should be doing to better support our collective users. If you're interested in going, I recommend reaching out via the debian-cloud mailing list[***]. [*] https://lists.debian.org/debian-cloud/2019/08/msg00065.html [**] https://wiki.debian.org/Sprints/2019/DebianCloud2019 [***] https://lists.debian.org/debian-cloud/ -- Jeremy Stanley

3 2

RE: [masakari] pacemaker-remote Setup Overview
by Devharakar, Shilpa 21 Aug '19

21 Aug '19

Hi Ralf Teckelmann, Sorry for the attachment, instead please refer [1] Masakari team is in process of 'adding devstack support to install host-monitor', please refer community patch [2]. You can refer 'devstack/plugin.sh' [1]: http://paste.openstack.org/show/760301/ [2]: https://review.opendev.org/#/c/671200/ > Hi Ralf Teckelmann, > > Sorry resending by correcting subject with appropriate subject. Thanks with Regards, Shilpa Shivaji Devharakar| Software Development Supervisor | NTT DATA Services| w. 91-020- 67095703 | Shilpa.Devharakar(a)nttdata.com | Learn more at nttdata.com/americas -----Original Message----- From: openstack-discuss-request(a)lists.openstack.org <openstack-discuss-request(a)lists.openstack.org> Sent: Monday, August 19, 2019 10:19 PM To: openstack-discuss(a)lists.openstack.org Subject: openstack-discuss Digest, Vol 10, Issue 94 Send openstack-discuss mailing list submissions to openstack-discuss(a)lists.openstack.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss or, via email, send a message with subject or body 'help' to openstack-discuss-request(a)lists.openstack.org You can reach the person managing the list at openstack-discuss-owner(a)lists.openstack.org When replying, please edit your Subject line so it is more specific than "Re: Contents of openstack-discuss digest..." Today's Topics: 1. [tc] weekly update (Mohammed Naser) 2. RE: [masakari] pacemaker-remote Setup Overview (Devharakar, Shilpa) 3. Re: [tc] weekly update (Andreas Jaeger) 4. Re: [all] [tc] [docs] [release] [ptls] Docs as SIG: Ownership of docs.openstack.org (Doug Hellmann) ---------------------------------------------------------------------- Message: 1 Date: Mon, 19 Aug 2019 12:26:48 -0400 From: Mohammed Naser <mnaser(a)vexxhost.com> To: OpenStack Discuss <openstack-discuss(a)lists.openstack.org> Subject: [tc] weekly update Message-ID: <CAEs876hqf-R4r9+LZcVbPPLJMEHTs=tPBztJtGqO8-oZvEXLcg(a)mail.gmail.com> Content-Type: text/plain; charset="UTF-8" Hi everyone, Here’s the update for what happened in the OpenStack TC this week. You can get more information by checking for changes in openstack/governance repository. # Retired projects - Networking-generic-switch-tempest (from networking-generic-switch): https://review.opendev.org/#/c/674430/ # General changes - Michał Dulko as Kuryr PTL: https://review.opendev.org/#/c/674624/ - Added a mission to Swift taken from its wiki: https://review.opendev.org/#/c/675307/ - Sean McGinnis as release PTL: https://review.opendev.org/#/c/675246/ Thanks for tuning in! Regards, Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com ------------------------------ Message: 2 Date: Mon, 19 Aug 2019 16:34:26 +0000 From: "Devharakar, Shilpa" <Shilpa.Devharakar(a)nttdata.com> To: "openstack-discuss(a)lists.openstack.org" <openstack-discuss(a)lists.openstack.org> Subject: RE: [masakari] pacemaker-remote Setup Overview Message-ID: <CH2PR12MB4072764F39DDD35C4A8ED158FFA80(a)CH2PR12MB4072.namprd12.prod.outlook.com> Content-Type: text/plain; charset="utf-8" Hi Ralf Teckelmann, Sorry resending by correcting subject with appropriate subject. > Hello, > > Utilizing openstack-ansible we successfully installed all the masakari services. Besides masakari-hostmonitor all are running fine. > For the hostmonitor a pacemaker cluster is missing. > > Can anyone give me an overview how the pacemaker cluster setup would look like? > Which (pacemaker) services is running where (compute nodes, something on any other node,...), etc? > > Best regards, > > Ralf Teckelmann Sorry for the late answer... Masakari team is in process of 'adding devstack support to install host-monitor', please refer community patch [1]. You can refer 'devstack/plugin.sh', please note it has IPMI Hardware support dependency. Also PFA 'detailed_steps_on_ubuntu_for_pacemaker_verification.txt' for verification of same carried out on Ubuntu distribution (installed openstack using devstack with Masakari enabled). [1]: https://review.opendev.org/#/c/671200/ Add devstack support to install host-monitor Thanks with Regards, Shilpa Shivaji Devharakar| Software Development Supervisor | NTT DATA Services| w. 91-020- 67095703 | Shilpa.Devharakar(a)nttdata.com | Learn more at nttdata.com/americas -----Original Message----- From: openstack-discuss-request(a)lists.openstack.org <openstack-discuss-request(a)lists.openstack.org> Sent: Monday, August 12, 2019 6:30 PM To: openstack-discuss(a)lists.openstack.org Subject: openstack-discuss Digest, Vol 10, Issue 59 Send openstack-discuss mailing list submissions to openstack-discuss(a)lists.openstack.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss or, via email, send a message with subject or body 'help' to openstack-discuss-request(a)lists.openstack.org You can reach the person managing the list at openstack-discuss-owner(a)lists.openstack.org When replying, please edit your Subject line so it is more specific than "Re: Contents of openstack-discuss digest..." Today's Topics: 1. Re: [tripleo][openstack-ansible] Integrating ansible-role-collect-logs in OSA (Arx Cruz) 2. [swauth][swift] Retiring swauth (Ondrej Novy) 3. [ironic] Resuming having weekly meetings (Julia Kreger) 4. [masakari] pacemaker-remote Setup Overview (Teckelmann, Ralf, NMU-OIP) ---------------------------------------------------------------------- Message: 1 Date: Mon, 12 Aug 2019 12:32:34 +0200 From: Arx Cruz <arxcruz(a)redhat.com> To: Jean-Philippe Evrard <jean-philippe(a)evrard.me> Cc: openstack-discuss(a)lists.openstack.org Subject: Re: [tripleo][openstack-ansible] Integrating ansible-role-collect-logs in OSA Message-ID: <CAB27Hy1tB0TjEwsvrgeBUF1NFCzDadE58-VR68Qt_=3RKY+fVw(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hello, I've started to split the logs collection tasks in small tasks [1] in order to allow other users to choose what exactly they want to collect. For example, if you don't need the openstack information, or if you don't care about networking, etc. Please take a look. I'll also add it on the OSA agenda for tomorrow's meeting. Kind regards, 1 - https://review.opendev.org/#/c/675858/ On Mon, Jul 22, 2019 at 8:44 AM Jean-Philippe Evrard < jean-philippe(a)evrard.me> wrote: > Sorry for the late answer... > > On Wed, 2019-07-10 at 12:12 -0600, Wesley Hayutin wrote: > > > > These are of course just passed in as extra-config. I think each > > project would want to define their own list of files and maintain it > > in their own project. WDYT? > > Looks good. We can either clean up the defaults, or OSA can just > override the defaults, and it would be good enough. I would say that > this can still be improved later, after OSA has started using the role > too. > > > It simple enough. But I am happy to see a different approach. > > Simple is good! > > > Any thoughts on additional work that I am not seeing? > > None :) > > > > > Thanks for responding! I know our team is very excited about the > > continued collaboration with other upstream projects, so thanks!! > > > > Likewise. Let's reduce tech debt/maintain more code together! > > Regards, > Jean-Philippe Evrard (evrardjp) > > > > > -- Arx Cruz Software Engineer Red Hat EMEA <https://www.redhat.com> arxcruz(a)redhat.com @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190812…> ------------------------------ Message: 2 Date: Mon, 12 Aug 2019 12:56:15 +0200 From: Ondrej Novy <novy(a)ondrej.org> To: openstack-discuss(a)lists.openstack.org Subject: [swauth][swift] Retiring swauth Message-ID: <CAOO6c=wgDZDRpQboo=_0qZ=fHrfu0rO0w=PaUat9bJduwFiVXw(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi, because swauth is not compatible with current Swift, doesn't support Python 3, I don't have time to maintain it and my employer is not interested in swauth, I'm going to retire swauth project. If nobody take over it, I will start removing swauth from opendev on 08/24. Thanks. -- Best regards Ondřej Nový -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190812…> ------------------------------ Message: 3 Date: Mon, 12 Aug 2019 07:55:07 -0400 From: Julia Kreger <juliaashleykreger(a)gmail.com> To: openstack-discuss <openstack-discuss(a)lists.openstack.org> Subject: [ironic] Resuming having weekly meetings Message-ID: <CAF7gwdhSWcUbYu0S2QfvjO44Q_5vJr6KTUQE3TRu3UYirqFGmQ(a)mail.gmail.com> Content-Type: text/plain; charset="UTF-8" All, I meant to send this specific email last week, but got distracted and $life. I believe we need to go back to having weekly meetings. The couple times I floated this in the past two weeks, there hasn't seemed to be any objections, but I also did not perceive any real thoughts on the subject. While the concept and use of office hours has seemingly helped bring some more activity to our IRC channel, we don't have a check-point/sync-up mechanism without an explicit meeting. With that being said, I'm going to start the meeting today and if we have quorum, try to proceed with it today. -Julia ------------------------------ Message: 4 Date: Mon, 12 Aug 2019 12:59:20 +0000 From: "Teckelmann, Ralf, NMU-OIP" <ralf.teckelmann(a)bertelsmann.de> To: "openstack-discuss(a)lists.openstack.org" <openstack-discuss(a)lists.openstack.org> Subject: [masakari] pacemaker-remote Setup Overview Message-ID: <AM6PR04MB47112DF6617442709662B43389D30(a)AM6PR04MB4711.eurprd04.prod.outlook.com> Content-Type: text/plain; charset="utf-8" Hello, Utilizing openstack-ansible we successfully installed all the masakari services. Besides masakari-hostmonitor all are running fine. For the hostmonitor a pacemaker cluster is missing. Can anyone give me an overview how the pacemaker cluster setup would look like? Which (pacemaker) services is running where (compute nodes, something on any other node,...), etc? Best regards, Ralf Teckelmann -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190812…> ------------------------------ Subject: Digest Footer _______________________________________________ openstack-discuss mailing list openstack-discuss(a)lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss ------------------------------ End of openstack-discuss Digest, Vol 10, Issue 59 ************************************************* Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding. ------------------------------ Message: 3 Date: Mon, 19 Aug 2019 18:36:01 +0200 From: Andreas Jaeger <aj(a)suse.com> To: Mohammed Naser <mnaser(a)vexxhost.com>, OpenStack Discuss <openstack-discuss(a)lists.openstack.org>, juliaashleykreger(a)gmail.com Subject: Re: [tc] weekly update Message-ID: <803b9cce-9887-95a5-b257-21f164f5569a(a)suse.com> Content-Type: text/plain; charset=utf-8 On 19/08/2019 18.26, Mohammed Naser wrote: > Hi everyone, > > Here’s the update for what happened in the OpenStack TC this week. You > can get more information by checking for changes in > openstack/governance repository. > > # Retired projects > - Networking-generic-switch-tempest (from networking-generic-switch): > https://review.opendev.org/#/c/674430/ The process for retiring is documented here: https://docs.openstack.org/infra/manual/drivers.html#retiring-a-project Could you follow those steps to get the system out of Zuul properly, please? Andreas > # General changes > - Michał Dulko as Kuryr PTL: https://review.opendev.org/#/c/674624/ > - Added a mission to Swift taken from its wiki: > https://review.opendev.org/#/c/675307/ > - Sean McGinnis as release PTL: https://review.opendev.org/#/c/675246/ > > Thanks for tuning in! > > Regards, > Mohammed > -- Andreas Jaeger aj(a)suse.com Twitter: jaegerandi SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D 90409 Nürnberg GF: Nils Brauckmann, Felix Imendörffer, Enrica Angelone, HRB 247165 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 ------------------------------ Message: 4 Date: Mon, 19 Aug 2019 12:48:40 -0400 From: Doug Hellmann <doug(a)doughellmann.com> To: Jeremy Stanley <fungi(a)yuggoth.org> Cc: openstack-discuss(a)lists.openstack.org Subject: Re: [all] [tc] [docs] [release] [ptls] Docs as SIG: Ownership of docs.openstack.org Message-ID: <740FFC7B-F7F0-427C-95F8-C6D6E8A0FA7E(a)doughellmann.com> Content-Type: text/plain;charset=utf-8 > On Aug 19, 2019, at 10:59 AM, Jeremy Stanley <fungi(a)yuggoth.org> wrote: > > On 2019-08-19 13:17:35 +0000 (+0000), Alexandra Settle wrote: > [...] >> Doug has rightfully pointed out that whilst the documentation team >> as it stands today is no longer "integral", the docs.openstack.org >> web site is. An owner is required. >> >> The suggestion is for the Release Management team is the "least >> worst" (thanks, tonyb) place for the website manaagement to land. >> As Tony points out, this requires learning new tools and processes >> but the individuals working on the docs team currently have no >> intention to leave, and are around to help manage this from the >> SIG. >> >> Open to discussion and suggestions, but to summarise the proposal >> here: >> >> docs.openstack.org ownership is to transition to be the >> responsibility of the Release Management team officially provided >> there are no strong objections. > [...] > > The prose above is rather vague on what "the docs.openstack.org web > site" entails. Inferring from Doug's comments on 657142, I think you > and he are referring specifically to the content in the > https://opendev.org/openstack/openstack-manuals/src/branch/master/www > subtree. Is that pretty much it? The Apache virtual host > configuration and filesystem hosting the site itself are managed by > the Infra/OpenDev team, and there aren't any plans to change that as > far as I'm aware. > -- > Jeremy Stanley Yes, that’s correct. Doug ------------------------------ Subject: Digest Footer _______________________________________________ openstack-discuss mailing list openstack-discuss(a)lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss ------------------------------ End of openstack-discuss Digest, Vol 10, Issue 94 ************************************************* Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding.

2 1

[ptl][keystone] PTL Out of Office August 24 - September 4
by Colleen Murphy 20 Aug '19

20 Aug '19

As mentioned in today's keystone meeting, I will be on vacation between August 24 and September 4 with no laptop and little to no cell service. Morgan Fainberg (kmalloc) has graciously agreed to step up as acting PTL while I am gone (thank you!). We agreed in today's meeting that the team will plan to hold next week's meeting as usual and possibly skip the following one. Office hours will be cancelled unless someone decides they really want to cover something with the team. The priority efforts for the next couple of weeks are: * finish remaining system-scope/default roles migrations (deadline is feature freeze, Sept 9-13) * reviews for spec implementations and system-scope/default roles migrations (deadline is feature freeze, Sept 9-13) * reviews for keystonemiddleware and keystoneauth (final release Sept 2-6) * reviews for python-keystoneclient (final release Sept 9-13) * helping the requirements team with any requirements issues[1] before requirements freeze (Sept 9-13) * completing community goals (follow the PDF generation news[2]) In the event there's feedback on one of my own outstanding patches that needs to be addressed in a timely manner, I grant any keystone core permission to go ahead and update it (that goes generally even when I'm not completely AFK). Colleen [1] https://bugs.launchpad.net/keystone/+bug/1839393 [2] http://lists.openstack.org/pipermail/openstack-discuss/2019-August/008506.h…

1 0

Re: [all][infra] Zuul logs are in swift
by Eric Fried 20 Aug '19

20 Aug '19

Hi infra. I wanted to blast out a handful of issues I've had since the cutover to swift. I'm using Chrome Version 76.0.3809.100 (Official Build) (64-bit) on bionic (18.04.3). - Hot tip: if you want the dynamic logs (with timestamp links and sev filters), use the twisties. Clicking through gets you to the raw files. The former was not obvious to me. - Some in-app logs aren't working. E.g. when I try to look at controller=>logs=>screen-n-cpu.txt.gz from [1], it redirects me to [2]. The hover [3] has a double slash in it, not sure if that's related, but when I try squashing to one slash, I get an error... sometimes [4]. - When the in-app logs do render, they don't wrap. There's a horizontal scroll bar, but it's at the bottom of an inner frame, so it's off the screen most of the time and therefore not useful. (I don't have horizontal mouse scroll capabilities; maybe I should look into that.) - The timestamp links in app anchor the line at the "top" - which (for me, anyway) is "underneath" the header menu (Status Projects Jobs Labels Nodes Builds Buildsets), so I have to scroll up to get the anchored line and a few of its successors. Thanks as always for all your hard work. efried [1] https://zuul.opendev.org/t/openstack/build/402a73a9238643c2b893d53b37a6ce27… [2] https://zuul.opendev.org/tenants [3] https://zuul.opendev.org/t/openstack/build/402a73a9238643c2b893d53b37a6ce27… [4] http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infr…

4 9

[all][tc]Naming the U release of OpenStack -- Poll open
by Rico Lin 20 Aug '19

20 Aug '19

Hi, all OpenStackers, It's time to vote for the naming of the U release!! U 版本正式命名票选开始!! First, big thanks for all people who take their own time to propose names on [2] or help to push/improve to the naming process. Thank you. We'll use a public polling option over per-user private URLs for voting. This means everybody should proceed to use the following URL to cast their vote: *https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_19e5119b14f86294&akey=0cde542cb3de1b12 <https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_19e5119b14f86294&akey=0cde…>* We've selected a public poll to ensure that the whole community, not just Gerrit change owners get a vote. Also, the size of our community has grown such that we can overwhelm CIVS if using private URLs. A public can mean that users behind NAT, proxy servers or firewalls may receive a message saying that your vote has already been lodged if this happens please try another IP. Because this is a public poll, results will currently be only viewable by me until the poll closes. Once closed, I'll post the URL making the results viewable to everybody. This was done to avoid everybody seeing the results while the public poll is running. The poll will officially end on 2019-08-20 23:59:00+00:00 (UTC time)[1], and results will be posted shortly after. [1] https://governance.openstack.org/tc/reference/release-naming.html [2] https://wiki.openstack.org/wiki/Release_Naming/U_Proposals -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

1 3

[uc] Less than 4 days left to nominate for the UC!
by Ed Leafe 20 Aug '19

20 Aug '19

A week has gone by since nominations opened, and we have yet to receive a single nomination! Now I’m sure everyone’s waiting until the last minute in order to make a dramatic moment, but don’t put it off for *too* long! If you missed the initial announcement [0], here’s the information you need: Any individual member of the Foundation who is an Active User Contributor (AUC) can propose their candidacy (except the three sitting UC members elected in the previous election). Self-nomination is common, no third party nomination is required. They do so by sending an email to the user-committee(a)lists.openstack.orgmailing-list, with the subject: “UC candidacy” by August 16, 05:59 UTC. The email can include a description of the candidate platform. The candidacy is then confirmed by one of the election officials, after verification of the electorate status of the candidate. -- Ed Leafe [0] http://lists.openstack.org/pipermail/user-committee/2019-August/002864.html

3 4

Update / change user_id from server / VM
by Pawel Konczalski 20 Aug '19

20 Aug '19

Hi all, is it possible to update / change the user_id of a OpenStack server (VM) if the user no more exists? # openstack server show 8cf8164a-6f55-4435-9f4e-621617d7951f -c user_id +---------+----------------------------------+ | Field | Value | +---------+----------------------------------+ | user_id | ebfd5b2bf26a4f4381a290948cb3ce8b | +---------+----------------------------------+ # openstack user show ebfd5b2bf26a4f4381a290948cb3ce8b No user with a name or ID of 'ebfd5b2bf26a4f4381a290948cb3ce8b' exists. BR Pawel

1 0

ops meetup team meeting 2019-8-20
by Chris Morgan 20 Aug '19

20 Aug '19

Minutes for the openstack ops meetups team meeting today are linked below. Here are some notes: - Attendance at the upcoming NYC meetup (hosted at Bloomberg) is up to 40 and still growing - Hoping to arrange a social event on the evening of day 1, a sponsor for that is still being sought - easiest way to get updates is to follow https://twitter.com/osopsmeetup - one of the sessions will propose bringing more ceph content to these meetups or starting a new similar dedicated ceph operators meetup series <https://twitter.com/osopsmeetup> Meeting ended Tue Aug 20 14:37:20 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 10:37 AM Minutes: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2019/ops_meetup_tea… 10:37 AM Minutes (text): http://eavesdrop.openstack.org/meetings/ops_meetup_team/2019/ops_meetup_tea… 10:37 AM Log: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2019/ops_meetup_tea… Cheers, Chris -- Chris Morgan <mihalis68(a)gmail.com>

1 0

[all][infra] Changes to docs publishing (promote pipeline)
by Andreas Jaeger 20 Aug '19

20 Aug '19

We have set up in Zuul a new way of publishing artifacts and are beginning to use that now for documentation jobs [1]: The documents built in the gate queue are published as is with just copying over to our webserver in the promote pipeline. The jobs for building are still the same name (small implementation change), only the publish job has changed: It's now in the promote pipeline. There's no need for you to do anything. This work has been done for openstack-tox-docs (used by most OpenStack projects), api-ref and api-guide jobs, and for openstack-manuals and friends. To iterate the old way was: 1) Build docs in gate pipeline 2) Merge 3) Build docs in post pipeline (same git tree!) 4) Publish Now we do: 1) Build docs in gate pipeline 2) Merge 3) Take logs from gate pipeline and publish them You will notice a changed behaviour: The promote pipeline reports to gerrit - unlike the post one. So, you see that in the review and also get notified via email. Note that changes currently in gate pipeline might have used the previous openstack-tox-docs implemention and will fail since the promote job needs the changed implementation. The next publish will work. If you have any questions, please ask on #openstack-infra IRC channel. [1] https://review.opendev.org/677009 -- Andreas Jaeger aj(a)suse.com Twitter: jaegerandi SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

1 0

How are we managing quotas, flavors, projects and more across large org Openstack deployments?
by Robert Lennie 20 Aug '19

20 Aug '19

Hi, I am a complete neophyte to this forum so I may have missed any earlier discussions on this topic if there have been any? I am currently working on a proprietary legacy (Django based) "OpenStack Operations Manager" dashboard system that attempts to manage quotas, flavors, clusters and more across a very large distributed OpenStack deployment for multiple customers. There are a number of potential shortcomings with our current dashboard system and I was wondering how other teams in other organizations with similar large Openstack deployments are handling these types of system management issues? The issues addressed are likely common to other large environments. In particular what tools might exist upstream that allow system (particularly quota and flavor) management across large distributed Openstack environments? I welcome any feedback, comments, suggestions and any other information regarding the tools that currently exist or may be planned for this purpose? Regards, Robert Lennie Principal Software Engineer Verizon Media

5 5

Re: [masakari] how to install masakari on centos 7 (Vu Tan)
by Devharakar, Shilpa 20 Aug '19

20 Aug '19

Hi Vu Tan, Sorry for the attachment, instead please refer [1] Here are the steps we verified for Masakari installation on Ubuntu Distribution with openstack installed via devstack. [1]: http://paste.openstack.org/show/760303/ > Hi Vu Tan, > > Sorry for late reply. > Here are the steps we verified on Ubuntu Distribution, installed openstack via devstack. > > PFA 'detailed_steps_to_install_masakari.txt' > Do not refer '/masakari/etc/Masakari.conf' sample file, instead generate it using 'tox -egenconfig' after 'git clone' Thanks with Regards, Shilpa Shivaji Devharakar| Software Development Supervisor | NTT DATA Services| w. 91-020- 67095703 | Shilpa.Devharakar(a)nttdata.com | Learn more at nttdata.com/americas -----Original Message----- From: openstack-discuss-request(a)lists.openstack.org <openstack-discuss-request(a)lists.openstack.org> Sent: Monday, August 19, 2019 10:42 PM To: openstack-discuss(a)lists.openstack.org Subject: openstack-discuss Digest, Vol 10, Issue 95 Send openstack-discuss mailing list submissions to openstack-discuss(a)lists.openstack.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss or, via email, send a message with subject or body 'help' to openstack-discuss-request(a)lists.openstack.org You can reach the person managing the list at openstack-discuss-owner(a)lists.openstack.org When replying, please edit your Subject line so it is more specific than "Re: Contents of openstack-discuss digest..." Today's Topics: 1. Re: [all] [tc] [docs] [release] [ptls] Docs as SIG: Ownership of docs.openstack.org (Doug Hellmann) 2. Re: [openstack-dev] Dropping lazy translation support (Shengjing Zhu) 3. [neutron] Bug Deputy Report August 12 - August 19 (Ryan Tidwell) 4. Re: [masakari] how to install masakari on centos 7 (Vu Tan) (Devharakar, Shilpa) ---------------------------------------------------------------------- Message: 1 Date: Mon, 19 Aug 2019 12:59:32 -0400 From: Doug Hellmann <doug(a)doughellmann.com> To: Sean McGinnis <sean.mcginnis(a)gmx.com> Cc: Alexandra Settle <a.settle(a)outlook.com>, OpenStack Discuss <openstack-discuss(a)lists.openstack.org> Subject: Re: [all] [tc] [docs] [release] [ptls] Docs as SIG: Ownership of docs.openstack.org Message-ID: <9DABCC6E-1E61-45A6-8370-4F086428B3B6(a)doughellmann.com> Content-Type: text/plain;charset=utf-8 > On Aug 19, 2019, at 11:41 AM, Sean McGinnis <sean.mcginnis(a)gmx.com> wrote: > >> >> Quick recap: The documentation team is set to disband as an official >> project, and make the leap to becoming a SIG (Special Interest Group). >> >> >> The remaining individuals working on the docs team are sorting >> through what's left and where it is best placed. In [1], Doug has >> rightfully pointed out that whilst the documentation team as it >> stands today is no longer "integral", the docs.openstack.org web site >> is. An owner is required. >> > > Unless things have changed, SIGs can be owners of a resource published > via docs.openstack.org (and I am assuming that means be extension, > docs.o.o itself). Is there a reason the Docs SIG would not still be > able to own the site? > >> The suggestion is for the Release Management team is the "least worst" >> (thanks, tonyb) place for the website manaagement to land. As Tony >> points out, this requires learning new tools and processes but the >> individuals working on the docs team currently have no intention to >> leave, and are around to help manage this from the SIG. >> > > I'm personally fine with the release team taking this on, but it does > seem like an odd fit. I think it would make a lot more sense for the > Docs SIG to own the docs site than the release team. Thierry has always drawn (one of) the distinction(s) between teams and SIGs as being that teams own tasks that are “part of” the thing we produce that we call OpenStack, while SIGs are less formally part of that input to that production process. Updating the docs site every time we have a new release felt like it should be part of the formal process, and definitely not something we should leave to chance. The cadence made me think the release team could be a good home. It’s 95% automated now, for what that’s worth. I imagine someone could automate the step of adding the new series pages, although I’m not sure what the trigger would be. We could also look at other ways to build the site that don’t require any action each cycle, of course, including not updating it at all and only publishing docs out of master. That’s especially appealing if we don’t have anyone in the community willing and able to pick up the work. > >> Open to discussion and suggestions, but to summarise the proposal here: >> >> docs.openstack.org ownership is to transition to be the >> responsibility of the Release Management team officially provided >> there are no strong objections. >> >> Thanks, >> >> Alex >> IRC: asettle >> >> [1] https://review.opendev.org/#/c/657142/ >> [2] https://review.opendev.org/#/c/657141/ > ------------------------------ Message: 2 Date: Mon, 19 Aug 2019 20:46:05 +0800 From: Shengjing Zhu <zsj950618(a)gmail.com> To: openstack-discuss(a)lists.openstack.org Cc: mriedemos(a)gmail.com Subject: Re: [openstack-dev] Dropping lazy translation support Message-ID: <CAG+qr1F8BcOvw3YyQg9CUptkSxDAsW_125aSCDydTGjWQHfLiw(a)mail.gmail.com> Content-Type: text/plain; charset="UTF-8" Sorry for replying the old mail, and please cc me when reply. Matt Riedemann <mriedemos at gmail.com> writes: > This is a follow up to a dev ML email [1] where I noticed that some > implementations of the upgrade-checkers goal were failing because some > projects still use the oslo_i18n.enable_lazy() hook for lazy log > message translation (and maybe API responses?). > > The very old blueprints related to this can be found here [2][3][4]. > > If memory serves me correctly from my time working at IBM on this, > this was needed to: > > 1. Generate logs translated in other languages. > > 2. Return REST API responses if the "Accept-Language" header was used > and a suitable translation existed for that language. > > #1 is a dead horse since I think at least the Ocata summit when we > agreed to no longer translate logs since no one used them. > > #2 is probably something no one knows about. I can't find end-user > documentation about it anywhere. It's not tested and therefore I have > no idea if it actually works anymore. > > I would like to (1) deprecate the oslo_i18n.enable_lazy() function so > new projects don't use it and (2) start removing the enable_lazy() > usage from existing projects like keystone, glance and cinder. > > Are there any users, deployments or vendor distributions that still > rely on this feature? If so, please speak up now. I was pointed to this discussion when I tried to fix this feature in keystone, https://review.opendev.org/677117 For #2 translated API response, this feature probably hasn't been working for some time, but it's still a valid user case. Has the decision been settled? -- Regards, Shengjing Zhu ------------------------------ Message: 3 Date: Mon, 19 Aug 2019 11:32:23 -0500 From: Ryan Tidwell <rktidwell85(a)gmail.com> To: openstack-discuss(a)lists.openstack.org Subject: [neutron] Bug Deputy Report August 12 - August 19 Message-ID: <CAKe2JbjhPpg0AjwX8yXj+iTtuYCVe=PoGOgcK0DdoNyLFRckFw(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hello Neutron Team, Here is my bug deputy report for August 12 - August 19: Medium: -[OVS agent] Physical bridges can't be initialized if there is no connectivity to rabbitmq https://bugs.launchpad.net/neutron/+bug/1840443 The fix for this has been merged and a number of backports have merged as well. It appears to have been handled by the team. - excessive number of dvrs where vm got a fixed ip on floating network https://bugs.launchpad.net/bugs/1840579 https://review.opendev.org/#/c/677092/ has been proposed and is being worked on. This appears to be related to how we determine whether to instantiate a DVR local router on a compute node. It looks like there is a case where we create a local router when it's not necessary, thereby consuming too many IP's on the floating IP network at scale. Undecided: - network/subnet resources cannot be read and written separated https://bugs.launchpad.net/neutron/+bug/1840638 https://review.opendev.org/#/c/677166/ has been proposed. This was just reported just a few hours ago and still needs some triage to confirm severity of the issue. RFE's: - [RFE] Add new config option to enable IGMP snooping in ovs https://bugs.launchpad.net/bugs/1840136 Regards, Ryan Tidwell -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190819…> ------------------------------ Message: 4 Date: Mon, 19 Aug 2019 16:33:40 +0000 From: "Devharakar, Shilpa" <Shilpa.Devharakar(a)nttdata.com> To: "openstack-discuss(a)lists.openstack.org" <openstack-discuss(a)lists.openstack.org> Subject: Re: [masakari] how to install masakari on centos 7 (Vu Tan) Message-ID: <CH2PR12MB4072BC1B71DAFAF0B8E3021CFFA80(a)CH2PR12MB4072.namprd12.prod.outlook.com> Content-Type: text/plain; charset="utf-8" Hi Vu Tan, Sorry for late reply. Here are the steps we verified on Ubuntu Distribution, installed openstack via devstack. PFA 'detailed_steps_to_install_masakari.txt' Do not refer '/masakari/etc/Masakari.conf' sample file, instead generate it using 'tox -egenconfig' after 'git clone' > Hi Patil, > May I know how is it going ? > >> On Tue, Jul 23, 2019 at 10:18 PM Vu Tan <vungoctan252(a)gmail.com> wrote: >> >> Hi Patil, >> Thank you for your reply, please instruct me if you successfully >> install it. Thanks a lot >> >> On Tue, Jul 23, 2019 at 8:12 PM Patil, Tushar > > <Tushar.Patil(a)nttdata.com> >> wrote: >> >> Hi Vu Tan, >> >> I'm trying to install Masakari using source code to reproduce the issue. >> If I hit the same issue as yours, I will troubleshoot this issue and >> let you know the solution or will update you what steps I have >> followed to bring up Masakari services successfully. >> >> Regards, >> Tushar Patil >> >> ________________________________________ >> From: Vu Tan <vungoctan252(a)gmail.com> >> Sent: Monday, July 22, 2019 12:33 PM >> To: Gaëtan Trellu >> Cc: Patil, Tushar; openstack-discuss(a)lists.openstack.org >> Subject: Re: [masakari] how to install masakari on centos 7 >> >> Hi Patil, >> May I know when the proper document for masakari is released ? I have >> configured conf file in controller and compute node, it seems running >> but it is not running as it should be, a lots of error in logs, here >> is a sample log: >> >> 2.7/site-packages/oslo_config/cfg.py:3024 >> 2019-07-19 10:25:26.360 7745 DEBUG oslo_service.service [-] bindir >> = /usr/local/bin log_opt_values /usr/lib/ >> python2.7/site-packages/oslo_config/cfg.py:3024 >> 2019-07-19 18:46:21.291 7770 ERROR masakari File >> "/usr/lib/python2.7/site-packages/oslo_service/service.py", line 65, >> in _is_daemo n >> 2019-07-19 18:46:21.291 7770 ERROR masakari is_daemon = os.getpgrp() >> != os.tcgetpgrp(sys.stdout.fileno()) >> 2019-07-19 18:46:21.291 7770 ERROR masakari OSError: [Errno 5] >> Input/output error >> 2019-07-19 18:46:21.291 7770 ERROR masakari >> 2019-07-19 18:46:21.300 7745 CRITICAL masakari [-] Unhandled error: >> OSError: [Errno 5] Input/output error >> 2019-07-19 18:46:21.300 7745 ERROR masakari Traceback (most recent >> call >> last): >> 2019-07-19 18:46:21.300 7745 ERROR masakari File >> "/usr/bin/masakari-api", line 10, in <module> >> >> I dont know if it is missing package or wrong configuration >> >> >> On Thu, Jul 11, 2019 at 6:14 PM Gaëtan Trellu < >> gaetan.trellu(a)incloudus.com<mailto:gaetan.trellu@incloudus.com>> wrote: >> You will have to enable the debit, debug = true and check the APi log. >> >> Did you try to use the openstack CLi ? >> >> Gaetan >> >> On Jul 11, 2019 12:32 AM, Vu Tan <vungoctan252(a)gmail.com<mailto: >> vungoctan252(a)gmail.com>> wrote: >> I know it's just a warning, just take a look at this image: >> [image.png] >> it's just hang there forever, and in the log show what I have shown >> to you >> >> On Wed, Jul 10, 2019 at 8:07 PM Gaëtan Trellu < >> gaetan.trellu(a)incloudus.com<mailto:gaetan.trellu@incloudus.com>> wrote: >> This is just a warning, not an error. >> >> On Jul 10, 2019 3:12 AM, Vu Tan <vungoctan252(a)gmail.com<mailto: >> vungoctan252(a)gmail.com>> wrote: >> Hi Gaetan, >> I follow you the guide you gave me, but the problem still persist, >> can you please take a look at my configuration to see what is wrong >> or what is missing in my config ? >> the error: >> 2019-07-10 14:08:46.876 17292 WARNING >> keystonemiddleware._common.config [-] The option "__file__" in conf >> is not known to auth_token >> 2019-07-10 14:08:46.876 17292 WARNING >> keystonemiddleware._common.config [-] The option "here" in conf is >> not known to auth_token >> 2019-07-10 14:08:46.882 17292 WARNING keystonemiddleware.auth_token >> [-] AuthToken middleware is set with keystone_authtoken.service_ >> >> the config: >> >> [DEFAULT] >> enabled_apis = masakari_api >> log_dir = /var/log/kolla/masakari >> state_path = /var/lib/masakari >> os_user_domain_name = default >> os_project_domain_name = default >> os_privileged_user_tenant = service >> os_privileged_user_auth_url = http://controller:5000/v3 >> os_privileged_user_name = nova os_privileged_user_password = P@ssword >> masakari_api_listen = controller masakari_api_listen_port = 15868 >> debug = False auth_strategy=keystone >> >> [wsgi] >> # The paste configuration file path >> api_paste_config = /etc/masakari/api-paste.ini >> >> [keystone_authtoken] >> www_authenticate_uri = http://controller:5000 auth_url = >> http://controller:5000 auth_type = password project_domain_id = >> default project_domain_name = default user_domain_name = default >> user_domain_id = default project_name = service username = masakari >> password = P@ssword region_name = RegionOne >> >> [oslo_middleware] >> enable_proxy_headers_parsing = True >> >> [database] >> connection = mysql+pymysql://masakari:P@ssword@controller/masakari >> >> >> >> On Tue, Jul 9, 2019 at 10:25 PM Vu Tan <vungoctan252(a)gmail.com<mailto: >> vungoctan252(a)gmail.com>> wrote: >> Thank Patil Tushar, I hope it will be available soon >> >> On Tue, Jul 9, 2019 at 8:18 AM Patil, Tushar >> <Tushar.Patil(a)nttdata.com <mailto:Tushar.Patil@nttdata.com>> wrote: >> Hi Vu and Gaetan, >> >> Gaetan, thank you for helping out Vu in setting up masakari-monitors >> service. >> >> As a masakari team ,we have noticed there is a need to add proper >> documentation to help the community run Masakari services in their >> environment. We are working on adding proper documentation in this 'Train' >> cycle. >> >> Will send an email on this mailing list once the patches are uploaded >> on the gerrit so that you can give your feedback on the same. >> >> If you have any trouble in setting up Masakari, please let us know on >> this mailing list or join the bi-weekly IRC Masakari meeting on the >> #openstack-meeting IRC channel. The next meeting will be held on 16th >> July >> 2019 @0400 UTC. >> >> Regards, >> Tushar Patil >> >> ________________________________________ >> From: Vu Tan <vungoctan252(a)gmail.com<mailto:vungoctan252@gmail.com>> >> Sent: Monday, July 8, 2019 11:21:16 PM >> To: Gaëtan Trellu >> Cc: openstack-discuss(a)lists.openstack.org<mailto: >> openstack-discuss(a)lists.openstack.org> >> Subject: Re: [masakari] how to install masakari on centos 7 >> >> Hi Gaetan, >> Thanks for pinpoint this out, silly me that did not notice the simple >> "error InterpreterNotFound: python3". Thanks a lot, I appreciate it >> >> On Mon, Jul 8, 2019 at 9:15 PM <gaetan.trellu(a)incloudus.com<mailto: >> gaetan.trellu(a)incloudus.com><mailto:gaetan.trellu@incloudus.com<mailto: >> gaetan.trellu(a)incloudus.com>>> wrote: >> Vu Tan, >> >> About "auth_token" error, you need "os_privileged_user_*" options >> into your masakari.conf for the API. >> As mentioned previously please have a look here to have an example of >> configuration working (for me at least): >> >> - masakari.conf: >> >> https://review.opendev.org/#/c/615715/42/ansible/roles/masakari/templ >> ates/masakari.conf.j2 >> - masakari-monitor.conf: >> >> https://review.opendev.org/#/c/615715/42/ansible/roles/masakari/templ >> ates/masakari-monitors.conf.j2 >> >> About your tox issue make sure you have Python3 installed. >> >> Gaëtan >> >> On 2019-07-08 06:08, Vu Tan wrote: >> >> > Hi Gaetan, >> > I try to generate config file by using this command tox -egenconfig >> > on top level of masakari but the output is error, is this masakari >> > still in beta version ? >> > [root@compute1 masakari-monitors]# tox -egenconfig genconfig >> > create: /root/masakari-monitors/.tox/genconfig >> > ERROR: InterpreterNotFound: python3 >> > _____________________________________________________________ >> > summary >> > ______________________________________________________________ >> > ERROR: genconfig: InterpreterNotFound: python3 >> > >> > On Mon, Jul 8, 2019 at 3:24 PM Vu Tan <vungoctan252(a)gmail.com<mailto: >> vungoctan252(a)gmail.com><mailto:vungoctan252@gmail.com<mailto: >> vungoctan252(a)gmail.com>>> wrote: >> > Hi, >> > Thanks a lot for your reply, I install pacemaker/corosync, >> > masakari-api, maskari-engine on controller node, and I run >> > masakari-api with this command: masakari-api, but I dont know >> > whether the process is running like that or is it just hang there, >> > here is what it shows when I run the command, I leave it there for >> > a while but it does not change anything : >> > [root@controller masakari]# masakari-api >> > 2019-07-08 15:21:09.946 30250 INFO masakari.api.openstack [-] >> > Loaded >> > extensions: ['extensions', 'notifications', 'os-hosts', 'segments', >> > 'versions'] >> > 2019-07-08 15:21:09.955 30250 WARNING >> > keystonemiddleware._common.config [-] The option "__file__" in conf >> > is not known to auth_token >> > 2019-07-08 15:21:09.955 30250 WARNING >> > keystonemiddleware._common.config [-] The option "here" in conf is >> > not known to auth_token >> > 2019-07-08 15:21:09.960 30250 WARNING keystonemiddleware.auth_token >> > [-] AuthToken middleware is set with >> > keystone_authtoken.service_token_roles_required set to False. This >> > is backwards compatible but deprecated behaviour. Please set this to True. >> > 2019-07-08 15:21:09.974 30250 INFO masakari.wsgi [-] masakari_api >> > listening on 127.0.0.1:15868<http://127.0.0.1:15868>< >> http://127.0.0.1:15868> >> > 2019-07-08 15:21:09.975 30250 INFO oslo_service.service [-] >> > Starting 4 workers >> > 2019-07-08 15:21:09.984 30274 INFO >> > masakari.masakari_api.wsgi.server [-] (30274) wsgi starting up on >> > http://127.0.0.1:15868 >> > 2019-07-08 15:21:09.985 30275 INFO >> > masakari.masakari_api.wsgi.server [-] (30275) wsgi starting up on >> > http://127.0.0.1:15868 >> > 2019-07-08 15:21:09.992 30277 INFO >> > masakari.masakari_api.wsgi.server [-] (30277) wsgi starting up on >> > http://127.0.0.1:15868 >> > 2019-07-08 15:21:09.994 30276 INFO >> > masakari.masakari_api.wsgi.server [-] (30276) wsgi starting up on >> > http://127.0.0.1:15868 >> > >> > On Sun, Jul 7, 2019 at 7:37 PM Gaëtan Trellu >> ><gaetan.trellu(a)incloudus.com<mailto:gaetan.trellu@incloudus.com >> ><mailto:gaetan.trellu@incloudus.com<mailto:gaetan.trellu@incloudus.c >> >om>>> >> wrote: >> > >> > Hi Vu Tan, >> > >> > Masakari documentation doesn't really exist... I had to figured >> > some stuff by myself to make it works into Kolla project. >> > >> > On controller nodes you need: >> > >> > - pacemaker >> > - corosync >> > - masakari-api (openstack/masakari repository) >> > - masakari- engine (openstack/masakari repository) >> > >> > On compute nodes you need: >> > >> > - pacemaker-remote (integrated to pacemaker cluster as a resource) >> > - masakari- hostmonitor (openstack/masakari-monitor repository) >> > - masakari-instancemonitor (openstack/masakari-monitor repository) >> > - masakari-processmonitor (openstack/masakari-monitor repository) >> > >> > For masakari-hostmonitor, the service needs to have access to >> > systemctl command (make sure you are not using sysvinit). >> > >> > For masakari-monitor, the masakari-monitor.conf is a bit different, >> > you will have to configure the [api] section properly. >> > >> > RabbitMQ needs to be configured (as transport_url) on masakari-api >> > and masakari-engine too. >> > >> > Please check this review[1], you will have masakari.conf and >> > masakari-monitor.conf configuration examples. >> > >> > [1] https://review.opendev.org/#/c/615715 >> > >> > Gaëtan >> > >> > On Jul 7, 2019 12:08 AM, Vu Tan <vungoctan252(a)gmail.com<mailto: >> vungoctan252(a)gmail.com><mailto:vungoctan252@gmail.com<mailto: >> vungoctan252(a)gmail.com>>> wrote: >> > >> > VU TAN <VUNGOCTAN252(a)GMAIL.COM<mailto:VUNGOCTAN252@GMAIL.COM><mailto: >> VUNGOCTAN252(a)GMAIL.COM<mailto:VUNGOCTAN252@GMAIL.COM>>> >> > >> > 10:30 AM (35 minutes ago) >> > >> > to openstack-discuss >> > >> > Sorry, I resend this email because I realized that I lacked of >> > prefix on this email's subject >> > >> > Hi, >> > >> > I would like to use Masakari and I'm having trouble finding a step >> > by step or other documentation to get started with. Which part >> > should be installed on controller, which is should be on compute, >> > and what is the prerequisite to install masakari, I have installed >> > corosync and pacemaker on compute and controller nodes, , what else >> > do I need to do ? step I have done so far: >> > - installed corosync/pacemaker >> > - install masakari on compute node on this github repo: >> > https://github.com/openstack/masakari >> > - add masakari in to mariadb >> > here is my configuration file of masakari.conf, do you mind to take >> > a look at it, if I have misconfigured anything? >> > >> > [DEFAULT] >> > enabled_apis = masakari_api >> > >> > # Enable to specify listening IP other than default >> > masakari_api_listen = controller # Enable to specify port other >> > than default masakari_api_listen_port = 15868 debug = False >> > auth_strategy=keystone >> > >> > [wsgi] >> > # The paste configuration file path api_paste_config = >> > /etc/masakari/api-paste.ini >> > >> > [keystone_authtoken] >> > www_authenticate_uri = http://controller:5000 auth_url = >> > http://controller:5000 auth_type = password project_domain_id = >> > default user_domain_id = default project_name = service username = >> > masakari password = P@ssword >> > >> > [database] >> > connection = mysql+pymysql://masakari:P@ssword@controller/masakari >> Disclaimer: This email and any attachments are sent in strictest >> confidence for the sole use of the addressee and may contain legally >> privileged, confidential, and proprietary data. If you are not the >> intended recipient, please advise the sender by replying promptly to >> this email and then delete and destroy this email and any attachments >> without any further use, copying or forwarding. >> >> >> Disclaimer: This email and any attachments are sent in strictest >> confidence for the sole use of the addressee and may contain legally >> privileged, confidential, and proprietary data. If you are not the >> intended recipient, please advise the sender by replying promptly to >> this email and then delete and destroy this email and any attachments >> without any further use, copying or forwarding. >> > Thanks with Regards, Shilpa Shivaji Devharakar| Software Development Supervisor | NTT DATA Services| w. 91-020- 67095703 | Shilpa.Devharakar(a)nttdata.com | Learn more at nttdata.com/americas -----Original Message----- From: openstack-discuss-request(a)lists.openstack.org <openstack-discuss-request(a)lists.openstack.org> Sent: Sunday, August 4, 2019 12:42 AM To: openstack-discuss(a)lists.openstack.org Subject: openstack-discuss Digest, Vol 10, Issue 13 Send openstack-discuss mailing list submissions to openstack-discuss(a)lists.openstack.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss or, via email, send a message with subject or body 'help' to openstack-discuss-request(a)lists.openstack.org You can reach the person managing the list at openstack-discuss-owner(a)lists.openstack.org When replying, please edit your Subject line so it is more specific than "Re: Contents of openstack-discuss digest..." Today's Topics: 1. Re: [nova][ops] Documenting nova tunables at scale (Joe Robinson) 2. Re: [masakari] how to install masakari on centos 7 (Vu Tan) ---------------------------------------------------------------------- Message: 1 Date: Sat, 3 Aug 2019 10:40:11 +1000 From: Joe Robinson <joseph.r.email(a)gmail.com> To: Matt Riedemann <mriedemos(a)gmail.com> Cc: openstack-discuss(a)lists.openstack.org Subject: Re: [nova][ops] Documenting nova tunables at scale Message-ID: <CAOvR4Gx1K+7+Thyz-qv57D-vNx-OZQFtxhxk+X6hCQT3QiGpug(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi Matt, My name is Joe - docs person from years back - this looks like a good initiative and I would be up for documenting these settings at scale. Next step I can see is gathering more Info about this pain point (already started :)) and then I can draft something together for feedback. On Sat, 3 Aug. 2019, 6:25 am Matt Riedemann, <mriedemos(a)gmail.com> wrote: > I wanted to send this to get other people's feedback if they have > particular nova configurations once they hit a certain scale (hundreds > or thousands of nodes). Every once in awhile in IRC I'll be chatting > with someone about configuration changes they've made running at large > scale to avoid, for example, hammering the control plane. I don't know > how many times I've thought, "it would be nice if we had a doc > highlighting some of these things so a new operator could come along > and see, oh I've never tried changing that value before". > > I haven't started that doc, but I've started a bug report for people > to dump some of their settings. The most common ones could go into a > simple admin doc to start. > > I know there is more I've thought about in the past that I don't have > in here but this is just a starting point so I don't make the mistake > of not taking action on this again. > > https://bugs.launchpad.net/nova/+bug/1838819 > > -- > > Thanks, > > Matt > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190803…> ------------------------------ Message: 2 Date: Thu, 1 Aug 2019 11:43:13 +0700 From: Vu Tan <vungoctan252(a)gmail.com> To: "Patil, Tushar" <Tushar.Patil(a)nttdata.com> Cc: Gaëtan Trellu <gaetan.trellu(a)incloudus.com>, "openstack-discuss(a)lists.openstack.org" <openstack-discuss(a)lists.openstack.org> Subject: Re: [masakari] how to install masakari on centos 7 Message-ID: <CACnQ=ZGFkWQ3G5rxYRCmqLQB-FvbaPutHXVb4AZrHCKp09LRsA(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi Patil, May I know how is it going ? On Tue, Jul 23, 2019 at 10:18 PM Vu Tan <vungoctan252(a)gmail.com> wrote: > Hi Patil, > Thank you for your reply, please instruct me if you successfully > install it. Thanks a lot > > On Tue, Jul 23, 2019 at 8:12 PM Patil, Tushar > <Tushar.Patil(a)nttdata.com> > wrote: > >> Hi Vu Tan, >> >> I'm trying to install Masakari using source code to reproduce the issue. >> If I hit the same issue as yours, I will troubleshoot this issue and >> let you know the solution or will update you what steps I have >> followed to bring up Masakari services successfully. >> >> Regards, >> Tushar Patil >> >> ________________________________________ >> From: Vu Tan <vungoctan252(a)gmail.com> >> Sent: Monday, July 22, 2019 12:33 PM >> To: Gaëtan Trellu >> Cc: Patil, Tushar; openstack-discuss(a)lists.openstack.org >> Subject: Re: [masakari] how to install masakari on centos 7 >> >> Hi Patil, >> May I know when the proper document for masakari is released ? I have >> configured conf file in controller and compute node, it seems running >> but it is not running as it should be, a lots of error in logs, here >> is a sample log: >> >> 2.7/site-packages/oslo_config/cfg.py:3024 >> 2019-07-19 10:25:26.360 7745 DEBUG oslo_service.service [-] bindir >> = /usr/local/bin log_opt_values /usr/lib/ >> python2.7/site-packages/oslo_config/cfg.py:3024 >> 2019-07-19 18:46:21.291 7770 ERROR masakari File >> "/usr/lib/python2.7/site-packages/oslo_service/service.py", line 65, >> in _is_daemo n >> 2019-07-19 18:46:21.291 7770 ERROR masakari is_daemon = os.getpgrp() >> != os.tcgetpgrp(sys.stdout.fileno()) >> 2019-07-19 18:46:21.291 7770 ERROR masakari OSError: [Errno 5] >> Input/output error >> 2019-07-19 18:46:21.291 7770 ERROR masakari >> 2019-07-19 18:46:21.300 7745 CRITICAL masakari [-] Unhandled error: >> OSError: [Errno 5] Input/output error >> 2019-07-19 18:46:21.300 7745 ERROR masakari Traceback (most recent >> call >> last): >> 2019-07-19 18:46:21.300 7745 ERROR masakari File >> "/usr/bin/masakari-api", line 10, in <module> >> >> I dont know if it is missing package or wrong configuration >> >> >> On Thu, Jul 11, 2019 at 6:14 PM Gaëtan Trellu < >> gaetan.trellu(a)incloudus.com<mailto:gaetan.trellu@incloudus.com>> wrote: >> You will have to enable the debit, debug = true and check the APi log. >> >> Did you try to use the openstack CLi ? >> >> Gaetan >> >> On Jul 11, 2019 12:32 AM, Vu Tan <vungoctan252(a)gmail.com<mailto: >> vungoctan252(a)gmail.com>> wrote: >> I know it's just a warning, just take a look at this image: >> [image.png] >> it's just hang there forever, and in the log show what I have shown >> to you >> >> On Wed, Jul 10, 2019 at 8:07 PM Gaëtan Trellu < >> gaetan.trellu(a)incloudus.com<mailto:gaetan.trellu@incloudus.com>> wrote: >> This is just a warning, not an error. >> >> On Jul 10, 2019 3:12 AM, Vu Tan <vungoctan252(a)gmail.com<mailto: >> vungoctan252(a)gmail.com>> wrote: >> Hi Gaetan, >> I follow you the guide you gave me, but the problem still persist, >> can you please take a look at my configuration to see what is wrong >> or what is missing in my config ? >> the error: >> 2019-07-10 14:08:46.876 17292 WARNING >> keystonemiddleware._common.config [-] The option "__file__" in conf >> is not known to auth_token >> 2019-07-10 14:08:46.876 17292 WARNING >> keystonemiddleware._common.config [-] The option "here" in conf is >> not known to auth_token >> 2019-07-10 14:08:46.882 17292 WARNING keystonemiddleware.auth_token >> [-] AuthToken middleware is set with keystone_authtoken.service_ >> >> the config: >> >> [DEFAULT] >> enabled_apis = masakari_api >> log_dir = /var/log/kolla/masakari >> state_path = /var/lib/masakari >> os_user_domain_name = default >> os_project_domain_name = default >> os_privileged_user_tenant = service >> os_privileged_user_auth_url = http://controller:5000/v3 >> os_privileged_user_name = nova os_privileged_user_password = P@ssword >> masakari_api_listen = controller masakari_api_listen_port = 15868 >> debug = False auth_strategy=keystone >> >> [wsgi] >> # The paste configuration file path >> api_paste_config = /etc/masakari/api-paste.ini >> >> [keystone_authtoken] >> www_authenticate_uri = http://controller:5000 auth_url = >> http://controller:5000 auth_type = password project_domain_id = >> default project_domain_name = default user_domain_name = default >> user_domain_id = default project_name = service username = masakari >> password = P@ssword region_name = RegionOne >> >> [oslo_middleware] >> enable_proxy_headers_parsing = True >> >> [database] >> connection = mysql+pymysql://masakari:P@ssword@controller/masakari >> >> >> >> On Tue, Jul 9, 2019 at 10:25 PM Vu Tan <vungoctan252(a)gmail.com<mailto: >> vungoctan252(a)gmail.com>> wrote: >> Thank Patil Tushar, I hope it will be available soon >> >> On Tue, Jul 9, 2019 at 8:18 AM Patil, Tushar >> <Tushar.Patil(a)nttdata.com <mailto:Tushar.Patil@nttdata.com>> wrote: >> Hi Vu and Gaetan, >> >> Gaetan, thank you for helping out Vu in setting up masakari-monitors >> service. >> >> As a masakari team ,we have noticed there is a need to add proper >> documentation to help the community run Masakari services in their >> environment. We are working on adding proper documentation in this 'Train' >> cycle. >> >> Will send an email on this mailing list once the patches are uploaded >> on the gerrit so that you can give your feedback on the same. >> >> If you have any trouble in setting up Masakari, please let us know on >> this mailing list or join the bi-weekly IRC Masakari meeting on the >> #openstack-meeting IRC channel. The next meeting will be held on 16th >> July >> 2019 @0400 UTC. >> >> Regards, >> Tushar Patil >> >> ________________________________________ >> From: Vu Tan <vungoctan252(a)gmail.com<mailto:vungoctan252@gmail.com>> >> Sent: Monday, July 8, 2019 11:21:16 PM >> To: Gaëtan Trellu >> Cc: openstack-discuss(a)lists.openstack.org<mailto: >> openstack-discuss(a)lists.openstack.org> >> Subject: Re: [masakari] how to install masakari on centos 7 >> >> Hi Gaetan, >> Thanks for pinpoint this out, silly me that did not notice the simple >> "error InterpreterNotFound: python3". Thanks a lot, I appreciate it >> >> On Mon, Jul 8, 2019 at 9:15 PM <gaetan.trellu(a)incloudus.com<mailto: >> gaetan.trellu(a)incloudus.com><mailto:gaetan.trellu@incloudus.com<mailto: >> gaetan.trellu(a)incloudus.com>>> wrote: >> Vu Tan, >> >> About "auth_token" error, you need "os_privileged_user_*" options >> into your masakari.conf for the API. >> As mentioned previously please have a look here to have an example of >> configuration working (for me at least): >> >> - masakari.conf: >> >> https://review.opendev.org/#/c/615715/42/ansible/roles/masakari/templ >> ates/masakari.conf.j2 >> - masakari-monitor.conf: >> >> https://review.opendev.org/#/c/615715/42/ansible/roles/masakari/templ >> ates/masakari-monitors.conf.j2 >> >> About your tox issue make sure you have Python3 installed. >> >> Gaëtan >> >> On 2019-07-08 06:08, Vu Tan wrote: >> >> > Hi Gaetan, >> > I try to generate config file by using this command tox -egenconfig >> > on top level of masakari but the output is error, is this masakari >> > still in beta version ? >> > [root@compute1 masakari-monitors]# tox -egenconfig genconfig >> > create: /root/masakari-monitors/.tox/genconfig >> > ERROR: InterpreterNotFound: python3 >> > _____________________________________________________________ >> > summary >> > ______________________________________________________________ >> > ERROR: genconfig: InterpreterNotFound: python3 >> > >> > On Mon, Jul 8, 2019 at 3:24 PM Vu Tan <vungoctan252(a)gmail.com<mailto: >> vungoctan252(a)gmail.com><mailto:vungoctan252@gmail.com<mailto: >> vungoctan252(a)gmail.com>>> wrote: >> > Hi, >> > Thanks a lot for your reply, I install pacemaker/corosync, >> > masakari-api, maskari-engine on controller node, and I run >> > masakari-api with this command: masakari-api, but I dont know >> > whether the process is running like that or is it just hang there, >> > here is what it shows when I run the command, I leave it there for >> > a while but it does not change anything : >> > [root@controller masakari]# masakari-api >> > 2019-07-08 15:21:09.946 30250 INFO masakari.api.openstack [-] >> > Loaded >> > extensions: ['extensions', 'notifications', 'os-hosts', 'segments', >> > 'versions'] >> > 2019-07-08 15:21:09.955 30250 WARNING >> > keystonemiddleware._common.config [-] The option "__file__" in conf >> > is not known to auth_token >> > 2019-07-08 15:21:09.955 30250 WARNING >> > keystonemiddleware._common.config [-] The option "here" in conf is >> > not known to auth_token >> > 2019-07-08 15:21:09.960 30250 WARNING keystonemiddleware.auth_token >> > [-] AuthToken middleware is set with >> > keystone_authtoken.service_token_roles_required set to False. This >> > is backwards compatible but deprecated behaviour. Please set this to True. >> > 2019-07-08 15:21:09.974 30250 INFO masakari.wsgi [-] masakari_api >> > listening on 127.0.0.1:15868<http://127.0.0.1:15868>< >> http://127.0.0.1:15868> >> > 2019-07-08 15:21:09.975 30250 INFO oslo_service.service [-] >> > Starting 4 workers >> > 2019-07-08 15:21:09.984 30274 INFO >> > masakari.masakari_api.wsgi.server [-] (30274) wsgi starting up on >> > http://127.0.0.1:15868 >> > 2019-07-08 15:21:09.985 30275 INFO >> > masakari.masakari_api.wsgi.server [-] (30275) wsgi starting up on >> > http://127.0.0.1:15868 >> > 2019-07-08 15:21:09.992 30277 INFO >> > masakari.masakari_api.wsgi.server [-] (30277) wsgi starting up on >> > http://127.0.0.1:15868 >> > 2019-07-08 15:21:09.994 30276 INFO >> > masakari.masakari_api.wsgi.server [-] (30276) wsgi starting up on >> > http://127.0.0.1:15868 >> > >> > On Sun, Jul 7, 2019 at 7:37 PM Gaëtan Trellu >> ><gaetan.trellu(a)incloudus.com<mailto:gaetan.trellu@incloudus.com >> ><mailto:gaetan.trellu@incloudus.com<mailto:gaetan.trellu@incloudus.c >> >om>>> >> wrote: >> > >> > Hi Vu Tan, >> > >> > Masakari documentation doesn't really exist... I had to figured >> > some stuff by myself to make it works into Kolla project. >> > >> > On controller nodes you need: >> > >> > - pacemaker >> > - corosync >> > - masakari-api (openstack/masakari repository) >> > - masakari- engine (openstack/masakari repository) >> > >> > On compute nodes you need: >> > >> > - pacemaker-remote (integrated to pacemaker cluster as a resource) >> > - masakari- hostmonitor (openstack/masakari-monitor repository) >> > - masakari-instancemonitor (openstack/masakari-monitor repository) >> > - masakari-processmonitor (openstack/masakari-monitor repository) >> > >> > For masakari-hostmonitor, the service needs to have access to >> > systemctl command (make sure you are not using sysvinit). >> > >> > For masakari-monitor, the masakari-monitor.conf is a bit different, >> > you will have to configure the [api] section properly. >> > >> > RabbitMQ needs to be configured (as transport_url) on masakari-api >> > and masakari-engine too. >> > >> > Please check this review[1], you will have masakari.conf and >> > masakari-monitor.conf configuration examples. >> > >> > [1] https://review.opendev.org/#/c/615715 >> > >> > Gaëtan >> > >> > On Jul 7, 2019 12:08 AM, Vu Tan <vungoctan252(a)gmail.com<mailto: >> vungoctan252(a)gmail.com><mailto:vungoctan252@gmail.com<mailto: >> vungoctan252(a)gmail.com>>> wrote: >> > >> > VU TAN <VUNGOCTAN252(a)GMAIL.COM<mailto:VUNGOCTAN252@GMAIL.COM><mailto: >> VUNGOCTAN252(a)GMAIL.COM<mailto:VUNGOCTAN252@GMAIL.COM>>> >> > >> > 10:30 AM (35 minutes ago) >> > >> > to openstack-discuss >> > >> > Sorry, I resend this email because I realized that I lacked of >> > prefix on this email's subject >> > >> > Hi, >> > >> > I would like to use Masakari and I'm having trouble finding a step >> > by step or other documentation to get started with. Which part >> > should be installed on controller, which is should be on compute, >> > and what is the prerequisite to install masakari, I have installed >> > corosync and pacemaker on compute and controller nodes, , what else >> > do I need to do ? step I have done so far: >> > - installed corosync/pacemaker >> > - install masakari on compute node on this github repo: >> > https://github.com/openstack/masakari >> > - add masakari in to mariadb >> > here is my configuration file of masakari.conf, do you mind to take >> > a look at it, if I have misconfigured anything? >> > >> > [DEFAULT] >> > enabled_apis = masakari_api >> > >> > # Enable to specify listening IP other than default >> > masakari_api_listen = controller # Enable to specify port other >> > than default masakari_api_listen_port = 15868 debug = False >> > auth_strategy=keystone >> > >> > [wsgi] >> > # The paste configuration file path api_paste_config = >> > /etc/masakari/api-paste.ini >> > >> > [keystone_authtoken] >> > www_authenticate_uri = http://controller:5000 auth_url = >> > http://controller:5000 auth_type = password project_domain_id = >> > default user_domain_id = default project_name = service username = >> > masakari password = P@ssword >> > >> > [database] >> > connection = mysql+pymysql://masakari:P@ssword@controller/masakari >> Disclaimer: This email and any attachments are sent in strictest >> confidence for the sole use of the addressee and may contain legally >> privileged, confidential, and proprietary data. If you are not the >> intended recipient, please advise the sender by replying promptly to >> this email and then delete and destroy this email and any attachments >> without any further use, copying or forwarding. >> >> >> Disclaimer: This email and any attachments are sent in strictest >> confidence for the sole use of the addressee and may contain legally >> privileged, confidential, and proprietary data. If you are not the >> intended recipient, please advise the sender by replying promptly to >> this email and then delete and destroy this email and any attachments >> without any further use, copying or forwarding. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190801…> ------------------------------ Subject: Digest Footer _______________________________________________ openstack-discuss mailing list openstack-discuss(a)lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss ------------------------------ End of openstack-discuss Digest, Vol 10, Issue 13 ************************************************* Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: detailed_steps_to_install_masakari.txt URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190819…> ------------------------------ Subject: Digest Footer _______________________________________________ openstack-discuss mailing list openstack-discuss(a)lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss ------------------------------ End of openstack-discuss Digest, Vol 10, Issue 95 ************************************************* Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding.

1 0

Re: [keystone][horizon] Integration with GuardianKey
by Paulo Angelo 20 Aug '19

20 Aug '19

> > > > 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 <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? > > Keystone would be the best place for this. Horizon is only one way a user > can log in to OpenStack, so hooking into Horizon would not cover your > attack vector. Keystone has a built-in auditing system specifically for > this, using CADF notifications to emit events when a user logs in: > > https://docs.openstack.org/keystone/latest/admin/event_notifications.html > > All you need to do is create a consumer for those notifications. > > Colleen > Thank you, Colleen, for your message. These days, I spent some time on it to understand better about the OpenStack events. As I could see, the authentication event does not have the user login name and other useful user information, such as e-mail. Is there a way to retrieve this information using the OpenStack resources? Or the best way is to access directly the database? Another question: We will need to deny the access if GuardianKey identifies a high attack risk. In this case, is there an easy way to drop a user session using the Keystone API or resources (and the information in the event)? Finally, you mentioned about the consumer. Is this a consumer for a RabbitMQ queue or an OpenStack API consumer? In the last case, is there example code for this? Thank you in advance. Regards, Paulo Angelo

1 0

Heat Template
by mesut aygün 19 Aug '19

19 Aug '19

Hi everyone; I am writing the template for cluster but i cant inject the cloud-init data. How can I inject the password data for vm? heat_template_version: 2014-10-16 new_instance: type: OS::Nova::Server properties: key_name: { get_param: key_name } image: { get_param: image_id } flavor: bir name: str_replace: template: master-$NONCE-dmind params: $NONCE: { get_resource: name_nonce } user_data: | #!/bin/bash #cloud-config password: 724365 echo "Running boot script" >> /home/ubuntu/test sudo sed -i "/^[^#]*PasswordAuthentication[[:space:]]no/c\PasswordAuthentication yes" /etc/ssh/sshd_config sudo useradd -d /home/mesut -m mesut sudo usermod --password 724365 ubuntu /etc/init.d/ssh restart

2 1

[neutron] Bug Deputy Report August 12-19
by Ryan Tidwell 19 Aug '19

19 Aug '19

Hello Neutron Team, Here is my bug deputy report for August 12 - August 19: Medium: -[OVS agent] Physical bridges can't be initialized if there is no connectivity to rabbitmq https://bugs.launchpad.net/neutron/+bug/1840443 The fix for this has been merged and a number of backports have merged as well. It appears to have been handled by the team. - excessive number of dvrs where vm got a fixed ip on floating network https://bugs.launchpad.net/bugs/1840579 https://review.opendev.org/#/c/677092/ has been proposed and is being worked on. This appears to be related to how we determine whether to instantiate a DVR local router on a compute node. It looks like there is a case where we create a local router when it's not necessary, thereby consuming too many IP's on the floating IP network at scale. Undecided: - network/subnet resources cannot be read and written separated https://bugs.launchpad.net/neutron/+bug/1840638 https://review.opendev.org/#/c/677166/ has been proposed. This was just reported just a few hours ago and still needs some triage to confirm severity of the issue. RFE's: - [RFE] Add new config option to enable IGMP snooping in ovs https://bugs.launchpad.net/bugs/1840136 Regards, Ryan Tidwell

1 0

[neutron] Bug Deputy Report August 12 - August 19
by Ryan Tidwell 19 Aug '19

19 Aug '19

Hello Neutron Team, Here is my bug deputy report for August 12 - August 19: Medium: -[OVS agent] Physical bridges can't be initialized if there is no connectivity to rabbitmq https://bugs.launchpad.net/neutron/+bug/1840443 The fix for this has been merged and a number of backports have merged as well. It appears to have been handled by the team. - excessive number of dvrs where vm got a fixed ip on floating network https://bugs.launchpad.net/bugs/1840579 https://review.opendev.org/#/c/677092/ has been proposed and is being worked on. This appears to be related to how we determine whether to instantiate a DVR local router on a compute node. It looks like there is a case where we create a local router when it's not necessary, thereby consuming too many IP's on the floating IP network at scale. Undecided: - network/subnet resources cannot be read and written separated https://bugs.launchpad.net/neutron/+bug/1840638 https://review.opendev.org/#/c/677166/ has been proposed. This was just reported just a few hours ago and still needs some triage to confirm severity of the issue. RFE's: - [RFE] Add new config option to enable IGMP snooping in ovs https://bugs.launchpad.net/neutron/+bug/1840136 Regards, Ryan Tidwell

1 0

[tc] weekly update
by Mohammed Naser 19 Aug '19

19 Aug '19

Hi everyone, Here’s the update for what happened in the OpenStack TC this week. You can get more information by checking for changes in openstack/governance repository. # Retired projects - Networking-generic-switch-tempest (from networking-generic-switch): https://review.opendev.org/#/c/674430/ # General changes - Michał Dulko as Kuryr PTL: https://review.opendev.org/#/c/674624/ - Added a mission to Swift taken from its wiki: https://review.opendev.org/#/c/675307/ - Sean McGinnis as release PTL: https://review.opendev.org/#/c/675246/ Thanks for tuning in! Regards, Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

2 1

RE: [masakari] pacemaker-remote Setup Overview
by Devharakar, Shilpa 19 Aug '19

19 Aug '19

Hi Ralf Teckelmann, Sorry resending by correcting subject with appropriate subject. > Hello, > > Utilizing openstack-ansible we successfully installed all the masakari services. Besides masakari-hostmonitor all are running fine. > For the hostmonitor a pacemaker cluster is missing. > > Can anyone give me an overview how the pacemaker cluster setup would look like? > Which (pacemaker) services is running where (compute nodes, something on any other node,...), etc? > > Best regards, > > Ralf Teckelmann Sorry for the late answer... Masakari team is in process of 'adding devstack support to install host-monitor', please refer community patch [1]. You can refer 'devstack/plugin.sh', please note it has IPMI Hardware support dependency. Also PFA 'detailed_steps_on_ubuntu_for_pacemaker_verification.txt' for verification of same carried out on Ubuntu distribution (installed openstack using devstack with Masakari enabled). [1]: https://review.opendev.org/#/c/671200/ Add devstack support to install host-monitor Thanks with Regards, Shilpa Shivaji Devharakar| Software Development Supervisor | NTT DATA Services| w. 91-020- 67095703 | Shilpa.Devharakar(a)nttdata.com | Learn more at nttdata.com/americas -----Original Message----- From: openstack-discuss-request(a)lists.openstack.org <openstack-discuss-request(a)lists.openstack.org> Sent: Monday, August 12, 2019 6:30 PM To: openstack-discuss(a)lists.openstack.org Subject: openstack-discuss Digest, Vol 10, Issue 59 Send openstack-discuss mailing list submissions to openstack-discuss(a)lists.openstack.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss or, via email, send a message with subject or body 'help' to openstack-discuss-request(a)lists.openstack.org You can reach the person managing the list at openstack-discuss-owner(a)lists.openstack.org When replying, please edit your Subject line so it is more specific than "Re: Contents of openstack-discuss digest..." Today's Topics: 1. Re: [tripleo][openstack-ansible] Integrating ansible-role-collect-logs in OSA (Arx Cruz) 2. [swauth][swift] Retiring swauth (Ondrej Novy) 3. [ironic] Resuming having weekly meetings (Julia Kreger) 4. [masakari] pacemaker-remote Setup Overview (Teckelmann, Ralf, NMU-OIP) ---------------------------------------------------------------------- Message: 1 Date: Mon, 12 Aug 2019 12:32:34 +0200 From: Arx Cruz <arxcruz(a)redhat.com> To: Jean-Philippe Evrard <jean-philippe(a)evrard.me> Cc: openstack-discuss(a)lists.openstack.org Subject: Re: [tripleo][openstack-ansible] Integrating ansible-role-collect-logs in OSA Message-ID: <CAB27Hy1tB0TjEwsvrgeBUF1NFCzDadE58-VR68Qt_=3RKY+fVw(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hello, I've started to split the logs collection tasks in small tasks [1] in order to allow other users to choose what exactly they want to collect. For example, if you don't need the openstack information, or if you don't care about networking, etc. Please take a look. I'll also add it on the OSA agenda for tomorrow's meeting. Kind regards, 1 - https://review.opendev.org/#/c/675858/ On Mon, Jul 22, 2019 at 8:44 AM Jean-Philippe Evrard < jean-philippe(a)evrard.me> wrote: > Sorry for the late answer... > > On Wed, 2019-07-10 at 12:12 -0600, Wesley Hayutin wrote: > > > > These are of course just passed in as extra-config. I think each > > project would want to define their own list of files and maintain it > > in their own project. WDYT? > > Looks good. We can either clean up the defaults, or OSA can just > override the defaults, and it would be good enough. I would say that > this can still be improved later, after OSA has started using the role > too. > > > It simple enough. But I am happy to see a different approach. > > Simple is good! > > > Any thoughts on additional work that I am not seeing? > > None :) > > > > > Thanks for responding! I know our team is very excited about the > > continued collaboration with other upstream projects, so thanks!! > > > > Likewise. Let's reduce tech debt/maintain more code together! > > Regards, > Jean-Philippe Evrard (evrardjp) > > > > > -- Arx Cruz Software Engineer Red Hat EMEA <https://www.redhat.com> arxcruz(a)redhat.com @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190812…> ------------------------------ Message: 2 Date: Mon, 12 Aug 2019 12:56:15 +0200 From: Ondrej Novy <novy(a)ondrej.org> To: openstack-discuss(a)lists.openstack.org Subject: [swauth][swift] Retiring swauth Message-ID: <CAOO6c=wgDZDRpQboo=_0qZ=fHrfu0rO0w=PaUat9bJduwFiVXw(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi, because swauth is not compatible with current Swift, doesn't support Python 3, I don't have time to maintain it and my employer is not interested in swauth, I'm going to retire swauth project. If nobody take over it, I will start removing swauth from opendev on 08/24. Thanks. -- Best regards Ondřej Nový -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190812…> ------------------------------ Message: 3 Date: Mon, 12 Aug 2019 07:55:07 -0400 From: Julia Kreger <juliaashleykreger(a)gmail.com> To: openstack-discuss <openstack-discuss(a)lists.openstack.org> Subject: [ironic] Resuming having weekly meetings Message-ID: <CAF7gwdhSWcUbYu0S2QfvjO44Q_5vJr6KTUQE3TRu3UYirqFGmQ(a)mail.gmail.com> Content-Type: text/plain; charset="UTF-8" All, I meant to send this specific email last week, but got distracted and $life. I believe we need to go back to having weekly meetings. The couple times I floated this in the past two weeks, there hasn't seemed to be any objections, but I also did not perceive any real thoughts on the subject. While the concept and use of office hours has seemingly helped bring some more activity to our IRC channel, we don't have a check-point/sync-up mechanism without an explicit meeting. With that being said, I'm going to start the meeting today and if we have quorum, try to proceed with it today. -Julia ------------------------------ Message: 4 Date: Mon, 12 Aug 2019 12:59:20 +0000 From: "Teckelmann, Ralf, NMU-OIP" <ralf.teckelmann(a)bertelsmann.de> To: "openstack-discuss(a)lists.openstack.org" <openstack-discuss(a)lists.openstack.org> Subject: [masakari] pacemaker-remote Setup Overview Message-ID: <AM6PR04MB47112DF6617442709662B43389D30(a)AM6PR04MB4711.eurprd04.prod.outlook.com> Content-Type: text/plain; charset="utf-8" Hello, Utilizing openstack-ansible we successfully installed all the masakari services. Besides masakari-hostmonitor all are running fine. For the hostmonitor a pacemaker cluster is missing. Can anyone give me an overview how the pacemaker cluster setup would look like? Which (pacemaker) services is running where (compute nodes, something on any other node,...), etc? Best regards, Ralf Teckelmann -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190812…> ------------------------------ Subject: Digest Footer _______________________________________________ openstack-discuss mailing list openstack-discuss(a)lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss ------------------------------ End of openstack-discuss Digest, Vol 10, Issue 59 ************************************************* Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding.

1 0

Re: [masakari] how to install masakari on centos 7 (Vu Tan)
by Devharakar, Shilpa 19 Aug '19

19 Aug '19

Hi Vu Tan, Sorry for late reply. Here are the steps we verified on Ubuntu Distribution, installed openstack via devstack. PFA 'detailed_steps_to_install_masakari.txt' Do not refer '/masakari/etc/Masakari.conf' sample file, instead generate it using 'tox -egenconfig' after 'git clone' > Hi Patil, > May I know how is it going ? > >> On Tue, Jul 23, 2019 at 10:18 PM Vu Tan <vungoctan252(a)gmail.com> wrote: >> >> Hi Patil, >> Thank you for your reply, please instruct me if you successfully >> install it. Thanks a lot >> >> On Tue, Jul 23, 2019 at 8:12 PM Patil, Tushar > > <Tushar.Patil(a)nttdata.com> >> wrote: >> >> Hi Vu Tan, >> >> I'm trying to install Masakari using source code to reproduce the issue. >> If I hit the same issue as yours, I will troubleshoot this issue and >> let you know the solution or will update you what steps I have >> followed to bring up Masakari services successfully. >> >> Regards, >> Tushar Patil >> >> ________________________________________ >> From: Vu Tan <vungoctan252(a)gmail.com> >> Sent: Monday, July 22, 2019 12:33 PM >> To: Gaëtan Trellu >> Cc: Patil, Tushar; openstack-discuss(a)lists.openstack.org >> Subject: Re: [masakari] how to install masakari on centos 7 >> >> Hi Patil, >> May I know when the proper document for masakari is released ? I have >> configured conf file in controller and compute node, it seems running >> but it is not running as it should be, a lots of error in logs, here >> is a sample log: >> >> 2.7/site-packages/oslo_config/cfg.py:3024 >> 2019-07-19 10:25:26.360 7745 DEBUG oslo_service.service [-] bindir >> = /usr/local/bin log_opt_values /usr/lib/ >> python2.7/site-packages/oslo_config/cfg.py:3024 >> 2019-07-19 18:46:21.291 7770 ERROR masakari File >> "/usr/lib/python2.7/site-packages/oslo_service/service.py", line 65, >> in _is_daemo n >> 2019-07-19 18:46:21.291 7770 ERROR masakari is_daemon = os.getpgrp() >> != os.tcgetpgrp(sys.stdout.fileno()) >> 2019-07-19 18:46:21.291 7770 ERROR masakari OSError: [Errno 5] >> Input/output error >> 2019-07-19 18:46:21.291 7770 ERROR masakari >> 2019-07-19 18:46:21.300 7745 CRITICAL masakari [-] Unhandled error: >> OSError: [Errno 5] Input/output error >> 2019-07-19 18:46:21.300 7745 ERROR masakari Traceback (most recent >> call >> last): >> 2019-07-19 18:46:21.300 7745 ERROR masakari File >> "/usr/bin/masakari-api", line 10, in <module> >> >> I dont know if it is missing package or wrong configuration >> >> >> On Thu, Jul 11, 2019 at 6:14 PM Gaëtan Trellu < >> gaetan.trellu(a)incloudus.com<mailto:gaetan.trellu@incloudus.com>> wrote: >> You will have to enable the debit, debug = true and check the APi log. >> >> Did you try to use the openstack CLi ? >> >> Gaetan >> >> On Jul 11, 2019 12:32 AM, Vu Tan <vungoctan252(a)gmail.com<mailto: >> vungoctan252(a)gmail.com>> wrote: >> I know it's just a warning, just take a look at this image: >> [image.png] >> it's just hang there forever, and in the log show what I have shown >> to you >> >> On Wed, Jul 10, 2019 at 8:07 PM Gaëtan Trellu < >> gaetan.trellu(a)incloudus.com<mailto:gaetan.trellu@incloudus.com>> wrote: >> This is just a warning, not an error. >> >> On Jul 10, 2019 3:12 AM, Vu Tan <vungoctan252(a)gmail.com<mailto: >> vungoctan252(a)gmail.com>> wrote: >> Hi Gaetan, >> I follow you the guide you gave me, but the problem still persist, >> can you please take a look at my configuration to see what is wrong >> or what is missing in my config ? >> the error: >> 2019-07-10 14:08:46.876 17292 WARNING >> keystonemiddleware._common.config [-] The option "__file__" in conf >> is not known to auth_token >> 2019-07-10 14:08:46.876 17292 WARNING >> keystonemiddleware._common.config [-] The option "here" in conf is >> not known to auth_token >> 2019-07-10 14:08:46.882 17292 WARNING keystonemiddleware.auth_token >> [-] AuthToken middleware is set with keystone_authtoken.service_ >> >> the config: >> >> [DEFAULT] >> enabled_apis = masakari_api >> log_dir = /var/log/kolla/masakari >> state_path = /var/lib/masakari >> os_user_domain_name = default >> os_project_domain_name = default >> os_privileged_user_tenant = service >> os_privileged_user_auth_url = http://controller:5000/v3 >> os_privileged_user_name = nova os_privileged_user_password = P@ssword >> masakari_api_listen = controller masakari_api_listen_port = 15868 >> debug = False auth_strategy=keystone >> >> [wsgi] >> # The paste configuration file path >> api_paste_config = /etc/masakari/api-paste.ini >> >> [keystone_authtoken] >> www_authenticate_uri = http://controller:5000 auth_url = >> http://controller:5000 auth_type = password project_domain_id = >> default project_domain_name = default user_domain_name = default >> user_domain_id = default project_name = service username = masakari >> password = P@ssword region_name = RegionOne >> >> [oslo_middleware] >> enable_proxy_headers_parsing = True >> >> [database] >> connection = mysql+pymysql://masakari:P@ssword@controller/masakari >> >> >> >> On Tue, Jul 9, 2019 at 10:25 PM Vu Tan <vungoctan252(a)gmail.com<mailto: >> vungoctan252(a)gmail.com>> wrote: >> Thank Patil Tushar, I hope it will be available soon >> >> On Tue, Jul 9, 2019 at 8:18 AM Patil, Tushar >> <Tushar.Patil(a)nttdata.com <mailto:Tushar.Patil@nttdata.com>> wrote: >> Hi Vu and Gaetan, >> >> Gaetan, thank you for helping out Vu in setting up masakari-monitors >> service. >> >> As a masakari team ,we have noticed there is a need to add proper >> documentation to help the community run Masakari services in their >> environment. We are working on adding proper documentation in this 'Train' >> cycle. >> >> Will send an email on this mailing list once the patches are uploaded >> on the gerrit so that you can give your feedback on the same. >> >> If you have any trouble in setting up Masakari, please let us know on >> this mailing list or join the bi-weekly IRC Masakari meeting on the >> #openstack-meeting IRC channel. The next meeting will be held on 16th >> July >> 2019 @0400 UTC. >> >> Regards, >> Tushar Patil >> >> ________________________________________ >> From: Vu Tan <vungoctan252(a)gmail.com<mailto:vungoctan252@gmail.com>> >> Sent: Monday, July 8, 2019 11:21:16 PM >> To: Gaëtan Trellu >> Cc: openstack-discuss(a)lists.openstack.org<mailto: >> openstack-discuss(a)lists.openstack.org> >> Subject: Re: [masakari] how to install masakari on centos 7 >> >> Hi Gaetan, >> Thanks for pinpoint this out, silly me that did not notice the simple >> "error InterpreterNotFound: python3". Thanks a lot, I appreciate it >> >> On Mon, Jul 8, 2019 at 9:15 PM <gaetan.trellu(a)incloudus.com<mailto: >> gaetan.trellu(a)incloudus.com><mailto:gaetan.trellu@incloudus.com<mailto: >> gaetan.trellu(a)incloudus.com>>> wrote: >> Vu Tan, >> >> About "auth_token" error, you need "os_privileged_user_*" options >> into your masakari.conf for the API. >> As mentioned previously please have a look here to have an example of >> configuration working (for me at least): >> >> - masakari.conf: >> >> https://review.opendev.org/#/c/615715/42/ansible/roles/masakari/templ >> ates/masakari.conf.j2 >> - masakari-monitor.conf: >> >> https://review.opendev.org/#/c/615715/42/ansible/roles/masakari/templ >> ates/masakari-monitors.conf.j2 >> >> About your tox issue make sure you have Python3 installed. >> >> Gaëtan >> >> On 2019-07-08 06:08, Vu Tan wrote: >> >> > Hi Gaetan, >> > I try to generate config file by using this command tox -egenconfig >> > on top level of masakari but the output is error, is this masakari >> > still in beta version ? >> > [root@compute1 masakari-monitors]# tox -egenconfig genconfig >> > create: /root/masakari-monitors/.tox/genconfig >> > ERROR: InterpreterNotFound: python3 >> > _____________________________________________________________ >> > summary >> > ______________________________________________________________ >> > ERROR: genconfig: InterpreterNotFound: python3 >> > >> > On Mon, Jul 8, 2019 at 3:24 PM Vu Tan <vungoctan252(a)gmail.com<mailto: >> vungoctan252(a)gmail.com><mailto:vungoctan252@gmail.com<mailto: >> vungoctan252(a)gmail.com>>> wrote: >> > Hi, >> > Thanks a lot for your reply, I install pacemaker/corosync, >> > masakari-api, maskari-engine on controller node, and I run >> > masakari-api with this command: masakari-api, but I dont know >> > whether the process is running like that or is it just hang there, >> > here is what it shows when I run the command, I leave it there for >> > a while but it does not change anything : >> > [root@controller masakari]# masakari-api >> > 2019-07-08 15:21:09.946 30250 INFO masakari.api.openstack [-] >> > Loaded >> > extensions: ['extensions', 'notifications', 'os-hosts', 'segments', >> > 'versions'] >> > 2019-07-08 15:21:09.955 30250 WARNING >> > keystonemiddleware._common.config [-] The option "__file__" in conf >> > is not known to auth_token >> > 2019-07-08 15:21:09.955 30250 WARNING >> > keystonemiddleware._common.config [-] The option "here" in conf is >> > not known to auth_token >> > 2019-07-08 15:21:09.960 30250 WARNING keystonemiddleware.auth_token >> > [-] AuthToken middleware is set with >> > keystone_authtoken.service_token_roles_required set to False. This >> > is backwards compatible but deprecated behaviour. Please set this to True. >> > 2019-07-08 15:21:09.974 30250 INFO masakari.wsgi [-] masakari_api >> > listening on 127.0.0.1:15868<http://127.0.0.1:15868>< >> http://127.0.0.1:15868> >> > 2019-07-08 15:21:09.975 30250 INFO oslo_service.service [-] >> > Starting 4 workers >> > 2019-07-08 15:21:09.984 30274 INFO >> > masakari.masakari_api.wsgi.server [-] (30274) wsgi starting up on >> > http://127.0.0.1:15868 >> > 2019-07-08 15:21:09.985 30275 INFO >> > masakari.masakari_api.wsgi.server [-] (30275) wsgi starting up on >> > http://127.0.0.1:15868 >> > 2019-07-08 15:21:09.992 30277 INFO >> > masakari.masakari_api.wsgi.server [-] (30277) wsgi starting up on >> > http://127.0.0.1:15868 >> > 2019-07-08 15:21:09.994 30276 INFO >> > masakari.masakari_api.wsgi.server [-] (30276) wsgi starting up on >> > http://127.0.0.1:15868 >> > >> > On Sun, Jul 7, 2019 at 7:37 PM Gaëtan Trellu >> ><gaetan.trellu(a)incloudus.com<mailto:gaetan.trellu@incloudus.com >> ><mailto:gaetan.trellu@incloudus.com<mailto:gaetan.trellu@incloudus.c >> >om>>> >> wrote: >> > >> > Hi Vu Tan, >> > >> > Masakari documentation doesn't really exist... I had to figured >> > some stuff by myself to make it works into Kolla project. >> > >> > On controller nodes you need: >> > >> > - pacemaker >> > - corosync >> > - masakari-api (openstack/masakari repository) >> > - masakari- engine (openstack/masakari repository) >> > >> > On compute nodes you need: >> > >> > - pacemaker-remote (integrated to pacemaker cluster as a resource) >> > - masakari- hostmonitor (openstack/masakari-monitor repository) >> > - masakari-instancemonitor (openstack/masakari-monitor repository) >> > - masakari-processmonitor (openstack/masakari-monitor repository) >> > >> > For masakari-hostmonitor, the service needs to have access to >> > systemctl command (make sure you are not using sysvinit). >> > >> > For masakari-monitor, the masakari-monitor.conf is a bit different, >> > you will have to configure the [api] section properly. >> > >> > RabbitMQ needs to be configured (as transport_url) on masakari-api >> > and masakari-engine too. >> > >> > Please check this review[1], you will have masakari.conf and >> > masakari-monitor.conf configuration examples. >> > >> > [1] https://review.opendev.org/#/c/615715 >> > >> > Gaëtan >> > >> > On Jul 7, 2019 12:08 AM, Vu Tan <vungoctan252(a)gmail.com<mailto: >> vungoctan252(a)gmail.com><mailto:vungoctan252@gmail.com<mailto: >> vungoctan252(a)gmail.com>>> wrote: >> > >> > VU TAN <VUNGOCTAN252(a)GMAIL.COM<mailto:VUNGOCTAN252@GMAIL.COM><mailto: >> VUNGOCTAN252(a)GMAIL.COM<mailto:VUNGOCTAN252@GMAIL.COM>>> >> > >> > 10:30 AM (35 minutes ago) >> > >> > to openstack-discuss >> > >> > Sorry, I resend this email because I realized that I lacked of >> > prefix on this email's subject >> > >> > Hi, >> > >> > I would like to use Masakari and I'm having trouble finding a step >> > by step or other documentation to get started with. Which part >> > should be installed on controller, which is should be on compute, >> > and what is the prerequisite to install masakari, I have installed >> > corosync and pacemaker on compute and controller nodes, , what else >> > do I need to do ? step I have done so far: >> > - installed corosync/pacemaker >> > - install masakari on compute node on this github repo: >> > https://github.com/openstack/masakari >> > - add masakari in to mariadb >> > here is my configuration file of masakari.conf, do you mind to take >> > a look at it, if I have misconfigured anything? >> > >> > [DEFAULT] >> > enabled_apis = masakari_api >> > >> > # Enable to specify listening IP other than default >> > masakari_api_listen = controller # Enable to specify port other >> > than default masakari_api_listen_port = 15868 debug = False >> > auth_strategy=keystone >> > >> > [wsgi] >> > # The paste configuration file path api_paste_config = >> > /etc/masakari/api-paste.ini >> > >> > [keystone_authtoken] >> > www_authenticate_uri = http://controller:5000 auth_url = >> > http://controller:5000 auth_type = password project_domain_id = >> > default user_domain_id = default project_name = service username = >> > masakari password = P@ssword >> > >> > [database] >> > connection = mysql+pymysql://masakari:P@ssword@controller/masakari >> Disclaimer: This email and any attachments are sent in strictest >> confidence for the sole use of the addressee and may contain legally >> privileged, confidential, and proprietary data. If you are not the >> intended recipient, please advise the sender by replying promptly to >> this email and then delete and destroy this email and any attachments >> without any further use, copying or forwarding. >> >> >> Disclaimer: This email and any attachments are sent in strictest >> confidence for the sole use of the addressee and may contain legally >> privileged, confidential, and proprietary data. If you are not the >> intended recipient, please advise the sender by replying promptly to >> this email and then delete and destroy this email and any attachments >> without any further use, copying or forwarding. >> > Thanks with Regards, Shilpa Shivaji Devharakar| Software Development Supervisor | NTT DATA Services| w. 91-020- 67095703 | Shilpa.Devharakar(a)nttdata.com | Learn more at nttdata.com/americas -----Original Message----- From: openstack-discuss-request(a)lists.openstack.org <openstack-discuss-request(a)lists.openstack.org> Sent: Sunday, August 4, 2019 12:42 AM To: openstack-discuss(a)lists.openstack.org Subject: openstack-discuss Digest, Vol 10, Issue 13 Send openstack-discuss mailing list submissions to openstack-discuss(a)lists.openstack.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss or, via email, send a message with subject or body 'help' to openstack-discuss-request(a)lists.openstack.org You can reach the person managing the list at openstack-discuss-owner(a)lists.openstack.org When replying, please edit your Subject line so it is more specific than "Re: Contents of openstack-discuss digest..." Today's Topics: 1. Re: [nova][ops] Documenting nova tunables at scale (Joe Robinson) 2. Re: [masakari] how to install masakari on centos 7 (Vu Tan) ---------------------------------------------------------------------- Message: 1 Date: Sat, 3 Aug 2019 10:40:11 +1000 From: Joe Robinson <joseph.r.email(a)gmail.com> To: Matt Riedemann <mriedemos(a)gmail.com> Cc: openstack-discuss(a)lists.openstack.org Subject: Re: [nova][ops] Documenting nova tunables at scale Message-ID: <CAOvR4Gx1K+7+Thyz-qv57D-vNx-OZQFtxhxk+X6hCQT3QiGpug(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi Matt, My name is Joe - docs person from years back - this looks like a good initiative and I would be up for documenting these settings at scale. Next step I can see is gathering more Info about this pain point (already started :)) and then I can draft something together for feedback. On Sat, 3 Aug. 2019, 6:25 am Matt Riedemann, <mriedemos(a)gmail.com> wrote: > I wanted to send this to get other people's feedback if they have > particular nova configurations once they hit a certain scale (hundreds > or thousands of nodes). Every once in awhile in IRC I'll be chatting > with someone about configuration changes they've made running at large > scale to avoid, for example, hammering the control plane. I don't know > how many times I've thought, "it would be nice if we had a doc > highlighting some of these things so a new operator could come along > and see, oh I've never tried changing that value before". > > I haven't started that doc, but I've started a bug report for people > to dump some of their settings. The most common ones could go into a > simple admin doc to start. > > I know there is more I've thought about in the past that I don't have > in here but this is just a starting point so I don't make the mistake > of not taking action on this again. > > https://bugs.launchpad.net/nova/+bug/1838819 > > -- > > Thanks, > > Matt > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190803…> ------------------------------ Message: 2 Date: Thu, 1 Aug 2019 11:43:13 +0700 From: Vu Tan <vungoctan252(a)gmail.com> To: "Patil, Tushar" <Tushar.Patil(a)nttdata.com> Cc: Gaëtan Trellu <gaetan.trellu(a)incloudus.com>, "openstack-discuss(a)lists.openstack.org" <openstack-discuss(a)lists.openstack.org> Subject: Re: [masakari] how to install masakari on centos 7 Message-ID: <CACnQ=ZGFkWQ3G5rxYRCmqLQB-FvbaPutHXVb4AZrHCKp09LRsA(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi Patil, May I know how is it going ? On Tue, Jul 23, 2019 at 10:18 PM Vu Tan <vungoctan252(a)gmail.com> wrote: > Hi Patil, > Thank you for your reply, please instruct me if you successfully > install it. Thanks a lot > > On Tue, Jul 23, 2019 at 8:12 PM Patil, Tushar > <Tushar.Patil(a)nttdata.com> > wrote: > >> Hi Vu Tan, >> >> I'm trying to install Masakari using source code to reproduce the issue. >> If I hit the same issue as yours, I will troubleshoot this issue and >> let you know the solution or will update you what steps I have >> followed to bring up Masakari services successfully. >> >> Regards, >> Tushar Patil >> >> ________________________________________ >> From: Vu Tan <vungoctan252(a)gmail.com> >> Sent: Monday, July 22, 2019 12:33 PM >> To: Gaëtan Trellu >> Cc: Patil, Tushar; openstack-discuss(a)lists.openstack.org >> Subject: Re: [masakari] how to install masakari on centos 7 >> >> Hi Patil, >> May I know when the proper document for masakari is released ? I have >> configured conf file in controller and compute node, it seems running >> but it is not running as it should be, a lots of error in logs, here >> is a sample log: >> >> 2.7/site-packages/oslo_config/cfg.py:3024 >> 2019-07-19 10:25:26.360 7745 DEBUG oslo_service.service [-] bindir >> = /usr/local/bin log_opt_values /usr/lib/ >> python2.7/site-packages/oslo_config/cfg.py:3024 >> 2019-07-19 18:46:21.291 7770 ERROR masakari File >> "/usr/lib/python2.7/site-packages/oslo_service/service.py", line 65, >> in _is_daemo n >> 2019-07-19 18:46:21.291 7770 ERROR masakari is_daemon = os.getpgrp() >> != os.tcgetpgrp(sys.stdout.fileno()) >> 2019-07-19 18:46:21.291 7770 ERROR masakari OSError: [Errno 5] >> Input/output error >> 2019-07-19 18:46:21.291 7770 ERROR masakari >> 2019-07-19 18:46:21.300 7745 CRITICAL masakari [-] Unhandled error: >> OSError: [Errno 5] Input/output error >> 2019-07-19 18:46:21.300 7745 ERROR masakari Traceback (most recent >> call >> last): >> 2019-07-19 18:46:21.300 7745 ERROR masakari File >> "/usr/bin/masakari-api", line 10, in <module> >> >> I dont know if it is missing package or wrong configuration >> >> >> On Thu, Jul 11, 2019 at 6:14 PM Gaëtan Trellu < >> gaetan.trellu(a)incloudus.com<mailto:gaetan.trellu@incloudus.com>> wrote: >> You will have to enable the debit, debug = true and check the APi log. >> >> Did you try to use the openstack CLi ? >> >> Gaetan >> >> On Jul 11, 2019 12:32 AM, Vu Tan <vungoctan252(a)gmail.com<mailto: >> vungoctan252(a)gmail.com>> wrote: >> I know it's just a warning, just take a look at this image: >> [image.png] >> it's just hang there forever, and in the log show what I have shown >> to you >> >> On Wed, Jul 10, 2019 at 8:07 PM Gaëtan Trellu < >> gaetan.trellu(a)incloudus.com<mailto:gaetan.trellu@incloudus.com>> wrote: >> This is just a warning, not an error. >> >> On Jul 10, 2019 3:12 AM, Vu Tan <vungoctan252(a)gmail.com<mailto: >> vungoctan252(a)gmail.com>> wrote: >> Hi Gaetan, >> I follow you the guide you gave me, but the problem still persist, >> can you please take a look at my configuration to see what is wrong >> or what is missing in my config ? >> the error: >> 2019-07-10 14:08:46.876 17292 WARNING >> keystonemiddleware._common.config [-] The option "__file__" in conf >> is not known to auth_token >> 2019-07-10 14:08:46.876 17292 WARNING >> keystonemiddleware._common.config [-] The option "here" in conf is >> not known to auth_token >> 2019-07-10 14:08:46.882 17292 WARNING keystonemiddleware.auth_token >> [-] AuthToken middleware is set with keystone_authtoken.service_ >> >> the config: >> >> [DEFAULT] >> enabled_apis = masakari_api >> log_dir = /var/log/kolla/masakari >> state_path = /var/lib/masakari >> os_user_domain_name = default >> os_project_domain_name = default >> os_privileged_user_tenant = service >> os_privileged_user_auth_url = http://controller:5000/v3 >> os_privileged_user_name = nova os_privileged_user_password = P@ssword >> masakari_api_listen = controller masakari_api_listen_port = 15868 >> debug = False auth_strategy=keystone >> >> [wsgi] >> # The paste configuration file path >> api_paste_config = /etc/masakari/api-paste.ini >> >> [keystone_authtoken] >> www_authenticate_uri = http://controller:5000 auth_url = >> http://controller:5000 auth_type = password project_domain_id = >> default project_domain_name = default user_domain_name = default >> user_domain_id = default project_name = service username = masakari >> password = P@ssword region_name = RegionOne >> >> [oslo_middleware] >> enable_proxy_headers_parsing = True >> >> [database] >> connection = mysql+pymysql://masakari:P@ssword@controller/masakari >> >> >> >> On Tue, Jul 9, 2019 at 10:25 PM Vu Tan <vungoctan252(a)gmail.com<mailto: >> vungoctan252(a)gmail.com>> wrote: >> Thank Patil Tushar, I hope it will be available soon >> >> On Tue, Jul 9, 2019 at 8:18 AM Patil, Tushar >> <Tushar.Patil(a)nttdata.com <mailto:Tushar.Patil@nttdata.com>> wrote: >> Hi Vu and Gaetan, >> >> Gaetan, thank you for helping out Vu in setting up masakari-monitors >> service. >> >> As a masakari team ,we have noticed there is a need to add proper >> documentation to help the community run Masakari services in their >> environment. We are working on adding proper documentation in this 'Train' >> cycle. >> >> Will send an email on this mailing list once the patches are uploaded >> on the gerrit so that you can give your feedback on the same. >> >> If you have any trouble in setting up Masakari, please let us know on >> this mailing list or join the bi-weekly IRC Masakari meeting on the >> #openstack-meeting IRC channel. The next meeting will be held on 16th >> July >> 2019 @0400 UTC. >> >> Regards, >> Tushar Patil >> >> ________________________________________ >> From: Vu Tan <vungoctan252(a)gmail.com<mailto:vungoctan252@gmail.com>> >> Sent: Monday, July 8, 2019 11:21:16 PM >> To: Gaëtan Trellu >> Cc: openstack-discuss(a)lists.openstack.org<mailto: >> openstack-discuss(a)lists.openstack.org> >> Subject: Re: [masakari] how to install masakari on centos 7 >> >> Hi Gaetan, >> Thanks for pinpoint this out, silly me that did not notice the simple >> "error InterpreterNotFound: python3". Thanks a lot, I appreciate it >> >> On Mon, Jul 8, 2019 at 9:15 PM <gaetan.trellu(a)incloudus.com<mailto: >> gaetan.trellu(a)incloudus.com><mailto:gaetan.trellu@incloudus.com<mailto: >> gaetan.trellu(a)incloudus.com>>> wrote: >> Vu Tan, >> >> About "auth_token" error, you need "os_privileged_user_*" options >> into your masakari.conf for the API. >> As mentioned previously please have a look here to have an example of >> configuration working (for me at least): >> >> - masakari.conf: >> >> https://review.opendev.org/#/c/615715/42/ansible/roles/masakari/templ >> ates/masakari.conf.j2 >> - masakari-monitor.conf: >> >> https://review.opendev.org/#/c/615715/42/ansible/roles/masakari/templ >> ates/masakari-monitors.conf.j2 >> >> About your tox issue make sure you have Python3 installed. >> >> Gaëtan >> >> On 2019-07-08 06:08, Vu Tan wrote: >> >> > Hi Gaetan, >> > I try to generate config file by using this command tox -egenconfig >> > on top level of masakari but the output is error, is this masakari >> > still in beta version ? >> > [root@compute1 masakari-monitors]# tox -egenconfig genconfig >> > create: /root/masakari-monitors/.tox/genconfig >> > ERROR: InterpreterNotFound: python3 >> > _____________________________________________________________ >> > summary >> > ______________________________________________________________ >> > ERROR: genconfig: InterpreterNotFound: python3 >> > >> > On Mon, Jul 8, 2019 at 3:24 PM Vu Tan <vungoctan252(a)gmail.com<mailto: >> vungoctan252(a)gmail.com><mailto:vungoctan252@gmail.com<mailto: >> vungoctan252(a)gmail.com>>> wrote: >> > Hi, >> > Thanks a lot for your reply, I install pacemaker/corosync, >> > masakari-api, maskari-engine on controller node, and I run >> > masakari-api with this command: masakari-api, but I dont know >> > whether the process is running like that or is it just hang there, >> > here is what it shows when I run the command, I leave it there for >> > a while but it does not change anything : >> > [root@controller masakari]# masakari-api >> > 2019-07-08 15:21:09.946 30250 INFO masakari.api.openstack [-] >> > Loaded >> > extensions: ['extensions', 'notifications', 'os-hosts', 'segments', >> > 'versions'] >> > 2019-07-08 15:21:09.955 30250 WARNING >> > keystonemiddleware._common.config [-] The option "__file__" in conf >> > is not known to auth_token >> > 2019-07-08 15:21:09.955 30250 WARNING >> > keystonemiddleware._common.config [-] The option "here" in conf is >> > not known to auth_token >> > 2019-07-08 15:21:09.960 30250 WARNING keystonemiddleware.auth_token >> > [-] AuthToken middleware is set with >> > keystone_authtoken.service_token_roles_required set to False. This >> > is backwards compatible but deprecated behaviour. Please set this to True. >> > 2019-07-08 15:21:09.974 30250 INFO masakari.wsgi [-] masakari_api >> > listening on 127.0.0.1:15868<http://127.0.0.1:15868>< >> http://127.0.0.1:15868> >> > 2019-07-08 15:21:09.975 30250 INFO oslo_service.service [-] >> > Starting 4 workers >> > 2019-07-08 15:21:09.984 30274 INFO >> > masakari.masakari_api.wsgi.server [-] (30274) wsgi starting up on >> > http://127.0.0.1:15868 >> > 2019-07-08 15:21:09.985 30275 INFO >> > masakari.masakari_api.wsgi.server [-] (30275) wsgi starting up on >> > http://127.0.0.1:15868 >> > 2019-07-08 15:21:09.992 30277 INFO >> > masakari.masakari_api.wsgi.server [-] (30277) wsgi starting up on >> > http://127.0.0.1:15868 >> > 2019-07-08 15:21:09.994 30276 INFO >> > masakari.masakari_api.wsgi.server [-] (30276) wsgi starting up on >> > http://127.0.0.1:15868 >> > >> > On Sun, Jul 7, 2019 at 7:37 PM Gaëtan Trellu >> ><gaetan.trellu(a)incloudus.com<mailto:gaetan.trellu@incloudus.com >> ><mailto:gaetan.trellu@incloudus.com<mailto:gaetan.trellu@incloudus.c >> >om>>> >> wrote: >> > >> > Hi Vu Tan, >> > >> > Masakari documentation doesn't really exist... I had to figured >> > some stuff by myself to make it works into Kolla project. >> > >> > On controller nodes you need: >> > >> > - pacemaker >> > - corosync >> > - masakari-api (openstack/masakari repository) >> > - masakari- engine (openstack/masakari repository) >> > >> > On compute nodes you need: >> > >> > - pacemaker-remote (integrated to pacemaker cluster as a resource) >> > - masakari- hostmonitor (openstack/masakari-monitor repository) >> > - masakari-instancemonitor (openstack/masakari-monitor repository) >> > - masakari-processmonitor (openstack/masakari-monitor repository) >> > >> > For masakari-hostmonitor, the service needs to have access to >> > systemctl command (make sure you are not using sysvinit). >> > >> > For masakari-monitor, the masakari-monitor.conf is a bit different, >> > you will have to configure the [api] section properly. >> > >> > RabbitMQ needs to be configured (as transport_url) on masakari-api >> > and masakari-engine too. >> > >> > Please check this review[1], you will have masakari.conf and >> > masakari-monitor.conf configuration examples. >> > >> > [1] https://review.opendev.org/#/c/615715 >> > >> > Gaëtan >> > >> > On Jul 7, 2019 12:08 AM, Vu Tan <vungoctan252(a)gmail.com<mailto: >> vungoctan252(a)gmail.com><mailto:vungoctan252@gmail.com<mailto: >> vungoctan252(a)gmail.com>>> wrote: >> > >> > VU TAN <VUNGOCTAN252(a)GMAIL.COM<mailto:VUNGOCTAN252@GMAIL.COM><mailto: >> VUNGOCTAN252(a)GMAIL.COM<mailto:VUNGOCTAN252@GMAIL.COM>>> >> > >> > 10:30 AM (35 minutes ago) >> > >> > to openstack-discuss >> > >> > Sorry, I resend this email because I realized that I lacked of >> > prefix on this email's subject >> > >> > Hi, >> > >> > I would like to use Masakari and I'm having trouble finding a step >> > by step or other documentation to get started with. Which part >> > should be installed on controller, which is should be on compute, >> > and what is the prerequisite to install masakari, I have installed >> > corosync and pacemaker on compute and controller nodes, , what else >> > do I need to do ? step I have done so far: >> > - installed corosync/pacemaker >> > - install masakari on compute node on this github repo: >> > https://github.com/openstack/masakari >> > - add masakari in to mariadb >> > here is my configuration file of masakari.conf, do you mind to take >> > a look at it, if I have misconfigured anything? >> > >> > [DEFAULT] >> > enabled_apis = masakari_api >> > >> > # Enable to specify listening IP other than default >> > masakari_api_listen = controller # Enable to specify port other >> > than default masakari_api_listen_port = 15868 debug = False >> > auth_strategy=keystone >> > >> > [wsgi] >> > # The paste configuration file path api_paste_config = >> > /etc/masakari/api-paste.ini >> > >> > [keystone_authtoken] >> > www_authenticate_uri = http://controller:5000 auth_url = >> > http://controller:5000 auth_type = password project_domain_id = >> > default user_domain_id = default project_name = service username = >> > masakari password = P@ssword >> > >> > [database] >> > connection = mysql+pymysql://masakari:P@ssword@controller/masakari >> Disclaimer: This email and any attachments are sent in strictest >> confidence for the sole use of the addressee and may contain legally >> privileged, confidential, and proprietary data. If you are not the >> intended recipient, please advise the sender by replying promptly to >> this email and then delete and destroy this email and any attachments >> without any further use, copying or forwarding. >> >> >> Disclaimer: This email and any attachments are sent in strictest >> confidence for the sole use of the addressee and may contain legally >> privileged, confidential, and proprietary data. If you are not the >> intended recipient, please advise the sender by replying promptly to >> this email and then delete and destroy this email and any attachments >> without any further use, copying or forwarding. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190801…> ------------------------------ Subject: Digest Footer _______________________________________________ openstack-discuss mailing list openstack-discuss(a)lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss ------------------------------ End of openstack-discuss Digest, Vol 10, Issue 13 ************************************************* Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding.

1 0

[neutron] Bug Deputy Report August 12 - August 19
by Ryan Tidwell 19 Aug '19

19 Aug '19

Hello Neutron Team, Here is my bug deputy report for August 12 - August 19: Medium: -[OVS agent] Physical bridges can't be initialized if there is no connectivity to rabbitmq https://bugs.launchpad.net/neutron/+bug/1840443 The fix for this has been merged and a number of backports have merged as well. It appears to have been handled by the team. - excessive number of dvrs where vm got a fixed ip on floating network https://bugs.launchpad.net/bugs/1840579 https://review.opendev.org/#/c/677092/ has been proposed and is being worked on. This appears to be related to how we determine whether to instantiate a DVR local router on a compute node. It looks like there is a case where we create a local router when it's not necessary, thereby consuming too many IP's on the floating IP network at scale. Undecided: - network/subnet resources cannot be read and written separated https://bugs.launchpad.net/neutron/+bug/1840638 https://review.opendev.org/#/c/677166/ has been proposed. This was just reported just a few hours ago and still needs some triage to confirm severity of the issue. RFE's: - [RFE] Add new config option to enable IGMP snooping in ovs https://bugs.launchpad.net/bugs/1840136 Regards, Ryan Tidwell

1 0

[cyborg] [nova] [placement] Shelve/unshelve behavior
by Nadathur, Sundar 19 Aug '19

19 Aug '19

Hi, I tested various instance operations using the Nova patch series for Cyborg integration [1]. Many of them worked as expected: pause/unpause, lock/unlock, rescue/unrescue, etc. That is, the application in the VM can successfully offload to the accelerator device before and after the sequence. Suspend fails with the Libvirt error: "Domain has assigned non-USB devices." I think this is known behavior. But, shelve/shelve-offloaded/unshelve sequence shows two discrepancies: * After shelve, the instance is shut off in Libvirt but is shown as ACTIVE in 'openstack server list'. * After unshelve, the PCI VF gets re-attached on VM startup and the application inside the VM can access the accelerator device. However, 'openstack resource provider usage show <rp-uuid>' shows the RC usage as 0, i.e., there seems to be no claim in Placement for the resource in use. After shelve, the instance transitions to 'shelve-offloaded' automatically after the configured time interval. The resource class usage is 0. This part is good. But, after the unshelve, one would think the usage would be bumped up automatically. P.S.: Still investigating hard reboots and start/stop operations. [1] https://review.opendev.org/#/q/status:open+project:openstack/nova+bp/nova-c… Regards, Sundar

2 1

RE: openstack-discuss Digest, Vol 10, Issue 59
by Devharakar, Shilpa 19 Aug '19

19 Aug '19

Hi Ralf Teckelmann, > Hello, > > Utilizing openstack-ansible we successfully installed all the masakari services. Besides masakari-hostmonitor all are running fine. > For the hostmonitor a pacemaker cluster is missing. > > Can anyone give me an overview how the pacemaker cluster setup would look like? > Which (pacemaker) services is running where (compute nodes, something on any other node,...), etc? > > Best regards, > > Ralf Teckelmann Sorry for the late answer... Masakari team is in process of 'adding devstack support to install host-monitor', please refer community patch [1]. You can refer 'devstack/plugin.sh', please note it has IPMI Hardware support dependency. Also PFA 'detailed_steps_on_ubuntu_for_pacemaker_verification.txt' for verification of same carried out on Ubuntu distribution (installed openstack using devstack with Masakari enabled). [1]: https://review.opendev.org/#/c/671200/ Add devstack support to install host-monitor Thanks with Regards, Shilpa Shivaji Devharakar| Software Development Supervisor | NTT DATA Services| w. 91-020- 67095703 | Shilpa.Devharakar(a)nttdata.com | Learn more at nttdata.com/americas -----Original Message----- From: openstack-discuss-request(a)lists.openstack.org <openstack-discuss-request(a)lists.openstack.org> Sent: Monday, August 12, 2019 6:30 PM To: openstack-discuss(a)lists.openstack.org Subject: openstack-discuss Digest, Vol 10, Issue 59 Send openstack-discuss mailing list submissions to openstack-discuss(a)lists.openstack.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss or, via email, send a message with subject or body 'help' to openstack-discuss-request(a)lists.openstack.org You can reach the person managing the list at openstack-discuss-owner(a)lists.openstack.org When replying, please edit your Subject line so it is more specific than "Re: Contents of openstack-discuss digest..." Today's Topics: 1. Re: [tripleo][openstack-ansible] Integrating ansible-role-collect-logs in OSA (Arx Cruz) 2. [swauth][swift] Retiring swauth (Ondrej Novy) 3. [ironic] Resuming having weekly meetings (Julia Kreger) 4. [masakari] pacemaker-remote Setup Overview (Teckelmann, Ralf, NMU-OIP) ---------------------------------------------------------------------- Message: 1 Date: Mon, 12 Aug 2019 12:32:34 +0200 From: Arx Cruz <arxcruz(a)redhat.com> To: Jean-Philippe Evrard <jean-philippe(a)evrard.me> Cc: openstack-discuss(a)lists.openstack.org Subject: Re: [tripleo][openstack-ansible] Integrating ansible-role-collect-logs in OSA Message-ID: <CAB27Hy1tB0TjEwsvrgeBUF1NFCzDadE58-VR68Qt_=3RKY+fVw(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hello, I've started to split the logs collection tasks in small tasks [1] in order to allow other users to choose what exactly they want to collect. For example, if you don't need the openstack information, or if you don't care about networking, etc. Please take a look. I'll also add it on the OSA agenda for tomorrow's meeting. Kind regards, 1 - https://review.opendev.org/#/c/675858/ On Mon, Jul 22, 2019 at 8:44 AM Jean-Philippe Evrard < jean-philippe(a)evrard.me> wrote: > Sorry for the late answer... > > On Wed, 2019-07-10 at 12:12 -0600, Wesley Hayutin wrote: > > > > These are of course just passed in as extra-config. I think each > > project would want to define their own list of files and maintain it > > in their own project. WDYT? > > Looks good. We can either clean up the defaults, or OSA can just > override the defaults, and it would be good enough. I would say that > this can still be improved later, after OSA has started using the role > too. > > > It simple enough. But I am happy to see a different approach. > > Simple is good! > > > Any thoughts on additional work that I am not seeing? > > None :) > > > > > Thanks for responding! I know our team is very excited about the > > continued collaboration with other upstream projects, so thanks!! > > > > Likewise. Let's reduce tech debt/maintain more code together! > > Regards, > Jean-Philippe Evrard (evrardjp) > > > > > -- Arx Cruz Software Engineer Red Hat EMEA <https://www.redhat.com> arxcruz(a)redhat.com @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190812…> ------------------------------ Message: 2 Date: Mon, 12 Aug 2019 12:56:15 +0200 From: Ondrej Novy <novy(a)ondrej.org> To: openstack-discuss(a)lists.openstack.org Subject: [swauth][swift] Retiring swauth Message-ID: <CAOO6c=wgDZDRpQboo=_0qZ=fHrfu0rO0w=PaUat9bJduwFiVXw(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi, because swauth is not compatible with current Swift, doesn't support Python 3, I don't have time to maintain it and my employer is not interested in swauth, I'm going to retire swauth project. If nobody take over it, I will start removing swauth from opendev on 08/24. Thanks. -- Best regards Ondřej Nový -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190812…> ------------------------------ Message: 3 Date: Mon, 12 Aug 2019 07:55:07 -0400 From: Julia Kreger <juliaashleykreger(a)gmail.com> To: openstack-discuss <openstack-discuss(a)lists.openstack.org> Subject: [ironic] Resuming having weekly meetings Message-ID: <CAF7gwdhSWcUbYu0S2QfvjO44Q_5vJr6KTUQE3TRu3UYirqFGmQ(a)mail.gmail.com> Content-Type: text/plain; charset="UTF-8" All, I meant to send this specific email last week, but got distracted and $life. I believe we need to go back to having weekly meetings. The couple times I floated this in the past two weeks, there hasn't seemed to be any objections, but I also did not perceive any real thoughts on the subject. While the concept and use of office hours has seemingly helped bring some more activity to our IRC channel, we don't have a check-point/sync-up mechanism without an explicit meeting. With that being said, I'm going to start the meeting today and if we have quorum, try to proceed with it today. -Julia ------------------------------ Message: 4 Date: Mon, 12 Aug 2019 12:59:20 +0000 From: "Teckelmann, Ralf, NMU-OIP" <ralf.teckelmann(a)bertelsmann.de> To: "openstack-discuss(a)lists.openstack.org" <openstack-discuss(a)lists.openstack.org> Subject: [masakari] pacemaker-remote Setup Overview Message-ID: <AM6PR04MB47112DF6617442709662B43389D30(a)AM6PR04MB4711.eurprd04.prod.outlook.com> Content-Type: text/plain; charset="utf-8" Hello, Utilizing openstack-ansible we successfully installed all the masakari services. Besides masakari-hostmonitor all are running fine. For the hostmonitor a pacemaker cluster is missing. Can anyone give me an overview how the pacemaker cluster setup would look like? Which (pacemaker) services is running where (compute nodes, something on any other node,...), etc? Best regards, Ralf Teckelmann -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190812…> ------------------------------ Subject: Digest Footer _______________________________________________ openstack-discuss mailing list openstack-discuss(a)lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss ------------------------------ End of openstack-discuss Digest, Vol 10, Issue 59 ************************************************* Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding.

1 0

Kombu 4.6.4 is breaking devstack with python 3.7
by Daniel Leaberry 19 Aug '19

19 Aug '19

I'm not sure if this is the correct place to report it but I'm working on the Cinder Thirdparty CI requirement to move testing to Python 3.7. https://wiki.openstack.org/wiki/Cinder/3rdParty-drivers-py3-update <https://wiki.openstack.org/wiki/Cinder/3rdParty-drivers-py3-update> Unfortunately this commit moving Kombu to 4.6.4 a day ago has broken the devstack setup scripts. https://opendev.org/openstack/requirements/commit/b236f0af43259959cb2a0f828… <https://opendev.org/openstack/requirements/commit/b236f0af43259959cb2a0f828…> It breaks because (I believe) Eventlet is monkey patching and kombu 4.6.4 interacts badly. See these two bug reports for more details. https://github.com/eventlet/eventlet/issues/534 <https://github.com/eventlet/eventlet/issues/534> https://github.com/nameko/nameko/issues/655 <https://github.com/nameko/nameko/issues/655> Kombu 4.6.4 now results in this error when running /usr/local/bin/nova-manage --config-file /etc/nova/nova.conf api_db sync 2019-08-16 22:56:25.446 <http://openstack-logs.purestorage.com/PureISCSIDriver-tempest-dsvm-xenial-a…> | File "/usr/local/lib/python3.7/dist-packages/eventlet/green/os.py", line 107, in open 2019-08-16 22:56:25.446 <http://openstack-logs.purestorage.com/PureISCSIDriver-tempest-dsvm-xenial-a…> | fd = __original_open__(file, flags, mode, dir_fd=dir_fd) 2019-08-16 22:56:25.446 <http://openstack-logs.purestorage.com/PureISCSIDriver-tempest-dsvm-xenial-a…> | TypeError: open: path should be string, bytes or os.PathLike, not _NormalAccessor You can see full logs here. http://openstack-logs.purestorage.com/PureISCSIDriver-tempest-dsvm-xenial-a… <http://openstack-logs.purestorage.com/PureISCSIDriver-tempest-dsvm-xenial-a…> I'm open to any recommendation of a workaround. Downgrading to kombu 4.6.3 apparently works fine but I'm not sure how to do that within an automated devstack run. Thanks

2 1

Re: Kombu 4.6.4 is breaking devstack with python 3.7
by Eric Fried 19 Aug '19

19 Aug '19

Hi Daniel. > Unfortunately this commit moving Kombu to 4.6.4 a day ago has broken the devstack setup scripts. > https://opendev.org/openstack/requirements/commit/b236f0af43259959cb2a0f828… <snip> > TypeError: open: path should be string, bytes or os.PathLike, not _NormalAccessor After I saw this go by, nova (at least) started failing all openstack-tox-py37 runs with the same error. I was able to recreate the problem locally. I was also able to resolve it by moving kombu back to 4.6.3. Clearly we need to blacklist kombu 4.6.4 for the moment. I've proposed that patch here [1]. Thank you very much for identifying the root of the problem. efried [1] https://review.opendev.org/#/c/677070/

2 2

[blazar] IRC meeting tomorrow
by Pierre Riteau 19 Aug '19

19 Aug '19

Hello, We have our weekly Blazar IRC meeting scheduled for tomorrow at 09:00 UTC on #openstack-meeting-alt. As the last weekly meeting was at the end of July, we have a busy agenda this week: https://wiki.openstack.org/wiki/Meetings/Blazar#Agenda_for_20_August_2019 Everyone is welcome to join and propose additional topics, time permitting. Best wishes, Pierre

1 0

[all] [tc] PDF Community Goal Update
by Alexandra Settle 19 Aug '19

19 Aug '19

Hi all, Apologies for the radio silence regarding the PDF Community Goal. Due to vacation and personal circumstance, I've been "offline" for the better part of the last 2 months. Update * Stephen Finucane has been working on adding Python 3 support to rst2pdf * Common issues are being tracked within this etherpad [1] * Overall status: https://review.opendev.org/#/q/topic:build-pdf-docs Help needed * We would appreciate anyone who is comfortable with Python to help and volunteer to test the rst2pdf output with Python 2. Working within a larger project like Neutron to see how much it can do, as they have specific styling capabilities. * NOTE: The original discussion included using the LaTeX builder instead of rst2pdf. However, the LaTeX builder is not playing ball as nicely as we'd like, so we're trying to figure out if this would be easier. The LaTeX builder is still the primary plan, since we still don't know what we're going with and the overlap between the two is significant. Questions? Thank you, Alex [1] https://etherpad.openstack.org/p/pdf-goal-train-common-problems

1 1

[question][placement][rest api][403]
by 崔恒香 19 Aug '19

19 Aug '19

This is my problem with placement rest api.(Token and endpoint were OK) {"errors": [{"status": 403, "title": "Forbidden", "detail": "Access was denied to this resource.\n\n Policy does not allow placement:resource_providers:list to be performed. ", "request_id": "req-5b409f22-7741-4948-be6f-ea28c2896a3f" }]} Regards, Cuihx

2 1

Some questions about contributing a golang project
by Douglas Zhang 18 Aug '19

18 Aug '19

Hello everyone, My colleagues and me have been working on an openstack admin project(like horizon, but more efficient) using Golang, and now we are willing to contribute it to openstack community. While looking through the project creators' guide [1], we have met some questions that need to be answered: As this project is written by go, it is not possible to register it on PyPI, would this have any influence? Would openstack community accept golang projects as its related projects? [1] https://docs.openstack.org/infra/manual/creators.html#give-openstack-permis… Thanks, Douglas

3 2

[all][tc] U Cycle Naming Poll
by Doug Hellmann 18 Aug '19

18 Aug '19

Every OpenStack development cycle and release has a code-name. As with everything we do, the process of choosing the name is open and based on input from communty members. The name critera are described in [1], and this time around we were looking for names starting with U associated with China. With some extra assistance from local community members (thank you to everyone who helped!), we have a list of candidate names that will go into the poll. Below is a subset of the names propsed, including those that meet the standard criteria and some of the suggestions that do not. Before we start the poll, the process calls for us to provide a period of 1 week so that any names removed from the proposals can be discussed and any last-minute objections can be raised. We will start the poll next week using this list, including any modifications based on that discussion. 乌镇镇 [GR]:Ujenn [PY]:Wuzhen https://en.wikipedia.org/wiki/Wuzhen 温州市 [GR]:Uanjou [PY]:Wenzhou https://en.wikipedia.org/wiki/Wenzhou 乌衣巷 [GR]:Ui [PY]:Wuyi https://en.wikipedia.org/wiki/Wuyi_Lane 温岭市 [GR]:Uanliing [PY]:Wenling https://en.wikipedia.org/wiki/Wenling 威海市 [GR]:Ueihae [PY]:Weihai https://en.wikipedia.org/wiki/Weihai 微山湖 [GR]:Ueishan [PY]:Weishan https://en.wikipedia.org/wiki/Nansi_Lake 乌苏里江 Ussri https://en.wikipedia.org/wiki/Ussuri_River (the name is shared among Mongolian/Manchu/Russian; this is a common Latin-alphabet transcription of the name. Pinyin would be Wūsūlǐ) 乌兰察布市 Ulanqab https://en.wikipedia.org/wiki/Ulanqab (the name is in Mongolian; this is a common Latin-alphabet transcription of the name. Pinyin would be Wūlánchábù) 乌兰浩特市 Ulanhot https://en.wikipedia.org/wiki/Ulanhot (the name is in Mongolian; this is a common Latin-alphabet transcription of the name. Pinyin would be Wūlánhàotè) 乌兰苏海组 Ulansu (Ulansu sea) (the name is in Mongolian) 乌拉特中旗 Urad https://en.wikipedia.org/wiki/Urad_Middle_Banner (the name is in Mongolian; this is a common Latin-alphabet transcription of the name. Pinyin would be Wūlātè) 东/西乌珠穆沁旗 Ujimqin https://en.wikipedia.org/wiki/Ujimqin (the name is in Mongolian; this is a common Latin-alphabet transcription of the name. Pinyin would be Wūzhūmùqìn) Ula "Miocene Baogeda Ula" (the name is in Mongolian) Uma http://www.fallingrain.com/world/CH/20/Uma.html Unicorn Urban Unique Umpire Utopia Umbrella Ultimate [1] https://governance.openstack.org/tc/reference/release-naming.html

20 59

[keystone] Keystone Team Update - Week of 12 August 2019
by Colleen Murphy 17 Aug '19

17 Aug '19

# Keystone Team Update - Week of 12 August 2019 ## News ### Feature Proposal Freeze This week is our scheduled feature proposal freeze[1], see status summary post[2]. [1] https://releases.openstack.org/train/schedule.html [2] http://lists.openstack.org/pipermail/openstack-discuss/2019-August/008549.h… ### Trusts API While implementing system scope and default roles for the trusts API we discovered an inconsistency in the error handling for the GET trust details request: most of our APIs do RBAC enforcement first thing, and return a 403 if the resource is missing so as not to divulge whether there's a record in the database for the requested resource. The GET trust details request does the database lookup first and exposes a 404 to the user if the record is missing. We discussed in the bug report[3] whether this is desireable, intended, acceptable, or dangerous behavior, and so far have converged on not fixing the issue in the interest of not breaking the API contract. If you have feelings to the contrary, please speak up in the bug report. [3] https://bugs.launchpad.net/bugs/1840288 ## Action Items * knikolla to finish initial implementation proposal of renewable group membership next week * kmalloc to finish initial implementation proposal of resource options migration next week ## Office Hours When there are topics to cover, the keystone team holds office hours on Tuesdays at 17:00 UTC. The topic for next week's office hour will be: feature proposal review - we'll walk through code implementations (if available) and answer any questions, or discuss design details if code is not available yet The location for next week's office hour will be: https://meet.jit.si/keystone-office-hours Add topics you would like to see covered during office hours to the etherpad: https://etherpad.openstack.org/p/keystone-office-hours-topics ## Open Specs Ongoing specs: https://bit.ly/2OyDLTh ## Recently Merged Changes Search query: https://bit.ly/2pquOwT We merged 15 changes this week, which included support for auth receipts in keystoneauth[4], the IPv6 community goal work[5], and some more changes to implement access rules in application credentials[6]. [4] https://review.opendev.org/675049 [5] https://review.opendev.org/671903 [6] https://review.opendev.org/#/q/status:merged+topic:bp/whitelist-extension-f… ## Changes that need Attention Search query: https://bit.ly/2tymTje There are 47 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. ### Priority Reviews * Train Roadmap Stories - System scope/default roles (https://trello.com/c/ERo50T7r , https://trello.com/c/RlYyb4DU) + https://review.opendev.org/#/q/status:open+topic:implement-default-roles+la… + https://review.opendev.org/#/q/status:open+topic:trust-policies + https://review.opendev.org/#/q/topic:bug/1805409 - Federated attributes for users (https://trello.com/c/dEmSumDQ) + https://review.opendev.org/#/q/status:open+topic:bp/support-federated-attr - Application credential access rules (https://trello.com/c/dJsWMI4W) + https://review.opendev.org/#/q/status:open+topic:bp/whitelist-extension-for… * Closes bugs - Honor group_members_are_ids for user_enabled_emulation https://review.opendev.org/674782 - Cleanup session on delete https://review.opendev.org/674139 - token: consistently decode binary types https://review.opendev.org/665617 * Oldest - OpenID Connect improved support https://review.opendev.org/373983 ## Bugs This week we opened 6 new bugs and closed 3. Bugs opened (6) Bug #1840288 (keystone:High) opened by Colleen Murphy https://bugs.launchpad.net/keystone/+bug/1840288 Bug #1840291 (keystone:Medium) opened by Rabi Mishra https://bugs.launchpad.net/keystone/+bug/1840291 Bug #1840090 (keystone:Undecided) opened by Adrian Turjak https://bugs.launchpad.net/keystone/+bug/1840090 Bug #1840403 (keystone:Undecided) opened by Ariya Jantaravises https://bugs.launchpad.net/keystone/+bug/1840403 Bug #1839748 (keystoneauth:High) opened by Adrian Turjak https://bugs.launchpad.net/keystoneauth/+bug/1839748 Bug #1840235 (keystoneauth:Undecided) opened by Rabi Mishra https://bugs.launchpad.net/keystoneauth/+bug/1840235 Bugs closed (1) Bug #1840288 (keystone:High) https://bugs.launchpad.net/keystone/+bug/1840288 Bugs fixed (2) Bug #1839577 (keystone:Medium) fixed by Adrian Turjak https://bugs.launchpad.net/keystone/+bug/1839577 Bug #1839748 (keystoneauth:High) fixed by Adrian Turjak https://bugs.launchpad.net/keystoneauth/+bug/1839748 ## Milestone Outlook https://releases.openstack.org/train/schedule.html This week is feature proposal freeze week for the keystone team, which as mentioned previously is being extended for some initiatives. Oslo feature freeze is in two weeks: anything we need to complete for oslo.policy needs to be merged before then. Oslo.limit is still pre-1.0 so feature freeze won't apply to it. The PTL nomination period is also in two weeks: while I intend to run again I'm also happy to answer questions about the role if anyone wants to also put their name in. Final release for non-client libraries (keystonemiddleware, keystoneauth) is in three weeks. Feature freeze and client library freeze is in four weeks. This is also the soft string freeze and the requirements freeze and the community goals deadline. ## Shout-outs Keystoneauth now supports multi-factor authentication and auth receipts[7]. Thanks to Adrian for tackling this ahead of the library freeze deadline! [7] https://docs.openstack.org/keystoneauth/latest/authentication-plugins.html#… ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter

1 0

[keystone] Feature proposal freeze status
by Colleen Murphy 17 Aug '19

17 Aug '19

This week is the keystone team's feature proposal freeze week. Here's a status update for our planned features for this cycle[1]: * Add Fine Grained Restrictions to Application Credentials[2]: implementation is proposed and ready for review[3], most work is merged, some patches remaining for review, client work not started * Expiring Group Memberships Through Mapping Rules[4]: implementation not yet proposed, 1-week extension granted[5] * Explicit Domain IDs[6]: Complete[7] * Immutable Resources[8]: Implementation proposed[9], partially WIP; depends on resource options work * Resource options for all resource types[10]: implementation not yet proposed, 1-week extension granted[11] * Extend user API to support federated attributes[12]: proposed and ready for review[13] We're only holding spec work accountable to the feature proposal freeze deadline. Other roadmap features[14], including system scope and default roles work, is open for code proposals until feature freeze week. [1] http://specs.openstack.org/openstack/keystone-specs/ [2] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/train/ca… [3] https://review.opendev.org/#/q/topic:bp/whitelist-extension-for-app-creds [4] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/train/ex… [5] http://lists.openstack.org/pipermail/openstack-discuss/2019-August/008513.h… [6] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/train/ex… [7] https://review.opendev.org/605235 [8] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/train/im… [9] https://review.opendev.org/#/q/topic:immutable-resources [10] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/train/re… [11] http://lists.openstack.org/pipermail/openstack-discuss/2019-August/008546.h… [12] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/train/su… [13] https://review.opendev.org/#/q/topic:bp/support-federated-attr [14] https://trello.com/b/ClKW9C8x/keystone-train-roadmap

1 0

[keystone] Feature proposal freeze exception for resource options
by Colleen Murphy 17 Aug '19

17 Aug '19

Work is underway to implement resource options for all resources[1] but the code has not been proposed yet. Since the implementation is close to ready to review, and because immutable resources[2] depends on it, we're proposing a 1-week extension to our feature proposal freeze deadline[3]. This will also push out the work for immutable resources, but the majority of this feature has been implemented[4] and will only require a rebase on top of the resource options work. If you have any concerns about this, please let me or the team know. Colleen [1] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/train/re… [2] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/train/im… [3] https://releases.openstack.org/train/schedule.html [4] https://review.opendev.org/#/q/topic:immutable-resources

1 0

[goal][python3] Train unit tests weekly update (goal-4)
by Corey Bryant 17 Aug '19

17 Aug '19

This is the goal-4 weekly update for the "Update Python 3 test runtimes for Train" goal [1]. There are 4 weeks remaining for completion of Train community goals [2]. == How can you help? == If your project has failing tests please take a look and help fix. Python 3.7 unit tests will be self-testing in Zuul. Failing patches: https://review.openstack.org/#/q/topic:python3-train +status:open+(+label:Verified-1+OR+label:Verified-2+) If your project has patches with successful tests please help get them merged. Open patches needing reviews: https://review.openstack.org/#/q/topic:python3 -train+is:open Patch automation scripts needing review: https://review.opendev.org/#/c/666934 == Ongoing Work == Thank you to all who have contributed their time and fixes to enable patches to land. We're down to 23 projects with failing tests. == Completed Work == All patches have been submitted to all applicable projects for this goal. Merged patches: https://review.openstack.org/#/q/topic:python3-train +is:merged == What's the Goal? == To ensure (in the Train cycle) that all official OpenStack repositories with Python 3 unit tests are exclusively using the 'openstack-python3-train-jobs' Zuul template or one of its variants (e.g. 'openstack-python3-train-jobs-neutron') to run unit tests, and that tests are passing. This will ensure that all official projects are running py36 and py37 unit tests in Train. For complete details please see [1]. == Reference Material == [1] Goal description: https://governance.openstack.org/tc/goals/train/ python3-updates.html [2] Train release schedule: https://releases.openstack.org/train /schedule.html (see R-5 for "Train Community Goals Completed") Storyboard: https://storyboard.openstack.org/#!/story/2005924 Porting to Python 3.7: https://docs.python.org/3/whatsnew/3.7.html#porting-to-python-3-7 Python Update Process: https://opendev.org/openstack/governance/src/branch/master/resolutions/2018… Train runtimes: https://opendev.org/openstack/governance/src/branch/master/reference/runtim… train.rst Thanks,

1 0

[ironic][ptl] Taking a break - i.e. disconnecting for a few weeks in September
by Julia Kreger 16 Aug '19

16 Aug '19

Greetings everyone, For my own mental health and with various things that have occurred in my life these past six months, I will be disconnecting for two weeks during the month of September, starting on the 6th. To put icing on the cake, I then have business related travel the two weeks following my return that will inhibit regular IRC access during peak contributor days/hours. In my absence, Dmitry Tantsur has agreed to take care of my PTL responsibilities. This will include the time through requirements freeze and quite possibly include the creation of the stable/train branch if necessary. That being said, fear not! I still intend to run for Ironic's PTL for the next cycle! -Julia

2 1

[neutron][OVN] Instance not getting metadata
by Zufar Dhiyaulhaq 16 Aug '19

16 Aug '19

Hi, I have set up OpenStack with OVN enabled (manual install) and I can create Instance, associate floating IP and test the ping. But my Instance not getting metadata from OpenStack. I check the reference architecture, https://docs.openstack.org/networking-ovn/queens/admin/refarch/refarch.html the compute nodes should have installed ovn-metadata-agent but I don't find any configuration document about ovn-metadata-agent. I have configured the configuration files like this: [DEFAULT] nova_metadata_ip = 10.100.100.10 [ovs] ovsdb_connection = unix:/var/run/openvswitch/db.sock [ovn] ovn_sb_connection = tcp:10.101.101.10:6642 But the agent always fails. Full logs: http://paste.openstack.org/show/757805/ Anyone know whats happen and how to fix this error? Best Regards, Zufar Dhiyaulhaq

2 3

[monasca][ptl] Out of office
by Witek Bedyk 16 Aug '19

16 Aug '19

Hello everyone, I will be out of office from August 19th until 30th. In Monasca related matters please contact: Martin Chacon Piza <martindavid.chaconpiza1(a)est.fujitsu.com> Thanks Witek

1 0

[placement] update 19-32
by Chris Dent 16 Aug '19

16 Aug '19

HTML: https://anticdent.org/placement-update-19-32.html Here's placement update 19-32. There will be no update 33; I'm going to take next week off. If there are Placement-related issues that need immediate attention please speak with any of Eric Fried (efried), Balazs Gibizer (gibi), or Tetsuro Nakamura (tetsuro). # Most Important Same as last week: The main things on the Placement radar are implementing Consumer Types and cleanups, performance analysis, and documentation related to nested resource providers. A thing we should place on the "important" list is bringing the osc placement plugin up to date. We also need to discuss what would we would like the plugin to be. Is it required that it have ways to perform all the functionality of the API, or is it about providing ways to do what humans need to do with the placement API? Is there a difference? We decided that consumer types is medium priority: The nova-side use of the functionality is not going to happen in Train, but it would be nice to have the placement-side ready when U opens. The primary person working on it, tssurya, is spread pretty thin so it might not happen unless someone else has the cycles to give it some attention. On the documentation front, we realized during some performance work [last](https://review.opendev.org/675606) [week](https://review.opendev.org/#/c/676204/4/placement/tests/functional/ga… that it easy to have an incorrect grasp of how `same_subtree` works when there are more than two groups involved. It is critical that we create good "how to use" documentation for this and other advanced placement features. Not only can it be easy to get wrong, it can be challenge to see that you've got it wrong (the failure mode is "more results, only some of which you actually wanted"). # What's Changed * Yet more [performance fixes](https://review.opendev.org/#/q/topic:optimize-_build_provider_summar… are in the process of merging. Most of these are related to getting `_merge_candidates` and `_build_provider_summaries` to have less impact. The fixes are generally associated with avoiding duplicate work by generating dicts of reusable objects earlier in the request. This is possible because of the relatively new `RequestWideSearchContext`. In a request that returns many provider summaries `_build_provider_summaries` continues to have a significant impact because it has to create many objects but overall everything is much less heavyweight. More on performance in Themes, below. * The combination of all these performance fixes, and because of microversions, makes it reasonable for anyone running placement in a resource constrained environment (or simply wanting things to be faster) to consider running Train placement with _any_ release of OpenStack. Obviously you should test it first, but it is worth investigating. More information on how to achieve this can be found in the [upgrade to stein docs](https://docs.openstack.org/placement/latest/upgrade/to-stein.html) # Stories/Bugs (Numbers in () are the change since the last pupdate.) There are 23 (1) stories in [the placement group](https://storyboard.openstack.org/#!/project_group/placement). 0 (0) are [untagged](https://storyboard.openstack.org/#!/worklist/580). 4 (1) are [bugs](https://storyboard.openstack.org/#!/worklist/574). 4 (0) are [cleanups](https://storyboard.openstack.org/#!/worklist/575). 11 (0) are [rfes](https://storyboard.openstack.org/#!/worklist/594). 4 (0) are [docs](https://storyboard.openstack.org/#!/worklist/637). If you're interested in helping out with placement, those stories are good places to look. * Placement related nova [bugs not yet in progress](https://goo.gl/TgiPXb) on launchpad: 18 (1). * Placement related nova [in progress bugs](https://goo.gl/vzGGDQ) on launchpad: 4 (-1). # osc-placement osc-placement is currently behind by 12 microversions. * <https://review.opendev.org/666542> Add support for multiple member_of. There's been some useful discussion about how to achieve this, and a consensus has emerged on how to get the best results. * <https://review.opendev.org/640898> Adds a new '--amend' option which can update resource provider inventory without requiring the user to pass a full replacement for inventory. This has been broken up into three patches to help with review. # Main Themes ## Consumer Types Adding a type to consumers will allow them to be grouped for various purposes, including quota accounting. * <https://review.opendev.org/#/q/topic:bp/support-consumer-types> A WIP, as microversion 1.37, has started. As mentioned above, this is currently paused while other things take priority. If you have time that you could spend on this please respond here expressing that interest. ## Cleanup Cleanup is an overarching theme related to improving documentation, performance and the maintainability of the code. The changes we are making this cycle are fairly complex to use and are fairly complex to write, so it is good that we're going to have plenty of time to clean and clarify all these things. As said above, there's lots of performance work in progress. We'll need to make a similar effort with regard to docs. For example, all of the coders involved in the creation and review of the `same_subtree` functionality struggle to explain, clearly and simply, how it will work in a variety of situations. We need to enumerate the situations and the outcomes, in documentation. One outcome of this work will be something like a _Deployment Considerations_ document to help people choose how to tweak their placement deployment to match their needs. The simple answer is use more web servers and more database servers, but that's often very wasteful. On the performance front, there is one major area of impact which has not received much attention yet. When requesting allocation candidates (or resource providers) that will return many results the cost of JSON serialization is just under one quarter of the processing time. This is to be expected when the response body is `2379k` big, and 154000 lines long (when pretty printed) for 7000 provider summaries and 2000 allocation requests. But there are ways to fix it. One is to ask more focused questions (so fewer results are expected). Another is to `limit=N` the results (but this can lead to issues with migrations). Another is to [use a different JSON serializer](https://review.opendev.org/674661). Should we do that? It make a _big_ difference with large result sets (which will be common in big and sparse clouds). # Other Placement Miscellaneous changes can be found in [the usual place](https://review.opendev.org/#/q/project:openstack/placement+status:op…. There are two [os-traits changes](https://review.opendev.org/#/q/project:openstack/os-traits+status:… being discussed. And zero [os-resource-classes changes](https://review.opendev.org/#/q/project:openstack/os-resource-class…. # Other Service Users New discoveries are added to the end. Merged stuff is removed. Anything that has had no activity in 4 weeks has been removed. * <https://review.openstack.org/#/q/topic:bug/1819923> Nova: nova-manage: heal port allocations * <https://review.opendev.org/659233> Cyborg: Placement report * <https://review.opendev.org/662229> helm: add placement chart * <https://review.opendev.org/634551> libvirt: report pmem namespaces resources by provider tree * <https://review.opendev.org/660852> Nova: Remove PlacementAPIConnectFailure handling from AggregateAPI * <https://review.opendev.org/670112> Nova: WIP: Add a placement audit command * <https://review.opendev.org/671312> blazar: Fix placement operations in multi-region deployments * <https://review.opendev.org/671793> Nova: libvirt: Start reporting PCPU inventory to placement A part of <https://review.opendev.org/#/q/topic:bp/cpu-resources * <https://review.opendev.org/#/q/topic:bp/support-move-ops-with-qos-ports> Nova: support move ops with qos ports * <https://review.opendev.org/666202> Blazar: Create placement client for each request * <https://review.opendev.org/667952> nova: Support filtering of hosts by forbidden aggregates * <https://review.opendev.org/669079> blazar: Send global_request_id for tracing calls * <https://review.opendev.org/670696> tempest: Add placement API methods for testing routed provider nets * <https://review.opendev.org/672678> openstack-helm: Build placement in OSH-images * <https://review.opendev.org/674129> Correct global_request_id sent to Placement * <https://review.opendev.org/#/q/topic:bp/cross-cell-resize> Nova: cross cell resize * <https://review.opendev.org/674524> Nova: Scheduler translate properties to traits * <https://review.opendev.org/623558> Nova: single pass instance info fetch in host manager * <https://review.opendev.org/674708> Zun: [WIP] Claim container allocation in placement # End Have a good next week. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent

1 0

kayobe 6.0.0.0rc1 (stein)
by no-reply＠openstack.org 16 Aug '19

16 Aug '19

Hello everyone, A new release candidate for kayobe for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/kayobe/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://opendev.org/openstack/kayobe/log/?h=stable/stein Release notes for kayobe can be found at: https://docs.openstack.org/releasenotes/kayobe/

1 0

[ironic] [stable] Proposal to add Riccardo Pittau to ironic-stable-maint
by Dmitry Tantsur 16 Aug '19

16 Aug '19

Hi folks! I'd like to propose adding Riccardo to our stable team. He's been consistently checking stable patches [1], and we're clearly understaffed when it comes to stable reviews. Thoughts? Dmitry [1] https://review.opendev.org/#/q/reviewer:%22Riccardo+Pittau+%253Celfosardo%2…

6 6

Re: [lists.openstack.org]Re: [nova] The race for 2.76
by Brin Zhang(张百林) 16 Aug '19

16 Aug '19

> On 8/13/2019 7:25 AM, Matt Riedemann wrote: > > There are several compute API microversion changes that are > > conflicting and will be fighting for 2.76, but I think we're trying to > > prioritize this one [1] for the ironic power sync external event > > handling since (1) Surya is going to be on vacation soon, (2) there is > > an ironic change that depends on it which has had review [2] and (3) > > the nova change has had quite a bit of review already. > > > > As such I think others waiting to rebase from 2.75 to 2.76 should > > probably hold off until [1] is approved which should happen today or > > tomorrow. > > > > [1] https://review.opendev.org/#/c/645611/ > > [2] https://review.opendev.org/#/c/664842/ > These are both approved now so let the rebasing begin! "Specifying az when restore shelved server" have been updated, and now it's in the nova-runway, please review, thanks. Links: https://review.opendev.org/#/q/topic:bp/support-specifying-az-when-restore-… -- Thanks, Matt

1 0

[nova] NUMA live migration is ready for review and testing
by Artom Lifshitz 16 Aug '19

16 Aug '19

tl;dr If you care about NUMA live migration, check out [1] and test in in your env(s), or review it. Over the months that I've worked on NUMA LM, I've been pinged by various folks that were interested in helping out. At this point I've addressed all the issues that were found at the end of the Stein cycle, and the series is ready for review and testing, with the aim of getting it merged in Train (for real this time). So if you care about NUMA-aware live migration and have some spare time and hardware (if you're in the former category I don't think I need to explain what kind of hardware - though I'll try to answer questions as best I can), I would greatly appreciate it if you deployed the patches and tested them. I've done that myself, of course, but, as at the end of Stein, I'm sure there are edge cases that I didn't think of (though I'm selfishly hoping that there aren't). I believe the series is also ready for review, though I haven't put it in the runway queue just yet because the last functional test patch is still a WIP, as I need to fiddle with it to assert more things. Thanks in advance, cheers! [1] https://review.opendev.org/#/c/672595/8

4 3

[qa][openstackclient] Debugging devstack slowness
by Clark Boylan 16 Aug '19

16 Aug '19

Today I have been digging into devstack runtime costs to help Donny Davis understand why tempest jobs sometimes timeout on the FortNebula cloud. One thing I discovered was that the keystone user, group, project, role, and domain setup [0] can take many minutes [1][2] (in the examples here almost 5). I've rewritten create_keystone_accounts to be a python tool [3] and get the runtime for that subset of setup from ~100s to ~9s [4]. I imagine that if we applied this to the other create_X_accounts functions we would see similar results. I think this is so much faster because we avoid repeated costs in openstack client including: python process startup, pkg_resource disk scanning to find entrypoints, and needing to convert names to IDs via the API every time osc is run. Given my change shows this can be so much quicker is there any interest in modifying devstack to be faster here? And if so what do we think an appropriate approach would be? [0] https://opendev.org/openstack/devstack/src/commit/6aeaceb0c4ef078d028fb6605… [1] http://logs.openstack.org/05/672805/4/check/tempest-full/14f3211/job-output… [2] http://logs.openstack.org/05/672805/4/check/tempest-full/14f3211/job-output… [3] https://review.opendev.org/#/c/673108/ [4] http://logs.openstack.org/08/673108/6/check/devstack-xenial/a4107d0/job-out… Note the jobs compared above all ran on rax-dfw. Clark

11 23

[question][placement][rest api][403]
by 崔恒香 16 Aug '19

16 Aug '19

This is my problem with placement rest api.(Token and endpoint were OK) {"errors": [{"status": 403, "title": "Forbidden", "detail": "Access was denied to this resource.\n\n Policy does not allow placement:resource_providers:list to be performed. ", "request_id": "req-5b409f22-7741-4948-be6f-ea28c2896a3f" }]} Regards, Cuihx

2 1

[nova] The race for 2.76
by Matt Riedemann 16 Aug '19

16 Aug '19

There are several compute API microversion changes that are conflicting and will be fighting for 2.76, but I think we're trying to prioritize this one [1] for the ironic power sync external event handling since (1) Surya is going to be on vacation soon, (2) there is an ironic change that depends on it which has had review [2] and (3) the nova change has had quite a bit of review already. As such I think others waiting to rebase from 2.75 to 2.76 should probably hold off until [1] is approved which should happen today or tomorrow. [1] https://review.opendev.org/#/c/645611/ [2] https://review.opendev.org/#/c/664842/ -- Thanks, Matt

1 1

[glance] worker, thread, taskflow interplay
by Gregory Orange 15 Aug '19

15 Aug '19

We are trying to figure out how these two settings interplay in: [DEFAULT]/workers [taskflow_executor]/max_workers [oslo_messaging_zmq]/rpc_thread_pool_size Just setting workers makes a bit of sense, and based on our testing: =0 creates one process =1 creates 1 plus 1 child =n creates 1 plus n children Are there green threads (i.e. coroutines, per https://eventlet.net/doc/basic_usage.html) within every process, regardless of the value of workers? Does max_workers affect that? We have read some Glance doco, hunted about various bug reports[1] and other discussions online to get some insight, but I think we're not clear on it. Can anyone explain this a bit better to me? This is all in Rocky. Thank you, Greg. [1] https://bugs.launchpad.net/glance/+bug/1748916

2 1

[keystone] Feature proposal freeze exception for refreshable group membership
by Colleen Murphy 15 Aug '19

15 Aug '19

Work is in progress to implement refreshable group membership in keystone[1]. In order to allow for some breathing room for thorough discussion on the implementation details, we're proposing a 1-week extension to our scheduled feature proposal freeze deadline (this week)[2]. Please let me or the team know if you have any concerns about this. Colleen [1] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/train/ex… [2] https://releases.openstack.org/train/schedule.html

2 1

[blazar] IRC meeting today
by Pierre Riteau 15 Aug '19

15 Aug '19

Hello, Today we have our biweekly Blazar IRC meeting at 16:00 UTC on #openstack-meeting-alt: https://wiki.openstack.org/wiki/Meetings/Blazar#Agenda_for_15_Aug_2019_.28A… We can update on the status of upstream contributions from our user community. Everyone is welcome to join and bring up any other topic. Cheers, Pierre

1 0

[nova] API updates week 19-33
by Ghanshyam Mann 15 Aug '19

15 Aug '19

Hello Everyone, Please find the Nova API updates of this week. API Related BP : ============ COMPLETED: 1. Support adding description while locking an instance: - https://blueprints.launchpad.net/nova/+spec/add-locked-reason 2. Add host and hypervisor_hostname flag to create server - https://blueprints.launchpad.net/nova/+spec/add-host-and-hypervisor-hostnam… Code Ready for Review: ------------------------------ 1. Specifying az when restore shelved server - Topic: https://review.opendev.org/#/q/topic:bp/support-specifying-az-when-restore-… - Weekly Progress: This has been rebased as 2.75 microversion is already merged. This will need again rebase as 2.76 is reserved for 'Add 'power-update' external event' 2. Nova API cleanup - Topic: https://review.opendev.org/#/q/topic:bp/api-consistency-cleanup+(status:ope… - Weekly Progress: Nova patch is merged. python-novaclient patch is pending. 3. Show Server numa-topology - Topic: https://review.opendev.org/#/q/topic:bp/show-server-numa-topology+(status:o… - Weekly Progress: Alex is +1 on nova change, but this is with microversion number as 2.76. This might need to be hold on ? 4. Nova API policy improvement - Topic: https://review.openstack.org/#/q/topic:bp/policy-default-refresh+(status:op… - Weekly Progress: First set of os-service and Admin Action API policy series is ready to review. I have sent the review guide over ML - http://lists.openstack.org/pipermail/openstack-discuss/2019-August/008504.h… 5. Add 'power-update' external event: - Topic: https://review.opendev.org/#/q/topic:bp/nova-support-instance-power-update+… - Weekly Progress: This is reserved for 2.76 and we should merge this soon as many other microversion changes are waiting for grabbing 2.76. I do not have updates on the current state, maybe matt or surya can add more if needed. 6. Add User-id field in migrations table - Topic: https://review.opendev.org/#/q/topic:bp/add-user-id-field-to-the-migrations… - Weekly Progress: Changes are up for review but with microversion 2.76. We can rebase the microverison number later and not blocking for review. I will review it next week. 7. Support delete_on_termination in volume attach api -Spec: https://review.opendev.org/#/q/topic:bp/support-delete-on-termination-in-se… - Weekly Progress: Spec is merged and code is up for review. This is another one from Brin. Ready for review and rebase on available microversion number can be done later. Specs are merged and code in-progress: ------------------------------ ------------------ 1. Detach and attach boot volumes: - Topic: https://review.openstack.org/#/q/topic:bp/detach-boot-volume+(status:open+O… - Weekly Progress: No Progress. Patches are in merge conflict. Spec Ready for Review: ----------------------------- 1. Support for changing deleted_on_termination after boot -Spec: https://review.openstack.org/#/c/580336/ - Weekly Progress: This has been added in backlog. Previously approved Spec needs to be re-proposed for Train: --------------------------------------------------------------------------- 1. Servers Ips non-unique network names : - https://blueprints.launchpad.net/nova/+spec/servers-ips-non-unique-network-… - https://review.openstack.org/#/q/topic:bp/servers-ips-non-unique-network-na… - I remember I planned this to re-propose but could not get time. If anyone would like to help on this please repropose. otherwise I will start this in U cycle. 2. Volume multiattach enhancements: - https://blueprints.launchpad.net/nova/+spec/volume-multiattach-enhancements - https://review.openstack.org/#/q/topic:bp/volume-multiattach-enhancements+(… - This also need volutneer - http://lists.openstack.org/pipermail/openstack-discuss/2019-June/007411.html Others: 1. Add API ref guideline for body text - 2 api-ref are left to fix. Bugs: ==== No progress report in this week. NOTE- There might be some bug which is not tagged as 'api' or 'api-ref', those are not in the above list. Tag such bugs so that we can keep our eyes. -gmann

1 0

[all] [tc] General questions on PDF community goal
by Akihiro Motoki 15 Aug '19

15 Aug '19

Hi, I have a couple of general questions on PDF community goal. What is the criteria of completing the PDF community goal? Is it okay if we publish a PDF deliverable anyway? During working on it, I hit the following questions. We already reached Train-2 milestone, so I think it is the time to clarify the detail criteria of completing the community goal. - Where should the generated PDF file to be located and What is the recommended PDF file name? <top directory>/<repository-name>.pdf? index.pdf? Any path and any file is okay? - Do we create a link to the PDF file from index.html (per-project top page)? If needed, perhaps this would be a thing covered by openstackdocstheme. Otherwise, how can normal consumers know PDF documents? - Which repositories need to provide PDF version of documents? My understanding (amotoki) is that repositories with 'publish-openstack-docs-pti' should publish PDF doc. right? - Do we need PDF version of release notes? - Do we need PDF version of API reference? I see no coordination efforts recently and am afraid that individual projects cannot decide whether patches to their repositories are okay to merge. Thanks, Akihiro Motoki (irc: amotoki)

3 2

[ansible][openstack-ansible][tripleo][kolla-ansible] Ansible SIG
by Mohammed Naser 15 Aug '19

15 Aug '19

Hi everyone, One of the things that came up recently was collaborating more with other deployment tools and this has brought up things like working together on our Ansible roles as more and more deployments tools start to use it. However, as we start to practice this, we realize that a project team ownership starts not making much sense (due to the fact that a project can only be under one team in governance). It starts being confusing when a role is built by OSA, and consumed by TripleO, so the PTL is from another team and it all starts getting weird and odd, so we discussed the creation of an Ansible SIG for those who are interested in maintaining code across our community together that would be consumed together. We already have some deliverables that can live underneath it which is pretty awesome too, so I'm emailing this to ask for interested parties to speak up if they're interested and to mention that we're more than happy to have other co-chairs that are intersted. I've submitted the initial patch here: https://review.opendev.org/676428 Thank you, Mohammed

2 2

neutron-server won't start in OpenStack OVN
by Zufar Dhiyaulhaq 15 Aug '19

15 Aug '19

Hi everyone, I try to install OpenStack with OVN enabled. But when trying to start neutron-server, the service is always inactive (exited) I try to check neutron-server logs and gets this message: 2019-08-14 05:40:32.649 4223 INFO networking_ovn.ml2.qos_driver [-] Starting OVNQosDriver 2019-08-14 05:40:32.651 4224 INFO networking_ovn.ovsdb.impl_idl_ovn [-] Getting OvsdbSbOvnIdl for MaintenanceWorker with retry 2019-08-14 05:40:32.654 4225 INFO ovsdbapp.backend.ovs_idl.vlog [-] tcp:10.101.101.10:6641: connecting... 2019-08-14 05:40:32.655 4225 INFO ovsdbapp.backend.ovs_idl.vlog [-] tcp:10.101.101.10:6641: connected 2019-08-14 05:40:32.657 4220 INFO ovsdbapp.backend.ovs_idl.vlog [-] tcp:10.101.101.10:6642: connecting... 2019-08-14 05:40:32.658 4220 INFO ovsdbapp.backend.ovs_idl.vlog [-] tcp:10.101.101.10:6642: connected 2019-08-14 05:40:32.660 4225 INFO networking_ovn.ovsdb.impl_idl_ovn [-] Getting OvsdbSbOvnIdl for AllServicesNeutronWorker with retry 2019-08-14 05:40:32.670 4220 INFO neutron.wsgi [-] (4220) wsgi starting up on http://0.0.0.0:9696 2019-08-14 05:40:32.692 4225 INFO ovsdbapp.backend.ovs_idl.vlog [-] tcp:10.101.101.10:6642: connecting... 2019-08-14 05:40:32.692 4225 INFO ovsdbapp.backend.ovs_idl.vlog [-] tcp:10.101.101.10:6642: connected 2019-08-14 05:40:32.693 4224 INFO ovsdbapp.backend.ovs_idl.vlog [-] tcp:10.101.101.10:6642: connecting... 2019-08-14 05:40:32.694 4224 INFO ovsdbapp.backend.ovs_idl.vlog [-] tcp:10.101.101.10:6642: connected 2019-08-14 05:40:32.697 4224 INFO networking_ovn.ml2.qos_driver [-] Starting OVNQosDriver 2019-08-14 05:40:32.844 4225 INFO oslo_service.service [-] Parent process has died unexpectedly, exiting 2019-08-14 05:40:32.844 4224 INFO oslo_service.service [-] Parent process has died unexpectedly, exiting 2019-08-14 05:40:32.844 4222 INFO oslo_service.service [-] Parent process has died unexpectedly, exiting 2019-08-14 05:40:32.845 4223 INFO oslo_service.service [-] Parent process has died unexpectedly, exiting 2019-08-14 05:40:32.845 4221 INFO oslo_service.service [-] Parent process has died unexpectedly, exiting neutron-server full logs: https://paste.ubuntu.com/p/GHfS38KFCr/ ovsdb-server port is active: https://paste.ubuntu.com/p/MhgNs8SGdX/ neutron.conf and ml2_conf.ini: https://paste.ubuntu.com/p/4J7hTVf5qz/ Does anyone know why this error happens? Best Regards, Zufar Dhiyaulhaq

2 2

creating instances, haproxy eats CPU, glance eats RAM
by Gregory Orange 15 Aug '19

15 Aug '19

Hi everyone, We have a Queens/Rocky environment with haproxy in front of most services. Recently we've found a problem when creating multiple instances (2 VCPUs, 6GB RAM) from large images. The behaviour is the same whether we use Horizon or Terraform, so I've continued on with Terraform since it's easier to repeat attempts. WORKS: 340MB image, create 80x instances, 40 at a time FAILS: 20GB image, create 40x instances, 20 at a time ... Changed haproxy config, added "balance roundrobin" to glance, cinder, nova, neutron stanzas (there was no 'balance' config before, not sure what it would have been doing) ... WORKS sometimes[1]: 20GB image, create 40x instances, 20 at a time FAILS: 20GB image, create 80x instances, 40 at a time The failure condition: * The active haproxy server has a single core go to 100% usage (the rest are idle) * One glance server's RAM usage grows rapidly and continuously * Some instances that are building complete * Creating new instances fails (BUILD state forever) * Horizon becomes unresponsive * Ceph and Cinder don't appear to be overloaded (ceph -s, logs, system state) * These states do not recover until we take the following actions... To recover: * Kill any remaining (Terraform) attempts to launch instances * Stop haproxy on the active server * Wait a few seconds * Start haproxy again [1] When we create enough to not quite overload it, haproxy server goes to 100% on one core but recovers once the instances are (slooowly) created. The cause of the problem is not clear (e.g. from haproxy and glance logs, system state), and I'm looking for pointers on where to look or what to try next. Can you help? Thank you, Greg.

2 4

[Telemetry][Shanghai Summit] Looking for Project Update session volunteers
by Trinh Nguyen 15 Aug '19

15 Aug '19

Hi team, I cannot attend the next summit in Shanghai so I'm looking for one-two volunteers who want to represent the Telemetry team at the summit. Please reply to this email by this Sunday and we will work through the presentation together. Bests, -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

2 1

[nova] Shanghai Project Update - Volunteer(s) needed
by Eric Fried 15 Aug '19

15 Aug '19

Hello Nova. Traditionally summit project updates are done by the PTL(s) of the foregoing and/or upcoming cycles. In this case, the former (that would be me) will not be attending the summit, and we don't yet know who the latter will be. So I am asking for a volunteer or two who is a) attending the summit [1], and b) willing [2] to deliver a Nova project update presentation. I (and others, I am sure) will be happy to help with slide content and other prep. Please respond ASAP so we can reserve a slot. Thanks, efried [1] it need not be definite at this point - obviously corporate, political, travel, and personal contingencies may interfere [2] blah blah, opportunity for exposure, yatta yatta, good experience, etc.

4 4

[release] Release countdown for week R-8, August 19-23
by Sean McGinnis 15 Aug '19

15 Aug '19

Your long awaited countdown email... Development Focus ----------------- It's probably a good time for teams to take stock of their library and client work that needs to be completed yet. The non-client library freeze is coming up, followed closely by the client lib freeze. Please plan accordingly to avoid any last minute rushes to get key functionality in. General Information ------------------- Looking ahead to Train-3, please be aware of the feature freeze dates. Those vary depending on deliverable type: * General libraries (except client libraries) need to have their last feature release before Non-client library freeze (September 05). Their stable branches are cut early. * Client libraries (think python-*client libraries) need to have their last feature release before Client library freeze (September 12) * Deliverables following a cycle-with-rc model (that would be most services) observe a Feature freeze on that same date, September 12. Any feature addition beyond that date should be discussed on the mailing-list and get PTL approval. * After feature freeze, cycle-with-rc deliverables need to produce a first release candidate (and a stable branch) before RC1 deadline (September 26) * Deliverables following cycle-with-intermediary model can release as necessary, but in all cases before Final RC deadline (October 10) Finally, now is a good time to list contributors to your team who do not have a code contribution, and therefore won't automatically be considered an Active Technical Contributor and allowed to vote in election. This is done by adding extra-atcs to: https://opendev.org/openstack/governance/src/branch/master/reference/projec… before the Extra-ATC freeze on August 29. Upcoming Deadlines & Dates -------------------------- Extra-ATC freeze: August 29 (R-7 week) Non-client library freeze: September 05 (R-6 week) Client library freeze: September 12 (R-5 week) Train-3 milestone: September 12 (R-5 week) -- Sean McGinnis (smcginnis)

1 0

August 14 Early Bird Registration Deadline - Open Infrastructure Summit Shanghai
by Kendall Waters 15 Aug '19

15 Aug '19

Hi everyone, Friendly reminder that today, August 14, at 11:59pm PT (August 15 at 2:59pm China Standard Time) is the deadline to purchase passes for the Open Infrastructure Summit at the early bird price. Register now before the prices increase! There are 2 ways to register - in USD <https://app.eventxtra.link/registrations/6640a923-98d7-44c7-a623-1e2c9132b4…> or in RMB (with e-fapiao) <https://app.eventxtra.link/registrations/f564960c-74f6-452d-b0b2-484386d33e…>. In case you missed it, the agenda <https://www.openstack.org/summit/shanghai-2019/summit-schedule> went live last week and features sessions covering CI/CD, Edge Computing, 5G, hybrid cloud, and more. Other Summit News If you require a visa to travel to China, please apply here Hiring talent to build your open infrastructure strategy? Have a new product to share? Join the Summit as as sponsor If you have any questions, please email summit(a)openstack.org <mailto:summit@openstack.org>. Cheers, Kendall Kendall Waters OpenStack Marketing & Events kendall(a)openstack.org

1 0

[tripleo] TripleO CI Summary: Sprint 34
by Rafael Folco 14 Aug '19

14 Aug '19

Greetings, The TripleO CI team has just completed Sprint 34 / Unified Sprint 13 (Jul 18 thru Aug 07). The following is a summary of completed work during this sprint cycle: - Created RHEL8 jobs to build a periodic pipeline in the RDO Software Factory and provide early feedback for CentOS8 coverage. - Fixed RHEL8 container and image build jobs in the periodic pipeline. - Bootstrapped RHEL8 standalone job and made progress on RHEL8 OVB featureset 001 job. - Completed scenario007 and featureset039 job updates upstream. - Promotion status: red on all branches at half of the sprint due to rhel8 changes and infra related issues (transient failures). - Disabled Fedora jobs from periodic pipeline. - Merged code for automatic creation of featureset matrix on TripleO quickstart documentation [3]. The planned work for the next sprint [1] are: - Create scenario1-4 jobs for RHEL8 in the periodic pipeline. - Design and test multi-arch container support. - Resume the design work for a staging environment to test changes in the promoter server for the multi-arch builds. - Continue OVB featureset001 bootstrapping on RHEL8. - Disable Fedora jobs upstream. The Ruck and Rover for this sprint are Chandan Kumar (chkumar) and Ronelle Landy (rlandy). Please direct questions or queries to them regarding CI status or issues in #tripleo, ideally to whomever has the ‘|ruck’ suffix on their nick. Ruck/rover notes are being tracked in etherpad [2]. Thanks, rfolco [1] https://tree.taiga.io/project/tripleo-ci-board/taskboard/unified-sprint-14 [2] https://etherpad.openstack.org/p/ruckroversprint14 [3] https://docs.openstack.org/tripleo-quickstart/latest/feature-configuration.…

1 0

[nova][stacktach]
by Blom, Merlin, NMU-OI 14 Aug '19

14 Aug '19

Hey, it anybody using stacktach with OpenStack Nova Stein? I can't stream messages to it via Nova: -> stacktach_worker_config.json {"deployments": [ { "name": "xxx.dev", "durable_queue": false, "rabbit_host": "10.x.x.x", "rabbit_port": 5672, "rabbit_userid": "nova", "rabbit_password": "xxx", "rabbit_virtual_host": "/nova", "exit_on_exception": true, "topics": { "nova": [ { "queue": "notification.info", "routing_key": "notification.info" }, { "queue": "monitor.error", "routing_key": "monitor.error" } . How do you configure it? Are there alternatives for reading RabbitMQ Messages for debug/billing purposes? Greetings, Merlin Blom

1 0

[os-acc] os-acc will be retired as a project
by Nadathur, Sundar 14 Aug '19

14 Aug '19

A project called os-acc [1] was created in Stein cycle based on an expectation that it will be used for Cyborg - Nova integration. It is not relevant anymore and we have no plans to support it in Train. We are discontinuing it with immediate effect. It was never used and had no developer base to speak of. So, we do not see any issues or impact for anybody. [1] https://opendev.org/openstack/os-acc/ Regards, Sundar

1 0

[cyborg] Poll for new weekly IRC meeting time
by Nadathur, Sundar 14 Aug '19

14 Aug '19

The current Cyborg weekly IRC meeting time [1] is a conflict for many. We are looking for a better time that works for more people, with the understanding that no time is perfect for all. Please fill out this poll: https://doodle.com/poll/6t279f9y6msztz7x Be sure to indicate which times do not work for you. You can propose a new timeslot beyond what I included in the poll. [1] https://wiki.openstack.org/wiki/Meetings/CyborgTeamMeeting#Weekly_IRC_Cybor… Regards, Sundar

1 1

[Watcher] team meeting at 08:00 UTC today
by li.canwei2＠zte.com.cn 14 Aug '19

14 Aug '19

Hi team, Watcher team will have a meeting at 08:00 UTC today in the #openstack-meeting-alt channel. The agenda is available on https://wiki.openstack.org/wiki/Watcher_Meeting_Agenda feel free to add any additional items. Thanks! Canwei Li

1 0

Re: [lists.openstack.org代发]Re: [nova] Shanghai Project Update - Volunteer(s) needed
by Brin Zhang(张百林) 14 Aug '19

14 Aug '19

> I apply the second one. I can also provide some help if there is a need. Stephen Finucane <sfinucan(a)redhat.com<mailto:sfinucan@redhat.com>> 于2019年8月14日周三上午5:25写道： On Tue, 2019-08-13 at 15:20 -0500, Eric Fried wrote: > Hello Nova. > > Traditionally summit project updates are done by the PTL(s) of the > foregoing and/or upcoming cycles. In this case, the former (that would > be me) will not be attending the summit, and we don't yet know who the > latter will be. > > So I am asking for a volunteer or two who is a) attending the summit > [1], and b) willing [2] to deliver a Nova project update presentation. I > (and others, I am sure) will be happy to help with slide content and > other prep. Unless someone else wants to do it, I think I can probably do it. Stephen > Please respond ASAP so we can reserve a slot. > > Thanks, > efried > > [1] it need not be definite at this point - obviously corporate, > political, travel, and personal contingencies may interfere > [2] blah blah, opportunity for exposure, yatta yatta, good experience, etc. >

1 0

reply: [lists.openstack.org][nova] The race for 2.76
by Brin Zhang(张百林) 14 Aug '19

14 Aug '19

> There are several compute API microversion changes that are conflicting and will be fighting for 2.76, but I think we're trying to prioritize this one [1] for the ironic > power sync external event handling since (1) Surya is going to be on vacation soon, (2) there is an ironic change that depends on it which has had review [2] and (3) > the nova change has had quite a bit of review already. > As such I think others waiting to rebase from 2.75 to 2.76 should probably hold off until [1] is approved which should happen today or tomorrow. > > [1] https://review.opendev.org/#/c/645611/ > [2] https://review.opendev.org/#/c/664842/ > > -- > > Thanks, > > Matt Agree with Matt. It is recommended to speed up the review of the patches on nova-runway [1]. I found that it has accumulated a lot, and some of them are difficult to complete in one cycle. [1] https://etherpad.openstack.org/p/nova-runways-train

1 0

OpenStack 14 CentOS and Nvidia driver for vgpu?
by Piotr Baranowski 14 Aug '19

14 Aug '19

Hello list, I'm struggling deploying Rocky with vGPU using nvidia drivers. Has anyone experienced the issues loading nvidia modules? I'm talking about hypervisor part of the setup. There are two modules provided by nvidia. One loads correctly it's the nvidia.ko one. The other however does not. The module is called nvidia-vgpu-vfio.ko I'm trying to load it and it seems that 7.6 kernel is no longer compatible with it modprobe nvidia-vgpu-vfio modprobe: ERROR: could not insert 'nvidia_vgpu_vfio': Invalid argument dmesg shows this: nvidia_vgpu_vfio: disagrees about version of symbol vfio_pin_pages nvidia_vgpu_vfio: Unknown symbol vfio_pin_pages (err -22) nvidia_vgpu_vfio: disagrees about version of symbol vfio_unpin_pages nvidia_vgpu_vfio: Unknown symbol vfio_unpin_pages (err -22) nvidia_vgpu_vfio: disagrees about version of symbol vfio_register_notifier nvidia_vgpu_vfio: Unknown symbol vfio_register_notifier (err -22) nvidia_vgpu_vfio: disagrees about version of symbol vfio_unregister_notifier nvidia_vgpu_vfio: Unknown symbol vfio_unregister_notifier (err -22) modinfo nvidia-vgpu-vfio filename: /lib/modules/3.10.0-957.27.2.el7.x86_64/weak-updates/nvidia-vgpu-vfio.ko version: 430.27 supported: external license: MIT rhelversion: 7.6 srcversion: 0A179A61A02AD500D05FB1A alias: pci:v000010DEd00000E00sv*sd*bc04sc80i00* alias: pci:v000010DEd*sv*sd*bc03sc02i00* alias: pci:v000010DEd*sv*sd*bc03sc00i00* depends: nvidia,mdev,vfio vermagic: 3.10.0-940.el7.x86_64 SMP mod_unload modversions My guess is that somewhere along the rhel/centos 7.6 lifecycle vfio module changed the vfio module and broke the compatibility. Nvidia provides those modules built against the BETA 7.6 release and assume weak-modules to make it work. Somehow it does not. Anybody got any suggestions how to handle this? I'm working on it with nvidia enterprise support but maybe one of you got there first? best regards -- Piotr Baranowski

1 0

[tc] meeting summary for aug. 8 2019
by Mohammed Naser 13 Aug '19

13 Aug '19

Hi everyone, The TC held it’s monthly meeting on the 8th of August 2019 and this email provides a summary of that meeting Jeremy Stanley (fungi) was added as TC Liaison for the Image Encryption pop-up team and their proposed resolution on proper retirement procedures was approved and merged. Swift is now working in Python 3 and inside DevStack so this puts us in a really good place to continue with Python 3 efforts in Swift. Graham Hayes (mugsie) is currently working on the code for the proposal bot so that when we cut a branch, it automatically pushes up a patch to add the ‘python3 jobs’ for that series. Thierry Carrez (ttx) organized the milestone 2 forum meeting with TC members. We have Jim Rollenhagen (jroll) and maybe Graham Hayes (mugsie) volunteering for the programming committee. The proposal for making goal selection a two-step process has been needing reviews for a while so I encourage the community to have a look at it as well as other TC members. We also talked about who’s attending the Shanghai Summit (here’s the Etherpad with the list of who’s going: https://etherpad.openstack.org/p/PVG-TC-PTG) and who will be attending the leadership meeting. We think that everybody already on the TC going to PTG will be there but we’ll only be able to know the exact number at the end of the election, so towards the end of September. We’re also thinking about starting a “Large Scale” SIG so people could collaborate in tackling more of the scaling issues together. Thierry Carrez (ttx) and I will be looking into that by mentioning the idea to LINE and YahooJapan (as some perspective at-scale operators)to see what they think and also make a list of organizations that could be interested. Rico Lin (ricolin) will also update the SIG guidelines documents to make the whole process easier and Jim Rollenhagen (jroll) will try and bring this up at Verizon Media. Finally, we talked about an issue regarding CI Maintainers associated with Cinder not maintaining their systems by not migrating them to Python 3.7. Half of those drivers will be deprecated since they still run on Python 2.7, which won’t be supported by the next ‘U’ release. Jay Bryant tried contacting them all individually but most didn’t answer (a lot of contact info isn’t up to date). If you know someone who maintains a Cinder driver in-tree, please have them double-check on this. I hope that I covered most of what we discussed, for the full meeting logs, you can find them here: http://eavesdrop.openstack.org/meetings/tc/2019/tc.2019-08-08-14.00.log.html Thanks for tuning in! Regards, Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

4 4

[ptl][release] Stepping down as Release Management PTL
by Tony Breeds 13 Aug '19

13 Aug '19

Hello all, I'm sorry to say that I have insufficient time and resources to dedicate to being the kind of PTL the community deserves. With that in mind I've asked if Sean has the time to see out the role for the remainder of the Train cycle and he's agreed. I have proposed https://review.opendev.org/675246 up update the governance repo. I'm not going any where but instead trying to take on less and do *that* better. Yours Tony.

6 9