February 2020 - openstack-discuss

[tripleo] RDO image server migration
by Wesley Hayutin 15 Feb '20

15 Feb '20

FYI... Possible interruption on 3rd party ovb jobs. ---------- Forwarded message --------- From: Daniel Pawlik <dpawlik(a)redhat.com> Date: Fri, Feb 14, 2020 at 8:47 AM Subject: [rdo-dev] [rdo-users] [infra] RDO image server migration To: <dev(a)lists.rdoproject.org> Hello, We are going to migrate images.rdoproject.org to our new cloud provider, starting on February 17th at 10 AM UTC. Migration should be transparent to the end user (scripts and job definition are using new image server). However, you have to keep in mind the unforeseen events that may occur. Write access to the old server will be disabled and until DNS propagation is not done, you could have read-only access. If you have any doubts or concerns, please do not hesitate to contact: - Daniel Pawlik <dpawlik(a)redhat.com> - Javier Pena <jpena(a)redhat.com> Regards, Daniel _______________________________________________ dev mailing list dev(a)lists.rdoproject.org http://lists.rdoproject.org/mailman/listinfo/dev To unsubscribe: dev-unsubscribe(a)lists.rdoproject.org

1 0

[tripleo] RDO image server migration
by Daniel Pawlik 15 Feb '20

15 Feb '20

Hello, We are going to migrate images.rdoproject.org to our new cloud provider, starting on February 17th at 10 AM UTC. Migration should be transparent to the end user (scripts and job definition are using new image server). However, you have to keep in mind the unforeseen events that may occur. Write access to the old server will be disabled and until DNS propagation is not done, you could have read-only access. If you have any doubts or concerns, please do not hesitate to contact: - Daniel Pawlik <dpawlik(a)redhat.com> - Javier Pena <jpena(a)redhat.com> Regards, Daniel

1 0

[security] Vancouver PTG Planning - Security SIG
by Gage Hugo 15 Feb '20

15 Feb '20

Hello, It's about that time again, to start planning for the next PTG. To help gauge interest and track any topics that anyone is interested in, I've created an etherpad: https://etherpad.openstack.org/p/yvr-ptg-security-sig Please add your name if you plan to attend and any topic ideas that you are interested in. Thanks!

1 0

[release] Release countdown for week R-12, February 17-21
by Sean McGinnis 14 Feb '20

14 Feb '20

Development Focus ----------------- We are now past the Ussuri-2 milestone, and entering the last development phase of the cycle. Teams should be focused on implementing planned work for the cycle. Now is a good time to review those plans and reprioritize anything if needed based on the what progress has been made and what looks realistic to complete in the next few weeks. General Information ------------------- Looking ahead to the end of the release cycle, please be aware of the feature freeze dates. Those vary depending on deliverable type: * General libraries (except client libraries) need to have their last feature release before Non-client library freeze (April 2). Their stable branches are cut early. * Client libraries (think python-*client libraries) need to have their last feature release before Client library freeze (April 9) * Deliverables following a cycle-with-rc model (that would be most services) observe a Feature freeze on that same date, April 9. Any feature addition beyond that date should be discussed on the mailing-list and get PTL approval. After feature freeze, cycle-with-rc deliverables need to produce a first release candidate (and a stable branch) before RC1 deadline (April 23) * Deliverables following cycle-with-intermediary model can release as necessary, but in all cases before Final RC deadline (May 7) Upcoming Deadlines & Dates -------------------------- Non-client library freeze: April 2 (R-6 week) Client library freeze: April 9 (R-5 week) Ussuri-3 milestone: April 9 (R-5 week) OpenDev+PTG Vancouver: June 8-11

1 0

[tripleo] TripleO CI Summary: Sprint 42
by Rafael Folco 14 Feb '20

14 Feb '20

