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

[searchlight] Team meeting today at 13:30 UTC
by Trinh Nguyen 08 Apr '19

08 Apr '19

Hi team, We will have the team meeting today at 13:30 UTC on #openstack-searchlight IRC channel. Please look at the meeting agenda at https://etherpad.openstack.org/p/search-team-meeting-agenda Yours, -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

1 0

[Magnum] How to use docker CLI against a Magnum-managed Kubernetes cluster
by Namrata Sitlani 08 Apr '19

08 Apr '19

Hello, I am trying to use docker CLI against a Magnum-managed Kubernetes cluster so as to interact with its Docker registry. I followed the steps as explained in https://docs.openstack.org/magnum/rocky/user/#interfacing-with-a-secure-clu… but magnum does not setup docker on tcp port so it cannot be accessed outside the minion node(where docker is running). I appreciate any help guiding how to use docker CLI. Thanks Namrata Sitlani

2 1

Re: [OpenStack-I18n] Questions about Stein Dashboard UI translations
by Ian Y. Choi 07 Apr '19

07 Apr '19

"Team activities with release" are described in https://docs.openstack.org/i18n/latest/release_management.html , but let me first try to clarify more on I18n team activites with stable versions in Zanata regarding project release activities. Generally, there are two main reasons creating and maintaining stable versions in Zanata: 1. Hard StringFreezes with RC1, RC2, and so on : checking translation is much better using stable versions(with translation checksite, ideally) : That's why creating stable versions in Zanata is encouraged when there is first stable-xx branch in project repositories 2. Maintaining translation bugs on stable branches : There might be translation bugs on released artifacts - tranlation bugs can be fixed by editing stable versions in Zanata, syncing with project repos, and releasing new artifacts on target stable branches. : Usually, after final real stable artifacts are announced, then translations on stable versions from the first part are merged into master version for the next release. For the first part, Ideally, it would be excellent if there are enough translation demand, stable version creation activities in Zanata, translation activites on stable versions, communications via I18n-release cross project liaison, and review activities through translation checksite, and those are interactive together. If not, then I think I18n team needs to minimize the targets for such purpose or think differently how I18n team reacts with final new stable version creation. For the second part, the glad news I wanna share is that now all stable versions in Zanata now have content. More details are described in below: - Now projects mentioned in http://lists.openstack.org/pipermail/openstack-i18n/2019-March/003382.html should have "stable-stein" versions in Zanata : except "sahara-plugin-*" since there is no translated resource even on master version -> I wanna set that those will be synced only for master repos. - Some stable document versions including "keystone, octavia-dashboard, trove, watcher" projects were already filled translations from master (thanks a lot, Andreas and/or Frank!), but a few of them still had releasenotes documents, which need to be deleted on stable versions: "murano-dashboard, solum-dashboard, swift, trove-dashboard, zaqar, zaqar-ui, zun-ui". - One zh-CN translator did translations from empty content stable-stein version for ironic-ui project. Since the content were actually the same as master branch, I deleted stable-stein version on ironic-ui project, re-created stable-version by copying from master version, and removed releasenotes document on stable-stein version. - Strangely, there are no releasenotes document on master version for karbor-dashboard and neutron-lbaas-dashboard projects - need to be investigated further. As Train PTL, I will identify how much translations were for Stein release and try to find better ways how I18n team can work well regarding new release activites which will happen after around 6 months. With many thanks, /Ian Akihiro Motoki wrote on 4/5/2019 1:35 AM: > I see no content for stable-stein version for example in > neutron-fwaas-dashboard [1]. > What should we do? > I am really confused with the process around stable-stein cut.... > > [1] > https://translate.openstack.org/project/view/neutron-fwaas-dashboard?dswid=… > > On Mon, Apr 1, 2019 at 7:21 PM Frank Kloeker <eumel(a)arcor.de > <mailto:eumel@arcor.de>> wrote: > > Good morning, > > last week I was on a business trip and just wondering about ML > activities. But for sure, we have release weeks and thanks for > raising > up that topic. > Based on Ian's work I just cleaned up the Stein Dashboard with stable > branches as available [1]. So it's more clear what translators > have to > do, I mean translate stable branch instead of master. There is no > clear > handover between project teams when a stable branch is available, so > this needs to investigate by Zanata admin/PTL, or the failed job > list on > [2]. A lot of good jobs are already running on [3] > Further I investigted Ian's creation of empty versions in Zanata > and I > would say that won't work well, because that are post jobs and not > periodic jobs in Zuul. So if now merge on stable branch will > happen, the > po files won't sync to Zanata. Or it will take days, like in [4]. > On the > other hand, someone will translate things targeting in that release, > then it's required to copy the stable version from master as usually. > I know, this takes some time and work, but at the moment there is no > improvement because Zanata developement is already gone and the > feature > set on API is at it is. > > Regarding the second question for Horizon on translation check > site it > might be a question for the Horizon team. From my experience with > language settings it depends mostly on your browser settings. So > I'm not > sure if it's really a bug. > > kind regards > > Frank > > > [1] > https://translate.openstack.org/version-group/view/Stein-dashboard-translat… > [2] > http://zuul.openstack.org/builds?job_name=upstream-translation-update&job_n… > [3] > http://zuul.openstack.org/builds?job_name=upstream-translation-update&branc… > [4] > http://zuul.openstack.org/builds?job_name=upstream-translation-update&proje… > > > > > Am 2019-03-27 03:21, schrieb Yuko Katabami: > > Hi Frank and all, > > > > I have a couple of questions about Horizon UI translation. > > Hope you can help me. > > > > 1. Is stable-stein version going to be created soon in Zanata? I > > noticed that the projects in github already have the new branch. > > > > 2. With Octavia Dashboard, I am not able to see Japanese > translations > > in Horizon even though it is 100% completed in master. I can see > that > > po files are imported properly: > > > https://github.com/openstack/octavia-dashboard/tree/master/octavia_dashboar… > > Is there anything I need to do to be able to see it in my > environment? > > > > Many thanks in advance. > > > > Yuko > > _______________________________________________ > > OpenStack-I18n mailing list > > OpenStack-I18n(a)lists.openstack.org > <mailto:OpenStack-I18n@lists.openstack.org> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n > > > _______________________________________________ > OpenStack-I18n mailing list > OpenStack-I18n(a)lists.openstack.org > <mailto:OpenStack-I18n@lists.openstack.org> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n > > > _______________________________________________ > OpenStack-I18n mailing list > OpenStack-I18n(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n

1 0

Re: [Zun] Address already belongs to a bound Neutron port Error
by Hongbin Lu 07 Apr '19

07 Apr '19

On Thu, Apr 4, 2019 at 5:14 AM Navdeep Uniyal <navdeep.uniyal(a)bristol.ac.uk> wrote: > Hi Hongbin, > > > > I could not see the logs. I have installed zun on the baremetal machine > with full openstack (not devstack) > > -- Logs begin at Tue 2019-04-02 16:23:14 UTC, end at Thu 2019-04-04 > 09:05:59 UTC. -- > > -- No entries – > My bad. If you were following the installation guide, you should run "sudo journalctl -u kuryr-libnetwork" > > > Please advise me how can I enable logging for this. > > I can’t find anything in /etc/kuryr/kuryr.log > In my kuryr.conf file I have set the value to debug and the log file as > ‘/etc/kuryr/kuryr.log’ > It is systemd process so uses journalctl to retrieve the log. No further configuration is needed, although it is always helpful to turn on debug on troubleshooting > > My flat network is: > > openstack network show 5guknet > > > +---------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+ > > | Field | > Value > | > > > +---------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+ > > | admin_state_up | > UP > | > > | availability_zone_hints > | > | > > | availability_zones | > nova > | > > | created_at | > 2019-04-03T15:30:50Z > | > > | description > | > | > > | dns_domain | > None > | > > | id | > a9decbf0-e8c8-4574-86f8-242756fce63b > | > > | ipv4_address_scope | > None > | > > | ipv6_address_scope | > None > | > > | is_default | > False > | > > | is_vlan_transparent | > None > | > > | mtu | > 1500 > | > > | name | > 5guknet > | > > | port_security_enabled | True > | > > | project_id | > a8888997d0da4d3d80fe7ca833e74bb7 > | > > | provider:network_type | > flat > | > > | provider:physical_network | 5guknet > | > > | provider:segmentation_id | > None > | > > | qos_policy_id | > None > | > > | revision_number | 4 > | > > | router:external | > External > | > > | segments | > None > | > > | shared | True > | > > | status | > ACTIVE > | > > | subnets | > e684a17b-6b17-4ea2-bbc9-752a21304dcc > | > > | tags | kuryr.net.existing:7c34de9e89a3, > kuryr.net.uuid.lh:7c34de9e89a3e86ee3561834520bc2ea, > kuryr.net.uuid.uh:35c16ff10c1821c06a7098833e0bf131 | > > | updated_at | > 2019-04-03T15:33:37Z > | > > > +---------------------------+-----------------------------------------------------------------------------------------------------------------------------------------+ > > > > Subnet: > > openstack subnet show e684a17b-6b17-4ea2-bbc9-752a21304dcc > > +-------------------+--------------------------------------+ > > | Field | Value | > > +-------------------+--------------------------------------+ > > | allocation_pools | 10.68.48.131-10.68.48.150 | > > | cidr | 10.68.48.0/24 | > > | created_at | 2019-04-03T15:30:51Z | > > | description | | > > | dns_nameservers | 8.8.8.8 | > > | enable_dhcp | True | > > | gateway_ip | 10.68.48.1 | > > | host_routes | | > > | id | e684a17b-6b17-4ea2-bbc9-752a21304dcc | > > | ip_version | 4 | > > | ipv6_address_mode | None | > > | ipv6_ra_mode | None | > > | name | 5guknet | > > | network_id | a9decbf0-e8c8-4574-86f8-242756fce63b | > > | project_id | a8888997d0da4d3d80fe7ca833e74bb7 | > > | revision_number | 1 | > > | segment_id | None | > > | service_types | | > > | subnetpool_id | None | > > | tags | b130d090-9b7f-4c68-9f45-775a18bbb649 | > > | updated_at | 2019-04-03T15:33:37Z | > > +-------------------+--------------------------------------+ > > > > Port: > openstack port show 8b203580-2051-4ad0-8057-c7885324d0b9 > > > +-----------------------+-----------------------------------------------------------------------------+ > > | Field | > Value > | > > > +-----------------------+-----------------------------------------------------------------------------+ > > | admin_state_up | UP > | > > | allowed_address_pairs > | > | > > | binding_host_id | > bedminster > | > > | binding_profile > | > | > > | binding_vif_details | > port_filter='True' > | > > | binding_vif_type | bridge > | > > | binding_vnic_type | > normal > | > > | created_at | > 2019-04-04T09:05:33Z > | > > | data_plane_status | > None > | > > | description > | > | > > | device_id | > c6428670-2846-4862-8ecb-611293cabc2c > | > > | device_owner | > compute:kuryr > | > > | dns_assignment | > None > | > > | dns_domain | > None > | > > | dns_name | > None > | > > | extra_dhcp_opts > | > | > > | fixed_ips | ip_address='10.68.48.143', > subnet_id='e684a17b-6b17-4ea2-bbc9-752a21304dcc' | > > | id | 8b203580-2051-4ad0-8057-c7885324d0b9 > | > > | mac_address | > fa:16:3e:2e:07:ad > | > > | name > | > | > > | network_id | > a9decbf0-e8c8-4574-86f8-242756fce63b > | > > | port_security_enabled | > True > | > > | project_id | a8888997d0da4d3d80fe7ca833e74bb7 > | > > | qos_policy_id | > None > | > > | revision_number | > 2 > | > > | security_group_ids | > 49839b6f-79c7-4db7-bb71-ffecbdd645d5 > | > > | status | > DOWN > | > > | tags > | > | > > | trunk_details | > None > | > > | updated_at | 2019-04-04T09:05:33Z > | > > > +-----------------------+-----------------------------------------------------------------------------+ > > Thank you, > > Kind Regards, > > Navdeep > > > > > > *From:* Hongbin Lu <hongbin034(a)gmail.com> > *Sent:* 04 April 2019 02:49 > *To:* Navdeep Uniyal <navdeep.uniyal(a)bristol.ac.uk> > *Cc:* openstack(a)lists.openstack.org > *Subject:* Re: [Zun] Address already belongs to a bound Neutron port Error > > > > Hi Navdeep, > > > > It looks I cannot reproduce the problem using rocky with flat network. If > possible, would you provide the following: > > > > * Your kuryr-libnetwork log (with sensitive information removed). You can > get it by running "sudo journalctl -u devstack@kuryr-libnetwork". > > * Your flat network (openstack network show XXX) > > * Your subnet (openstack subnet show e684a17b-6b17-4ea2-bbc9-752a21304dcc) > > * Your port (openstack port show f0d6153a-7408-4cd5-82c3-9abed48ad056) > > > > Best regards, > > Hongbin > > > > On Wed, Apr 3, 2019 at 11:52 AM Navdeep Uniyal < > navdeep.uniyal(a)bristol.ac.uk> wrote: > > Dear All, > > > > I have just installed Zun and tried creating a container following the > instructions as per the following webpage: > > https://docs.openstack.org/zun/rocky/install/index.html > > > > I am getting following error while starting my test container using > ‘openstack appcontainer run --name container2 --net network=$NET_ID cirros > ping 8.8.8.8’: > > > > status_reason | Docker internal error: 500 Server Error: Internal > Server Error ("IpamDriver.RequestAddress: Requested ip address > {'subnet_id': u'e684a17b-6b17-4ea2-bbc9-752a21304dcc', 'ip_address': > u'10.68.48.147'} already belongs to a bound Neutron port: > f0d6153a-7408-4cd5-82c3-9abed48ad056"). > > > > The network I selected is a flat network on openstack with external flag > true. > > Please advise me how to solve the issue or if there is a specific > requirement for this. > > > > Thank you, > > Kind Regards, > > Navdeep > >

2 6

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

06 Apr '19

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

5 6

[tc][ptl][all] Completion Report: OpenStack gate testing migration to Bionic (Ubuntu LTS 18.04)
by Ghanshyam Mann 06 Apr '19

06 Apr '19

