February 2021 - openstack-discuss

vscode/codium extension for Ansible users
by Sorin Sbarnea 25 Feb '21

25 Feb '21

If you happen to use vscode or codium and you end-up having to deal with a lot of Ansible content to edit, you may want to try the newer Ansible Language <https://marketplace.visualstudio.com/items?itemName=zbr.vscode-ansible> extension. For the moment it has two major features: - Display violations identified by ansible-lint, ansible own syntax check and yamllint inside problems tab. - Validate Ansible YAML files and provide auto-complete by using Ansible schemas. I am also working on adding schema validation for Zuul config files in the next version, it is bit outside "ansible" realm, but would likely prove useful too. -- /sorin

1 0

[TripleO] next irc meeting Tuesday Mar 02 @ 1400 UTC in #tripleo
by Marios Andreou 25 Feb '21

25 Feb '21

Reminder that the next TripleO irc meeting is: ** Tuesday 02 March at 1400 UTC in #tripleo ** ** https://wiki.openstack.org/wiki/Meetings/TripleO ** ** https://etherpad.opendev.org/p/tripleo-meeting-items ** Please add anything you want to highlight at https://etherpad.opendev.org/p/tripleo-meeting-items This can be recently completed things, ongoing review requests, blocking issues, or anything else tripleo you want to share. Our last meeting was on Feb 16 - you can find the logs there http://eavesdrop.openstack.org/meetings/tripleo/2021/tripleo.2021-02-16-14.… Hope you can make it on Tuesday, thanks, marios

1 0

RE: [kolla] Stack creation fails
by Braden, Albert 25 Feb '21

25 Feb '21

After doing some experiments I realize that this is unrelated to heat. If I manually build 20 volumes, 2 of them will be stuck in "creating" status. (openstack) [abraden@chrnc-dev-os-build-01 kolla_multinode]$ for x in {1..20}; do echo $x; openstack volume create --image 42d2a2db-d741-4080-8e8a-a713696de7c2 --size 50 atest$x;done (openstack) [abraden@chrnc-dev-os-build-01 kolla_multinode]$ ovl|grep atest | 1ab37b22-e06f-4360-83b5-e8272a906746 | atest20 | available | 50 | | | 641e8edf-26c1-4c7c-a02f-a199891adcb2 | atest19 | available | 50 | | | 7687e401-1ea1-4eb7-99d5-232ac33ea6eb | atest18 | available | 50 | | | 64c14f24-69c6-42f2-90ad-60f464c5fd3f | atest17 | available | 50 | | | 0bcd4e8e-4d53-4f74-9d7c-001e6aaeef88 | atest16 | creating | 50 | | | 9748a5ad-7a09-4f2f-9abd-12d69a27ab90 | atest15 | available | 50 | | | 85e84467-eef9-447f-9ba9-2545bef857ef | atest14 | available | 50 | | | c55c17c4-3471-4a06-8cc1-497a7f17ec72 | atest13 | available | 50 | | | 7d43cce3-fc4e-4697-9a8f-ca38226ca6cf | atest12 | available | 50 | | | f5a2062a-f6ee-4475-841e-d2efe5b9d4af | atest11 | available | 50 | | | 2b223e8a-c252-4306-8372-e2642b7fbf33 | atest10 | available | 50 | | | 5ce06f71-0169-4e9c-8133-7b1f826573c4 | atest9 | available | 50 | | | 1b40e297-3c54-4260-a4e7-535e183c8d74 | atest8 | available | 50 | | | e1ce1693-ba65-4f12-a85d-8b54e9259ef5 | atest7 | available | 50 | | | 0e6e5d95-a0c0-4daf-b21e-ebd5c8d6cb69 | atest6 | creating | 50 | | | 520d6912-535f-40e7-9da9-9f717f1eba2b | atest5 | available | 50 | | | 4d970654-e83f-4b6a-9c19-f917c4ec2825 | atest4 | available | 50 | | | ad77c9cd-e7bf-428b-8b01-c847fd818c9c | atest3 | available | 50 | | | c7d34554-467d-4312-9e81-5e8d00dcc7be | atest2 | available | 50 | | | 30ea4cdf-9d1e-471b-822b-1dc81e38ff96 | atest1 | available | 50 | | From: Braden, Albert <C-Albert.Braden(a)charter.com> Sent: Wednesday, February 24, 2021 1:40 PM To: openstack-discuss(a)lists.openstack.org Subject: [EXTERNAL] RE: [heat] [kolla] Stack creation fails CAUTION: The e-mail below is from an external source. Please exercise caution before opening attachments, clicking links, or following guidance. Turns out the failed key occurs when the previous keypair fails to delete with the stack, preventing the new keypair with the same name from being created, and I can fix it by manually deleting that keypair. I'm still looking for answers on [1]. From: Braden, Albert <C-Albert.Braden(a)charter.com<mailto:C-Albert.Braden@charter.com>> Sent: Wednesday, February 24, 2021 1:13 PM To: openstack-discuss(a)lists.openstack.org<mailto:openstack-discuss@lists.openstack.org> Subject: [EXTERNAL] [heat] [kolla] Stack creation fails CAUTION: The e-mail below is from an external source. Please exercise caution before opening attachments, clicking links, or following guidance. I'm using a heat template to try and build an Openstack cluster on VMs and it is failing in 2 different ways. It starts out fine for both: (openstack) [abraden@chrnc-dev-os-build-01 kolla_multinode]$ os stack create -t kolla_multinode.yaml upgrade-stack +---------------------+----------------------------------------------------------------------------------------+ | Field | Value | +---------------------+----------------------------------------------------------------------------------------+ | id | 7b4a49d2-0418-453a-abde-5e510b588b71 | | stack_name | upgrade-stack | | description | Deploy virtualized multi-node OpenStack and Ceph using kolla-ansible and ceph-ansible. | | | | | creation_time | 2021-02-23T21:17:02Z | | updated_time | None | | stack_status | CREATE_IN_PROGRESS | | stack_status_reason | Stack CREATE started | +---------------------+----------------------------------------------------------------------------------------+ Sometimes it stays in CREATE_IN_PROGRESS status for a long time, and when I look at volumes I see one or more volumes stuck in "creating" status [1]. If I set the stuck volumes to "error" status then heat retries and the cluster builds successfully. Other times the keypair fails. First it goes to DELETE_COMPLETE status and then to CREATE_FAILED [2], and the the stack goes to CREATE_FAILED status. When this happens no volumes are created, and I haven't found a workaround for this failure. Where should I be looking for the issue? Nothing in the log is jumping out at me. RMQ and keystone seem fine. Searching for the id of the failed stack or the stuck volume in /var/log/kolla/* doesn't find any errors or warnings. [1] volumes<https://paste.ubuntu.com/p/ZBhn7TQ2Hv/> [2] failed key<https://paste.ubuntu.com/p/gGwDRyT2Nd/> I apologize for the nonsense below. I have not been able to stop it from being attached to my external emails. The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited. E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.

