January 2019 - openstack-discuss - lists.openstack.org

Denver Summit CFP Closing Tomorrow
by Ashlee Ferguson 22 Jan '19

22 Jan '19

Hi everyone, The CFP closes in less than 48 hours, so make sure to submit your presentations, panels, and workshops <https://www.openstack.org/summit/denver-2019/call-for-presentations> for the Denver Open Infrastructure Summit before tomorrow, January 23 at 11:59pm PT (January 24 at 7:59am UTC). SUBMIT YOUR PRESENTATION <https://www.openstack.org/summit/denver-2019/call-for-presentations> Tracks: AI, Machine Learning & HPC CI/CD Container Infrastructure Edge Computing Hands-on Workshops Open Development (formerly Open Source Community) Open Infrastructure Basics Private & Hybrid Cloud Public Cloud Security - NEW! Telecom & NFV Full track descriptions <https://www.openstack.org/summit/denver-2019/summit-categories> For tips on your submissions, check out these articles for some advice from the Summit Programming Committees— http://superuser.openstack.org/articles/tips-for-the-open-infrastructure-su… http://superuser.openstack.org/articles/tips-open-development-track-denver-… http://superuser.openstack.org/articles/tips-for-talks-on-the-public-cloud-… Denver Summit registration <https://openinfrasummitandptgdenver.eventbrite.com/> and sponsor sales are currently open. Learn more <https://www.openstack.org/summit/denver-2019> Please email speakersupport(a)openstack.org <mailto:speakersupport@openstack.org> with any questions or feedback. Cheers, Ashlee Ashlee Ferguson OpenStack Foundation ashlee(a)openstack.org

1 0

[tripleo][openstack-ansible] collaboration on os_tempest role update VII - Jan 22, 2019
by Chandan kumar 22 Jan '19

22 Jan '19

Hello, Here is the seventh update (Jan 15 to Jan 22, 2019) on collaboration on os_tempest[1] role between TripleO and OpenStack-Ansible projects. Things got merged: os_tempest: * Add support for aarch64 images - https://review.openstack.org/#/c/620032/ * Configuration drives don't appear to work on aarch64+kvm - https://review.openstack.org/#/c/626592/ * Fix tempest workspace path - https://review.openstack.org/#/c/628182/ * Add libselinux-python package for Red Hat distro - https://review.openstack.org/#/c/631203/ * Use usr/local/share/ansible/roles for data_files - https://review.openstack.org/#/c/630917/ * Use tempest_domain_name var for setting domain - https://review.openstack.org/#/c/630957/ * Rename tempest_public_net_physical_{type to name} - https://review.openstack.org/#/c/631183/ * Add tempest_interface_name var for setting interface - https://review.openstack.org/#/c/630942/ ansible-config_template * Use usr/share/ansible/plugins for data_files - https://review.openstack.org/631214 ansible-role-python_venv_build * Use usr/local/share/ansible/roles for data_files - https://review.openstack.org/#/c/631777/ openstack-ansible-tests * Setup clouds.yaml on tempest node - https://review.openstack.org/631794 Tripleo-spec * New spec for stein: os_tempest tripleo integration - https://review.openstack.org/630654 Summary: * We have cleaned up os_tempest cloudname and network related vars, fixed tempest workspace upgrade issue and os_tempest got support of aarch64 images and nova Configuration drives. * Tripleo os_tempest spec published: https://specs.openstack.org/openstack/tripleo-specs/specs/stein/ostempest-t… Things in Progress: os_tempest * Always generate stackviz irrespective of tests pass or fail - https://review.openstack.org/631967 * Add telemetry distro plugin install for aodh - https://review.openstack.org/632125 * Added tempest.conf for heat_plugin - https://review.openstack.org/632021 * Use the correct heat tests - https://review.openstack.org/630695 * Use tempest_cloud_name in tempestconf - https://review.openstack.org/631708 * Adds tempest run command with --test-list option - https://review.openstack.org/631351 os_tempest integration with Tripleo * Added requirements for integrating os_tempest role - https://review.openstack.org/628421 * Run tempest using os_tempest role in standalone job - https://review.openstack.org/627500 * Use os_tempest for running tempest on standalone - https://review.openstack.org/628415 Upcoming week: * We are able to run tempest in Triplo CI standalone test results are here: http://logs.openstack.org/00/627500/65/check/tripleo-ci-centos-7-standalone… * We will try to finish os_tempest integration with tripleo and heat support in os_tempest. Thanks to odyssey4me, cloudnull, jrosser (a lot of help on different patches), Panda and Sagi from Tripleo CI team pabelanger and dmsimard on figuring out os_tempest dependencies, action_plugins and nested ansible. Here is the 6th 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-January/001730.… Thanks, Chandan Kumar

2 1

[Trove] State of the Trove service tenant deployment model
by Michael Richardson 22 Jan '19

22 Jan '19

Hi all, Is anyone aware of the current state of the "service tenant" deployment model for Trove, and whether it is a viable option; or whether the historical method of customer tenants/projects are still the recommended approach? Any and all comments/thoughts/gotchas would be most appreciated! Cheers, Michael

3 6

Fwd: [OpenStack Foundation] 2019 Individual Director election and Bylaws amendment results
by Chris Morgan 22 Jan '19

22 Jan '19

