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

Re: [openstack-dev] Are we ready to put stable/ocata into extended maintenance mode?
by Alex Schultz 03 Mar '21

03 Mar '21

On Tue, Sep 18, 2018 at 1:30 PM Alex Schultz <aschultz(a)redhat.com> wrote: > > On Tue, Sep 18, 2018 at 1:27 PM, Matt Riedemann <mriedemos(a)gmail.com> wrote: > > The release page says Ocata is planned to go into extended maintenance mode > > on Aug 27 [1]. There really isn't much to this except it means we don't do > > releases for Ocata anymore [2]. There is a caveat that project teams that do > > not wish to maintain stable/ocata after this point can immediately end of > > life the branch for their project [3]. We can still run CI using tags, e.g. > > if keystone goes ocata-eol, devstack on stable/ocata can still continue to > > install from stable/ocata for nova and the ocata-eol tag for keystone. > > Having said that, if there is no undue burden on the project team keeping > > the lights on for stable/ocata, I would recommend not tagging the > > stable/ocata branch end of life at this point. > > > > So, questions that need answering are: > > > > 1. Should we cut a final release for projects with stable/ocata branches > > before going into extended maintenance mode? I tend to think "yes" to flush > > the queue of backports. In fact, [3] doesn't mention it, but the resolution > > said we'd tag the branch [4] to indicate it has entered the EM phase. > > > > 2. Are there any projects that would want to skip EM and go directly to EOL > > (yes this feels like a Monopoly question)? > > > > I believe TripleO would like to EOL instead of EM for Ocata as > indicated by the thead > http://lists.openstack.org/pipermail/openstack-dev/2018-September/134671.ht… > Bringing this backup to see what we need to do to get the stable/ocata branches ended for the TripleO projects. I'm bringing this up because we have https://review.openstack.org/#/c/647009/ which is for the upcoming rename but CI is broken and we have no interest in continue to keep the stable/ocata branches alive (or fix ci for them). Thanks, -Alex > Thanks, > -Alex > > > [1] https://releases.openstack.org/ > > [2] > > https://docs.openstack.org/project-team-guide/stable-branches.html#maintena… > > [3] > > https://docs.openstack.org/project-team-guide/stable-branches.html#extended… > > [4] > > https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.… > > > > -- > > > > Thanks, > > > > Matt > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

5 11

[Syntribos] Does anyone still use this?
by Gage Hugo 08 May '20

08 May '20

The Security SIG has recently been looking into updating several sites/documentation and one part we discussed the last couple meetings was the security tools listings[0]. One of the projects listed there, Syntribos, doesn't appear to have much activity[1] outside of zuul/python/docs maintenance and the idea of retiring the project was mentioned. However, there does seem to be an occasional bug-fix submitted, so we are sending this email out to see if anyone is still utilizing Syntribos. If so, please either respond here, reach out to us in the #openstack-security irc channel, or fill out the section in the Security SIG Agenda etherpad[2]. Thanks! [0] https://security.openstack.org/#security-tool-development [1] https://review.opendev.org/#/q/project:openstack/syntribos [2] https://etherpad.openstack.org/p/security-agenda

2 2

[openstack-ansible] dropping suse support
by Mohammed Naser 06 May '20

06 May '20

Hi everyone, I've been trying to avoid writing this email for the longest time ever. It's really painful to have to reach this state, but I think we've hit a point where we can no longer maintain support for SUSE within OpenStack Ansible. Unfortunately, with the recent layoffs, the OSA team has taken a huge hit in terms of contributors which means that there is far less contributors within the project. This means that we have less resources to go around and it forces us to focus on a more functional, reliable and well tested set of scenarios. Over the past few cycles, there has been effort to add SUSE support to OpenStack Ansible, during the time that we had maintainers, it was great and SUSE issues were being fixed promptly. In addition, due to the larger team at the time, we found ourselves having some extra time where we can help unbreak other gates. Jesse used to call this a "labour of love", which I admired at the time and hoped we continue to do as much as we can of. However, the lack of a committed maintainer for OpenSUSE has resulted in constantly failing jobs[1][2] (which were moved to non-voting, wasting CI resources as no one fixed them). In addition, it's causing several gate blocks for a few times with no one really finding the time to clean them up. We are resource constrained at this point and we need the resource to go towards making the small subset of supported features functional (i.e. CentOS/Ubuntu). We struggle with that enough, and there seems to be no deployers that are running SUSE in real life at the moment based on bugs submitted. With that, I propose that we drop SUSE support this cycle. If anyone would like to volunteer to maintain it, we can review that option, but that would require a serious commitment as we've had maintainers step off and it hurts the velocity of the project as no one can merge code anymore. ..Really wish I didn't have to write this email Mohammed [1]: http://zuul.opendev.org/t/openstack/builds?job_name=openstack-ansible-funct… [2]: http://zuul.opendev.org/t/openstack/builds?job_name=openstack-ansible-funct…

6 9

[nova]review guide for the policy default refresh spec
by Ghanshyam Mann 30 Oct '19

30 Oct '19

Hello Everyone, As many of you might know that in Train, we are doing Nova policy changes to adopt the keystone's new defaults and scope type[1]. There are multiple changes required per policy as mentioned in spec. I am writing this review guide for the patch sequence and at the end how each policy will look like. I have prepared the first set of patches. I would like to get the feedback on those so that we can modify the other policy also on the same line. My plan is to start the other policy work after we merge the first set of policy changes. Patch sequence: Example: os-services API policy: ------------------------------------------------------------- 1. Cover/Improve the test coverage for existing policies: This will be the first patch. We do not have good test coverage of the policy, current tests are not at all useful and do not perform the real checks. Idea is to add the actual tests coverage for each policy as the first patch. new tests try to access the API with all possible context and check for positive and negative cases. - https://review.opendev.org/#/c/669181/ 2. Introduce scope_types: This will add the scope_type for policy. It will be either 'system', 'project' or 'system and project'. In the same patch, along with existing test working as it is, new tests of scope type will be added which will run with [oslo_policy] enforce_scope=True so that we can capture the real scope checks. - https://review.opendev.org/#/c/645427/ 3. Add new default roles: This will add new defaults which can be SYSTEM_ADMIN, SYSTEM_READER, PROJECT_MEMBER_OR_SYSTEM_ADMIN, PROJECT_READER_OR_SYSTEM_READER etc depends on Policy. Test coverage of new defaults, as well as deprecated defaults, are covered in same patch. This patch will add the granularity in policy if needed. Without policy granularity, we cannot add new defaults per rule. - https://review.opendev.org/#/c/648480/ (I need to add more tests for deprecated rules) 4. Pass actual Targets in policy: This is to pass the actual targets in context.can(). Main goal is to remove the defaults targets which is nothing but context'user_id,project_id only. It will be {} if no actual target data needed in check_str. - https://review.opendev.org/#/c/676688/ Patch sequence: Example: Admin Action API policy: 1. https://review.opendev.org/#/c/657698/ 2. https://review.opendev.org/#/c/657823/ 3. https://review.opendev.org/#/c/676682/ 4. https://review.opendev.org/#/c/663095/ There are other patches I have posted in between for common changes or fix or framework etc. [1] https://specs.openstack.org/openstack/nova-specs/specs/train/approved/polic… -gmann

1 2

[metrics] [telemetry] [stein] cpu_util
by Budai Laszlo 18 Oct '19

18 Oct '19

Hello all, the release release announce of ceilometer rocky is deprecating the cpu_util and *.rate metrics "* cpu_util and *.rate meters are deprecated and will be removed in future release in favor of the Gnocchi rate calculation equivalent." so we don't have them in Stein. Can you direct me to some document that describes how to achieve these with Gnocchi rate calculation? Thank you, Laszlo

5 4

[aodh] [heat] Stein: How to create alarms based on rate metrics like CPU utilization?
by Bernd Bausch 18 Oct '19

18 Oct '19

