August 2021 - openstack-discuss - lists.openstack.org

[nova][placement] Xena release
by Balazs Gibizer 06 Sep '21

06 Sep '21

Hi, We are getting close to the Xena release. So I created a tracking etherpad[1] with the schedule and TODOs. One thing that I want to highlight is that we will hit Feature Freeze on 3rd of September. As the timeframe between FF and RC1 is short I'm not plannig with FFEs. Patches that are approved before 3rd of Sept EOB can be rechecked or rebased if needed and then re-approved. If you have a patch that is really close but not approved before the deadline, and you think there are two cores that willing to review it before RC1, then please send a mail to the ML with [nova][FFE] subject prefix not later than 7th of Sept EOB. Cheers, gibi [1] https://etherpad.opendev.org/p/nova-xena-rc-potential

1 1

[cinder] discuss nas_secure options and root_squash (prohibiting root access to share)
by Stefan Hoffmann 06 Sep '21

06 Sep '21

Hi cinder team, like discussed in the last meeting, I prepared a list [1] of combinations of the nas_secure options and when to use them. If one want to prohibit root access to NFS share, only setting nas_secure_file_operations and nas_secure_file_permissions to true is a useful option, I think. (Option 4) But also the nas_secure_file_operations is not useful to determine if _qemu_img_info and fs access check at _connect_device should be done with root user or cinder user. So I will update the change [2] like proposed in the etherpad. Feel free to add other use cases and hints for the options to [1] and discuss about the proposed change. Regards Stefan [1] https://etherpad.opendev.org/p/gSotXYAZ3JfJE8FEpMpS [2] https://review.opendev.org/c/openstack/cinder/+/802882 Initial Bug: https://bugs.launchpad.net/cinder/+bug/1938196?comments=all

1 1

[kolla-ansible] Running Docker Swarm with Kuryr networking
by Paolo Celati 02 Sep '21

02 Sep '21

Hi, long story short I have a 3 node Openstack cluster that I manage with kolla-ansible, and I'd like to run Docker Swarm on that as well. I am aware Magnum exists, but I'd first like to get my head around this simpler case. Seeing as I'd like to connect Docker containers from swarm compose files to Neutron networks I'm trying to set up Kuryr together with a swarm configuration. However the documentation is a little scarce <https://docs.openstack.org/kolla-ansible/latest/reference/containers/kuryr-…> and I'd prefer running everything on these three hosts, including etcd. If I follow the guide and pass --cluster-store and --cluster-advertise arguments to dockerd then I can't run Docker in Swarm mode because I get an error saying Swarm is incompatible with those options, and at the same time it's not clear from documentation how you are expected to do Kuryr+Swarm. I did initialise the Swarm cluster before trying to add Kuryr, so I don't know if perhaps doing this the other way works? Do you have ideas or advice with this scenario? If worst comes to worst I can set up an external etcd cluster on a separate non-Openstack cluster but I'd rather avoid that. Thanks in advance, Paolo

4 9

[nova][cinder][barbican] storing secrets in service project
by Pavlo Shchelokovskyy 02 Sep '21

02 Sep '21