Congrats to the new openstack foundation directors! Just FYI the following went to the foundation mailing list. Chris From: Jonathan Bryce <jonathan(a)openstack.org> Date: Fri, Jan 18, 2019, 12:42 Subject: [OpenStack Foundation] 2019 Individual Director election and Bylaws amendment results To: <foundation(a)lists.openstack.org> Hello everyone, The 2019 election of Individual Directors has closed. Results are available at the following link: https://www.bigpulse.com/pollresults?code=1336400LYwRuQQZqR72BJRpKJYV The Bylaws amendments have now been passed by the Individual Member class. The elected and appointed directors will be seated at the Board meeting at the end of January. Congratulations to our new and returning directors. We actually had the highest number of voters for any of our elections participate this year, so thank you to everyone for joining in the process. Jonathan 210-317-2438 Individual Directors ----------------------------------------- Tim Bell ChangBo Guo Sean McGinnis Prakash Ramchandran Allison Randal Egle Sigler Monty Taylor Shane Wang Platinum Directors ----------------------------------------- Alan Clark Ruan He Anni Lai Mark McLoughlin Chris Price Imad Sousou Brian Stein Ryan Van Wyk Gold Directors ----------------------------------------- Mark Baker Johan Christenson Robert Esker Clemens Hardewig Arkady Kanevsky JunWei Liu Vijoy Pandey Joseph Wang _______________________________________________ Foundation mailing list Foundation(a)lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation -- Chris Morgan <mihalis68(a)gmail.com>

2 1

About gitignore policy.
by Natal Ngétal 22 Jan '19

22 Jan '19

Hi everyone, I would to have more information about the .gitignore file policy. First I have made a patch to ignore backup files from vim editor. The patches was refused because that doesn't respect the OpenStack policy: https://review.openstack.org/#/c/631790/ https://review.openstack.org/#/c/631789/ The policy is available in a cookiecutter template repository: https://git.openstack.org/cgit/openstack-dev/cookiecutter/tree/%7b%7bcookie… Then I have started to make patch, to align OpenStack projects with this policy: https://review.openstack.org/#/c/632086/ In nova project the patch was refused, the first reason was we have already talk about this subject. The second reason was this policy is only for the new projects. Oslo is not a new project and is follow this policy. I know is not a priority subject, but I just want understand. For me a policy must be followed by all projects, to harmonize all, but maybe I wrong. For example, in this case, I would to know what is the rules? The new projects must follow the policy but not the old ones? In this case, what the rules for old projects and can we defined also an policy for it? Thanks in advance for your help. My best regards

4 4

[qa] dynamic credentials with the tempest swift client
by Udi Kalifon 22 Jan '19

22 Jan '19

Hello. I am developing GUI tests (Selenium) for the openstack director. I am now trying to make use of tempest Swift client in one of the tests which needs to fetch a file from the tripleo plans. I added this code in our base class to access the client: class GUITestCase(test.BaseTestCase): credentials = ('admin', 'primary') @classmethod def setup_clients(cls): super(GUITestCase, cls).setup_clients() # Clients for Swift cls.account_client = cls.os_admin.account_client cls.container_client = cls.os_admin.container_client cls.object_client = cls.os_admin.object_client I then try to list the objects in the "overcloud" container, which is where the default plans are found: class TestSwift(GUITestCase): def test_swift(self): (resp, body) = self.container_client.list_container_objects( "overcloud") print resp print body It returns a "not found" error. I'm pretty sure that the reason for it not finding the container (which is definitely there) is that it creates a project and a user for itself, and uses those credentials for its interactions with the undercloud. I can see the POST calls in tempest.log that show that it's creating itself the dynamic credentials: INFO tempest.lib.common.rest_client [req-54a... ] Request (TestSwift:setUpClass): 201 POST http://192.168.24.3:35357/v3/projects 0.365s INFO tempest.lib.common.rest_client [req-d3f... ] Request (TestSwift:setUpClass): 201 POST http://192.168.24.3:35357/v3/users 0.493s INFO tempest.lib.common.rest_client [req-480... ] Request (TestSwift:setUpClass): 200 GET http://192.168.24.3:35357/v3/roles 0.297s INFO tempest.lib.common.rest_client [req-e0a... ] Request (TestSwift:setUpClass): 204 PUT http://192.168.24.3:35357/v3/projects/9e1e6b33dcbd4aebb546c56a7258d5e0/user… 0.270s INFO tempest.lib.common.dynamic_creds [-] *Acquired dynamic creds:* credentials: Credentials: {'username': u'tempest-TestSwift-1494291785', 'project_name': u'tempest-TestSwift-1494291785', 'project_domain_id': u'default', 'user_domain_id': u'default', 'tenant_id': u'9e1e6b33dcbd4aebb546c56a7258d5e0', 'user_domain_name': u'Default', 'domain_name': u'Default', 'tenant_name': u'tempest-TestSwift-1494291785', 'user_id': u'cc715537a0c048b7a8692a0c8304b94d', 'project_id': u'9e1e6b33dcbd4aebb546c56a7258d5e0', 'domain_id': u'default', 'project_domain_name': u'Default'}, Network: None, Subnet: None, Router: None So I'm looking for a way to utilize the client without it automatically creating itself dynamic credentials; it has to use the already-existing admin credentials on the admin project in order to see the container with the plans. What's the right way to do that, please? Thanks a lot in advance! Regards, Udi Kalifon; Senior QE; RHOS-UI Automation

