December 2020 - openstack-discuss

Re: something abount ironic-python-agent
by Kaifeng Wang 28 Dec '20

28 Dec '20

On Sun, Dec 27, 2020 at 8:39 PM Ankele zhang <ankelezhang(a)gmail.com> wrote: > Hi Kaifeng: > Before receiving your reply, I have downloaded > the ronic-python-agent-builder-2.3.0, but I don't know how to build it and > how to use it, I can't find the direction for use. > And I try 'python setup.py install' to install it. and the following is my > execution. > > I don't know the optional values of 'distribution', 'release', 'element', > I hope you can help me. > > distribution refers to the base image that the ramdisk will be built on, release is used to specify the distribution variant. element is a concept of diskimage-builder, each element is handling part of the building process, you can take a look at the diskimage-builder documentation for a complete list [1]. In case further customization on the ramdisk is required, elements can be included by the argument. We have some examples on how to use the IPA-B at [2]. [1] https://docs.openstack.org/diskimage-builder/latest/elements.html [2] https://docs.openstack.org/ironic-python-agent-builder/latest/admin/dib.html Ankele > > Kaifeng Wang <kaifeng.w(a)gmail.com> 于2020年12月27日周日下午2:04写道： > >> >> >> On Sun, Dec 27, 2020 at 12:12 AM Ankele zhang <ankelezhang(a)gmail.com> >> wrote: >> >>> Hi ~ >>> I have deployed OpenStack platform in Rocky version and integreted >>> Ironic(Rocky) into it according to the official documents. I download the >>> coreOS vmlinuz and ramdisk images from >>> https://tarballs.opendev.org/openstack/ironic-python-agent/coreos/files/. >>> and if I don't clean my devices I can deploy baremetal node server >>> currently. When I cleaning my disk using "openstack baremetal node clean >>> --clean-steps '[{"interface": "deploy", "step": "erase_devices"}]' my_bm", >>> I got an error message "Clean step failed: Error performing clean_step >>> erase_devices: No HardwareManager found to handle method: Could not find >>> method: erase_block_device" from ironic-conductor.log and I got the same >>> error in coreOS by "sudo journalctl -u ironic-python-agent -f". I download >>> the Rocky ironic-python-agent source code from github and I search >>> 'erase_block_devices' ,it returned from hardware.py +781. So, the first >>> problem , I don't know why I got this error message. >>> >> >> CoreOS based ramdisk was not maintained for a while, you could try a >> rocky release at >> https://tarballs.opendev.org/openstack/ironic-python-agent/dib/ >> >> >>> I downloaded the source code of the ironic-python-agent and tried to >>> build the coreOS image by 'Makefile', but I always got error as following, >>> this is my second problem. >>> >>> >> Building an IPA ramdisk is moved from diskimage-builder to >> ironic-python-agent-builder, you can find the document here: >> https://docs.openstack.org/ironic-python-agent-builder/latest/ >> >> >>> >>> Finally, I want to code my own 'custom HardwareManager' to support 'raid >>> config' for the ironic-python-agent, but I don't know how to get started. >>> >>> >> For an in-band RAID support, you'll need to create a new hardware manager >> and implement some deploy steps to support RAID configuration, >> specifically, the create_configuration and delete_configuration steps. >> The following links may provide some starting points for you. >> https://docs.openstack.org/ironic/latest/contributor/deploy-steps.html >> >> https://docs.openstack.org/ironic/latest/admin/cleaning.html#raid-interface >> >> Hope this helps. >> >> >>> Looking forward to your help. Thank you. >>> >>> Ankele >>> >>

1 0

something abount ironic-python-agent
by Ankele zhang 26 Dec '20

26 Dec '20