1 0

[ops][victoria][trove] Problems running Trove
by DHilsbos＠performair.com 25 Feb '21

25 Feb '21

All; I've had a number of issues getting Trove to run for us, though I've worked through most of them (lots of network problems...). I now have the Nova instance starting, and it reaches out to the cluster's RabbitMQ instance. I'm getting these errors logged in /var/log/trove/trove-guestagent.log inside the Nova instance: ERROR trove.guestagent.volume '/dev/vdb' was not formatted.: oslo.concurrency.processutils.ProcessExecutionError: Unexpected error while running command. Command: sudo dumpe2fs /dev/vdb Exit code: 1 Stdout: "Couldn't find valid filesystem superblock.\n" Stderror: 'dumpe2fs: Bad magic number in super-block while trying to open /dev/vdb\n' Farther down, I get this: WARNING trove.guestagent.utils.docker [-] Failed to get container database: docker.errors.NotFound: 404 Client Error: Not Found ("No such container: database") There are a number of similar errors, all indicating that it can't get the Docker files from somewhere. I'm not sure if the first is an actual issue. Wouldn't the current Trove setup expect it's data storage add-on volume to be blank initially? The second suggests that I still have a network issue, most likely routing, as the Nova instance thinks it has 2 routes to the internet, but only one works. Any thoughts would be appreciated. Dominic L. Hilsbos, MBA Director - Information Technology Perform Air International Inc. DHilsbos(a)PerformAir.com www.PerformAir.com

3 5

[ALL] [infra] [QA] RHEL in upstream first party ci. aka RHEL for Open Source Infrastructure
by Sean Mooney 25 Feb '21

25 Feb '21