Hi all, When Barbican is involved, and services like Nova and Cinder create secrets behind the scenes themselves, this results in problems deleting or otherwise managing some resources by cloud admins. For example as described in https://bugs.launchpad.net/cinder/+bug/1775372, admin can not delete an encrypted volume created by another user, and needs to resort to adding herself to the project first with appropriate roles. This stems IMO from the difference in default resource access policies between Barbican and other services that consume it. For example, while in Nova or Cinder, cloud admin by default can delete servers or volumes in other projects, in Barbican by default only secret creator or admin "in the same project" can delete a secret. I came up with at least 3 solutions (already mentioned in the issue above) but would like to discuss their validity, pros and cons, and especially how they affect the security model and the use cases that this Nova-Cinder-Barbican integration aims to solve. 1. Just ignore failure to delete a secret and log appropriate warning that a secret may be left orphaned. Obviously not the best solution, but rather simple one, also will protect from cases when for whatever reason a secret will be deleted from Barbican directly (e.g. by mistake), rendering volume undeletable for anyone. 2. Change default barbican policies to allow secret deletion for cloud admin (system scope?). Naturally has implications for the Barbican model for resources access, so may be not that appropriate. 3. Store the secrets in the service project instead of user's. Currently those secrets are generated by Nova or Cinder themselves, and user quite probably is not even aware that there was something created in Barbican on her behalf. The user also has no option to pass her own secrets to any of the involved API calls, so this is something happening completely behind the scenes. So do we really need to store these secrets in the user's project? Wouldn't it be better to store them in the service project, have the same service user defined in Nova and Cinder, so it can operate and access those secrets regardless of who manages the resource which depends on access to this secret? This also may solve the problem of encrypted local instance images in Nova, where upon host restart, Nova is not able to bring those instances up because it lacks the context capable of accessing those secrets. I think the third option is the best one, but I may be missing the actual use case meant behind this feature. Is it "keep the data encrypted at rest and in transit" or more strictly "encrypt data of different users with different keys and limit access to those keys" (for the case of breach etc) ? In the first case it seems storing all the auto-generated secrets in a service project would suffice... Please help me understand the best approach to take. Best regards, Pavlo.

4 4

[tc][all]Please help to identify common pain points & video meeting scheduled next week
by Rico Lin 02 Sep '21

02 Sep '21

Dear all First, I thank Kendall and everyone who help with the Pain point elimination etherpad [1]. Two paths we plan to work on or would like to see how we can push it forward: 1. To identify common pain points from OpenStack. And see if we can target them in the following cycles. 2. To see if we can have a community-wide goal to encourage project teams to pick up their own pain point in the following cycles. *This ML is focused on the first path; To identify common pain points.* So I would like to encourage all to help to identify common pain points from it and also help put your feedbacks on the etherpad [1]. To identify common pain points, you can help to leave comments to pain points that you feel it is not an issue for a single project team but for a larger scope. We kind of recognized rabbitmq (or said RPC backend) might be one of the common pain points from that etherpad. And we wish to learn more from all of you. And we need operators' feedback mostly. Also, *we plan to put `identify common pain points` on schedule for the TC meeting next week (which is a video meeting on google meet). If you're interested, please help with etherpad, and join the TC meeting [2] next week.* [1] https://etherpad.opendev.org/p/pain-point-elimination [2] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee *Rico Lin* OIF Individual Board of directors, OpenStack TC, Multi-arch SIG chair, Heat PTL, Senior Software Engineer@EasyStack

1 1

[magnum] [kolla-ansible] [kayobe] [Victoria]
by Tony Pearce 01 Sep '21

01 Sep '21

