- openstack-discuss - lists.openstack.org

[dev][nova] Yay Friday gate regressions!
by Matt Riedemann 01 Dec '18

01 Dec '18

Just FYI there are a couple of regressions hitting nova unit and functional test jobs right now: https://bugs.launchpad.net/nova/+bug/1806123 ^ Is likely due to mocking a global for the new I/O concurrency semaphore stuff in the libvirt driver. I'm not sure what we should do about that one. During the code review I suggested writing a fixture which would essentially maintain the context manager (so we have __enter__ and __exit__) but just make it a noop, but we still want to make sure it's called in places where it's used. https://bugs.launchpad.net/nova/+bug/1806126 ^ Is a bit hairier since I'm seeing both weird, potentially global mock, failures and also timeouts, also potentially because of mocking globals. Since there is no functional code change tied to that one yet (it's still being reviewed, this was a recreate test change only), I have proposed a revert to try and stem the bleeding unless someone (mdbooth?) can root cause and fix it faster. Happy rechecking! -- Thanks, Matt

2 1

[senlin] New meeting time for odd weeks
by Duc Truong 30 Nov '18

30 Nov '18

As discussed in our last Senlin meeting [1], I would like to propose holding the weekly meeting during odd weeks at a time that is more convenient for US and Europe. The proposal is to have the meeting at 19:00 UTC (11am PST) for odd weeks, while the meeting time for even weeks stays at the current time of 5:30 UTC. If accepted, the meeting times for upcoming weeks would be as follows: - Thursday, December 6, 2018 at 19:00:00 UTC - Friday, December 14, 2018 at 05:30:00 UTC - Thursday, December 20, 2018 at 19:00:00 UTC ... Please reply with any feedback. Regards, Duc (dtruong) [1] http://eavesdrop.openstack.org/meetings/senlin/2018/senlin.2018-11-30-05.30…

1 0

[openstack-dev] [nova] Would an api option to create an instance without powering on be useful?
by Matthew Booth 30 Nov '18

30 Nov '18

I have a request to do $SUBJECT in relation to a V2V workflow. The use case here is conversion of a VM/Physical which was previously powered off. We want to move its data, but we don't want to be powering on stuff which wasn't previously on. This would involve an api change, and a hopefully very small change in drivers to support it. Technically I don't see it as an issue. However, is it a change we'd be willing to accept? Is there any good reason not to do this? Are there any less esoteric workflows which might use this feature? Matt -- Matthew Booth Red Hat OpenStack Engineer, Compute DFG Phone: +442070094448 (UK) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

5 4

[tripleo] Expose healthchecks via systemd for podman
by Jill Rouleau 30 Nov '18

30 Nov '18

The healthchecks currently in use in tripleo depend on the the docker healthcheck implementation, so podman/oci containers will not expose them. The /openstack/healthcheck script is still available in the images, we just need a way to run the checks and expose the result. https://review.openstack.org/#/c/620372/ proposes having paunch write out a $service-healthcheck systemd unit and corresponding timer. Interested in what folks think about the approach. -Jill

2 2

[openstack-dev][tripleo] TripleO CI Summary: Sprint 22
by Rafael Folco 30 Nov '18

30 Nov '18

Greetings, The TripleO CI team has just completed Sprint 22 (Nov 08 thru Nov 28). The following is a summary of completed work during this sprint cycle: - Converted multinode scenarios(1-4) to standalone job. This effort will allow us to replace multinode scenario jobs that are consuming most of upstream resources. Replacement of multinode scenario jobs is starting immediately and should be complete by Jan 2019. - Improved python and ansible support on Fedora 28 job, which is successfully deploying TripleO, but still requires further work on Tempest packaging before becoming a voting job. This is the first step in using upstream CI to validate python3 and RHEL8 work. - Investigated alternative solutions for the reproducer to approximate with the zuulv3 workflow. A PoC has been developed to run Zuul in a container as the reproducer script for TripleO CI. - Tested a new CI environment for OVB jobs on RDO cloud. Experiments for refectoring ovb deployment to be incorporated into CI code without te-broker bits. - https://tree.taiga.io/project/tripleo-ci-board/epic/298 - Initial testing of CentOS 7.6 looks good - https://tree.taiga.io/project/tripleo-ci-board/issue/309?kanban-status=2027… The sprint task board for CI team is tracked on Taiga [1] and the Ruck and Rover notes for this sprint has been tracked in the etherpad [2]. The planned work for the next sprint focuses in completing the upstream standalone job for Fedora 28 by eliminating all related issues. It also includes moving the multinode scenarios to the standalone jobs that has started in the previous sprint. The team continues to work on the reproducer and preparing a CI environment for OVB. The only new item for the sprint is to start building the production pipeline promotion jobs for Fedora 28. The Ruck and Rover for this sprint are Marios Andreou (marios) and Sorin Sbarnea (ssbarnea). Please direct questions or queries to them regarding CI status or issues in #tripleo, ideally to whomever has the ‘|ruck’ suffix on their nick. Thanks, Folco [1] https://tree.taiga.io/project/tripleo-ci-board/taskboard/sprint-23unified-s… [2] https://review.rdoproject.org/etherpad/p/ruckrover-sprint22 -- Rafael Folco Senior Software Engineer

1 0

[placement] update 18-48
by Chris Dent 30 Nov '18

30 Nov '18

HTML: https://anticdent.org/placement-update-18-48.html Here's a placement update. It's been a rather busy week in placement-land: Gibi and I, with the help of others, have been getting the functional tests in nova working with an external placement. It is working now, which is great, but much work was done, more details within. # Most Important Progress continues on the work in ansible, puppet/tripleo, kolla, loci to package placement up and establish upgrade processes. All of these things need review (see below). Work on GPU reshaping in virt drivers is getting close. # What's Changed * Devstack installs placement from openstack/placement, not nova. * Placement now runs tempest and grenade (in py3) in CI. This is great because real integration tests and sad because our once really fast CI runs are gone. * The placement service can now start without a conf file. This is basically fixing a bug: we required a single config file in a specific location, rather than the defaults (which includes no file). We require an explicit database connection. # Bugs * Placement related [bugs not yet in progress](https://goo.gl/TgiPXb): 19. +2. * [In progress placement bugs](https://goo.gl/vzGGDQ) 14. +1 # Specs Spec freeze is milestone 2, the week of January 7th. None of the specs listed last week have merged. * <https://review.openstack.org/#/c/544683/> Account for host agg allocation ratio in placement (Still in rocky/) * <https://review.openstack.org/#/c/595236/> Add subtree filter for GET /resource_providers * <https://review.openstack.org/#/c/597601/> Resource provider - request group mapping in allocation candidate * <https://review.openstack.org/#/c/549067/> VMware: place instances on resource pool (still in rocky/) * <https://review.openstack.org/#/c/555081/> Standardize CPU resource tracking * <https://review.openstack.org/#/c/599957/> Allow overcommit of dedicated CPU (Has an alternative which changes allocations to a float) * <https://review.openstack.org/#/c/591037/> Modelling passthrough devices for report to placement * <https://review.openstack.org/#/c/603955/> Nova Cyborg interaction specification. * <https://review.openstack.org/#/c/601596/> supporting virtual NVDIMM devices * <https://review.openstack.org/#/c/603352/> Spec: Support filtering by forbidden aggregate * <https://review.openstack.org/#/c/552924/> Proposes NUMA topology with RPs * <https://review.openstack.org/#/c/569011/> Count quota based on resource class * <https://review.openstack.org/#/c/141219/> Adds spec for instance live resize * <https://review.openstack.org/#/c/612497/> Provider config YAML file * <https://review.openstack.org/#/c/509042/> Propose counting quota usage from placement and API database * <https://review.openstack.org/603545> Resource modeling in cyborg. * <https://review.openstack.org/#/c/609960/> Support filtering of allocation_candidates by forbidden aggregates # Main Themes ## Making Nested Useful Progress is being made on gpu-reshaping for libvirt and xen: * <https://review.openstack.org/#/q/topic:bp/reshape-provider-tree+status:open> Also making use of nested is bandwidth-resource-provider: * <https://review.openstack.org/#/q/topic:bp/bandwidth-resource-provider> Eric's in the process of doing lots of cleanups to how often the ProviderTree in the resource tracker is checked against placement, and a variety of other "let's make this more right" changes in the same neighborhood: * Stack at: <https://review.openstack.org/#/c/615646/> ## Extraction (There's an [etherpad](https://etherpad.openstack.org/p/placement-extract-stein-4) which tracks some of the work related to extraction. Please refer to that for additional information.) Several deployment tools are working on making things work with the extracted placement: * [TripleO](https://review.openstack.org/#/q/topic:tripleo-placement-extractio… * [OpenStack Ansible](https://review.openstack.org/#/q/project:openstack/openstack-ansib… * [Kolla](https://review.openstack.org/#/c/613589/) * [Kolla Ansible](https://review.openstack.org/#/c/613629/) * [Loci](https://review.openstack.org/#/c/617273/) A replacement for `placeload` performance testing that was in the `nova-next` job: <https://review.openstack.org/#/c/619248/>. This might be of interest to people trying to do testing of live services without devstack. It starts with a basic node, turns on mysql, runs placement with uwsgi, and does the placeload testing. Note that this found a pretty strange [bug in _ensure_aggregates](https://bugs.launchpad.net/nova/+bug/1804453). Documentation tuneups: * Release-notes: <https://review.openstack.org/#/c/618708/> This is blocked until we refactor the release notes to reflect _now_ better. * The main remaining task here is participating in [openstack-manuals](https://docs.openstack.org/doc-contrib-guide/doc-index.h…. **The functional tests in nova** excitement this week has led to some interesting changes. The biggest of these is changing placement to [no longer use global config](https://review.openstack.org/#/c/619121/). That patch is an aggregate of the many things done to remove a race condition in the [nova functional tests](https://review.openstack.org/#/c/617941/). Trying to use the config of two different projects in the same process space is hard if they are both global. So now placement doesn't. This is a win in many ways. Getting those two patches merged _soon_ is important. We've been putting off making a decision about os-resource-classes. Anyone have strong opinions? # Other There are 12 or so [open changes](https://review.openstack.org/#/q/status:open+project:openstack/pla… in placement itself. Of those these two are the most important: * <https://review.openstack.org/#/c/619121/> Stop using global oslo_config * <https://review.openstack.org/#/c/614559/> Correct lower-constraints.txt and the related tox job Outside of placement itself, here are some related changes: * <https://review.openstack.org/#/q/topic:bp/initial-allocation-ratios> Improve handling of default allocation ratios * <https://review.openstack.org/#/q/topic:minimum-bandwidth-allocation-placeme…> Neutron minimum bandwidth implementation * <https://review.openstack.org/#/c/602160/> Add OWNERSHIP $SERVICE traits * <https://review.openstack.org/#/c/586960/> zun: Use placement for unified resource management * <https://review.openstack.org/#/q/project:openstack/blazar+topic:bp/placemen…> Blazar using the placement-api * <https://review.openstack.org/619626> Tenks doing some node management, with a bit of optional placement. * <https://review.openstack.org/#/c/620485/> Sync placement database to the current version (in grenade) * <https://review.openstack.org/#/c/619107/> Address nits on lib/placement for extracted placement (in devstack) # End That was the November that was. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

2 1

Horizon Logging Question
by sam.bouwari＠verizon.com 30 Nov '18

30 Nov '18