3 4

[oslo] Meetings next two weeks
by Ben Nemec 22 Jan '19

22 Jan '19

I had some last-minute travel come up for next week (the 28th-1st) which means I may have spotty availability. I'm not sure if I'll be able to run the meeting on Monday. I guess you can watch for courtesy pings and if they don't happen then chances are I couldn't. :-) The next week (4th-8th) I'm on vacation so I definitely won't be around. Unless someone else wants to run the meeting that one will not happen for sure. -Ben

1 0

UC Election - Looking for Election Officials
by Matt Van Winkle 22 Jan '19

22 Jan '19

Hey Stackers, We are getting ready for the Winter UC election and we need to have at least two Election Officials. I was wondering if you would like to help us on that process. You can find all the details of the election at *https://governance.openstack.org/uc/reference/uc-election-feb2019.html <https://governance.openstack.org/uc/reference/uc-election-feb2019.html>*. I do want to point out to those who are new that Election Officials are unable to run in the election itself but can of course vote. The election dates will be: January 21 - February 03, 05:59 UTC: Open candidacy for UC positions February 04 - February 10, 11:59 UTC: UC elections (voting) Please, reach out to any of the current UC members or simple reply to this email if you can help us in this community process. Thanks, OpenStack User Committee Amy, Leong, Matt, Melvin, and Joseph

4 4

[Release-job-failures][puppet] Release of openstack/puppet-aodh failed
by Jean-Philippe Evrard 22 Jan '19

22 Jan '19

Hello, puppet-aodh failed [3] to release due to an issue in the upload- puppetforge role, for a permission issue [0]. Maybe a privilege escalation is required in [1], or a deeper analysis needs to be done. The role was changed 5 days ago [2], so I am not sure this code had the chance to be tested in post release pipelines. Could someone have a look, please? Thank you in advance. Jean-Philippe Evrard (evrardjp) [0]: http://logs.openstack.org/61/617ffad84b633618490ca1023f8a31d9694b31a9/relea… [1]: http://git.openstack.org/cgit/openstack-infra/zuul-jobs/tree/roles/upload-p… [2]: https://github.com/openstack-infra/zuul-jobs/commit/fd8ffc6711d6481e2fcd40d… [3]: http://lists.openstack.org/pipermail/release-job-failures/2019-January/0010…

2 2

[nova][ops] Problems disabling notifications on state changes
by Massimo Sgaravatto 22 Jan '19

22 Jan '19

I am disabling ceilometer on my OpenStack Ocata cloud. As fas as I understand, besides stopping the ceilometer services, I can also apply the following changes to nova.conf on the compute nodes: instance_usage_audit = True --> false notify_on_state_change = vm_and_task_state --> None I have a problem with the latter change: # grep ^notify_on_state_change /etc/nova/nova.conf notify_on_state_change=None but in the nova log: 2019-01-21 08:31:48.246 6349 ERROR nova ConfigFileValueError: Value for option notify_on_state_change is not valid: Valid values are [None, vm_state, vm_and_task_state], but found 'None' I have also tried setting notify_on_state_change=<None> but it complains that it is not a valid value I can simply comment that line, but I am afraid there is a problem somewhere Thanks, Massimo

2 2

Question about Heat parser
by adjandeye.sylla＠orange.com 22 Jan '19

22 Jan '19

Dear all, In the context of my post-doc research, I'm working with HOT templates and I want to parse them. Instead of developing a new parser, I want to reuse the one that is used by Heat but I don't want to connect to a running OpenStack to do the parsing. Is it possible to use Heat as a standalone parser (i.e. without connecting to a running OpenStack) ? Thank you for your answer. Best regards, Adja SYLLA _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.

2 2

[all] New Automatic SIG (continue discussion)
by Rico Lin 22 Jan '19

22 Jan '19

Dear all To continue the discussion of whether we should have new SIG for autoscaling. I think we already got enough time for this ML [1], and it's time to jump to the next step. As we got a lot of positive feedbacks from ML [1], I think it's definitely considered an action to create a new SIG, do some init works, and finally Here are some things that we can start right now, to come out with the name of SIG, the definition and mission. Here's my draft plan: To create a SIG name `Automatic SIG`, with given initial mission to improve automatic scaling with (but not limited to) OpenStack. As we discussed in forum [2], to have scenario tests and documents will be considered as actions for the initial mission. I gonna assume we will start from scenarios which already provide some basic tests and documents which we can adapt very soon and use them to build a SIG environment. And the long-term mission of this SIG is to make sure we provide good documentation and test coverage for most automatic functionality. I suggest `Automatic SIG` instead of `Autoscaling SIG` to make sure we can provide more value if there are more needs in the future. Just like the example which Adam raised `self-optimizing` from people who are using watcher [3]. Let me know if you got any concerns about this name. And to clarify, there will definitely some cross SIG co-work between this new SIG and Self-Healing SIG (there're some common requirements even across self-healing and autoscaling features.). We also need to make sure we do not provide any duplicated work against self-healing SIG. As a start, let's only focus on autoscaling scenario, and make sure we're doing it right before we move to multiple cases. If no objection, I will create the new SIG before next weekend and plan a short schedule in Denver summit and PTG. [1] http://lists.openstack.org/pipermail/openstack-discuss/2018-November/000284… [2] https://etherpad.openstack.org/p/autoscaling-integration-and-feedback [3] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000813… -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

