- openstack-discuss - lists.openstack.org

[ironic]Anaconda deploy interface config
by Carol Bouchard 08 Feb '22

08 Feb '22

Ironic folks: I'm trying to spawn a RHEL7 image using a kickstart file and having issues with stage2 file. First I used bifrost to initially setup a couple of VMs. (There is no openstack/glance). I'm now using one of those VMs to boot up with RHEL7. I changed the VM config with the following: *| deploy_interface | anaconda* * | instance_info | {'kernel': 'http://myip:8080/RHEL7/vmlinuz <http://myip:8080/RHEL7/vmlinuz>', 'ramdisk': 'http://myip:8080/RHEL7/initrd.img <http://myip:8080/RHEL7/initrd.img>', 'image_source': 'http://myip:8080/RHEL7/initrd.img <http://myip:8080/RHEL7/initrd.img>', 'stage2': 'http://myip:8080/RHEL7/squashfs.img <http://myip:8080/RHEL7/squashfs.img>', 'ks_cfg': 'http://myip:8080/RHEL7/ks.cfg.template <http://myip:8080/RHEL7/ks.cfg.template>', 'ks_template': 'http://myip:8080/RHEL7/ks.cfg.template <http://myip:8080/RHEL7/ks.cfg.template>'}* ironic.conf changes I made are as follows: *enabled_deploy_interfaces = direct,ramdisk,anaconda* *[anaconda]default_ks_template = file:///etc/ironic/ks.cfg.template* The error I'm getting is as follows: *$ baremetal node show testvm1 --field last_error* *| last_error | Deploy step deploy.deploy failed with IsADirectoryError: [Errno 21] Is a directory: '/httpboot/4e41df61-84b1-5856-bfb6-6b5f2cd3dd11/LiveOS/squashfs.img'.* Tail end of traceback is as follows: * ironic-conductor[]: ERROR ironic.conductor.utils File "/opt/stack/bifrost/lib64/python3.9/site-packages/ironic/common/pxe_utils.py", line 1245, in cache_ramdisk_kernel ironic-conductor[]: ERROR ironic.conductor.utils deploy_utils.fetch_images(ctx, TFTPImageCache(), list(t_pxe_info.values()), ironic-conductor[]: ERROR ironic.conductor.utils File "/opt/stack/bifrost/lib64/python3.9/site-packages/ironic/drivers/modules/deploy_utils.py", line 240, in fetch_images ironic-conductor[]: ERROR ironic.conductor.utils cache.fetch_image(href, path, ctx=ctx, force_raw=force_raw) ironic-conductor[]: ERROR ironic.conductor.utils File "/opt/stack/bifrost/lib64/python3.9/site-packages/ironic/drivers/modules/image_cache.py", line 120, in fetch_image ironic-conductor[]: ERROR ironic.conductor.utils dest_up_to_date = _delete_dest_path_if_stale(master_path, ironic-conductor[]: ERROR ironic.conductor.utils File "/opt/stack/bifrost/lib64/python3.9/site-packages/ironic/drivers/modules/image_cache.py", line 460, in _delete_dest_path_if_stale ironic-conductor[]: ERROR ironic.conductor.utils os.unlink(dest_path) ironic-conductor[]: ERROR ironic.conductor.utils IsADirectoryError: [Errno 21] Is a directory: '/httpboot/4e41df61-84b1-5856-bfb6-6b5f2cd3dd11/LiveOS/squashfs.img'* Please advise. Carol

3 5

[election][cinder] PTL Candidacy for Z
by Rajat Dhasmana 08 Feb '22

08 Feb '22