Prior to Stein, Ceilometer issued a metric named /cpu_util/, which I could use to trigger alarms and autoscaling when CPU utilization was too high. cpu_util doesn't exist anymore. Instead, we are asked to use Gnocchi's /rate/ feature. However, when using rates, alarms on a group of resources require more parameters than just one metric: Both an aggregation and a reaggregation method are needed. For example, a group of instances that implement "myapp": gnocchi measures aggregation -m cpu --reaggregation mean --aggregation rate:mean --query server_group=myapp --resource-type instance Actually, this command uses a deprecated API (but from what I can see, Aodh still uses it). The new way is like this: gnocchi aggregates --resource-type instance '(aggregate rate:mean (metric cpu mean))' server_group=myapp If rate:mean is in the archive policy, it also works the other way around: gnocchi aggregates --resource-type instance '(aggregate mean (metric cpu rate:mean))' server_group=myapp Without reaggregation, I get quite unexpected numbers, including negative CPU rates. If you want to understand why, see this discussion with one of the Gnocchi maintainers [1]. *My problem*: Aodh allows me to set an aggregation method, but not a reaggregation method. How can I create alarms based on rates? The problem extends to Heat and autoscaling. Thanks much, Bernd. [1] https://github.com/gnocchixyz/gnocchi/issues/1044

4 3

[all] [tc] [docs] [release] [ptls] Docs as SIG: Ownership of docs.openstack.org
by Alexandra Settle 03 Oct '19

03 Oct '19

Hi all, Quick recap: The documentation team is set to disband as an official project, and make the leap to becoming a SIG (Special Interest Group). This decision is not one we have made lightly, but with the changes of direction since Pike (project documentation belonging with the projects, etc) the need for a centralised documentation team as an official project is no longer integral to producing the software. The transition of the docs team to a SIG has already begun [1] and [2]. The openstackdocstheme, openstack-doc-tools, os-api-ref and whereto have been placed within the remit of the Oslo team and approved. The remaining individuals working on the docs team are sorting through what's left and where it is best placed. In [1], Doug has rightfully pointed out that whilst the documentation team as it stands today is no longer "integral", the docs.openstack.org web site is. An owner is required. The suggestion is for the Release Management team is the "least worst" (thanks, tonyb) place for the website manaagement to land. As Tony points out, this requires learning new tools and processes but the individuals working on the docs team currently have no intention to leave, and are around to help manage this from the SIG. Open to discussion and suggestions, but to summarise the proposal here: docs.openstack.org ownership is to transition to be the responsibility of the Release Management team officially provided there are no strong objections. Thanks, Alex IRC: asettle [1] https://review.opendev.org/#/c/657142/ [2] https://review.opendev.org/#/c/657141/

5 11

[kolla-ansible] migration
by Ignazio Cassano 03 Oct '19

03 Oct '19

Hello, Anyone have tried to migrate an existing openstack installation to kolla containers? Thanks Ignazio

5 16

[tc][uc][all] Starting goal selection for U series
by Ghanshyam Mann 26 Sep '19

26 Sep '19

Hello everyone, We are in R10 week of Train cycle and not so far from the start of U cycle. It's time to start the discussions about community-wide goals ideas for the U series. We are little late to start this thread for U series which usually happened during Summit Forum. But it is not mandatory to wait for f2f meetup to kick off the goal discussions, we can always start the same via ML or ad-hoc meetings. During Shanghai Summit Forum, we will be having the f2f discussion for U (continue the discussion from ML threads) as well as V cycle goals ideas. Community-wide goals are important in term of solving and improving a technical area across OpenStack as a whole. It has lot more benefits to be considered from users as well from a developers perspective. See [1] for more details about community-wide goals and process. Also, you can refer to the backlogs of community-wide goals from this[2] and train cycle goals[3]. If you are interested in proposing a goal, please write down the idea on this etherpad[4] - https://etherpad.openstack.org/p/PVG-u-series-goals Accordingly, we will start the separate ML discussion over each goal idea. [1] https://governance.openstack.org/tc/goals/index.html [2] https://etherpad.openstack.org/p/community-goals [3] https://etherpad.openstack.org/p/BER-t-series-goals [4] https://etherpad.openstack.org/p/PVG-u-series-goals -gmann

1 1

[nova][glance][entropy][database] update glance metadata for nova instance
by Jordan Ansell 11 Sep '19

11 Sep '19

Hi Openstack Discuss, I have an issue with nova not synchronizing changes between a glance image and it's local image meta information in nova. I have updated a glance image with the property "hw_rng_model=virtio", and that successfully passes that to new instances created using the updated image. However existing instances do not receive this new property. I have located the image metadata within the nova database, in the **instance_system_metadata** table, and can see it's not updated for the existing instances, and only adding the relevant rows for instances that are created when that property is present. The key being "image_hw_rng_model" and "virtio" being the value. Is there a way to tell nova to update the table for existing instances, and synchronizing the two databases? Or is this the kind of thing that would need to be done *shudder* manually...? If so, are there any experts out there who can point me to some documentation on doing this correctly before I go butcher a couple of dummy nova database? Regards, Jordan

3 4

[nova][keystone][neutron][kuryr][requirements] breaking tests with new library versions
by Matthew Thode 11 Sep '19

11 Sep '19

NOVA: lxml===4.4.1 nova tests fail https://bugs.launchpad.net/nova/+bug/1838666 websockify===0.9.0 tempest test failing KEYSTONE: oauthlib===3.1.0 keystone https://bugs.launchpad.net/keystone/+bug/1839393 NEUTRON: tenacity===5.1.1 https://2c976b5e9e9a7bed9985-82d79a041e998664bd1d0bc4b6e78332.ssl.cf2.rackc… this could be caused by pytest===5.1.0 as well KURYR: kubernetes===10.0.1 openshift PINS this, only kuryr-tempest-plugin deps on it https://review.opendev.org/665352 MISC: tornado===5.1.1 salt is cauing this, no eta on fix (same as the last year) stestr===2.5.0 needs merged https://github.com/mtreinish/stestr/pull/265 jsonschema===3.0.2 see https://review.opendev.org/649789 I'm trying to get this in place as we are getting closer to the requirements freeze (sept 9th-13th). Any help clearing up these bugs would be appreciated. -- Matthew Thode

7 18

[mistral] Publish field in workflow tasks
by Ali Abdelal 09 Sep '19

09 Sep '19

Hello, Currently, there are two "publish" fields, one in the task(regular "publish")-the scope is branch and not global, and another under "on-success", “on-error” or “on-complete”. In the current behavior, regular "publish" is ignored if there is "publish" under "on-success", “on-error” or “on-complete” [1]. For example:- (a) version: '2.0' wf1: tasks: t1: publish: res_x1: 1 on-success: publish: branch: res_x2: 2 (b) version: '2.0' wf2: tasks: t1: publish: res_x1: 1 "res_x1" won't be published in (a), but it will in (b). We can either:- 1) Invalidate such syntax. 2) Merge the two publishes together and if there are duplicate keys, there are two options:- a) What takes priority is what's in publish under "on-success" or “on-error” or “on-complete. b) Not allow having a duplicate. What is your opinion? And please tell us if you have other suggestions. [1] https://bugs.launchpad.net/mistral/+bug/1791449

2 1

[all][tc] PDF Community Goal Update
by Akihiro Motoki 07 Sep '19

07 Sep '19

Hi all, I would like to share the status of the PDF community goal. We made great progresses these two weeks. Highlights ---------- It is time for working on the PDF community goal in your project! - openstack-tox-docs job supports PDF build now. AJaeger and I worked on the job support of PDF doc build and publishing and have completed it. - We confirmed PDF build with the sphinx latex builder works for several major projects like nova, cinder and neutron. The approach with the latex builder should work for most projects. - First PDF doc is now published from the i18n project. How to get started ------------------ - "How to get started" section in the PDF goal etherpad [1] explains the minimum steps. You can find useful examples there too. - To build PDF docs locally, you need to install LaTex related packages. See "To test locally" in the etherpad [1]. - If you hit problems during PDF build, check the common problems etherpad [2]. We are collecting knowledges there. - If you have questions, feel free to ask #openstack-doc IRC channel. Also Please sign up your name to "Project volunteers" in [1]. Useful links ------------ [1] https://etherpad.openstack.org/p/train-pdf-support-goal [2] https://etherpad.openstack.org/p/pdf-goal-train-common-problems [3] Ongoing reviews: https://review.opendev.org/#/q/topic:build-pdf-docs+(status:open+OR+status:… Thanks, Akihiro Motoki (amotoki)

