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

Post OpenDev Repo Migration Issues
by Clark Boylan 21 Apr '19

21 Apr '19

Hello, There are two quick things we want to point out that we've noticed after the OpenDev Gerrit manuevers. First, any commit Depends-On footers for unmerged changes will need to use https://review.opendev.org urls instead of https://review.openstack.org urls. This is due to a limitation in Zuul and how it sees the Gerrit server. Any Depends-On footers that use https://review.openstack.org are currently non-functional and they will not enforce the dependency relationship. Second, while we have fairly robust http(s) redirects in place for old urls (including those from cgit to gitea) any ssh repo urls will need to be updated to use the new canonical paths if a repo has moved. We are unable to redirect incoming ssh requests against Gerrit. If you need to know what the canonical path is go to the corresponding https repo url and the resulting destination is the canonical location. Again thank you for your patience, Clark

3 3

[placement][nova][ptg] Shared resource providers for shared disk on compute hosts
by Chris Dent 21 Apr '19

21 Apr '19

This topic is from the cross project etherpad [1] There's a spec in progress for this: https://review.openstack.org/#/c/650188/ It does a pretty good job of explaining some of the corner cases. We need to make sure we have a good awareness of all the corners because when we try to do (or even think about) this feature we discover a problem that derails the work. Which is unfortunate because supporting shared disk is one of the principles on which placement was sold. All the necessary functionality is already there in placement, so making it work is mostly on the nova side, a lot of it in nova-compute. Much of the challenge is associated with dealing with move operations. A question I posed on the spec is whether it is possible to make this happen without having to rely on additional config. It seems like something where it would be super nice (but perhaps not possible) for a virtdriver to be able to turn on and manage itself. So the discussion surrounding this topic is perhaps around: * teasing out the dark corners as much as possible so we don't stumble again * nailing the issues with moves * exploring the options for making it as hands-free as possible [1] https://etherpad.openstack.org/p/ptg-train-xproj-nova-placement -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

2 1

[dev] Queries regarding migration through Openstack
by Priyanka Sangtani 21 Apr '19

21 Apr '19

Hi All, I'm currently working on a project which requires me to understand the live migration and cold migration process in Openstack. I have the following questions: 1. In case of live migration with shared storage, how is the current downtime set through update_downtime used? Like when does it know that it needs to pause the VM on the source and perform the stop and copy phase? It would be great if you could point me to the code base where this is happening. Is this handled by QEMU? 2. In case of cold migrate, how does it select the destination host? As per the code, I saw that it generates a sorted list of hosts based on filtering and weighing but then we also perform randomization. I'm confused as to how this works. Thank you so much for your time. Regards, Priyanka

1 0

[nova] - Stack VMs based on RAM
by Georgios Dimitrakakis 21 Apr '19

21 Apr '19

All, in the past I used to stack VMs based on RAM on hosts by putting the following settings in my nova.conf file: ->ram_weight_multiplier=-1.0 ->available_filters=nova.scheduler.filters.all_filters ->enabled_filters=RetryFilter,AvailabilityZoneFilter,CoreFilter,RamFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter I have now a Rocky installation and although I have set the above on my controller node and restarted corresponding services the result when spawning two VMs (one after another) is still to be distributed on two different hosts. Seems that the something is missing in order to override the default behavior. Any suggestions please? Best regards, G.

4 26

[tc] project-update exception for 654057
by Mohammed Naser 21 Apr '19

21 Apr '19

Hi everyone: As chair, I'm making an exception to the usual timeline for the project-update housekeeping rules for change #654057 based on the following reasons: - This has no governing change, the only change is pointing to the correct deliverable repository as part of this. - The reasonable possible objection is the prefix/rename of a repository, however, this is already done. If there is any concerns about any specific renames, we can work with infra. to rename them and update the projects.yaml afterwards. - This helps unblock the (hard working) infrastructure team at cleaning up their work. It is impacting our openstack/openstack submodules repo. If anyone has any objects, you're free to propose a full (or partial) revert with your concerns. Have a good weekend! 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

[qa][zun][kuryr][k8s]
by Hongbin Lu 20 Apr '19

20 Apr '19