Hi All, I would like to announce my candidacy for PTL of the Cinder project for the Z cycle. Since this is the first time I'm proposing my candidacy, I would like to briefly introduce myself. I started contributing to OpenStack back in the Queens release (although not very actively) and started focusing on the Cinder project in the Rocky release. I became a core reviewer in Cinder in the mid of the Stein release and since then I've been actively contributing to the Cinder project in terms of features, bug fixes, reviews etc. I'm also a part of Cinder's core security group and a stable core and currently serving as release liaison for Cinder for the past 3 releases. Coming to the focus for the Z release, Cinder receives an abundance of commits every cycle in terms of new drivers, driver features, core cinder features, bug fixes, improvements etc and we've always faced a shortage in reviews. It is not due to fewer people working actively but more of a priority issue in their respective roles. I would like to encourage contributors to discuss with their managers about the importance of code review in opensource and how it is helpful for the community and the individuals as well. Apart from that, I would like to revisit the security issues backlog since that hasn't been looked upon in quite some time and if we encounter something that needs attention, we can also hold core security meetings from time to time to address the issues. We are also getting active driver contributions every cycle which is a good thing, but sadly the driver implementation patches seem to have a lot of mistakes which are well documented in the driver contribution docs and something I would like to highlight in the Z PTG (as most of the vendors join it and propose their driver ideas). Again, the documentation is not perfect as we discussed in Yoga PTG. Following up upon this and improving it is another focus I support for Cinder. Lastly, I would like to put more emphasis upon the 3rd Party CI compliance check which we haven't done in a while and it would be good to know how many vendors are actually maintaining their CI consistently. There are some new ideas started by Brian in the past releases which I would like to continue. Some examples include the last cinder meeting being a video+IRC meeting and every third Friday of the month, we have a festival of XS reviews which significantly reduced the backlog of open patches. In the end, I would like to say, I want to continue the good trends set in the Cinder community and improve on certain areas where there is not much attention being given. I will do my best to address the above mentioned items during my time as PTL. Thanks for considering me. Rajat Dhasmana (whoami-rajat)

1 0

[election][tc] My TC non-candidacy
by Radosław Piliszek 08 Feb '22

08 Feb '22

Dears, I am hereby announcing my TC non-candidacy. It was a great pleasure to work with you but my personal and professional life has shifted away from OpenStack enough to make it hard for me to dedicate the time the TC deserves. Kind regards, -yoctozepto

4 3

[all][elections][ptl][tc] Combined PTL/TC z cycle Election Nominations Kickoff
by Ghanshyam Mann 08 Feb '22

08 Feb '22