Testing out Kubernetes with Magnum project, deployed via kayobe on Victoria we have deployed an auto scaling cluster and have run into a problem and I'm not sure how to proceed. I understand that the cluster tried to scale up but the openstack project did not have enough CPU resources to accommodate it (error= Quota exceeded for cores: Requested 4, but already used 20 of 20 cores). So the situation is that the cluster shows "healthy" and "UPDATE_FAILED" but also kubectl commands are failing [1]. What is required to return the cluster back to a working status at this point? I have tried: - cluster resize to reduce number of workers - cluster resize to increase number of workers after increasing project quota - cluster resize and maintaining the same number of workers When trying any of the above, horizon shows an immediate error "Unable to resize given cluster" but magnum logs and heat logs do not show any log update at all at that time. - using "check stack" and resume stack in the stack horizon menu gives this error [2] Investigating the kubectl issue, it was noted that some services had failed on the master node [3]. Manual start as well as reboot the node did not bring up the services. Unfortunately I dont have ssh access to the master and no further information has been forthcoming with regards to logs for those service failures so I am unable to provide anything around that here. I found this link [4] so I decided to delete the master node then run "check" cluster again but the check cluster just fails in the same way except this time it fails saying that it cannot find the master [5] while the previous error was that it could not find a node. Ideally I would prefer to recover the cluster - whether this is still possible I am unsure. I can probably recreate this scenario again. What steps should be performed in this case to restore the cluster? [1] kubectl get no Error from server (Timeout): the server was unable to return a response in the time allotted, but may still be processing the request (get nodes) [2] Resource CHECK failed: ["['NotFound: resources[4].resources.kube-minion: Instance None could not be found. (HTTP 404) (Request-ID: req-6069ff6a-9eb6-4bce-bb25-4ef001ebc428)']. 'CHECK' not fully supported (see resources)"] [3] [systemd] Failed Units: 3 etcd.service heat-container-agent.service logrotate.service [4] https://bugzilla.redhat.com/show_bug.cgi?id=1459854 [5] ["['NotFound: resources.kube_masters.resources[0].resources.kube-master: Instance c6185e8e-1a98-4925-959b-0a56210b8c9e could not be found. (HTTP 404) (Request-ID: req-bdfcc853-7dbb-4022-9208-68b1ab31008a)']. 'CHECK' not fully supported (see resources)"]. Kind regards, Tony Pearce

3 6

[all][tc] Technical Committee next weekly meeting on Sept 2nd at 1500 UTC
by Ghanshyam Mann 01 Sep '21

01 Sep '21

Hello Everyone, Technical Committee's next weekly meeting is scheduled for Sept 2nd at 1500 UTC. If you would like to add topics for discussion, please add them to the below wiki page by Wednesday, Sept 1st, at 2100 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting -gmann

2 2

[nova][cyborg][gpu] GPU performance testing
by Ildiko Vancsa 01 Sep '21

01 Sep '21

Hi, I got a question about tools and practices to check GPU performance in an OpenStack environment that I need some help to answer. The question is about recommended GPU performance testing/benchmarking tools if there are a few that people in the community are using and would recommend? The scope of the testing work is to check GPU performance in OpenStack VMs (both virtualized and passthrough). All the help and pointers are very much appreciated! Thanks, Ildikó

6 9

[largescale-sig] Next meeting: Sept 1st, 15utc
by Thierry Carrez 01 Sep '21

01 Sep '21

Hi everyone, Our next Large Scale SIG meeting will be this Wednesday in #openstack-operators on OFTC IRC, at 15UTC. You can doublecheck how that time translates locally at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20210901T15 A number of topics have already been added to the agenda, including discussing the topic of our next OpenInfra.Live show! Feel free to add other topics to our agenda at: https://etherpad.openstack.org/p/large-scale-sig-meeting Regards, -- Thierry Carrez

1 1

[Kolla][Kolla-Ansible] Ironic Node Cleaning Failed
by Anirudh Gupta 01 Sep '21

01 Sep '21

