March 2021 - openstack-discuss - lists.openstack.org

Puppet openstack modules
by Bessghaier, Narjes 03 Mar '21

03 Mar '21

Dear OpenStack team, My name is Narjes and I'm a PhD student at the University of Montréal, Canada. My current work consists of analyzing code reviews on the puppet modules. I would like to precisely know what the ruby files are used for in the puppet modules. As mentioned in the official website, most of unit test are written in ruby. Are ruby files destined to carry out units tests or destined for production code. I appreciate your help, Thank you

3 4

[election][nova] PTL Candidacy for Wallaby
by Balazs Gibizer 03 Mar '21

03 Mar '21

Hi, I would like to continue serving as the Nova PTL in the Xena cycle. In Wallaby I hope I helped to keep Nova alive and kicking and I intend to continue what I have started. My employer is supportive to continue spending time on PTL and core duties. If I am elected then I will try to focus on the following areas: * Keeping the Nova bug backlog under control * Working on changes that help the maintainability and stability of Nova * Finishing up things that are already ongoing before starting new items Also, I'd like to note that if elected then Xena will be my 3rd consecutive term as Nova PTL so I will spend some time during the cycle to find my successor for the Y cycle. Cheers, gibi

1 0

Train/SR-IOV direct port mode live-migration - question
by Heib, Mohammad (Nokia - IL/Kfar Sava) 03 Mar '21

03 Mar '21

Hi All, we recently moved to openstack Train and according to the version release notes the SR-IOV direct port live-migration support was added to this version. so we tried to do some live-migration to vm with two SR-IOV direct ports attached to bond interface on the vm (no vSwitch interface or a indirect only direct ports) but seems that we have an issue with maintaining the network connectivity during and after the live-migration, according to [1] i see that in order to maintain network connectivity during the migration we have to add one indirect or vswitch port to the bond and this interface will carry the traffic during the migration and once the migration completed the direct port will back to be the primary slave on the target VM bond. my question is if we don't add the indirect port we will lose the connectivity during the migration which makes sense to me, but why the connectivity does not back after the migration completed successfully, and why the bond master boot up with no slaves on the target VM? according to some documents and blueprints that I found in google (including [2],[3]) the guest os will receive a virtual hotplug add even and the bond master will enslave those devices and connectivity will back which is not the case here. so I wondering maybe I need to add some scripts to handle those events (if so where to add them) or some network flags to the ifcfg-* files or i need to use a specific guest os? [1] : https://specs.openstack.org/openstack/nova-specs/specs/stein/approved/libvi… <https://specs.openstack.org/openstack/nova-specs/specs/stein/approved/libvi…> [2] :https://www.researchgate.net/publication/228722278_Live_migration_with_pass-through_device_for_Linux_VM <https://www.researchgate.net/publication/228722278_Live_migration_with_pass…> [3] :https://openstack.nimeyo.com/72653/openstack-nova-neutron-live-migration-with-direct-passthru <https://openstack.nimeyo.com/72653/openstack-nova-neutron-live-migration-wi…> *bond master ifcfg file:* DEVICE=bond1 BONDING_OPTS=mode=active-backup HOTPLUG=yes TYPE=Bond BONDING_MASTER=yes BOOTPROTO=none NAME=bond1 ONBOOT=yes *slaves ifcfg files:* TYPE=Ethernet DEVICE=eth0 HOTPLUG=no ONBOOT=no MASTER=bond1 SLAVE=yes BOOTPROTO=none NM_CONTROLLED=no *guest OS:* CentOS Linux release 7.7.1908 (Core) * * */Thanks in advance for any help :)/,*

2 1

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

anti-affinity: what're the mechanics?
by Ken D'Ambrosio 03 Mar '21

03 Mar '21

Hey, all. Turns out we really need anti-affinity running on our (very freaking old -- Juno) clouds. I'm trying to find docs that describe its functionality, and am failing. If I enable it, and (say) have 10 hypervisors, and 12 VMs to fire off, what happens when VM #11 goes to fire? Does it fail, or does the scheduler just continue to at least *try* to maintain as few possible on each hypervisor? Thanks! -Ken

3 2

[victoria][nova] Instance Live Migration
by Ammad Syed 03 Mar '21

03 Mar '21