Hello Everyone, Nominations for OpenStack PTLs (Project Team Leads) and TC (Technical Committee) positions (5 positions) are now open and will remain open until Feb 15, 2022 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/z/<Project_Name or "TC">/<email_address> (for example, "candidates/z/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 Xena to Yoga timeframe, Mar 26, 2021 00:00 UTC - Feb 15, 2022 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 Feb 22, 2022 23:45 UTC through to Mar 01, 2022 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 Xena to Yoga timeframe, Mar 26, 2021 00:00 UTC - Feb 15, 2022 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 Xena to Yoga timeframe, Mar 26, 2021 00:00 UTC - Feb 15, 2022 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: PTL + TC nomination starts @ Feb 08, 2022 23:45 UTC PTL + TC nomination ends @ Feb 15, 2022 23:45 UTC TC campaigning starts @ Feb 15, 2022 23:45 UTC TC campaigning ends @ Feb 22, 2022 23:45 UTC PTL + TC elections start @ Feb 22, 2022 23:45 UTC PTL + TC elections end @ Mar 01, 2022 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 2022-02-15 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 -gmann & The OpenStack Technical Election Officials

1 0

[stable] sphinx docs jobs fail on old stable branches (no more py2 support)
by Előd Illés 08 Feb '22

08 Feb '22

Hi stable maintainers, This mail is about to get some attention to build-openstack-sphinx-docs job that recently started to fail on old stable branches (Queens and Pike) and block gates for about ~30 repositories. (The failures are also visible in periodic stable jobs). This is because py27 support from sphinx jobs were removed [1] recently. (Python 3 (py35) support was mostly done in Rocky so that branch is not affected) To unblock the gates I see the following options: 1. fix sphinx jobs to work with py35 (most probably requires some patches to backport - in a squashed patch - and maybe some resolution of requirement conflicts) 2. set sphinx jobs to non-voting (even better to remove them to do not use resources unnecessarily) 3. revert the patch [1] that removed the py2 support of sphinx (maybe the easiest thing to do, though i understand that py2 support is something that shouldn't be kept forever) 4. teams examine their old branches and if they are not really maintained, haven't merged patches recently, then probably it is a good time to propose their EOL transition according to the EOL process [1] Some additional thoughts: - When Extended Maintenance was introduced the community agreed that certain CI jobs can be removed, CI coverage can be reduced as time goes. - To keep open an old branch in Extended Maintenance helps the cooperation between vendors / users as instead of maintaining it by themselves it can be done with a common effort, which could be beneficial for everyone. On the other hand, if there are no maintainers or invested efforts to keep the branch and CI alive, then it is a reasonable decision to transition the branch to End of Life. Please consider the above options and act to eliminate the gate failures / periodic stable job failures. [1] https://review.opendev.org/c/zuul/zuul-jobs/+/827588 <https://review.opendev.org/#/q/I98c3da5b02a4ac7fb9d7bd8e00170762e77b9f40>[2] https://docs.openstack.org/project-team-guide/stable-branches.html#end-of-l… Thanks, Előd

2 1

[election][ptl][cinder] PTL non-candidacy
by Brian Rosmaita 08 Feb '22

08 Feb '22

Hello Argonauts, With the election season rapidly approaching [0], I want to communicate my intentions to the team, to wit, I will not be standing for PTL for the Z cycle. I've served as PTL for five cycles, which conflicts with my belief that it's good for open source projects to rotate leadership. I think the Cinder project is fairly healthy, but it will be good to have someone take the Cinder helm who has a fresh perspective and who will be as excited to be PTL as I was way back in Ussuri. We have an excellent project team, and I have no doubt that whoever steps up will have plenty of support from the Cinder community (including me, I don't have any intention of going anywhere in the near term). cheers, brian [0] http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027070…

7 6

Floating IP issue regarding Latest upgrade to XENA
by Adivya Singh 08 Feb '22

08 Feb '22

Hi Team, We have the latest upgrade to XENA, and we are facing an issue with XENA release , where a few times, even Floating IP attached to the instance are not reachable. I tried various ways to troubleshoot the issue, Regarding The IP is reachable from the router Namespace, The router IP is reachable, L3 agent is working Fine, as other Floating IP are reachable which are hosted through router on L3 agent, All ports are up, Interfaces are up, SNAT and DNAT are working Fine, But as soon as i dissociate and associate the Floating IP , it started working Fine Any Idea, why this Happening , and later on Fixed when Floating IP is dissociate and associate again, and later again starts happening Regards Adivya Singh

1 0

[ironic] Each deploy overwrites the entire target disk
by Radosław Piliszek 08 Feb '22

08 Feb '22

Dears, I have a question regarding the default behaviour of Ironic Python Agent - it seems that each deploy causes the entire target disk to be overwritten. I have noticed this after replacing disks with larger ones, the deployment process started taking considerably longer and I observed that each sector is rewritten on the target device. Is that expected? Can I somehow avoid it? I am using whole-disk, qcow2 images that are much smaller than the disk size (even in raw form). I am running Ironic Wallaby. The deployment method is direct. Kind regards, -yoctozepto

2 4

[openstack-helm] No Meeting Tomorrow
by Gage Hugo 07 Feb '22

07 Feb '22

Hey team, Since there's nothing on the agenda for tomorrow's meeting, it has been cancelled. We will meet again next week.

1 0

[nova][ops] Problem with nova policies for resume operation
by Massimo Sgaravatto 07 Feb '22

07 Feb '22

Dear all I am running a Xena installation I have modified the nova policy fail so that certain operations can be done only by the user who created the instance, or by the administrator This [*] is my policy.yaml file. While the suspend operation works as intended (I can suspend only my instances and I am not allowed to suspend an instance created by another user) I am not able to resume an instance that I own and that I have previously suspended. I get this error: ERROR (Forbidden): Policy doesn't allow os_compute_api:os-suspend-server:suspend to be performed. (HTTP 403) (Request-ID: req-c57458bc-b1ea-4b40-a1d2-0f67608ef673) Only removing the line: "os_compute_api:os-suspend-server:suspend": "rule:admin_api or user_id:%(user_id)s" from the policy file, I am able to resume the instance. I am not able to understand what is wrong with that policy. Any hints ? Thanks, Massimo [*] # Pause a server # POST /servers/{server_id}/action (pause) # Intended scope(s): system, project "os_compute_api:os-pause-server:pause": "rule:admin_api or user_id:%(user_id)s" # Delete a server # DELETE /servers/{server_id} # Intended scope(s): system, project "os_compute_api:servers:delete": "rule:admin_api or user_id:%(user_id)s" # Resize a server # POST /servers/{server_id}/action (resize) # Intended scope(s): system, project "os_compute_api:servers:resize": "rule:admin_api or user_id:%(user_id)s" # Rebuild a server # POST /servers/{server_id}/action (rebuild) # Intended scope(s): system, project "os_compute_api:servers:rebuild": "rule:admin_api or user_id:%(user_id)s" # Stop a server # POST /servers/{server_id}/action (os-stop) # Intended scope(s): system, project "os_compute_api:servers:stop": "rule:admin_api or user_id:%(user_id)s" # Resume suspended server # POST /servers/{server_id}/action (resume) # Intended scope(s): system, project "os_compute_api:os-suspend-server:resume": "rule:admin_api or user_id:%(user_id)s" # Suspend server # POST /servers/{server_id}/action (suspend) # Intended scope(s): system, project "os_compute_api:os-suspend-server:suspend": "rule:admin_api or user_id:%(user_id)s"

4 8