6 8

[Cyborg][IRC] The Cyborg IRC meeting will be held Wednesday at 0300 UTC
by Li Liu 22 Jan '19

22 Jan '19

The IRC meeting will be held Wednesday at 0300 UTC, which is 10:00 pm est(Tuesday) / 7:00 pm pst(Tuesday) /11 am Beijing time (Wednesday) This Week's Agenda: 1. Track Status on DB work 2. Plans on pushing for the deadline of Stein(1.5 month to go) a. Nova integration. . b. DB change, device drivers and discovery. -- Thank you Regards Li Liu

1 0

[congress] nominating Akhil Jain for core reviewer
by Eric K 22 Jan '19

22 Jan '19

Hi all, I'm writing to nominate Akhil Jain as a Congress core reviewer. He has been an active and consistent contributor in code, reviews, and community interactions for Rocky and Stein cycles. Some of his key contributions include data source drivers, working with other projects to drive key integrations, thorough code reviews, and many important nuts-and-bolts patches. He has been especially valuable to the project and the community through his technical designs informed by his gathering and understanding of operator requirements. Akhil: I look forward to continuing working together! Eric

2 1

Read Only FS after ceph issue
by Grant Morley 22 Jan '19

22 Jan '19

Hi all, We are in the process of retiring one of our old platforms and last night our ceph cluster went into an "Error" state briefly because 1 of the OSDs went close to full. The data got re-balanced fine and the health of ceph is now "OK" - however we have about 40% of our instances that now have corrupt disks which is a bit odd. Even more strange is that we cannot get them into rescue mode. As soon as we try we the instances seem to hang during the bootup process when they are trying to mount "/dev/vdb1" and we eventually get a kernel timeout error as below: Warning: fsck not present, so skipping root file system [ 5.644526] EXT4-fs (vdb1): INFO: recovery required on readonly filesystem [ 5.645583] EXT4-fs (vdb1): write access will be enabled during recovery [ 240.504873] INFO: task exe:332 blocked for more than 120 seconds. [ 240.506986] Not tainted 4.4.0-66-generic #87-Ubuntu [ 240.508782] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 240.511438] exe D ffff88003714b878 0 332 1 0x00000000 [ 240.513809] ffff88003714b878 ffff88007c18e358 ffffffff81e11500 ffff88007be81c00 [ 240.516665] ffff88003714c000 ffff88007fc16dc0 7fffffffffffffff ffffffff81838cd0 [ 240.519546] ffff88003714b9d0 ffff88003714b890 ffffffff818384d5 0000000000000000 [ 240.522399] Call Trace: I have even tried using a different image for nova rescue and we are getting the same results. Has anyone come across this before? This system is running OpenStack Mitaka with Ceph Jewel. Any help or suggestions will be much appreciated. Regards, -- Grant Morley Cloud Lead Absolute DevOps Ltd Units H, J & K, Gateway 1000, Whittle Way, Stevenage, Herts, SG1 2FP www.absolutedevops.io <http://www.absolutedevops.io/> grant(a)absolutedevops.io <mailto:grant@absolutedevops.io> 0845 874 0580

2 2

[manila-ui][queens] cannot create share snapshot
by Ignazio Cassano 21 Jan '19

21 Jan '19

Hello, I installed manila on centos queens but it is not possible creating share snapshot from ui: Danger: An error occurred. Please try again later. It works from command line . Regards Ignazio

2 2

[Diversity] [OffTOPIC] OpenStack Diversity Survey - ends Feb 28
by Amy Marrich 21 Jan '19

21 Jan '19

This is the last time the Diversity and Inclusion WG is asking for your assistance for our current survey in collecting data in regards to diversity. We will be closing the survey on February 28th, 2019 in order to start compiling the data. We revised the Diversity Survey that was originally distributed to the Community in the Fall of 2015 and reached out in August with our new survey. We are looking to update our view of the OpenStack community and it's diversity. We are pleased to be working with members of the CHAOSS project who have signed confidentiality agreements in order to assist us in the following ways: 1) Assistance in analyzing the results 2) And feeding the results into the CHAOSS software and metrics development work so that we can help other Open Source projects Please take the time to fill out the survey and share it with others in the community. The survey can be found at: https://www.surveymonkey.com/r/OpenStackDiversity Thank you for assisting us in this important task! Please feel free to reach out to me via email, in Berlin, or to myself or any WG member in #openstack-diversity! Amy Marrich (spotz) Diversity and Inclusion Working Group Chair

1 0

[tc] [all] Please help verify the role of the TC
by Chris Dent 21 Jan '19

21 Jan '19