Hello Everyone, We have all patches merged now for legacy job migration to bionic. All the legacy and zuulv3 native jobs are running on Bionic in stable/stein onwards. This means we have completed our stein testing runtime[1] in OpenStack as a whole. Thanks a lot to all of the teams for such nice coordination. Summary: - Started this migration very late in stein (in Dec 2018) - FInished migration in 2 part. 1. zuulv3 native job migration, 2. legacy jobs migration. - networking-midonet bionic jobs are n-v as it is not yet ready on bionic. - ~50 patches merged to migrate the gate jobs - ~ 60 DNM testing patches done before migration happens - We managed no big gate break for any project. Except for Cinder which was for 1 day I think. Ref: - https://review.openstack.org/#/q/(topic:legacy-job-bionic+OR+topic:legacy-j… - https://review.openstack.org/#/q/topic:devstack-bionic - http://lists.openstack.org/pipermail/openstack-discuss/2019-March/004268.ht… - http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003598.ht… - https://etherpad.openstack.org/p/legacy-job-bionic - http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000837… - https://etherpad.openstack.org/p/devstack-bionic [1] https://governance.openstack.org/tc/reference/runtimes/stein.html -gmann

6 5

[ec2api] SSL Problem
by Georgios Dimitrakakis 06 Apr '19

06 Apr '19

Dear all, I am trying to setup ec2-api with SSL support on Rocky and no matter what I do I am getting the following error in the logs (/var/log/messages) ec2-api: SSLError: [SSL: SSL_HANDSHAKE_FAILURE] ssl handshake failure (_ssl.c:1822) and in the end ec2-api: SSLError: [SSL: PEER_DID_NOT_RETURN_A_CERTIFICATE] peer did not return a certificate (_ssl.c:1822) The full trace can be found here: https://pastebin.com/iPHXudag (where I have hidden the hostname) What I have done is that in "ec2api.conf" I have set the ca_file, cert_file and key_file pointing to the same files that Openstack's Dashboard is using which can be accessed without a problem. Afterwards I have restarted all ec2 services meaning both the "openstack-ec2-api-metadata.service" and "openstack-ec2-api.service". Using openssl cli and trying to connect to port 8788 I am seeing somewhere in the middle the error: SSL_connect:SSLv3 write client key exchange A write to 0x26c3e30 [0x2721290] (6 bytes => -1 (0xFFFFFFFFFFFFFFFF)) SSL_connect:error in SSLv3 write finished A SSL_connect:error in SSLv3 write finished A write:errno=32 The same openssl cli for port 443 (dashboard) works out of the box without a problem Obviously the cert is not served properly but cannot figure out why... Needless to say that I have tripled checked for any spelling mistakes, permissions etc. but I am open to suggestions. I have set ec2api to "Debug" mode but there isn't anything useful in the logs and in fact is not writing anything except a line like the one below when trying to access it: 2019-04-06 01:25:03.805 211954 DEBUG ec2api.wsgi.server [-] (211954) accepted ('xxx.xxx.xxx.xxx', 60154) server /usr/lib/python2.7/site-packages/eventlet/wsgi.py:883 Can someone shed some light please? If there is anything that you would like me to share with you like the openssl CLI's output or the ec2api.log please let me know. Best regards, G.

2 3

octavia 4.0.0.0rc3 (stein)
by no-reply＠openstack.org 06 Apr '19

06 Apr '19

Hello everyone, A new release candidate for octavia for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/octavia/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://git.openstack.org/cgit/openstack/octavia/log/?h=stable/stein Release notes for octavia can be found at: https://docs.openstack.org/releasenotes/octavia/ If you find an issue that could be considered release-critical, please file it at: https://storyboard.openstack.org/#!/project/908 and tag it *stein-rc-potential* to bring it to the octavia release crew's attention.

1 0

[telemetry] how does one can participate in the telemetry planning for train?
by Miguel Lavalle 06 Apr '19

06 Apr '19