Greetings, The TripleO CI team has just completed Sprint 42 / Unified Sprint 21 (Jan 23 thru Feb 12). The following is a summary of completed work during this sprint cycle: - Started refactoring Promoter code into a modular implementation w/ testing oriented design and accommodating the changes for the new promotion pipeline. - Completed building CentOS8 containers with required repositories. This is still an unofficial build as some of the repositories (like Ceph) are not from RDO/TripleO. - Refined the component pipeline design [3] w/ the new aggregated hash containing all promoted components. Continued to implement the downstream version of the component pipeline. - Translated get-hash into a separated role in ci-config repo, de-attaching from promote-hash role in config. Added support for the new component and integration jobs. - Made improvements to the collect-logs plugin as part of the shared goals for the combined CI team. - Built CI workflow to follow successful manual standalone deployment using an IPA server. The TLS CI job is not running yet and still needs to be activated. Ruck/Rover Notes: - There were at least four upstream gate outages during this sprint. All have been resolved at this time. Notes are here [4]. The planned work for the next sprint [1] extends the work started in the previous sprint and focuses on the following: - Build the CentOS8 pipeline starting with the base jobs to build containers and promote hashes. - Replicate the component jobs to all available components and build the new promotion pipeline in CentOS8. - Continue the promoter code refactoring and converting the legacy code in a modular implementation that can be tested more efficiently. - Continue the collect-logs effort to make it a shared tool used by multiple teams. - Collaborate with the RDO team in migrating 3rd party CI to vexxhost. The Ruck and Rover for this sprint are Wesley Hayutin (weshay) and Marios Andreou (marios). Please direct questions or queries to them regarding CI status or issues in #tripleo, ideally to whomever has the ‘|ruck’ suffix on their nick. Ruck/rover notes to be tracked in etherpad [2]. Thanks, rfolco [1] https://tree.taiga.io/project/tripleo-ci-board/taskboard/unified-sprint-22 [2] https://etherpad.openstack.org/p/ruckroversprint22 [3] https://hackmd.io/5uYRmLaOTI2raTbHWsaiSQ [4] https://etherpad.openstack.org/p/ruckroversprint21

1 0

[Outreachy] Call for mentors, projects by Feb 25
by Samuel de Medeiros Queiroz 14 Feb '20

14 Feb '20

Hi all, TL;DR OpenStack is participating of Outreachy! Mentors, please submit project proposals by Feb 25. More info: https://www.outreachy.org/communities/cfp/openstack/ Outreachy's goal is to support people from groups underrepresented in the technology industry. The upcoming round runs from May to August 2020. Now that we are confirmed as a participating community, we welcome experienced community contributors to help out as mentors, who need to submit project proposals. Therefore, if you have an interesting project that meets the criteria, please submit it as soon as possible. You can find more information about the program, project criteria, mentor requirements, and submit your project at the Call for mentors page <https://www.outreachy.org/communities/cfp/openstack/> [1]. I have participated twice of Outreachy as a mentor and I can tell you it was a great opportunity to get someone onboard the community and, of course, to learn from them. Besides getting work done (which is great), we happen to make our community more diverse, while helping with its continuity. Please let me know if you have any questions. Thanks, Samuel [1] https://www.outreachy.org/communities/cfp/openstack/

1 0

[keystone] Keystone Team Update - Week of 10 February 2020
by Vishakha Agarwal 14 Feb '20

14 Feb '20

# Keystone Team Update - Week of 10 February 2020 ## News ### YVR PTG Keystone People can write down the topics in etherpad [1] to have a brief discussion with the team. [1] https://etherpad.openstack.org/p/yvr-ptg-keystone ### User Support and Bug Duty Every week the duty is being rotated between the members. The person-in-charge for bug duty for current and upcoming week can be seen on the etherpad [2] [2] https://etherpad.openstack.org/p/keystone-l1-duty ## Open Specs Ussuri specs: https://bit.ly/2XDdpkU Ongoing specs: https://bit.ly/2OyDLTh ## Recently Merged Changes Search query: https://bit.ly/2pquOwT We merged 10 changes this week. ## Changes that need Attention Search query: https://bit.ly/2tymTje There are 21 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. ### Priority Reviews * Ussuri Roadmap Stories - Groups in keystone SAML assertion https://tree.taiga.io/project/keystone-ussuri-roadmap/us/33 https://review.opendev.org/#/c/588211/ Add openstack_groups to assertion - Add support for modifying resource options to CLI tool https://tree.taiga.io/project/keystone-ussuri-roadmap/us/53 https://review.opendev.org/#/c/697444/ Adding options to user cli ## Bugs This week we opened 3 new bugs and closed 2. Bugs opened (3) Bug #1862802 (keystone:Wishlist): Avoid the default domain usage when the Domain is not specified in the project creation - Opened by Raildo Mascena de Sousa Filho https://bugs.launchpad.net/keystone/+bug/1862802 Bug #1862606 (keystone:Undecided): LDAP support broken if UTF8 characters in DN (python2) - Opened by Rafal Ramocki https://bugs.launchpad.net/keystone/+bug/1862606 Bug #1863098 (keystone:Undecided): Install and configure in keystone - Opened by Assassins! https://bugs.launchpad.net/keystone/+bug/1863098 Bugs closed (2) Bug #1808305 (python-keystoneclient:Won't Fix) https://bugs.launchpad.net/python-keystoneclient/+bug/1808305 Bug #1823258 (keystone:Undecided): RFE: Immutable Resources - Fixed by Colleen Murphy https://bugs.launchpad.net/keystone/+bug/1823258 ## Milestone Outlook https://releases.openstack.org/ussuri/schedule.html This week marks the milestone 2 spec freeze. Feature proposal freeze is in week of March 9. This means code implementing approved specs needs to be in a reviewable, non-WIP state. ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Re: RHOSP-like installation
by Amy Marrich 14 Feb '20