Recently Thierry, with the help of other TC members, wrote down the perceived role of the TC [1]. This was inspired by the work on the "Vision for OpenStack Clouds" [2]. If we think we should have that document to help validate and direct our software development, we should have something similar to validate governance. Now we need to make sure the document reflects not just how things are but also how they should be. We (the TC) would like feedback from the community on the following general questions (upon which you should feel free to expand as necessary). * Does the document accurately reflect what you see the TC doing? * What's in the list that shouldn't be? * What's not in the list that should be? * Should something that is listed be done more or less? Discussions like these are sometimes perceived as pointless navel gazing. That's a fair complaint when they result in nothing changing (if it should). In this case however, it is fair to say that the composition of the OpenStack community is changing and we _may_ need some adjustments in governance to effectively adapt. We can't know if any changes should be big or little until we talk about them. We have several weeks before the next TC election, so now seems an appropriate time. Note that the TC was chartered with a mission [3]: The Technical Committee (“TC”) is tasked with providing the technical leadership for OpenStack as a whole (all official projects, as defined below). It enforces OpenStack ideals (Openness, Transparency, Commonality, Integration, Quality…), decides on issues affecting multiple projects, forms an ultimate appeals board for technical decisions, and generally has technical oversight over all of OpenStack. Thanks for your participation and help. [1] https://governance.openstack.org/tc/reference/role-of-the-tc.html [2] https://governance.openstack.org/tc/reference/technical-vision.html [3] https://governance.openstack.org/tc/reference/charter.html#mission -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

15 52

[dev][tc][ptl] Evaluating projects in relation to OpenStack cloud vision
by Julia Kreger 21 Jan '19

21 Jan '19

As some of you may or may not have heard, recently the Technical Committee approved a technical vision document [1]. The goal of the technical vision document is to try to provide a reference point for cloud infrastructure software in an ideal universe. It is naturally recognized that not all items will apply to all projects. With that in mind, we want to encourage projects to leverage the vision by performing a realistic self-evaluation to determine how their individual project compares to the technical vision: What gaps exist in the project that could be closed to be more in alignment with the vision? Are there aspects of the vision which are inappropriate for the project to such a degree that the vision itself should change, not the project? We envision the results of the evaluation to be added to each project's primary contributor documentation tree (/doc/source/contributor/vision-reflection.rst) as a list of bullet points detailing areas where a project feels they need adjustment to better align with the technical vision, and if the project already has visibility into a path forward, that as well. As with all things of this nature, we anticipate projects to treat the document as a living document and update it as each project's contributors feel necessary. If an individual project community feels something in the overall OpenStack community technical vision does not apply, that is okay. If the project community feels that something in the vision is wrong for the whole of OpenStack, please feel free to submit a revision to gerrit in order to start that discussion. Once projects have performed a realistic self-evaluation, we ask each project to then consider those items they identified in their future planning as areas that could use the attention of contributors. To be very explicit about this, the intent is to help enable projects to identify areas for improved alignment with the rest of OpenStack using a short, concise, easily consumable list that can be referenced in planning, or even by drive-by contributors if they are intrigued by a specific problem. Thanks, Julia Kreger & Chris Dent [1] https://governance.openstack.org/tc/reference/technical-vision.html

3 4

[heystone][nova][cinder] netapp queens trust scoped token
by Ignazio Cassano 21 Jan '19

21 Jan '19

Hello Everyone, I am using a client for backupping openstack virtual machine. The crux of the problem is the client uses trust based authentication for scheduling backup jobs on behalf of user. When a trust scoped token is passed to cinder client to take a snapshot, I expect the client use the token to authenticate and perform the operation which cinder client does. However cinder volume service invokes novaclient as part of cinder nfs backend snapshot operation and novaclient tries to re-authenticate. Since keystone does not allow re-authentication using trust based tokens, cinder snapshot operation fails. So I get the following error: 2018-12-12 04:07:14.759 2859 ERROR cinder.volume.drivers. remotefs [req-61d977c1-eef3-4309-ac02-aaa0eb880925 ab1bdb5dadc54312891f3a6410fef04d 6d1bffb04e3b4cdda30dc17aa96bfffc - default default] Call to Nova to create snapshot failed: Forbidden: You are not authorized to perform the requested action: Using trust-scoped token to create another token. Create a new trust-scoped token instead. (HTTP 403) (Request-ID: req-f55b682a-001b-4952-bfb1-abf4dd6bf459) > 2018-12-12 04:07:14.759 2859 ERROR cinder.volume.drivers. remotefs Traceback (most recent call last): > 2018-12-12 04:07:14.759 2859 ERROR cinder.volume.drivers. remotefs File "/usr/lib/python2.7/site-packages/cinder/volume/drivers/ remotefs.py", line 1452, in _create_snapshot_online > 2018-12-12 04:07:14.759 2859 ERROR cinder.volume.drivers. remotefs connection_info) > 2018-12-12 04:07:14.759 2859 ERROR cinder.volume.drivers. remotefs File "/usr/lib/python2.7/site-packages/cinder/compute/nova.py", line 188, in create_volume_snapshot > 2018-12-12 04:07:14.759 2859 ERROR cinder.volume.drivers. remotefs create_info=create_info) > 2018-12-12 04:07:14.759 2859 ERROR cinder.volume.drivers. remotefs File "/usr/lib/python2.7/site-packages/novaclient/v2/assisted_volume_snapshots.py", line 43, in create > 2018-12-12 04:07:14.759 2859 ERROR cinder.volume.drivers. remotefs return self._create('/os-assisted-volume-snapshots', body, 'snapshot') > 2018-12-12 04:07:14.759 2859 ERROR cinder.volume.drivers. remotefs File "/usr/lib/python2.7/site-packages/novaclient/base.py", line 361, in _create > 2018-12-12 04:07:14.759 2859 ERROR cinder.volume.drivers. remotefs resp, body = self.api.client.post(url, body=body) > 2018-12-12 04:07:14.759 2859 ERROR cinder.volume.drivers. remotefs File "/usr/lib/python2.7/site-packages/keystoneauth1/adapter.py", line 310, in post > 2018-12-12 04:07:14.759 2859 ERROR cinder.volume.drivers. remotefs return self.request(url, 'POST', **kwargs) My cinder volume are non netapp fas8040 via nfs. Anyone can help me ? Regards Ignazio