Hi Telemetry Team, Some of my co-workers are interested in participating in the up-coming telemetry planning for Train ( https://etherpad.openstack.org/p/telemetry-train) How can we get the url of the Google hangout? Best regards Miguel

1 0

[requirements][FFE][congress] lower psycopg2 requirement to 2.5.1
by Eric K 06 Apr '19

06 Apr '19

Requesting exception to lower a requirement to resolve a packaging issue. https://review.openstack.org/#/c/650100/

4 7

[nova] XenProject and XenServer CIs not running
by Stephen Finucane 05 Apr '19

05 Apr '19

I've proposed a patch to remove the 'devstack/tempest-dsvm-tempest-xen- rc' from nova [1]. Matt Riedemann pointed out that this may have been used by the XenProject or XenServer CIs. However, it appears that these CIs are not currently running and haven't been in the past 7 days [2]. Could anyone advise if this is a temporary glitch or if the CIs are offline for the foreseeable future? Similarly, could anyone say if that file is safe to remove and, if not, what's using it? Thanks, Stephen [1] https://review.openstack.org/650018 [2] http://ciwatch.mmedvede.net/project?project=nova&time=7+days

2 1

[dev][keystone] Keystone Team Update - Week of 1 April 2019
by Colleen Murphy 05 Apr '19

05 Apr '19

# Keystone Team Update - Week of 1 April 2019 ## News ### RC2 and Stein Release We landed everything we had planned for RC2 and released it this week[1]. The final release is scheduled for next week[2]. [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004526.ht… [2] https://review.openstack.org/650362 ### Train Planning In advance of the PTG, I've started prepping keystone specs we already know we want to work on in Train[3] and started the Train Roadmap Trello board[4]. Please take a look at both to refresh your memory on what we had planned but didn't finish in past cycles so that we can discuss what to keep and what to scrap for this cycle. We should also talk about our specs backlog[5] and prune it if there are specs that are no longer relevant. [3] https://review.openstack.org/650126 [4] https://trello.com/b/ClKW9C8x/keystone-train-roadmap [5] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/backlog/ ### PTG Planning I've proposed a rough agenda for the PTG[6]. Since our schedule doesn't start until Thursday afternoon, we won't formally meet Thursday morning but we will have time to meet with the QA team and Edge groups who are having sessions at that time. Thursday afternoon we will meet and recap the Forum sessions and decide if we want to change the agenda schedule meetings with other teams. [6] https://etherpad.openstack.org/p/keystone-train-ptg ## Recently Merged Changes Search query: https://bit.ly/2pquOwT We merged 18 changes this week, which included everything we had planned for RC2. ## Changes that need Attention Search query: https://bit.ly/2tymTje There are 40 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. ## Bugs This week we opened 1 new bug and closed 2. Bugs opened (1) Bug #1823258 (keystone:Undecided) opened by Colleen Murphy https://bugs.launchpad.net/keystone/+bug/1823258 Bugs fixed (2) Bug #1808859 (keystone:High) fixed by Colleen Murphy https://bugs.launchpad.net/keystone/+bug/1808859 Bug #1801873 (keystone:Medium) fixed by Colleen Murphy https://bugs.launchpad.net/keystone/+bug/1801873 ## Milestone Outlook https://releases.openstack.org/stein/schedule.html The final release for Stein was proposed today[7] and the actual release will take place next week. [7] https://review.openstack.org/650362 ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter

1 0

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

05 Apr '19

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

6 15

[nova] Train Runways Etherpad Is Live!
by Eric Fried 05 Apr '19

05 Apr '19

Nova contributors and reviewers- I have seeded the runways etherpad for Train [1] (by copying from the Stein version [2]). As of this writing, I see six approved Train blueprints [3]. If you own one of these, and your code is ready, please register it in the Queue section of the etherpad and alert us in #openstack-nova. Thanks, efried [1] https://etherpad.openstack.org/p/nova-runways-train [2] https://etherpad.openstack.org/p/nova-runways-stein [3] https://blueprints.launchpad.net/nova/train

1 0

Integration with GuardianKey
by Paulo Angelo 05 Apr '19

05 Apr '19

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

3 2

[PTL][release] Final releases for Stein proposed
by Sean McGinnis 05 Apr '19

05 Apr '19

Greetings! With yesterday's final RC deadline past, I have now proposed a patch for the final releases for all cycle-with-rc projects for Stein. https://review.openstack.org/#/c/650362/ We would love to have all PTLs provide a +1 on that patch. While not strictly necessary, it is great to see everyone's acknowledgement of the patch. Plus you will all get included in the metedata for the final tag, so it makes a great record. Thanks! Sean

1 0

kolla-ansible 8.0.0.0rc1 (stein)
by no-reply＠openstack.org 05 Apr '19

05 Apr '19

Hello everyone, A new release candidate for kolla-ansible for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/kolla-ansible/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://git.openstack.org/cgit/openstack/kolla-ansible/log/?h=stable/stein Release notes for kolla-ansible can be found at: https://docs.openstack.org/releasenotes/kolla-ansible/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/kolla-ansible/+bugs and tag it *stein-rc-potential* to bring it to the kolla-ansible release crew's attention.

1 0

kolla 8.0.0.0rc1 (stein)
by no-reply＠openstack.org 05 Apr '19

05 Apr '19

Hello everyone, A new release candidate for kolla for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/kolla/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://git.openstack.org/cgit/openstack/kolla/log/?h=stable/stein Release notes for kolla can be found at: https://docs.openstack.org/releasenotes/kolla/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/kolla/+bugs and tag it *stein-rc-potential* to bring it to the kolla release crew's attention.

1 0

[placement] update 19-13
by Chris Dent 05 Apr '19

05 Apr '19

HTML: https://anticdent.org/placement-update-19-13.html Placement update 19-13 is brought to you by the letters P and U. # Most Important The [Virtual Pre-PTG](http://lists.openstack.org/pipermail/openstack-discuss/2019-March/… starts next week. Watch out for emails to start different threads throughout the week. Also next week there will be a Nova pre-PTG [spec review](http://lists.openstack.org/pipermail/openstack-discuss/2019-April/t…. Plenty of the pending work touches on placement. In the meantime here are a couple of etherpads for the PTG: * <https://etherpad.openstack.org/p/placement-ptg-train> * <https://etherpad.openstack.org/p/ptg-train-xproj-nova-placement> # What's Changed * There were some lingering docs and log fixes so we released an RC 3 of Placement. That candidate will become 1.0.0 on April 10th. * Microversion 1.32, for [forbidden aggregates](https://docs.openstack.org/placement/latest/placement-api-micro… merged. * We've decided it would be nice to a) release os-traits and os-resource-classes in an independent fashion and, b) make them available to both placement and nova as tox-siblings. We'll do (a) once release time settles. For (b) the strategy is still a bit up in the air. There's some [email discussion](http://lists.openstack.org/pipermail/openstack-discuss/2019-Apr…. # Specs/Features * Two traits related specs have been re-proposed to Train, following the [new process](https://docs.openstack.org/placement/latest/contributor/contributi…. * <https://review.openstack.org/649992> Spec: support any trait in allocation candidates * <https://review.openstack.org/649368> Spec: support mixing required traits with any traits * As before, the spec for [request group mapping](https://review.openstack.org/597601) will need to be revisited. # Bugs * StoryBoard stories in [the placement group](https://storyboard.openstack.org/#!/project_group/placement): 6. 0 are [untagged](https://storyboard.openstack.org/#!/worklist/580). * Placement related [bugs not yet in progress](https://goo.gl/TgiPXb): 13. -1. * [In progress placement bugs](https://goo.gl/vzGGDQ) 5. -2. Once Stein has settled, we'll figure out a good time to have a bug cleanup and consolidation. # osc-placement osc-placement is currently behind by 14 microversions. +1 since last week. Pending changes: * [support for 1.19](https://review.openstack.org/#/c/641094/) * [support for 1.21](https://review.openstack.org/#/c/641123/) * [aggregate allocation ratio tool](https://review.openstack.org/#/c/640898/) * [stack to fix docs and classifiers](https://review.openstack.org/650093) # Main Themes Be thinking about what you'd like the main themes to be. Put them on the [PTG etherpad](https://etherpad.openstack.org/p/placement-ptg-train). # Other Placement * <https://review.openstack.org/#/c/645255/> This is a start at unit tests for the PlacementFixture. It is proving a bit "fun" to get right, as there are many layers involved. Making sure seemingly unrelated changes in placement don't break the nova gate is important. Besides these unit tests, there's discussion on the PTG etherpad of running the nova functional tests, or a subset thereof, in placement's check run. On the one hand this is a pain and messy, but on the other consider what we're enabling: Functional tests that use the real functionality of an external service (real data, real web requests), not stubs or fakes. * <https://review.openstack.org/641404> Use ``code`` role in api-ref titles * <https://review.openstack.org/649618> Removing some unused code. # Other Service Users New discoveries are added to the end. Merged stuff is removed. Since last week 2 removals (by merge), 7 new discoveries. * <https://review.openstack.org/552924> Nova: Spec: Proposes NUMA topology with RPs * <https://review.openstack.org/622893> Nova: Spec: Virtual persistent memory libvirt driver implementation * <https://review.openstack.org/641899> Nova: Check compute_node existence in when nova-compute reports info to placement * <https://review.openstack.org/601596> Nova: spec: support virtual persistent memory * <https://review.openstack.org/#/q/topic:bug/1790204> Workaround doubling allocations on resize * <https://review.openstack.org/555081> Nova: Spec: Standardize CPU resource tracking * <https://review.openstack.org/646029> Nova: Spec: Use in_tree getting allocation candidates * <https://review.openstack.org/645316> Nova: Pre-filter hosts based on multiattach volume support * <https://review.openstack.org/606199> Ironic: A fresh way of looking at step retrieval * <https://review.openstack.org/647396> Nova: Add flavor to requested_resources in RequestSpec * <https://review.openstack.org/633204> Blazar: Retry on inventory update conflict * <https://review.openstack.org/640080> Nova: Use aggregate_add_host in nova-manage * <https://review.openstack.org/#/q/topic:bp/count-quota-usage-from-placement> Nova: count quota usage from placement * <https://review.openstack.org/#/q/topic:bug/1819923> Nova: nova-manage: heal port allocations * <https://review.openstack.org/624335> puppet-tripleo: Initial extraction of the Placement service from Nova * <https://review.openstack.org/#/q/topic:bug/1821824> Nova: bug fix prevent forbidden traits from working as expected * <https://review.openstack.org/648665> Nova: Spec for a new nova virt driver to manage an RSD * <https://review.openstack.org/#/c/642067/> Helm: Allow more generic overrides for nova placement-api * <https://review.openstack.org/647578> Nova: add spec for image metadata prefiltering * <https://review.openstack.org/609960> Support filtering of allocation_candidates by forbidden aggregates * <https://review.openstack.org/#/q/topic:bp/use-placement-in-tree> Enable in_tree allocation candidates from the nova side * <https://review.openstack.org/650143> openstack-ansible: Remove deprecated scheduler filters * <https://review.openstack.org/625284> Cyborg: Initially readme for nova pilot * <https://review.openstack.org/629142> Tempest: Add QoS policies and minimum bandwidth rule client * <https://review.openstack.org/641994> Nova-spec: Re-approve AMD SEV support for Train * <https://review.openstack.org/648687> Nova-spec: Add PENDING vm state # End Latency is the mind-killer. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

1 0

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

05 Apr '19

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

7 6

Openstack attaching same pci device to 2 different vms?
by Manuel Sopena Ballesteros 05 Apr '19

05 Apr '19

Dear Openstack community, I recently setup pci-passthrough against nvme drives to directly attach the disks to the vm as a block device. I created 2 vms on the same physical host and I can see the disks (nvme0n1) on both of them: [centos@test-nvme-small ~]$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vda 253:0 0 10G 0 disk └─vda1 253:1 0 10G 0 part / nvme0n1 259:0 0 1.8T 0 disk [centos@test-nvme-small-2 ~]$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vda 253:0 0 10G 0 disk └─vda1 253:1 0 10G 0 part / nvme0n1 259:0 0 1.8T 0 disk So I wanted to check which nvme device was attached to which vm. I thought one option would be to dump the vm xml file from virsh which can be found below (I am only putting the information between the disks section but happy to attach the hole file if needed): Device/disk configuration for instance-00000094 <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='none'/> <source file='/var/lib/nova/instances/fd95cc45-1501-4693-8643-944be2ff4625/disk'/> <backingStore type='file' index='1'> <format type='raw'/> <source file='/var/lib/nova/instances/_base/4cc6eebe175e35178cb81853818a1eb103cea937'/> <backingStore/> </backingStore> <target dev='vda' bus='virtio'/> <alias name='virtio-disk0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </disk> Device/disk configuration for instance-00000093 <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='none'/> <source file='/var/lib/nova/instances/7e6a055c-1b4e-458c-89cd-cb8c1d10e939/disk'/> <backingStore type='file' index='1'> <format type='raw'/> <source file='/var/lib/nova/instances/_base/4cc6eebe175e35178cb81853818a1eb103cea937'/> <backingStore/> </backingStore> <target dev='vda' bus='virtio'/> <alias name='virtio-disk0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </disk> Based on this output and If I am not mistaken I am under the impression that the host pci device attached to both vms is 0000:00:04.0 Questions: Is there an Openstack way to check which pci devices are attached to which vms instead of having to dump the vm xml file? Am I right assuming that the same disk is attached to both vms? If yes, how can that happen? Thank you very much NOTICE Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.

3 3

octavia 4.0.0.0rc2 (stein)
by no-reply＠openstack.org 05 Apr '19

05 Apr '19

Hello everyone, A new release candidate for octavia for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/octavia/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://git.openstack.org/cgit/openstack/octavia/log/?h=stable/stein Release notes for octavia can be found at: https://docs.openstack.org/releasenotes/octavia/ If you find an issue that could be considered release-critical, please file it at: https://storyboard.openstack.org/#!/project/908 and tag it *stein-rc-potential* to bring it to the octavia release crew's attention.

1 0

openstack-congress 9.0.0.0rc2 (stein)
by no-reply＠openstack.org 05 Apr '19

05 Apr '19

Hello everyone, A new release candidate for openstack-congress for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/congress/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://git.openstack.org/cgit/openstack/congress/log/?h=stable/stein Release notes for openstack-congress can be found at: https://docs.openstack.org/releasenotes/congress/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/congress/+bugs and tag it *stein-rc-potential* to bring it to the openstack-congress release crew's attention.

1 0

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

05 Apr '19

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

10 19

nova 19.0.0.0rc2 (stein)
by no-reply＠openstack.org 05 Apr '19

05 Apr '19

Hello everyone, A new release candidate for nova for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/nova/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://git.openstack.org/cgit/openstack/nova/log/?h=stable/stein Release notes for nova can be found at: https://docs.openstack.org/releasenotes/nova/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/nova/+bugs and tag it *stein-rc-potential* to bring it to the nova release crew's attention.

1 0

[nova] Down cell testing with devstack
by Matt Riedemann 05 Apr '19

05 Apr '19

Just an FYI but I've posted a docs patch with a testing guide for recreating a down-cell environment with a simple devstack setup: https://review.openstack.org/#/c/650167/ I had done this awhile back and had it on my todo list to make sure this was documented for the next time I need to do some manual testing with down cells. -- Thanks, Matt

1 0

[requirements][FFE][congress] remove psycopg2>=2.7
by Eric K 05 Apr '19

05 Apr '19

Requesting exception to remove a requirement to resolve a packaging issue. The package is needed only for an experimental feature, but causes packaging issue on RHEL/CentOS 7. Propose to remove from requirements and require manual install to enable the experimental feature. https://review.openstack.org/#/c/649772/

5 11

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

04 Apr '19

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

1 2

openstack-heat 12.0.0.0rc2 (stein)
by no-reply＠openstack.org 04 Apr '19

04 Apr '19

Hello everyone, A new release candidate for openstack-heat for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/heat/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://git.openstack.org/cgit/openstack/heat/log/?h=stable/stein Release notes for openstack-heat can be found at: https://docs.openstack.org/releasenotes/heat/ If you find an issue that could be considered release-critical, please file it at: https://storyboard.openstack.org/#!/project/989 and tag it *stein-rc-potential* to bring it to the openstack-heat release crew's attention.

1 0

mistral-dashboard 8.0.0.0rc2 (stein)
by no-reply＠openstack.org 04 Apr '19

04 Apr '19

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

1 0

mistral 8.0.0.0rc2 (stein)
by no-reply＠openstack.org 04 Apr '19

04 Apr '19

Hello everyone, A new release candidate for mistral for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/mistral/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://git.openstack.org/cgit/openstack/mistral/log/?h=stable/stein Release notes for mistral can be found at: https://docs.openstack.org/releasenotes/mistral/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/mistral/+bugs and tag it *stein-rc-potential* to bring it to the mistral release crew's attention.

1 0

mistral-extra 8.0.0.0rc2 (stein)
by no-reply＠openstack.org 04 Apr '19

04 Apr '19

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

1 0

murano 7.0.0.0rc2 (stein)
by no-reply＠openstack.org 04 Apr '19

04 Apr '19

Hello everyone, A new release candidate for murano for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/murano/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://git.openstack.org/cgit/openstack/murano/log/?h=stable/stein Release notes for murano can be found at: https://docs.openstack.org/releasenotes/murano/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/murano/+bugs and tag it *stein-rc-potential* to bring it to the murano release crew's attention.

1 0

magnum 8.0.0.0rc2 (stein)
by no-reply＠openstack.org 04 Apr '19

04 Apr '19

Hello everyone, A new release candidate for magnum for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/magnum/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://git.openstack.org/cgit/openstack/magnum/log/?h=stable/stein Release notes for magnum can be found at: https://docs.openstack.org/releasenotes/magnum/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/magnum/+bugs and tag it *stein-rc-potential* to bring it to the magnum release crew's attention.

1 0

horizon 15.0.0.0rc2 (stein)
by no-reply＠openstack.org 04 Apr '19

04 Apr '19

Hello everyone, A new release candidate for horizon for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/horizon/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://git.openstack.org/cgit/openstack/horizon/log/?h=stable/stein Release notes for horizon can be found at: https://docs.openstack.org/releasenotes/horizon/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/horizon/+bugs and tag it *stein-rc-potential* to bring it to the horizon release crew's attention.

1 0

[release] Release countdown for week R-0, April 8-12
by Sean McGinnis 04 Apr '19

04 Apr '19

This is the final countdown email for the Stein development cycle. Thanks to everyone involved in the Stein release! Development Focus ----------------- Teams attending the PTG should be preparing for those discussions and capturing information in the etherpads: https://wiki.openstack.org/wiki/PTG/Train/Etherpads General Information ------------------- The release team plans on doing the final Stein release on 10 April. We will re-tag the last commit used for the final RC using the final version number. If you have not already done so, now would be a good time to take a look at the Train schedule and start planning team activities: https://releases.openstack.org/train/schedule.html Actions --------- PTLs and release liaisons should watch for the final release patch from the release team. While not required, we would appreciate having an ack from each team before we approve it on the 10th. Upcoming Deadlines & Dates -------------------------- Final RC deadline: April 1 Final Stein release: April 10 -- Sean McGinnis (smcginnis)

1 0

Re: Help with kernel panic on cirros image boot process.
by Jorge Luiz Correa 04 Apr '19

04 Apr '19

> We have the same issue in the upstream CI system with the cirros 0.3.5 > image: > > http://status.openstack.org/elastic-recheck/#1737039 > > Have you tried using the 0.4.0 image? Yes, I'm using cirros-0.4.0-x86_64-disk.img. Same problem with randomly kernel panic on boot. Thanks.

1 0

[qa][patrole] get_tenant_network found None
by Sergey Vilgelm 04 Apr '19

04 Apr '19

Hello, There is an issue with get_tenant_network function in the Patrole tests. Zuul failed on patch set [0] due to 'Multiple possible networks found, use a Network ID to be more specific’[1]. Tempest logs[2] contain an message: '(ServerActionsRbacTest:setUpClass) Found network None available for tenant’. Who knows why this can happen? I have an idea, that this could happen in case of a parallel test running and one test rewrote the roles and another test didn’t find a tenant's network at same time because of the wrong roles. [0] https://review.openstack.org/#/c/648255/ [1] http://logs.openstack.org/55/648255/1/check/patrole-admin/63b6639/testr_res… [2] http://logs.openstack.org/55/648255/1/check/patrole-admin/63b6639/controlle… -- Sergey Vilgelm https://www.vilgelm.info

2 3

[oslo] No meeting next week
by Ben Nemec 04 Apr '19

04 Apr '19

I forgot to mention it in the meeting this week, but I'll be on PTO next week (the 8th to the 12th) so there won't be a meeting. Unless someone else wants to run it, of course. I'll be back the following week and we'll get back to our regular schedule for a couple of weeks and then it will be Summit/PTG. I'm going to try to take a look at the oslo.service sighup patch before I leave, but if there's anything else pressing let me know ASAP. Thanks. -Ben

1 0

SFC delete port chain failed
by Navdeep Uniyal 04 Apr '19

04 Apr '19

Dear All, I am facing errors while creating/deleting the SF Chain: 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager [req-d03ef918-2314-4728-bb8b-c5670b4b9da1 c8c777caa52b45649a6c312b38e81956 1c915b508cfa4c799389bf354fceb056 - default default] 'PortChainContext' object has no attribute 'session': AttributeError: 'PortChainContext' object has no attribute 'session' 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager Traceback (most recent call last): 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py", line 101, in _call_drivers 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager getattr(driver.obj, method_name)(context) 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager File "/usr/lib/python2.7/dist-packages/oslo_log/helpers.py", line 67, in wrapper 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager return method(*args, **kwargs) 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 887, in delete_port_chain 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager self._delete_portchain_path(context, port_chain) 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager File "/usr/lib/python2.7/dist-packages/oslo_log/helpers.py", line 67, in wrapper 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager return method(*args, **kwargs) 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 594, in _delete_portchain_path 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager port_chain['flow_classifiers'] 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 577, in _delete_path_node_flowrule 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager context, node, port, pc_corr, fc_ids) 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 568, in _delete_path_node_port_flowrule 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager self._delete_agent_fdb_entries(context, flow_rule) 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 192, in _delete_agent_fdb_entries 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager self._call_on_l2pop_driver(context, "remove_fdb_entries", flow_rule) 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 170, in _call_on_l2pop_driver 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager pop_ports = self._get_remote_pop_ports(context, flow_rule) 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager File "/usr/lib/python2.7/dist-packages/oslo_log/helpers.py", line 67, in wrapper 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager return method(*args, **kwargs) 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/drivers/ovs/driver.py", line 133, in _get_remote_pop_ports 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager next_hop['net_uuid']) 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager File "/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/drivers/l2pop/db.py", line 152, in get_agent_network_active_port_count 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager query = context.session.query(models_v2.Port) 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager AttributeError: 'PortChainContext' object has no attribute 'session' 2019-04-04 12:00:10.186 182062 ERROR networking_sfc.services.sfc.driver_manager 2019-04-04 12:00:10.188 182062 ERROR networking_sfc.services.sfc.driver_manager [req-d03ef918-2314-4728-bb8b-c5670b4b9da1 c8c777caa52b45649a6c312b38e81956 1c915b508cfa4c799389bf354fceb056 - default default] SFC driver 'ovs' failed in delete_port_chain 2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin [req-d03ef918-2314-4728-bb8b-c5670b4b9da1 c8c777caa52b45649a6c312b38e81956 1c915b508cfa4c799389bf354fceb056 - default default] delete_port_chain failed.: SfcDriverError: delete_port_chain failed. 2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin Traceback (most recent call last): 2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/plugin.py", line 99, in delete_port_chain 2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin self.driver_manager.delete_port_chain(pc_context) 2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py", line 130, in delete_port_chain 2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin self._call_drivers("delete_port_chain", context) 2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py", line 113, in _call_drivers 2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin method=method_name 2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin SfcDriverError: delete_port_chain failed. 2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin 2019-04-04 12:00:10.189 182062 ERROR networking_sfc.services.sfc.plugin [req-d03ef918-2314-4728-bb8b-c5670b4b9da1 c8c777caa52b45649a6c312b38e81956 1c915b508cfa4c799389bf354fceb056 - default default] Delete port chain failed, portchain 'b8bba555-e22b-46ee-8267-dc8babe07ef2': SfcDriverError: delete_port_chain failed. 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource [req-d03ef918-2314-4728-bb8b-c5670b4b9da1 c8c777caa52b45649a6c312b38e81956 1c915b508cfa4c799389bf354fceb056 - default default] delete failed: No details.: SfcDriverError: delete_port_chain failed. 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource Traceback (most recent call last): 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource File "/usr/lib/python2.7/dist-packages/neutron/api/v2/resource.py", line 98, in resource 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource result = method(request=request, **args) 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource File "/usr/lib/python2.7/dist-packages/neutron/api/v2/base.py", line 551, in delete 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource return self._delete(request, id, **kwargs) 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource File "/usr/lib/python2.7/dist-packages/neutron/db/api.py", line 91, in wrapped 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource setattr(e, '_RETRY_EXCEEDED', True) 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource self.force_reraise() 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource six.reraise(self.type_, self.value, self.tb) 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource File "/usr/lib/python2.7/dist-packages/neutron/db/api.py", line 87, in wrapped 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource return f(*args, **kwargs) 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource File "/usr/lib/python2.7/dist-packages/oslo_db/api.py", line 147, in wrapper 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource ectxt.value = e.inner_exc 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource self.force_reraise() 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource six.reraise(self.type_, self.value, self.tb) 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource File "/usr/lib/python2.7/dist-packages/oslo_db/api.py", line 135, in wrapper 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource return f(*args, **kwargs) 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource File "/usr/lib/python2.7/dist-packages/neutron/db/api.py", line 126, in wrapped 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource LOG.debug("Retry wrapper got retriable exception: %s", e) 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource self.force_reraise() 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource six.reraise(self.type_, self.value, self.tb) 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource File "/usr/lib/python2.7/dist-packages/neutron/db/api.py", line 122, in wrapped 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource return f(*dup_args, **dup_kwargs) 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource File "/usr/lib/python2.7/dist-packages/neutron/api/v2/base.py", line 579, in _delete 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource obj_deleter(request.context, id, **kwargs) 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource File "/usr/lib/python2.7/dist-packages/oslo_log/helpers.py", line 67, in wrapper 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource return method(*args, **kwargs) 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/plugin.py", line 104, in delete_port_chain 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource portchain_id) 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource self.force_reraise() 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource six.reraise(self.type_, self.value, self.tb) 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/plugin.py", line 99, in delete_port_chain 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource self.driver_manager.delete_port_chain(pc_context) 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py", line 130, in delete_port_chain 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource self._call_drivers("delete_port_chain", context) 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/networking_sfc/services/sfc/driver_manager.py", line 113, in _call_drivers 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource method=method_name 2019-04-04 12:00:10.191 182062 ERROR neutron.api.v2.resource SfcDriverError: delete_port_chain failed. Due to this error, I am unable to delete the existing chain. I am using openstack queens Full installation. Please let me know how to triage this issue. Kind Regards, Navdeep

