May 2019 - openstack-discuss - lists.openstack.org

[vitrage][ptl][tc] stepping down as Vitrage PTL
by Ifat Afek 23 May '19

23 May '19

Hi, As I have taken on a new role in my company, I will not be able to continue serving as the Vitrage PTL. I’ve been the PTL of Vitrage from the day it started (back then in Mitaka), and it has been a real pleasure for me. Helping a project grow from an idea and a set of diagrams to a production-grade service was an amazing experience. I am honored to have worked with excellent developers, both Vitrage core contributors and other community members. I learned a lot, and also managed to have fun along the way :-) I would like to take this opportunity to thank everyone who contributed to the success of Vitrage – either by writing code, suggesting new use cases, participating in our discussions, or helping out when our gate was broken. Eyal Bar-Ilan (irc: eyalb), a Vitrage core contributor who was part of the team from the very beginning, will be replacing me as the new Vitrage PTL [1]. I’m sure he will make an excellent PTL, as someone who knows every piece of the code and is tightly connected to the community. I will still be around to help if needed. I wish Eyal lots of luck in his new role! Ifat [1] https://review.opendev.org/#/c/660563/

5 4

Re: [monasca] Proposing Akhil Jain for Monasca core team
by Joseph Davis 23 May '19

23 May '19

+1 to what Witek wrote. :) Date: Thu, 23 May 2019 13:23:31 +0100 From: Doug Szumski<doug(a)stackhpc.com> To: Witek Bedyk<witold.bedyk(a)suse.com>, openstack-discuss(a)lists.openstack.org Subject: Re: [monasca] Proposing Akhil Jain for Monasca core team Message-ID:<60faa8a1-51ea-bea6-93f0-855fdc0ccde9(a)stackhpc.com> Content-Type: text/plain; charset=utf-8; format=flowed On 23/05/2019 12:24, Witek Bedyk wrote: > Hello team, > > I would like to propose Akhil Jain to join the Monasca core team. +1, thanks for your contributions Akhil! > Akhil has added authenticated webhook notification support [1] and > worked on integrating Monasca with Congress, where he's also the core > reviewer. His work has been presented at the last Open Infrastructure > Summit in Denver [2]. > > Akhil has good understanding of Monasca and OpenStack architecture and > constantly helps us in providing sensible reviews. I'm sure Monasca > project will benefit from this nomination. > > Cheers > Witek > > [1]https://storyboard.openstack.org/#!/story/2003105 > [2] > https://www.openstack.org/summit/denver-2019/summit-schedule/events/23261/p… >

1 0

Re: [nova][dev][ops] server status when compute host is down
by melanie witt 23 May '19

23 May '19

+@openstack-discuss, ML was accidentally dropped from Mohammed's reply On Thu, 23 May 2019 20:45:13 +0800, Mohammed Naser <mnaser(a)vexxhost.com> wrote: > > > On Thu, May 23, 2019, 10:00 AM melanie witt <melwittt(a)gmail.com > <mailto:melwittt@gmail.com>> wrote: > > Hey all, > > I'm looking for feedback around whether we can improve how we show > server status in server list and server show when the compute host it > resides on is down. > > When a compute host goes down while a server on it was previously > running, the server status continues to show as ACTIVE in a server > list. > This is because the power state and status is adjusted by a periodic > task run by nova-compute, so if nova-compute is down, it cannot update > those states. > > So, for an end user, when they do a server list, they see their server > as ACTIVE when it's actually powered off. > > We have another field called 'host_status' available since API > microversion 2.16 [1] which is controlled by policy and defaults to > admin, which is capable of showing the server status as UNKNOWN if the > field is specified, for example: > > nova list --fields > id,name,status,task_state,power_state,networks,host_status > > This is cool, but it is only available to admin by default, and it > requires that the end user adds the field to their CLI command in the > --fields option. > > Question: do people think we should make the server status field > reflect > UNKNOWN as well, if the 'host_status' is UNKNOWN? And if so, should it > be controlled by policy or no? > > > I'm in support of this. I also agree on the fact it should be controlled > by policy however not to get too ahead of my self: > > - I think it should ideally be defaulted to true > - ideally this should be an API level policy and not compute level > > Normally, we do not expose compute host details to non-admin in the API > by default, but I noticed recently that our "down cells" support will > show server status as UNKNOWN if a server is in a down cell [2]. So I > wondered if it would be considered OK to show UNKNOWN if a host is down > we well, without defaulting it to admin-only. > > I would really appreciate if people could share their opinion here and > if consensus is in support, I will move forward with proposing a change > accordingly. > > Cheers, > -melanie > > > Thank you for proposing this > > [1] > https://docs.openstack.org/nova/latest/reference/api-microversion-history.h… > [2] > https://github.com/openstack/nova/blob/66a77f2fb75bbb9daebdca1cad0255ecafe4… >