2 4

Patch needs to be re-approved.
by Ni, Qi 21 Jan '19

21 Jan '19

Hi, my patch https://review.openstack.org/#/c/623401/13 has passed the code review but according to Developer's Guide, it will not automatically merged when the dependent change has merged. It now needs another approval or a toggle of the approval. Please take a look at it. Thank you. Best Regards, Nicky.

2 1

[ironic] alidation of image href secreturl failed, reason: Got HTTP code 404 instead of 200 in response to HEAD request
by Zufar Dhiyaulhaq 21 Jan '19

21 Jan '19

Hi, I get some error when trying to create an instance for bare-metal node. Bellow is my troubleshooting. I don't know what is happening. Any suggestions? *Ironic Error Log*: 2019-01-19 15:36:41.232 15780 ERROR ironic.drivers.modules.deploy_utils [req-200dac66-0995-41c4-8c8c-dff053d27e36 499299da0c284a4ba9214ea0d83867cc 62088a869020430392a4fb1a0c5d2863 - default default] Agent deploy supports only HTTP(S) URLs as instance_info['image_source'] or swift temporary URL. Either the specified URL is not a valid HTTP(S) URL or is not reachable for node 6c20755a-e36b-495a-98e1-a40f58e5ac3c. Error: Validation of image href secreturl failed, reason: Got HTTP code 404 instead of 200 in response to HEAD request.: ImageRefValidationFailed: Validation of image href secreturl failed, reason: Got HTTP code 404 instead of 200 in response to HEAD request. 2019-01-19 15:36:41.233 15780 ERROR ironic.conductor.manager [req-200dac66-0995-41c4-8c8c-dff053d27e36 499299da0c284a4ba9214ea0d83867cc 62088a869020430392a4fb1a0c5d2863 - default default] Error while preparing to deploy to node 6c20755a-e36b-495a-98e1-a40f58e5ac3c: Validation of image href secreturl failed, reason: Got HTTP code 404 instead of 200 in response to HEAD request.: ImageRefValidationFailed: Validation of image href secreturl failed, reason: Got HTTP code 404 instead of 200 in response to HEAD request. *Nova Error Log:* 2019-01-19 16:35:52.639 13355 ERROR oslo.service.loopingcall [-] Fixed interval looping call 'nova.virt.ironic.driver.IronicDriver._wait_for_active' failed: InstanceDeployFailure: Failed to provision instance 3$ 2019-01-19 16:35:52.639 13355 ERROR oslo.service.loopingcall Traceback (most recent call last): 2019-01-19 16:35:52.639 13355 ERROR oslo.service.loopingcall File "/usr/lib/python2.7/site-packages/oslo_service/loopingcall.py", line 137, in _run_loop 2019-01-19 16:35:52.639 13355 ERROR oslo.service.loopingcall result = func(*self.args, **self.kw) 2019-01-19 16:35:52.639 13355 ERROR oslo.service.loopingcall File "/usr/lib/python2.7/site-packages/nova/virt/ironic/driver.py", line 505, in _wait_for_active 2019-01-19 16:35:52.639 13355 ERROR oslo.service.loopingcall raise exception.InstanceDeployFailure(msg) 2019-01-19 16:35:52.639 13355 ERROR oslo.service.loopingcall InstanceDeployFailure: Failed to provision instance 38c276b1-b88a-4f4b-924b-8b52377f3145: Failed to prepare to deploy: Validation of image href secre$ 2019-01-19 16:35:52.639 13355 ERROR oslo.service.loopingcall 2019-01-19 16:35:52.640 13355 ERROR nova.virt.ironic.driver [req-e11c3fcc-2066-49c6-b47b-0e3879840ad0 7ad46602ac42417a8c798c69cb3105e5 f3bb39ae2e0946e1bbf812bcde6e08a7 - default default] Error deploying instanc$ 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [req-e11c3fcc-2066-49c6-b47b-0e3879840ad0 7ad46602ac42417a8c798c69cb3105e5 f3bb39ae2e0946e1bbf812bcde6e08a7 - default default] [instance: 38c276b1-b88a-4$ 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] Traceback (most recent call last): 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 2252, in _build_resources 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] yield resources 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 2032, in _build_and_run_instance 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] block_device_info=block_device_info) 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] File "/usr/lib/python2.7/site-packages/nova/virt/ironic/driver.py", line 1136, in spawn 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] 'node': node_uuid}) 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__ 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] self.force_reraise() 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in force_reraise 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] six.reraise(self.type_, self.value, self.tb) 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] File "/usr/lib/python2.7/site-packages/nova/virt/ironic/driver.py", line 1128, in spawn 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] timer.start(interval=CONF.ironic.api_retry_interval).wait() 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] File "/usr/lib/python2.7/site-packages/eventlet/event.py", line 121, in wait 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] return hubs.get_hub().switch() 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] File "/usr/lib/python2.7/site-packages/eventlet/hubs/hub.py", line 294, in switch 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] return self.greenlet.switch() 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] File "/usr/lib/python2.7/site-packages/oslo_service/loopingcall.py", line 137, in _run_loop 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] result = func(*self.args, ** self.kw) 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] File "/usr/lib/python2.7/site-packages/nova/virt/ironic/driver.py", line 505, in _wait_for_active 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] raise exception.InstanceDeployFailure(msg) 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] InstanceDeployFailure: Failed to provision instance 38c276b1-b88a-4f4b-924b-8b52377f3145: Failed to prep$ 2019-01-19 16:35:52.641 13355 ERROR nova.compute.manager [instance: 38c276b1-b88a-4f4b-924b-8b52377f3145] *Ironic Configuration:* [DEFAULT] enabled_drivers=pxe_ipmitool enabled_hardware_types = ipmi log_dir=/var/log/ironic transport_url=rabbit://guest:guest@10.60.60.10:5672/ auth_strategy=keystone notification_driver = messaging [conductor] send_sensor_data = true automated_clean=true [swift] region_name = RegionOne project_domain_id = default user_domain_id = default project_name = services password = IRONIC_PASSWORD username = ironic auth_url = http://10.60.60.10:5000/v3 auth_type = password [pxe] tftp_root=/tftpboot tftp_server=10.60.60.10 ipxe_enabled=True pxe_bootfile_name=undionly.kpxe uefi_pxe_bootfile_name=ipxe.efi pxe_config_template=$pybasedir/drivers/modules/ipxe_config.template uefi_pxe_config_template=$pybasedir/drivers/modules/ipxe_config.template pxe_append_params=coreos.autologin #ipxe_use_swift=True [agent] image_download_source = http [deploy] http_root=/httpboot http_url=http://10.60.60.10:8088 [service_catalog] insecure = True auth_uri=http://10.60.60.10:5000/v3 auth_type=password auth_url=http://10.60.60.10:35357 project_domain_id = default user_domain_id = default project_name = services username = ironic password = IRONIC_PASSWORD region_name = RegionOne [database] connection=mysql+pymysql:// ironic:IRONIC_DBPASSWORD@10.60.60.10/ironic?charset=utf8 [keystone_authtoken] auth_url=http://10.60.60.10:35357 www_authenticate_uri=http://10.60.60.10:5000 auth_type=password username=ironic password=IRONIC_PASSWORD user_domain_name=Default project_name=services project_domain_name=Default [neutron] www_authenticate_uri=http://10.60.60.10:5000 auth_type=password auth_url=http://10.60.60.10:35357 project_domain_name=Default project_name=services user_domain_name=Default username=ironic password=IRONIC_PASSWORD cleaning_network = 461a6663-e015-4ecf-9076-d1b502c3db25 provisioning_network = 461a6663-e015-4ecf-9076-d1b502c3db25 [glance] region_name = RegionOne project_domain_id = default user_domain_id = default project_name = services password = IRONIC_PASSWORD username = ironic auth_url = http://10.60.60.10:5000/v3 auth_type = password temp_url_endpoint_type = swift swift_endpoint_url = http://10.60.60.10:8080/v1/AUTH_%(tenant_id)s swift_account = AUTH_f3bb39ae2e0946e1bbf812bcde6e08a7 swift_container = glance swift_temp_url_key = secret *Temp-URL enable:* [root@zu-controller0 ~(keystone_admin)]# openstack object store account show +------------+---------------------------------------+ | Field | Value | +------------+---------------------------------------+ | Account | AUTH_f3bb39ae2e0946e1bbf812bcde6e08a7 | | Bytes | 996 | | Containers | 1 | | Objects | 1 | | properties | Temp-Url-Key='secret' | +------------+---------------------------------------+ *Swift Endpoint:* [root@zu-controller0 ~(keystone_admin)]# openstack endpoint list | grep swift | 07e9d544a44241f5b317f651dce5f0a4 | RegionOne | swift | object-store | True | public | http://10.60.60.10:8080/v1/AUTH_%(tenant_id)s | | dadfd168384542b0933fe41df87d9dc8 | RegionOne | swift | object-store | True | internal | http://10.60.60.10:8080/v1/AUTH_%(tenant_id)s | | e53aca9d357542868516d367a0bf13a6 | RegionOne | swift | object-store | True | admin | http://10.60.60.10:8080/v1/AUTH_%(tenant_id)s | Best Regards, Zufar Dhiyaulhaq