Hello Horizon Proj Developers. In previous (older) Openstack/Horizon versions (version 7 or 8), the /var/log/horizon.log file used to reveal "remote address" information when a user attempts to login to Horizon GUI with wrong password, or if someone is trying to guess a password, then a log entry similar to this would be logged: 2018-11-01 19:39:35,728 3711 WARNING openstack_auth.forms Login failed for user "admin", remote address 192.168.1.12. In newer OSP/Horizon versions, the "remote address" field seems to have been truncated from the log and all we see now is a login entry in /var/log/horizon.log similar to this: 2018-11-30 14:23:10,912 473292 WARNING openstack_auth.forms Login failed for user "admin". Is there any valid reason as to why this feature was removed from newer version of Horizon? Logging the "remote address" information is very useful from security/IR and log monitoring standpoint where an analyst can identify if someone is trying to guess passwords, or trying to brute force the Horizon GUI, and other useful scenarios. Is there a configuration parameter in Horizon that can be turned on to log the "remote address" infromation again? Or is this feature just not available anymore in the product? Your help is greatly appreciated! Thanks Sam Bouwari

1 0

[dev][keystone]
by Colleen Murphy 30 Nov '18

30 Nov '18

# Keystone Team Update - Week of 26 November 2018 ## News ### Forum Recap Two weeks ago some of us attended the OpenStack Summit in Berlin, where we had a couple of keystone-specific sessions and had some discussions with Edge computing operators and public cloud operators about keystone use cases. Lance wrote up a recap[1]. [1] https://www.lbragstad.com/blog/openstack-summit-berlin-recap ### Refreshable application credentials We had a short discussion on how refreshable application credentials will be implemented[2]. The summary is that new fields should be added to the existing model, renewed_at and renewable_roles. We had discussed adding a new expiration field or reusing the existing expiration field, but decided that for the refresh use case, application credentials shouldn't be using expiration but instead a static comparison of the last refresh time and a configurable TTL tied to the IdP. The existing expiration field will remain user-configurable. [2] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-k… ## Open Specs Stein specs: https://bit.ly/2Pi6dGj Ongoing specs: https://bit.ly/2OyDLTh The JWT spec[3] and the domain support for limits spec[4] are ready to go, please have a look. There are also several specs not proposed for Stein but instead proposed as "ongoing" that need reviews. [3] https://review.openstack.org/541903 [4] https://review.openstack.org/599491 ## Recently Merged Changes Search query: https://bit.ly/2pquOwT We merged 20 changes this week. ## Changes that need Attention Search query: https://bit.ly/2RLApdA There are 82 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. Most of them are from Lance to incorporate our new default roles into our own policies. ## Bugs This week we opened 14 new bugs and closed 4. Bugs opened (14) Bug #1805400 (keystone:High) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1805400 Bug #1805363 (keystone:Medium) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1805363 Bug #1805366 (keystone:Medium) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1805366 Bug #1805368 (keystone:Medium) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1805368 Bug #1805369 (keystone:Medium) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1805369 Bug #1805371 (keystone:Medium) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1805371 Bug #1805372 (keystone:Medium) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1805372 Bug #1805402 (keystone:Medium) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1805402 Bug #1805403 (keystone:Medium) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1805403 Bug #1805406 (keystone:Medium) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1805406 Bug #1805880 (keystone:Medium) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1805880 Bug #1805409 (keystone:Wishlist) opened by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1805409 Bug #1805165 (keystone:Undecided) opened by Boris Bobrov https://bugs.launchpad.net/keystone/+bug/1805165 Bug #1805817 (keystone:Undecided) opened by Robert Duncan https://bugs.launchpad.net/keystone/+bug/1805817 Bugs fixed (4) Bug #1735250 (keystone:High) fixed by wangxiyuan https://bugs.launchpad.net/keystone/+bug/1735250 Bug #1792026 (keystone:Medium) fixed by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1792026 Bug #1781536 (keystone:Low) fixed by Gage Hugo https://bugs.launchpad.net/keystone/+bug/1781536 Bug #1802357 (oslo.policy:Undecided) fixed by no one https://bugs.launchpad.net/oslo.policy/+bug/1802357 ## Milestone Outlook https://releases.openstack.org/stein/schedule.html There is just over a month left until the Stein spec freeze. Please have a look at the currently proposed specs for Stein. ## Shout-outs Thanks Jens Harbott for helping us out with our Zuul job issues[5][6]! [5] https://review.openstack.org/611563 [6] https://review.openstack.org/620553 ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter Dashboard generated using gerrit-dash-creator and https://gist.github.com/lbragstad/9b0477289177743d1ebfc276d1697b67

1 1

Re: [Openstack] [Pike][Neutron] L3 metering with DVR doesn't work
by Alexandru Sorodoc 30 Nov '18

30 Nov '18

Hello Brian, Thanks for the info. I looked into the code for the metering agent and discovered the following: 1. The metering agent on compute nodes doesn't get notified about DVR routers running on the node. 2. For DVR routers it tries to meter the rfp- interface(for floating ips) on the snat- namespace. This is wrong. The rfp- interface lies on the qrouter- namespace on compute nodes. Also, there is a qg- interface on the snat- namespace on network nodes (for performing NAT) which should be metered too. 3. There is a race condition whereby the metering agent is notified about a router before its namespaces are created. The agent ends up not adding the metering rules for those namespaces and this leads to unrecorded traffic. I addressed those issues in a change: https://review.openstack.org/#/c/621165/. Any feedback is appreciated. Best regards, Alex On 26/10/2018 21:49, Brian Haley wrote: > On 10/25/2018 08:06 AM, Alexandru Sorodoc wrote: >> Hello, >> >> I'm trying to set up metering for neutron in Pike. I tested it with a >> centralized router and it works, but when I try with a distributed >> router it >> doesn't record any usage samples. I have one compute node and one >> network node >> and I've created an instance with a floating ip. > > The metering agent isn't very well maintained, and I don't see any > open bugs similar to this issue. The only thing I can remember is > this abandoned change regarding traffic counters for DVR routers - > https://review.openstack.org/#/c/486493/ but there was no follow-on > from the author. > > The best thing to do would be to try and reproduce it on the master > branch (or Rocky) and file a bug. > > > I think this is because the router is running on network1. Why is it > > running on > > network1 and why does it seem that the l3 agent on compute1 does the > actual > > routing? > > The compute node will do all the routing when a floating IP is > associated, the router on network1 is for default snat traffic when > there is no floating IP and the instance tries to communicate out the > external network. > > -Brian > >> >> openstack router show public-router2 >> +-------------------------+----------------------------------------------------+ >> >> | Field | >> Value | >> +-------------------------+----------------------------------------------------+ >> >> | admin_state_up | >> UP | >> | availability_zone_hints >> | | >> | availability_zones | >> nova | >> | created_at | >> 2018-10-05T12:07:32Z | >> | description | | >> | distributed | >> True | >> | external_gateway_info | {"network_id": >> "b96473ce- | >> | | 94f6-464f-a703-5285fb8ff3d3", >> "enable_snat": true, | >> | | "external_fixed_ips": >> [{"subnet_id": | >> | | >> "6c08c3d9-7df1-4bec-b847-19f80b9d1764", | >> | | "ip_address": >> "192.168.252.102"}]} | >> | flavor_id | >> None | >> | ha | >> False | >> | id | >> 37c1794b-58d1-4d0d-b34b-944ca411b86b | >> | name | >> public-router2 | >> | project_id | >> fe203109e67f4e39b066c9529f9fc35d | >> | revision_number | >> 5 | >> | routes | | >> | status | >> ACTIVE | >> | tags | | >> | updated_at | >> 2018-10-05T12:09:36Z | >> +-------------------------+----------------------------------------------------+ >> >> >> openstack network agent list >> +-----------+------------+-----------+-------------------+-------+-------+--------------+ >> >> | ID | Agent Type | Host | Availability Zone | Alive | >> State | Binary | >> +-----------+------------+-----------+-------------------+-------+-------+--------------+ >> >> | 14b9ea75- | L3 agent | compute1. | nova | :-) | UP | >> neutron-l3-a | >> | 1dc1-4e37 | | localdoma | | | | gent | >> | -a2b0-508 | | in | | | | | >> | 3d336916d | | | | | | | >> | 26139ec1- | Metering | compute1. | None | :-) | UP | >> neutron- | >> | f4f9-4bb3 | agent | localdoma | | | | metering- | >> | -aebb-c35 | | in | | | | agent | >> | 3a36ed79c | | | | | | | >> | 2a54971f- | DHCP agent | network1. | nova | :-) | UP | >> neutron- | >> | 9849-4ed2 | | localdoma | | | | dhcp-agent | >> | -b009-00e | | in | | | | | >> | 45eb4d255 | | | | | | | >> | 443c0b49- | Open | compute1. | None | :-) | UP | >> neutron- | >> | 4484-44d2 | vSwitch | localdoma | | | | openvswitch- | >> | -a704-32a | agent | in | | | | agent | >> | 92ffe6982 | | | | | | | >> | 5d00a219 | L3 agent | network1. | nova | :-) | UP | >> neutron-vpn- | >> | -abce- | | localdoma | | | | agent | >> | 48ca- | | in | | | | | >> | ba1e-d962 | | | | | | | >> | 01bd7de3 | | | | | | | >> | bc3458b4 | Open | network1. | None | :-) | UP | >> neutron- | >> | -250e- | vSwitch | localdoma | | | | openvswitch- | >> | 4adf-90e0 | agent | in | | | | agent | >> | -110a1a7f | | | | | | | >> | 6ccb | | | | | | | >> | c29f9da8- | Metering | network1. | None | :-) | UP | >> neutron- | >> | ca58-4a11 | agent | localdoma | | | | metering- | >> | -b500-a25 | | in | | | | agent | >> | 3f820808e | | | | | | | >> | cdce667d- | Metadata | network1. | None | :-) | UP | >> neutron- | >> | faa4 | agent | localdoma | | | | metadata- | >> | -49ed- | | in | | | | agent | >> | 83ee-e0e5 | | | | | | | >> | a352d482 | | | | | | | >> | cf5ae104- | Metadata | compute1. | None | :-) | UP | >> neutron- | >> | 49d7-4c85 | agent | localdoma | | | | metadata- | >> | -a252-cc5 | | in | | | | agent | >> | 9a9a12789 | | | | | | | >> +-----------+------------+-----------+-------------------+-------+-------+--------------+ >> >> >> If I check the node on which my distributed router is running it >> tells me that >> it's running on the network node: >> >> neutron l3-agent-list-hosting-router >> 37c1794b-58d1-4d0d-b34b-944ca411b86b >> +--------------------------------------+----------------------+----------------+-------+----------+ >> >> | id | host | >> admin_state_up | alive | ha_state | >> +--------------------------------------+----------------------+----------------+-------+----------+ >> >> | 5d00a219-abce-48ca-ba1e-d96201bd7de3 | network1.localdomain | >> True | :-) | | >> +--------------------------------------+----------------------+----------------+-------+----------+ >> >> >> If I check the iptable rules for the router on the compute and >> network nodes by running: >> >> ip netns exec qrouter-37c1794b-58d1-4d0d-b34b-944ca411b86b iptables >> -nv -L >> >> I see that compute1 records the traffic while network1 doesn't. Also, >> I did some >> debugging and found out that the metering agent on compute1 receives >> an empty >> list of routers when querying the routers that it should monitor. >> >> Source: >> >> https://github.com/openstack/neutron/blob/stable/pike/neutron/services/mete… >> >> >> https://github.com/openstack/neutron/blob/stable/pike/neutron/db/metering/m… >> >> >> I think this is because the router is running on network1. Why is it >> running on >> network1 and why does it seem that the l3 agent on compute1 does the >> actual >> routing? >> >> Thanks, >> Alex >> >> >> >> _______________________________________________ >> Mailing list: >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >> Post to : openstack(a)lists.openstack.org >> Unsubscribe : >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >> > _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack(a)lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

1 0

[oslo][nova][stable][requirements] Fixing a high CPU usage from oslo.service into stable/rocky branch
by Herve Beraud 30 Nov '18

30 Nov '18