Hi all, Right now, we have a devstack plugin [1] to install container engine (i.e. docker, cri-o). The plugin is currently used by Zun and Kuryr and under the governance of QA team. I am working on a patch [2] to enable k8s installation via devstack. Zun needs this feature to setup the CI for the virtual kubelet provider, and I heard Kuryr also interest to leverage it. The original idea is to incorporate k8s installation into devstack-plugin-container, so that we can avoid the overhead to bootstrap and maintain a separated plugin. However, the feedback I received so far gave preference to a separated plugin for k8s, so I sent out this email to collect more opinions. Do you prefer a dedicated devstack plugin for k8s, or is fine to reuse the existing container plugin for this purpose? [1] https://github.com/openstack/devstack-plugin-container [2] https://review.openstack.org/#/c/646018/ Best regards, Hongbin

3 3

https://review.openstack.org is down?
by Arkady.Kanevsky＠dell.com 20 Apr '19

20 Apr '19

5 5

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

20 Apr '19

# Keystone Team Update - Week of 15 April 2019 ## News This week has been mostly about Forum and PTG preparation. Please review the PTG agenda[1] and come prepared to discuss the proposed topics. According to the team dinner poll[2] it looks like Wednesday is the best day for us to go out as a team, so I will find somewhere to make a reservation for the ~8 of us. [1] https://etherpad.openstack.org/p/keystone-train-ptg [2] https://framadate.org/BHNNU9S3f9N3lasH ## Open Specs Train specs: https://bit.ly/2uZ2tRl Ongoing specs: https://bit.ly/2OyDLTh I would like to start prioritizing and committing to these specs soon after the PTG so please review the proposals and/or prepare and update your own proposals for this cycle. If a spec is proposed under ongoing/ but it should be completed this cycle, please repropose it under train/. ## Recently Merged Changes Search query: https://bit.ly/2pquOwT Gerrit is under maintenance right now so I don't have stats at the moment ;) ## Changes that need Attention Search query: https://bit.ly/2tymTje Same here. ## Bugs This week we opened 2 new bugs and closed none. At first glance the two new bugs appear to be issues with the new Stein packages on Ubuntu. Bug #1825111 (keystone:Undecided) opened by Robert Holling https://bugs.launchpad.net/keystone/+bug/1825111 Bug #1825214 (keystone:Undecided) opened by Joseph Beale https://bugs.launchpad.net/keystone/+bug/1825214 ## Milestone Outlook https://releases.openstack.org/train/schedule.html ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter

1 0

[stackalytics] Moving stackalytics configuration file to github repo
by Sergey Nikitin 20 Apr '19

20 Apr '19

Hello everyone, Every day Stackalytics team works on new features. One of these features is a statistics collecting for non OpenStack projects. For example Kubernetes [1]. Stackalytics project has configuration file (default_data.json), which contains a lot of data, including user properties. Such as name, launchpad ID, github ID, email and companies. It's a usual situation when a contributor change his/her email or find a better job in new company. To do not loose stats which were pinned with old email or to point that he/she now work in new company contributor must add/modify his/her record in default_data.json config file. This config file was in `etc` directory in stackalytics repo [2]. But we moved this file to new github repository [3]. It was made to do not force non OpenStack contributors use OpenStack Gerrit to update their stackalytics profiles. >From this moment if you want to update your stackalytics profile you must create a pull request to the new github repo [3]. The new data will be applied within 12 hours after pull request merge. All current patches with user data changes from stackalytics gerrit [4] are still valid and will be applied and moved to [3] after approve. So do not worry about them. More information about user data updating you can find in Stackalytics Wiki page [5]. If you have any questions we will be glad to answer. Stackalytics team. [1] https://www.stackalytics.com/cncf?project_type=kubernetes [2] https://github.com/openstack/stackalytics/blob/master/etc/default_data.json [3] https://github.com/stackalytics/default_data [4] https://review.openstack.org/#/q/project:openstack/stackalytics+status:open [5] https://wiki.openstack.org/wiki/Stackalytics#Company_affiliation -- Best Regards, Sergey Nikitin

3 2

[qa] [ptg] QA Stein Retrospective Etherpad
by Ghanshyam Mann 20 Apr '19

20 Apr '19

Hi All, I have started an etherpad for Stein cycle QA retrospective - https://etherpad.openstack.org/p/qa-stein-retrospective This will be discussed in PTG on Thursday 9.00-09.30 AM, so please add your feedback/comment before that. -gmann

1 0