2 6

Help with kernel panic on cirros image boot process.
by Jorge Luiz Correa 04 Apr '19

04 Apr '19

Hi all! I'm having kernel panic randomically with cirros image. Sometimes the instances boots, sometimes not. I'm using Openstack Queens, Ubuntu Server 18.04 and KVM (following the install guide). The nova/instances directory, where are stored ephemeral disks, is over a GlusterFS system. I've noted that other images, like Ubuntu Cloud Image, do not get this error. It's just with cirros and sometimes. I appreciate any help guiding on where I can look for to identify what is causing these errors. I've analyzed libvirt logs and them show just a launched instance, everything ok. The _base/<ID> file used to launch the instances is the same that is used with cirros instances that worked (it's in a GlusterFS). Something got wrong during the instance boot process. Thank you! [ 1.586076] EDD information not available. [ 1.590261] Freeing unused kernel memory: 1480K (ffffffff81f42000 - ffffffff820b4000) [ 1.594823] Write protecting the kernel read-only data: 14336k [ 1.598951] Freeing unused kernel memory: 1860K (ffff88000182f000 - ffff880001a00000) [ 1.625178] Freeing unused kernel memory: 168K (ffff880001dd6000 - ffff880001e00000) info: initramfs: up at 1.07 modprobe: module virtio_pci not found in modules.dep modprobe: module virtio_blk not found in modules.dep modprobe: module virtio_net not found in modules.dep modprobe: module vfat not found in modules.dep modprobe: module nls_cp437 not found in modules.dep info: copying initramfs to /dev/vda1 [ 2.028648] jbd2_journal_bmap: journal block not found at offset 12 on vda1-8 [ 2.034075] Aborting journal on device vda1-8. mount: mounting /dev on ./dev failed: No such file or directory info: initramfs loading root from /dev/vda1 switch_root: can't execute '/sbin/init': No such file or directory [ 2.692399] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100 [ 2.692399] [ 2.696061] CPU: 0 PID: 1 Comm: switch_root Not tainted 4.4.0-28-generic #47-Ubuntu [ 2.699012] Hardware name: OpenStack Foundation OpenStack Nova, BIOS 1.10.2-1ubuntu1 04/01/2014 [ 2.702373] 0000000000000086 000000004016d54a ffff88003e2fbe10 ffffffff813eb1a3 [ 2.705849] ffffffff81cb10d8 ffff88003e2fbea8 ffff88003e2fbe98 ffffffff8118bf57 [ 2.709353] ffff880000000010 ffff88003e2fbea8 ffff88003e2fbe40 000000004016d54a [ 2.712875] Call Trace: [ 2.714013] [<ffffffff813eb1a3>] dump_stack+0x63/0x90 [ 2.715995] [<ffffffff8118bf57>] panic+0xd3/0x215 [ 2.717840] [<ffffffff81184e1e>] ? perf_event_exit_task+0xbe/0x350 [ 2.720105] [<ffffffff81084541>] do_exit+0xae1/0xaf0 [ 2.722090] [<ffffffff810845d3>] do_group_exit+0x43/0xb0 [ 2.724150] [<ffffffff81084654>] SyS_exit_group+0x14/0x20 [ 2.726207] [<ffffffff818276b2>] entry_SYSCALL_64_fastpath+0x16/0x71 [ 2.729271] Kernel Offset: disabled [ 2.730741] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100 [ 2.730741] - JLC

2 1

[Release-job-failures][freezer] Tag of openstack/freezer-api failed
by Sean McGinnis 04 Apr '19

04 Apr '19

The release of freezer-api failed due to the use of oslosphinx. Sphinx 2.0 was released late last week, and with the major version bump, it has now removed some deprecated things that the oslosphinx theme was using. Projects have been migrating to openstackdocstheme for some time now, with the majority using that instead. Since oslosphinx was going away anyway, it is now being retired and compatibility issues will not be fixed. I have proposed a patch to get freezer-api moved over to openstackdocstheme: https://review.openstack.org/650032 This (or something like it) will need to be merged before we can do a successful release of freezer-api since release notes are generated off of the master branch. Sean ----- Forwarded message from zuul(a)openstack.org ----- Date: Thu, 04 Apr 2019 14:14:59 +0000 From: zuul(a)openstack.org To: release-job-failures(a)lists.openstack.org Subject: [Release-job-failures] Tag of openstack/freezer-api failed Reply-To: openstack-discuss(a)lists.openstack.org Build failed. - publish-openstack-releasenotes-python3 http://logs.openstack.org/59/59a8e662bb73926eb35cd49fbc7371c9dc7170bd/tag/p… : FAILURE in 3m 01s

1 1

tacker 1.0.0.0rc2 (stein)
by no-reply＠openstack.org 04 Apr '19

04 Apr '19

Hello everyone, A new release candidate for tacker for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/tacker/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://git.openstack.org/cgit/openstack/tacker/log/?h=stable/stein Release notes for tacker can be found at: https://docs.openstack.org/releasenotes/tacker/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/tacker/+bugs and tag it *stein-rc-potential* to bring it to the tacker release crew's attention.

1 0

[nova][ops] Help with kernel panic on cirros image boot process.
by Jorge Luiz Correa 04 Apr '19

04 Apr '19

Hi all! I'm having kernel panic randomically with cirros image. Sometimes the instances boots, sometimes not. I'm using Openstack Queens, Ubuntu Server 18.04 and KVM (following the install guide). The nova/instances directory, where are stored ephemeral disks, is over a GlusterFS system. I've noted that other images, like Ubuntu Cloud Image, do not get this error. It's just with cirros and sometimes. I appreciate any help guiding on where I can look for to identify what is causing these errors. I've analyzed libvirt logs and them show just a launched instance, everything ok. The _base/<ID> file used to launch the instances is the same that is used with cirros instances that worked (it's in a GlusterFS). Something got wrong during the instance boot process. Boot log: [ 1.586076] EDD information not available. [ 1.590261] Freeing unused kernel memory: 1480K (ffffffff81f42000 - ffffffff820b4000) [ 1.594823] Write protecting the kernel read-only data: 14336k [ 1.598951] Freeing unused kernel memory: 1860K (ffff88000182f000 - ffff880001a00000) [ 1.625178] Freeing unused kernel memory: 168K (ffff880001dd6000 - ffff880001e00000) info: initramfs: up at 1.07 modprobe: module virtio_pci not found in modules.dep modprobe: module virtio_blk not found in modules.dep modprobe: module virtio_net not found in modules.dep modprobe: module vfat not found in modules.dep modprobe: module nls_cp437 not found in modules.dep info: copying initramfs to /dev/vda1 [ 2.028648] jbd2_journal_bmap: journal block not found at offset 12 on vda1-8 [ 2.034075] Aborting journal on device vda1-8. mount: mounting /dev on ./dev failed: No such file or directory info: initramfs loading root from /dev/vda1 switch_root: can't execute '/sbin/init': No such file or directory [ 2.692399] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100 [ 2.692399] [ 2.696061] CPU: 0 PID: 1 Comm: switch_root Not tainted 4.4.0-28-generic #47-Ubuntu [ 2.699012] Hardware name: OpenStack Foundation OpenStack Nova, BIOS 1.10.2-1ubuntu1 04/01/2014 [ 2.702373] 0000000000000086 000000004016d54a ffff88003e2fbe10 ffffffff813eb1a3 [ 2.705849] ffffffff81cb10d8 ffff88003e2fbea8 ffff88003e2fbe98 ffffffff8118bf57 [ 2.709353] ffff880000000010 ffff88003e2fbea8 ffff88003e2fbe40 000000004016d54a [ 2.712875] Call Trace: [ 2.714013] [<ffffffff813eb1a3>] dump_stack+0x63/0x90 [ 2.715995] [<ffffffff8118bf57>] panic+0xd3/0x215 [ 2.717840] [<ffffffff81184e1e>] ? perf_event_exit_task+0xbe/0x350 [ 2.720105] [<ffffffff81084541>] do_exit+0xae1/0xaf0 [ 2.722090] [<ffffffff810845d3>] do_group_exit+0x43/0xb0 [ 2.724150] [<ffffffff81084654>] SyS_exit_group+0x14/0x20 [ 2.726207] [<ffffffff818276b2>] entry_SYSCALL_64_fastpath+0x16/0x71 [ 2.729271] Kernel Offset: disabled [ 2.730741] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100 Thank you!

1 0

[Zun] Address already belongs to a bound Neutron port Error
by Navdeep Uniyal 04 Apr '19

04 Apr '19

Dear All, I have just installed Zun and tried creating a container following the instructions as per the following webpage: https://docs.openstack.org/zun/rocky/install/index.html I am getting following error while starting my test container using 'openstack appcontainer run --name container2 --net network=$NET_ID cirros ping 8.8.8.8': status_reason | Docker internal error: 500 Server Error: Internal Server Error ("IpamDriver.RequestAddress: Requested ip address {'subnet_id': u'e684a17b-6b17-4ea2-bbc9-752a21304dcc', 'ip_address': u'10.68.48.147'} already belongs to a bound Neutron port: f0d6153a-7408-4cd5-82c3-9abed48ad056"). The network I selected is a flat network on openstack with external flag true. Please advise me how to solve the issue or if there is a specific requirement for this. Thank you, Kind Regards, Navdeep

2 2

cloudkitty 9.0.0.0rc2 (stein)
by no-reply＠openstack.org 04 Apr '19

04 Apr '19

Hello everyone, A new release candidate for cloudkitty for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/cloudkitty/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://git.openstack.org/cgit/openstack/cloudkitty/log/?h=stable/stein Release notes for cloudkitty can be found at: https://docs.openstack.org/releasenotes/cloudkitty/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/cloudkitty/+bugs and tag it *stein-rc-potential* to bring it to the cloudkitty release crew's attention.

1 0

[Magnum] Unable to create Kubernetes cluster
by Anirudh Gupta 04 Apr '19

04 Apr '19

Hi Team, I am trying to create kubernetes cluster using Magnum Openstack. My External Network configuration is as follows: neutron net-create MGMT_NET --shared --router:external --provider:physical_network provider1 --provider:network_type flat neutron subnet-create MGMT_NET 10.0.61.0/24 --name MGMT_SUBNET --allocation-pool start=10.0.61.10,end=10.0.61.250 --disable-dhcp --gateway 10.0.61.1 Then I am creating a template with docker storage driver as "Overlay" openstack coe cluster template create kubernetes-cluster-template --image fedora-atomic-latest --docker-storage-driver overlay --external-network public --dns-nameserver 8.8.8.8 --master-flavor m1.small --flavor m1.small --coe kubernetes Creating a cluster with 1 master node openstack coe cluster create kubernetes-cluster --cluster-template kubernetes-cluster-template --master-count 1 --node-count 1 --keypair key-pair When I look into my stack, it shows the event kube_masters <http://192.168.121.118/horizon/project/stacks/stack/58ddd64a-8779-495d-8d31…> Create in Progress and eventaully after 1 hr, it gets failed. I have checked the Troubleshooting Guide as well, but found nothing that could help me resolving the issue. https://docs.openstack.org/magnum/rocky/admin/troubleshooting-guide.html Can you please suggest some pointers in order to resolve the issue. Regards Anirudh Gupta

1 0

RE: [charms] Enabling Neutron DVR & ovs
by James Page 04 Apr '19

04 Apr '19