Hey all! Here is a thread to coordinate all the teams (oslo, nova, stable, requirements) working on the update of the oslo.service constraint in the Rocky requirements. # Summary Usage of threading event with eventlet caused inefficient code (causing many useless system calls and high CPU usage). This issue was already fixed on oslo.service master and we also want to fix it in stable/rocky. Our main issue is how to fix the high CPU usage on stable/rocky without break the nova CI. Indeed, we already have backported the eventlet related fix to oslo.service but this fix requires also a nova update to avoid nova CI errors due to threading removal on oslo.service that introduce the nova CI errors. A fix was proposed and merged on oslo.service master to introduce a new feature (fixture) that avoid the nova CI errors, but backporting the master fix to Rocky introduces a new feature into a stable branch so this is also an issue. So we need to discuss with all the teams to find a proper solution. # History A few weeks ago this issue was opened on oslo.service ( https://bugs.launchpad.net/oslo.service/+bug/1798774) and it was fixed by this submited patch on the master branch ( https://review.openstack.org/#/c/611807/ ). This change use the proper event primitive to fix the performance issue. A new version of oslo.service was released (1.32.1) Since these changes was introduced into oslo.service master, nova facing some issues into the master CI process, due to the threading changes, and they was fixed by these patches ( https://review.openstack.org/#/c/615724/, https://review.openstack.org/#/c/617989/ ) into master. Few weeks ago I have backport to oslo.service some changes ( https://review.openstack.org/#/c/614489/ ) from master to stable/rocky to also fix the problem in the rocky release. When this backport was merged we have created a new release of oslo.service (1.31.6) ( https://review.openstack.org/#/c/616505/ ) (stable/rocky version). Then the openstack proposal bot submit a patch to requirements on stable rocky to update the oslo.service version with the latest version (1.31.6) but if we'll use it we'll then break the CI https://review.openstack.org/#/c/618834/ so this patch is currently blocked to avoid nova CI error. # Issue Since the oslo.services threading changes were backported to rocky we risk to faces the same issues inside the nova rocky CI if we update the requirements. In parallel in oslo.service we have started to backport a new patch who introduces fixture ( https://review.openstack.org/#/c/617989/ ) from master to rocky, and also we start to backport on nova rocky branch ( https://review.openstack.org/619019, https://review.openstack.org/619022 ) patches who use oslo.service.fixture and who solve the nova CI issue. The patch on oslo.service exposes a public oslo_service.fixture.SleepFixture for this purpose. It can be maintained opaquely as internals change without affecting its consumers. The main problem is that the patch bring a new functionality to a stable branch (oslo.service rocky) but this patch help to fix the nova issue. Also openstack proposal bot submit a patch to requirements on stable rocky to update the oslo.service version with the latest version (1.31.6) but if we'll use it we'll then break the CI https://review.openstack.org/#/c/618834/ since the oslo service 1.31.6 is incompatible with novas stable rocky unittest due to the threading changes. # Questions and proposed solutions This thread try to summarize the current situation. We need to find how to be able to proceed, so this thread aim to allow to discuss between team to find the best way to fix. 1. Do we need to continue to try to backport fixture on oslo.service to fix the CI problem (https://review.openstack.org/#/c/617989/) ? 2. Do we need to find an another approach like mocking oslo.service.loopingcall._Event.wait in nova instead of mocking oslo_service.loopingcall._ThreadingEvent.wait (example: https://review.openstack.org/#/c/616697/2/nova/tests/unit/compute/test_comp…) ? This is only a fix on the nova side and it allows us to update oslo.service requirements and allows us to fix the high CPU usage issue. I've submit this patch (https://review.openstack.org/619246) who implement the description above. Personaly I think we need to find an another approach like the mocking remplacement (c.f 2). We need to decide which way we use and to discuss about other solutions. -- Hervé Beraud Senior Software Engineer Red Hat - Openstack Oslo irc: hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

8 20

Re: [openstack-dev] [vitrage] I have some problems with Prometheus alarms in vitrage.
by Won 29 Nov '18

29 Nov '18

Hi, I attached four log files. I collected the logs from about 17:14 to 17:42. I created an instance of 'deltesting3' at 17:17. 7minutes later, at 17:24, the entity graph showed the dentesting3 and vitrage colletor and graph logs are appeared. When creating an instance in ubuntu server, it appears immediately in the entity graph and logs, but when creating an instance in computer1 (multi node), it appears about 5~10 minutes later. I deleted an instance of 'deltesting3' around 17:26. > After ~20minutes, there was only Apigateway. Does it make sense? did you > delete the instances on ubuntu, in addition to deltesting? > I only deleted 'deltesting'. After that, only the logs from 'apigateway' and 'kube-master' were collected. But other instances were working well. I don't know why only two instances are collected in the log. NOV 19 In this log, 'agigateway' and 'kube-master' were continuously collected in a short period of time, but other instances were sometimes collected in long periods. In any case, I would expect to see the instances deleted from the graph at > this stage, since they were not returned by get_all. > Can you please send me the log of vitrage-graph at the same time (Nov 15, > 16:35-17:10)? > Information 'deldtesting3' that has already been deleted continues to be collected in vitrage-graph.service. Br, Won 2018년 11월 15일 (목) 오후 10:13, Ifat Afek <ifatafekn(a)gmail.com>님이 작성: > > On Thu, Nov 15, 2018 at 10:28 AM Won <wjstk16(a)gmail.com> wrote: > >> Looking at the logs, I see two issues: >>> 1. On ubuntu server, you get a notification about the vm deletion, while >>> on compute1 you don't get it. >>> Please make sure that Nova sends notifications to >>> 'vitrage_notifications' - it should be configured in /etc/nova/nova.conf. >>> 2. Once in 10 minutes (by default) nova.instance datasource queries all >>> instances. The deleted vm is supposed to be deleted in Vitrage at this >>> stage, even if the notification was lost. >>> Please check in your collector log for the a message of "novaclient.v2.client >>> [-] RESP BODY" before and after the deletion, and send me its content. >> >> >> I attached two log files. I created a VM in computer1 which is a >> computer node and deleted it a few minutes later. Log for 30 minutes from >> VM creation. >> The first is the log of the vitrage-collect that grep instance name. >> The second is the noovaclient.v2.clinet [-] RESP BODY log. >> After I deleted the VM, no log of the instance appeared in the collector >> log no matter how long I waited. >> >> I added the following to Nova.conf on the computer1 node.(attached file >> 'compute_node_local_conf.txt') >> notification_topics = notifications,vitrage_notifications >> notification_driver = messagingv2 >> vif_plugging_timeout = 300 >> notify_on_state_change = vm_and_task_state >> instance_usage_audit_period = hour >> instance_usage_audit = True >> > > Hi, > > From the collector log RESP BODY messages I understand that in the > beginning there were the following servers: > compute1: deltesting > ubuntu: Apigateway, KubeMaster and others > > After ~20minutes, there was only Apigateway. Does it make sense? did you > delete the instances on ubuntu, in addition to deltesting? > In any case, I would expect to see the instances deleted from the graph at > this stage, since they were not returned by get_all. > Can you please send me the log of vitrage-graph at the same time (Nov 15, > 16:35-17:10)? > > There is still the question of why we don't see a notification from Nova, > but let's try to solve the issues one by one. > > Thanks, > Ifat > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

2 2

[openlab] November Update
by Melvin Hillsman 29 Nov '18

29 Nov '18

Hi everyone, We should have been doing this - totally my fault here - and hope you find updates at least monthly re OpenLab useful. In order to allow all people participating in OpenLab to provide details on the updates we are using etherpad: https://etherpad.openlabtesting.org/p/november2018update Thanks to all the community members helping to make OpenLab successful! -- Kind regards, Melvin Hillsman mrhillsman(a)gmail.com mobile: (832) 264-2646

2 1

[ironic] Finding a time to discuss cleaning/deployment steps visibility
by Julia Kreger 29 Nov '18

29 Nov '18

Greetings everyone, As discussed previously, I'd like to find a time when we can get on a higher bandwidth medium to discuss making clean and deployment steps visible. Generally we've struggled to gain consensus and I'd like for us to focus on trying to reach a minimally viable feature. I've created a doodle at: https://doodle.com/poll/yan4wyvztf7mpq46 Most recent specification: https://review.openstack.org/#/c/606199/ -Julia

1 0

[all] [infra] StoryBoard Migration: The Remaining Blockers Summary
by Kendall Nelson 29 Nov '18

29 Nov '18