Hi ~ I have deployed OpenStack platform in Rocky version and integreted Ironic(Rocky) into it according to the official documents. I download the coreOS vmlinuz and ramdisk images from https://tarballs.opendev.org/openstack/ironic-python-agent/coreos/files/. and if I don't clean my devices I can deploy baremetal node server currently. When I cleaning my disk using "openstack baremetal node clean --clean-steps '[{"interface": "deploy", "step": "erase_devices"}]' my_bm", I got an error message "Clean step failed: Error performing clean_step erase_devices: No HardwareManager found to handle method: Could not find method: erase_block_device" from ironic-conductor.log and I got the same error in coreOS by "sudo journalctl -u ironic-python-agent -f". I download the Rocky ironic-python-agent source code from github and I search 'erase_block_devices' ,it returned from hardware.py +781. So, the first problem , I don't know why I got this error message. I downloaded the source code of the ironic-python-agent and tried to build the coreOS image by 'Makefile', but I always got error as following, this is my second problem. [image: image.png] Finally, I want to code my own 'custom HardwareManager' to support 'raid config' for the ironic-python-agent, but I don't know how to get started. Looking forward to your help. Thank you. Ankele

2 1

ssh authentication error with Gerrit
by Pete Zaitcev 26 Dec '20

26 Dec '20

Hello: Does anyone here happen to know how to deal with something like this: ........... debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ssh-rsa SHA256:RXNl/GKyDaKiIQ93BoDvrNSKUPFvA1PNeAO9QiirYZU debug1: Host '[review.opendev.org]:29418' is known and matches the RSA host key. debug1: Found key in /q/zaitcev/.ssh/known_hosts:133 debug1: rekey out after 4294967296 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: rekey in after 4294967296 blocks debug1: Will attempt key: /q/zaitcev/.ssh/id_rsa_ostk2014 RSA SHA256:nz5*** explicit agent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey debug1: Next authentication method: publickey debug1: Offering public key: /q/zaitcev/.ssh/id_rsa_ostk2014 RSA SHA256:nz5*** explicit agent debug1: send_pubkey_test: no mutual signature algorithm debug1: No more authentication methods to try. zaitcev(a)review.opendev.org: Permission denied (publickey). [zaitcev@suzdal swift-dark]$ I guess that ssh client in Fedora 33 has a cipher suite that has no intersection with the ssh server at review.opendev.org. But I do not understand what the server is offering, so I do not know what I need to enable. Thanks in advance, -- Pete

2 2

[qa][tempest-plugins][release][stable] Releasing stein-em tag for Tempest plugins
by Ghanshyam Mann 26 Dec '20

26 Dec '20

Hello Everyone, As the stable/stein branch is in Extended Maintenance now[1], Tempest has dropped the support of stable/stein[2]. Tempest and its plugins are branchless which means the master version of Tempest and its plugins are used to test the supported stable branches. Once the stable branch is moved to EM state then, Tempest and its plugins compatible tag needs to be released so that we can keep testing the EM stable branches with this tag once the master Tempest and its plugins are not compatible[3]. This tag can be used as the latest compatible version of Tempest and its plugins for testing the stable/stein in upstream as well as production cloud testing. I have proposed all release patches: - https://review.opendev.org/q/topic:%22tempest-plugin-stein-em%22+(status:op… [1] https://releases.openstack.org/stein/index.html [2] https://review.opendev.org/c/openstack/tempest/+/766770 [3] https://docs.openstack.org/tempest/latest/stable_branch_support_policy.html -gmann

1 0

grouping resources on specific set of nodes
by Volodymyr Litovka 26 Dec '20

26 Dec '20

Hi colleagues, I can't realize how to do the simple-looking thing: there are few locations with small amount of compute/storage/network resources (like small branches with 3 physical servers for both compute, storage and network roles) and I want to see all these locations as single cloud and manage them centrally using single "controller cluster", while localizing resource usage to the specific location. _Kind of_ assign specific project to location "A" and, thus, all resources (VMs, networks, storage resources, ...) in this project will be allocated from nodes, physically located in location "A". Are there any ways to implement this kind of behavior in Openstack? Thank you. -- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

1 0

New nova compute nodes not correctly adding into service
by Grant Morley 25 Dec '20