Hi Emil On Sat, Mar 30, 2019 at 1:55 PM Emil Larsson <Emil.Larsson(a)zetup.se> wrote: > Hi guys, > > I have been experimenting with the enable-dvr option in neutron-api. I > cannot find a clear guide on how to configure this. > However I have ran into some issues trying to figure out the configuration > to enable dvr. > > This is where juju stops: > unit-neutron-openvswitch-1: 11:45:35 INFO > unit.neutron-openvswitch/1.juju-log Creating bridge br-int > unit-neutron-openvswitch-1: 11:45:35 INFO > unit.neutron-openvswitch/1.juju-log Creating bridge br-ex > unit-neutron-openvswitch-1: 11:45:36 DEBUG > unit.neutron-openvswitch/1.juju-log Replacing iface 'eno1' with bond master > 'os' > unit-neutron-openvswitch-1: 11:45:36 DEBUG > unit.neutron-openvswitch/1.juju-log Replacing iface 'eno2' with bond master > 'os' > unit-neutron-openvswitch-1: 11:45:36 DEBUG > unit.neutron-openvswitch/1.juju-log Replacing iface 'eno3' with bond master > 'stor' > unit-neutron-openvswitch-1: 11:45:36 DEBUG > unit.neutron-openvswitch/1.juju-log Replacing iface 'eno4' with bond master > 'stor' > unit-neutron-openvswitch-1: 11:45:37 INFO > unit.neutron-openvswitch/1.juju-log Creating bridge br-data > unit-neutron-openvswitch-1: 11:45:37 DEBUG > unit.neutron-openvswitch/1.juju-log Interface os.392 is not a Linux bridge > unit-neutron-openvswitch-1: 11:45:37 INFO > unit.neutron-openvswitch/1.juju-log Adding port os.392 to bridge br-data > unit-neutron-openvswitch-1: 11:45:37 DEBUG > unit.neutron-openvswitch/1.config-changed Failed to restart > os-charm-phy-nic-mtu.service: Unit os-charm-phy-nic-mtu.service not found. > That restart failure is a bit of a red-herring (and needs tidying) - it relates to a tactical fix for MTU configuration of interfaces in Trusty (for which we are due to drop support this year). snip [...] > > Any help appreciated :) > The current release of OpenStack Charms still requires use of the neutron-gateway charm for snat traffic routing; that said we have gateway-less features currently in development which allow the agents managed by the neutron-openvswitch charm to be configured for snat routing as well, removing the need for the gateway. Here is a bundle based on the openstack-base bundle which I've been testing with: http://paste.ubuntu.com/p/nsx86snZpb/ Obviously the network space binding, storage configuration and maas tags are all specific to my testing environment - but it demonstrates how to get this working. HTH Regards James

1 0

[dev] [nova] API updates week 19-14
by Ghanshyam Mann 04 Apr '19

04 Apr '19

Hi All, After a long break, I am continuing nova API updates over email. Please find the Nova API highlights of this week. Weekly Office Hour: =============== API office hour is on hold as of now. We can continue it if people are intrested. I am asking the feedback on this ML thread- http://lists.openstack.org/pipermail/openstack-discuss/2019-March/004336.ht… Planned Features : ============== Now we are in Train developement cycle, so I am adding the Train proposed spec first and second part includes all previously approved BP but not completed . Code Ready for Review: ------------------------------ - None Spec Ready for Review: ----------------------------- 1. Support adding description while locking an instance: - Spec: https://review.openstack.org/#/c/638629/ - Weekly Progress: Spec is in review. 2. Nova API policy improvement - Spec: https://review.openstack.org/#/c/547850/ - PoC: https://review.openstack.org/#/q/topic:bp/policy-default-refresh+(status:op… - Weekly Progress: Spec is ready to review, pushed the PoC patches for each proposed changed 3. Support deleting data volume when destroy instance - Spec: https://review.openstack.org/#/c/580336/ - Weekly Progress: Proposed for Train. Ready to review. 4. Nova API cleanup - Spec: https://review.openstack.org/#/c/603969/ - Weekly Progress: Proposed for Train. Ready to review. 5. Add host and hypervisor_hostname flag to create server - Spec: https://review.openstack.org/#/c/645458/ - Weekly Progress: Spec under review 6. Specifying az when restore shelved server - Spec: https://review.openstack.org/#/c/624689/ - Weekly Progress: Spec under review 7. default value of swap in the show flavor details API - Spec: https://review.openstack.org/#/c/648919/ - Weekly Progress: New spec, ready for review. 8. Support for changing deleted_on_termination after boot -Spec: https://review.openstack.org/#/c/580336/ - Weekly Progress: Ready for review. 9. Support delete_on_termination in volume attach api\ -Spec: https://review.openstack.org/#/c/612949/ - Weekly Progress: Ready for review. 10. Add API ref guideline for body text - ~8 api-ref are left to fix. Previously approved Spec needs to be re-proposed for Train: --------------------------------------------------------------------------- 1. 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… 2. Servers Ips non-unique network names : - https://blueprints.launchpad.net/nova/+spec/servers-ips-non-unique-network-… - https://review.openstack.org/#/q/topic:bp/servers-ips-non-unique-network-na… 3. Volume multiattach enhancements: - https://blueprints.launchpad.net/nova/+spec/volume-multiattach-enhancements - https://review.openstack.org/#/q/topic:bp/volume-multiattach-enhancements+(… BP Completed: ------------------- - None Bugs: ==== No progress report in this week. 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

[tc] next meeting
by Mohammed Naser 04 Apr '19

04 Apr '19

Hi everyone: It's quite a busy time but our monthly meeting is due. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting I left the list of past agenda topics in order to leave it for anyone to reference back if they'd like. Please add topics by most Wednesday so we can send out an agenda before the meeting. Thanks, Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

1 1

NVMe PCI-passthrough
by Manuel Sopena Ballesteros 04 Apr '19

04 Apr '19

Dear Openstack community, I am trying to attach NVMe drives to my vms and would like to check the configuration I have because for some reason it is not working. This is my physical host details: [root@zeus-59 ~]# lspci -nn -D | grep -i ssd 0000:03:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01) 0000:04:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01) 0000:06:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01) 0000:07:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01) 0000:08:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01) 0000:09:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01) 0000:84:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01) 0000:85:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01) 0000:86:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01) 0000:87:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01) My idea is to attach either 0000:03:00.0 or 0000:04:00.0 to a vm This is how I identify the block devices for each pci device: [root@zeus-59 ~]# ls -l /sys/bus/pci/devices/0000\:03\:00.0/nvme total 0 drwxr-xr-x. 4 root root 0 Apr 3 14:02 nvme0 [root@zeus-59 ~]# ls -l /sys/bus/pci/devices/0000\:04\:00.0/nvme total 0 drwxr-xr-x. 4 root root 0 Apr 3 14:02 nvme1 I installed the OS on the physical machine leaving those 2 drives intact: [root@zeus-59 ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 59.6G 0 disk ├─sda1 8:1 0 1G 0 part /boot └─sda2 8:2 0 4G 0 part [SWAP] sr0 11:0 1 906M 0 rom nvme0n1 259:15 0 1.8T 0 disk nvme1n1 259:0 0 1.8T 0 disk nvme2n1 259:11 0 1.8T 0 disk └─nvme2n1p1 259:12 0 1.8T 0 part /var/lib/docker/btrfs nvme3n1 259:6 0 1.8T 0 disk └─nvme3n1p1 259:7 0 1.8T 0 part nvme4n1 259:13 0 1.8T 0 disk └─nvme4n1p1 259:14 0 1.8T 0 part nvme5n1 259:5 0 1.8T 0 disk └─nvme5n1p1 259:8 0 1.8T 0 part nvme6n1 259:17 0 1.8T 0 disk └─nvme6n1p1 259:18 0 1.8T 0 part nvme7n1 259:9 0 1.8T 0 disk └─nvme7n1p1 259:10 0 1.8T 0 part nvme8n1 259:3 0 1.8T 0 disk └─nvme8n1p1 259:4 0 1.8T 0 part nvme9n1 259:1 0 1.8T 0 disk └─nvme9n1p1 259:2 0 1.8T 0 part The next thing is to configure Openstack nova api config [pci] alias = { "vendor_id":"8086", "product_id":"0953", "device_type":"type-PCI", "name":"nvme"} nova scheduler config [filter_scheduler] enabled_filters = RetryFilter, AvailabilityZoneFilter, ComputeFilter, ComputeCapabilitiesFilter, ImagePropertiesFilter, ServerGroupAntiAffinityFilter, ServerGroupAffinityFilter, PciPassthroughFilter available_filters = nova.scheduler.filters.all_filters nova compute config [filter_scheduler] enabled_filters = RetryFilter, AvailabilityZoneFilter, ComputeFilter, ComputeCapabilitiesFilter, ImagePropertiesFilter, ServerGroupAntiAffinityFilter, ServerGroupAffinityFilter, PciPassthroughFilter available_filters = nova.scheduler.filters.all_filters [pci] passthrough_whitelist = [ {"address":"0000:03:00.0"}, {"address":"0000:04:00.0"} ] alias = { "vendor_id":"8086", "product_id":"0953", "device_type":"type-PCI", "name":"nvme"} Then I create my flavor openstack flavor create nvme.small --ram 64000 --disk 10 --vcpus 7 --property "pci_passthrough:alias"="nvme:1" I created the vm towards the host with the free nvme drives [root@openstack-deployment ~]# openstack server create --flavor nvme.small --image centos7.5-image --nic net-id=hpc --security-group admin --key-name mykey --availability-zone nova:zeus-59.localdomain test_nvme_small Vm creation fails and I can see this error in the nova compute logs 2019-04-03 16:50:35.512 7 ERROR nova.virt.libvirt.guest [req-8478a99f-bad0-43d5-b405-55c45e8d8cae 91e83343e9834c8ba0172ff369c8acac b91520cff5bd45c59a8de07c38641582 - default default] Error launching a defined domain with XML: <domain type='kvm'> <name>instance-00000090</name> ... <devices> <emulator>/usr/libexec/qemu-kvm</emulator> <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='none'/> <source file='/var/lib/nova/instances/a261fcd4-eca3-4982-8b2a-1df33087ab40/disk'/> <target dev='vda' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </disk> ... 2019-04-03 16:50:35.513 7 ERROR nova.virt.libvirt.driver [req-8478a99f-bad0-43d5-b405-55c45e8d8cae 91e83343e9834c8ba0172ff369c8acac b91520cff5bd45c59a8de07c38641582 - default default] [instance: a261fcd4-eca3-4982-8b2a-1df33087ab40] Failed to start libvirt guest: libvirtError: unsupported configuration: host doesn't support passthrough of host PCI devices Any idea or advice would be very helpful Thank you very much NOTICE Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.

3 3

cinder 14.0.0.0rc2 (stein)
by no-reply＠openstack.org 04 Apr '19

04 Apr '19

Hello everyone, A new release candidate for cinder for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/cinder/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://git.openstack.org/cgit/openstack/cinder/log/?h=stable/stein Release notes for cinder can be found at: https://docs.openstack.org/releasenotes/cinder/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/cinder/+bugs and tag it *stein-rc-potential* to bring it to the cinder release crew's attention.

1 0

[trove] CI job migration to Bionic for stable/stein
by Lingxian Kong 04 Apr '19

04 Apr '19

Hi team, I've fixed the problems that blocked the job migration for the master, now according to the community requirement, we also need to finish the migration for stable/stein. I've already backported the needed patches, please review or reply directly to this email if you have any concerns. https://review.openstack.org/#/c/649744/ https://review.openstack.org/#/c/649745/ --- Cheers, Lingxian Kong Catalyst Cloud

1 0

keystone 15.0.0.0rc2 (stein)
by no-reply＠openstack.org 03 Apr '19

03 Apr '19

Hello everyone, A new release candidate for keystone for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/keystone/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://git.openstack.org/cgit/openstack/keystone/log/?h=stable/stein Release notes for keystone can be found at: https://docs.openstack.org/releasenotes/keystone/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/keystone/+bugs and tag it *stein-rc-potential* to bring it to the keystone release crew's attention.

1 0

networking-powervm 8.0.0.0rc2 (stein)
by no-reply＠openstack.org 03 Apr '19

03 Apr '19

Hello everyone, A new release candidate for networking-powervm for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/networking-powervm/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://git.openstack.org/cgit/openstack/networking-powervm/log/?h=stable/s… Release notes for networking-powervm can be found at: https://docs.openstack.org/releasenotes/networking-powervm/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/networking-powervm/+bugs and tag it *stein-rc-potential* to bring it to the networking-powervm release crew's attention.

1 0

ceilometer-powervm 8.0.0.0rc2 (stein)
by no-reply＠openstack.org 03 Apr '19

03 Apr '19

Hello everyone, A new release candidate for ceilometer-powervm for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/ceilometer-powervm/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://git.openstack.org/cgit/openstack/ceilometer-powervm/log/?h=stable/s… Release notes for ceilometer-powervm can be found at: https://docs.openstack.org/releasenotes/ceilometer-powervm/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/ceilometer-powervm/+bugs and tag it *stein-rc-potential* to bring it to the ceilometer-powervm release crew's attention.

1 0

nova_powervm 8.0.0.0rc2 (stein)
by no-reply＠openstack.org 03 Apr '19

03 Apr '19

Hello everyone, A new release candidate for nova_powervm for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/nova-powervm/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://git.openstack.org/cgit/openstack/nova-powervm/log/?h=stable/stein Release notes for nova_powervm can be found at: https://docs.openstack.org/releasenotes/nova-powervm/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/nova-powervm/+bugs and tag it *stein-rc-potential* to bring it to the nova_powervm release crew's attention.

1 0

openstack-placement 1.0.0.0rc3 (stein)
by no-reply＠openstack.org 03 Apr '19

03 Apr '19

Hello everyone, A new release candidate for openstack-placement for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/placement/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://git.openstack.org/cgit/openstack/placement/log/?h=stable/stein Release notes for openstack-placement can be found at: https://docs.openstack.org/releasenotes/placement/ If you find an issue that could be considered release-critical, please file it at: https://storyboard.openstack.org/#!/project/openstack/placement and tag it *stein-rc-potential* to bring it to the openstack-placement release crew's attention.