Hello! As with all of my other summaries, if you are looking for the long etherpad version, you can find it here[1]. Somewhere along the way I used the wrong etherpad for notes and so we ended up doing the StoryBoard things in the etherpad originally meant for another session so pardon the name. Anywho. Overall the session went really well, there weren’t any huge glaring issues that anyone brought up. The majority of things were all smaller usability things. Just about all of which are definitely doable. The only slightly larger feature request (that we hadn't previously discussed) was a separate interface for filing stories- similar to the one LP provides. Something simple so the user doesn’t feel like they need to fill in all this information, but can just provide the minimum. I haven’t quite gotten around to making stories for all of the things discussed in the etherpad, but should have them up soon! You will be able to see them here[2], once they’ve been created. If you have opinions about any of what we discussed or have something you wanted to bring up but could not attend the session please drop into #storyboard and chat with us, or join us at our weekly meeting on Wednesday at 19:00 UTC. -Kendall (diablo_rojo) [1]https://etherpad.openstack.org/p/BER-Contrib-Portal-Feedback (yes, I know the name doesn’t seem right..) [2] https://storyboard.openstack.org/#!/story/list?status=active&project_group_…

2 2

[tripleo] gate is backed up (again)
by Alex Schultz 29 Nov '18

29 Nov '18

Ahoy folks. We're running into a massive backlog and it's messing with everyone again. As stop gap, we're clearing the gate and will need to land the patches to switch them back to non-voting and remove the scenarios[0] from the gate in stable branches. We had switched them back to voting ~2 weeks ago because they were still in the gate (but non-voting). I thought we weren't going to run into as many issues in the stable branches but we've been backporting a bit more lately. We are proposing this because in the gate we've had a bunch of scenario failures[1] not related to code but just time outs. Additionally we're making progress on converting the master scenario jobs to standalone versions which may be backportable to stable/rocky. So in the mean time, we're asking that you not approve or recheck anything until the CI has stabilized. We'll send out a note when we're clear. Thanks, -Alex [0] https://review.openstack.org/#/q/topic:scenarios-nv+(status:open+OR+status:… [1] http://zuul.openstack.org/builds?pipeline=gate&result=failure&result=timed_…

1 0

Re: [Openstack-operators] Fwd: Nova hypervisor uuid
by Ignazio Cassano 29 Nov '18

29 Nov '18

Hi Matt, sorry but I lost your answer and Gianpiero forwarded it to me. I am sure kvm nodes names are note changed. Tables where uuid are duplicated are: dataresource_providers in nova_api db compute_nodes in nova db Regards Ignazio Il 28/Nov/2018 11:09 AM, "Gianpiero Ardissono" <gp.ardissono(a)gmail.com> ha scritto: > > ---------- Forwarded message --------- > From: Matt Riedemann <mriedemos(a)gmail.com> > Date: mar 27 nov 2018, 19:03 > Subject: Re: [Openstack-operators] Nova hypervisor uuid > To: <openstack-operators(a)lists.openstack.org> > > > On 11/27/2018 11:32 AM, Ignazio Cassano wrote: > > Hi All, > > Please anyone know where hypervisor uuid is retrived? > > Sometime updating kmv nodes with yum update it changes and in nova > > database 2 uuids are assigned to the same node. > > regards > > Ignazio > > > > > > > > > > _______________________________________________ > > OpenStack-operators mailing list > > OpenStack-operators(a)lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > > > To be clear, do you mean the computes_nodes.uuid column value in the > cell database? Which is also used for the GET /os-hypervisors response > 'id' value if using microversion >= 2.53. If so, that is generated > randomly* when the compute_nodes table record is created: > > > https://github.com/openstack/nova/blob/8545ba2af7476e0884b5e7fb90965bef92d6… > > > https://github.com/openstack/nova/blob/8545ba2af7476e0884b5e7fb90965bef92d6… > > When you hit this problem, are you sure the hostname on the compute host > is not changing? Because when nova-compute starts up, it should look for > the existing compute node record by host name and node name, which for > the libvirt driver should be the same. That lookup code is here: > > > https://github.com/openstack/nova/blob/8545ba2af7476e0884b5e7fb90965bef92d6… > > So the only way nova-compute should create a new compute_nodes table > record for the same host is if the host/node name changes during the > upgrade. Is the deleted value in the database the same (0) for both of > those records? > > * The exception to this is for the ironic driver which re-uses the > ironic node uuid as of this change: > https://review.openstack.org/#/c/571535/ > > -- > > Thanks, > > Matt > > _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > _______________________________________________ OpenStack-operators mailing list OpenStack-operators(a)lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

2 6

[release][ptl] Holding all release activity
by Sean McGinnis 29 Nov '18

29 Nov '18

Hey everyone, There have been a rash of Pypi and other issues lately that have led to release job failures. We will be holding off on processing any more releases until we've seen some evidence that things have been resolved. I would guess this means that there will be no releases done until early next week. If you have a critical need for a release, please come talk to us in the #openstack-release channel and we can see if there is anything we can do in the interim. Thanks! Sean

1 1

[glance][ops][users]OpenStack Glance default visibility survey
by ekuvaja＠redhat.com 29 Nov '18

29 Nov '18

I've invited you to fill out the following form: OpenStack Glance default visibility survey To fill it out, visit: https://docs.google.com/forms/d/e/1FAIpQLScbbmeLQrx34P84U-Wr2RoLOpXdWMEZg-X… Hello all, Time for another very quick survey from Glance team. This time we would like to get your feedback on if we should set the default visibility of newly created images to "private" or not. Please note this survey closes in a week and we will take the action based on the results provided. Erno jokke Kuvaja I've invited you to fill out a form: Google Forms: Create and analyze surveys.

1 0

[release] Release countdown for week R-18, Dec 3-7
by Sean McGinnis 29 Nov '18

29 Nov '18

Welcome back from the Summit and holidays. Back to our regularly scheduled countdown emails. Development Focus ----------------- With the longer development cycle we are still a few weeks out until milestone 2. Hopefully folks got some good input and feedback and the Summit and Forum. Teams should be taking input and adjusting any earlier plans as needed based on this. General Information ------------------- Now may be a good time for teams to check on any stable releases that need to be done for your deliverables. If you have bugfixes that have been backported, but no stable release getting those. If you are unsure what is out there committed but not released, in the openstack/releases repo, running the command "tools/list_stable_unreleased_changes.sh <cycle_name>" gives a nice report. Upcoming Deadlines & Dates -------------------------- Start using openstack-discuss ML: November 19 (in case you missed it) Stein-2 Milestone: January 10 -- Sean McGinnis (smcginnis)

1 0

[dev] [tc][all] TC office hours is started now on #openstack-tc
by Ghanshyam Mann 29 Nov '18

29 Nov '18

Hi All, TC office hour is started on #openstack-tc channel. Feel free to reach to us for anything you want discuss/input/feedback/help from TC. - TC

1 0

Re: [openstack-dev] [TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes
by Bogdan Dobrelya 29 Nov '18

29 Nov '18

On 11/29/18 2:00 PM, Jay Pipes wrote: > On 11/29/2018 04:28 AM, Bogdan Dobrelya wrote: >> On 11/28/18 8:55 PM, Doug Hellmann wrote: >>> I thought the preferred solution for more complex settings was config >>> maps. Did that approach not work out? >>> >>> Regardless, now that the driver work is done if someone wants to take >>> another stab at etcd integration it’ll be more straightforward today. >>> >>> Doug >>> >> >> While sharing configs is a feasible option to consider for large scale >> configuration management, Etcd only provides a strong consistency, >> which is also known as "Unavailable" [0]. For edge scenarios, to >> configure 40,000 remote computes over WAN connections, we'd rather >> want instead weaker consistency models, like "Sticky Available" [0]. >> That would allow services to fetch their configuration either from a >> central "uplink" or locally as well, when the latter is not accessible >> from remote edge sites. Etcd cannot provide 40,000 local endpoints to >> fit that case I'm afraid, even if those would be read only replicas. >> That is also something I'm highlighting in the paper [1] drafted for >> ICFC-2019. >> >> But had we such a sticky available key value storage solution, we >> would indeed have solved the problem of multiple configuration >> management system execution for thousands of nodes as James describes it. > > It's not that etcd is incapable of providing something like this. It's > that a *single* etcd KVS used by 40K compute nodes across a > disaggregated control plane would not be available to all of those nodes > simultaneously. > > But you could certainly use etcd as the data store to build a sticky > available configuration data store. If, for example, you had many local > [1] etcd KVS that stored local data and synchronized the local data set > with other etcd KVS endpoints when a network partition was restored, you > could get such a system that was essentially "sticky available" for all > intents and purposes. > > Come to think of it, you could do the same with a SQLite DB, ala Swift's > replication of SQLite DBs via rsync. > > But, at the risk of sounding like a broken record, at the end of the > day, many of OpenStack's core services -- notably Nova -- were not > designed for disaggregated control planes. They were designed for the > datacenter, with tightly-packed compute resources and low-latency links > for the control plane. > > The entire communication bus and state management system would need to > be redesigned from the nova-compute to the nova-conductor for (far) edge > case clouds to be a true reality. > > Instead of sending all data updates synchronously from each nova-compute > to nova-conductor, the communication bus needs to be radically > redesigned so that the nova-compute uses a local data store *as its > primary data storage* and then asynchronously sends batched updates to > known control plane endpoints when those regular network partitions > correct themselves. > > The nova-compute manager will need to be substantially hardened to keep > itself up and running (and writing to that local state storage) for long > periods of time and contain all the logic to resync itself when network > uplinks become available again. > > Finally, if those local nova-computes need to actually *do* anything > other than keep existing VMs/baremetal machines up and running, then a > local Compute API service needs to be made available in the far edge > sites themselves -- offering some subset of Compute API functionality to > control the VMs in that local site. Otherwise, the whole "multiple > department stores running an edge OpenStack site that can tolerate the > Mother Ship being down" isn't a thing that will work. > > Like I said, pretty much a complete redesign of the nova control plane... We derived a little bit off the topic... but that all is valid for the post-MVP Edge architecture phases [0] targeted for multiple (aka disaggregated/autonomous/local vs central) control planes, indeed. Although there are more options than that complete redesign. IIUC, does the latter assume supporting alternative to SQL/AMQP-ish data/messaging backends for Nova and OpenStack in general? That is only an option (see such backends examples [1][2]), though I love it the most :) Other options may be creating client libraries acting on top of APIs or existing DB/MQ backends and performing low-level data synchronization, or acting as an API re-translators, over multiple control planes. And AFAICT that would *not* require complete redesign of supported backends nor types of transactions in Nova et al. And for MQ, a brokerless qdr or something (there was a nice presentation at the summit)... But in the end, indeed, it is kinda proved in multiple R&D papers, like [3],[4] that only causal sticky consistent synchronization with advanced conflicts resolving [5] is the best Edge-y/Fog-y choice for both such client libraries and causal consistent DB/KVS/MQ backends. I think that is something similar what you (Jay) diescribed for multiple Etcd cluster exchanging its data? So for that example, such client libraries should be maintaining sticky sessions to groups of those Etcd clusters and replicate data around doing it the best of causal consistent ways. PS. That a nice SQLight & rsync combo would not provide us the best of eventual consistency world, no, it would rather be something of a "Total Available" [6] thing, the lowest of it, like Read Uncommited or Monotonic Writes, and would be a very (very) poor choice IMO. [0] https://wiki.openstack.org/w/index.php?title=OpenStack_Edge_Discussions_Dub… [1] https://www.ronpub.com/OJDB_2015v2i1n02_Elbushra.pdf [2] http://rainbowfs.lip6.fr/data/RainbowFS-2016-04-12.pdf [3] https://www.cs.cmu.edu/~dga/papers/cops-sosp2011.pdf [4] http://www.cs.cornell.edu/lorenzo/papers/cac-tr.pdf [5] https://ieeexplore.ieee.org/document/8104644 [6] https://jepsen.io/consistency > > Best, > -jay > > [1] or local-ish, think POPs or even local to the compute node itself... > >> [0] https://jepsen.io/consistency >> [1] >> https://github.com/bogdando/papers-ieee/blob/master/ICFC-2019/LaTeX/positio… -- Best regards, Bogdan Dobrelya, Irc #bogdando

1 0

[Openstack] [Ocata] config option show_multiple_locations
by Eugen Block 29 Nov '18

29 Nov '18

Hello list, I have a strange issue I'd like to report here, I'm not sure whether this could be a bug or a config issue on my side. The environment has developed from Liberty to Ocata over the last 3 years, backend for glance, cinder and nova is Ceph since Mitaka release. So according to [1] these two config options should be set to true. > show_multiple_locations = True > show_image_direct_url = True This setup has worked just fine, live snapshots of nova worked as expected. Last year the environment was upgraded to Ocata (successfully), and some time later I decided to clean up the configs, I set show_multiple_locations to false, also because glance reports: > Option "show_multiple_locations" from group "DEFAULT" is deprecated > for removal. Its value may be silently ignored in the future. Since this change the nova live snapshots stopped working, resulting in this stack trace: ---cut here--- [req-5bd2fef2-2155-4a89-b346-e20fb0b0d14a df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e 2e3c3f3822124a3fa9fd905164f519ae - - -] Failed to snapshot image Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 1626, in snapshot purge_props=False) File "/usr/lib/python2.7/site-packages/nova/image/api.py", line 132, in update purge_props=purge_props) File "/usr/lib/python2.7/site-packages/nova/image/glance.py", line 733, in update _reraise_translated_image_exception(image_id) File "/usr/lib/python2.7/site-packages/nova/image/glance.py", line 1050, in _reraise_translated_image_exception six.reraise(type(new_exc), new_exc, exc_trace) File "/usr/lib/python2.7/site-packages/nova/image/glance.py", line 731, in update image = self._update_v2(context, sent_service_image_meta, data) File "/usr/lib/python2.7/site-packages/nova/image/glance.py", line 745, in _update_v2 image = self._add_location(context, image_id, location) File "/usr/lib/python2.7/site-packages/nova/image/glance.py", line 630, in _add_location location, {}) File "/usr/lib/python2.7/site-packages/nova/image/glance.py", line 168, in call result = getattr(controller, method)(*args, **kwargs) File "/usr/lib/python2.7/site-packages/glanceclient/v2/images.py", line 340, in add_location response = self._send_image_update_request(image_id, add_patch) File "/usr/lib/python2.7/site-packages/glanceclient/common/utils.py", line 535, in inner return RequestIdProxy(wrapped(*args, **kwargs)) File "/usr/lib/python2.7/site-packages/glanceclient/v2/images.py", line 324, in _send_image_update_request data=json.dumps(patch_body)) File "/usr/lib/python2.7/site-packages/glanceclient/common/http.py", line 294, in patch return self._request('PATCH', url, **kwargs) File "/usr/lib/python2.7/site-packages/glanceclient/common/http.py", line 277, in _request resp, body_iter = self._handle_response(resp) File "/usr/lib/python2.7/site-packages/glanceclient/common/http.py", line 107, in _handle_response raise exc.from_response(resp, resp.content) ImageNotAuthorized: Not authorized for image e99b2dfd-db33-4475-a51f-af4b913a7041. INFO nova.compute.manager [req-5bd2fef2-2155-4a89-b346-e20fb0b0d14a df7b63e69da3b1ee2be3d79342e7992f3620beddbdac7768dcb738105e74301e 2e3c3f3822124a3fa9fd905164f519ae - - -] [instance: 751b3731-de0d-42cd-a105-b92e326294aa] Successfully reverted task state from image_uploading on failure for instance. ---cut here--- A couple of weeks passed until this problem occured (oviously nobody took snapshots), so I didn't immediately connect it to the config change, but when I followed the stack trace, I found this comment: ---cut here--- def _add_location(self, context, image_id, location): # 'show_multiple_locations' must be enabled in glance api conf file. [...] ---cut here--- I wouldn't expect this dependency if the option is marked as deprecated. Is this my misunderstanding or did I forget other configs that would prevent this behavior? Thank you for any information about this topic. Regards, Eugen [1] http://docs.ceph.com/docs/master/rbd/rbd-openstack/#for-mitaka-only

