- openstack-discuss - lists.openstack.org

(Openstack-nova or neutron error) in Canonical Openstack
by Adivya Singh 23 Nov '22

23 Nov '22

hi, What could be the reason for this error? Any guesses Went to status ERROR due to "Message: Build of instance 29ff9e37-e619-4406-adb8-200eec3aa1c7 aborted: Failed to allocate the network(s), not rescheduling., Code: 500" I am planning to restart libvirt services on compute node, may be Start the Nova services in compute node, neutron ovs services in compute node Maybe change the parameter in the plugin for the neutron time parameter from 10 sec to 60 sec. Any guesses, what more can I do more?

4 3

[neutron][tap-as-a-service][release] Deletion old branches of taas
by Lajos Katona 23 Nov '22

23 Nov '22

Hi, Tap-as-a-service is a Neutron stadium project, and recently we decided it is time to EOL old branches of it as we did for other stadium projects (see for example [1]). The branches which we would like to delete are: - stable/ocata - stable/pike - stable/queens - stable/rocky - stable/stein If you would like to keep these branches please answer back to this mail. As tap-as-a-service was moved in and out of stadium projects, it has no yaml files in releases repo before zed, I would like to ask the help of the release team to delete and tag these branches. I list here the hashes to have everything here as reference: - stable/ocata: 23536669c161be786185ecb6fb8831458476f74b - stable/pike: 0c974fe28b31453ab02eb597b4242f059b274c95 - stable/queens: 33f3e6d0432241e2846288291f1a8229c95b1425 - stable/rocky: 0eae0a540d16192c583232b8dfc574f233e60199 - stable/stein: 951390c12655f296460a3210c221da47f9cb5a3b [1]: https://review.opendev.org/c/openstack/releases/+/846188 Best wishes Lajos (lajoskatona)

1 0

ISO file as user-data
by Srinivasan T 23 Nov '22

23 Nov '22

Hi Team, I'm trying to understand if it is possible to pass an ISO file as user-data or config-drive while creating an instance. Ex., *openstack server create --image <my image> --flavor <my flavor> --user-data /path/to/myiso.iso --network <my network> --config-drive true <instance name>* Basically we need to mount & get the files in our ISO that is passed to the VM instance for initial configuration. When trying the above OpenStack CLI command with ISO as user-data, below error is thrown (where as plain text file works), *'utf8' codec can't decode byte 0xbb in position 32848: invalid start byte* Regards, Srini

1 0

[keystone] Weekly Meeting Cancelled
by Dave Wilde 22 Nov '22

22 Nov '22

Sorry for the late notice, but the weekly meeting is cancelled this week as I’m AFK for the U.S. holiday. Please let me know if you need anything and have a wonderful holiday if you’re celebrating. /Dave Sent from my iPad

1 0

Problem in freezer deploymentnt
by K Santhosh 22 Nov '22

22 Nov '22

Hai , I am Santhosh, I do facing a problem with freezer deploymentnt After the deployment of freezer . The freezer_scheduler container is continuously restarting in kolla openstack can you help me out with this freezer_scheduler container

2 1

Strange situation regarding Availability Zones
by Lennart van Gijtenbeek | Routz 22 Nov '22

22 Nov '22

3 3

[neutron] CI meeting 22.11 cancelled
by Slawek Kaplonski 22 Nov '22

22 Nov '22

Hi, I don't feel well today and I will not be able to chair neutron CI meeting. See You on the meeting next week. -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

Re: [neutron-dynamic-routing] BGPspeaker LOOP
by Roberto Bartzen Acosta 22 Nov '22

22 Nov '22