Hi Team, We have deployed 2 node kolla ansible *12.0.0* in order to deploy openstack *wallaby* release. We have also enabled ironic in order to provision the bare metal nodes. On each server we have 3 nics - *eno1* - OAM for external connectivity and endpoint's publicURL - *eno2* - Mgmt for internal communication between various openstack services. - *ens2f0* - Data Interface Corresponding to this we have defined the following fields in globals.yml - kolla_base_distro: "centos" - kolla_install_type: "source" - openstack_release: "wallaby" - network_interface: "eno2" # MGMT interface - kolla_external_vip_interface: "eno1" # OAM Interface - kolla_internal_vip_address: "192.168.10.3" # MGMT Subnet free ip - kolla_external_vip_address: "10.0.1.136" # OAM subnet free IP - neutron_external_interface: "ens2f0" # Data Interface - enable_neutron_provider_networks: "yes" Note: Only relevant fields are being shown in this query Also, for ironic following fields have been defined in globals.yml - enable_ironic: "yes" - enable_ironic_neutron_agent: "{{ enable_neutron | bool and enable_ironic | bool }}" - enable_horizon_ironic: "{{ enable_ironic | bool }}" - ironic_dnsmasq_interface: "*ens2f0*" # Data interface - ironic_dnsmasq_dhcp_range: "20.20.20.10,20.20.20.100" - ironic_dnsmasq_boot_file: "pxelinux.0" - ironic_cleaning_network: "public1" - ironic_dnsmasq_default_gateway: "20.20.20.1" After successful deployment, a flat provider network with the name public1 is being created in openstack using the below commands: - openstack network create public1 --provider-network-type flat --provider-physical-network physnet1 - openstack subnet create subnet1 --network public1 --subnet-range 20.20.20.0/24 --allocation-pool start=20.20.20.10,end=20.20.20.100 --ip-version=4 --gateway=20.20.20.1 --dhcp Issue/Queries: - Is the configuration done in globals.yml correct or is there anything else that needs to be done in order to separate control and data plane traffic? - Also I have set automated_cleaning as "true" in ironic-conductor conatiner settings.But after creating the baremetal node, we run "node manage" command which runs successfully. Running "*openstack baremetal node provide <node id>"* command powers on the machine, sets the boot mode on Network Boot but no DHCP request for that particular mac is obtained on the controller. Is there anything I am missing that needs to be done in order to make ironic work? Note: I have also verified that the nic is PXE enabled in system configuration setting Regards Anirudh Gupta

3 15

[cinder][nova] fsfreeze hooks issues with cinder snapshot/backup
by Arthur Outhenin-Chalandre 01 Sep '21

01 Sep '21

Hello, We are trying to trigger an fsfreeze via a cinder backup or snapshot. We confirmed that the fsfreeze hooks are actually called with a nova snapshot with `/var/log/qga-fsfreeze-hook.log` in the VM, but we can't achieve the same thing with a cinder backup/snapshot attached to the same instance. We are using Wallaby, libvirt, RBD for cinder volumes and RBD as well for cinder-backup. According to this (old) spec [0], cinder should call the `quiesce()` method in nova during backup/snapshot. We looked in the cinder code and couldn't find any clear evidence that this method is actually called by cinder (but we may have missed something). We added some debug messages on quiesce/can_quiesce/require_quiesce/... in `nova/virt/libvirt/driver.py` and they are never called with a cinder backup/snapshot in our setup while they are (and succeed) if we do a nova snapshot. We are starting to suspect that something is missing in cinder, but it could very well be a problem with our setup as well... Does someone use this feature or know if it should be working/implemented? [0]: https://wiki.openstack.org/wiki/Cinder/QuiescedSnapshotWithQemuGuestAgent#C… Cheers, -- Arthur Outhenin-Chalandre

4 4

[release][heat][ironic][requirements][swift][OpenStackSDK][vitrage][barbican][heat][horizon][ironic][neutron][QA] Cycle With Intermediary Unreleased Deliverables
by Herve Beraud 01 Sep '21

01 Sep '21

Hello teams Quick reminder that we'll need a release very soon for a number of deliverables following a cycle-with-intermediary release model but which have not done *any* release yet in the Xena cycle: ansible-role-atos-hsm ansible-role-lunasa-hsm ansible-role-thales-hsm heat-agents horizon ironic-prometheus-exporter ironic-python-agent-builder ironic-ui ovn-octavia-provider patrole python-openstackclient requirements swift tempest vitrage-dashboard vitrage Those should be released ASAP, and in all cases before the week of 13 September, 2021, so that we have a release to include in the final Xena release. Thanks for your attention. -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud

4 6

Need some help to understand "Baremetal Provision Configuration" file
by wodel youchi 01 Sep '21

01 Sep '21