Hi, I am trying to configure live migration of instance backed by lvm iscsi storage. I have done below mentioned config in nova.conf. [libvirt] virt_type = kvm volume_use_multipath = True live_migration_uri = qemu+ssh://nova@%s/system The live migration is being failed with below logs. 2021-03-03 07:15:51.917 706290 INFO nova.compute.manager [-] [instance: 7de891d3-c712-434c-b39f-08e512e46e83] Took 6.02 seconds for pre_live_migration on destination host kvm12-a1-khi01. 2021-03-03 07:15:52.029 706290 ERROR nova.virt.libvirt.driver [-] [instance: 7de891d3-c712-434c-b39f-08e512e46e83] Live Migration failure: operation failed: Failed to connect to remote libvirt URI qemu+ssh://nova@kvm12-a1-khi01/system: Cannot recv data: Host key verification failed.: Connection reset by peer: libvirt.libvirtError: operation failed: Failed to connect to remote libvirt URI qemu+ssh://nova@kvm12-a1-khi01/system: Cannot recv data: Host key verification failed.: Connection reset by peer 2021-03-03 07:15:52.444 706290 ERROR nova.virt.libvirt.driver [-] [instance: 7de891d3-c712-434c-b39f-08e512e46e83] Migration operation has aborted 2021-03-03 07:15:52.489 706290 INFO nova.compute.manager [-] [instance: 7de891d3-c712-434c-b39f-08e512e46e83] Swapping old allocation on dict_keys(['3e5679c8-165e-4c35-9de5-ef0d3af0f9d8']) held by migration f519f768-5a62-4f17-9ac0-1cc2c814ec3a for instance 2021-03-03 07:15:55.927 706290 WARNING nova.compute.manager [req-116cf2ef-4720-421e-9aad-75451e3deafe b95c0ad0fb9848598988b5bff99ca55b abf41db7e6dc429086713f4b46cd3655 - default default] [instance: 7de891d3-c712-434c-b39f-08e512e46e83] Received unexpected event network-vif-unplugged-df7666d6-add3-4638-98e1-14db30122c3f for instance with vm_state active and task_state None. I am able to login from host1 to host2 via ssh without password. Also I have disabled hostkey check in ssh config of nova. (~/.ssh/config) Host * StrictHostKeyChecking no UserKnownHostsFile=/dev/null I am able to connect host2 from host 1 and vice versa via virsh uri. nova@kvm10-a1-khi01:~$ virsh -c qemu+ssh://nova@kvm12-a1-khi01/system Welcome to virsh, the virtualization interactive terminal. Type: 'help' for help with commands 'quit' to quit virsh # exit No sure where i am missing something. - Ammad

1 0

Some questions about Ironic bare metal
by Ankele zhang 03 Mar '21

03 Mar '21

Hi, I have included Ironic service into my rocky OpenStack platform. Using the IPMI driver. The cleaning network and the provisioning network are my provider network. I have some questions about Ironic deleting and inspecting. 1、every time I delete my baremetal nodes, I need to delete the associated servers first. the servers delete successfully, but the associated servers filed in nodes are still exist. So I need to set nodes to maintenance mode before I can delete bare metal nodes. what's more, the port list in 'openstack port list' which belong to the nodes can not be deleted automatically. How can I delete nodes correctly? 2、If the new created baremetal nodes' system disks have exist OS data.I cannot inspect them, I need to clean them first, but the cleaning step need MAC address of the nodes and the MAC addresses are obtained by inspecting. So what should I do? I don't want to fill in the MAC addresses manually. I have got the PXE boot but was immediately plugged into the existing system as: [image: image.png] 0.1s later: [image: image.png] Looking forward to your help. Ankele.

2 1

[all][elections][ptl][tc] Combined PTL/TC April 2021 Nominations Kickoff
by Kendall Nelson 03 Mar '21

03 Mar '21