2 2

[openstack-dev] [mistral] Renat is on vacation until Dec 17th
by Renat Akhmerov 29 Nov '18

29 Nov '18

Hi, I’ll be on vacation till Dec 17th. I’ll be replying emails but with delays. Thanks Renat Akhmerov @Nokia __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

1 0

[Openstack] TAPaaS on Queens?
by M. Ranganathan 28 Nov '18

28 Nov '18

Hello all, I want to experiment with SNORT as a service on OpenStack. I looked at the TAPaaS project. However, I am not sure it runs on OpenStack Queens. I don't see it in the queens release https://releases.openstack.org/queens/index.html so I am wondering if this project is still alive (?) Thanks, Ranga -- M. Ranganathan _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack(a)lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

2 1

[glance] Interoperable Image Import: Plugin configuration ignored
by Bernd Bausch 28 Nov '18

28 Nov '18

Exploring image import on Rocky. My cloud is a Devstack. To permit image import, I modified it so that it runs Glance not as uwsgi processes behind Apache, but as standalone processes. The glance-direct image import process (create, stage, import) works - except that the configured plugin is simply ignored. /etc/glance/glance-image-import.conf: [image_import_opts] image_import_plugins = [inject_image_metadata] [inject_metadata_properties] inject = "import-type":"user-import" ignore_user_roles = admin /etc/glance/policy.json contains: "get_task": "", "get_tasks": "", "add_task": "", "modify_task": "", "tasks_api_access": "role:admin", Yet imported images are lacking the configured metadata. I added a few LOG calls. get_import_plugins() in glance/async/flows/plugins/__init__.py tells me that image_import_plugins = []. It looks like the configuration in glance-image-import.conf is ignored or not read at all. How can I find out what I am doing wrong?

1 0

[Openstack] How to create a tap port using openstack API?
by M. Ranganathan 28 Nov '18

28 Nov '18

Hello, I want to write my own VNF. For this I need to : 1. Create a network namespace. 2. Create a ovs internal port on a bridge with an appropriate tag. 3. Send the port to the network namespace. 4. Run a service in the network namespace that could (for example) read packets. Are there "openstack networking" commands to do steps 1-3 above or should this be done manually? ( What I want to do, essentially is to create a tap port and read packets from this tap port. Incidentally, the TAPaaS project was doing something like this but it seems to be unsupported.) Thanks, Ranga -- M. Ranganathan _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack(a)lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

1 0

[Openstack] OpenStack federation and WAYF process with multiple IdPs
by Rafael Weingärtner 28 Nov '18

28 Nov '18

Hello Openstackers, I am testing the integration of OpenStack (acting as a service provider) using Keycloak (as an identity provider) with OpenId Connect protocol. So far everything is working, but when I enable more than one IdP, I get an odd behavior. The “where are you from (WAYF)” process is happening twice, one in Horizon (where the user selects the authentication provider A.K.A IdP), and another one in Keystone via the Apache HTTPD OIDC module. I assume this is happening because the actual application being authenticated via OIDC is Keystone, and just afterwards, the other systems will authenticate themselves via Keystone. Has anybody else experienced/”dealt with” this situation? Is this by design? Am I missing a parameter/configuration or something else? The version of OpenStack that I am using is Rocky. -- Rafael Weingärtner _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack(a)lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

1 0

[nova] Heads up on default policy change for zero-disk flavors
by Matt Riedemann 28 Nov '18

28 Nov '18

Coming back to a security bug there is a change in nova [1] in Stein to change the value on the "os_compute_api:servers:create:zero_disk_flavor" policy rule to make it admin-only by default. This makes server create fail for non-admins users who are using flavors with root_gb=0 *unless* they are booting from volume. If you already have this configuration set before upgrading to stein then your deployment tooling shouldn't overwrite the configured policy and you won't notice any changes, but if you have an empty policy file and upgrade and have 0 root_gb flavors, your users could see server create failures. Let us know if you have any issues with this, or would like to see something done in the way of further documentation/communication and/or a nova-status upgrade check. [1] https://review.openstack.org/#/c/603910/ -- Thanks, Matt

1 0

[nova][cinder] Why can't nova in stein work with cinder from queens?
by Matt Riedemann 28 Nov '18

28 Nov '18

A change in nova [1] was approved which makes an assertion that we (nova? openstack?) do not support running nova from stein with cinder from queens, and I guess I'd like to know where that support statement is written down? Granted, I know we don't gate that way but I'm not aware of anything preventing it from working given we use microversions and nova, as the client, should be able to work with cinder from v1, v2 or v3 assuming it's doing version discovery correctly (which we've been doing in nova since queens when we needed to start using the cinder v3.44 volume attachments API for multiattach - but it's not required). In fact, nova-api still has compatibility code for older versions of cinder to determine what it should do about working with volume attachments [2]. I've been thinking lately about how to drop that code which would at the very least require a release note saying nova requires cinder >= queens, but nothing like that was requested in the change that drops support for cinder v1 from nova and asserts that nova in stein requires cinder >= queens. Maybe I'm just yelling at kids to get off my lawn, but I don't really want this to be precedent without some discussion because I know at various times operators have complained about upgrades being hard because they assume all of the services must be upgraded to the same release at the same time, and I don't think that is true, or should be true, because if it is, we're doing a really bad job of defining versioned interfaces between the services. [1] https://review.openstack.org/#/c/617927/ [2] https://github.com/openstack/nova/blob/7217e38bafb75e8a613763835b64e48e6b2c… -- Thanks, Matt

2 3

[OCTAVIA] How to monitor amphora
by Gaël THEROND 28 Nov '18

28 Nov '18

Hi guys, As already discussed I had to test Octavia as our corporate LoadBalancer solution and it was a success. Thank to everyone on this list that assisted me and especially Michael Octavia is fully working and without weird nightmare glitches. Now that I validated the technical part of my project, I need to enter more operationals questions such as what’s the best way to monitor and log amphora? I would like to be able to get a monitoring and logging agent installed on the amphora in order to get proper metrics about what’s going on with the LoadBalancer, is it fully cpu loaded? Is it using all network resources available, are the file descriptors near the initial limits? How much xxx HTTP return code the loadBalancer is facing and send those logs to an ELK or something similar. Do you know if that something that I could achieve by adding more elements to the image at DIB time or are there any other better best-practices that I should be aware of ? As Octavia is creating a namespace for each HAProxy process, I am wandering if it’s even possible. Thanks a lot for your hard work guys. Kind regards,

5 8

[loci] Project Technical Leadership Change
by Chris Hoge 28 Nov '18

28 Nov '18

After discussion with the current Loci PTL, team members, and the OpenStack TC at the Berlin Summit, I will be stepping in as interim PTL for the Loci project for the remainder of the development cycle. If you have any questions or concerns about this, please feel free to reach out to me directly. As a reminder, Loci has weekly team meetings on Friday at 1500 UTC in the #openstack-loci channel that we will be resuming this week. Thanks, Chris Hoge

2 3

[Openstack] [Nova] Instance creation problem
by Minjun Hong 28 Nov '18

28 Nov '18