9 15

[tripleo] Proposing Damien Ciabrini as core on TripleO/HA
by Michele Baldessari 06 Sep '19

06 Sep '19

Hi all, Damien (dciabrin on IRC) has always been very active in all HA things in TripleO and I think it is overdue for him to have core rights on this topic. So I'd like to propose to give him core permissions on any HA-related code in TripleO. Please vote here and in a week or two we can then act on this. Thanks, -- Michele Baldessari <michele(a)acksyn.org> C2A5 9DA3 9961 4FFB E01B D0BC DDD4 DCCB 7515 5C6D

16 15

[keystone][edge] Edge Hacking Days - August 16
by Ildiko Vancsa 04 Sep '19

04 Sep '19

Hi, It is a friendly reminder that we are having the second edge hacking days in August this Friday (August 16). The dial-in information is the same, you can find the details here: https://etherpad.openstack.org/p/osf-edge-hacking-days If you’re interested in joining please __add your name and the time period (with time zone) when you will be available__ on these dates. You can also add topics that you would be interested in working on. We will keep on working on two items: * Keystone to Keystone federation testing in DevStack * Building the centralized edge reference architecture on Packet HW using TripleO Please let me know if you have any questions. See you on Friday! :) Thanks, Ildikó

1 1

[Horizon] [stable] Adding Radomir Dopieralski to horizon-stable-maint
by Ivan Kolodyazhny 03 Sep '19

03 Sep '19

Hi team, I'd like to propose adding Radomir Dopieralski to the horizon-stable-maint team. He's doing good quality reviews for stable branches [1] on a regular basis and I think Radomir will be a good member of our small group. [1] https://review.opendev.org/#/q/reviewer:openstack%2540sheep.art.pl+NOT+bran… Regards, Ivan Kolodyazhny, http://blog.e0ne.info/

2 2

[keystone] Weekly meeting for September 3rd 2019
by Morgan Fainberg 03 Sep '19

03 Sep '19

As of this time, we are planning to skip the keystone weekly meeting for 2019-09-03. This is to allow for work to continue with less interruption as well as US-based folks who have Labor Day (2019-09-02 this year) off to continue to make progress in light of the abbreviated week. As always, please feel free to join us on irc (freenode) in #openstack-keystone if you have any questions. I am also available (irc nic: kmalloc ). Cheers, --Morgan

1 1

[tc] Gradually reduce TC to 11 members over 2020
by Thierry Carrez 03 Sep '19

03 Sep '19

Hi everyone, The size of the TC is a trade-off between getting enough community representation and keeping enough members engaged and active. The current size (13 members) was defined by in 2013, as we moved from 5 directly-elected seats + all PTLs (which would have been 14 people) to a model that could better cope with our explosive growth. Since then, 13 has worked well, to ensure that new blood could come in at every cycle. I would argue that today, there are far less need to get wide representation in the TC (we are pretty aligned), and less difficulty to enter the TC (there is more turnover). In 2019 OpenStack, 13 members is a rather large group. It is becoming difficult to find 13 people able to commit to a significant amount of time over the coming year. And it is difficult to keep all those 13 members active and engaged. IMHO it is time to reduce the TC to 11 members, which sounds like a more reasonable and manageable size. We should encourage people to stop for a while and come back, rather than burn too many people at the same time. We should encourage more people to watch from the sidelines, rather than have a group so large that everyone that can be in it is in it. This would not be a big-bang change, just something we would gradually put in place over the next year. My strawman plan would be as follows: - Sept. 2019 election: no change, elect 6 seats as planned - Feb. 2020 election: elect 6 seats instead of 7 - Sept. 2020 election: elect 5 seats instead of 6 - Then elect 6 seats at every start-of-year and 5 at every end-of-year That would result in TC membership sizes: - U cycle (Q4 2019/Q1 2020): 13 members - V cycle (Q2/Q3 2020): 12 members - W cycle (Q4 2020/Q1 2021): 11 members - after that: 11 members FWIW, I intend to not run for reelection in the Feb 2020 election, so nobody else has to sacrifice their seat to that reform for that election :) Thoughts? -- Thierry Carrez (ttx)

13 18

[tc] not seeking reelection
by Lance Bragstad 02 Sep '19

02 Sep '19

Hi all, Now that the nomination period is open for TC candidates, I'd like to say that I won't be running for a second term on the TC. My time on the TC has enriched my understanding of open-source communities and I appreciate all the time people put into helping me get up-to-speed. I wish the best of luck to folks putting their hat in the ring this week! Thanks all, Lance

5 4

[tc][elections] Not seeking re-election to TC
by Julia Kreger 02 Sep '19

02 Sep '19

Greetings everyone, I wanted to officially let everyone know that I will not be running for re-election to the TC. I have enjoyed serving on the TC for the past two years. Due to some changes in my personal and professional lives, It will not be possible for me to serve during this next term. Thanks everyone! -Julia

8 7

[tc][elections] Not running for reelection to TC this term
by Jeremy Stanley 02 Sep '19

02 Sep '19

I've been on the OpenStack Technical Committee continuously for several years, and would like to take this opportunity to thank everyone in the community for their support and for the honor of being chosen to represent you. I plan to continue participating in the community, including in TC-led activities, but am stepping back from reelection this round for a couple of reasons. First, I want to provide others with an opportunity to serve our community on the TC. I hope that by standing aside for now, others will be encouraged to run. A regular influx of fresh opinions helps us maintain the requisite level of diversity to engage in productive debate. Second, the scheduling circumstances for this election, with the TC and PTL activities combined, will be a bit more complicated for our election officials. I'd prefer to stay engaged in officiating so that we can ensure it goes as smoothly for everyone a possible. To do this without risking a conflict of interest, I need to not be running for office. It's quite possible I'll run again in 6 months, but for now I'm planning to help behind the scenes instead. Best of luck to all who decide to run for election to any of our leadership roles! -- Jeremy Stanley

9 8

not running for the TC this term
by Doug Hellmann 02 Sep '19

02 Sep '19

Since nominations open this week, I wanted to go ahead and let you all know that I will not be seeking re-election to the Technical Committee this term. My role within Red Hat has been changing over the last year, and while I am still working on projects related to OpenStack it is no longer my sole focus. I will still be around, but it is better for me to make room on the TC for someone with more time to devote to it. It’s hard to believe it has been 6 years since I first joined the Technical Committee. So much has happened in our community in that time, and I want to thank all of you for the trust you have placed in me through it all. It has been an honor to serve and help build the community. Thank you, Doug

8 7

[oslo] Proposing Gabriele Santomaggio as oslo.messaging core
by Ben Nemec 02 Sep '19

02 Sep '19

Hello Norsk, It is my pleasure to propose Gabriele Santomaggio (gsantomaggio) as a new member of the oslo.messaging core team. He has been contributing to the project for about a cycle now and has gotten up to speed on our development practices. Oh, and he wrote the book on RabbitMQ[0]. :-) Obviously we think he'd make a good addition to the core team. If there are no objections, I'll make that happen in a week. Thanks. -Ben 0: http://shop.oreilly.com/product/9781849516501.do

7 7

[ptl][cinder] U Cycle PTL Non-Candidacy ...
by Jay Bryant 02 Sep '19

02 Sep '19

All, I just wanted to communicate that I am not going to be running for another term as Cinder's PTL. It has been an honor to lead the Cinder team for the last two years. When I started working with OpenStack nearly 6 years ago, leading the Cinder team was one of my goals and I appreciate the team trusting me with this responsibility for the last 4 cycles. I have enjoyed watching the project evolve over the last couple of years, going from a focus on getting new features in place to a focus on ensuring that customers get reliable storage management with an ever improving user experience. Cinder's value in the storage community outside of OpenStack has been validated as other SDS solutions have leveraged it to provide storage management for the many vendors that Cinder supports. Cinder continues to grow by adding things like cinderlib, making it relevant not only in virtualized environments but also for containerized environments. I am glad that I have been able to help this evolution happen. As PTLs have done in the past, it is time for me to pursue other opportunities in the OpenStack ecosystem and hand over the reigns to a new leader. Cinder has a great team and will continue to do great things. Fear not, I am not going to go anywhere, I plan to continue to stay active in Cinder for the foreseeable future. Again, thank you for the opportunity to be Cinder's PTL, it has been a great ride! Sincerely, Jay Bryant (irc: jungleboyj)