2 1

[Nova] [Scheduler] Change Nova weight_multiplier method to accept host_state
by Yikun Jiang 21 Jan '19

21 Jan '19

In blueprint [1], we approved to allow set weights multiplier on host aggregates to have more flexibility when scheduling. In order to make weigher can get the metadata info, we propose to add a new parameter "host_state" in weight_multiplier method [2], just like what we current do in filter host_passes [3]. That means if you implements the custom weigher, you should change your weigher to accept a host_state. Any thoughts or feedback are welcome, thanks! : ) [1] https://blueprints.launchpad.net/nova/+spec/per-aggregate-scheduling-weight [2] https://review.openstack.org/#/c/628163/12/nova/weights.py@79 [3] https://github.com/openstack/nova/blob/master/nova/scheduler/filters/__init… Regards, Yikun ---------------------------------------- Jiang Yikun（Kero） Mail: yikunkero(a)gmail.com

1 0

[releases] Additions to releases-core
by Sean McGinnis 21 Jan '19

21 Jan '19

I'm very happy to announce I have added Kendall Nelson and Jean-Philippe Evrard to the releases-core group. These two have been doing release request reviews and asking questions to learn about the release process, and we feel they are ready for more. Initially we will just be looking at +2's and saving approvals for one of the existing core members until everyone has more confidence. I wouldn't expect this +2-only period to last long though. We will also need to work out reallocation of review days. Right now, the current cores have taken different days for them to be the point person for processing reviews. With the expanded team, I think we should take a look at those days again and get the work divided up amongst us. Thanks Kendall and JP for getting involved and helping with this important piece of the process, and welcome to the releases-core team! Sean