Hi. I'm setting up a Openstack system on the servers of my laboratory. While I try to create an instance, a problem has occurred! Instance creation was failed and it seems that libvirt failed to attaching the vif to the instance. When I create a virtual machine by using virsh tool (libvirt) manually, there was no problem. I add the logs as follows: 1. controller node > "/var/log/nova/nova-conductor.log" > 2018-11-28 21:18:13.033 2657 ERROR nova.scheduler.utils > [req-291fdb2d-fa94-461c-9f5f-68d340791c77 3367829d9c004653bdc9102443bd4736 > 47270e4fb58045dc88b6f0f736286ffc - default default] [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] Error from last host: node1 (node > node1): [u'Traceback (most recent call last):\n', u' File > "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 1840, in > _do_build_and_run_instance\n filter_properties, request_spec)\n', u' > File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 2120, > in _build_and_run_instance\n instance_uuid=instance.uuid, > reason=six.text_type(e))\n', u"RescheduledException: Build of instance > 9c2d08f3-0680-4709-a64d-ae1729a11304 was re-scheduled: internal error: > libxenlight failed to create new domain 'instance-00000008'\n"] > 2018-11-28 21:18:13.033 2657 WARNING nova.scheduler.utils > [req-291fdb2d-fa94-461c-9f5f-68d340791c77 3367829d9c004653bdc9102443bd4736 > 47270e4fb58045dc88b6f0f736286ffc - default default] Failed to > compute_task_build_instances: Exceeded maximum number of retries. Exceeded > max scheduling attempts 3 for instance > 9c2d08f3-0680-4709-a64d-ae1729a11304. Last exception: internal error: > libxenlight failed to create new domain 'instance-00000008': > MaxRetriesExceeded: Exceeded maximum number of retries. Exceeded max > scheduling attempts 3 for instance 9c2d08f3-0680-4709-a64d-ae1729a11304. > Last exception: internal error: libxenlight failed to create new domain > 'instance-00000008' > 2018-11-28 21:18:13.034 2657 WARNING nova.scheduler.utils > [req-291fdb2d-fa94-461c-9f5f-68d340791c77 3367829d9c004653bdc9102443bd4736 > 47270e4fb58045dc88b6f0f736286ffc - default default] [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] Setting instance to ERROR state.: > MaxRetriesExceeded: Exceeded maximum number of retries. Exceeded max > scheduling attempts 3 for instance 9c2d08f3-0680-4709-a64d-ae1729a11304. > Last exception: internal error: libxenlight failed to create new domain > 'instance-00000008' > 2018-11-28 21:18:13.067 2657 WARNING oslo_config.cfg > [req-291fdb2d-fa94-461c-9f5f-68d340791c77 3367829d9c004653bdc9102443bd4736 > 47270e4fb58045dc88b6f0f736286ffc - default default] Option "url" from group > "neutron" is deprecated for removal (Endpoint lookup uses the service > catalog via common keystoneauth1 Adapter configuration options. In the > current release, "url" will override this behavior, but will be ignored > and/or removed in a future release. To achieve the same result, use the > endpoint_override option instead.). Its value may be silently ignored in > the future. > "/var/log/neutron/neutron-linuxbridge-agent.log" > 2018-11-28 17:41:45.593 2476 INFO > neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent [-] > Interface mappings: {'provider': 'enp1s0f1'} > 2018-11-28 17:41:45.593 2476 INFO > neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent [-] > Bridge mappings: {} > 2018-11-28 17:41:45.624 2476 INFO > neutron.plugins.ml2.drivers.linuxbridge.agent.linuxbridge_neutron_agent [-] > Agent initialized successfully, now running... > 2018-11-28 17:41:45.901 2476 INFO > neutron.plugins.ml2.drivers.agent._common_agent > [req-c447894c-9013-4bec-82e4-8b501414184d - - - - -] RPC agent_id: > lba0369fa2714a > 2018-11-28 17:41:45.907 2476 INFO neutron.agent.agent_extensions_manager > [req-c447894c-9013-4bec-82e4-8b501414184d - - - - -] Loaded agent > extensions: [] > 2018-11-28 17:41:46.121 2476 INFO > neutron.plugins.ml2.drivers.agent._common_agent > [req-c447894c-9013-4bec-82e4-8b501414184d - - - - -] Linux bridge agent > Agent RPC Daemon Started! > 2018-11-28 17:41:46.122 2476 INFO > neutron.plugins.ml2.drivers.agent._common_agent > [req-c447894c-9013-4bec-82e4-8b501414184d - - - - -] Linux bridge agent > Agent out of sync with plugin! > 2018-11-28 17:41:46.512 2476 INFO > neutron.plugins.ml2.drivers.linuxbridge.agent.arp_protect > [req-c447894c-9013-4bec-82e4-8b501414184d - - - - -] Clearing orphaned ARP > spoofing entries for devices [] > 2018-11-28 17:41:47.020 2476 INFO > neutron.plugins.ml2.drivers.linuxbridge.agent.arp_protect > [req-c447894c-9013-4bec-82e4-8b501414184d - - - - -] Clearing orphaned ARP > spoofing entries for devices [] > 2018-11-28 17:42:45.981 2476 ERROR > neutron.plugins.ml2.drivers.agent._common_agent [-] Failed reporting > state!: MessagingTimeout: Timed out waiting for a reply to message ID > 20ef587240864120b878559ab821adbf > 2018-11-28 17:42:45.981 2476 ERROR > neutron.plugins.ml2.drivers.agent._common_agent Traceback (most recent call > last): > 2018-11-28 17:42:45.981 2476 ERROR > neutron.plugins.ml2.drivers.agent._common_agent File > "/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/drivers/agent/_common_agent.py", > line 128, in _report_state > 2018-11-28 17:42:45.981 2476 ERROR > neutron.plugins.ml2.drivers.agent._common_agent True) > 2018-11-28 17:42:45.981 2476 ERROR > neutron.plugins.ml2.drivers.agent._common_agent File > "/usr/lib/python2.7/dist-packages/neutron/agent/rpc.py", line 93, in > report_state > 2018-11-28 17:42:45.981 2476 ERROR > neutron.plugins.ml2.drivers.agent._common_agent return method(context, > 'report_state', **kwargs) > 2018-11-28 17:42:45.981 2476 ERROR > neutron.plugins.ml2.drivers.agent._common_agent File > "/usr/lib/python2.7/dist-packages/oslo_messaging/rpc/client.py", line 174, > in call > 2018-11-28 17:42:45.981 2476 ERROR > neutron.plugins.ml2.drivers.agent._common_agent retry=self.retry) > 2018-11-28 17:42:45.981 2476 ERROR > neutron.plugins.ml2.drivers.agent._common_agent File > "/usr/lib/python2.7/dist-packages/oslo_messaging/transport.py", line 131, > in _send > 2018-11-28 17:42:45.981 2476 ERROR > neutron.plugins.ml2.drivers.agent._common_agent timeout=timeout, > retry=retry) > 2018-11-28 17:42:45.981 2476 ERROR > neutron.plugins.ml2.drivers.agent._common_agent File > "/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", > line 559, in send > 2018-11-28 17:42:45.981 2476 ERROR > neutron.plugins.ml2.drivers.agent._common_agent retry=retry) > 2018-11-28 17:42:45.981 2476 ERROR > neutron.plugins.ml2.drivers.agent._common_agent File > "/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", > line 548, in _send > 2018-11-28 17:42:45.981 2476 ERROR > neutron.plugins.ml2.drivers.agent._common_agent result = > self._waiter.wait(msg_id, timeout) > 2018-11-28 17:42:45.981 2476 ERROR > neutron.plugins.ml2.drivers.agent._common_agent File > "/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", > line 440, in wait > 2018-11-28 17:42:45.981 2476 ERROR > neutron.plugins.ml2.drivers.agent._common_agent message = > self.waiters.get(msg_id, timeout=timeout) > 2018-11-28 17:42:45.981 2476 ERROR > neutron.plugins.ml2.drivers.agent._common_agent File > "/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", > line 328, in get > 2018-11-28 17:42:45.981 2476 ERROR > neutron.plugins.ml2.drivers.agent._common_agent 'to message ID %s' % > msg_id) > 2018-11-28 17:42:45.981 2476 ERROR > neutron.plugins.ml2.drivers.agent._common_agent MessagingTimeout: Timed out > waiting for a reply to message ID 20ef587240864120b878559ab821adbf > 2018-11-28 17:42:45.981 2476 ERROR > neutron.plugins.ml2.drivers.agent._common_agent > 2018-11-28 17:42:45.986 2476 WARNING oslo.service.loopingcall [-] Function > 'neutron.plugins.ml2.drivers.agent._common_agent.CommonAgentLoop._report_state' > run outlasted interval by 30.07 sec > 2018-11-28 17:42:46.055 2476 INFO > neutron.plugins.ml2.drivers.agent._common_agent [-] Linux bridge agent > Agent has just been revived. Doing a full sync. > 2018-11-28 17:42:46.156 2476 INFO > neutron.plugins.ml2.drivers.agent._common_agent > [req-c447894c-9013-4bec-82e4-8b501414184d - - - - -] Linux bridge agent > Agent out of sync with plugin! > 2018-11-28 17:43:40.189 2476 INFO neutron.agent.securitygroups_rpc > [req-c447894c-9013-4bec-82e4-8b501414184d - - - - -] Preparing filters for > devices set(['tap4a09374a-7f']) > 2018-11-28 17:43:40.935 2476 INFO > neutron.plugins.ml2.drivers.agent._common_agent > [req-c447894c-9013-4bec-82e4-8b501414184d - - - - -] Port tap4a09374a-7f > updated. Details: {u'profile': {}, u'network_qos_policy_id': None, > u'qos_policy_id': None, u'allowed_address_pairs': [], u'admin_state_up': > True, u'network_id': u'87fa0d9c-5ed3-4332-8782-0d4139eed7f3', > u'segmentation_id': None, u'mtu': 1500, u'device_owner': u'network:dhcp', > u'physical_network': u'provider', u'mac_address': u'fa:16:3e:ab:0e:84', > u'device': u'tap4a09374a-7f', u'port_security_enabled': False, u'port_id': > u'4a09374a-7fa5-42c2-9430-67a0cd65336c', u'fixed_ips': [{u'subnet_id': > u'e95946a8-070c-42c4-877e-279e6e7acc7e', u'ip_address': u'192.0.10.4'}], > u'network_type': u'flat'} > 2018-11-28 17:43:41.124 2476 INFO > neutron.plugins.ml2.drivers.linuxbridge.agent.arp_protect > [req-c447894c-9013-4bec-82e4-8b501414184d - - - - -] Skipping ARP spoofing > rules for port 'tap4a09374a-7f' because it has port security disabled "/var/log/neutron/neutron-server.log" > 2018-11-28 17:30:02.130 15995 INFO neutron.pecan_wsgi.hooks.translation > [req-e7554d70-c84d-46d5-8ff6-a536fb35664c 29a3a16fd2484ee9bed834a3835545af > 5ebe3484974848b182a381127cb35a22 - default default] GET failed (client > error): The resource could not be found. > 2018-11-28 17:30:02.130 15995 INFO neutron.wsgi > [req-e7554d70-c84d-46d5-8ff6-a536fb35664c 29a3a16fd2484ee9bed834a3835545af > 5ebe3484974848b182a381127cb35a22 - default default] 10.150.21.183 "GET > /v2.0/floatingips?fixed_ip_address=192.0.10.10&port_id=8ab0d544-ec5b-4e69-95f4-1f06f7b53bb4 > HTTP/1.1" status: 404 len: 309 time: 0.0072770 > 2018-11-28 17:30:02.167 15995 INFO neutron.wsgi > [req-a2b5f53b-8992-4178-b0b6-55be9d1a0f32 29a3a16fd2484ee9bed834a3835545af > 5ebe3484974848b182a381127cb35a22 - default default] 10.150.21.183 "GET > /v2.0/subnets?id=e95946a8-070c-42c4-877e-279e6e7acc7e HTTP/1.1" status: > 200 len: 822 time: 0.0341990 > 2018-11-28 17:30:02.199 15995 INFO neutron.wsgi > [req-9e1a51e9-9ccc-4226-a78f-0420ff95c147 29a3a16fd2484ee9bed834a3835545af > 5ebe3484974848b182a381127cb35a22 - default default] 10.150.21.183 "GET > /v2.0/ports?network_id=87fa0d9c-5ed3-4332-8782-0d4139eed7f3&device_owner=network%3Adhcp > HTTP/1.1" status: 200 len: 1080 time: 0.0300300 > 2018-11-28 17:30:02.584 15995 INFO neutron.notifiers.nova [-] Nova event > response: {u'status': u'completed', u'tag': > u'8ab0d544-ec5b-4e69-95f4-1f06f7b53bb4', u'name': u'network-changed', > u'server_uuid': u'a9afc2d4-f4c9-429b-9773-4de8a3eaefa5', u'code': 200} > 2018-11-28 17:30:02.628 15995 INFO neutron.wsgi > [req-73265cf5-5f0d-4217-b716-caa2fb906abf 29a3a16fd2484ee9bed834a3835545af > 5ebe3484974848b182a381127cb35a22 - default default] 10.150.21.183 "GET > /v2.0/ports?tenant_id=47270e4fb58045dc88b6f0f736286ffc&device_id=a9afc2d4-f4c9-429b-9773-4de8a3eaefa5 > HTTP/1.1" status: 200 len: 1062 time: 0.0316660 > 2018-11-28 17:30:02.696 15995 INFO neutron.wsgi > [req-ed53b92c-3033-4b4a-ade4-fdc5a3463e8c 29a3a16fd2484ee9bed834a3835545af > 5ebe3484974848b182a381127cb35a22 - default default] 10.150.21.183 "GET > /v2.0/networks?id=87fa0d9c-5ed3-4332-8782-0d4139eed7f3 HTTP/1.1" status: > 200 len: 872 time: 0.0655539 > 2018-11-28 17:30:02.702 15995 WARNING neutron.pecan_wsgi.controllers.root > [req-ccd8c9b8-d2cf-40f7-b53b-5936bd0c9a6d 29a3a16fd2484ee9bed834a3835545af > 5ebe3484974848b182a381127cb35a22 - default default] No controller found > for: floatingips - returning response code 404: PecanNotFound 2. compute node > "/var/log/libvirt/libxl/libxl-driver.log" > 2018-11-28 08:40:31.920+0000: libxl: > libxl_event.c:681:libxl__ev_xswatch_deregister: remove watch for path > @releaseDomain: Bad file descriptor > 2018-11-28 09:57:01.707+0000: libxl: > libxl_exec.c:118:libxl_report_child_exitstatus: /etc/xen/scripts/vif-bridge > online [2536] exited with error status 1 > 2018-11-28 09:57:01.708+0000: libxl: > libxl_device.c:1286:device_hotplug_child_death_cb: script: ip link set > vif1.0 name tape5a239a8-6e failed > 2018-11-28 09:57:01.708+0000: libxl: > libxl_create.c:1522:domcreate_attach_devices: Domain 1:unable to add vif > devices "/var/log/xen/xen-hotplug.log" > RTNETLINK answers: Device or resource busy "/var/log/nova/nova-compute.log" > : libvirtError: internal error: libxenlight failed to create new domain > 'instance-00000008' > 2018-11-28 21:18:11.350 2384 ERROR nova.virt.libvirt.driver > [req-b3e761b7-00fa-4930-bd9e-4330f8440c03 48086750fa13420888601964bb6a9d0d > 5ebe3484974848b182a381127cb35a22 - default default] [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] Failed to start libvirt guest: > libvirtError: internal error: libxenlight failed to create new domain > 'instance-00000008' > 2018-11-28 21:18:11.352 2384 INFO os_vif > [req-b3e761b7-00fa-4930-bd9e-4330f8440c03 48086750fa13420888601964bb6a9d0d > 5ebe3484974848b182a381127cb35a22 - default default] Successfully unplugged > vif > VIFBridge(active=False,address=fa:16:3e:6b:e4:b7,bridge_name='brq87fa0d9c-5e',has_traffic_filtering=True,id=484807ca-8c7c-4509-a5f5-ed7e5fd2078f,network=Network(87fa0d9c-5ed3-4332-8782-0d4139eed7f3),plugin='linux_bridge',port_profile=<?>,preserve_on_delete=False,vif_name='tap484807ca-8c') > 2018-11-28 21:18:11.554 2384 INFO nova.virt.libvirt.driver > [req-b3e761b7-00fa-4930-bd9e-4330f8440c03 48086750fa13420888601964bb6a9d0d > 5ebe3484974848b182a381127cb35a22 - default default] [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] Deleting instance files > /var/lib/nova/instances/9c2d08f3-0680-4709-a64d-ae1729a11304_del > 2018-11-28 21:18:11.556 2384 INFO nova.virt.libvirt.driver > [req-b3e761b7-00fa-4930-bd9e-4330f8440c03 48086750fa13420888601964bb6a9d0d > 5ebe3484974848b182a381127cb35a22 - default default] [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] Deletion of > /var/lib/nova/instances/9c2d08f3-0680-4709-a64d-ae1729a11304_del complete > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager > [req-b3e761b7-00fa-4930-bd9e-4330f8440c03 48086750fa13420888601964bb6a9d0d > 5ebe3484974848b182a381127cb35a22 - default default] [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] Instance failed to spawn: > libvirtError: internal error: libxenlight failed to create new domain > 'instance-00000008' > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] Traceback (most recent call last): > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] File > "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 2251, in > _build_resources > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] yield resources > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] File > "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 2031, in > _build_and_run_instance > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] > block_device_info=block_device_info) > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] File > "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py", line 3089, > in spawn > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] destroy_disks_on_failure=True) > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] File > "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py", line 5614, > in _create_domain_and_network > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] destroy_disks_on_failure) > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] File > "/usr/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in > __exit__ > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] self.force_reraise() > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] File > "/usr/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in > force_reraise > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] six.reraise(self.type_, > self.value, self.tb) > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] File > "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py", line 5583, > in _create_domain_and_network > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] > post_xml_callback=post_xml_callback) > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] File > "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py", line 5502, > in _create_domain > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] guest.launch(pause=pause) > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] File > "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/guest.py", line 144, in > launch > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] self._encoded_xml, > errors='ignore') > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] File > "/usr/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in > __exit__ > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] self.force_reraise() > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] File > "/usr/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in > force_reraise > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] six.reraise(self.type_, > self.value, self.tb) > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] File > "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/guest.py", line 139, in > launch > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] return > self._domain.createWithFlags(flags) > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] File > "/usr/lib/python2.7/dist-packages/eventlet/tpool.py", line 186, in doit > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] result = > proxy_call(self._autowrap, f, *args, **kwargs) > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] File > "/usr/lib/python2.7/dist-packages/eventlet/tpool.py", line 144, in > proxy_call > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] rv = execute(f, *args, **kwargs) > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] File > "/usr/lib/python2.7/dist-packages/eventlet/tpool.py", line 125, in execute > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] six.reraise(c, e, tb) > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] File > "/usr/lib/python2.7/dist-packages/eventlet/tpool.py", line 83, in tworker > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] rv = meth(*args, **kwargs) > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] File > "/usr/lib/python2.7/dist-packages/libvirt.py", line 1092, in createWithFlags > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] if ret == -1: raise libvirtError > ('virDomainCreateWithFlags() failed', dom=self) > 2018-11-28 21:18:11.614 2384 ERROR nova.compute.manager [instance: > 9c2d08f3-0680-4709-a64d-ae1729a11304] libvirtError: internal error: > libxenlight failed to create new domain 'instance-00000008' Anyone help me please. _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack(a)lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