1 0

[release][ptl] Delays on releasing RC requests
by Sean McGinnis 03 Apr '19

03 Apr '19

Just a heads up to anyone that is proposing a new RC release by this Thursday's final RC deadline. Sphinx 2.0 was released last Thursday, removing some deprecations that were not noticed in various libs and extensions that end up being used in our docs jobs. Our immediate issue is sphinxcontib.datatemplates that has been updated to handle not using the deprecated calls. But we have been blocked on a requirements update to allow that newer release to be used. We think (fingers crossed) that we have all the stars aligned where that should be merging in about an hour or so. Once it does, we should be able to recheck any existing release requests that have failing doc jobs and get those processed. If you were planning on requesting a new RC today, please go ahead and submit the request. If you have any questions, please stop by the #openstack-release channel. Thanks! Sean

1 1

[nova] super long online_data_migrations
by Mohammed Naser 03 Apr '19

03 Apr '19

Hi there, During upgrades, I've noticed that when running online_data_migrations with "infinite-until-done" mode, it loops over all of the migrations one by one. However, one of the online data migrations (instance_obj.populate_missing_availability_zones) makes a query that takes a really long time as it seems inefficient (which eventually results in 0, cause it already ran), which means as it loops in "blocks" of 50, there's almost a 2-3 to 8 minute wait in really large environments. The question ends up in specific: SELECT count(*) AS count_1 FROM (SELECT instance_extra.created_at AS instance_extra_created_at, instance_extra.updated_at AS instance_extra_updated_at, instance_extra.deleted_at AS instance_extra_deleted_at, instance_extra.deleted AS instance_extra_deleted, instance_extra.id AS instance_extra_id, instance_extra.instance_uuid AS instance_extra_instance_uuid FROM instance_extra WHERE instance_extra.keypairs IS NULL AND instance_extra.deleted = 0) AS anon_1 The explain for the DB query in this example: +------+-------------+----------------+------+---------------+------+---------+------+--------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +------+-------------+----------------+------+---------------+------+---------+------+--------+-------------+ | 1 | SIMPLE | instance_extra | ALL | NULL | NULL | NULL | NULL | 382473 | Using where | +------+-------------+----------------+------+---------------+------+---------+------+--------+-------------+ It's possible that it can be ever worse, as this number is from another very-long running environments. +------+-------------+----------------+------+---------------+------+---------+------+---------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +------+-------------+----------------+------+---------------+------+---------+------+---------+-------------+ | 1 | SIMPLE | instance_extra | ALL | NULL | NULL | NULL | NULL | 3008741 | Using where | +------+-------------+----------------+------+---------------+------+---------+------+---------+-------------+ I'm not the SQL expert, could we not optimize this? Alternatively, could we update the online data migrations code to "pop out" any of the migrations that return 0 for the next iteration, that way it only works on those online_data_migrations that *have* to be done, and ignore those it knows are done? Thanks, Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

5 7

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

03 Apr '19

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

4 4

[trove] Trove for Train
by Lingxian Kong 03 Apr '19

03 Apr '19