3 2

[nova] Status of the bp support-move-ops-with-qos-ports
by Balázs Gibizer 01 Sep '19

01 Sep '19

Hi, As feature freeze is closing in I try to raise awareness of the implementation status of the support-move-ops-with-qos-ports<https://review.opendev.org/#/q/status:open+project:openstack/nova+branch:ma…> bp [1]. The original goal of the bp was to support every move operations (cold migrate, resize, live-migrate, evacuate, unshelve). Today I have ready and tested (unit + functional) patches proposed for cold migrate and resize [2]. I don't think every move operations will be ready and merged in Train but I still hope that there is a chance for cold migrate and resize to land. Sure I will continue working on supporting the operations that miss the Train in the U release. One possible complication in the current patch series is that it proposes the necessary RPC changes for _every_ move operations [3]. This might not be what we want to merge in Train if only cold migrate and resize support fill fit. So I see two possible way forwards: a) Others also feel that cold migrate and resize will fit into Train, and then I will quickly change [3] to only modify those RPCs. b) We agree to postpone the whole series to U. Then I will not spend too much time on reworking [3] in the Train timeframe. A connected topic: I proposed patches [4] to add cold migrate and resize tempest coverage to the nova-grenade-multinode (renamed from nova-grenade-live-migrate) job as Matt pointed out in [3] that we don't have such coverage and that my original change in [3] would have broken a mixed-compute-version deployment. Any feedback is appreciated. Cheers, gibi [1] https://specs.openstack.org/openstack/nova-specs/specs/train/approved/suppo… [2] https://review.opendev.org/#/q/topic:bp/support-move-ops-with-qos-ports [3] https://review.opendev.org/#/c/655721 [4] https://review.opendev.org/#/c/679210

4 5

[neutron][qa] Databases used on CI jobs
by Slawek Kaplonski 01 Sep '19

01 Sep '19

Hi, Recently in Neutron we merged patch [1] which caused error in Kolla-ansible [2]. It seems that issue happens on mariadb 10.1 which is used in broken Kolla-ansible job so I started checking what database is used on Neutron’s jobs as we didn’t found any issue with this patch. And it seems that in all scenario/api jobs we have installed mysql 5.7 - see [3] for example. And the question is - should we maybe switch somehow to Mariadb instead of Mysql? Should it be done globally or maybe it’s only “issue” in Neutron’s CI jobs? Or maybe we should have jobs with both Mariadb and Mysql databases? [1] https://review.opendev.org/#/c/677221 [2] https://bugs.launchpad.net/kolla-ansible/+bug/1841907 [3] https://2f275f27875ae066d2b6-00a9605a715176e6bd23401c23e881d7.ssl.cf2.rackc… — Slawek Kaplonski Senior software engineer Red Hat

4 6

[qa][ptl][election] Quality Assurance PTL Candidacy for Ussuri
by Ghanshyam Mann 01 Sep '19

01 Sep '19

Hi Everyone, I would like to announce my candidacy for Quality Assurance PTL role for Ussuri cycle. It was a great experience while serving QA PTL for the last three cycles. With very few active contributions, I am proud on the team to keep the QA tooling up and maintained. Making sure no gate break and keep the OpenStack stability as a priority. In Train Cycle, we concentrate on a few key things like improving the gate stability which was tried with breaking the integrate-gate project template into project-specific template[1]. Migrating all the OpenStack CI/CD from Xenial to Bionic etc. We have few more planned work still pending for Train like keystone's system scope testing, making sanity job voting, documenting the QA process etc but I think we will be able to make it in Train as we still have around a month to release Train. Along with daily QA activities, my priority for QA in the next cycle will be: - Release Patrole stable version and find out the way to make it faster so that it can test the API policy on project gate also. - New ideas for more tooling or tests project to focus on OpenStack or Common communities. - Finish the grenade job to zuulv3 which is not yet merged. - Stability of Tempest plugins. There are many tempest plugins which are not so stable. We will plan audit activities for all plugins. I know using Tempest service registry and setting service_availabilty properly is the key things to do on the Plugins side. - Finish the JSON strict validation for volume services. Zhufl has lot of patches to review on this. This will be on priority to finish in the next cycle. - Guiding and motivating more contributors to QA projects. Thanks for reading and consideration my candidacy for Ussuri cycle. [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-July/007568.html -gmann

1 0

[all][tc] Hear ye! Hear ye! Our Newest Release Name - OpenStack Ussuri
by Rico Lin 01 Sep '19

01 Sep '19

Dear all OpenStackers It's my honor to announce OpenStack U release name "*Ussuri" *(naming after Ussuri River). Ussuri has been selected as top one option from community poll and also been lawyer-approved, so it's official. Thanks again for all who join the U release naming processes. -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

6 5

[security] Weekly Newsletter - 29 Aug 2019
by Gage Hugo 01 Sep '19

01 Sep '19

Last two weeks had no meeting activity, however this week we had plenty, so here's the summary. Hope everyone has a great weekend! #Date: 29 Aug 2019 - Security SIG Meeting Info: http://eavesdrop.openstack.org/#Security_SIG_meeting - Weekly on Thursday at 1500 UTC in #openstack-meeting - Agenda: https://etherpad.openstack.org/p/security-agenda - https://security.openstack.org/ - https://wiki.openstack.org/wiki/Security-SIG #Meeting Notes - Summary: http://eavesdrop.openstack.org/meetings/security/2019/security.2019-08-29-1… - OSSA-2019-004 was released this week, more details here: https://security.openstack.org/ossa/OSSA-2019-004.html - The VMT is currently in the process of updating the requirements for a project to obtain the "vulnerability:managed tag, there is a current change in progress here:https://review.opendev.org/#/c/678426/ - The main goal is to reduce the barrier of entry by not explicitly requiring an audit being performed on the project (but still recommending it), as well as clarifications on other guidelines - The security docs are continuing to see updates: https://review.opendev.org/#/q/project:openstack/security-doc - Shoutout to nickthetait for taking on this work, and to those reviewing it as well! - We discussed the default policy file discrepencies in Cinder/Nova in the Queens release, it appears that several projects have different file defaults for policy. - This is causing issues when a policy file works fine in one release, but after upgrading, the file is no longer automatically detected. - One path forward is to open a security docs bug to track these and look for a way to resolve this. #VMT Reports - A full list of publicly marked security issues can be found here: https://bugs.launchpad.net/ossa/ - OSSA-2019-004 was released this week, more details here: https://security.openstack.org/ossa/OSSA-2019-004.html

1 0

[cinder] PTL candidacy
by Brian Rosmaita 31 Aug '19

31 Aug '19