1 0

[all][docs] season of docs
by Mohammed Naser 23 May '19

23 May '19

Hi there: It seems like Google has come up with a new somewhat-GSoC-like idea but focused on documentation. I think it could be a good opportunity for the documentation team (or any specific team actually, coordinated with docs) to be part of this. https://opensource.googleblog.com/2019/03/introducing-season-of-docs.html I'm not sure if the team has the amount of resources, but it seems they should be able to apply to this. Does this seem like something that might help the team more (or perhaps a specific project, coordinating with the docs team) to apply for this? Thanks, Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

7 10

Summit video website shenanigans
by Matt Riedemann 23 May '19

23 May '19

On Sunday I was able to pull up several of the summit videos on youtube via the summit phone app, e.g. [1] but when trying to view the same videos from the summit video website I'm getting errors [2]. Is there just something still in progress with linking the videos on the https://www.openstack.org/videos/ site? Note that in one case 15 minutes of a talk was chopped (40 minute talk chopped to 25 minutes) [3]. I reckon I should take that up directly with the speakersupport(a)openstack.org team though? [1] https://www.youtube.com/watch?v=YdSVY4517sE [2] https://www.openstack.org/videos/summits/denver-2019/the-vision-for-opensta… [3] https://www.youtube.com/watch?v=OyNFIOSGjac -- Thanks, Matt

3 4

[glance][interop] standardized image "name" ?
by Mohammed Naser 23 May '19

23 May '19

Hi everyone, Something that I've been dealing with is the fact that regardless of what cloud you're using, the naming structure is very much different. While we aim to be interoperable, if I want to "boot an Debian Stretch server", the image name will probably be different all over the places. Is there some sort of way we can eliminate this by implementing a standard naming convention which would allow us to use the same images across all systems? I'm just opening the idea for discussion, I'd love to hear what others think about this. Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

15 22

Re: [nova] Validation for requested host/node on server create
by Boxiang Zhu 23 May '19

23 May '19

+1 for option 3, too. Check host/hypervisor_hostname fisrt in API layer so that we will not create a "ERROR" vm with "NoValidHost" exception. >> It seems we've come to an impasse on this change [1] because of a >> concern about where to validate the requested host and/or >> hypervisor_hostname. >> >> The change is currently validating in the API to provide a fast fail 400 >> response to the user if the host and/or node don't exist. The concern is >> that the lookup for the compute node will be done again in the scheduler >> [2]. Also, if the host is not provided, then to validate the node we >> have to iterate the cells looking for the given compute node (we could >> use placement though, more on that below). >> >> I've added this to the nova meeting agenda for tomorrow but wanted to >> try and enumerate what I see are the options before the meeting so we >> don't have to re-cap all of this during the meeting. >> >> The options as I see them are: >> >> 1. Omit the validation in the API and let the scheduler do the validation. >> >> Pros: no performance impact in the API when creating server(s) >> >> Cons: if the host/node does not exist, the user will get a 202 response >> and eventually a NoValidHost error which is not a great user experience, >> although it is what happens today with the availability_zone forced >> host/node behavior we already have [3] so maybe it's acceptable. >> >> 2. Only validate host in the API since we can look up the HostMapping in >> the API DB. If the user also provided a node then we'd just throw that >> on the RequestSpec and let the scheduler code validate it. >> >> Pros: basic validation for the simple and probably most widely used case >> since for non-baremetal instances the host and node are going to be the same >> >> Cons: still could have a late failure in the scheduler with NoValidHost >> error; does not cover the case that only node (no host) is specified >> >> 3. Validate both the host and node in the API. This can be broken down: >> >> a) If only host is specified, do #2 above. >> b) If only node is specified, iterate the cells looking for the node (or >> query a resource provider with that name in placement which would avoid >> down cell issues) >> c) If both host and node is specified, get the HostMapping and from that >> lookup the ComputeNode in the given cell (per the HostMapping) >> >> Pros: fail fast behavior in the API if either the host and/or node do >> not exist >> >> Cons: performance hit in the API to validate the host/node and >> redundancy with the scheduler to find the ComputeNode to get its uuid >> for the in_tree filtering on GET /allocation_candidates. >> >> Note that if we do find the ComputeNode in the API, we could also >> (later?) make a change to the Destination object to add a node_uuid IMHO, is it better to call it compute_node_uuid? : ) >> field so we can pass that through on the RequestSpec from >> API->conductor->scheduler and that should remove the need for the >> duplicate query in the scheduler code for the in_tree logic. >> >> I'm personally in favor of option 3 since we know that users hate >> NoValidHost errors and we have ways to mitigate the performance overhead >> of that validation. > >Count me in the option 3 boat too, for the same reasons. Rather avoid >NoValidHost and there's mitigation we can do for the perf issue. > >-melanie > >> Note that this isn't necessarily something that has to happen in the >> same change that introduces the host/hypervisor_hostname parameters to >> the API. If we do the validation in the API I'd probably split the >> validation logic into it's own patch to make it easier to test and >> review on its own. >> >> [1] https://review.opendev.org/#/c/645520/ >> [2] >> https://github.com/openstack/nova/blob/2e85453879533af0b4d0e1178797d26f026a… >> [3] https://docs.openstack.org/nova/latest/admin/availability-zones.html >> -- Boxiang