Hi, I'm Lingxian Kong, I'm going to serve as Trove PTL for the Train dev cycle. Since the master branch is open for contribution and review, for those who care about Trove, here are several things I'd like to bring to your attention and most importantly, need your feedback. - Deprecate nova-network. As I mentioned in the candidacy, The nova-network related code is spread in the repo, which makes it very difficult for new feature implementation and bugfix. Considering nova-network was deprecated in the OpenStack Newton release, I propose we also deprecate nova-network support in Trove and remove after several cycles according to the deprecation policy of the community. I'm not sure if there is still anyone using nova-network for Trove, especially in production. If yes, please reply to this email. - Create service VM in admin project by default Currently, Trove has configuration support to create the db instance in the admin project, which I think should be the default deployment model to reduce the security risk given all the db instances are communicating with RabbitMQ in the control plane. - Remove SecurityGroup API extension TBH, I don't know when and why that extension was added in Trove but since it's not included in Trove API document( https://developer.openstack.org/api-ref/database/) I assume there is on one relies on that in production, so should be safe to remove. - Remove SecurityGroup related database model I don't have the history development background in my mind, but IMHO, i don't think it's reasonable for Trove to maintain such information in db. - Security group management enhancement Removing the API extension and database model doesn't mean Trove shouldn't support security group for the db instance, on the contrary, security should always be the first thing we consider for new features. The two tasks above are actually prerequisites for this one. In order to make it easy to maintain and as more secure as possible, Trove is not going to allow the end user to manipulate the security group associated with db instance. Trove will try to provide as more information as possible to make the debugging and performance tuning easy. - Monitoring capability Currently, there is no monitoring capability support in Trove, and I think that's the only main part missing for Trove to be running in production. I don't have a full picture in mind now but will try to figure out how to achieve that. - Priorities of the previous dev cycles Of course, I shouldn't put the previous dev cycle priorities away from the track, e.g. the Stein dev cycle priorities are well documented here https://etherpad.openstack.org/p/trove-stein-priorities-and-specs-tracking As Trove project has been experiencing some up and downs in the past, but it's still very useful in some deployment use cases and has some advantages over the container deployment model. As you could guess, the reason I raised my hand to lead Trove is that we(Catalyst Cloud) have been deploying Trove in production, so all those things are aiming at making Trove production ready, not only for private cloud but also for the public. If you have any concerns related to what's mentioned above, please don't hesitate to reply. Alternately, I'm always in the #openstack-trove IRC channel and could answer any questions during the working hours of UTC+12. I really appreciate any feedback from the community. --- Cheers, Lingxian Kong Catalyst Cloud

5 6

[horizon] Unused xstatic-* projects retirement
by Ivan Kolodyazhny 03 Apr '19

03 Apr '19

Hi team, There are some xstatic packages which I didn't start to use in Horizon or plugins. We didn't do any release of them. During the last meeting [1] we agreed to mark them as retired. I'll start retired procedure [2] today. If you're going to use them, please let me know. The list of the projects to be retired: - xstatic-angular-ui-router - xstatic-bootstrap-datepicker - xstatic-hogan - xstatic-jquery-migrate - xstatic-jquery.quicksearch - xstatic-jquery.tablesorter - xstatic-rickshaw - xstatic-spin - xstatic-vis [1] http://eavesdrop.openstack.org/meetings/horizon/2019/horizon.2019-01-09-15.… Regards, Ivan Kolodyazhny, http://blog.e0ne.info/

3 4

[stable][kolla] EOL kolla ocata branch
by Eduardo Gonzalez 03 Apr '19

03 Apr '19

Hi stable team, Kolla project is ready to tag EOL the stable/ocata branch. We would like to tag the following repositories as EOL: - openstack/kolla - openstack/kolla-ansible Let me know if need anything else. Regards

4 5

[taas] tap-as-a-service tempest plugin going to move
by Takashi Yamamoto 03 Apr '19

03 Apr '19

hi, tap-as-a-service tempest plugin is going to be moved into a separate branch-less repository. [1][2] i'm not sure what projects are using the plugin for their jobs. (thus this heads-up) i will update networking-midonet jobs. [3] [1] https://github.com/openstack/tap-as-a-service-tempest-plugin [2] https://review.openstack.org/#/c/649304/ [3] https://review.openstack.org/#/c/649309/

1 0

[release][heat] missing releases on tarballs.openstack.org
by Matthew Thode 03 Apr '19

03 Apr '19

Hi, there are a few tags missing for heat at https://tarballs.openstack.org/heat/ The missing releases are 11.0.1 and 12.0.0rc1 at the least. The cause may be the package name was changed in setup.cfg because it needed to be openstack-heat to be an available name on pypi. (via smcginnis). -- Matthew Thode

3 2

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

03 Apr '19

Hello, Here is the 17th update (Mar 27 to Apr 02, 2019) on collaboration on os_tempest[1] role between TripleO and OpenStack-Ansible projects. Highlights of the week: * os_tempest got support of new source build process using python_venv_build role and it removes tempest_developer_mode from the os_tempest var * keystone_service_internaluri_insecure var got removed from os_tempest playbook and tempest_tempest_conf_overrides is passed to handle tempestconf overrides using zuul jobs. Thanks to odyssey4me, jrosser and mnaser for helping on new source build process patch. Things got merged: os_tempest: * Reuse tempest_tempest_conf_overrides in tempestconf extra args - https://review.openstack.org/648137 * Update role for new source build process - https://review.openstack.org/648026 * Test using integrated build - https://review.openstack.org/648580 tripleo * Update os_tempest playbook var for source install - https://review.openstack.org/648617 * Add tempest_tempest_conf_overrides to fs overrides - https://review.openstack.org/648373 * Remove keystone_service_internaluri_insecure var from os_tempest - https://review.openstack.org/647782 Things in progress: os_tempest: * user guide - https://review.openstack.org/#/c/644570/ tripleo * Introduce tempest_services var for installing tempest_plugins - https://review.openstack.org/#/c/648678/ * Add tempest_test_whitelist to allowed_override - https://review.openstack.org/648110 * Remove the tempest_test_whitelist from playbook - https://review.openstack.org/648111 What is coming for next week? * Arx is working on moving vars from os_tempest tripleo playbook to zuul var overrides so that it will be consumable while porting tripleo standalone scenario jobs to os_tempest. Here is the 16th update [2]. Have queries, Feel free to ping us on #tripleo or #openstack-ansible channel. Links: [1.] http://git.openstack.org/cgit/openstack/openstack-ansible-os_tempest [2.] http://lists.openstack.org/pipermail/openstack-discuss/2019-March/004270.ht… Thanks, Chandan Kumar

1 0

[octavia-api][queens] broken pipe
by Ignazio Cassano 03 Apr '19

03 Apr '19

Hello All, I installed octavia queens with centos and it works but in /var/log/messages I got a lot of errors like the following: Apr 2 09:53:15 tst2-osctrl01 octavia-api: self.RequestHandlerClass(request, client_address, self) Apr 2 09:53:15 tst2-osctrl01 octavia-api: File "/usr/lib64/python2.7/SocketServer.py", line 651, in __init__ Apr 2 09:53:15 tst2-osctrl01 octavia-api: self.finish() Apr 2 09:53:15 tst2-osctrl01 octavia-api: File "/usr/lib64/python2.7/SocketServer.py", line 710, in finish Apr 2 09:53:15 tst2-osctrl01 octavia-api: self.wfile.close() Apr 2 09:53:15 tst2-osctrl01 octavia-api: File "/usr/lib64/python2.7/socket.py", line 279, in close Apr 2 09:53:15 tst2-osctrl01 octavia-api: self.flush() Apr 2 09:53:15 tst2-osctrl01 octavia-api: File "/usr/lib64/python2.7/socket.py", line 303, in flush Apr 2 09:53:15 tst2-osctrl01 octavia-api: self._sock.sendall(view[write_offset:write_offset+buffer_size]) Apr 2 09:53:15 tst2-osctrl01 octavia-api: error: [Errno 32] Broken pipe octavia-api is under haproxy: listen octavia_cluster bind 10.102.184.190:9876 balance source option tcpka option httpchk option tcplog server tst2-osctrl01 10.102.184.191:9876 check fall 5 inter 2000 rise 2 server tst2-osctrl02 10.102.184.192:9876 check fall 5 inter 2000 rise 2 server tst2-osctrl03 10.102.184.193:9876 check fall 5 inter 2000 rise 2 Any help, please ? Another question is related to openstack command: Must I use neutron lbbas command or openstack loadbalancer command for octavia ? Loadbalancers created with neutron command cannot be shown with openstack loadbalancer command . Many thanks Ignazio

3 5

[ops] ops meetups twitter
by Chris Morgan 02 Apr '19

02 Apr '19

Hey all, Those of you who use twitter, please follow https://twitter.com/osopsmeetup to receive low-volume technical-only notifications of news relevant to openstack operators, mainly meetups. The account is run by the OpenStack Ops Meetups team. Chris -- Chris Morgan <mihalis68(a)gmail.com>

1 0

[scientific-sig] IRC Meeting today 2100 UTC
by Stig Telfer 02 Apr '19

02 Apr '19

Hi All - We have a Scientific SIG IRC meeting today at 2100 UTC in channel #openstack-meeting. Everyone is welcome. Today’s agenda is here: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_April_2nd_2019 We have a CFP for high-performance containerised workloads, follow-up on the discussion around help most needed for SIGs, and planning for SIG activities at the Denver summit. Cheers, Stig

1 0

[dev][keystone] Meeting time
by Colleen Murphy 02 Apr '19

02 Apr '19

As discussed in today's meeting, the end of the cycle is a good time to revisit the team meeting time. Please fill out the poll: https://doodle.com/poll/zxv6d2mxngmhb3vc We'll plan on having next week's meeting at the normal time in the normal meeting channel and discuss/announce any changes then. Colleen

1 2

[tripleo] disbanding security squad
by Juan Antonio Osorio Robles 02 Apr '19

02 Apr '19

Hello, So, the security squad hasn't had any activity for some time now. So I'm disbanding it for the time being. Folks can revive it if the need arises. The review to remove it from our docs is the following: https://review.openstack.org/#/c/649346/ Best regards

1 0

[Gerrit][Infra] Marking bot comments in email headers?
by Michael Still 02 Apr '19

02 Apr '19

Hi, wouldn't it be cool if we could somehow mark email from gerrit that came from a bot? Or inversely, call out email sent by a human somehow. That way I could null route all the bot spam and suddenly gerrit email would be useful again. Is this a thing upstream gerrit supports at all? Thanks, Michael

2 1

[sphinx][pecan][wsme][mistral] Sphinx 2.0.0 is not compatible with
by Renat Akhmerov 02 Apr '19

02 Apr '19

Hi, We have a problem with "openstack-tox-docs” CI job, see [1]. It seems like the new version of Sphinx (2.0.0) is not compatible with sphinxcontrib-pecanwsme 0.9.0. Does anyone know how to better address this? I guess there needs to be a new version of sphinxcontrib-pecanwsme that fixes this bug but I’m not even sure that this project is maintained. [1] http://logs.openstack.org/16/648316/6/check/openstack-tox-docs/3a2d588/job-… Thanks Renat Akhmerov @Nokia

3 4

qemu emulation or virtualiztion, which one is it using?
by Manuel Sopena Ballesteros 02 Apr '19

02 Apr '19

Hi, "openstack hypervisor list" command shows qemu as type of hypervisor. How do I know it is using virtualization and not qemu emulation? Thank you NOTICE Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.

4 6

[summit][ptg][mistral] Mistral PTL is at the Summit and the PTG
by Renat Akhmerov 02 Apr '19

02 Apr '19

Hi, Just want to make sure that people interested in any Mistral discussions know that I’m going to Denver and will be there almost till the end of the PTG. So if you’d like to catch me there, just ping me over email or in IRC (rakhmerov). Unfortunately, the approval to go was given quite late and we (again) failed to arrange a full event for Mistral. For that reason I don’t expect many Mistral team members to be in Denver. We’ll fix that in future. But for now we’ll have to be satisfied with informal talks. Some possible reasons why you may want to meet me there: • You already use Mistral but you need additional features in it and you are not sure wether it’s doable or not • You are just looking at Mistral as a technology that might be potentially useful for you and you have questions about architecture, use cases, real experience with it etc. • You’ve already tried Mistral in the past but had issues with it and you’re not sure wether it's worth trying again • You want to help with the development of the project but you don’t know what to begin with and how to better communicate with us Also, if anyone thinks I may be useful at some sessions that are somehow related to Mistral then please let me know and I’ll come. Thanks! Renat Akhmerov @Nokia

1 0

[keystone] how to write a plugin?
by Sergey Vilgelm 02 Apr '19

02 Apr '19

Hello community, Please help me to figure out how to write a plugin for keystone to modify the current functionality. I planned to create a middleware, but found that the paste was removed in Rocky and now Keystone uses the hard-coded list of middleware/apps. I need to call an additional script/api when creating a domain or a project. Is it possible to implement this without patching Keystone? -- Sergey Vilgelm https://www.vilgelm.info

2 3

[searchlight] Searchlight for Train
by Trinh Nguyen 02 Apr '19

02 Apr '19

Hi team, As we are reaching the final weeks of the Stein cycle, I would like to discuss a little bit about what we've done in Stein and planning for the Train cycle. Stein cycle highlights as putting in [1]: - Searchlight now works with Elasticsearch 5.x - We have released a new vision to make Searchlight a multi-cloud application [2]. Moreover, we did a comparison of our vision and the OpenStack clouds vision - Functional test setup has been improved - Searchlight now can work and be tested with Python 3.7 And for the Train cycle, we would like to accomplish these main goals to fulfill the vision: - Make searchlight work with multiple cloud platforms including multiple OpenStack clouds [6], Azure [9], Google Cloud [10], AWS [11]. - Add support for other OpenStack resources: Tacker [7], Octavia [8] - Deprecate support for Elasticsearch 2.x [5] There is a lot of work to be done so I would continue putting effort to encourage new contributors to Searchlight and explore the values it could bring the world. Let's rock it!!! Yours, [1] https://releases.openstack.org/stein/highlights.html#searchlight-search-ser… [2] https://docs.openstack.org/searchlight/latest/contributor/searchlight-visio… [3] https://docs.openstack.org/searchlight/latest/contributor/vision-reflection… [4] https://governance.openstack.org/tc/reference/technical-vision.html [5] https://storyboard.openstack.org/#!/story/2004904 [6] https://storyboard.openstack.org/#!/story/2004840 [7] https://storyboard.openstack.org/#!/story/2004968 [8] https://storyboard.openstack.org/#!/story/2004383 [9] https://storyboard.openstack.org/#!/story/2004718 [10] https://storyboard.openstack.org/#!/story/2004996 [11] https://storyboard.openstack.org/#!/story/2004719 -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

1 0

[placement][nova][infra] best way to add to required-projects on several zuul jobs
by Chris Dent 02 Apr '19

02 Apr '19

The extraction of placement led to the development of os-traits and os-resource-classes [1,2] which are python modules which contain symbols that represent "blessed" strings used as traits and resource classes in at least nova, placement and neutron, but plenty of others soon. These symbols are actively used when developing new features, so being able to access the python modules via tox-siblings [3] in both unit and functional tests, from multiple projects, would be grand: developers could depends-on changes in modules as they are being developed, or rely on symbols in master of the modules before there is a release to pypi. What is the best way to do this? Many projects are using templates like "openstack-python-jobs" but as far as I can tell there's no easy way to override just a part of a template in a local .zuul.yaml and the usual thing is to create another template such as "openstack-python-jobs-neutron" which re-lists all the jobs within, and adds a custom required-projects to each job. Is this (creating another template) the right/best way to add to required-projects for this kind of thing? If not, what's the best way? Presumably it is better to create a centralized job or template when >1 projects will need the additional libraries? Ideas? Thanks. [1] https://docs.openstack.org/os-traits/latest/ [2] https://docs.openstack.org/os-resource-classes/latest/ [3] https://docs.openstack.org/infra/manual/zuulv3.html#installation-of-sibling… -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

2 1

[all] Train goal: removing and simplifying the endpoint tripplets?
by Thomas Goirand 02 Apr '19

02 Apr '19

Hi, During the summit in Tokyo (if I remember well), Sean Dague lead a discussion about removing the need for having 3 endpoints per service. I was very excited about the proposal, and it's IMO a shame it hasn't been implemented. Everyone in the room agreed. Here the content of the discussion as I remember it: <discussion in Tokyo> 1/ The only service that needed the admin endpoint was Keystone. This requirement is now gone. So we could get rid of the admin endpoint all together. 2/ The need for an interal vs public endpoint was only needed for accounting (of for example bandwidth when uploading to Glance), but this could be work-around by operators by using intelligent routing. So we wouldn't need the internal endpoint. This makes us only need the public endpoint, and that's it. Then, there are these %(tenant_id)s bits in the endpoints which are also very much annoying, and could be removed if the clients were smarter. These are still needed, apparently, for: - cinder - swift - heat </discussion in Tokyo> Is anyone planning to implement (at least some parts of) the above? Cheers, Thomas Goirand (zigo)

8 7

[trove] Use storyboard
by Lingxian Kong 01 Apr '19

01 Apr '19

Hi trove team, We are going to use storyboard[1] for task tracking from Train dev cycle, please make sure there is related story/task for every new patch from now on. I didn't migrate things from launchpad so the links in the existing patches are still valid. [1]: https://storyboard.openstack.org/#!/project_group/trove --- Cheers, Lingxian Kong Catalyst Cloud

1 0

[neutron] CI meeting cancel
by Slawomir Kaplonski 01 Apr '19

01 Apr '19

Hi, I can’t chair neutron CI meeting this Tuesday (2.04) so I cancel it. See You on next meeting on 9.04. — Slawek Kaplonski Senior software engineer Red Hat

1 0

[training-labs] DHCP IP conflict with Ubuntu 18.04.2
by Julian Meier 01 Apr '19

01 Apr '19

Hi, we are currently working on a new environment for our school to teach some basic knowledge about OpenStack. Our goal is to run OpenStack training-labs for each student on VMs running on ESXi. Therefor we've enabled nested virtualization (vhv.enable=TRUE) for the VMs in vSphere. Then we basically do following on Ubuntu 18.04.2: ``` echo 1 > /sys/module/kvm/parameters/ignore_msr # to avoid following error while building the base image: "This usually means the libguestfs appliance failed to start or crashed." sudo apt-get install -y qemu-kvm libvirt-bin libguestfs-tools bridge-utils virt-manager virsh pool-create-as --name default --type dir --target /var/lib/libvirt/images wget http://tarballs.openstack.org/training-labs/dist/labs-stable-rocky.tgz tar xzf labs-stable-rocky.tgz cd labs/ ``` We build the base image ubuntu-18.04-server-amd64 with `./st.py --build basedisk --provider kvm` and then the cluster `./st.py --build cluster --provider kvm`. Everything works fine till...: stacktrain.log: ``` 12256 13:08:19.992 stacktrain.core.autostart INFO Start autostart/04_setup_nova_compute.sh 12256 13:08:19.994 stacktrain.core.ssh DEBUG vm_ssh: ssh -q -i /opt/oslab/labs/lib/osbash-ssh-keys/osbash_key -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o ConnectTimeout=20 -o ControlPath=none -p 22 osbash(a)192.168.122.208 bash autostart/04_setup_nova_compute.sh && rm -vf autostart/04_setup_nova_compute.sh 12256 13:08:19.994 stacktrain.core.ssh DEBUG Writing live log for ssh call at /opt/oslab/labs/log/021_04_setup_nova_compute.auto. 12256 13:08:56.551 stacktrain.core.ssh ERROR ssh returned status 255. 12256 13:08:56.552 stacktrain.core.autostart ERROR Script failure: 04_setup_nova_compute 11272 13:08:57.110 stacktrain.core.autostart ERROR Script failed. Exiting. ``` ssh.log: ``` ssh -q -i /opt/oslab/labs/lib/osbash-ssh-keys/osbash_key -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o ConnectTimeout=20 -o ControlPath=none -p 22 osbash(a)192.168.122.208 mkdir -p autostart ssh -q -i /opt/oslab/labs/lib/osbash-ssh-keys/osbash_key -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o ConnectTimeout=20 -o ControlPath=none -p 22 osbash(a)192.168.122.208 bash autostart/04_setup_nova_compute.sh && rm -vf autostart/04_setup_nova_compute.sh ``` For me it looks like both VMs (controller + compute1) get the same IP address (with `./st.py --build nodes_only --provider kvm`): ... Your cluster nodes: INFO VM name: compute1 INFO SSH login: ssh osbash(a)192.168.122.47 INFO (password: osbash) INFO VM name: controller INFO SSH login: ssh osbash(a)192.168.122.47 INFO (password: osbash) INFO Dashboard: Assuming horizon is on controller VM. INFO http://192.168.122.47/horizon/ INFO User : myuser (password: myuser_user_pass) INFO User : admin (password: admin_user_secret) INFO Network: mgmt INFO Network address: 10.0.0.0 INFO Network: provider INFO Network address: 203.0.113.0 ``` >From within the VMs: ``` # controller: osbash@osbash:~$ ifconfig ens3 ens3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.122.47 netmask 255.255.255.0 broadcast 192.168.122.255 inet6 fe80::5054:ff:fed9:b165 prefixlen 64 scopeid 0x20<link> ether 52:54:00:d9:b1:65 txqueuelen 1000 (Ethernet) ... osbash@osbash:~$ netplan ip leases ens3 # This is private data. Do not parse. ADDRESS=192.168.122.47 NETMASK=255.255.255.0 ROUTER=192.168.122.1 SERVER_ADDRESS=192.168.122.1 NEXT_SERVER=192.168.122.1 BROADCAST=192.168.122.255 T1=1800 T2=3150 LIFETIME=3600 DNS=192.168.122.1 HOSTNAME=osbash CLIENTID=ffb55e67ff00020000ab11bba91ddef33599c5 osbash@osbash:~$ cat /etc/machine-id b8c7057a4c084e69aa3743960d41d5ce # compute1: osbash@compute1:~$ ifconfig ens3 ens3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.122.47 netmask 255.255.255.0 broadcast 192.168.122.255 inet6 fe80::5054:ff:fe17:b640 prefixlen 64 scopeid 0x20<link> ether 52:54:00:17:b6:40 txqueuelen 1000 (Ethernet) ... osbash@compute1:~$ netplan ip leases ens3 # This is private data. Do not parse. ADDRESS=192.168.122.47 NETMASK=255.255.255.0 ROUTER=192.168.122.1 SERVER_ADDRESS=192.168.122.1 NEXT_SERVER=192.168.122.1 BROADCAST=192.168.122.255 T1=1800 T2=3150 LIFETIME=3600 DNS=192.168.122.1 HOSTNAME=compute1 CLIENTID=ffb55e67ff00020000ab11bba91ddef33599c5 osbash@compute1:~$ cat /etc/machine-id b8c7057a4c084e69aa3743960d41d5ce ``` I believe the VMs share the same IP address because of the same machine-id (which is used as DUID: http://manpages.ubuntu.com/manpages/bionic/man5/networkd.conf.5.html) Am I wrong? Thanks for your help, Julian

1 0

[placement] update 19-12
by Chris Dent 01 Apr '19

01 Apr '19

HTML: https://anticdent.org/placement-update-19-12.html Placement update 19-12. Nearing 1/4 of the way through the year. I won't be around on Monday, if someone else can chair the [meeting](http://eavesdrop.openstack.org/#Placement_Team_Meeting) that would be great. Or feel free to cancel it. # Most Important An RC2 was cut earlier this week, expecting it to be the last, but there are a [couple of patches](https://review.openstack.org/#/q/project:openstack/placement+branc… which could be put in an RC3 if we were inclined that way. Discuss. We merged a first suite of [contribution guidelines](https://docs.openstack.org/placement/latest/contributor/contrib…. These are worth reading as they explain how to manage bugs, start new features, and be a good reviewer. Because of the introduction of StoryBoard, processes are different from what you may have been used to in Nova. Because of limited time and space and conflicting responsibilities the Placement team will be doing a [Virtual Pre-PTG](http://lists.openstack.org/pipermail/openstack-discuss/2019-March/…. # What's Changed * The contribution guidelines linked above describe how to manage specs, which will now be in-tree. If you have a spec to propose or re-propose (from stein in nova), it now goes in ``doc/source/specs/train/approved/``. * Some [image type traits](https://review.openstack.org/648147) have merged (to be used in a nova-side request pre-filter), but the change has exposed an issue we'll need to resolve: os-traits and os-resource-classes are under the cycle-with-intermediary style release which means that at this time in the cycle it is difficult to make a release which can delay work. We could switch to independent. This would make sense for libraries that are basically lists of strings. It's hard to break that. We could also investigate making os-traits and os-resource-classes required-projects in job templates in zuul. This would allow them to be "tox siblings". Or we could wait. Please express an opinion if you have one. * In discussion in `#openstack-nova` about the patch to [delete placement from nova](https://review.openstack.org/#/c/618215/), it was decided that rather than merge that after the final RC, we would wait until the PTG. There is discussion on the patch which attempts to explain the reasons why. # Specs/Blueprint/Features * The spec for [forbidden aggregate membership](https://docs.openstack.org/placement/latest/specs/train/approve… has merged. * The two traits-related specs from stein will need to be re-proposed to placement for train: * [any traits](http://specs.openstack.org/openstack/nova-specs/specs/stein/approve… * [mixing required traits](http://specs.openstack.org/openstack/nova-specs/specs/stein/approve… * The spec for [request group mapping](https://review.openstack.org/597601) will need to be revisited. # Bugs * StoryBoard stories in [the placement group](https://storyboard.openstack.org/#!/project_group/placement): 4 * Placement related [bugs not yet in progress](https://goo.gl/TgiPXb): 14. * [In progress placement bugs](https://goo.gl/vzGGDQ) 7. +1. We should do a bug squash day at some point. Should we wait until after the PTG or no? Note that the [contribution guidelines](https://docs.openstack.org/placement/latest/contributor/contrib… has some information on how to evaluate new stories and what tags to add. # osc-placement osc-placement is currently behind by 13 microversions. Pending changes: * [support for 1.19](https://review.openstack.org/#/c/641094/) * [support for 1.21](https://review.openstack.org/#/c/641123/) * [aggregate allocation ratio tool](https://review.openstack.org/#/c/640898/) # Main Themes Be thinking about what you'd like the main themes to be. Put them on the [PTG etherpad](https://etherpad.openstack.org/p/placement-ptg-train). # Other Placement * <https://review.openstack.org/#/q/topic:2005297-negative-aggregate-membership> Negative member of aggregate filtering resource providers and allocation candidates. This is nearly ready. * <https://review.openstack.org/#/c/645255/> This is a start at unit tests for the PlacementFixture. It is proving a bit "fun" to get right, as there are many layers involved. Making sure seemingly unrelated changes in placement don't break the nova gate is important. Besides these unit tests, there's discussion on the PTG etherpad of running the nova functional tests, or a subset thereof, in placement's check run. On the one hand this is a pain and messy, but on the other consider what we're enabling: Functional tests that use the real functionality of an external service (real data, real web requests), not stubs or fakes. * <https://review.openstack.org/641404> Use ``code`` role in api-ref titles # Other Service Users There's a lot here, but it is certain this is not all of it. If I missed something you care about, followup mentioning it. * <https://review.openstack.org/552924> Nova: Spec: Proposes NUMA topology with RPs * <https://review.openstack.org/622893> Nova: Spec: Virtual persistent memory libvirt driver implementation * <https://review.openstack.org/641899> Nova: Check compute_node existence in when nova-compute reports info to placement * <https://review.openstack.org/601596> Nova: spec: support virtual persistent memory * <https://review.openstack.org/#/q/topic:bug/1790204> Workaround doubling allocations on resize * <https://review.openstack.org/555081> Nova: Spec: Standardize CPU resource tracking * <https://review.openstack.org/646029> Nova: Spec: Use in_tree getting allocation candidates * <https://review.openstack.org/645316> Nova: Pre-filter hosts based on multiattach volume support * <https://review.openstack.org/606199> Ironic: A fresh way of looking at step retrieval * <https://review.openstack.org/647396> Nova: Add flavor to requested_resources in RequestSpec * <https://review.openstack.org/633204> Blazar: Retry on inventory update conflict * <https://review.openstack.org/640080> Nova: Use aggregate_add_host in nova-manage * <https://review.openstack.org/#/q/topic:bp/count-quota-usage-from-placement> Nova: count quota usage from placement * <https://review.openstack.org/#/q/topic:bug/1819923> Nova: nova-manage: heal port allocations * <https://review.openstack.org/648500> Tempest: Init placement client in tempest Manager object * <https://review.openstack.org/624335> puppet-tripleo: Initial extraction of the Placement service from Nova * <https://review.openstack.org/#/q/topic:bug/1821824> Nova: bug fix prevent forbidden traits from working as expected * <https://review.openstack.org/648665> Nova: Spec for a new nova virt driver to manage an RSD * <https://review.openstack.org/#/q/topic:bug/1819460> Nova: Handle placement error during re-schedule * <https://review.openstack.org/#/c/642067/> Helm: Allow more generic overrides for nova placement-api * <https://review.openstack.org/647578> Nova: add spec for image metadata prefiltering -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

3 3

[Magnum] Cluster Create failure
by Navdeep Uniyal 01 Apr '19

01 Apr '19

Hi All, I am trying to create a cluster using Magnum using : magnum cluster-create kubernetes-cluster --cluster-template kubernetes-cluster-template --master-count 1 --node-count 1 --keypair magnum_key My Template looks like this: +-----------------------+--------------------------------------+ | Property | Value | +-----------------------+--------------------------------------+ | insecure_registry | - | | labels | {} | | updated_at | - | | floating_ip_enabled | True | | fixed_subnet | - | | master_flavor_id | small | | user_id | b4727cb329c14c388d777d0ce38c8a6b | | uuid | 24d01aea-c968-42e3-bcaa-a2e756aac5c7 | | no_proxy | - | | https_proxy | - | | tls_disabled | False | | keypair_id | - | | hidden | False | | project_id | 4c6bc4445c764249921a0a6e40b192dd | | public | False | | http_proxy | - | | docker_volume_size | 4 | | server_type | vm | | external_network_id | 5guknet | | cluster_distro | fedora-atomic | | image_id | fedora-atomic-latest | | volume_driver | - | | registry_enabled | False | | docker_storage_driver | devicemapper | | apiserver_port | - | | name | kubernetes-cluster-template | | created_at | 2019-03-27T12:21:27+00:00 | | network_driver | flannel | | fixed_network | - | | coe | kubernetes | | flavor_id | small | | master_lb_enabled | False | | dns_nameserver | 8.8.8.8 | +-----------------------+--------------------------------------+ I am getting the following error: {"explanation": "The server could not comply with the request since it is either malformed or otherwise incorrect.", "code": 400, "error": {"message": "ResourceTypeUnavailable: : resources.kube_masters<nested_st ack>.resources.0<file:///var/lib/magnum/env/lib/python2.7/site-packages/magnum/drivers/k8s_fedora_atomic_v1/templates/kubemaster.yaml>: : HEAT-E99001 Service cinder is not available for resource type Magnum::Opt ional::Cinder::Volume, reason: cinder volumev3 endpoint is not in service catalog.", "traceback": null, "type": "StackValidationFailed"}, "title": "Bad Request"} log_http_response /var/lib/magnum/env/local/lib/python2.7/site-packages/heatclient/common/http.py:157 2019-03-27 17:28:11.174 145885 ERROR oslo_messaging.rpc.server [req-b4037dc5-2fe1-4533-a6e3-433609c6b22d - - - - -] Exception during message handling: InvalidParameterValue: ERROR: ResourceTypeUnavailable: : res ources.kube_masters<nested_stack>.resources.0<file:///var/lib/magnum/env/lib/python2.7/site-packages/magnum/drivers/k8s_fedora_atomic_v1/templates/kubemaster.yaml>: : HEAT-E99001 Service cinder is not available for resource type Magnum::Optional::Cinder::Volume, reason: cinder volumev3 endpoint is not in service catalog. 2019-03-27 17:28:11.174 145885 ERROR oslo_messaging.rpc.server Traceback (most recent call last): 2019-03-27 17:28:11.174 145885 ERROR oslo_messaging.rpc.server File "/var/lib/magnum/env/local/lib/python2.7/site-packages/oslo_messaging/rpc/server.py", line 166, in _process_incoming 2019-03-27 17:28:11.174 145885 ERROR oslo_messaging.rpc.server res = self.dispatcher.dispatch(message) 2019-03-27 17:28:11.174 145885 ERROR oslo_messaging.rpc.server File "/var/lib/magnum/env/local/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 265, in dispatch 2019-03-27 17:28:11.174 145885 ERROR oslo_messaging.rpc.server return self._do_dispatch(endpoint, method, ctxt, args) 2019-03-27 17:28:11.174 145885 ERROR oslo_messaging.rpc.server File "/var/lib/magnum/env/local/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 194, in _do_dispatch 2019-03-27 17:28:11.174 145885 ERROR oslo_messaging.rpc.server result = func(ctxt, **new_args) 2019-03-27 17:28:11.174 145885 ERROR oslo_messaging.rpc.server File "/var/lib/magnum/env/local/lib/python2.7/site-packages/magnum/conductor/handlers/cluster_conductor.py", line 80, in cluster_create 2019-03-27 17:28:11.174 145885 ERROR oslo_messaging.rpc.server raise e 2019-03-27 17:28:11.174 145885 ERROR oslo_messaging.rpc.server InvalidParameterValue: ERROR: ResourceTypeUnavailable: : resources.kube_masters<nested_stack>.resources.0<file:///var/lib/magnum/env/lib/python2.7/s ite-packages/magnum/drivers/k8s_fedora_atomic_v1/templates/kubemaster.yaml>: : HEAT-E99001 Service cinder is not available for resource type Magnum::Optional::Cinder::Volume, reason: cinder volumev3 endpoint is not in service catalog. 2019-03-27 17:28:11.174 145885 ERROR oslo_messaging.rpc.server The magnum.conf file is as suggested in https://docs.openstack.org/magnum/pike/install/install-guide-from-source.ht… I DO NOT have cinder in my openstack. I believe, it is optional. Please suggest how can I resolve this issue. Kind Regards, Navdeep

4 13

[nova][CI] nova-live-migration failing
by Eric Fried 01 Apr '19

01 Apr '19

I've noticed the nova-live-migration job failing consistently over the weekend on clearly unrelated patches. Haven't had a chance to look into it at all. Please consider holding off blind rechecks for a bit. Thanks, Eric Fried Concept Brazilian Jiu Jitsu http://taylorbjj.com

2 1

[neutron] CI broken
by Slawomir Kaplonski 01 Apr '19

01 Apr '19

Hi, Just FYI, since few days we have broken neutron-tempest-plugin-designate-scenario job and it is failing 100% times. Bug is reported in [1]. If this job failed on Your patch, please don’t recheck as it will not solve the problem. [1] https://bugs.launchpad.net/neutron/+bug/1822453 — Slawek Kaplonski Senior software engineer Red Hat

2 2

Re: [nova][CI] nova-live-migration failing
by Eric Fried 01 Apr '19

01 Apr '19

> I've noticed the nova-live-migration job failing consistently over the > weekend on clearly unrelated patches. Haven't had a chance to look > into it at all. Please consider holding off blind rechecks for a bit. Matt identified bug [1], cause [2], and fix [3]. Please wait until the latter has merged (or rebase on top of it) before rechecking in nova. Thanks, efried [1] https://bugs.launchpad.net/nova/+bug/1822605 [2] https://review.openstack.org/#/c/601433/ [3] https://review.openstack.org/#/c/649036/

1 0

[neutron] bug deputy report for week of 2019-03-25
by Bence Romsics 01 Apr '19

01 Apr '19

Hi Neutrinos, I was the bug deputy this week. I'm going to be on a training on Monday, so I'm sending this report a bit early. If I have the chance on Monday I'll send an updated version still before the team meeting in reply to this. We have no critical bugs and no new RFEs this week. If I may, please let me call your attention to the two High bugs below. High: * https://bugs.launchpad.net/neutron/+bug/1821912 intermittent ssh failures in various scenario tests gate failure, no fix proposed yet * https://bugs.launchpad.net/neutron/+bug/1822256 Ip segments lost when restart ovs-agent with openvswitch firewall packet loss at agent restart, no fix proposed yet Medium: * https://bugs.launchpad.net/neutron/+bug/1822100 Network Update if current provider net attribure key/value pair in request fix proposed: https://review.openstack.org/648522 * https://bugs.launchpad.net/neutron/+bug/1822105 Policy rules related to "sub parameters" doesn't work properly fix proposed: https://review.openstack.org/648532 * https://bugs.launchpad.net/neutron/+bug/1821948 Unstable unit test uses subnet broadcast address low frequency gate failure, fix merged: https://review.openstack.org/648172 Low: * https://bugs.launchpad.net/neutron/+bug/1822155 neutron-keepalived-state-change can not start on some python3 distro problem specific to (unsupported) python3.4, fix proposed: https://review.openstack.org/648459 * https://bugs.launchpad.net/neutron/+bug/1822199 neutron-vpn-netns-wrapper not invoked with --rootwrap_config parameter low hanging fruit, no fix proposed yet Incomplete: * https://bugs.launchpad.net/neutron/+bug/1821567 network_segment_ranges could not load in tricirlce test likely not a neutron bug but a tricircle one * https://bugs.launchpad.net/neutron/+bug/1821925 Limit test coverage for Extended Maintenance stable branches please look at it if you're interested in stable / extended maintenance process * https://bugs.launchpad.net/neutron/+bug/1821963 Rally test delete-subnets fails at higher concurrency could not reproduce yet, waiting to hear back from reporter Duplicate: * https://bugs.launchpad.net/neutron/+bug/1821357 VRRP vip on VM not reachable from other network on DVR setup duplicate of https://bugs.launchpad.net/bugs/1774459 Cheers, Bence irc: rubasov

1 1

[kuryr] Changing upstream meeting time
by Daniel Mellado 01 Apr '19

01 Apr '19

Hi all! Since most of our regular meeting attendees are in CEST time zone, I'm shifting the time slot for our regular meetings to match DST, so the new meeting time would be Mondays at 14:00 UTC. I've already proposed a patch at [1]. Searching at http://eavesdrop.openstack.org/ shows no conflict, so we'll be meeting at that time at #openstack-meeting-4 (falling back to #openstack-kuryr should any issues arise). If you have any doubt or comment, feel free to ping me at the irc. Best! Daniel [1] https://review.openstack.org/#/c/648927/

1 0

[monasca][ptg] PTG Planning
by Witek Bedyk 01 Apr '19

01 Apr '19

Hello everyone, the schedule for the next PTG in Denver has been published [1]. We have a room reserved from Thursday afternoon until Saturday. I have started an etherpad to collect topics for the discussion: https://etherpad.openstack.org/p/monasca-ptg-stein Please add your name and the times when you can attend (both F2F and remotely). Please also put the topics you would like to discuss or features you think we should add in the next release cycle. Thanks for your input and I'm looking forward to see/hear you there. Witek [1] https://www.openstack.org/ptg#tab_schedule

1 1