Hi, I am trying to deploy openstack Wallaby. I need some help to understand the meaning of this file "Baremetal Provision Configuration" Here is the example given in the documentation : First in : https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/deploym… : Provision Baremetal Instances > - name: Controller > count: 3 > defaults: > networks: > - network: ctlplane > subnet: ctlplane-subnet > vif: true > - network: external > subnet: external_subnet > *- network: internalapi > subnet: internal_api_subnet01* > - network: storage > subnet: storage_subnet01 > - network: storagemgmt > subnet: storage_mgmt_subnet01 > - network: tenant > subnet: tenant_subnet01 > network_config: > template: /home/stack/nic-config/controller.j2 > default_route_network: > - external- name: Compute > count: 100 > defaults: > networks: > - network: ctlplane > subnet: ctlplane-subnet > vif: true > *- network: internalapi > subnet: internal_api_subnet02* > - network: tenant > subnet: tenant_subnet02 > - network: storage > subnet: storage_subnet02 > network_config: > template: /home/stack/nic-config/compute.j2 > > Second in : https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/provisi… : Baremetal Provision Configuration > - name: Controller > count: 1 > hostname_format: controller-%index% > ansible_playbooks: > - playbook: bm-deploy-playbook.yaml > defaults: > profile: control > networks: > - network: external > subnet: external_subnet > *- network: internal_api > subnet: internal_api_subnet01* > - network: storage > subnet: storage_subnet01 > - network: storage_mgmt > subnet: storage_mgmt_subnet01 > - network: tenant > subnet: tenant_subnet01 > network_config: > template: templates/multiple_nics/multiple_nics_dvr.j2 > default_route_network: > - external- name: Compute > count: 1 > hostname_format: compute-%index% > ansible_playbooks: > - playbook: bm-deploy-playbook.yaml > defaults: > profile: compute-leaf2 > networks: > *- network: internal_api > subnet: internal_api_subnet02* > - network: tenant > subnet: tenant_subnet02 > - network: storage > subnet: storage_subnet02 > network_config: > template: templates/multiple_nics/multiple_nics_dvr.j2 > > My questions : 1 - Does the name of the network have to match the name of the network (name_lower) in network_data.yaml? because there is an underscore missing in the first example 2 - What is the meaning of the numbers in the subnet name of the network "*internal_api_subnet01 *for controllers and *internal_api_subnet02 *for compute nodes" ? why a different number? What is the meaning of it? I have tried to create the *overcloud-baremetal-deployed.yaml* file several times, and every time I get errors here. Regards.

3 10

Re: Wallaby Magnum Issue
by Mohammed Naser 31 Aug '21

31 Aug '21