3 2

[nova] review guide for the bandwidth patches
by Balázs Gibizer 21 Jan '19

21 Jan '19

Hi, After discussing generic concerns about the current proposed patch series[1] for the bandwidth-resource-provider bp [2] with Matt, I decided to write a summary that might help other reviewers. Grouping of the pathes ---------------------- The whole nova implementation is one long patch series that can be splitted into smaller logical steps * Already merged patches added the two new standard resource classes and added a field to RequestSpec to store the resource request of each neutron port. * The open patch series start at [3] now and the patches between [3] [4] introduce the ability to boot a server with neutron ports that has resource request. These patches implement handling the extra resources during boot, re-schedule and delete. These patches only work if a server has maximum one neutron port that has resource request. * The patches after [4] until [5] implement the calculation and communiction of the mapping between ports and resource providers that are fulfilling the given port resource request. (The reason why this is done in nova described below.) So these patches allow having more than one neutron port per server having resource request. * the next two patches [6][7] implement rejecting use cases that was decided to out of scope for the feature (interface attach with resource requst, booting with network having resource request) * The next patch [8] add support for removing resource allocation during interface detach if the detached port has resource request * The rest of the series up until [9] implement support for selecting VFs form the same PF that the bandwidth was allocated from. This allows handling bandwidth and VF resources properly even if there are more than one PFs on the same compute connected to the same physnet. What is still missing from the patch series: * Support for any kind of server move operations (resize, migrate, evacuate, live-migrate, unshelve) * Upgrade support: Bound SRIOV ports might already have QoS policy that would need healing resource allocation in placement. * Supporting separation of QoS aware and non aware ports on the same host. This can be done with host aggregates today, but the bp described possible ways to support a better separation. * Supporting multisegment network that has more than one segment having physnet name. For this we would need any-trait support from placement. The spec for it is approved but the implementation is on hold due to placement extraction. Order of the patches -------------------- One comment I got from Matt is that the patches are in wrong order. The current order allows booting server with bandwidth request _before_ every other server operation is supported (or rejected). This could lead to the violation of the resource view of the system. For example booting a server with a QoS aware port will result in bandwidth allocation on the compute host. But then later on migrating that server to another host does not properly handle moving the allocation to the target host. In my view reordering the patches to only allow booting the first server with bandwdith after every other operation is supported is not feasible. The current chain is already 17 patches long and it does not touch server moving operations at all. Also if I cannot boot a server with bandwidth then I cannot test that such server can be moved properly. So all the functional test would end up in the last patch of the series. However I think we can use the feature flag approach. We can implement and verify everything in the current order without the end user seeing or causing any kind of inconsistencies. The nova implementation is only activated if a neutron port has a resource_request field. This field is added to the neutron API as an API extension. We can mark this extension experimental while we are working through the missing pieces of the feature. But we can also turn on that extension in our test envirnoment to verify each and every step during the implementation process. Which RP fulfills the request of a neutron port ----------------------------------------------- Neutron expects a single RP uuid sent by nova in the port binding that tells neutron about which RP providers the resources for that port. This is the famous problem to find which request group is fulfilled by which resource provider in an allocation candidate. There are 3 possible solutions: * Neutron does the mapping. This would require Neutron to see each port binding for a given server as a single request. This is not the case today and not feasible to hack around in neutron. * Placement does the mapping. This is technically feasible and in my oppinion this is the good solution. But placement is in feature freeze so the spec [10] describing this change is put on hold. * Nova does the mapping. This is what pathes after [4] until [5] implement. It is a temporary solution until the placement based solution can be provided. The current patches are structured in a way that all ovo and neutronv2/api impacts in nova are reusable for the placement based solution later without change. There is only one patch [11] that will be thrown away when the placement based solution is available. I hope this mail helps reviewing the series. Cheers, gibi [1] https://review.openstack.org/#/q/topic:bp/bandwidth-resource-provider+(stat… [2] https://blueprints.launchpad.net/nova/+spec/bandwidth-resource-provider [3] https://review.openstack.org/#/c/625941/ [4] https://review.openstack.org/#/c/567268/ [5] https://review.openstack.org/#/c/573317/ [6] https://review.openstack.org/#/c/570078 [7] https://review.openstack.org/#/c/570079 [8] https://review.openstack.org/#/c/622421 [9] https://review.openstack.org/#/c/623543 [10] https://review.openstack.org/#/c/597601 [11] https://review.openstack.org/#/c/616239

7 25