14 Feb '20

Adding the discuss list back in On Thu, Feb 13, 2020 at 5:16 PM Amy Marrich <amy(a)demarco.com> wrote: > Volodymyr, > > I'm sure someone from the TripleO team will pipe in, but TripleO is closer > to RHOSP then RDO. When I was playing with it in the past I found Keith > Tenzer's blogs helpful. There might be more recent ones then this but > here's a link to one: > > > https://keithtenzer.com/2015/10/14/howto-openstack-deployment-using-tripleo… > > Thanks, > > Amy Marrich (spotz) > > On Thu, Feb 13, 2020 at 5:05 PM Volodymyr Litovka <doka.ua(a)gmx.com> wrote: > >> Dear colleagues, >> >> while having a good experience with Openstack on Ubuntu, we're facing a >> plenty of questions re RHOSP installation. >> >> The primary requirement for our team re RHOSP is to get a knowledge on >> RHOSP - how to install it and maintain. As far as I understand, RDO is >> the closest way to reach this target but which kind of installation it's >> better to use? - >> * plain RDO installation as described in generic Openstack guide at >> https://docs.openstack.org/install-guide/index.html (specifics in >> RHEL/CentOS sections) >> * or TripleO installation as described in http://tripleo.org/install/ >> * or, may be, it is possible to use RHOSP in kind of trial mode to get >> enough knowledge on this platform? >> >> Our lab consists of four servers (64G RAM, 16 cores@2GHz) which we're >> going to use in "ultraconverged" mode - as both controller and agent >> (compute/network/storage) nodes (controllers, though, can be in >> virsh-controlled VMs). In case of TripleO scenario, 4th server can be >> used for undercloud role. This installation is intended not for >> production use, but rather for learning purposes, so no special >> requirements for productivity. The only special requirement - to be >> functionally as much as close to canonical RHOSP platform. >> >> I will highly appreciate your suggestions on this issue. >> >> Thank you. >> >> -- >> Volodymyr Litovka >> "Vision without Execution is Hallucination." -- Thomas Edison >> >> >>

2 1

[all][PTL][tc] U Community Goal: Project PTL & Contrib Docs Update #2
by Kendall Nelson 14 Feb '20

14 Feb '20

Hello! First off I want to say thank you to the 4 projects that have already gotten started/completed the goal! Good work Glance, Neutron, Searchlight, and Watcher :) For the rest of the projects, thankfully we have more time to work on this goal than for the dropping py2 goal given that its documentation we aren't restricted to it being completed by feature freeze. That said, the sooner the better :) One thing I did want to draw attention to was the discussion around adding an include for CONTRIBUTING.rst to doc/source/contributor/contributing.rst[4] and the patch I have to add it to the template[5]. I also pushed a patch to clarify doc/source/contributor/contributing.rst vs CONTRIBUTING.rst -Kendall (diablo_rojo) [1] Goal: https://governance.openstack.org/tc/goals/selected/ussuri/project-ptl-and-c… [2] Docs Template: https://opendev.org/openstack/cookiecutter/src/branch/master/%7b%7bcookiecu… [3] Tracking: https://storyboard.openstack.org/#!/story/2007236 [4] TC Discussion: http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2020… [5] Patch to add include: https://review.opendev.org/#/c/707735/ [6] contributing.rst vs CONTRIBUTING.rst clarification patch: https://review.opendev.org/#/c/707736/

1 0

[tripleo] CI is RED py27 related
by Wesley Hayutin 14 Feb '20

14 Feb '20

Greetings, Most of the jobs went RED a few minutes ago. Again it's related to python27. Nothing is going to pass CI until this is fixed. See: https://etherpad.openstack.org/p/ruckroversprint21 We'll update the list when we have the required patches in. Thanks

2 5

[release] Release countdown for week R-13, February 10-14
by Sean McGinnis 14 Feb '20

14 Feb '20