Please keep replies on list so others can help too. I don’t know how well tested the Swarm driver is at this point. I believe most Magnum users are using it for Kubernetes only. On Fri, Aug 20, 2021 at 1:05 AM Karera Tony <tonykarera(a)gmail.com> wrote: > Hello Naser, > > Please check below. > > openstack coe cluster template create swarm-cluster-template1 \ > --image fedora-atomic-latest \ > --external-network External_1700\ > --dns-nameserver 8.8.8.8 \ > --master-flavor m1.small \ > --flavor m1.small \ > --coe swarm > openstack coe cluster create swarm-cluster \ > --cluster-template swarm-cluster-template \ > --master-count 1 \ > --node-count 2 \ > --keypair Newkey > > Regards > > Tony Karera > > > > > On Fri, Aug 20, 2021 at 7:03 AM Mohammed Naser <mnaser(a)vexxhost.com> > wrote: > >> What does your cluster template and cluster create command look like? >> >> On Fri, Aug 20, 2021 at 12:59 AM Karera Tony <tonykarera(a)gmail.com> >> wrote: >> >>> Hello Wang, >>> >>> Thanks for the feedback. >>> >>> Unfortunately Octavia is not deployed in my environment (at least not >>> yet) and LB is not enabled on either the cluster template or the cluster >>> itself. >>> >>> Regards >>> >>> Tony Karera >>> >>> >>> >>> >>> On Fri, Aug 20, 2021 at 6:52 AM feilong <feilong(a)catalyst.net.nz> wrote: >>> >>>> Hi Karera, >>>> >>>> It's probably a bug. If you do have Octavia deployed, can you try to >>>> not disable the LB and see how it goes? >>>> >>>> >>>> On 20/08/21 4:18 pm, Karera Tony wrote: >>>> >>>> Hello Team, >>>> >>>> I deployed Openstack Wallby on Ubuntu20 and enabled Magum, however when >>>> I create a cluster I get the error below. >>>> >>>> >>>> *Status Reason ERROR: Property error: : resources.api_lb.properties: : >>>> Property allowed_cidrs not assigned* >>>> Can someone advise on where I could be wrong. Btw, I disabled load >>>> balancer while creating the cluster. >>>> >>>> Regards >>>> >>>> Tony Karera >>>> >>>> >>>> -- >>>> Cheers & Best regards, >>>> ------------------------------------------------------------------------------ >>>> Feilong Wang (王飞龙) (he/him) >>>> Head of Research & Development >>>> >>>> Catalyst Cloud >>>> Aotearoa's own >>>> >>>> Mob: +64 21 0832 6348 | www.catalystcloud.nz >>>> Level 6, 150 Willis Street, Wellington 6011, New Zealand <https://www.google.com/maps/search/150+Willis+Street,+Wellington+6011,+New+…> >>>> >>>> CONFIDENTIALITY NOTICE: This email is intended for the named recipients only. >>>> It may contain privileged, confidential or copyright information. If you are >>>> not the named recipient, any use, reliance upon, disclosure or copying of this >>>> email or its attachments is unauthorised. If you have received this email in >>>> error, please reply via email or call +64 21 0832 6348. >>>> ------------------------------------------------------------------------------ >>>> >>>> -- >> Mohammed Naser >> VEXXHOST, Inc. >> > -- Mohammed Naser VEXXHOST, Inc.

6 34

How to stop the whole system gracefully ?
by Tommy Sway 31 Aug '21

31 Aug '21

My system is installed using kola-ansible. The database was inconsistent due to the last unexpected shutdown, and the system could not start normally, which was very troublesome. I would like to ask what command should be used to shut down the entire system gracefully in an emergency ? Thanks.

2 3

Subject: [all][elections][ptl] PTL Voting Kickoff - Cyborg
by Belmiro Moreira 31 Aug '21

31 Aug '21

Polls for PTL elections are now open and will remain open for you to cast your vote until Sep 07, 2021 23:45 UTC. We are having PTL elections for Cyborg. Please rank all candidates in your order of preference. You are eligible to vote in a PTL election if you are a Foundationindividual member[0] and had a commit in one of that team'sdeliverable repositories[1] over the Sep 25, 2020 00:00 UTC - Aug 24, 2021 00:00 UTC timeframe (Wallaby to Xena) or if you are in that team's list of extra-atcs[2]. If you are eligible to vote in an election, you should find youremail with a link to the Condorcet page to cast your vote in theinbox of your Gerrit preferred email[3]. What to do if you don't see the email and have a commit in atleast one of the projects having an election:* check the trash or spam folders of your gerrit Preferred Email address, in case it went into trash or spam* wait a bit and check again, in case your email server is a bit slow* find the sha of at least one commit from the project's deliverable repos[0] and email the election officials[4]. If we can confirm that you are entitled to vote, we will add youto the voters list for the appropriate election. Our democratic process is important to the health of OpenStack,please exercise your right to vote! Candidate statements/platforms can be found linked to Candidatenames on this page:https://governance.openstack.org/election/ Happy voting,Belmiro,On behalf of all the Election Officials [0] https://www.openstack.org/community/members/ [1] The list of the repositories eligible for electoral status: https://opendev.org/openstack/governance/src/tag/0.10.0/reference/projects.… [2] Look for the extra-atcs element in [1] [3] Sign into review.openstack.org: Go to Settings > Contact Information. Look at the email listed as your preferred email. That is where the ballot has been sent. [4] https://governance.openstack.org/election/#election-officials

1 1