Hello everyone, I would like to announce my candidacy for Cinder PTL for the 'U' cycle. The Cinder project is in a good state right now due to Jay Bryant's leadership and a strong community of developers interested in keeping Cinder stable and relevant. The project has matured (which is a good thing): a look at the cinder-specs repository shows an interest in adding some features, but there's also a large focus on enhancing existing features and introducing improvements to make the software more reliable. And the project's relevance has been continued by the introduction of the cinderlib library that makes Cinder backend drivers usable for applications beyond OpenStack, for example, by the Ember CSI plugin for containers. The Cinder project also faces some challenges. Like all the major OpenStack projects, over the past several cycles it has been showing a decline in the number of contributors and in the diversity of their affiliations. Further, we had a big scare this cycle when it looked like about half of the backend drivers would have to be marked unsupported due to vendors not updating their third-party CI systems to Python 3. (As we approach milestone 3, happily, the situation is looking better.) Much as I'd like to say that as Cinder PTL, my scintillating personality will reverse this trend, the reality is that the days of companies renting out an entire museum in San Diego or Paris to entertain OpenStack contributors are well behind us. (Plus, I don't have a scintillating personality.) The positive way to look at this is that our community has contracted to a hard core of sufficient density as the effluvium is ejected, and we've reached a kind of steady state. Thus I think the main task I would need to undertake as PTL is to focus on nurturing the community we have. This isn't to say that we won't continue to do onboarding and outreach (we will), it's just that the days when an OpenStack project could design features and people would just show up and work on them are in the past. So we need to make sure that the current Cinder community--both developers working on the main project and developers working on vendor drivers--feel well-connected and valued. (This isn't to say they don't feel that way now; my point is that this is important to maintain.) Concrete steps toward this goal are continuing Jay's good work in keeping the Cinder community well-informed of the discussions at weekly meetings, Forum sessions, the PTG, and midcycle, and taking advantage of video meeting software so we can have more (virtual) face-to-face meetings. All this is sounds reasonable enough, but why me? I'm a fairly new member of the Cinder community. I've been a Cinder core contributor since April and have been helping with stable maintenance and releases. I've had some experience as an OpenStack PTL (Glance PTL for O, P, and Q), so I know what I'm getting into. I'm an active participant in the Cinder community, and if you'll have me as PTL, I promise to do my best not to break anything. Thank you for your consideration, Brian Rosmaita (rosmaita)

1 0

[neutron][graphql] Is the graphql branch still being used?
by Miguel Lavalle 31 Aug '19

31 Aug '19

Dear Stackers, Some time ago we created a feature branch in the Neutron repo for a PoC with graphql: https://opendev.org/openstack/neutron/src/branch/feature/graphql Is this PoC still going on? Is the branch still needed? The branch has been inactive since January and we are finding that patches against this branch don't pass zuul tests: https://review.opendev.org/#/c/678144/. If the branch is still being used, the team working on it should fix it so tests pass. If it is not used, let's remove it. If I don't hear back from anyone having interest in maintaining this branch by September 6th, I will go ahead and remove it. Thanks an regards Miguel

5 5

[tc] monthly meeting
by Mohammed Naser 31 Aug '19

31 Aug '19

Hi everyone, Here's the planning for the next TC meeting which will happen on Thursday, September 5th at 1400 UTC. If you’d like to add a topic of discussion, please feel free to do so. We will be cutting off the agenda on Wednesday the 4th so any subject added afterward won’t appear in the plan. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting Regards, Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

1 0

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

31 Aug '19

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

1 0

[election][ptl][swift] Tim Burke's candidacy for Swift PTL
by tim＠swiftstack.com 31 Aug '19

31 Aug '19

I would be honored to continue serving you as Swift PTL. This past cycle, we have laid the foundation for Swift's continued success: we support running Swift on Python 3. This has been long overdue, and a long time coming. While we first began to the process four years ago, momentum has only really picked up for it in the last year and a half. As of last week, all unit tests and functional tests now run under py3. It has been such a joy to see this project finally coming to a close. We certainly benefited greatly by having four and a half years with an exceptionally stable base to build upon, but now we have ensured Swift's future deployability, maintainability, and longevity. John Dickinson's long-time goal that Swift be used everywhere, every day, by everyone could only hope to be fleeting without this community- driven effort. Speaking of, I'm so happy to see that the transition to storing Zuul logs in Swift [1] has gone so smoothly. A half-dozen or so clusters suddenly started ingesting millions more PUTs every day, and yet Clark Boylan says he "[hasn't] heard complaints from the swift clouds" -- I can think of few better compliments on the quality of our software. :-) With many millions of objects getting created every day and a median object size in the tens of kilobytes, this emphasizes another years- long project: OVH's work to optimize small-file workloads. Our next focus should be to integrate their (already running in production!) improvements back into master and disseminate their knowledge of how to hack on, debug, deploy, monitor, and troubleshoot in a brave new world. I look forward to organizing this effort in Ussuri. Tim Burke [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-August/008516.h…

1 0

Metadata service caching old nameservers?
by Grant Morley 31 Aug '19

31 Aug '19

Hi All, We have a bit of a weird issue with resolv.conf for instances. We have changed our subnets in neutron to use googles nameservers which is fine. However it seems that when instances are launched they are still getting the old nameserver settings as well as the new ones. If I look at the metadata networking service it returns the old nameservers as well as the new ones below: curl -i http://169.254.169.254/openstack/2017-02-22/network_data.json HTTP/1.1 200 OK Content-Type: text/plain; charset=UTF-8 Content-Length: 753 Date: Thu, 29 Aug 2019 09:40:03 GMT {"services": [{"type": "dns", "address": "178.18.121.70"}, {"type": "dns", "address": "178.18.121.78"}, {"type": "dns", "address": "8.8.8.8"}, {"type": "dns", "address": "8.8.4.4"}] In our neutron dhcp-agent.ini file we have the correct dnsmasq nameservers set: dnsmasq_dns_servers = 8.8.8.8, 8.8.4.4 Are there any database tables I can change or clear up to ensure the old nameservers no longer get set? I can't seem to find any reference in our config any more of the old nameservers, so I assume one of the services is still setting them but I can't figure out what is. Any help will be much appreciated. Many thanks, -- Grant Morley Cloud Lead, Civo Ltd www.civo.com <https://www.civo.com/>| Signup for an account! <https://www.civo.com/signup>

2 3

[openstack-dev][magnum] Using Fedora Atomic 29 for k8s cluster
by Feilong Wang 30 Aug '19

30 Aug '19

Hi all, At this moment, Magnum is still using Fedora Atomic 27 as the default image in devstack. But you can definitely use Fedora Atomic 29 and it works fine. But you may run into a performance issue when booting Fedora Atomic 29 if your compute host doesn't have enough entropy. There are two steps you need for that case: 1. Adding property hw_rng_model='virtio' to Fedora Atomic 29 image 2. Adding property hw_rng:allowed='True' to flavor, and we also need hw_rng:rate_bytes=4096 and hw_rng:rate_period=1 to get a reasonable rate limit to avoid the VM drain the hypervisor. We are working on a patch for Magnum devstack to support FA29 out of box. Meanwhile, we're starting to test Fedora CoreOS 30. Please popup in #openstack-containers channel if you have any question. Cheers. -- Cheers & Best regards, Feilong Wang (王飞龙) -------------------------------------------------------------------------- Head of R&D Catalyst Cloud - Cloud Native New Zealand Tel: +64-48032246 Email: flwang(a)catalyst.net.nz Level 6, Catalyst House, 150 Willis Street, Wellington --------------------------------------------------------------------------

6 12

[neutron][ptl][elections] Non candidacy for U cycle
by Miguel Lavalle 30 Aug '19

30 Aug '19

Dear Neutron team, It has been an honor to be your PTL for the past four cycles. I have really enjoyed the ride and am thankful for all the support and hard work that you all have provided over these past two years. As I said in my last self-nomination ( http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003714.ht…) I am of the opinion that it is healthy to transfer periodically the baton to a new leader with fresh ideas and energy. One of the focus areas of my PTL tenure has been to keep the team strong by actively helping community members to become contributors and core reviewers. As a consequence, I know for a fact that we have a deep bench of potential new PTLs ready to step up to the plate. As for me, I am not going anywhere. I am very lucky that my management at Verizon Media supports my continued active involvement with the community at large and the Neutron family of projects in particular. So I look forward to help the team in the upcoming U cycle and beyond. Thank you soooo much! Miguel

9 8

Issue in cloudkitty
by Jyoti Dahiwele 30 Aug '19

30 Aug '19