Nominations for OpenStack PTLs (Project Team Leads) and TC (Technical Committee) positions (5 positions) are now open and will remain open until Mar 09, 2021 23:45 UTC. All nominations must be submitted as a text file to the openstack/election repository as explained at https://governance.openstack.org/election/#how-to-submit-a-candidacy Please make sure to follow the candidacy file naming convention: candidates/xena/<Project_Name or "TC">/<email_address> (for example, "candidates/xena/TC/stacker(a)example.org"). The name of the file should match an email address for your current OpenStack Foundation Individual Membership. Take this opportunity to ensure that your OSF member profile contains current information: https://www.openstack.org/profile/ Any OpenStack Foundation Individual Member can propose their candidacy for an available, directly-elected seat on the Technical Committee. In order to be an eligible candidate for PTL you must be an OpenStack Foundation Individual Member. PTL candidates must also have contributed to the corresponding team during the Victoria to Wallaby timeframe, Apr 24, 2020 00:00 UTC - Mar 08, 2021 00:00 UTC. Your Gerrit account must also have a verified email address matching the one used in your candidacy filename. Both PTL and TC elections will be held from Mar 12, 2021 23:45 UTC through to Mar 19, 2021 23:45 UTC. The electorate for the TC election are the OpenStack Foundation Individual Members who have a code contribution to one of the official teams over the Victoria to Wallaby timeframe, Apr 24, 2020 00:00 UTC - Mar 08, 2021 00:00 UTC, as well as any Extra ATCs who are acknowledged by the TC. The electorate for a PTL election are the OpenStack Foundation Individual Members who have a code contribution over the Victoria to Wallaby timeframe, Apr 24, 2020 00:00 UTC - Mar 08, 2021 00:00 UTC, in a deliverable repository maintained by the team which the PTL would lead, as well as the Extra ATCs who are acknowledged by the TC for that specific team. The list of project teams can be found at https://governance.openstack.org/tc/reference/projects/ and their individual team pages include lists of corresponding Extra ATCs. Please find below the timeline: nomination starts @ Mar 02, 2021 23:45 UTC nomination ends @ Mar 09, 2021 23:45 UTC campaigning starts @ Mar 09, 2021 23:45 UTC campaigning ends @ Mar 11, 2021 23:45 UTC elections start @ Mar 12, 2021 23:45 UTC elections end @ Mar 19, 2021 23:45 UTC Shortly after election officials approve candidates, they will be listed on the https://governance.openstack.org/election/ page. The electorate is requested to confirm their email addresses in Gerrit prior to 2021-03-08 00:00:00+00:00, so that the emailed ballots are sent to the correct email address. This email address should match one which was provided in your foundation member profile as well. Gerrit account information and OSF member profiles can be updated at https://review.openstack.org/#/settings/contact and https://www.openstack.org/profile/ accordingly. If you have any questions please be sure to either ask them on the mailing list or to the elections officials: https://governance.openstack.org/election/#election-officials -Kendall Nelson (diablo_rojo)

1 0

[all][elections][ptl][tc] IMPORTANT Note About March 2021 Elections
by Jeremy Stanley 03 Mar '21

03 Mar '21

Please note that to be eligible to vote in upcoming Technical Committee and Project Team Lead elections, you must make sure that your Preferred Email Address in Gerrit appears somewhere in your Open Infrastructure Foundation Individual Member profile. To check this, visit https://review.opendev.org/settings/#EmailAddresses while authenticated to Gerrit and make a note of which address has the Preferred button selected. Next visit https://openstackid.org/accounts/user/profile and (after authenticating) make sure that address appears in at least one of the Email, Second Email, or Third Email fields. If not, add it to one of the available Email fields there and click the Save button. This requirement has changed slightly from before (when any address known to Gerrit was sufficient), because of slightly stricter API handling in the newer Gerrit release we're now running. If you have any questions, please feel free to reply or reach out to the technical election officials in the #openstack-election IRC channel on Freenode. -- Jeremy Stanley

1 0

Re: [openstack-community] Ovn chassis error possibly networking config error.
by Amy Marrich 03 Mar '21

03 Mar '21

Deepesh, Forwarding to the OpenStack Discuss mailing list. Thanks, Amy (spotz) On Sat, Feb 27, 2021 at 12:42 PM Dees <motosingh(a)yahoo.co.uk> wrote: > Hi All, > > Deployed openstack all service yesterday and seemed to be running since > power cycling the openstack today. > > Then deployed and configured VM instance with networking but config > onv-chassis is reporting error, as I am new to openstack (having used it > number of years back) mind guiding where I should be looking any help will > be greatly appreciated. > > > > nova-compute/0* active idle 1 10.141.14.62 > Unit is ready > ntp/0* active idle 10.141.14.62 > 123/udp chrony: Ready > ovn-chassis/0* error idle 10.141.14.62 > hook failed: "config-changed" > > > Deployed VM instance using the following command line. > > > curl > http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64.img > | \ > openstack image create --public --container-format bare --disk-format > qcow2 \ > --property architecture=x86_64 --property hw_disk_bus=virtio \ > --property hw_vif_model=virtio "focal_x86_64" > > openstack flavor create --ram 512 --disk 4 m1.micro > > openstack network create Pub_Net --external --share --default \ > --provider-network-type vlan --provider-segment 200 > --provider-physical-network physnet1 > > openstack subnet create Pub_Subnet --allocation-pool > start=10.141.40.40,end=10.141.40.62 \ > --subnet-range 10.141.40.0/26 --no-dhcp --gateway 10.141.40.1 \ > --network Pub_Net > > openstack network create Network1 --internal > openstack subnet create Subnet1 \ > --allocation-pool start=192.168.0.10,end=192.168.0.199 \ > --subnet-range 192.168.0.0/24 \ > --gateway 192.168.0.1 --dns-nameserver 10.0.0.3 \ > --network Network1 > > Kind regards, > Deepesh > _______________________________________________ > Community mailing list > Community(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/community >

3 3