Thanks Sean. I believe that the os-ken driver is not coded to honor this premise because the below function can learn new paths from peer update messages. https://opendev.org/openstack/os-ken/src/branch/master/os_ken/services/prot… Em qua., 16 de nov. de 2022 às 09:14, Sean Mooney <smooney(a)redhat.com> escreveu: > On Wed, 2022-11-16 at 09:05 -0300, Roberto Bartzen Acosta wrote: > > Sorry for the mistake, I meant, the bgpspeaker should only "*advertise*!" > > and not "learn" the AS_PATHs via BGP. > yes that used to be the scope of that project to advertise only and not > learn > so i would geuss either that has change recently and they broke backward > compaitbly > or they have refactord it to use an external bgp speaker like frr and it > learns by default > > i dont really see anything here > https://github.com/openstack/neutron-dynamic-routing/commits/master > im not really familar with the internals of the project but i dont see any > code to learn routs form > > > https://github.com/openstack/neutron-dynamic-routing/blob/master/neutron_dy… > > it just has code for advertizing and withdrawing routes. > > > > > > > Em qua., 16 de nov. de 2022 às 08:57, Sean Mooney <smooney(a)redhat.com> > > escreveu: > > > > > On Wed, 2022-11-16 at 08:43 -0300, Roberto Bartzen Acosta wrote: > > > > Hey folks, > > > > > > > > Please, I have a question here, the bgpspeaker should only "learn" > and > > > not > > > > "advertise" the AS_PATHs via BGP, right? > > > > > > its been a while since i looked at it but in the past it did not > supprot > > > learning at all > > > > > > it just advertised the routes for the neutron netowrks > > > > > > > > > > > In my tests, I can see that it is learning routes from BGP neighbors. > > > This > > > > behavior can cause an AS_PATH loop because the bgpspeaker learns > back its > > > > own advertised routes, and I see a message like this in the logs: > > > > > > > > 2022-11-11 19:45:41.967 7220 ERROR bgpspeaker.peer [-] AS_PATH on > UPDATE > > > > message has loops. Ignoring this message: > > > > > > > > BGPUpdate(len=91,nlri=[],path_attributes=[BGPPathAttributeMpReachNLRI(afi=2,flags=144,length=46,next_hop='2001:db7:1::1',nlri=[IP6AddrPrefix(addr='2001:db9:1234::',length=64)],safi=1,type=14), > > > > BGPPathAttributeOrigin(flags=64,length=1,type=1,value=0), > > > > BGPPathAttributeAsPath(flags=80,length=10,type=2,value=[[65001, > > > > > > > > 65000]])],total_path_attribute_len=68,type=2,withdrawn_routes=[],withdrawn_routes_len=0) > > > > > > > > This can be fixed by suppressing the neighbor route advertisement > (using > > > > route-map export), but have I misunderstood how > neutron-dymanic-routing > > > > works or do we have a possible bug here? > > > > > > > > Regards > > > > > > > > > > > > > > -- _‘Esta mensagem é direcionada apenas para os endereços constantes no cabeçalho inicial. Se você não está listado nos endereços constantes no cabeçalho, pedimos-lhe que desconsidere completamente o conteúdo dessa mensagem e cuja cópia, encaminhamento e/ou execução das ações citadas estão imediatamente anuladas e proibidas’._ * **‘Apesar do Magazine Luiza tomar todas as precauções razoáveis para assegurar que nenhum vírus esteja presente nesse e-mail, a empresa não poderá aceitar a responsabilidade por quaisquer perdas ou danos causados por esse e-mail ou por seus anexos’.*

2 3

[barbican][release] Transition Queens, Rocky & Stein to EOL
by Grzegorz Grasza 22 Nov '22

22 Nov '22

Hi all, The barbican team no longer plans to maintain branches older than Train. The patch to mark these branches as EOL is in review [1], but according to the steps to achieve this [2], we need first to announce it. Please send your feedback by leaving a comment on the patch. I will unblock it next week. / Greg [1] https://review.opendev.org/c/openstack/releases/+/862515 [2] https://docs.openstack.org/project-team-guide/stable-branches.html#end-of-l…

1 0

[all][openstack-dev][ptls] Migrating devstack jobs to Jammy (Ubuntu LTS 22.04)
by Dmitriy Rabotyagov 22 Nov '22

22 Nov '22

Hi everyone, According to a 2023.1 community-wide goal [1], base-jobs including but not limited to devstack-minimal, devstack, devstack-ipv6, devstack-multinode, tox, will be switched from Ubuntu Focal (20.04) to Jammy (22.04). That will also bring python 3.10 as a default python interpreter for these jobs. Migration will affect most of the projects, so to make it smooth, we will split the process into the following steps: 1. Patches for switching base jobs to Jammy will be proposed and marked as WIP (Work In Progress). It will allow projects to check if their code is compatible without breaking gates. These patches are ready and you can check them out here [2] 2. All projects should ensure that the code is compatible and merge changes if required. To properly track and test these changes you should: * Create a DNM patch that will contain in its commit message: "Depends-On: https://review.opendev.org/c/openstack/tempest/+/861110" to consume new nodesets. You can check the sample patch for Nova below [3] * In case of any job failure due to Ubuntu 22.04 or Python 3.10, land requires changes to support this new distribution * If you have overridden nodeset for your project jobs, ensure that you also have jobs against Ubuntu 22.04 and these jobs set to voting. * Set topic to all related changes to "migrate-to-jammy" * Please use etherpad [4] for tracking patches, bug reports, current status, or any other activity related to this topic 3. On R-18, which is the first 2023.1 milestone that will happen on the 18th of November 2022, base-jobs patches mentioned in step 1 will be merged. Please ensure you have verified compatibility for your projects and landed the required changes if any were needed before this date otherwise, they might fail. Please, do not hesitate to raise any questions or concerns. [1] https://governance.openstack.org/tc/goals/selected/migrate-ci-jobs-to-ubunt… [2] https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/861116 https://review.opendev.org/c/openstack/tempest/+/861110 https://review.opendev.org/c/openstack/devstack/+/860795 [3] https://review.opendev.org/c/openstack/nova/+/861111 [4] https://etherpad.opendev.org/p/migrate-to-jammy

2 2