Development Focus ----------------- The Ussuri-2 milestone is next week, on February 13! Ussuri-related specs should now be finalized so that teams can move to implementation ASAP. Some teams observe specific deadlines on the second milestone (mostly spec freezes): please refer to https://releases.openstack.org/ussuri/schedule.html for details. General Information ------------------- Libraries need to be released at least once per milestone period. Next week, the release team will propose releases for any library that has not been otherwise released since milestone 1. PTL's and release liaisons, please watch for these and give a +1 to acknowledge them. If there is some reason to hold off on a release, let us know that as well. A +1 would be appreciated, but if we do not hear anything at all by the end of the week, we will assume things are OK to proceed. Remember that non-library deliverables that follow the cycle-with-intermediary release model should have an intermediary release before milestone-2. Those who haven't will be proposed to switch to the cycle-with-rc model, which is more suited to deliverables that are released only once per cycle. Next week is also the deadline to freeze the contents of the final release. All new 'Ussuri' deliverables need to have a deliverable file (https://opendev.org/openstack/releases/src/branch/master/deliverables/ussuri ) and need to have done a release by milestone-2. The following new deliverables have not had a release yet, and will not be included in Ussuri unless a release is requested for them in the coming week: - adjutant, adjutant-ui, python-adjutantclient (Adjutant) - barbican-ui (Barbican) - js-openstack-lib (OpenStackSDK) - ovn-octavia-provider (Neutron) - sushy-cli (Ironic) - tripleo-operator-ansible (TripleO) Changes proposing those deliverables for inclusion in Ussuri have been posted, please update them with an actual release request before the milestone-2 deadline if you plan on including that deliverable in Ussuri, or -1 if you need one more cycle to be ready. Upcoming Deadlines & Dates -------------------------- Ussuri-2 Milestone: February 13 (R-13 week)

1 1

[nova] API updates week 20-7
by Ghanshyam Mann 14 Feb '20

14 Feb '20

Hello Everyone, Please find the Nova API updates of this week. Please add if I missed any BPs/API related work. API Related BP : ============ COMPLETED: 1. Add image-precache-support spec: - https://blueprints.launchpad.net/nova/+spec/image-precache-support Code Ready for Review: ------------------------------ 1. Nova API policy improvement - Topic: https://review.opendev.org/#/q/topic:bp/policy-defaults-refresh+(status:ope… - Weekly Progress: API till D is covered and ready for review. Fixed 5 bugs in policy while working on new defaults. - Review guide over ML - http://lists.openstack.org/pipermail/openstack-discuss/2019-August/008504.h… 2. Non-Admin user can filter their instance by availability zone: - Topic: https://review.opendev.org/#/q/topic:bp/non-admin-filter-instance-by-az+(st… - Weekly Progress: Code under review. efried needs to remove his -2 now as spec is merge 3. Boot from volume instance rescue - Topic: https://review.opendev.org/#/q/topic:bp/virt-bfv-instance-rescue+(status:op… - Weekly Progress: Code is in progress. Lee Yarwood has removed the WIP from patches so ready for review. 4. Add action event fault details -Topic: https://review.opendev.org/#/q/topic:bp/action-event-fault-details+(status:… - Weekly Progress: Spec is merged and code is ready for review. Specs are merged and code in-progress: ------------------------------ ------------------ - None Spec Ready for Review or Action from Author: --------------------------------------------------------- 1. Support specifying vnic_type to boot a server -Spec: https://review.opendev.org/#/c/672400/ - Weekly Progress: Stephen summarized the comment about not in scope of nova. I will remove it from this list from next report. 2. Allow specify user to reset password -Spec: https://review.opendev.org/#/c/682302/5 - Weekly Progress: One +2 on this but other are disagree on this idea. More discussion on review. 3. Support re-configure deleted_on_termination in server -Spec: https://review.openstack.org/#/c/580336/ - Weekly Progress: This is old spec and there is no consensus on this till now. Others: 1. None Bugs: ==== I started fixing policy bugs while working on policy-defaults-refresh BP. 5 bugs have been identified till now and fix up for review. - https://bugs.launchpad.net/nova/+bugs?field.tag=policy-defaults-refresh NOTE- There might be some bug which is not tagged as 'api' or 'api-ref', those are not in the above list. Tag such bugs so that we can keep our eyes. -gmann

1 0

[neutron][metering] Dublicated Neutron Meter Rules in different projects kills metering
by merlin.blom＠bertelsmann.de 13 Feb '20

13 Feb '20