[OSSA-2021-005] Neutron: Arbitrary dnsmasq reconfiguration via extra_dhcp_opts (CVE-2021-40085)
by Jeremy Stanley 31 Aug '21

31 Aug '21

==================================================================== OSSA-2021-005: Arbitrary dnsmasq reconfiguration via extra_dhcp_opts ==================================================================== :Date: August 31, 2021 :CVE: CVE-2021-40085 Affects ~~~~~~~ - Neutron: <16.4.1, >=17.0.0 <17.2.1, >=18.0.0 <18.1.1 Description ~~~~~~~~~~~ Pavel Toporkov reported a vulnerability in Neutron. By supplying a specially crafted extra_dhcp_opts value, an authenticated user may add arbitrary configuration to the dnsmasq process in order to crash the service, change parameters for other tenants sharing the same interface, or otherwise alter that daemon's behavior. This vulnerability may also be used to trigger a configuration parsing buffer overflow in versions of dnsmasq prior to 2.81, which could lead to remote code execution. All Neutron deployments are affected. Patches ~~~~~~~ - https://review.opendev.org/806750 (Ussuri) - https://review.opendev.org/806749 (Victoria) - https://review.opendev.org/806748 (Wallaby) - https://review.opendev.org/806746 (Xena) Credits ~~~~~~~ - Pavel Toporkov (CVE-2021-40085) References ~~~~~~~~~~ - https://launchpad.net/bugs/1939733 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-40085 -- Jeremy Stanley

1 0

[nova][placement] Asia friendly meeting slot on 2nd of Sept
by Balazs Gibizer 31 Aug '21

31 Aug '21

Hi, This is a reminder that the next Asia friendly Nova meeting timeslot is coming up this week on Thursday 8:00 UTC[1]. We will hold that meeting on IRC[2] in the #openstack-nova channel on the OFTC server. See you there. Cheers, gibi [1] http://www.timeanddate.com/worldclock/fixedtime.html?iso=2021-09-02T08:00:00 [2] https://docs.openstack.org/contributors/common/irc.html

1 0

A question about nova live-migration across AZ
by Yingji Sun 31 Aug '21

31 Aug '21

Buddies, I can migration nova instance across available zones with the command below. Suppose instance is in AZ1 and host is in AZ2. nova --os-compute-api-version 2.67 live-migration --force [--block-migrate] <server> [<host>] After migration, the instance’s available zone is changed to AZ2. However, the available zone information in request_specs was not changed. So next time when trying to migrate the instance without specifying a target, the migration target will be selected through nova scheduler, by the availability zone value (AZ1) saved in request_specs. This caused some error. Is this an expected behavior ? Yingji.

4 3

[baremetal-sig][ironic] Tue Sep 7, 2021, 2pm UTC: Ironic User & Operator Feedback
by Arne Wiebalck 30 Aug '21

30 Aug '21

Dear all, The Bare Metal SIG is back from the summer break and will zoom-meet next week, Tue Sep 7, 2021, at 2pm UTC. To start the new season, this first session will focus on: User/operator/admin feedback for Ironic So come along, meet other Ironicers and discuss your Ironic pain points, issues, experiences and ideas with the community and in particular the upstream developers! Everyone, in particular not-yet Ironicers, are welcome to join! All details can be found on: https://etherpad.opendev.org/p/bare-metal-sig Hope to see you there! Arne (for the Bare Metal SIG)

1 0

[Kolla] update
by Ignazio Cassano 30 Aug '21

30 Aug '21

Hello, I would like to ask if the procedure I am using for update my kolla wallaby is correct. Every week new images are released so I execute the following steps: 1. Pull new images on my local registry 2 pull new images from my local registry to controllers and compute nodes 3 kolla-ansible deploy Are the above steps the correct way or I missed something? Must I clean something before deploying ? Thanks Ignazio

3 10

No meeting tomorrow
by Gage Hugo 30 Aug '21

30 Aug '21