Dear Team, Plz help in following issue. While collecting gnocchi aggregates I ran into 400 response from gnocchi due to lack of metrics at that particular point of time. I am unable to fill the metrics with zero values. The cloudkitty rated_data_frames table in the database shows __NO_DATA__ . Here below are the logs *cloudkitty-processor.log* *2019-01-11 17:06:56.334 7207 WARNING cloudkitty.orchestrator [-] [5793054cd0fe4a018e959eb9081442a8] Error while collecting metric volume.size: {u'cause': u'Metrics not found', u'detail': [u'volume.size']} (HTTP 400). Retrying on next collection cycle.: BadRequest: {u'cause': u'Metrics not found', u'detail': [u'volume.size']} (HTTP 400)* *2019-01-11 17:07:00.356 7207 WARNING cloudkitty.orchestrator [-] [2eea218eea984dd68f1378ea21c64b83] Error while collecting metric volume.size: {u'cause': u'Metrics not found', u'detail': [u'volume.size']} (HTTP 400). Retrying on next collection cycle.: BadRequest: {u'cause': u'Metrics not found', u'detail': [u'volume.size']} (HTTP 400)* *gnocchi-api.log* *10.20.0.100 - - [11/Jan/2019:17:07:04 +0000] "POST /v1/aggregates?details=False&groupby=id&groupby=project_id&start=2019-01-01T00%3A00%3A00&stop=2019-01-01T01%3A00%3A00 HTTP/1.1" 400 280 "-" "cloudkitty-processor keystoneauth1/3.11.2 python-requests/2.21.0 CPython/2.7.15rc1"* *10.20.0.100 - - [11/Jan/2019:17:07:08 +0000] "POST /v1/aggregates?details=False&groupby=id&groupby=project_id&start=2019-01-01T00%3A00%3A00&stop=2019-01-01T01%3A00%3A00 HTTP/1.1" 400 280 "-" "cloudkitty-processor keystoneauth1/3.11.2 python-requests/2.21.0 CPython/2.7.15rc1"* *Also, the price while launching the instance is not getting updated on the fly.* *Below are the processor logs of cloudkitty:-* *2019-08-30 11:20:18.571 23130 ERROR oslo_messaging.rpc.server AttributeError: 'list' object has no attribute 'start'* 2019-08-30 11:20:18.571 23130 ERROR oslo_messaging.rpc.server 2019-08-30 11:20:18.887 23136 DEBUG cloudkitty.orchestrator [-] Received quote from RPC. quote /usr/lib/python2.7/site-packages/cloudkitty/orchestrator.py:11 1 2019-08-30 11:20:18.977 23136 DEBUG oslo_db.api [-] Loading backend 'sqlalchemy' from 'cloudkitty.rating.hash.db.sqlalchemy.api' _load_backend /usr/lib/pytho n2.7/site-packages/oslo_db/api.py:261 2019-08-30 11:20:19.131 23136 DEBUG oslo_db.api [-] Loading backend 'sqlalchemy' from 'cloudkitty.db.sqlalchemy.api' _load_backend /usr/lib/python2.7/site-pa ckages/oslo_db/api.py:261 2019-08-30 11:20:19.153 23136 DEBUG oslo_db.api [-] Loading backend 'sqlalchemy' from 'cloudkitty.rating.pyscripts.db.sqlalchemy.api' _load_backend /usr/lib/ python2.7/site-packages/oslo_db/api.py:261 2019-08-30 11:20:19.167 23136 ERROR oslo_messaging.rpc.server [-] Exception during message handling: AttributeError: 'list' object has no attribute 'start' 2019-08-30 11:20:19.167 23136 ERROR oslo_messaging.rpc.server Traceback (most recent call last):

1 0

[election][barbican][ptl] U Cycle Candidacy
by Douglas Mendizábal 30 Aug '19

30 Aug '19

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I would like to announce my candidacy to continue to serve as Barbican PTL for the U cycle. My goals for this next cycle is to continue to improve the usability of the client libraries, especially getting feature parity between python-barbicanclient and openstacksdk.key_manager to support the Image Encryption cross-project effort. Thank you, Douglas Mendizábal -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEwcapj5oGTj2zd3XogB6WFOq/OrcFAl1pJhAACgkQgB6WFOq/ OreypA/+JweQuiTuM4TgcmngHdFWBWZeL2VQ9a6OgyfxwSBXV7QP859wbmLsc6UP bOZkRCNNq2/GLkx6fvQ8/4Q7NzoB5ZL3OSAJVkbo3Gdm8/eXiq+FHiy6JqX+2EjD 3GT8FUHDxI22zxsFnn9ILUGkreyJ2vxYFlIDhhRVrpJu40NCm8cm2FmVuFDmWbgk 3T73+Sch2GAkSuiB/ntlHlvzCd2yFX+8dLjtjeyRHL+uhA9Kx8Y75FMKF4bzlFl0 7WLc9fcQl7TSu3HlW0wFrC+EIIe9SJTvJF2f0UyuKstJLP1DdYyGNW+Qdv1Kcdwv 71jt8ZhjyD7OZ+WQ3kaYFcF33i2sTSpKWHZNISf3uB3dw1UL+tsu9x9xlcy+hfu3 AExE6kCmXinVNYf5i99MxNBbiqrnXJd5jSfLehHPj6dopUED253hqEu2ugO65aBM Nv1gORQPuO6iPq6l6YtHFj453OxBwFAvtTmPAKbd3S2N1USlik3x393t6y7ykhta X+EyC+Tci0cwX3JV1qkDSJvC1oPb0F8ynykrT3HrkCaDSqQ5xrScmMbXrlyHiB3J E99xzTKePz+xp7wY7hTFrSWdjFRJBlhgEgPzkxNCqblVkDkx3CvSdMfs3K75h0Og t4tckF82J5j+LeXn2W8nk6ZHGkKaFlC2cSWjCk5YWjBhridhVGs= =pfrQ -----END PGP SIGNATURE-----

1 0

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

30 Aug '19

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

1 0

[ops][glance] How to remove images stuck in 'deleted'
by Massimo Sgaravatto 30 Aug '19

30 Aug '19

Hi I have a few old images that for some reasons are stuck in the deleted state, and I would like to remove them Since a simple "openstack image delete <id>" can't be used [*], is it safe to set images.deleted to '1' in the glance db and then remove the relevant file in the backend ? Or are there better/safer options ? I am now running OpenStack Rocky Thanks, Massimo [*] Failed to delete image with name or ID '70a784ec-b109-4d4a-8a63-7c58d8db866c': 400 Bad Request: Image status transition from deleted to deleted is not allowed (HTTP 400)

1 0

[loci] Non-candidacy for U cycle
by Chris Hoge 30 Aug '19

30 Aug '19

Thank you to the Loci team for having me serve as PTL. With the project seeing heavier usage in production, I feel it's important to hand over leadership to the developers who have more day-to-day usage. There are still lots of great enhancements that can be made to the project, and I'm excited to see what comes next. -Chris

2 1

[placement] update 19-34
by Chris Dent 30 Aug '19

30 Aug '19