I want to use Neutron Meter with gnocchi to report the egress bandwidth used for public traffic. So I created neutron meter labels and neutron meter rules to include all ipv4 traffic: +-------------------+------------------------------------------------------- ---------------------------------------------+ | Field | Value | +-------------------+------------------------------------------------------- ---------------------------------------------+ | direction | egress | | id | f2c9b9a8-0af3-40a5-a718-6e841bad111d | | is_excluded | False | | location | cloud='', project.domain_id='default', project.domain_name=, | | | project.id='80120067cd7949908e44dce45aeb7712', project.name='billing', region_name='xxx', | | | zone= | | metering_label_id | d0068fc8-4a3e-4108-aa11-e3c171d4d1e1 | | name | None | | project_id | None | | remote_ip_prefix | 0.0.0.0/0 | +-------------------+------------------------------------------------------- ---------------------------------------------+ And excluded all private nets: +-------------------+------------------------------------------------------- ---------------------------------------------+ | Field | Value | +-------------------+------------------------------------------------------- ---------------------------------------------+ | direction | egress | | id | 838c9631-665b-42b6-b1e9-539983a38573 | | is_excluded | True | | location | cloud='', project.domain_id='default', project.domain_name=, | | | project.id='80120067cd7949908e44dce45aeb7712', project.name='billing', region_name='xxx', | | | zone= | | metering_label_id | 435652e6-e985-4351-a31a-954bace9eea0 | | name | None | | project_id | None | | remote_ip_prefix | 10.0.0.0/8 | +-------------------+------------------------------------------------------- ---------------------------------------------+ It works fine for just one project but if I apply it to all projects it fails and no measures are recorded in gnocchi. The neutron-metering-agent.log shows the following warning: Feb 13 09:14:18 xxx_host neutron-metering-agent: 2020-02-13 09:14:09.648 4732 WARNING neutron.agent.linux.iptables_manager [req-4c38f1f5-2db4-4d4a-9c1f-9585b1b50427 65c6d4bdcbc7469a910f6361b7f70f27 80120067cd7949908e44dce45aeb7712 - - -] Duplicate iptables rule detected. This may indicate a bug in the iptables rule generation code. Line: -A neutron-meter-r-28155d45-d16 -s 10.0.0.0/8 -o qg-c61bafef-ea -j RETURN I would expect that it is possible to have similar rules for different projects. What do you think? Is it part of the rule creation code? In the iptables_manager code the function is criticized: <https://github.com/openstack/neutron/blob/86e4f141159072421a19080455caba1b0 efef776/neutron/agent/linux/iptables_manager.py> https://github.com/openstack/neutron/blob/86e4f141159072421a19080455caba1b0e fef776/neutron/agent/linux/iptables_manager.py # TODO(kevinbenton): remove this function and the next one. They are # just oversized brooms to sweep bugs under the rug!!! We generate the # rules and we shouldn't be generating duplicates. def _weed_out_duplicates(line): if line in seen_lines: thing = 'chain' if line.startswith(':') else 'rule' LOG.warning("Duplicate iptables %(thing)s detected. This " "may indicate a bug in the iptables " "%(thing)s generation code. Line: %(line)s", {'thing': thing, 'line': line}) return False seen_lines.add(line) # Leave it alone return True <https://bugs.launchpad.net/neutron/+bug/1863068> https://bugs.launchpad.net/neutron/+bug/1863068 Merlin Blom

1 0

[Watcher]IRC meeting at 8:00 UTC today
by licanwei 13 Feb '20

13 Feb '20

2 2

[openstack-dev][kuryr] Kubelet error in ARM64
by VeeraReddy 13 Feb '20

13 Feb '20

Hi I am getting following error in kubelet in arm64 platform Feb 13 07:16:32 node-2088 kubelet[16776]: E0213 07:16:32.493458 16776 machine.go:288] failed to get cache information for node 0: open /sys/devices/system/cpu/cpu0/cache/index0/size: no such file or directoryFeb 13 07:16:32 node-2088 kubelet[16776]: I0213 07:16:32.493600 16776 gce.go:44] Error while reading product_name: open /sys/class/dmi/id/product_name: no such file or directory Help me in fixing above issue. Regards, Veera.

2 1

[operators][cinder] RSD and Swordfish drivers being abandoned
by Brian Rosmaita 13 Feb '20

13 Feb '20

Greetings operators, The current maintainers of the Intel Rack Scale Design (RSD) driver announced at this week's Cinder meeting that the driver will be marked as UNSUPPORTED in Ussuri and that the driver will no longer be maintained. The Swordfish driver, which was under active development, but not yet merged to Cinder, is also being abandoned as well as the os-brick modifications to support NVMeoF. Finally, the third-party CI system for the RSD driver is being dismantled. We want you to be aware of these changes, but more optimistically, we are hoping that there would be some interest in the community in picking these up. If you are or know of such a person, please contact us right away so that we can get a technology transfer going before the current development group has been dispersed to other projects. For more information, please contact: Ivens Zambrano (ivens.zambrano(a)intel.com / IRC:IvensZambrano) David Shaughnessy (david.shaughnessy(a)intel.com / IRC: davidsha) thanks, brian