Hey team, Since there are no agenda items [0] for the IRC meeting tomorrow, the meeting is cancelled. Our next meeting will be Sept 7th. Thanks [0] https://etherpad.opendev.org/p/openstack-helm-weekly-meeting

1 0

[ci][nova] Server {uuid} failed to delete
by Balazs Gibizer 30 Aug '21

30 Aug '21

Hi, The gate is in a bad shape due to frequent failure of server delete tests due to placement conflicts. The bug that is tracked in [1] became more frequent after a recent placement feature (consumer_types) got landed. The nova team is aware of the situation and possible fixes are being discussed [2]. Cheers, gibi [1] http://status.openstack.org/elastic-recheck/#1836754 [2] https://review.opendev.org/q/topic:bug/1836754

3 4

Hypervisors inaccessable with VM on provider network
by Matthew Ens 30 Aug '21

30 Aug '21

Hello, I am running openstack-victoria on centos8 without OVS and I have followed the installation directions according to the docs with the option to have self-service networks as our project does not need all our vm's accessible from the outside. We do still however occasionally use the provider network for users who need external access to the VM and in cases where using a floating ip is not sufficient. We noticed when there is a VM connected to the provider network we lose access to the hypervisor (cannot ssh or anything, ping still gives a response though) and the hypervisor itself loses internet access (cannot ping or curl some test website). We narrowed it down to two issues. One, we were using firewalld to keep track of our own firewall rules while openstack uses iptables to enforce its security group rules. These two did not work well together due to the second issue where openstack assigns incoming connections to a conntrack zone, it seemed like firewalld could not handle this correctly and would drop connections that should have been allowed under its rules. After transferring our firewall rules to iptables and masking firewalld, the hypervisor was accessible over ssh but could not access the internet due to our rule allowing ESTABLISHED and RELATED connections not being applied properly when a packet was assigned to a conntrack zone. The work around we found for this was to add a rule where packets destined for the hypervisor were not assigned to a conntrack zone (add a rule to the raw iptables table in the PREROUTING chain to just be accepted if the destination ip address was the address of the hypervisor). This worked until a new vm was created as openstack rebuilds the iptables when a change is made and puts it's own rules above those created by someone other than openstack. To fix this we changed the code in neutron (iptables_manager.py, the modify_rules function) to put this rule only above those made by openstack in the raw iptables table, PREROUTING chain. This fixed our issue, we are now able to access the hypervisor when VMs are running on a provider network and VMs and the hypervisor are accessible and able to access the internet. Security groups are also properly enforced on the VMs as are our firewall rules assigned elsewhere in iptables. I'm not sure if this is exactly a bug since in most cases openstack should be assigning its own firewall rules first in case there are DROP rules put in by someone else or I could also have missed some configuration step in which case I would love to know how I can improve. We thought others may be having a similar issue. If you'd like more details or have suggestions I'm happy to receive feedback. Cheers, Matt

1 0

[PTLs][release] Xena Cycle Highlights
by helena＠openstack.org 30 Aug '21

30 Aug '21

Hello Everyone! The deadline for cycle highlights is just a few days away, on September 3 [1]. Please be sure to get those in. I look forward to seeing what all you all have accomplished this release! How To Reminder: ------------------------- Simply add them to the deliverables/$RELEASE/$PROJECT.yaml in the openstack/releases repo like this: cycle-highlights: - Introduced new service to use unused host to mine bitcoin. The formatting options for this tag are the same as what you are probably used to with Reno release notes. Also, you can check on the formatting of the output by either running locally: tox -e docs And then checking the resulting doc/build/html/$RELEASE/highlights.html file or the output of the build-openstack-sphinx-docs job under html/$RELEASE/highlights.html. Feel free to add Kendall Nelson (diablo_rojo) as a reviewer on your patches. Thanks :) -Helena Spease (hspease) [1] [ https://releases.openstack.org/xena/schedule.html ]( https://releases.openstack.org/xena/schedule.html )

1 0