2 1

[TripleO][Edge] Reduce base layer of containers for security and size of images (maintenance) sakes
by Bogdan Dobrelya 28 Nov '18

28 Nov '18

Changing the topic to follow the subject. [tl;dr] it's time to rearchitect container images to stop incluiding config-time only (puppet et al) bits, which are not needed runtime and pose security issues, like CVEs, to maintain daily. Background: 1) For the Distributed Compute Node edge case, there is potentially tens of thousands of a single-compute-node remote edge sites connected over WAN to a single control plane, which is having high latency, like a 100ms or so, and limited bandwith. Reducing the base layer size becomes a decent goal there. See the security background below. 2) For a generic security (Day 2, maintenance) case, when puppet/ruby/systemd/name-it gets a CVE fixed, the base layer has to be updated and all layers on top - to be rebuild, and all of those layers, to be re-fetched for cloud hosts and all containers to be restarted... And all of that because of some fixes that have nothing to OpenStack. By the remote edge sites as well, remember of "tens of thousands", high latency and limited bandwith?.. 3) TripleO CI updates (including puppet*) packages in containers, not in a common base layer of those. So each a CI job has to update puppet* and its dependencies - ruby/systemd as well. Reducing numbers of packages to update for each container makes sense for CI as well. Implementation related: WIP patches [0],[1] for early review, uses a config "pod" approach, does not require to maintain a two sets of config vs runtime images. Future work: a) cronie requires systemd, we'd want to fix that also off the base layer. b) rework to podman pods for docker-puppet.py instead of --volumes-from a side car container (can't be backported for Queens then, which is still nice to have a support for the Edge DCN case, at least downstream only perhaps). Some questions raised on IRC: Q: is having a service be able to configure itself really need to involve a separate pod? A: Highly likely yes, removing not-runtime things is a good idea and pods is an established PaaS paradigm already. That will require some changes in the architecture though (see the topic with WIP patches). Q: that's (fetching a config container) actually more data that about to download otherwise A: It's not, if thinking of Day 2, when have to re-fetch the base layer and top layers, when some unrelated to openstack CVEs got fixed there for ruby/puppet/systemd. Avoid the need to restart service containers because of those minor updates puched is also a nice thing. Q: the best solution here would be using packages on the host, generating the config files on the host. And then having an all-in-one container for all the services which lets them run in an isolated mannner. A: I think for Edge cases, that's a no go as we might want to consider tiny low footprint OS distros like former known Container Linux or Atomic. Also, an all-in-one container looks like an anti-pattern from the world of VMs. [0] https://review.openstack.org/#/q/topic:base-container-reduction [1] https://review.rdoproject.org/r/#/q/topic:base-container-reduction > Here is a related bug [1] and implementation [1] for that. PTAL folks! > > [0] https://bugs.launchpad.net/tripleo/+bug/1804822 > [1] https://review.openstack.org/#/q/topic:base-container-reduction > >> Let's also think of removing puppet-tripleo from the base container. >> It really brings the world-in (and yum updates in CI!) each job and each >> container! >> So if we did so, we should then either install puppet-tripleo and co on >> the host and bind-mount it for the docker-puppet deployment task steps >> (bad idea IMO), OR use the magical --volumes-from <a-side-car-container> >> option to mount volumes from some "puppet-config" sidecar container >> inside each of the containers being launched by docker-puppet tooling. > > On Wed, Oct 31, 2018 at 11:16 AM Harald Jensås <hjensas at redhat.com> > wrote: >> We add this to all images: >> >> https://github.com/openstack/tripleo-common/blob/d35af75b0d8c4683a677660646… >> >> /bin/sh -c yum -y install iproute iscsi-initiator-utils lvm2 python >> socat sudo which openstack-tripleo-common-container-base rsync cronie >> crudini openstack-selinux ansible python-shade puppet-tripleo python2- >> kubernetes && yum clean all && rm -rf /var/cache/yum 276 MB >> >> Is the additional 276 MB reasonable here? >> openstack-selinux <- This package run relabling, does that kind of >> touching the filesystem impact the size due to docker layers? >> >> Also: python2-kubernetes is a fairly large package (18007990) do we use >> that in every image? I don't see any tripleo related repos importing >> from that when searching on Hound? The original commit message[1] >> adding it states it is for future convenience. >> >> On my undercloud we have 101 images, if we are downloading every 18 MB >> per image thats almost 1.8 GB for a package we don't use? (I hope it's >> not like this? With docker layers, we only download that 276 MB >> transaction once? Or?) >> >> >> [1] https://review.openstack.org/527927 > > > > -- > Best regards, > Bogdan Dobrelya, > Irc #bogdando -- Best regards, Bogdan Dobrelya, Irc #bogdando

4 5

[Openstack] [OpenStack][cinder]Does cinder allocate disk to the volumes dynamically?
by Soheil Pourbafrani 28 Nov '18

28 Nov '18

Hi, I was wondering if the Cinder allocates disk to volumes statically or dynamically? _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack(a)lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

2 2

[tripleo] Let's improve upstream docs
by Marios Andreou 28 Nov '18

28 Nov '18

Hi folks, as just mentioned in the tripleo weekly irc meeting [1] some of us are trying to make small weekly improvements to the tripleo docs [2]. We are using this bug [3] for tracking and this effort is a result of some feedback during the recent Berlin summit. The general idea is 1 per week (or more if you can and want) - improvement/removal of stale content/identifying missing sections, or anything else you might care to propose. Please join us if you can, just add "Related-Bug: #1804642" to your commit message thanks [1] https://wiki.openstack.org/wiki/Meetings/TripleO [2] https://docs.openstack.org/tripleo-docs/latest/ [3] https://bugs.launchpad.net/tripleo/+bug/1804642

2 3

[kolla] Meeting 28-nov-2018 canceled
by Eduardo Gonzalez 28 Nov '18

28 Nov '18

Dear Kolla Team, Due to many people wont be able to attend today meeting, the Kolla weekly meeting on Wednesday 28th is canceled. Best regards

1 0

[dev] [nova] API updates week 18-48
by Ghanshyam Mann 28 Nov '18

28 Nov '18

Hi All, Please find the Nova API highlights of this week. Weekly Office Hour: =============== No Office hour (Alex was not online) - I did bug triage during that time. Triaged 5 bugs and updated the API bug report etherpad. Planned Features : ============== Below are the API related features for Stein. Ref - https://etherpad.openstack.org/p/stein-nova-subteam-tracking (feel free to add API item there if you are working or found any). NOTE: sequence order are not the priority, they are listed as per their start date. 1. Handling a down cell - https://blueprints.launchpad.net/nova/+spec/handling-down-cell - https://review.openstack.org/#/q/topic:bp/handling-down-cell+(status:open+O… - Weekly Progress: tssurya has progress on this and discussin with matt and melanie . 2. Servers Ips non-unique network names : - https://blueprints.launchpad.net/nova/+spec/servers-ips-non-unique-network-… - Spec Merged - https://review.openstack.org/#/q/topic:bp/servers-ips-non-unique-network-na… - Weekly Progress: No progress. I will take care of this after api policy improvement spec update. 3. Volume multiattach enhancements: - https://blueprints.launchpad.net/nova/+spec/volume-multiattach-enhancements - https://review.openstack.org/#/q/topic:bp/volume-multiattach-enhancements+(… - Weekly Progress: No progress. 4. Add API ref guideline for body text (takashin) - https://review.openstack.org/#/c/605628/ - Weekly Progress: It has one +2 and need one more +2. 5. Detach and attach boot volumes: - https://blueprints.launchpad.net/nova/+spec/detach-boot-volume - https://review.openstack.org/#/q/topic:bp/detach-boot-volume+(status:open+O… - Weekly Progress: No progress. Specs: 6. Nova API policy updates https://blueprints.launchpad.net/nova/+spec/granular-api-policy Spec: https://review.openstack.org/#/c/547850/ - Weekly Progress: No progress in this week. I will update the spec next week. 7. Nova API cleanup https://blueprints.launchpad.net/nova/+spec/api-consistency-cleanup Spec: https://review.openstack.org/#/c/603969/ - Weekly Progress: Updated the spec with review comment and added 2 more cleanup listed in etherpad 8. Support deleting data volume when destroy instance(Brin Zhang) - https://review.openstack.org/#/c/580336/ - Weekly Progress: No Progress this week. Waiting for spec review. COMPLETED: 1. API Extensions merge work - https://blueprints.launchpad.net/nova/+spec/api-extensions-merge-stein - https://review.openstack.org/#/q/project:openstack/nova+branch:master+topic… - Weekly Progress: This was COMPLETED few weeks back itself. 2. Boot instance specific storage backend - https://blueprints.launchpad.net/nova/+spec/boot-instance-specific-storage-… - https://review.openstack.org/#/q/topic:bp/boot-instance-specific-storage-ba… - Weekly Progress: COMPLETED Bugs: ==== This week Bug Progress: https://etherpad.openstack.org/p/nova-api-weekly-bug-report Critical: 0->0 High importance: 1->1 By Status: New: 5->2 Confirmed/Triage: 32-> 32 In-progress: 36->35 Incomplete: 5->6 ===== Total: 78->75 NOTE- There might be some bug which are not tagged as 'api' or 'api-ref', those are not in above list. Tag such bugs so that we can keep our eyes. -gmann

1 0

[openstack-dev] [Cyborg] IRC meeting still happens at usual time this Wednesday
by Li Liu 27 Nov '18

27 Nov '18

Hi Team, I know there is a polling on the new IRC meeting time, but before we gather more inputs, let's keep using the old time slot for this week (10PM Beijing Time/9AM EST/6AM PST) Agenda for this week's meeting: 1. Status update on NOVA interaction spec 2. Status update on DB scheme spec 3. Status tracking on all the open patches -- Thank you Regards Li __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

1 0

Re: [Openstack] [PackStack][Cinder]Save Volumes in The Compute nodes
by Soheil Pourbafrani 27 Nov '18

27 Nov '18

Thanks! and Does it need to cinder module to be installed on compute nodes? On Sat, Nov 17, 2018 at 1:13 PM Bernd Bausch <berndbausch(a)gmail.com> wrote: > Yes. You need to enable Cinder’s InstanceLocalityFilter, see > > https://docs.openstack.org/cinder/latest/configuration/block-storage/schedu… > . > > Here a tip: > https://ask.openstack.org/en/question/92001/cinder-lvm-volume-local-to-inst… > > Bernd > > On Nov 17, 2018, at 8:38, Soheil Pourbafrani <soheil.ir08(a)gmail.com> > wrote: > > Hi, > I have 8 servers with just local HDD disk. I want to use one server as the > controller and network node and the other (7 servers) as the compute node. > > I was wondering if it's possible to install PackStack that every compute > node to store its volumes in it's HDD local disk? (I guess the Cinder > should be installed on every Compute node alongside other settings) > > Thanks > > _______________________________________________ > Mailing list: > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack(a)lists.openstack.org > Unsubscribe : > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack(a)lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

6 8

[dev] [tc][all] TC office hours is started now on #openstack-tc
by Ghanshyam Mann 27 Nov '18

27 Nov '18

Hi All, TC office hour is started on #openstack-tc channel. Feel free to reach to us for anything you want discuss/input/feedback/help from TC. - TC

1 0

Any way to reply to archived messages?
by Ben Nemec 27 Nov '18

27 Nov '18

Let's say hypothetically someone procrastinated too long on the mailing list switchover and missed some messages on openstack-discuss, but now wants to reply to them. Is there any way to do that without breaking the threading in people's clients? Perhaps some way to request a message from the archive to be sent to me (err, this hypothetical person ;-). -Ben

2 2

[dev] Extracted placement repo is now used in devstack/grenade jobs on master
by Matt Riedemann 27 Nov '18

27 Nov '18

Now that [1] is merged, the extracted openstack/placement repo is being used in devstack and grenade testing for changes on master. This is part of a series of changes for the extraction [2] from nova but it's likely the one that will have the most impact (if any) to other projects on a daily basis because of our CI system. So this is just an FYI in case something goes off the rails in the near future, hit us in the mailing list or #openstack-placement (or #openstack-nova) IRC channels. [1] https://review.openstack.org/#/c/600162/ [2] https://etherpad.openstack.org/p/BER-placement-extract -- Thanks, Matt

1 0

[all][docs] Making the Contributor Portal More Useful Summary
by Kendall Nelson 27 Nov '18

27 Nov '18

Hello! If you’re interested in starting with the etherpad from this forum session, you can peruse that here[1]. The biggest part of the discussion here was that the page[2] is overloaded and most users don’t make it down the page to other information they might be looking for. It’s trying to be too many things at once and we need to simplify the pages. The plan is to split into one focused on contribution information and another focused more on general community info. If you have opinions on how the split should go and weren’t in the forum session, please let us know! Another idea that was discussed was some sort of wizard/decision tree to help people find the part of the portal they want based on 3ish questions: Know what project you’re looking for? (would open to project section of code and docs contribution type) Brand new to OpenStack? (would point to contributor guide or where we need help) Or Interested in a particular topic? (would open to project groups in code and docs contribution type) The rest of discussion centered on smaller changes to the contribution topics in the page. Adding tooltips, making certain things more obvious (like the think to the actual contributor guide), making sure Docs & i18n get included in the code & docs section since that pulls from the project navigator. If you’re interested in getting involved with this page, let me know! We don’t have this work currently tracked in Launchpad or StoryBoard because the page is maintained by the Foundation, but we are working to change that! -Kendall (diablo_rojo) [1]https://etherpad.openstack.org/p/BER-Contrib-Portal [2]https://www.openstack.org/community/

1 0

[scientific] IRC meeting today 2100 UTC - Handling controlled-access data
by Stig Telfer 27 Nov '18

27 Nov '18

Hi All - We have a Scientific SIG IRC meeting at 2100 UTC (about 45 minute’s time) in IRC channel #openstack-meeting. Everyone is welcome. Today we’d like to gather interested parties for reporting on best practice on handling sensitive data (for example, genomics or medical data, but not limited to that). We’d also like to talk on best practices for intensive AI & ML. The full agenda is here: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_November_27th_20… Cheers, Stig

1 0

[openstack-dev] [pacemaker] Live migration with VirtualDomain resource-agent
by Murali Annamneni 27 Nov '18

27 Nov '18

Hi, I'm trying to setup pacemaker for live-migration when a compute node hosting the VM goes down. So, I created cluster resource for the compute-instance (demo1) with 'VirtualDomain' resource agent. >>> pcs resource create demo1 VirtualDomain migrateuri="qemu+tcp://<DestinationCompuNode>:16509/system" config="/etc/pacemaker/demo1.xml" migration_transport="tcp" meta allow-migrate="true" op start timeout="120s" op stop timeout="180s" And I manually shutdown the compute node hosting the vm, but, I don't see the migration is happening. Can someone please help me what I am missing here ? Thanks & Regards, Murali __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

1 0

Re: [Openstack-operators] IMPORTANT: We're combining the lists!
by Jeremy Stanley 27 Nov '18

27 Nov '18

REMINDER: The openstack, openstack-dev, openstack-sigs and openstack-operators mailing lists (to which this was sent) are being replaced by a new openstack-discuss(a)lists.openstack.org mailing list. The new list[0] has been open for posts from subscribers since Monday November 19, and the old lists will be configured to no longer accept posts starting on Monday December 3. In the interim, posts to the old lists will also get copied to the new list so it's safe to unsubscribe from them now and not miss any messages. See my previous notice[1] for details. As of the time of this announcement, we have 403 subscribers on openstack-discuss with six days to go before the old lists are closed down for good). I have updated the old list descriptions to indicate the openstack-discuss list is preferred, and added a custom "welcome message" with the same for anyone who subscribes to them over the next week. [0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.ht… -- Jeremy Stanley _______________________________________________ OpenStack-operators mailing list OpenStack-operators(a)lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

1 0

Re: [Openstack-sigs] IMPORTANT: We're combining the lists!
by Jeremy Stanley 27 Nov '18

27 Nov '18

REMINDER: The openstack, openstack-dev, openstack-sigs and openstack-operators mailing lists (to which this was sent) are being replaced by a new openstack-discuss(a)lists.openstack.org mailing list. The new list[0] has been open for posts from subscribers since Monday November 19, and the old lists will be configured to no longer accept posts starting on Monday December 3. In the interim, posts to the old lists will also get copied to the new list so it's safe to unsubscribe from them now and not miss any messages. See my previous notice[1] for details. As of the time of this announcement, we have 403 subscribers on openstack-discuss with six days to go before the old lists are closed down for good). I have updated the old list descriptions to indicate the openstack-discuss list is preferred, and added a custom "welcome message" with the same for anyone who subscribes to them over the next week. [0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.ht… -- Jeremy Stanley _______________________________________________ openstack-sigs mailing list openstack-sigs(a)lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs

1 0

Re: [openstack-dev] IMPORTANT: We're combining the lists!
by Jeremy Stanley 27 Nov '18

27 Nov '18

REMINDER: The openstack, openstack-dev, openstack-sigs and openstack-operators mailing lists (to which this was sent) are being replaced by a new openstack-discuss(a)lists.openstack.org mailing list. The new list[0] has been open for posts from subscribers since Monday November 19, and the old lists will be configured to no longer accept posts starting on Monday December 3. In the interim, posts to the old lists will also get copied to the new list so it's safe to unsubscribe from them now and not miss any messages. See my previous notice[1] for details. As of the time of this announcement, we have 403 subscribers on openstack-discuss with six days to go before the old lists are closed down for good). I have updated the old list descriptions to indicate the openstack-discuss list is preferred, and added a custom "welcome message" with the same for anyone who subscribes to them over the next week. [0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.ht… -- Jeremy Stanley __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

1 0

Re: [Openstack] IMPORTANT: We're combining the lists!
by Jeremy Stanley 27 Nov '18

27 Nov '18

REMINDER: The openstack, openstack-dev, openstack-sigs and openstack-operators mailing lists (to which this was sent) are being replaced by a new openstack-discuss(a)lists.openstack.org mailing list. The new list[0] has been open for posts from subscribers since Monday November 19, and the old lists will be configured to no longer accept posts starting on Monday December 3. In the interim, posts to the old lists will also get copied to the new list so it's safe to unsubscribe from them now and not miss any messages. See my previous notice[1] for details. As of the time of this announcement, we have 403 subscribers on openstack-discuss with six days to go before the old lists are closed down for good). I have updated the old list descriptions to indicate the openstack-discuss list is preferred, and added a custom "welcome message" with the same for anyone who subscribes to them over the next week. [0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.ht… -- Jeremy Stanley _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack(a)lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

1 0

[Openstack-operators] Nova hypervisor uuid
by Ignazio Cassano 27 Nov '18

27 Nov '18

Hi All, Please anyone know where hypervisor uuid is retrived? Sometime updating kmv nodes with yum update it changes and in nova database 2 uuids are assigned to the same node. regards Ignazio _______________________________________________ OpenStack-operators mailing list OpenStack-operators(a)lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

2 1