1 0

[qa][ptg] QA PTG, Vancouver Planning
by Ghanshyam Mann 13 Feb '20

13 Feb '20

Hello Everyone, I have started the Vancouver PTG planning for QA[1]. The very first step is to reserve the space based on number of attendees. For that, please write your name in the etherpad. I know it might not be confirmed yet or the travel process has not started, still, you can write your probability of attending. It is not necessary to be 100% in QA but if you are planning to spend some time in QA PTG, still write your name with comment. [1] https://etherpad.openstack.org/p/qa-victoria-ptg -gmann

1 0

[cinder][ptg] Victoria (Vancouver 2020) PTG headcount
by Brian Rosmaita 13 Feb '20

13 Feb '20

I need to get a rough headcount to submit to the PTG planning committee. Please take a minute to put your name on this etherpad if you think/hope/plan to attend (no commitment--we just want to increase the likelihood that we'll have enough seats for the Cinder team): https://etherpad.openstack.org/p/cinder-victoria-ptg-planning While you're on that etherpad, if you have a topic idea already, feel free to add it. I need the headcount info by 19:00 UTC on 28 February. (But do it now before you forget.) thanks, brian

1 0

[largescale-sig] Meeting summary and next actions
by Thierry Carrez 12 Feb '20

12 Feb '20

Hi everyone, The Large Scale SIG held a meeting today. We had a small attendance, and blame holidays for that. But you can catch up with the summary and logs of the meeting at: http://eavesdrop.openstack.org/meetings/large_scale_sig/2020/large_scale_si… We started with a presentation by oneswig of the integration of HAProxy telemetry via Monasca on a Kolla-Ansible-based deployment, and how that can help us derive latency information based on the API server called, the HTTP method and the HTTP code result across all HAProxy-fronted servers in a deployment. Slides are available at: http://www.stackhpc.com/resources/HAproxy-telemetry.pdf Regarding progress on our "Documenting large scale operations" goal, some doc links were proposed and all seem relevant to our collection. On the "Scaling within one cluster, and instrumentation of the bottlenecks" goal, the draft of the oslo.metrics spec got a first round of comments. masahito will refresh it based on those initial comments, but it would be good for SIG members to also weigh in at that early stage. In other news, we discussed the SIG's involvement in the "Large-scale Usage of Open Source Infrastructure Software" track at the OpenDev event in Vancouver in June. We plan to have SIG members directly involved and have discussions around our two goals for 2020. TODOs between now and next meeting: - masahito to update spec based on initial feedback - everyone to review and comment on https://review.opendev.org/#/c/704733/ The next meeting will happen on February 26, at 9:00 UTC on #openstack-meeting. Cheers, -- Thierry Carrez (ttx)

1 0

[scientific-sig] No Scientific SIG meeting today
by Stig Telfer 12 Feb '20

12 Feb '20

Hi All - Unfortunately there will not be a Scientific SIG IRC meeting today, owing to other commitments and availability. Apologies, Stig

1 0

How to Migrate OpenStack Instance from one Tenant to another
by Pradeep Antil 12 Feb '20

12 Feb '20

Hi Folks, I am using Mitaka OpenStack and VLAN as network type driver for tenant VMs. Initially i have provisioned all the VMs (Including Customer VMs) inside the admin. I want to segregate my internal VMs and Customer VMs, for this to accomplish i have created different tenant names and now i want customer VMs from admin tenant to Customer tenant, On Google , i have a found a script which migrates the VMs but that script doesn't update network and security group details, Can anyone help me and suggest what steps needs to executed to update network , security group and attached Volumes ..? Below is the exact script: #!/bin/bash for i do if [ "$i" != "$1" ]; then echo "moving instance id " $i " to project id" $1; mysql -uroot -s -N <<query use nova; update instances set project_id="$1" where uuid="$i"; query else #get project id of the instance before update old_proj_id=$(mysql -uroot -s -N <<query use nova; select project_id from instances where uuid="$2"; query ) #get user id of the instance before update user_id=$(mysql -uroot -s -N <<query use nova; select user_id from instances where uuid="$2"; query ) fi done echo "quota_resync " $old_proj_id; ./quota_resync.sh $old_proj_id $user_id; echo "quota_resync " $1; ./quota_resync.sh $1 $user_id; root@xxxx:/mnt# cat quota_resync.sh #!/bin/bash count=$(mysql -uroot -s -N <<query use nova; select count(*) from instances where project_id="$1" and vm_state="active"; query ) memory=$(mysql -uroot -s -N <<query use nova; select sum(memory_mb) from instances where project_id="$1" and vm_state="active"; query ) vcpu=$(mysql -uroot -s -N <<query use nova; select sum(vcpus) from instances where project_id="$1" and vm_state="active"; query ) echo "count" $count; echo "vcpus" $vcpu; echo "Ram" $memory; update=$(mysql -uroot -s -N <<query use nova; update quota_usages set in_use=$count where project_id="$1" and user_id="$2" and resource="instances"; update quota_usages set in_use=$memory where project_id="$1" and user_id="$2" and resource="ram"; update quota_usages set in_use=$vcpu where project_id="$1" and user_id="$2" and resource="cores"; query ) root@xxxx:/mnt# Script Execution Method : # /vm_move.sh "destination_tenant_id" "VM_id" -- Best Regards Pradeep Kumar

1 0

Re: [ospurge] looking for project owners / considering adoption
by Artem Goncharov 12 Feb '20

12 Feb '20

Hi, I am thinking to submit (not found possibility so far) a forum-like session for that again in Vancouver, where I would present current status of implementation and we can plan further steps. Unfortunately I have still no confirmation from my employer, that I will be allowed to go. Any ideas/objections? Regards, Artem > On 3. Nov 2019, at 02:34, Tobias Rydberg <tobias.rydberg(a)citynetwork.eu> wrote: > > Hi, > > Sounds really good Artem! Will you be at the session at the Summit? If not, I will bring the information from you to the session... > > Cheers, > Tobias > > Tobias Rydberg > Senior Developer > Twitter & IRC: tobberydberg > > www.citynetwork.eu <http://www.citynetwork.eu/> | www.citycloud.com <http://www.citycloud.com/> > > INNOVATION THROUGH OPEN IT INFRASTRUCTURE > ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED > On 2019-11-02 16:26, Artem Goncharov wrote: >> Hi Tobby, >> >> As I mentioned, if Monty does not start work, I will start it in few weeks latest (mid November). I need this now in my project, therefore I will be definitely able to spend time on implementation in both SDK and OSC. >> >> P.S. mailing this to you, since I will not be on the Summit. >> >> Regards, >> Artem >> >>> On 2. Nov 2019, at 09:19, Tobias Rydberg <tobias.rydberg(a)citynetwork.eu <mailto:tobias.rydberg@citynetwork.eu>> wrote: >>> >>> Hi, >>> >>> A Forum session is planned for this topic, Monday 11:40. Suites perfect to continue the discussions there as well. >>> >>> https://www.openstack.org/summit/shanghai-2019/summit-schedule/events/24407… <https://www.openstack.org/summit/shanghai-2019/summit-schedule/events/24407…> >>> BR, >>> Tobias >>> >>> Tobias Rydberg >>> Senior Developer >>> Twitter & IRC: tobberydberg >>> >>> www.citynetwork.eu <http://www.citynetwork.eu/> | www.citycloud.com <http://www.citycloud.com/> >>> >>> INNOVATION THROUGH OPEN IT INFRASTRUCTURE >>> ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED >>> On 2019-10-30 15:43, Artem Goncharov wrote: >>>> Hi Adam, >>>> >>>> Since I need this now as well I will start working on implementation how it was agreed (in SDK and in OSC) during last summit by mid of November. There is no need for discussing this further, it just need to be implemented. Sad that we got no progress in half a year. >>>> >>>> Regards, >>>> Artem (gtema). >>>> >>>>> On 30. Oct 2019, at 14:26, Adam Harwell <flux.adam(a)gmail.com <mailto:flux.adam@gmail.com>> wrote: >>>>> >>>>> That's too bad that you won't be at the summit, but I think there may still be some discussion planned about this topic. >>>>> >>>>> Yeah, I understand completely about priorities and such internally. Same for me... It just happens that this IS priority work for us right now. :) >>>>> >>>>> >>>>> On Tue, Oct 29, 2019, 07:48 Adrian Turjak <adriant(a)catalyst.net.nz <mailto:adriant@catalyst.net.nz>> wrote: >>>>> My apologies I missed this email. >>>>> >>>>> Sadly I won't be at the summit this time around. There may be some public cloud focused discussions, and some of those often have this topic come up. Also if Monty from the SDK team is around, I'd suggest finding him and having a chat. >>>>> >>>>> I'll help if I can but we are swamped with internal work and I can't dedicate much time to do upstream work that isn't urgent. :( >>>>> >>>>> On 17/10/19 8:48 am, Adam Harwell wrote: >>>>>> That's interesting -- we have already started working to add features and improve ospurge, and it seems like a plenty useful tool for our needs, but I think I agree that it would be nice to have that functionality built into the sdk. I might be able to help with both, since one is immediately useful and we (like everyone) have deadlines to meet, and the other makes sense to me as a possible future direction that could be more widely supported. >>>>>> >>>>>> Will you or someone else be hosting and discussion about this at the Shanghai summit? I'll be there and would be happy to join and discuss. >>>>>> >>>>>> --Adam >>>>>> >>>>>> On Tue, Oct 15, 2019, 22:04 Adrian Turjak <adriant(a)catalyst.net.nz <mailto:adriant@catalyst.net.nz>> wrote: >>>>>> I tried to get a community goal to do project deletion per project, but >>>>>> we ended up deciding that a community goal wasn't ideal unless we did >>>>>> build a bulk delete API in each service: >>>>>> https://review.opendev.org/#/c/639010/ <https://review.opendev.org/#/c/639010/> >>>>>> https://etherpad.openstack.org/p/community-goal-project-deletion <https://etherpad.openstack.org/p/community-goal-project-deletion> >>>>>> https://etherpad.openstack.org/p/DEN-Deletion-of-resources <https://etherpad.openstack.org/p/DEN-Deletion-of-resources> >>>>>> https://etherpad.openstack.org/p/DEN-Train-PublicCloudWG-brainstorming <https://etherpad.openstack.org/p/DEN-Train-PublicCloudWG-brainstorming> >>>>>> >>>>>> What we decided on, but didn't get a chance to work on, was building >>>>>> into the OpenstackSDK OS-purge like functionality, as well as reporting >>>>>> functionality (of all project resources to be deleted). That way we >>>>>> could have per project per resource deletion logic, and all of that >>>>>> defined in the SDK. >>>>>> >>>>>> I was up for doing some of the work, but ended up swamped with internal >>>>>> work and just didn't drive or push for the deletion work upstream. >>>>>> >>>>>> If you want to do something useful, don't pursue OS-Purge, help us add >>>>>> that official functionality to the SDK, and then we can push for bulk >>>>>> deletion APIs in each project to make resource deletion more pleasant. >>>>>> >>>>>> I'd be happy to help with the work, and Monty on the SDK team will most >>>>>> likely be happy to as well. :) >>>>>> >>>>>> Cheers, >>>>>> Adrian >>>>>> >>>>>> On 1/10/19 11:48 am, Adam Harwell wrote: >>>>>> > I haven't seen much activity on this project in a while, and it's been >>>>>> > moved to opendev/x since the opendev migration... Who is the current >>>>>> > owner of this project? Is there anyone who actually is maintaining it, >>>>>> > or would mind if others wanted to adopt the project to move it forward? >>>>>> > >>>>>> > Thanks, >>>>>> > --Adam Harwell >>>> >>

2 1

Galera and haproxy fail; keystone error 'Lost connection to MySQL server during query'
by Albert Braden 12 Feb '20

12 Feb '20

If I run galera without haproxy and point everything to 1 server, it seems to work fine, but we want to load-balance it with haproxy. After setting up haproxy we had lots of errors in nova, neutron and keystone, but I got rid of those by setting haproxy timeout values to 10 minutes. The remaining errors are in keystone. In /var/log/keystone/keystone-wsgi-public.log I see "Loaded 2 Fernet keys" every 5 minutes and this is frequently accompanied by a mysql error 'Lost connection to MySQL server during query' I tried changing various config items in haproxy, galera and keystone, but nothing seems to help. How can I fix these errors? Errors: https://f.perl.bot/p/pbq26k https://f.perl.bot/p/1tnh78 https://f.perl.bot/p/fuxmwo Haproxy config: https://f.perl.bot/p/gu2lil Mysql timeout values: https://f.perl.bot/p/i6l7tn Keystone config (minus commented lines): https://f.perl.bot/p/o6fdht

2 3

[ptl][keystone] cmurphy afk week of February 17
by Colleen Murphy 12 Feb '20

12 Feb '20

I will be on vacation the week of February 17 and will not be computering. Kristi Nikolla (knikolla) has graciously agreed to act as stand-in PTL for keystone during that time and will chair next week's meeting. If necessary I will be reachable by email or IRC but with some delay (hours or days). Colleen

1 0

[keystone] YVR PTG planning
by Colleen Murphy 12 Feb '20

12 Feb '20

Hi all, It's time to start planning the next PTG. Unlike Shanghai, I'm tentatively assuming that we will be able to hold this one in person. I've created an etherpad to start tracking it: https://etherpad.openstack.org/p/yvr-ptg-keystone Please add your name to the etherpad if you have a hunch you'll be attending and participating in keystone-related discussions, and please also add your topic ideas to the list. Colleen

1 0