HTML: https://anticdent.org/placement-update-19-34.html Welcome to placement update 19-34. Feature Freeze is the week of September 9th. We have features in progress in placement itself (consumer types) and osc-placement that would be great to land. # Most Important In addition to the features above, we really need to get started on tuning up the documentation so that `same_subtree` and friends can be used effectively. It is also time to start thinking about what features, if any, need to be pursued in Ussuri. If there are few, that ought to leave time and energy for getting the osc-placement plugin more up to date. And, there are plenty of stories (see below) that need attention. Ideally we'd end every cycle with zero stories, including removing ones that no longer make sense. # What's Changed * Tetsuro has picked up the baton for performance and refactoring work and found [some](https://review.opendev.org/677120) [improvements](https://review.opendev.org/677209) that have merged. There's additional work in progress (noted below). # Stories/Bugs (Numbers in () are the change since the last pupdate.) There are 25 (2) stories in [the placement group](https://storyboard.openstack.org/#!/project_group/placement). 0 (0) are [untagged](https://storyboard.openstack.org/#!/worklist/580). 5 (1) are [bugs](https://storyboard.openstack.org/#!/worklist/574). 4 (0) are [cleanups](https://storyboard.openstack.org/#!/worklist/575). 12 (1) are [rfes](https://storyboard.openstack.org/#!/worklist/594). 4 (0) are [docs](https://storyboard.openstack.org/#!/worklist/637). If you're interested in helping out with placement, those stories are good places to look. * Placement related nova [bugs not yet in progress](https://goo.gl/TgiPXb) on launchpad: 17 (-1). * Placement related nova [in progress bugs](https://goo.gl/vzGGDQ) on launchpad: 6 (2). # osc-placement osc-placement is currently behind by 12 microversions. * <https://review.opendev.org/666542> Add support for multiple member_of. There's been some useful discussion about how to achieve this, and a consensus has emerged on how to get the best results. * <https://review.opendev.org/640898> Adds a new `--amend` option which can update resource provider inventory without requiring the user to pass a full replacement for inventory and an `--aggregate` option to set inventory on all the providers in an aggregate. This has been broken up into three patches to help with review. This one is very close but needs review from more people than Matt. # Main Themes ## Consumer Types Adding a type to consumers will allow them to be grouped for various purposes, including quota accounting. * <https://review.opendev.org/#/q/topic:bp/support-consumer-types> A WIP, as microversion 1.37, has started. I picked this up yesterday and hope to have it finished next week, barring distractions. I figure having it in place for nova for Ussuri is a nice to have. ## Cleanup Cleanup is an overarching theme related to improving documentation, performance and the maintainability of the code. The changes we are making this cycle are fairly complex to use and are fairly complex to write, so it is good that we're going to have plenty of time to clean and clarify all these things. Performance related explorations continue: * <https://review.opendev.org/#/c/679385/> Refactor initialization of research context. This puts the code that might cause an exit earlier in the process so we can avoid useless work. One outcome of the performance work needs to be something like a _Deployment Considerations_ document to help people choose how to tweak their placement deployment to match their needs. The simple answer is use more web servers and more database servers, but that's often very wasteful. Discussions about [using a different JSON serializer](http://lists.openstack.org/pipermail/openstack-discuss/2019-Aug… terminated choosing not to use `orjson` because it presents some packaging and distribution issues that might be problematic. There's still an option to use one of the other alternatives, but that exploration has not started. # Other Placement Miscellaneous changes can be found in [the usual place](https://review.opendev.org/#/q/project:openstack/placement+status:op…. * <https://review.opendev.org/676982> Merge request log and request id middlewares is worth attention. It makes sure that _all_ log message from a single request use a global and local request id. There are two [os-traits changes](https://review.opendev.org/#/q/project:openstack/os-traits+status:… being discussed. And zero [os-resource-classes changes](https://review.opendev.org/#/q/project:openstack/os-resource-class…. # Other Service Users New discoveries are added to the end. Merged stuff is removed. Anything that has had no activity in 4 weeks has been removed. * <https://review.opendev.org/659233> Cyborg: Placement report * <https://review.opendev.org/662229> helm: add placement chart * <https://review.opendev.org/#/q/topic:bp/virtual-persistent-memory> libvirt: report pmem namespaces resources by provider tree * <https://review.opendev.org/660852> Nova: Remove PlacementAPIConnectFailure handling from AggregateAPI * <https://review.opendev.org/670112> Nova: WIP: Add a placement audit command * <https://review.opendev.org/671793> Nova: libvirt: Start reporting PCPU inventory to placement A part of <https://review.opendev.org/#/q/topic:bp/cpu-resources> * <https://review.opendev.org/#/q/topic:bp/support-move-ops-with-qos-ports> Nova: support move ops with qos ports * <https://review.opendev.org/666202> Blazar: Create placement client for each request * <https://review.opendev.org/667952> nova: Support filtering of hosts by forbidden aggregates * <https://review.opendev.org/669079> blazar: Send global_request_id for tracing calls * <https://review.opendev.org/670696> tempest: Add placement API methods for testing routed provider nets * <https://review.opendev.org/672678> openstack-helm: Build placement in OSH-images * <https://review.opendev.org/674129> Correct global_request_id sent to Placement * <https://review.opendev.org/#/q/topic:bp/cross-cell-resize> Nova: cross cell resize * <https://review.opendev.org/674524> Nova: Scheduler translate properties to traits * <https://review.opendev.org/623558> Nova: single pass instance info fetch in host manager * <https://review.opendev.org/674708> Zun: [WIP] Claim container allocation in placement * <https://review.opendev.org/#/q/topic:bp/provider-config-file> Nova: using provider config file for custom resource providers # End ☃ -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent

1 0

[kolla] PTL candidacy
by Mark Goddard 30 Aug '19

30 Aug '19

Hi, I'd like to nominate myself to serve as the Kolla PTL for the Ussuri cycle. I have been PTL for the Train cycle, and would like the opportunity to continue to lead the team. In my Train nomination [1] I proposed a few things, including: * help those on the periphery of the project get more involved * try a new meeting time * hold a virtual PTG * adopt some of ironic's planning and tracking processes * continue improving CI testing During the cycle we have helped a number of new contributors get involved, and have taken on a new core contributor who is already one of the most active members. We polled for a new meeting time but found we were already optimal. The virtual PTG helped us to prioritise our efforts, and I expect we'll hold another this cycle. We now use a whiteboard [2] similar to ironic's, and went through a process of prioritisation of features for this cycle which we continue to use to guide our efforts. Finally, CI test coverage continues to improve - notably the new multinode upgrade job caught a pretty nasty MariaDB upgrade bug that we might not otherwise have spotted before release. If elected this cycle I'd like to continue to reflect on our processes, and encourage increasing test coverage for further stability. We recently added Kayobe [3] as a project deliverable, and I intend to ensure that these two overlapping communities come together effectively to make the most effective use of our combined resources. Thanks for reading, Mark Goddard (mgoddard) [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003617.ht… [2] https://etherpad.openstack.org/p/KollaWhiteBoard [3] https://docs.openstack.org/kayobe

1 0

Re: [User-committee] UC candidacy
by Ian Y. Choi 30 Aug '19

30 Aug '19

Hello, As an UC election official, I confirm that the candidate is eligible for UC election within nomination period. With many thanks, /Ian On Friday, August 30, 2019, Jaesuk Ahn <bluejay.ahn(a)gmail.com> wrote: > > Hi, > > This is Jaesuk Ahn from OpenStack Korea User Group. > I would like announce my candidacy to serve as the User Committee. > > As a strong advocate of OpenStack community, I have been involved in > OpenStack > from 2010, founded OpenStack Korea Community in 2011, and been a > coordinator of > the Korea community since then. I have devoted myself to build an open and > healthy local community, in addition, I have always been trying to be a > good > arbitrator between local and global community to embrace a diversity > together. > > Here are articles about various events that I have been one of main > organizers > and program chair of the events [1], [2], [3]. Please see the presentation > [4] > I did with two other community leaders on how we have built community in > Korea. > > From a technical point of view, I have been leading OpenStack dev team > since > 2010. I have switched companies during those years but was able to focus > on one > thing: deployment automation & lifecycle management of OpenStack. > OpenStack-Helm, > and Airship are the most recent efforts on this line of work in my career. > Here is my linkedin profile stating my work during the last 10 years [5]. > > I am currently leading a development team to work on > openstack-on-kubernetes in > SK Telecom. I have made an architectural decision to leverage kubernetes > for > OpenStack lifecycle management in 2016, that this decision eventually led > us to > collaborate with AT&T team. As a result of community collaboration with > AT&T, > I am happy to see both OpenStack-Helm project and Airship project active > in > the community. > > if I am chosen by the community, I am fully committed to hear various > voices > from many community members, especially from community members who has > difficulties in language and time barrier. I will do my best to > collaborate with others to > make OpenStack community more diverse and active. > > [1] https://superuser.openstack.org/articles/building-new- > foundations-openinfra-days-korea/ > [2] https://superuser.openstack.org/articles/openstack-korea-days-2017/ > [3] https://superuser.openstack.org/articles/openstack-day-in- > korea-2015-to-infinity-and-beyond/ > [4] https://www.slideshare.net/openstack_kr/boston-summit- > what-makes-it-possible-to-run-openstack-community-for-three-generations > [5] https://www.linkedin.com/in/jsahn/ > > > Thanks > > > *Jaesuk Ahn*, Ph.D. > Cloud Labs, SK Telecom >

1 0