1 0

[blazar] Limits to reservation usage
by Pierre Riteau 23 May '19

23 May '19

Hello, We had a very interesting first Blazar IRC meeting for the Americas last week [1]. One of the topics discussed was enforcing limits to reservation usage. Currently, upstream Blazar doesn't provide ways to limit reservations per user or project. It is technically possible for users to reserve more resources than what their quotas allows them to use. The Chameleon project, which has been running Blazar in production for several years, has extended it to: a) enforce operator-defined limits to reservation length (e.g. 7 days) b) when creating or updating reservations, check whether the project has enough available Service Units (SU) in their allocation, which is stored in a custom external database George Turner from Indiana University Bloomington explained how Jetstream, if it were to use Blazar to share GPU resources, would have a similar requirement to check reservation usage against XSEDE allocations (which are again stored in a custom database). I am starting this thread to discuss how Blazar can support enforcing these kinds of limits, making sure that it is generic enough to be plugged with the various custom allocation backends in use. 1) Blazar should check Nova limits as a guide for limiting reservation usage at any point in time: if number of instances quota is 8, we shouldn't allow the user to reserve more than 8 instances at any point in time. 2) In addition, Blazar could use a quota to limit how much resources can be allocated in advance. Operators may be happy for projects to reserve 8 instances for a month, but not for a century. This could be expressed as a time dimension that would apply to the instance / cores / ram quotas. 3) If Blazar was making REST requests to a customisable endpoint on reservation creation / update, expecting to get a simple yes/no answer (with a human-friendly error message, like how much SUs are left compared to how much would be used), would people be motivated to write a small REST service making the link between Blazar and any custom allocation backend? Feel free to reply to this message or join our next meeting on Thursday May 23 at 1600 UTC. Cheers, Pierre [1] http://eavesdrop.openstack.org/meetings/blazar/2019/blazar.2019-05-09-16.01…

2 1

[Infra][ironic][Release-job-failures] release-post job for openstack/releases failed
by Sean McGinnis 23 May '19

23 May '19

There was a failure in the post job for ironic-inspector in stable/stein. The error was after tagging during the log collection task. "rsync: connection unexpectedly closed" http://logs.openstack.org/8f/8f71bcfb8d02cae91d0e49e5813c03c745745c92/relea… It appears all necessary tasks completed though, so I believe this should be safe to ignore. This failures caused the doc publishing job to be skipped, but we had other releases that would have picked that up. Just sharing in case we run into something similar again and need to start tracking down root cause of the rsync failure. If anyone sees anything unusual that may be a side effect of this, please let us know and we can try to investigate. Sean ----- Forwarded message from zuul(a)openstack.org ----- Date: Wed, 22 May 2019 16:08:49 +0000 From: zuul(a)openstack.org To: release-job-failures(a)lists.openstack.org Subject: [Release-job-failures] release-post job for openstack/releases failed Reply-To: openstack-discuss(a)lists.openstack.org Build failed. - tag-releases http://logs.openstack.org/8f/8f71bcfb8d02cae91d0e49e5813c03c745745c92/relea… : POST_FAILURE in 4m 48s - publish-tox-docs-static publish-tox-docs-static : SKIPPED _______________________________________________ Release-job-failures mailing list Release-job-failures(a)lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures ----- End forwarded message -----

3 3

[telemetry] Team meetings on May 23rd 02:00 and 08:00
by Trinh Nguyen 23 May '19

23 May '19

Hi team, I have sent this in another thread but I think It would better to do it in a separate email. According to the poll [1], I will organize 2 meeting sessions on May 23rd: - Core contributors (mostly in APAC): 02:00-03:00 UTC - Cross-projects contributors (mostly in the US or around): 08:00-09:00 UTC Some core members or at least myself will be able to attend both meetings so I think it should be fine. I draft the meeting agenda in [2]. Please check it out and input the topics that you want to discuss but remember the 1-hour meeting constraint. [1] https://doodle.com/poll/cd9d3ksvpms4frud [2] https://etherpad.openstack.org/p/telemetry-meeting-agenda Bests, -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

1 2