25 Dec '20

Hi All, I was wondering if anyone could point me in the right direction with an issue we are having adding in new compute nodes to our platform. We have been trying to add a few new compute nodes to increase our capacity and upon configuring them with OSA and them appearing to be in service we have noticed that no new instances are provisioning onto them. We did a test by disabling all compute nodes except for the new ones and an instance launch failed with "No valid compute hosts were found" We have enabled debug mode on Nova and also looked at the nova-api containers ( scheduler, compute etc ) and it appears there is not even an attempt to try and launch an instance on the new hosts from what we can see. The only thing we have noticed on the newly added hosts is that the "privsep-helper" doesn't appear to be started whereas on a working node it is running. We have not changed the software versions of OpenStack or OSA, we are running Queens. The newly added compute node is reporting itself back fine from what we can see: Total usable vcpus: 72, total allocated vcpus: 0 _report_final_resource_view /openstack/venvs/nova-17.1.2/lib/python2.7/site-packages/nova/compute/resource_tracker.py:827 2020-12-24 16:26:32.895 6491 INFO nova.compute.resource_tracker [req-6c58a97e-b7cb-4987-a219-da5b1ce156f8 - - - - -] Final resource view: name=compute-27.openstack.local phys_ram=257826MB used_ram=2048MB phys_disk=30166GB used_disk=0GB total_vcpus=72 used_vcpus=0 pci_stats=[] 2020-12-24 16:26:33.022 6491 DEBUG nova.compute.resource_tracker [req-6c58a97e-b7cb-4987-a219-da5b1ce156f8 - - - - -] Compute_service record updated for compute-27:compute-27.openstack.local _update_available_resource /openstack/venvs/nova-17.1.2/lib/python2.7/site-packages/nova/compute/resource_tracker.py:767 2020-12-24 16:26:33.023 6491 DEBUG oslo_concurrency.lockutils [req-6c58a97e-b7cb-4987-a219-da5b1ce156f8 - - - - -] Lock "compute_resources" released by "nova.compute.resource_tracker._update_available_resource" :: held 0.334s inner /openstack/venvs/nova-17.1.2/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:285 2020-12-24 16:26:35.001 6491 DEBUG oslo_service.periodic_task [req-6c58a97e-b7cb-4987-a219-da5b1ce156f8 - - - - -] Running periodic task ComputeManager._poll_rebooting_instances run_periodic_tasks /openstack/venvs/nova-17.1.2/lib/python2.7/site-packages/oslo_service/periodic_task.py:215 Does anyone know of any other logs we can check / enable that might lead us in the right direction to figure out why the new hosts are not adding in? Any help would be greatly appreciated as we are a bit stumped at the moment. Many thanks, -- Grant Morley Site Reliability Engineer, Civo Ltd Unit H-K, Gateway 1000, Whittle Way Stevenage, Herts, SG1 2FP, UK Visit us at www.civo.com <https://www.civo.com/> Signup for an account now > <https://www.civo.com/signup>

3 2

[cinder] patches for lower-constraints
by Brian Rosmaita 23 Dec '20

23 Dec '20

As discussed at today's cinder meeting, there are patches available that address the lower constraints problems arising from the upgraded pip dependency resolver for most cinder deliverables. Except for master, I've tried to keep the changes minimal. One possibly controversial change has been to add indirect dependencies to test-requirements.txt in a few cases where the version range was so wide that the resolver was taking a very long time to figure out a satisfactory resolution. An example of this is the cinder stable/train patch: https://review.opendev.org/c/openstack/cinder/+/767954 I'm not sure when these patches will be merged, but you can always add the appropriate one as a dependency in gerrit to get the check jobs to pass on your patch. You can find them by using the gerrit hashtag 'fix-l-c': https://review.opendev.org/q/hashtag:fix-l-c Apparently only the owner of a review can add a hashtag, so os-brick/master (merged, owned by lpetrut) and the patches for the non-releaseable stable branches that e0ne is working on aren't in the list yet.