[Packaging-Rpm] PTL Candidacy
by Javier Pena 30 Aug '19

30 Aug '19

Hello everyone, I would like to announce my candidacy to be the PTL for the Packaging Rpm project during the Ussuri development cycle. For the Ussuri cycle, my focus would be on: * Making sure all packages have been migrated to Python 3, so we can finally get rid of Python 2. * Transition the RDO CI and packages to CentOS 8, once it is released, and remove the now obsolete Fedora-based CI. That, of course, would be in addition to our common goals: expanding our contributor base, improving collaboration between RPM distributions, and keeping a high quality set of packages. Thanks, Javier

1 0

[cloudkitty] PTL candidacy
by Luka Peschke 30 Aug '19

30 Aug '19

Hello contributors, user, operators, I would like to submit my candidacy as CloudKitty's PTL for the Ussuri cycle. I've been contributing to the project for several releases and I've been the PTL for the last two releases. I'm very happy with the T cycle, as the goals we fixed ourselves have been achieved: the planned features have been implemented, some features that were planned for U might make it into T, and most importantly, our community has grown. If you want to have me as the project's PTL for the Ussuri cycle, I'd like to keep focusing on the points we addressed during the last few cycles: * Help CloudKitty's community to grow. This is a constant effort, and it is starting to pay off: people are gaining interest in CloudKitty, more and more questions and suggestions are being asked/made on IRC, and some external contributors are proposing patches. That's very rewarding for our small community, and we intent to keep it going! * Improving the documentation: A lot has been done during the last cycles, but with the growth of the v2 API, we need to keep putting effort into this; more specifically into tutorials, guides and into the developer documentation I'd also like to finally work on the new rating module. This has been planned and asked for too long, and we should finally work on this together. I will use this opportunity to thank everybody who's been involved in CloudKitty: developers, reviewers, users... The project lives thanks to you! Thank you for your attention, Luka Peschke

1 0

[Glance] PTL Candidacy
by Abhishek Kekane 30 Aug '19

30 Aug '19

Hello everyone, I would like to announce my candidacy for the role of PTL of Glance for the Ussuri cycle. I have been working closely with several previous PTL's like Erno and Brian and I am hoping to contribute back to the community as a PTL while following their excellent example. I've been working primarily with Glance since Icehouse and do work full-time on Glance upstream. During that time I've served community in release liaison role, as Glance core reviewer and part of Glance bugs team. I have represented Glance in interactions with various teams, such as the cross-projects interactions, API workgroup, documentation and OSIC. Even though I work in GMT+05:30 time zone, I am flexible enough to catchup with peoples who were in US or European time-zone. I have seen lots of highs and lows of the Glance and am proud that we have not only survived but also becoming strong. During the Train cycle we have managed to release glance-store version 1.0 which supports multiple stores configuration. This is how I want to focus for Ussuri cycle 1. Multiple stores support As glance-store v1.0 is out with multiple stores configuration support, I want to make sure Glance is able maintain it's backward compatibility and doesn't break any cross-project workflow. Most of the work is already done during Train cycle but in case if any bug occurs then it will be solved on the high priority. Multiple stores will also play role in Edge computing, so if any enhancement is required then it will be handled on top priority. 2. Glance cluster awareness With Interoperable Image Import and new edge usecases, Glance cluster awareness [0] is most important feature. Even the basic implementation has started during Train cycle, we want to use this in caching operations which will be carried out during this development cycle. 3. Bridging gap between Glance and Horizon Glance has now added new features such as new import workflow, import plugins, hidden images etc. Horizon is yet to implement these in the dashboards. I am going to put some efforts in communication with horizon team and help them to understand/implement/bridge this gap. 4. Catching up with tempest Similar to horizon, Glance needs to have tempest upto-date with new image import workflow, hidden images, multiples stores scenarios. I would like to catchup with tempest team and extend a hand to bridge this gap. 5. Community priorities Whatever community goals put forward by TC, as a PTL of Glance project will want to adopt these as a priority for Ussuri cycle. 6. Other As we are very short team at this moment, I would like to put some efforts in attracting some contributors, help them to understand how Glance functions and encourage them to contribute for Glance. Looking at past how Erno and Brian has steadied the ship, I know its a big task and with their help I will do my best not to fail the expectations. Thank you for consideration, Abhishek Kekane [0] https://review.opendev.org/#/c/664956/2/specs/train/approved/glance/cluster…

1 0

[all][election][TC] Candidacy for TC
by Kendall Nelson 30 Aug '19

30 Aug '19

Hello Everyone :) I am declaring my candidacy for the TC election. Roles like PTL and TC member are incredibly important when it comes to enabling others’ success and removing roadblocks that stand between contributors (new or established) and the work they want to do. Much of the work I have done over the years has had this focus, and as an elected member of the TC I think I could have an even larger impact. A little background on me: I have been working on OpenStack since 2015 (Liberty release). I started with getting involved organizing and mentoring in the Women of OpenStack’s mentoring programs and developing Cinder before branching out to os-brick and on to other roles. Since then, I have been involved in many different projects and efforts focused on supporting the larger community. Highlights: - Onboarded over 300 global contributors as instructor at OpenStack Upstream Institute (OUI) building our contributor community in places like Brazil, Korea, and Vietnam[1] - Developed the curriculum of OUI, including the Contributor Guide[2]. - Evolved OpenStack’s various mentoring programs[3] and actively participated in them, including our community’s involvement in the Outreachy Program[4]. - Established the First Contact SIG[5]. - Coordinated the community’s ongoing migration to StoryBoard from Launchpad - Presided over 5 releases of (Pike-Train) technical elections (both PTL and TC) as an election official - Served on the Release Management, Cinder, & Infrastructure (StoryBoard) teams - Helped organize Forums, PTGs, and other in-person gatherings - Collaborated with the k8s community to improve both our community’s various onboarding programs My experience teaching Upstream Institute and running the First Contact SIG has helped me build skills that will be beneficial as a TC member, such as making connections between new contributors and existing projects or efforts. This ability to make connections and start conversations will support our community’s cross project efforts as they continue to be a challenge that I will help the TC overcome. My previous work has afforded me the opportunity to interact with almost every OpenStack project and understand how they operate differently from one another. Each project has its own culture; understanding that and how to engage with each of them is incredibly important for the Technical Committee to achieve selected community goals and other cross project efforts. As a member of the TC, I will seek to lower the barrier to entry to roles like contributor or even PTL. There is a lot of duplicate and stale information for setting up the accounts and tools needed to get started which should be cleaned up. Individual project contributor documentation[6][7] doesn’t exist for all the projects currently and would be valuable. Individual project PTL guides (similar to the Release Management process doc[8]) would also benefit our community as it would smooth the transition from one PTL to another and minimize the loss of tribal knowledge, especially when these transitions happen in the middle of a cycle. I’ve proposed this contributor documentation focus as a community goal for the U release[9]. Anything we can do to make a cohesive path for new community members to work their way to roles like PTL will ensure the health and success of our future. I love this community and all the awesome people in it, serving on the TC would be a great experience and an honor. Thank you, Kendall Review history: https://review.opendev.org/#/q/reviewer:16708,n,z Commit history: https://review.openstack.org/#/q/owner:16708,n,z Foundation Profile: https://www.openstack.org/community/members/profile/35859/ Freenode: diablo_rojo [1] https://docs.openstack.org/upstream-training/ [2] https://docs.openstack.org/contributors/ [3] https://wiki.openstack.org/wiki/Mentoring [4] https://www.outreachy.org/ [5] https://wiki.openstack.org/wiki/First_Contact_SIG [6] https://docs.openstack.org/swift/latest/development_guidelines.html [7] https://docs.openstack.org/nova/latest/contributor/index.html [8] https://releases.openstack.org/reference/process.html [9] https://etherpad.openstack.org/p/PVG-u-series-goals

2 1

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

30 Aug '19

Dear Neutrinos, It turns out that this week we still have 3 out of 5 members of the drivers team off on vacation, so we won't have quorum for the meeting again. As a consequence, I am cancelling this week once more. We will resume on September 9th at the usual time. Best regards

1 0