Hi o/ im not involed with this announcement that happened a few minutes ago but redhat has just annouched RHEL for Open Source Infrastructure https://www.redhat.com/en/blog/extending-no-cost-red-hat-enterprise-linux-o… it is avaiable for all opensouce communities to build infrastucture and and ci systems with. Before the the recent centos stream annoucnments we had discussed the posiblity of useing CentOS 8 in ci more widely in nova but we dropped that idea when teh recent changes happened. at first glance this looks like a program that would allow the first party ci to use RHEL instead of centos for our testing and development so i wanted to start a thread on this before we select our supported runtimes for xena. unfortuntelly there is a throwawy comment at the end of the press release that "We realize this program doesn’t cover situations where open source projects are using Public CI infrastructure provided by third-parties." im not sure if they are referring to things like travis or if it means we cannot build image ourselves and deploy them to vm on third praty clouds which donated infrastructure to the community to use to host the first party ci. that is something that would have to be clarifed with rosi-program(a)redhat.com to confirm but at the very least i wanted to highlihgt this to people so that we can at lest disucss if should/can utilize the program or not to provide rhel images in the first party ci or not. im not actully advocating for swtich jobs to rhel, it might make sense for tripleo or some other projects and it might be nice to have the ablity to run one or two jobs out of a set of jobs for a give porject on multiple operationg systems but thsi is more an attempt to evaluate if this is relevent to our comunity or not. regards sean.

2 1

[neutron] Drivers meeting 26.02.2021
by Slawek Kaplonski 25 Feb '21

25 Feb '21

Hi, We don't have any agenda for tomorrow's drivers meeting. Due to that and additional due to fact that we have recharge day in Red Hat let's cancel that meeting. See You on the meeting next week. Have a great weekend! -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[neutron][ipam] how is the first subnet determined by neutron?
by Tony Liu 25 Feb '21

25 Feb '21

Hi, When there are multiple subnets in a provider network, FIP is always allocated from the "first" subnet. What I see is that, the "first" subnet is the subnet added as the first. Or the first subnet from "openstack network show". Is that how subnets ordered, by creation order? Is there any way to change this order by manipulating, like subnets table in DB? I have two subnets, I want to allocate FIP from the second subnet, instead of the first, without clean them up and recreate them. Is that possible? Note, not allocate specific address, but auto allocation. Thanks! Tony

2 1

Security Interface for Ironic Discussion
by Leo McGann 24 Feb '21

24 Feb '21

Hi all, I just wanted to throw out there a discussion we will be having about Ironic and the creation of a new generic security interface and integration with Keylime as a means of node attestation tomorrow at 1pm EST. I have attached a link to the spec we are drafting and a google calendar invite to this email. https://review.opendev.org/c/openstack/ironic-specs/+/576718/20/specs/appro… https://calendar.google.com/event?action=TEMPLATE&tmeid=Nmx0azZqdTFxZ2QycjB… Thanks! Leo

3 5

[heat] [kolla] Stack creation fails
by Braden, Albert 24 Feb '21

24 Feb '21

I'm using a heat template to try and build an Openstack cluster on VMs and it is failing in 2 different ways. It starts out fine for both: (openstack) [abraden@chrnc-dev-os-build-01 kolla_multinode]$ os stack create -t kolla_multinode.yaml upgrade-stack +---------------------+----------------------------------------------------------------------------------------+ | Field | Value | +---------------------+----------------------------------------------------------------------------------------+ | id | 7b4a49d2-0418-453a-abde-5e510b588b71 | | stack_name | upgrade-stack | | description | Deploy virtualized multi-node OpenStack and Ceph using kolla-ansible and ceph-ansible. | | | | | creation_time | 2021-02-23T21:17:02Z | | updated_time | None | | stack_status | CREATE_IN_PROGRESS | | stack_status_reason | Stack CREATE started | +---------------------+----------------------------------------------------------------------------------------+ Sometimes it stays in CREATE_IN_PROGRESS status for a long time, and when I look at volumes I see one or more volumes stuck in "creating" status [1]. If I set the stuck volumes to "error" status then heat retries and the cluster builds successfully. Other times the keypair fails. First it goes to DELETE_COMPLETE status and then to CREATE_FAILED [2], and the the stack goes to CREATE_FAILED status. When this happens no volumes are created, and I haven't found a workaround for this failure. Where should I be looking for the issue? Nothing in the log is jumping out at me. RMQ and keystone seem fine. Searching for the id of the failed stack or the stuck volume in /var/log/kolla/* doesn't find any errors or warnings. [1] volumes<https://paste.ubuntu.com/p/ZBhn7TQ2Hv/> [2] failed key<https://paste.ubuntu.com/p/gGwDRyT2Nd/> I apologize for the nonsense below. I have not been able to stop it from being attached to my external emails. E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.

1 1

[security][security sig] No meeting tomorrow
by Gage Hugo 24 Feb '21

24 Feb '21

Hello everyone, The security SIG meeting for tomorrow is cancelled, we plan on meeting next week at the usual time. Thanks

1 0