1 0

[cinder] limited review bandwidth until 4 January 2021
by Brian Rosmaita 23 Dec '20

23 Dec '20

Just a reminder that most cinder cores will not be active from tomorrow (24 December) through 4 January 2021. Happy holidays! brian

1 0

[cinder] meeting time change poll
by Brian Rosmaita 23 Dec '20

23 Dec '20

At today's meeting, Lucio proposed moving the cinder weekly meeting time. Please respond to this poll to assess some options before Tuesday 22 December at 1200 UTC. https://rosmaita.wufoo.com/forms/wallaby-cinder-meeting-time-poll/ There's a free-form field on the form so you can propose other alternatives. We aren't considering changing the day of the meeting (Wednesday) at this time, but that's a possibility if it would encourage more attendance. NOTE: next week's meeting, Wednesday 23 December, will be held at the usual time of 1400 UTC. cheers, brian

1 1

[tc] weekly meeting summary
by Mohammed Naser 23 Dec '20

23 Dec '20

Hi everyone, Here's a summary of what happened in our TC weekly meeting last Thursday, Dec 17th. # ATTENDEES (LINES SAID) 1. mnaser (82) 2. gmann (46) 3. diablo_rojo (25) 4. jungleboyj (18) 5. fungi (10) 6. belmoreira (6) 7. ricolin (4) # MEETING SUMMARY 1. Rollcall 2. Skipping the next meetings. Due to the upcoming holidays, we are skipping the next two meetings on Dec 24 and Dec 31st. Mnaser to send an email with details. 3. Follow up on past action items - mnaser send email to ML to find volunteers to help drive goal selection: email sent, and no one strongly opposed. mnaser will write a proposed goal for X about stabilization/cooldown. - gmann complete retirement of searchlight & qinling: DONE - diablo_rojo complete retirement of karbor: In progress, getting there. 4. Audit SIG list and chairs (diablo_rojo) - This list is out of date and a lot of chairs are not active anymore. If any SIG has completed their purpose then we move them to an advisory state, otherwise close. diablo_rojo reach out to SIGs/ML and start auditing states of SIGs 5. Annual report suggestions (diablo_rojo) - mnaser and diablo_rojo are working on the annual report for OpenStack, ideas are welcome. Once it's mostly written a draft will be sent out before submitting it. 6. X cycle goal selection start This item has to go with the action item above regarding the stabilization goal proposal. We'll remove this item from the agenda. 7. Audit and clean-up tags (gmann) - http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019505… gmann started ML on API tag and will see how many projects start and will continue on other tag audits in parallel. We'll remove sub-items in there in the meantime. gmann continue to audit tags + outreach to the community to apply for them 8. X cycle release name vote recording (gmann) - Votes are recorded in ML, mnaser will remove X cycle release name vote recording from the agenda. 9. CentOS 8 releases are discontinued / switch to CentOS 8 Stream (gmann/yoctozepto) - We have an action item to get the community to get together and the QA team is doing the right thing. We'll remove centos 8 topic from the upcoming agenda. 10. Open reviews - https://review.opendev.org/q/projects:openstack/governance+is:open - https://review.opendev.org/c/openstack/governance/+/759904 - https://review.opendev.org/c/openstack/governance/+/759904/7/resolutions/20… # ACTION ITEMS - mnaser send out email about skipping both upcoming meetings - mnaser write a proposed goal for X about stabilization/cooldown - diablo_rojo complete retirement of karbor - diablo_rojo reach out to SIGs/ML and start auditing states of SIGs - mnaser drop X cycle goal selection start from agenda - gmann continue to audit tags + outreach to the community to apply for them - mnaser drop X cycle release name vote recording - mnaser remove centos 8 topic from upcoming agenda To read the full logs of the meeting, please refer to http://eavesdrop.openstack.org/meetings/tc/2020/tc.2020-12-17-15.00.log.html -- Mohammed Naser VEXXHOST, Inc.

1 0