From vinhducnguyen1708 at gmail.com Sun Aug 1 16:25:13 2021 From: vinhducnguyen1708 at gmail.com (Vinh Nguyen Duc) Date: Sun, 01 Aug 2021 16:25:13 -0000 Subject: VPNaaS for Openstack Message-ID: An HTML attachment was scrubbed... URL: From melwittt at gmail.com Sun Aug 1 17:23:13 2021 From: melwittt at gmail.com (melanie witt) Date: Sun, 1 Aug 2021 10:23:13 -0700 Subject: [nova][gate] nova-tox-functional-* jobs failing on master branch In-Reply-To: <9d29a21e-3d8c-bcc8-6c47-a0314ae6ad9c@gmail.com> References: <9d29a21e-3d8c-bcc8-6c47-a0314ae6ad9c@gmail.com> Message-ID: Update: it looks like the jobs are back to passing now (bug has to do with date/time and a missed time override). So, this is no longer urgent. Jobs should be passing as normal now. The patch below still needs review to prevent periodic problems with the date/time. Cheers, -melwitt On Sat, Jul 31, 2021 at 09:10 melanie witt wrote: > Hey all, > > The nova-tox-functional-* jobs on the openstack/nova master branch are > currently failing 100% of the time: > > > https://zuul.openstack.org/builds?job_name=nova-tox-functional-py38&branch=master > > This is due to another issue with time overrides (a lack thereof) in the > test_archive_task_logs functional tests. The same bug has happened in > the past and the fix is now known to have been unsuccessful: > > https://bugs.launchpad.net/nova/+bug/1934519 > > Another fix has been proposed here: > > https://review.opendev.org/c/openstack/nova/+/803106 > > Please hold your rechecks until the fix merges and apologies for the > trouble. > > -melwitt > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amy at demarco.com Sun Aug 1 21:14:30 2021 From: amy at demarco.com (Amy Marrich) Date: Sun, 1 Aug 2021 16:14:30 -0500 Subject: Diversity and Inclusion Meeting Reminder - OFTC Message-ID: The Diversity & Inclusion WG invites members of all OIF projects to attend our next meeting Monday Auguat 2nd, at 17:00 UTC in the #openinfra-diversity channel on OFTC. The agenda can be found at https://etherpad.openstack.org/p/ diversity-wg-agenda. Please feel free to add any topics you wish to discuss at the meeting. Thanks, Amy (apotz) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssbarnea at redhat.com Mon Aug 2 08:39:17 2021 From: ssbarnea at redhat.com (Sorin Sbarnea) Date: Mon, 2 Aug 2021 09:39:17 +0100 Subject: [TripleO] centos7 gate blocker (stable/train) please hold rechecks In-Reply-To: References: Message-ID: I would have wished to see some active involvement on the upstream pip ticket and maybe even a PR to address the problem. IMHO, spending time on CI workarounds may not prove the best approach, especially for issues like this. I would invite others to become more involved with upstream project that affect us, especially those working on older platforms (hint centos7 and python 3.6). As pip maintainers mentioned, they time does not worth working around python 3.6 bugs, especially as it is like two months away for EOL. Still, they expressed willingness to review PRs from others!!! IMHO add the extra environment variables to all systems and containers is likely to be 10x more time consuming than fixing the problem upstream. Cheers Sorin On Tue, 27 Jul 2021 at 16:38, Marios Andreou wrote: > this issue should now be resolved please reach out in the usual way if > there are further issues here > > thanks > > > > On Tue, Jul 27, 2021 at 10:01 AM Marios Andreou wrote: > > > > Hello tripleo o/ > > > > new gate blocker for centos7 hitting stable/train tripleo repos > > > https://zuul.opendev.org/t/openstack/builds?job_name=tripleo-ci-centos-7-content-provider > > > > bug is at https://bugs.launchpad.net/tripleo/+bug/1938079 - hitting > > stable/train (we only run c7 jobs there). > > > > investigation/resolution ongoing > > > > please hold rechecks for centos7 jobs. > > > > thank you > > > -- -- /zbr -------------- next part -------------- An HTML attachment was scrubbed... URL: From thierry at openstack.org Mon Aug 2 08:55:11 2021 From: thierry at openstack.org (Thierry Carrez) Date: Mon, 2 Aug 2021 10:55:11 +0200 Subject: [largescale-sig] Next meeting: Aug 4, 15utc Message-ID: <9806f127-8838-3ce5-74d2-b98c67408d99@openstack.org> Hi everyone, Our next Large Scale SIG meeting will be this Wednesday in #openstack-operators on OFTC IRC, at 15UTC. You can doublecheck how that time translates locally at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20210804T15 A number of topics have already been added to the agenda, including discussing the contents of our next OpenInfra.Live show. Feel free to add other topics to our agenda at: https://etherpad.openstack.org/p/large-scale-sig-meeting Regards, -- Thierry Carrez From marios at redhat.com Mon Aug 2 09:51:17 2021 From: marios at redhat.com (Marios Andreou) Date: Mon, 2 Aug 2021 12:51:17 +0300 Subject: [TripleO] centos7 gate blocker (stable/train) please hold rechecks In-Reply-To: References: Message-ID: On Mon, Aug 2, 2021 at 11:39 AM Sorin Sbarnea wrote: > > I would have wished to see some active involvement on the upstream pip ticket and maybe even a PR to address the problem. IMHO, spending time on CI workarounds may not prove the best approach, especially for issues like this. > > I would invite others to become more involved with upstream project that affect us, especially those working on older platforms (hint centos7 and python 3.6). > > As pip maintainers mentioned, they time does not worth working around python 3.6 bugs, especially as it is like two months away for EOL. Still, they expressed willingness to review PRs from others!!! > > IMHO add the extra environment variables to all systems and containers is likely to be 10x more time consuming than fixing the problem upstream. > I think it is hard to disagree with any of what you wrote here Sorin. As tripleo-ci ruck this sprint though you well know it's hard to dig enough into any one thing to deliver the kind of fix you're suggesting. I try and unblock us and then if i get really bored cos everything is working swimminly I may revisit for this kind of issue. If you are aware of a better way can you please go add some information onto the bug as a first step? Even if you don't someone else may then pick it up later? regards, marios > Cheers > Sorin > > On Tue, 27 Jul 2021 at 16:38, Marios Andreou wrote: >> >> this issue should now be resolved please reach out in the usual way if >> there are further issues here >> >> thanks >> >> >> >> On Tue, Jul 27, 2021 at 10:01 AM Marios Andreou wrote: >> > >> > Hello tripleo o/ >> > >> > new gate blocker for centos7 hitting stable/train tripleo repos >> > https://zuul.opendev.org/t/openstack/builds?job_name=tripleo-ci-centos-7-content-provider >> > >> > bug is at https://bugs.launchpad.net/tripleo/+bug/1938079 - hitting >> > stable/train (we only run c7 jobs there). >> > >> > investigation/resolution ongoing >> > >> > please hold rechecks for centos7 jobs. >> > >> > thank you >> >> > -- > -- > /zbr From jlibosva at redhat.com Mon Aug 2 10:17:19 2021 From: jlibosva at redhat.com (Jakub Libosvar) Date: Mon, 2 Aug 2021 12:17:19 +0200 Subject: [neutron] Bug deputy report July 26 - Aug 2 Message-ID: Hi, I was bug deputy for the last week, here is the report. There are couple of unassigned bugs, I would highlight the first on the list related to stable/ussuri functional tests failures that needs an assignee. Kuba Critical * [stable/ussuri] Functional jobs timeout, many tests with fixtures._fixtures.timeout.TimeoutException https://bugs.launchpad.net/neutron/+bug/1938262 Needs assignee * [fullstack] OOM mysql service https://bugs.launchpad.net/neutron/+bug/1938455 Patch up for review: https://review.opendev.org/c/openstack/neutron/+/802907 Assigned to Rodolfo High * L3 agent fails to process a DVR router external network change https://bugs.launchpad.net/neutron/+bug/1938191 Needs assignee * [ovn]Router scheduler failing for config "default_availability_zones" https://bugs.launchpad.net/neutron/+bug/1938261 Patch up for review: https://review.opendev.org/c/openstack/neutron/+/802665 * FT "test_restart_rpc_on_sighup_multiple_workers" failing recurrently https://bugs.launchpad.net/neutron/+bug/1938428 Patch up for review: https://review.opendev.org/c/openstack/neutron/+/802860 Assigned to Rodolfo * vpnaas problem:ipsec pluto not running centos 8 victoria wallaby https://bugs.launchpad.net/neutron/+bug/1938571 Needs assignee * ofctl timeouts lead to dvr-ha-multinode-full failures https://bugs.launchpad.net/neutron/+bug/1938685 Needs assignee Medium * Cannot delete vlan type network via network generic switch (ngs) https://bugs.launchpad.net/neutron/+bug/1938023 Needs assignee * Cannot adjust number of resources in one agent step during device handling https://bugs.launchpad.net/neutron/+bug/1938202 Assigned to Mitya Eremeev * [ovn]agents alive status error after restarting neutron server https://bugs.launchpad.net/neutron/+bug/1938478 Needs assignee * Typo in OVN SUPPORTED_DHCP_OPTS_MAPPING dictionary https://bugs.launchpad.net/neutron/+bug/1938569 Patch up for review: https://review.opendev.org/c/openstack/neutron/+/803037 Assigned to Eduardo Low * Misalignment with extra-dhcp-options between neutronclient & openstackclient https://bugs.launchpad.net/neutron/+bug/1938575 Needs assignee Wishlist * [networking-bgpvpn] Port events now use payload Patch up for review: https://review.opendev.org/c/openstack/networking-bgpvpn/+/802916 Assigned to Rodolfo * Missing Diffie-Hellman-Groups vpnaas: https://bugs.launchpad.net/neutron/+bug/1938284 Patch up for review: https://review.opendev.org/c/openstack/neutron-vpnaas/+/802714 From balazs.gibizer at est.tech Mon Aug 2 13:05:41 2021 From: balazs.gibizer at est.tech (Balazs Gibizer) Date: Mon, 02 Aug 2021 15:05:41 +0200 Subject: [nova][gate] nova-tox-functional-* jobs failing on master branch In-Reply-To: References: <9d29a21e-3d8c-bcc8-6c47-a0314ae6ad9c@gmail.com> Message-ID: On Sun, Aug 1, 2021 at 10:23, melanie witt wrote: > Update: it looks like the jobs are back to passing now (bug has to do > with date/time and a missed time override). So, this is no longer > urgent. > > Jobs should be passing as normal now. The patch below still needs > review to prevent periodic problems with the date/time. Thanks Melanie to taking care of it. I still think that your fix needs to land soon as we don't want to get hit by the same block just before the Feature Freeze a months from now. I will make sure that fix is reviewed. Cheers, gibi > > Cheers, > -melwitt > > On Sat, Jul 31, 2021 at 09:10 melanie witt wrote: >> Hey all, >> >> The nova-tox-functional-* jobs on the openstack/nova master branch >> are >> currently failing 100% of the time: >> >> https://zuul.openstack.org/builds?job_name=nova-tox-functional-py38&branch=master >> >> This is due to another issue with time overrides (a lack thereof) >> in the >> test_archive_task_logs functional tests. The same bug has happened >> in >> the past and the fix is now known to have been unsuccessful: >> >> https://bugs.launchpad.net/nova/+bug/1934519 >> >> Another fix has been proposed here: >> >> https://review.opendev.org/c/openstack/nova/+/803106 >> >> Please hold your rechecks until the fix merges and apologies for the >> trouble. >> >> -melwitt From jimmy at openstack.org Mon Aug 2 13:23:27 2021 From: jimmy at openstack.org (Jimmy McArthur) Date: Mon, 2 Aug 2021 08:23:27 -0500 Subject: [i18n] Zanata Message-ID: <359182F4-1B9F-4795-A9D6-AF074FFFDC23@getmailspring.com> Has Zanata been deprecated? I have a person trying to log in and they're unable. It's a new user that would like to contribute to the translation team. What's the best path to send them? Thank you, Jimmy -------------- next part -------------- An HTML attachment was scrubbed... URL: From eblock at nde.ag Mon Aug 2 13:32:51 2021 From: eblock at nde.ag (Eugen Block) Date: Mon, 02 Aug 2021 13:32:51 +0000 Subject: [i18n] Zanata In-Reply-To: <359182F4-1B9F-4795-A9D6-AF074FFFDC23@getmailspring.com> Message-ID: <20210802133251.Horde.QqhNEJeXCTihV2Qzl8BvZJK@webmail.nde.ag> Hi, I can login and browse successfully, no troubles for me. This is the URL I tried: https://translate.openstack.org/?dswid=6334 Regards, Eugen Zitat von Jimmy McArthur : > Has Zanata been deprecated? I have a person trying to log in and > they're unable. It's a new user that would like to contribute to the > translation team. What's the best path to send them? > > Thank you, > Jimmy From skaplons at redhat.com Mon Aug 2 15:05:20 2021 From: skaplons at redhat.com (Slawek Kaplonski) Date: Mon, 2 Aug 2021 17:05:20 +0200 Subject: [neutron][ops] VLAN Provider Network In-Reply-To: <0670B960225633449A24709C291A52525124C8B1@COM01.performair.local> References: <0670B960225633449A24709C291A52525124C8B1@COM01.performair.local> Message-ID: <20210802150520.sitqyjqs3r4cxlyz@p1.localdomain> Hi, On Mon, Jul 26, 2021 at 09:30:59PM +0000, DHilsbos at performair.com wrote: > All; > > We're using OpenStack Victoria, with OVS networking (no OVN). I'm having some problems with a VLAN provider network that I added to my OpenStack. I have other VLAN provider networks, that I based this one off of. > > Instances are getting the tap interfaces, but these interfaces are not getting IP addresses, and when a static IP is given, they can't ping either the DHCP address or the gateway address. Can instances with static IPs ping each other or it also don't works? > > I have checked the switch configuration, to verify the VLAN is bound appropriately. I rebooted the whole cluster to ensure the configuration change applied. > > Here's a snip our plugin.ini > [ml2_type_vlan] > network_vlan_ranges = provider_core:55:55,provider_core:64:64,... > > 64 works, 55, doesn't. > > I'm not seeing anything concerning in /var/log/openvswitch/ovs-vswitchd.log > > I'm sure it's something dumb, but I'm not seeing it. Please check also configuration of the OVS agent on the compute nodes where instances are configured and on the servers where DHCP agent's are running. > > Any suggestions for what else to look at? You should also check with tcpdump where packets are actually dropped. You can start checking on the physical interface in the host if there are packets with vlan_id 55 (the one which don't works). If packets are going out from compute node, You can check on Your switches and move to the next server. If packets are not on that physical interface, You should look in the Openflow rules configuration in the openvswitch on the compute node. > > Thank you, > > Dominic L. Hilsbos, MBA > Vice President - Information Technology > Perform Air International Inc. > DHilsbos at PerformAir.com > www.PerformAir.com > > -- Slawek Kaplonski Principal Software Engineer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From iurygregory at gmail.com Mon Aug 2 15:11:30 2021 From: iurygregory at gmail.com (Iury Gregory) Date: Mon, 2 Aug 2021 17:11:30 +0200 Subject: [ironic] Xena Mid-cycle In-Reply-To: References: Message-ID: Hello Ironicers! The midcycle will take place on August 23 (3-4PM UTC ), 24 (2-3PM UTC) and 25 (2-3PM) . Please add topics to the etherpad [1], if we don't have enough topics till 16th August we will probably remove some days. [1] https://etherpad.opendev.org/p/ironic-xena-midcycle Em ter., 20 de jul. de 2021 às 15:55, Iury Gregory escreveu: > Hello Ironicers! > > In our upstream meeting we decided we should do a virtual mid-cycle! If > you are interested please fill out the doodle[1] and add topics in the > etherpad[2]. > > Keep in mind we have contributors in many time zones, if you think we > should add more time windows, please let me know. Maybe we can have > multiple sessions each day so we can accommodate APAC TZ. > > I will close the doodle before our upstream meeting next week. > > [1] https://doodle.com/poll/mhh959u4s4rturxi > [2] https://etherpad.opendev.org/p/ironic-xena-midcycle > > -- > > > *Att[]'sIury Gregory Melo Ferreira * > *MSc in Computer Science at UFCG* > *Part of the ironic-core and puppet-manager-core team in OpenStack* > *Software Engineer at Red Hat Czech* > *Social*: https://www.linkedin.com/in/iurygregory > *E-mail: iurygregory at gmail.com * > -- *Att[]'sIury Gregory Melo Ferreira * *MSc in Computer Science at UFCG* *Part of the ironic-core and puppet-manager-core team in OpenStack* *Software Engineer at Red Hat Czech* *Social*: https://www.linkedin.com/in/iurygregory *E-mail: iurygregory at gmail.com * -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonykarera at gmail.com Mon Aug 2 16:17:19 2021 From: tonykarera at gmail.com (Karera Tony) Date: Mon, 2 Aug 2021 09:17:19 -0700 Subject: Masakari with Kolla-ansible Message-ID: Hello Team, I have deployed Openstack with Kolla-ansible on Centos8 and also enabled Masakari but I keep getting the error below in the masakari-hostmonitor.log on the controller nodes. Has anyone faced such a challenge ? 2021-08-02 18:08:52.409 7 WARNING masakarimonitors.hostmonitor.host_handler.handle_host [-] ' controller1.aos.rw' is unstable state on cluster.: oslo_concurrency.processutils.ProcessExecutionError: Unexpected error while running command. 2021-08-02 18:08:52.409 7 WARNING masakarimonitors.hostmonitor.host_handler.handle_host [-] hostmonitor skips monitoring hosts. 2021-08-02 18:09:57.476 7 WARNING masakarimonitors.hostmonitor.host_handler.handle_host [-] Corosync communication using 'ens33' is failed.: oslo_concurrency.processutils.ProcessExecutionError: Unexpected error while running command. Regards Tony Karera -------------- next part -------------- An HTML attachment was scrubbed... URL: From rguyett at datto.com Mon Aug 2 16:36:42 2021 From: rguyett at datto.com (Reid Guyett) Date: Mon, 2 Aug 2021 12:36:42 -0400 Subject: [swift] EC data left in old location after rebalance In-Reply-To: References: Message-ID: Hi, We have tried running the object-reconstructor on a couple servers with a new configuration file where handoffs_only = True a few times. We only ran on a couple servers to make sure it was working as desired and no handoffs would be left. Each time it looks like it shows that there are still handoffs remaining but running more times doesn't progress: ... object-reconstructor: x.x.y42:6200/d12/22520 Unexpected response: ":ERROR: 500 'ERROR: With :UPDATES: 1 failures to 0 successes'" object-reconstructor: x.x.y.46:6200/d14/15843 Unexpected response: ":ERROR: 500 'ERROR: With :UPDATES: 31 failures to 0 successes'" ... object-reconstructor: 153/1861 (8.22%) partitions reconstructed in 62.53s (2.45/sec, 11m remaining) object-reconstructor: Handoffs only mode still has handoffs remaining. Next pass will continue to revert handoffs. object-reconstructor: Object reconstruction complete (once). (1.04 minutes) We increased debugging logging for a little while and another message we are seeing a lot on the newer servers is: "local2.warning hostname object-server: ssync subrequest failed with 400: POST /device/partition/account/container/object" (Message contains actual data). Searching all devices in the cluster for the above object+fragment returns 1 fragment on 2 devices (same fragment in both). First copy is in the location where it should have been before rebalance and second copy is in the location it should be after rebalance. It does look like we have dark data as we have many fragments where they are the only part available like above. Would this affect the above? Also how did we get into a situation where we have only 1 fragment? None of the servers have been down for more than the time it takes for a reboot. We haven't reintroduced a bad disk with data. More background on our environment: The software team is expiring objects but we are not running the object-expirer. They are also deleting some objects but it seems that some of the fragments don't get deleted. We doubled the size of the cluster and the rebalance that brought these objects/fragments into view said we were moving 100% partitions. Reid On Mon, Jul 26, 2021 at 6:54 PM Matthew Oliver wrote: > > Yeah running it "once" would be a single cycle. Or you can watch logs, there should be something like: "Object reconstruction complete. (x minutes)" > > Usually you can also watch swift-recon and wait until the oldest completion timestamp was after the date you restarted the reconstructors, But it seems the reconstructor still isn't plumbed through reconstruction. I do have an old patch for that (https://review.opendev.org/c/openstack/swift/+/541141 opps 3 years old), I'll just dust it off and shepherd it through so it'll work upstream. > > Matt > > On Tue, Jul 27, 2021 at 6:29 AM Reid Guyett wrote: >> >> > handoffs_first for a reconstruction cycle to 2 >> Does this mean to set handoffs_first/handoffs_only = true and run the >> reconstructor twice in with `-o`? >> >> Thanks! >> >> Reid >> >> >> >> >> On Sun, Jul 25, 2021 at 9:02 PM Matthew Oliver wrote: >> > >> > You try enabling handoffs_first for a reconstruction cycle to 2, as this will prioritise those on handoffs. But make sure you turn it off as it'll stop normal reconstruction from happening. >> > >> > I am working on some code to build in better old primary handoff usage in the reconstructor but that code hasn't landed yet, and not sure when it will. >> > >> > Regards, >> > Matt >> > >> > On Tue, Jul 20, 2021 at 11:54 PM Reid Guyett wrote: >> >> >> >> Hello, >> >> >> >> We started using EC policies in a new cluster a few months ago and >> >> added more capacity. During the rebalance (started June 30), it seems >> >> that all the data was copied to the new locations but it didn't clean >> >> up the old locations. This was identified through our handoff >> >> monitoring. >> >> >> >> OS: Ubuntu 18.04 >> >> Swift: 2.17.1 >> >> >> >> Example: >> >> List of devices for partition >> >> >> >> ~$ swift-get-nodes /etc/swift/object-4.ring.gz -p 14242 >> >> ... removed ... >> >> Server:Port Device x.x.x.31:6031 d31 >> >> Server:Port Device x.x.x.66:6030 d30 >> >> Server:Port Device x.x.x.25:6029 d29 >> >> Server:Port Device x.x.x.33:6027 d27 >> >> Server:Port Device x.x.x.36:6020 d20 >> >> Server:Port Device x.x.x.29:6018 d18 >> >> Server:Port Device x.x.x.21:6033 d33 >> >> Server:Port Device x.x.x.27:6025 d25 >> >> Server:Port Device x.x.x.35:6022 d22 >> >> Server:Port Device x.x.x.39:6031 d31 >> >> Server:Port Device x.x.x.28:6032 d32 >> >> Server:Port Device x.x.x.23:6021 d21 >> >> Server:Port Device x.x.x.26:6022 d22 >> >> Server:Port Device x.x.x.34:6023 d23 >> >> Server:Port Device x.x.x.37:6019 d19 >> >> Server:Port Device x.x.x.30:6017 d17 >> >> Server:Port Device x.x.x.22:6027 d27 >> >> Server:Port Device x.x.x.24:6031 d31 >> >> Server:Port Device x.x.x.32:6032 d32 >> >> >> >> Partitions look to have the correct data on them: >> >> >> >> ~$ ssh root at x.x.x.31 "ls -lah ${DEVICE:-/srv/node*}/d31/objects-4/14242 | wc -l" >> >> 664 >> >> ~$ ssh root at x.x.x.66 "ls -lah ${DEVICE:-/srv/node*}/d30/objects-4/14242 | wc -l" >> >> 664 >> >> ~$ ssh root at x.x.x.25 "ls -lah ${DEVICE:-/srv/node*}/d29/objects-4/14242 | wc -l" >> >> 664 >> >> ~$ ssh root at x.x.x.33 "ls -lah ${DEVICE:-/srv/node*}/d27/objects-4/14242 | wc -l" >> >> 664 >> >> ~$ ssh root at x.x.x.36 "ls -lah ${DEVICE:-/srv/node*}/d20/objects-4/14242 | wc -l" >> >> 664 >> >> ~$ ssh root at x.x.x.29 "ls -lah ${DEVICE:-/srv/node*}/d18/objects-4/14242 | wc -l" >> >> 664 >> >> ~$ ssh root at x.x.x.21 "ls -lah ${DEVICE:-/srv/node*}/d33/objects-4/14242 | wc -l" >> >> 664 >> >> ~$ ssh root at x.x.x.27 "ls -lah ${DEVICE:-/srv/node*}/d25/objects-4/14242 | wc -l" >> >> 664 >> >> ~$ ssh root at x.x.x.35 "ls -lah ${DEVICE:-/srv/node*}/d22/objects-4/14242 | wc -l" >> >> 664 >> >> ~$ ssh root at x.x.x.39 "ls -lah ${DEVICE:-/srv/node*}/d31/objects-4/14242 | wc -l" >> >> 664 >> >> ~$ ssh root at x.x.x.28 "ls -lah ${DEVICE:-/srv/node*}/d32/objects-4/14242 | wc -l" >> >> 664 >> >> ~$ ssh root at x.x.x.23 "ls -lah ${DEVICE:-/srv/node*}/d21/objects-4/14242 | wc -l" >> >> 664 >> >> ~$ ssh root at x.x.x.26 "ls -lah ${DEVICE:-/srv/node*}/d22/objects-4/14242 | wc -l" >> >> 664 >> >> ~$ ssh root at x.x.x.34 "ls -lah ${DEVICE:-/srv/node*}/d23/objects-4/14242 | wc -l" >> >> 664 >> >> ~$ ssh root at x.x.x.37 "ls -lah ${DEVICE:-/srv/node*}/d19/objects-4/14242 | wc -l" >> >> 664 >> >> ~$ ssh root at x.x.x.30 "ls -lah ${DEVICE:-/srv/node*}/d17/objects-4/14242 | wc -l" >> >> 664 >> >> ~$ ssh root at x.x.x.22 "ls -lah ${DEVICE:-/srv/node*}/d27/objects-4/14242 | wc -l" >> >> 664 >> >> ~$ ssh root at x.x.x.24 "ls -lah ${DEVICE:-/srv/node*}/d31/objects-4/14242 | wc -l" >> >> 664 >> >> ~$ ssh root at x.x.x.32 "ls -lah ${DEVICE:-/srv/node*}/d32/objects-4/14242 | wc -l" >> >> 664 >> >> >> >> From one of the nodes that does not belong to the list above. This >> >> partition should not exist on this node after the rebalance. >> >> >> >> x.x.x.20:~# ls /srv/node/d28/objects-4/14242 | wc -l >> >> 627 >> >> >> >> The reconstructor is throwing a lot of these unexpected response >> >> errors in the logs. Manually running it from the node that should not >> >> have the partition, I can reproduce the error. x.x.y.0/24 is the >> >> replication network. >> >> >> >> x.x.x.20:~# swift-object-reconstructor /etc/swift/object-server.conf >> >> -d d28 -p 14242 -o -v >> >> object-reconstructor: x.x.y.42:6200/d30/14242 Unexpected response: >> >> ":ERROR: 500 'ERROR: With :UPDATES: 36 failures to 0 successes'" >> >> >> >> There looked to have been some partition locations cleaned up around >> >> July 11. Our expectation is that the old partition locations should be >> >> cleaned gradually since June 30 but we're not seeing that. >> >> I Was hoping for some ideas on what may be the problem (if any) and >> >> how we can make sure that the old partitions are cleaned up. >> >> >> >> Thanks, >> >> Reid >> >> >> >> >> From syedammad83 at gmail.com Tue Aug 3 07:07:19 2021 From: syedammad83 at gmail.com (Ammad Syed) Date: Tue, 3 Aug 2021 12:07:19 +0500 Subject: [wallaby][neutron] OVN ovs-system: deferred action limit reached, drop recirc action Message-ID: Hi, I am using openstack with OVN 20.12 and OVS 2.15.0 on ubuntu 20.04. I am using geneve tenant network and vlan provider network. I am continuously getting below messages in my dmesg logs continuously on compute node 1 only the other two compute nodes have no such messages. [275612.826698] openvswitch: ovs-system: deferred action limit reached, drop recirc action [275683.750343] openvswitch: ovs-system: deferred action limit reached, drop recirc action [276102.200772] openvswitch: ovs-system: deferred action limit reached, drop recirc action [276161.575494] openvswitch: ovs-system: deferred action limit reached, drop recirc action [276210.262524] openvswitch: ovs-system: deferred action limit reached, drop recirc action I have tried by reinstalling (OS everything) compute node 1 but still having same errors. Need your advice. Ammad -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbauza at redhat.com Tue Aug 3 08:21:19 2021 From: sbauza at redhat.com (Sylvain Bauza) Date: Tue, 3 Aug 2021 10:21:19 +0200 Subject: [nova][glance] nova-lvm job constantly fails on glance image upload Message-ID: Hi, I recently spotted a constant failure on the nova-lvm job [1] which seems to occur since July-19 at least, and which prevents us to merge all changes touching the nova-libvirt code section [2] Evidences show a glance image upload HTTP 502 failure when we want to snapshot [3] which corresponds to the Glance API getting issues with staged image data not found [4] Until we figure out how to solve this, recheck against nova changes touching nova/virt/libvirt/ module are useless. Any help would be appreciated on debugging the Glance failure, tho. Thanks, -Sylvain [1] https://zuul.openstack.org/builds?job_name=nova-lvm&branch=master [2] https://zuul.openstack.org/job/nova-lvm [3] https://zuul.openstack.org/build/a04b0d2e184a4d3e9c39bd6110b454ea/log/controller/logs/screen-n-cpu.txt?severity=4#12772 [4] https://zuul.openstack.org/build/a04b0d2e184a4d3e9c39bd6110b454ea/log/controller/logs/screen-g-api.txt?severity=3#3555 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbauza at redhat.com Tue Aug 3 08:48:21 2021 From: sbauza at redhat.com (Sylvain Bauza) Date: Tue, 3 Aug 2021 10:48:21 +0200 Subject: [nova][glance] nova-lvm job constantly fails on glance image upload In-Reply-To: References: Message-ID: On Tue, Aug 3, 2021 at 10:21 AM Sylvain Bauza wrote: > > Evidences show a glance image upload HTTP 502 failure when we want to > snapshot [3] which corresponds to the Glance API getting issues with staged > image data not found [4] > > To be clear, and as I said in the #openstack-nova channel, correlation isn't consequence. We are sure that the job is failing *because* Glance image upload fails, but we don't know yet *why*. In the meantime, I filed a bug https://bugs.launchpad.net/nova/+bug/1938765 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lyarwood at redhat.com Tue Aug 3 09:14:23 2021 From: lyarwood at redhat.com (Lee Yarwood) Date: Tue, 3 Aug 2021 10:14:23 +0100 Subject: [nova][glance] nova-lvm job constantly fails on glance image upload In-Reply-To: References: Message-ID: <20210803091423.x6ipdwykepcmyipy@lyarwood-laptop.usersys.redhat.com> On 03-08-21 10:48:21, Sylvain Bauza wrote: > On Tue, Aug 3, 2021 at 10:21 AM Sylvain Bauza wrote: > > > > > Evidences show a glance image upload HTTP 502 failure when we want to > > snapshot [3] which corresponds to the Glance API getting issues with staged > > image data not found [4] > > > > > To be clear, and as I said in the #openstack-nova channel, correlation > isn't consequence. We are sure that the job is failing *because* Glance > image upload fails, but we don't know yet *why*. > > > In the meantime, I filed a bug https://bugs.launchpad.net/nova/+bug/1938765 Looks like a simple case of us needing to increase GLANCE_LIMIT_IMAGE_SIZE_TOTAL to accommodate the RAW snapshots created by tests within the job. I've posted the following: zuul: Increase GLANCE_LIMIT_IMAGE_SIZE_TOTAL for nova-lvm https://review.opendev.org/c/openstack/nova/+/803322 Cheers, -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From puttmann at neozo.de Tue Aug 3 10:50:01 2021 From: puttmann at neozo.de (=?utf-8?B?QmrDtnJuIFB1dHRtYW5u?=) Date: Tue, 3 Aug 2021 10:50:01 +0000 Subject: [centos][kolla-ansible][wallaby][vpnaas] I need Help Message-ID: <438A7E90-28C7-4B89-98D0-A814D873CACE@neozo.de> Hi! We had similar problems while testing VPNaaS with Victoria in HA mode. The main takeaway was the following: - the path to the pidfile of the libreswan process in the driver is wrong. This causes the process.active check to always fail. diff --git a/neutron_vpnaas/services/vpn/device_drivers/libreswan_ipsec.py b/neutron_vpnaas/services/vpn/device_drivers/libreswan_ipsec.py index 90731f7a4..48b178d05 100644 --- a/neutron_vpnaas/services/vpn/device_drivers/libreswan_ipsec.py +++ b/neutron_vpnaas/services/vpn/device_drivers/libreswan_ipsec.py @@ -30,6 +30,9 @@ class LibreSwanProcess(ipsec.OpenSwanProcess): self._rootwrap_cfg = self._get_rootwrap_config() super(LibreSwanProcess, self).__init__(conf, process_id, vpnservice, namespace) + self.pid_path = os.path.join( + self.config_dir, 'var', 'run', 'pluto', 'pluto') + self.pid_file = '%s.pid' % self.pid_path def _ipsec_execute(self, cmd, check_exit_code=True, extra_ok_codes=None): """Execute ipsec command on namespace. - when deploying VPNaaS in HA mode, takeover fails as the standby node is missing the necessary configuration files for Libreswan. diff --git a/neutron_vpnaas/services/vpn/device_drivers/ipsec.py b/neutron_vpnaas/services/vpn/device_drivers/ipsec.py index 424c0eea0..7b1c96b3d 100644 --- a/neutron_vpnaas/services/vpn/device_drivers/ipsec.py +++ b/neutron_vpnaas/services/vpn/device_drivers/ipsec.py @@ -1077,12 +1077,19 @@ class IPsecDriver(device_drivers.DeviceDriver, metaclass=abc.ABCMeta): def report_status(self, context): status_changed_vpn_services = [] for process_id, process in list(self.processes.items()): - # NOTE(mnaser): It's not necessary to check status for processes - # of a backup L3 agent router = self.routers.get(process_id) - if router and router.router['ha'] and router.ha_state == 'backup': - LOG.debug("%s router in backup state, skipping", process_id) - continue + if router and router.router['ha']: + # NOTE(mnaser): It's not necessary to check status for processes + # of a backup L3 agent + if router.ha_state == 'backup': + LOG.debug("%s router in backup state, skipping", process_id) + continue + # When a ha takeover took place, router will initially not be active. Enable it now. + if router.ha_state == 'primary' and not process.active: + LOG.debug("%s is primary but not active. Activating.", process_id) + process.ensure_configs() + process.enable() + continue if not self.should_be_reported(context, process): continue previous_status = self.get_process_status_cache(process) With these patches applied, VPNaaS worked as expected, at least in Victoria. It seems, as Bodo already pointed out, that CentOS 8 is coming with Libreswan 4.4 which apparently dropped the "—use-netkey" parameter and now expects "--use-xfrm" So you could try to patch the corresponding driver files: diff --git a/neutron_vpnaas/services/vpn/device_drivers/ipsec.py b/neutron_vpnaas/services/vpn/device_drivers/ipsec.py index 424c0eea0..051719d40 100644 --- a/neutron_vpnaas/services/vpn/device_drivers/ipsec.py +++ b/neutron_vpnaas/services/vpn/device_drivers/ipsec.py @@ -647,7 +647,7 @@ class OpenSwanProcess(BaseSwanProcess): 'pluto', '--ctlbase', self.pid_path, '--ipsecdir', self.etc_dir, - '--use-netkey', + '--use-xfrm', '--uniqueids', '--nat_traversal', '--secretsfile', self.secrets_file] diff --git a/neutron_vpnaas/services/vpn/device_drivers/libreswan_ipsec.py b/neutron_vpnaas/services/vpn/device_drivers/libreswan_ipsec.py index 90731f7a4..b68e05f81 100644 --- a/neutron_vpnaas/services/vpn/device_drivers/libreswan_ipsec.py +++ b/neutron_vpnaas/services/vpn/device_drivers/libreswan_ipsec.py @@ -106,7 +106,7 @@ class LibreSwanProcess(ipsec.OpenSwanProcess): def start_pluto(self): cmd = ['pluto', - '--use-netkey', + '--use-xfrm', '--uniqueids'] if self.conf.ipsec.enable_detailed_logging: You could apply the patches to the device driver files on a local machine and copy the patched files into the corresponding containers via: docker cp /path/to/patched/{{ driver_file }} neutron_l3_agent:/usr/lib/python3.6/site-packages/neutron_vpnaas/services/vpn/device_drivers/{{ driver_file }} After that, restart the container. At least, that worked for us. Some commands, that proved quite useful for debugging the VPN stuff (please ignore if you already know this, just found this info very useful myself ;-) Get host for VPN tunnel: export PROJECT_ID=THE_PROJECT_ID ROUTER_ID=$(openstack --os-cloud THE_PROJECT_NAME vpn service list --long -f json | jq -r ".[] | select(.Project == \"${PROJECT_ID}\").Router") echo ${ROUTER_ID} openstack --os-cloud THE_PROJECT_NAME port list --router ${ROUTER_ID} --device-owner network:ha_router_replicated_interface -c binding_host_id -f value | sort -u Enable detailed logging in /etc/kolla/neutron-l3-agent/l3_agent.ini (restart container after changing this): [ipsec] enable_detailed_logging = True Logfile can now be found in neutron_l3_agent under /var/lib/neutron/ipsec/ROUTER_ID/log/ Get ipsec status (execute in neutron_l3_agent container): export ROUTER_ID=THE_ROUTER_ID ip netns exec qrouter-${ROUTER_ID} neutron-vpn-netns-wrapper --mount_paths="/etc:/var/lib/neutron/ipsec/${ROUTER_ID}/etc,/var/run:/var/lib/neutron/ipsec/${ROUTER_ID}/var/run" --rootwrap_config=/etc/neutron/rootwrap.conf --cmd="ipsec,whack,--status" ipsec.conf for router can be found under /var/lib/neutron/ipsec/ROUTER_ID/etc/ipsec.conf If you want to change the configuration directly (e.g. for testing cipher), the connection configuration needs to be reloaded: export ROUTER_ID=THE_ROUTER_ID ip netns exec qrouter-${ROUTER_ID} neutron-vpn-netns-wrapper --mount_paths="/etc:/var/lib/neutron/ipsec/${ROUTER_ID}/etc,/var/run:/var/lib/neutron/ipsec/${ROUTER_ID}/var/run" --rootwrap_config=/etc/neutron/rootwrap.conf --cmd="ipsec,auto,--replace,CONNECTION_ID" CONNECTION_ID can be found in ipsec.conf, e.g. conn 2b965b6b-2e03-4a89-acff-74cb56335f22 To initiate the tunnel after configuration change: export ROUTER_ID=THE_ROUTER_ID ip netns exec qrouter-${ROUTER_ID} neutron-vpn-netns-wrapper --mount_paths="/etc:/var/lib/neutron/ipsec/${ROUTER_ID}/etc,/var/run:/var/lib/neutron/ipsec/${ROUTER_ID}/var/run" --rootwrap_config=/etc/neutron/rootwrap.conf --cmd="ipsec,whack,--initiate,--name,CONNECTION_ID" To reread secrets: export ROUTER_ID=THE_ROUTER_ID ip netns exec qrouter-${ROUTER_ID} neutron-vpn-netns-wrapper --mount_paths="/etc:/var/lib/neutron/ipsec/${ROUTER_ID}/etc,/var/run:/var/lib/neutron/ipsec/${ROUTER_ID}/var/run" --rootwrap_config=/etc/neutron/rootwrap.conf --cmd="ipsec,auto,--rereadsecrets" Hope this is of some use. All the best and take care, Björn Puttmann -- NEOZO Cloud GmbH From lyarwood at redhat.com Tue Aug 3 11:09:22 2021 From: lyarwood at redhat.com (Lee Yarwood) Date: Tue, 3 Aug 2021 12:09:22 +0100 Subject: [nova][glance][grenade] nova-lvm job constantly fails on glance image upload In-Reply-To: <20210803091423.x6ipdwykepcmyipy@lyarwood-laptop.usersys.redhat.com> References: <20210803091423.x6ipdwykepcmyipy@lyarwood-laptop.usersys.redhat.com> Message-ID: <20210803110922.2wn7wuwg4lbfakk4@lyarwood-laptop.usersys.redhat.com> On 03-08-21 10:14:23, Lee Yarwood wrote: > On 03-08-21 10:48:21, Sylvain Bauza wrote: > > On Tue, Aug 3, 2021 at 10:21 AM Sylvain Bauza wrote: > > > > > > > > Evidences show a glance image upload HTTP 502 failure when we want to > > > snapshot [3] which corresponds to the Glance API getting issues with staged > > > image data not found [4] > > > > > > > > To be clear, and as I said in the #openstack-nova channel, correlation > > isn't consequence. We are sure that the job is failing *because* Glance > > image upload fails, but we don't know yet *why*. > > > > > > In the meantime, I filed a bug https://bugs.launchpad.net/nova/+bug/1938765 > > Looks like a simple case of us needing to increase > GLANCE_LIMIT_IMAGE_SIZE_TOTAL to accommodate the RAW snapshots created by > tests within the job. I've posted the following: > > zuul: Increase GLANCE_LIMIT_IMAGE_SIZE_TOTAL for nova-lvm > https://review.opendev.org/c/openstack/nova/+/803322 This is now blocked by the following grenade fix if any cores have time: Unblock Gate: create encryption type with right params https://review.opendev.org/c/openstack/grenade/+/803317 Thanks in advance! -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From smooney at redhat.com Tue Aug 3 12:02:45 2021 From: smooney at redhat.com (Sean Mooney) Date: Tue, 03 Aug 2021 13:02:45 +0100 Subject: stackalytics.com/api/1.0/activity In-Reply-To: References: Message-ID: <6bcc2e8ef14182325875063bf47f7531ea7cd9ce.camel@redhat.com> On Fri, 2021-07-30 at 09:12 +0100, Mark Goddard wrote: > This trips people up a lot. Is there someone who is able to retire > stackalytics.com, or redirect to stackalytics.io? it might make more sense to eventually move this to somethign hosted by opendev rather then relying on the good nature of the comunity to run it. stackalytics.io? was orginally intended to be tempory unitl stackalytics.com got fixed if i recall correctly. not that stackalytics.io? is not working great but if we want to continue to suppor thtis as a resouce for our comunity it would be nice if the foundation could host an offical instnace at say stackalytics.opendev.org or even just make that a cname/redirect to stackalytics.io? so we have a name we can just point to the working instance. > > On Fri, 30 Jul 2021 at 08:59, Lajos Katona wrote: > > > > Hi, > > There was some change few month ago and the link is stackalytics.io? > > https://www.stackalytics.io/api/1.0/activity?page_size=100 > > > > Regards > > Lajos (lajoskatona) > > > > Csatari, Gergely (Nokia - FI/Espoo) ezt írta (időpont: 2021. júl. 30., P, 8:54): > > > > > > Hi, > > > > > > > > > > > > We plan to use the API of stackalytics.com and we realized that the data it provides ([1]) is never more recent than March 2021. Does anyone know what is the reason for this? > > > > > > > > > > > > Thanks, > > > > > > Gergely > > > > > > > > > > > > 1: https://www.stackalytics.com/api/1.0/activity?page_size=100 > From fungi at yuggoth.org Tue Aug 3 12:29:53 2021 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 3 Aug 2021 12:29:53 +0000 Subject: stackalytics.com/api/1.0/activity In-Reply-To: <6bcc2e8ef14182325875063bf47f7531ea7cd9ce.camel@redhat.com> References: <6bcc2e8ef14182325875063bf47f7531ea7cd9ce.camel@redhat.com> Message-ID: <20210803122953.dyi2qeylufj6csio@yuggoth.org> On 2021-08-03 13:02:45 +0100 (+0100), Sean Mooney wrote: > it might make more sense to eventually move this to somethign > hosted by opendev rather then relying on the good nature of the > comunity to run it. [...] We did try at one time some years ago, but the service was unmanageable (required a restart to update any of the user data, which took hours and up to a day to re-query everything and come back online) and buggy (left hung SSH connections in its wake until the max sessions limit enforced for the Gerrit API kicked in and blocked it from reconnecting). We had volunteers lined up to solve these problems, and even some patches already proposed to start addressing them, but could not get the maintainers to review that work. Eventually we gave up, scrapped the idea, and tore down our server for it. Unless those issues have been addressed, we'd need new volunteers to get the service in shape... but even so, I'm hesitant to suggest OpenDev take on maintaining new services when we're actively trying to shed responsibilities so we can focus on improving services the community relies strongly on to get things done. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From anyrude10 at gmail.com Tue Aug 3 11:02:57 2021 From: anyrude10 at gmail.com (Anirudh Gupta) Date: Tue, 3 Aug 2021 16:32:57 +0530 Subject: [Kolla][Kolla-Ansible] Ironic Node Cleaning Failed In-Reply-To: References: Message-ID: Hi Radosław, I read somewhere in openstack-discuss forums that you are also using Ironic service in Kolla Ansible, Can you please go through my query chain and suggest some pointers to resolve the issue. I am unable to find any error logs except the ones I shared. Looking forward to hearing from you Regards Anirudh Gupta On Sat, Jul 31, 2021 at 1:59 AM Anirudh Gupta wrote: > Hi Dmitry > > Thanks for your time. > > My system is getting IP 20.20.20.10 which is in the range defined in > ironic_dnsmasq_dhcp_range field under globals.yml file. > > ironic_dnsmasq_dhcp_range: "20.20.20.10,20.20.20.100" > > And in the cleaning network (public1), the range defined is > 20.20.20.150-20.20.20.200 > > As per my understanding, these 2 ranges should be mutually exclusive. > > Please suggest if my understanding is not correct. > > Any suggestions what should I do to resolve this issue? > > Regards > Anirudh Gupta > > > On Sat, 31 Jul, 2021, 12:06 am Dmitry Tantsur, > wrote: > >> >> >> On Thu, Jul 29, 2021 at 6:05 PM Anirudh Gupta >> wrote: >> >>> Hi Team, >>> >>> In to the email below, I have some updated information:- >>> >>> Earlier the allocation range mentioned in "*ironic_dnsmasq_dhcp_range*" >>> in globals.yml had an overlapping range with the cleaning network, due to >>> which there was some issue in receiving the DHCP request >>> >>> After creating a cleaning network with a separate allocation range, I am >>> successfully getting IP allocated to my Baremetal Node >>> >>> - openstack subnet create subnet1 --network public1 --subnet-range >>> 20.20.20.0/24 --allocation-pool start=20.20.20.150,end=20.20.20.200 >>> --ip-version=4 --gateway=20.20.20.1 --dhcp >>> >>> >>> [image: image.png] >>> >>> After getting the IP, there is no further action on the node. From " >>> *clean_wait*", it goes into "*clean_failed*" state after around half an >>> hour. >>> >> >> The IP address is not from the cleaning range, it may come from >> inspection. You probably need to investigate your network topology, maybe >> use tcpdump. >> >> Unfortunately, I'm not fluent in Kolla to say if it can be a bug or not. >> >> Dmitry >> >> >>> >>> On verifying the logs, I could see the below error messages >>> >>> >>> - In */var/log/kolla/ironic/ironic-conductor.log*, we observed the >>> following error: >>> >>> ERROR ironic.conductor.utils [-] Cleaning for node >>> 3a56748e-a8ca-4dec-a332-ace18e6d494e failed. *Timeout reached while >>> cleaning the node. Please check if the ramdisk responsible for the cleaning >>> is running on the node. Failed on step {}.* >>> >>> >>> Note : For Cleaning the node, we have used the below images >>> >>> >>> >>> https://tarballs.openstack.org/ironic-python-agent/dib/files/ipa-centos8-master.kernel >>> >>> >>> https://tarballs.openstack.org/ironic-python-agent/dib/files/ipa-centos8-master.initramfs >>> >>> >>> - In /var/log/kolla/nova/nova-compute-ironic.log, we observed the >>> error >>> >>> ERROR nova.compute.manager [req-810ffedf-3343-471c-94db-85411984e6cc - - >>> - - -] No compute node record for host controller-ironic: >>> nova.exception_Remote.ComputeHostNotFound_Remote: Compute host >>> controller-ironic could not be found. >>> >>> >>> Can someone please help in this regard? >>> >>> Regards >>> Anirudh Gupta >>> >>> >>> On Tue, Jul 27, 2021 at 12:52 PM Anirudh Gupta >>> wrote: >>> >>>> Hi Team, >>>> >>>> We have deployed 2 node kolla ansible *12.0.0* in order to deploy >>>> openstack *wallaby* release. We have also enabled ironic in order to >>>> provision the bare metal nodes. >>>> >>>> On each server we have 3 nics >>>> >>>> - *eno1* - OAM for external connectivity and endpoint's publicURL >>>> - *eno2* - Mgmt for internal communication between various >>>> openstack services. >>>> - *ens2f0* - Data Interface >>>> >>>> >>>> Corresponding to this we have defined the following fields in >>>> globals.yml >>>> >>>> >>>> - kolla_base_distro: "centos" >>>> - kolla_install_type: "source" >>>> - openstack_release: "wallaby" >>>> - network_interface: "eno2" # MGMT >>>> interface >>>> - kolla_external_vip_interface: "eno1" # OAM Interface >>>> - kolla_internal_vip_address: "192.168.10.3" # MGMT Subnet free >>>> ip >>>> - kolla_external_vip_address: "10.0.1.136" # OAM subnet free >>>> IP >>>> - neutron_external_interface: "ens2f0" # Data Interface >>>> - enable_neutron_provider_networks: "yes" >>>> >>>> Note: Only relevant fields are being shown in this query >>>> >>>> Also, for ironic following fields have been defined in globals.yml >>>> >>>> - enable_ironic: "yes" >>>> - enable_ironic_neutron_agent: "{{ enable_neutron | bool and >>>> enable_ironic | bool }}" >>>> - enable_horizon_ironic: "{{ enable_ironic | bool }}" >>>> - ironic_dnsmasq_interface: "*ens2f0*" # Data >>>> interface >>>> - ironic_dnsmasq_dhcp_range: "20.20.20.10,20.20.20.100" >>>> - ironic_dnsmasq_boot_file: "pxelinux.0" >>>> - ironic_cleaning_network: "public1" >>>> - ironic_dnsmasq_default_gateway: "20.20.20.1" >>>> >>>> >>>> After successful deployment, a flat provider network with the name >>>> public1 is being created in openstack using the below commands: >>>> >>>> >>>> - openstack network create public1 --provider-network-type flat >>>> --provider-physical-network physnet1 >>>> - openstack subnet create subnet1 --network public1 --subnet-range >>>> 20.20.20.0/24 --allocation-pool start=20.20.20.10,end=20.20.20.100 >>>> --ip-version=4 --gateway=20.20.20.1 --dhcp >>>> >>>> >>>> Issue/Queries: >>>> >>>> >>>> - Is the configuration done in globals.yml correct or is there >>>> anything else that needs to be done in order to separate control and data >>>> plane traffic? >>>> >>>> >>>> - Also I have set automated_cleaning as "true" in ironic-conductor >>>> conatiner settings.But after creating the baremetal node, we run "node >>>> manage" command which runs successfully. Running "*openstack >>>> baremetal node provide "* command powers on the machine, >>>> sets the boot mode on Network Boot but no DHCP request for that particular >>>> mac is obtained on the controller. Is there anything I am missing that >>>> needs to be done in order to make ironic work? >>>> >>>> Note: I have also verified that the nic is PXE enabled in system >>>> configuration setting >>>> >>>> Regards >>>> Anirudh Gupta >>>> >>>> >>>> >> >> -- >> Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, >> Commercial register: Amtsgericht Muenchen, HRB 153243, >> Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael >> O'Neill >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 38285 bytes Desc: not available URL: From smooney at redhat.com Tue Aug 3 14:05:22 2021 From: smooney at redhat.com (Sean Mooney) Date: Tue, 03 Aug 2021 15:05:22 +0100 Subject: stackalytics.com/api/1.0/activity In-Reply-To: <20210803122953.dyi2qeylufj6csio@yuggoth.org> References: <6bcc2e8ef14182325875063bf47f7531ea7cd9ce.camel@redhat.com> <20210803122953.dyi2qeylufj6csio@yuggoth.org> Message-ID: <8979b6c24e32b9b4115a53bb91aa147bd9a22ef7.camel@redhat.com> On Tue, 2021-08-03 at 12:29 +0000, Jeremy Stanley wrote: > On 2021-08-03 13:02:45 +0100 (+0100), Sean Mooney wrote: > > it might make more sense to eventually move this to somethign > > hosted by opendev rather then relying on the good nature of the > > comunity to run it. > [...] > > We did try at one time some years ago, but the service was > unmanageable (required a restart to update any of the user data, > which took hours and up to a day to re-query everything and come > back online) and buggy (left hung SSH connections in its wake until > the max sessions limit enforced for the Gerrit API kicked in and > blocked it from reconnecting). We had volunteers lined up to solve > these problems, and even some patches already proposed to start > addressing them, but could not get the maintainers to review that > work. Eventually we gave up, scrapped the idea, and tore down our > server for it. > > Unless those issues have been addressed, we'd need new volunteers to > get the service in shape... but even so, I'm hesitant to suggest > OpenDev take on maintaining new services when we're actively trying > to shed responsibilities so we can focus on improving services the > community relies strongly on to get things done. ack capasity is a concern but coudl we host a simple redirect or cname so that if the serivce moves again we dont need to cahnge our messaging to contibutors. cnames would have ssl issues but a rediect would work to atleast land people on the correct verions that currently works. perhaps that is too much work for little benifit. honestly im not sure how much upstram porject actully use it anymore. i know that some compainies do use the data from stackalitics for incentives but honestly i think that actully harms the comunity as it can promote trivial or nuisance commits jus tto games stats. by nuisance commit i dont actully mean commits that dont fix anything i mean when the same typo fix is summit to evey repo or where commit are broken down in many one of small line count commits to fix effectivly the same thing that could have been grouped into one commit. there are some good uses of stakalitics like evaluating the healt of a project by its vilocity, diverity and such so i think its still valuable. but it can be abused too. From croeland at redhat.com Tue Aug 3 13:59:03 2021 From: croeland at redhat.com (Cyril Roelandt) Date: Tue, 3 Aug 2021 15:59:03 +0200 Subject: Automagically find LP bugs that should be marked as "Fix Released" Message-ID: Hello, I recently realized that some of my Launchpad bugs had a status different from "Fix Released" even though a fix had been released, and still appeared in my query of "open bugs". I wrote a simple script[1] to find bugs in a similar state: $ cd ~/openstack/glance_store/ # We assume the repository is up-to-date # Let's find the glance_store bugs fixed between 2.4.0 and 2.5.0 $ fix-released.sh 2.4.0 2.5.0 glance-store https://bugs.launchpad.net/glance-store/+bug/1915163 (Opinion) https://bugs.launchpad.net/glance-store/+bug/1915602 (New) In both these bug reports the following comment can be found: "This issue was fixed in the openstack/glance_store 2.5.0 release.", but the bug statuses have not been changed to "Fix Released". Comments are welcome, and I hope this helps. Cyril [1] https://gist.github.com/CyrilRoelandteNovance/1af6a5a23112ce444bda0ca2010d3465 From dtantsur at redhat.com Tue Aug 3 13:58:52 2021 From: dtantsur at redhat.com (Dmitry Tantsur) Date: Tue, 3 Aug 2021 15:58:52 +0200 Subject: [Kolla][Kolla-Ansible] Ironic Node Cleaning Failed In-Reply-To: References: Message-ID: Hi, You need to check the dnsmasq logs (there are two dnsmasqs: from neutron and from ironic-inspector). tcpdump may also help to determine where the packages are lost. Dmitry On Fri, Jul 30, 2021 at 10:29 PM Anirudh Gupta wrote: > Hi Dmitry > > Thanks for your time. > > My system is getting IP 20.20.20.10 which is in the range defined in > ironic_dnsmasq_dhcp_range field under globals.yml file. > > ironic_dnsmasq_dhcp_range: "20.20.20.10,20.20.20.100" > > And in the cleaning network (public1), the range defined is > 20.20.20.150-20.20.20.200 > > As per my understanding, these 2 ranges should be mutually exclusive. > > Please suggest if my understanding is not correct. > > Any suggestions what should I do to resolve this issue? > > Regards > Anirudh Gupta > > > On Sat, 31 Jul, 2021, 12:06 am Dmitry Tantsur, > wrote: > >> >> >> On Thu, Jul 29, 2021 at 6:05 PM Anirudh Gupta >> wrote: >> >>> Hi Team, >>> >>> In to the email below, I have some updated information:- >>> >>> Earlier the allocation range mentioned in "*ironic_dnsmasq_dhcp_range*" >>> in globals.yml had an overlapping range with the cleaning network, due to >>> which there was some issue in receiving the DHCP request >>> >>> After creating a cleaning network with a separate allocation range, I am >>> successfully getting IP allocated to my Baremetal Node >>> >>> - openstack subnet create subnet1 --network public1 --subnet-range >>> 20.20.20.0/24 --allocation-pool start=20.20.20.150,end=20.20.20.200 >>> --ip-version=4 --gateway=20.20.20.1 --dhcp >>> >>> >>> [image: image.png] >>> >>> After getting the IP, there is no further action on the node. From " >>> *clean_wait*", it goes into "*clean_failed*" state after around half an >>> hour. >>> >> >> The IP address is not from the cleaning range, it may come from >> inspection. You probably need to investigate your network topology, maybe >> use tcpdump. >> >> Unfortunately, I'm not fluent in Kolla to say if it can be a bug or not. >> >> Dmitry >> >> >>> >>> On verifying the logs, I could see the below error messages >>> >>> >>> - In */var/log/kolla/ironic/ironic-conductor.log*, we observed the >>> following error: >>> >>> ERROR ironic.conductor.utils [-] Cleaning for node >>> 3a56748e-a8ca-4dec-a332-ace18e6d494e failed. *Timeout reached while >>> cleaning the node. Please check if the ramdisk responsible for the cleaning >>> is running on the node. Failed on step {}.* >>> >>> >>> Note : For Cleaning the node, we have used the below images >>> >>> >>> >>> https://tarballs.openstack.org/ironic-python-agent/dib/files/ipa-centos8-master.kernel >>> >>> >>> https://tarballs.openstack.org/ironic-python-agent/dib/files/ipa-centos8-master.initramfs >>> >>> >>> - In /var/log/kolla/nova/nova-compute-ironic.log, we observed the >>> error >>> >>> ERROR nova.compute.manager [req-810ffedf-3343-471c-94db-85411984e6cc - - >>> - - -] No compute node record for host controller-ironic: >>> nova.exception_Remote.ComputeHostNotFound_Remote: Compute host >>> controller-ironic could not be found. >>> >>> >>> Can someone please help in this regard? >>> >>> Regards >>> Anirudh Gupta >>> >>> >>> On Tue, Jul 27, 2021 at 12:52 PM Anirudh Gupta >>> wrote: >>> >>>> Hi Team, >>>> >>>> We have deployed 2 node kolla ansible *12.0.0* in order to deploy >>>> openstack *wallaby* release. We have also enabled ironic in order to >>>> provision the bare metal nodes. >>>> >>>> On each server we have 3 nics >>>> >>>> - *eno1* - OAM for external connectivity and endpoint's publicURL >>>> - *eno2* - Mgmt for internal communication between various >>>> openstack services. >>>> - *ens2f0* - Data Interface >>>> >>>> >>>> Corresponding to this we have defined the following fields in >>>> globals.yml >>>> >>>> >>>> - kolla_base_distro: "centos" >>>> - kolla_install_type: "source" >>>> - openstack_release: "wallaby" >>>> - network_interface: "eno2" # MGMT >>>> interface >>>> - kolla_external_vip_interface: "eno1" # OAM Interface >>>> - kolla_internal_vip_address: "192.168.10.3" # MGMT Subnet free >>>> ip >>>> - kolla_external_vip_address: "10.0.1.136" # OAM subnet free >>>> IP >>>> - neutron_external_interface: "ens2f0" # Data Interface >>>> - enable_neutron_provider_networks: "yes" >>>> >>>> Note: Only relevant fields are being shown in this query >>>> >>>> Also, for ironic following fields have been defined in globals.yml >>>> >>>> - enable_ironic: "yes" >>>> - enable_ironic_neutron_agent: "{{ enable_neutron | bool and >>>> enable_ironic | bool }}" >>>> - enable_horizon_ironic: "{{ enable_ironic | bool }}" >>>> - ironic_dnsmasq_interface: "*ens2f0*" # Data >>>> interface >>>> - ironic_dnsmasq_dhcp_range: "20.20.20.10,20.20.20.100" >>>> - ironic_dnsmasq_boot_file: "pxelinux.0" >>>> - ironic_cleaning_network: "public1" >>>> - ironic_dnsmasq_default_gateway: "20.20.20.1" >>>> >>>> >>>> After successful deployment, a flat provider network with the name >>>> public1 is being created in openstack using the below commands: >>>> >>>> >>>> - openstack network create public1 --provider-network-type flat >>>> --provider-physical-network physnet1 >>>> - openstack subnet create subnet1 --network public1 --subnet-range >>>> 20.20.20.0/24 --allocation-pool start=20.20.20.10,end=20.20.20.100 >>>> --ip-version=4 --gateway=20.20.20.1 --dhcp >>>> >>>> >>>> Issue/Queries: >>>> >>>> >>>> - Is the configuration done in globals.yml correct or is there >>>> anything else that needs to be done in order to separate control and data >>>> plane traffic? >>>> >>>> >>>> - Also I have set automated_cleaning as "true" in ironic-conductor >>>> conatiner settings.But after creating the baremetal node, we run "node >>>> manage" command which runs successfully. Running "*openstack >>>> baremetal node provide "* command powers on the machine, >>>> sets the boot mode on Network Boot but no DHCP request for that particular >>>> mac is obtained on the controller. Is there anything I am missing that >>>> needs to be done in order to make ironic work? >>>> >>>> Note: I have also verified that the nic is PXE enabled in system >>>> configuration setting >>>> >>>> Regards >>>> Anirudh Gupta >>>> >>>> >>>> >> >> -- >> Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, >> Commercial register: Amtsgericht Muenchen, HRB 153243, >> Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael >> O'Neill >> > -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 38285 bytes Desc: not available URL: From anyrude10 at gmail.com Tue Aug 3 15:02:47 2021 From: anyrude10 at gmail.com (Anirudh Gupta) Date: Tue, 3 Aug 2021 20:32:47 +0530 Subject: [Kolla][Kolla-Ansible] Ironic Node Cleaning Failed In-Reply-To: References: Message-ID: Hi Dmitry, I might be wrong, but as per my understanding if there would be an issue in dnsmasq, then IP 20.20.20.10 would not have been assigned to the machine. TCPDUMP logs are as below: 20:16:58.938089 IP controller.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 312 20:17:02.765291 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 98:f2:b3:3f:72:e5 (oui Unknown), length 359 20:17:02.766303 IP controller.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 312 20:17:26.944378 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 98:f2:b3:3f:72:e5 (oui Unknown), length 347 20:17:26.944756 IP controller.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 312 20:17:30.763627 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 98:f2:b3:3f:72:e5 (oui Unknown), length 359 20:17:30.764620 IP controller.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 312 20:17:54.938791 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 98:f2:b3:3f:72:e5 (oui Unknown), length 347 Also the neutron dnsmasq logs and ironic inspector logs are attached in the mail. Regards Anirudh Gupta On Tue, Aug 3, 2021 at 7:29 PM Dmitry Tantsur wrote: > Hi, > > You need to check the dnsmasq logs (there are two dnsmasqs: from neutron > and from ironic-inspector). tcpdump may also help to determine where the > packages are lost. > > Dmitry > > On Fri, Jul 30, 2021 at 10:29 PM Anirudh Gupta > wrote: > >> Hi Dmitry >> >> Thanks for your time. >> >> My system is getting IP 20.20.20.10 which is in the range defined in >> ironic_dnsmasq_dhcp_range field under globals.yml file. >> >> ironic_dnsmasq_dhcp_range: "20.20.20.10,20.20.20.100" >> >> And in the cleaning network (public1), the range defined is >> 20.20.20.150-20.20.20.200 >> >> As per my understanding, these 2 ranges should be mutually exclusive. >> >> Please suggest if my understanding is not correct. >> >> Any suggestions what should I do to resolve this issue? >> >> Regards >> Anirudh Gupta >> >> >> On Sat, 31 Jul, 2021, 12:06 am Dmitry Tantsur, >> wrote: >> >>> >>> >>> On Thu, Jul 29, 2021 at 6:05 PM Anirudh Gupta >>> wrote: >>> >>>> Hi Team, >>>> >>>> In to the email below, I have some updated information:- >>>> >>>> Earlier the allocation range mentioned in "*ironic_dnsmasq_dhcp_range*" >>>> in globals.yml had an overlapping range with the cleaning network, due to >>>> which there was some issue in receiving the DHCP request >>>> >>>> After creating a cleaning network with a separate allocation range, I >>>> am successfully getting IP allocated to my Baremetal Node >>>> >>>> - openstack subnet create subnet1 --network public1 --subnet-range >>>> 20.20.20.0/24 --allocation-pool start=20.20.20.150,end=20.20.20.200 >>>> --ip-version=4 --gateway=20.20.20.1 --dhcp >>>> >>>> >>>> [image: image.png] >>>> >>>> After getting the IP, there is no further action on the node. From " >>>> *clean_wait*", it goes into "*clean_failed*" state after around half >>>> an hour. >>>> >>> >>> The IP address is not from the cleaning range, it may come from >>> inspection. You probably need to investigate your network topology, maybe >>> use tcpdump. >>> >>> Unfortunately, I'm not fluent in Kolla to say if it can be a bug or not. >>> >>> Dmitry >>> >>> >>>> >>>> On verifying the logs, I could see the below error messages >>>> >>>> >>>> - In */var/log/kolla/ironic/ironic-conductor.log*, we observed the >>>> following error: >>>> >>>> ERROR ironic.conductor.utils [-] Cleaning for node >>>> 3a56748e-a8ca-4dec-a332-ace18e6d494e failed. *Timeout reached while >>>> cleaning the node. Please check if the ramdisk responsible for the cleaning >>>> is running on the node. Failed on step {}.* >>>> >>>> >>>> Note : For Cleaning the node, we have used the below images >>>> >>>> >>>> >>>> https://tarballs.openstack.org/ironic-python-agent/dib/files/ipa-centos8-master.kernel >>>> >>>> >>>> https://tarballs.openstack.org/ironic-python-agent/dib/files/ipa-centos8-master.initramfs >>>> >>>> >>>> - In /var/log/kolla/nova/nova-compute-ironic.log, we observed the >>>> error >>>> >>>> ERROR nova.compute.manager [req-810ffedf-3343-471c-94db-85411984e6cc - >>>> - - - -] No compute node record for host controller-ironic: >>>> nova.exception_Remote.ComputeHostNotFound_Remote: Compute host >>>> controller-ironic could not be found. >>>> >>>> >>>> Can someone please help in this regard? >>>> >>>> Regards >>>> Anirudh Gupta >>>> >>>> >>>> On Tue, Jul 27, 2021 at 12:52 PM Anirudh Gupta >>>> wrote: >>>> >>>>> Hi Team, >>>>> >>>>> We have deployed 2 node kolla ansible *12.0.0* in order to deploy >>>>> openstack *wallaby* release. We have also enabled ironic in order to >>>>> provision the bare metal nodes. >>>>> >>>>> On each server we have 3 nics >>>>> >>>>> - *eno1* - OAM for external connectivity and endpoint's publicURL >>>>> - *eno2* - Mgmt for internal communication between various >>>>> openstack services. >>>>> - *ens2f0* - Data Interface >>>>> >>>>> >>>>> Corresponding to this we have defined the following fields in >>>>> globals.yml >>>>> >>>>> >>>>> - kolla_base_distro: "centos" >>>>> - kolla_install_type: "source" >>>>> - openstack_release: "wallaby" >>>>> - network_interface: "eno2" # MGMT >>>>> interface >>>>> - kolla_external_vip_interface: "eno1" # OAM >>>>> Interface >>>>> - kolla_internal_vip_address: "192.168.10.3" # MGMT Subnet free >>>>> ip >>>>> - kolla_external_vip_address: "10.0.1.136" # OAM subnet free >>>>> IP >>>>> - neutron_external_interface: "ens2f0" # Data Interface >>>>> - enable_neutron_provider_networks: "yes" >>>>> >>>>> Note: Only relevant fields are being shown in this query >>>>> >>>>> Also, for ironic following fields have been defined in globals.yml >>>>> >>>>> - enable_ironic: "yes" >>>>> - enable_ironic_neutron_agent: "{{ enable_neutron | bool and >>>>> enable_ironic | bool }}" >>>>> - enable_horizon_ironic: "{{ enable_ironic | bool }}" >>>>> - ironic_dnsmasq_interface: "*ens2f0*" # >>>>> Data interface >>>>> - ironic_dnsmasq_dhcp_range: "20.20.20.10,20.20.20.100" >>>>> - ironic_dnsmasq_boot_file: "pxelinux.0" >>>>> - ironic_cleaning_network: "public1" >>>>> - ironic_dnsmasq_default_gateway: "20.20.20.1" >>>>> >>>>> >>>>> After successful deployment, a flat provider network with the name >>>>> public1 is being created in openstack using the below commands: >>>>> >>>>> >>>>> - openstack network create public1 --provider-network-type flat >>>>> --provider-physical-network physnet1 >>>>> - openstack subnet create subnet1 --network public1 --subnet-range >>>>> 20.20.20.0/24 --allocation-pool start=20.20.20.10,end=20.20.20.100 >>>>> --ip-version=4 --gateway=20.20.20.1 --dhcp >>>>> >>>>> >>>>> Issue/Queries: >>>>> >>>>> >>>>> - Is the configuration done in globals.yml correct or is there >>>>> anything else that needs to be done in order to separate control and data >>>>> plane traffic? >>>>> >>>>> >>>>> - Also I have set automated_cleaning as "true" in ironic-conductor >>>>> conatiner settings.But after creating the baremetal node, we run "node >>>>> manage" command which runs successfully. Running "*openstack >>>>> baremetal node provide "* command powers on the machine, >>>>> sets the boot mode on Network Boot but no DHCP request for that particular >>>>> mac is obtained on the controller. Is there anything I am missing that >>>>> needs to be done in order to make ironic work? >>>>> >>>>> Note: I have also verified that the nic is PXE enabled in system >>>>> configuration setting >>>>> >>>>> Regards >>>>> Anirudh Gupta >>>>> >>>>> >>>>> >>> >>> -- >>> Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, >>> Commercial register: Amtsgericht Muenchen, HRB 153243, >>> Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael >>> O'Neill >>> >> > > -- > Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, > Commercial register: Amtsgericht Muenchen, HRB 153243, > Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael > O'Neill > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 38285 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ironic-inspector.log Type: application/octet-stream Size: 80891 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: neutron_dnsmasq.log Type: application/octet-stream Size: 2720 bytes Desc: not available URL: From gmann at ghanshyammann.com Tue Aug 3 15:04:39 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Tue, 03 Aug 2021 10:04:39 -0500 Subject: [all][tc] Technical Committee next weekly meeting on Aug 5th at 1500 UTC Message-ID: <17b0c8b93a0.bc608931193668.6127192075030493532@ghanshyammann.com> Hello Everyone, Technical Committee's next weekly meeting is scheduled for Aug 5th at 1500 UTC. If you would like to add topics for discussion, please add them to the below wiki page by Wednesday, Aug 4th, at 2100 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting -gmann From balazs.gibizer at est.tech Tue Aug 3 16:33:41 2021 From: balazs.gibizer at est.tech (Balazs Gibizer) Date: Tue, 03 Aug 2021 18:33:41 +0200 Subject: [nova][placement]Weekly meeting canceled on 10th of Aug Message-ID: <5CV9XQ.B89VWONPL1OO3@est.tech> Hi, As it seems many of us will be on PTO next week I cancel the weekly meeting. Cheers, gibi From jistr at redhat.com Tue Aug 3 16:49:58 2021 From: jistr at redhat.com (Jiri Stransky) Date: Tue, 3 Aug 2021 16:49:58 +0000 Subject: Migrating VM's In-Reply-To: <4cded1d64e53d5481e3e6cd592ec7bd5c0745394.camel@redhat.com> References: <1736702715.1155169.1627549499141.ref@mail.yahoo.com> <1736702715.1155169.1627549499141@mail.yahoo.com> <4cded1d64e53d5481e3e6cd592ec7bd5c0745394.camel@redhat.com> Message-ID: Hello folks, On Thu, Jul 29, 2021 at 6:24 PM Sean Mooney wrote: > > On Thu, 2021-07-29 at 15:28 +0000, Jiri Stransky wrote: > > OS Migrate might be worth a look, it's an Ansible collection. It does > > cold migration that does not require admin privileges (is runnable by > > tenants who are sufficiently technically savvy). > > > > default nova policy requrie admin right for cold migration > https://github.com/openstack/nova/blob/master/nova/policies/migrate_server.py#L25-L36 > > os-migrate is not useing nova migration apis its migrating the data and vms behind novas back. I used the term "cold migration" in the generic sense (migration of VMs while they're stopped), not in the particular "Nova cold migration" sense. While we're not using any migration-specific APIs (not sure if these would work *between* clouds, incl. copying Cinder volumes), we do still interact with OpenStack only through the normal REST APIs, we do not touch the backing MariaDB database directly. (So i do not see our approach as migrating "behind Nova's back".) > > > > > It can copy VMs with > > attached volumes. If boot disk copy is desired, then the destination > > instance will be created as boot-from-volume (the alternative option > > being re-imaging the instance from a pre-existing Glance image in the > > destination cloud, which is good for instances which store important > > data only in volumes, and can be rebuilt as in `openstack server > > rebuild`). Aside from migrating VMs, it should also help you migrate > > prerequisites for VMs, e.g. tenant networking resources or security > > groups. > > > > Perhaps even if you end up doing the migration on behalf of tenants, > > at least you wouldn't have to do it fully by hand, and you'd have > > something for the migration of attached volumes. > > os-migrate is a tool for moveing betweeen different cloud deployemnets isntead of doing a upgrade you deploy a parralel > cloud and then you use os-migrate to move workloads. +1. > > while that sound nice in practic it will break any automatin that site on top of openstack ans the workload will not > be moved to a new cloud so so if you have deployed yoru vms with heat or use an external VNFM you willl nolonger be abel to manage the vms. The data is copied to destination and a new VM is created using the data copy (assuming the two different migration modes i described in previous e-mails and in the blog). Floating IP addresses will also differ in the destination since generally different clouds have different FIP ranges. Whether this is a suitable approach or not depends per use case expectations and constraints. > > os migrate will not be transparent to the enduser > for example there keystone project id and user id will change. > this is because keysotne does not allow you to choose a uuid when create user or projects > https://docs.openstack.org/api-ref/identity/v3/index.html?expanded=create-user-detail#create-user > https://docs.openstack.org/api-ref/identity/v3/index.html?expanded=create-project-detail#create-project Indeed as we're recreating the resources using APIs rather than a direct DB access, IDs in the destination are different, but on the other hand going trough the normal REST APIs (rather than trying to force IDs by DB editing for example) considerably lowers the risk of creating inconsistent state of OpenStack services. Again, whether this is suitable or not depends per use case. I would say the migration procedure is transparent to the user (e.g. the resources are serialized into readable and editable YAML files, which are then used when creating resources in destination). > > while some resouces can be recarted with the same external ids resouces like flaover obviously need admin privladges. > nova lso caches the version of the imave and flavor the server was booted with. > > if you have modifed the flaovr or image extra spces since the vms were booted the vms that are create on the destination > may be diffeente then the souce and that may or may not break the newly created vm. Indeed this is something to watch out for if the src/dst flavors or images happen to differ somehow. I would not say differences are entirely disqualifying the migration, but care needs to be taken that workloads' requirements are still satisfied. > > so while it might be useful in limited cases you shoudl be aware the way it works is generally not supprotable in public cloud or by normal users > its a tool that a cloud operator can use. As i wrote earlier, the user needs to be somewhat technically savvy (most importantly, be able to work with Ansible and have at least high-level understanding of OpenStack), but admin privileges are not required unless you are trying to migrate resources that only admins can create (public images, users, projects, flavors, ...). We tested it with a cloud where we didn't have admin access. > > as a reulst it is portentially more dangourous then just a normal upgades as its more like that the vm abi and resouce uuids will change. Upgrade is less invasive on the level of individual resources, but migration allows you to scope risk better. In other words: when upgrading, the entire cloud is at some level of risk. When migrating tenant content with tenant credentials, only one tenant in the source and one tenant in the destination are being affected at a given time. Which approach is considered less dangerous will depend on use cases. > im also not sure if it will work with ironic i suspect not. I would hope at least the re-imaging mode of migration would work, but we did not test migrating instances deployed on Ironic nodes, so i'm also not sure. > > it also cannot handel all resouces for all service for example it cannot tansfer octaivia loadblanceser, barbical secreats, swift objecst or trove db instance or heat stacks to name but a few > service that are not supported. The supported resources are: users, projects, networks, subnets, routers, security groups, images, nova flavors and key pairs, VMs + attached volumes + FIP creation. Have a good day, Jirka From smooney at redhat.com Tue Aug 3 17:03:54 2021 From: smooney at redhat.com (Sean Mooney) Date: Tue, 03 Aug 2021 18:03:54 +0100 Subject: Migrating VM's In-Reply-To: References: <1736702715.1155169.1627549499141.ref@mail.yahoo.com> <1736702715.1155169.1627549499141@mail.yahoo.com> <4cded1d64e53d5481e3e6cd592ec7bd5c0745394.camel@redhat.com> Message-ID: On Tue, 2021-08-03 at 16:49 +0000, Jiri Stransky wrote: > Hello folks, > > On Thu, Jul 29, 2021 at 6:24 PM Sean Mooney wrote: > > > > On Thu, 2021-07-29 at 15:28 +0000, Jiri Stransky wrote: > > > OS Migrate might be worth a look, it's an Ansible collection. It does > > > cold migration that does not require admin privileges (is runnable by > > > tenants who are sufficiently technically savvy). > > > > > > > default nova policy requrie admin right for cold migration > > https://github.com/openstack/nova/blob/master/nova/policies/migrate_server.py#L25-L36 > > > > os-migrate is not useing nova migration apis its migrating the data and vms behind novas back. > > I used the term "cold migration" in the generic sense (migration of > VMs while they're stopped), not in the particular "Nova cold > migration" sense. While we're not using any migration-specific APIs > (not sure if these would work *between* clouds, incl. copying Cinder > volumes), we do still interact with OpenStack only through the normal > REST APIs, we do not touch the backing MariaDB database directly. (So > i do not see our approach as migrating "behind Nova's back".) do you run any process on the host or interact with any files on the host or libvirt/qemu in any way with the data migrator? if you are just using snapshots and grabign datat form glance or doing data copeis with tools in the vms i retract my statement but otherwise any interaction with the nova instance directly outside of the nova api would be out of band and behind novas back. > > > > > > > > > > It can copy VMs with > > > attached volumes. If boot disk copy is desired, then the destination > > > instance will be created as boot-from-volume (the alternative option > > > being re-imaging the instance from a pre-existing Glance image in the > > > destination cloud, which is good for instances which store important > > > data only in volumes, and can be rebuilt as in `openstack server > > > rebuild`). Aside from migrating VMs, it should also help you migrate > > > prerequisites for VMs, e.g. tenant networking resources or security > > > groups. > > > > > > Perhaps even if you end up doing the migration on behalf of tenants, > > > at least you wouldn't have to do it fully by hand, and you'd have > > > something for the migration of attached volumes. > > > > os-migrate is a tool for moveing betweeen different cloud deployemnets isntead of doing a upgrade you deploy a parralel > > cloud and then you use os-migrate to move workloads. > > +1. > > > > > while that sound nice in practic it will break any automatin that site on top of openstack ans the workload will not > > be moved to a new cloud so so if you have deployed yoru vms with heat or use an external VNFM you willl nolonger be abel to manage the vms. > > The data is copied to destination and a new VM is created using the > data copy (assuming the two different migration modes i described in > previous e-mails and in the blog). Floating IP addresses will also > differ in the destination since generally different clouds have > different FIP ranges. Whether this is a suitable approach or not > depends per use case expectations and constraints. > > > > > os migrate will not be transparent to the enduser > > for example there keystone project id and user id will change. > > this is because keysotne does not allow you to choose a uuid when create user or projects > > https://docs.openstack.org/api-ref/identity/v3/index.html?expanded=create-user-detail#create-user > > https://docs.openstack.org/api-ref/identity/v3/index.html?expanded=create-project-detail#create-project > > Indeed as we're recreating the resources using APIs rather than a > direct DB access, IDs in the destination are different, but on the > other hand going trough the normal REST APIs (rather than trying to > force IDs by DB editing for example) considerably lowers the risk of > creating inconsistent state of OpenStack services. Again, whether this > is suitable or not depends per use case. I would say the migration > procedure is transparent to the user (e.g. the resources are > serialized into readable and editable YAML files, which are then used > when creating resources in destination). > > > > > while some resouces can be recarted with the same external ids resouces like flaover obviously need admin privladges. > > nova lso caches the version of the imave and flavor the server was booted with. > > > > if you have modifed the flaovr or image extra spces since the vms were booted the vms that are create on the destination > > may be diffeente then the souce and that may or may not break the newly created vm. > > Indeed this is something to watch out for if the src/dst flavors or > images happen to differ somehow. I would not say differences are > entirely disqualifying the migration, but care needs to be taken that > workloads' requirements are still satisfied. > > > > > so while it might be useful in limited cases you shoudl be aware the way it works is generally not supprotable in public cloud or by normal users > > its a tool that a cloud operator can use. > > As i wrote earlier, the user needs to be somewhat technically savvy > (most importantly, be able to work with Ansible and have at least > high-level understanding of OpenStack), but admin privileges are not > required unless you are trying to migrate resources that only admins > can create (public images, users, projects, flavors, ...). We tested > it with a cloud where we didn't have admin access. > > > > > as a reulst it is portentially more dangourous then just a normal upgades as its more like that the vm abi and resouce uuids will change. > > Upgrade is less invasive on the level of individual resources, but > migration allows you to scope risk better. In other words: when > upgrading, the entire cloud is at some level of risk. When migrating > tenant content with tenant credentials, only one tenant in the source > and one tenant in the destination are being affected at a given time. > Which approach is considered less dangerous will depend on use cases. > > > im also not sure if it will work with ironic i suspect not. > > I would hope at least the re-imaging mode of migration would work, but > we did not test migrating instances deployed on Ironic nodes, so i'm > also not sure. > > > > > it also cannot handel all resouces for all service for example it cannot tansfer octaivia loadblanceser, barbical secreats, swift objecst or trove db instance or heat stacks to name but a few > > service that are not supported. > > The supported resources are: users, projects, networks, subnets, > routers, security groups, images, nova flavors and key pairs, VMs + > attached volumes + FIP creation. > > > Have a good day, > > Jirka > From franck.vedel at univ-grenoble-alpes.fr Tue Aug 3 17:30:50 2021 From: franck.vedel at univ-grenoble-alpes.fr (Franck VEDEL) Date: Tue, 3 Aug 2021 19:30:50 +0200 Subject: [centos][kolla-ansible][wallaby][vpnaas] I need Help In-Reply-To: <438A7E90-28C7-4B89-98D0-A814D873CACE@neozo.de> References: <438A7E90-28C7-4B89-98D0-A814D873CACE@neozo.de> Message-ID: Hello, thank you for all this work, all this information. I currently have a working Victoria Openstack, but, I'm sorry, I don't see how to apply these changes. I read the information, I reread, I look (google) for additional information to understand the commands that I do not know enough about (diff git for example ....), I do not know how to do it. I don't have ipsec.py and librewan_ipsec.py files (except in docker containers), so if I understand correctly: - get the patches (how? Thanks in advance) - copy the files to the containers (only neutron_l3_agent I think) - relaunch the container Is it this ? Thanks for the help, really Franck -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.urdin at binero.com Tue Aug 3 21:54:52 2021 From: tobias.urdin at binero.com (Tobias Urdin) Date: Tue, 3 Aug 2021 21:54:52 +0000 Subject: [nova][neutron][deployment-projects] Re secbug #1734320 In-Reply-To: References: Message-ID: <74976B41-1C9B-405F-9ACA-7C3CD5978E60@binero.com> Hello, Seems like there was no feedback here or did you figure anything out? I’m also very interested in the recommend approach to this. Best regards > On 18 Jun 2021, at 18:12, Radosław Piliszek wrote: > > Hello Folks! > > I am writing this because a recent patch proposed to DevStack [1] > mentioned "when using ml2/ovs vif isolation should always be used to > prevent cross tenant traffic during a live migration" which is related > to secbug #1734320 "Eavesdropping private traffic" [2]. > However, I've found that none of the publicly-available deployment > projects seem to be using ``isolate_vif``. [3] [4] > Should this be corrected? > > PS: I used the deployment-projects tag as a collective tag to avoid > mentioning all the projects (as it is too long to write :-) ). I hope > that relevant people see this if need be or someone passes the > information to them. For now, I am curious whether this should > actually be enforced by default with ML2/OVS. > > [1] https://review.opendev.org/c/openstack/devstack/+/796826 > [2] https://bugs.launchpad.net/neutron/+bug/1734320 > [3] https://codesearch.opendev.org/?q=%5Cbisolate_vif%5Cb&i=nope&files=&excludeFiles=&repos= > [4] https://github.com/search?p=1&q=isolate_vif&type=Code > > -yoctozepto > From skaplons at redhat.com Wed Aug 4 06:55:47 2021 From: skaplons at redhat.com (Slawek Kaplonski) Date: Wed, 4 Aug 2021 08:55:47 +0200 Subject: [nova][neutron][deployment-projects] Re secbug #1734320 In-Reply-To: References: Message-ID: <20210804065547.gjildotonzg4x6xg@p1.localdomain> Hi, On Fri, Jun 18, 2021 at 06:12:35PM +0200, Radosław Piliszek wrote: > Hello Folks! > > I am writing this because a recent patch proposed to DevStack [1] > mentioned "when using ml2/ovs vif isolation should always be used to > prevent cross tenant traffic during a live migration" which is related > to secbug #1734320 "Eavesdropping private traffic" [2]. > However, I've found that none of the publicly-available deployment > projects seem to be using ``isolate_vif``. [3] [4] > Should this be corrected? > > PS: I used the deployment-projects tag as a collective tag to avoid > mentioning all the projects (as it is too long to write :-) ). I hope > that relevant people see this if need be or someone passes the > information to them. For now, I am curious whether this should > actually be enforced by default with ML2/OVS. I think that Sean explained in the commit message of https://review.opendev.org/c/openstack/os-vif/+/612534/ why it defaults to False. And as it is os-vif's setting we can't do it "conditional" as os-vif don't knows about Neutron backend which is used really. So IMO deployment tools should maybe default this setting to True when ML2/OVS is used really. > > [1] https://review.opendev.org/c/openstack/devstack/+/796826 > [2] https://bugs.launchpad.net/neutron/+bug/1734320 > [3] https://codesearch.opendev.org/?q=%5Cbisolate_vif%5Cb&i=nope&files=&excludeFiles=&repos= > [4] https://github.com/search?p=1&q=isolate_vif&type=Code > > -yoctozepto > -- Slawek Kaplonski Principal Software Engineer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From jistr at redhat.com Wed Aug 4 08:45:14 2021 From: jistr at redhat.com (Jiri Stransky) Date: Wed, 4 Aug 2021 08:45:14 +0000 Subject: Migrating VM's In-Reply-To: References: <1736702715.1155169.1627549499141.ref@mail.yahoo.com> <1736702715.1155169.1627549499141@mail.yahoo.com> <4cded1d64e53d5481e3e6cd592ec7bd5c0745394.camel@redhat.com> Message-ID: On Tue, Aug 3, 2021 at 5:04 PM Sean Mooney wrote: > > On Tue, 2021-08-03 at 16:49 +0000, Jiri Stransky wrote: > > Hello folks, > > > > On Thu, Jul 29, 2021 at 6:24 PM Sean Mooney wrote: > > > > > > On Thu, 2021-07-29 at 15:28 +0000, Jiri Stransky wrote: > > > > OS Migrate might be worth a look, it's an Ansible collection. It does > > > > cold migration that does not require admin privileges (is runnable by > > > > tenants who are sufficiently technically savvy). > > > > > > > > > > default nova policy requrie admin right for cold migration > > > https://github.com/openstack/nova/blob/master/nova/policies/migrate_server.py#L25-L36 > > > > > > os-migrate is not useing nova migration apis its migrating the data and vms behind novas back. > > > > I used the term "cold migration" in the generic sense (migration of > > VMs while they're stopped), not in the particular "Nova cold > > migration" sense. While we're not using any migration-specific APIs > > (not sure if these would work *between* clouds, incl. copying Cinder > > volumes), we do still interact with OpenStack only through the normal > > REST APIs, we do not touch the backing MariaDB database directly. (So > > i do not see our approach as migrating "behind Nova's back".) > do you run any process on the host or interact with any files on the host or libvirt/qemu in any way with > the data migrator? if you are just using snapshots and grabign datat form glance or doing data copeis with tools in the > vms i retract my statement but otherwise any interaction with the nova instance directly outside of the nova api would be > out of band and behind novas back. We do not run any process on the compute hosts. OS Migrate workload migration must work without admin access, which also means no access to the compute hosts. There are tenant-owned VMs which facilitate direct data copying between the clouds, which we call "conversion hosts", and they do one thing on top of a pure copy: sparsification using virt-sparsify before the copying starts. This significantly speeds up copying of "empty space", and is only done on partitions where virt-sparsify can recognize a filesystem that can be sparsified. (We should probably have an option to disable this behavior, in case the user would be interested in a pure copy including e.g. leftovers of deleted files which are considered inaccessible empty space by the filesystem.) Have a good day, Jirka From smooney at redhat.com Wed Aug 4 12:02:10 2021 From: smooney at redhat.com (Sean Mooney) Date: Wed, 04 Aug 2021 13:02:10 +0100 Subject: Migrating VM's In-Reply-To: References: <1736702715.1155169.1627549499141.ref@mail.yahoo.com> <1736702715.1155169.1627549499141@mail.yahoo.com> <4cded1d64e53d5481e3e6cd592ec7bd5c0745394.camel@redhat.com> Message-ID: <16f3921afdaf1065fe98025dabd066a32f8e567d.camel@redhat.com> On Wed, 2021-08-04 at 08:45 +0000, Jiri Stransky wrote: > On Tue, Aug 3, 2021 at 5:04 PM Sean Mooney wrote: > > > > On Tue, 2021-08-03 at 16:49 +0000, Jiri Stransky wrote: > > > Hello folks, > > > > > > On Thu, Jul 29, 2021 at 6:24 PM Sean Mooney wrote: > > > > > > > > On Thu, 2021-07-29 at 15:28 +0000, Jiri Stransky wrote: > > > > > OS Migrate might be worth a look, it's an Ansible collection. It does > > > > > cold migration that does not require admin privileges (is runnable by > > > > > tenants who are sufficiently technically savvy). > > > > > > > > > > > > > default nova policy requrie admin right for cold migration > > > > https://github.com/openstack/nova/blob/master/nova/policies/migrate_server.py#L25-L36 > > > > > > > > os-migrate is not useing nova migration apis its migrating the data and vms behind novas back. > > > > > > I used the term "cold migration" in the generic sense (migration of > > > VMs while they're stopped), not in the particular "Nova cold > > > migration" sense. While we're not using any migration-specific APIs > > > (not sure if these would work *between* clouds, incl. copying Cinder > > > volumes), we do still interact with OpenStack only through the normal > > > REST APIs, we do not touch the backing MariaDB database directly. (So > > > i do not see our approach as migrating "behind Nova's back".) > > do you run any process on the host or interact with any files on the host or libvirt/qemu in any way with > > the data migrator? if you are just using snapshots and grabign datat form glance or doing data copeis with tools in the > > vms i retract my statement but otherwise any interaction with the nova instance directly outside of the nova api would be > > out of band and behind novas back. > > We do not run any process on the compute hosts. OS Migrate workload > migration must work without admin access, which also means no access > to the compute hosts. > > There are tenant-owned VMs which facilitate direct data copying > between the clouds, which we call "conversion hosts", and they do one > thing on top of a pure copy: sparsification using virt-sparsify before > the copying starts. This significantly speeds up copying of "empty > space", and is only done on partitions where virt-sparsify can > recognize a filesystem that can be sparsified. (We should probably > have an option to disable this behavior, in case the user would be > interested in a pure copy including e.g. leftovers of deleted files > which are considered inaccessible empty space by the filesystem.) ah ok that is much more supportable then in a production cloud. thanks for explaining. itought the data mover vm was basically connecting to the host to copy the qcows directly im glad to hear it is not. > > Have a good day, > > Jirka > From senrique at redhat.com Wed Aug 4 13:06:23 2021 From: senrique at redhat.com (Sofia Enriquez) Date: Wed, 4 Aug 2021 10:06:23 -0300 Subject: [cinder] Bug deputy report for week of 2021-04-08 Message-ID: Hello, This is a bug report from 2021-28-07 to 2021-04-08. We won't have the Cinder Bug Meeting today but we're welcome to attend the cinder mid cycle. Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting ----------------------------------------------------------------------------------------- Low - https://bugs.launchpad.net/cinder/+bug/1938869 "max_over_subscription_ratio set auto mode rbd backend will have a negative value". Unassigned. Incomplete - https://bugs.launchpad.net/cinder/+bug/1938488 "When restarting the c-bak service snapshot status is always backing-up". Unassigned Cheers, Sofi -- L. Sofía Enriquez she/her Software Engineer Red Hat PnT IRC: @enriquetaso @RedHat Red Hat Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: From thierry at openstack.org Wed Aug 4 16:06:29 2021 From: thierry at openstack.org (Thierry Carrez) Date: Wed, 4 Aug 2021 18:06:29 +0200 Subject: [largescale-sig] Next meeting: Aug 4, 15utc In-Reply-To: <9806f127-8838-3ce5-74d2-b98c67408d99@openstack.org> References: <9806f127-8838-3ce5-74d2-b98c67408d99@openstack.org> Message-ID: We held our meeting today. Small attendance, but we discussed the details of our next "large Scale OpenStack" OpenInfra.Live episode around software-defined supercomputers. Don't miss it on August 26! https://openinfra.dev/live/ You can read the meeting logs at: https://meetings.opendev.org/meetings/large_scale_sig/2021/large_scale_sig.2021-08-04-15.00.html Our next IRC meeting will be Sept 1, at 1500utc on #openstack-operators on OFTC. Regards, -- Thierry Carrez (ttx) From DHilsbos at performair.com Wed Aug 4 16:39:18 2021 From: DHilsbos at performair.com (DHilsbos at performair.com) Date: Wed, 4 Aug 2021 16:39:18 +0000 Subject: [ops][nova][victoria] Power State = Suspended? Message-ID: <0670B960225633449A24709C291A52525125F40D@COM01.performair.local> All; I had something unusual happen this morning; one of my VMs was showing "Suspended" under the Power State in the Horizon dashboard. I've never seen that. What does it mean? Any search that I do points me to a bunch of resources for Status Suspended. Thank you, Dominic L. Hilsbos, MBA Vice President - Information Technology Perform Air International Inc. DHilsbos at PerformAir.com www.PerformAir.com From smooney at redhat.com Wed Aug 4 17:37:04 2021 From: smooney at redhat.com (Sean Mooney) Date: Wed, 04 Aug 2021 18:37:04 +0100 Subject: [ops][nova][victoria] Power State = Suspended? In-Reply-To: <0670B960225633449A24709C291A52525125F40D@COM01.performair.local> References: <0670B960225633449A24709C291A52525125F40D@COM01.performair.local> Message-ID: <9e5c73c2a2b9513c8c44c19f6d370411c016b169.camel@redhat.com> On Wed, 2021-08-04 at 16:39 +0000, DHilsbos at performair.com wrote: > All; > > I had something unusual happen this morning; one of my VMs was showing "Suspended" under the Power State in the Horizon dashboard. > > I've never seen that. What does it mean? > > Any search that I do points me to a bunch of resources for Status Suspended. suspened is like hibernate in windows. in the libvirt driver we call libvirt managed_save api this pauses the guests, snapshots the guest ram and saves it to disk then stops the instance. so this frees the guest ram on the host and save it to a file so that we can recreate the vm and resume it as if nothing happened. nova also supports pause. pause is similar to suspend but much less invasive. pause jsut stops the execution of the guest cpus but the guest qemu process is still running. if you have pci passtough device when you use suspend the device are detach before its suspended  and then reattached when its resumed. if you use pause we dont need to do this since the dma regoins for the passthough devices are never touched. different virt dirver may or may not supprot pause/suspend and they may work differently. suspeedn is bascally supend the guest execution to disk where as pause is like you laptos sleep or suspend to ram. in a could env i dont really think either are that useful if im being honest and im not sure we woudl add them today if they did not really exits, generally if the vm is not running you should shleve it. from a schduler point of view pausign, suspending and stoping an insntce all use the same amount of resouces as a runnign instnace so form a billing perpsective public cloud will change you the same for all 4 states. shelve instance are only using disk space and floating ips so genrealy that will be reflected in the cost and it will be much cheaper on a public cloud to shelve an instnace. > > Thank you, > > Dominic L. Hilsbos, MBA > Vice President - Information Technology > Perform Air International Inc. > DHilsbos at PerformAir.com > www.PerformAir.com > > From DHilsbos at performair.com Wed Aug 4 17:48:23 2021 From: DHilsbos at performair.com (DHilsbos at performair.com) Date: Wed, 4 Aug 2021 17:48:23 +0000 Subject: [ops][nova][victoria] Power State = Suspended? In-Reply-To: <9e5c73c2a2b9513c8c44c19f6d370411c016b169.camel@redhat.com> References: <0670B960225633449A24709C291A52525125F40D@COM01.performair.local> <9e5c73c2a2b9513c8c44c19f6d370411c016b169.camel@redhat.com> Message-ID: <0670B960225633449A24709C291A52525125F6B6@COM01.performair.local> Sean; Thank you. Again, this was not Status. The VM was not suspended through OpenStack. Suspended showed up in the Power State. Normally, if I suspend a VM through OpenStack, Status = Suspended, Power State = Shut Down. In this case Status = Active, Power State = Supsended. Is it possible that the Windows OS inside the VM went into a Suspended state, and libvirt / kvm / qemu recognized that? Thank you, Dominic L. Hilsbos, MBA Vice President – Information Technology Perform Air International Inc. DHilsbos at PerformAir.com www.PerformAir.com -----Original Message----- From: Sean Mooney [mailto:smooney at redhat.com] Sent: Wednesday, August 4, 2021 10:37 AM To: Dominic Hilsbos; openstack-discuss at lists.openstack.org Subject: Re: [ops][nova][victoria] Power State = Suspended? On Wed, 2021-08-04 at 16:39 +0000, DHilsbos at performair.com wrote: > All; > > I had something unusual happen this morning; one of my VMs was showing "Suspended" under the Power State in the Horizon dashboard. > > I've never seen that. What does it mean? > > Any search that I do points me to a bunch of resources for Status Suspended. suspened is like hibernate in windows. in the libvirt driver we call libvirt managed_save api this pauses the guests, snapshots the guest ram and saves it to disk then stops the instance. so this frees the guest ram on the host and save it to a file so that we can recreate the vm and resume it as if nothing happened. nova also supports pause. pause is similar to suspend but much less invasive. pause jsut stops the execution of the guest cpus but the guest qemu process is still running. if you have pci passtough device when you use suspend the device are detach before its suspended  and then reattached when its resumed. if you use pause we dont need to do this since the dma regoins for the passthough devices are never touched. different virt dirver may or may not supprot pause/suspend and they may work differently. suspeedn is bascally supend the guest execution to disk where as pause is like you laptos sleep or suspend to ram. in a could env i dont really think either are that useful if im being honest and im not sure we woudl add them today if they did not really exits, generally if the vm is not running you should shleve it. from a schduler point of view pausign, suspending and stoping an insntce all use the same amount of resouces as a runnign instnace so form a billing perpsective public cloud will change you the same for all 4 states. shelve instance are only using disk space and floating ips so genrealy that will be reflected in the cost and it will be much cheaper on a public cloud to shelve an instnace. > > Thank you, > > Dominic L. Hilsbos, MBA > Vice President - Information Technology > Perform Air International Inc. > DHilsbos at PerformAir.com > www.PerformAir.com > > From erin at openstack.org Wed Aug 4 18:30:25 2021 From: erin at openstack.org (Erin Disney) Date: Wed, 4 Aug 2021 13:30:25 -0500 Subject: [Ironic] Users Needed! OpenInfra Live Opportunity Message-ID: <1F765F73-F22F-40A8-9466-471EA4B0DFB1@openstack.org> Hey All- We have an OpenInfra Live episode coming up next Thursday, August 12th at 14:00 UTC focused on Ironic. We will be kicking off the episode with a project overview and look at the development roadmap, then would like to feature companies running it in production to discuss their use cases, and wrap up the episode discussing FAQs regarding Ironic as a group. We currently have one user signed up but would love to add one or two more to the line up. If this is something you or your team would be interested in participating in, please reach out to me directly (erin at openstack.org). If the day/time doesn’t work but you are still willing to discuss your deployment, a pre-recorded video is an option as well. Thanks in advance! For more on OpenInfra Live, check out https://openinfra.dev/live. Erin Disney Event Marketing Open Infrastructure Foundation -------------- next part -------------- An HTML attachment was scrubbed... URL: From jimmy at openstack.org Wed Aug 4 22:07:42 2021 From: jimmy at openstack.org (Jimmy McArthur) Date: Wed, 4 Aug 2021 17:07:42 -0500 Subject: [i18n] Zanata In-Reply-To: <20210802133251.Horde.QqhNEJeXCTihV2Qzl8BvZJK@webmail.nde.ag> References: <20210802133251.Horde.QqhNEJeXCTihV2Qzl8BvZJK@webmail.nde.ag> Message-ID: <558A7030-199F-4EA2-B368-123BA00606C5@getmailspring.com> Apologies for the delayed response here, but the user I'm trying to help is indeed unable to log in to Zanata. We've set up a temporary password for them and I've tried myself and it's basically a loop. It says there is already an account with that name, but it won't let him log in, it keeps pointing him to the screen to create a new account. Here's a link to a video demonstrating the problem. I've tried myself with their credentials and get the same: https://drive.google.com/file/d/1iE0iWoYgTb5zk3SzP8oB5aYrtplRqlEm/view?usp=sharing CC'ing Han Guangyu, the user with the issue. Any help appreciated! Their company is looking to start contributing to i18n team, so it would be great if we could get them going :) Cheers, Jimmy On Aug 2 2021, at 8:32 am, Eugen Block wrote: > Hi, > > I can login and browse successfully, no troubles for me. This is the > URL I tried: > > https://translate.openstack.org/?dswid=6334 > Regards, > Eugen > > > Zitat von Jimmy McArthur : > > Has Zanata been deprecated? I have a person trying to log in and > > they're unable. It's a new user that would like to contribute to the > > translation team. What's the best path to send them? > > > > Thank you, > > Jimmy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From haiwu.us at gmail.com Wed Aug 4 22:11:57 2021 From: haiwu.us at gmail.com (hai wu) Date: Wed, 4 Aug 2021 17:11:57 -0500 Subject: how to update existing vm instances 'availability_zone' field in nova database 'instances' table Message-ID: Hi, How to update existing vm instances 'availability_zone' field in nova database 'instances' table? It turns out there are many VMs with default 'nova' availability zone, while the hypervisors are with another different target aggregate/availability zone name, thus live migration for these VMs are failing. The strange thing is that the 'OS-EXT-AZ:availability_zone' output from 'openstack server show VM_NAME' is showing these VMs are already with the target availibity_zone name. No idea why we have this inconsistency. Would it be ok to just update database table entry directly to set 'availility_zone' to different value for these VMs? Or there might be better alternatives I am not aware of? Thanks, Hai From gmann at ghanshyammann.com Wed Aug 4 22:31:35 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Wed, 04 Aug 2021 17:31:35 -0500 Subject: [all][tc] Technical Committee next weekly meeting on Aug 5th at 1500 UTC In-Reply-To: <17b0c8b93a0.bc608931193668.6127192075030493532@ghanshyammann.com> References: <17b0c8b93a0.bc608931193668.6127192075030493532@ghanshyammann.com> Message-ID: <17b134b20a2.e56950f2267174.414975498055011694@ghanshyammann.com> Hello Everyone, Below is the agenda for Tomorrow's TC meeting schedule at 1500 UTC in #openstack-tc IRC channel. -https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting == Agenda for tomorrow's TC meeting == * Roll call * Follow up on past action items * Project Skyline (diablo_rojo) * Gate health check (dansmith/yoctozepto) ** http://paste.openstack.org/show/jD6kAP9tHk7PZr2nhv8h/ * Xena Tracker ** https://etherpad.opendev.org/p/tc-xena-tracker * Wallaby testing runtime for centos8 vs centos8-stream ** https://review.opendev.org/q/I508eceb00d7501ffcfac73d7bc2272badb241494 ** centos8 does not work in stable/wallaby, for details, comments in https://review.opendev.org/c/openstack/devstack/+/803039 * PTG Planning ** https://etherpad.opendev.org/p/tc-yoga-ptg ** Plan the community session with live streaming (belmoreira) * Board informal Brainstorming sessions about "community health and resource management" * OpenStack newsletter items ** https://etherpad.opendev.org/p/newsletter-openstack-news * Open Reviews ** https://review.opendev.org/q/projects:openstack/governance+is:open -gmann ---- On Tue, 03 Aug 2021 10:04:39 -0500 Ghanshyam Mann wrote ---- > > Hello Everyone, > > Technical Committee's next weekly meeting is scheduled for Aug 5th at 1500 UTC. > > If you would like to add topics for discussion, please add them to the below wiki page by > Wednesday, Aug 4th, at 2100 UTC. > > https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting > > -gmann > > From cboylan at sapwetik.org Wed Aug 4 22:47:44 2021 From: cboylan at sapwetik.org (Clark Boylan) Date: Wed, 04 Aug 2021 15:47:44 -0700 Subject: [i18n] Zanata In-Reply-To: <558A7030-199F-4EA2-B368-123BA00606C5@getmailspring.com> References: <20210802133251.Horde.QqhNEJeXCTihV2Qzl8BvZJK@webmail.nde.ag> <558A7030-199F-4EA2-B368-123BA00606C5@getmailspring.com> Message-ID: <45982c97-d48b-46ce-ae8c-e5a0e832ee4e@www.fastmail.com> On Wed, Aug 4, 2021, at 3:07 PM, Jimmy McArthur wrote: > Apologies for the delayed response here, but the user I'm trying to > help is indeed unable to log in to Zanata. We've set up a temporary > password for them and I've tried myself and it's basically a loop. It > says there is already an account with that name, but it won't let him > log in, it keeps pointing him to the screen to create a new account. > > Here's a link to a video demonstrating the problem. I've tried myself > with their credentials and get the same: > https://drive.google.com/file/d/1iE0iWoYgTb5zk3SzP8oB5aYrtplRqlEm/view?usp=sharing > CC'ing Han Guangyu, the user with the issue. > > Any help appreciated! Their company is looking to start contributing > to i18n team, so it would be great if we could get them going :) Sorry, I missed this thread initially as it was was sent to the [i18n] label. The OpenDev/OpenStack infra team run the Zanata server, in the future sending email to service-discuss at lists.opendev.org is more likely to get eyeballs on this sort of thing. It also helps if people having problems reach out directly so that we don't resort to playing telephone and missing important information. Looking at the attached video, the error is that a user with the specified email address already exists. Looking at the database I see that there are records for this email address in the HAccount and HPerson tables but no openstackid openid is associated with this account in the HCredentials table. On closer inspection of the records that are present I note there is a password hash set, but there shouldn't be any password hashes if openstackid openid is used to login and create the account. I think what happened is somehow an account was created directly and not via openid. Now when attempting to login with openid there is a conflict because an account already has that email address. It would be good to understand how this happened if possible so that we can avoid it for the future. As far as fixing this account goes I suspect that if we delete the existing account then the next login attempt will be able to successfully create a new account with the associated openid. I don't know that we've ever done this before so coordinating this deletion when login can be reattempted is a good idea. Finally, it is worth noting that the translation tooling needs help, not just the translations themselves. Unfortunately the software we are using for this is no longer maintained and ideally needs to be replaced. > > Cheers, > Jimmy > > > On Aug 2 2021, at 8:32 am, Eugen Block wrote: > > Hi, > > > > I can login and browse successfully, no troubles for me. This is the > > URL I tried: > > > > https://translate.openstack.org/?dswid=6334 > > > > Regards, > > Eugen > > > > > > Zitat von Jimmy McArthur : > > > > > Has Zanata been deprecated? I have a person trying to log in and > > > they're unable. It's a new user that would like to contribute to the > > > translation team. What's the best path to send them? > > > > > > Thank you, > > > Jimmy From tonyppe at gmail.com Thu Aug 5 06:22:46 2021 From: tonyppe at gmail.com (Tony Pearce) Date: Thu, 5 Aug 2021 14:22:46 +0800 Subject: [magnum] [kolla-ansible] [kayobe] [Victoria] Message-ID: Testing out Kubernetes with Magnum project, deployed via kayobe on Victoria we have deployed an auto scaling cluster and have run into a problem and I'm not sure how to proceed. I understand that the cluster tried to scale up but the openstack project did not have enough CPU resources to accommodate it (error= Quota exceeded for cores: Requested 4, but already used 20 of 20 cores). So the situation is that the cluster shows "healthy" and "UPDATE_FAILED" but also kubectl commands are failing [1]. What is required to return the cluster back to a working status at this point? I have tried: - cluster resize to reduce number of workers - cluster resize to increase number of workers after increasing project quota - cluster resize and maintaining the same number of workers When trying any of the above, horizon shows an immediate error "Unable to resize given cluster" but magnum logs and heat logs do not show any log update at all at that time. - using "check stack" and resume stack in the stack horizon menu gives this error [2] Investigating the kubectl issue, it was noted that some services had failed on the master node [3]. Manual start as well as reboot the node did not bring up the services. Unfortunately I dont have ssh access to the master and no further information has been forthcoming with regards to logs for those service failures so I am unable to provide anything around that here. I found this link [4] so I decided to delete the master node then run "check" cluster again but the check cluster just fails in the same way except this time it fails saying that it cannot find the master [5] while the previous error was that it could not find a node. Ideally I would prefer to recover the cluster - whether this is still possible I am unsure. I can probably recreate this scenario again. What steps should be performed in this case to restore the cluster? [1] kubectl get no Error from server (Timeout): the server was unable to return a response in the time allotted, but may still be processing the request (get nodes) [2] Resource CHECK failed: ["['NotFound: resources[4].resources.kube-minion: Instance None could not be found. (HTTP 404) (Request-ID: req-6069ff6a-9eb6-4bce-bb25-4ef001ebc428)']. 'CHECK' not fully supported (see resources)"] [3] [systemd] Failed Units: 3 etcd.service heat-container-agent.service logrotate.service [4] https://bugzilla.redhat.com/show_bug.cgi?id=1459854 [5] ["['NotFound: resources.kube_masters.resources[0].resources.kube-master: Instance c6185e8e-1a98-4925-959b-0a56210b8c9e could not be found. (HTTP 404) (Request-ID: req-bdfcc853-7dbb-4022-9208-68b1ab31008a)']. 'CHECK' not fully supported (see resources)"]. Kind regards, Tony Pearce -------------- next part -------------- An HTML attachment was scrubbed... URL: From skaplons at redhat.com Thu Aug 5 07:35:31 2021 From: skaplons at redhat.com (Slawek Kaplonski) Date: Thu, 05 Aug 2021 09:35:31 +0200 Subject: [neutron] Drivers team meeting - agenda for Friday 05.08.2021 Message-ID: <12064109.8hArY157x0@p1> Hi, Agenda for our tomorrow's drivers meeting is at [1]. We have one RFE to discuss: https://bugs.launchpad.net/neutron/+bug/1936408 - [RFE] Neutron quota change should check available existing resources [1] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers -- Slawek Kaplonski Principal Software Engineer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From ssbarnea at redhat.com Thu Aug 5 08:16:29 2021 From: ssbarnea at redhat.com (Sorin Sbarnea) Date: Thu, 5 Aug 2021 09:16:29 +0100 Subject: gerrit no longer lading from iphone In-Reply-To: References: Message-ID: Mystery sorted: 1blocker ad filter extension was crashing mobile safari. I reported it to them and whitelisted the domain. Bit weird as we do not do any tracking on gerrit. In anyone has a similar problem: remember to disable all extensions. Apparently that affected the private mode as well. On Mon, 26 Jul 2021 at 00:30, Ian Wienand wrote: > On Sun, Jul 25, 2021 at 05:48:54PM +0100, Sorin Sbarnea wrote: > > I am wondering if something was changed on our gerrit deployment recently > > as it seems to no longer load on ios safari. > > I just tested iOS/safari and it works for me. Also the gerrit logs > show plenty of hits with 'Mobile Safari' in it. > > The gerrit server did recently move as announced in several places [1]. > > So far we have resolved issues which have turned out to be client side > issues such as old DNS overrides and incorrectly configured firewalls. > > The server is in a new provider, and it's not impossible there are > communication issues between networks. However we'd need details such > as IP addresses to see if you're making it to the server or not. If > you'd understandably not like to broadcast all your network details > here, you can send mail with details to > service-incident at lists.opendev.org and we can investigate further. > > -i > > [1] > http://lists.opendev.org/pipermail/service-discuss/2021-July/000263.html > > -- -- /zbr -------------- next part -------------- An HTML attachment was scrubbed... URL: From skaplons at redhat.com Thu Aug 5 09:50:46 2021 From: skaplons at redhat.com (Slawek Kaplonski) Date: Thu, 05 Aug 2021 11:50:46 +0200 Subject: [neutron][stable] Nominate Lajos Katona to the neutron-stable-maint team Message-ID: <4154938.lVMuQLOT2H@p1> Hi, I would like to nominate Lajos Katona as a Neutron stable core reviewer. Lajos is core in Neutron since long time. He is maintaining many stadium projects as well as he is very active in the main Neutron project. He helps us a lot with keeping stable branches healthy (especially for stadium projects, but not only). During that time he has proven already his knowledge about Neutron and Neutron stadium projects as well as knowledge of the stable branches rules. I will keep this nomination open for about 1 week. After that if there will be no votes agains, I will ask stable-maint-core team to add Lajos to the neutron-stable-maint team. -- Slawek Kaplonski Principal Software Engineer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From skaplons at redhat.com Thu Aug 5 10:20:28 2021 From: skaplons at redhat.com (Slawek Kaplonski) Date: Thu, 05 Aug 2021 12:20:28 +0200 Subject: [networking-bgpvpn][networking-bagpipe] Propose to EOL stable/pike and stable/queens Message-ID: <3027663.6fTeYNvNto@p1> Hi, Regarding recent email from Elod [1] CI of the stable/pike and stable/queens branches in networking-bgpvpn is broken now. I checked that it's due to Horizon which is already EOL in those branches. I proposed patch [2] to hopefully fix it quickly by using eol tag of Horizon. But even with that there are some other problems in the openstack-tox-pep8 and networking-bgpvpn-dsvm-functional jobs. Last merged patches in networking-bgpvpn were in 2019: [3] and [4]. Giving all that I propose to make networking-bgpvpn stable/pike and stable/ queens branches to be EOL now. Networking-bagpipe project is tightly coupled with networking-bgpvpn. Last patches merged in that project were also in 2019: [5] and [6]. Because of the above, I propose also to make branches stable/pike and stable/ queens in the networking-bagpipe to be EOL. I will wait until end of next week for anyone who would like to maybe step up as maintainer of those branches. If there will be no volunteers for that, I will EOL those branches in networking-bgpvpn and networking-bagpipe. [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-July/ 023944.html [2] https://review.opendev.org/c/openstack/networking-bgpvpn/+/803545 [3] https://review.opendev.org/q/project:openstack/networking-bgpvpn+branch:stable/queens [4] https://review.opendev.org/q/project:openstack/networking-bgpvpn+branch:stable/queens [5] https://review.opendev.org/q/project:openstack/networking-bagpipe+branch:stable/queens [6] https://review.opendev.org/q/project:openstack/networking-bagpipe+branch:stable/pike -- Slawek Kaplonski Principal Software Engineer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From lokendrarathour at gmail.com Thu Aug 5 11:31:34 2021 From: lokendrarathour at gmail.com (Lokendra Rathour) Date: Thu, 5 Aug 2021 17:01:34 +0530 Subject: "[Kolla][Kolla-Ansible] Ironic Node Deployment" Message-ID: Hi Team, I was trying to deploy Ironic Node on Kolla Ansible Setup. Document used for reference: https://docs.openstack.org/kolla-ansible/latest/reference/bare-metal/ironic-guide.html Although this document says : *" Ironic works well in Kolla, though it is not thoroughly tested as part of Kolla CI, so may be subject to instability"* We have tried 2 node Kolla Ansible *12.0.0* in order to deploy OpenStack *wallaby* release with enabled ironic for Bare-metal nodes provisioning. But facing issues in "Node Provisioning" So, has anyone tried the Baremetal Provisioning on Koll Setup? Please share /suggest any approach to achieve this. -- ~ Lokendra skype: lokendrarathour -------------- next part -------------- An HTML attachment was scrubbed... URL: From radoslaw.piliszek at gmail.com Thu Aug 5 13:25:59 2021 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Thu, 5 Aug 2021 15:25:59 +0200 Subject: Masakari with Kolla-ansible In-Reply-To: References: Message-ID: On Mon, Aug 2, 2021 at 6:19 PM Karera Tony wrote: > > Hello Team, Hello Tony, > I have deployed Openstack with Kolla-ansible on Centos8 and also enabled Masakari but I keep getting the error below in the masakari-hostmonitor.log on the controller nodes. Have you enabled hacluster as well? It is a required component for hostmonitor unless you are providing your own hacluster (i.e., pacemaker+corosync cluster). Kind regards, -yoctozepto From nate.johnston at redhat.com Thu Aug 5 13:50:15 2021 From: nate.johnston at redhat.com (Nate Johnston) Date: Thu, 5 Aug 2021 09:50:15 -0400 Subject: [neutron][stable] Nominate Lajos Katona to the neutron-stable-maint team In-Reply-To: <4154938.lVMuQLOT2H@p1> References: <4154938.lVMuQLOT2H@p1> Message-ID: <20210805135015.p26hi4yqz5rx33qn@grind.home> I think Lajos would be a great addition! +1 Nate On Thu, Aug 05, 2021 at 11:50:46AM +0200, Slawek Kaplonski wrote: > Hi, > > I would like to nominate Lajos Katona as a Neutron stable core reviewer. Lajos > is core in Neutron since long time. He is maintaining many stadium projects as > well as he is very active in the main Neutron project. He helps us a lot with > keeping stable branches healthy (especially for stadium projects, but not > only). > During that time he has proven already his knowledge about Neutron and Neutron > stadium projects as well as knowledge of the stable branches rules. > > I will keep this nomination open for about 1 week. After that if there will be > no votes agains, I will ask stable-maint-core team to add Lajos to the > neutron-stable-maint team. > > -- > Slawek Kaplonski > Principal Software Engineer > Red Hat From cboylan at sapwetik.org Thu Aug 5 15:03:29 2021 From: cboylan at sapwetik.org (Clark Boylan) Date: Thu, 05 Aug 2021 08:03:29 -0700 Subject: [i18n] Zanata In-Reply-To: References: <20210802133251.Horde.QqhNEJeXCTihV2Qzl8BvZJK@webmail.nde.ag> <558A7030-199F-4EA2-B368-123BA00606C5@getmailspring.com> <45982c97-d48b-46ce-ae8c-e5a0e832ee4e@www.fastmail.com> Message-ID: <13fa2668-ba87-47ed-ab7d-631dbe4f5a74@www.fastmail.com> On Wed, Aug 4, 2021, at 8:35 PM, 韩光宇 wrote: > Hi, > > Thank you very very much for you, you work so hard to help me out. > > You can delete directly the existing account and don't need to check > with me again. I just hope the email can log in it. I have deleted the existing user account via the web ui admin manage users page. > > About how this happen, I think your guess is right. The first, I signed > up in https://translate.openstack.org/. But when I log in, it need > OpenID. So, the second step, I sign up openid. And then, I can't log in > as now. I'm sorry if my operation is incorrect. > > Thank you, > Han Guangyu > > > ------------------ Original ------------------ > *From: * "Clark Boylan"; > *Date: * Thu, Aug 5, 2021 06:49 AM > *To: * "Jimmy McArthur"; > "openstack-discuss at lists.openstack.org"; > *Cc: * "hanguangyu at uniontech.com"; > *Subject: * Re: [i18n] Zanata > > On Wed, Aug 4, 2021, at 3:07 PM, Jimmy McArthur wrote: > > Apologies for the delayed response here, but the user I'm trying to > > help is indeed unable to log in to Zanata. We've set up a temporary > > password for them and I've tried myself and it's basically a loop. It > > says there is already an account with that name, but it won't let him > > log in, it keeps pointing him to the screen to create a new account. > > > > Here's a link to a video demonstrating the problem. I've tried myself > > with their credentials and get the same: > > https://drive.google.com/file/d/1iE0iWoYgTb5zk3SzP8oB5aYrtplRqlEm/view?usp=sharing > > CC'ing Han Guangyu, the user with the issue. > > > > Any help appreciated! Their company is looking to start contributing > > to i18n team, so it would be great if we could get them going :) > > Sorry, I missed this thread initially as it was was sent to the [i18n] > label. The OpenDev/OpenStack infra team run the Zanata server, in the > future sending email to service-discuss at lists.opendev.org is more > likely to get eyeballs on this sort of thing. It also helps if people > having problems reach out directly so that we don't resort to playing > telephone and missing important information. > > Looking at the attached video, the error is that a user with the > specified email address already exists. Looking at the database I see > that there are records for this email address in the HAccount and > HPerson tables but no openstackid openid is associated with this > account in the HCredentials table. > > On closer inspection of the records that are present I note there is a > password hash set, but there shouldn't be any password hashes if > openstackid openid is used to login and create the account. I think > what happened is somehow an account was created directly and not via > openid. Now when attempting to login with openid there is a conflict > because an account already has that email address. It would be good to > understand how this happened if possible so that we can avoid it for > the future. > > As far as fixing this account goes I suspect that if we delete the > existing account then the next login attempt will be able to > successfully create a new account with the associated openid. I don't > know that we've ever done this before so coordinating this deletion > when login can be reattempted is a good idea. > > Finally, it is worth noting that the translation tooling needs help, > not just the translations themselves. Unfortunately the software we are > using for this is no longer maintained and ideally needs to be replaced. > From number9 at dimlight.org Thu Aug 5 17:25:15 2021 From: number9 at dimlight.org (number9) Date: Thu, 05 Aug 2021 12:25:15 -0500 Subject: [ops] Openstack Victoria SPICE configuration not working Message-ID: <2e6f3235c70b84f47730cce25888541b@dimlight.org> I have posted this on stackexchange, but am also asking here: Running openstack on Ubuntu 20.04 with a controller node and four compute nodes. I am reading the instructions on configuring SPICE here. I will admit, I found out about which packages to install from other sites, as the instructions at the link do not actually list any software that needs to be installed. On the compute nodes and controller, I installed nova-spiceproxy On the controller I installed nova-spiceproxy and spice-html5 I followed the instructions in the link on configuring /etc/nova/nova.conf on the controller and all compute nodes. In a nutshell, when you click on console in the dashboard, it simply says: Something went wrong! An unexpected error has occurred. Try refreshing the page. If that doesn't help, contact your local administrator. I have parsed every log in /var/log on the compute and controller nodes and found nothing that would indicate it is failing. On the compute node, I can do a ps aux and see that spice is running on the instance I am trying to connect to. I am really not sure where to go. I have tried VNC and noVNC also to no avail, each time completely removing the old configs and only adding the new. I have reverted back to SPICE to try the "simple" approach. My relevant config items in /etc/nova/nova.conf from a compute node are: [DEFAULT] vnc_eanabled = false # yes, I know it is redundant, I am following the docs... [vnc] enabled = false [spice] enabled = true agent_enabled = true html5proxy_base_url = http://10.131.39.40:6082/spice_auto.html # the above IP is the IP of the controller. server_listen = 0.0.0.0 server_proxyclient_address = 10.131.29.42 # the above IP is the IP of the controller that I pulled this config from html5proxy_host = 0.0.0.0 html5proxy_port = 6082 Back on the controller node, in /etc/nova/nova.conf I have: [spice] enabled = true agent_enabled = false html5proxy_host = 0.0.0.0 html5proxy_port = 6082 keymap = en_us I also have vnc false, as it is on the compute nodes. I will admit further, I have tried at least 20 iterations of this, just leaving off proxy ports, or thinking for a moment that the proxyclientaddress was the controller node, but none of them work. I do restart nova on the controller and all compute nodes after every change. Any ideas or directions would be appreciated. I wish there were logs, I am perhaps missing them or need to turn on debugging of some kind. From hanguangyu at uniontech.com Thu Aug 5 03:35:33 2021 From: hanguangyu at uniontech.com (=?utf-8?B?6Z+p5YWJ5a6H?=) Date: Thu, 5 Aug 2021 11:35:33 +0800 Subject: [i18n] Zanata In-Reply-To: <45982c97-d48b-46ce-ae8c-e5a0e832ee4e@www.fastmail.com> References: <20210802133251.Horde.QqhNEJeXCTihV2Qzl8BvZJK@webmail.nde.ag> <558A7030-199F-4EA2-B368-123BA00606C5@getmailspring.com> <45982c97-d48b-46ce-ae8c-e5a0e832ee4e@www.fastmail.com> Message-ID: Hi, Thank you very very much for you, you work so hard to help me out.   You can delete directly the existing account and don't need to check with me again. I just hope the email can log in it. About how this happen, I think your guess is right. The first, I signed up in https://translate.openstack.org/. But when I log in, it need OpenID. So, the second step, I sign up openid. And then, I can't log in as now. I'm sorry if my operation is incorrect. Thank you, Han Guangyu     ------------------ Original ------------------ From:  "Clark Boylan" From anyrude10 at gmail.com Thu Aug 5 11:26:34 2021 From: anyrude10 at gmail.com (Anirudh Gupta) Date: Thu, 5 Aug 2021 16:56:34 +0530 Subject: [Kolla][Kolla-Ansible] Ironic Node Cleaning Failed In-Reply-To: References: Message-ID: Hi Team, On further debugging, I found an error in neutron-server logs Failed to bind port 476d8175-ffc2-49ba-bb12-0a77c1f07e5f on host f4a43fa5-9c41-488e-a34d-714ae5a9d300 for vnic_type baremetal using segments [{'id': '1a5bbe96-2488-4971-925f-7c9346ba3ef5', 'network_type': 'flat', 'physical_network': 'physnet1', 'segmentation_id': None, 'network_id': '5b6cccec-ad86-4ed9-8d3c-72a31ec3a0d4'}] 2021-08-05 16:33:06.979 23 INFO neutron.plugins.ml2.plugin [req-54d11d51-7319-43ea-b70c-fe39d8aafe8a 21d6a238438e4294912746bcdc895e31 3eca725754e1405eb178cc39bd0da3aa - default default] Attempt 9 to bind port 476d8175-ffc2-49ba-bb12-0a77c1f07e5f where 476d8175-ffc2-49ba-bb12-0a77c1f07e5f is the uuid of Baremetal Node However the port is created in openstack, but its state is down [ansible at localhost ~]$ openstack port list +--------------------------------------+------+-------------------+---------------------------------------------------------------------------+--------+ | ID | Name | MAC Address | Fixed IP Addresses | Status | +--------------------------------------+------+-------------------+---------------------------------------------------------------------------+--------+ | 07d6b83d-d83c-498f-8ba8-b4f21bef7249 | | fa:16:3e:38:05:9d | ip_address='10.0.1.200', subnet_id='7b72c158-2146-4bd6-893b-bd76b4a3e869' | ACTIVE | | 476d8175-ffc2-49ba-bb12-0a77c1f07e5f | | *98:f2:b3:3f:72:d8* | ip_address='10.0.1.202', subnet_id='7b72c158-2146-4bd6-893b-bd76b4a3e869' | *DOWN * | +--------------------------------------+------+-------------------+---------------------------------------------------------------------------+--------+ *98:f2:b3:3f:72:d8 *is the mac address of my Baremetal Node on which PXE is enabled. Can someone please help in resolving this issue. *Issue:* *Node goes in clean_failed from clean_wait.* Regards Anirudh Gupta On Tue, Aug 3, 2021 at 8:32 PM Anirudh Gupta wrote: > Hi Dmitry, > > I might be wrong, but as per my understanding if there would be an issue > in dnsmasq, then IP 20.20.20.10 would not have been assigned to the machine. > > TCPDUMP logs are as below: > > 20:16:58.938089 IP controller.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, > Reply, length 312 > 20:17:02.765291 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, > Request from 98:f2:b3:3f:72:e5 (oui Unknown), length 359 > 20:17:02.766303 IP controller.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, > Reply, length 312 > 20:17:26.944378 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, > Request from 98:f2:b3:3f:72:e5 (oui Unknown), length 347 > 20:17:26.944756 IP controller.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, > Reply, length 312 > 20:17:30.763627 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, > Request from 98:f2:b3:3f:72:e5 (oui Unknown), length 359 > 20:17:30.764620 IP controller.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, > Reply, length 312 > 20:17:54.938791 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, > Request from 98:f2:b3:3f:72:e5 (oui Unknown), length 347 > > Also the neutron dnsmasq logs and ironic inspector logs are attached in > the mail. > > Regards > Anirudh Gupta > > > On Tue, Aug 3, 2021 at 7:29 PM Dmitry Tantsur wrote: > >> Hi, >> >> You need to check the dnsmasq logs (there are two dnsmasqs: from neutron >> and from ironic-inspector). tcpdump may also help to determine where the >> packages are lost. >> >> Dmitry >> >> On Fri, Jul 30, 2021 at 10:29 PM Anirudh Gupta >> wrote: >> >>> Hi Dmitry >>> >>> Thanks for your time. >>> >>> My system is getting IP 20.20.20.10 which is in the range defined in >>> ironic_dnsmasq_dhcp_range field under globals.yml file. >>> >>> ironic_dnsmasq_dhcp_range: "20.20.20.10,20.20.20.100" >>> >>> And in the cleaning network (public1), the range defined is >>> 20.20.20.150-20.20.20.200 >>> >>> As per my understanding, these 2 ranges should be mutually exclusive. >>> >>> Please suggest if my understanding is not correct. >>> >>> Any suggestions what should I do to resolve this issue? >>> >>> Regards >>> Anirudh Gupta >>> >>> >>> On Sat, 31 Jul, 2021, 12:06 am Dmitry Tantsur, >>> wrote: >>> >>>> >>>> >>>> On Thu, Jul 29, 2021 at 6:05 PM Anirudh Gupta >>>> wrote: >>>> >>>>> Hi Team, >>>>> >>>>> In to the email below, I have some updated information:- >>>>> >>>>> Earlier the allocation range mentioned in "*ironic_dnsmasq_dhcp_range*" >>>>> in globals.yml had an overlapping range with the cleaning network, due to >>>>> which there was some issue in receiving the DHCP request >>>>> >>>>> After creating a cleaning network with a separate allocation range, I >>>>> am successfully getting IP allocated to my Baremetal Node >>>>> >>>>> - openstack subnet create subnet1 --network public1 --subnet-range >>>>> 20.20.20.0/24 --allocation-pool >>>>> start=20.20.20.150,end=20.20.20.200 --ip-version=4 --gateway=20.20.20.1 >>>>> --dhcp >>>>> >>>>> >>>>> [image: image.png] >>>>> >>>>> After getting the IP, there is no further action on the node. From " >>>>> *clean_wait*", it goes into "*clean_failed*" state after around half >>>>> an hour. >>>>> >>>> >>>> The IP address is not from the cleaning range, it may come from >>>> inspection. You probably need to investigate your network topology, maybe >>>> use tcpdump. >>>> >>>> Unfortunately, I'm not fluent in Kolla to say if it can be a bug or not. >>>> >>>> Dmitry >>>> >>>> >>>>> >>>>> On verifying the logs, I could see the below error messages >>>>> >>>>> >>>>> - In */var/log/kolla/ironic/ironic-conductor.log*, we observed the >>>>> following error: >>>>> >>>>> ERROR ironic.conductor.utils [-] Cleaning for node >>>>> 3a56748e-a8ca-4dec-a332-ace18e6d494e failed. *Timeout reached while >>>>> cleaning the node. Please check if the ramdisk responsible for the cleaning >>>>> is running on the node. Failed on step {}.* >>>>> >>>>> >>>>> Note : For Cleaning the node, we have used the below images >>>>> >>>>> >>>>> >>>>> https://tarballs.openstack.org/ironic-python-agent/dib/files/ipa-centos8-master.kernel >>>>> >>>>> >>>>> https://tarballs.openstack.org/ironic-python-agent/dib/files/ipa-centos8-master.initramfs >>>>> >>>>> >>>>> - In /var/log/kolla/nova/nova-compute-ironic.log, we observed the >>>>> error >>>>> >>>>> ERROR nova.compute.manager [req-810ffedf-3343-471c-94db-85411984e6cc - >>>>> - - - -] No compute node record for host controller-ironic: >>>>> nova.exception_Remote.ComputeHostNotFound_Remote: Compute host >>>>> controller-ironic could not be found. >>>>> >>>>> >>>>> Can someone please help in this regard? >>>>> >>>>> Regards >>>>> Anirudh Gupta >>>>> >>>>> >>>>> On Tue, Jul 27, 2021 at 12:52 PM Anirudh Gupta >>>>> wrote: >>>>> >>>>>> Hi Team, >>>>>> >>>>>> We have deployed 2 node kolla ansible *12.0.0* in order to deploy >>>>>> openstack *wallaby* release. We have also enabled ironic in order to >>>>>> provision the bare metal nodes. >>>>>> >>>>>> On each server we have 3 nics >>>>>> >>>>>> - *eno1* - OAM for external connectivity and endpoint's publicURL >>>>>> - *eno2* - Mgmt for internal communication between various >>>>>> openstack services. >>>>>> - *ens2f0* - Data Interface >>>>>> >>>>>> >>>>>> Corresponding to this we have defined the following fields in >>>>>> globals.yml >>>>>> >>>>>> >>>>>> - kolla_base_distro: "centos" >>>>>> - kolla_install_type: "source" >>>>>> - openstack_release: "wallaby" >>>>>> - network_interface: "eno2" # MGMT >>>>>> interface >>>>>> - kolla_external_vip_interface: "eno1" # OAM >>>>>> Interface >>>>>> - kolla_internal_vip_address: "192.168.10.3" # MGMT Subnet >>>>>> free ip >>>>>> - kolla_external_vip_address: "10.0.1.136" # OAM subnet >>>>>> free IP >>>>>> - neutron_external_interface: "ens2f0" # Data >>>>>> Interface >>>>>> - enable_neutron_provider_networks: "yes" >>>>>> >>>>>> Note: Only relevant fields are being shown in this query >>>>>> >>>>>> Also, for ironic following fields have been defined in globals.yml >>>>>> >>>>>> - enable_ironic: "yes" >>>>>> - enable_ironic_neutron_agent: "{{ enable_neutron | bool and >>>>>> enable_ironic | bool }}" >>>>>> - enable_horizon_ironic: "{{ enable_ironic | bool }}" >>>>>> - ironic_dnsmasq_interface: "*ens2f0*" # >>>>>> Data interface >>>>>> - ironic_dnsmasq_dhcp_range: "20.20.20.10,20.20.20.100" >>>>>> - ironic_dnsmasq_boot_file: "pxelinux.0" >>>>>> - ironic_cleaning_network: "public1" >>>>>> - ironic_dnsmasq_default_gateway: "20.20.20.1" >>>>>> >>>>>> >>>>>> After successful deployment, a flat provider network with the name >>>>>> public1 is being created in openstack using the below commands: >>>>>> >>>>>> >>>>>> - openstack network create public1 --provider-network-type flat >>>>>> --provider-physical-network physnet1 >>>>>> - openstack subnet create subnet1 --network public1 >>>>>> --subnet-range 20.20.20.0/24 --allocation-pool >>>>>> start=20.20.20.10,end=20.20.20.100 --ip-version=4 --gateway=20.20.20.1 >>>>>> --dhcp >>>>>> >>>>>> >>>>>> Issue/Queries: >>>>>> >>>>>> >>>>>> - Is the configuration done in globals.yml correct or is there >>>>>> anything else that needs to be done in order to separate control and data >>>>>> plane traffic? >>>>>> >>>>>> >>>>>> - Also I have set automated_cleaning as "true" in >>>>>> ironic-conductor conatiner settings.But after creating the baremetal node, >>>>>> we run "node manage" command which runs successfully. Running "*openstack >>>>>> baremetal node provide "* command powers on the machine, >>>>>> sets the boot mode on Network Boot but no DHCP request for that particular >>>>>> mac is obtained on the controller. Is there anything I am missing that >>>>>> needs to be done in order to make ironic work? >>>>>> >>>>>> Note: I have also verified that the nic is PXE enabled in system >>>>>> configuration setting >>>>>> >>>>>> Regards >>>>>> Anirudh Gupta >>>>>> >>>>>> >>>>>> >>>> >>>> -- >>>> Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, >>>> Commercial register: Amtsgericht Muenchen, HRB 153243, >>>> Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael >>>> O'Neill >>>> >>> >> >> -- >> Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, >> Commercial register: Amtsgericht Muenchen, HRB 153243, >> Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael >> O'Neill >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 38285 bytes Desc: not available URL: From tonykarera at gmail.com Fri Aug 6 07:47:52 2021 From: tonykarera at gmail.com (Karera Tony) Date: Fri, 6 Aug 2021 09:47:52 +0200 Subject: Masakari with Kolla-ansible In-Reply-To: References: Message-ID: Hello Radoslaw, I enabled it but it seems the corosync cluster is not working. I don't know if there is any other trick to try. Regards Tony Karera On Thu, Aug 5, 2021 at 3:26 PM Radosław Piliszek < radoslaw.piliszek at gmail.com> wrote: > On Mon, Aug 2, 2021 at 6:19 PM Karera Tony wrote: > > > > Hello Team, > > Hello Tony, > > > I have deployed Openstack with Kolla-ansible on Centos8 and also enabled > Masakari but I keep getting the error below in the masakari-hostmonitor.log > on the controller nodes. > > Have you enabled hacluster as well? > It is a required component for hostmonitor unless you are providing > your own hacluster (i.e., pacemaker+corosync cluster). > > Kind regards, > > -yoctozepto > -------------- next part -------------- An HTML attachment was scrubbed... URL: From balazs.gibizer at est.tech Fri Aug 6 08:35:06 2021 From: balazs.gibizer at est.tech (Balazs Gibizer) Date: Fri, 06 Aug 2021 10:35:06 +0200 Subject: [nova][placement] PTL is on vacation next week Message-ID: Hi, I will be on PTO next week. The weekly nova meeting has been canceled. cheers, gibi From jlibosva at redhat.com Fri Aug 6 10:00:34 2021 From: jlibosva at redhat.com (Jakub Libosvar) Date: Fri, 6 Aug 2021 12:00:34 +0200 Subject: [wallaby][neutron][ovn] Multiple VLAN ranges and FLAT network In-Reply-To: References: Message-ID: On 01.07.2021 12:51, Malik Obaid wrote: > Hi, > > I am using Openstack Wallaby release on Ubuntu 20.04. > > I am configuring openstack neutron for production and just want to know is > there a way to specify different vlan ranges with multiple physical > networks. > > I would really appreciate any input in this regard. > > Thank you. > > Regards, > Malik Obaid > Hi Malik, this is in general answer even if you don't use OVN - you can configure vlan range per provider network in the [ml2_type_vlan] network_vlan_ranges config option. The format of the value is :: separated by comma. Hope that helps. Kuba From radoslaw.piliszek at gmail.com Fri Aug 6 12:20:52 2021 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Fri, 6 Aug 2021 14:20:52 +0200 Subject: Masakari with Kolla-ansible In-Reply-To: References: Message-ID: On Fri, Aug 6, 2021 at 9:48 AM Karera Tony wrote: > > Hello Radoslaw, > > I enabled it but it seems the corosync cluster is not working. > > I don't know if there is any other trick to try. There are no tricks. You might want to check the corosync status via: crm_mon -1 issued in the pacemaker container on the faulty controller host. > Regards > > Tony Karera > > > > > On Thu, Aug 5, 2021 at 3:26 PM Radosław Piliszek wrote: >> >> On Mon, Aug 2, 2021 at 6:19 PM Karera Tony wrote: >> > >> > Hello Team, >> >> Hello Tony, >> >> > I have deployed Openstack with Kolla-ansible on Centos8 and also enabled Masakari but I keep getting the error below in the masakari-hostmonitor.log on the controller nodes. >> >> Have you enabled hacluster as well? >> It is a required component for hostmonitor unless you are providing >> your own hacluster (i.e., pacemaker+corosync cluster). >> >> Kind regards, >> >> -yoctozepto From anyrude10 at gmail.com Fri Aug 6 12:12:23 2021 From: anyrude10 at gmail.com (Anirudh Gupta) Date: Fri, 6 Aug 2021 17:42:23 +0530 Subject: [Kolla][Kolla-Ansible] Ironic Node Cleaning Failed In-Reply-To: References: Message-ID: Hi Dmitry, I tried taking TCPDUMP while the Baremetal Node was booting up and looked for tftp protocols and found there was some "*File Not Found" *traces for bootx64.efi [image: image.png] Then, I found a related post on openstack Discuss which suggested to enable IPXE http://lists.openstack.org/pipermail/openstack-discuss/2019-October/010329.html After re-deploying the setup with IPXE enabled, i found similar traces now for *ipxe.efi file* [image: image.png] Can you please now suggest what possibly could be a miss in configuration and steps to resolve it. For your reference, I am attaching the complete tcpdump logs of both the Scenarios Looking forward to hearing from you. Regards Anirudh Gupta On Thu, Aug 5, 2021 at 4:56 PM Anirudh Gupta wrote: > Hi Team, > > On further debugging, I found an error in neutron-server logs > > > Failed to bind port 476d8175-ffc2-49ba-bb12-0a77c1f07e5f on host > f4a43fa5-9c41-488e-a34d-714ae5a9d300 for vnic_type baremetal using segments > [{'id': '1a5bbe96-2488-4971-925f-7c9346ba3ef5', 'network_type': 'flat', > 'physical_network': 'physnet1', 'segmentation_id': None, 'network_id': > '5b6cccec-ad86-4ed9-8d3c-72a31ec3a0d4'}] > 2021-08-05 16:33:06.979 23 INFO neutron.plugins.ml2.plugin > [req-54d11d51-7319-43ea-b70c-fe39d8aafe8a 21d6a238438e4294912746bcdc895e31 > 3eca725754e1405eb178cc39bd0da3aa - default default] Attempt 9 to bind port > 476d8175-ffc2-49ba-bb12-0a77c1f07e5f > > where 476d8175-ffc2-49ba-bb12-0a77c1f07e5f is the uuid of Baremetal Node > > However the port is created in openstack, but its state is down > > [ansible at localhost ~]$ openstack port list > > +--------------------------------------+------+-------------------+---------------------------------------------------------------------------+--------+ > | ID | Name | MAC Address | Fixed > IP Addresses | > Status | > > +--------------------------------------+------+-------------------+---------------------------------------------------------------------------+--------+ > | 07d6b83d-d83c-498f-8ba8-b4f21bef7249 | | fa:16:3e:38:05:9d | > ip_address='10.0.1.200', subnet_id='7b72c158-2146-4bd6-893b-bd76b4a3e869' | > ACTIVE | > | 476d8175-ffc2-49ba-bb12-0a77c1f07e5f | | *98:f2:b3:3f:72:d8* | > ip_address='10.0.1.202', subnet_id='7b72c158-2146-4bd6-893b-bd76b4a3e869' | *DOWN > * | > > +--------------------------------------+------+-------------------+---------------------------------------------------------------------------+--------+ > > *98:f2:b3:3f:72:d8 *is the mac address of my Baremetal Node on which PXE > is enabled. > > Can someone please help in resolving this issue. > > *Issue:* > *Node goes in clean_failed from clean_wait.* > > Regards > Anirudh Gupta > > On Tue, Aug 3, 2021 at 8:32 PM Anirudh Gupta wrote: > >> Hi Dmitry, >> >> I might be wrong, but as per my understanding if there would be an issue >> in dnsmasq, then IP 20.20.20.10 would not have been assigned to the machine. >> >> TCPDUMP logs are as below: >> >> 20:16:58.938089 IP controller.bootps > 255.255.255.255.bootpc: >> BOOTP/DHCP, Reply, length 312 >> 20:17:02.765291 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, >> Request from 98:f2:b3:3f:72:e5 (oui Unknown), length 359 >> 20:17:02.766303 IP controller.bootps > 255.255.255.255.bootpc: >> BOOTP/DHCP, Reply, length 312 >> 20:17:26.944378 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, >> Request from 98:f2:b3:3f:72:e5 (oui Unknown), length 347 >> 20:17:26.944756 IP controller.bootps > 255.255.255.255.bootpc: >> BOOTP/DHCP, Reply, length 312 >> 20:17:30.763627 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, >> Request from 98:f2:b3:3f:72:e5 (oui Unknown), length 359 >> 20:17:30.764620 IP controller.bootps > 255.255.255.255.bootpc: >> BOOTP/DHCP, Reply, length 312 >> 20:17:54.938791 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, >> Request from 98:f2:b3:3f:72:e5 (oui Unknown), length 347 >> >> Also the neutron dnsmasq logs and ironic inspector logs are attached in >> the mail. >> >> Regards >> Anirudh Gupta >> >> >> On Tue, Aug 3, 2021 at 7:29 PM Dmitry Tantsur >> wrote: >> >>> Hi, >>> >>> You need to check the dnsmasq logs (there are two dnsmasqs: from neutron >>> and from ironic-inspector). tcpdump may also help to determine where the >>> packages are lost. >>> >>> Dmitry >>> >>> On Fri, Jul 30, 2021 at 10:29 PM Anirudh Gupta >>> wrote: >>> >>>> Hi Dmitry >>>> >>>> Thanks for your time. >>>> >>>> My system is getting IP 20.20.20.10 which is in the range defined in >>>> ironic_dnsmasq_dhcp_range field under globals.yml file. >>>> >>>> ironic_dnsmasq_dhcp_range: "20.20.20.10,20.20.20.100" >>>> >>>> And in the cleaning network (public1), the range defined is >>>> 20.20.20.150-20.20.20.200 >>>> >>>> As per my understanding, these 2 ranges should be mutually exclusive. >>>> >>>> Please suggest if my understanding is not correct. >>>> >>>> Any suggestions what should I do to resolve this issue? >>>> >>>> Regards >>>> Anirudh Gupta >>>> >>>> >>>> On Sat, 31 Jul, 2021, 12:06 am Dmitry Tantsur, >>>> wrote: >>>> >>>>> >>>>> >>>>> On Thu, Jul 29, 2021 at 6:05 PM Anirudh Gupta >>>>> wrote: >>>>> >>>>>> Hi Team, >>>>>> >>>>>> In to the email below, I have some updated information:- >>>>>> >>>>>> Earlier the allocation range mentioned in " >>>>>> *ironic_dnsmasq_dhcp_range*" in globals.yml had an overlapping range >>>>>> with the cleaning network, due to which there was some issue in receiving >>>>>> the DHCP request >>>>>> >>>>>> After creating a cleaning network with a separate allocation range, I >>>>>> am successfully getting IP allocated to my Baremetal Node >>>>>> >>>>>> - openstack subnet create subnet1 --network public1 >>>>>> --subnet-range 20.20.20.0/24 --allocation-pool >>>>>> start=20.20.20.150,end=20.20.20.200 --ip-version=4 --gateway=20.20.20.1 >>>>>> --dhcp >>>>>> >>>>>> >>>>>> [image: image.png] >>>>>> >>>>>> After getting the IP, there is no further action on the node. From " >>>>>> *clean_wait*", it goes into "*clean_failed*" state after around half >>>>>> an hour. >>>>>> >>>>> >>>>> The IP address is not from the cleaning range, it may come from >>>>> inspection. You probably need to investigate your network topology, maybe >>>>> use tcpdump. >>>>> >>>>> Unfortunately, I'm not fluent in Kolla to say if it can be a bug or >>>>> not. >>>>> >>>>> Dmitry >>>>> >>>>> >>>>>> >>>>>> On verifying the logs, I could see the below error messages >>>>>> >>>>>> >>>>>> - In */var/log/kolla/ironic/ironic-conductor.log*, we observed >>>>>> the following error: >>>>>> >>>>>> ERROR ironic.conductor.utils [-] Cleaning for node >>>>>> 3a56748e-a8ca-4dec-a332-ace18e6d494e failed. *Timeout reached while >>>>>> cleaning the node. Please check if the ramdisk responsible for the cleaning >>>>>> is running on the node. Failed on step {}.* >>>>>> >>>>>> >>>>>> Note : For Cleaning the node, we have used the below images >>>>>> >>>>>> >>>>>> >>>>>> https://tarballs.openstack.org/ironic-python-agent/dib/files/ipa-centos8-master.kernel >>>>>> >>>>>> >>>>>> https://tarballs.openstack.org/ironic-python-agent/dib/files/ipa-centos8-master.initramfs >>>>>> >>>>>> >>>>>> - In /var/log/kolla/nova/nova-compute-ironic.log, we observed the >>>>>> error >>>>>> >>>>>> ERROR nova.compute.manager [req-810ffedf-3343-471c-94db-85411984e6cc >>>>>> - - - - -] No compute node record for host controller-ironic: >>>>>> nova.exception_Remote.ComputeHostNotFound_Remote: Compute host >>>>>> controller-ironic could not be found. >>>>>> >>>>>> >>>>>> Can someone please help in this regard? >>>>>> >>>>>> Regards >>>>>> Anirudh Gupta >>>>>> >>>>>> >>>>>> On Tue, Jul 27, 2021 at 12:52 PM Anirudh Gupta >>>>>> wrote: >>>>>> >>>>>>> Hi Team, >>>>>>> >>>>>>> We have deployed 2 node kolla ansible *12.0.0* in order to deploy >>>>>>> openstack *wallaby* release. We have also enabled ironic in order >>>>>>> to provision the bare metal nodes. >>>>>>> >>>>>>> On each server we have 3 nics >>>>>>> >>>>>>> - *eno1* - OAM for external connectivity and endpoint's publicURL >>>>>>> - *eno2* - Mgmt for internal communication between various >>>>>>> openstack services. >>>>>>> - *ens2f0* - Data Interface >>>>>>> >>>>>>> >>>>>>> Corresponding to this we have defined the following fields in >>>>>>> globals.yml >>>>>>> >>>>>>> >>>>>>> - kolla_base_distro: "centos" >>>>>>> - kolla_install_type: "source" >>>>>>> - openstack_release: "wallaby" >>>>>>> - network_interface: "eno2" # MGMT >>>>>>> interface >>>>>>> - kolla_external_vip_interface: "eno1" # OAM >>>>>>> Interface >>>>>>> - kolla_internal_vip_address: "192.168.10.3" # MGMT Subnet >>>>>>> free ip >>>>>>> - kolla_external_vip_address: "10.0.1.136" # OAM subnet >>>>>>> free IP >>>>>>> - neutron_external_interface: "ens2f0" # Data >>>>>>> Interface >>>>>>> - enable_neutron_provider_networks: "yes" >>>>>>> >>>>>>> Note: Only relevant fields are being shown in this query >>>>>>> >>>>>>> Also, for ironic following fields have been defined in globals.yml >>>>>>> >>>>>>> - enable_ironic: "yes" >>>>>>> - enable_ironic_neutron_agent: "{{ enable_neutron | bool and >>>>>>> enable_ironic | bool }}" >>>>>>> - enable_horizon_ironic: "{{ enable_ironic | bool }}" >>>>>>> - ironic_dnsmasq_interface: "*ens2f0*" # >>>>>>> Data interface >>>>>>> - ironic_dnsmasq_dhcp_range: "20.20.20.10,20.20.20.100" >>>>>>> - ironic_dnsmasq_boot_file: "pxelinux.0" >>>>>>> - ironic_cleaning_network: "public1" >>>>>>> - ironic_dnsmasq_default_gateway: "20.20.20.1" >>>>>>> >>>>>>> >>>>>>> After successful deployment, a flat provider network with the name >>>>>>> public1 is being created in openstack using the below commands: >>>>>>> >>>>>>> >>>>>>> - openstack network create public1 --provider-network-type flat >>>>>>> --provider-physical-network physnet1 >>>>>>> - openstack subnet create subnet1 --network public1 >>>>>>> --subnet-range 20.20.20.0/24 --allocation-pool >>>>>>> start=20.20.20.10,end=20.20.20.100 --ip-version=4 --gateway=20.20.20.1 >>>>>>> --dhcp >>>>>>> >>>>>>> >>>>>>> Issue/Queries: >>>>>>> >>>>>>> >>>>>>> - Is the configuration done in globals.yml correct or is there >>>>>>> anything else that needs to be done in order to separate control and data >>>>>>> plane traffic? >>>>>>> >>>>>>> >>>>>>> - Also I have set automated_cleaning as "true" in >>>>>>> ironic-conductor conatiner settings.But after creating the baremetal node, >>>>>>> we run "node manage" command which runs successfully. Running "*openstack >>>>>>> baremetal node provide "* command powers on the >>>>>>> machine, sets the boot mode on Network Boot but no DHCP request for that >>>>>>> particular mac is obtained on the controller. Is there anything I am >>>>>>> missing that needs to be done in order to make ironic work? >>>>>>> >>>>>>> Note: I have also verified that the nic is PXE enabled in system >>>>>>> configuration setting >>>>>>> >>>>>>> Regards >>>>>>> Anirudh Gupta >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> -- >>>>> Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, >>>>> Commercial register: Amtsgericht Muenchen, HRB 153243, >>>>> Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, >>>>> Michael O'Neill >>>>> >>>> >>> >>> -- >>> Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, >>> Commercial register: Amtsgericht Muenchen, HRB 153243, >>> Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael >>> O'Neill >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 38285 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 185546 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 200447 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dump.pcap Type: application/octet-stream Size: 732134 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dump_ipxe.pcap Type: application/octet-stream Size: 1275772 bytes Desc: not available URL: From chris at lyonsgroup.family Fri Aug 6 12:18:19 2021 From: chris at lyonsgroup.family (Chris Lyons) Date: Fri, 6 Aug 2021 12:18:19 +0000 Subject: Octavia Message-ID: Octavia group, I created this story to see if I could get some assistance on an Octavia issue I am having with my infra. I did a vanilla install of Openstack Wallaby using the Kolla project with Octavia enabled and auto-configure set. Everything appeared to install fine. When I try to create a load balancer using the horizon console or the cli or through further installs such as cloudfoundry that require a loadbalancer, I get an error from glance about “No image found with tag amphora” even though the image does exist. I hope it is something simple or an oversight on my part. Could I get some ideas or places to look? Story: https://storyboard.openstack.org/#!/story/2009103 Kolla install followed: https://docs.openstack.org/kolla-ansible/latest/reference/networking/octavia.html cli output : [root at kolla ~]# openstack image list --tag amphora +--------------------------------------+---------------------+--------+ | ID | Name | Status | +--------------------------------------+---------------------+--------+ | 8f7398e7-7912-43b8-8131-e90f21c91ab4 | amphora | active | | 9bf14389-8521-4fb7-a7db-925f4dea1bf3 | amphora-x64-haproxy | active | +--------------------------------------+---------------------+--------+ [root at kolla ~]# My Infra scripts (relevant): https://github.com/mephmanx/openstack-scripts/blob/32363ef5753fdec381f713c747c90a5c14b3ae72/kolla.sh#L340 I am admin of said infra so if anyone has time or availability (or interest) to log in and take a look I would be happy to provide creds. Thank you for any time that you could provide or offer! -------------- next part -------------- An HTML attachment was scrubbed... URL: From akanevsk at redhat.com Fri Aug 6 13:52:44 2021 From: akanevsk at redhat.com (Arkady Kanevsky) Date: Fri, 6 Aug 2021 08:52:44 -0500 Subject: [interop][cinder] review of next.json (part 2) In-Reply-To: References: <07c47d7a-0ca1-aad4-4cd8-369049bd6b63@gmail.com> <954a3f22-8d7c-c40b-09cf-d21628cb0227@gmail.com> <8ccc4dfa-4b20-2277-c60b-23d9970d72f3@gmail.com> Message-ID: Brian, can we schedule it for Tu 16:30-16:45 UTC? or some time 16:00-17:00 on Tu? Thanks, Arkady On Fri, Jul 30, 2021 at 11:17 AM Arkady Kanevsky wrote: > Thanks Brian. > Will discuss at next Interop team meeting and will assign a person to meet > and present with cinder team at that time. > > On Thu, Jul 29, 2021 at 8:07 AM Brian Rosmaita > wrote: > >> On 7/28/21 6:08 PM, Arkady Kanevsky wrote: >> > Brian, >> > lets postpone it till PTG. >> > I am booked solid Wed morning. >> > Thanks, >> > Arkady >> >> That works for us. The Cinder team will be meeting 13:00-16:00 UTC from >> Tuesday through Friday the week of the PTG. I'd like to schedule you >> right at 13:00 UTC on one of those days. You can decide among >> yourselves what works for you and please put a note on our planning >> etherpad: >> >> https://etherpad.opendev.org/p/yoga-ptg-cinder-planning >> >> thanks! >> brian >> >> >> > >> > On Wed, Jul 28, 2021 at 4:32 PM Brian Rosmaita >> > > wrote: >> > >> > On 5/13/21 10:38 AM, Kanevsky, Arkady wrote: >> > > Thanks Brian. >> > > I will discuss with the team and we will have somebody from the >> > Interop team attending it. >> > >> > Hello Interop WG, >> > >> > Just want to remind you that we're holding the cinder xena R-9 >> virtual >> > midcycle next week on Wednesday 4 August 2021, and that we've got >> > you on >> > the agenda for a 20 minute discussion at 1400 UTC. You can read >> > through >> > an earlier discussion at the weekly cinder meeting to get an idea of >> > what questions we have: >> > >> > >> http://eavesdrop.openstack.org/meetings/cinder/2021/cinder.2021-05-12-14.00.log.html#l-56 >> > < >> http://eavesdrop.openstack.org/meetings/cinder/2021/cinder.2021-05-12-14.00.log.html#l-56 >> > >> > >> > Connection info is: https://bluejeans.com/3228528973 >> > >> > >> > If something has changed and no one's available, let me know. We >> can >> > postpone the discussion to the Yoga virtual PTG. >> > >> > thanks! >> > brian >> > >> > > Thanks, >> > > >> > > -----Original Message----- >> > > From: Brian Rosmaita > > > >> > > Sent: Thursday, May 13, 2021 9:25 AM >> > > To: openstack-discuss at lists.openstack.org >> > >> > > Subject: [interop][cinder] review of next.json (part 2) >> > > >> > > >> > > [EXTERNAL EMAIL] >> > > >> > > Hello Interop WG, >> > > >> > > The Cinder team completed its discussion of what capabilities >> > should be added as advisory in next.json at yesterday's weekly >> > cinder meeting [0]. >> > > >> > > The tldr; is that we don't have anything to propose for inclusion >> > in next.json at the present time. >> > > >> > > The team does have some general questions that would help us >> > determine the suitability of some proposed capabilities. We'd like >> > to invite someone from the Interop WG to the cinder xena R-9 virtual >> > midcycle (Wednesday 4 August 2021, 1400-1600 UTC) so we can discuss >> > this "live". >> > > So if someone could put 1400 UTC 4 August on their schedule for a >> > 20 minute discussion, that would be very helpful. >> > > >> > > cheers, >> > > brian >> > > >> > > >> > > [0] >> > > >> > >> http://eavesdrop.openstack.org/meetings/cinder/2021/cinder.2021-05-12-14.00.log.html#l-56 >> > < >> http://eavesdrop.openstack.org/meetings/cinder/2021/cinder.2021-05-12-14.00.log.html#l-56 >> > >> > > >> > >> > >> > >> > >> > -- >> > Arkady Kanevsky, Ph.D. >> > Phone: 972 707-6456 >> > Corporate Phone: 919 729-5744 ext. 8176456 >> >> > > -- > Arkady Kanevsky, Ph.D. > Phone: 972 707-6456 > Corporate Phone: 919 729-5744 ext. 8176456 > -- Arkady Kanevsky, Ph.D. Phone: 972 707-6456 Corporate Phone: 919 729-5744 ext. 8176456 -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnsomor at gmail.com Fri Aug 6 14:04:34 2021 From: johnsomor at gmail.com (Michael Johnson) Date: Fri, 6 Aug 2021 07:04:34 -0700 Subject: Octavia In-Reply-To: References: Message-ID: This is a kolla bug most likely. This could be caused by a few possible issues in kolla: 1. The images are owned by the wrong project. Kolla may deploy Octavia under a special service project. The image kolla uploads to glance must be uploaded under the service project as owner. A simple test to see if this is the issue would be to set the image as "public" such that all users of the cloud can see it. If a load balancer can be created after that change, the images are loaded under a project that Octavia cannot access. 2. The other possibility is kolla configured an alternate tag name. Check the [controller_worker] amp_image_tag setting [1] in octavia.conf. The images must be tagged with the same name as is configured in the octavia.conf for the controllers. Let us know either way (and ideally open a bug for kolla) what you find out. Michael [1] https://docs.openstack.org/octavia/latest/configuration/configref.html#controller_worker.amp_image_tag On Fri, Aug 6, 2021 at 5:52 AM Chris Lyons wrote: > > Octavia group, > > > > I created this story to see if I could get some assistance on an Octavia issue I am having with my infra. I did a vanilla install of Openstack Wallaby using the Kolla project with Octavia enabled and auto-configure set. Everything appeared to install fine. When I try to create a load balancer using the horizon console or the cli or through further installs such as cloudfoundry that require a loadbalancer, I get an error from glance about “No image found with tag amphora” even though the image does exist. I hope it is something simple or an oversight on my part. Could I get some ideas or places to look? > > > > Story: > > > > https://storyboard.openstack.org/#!/story/2009103 > > > > Kolla install followed: > > > > https://docs.openstack.org/kolla-ansible/latest/reference/networking/octavia.html > > > > cli output : > > > > [root at kolla ~]# openstack image list --tag amphora > > +--------------------------------------+---------------------+--------+ > > | ID | Name | Status | > > +--------------------------------------+---------------------+--------+ > > | 8f7398e7-7912-43b8-8131-e90f21c91ab4 | amphora | active | > > | 9bf14389-8521-4fb7-a7db-925f4dea1bf3 | amphora-x64-haproxy | active | > > +--------------------------------------+---------------------+--------+ > > [root at kolla ~]# > > > > My Infra scripts (relevant): > > > > https://github.com/mephmanx/openstack-scripts/blob/32363ef5753fdec381f713c747c90a5c14b3ae72/kolla.sh#L340 > > > > > > I am admin of said infra so if anyone has time or availability (or interest) to log in and take a look I would be happy to provide creds. > > > > Thank you for any time that you could provide or offer! From hberaud at redhat.com Fri Aug 6 14:13:31 2021 From: hberaud at redhat.com (Herve Beraud) Date: Fri, 6 Aug 2021 16:13:31 +0200 Subject: [release] Release countdown for week R-8, Aug 09 - Aug 13 Message-ID: General Information ------------------- The following cycle-with-intermediary deliverables have not done any intermediary release yet during this cycle. The cycle-with-rc release model is more suited for deliverables that plan to be released only once per cycle. As a result, we have proposed[1] to change the release model for the following deliverables: - python-openstackclient ( https://review.opendev.org/c/openstack/releases/+/803221) - ansible-role-atos-hsm ( https://review.opendev.org/c/openstack/releases/+/803216) - ansible-role-atos-lunasa ( https://review.opendev.org/c/openstack/releases/+/803216) - ansible-role-thales-hsm ( https://review.opendev.org/c/openstack/releases/+/803216) [1] https://review.opendev.org/q/topic:%22not-yet-released%22 PTLs and release liaisons for each of those deliverables can either +1 the release model change, or propose an intermediary release for that deliverable. In absence of answer by the end of R-10 week we'll consider that the switch to cycle-with-rc is preferable. We also published a proposed release schedule for the upcoming yoga cycle. Please check out the separate thread: https://review.opendev.org/c/openstack/releases/+/800663 Upcoming Deadlines & Dates -------------------------- Non-client library freeze: August 26 (R-6 week) Client library freeze: September 2 (R-5 week) Xena-3 milestone: September 2 (R-5 week) -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnsomor at gmail.com Fri Aug 6 14:42:42 2021 From: johnsomor at gmail.com (Michael Johnson) Date: Fri, 6 Aug 2021 07:42:42 -0700 Subject: Octavia In-Reply-To: References: Message-ID: Hmm, so not the usual suspects. Can you check the glance logs and see what error it is reporting when Octavia attempts to access the image? Also, confirm that the settings kolla provided for the glance endpoint are valid in the octavia.conf. [glance] section documented here: https://docs.openstack.org/octavia/latest/configuration/configref.html#glance They may not be configured, which is ok as it will look them up in the catalog if they are not specified. Also, double check that the image driver is set to glance in [controller_worker] image_driver. https://docs.openstack.org/octavia/latest/configuration/configref.html#controller_worker.image_driver Though from the logs this setting looks correct. The default setting if not specified is the glance driver. If you want to chat in more real-time, we are on IRC OFTC in channel #openstack-lbaas. Michael On Fri, Aug 6, 2021 at 7:07 AM Chris Lyons wrote: > > Both of those appear ok…. I do have the amphora image set to public and I see this in the Octavia.conf file: > > > > > > [controller_worker] > > amp_ssh_key_name = octavia_ssh_key > > amp_image_tag = amphora > > amp_image_owner_id = 4269b3cd5452416e8153f5b4f5adcf0c > > amp_boot_network_list = adfa01a9-55bd-42ea-b849-81060d5d7c09 > > amp_secgroup_list = ecf269e2-42fc-477b-9ce1-38d60c1d8d5d > > amp_flavor_id = c854d1e7-885f-4f7a-88a3-79728b561830 > > client_ca = /etc/octavia/certs/client_ca.cert.pem > > network_driver = allowed_address_pairs_driver > > compute_driver = compute_nova_driver > > amphora_driver = amphora_haproxy_rest_driver > > amp_active_retries = 100 > > amp_active_wait_sec = 2 > > loadbalancer_topology = SINGLE > > > > > > > > From: Michael Johnson > Date: Friday, August 6, 2021 at 10:04 AM > To: Chris Lyons > Cc: openstack-discuss at lists.openstack.org > Subject: Re: Octavia > > This is a kolla bug most likely. > > This could be caused by a few possible issues in kolla: > > 1. The images are owned by the wrong project. Kolla may deploy > Octavia under a special service project. The image kolla uploads to > glance must be uploaded under the service project as owner. A simple > test to see if this is the issue would be to set the image as "public" > such that all users of the cloud can see it. If a load balancer can be > created after that change, the images are loaded under a project that > Octavia cannot access. > 2. The other possibility is kolla configured an alternate tag name. > Check the [controller_worker] amp_image_tag setting [1] in > octavia.conf. The images must be tagged with the same name as is > configured in the octavia.conf for the controllers. > > Let us know either way (and ideally open a bug for kolla) what you find out. > > Michael > > [1] https://docs.openstack.org/octavia/latest/configuration/configref.html#controller_worker.amp_image_tag > > On Fri, Aug 6, 2021 at 5:52 AM Chris Lyons wrote: > > > > Octavia group, > > > > > > > > I created this story to see if I could get some assistance on an Octavia issue I am having with my infra. I did a vanilla install of Openstack Wallaby using the Kolla project with Octavia enabled and auto-configure set. Everything appeared to install fine. When I try to create a load balancer using the horizon console or the cli or through further installs such as cloudfoundry that require a loadbalancer, I get an error from glance about “No image found with tag amphora” even though the image does exist. I hope it is something simple or an oversight on my part. Could I get some ideas or places to look? > > > > > > > > Story: > > > > > > > > https://storyboard.openstack.org/#!/story/2009103 > > > > > > > > Kolla install followed: > > > > > > > > https://docs.openstack.org/kolla-ansible/latest/reference/networking/octavia.html > > > > > > > > cli output : > > > > > > > > [root at kolla ~]# openstack image list --tag amphora > > > > +--------------------------------------+---------------------+--------+ > > > > | ID | Name | Status | > > > > +--------------------------------------+---------------------+--------+ > > > > | 8f7398e7-7912-43b8-8131-e90f21c91ab4 | amphora | active | > > > > | 9bf14389-8521-4fb7-a7db-925f4dea1bf3 | amphora-x64-haproxy | active | > > > > +--------------------------------------+---------------------+--------+ > > > > [root at kolla ~]# > > > > > > > > My Infra scripts (relevant): > > > > > > > > https://github.com/mephmanx/openstack-scripts/blob/32363ef5753fdec381f713c747c90a5c14b3ae72/kolla.sh#L340 > > > > > > > > > > > > I am admin of said infra so if anyone has time or availability (or interest) to log in and take a look I would be happy to provide creds. > > > > > > > > Thank you for any time that you could provide or offer! > > > > This email has been scanned by Inbound Shield™. From chris at lyonsgroup.family Fri Aug 6 14:07:47 2021 From: chris at lyonsgroup.family (Chris Lyons) Date: Fri, 6 Aug 2021 14:07:47 +0000 Subject: Octavia In-Reply-To: References: , Message-ID: Both of those appear ok…. I do have the amphora image set to public and I see this in the Octavia.conf file: [controller_worker] amp_ssh_key_name = octavia_ssh_key amp_image_tag = amphora amp_image_owner_id = 4269b3cd5452416e8153f5b4f5adcf0c amp_boot_network_list = adfa01a9-55bd-42ea-b849-81060d5d7c09 amp_secgroup_list = ecf269e2-42fc-477b-9ce1-38d60c1d8d5d amp_flavor_id = c854d1e7-885f-4f7a-88a3-79728b561830 client_ca = /etc/octavia/certs/client_ca.cert.pem network_driver = allowed_address_pairs_driver compute_driver = compute_nova_driver amphora_driver = amphora_haproxy_rest_driver amp_active_retries = 100 amp_active_wait_sec = 2 loadbalancer_topology = SINGLE From: Michael Johnson Date: Friday, August 6, 2021 at 10:04 AM To: Chris Lyons Cc: openstack-discuss at lists.openstack.org Subject: Re: Octavia This is a kolla bug most likely. This could be caused by a few possible issues in kolla: 1. The images are owned by the wrong project. Kolla may deploy Octavia under a special service project. The image kolla uploads to glance must be uploaded under the service project as owner. A simple test to see if this is the issue would be to set the image as "public" such that all users of the cloud can see it. If a load balancer can be created after that change, the images are loaded under a project that Octavia cannot access. 2. The other possibility is kolla configured an alternate tag name. Check the [controller_worker] amp_image_tag setting [1] in octavia.conf. The images must be tagged with the same name as is configured in the octavia.conf for the controllers. Let us know either way (and ideally open a bug for kolla) what you find out. Michael [1] https://docs.openstack.org/octavia/latest/configuration/configref.html#controller_worker.amp_image_tag On Fri, Aug 6, 2021 at 5:52 AM Chris Lyons wrote: > > Octavia group, > > > > I created this story to see if I could get some assistance on an Octavia issue I am having with my infra. I did a vanilla install of Openstack Wallaby using the Kolla project with Octavia enabled and auto-configure set. Everything appeared to install fine. When I try to create a load balancer using the horizon console or the cli or through further installs such as cloudfoundry that require a loadbalancer, I get an error from glance about “No image found with tag amphora” even though the image does exist. I hope it is something simple or an oversight on my part. Could I get some ideas or places to look? > > > > Story: > > > > https://storyboard.openstack.org/#!/story/2009103 > > > > Kolla install followed: > > > > https://docs.openstack.org/kolla-ansible/latest/reference/networking/octavia.html > > > > cli output : > > > > [root at kolla ~]# openstack image list --tag amphora > > +--------------------------------------+---------------------+--------+ > > | ID | Name | Status | > > +--------------------------------------+---------------------+--------+ > > | 8f7398e7-7912-43b8-8131-e90f21c91ab4 | amphora | active | > > | 9bf14389-8521-4fb7-a7db-925f4dea1bf3 | amphora-x64-haproxy | active | > > +--------------------------------------+---------------------+--------+ > > [root at kolla ~]# > > > > My Infra scripts (relevant): > > > > https://github.com/mephmanx/openstack-scripts/blob/32363ef5753fdec381f713c747c90a5c14b3ae72/kolla.sh#L340 > > > > > > I am admin of said infra so if anyone has time or availability (or interest) to log in and take a look I would be happy to provide creds. > > > > Thank you for any time that you could provide or offer! This email has been scanned by Inbound Shield™. -------------- next part -------------- An HTML attachment was scrubbed... URL: From akanevsk at redhat.com Fri Aug 6 16:32:22 2021 From: akanevsk at redhat.com (Arkady Kanevsky) Date: Fri, 6 Aug 2021 11:32:22 -0500 Subject: [Swift][Interop] PTG time Message-ID: Swift team, Interop team would like time on Yoga PTG Monday or Tu between 21-22 UTC to discuss Interop guideline coverage for Swift. Thanks, Arkady -- Arkady Kanevsky, Ph.D. Phone: 972 707-6456 Corporate Phone: 919 729-5744 ext. 8176456 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dtantsur at redhat.com Fri Aug 6 16:34:41 2021 From: dtantsur at redhat.com (Dmitry Tantsur) Date: Fri, 6 Aug 2021 18:34:41 +0200 Subject: [Kolla][Kolla-Ansible] Ironic Node Cleaning Failed In-Reply-To: References: Message-ID: Hi! It might be a Kolla issue, please ping the Kolla devs. Dmitry On Fri, Aug 6, 2021 at 2:12 PM Anirudh Gupta wrote: > Hi Dmitry, > > I tried taking TCPDUMP while the Baremetal Node was booting up and looked > for tftp protocols and found there was some "*File Not Found" *traces for > bootx64.efi > > [image: image.png] > > Then, I found a related post on openstack Discuss which suggested to > enable IPXE > > http://lists.openstack.org/pipermail/openstack-discuss/2019-October/010329.html > > After re-deploying the setup with IPXE enabled, i found similar traces now > for *ipxe.efi file* > > [image: image.png] > > Can you please now suggest what possibly could be a miss in configuration > and steps to resolve it. > > For your reference, I am attaching the complete tcpdump logs of both the > Scenarios > > Looking forward to hearing from you. > > Regards > Anirudh Gupta > > > > > > On Thu, Aug 5, 2021 at 4:56 PM Anirudh Gupta wrote: > >> Hi Team, >> >> On further debugging, I found an error in neutron-server logs >> >> >> Failed to bind port 476d8175-ffc2-49ba-bb12-0a77c1f07e5f on host >> f4a43fa5-9c41-488e-a34d-714ae5a9d300 for vnic_type baremetal using segments >> [{'id': '1a5bbe96-2488-4971-925f-7c9346ba3ef5', 'network_type': 'flat', >> 'physical_network': 'physnet1', 'segmentation_id': None, 'network_id': >> '5b6cccec-ad86-4ed9-8d3c-72a31ec3a0d4'}] >> 2021-08-05 16:33:06.979 23 INFO neutron.plugins.ml2.plugin >> [req-54d11d51-7319-43ea-b70c-fe39d8aafe8a 21d6a238438e4294912746bcdc895e31 >> 3eca725754e1405eb178cc39bd0da3aa - default default] Attempt 9 to bind port >> 476d8175-ffc2-49ba-bb12-0a77c1f07e5f >> >> where 476d8175-ffc2-49ba-bb12-0a77c1f07e5f is the uuid of Baremetal Node >> >> However the port is created in openstack, but its state is down >> >> [ansible at localhost ~]$ openstack port list >> >> +--------------------------------------+------+-------------------+---------------------------------------------------------------------------+--------+ >> | ID | Name | MAC Address | Fixed >> IP Addresses | >> Status | >> >> +--------------------------------------+------+-------------------+---------------------------------------------------------------------------+--------+ >> | 07d6b83d-d83c-498f-8ba8-b4f21bef7249 | | fa:16:3e:38:05:9d | >> ip_address='10.0.1.200', subnet_id='7b72c158-2146-4bd6-893b-bd76b4a3e869' | >> ACTIVE | >> | 476d8175-ffc2-49ba-bb12-0a77c1f07e5f | | *98:f2:b3:3f:72:d8* | >> ip_address='10.0.1.202', subnet_id='7b72c158-2146-4bd6-893b-bd76b4a3e869' | *DOWN >> * | >> >> +--------------------------------------+------+-------------------+---------------------------------------------------------------------------+--------+ >> >> *98:f2:b3:3f:72:d8 *is the mac address of my Baremetal Node on which PXE >> is enabled. >> >> Can someone please help in resolving this issue. >> >> *Issue:* >> *Node goes in clean_failed from clean_wait.* >> >> Regards >> Anirudh Gupta >> >> On Tue, Aug 3, 2021 at 8:32 PM Anirudh Gupta wrote: >> >>> Hi Dmitry, >>> >>> I might be wrong, but as per my understanding if there would be an issue >>> in dnsmasq, then IP 20.20.20.10 would not have been assigned to the machine. >>> >>> TCPDUMP logs are as below: >>> >>> 20:16:58.938089 IP controller.bootps > 255.255.255.255.bootpc: >>> BOOTP/DHCP, Reply, length 312 >>> 20:17:02.765291 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, >>> Request from 98:f2:b3:3f:72:e5 (oui Unknown), length 359 >>> 20:17:02.766303 IP controller.bootps > 255.255.255.255.bootpc: >>> BOOTP/DHCP, Reply, length 312 >>> 20:17:26.944378 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, >>> Request from 98:f2:b3:3f:72:e5 (oui Unknown), length 347 >>> 20:17:26.944756 IP controller.bootps > 255.255.255.255.bootpc: >>> BOOTP/DHCP, Reply, length 312 >>> 20:17:30.763627 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, >>> Request from 98:f2:b3:3f:72:e5 (oui Unknown), length 359 >>> 20:17:30.764620 IP controller.bootps > 255.255.255.255.bootpc: >>> BOOTP/DHCP, Reply, length 312 >>> 20:17:54.938791 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, >>> Request from 98:f2:b3:3f:72:e5 (oui Unknown), length 347 >>> >>> Also the neutron dnsmasq logs and ironic inspector logs are attached in >>> the mail. >>> >>> Regards >>> Anirudh Gupta >>> >>> >>> On Tue, Aug 3, 2021 at 7:29 PM Dmitry Tantsur >>> wrote: >>> >>>> Hi, >>>> >>>> You need to check the dnsmasq logs (there are two dnsmasqs: from >>>> neutron and from ironic-inspector). tcpdump may also help to determine >>>> where the packages are lost. >>>> >>>> Dmitry >>>> >>>> On Fri, Jul 30, 2021 at 10:29 PM Anirudh Gupta >>>> wrote: >>>> >>>>> Hi Dmitry >>>>> >>>>> Thanks for your time. >>>>> >>>>> My system is getting IP 20.20.20.10 which is in the range defined in >>>>> ironic_dnsmasq_dhcp_range field under globals.yml file. >>>>> >>>>> ironic_dnsmasq_dhcp_range: "20.20.20.10,20.20.20.100" >>>>> >>>>> And in the cleaning network (public1), the range defined is >>>>> 20.20.20.150-20.20.20.200 >>>>> >>>>> As per my understanding, these 2 ranges should be mutually exclusive. >>>>> >>>>> Please suggest if my understanding is not correct. >>>>> >>>>> Any suggestions what should I do to resolve this issue? >>>>> >>>>> Regards >>>>> Anirudh Gupta >>>>> >>>>> >>>>> On Sat, 31 Jul, 2021, 12:06 am Dmitry Tantsur, >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Thu, Jul 29, 2021 at 6:05 PM Anirudh Gupta >>>>>> wrote: >>>>>> >>>>>>> Hi Team, >>>>>>> >>>>>>> In to the email below, I have some updated information:- >>>>>>> >>>>>>> Earlier the allocation range mentioned in " >>>>>>> *ironic_dnsmasq_dhcp_range*" in globals.yml had an overlapping >>>>>>> range with the cleaning network, due to which there was some issue in >>>>>>> receiving the DHCP request >>>>>>> >>>>>>> After creating a cleaning network with a separate allocation range, >>>>>>> I am successfully getting IP allocated to my Baremetal Node >>>>>>> >>>>>>> - openstack subnet create subnet1 --network public1 >>>>>>> --subnet-range 20.20.20.0/24 --allocation-pool >>>>>>> start=20.20.20.150,end=20.20.20.200 --ip-version=4 --gateway=20.20.20.1 >>>>>>> --dhcp >>>>>>> >>>>>>> >>>>>>> [image: image.png] >>>>>>> >>>>>>> After getting the IP, there is no further action on the node. From " >>>>>>> *clean_wait*", it goes into "*clean_failed*" state after around >>>>>>> half an hour. >>>>>>> >>>>>> >>>>>> The IP address is not from the cleaning range, it may come from >>>>>> inspection. You probably need to investigate your network topology, maybe >>>>>> use tcpdump. >>>>>> >>>>>> Unfortunately, I'm not fluent in Kolla to say if it can be a bug or >>>>>> not. >>>>>> >>>>>> Dmitry >>>>>> >>>>>> >>>>>>> >>>>>>> On verifying the logs, I could see the below error messages >>>>>>> >>>>>>> >>>>>>> - In */var/log/kolla/ironic/ironic-conductor.log*, we observed >>>>>>> the following error: >>>>>>> >>>>>>> ERROR ironic.conductor.utils [-] Cleaning for node >>>>>>> 3a56748e-a8ca-4dec-a332-ace18e6d494e failed. *Timeout reached while >>>>>>> cleaning the node. Please check if the ramdisk responsible for the cleaning >>>>>>> is running on the node. Failed on step {}.* >>>>>>> >>>>>>> >>>>>>> Note : For Cleaning the node, we have used the below images >>>>>>> >>>>>>> >>>>>>> >>>>>>> https://tarballs.openstack.org/ironic-python-agent/dib/files/ipa-centos8-master.kernel >>>>>>> >>>>>>> >>>>>>> https://tarballs.openstack.org/ironic-python-agent/dib/files/ipa-centos8-master.initramfs >>>>>>> >>>>>>> >>>>>>> - In /var/log/kolla/nova/nova-compute-ironic.log, we observed >>>>>>> the error >>>>>>> >>>>>>> ERROR nova.compute.manager [req-810ffedf-3343-471c-94db-85411984e6cc >>>>>>> - - - - -] No compute node record for host controller-ironic: >>>>>>> nova.exception_Remote.ComputeHostNotFound_Remote: Compute host >>>>>>> controller-ironic could not be found. >>>>>>> >>>>>>> >>>>>>> Can someone please help in this regard? >>>>>>> >>>>>>> Regards >>>>>>> Anirudh Gupta >>>>>>> >>>>>>> >>>>>>> On Tue, Jul 27, 2021 at 12:52 PM Anirudh Gupta >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Team, >>>>>>>> >>>>>>>> We have deployed 2 node kolla ansible *12.0.0* in order to deploy >>>>>>>> openstack *wallaby* release. We have also enabled ironic in order >>>>>>>> to provision the bare metal nodes. >>>>>>>> >>>>>>>> On each server we have 3 nics >>>>>>>> >>>>>>>> - *eno1* - OAM for external connectivity and endpoint's >>>>>>>> publicURL >>>>>>>> - *eno2* - Mgmt for internal communication between various >>>>>>>> openstack services. >>>>>>>> - *ens2f0* - Data Interface >>>>>>>> >>>>>>>> >>>>>>>> Corresponding to this we have defined the following fields in >>>>>>>> globals.yml >>>>>>>> >>>>>>>> >>>>>>>> - kolla_base_distro: "centos" >>>>>>>> - kolla_install_type: "source" >>>>>>>> - openstack_release: "wallaby" >>>>>>>> - network_interface: "eno2" # >>>>>>>> MGMT interface >>>>>>>> - kolla_external_vip_interface: "eno1" # OAM >>>>>>>> Interface >>>>>>>> - kolla_internal_vip_address: "192.168.10.3" # MGMT Subnet >>>>>>>> free ip >>>>>>>> - kolla_external_vip_address: "10.0.1.136" # OAM subnet >>>>>>>> free IP >>>>>>>> - neutron_external_interface: "ens2f0" # Data >>>>>>>> Interface >>>>>>>> - enable_neutron_provider_networks: "yes" >>>>>>>> >>>>>>>> Note: Only relevant fields are being shown in this query >>>>>>>> >>>>>>>> Also, for ironic following fields have been defined in globals.yml >>>>>>>> >>>>>>>> - enable_ironic: "yes" >>>>>>>> - enable_ironic_neutron_agent: "{{ enable_neutron | bool and >>>>>>>> enable_ironic | bool }}" >>>>>>>> - enable_horizon_ironic: "{{ enable_ironic | bool }}" >>>>>>>> - ironic_dnsmasq_interface: "*ens2f0*" # >>>>>>>> Data interface >>>>>>>> - ironic_dnsmasq_dhcp_range: "20.20.20.10,20.20.20.100" >>>>>>>> - ironic_dnsmasq_boot_file: "pxelinux.0" >>>>>>>> - ironic_cleaning_network: "public1" >>>>>>>> - ironic_dnsmasq_default_gateway: "20.20.20.1" >>>>>>>> >>>>>>>> >>>>>>>> After successful deployment, a flat provider network with the name >>>>>>>> public1 is being created in openstack using the below commands: >>>>>>>> >>>>>>>> >>>>>>>> - openstack network create public1 --provider-network-type flat >>>>>>>> --provider-physical-network physnet1 >>>>>>>> - openstack subnet create subnet1 --network public1 >>>>>>>> --subnet-range 20.20.20.0/24 --allocation-pool >>>>>>>> start=20.20.20.10,end=20.20.20.100 --ip-version=4 --gateway=20.20.20.1 >>>>>>>> --dhcp >>>>>>>> >>>>>>>> >>>>>>>> Issue/Queries: >>>>>>>> >>>>>>>> >>>>>>>> - Is the configuration done in globals.yml correct or is there >>>>>>>> anything else that needs to be done in order to separate control and data >>>>>>>> plane traffic? >>>>>>>> >>>>>>>> >>>>>>>> - Also I have set automated_cleaning as "true" in >>>>>>>> ironic-conductor conatiner settings.But after creating the baremetal node, >>>>>>>> we run "node manage" command which runs successfully. Running "*openstack >>>>>>>> baremetal node provide "* command powers on the >>>>>>>> machine, sets the boot mode on Network Boot but no DHCP request for that >>>>>>>> particular mac is obtained on the controller. Is there anything I am >>>>>>>> missing that needs to be done in order to make ironic work? >>>>>>>> >>>>>>>> Note: I have also verified that the nic is PXE enabled in system >>>>>>>> configuration setting >>>>>>>> >>>>>>>> Regards >>>>>>>> Anirudh Gupta >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> -- >>>>>> Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, >>>>>> Commercial register: Amtsgericht Muenchen, HRB 153243, >>>>>> Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, >>>>>> Michael O'Neill >>>>>> >>>>> >>>> >>>> -- >>>> Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, >>>> Commercial register: Amtsgericht Muenchen, HRB 153243, >>>> Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael >>>> O'Neill >>>> >>> -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 38285 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 185546 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 200447 bytes Desc: not available URL: From zigo at debian.org Fri Aug 6 17:11:53 2021 From: zigo at debian.org (Thomas Goirand) Date: Fri, 6 Aug 2021 19:11:53 +0200 Subject: [ops] Openstack Victoria SPICE configuration not working In-Reply-To: <2e6f3235c70b84f47730cce25888541b@dimlight.org> References: <2e6f3235c70b84f47730cce25888541b@dimlight.org> Message-ID: <390fe0dd-3253-5c2c-abb4-e9c9d97a808e@debian.org> On 8/5/21 7:25 PM, number9 wrote: > I have posted this on stackexchange, but am also asking here: > > > > Running openstack on Ubuntu 20.04 with a controller node and four > compute nodes. I am reading the instructions on configuring SPICE here. > I will admit, I found out about which packages to install from other > sites, as the instructions at the link do not actually list any software > that needs to be installed. > >     On the compute nodes and controller, I installed nova-spiceproxy >     On the controller I installed nova-spiceproxy and spice-html5 > > I followed the instructions in the link on configuring > /etc/nova/nova.conf on the controller and all compute nodes. > > In a nutshell, when you click on console in the dashboard, it simply says: > > Something went wrong! > > An unexpected error has occurred. Try refreshing the page. If that > doesn't help, contact your local administrator. > > I have parsed every log in /var/log on the compute and controller nodes > and found nothing that would indicate it is failing. > > On the compute node, I can do a ps aux and see that spice is running on > the instance I am trying to connect to. > > > I am really not sure where to go. I have tried VNC and noVNC also to no > avail, each time completely removing the old > configs and only adding the new. I have reverted back to SPICE to try > the "simple" approach. > > My relevant config items in /etc/nova/nova.conf from a compute node are: > > [DEFAULT] > vnc_eanabled = false > # yes, I know it is redundant, I am following the docs... > > [vnc] > enabled = false > > [spice] > enabled = true > agent_enabled = true > html5proxy_base_url = http://10.131.39.40:6082/spice_auto.html > # the above IP is the IP of the controller. > server_listen = 0.0.0.0 > server_proxyclient_address = 10.131.29.42 > # the above IP is the IP of the controller that I pulled this config from > html5proxy_host = 0.0.0.0 > html5proxy_port = 6082 > > Back on the controller node, in /etc/nova/nova.conf I have: > > [spice] > enabled = true > agent_enabled = false > html5proxy_host = 0.0.0.0 > html5proxy_port = 6082 > keymap = en_us > > I also have vnc false, as it is on the compute nodes. I will admit > further, I have tried at least 20 iterations of this, just leaving off > proxy ports, or thinking for a moment that the proxyclientaddress was > the controller node, but none of them work. I do restart nova on the > controller and all compute nodes after every change. > > Any ideas or directions would be appreciated. I wish there were logs, I > am perhaps missing them or need to turn on debugging of some kind. > Hi, The Debian packages have spice by default. Did you try it? Cheers, Thomas Goirand (zigo) From gmann at ghanshyammann.com Fri Aug 6 18:04:23 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Fri, 06 Aug 2021 13:04:23 -0500 Subject: [all][tc] What's happening in Technical Committee: summary 6th Aug, 21: Reading: 5 min Message-ID: <17b1ca336c8.e9cdb0d3373503.8948978323458077465@ghanshyammann.com> Hello Everyone, Here is last week's summary of the Technical Committee activities. 1. What we completed this week: ========================= * Added tap-as-a-service back to neutron stadium[1] * Defined Yoga release testing runtime[2] * Migration from Freenode to OFTC[3]. Only a few repo patches are pending to merge and can be merged in their own time[4]. 2. TC Meetings: ============ * TC held this week meeting on Thursday; you can find the full meeting logs in the below link: - https://meetings.opendev.org/meetings/tc/2021/tc.2021-08-05-15.00.log.html * We will have next week's meeting on Aug 12th, Thursday 15:00 UTC[5]. 3. Activities In progress: ================== TC Tracker for Xena cycle ------------------------------ TC is using the etherpad[6] for Xena cycle working item. We will be checking and updating the status biweekly in the same etherpad. Open Reviews ----------------- * Two open reviews for ongoing activities[7]. Wallaby testing runtime for centos8 vs centos8-stream ----------------------------------------------------------------- * Centos8 which is testing runtime for stable/wallaby cannot run on stable/wallaby testing anymore[8]. * We are discussing in TC whether to update the wallaby testing runtime from centos8->centos8-stream or stop testing centos8 itself. We will continue discussing it in the next TC meeting, feel free to join us if you have any input on this topic. Project Skyline(dashboard) proposal ------------------------------------------ * This is a new proposal about a new GUI for OpenStack name 'Skyline'. Discussion is in the initial stage and TC is not so clear if it is a proposal for a new separate project application or new repo/deliverables within the Horizon project. As the next step, TC asked to start the ML thread with all the details and then we can continue the discussion. * Meanwhile we will continue the discussion of 'required things (zuul, devstack integration etc ) we need to know about this proposal' in the next TC meeting Project updates ------------------- * Retiring js-openstack-lib [9] Yoga release community-wide goal ----------------------------------------- * Please add the possible candidates in this etherpad [10]. * Current status: Proposed "Secure RBAC" to select for Yoga cycle[11]. PTG planning ---------------- * TC booked three slots: ** 1. Monday 15-17 UTC for TC + Community Leaders ** 2. Thursday 13-17 UTC ** 3. Friday 13-17UTC * We are collecting the PTG topics in etherpad[12], feel free to add any topic you want to discuss. Test support for TLS default: ---------------------------------- * Rico has started a separate email thread over testing with tls-proxy enabled[13], we encourage projects to participate in that testing and help to enable the tls-proxy in gate testing. 4. How to contact the TC: ==================== If you would like to discuss or give feedback to TC, you can reach out to us in multiple ways: 1. Email: you can send the email with tag [tc] on openstack-discuss ML[14]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [15] 3. Office hours: The Technical Committee offers a weekly office hour every Tuesday at 0100 UTC [16] 4. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] https://review.opendev.org/c/openstack/governance/+/802833 [2] https://review.opendev.org/c/openstack/governance/+/799927 [3] https://etherpad.opendev.org/p/openstack-irc-migration-to-oftc [4] https://review.opendev.org/q/topic:%2522oftc%2522+status:open [5] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [6] https://etherpad.opendev.org/p/tc-xena-tracker [7] https://review.opendev.org/q/project:openstack/governance+status:open [8] https://review.opendev.org/c/openstack/devstack/+/803071 [9] https://review.opendev.org/c/openstack/governance/+/798540 [10] https://etherpad.opendev.org/p/y-series-goals [11] https://review.opendev.org/c/openstack/governance/+/803783 [12] https://etherpad.opendev.org/p/tc-yoga-ptg [13] http://lists.openstack.org/pipermail/openstack-discuss/2021-June/023000.html [14] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [15] http://eavesdrop.openstack.org/#Technical_Committee_Meeting [16] http://eavesdrop.openstack.org/#Technical_Committee_Office_hours -gmann From akanevsk at redhat.com Fri Aug 6 19:06:43 2021 From: akanevsk at redhat.com (Arkady Kanevsky) Date: Fri, 6 Aug 2021 14:06:43 -0500 Subject: [all][tc] What's happening in Technical Committee: summary 6th Aug, 21: Reading: 5 min In-Reply-To: <17b1ca336c8.e9cdb0d3373503.8948978323458077465@ghanshyammann.com> References: <17b1ca336c8.e9cdb0d3373503.8948978323458077465@ghanshyammann.com> Message-ID: Ghanshyam, should we schedule time at PTG with Interop to better understand starter kits and see if we should align interop guidelines with them? Thanks, Arkady On Fri, Aug 6, 2021 at 1:09 PM Ghanshyam Mann wrote: > Hello Everyone, > > Here is last week's summary of the Technical Committee activities. > > 1. What we completed this week: > ========================= > * Added tap-as-a-service back to neutron stadium[1] > * Defined Yoga release testing runtime[2] > * Migration from Freenode to OFTC[3]. Only a few repo patches are pending > to merge and can be merged in their own time[4]. > > 2. TC Meetings: > ============ > * TC held this week meeting on Thursday; you can find the full meeting > logs in the below link: > - > https://meetings.opendev.org/meetings/tc/2021/tc.2021-08-05-15.00.log.html > > * We will have next week's meeting on Aug 12th, Thursday 15:00 UTC[5]. > > > 3. Activities In progress: > ================== > TC Tracker for Xena cycle > ------------------------------ > TC is using the etherpad[6] for Xena cycle working item. We will be > checking and updating > the status biweekly in the same etherpad. > > Open Reviews > ----------------- > * Two open reviews for ongoing activities[7]. > > Wallaby testing runtime for centos8 vs centos8-stream > ----------------------------------------------------------------- > * Centos8 which is testing runtime for stable/wallaby cannot run on > stable/wallaby testing anymore[8]. > * We are discussing in TC whether to update the wallaby testing runtime > from centos8->centos8-stream or stop testing > centos8 itself. We will continue discussing it in the next TC meeting, > feel free to join us if you have any input on this topic. > > Project Skyline(dashboard) proposal > ------------------------------------------ > * This is a new proposal about a new GUI for OpenStack name 'Skyline'. > Discussion is in the initial stage and TC is not so clear > if it is a proposal for a new separate project application or new > repo/deliverables within the Horizon project. As the next step, > TC asked to start the ML thread with all the details and then we can > continue the discussion. > * Meanwhile we will continue the discussion of 'required things (zuul, > devstack integration etc ) we need to know about this proposal' > in the next TC meeting > > Project updates > ------------------- > * Retiring js-openstack-lib [9] > > Yoga release community-wide goal > ----------------------------------------- > * Please add the possible candidates in this etherpad [10]. > * Current status: Proposed "Secure RBAC" to select for Yoga cycle[11]. > > PTG planning > ---------------- > * TC booked three slots: > ** 1. Monday 15-17 UTC for TC + Community Leaders > ** 2. Thursday 13-17 UTC > ** 3. Friday 13-17UTC > * We are collecting the PTG topics in etherpad[12], feel free to add any > topic you want to discuss. > > Test support for TLS default: > ---------------------------------- > * Rico has started a separate email thread over testing with tls-proxy > enabled[13], we encourage projects > to participate in that testing and help to enable the tls-proxy in gate > testing. > > > 4. How to contact the TC: > ==================== > If you would like to discuss or give feedback to TC, you can reach out to > us in multiple ways: > > 1. Email: you can send the email with tag [tc] on openstack-discuss ML[14]. > 2. Weekly meeting: The Technical Committee conduct a weekly meeting every > Thursday 15 UTC [15] > 3. Office hours: The Technical Committee offers a weekly office hour every > Tuesday at 0100 UTC [16] > 4. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. > > [1] https://review.opendev.org/c/openstack/governance/+/802833 > [2] https://review.opendev.org/c/openstack/governance/+/799927 > [3] https://etherpad.opendev.org/p/openstack-irc-migration-to-oftc > [4] https://review.opendev.org/q/topic:%2522oftc%2522+status:open > [5] > https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting > [6] https://etherpad.opendev.org/p/tc-xena-tracker > [7] https://review.opendev.org/q/project:openstack/governance+status:open > [8] https://review.opendev.org/c/openstack/devstack/+/803071 > [9] https://review.opendev.org/c/openstack/governance/+/798540 > [10] https://etherpad.opendev.org/p/y-series-goals > [11] https://review.opendev.org/c/openstack/governance/+/803783 > [12] https://etherpad.opendev.org/p/tc-yoga-ptg > [13] > http://lists.openstack.org/pipermail/openstack-discuss/2021-June/023000.html > [14] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss > [15] http://eavesdrop.openstack.org/#Technical_Committee_Meeting > [16] http://eavesdrop.openstack.org/#Technical_Committee_Office_hours > > -gmann > > -- Arkady Kanevsky, Ph.D. Phone: 972 707-6456 Corporate Phone: 919 729-5744 ext. 8176456 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Fri Aug 6 19:22:04 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Fri, 06 Aug 2021 14:22:04 -0500 Subject: [all][tc] What's happening in Technical Committee: summary 6th Aug, 21: Reading: 5 min In-Reply-To: References: <17b1ca336c8.e9cdb0d3373503.8948978323458077465@ghanshyammann.com> Message-ID: <17b1cea566d.bb4dd425374727.3563622176129697950@ghanshyammann.com> ---- On Fri, 06 Aug 2021 14:06:43 -0500 Arkady Kanevsky wrote ---- > Ghanshyam,should we schedule time at PTG with Interop to better understand starter kits and see if we should align interop guidelines with them?Thanks,Arkady Sure Arkady, please add the topic in the below PTG. https://etherpad.opendev.org/p/tc-yoga-ptg -gmann > On Fri, Aug 6, 2021 at 1:09 PM Ghanshyam Mann wrote: > Hello Everyone, > > Here is last week's summary of the Technical Committee activities. > > 1. What we completed this week: > ========================= > * Added tap-as-a-service back to neutron stadium[1] > * Defined Yoga release testing runtime[2] > * Migration from Freenode to OFTC[3]. Only a few repo patches are pending to merge and can be merged in their own time[4]. > > 2. TC Meetings: > ============ > * TC held this week meeting on Thursday; you can find the full meeting logs in the below link: > - https://meetings.opendev.org/meetings/tc/2021/tc.2021-08-05-15.00.log.html > > * We will have next week's meeting on Aug 12th, Thursday 15:00 UTC[5]. > > > 3. Activities In progress: > ================== > TC Tracker for Xena cycle > ------------------------------ > TC is using the etherpad[6] for Xena cycle working item. We will be checking and updating > the status biweekly in the same etherpad. > > Open Reviews > ----------------- > * Two open reviews for ongoing activities[7]. > > Wallaby testing runtime for centos8 vs centos8-stream > ----------------------------------------------------------------- > * Centos8 which is testing runtime for stable/wallaby cannot run on stable/wallaby testing anymore[8]. > * We are discussing in TC whether to update the wallaby testing runtime from centos8->centos8-stream or stop testing > centos8 itself. We will continue discussing it in the next TC meeting, feel free to join us if you have any input on this topic. > > Project Skyline(dashboard) proposal > ------------------------------------------ > * This is a new proposal about a new GUI for OpenStack name 'Skyline'. Discussion is in the initial stage and TC is not so clear > if it is a proposal for a new separate project application or new repo/deliverables within the Horizon project. As the next step, > TC asked to start the ML thread with all the details and then we can continue the discussion. > * Meanwhile we will continue the discussion of 'required things (zuul, devstack integration etc ) we need to know about this proposal' > in the next TC meeting > > Project updates > ------------------- > * Retiring js-openstack-lib [9] > > Yoga release community-wide goal > ----------------------------------------- > * Please add the possible candidates in this etherpad [10]. > * Current status: Proposed "Secure RBAC" to select for Yoga cycle[11]. > > PTG planning > ---------------- > * TC booked three slots: > ** 1. Monday 15-17 UTC for TC + Community Leaders > ** 2. Thursday 13-17 UTC > ** 3. Friday 13-17UTC > * We are collecting the PTG topics in etherpad[12], feel free to add any topic you want to discuss. > > Test support for TLS default: > ---------------------------------- > * Rico has started a separate email thread over testing with tls-proxy enabled[13], we encourage projects > to participate in that testing and help to enable the tls-proxy in gate testing. > > > 4. How to contact the TC: > ==================== > If you would like to discuss or give feedback to TC, you can reach out to us in multiple ways: > > 1. Email: you can send the email with tag [tc] on openstack-discuss ML[14]. > 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [15] > 3. Office hours: The Technical Committee offers a weekly office hour every Tuesday at 0100 UTC [16] > 4. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. > > [1] https://review.opendev.org/c/openstack/governance/+/802833 > [2] https://review.opendev.org/c/openstack/governance/+/799927 > [3] https://etherpad.opendev.org/p/openstack-irc-migration-to-oftc > [4] https://review.opendev.org/q/topic:%2522oftc%2522+status:open > [5] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting > [6] https://etherpad.opendev.org/p/tc-xena-tracker > [7] https://review.opendev.org/q/project:openstack/governance+status:open > [8] https://review.opendev.org/c/openstack/devstack/+/803071 > [9] https://review.opendev.org/c/openstack/governance/+/798540 > [10] https://etherpad.opendev.org/p/y-series-goals > [11] https://review.opendev.org/c/openstack/governance/+/803783 > [12] https://etherpad.opendev.org/p/tc-yoga-ptg > [13] http://lists.openstack.org/pipermail/openstack-discuss/2021-June/023000.html > [14] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss > [15] http://eavesdrop.openstack.org/#Technical_Committee_Meeting > [16] http://eavesdrop.openstack.org/#Technical_Committee_Office_hours > > -gmann > > > > -- > Arkady Kanevsky, Ph.D.Phone: 972 707-6456Corporate Phone: 919 729-5744 ext. 8176456 > From haiwu.us at gmail.com Fri Aug 6 19:24:09 2021 From: haiwu.us at gmail.com (hai wu) Date: Fri, 6 Aug 2021 14:24:09 -0500 Subject: how to update existing vm instances 'availability_zone' field in nova database 'instances' table In-Reply-To: References: Message-ID: It seems this 'AvailabilityZoneFilter' is really buggy. The 'instances' table 'availability_zone' field was already updated to match the target desired zone name, but 'AvailabilityZoneFilter' kept rejecting the request. I already restarted nova-api, nova-conductor, nova-scheduler services after updating this database field value, but that's not helpful. In the source code in file '/usr/lib/python3/dist-packages/nova/scheduler/filters/availability_zone_filter.py', how does 'spec_obj' got its availability_zone value? I don't understand this particular code. This issue is really frustrating .. def host_passes(self, host_state, spec_obj): availability_zone = spec_obj.availability_zone On Wed, Aug 4, 2021 at 5:11 PM hai wu wrote: > > Hi, > > How to update existing vm instances 'availability_zone' field in nova > database 'instances' table? It turns out there are many VMs with > default 'nova' availability zone, while the hypervisors are with > another different target aggregate/availability zone name, thus live > migration for these VMs are failing. > > The strange thing is that the 'OS-EXT-AZ:availability_zone' output > from 'openstack server show VM_NAME' is showing these VMs are already > with the target availibity_zone name. No idea why we have this > inconsistency. > > Would it be ok to just update database table entry directly to set > 'availility_zone' to different value for these VMs? Or there might be > better alternatives I am not aware of? > > Thanks, > Hai From akanevsk at redhat.com Fri Aug 6 20:43:31 2021 From: akanevsk at redhat.com (Arkady Kanevsky) Date: Fri, 6 Aug 2021 15:43:31 -0500 Subject: [all][tc] What's happening in Technical Committee: summary 6th Aug, 21: Reading: 5 min In-Reply-To: <17b1cea566d.bb4dd425374727.3563622176129697950@ghanshyammann.com> References: <17b1ca336c8.e9cdb0d3373503.8948978323458077465@ghanshyammann.com> <17b1cea566d.bb4dd425374727.3563622176129697950@ghanshyammann.com> Message-ID: done. Please, let me know which day and time it will be scheduled and I will be there. On Fri, Aug 6, 2021 at 2:22 PM Ghanshyam Mann wrote: > ---- On Fri, 06 Aug 2021 14:06:43 -0500 Arkady Kanevsky < > akanevsk at redhat.com> wrote ---- > > Ghanshyam,should we schedule time at PTG with Interop to better > understand starter kits and see if we should align interop guidelines with > them?Thanks,Arkady > > Sure Arkady, please add the topic in the below PTG. > > https://etherpad.opendev.org/p/tc-yoga-ptg > > -gmann > > > On Fri, Aug 6, 2021 at 1:09 PM Ghanshyam Mann > wrote: > > Hello Everyone, > > > > Here is last week's summary of the Technical Committee activities. > > > > 1. What we completed this week: > > ========================= > > * Added tap-as-a-service back to neutron stadium[1] > > * Defined Yoga release testing runtime[2] > > * Migration from Freenode to OFTC[3]. Only a few repo patches are > pending to merge and can be merged in their own time[4]. > > > > 2. TC Meetings: > > ============ > > * TC held this week meeting on Thursday; you can find the full meeting > logs in the below link: > > - > https://meetings.opendev.org/meetings/tc/2021/tc.2021-08-05-15.00.log.html > > > > * We will have next week's meeting on Aug 12th, Thursday 15:00 UTC[5]. > > > > > > 3. Activities In progress: > > ================== > > TC Tracker for Xena cycle > > ------------------------------ > > TC is using the etherpad[6] for Xena cycle working item. We will be > checking and updating > > the status biweekly in the same etherpad. > > > > Open Reviews > > ----------------- > > * Two open reviews for ongoing activities[7]. > > > > Wallaby testing runtime for centos8 vs centos8-stream > > ----------------------------------------------------------------- > > * Centos8 which is testing runtime for stable/wallaby cannot run on > stable/wallaby testing anymore[8]. > > * We are discussing in TC whether to update the wallaby testing runtime > from centos8->centos8-stream or stop testing > > centos8 itself. We will continue discussing it in the next TC meeting, > feel free to join us if you have any input on this topic. > > > > Project Skyline(dashboard) proposal > > ------------------------------------------ > > * This is a new proposal about a new GUI for OpenStack name 'Skyline'. > Discussion is in the initial stage and TC is not so clear > > if it is a proposal for a new separate project application or new > repo/deliverables within the Horizon project. As the next step, > > TC asked to start the ML thread with all the details and then we can > continue the discussion. > > * Meanwhile we will continue the discussion of 'required things (zuul, > devstack integration etc ) we need to know about this proposal' > > in the next TC meeting > > > > Project updates > > ------------------- > > * Retiring js-openstack-lib [9] > > > > Yoga release community-wide goal > > ----------------------------------------- > > * Please add the possible candidates in this etherpad [10]. > > * Current status: Proposed "Secure RBAC" to select for Yoga cycle[11]. > > > > PTG planning > > ---------------- > > * TC booked three slots: > > ** 1. Monday 15-17 UTC for TC + Community Leaders > > ** 2. Thursday 13-17 UTC > > ** 3. Friday 13-17UTC > > * We are collecting the PTG topics in etherpad[12], feel free to add > any topic you want to discuss. > > > > Test support for TLS default: > > ---------------------------------- > > * Rico has started a separate email thread over testing with tls-proxy > enabled[13], we encourage projects > > to participate in that testing and help to enable the tls-proxy in gate > testing. > > > > > > 4. How to contact the TC: > > ==================== > > If you would like to discuss or give feedback to TC, you can reach out > to us in multiple ways: > > > > 1. Email: you can send the email with tag [tc] on openstack-discuss > ML[14]. > > 2. Weekly meeting: The Technical Committee conduct a weekly meeting > every Thursday 15 UTC [15] > > 3. Office hours: The Technical Committee offers a weekly office hour > every Tuesday at 0100 UTC [16] > > 4. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. > > > > [1] https://review.opendev.org/c/openstack/governance/+/802833 > > [2] https://review.opendev.org/c/openstack/governance/+/799927 > > [3] https://etherpad.opendev.org/p/openstack-irc-migration-to-oftc > > [4] https://review.opendev.org/q/topic:%2522oftc%2522+status:open > > [5] > https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting > > [6] https://etherpad.opendev.org/p/tc-xena-tracker > > [7] > https://review.opendev.org/q/project:openstack/governance+status:open > > [8] https://review.opendev.org/c/openstack/devstack/+/803071 > > [9] https://review.opendev.org/c/openstack/governance/+/798540 > > [10] https://etherpad.opendev.org/p/y-series-goals > > [11] https://review.opendev.org/c/openstack/governance/+/803783 > > [12] https://etherpad.opendev.org/p/tc-yoga-ptg > > [13] > http://lists.openstack.org/pipermail/openstack-discuss/2021-June/023000.html > > [14] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss > > [15] http://eavesdrop.openstack.org/#Technical_Committee_Meeting > > [16] http://eavesdrop.openstack.org/#Technical_Committee_Office_hours > > > > -gmann > > > > > > > > -- > > Arkady Kanevsky, Ph.D.Phone: 972 707-6456Corporate Phone: 919 729-5744 > ext. 8176456 > > > > -- Arkady Kanevsky, Ph.D. Phone: 972 707-6456 Corporate Phone: 919 729-5744 ext. 8176456 -------------- next part -------------- An HTML attachment was scrubbed... URL: From DHilsbos at performair.com Fri Aug 6 20:51:25 2021 From: DHilsbos at performair.com (DHilsbos at performair.com) Date: Fri, 6 Aug 2021 20:51:25 +0000 Subject: [neutron][ops] VLAN Provider Network In-Reply-To: <20210802150520.sitqyjqs3r4cxlyz@p1.localdomain> References: <0670B960225633449A24709C291A52525124C8B1@COM01.performair.local> <20210802150520.sitqyjqs3r4cxlyz@p1.localdomain> Message-ID: <0670B960225633449A24709C291A525251263901@COM01.performair.local> All; I apologize for disappearing from this discussion, I got really busy. Static IPs still could not ping each other, I did test that. I noticed that, even though the subnet was selected for DHCP, the DHCP port didn't exist. I disabled DHCP for the subnet, and then re-enabled it, and everything started working. The port disappeared again later, however, when there weren't any VMs in the project / attached to the network. I think I know what happened, and possibly even why, though I have no evidence of it. When I originally configured the actual provider network for the addition of this VLAN, I missed adding it to the network nodes' connection. Thus when I configured the network & subnet on OpenStack, the network node failed... something? I fixed the underlying network issue, then, several days later, removed and re-added the DHCP support, as noted above, and things started working. Thank you, Dominic L. Hilsbos, MBA Vice President - Information Technology Perform Air International Inc. DHilsbos at PerformAir.com www.PerformAir.com -----Original Message----- From: Slawek Kaplonski [mailto:skaplons at redhat.com] Sent: Monday, August 2, 2021 8:05 AM To: Dominic Hilsbos Cc: openstack-discuss at lists.openstack.org Subject: Re: [neutron][ops] VLAN Provider Network Hi, On Mon, Jul 26, 2021 at 09:30:59PM +0000, DHilsbos at performair.com wrote: > All; > > We're using OpenStack Victoria, with OVS networking (no OVN). I'm having some problems with a VLAN provider network that I added to my OpenStack. I have other VLAN provider networks, that I based this one off of. > > Instances are getting the tap interfaces, but these interfaces are not getting IP addresses, and when a static IP is given, they can't ping either the DHCP address or the gateway address. Can instances with static IPs ping each other or it also don't works? > > I have checked the switch configuration, to verify the VLAN is bound appropriately. I rebooted the whole cluster to ensure the configuration change applied. > > Here's a snip our plugin.ini > [ml2_type_vlan] > network_vlan_ranges = provider_core:55:55,provider_core:64:64,... > > 64 works, 55, doesn't. > > I'm not seeing anything concerning in > /var/log/openvswitch/ovs-vswitchd.log > > I'm sure it's something dumb, but I'm not seeing it. Please check also configuration of the OVS agent on the compute nodes where instances are configured and on the servers where DHCP agent's are running. > > Any suggestions for what else to look at? You should also check with tcpdump where packets are actually dropped. You can start checking on the physical interface in the host if there are packets with vlan_id 55 (the one which don't works). If packets are going out from compute node, You can check on Your switches and move to the next server. If packets are not on that physical interface, You should look in the Openflow rules configuration in the openvswitch on the compute node. > > Thank you, > > Dominic L. Hilsbos, MBA > Vice President - Information Technology Perform Air International Inc. > DHilsbos at PerformAir.com > www.PerformAir.com > > -- Slawek Kaplonski Principal Software Engineer Red Hat From DHilsbos at performair.com Fri Aug 6 20:54:22 2021 From: DHilsbos at performair.com (DHilsbos at performair.com) Date: Fri, 6 Aug 2021 20:54:22 +0000 Subject: [ops][nova][victoria] Power State = Suspended? In-Reply-To: <0670B960225633449A24709C291A52525125F6B6@COM01.performair.local> References: <0670B960225633449A24709C291A52525125F40D@COM01.performair.local> <9e5c73c2a2b9513c8c44c19f6d370411c016b169.camel@redhat.com> <0670B960225633449A24709C291A52525125F6B6@COM01.performair.local> Message-ID: <0670B960225633449A24709C291A52525126392D@COM01.performair.local> All; Like with the network issue conversation that I disappeared from, I apologize for disappearing from this conversation. I've pretty much confirmed that this issue is caused by the Windows 10 guest operating system going into / trying to go into a sleep state. Using the exact same image, if I leave sleep enabled, this un-recoverable state is guaranteed. If I disable sleep, I haven't yet run into this problem. Thank you, Dominic L. Hilsbos, MBA Vice President – Information Technology Perform Air International Inc. DHilsbos at PerformAir.com www.PerformAir.com -----Original Message----- From: DHilsbos at performair.com [mailto:DHilsbos at performair.com] Sent: Wednesday, August 4, 2021 10:48 AM To: openstack-discuss at lists.openstack.org Cc: smooney at redhat.com Subject: RE: [ops][nova][victoria] Power State = Suspended? Sean; Thank you. Again, this was not Status. The VM was not suspended through OpenStack. Suspended showed up in the Power State. Normally, if I suspend a VM through OpenStack, Status = Suspended, Power State = Shut Down. In this case Status = Active, Power State = Supsended. Is it possible that the Windows OS inside the VM went into a Suspended state, and libvirt / kvm / qemu recognized that? Thank you, Dominic L. Hilsbos, MBA Vice President – Information Technology Perform Air International Inc. DHilsbos at PerformAir.com www.PerformAir.com -----Original Message----- From: Sean Mooney [mailto:smooney at redhat.com] Sent: Wednesday, August 4, 2021 10:37 AM To: Dominic Hilsbos; openstack-discuss at lists.openstack.org Subject: Re: [ops][nova][victoria] Power State = Suspended? On Wed, 2021-08-04 at 16:39 +0000, DHilsbos at performair.com wrote: > All; > > I had something unusual happen this morning; one of my VMs was showing "Suspended" under the Power State in the Horizon dashboard. > > I've never seen that. What does it mean? > > Any search that I do points me to a bunch of resources for Status Suspended. suspened is like hibernate in windows. in the libvirt driver we call libvirt managed_save api this pauses the guests, snapshots the guest ram and saves it to disk then stops the instance. so this frees the guest ram on the host and save it to a file so that we can recreate the vm and resume it as if nothing happened. nova also supports pause. pause is similar to suspend but much less invasive. pause jsut stops the execution of the guest cpus but the guest qemu process is still running. if you have pci passtough device when you use suspend the device are detach before its suspended  and then reattached when its resumed. if you use pause we dont need to do this since the dma regoins for the passthough devices are never touched. different virt dirver may or may not supprot pause/suspend and they may work differently. suspeedn is bascally supend the guest execution to disk where as pause is like you laptos sleep or suspend to ram. in a could env i dont really think either are that useful if im being honest and im not sure we woudl add them today if they did not really exits, generally if the vm is not running you should shleve it. from a schduler point of view pausign, suspending and stoping an insntce all use the same amount of resouces as a runnign instnace so form a billing perpsective public cloud will change you the same for all 4 states. shelve instance are only using disk space and floating ips so genrealy that will be reflected in the cost and it will be much cheaper on a public cloud to shelve an instnace. > > Thank you, > > Dominic L. Hilsbos, MBA > Vice President - Information Technology > Perform Air International Inc. > DHilsbos at PerformAir.com > www.PerformAir.com > > From number9 at dimlight.org Fri Aug 6 21:32:39 2021 From: number9 at dimlight.org (number9) Date: Fri, 06 Aug 2021 16:32:39 -0500 Subject: [ops] Openstack Victoria SPICE configuration not working In-Reply-To: <390fe0dd-3253-5c2c-abb4-e9c9d97a808e@debian.org> References: <2e6f3235c70b84f47730cce25888541b@dimlight.org> <390fe0dd-3253-5c2c-abb4-e9c9d97a808e@debian.org> Message-ID: I am not sure I follow you. I am on ubuntu... do I need to install some debian spice package to get this working? On 2021-08-06 12:11, Thomas Goirand wrote: > On 8/5/21 7:25 PM, number9 wrote: >> I have posted this on stackexchange, but am also asking here: >> >> >> >> Running openstack on Ubuntu 20.04 with a controller node and four >> compute nodes. I am reading the instructions on configuring SPICE >> here. >> I will admit, I found out about which packages to install from other >> sites, as the instructions at the link do not actually list any >> software >> that needs to be installed. >> >>     On the compute nodes and controller, I installed nova-spiceproxy >>     On the controller I installed nova-spiceproxy and spice-html5 >> >> I followed the instructions in the link on configuring >> /etc/nova/nova.conf on the controller and all compute nodes. >> >> In a nutshell, when you click on console in the dashboard, it simply >> says: >> >> Something went wrong! >> >> An unexpected error has occurred. Try refreshing the page. If that >> doesn't help, contact your local administrator. >> >> I have parsed every log in /var/log on the compute and controller >> nodes >> and found nothing that would indicate it is failing. >> >> On the compute node, I can do a ps aux and see that spice is running >> on >> the instance I am trying to connect to. >> >> >> I am really not sure where to go. I have tried VNC and noVNC also to >> no >> avail, each time completely removing the old >> configs and only adding the new. I have reverted back to SPICE to try >> the "simple" approach. >> >> My relevant config items in /etc/nova/nova.conf from a compute node >> are: >> >> [DEFAULT] >> vnc_eanabled = false >> # yes, I know it is redundant, I am following the docs... >> >> [vnc] >> enabled = false >> >> [spice] >> enabled = true >> agent_enabled = true >> html5proxy_base_url = http://10.131.39.40:6082/spice_auto.html >> # the above IP is the IP of the controller. >> server_listen = 0.0.0.0 >> server_proxyclient_address = 10.131.29.42 >> # the above IP is the IP of the controller that I pulled this config >> from >> html5proxy_host = 0.0.0.0 >> html5proxy_port = 6082 >> >> Back on the controller node, in /etc/nova/nova.conf I have: >> >> [spice] >> enabled = true >> agent_enabled = false >> html5proxy_host = 0.0.0.0 >> html5proxy_port = 6082 >> keymap = en_us >> >> I also have vnc false, as it is on the compute nodes. I will admit >> further, I have tried at least 20 iterations of this, just leaving off >> proxy ports, or thinking for a moment that the proxyclientaddress was >> the controller node, but none of them work. I do restart nova on the >> controller and all compute nodes after every change. >> >> Any ideas or directions would be appreciated. I wish there were logs, >> I >> am perhaps missing them or need to turn on debugging of some kind. >> > > Hi, > > The Debian packages have spice by default. Did you try it? > > Cheers, > > Thomas Goirand (zigo) I From gmann at ghanshyammann.com Sat Aug 7 00:15:20 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Fri, 06 Aug 2021 19:15:20 -0500 Subject: [all][tc] What's happening in Technical Committee: summary 6th Aug, 21: Reading: 5 min In-Reply-To: References: <17b1ca336c8.e9cdb0d3373503.8948978323458077465@ghanshyammann.com> <17b1cea566d.bb4dd425374727.3563622176129697950@ghanshyammann.com> Message-ID: <17b1df6d496.10d9828b6378122.8824536001930929076@ghanshyammann.com> Thanks, Arkady, I will ping you once the schedule is finalized. -gmann ---- On Fri, 06 Aug 2021 15:43:31 -0500 Arkady Kanevsky wrote ---- > done.Please, let me know which day and time it will be scheduled and I will be there. > On Fri, Aug 6, 2021 at 2:22 PM Ghanshyam Mann wrote: > ---- On Fri, 06 Aug 2021 14:06:43 -0500 Arkady Kanevsky wrote ---- > > Ghanshyam,should we schedule time at PTG with Interop to better understand starter kits and see if we should align interop guidelines with them?Thanks,Arkady > > Sure Arkady, please add the topic in the below PTG. > > https://etherpad.opendev.org/p/tc-yoga-ptg > > -gmann > > > On Fri, Aug 6, 2021 at 1:09 PM Ghanshyam Mann wrote: > > Hello Everyone, > > > > Here is last week's summary of the Technical Committee activities. > > > > 1. What we completed this week: > > ========================= > > * Added tap-as-a-service back to neutron stadium[1] > > * Defined Yoga release testing runtime[2] > > * Migration from Freenode to OFTC[3]. Only a few repo patches are pending to merge and can be merged in their own time[4]. > > > > 2. TC Meetings: > > ============ > > * TC held this week meeting on Thursday; you can find the full meeting logs in the below link: > > - https://meetings.opendev.org/meetings/tc/2021/tc.2021-08-05-15.00.log.html > > > > * We will have next week's meeting on Aug 12th, Thursday 15:00 UTC[5]. > > > > > > 3. Activities In progress: > > ================== > > TC Tracker for Xena cycle > > ------------------------------ > > TC is using the etherpad[6] for Xena cycle working item. We will be checking and updating > > the status biweekly in the same etherpad. > > > > Open Reviews > > ----------------- > > * Two open reviews for ongoing activities[7]. > > > > Wallaby testing runtime for centos8 vs centos8-stream > > ----------------------------------------------------------------- > > * Centos8 which is testing runtime for stable/wallaby cannot run on stable/wallaby testing anymore[8]. > > * We are discussing in TC whether to update the wallaby testing runtime from centos8->centos8-stream or stop testing > > centos8 itself. We will continue discussing it in the next TC meeting, feel free to join us if you have any input on this topic. > > > > Project Skyline(dashboard) proposal > > ------------------------------------------ > > * This is a new proposal about a new GUI for OpenStack name 'Skyline'. Discussion is in the initial stage and TC is not so clear > > if it is a proposal for a new separate project application or new repo/deliverables within the Horizon project. As the next step, > > TC asked to start the ML thread with all the details and then we can continue the discussion. > > * Meanwhile we will continue the discussion of 'required things (zuul, devstack integration etc ) we need to know about this proposal' > > in the next TC meeting > > > > Project updates > > ------------------- > > * Retiring js-openstack-lib [9] > > > > Yoga release community-wide goal > > ----------------------------------------- > > * Please add the possible candidates in this etherpad [10]. > > * Current status: Proposed "Secure RBAC" to select for Yoga cycle[11]. > > > > PTG planning > > ---------------- > > * TC booked three slots: > > ** 1. Monday 15-17 UTC for TC + Community Leaders > > ** 2. Thursday 13-17 UTC > > ** 3. Friday 13-17UTC > > * We are collecting the PTG topics in etherpad[12], feel free to add any topic you want to discuss. > > > > Test support for TLS default: > > ---------------------------------- > > * Rico has started a separate email thread over testing with tls-proxy enabled[13], we encourage projects > > to participate in that testing and help to enable the tls-proxy in gate testing. > > > > > > 4. How to contact the TC: > > ==================== > > If you would like to discuss or give feedback to TC, you can reach out to us in multiple ways: > > > > 1. Email: you can send the email with tag [tc] on openstack-discuss ML[14]. > > 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [15] > > 3. Office hours: The Technical Committee offers a weekly office hour every Tuesday at 0100 UTC [16] > > 4. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. > > > > [1] https://review.opendev.org/c/openstack/governance/+/802833 > > [2] https://review.opendev.org/c/openstack/governance/+/799927 > > [3] https://etherpad.opendev.org/p/openstack-irc-migration-to-oftc > > [4] https://review.opendev.org/q/topic:%2522oftc%2522+status:open > > [5] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting > > [6] https://etherpad.opendev.org/p/tc-xena-tracker > > [7] https://review.opendev.org/q/project:openstack/governance+status:open > > [8] https://review.opendev.org/c/openstack/devstack/+/803071 > > [9] https://review.opendev.org/c/openstack/governance/+/798540 > > [10] https://etherpad.opendev.org/p/y-series-goals > > [11] https://review.opendev.org/c/openstack/governance/+/803783 > > [12] https://etherpad.opendev.org/p/tc-yoga-ptg > > [13] http://lists.openstack.org/pipermail/openstack-discuss/2021-June/023000.html > > [14] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss > > [15] http://eavesdrop.openstack.org/#Technical_Committee_Meeting > > [16] http://eavesdrop.openstack.org/#Technical_Committee_Office_hours > > > > -gmann > > > > > > > > -- > > Arkady Kanevsky, Ph.D.Phone: 972 707-6456Corporate Phone: 919 729-5744 ext. 8176456 > > > > > > -- > Arkady Kanevsky, Ph.D.Phone: 972 707-6456Corporate Phone: 919 729-5744 ext. 8176456 > From berndbausch at gmail.com Sat Aug 7 00:21:26 2021 From: berndbausch at gmail.com (Bernd Bausch) Date: Sat, 7 Aug 2021 09:21:26 +0900 Subject: Octavia In-Reply-To: References: Message-ID: <26e5229a-0584-c5f5-e85f-6547b158dc47@gmail.com> I had that problem when setting up a Victoria Kolla cluster, and it turned out that the image was owned by the wrong project, as suspected by Michael. I changed the owner in Glance, and it worked. The owner must be 4269b3cd5452416e8153f5b4f5adcf0c in Chris' case (openstack image set --project 4269b3cd5452416e8153f5b4f5adcf0c amphora-image-name). I don't think this is a Kolla problem, as Kolla leaves the responsibility of building and uploading the image to the administrator (or it did so at Victoria). Bernd Bausch On 2021/08/06 11:07 PM, Chris Lyons wrote: > > Both of those appear ok….  I do have the amphora image set to public > and I see this in the Octavia.conf file: > > [controller_worker] > > amp_ssh_key_name = octavia_ssh_key > > amp_image_tag = amphora > > amp_image_owner_id = 4269b3cd5452416e8153f5b4f5adcf0c > > amp_boot_network_list = adfa01a9-55bd-42ea-b849-81060d5d7c09 > > amp_secgroup_list = ecf269e2-42fc-477b-9ce1-38d60c1d8d5d > > amp_flavor_id = c854d1e7-885f-4f7a-88a3-79728b561830 > > client_ca = /etc/octavia/certs/client_ca.cert.pem > > network_driver = allowed_address_pairs_driver > > compute_driver = compute_nova_driver > > amphora_driver = amphora_haproxy_rest_driver > > amp_active_retries = 100 > > amp_active_wait_sec = 2 > > loadbalancer_topology = SINGLE > > *From: *Michael Johnson > *Date: *Friday, August 6, 2021 at 10:04 AM > *To: *Chris Lyons > *Cc: *openstack-discuss at lists.openstack.org > > *Subject: *Re: Octavia > > This is a kolla bug most likely. > > This could be caused by a few possible issues in kolla: > > 1. The images are owned by the wrong project.  Kolla may deploy > Octavia under a special service project. The image kolla uploads to > glance must be uploaded under the service project as owner. A simple > test to see if this is the issue would be to set the image as "public" > such that all users of the cloud can see it. If a load balancer can be > created after that change, the images are loaded under a project that > Octavia cannot access. > 2. The other possibility is kolla configured an alternate tag name. > Check the [controller_worker] amp_image_tag setting [1] in > octavia.conf. The images must be tagged with the same name as is > configured in the octavia.conf for the controllers. > > Let us know either way (and ideally open a bug for kolla) what you > find out. > > Michael > > [1] > https://docs.openstack.org/octavia/latest/configuration/configref.html#controller_worker.amp_image_tag > > > On Fri, Aug 6, 2021 at 5:52 AM Chris Lyons > wrote: > > > > Octavia group, > > > > > > > > I created this story to see if I could get some assistance on an > Octavia issue I am having with my infra.  I did a vanilla install of > Openstack Wallaby using the Kolla project with Octavia enabled and > auto-configure set. Everything appeared to install fine.  When I try > to create a load balancer using the horizon console or the cli or > through further installs such as cloudfoundry that require a > loadbalancer, I get an error from glance about “No image found with > tag amphora” even though the image does exist.  I hope it is something > simple or an oversight on my part. Could I get some ideas or places to > look? > > > > > > > > Story: > > > > > > > > https://storyboard.openstack.org/#!/story/2009103 > > > > > > > > > Kolla install followed: > > > > > > > > > https://docs.openstack.org/kolla-ansible/latest/reference/networking/octavia.html > > > > > > > > > cli output : > > > > > > > > [root at kolla ~]# openstack image list --tag amphora > > > > +--------------------------------------+---------------------+--------+ > > > > | ID                                   | Name                | Status | > > > > +--------------------------------------+---------------------+--------+ > > > > | 8f7398e7-7912-43b8-8131-e90f21c91ab4 | amphora             | active | > > > > | 9bf14389-8521-4fb7-a7db-925f4dea1bf3 | amphora-x64-haproxy | active | > > > > +--------------------------------------+---------------------+--------+ > > > > [root at kolla ~]# > > > > > > > > My Infra scripts (relevant): > > > > > > > > > https://github.com/mephmanx/openstack-scripts/blob/32363ef5753fdec381f713c747c90a5c14b3ae72/kolla.sh#L340 > > > > > > > > > > > > > I am admin of said infra so if anyone has time or availability (or > interest) to log in and take a look I would be happy to provide creds. > > > > > > > > Thank you for any time that you could provide or offer! > > > > This email has been scanned by Inbound Shield™. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zigo at debian.org Sat Aug 7 15:01:42 2021 From: zigo at debian.org (Thomas Goirand) Date: Sat, 7 Aug 2021 17:01:42 +0200 Subject: [ops] Openstack Victoria SPICE configuration not working In-Reply-To: References: <2e6f3235c70b84f47730cce25888541b@dimlight.org> <390fe0dd-3253-5c2c-abb4-e9c9d97a808e@debian.org> Message-ID: On 8/6/21 11:32 PM, number9 wrote: > I am not sure I follow you. I am on ubuntu... do I need to install some > debian > spice package to get this working? Probably you don't *need* it, but using Debian is another option... Thomas From number9 at dimlight.org Sat Aug 7 15:10:20 2021 From: number9 at dimlight.org (number9) Date: Sat, 07 Aug 2021 10:10:20 -0500 Subject: [ops] Openstack Victoria SPICE configuration not working In-Reply-To: References: <2e6f3235c70b84f47730cce25888541b@dimlight.org> <390fe0dd-3253-5c2c-abb4-e9c9d97a808e@debian.org> Message-ID: Are you suggesting that I rebuild my six servers with Debian in order to get spice working? I thought Ubuntu server was a supported platform (e.g. the docs say RHEL, SuSe, Ubuntu)? Would moving to Wallaby help? I am hesitant, as I have tried to get vnc and novnc working on Rocky and Pike with the same results. The problem is I really _need_ it to work for next semester so the students can access their vms over the web for some remote classes. Thanks. On 2021-08-07 10:01, Thomas Goirand wrote: > On 8/6/21 11:32 PM, number9 wrote: >> I am not sure I follow you. I am on ubuntu... do I need to install >> some >> debian >> spice package to get this working? > > Probably you don't *need* it, but using Debian is another option... > > Thomas From tobias.urdin at binero.com Sun Aug 8 08:34:26 2021 From: tobias.urdin at binero.com (Tobias Urdin) Date: Sun, 8 Aug 2021 08:34:26 +0000 Subject: how to update existing vm instances 'availability_zone' field in nova database 'instances' table In-Reply-To: References: Message-ID: <329DDA62-FDB6-436A-8D10-90D7649D0E9E@binero.com> Hello, The availability_zone field in the instances object is a read-only field that doesn’t have anything to do with the actual scheduling of instances. This has been covered numerous of times on the mailing list here. The request_specs table in the nova API database contains the specs for when an instance was launched and the JSON blob there (in the spec field) includes the field availability_zone which affects scheduling. Please not that it’s not supported or recommend to update that field and if you do it should be done using oslo_versionedobjects even though updating it directly in the database will make it appear to work but might not be without bugs. Best regards > On 6 Aug 2021, at 21:24, hai wu wrote: > > It seems this 'AvailabilityZoneFilter' is really buggy. The > 'instances' table 'availability_zone' field was already updated to > match the target desired zone name, but 'AvailabilityZoneFilter' kept > rejecting the request. I already restarted nova-api, nova-conductor, > nova-scheduler services after updating this database field value, but > that's not helpful. > > In the source code in file > '/usr/lib/python3/dist-packages/nova/scheduler/filters/availability_zone_filter.py', > how does 'spec_obj' got its availability_zone value? I don't > understand this particular code. This issue is really frustrating .. > def host_passes(self, host_state, spec_obj): > availability_zone = spec_obj.availability_zone > > On Wed, Aug 4, 2021 at 5:11 PM hai wu wrote: >> >> Hi, >> >> How to update existing vm instances 'availability_zone' field in nova >> database 'instances' table? It turns out there are many VMs with >> default 'nova' availability zone, while the hypervisors are with >> another different target aggregate/availability zone name, thus live >> migration for these VMs are failing. >> >> The strange thing is that the 'OS-EXT-AZ:availability_zone' output >> from 'openstack server show VM_NAME' is showing these VMs are already >> with the target availibity_zone name. No idea why we have this >> inconsistency. >> >> Would it be ok to just update database table entry directly to set >> 'availility_zone' to different value for these VMs? Or there might be >> better alternatives I am not aware of? >> >> Thanks, >> Hai > From tonykarera at gmail.com Sun Aug 8 10:37:41 2021 From: tonykarera at gmail.com (Karera Tony) Date: Sun, 8 Aug 2021 12:37:41 +0200 Subject: Masakari with Kolla-ansible In-Reply-To: References: Message-ID: Dear Radosław, I got it working and also checked the corosync status and it was OK. Unfortunately when I test by killing the qemu-kvm service on the compute node. Only one instance on the compute node gets restarted and the rest remain shutdown. Regards Tony Karera On Fri, Aug 6, 2021 at 2:21 PM Radosław Piliszek < radoslaw.piliszek at gmail.com> wrote: > On Fri, Aug 6, 2021 at 9:48 AM Karera Tony wrote: > > > > Hello Radoslaw, > > > > I enabled it but it seems the corosync cluster is not working. > > > > I don't know if there is any other trick to try. > > There are no tricks. > You might want to check the corosync status via: > crm_mon -1 > issued in the pacemaker container on the faulty controller host. > > > Regards > > > > Tony Karera > > > > > > > > > > On Thu, Aug 5, 2021 at 3:26 PM Radosław Piliszek < > radoslaw.piliszek at gmail.com> wrote: > >> > >> On Mon, Aug 2, 2021 at 6:19 PM Karera Tony > wrote: > >> > > >> > Hello Team, > >> > >> Hello Tony, > >> > >> > I have deployed Openstack with Kolla-ansible on Centos8 and also > enabled Masakari but I keep getting the error below in the > masakari-hostmonitor.log on the controller nodes. > >> > >> Have you enabled hacluster as well? > >> It is a required component for hostmonitor unless you are providing > >> your own hacluster (i.e., pacemaker+corosync cluster). > >> > >> Kind regards, > >> > >> -yoctozepto > -------------- next part -------------- An HTML attachment was scrubbed... URL: From radoslaw.piliszek at gmail.com Sun Aug 8 16:38:40 2021 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Sun, 8 Aug 2021 18:38:40 +0200 Subject: Masakari with Kolla-ansible In-Reply-To: References: Message-ID: On Sun, Aug 8, 2021 at 12:37 PM Karera Tony wrote: > > Dear Radosław, Dear Tony, > I got it working and also checked the corosync status and it was OK. I am very glad! > Unfortunately when I test by killing the qemu-kvm service on the compute node. There is one qemu-kvm per running instance - are you killing them all then? > Only one instance on the compute node gets restarted and the rest remain shutdown. You would have to include both the Masakari instance monitor and Masakari engine logs. Do note the host monitor (so the Pacemaker stack as well) does not play any role here. -yoctozepto From tonykarera at gmail.com Sun Aug 8 16:41:48 2021 From: tonykarera at gmail.com (Karera Tony) Date: Sun, 8 Aug 2021 18:41:48 +0200 Subject: Masakari with Kolla-ansible In-Reply-To: References: Message-ID: Dear Radosław, Thanks a lot. I will check it out accordingly. I really appreciate the help Regards Tony Karera On Sun, Aug 8, 2021 at 6:38 PM Radosław Piliszek < radoslaw.piliszek at gmail.com> wrote: > On Sun, Aug 8, 2021 at 12:37 PM Karera Tony wrote: > > > > Dear Radosław, > > Dear Tony, > > > I got it working and also checked the corosync status and it was OK. > > I am very glad! > > > Unfortunately when I test by killing the qemu-kvm service on the compute > node. > > There is one qemu-kvm per running instance - are you killing them all then? > > > Only one instance on the compute node gets restarted and the rest remain > shutdown. > > You would have to include both the Masakari instance monitor and > Masakari engine logs. > Do note the host monitor (so the Pacemaker stack as well) does not > play any role here. > > -yoctozepto > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrunge at matthias-runge.de Mon Aug 9 07:21:11 2021 From: mrunge at matthias-runge.de (Matthias Runge) Date: Mon, 9 Aug 2021 09:21:11 +0200 Subject: [ops] Openstack Victoria SPICE configuration not working In-Reply-To: References: <2e6f3235c70b84f47730cce25888541b@dimlight.org> <390fe0dd-3253-5c2c-abb4-e9c9d97a808e@debian.org> Message-ID: On Sat, Aug 07, 2021 at 10:10:20AM -0500, number9 wrote: > Are you suggesting that I rebuild my six servers with Debian in order > to get spice working? > > I thought Ubuntu server was a supported platform (e.g. the docs say > RHEL, SuSe, Ubuntu)? > > Would moving to Wallaby help? I am hesitant, as I have tried to get > vnc and novnc working on Rocky and Pike with the same results. > The problem is I really _need_ it to work for next semester so > the students can access their vms over the web for some remote classes. > > Thanks. > Hi, from the error description, I can only suspect you may be able to see the error message in Horizon logs. Usually a "Something went wrong" message is the nicer way for a 500 server error. If I understood correctly what Thomas was trying to suggest is: Ubuntu and Debian packages should work on both systems, i.e. you should be able to use the Debian packages on Ubuntu. Thomas puts a lot of effort in these. OpenStack is quite easy to misconfigure, and you can waste some time in finding your own typos (or the one in guides). This is why installers are popular. Matthias -- Matthias Runge From ralonsoh at redhat.com Mon Aug 9 08:06:46 2021 From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez) Date: Mon, 9 Aug 2021 10:06:46 +0200 Subject: [neutron][stable] Nominate Lajos Katona to the neutron-stable-maint team In-Reply-To: <20210805135015.p26hi4yqz5rx33qn@grind.home> References: <4154938.lVMuQLOT2H@p1> <20210805135015.p26hi4yqz5rx33qn@grind.home> Message-ID: Hello: +1 from me of course. Sorry for the late reply, I was on PTO. Regards. On Thu, Aug 5, 2021 at 3:50 PM Nate Johnston wrote: > I think Lajos would be a great addition! +1 > > Nate > > On Thu, Aug 05, 2021 at 11:50:46AM +0200, Slawek Kaplonski wrote: > > Hi, > > > > I would like to nominate Lajos Katona as a Neutron stable core reviewer. > Lajos > > is core in Neutron since long time. He is maintaining many stadium > projects as > > well as he is very active in the main Neutron project. He helps us a lot > with > > keeping stable branches healthy (especially for stadium projects, but > not > > only). > > During that time he has proven already his knowledge about Neutron and > Neutron > > stadium projects as well as knowledge of the stable branches rules. > > > > I will keep this nomination open for about 1 week. After that if there > will be > > no votes agains, I will ask stable-maint-core team to add Lajos to the > > neutron-stable-maint team. > > > > -- > > Slawek Kaplonski > > Principal Software Engineer > > Red Hat > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at stackhpc.com Mon Aug 9 08:16:11 2021 From: mark at stackhpc.com (Mark Goddard) Date: Mon, 9 Aug 2021 09:16:11 +0100 Subject: "[Kolla][Kolla-Ansible] Ironic Node Deployment" In-Reply-To: References: Message-ID: Hi Lokendra, We regularly use Ironic with Kolla. Unfortunately it can be quite challenging to get working, but it is possible. tcpdump and console logs are your friends. Regards, Mark On Thu, 5 Aug 2021 at 12:32, Lokendra Rathour wrote: > > Hi Team, > > I was trying to deploy Ironic Node on Kolla Ansible Setup. > Document used for reference: > https://docs.openstack.org/kolla-ansible/latest/reference/bare-metal/ironic-guide.html > > Although this document says > : " Ironic works well in Kolla, though it is not thoroughly tested as part of Kolla CI, so may be subject to instability" > > We have tried 2 node Kolla Ansible 12.0.0 in order to deploy OpenStack wallaby release with enabled ironic for Bare-metal nodes provisioning. But facing issues in "Node Provisioning" > > So, has anyone tried the Baremetal Provisioning on Koll Setup? > Please share /suggest any approach to achieve this. > > -- > ~ Lokendra > skype: lokendrarathour From lokendrarathour at gmail.com Mon Aug 9 08:51:45 2021 From: lokendrarathour at gmail.com (Lokendra Rathour) Date: Mon, 9 Aug 2021 14:21:45 +0530 Subject: "[Kolla][Kolla-Ansible] Ironic Node Deployment" In-Reply-To: References: Message-ID: Hi Mark, Thanks for the reply. As it looks that getting ironic installed in Kolla-Ansible is not that easy. As we know that Kayobe is also using Kolla-ansible underneath, so we may have a similar line of challenges when deploying ironic over Kayobe ? Best Regards, Lokendra On Mon, Aug 9, 2021 at 1:46 PM Mark Goddard wrote: > Hi Lokendra, > > We regularly use Ironic with Kolla. Unfortunately it can be quite > challenging to get working, but it is possible. tcpdump and console > logs are your friends. > > Regards, > Mark > > On Thu, 5 Aug 2021 at 12:32, Lokendra Rathour > wrote: > > > > Hi Team, > > > > I was trying to deploy Ironic Node on Kolla Ansible Setup. > > Document used for reference: > > > https://docs.openstack.org/kolla-ansible/latest/reference/bare-metal/ironic-guide.html > > > > Although this document says > > : " Ironic works well in Kolla, though it is not thoroughly tested as > part of Kolla CI, so may be subject to instability" > > > > We have tried 2 node Kolla Ansible 12.0.0 in order to deploy OpenStack > wallaby release with enabled ironic for Bare-metal nodes provisioning. But > facing issues in "Node Provisioning" > > > > So, has anyone tried the Baremetal Provisioning on Koll Setup? > > Please share /suggest any approach to achieve this. > > > > -- > > ~ Lokendra > > skype: lokendrarathour > -- ~ Lokendra www.inertiaspeaks.com www.inertiagroups.com skype: lokendrarathour -------------- next part -------------- An HTML attachment was scrubbed... URL: From katkumar at in.ibm.com Mon Aug 9 09:23:41 2021 From: katkumar at in.ibm.com (Katari Kumar) Date: Mon, 9 Aug 2021 09:23:41 +0000 Subject: Snapshot Attachment support in cinder Message-ID: An HTML attachment was scrubbed... URL: From radoslaw.piliszek at gmail.com Mon Aug 9 09:38:43 2021 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Mon, 9 Aug 2021 11:38:43 +0200 Subject: "[Kolla][Kolla-Ansible] Ironic Node Deployment" In-Reply-To: References: Message-ID: On Mon, Aug 9, 2021 at 10:53 AM Lokendra Rathour wrote: > Hi Mark, > Thanks for the reply. > As it looks that getting ironic installed in Kolla-Ansible is not that > easy. > As we know that Kayobe is also using Kolla-ansible underneath, so we may > have a similar line of challenges when deploying ironic over Kayobe ? > It will be the same experience, except for handling of the server provisioning layer and setting up networking for you. I suggest you try it as it gives you more out of the box and may help you spot the issue in your previous setup. Ironic works just fine with Kolla Ansible but requires more understanding of your baremetal layer than the other services. Also, do note Kayobe will use Ironic (via Bifrost) to provision your nodes so you will test Ironic from yet another angle. -yoctozepto > Best Regards, > Lokendra > > On Mon, Aug 9, 2021 at 1:46 PM Mark Goddard wrote: > >> Hi Lokendra, >> >> We regularly use Ironic with Kolla. Unfortunately it can be quite >> challenging to get working, but it is possible. tcpdump and console >> logs are your friends. >> >> Regards, >> Mark >> >> On Thu, 5 Aug 2021 at 12:32, Lokendra Rathour >> wrote: >> > >> > Hi Team, >> > >> > I was trying to deploy Ironic Node on Kolla Ansible Setup. >> > Document used for reference: >> > >> https://docs.openstack.org/kolla-ansible/latest/reference/bare-metal/ironic-guide.html >> > >> > Although this document says >> > : " Ironic works well in Kolla, though it is not thoroughly tested as >> part of Kolla CI, so may be subject to instability" >> > >> > We have tried 2 node Kolla Ansible 12.0.0 in order to deploy >> OpenStack wallaby release with enabled ironic for Bare-metal nodes >> provisioning. But facing issues in "Node Provisioning" >> > >> > So, has anyone tried the Baremetal Provisioning on Koll Setup? >> > Please share /suggest any approach to achieve this. >> > >> > -- >> > ~ Lokendra >> > skype: lokendrarathour >> > > > -- > ~ Lokendra > www.inertiaspeaks.com > www.inertiagroups.com > skype: lokendrarathour > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at stackhpc.com Mon Aug 9 09:44:14 2021 From: mark at stackhpc.com (Mark Goddard) Date: Mon, 9 Aug 2021 10:44:14 +0100 Subject: "[Kolla][Kolla-Ansible] Ironic Node Deployment" In-Reply-To: References: Message-ID: On Mon, 9 Aug 2021 at 09:52, Lokendra Rathour wrote: > Hi Mark, > Thanks for the reply. > As it looks that getting ironic installed in Kolla-Ansible is not that > easy. > As we know that Kayobe is also using Kolla-ansible underneath, so we may > have a similar line of challenges when deploying ironic over Kayobe ? > Kayobe uses Bifrost, which deploys Ironic in a standalone mode, without nova, neutron, etc. This simplifies things a bit, but of course many of the challenges of working with bare metal remain. Mark > Best Regards, > Lokendra > > On Mon, Aug 9, 2021 at 1:46 PM Mark Goddard wrote: > >> Hi Lokendra, >> >> We regularly use Ironic with Kolla. Unfortunately it can be quite >> challenging to get working, but it is possible. tcpdump and console >> logs are your friends. >> >> Regards, >> Mark >> >> On Thu, 5 Aug 2021 at 12:32, Lokendra Rathour >> wrote: >> > >> > Hi Team, >> > >> > I was trying to deploy Ironic Node on Kolla Ansible Setup. >> > Document used for reference: >> > >> https://docs.openstack.org/kolla-ansible/latest/reference/bare-metal/ironic-guide.html >> > >> > Although this document says >> > : " Ironic works well in Kolla, though it is not thoroughly tested as >> part of Kolla CI, so may be subject to instability" >> > >> > We have tried 2 node Kolla Ansible 12.0.0 in order to deploy >> OpenStack wallaby release with enabled ironic for Bare-metal nodes >> provisioning. But facing issues in "Node Provisioning" >> > >> > So, has anyone tried the Baremetal Provisioning on Koll Setup? >> > Please share /suggest any approach to achieve this. >> > >> > -- >> > ~ Lokendra >> > skype: lokendrarathour >> > > > -- > ~ Lokendra > www.inertiaspeaks.com > www.inertiagroups.com > skype: lokendrarathour > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lucasagomes at gmail.com Mon Aug 9 10:20:15 2021 From: lucasagomes at gmail.com (Lucas Alvares Gomes) Date: Mon, 9 Aug 2021 11:20:15 +0100 Subject: [neutron][stable] Nominate Lajos Katona to the neutron-stable-maint team In-Reply-To: <4154938.lVMuQLOT2H@p1> References: <4154938.lVMuQLOT2H@p1> Message-ID: Hi, On Thu, Aug 5, 2021 at 10:50 AM Slawek Kaplonski wrote: > > Hi, > > I would like to nominate Lajos Katona as a Neutron stable core reviewer. Lajos > is core in Neutron since long time. He is maintaining many stadium projects as > well as he is very active in the main Neutron project. He helps us a lot with > keeping stable branches healthy (especially for stadium projects, but not > only). > During that time he has proven already his knowledge about Neutron and Neutron > stadium projects as well as knowledge of the stable branches rules. > > I will keep this nomination open for about 1 week. After that if there will be > no votes agains, I will ask stable-maint-core team to add Lajos to the > neutron-stable-maint team. > +1 to add Lajos to the team. > -- > Slawek Kaplonski > Principal Software Engineer > Red Hat From number9 at dimlight.org Mon Aug 9 10:33:18 2021 From: number9 at dimlight.org (number9) Date: Mon, 09 Aug 2021 05:33:18 -0500 Subject: [ops] Openstack Victoria SPICE configuration not working In-Reply-To: References: <2e6f3235c70b84f47730cce25888541b@dimlight.org> <390fe0dd-3253-5c2c-abb4-e9c9d97a808e@debian.org> Message-ID: Thanks for the information, I have a few questions: What packages are you referring to? Did I install the wrong spice packages to make spice run? You note installers are popular, but I was under the impression the only installer was the "single machine" developer installer, and not one for a controller node, five compute nodes and a block storage node. Am I missing something? Is there an installer where I can just install Openstack "controller" on the controller, "compute" on the compute nodes and say "swift" or "cinder" on my storage node, and it will all be configured to work together? That would save me some real configuration time. I have already installed it three times by hand (Rocky, Pike, Victoria), and that is a fair amount of work. Thanks. On 2021-08-09 02:21, Matthias Runge wrote: > On Sat, Aug 07, 2021 at 10:10:20AM -0500, number9 wrote: >> Are you suggesting that I rebuild my six servers with Debian in order >> to get spice working? >> >> I thought Ubuntu server was a supported platform (e.g. the docs say >> RHEL, SuSe, Ubuntu)? >> >> Would moving to Wallaby help? I am hesitant, as I have tried to get >> vnc and novnc working on Rocky and Pike with the same results. >> The problem is I really _need_ it to work for next semester so >> the students can access their vms over the web for some remote >> classes. >> >> Thanks. >> > > Hi, > > from the error description, I can only suspect you may be able to see > the error message in Horizon logs. Usually a "Something went wrong" > message is the nicer way for a 500 server error. > > If I understood correctly what Thomas was trying to suggest is: Ubuntu > and Debian packages should work on both systems, i.e. you should be > able to use the Debian packages on Ubuntu. Thomas puts a lot of effort > in these. > > OpenStack is quite easy to misconfigure, and you can waste some time in > finding your own typos (or the one in guides). This is why installers > are popular. > > Matthias From stephenfin at redhat.com Mon Aug 9 10:59:11 2021 From: stephenfin at redhat.com (Stephen Finucane) Date: Mon, 09 Aug 2021 11:59:11 +0100 Subject: [ops] Openstack Victoria SPICE configuration not working In-Reply-To: <2e6f3235c70b84f47730cce25888541b@dimlight.org> References: <2e6f3235c70b84f47730cce25888541b@dimlight.org> Message-ID: <5e202efe22375125c82f5aaf6463214b7598dc44.camel@redhat.com> On Thu, 2021-08-05 at 12:25 -0500, number9 wrote: > I have posted this on stackexchange, but am also asking here: > > Running openstack on Ubuntu 20.04 with a controller node and four > compute nodes. I am reading the instructions on configuring SPICE here. > I will admit, I found out about which packages to install from other > sites, as the instructions at the link do not actually list any software > that needs to be installed. > > On the compute nodes and controller, I installed nova-spiceproxy > On the controller I installed nova-spiceproxy and spice-html5 Not an answer, but as an aside SPICE support is poorly maintained in nova and its usage not generally advised. It may be removed in a future release. I would suggest relying on noVNC instead. With that said... > > I followed the instructions in the link on configuring > /etc/nova/nova.conf on the controller and all compute nodes. > > In a nutshell, when you click on console in the dashboard, it simply > says: > > Something went wrong! > > An unexpected error has occurred. Try refreshing the page. If that > doesn't help, contact your local administrator. > > I have parsed every log in /var/log on the compute and controller nodes > and found nothing that would indicate it is failing. > > On the compute node, I can do a ps aux and see that spice is running on > the instance I am trying to connect to. > > > I am really not sure where to go. I have tried VNC and noVNC also to no > avail, each time completely removing the old > configs and only adding the new. I have reverted back to SPICE to try > the "simple" approach. > > My relevant config items in /etc/nova/nova.conf from a compute node are: > > [DEFAULT] > vnc_eanabled = false There's a typo here, but it shouldn't matter - that config option has been replaced by the '[vnc] enabled' option below. The doc clearly needs an update. As another aside, because virtually everyone seems to use an installer, the actual install guides get very TLC and are subsequently prone to bitrot :( However, the remote console doc at [1] was updated in recent releases and should be relatively accurate. [1] https://docs.openstack.org/nova/latest/admin/remote-console-access.html > # yes, I know it is redundant, I am following the docs... > > [vnc] > enabled = false > > [spice] > enabled = true > agent_enabled = true > html5proxy_base_url = http://10.131.39.40:6082/spice_auto.html > # the above IP is the IP of the controller. > server_listen = 0.0.0.0 > server_proxyclient_address = 10.131.29.42 So I assume '10.131.39.40' is address of the controller and '10.131.29.42' is the address of the compute node, yes? Is the former publicly accessible from the same place you're browsing the web UX? I would assume not, given it's a private network IP. If not, this needs to be updated. This is the value returned from the API which is in turn used by Horizon iirc. > # the above IP is the IP of the controller that I pulled this config > from > html5proxy_host = 0.0.0.0 > html5proxy_port = 6082 These are redundant (they match the defaults) but also no harm so... > > Back on the controller node, in /etc/nova/nova.conf I have: > > [spice] > enabled = true > agent_enabled = false > html5proxy_host = 0.0.0.0 > html5proxy_port = 6082 > keymap = en_us This all looks correct to me. Somewhat unrelated: I'm not certain whether this is true for SPICE, but you should not configure the keymap option for VNC. It's the source of bugs since the QEMU-based keymaps this enables are incomplete and buggy. Better to use a newer version of noVNC that supports native keymapping. > > I also have vnc false, as it is on the compute nodes. I will admit > further, I have tried at least 20 iterations of this, just leaving off > proxy ports, or thinking for a moment that the proxyclientaddress was > the controller node, but none of them work. I do restart nova on the > controller and all compute nodes after every change. > > Any ideas or directions would be appreciated. I wish there were logs, I > am perhaps missing them or need to turn on debugging of some kind. I suspect the issue is with the address used for '[spice] html5proxy_base_url'. I would suggest using the 'openstack console url show' command to get a URL to access the console without needing to invoke Horizon. If you're able to access this URL then the issue is instead somewhere in Horizon. If not, it's definitely nova. You can also enable debug-level logging for the nova-spicehtml5proxy and nova-novncproxy services to ensure you're actually seeing a connection from your browser. Hopefully this helps somewhat, Stephen From mnasiadka at gmail.com Mon Aug 9 11:24:47 2021 From: mnasiadka at gmail.com (=?UTF-8?Q?Micha=C5=82_Nasiadka?=) Date: Mon, 9 Aug 2021 13:24:47 +0200 Subject: [kolla] Transitioning stable/queens to eol Message-ID: Hello, We've kept stable/queens branches of kolla and kolla-ansible around under extended maintenance for a while now. The coordinated Queens release was 28th Feb, 2018 (Kolla on 26th Mar, 2018). The last time a change was backported to these branches has been a while: - kolla stable/queens: Jun 8, 2020 - kolla-ansible stable/queens: Nov 3, 2019 There is no CI running for those projects periodically, last CI jobs have been run: - kolla - 24th Aug, 2020 - kolla-ansible - 17th Jun, 2020 All changes to those branches have been abandoned long time (and nothing new proposed for at least a year): https://review.opendev.org/q/branch:stable/queens+project:openstack/kolla https://review.opendev.org/q/branch:stable/queens+project:openstack/kolla-ansible So, I'd like to request that these branches be moved to end-of-life. Patch proposed to add EOL tags to both kolla and kolla-ansible: https://review.opendev.org/c/openstack/releases/+/803701 -- Michał Nasiadka mnasiadka at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierre at stackhpc.com Mon Aug 9 12:16:03 2021 From: pierre at stackhpc.com (Pierre Riteau) Date: Mon, 9 Aug 2021 14:16:03 +0200 Subject: [kolla] Transitioning stable/queens to eol In-Reply-To: References: Message-ID: +1 Kolla Ansible on stable/queens is using the legacy Docker packages, which have been retired by the Docker project. It is very hard to find a reliable mirror for these packages. On Mon, 9 Aug 2021 at 13:26, Michał Nasiadka wrote: > Hello, > > We've kept stable/queens branches of kolla and kolla-ansible around under > extended maintenance for a while now. > The coordinated Queens release was 28th Feb, 2018 (Kolla on 26th Mar, > 2018). > > The last time a change was backported to these branches has been a while: > - kolla > stable/queens: Jun 8, 2020 > - kolla-ansible > stable/queens: Nov 3, 2019 > > There is no CI running for those projects periodically, last CI jobs have > been run: > - kolla - 24th Aug, 2020 > - kolla-ansible - 17th Jun, 2020 > > All changes to those branches have been abandoned long time (and nothing > new proposed for at least a year): > https://review.opendev.org/q/branch:stable/queens+project:openstack/kolla > > https://review.opendev.org/q/branch:stable/queens+project:openstack/kolla-ansible > > So, I'd like to request that these branches be moved to end-of-life. > > Patch proposed to add EOL tags to both kolla and kolla-ansible: > https://review.opendev.org/c/openstack/releases/+/803701 > > -- > Michał Nasiadka > mnasiadka at gmail.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rosmaita.fossdev at gmail.com Mon Aug 9 12:29:16 2021 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Mon, 9 Aug 2021 08:29:16 -0400 Subject: [interop][cinder] review of next.json (part 2) In-Reply-To: References: <07c47d7a-0ca1-aad4-4cd8-369049bd6b63@gmail.com> <954a3f22-8d7c-c40b-09cf-d21628cb0227@gmail.com> <8ccc4dfa-4b20-2277-c60b-23d9970d72f3@gmail.com> Message-ID: On 8/6/21 9:52 AM, Arkady Kanevsky wrote: > Brian, > can we schedule it for Tu 16:30-16:45 UTC? or some time 16:00-17:00 on Tu? > Thanks, > Arkady Could we schedule the session for 16:00 UTC on Tuesday 19 Oct? cheers, brian > > On Fri, Jul 30, 2021 at 11:17 AM Arkady Kanevsky > wrote: > > Thanks Brian. > Will discuss at next Interop team meeting and will assign a person > to meet and present with cinder team at that time. > > On Thu, Jul 29, 2021 at 8:07 AM Brian Rosmaita > > wrote: > > On 7/28/21 6:08 PM, Arkady Kanevsky wrote: > > Brian, > > lets postpone it till PTG. > > I am booked solid Wed morning. > > Thanks, > > Arkady > > That works for us.  The Cinder team will be meeting 13:00-16:00 > UTC from > Tuesday through Friday the week of the PTG.  I'd like to > schedule you > right at 13:00 UTC on one of those days.  You can decide among > yourselves what works for you and please put a note on our planning > etherpad: > > https://etherpad.opendev.org/p/yoga-ptg-cinder-planning > > > thanks! > brian > > > > > > On Wed, Jul 28, 2021 at 4:32 PM Brian Rosmaita > > > >> wrote: > > > >     On 5/13/21 10:38 AM, Kanevsky, Arkady wrote: > >      > Thanks Brian. > >      > I will discuss with the team and we will have somebody > from the > >     Interop team attending it. > > > >     Hello Interop WG, > > > >     Just want to remind you that we're holding the cinder > xena R-9 virtual > >     midcycle next week on Wednesday 4 August 2021, and that > we've got > >     you on > >     the agenda for a 20 minute discussion at 1400 UTC.  You > can read > >     through > >     an earlier discussion at the weekly cinder meeting to get > an idea of > >     what questions we have: > > > > > http://eavesdrop.openstack.org/meetings/cinder/2021/cinder.2021-05-12-14.00.log.html#l-56 > > > >  > > > > >     Connection info is: https://bluejeans.com/3228528973 > > >      > > > > >     If something has changed and no one's available, let me > know.  We can > >     postpone the discussion to the Yoga virtual PTG. > > > >     thanks! > >     brian > > > >      > Thanks, > >      > > >      > -----Original Message----- > >      > From: Brian Rosmaita > >      >> > >      > Sent: Thursday, May 13, 2021 9:25 AM > >      > To: openstack-discuss at lists.openstack.org > > >      > > >      > Subject: [interop][cinder] review of next.json (part 2) > >      > > >      > > >      > [EXTERNAL EMAIL] > >      > > >      > Hello Interop WG, > >      > > >      > The Cinder team completed its discussion of what > capabilities > >     should be added as advisory in next.json at yesterday's > weekly > >     cinder meeting [0]. > >      > > >      > The tldr; is that we don't have anything to propose > for inclusion > >     in next.json at the present time. > >      > > >      > The team does have some general questions that would > help us > >     determine the suitability of some proposed capabilities. > We'd like > >     to invite someone from the Interop WG to the cinder xena > R-9 virtual > >     midcycle (Wednesday 4 August 2021, 1400-1600 UTC) so we > can discuss > >     this "live". > >      > So if someone could put 1400 UTC 4 August on their > schedule for a > >     20 minute discussion, that would be very helpful. > >      > > >      > cheers, > >      > brian > >      > > >      > > >      > [0] > >      > > > > http://eavesdrop.openstack.org/meetings/cinder/2021/cinder.2021-05-12-14.00.log.html#l-56 > > > >  > > >      > > > > > > > > > > > -- > > Arkady Kanevsky, Ph.D. > > Phone: 972 707-6456 > > Corporate Phone: 919 729-5744 ext. 8176456 > > > > -- > Arkady Kanevsky, Ph.D. > Phone: 972 707-6456 > Corporate Phone: 919 729-5744 ext. 8176456 > > > > -- > Arkady Kanevsky, Ph.D. > Phone: 972 707-6456 > Corporate Phone: 919 729-5744 ext. 8176456 From bkslash at poczta.onet.pl Mon Aug 9 12:31:17 2021 From: bkslash at poczta.onet.pl (bkslash) Date: Mon, 9 Aug 2021 14:31:17 +0200 Subject: [neutron-vpnaas][kolla-ansible][victoria] Growing memory consumption with only one VPN connection In-Reply-To: <3490402.o3x6GOIaP6@p1> References: <44F0A10E-99B2-430B-9F32-2E3A4CE95B58@poczta.onet.pl> <3490402.o3x6GOIaP6@p1> Message-ID: <11E1A6A6-4A1B-455F-B589-4E63C16868EB@poczta.onet.pl> Hi Sławek, I’ll do that soon, still testing some options nad observing results. Best regards Adam Tomas > > Please open Launchpad bug for that https://bugs.launchpad.net/neutron/+filebug > - it will be easier to track it there. > Please include what versions are You using exactly and how to reproduce the > issue. > > -- > Slawek Kaplonski > Principal Software Engineer > Red Hat From felipe.ebert at gmail.com Mon Aug 9 12:36:14 2021 From: felipe.ebert at gmail.com (Felipe Ebert) Date: Mon, 9 Aug 2021 14:36:14 +0200 Subject: Support for Automating Source Code Documentation Message-ID: Hi, I am currently working on designing a bot to support open-source software development: the idea is that the bot can analyze code review comments, detect those related to explaining the reasons behind the implementation choices and suggest these reasons as source code comments. As the first step of this design process we would like to ask developers involved in code reviews to answer a survey (we expect it to take not more than 25 minutes): https://forms.office.com/r/9nD4HtNbTK Thanks in advance, -- Felipe Ebert Eindhoven University of Technology, The Netherlands -------------- next part -------------- An HTML attachment was scrubbed... URL: From haiwu.us at gmail.com Mon Aug 9 13:50:40 2021 From: haiwu.us at gmail.com (hai wu) Date: Mon, 9 Aug 2021 08:50:40 -0500 Subject: how to update existing vm instances 'availability_zone' field in nova database 'instances' table In-Reply-To: <329DDA62-FDB6-436A-8D10-90D7649D0E9E@binero.com> References: <329DDA62-FDB6-436A-8D10-90D7649D0E9E@binero.com> Message-ID: Thanks Tobias! I was wondering about this 'request_specs' table before, and 'availability_zone' in its blob for those VMs were NULL value IIRC, and I don't know how to update it before. I am not sure how to use oslo_versionedobjects to update it. So basically there would be no way for us to use new 'availability_zone' aggregate name later for hypervisor hosts? I finally worked around this issue by removing hosts from new availability zone name, which by default put those hosts back to `nova` zone, and that ensured the live migration process working again. This is not ideal, but is now working. Thanks, Hai On Sun, Aug 8, 2021 at 3:44 AM Tobias Urdin wrote: > > Hello, > > The availability_zone field in the instances object is a read-only field that doesn’t have anything to do with > the actual scheduling of instances. This has been covered numerous of times on the mailing list here. > > The request_specs table in the nova API database contains the specs for when an instance was launched and > the JSON blob there (in the spec field) includes the field availability_zone which affects scheduling. > > Please not that it’s not supported or recommend to update that field and if you do it should be done using oslo_versionedobjects > even though updating it directly in the database will make it appear to work but might not be without bugs. > > Best regards > > > On 6 Aug 2021, at 21:24, hai wu wrote: > > > > It seems this 'AvailabilityZoneFilter' is really buggy. The > > 'instances' table 'availability_zone' field was already updated to > > match the target desired zone name, but 'AvailabilityZoneFilter' kept > > rejecting the request. I already restarted nova-api, nova-conductor, > > nova-scheduler services after updating this database field value, but > > that's not helpful. > > > > In the source code in file > > '/usr/lib/python3/dist-packages/nova/scheduler/filters/availability_zone_filter.py', > > how does 'spec_obj' got its availability_zone value? I don't > > understand this particular code. This issue is really frustrating .. > > def host_passes(self, host_state, spec_obj): > > availability_zone = spec_obj.availability_zone > > > > On Wed, Aug 4, 2021 at 5:11 PM hai wu wrote: > >> > >> Hi, > >> > >> How to update existing vm instances 'availability_zone' field in nova > >> database 'instances' table? It turns out there are many VMs with > >> default 'nova' availability zone, while the hypervisors are with > >> another different target aggregate/availability zone name, thus live > >> migration for these VMs are failing. > >> > >> The strange thing is that the 'OS-EXT-AZ:availability_zone' output > >> from 'openstack server show VM_NAME' is showing these VMs are already > >> with the target availibity_zone name. No idea why we have this > >> inconsistency. > >> > >> Would it be ok to just update database table entry directly to set > >> 'availility_zone' to different value for these VMs? Or there might be > >> better alternatives I am not aware of? > >> > >> Thanks, > >> Hai > > > From akanevsk at redhat.com Mon Aug 9 14:00:10 2021 From: akanevsk at redhat.com (Arkady Kanevsky) Date: Mon, 9 Aug 2021 09:00:10 -0500 Subject: [interop][cinder] review of next.json (part 2) In-Reply-To: References: <07c47d7a-0ca1-aad4-4cd8-369049bd6b63@gmail.com> <954a3f22-8d7c-c40b-09cf-d21628cb0227@gmail.com> <8ccc4dfa-4b20-2277-c60b-23d9970d72f3@gmail.com> Message-ID: Yes. 16:00 UTC will work. On Mon, Aug 9, 2021 at 7:29 AM Brian Rosmaita wrote: > On 8/6/21 9:52 AM, Arkady Kanevsky wrote: > > Brian, > > can we schedule it for Tu 16:30-16:45 UTC? or some time 16:00-17:00 on > Tu? > > Thanks, > > Arkady > > Could we schedule the session for 16:00 UTC on Tuesday 19 Oct? > > cheers, > brian > > > > > On Fri, Jul 30, 2021 at 11:17 AM Arkady Kanevsky > > wrote: > > > > Thanks Brian. > > Will discuss at next Interop team meeting and will assign a person > > to meet and present with cinder team at that time. > > > > On Thu, Jul 29, 2021 at 8:07 AM Brian Rosmaita > > > > wrote: > > > > On 7/28/21 6:08 PM, Arkady Kanevsky wrote: > > > Brian, > > > lets postpone it till PTG. > > > I am booked solid Wed morning. > > > Thanks, > > > Arkady > > > > That works for us. The Cinder team will be meeting 13:00-16:00 > > UTC from > > Tuesday through Friday the week of the PTG. I'd like to > > schedule you > > right at 13:00 UTC on one of those days. You can decide among > > yourselves what works for you and please put a note on our > planning > > etherpad: > > > > https://etherpad.opendev.org/p/yoga-ptg-cinder-planning > > > > > > thanks! > > brian > > > > > > > > > > On Wed, Jul 28, 2021 at 4:32 PM Brian Rosmaita > > > > > > > >> wrote: > > > > > > On 5/13/21 10:38 AM, Kanevsky, Arkady wrote: > > > > Thanks Brian. > > > > I will discuss with the team and we will have somebody > > from the > > > Interop team attending it. > > > > > > Hello Interop WG, > > > > > > Just want to remind you that we're holding the cinder > > xena R-9 virtual > > > midcycle next week on Wednesday 4 August 2021, and that > > we've got > > > you on > > > the agenda for a 20 minute discussion at 1400 UTC. You > > can read > > > through > > > an earlier discussion at the weekly cinder meeting to get > > an idea of > > > what questions we have: > > > > > > > > > http://eavesdrop.openstack.org/meetings/cinder/2021/cinder.2021-05-12-14.00.log.html#l-56 > > < > http://eavesdrop.openstack.org/meetings/cinder/2021/cinder.2021-05-12-14.00.log.html#l-56 > > > > > > > < > http://eavesdrop.openstack.org/meetings/cinder/2021/cinder.2021-05-12-14.00.log.html#l-56 > < > http://eavesdrop.openstack.org/meetings/cinder/2021/cinder.2021-05-12-14.00.log.html#l-56 > >> > > > > > > Connection info is: https://bluejeans.com/3228528973 > > > > > > > > > > > > > If something has changed and no one's available, let me > > know. We can > > > postpone the discussion to the Yoga virtual PTG. > > > > > > thanks! > > > brian > > > > > > > Thanks, > > > > > > > > -----Original Message----- > > > > From: Brian Rosmaita > > > > > >> > > > > Sent: Thursday, May 13, 2021 9:25 AM > > > > To: openstack-discuss at lists.openstack.org > > > > > > > > > > > Subject: [interop][cinder] review of next.json (part 2) > > > > > > > > > > > > [EXTERNAL EMAIL] > > > > > > > > Hello Interop WG, > > > > > > > > The Cinder team completed its discussion of what > > capabilities > > > should be added as advisory in next.json at yesterday's > > weekly > > > cinder meeting [0]. > > > > > > > > The tldr; is that we don't have anything to propose > > for inclusion > > > in next.json at the present time. > > > > > > > > The team does have some general questions that would > > help us > > > determine the suitability of some proposed capabilities. > > We'd like > > > to invite someone from the Interop WG to the cinder xena > > R-9 virtual > > > midcycle (Wednesday 4 August 2021, 1400-1600 UTC) so we > > can discuss > > > this "live". > > > > So if someone could put 1400 UTC 4 August on their > > schedule for a > > > 20 minute discussion, that would be very helpful. > > > > > > > > cheers, > > > > brian > > > > > > > > > > > > [0] > > > > > > > > > > http://eavesdrop.openstack.org/meetings/cinder/2021/cinder.2021-05-12-14.00.log.html#l-56 > > < > http://eavesdrop.openstack.org/meetings/cinder/2021/cinder.2021-05-12-14.00.log.html#l-56 > > > > > > > < > http://eavesdrop.openstack.org/meetings/cinder/2021/cinder.2021-05-12-14.00.log.html#l-56 > < > http://eavesdrop.openstack.org/meetings/cinder/2021/cinder.2021-05-12-14.00.log.html#l-56 > >> > > > > > > > > > > > > > > > > > > > -- > > > Arkady Kanevsky, Ph.D. > > > Phone: 972 707-6456 > > > Corporate Phone: 919 729-5744 ext. 8176456 > > > > > > > > -- > > Arkady Kanevsky, Ph.D. > > Phone: 972 707-6456 > > Corporate Phone: 919 729-5744 ext. 8176456 > > > > > > > > -- > > Arkady Kanevsky, Ph.D. > > Phone: 972 707-6456 > > Corporate Phone: 919 729-5744 ext. 8176456 > > -- Arkady Kanevsky, Ph.D. Phone: 972 707-6456 Corporate Phone: 919 729-5744 ext. 8176456 -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleg.bondarev at huawei.com Mon Aug 9 14:08:02 2021 From: oleg.bondarev at huawei.com (Oleg Bondarev) Date: Mon, 9 Aug 2021 14:08:02 +0000 Subject: [neutron] Bug Deputy Report Aug 2 - 8th Message-ID: <4851588ebe394a67bd16d7d36a9dbe14@huawei.com> Hi everyone, Please find Bug Deputy report for the week Aug 2 - 8th below. One Critical Bug waits for an assignee, also one Medium bug is unassigned. Otherwise all good. Critical - https://bugs.launchpad.net/neutron/+bug/1938766 - Functional tests related to ovn failing with No such file or directory: '/tmp/tmps9cyr99c/ovn_northd.log' Ed · Confirmed · Unassigned High - https://bugs.launchpad.net/neutron/+bug/1938685 - ofctl timeouts lead to dvr-ha-multinode-full failures · Fix released: https://review.opendev.org/c/openstack/neutron/+/803211 · Assigned to obondarev - https://bugs.launchpad.net/neutron/+bug/1938788 - Validate if fixed_ip given for port isn't the same as subnet's gateway_ip · Won't Fix: https://review.opendev.org/c/openstack/neutron/+/803334 - abandoned after discussion - https://bugs.launchpad.net/neutron/+bug/1939144 - [OVN] Router Availability Zones doesn't work with segmented networks Edit · In Progress: https://review.opendev.org/c/openstack/neutron/+/803759 · Assigned to Lucas Alvares Gomes (lucasagomes) Medium - https://bugs.launchpad.net/neutron/+bug/1938910 - Duplicate default SG error when new system scopes are used · In progress: https://review.opendev.org/c/openstack/neutron/+/803489 · Assigned to slaweq - https://bugs.launchpad.net/neutron/+bug/1938972 - Trunk and port are residual in VM deleting scenario when southbound plugin/agent failed · Triaged · Unassigned - https://bugs.launchpad.net/neutron/+bug/1939125 - Incorect Auto schedule new network segments notification listner · Triaged · Assigned to Szymon Wróblewski (bluex) Low - https://bugs.launchpad.net/neutron/+bug/1939137 - ovn + log service plugin reports AttributeError: 'NoneType' object has no attribute 'tenant_id' · Triaged · Assigned to Kamil Sambor RFEs - https://bugs.launchpad.net/neutron/+bug/1938966 - [RFE] pps limitation on neutron ports for openvswitch agent · New: to be discussed on Drivers meeting · Unassigned Invalid - https://bugs.launchpad.net/neutron/+bug/1938826 - Install and configure controller node in Neutron · bug in deployment - https://bugs.launchpad.net/neutron/+bug/1938913 - Install and configure compute node in Neutron · not a Neutron issue Thanks, Oleg --- Advanced Software Technology Lab Huawei -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrunge at matthias-runge.de Mon Aug 9 15:15:05 2021 From: mrunge at matthias-runge.de (Matthias Runge) Date: Mon, 9 Aug 2021 17:15:05 +0200 Subject: [ops] Openstack Victoria SPICE configuration not working In-Reply-To: References: <2e6f3235c70b84f47730cce25888541b@dimlight.org> <390fe0dd-3253-5c2c-abb4-e9c9d97a808e@debian.org> Message-ID: On Mon, Aug 09, 2021 at 05:33:18AM -0500, number9 wrote: > Thanks for the information, I have a few questions: > > > What packages are you referring to? Did I install the wrong spice packages > to make spice run? > > > You note installers are popular, but I was under the impression the only > installer was > the "single machine" developer installer, and not one for a controller node, > five > compute nodes and a block storage node. Am I missing something? Is there an > installer > where I can just install Openstack "controller" on the controller, "compute" > on the > compute nodes and say "swift" or "cinder" on my storage node, and it will > all be > configured to work together? That would save me some real configuration > time. I have already > installed it three times by hand (Rocky, Pike, Victoria), and that is a fair > amount of work. I was referring to .deb packages. I don't know what you did install (and what not). Also I am not using Debian (or Ubuntu). Installers would deploy OpenStack on your bare metal machines, and would make "things work" together. I'd just name kolla or tripleo here, but there are more, see[1]. Single node deployments are just a special case, but are not really supportable (nor would they create a highly available infrastructure). Matthias [1] https://www.openstack.org/software/project-navigator/deployment-tools > > Thanks. > > On 2021-08-09 02:21, Matthias Runge wrote: > > On Sat, Aug 07, 2021 at 10:10:20AM -0500, number9 wrote: > > > Are you suggesting that I rebuild my six servers with Debian in order > > > to get spice working? > > > > > > I thought Ubuntu server was a supported platform (e.g. the docs say > > > RHEL, SuSe, Ubuntu)? > > > > > > Would moving to Wallaby help? I am hesitant, as I have tried to get > > > vnc and novnc working on Rocky and Pike with the same results. > > > The problem is I really _need_ it to work for next semester so > > > the students can access their vms over the web for some remote > > > classes. > > > > > > Thanks. > > > > > > > Hi, > > > > from the error description, I can only suspect you may be able to see > > the error message in Horizon logs. Usually a "Something went wrong" > > message is the nicer way for a 500 server error. > > > > If I understood correctly what Thomas was trying to suggest is: Ubuntu > > and Debian packages should work on both systems, i.e. you should be > > able to use the Debian packages on Ubuntu. Thomas puts a lot of effort > > in these. > > > > OpenStack is quite easy to misconfigure, and you can waste some time in > > finding your own typos (or the one in guides). This is why installers > > are popular. > > > > Matthias > -- Matthias Runge From chris at lyonsgroup.family Mon Aug 9 00:56:12 2021 From: chris at lyonsgroup.family (Chris Lyons) Date: Mon, 9 Aug 2021 00:56:12 +0000 Subject: Octavia In-Reply-To: <26e5229a-0584-c5f5-e85f-6547b158dc47@gmail.com> References: , <26e5229a-0584-c5f5-e85f-6547b158dc47@gmail.com> Message-ID: I think I might have solved it. It looks like during the kolla install a “Octavia-openrc.sh” script is created which sets up the env to use an account called “service”. After running that and re-uploading the amphora image I am now able to see amphora instances get created. Thank you Bernd for the suggestion that you gve! It caused me to look around in the permissions area and found the solution! From: Bernd Bausch Date: Friday, August 6, 2021 at 8:21 PM To: openstack-discuss at lists.openstack.org , Chris Lyons Subject: Re: Octavia I had that problem when setting up a Victoria Kolla cluster, and it turned out that the image was owned by the wrong project, as suspected by Michael. I changed the owner in Glance, and it worked. The owner must be 4269b3cd5452416e8153f5b4f5adcf0c in Chris' case (openstack image set --project 4269b3cd5452416e8153f5b4f5adcf0c amphora-image-name). I don't think this is a Kolla problem, as Kolla leaves the responsibility of building and uploading the image to the administrator (or it did so at Victoria). Bernd Bausch On 2021/08/06 11:07 PM, Chris Lyons wrote: Both of those appear ok…. I do have the amphora image set to public and I see this in the Octavia.conf file: [controller_worker] amp_ssh_key_name = octavia_ssh_key amp_image_tag = amphora amp_image_owner_id = 4269b3cd5452416e8153f5b4f5adcf0c amp_boot_network_list = adfa01a9-55bd-42ea-b849-81060d5d7c09 amp_secgroup_list = ecf269e2-42fc-477b-9ce1-38d60c1d8d5d amp_flavor_id = c854d1e7-885f-4f7a-88a3-79728b561830 client_ca = /etc/octavia/certs/client_ca.cert.pem network_driver = allowed_address_pairs_driver compute_driver = compute_nova_driver amphora_driver = amphora_haproxy_rest_driver amp_active_retries = 100 amp_active_wait_sec = 2 loadbalancer_topology = SINGLE From: Michael Johnson Date: Friday, August 6, 2021 at 10:04 AM To: Chris Lyons Cc: openstack-discuss at lists.openstack.org Subject: Re: Octavia This is a kolla bug most likely. This could be caused by a few possible issues in kolla: 1. The images are owned by the wrong project. Kolla may deploy Octavia under a special service project. The image kolla uploads to glance must be uploaded under the service project as owner. A simple test to see if this is the issue would be to set the image as "public" such that all users of the cloud can see it. If a load balancer can be created after that change, the images are loaded under a project that Octavia cannot access. 2. The other possibility is kolla configured an alternate tag name. Check the [controller_worker] amp_image_tag setting [1] in octavia.conf. The images must be tagged with the same name as is configured in the octavia.conf for the controllers. Let us know either way (and ideally open a bug for kolla) what you find out. Michael [1] https://docs.openstack.org/octavia/latest/configuration/configref.html#controller_worker.amp_image_tag On Fri, Aug 6, 2021 at 5:52 AM Chris Lyons wrote: > > Octavia group, > > > > I created this story to see if I could get some assistance on an Octavia issue I am having with my infra. I did a vanilla install of Openstack Wallaby using the Kolla project with Octavia enabled and auto-configure set. Everything appeared to install fine. When I try to create a load balancer using the horizon console or the cli or through further installs such as cloudfoundry that require a loadbalancer, I get an error from glance about “No image found with tag amphora” even though the image does exist. I hope it is something simple or an oversight on my part. Could I get some ideas or places to look? > > > > Story: > > > > https://storyboard.openstack.org/#!/story/2009103 > > > > Kolla install followed: > > > > https://docs.openstack.org/kolla-ansible/latest/reference/networking/octavia.html > > > > cli output : > > > > [root at kolla ~]# openstack image list --tag amphora > > +--------------------------------------+---------------------+--------+ > > | ID | Name | Status | > > +--------------------------------------+---------------------+--------+ > > | 8f7398e7-7912-43b8-8131-e90f21c91ab4 | amphora | active | > > | 9bf14389-8521-4fb7-a7db-925f4dea1bf3 | amphora-x64-haproxy | active | > > +--------------------------------------+---------------------+--------+ > > [root at kolla ~]# > > > > My Infra scripts (relevant): > > > > https://github.com/mephmanx/openstack-scripts/blob/32363ef5753fdec381f713c747c90a5c14b3ae72/kolla.sh#L340 > > > > > > I am admin of said infra so if anyone has time or availability (or interest) to log in and take a look I would be happy to provide creds. > > > > Thank you for any time that you could provide or offer! This email has been scanned by Inbound Shield™. This email has been scanned by Inbound Shield™. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at lyonsgroup.family Mon Aug 9 01:57:49 2021 From: chris at lyonsgroup.family (Chris Lyons) Date: Mon, 9 Aug 2021 01:57:49 +0000 Subject: Octavia In-Reply-To: References: , <26e5229a-0584-c5f5-e85f-6547b158dc47@gmail.com>, Message-ID: Well…it gets. A lot further…. I see this error now…. Im looking around to see if it’s a security group missing or if there is some other setting I missed. Im not seeing any scripts to prep the env…usually there is something like that if it’s a security group…anyone know? |__Atom 'STANDALONE-octavia-create-amp-for-lb-subflow-octavia-create-amphora-indb' {'intention': 'EXECUTE', 'state': 'SUCCESS', 'requires': {'loadbalancer_id': '5b4598ee-d055-40c4-997d-ea41009d819e'}, 'provides': 'b6a7018d-d436-477b-8aad-b1b53b1e6cde'} |__Flow 'STANDALONE-octavia-create-amp-for-lb-subflow' |__Atom 'STANDALONE-octavia-get-amphora-for-lb-subflow-octavia-mapload-balancer-to-amphora' {'intention': 'EXECUTE', 'state': 'SUCCESS', 'requires': {'loadbalancer_id': '5b4598ee-d055-40c4-997d-ea41009d819e', 'flavor': {}, 'availability_zone': {}, 'server_group_id': None}, 'provides': None} |__Flow 'STANDALONE-octavia-get-amphora-for-lb-subflow' |__Atom 'octavia.controller.worker.v1.tasks.network_tasks.GetSubnetFromVIP' {'intention': 'EXECUTE', 'state': 'SUCCESS', 'requires': {'loadbalancer': }, 'provides': } |__Atom 'octavia.controller.worker.v1.tasks.network_tasks.UpdateVIPSecurityGroup' {'intention': 'EXECUTE', 'state': 'SUCCESS', 'requires': {'loadbalancer_id': '5b4598ee-d055-40c4-997d-ea41009d819e'}, 'provides': '3512c022-9189-4709-be49-46555d7ce8c6'} |__Atom 'octavia.controller.worker.v1.tasks.database_tasks.UpdateVIPAfterAllocation' {'intention': 'EXECUTE', 'state': 'SUCCESS', 'requires': {'loadbalancer_id': '5b4598ee-d055-40c4-997d-ea41009d819e', 'vip': }, 'provides': } |__Atom 'octavia.controller.worker.v1.tasks.network_tasks.AllocateVIP' {'intention': 'EXECUTE', 'state': 'SUCCESS', 'requires': {'loadbalancer': }, 'provides': } |__Atom 'reload-lb-before-allocate-vip' {'intention': 'EXECUTE', 'state': 'SUCCESS', 'requires': {'loadbalancer_id': '5b4598ee-d055-40c4-997d-ea41009d819e'}, 'provides': } |__Atom 'octavia.controller.worker.v1.tasks.lifecycle_tasks.LoadBalancerIDToErrorOnRevertTask' {'intention': 'EXECUTE', 'state': 'SUCCESS', 'requires': {'loadbalancer_id': '5b4598ee-d055-40c4-997d-ea41009d819e'}, 'provides': None} |__Flow 'octavia-create-loadbalancer-flow': octavia.amphorae.driver_exceptions.exceptions.TimeOutException: contacting the amphora timed out 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker Traceback (most recent call last): 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker File "/usr/lib/python3.6/site-packages/taskflow/engines/action_engine/executor.py", line 53, in _execute_task 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker result = task.execute(**arguments) 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker File "/usr/lib/python3.6/site-packages/octavia/controller/worker/v1/tasks/amphora_driver_tasks.py", line 424, in execute 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker amp_info = self.amphora_driver.get_info(amphora) 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker File "/usr/lib/python3.6/site-packages/octavia/amphorae/drivers/haproxy/rest_api_driver.py", line 373, in get_info 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker amphora, raise_retry_exception=raise_retry_exception) 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker File "/usr/lib/python3.6/site-packages/octavia/amphorae/drivers/haproxy/rest_api_driver.py", line 106, in _populate_amphora_api_version 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker raise_retry_exception=raise_retry_exception)['api_version'] 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker File "/usr/lib/python3.6/site-packages/octavia/amphorae/drivers/haproxy/rest_api_driver.py", line 744, in get_api_version 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker raise_retry_exception=raise_retry_exception) 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker File "/usr/lib/python3.6/site-packages/octavia/amphorae/drivers/haproxy/rest_api_driver.py", line 738, in request 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker raise driver_except.TimeOutException() 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker octavia.amphorae.driver_exceptions.exceptions.TimeOutException: contacting the amphora timed out 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker 2021-08-08 21:22:35.995 27 WARNING octavia.controller.worker.v1.controller_worker [-] Task 'STANDALONE-octavia-create-amp-for-lb-subflow-octavia-amp-compute-connectivity-wait' (7f8c1119-9020-4fb8-ae98-1495875a3dc2) transitioned into state 'REVERTED' from state 'REVERTING' 2021-08-08 21:22:36.003 27 WARNING octavia.controller.worker.v1.controller_worker [-] Task 'STANDALONE-octavia-create-amp-for-lb-subflow-octavia-update-amphora-info' (ca7b4681-3fe6-4834-b7ee-2fb2dbe01c3c) transitioned into state 'REVERTED' from state 'REVERTING' 2021-08-08 21:22:36.011 27 WARNING octavia.controller.worker.v1.controller_worker [-] Task 'STANDALONE-octavia-create-amp-for-lb-subflow-octavia-compute-wait' (2ef36bd4-15be-468f-9a8c-f6b60728da6c) transitioned into state 'REVERTED' from state 'REVERTING' 2021-08-08 21:22:36.017 27 WARNING octavia.controller.worker.v1.tasks.database_tasks [-] Reverting mark amphora booting in DB for amp id b6a7018d-d436-477b-8aad-b1b53b1e6cde and compute id c93393df-a39a-486e-812d-73652209fcff 2021-08-08 21:22:36.049 27 WARNING octavia.controller.worker.v1.controller_worker [-] Task 'STANDALONE-octavia-create-amp-for-lb-subflow-octavia-mark-amphora-booting-indb' (6aac42e0-fe77-43b8-9323-e0f79304d9d6) transitioned into state 'REVERTED' from state 'REVERTING' 2021-08-08 21:22:36.056 27 WARNING octavia.controller.worker.v1.controller_worker [-] Task 'STANDALONE-octavia-create-amp-for-lb-subflow-octavia-update-amphora-computeid' (592da2b6-ab90-4292-a854-c6e2a679dabf) transitioned into state 'REVERTED' from state 'REVERTING' 2021-08-08 21:22:36.061 27 WARNING octavia.controller.worker.v1.tasks.compute_tasks [-] Reverting compute create for amphora with id b6a7018d-d436-477b-8aad-b1b53b1e6cde and compute id: c93393df-a39a-486e-812d-73652209fcff 2021-08-08 21:22:36.576 27 WARNING octavia.controller.worker.v1.controller_worker [-] Task 'STANDALONE-octavia-create-amp-for-lb-subflow-octavia-cert-compute-create' (59401bf8-9191-4ac1-b4f3-b551a139df9d) transitioned into state 'REVERTED' from state 'REVERTING' 2021-08-08 21:22:36.582 27 WARNING octavia.controller.worker.v1.controller_worker [-] Task 'STANDALONE-octavia-create-amp-for-lb-subflow-octavia-update-cert-expiration' (9e731d93-8cb8-46cb-9be4-073e1579a5f8) transitioned into state 'REVERTED' from state 'REVERTING' From: Chris Lyons Date: Sunday, August 8, 2021 at 8:56 PM To: Bernd Bausch , openstack-discuss at lists.openstack.org Subject: Re: Octavia I think I might have solved it. It looks like during the kolla install a “Octavia-openrc.sh” script is created which sets up the env to use an account called “service”. After running that and re-uploading the amphora image I am now able to see amphora instances get created. Thank you Bernd for the suggestion that you gve! It caused me to look around in the permissions area and found the solution! From: Bernd Bausch Date: Friday, August 6, 2021 at 8:21 PM To: openstack-discuss at lists.openstack.org , Chris Lyons Subject: Re: Octavia I had that problem when setting up a Victoria Kolla cluster, and it turned out that the image was owned by the wrong project, as suspected by Michael. I changed the owner in Glance, and it worked. The owner must be 4269b3cd5452416e8153f5b4f5adcf0c in Chris' case (openstack image set --project 4269b3cd5452416e8153f5b4f5adcf0c amphora-image-name). I don't think this is a Kolla problem, as Kolla leaves the responsibility of building and uploading the image to the administrator (or it did so at Victoria). Bernd Bausch On 2021/08/06 11:07 PM, Chris Lyons wrote: Both of those appear ok…. I do have the amphora image set to public and I see this in the Octavia.conf file: [controller_worker] amp_ssh_key_name = octavia_ssh_key amp_image_tag = amphora amp_image_owner_id = 4269b3cd5452416e8153f5b4f5adcf0c amp_boot_network_list = adfa01a9-55bd-42ea-b849-81060d5d7c09 amp_secgroup_list = ecf269e2-42fc-477b-9ce1-38d60c1d8d5d amp_flavor_id = c854d1e7-885f-4f7a-88a3-79728b561830 client_ca = /etc/octavia/certs/client_ca.cert.pem network_driver = allowed_address_pairs_driver compute_driver = compute_nova_driver amphora_driver = amphora_haproxy_rest_driver amp_active_retries = 100 amp_active_wait_sec = 2 loadbalancer_topology = SINGLE From: Michael Johnson Date: Friday, August 6, 2021 at 10:04 AM To: Chris Lyons Cc: openstack-discuss at lists.openstack.org Subject: Re: Octavia This is a kolla bug most likely. This could be caused by a few possible issues in kolla: 1. The images are owned by the wrong project. Kolla may deploy Octavia under a special service project. The image kolla uploads to glance must be uploaded under the service project as owner. A simple test to see if this is the issue would be to set the image as "public" such that all users of the cloud can see it. If a load balancer can be created after that change, the images are loaded under a project that Octavia cannot access. 2. The other possibility is kolla configured an alternate tag name. Check the [controller_worker] amp_image_tag setting [1] in octavia.conf. The images must be tagged with the same name as is configured in the octavia.conf for the controllers. Let us know either way (and ideally open a bug for kolla) what you find out. Michael [1] https://docs.openstack.org/octavia/latest/configuration/configref.html#controller_worker.amp_image_tag On Fri, Aug 6, 2021 at 5:52 AM Chris Lyons wrote: > > Octavia group, > > > > I created this story to see if I could get some assistance on an Octavia issue I am having with my infra. I did a vanilla install of Openstack Wallaby using the Kolla project with Octavia enabled and auto-configure set. Everything appeared to install fine. When I try to create a load balancer using the horizon console or the cli or through further installs such as cloudfoundry that require a loadbalancer, I get an error from glance about “No image found with tag amphora” even though the image does exist. I hope it is something simple or an oversight on my part. Could I get some ideas or places to look? > > > > Story: > > > > https://storyboard.openstack.org/#!/story/2009103 > > > > Kolla install followed: > > > > https://docs.openstack.org/kolla-ansible/latest/reference/networking/octavia.html > > > > cli output : > > > > [root at kolla ~]# openstack image list --tag amphora > > +--------------------------------------+---------------------+--------+ > > | ID | Name | Status | > > +--------------------------------------+---------------------+--------+ > > | 8f7398e7-7912-43b8-8131-e90f21c91ab4 | amphora | active | > > | 9bf14389-8521-4fb7-a7db-925f4dea1bf3 | amphora-x64-haproxy | active | > > +--------------------------------------+---------------------+--------+ > > [root at kolla ~]# > > > > My Infra scripts (relevant): > > > > https://github.com/mephmanx/openstack-scripts/blob/32363ef5753fdec381f713c747c90a5c14b3ae72/kolla.sh#L340 > > > > > > I am admin of said infra so if anyone has time or availability (or interest) to log in and take a look I would be happy to provide creds. > > > > Thank you for any time that you could provide or offer! This email has been scanned by Inbound Shield™. This email has been scanned by Inbound Shield™. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at stackhpc.com Mon Aug 9 08:13:27 2021 From: mark at stackhpc.com (Mark Goddard) Date: Mon, 9 Aug 2021 09:13:27 +0100 Subject: [Kolla][Kolla-Ansible] Ironic Node Cleaning Failed In-Reply-To: References: Message-ID: On Fri, 6 Aug 2021 at 13:49, Anirudh Gupta wrote: > Hi Dmitry, > > I tried taking TCPDUMP while the Baremetal Node was booting up and looked > for tftp protocols and found there was some "*File Not Found" *traces for > bootx64.efi > > [image: image.png] > > Then, I found a related post on openstack Discuss which suggested to > enable IPXE > > http://lists.openstack.org/pipermail/openstack-discuss/2019-October/010329.html > > After re-deploying the setup with IPXE enabled, i found similar traces now > for *ipxe.efi file* > > [image: image.png] > > Can you please now suggest what possibly could be a miss in configuration > and steps to resolve it. > Hi Anirudh, I'd suggest installing a tftp client on your machine and making some requests. The TFTP daemon runs in the ironic_pxe container, and TFTP files are served from /tftpboot in that container. Mark > > For your reference, I am attaching the complete tcpdump logs of both the > Scenarios > > Looking forward to hearing from you. > > Regards > Anirudh Gupta > > > > > > On Thu, Aug 5, 2021 at 4:56 PM Anirudh Gupta wrote: > >> Hi Team, >> >> On further debugging, I found an error in neutron-server logs >> >> >> Failed to bind port 476d8175-ffc2-49ba-bb12-0a77c1f07e5f on host >> f4a43fa5-9c41-488e-a34d-714ae5a9d300 for vnic_type baremetal using segments >> [{'id': '1a5bbe96-2488-4971-925f-7c9346ba3ef5', 'network_type': 'flat', >> 'physical_network': 'physnet1', 'segmentation_id': None, 'network_id': >> '5b6cccec-ad86-4ed9-8d3c-72a31ec3a0d4'}] >> 2021-08-05 16:33:06.979 23 INFO neutron.plugins.ml2.plugin >> [req-54d11d51-7319-43ea-b70c-fe39d8aafe8a 21d6a238438e4294912746bcdc895e31 >> 3eca725754e1405eb178cc39bd0da3aa - default default] Attempt 9 to bind port >> 476d8175-ffc2-49ba-bb12-0a77c1f07e5f >> >> where 476d8175-ffc2-49ba-bb12-0a77c1f07e5f is the uuid of Baremetal Node >> >> However the port is created in openstack, but its state is down >> >> [ansible at localhost ~]$ openstack port list >> >> +--------------------------------------+------+-------------------+---------------------------------------------------------------------------+--------+ >> | ID | Name | MAC Address | Fixed >> IP Addresses | >> Status | >> >> +--------------------------------------+------+-------------------+---------------------------------------------------------------------------+--------+ >> | 07d6b83d-d83c-498f-8ba8-b4f21bef7249 | | fa:16:3e:38:05:9d | >> ip_address='10.0.1.200', subnet_id='7b72c158-2146-4bd6-893b-bd76b4a3e869' | >> ACTIVE | >> | 476d8175-ffc2-49ba-bb12-0a77c1f07e5f | | *98:f2:b3:3f:72:d8* | >> ip_address='10.0.1.202', subnet_id='7b72c158-2146-4bd6-893b-bd76b4a3e869' | *DOWN >> * | >> >> +--------------------------------------+------+-------------------+---------------------------------------------------------------------------+--------+ >> >> *98:f2:b3:3f:72:d8 *is the mac address of my Baremetal Node on which PXE >> is enabled. >> >> Can someone please help in resolving this issue. >> >> *Issue:* >> *Node goes in clean_failed from clean_wait.* >> >> Regards >> Anirudh Gupta >> >> On Tue, Aug 3, 2021 at 8:32 PM Anirudh Gupta wrote: >> >>> Hi Dmitry, >>> >>> I might be wrong, but as per my understanding if there would be an issue >>> in dnsmasq, then IP 20.20.20.10 would not have been assigned to the machine. >>> >>> TCPDUMP logs are as below: >>> >>> 20:16:58.938089 IP controller.bootps > 255.255.255.255.bootpc: >>> BOOTP/DHCP, Reply, length 312 >>> 20:17:02.765291 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, >>> Request from 98:f2:b3:3f:72:e5 (oui Unknown), length 359 >>> 20:17:02.766303 IP controller.bootps > 255.255.255.255.bootpc: >>> BOOTP/DHCP, Reply, length 312 >>> 20:17:26.944378 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, >>> Request from 98:f2:b3:3f:72:e5 (oui Unknown), length 347 >>> 20:17:26.944756 IP controller.bootps > 255.255.255.255.bootpc: >>> BOOTP/DHCP, Reply, length 312 >>> 20:17:30.763627 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, >>> Request from 98:f2:b3:3f:72:e5 (oui Unknown), length 359 >>> 20:17:30.764620 IP controller.bootps > 255.255.255.255.bootpc: >>> BOOTP/DHCP, Reply, length 312 >>> 20:17:54.938791 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, >>> Request from 98:f2:b3:3f:72:e5 (oui Unknown), length 347 >>> >>> Also the neutron dnsmasq logs and ironic inspector logs are attached in >>> the mail. >>> >>> Regards >>> Anirudh Gupta >>> >>> >>> On Tue, Aug 3, 2021 at 7:29 PM Dmitry Tantsur >>> wrote: >>> >>>> Hi, >>>> >>>> You need to check the dnsmasq logs (there are two dnsmasqs: from >>>> neutron and from ironic-inspector). tcpdump may also help to determine >>>> where the packages are lost. >>>> >>>> Dmitry >>>> >>>> On Fri, Jul 30, 2021 at 10:29 PM Anirudh Gupta >>>> wrote: >>>> >>>>> Hi Dmitry >>>>> >>>>> Thanks for your time. >>>>> >>>>> My system is getting IP 20.20.20.10 which is in the range defined in >>>>> ironic_dnsmasq_dhcp_range field under globals.yml file. >>>>> >>>>> ironic_dnsmasq_dhcp_range: "20.20.20.10,20.20.20.100" >>>>> >>>>> And in the cleaning network (public1), the range defined is >>>>> 20.20.20.150-20.20.20.200 >>>>> >>>>> As per my understanding, these 2 ranges should be mutually exclusive. >>>>> >>>>> Please suggest if my understanding is not correct. >>>>> >>>>> Any suggestions what should I do to resolve this issue? >>>>> >>>>> Regards >>>>> Anirudh Gupta >>>>> >>>>> >>>>> On Sat, 31 Jul, 2021, 12:06 am Dmitry Tantsur, >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Thu, Jul 29, 2021 at 6:05 PM Anirudh Gupta >>>>>> wrote: >>>>>> >>>>>>> Hi Team, >>>>>>> >>>>>>> In to the email below, I have some updated information:- >>>>>>> >>>>>>> Earlier the allocation range mentioned in " >>>>>>> *ironic_dnsmasq_dhcp_range*" in globals.yml had an overlapping >>>>>>> range with the cleaning network, due to which there was some issue in >>>>>>> receiving the DHCP request >>>>>>> >>>>>>> After creating a cleaning network with a separate allocation range, >>>>>>> I am successfully getting IP allocated to my Baremetal Node >>>>>>> >>>>>>> - openstack subnet create subnet1 --network public1 >>>>>>> --subnet-range 20.20.20.0/24 --allocation-pool >>>>>>> start=20.20.20.150,end=20.20.20.200 --ip-version=4 --gateway=20.20.20.1 >>>>>>> --dhcp >>>>>>> >>>>>>> >>>>>>> [image: image.png] >>>>>>> >>>>>>> After getting the IP, there is no further action on the node. From " >>>>>>> *clean_wait*", it goes into "*clean_failed*" state after around >>>>>>> half an hour. >>>>>>> >>>>>> >>>>>> The IP address is not from the cleaning range, it may come from >>>>>> inspection. You probably need to investigate your network topology, maybe >>>>>> use tcpdump. >>>>>> >>>>>> Unfortunately, I'm not fluent in Kolla to say if it can be a bug or >>>>>> not. >>>>>> >>>>>> Dmitry >>>>>> >>>>>> >>>>>>> >>>>>>> On verifying the logs, I could see the below error messages >>>>>>> >>>>>>> >>>>>>> - In */var/log/kolla/ironic/ironic-conductor.log*, we observed >>>>>>> the following error: >>>>>>> >>>>>>> ERROR ironic.conductor.utils [-] Cleaning for node >>>>>>> 3a56748e-a8ca-4dec-a332-ace18e6d494e failed. *Timeout reached while >>>>>>> cleaning the node. Please check if the ramdisk responsible for the cleaning >>>>>>> is running on the node. Failed on step {}.* >>>>>>> >>>>>>> >>>>>>> Note : For Cleaning the node, we have used the below images >>>>>>> >>>>>>> >>>>>>> >>>>>>> https://tarballs.openstack.org/ironic-python-agent/dib/files/ipa-centos8-master.kernel >>>>>>> >>>>>>> >>>>>>> https://tarballs.openstack.org/ironic-python-agent/dib/files/ipa-centos8-master.initramfs >>>>>>> >>>>>>> >>>>>>> - In /var/log/kolla/nova/nova-compute-ironic.log, we observed >>>>>>> the error >>>>>>> >>>>>>> ERROR nova.compute.manager [req-810ffedf-3343-471c-94db-85411984e6cc >>>>>>> - - - - -] No compute node record for host controller-ironic: >>>>>>> nova.exception_Remote.ComputeHostNotFound_Remote: Compute host >>>>>>> controller-ironic could not be found. >>>>>>> >>>>>>> >>>>>>> Can someone please help in this regard? >>>>>>> >>>>>>> Regards >>>>>>> Anirudh Gupta >>>>>>> >>>>>>> >>>>>>> On Tue, Jul 27, 2021 at 12:52 PM Anirudh Gupta >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Team, >>>>>>>> >>>>>>>> We have deployed 2 node kolla ansible *12.0.0* in order to deploy >>>>>>>> openstack *wallaby* release. We have also enabled ironic in order >>>>>>>> to provision the bare metal nodes. >>>>>>>> >>>>>>>> On each server we have 3 nics >>>>>>>> >>>>>>>> - *eno1* - OAM for external connectivity and endpoint's >>>>>>>> publicURL >>>>>>>> - *eno2* - Mgmt for internal communication between various >>>>>>>> openstack services. >>>>>>>> - *ens2f0* - Data Interface >>>>>>>> >>>>>>>> >>>>>>>> Corresponding to this we have defined the following fields in >>>>>>>> globals.yml >>>>>>>> >>>>>>>> >>>>>>>> - kolla_base_distro: "centos" >>>>>>>> - kolla_install_type: "source" >>>>>>>> - openstack_release: "wallaby" >>>>>>>> - network_interface: "eno2" # >>>>>>>> MGMT interface >>>>>>>> - kolla_external_vip_interface: "eno1" # OAM >>>>>>>> Interface >>>>>>>> - kolla_internal_vip_address: "192.168.10.3" # MGMT Subnet >>>>>>>> free ip >>>>>>>> - kolla_external_vip_address: "10.0.1.136" # OAM subnet >>>>>>>> free IP >>>>>>>> - neutron_external_interface: "ens2f0" # Data >>>>>>>> Interface >>>>>>>> - enable_neutron_provider_networks: "yes" >>>>>>>> >>>>>>>> Note: Only relevant fields are being shown in this query >>>>>>>> >>>>>>>> Also, for ironic following fields have been defined in globals.yml >>>>>>>> >>>>>>>> - enable_ironic: "yes" >>>>>>>> - enable_ironic_neutron_agent: "{{ enable_neutron | bool and >>>>>>>> enable_ironic | bool }}" >>>>>>>> - enable_horizon_ironic: "{{ enable_ironic | bool }}" >>>>>>>> - ironic_dnsmasq_interface: "*ens2f0*" # >>>>>>>> Data interface >>>>>>>> - ironic_dnsmasq_dhcp_range: "20.20.20.10,20.20.20.100" >>>>>>>> - ironic_dnsmasq_boot_file: "pxelinux.0" >>>>>>>> - ironic_cleaning_network: "public1" >>>>>>>> - ironic_dnsmasq_default_gateway: "20.20.20.1" >>>>>>>> >>>>>>>> >>>>>>>> After successful deployment, a flat provider network with the name >>>>>>>> public1 is being created in openstack using the below commands: >>>>>>>> >>>>>>>> >>>>>>>> - openstack network create public1 --provider-network-type flat >>>>>>>> --provider-physical-network physnet1 >>>>>>>> - openstack subnet create subnet1 --network public1 >>>>>>>> --subnet-range 20.20.20.0/24 --allocation-pool >>>>>>>> start=20.20.20.10,end=20.20.20.100 --ip-version=4 --gateway=20.20.20.1 >>>>>>>> --dhcp >>>>>>>> >>>>>>>> >>>>>>>> Issue/Queries: >>>>>>>> >>>>>>>> >>>>>>>> - Is the configuration done in globals.yml correct or is there >>>>>>>> anything else that needs to be done in order to separate control and data >>>>>>>> plane traffic? >>>>>>>> >>>>>>>> >>>>>>>> - Also I have set automated_cleaning as "true" in >>>>>>>> ironic-conductor conatiner settings.But after creating the baremetal node, >>>>>>>> we run "node manage" command which runs successfully. Running "*openstack >>>>>>>> baremetal node provide "* command powers on the >>>>>>>> machine, sets the boot mode on Network Boot but no DHCP request for that >>>>>>>> particular mac is obtained on the controller. Is there anything I am >>>>>>>> missing that needs to be done in order to make ironic work? >>>>>>>> >>>>>>>> Note: I have also verified that the nic is PXE enabled in system >>>>>>>> configuration setting >>>>>>>> >>>>>>>> Regards >>>>>>>> Anirudh Gupta >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> -- >>>>>> Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, >>>>>> Commercial register: Amtsgericht Muenchen, HRB 153243, >>>>>> Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, >>>>>> Michael O'Neill >>>>>> >>>>> >>>> >>>> -- >>>> Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, >>>> Commercial register: Amtsgericht Muenchen, HRB 153243, >>>> Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael >>>> O'Neill >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 38285 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 185546 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 200447 bytes Desc: not available URL: From anyrude10 at gmail.com Mon Aug 9 08:31:24 2021 From: anyrude10 at gmail.com (Anirudh Gupta) Date: Mon, 9 Aug 2021 14:01:24 +0530 Subject: [Kolla][Kolla-Ansible] Ironic Node Cleaning Failed In-Reply-To: References: Message-ID: Hi Mark, Earlier I was passing the boot_mode as uefi while creating the baremetal node. On Kolla-Ansible Launchpad, I found some issues related to UEFI mode, so I didn't pass the parameter. With IPXE and without passing UEFI boot mode parameter, my node started cleaning. It connected with the TFTP server. But from the last 2 hours, the state is still in *clean_wait* only. The ramdisk and kernel images I used were the ones mentioned in the link below - https://tarballs.openstack.org/ironic-python-agent/dib/files/ipa-centos8-master.kernel - https://tarballs.openstack.org/ironic-python-agent/dib/files/ipa-centos8-master.initramfs For this I followed the latest kolla ansible document:- - https://docs.openstack.org/kolla-ansible/latest/reference/bare-metal/ironic-guide.html All I can see in *ironic-conductor* logs is: 2021-08-09 13:49:51.159 7 DEBUG ironic.drivers.modules.agent_base [-] Heartbeat from node 8b1ec553-fbc9-4912-bd33-88afc41b8f81 heartbeat /var/lib/kolla/venv/lib/python3.6/site-packages/ironic/drivers/modules/agent_base.py:641 2021-08-09 13:49:51.178 7 DEBUG ironic.drivers.modules.agent_client [-] Fetching status of agent commands for node 8b1ec553-fbc9-4912-bd33-88afc41b8f81 get_commands_status /var/lib/kolla/venv/lib/python3.6/site-packages/ironic/drivers/modules/agent_client.py:310 2021-08-09 13:49:51.186 7 DEBUG ironic.drivers.modules.agent_client [-] Status of agent commands for node 8b1ec553-fbc9-4912-bd33-88afc41b8f81: get_clean_steps: result "{'clean_steps': {'GenericHardwareManager': [{'step': 'erase_devices', 'priority': 10, 'interface': 'deploy', 'reboot_requested': False, 'abortable': True}, {'step': 'erase_devices_metadata', 'priority': 99, 'interface': 'deploy', 'reboot_requested': False, 'abortable': True}, {'step': 'erase_pstore', 'priority': 0, 'interface': 'deploy', 'reboot_requested': False, 'abortable': True}, {'step': 'delete_configuration', 'priority': 0, 'interface': 'raid', 'reboot_requested': False, 'abortable': True}, {'step': 'create_configuration', 'priority': 0, 'interface': 'raid', 'reboot_requested': False, 'abortable': True}, {'step': 'burnin_cpu', 'priority': 0, 'interface': 'deploy', 'reboot_requested': False, 'abortable': True}, {'step': 'burnin_disk', 'priority': 0, 'interface': 'deploy', 'reboot_requested': False, 'abortable': True}, {'step': 'burnin_memory', 'priority': 0, 'interface': 'deploy', 'reboot_requested': False, 'abortable': True}, {'step': 'burnin_network', 'priority': 0, 'interface': 'deploy', 'reboot_requested': False, 'abortable': True}]}, 'hardware_manager_version': {'MellanoxDeviceHardwareManager': '1', 'generic_hardware_manager': '1.1'}}", error "None"; execute_clean_step: result "{'clean_result': None, 'clean_step': {'step': 'erase_devices_metadata', 'priority': 99, 'interface': 'deploy', 'reboot_requested': False, 'abortable': True, 'requires_ramdisk': True}}", error "None"; execute_clean_step: result "None", error "None" get_commands_status /var/lib/kolla/venv/lib/python3.6/site-packages/ironic/drivers/modules/agent_client.py:342 2021-08-09 13:49:51.186 7 DEBUG ironic.drivers.modules.agent_base [-] *Clean step still running for node 8b1ec553-fbc9-4912-bd33-88afc41b8f81:* None _get_completed_command /var/lib/kolla/venv/lib/python3.6/site-packages/ironic/drivers/modules/agent_base.py:267 It would be a great help if you could suggest some pointers. Regards Anirudh Gupta I tried On Mon, Aug 9, 2021 at 1:43 PM Mark Goddard wrote: > > > On Fri, 6 Aug 2021 at 13:49, Anirudh Gupta wrote: > >> Hi Dmitry, >> >> I tried taking TCPDUMP while the Baremetal Node was booting up and looked >> for tftp protocols and found there was some "*File Not Found" *traces >> for bootx64.efi >> >> [image: image.png] >> >> Then, I found a related post on openstack Discuss which suggested to >> enable IPXE >> >> http://lists.openstack.org/pipermail/openstack-discuss/2019-October/010329.html >> >> After re-deploying the setup with IPXE enabled, i found similar traces >> now for *ipxe.efi file* >> >> [image: image.png] >> >> Can you please now suggest what possibly could be a miss in configuration >> and steps to resolve it. >> > > Hi Anirudh, > > I'd suggest installing a tftp client on your machine and making some > requests. The TFTP daemon runs in the ironic_pxe container, and TFTP files > are served from /tftpboot in that container. > > Mark > >> >> For your reference, I am attaching the complete tcpdump logs of both the >> Scenarios >> >> Looking forward to hearing from you. >> >> Regards >> Anirudh Gupta >> >> >> >> >> >> On Thu, Aug 5, 2021 at 4:56 PM Anirudh Gupta wrote: >> >>> Hi Team, >>> >>> On further debugging, I found an error in neutron-server logs >>> >>> >>> Failed to bind port 476d8175-ffc2-49ba-bb12-0a77c1f07e5f on host >>> f4a43fa5-9c41-488e-a34d-714ae5a9d300 for vnic_type baremetal using segments >>> [{'id': '1a5bbe96-2488-4971-925f-7c9346ba3ef5', 'network_type': 'flat', >>> 'physical_network': 'physnet1', 'segmentation_id': None, 'network_id': >>> '5b6cccec-ad86-4ed9-8d3c-72a31ec3a0d4'}] >>> 2021-08-05 16:33:06.979 23 INFO neutron.plugins.ml2.plugin >>> [req-54d11d51-7319-43ea-b70c-fe39d8aafe8a 21d6a238438e4294912746bcdc895e31 >>> 3eca725754e1405eb178cc39bd0da3aa - default default] Attempt 9 to bind port >>> 476d8175-ffc2-49ba-bb12-0a77c1f07e5f >>> >>> where 476d8175-ffc2-49ba-bb12-0a77c1f07e5f is the uuid of Baremetal Node >>> >>> However the port is created in openstack, but its state is down >>> >>> [ansible at localhost ~]$ openstack port list >>> >>> +--------------------------------------+------+-------------------+---------------------------------------------------------------------------+--------+ >>> | ID | Name | MAC Address | >>> Fixed IP Addresses | >>> Status | >>> >>> +--------------------------------------+------+-------------------+---------------------------------------------------------------------------+--------+ >>> | 07d6b83d-d83c-498f-8ba8-b4f21bef7249 | | fa:16:3e:38:05:9d | >>> ip_address='10.0.1.200', subnet_id='7b72c158-2146-4bd6-893b-bd76b4a3e869' | >>> ACTIVE | >>> | 476d8175-ffc2-49ba-bb12-0a77c1f07e5f | | *98:f2:b3:3f:72:d8* | >>> ip_address='10.0.1.202', subnet_id='7b72c158-2146-4bd6-893b-bd76b4a3e869' | *DOWN >>> * | >>> >>> +--------------------------------------+------+-------------------+---------------------------------------------------------------------------+--------+ >>> >>> *98:f2:b3:3f:72:d8 *is the mac address of my Baremetal Node on which >>> PXE is enabled. >>> >>> Can someone please help in resolving this issue. >>> >>> *Issue:* >>> *Node goes in clean_failed from clean_wait.* >>> >>> Regards >>> Anirudh Gupta >>> >>> On Tue, Aug 3, 2021 at 8:32 PM Anirudh Gupta >>> wrote: >>> >>>> Hi Dmitry, >>>> >>>> I might be wrong, but as per my understanding if there would be an >>>> issue in dnsmasq, then IP 20.20.20.10 would not have been assigned to the >>>> machine. >>>> >>>> TCPDUMP logs are as below: >>>> >>>> 20:16:58.938089 IP controller.bootps > 255.255.255.255.bootpc: >>>> BOOTP/DHCP, Reply, length 312 >>>> 20:17:02.765291 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, >>>> Request from 98:f2:b3:3f:72:e5 (oui Unknown), length 359 >>>> 20:17:02.766303 IP controller.bootps > 255.255.255.255.bootpc: >>>> BOOTP/DHCP, Reply, length 312 >>>> 20:17:26.944378 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, >>>> Request from 98:f2:b3:3f:72:e5 (oui Unknown), length 347 >>>> 20:17:26.944756 IP controller.bootps > 255.255.255.255.bootpc: >>>> BOOTP/DHCP, Reply, length 312 >>>> 20:17:30.763627 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, >>>> Request from 98:f2:b3:3f:72:e5 (oui Unknown), length 359 >>>> 20:17:30.764620 IP controller.bootps > 255.255.255.255.bootpc: >>>> BOOTP/DHCP, Reply, length 312 >>>> 20:17:54.938791 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, >>>> Request from 98:f2:b3:3f:72:e5 (oui Unknown), length 347 >>>> >>>> Also the neutron dnsmasq logs and ironic inspector logs are attached in >>>> the mail. >>>> >>>> Regards >>>> Anirudh Gupta >>>> >>>> >>>> On Tue, Aug 3, 2021 at 7:29 PM Dmitry Tantsur >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> You need to check the dnsmasq logs (there are two dnsmasqs: from >>>>> neutron and from ironic-inspector). tcpdump may also help to determine >>>>> where the packages are lost. >>>>> >>>>> Dmitry >>>>> >>>>> On Fri, Jul 30, 2021 at 10:29 PM Anirudh Gupta >>>>> wrote: >>>>> >>>>>> Hi Dmitry >>>>>> >>>>>> Thanks for your time. >>>>>> >>>>>> My system is getting IP 20.20.20.10 which is in the range defined in >>>>>> ironic_dnsmasq_dhcp_range field under globals.yml file. >>>>>> >>>>>> ironic_dnsmasq_dhcp_range: "20.20.20.10,20.20.20.100" >>>>>> >>>>>> And in the cleaning network (public1), the range defined is >>>>>> 20.20.20.150-20.20.20.200 >>>>>> >>>>>> As per my understanding, these 2 ranges should be mutually exclusive. >>>>>> >>>>>> Please suggest if my understanding is not correct. >>>>>> >>>>>> Any suggestions what should I do to resolve this issue? >>>>>> >>>>>> Regards >>>>>> Anirudh Gupta >>>>>> >>>>>> >>>>>> On Sat, 31 Jul, 2021, 12:06 am Dmitry Tantsur, >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Jul 29, 2021 at 6:05 PM Anirudh Gupta >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Team, >>>>>>>> >>>>>>>> In to the email below, I have some updated information:- >>>>>>>> >>>>>>>> Earlier the allocation range mentioned in " >>>>>>>> *ironic_dnsmasq_dhcp_range*" in globals.yml had an overlapping >>>>>>>> range with the cleaning network, due to which there was some issue in >>>>>>>> receiving the DHCP request >>>>>>>> >>>>>>>> After creating a cleaning network with a separate allocation range, >>>>>>>> I am successfully getting IP allocated to my Baremetal Node >>>>>>>> >>>>>>>> - openstack subnet create subnet1 --network public1 >>>>>>>> --subnet-range 20.20.20.0/24 --allocation-pool >>>>>>>> start=20.20.20.150,end=20.20.20.200 --ip-version=4 --gateway=20.20.20.1 >>>>>>>> --dhcp >>>>>>>> >>>>>>>> >>>>>>>> [image: image.png] >>>>>>>> >>>>>>>> After getting the IP, there is no further action on the node. From " >>>>>>>> *clean_wait*", it goes into "*clean_failed*" state after around >>>>>>>> half an hour. >>>>>>>> >>>>>>> >>>>>>> The IP address is not from the cleaning range, it may come from >>>>>>> inspection. You probably need to investigate your network topology, maybe >>>>>>> use tcpdump. >>>>>>> >>>>>>> Unfortunately, I'm not fluent in Kolla to say if it can be a bug or >>>>>>> not. >>>>>>> >>>>>>> Dmitry >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> On verifying the logs, I could see the below error messages >>>>>>>> >>>>>>>> >>>>>>>> - In */var/log/kolla/ironic/ironic-conductor.log*, we observed >>>>>>>> the following error: >>>>>>>> >>>>>>>> ERROR ironic.conductor.utils [-] Cleaning for node >>>>>>>> 3a56748e-a8ca-4dec-a332-ace18e6d494e failed. *Timeout reached >>>>>>>> while cleaning the node. Please check if the ramdisk responsible for the >>>>>>>> cleaning is running on the node. Failed on step {}.* >>>>>>>> >>>>>>>> >>>>>>>> Note : For Cleaning the node, we have used the below images >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> https://tarballs.openstack.org/ironic-python-agent/dib/files/ipa-centos8-master.kernel >>>>>>>> >>>>>>>> >>>>>>>> https://tarballs.openstack.org/ironic-python-agent/dib/files/ipa-centos8-master.initramfs >>>>>>>> >>>>>>>> >>>>>>>> - In /var/log/kolla/nova/nova-compute-ironic.log, we observed >>>>>>>> the error >>>>>>>> >>>>>>>> ERROR nova.compute.manager >>>>>>>> [req-810ffedf-3343-471c-94db-85411984e6cc - - - - -] No compute node record >>>>>>>> for host controller-ironic: >>>>>>>> nova.exception_Remote.ComputeHostNotFound_Remote: Compute host >>>>>>>> controller-ironic could not be found. >>>>>>>> >>>>>>>> >>>>>>>> Can someone please help in this regard? >>>>>>>> >>>>>>>> Regards >>>>>>>> Anirudh Gupta >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Jul 27, 2021 at 12:52 PM Anirudh Gupta >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi Team, >>>>>>>>> >>>>>>>>> We have deployed 2 node kolla ansible *12.0.0* in order to deploy >>>>>>>>> openstack *wallaby* release. We have also enabled ironic in order >>>>>>>>> to provision the bare metal nodes. >>>>>>>>> >>>>>>>>> On each server we have 3 nics >>>>>>>>> >>>>>>>>> - *eno1* - OAM for external connectivity and endpoint's >>>>>>>>> publicURL >>>>>>>>> - *eno2* - Mgmt for internal communication between various >>>>>>>>> openstack services. >>>>>>>>> - *ens2f0* - Data Interface >>>>>>>>> >>>>>>>>> >>>>>>>>> Corresponding to this we have defined the following fields in >>>>>>>>> globals.yml >>>>>>>>> >>>>>>>>> >>>>>>>>> - kolla_base_distro: "centos" >>>>>>>>> - kolla_install_type: "source" >>>>>>>>> - openstack_release: "wallaby" >>>>>>>>> - network_interface: "eno2" # >>>>>>>>> MGMT interface >>>>>>>>> - kolla_external_vip_interface: "eno1" # OAM >>>>>>>>> Interface >>>>>>>>> - kolla_internal_vip_address: "192.168.10.3" # MGMT Subnet >>>>>>>>> free ip >>>>>>>>> - kolla_external_vip_address: "10.0.1.136" # OAM subnet >>>>>>>>> free IP >>>>>>>>> - neutron_external_interface: "ens2f0" # Data >>>>>>>>> Interface >>>>>>>>> - enable_neutron_provider_networks: "yes" >>>>>>>>> >>>>>>>>> Note: Only relevant fields are being shown in this query >>>>>>>>> >>>>>>>>> Also, for ironic following fields have been defined in globals.yml >>>>>>>>> >>>>>>>>> - enable_ironic: "yes" >>>>>>>>> - enable_ironic_neutron_agent: "{{ enable_neutron | bool and >>>>>>>>> enable_ironic | bool }}" >>>>>>>>> - enable_horizon_ironic: "{{ enable_ironic | bool }}" >>>>>>>>> - ironic_dnsmasq_interface: "*ens2f0*" # >>>>>>>>> Data interface >>>>>>>>> - ironic_dnsmasq_dhcp_range: "20.20.20.10,20.20.20.100" >>>>>>>>> - ironic_dnsmasq_boot_file: "pxelinux.0" >>>>>>>>> - ironic_cleaning_network: "public1" >>>>>>>>> - ironic_dnsmasq_default_gateway: "20.20.20.1" >>>>>>>>> >>>>>>>>> >>>>>>>>> After successful deployment, a flat provider network with the name >>>>>>>>> public1 is being created in openstack using the below commands: >>>>>>>>> >>>>>>>>> >>>>>>>>> - openstack network create public1 --provider-network-type >>>>>>>>> flat --provider-physical-network physnet1 >>>>>>>>> - openstack subnet create subnet1 --network public1 >>>>>>>>> --subnet-range 20.20.20.0/24 --allocation-pool >>>>>>>>> start=20.20.20.10,end=20.20.20.100 --ip-version=4 --gateway=20.20.20.1 >>>>>>>>> --dhcp >>>>>>>>> >>>>>>>>> >>>>>>>>> Issue/Queries: >>>>>>>>> >>>>>>>>> >>>>>>>>> - Is the configuration done in globals.yml correct or is there >>>>>>>>> anything else that needs to be done in order to separate control and data >>>>>>>>> plane traffic? >>>>>>>>> >>>>>>>>> >>>>>>>>> - Also I have set automated_cleaning as "true" in >>>>>>>>> ironic-conductor conatiner settings.But after creating the baremetal node, >>>>>>>>> we run "node manage" command which runs successfully. Running "*openstack >>>>>>>>> baremetal node provide "* command powers on the >>>>>>>>> machine, sets the boot mode on Network Boot but no DHCP request for that >>>>>>>>> particular mac is obtained on the controller. Is there anything I am >>>>>>>>> missing that needs to be done in order to make ironic work? >>>>>>>>> >>>>>>>>> Note: I have also verified that the nic is PXE enabled in system >>>>>>>>> configuration setting >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Anirudh Gupta >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, >>>>>>> Commercial register: Amtsgericht Muenchen, HRB 153243, >>>>>>> Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, >>>>>>> Michael O'Neill >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, >>>>> Commercial register: Amtsgericht Muenchen, HRB 153243, >>>>> Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, >>>>> Michael O'Neill >>>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 38285 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 185546 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 200447 bytes Desc: not available URL: From number9 at dimlight.org Mon Aug 9 15:36:29 2021 From: number9 at dimlight.org (number9) Date: Mon, 09 Aug 2021 10:36:29 -0500 Subject: [ops] Openstack Victoria SPICE configuration not working In-Reply-To: <5e202efe22375125c82f5aaf6463214b7598dc44.camel@redhat.com> References: <2e6f3235c70b84f47730cce25888541b@dimlight.org> <5e202efe22375125c82f5aaf6463214b7598dc44.camel@redhat.com> Message-ID: <098c4004fc512d738814b1843ed6ae2f@dimlight.org> On 2021-08-09 05:59, Stephen Finucane wrote: > On Thu, 2021-08-05 at 12:25 -0500, number9 wrote: >> I have posted this on stackexchange, but am also asking here: >> >> Running openstack on Ubuntu 20.04 with a controller node and four >> compute nodes. I am reading the instructions on configuring SPICE >> here. >> I will admit, I found out about which packages to install from other >> sites, as the instructions at the link do not actually list any >> software >> that needs to be installed. >> >> On the compute nodes and controller, I installed nova-spiceproxy >> On the controller I installed nova-spiceproxy and spice-html5 > > Not an answer, but as an aside SPICE support is poorly maintained in > nova and > its usage not generally advised. It may be removed in a future release. > I would > suggest relying on noVNC instead. With that said... Hrm, I might try to go back to noVNC. I could never get that working either. > >> >> I followed the instructions in the link on configuring >> /etc/nova/nova.conf on the controller and all compute nodes. >> > > There's a typo here, but it shouldn't matter - that config option has > been > replaced by the '[vnc] enabled' option below. The doc clearly needs an > update. > As another aside, because virtually everyone seems to use an installer, > the > actual install guides get very TLC and are subsequently prone to bitrot > :( > However, the remote console doc at [1] was updated in recent releases > and should > be relatively accurate. > > [1] > https://docs.openstack.org/nova/latest/admin/remote-console-access.html > I have been referencing the above doc. I am just noting that I was putting in redundancies as I never know what is really working in the configs when there are differences from say one version to the next. >> # yes, I know it is redundant, I am following the docs... >> >> [vnc] >> enabled = false >> >> [spice] >> enabled = true >> agent_enabled = true >> html5proxy_base_url = http://10.131.39.40:6082/spice_auto.html >> # the above IP is the IP of the controller. >> server_listen = 0.0.0.0 >> server_proxyclient_address = 10.131.29.42 > > So I assume '10.131.39.40' is address of the controller and > '10.131.29.42' is > the address of the compute node, yes? Is the former publicly accessible > from the > same place you're browsing the web UX? I would assume not, given it's a > private > network IP. If not, this needs to be updated. This is the value > returned from > the API which is in turn used by Horizon iirc. YES, the private internal IIP address scheme is what people hit horizon dashboard on. The clients are am on a private internal network. > > I suspect the issue is with the address used for '[spice] > html5proxy_base_url'. > I would suggest using the 'openstack console url show' command to get a > URL to > access the console without needing to invoke Horizon. If you're able to > access > this URL then the issue is instead somewhere in Horizon. If not, it's > definitely > nova. You can also enable debug-level logging for the > nova-spicehtml5proxy and > nova-novncproxy services to ensure you're actually seeing a connection > from your > browser. I will check openstack console url show It says I need a , but no matter what I put in, I get "no server name or ID of that exists". Huh, perhaps I am loosing my mind? I can login to horizon and spin up VMs, but this is blank: openstack server list As I was trying different server names on openstack console url show. From ildiko.vancsa at gmail.com Mon Aug 9 15:46:38 2021 From: ildiko.vancsa at gmail.com (Ildiko Vancsa) Date: Mon, 9 Aug 2021 08:46:38 -0700 Subject: [nova][cyborg][gpu] GPU performance testing Message-ID: Hi, I got a question about tools and practices to check GPU performance in an OpenStack environment that I need some help to answer. The question is about recommended GPU performance testing/benchmarking tools if there are a few that people in the community are using and would recommend? The scope of the testing work is to check GPU performance in OpenStack VMs (both virtualized and passthrough). All the help and pointers are very much appreciated! Thanks, Ildikó From stephenfin at redhat.com Mon Aug 9 15:48:03 2021 From: stephenfin at redhat.com (Stephen Finucane) Date: Mon, 09 Aug 2021 16:48:03 +0100 Subject: [ops] Openstack Victoria SPICE configuration not working In-Reply-To: <098c4004fc512d738814b1843ed6ae2f@dimlight.org> References: <2e6f3235c70b84f47730cce25888541b@dimlight.org> <5e202efe22375125c82f5aaf6463214b7598dc44.camel@redhat.com> <098c4004fc512d738814b1843ed6ae2f@dimlight.org> Message-ID: <0cc77f5786a7f294dc45f755bb7d52953c07bead.camel@redhat.com> On Mon, 2021-08-09 at 10:36 -0500, number9 wrote: > On 2021-08-09 05:59, Stephen Finucane wrote: > > On Thu, 2021-08-05 at 12:25 -0500, number9 wrote: > > > I have posted this on stackexchange, but am also asking here: > > > > > > Running openstack on Ubuntu 20.04 with a controller node and four > > > compute nodes. I am reading the instructions on configuring SPICE > > > here. > > > I will admit, I found out about which packages to install from other > > > sites, as the instructions at the link do not actually list any > > > software > > > that needs to be installed. > > > > > > On the compute nodes and controller, I installed nova-spiceproxy > > > On the controller I installed nova-spiceproxy and spice-html5 > > > > Not an answer, but as an aside SPICE support is poorly maintained in > > nova and > > its usage not generally advised. It may be removed in a future release. > > I would > > suggest relying on noVNC instead. With that said... > > Hrm, I might try to go back to noVNC. I could never get that working > either. > > > > > > > > > I followed the instructions in the link on configuring > > > /etc/nova/nova.conf on the controller and all compute nodes. > > > > > > > There's a typo here, but it shouldn't matter - that config option has > > been > > replaced by the '[vnc] enabled' option below. The doc clearly needs an > > update. > > As another aside, because virtually everyone seems to use an installer, > > the > > actual install guides get very TLC and are subsequently prone to bitrot > > :( > > However, the remote console doc at [1] was updated in recent releases > > and should > > be relatively accurate. > > > > [1] > > https://docs.openstack.org/nova/latest/admin/remote-console-access.html > > > > I have been referencing the above doc. I am just noting that I was > putting > in redundancies as I never know what is really working in the configs > when > there are differences from say one version to the next. > > > > > # yes, I know it is redundant, I am following the docs... > > > > > > [vnc] > > > enabled = false > > > > > > [spice] > > > enabled = true > > > agent_enabled = true > > > html5proxy_base_url = http://10.131.39.40:6082/spice_auto.html > > > # the above IP is the IP of the controller. > > > server_listen = 0.0.0.0 > > > server_proxyclient_address = 10.131.29.42 > > > > So I assume '10.131.39.40' is address of the controller and > > '10.131.29.42' is > > the address of the compute node, yes? Is the former publicly accessible > > from the > > same place you're browsing the web UX? I would assume not, given it's a > > private > > network IP. If not, this needs to be updated. This is the value > > returned from > > the API which is in turn used by Horizon iirc. > > YES, the private internal IIP address scheme is what people hit horizon > dashboard > on. The clients are am on a private internal network. Another thing to try is to connect the server directly using a local SPICE or VNC client. The IP address will be the IP of the compute host, while the port can be seen in the XML for each individual instance. This isn't a long-term solution but it's another way to rule out potentially faulty or misconfigured components. > > > > > I suspect the issue is with the address used for '[spice] > > html5proxy_base_url'. > > I would suggest using the 'openstack console url show' command to get a > > URL to > > access the console without needing to invoke Horizon. If you're able to > > access > > this URL then the issue is instead somewhere in Horizon. If not, it's > > definitely > > nova. You can also enable debug-level logging for the > > nova-spicehtml5proxy and > > nova-novncproxy services to ensure you're actually seeing a connection > > from your > > browser. > > I will check openstack console url show > > It says I need a , but no matter what I put in, I get "no server > name or ID of that exists". > > > Huh, perhaps I am loosing my mind? I can login to horizon and spin up > VMs, but this is blank: > > openstack server list > > As I was trying different server names on openstack console url show. This sounds like you are using a different tenant/project and possibly different user for the CLI vs. the web UI. If you're using a stackrc file, check the value of the 'OS_PROJECT_ID' and 'OS_PROJECT_NAME' environment variables against what's showing in your web UI (top right corner, iirc). If you're using a 'clouds.yaml' file, check the value of 'clouds.$cloud.auth.project_id' and 'clouds.$cloud.auth.project_name' against same. Stephen From rdhasman at redhat.com Mon Aug 9 16:20:03 2021 From: rdhasman at redhat.com (Rajat Dhasmana) Date: Mon, 9 Aug 2021 21:50:03 +0530 Subject: Snapshot Attachment support in cinder In-Reply-To: References: Message-ID: Hi Manoj, Snapshot attachment is a feature used to create backups from a snapshot efficiently if the driver supports it. This functionality is not exposed to users and is an optimization rather than a feature that a backend supports. See patch[1] which corrects its description in the support matrix. [1] https://review.opendev.org/c/openstack/cinder/+/800015 On Mon, Aug 9, 2021 at 2:55 PM Katari Kumar wrote: > Hi everyone, > > Is snapshot attachment supported by openstack ? does it really look for > the sanpshot table when we perform attachemnt with snapshot id? > i see this error below > stack at altranvm4:~$ cinder list > > +--------------------------------------+-----------+--------------------------+------+-----------------+----------+-------------+ > | ID | Status | Name > | Size | Volume Type | Bootable | Attached to | > > +--------------------------------------+-----------+--------------------------+------+-----------------+----------+-------------+ > | 418f5dd9-bed9-4a04-abf4-26cae153beb7 | available | non-rep-vol1 > | 1 | vol_type_auto_0 | false | | > | e646f5ca-071d-4e3d-b8a9-844301e703a5 | available | > clone_non_rep_vol_auto_0 | 1 | vol_type_auto_1 | false | | > > +--------------------------------------+-----------+--------------------------+------+-----------------+----------+-------------+ > stack at altranvm4:~$ cinder snapshot-list > > +--------------------------------------+--------------------------------------+-----------+-----------+------+----------------------------------+ > | ID | Volume ID > | Status | Name | Size | User ID | > > +--------------------------------------+--------------------------------------+-----------+-----------+------+----------------------------------+ > | e229406e-3b93-4c4c-aabb-43e017bd0c1a | > 418f5dd9-bed9-4a04-abf4-26cae153beb7 | available | snap-vol1 | 1 | > 2f9f21f8794d430fb7d425cf7243c22a | > > +--------------------------------------+--------------------------------------+-----------+-----------+------+----------------------------------+ > stack at altranvm4:~$ openstack server list > > +--------------------------------------+-------------+--------+------------------------+--------------------------+-----------+ > | ID | Name | Status | Networks > | Image | Flavor | > > +--------------------------------------+-------------+--------+------------------------+--------------------------+-----------+ > | 46958490-f41f-4a98-9a7a-ae1f93b8b73e | host_auto_0 | ACTIVE | > shared=192.168.233.6 | cirros-0.5.2-x86_64-disk | cirros256 | > | 3026096b-efb4-4dd5-a73b-804d87c1ca1e | testhost1 | ACTIVE | > shared=192.168.233.138 | cirros-0.5.2-x86_64-disk | cirros256 | > > +--------------------------------------+-------------+--------+------------------------+--------------------------+-----------+ > > * stack at altranvm4:~$ openstack server add volume > 3026096b-efb4-4dd5-a73b-804d87c1ca1e > e229406e-3b93-4c4c-aabb-43e017bd0c1a No volume with a name or ID of > 'e229406e-3b93-4c4c-aabb-43e017bd0c1a' exists.* > > it is looking for the id in the volume table , where as the id given is a > snapshot > Cinder support matrix ( > https://docs.openstack.org/cinder/latest/reference/support-matrix.html) > says many drivers are supporting snapshot attachment. i wonder how ? > Even the '#cinder attachment-create' gives the same error if snapshot is > used for attachment. > > BR, > Manoj Katari > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From katkumar at in.ibm.com Mon Aug 9 17:03:37 2021 From: katkumar at in.ibm.com (Katari Kumar) Date: Mon, 9 Aug 2021 17:03:37 +0000 Subject: Snapshot Attachment support in cinder In-Reply-To: References: , Message-ID: An HTML attachment was scrubbed... URL: From rosmaita.fossdev at gmail.com Mon Aug 9 19:05:45 2021 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Mon, 9 Aug 2021 15:05:45 -0400 Subject: [cinder] xena R-9 mid-cycle summary available Message-ID: <385994f5-a209-0a76-9a66-de56bd405fb5@gmail.com> In case you missed last week's exciting cinder R-9 virtual mid-cycle session, I've posted a summary: https://wiki.openstack.org/wiki/CinderXenaMidCycleSummary The mid-cycle was recorded; there's a link on the wiki page. Although we're done with midcycles for Xena, the excitement is not over for cinder. There are our regular weekly meetings [1,2] and the August edition of the Festival of XS Reviews [3] is coming up soon. cheers, brian [1] https://meetings.opendev.org/#Cinder_Team_Meeting [2] https://meetings.opendev.org/#Cinder_Bug_Squad_Meeting [3] https://meetings.opendev.org/#Cinder_Festival_of_XS_Reviews From gmann at ghanshyammann.com Mon Aug 9 19:46:55 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Mon, 09 Aug 2021 14:46:55 -0500 Subject: [all][tc] Technical Committee next weekly meeting on Aug 12th at 1500 UTC Message-ID: <17b2c742a53.d429dbd810840.1063787877581206666@ghanshyammann.com> Hello Everyone, Technical Committee's next weekly meeting is scheduled for Aug 12th at 1500 UTC. If you would like to add topics for discussion, please add them to the below wiki page by Wednesday, Aug 11th, at 2100 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting -gmann From tonyliu0592 at hotmail.com Tue Aug 10 03:37:54 2021 From: tonyliu0592 at hotmail.com (Tony Liu) Date: Tue, 10 Aug 2021 03:37:54 +0000 Subject: [tripleo][collectd][snmp]configuration example Message-ID: Hi, I am trying to enable SNMP plugin for collected by tripleo. I had some tries, but no luck. Can't figure it out by reading puppet module. Could anyone show me an example to configure a list of "host" and "data" in template? Thanks! Tony From berndbausch at gmail.com Tue Aug 10 06:38:55 2021 From: berndbausch at gmail.com (Bernd Bausch) Date: Tue, 10 Aug 2021 15:38:55 +0900 Subject: Octavia In-Reply-To: References: <26e5229a-0584-c5f5-e85f-6547b158dc47@gmail.com> Message-ID: <3088a3b9-f683-3117-9e67-eec1fb74c3eb@gmail.com> The stacktrace shows that Octavia can't reach an Amphora. I suppose you get this log when trying to create a loadbalancer? If so, most likely the Amphora management network is not set up correctly. The difficulty is that Octavia workers, which are /processes /running on the controllers, need to have access to the same management network as the Amphora /instances/. If you implement the management network as a normal tenant network, some non-trivial manual Openvswitch configuration is required. See https://docs.openstack.org/octavia/latest/install/install-ubuntu.html#install-and-configure-components for instructions. In production settings, usually a VLAN is used, which is easy to access from controller processes. I succeeded running Octavia on a Kolla cluster with three-way controllers, with a tenant network (VXLAN-based) for amphora management. My notes are attached (they are tailored to my configuration, of course). Bernd. On 2021/08/09 10:57 AM, Chris Lyons wrote: Well…it gets. A lot further….  I see this error now…. Im looking around to see if it’s a security group missing or if there is some other setting I missed.  Im not seeing any scripts to prep the env…usually there is something like that if it’s a security group…anyone know? ... 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker Traceback (most recent call last): 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker   File "/usr/lib/python3.6/site-packages/taskflow/engines/action_engine/executor.py", line 53, in _execute_task 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker     result = task.execute(**arguments) 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker   File "/usr/lib/python3.6/site-packages/octavia/controller/worker/v1/tasks/amphora_driver_tasks.py", line 424, in execute 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker     amp_info = self.amphora_driver.get_info(amphora) 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker   File "/usr/lib/python3.6/site-packages/octavia/amphorae/drivers/haproxy/rest_api_driver.py", line 373, in get_info 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker     amphora, raise_retry_exception=raise_retry_exception) 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker   File "/usr/lib/python3.6/site-packages/octavia/amphorae/drivers/haproxy/rest_api_driver.py", line 106, in _populate_amphora_api_version 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker raise_retry_exception=raise_retry_exception)['api_version'] 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker   File "/usr/lib/python3.6/site-packages/octavia/amphorae/drivers/haproxy/rest_api_driver.py", line 744, in get_api_version 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker raise_retry_exception=raise_retry_exception) 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker   File "/usr/lib/python3.6/site-packages/octavia/amphorae/drivers/haproxy/rest_api_driver.py", line 738, in request 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker     raise driver_except.TimeOutException() 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker octavia.amphorae.driver_exceptions.exceptions.TimeOutException: contacting the amphora timed out ... -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- =========================================================================== Make the Loadbalancer management network accessible to controllers =========================================================================== Assumptions ----------------------------------------------------- By default, kolla-ansible creates a VXLAN named lb-mgmt-net. These instructions assume the following characteristics: $ openstack subnet show lb-mgmt-subnet -c allocation_pools -c cidr -c gateway_ip -c enable_dhcp +------------------+-------------------------+ | Field | Value | +------------------+-------------------------+ | allocation_pools | 172.16.0.50-172.16.0.99 | | cidr | 172.16.0.0/24 | | enable_dhcp | True | | gateway_ip | 172.16.0.166 | +------------------+-------------------------+ Create a NIC that facilitates access to lb-mgmt-net -------------------------------------------------------- Get DHCP server's port ID and host: openstack port list --network lb-mgmt-net openstack network agent list --network lb-mgmt-net We assume host is k1 for the rest of this document. Find the VLAN ID (tag) that Openvswitch associated the with DHCP server's NIC. The NIC's name starts with "tap", then the first 12 characters of the port ID. ssh k1 sudo docker exec openvswitch_vswitchd ovsdb-client \ dump unix:/var/run/openvswitch/db.sock Open_vSwitch Port name tag Port table name tag -------------- --- br-ex [] ... tap4df0c7a2-27 1 <<< DHCP server's port ID starts with 4df0c7a2-27 Here the VLAN ID (tag) is 1. Create a bridge port in br-int and give it the same VLAN ID (tag) as before: ssh k1 sudo docker exec openvswitch_vswitchd ovs-vsctl add-port br-int o-hm0 tag=1 -- \ set interface o-hm0 type=internal These are two commands in one, separated by a double dash. Double-check success with ssh k1 ip a show dev o-hm0 Configure the lb-mgmt-net gateway address on o-hm0 --------------------------------------------------------- On k1, add two lines to /etc/netplan/00-installer-config.yaml: o-hm0: addresses: [ 172.16.0.166/24 ] version: 2 then ssh k1 sudo netplan apply Double-check success. o-hm0 should be up and have its IP address, and there should be a route to 172.16.0.0/24 via o-hm0. ssh k1 ip a show dev o-hm0 ssh k1 ip r Add routes from k2 and k3 to o-hm0 ------------------------------------------------------------ At this point, the network is accessible to k1. Add routes to the other controllers via k1. ssh k2 sudo ip r add 172.16.0.0/24 via 192.168.122.201 ssh k1 sudo ip r add 172.16.0.0/24 via 192.168.122.201 Make routes persistent on k2 and k3. $ cat /etc/netplan/00-installer-config.yaml # This is the network config written by 'subiquity' network: ethernets: ens3: .... routes: - to: 172.16.0.0/24 via: 192.168.122.201 Relax the firewall on k1 ------------------------------------------------------------- The firewall must allow traffic from and to lb-mgmt-net. Create an rc.local file with this content: #!/bin/bash iptables -A FORWARD -s 172.16.0.0/24 -j ACCEPT iptables -A FORWARD -d 172.16.0.0/24 -j ACCEPT Make it executable, then enable and start the rc-local service. sudo chmod +x /etc/rc.local sudo systemctl enable rc-local --now From kkchn.in at gmail.com Tue Aug 10 07:54:53 2021 From: kkchn.in at gmail.com (KK CHN) Date: Tue, 10 Aug 2021 13:24:53 +0530 Subject: WIndows VMs exporting toe KVM hosts : Once KVM host fails to boot the VM Message-ID: I am migrating one Windows 12 VM from oVirt hypervisor. The Windows image is a single disk images. I have two KVM hosts running .. I am successfully able to import the VM to one of our KVM host. Windows VM is up and running able to login to the Desktop environment. But the same VM image I am trying in the second KVM host to launch it, its not booting Booting from Hard disk ...... / Its wait in this state for a long ( 20 minutes ) . I tried to delete and create the VM again in the second KVM host, its reaching to Booting from Hard disk .... // No progress after this.. Any suggestions for troubleshooting? . Does I have to execute any utilities and its out put required for trouble shooting let me know. Kris -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at stackhpc.com Tue Aug 10 07:54:09 2021 From: mark at stackhpc.com (Mark Goddard) Date: Tue, 10 Aug 2021 08:54:09 +0100 Subject: [kolla] Transitioning stable/queens to eol In-Reply-To: References: Message-ID: +1 On Mon, 9 Aug 2021 at 12:26, Michał Nasiadka wrote: > > Hello, > > We've kept stable/queens branches of kolla and kolla-ansible around under extended maintenance for a while now. > The coordinated Queens release was 28th Feb, 2018 (Kolla on 26th Mar, 2018). > > The last time a change was backported to these branches has been a while: > - kolla > stable/queens: Jun 8, 2020 > - kolla-ansible > stable/queens: Nov 3, 2019 > > There is no CI running for those projects periodically, last CI jobs have been run: > - kolla - 24th Aug, 2020 > - kolla-ansible - 17th Jun, 2020 > > All changes to those branches have been abandoned long time (and nothing new proposed for at least a year): > https://review.opendev.org/q/branch:stable/queens+project:openstack/kolla > https://review.opendev.org/q/branch:stable/queens+project:openstack/kolla-ansible > > So, I'd like to request that these branches be moved to end-of-life. > > Patch proposed to add EOL tags to both kolla and kolla-ansible: > https://review.opendev.org/c/openstack/releases/+/803701 > > -- > Michał Nasiadka > mnasiadka at gmail.com From hberaud at redhat.com Tue Aug 10 10:13:36 2021 From: hberaud at redhat.com (Herve Beraud) Date: Tue, 10 Aug 2021 12:13:36 +0200 Subject: [oslo] feature freeze - Aug 23 - Aug 27 (R-6) Message-ID: Hello Osloers, Just a friendly reminder that oslo's feature freeze will happen in 2 weeks (R-6 - Aug 23 - Aug 27). It's earlier than everyone else, and if you're wondering why, we have a policy[1] that discusses it. The main thing is that if you have features you want to get into Oslo libraries this cycle, please make sure they merge by Friday. After that we'll need to go through the FFE process and there's no guarantee we can land them. Feel free to ping us on IRC if you need reviews. Thanks for your attention. [1] http://specs.openstack.org/openstack/oslo-specs/specs/policy/feature-freeze.html -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -------------- next part -------------- An HTML attachment was scrubbed... URL: From radoslaw.piliszek at gmail.com Tue Aug 10 11:55:23 2021 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Tue, 10 Aug 2021 13:55:23 +0200 Subject: [kolla] Transitioning stable/queens to eol In-Reply-To: References: Message-ID: +1 On Tue, Aug 10, 2021 at 9:54 AM Mark Goddard wrote: > > +1 > > On Mon, 9 Aug 2021 at 12:26, Michał Nasiadka wrote: > > > > Hello, > > > > We've kept stable/queens branches of kolla and kolla-ansible around under extended maintenance for a while now. > > The coordinated Queens release was 28th Feb, 2018 (Kolla on 26th Mar, 2018). > > > > The last time a change was backported to these branches has been a while: > > - kolla > > stable/queens: Jun 8, 2020 > > - kolla-ansible > > stable/queens: Nov 3, 2019 > > > > There is no CI running for those projects periodically, last CI jobs have been run: > > - kolla - 24th Aug, 2020 > > - kolla-ansible - 17th Jun, 2020 > > > > All changes to those branches have been abandoned long time (and nothing new proposed for at least a year): > > https://review.opendev.org/q/branch:stable/queens+project:openstack/kolla > > https://review.opendev.org/q/branch:stable/queens+project:openstack/kolla-ansible > > > > So, I'd like to request that these branches be moved to end-of-life. > > > > Patch proposed to add EOL tags to both kolla and kolla-ansible: > > https://review.opendev.org/c/openstack/releases/+/803701 > > > > -- > > Michał Nasiadka > > mnasiadka at gmail.com > From kennelson11 at gmail.com Tue Aug 10 13:17:07 2021 From: kennelson11 at gmail.com (Kendall Nelson) Date: Tue, 10 Aug 2021 06:17:07 -0700 Subject: [TC] [horizon] Project Skyline Timeline Message-ID: Hello All! I would like to introduce you to project Skyline[1]! The team has been hard at work getting it ready for the project proposal stage. While they are not quite ready yet (still working on Zuul testing and devstack integration), I wanted to take a moment and give a little history on conversations in this space and see if there was anything else they needed to do before we actually draft the project proposal. There was a mailing list thread[2] a while back that discussed updating Horizon and what that would look like. I would encourage you to read it if you're interested in the complete history, but it all boils down to a few summaries- Mohammed's[3]: ".... 1. Distributions are happy in the way that Horizon is deployed today 2. Distributions don't want to have a front-end JS based thingamajig 3. Users, operators and deployers want to improve the UI experience of Horizon 4. There is so much _historic_ stuff stuffed into Horizon that rewriting something from scratch is easier than refactoring Horizon 5. The path to improving UI inside OpenStack is "starting from scratch". ...." Adrian's [4]: "...As corny as it sounds, I think the first step is admitting we have a problem, and getting a group of interested parties involved to actually "design/build something better by broadcasting a call to arms of sorts. Radomir's [5]: "The current Horizon developers are not going to do it. We are too busy maintaining the released versions of Horizon and trying to keep up with new features being added to OpenStack, and that situation is unlikely to change for at least several years from now, even if a replacement for Horizon with full feature parity was released tomorrow — we will still need to support the released versions of Horizon. We are happy to help with advice and explanations of how current Horizon implementation works — but we won't write the code. You have to start that project yourself or find other developers willing to work on it, who won't mind you telling them which framework to use." Thierry's[6]: " From the outside of this hypothetical team, the Horizon team says that it will continue to maintain the distro-friendly Django-based Horizon code, and that as a team it has no interest/bandwidth in driving a rewrite internally. That means a new team needs to form up (even if obviously some people can be member of both teams). Now from the outside of this hypothetical new team, the TC can say if it supports the idea of a more-JS-native harder-to-package framework and would gladly add it the list of official OpenStack project teams as an alternative solution to Horizon. That may encourage some to step up." And Akihiro[7] "The current state of horizon is almost in the maintenance mode. We have less contributors release by release. The current horizon team is very small (and horizon cores except one are part-time with other projects or outside of OpenStack upstream), so I don't think the horizon team can lead the effort properly. I think it is better that folks interested in this start an effort to implement OpenStack dashboard in modern technologies for better UX as a separate project (or a separate branch)." Cut to the last PTG[8] when the Skyline folks attended the Horizon sessions to work with the team which you can also catch up. And now, we have the Skyline team working on the last few things (I think) before they are ready to propose it as an OpenStack project. I, for one, am excited to have this infusion of new contributors that can help bring a new OpenStack dashboard into reality. If you have any feedback on other things that need to happen before they can be proposed as a project, please reply! -Kendall Nelson (diablo_rojo) [1] Repos: https://opendev.org/skyline/ [2] Original thread: http://lists.openstack.org/pipermail/openstack-discuss/2020-June/015551.html [3] Mohammed's summary http://lists.openstack.org/pipermail/openstack-discuss/2020-June/015654.html [4] Adrian's summary http://lists.openstack.org/pipermail/openstack-discuss/2020-June/015659.html [5] Radomir's summary http://lists.openstack.org/pipermail/openstack-discuss/2020-June/015667.html [6] Thierry's summary http://lists.openstack.org/pipermail/openstack-discuss/2020-June/015674.html [7] Akihiro's summary http://lists.openstack.org/pipermail/openstack-discuss/2020-June/015575.html[] [8] PTG Discussion: https://etherpad.opendev.org/p/xena-ptg-horizon-planning -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Tue Aug 10 14:50:30 2021 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 10 Aug 2021 14:50:30 +0000 Subject: [OSSA-2021-003] Keystone: Account name and UUID oracles in account locking (CVE-2021-38155) Message-ID: <20210810145029.vjopu2uukazukvy6@yuggoth.org> =============================================================== OSSA-2021-003: Account name and UUID oracles in account locking =============================================================== :Date: August 10, 2021 :CVE: CVE-2021-38155 Affects ~~~~~~~ - Keystone: >=10.0.0 <16.0.2, >=17.0.0 <17.0.1, >=18.0.0 <18.0.1, >=19.0.0 <19.0.1 Description ~~~~~~~~~~~ Samuel de Medeiros Queiroz with Oi Cloud reported a vulnerability affecting Keystone account locking. By guessing the name of an account and failing to authenticate multiple times, any unauthenticated actor could both confirm the account exists and obtain that account's corresponding UUID, which might be leveraged for other unrelated attacks. All Keystone deployments enabling security_compliance.lockout_failure_attempts are affected. Patches ~~~~~~~ - https://review.opendev.org/790444 (Train) - https://review.opendev.org/790443 (Ussuri) - https://review.opendev.org/790442 (Victoria) - https://review.opendev.org/790440 (Wallaby) - https://review.opendev.org/759940 (Xena) Credits ~~~~~~~ - Samuel de Medeiros Queiroz from Oi Cloud (CVE-2021-38155) References ~~~~~~~~~~ - https://launchpad.net/bugs/1688137 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-38155 -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From kkchn.in at gmail.com Tue Aug 10 08:53:15 2021 From: kkchn.in at gmail.com (KK CHN) Date: Tue, 10 Aug 2021 14:23:15 +0530 Subject: WIndows VMs exporting toe KVM hosts : Once KVM host fails to boot the VM In-Reply-To: References: Message-ID: /var/log/libvirt/qemu/WindowsMyVMName.og output here in the attached screenshot On Tue, Aug 10, 2021 at 1:24 PM KK CHN wrote: > I am migrating one Windows 12 VM from oVirt hypervisor. The Windows > image is a single disk images. > > I have two KVM hosts running .. I am successfully able to import the > VM to one of our KVM host. Windows VM is up and running able to login to > the Desktop environment. > > But the same VM image I am trying in the second KVM host to launch it, its > not booting > > Booting from Hard disk ...... / Its wait in this state for a long ( 20 > minutes ) . > > I tried to delete and create the VM again in the second KVM host, its > reaching > to Booting from Hard disk .... // No progress after this.. > > Any suggestions for troubleshooting? . > > Does I have to execute any utilities and its out put required for trouble > shooting let me know. > > Kris > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot from 2021-08-10 14-18-41.png Type: image/png Size: 182933 bytes Desc: not available URL: From xxxcloudlearner at gmail.com Tue Aug 10 09:29:01 2021 From: xxxcloudlearner at gmail.com (cloud learner) Date: Tue, 10 Aug 2021 14:59:01 +0530 Subject: Unable to retrieve flavor details and unable to retrieve instance details Message-ID: Dear Experts, I have deployed victoria with controller+compute, and 2 extra compute using packstack. Everything is working fine but many times it shows the error as mentioned in the subject line. The log files of nova are attached herewith. Kindly help -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: nova-conductor.log Type: application/octet-stream Size: 6822514 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: nova-compute.log Type: application/octet-stream Size: 7768583 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: nova-api.log Type: application/octet-stream Size: 9107883 bytes Desc: not available URL: From chris at lyonsgroup.family Tue Aug 10 12:31:13 2021 From: chris at lyonsgroup.family (Chris Lyons) Date: Tue, 10 Aug 2021 12:31:13 +0000 Subject: Octavia In-Reply-To: <3088a3b9-f683-3117-9e67-eec1fb74c3eb@gmail.com> References: <26e5229a-0584-c5f5-e85f-6547b158dc47@gmail.com> , <3088a3b9-f683-3117-9e67-eec1fb74c3eb@gmail.com> Message-ID: Thank you! I am trying the path of adding a separate physical (although its really virtual..) network that will be exclusively for lb-mgmt….that would work also, correct? I added a port to my virtual router and the added a corresponding port to each openstack vm. It sounds like only control and compute nodes need it but I was going to add it to everything to start and then eliminate one by one once it worked. Would that approach also work? From: Bernd Bausch Date: Tuesday, August 10, 2021 at 2:39 AM To: Chris Lyons , openstack-discuss at lists.openstack.org Subject: Re: Octavia The stacktrace shows that Octavia can't reach an Amphora. I suppose you get this log when trying to create a loadbalancer? If so, most likely the Amphora management network is not set up correctly. The difficulty is that Octavia workers, which are processes running on the controllers, need to have access to the same management network as the Amphora instances. If you implement the management network as a normal tenant network, some non-trivial manual Openvswitch configuration is required. See https://docs.openstack.org/octavia/latest/install/install-ubuntu.html#install-and-configure-components for instructions. In production settings, usually a VLAN is used, which is easy to access from controller processes. I succeeded running Octavia on a Kolla cluster with three-way controllers, with a tenant network (VXLAN-based) for amphora management. My notes are attached (they are tailored to my configuration, of course). Bernd. On 2021/08/09 10:57 AM, Chris Lyons wrote: Well…it gets. A lot further…. I see this error now…. Im looking around to see if it’s a security group missing or if there is some other setting I missed. Im not seeing any scripts to prep the env…usually there is something like that if it’s a security group…anyone know? ... 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker Traceback (most recent call last): 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker File "/usr/lib/python3.6/site-packages/taskflow/engines/action_engine/executor.py", line 53, in _execute_task 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker result = task.execute(**arguments) 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker File "/usr/lib/python3.6/site-packages/octavia/controller/worker/v1/tasks/amphora_driver_tasks.py", line 424, in execute 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker amp_info = self.amphora_driver.get_info(amphora) 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker File "/usr/lib/python3.6/site-packages/octavia/amphorae/drivers/haproxy/rest_api_driver.py", line 373, in get_info 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker amphora, raise_retry_exception=raise_retry_exception) 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker File "/usr/lib/python3.6/site-packages/octavia/amphorae/drivers/haproxy/rest_api_driver.py", line 106, in _populate_amphora_api_version 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker raise_retry_exception=raise_retry_exception)['api_version'] 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker File "/usr/lib/python3.6/site-packages/octavia/amphorae/drivers/haproxy/rest_api_driver.py", line 744, in get_api_version 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker raise_retry_exception=raise_retry_exception) 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker File "/usr/lib/python3.6/site-packages/octavia/amphorae/drivers/haproxy/rest_api_driver.py", line 738, in request 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker raise driver_except.TimeOutException() 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker octavia.amphorae.driver_exceptions.exceptions.TimeOutException: contacting the amphora timed out ... This email has been scanned by Inbound Shield™. -------------- next part -------------- An HTML attachment was scrubbed... URL: From helena at openstack.org Tue Aug 10 20:33:17 2021 From: helena at openstack.org (helena at openstack.org) Date: Tue, 10 Aug 2021 15:33:17 -0500 (CDT) Subject: [all][elections][ptl][tc] Combined PTL/TC Election Season Message-ID: <1628627597.961916865@apps.rackspace.com> Election details: [ https://governance.openstack.org/election/ ]( https://governance.openstack.org/election/ ) Hello everyone! The nomination period officially begins August 17, 2021 23:45. Please read the stipulations and timelines for candidates and electorate contained in this governance documentation. The PTL and TC elections for the coming cycle will run concurrently; deadlines for their nomination and voting activities are synchronized but will still use separate ballots. Please note, if only one candidate is nominated as PTL for a project team during the PTL nomination period, that candidate will win by acclaim, and there will be no poll. There will only be a poll if there is more than one candidate stepping forward for a project team's PTL position. If teams do not produce any PTL candidate during the nomination period, or are interested in considering alternatives prior to nominations, the TC may consider requests to switch to the new distributed leadership model they recently documented[1]. In keeping with the established plan[1 ] to gradually reduce the size of the Technical Committee, we will only fill four (4) seats in this coming election. There will be further announcements posted to the mailing list as action is required from the electorate or candidates. This email is for information purposes only. If you have any questions which you feel affect others please reply to this email thread. If you have any questions that you which to discuss in private please email any of the election officials[3] so that we may address your concerns. [1] [ https://governance.openstack.org/tc/resolutions/20200803-distributed-project-leadership.html ]( https://governance.openstack.org/tc/resolutions/20200803-distributed-project-leadership.html ) [2] [ https://governance.openstack.org/tc/reference/charter.html#number-of-seats-to-elect ]( https://governance.openstack.org/tc/reference/charter.html#number-of-seats-to-elect ) [3] [ https://governance.openstack.org/election/#election-officials ]( https://governance.openstack.org/election/#election-officials ) Cheers, Helena on behalf of the OpenStack Technical Election Officials -------------- next part -------------- An HTML attachment was scrubbed... URL: From moshele at nvidia.com Tue Aug 10 20:38:39 2021 From: moshele at nvidia.com (Moshe Levi) Date: Tue, 10 Aug 2021 20:38:39 +0000 Subject: [neutron][ovn] support for stateless NAT for floating ip in ml2 ovn Message-ID: Hi all, OVN support stateless NAT operations [1] for use case of 1:1 mapped between inner and external ips, i.e dnat_and_snat rule. In openstack is the floating ip use-case. Looking on ml2 ovn support it seem that it only support floating ip with connection tracking. Can ml2 ovn support also the stateless NAT option? Is there concerns using stateless NAT? [1] - https://patchwork.ozlabs.org/project/openvswitch/cover/1570154179-14525-1-git-send-email-ankur.sharma at nutanix.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.matulis at canonical.com Wed Aug 11 00:00:04 2021 From: peter.matulis at canonical.com (Peter Matulis) Date: Tue, 10 Aug 2021 20:00:04 -0400 Subject: [docs] Double headings on every page In-Reply-To: References: Message-ID: I'm now seeing this symptom on several projects in the 'latest' release branch. Such as: https://docs.openstack.org/nova/latest/ My browser exposes the following error: [image: image.png] We patched [1] our project as a workaround. Could one of Stephen's commits [2] be involved? [1]: https://review.opendev.org/c/openstack/charm-deployment-guide/+/803531 [2]: https://opendev.org/openstack/openstackdocstheme/commit/08461c5311aa692088a27eb40a87965fd8515aba On Thu, Jun 10, 2021 at 3:51 PM Peter Matulis wrote: > Hi Stephen. Did you ever get to circle back to this? > > On Fri, May 14, 2021 at 7:34 AM Stephen Finucane > wrote: > >> On Tue, 2021-05-11 at 11:14 -0400, Peter Matulis wrote: >> >> Hi, I'm hitting an oddity in one of my projects where the titles of all >> pages show up twice. >> >> Example: >> >> >> https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/wallaby/app-nova-cells.html >> >> Source file is here: >> >> >> https://opendev.org/openstack/charm-deployment-guide/src/branch/master/deploy-guide/source/app-nova-cells.rst >> >> Does anyone see what can be causing this? It appears to happen only for >> the current stable release ('wallaby') and 'latest'. >> >> Thanks, >> Peter >> >> >> I suspect you're bumping into issues introduced by a new version of >> Sphinx or docutils (new versions of both were released recently). >> >> Comparing the current nova docs [1] to what you have, I see the duplicate >>

element is present but hidden by the following CSS rule: >> >> .docs-body .section h1 { >> >> display: none; >> >> } >> >> >> That works because we have the following HTML in the nova docs: >> >>
>> >>

Extra Specs

>> >> ... >> >>
>> >> >> while the docs you linked are using the HTML5 semantic '
' tag: >> >>
>> >>

Nova Cells

>> >> ... >> >>
>> >> >> So to fix this, we'll have to update the openstackdocstheme to handle >> these changes. I can try to take a look at this next week but I really >> wouldn't mind if someone beat me to it. >> >> Stephen >> >> [1] https://docs.openstack.org/nova/latest/configuration/extra-specs.html >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 7527 bytes Desc: not available URL: From shnmnr at gmail.com Wed Aug 11 01:30:19 2021 From: shnmnr at gmail.com (Shane Miner) Date: Tue, 10 Aug 2021 21:30:19 -0400 Subject: Octavia In-Reply-To: References: <26e5229a-0584-c5f5-e85f-6547b158dc47@gmail.com> Message-ID: On Mon, Aug 9, 2021, 11:27 AM Chris Lyons wrote: > Well…it gets. A lot further…. I see this error now…. Im looking around to > see if it’s a security group missing or if there is some other setting I > missed. Im not seeing any scripts to prep the env…usually there is > something like that if it’s a security group…anyone know? > > > > |__Atom > 'STANDALONE-octavia-create-amp-for-lb-subflow-octavia-create-amphora-indb' > {'intention': 'EXECUTE', 'state': 'SUCCESS', 'requires': > {'loadbalancer_id': '5b4598ee-d055-40c4-997d-ea41009d819e'}, 'provides': > 'b6a7018d-d436-477b-8aad-b1b53b1e6cde'} > > |__Flow > 'STANDALONE-octavia-create-amp-for-lb-subflow' > > |__Atom > 'STANDALONE-octavia-get-amphora-for-lb-subflow-octavia-mapload-balancer-to-amphora' > {'intention': 'EXECUTE', 'state': 'SUCCESS', 'requires': > {'loadbalancer_id': '5b4598ee-d055-40c4-997d-ea41009d819e', 'flavor': {}, > 'availability_zone': {}, 'server_group_id': None}, 'provides': None} > > |__Flow > 'STANDALONE-octavia-get-amphora-for-lb-subflow' > > |__Atom > 'octavia.controller.worker.v1.tasks.network_tasks.GetSubnetFromVIP' > {'intention': 'EXECUTE', 'state': 'SUCCESS', 'requires': {'loadbalancer': > }, > 'provides': } > > |__Atom > 'octavia.controller.worker.v1.tasks.network_tasks.UpdateVIPSecurityGroup' > {'intention': 'EXECUTE', 'state': 'SUCCESS', 'requires': > {'loadbalancer_id': '5b4598ee-d055-40c4-997d-ea41009d819e'}, 'provides': > '3512c022-9189-4709-be49-46555d7ce8c6'} > > |__Atom > 'octavia.controller.worker.v1.tasks.database_tasks.UpdateVIPAfterAllocation' > {'intention': 'EXECUTE', 'state': 'SUCCESS', 'requires': > {'loadbalancer_id': '5b4598ee-d055-40c4-997d-ea41009d819e', 'vip': > }, 'provides': > } > > |__Atom > 'octavia.controller.worker.v1.tasks.network_tasks.AllocateVIP' > {'intention': 'EXECUTE', 'state': 'SUCCESS', 'requires': {'loadbalancer': > }, > 'provides': } > > |__Atom > 'reload-lb-before-allocate-vip' {'intention': 'EXECUTE', 'state': > 'SUCCESS', 'requires': {'loadbalancer_id': > '5b4598ee-d055-40c4-997d-ea41009d819e'}, 'provides': > } > > |__Atom > 'octavia.controller.worker.v1.tasks.lifecycle_tasks.LoadBalancerIDToErrorOnRevertTask' > {'intention': 'EXECUTE', 'state': 'SUCCESS', 'requires': > {'loadbalancer_id': '5b4598ee-d055-40c4-997d-ea41009d819e'}, 'provides': > None} > > |__Flow > 'octavia-create-loadbalancer-flow': > octavia.amphorae.driver_exceptions.exceptions.TimeOutException: contacting > the amphora timed out > > 2021-08-08 21:22:35.965 27 ERROR > octavia.controller.worker.v1.controller_worker Traceback (most recent call > last): > > 2021-08-08 21:22:35.965 27 ERROR > octavia.controller.worker.v1.controller_worker File > "/usr/lib/python3.6/site-packages/taskflow/engines/action_engine/executor.py", > line 53, in _execute_task > > 2021-08-08 21:22:35.965 27 ERROR > octavia.controller.worker.v1.controller_worker result = > task.execute(**arguments) > > 2021-08-08 21:22:35.965 27 ERROR > octavia.controller.worker.v1.controller_worker File > "/usr/lib/python3.6/site-packages/octavia/controller/worker/v1/tasks/amphora_driver_tasks.py", > line 424, in execute > > 2021-08-08 21:22:35.965 27 ERROR > octavia.controller.worker.v1.controller_worker amp_info = > self.amphora_driver.get_info(amphora) > > 2021-08-08 21:22:35.965 27 ERROR > octavia.controller.worker.v1.controller_worker File > "/usr/lib/python3.6/site-packages/octavia/amphorae/drivers/haproxy/rest_api_driver.py", > line 373, in get_info > > 2021-08-08 21:22:35.965 27 ERROR > octavia.controller.worker.v1.controller_worker amphora, > raise_retry_exception=raise_retry_exception) > > 2021-08-08 21:22:35.965 27 ERROR > octavia.controller.worker.v1.controller_worker File > "/usr/lib/python3.6/site-packages/octavia/amphorae/drivers/haproxy/rest_api_driver.py", > line 106, in _populate_amphora_api_version > > 2021-08-08 21:22:35.965 27 ERROR > octavia.controller.worker.v1.controller_worker > raise_retry_exception=raise_retry_exception)['api_version'] > > 2021-08-08 21:22:35.965 27 ERROR > octavia.controller.worker.v1.controller_worker File > "/usr/lib/python3.6/site-packages/octavia/amphorae/drivers/haproxy/rest_api_driver.py", > line 744, in get_api_version > > 2021-08-08 21:22:35.965 27 ERROR > octavia.controller.worker.v1.controller_worker > raise_retry_exception=raise_retry_exception) > > 2021-08-08 21:22:35.965 27 ERROR > octavia.controller.worker.v1.controller_worker File > "/usr/lib/python3.6/site-packages/octavia/amphorae/drivers/haproxy/rest_api_driver.py", > line 738, in request > > 2021-08-08 21:22:35.965 27 ERROR > octavia.controller.worker.v1.controller_worker raise > driver_except.TimeOutException() > > 2021-08-08 21:22:35.965 27 ERROR > octavia.controller.worker.v1.controller_worker > octavia.amphorae.driver_exceptions.exceptions.TimeOutException: contacting > the amphora timed out > > 2021-08-08 21:22:35.965 27 ERROR > octavia.controller.worker.v1.controller_worker > > 2021-08-08 21:22:35.995 27 WARNING > octavia.controller.worker.v1.controller_worker [-] Task > 'STANDALONE-octavia-create-amp-for-lb-subflow-octavia-amp-compute-connectivity-wait' > (7f8c1119-9020-4fb8-ae98-1495875a3dc2) transitioned into state 'REVERTED' > from state 'REVERTING' > > 2021-08-08 21:22:36.003 27 WARNING > octavia.controller.worker.v1.controller_worker [-] Task > 'STANDALONE-octavia-create-amp-for-lb-subflow-octavia-update-amphora-info' > (ca7b4681-3fe6-4834-b7ee-2fb2dbe01c3c) transitioned into state 'REVERTED' > from state 'REVERTING' > > 2021-08-08 21:22:36.011 27 WARNING > octavia.controller.worker.v1.controller_worker [-] Task > 'STANDALONE-octavia-create-amp-for-lb-subflow-octavia-compute-wait' > (2ef36bd4-15be-468f-9a8c-f6b60728da6c) transitioned into state 'REVERTED' > from state 'REVERTING' > > 2021-08-08 21:22:36.017 27 WARNING > octavia.controller.worker.v1.tasks.database_tasks [-] Reverting mark > amphora booting in DB for amp id b6a7018d-d436-477b-8aad-b1b53b1e6cde and > compute id c93393df-a39a-486e-812d-73652209fcff > > 2021-08-08 21:22:36.049 27 WARNING > octavia.controller.worker.v1.controller_worker [-] Task > 'STANDALONE-octavia-create-amp-for-lb-subflow-octavia-mark-amphora-booting-indb' > (6aac42e0-fe77-43b8-9323-e0f79304d9d6) transitioned into state 'REVERTED' > from state 'REVERTING' > > 2021-08-08 21:22:36.056 27 WARNING > octavia.controller.worker.v1.controller_worker [-] Task > 'STANDALONE-octavia-create-amp-for-lb-subflow-octavia-update-amphora-computeid' > (592da2b6-ab90-4292-a854-c6e2a679dabf) transitioned into state 'REVERTED' > from state 'REVERTING' > > 2021-08-08 21:22:36.061 27 WARNING > octavia.controller.worker.v1.tasks.compute_tasks [-] Reverting compute > create for amphora with id b6a7018d-d436-477b-8aad-b1b53b1e6cde and compute > id: c93393df-a39a-486e-812d-73652209fcff > > 2021-08-08 21:22:36.576 27 WARNING > octavia.controller.worker.v1.controller_worker [-] Task > 'STANDALONE-octavia-create-amp-for-lb-subflow-octavia-cert-compute-create' > (59401bf8-9191-4ac1-b4f3-b551a139df9d) transitioned into state 'REVERTED' > from state 'REVERTING' > > 2021-08-08 21:22:36.582 27 WARNING > octavia.controller.worker.v1.controller_worker [-] Task > 'STANDALONE-octavia-create-amp-for-lb-subflow-octavia-update-cert-expiration' > (9e731d93-8cb8-46cb-9be4-073e1579a5f8) transitioned into state 'REVERTED' > from state 'REVERTING' > > > > > > > > *From: *Chris Lyons > *Date: *Sunday, August 8, 2021 at 8:56 PM > *To: *Bernd Bausch , > openstack-discuss at lists.openstack.org < > openstack-discuss at lists.openstack.org> > *Subject: *Re: Octavia > > I think I might have solved it. It looks like during the kolla install a > “Octavia-openrc.sh” script is created which sets up the env to use an > account called “service”. After running that and re-uploading the amphora > image I am now able to see amphora instances get created. Thank you Bernd > for the suggestion that you gve! It caused me to look around in the > permissions area and found the solution! > > > > *From: *Bernd Bausch > *Date: *Friday, August 6, 2021 at 8:21 PM > *To: *openstack-discuss at lists.openstack.org < > openstack-discuss at lists.openstack.org>, Chris Lyons > > *Subject: *Re: Octavia > > I had that problem when setting up a Victoria Kolla cluster, and it turned > out that the image was owned by the wrong project, as suspected by Michael. > I changed the owner in Glance, and it worked. The owner must be 4269b3cd5452416e8153f5b4f5adcf0c > in Chris' case (openstack image set --project > 4269b3cd5452416e8153f5b4f5adcf0c amphora-image-name). > > I don't think this is a Kolla problem, as Kolla leaves the responsibility > of building and uploading the image to the administrator (or it did so at > Victoria). > > Bernd Bausch > > On 2021/08/06 11:07 PM, Chris Lyons wrote: > > Both of those appear ok…. I do have the amphora image set to public and I > see this in the Octavia.conf file: > > > > > > [controller_worker] > > amp_ssh_key_name = octavia_ssh_key > > amp_image_tag = amphora > > amp_image_owner_id = 4269b3cd5452416e8153f5b4f5adcf0c > > amp_boot_network_list = adfa01a9-55bd-42ea-b849-81060d5d7c09 > > amp_secgroup_list = ecf269e2-42fc-477b-9ce1-38d60c1d8d5d > > amp_flavor_id = c854d1e7-885f-4f7a-88a3-79728b561830 > > client_ca = /etc/octavia/certs/client_ca.cert.pem > > network_driver = allowed_address_pairs_driver > > compute_driver = compute_nova_driver > > amphora_driver = amphora_haproxy_rest_driver > > amp_active_retries = 100 > > amp_active_wait_sec = 2 > > loadbalancer_topology = SINGLE > > > > > > > > *From: *Michael Johnson > *Date: *Friday, August 6, 2021 at 10:04 AM > *To: *Chris Lyons > *Cc: *openstack-discuss at lists.openstack.org > > > *Subject: *Re: Octavia > > This is a kolla bug most likely. > > This could be caused by a few possible issues in kolla: > > 1. The images are owned by the wrong project. Kolla may deploy > Octavia under a special service project. The image kolla uploads to > glance must be uploaded under the service project as owner. A simple > test to see if this is the issue would be to set the image as "public" > such that all users of the cloud can see it. If a load balancer can be > created after that change, the images are loaded under a project that > Octavia cannot access. > 2. The other possibility is kolla configured an alternate tag name. > Check the [controller_worker] amp_image_tag setting [1] in > octavia.conf. The images must be tagged with the same name as is > configured in the octavia.conf for the controllers. > > Let us know either way (and ideally open a bug for kolla) what you find > out. > > Michael > > [1] > https://docs.openstack.org/octavia/latest/configuration/configref.html#controller_worker.amp_image_tag > > On Fri, Aug 6, 2021 at 5:52 AM Chris Lyons > wrote: > > > > Octavia group, > > > > > > > > I created this story to see if I could get some assistance on an Octavia > issue I am having with my infra. I did a vanilla install of Openstack > Wallaby using the Kolla project with Octavia enabled and auto-configure > set. Everything appeared to install fine. When I try to create a load > balancer using the horizon console or the cli or through further installs > such as cloudfoundry that require a loadbalancer, I get an error from > glance about “No image found with tag amphora” even though the image does > exist. I hope it is something simple or an oversight on my part. Could I > get some ideas or places to look? > > > > > > > > Story: > > > > > > > > https://storyboard.openstack.org/#!/story/2009103 > > > > > > > > Kolla install followed: > > > > > > > > > https://docs.openstack.org/kolla-ansible/latest/reference/networking/octavia.html > > > > > > > > cli output : > > > > > > > > [root at kolla ~]# openstack image list --tag amphora > > > > +--------------------------------------+---------------------+--------+ > > > > | ID | Name | Status | > > > > +--------------------------------------+---------------------+--------+ > > > > | 8f7398e7-7912-43b8-8131-e90f21c91ab4 | amphora | active | > > > > | 9bf14389-8521-4fb7-a7db-925f4dea1bf3 | amphora-x64-haproxy | active | > > > > +--------------------------------------+---------------------+--------+ > > > > [root at kolla ~]# > > > > > > > > My Infra scripts (relevant): > > > > > > > > > https://github.com/mephmanx/openstack-scripts/blob/32363ef5753fdec381f713c747c90a5c14b3ae72/kolla.sh#L340 > > > > > > > > > > > > I am admin of said infra so if anyone has time or availability (or > interest) to log in and take a look I would be happy to provide creds. > > > > > > > > Thank you for any time that you could provide or offer! > > > > This email has been scanned by Inbound Shield™. > > > *This email has been scanned by Inbound Shield™.* > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From berndbausch at gmail.com Wed Aug 11 01:38:05 2021 From: berndbausch at gmail.com (Bernd Bausch) Date: Wed, 11 Aug 2021 10:38:05 +0900 Subject: Octavia In-Reply-To: References: <26e5229a-0584-c5f5-e85f-6547b158dc47@gmail.com> <3088a3b9-f683-3117-9e67-eec1fb74c3eb@gmail.com> Message-ID: <76217647-3770-4f56-d9ca-c0ec05899749@gmail.com> A flat network for LB management should work as well. However, the LB management network has nothing to do with your VMs (except the amphorae), and it's unclear to me what ports you are adding to them and the Neutron router. There is no router for a flat network. You seem to imply that your machines (controllers, computes) are virtual. My experience with Kolla is also in a virtual environment. I had to abandon VLAN or flat LB management networks because I was not competent enough to solve the networking problems outside of Kolla and went for the tenant network solution that I shared. Bernd On 2021/08/10 9:31 PM, Chris Lyons wrote: > > Thank you!  I am trying the path of adding a separate physical > (although its really virtual..) network that will be exclusively for > lb-mgmt….that would work also, correct?  I added a port to my virtual > router and the added a corresponding port to each openstack vm.  It > sounds like only control and compute nodes need it but I was going to > add it to everything to start and then eliminate one by one once it > worked. > > Would that approach also work? > > *From: *Bernd Bausch > *Date: *Tuesday, August 10, 2021 at 2:39 AM > *To: *Chris Lyons , > openstack-discuss at lists.openstack.org > > *Subject: *Re: Octavia > > The stacktrace shows that Octavia can't reach an Amphora. I suppose > you get this log when trying to create a loadbalancer? If so, most > likely the Amphora management network is not set up correctly. > > The difficulty is that Octavia workers, which are /processes /running > on the controllers, need to have access to the same management network > as the Amphora /instances/. If you implement the management network as > a normal tenant network, some non-trivial manual Openvswitch > configuration is required. See > https://docs.openstack.org/octavia/latest/install/install-ubuntu.html#install-and-configure-components > > for instructions. In production settings, usually a VLAN is used, > which is easy to access from controller processes. > > I succeeded running Octavia on a Kolla cluster with three-way > controllers, with a tenant network (VXLAN-based) for amphora > management. My notes are attached (they are tailored to my > configuration, of course). > > Bernd. > > On 2021/08/09 10:57 AM, Chris Lyons wrote: > > Well…it gets. A lot further….  I see this error now…. Im looking > around to see if it’s a security group missing or if there is some > other setting I missed.  Im not seeing any scripts to prep the > env…usually there is something like that if it’s a security > group…anyone know? > > ... > > 2021-08-08 21:22:35.965 27 ERROR > octavia.controller.worker.v1.controller_worker Traceback (most recent > call last): > > 2021-08-08 21:22:35.965 27 ERROR > octavia.controller.worker.v1.controller_worker   File > "/usr/lib/python3.6/site-packages/taskflow/engines/action_engine/executor.py", > line 53, in _execute_task > > 2021-08-08 21:22:35.965 27 ERROR > octavia.controller.worker.v1.controller_worker     result = > task.execute(**arguments) > > 2021-08-08 21:22:35.965 27 ERROR > octavia.controller.worker.v1.controller_worker   File > "/usr/lib/python3.6/site-packages/octavia/controller/worker/v1/tasks/amphora_driver_tasks.py", > line 424, in execute > > 2021-08-08 21:22:35.965 27 ERROR > octavia.controller.worker.v1.controller_worker     amp_info = > self.amphora_driver.get_info(amphora) > > 2021-08-08 21:22:35.965 27 ERROR > octavia.controller.worker.v1.controller_worker   File > "/usr/lib/python3.6/site-packages/octavia/amphorae/drivers/haproxy/rest_api_driver.py", > line 373, in get_info > > 2021-08-08 21:22:35.965 27 ERROR > octavia.controller.worker.v1.controller_worker     amphora, > raise_retry_exception=raise_retry_exception) > > 2021-08-08 21:22:35.965 27 ERROR > octavia.controller.worker.v1.controller_worker   File > "/usr/lib/python3.6/site-packages/octavia/amphorae/drivers/haproxy/rest_api_driver.py", > line 106, in _populate_amphora_api_version > > 2021-08-08 21:22:35.965 27 ERROR > octavia.controller.worker.v1.controller_worker > raise_retry_exception=raise_retry_exception)['api_version'] > > 2021-08-08 21:22:35.965 27 ERROR > octavia.controller.worker.v1.controller_worker   File > "/usr/lib/python3.6/site-packages/octavia/amphorae/drivers/haproxy/rest_api_driver.py", > line 744, in get_api_version > > 2021-08-08 21:22:35.965 27 ERROR > octavia.controller.worker.v1.controller_worker > raise_retry_exception=raise_retry_exception) > > 2021-08-08 21:22:35.965 27 ERROR > octavia.controller.worker.v1.controller_worker   File > "/usr/lib/python3.6/site-packages/octavia/amphorae/drivers/haproxy/rest_api_driver.py", > line 738, in request > > 2021-08-08 21:22:35.965 27 ERROR > octavia.controller.worker.v1.controller_worker     raise > driver_except.TimeOutException() > > 2021-08-08 21:22:35.965 27 ERROR > octavia.controller.worker.v1.controller_worker > octavia.amphorae.driver_exceptions.exceptions.TimeOutException: > contacting the amphora timed out > > ... > > > > > /This email has been scanned by Inbound Shield™./ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonyppe at gmail.com Wed Aug 11 07:04:12 2021 From: tonyppe at gmail.com (Tony Pearce) Date: Wed, 11 Aug 2021 15:04:12 +0800 Subject: [magnum] [kolla-ansible] [kayobe] [Victoria] Magnum Kubernetes cluster failure recovery In-Reply-To: References: Message-ID: I sent this mail last week looking for some insight with regards to a magnum issue we had. I hadnt seen any reply and searched for my sent mail - I found I did not complete the subject line. Sorry about that. Resending again here with a subject. If anyone has any insight to this I'd be grateful to hear from you. Kind regards, Tony Pearce ---------- Forwarded message --------- From: Tony Pearce Date: Thu, 5 Aug 2021 at 14:22 Subject: [magnum] [kolla-ansible] [kayobe] [Victoria] To: OpenStack Discuss Testing out Kubernetes with Magnum project, deployed via kayobe on Victoria we have deployed an auto scaling cluster and have run into a problem and I'm not sure how to proceed. I understand that the cluster tried to scale up but the openstack project did not have enough CPU resources to accommodate it (error= Quota exceeded for cores: Requested 4, but already used 20 of 20 cores). So the situation is that the cluster shows "healthy" and "UPDATE_FAILED" but also kubectl commands are failing [1]. What is required to return the cluster back to a working status at this point? I have tried: - cluster resize to reduce number of workers - cluster resize to increase number of workers after increasing project quota - cluster resize and maintaining the same number of workers When trying any of the above, horizon shows an immediate error "Unable to resize given cluster" but magnum logs and heat logs do not show any log update at all at that time. - using "check stack" and resume stack in the stack horizon menu gives this error [2] Investigating the kubectl issue, it was noted that some services had failed on the master node [3]. Manual start as well as reboot the node did not bring up the services. Unfortunately I dont have ssh access to the master and no further information has been forthcoming with regards to logs for those service failures so I am unable to provide anything around that here. I found this link [4] so I decided to delete the master node then run "check" cluster again but the check cluster just fails in the same way except this time it fails saying that it cannot find the master [5] while the previous error was that it could not find a node. Ideally I would prefer to recover the cluster - whether this is still possible I am unsure. I can probably recreate this scenario again. What steps should be performed in this case to restore the cluster? [1] kubectl get no Error from server (Timeout): the server was unable to return a response in the time allotted, but may still be processing the request (get nodes) [2] Resource CHECK failed: ["['NotFound: resources[4].resources.kube-minion: Instance None could not be found. (HTTP 404) (Request-ID: req-6069ff6a-9eb6-4bce-bb25-4ef001ebc428)']. 'CHECK' not fully supported (see resources)"] [3] [systemd] Failed Units: 3 etcd.service heat-container-agent.service logrotate.service [4] https://bugzilla.redhat.com/show_bug.cgi?id=1459854 [5] ["['NotFound: resources.kube_masters.resources[0].resources.kube-master: Instance c6185e8e-1a98-4925-959b-0a56210b8c9e could not be found. (HTTP 404) (Request-ID: req-bdfcc853-7dbb-4022-9208-68b1ab31008a)']. 'CHECK' not fully supported (see resources)"]. Kind regards, Tony Pearce -------------- next part -------------- An HTML attachment was scrubbed... URL: From S.Kieske at mittwald.de Wed Aug 11 10:16:33 2021 From: S.Kieske at mittwald.de (Sven Kieske) Date: Wed, 11 Aug 2021 10:16:33 +0000 Subject: [magnum] [kolla-ansible] [kayobe] [Victoria] Magnum Kubernetes cluster failure recovery In-Reply-To: References: Message-ID: Hi Tony, we don't run victoria release but maybe I can give you some pointers where to look: as far as I understand Magnum and the kubernetes autoscaler, magnum uses heat to create stacks for the initial kubernetes deployment. the problem is, that the kubernetes autoscaler directly talks to the openstack api, e.g. nova for creating and destroying instances. This can result in some weird situations, e.g. the autoscaler deletes volumes but heat never is involved, so heat still thinks a volume is there which isn't. so you might want to check all resources in your magnum heat stacks, if they are really there, or if autoscaler did things to them. if you e.g. find resources deleted by autoscaler, mark the appropriate heat stack as unhealthy and trigger a stack update, so heat can do it's thing. the stack should then return in a healthy status. if someone has a solution to this general problem, I would be very interested (beside the obvious "solution" to just disable the autoscaler)! HTH Sven On Mi, 2021-08-11 at 15:04 +0800, Tony Pearce wrote: > I sent this mail last week looking for some insight with regards to a > magnum issue we had. I hadnt seen any reply and searched for my sent mail - > I found I did not complete the subject line. Sorry about that. > > Resending again here with a subject. If anyone has any insight to this I'd > be grateful to hear from you. > > Kind regards, > > Tony Pearce > > > > > ---------- Forwarded message --------- > From: Tony Pearce > Date: Thu, 5 Aug 2021 at 14:22 > Subject: [magnum] [kolla-ansible] [kayobe] [Victoria] > To: OpenStack Discuss > > > Testing out Kubernetes with Magnum project, deployed via kayobe on Victoria > we have deployed an auto scaling cluster and have run into a problem and > I'm not sure how to proceed. I understand that the cluster tried to scale > up but the openstack project did not have enough CPU resources to > accommodate it (error= Quota exceeded for cores: Requested 4, but already > used 20 of 20 cores). > > So the situation is that the cluster shows "healthy" and "UPDATE_FAILED" > but also kubectl commands are failing [1]. > > What is required to return the cluster back to a working status at this > point? I have tried: > - cluster resize to reduce number of workers > - cluster resize to increase number of workers after increasing project > quota > - cluster resize and maintaining the same number of workers > > When trying any of the above, horizon shows an immediate error "Unable to > resize given cluster" but magnum logs and heat logs do not show any log > update at all at that time. > > - using "check stack" and resume stack in the stack horizon menu gives this > error [2] > > Investigating the kubectl issue, it was noted that some services had failed > on the master node [3]. Manual start as well as reboot the node did not > bring up the services. Unfortunately I dont have ssh access to the master > and no further information has been forthcoming with regards to logs for > those service failures so I am unable to provide anything around that here. > > I found this link [4] so I decided to delete the master node then run > "check" cluster again but the check cluster just fails in the same way > except this time it fails saying that it cannot find the master [5] while > the previous error was that it could not find a node. > > Ideally I would prefer to recover the cluster - whether this is still > possible I am unsure. I can probably recreate this scenario again. What > steps should be performed in this case to restore the cluster? > > > > [1] > kubectl get no > Error from server (Timeout): the server was unable to return a response in > the time allotted, but may still be processing the request (get nodes) > > [2] > Resource CHECK failed: ["['NotFound: resources[4].resources.kube-minion: > Instance None could not be found. (HTTP 404) (Request-ID: > req-6069ff6a-9eb6-4bce-bb25-4ef001ebc428)']. 'CHECK' not fully supported > (see resources)"] > > [3] > > [systemd] > Failed Units: 3 >   etcd.service >   heat-container-agent.service >   logrotate.service > > [4] https://bugzilla.redhat.com/show_bug.cgi?id=1459854 > > [5] > > ["['NotFound: resources.kube_masters.resources[0].resources.kube-master: > Instance c6185e8e-1a98-4925-959b-0a56210b8c9e could not be found. (HTTP > 404) (Request-ID: req-bdfcc853-7dbb-4022-9208-68b1ab31008a)']. 'CHECK' not > fully supported (see resources)"]. > > Kind regards, > > Tony Pearce -- Mit freundlichen Grüßen / Regards Sven Kieske Systementwickler     Mittwald CM Service GmbH & Co. KG Königsberger Straße 4-6 32339 Espelkamp   Tel.: 05772 / 293-900 Fax: 05772 / 293-333   https://www.mittwald.de   Geschäftsführer: Robert Meyer, Florian Jürgens   St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen Informationen zur Datenverarbeitung im Rahmen unserer Geschäftstätigkeit  gemäß Art. 13-14 DSGVO sind unter www.mittwald.de/ds abrufbar. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From S.Kieske at mittwald.de Wed Aug 11 10:25:14 2021 From: S.Kieske at mittwald.de (Sven Kieske) Date: Wed, 11 Aug 2021 10:25:14 +0000 Subject: [magnum] [kolla-ansible] [kayobe] [Victoria] Magnum Kubernetes cluster failure recovery In-Reply-To: References: Message-ID: <85bd5e9e6b4c8e0a60f51f9fd32e170a1d4064ec.camel@mittwald.de> On Mi, 2021-08-11 at 10:16 +0000, Sven Kieske wrote: > the problem is, that the kubernetes autoscaler directly talks to the openstack api, e.g. > nova for creating and destroying instances. Nevermind I got that wrong. The autoscaler talks to heat, so there should no problem (but heat trips itself up on some error conditions). I was in fact talking about the magnum auto healer (https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/magnum-auto-healer/using-magnum-auto-healer.md ) which seems to circumvent heat and talks directly with nova. Are you using the magnum auto healing feature by chance? HTH -- Mit freundlichen Grüßen / Regards Sven Kieske Systementwickler     Mittwald CM Service GmbH & Co. KG Königsberger Straße 4-6 32339 Espelkamp   Tel.: 05772 / 293-900 Fax: 05772 / 293-333   https://www.mittwald.de   Geschäftsführer: Robert Meyer, Florian Jürgens   St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen Informationen zur Datenverarbeitung im Rahmen unserer Geschäftstätigkeit  gemäß Art. 13-14 DSGVO sind unter www.mittwald.de/ds abrufbar. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From xin-ran.wang at intel.com Wed Aug 11 11:52:38 2021 From: xin-ran.wang at intel.com (Wang, Xin-ran) Date: Wed, 11 Aug 2021 11:52:38 +0000 Subject: [cyborg]Cyborg weekly meeting time slot Message-ID: Hi all, I would like to let you know that the now time slot of Cyborg Weekly meeting is 12:00-13:00 UTC. Welcome to join us on https://www.irccloud.com/irc/oftc/channel/openstack-cyborg. Thanks, Xin-Ran Wang -------------- next part -------------- An HTML attachment was scrubbed... URL: From senrique at redhat.com Wed Aug 11 14:14:42 2021 From: senrique at redhat.com (Sofia Enriquez) Date: Wed, 11 Aug 2021 11:14:42 -0300 Subject: [cinder] Bug deputy report for week of 2021-11-08 Message-ID: Hello, This is a bug report from 2021-04-08 to 2021-11-08. Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting ----------------------------------------------------------------------------------------- Incomplete - https://bugs.launchpad.net/cinder/+bug/1939145 "[IBM Storwize SVC]: use system_id in mkrelationship". Unassigned. Wishlist - https://bugs.launchpad.net/cinder-tempest-plugin/+bug/1939325 "Add placement service to README". Unassigned. - https://bugs.launchpad.net/cinder-tempest-plugin/+bug/1939322 " glance registry was deprecated in Queens and should be removed from README". Unassigned. Cheers, -- Sofía Enriquez she/her Software Engineer Red Hat PnT IRC: @enriquetaso @RedHat Red Hat Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: From feilong at catalystcloud.nz Wed Aug 11 09:06:33 2021 From: feilong at catalystcloud.nz (feilong) Date: Wed, 11 Aug 2021 21:06:33 +1200 Subject: [magnum] [kolla-ansible] [kayobe] [Victoria] Magnum Kubernetes cluster failure recovery In-Reply-To: References: Message-ID: <54b6eb74-fe76-1c20-86f9-8082b2186343@catalystcloud.nz> Hi Tony, If I understand correctly, now you're Magnum env can create k8s cluster successfully. But the auto scaling failure caused the update_failed status, is it? If so, cluster resize should be able to bring the cluster back. And you can just resize the cluster to the current node number.  For that case, magnum should be able to fix the heat stack. If you failed with resize, then better check the heat log to understand why the heat stack update failed. On 11/08/21 7:04 pm, Tony Pearce wrote: > I sent this mail last week looking for some insight with regards to a > magnum issue we had. I hadnt seen any reply and searched for my sent > mail - I found I did not complete the subject line. Sorry about that.  > > Resending again here with a subject. If anyone has any insight to this > I'd be grateful to hear from you.  > > Kind regards, > > Tony Pearce > > > > > ---------- Forwarded message --------- > From: *Tony Pearce* > > Date: Thu, 5 Aug 2021 at 14:22 > Subject: [magnum] [kolla-ansible] [kayobe] [Victoria] > To: OpenStack Discuss > > > > Testing out Kubernetes with Magnum project, deployed via kayobe on > Victoria we have deployed an auto scaling cluster and have run into a > problem and I'm not sure how to proceed. I understand that the cluster > tried to scale up but the openstack project did not have enough CPU > resources to accommodate it (error= Quota exceeded for cores: > Requested 4, but already used 20 of 20 cores). > > So the situation is that the cluster shows "healthy" and > "UPDATE_FAILED" but also kubectl commands are failing [1]. > > What is required to return the cluster back to a working status at > this point? I have tried: > - cluster resize to reduce number of workers > - cluster resize to increase number of workers after increasing > project quota > - cluster resize and maintaining the same number of workers > > When trying any of the above, horizon shows an immediate error "Unable > to resize given cluster" but magnum logs and heat logs do not show any > log update at all at that time. > > - using "check stack" and resume stack in the stack horizon menu gives > this error [2] > > Investigating the kubectl issue, it was noted that some services had > failed on the master node [3]. Manual start as well as reboot the node > did not bring up the services. Unfortunately I dont have ssh access to > the master and no further information has been forthcoming with > regards to logs for those service failures so I am unable to provide > anything around that here. > > I found this link [4] so I decided to delete the master node then run > "check" cluster again but the check cluster just fails in the same way > except this time it fails saying that it cannot find the master [5] > while the previous error was that it could not find a node. > > Ideally I would prefer to recover the cluster - whether this is still > possible I am unsure. I can probably recreate this scenario again. > What steps should be performed in this case to restore the cluster? > > > > [1] > kubectl get no > Error from server (Timeout): the server was unable to return a > response in the time allotted, but may still be processing the request > (get nodes) > > [2] > Resource CHECK failed: ["['NotFound: > resources[4].resources.kube-minion: Instance None could not be found. > (HTTP 404) (Request-ID: req-6069ff6a-9eb6-4bce-bb25-4ef001ebc428)']. > 'CHECK' not fully supported (see resources)"] > > [3] > > [systemd] > Failed Units: 3 >   etcd.service >   heat-container-agent.service >   logrotate.service > > [4] https://bugzilla.redhat.com/show_bug.cgi?id=1459854 > > [5] > > ["['NotFound: > resources.kube_masters.resources[0].resources.kube-master: Instance > c6185e8e-1a98-4925-959b-0a56210b8c9e could not be found. (HTTP 404) > (Request-ID: req-bdfcc853-7dbb-4022-9208-68b1ab31008a)']. 'CHECK' not > fully supported (see resources)"]. > > Kind regards, > > Tony Pearce -- Cheers & Best regards, ------------------------------------------------------------------------------ Feilong Wang (王飞龙) (he/him) Head of Research & Development Catalyst Cloud Aotearoa's own Mob: +64 21 0832 6348 | www.catalystcloud.nz Level 6, 150 Willis Street, Wellington 6011, New Zealand CONFIDENTIALITY NOTICE: This email is intended for the named recipients only. It may contain privileged, confidential or copyright information. If you are not the named recipient, any use, reliance upon, disclosure or copying of this email or its attachments is unauthorised. If you have received this email in error, please reply via email or call +64 21 0832 6348. ------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From erin at openstack.org Wed Aug 11 17:05:19 2021 From: erin at openstack.org (Erin Disney) Date: Wed, 11 Aug 2021 12:05:19 -0500 Subject: OpenInfra Live - August 12th at 9am CT Message-ID: <58B5AD92-488A-4FB6-A2CE-0297952536F0@openstack.org> Hi everyone, This week’s OpenInfra Live episode is brought to you by the Bare Metal SIG. Join us as members from the Bare Metal SIG join us to discuss how Ironic works to simplify many of the hardships physical bare metal operators deal with on a daily basis, including an overview of the project, project roadmap, and use cases of Ironic in production. Episode: Bare Metal: Ironic In Production Date and time: August 12th at 9am CT (1400 UTC) You can watch us live on: YouTube: https://www.youtube.com/watch?v=m81Q2bU9bGU LinkedIn: https://www.linkedin.com/feed/update/urn:li:ugcPost:6830910904905940992/ Facebook: https://www.facebook.com/104139126308032/posts/4229345477120689/ WeChat: recording will be posted on OpenStack WeChat after the live stream Speakers: Julia Kreger (Red Hat) Mohammed Naser (Vexxhost) Mark Goddard (Stack HPC) Chris Krelle (NVIDIA) Have an idea for a future episode? Share it now at ideas.openinfra.live . Thanks, Erin Erin Disney Event Marketing Open Infrastructure Foundation -------------- next part -------------- An HTML attachment was scrubbed... URL: From helena at openstack.org Wed Aug 11 19:05:51 2021 From: helena at openstack.org (helena at openstack.org) Date: Wed, 11 Aug 2021 14:05:51 -0500 (CDT) Subject: [PTLs][release] Xena Cycle Highlights In-Reply-To: <1626203962.46862440@apps.rackspace.com> References: <1626203962.46862440@apps.rackspace.com> Message-ID: <1628708751.85977710@apps.rackspace.com> Hello everyone! I wanted to send out another reminder that the deadline for cycle highlights is the end of the R-5 week on September 3 (see below email for more details). I look forward to seeing them :) Cheers, Helena Marketing and Community Associate OpenInfra Foundation -----Original Message----- From: "helena at openstack.org" Sent: Tuesday, July 13, 2021 2:19pm To: "OpenStack Discuss" Subject: [PTLs][release] Xena Cycle Highlights Hello Everyone!It's that time of the year once again! It's time to start thinking about calling out 'cycle-highlights' in your deliverables! As PTLs, you probably get many pings towards the end of every release cycle by various parties (marketing, management, journalists, etc) asking for highlights of what is new and what significant changes are coming in the new release. By putting them all in the same place it makes them easy to reference because they get compiled into a pretty website like this from the last few releases: Ussuri[1], Victoria[2]. We don't need a fully fledged marketing message, just a few highlights (3-4 ideally), from each project team. Looking through your release notes might be a good place to start. The deadline for cycle highlights is the end of the R-5 week [3] on September 3.How To Reminder: -------------------------Simply add them to the deliverables/$RELEASE/$PROJECT.yaml in the openstack/releases repo like this: cycle-highlights: - Introduced new service to use unused host to mine bitcoin.The formatting options for this tag are the same as what you are probably used to with Reno release notes.Also, you can check on the formatting of the output by either running locally: tox -e docsAnd then checking the resulting doc/build/html/$RELEASE/highlights.html file or the output of the build-openstack-sphinx-docs job under html/$RELEASE/highlights.html. Feel free to add Kendall Nelson (diablo_rojo) as a reviewer on your patches. Can't wait to see you all have accomplished this release! Thanks :) -Helena Spease (hspease) [1] [ https://releases.openstack.org/ussuri/highlights.html ]( https://releases.openstack.org/ussuri/highlights.html ) [2] [ https://releases.openstack.org/victoria/highlights.html ]( https://releases.openstack.org/victoria/highlights.html ) [3] [ https://releases.openstack.org/xena/schedule.html ]( https://releases.openstack.org/xena/schedule.html ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From feilong at catalystcloud.nz Wed Aug 11 18:41:24 2021 From: feilong at catalystcloud.nz (feilong) Date: Thu, 12 Aug 2021 06:41:24 +1200 Subject: [magnum] [kolla-ansible] [kayobe] [Victoria] Magnum Kubernetes cluster failure recovery In-Reply-To: <85bd5e9e6b4c8e0a60f51f9fd32e170a1d4064ec.camel@mittwald.de> References: <85bd5e9e6b4c8e0a60f51f9fd32e170a1d4064ec.camel@mittwald.de> Message-ID: <1701b95c-2cad-c593-e394-1825355e61ea@catalystcloud.nz> Let me try to explain it from a design perspective: 1. Auto scaler: Now cluster auto scaler talks to Magnum resize API directly to scale, see https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/magnum/magnum_manager_impl.go#L399 2. Auto healer: As you know auto scaler only cares about the worker node, it won't scale the master nodes. However, auto healer can repair both master nodes and worker nodes. With worker nodes repairing, Magnum auto healer uses magnum resize API. But because the magnum resize api doesn't support master nodes resizing, so the master nodes repairing is done by Heat stack update. magnum auto healer will mark some resources of the master node as unhealthy, then call Heat stack update to rebuild those resources. On 11/08/21 10:25 pm, Sven Kieske wrote: > On Mi, 2021-08-11 at 10:16 +0000, Sven Kieske wrote: >> the problem is, that the kubernetes autoscaler directly talks to the openstack api, e.g. >> nova for creating and destroying instances. > Nevermind I got that wrong. > > The autoscaler talks to heat, so there should no problem (but heat trips itself up on some error conditions). > I was in fact talking about the magnum auto healer (https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/magnum-auto-healer/using-magnum-auto-healer.md ) > which seems to circumvent heat and talks directly with nova. > > Are you using the magnum auto healing feature by chance? > > HTH > -- Cheers & Best regards, ------------------------------------------------------------------------------ Feilong Wang (王飞龙) (he/him) Head of Research & Development Catalyst Cloud Aotearoa's own Mob: +64 21 0832 6348 | www.catalystcloud.nz Level 6, 150 Willis Street, Wellington 6011, New Zealand CONFIDENTIALITY NOTICE: This email is intended for the named recipients only. It may contain privileged, confidential or copyright information. If you are not the named recipient, any use, reliance upon, disclosure or copying of this email or its attachments is unauthorised. If you have received this email in error, please reply via email or call +64 21 0832 6348. ------------------------------------------------------------------------------ From gouthampravi at gmail.com Wed Aug 11 21:59:02 2021 From: gouthampravi at gmail.com (Goutham Pacha Ravi) Date: Wed, 11 Aug 2021 14:59:02 -0700 Subject: [manila] Propose haixin to manila-core Message-ID: Hello Zorillas, Haixin (haixin77 on Launchpad, haixin on OFTC) has been contributing to manila since the Train release. He is part of a team that operates manila at scale at Inspur and supports their storage integrations within OpenStack. He diligently files bug reports, interacts with the community and has thus far contributed several important perf-scale improvements across the service stack. He also provides useful review feedback to fellow contributors, and participates in team-efforts such as bug squashes, review jams and mentorship of new contributors. I'm delighted to note that he wants to take on some more maintenance responsibility [2]. So, with your support I'd like to add haixin to the manila-core group on gerrit. This "power" comes with significant responsibility and I'm hoping haixin will ramp up soon and help share some of the load from the existing maintainers. Please let me know your thoughts, +/- 1s, 2s, 2-cents, etc! Thanks, Goutham [1] https://www.stackalytics.io/?user_id=haixin77&project_type=all&release=all&metric=person-day&module=manila-group [2] https://docs.openstack.org/manila/latest/contributor/manila-review-policy.html From tpb at dyncloud.net Wed Aug 11 22:11:17 2021 From: tpb at dyncloud.net (Tom Barron) Date: Wed, 11 Aug 2021 18:11:17 -0400 Subject: [manila] Propose haixin to manila-core In-Reply-To: References: Message-ID: <20210811221117.cqw7x3vxbk4i6wqf@barron.net> On 11/08/21 14:59 -0700, Goutham Pacha Ravi wrote: >Hello Zorillas, > >Haixin (haixin77 on Launchpad, haixin on OFTC) has been contributing >to manila since the Train release. He is part of a team that operates >manila at scale at Inspur and supports their storage integrations >within OpenStack. He diligently files bug reports, interacts with the >community and has thus far contributed several important perf-scale >improvements across the service stack. He also provides useful review >feedback to fellow contributors, and participates in team-efforts such >as bug squashes, review jams and mentorship of new contributors. I'm >delighted to note that he wants to take on some more maintenance >responsibility [2]. > >So, with your support I'd like to add haixin to the manila-core group >on gerrit. This "power" comes with significant responsibility and I'm >hoping haixin will ramp up soon and help share some of the load from >the existing maintainers. Please let me know your thoughts, +/- 1s, >2s, 2-cents, etc! > >Thanks, >Goutham > >[1] https://www.stackalytics.io/?user_id=haixin77&project_type=all&release=all&metric=person-day&module=manila-group >[2] https://docs.openstack.org/manila/latest/contributor/manila-review-policy.html > An enthusiastic +1 from me! -- Tom Barron From zhangbailin at inspur.com Thu Aug 12 00:51:38 2021 From: zhangbailin at inspur.com (=?utf-8?B?QnJpbiBaaGFuZyjlvKDnmb7mnpcp?=) Date: Thu, 12 Aug 2021 00:51:38 +0000 Subject: =?utf-8?B?562U5aSNOiBbbWFuaWxhXSBQcm9wb3NlIGhhaXhpbiB0byBtYW5pbGEtY29y?= =?utf-8?Q?e?= In-Reply-To: References: Message-ID: <151b8c17d90c474b85f7d74e01a6a42f@inspur.com> +2 I see that Haixin’s contribution to the Manila project is outstanding and continues to contribute. I am very happy that he can be recognized by the Manila team. brinzhang Inspur Electronic Information Industry Co.,Ltd. -----邮件原件----- 发件人: Goutham Pacha Ravi [mailto:gouthampravi at gmail.com] 发送时间: 2021年8月12日 5:59 收件人: OpenStack Discuss 主题: [manila] Propose haixin to manila-core Hello Zorillas, Haixin (haixin77 on Launchpad, haixin on OFTC) has been contributing to manila since the Train release. He is part of a team that operates manila at scale at Inspur and supports their storage integrations within OpenStack. He diligently files bug reports, interacts with the community and has thus far contributed several important perf-scale improvements across the service stack. He also provides useful review feedback to fellow contributors, and participates in team-efforts such as bug squashes, review jams and mentorship of new contributors. I'm delighted to note that he wants to take on some more maintenance responsibility [2]. So, with your support I'd like to add haixin to the manila-core group on gerrit. This "power" comes with significant responsibility and I'm hoping haixin will ramp up soon and help share some of the load from the existing maintainers. Please let me know your thoughts, +/- 1s, 2s, 2-cents, etc! Thanks, Goutham [1] https://www.stackalytics.io/?user_id=haixin77&project_type=all&release=all&metric=person-day&module=manila-group [2] https://docs.openstack.org/manila/latest/contributor/manila-review-policy.html From kkchn.in at gmail.com Thu Aug 12 01:23:24 2021 From: kkchn.in at gmail.com (KK CHN) Date: Thu, 12 Aug 2021 06:53:24 +0530 Subject: Automating import of large numbers of VMs to OpenStack from other hypervisor environment Message-ID: Hi list, I am in the process of migrating 150+ VMs running on Rhevm4.1 to KVM based OpenStack installation ( Ussuri with KVm and glance as image storage.) What I am doing now, manually shutdown each VM through RHVM GUI and export to export domain and scp those image files of each VM to our OpenStack controller node and uploading to glance and creating each VM manually. query 1. Is there a better way to automate this migration by any utility or scripts ? Any one done this kind of automatic migration before what was your approach? Or whats the better approach instead of doing manual migration ? Or only manually I have to repeat the process for all 150+ Virtual machines? ( guest VMs are CentOS7 and Redhat Linux 7 with LVM data partitions attached) Kindly share your thoughts.. Query 2. other than this 150+ VMs Redhat Linux 7 and Centos VMs on Rhevm 4.1, I have to migrate 50+ VMs which hosted on hyperV. What the method / approach for exporting from HyperV and importing to OpenStack Ussuri version with glance with KVM hpervisor ? ( This is the ffirst time I am going to use hyperV, no much idea about export from hyperv and Import to KVM) Will the images exported form HyperV(vhdx image disks with single disk and multiple disk(max 3 disk) VMs) can be directly imported to KVM ? does KVM support this or need to modify vhdx disk images to any other format ? What is the best approach should be in case of HyperV hosted VMs( Windows 2012 guest machines and Linux guest machines ) to be imported to KVM based OpenStack(Ussuri version with glance as image storage ). Thanks in advance Kris -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Thu Aug 12 01:26:13 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Wed, 11 Aug 2021 20:26:13 -0500 Subject: [all][tc] Technical Committee next weekly meeting on Aug 12th at 1500 UTC In-Reply-To: <17b2c742a53.d429dbd810840.1063787877581206666@ghanshyammann.com> References: <17b2c742a53.d429dbd810840.1063787877581206666@ghanshyammann.com> Message-ID: <17b37f78657.f818a78d135503.6925093707825578011@ghanshyammann.com> Hello Everyone, Below is the agenda for Tomorrow's TC meeting schedule at 1500 UTC in #openstack-tc IRC channel. -https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting == Agenda for tomorrow's TC meeting == * Roll call * Follow up on past action items * Required things/steps to push Project Skyline(dashboard) proposal (diablo_rojo) * Gate health check (dansmith/yoctozepto) ** http://paste.openstack.org/show/jD6kAP9tHk7PZr2nhv8h/ * Wallaby testing runtime for centos8 vs centos8-stream ** https://review.opendev.org/q/I508eceb00d7501ffcfac73d7bc2272badb241494 ** centos8 does not work in stable/wallaby, for details, comments in https://review.opendev.org/c/openstack/devstack/+/803039 * Murano project health (gmann) * PTG Planning ** https://etherpad.opendev.org/p/tc-yoga-ptg * Open Reviews ** https://review.opendev.org/q/projects:openstack/governance+is:open -gmann ---- On Mon, 09 Aug 2021 14:46:55 -0500 Ghanshyam Mann wrote ---- > Hello Everyone, > > Technical Committee's next weekly meeting is scheduled for Aug 12th at 1500 UTC. > > If you would like to add topics for discussion, please add them to the below wiki page by > Wednesday, Aug 11th, at 2100 UTC. > > https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting > > -gmann > > From tkajinam at redhat.com Thu Aug 12 01:35:19 2021 From: tkajinam at redhat.com (Takashi Kajinami) Date: Thu, 12 Aug 2021 10:35:19 +0900 Subject: [neutron] Status of networking-mlnx: Is it still maintained ? In-Reply-To: References: Message-ID: I noticed I didn't update this thread. I managed to get a response from the current maintainer of networking-mlnx and it was confirmed there is an intention to keep maintaining the repo. The missing stable/wallaby has been created. The deprecation in puppet-neutron was merged once but it has been reverted. On Mon, Jul 19, 2021 at 4:14 PM Takashi Kajinami wrote: > Because I've received no feedback about this topic, I'll move forward the > deprecation > of networking-mlnx support in puppet-neutron. > https://review.opendev.org/c/openstack/puppet-neutron/+/800502 > > If anybody has concerns please share your thoughts on the proposed change. > > On Mon, Jul 12, 2021 at 11:49 PM Takashi Kajinami > wrote: > >> Hello, >> >> I noticed the networking-mlnx repo[1] is not updated for a while and >> looks unmaintained. >> The repo doesn't have a stable/wallaby release created, and >> its setup.cfg doesn't include python 3.8 as a supported platform. >> https://opendev.org/x/networking-mlnx >> >> Is anybody still maintaining this repo ? >> >> If the repo is no longer maintained, I'll propose deprecating support >> for the plugin from puppet-neutron. >> Please let me know if you have any concern with that deprecation. >> >> I appreciate any input about this $topic. >> >> Thank you, >> Takashi Kajinami >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From berndbausch at gmail.com Thu Aug 12 03:09:23 2021 From: berndbausch at gmail.com (Bernd Bausch) Date: Thu, 12 Aug 2021 12:09:23 +0900 Subject: Unable to retrieve flavor details and unable to retrieve instance details In-Reply-To: References: Message-ID: Which action provokes this error? You seem to say that it doesn't always happen; do you have an idea under which circumstances it occurs? On Wed, Aug 11, 2021 at 2:45 AM cloud learner wrote: > Dear Experts, > > I have deployed victoria with controller+compute, and 2 extra compute > using packstack. Everything is working fine but many times it shows the > error as mentioned in the subject line. The log files of nova are > attached herewith. Kindly help > -------------- next part -------------- An HTML attachment was scrubbed... URL: From skaplons at redhat.com Thu Aug 12 05:32:56 2021 From: skaplons at redhat.com (Slawek Kaplonski) Date: Thu, 12 Aug 2021 07:32:56 +0200 Subject: [neutron] Drivers meeting 13.08 cancelled Message-ID: <13246034.Z6Tt6EkaQD@p1> Hi, I'm cancelling tomorrow drivers meeting. I know that Miguel and all Red Hat people will not be there so we will not have quorum on the meeting. See You all online. -- Slawek Kaplonski Principal Software Engineer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From skaplons at redhat.com Thu Aug 12 06:53:31 2021 From: skaplons at redhat.com (Slawek Kaplonski) Date: Thu, 12 Aug 2021 08:53:31 +0200 Subject: [networking-bgpvpn][networking-bagpipe] Propose to EOL stable/pike and stable/queens In-Reply-To: <3027663.6fTeYNvNto@p1> References: <3027663.6fTeYNvNto@p1> Message-ID: <2960185.KPFn9PeN4i@p1> Hi, There was no volunteers who would like to keep stable/pike and/or stable/ queens for networking-bagpipe and networking-bgpvpn so I just proposed procedure to make it EOL. Patches for that are here: https://review.opendev.org/c/openstack/releases/+/804351/ https://review.opendev.org/c/openstack/releases/+/804352/ On czwartek, 5 sierpnia 2021 12:20:28 CEST you wrote: > Hi, > > Regarding recent email from Elod [1] CI of the stable/pike and stable/queens > branches in networking-bgpvpn is broken now. I checked that it's due to > Horizon which is already EOL in those branches. > I proposed patch [2] to hopefully fix it quickly by using eol tag of Horizon. > But even with that there are some other problems in the openstack-tox-pep8 and > networking-bgpvpn-dsvm-functional jobs. > Last merged patches in networking-bgpvpn were in 2019: [3] and [4]. > Giving all that I propose to make networking-bgpvpn stable/pike and stable/ > queens branches to be EOL now. > > Networking-bagpipe project is tightly coupled with networking-bgpvpn. Last > patches merged in that project were also in 2019: [5] and [6]. > Because of the above, I propose also to make branches stable/pike and stable/ > queens in the networking-bagpipe to be EOL. > > I will wait until end of next week for anyone who would like to maybe step up > as maintainer of those branches. If there will be no volunteers for that, I > will EOL those branches in networking-bgpvpn and networking-bagpipe. > > [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-July/ > 023944.html > [2] https://review.opendev.org/c/openstack/networking-bgpvpn/+/803545 > [3] > https://review.opendev.org/q/project:openstack/networking-bgpvpn+branch:stabl > e/queens [4] > https://review.opendev.org/q/project:openstack/networking-bgpvpn+branch:stabl > e/queens [5] > https://review.opendev.org/q/project:openstack/networking-bagpipe+branch:stab > le/queens [6] > https://review.opendev.org/q/project:openstack/networking-bagpipe+branch:stab > le/pike -- Slawek Kaplonski Principal Software Engineer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From lyarwood at redhat.com Thu Aug 12 07:51:17 2021 From: lyarwood at redhat.com (Lee Yarwood) Date: Thu, 12 Aug 2021 08:51:17 +0100 Subject: [nova] Removal of legacy block_device_info format Message-ID: <20210812075117.4ufzgvumo4r4glvb@lyarwood-laptop.usersys.redhat.com> Hello all, This is advance notice of $subject [1] for out of tree virt driver maintainers. While working on a bugfix [2] I noticed that the original legacy block_device_info dict format [3] hasn't been used by any in-tree drivers since xenapi was dropped in Victoria [4]. As a result I will be looking to remove support for the format during Xena unless any out of tree drivers come forward with issues. Cheers, Lee [1] https://review.opendev.org/c/openstack/nova/+/804286 [2] https://review.opendev.org/c/openstack/nova/+/804230 [3] https://docs.openstack.org/nova/latest/reference/block-device-structs.html#block-device-info [4] https://review.opendev.org/c/openstack/nova/+/749304 -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From pierre at stackhpc.com Thu Aug 12 08:55:51 2021 From: pierre at stackhpc.com (Pierre Riteau) Date: Thu, 12 Aug 2021 10:55:51 +0200 Subject: [blazar][ptg] Yoga PTG meeting Message-ID: Hello, As part of the Yoga PTG, the Blazar team project will meet on Thursday October 21 from 15:00 to 17:00 UTC in the Bexar room. I have created an Etherpad to define the agenda: https://etherpad.opendev.org/p/yoga-ptg-blazar Feel free to add topics you would like to see discussed. Thanks, Pierre Riteau -------------- next part -------------- An HTML attachment was scrubbed... URL: From tkajinam at redhat.com Thu Aug 12 10:09:06 2021 From: tkajinam at redhat.com (Takashi Kajinami) Date: Thu, 12 Aug 2021 19:09:06 +0900 Subject: [puppet] Propose retiring puppet-monasca Message-ID: Hello, tl;dr If nobody is interested in fixing bug 1930553, then I'll propose retiring puppet-monasca during this cycle. A few months ago, I found an issue[1] with puppet-monasca and it turned out that the module is not compatible with the recent puppet-python. The module still relies on python::virtualenv which was removed in puppet-python 6.0. Currently the gate was unblocked by pinning puppet-python to an older version but we should remove that pin at some point. [1] https://bugs.launchpad.net/puppet-monasca/+bug/1930553 However, fixing the problem requires relatively large refactoring, and I'm afraid we(at least, I) don't have enough resources for that. The main challenge is that we have no functional tests in our CI jobs now to validate the fix in puppet-monasca. I checked the commit history of this module but I don't see any meaningful change made for several years. If nobody is interested in maintaining the module and fixing the problem then I'd propose retiring the module. I'll wait for any feedback for a week, then decide whether I'll submit actual patches to retire the repo. Thank you, Takashi -------------- next part -------------- An HTML attachment was scrubbed... URL: From khanh.chu at svtech.com.vn Thu Aug 12 14:43:13 2021 From: khanh.chu at svtech.com.vn (Chu Ha Khanh) Date: Thu, 12 Aug 2021 21:43:13 +0700 Subject: Horizon problem when configure 2 regions Message-ID: <000001d78f88$62726f70$27574e50$@svtech.com.vn> I lab configuring 2 region RegionOne, RegionTwo. 2 install 2 controllers node. RegionOne: control3: Horizon, Keystone, Glance. RegionTwo: control4: Glance. I can list image when I use CLI to each regions. However when I login to RegionTwo on Horizon. It show problem. I stuck for several weeks . Hope can be helped. Thank and Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 46961 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 63713 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 75762 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 76212 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: log_image.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: my_local_settings Type: application/octet-stream Size: 8795 bytes Desc: not available URL: From mnaser at vexxhost.com Thu Aug 12 15:56:14 2021 From: mnaser at vexxhost.com (Mohammed Naser) Date: Thu, 12 Aug 2021 11:56:14 -0400 Subject: [murano][tc] Project Retirement Message-ID: Hi folks, Today, at the TC weekly meeting, it was brought up that Murano was not very active over the past few years and most likely has had a major amount of bitrot. The community is not able to reach the current PTL of the project either. Personally, I think that at this point, Murano is a bit past it's time. We've got a lot more developments in application deployment nowadays, OpenStack offers things like Magnum to get a Kubernetes cluster which you can run workloads on via Helm, or projects like Zun offer serverlerss containers directly, making a lot of what Murano used to do not so helpful in the current landscape. I'm sending this email to discuss/propose the idea of retiring the project. Regards, Mohammed -- Mohammed Naser VEXXHOST, Inc. From marios at redhat.com Thu Aug 12 15:58:21 2021 From: marios at redhat.com (Marios Andreou) Date: Thu, 12 Aug 2021 18:58:21 +0300 Subject: [TripleO] next irc meeting Tuesday 17 August @ 1400 UTC in OFTC #tripleo Message-ID: Reminder the next TripleO irc meeting is this coming Tuesday agenda: https://wiki.openstack.org/wiki/Meetings/TripleO one-off items: https://etherpad.opendev.org/p/tripleo-meeting-items (please add any tripleo status/ongoing work etc to the etherpad). Our last meeting was on Aug 03 - you can find logs @ https://meetings.opendev.org/meetings/tripleo/2021/tripleo.2021-08-03-14.00.html Hope you can make it, regards, marios From stephenfin at redhat.com Thu Aug 12 16:00:29 2021 From: stephenfin at redhat.com (Stephen Finucane) Date: Thu, 12 Aug 2021 17:00:29 +0100 Subject: [all] SQLAlchemy 2.0 and coming ORM apocalypse Message-ID: <3c6449e1f3529b85fdd2d17459adb3dc9d3add9f.camel@redhat.com> tl;dr: If you haven't already started looking at SQLAlchemy 2.0 compatibility and/or are still using sqlalchemy-migrate, you probably have work to do. As you can guess from $subject, there's a new major version of SQLAlchemy in the pipeline. The good news: it cleans up a lot of cruft and makes a lot of things such as session management more explicit and verbose, with the idea being that this should avoid a lot of gotchas and foot-gun moments. The bad news: the changes are pretty extensive, and virtually anyone that uses SQLAlchemy, which is to say every (?) OpenStack service out there, will likely have to make changes. This change will likely have a couple of impacts for users: # Breaking changes in oslo.db The oslo devs have been steadily working through the many errors that oslo.db is currently emitting when SQLAlchemy 2.0 deprecation warnings are turned on. The patches (which is not yet complete) to address these can be found here [1]. As a result of these changes, a number of oslo.db APIs are likely to start performing slightly differently, and many more may be deprecated and eventually removed. An example of the kind of change you can expect to see can be found in this glance patch [2]. We will work to minimize these changes but some will be unavoidable once sqlalchemy 2.0 actually arrives. # Breaking changes in your own project If oslo.db seeing breaking changes because of SQLAlchemy 2.0, you can be sure that you're going to see some too. Fortunately, there are ways you can get ahead of this. Turning SADeprecationWarning warnings into errors for your own module, as we've done for oslo.db [3][4] seems a sensible pattern to weed out these issues. As an aside, enabling warnings as errors seems to be a generally good idea in a unit test environment. It's usually a lot easier to address these things as they pop up that when things are finally removed and stuff explodes. To each their own though, of course. # The long prophesied death of sqlalchemy-migrate The lack of maintenance on sqlalchemy-migrate has already been well documented [5], however, SQLAlchemy 2.0 is likely to be the thing that finally puts the nail in sqlalchemy-migrate's coffin. I've been working on migrating the last few laggards still using sqlalchemy-migrate and have successfully removed all traces of it from glance (thanks, glance-core!), while the nova and cinder patches are making reasonable progress (though I do wish it was faster). The only remaining "core" project to be migrated is keystone. This proved a little too complicated for me to do in the limited time I have to work on these things, and I'm in the middle of a role change in my day job so my time to work on upstream OpenStack will be decreasing much further going forward (though not to zero, I'm hoping). Fortunately, there's quite a bit of prior art available now that people can follow when migrating stuff [6]. Related to the oslo.db changes: everything related to sqlalchemy-migrate in oslo.db should be deprecated by the next oslo.db release, and I suspect we'll be pretty aggressive in pruning these. Based on codesearch.o.o, this will have impacts for at least keystone and cinder. # A chance to evaluate all things DB One positive out of this is that the changes necessary may be broad enough to take the opportunity to re-evaluate decisions made regarding your DB layer. We've been doing this in nova, moving lots of things about to clear up the distinction between the main and API DBs and to reduce lots of tech debt that had built up in 'nova.db'. Consider using the opportunity to do the if possible. --- Hopefully this has been useful. If you have questions about any of the above, please reach out and I'll do my best to answer them. Cheers, Stephen [1] https://review.opendev.org/q/topic:%2522sqlalchemy-20%2522+(status:open+OR+status:merged)+project:openstack/oslo.db [2] https://review.opendev.org/c/openstack/glance/+/804406 [3] https://github.com/openstack/oslo.db/commit/40bce5a2baf75dc87dd591e0f71a00f221a2ba92 [4] https://github.com/openstack/oslo.db/commit/4c1eb966c08d29214c1905e74965f4109f41b013 [5] http://lists.openstack.org/pipermail/openstack-discuss/2021-February/020672.html [6] https://review.opendev.org/q/topic:%22bp%252Fremove-sqlalchemy-migrate%22+(status:open%20OR%20status:merged) From mike_mp at zzzcomputing.com Thu Aug 12 23:47:00 2021 From: mike_mp at zzzcomputing.com (Mike Bayer) Date: Thu, 12 Aug 2021 19:47:00 -0400 Subject: [all] SQLAlchemy 2.0 and coming ORM apocalypse In-Reply-To: <3c6449e1f3529b85fdd2d17459adb3dc9d3add9f.camel@redhat.com> References: <3c6449e1f3529b85fdd2d17459adb3dc9d3add9f.camel@redhat.com> Message-ID: <3c334098-a704-441e-b1e3-a27cc0459566@www.fastmail.com> didn't see the main docs linked so the story starts at SQLA's migration docs. starting w/ 1.4 which has all of 2.0's internals ready to go: https://docs.sqlalchemy.org/en/14/changelog/migration_14.html then 2.0 which includes 1.x->2.0 migration notes: https://docs.sqlalchemy.org/en/14/changelog/migration_20.html we spent a lot of time trying to make this process smooth. it has both a few ideas from how py2->py3 worked (warnings mode) and also does some things intentionally the opposite of how py2/3 did it (you can run a codebase that is compatible with 1.4 and 2.0 at the same time). On Thu, Aug 12, 2021, at 12:00 PM, Stephen Finucane wrote: > tl;dr: If you haven't already started looking at SQLAlchemy 2.0 compatibility > and/or are still using sqlalchemy-migrate, you probably have work to do. > > As you can guess from $subject, there's a new major version of SQLAlchemy in the > pipeline. The good news: it cleans up a lot of cruft and makes a lot of things > such as session management more explicit and verbose, with the idea being that > this should avoid a lot of gotchas and foot-gun moments. The bad news: the > changes are pretty extensive, and virtually anyone that uses SQLAlchemy, which > is to say every (?) OpenStack service out there, will likely have to make > changes. > > This change will likely have a couple of impacts for users: > > # Breaking changes in oslo.db > > The oslo devs have been steadily working through the many errors that oslo.db is > currently emitting when SQLAlchemy 2.0 deprecation warnings are turned on. The > patches (which is not yet complete) to address these can be found here [1]. As a > result of these changes, a number of oslo.db APIs are likely to start performing > slightly differently, and many more may be deprecated and eventually removed. An > example of the kind of change you can expect to see can be found in this glance > patch [2]. We will work to minimize these changes but some will be unavoidable > once sqlalchemy 2.0 actually arrives. > > # Breaking changes in your own project > > If oslo.db seeing breaking changes because of SQLAlchemy 2.0, you can be sure > that you're going to see some too. Fortunately, there are ways you can get ahead > of this. Turning SADeprecationWarning warnings into errors for your own module, > as we've done for oslo.db [3][4] seems a sensible pattern to weed out these > issues. > > As an aside, enabling warnings as errors seems to be a generally good idea in a > unit test environment. It's usually a lot easier to address these things as they > pop up that when things are finally removed and stuff explodes. To each their > own though, of course. > > # The long prophesied death of sqlalchemy-migrate > > The lack of maintenance on sqlalchemy-migrate has already been well documented > [5], however, SQLAlchemy 2.0 is likely to be the thing that finally puts the > nail in sqlalchemy-migrate's coffin. I've been working on migrating the last few > laggards still using sqlalchemy-migrate and have successfully removed all traces > of it from glance (thanks, glance-core!), while the nova and cinder patches are > making reasonable progress (though I do wish it was faster). The only remaining > "core" project to be migrated is keystone. This proved a little too complicated > for me to do in the limited time I have to work on these things, and I'm in the > middle of a role change in my day job so my time to work on upstream OpenStack > will be decreasing much further going forward (though not to zero, I'm hoping). > Fortunately, there's quite a bit of prior art available now that people can > follow when migrating stuff [6]. > > Related to the oslo.db changes: everything related to sqlalchemy-migrate in > oslo.db should be deprecated by the next oslo.db release, and I suspect we'll be > pretty aggressive in pruning these. Based on codesearch.o.o, this will have > impacts for at least keystone and cinder. > > # A chance to evaluate all things DB > > One positive out of this is that the changes necessary may be broad enough to > take the opportunity to re-evaluate decisions made regarding your DB layer. > We've been doing this in nova, moving lots of things about to clear up the > distinction between the main and API DBs and to reduce lots of tech debt that > had built up in 'nova.db'. Consider using the opportunity to do the if possible. > > --- > > Hopefully this has been useful. If you have questions about any of the above, > please reach out and I'll do my best to answer them. > > Cheers, > Stephen > > > [1] https://review.opendev.org/q/topic:%2522sqlalchemy-20%2522+(status:open+OR+status:merged)+project:openstack/oslo.db > [2] https://review.opendev.org/c/openstack/glance/+/804406 > [3] https://github.com/openstack/oslo.db/commit/40bce5a2baf75dc87dd591e0f71a00f221a2ba92 > [4] https://github.com/openstack/oslo.db/commit/4c1eb966c08d29214c1905e74965f4109f41b013 > [5] http://lists.openstack.org/pipermail/openstack-discuss/2021-February/020672.html > [6] https://review.opendev.org/q/topic:%22bp%252Fremove-sqlalchemy-migrate%22+(status:open%20OR%20status:merged) > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gouthampravi at gmail.com Fri Aug 13 07:34:18 2021 From: gouthampravi at gmail.com (Goutham Pacha Ravi) Date: Fri, 13 Aug 2021 00:34:18 -0700 Subject: [manila] We're having an OSC Hack-a-thon - Aug 18-20th 2021 Message-ID: Hi Zorillas and other interested stackers, tl;dr: - We're swarming to add missing OSC commands to python-manilaclient between 18th-20th Aug 2021, join us. - Kick-off Aug 18th at 1400 UTC, Mid-point check Aug 19th, 1500 UTC, Close-out Aug 20th, 1500 UTC on https://meetpad.opendev.org/manila-xena-hackathon Now for the longer version: As discussed at our IRC meeting today [1], I'm excited to share the nitty gritties of the upcoming OSC hack-a-thon. We'd be delighted to welcome existing and new contributors to come join us in the quest to achieve CLI parity in the OpenStackClient plugin within python-manilaclient. The work is being tracked here: https://tree.taiga.io/project/gouthampacha-openstack-manila-osc-integration-with-python-manilaclient/kanban The commands we're targeting are also featured in a specification: https://specs.openstack.org/openstack/manila-specs/specs/release_independent/manila-support-openstackclient.html The fine print for the hack-a-thon: - Maari Tamm has been the force behind this effort so far, and she's put up a very helpful "Getting Started" wiki [2] that we intend to expand through the hack-a-thon and finally add to the project's Contributor Docs. There are also several examples of recent additions [3][4][5] that could serve as inspiration. - You're free to create, claim and edit Taiga cards for the implementation you're chasing, we highly recommend picking only one card, and not claiming something someone else already has. Please reach out to gouthamr/maaritamm if you have to be added to the taiga board. - Also, Add yourself as a "watcher" to two other Taiga cards that someone else is implementing, this will mean that you will be a code reviewer on these implementations! - You can work in teams - min size: 1, max size: 3 - You can submit code between Aug 18th 1200 UTC and Aug 21st 1200 UTC to count towards this hack-a-thon - A day before the hack-a-thon, a few of us will gather to prep taiga.io cards, communicate with owners if there are conflicts, pre-reqs, etc. - During the hack-a-thon, we'll use #openstack-manila on OFTC to chat, and hop onto a meetpad room: https://meetpad.opendev.org/manila-xena-hackathon when required. - We'll have a half-hour kick-off session on Aug 18th at 1400 UTC - We'll use the manila community meeting hour as a mid-point status check (Aug 19th, 1500 UTC) - We'll have a half-hour close out meeting to discuss reviews, AIs and futures (grab your beers) (Aug 20th, 1500 UTC) I'm quite excited to participate in this, and I hope you are too. Please feel free to reach out here or on OFTC's #openstack-manila if you have any questions! Thanks, Goutham [1] https://meetings.opendev.org/meetings/manila/2021/manila.2021-08-12-15.00.log.html#l-40 [2] https://docs.google.com/document/d/1Kc02fO_ei-6NxPm_b6mnFbf-6MVdjMk71mFqX1aeEIs/edit [3] https://review.opendev.org/c/openstack/python-manilaclient/+/772393 [4] https://review.opendev.org/c/openstack/python-manilaclient/+/762754 [5] https://review.opendev.org/c/openstack/python-manilaclient/+/701229 -------------- next part -------------- An HTML attachment was scrubbed... URL: From midhunlaln66 at gmail.com Fri Aug 13 07:57:29 2021 From: midhunlaln66 at gmail.com (Midhunlal Nb) Date: Fri, 13 Aug 2021 13:27:29 +0530 Subject: Backup controller node Message-ID: Hi team, I have a rocky installed openstack environment and it is working fine.In my set up I have; 1 controller node,2 compute nodes and 1 storage node. Now we are planning to add 1 more controller node as backup.Is it possible to add 1 more controller node in existing set up? if it is possible ,anyone please share the procedure. Thanks & Regards Midhunlal N B +918921245637 -------------- next part -------------- An HTML attachment was scrubbed... URL: From marios at redhat.com Fri Aug 13 12:43:31 2021 From: marios at redhat.com (Marios Andreou) Date: Fri, 13 Aug 2021 15:43:31 +0300 Subject: [tripleo] Y cycle PTL nominations from 17th August Message-ID: Hello tripleo o/ in case you missed in, the OpenStack Y cycle election season is soon upon us starting 17th August [1] As previously mentioned in tripleo irc meetings I do not intend to run for a third cycle as ptl. I think it is healthy for the project to have new energy and ideas brought by a new ptl and we are very fortunate to have many capable candidates in our community who have not previously occupied that role. I'd like to encourage anyone who is considering this to read the info from [1] and in particular prepare a nomination [2]. Feel free to reach out to me if you have any questions or concerns. If you *are* thinking about it bear in mind there are many experienced people around that can and will help so ... how badly can it go ! ;) regards, marios [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-August/024093.html [2] https://governance.openstack.org/election/#how-to-submit-a-candidacy From amy at demarco.com Fri Aug 13 13:25:19 2021 From: amy at demarco.com (Amy Marrich) Date: Fri, 13 Aug 2021 08:25:19 -0500 Subject: [tripleo] Y cycle PTL nominations from 17th August In-Reply-To: References: Message-ID: Marios thank you for all your hard work over the last 2 cycles! Amy (spotz) On Fri, Aug 13, 2021 at 7:47 AM Marios Andreou wrote: > Hello tripleo o/ > > in case you missed in, the OpenStack Y cycle election season is soon > upon us starting 17th August [1] > > As previously mentioned in tripleo irc meetings I do not intend to run > for a third cycle as ptl. I think it is healthy for the project to > have new energy and ideas brought by a new ptl and we are very > fortunate to have many capable candidates in our community who have > not previously occupied that role. > > I'd like to encourage anyone who is considering this to read the info > from [1] and in particular prepare a nomination [2]. Feel free to > reach out to me if you have any questions or concerns. If you *are* > thinking about it bear in mind there are many experienced people > around that can and will help so ... how badly can it go ! ;) > > regards, marios > > [1] > http://lists.openstack.org/pipermail/openstack-discuss/2021-August/024093.html > [2] https://governance.openstack.org/election/#how-to-submit-a-candidacy > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.faulkner at verizonmedia.com Fri Aug 13 15:58:46 2021 From: jay.faulkner at verizonmedia.com (Jay Faulkner) Date: Fri, 13 Aug 2021 08:58:46 -0700 Subject: [ironic] Departure from full-time work on the project Message-ID: Hello everyone, As mentioned in the Ironic IRC meeting, I will no longer be working full time on OpenStack Ironic after this week. It is my intention to continue reviewing code for a small amount of time on the weekends until my context around the project becomes too stale. Working on OpenStack Ironic has been the greatest adventure of my career so far, but I'll mostly remember all the nice people I met along the way. Thanks, Jay Faulkner -------------- next part -------------- An HTML attachment was scrubbed... URL: From anyrude10 at gmail.com Fri Aug 13 06:56:36 2021 From: anyrude10 at gmail.com (Anirudh Gupta) Date: Fri, 13 Aug 2021 12:26:36 +0530 Subject: [Kolla][Kolla-Ansible] Ironic Node Cleaning Failed In-Reply-To: References: Message-ID: Hi All, I had a 900 GB hard disk on my Baremetal Node and it took approx *15 hours *to make the baremetal node come in *available* state from *clean_wait* state. Once the baremetal node came available, I was able to create a server and provision it with a user image. Is taking 15 hours to erase_device in clean_wait normal for a 900 GB hard disk in Ironic? Regards Anirudh Gupta On Mon, Aug 9, 2021 at 2:01 PM Anirudh Gupta wrote: > Hi Mark, > > Earlier I was passing the boot_mode as uefi while creating the baremetal > node. > On Kolla-Ansible Launchpad, I found some issues related to UEFI mode, so I > didn't pass the parameter. > > With IPXE and without passing UEFI boot mode parameter, my node started > cleaning. It connected with the TFTP server. > > But from the last 2 hours, the state is still in *clean_wait* only. > > The ramdisk and kernel images I used were the ones mentioned in the link > below > > > - > https://tarballs.openstack.org/ironic-python-agent/dib/files/ipa-centos8-master.kernel > - > https://tarballs.openstack.org/ironic-python-agent/dib/files/ipa-centos8-master.initramfs > > > For this I followed the latest kolla ansible document:- > > - > https://docs.openstack.org/kolla-ansible/latest/reference/bare-metal/ironic-guide.html > > > All I can see in *ironic-conductor* logs is: > > 2021-08-09 13:49:51.159 7 DEBUG ironic.drivers.modules.agent_base [-] > Heartbeat from node 8b1ec553-fbc9-4912-bd33-88afc41b8f81 heartbeat > /var/lib/kolla/venv/lib/python3.6/site-packages/ironic/drivers/modules/agent_base.py:641 > 2021-08-09 13:49:51.178 7 DEBUG ironic.drivers.modules.agent_client [-] > Fetching status of agent commands for node > 8b1ec553-fbc9-4912-bd33-88afc41b8f81 get_commands_status > /var/lib/kolla/venv/lib/python3.6/site-packages/ironic/drivers/modules/agent_client.py:310 > 2021-08-09 13:49:51.186 7 DEBUG ironic.drivers.modules.agent_client [-] > Status of agent commands for node 8b1ec553-fbc9-4912-bd33-88afc41b8f81: > get_clean_steps: result "{'clean_steps': {'GenericHardwareManager': > [{'step': 'erase_devices', 'priority': 10, 'interface': 'deploy', > 'reboot_requested': False, 'abortable': True}, {'step': > 'erase_devices_metadata', 'priority': 99, 'interface': 'deploy', > 'reboot_requested': False, 'abortable': True}, {'step': 'erase_pstore', > 'priority': 0, 'interface': 'deploy', 'reboot_requested': False, > 'abortable': True}, {'step': 'delete_configuration', 'priority': 0, > 'interface': 'raid', 'reboot_requested': False, 'abortable': True}, > {'step': 'create_configuration', 'priority': 0, 'interface': 'raid', > 'reboot_requested': False, 'abortable': True}, {'step': 'burnin_cpu', > 'priority': 0, 'interface': 'deploy', 'reboot_requested': False, > 'abortable': True}, {'step': 'burnin_disk', 'priority': 0, 'interface': > 'deploy', 'reboot_requested': False, 'abortable': True}, {'step': > 'burnin_memory', 'priority': 0, 'interface': 'deploy', 'reboot_requested': > False, 'abortable': True}, {'step': 'burnin_network', 'priority': 0, > 'interface': 'deploy', 'reboot_requested': False, 'abortable': True}]}, > 'hardware_manager_version': {'MellanoxDeviceHardwareManager': '1', > 'generic_hardware_manager': '1.1'}}", error "None"; execute_clean_step: > result "{'clean_result': None, 'clean_step': {'step': > 'erase_devices_metadata', 'priority': 99, 'interface': 'deploy', > 'reboot_requested': False, 'abortable': True, 'requires_ramdisk': True}}", > error "None"; execute_clean_step: result "None", error "None" > get_commands_status > /var/lib/kolla/venv/lib/python3.6/site-packages/ironic/drivers/modules/agent_client.py:342 > 2021-08-09 13:49:51.186 7 DEBUG ironic.drivers.modules.agent_base [-] *Clean > step still running for node 8b1ec553-fbc9-4912-bd33-88afc41b8f81:* None > _get_completed_command > /var/lib/kolla/venv/lib/python3.6/site-packages/ironic/drivers/modules/agent_base.py:267 > > It would be a great help if you could suggest some pointers. > > Regards > Anirudh Gupta > > > > > I tried > > On Mon, Aug 9, 2021 at 1:43 PM Mark Goddard wrote: > >> >> >> On Fri, 6 Aug 2021 at 13:49, Anirudh Gupta wrote: >> >>> Hi Dmitry, >>> >>> I tried taking TCPDUMP while the Baremetal Node was booting up and >>> looked for tftp protocols and found there was some "*File Not Found" *traces >>> for bootx64.efi >>> >>> [image: image.png] >>> >>> Then, I found a related post on openstack Discuss which suggested to >>> enable IPXE >>> >>> http://lists.openstack.org/pipermail/openstack-discuss/2019-October/010329.html >>> >>> After re-deploying the setup with IPXE enabled, i found similar traces >>> now for *ipxe.efi file* >>> >>> [image: image.png] >>> >>> Can you please now suggest what possibly could be a miss in >>> configuration and steps to resolve it. >>> >> >> Hi Anirudh, >> >> I'd suggest installing a tftp client on your machine and making some >> requests. The TFTP daemon runs in the ironic_pxe container, and TFTP files >> are served from /tftpboot in that container. >> >> Mark >> >>> >>> For your reference, I am attaching the complete tcpdump logs of both the >>> Scenarios >>> >>> Looking forward to hearing from you. >>> >>> Regards >>> Anirudh Gupta >>> >>> >>> >>> >>> >>> On Thu, Aug 5, 2021 at 4:56 PM Anirudh Gupta >>> wrote: >>> >>>> Hi Team, >>>> >>>> On further debugging, I found an error in neutron-server logs >>>> >>>> >>>> Failed to bind port 476d8175-ffc2-49ba-bb12-0a77c1f07e5f on host >>>> f4a43fa5-9c41-488e-a34d-714ae5a9d300 for vnic_type baremetal using segments >>>> [{'id': '1a5bbe96-2488-4971-925f-7c9346ba3ef5', 'network_type': 'flat', >>>> 'physical_network': 'physnet1', 'segmentation_id': None, 'network_id': >>>> '5b6cccec-ad86-4ed9-8d3c-72a31ec3a0d4'}] >>>> 2021-08-05 16:33:06.979 23 INFO neutron.plugins.ml2.plugin >>>> [req-54d11d51-7319-43ea-b70c-fe39d8aafe8a 21d6a238438e4294912746bcdc895e31 >>>> 3eca725754e1405eb178cc39bd0da3aa - default default] Attempt 9 to bind port >>>> 476d8175-ffc2-49ba-bb12-0a77c1f07e5f >>>> >>>> where 476d8175-ffc2-49ba-bb12-0a77c1f07e5f is the uuid of Baremetal Node >>>> >>>> However the port is created in openstack, but its state is down >>>> >>>> [ansible at localhost ~]$ openstack port list >>>> >>>> +--------------------------------------+------+-------------------+---------------------------------------------------------------------------+--------+ >>>> | ID | Name | MAC Address | >>>> Fixed IP Addresses | >>>> Status | >>>> >>>> +--------------------------------------+------+-------------------+---------------------------------------------------------------------------+--------+ >>>> | 07d6b83d-d83c-498f-8ba8-b4f21bef7249 | | fa:16:3e:38:05:9d | >>>> ip_address='10.0.1.200', subnet_id='7b72c158-2146-4bd6-893b-bd76b4a3e869' | >>>> ACTIVE | >>>> | 476d8175-ffc2-49ba-bb12-0a77c1f07e5f | | *98:f2:b3:3f:72:d8* | >>>> ip_address='10.0.1.202', subnet_id='7b72c158-2146-4bd6-893b-bd76b4a3e869' | *DOWN >>>> * | >>>> >>>> +--------------------------------------+------+-------------------+---------------------------------------------------------------------------+--------+ >>>> >>>> *98:f2:b3:3f:72:d8 *is the mac address of my Baremetal Node on which >>>> PXE is enabled. >>>> >>>> Can someone please help in resolving this issue. >>>> >>>> *Issue:* >>>> *Node goes in clean_failed from clean_wait.* >>>> >>>> Regards >>>> Anirudh Gupta >>>> >>>> On Tue, Aug 3, 2021 at 8:32 PM Anirudh Gupta >>>> wrote: >>>> >>>>> Hi Dmitry, >>>>> >>>>> I might be wrong, but as per my understanding if there would be an >>>>> issue in dnsmasq, then IP 20.20.20.10 would not have been assigned to the >>>>> machine. >>>>> >>>>> TCPDUMP logs are as below: >>>>> >>>>> 20:16:58.938089 IP controller.bootps > 255.255.255.255.bootpc: >>>>> BOOTP/DHCP, Reply, length 312 >>>>> 20:17:02.765291 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: >>>>> BOOTP/DHCP, Request from 98:f2:b3:3f:72:e5 (oui Unknown), length 359 >>>>> 20:17:02.766303 IP controller.bootps > 255.255.255.255.bootpc: >>>>> BOOTP/DHCP, Reply, length 312 >>>>> 20:17:26.944378 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: >>>>> BOOTP/DHCP, Request from 98:f2:b3:3f:72:e5 (oui Unknown), length 347 >>>>> 20:17:26.944756 IP controller.bootps > 255.255.255.255.bootpc: >>>>> BOOTP/DHCP, Reply, length 312 >>>>> 20:17:30.763627 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: >>>>> BOOTP/DHCP, Request from 98:f2:b3:3f:72:e5 (oui Unknown), length 359 >>>>> 20:17:30.764620 IP controller.bootps > 255.255.255.255.bootpc: >>>>> BOOTP/DHCP, Reply, length 312 >>>>> 20:17:54.938791 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: >>>>> BOOTP/DHCP, Request from 98:f2:b3:3f:72:e5 (oui Unknown), length 347 >>>>> >>>>> Also the neutron dnsmasq logs and ironic inspector logs are attached >>>>> in the mail. >>>>> >>>>> Regards >>>>> Anirudh Gupta >>>>> >>>>> >>>>> On Tue, Aug 3, 2021 at 7:29 PM Dmitry Tantsur >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> You need to check the dnsmasq logs (there are two dnsmasqs: from >>>>>> neutron and from ironic-inspector). tcpdump may also help to determine >>>>>> where the packages are lost. >>>>>> >>>>>> Dmitry >>>>>> >>>>>> On Fri, Jul 30, 2021 at 10:29 PM Anirudh Gupta >>>>>> wrote: >>>>>> >>>>>>> Hi Dmitry >>>>>>> >>>>>>> Thanks for your time. >>>>>>> >>>>>>> My system is getting IP 20.20.20.10 which is in the range defined in >>>>>>> ironic_dnsmasq_dhcp_range field under globals.yml file. >>>>>>> >>>>>>> ironic_dnsmasq_dhcp_range: "20.20.20.10,20.20.20.100" >>>>>>> >>>>>>> And in the cleaning network (public1), the range defined is >>>>>>> 20.20.20.150-20.20.20.200 >>>>>>> >>>>>>> As per my understanding, these 2 ranges should be mutually exclusive. >>>>>>> >>>>>>> Please suggest if my understanding is not correct. >>>>>>> >>>>>>> Any suggestions what should I do to resolve this issue? >>>>>>> >>>>>>> Regards >>>>>>> Anirudh Gupta >>>>>>> >>>>>>> >>>>>>> On Sat, 31 Jul, 2021, 12:06 am Dmitry Tantsur, >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Jul 29, 2021 at 6:05 PM Anirudh Gupta >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi Team, >>>>>>>>> >>>>>>>>> In to the email below, I have some updated information:- >>>>>>>>> >>>>>>>>> Earlier the allocation range mentioned in " >>>>>>>>> *ironic_dnsmasq_dhcp_range*" in globals.yml had an overlapping >>>>>>>>> range with the cleaning network, due to which there was some issue in >>>>>>>>> receiving the DHCP request >>>>>>>>> >>>>>>>>> After creating a cleaning network with a separate allocation >>>>>>>>> range, I am successfully getting IP allocated to my Baremetal Node >>>>>>>>> >>>>>>>>> - openstack subnet create subnet1 --network public1 >>>>>>>>> --subnet-range 20.20.20.0/24 --allocation-pool >>>>>>>>> start=20.20.20.150,end=20.20.20.200 --ip-version=4 --gateway=20.20.20.1 >>>>>>>>> --dhcp >>>>>>>>> >>>>>>>>> >>>>>>>>> [image: image.png] >>>>>>>>> >>>>>>>>> After getting the IP, there is no further action on the node. From >>>>>>>>> "*clean_wait*", it goes into "*clean_failed*" state after around >>>>>>>>> half an hour. >>>>>>>>> >>>>>>>> >>>>>>>> The IP address is not from the cleaning range, it may come from >>>>>>>> inspection. You probably need to investigate your network topology, maybe >>>>>>>> use tcpdump. >>>>>>>> >>>>>>>> Unfortunately, I'm not fluent in Kolla to say if it can be a bug or >>>>>>>> not. >>>>>>>> >>>>>>>> Dmitry >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> On verifying the logs, I could see the below error messages >>>>>>>>> >>>>>>>>> >>>>>>>>> - In */var/log/kolla/ironic/ironic-conductor.log*, we observed >>>>>>>>> the following error: >>>>>>>>> >>>>>>>>> ERROR ironic.conductor.utils [-] Cleaning for node >>>>>>>>> 3a56748e-a8ca-4dec-a332-ace18e6d494e failed. *Timeout reached >>>>>>>>> while cleaning the node. Please check if the ramdisk responsible for the >>>>>>>>> cleaning is running on the node. Failed on step {}.* >>>>>>>>> >>>>>>>>> >>>>>>>>> Note : For Cleaning the node, we have used the below images >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> https://tarballs.openstack.org/ironic-python-agent/dib/files/ipa-centos8-master.kernel >>>>>>>>> >>>>>>>>> >>>>>>>>> https://tarballs.openstack.org/ironic-python-agent/dib/files/ipa-centos8-master.initramfs >>>>>>>>> >>>>>>>>> >>>>>>>>> - In /var/log/kolla/nova/nova-compute-ironic.log, we observed >>>>>>>>> the error >>>>>>>>> >>>>>>>>> ERROR nova.compute.manager >>>>>>>>> [req-810ffedf-3343-471c-94db-85411984e6cc - - - - -] No compute node record >>>>>>>>> for host controller-ironic: >>>>>>>>> nova.exception_Remote.ComputeHostNotFound_Remote: Compute host >>>>>>>>> controller-ironic could not be found. >>>>>>>>> >>>>>>>>> >>>>>>>>> Can someone please help in this regard? >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Anirudh Gupta >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Jul 27, 2021 at 12:52 PM Anirudh Gupta < >>>>>>>>> anyrude10 at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Hi Team, >>>>>>>>>> >>>>>>>>>> We have deployed 2 node kolla ansible *12.0.0* in order to >>>>>>>>>> deploy openstack *wallaby* release. We have also enabled ironic >>>>>>>>>> in order to provision the bare metal nodes. >>>>>>>>>> >>>>>>>>>> On each server we have 3 nics >>>>>>>>>> >>>>>>>>>> - *eno1* - OAM for external connectivity and endpoint's >>>>>>>>>> publicURL >>>>>>>>>> - *eno2* - Mgmt for internal communication between various >>>>>>>>>> openstack services. >>>>>>>>>> - *ens2f0* - Data Interface >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Corresponding to this we have defined the following fields in >>>>>>>>>> globals.yml >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - kolla_base_distro: "centos" >>>>>>>>>> - kolla_install_type: "source" >>>>>>>>>> - openstack_release: "wallaby" >>>>>>>>>> - network_interface: "eno2" # >>>>>>>>>> MGMT interface >>>>>>>>>> - kolla_external_vip_interface: "eno1" # OAM >>>>>>>>>> Interface >>>>>>>>>> - kolla_internal_vip_address: "192.168.10.3" # MGMT Subnet >>>>>>>>>> free ip >>>>>>>>>> - kolla_external_vip_address: "10.0.1.136" # OAM subnet >>>>>>>>>> free IP >>>>>>>>>> - neutron_external_interface: "ens2f0" # Data >>>>>>>>>> Interface >>>>>>>>>> - enable_neutron_provider_networks: "yes" >>>>>>>>>> >>>>>>>>>> Note: Only relevant fields are being shown in this query >>>>>>>>>> >>>>>>>>>> Also, for ironic following fields have been defined in globals.yml >>>>>>>>>> >>>>>>>>>> - enable_ironic: "yes" >>>>>>>>>> - enable_ironic_neutron_agent: "{{ enable_neutron | bool and >>>>>>>>>> enable_ironic | bool }}" >>>>>>>>>> - enable_horizon_ironic: "{{ enable_ironic | bool }}" >>>>>>>>>> - ironic_dnsmasq_interface: "*ens2f0*" >>>>>>>>>> # Data interface >>>>>>>>>> - ironic_dnsmasq_dhcp_range: "20.20.20.10,20.20.20.100" >>>>>>>>>> - ironic_dnsmasq_boot_file: "pxelinux.0" >>>>>>>>>> - ironic_cleaning_network: "public1" >>>>>>>>>> - ironic_dnsmasq_default_gateway: "20.20.20.1" >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> After successful deployment, a flat provider network with the >>>>>>>>>> name public1 is being created in openstack using the below commands: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - openstack network create public1 --provider-network-type >>>>>>>>>> flat --provider-physical-network physnet1 >>>>>>>>>> - openstack subnet create subnet1 --network public1 >>>>>>>>>> --subnet-range 20.20.20.0/24 --allocation-pool >>>>>>>>>> start=20.20.20.10,end=20.20.20.100 --ip-version=4 --gateway=20.20.20.1 >>>>>>>>>> --dhcp >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Issue/Queries: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - Is the configuration done in globals.yml correct or is >>>>>>>>>> there anything else that needs to be done in order to separate control and >>>>>>>>>> data plane traffic? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - Also I have set automated_cleaning as "true" in >>>>>>>>>> ironic-conductor conatiner settings.But after creating the baremetal node, >>>>>>>>>> we run "node manage" command which runs successfully. Running "*openstack >>>>>>>>>> baremetal node provide "* command powers on the >>>>>>>>>> machine, sets the boot mode on Network Boot but no DHCP request for that >>>>>>>>>> particular mac is obtained on the controller. Is there anything I am >>>>>>>>>> missing that needs to be done in order to make ironic work? >>>>>>>>>> >>>>>>>>>> Note: I have also verified that the nic is PXE enabled in system >>>>>>>>>> configuration setting >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Anirudh Gupta >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, >>>>>>>> Commercial register: Amtsgericht Muenchen, HRB 153243, >>>>>>>> Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, >>>>>>>> Michael O'Neill >>>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, >>>>>> Commercial register: Amtsgericht Muenchen, HRB 153243, >>>>>> Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, >>>>>> Michael O'Neill >>>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 38285 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 185546 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 200447 bytes Desc: not available URL: From anyrude10 at gmail.com Fri Aug 13 09:13:51 2021 From: anyrude10 at gmail.com (Anirudh Gupta) Date: Fri, 13 Aug 2021 14:43:51 +0530 Subject: [Kolla-Ansible][Ironic] Baremetal node Cleaning fails in UEFI mode, but succeeds in Legacy Bios Mode Message-ID: Hi Team, I am trying to provision Baremetal node using IRONIC with KOLLA-ANSIBLE. I have enabled the support of "IPXE" in kolla-ansible as well. I am getting an issue that when my baremetal node is booted in UEFI Mode, it is not able to find file *"ipxe.efi"* as a result of which cleaning of the node fails [image: image.png] But when I change the BIOS Mode of my Baremetal Node to Legacy.BIOS, it looks for the file "*undionly.kpxe"* for which the acknowledgment is received and Data Packets are transferred. Eventually the cleaning of node is also a success. [image: image.png] Is there any limitation of IRONIC or KOLLA-ANSIBLE side that provisioning of Baremetal Node can only be done in Legacy Bios Mode? For bare metal provisioning in UEFI mode, is there any other parameter that needs to be enabled. Regards Anirudh Gupta -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 200447 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 91313 bytes Desc: not available URL: From chris at lyonsgroup.family Fri Aug 13 11:53:23 2021 From: chris at lyonsgroup.family (Chris Lyons) Date: Fri, 13 Aug 2021 11:53:23 +0000 Subject: Octavia In-Reply-To: <76217647-3770-4f56-d9ca-c0ec05899749@gmail.com> References: <26e5229a-0584-c5f5-e85f-6547b158dc47@gmail.com> <3088a3b9-f683-3117-9e67-eec1fb74c3eb@gmail.com> <76217647-3770-4f56-d9ca-c0ec05899749@gmail.com> Message-ID: I got close with my approach but I wasn’t sure how to get the network interface I created for Octavia to map to physnet2 to tell the kolla Octavia LB mgmt. subnet to use it. So….Ill go with your approach. It sounds like you have an all-in-one setup….Im going through the steps with a multinode setup. How do I find the DHCP servers port? This is my output from this command. I used network01 host as that has the OVS stuff on it. Network02 also has OVS… [root at kolla ~]# ssh network01 sudo docker exec openvswitch_vswitchd ovsdb-client dump unix:/var/run/openvswitch/db.sock Open_vSwitch Port name tag Port table name tag -------------- --- br-ex [] br-int [] br-tun [] eth1 [] int-br-ex [] patch-int [] patch-tun [] phy-br-ex [] qg-dd91a0d9-e7 2 qr-1fb72495-df 3 qr-a7bcbd91-14 4 qr-cd05b21c-b7 6 qr-e9938869-17 5 tap12d3571c-7f 1 tapd6c55c73-05 4 tape62e9ed6-a7 3 vxlan-0a00c817 [] vxlan-0a00c81b [] [root at kolla ~]# From: Bernd Bausch Date: Tuesday, August 10, 2021 at 9:38 PM To: Chris Lyons , openstack-discuss Subject: Re: Octavia A flat network for LB management should work as well. However, the LB management network has nothing to do with your VMs (except the amphorae), and it's unclear to me what ports you are adding to them and the Neutron router. There is no router for a flat network. You seem to imply that your machines (controllers, computes) are virtual. My experience with Kolla is also in a virtual environment. I had to abandon VLAN or flat LB management networks because I was not competent enough to solve the networking problems outside of Kolla and went for the tenant network solution that I shared. Bernd On 2021/08/10 9:31 PM, Chris Lyons wrote: Thank you! I am trying the path of adding a separate physical (although its really virtual..) network that will be exclusively for lb-mgmt….that would work also, correct? I added a port to my virtual router and the added a corresponding port to each openstack vm. It sounds like only control and compute nodes need it but I was going to add it to everything to start and then eliminate one by one once it worked. Would that approach also work? From: Bernd Bausch Date: Tuesday, August 10, 2021 at 2:39 AM To: Chris Lyons , openstack-discuss at lists.openstack.org Subject: Re: Octavia The stacktrace shows that Octavia can't reach an Amphora. I suppose you get this log when trying to create a loadbalancer? If so, most likely the Amphora management network is not set up correctly. The difficulty is that Octavia workers, which are processes running on the controllers, need to have access to the same management network as the Amphora instances. If you implement the management network as a normal tenant network, some non-trivial manual Openvswitch configuration is required. See https://docs.openstack.org/octavia/latest/install/install-ubuntu.html#install-and-configure-components for instructions. In production settings, usually a VLAN is used, which is easy to access from controller processes. I succeeded running Octavia on a Kolla cluster with three-way controllers, with a tenant network (VXLAN-based) for amphora management. My notes are attached (they are tailored to my configuration, of course). Bernd. On 2021/08/09 10:57 AM, Chris Lyons wrote: Well…it gets. A lot further…. I see this error now…. Im looking around to see if it’s a security group missing or if there is some other setting I missed. Im not seeing any scripts to prep the env…usually there is something like that if it’s a security group…anyone know? ... 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker Traceback (most recent call last): 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker File "/usr/lib/python3.6/site-packages/taskflow/engines/action_engine/executor.py", line 53, in _execute_task 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker result = task.execute(**arguments) 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker File "/usr/lib/python3.6/site-packages/octavia/controller/worker/v1/tasks/amphora_driver_tasks.py", line 424, in execute 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker amp_info = self.amphora_driver.get_info(amphora) 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker File "/usr/lib/python3.6/site-packages/octavia/amphorae/drivers/haproxy/rest_api_driver.py", line 373, in get_info 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker amphora, raise_retry_exception=raise_retry_exception) 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker File "/usr/lib/python3.6/site-packages/octavia/amphorae/drivers/haproxy/rest_api_driver.py", line 106, in _populate_amphora_api_version 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker raise_retry_exception=raise_retry_exception)['api_version'] 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker File "/usr/lib/python3.6/site-packages/octavia/amphorae/drivers/haproxy/rest_api_driver.py", line 744, in get_api_version 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker raise_retry_exception=raise_retry_exception) 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker File "/usr/lib/python3.6/site-packages/octavia/amphorae/drivers/haproxy/rest_api_driver.py", line 738, in request 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker raise driver_except.TimeOutException() 2021-08-08 21:22:35.965 27 ERROR octavia.controller.worker.v1.controller_worker octavia.amphorae.driver_exceptions.exceptions.TimeOutException: contacting the amphora timed out ... This email has been scanned by Inbound Shield™. -------------- next part -------------- An HTML attachment was scrubbed... URL: From DHilsbos at performair.com Fri Aug 13 16:25:03 2021 From: DHilsbos at performair.com (DHilsbos at performair.com) Date: Fri, 13 Aug 2021 16:25:03 +0000 Subject: [victoria][ops][horizon][neutron] Network not available to use by Members in Horizon Message-ID: <0670B960225633449A24709C291A525251C78C29@COM03.performair.local> All; We just discovered, this morning, that Members of one of our projects can't see the project's network, in order to use it in Instance creation. If an Administrator creates a Port, the Member user can then use it to create an Instance. Most of our activity to this point has been by Administrators, this is the first time we've opened a project up to users with the Member level. Is this expected behavior? Thank you, Dominic L. Hilsbos, MBA Vice President - Information Technology Perform Air International Inc. DHilsbos at PerformAir.com www.PerformAir.com From alan.davis at apogee-research.com Fri Aug 13 16:49:25 2021 From: alan.davis at apogee-research.com (Alan Davis) Date: Fri, 13 Aug 2021 12:49:25 -0400 Subject: [rocky][cinder][lvm] VM LVM leakage to packstack host OS Message-ID: All, I have an issue with LVM on a rocky packstack installation where the LVM constructs inside the VMs running on the server "leak" into the host OS LVM configuration. Here's the listing of the errors from the OS: [root at stack2 log(keystone_apg-project)]# pvs WARNING: Device for PV ILdbcY-VFCm-fnH6-Y3jc-pdWZ-fnl8-PH3TPe not found or rejected by a filter. WARNING: Device for PV yZy8Xk-foKT-ovjV-0EZv-VxEM-GqiP-WH7k53 not found or rejected by a filter. Couldn't find device with uuid ILdbcY-VFCm-fnH6-Y3jc-pdWZ-fnl8-PH3TPe. Couldn't find device with uuid yZy8Xk-foKT-ovjV-0EZv-VxEM-GqiP-WH7k53. PV VG Fmt Attr PSize PFree /dev/md0 cinder-volumes lvm2 a-- <9.10t 4.87t /dev/sdaa pub_vg lvm2 a-- <250.00g 0 /dev/sdac apg-git-encrypted_vg lvm2 a-- <30.00g 0 /dev/sdah encrypted_vg lvm2 a-- <60.00g <60.00g /dev/sdb2 centos_stack2 lvm2 a-- 74.00g 0 [unknown] encrypted_vg lvm2 a-m <60.00g 0 [unknown] encrypted_vg lvm2 a-m <100.00g <100.00g Here are the current cinder.conf lines that seem relevant: # Type of LVM volumes to deploy; (default, thin, or auto). Auto defaults to # thin if thin is supported. (string value) # Possible values: # default - # thin - # auto - lvm_type = default # LVM conf file to use for the LVM driver in Cinder; this setting is ignored if # the specified file does not exist (You can also specify 'None' to not use a # conf file even if one exists). (string value) #lvm_conf_file = /etc/cinder/lvm.conf # Suppress leaked file descriptor warnings in LVM commands. (boolean value) #lvm_suppress_fd_warnings = false I think there are several things going on here : duplicate VG names causing LVM to see UUID/name conflicts and "leakage" of LVM data that cinder should be managing to the OS level. What do I need to change in my configuration to fix this and avoid problems in the future? Thanks -- Alan Davis Principal System Administrator Apogee Research LLC Office : 571.384.8941 x26 Cell : 410.701.0518 -------------- next part -------------- An HTML attachment was scrubbed... URL: From openinfradn at gmail.com Fri Aug 13 16:53:17 2021 From: openinfradn at gmail.com (open infra) Date: Fri, 13 Aug 2021 22:23:17 +0530 Subject: Need a help to recover Openstack Message-ID: Hi, Openstack was failed and noticed that mariadb-server-1 pod is failing. openstack mariadb-server-0 0/1 Running openstack mariadb-server-1 0/1 CrashLoopBackOff I managed to get logs of each pod. mariadb-server-0 log: https://paste.opendev.org/show/808070/ and https://paste.opendev.org/show/808071/ mariadb-server-1 log: https://paste.opendev.org/show/808067/ I highly appreciate if I can get a hint or steps to resolve this issue. OpenStack is deployed on STX. Regards, Danishka -------------- next part -------------- An HTML attachment was scrubbed... URL: From openinfradn at gmail.com Fri Aug 13 16:58:10 2021 From: openinfradn at gmail.com (open infra) Date: Fri, 13 Aug 2021 22:28:10 +0530 Subject: Need a help to recover Openstack In-Reply-To: References: Message-ID: Here is the describe pod output for the failing pod. https://paste.opendev.org/show/808076/ On Fri, Aug 13, 2021 at 10:23 PM open infra wrote: > Hi, > > > Openstack was failed and noticed that mariadb-server-1 pod is failing. > > > openstack mariadb-server-0 0/1 Running > > openstack mariadb-server-1 0/1 CrashLoopBackOff > > > I managed to get logs of each pod. > > > mariadb-server-0 log: > > https://paste.opendev.org/show/808070/ > > and > > https://paste.opendev.org/show/808071/ > > > mariadb-server-1 log: > > https://paste.opendev.org/show/808067/ > > > I highly appreciate if I can get a hint or steps to resolve this issue. > > > OpenStack is deployed on STX. > > > Regards, > > Danishka > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ildiko.vancsa at gmail.com Fri Aug 13 17:12:31 2021 From: ildiko.vancsa at gmail.com (Ildiko Vancsa) Date: Fri, 13 Aug 2021 10:12:31 -0700 Subject: Need a help to recover Openstack In-Reply-To: References: Message-ID: <6D52275A-7ACF-48F1-97A8-49FD389E99EF@gmail.com> Hi Danishka, The issue you’re facing seems to be originating from how MariaDB gets deployed in StarlingX, at least based on a quick glance at the logs. In that sense it might be better to ask that community. Have you tried that already? Thanks and Best Regards, Ildikó > On Aug 13, 2021, at 09:58, open infra wrote: > > Here is the describe pod output for the failing pod. > https://paste.opendev.org/show/808076/ > > On Fri, Aug 13, 2021 at 10:23 PM open infra wrote: > Hi, > > Openstack was failed and noticed that mariadb-server-1 pod is failing. > > openstack mariadb-server-0 0/1 Running > openstack mariadb-server-1 0/1 CrashLoopBackOff > > I managed to get logs of each pod. > > mariadb-server-0 log: > https://paste.opendev.org/show/808070/ > and > https://paste.opendev.org/show/808071/ > > mariadb-server-1 log: > https://paste.opendev.org/show/808067/ > > I highly appreciate if I can get a hint or steps to resolve this issue. > > OpenStack is deployed on STX. > > Regards, > Danishka > From haleyb.dev at gmail.com Fri Aug 13 17:36:57 2021 From: haleyb.dev at gmail.com (Brian Haley) Date: Fri, 13 Aug 2021 13:36:57 -0400 Subject: [neutron][stable] Nominate Lajos Katona to the neutron-stable-maint team In-Reply-To: <4154938.lVMuQLOT2H@p1> References: <4154938.lVMuQLOT2H@p1> Message-ID: +1 from me. Sorry for the late vote. -Brian On 8/5/21 5:50 AM, Slawek Kaplonski wrote: > Hi, > > I would like to nominate Lajos Katona as a Neutron stable core reviewer. Lajos > is core in Neutron since long time. He is maintaining many stadium projects as > well as he is very active in the main Neutron project. He helps us a lot with > keeping stable branches healthy (especially for stadium projects, but not > only). > During that time he has proven already his knowledge about Neutron and Neutron > stadium projects as well as knowledge of the stable branches rules. > > I will keep this nomination open for about 1 week. After that if there will be > no votes agains, I will ask stable-maint-core team to add Lajos to the > neutron-stable-maint team. > From mnaser at vexxhost.com Fri Aug 13 17:57:03 2021 From: mnaser at vexxhost.com (Mohammed Naser) Date: Fri, 13 Aug 2021 13:57:03 -0400 Subject: Need a help to recover Openstack In-Reply-To: <6D52275A-7ACF-48F1-97A8-49FD389E99EF@gmail.com> References: <6D52275A-7ACF-48F1-97A8-49FD389E99EF@gmail.com> Message-ID: I’d delete all 3 pods and let OSH rebuild the MariaDB cluster :) On Fri, Aug 13, 2021 at 1:16 PM Ildiko Vancsa wrote: > Hi Danishka, > > The issue you’re facing seems to be originating from how MariaDB gets > deployed in StarlingX, at least based on a quick glance at the logs. In > that sense it might be better to ask that community. Have you tried that > already? > > Thanks and Best Regards, > Ildikó > > > > On Aug 13, 2021, at 09:58, open infra wrote: > > > > Here is the describe pod output for the failing pod. > > https://paste.opendev.org/show/808076/ > > > > On Fri, Aug 13, 2021 at 10:23 PM open infra > wrote: > > Hi, > > > > Openstack was failed and noticed that mariadb-server-1 pod is failing. > > > > openstack mariadb-server-0 0/1 Running > > openstack mariadb-server-1 0/1 CrashLoopBackOff > > > > I managed to get logs of each pod. > > > > mariadb-server-0 log: > > https://paste.opendev.org/show/808070/ > > and > > https://paste.opendev.org/show/808071/ > > > > mariadb-server-1 log: > > https://paste.opendev.org/show/808067/ > > > > I highly appreciate if I can get a hint or steps to resolve this issue. > > > > OpenStack is deployed on STX. > > > > Regards, > > Danishka > > > > > -- Mohammed Naser VEXXHOST, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From akekane at redhat.com Fri Aug 13 18:25:53 2021 From: akekane at redhat.com (Abhishek Kekane) Date: Fri, 13 Aug 2021 23:55:53 +0530 Subject: [all] SQLAlchemy 2.0 and coming ORM apocalypse In-Reply-To: <3c334098-a704-441e-b1e3-a27cc0459566@www.fastmail.com> References: <3c6449e1f3529b85fdd2d17459adb3dc9d3add9f.camel@redhat.com> <3c334098-a704-441e-b1e3-a27cc0459566@www.fastmail.com> Message-ID: Now glance is hit with different SQLA related error, We are tracking it here [1]. [1] https://bugs.launchpad.net/glance/+bug/1939716 Thanks & Best Regards, Abhishek Kekane On Fri, Aug 13, 2021 at 5:27 AM Mike Bayer wrote: > didn't see the main docs linked so the story starts at SQLA's migration > docs. > > starting w/ 1.4 which has all of 2.0's internals ready to go: > > https://docs.sqlalchemy.org/en/14/changelog/migration_14.html > > then 2.0 which includes 1.x->2.0 migration notes: > > https://docs.sqlalchemy.org/en/14/changelog/migration_20.html > > we spent a lot of time trying to make this process smooth. it has both a > few ideas from how py2->py3 worked (warnings mode) and also does some > things intentionally the opposite of how py2/3 did it (you can run a > codebase that is compatible with 1.4 and 2.0 at the same time). > > > > > On Thu, Aug 12, 2021, at 12:00 PM, Stephen Finucane wrote: > > tl;dr: If you haven't already started looking at SQLAlchemy 2.0 > compatibility > and/or are still using sqlalchemy-migrate, you probably have work to do. > > As you can guess from $subject, there's a new major version of SQLAlchemy > in the > pipeline. The good news: it cleans up a lot of cruft and makes a lot of > things > such as session management more explicit and verbose, with the idea being > that > this should avoid a lot of gotchas and foot-gun moments. The bad news: the > changes are pretty extensive, and virtually anyone that uses SQLAlchemy, > which > is to say every (?) OpenStack service out there, will likely have to make > changes. > > This change will likely have a couple of impacts for users: > > # Breaking changes in oslo.db > > The oslo devs have been steadily working through the many errors that > oslo.db is > currently emitting when SQLAlchemy 2.0 deprecation warnings are turned on. > The > patches (which is not yet complete) to address these can be found here > [1]. As a > result of these changes, a number of oslo.db APIs are likely to start > performing > slightly differently, and many more may be deprecated and eventually > removed. An > example of the kind of change you can expect to see can be found in this > glance > patch [2]. We will work to minimize these changes but some will be > unavoidable > once sqlalchemy 2.0 actually arrives. > > # Breaking changes in your own project > > If oslo.db seeing breaking changes because of SQLAlchemy 2.0, you can be > sure > that you're going to see some too. Fortunately, there are ways you can get > ahead > of this. Turning SADeprecationWarning warnings into errors for your own > module, > as we've done for oslo.db [3][4] seems a sensible pattern to weed out these > issues. > > As an aside, enabling warnings as errors seems to be a generally good idea > in a > unit test environment. It's usually a lot easier to address these things > as they > pop up that when things are finally removed and stuff explodes. To each > their > own though, of course. > > # The long prophesied death of sqlalchemy-migrate > > The lack of maintenance on sqlalchemy-migrate has already been well > documented > [5], however, SQLAlchemy 2.0 is likely to be the thing that finally puts > the > nail in sqlalchemy-migrate's coffin. I've been working on migrating the > last few > laggards still using sqlalchemy-migrate and have successfully removed all > traces > of it from glance (thanks, glance-core!), while the nova and cinder > patches are > making reasonable progress (though I do wish it was faster). The only > remaining > "core" project to be migrated is keystone. This proved a little too > complicated > for me to do in the limited time I have to work on these things, and I'm > in the > middle of a role change in my day job so my time to work on upstream > OpenStack > will be decreasing much further going forward (though not to zero, I'm > hoping). > Fortunately, there's quite a bit of prior art available now that people can > follow when migrating stuff [6]. > > Related to the oslo.db changes: everything related to sqlalchemy-migrate in > oslo.db should be deprecated by the next oslo.db release, and I suspect > we'll be > pretty aggressive in pruning these. Based on codesearch.o.o, this will have > impacts for at least keystone and cinder. > > # A chance to evaluate all things DB > > One positive out of this is that the changes necessary may be broad enough > to > take the opportunity to re-evaluate decisions made regarding your DB layer. > We've been doing this in nova, moving lots of things about to clear up the > distinction between the main and API DBs and to reduce lots of tech debt > that > had built up in 'nova.db'. Consider using the opportunity to do the if > possible. > > --- > > Hopefully this has been useful. If you have questions about any of the > above, > please reach out and I'll do my best to answer them. > > Cheers, > Stephen > > > [1] > https://review.opendev.org/q/topic:%2522sqlalchemy-20%2522+(status:open+OR+status:merged)+project:openstack/oslo.db > [2] https://review.opendev.org/c/openstack/glance/+/804406 > [3] > https://github.com/openstack/oslo.db/commit/40bce5a2baf75dc87dd591e0f71a00f221a2ba92 > [4] > https://github.com/openstack/oslo.db/commit/4c1eb966c08d29214c1905e74965f4109f41b013 > [5] > http://lists.openstack.org/pipermail/openstack-discuss/2021-February/020672.html > [6] > https://review.opendev.org/q/topic:%22bp%252Fremove-sqlalchemy-migrate%22+(status:open%20OR%20status:merged) > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cboylan at sapwetik.org Fri Aug 13 18:33:08 2021 From: cboylan at sapwetik.org (Clark Boylan) Date: Fri, 13 Aug 2021 11:33:08 -0700 Subject: [all] SQLAlchemy 2.0 and coming ORM apocalypse In-Reply-To: <3c334098-a704-441e-b1e3-a27cc0459566@www.fastmail.com> References: <3c6449e1f3529b85fdd2d17459adb3dc9d3add9f.camel@redhat.com> <3c334098-a704-441e-b1e3-a27cc0459566@www.fastmail.com> Message-ID: <36234db1-646e-4af6-a03d-466c56966075@www.fastmail.com> On Thu, Aug 12, 2021, at 4:47 PM, Mike Bayer wrote: > didn't see the main docs linked so the story starts at SQLA's migration docs. > > starting w/ 1.4 which has all of 2.0's internals ready to go: > > https://docs.sqlalchemy.org/en/14/changelog/migration_14.html > > then 2.0 which includes 1.x->2.0 migration notes: > > https://docs.sqlalchemy.org/en/14/changelog/migration_20.html > > we spent a lot of time trying to make this process smooth. it has both > a few ideas from how py2->py3 worked (warnings mode) and also does some > things intentionally the opposite of how py2/3 did it (you can run a > codebase that is compatible with 1.4 and 2.0 at the same time). > > Thank you for those docs. I used them yesterday to kickstart this process for Zuul. One thing I ran into is that the Python docs on warnings filters [0] are completely wrong [1][2][3] about being able to use regular expressions there. At least for filters supplied via environment variables or command line flags. I suspect this is why the migration docs suggest you do an internal filter instead, but wanted to call this out if anyone else ends up spending far too much time trying to understand why this isn't working. [0] https://docs.python.org/3/library/warnings.html#the-warnings-filter [1] https://bugs.python.org/issue34624 [2] https://github.com/python/cpython/pull/9358 [3] https://github.com/python/cpython/commit/62ec638 From gmann at ghanshyammann.com Fri Aug 13 22:21:38 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Fri, 13 Aug 2021 17:21:38 -0500 Subject: [all][tc] What's happening in Technical Committee: summary 13th Aug, 21: Reading: 5 min Message-ID: <17b419b3fc2.1030ad2b8244884.8402445735424754694@ghanshyammann.com> Hello Everyone, Here is this week's summary of the Technical Committee activities. 1. What we completed this week: ========================= * Project Skyline(dashboard) pre-proposal discussion. ** TC discussed the pre-proposal required things for the skyline team need to prepare before the project proposal. Kendall sent it on ML[1]. We will wait for the proposal which will have more implementation details. 2. TC Meetings: ============ * TC held this week meeting on Thursday; you can find the full meeting logs in the below link: - https://meetings.opendev.org/meetings/tc/2021/tc.2021-08-12-15.00.log.html * We will have next week's meeting on Aug 19th, Thursday 15:00 UTC[2]. 3. Activities In progress: ================== TC Tracker for Xena cycle ------------------------------ TC is using the etherpad[3] for Xena cycle working item. We will be checking and updating the status biweekly in the same etherpad. Open Reviews ----------------- * Two open reviews for ongoing activities[4]. Combined PTL/TC Election Season for Yoga ---------------------------------------------------- * Yoga cycle election for PTL and TC will be held combined. * The nomination period officially begins August 17, 2021 23:45. * Please read Helena email for more details[5] Murano Project retirement proposal ------------------------------------------ * During a check on project health, we found that Murano is not active anymore. * No code change in Xena cycle last patch merged 4 months ago: https://review.opendev.org/c/openstack/murano/+/783446 * Core team or PTL are not reachable. * In the TC meeting, we decided to start the proposal for its retirement. If you are using it or interested in maintaining it, please respond to mnaser email on openstack-discuss ML[6] Wallaby testing runtime for centos8 vs centos8-stream ----------------------------------------------------------------- * We continue to discuss it in the TC meeting and we agreed: ** Devstack centos8-stream support can be backported to stable/wallaby with the centos8-stream job. ** We will discuss in PTG whether we should update the TC documentation on testing runtime for stable branch or what to do when centos8 is EOL (in Dec 2021). Project updates ------------------- * Retiring js-openstack-lib [7] Yoga release community-wide goal ----------------------------------------- * Please add the possible candidates in this etherpad [8]. * Current status: Proposed "Secure RBAC" to select for Yoga cycle[9]. PTG planning ---------------- * We are collecting the PTG topics in etherpad[10], feel free to add any topic you would like to discuss. Test support for TLS default: ---------------------------------- * Rico has started a separate email thread over testing with tls-proxy enabled[11], we encourage projects to participate in that testing and help to enable the tls-proxy in gate testing. 4. How to contact the TC: ==================== If you would like to discuss or give feedback to TC, you can reach out to us in multiple ways: 1. Email: you can send the email with tag [tc] on openstack-discuss ML[12]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [13] 3. Office hours: The Technical Committee offers a weekly office hour every Tuesday at 0100 UTC [14] 4. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-August/024088.html [2] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [3] https://etherpad.opendev.org/p/tc-xena-tracker [4] https://review.opendev.org/q/project:openstack/governance+status:open [5] http://lists.openstack.org/pipermail/openstack-discuss/2021-August/024093.html [6] http://lists.openstack.org/pipermail/openstack-discuss/2021-August/024120.html [7] https://review.opendev.org/c/openstack/governance/+/798540 [8] https://etherpad.opendev.org/p/y-series-goals [9] https://review.opendev.org/c/openstack/governance/+/803783 [10] https://etherpad.opendev.org/p/tc-yoga-ptg [11] http://lists.openstack.org/pipermail/openstack-discuss/2021-June/023000.html [12] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [13] http://eavesdrop.openstack.org/#Technical_Committee_Meeting [14] http://eavesdrop.openstack.org/#Technical_Committee_Office_hours -gmann From akanevsk at redhat.com Sat Aug 14 01:18:49 2021 From: akanevsk at redhat.com (Arkady Kanevsky) Date: Fri, 13 Aug 2021 21:18:49 -0400 Subject: [ironic] Departure from full-time work on the project In-Reply-To: References: Message-ID: Thanks for all the hard work Jay On Fri, Aug 13, 2021 at 12:10 PM Jay Faulkner wrote: > Hello everyone, > > As mentioned in the Ironic IRC meeting, I will no longer be working full > time on OpenStack Ironic after this week. It is my intention to continue > reviewing code for a small amount of time on the weekends until my context > around the project becomes too stale. > > Working on OpenStack Ironic has been the greatest adventure of my career > so far, but I'll mostly remember all the nice people I met along the way. > > Thanks, > Jay Faulkner > -- Arkady Kanevsky, Ph.D. Phone: 972 707-6456 Corporate Phone: 919 729-5744 ext. 8176456 -------------- next part -------------- An HTML attachment was scrubbed... URL: From midhunlaln66 at gmail.com Sat Aug 14 02:29:47 2021 From: midhunlaln66 at gmail.com (Midhunlal Nb) Date: Sat, 14 Aug 2021 07:59:47 +0530 Subject: Active and standby controller nodes Message-ID: Hi team, I have a rocky installed openstack environment and it is working fine.In my set up I have; 1 controller node,2 compute nodes and 1 storage node. Now we are planning to add 1 more controller node as standby.Is it possible to add 1 more controller node in existing set up? if it is possible ,anyone please share the procedure. Thanks & Regards Midhunlal N B +918921245637 -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhangbailin at inspur.com Sat Aug 14 07:54:38 2021 From: zhangbailin at inspur.com (=?gb2312?B?QnJpbiBaaGFuZyjVxbDZwdYp?=) Date: Sat, 14 Aug 2021 07:54:38 +0000 Subject: =?gb2312?B?tPC4tDogW3ZlbnVzXSBQcm9qZWN0IFByb2dyZXNz?= In-Reply-To: <211c0536f25940cf937d7a97c35cc4dc@inspur.com> References: <211c0536f25940cf937d7a97c35cc4dc@inspur.com> Message-ID: <50331b43448244ce823832f87a708576@inspur.com> Thanks for working for this job. As we discussed support for log retrieval of Cyborg in Hackthon in China at April 2021, which improves our efficiency in locating and solving problems. And there are many companies have expressed interest in the Venus project, and we have already begun to cooperate. Thanks. brinzhang Inspur Electronic Information Industry Co.,Ltd. 发件人: Liye Pang(逄立业) 发送时间: 2021年8月14日 15:38 收件人: openstack-discuss at lists.openstack.org 抄送: Brin Zhang(张百林) 主题: [venus] Project Progress Hi Team: Thanks to everyone for months of hard work, we have made great progress of venus, mainly as follows: 1. Add the retrieval of vitrage, cyborg and other modules to venus. 2.Developed the deployment based on kolla-ansible of venus,the location is: https://review.opendev.org/c/openstack/kolla-ansible/+/793897 https://review.opendev.org/c/openstack/kolla/+/793795 3.The configuration, Search,analysis of Venus are integrated into horizon in the form of plugin as the attached picture. Hope everyone will make persistent efforts to make venus easier and more practical. Regards, pangliye -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3626 bytes Desc: not available URL: From radoslaw.piliszek at gmail.com Sat Aug 14 08:35:47 2021 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Sat, 14 Aug 2021 10:35:47 +0200 Subject: [venus] Project Progress In-Reply-To: <50331b43448244ce823832f87a708576@inspur.com> References: <211c0536f25940cf937d7a97c35cc4dc@inspur.com> <50331b43448244ce823832f87a708576@inspur.com> Message-ID: Dear colleagues from Inspur, I have seen your proposals to Kolla and Kolla Ansible. I have added a discussion point in the upcoming Kolla's meeting. [1] The team has to agree on the inclusion of this non-official project. I am looking forward to a positive resolution. It could help if you joined us then as well. I think it is important to answer the question whether you are planning to make Venus an official OpenStack project or not and what the progress of that action is (if any). With my TC hat on, I must say I have not seen any official request so far. [1] https://wiki.openstack.org/wiki/Meetings/Kolla#Agenda_for_the_next_meeting_.282021-08-18.29 Kind regards, -yoctozepto On Sat, Aug 14, 2021 at 9:56 AM Brin Zhang(张百林) wrote: > > Thanks for working for this job. > > As we discussed support for log retrieval of Cyborg in Hackthon in China at April 2021, which improves our efficiency in locating and solving problems. > > And there are many companies have expressed interest in the Venus project, and we have already begun to cooperate. > > > > Thanks. > > > > brinzhang > > Inspur Electronic Information Industry Co.,Ltd. > > > > 发件人: Liye Pang(逄立业) > 发送时间: 2021年8月14日 15:38 > 收件人: openstack-discuss at lists.openstack.org > 抄送: Brin Zhang(张百林) > 主题: [venus] Project Progress > > > > Hi Team: > > Thanks to everyone for months of hard work, we have made great progress of venus, mainly as follows: > > 1. Add the retrieval of vitrage, cyborg and other modules to venus. > > 2.Developed the deployment based on kolla-ansible of venus,the location is: > > https://review.opendev.org/c/openstack/kolla-ansible/+/793897 > > https://review.opendev.org/c/openstack/kolla/+/793795 > > 3.The configuration, Search,analysis of Venus are integrated into horizon in the form of plugin as the attached picture. > > > > Hope everyone will make persistent efforts to make venus easier and more practical. > > > > Regards, > > pangliye > > From joykechen at 163.com Sat Aug 14 08:51:07 2021 From: joykechen at 163.com (=?GBK?B?s8K/yw==?=) Date: Sat, 14 Aug 2021 16:51:07 +0800 (CST) Subject: [cyborg]Cyborg weekly meeting time slot Message-ID: <39a118b9.13fb.17b43db8e72.Coremail.joykechen@163.com> Thanks xinran's advice. So that we can have more time to discuss problems at night~ Thanks, Ke Chen -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhangbailin at inspur.com Sat Aug 14 08:54:36 2021 From: zhangbailin at inspur.com (=?utf-8?B?QnJpbiBaaGFuZyjlvKDnmb7mnpcp?=) Date: Sat, 14 Aug 2021 08:54:36 +0000 Subject: =?utf-8?B?562U5aSNOiBbdmVudXNdIFByb2plY3QgUHJvZ3Jlc3M=?= In-Reply-To: References: <211c0536f25940cf937d7a97c35cc4dc@inspur.com> <50331b43448244ce823832f87a708576@inspur.com> Message-ID: Thanks Radosław for you attention. We have sent an application to the TC team to make Venus an official project, which requires a process. If we can reach an agreement at the kolla meeting, I think we can proceed simultaneously. Thanks. brinzhang Inspur Electronic Information Industry Co.,Ltd. -----邮件原件----- 发件人: Radosław Piliszek [mailto:radoslaw.piliszek at gmail.com] 发送时间: 2021年8月14日 16:36 收件人: Brin Zhang(张百林) 抄送: Liye Pang(逄立业) ; openstack-discuss at lists.openstack.org 主题: Re: [venus] Project Progress Dear colleagues from Inspur, I have seen your proposals to Kolla and Kolla Ansible. I have added a discussion point in the upcoming Kolla's meeting. [1] The team has to agree on the inclusion of this non-official project. I am looking forward to a positive resolution. It could help if you joined us then as well. I think it is important to answer the question whether you are planning to make Venus an official OpenStack project or not and what the progress of that action is (if any). With my TC hat on, I must say I have not seen any official request so far. [1] https://wiki.openstack.org/wiki/Meetings/Kolla#Agenda_for_the_next_meeting_.282021-08-18.29 Kind regards, -yoctozepto On Sat, Aug 14, 2021 at 9:56 AM Brin Zhang(张百林) wrote: > > Thanks for working for this job. > > As we discussed support for log retrieval of Cyborg in Hackthon in China at April 2021, which improves our efficiency in locating and solving problems. > > And there are many companies have expressed interest in the Venus project, and we have already begun to cooperate. > > > > Thanks. > > > > brinzhang > > Inspur Electronic Information Industry Co.,Ltd. > > > > 发件人: Liye Pang(逄立业) > 发送时间: 2021年8月14日 15:38 > 收件人: openstack-discuss at lists.openstack.org > 抄送: Brin Zhang(张百林) > 主题: [venus] Project Progress > > > > Hi Team: > > Thanks to everyone for months of hard work, we have made great progress of venus, mainly as follows: > > 1. Add the retrieval of vitrage, cyborg and other modules to venus. > > 2.Developed the deployment based on kolla-ansible of venus,the location is: > > > https://review.opendev.org/c/openstack/kolla-ansible/+/793897 > > https://review.opendev.org/c/openstack/kolla/+/793795 > > 3.The configuration, Search,analysis of Venus are integrated into horizon in the form of plugin as the attached picture. > > > > Hope everyone will make persistent efforts to make venus easier and more practical. > > > > Regards, > > pangliye > > From nick-liste at posteo.eu Sat Aug 14 11:15:13 2021 From: nick-liste at posteo.eu (Nicola Ferrari (#554252)) Date: Sat, 14 Aug 2021 13:15:13 +0200 Subject: Pls help newbie :) bare metal new Ansible deployment In-Reply-To: <7029c6ed-8e77-a734-f191-2e7d318d5ded@posteo.eu> References: <7029c6ed-8e77-a734-f191-2e7d318d5ded@posteo.eu> Message-ID: Dears, just to follow up and close this thread: problem was solved by setting both internal_lb_vip_address: external_lb_vip_address: in user config, with 2 different ips. (external_lb_vip_address: was not previously set) Thanks to everybody and have a nice day! -- +------------------------+ | on LinuxCounter I was | | Linux User #554252 | +------------------------+ From miguel at mlavalle.com Sat Aug 14 13:19:39 2021 From: miguel at mlavalle.com (Miguel Lavalle) Date: Sat, 14 Aug 2021 08:19:39 -0500 Subject: [ironic] Departure from full-time work on the project In-Reply-To: References: Message-ID: You will be missed in the community and at the office. Good luck On Fri, Aug 13, 2021, 8:19 PM Arkady Kanevsky wrote: > Thanks for all the hard work Jay > > On Fri, Aug 13, 2021 at 12:10 PM Jay Faulkner < > jay.faulkner at verizonmedia.com> wrote: > >> Hello everyone, >> >> As mentioned in the Ironic IRC meeting, I will no longer be working full >> time on OpenStack Ironic after this week. It is my intention to continue >> reviewing code for a small amount of time on the weekends until my context >> around the project becomes too stale. >> >> Working on OpenStack Ironic has been the greatest adventure of my career >> so far, but I'll mostly remember all the nice people I met along the way. >> >> Thanks, >> Jay Faulkner >> > > > -- > Arkady Kanevsky, Ph.D. > Phone: 972 707-6456 > Corporate Phone: 919 729-5744 ext. 8176456 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thierry at openstack.org Sat Aug 14 14:32:09 2021 From: thierry at openstack.org (Thierry Carrez) Date: Sat, 14 Aug 2021 16:32:09 +0200 Subject: [murano][tc] Project Retirement In-Reply-To: References: Message-ID: <3117ebb2-ea5f-9905-2447-1773c4c23eab@openstack.org> Mohammed Naser wrote: > Today, at the TC weekly meeting, it was brought up that Murano was not > very active over the past few years and most likely has had a major > amount of bitrot. The community is not able to reach the current PTL > of the project either. > > Personally, I think that at this point, Murano is a bit past it's > time. We've got a lot more developments in application deployment > nowadays, OpenStack offers things like Magnum to get a Kubernetes > cluster which you can run workloads on via Helm, or projects like Zun > offer serverlerss containers directly, making a lot of what Murano > used to do not so helpful in the current landscape. > > I'm sending this email to discuss/propose the idea of retiring the project. +1 due to: - low adoption - peripheral nature (no other project depends on it) - superseded by other software distribution strategies (containers) zhurong has done a great job at keeping it alive from a release standpoint, but I have no idea how usable it actually is today. -- Thierry From aaronzhu1121 at gmail.com Sat Aug 14 14:59:55 2021 From: aaronzhu1121 at gmail.com (Rong Zhu) Date: Sat, 14 Aug 2021 22:59:55 +0800 Subject: [murano][tc] Project Retirement In-Reply-To: <3117ebb2-ea5f-9905-2447-1773c4c23eab@openstack.org> References: <3117ebb2-ea5f-9905-2447-1773c4c23eab@openstack.org> Message-ID: Hi, Sorry for my late response, I am a little bit busy for internal works recently. If TC has decided to retire murano, I have no objection. But If TC think someone can keep maintain it and not retire, I am glad to keeping maintain Murano project. Please reconsider this. Thanks, Rong Zhu Thierry Carrez 于2021年8月14日 周六22:41写道： > Mohammed Naser wrote: > > Today, at the TC weekly meeting, it was brought up that Murano was not > > very active over the past few years and most likely has had a major > > amount of bitrot. The community is not able to reach the current PTL > > of the project either. > > > > Personally, I think that at this point, Murano is a bit past it's > > time. We've got a lot more developments in application deployment > > nowadays, OpenStack offers things like Magnum to get a Kubernetes > > cluster which you can run workloads on via Helm, or projects like Zun > > offer serverlerss containers directly, making a lot of what Murano > > used to do not so helpful in the current landscape. > > > > I'm sending this email to discuss/propose the idea of retiring the > project. > > +1 due to: > > - low adoption > - peripheral nature (no other project depends on it) > - superseded by other software distribution strategies (containers) > > zhurong has done a great job at keeping it alive from a release > standpoint, but I have no idea how usable it actually is today. > > -- > Thierry > > -- Thanks, Rong Zhu -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick-liste at posteo.eu Sat Aug 14 11:15:13 2021 From: nick-liste at posteo.eu (Nicola Ferrari (#554252)) Date: Sat, 14 Aug 2021 13:15:13 +0200 Subject: Pls help newbie :) bare metal new Ansible deployment In-Reply-To: <7029c6ed-8e77-a734-f191-2e7d318d5ded@posteo.eu> References: <7029c6ed-8e77-a734-f191-2e7d318d5ded@posteo.eu> Message-ID: Dears, just to follow up and close this thread: problem was solved by setting both internal_lb_vip_address: external_lb_vip_address: in user config, with 2 different ips. (external_lb_vip_address: was not previously set) Thanks to everybody and have a nice day! -- +------------------------+ | on LinuxCounter I was | | Linux User #554252 | +------------------------+ From openinfradn at gmail.com Sun Aug 15 08:20:35 2021 From: openinfradn at gmail.com (open infra) Date: Sun, 15 Aug 2021 13:50:35 +0530 Subject: Need a help to recover Openstack In-Reply-To: References: <6D52275A-7ACF-48F1-97A8-49FD389E99EF@gmail.com> Message-ID: Thanks Ildikó and Mohammed. > The issue you’re facing seems to be originating from how MariaDB gets deployed in StarlingX, at least based on a quick glance at the logs. In that sense it might be better to ask that community. Have you tried that already? I did send a mail to STX mailing list after you asked to do so. >I’d delete all 3 pods and let OSH rebuild the MariaDB cluster :) I have deleted all mariadb related pods but no luck. Same pod failing again and again. I cant see mariadb process in mariadb-server-1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ricolin at ricolky.com Sun Aug 15 18:49:29 2021 From: ricolin at ricolky.com (Rico Lin) Date: Mon, 16 Aug 2021 02:49:29 +0800 Subject: [tc][all] Please Help On Collecting Pain Points In-Reply-To: References: Message-ID: Hi all, Would like to bump this mail again. We're currently collect pain points from project teams and operators. Please help to fill them in: https://etherpad.opendev.org/p/pain-point-elimination *Rico Lin* OIF Individual Board of directors, OpenStack TC, Multi-arch SIG chair, Heat PTL, Senior Software Engineer at EasyStack On Tue, Jul 27, 2021 at 5:58 PM Kendall Nelson wrote: > Looks like we've started making some progress in the etherpad[1] which is > great- thank you to those that have already jotted ideas down- but we are > still missing a fair number of projects.. > > If we want pain points fixing to be a community goal, we should get them > collected ASAP. If there is anything I can help with, please let me know! > > -Kendall (diablo_rojo) > > [1] https://etherpad.opendev.org/p/pain-point-elimination > > On Thu, Jul 15, 2021 at 8:04 AM Rico Lin wrote: > >> Dear all >> As a proposal for pre-select goals for Yoga [1]. We need to figure out >> the possibility. >> >> *I would like to ask each project team, SIG, and pop-up if you can kindly >> provide the major pain point you have (and better to be fixable by >> bugs/features).* >> >> *What you can help with is added in pain point information in [2].* >> *Information like pain point topic, description, and ideas on how to >> targeting them.* >> >> *Why this is important?* >> I think this data allows us to see clearly if we can have goals like >> `eliminate pain points`. >> >> *What's after this?* >> If we can make sure this can be a goal material, we might be able to have >> this as a goal and allow project teams to focus on one of their most >> important issues. >> >> >> As an alternative, we might be able to collect from user side with a user >> survey, but that's more like a really long-term plan for this. >> >> [1] https://etherpad.opendev.org/p/y-series-goals >> [2] https://etherpad.opendev.org/p/pain-point-elimination >> >> *Rico Lin* >> OIF Board director, OpenStack TC, Multi-arch SIG chair, Heat PTL, >> Senior Software Engineer at EasyStack >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xin-ran.wang at intel.com Mon Aug 16 02:20:35 2021 From: xin-ran.wang at intel.com (Wang, Xin-ran) Date: Mon, 16 Aug 2021 02:20:35 +0000 Subject: [cyborg] Y cycle PTL nomination from 17th August Message-ID: Hi all, The Y cycle PTL nomination will start on 17th August. Firstly, I want to give a big thanks to all of you, thank you for the continuously support and contribution for Cyborg. As I have been this role for almost 2 cycles, I think it is better to have someone else to take this role which can bring us new ideas. Please refer to this guide[1] if you want submit your candidacy. If you have any question, please feel free to contact me. [1] https://governance.openstack.org/election/#how-to-submit-a-candidacy Thanks, Xin-Ran -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhangbailin at inspur.com Mon Aug 16 03:07:32 2021 From: zhangbailin at inspur.com (=?gb2312?B?QnJpbiBaaGFuZyjVxbDZwdYp?=) Date: Mon, 16 Aug 2021 03:07:32 +0000 Subject: =?gb2312?B?tPC4tDogW2N5Ym9yZ10gWSBjeWNsZSBQVEwgbm9taW5hdGlvbiBmcm9tIDE3?= =?gb2312?Q?th_August?= In-Reply-To: References: Message-ID: <1eb623756115420db2cca1bc353fc553@inspur.com> Hi Xinran, Thank you for your hard work. During your tenure, we have introduced drivers for Intel QAT, Intel X710, Inspur FPGA, Inspur SSD, and the "sriov-smartnic-support" related work we are doing. I am glad that you have not left Cyborg and will continue to maintain the Cyborg project with us. I will submit a candidate application, hoping to get your approval. Thanks. brinzhang Inspur Electronic Information Industry Co.,Ltd. 发件人: Wang, Xin-ran [mailto:xin-ran.wang at intel.com] 发送时间: 2021年8月16日 10:21 收件人: openstack-discuss 主题: [cyborg] Y cycle PTL nomination from 17th August Hi all, The Y cycle PTL nomination will start on 17th August. Firstly, I want to give a big thanks to all of you, thank you for the continuously support and contribution for Cyborg. As I have been this role for almost 2 cycles, I think it is better to have someone else to take this role which can bring us new ideas. Please refer to this guide[1] if you want submit your candidacy. If you have any question, please feel free to contact me. [1] https://governance.openstack.org/election/#how-to-submit-a-candidacy Thanks, Xin-Ran -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaronzhu1121 at gmail.com Mon Aug 16 03:49:34 2021 From: aaronzhu1121 at gmail.com (Rong Zhu) Date: Mon, 16 Aug 2021 11:49:34 +0800 Subject: [cyborg] Y cycle PTL nomination from 17th August In-Reply-To: References: Message-ID: Xinran, Thanks for your great efforts for cyborg. Wang, Xin-ran 于2021年8月16日 周一10:25写道： > Hi all, > > > > The Y cycle PTL nomination will start on 17th August. Firstly, I want to > give a big thanks to all of you, thank you for the continuously support and > contribution for Cyborg. As I have been this role for almost 2 cycles, I > think it is better to have someone else to take this role which can bring > us new ideas. > > > > Please refer to this guide[1] if you want submit your candidacy. If you > have any question, please feel free to contact me. > > > > [1] https://governance.openstack.org/election/#how-to-submit-a-candidacy > > > > Thanks, > > Xin-Ran > > > -- Thanks, Rong Zhu -------------- next part -------------- An HTML attachment was scrubbed... URL: From hberaud at redhat.com Mon Aug 16 07:49:06 2021 From: hberaud at redhat.com (Herve Beraud) Date: Mon, 16 Aug 2021 09:49:06 +0200 Subject: [release] Y cycle PTL nominations from 17th August Message-ID: Hello, in case you missed in, the OpenStack Y cycle election season is soon upon us starting 17th August [1]. I do not intend to run for a third cycle as ptl. I think it is healthy for the project to have new energy and ideas brought by a new ptl. I'd like to encourage anyone who is considering this to read the info from [1] and in particular prepare a nomination [2]. Feel free to reach out to me if you have any questions or concerns. If you *are* thinking about it bear in mind there are many experienced people around that can and will help you. Thanks for your attention, [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-August/024093.html [2] https://governance.openstack.org/election/#how-to-submit-a-candidacy -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -------------- next part -------------- An HTML attachment was scrubbed... URL: From skaplons at redhat.com Mon Aug 16 07:53:00 2021 From: skaplons at redhat.com (Slawek Kaplonski) Date: Mon, 16 Aug 2021 09:53:00 +0200 Subject: [victoria][ops][horizon][neutron] Network not available to use by Members in Horizon In-Reply-To: <0670B960225633449A24709C291A525251C78C29@COM03.performair.local> References: <0670B960225633449A24709C291A525251C78C29@COM03.performair.local> Message-ID: <2452154.BiziIVhrhC@p1> Hi, On piątek, 13 sierpnia 2021 18:25:03 CEST DHilsbos at performair.com wrote: > All; > > We just discovered, this morning, that Members of one of our projects can't > see the project's network, in order to use it in Instance creation. If an > Administrator creates a Port, the Member user can then use it to create an > Instance. > > Most of our activity to this point has been by Administrators, this is the > first time we've opened a project up to users with the Member level. > > Is this expected behavior? Please check what project is owner of the network and how are Your policies configured. By default owner (project) of the network should always see it and be able to create port in own network. > > Thank you, > > Dominic L. Hilsbos, MBA > Vice President - Information Technology > Perform Air International Inc. > DHilsbos at PerformAir.com > www.PerformAir.com -- Slawek Kaplonski Principal Software Engineer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From patryk.jakuszew at gmail.com Mon Aug 16 08:13:42 2021 From: patryk.jakuszew at gmail.com (Patryk Jakuszew) Date: Mon, 16 Aug 2021 10:13:42 +0200 Subject: [rocky][cinder][lvm] VM LVM leakage to packstack host OS In-Reply-To: References: Message-ID: Hi, On Fri, 13 Aug 2021 at 18:53, Alan Davis wrote: > I think there are several things going on here : duplicate VG names causing LVM to see UUID/name conflicts and "leakage" of LVM data that cinder should be managing to the OS level. > > What do I need to change in my configuration to fix this and avoid problems in the future? Your system-wide lvm.conf (not the cinder one) is probably missing a valid global_filter configuration - adjusting it to only include your system volumes and cinder-volumes group should mitigate that. -- Regards, Patryk Jakuszew From hberaud at redhat.com Mon Aug 16 08:26:39 2021 From: hberaud at redhat.com (Herve Beraud) Date: Mon, 16 Aug 2021 10:26:39 +0200 Subject: [release] Release countdown for week R-7, Aug 16 - Aug 20 Message-ID: Development Focus ----------------- We are entering the last weeks of the Xena development cycle. From now until the final release, we'll send a countdown email like this every week. It's probably a good time for teams to take stock of their library and client work that needs to be completed yet. The non-client library freeze is coming up, followed closely by the client lib freeze. Now is a good time to make decisions on deferring feature work to the next development cycle in order to be able to focus on finishing already-started feature work. Please plan accordingly to avoid any last minute rushes to get key functionality in. General Information ------------------- We are now getting close to the end of the cycle, and will be gradually freezing feature work on the various deliverables that make up the OpenStack release. This coming week is the deadline for general libraries (except client libraries): their last feature release needs to happen before "Non-client library freeze" on September 19. Only bugfixes releases will be allowed beyond this point. When requesting those library releases, you can also include the stable/xena branching request with the review (as an example, see the "branches" section here: https://opendev.org/openstack/releases/src/branch/master/deliverables/pike/os-brick.yaml#n2 A quick reminder of the upcoming freeze dates. Those vary depending on deliverable type: * General libraries (except client libraries) need to have their last feature release before Non-client library freeze (August 19th). Their stable branches are cut early. * Client libraries (think python-*client libraries) need to have their last feature release before Client library freeze (September 2nd) * Deliverables following a cycle-with-rc model (that would be most services) observe a Feature freeze on that same date, September 2nd. Any feature addition beyond that date should be discussed on the mailing-list and get PTL approval. After feature freeze, cycle-with-rc deliverables need to produce a first release candidate (and a stable branch) before RC1 deadline (Sep 13 - Sep 17). * Deliverables following cycle-with-intermediary model can release as necessary, but in all cases before Final RC deadline (Sep 27 - Oct 01). As we are getting to the point of creating stable/xena branches, this would be a good point for teams to review membership in their xena-stable-maint groups. Once the stable/xena branches are cut for a repo, the ability to approve any necessary backports into those branches for xena will be limited to the members of that stable team. If there are any questions about stable policy or stable team membership, please reach out in the #openstack-stable channel. Finally, now is also a good time to start planning what highlights you want for your deliverables in the cycle highlights. The deadline to submit an initial version for those is set to Feature freeze (September 2nd). Background on cycle-highlights: http://lists.openstack.org/pipermail/openstack-discuss/2021-August/024105.html Project Team Guide, Cycle-Highlights: https://docs.openstack.org/project-team-guide/release-management.html#cycle-highlights knelson [at] openstack.org/diablo_rojo on IRC is available if you need help selecting or writing your highlights Upcoming Deadlines & Dates -------------------------- Non-client library freeze: Aug 19 (R-7 week) Client library freeze: Sep 02 (R-5 week) Xena-3 milestone: Sep 02 (R-5 week) -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -------------- next part -------------- An HTML attachment was scrubbed... URL: From syedammad83 at gmail.com Mon Aug 16 09:26:17 2021 From: syedammad83 at gmail.com (Ammad Syed) Date: Mon, 16 Aug 2021 14:26:17 +0500 Subject: [wallaby][neutron] OVN Geneve multiple tunnels Message-ID: Hi, I am using neutron with ovn geneve. Currently I have two nic ports and I have bonded them in active passive bond in linux and assigned an IP address on vlan tagged interface for overlay network. Is it possible that I can use two or more IP addresses for overlay tunnels between compute hosts ? I am planning to assign an IP on each NIC so that I can have redundancy as well as a pair of tunnel with more throughput between compute hosts ? Ammad -------------- next part -------------- An HTML attachment was scrubbed... URL: From elod.illes at est.tech Mon Aug 16 09:33:42 2021 From: elod.illes at est.tech (=?UTF-8?B?RWzFkWQgSWxsw6lz?=) Date: Mon, 16 Aug 2021 11:33:42 +0200 Subject: [neutron][stable] Nominate Lajos Katona to the neutron-stable-maint team In-Reply-To: <1678645.VL9kP18s9H@p1> References: <4154938.lVMuQLOT2H@p1> <1678645.VL9kP18s9H@p1> Message-ID: <9e06b87e-11ee-ef0c-dac9-c14fa41bd207@est.tech> Hi, I've added Lajos to neutron-stable-maint group as it was requested Congrats Lajos & keep up the good work! \o/ Cheers, Előd On 2021. 08. 16. 9:56, Slawek Kaplonski wrote: > Hi, > > It's been more than week since I sent it and I got only positive feedback > about Lajos candidacy. > @Stable maint team: can You add Lajos to the neutron-stable-maint group? Or do > I need to do something more to get Lajos to that group? > > On czwartek, 5 sierpnia 2021 11:50:46 CEST Slawek Kaplonski wrote: >> Hi, >> >> I would like to nominate Lajos Katona as a Neutron stable core reviewer. > Lajos >> is core in Neutron since long time. He is maintaining many stadium projects >> as well as he is very active in the main Neutron project. He helps us a lot >> with keeping stable branches healthy (especially for stadium projects, but >> not only). >> During that time he has proven already his knowledge about Neutron and > Neutron >> stadium projects as well as knowledge of the stable branches rules. >> >> I will keep this nomination open for about 1 week. After that if there will > be >> no votes agains, I will ask stable-maint-core team to add Lajos to the >> neutron-stable-maint team. > From jlibosva at redhat.com Mon Aug 16 10:19:10 2021 From: jlibosva at redhat.com (Jakub Libosvar) Date: Mon, 16 Aug 2021 12:19:10 +0200 Subject: [wallaby][neutron] OVN Geneve multiple tunnels In-Reply-To: References: Message-ID: <30f3cfa9-4708-87ef-7a63-dfb1b2681e8c@redhat.com> On 16.08.2021 11:26, Ammad Syed wrote: > Hi, > > I am using neutron with ovn geneve. Currently I have two nic ports and I > have bonded them in active passive bond in linux and assigned an IP address > on vlan tagged interface for overlay network. > > Is it possible that I can use two or more IP addresses for overlay tunnels > between compute hosts ? I am planning to assign an IP on each NIC so that I > can have redundancy as well as a pair of tunnel with more throughput > between compute hosts ? > > Ammad > Hi Ammad, as per the ovn-controller code [1] it doesn't support list of IPs for the tunnel endpoints. Therefore you can't have 2 IPs used for the tunnels. If you want to achieve higher throughput you can configure the linux bond to use LACP and run it in active/active mode. I hope that helps. Jakub [1] https://github.com/ovn-org/ovn/blob/f9a4c68373b1e4d32e1f027f7f4fdf154878dcc6/controller/encaps.c#L183-L185 From stephenfin at redhat.com Mon Aug 16 11:04:04 2021 From: stephenfin at redhat.com (Stephen Finucane) Date: Mon, 16 Aug 2021 12:04:04 +0100 Subject: [all] SQLAlchemy 2.0 and coming ORM apocalypse In-Reply-To: References: <3c6449e1f3529b85fdd2d17459adb3dc9d3add9f.camel@redhat.com> <3c334098-a704-441e-b1e3-a27cc0459566@www.fastmail.com> Message-ID: <002a146c01b569bf3165c99ca66563939ab9e4b1.camel@redhat.com> On Fri, 2021-08-13 at 23:55 +0530, Abhishek Kekane wrote: > Now glance is hit with different SQLA related error, We are tracking it here > [1]. This had the same underlying cause as the previous change. I've pushed a patch to address this [1] Stephen [1] https://review.opendev.org/c/openstack/glance/+/804699 > > [1] https://bugs.launchpad.net/glance/+bug/1939716 > > Thanks & Best Regards, > > Abhishek Kekane > > > On Fri, Aug 13, 2021 at 5:27 AM Mike Bayer wrote: > > didn't see the main docs linked so the story starts at SQLA's migration > > docs. > > > > starting w/ 1.4 which has all of 2.0's internals ready to go: > > > > https://docs.sqlalchemy.org/en/14/changelog/migration_14.html > > > > then 2.0 which includes 1.x->2.0 migration notes: > > > > https://docs.sqlalchemy.org/en/14/changelog/migration_20.html > > > > we spent a lot of time trying to make this process smooth.  it has both a > > few ideas from how py2->py3 worked (warnings mode) and also does some things > > intentionally the opposite of how py2/3 did it (you can run a codebase that > > is compatible with 1.4 and 2.0 at the same time). > > > > > > > > > > On Thu, Aug 12, 2021, at 12:00 PM, Stephen Finucane wrote: > > > tl;dr: If you haven't already started looking at SQLAlchemy 2.0 > > > compatibility > > > and/or are still using sqlalchemy-migrate, you probably have work to do. > > > > > > As you can guess from $subject, there's a new major version of SQLAlchemy > > > in the > > > pipeline. The good news: it cleans up a lot of cruft and makes a lot of > > > things > > > such as session management more explicit and verbose, with the idea being > > > that > > > this should avoid a lot of gotchas and foot-gun moments. The bad news: the > > > changes are pretty extensive, and virtually anyone that uses SQLAlchemy, > > > which > > > is to say every (?) OpenStack service out there, will likely have to make > > > changes. > > > > > > This change will likely have a couple of impacts for users: > > > > > > # Breaking changes in oslo.db > > > > > > The oslo devs have been steadily working through the many errors that > > > oslo.db is > > > currently emitting when SQLAlchemy 2.0 deprecation warnings are turned on. > > > The > > > patches (which is not yet complete) to address these can be found here > > > [1]. As a > > > result of these changes, a number of oslo.db APIs are likely to start > > > performing > > > slightly differently, and many more may be deprecated and eventually > > > removed. An > > > example of the kind of change you can expect to see can be found in this > > > glance > > > patch [2]. We will work to minimize these changes but some will be > > > unavoidable > > > once sqlalchemy 2.0 actually arrives. > > > > > > # Breaking changes in your own project > > > > > > If oslo.db seeing breaking changes because of SQLAlchemy 2.0, you can be > > > sure > > > that you're going to see some too. Fortunately, there are ways you can get > > > ahead > > > of this. Turning SADeprecationWarning warnings into errors for your own > > > module, > > > as we've done for oslo.db [3][4] seems a sensible pattern to weed out > > > these > > > issues. > > > > > > As an aside, enabling warnings as errors seems to be a generally good idea > > > in a > > > unit test environment. It's usually a lot easier to address these things > > > as they > > > pop up that when things are finally removed and stuff explodes. To each > > > their > > > own though, of course. > > > > > > # The long prophesied death of sqlalchemy-migrate > > > > > > The lack of maintenance on sqlalchemy-migrate has already been well > > > documented > > > [5], however, SQLAlchemy 2.0 is likely to be the thing that finally puts > > > the > > > nail in sqlalchemy-migrate's coffin. I've been working on migrating the > > > last few > > > laggards still using sqlalchemy-migrate and have successfully removed all > > > traces > > > of it from glance (thanks, glance-core!), while the nova and cinder > > > patches are > > > making reasonable progress (though I do wish it was faster). The only > > > remaining > > > "core" project to be migrated is keystone. This proved a little too > > > complicated > > > for me to do in the limited time I have to work on these things, and I'm > > > in the > > > middle of a role change in my day job so my time to work on upstream > > > OpenStack > > > will be decreasing much further going forward (though not to zero, I'm > > > hoping). > > > Fortunately, there's quite a bit of prior art available now that people > > > can > > > follow when migrating stuff [6]. > > > > > > Related to the oslo.db changes: everything related to sqlalchemy-migrate > > > in > > > oslo.db should be deprecated by the next oslo.db release, and I suspect > > > we'll be > > > pretty aggressive in pruning these. Based on codesearch.o.o, this will > > > have > > > impacts for at least keystone and cinder. > > > > > > # A chance to evaluate all things DB > > > > > > One positive out of this is that the changes necessary may be broad enough > > > to > > > take the opportunity to re-evaluate decisions made regarding your DB > > > layer. > > > We've been doing this in nova, moving lots of things about to clear up the > > > distinction between the main and API DBs and to reduce lots of tech debt > > > that > > > had built up in 'nova.db'. Consider using the opportunity to do the if > > > possible. > > > > > > --- > > > > > > Hopefully this has been useful. If you have questions about any of the > > > above, > > > please reach out and I'll do my best to answer them. > > > > > > Cheers, > > > Stephen > > > > > > > > > [1]  > > > > > > https://review.opendev.org/q/topic:%2522sqlalchemy-20%2522+(status:open+OR+status:merged)+project:openstack/oslo.db > > > [2] https://review.opendev.org/c/openstack/glance/+/804406 > > > [3]  > > > > > > https://github.com/openstack/oslo.db/commit/40bce5a2baf75dc87dd591e0f71a00f221a2ba92 > > > [4]  > > > > > > https://github.com/openstack/oslo.db/commit/4c1eb966c08d29214c1905e74965f4109f41b013 > > > [5]  > > > > > > http://lists.openstack.org/pipermail/openstack-discuss/2021-February/020672.html > > > [6]  > > > > > > https://review.opendev.org/q/topic:%22bp%252Fremove-sqlalchemy-migrate%22+(status:open%20OR%20status:merged) > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From skaplons at redhat.com Mon Aug 16 11:19:56 2021 From: skaplons at redhat.com (Slawek Kaplonski) Date: Mon, 16 Aug 2021 13:19:56 +0200 Subject: [neutron][stable] Nominate Lajos Katona to the neutron-stable-maint team In-Reply-To: <9e06b87e-11ee-ef0c-dac9-c14fa41bd207@est.tech> References: <4154938.lVMuQLOT2H@p1> <1678645.VL9kP18s9H@p1> <9e06b87e-11ee-ef0c-dac9-c14fa41bd207@est.tech> Message-ID: <2524006.0XaToDZh8t@p1> Hi, On poniedziałek, 16 sierpnia 2021 11:33:42 CEST Előd Illés wrote: > Hi, > > I've added Lajos to neutron-stable-maint group as it was requested Thx a lot Elod :) > Congrats Lajos & keep up the good work! \o/ > > Cheers, > > Előd > > On 2021. 08. 16. 9:56, Slawek Kaplonski wrote: > > Hi, > > > > It's been more than week since I sent it and I got only positive feedback > > about Lajos candidacy. > > @Stable maint team: can You add Lajos to the neutron-stable-maint group? Or > > do I need to do something more to get Lajos to that group? > > > > On czwartek, 5 sierpnia 2021 11:50:46 CEST Slawek Kaplonski wrote: > >> Hi, > >> > >> I would like to nominate Lajos Katona as a Neutron stable core reviewer. > > > > Lajos > > > >> is core in Neutron since long time. He is maintaining many stadium projects > >> as well as he is very active in the main Neutron project. He helps us a lot > >> with keeping stable branches healthy (especially for stadium projects, but > >> not only). > >> During that time he has proven already his knowledge about Neutron and > > > > Neutron > > > >> stadium projects as well as knowledge of the stable branches rules. > >> > >> I will keep this nomination open for about 1 week. After that if there will > > > > be > > > >> no votes agains, I will ask stable-maint-core team to add Lajos to the > >> neutron-stable-maint team. -- Slawek Kaplonski Principal Software Engineer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From whayutin at redhat.com Mon Aug 16 13:28:33 2021 From: whayutin at redhat.com (Wesley Hayutin) Date: Mon, 16 Aug 2021 07:28:33 -0600 Subject: [tripleo] Y cycle PTL nominations from 17th August In-Reply-To: References: Message-ID: Well done Marios! Thanks for driving the last two cycles! Looking forward to see who steps up to drive :) On Fri, Aug 13, 2021 at 7:34 AM Amy Marrich wrote: > Marios thank you for all your hard work over the last 2 cycles! > > Amy (spotz) > > On Fri, Aug 13, 2021 at 7:47 AM Marios Andreou wrote: > >> Hello tripleo o/ >> >> in case you missed in, the OpenStack Y cycle election season is soon >> upon us starting 17th August [1] >> >> As previously mentioned in tripleo irc meetings I do not intend to run >> for a third cycle as ptl. I think it is healthy for the project to >> have new energy and ideas brought by a new ptl and we are very >> fortunate to have many capable candidates in our community who have >> not previously occupied that role. >> >> I'd like to encourage anyone who is considering this to read the info >> from [1] and in particular prepare a nomination [2]. Feel free to >> reach out to me if you have any questions or concerns. If you *are* >> thinking about it bear in mind there are many experienced people >> around that can and will help so ... how badly can it go ! ;) >> >> regards, marios >> >> [1] >> http://lists.openstack.org/pipermail/openstack-discuss/2021-August/024093.html >> [2] https://governance.openstack.org/election/#how-to-submit-a-candidacy >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From marios at redhat.com Mon Aug 16 13:39:53 2021 From: marios at redhat.com (Marios Andreou) Date: Mon, 16 Aug 2021 16:39:53 +0300 Subject: [tripleo] Y cycle PTL nominations from 17th August In-Reply-To: References: Message-ID: thank you Wes for your encouragement and all the help along the way! ;) regards On Monday, August 16, 2021, Wesley Hayutin wrote: > Well done Marios! > Thanks for driving the last two cycles! Looking forward to see who steps > up to drive :) > > On Fri, Aug 13, 2021 at 7:34 AM Amy Marrich wrote: > >> Marios thank you for all your hard work over the last 2 cycles! >> >> Amy (spotz) >> >> On Fri, Aug 13, 2021 at 7:47 AM Marios Andreou wrote: >> >>> Hello tripleo o/ >>> >>> in case you missed in, the OpenStack Y cycle election season is soon >>> upon us starting 17th August [1] >>> >>> As previously mentioned in tripleo irc meetings I do not intend to run >>> for a third cycle as ptl. I think it is healthy for the project to >>> have new energy and ideas brought by a new ptl and we are very >>> fortunate to have many capable candidates in our community who have >>> not previously occupied that role. >>> >>> I'd like to encourage anyone who is considering this to read the info >>> from [1] and in particular prepare a nomination [2]. Feel free to >>> reach out to me if you have any questions or concerns. If you *are* >>> thinking about it bear in mind there are many experienced people >>> around that can and will help so ... how badly can it go ! ;) >>> >>> regards, marios >>> >>> [1] http://lists.openstack.org/pipermail/openstack-discuss/ >>> 2021-August/024093.html >>> [2] https://governance.openstack.org/election/#how-to-submit-a-candidacy >>> >>> >>> -- _sent from my mobile - sorry for spacing spelling etc_ -------------- next part -------------- An HTML attachment was scrubbed... URL: From skaplons at redhat.com Mon Aug 16 07:56:45 2021 From: skaplons at redhat.com (Slawek Kaplonski) Date: Mon, 16 Aug 2021 09:56:45 +0200 Subject: [neutron][stable] Nominate Lajos Katona to the neutron-stable-maint team In-Reply-To: <4154938.lVMuQLOT2H@p1> References: <4154938.lVMuQLOT2H@p1> Message-ID: <1678645.VL9kP18s9H@p1> Hi, It's been more than week since I sent it and I got only positive feedback about Lajos candidacy. @Stable maint team: can You add Lajos to the neutron-stable-maint group? Or do I need to do something more to get Lajos to that group? On czwartek, 5 sierpnia 2021 11:50:46 CEST Slawek Kaplonski wrote: > Hi, > > I would like to nominate Lajos Katona as a Neutron stable core reviewer. Lajos > is core in Neutron since long time. He is maintaining many stadium projects > as well as he is very active in the main Neutron project. He helps us a lot > with keeping stable branches healthy (especially for stadium projects, but > not only). > During that time he has proven already his knowledge about Neutron and Neutron > stadium projects as well as knowledge of the stable branches rules. > > I will keep this nomination open for about 1 week. After that if there will be > no votes agains, I will ask stable-maint-core team to add Lajos to the > neutron-stable-maint team. -- Slawek Kaplonski Principal Software Engineer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From mark at stackhpc.com Mon Aug 16 08:22:14 2021 From: mark at stackhpc.com (Mark Goddard) Date: Mon, 16 Aug 2021 09:22:14 +0100 Subject: [Kolla-Ansible][Ironic] Baremetal node Cleaning fails in UEFI mode, but succeeds in Legacy Bios Mode In-Reply-To: References: Message-ID: Hi Anirudh, Are you using CentOS 8? The iPXE EFI bootloader file is named ipxe-x86_64.efi there, so a TFTP request for ipxe.efi will fail. Could you try setting the following in ironic.conf: [pxe] uefi_ipxe_bootfile_name = ipxe-x86_64.efi If this works, we should change it in kolla-ansible. Would you be able to propose the change via Gerrit? Mark On Fri, 13 Aug 2021 at 17:18, Anirudh Gupta wrote: > Hi Team, > > I am trying to provision Baremetal node using IRONIC with KOLLA-ANSIBLE. > I have enabled the support of "IPXE" in kolla-ansible as well. > > I am getting an issue that when my baremetal node is booted in UEFI Mode, > it is not able to find file *"ipxe.efi"* as a result of which cleaning of > the node fails > > [image: image.png] > > But when I change the BIOS Mode of my Baremetal Node to Legacy.BIOS, it > looks for the file "*undionly.kpxe"* for which the acknowledgment is > received and Data Packets are transferred. Eventually the cleaning of node > is also a success. > > [image: image.png] > > Is there any limitation of IRONIC or KOLLA-ANSIBLE side that provisioning > of Baremetal Node can only be done in Legacy Bios Mode? > For bare metal provisioning in UEFI mode, is there any other parameter > that needs to be enabled. > > Regards > Anirudh Gupta > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 200447 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 91313 bytes Desc: not available URL: From anyrude10 at gmail.com Mon Aug 16 09:24:28 2021 From: anyrude10 at gmail.com (Anirudh Gupta) Date: Mon, 16 Aug 2021 14:54:28 +0530 Subject: [Kolla-Ansible][Ironic] Baremetal node Cleaning fails in UEFI mode, but succeeds in Legacy Bios Mode In-Reply-To: References: Message-ID: Hi Mark, Thanks for your reply. Yes, I am using Centos 8 only. I tried changing the settings and restarted the docker container. The cleaning process moved a step further but it started showing the error *"Could not select: Exec format not supported"* [image: image.png] Regards Anirudh Gupta On Mon, Aug 16, 2021 at 1:52 PM Mark Goddard wrote: > Hi Anirudh, > > Are you using CentOS 8? The iPXE EFI bootloader file is > named ipxe-x86_64.efi there, so a TFTP request for ipxe.efi will fail. > > Could you try setting the following in ironic.conf: > > [pxe] > uefi_ipxe_bootfile_name = ipxe-x86_64.efi > > If this works, we should change it in kolla-ansible. Would you be able to > propose the change via Gerrit? > > Mark > > On Fri, 13 Aug 2021 at 17:18, Anirudh Gupta wrote: > >> Hi Team, >> >> I am trying to provision Baremetal node using IRONIC with KOLLA-ANSIBLE. >> I have enabled the support of "IPXE" in kolla-ansible as well. >> >> I am getting an issue that when my baremetal node is booted in UEFI Mode, >> it is not able to find file *"ipxe.efi"* as a result of which cleaning >> of the node fails >> >> [image: image.png] >> >> But when I change the BIOS Mode of my Baremetal Node to Legacy.BIOS, it >> looks for the file "*undionly.kpxe"* for which the acknowledgment is >> received and Data Packets are transferred. Eventually the cleaning of node >> is also a success. >> >> [image: image.png] >> >> Is there any limitation of IRONIC or KOLLA-ANSIBLE side that provisioning >> of Baremetal Node can only be done in Legacy Bios Mode? >> For bare metal provisioning in UEFI mode, is there any other parameter >> that needs to be enabled. >> >> Regards >> Anirudh Gupta >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 200447 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 91313 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 126227 bytes Desc: not available URL: From amy at demarco.com Mon Aug 16 14:36:34 2021 From: amy at demarco.com (Amy Marrich) Date: Mon, 16 Aug 2021 07:36:34 -0700 Subject: [release] Y cycle PTL nominations from 17th August In-Reply-To: References: Message-ID: <57807A9C-8FDA-42A0-A051-90AFC5154622@demarco.com> Herve, Thank you for all your hard work. Amy (spotz) > On Aug 16, 2021, at 12:52 AM, Herve Beraud wrote: > >  > Hello, > > in case you missed in, the OpenStack Y cycle election season is soon > upon us starting 17th August [1]. > > I do not intend to run for a third cycle as ptl. I think it is healthy for the project to > have new energy and ideas brought by a new ptl. > > I'd like to encourage anyone who is considering this to read the info > from [1] and in particular prepare a nomination [2]. Feel free to > reach out to me if you have any questions or concerns. If you *are* > thinking about it bear in mind there are many experienced people > around that can and will help you. > > Thanks for your attention, > > [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-August/024093.html > [2] https://governance.openstack.org/election/#how-to-submit-a-candidacy > > -- > Hervé Beraud > Senior Software Engineer at Red Hat > irc: hberaud > https://github.com/4383/ > https://twitter.com/4383hberaud > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Mon Aug 16 15:06:18 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Mon, 16 Aug 2021 10:06:18 -0500 Subject: [all]Introduction to venus which is the project of log management and has been contributed to the OpenStack community In-Reply-To: References: Message-ID: <17b4f7fc2ab.be9841f87523.859289224419125442@ghanshyammann.com> ---- On Wed, 13 Jan 2021 04:59:47 -0600 Thierry Carrez wrote ---- > Laurent Dumont wrote: > > This seems really interesting. Tracing events with request-ids is > > something that is quite useful. > > > > What is the current state? Can it be deployed by a third party? > > I see code up at https://opendev.org/inspur/ but I haven't tried > deploying it. > > If it gathers momentum, I suspect it will be proposed as a new official > OpenStack project, and if the Technical Committee approves it, it will > be moved under the openstack/ namespace on opendev.org. It already > follows our usual repository structure (venus, python-venusclient, > venus-tempest-plugin...) +1, I agree that this is ready to apply as an official project and then we can start the discussion in TC about checking the requirement. Please propose the patch to governance and I am adding it to the next TC meeting agenda too. - https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda_Suggestions -gmann > > -- > Thierry > > From gmann at ghanshyammann.com Mon Aug 16 15:12:23 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Mon, 16 Aug 2021 10:12:23 -0500 Subject: =?UTF-8?Q?Re:_=E7=AD=94=E5=A4=8D:_[venus]_Project_Progress?= In-Reply-To: References: <211c0536f25940cf937d7a97c35cc4dc@inspur.com> <50331b43448244ce823832f87a708576@inspur.com> Message-ID: <17b4f8555ee.12017cc7c7996.3189664691453804006@ghanshyammann.com> ---- On Sat, 14 Aug 2021 03:54:36 -0500 Brin Zhang(张百林) wrote ---- > Thanks Radosław for you attention. > > We have sent an application to the TC team to make Venus an official project, which requires a process. If we can reach an agreement at the kolla meeting, I think we can proceed simultaneously. > Just to clarify, it is discussed in ML[1]about the background and initial discussion and as next step, Venus team will add the application proposal in governance. I have added this in TC next meeting agenda too. - https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda_Suggestions On inclusion of non-official project. in Kolla, +1 on discussing it with Kolla team in their meeting. In case it help, we have added non-official projects in OpenStack Charms before - https://review.opendev.org/c/openstack/governance/+/720533 [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019745.html > Thanks. > > brinzhang > Inspur Electronic Information Industry Co.,Ltd. > > -----邮件原件----- > 发件人: Radosław Piliszek [mailto:radoslaw.piliszek at gmail.com] > 发送时间: 2021年8月14日 16:36 > 收件人: Brin Zhang(张百林) > 抄送: Liye Pang(逄立业) ; openstack-discuss at lists.openstack.org > 主题: Re: [venus] Project Progress > > Dear colleagues from Inspur, > > I have seen your proposals to Kolla and Kolla Ansible. > I have added a discussion point in the upcoming Kolla's meeting. [1] The team has to agree on the inclusion of this non-official project. > I am looking forward to a positive resolution. > It could help if you joined us then as well. > I think it is important to answer the question whether you are planning to make Venus an official OpenStack project or not and what the progress of that action is (if any). > With my TC hat on, I must say I have not seen any official request so far. > > [1] https://wiki.openstack.org/wiki/Meetings/Kolla#Agenda_for_the_next_meeting_.282021-08-18.29 > > Kind regards, > -yoctozepto > > > > On Sat, Aug 14, 2021 at 9:56 AM Brin Zhang(张百林) wrote: > > > > Thanks for working for this job. > > > > As we discussed support for log retrieval of Cyborg in Hackthon in China at April 2021, which improves our efficiency in locating and solving problems. > > > > And there are many companies have expressed interest in the Venus project, and we have already begun to cooperate. > > > > > > > > Thanks. > > > > > > > > brinzhang > > > > Inspur Electronic Information Industry Co.,Ltd. > > > > > > > > 发件人: Liye Pang(逄立业) > > 发送时间: 2021年8月14日 15:38 > > 收件人: openstack-discuss at lists.openstack.org > > 抄送: Brin Zhang(张百林) > > 主题: [venus] Project Progress > > > > > > > > Hi Team: > > > > Thanks to everyone for months of hard work, we have made great progress of venus, mainly as follows: > > > > 1. Add the retrieval of vitrage, cyborg and other modules to venus. > > > > 2.Developed the deployment based on kolla-ansible of venus,the location is: > > > > > > https://review.opendev.org/c/openstack/kolla-ansible/+/793897 > > > > https://review.opendev.org/c/openstack/kolla/+/793795 > > > > 3.The configuration, Search,analysis of Venus are integrated into horizon in the form of plugin as the attached picture. > > > > > > > > Hope everyone will make persistent efforts to make venus easier and more practical. > > > > > > > > Regards, > > > > pangliye > > > > > From fungi at yuggoth.org Mon Aug 16 15:28:34 2021 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 16 Aug 2021 15:28:34 +0000 Subject: =?utf-8?B?562U5aSN?= =?utf-8?Q?=3A?= [venus] Project Progress In-Reply-To: <17b4f8555ee.12017cc7c7996.3189664691453804006@ghanshyammann.com> References: <211c0536f25940cf937d7a97c35cc4dc@inspur.com> <50331b43448244ce823832f87a708576@inspur.com> <17b4f8555ee.12017cc7c7996.3189664691453804006@ghanshyammann.com> Message-ID: <20210816152834.56h66ooupqfm3of6@yuggoth.org> On 2021-08-16 10:12:23 -0500 (-0500), Ghanshyam Mann wrote: [...] > On inclusion of non-official project. in Kolla, +1 on discussing > it with Kolla team in their meeting. In case it help, we have > added non-official projects in OpenStack Charms before - > https://review.opendev.org/c/openstack/governance/+/720533 [...] If you think about it though, deployment projects generally install plenty of software which isn't part of an official deliverable for one of our project teams (as dependencies or even just useful add-ons for the deployment). An obvious example: would we require a deployment project to ask permission from the TC to install MySQL/MariaDB? Those certainly aren't OpenStack projects, but you'd be hard-pressed to find a production OpenStack deployment without some variety of RDBMS. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From kennelson11 at gmail.com Mon Aug 16 15:47:17 2021 From: kennelson11 at gmail.com (Kendall Nelson) Date: Mon, 16 Aug 2021 08:47:17 -0700 Subject: [tc][all] Please Help On Collecting Pain Points In-Reply-To: References: Message-ID: At this point, it looks like we are still missing pain points from the following projects: Adjutant Ec2-API Mistral Monasca Murano Octavia OpenStack Chef OpenStack-Helm OpenStackAnsible OpenStackSDK Puppet OpenStack QA Rally Requirements Sahara Senlin Solum Storlets Tacker TripleO Vitrage Watcher Zaqar Zun If you all can help us collect pain points for those projects, I think we have all of them covered and can move forward drafting this into a goal. Also, if anyone is interested in being a goal champion (or helping to be a goal champion- we can have more than one person) please speak up! -Kendall (diablo_rojo) On Sun, Aug 15, 2021 at 11:51 AM Rico Lin wrote: > Hi all, > > Would like to bump this mail again. > We're currently collect pain points from project teams and operators. > Please help to fill them in: > https://etherpad.opendev.org/p/pain-point-elimination > > > *Rico Lin* > OIF Individual Board of directors, OpenStack TC, Multi-arch SIG chair, > Heat PTL, > Senior Software Engineer at EasyStack > > > On Tue, Jul 27, 2021 at 5:58 PM Kendall Nelson > wrote: > >> Looks like we've started making some progress in the etherpad[1] which is >> great- thank you to those that have already jotted ideas down- but we are >> still missing a fair number of projects.. >> >> If we want pain points fixing to be a community goal, we should get them >> collected ASAP. If there is anything I can help with, please let me know! >> >> -Kendall (diablo_rojo) >> >> [1] https://etherpad.opendev.org/p/pain-point-elimination >> >> On Thu, Jul 15, 2021 at 8:04 AM Rico Lin wrote: >> >>> Dear all >>> As a proposal for pre-select goals for Yoga [1]. We need to figure out >>> the possibility. >>> >>> *I would like to ask each project team, SIG, and pop-up if you can >>> kindly provide the major pain point you have (and better to be fixable by >>> bugs/features).* >>> >>> *What you can help with is added in pain point information in [2].* >>> *Information like pain point topic, description, and ideas on how to >>> targeting them.* >>> >>> *Why this is important?* >>> I think this data allows us to see clearly if we can have goals like >>> `eliminate pain points`. >>> >>> *What's after this?* >>> If we can make sure this can be a goal material, we might be able to >>> have this as a goal and allow project teams to focus on one of their most >>> important issues. >>> >>> >>> As an alternative, we might be able to collect from user side with a >>> user survey, but that's more like a really long-term plan for this. >>> >>> [1] https://etherpad.opendev.org/p/y-series-goals >>> [2] https://etherpad.opendev.org/p/pain-point-elimination >>> >>> *Rico Lin* >>> OIF Board director, OpenStack TC, Multi-arch SIG chair, Heat PTL, >>> Senior Software Engineer at EasyStack >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From radoslaw.piliszek at gmail.com Mon Aug 16 15:49:40 2021 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Mon, 16 Aug 2021 17:49:40 +0200 Subject: =?UTF-8?B?UmU6IOetlOWkjTogW3ZlbnVzXSBQcm9qZWN0IFByb2dyZXNz?= In-Reply-To: <20210816152834.56h66ooupqfm3of6@yuggoth.org> References: <211c0536f25940cf937d7a97c35cc4dc@inspur.com> <50331b43448244ce823832f87a708576@inspur.com> <17b4f8555ee.12017cc7c7996.3189664691453804006@ghanshyammann.com> <20210816152834.56h66ooupqfm3of6@yuggoth.org> Message-ID: On Mon, Aug 16, 2021 at 5:29 PM Jeremy Stanley wrote: > > On 2021-08-16 10:12:23 -0500 (-0500), Ghanshyam Mann wrote: > [...] > > On inclusion of non-official project. in Kolla, +1 on discussing > > it with Kolla team in their meeting. In case it help, we have > > added non-official projects in OpenStack Charms before - > > https://review.opendev.org/c/openstack/governance/+/720533 > [...] > > If you think about it though, deployment projects generally install > plenty of software which isn't part of an official deliverable for > one of our project teams (as dependencies or even just useful > add-ons for the deployment). An obvious example: would we require > a deployment project to ask permission from the TC to install > MySQL/MariaDB? Those certainly aren't OpenStack projects, but you'd > be hard-pressed to find a production OpenStack deployment without > some variety of RDBMS. Yeah, I definitely treat it as a team-internal decision. -yoctozepto > -- > Jeremy Stanley From stefan.hoffmann at cloudandheat.com Mon Aug 16 16:05:04 2021 From: stefan.hoffmann at cloudandheat.com (Stefan Hoffmann) Date: Mon, 16 Aug 2021 18:05:04 +0200 Subject: [cinder] discuss nas_secure options and root_squash (prohibiting root access to share) Message-ID: <9884c0fb2ffac6ef7ab9aeae2d1c692149a5a799.camel@cloudandheat.com> Hi cinder team, like discussed in the last meeting, I prepared a list [1] of combinations of the nas_secure options and when to use them. If one want to prohibit root access to NFS share, only setting nas_secure_file_operations and nas_secure_file_permissions to true is a useful option, I think. (Option 4) But also the nas_secure_file_operations is not useful to determine if _qemu_img_info and fs access check at _connect_device should be done with root user or cinder user. So I will update the change [2] like proposed in the etherpad. Feel free to add other use cases and hints for the options to [1] and discuss about the proposed change. Regards Stefan [1] https://etherpad.opendev.org/p/gSotXYAZ3JfJE8FEpMpS [2] https://review.opendev.org/c/openstack/cinder/+/802882 Initial Bug: https://bugs.launchpad.net/cinder/+bug/1938196?comments=all From fungi at yuggoth.org Mon Aug 16 16:20:27 2021 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 16 Aug 2021 16:20:27 +0000 Subject: [ops][security-sig] KVM AMD vulnerabilities (CVE-2021-3653, CVE-2021-3656) Message-ID: <20210816162027.kl37cgf5gtqfv7ct@yuggoth.org> I usually don't do this, but as it is likely to be a widespread concern across many OpenStack deployments I thought it would be a good idea to bring the situation to everyone's attention and help spread the word. Today, two new vulnerabilities were announced in the Linux KVM implementation for AMD processors (CVE-2021-3653 and CVE-2021-3656): https://www.openwall.com/lists/oss-security/2021/08/16/1 The impact described there indicates that these could be leveraged by guest virtual machines to gain access to their underlying hypervisor host servers. If you run a KVM-based deployment on AMD processors, please be on the lookout for updates from your Linux distribution and apply them at the earliest opportunity. Also consider temporarily enacting the mitigations listed in the advisory (e.g. disabling nested virtualization in the kvm_amd module). -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From DHilsbos at performair.com Mon Aug 16 16:31:25 2021 From: DHilsbos at performair.com (DHilsbos at performair.com) Date: Mon, 16 Aug 2021 16:31:25 +0000 Subject: [victoria][ops][horizon][neutron] Network not available to use by Members in Horizon In-Reply-To: <2452154.BiziIVhrhC@p1> References: <0670B960225633449A24709C291A525251C78C29@COM03.performair.local> <2452154.BiziIVhrhC@p1> Message-ID: <0670B960225633449A24709C291A525251C7BBB2@COM03.performair.local> All; Thank you for your responses. I probably should have mentioned that the network in question is an external, provider network. Some additional Googling indicated that such networks get an RBAC rule (use-as-external) which limits what non-admins can do with them, even against the "owning" project. I added a countering RBAC rule (use-as-shared) which targets only the project in question, and that resolved the observer issues. Thank you, Dominic L. Hilsbos, MBA Vice President – Information Technology Perform Air International Inc. DHilsbos at PerformAir.com www.PerformAir.com -----Original Message----- From: Slawek Kaplonski [mailto:skaplons at redhat.com] Sent: Monday, August 16, 2021 12:53 AM To: openstack-discuss at lists.openstack.org Cc: Dominic Hilsbos Subject: Re: [victoria][ops][horizon][neutron] Network not available to use by Members in Horizon Hi, On piątek, 13 sierpnia 2021 18:25:03 CEST DHilsbos at performair.com wrote: > All; > > We just discovered, this morning, that Members of one of our projects > can't see the project's network, in order to use it in Instance > creation. If an Administrator creates a Port, the Member user can > then use it to create an Instance. > > Most of our activity to this point has been by Administrators, this is > the first time we've opened a project up to users with the Member level. > > Is this expected behavior? Please check what project is owner of the network and how are Your policies configured. By default owner (project) of the network should always see it and be able to create port in own network. > > Thank you, > > Dominic L. Hilsbos, MBA > Vice President - Information Technology Perform Air International Inc. > DHilsbos at PerformAir.com > www.PerformAir.com -- Slawek Kaplonski Principal Software Engineer Red Hat From victoria at vmartinezdelacruz.com Mon Aug 16 19:08:17 2021 From: victoria at vmartinezdelacruz.com (=?UTF-8?Q?Victoria_Mart=C3=ADnez_de_la_Cruz?=) Date: Mon, 16 Aug 2021 21:08:17 +0200 Subject: [manila] Propose haixin to manila-core In-Reply-To: <151b8c17d90c474b85f7d74e01a6a42f@inspur.com> References: <151b8c17d90c474b85f7d74e01a6a42f@inspur.com> Message-ID: Huge +1 for Haixin! Haixin made several great contributions to Manila, I'm truly happy to see him being nominated for coredom. Best, V On Thu, Aug 12, 2021 at 2:55 AM Brin Zhang(张百林) wrote: > +2 > > I see that Haixin’s contribution to the Manila project is outstanding and > continues to contribute. I am very happy that he can be recognized by the > Manila team. > > brinzhang > Inspur Electronic Information Industry Co.,Ltd. > -----邮件原件----- > 发件人: Goutham Pacha Ravi [mailto:gouthampravi at gmail.com] > 发送时间: 2021年8月12日 5:59 > 收件人: OpenStack Discuss > 主题: [manila] Propose haixin to manila-core > > Hello Zorillas, > > Haixin (haixin77 on Launchpad, haixin on OFTC) has been contributing to > manila since the Train release. He is part of a team that operates manila > at scale at Inspur and supports their storage integrations within > OpenStack. He diligently files bug reports, interacts with the community > and has thus far contributed several important perf-scale improvements > across the service stack. He also provides useful review feedback to fellow > contributors, and participates in team-efforts such as bug squashes, review > jams and mentorship of new contributors. I'm delighted to note that he > wants to take on some more maintenance responsibility [2]. > > So, with your support I'd like to add haixin to the manila-core group on > gerrit. This "power" comes with significant responsibility and I'm hoping > haixin will ramp up soon and help share some of the load from the existing > maintainers. Please let me know your thoughts, +/- 1s, 2s, 2-cents, etc! > > Thanks, > Goutham > > [1] > https://www.stackalytics.io/?user_id=haixin77&project_type=all&release=all&metric=person-day&module=manila-group > [2] > https://docs.openstack.org/manila/latest/contributor/manila-review-policy.html > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From victoria at vmartinezdelacruz.com Mon Aug 16 19:13:54 2021 From: victoria at vmartinezdelacruz.com (=?UTF-8?Q?Victoria_Mart=C3=ADnez_de_la_Cruz?=) Date: Mon, 16 Aug 2021 21:13:54 +0200 Subject: [manila] We're having an OSC Hack-a-thon - Aug 18-20th 2021 In-Reply-To: References: Message-ID: Thanks a lot for leading this Goutham and Maari! Definitely quite excited by this effort and looking forward to meeting with you all this week. Cheers, V On Fri, Aug 13, 2021 at 9:38 AM Goutham Pacha Ravi wrote: > Hi Zorillas and other interested stackers, > > tl;dr: > - We're swarming to add missing OSC commands to python-manilaclient > between 18th-20th Aug 2021, join us. > - Kick-off Aug 18th at 1400 UTC, Mid-point check Aug 19th, 1500 UTC, > Close-out Aug 20th, 1500 UTC on > https://meetpad.opendev.org/manila-xena-hackathon > > Now for the longer version: > > As discussed at our IRC meeting today [1], I'm excited to share the nitty > gritties of the upcoming OSC hack-a-thon. We'd be delighted to welcome > existing and new contributors to come join us in the quest to achieve CLI > parity in the OpenStackClient plugin within python-manilaclient. > > The work is being tracked here: > https://tree.taiga.io/project/gouthampacha-openstack-manila-osc-integration-with-python-manilaclient/kanban > > The commands we're targeting are also featured in a specification: https://specs.openstack.org/openstack/manila-specs/specs/release_independent/manila-support-openstackclient.html > > > The fine print for the hack-a-thon: > > - Maari Tamm has been the force behind this effort so far, and she's put > up a very helpful "Getting Started" wiki [2] that we intend to expand > through the hack-a-thon and finally add to the project's Contributor Docs. > There are also several examples of recent additions [3][4][5] that could > serve as inspiration. > - You're free to create, claim and edit Taiga cards for the implementation > you're chasing, we highly recommend picking only one card, and not claiming > something someone else already has. Please reach out to gouthamr/maaritamm > if you have to be added to the taiga board. > - Also, Add yourself as a "watcher" to two other Taiga cards that someone > else is implementing, this will mean that you will be a code reviewer on > these implementations! > - You can work in teams - min size: 1, max size: 3 > - You can submit code between Aug 18th 1200 UTC and Aug 21st 1200 UTC to > count towards this hack-a-thon > - A day before the hack-a-thon, a few of us will gather to prep taiga.io > cards, communicate with owners if there are conflicts, pre-reqs, etc. > - During the hack-a-thon, we'll use #openstack-manila on OFTC to chat, and > hop onto a meetpad room: https://meetpad.opendev.org/manila-xena-hackathon > when required. > - We'll have a half-hour kick-off session on Aug 18th at 1400 UTC > - We'll use the manila community meeting hour as a mid-point status check > (Aug 19th, 1500 UTC) > - We'll have a half-hour close out meeting to discuss reviews, AIs and > futures (grab your beers) (Aug 20th, 1500 UTC) > > I'm quite excited to participate in this, and I hope you are too. Please > feel free to reach out here or on OFTC's #openstack-manila if you have any > questions! > > Thanks, > Goutham > > [1] > https://meetings.opendev.org/meetings/manila/2021/manila.2021-08-12-15.00.log.html#l-40 > [2] > https://docs.google.com/document/d/1Kc02fO_ei-6NxPm_b6mnFbf-6MVdjMk71mFqX1aeEIs/edit > [3] https://review.opendev.org/c/openstack/python-manilaclient/+/772393 > [4] https://review.opendev.org/c/openstack/python-manilaclient/+/762754 > [5] https://review.opendev.org/c/openstack/python-manilaclient/+/701229 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ces.eduardo98 at gmail.com Mon Aug 16 19:56:49 2021 From: ces.eduardo98 at gmail.com (Carlos Silva) Date: Mon, 16 Aug 2021 16:56:49 -0300 Subject: [manila] Propose haixin to manila-core In-Reply-To: References: <151b8c17d90c474b85f7d74e01a6a42f@inspur.com> Message-ID: +1! Thank you for your contributions, Haixin! Regards, Carlos Em seg., 16 de ago. de 2021 às 16:09, Victoria Martínez de la Cruz < victoria at vmartinezdelacruz.com> escreveu: > Huge +1 for Haixin! > > Haixin made several great contributions to Manila, I'm truly happy to see > him being nominated for coredom. > > Best, > > V > > On Thu, Aug 12, 2021 at 2:55 AM Brin Zhang(张百林) > wrote: > >> +2 >> >> I see that Haixin’s contribution to the Manila project is outstanding and >> continues to contribute. I am very happy that he can be recognized by the >> Manila team. >> >> brinzhang >> Inspur Electronic Information Industry Co.,Ltd. >> -----邮件原件----- >> 发件人: Goutham Pacha Ravi [mailto:gouthampravi at gmail.com] >> 发送时间: 2021年8月12日 5:59 >> 收件人: OpenStack Discuss >> 主题: [manila] Propose haixin to manila-core >> >> Hello Zorillas, >> >> Haixin (haixin77 on Launchpad, haixin on OFTC) has been contributing to >> manila since the Train release. He is part of a team that operates manila >> at scale at Inspur and supports their storage integrations within >> OpenStack. He diligently files bug reports, interacts with the community >> and has thus far contributed several important perf-scale improvements >> across the service stack. He also provides useful review feedback to fellow >> contributors, and participates in team-efforts such as bug squashes, review >> jams and mentorship of new contributors. I'm delighted to note that he >> wants to take on some more maintenance responsibility [2]. >> >> So, with your support I'd like to add haixin to the manila-core group on >> gerrit. This "power" comes with significant responsibility and I'm hoping >> haixin will ramp up soon and help share some of the load from the existing >> maintainers. Please let me know your thoughts, +/- 1s, 2s, 2-cents, etc! >> >> Thanks, >> Goutham >> >> [1] >> https://www.stackalytics.io/?user_id=haixin77&project_type=all&release=all&metric=person-day&module=manila-group >> [2] >> https://docs.openstack.org/manila/latest/contributor/manila-review-policy.html >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ashlee at openstack.org Mon Aug 16 21:29:09 2021 From: ashlee at openstack.org (Ashlee Ferguson) Date: Mon, 16 Aug 2021 16:29:09 -0500 Subject: OpenInfra Live - August 19 at 9am CT Message-ID: Hi everyone, This week’s OpenInfra Live episode is brought to you by the OpenStack community. For the uninitiated, OpenStack's role in programmable infrastructure can be a little hard to understand unless you know its capabilities and how it works. Furthermore, to some people, OpenStack looks very similar to virtualization or simply like existing public cloud offerings. To fully understand this cloud platform, we will start at the origins of cloud technology and end at how today's OpenStack works. Episode: OpenStack Basics Date and time: August 19 at 9am CT (1400 UTC) You can watch us live on: YouTube: https://www.youtube.com/watch?v=hGRkdYu6I5k LinkedIn: https://www.linkedin.com/feed/update/urn:li:ugcPost:6831694874451042304/ Facebook: https://www.facebook.com/104139126308032/posts/4235953959793174/ WeChat: recording will be posted on OpenStack WeChat after the live stream Speakers: Ben Silverman, CBTS Ildiko Vancsa, Open Infrastructure Foundation Have an idea for a future episode? Share it now at ideas.openinfra.live . Thanks, Ashlee -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Mon Aug 16 21:35:32 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Mon, 16 Aug 2021 16:35:32 -0500 Subject: [all][tc] Technical Committee next weekly meeting on Aug 19th at 1500 UTC Message-ID: <17b50e41dc0.1151c354920925.431459325648627296@ghanshyammann.com> Hello Everyone, Technical Committee's next weekly meeting is scheduled for Aug 19th at 1500 UTC. If you would like to add topics for discussion, please add them to the below wiki page by Wednesday, Aug 18th, at 2100 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting -gmann From ihrachys at redhat.com Tue Aug 17 00:20:02 2021 From: ihrachys at redhat.com (Ihar Hrachyshka) Date: Mon, 16 Aug 2021 20:20:02 -0400 Subject: [neutron][ovn] support for stateless NAT for floating ip in ml2 ovn In-Reply-To: References: Message-ID: <20210817002002.252368-1-ihrachys@redhat.com> > Hi all, > > OVN support stateless NAT operations [1] for use case of 1:1 mapped > between inner and external ips, i.e dnat_and_snat rule. In openstack is > the floating ip use-case. Looking on ml2 ovn support it seem that it > only support floating ip with connection tracking. Can ml2 ovn support > also the stateless NAT option? Is there concerns using stateless NAT? Hi Moshe, you are talking about an "option". Do you mean OpenStack would have a new API extension for FIPs to choose it? Or a configuration option? AFAIU the only limitation for stateless dnat_and_snat rules in OVN is that the mapping must be 1:1, which I think is always the case with OpenStack FIPs (fixed_ip_address attribute is not a list). If so, perhaps always using stateless NAT rules is the way to go (so no api or config option). Am I missing something? I am not aware of any concerns using stateless NAT. But to clarify your motivation: do you expect it to perform better cpu/bandwidth wise? Thanks, Ihar From miguel at mlavalle.com Tue Aug 17 02:13:50 2021 From: miguel at mlavalle.com (Miguel Lavalle) Date: Mon, 16 Aug 2021 21:13:50 -0500 Subject: [neutron] bug deputy report August 9th to 15th Message-ID: Hi, Here's this week's bugs deputy report: High ==== https://bugs.launchpad.net/neutron/+bug/1939924 [ovn] NeutronNetworks.create_and_delete_subnets failing in concurrent scenario. Needs owner Medium ====== https://bugs.launchpad.net/neutron/+bug/1939403 [ovn] Tag on localnet port is not changed when proivder segment is updated. Assigned to Jakub Libosvar https://bugs.launchpad.net/neutron/+bug/1939429 [periodic] "neutron-ovn-tempest-ovs-master-fedora" failing with Fedora 34. Assigned to Rodolfo Alonso https://bugs.launchpad.net/neutron/+bug/1939432 Concurrent DHCP agent updates can result in a DB lock. Assigned to Rodolfo Alonso. Proposed fix: https://review.opendev.org/c/openstack/neutron/+/804218 https://bugs.launchpad.net/neutron/+bug/1939558 Security group log entry remains in the database after its security group is deleted. Assigned to Slawek Kaplonski. Proposed fix: https://review.opendev.org/c/openstack/neutron/+/804237 https://bugs.launchpad.net/neutron/+bug/1939704 db-sync script may fail when migrating from ovs to ovn. Assigned to Jakub Libosvar. Proposed fix: https://review.opendev.org/c/openstack/neutron/+/804405 https://bugs.launchpad.net/neutron/+bug/1940009 Some options are missing from neutron.conf generated by "tox -e genconfig". Owner assigned Incomplete ======== https://bugs.launchpad.net/neutron/+bug/1939723 neutron-ovn-db-sync generates insufficient flow https://bugs.launchpad.net/neutron/+bug/1939726 neutron-ovn-db-sync error during generate OVN DB RFEs ==== https://bugs.launchpad.net/neutron/+bug/1939602 [RFE] Add a memory profiler. Proposed implementation: https://review.opendev.org/c/openstack/neutron/+/803034 (Rodolfo Alonso) Invalid ===== https://bugs.launchpad.net/neutron/+bug/1939374 [OVN] Support baremetal type vnic https://bugs.launchpad.net/neutron/+bug/1939514 test_dvr_fip_and_router_namespace_rules_with_address_scopes_match iptables failure -------------- next part -------------- An HTML attachment was scrubbed... URL: From gfidente at redhat.com Tue Aug 17 09:14:04 2021 From: gfidente at redhat.com (Giulio Fidente) Date: Tue, 17 Aug 2021 11:14:04 +0200 Subject: [tripleo] Y cycle PTL nominations from 17th August In-Reply-To: References: Message-ID: <42180a17-fad6-b20b-983b-21eff5cb92f6@redhat.com> On 8/13/21 3:25 PM, Amy Marrich wrote: > Marios thank you for all your hard work over the last 2 cycles! +1 thank you! I can't commit the necessary time and resources to do PTL well but I am amazed by the great work that you and every person before you did. -- Giulio Fidente GPG KEY: 08D733BA From toky0ghoul at yandex.com Tue Aug 17 09:36:06 2021 From: toky0ghoul at yandex.com (toky0) Date: Tue, 17 Aug 2021 10:36:06 +0100 Subject: [juju][wallaby] no obvious space for container Message-ID: Hi, I'm running into error [1] while trying to create lxd containers in the maas+juju deployment guide. This is the output for juju spaces: Name Space ID Subnets alpha 0 default 2 192.168.220.0/24 2001:db8:0:220::/64 public 1 2001:db8::/64 Any pointers are appreciated. Let me know if you need more info. Regards, Sami [1] 3 started 2001:db8:0:220::40 controller0 focal default Deployed 3/lxd/0 down pending focal no obvious space for container "3/lxd/0", host machine has spaces: "default", "public" From smooney at redhat.com Tue Aug 17 11:32:09 2021 From: smooney at redhat.com (Sean Mooney) Date: Tue, 17 Aug 2021 12:32:09 +0100 Subject: [neutron][ovn] support for stateless NAT for floating ip in ml2 ovn In-Reply-To: <20210817002002.252368-1-ihrachys@redhat.com> References: <20210817002002.252368-1-ihrachys@redhat.com> Message-ID: <9096201007244d0732f019d1452575e61080e09c.camel@redhat.com> On Mon, 2021-08-16 at 20:20 -0400, Ihar Hrachyshka wrote: > > Hi all, > > > > OVN support stateless NAT operations [1] for use case of 1:1 mapped > > between inner and external ips, i.e dnat_and_snat rule. In openstack is > > the floating ip use-case. Looking on ml2 ovn support it seem that it > > only support floating ip with connection tracking. Can ml2 ovn support > > also the stateless NAT option? Is there concerns using stateless NAT? > > Hi Moshe, moshe out of interest does hardware offloaded ovs support hardware offloaded NAT (stateful or stateless) yet with connectx-6 dx? im not sure how feature enabled the connection tracker suppport is in the tc flower offload path so if this provided the ablity to do hardware offloaded floating ip nat i think this would be another point in favor of supporting it. the dpdk connection track is certelly still a bottle neck to dpdk perfromance so for ovs-dpdk i would expect to see a nice uplift in perfermance vs userspace contrack based nat so that is another reason to support this in my view. > > you are talking about an "option". Do you mean OpenStack would have a > new API extension for FIPs to choose it? Or a configuration option? > > AFAIU the only limitation for stateless dnat_and_snat rules in OVN is > that the mapping must be 1:1, which I think is always the case with > OpenStack FIPs (fixed_ip_address attribute is not a list). If so, > perhaps always using stateless NAT rules is the way to go (so no api or > config option). Am I missing something? > > I am not aware of any concerns using stateless NAT. But to clarify your > motivation: do you expect it to perform better cpu/bandwidth wise? im pretty sure this has been dicussed in the past. when david and i where working on neutron at intel on the learn action firewally and openflow bridge based routing a few years ago im pretty sure we discused using nat for FIPs when contrack suppport was first being added to ovs. this makes perfect sense to me to support FIPs via ovs openflow nat rules even on ml2/ovs i dont think that needs to be restricted to ovn although ill admit the ip tables nat entries in teh kernel router namespace proably scalse better the the ovs implemenation based on teh connection tracker today. stateful vs statless not is an interesting question. https://patchwork.ozlabs.org/project/openvswitch/cover/1570154179-14525-1-git-send-email-ankur.sharma at nutanix.com/ seams to imply that it must be implemented as a dnat_and_snat rule and i think that has the implication that since its stateless it will always take affect even in the same subnet? i dont know if we can restrict that so that the stateless rule only take effect if we are leaving the openstack env or not. looking at the patches i think that would be the main delta although i am just guessing that that will be a side efffect of the stateless implemenation after a quick glance. if i am correct about that i think we would need to opt into stateless nat for FIPs to maintain backwards compatiablity. this could be done at a port level with a new extentions, at a config level ideallly globally, or perhaps we can add an extion to the FIP api to specify that it shoudl be statefully or stateless. that latter is proably the cleanest of the 3 espically if we were to also support this in other ml2/drivers eventually but i dont think we could just swtich to stateless fips if it will afffect the east west flows in any way. if there is no affeect on east west flows and it only affect north/south folow into and out of the openstack cluster then moveign to statelesss in all cases likely would improve perfermance as there will be less contention for the connection tracker. > > Thanks, > Ihar > > From helena at openstack.org Tue Aug 17 14:18:51 2021 From: helena at openstack.org (helena at openstack.org) Date: Tue, 17 Aug 2021 09:18:51 -0500 (CDT) Subject: [all][elections][ptl][tc] Combined PTL/TC Nominations Kickoff Message-ID: <1629209931.530623580@apps.rackspace.com> Hello Everyone! Nominations for OpenStack PTLs (Project Team Leads) and TC (Technical Committee) positions (4 positions) are now open and will remain open until August 24, 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 ]( https://governance.openstack.org/election/#how-to-submit-a-candidacy )[ ]( https://governance.openstack.org/election/#how-to-submit-a-candidacy ) Please make sure to follow the candidacy file naming convention: candidates/yoga// (for example, "candidates/yoga/TC/stacker at example.org"). The name of the file should match an email address for your current OpenInfra Foundation Individual Membership. Take this opportunity to ensure that your Openinfra Foundation member profile contains current information: [ https://www.openstack.org/profile/ ]( https://www.openstack.org/profile/ ) Any OpenInfra 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 OpenInfra Foundation Individual Member. PTL candidates must also have contributed to the corresponding team during the Wallaby to Xena timeframe, September 25, 2020 00:00 UTC - August 24, 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 August 31, 2021 23:45 UTC through to September 7, 2021 23:45 UTC. The electorate for the TC election are the OpenInfra Foundation Individual Members who have a code contribution to one of the official teams over the Wallaby to Xena timeframe, September 25, 2020 00:00 UTC - August 24, 2021 00:00 UTC, as well as any Extra ATCs who are acknowledged by the TC. The electorate for a PTL election are the OpenInfra Foundation Individual Members who have a code contribution over the Wallaby to Xena timeframe, September 25, 2020 00:00 UTC - August 24, 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/ ]( https://governance.openstack.org/tc/reference/projects/ ) and their individual team pages include lists of corresponding Extra ATCs. Please find below the timeline: Nominations Start @ August 17, 2021 23:45 UTC Nominations End @ August 24, 2021 23:45 UTC Campaigning Start @ August 24, 2021 23:45 UTC Campaigning End @ August 31, 2021 23:45 UTC Election Start @ August 31, 2021 23:45 UTC Election End @ September 7, 2021 23:45 UTC Shortly after election officials approve candidates, they will be listed on the [ https://governance.openstack.org/election/ ]( https://governance.openstack.org/election/ ) page. The electorate is requested to confirm their email addresses in Gerrit prior to 2020-08-24 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 OpenInfra Foundation member profiles can be updated at [ https://review.openstack.org/#/settings/contact ]( https://review.openstack.org/#/settings/contact ) and [ https://www.openstack.org/profile/ ]( https://www.openstack.org/profile/ ) accordingly. As a reminder, be sure you mark civs as authorized to send e-mails to that address (this is new, due to a civs service policy change since the last round of elections). 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 ]( https://governance.openstack.org/election/#election-officials ) Cheers, Helena on behalf of the OpenStack Technical Election Officials -------------- next part -------------- An HTML attachment was scrubbed... URL: From balazs.gibizer at est.tech Tue Aug 17 14:54:36 2021 From: balazs.gibizer at est.tech (Balazs Gibizer) Date: Tue, 17 Aug 2021 16:54:36 +0200 Subject: [nova][placement] PTL nomination open Message-ID: <03OZXQ.1NTDOK9MY97N1@est.tech> Hi! As per [1] Nova (including Placement) PTL nomination period is open. As I noted in my Xena nomination[2] I'm not intended to run for a 4th cycle. If you have any question about being a nova PTL then feel free to contact me publicly or privately. Cheers, gibi [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-August/024191.html [2] http://lists.openstack.org/pipermail/openstack-discuss/2021-March/020834.html From fungi at yuggoth.org Tue Aug 17 15:05:27 2021 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 17 Aug 2021 15:05:27 +0000 Subject: [OSSA-2021-004] Neutron: Linuxbridge ARP filter bypass on Netfilter platforms (CVE-2021-38598) Message-ID: <20210817150527.dmbtpofzj2uckwo7@yuggoth.org> =================================================================== OSSA-2021-004: Linuxbridge ARP filter bypass on Netfilter platforms =================================================================== :Date: August 17, 2021 :CVE: CVE-2021-38598 Affects ~~~~~~~ - Neutron: <16.4.1, >=17.0.0 <17.1.3, ==18.0.0 Description ~~~~~~~~~~~ Jake Yip with ARDC and Justin Mammarella with the University of Melbourne reported a vulnerability in Neutron's linuxbridge driver on newer Netfilter-based platforms (the successor to IPTables). By sending carefully crafted packets, anyone in control of a server instance connected to the virtual switch can impersonate the hardware addresses of other systems on the network, resulting in denial of service or in some cases possibly interception of traffic intended for other destinations. Only deployments using the linuxbridge driver with ebtables-nft are affected. Patches ~~~~~~~ - https://review.opendev.org/804058 (Train) - https://review.opendev.org/804057 (Ussuri) - https://review.opendev.org/804056 (Victoria) - https://review.opendev.org/785917 (Wallaby) - https://review.opendev.org/785177 (Xena) Credits ~~~~~~~ - Jake Yip from ARDC (CVE-2021-38598) - Justin Mammarella from University of Melbourne (CVE-2021-38598) References ~~~~~~~~~~ - https://launchpad.net/bugs/1938670 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-38598 Notes ~~~~~ - The stable/train branch is under extended maintenance and will receive no new point releases, but a patch for it is provided as a courtesy. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From sylvain.bauza at gmail.com Tue Aug 17 15:20:46 2021 From: sylvain.bauza at gmail.com (Sylvain Bauza) Date: Tue, 17 Aug 2021 17:20:46 +0200 Subject: [all][elections][ptl][tc] Combined PTL/TC Nominations Kickoff In-Reply-To: <1629209931.530623580@apps.rackspace.com> References: <1629209931.530623580@apps.rackspace.com> Message-ID: Le mar. 17 août 2021 à 16:21, helena at openstack.org a écrit : > Hello Everyone! > > > Nominations for OpenStack PTLs (Project Team Leads) and TC (Technical > Committee) positions (4 positions) are now open and will remain > open until August 24, 2021 23:45 UTC. > > > When I look at the official election site, I only see the PTL nominations should be open at 23.45 UTC. So, they are not yet open, right ? Thanks, Sylvain 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/yoga// (for > example, "candidates/yoga/TC/stacker at example.org"). > > The name of the file should match an email address for your > current OpenInfra Foundation Individual Membership. Take this opportunity > to ensure that your Openinfra Foundation member profile contains current > information: https://www.openstack.org/profile/ > > Any OpenInfra 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 OpenInfra Foundation Individual Member. PTL candidates must also have > contributed to the corresponding team during the Wallaby to Xena timeframe, > September 25, 2020 00:00 UTC - August 24, 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 August 31, 2021 23:45 > UTC through to September 7, 2021 23:45 UTC. The electorate for the > TC election are the OpenInfra Foundation Individual Members who have a > code contribution to one of the official teams over > the Wallaby to Xena timeframe, September 25, 2020 00:00 UTC - August 24, > 2021 00:00 UTC, as well as any Extra ATCs who are acknowledged by the TC. > The electorate for a PTL election are the OpenInfra Foundation Individual > Members who have a code contribution over > the Wallaby to Xena timeframe, September 25, 2020 00:00 UTC - August 24, > 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: > > Nominations Start @ August 17, 2021 23:45 UTC > Nominations End @ August 24, 2021 23:45 UTC > Campaigning Start @ August 24, 2021 23:45 UTC > Campaigning End @ August 31, 2021 23:45 UTC > Election Start @ August 31, 2021 23:45 UTC > Election End @ September 7, 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 2020-08-24 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 OpenInfra Foundation member profiles can be updated at > https://review.openstack.org/#/settings/contact and > https://www.openstack.org/profile/ accordingly. As a reminder, be sure > you mark civs as authorized to send e-mails to that address (this is new, > due to a civs service policy change since the last round of elections). > > 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 > > Cheers, > Helena > on behalf of the OpenStack Technical Election Officials > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Tue Aug 17 15:37:44 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Tue, 17 Aug 2021 10:37:44 -0500 Subject: [release] Y cycle PTL nominations from 17th August In-Reply-To: References: Message-ID: <17b54c2e5fb.11e18a27828433.414414668378904692@ghanshyammann.com> Thanks, Herve for all your help and hard work done in the release. -gmann ---- On Mon, 16 Aug 2021 02:49:06 -0500 Herve Beraud wrote ---- > Hello, > > in case you missed in, the OpenStack Y cycle election season is soon > upon us starting 17th August [1]. > > I do not intend to run for a third cycle as ptl. I think it is healthy for the project to > have new energy and ideas brought by a new ptl. > > I'd like to encourage anyone who is considering this to read the info > from [1] and in particular prepare a nomination [2]. Feel free to > reach out to me if you have any questions or concerns. If you *are* > thinking about it bear in mind there are many experienced people > around that can and will help you. > > Thanks for your attention, > > [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-August/024093.html > [2] https://governance.openstack.org/election/#how-to-submit-a-candidacy > -- > Hervé BeraudSenior Software Engineer at Red Hatirc: hberaudhttps://github.com/4383/https://twitter.com/4383hberaud > > From fungi at yuggoth.org Tue Aug 17 15:38:46 2021 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 17 Aug 2021 15:38:46 +0000 Subject: [all][elections][ptl][tc] Combined PTL/TC Nominations Kickoff In-Reply-To: References: <1629209931.530623580@apps.rackspace.com> Message-ID: <20210817153846.pr2yckqjthcgcmjc@yuggoth.org> On 2021-08-17 17:20:46 +0200 (+0200), Sylvain Bauza wrote: > Le mar. 17 août 2021 à 16:21, helena at openstack.org a écrit : [...] > When I look at the official election site, I only see the PTL > nominations should be open at 23.45 UTC. So, they are not yet > open, right ? [...] > > Nominations Start @ August 17, 2021 23:45 UTC [...] The message you quoted seems to confirm this as well. That said, you can upload your candidacy earlier, the election officials simply won't be confirming them until after the start time. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From helena at openstack.org Tue Aug 17 17:54:14 2021 From: helena at openstack.org (helena at openstack.org) Date: Tue, 17 Aug 2021 12:54:14 -0500 (CDT) Subject: [all][elections][ptl][tc] Combined PTL/TC Nominations Kickoff In-Reply-To: References: <1629209931.530623580@apps.rackspace.com> Message-ID: <1629222854.394317125@apps.rackspace.com> Correct, I mistakenly sent the email a bit early. It will be opening in a few hours. Cheers, Helena -----Original Message----- From: "Sylvain Bauza" Sent: Tuesday, August 17, 2021 10:20am To: helena at openstack.org Cc: "OpenStack Discuss" , "Ian Y. Choi" , "Amy Marrich" , "Belmiro Moreira" , "Andy McCrae" Subject: Re: [all][elections][ptl][tc] Combined PTL/TC Nominations Kickoff Le mar. 17 août 2021 à 16:21, [ helena at openstack.org ]( mailto:helena at openstack.org ) <[ helena at openstack.org ]( mailto:helena at openstack.org )> a écrit : Hello Everyone! Nominations for OpenStack PTLs (Project Team Leads) and TC (Technical Committee) positions (4 positions) are now open and will remain open until August 24, 2021 23:45 UTC. When I look at the official election site, I only see the PTL nominations should be open at 23.45 UTC. So, they are not yet open, right ? Thanks, Sylvain 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 ]( https://governance.openstack.org/election/#how-to-submit-a-candidacy )[ ]( https://governance.openstack.org/election/#how-to-submit-a-candidacy ) Please make sure to follow the candidacy file naming convention: candidates/yoga// (for example, "candidates/yoga/TC/[ stacker at example.org ]( mailto:stacker at example.org )"). The name of the file should match an email address for your current OpenInfra Foundation Individual Membership. Take this opportunity to ensure that your Openinfra Foundation member profile contains current information: [ https://www.openstack.org/profile/ ]( https://www.openstack.org/profile/ ) Any OpenInfra 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 OpenInfra Foundation Individual Member. PTL candidates must also have contributed to the corresponding team during the Wallaby to Xena timeframe, September 25, 2020 00:00 UTC - August 24, 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 August 31, 2021 23:45 UTC through to September 7, 2021 23:45 UTC. The electorate for the TC election are the OpenInfra Foundation Individual Members who have a code contribution to one of the official teams over the Wallaby to Xena timeframe, September 25, 2020 00:00 UTC - August 24, 2021 00:00 UTC, as well as any Extra ATCs who are acknowledged by the TC. The electorate for a PTL election are the OpenInfra Foundation Individual Members who have a code contribution over the Wallaby to Xena timeframe, September 25, 2020 00:00 UTC - August 24, 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/ ]( https://governance.openstack.org/tc/reference/projects/ ) and their individual team pages include lists of corresponding Extra ATCs. Please find below the timeline: Nominations Start @ August 17, 2021 23:45 UTC Nominations End @ August 24, 2021 23:45 UTC Campaigning Start @ August 24, 2021 23:45 UTC Campaigning End @ August 31, 2021 23:45 UTC Election Start @ August 31, 2021 23:45 UTC Election End @ September 7, 2021 23:45 UTC Shortly after election officials approve candidates, they will be listed on the [ https://governance.openstack.org/election/ ]( https://governance.openstack.org/election/ ) page. The electorate is requested to confirm their email addresses in Gerrit prior to 2020-08-24 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 OpenInfra Foundation member profiles can be updated at [ https://review.openstack.org/#/settings/contact ]( https://review.openstack.org/#/settings/contact ) and [ https://www.openstack.org/profile/ ]( https://www.openstack.org/profile/ ) accordingly. As a reminder, be sure you mark civs as authorized to send e-mails to that address (this is new, due to a civs service policy change since the last round of elections). 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 ]( https://governance.openstack.org/election/#election-officials ) Cheers, Helena on behalf of the OpenStack Technical Election Officials -------------- next part -------------- An HTML attachment was scrubbed... URL: From opensrloo at gmail.com Tue Aug 17 20:16:09 2021 From: opensrloo at gmail.com (Ruby Loo) Date: Tue, 17 Aug 2021 16:16:09 -0400 Subject: [ironic] Departure from full-time work on the project In-Reply-To: References: Message-ID: Bye for now Jay! I'm so sorry to see you leave, but glad I/we had the opportunity to meet and work with you. It has been fun! Thanks for everything you've done and good luck with the next chapter of your career! --ruby On Fri, Aug 13, 2021 at 12:10 PM Jay Faulkner wrote: > Hello everyone, > > As mentioned in the Ironic IRC meeting, I will no longer be working full > time on OpenStack Ironic after this week. It is my intention to continue > reviewing code for a small amount of time on the weekends until my context > around the project becomes too stale. > > Working on OpenStack Ironic has been the greatest adventure of my career > so far, but I'll mostly remember all the nice people I met along the way. > > Thanks, > Jay Faulkner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amy at demarco.com Tue Aug 17 20:16:59 2021 From: amy at demarco.com (Amy Marrich) Date: Tue, 17 Aug 2021 15:16:59 -0500 Subject: [nova][placement] PTL nomination open In-Reply-To: <03OZXQ.1NTDOK9MY97N1@est.tech> References: <03OZXQ.1NTDOK9MY97N1@est.tech> Message-ID: Thanks for all your hard work! Amy (spotz) On Tue, Aug 17, 2021 at 9:57 AM Balazs Gibizer wrote: > Hi! > > As per [1] Nova (including Placement) PTL nomination period is open. As > I noted in my Xena nomination[2] I'm not intended to run for a 4th > cycle. If you have any question about being a nova PTL then feel free > to contact me publicly or privately. > > Cheers, > gibi > > [1] > > http://lists.openstack.org/pipermail/openstack-discuss/2021-August/024191.html > [2] > > http://lists.openstack.org/pipermail/openstack-discuss/2021-March/020834.html > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amy at demarco.com Tue Aug 17 20:24:33 2021 From: amy at demarco.com (Amy Marrich) Date: Tue, 17 Aug 2021 15:24:33 -0500 Subject: [ironic] Departure from full-time work on the project In-Reply-To: References: Message-ID: Jay, You'll be missed! Thanks for everything you've done over the years. Amy (spotz) On Fri, Aug 13, 2021 at 11:06 AM Jay Faulkner wrote: > Hello everyone, > > As mentioned in the Ironic IRC meeting, I will no longer be working full > time on OpenStack Ironic after this week. It is my intention to continue > reviewing code for a small amount of time on the weekends until my context > around the project becomes too stale. > > Working on OpenStack Ironic has been the greatest adventure of my career > so far, but I'll mostly remember all the nice people I met along the way. > > Thanks, > Jay Faulkner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From skaplons at redhat.com Tue Aug 17 20:53:40 2021 From: skaplons at redhat.com (Slawek Kaplonski) Date: Tue, 17 Aug 2021 22:53:40 +0200 Subject: [neutron][elections] PTL non candidacy for Y cycle Message-ID: <24443596.64OI9Hj3fW@p1> Hi, It's been great 2 years for me when I had an honor to serve as Neutron PTL - yeah, time flies :) It has been pleasure to work with all of You on the Neutron project. We did a lot of great things during that time. But now, as I said in my last nomination [1], I'm not going to candidate for being PTL in the Yoga cycle. I think it's good for the project to have new leader every few cycles. That brings fresh ideas and new energy to the project. If You would be interested in that, to which I encourage anyone, and maybe have any questions, feel free to reach out to me in any way (irc, email, etc.). I will be more than happy to answer all Your questions. As for me, I'm not going anywhere. I'm still going to work on Neutron as I did so far. I will be of course very happy to help new PTL if that will be needed :) Once again thank You all for all Your help and supporting me in that role in the last 2 years and good luck to our new PTL! [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-March/ 020901.html -- Slawek Kaplonski Principal Software Engineer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From viroel at gmail.com Tue Aug 17 20:56:04 2021 From: viroel at gmail.com (Douglas) Date: Tue, 17 Aug 2021 17:56:04 -0300 Subject: [manila] Propose haixin to manila-core In-Reply-To: References: Message-ID: +1 haixin, thank you for your contributions to Manila. You will be a great addition to the team. On Wed, Aug 11, 2021 at 7:00 PM Goutham Pacha Ravi wrote: > Hello Zorillas, > > Haixin (haixin77 on Launchpad, haixin on OFTC) has been contributing > to manila since the Train release. He is part of a team that operates > manila at scale at Inspur and supports their storage integrations > within OpenStack. He diligently files bug reports, interacts with the > community and has thus far contributed several important perf-scale > improvements across the service stack. He also provides useful review > feedback to fellow contributors, and participates in team-efforts such > as bug squashes, review jams and mentorship of new contributors. I'm > delighted to note that he wants to take on some more maintenance > responsibility [2]. > > So, with your support I'd like to add haixin to the manila-core group > on gerrit. This "power" comes with significant responsibility and I'm > hoping haixin will ramp up soon and help share some of the load from > the existing maintainers. Please let me know your thoughts, +/- 1s, > 2s, 2-cents, etc! > > Thanks, > Goutham > > [1] > https://www.stackalytics.io/?user_id=haixin77&project_type=all&release=all&metric=person-day&module=manila-group > [2] > https://docs.openstack.org/manila/latest/contributor/manila-review-policy.html > > -- Douglas Salles Viroel -------------- next part -------------- An HTML attachment was scrubbed... URL: From ihrachys at redhat.com Tue Aug 17 22:10:02 2021 From: ihrachys at redhat.com (Ihar Hrachyshka) Date: Tue, 17 Aug 2021 18:10:02 -0400 Subject: [neutron][ovn] support for stateless NAT for floating ip in ml2 ovn In-Reply-To: References: <20210817002002.252368-1-ihrachys@redhat.com> <9096201007244d0732f019d1452575e61080e09c.camel@redhat.com> Message-ID: On Tue, Aug 17, 2021 at 3:14 PM Moshe Levi wrote: > > > > > -----Original Message----- > > From: Sean Mooney > > Sent: Tuesday, August 17, 2021 2:32 PM > > To: Ihar Hrachyshka ; openstack- > > discuss at lists.openstack.org > > Subject: Re: [neutron][ovn] support for stateless NAT for floating ip in ml2 > > ovn > > > > External email: Use caution opening links or attachments > > > > > > On Mon, 2021-08-16 at 20:20 -0400, Ihar Hrachyshka wrote: > > > > Hi all, > > > > > > > > OVN support stateless NAT operations [1] for use case of 1:1 mapped > > > > between inner and external ips, i.e dnat_and_snat rule. In openstack > > > > is the floating ip use-case. Looking on ml2 ovn support it seem > > > > that it only support floating ip with connection tracking. Can ml2 > > > > ovn support also the stateless NAT option? Is there concerns using > > stateless NAT? > > > > > > Hi Moshe, > > moshe out of interest does hardware offloaded ovs support hardware > > offloaded NAT (stateful or stateless) yet with connectx-6 dx? > So connectx-6 dx can offload NAT (just SNAT or DNAT), but in the case of dnat_and_snat rules offload won't work. > We need to optimize ovn to make it work because of it snat and dnat zones. We can offload stateless without changing ovn and the driver and the performance is better because we don't have the snat /dnat zone in ovn. > > > > > im not sure how feature enabled the connection tracker suppport is in the tc > > flower offload path so if this provided the ablity to do hardware offloaded > > floating ip nat i think this would be another point in favor of supporting it. > [ML] so the stateless nat we can do today. (we check it in openstack env and just adding stateless config manual in ovn tables. > > You mean like this? https://review.opendev.org/c/openstack/neutron/+/804807 (This also passed CI.) > > the dpdk connection track is certelly still a bottle neck to dpdk perfromance > > so for ovs-dpdk i would expect to see a nice uplift in perfermance vs > > userspace contrack based nat so that is another reason to support this in my > > view. > > > > > > you are talking about an "option". Do you mean OpenStack would have a > > > new API extension for FIPs to choose it? Or a configuration option? > I was talking about config option, because I wasn’t sure if we want to keep the stateful behavior or there are use case when customer will want to use stateful NAT. > I just can't figure out which scenario it would be, considering that an admin allocates addresses to FIP pools for monopolistic use by OpenStack, and FIPs are 1:1 mapped to fixed IP addresses. Which scenario do you have in mind? I understand the initial gut reaction to have it opt-in but IMHO it makes sense only if we can explain why switching to always-stateless won't work. > > > > > > AFAIU the only limitation for stateless dnat_and_snat rules in OVN is > > > that the mapping must be 1:1, which I think is always the case with > > > OpenStack FIPs (fixed_ip_address attribute is not a list). If so, > > > perhaps always using stateless NAT rules is the way to go (so no api > > > or config option). Am I missing something? > [ML] maybe this is why I raise this question here as I don't know the background of why it was implemented as stateful 😊 > > > > > > I am not aware of any concerns using stateless NAT. But to clarify > > > your > > > motivation: do you expect it to perform better cpu/bandwidth wise? > [ML] motivation is to enable ovs hardware offload to offload floating ip use-case and to improve performance. > > im pretty sure this has been dicussed in the past. > > when david and i where working on neutron at intel on the learn action > > firewally and openflow bridge based routing a few years ago im pretty sure > > we discused using nat for FIPs when contrack suppport was first being added > > to ovs. > > > > this makes perfect sense to me to support FIPs via ovs openflow nat rules > > even on ml2/ovs i dont think that needs to be restricted to ovn although ill > > admit the ip tables nat entries in teh kernel router namespace proably scalse > > better the the ovs implemenation based on teh connection tracker today. > > > > stateful vs statless not is an interesting question. > > https://patchwork.ozlabs.org/project/openvswitch/cover/1570154179- > > 14525-1-git-send-email-ankur.sharma at nutanix.com/ > > seams to imply that it must be implemented as a dnat_and_snat rule and i > > think that has the implication that since its stateless it will always take affect > > even in the same subnet? i dont know if we can restrict that so that the > > stateless rule only take effect if we are leaving the openstack env or not. > > I am not sure what you mean by saying "it will always take affect even in the same subnet". Could you please elaborate? AFAIU stateless NAT translation flows won't be reached when ports of the same logical switch communicate, same as they are not supposed to be triggered with ct_* rules. (Which is achieved by short-circuiting tables in OVN table architecture.) > > looking at the patches i think that would be the main delta although i am just > > guessing that that will be a side efffect of the stateless implemenation after a > > quick glance. if i am correct about that i think we would need to opt into > > stateless nat for FIPs to maintain backwards compatiablity. > > this could be done at a port level with a new extentions, at a config level > > ideallly globally, or perhaps we can add an extion to the FIP api to specify that > > it shoudl be statefully or stateless. that latter is proably the cleanest of the 3 > > espically if we were to also support this in other ml2/drivers eventually but i > > dont think we could just swtich to stateless fips if it will afffect the east west > > flows in any way. > > > > if there is no affeect on east west flows and it only affect north/south folow > > into and out of the openstack cluster then moveign to statelesss in all cases > > likely would improve perfermance as there will be less contention for the > > connection tracker. > [ML] in our test we didn't encounter effect on the east west flows. > > > > > > > > Thanks, > > > Ihar > > > > > > > > > > > From amy at demarco.com Tue Aug 17 22:28:03 2021 From: amy at demarco.com (Amy Marrich) Date: Tue, 17 Aug 2021 17:28:03 -0500 Subject: [neutron][elections] PTL non candidacy for Y cycle In-Reply-To: <24443596.64OI9Hj3fW@p1> References: <24443596.64OI9Hj3fW@p1> Message-ID: Thanks for all your hard work Slawek! Amy (spotz) > > On Aug 17, 2021, at 3:57 PM, Slawek Kaplonski wrote: > > Hi, > > It's been great 2 years for me when I had an honor to serve as Neutron PTL - > yeah, time flies :) > It has been pleasure to work with all of You on the Neutron project. We did a > lot of great things during that time. > But now, as I said in my last nomination [1], I'm not going to candidate for > being PTL in the Yoga cycle. I think it's good for the project to have new > leader every few cycles. That brings fresh ideas and new energy to the > project. > If You would be interested in that, to which I encourage anyone, and maybe > have any questions, feel free to reach out to me in any way (irc, email, > etc.). I will be more than happy to answer all Your questions. > > As for me, I'm not going anywhere. I'm still going to work on Neutron as I did > so far. > I will be of course very happy to help new PTL if that will be needed :) > > Once again thank You all for all Your help and supporting me in that role in > the last 2 years and good luck to our new PTL! > > [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-March/ > 020901.html > > -- > Slawek Kaplonski > Principal Software Engineer > Red Hat From sylvain.bauza at gmail.com Wed Aug 18 06:37:46 2021 From: sylvain.bauza at gmail.com (Sylvain Bauza) Date: Wed, 18 Aug 2021 08:37:46 +0200 Subject: [election][nova][placement] PTL candidacy for Yoga Message-ID: Hello Nova (and Placement) fellows, That's been some time I started to work on OpenStack and Nova in particular (I leave you guessing it [1]) but I feel this is time for me to run for the Nova PTL election and ask you to accept me for this hot seat (which is not a Yoga mat). First and foremost, I'd like to thank gibi for the hard work he did on the previous cycles, especially during this (hopefully) transient situation we currently face which challenges us in terms of teamwork. Running our team gatherings virtually twice is awfully exhausting and I also thank you all for supporting this situation. Hopefully our next PTG will be the last virtual one but who knows. I personally feel Nova now entered a period of quiet but productive pace. We accepted a solid amount of blueprints over the past cycles but we also delivered a decent ratio of them. That said, many challenges occur as of now which as a PTL I have the intention to continue to stress on and engage discussions between us how to solve them : - CI stability : We recently faced a couple of bugs that prevented us to merge code and I have the feeling that some of them are intertwined. I'd like us to identify all the stressing bits so we could prioritize any kind of tech debt fix that would help to gain better stability and not treat them as just standard bugs that we only look after our feature delivery duties. - Upgrades : I'm very happy to say we solved the long-running problem of version-to-next upgrades which are now painless. We have a couple of tools for helping operators to gain confidence before upgrades and we also have CI jobs that prove their stability. That said, I personally feel we now have another dimension of upgrades we barely scratched to define and I would like us to think about them. Placement reshapes and fast-forward-upgrades are for example two new features that Nova supports but I'd like us to take a second and identify all the improvements we could make for those (and prioritize efforts accordingly) - Contributors diversity : I don't think there is any surprise if I say that our Nova community is smaller than before. I don't think it's a problem and as I already said, we're productive. No, the concern that I have is that I'd love to have a way to help contributors that are maybe not having time to develop on Nova as a primary day-to-day job. We started to discuss on ways to define review priorities and I would like to pursue this direction by wondering what and how we could do for those contributors. Either way, I truly respect the ideal of Open Design. Whatever Nova becomes or evolves in the future, every single contributor is part of it and my role will be to make sure we have a consensus. Thanks, -Sylvain [1] 0x7DD -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralonsoh at redhat.com Wed Aug 18 07:12:28 2021 From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez) Date: Wed, 18 Aug 2021 09:12:28 +0200 Subject: [neutron][elections] PTL non candidacy for Y cycle In-Reply-To: References: <24443596.64OI9Hj3fW@p1> Message-ID: Thank you Slawek for your time and hard work. On Wed, Aug 18, 2021 at 12:35 AM Amy Marrich wrote: > Thanks for all your hard work Slawek! > > Amy (spotz) > > > > > On Aug 17, 2021, at 3:57 PM, Slawek Kaplonski > wrote: > > > > Hi, > > > > It's been great 2 years for me when I had an honor to serve as Neutron > PTL - > > yeah, time flies :) > > It has been pleasure to work with all of You on the Neutron project. We > did a > > lot of great things during that time. > > But now, as I said in my last nomination [1], I'm not going to candidate > for > > being PTL in the Yoga cycle. I think it's good for the project to have > new > > leader every few cycles. That brings fresh ideas and new energy to the > > project. > > If You would be interested in that, to which I encourage anyone, and > maybe > > have any questions, feel free to reach out to me in any way (irc, email, > > etc.). I will be more than happy to answer all Your questions. > > > > As for me, I'm not going anywhere. I'm still going to work on Neutron as > I did > > so far. > > I will be of course very happy to help new PTL if that will be needed :) > > > > Once again thank You all for all Your help and supporting me in that > role in > > the last 2 years and good luck to our new PTL! > > > > [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-March/ > > 020901.html > > > > -- > > Slawek Kaplonski > > Principal Software Engineer > > Red Hat > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at stackhpc.com Wed Aug 18 08:17:27 2021 From: mark at stackhpc.com (Mark Goddard) Date: Wed, 18 Aug 2021 09:17:27 +0100 Subject: [kolla] PTL non-candidacy Message-ID: Hi Koalas, As I suspect may be the case with many PTLs, I first took on the role largely because it needed to be done and no other candidates were forthcoming. As I settled into the role I found that I actually rather enjoyed it. The project has certainly come far since I first started using it in 2016, and I'm proud to have helped to steer the ship for a while. After 5 release cycles, the time has come to pass on the Kolla PTL hat to another Koala. I will still be actively involved in the community, and will be happy to help the next PTL while they get comfortable. Thank you to everyone who has supported me in this role, and to everyone who makes Kolla such a great community to be involved in. Long live Kolla! Cheers, Mark From lucasagomes at gmail.com Wed Aug 18 08:29:35 2021 From: lucasagomes at gmail.com (Lucas Alvares Gomes) Date: Wed, 18 Aug 2021 09:29:35 +0100 Subject: [neutron][elections] PTL non candidacy for Y cycle In-Reply-To: References: <24443596.64OI9Hj3fW@p1> Message-ID: Thank you for your hard work Slawek! On Wed, Aug 18, 2021 at 8:15 AM Rodolfo Alonso Hernandez wrote: > > Thank you Slawek for your time and hard work. > > On Wed, Aug 18, 2021 at 12:35 AM Amy Marrich wrote: >> >> Thanks for all your hard work Slawek! >> >> Amy (spotz) >> >> > >> > On Aug 17, 2021, at 3:57 PM, Slawek Kaplonski wrote: >> > >> > Hi, >> > >> > It's been great 2 years for me when I had an honor to serve as Neutron PTL - >> > yeah, time flies :) >> > It has been pleasure to work with all of You on the Neutron project. We did a >> > lot of great things during that time. >> > But now, as I said in my last nomination [1], I'm not going to candidate for >> > being PTL in the Yoga cycle. I think it's good for the project to have new >> > leader every few cycles. That brings fresh ideas and new energy to the >> > project. >> > If You would be interested in that, to which I encourage anyone, and maybe >> > have any questions, feel free to reach out to me in any way (irc, email, >> > etc.). I will be more than happy to answer all Your questions. >> > >> > As for me, I'm not going anywhere. I'm still going to work on Neutron as I did >> > so far. >> > I will be of course very happy to help new PTL if that will be needed :) >> > >> > Once again thank You all for all Your help and supporting me in that role in >> > the last 2 years and good luck to our new PTL! >> > >> > [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-March/ >> > 020901.html >> > >> > -- >> > Slawek Kaplonski >> > Principal Software Engineer >> > Red Hat >> From radoslaw.piliszek at gmail.com Wed Aug 18 08:41:16 2021 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Wed, 18 Aug 2021 10:41:16 +0200 Subject: [kolla] PTL non-candidacy In-Reply-To: References: Message-ID: On Wed, Aug 18, 2021 at 10:18 AM Mark Goddard wrote: > > Hi Koalas, Hi Mark, > As I suspect may be the case with many PTLs, I first took on the role > largely because it needed to be done and no other candidates were > forthcoming. As I settled into the role I found that I actually rather > enjoyed it. The project has certainly come far since I first started > using it in 2016, and I'm proud to have helped to steer the ship for a > while. After 5 release cycles, the time has come to pass on the Kolla > PTL hat to another Koala. I will still be actively involved in the > community, and will be happy to help the next PTL while they get > comfortable. Thank you to everyone who has supported me in this role, > and to everyone who makes Kolla such a great community to be involved > in. Thank you for being Kolla PTL and for the work you put into Kolla during those 5 cycles. By coincidence, it has also been 5 cycles as Kolla core for me! So, the only Kolla PTL I have known is you and now I am looking forward to seeing a new one. > Long live Kolla! Long live Kolla! -yoctozepto From mnasiadka at gmail.com Wed Aug 18 09:16:52 2021 From: mnasiadka at gmail.com (=?utf-8?Q?Micha=C5=82_Nasiadka?=) Date: Wed, 18 Aug 2021 11:16:52 +0200 Subject: [election][kolla] PTL candidacy for Yoga In-Reply-To: <7db1dc14-5740-4051-9126-d5d29c78238e@Spark> References: <7db1dc14-5740-4051-9126-d5d29c78238e@Spark> Message-ID: <0207c9ce-c1ec-422d-88a3-2f48bd0768a9@Spark> Hello Koalas, I’d like to nominate myself to serve as the Kolla PTL for Yoga cycle. I’ve been a Kolla/Kolla-Ansible user and developer since 2015/2016. Initially I started out as a user while working at IBM, and started my first small contributions in Ocata. I became a core while working in Nokia (Feb/Mar 2019) - and continued working on Kolla (and Kayobe) when I moved to StackHPC 2 years ago. I was lucky enough to change companies - but my upstream OpenStack interest remained the same. First and foremost - I’d like to thank Mark for the work he did on previous cycles, especially by bringing users together in the Kolla club, improving Kolla-Ansible’s performance and introducing Kayobe to the Kolla family. As a PTL I’d like to continue focus on: • User experience - documentation, work on eliminating user pain points, Kolla Klub-like activities • CI stability and improvements • Helping new contributors Thanks, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: From radoslaw.piliszek at gmail.com Wed Aug 18 09:23:46 2021 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Wed, 18 Aug 2021 11:23:46 +0200 Subject: [election][kolla] PTL candidacy for Yoga In-Reply-To: <0207c9ce-c1ec-422d-88a3-2f48bd0768a9@Spark> References: <7db1dc14-5740-4051-9126-d5d29c78238e@Spark> <0207c9ce-c1ec-422d-88a3-2f48bd0768a9@Spark> Message-ID: On Wed, Aug 18, 2021 at 11:17 AM Michał Nasiadka wrote: > I’d like to nominate myself to serve as the Kolla PTL for Yoga cycle. +1 -yoctozepto From katonalala at gmail.com Wed Aug 18 09:45:20 2021 From: katonalala at gmail.com (Lajos Katona) Date: Wed, 18 Aug 2021 11:45:20 +0200 Subject: [election][Neutron]PTL candidacy for Yoga Message-ID: Hello Openstack Community, I write to submit my candidacy for the Neutron PTL position during the Yoga cycle. I have worked with Openstack since Grizzly in downstream projects, and as a fulltime upstream developer from Rocky. I mostly focused on Neutron, but worked with testing, CI and even added some networking features to Horizon. I work for Ericsson, who brings in interesting TelCo needs and experiences, like trunks or bandwidth aware scheduling. In Ericsson I worked not only as developer, but as team lead and team coach, that gave me opportunity to view things from different perspectives and help teams to solve issues together. I tried to keep Neutron stadium projects alive and maintained, actively participated in Neutron meetings and in activities like the scheduled bug deputy weeks. In the last cycles the Neutron community was stable, and worked together as a real team, and was the best experience of my professional life to work with them and learn every day new things. As I see the team was able to create a kind of gravitation that encouraged developers from around the world to report their bugs, propose their fixes and new ideas to networking projects. My priorities as PTL are the following: * Keep Neutron's stadium ecosystem alive and healthy. In Xena we moved tap-as-a-service back to stadium, and there's even new features arriving to make some of them work with OVN. Continue this effort to keep Neutron as a natural API and code base for many projects. * The team has strong tradition to focus on CI with dedicated weekly meeting, eyes on jobs' results and increasing test coverage. Continue these efforts to make Neutron CI more stable and capable of giving fast and reliable feedback to developers. * In the last cycles OVN became one of Neutron's in-tree backends, and now it is used as default backend in Openstack CI. There's a continuous effort to remove the gaps between ML2/OVS and OVN (see: https://docs.openstack.org/neutron/latest/ovn/gaps.html), some of these already have owner (like QoS Minimum Bandwidth allocation with Placement, or BGP), this effort should be continued. * Neutron team is quite healthy, but I want to onboard developers from other companies to keep the influx of people and ideas. * In the last cycles the performance improvements were always on the written or unconscious TODO list of the team (like enginefacade-switch, or this cycle's efforts from Oleg and other Huawei developers). Like CI, performance improvements and monitoring should be a continuous effort. * Continue the ongoing implementation for feautres like new QoS rules (pps limit and minimum pps), and new l3 related features. Thank you for your time and consideration. Lajos Katona (lajoskatona) -------------- next part -------------- An HTML attachment was scrubbed... URL: From bcafarel at redhat.com Wed Aug 18 09:51:09 2021 From: bcafarel at redhat.com (Bernard Cafarelli) Date: Wed, 18 Aug 2021 11:51:09 +0200 Subject: [neutron][stable] Nominate Lajos Katona to the neutron-stable-maint team In-Reply-To: <9e06b87e-11ee-ef0c-dac9-c14fa41bd207@est.tech> References: <4154938.lVMuQLOT2H@p1> <1678645.VL9kP18s9H@p1> <9e06b87e-11ee-ef0c-dac9-c14fa41bd207@est.tech> Message-ID: Great, this is some nice news to read (catching up on PTO emails)! Welcome, go review some backports now :) Bernard Cafarelli Le lun. 16 août 2021 à 11:35, Előd Illés a écrit : > Hi, > > I've added Lajos to neutron-stable-maint group as it was requested > Congrats Lajos & keep up the good work! \o/ > > Cheers, > > Előd > > > On 2021. 08. 16. 9:56, Slawek Kaplonski wrote: > > Hi, > > > > It's been more than week since I sent it and I got only positive feedback > > about Lajos candidacy. > > @Stable maint team: can You add Lajos to the neutron-stable-maint group? > Or do > > I need to do something more to get Lajos to that group? > > > > On czwartek, 5 sierpnia 2021 11:50:46 CEST Slawek Kaplonski wrote: > >> Hi, > >> > >> I would like to nominate Lajos Katona as a Neutron stable core reviewer. > > Lajos > >> is core in Neutron since long time. He is maintaining many stadium > projects > >> as well as he is very active in the main Neutron project. He helps us a > lot > >> with keeping stable branches healthy (especially for stadium projects, > but > >> not only). > >> During that time he has proven already his knowledge about Neutron and > > Neutron > >> stadium projects as well as knowledge of the stable branches rules. > >> > >> I will keep this nomination open for about 1 week. After that if there > will > > be > >> no votes agains, I will ask stable-maint-core team to add Lajos to the > >> neutron-stable-maint team. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joykechen at 163.com Wed Aug 18 11:59:28 2021 From: joykechen at 163.com (=?GBK?B?s8K/yw==?=) Date: Wed, 18 Aug 2021 19:59:28 +0800 (CST) Subject: [cyborg] Y cycle PTL nomination from 17th August In-Reply-To: References: Message-ID: <3c32ca21.63ca.17b592170a8.Coremail.joykechen@163.com> Hi XinRan: Thank you for your great contribution to cyborg project, especially the interaction between Cyborg/Nova /Placement, which has laid the foundation for cyborg to move forward. It's great. 在 2021-08-16 11:49:34，"Rong Zhu" 写道： Xinran, Thanks for your great efforts for cyborg. Wang, Xin-ran 于2021年8月16日 周一10:25写道： Hi all, The Y cycle PTL nomination will start on 17th August. Firstly, I want to give a big thanks to all of you, thank you for the continuously support and contribution for Cyborg. As I have been this role for almost 2 cycles, I think it is better to have someone else to take this role which can bring us new ideas. Please refer to this guide[1] if you want submit your candidacy. If you have any question, please feel free to contact me. [1] https://governance.openstack.org/election/#how-to-submit-a-candidacy Thanks, Xin-Ran -- Thanks, Rong Zhu -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooney at redhat.com Wed Aug 18 11:59:46 2021 From: smooney at redhat.com (Sean Mooney) Date: Wed, 18 Aug 2021 12:59:46 +0100 Subject: [neutron][ovn] support for stateless NAT for floating ip in ml2 ovn In-Reply-To: References: <20210817002002.252368-1-ihrachys@redhat.com> <9096201007244d0732f019d1452575e61080e09c.camel@redhat.com> Message-ID: <3b84603ca14830e712154091692f05538fdcacef.camel@redhat.com> On Tue, 2021-08-17 at 18:10 -0400, Ihar Hrachyshka wrote: > On Tue, Aug 17, 2021 at 3:14 PM Moshe Levi wrote: > > > > > > > > > -----Original Message----- > > > From: Sean Mooney > > > Sent: Tuesday, August 17, 2021 2:32 PM > > > To: Ihar Hrachyshka ; openstack- > > > discuss at lists.openstack.org > > > Subject: Re: [neutron][ovn] support for stateless NAT for floating ip in ml2 > > > ovn > > > > > > External email: Use caution opening links or attachments > > > > > > > > > On Mon, 2021-08-16 at 20:20 -0400, Ihar Hrachyshka wrote: > > > > > Hi all, > > > > > > > > > > OVN support stateless NAT operations [1] for use case of 1:1 mapped > > > > > between inner and external ips, i.e dnat_and_snat rule. In openstack > > > > > is the floating ip use-case. Looking on ml2 ovn support it seem > > > > > that it only support floating ip with connection tracking. Can ml2 > > > > > ovn support also the stateless NAT option? Is there concerns using > > > stateless NAT? > > > > > > > > Hi Moshe, > > > moshe out of interest does hardware offloaded ovs support hardware > > > offloaded NAT (stateful or stateless) yet with connectx-6 dx? > > So connectx-6 dx can offload NAT (just SNAT or DNAT), but in the case of dnat_and_snat rules offload won't work. > > We need to optimize ovn to make it work because of it snat and dnat zones. We can offload stateless without changing ovn and the driver and the performance is better because we don't have the snat /dnat zone in ovn. > > > > > > > > im not sure how feature enabled the connection tracker suppport is in the tc > > > flower offload path so if this provided the ablity to do hardware offloaded > > > floating ip nat i think this would be another point in favor of supporting it. > > [ML] so the stateless nat we can do today. (we check it in openstack env and just adding stateless config manual in ovn tables. > > > > > You mean like this? > https://review.opendev.org/c/openstack/neutron/+/804807 (This also > passed CI.) > > > > the dpdk connection track is certelly still a bottle neck to dpdk perfromance > > > so for ovs-dpdk i would expect to see a nice uplift in perfermance vs > > > userspace contrack based nat so that is another reason to support this in my > > > view. > > > > > > > > you are talking about an "option". Do you mean OpenStack would have a > > > > new API extension for FIPs to choose it? Or a configuration option? > > I was talking about config option, because I wasn’t sure if we want to keep the stateful behavior or there are use case when customer will want to use stateful NAT. > > > > I just can't figure out which scenario it would be, considering that > an admin allocates addresses to FIP pools for monopolistic use by > OpenStack, and FIPs are 1:1 mapped to fixed IP addresses. Which > scenario do you have in mind? > > I understand the initial gut reaction to have it opt-in but IMHO it > makes sense only if we can explain why switching to always-stateless > won't work. > > > > > > > > > AFAIU the only limitation for stateless dnat_and_snat rules in OVN is > > > > that the mapping must be 1:1, which I think is always the case with > > > > OpenStack FIPs (fixed_ip_address attribute is not a list). If so, > > > > perhaps always using stateless NAT rules is the way to go (so no api > > > > or config option). Am I missing something? > > [ML] maybe this is why I raise this question here as I don't know the background of why it was implemented as stateful 😊 > > > > > > > > I am not aware of any concerns using stateless NAT. But to clarify > > > > your > > > > motivation: do you expect it to perform better cpu/bandwidth wise? > > [ML] motivation is to enable ovs hardware offload to offload floating ip use-case and to improve performance. > > > im pretty sure this has been dicussed in the past. > > > when david and i where working on neutron at intel on the learn action > > > firewally and openflow bridge based routing a few years ago im pretty sure > > > we discused using nat for FIPs when contrack suppport was first being added > > > to ovs. > > > > > > this makes perfect sense to me to support FIPs via ovs openflow nat rules > > > even on ml2/ovs i dont think that needs to be restricted to ovn although ill > > > admit the ip tables nat entries in teh kernel router namespace proably scalse > > > better the the ovs implemenation based on teh connection tracker today. > > > > > > stateful vs statless not is an interesting question. > > > https://patchwork.ozlabs.org/project/openvswitch/cover/1570154179- > > > 14525-1-git-send-email-ankur.sharma at nutanix.com/ > > > seams to imply that it must be implemented as a dnat_and_snat rule and i > > > think that has the implication that since its stateless it will always take affect > > > even in the same subnet? i dont know if we can restrict that so that the > > > stateless rule only take effect if we are leaving the openstack env or not. > > > > > I am not sure what you mean by saying "it will always take affect even > in the same subnet". Could you please elaborate? > > AFAIU stateless NAT translation flows won't be reached when ports of > the same logical switch communicate, same as they are not supposed to > be triggered with ct_* rules. (Which is achieved by short-circuiting > tables in OVN table architecture.) that is what i was concerned about. iw was not sure if in stateless mode that behavior would chagne. if no nat happens when talking to servers in the same neutorn netorks or in other neutron networks within hte same tenant then i think we shoudl be gould to alwasy enabel it > > > > looking at the patches i think that would be the main delta although i am just > > > guessing that that will be a side efffect of the stateless implemenation after a > > > quick glance. if i am correct about that i think we would need to opt into > > > stateless nat for FIPs to maintain backwards compatiablity. > > > this could be done at a port level with a new extentions, at a config level > > > ideallly globally, or perhaps we can add an extion to the FIP api to specify that > > > it shoudl be statefully or stateless. that latter is proably the cleanest of the 3 > > > espically if we were to also support this in other ml2/drivers eventually but i > > > dont think we could just swtich to stateless fips if it will afffect the east west > > > flows in any way. > > > > > > if there is no affeect on east west flows and it only affect north/south folow > > > into and out of the openstack cluster then moveign to statelesss in all cases > > > likely would improve perfermance as there will be less contention for the > > > connection tracker. > > [ML] in our test we didn't encounter effect on the east west flows. and based on ^ i think that is an endorsement for always using stateless nat however we need to be able to fallback to statefull not if ovn is not new enough to supprot it so https://review.opendev.org/c/openstack/neutron/+/804807 feels incomplete to me. https://patchwork.ozlabs.org/project/openvswitch/cover/1570154179-14525-1-git-send-email-ankur.sharma at nutanix.com/ this was merged in late 2019 so its reltivly recent addtion. im not sure we will want to raise our min ovn version to require statelsess support. > > > > > > > > > > > Thanks, > > > > Ihar > > > > > > > > > > > > > > > > > From amy at demarco.com Wed Aug 18 12:22:41 2021 From: amy at demarco.com (Amy Marrich) Date: Wed, 18 Aug 2021 07:22:41 -0500 Subject: [kolla] PTL non-candidacy In-Reply-To: References: Message-ID: Thanks for all your hard work Mark. Amy (spotz) On Wed, Aug 18, 2021 at 3:20 AM Mark Goddard wrote: > Hi Koalas, > > As I suspect may be the case with many PTLs, I first took on the role > largely because it needed to be done and no other candidates were > forthcoming. As I settled into the role I found that I actually rather > enjoyed it. The project has certainly come far since I first started > using it in 2016, and I'm proud to have helped to steer the ship for a > while. After 5 release cycles, the time has come to pass on the Kolla > PTL hat to another Koala. I will still be actively involved in the > community, and will be happy to help the next PTL while they get > comfortable. Thank you to everyone who has supported me in this role, > and to everyone who makes Kolla such a great community to be involved > in. > > Long live Kolla! > > Cheers, > Mark > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From skaplons at redhat.com Wed Aug 18 12:43:57 2021 From: skaplons at redhat.com (Slawek Kaplonski) Date: Wed, 18 Aug 2021 14:43:57 +0200 Subject: [neutron] Drivers meeting agenda for 20.08.2021 Message-ID: <2425659.Dg8HfsKTfU@p1> Hi, I will not be available this Thursday and Friday but we have 2 RFEs to discuss during drivers meeting and Miguel volunteered that he will chair the meeting on Friday. RFEs to discuss: * https://bugs.launchpad.net/neutron/+bug/1936408 It's again raised by ralonsoh as he added some new clarifications to it, let's discuss it in the drivers team again. * https://bugs.launchpad.net/neutron/+bug/1939602 New RFE proposed by ralonsoh -- Slawek Kaplonski Principal Software Engineer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From kkchn.in at gmail.com Wed Aug 18 13:01:03 2021 From: kkchn.in at gmail.com (KK CHN) Date: Wed, 18 Aug 2021 18:31:03 +0530 Subject: Windows2012 VM image importing and Instance Launch Failure Message-ID: Error : failed to perform requested operation on instance "WindowsVM "the instance has error status. Please try again later [Error exceeded maximum number of retries. Exhausted all hosts available for retrying build failures for instance e3d5c095-7d26-4b1e-89d1-d1a6e20a45041 I am trying to import a WIndows2012 Single disk VM, to OpenStack Ussuri, with glance and Qemu KVM. In bare machine KVM I am able to import and boot this Windows VM which exported from rhevm hypervisor as vhdx image. what I have done is 1. converted this windows image from vhdx to qcow2 2. root at MeghCtrol1:/home/cloud/CMOBB_APP#cirt-install --name WINDOWS --ram=1048 --vcups=1 --cpu host --hvm --dick path=BackUP2_CMAPP_disk_1_Windows_qcow2_imagefile,device=disk, format=qcow2,bus=virtio --graphics vnc --boot uefi This uploaded the qcow2 image of WindowsVM to KVM hypervisor and its working. But when I do importing to openstack unable to launch instance from the image . These are the steps I performed.. 1. openstack image create "WindowsVM" --file CMAPP_disk_1.qcow2 --disk-format qcow2 --container-format bare --public 4.openstack image set --property hw_firmware_type=uefi --property os_secure_boot=required WindowsVM 5.openstack image set --property hw_firmware_type=uefi --property hw_disk_bus=ide WindowsVM 6.openstack image show WindowsVM 7. root at dmzcloud:/home/cloud# openstack image show WindowsVM|grep "properties" | properties | hw_disk_bus='ide', hw_firmware_type='uefi', os_hash_algo='sha512', os_hash_value='753ee596980409e1e72d6d020c8219c56a6ada8b43f634fb575c594a245725a398e45982c0a1ad72b3fc3451cde62cceb9ff22be044863b31ecdd7893b049349', os_hidden='False', os_secure_boot='required', owner_specified.openstack.md5='', owner_specified.openstack.object='images/WindowsVM', owner_specified.openstack.sha256='' | root at dmzcloud:/home/cloud# Then I logged into horizon dashboard, from the images selected the imported image and try to launch the instance. With a Flavour of 550 GB disk, 4 vcpus and 8GB Ram .. The instance spawning ran for 30 minutes and throws the error which I pasted first in the right top corner of horizon dashboard. How to solve this error and boot the Windows machine successfully .. """ Error : failed to perform requested operation on instance "WindowsVM "the instance has error status. Please try again later [Error exceeded maximum number of retries. Exhausted all hosts available for retrying build failures for instance e3d5c095-7d26-4b1e-89d1-d1a6e20a45041 """ Any help highly appreciated. Kris -------------- next part -------------- An HTML attachment was scrubbed... URL: From thierry at openstack.org Wed Aug 18 13:08:25 2021 From: thierry at openstack.org (Thierry Carrez) Date: Wed, 18 Aug 2021 15:08:25 +0200 Subject: [murano][tc] Project Retirement In-Reply-To: References: <3117ebb2-ea5f-9905-2447-1773c4c23eab@openstack.org> Message-ID: Rong Zhu wrote: > Sorry for my late response, I am a little bit busy for internal works > recently. > > If TC has decided to retire murano, I have no objection. But If TC think > someone can keep maintain it and not retire, I am glad to keeping > maintain Murano project. Please reconsider this. For the record, I don't think there is an urgent need to retire Murano as long as it is maintained, fills community goals, hits release requirements, and is functional. Like mnaser said, it is a bit off in the modern landscape of application deployment technology, so I don't think it's a priority anymore -- if its continued existence blocked people from focusing on more critical components, I would support removing it. But based on Rong Zhu's response I'm not sure that's the case. -- Thierry From senrique at redhat.com Wed Aug 18 14:08:56 2021 From: senrique at redhat.com (Sofia Enriquez) Date: Wed, 18 Aug 2021 11:08:56 -0300 Subject: [cinder] Bug deputy report for week of 2021-18-08 Message-ID: Hello, This is a bug report from 2021-11-08 to 2021-18-08. This ^ isn't completely accurate. I apologize because my launchpad link failed or something and I've missed a couple of bugs that I've included in today's report. Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting ----------------------------------------------------------------------------------------- High - https://bugs.launchpad.net/cinder/+bug/1939972 "Original volume size is lost when uploading a volume to a qcow2 image". Assigned to Takashi Kajinam. - https://bugs.launchpad.net/cinder/+bug/1937084 "Nova thinks deleted volume is still attached". Assigned to Gorka Eguileor. Medium - https://bugs.launchpad.net/cinder/+bug/1939241 "StorPool: encrypted volumes cannot be attached". Assigned to Peter Penchev. - https://bugs.launchpad.net/cinder/+bug/1940069 "HPE 3PAR: SSH Connection rejected - max number of connections reached". Assigned to Raghavendra Tila. - https://bugs.launchpad.net/cinder/+bug/1938870 "KumoScale Driver replicated volume missing portals attached without raid". Assigned to Zohar Mamedov. - https://bugs.launchpad.net/cinder/+bug/1936848 "PowerMax - Group rename error". Assigned to Helen Walsh. - https://bugs.launchpad.net/cinder/+bug/1940436 "[LVM] lvextend command crashes with code 139". Assigned to Eric Harney. Low - https://bugs.launchpad.net/cinder/+bug/1939956 "Driver-specific options should not be added to [DEFAULT]". Assigned to Takashi Kajinami. - https://bugs.launchpad.net/cinder/+bug/1938572 "PowerMax - legacy PowerMax issue with generations". Assigned to Helen Walsh. - https://bugs.launchpad.net/cinder/+bug/1940437 "Removing a volume in wrong state doesn't report its state". Assigned to Emilien Macchi. Incomplete - https://bugs.launchpad.net/cinder/+bug/1939842 "[CEPH] cinder-backup service blocked by creating volume from backup". Assigned to Jeremy Li. - https://bugs.launchpad.net/cinder/+bug/1939139 "PowerMax - PowerMaxOS 5978.711 snapshot exception". Assigned to Helen Walsh. - https://bugs.launchpad.net/cinder/+bug/1936474 "Create instance from volume fails on reschedule". Unassigned. Wishlist - https://bugs.launchpad.net/cinder/+bug/1938457 "[Storwize] Fix rccg_name based on group display_name". Assigned to Venkata krishna Thumu. Cheers, -- L. Sofía Enriquez she/her Software Engineer Red Hat PnT IRC: @enriquetaso @RedHat Red Hat Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: From wodel.youchi at gmail.com Wed Aug 18 14:26:45 2021 From: wodel.youchi at gmail.com (wodel youchi) Date: Wed, 18 Aug 2021 15:26:45 +0100 Subject: Need help deploying Openstack Message-ID: Hi, I am trying to deploy openstack with tripleO using VMs and nested-KVM for the compute node. This is for test and learning purposes. I am using the Train version and following some tutorials. I prepared my different template files and started the deployment, but I got these errors : *Failed to provision instance fc40457e-4b3c-4402-ae9d-c528f2c2ad30: Asynchronous exception: Node failed to deploy. Exception: Agent API for node 6d3724fc-6f13-4588-bbe5-56bc4f9a4f87 returned HTTP status code 404 with error: Not found: Extension with id iscsi not found. for node* and *Got HTTP 409: {"errors": [{"status": 409, "title": "Conflict", "detail": "There was a conflict when trying to complete your request.\n\n Unable to allocate inventory: Unable to create allocation for 'CUSTOM_BAREMETAL' on resource provider '6d3724fc-6f13-4588-bbe5-56bc4f9a4f87'. The requested amount would exceed the capacity. ",* Could you help understand what those errors mean? I couldn't find anything similar on the net. Thanks in advance. Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From johfulto at redhat.com Wed Aug 18 15:01:02 2021 From: johfulto at redhat.com (John Fulton) Date: Wed, 18 Aug 2021 11:01:02 -0400 Subject: [tripleo] Re: Need help deploying Openstack In-Reply-To: References: Message-ID: Hi Wodel, Yes, it's possible to deploy openstack with tripleo using VMs and nested-KVM for the compute node. I personally use this tool on my hypervisor to do it. https://github.com/cjeanner/tripleo-lab By trying to get tripleo working with nested KVM without using a tool like the above you might eventually create your own version of the same tool though using the above helps you skip those steps. The issue you're hitting from the error message below looks like the Nova scheduler on the undercloud not finding an Ironic node that satisfies the scheduling criteria. This can be debugged but you might find it easier to just not have the problem by letting another tool deal with this for you. Also, with wallaby and newer tripleo does not use Nova on the undercloud and instead the recommended deployment process is to use metalsmith as described here: https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/provisioning/baremetal_provision.html You also have the standalone option of using tripleo on a single VM: https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/deployment/standalone.html John On Wed, Aug 18, 2021 at 10:28 AM wodel youchi wrote: > Hi, > I am trying to deploy openstack with tripleO using VMs and nested-KVM for > the compute node. This is for test and learning purposes. > > I am using the Train version and following some tutorials. > I prepared my different template files and started the deployment, but I > got these errors : > > *Failed to provision instance fc40457e-4b3c-4402-ae9d-c528f2c2ad30: > Asynchronous exception: Node failed to deploy. Exception: Agent API for > node 6d3724fc-6f13-4588-bbe5-56bc4f9a4f87 returned HTTP status code 404 > with error: Not found: Extension with id iscsi not found. for node* > > and > > *Got HTTP 409: {"errors": [{"status": 409, "title": "Conflict", "detail": > "There was a conflict when trying to complete your request.\n\n Unable to > allocate inventory: Unable to create allocation for 'CUSTOM_BAREMETAL' on > resource provider '6d3724fc-6f13-4588-bbe5-56bc4f9a4f87'. The requested > amount would exceed the capacity. ",* > > Could you help understand what those errors mean? I couldn't find anything > similar on the net. > > Thanks in advance. > > Regards. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wodel.youchi at gmail.com Wed Aug 18 15:28:39 2021 From: wodel.youchi at gmail.com (wodel youchi) Date: Wed, 18 Aug 2021 16:28:39 +0100 Subject: [tripleo] Re: Need help deploying Openstack In-Reply-To: References: Message-ID: Thanks John, My idea is to learn how to deploy openstack with tripleO like what will be with physical nodes, my goal is not to get openstack up and running to lean how to use it, my goal is to install it in the same way as if it was a physical implementation. About Wallaby, I have tried, but I got other errors : I followed these documents : https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/features/network_isolation.html https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/features/custom_networks.html#custom-networks https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/provisioning/baremetal_provision.html#network-config-properties At the end I tried these two commands : 1) openstack overcloud node provision --stack overcloud --network-config --output ~/overcloud-baremetal-deployed.yaml ~/templates/ *baremetal-node-net.yaml* And I this error message : > 2021-08-15 15:59:32.402435 | 52540075-9baf-2b0b-5fc8-000000000017 | > FATAL | Provision instances | localhost | error={"changed": false, > "logging": "Deploy attempt failed on node computeHCI2 > (UUID 9440e769-9634-4015-82b0-97b8c1921ef5), > cleaning up\nTraceback (most recent call last):\n File > \"/usr/lib/python3.6/site-packages/metalsmith/_provisioner.py\", line 392, > in provision_node\n nics.validate()\n > File \"/usr/lib/python3.6/site-packages/metalsmith/_nics.py\", line 60, in > validate\n > result.append(('network', self._get_network(nic)))\n File > \"/usr/lib/python3.6/site-packages/metalsmith/_nics.py\", line 128, in > _get_network\n > 'Unexpected fields for a network: %s' % ', > '.join(unexpected))\nmetalsmith.exceptions.InvalidNIC: > Unexpected fields for a network: subnet\nDeploy attempt failed on node > computeHCI0 (UUID 31eecc38-7d80-4ddd-9cc4-a76edf00ec3a), > cleaning up\nTraceback (most recent call last):\n File > \"/usr/lib/python3.6/site-packages/metalsmith/_provisioner.py\", line 392, > in provision_node\n > nics.validate()\n File > \"/usr/lib/python3.6/site-packages/metalsmith/_nics.py\", line 60, in > validate\n > result.append(('network', self._get_network(nic)))\n File > \"/usr/lib/python3.6/site-packages/metalsmith/_nics.py\", line 128, in > _get_network\n > 'Unexpected fields for a network: %s' % ', > '.join(unexpected))\nmetalsmith.exceptions.InvalidNIC: > Unexpected fields for a network: subnet\nDeploy attempt failed on node > controller2 (UUID f62f8cb5-40e4-4e40-805d-852c2a2f7e00), > cleaning up\nTraceback (most recent call last):\n File > \"/usr/lib/python3.6/site-packages/metalsmith/_provisioner.py\", line 392, > in provision_node\n nics.validate()\n File > \"/usr/lib/python3.6/site-packages/metalsmith/_nics.py\", line 60, in > validate\n > result.append(('network', self._get_network(nic)))\n File > \"/usr/lib/python3.6/site-packages/metalsmith/_nics.py\", line 128, in > _get_network\n > 'Unexpected fields for a network: %s' % ', > '.join(unexpected))\nmetalsmith.exceptions.InvalidNIC: > Unexpected fields for a network: subnet\nDeploy attempt failed on node > computeHCI1 (UUID 2798b208-4842-4083-9b3f-c46953b52928), > cleaning up\nTraceback (most recent call last):\n File > \"/usr/lib/python3.6/site-packages/metalsmith/_provisioner.py\", line 392, > in provision_node\n nics.validate()\n File > \"/usr/lib/python3.6/site-packages/metalsmith/_nics.py\", line 60, in > validate\n > result.append(('network', self._get_network(nic)))\n File > \"/usr/lib/python3.6/site-packages/metalsmith/_nics.py\", line 128, in > _get_network\n > 'Unexpected fields for a network: %s' % ', > '.join(unexpected))\nmetalsmith.exceptions.InvalidNIC: Unexpected fields > for a network: subnet\n > Deploy attempt failed on node controller1 (UUID > df87e5c7-32b0-4bfa-9ef9-f0a98666e7de), cleaning up\nTraceback (most recent > call last):\n > File \"/usr/lib/python3.6/site-packages/metalsmith/_provisioner.py\", > line 392, in provision_node\n > nics.validate()\n File > \"/usr/lib/python3.6/site-packages/metalsmith/_nics.py\", line 60, in > validate\n > result.append(('network', self._get_network(nic)))\n File > \"/usr/lib/python3.6/site-packages/metalsmith/_nics.py\", line 128, in > _get_network\n > 'Unexpected fields for a network: %s' % ', > '.join(unexpected))\nmetalsmith.exceptions.InvalidNIC: Unexpected fields > for a network: subnet\nDeploy attempt failed on node controller0 (UUID > af75122c-a6e8-42d7-afd2-571738c42061), cleaning up\nTraceback (most recent > call last):\n File \"/usr/lib/python3.6/site-packages/metalsmith/_*provisioner.py\", > line 392, in provision_node\n nics.validate()\n File > \"/usr/lib/python3.6/site-**packages/metalsmith/_nics.py\"**, line 60, in > validate\n result.append(('network', self._get_network(nic)))\n File > \"/usr/lib/python3.6/site-**packages/metalsmith/_nics.py\"**, line 128, > in _get_network\n 'Unexpected fields for a network: %s' % ', > '.join(unexpected))\**nmetalsmith.exceptions.**InvalidNIC: Unexpected > fields for a network: subnet\n", "msg": "Unexpected fields for a network: > subnet"}* > 2) openstack overcloud node provision --stack overcloud --output ~/ overcloud-baremetal-deployed.yaml ~/templates/*baremetal-node**.yaml* This time I got this error : > 2021-08-16 13:47:02.156021 | 52540075-9baf-0672-d7b8-000000000017 | > FATAL | Provision instances | localhost | error={"changed": false, > "logging": "Created port overcloud-computehci-1-ctlplane (UUID > 17e55729-b44b-40a8-9361-9e36e8527de5) for node controller0 (UUID > 61bc6512-9c4e-4199-936a-754801f7cffa) with {'network_id': > '1c8c5e86-79ac-4ec6-9616-3c965cab6e88', 'name': > 'overcloud-computehci-1-ctlplane'}\nCreated port > overcloud-controller-0-ctlplane (UUID 0a09bbb5-934d-4d34-ab5b-7c14518d06c6) > for node controller1 (UUID 03915e7c-a314-41d9-be8c-46291879692a) with > {'network_id': '1c8c5e86-79ac-4ec6-9616-3c965cab6e88', 'name': > 'overcloud-controller-0-ctlplane'}\nCreated port > overcloud-computehci-2-ctlplane (UUID 76ef56f1-4dbb-453e-a344-968b0da95823) > for node computeHCI2 (UUID a5d3552b-ab79-404e-8a52-48dc53a3aa45) with > {'network_id': '1c8c5e86-79ac-4ec6-9616-3c965cab6e88', 'name': > 'overcloud-computehci-2-ctlplane'}\nCreated port > overcloud-computehci-0-ctlplane (UUID 79967f38-90ee-49e6-8716-b09cc9460afe) > for node computeHCI1 (UUID 3534309b-c11f-48d4-b23d-3ed9f2dcbf79) with > {'network_id': '1c8c5e86-79ac-4ec6-9616-3c965cab6e88', 'name': > 'overcloud-computehci-0-ctlplane'}\nCreated port > overcloud-controller-1-ctlplane (UUID c70b7c8c-31a6-460e-aa77-ea37b8e332f6) > for node controller2 (UUID 83f47771-9f82-4437-8df4-de32bcd6fc63) with > {'network_id': '1c8c5e86-79ac-4ec6-9616-3c965cab6e88', 'name': > 'overcloud-controller-1-ctlplane'}\nCreated port > overcloud-controller-2-ctlplane (UUID 2b74c4e3-705c-4bf1-85de-a5e0a9cdb591) > for node computeHCI0 (UUID 3924529b-44a7-4c74-b1e1-2175d6313a3e) with > {'network_id': '1c8c5e86-79ac-4ec6-9616-3c965cab6e88', 'name': > 'overcloud-controller-2-ctlplane'}\nAttached port > overcloud-controller-0-ctlplane (UUID 0a09bbb5-934d-4d34-ab5b-7c14518d06c6) > to node controller1 (UUID 03915e7c-a314-41d9-be8c-46291879692a)\nAttached > port overcloud-computehci-1-ctlplane (UUID > 17e55729-b44b-40a8-9361-9e36e8527de5) to node controller0 (UUID > 61bc6512-9c4e-4199-936a-754801f7cffa)\nProvisioning started on node > controller1 (UUID 03915e7c-a314-41d9-be8c-46291879692a)\nAttached port > overcloud-computehci-2-ctlplane (UUID 76ef56f1-4dbb-453e-a344-968b0da95823) > to node computeHCI2 (UUID a5d3552b-ab79-404e-8a52-48dc53a3aa45)\nAttached > port overcloud-computehci-0-ctlplane (UUID > 79967f38-90ee-49e6-8716-b09cc9460afe) to node computeHCI1 (UUID > 3534309b-c11f-48d4-b23d-3ed9f2dcbf79)\nProvisioning started on node > controller0 (UUID 61bc6512-9c4e-4199-936a-754801f7cffa)\nAttached port > overcloud-controller-1-ctlplane (UUID c70b7c8c-31a6-460e-aa77-ea37b8e332f6) > to node controller2 (UUID > 83f47771-9f82-4437-8df4-de32bcd6fc63)\nProvisioning started on node > computeHCI2 (UUID a5d3552b-ab79-404e-8a52-48dc53a3aa45)\nProvisioning > started on node computeHCI1 (UUID > 3534309b-c11f-48d4-b23d-3ed9f2dcbf79)\nAttached port > overcloud-controller-2-ctlplane (UUID 2b74c4e3-705c-4bf1-85de-a5e0a9cdb591) > to node computeHCI0 (UUID > 3924529b-44a7-4c74-b1e1-2175d6313a3e)\nProvisioning started on node > controller2 (UUID 83f47771-9f82-4437-8df4-de32bcd6fc63)\nProvisioning > started on node computeHCI0 (UUID 3924529b-44a7-4c74-b1e1-2175d6313a3e)\n", > "msg": "Node *a5d3552b-ab79-404e-8a52-**48dc53a3aa45 reached failure > state \"deploy failed\"; the last error is Agent returned error for deploy > step {'step': 'write_image', 'priority': 80, 'argsinfo': None, 'interface': > 'deploy'} on node a5d3552b-ab79-404e-8a52-**48dc53a3aa45 : Error > performing deploy_step write_image: Command execution failed: Failed to > check the number of primary partitions present on /dev/vda for node > a5d3552b-ab79-404e-8a52-**48dc53a3aa45. Error: The device /dev/vda does > not have a valid MBR partition table."}* > Any ideas? thanks in advance. Regards. Le mer. 18 août 2021 à 16:01, John Fulton a écrit : > Hi Wodel, > > Yes, it's possible to deploy openstack with tripleo using VMs and > nested-KVM for the compute node. I personally use this tool on my > hypervisor to do it. > > https://github.com/cjeanner/tripleo-lab > > By trying to get tripleo working with nested KVM without using a tool like > the above you might eventually create your own version of the same tool > though using the above helps you skip those steps. > > The issue you're hitting from the error message below looks like the Nova > scheduler on the undercloud not finding an Ironic node that satisfies the > scheduling criteria. This can be debugged but you might find it easier to > just not have the problem by letting another tool deal with this for you. > Also, with wallaby and newer tripleo does not use Nova on the undercloud > and instead the recommended deployment process is to use metalsmith as > described here: > > > https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/provisioning/baremetal_provision.html > > You also have the standalone option of using tripleo on a single VM: > > > https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/deployment/standalone.html > > John > > On Wed, Aug 18, 2021 at 10:28 AM wodel youchi > wrote: > >> Hi, >> I am trying to deploy openstack with tripleO using VMs and nested-KVM for >> the compute node. This is for test and learning purposes. >> >> I am using the Train version and following some tutorials. >> I prepared my different template files and started the deployment, but I >> got these errors : >> >> *Failed to provision instance fc40457e-4b3c-4402-ae9d-c528f2c2ad30: >> Asynchronous exception: Node failed to deploy. Exception: Agent API for >> node 6d3724fc-6f13-4588-bbe5-56bc4f9a4f87 returned HTTP status code 404 >> with error: Not found: Extension with id iscsi not found. for node* >> >> and >> >> *Got HTTP 409: {"errors": [{"status": 409, "title": "Conflict", "detail": >> "There was a conflict when trying to complete your request.\n\n Unable to >> allocate inventory: Unable to create allocation for 'CUSTOM_BAREMETAL' on >> resource provider '6d3724fc-6f13-4588-bbe5-56bc4f9a4f87'. The requested >> amount would exceed the capacity. ",* >> >> Could you help understand what those errors mean? I couldn't find >> anything similar on the net. >> >> Thanks in advance. >> >> Regards. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: overcloud-networks-deployed.yaml Type: application/x-yaml Size: 3106 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: network_data-new.yaml Type: application/x-yaml Size: 1201 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: baremetal-node.yaml Type: application/x-yaml Size: 228 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: baremetal-node-net.yaml Type: application/x-yaml Size: 1218 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bonds_vlans.j2 Type: application/octet-stream Size: 2242 bytes Desc: not available URL: From dmendiza at redhat.com Wed Aug 18 15:35:10 2021 From: dmendiza at redhat.com (Douglas Mendizabal) Date: Wed, 18 Aug 2021 10:35:10 -0500 Subject: [barbican] No weekly meeting next week Message-ID: <253e5b79-35ad-cf85-7185-c91b57e5e722@redhat.com> Hi All, I'll be out on PTO for a few days, so I won't be available to chair the next Barbican weekly meeting. I should be back the following week for the August 31 meeting. Thanks, - Douglas Mendizábal (redrobot) https://etherpad.opendev.org/p/barbican-weekly-meeting From ihrachys at redhat.com Wed Aug 18 15:35:38 2021 From: ihrachys at redhat.com (Ihar Hrachyshka) Date: Wed, 18 Aug 2021 11:35:38 -0400 Subject: [neutron][ovn] support for stateless NAT for floating ip in ml2 ovn In-Reply-To: <3b84603ca14830e712154091692f05538fdcacef.camel@redhat.com> References: <20210817002002.252368-1-ihrachys@redhat.com> <9096201007244d0732f019d1452575e61080e09c.camel@redhat.com> <3b84603ca14830e712154091692f05538fdcacef.camel@redhat.com> Message-ID: On Wed, Aug 18, 2021 at 7:59 AM Sean Mooney wrote: > > On Tue, 2021-08-17 at 18:10 -0400, Ihar Hrachyshka wrote: > > On Tue, Aug 17, 2021 at 3:14 PM Moshe Levi wrote: > > > > > > > > > > > > > -----Original Message----- > > > > From: Sean Mooney > > > > Sent: Tuesday, August 17, 2021 2:32 PM > > > > To: Ihar Hrachyshka ; openstack- > > > > discuss at lists.openstack.org > > > > Subject: Re: [neutron][ovn] support for stateless NAT for floating ip in ml2 > > > > ovn > > > > > > > > External email: Use caution opening links or attachments > > > > > > > > > > > > On Mon, 2021-08-16 at 20:20 -0400, Ihar Hrachyshka wrote: > > > > > > Hi all, > > > > > > > > > > > > OVN support stateless NAT operations [1] for use case of 1:1 mapped > > > > > > between inner and external ips, i.e dnat_and_snat rule. In openstack > > > > > > is the floating ip use-case. Looking on ml2 ovn support it seem > > > > > > that it only support floating ip with connection tracking. Can ml2 > > > > > > ovn support also the stateless NAT option? Is there concerns using > > > > stateless NAT? > > > > > > > > > > Hi Moshe, > > > > moshe out of interest does hardware offloaded ovs support hardware > > > > offloaded NAT (stateful or stateless) yet with connectx-6 dx? > > > So connectx-6 dx can offload NAT (just SNAT or DNAT), but in the case of dnat_and_snat rules offload won't work. > > > We need to optimize ovn to make it work because of it snat and dnat zones. We can offload stateless without changing ovn and the driver and the performance is better because we don't have the snat /dnat zone in ovn. > > > > > > > > > > > im not sure how feature enabled the connection tracker suppport is in the tc > > > > flower offload path so if this provided the ablity to do hardware offloaded > > > > floating ip nat i think this would be another point in favor of supporting it. > > > [ML] so the stateless nat we can do today. (we check it in openstack env and just adding stateless config manual in ovn tables. > > > > > > > > You mean like this? > > https://review.opendev.org/c/openstack/neutron/+/804807 (This also > > passed CI.) > > > > > > the dpdk connection track is certelly still a bottle neck to dpdk perfromance > > > > so for ovs-dpdk i would expect to see a nice uplift in perfermance vs > > > > userspace contrack based nat so that is another reason to support this in my > > > > view. > > > > > > > > > > you are talking about an "option". Do you mean OpenStack would have a > > > > > new API extension for FIPs to choose it? Or a configuration option? > > > I was talking about config option, because I wasn’t sure if we want to keep the stateful behavior or there are use case when customer will want to use stateful NAT. > > > > > > > I just can't figure out which scenario it would be, considering that > > an admin allocates addresses to FIP pools for monopolistic use by > > OpenStack, and FIPs are 1:1 mapped to fixed IP addresses. Which > > scenario do you have in mind? > > > > I understand the initial gut reaction to have it opt-in but IMHO it > > makes sense only if we can explain why switching to always-stateless > > won't work. > > > > > > > > > > > > AFAIU the only limitation for stateless dnat_and_snat rules in OVN is > > > > > that the mapping must be 1:1, which I think is always the case with > > > > > OpenStack FIPs (fixed_ip_address attribute is not a list). If so, > > > > > perhaps always using stateless NAT rules is the way to go (so no api > > > > > or config option). Am I missing something? > > > [ML] maybe this is why I raise this question here as I don't know the background of why it was implemented as stateful 😊 > > > > > > > > > > I am not aware of any concerns using stateless NAT. But to clarify > > > > > your > > > > > motivation: do you expect it to perform better cpu/bandwidth wise? > > > [ML] motivation is to enable ovs hardware offload to offload floating ip use-case and to improve performance. > > > > im pretty sure this has been dicussed in the past. > > > > when david and i where working on neutron at intel on the learn action > > > > firewally and openflow bridge based routing a few years ago im pretty sure > > > > we discused using nat for FIPs when contrack suppport was first being added > > > > to ovs. > > > > > > > > this makes perfect sense to me to support FIPs via ovs openflow nat rules > > > > even on ml2/ovs i dont think that needs to be restricted to ovn although ill > > > > admit the ip tables nat entries in teh kernel router namespace proably scalse > > > > better the the ovs implemenation based on teh connection tracker today. > > > > > > > > stateful vs statless not is an interesting question. > > > > https://patchwork.ozlabs.org/project/openvswitch/cover/1570154179- > > > > 14525-1-git-send-email-ankur.sharma at nutanix.com/ > > > > seams to imply that it must be implemented as a dnat_and_snat rule and i > > > > think that has the implication that since its stateless it will always take affect > > > > even in the same subnet? i dont know if we can restrict that so that the > > > > stateless rule only take effect if we are leaving the openstack env or not. > > > > > > > > I am not sure what you mean by saying "it will always take affect even > > in the same subnet". Could you please elaborate? > > > > AFAIU stateless NAT translation flows won't be reached when ports of > > the same logical switch communicate, same as they are not supposed to > > be triggered with ct_* rules. (Which is achieved by short-circuiting > > tables in OVN table architecture.) > that is what i was concerned about. iw was not sure if in stateless mode > that behavior would chagne. if no nat happens when talking to servers in the same neutorn netorks > or in other neutron networks within hte same tenant then i think we shoudl be gould to alwasy enabel it > I'll double check the logic before merging anything. > > > > > > > looking at the patches i think that would be the main delta although i am just > > > > guessing that that will be a side efffect of the stateless implemenation after a > > > > quick glance. if i am correct about that i think we would need to opt into > > > > stateless nat for FIPs to maintain backwards compatiablity. > > > > this could be done at a port level with a new extentions, at a config level > > > > ideallly globally, or perhaps we can add an extion to the FIP api to specify that > > > > it shoudl be statefully or stateless. that latter is proably the cleanest of the 3 > > > > espically if we were to also support this in other ml2/drivers eventually but i > > > > dont think we could just swtich to stateless fips if it will afffect the east west > > > > flows in any way. > > > > > > > > if there is no affeect on east west flows and it only affect north/south folow > > > > into and out of the openstack cluster then moveign to statelesss in all cases > > > > likely would improve perfermance as there will be less contention for the > > > > connection tracker. > > > [ML] in our test we didn't encounter effect on the east west flows. > and based on ^ i think that is an endorsement for always using stateless nat however we need to be able to fallback > to statefull not if ovn is not new enough to supprot it so https://review.opendev.org/c/openstack/neutron/+/804807 feels incomplete > to me. https://patchwork.ozlabs.org/project/openvswitch/cover/1570154179-14525-1-git-send-email-ankur.sharma at nutanix.com/ > this was merged in late 2019 so its reltivly recent addtion. im not sure we will want to raise our min ovn version to require statelsess > support. Not too hard to fallback; but on this note, do we maintain minimal OVN version anywhere in neutron? I remember when I was adding support for allow-stateless ACLs, I was told we don't track it (hence runtime schema inspection in https://review.opendev.org/c/openstack/neutron/+/789974) Considering potential backports in downstream products, perhaps a runtime schema check is a better approach anyway. > > > > > > > > > > > > > > Thanks, > > > > > Ihar > > > > > > > > > > > > > > > > > > > > > > > > > From dmendiza at redhat.com Wed Aug 18 15:39:17 2021 From: dmendiza at redhat.com (Douglas Mendizabal) Date: Wed, 18 Aug 2021 10:39:17 -0500 Subject: [keystone] Weekly meetings Message-ID: Hi All, I'm helping the Keystone team get the weekly meetings back on track. [1] I'd like to propose a change to the meeting time slot from Tuesday at 1700 UTC to Tuesday at 1500 UTC to make it a little earlier for our contributors in EMEA. I'll be out next week, so I won't be available to chair the meeting, but I should be back the following week for the August 31 meeting. If there are no objections to this time change, I'll go ahead and propose a change to the meetings repo. Thanks, - Douglas Mendizábal (redrobot) [1] https://meetings.opendev.org/#Keystone_Team_Meeting From johfulto at redhat.com Wed Aug 18 15:39:21 2021 From: johfulto at redhat.com (John Fulton) Date: Wed, 18 Aug 2021 11:39:21 -0400 Subject: [tripleo] Re: Need help deploying Openstack In-Reply-To: References: Message-ID: On Wed, Aug 18, 2021 at 11:29 AM wodel youchi wrote: > Thanks John, > > My idea is to learn how to deploy openstack with tripleO like what will be > with physical nodes, my goal is not to get openstack up and running to lean > how to use it, my goal is to install it in the same way as if it was a > physical implementation. > I use tripleo lab for the same reasons while I'm working on TripleO. Tripleo-lab creates the virtual hardware, adds it to Ironic and then installs the undercloud. But that's where I stop using it and then deploy the overcloud myself. In this way I can pretend I'm using physical nodes. I just don't have to deal with the environmental issues from setting up the simulation with VMs myself (e.g. the second issue below /dev/vda does not have a valid MBR). My notes on using tripleo-lab to run the commands like the ones below (though I didn't have the errors you had) are here if it's useful to you: https://github.com/fultonj/xena/tree/main/networkv2 John > About Wallaby, I have tried, but I got other errors : > > I followed these documents : > > https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/features/network_isolation.html > > https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/features/custom_networks.html#custom-networks > > https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/provisioning/baremetal_provision.html#network-config-properties > > At the end I tried these two commands : > 1) openstack overcloud node provision --stack overcloud --network-config > --output ~/overcloud-baremetal-deployed.yaml ~/templates/ > *baremetal-node-net.yaml* > > And I this error message : > >> 2021-08-15 15:59:32.402435 | 52540075-9baf-2b0b-5fc8-000000000017 | >> FATAL | Provision instances | localhost | error={"changed": false, >> "logging": "Deploy attempt failed on node computeHCI2 >> (UUID 9440e769-9634-4015-82b0-97b8c1921ef5), >> cleaning up\nTraceback (most recent call last):\n File >> \"/usr/lib/python3.6/site-packages/metalsmith/_provisioner.py\", line 392, >> in provision_node\n nics.validate()\n >> File \"/usr/lib/python3.6/site-packages/metalsmith/_nics.py\", line 60, >> in validate\n >> result.append(('network', self._get_network(nic)))\n File >> \"/usr/lib/python3.6/site-packages/metalsmith/_nics.py\", line 128, in >> _get_network\n >> 'Unexpected fields for a network: %s' % ', >> '.join(unexpected))\nmetalsmith.exceptions.InvalidNIC: >> Unexpected fields for a network: subnet\nDeploy attempt failed on node >> computeHCI0 (UUID 31eecc38-7d80-4ddd-9cc4-a76edf00ec3a), >> cleaning up\nTraceback (most recent call last):\n File >> \"/usr/lib/python3.6/site-packages/metalsmith/_provisioner.py\", line 392, >> in provision_node\n >> nics.validate()\n File >> \"/usr/lib/python3.6/site-packages/metalsmith/_nics.py\", line 60, in >> validate\n >> result.append(('network', self._get_network(nic)))\n File >> \"/usr/lib/python3.6/site-packages/metalsmith/_nics.py\", line 128, in >> _get_network\n >> 'Unexpected fields for a network: %s' % ', >> '.join(unexpected))\nmetalsmith.exceptions.InvalidNIC: >> Unexpected fields for a network: subnet\nDeploy attempt failed on node >> controller2 (UUID f62f8cb5-40e4-4e40-805d-852c2a2f7e00), >> cleaning up\nTraceback (most recent call last):\n File >> \"/usr/lib/python3.6/site-packages/metalsmith/_provisioner.py\", line 392, >> in provision_node\n nics.validate()\n File >> \"/usr/lib/python3.6/site-packages/metalsmith/_nics.py\", line 60, in >> validate\n >> result.append(('network', self._get_network(nic)))\n File >> \"/usr/lib/python3.6/site-packages/metalsmith/_nics.py\", line 128, in >> _get_network\n >> 'Unexpected fields for a network: %s' % ', >> '.join(unexpected))\nmetalsmith.exceptions.InvalidNIC: >> Unexpected fields for a network: subnet\nDeploy attempt failed on node >> computeHCI1 (UUID 2798b208-4842-4083-9b3f-c46953b52928), >> cleaning up\nTraceback (most recent call last):\n File >> \"/usr/lib/python3.6/site-packages/metalsmith/_provisioner.py\", line 392, >> in provision_node\n nics.validate()\n File >> \"/usr/lib/python3.6/site-packages/metalsmith/_nics.py\", line 60, in >> validate\n >> result.append(('network', self._get_network(nic)))\n File >> \"/usr/lib/python3.6/site-packages/metalsmith/_nics.py\", line 128, in >> _get_network\n >> 'Unexpected fields for a network: %s' % ', >> '.join(unexpected))\nmetalsmith.exceptions.InvalidNIC: Unexpected fields >> for a network: subnet\n >> Deploy attempt failed on node controller1 (UUID >> df87e5c7-32b0-4bfa-9ef9-f0a98666e7de), cleaning up\nTraceback (most recent >> call last):\n >> File \"/usr/lib/python3.6/site-packages/metalsmith/_provisioner.py\", >> line 392, in provision_node\n >> nics.validate()\n File >> \"/usr/lib/python3.6/site-packages/metalsmith/_nics.py\", line 60, in >> validate\n >> result.append(('network', self._get_network(nic)))\n File >> \"/usr/lib/python3.6/site-packages/metalsmith/_nics.py\", line 128, in >> _get_network\n >> 'Unexpected fields for a network: %s' % ', >> '.join(unexpected))\nmetalsmith.exceptions.InvalidNIC: Unexpected fields >> for a network: subnet\nDeploy attempt failed on node controller0 (UUID >> af75122c-a6e8-42d7-afd2-571738c42061), cleaning up\nTraceback (most recent >> call last):\n File \"/usr/lib/python3.6/site-packages/metalsmith/_*provisioner.py\", >> line 392, in provision_node\n nics.validate()\n File >> \"/usr/lib/python3.6/site-**packages/metalsmith/_nics.py\"**, line 60, >> in validate\n result.append(('network', self._get_network(nic)))\n File >> \"/usr/lib/python3.6/site-**packages/metalsmith/_nics.py\"**, line 128, >> in _get_network\n 'Unexpected fields for a network: %s' % ', >> '.join(unexpected))\**nmetalsmith.exceptions.**InvalidNIC: Unexpected >> fields for a network: subnet\n", "msg": "Unexpected fields for a network: >> subnet"}* >> > > > > 2) openstack overcloud node provision --stack overcloud --output ~/ > overcloud-baremetal-deployed.yaml ~/templates/*baremetal-node**.yaml* > > This time I got this error : > >> 2021-08-16 13:47:02.156021 | 52540075-9baf-0672-d7b8-000000000017 | >> FATAL | Provision instances | localhost | error={"changed": false, >> "logging": "Created port overcloud-computehci-1-ctlplane (UUID >> 17e55729-b44b-40a8-9361-9e36e8527de5) for node controller0 (UUID >> 61bc6512-9c4e-4199-936a-754801f7cffa) with {'network_id': >> '1c8c5e86-79ac-4ec6-9616-3c965cab6e88', 'name': >> 'overcloud-computehci-1-ctlplane'}\nCreated port >> overcloud-controller-0-ctlplane (UUID 0a09bbb5-934d-4d34-ab5b-7c14518d06c6) >> for node controller1 (UUID 03915e7c-a314-41d9-be8c-46291879692a) with >> {'network_id': '1c8c5e86-79ac-4ec6-9616-3c965cab6e88', 'name': >> 'overcloud-controller-0-ctlplane'}\nCreated port >> overcloud-computehci-2-ctlplane (UUID 76ef56f1-4dbb-453e-a344-968b0da95823) >> for node computeHCI2 (UUID a5d3552b-ab79-404e-8a52-48dc53a3aa45) with >> {'network_id': '1c8c5e86-79ac-4ec6-9616-3c965cab6e88', 'name': >> 'overcloud-computehci-2-ctlplane'}\nCreated port >> overcloud-computehci-0-ctlplane (UUID 79967f38-90ee-49e6-8716-b09cc9460afe) >> for node computeHCI1 (UUID 3534309b-c11f-48d4-b23d-3ed9f2dcbf79) with >> {'network_id': '1c8c5e86-79ac-4ec6-9616-3c965cab6e88', 'name': >> 'overcloud-computehci-0-ctlplane'}\nCreated port >> overcloud-controller-1-ctlplane (UUID c70b7c8c-31a6-460e-aa77-ea37b8e332f6) >> for node controller2 (UUID 83f47771-9f82-4437-8df4-de32bcd6fc63) with >> {'network_id': '1c8c5e86-79ac-4ec6-9616-3c965cab6e88', 'name': >> 'overcloud-controller-1-ctlplane'}\nCreated port >> overcloud-controller-2-ctlplane (UUID 2b74c4e3-705c-4bf1-85de-a5e0a9cdb591) >> for node computeHCI0 (UUID 3924529b-44a7-4c74-b1e1-2175d6313a3e) with >> {'network_id': '1c8c5e86-79ac-4ec6-9616-3c965cab6e88', 'name': >> 'overcloud-controller-2-ctlplane'}\nAttached port >> overcloud-controller-0-ctlplane (UUID 0a09bbb5-934d-4d34-ab5b-7c14518d06c6) >> to node controller1 (UUID 03915e7c-a314-41d9-be8c-46291879692a)\nAttached >> port overcloud-computehci-1-ctlplane (UUID >> 17e55729-b44b-40a8-9361-9e36e8527de5) to node controller0 (UUID >> 61bc6512-9c4e-4199-936a-754801f7cffa)\nProvisioning started on node >> controller1 (UUID 03915e7c-a314-41d9-be8c-46291879692a)\nAttached port >> overcloud-computehci-2-ctlplane (UUID 76ef56f1-4dbb-453e-a344-968b0da95823) >> to node computeHCI2 (UUID a5d3552b-ab79-404e-8a52-48dc53a3aa45)\nAttached >> port overcloud-computehci-0-ctlplane (UUID >> 79967f38-90ee-49e6-8716-b09cc9460afe) to node computeHCI1 (UUID >> 3534309b-c11f-48d4-b23d-3ed9f2dcbf79)\nProvisioning started on node >> controller0 (UUID 61bc6512-9c4e-4199-936a-754801f7cffa)\nAttached port >> overcloud-controller-1-ctlplane (UUID c70b7c8c-31a6-460e-aa77-ea37b8e332f6) >> to node controller2 (UUID >> 83f47771-9f82-4437-8df4-de32bcd6fc63)\nProvisioning started on node >> computeHCI2 (UUID a5d3552b-ab79-404e-8a52-48dc53a3aa45)\nProvisioning >> started on node computeHCI1 (UUID >> 3534309b-c11f-48d4-b23d-3ed9f2dcbf79)\nAttached port >> overcloud-controller-2-ctlplane (UUID 2b74c4e3-705c-4bf1-85de-a5e0a9cdb591) >> to node computeHCI0 (UUID >> 3924529b-44a7-4c74-b1e1-2175d6313a3e)\nProvisioning started on node >> controller2 (UUID 83f47771-9f82-4437-8df4-de32bcd6fc63)\nProvisioning >> started on node computeHCI0 (UUID 3924529b-44a7-4c74-b1e1-2175d6313a3e)\n", >> "msg": "Node *a5d3552b-ab79-404e-8a52-**48dc53a3aa45 reached failure >> state \"deploy failed\"; the last error is Agent returned error for deploy >> step {'step': 'write_image', 'priority': 80, 'argsinfo': None, 'interface': >> 'deploy'} on node a5d3552b-ab79-404e-8a52-**48dc53a3aa45 : Error >> performing deploy_step write_image: Command execution failed: Failed to >> check the number of primary partitions present on /dev/vda for node >> a5d3552b-ab79-404e-8a52-**48dc53a3aa45. Error: The device /dev/vda does >> not have a valid MBR partition table."}* >> > > Any ideas? thanks in advance. > > Regards. > > Le mer. 18 août 2021 à 16:01, John Fulton a écrit : > >> Hi Wodel, >> >> Yes, it's possible to deploy openstack with tripleo using VMs and >> nested-KVM for the compute node. I personally use this tool on my >> hypervisor to do it. >> >> https://github.com/cjeanner/tripleo-lab >> >> By trying to get tripleo working with nested KVM without using a tool >> like the above you might eventually create your own version of the same >> tool though using the above helps you skip those steps. >> >> The issue you're hitting from the error message below looks like the Nova >> scheduler on the undercloud not finding an Ironic node that satisfies the >> scheduling criteria. This can be debugged but you might find it easier to >> just not have the problem by letting another tool deal with this for you. >> Also, with wallaby and newer tripleo does not use Nova on the undercloud >> and instead the recommended deployment process is to use metalsmith as >> described here: >> >> >> https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/provisioning/baremetal_provision.html >> >> You also have the standalone option of using tripleo on a single VM: >> >> >> https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/deployment/standalone.html >> >> John >> >> On Wed, Aug 18, 2021 at 10:28 AM wodel youchi >> wrote: >> >>> Hi, >>> I am trying to deploy openstack with tripleO using VMs and nested-KVM >>> for the compute node. This is for test and learning purposes. >>> >>> I am using the Train version and following some tutorials. >>> I prepared my different template files and started the deployment, but I >>> got these errors : >>> >>> *Failed to provision instance fc40457e-4b3c-4402-ae9d-c528f2c2ad30: >>> Asynchronous exception: Node failed to deploy. Exception: Agent API for >>> node 6d3724fc-6f13-4588-bbe5-56bc4f9a4f87 returned HTTP status code 404 >>> with error: Not found: Extension with id iscsi not found. for node* >>> >>> and >>> >>> *Got HTTP 409: {"errors": [{"status": 409, "title": "Conflict", >>> "detail": "There was a conflict when trying to complete your request.\n\n >>> Unable to allocate inventory: Unable to create allocation for >>> 'CUSTOM_BAREMETAL' on resource provider >>> '6d3724fc-6f13-4588-bbe5-56bc4f9a4f87'. The requested amount would exceed >>> the capacity. ",* >>> >>> Could you help understand what those errors mean? I couldn't find >>> anything similar on the net. >>> >>> Thanks in advance. >>> >>> Regards. >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From iurygregory at gmail.com Wed Aug 18 16:03:07 2021 From: iurygregory at gmail.com (Iury Gregory) Date: Wed, 18 Aug 2021 18:03:07 +0200 Subject: [Ironic] Xena Midcycle next week! Message-ID: Hello Ironicers! Our schedule for the Midcycle is available in the etherpad[1]. See you next week! [1] https://etherpad.opendev.org/p/ironic-xena-midcycle -- *Att[]'sIury Gregory Melo Ferreira * *MSc in Computer Science at UFCG* *Part of the ironic-core and puppet-manager-core team in OpenStack* *Software Engineer at Red Hat Czech* *Social*: https://www.linkedin.com/in/iurygregory *E-mail: iurygregory at gmail.com * -------------- next part -------------- An HTML attachment was scrubbed... URL: From dtantsur at redhat.com Wed Aug 18 16:05:19 2021 From: dtantsur at redhat.com (Dmitry Tantsur) Date: Wed, 18 Aug 2021 18:05:19 +0200 Subject: Need help deploying Openstack In-Reply-To: References: Message-ID: Hi, On Wed, Aug 18, 2021 at 4:39 PM wodel youchi wrote: > Hi, > I am trying to deploy openstack with tripleO using VMs and nested-KVM for > the compute node. This is for test and learning purposes. > > I am using the Train version and following some tutorials. > I prepared my different template files and started the deployment, but I > got these errors : > > *Failed to provision instance fc40457e-4b3c-4402-ae9d-c528f2c2ad30: > Asynchronous exception: Node failed to deploy. Exception: Agent API for > node 6d3724fc-6f13-4588-bbe5-56bc4f9a4f87 returned HTTP status code 404 > with error: Not found: Extension with id iscsi not found. for node* > > You somehow ended up using master (Xena release) deploy ramdisk with Train TripleO. You need to make sure to download Train images. I hope TripleO people can point you at the right place. Dmitry > and > > *Got HTTP 409: {"errors": [{"status": 409, "title": "Conflict", "detail": > "There was a conflict when trying to complete your request.\n\n Unable to > allocate inventory: Unable to create allocation for 'CUSTOM_BAREMETAL' on > resource provider '6d3724fc-6f13-4588-bbe5-56bc4f9a4f87'. The requested > amount would exceed the capacity. ",* > > Could you help understand what those errors mean? I couldn't find anything > similar on the net. > > Thanks in advance. > > Regards. > -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill -------------- next part -------------- An HTML attachment was scrubbed... URL: From miguel at mlavalle.com Wed Aug 18 16:13:01 2021 From: miguel at mlavalle.com (Miguel Lavalle) Date: Wed, 18 Aug 2021 11:13:01 -0500 Subject: [neutron][elections] PTL non candidacy for Y cycle In-Reply-To: References: <24443596.64OI9Hj3fW@p1> Message-ID: Hi Slawek, As always, it has been a pleasure to work under your leadership. You are a great PTL! Thanks for all your hard work Best regards Miguel On Wed, Aug 18, 2021 at 3:36 AM Lucas Alvares Gomes wrote: > Thank you for your hard work Slawek! > > On Wed, Aug 18, 2021 at 8:15 AM Rodolfo Alonso Hernandez > wrote: > > > > Thank you Slawek for your time and hard work. > > > > On Wed, Aug 18, 2021 at 12:35 AM Amy Marrich wrote: > >> > >> Thanks for all your hard work Slawek! > >> > >> Amy (spotz) > >> > >> > > >> > On Aug 17, 2021, at 3:57 PM, Slawek Kaplonski > wrote: > >> > > >> > Hi, > >> > > >> > It's been great 2 years for me when I had an honor to serve as > Neutron PTL - > >> > yeah, time flies :) > >> > It has been pleasure to work with all of You on the Neutron project. > We did a > >> > lot of great things during that time. > >> > But now, as I said in my last nomination [1], I'm not going to > candidate for > >> > being PTL in the Yoga cycle. I think it's good for the project to > have new > >> > leader every few cycles. That brings fresh ideas and new energy to the > >> > project. > >> > If You would be interested in that, to which I encourage anyone, and > maybe > >> > have any questions, feel free to reach out to me in any way (irc, > email, > >> > etc.). I will be more than happy to answer all Your questions. > >> > > >> > As for me, I'm not going anywhere. I'm still going to work on Neutron > as I did > >> > so far. > >> > I will be of course very happy to help new PTL if that will be needed > :) > >> > > >> > Once again thank You all for all Your help and supporting me in that > role in > >> > the last 2 years and good luck to our new PTL! > >> > > >> > [1] > http://lists.openstack.org/pipermail/openstack-discuss/2021-March/ > >> > 020901.html > >> > > >> > -- > >> > Slawek Kaplonski > >> > Principal Software Engineer > >> > Red Hat > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From radoslaw.piliszek at gmail.com Wed Aug 18 16:32:50 2021 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Wed, 18 Aug 2021 18:32:50 +0200 Subject: [murano][tc] Project Retirement In-Reply-To: References: <3117ebb2-ea5f-9905-2447-1773c4c23eab@openstack.org> Message-ID: On Wed, Aug 18, 2021 at 3:08 PM Thierry Carrez wrote: > > Rong Zhu wrote: > > Sorry for my late response, I am a little bit busy for internal works > > recently. > > > > If TC has decided to retire murano, I have no objection. But If TC think > > someone can keep maintain it and not retire, I am glad to keeping > > maintain Murano project. Please reconsider this. > > For the record, I don't think there is an urgent need to retire Murano > as long as it is maintained, fills community goals, hits release > requirements, and is functional. I disagree. I think we are giving it a false sense of usability. It likely can do "something" but there does not seem to exist enough workforce to triage and fix bugs [1] for quite some time. And some [2] look like users are having a hard time using it. This was also observed by me with my Kolla hat on - folks reported to us that they can't get Murano stuff running and we could only spread our hands. (-: It also does not seem to have had any new features since at least Stein. [3] We can also take a look at stackalytics [4]. Most person-day effort was eaten up by community-wide changes. My POV is that OpenStack is still a kind of quality badge that applies to projects under its umbrella. Seemingly, it's also the perspective of folks outside of the close community (ask anyone doing consulting ;-) ). And thus we should retire projects which did not stand the test of time. I am thankful for Rong Zhu's efforts to keep the project alive but it seems the world has moved on to solutions based on different technologies, as mentioned by you (Thierry) and Mohammed. And we, as OpenStack, should accept that and focus on better integration with those. [1] https://bugs.launchpad.net/murano/+bugs?orderby=-id&start=0 [2] https://bugs.launchpad.net/murano/+bug/1817538 [3] https://docs.openstack.org/releasenotes/murano/index.html [4] https://www.stackalytics.io/?module=murano-group&metric=person-day&release=xena -yoctozepto > Like mnaser said, it is a bit off in the modern landscape of application > deployment technology, so I don't think it's a priority anymore -- if > its continued existence blocked people from focusing on more critical > components, I would support removing it. But based on Rong Zhu's > response I'm not sure that's the case. > > -- > Thierry > From whayutin at redhat.com Wed Aug 18 17:02:35 2021 From: whayutin at redhat.com (Wesley Hayutin) Date: Wed, 18 Aug 2021 11:02:35 -0600 Subject: Need help deploying Openstack In-Reply-To: References: Message-ID: On Wed, Aug 18, 2021 at 10:10 AM Dmitry Tantsur wrote: > Hi, > > On Wed, Aug 18, 2021 at 4:39 PM wodel youchi > wrote: > >> Hi, >> I am trying to deploy openstack with tripleO using VMs and nested-KVM for >> the compute node. This is for test and learning purposes. >> >> I am using the Train version and following some tutorials. >> I prepared my different template files and started the deployment, but I >> got these errors : >> >> *Failed to provision instance fc40457e-4b3c-4402-ae9d-c528f2c2ad30: >> Asynchronous exception: Node failed to deploy. Exception: Agent API for >> node 6d3724fc-6f13-4588-bbe5-56bc4f9a4f87 returned HTTP status code 404 >> with error: Not found: Extension with id iscsi not found. for node* >> >> > You somehow ended up using master (Xena release) deploy ramdisk with Train > TripleO. You need to make sure to download Train images. I hope TripleO > people can point you at the right place. > > Dmitry > http://images.rdoproject.org/centos8/ http://images.rdoproject.org/centos8/train/rdo_trunk/current-tripleo/ > > >> and >> >> *Got HTTP 409: {"errors": [{"status": 409, "title": "Conflict", "detail": >> "There was a conflict when trying to complete your request.\n\n Unable to >> allocate inventory: Unable to create allocation for 'CUSTOM_BAREMETAL' on >> resource provider '6d3724fc-6f13-4588-bbe5-56bc4f9a4f87'. The requested >> amount would exceed the capacity. ",* >> >> Could you help understand what those errors mean? I couldn't find >> anything similar on the net. >> >> Thanks in advance. >> >> Regards. >> > > > -- > Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, > Commercial register: Amtsgericht Muenchen, HRB 153243, > Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael > O'Neill > -------------- next part -------------- An HTML attachment was scrubbed... URL: From moshele at nvidia.com Tue Aug 17 19:13:58 2021 From: moshele at nvidia.com (Moshe Levi) Date: Tue, 17 Aug 2021 19:13:58 +0000 Subject: [neutron][ovn] support for stateless NAT for floating ip in ml2 ovn In-Reply-To: <9096201007244d0732f019d1452575e61080e09c.camel@redhat.com> References: <20210817002002.252368-1-ihrachys@redhat.com> <9096201007244d0732f019d1452575e61080e09c.camel@redhat.com> Message-ID: > -----Original Message----- > From: Sean Mooney > Sent: Tuesday, August 17, 2021 2:32 PM > To: Ihar Hrachyshka ; openstack- > discuss at lists.openstack.org > Subject: Re: [neutron][ovn] support for stateless NAT for floating ip in ml2 > ovn > > External email: Use caution opening links or attachments > > > On Mon, 2021-08-16 at 20:20 -0400, Ihar Hrachyshka wrote: > > > Hi all, > > > > > > OVN support stateless NAT operations [1] for use case of 1:1 mapped > > > between inner and external ips, i.e dnat_and_snat rule. In openstack > > > is the floating ip use-case. Looking on ml2 ovn support it seem > > > that it only support floating ip with connection tracking. Can ml2 > > > ovn support also the stateless NAT option? Is there concerns using > stateless NAT? > > > > Hi Moshe, > moshe out of interest does hardware offloaded ovs support hardware > offloaded NAT (stateful or stateless) yet with connectx-6 dx? So connectx-6 dx can offload NAT (just SNAT or DNAT), but in the case of dnat_and_snat rules offload won't work. We need to optimize ovn to make it work because of it snat and dnat zones. We can offload stateless without changing ovn and the driver and the performance is better because we don't have the snat /dnat zone in ovn. > > im not sure how feature enabled the connection tracker suppport is in the tc > flower offload path so if this provided the ablity to do hardware offloaded > floating ip nat i think this would be another point in favor of supporting it. [ML] so the stateless nat we can do today. (we check it in openstack env and just adding stateless config manual in ovn tables. > > the dpdk connection track is certelly still a bottle neck to dpdk perfromance > so for ovs-dpdk i would expect to see a nice uplift in perfermance vs > userspace contrack based nat so that is another reason to support this in my > view. > > > > you are talking about an "option". Do you mean OpenStack would have a > > new API extension for FIPs to choose it? Or a configuration option? I was talking about config option, because I wasn’t sure if we want to keep the stateful behavior or there are use case when customer will want to use stateful NAT. > > > > AFAIU the only limitation for stateless dnat_and_snat rules in OVN is > > that the mapping must be 1:1, which I think is always the case with > > OpenStack FIPs (fixed_ip_address attribute is not a list). If so, > > perhaps always using stateless NAT rules is the way to go (so no api > > or config option). Am I missing something? [ML] maybe this is why I raise this question here as I don't know the background of why it was implemented as stateful 😊 > > > > I am not aware of any concerns using stateless NAT. But to clarify > > your > > motivation: do you expect it to perform better cpu/bandwidth wise? [ML] motivation is to enable ovs hardware offload to offload floating ip use-case and to improve performance. > im pretty sure this has been dicussed in the past. > when david and i where working on neutron at intel on the learn action > firewally and openflow bridge based routing a few years ago im pretty sure > we discused using nat for FIPs when contrack suppport was first being added > to ovs. > > this makes perfect sense to me to support FIPs via ovs openflow nat rules > even on ml2/ovs i dont think that needs to be restricted to ovn although ill > admit the ip tables nat entries in teh kernel router namespace proably scalse > better the the ovs implemenation based on teh connection tracker today. > > stateful vs statless not is an interesting question. > https://patchwork.ozlabs.org/project/openvswitch/cover/1570154179- > 14525-1-git-send-email-ankur.sharma at nutanix.com/ > seams to imply that it must be implemented as a dnat_and_snat rule and i > think that has the implication that since its stateless it will always take affect > even in the same subnet? i dont know if we can restrict that so that the > stateless rule only take effect if we are leaving the openstack env or not. > > looking at the patches i think that would be the main delta although i am just > guessing that that will be a side efffect of the stateless implemenation after a > quick glance. if i am correct about that i think we would need to opt into > stateless nat for FIPs to maintain backwards compatiablity. > this could be done at a port level with a new extentions, at a config level > ideallly globally, or perhaps we can add an extion to the FIP api to specify that > it shoudl be statefully or stateless. that latter is proably the cleanest of the 3 > espically if we were to also support this in other ml2/drivers eventually but i > dont think we could just swtich to stateless fips if it will afffect the east west > flows in any way. > > if there is no affeect on east west flows and it only affect north/south folow > into and out of the openstack cluster then moveign to statelesss in all cases > likely would improve perfermance as there will be less contention for the > connection tracker. [ML] in our test we didn't encounter effect on the east west flows. > > > > > Thanks, > > Ihar > > > > > > From GustavoFaganello.Santos at windriver.com Wed Aug 18 20:39:58 2021 From: GustavoFaganello.Santos at windriver.com (Santos, Gustavo Faganello) Date: Wed, 18 Aug 2021 20:39:58 +0000 Subject: [horizon][dev] Auto-Refresh Feature Proposal Message-ID: Hello, everyone. I'm here to find out what you think about the addition of a feature in OpenStack Horizon. As you may know, Horizon requires the user to manually update the page in order to get the most recent data in the system, e.g. if an instance is created, deleted or renamed before the page is reloaded, the user has to hit the refresh button in their browser to see those chang​es in the page. This applies to the majority of Horizon's pages, including, but not limited to, Instances, Volumes, Users and so on. With that in mind, our team has implemented and tested a prototype of an auto-refresh feature for Horizon. We've been using it for a while now and have received positive feedback from our clients. It automatically updates the information in tables, pie charts (such as the Compute Overview page graphs) and details pages every five seconds, without the need for manually refreshing the page. The information displayed on the page will be replaced by the most recent data without any action from the user or any page reloading. It essentially works by requesting, in the background, the opened page again and again every few seconds through AJAX, and then replacing the old information with the new one if they differ. The feature affects every element in Horizon, except AngularJS ones - the tables in the Compute Images, Key Pairs and Server Groups pages are AngularJS elements and will not be affected by auto-refresh, for example. We are open to looking into this issue in the future, though. Could you please let us know if you would be open to adding such a feature to Horizon? If so, we'd be willing to do the upstream implementation in OpenStack, and we think it would be a great addition to the end users. Kind regards. Gustavo Santos -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierre at stackhpc.com Wed Aug 18 20:52:37 2021 From: pierre at stackhpc.com (Pierre Riteau) Date: Wed, 18 Aug 2021 22:52:37 +0200 Subject: [blazar][ptg] Yoga PTG meeting In-Reply-To: References: Message-ID: Due to interest from Blazar users based in Australia, I have proposed an additional PTG session on Tuesday, October 19 from 07:00 to 08:00 UTC in the Diablo room. I encourage anyone based in Asia-Pacific who is interested in using or contributing to Blazar to join this session. On Thu, 12 Aug 2021 at 10:55, Pierre Riteau wrote: > Hello, > > As part of the Yoga PTG, the Blazar team project will meet on Thursday > October 21 from 15:00 to 17:00 UTC in the Bexar room. > > I have created an Etherpad to define the agenda: > https://etherpad.opendev.org/p/yoga-ptg-blazar > Feel free to add topics you would like to see discussed. > > Thanks, > Pierre Riteau > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lyarwood at redhat.com Wed Aug 18 21:07:34 2021 From: lyarwood at redhat.com (Lee Yarwood) Date: Wed, 18 Aug 2021 22:07:34 +0100 Subject: [nova][qa][infra] Adding no_timer_check to the kernel command line of our CI images Message-ID: <20210818210734.yruh6dygt22oc3nv@lyarwood-laptop.usersys.redhat.com> Hello all, For a while now we've been attempting to track down some infrequent but annoying Tempest test cleanup failures in CI when detaching volumes from an instance. Finally after rewriting part of the Tempest logic controlling the cleanup we've been able to confirm that this is being caused by a kernel panic within the instance at boot time as documented in the following bug: Failure to detach volume during Tempest test cleanup due to APIC related kernel panic within the guest OS https://bugs.launchpad.net/nova/+bug/1939108 This had been previously found in 2014 but at the time a fix was only proposed to Nova that would solve this when using a supplied kernel image: cirros 0.3.1 fails to boot https://bugs.launchpad.net/cirros/+bug/1312199 Use no_timer_check with soft-qemu https://review.opendev.org/c/openstack/nova/+/96090 Most (all?) of our CI currently running with [libvirt]virt_type=qemu uses the full Cirros 0.5.2 image. Does anyone have any suggestions on the best way of modifying the image(s) we use in CI to use the no_timer_check kernel command line arg? Thanks in advance, -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From akanevsk at redhat.com Wed Aug 18 21:12:47 2021 From: akanevsk at redhat.com (Arkady Kanevsky) Date: Wed, 18 Aug 2021 17:12:47 -0400 Subject: [nova][qa][infra] Adding no_timer_check to the kernel command line of our CI images In-Reply-To: <20210818210734.yruh6dygt22oc3nv@lyarwood-laptop.usersys.redhat.com> References: <20210818210734.yruh6dygt22oc3nv@lyarwood-laptop.usersys.redhat.com> Message-ID: Thanks Lee. it was causing problems for a long time. Thanks, Arkady On Wed, Aug 18, 2021 at 5:09 PM Lee Yarwood wrote: > Hello all, > > For a while now we've been attempting to track down some infrequent but > annoying Tempest test cleanup failures in CI when detaching volumes from > an instance. Finally after rewriting part of the Tempest logic > controlling the cleanup we've been able to confirm that this is being > caused by a kernel panic within the instance at boot time as documented > in the following bug: > > Failure to detach volume during Tempest test cleanup due to APIC related > kernel panic within the guest OS > https://bugs.launchpad.net/nova/+bug/1939108 > > This had been previously found in 2014 but at the time a fix was only > proposed to Nova that would solve this when using a supplied kernel > image: > > cirros 0.3.1 fails to boot > https://bugs.launchpad.net/cirros/+bug/1312199 > > Use no_timer_check with soft-qemu > https://review.opendev.org/c/openstack/nova/+/96090 > > Most (all?) of our CI currently running with [libvirt]virt_type=qemu > uses the full Cirros 0.5.2 image. Does anyone have any suggestions on > the best way of modifying the image(s) we use in CI to use the > no_timer_check kernel command line arg? > > Thanks in advance, > > -- > Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 > 2D76 > -- Arkady Kanevsky, Ph.D. Phone: 972 707-6456 Corporate Phone: 919 729-5744 ext. 8176456 -------------- next part -------------- An HTML attachment was scrubbed... URL: From cboylan at sapwetik.org Wed Aug 18 21:44:22 2021 From: cboylan at sapwetik.org (Clark Boylan) Date: Wed, 18 Aug 2021 14:44:22 -0700 Subject: =?UTF-8?Q?Re:_[nova][qa][infra]_Adding_no=5Ftimer=5Fcheck_to_the_kernel_?= =?UTF-8?Q?command_line_of_our_CI_images?= In-Reply-To: <20210818210734.yruh6dygt22oc3nv@lyarwood-laptop.usersys.redhat.com> References: <20210818210734.yruh6dygt22oc3nv@lyarwood-laptop.usersys.redhat.com> Message-ID: <43403578-abcf-4313-affd-2a27c3f076c5@www.fastmail.com> On Wed, Aug 18, 2021, at 2:07 PM, Lee Yarwood wrote: > Hello all, > > For a while now we've been attempting to track down some infrequent but > annoying Tempest test cleanup failures in CI when detaching volumes from > an instance. Finally after rewriting part of the Tempest logic > controlling the cleanup we've been able to confirm that this is being > caused by a kernel panic within the instance at boot time as documented > in the following bug: > > Failure to detach volume during Tempest test cleanup due to APIC related > kernel panic within the guest OS > https://bugs.launchpad.net/nova/+bug/1939108 > > This had been previously found in 2014 but at the time a fix was only > proposed to Nova that would solve this when using a supplied kernel > image: > > cirros 0.3.1 fails to boot > https://bugs.launchpad.net/cirros/+bug/1312199 > > Use no_timer_check with soft-qemu > https://review.opendev.org/c/openstack/nova/+/96090 > > Most (all?) of our CI currently running with [libvirt]virt_type=qemu > uses the full Cirros 0.5.2 image. Does anyone have any suggestions on > the best way of modifying the image(s) we use in CI to use the > no_timer_check kernel command line arg? The best way is probably to update the image upstream and then update the cirros version in our tests? https://github.com/cirros-dev/cirros/blob/master/src/boot/grub/menu.lst#L10 or maybe with a kernel build flag? Smoser does note in 1312199 above that baking this into the image is an option though that was some time ago. If you want to modify the existing images instead it would probably be a good idea to have something like devstack do it rather than the CI system so that people running tools like devstack don't end up with different images outside of the CI system. > > Thanks in advance, > > -- > Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76 From johnsomor at gmail.com Wed Aug 18 23:44:00 2021 From: johnsomor at gmail.com (Michael Johnson) Date: Wed, 18 Aug 2021 16:44:00 -0700 Subject: [horizon][dev] Auto-Refresh Feature Proposal In-Reply-To: References: Message-ID: Hi Gustavo, The Octavia pages (AngularJS) auto refresh like you are describing. The start of that work was this patch: https://review.opendev.org/c/openstack/octavia-dashboard/+/561458 in case it is helpful. Michael On Wed, Aug 18, 2021 at 1:46 PM Santos, Gustavo Faganello wrote: > > Hello, everyone. > > > > I'm here to find out what you think about the addition of a feature in OpenStack Horizon. As you may know, Horizon requires the user to manually update the page in order to get the most recent data in the system, e.g. if an instance is created, deleted or renamed before the page is reloaded, the user has to hit the refresh button in their browser to see those changes in the page. This applies to the majority of Horizon's pages, including, but not limited to, Instances, Volumes, Users and so on. > > > > With that in mind, our team has implemented and tested a prototype of an auto-refresh feature for Horizon. We've been using it for a while now and have received positive feedback from our clients. It automatically updates the information in tables, pie charts (such as the Compute Overview page graphs) and details pages every five seconds, without the need for manually refreshing the page. The information displayed on the page will be replaced by the most recent data without any action from the user or any page reloading. It essentially works by requesting, in the background, the opened page again and again every few seconds through AJAX, and then replacing the old information with the new one if they differ. The feature affects every element in Horizon, except AngularJS ones - the tables in the Compute Images, Key Pairs and Server Groups pages are AngularJS elements and will not be affected by auto-refresh, for example. We are open to looking into this issue in the future, though. > > > > Could you please let us know if you would be open to adding such a feature to Horizon? If so, we'd be willing to do the upstream implementation in OpenStack, and we think it would be a great addition to the end users. > > > > Kind regards. > > Gustavo Santos From aaronzhu1121 at gmail.com Thu Aug 19 00:07:33 2021 From: aaronzhu1121 at gmail.com (Rong Zhu) Date: Thu, 19 Aug 2021 08:07:33 +0800 Subject: [murano][tc] Project Retirement In-Reply-To: References: <3117ebb2-ea5f-9905-2447-1773c4c23eab@openstack.org> Message-ID: I am agree with all of you, But most of the projects are lacking of contributors. Keep or remove Murano can not make things better. I know some people are using Murano internal, they submited a bugfix sometimes. Remove Murano can not make those people focus on other projects, But will let those people out and a PTL out. Thanks, Rong Zhu Radosław Piliszek 于2021年8月19日 周四00:36写道： > On Wed, Aug 18, 2021 at 3:08 PM Thierry Carrez > wrote: > > > > Rong Zhu wrote: > > > Sorry for my late response, I am a little bit busy for internal works > > > recently. > > > > > > If TC has decided to retire murano, I have no objection. But If TC > think > > > someone can keep maintain it and not retire, I am glad to keeping > > > maintain Murano project. Please reconsider this. > > > > For the record, I don't think there is an urgent need to retire Murano > > as long as it is maintained, fills community goals, hits release > > requirements, and is functional. > > I disagree. I think we are giving it a false sense of usability. > It likely can do "something" but there does not seem to exist enough > workforce to triage and fix bugs [1] for quite some time. > And some [2] look like users are having a hard time using it. > This was also observed by me with my Kolla hat on - folks reported to > us that they can't get Murano stuff running and we could only spread > our hands. (-: > It also does not seem to have had any new features since at least Stein. > [3] > > We can also take a look at stackalytics [4]. > Most person-day effort was eaten up by community-wide changes. > > My POV is that OpenStack is still a kind of quality badge that applies > to projects under its umbrella. > Seemingly, it's also the perspective of folks outside of the close > community (ask anyone doing consulting ;-) ). > And thus we should retire projects which did not stand the test of time. > > I am thankful for Rong Zhu's efforts to keep the project alive but it > seems the world has moved on to solutions based on different > technologies, as mentioned by you (Thierry) and Mohammed. > And we, as OpenStack, should accept that and focus on better > integration with those. > > [1] https://bugs.launchpad.net/murano/+bugs?orderby=-id&start=0 > [2] https://bugs.launchpad.net/murano/+bug/1817538 > [3] https://docs.openstack.org/releasenotes/murano/index.html > [4] > https://www.stackalytics.io/?module=murano-group&metric=person-day&release=xena > > -yoctozepto > > > > Like mnaser said, it is a bit off in the modern landscape of application > > deployment technology, so I don't think it's a priority anymore -- if > > its continued existence blocked people from focusing on more critical > > components, I would support removing it. But based on Rong Zhu's > > response I'm not sure that's the case. > > > > -- > > Thierry > > > > -- Thanks, Rong Zhu -------------- next part -------------- An HTML attachment was scrubbed... URL: From kkchn.in at gmail.com Thu Aug 19 00:58:59 2021 From: kkchn.in at gmail.com (KK CHN) Date: Thu, 19 Aug 2021 06:28:59 +0530 Subject: list admins: my mails are not yet publishing to the list members ? Message-ID: List admins/ Members, I am new to openstack, so I subscribed to the openstack-discuss mailing list in my best belief that this is the right place for a newbe to ask doubts and post errors which occurs during my learning stage with Openstack. If this is not the right place to seek help/ ask about doubts regarding openstack kindly direct me to the right place. What ever mails I am sending to openstack-discuss at lists.openstack.org not even publishing to the mailing lists. last two weeks I have sent 5 to 6 emails with various errors I got while importing VMs from other hypervisors to OpenStack. I posted to openstack-discuss at lists.openstack.org but none of them got response from list members. Iam afraid that my emails are going to Spam or am I not in the right place sending those emails? kindly correct me if I am wrong. Best regards, Kris -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Thu Aug 19 01:34:33 2021 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 19 Aug 2021 01:34:33 +0000 Subject: list admins: my mails are not yet publishing to the list members ? In-Reply-To: References: Message-ID: <20210819013432.h3pgvsw24vsj7j6c@yuggoth.org> On 2021-08-19 06:28:59 +0530 (+0530), KK CHN wrote: [...] > What ever mails I am sending to openstack-discuss at lists.openstack.org > not even publishing to the mailing lists. > > last two weeks I have sent 5 to 6 emails with various errors I got while > importing VMs from other hypervisors to OpenStack. I posted to > openstack-discuss at lists.openstack.org but none of them got response from > list members. > > Iam afraid that my emails are going to Spam or am I not in the right > place sending those emails? kindly correct me if I am wrong. I see several in July and August from you, which were delivered to all subscribers: http://lists.openstack.org/pipermail/openstack-discuss/2021-July/ http://lists.openstack.org/pipermail/openstack-discuss/2021-August/ Some also received replies. Not every question is necessarily going to elicit an answer, sometimes you may need to find answers to your own questions if nobody reading the lists knows them or has time to respond. As for spam filtering, we do no spam filtering of this mailing list, our list moderators carefully review and conditionally approve posts from non-subscribers, and I suppose some may occasionally be discarded by accident in that situation, but anything appearing in the archives linked above were sent along to all list subscribers. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From alawson at aqorn.com Thu Aug 19 02:19:50 2021 From: alawson at aqorn.com (Adam Peacock) Date: Wed, 18 Aug 2021 19:19:50 -0700 Subject: list admins: my mails are not yet publishing to the list members ? In-Reply-To: <20210819013432.h3pgvsw24vsj7j6c@yuggoth.org> References: <20210819013432.h3pgvsw24vsj7j6c@yuggoth.org> Message-ID: For me, all recent Openstack mailing list emails started getting sent to my spam folder by Google. I needed to set an explicit rule to route them correctly. YMMV //adam *Adam Peacock* Principal Architect Office: +1-916-794-5706 On Wed, Aug 18, 2021 at 6:36 PM Jeremy Stanley wrote: > On 2021-08-19 06:28:59 +0530 (+0530), KK CHN wrote: > [...] > > What ever mails I am sending to openstack-discuss at lists.openstack.org > > not even publishing to the mailing lists. > > > > last two weeks I have sent 5 to 6 emails with various errors I got while > > importing VMs from other hypervisors to OpenStack. I posted to > > openstack-discuss at lists.openstack.org but none of them got response > from > > list members. > > > > Iam afraid that my emails are going to Spam or am I not in the right > > place sending those emails? kindly correct me if I am wrong. > > I see several in July and August from you, which were delivered to > all subscribers: > > http://lists.openstack.org/pipermail/openstack-discuss/2021-July/ > http://lists.openstack.org/pipermail/openstack-discuss/2021-August/ > > Some also received replies. Not every question is necessarily going > to elicit an answer, sometimes you may need to find answers to your > own questions if nobody reading the lists knows them or has time to > respond. > > As for spam filtering, we do no spam filtering of this mailing list, > our list moderators carefully review and conditionally approve posts > from non-subscribers, and I suppose some may occasionally be > discarded by accident in that situation, but anything appearing in > the archives linked above were sent along to all list subscribers. > -- > Jeremy Stanley > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Thu Aug 19 03:56:57 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Wed, 18 Aug 2021 22:56:57 -0500 Subject: [all][tc] Technical Committee next weekly meeting on Aug 19th at 1500 UTC In-Reply-To: <17b50e41dc0.1151c354920925.431459325648627296@ghanshyammann.com> References: <17b50e41dc0.1151c354920925.431459325648627296@ghanshyammann.com> Message-ID: <17b5c8e0881.d76b718670926.8777873777287665705@ghanshyammann.com> Hello Everyone, Below is the agenda for Tomorrow's TC meeting schedule at 1500 UTC in #openstack-tc IRC channel. -https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting == Agenda for tomorrow's TC meeting == * Roll call * Follow up on past action items * Gate health check (dansmith/yoctozepto) ** http://paste.openstack.org/show/jD6kAP9tHk7PZr2nhv8h/ * Murano project health (gmann) ** http://lists.openstack.org/pipermail/openstack-discuss/2021-August/024120.html * New project application: 'Venus' ** http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019748.html ** https://review.opendev.org/c/openstack/governance/+/804824 * PTG Planning ** https://etherpad.opendev.org/p/tc-yoga-ptg * Moving weekly meetings to video/voice calls. ** Example: https://ircbot.wl.linuxfoundation.org/meetings/fdio-meeting/2021/fd_io_csit_project_meeting/fdio-meeting-fd_io_csit_project_meeting.2021-08-11-14.02.log.html * Board informal Brainstorming sessions about "community health and resource management" ** http://lists.openstack.org/pipermail/foundation/2021-August/002998.html * Open Reviews ** https://review.opendev.org/q/projects:openstack/governance+is:open -gmann ---- On Mon, 16 Aug 2021 16:35:32 -0500 Ghanshyam Mann wrote ---- > Hello Everyone, > > Technical Committee's next weekly meeting is scheduled for Aug 19th at 1500 UTC. > > If you would like to add topics for discussion, please add them to the below wiki page by > Wednesday, Aug 18th, at 2100 UTC. > > https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting > > -gmann > > From cjeanner at redhat.com Thu Aug 19 05:45:44 2021 From: cjeanner at redhat.com (=?UTF-8?Q?C=c3=a9dric_Jeanneret?=) Date: Thu, 19 Aug 2021 07:45:44 +0200 Subject: [tripleo] Help wanted to fix CI! Message-ID: Hello Community! We're hitting a blocking issue in the CI: due to some changes in tox, the tox-py36 job is failing due to some bad encoding settings, preventing some package installation. More details: https://bugs.launchpad.net/tripleo/+bug/1940313 We'd need help in a massive tox.ini edition throughout all the projects, at least for master and stable/wallaby branches. Here's a couple of examples: https://review.opendev.org/q/topic:%22encodingfix%22+(status:open%20OR%20status:merged) If anyone has a spare minute to propose such a patch, please do - and, please, be sure to use the same topic, "encodingfix", so that anyone will be able to follow the work! Thank you for your support! Have a great one! Cheers, C. -- Cédric Jeanneret (He/Him/His) Sr. Software Engineer - OpenStack Platform Deployment Framework TC Red Hat EMEA https://www.redhat.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From risson at cri.epita.fr Thu Aug 19 06:00:23 2021 From: risson at cri.epita.fr (Marc 'risson' Schmitt) Date: Thu, 19 Aug 2021 08:00:23 +0200 Subject: [tripleo] Help wanted to fix CI! In-Reply-To: References: Message-ID: <20210819080023.37f5074e@hedgehog.lap.rsn.lama-corp.space> Hi, On Thu, 19 Aug 2021 07:45:44 +0200 Cédric Jeanneret wrote: > We'd need help in a massive tox.ini edition throughout all the > projects, at least for master and stable/wallaby branches. > > Here's a couple of examples: > https://review.opendev.org/q/topic:%22encodingfix%22+(status:open%20OR%20status:merged) That seems easily scriptable, especially with a tool like vcspull[1] that would clone all the repositories for you, or am I missing something? [1] https://vcspull.git-pull.com/ Regards, -- Marc 'risson' Schmitt Lama Corp. From cjeanner at redhat.com Thu Aug 19 06:27:41 2021 From: cjeanner at redhat.com (=?UTF-8?Q?C=c3=a9dric_Jeanneret?=) Date: Thu, 19 Aug 2021 08:27:41 +0200 Subject: [tripleo] Help wanted to fix CI! In-Reply-To: <20210819080023.37f5074e@hedgehog.lap.rsn.lama-corp.space> References: <20210819080023.37f5074e@hedgehog.lap.rsn.lama-corp.space> Message-ID: <91057037-1453-10b4-2e9c-455b3125cfff@redhat.com> On 8/19/21 8:00 AM, Marc 'risson' Schmitt wrote: > Hi, > > On Thu, 19 Aug 2021 07:45:44 +0200 > Cédric Jeanneret wrote: >> We'd need help in a massive tox.ini edition throughout all the >> projects, at least for master and stable/wallaby branches. >> >> Here's a couple of examples: >> https://review.opendev.org/q/topic:%22encodingfix%22+(status:open%20OR%20status:merged) > > That seems easily scriptable, especially with a tool like vcspull[1] > that would clone all the repositories for you, or am I missing > something? not that easy. seems "only" a subset of project actually need the update: https://zuul.openstack.org/builds?job_name=openstack-tox-py36 and there's a patch against tox itself that should make our life easier in the future: https://github.com/tox-dev/tox/commit/bb609f5acfc580588925367b00533bf808e9d4c1 but it has to hit the CI, and we have to ensure we don't set anything to C as it's done in some projects Are we still Monday? -.- > > [1] https://vcspull.git-pull.com/ > > Regards, > -- Cédric Jeanneret (He/Him/His) Sr. Software Engineer - OpenStack Platform Deployment Framework TC Red Hat EMEA https://www.redhat.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From eblock at nde.ag Thu Aug 19 06:57:31 2021 From: eblock at nde.ag (Eugen Block) Date: Thu, 19 Aug 2021 06:57:31 +0000 Subject: Windows2012 VM image importing and Instance Launch Failure In-Reply-To: Message-ID: <20210819065731.Horde.FpXaNdZM5p4cp8hj6taQ3jm@webmail.nde.ag> Hi, to launch windows VMs in openstack you need virtio drivers [2], see [1] for an example. I haven't done that in quite some time, but I remember after following that guide I was able to launch a windows VM. Regards, Eugen [1] https://docs.openstack.org/image-guide/windows-image.html [2] https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/latest-virtio/virtio-win.iso Zitat von KK CHN : > Error : failed to perform requested operation on instance "WindowsVM "the > instance has error status. Please try again later [Error exceeded maximum > number of retries. Exhausted all hosts available for retrying build > failures for instance e3d5c095-7d26-4b1e-89d1-d1a6e20a45041 > > I am trying to import a WIndows2012 Single disk VM, to OpenStack Ussuri, > with glance and Qemu KVM. > > In bare machine KVM I am able to import and boot this Windows VM which > exported from rhevm hypervisor as vhdx image. > what I have done is > > 1. converted this windows image from vhdx to qcow2 > 2. root at MeghCtrol1:/home/cloud/CMOBB_APP#cirt-install --name WINDOWS > --ram=1048 --vcups=1 --cpu host --hvm --dick > path=BackUP2_CMAPP_disk_1_Windows_qcow2_imagefile,device=disk, > format=qcow2,bus=virtio --graphics vnc --boot uefi > > This uploaded the qcow2 image of WindowsVM to KVM hypervisor and its > working. > > But when I do importing to openstack unable to launch instance from the > image . > > These are the steps I performed.. > > 1. openstack image create "WindowsVM" --file CMAPP_disk_1.qcow2 > --disk-format qcow2 --container-format bare --public > > 4.openstack image set --property hw_firmware_type=uefi --property > os_secure_boot=required WindowsVM > > 5.openstack image set --property hw_firmware_type=uefi --property > hw_disk_bus=ide WindowsVM > > 6.openstack image show WindowsVM > > 7. root at dmzcloud:/home/cloud# openstack image show WindowsVM|grep > "properties" > | properties | hw_disk_bus='ide', hw_firmware_type='uefi', > os_hash_algo='sha512', > os_hash_value='753ee596980409e1e72d6d020c8219c56a6ada8b43f634fb575c594a245725a398e45982c0a1ad72b3fc3451cde62cceb9ff22be044863b31ecdd7893b049349', > os_hidden='False', os_secure_boot='required', > owner_specified.openstack.md5='', > owner_specified.openstack.object='images/WindowsVM', > owner_specified.openstack.sha256='' | > root at dmzcloud:/home/cloud# > > > Then I logged into horizon dashboard, from the images selected the > imported image and try to launch the instance. With a Flavour of 550 GB > disk, 4 vcpus and 8GB Ram .. > > The instance spawning ran for 30 minutes and throws the error which I > pasted first in the right top corner of horizon dashboard. > > How to solve this error and boot the Windows machine successfully .. > > > """ > Error : failed to perform requested operation on instance "WindowsVM "the > instance has error status. Please try again later [Error exceeded maximum > number of retries. Exhausted all hosts available for retrying build > failures for instance e3d5c095-7d26-4b1e-89d1-d1a6e20a45041 > > > """ > > Any help highly appreciated. > > Kris From radoslaw.piliszek at gmail.com Thu Aug 19 07:07:39 2021 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Thu, 19 Aug 2021 09:07:39 +0200 Subject: [nova][qa][infra] Adding no_timer_check to the kernel command line of our CI images In-Reply-To: <43403578-abcf-4313-affd-2a27c3f076c5@www.fastmail.com> References: <20210818210734.yruh6dygt22oc3nv@lyarwood-laptop.usersys.redhat.com> <43403578-abcf-4313-affd-2a27c3f076c5@www.fastmail.com> Message-ID: On Wed, Aug 18, 2021 at 11:45 PM Clark Boylan wrote: > > On Wed, Aug 18, 2021, at 2:07 PM, Lee Yarwood wrote: > > Hello all, > > > > For a while now we've been attempting to track down some infrequent but > > annoying Tempest test cleanup failures in CI when detaching volumes from > > an instance. Finally after rewriting part of the Tempest logic > > controlling the cleanup we've been able to confirm that this is being > > caused by a kernel panic within the instance at boot time as documented > > in the following bug: > > > > Failure to detach volume during Tempest test cleanup due to APIC related > > kernel panic within the guest OS > > https://bugs.launchpad.net/nova/+bug/1939108 > > > > This had been previously found in 2014 but at the time a fix was only > > proposed to Nova that would solve this when using a supplied kernel > > image: > > > > cirros 0.3.1 fails to boot > > https://bugs.launchpad.net/cirros/+bug/1312199 > > > > Use no_timer_check with soft-qemu > > https://review.opendev.org/c/openstack/nova/+/96090 > > > > Most (all?) of our CI currently running with [libvirt]virt_type=qemu > > uses the full Cirros 0.5.2 image. Does anyone have any suggestions on > > the best way of modifying the image(s) we use in CI to use the > > no_timer_check kernel command line arg? > > The best way is probably to update the image upstream and then update the cirros version in our tests? https://github.com/cirros-dev/cirros/blob/master/src/boot/grub/menu.lst#L10 or maybe with a kernel build flag? Smoser does note in 1312199 above that baking this into the image is an option though that was some time ago. > > If you want to modify the existing images instead it would probably be a good idea to have something like devstack do it rather than the CI system so that people running tools like devstack don't end up with different images outside of the CI system. +1 on both the approaches. With slight preference to just modify cirros upstream - it's not a production image so we can tweak it to suit kvm-less qemu constraints without worry. -yoctozepto From bkslash at poczta.onet.pl Thu Aug 19 07:23:55 2021 From: bkslash at poczta.onet.pl (Adam Tomas) Date: Thu, 19 Aug 2021 09:23:55 +0200 Subject: [masakari] Compute service with name XXXXX not found. In-Reply-To: References: <212EC217-274F-44B4-829B-D4C0D2F949FF@poczta.onet.pl> Message-ID: <2EA62C12-4C96-4A71-BA86-5687E2396CF6@poczta.onet.pl> Problem solved. It was caused by unset (by kolla-ansible role) variable os_region_name in masakari.conf. Problem was visible only if number of regions was > 1. Due to wrong value of os_region_name masakari tried to GET /os-services from wrong endpoint (another region endpoint). Solution: set [DEFAULT] os_region_name = PUT_YOUR_REGION_NAME_HERE in /etc/kolla/config/masakari.conf or edit masakari.conf.j2 template file in kolla-ansible role Radosław Piliszek - thank you for help with this issue. Best Regards Adam Tomas > Wiadomość napisana przez Radosław Piliszek w dniu 14.06.2021, o godz. 09:35: > > The line > >> 2021-06-11 14:45:49.829 959 INFO masakari.api.openstack.wsgi [req-e9a58522-858d-4025-9c43-f9fee744a0db nova - - - -] HTTP exception thrown: Compute service with name XXXXX could not be found. > > suggests that nova actively disagrees that this compute node actually exists. > As for the exercised behaviour: this is tested both in Masakari and > Kolla Ansible CIs, and it works. > I am afraid the answer to why this fails lies in the format of that > hidden XXXXX. > At the moment, I can't really think of how that could affect the outcome. > Is XXXXX 100% the same between the different logs? > If you can't somehow share how XXXXX looks, then you might want to > check the Nova API logs (again, debug=True might help a bit) and > compare between how the openstack client query works vs how the > Masakari query works. Perhaps, there is a glitch at some stage that > causes the XXXXX to get garbled. > You can also append --debug to the openstack commands to get the > client side of the conversation. > > > On Fri, Jun 11, 2021 at 5:10 PM bkslash wrote: >> >>> openstack compute service list --service nova-compute --host $HOSTNAME >>> did you try including the same hostname in this command? >> yes, and it returns the same as "openstack compute service list" but of course only for host XXXXX >> >>> If it works and Masakari does not, I would make sure you set up >>> Masakari to speak to the right Nova API. >> I'm using kolla-ansible, all masakari configuration was generated based on globals.yaml and inventory file while deployment, so it should work almost "out of the box". Does masakari speak to nova via RabbitMQ? How else can I check which port/IP masakari speaks to? In logs I can only see requests TO masakari API, not where masakari tries to check hypervisor... > > Masakari speaks to Nova via Nova API only. > If you used Kolla Ansible, then it's set up correctly unless you > manually overrode that. > By default, Masakari looks up the Nova endpoint from the Keystone catalogue. > > -yoctozepto From radoslaw.piliszek at gmail.com Thu Aug 19 07:41:53 2021 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Thu, 19 Aug 2021 09:41:53 +0200 Subject: [masakari] Compute service with name XXXXX not found. In-Reply-To: <2EA62C12-4C96-4A71-BA86-5687E2396CF6@poczta.onet.pl> References: <212EC217-274F-44B4-829B-D4C0D2F949FF@poczta.onet.pl> <2EA62C12-4C96-4A71-BA86-5687E2396CF6@poczta.onet.pl> Message-ID: On Thu, Aug 19, 2021 at 9:24 AM Adam Tomas wrote: > > Problem solved. > It was caused by unset (by kolla-ansible role) variable os_region_name in masakari.conf. Problem was visible only if number of regions was > 1. Due to wrong value of os_region_name masakari tried to GET /os-services from wrong endpoint (another region endpoint). > > Solution: > set [DEFAULT] os_region_name = PUT_YOUR_REGION_NAME_HERE in /etc/kolla/config/masakari.conf > > or edit masakari.conf.j2 template file in kolla-ansible role > > Radosław Piliszek - thank you for help with this issue. Thank you for the summary. I will only add that we are tracking this as Kolla Ansible bug in https://bugs.launchpad.net/kolla-ansible/+bug/1939291 Fixed soon. -yoctozepto > Best Regards > Adam Tomas > > > Wiadomość napisana przez Radosław Piliszek w dniu 14.06.2021, o godz. 09:35: > > > > The line > > > >> 2021-06-11 14:45:49.829 959 INFO masakari.api.openstack.wsgi [req-e9a58522-858d-4025-9c43-f9fee744a0db nova - - - -] HTTP exception thrown: Compute service with name XXXXX could not be found. > > > > suggests that nova actively disagrees that this compute node actually exists. > > As for the exercised behaviour: this is tested both in Masakari and > > Kolla Ansible CIs, and it works. > > I am afraid the answer to why this fails lies in the format of that > > hidden XXXXX. > > At the moment, I can't really think of how that could affect the outcome. > > Is XXXXX 100% the same between the different logs? > > If you can't somehow share how XXXXX looks, then you might want to > > check the Nova API logs (again, debug=True might help a bit) and > > compare between how the openstack client query works vs how the > > Masakari query works. Perhaps, there is a glitch at some stage that > > causes the XXXXX to get garbled. > > You can also append --debug to the openstack commands to get the > > client side of the conversation. > > > > > > On Fri, Jun 11, 2021 at 5:10 PM bkslash wrote: > >> > >>> openstack compute service list --service nova-compute --host $HOSTNAME > >>> did you try including the same hostname in this command? > >> yes, and it returns the same as "openstack compute service list" but of course only for host XXXXX > >> > >>> If it works and Masakari does not, I would make sure you set up > >>> Masakari to speak to the right Nova API. > >> I'm using kolla-ansible, all masakari configuration was generated based on globals.yaml and inventory file while deployment, so it should work almost "out of the box". Does masakari speak to nova via RabbitMQ? How else can I check which port/IP masakari speaks to? In logs I can only see requests TO masakari API, not where masakari tries to check hypervisor... > > > > Masakari speaks to Nova via Nova API only. > > If you used Kolla Ansible, then it's set up correctly unless you > > manually overrode that. > > By default, Masakari looks up the Nova endpoint from the Keystone catalogue. > > > > -yoctozepto > From katonalala at gmail.com Thu Aug 19 07:55:05 2021 From: katonalala at gmail.com (Lajos Katona) Date: Thu, 19 Aug 2021 09:55:05 +0200 Subject: [neutron][elections] PTL non candidacy for Y cycle In-Reply-To: References: <24443596.64OI9Hj3fW@p1> Message-ID: Hi Slawek, Thanks for the last years hard work! Lajos Miguel Lavalle ezt írta (időpont: 2021. aug. 18., Sze, 18:18): > Hi Slawek, > > As always, it has been a pleasure to work under your leadership. You are a > great PTL! Thanks for all your hard work > > Best regards > > Miguel > > On Wed, Aug 18, 2021 at 3:36 AM Lucas Alvares Gomes > wrote: > >> Thank you for your hard work Slawek! >> >> On Wed, Aug 18, 2021 at 8:15 AM Rodolfo Alonso Hernandez >> wrote: >> > >> > Thank you Slawek for your time and hard work. >> > >> > On Wed, Aug 18, 2021 at 12:35 AM Amy Marrich wrote: >> >> >> >> Thanks for all your hard work Slawek! >> >> >> >> Amy (spotz) >> >> >> >> > >> >> > On Aug 17, 2021, at 3:57 PM, Slawek Kaplonski >> wrote: >> >> > >> >> > Hi, >> >> > >> >> > It's been great 2 years for me when I had an honor to serve as >> Neutron PTL - >> >> > yeah, time flies :) >> >> > It has been pleasure to work with all of You on the Neutron project. >> We did a >> >> > lot of great things during that time. >> >> > But now, as I said in my last nomination [1], I'm not going to >> candidate for >> >> > being PTL in the Yoga cycle. I think it's good for the project to >> have new >> >> > leader every few cycles. That brings fresh ideas and new energy to >> the >> >> > project. >> >> > If You would be interested in that, to which I encourage anyone, >> and maybe >> >> > have any questions, feel free to reach out to me in any way (irc, >> email, >> >> > etc.). I will be more than happy to answer all Your questions. >> >> > >> >> > As for me, I'm not going anywhere. I'm still going to work on >> Neutron as I did >> >> > so far. >> >> > I will be of course very happy to help new PTL if that will be >> needed :) >> >> > >> >> > Once again thank You all for all Your help and supporting me in that >> role in >> >> > the last 2 years and good luck to our new PTL! >> >> > >> >> > [1] >> http://lists.openstack.org/pipermail/openstack-discuss/2021-March/ >> >> > 020901.html >> >> > >> >> > -- >> >> > Slawek Kaplonski >> >> > Principal Software Engineer >> >> > Red Hat >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From radoslaw.piliszek at gmail.com Thu Aug 19 08:23:47 2021 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Thu, 19 Aug 2021 10:23:47 +0200 Subject: [masakari][elections] Self-nomination for PTL in Yoga Message-ID: Dears, I have been making sure Masakari is alive and well during the last 2 cycles (Wallaby and Xena). I have also ensured Masakari's smooth release at the end of its Victoria cycle before that. I also contribute to the Kolla project which is able to deploy Masakari with its monitors and the required Pacemaker stack. I plan to continue my work around the project, focusing on improving the reliability of and community confidence in Masakari by ensuring we align with the rest of the OpenStack, run meetings, have complete, healthy and robust gating, triage bugs, handle the mailing list, and improve our docs and contribution transparency. -yoctozepto From ricolin at ricolky.com Thu Aug 19 08:49:37 2021 From: ricolin at ricolky.com (Rico Lin) Date: Thu, 19 Aug 2021 16:49:37 +0800 Subject: [all][tc] Technical Committee next weekly meeting on Aug 19th at 1500 UTC In-Reply-To: <17b5c8e0881.d76b718670926.8777873777287665705@ghanshyammann.com> References: <17b50e41dc0.1151c354920925.431459325648627296@ghanshyammann.com> <17b5c8e0881.d76b718670926.8777873777287665705@ghanshyammann.com> Message-ID: Hi Ghanshyam If we have free time left from this week's meeting, I would like to suggest a new topic for `pain point elimination` [1]. Would like to hear from TCs and everyone about if we can make it a goal or not. and how can we process it (goal or not). Or we can discuss it after meeting:) [1] https://etherpad.opendev.org/p/pain-point-elimination *Rico Lin* OIF Individual Board of directors, OpenStack TC, Multi-arch SIG chair, Heat PTL, Senior Software Engineer at EasyStack On Thu, Aug 19, 2021 at 12:16 PM Ghanshyam Mann wrote: > Hello Everyone, > > Below is the agenda for Tomorrow's TC meeting schedule at 1500 UTC in > #openstack-tc IRC channel. > > -https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting > > == Agenda for tomorrow's TC meeting == > > * Roll call > > * Follow up on past action items > > * Gate health check (dansmith/yoctozepto) > ** http://paste.openstack.org/show/jD6kAP9tHk7PZr2nhv8h/ > > * Murano project health (gmann) > ** > http://lists.openstack.org/pipermail/openstack-discuss/2021-August/024120.html > > * New project application: 'Venus' > ** > http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019748.html > ** https://review.opendev.org/c/openstack/governance/+/804824 > > * PTG Planning > ** https://etherpad.opendev.org/p/tc-yoga-ptg > > * Moving weekly meetings to video/voice calls. > ** Example: > https://ircbot.wl.linuxfoundation.org/meetings/fdio-meeting/2021/fd_io_csit_project_meeting/fdio-meeting-fd_io_csit_project_meeting.2021-08-11-14.02.log.html > > * Board informal Brainstorming sessions about "community health and > resource management" > ** http://lists.openstack.org/pipermail/foundation/2021-August/002998.html > > * Open Reviews > ** https://review.opendev.org/q/projects:openstack/governance+is:open > > -gmann > > > > ---- On Mon, 16 Aug 2021 16:35:32 -0500 Ghanshyam Mann < > gmann at ghanshyammann.com> wrote ---- > > Hello Everyone, > > > > Technical Committee's next weekly meeting is scheduled for Aug 19th at > 1500 UTC. > > > > If you would like to add topics for discussion, please add them to the > below wiki page by > > Wednesday, Aug 18th, at 2100 UTC. > > > > > https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting > > > > -gmann > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tkajinam at redhat.com Thu Aug 19 09:00:54 2021 From: tkajinam at redhat.com (Takashi Kajinami) Date: Thu, 19 Aug 2021 18:00:54 +0900 Subject: [puppet] Propose retiring puppet-monasca In-Reply-To: References: Message-ID: Because I have not received any feedback, I proposed a series of patches to retire puppet-monasca. Please put any feedback on these patches if you have any concerns. https://review.opendev.org/q/topic:%22retire-puppet-monasca%22+(status:open%20OR%20status:merged) On Thu, Aug 12, 2021 at 7:09 PM Takashi Kajinami wrote: > Hello, > > > tl;dr > If nobody is interested in fixing bug 1930553, then I'll propose > retiring puppet-monasca during this cycle. > > A few months ago, I found an issue[1] with puppet-monasca and it turned > out that > the module is not compatible with the recent puppet-python. > The module still relies on python::virtualenv which was removed in > puppet-python 6.0. > Currently the gate was unblocked by pinning puppet-python to an older > version > but we should remove that pin at some point. > [1] https://bugs.launchpad.net/puppet-monasca/+bug/1930553 > > However, fixing the problem requires relatively large refactoring, and I'm > afraid > we(at least, I) don't have enough resources for that. > The main challenge is that we have no functional tests in our CI jobs now > to validate the fix in puppet-monasca. > > I checked the commit history of this module but I don't see any meaningful > change > made for several years. If nobody is interested in maintaining the module > and fixing > the problem then I'd propose retiring the module. > > I'll wait for any feedback for a week, then decide whether I'll submit > actual patches > to retire the repo. > > Thank you, > Takashi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lyarwood at redhat.com Thu Aug 19 09:02:27 2021 From: lyarwood at redhat.com (Lee Yarwood) Date: Thu, 19 Aug 2021 10:02:27 +0100 Subject: [nova][qa][infra] Adding no_timer_check to the kernel command line of our CI images In-Reply-To: References: <20210818210734.yruh6dygt22oc3nv@lyarwood-laptop.usersys.redhat.com> <43403578-abcf-4313-affd-2a27c3f076c5@www.fastmail.com> Message-ID: <20210819090227.4jwb4hjllgzpv55g@lyarwood-laptop.usersys.redhat.com> On 19-08-21 09:07:39, Radosław Piliszek wrote: > On Wed, Aug 18, 2021 at 11:45 PM Clark Boylan wrote: > > > > On Wed, Aug 18, 2021, at 2:07 PM, Lee Yarwood wrote: > > > Hello all, > > > > > > For a while now we've been attempting to track down some infrequent but > > > annoying Tempest test cleanup failures in CI when detaching volumes from > > > an instance. Finally after rewriting part of the Tempest logic > > > controlling the cleanup we've been able to confirm that this is being > > > caused by a kernel panic within the instance at boot time as documented > > > in the following bug: > > > > > > Failure to detach volume during Tempest test cleanup due to APIC related > > > kernel panic within the guest OS > > > https://bugs.launchpad.net/nova/+bug/1939108 > > > > > > This had been previously found in 2014 but at the time a fix was only > > > proposed to Nova that would solve this when using a supplied kernel > > > image: > > > > > > cirros 0.3.1 fails to boot > > > https://bugs.launchpad.net/cirros/+bug/1312199 > > > > > > Use no_timer_check with soft-qemu > > > https://review.opendev.org/c/openstack/nova/+/96090 > > > > > > Most (all?) of our CI currently running with [libvirt]virt_type=qemu > > > uses the full Cirros 0.5.2 image. Does anyone have any suggestions on > > > the best way of modifying the image(s) we use in CI to use the > > > no_timer_check kernel command line arg? > > > > The best way is probably to update the image upstream and then > > update the cirros version in our tests? > > https://github.com/cirros-dev/cirros/blob/master/src/boot/grub/menu.lst#L10 > > or maybe with a kernel build flag? Smoser does note in 1312199 above > > that baking this into the image is an option though that was some > > time ago. > > > If you want to modify the existing images instead it would probably > > be a good idea to have something like devstack do it rather than the > > CI system so that people running tools like devstack don't end up > > with different images outside of the CI system. > > +1 on both the approaches. With slight preference to just modify > cirros upstream - it's not a production image so we can tweak it to > suit kvm-less qemu constraints without worry. Okay I can try both for the time being as I'm not entirely convinced that Cirros upstream will accept the change, removing the devstack change if they ever do. Thanks for the input both! -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From balazs.gibizer at est.tech Thu Aug 19 09:27:17 2021 From: balazs.gibizer at est.tech (Balazs Gibizer) Date: Thu, 19 Aug 2021 11:27:17 +0200 Subject: [nova][placement] Xena release Message-ID: Hi, We are getting close to the Xena release. So I created a tracking etherpad[1] with the schedule and TODOs. One thing that I want to highlight is that we will hit Feature Freeze on 3rd of September. As the timeframe between FF and RC1 is short I'm not plannig with FFEs. Patches that are approved before 3rd of Sept EOB can be rechecked or rebased if needed and then re-approved. If you have a patch that is really close but not approved before the deadline, and you think there are two cores that willing to review it before RC1, then please send a mail to the ML with [nova][FFE] subject prefix not later than 7th of Sept EOB. Cheers, gibi [1] https://etherpad.opendev.org/p/nova-xena-rc-potential From ignaziocassano at gmail.com Thu Aug 19 10:00:32 2021 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Thu, 19 Aug 2021 12:00:32 +0200 Subject: [kolla][wallaby]bug 1815989 Message-ID: Hello All, I just updated my kolla wallaby installation, and seems the bug 1815989 has not solved yet. I lost packages during live migration. Is there any prediction for the solution of this problem? Many thanks Ignazio -------------- next part -------------- An HTML attachment was scrubbed... URL: From kkchn.in at gmail.com Thu Aug 19 12:10:11 2021 From: kkchn.in at gmail.com (KK CHN) Date: Thu, 19 Aug 2021 17:40:11 +0530 Subject: Windows2012 VM image importing and Instance Launch Failure In-Reply-To: <20210819065731.Horde.FpXaNdZM5p4cp8hj6taQ3jm@webmail.nde.ag> References: <20210819065731.Horde.FpXaNdZM5p4cp8hj6taQ3jm@webmail.nde.ag> Message-ID: On Thu, Aug 19, 2021 at 12:30 PM Eugen Block wrote: > Hi, > > to launch windows VMs in openstack you need virtio drivers [2], see > [1] for an example. > Is this virtiio drivers applicable to launch new Windows virtual machines y from downloaded ISOs only ? Or as in my case I am exporting from hyperV . The file I got is vhdx file and I converted it to qcow2 format. Is the virtio drivers hack required for exported(from other hypervisors) Windows images also ? to import it to openstack. if so The step mentioned here https://docs.openstack.org/image-guide/windows-image.html 1. 1. $ qemu-img create -f qcow2 ws2012.qcow2 15G Is this step needed for other hypervisor exported WindowsVM image which converted by me already in qcow2 format ? what the relevance of 15G in my case of qcow2 format WIndows Single disk images which is 17G in qcow2 format ? 2. Step 2 In mycase what need to be edited here so that it successfully can be imported to OpenStack and running . # virt-install --connect qemu:///system \ --name ws2012 --ram 2048 --vcpus 2 \ --network network=default,model=virtio \ --disk path=ws2012.qcow2,format=qcow2,device=disk,bus=virtio \ --cdrom /path/to/en_windows_server_2012_x64_dvd.iso \ --disk path=/path/to/virtio-win-0.1-XX.iso,device=cdrom \ --vnc --os-type windows --os-variant win2k12 \ --os-distro windows --os-version 2012 That file size ( 17 GB in qcow2 format, in bare KVM when I imported successfully its booted and disk space around 500 GB ) . > I haven't done that in quite some time, but I remember after following > that guide I was able to launch a windows VM. > > Regards, > Eugen > > > [1] https://docs.openstack.org/image-guide/windows-image.html > [2] > > https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/latest-virtio/virtio-win.iso > > Zitat von KK CHN : > > > Error : failed to perform requested operation on instance "WindowsVM "the > > instance has error status. Please try again later [Error exceeded maximum > > number of retries. Exhausted all hosts available for retrying build > > failures for instance e3d5c095-7d26-4b1e-89d1-d1a6e20a45041 > > > > I am trying to import a WIndows2012 Single disk VM, to OpenStack Ussuri, > > with glance and Qemu KVM. > > > > In bare machine KVM I am able to import and boot this Windows VM which > > exported from rhevm hypervisor as vhdx image. > > what I have done is > > > > 1. converted this windows image from vhdx to qcow2 > > 2. root at MeghCtrol1:/home/cloud/CMOBB_APP#cirt-install --name WINDOWS > > --ram=1048 --vcups=1 --cpu host --hvm --dick > > path=BackUP2_CMAPP_disk_1_Windows_qcow2_imagefile,device=disk, > > format=qcow2,bus=virtio --graphics vnc --boot uefi > > > > This uploaded the qcow2 image of WindowsVM to KVM hypervisor and its > > working. > > > > But when I do importing to openstack unable to launch instance from > the > > image . > > > > These are the steps I performed.. > > > > 1. openstack image create "WindowsVM" --file CMAPP_disk_1.qcow2 > > --disk-format qcow2 --container-format bare --public > > > > 4.openstack image set --property hw_firmware_type=uefi --property > > os_secure_boot=required WindowsVM > > > > 5.openstack image set --property hw_firmware_type=uefi --property > > hw_disk_bus=ide WindowsVM > > > > 6.openstack image show WindowsVM > > > > 7. root at dmzcloud:/home/cloud# openstack image show WindowsVM|grep > > "properties" > > | properties | hw_disk_bus='ide', hw_firmware_type='uefi', > > os_hash_algo='sha512', > > > os_hash_value='753ee596980409e1e72d6d020c8219c56a6ada8b43f634fb575c594a245725a398e45982c0a1ad72b3fc3451cde62cceb9ff22be044863b31ecdd7893b049349', > > os_hidden='False', os_secure_boot='required', > > owner_specified.openstack.md5='', > > owner_specified.openstack.object='images/WindowsVM', > > owner_specified.openstack.sha256='' | > > root at dmzcloud:/home/cloud# > > > > > > Then I logged into horizon dashboard, from the images selected the > > imported image and try to launch the instance. With a Flavour of 550 GB > > disk, 4 vcpus and 8GB Ram .. > > > > The instance spawning ran for 30 minutes and throws the error which I > > pasted first in the right top corner of horizon dashboard. > > > > How to solve this error and boot the Windows machine successfully .. > > > > > > """ > > Error : failed to perform requested operation on instance "WindowsVM "the > > instance has error status. Please try again later [Error exceeded maximum > > number of retries. Exhausted all hosts available for retrying build > > failures for instance e3d5c095-7d26-4b1e-89d1-d1a6e20a45041 > > > > > > """ > > > > Any help highly appreciated. > > > > Kris > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rosmaita.fossdev at gmail.com Thu Aug 19 12:58:16 2021 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Thu, 19 Aug 2021 08:58:16 -0400 Subject: [all][tc] Technical Committee next weekly meeting on Aug 19th at 1500 UTC In-Reply-To: <17b5c8e0881.d76b718670926.8777873777287665705@ghanshyammann.com> References: <17b50e41dc0.1151c354920925.431459325648627296@ghanshyammann.com> <17b5c8e0881.d76b718670926.8777873777287665705@ghanshyammann.com> Message-ID: <6d9e59b2-404f-4791-9f7c-0e5c07868c5d@gmail.com> On 8/18/21 11:56 PM, Ghanshyam Mann wrote: > Hello Everyone, > > Below is the agenda for Tomorrow's TC meeting schedule at 1500 UTC in #openstack-tc IRC channel. > [snip] > > * Moving weekly meetings to video/voice calls. > ** Example: https://ircbot.wl.linuxfoundation.org/meetings/fdio-meeting/2021/fd_io_csit_project_meeting/fdio-meeting-fd_io_csit_project_meeting.2021-08-11-14.02.log.html Here's some feedback for the proposal. A year ago we started holding the last Cinder weekly meeting of each month in video + irc (the irc component for people with bad connections or who are more comfortable with written than spoken English) [0]. The meetings are recorded (you can find links on the meeting agenda [1] if you're interested). I haven't watched any of them, well, because I was there. The point I want to make here is to compare the meeting logs from a video meeting [2] and the irc-only meeting the week before [3]. The video meeting logs are basically just a list of pointers into where the discussion happens, which is helpful, but you have to watch the recording. With the irc-only meeting logs, you have all the discussion in one place (though you get the sometimes strange interleaving of topics). The video meetings are good from a team cohesion standpoint. People enjoy the interaction and getting to see each other once a month. But the logs aren't very helpful when I want to go back and check something real quickly to see if I remembered a discussion correctly. The other nice thing about the irc-only logs is that if someone misses a meeting, it takes way less than an hour to find out what happened. I don't know about other people, but the way I keep up on the TC is reading Ghanshyam's excellent 5 minute summaries on the mailing list and looking at the meeting log if there's a topic where I want to get some more detail about the discussion. So, my suggestion is that if you want to do a video meeting, do it once a month, and that way you get the benefits of some video interaction, but the rest of us interested parties (which is basically the entire OpenStack community) aren't required to watch a video to find out how the discussion went. (Notice that I didn't say anything about voice calls. Those absolutely suck. Just my opinion.) cheers, brian [0] http://lists.openstack.org/pipermail/openstack-discuss/2020-July/015879.html [1] https://etherpad.opendev.org/p/cinder-xena-meetings [2] https://meetings.opendev.org/meetings/cinder/2021/cinder.2021-06-30-14.00.log.html [3] https://meetings.opendev.org/meetings/cinder/2021/cinder.2021-06-23-14.00.log.html From lyarwood at redhat.com Thu Aug 19 13:37:15 2021 From: lyarwood at redhat.com (Lee Yarwood) Date: Thu, 19 Aug 2021 14:37:15 +0100 Subject: [nova][qa][infra] Adding no_timer_check to the kernel command line of our CI images In-Reply-To: <20210819090227.4jwb4hjllgzpv55g@lyarwood-laptop.usersys.redhat.com> References: <20210818210734.yruh6dygt22oc3nv@lyarwood-laptop.usersys.redhat.com> <43403578-abcf-4313-affd-2a27c3f076c5@www.fastmail.com> <20210819090227.4jwb4hjllgzpv55g@lyarwood-laptop.usersys.redhat.com> Message-ID: <20210819133715.e6nvbpwl2leon6op@lyarwood-laptop.usersys.redhat.com> On 19-08-21 10:02:27, Lee Yarwood wrote: > On 19-08-21 09:07:39, Radosław Piliszek wrote: > > On Wed, Aug 18, 2021 at 11:45 PM Clark Boylan wrote: > > > > > > On Wed, Aug 18, 2021, at 2:07 PM, Lee Yarwood wrote: > > > > Hello all, > > > > > > > > For a while now we've been attempting to track down some infrequent but > > > > annoying Tempest test cleanup failures in CI when detaching volumes from > > > > an instance. Finally after rewriting part of the Tempest logic > > > > controlling the cleanup we've been able to confirm that this is being > > > > caused by a kernel panic within the instance at boot time as documented > > > > in the following bug: > > > > > > > > Failure to detach volume during Tempest test cleanup due to APIC related > > > > kernel panic within the guest OS > > > > https://bugs.launchpad.net/nova/+bug/1939108 > > > > > > > > This had been previously found in 2014 but at the time a fix was only > > > > proposed to Nova that would solve this when using a supplied kernel > > > > image: > > > > > > > > cirros 0.3.1 fails to boot > > > > https://bugs.launchpad.net/cirros/+bug/1312199 > > > > > > > > Use no_timer_check with soft-qemu > > > > https://review.opendev.org/c/openstack/nova/+/96090 > > > > > > > > Most (all?) of our CI currently running with [libvirt]virt_type=qemu > > > > uses the full Cirros 0.5.2 image. Does anyone have any suggestions on > > > > the best way of modifying the image(s) we use in CI to use the > > > > no_timer_check kernel command line arg? > > > > > > The best way is probably to update the image upstream and then > > > update the cirros version in our tests? > > > https://github.com/cirros-dev/cirros/blob/master/src/boot/grub/menu.lst#L10 > > > or maybe with a kernel build flag? Smoser does note in 1312199 above > > > that baking this into the image is an option though that was some > > > time ago. > > > > > If you want to modify the existing images instead it would probably > > > be a good idea to have something like devstack do it rather than the > > > CI system so that people running tools like devstack don't end up > > > with different images outside of the CI system. > > > > +1 on both the approaches. With slight preference to just modify > > cirros upstream - it's not a production image so we can tweak it to > > suit kvm-less qemu constraints without worry. > > Okay I can try both for the time being as I'm not entirely convinced > that Cirros upstream will accept the change, removing the devstack > change if they ever do. After talking to sean-k-mooney in #opentack-nova we have ended up reviving an old workaround option Sean had to remove the apic entirely from our test instances: https://review.opendev.org/q/topic:workaround-disable-apic I've also pushed a PR upstream in Cirros but as I said before I'm pretty doubtful this will ever land: https://github.com/cirros-dev/cirros/issues/69 https://github.com/cirros-dev/cirros/pull/70 Cheers, -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From gmann at ghanshyammann.com Thu Aug 19 14:47:27 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Thu, 19 Aug 2021 09:47:27 -0500 Subject: [all][tc] Technical Committee next weekly meeting on Aug 19th at 1500 UTC In-Reply-To: References: <17b50e41dc0.1151c354920925.431459325648627296@ghanshyammann.com> <17b5c8e0881.d76b718670926.8777873777287665705@ghanshyammann.com> Message-ID: <17b5ee1945b.12408e1b3112384.6152951738735242020@ghanshyammann.com> Sure Rico, We can cover that if we have time in the meeting or after the meeting. -gmann ---- On Thu, 19 Aug 2021 03:49:37 -0500 Rico Lin wrote ---- > Hi Ghanshyam > If we have free time left from this week's meeting, I would like to suggest a new topic for `pain point elimination` [1].Would like to hear from TCs and everyone about if we can make it a goal or not. and how can we process it (goal or not). > Or we can discuss it after meeting:)[1] https://etherpad.opendev.org/p/pain-point-elimination > > Rico LinOIF Individual Board of directors, OpenStack TC, Multi-arch SIG chair, Heat PTL, Senior Software Engineer at EasyStack > > > On Thu, Aug 19, 2021 at 12:16 PM Ghanshyam Mann wrote: > Hello Everyone, > > Below is the agenda for Tomorrow's TC meeting schedule at 1500 UTC in #openstack-tc IRC channel. > > -https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting > > == Agenda for tomorrow's TC meeting == > > * Roll call > > * Follow up on past action items > > * Gate health check (dansmith/yoctozepto) > ** http://paste.openstack.org/show/jD6kAP9tHk7PZr2nhv8h/ > > * Murano project health (gmann) > ** http://lists.openstack.org/pipermail/openstack-discuss/2021-August/024120.html > > * New project application: 'Venus' > ** http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019748.html > ** https://review.opendev.org/c/openstack/governance/+/804824 > > * PTG Planning > ** https://etherpad.opendev.org/p/tc-yoga-ptg > > * Moving weekly meetings to video/voice calls. > ** Example: https://ircbot.wl.linuxfoundation.org/meetings/fdio-meeting/2021/fd_io_csit_project_meeting/fdio-meeting-fd_io_csit_project_meeting.2021-08-11-14.02.log.html > > * Board informal Brainstorming sessions about "community health and resource management" > ** http://lists.openstack.org/pipermail/foundation/2021-August/002998.html > > * Open Reviews > ** https://review.opendev.org/q/projects:openstack/governance+is:open > > -gmann > > > > ---- On Mon, 16 Aug 2021 16:35:32 -0500 Ghanshyam Mann wrote ---- > > Hello Everyone, > > > > Technical Committee's next weekly meeting is scheduled for Aug 19th at 1500 UTC. > > > > If you would like to add topics for discussion, please add them to the below wiki page by > > Wednesday, Aug 18th, at 2100 UTC. > > > > https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting > > > > -gmann > > > > > > From gmann at ghanshyammann.com Thu Aug 19 16:15:53 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Thu, 19 Aug 2021 11:15:53 -0500 Subject: [murano][tc] Project Retirement In-Reply-To: References: <3117ebb2-ea5f-9905-2447-1773c4c23eab@openstack.org> Message-ID: <17b5f328e56.fcc93986117237.8164269090667224630@ghanshyammann.com> ---- On Wed, 18 Aug 2021 19:07:33 -0500 Rong Zhu wrote ---- > I am agree with all of you, But most of the projects are lacking of contributors. Keep or remove Murano can not make things better. I know some people are using Murano internal, they submited a bugfix sometimes. Remove Murano can not make those people focus on other projects, But will let those people out and a PTL out. Thanks, Rong Zhu for all your hard work and to continue to maintain it. In today's TC meeting, we discussed it and agreed not to retire the Murano project[1]. [1] https://meetings.opendev.org/meetings/tc/2021/tc.2021-08-19-15.00.log.html#l-98 -gmann > Thanks,Rong Zhu > > Radosław Piliszek 于2021年8月19日 周四00:36写道： > On Wed, Aug 18, 2021 at 3:08 PM Thierry Carrez wrote: > > > > Rong Zhu wrote: > > > Sorry for my late response, I am a little bit busy for internal works > > > recently. > > > > > > If TC has decided to retire murano, I have no objection. But If TC think > > > someone can keep maintain it and not retire, I am glad to keeping > > > maintain Murano project. Please reconsider this. > > > > For the record, I don't think there is an urgent need to retire Murano > > as long as it is maintained, fills community goals, hits release > > requirements, and is functional. > > I disagree. I think we are giving it a false sense of usability. > It likely can do "something" but there does not seem to exist enough > workforce to triage and fix bugs [1] for quite some time. > And some [2] look like users are having a hard time using it. > This was also observed by me with my Kolla hat on - folks reported to > us that they can't get Murano stuff running and we could only spread > our hands. (-: > It also does not seem to have had any new features since at least Stein. [3] > > We can also take a look at stackalytics [4]. > Most person-day effort was eaten up by community-wide changes. > > My POV is that OpenStack is still a kind of quality badge that applies > to projects under its umbrella. > Seemingly, it's also the perspective of folks outside of the close > community (ask anyone doing consulting ;-) ). > And thus we should retire projects which did not stand the test of time. > > I am thankful for Rong Zhu's efforts to keep the project alive but it > seems the world has moved on to solutions based on different > technologies, as mentioned by you (Thierry) and Mohammed. > And we, as OpenStack, should accept that and focus on better > integration with those. > > [1] https://bugs.launchpad.net/murano/+bugs?orderby=-id&start=0 > [2] https://bugs.launchpad.net/murano/+bug/1817538 > [3] https://docs.openstack.org/releasenotes/murano/index.html > [4] https://www.stackalytics.io/?module=murano-group&metric=person-day&release=xena > > -yoctozepto > > > > Like mnaser said, it is a bit off in the modern landscape of application > > deployment technology, so I don't think it's a priority anymore -- if > > its continued existence blocked people from focusing on more critical > > components, I would support removing it. But based on Rong Zhu's > > response I'm not sure that's the case. > > > > -- > > Thierry > > > > -- > Thanks, > Rong Zhu From yasufum.o at gmail.com Thu Aug 19 17:03:20 2021 From: yasufum.o at gmail.com (Yasufumi Ogawa) Date: Fri, 20 Aug 2021 02:03:20 +0900 Subject: [tacker][elections] PTL candidacy for Yoga Message-ID: Hi, I'd like to propose my candidacy for Tacker PTL in Yoga cycle. I've contributed to Tacker to introduce ETSI-NVF standard compliant features from Victoria cycle as a PTL. It's still midway of roadmap of our development plan and I'll continue to lead the development in the next cycle. - Implement the latest container technology with ETSI NFV standard. - Support multi API versions which is a mechanism for operators enable to deploy mixed environment of multi-vendor products in which some products provide a stable version APIs while other products adopt move advanced ones. - Proceed to design and implement test framework under development in ETSI NFV TST to improve the quality of the product, not only unit tests and functional tests, but also introduce more sophisticated scheme such as robot framework. - And also new requirements will be proposed in the next PTG! Thanks, Yasufumi From DHilsbos at performair.com Thu Aug 19 17:18:17 2021 From: DHilsbos at performair.com (DHilsbos at performair.com) Date: Thu, 19 Aug 2021 17:18:17 +0000 Subject: Windows2012 VM image importing and Instance Launch Failure In-Reply-To: References: <20210819065731.Horde.FpXaNdZM5p4cp8hj6taQ3jm@webmail.nde.ag> Message-ID: <0670B960225633449A24709C291A525251C7FCE6@COM03.performair.local> Kris; I also use Windows extensively for OpenStack instances. I have never been able to boot a Windows image with --property hw_firmware_type=uefi. It hasn't been important enough, to this point, to troubleshoot. Windows Server 2012 boots fine without UEFI though. We use Victoria on CentOS 8, and Ubuntu 20.10. It would be a good idea to install virtio drivers into the image, and use some other parameter for hw_disk_bus. I believe ide makes qemu software emulate and IDE interface. What you choose here will partly depend on where / how you store your images and volumes. Thank you, Dominic L. Hilsbos, MBA Vice President – Information Technology Perform Air International Inc. DHilsbos at PerformAir.com www.PerformAir.com From: KK CHN [mailto:kkchn.in at gmail.com] Sent: Thursday, August 19, 2021 5:10 AM To: openstack-discuss at lists.openstack.org Subject: Re: Windows2012 VM image importing and Instance Launch Failure On Thu, Aug 19, 2021 at 12:30 PM Eugen Block wrote: Hi, to launch windows VMs in openstack you need virtio drivers [2], see  [1] for an example. Is this  virtiio drivers applicable to launch   new  Windows  virtual machines y from downloaded ISOs only ?   Or  as in my case   I am exporting  from hyperV . The file I got   is vhdx file and I converted it to qcow2 format.  Is the virtio drivers  hack required for exported(from other hypervisors) Windows images also ? to import it to openstack. if so     The step mentioned  here        https://docs.openstack.org/image-guide/windows-image.html 1. a. $ qemu-img create -f qcow2 ws2012.qcow2 15G Is this step needed for  other hypervisor exported  WindowsVM image which converted by me already in qcow2 format ?   what the relevance of 15G in my case of  qcow2 format  WIndows Single disk images  which is 17G in qcow2 format ?   2.   Step 2  In  mycase  what need to be  edited  here so that it successfully can be imported to OpenStack and running .  # virt-install --connect qemu:///system \ --name ws2012 --ram 2048 --vcpus 2 \ --network network=default,model=virtio \ --disk path=ws2012.qcow2,format=qcow2,device=disk,bus=virtio \ --cdrom /path/to/en_windows_server_2012_x64_dvd.iso \ --disk path=/path/to/virtio-win-0.1-XX.iso,device=cdrom \ --vnc --os-type windows --os-variant win2k12 \ --os-distro windows --os-version 2012    That file size ( 17 GB  in qcow2 format, in bare KVM when I imported successfully  its booted and disk space  around 500 GB ) .     I haven't done that in quite some time, but I remember after following  that guide I was able to launch a windows VM. Regards, Eugen [1] https://docs.openstack.org/image-guide/windows-image.html [2]  https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/latest-virtio/virtio-win.iso Zitat von KK CHN : > Error : failed to perform requested operation on instance "WindowsVM "the > instance has error status. Please try again later [Error exceeded maximum > number of retries. Exhausted all hosts available for retrying build > failures for instance e3d5c095-7d26-4b1e-89d1-d1a6e20a45041 > > I am trying to import a WIndows2012 Single disk VM, to OpenStack Ussuri, > with glance and Qemu KVM. > > In bare machine KVM I am able to import and boot this Windows VM which > exported from rhevm hypervisor as  vhdx image. > what I have done is > > 1. converted this windows  image from vhdx to qcow2 > 2.  root at MeghCtrol1:/home/cloud/CMOBB_APP#cirt-install --name WINDOWS > --ram=1048 --vcups=1 --cpu host --hvm --dick > path=BackUP2_CMAPP_disk_1_Windows_qcow2_imagefile,device=disk, > format=qcow2,bus=virtio --graphics vnc --boot uefi > > This uploaded the qcow2 image of WindowsVM to  KVM  hypervisor and its > working. > > But when I do importing to openstack   unable to launch  instance from the > image . > > These are the steps I performed.. > > 1. openstack image create "WindowsVM" --file CMAPP_disk_1.qcow2 > --disk-format qcow2 --container-format bare --public > > 4.openstack image set --property hw_firmware_type=uefi --property > os_secure_boot=required WindowsVM > > 5.openstack image set --property hw_firmware_type=uefi --property > hw_disk_bus=ide WindowsVM > > 6.openstack image show WindowsVM > > 7. root at dmzcloud:/home/cloud# openstack image show WindowsVM|grep > "properties" > | properties       | hw_disk_bus='ide', hw_firmware_type='uefi', > os_hash_algo='sha512', > os_hash_value='753ee596980409e1e72d6d020c8219c56a6ada8b43f634fb575c594a245725a398e45982c0a1ad72b3fc3451cde62cceb9ff22be044863b31ecdd7893b049349', > os_hidden='False', os_secure_boot='required', > owner_specified.openstack.md5='', > owner_specified.openstack.object='images/WindowsVM', > owner_specified.openstack.sha256='' | > root at dmzcloud:/home/cloud# > > > Then  I logged into horizon dashboard,  from the images  selected the > imported image and try to launch the instance.  With  a Flavour of 550 GB > disk, 4 vcpus and 8GB Ram .. > > The instance spawning ran for 30 minutes and throws the error which I > pasted first in the right top corner of horizon dashboard. > > How to solve this error and boot the Windows machine successfully .. > > > """ > Error : failed to perform requested operation on instance "WindowsVM "the > instance has error status. Please try again later [Error exceeded maximum > number of retries. Exhausted all hosts available for retrying build > failures for instance e3d5c095-7d26-4b1e-89d1-d1a6e20a45041 > > > """ > > Any help highly appreciated. > > Kris From gmann at ghanshyammann.com Thu Aug 19 17:23:05 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Thu, 19 Aug 2021 12:23:05 -0500 Subject: [all][tc] Technical Committee next weekly meeting on Aug 19th at 1500 UTC In-Reply-To: <6d9e59b2-404f-4791-9f7c-0e5c07868c5d@gmail.com> References: <17b50e41dc0.1151c354920925.431459325648627296@ghanshyammann.com> <17b5c8e0881.d76b718670926.8777873777287665705@ghanshyammann.com> <6d9e59b2-404f-4791-9f7c-0e5c07868c5d@gmail.com> Message-ID: <17b5f7012d3.12b6819d1119608.3700346564411530785@ghanshyammann.com> ---- On Thu, 19 Aug 2021 07:58:16 -0500 Brian Rosmaita wrote ---- > On 8/18/21 11:56 PM, Ghanshyam Mann wrote: > > Hello Everyone, > > > > Below is the agenda for Tomorrow's TC meeting schedule at 1500 UTC in #openstack-tc IRC channel. > > > [snip] > > > > * Moving weekly meetings to video/voice calls. > > ** Example: https://ircbot.wl.linuxfoundation.org/meetings/fdio-meeting/2021/fd_io_csit_project_meeting/fdio-meeting-fd_io_csit_project_meeting.2021-08-11-14.02.log.html > > Here's some feedback for the proposal. A year ago we started holding > the last Cinder weekly meeting of each month in video + irc (the irc > component for people with bad connections or who are more comfortable > with written than spoken English) [0]. > > The meetings are recorded (you can find links on the meeting agenda [1] > if you're interested). I haven't watched any of them, well, because I > was there. > > The point I want to make here is to compare the meeting logs from a > video meeting [2] and the irc-only meeting the week before [3]. > > The video meeting logs are basically just a list of pointers into where > the discussion happens, which is helpful, but you have to watch the > recording. With the irc-only meeting logs, you have all the discussion > in one place (though you get the sometimes strange interleaving of topics). > > The video meetings are good from a team cohesion standpoint. People > enjoy the interaction and getting to see each other once a month. But > the logs aren't very helpful when I want to go back and check something > real quickly to see if I remembered a discussion correctly. The other > nice thing about the irc-only logs is that if someone misses a meeting, > it takes way less than an hour to find out what happened. > > I don't know about other people, but the way I keep up on the TC is > reading Ghanshyam's excellent 5 minute summaries on the mailing list and > looking at the meeting log if there's a topic where I want to get some > more detail about the discussion. Thanks again for the feedback, glad to hear that the summary email is helpful. > > So, my suggestion is that if you want to do a video meeting, do it once > a month, and that way you get the benefits of some video interaction, > but the rest of us interested parties (which is basically the entire > OpenStack community) aren't required to watch a video to find out how > the discussion went. +1, Thanks for sharing the experience which is helpful. In today TC meeting, we decided to try monthly video call and based on how it goes then we will formalize/ iterate it in PTG. -gmann > > (Notice that I didn't say anything about voice calls. Those absolutely > suck. Just my opinion.) > > > cheers, > brian > > [0] > http://lists.openstack.org/pipermail/openstack-discuss/2020-July/015879.html > [1] https://etherpad.opendev.org/p/cinder-xena-meetings > [2] > https://meetings.opendev.org/meetings/cinder/2021/cinder.2021-06-30-14.00.log.html > [3] > https://meetings.opendev.org/meetings/cinder/2021/cinder.2021-06-23-14.00.log.html > > From hrishikesh.karanjikar at gmail.com Thu Aug 19 17:23:51 2021 From: hrishikesh.karanjikar at gmail.com (Hrishikesh Karanjikar) Date: Thu, 19 Aug 2021 22:53:51 +0530 Subject: Configuration of OvS running on SmartNIC using OpenStack Message-ID: Dear All, I am looking forward to configuration/management of OvS running on SmartNIC using Openstack. Any pointers that can help are appreciated. -- Thanks and Regards, Hrishikesh Karanjikar -------------- next part -------------- An HTML attachment was scrubbed... URL: From frode.nordahl at canonical.com Thu Aug 19 18:07:38 2021 From: frode.nordahl at canonical.com (Frode Nordahl) Date: Thu, 19 Aug 2021 20:07:38 +0200 Subject: Configuration of OvS running on SmartNIC using OpenStack In-Reply-To: References: Message-ID: Hello Hrishikesh, On Thu, Aug 19, 2021 at 7:28 PM Hrishikesh Karanjikar wrote: > > Dear All, > > I am looking forward to configuration/management of OvS running on SmartNIC using Openstack. > Any pointers that can help are appreciated. Thank you for your interest in SmartNICs with control plane CPUs! There are efforts on the way to support SmartNICs with control plane CPUs with OpenStack. We are currently actively developing support in OpenStack's dependencies, namely libvirt [0], Open vSwitch [1] and OVN [2] and have also put forward specifications for implementation in Nova [3] and Neutron [4]. 0: https://www.spinics.net/linux/fedora/libvir/msg219545.html 1: http://patchwork.ozlabs.org/project/openvswitch/patch/20210506102840.285473-1-frode.nordahl at canonical.com/ 2: http://patchwork.ozlabs.org/project/ovn/cover/20210819110857.2229769-1-frode.nordahl at canonical.com/ 3: https://review.opendev.org/c/openstack/nova-specs/+/787458 4: https://review.opendev.org/c/openstack/neutron-specs/+/788821 -- Frode Nordahl > > -- > > Thanks and Regards, > Hrishikesh Karanjikar From allison at openstack.org Thu Aug 19 19:25:36 2021 From: allison at openstack.org (Allison Price) Date: Thu, 19 Aug 2021 14:25:36 -0500 Subject: It's time to submit your OpenStack User Survey In-Reply-To: <8F385236-8B73-4AA5-B632-EDBD30FCBD2C@openstack.org> References: <8F385236-8B73-4AA5-B632-EDBD30FCBD2C@openstack.org> Message-ID: <59F1197C-DE78-4B1D-A99E-B151B3DBE4DF@openstack.org> Hi everyone, Tomorrow is the last day to complete the user survey to be included in this round of analysis. Please tell all of your OpenStack teammates, customers and friends. https://www.openstack.org/user-survey/survey-2021 Thanks! Allison > On Jun 23, 2021, at 3:11 PM, Allison Price wrote: > > Hi everyone, > > Here’s my annual email requesting you complete the OpenStack User Survey [1] and share with your local communities / community friends who are operating OpenStack. Anonymous reposes and aggregated data from the User Survey are shared with the OPenStack PTLs and overall community to help understand operator software requirements. If you have never taken it before, please do! We welcome your feedback and I am happy to answer any questions you may have. If you are one of the many who have, all of your previous information should be stored, so you will just need to provide updates where relevant and re-save. > > Thank you all! > > Cheers, > Allison > > [1] https://www.openstack.org/user-survey/survey-2021 > > > Allison Price > Director of Marketing & Community > OpenInfra Foundation > e: allison at openstack.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierre at stackhpc.com Thu Aug 19 21:13:16 2021 From: pierre at stackhpc.com (Pierre Riteau) Date: Thu, 19 Aug 2021 23:13:16 +0200 Subject: [election][blazar] PTL candidacy for Yoga Message-ID: Hi, I would like to self-nominate for the role of PTL of Blazar for the Yoga release cycle. I have been PTL since the Stein cycle and I am willing to continue in this role. During the Xena cycle, an existing contributor became a core reviewer and we also welcomed changes from new contributors. I will keep working with the community to maintain the Blazar software for their use cases and encourage the addition of new functionalities, such as providing a calendar view in the dashboard or supporting preemptible instances. Thank you for your support, Pierre Riteau (priteau) From pierre at stackhpc.com Thu Aug 19 21:15:32 2021 From: pierre at stackhpc.com (Pierre Riteau) Date: Thu, 19 Aug 2021 23:15:32 +0200 Subject: [blazar] PTL on holiday next week Message-ID: Hello, I will be on holiday next week and will be back on August 30. The bi-weekly IRC meeting of August 26 is cancelled. Cheers, Pierre Riteau (priteau) From mnaser at vexxhost.com Fri Aug 20 02:40:56 2021 From: mnaser at vexxhost.com (Mohammed Naser) Date: Thu, 19 Aug 2021 22:40:56 -0400 Subject: Windows2012 VM image importing and Instance Launch Failure In-Reply-To: References: Message-ID: I suggest that you have a look at the compute node logs when it fails to spawn. I suspect the problem is not Your images but something inside openstack If I was to guess it’s probably missing UEFI firmware packages :) On Wed, Aug 18, 2021 at 9:17 AM KK CHN wrote: > Error : failed to perform requested operation on instance "WindowsVM "the > instance has error status. Please try again later [Error exceeded maximum > number of retries. Exhausted all hosts available for retrying build > failures for instance e3d5c095-7d26-4b1e-89d1-d1a6e20a45041 > > I am trying to import a WIndows2012 Single disk VM, to OpenStack Ussuri, > with glance and Qemu KVM. > > In bare machine KVM I am able to import and boot this Windows VM which > exported from rhevm hypervisor as vhdx image. > what I have done is > > 1. converted this windows image from vhdx to qcow2 > 2. root at MeghCtrol1:/home/cloud/CMOBB_APP#cirt-install --name WINDOWS > --ram=1048 --vcups=1 --cpu host --hvm --dick > path=BackUP2_CMAPP_disk_1_Windows_qcow2_imagefile,device=disk, > format=qcow2,bus=virtio --graphics vnc --boot uefi > > This uploaded the qcow2 image of WindowsVM to KVM hypervisor and its > working. > > But when I do importing to openstack unable to launch instance from the > image . > > These are the steps I performed.. > > 1. openstack image create "WindowsVM" --file CMAPP_disk_1.qcow2 > --disk-format qcow2 --container-format bare --public > > 4.openstack image set --property hw_firmware_type=uefi --property > os_secure_boot=required WindowsVM > > 5.openstack image set --property hw_firmware_type=uefi --property > hw_disk_bus=ide WindowsVM > > 6.openstack image show WindowsVM > > 7. root at dmzcloud:/home/cloud# openstack image show WindowsVM|grep > "properties" > | properties | hw_disk_bus='ide', hw_firmware_type='uefi', > os_hash_algo='sha512', > > os_hash_value='753ee596980409e1e72d6d020c8219c56a6ada8b43f634fb575c594a245725a398e45982c0a1ad72b3fc3451cde62cceb9ff22be044863b31ecdd7893b049349', > os_hidden='False', os_secure_boot='required', > owner_specified.openstack.md5='', > owner_specified.openstack.object='images/WindowsVM', > owner_specified.openstack.sha256='' | > root at dmzcloud:/home/cloud# > > > Then I logged into horizon dashboard, from the images selected the > imported image and try to launch the instance. With a Flavour of 550 GB > disk, 4 vcpus and 8GB Ram .. > > The instance spawning ran for 30 minutes and throws the error which I > pasted first in the right top corner of horizon dashboard. > > How to solve this error and boot the Windows machine successfully .. > > > """ > Error : failed to perform requested operation on instance "WindowsVM "the > instance has error status. Please try again later [Error exceeded maximum > number of retries. Exhausted all hosts available for retrying build > failures for instance e3d5c095-7d26-4b1e-89d1-d1a6e20a45041 > > > """ > > Any help highly appreciated. > > Kris > > -- Mohammed Naser VEXXHOST, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonykarera at gmail.com Fri Aug 20 04:18:04 2021 From: tonykarera at gmail.com (Karera Tony) Date: Fri, 20 Aug 2021 06:18:04 +0200 Subject: Wallaby Magnum Issue Message-ID: Hello Team, I deployed Openstack Wallby on Ubuntu20 and enabled Magum, however when I create a cluster I get the error below. *Status ReasonERROR: Property error: : resources.api_lb.properties: : Property allowed_cidrs not assigned* Can someone advise on where I could be wrong. Btw, I disabled load balancer while creating the cluster. Regards Tony Karera -------------- next part -------------- An HTML attachment was scrubbed... URL: From feilong at catalyst.net.nz Fri Aug 20 04:52:50 2021 From: feilong at catalyst.net.nz (feilong) Date: Fri, 20 Aug 2021 16:52:50 +1200 Subject: Wallaby Magnum Issue In-Reply-To: References: Message-ID: <2cce14b7-4cc2-0d89-ff4e-747f177d3ea7@catalyst.net.nz> Hi Karera, It's probably a bug. If you do have Octavia deployed, can you try to not disable the LB and see how it goes? On 20/08/21 4:18 pm, Karera Tony wrote: > Hello Team, > > I deployed Openstack Wallby on Ubuntu20 and enabled Magum, however > when I create a cluster I get the error below. > > *Status Reason > ERROR: Property error: : resources.api_lb.properties: : Property > allowed_cidrs not assigned* > Can someone advise on where I could be wrong. Btw, I disabled load > balancer while creating the cluster. > > Regards > > Tony Karera > > -- Cheers & Best regards, ------------------------------------------------------------------------------ Feilong Wang (王飞龙) (he/him) Head of Research & Development Catalyst Cloud Aotearoa's own Mob: +64 21 0832 6348 | www.catalystcloud.nz Level 6, 150 Willis Street, Wellington 6011, New Zealand CONFIDENTIALITY NOTICE: This email is intended for the named recipients only. It may contain privileged, confidential or copyright information. If you are not the named recipient, any use, reliance upon, disclosure or copying of this email or its attachments is unauthorised. If you have received this email in error, please reply via email or call +64 21 0832 6348. ------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonykarera at gmail.com Fri Aug 20 04:55:35 2021 From: tonykarera at gmail.com (Karera Tony) Date: Fri, 20 Aug 2021 06:55:35 +0200 Subject: Wallaby Magnum Issue In-Reply-To: <2cce14b7-4cc2-0d89-ff4e-747f177d3ea7@catalyst.net.nz> References: <2cce14b7-4cc2-0d89-ff4e-747f177d3ea7@catalyst.net.nz> Message-ID: Hello Wang, Thanks for the feedback. Unfortunately Octavia is not deployed in my environment (at least not yet) and LB is not enabled on either the cluster template or the cluster itself. Regards Tony Karera On Fri, Aug 20, 2021 at 6:52 AM feilong wrote: > Hi Karera, > > It's probably a bug. If you do have Octavia deployed, can you try to not > disable the LB and see how it goes? > > > On 20/08/21 4:18 pm, Karera Tony wrote: > > Hello Team, > > I deployed Openstack Wallby on Ubuntu20 and enabled Magum, however when I > create a cluster I get the error below. > > > *Status Reason ERROR: Property error: : resources.api_lb.properties: : > Property allowed_cidrs not assigned* > Can someone advise on where I could be wrong. Btw, I disabled load > balancer while creating the cluster. > > Regards > > Tony Karera > > > -- > Cheers & Best regards, > ------------------------------------------------------------------------------ > Feilong Wang (王飞龙) (he/him) > Head of Research & Development > > Catalyst Cloud > Aotearoa's own > > Mob: +64 21 0832 6348 | www.catalystcloud.nz > Level 6, 150 Willis Street, Wellington 6011, New Zealand > > CONFIDENTIALITY NOTICE: This email is intended for the named recipients only. > It may contain privileged, confidential or copyright information. If you are > not the named recipient, any use, reliance upon, disclosure or copying of this > email or its attachments is unauthorised. If you have received this email in > error, please reply via email or call +64 21 0832 6348. > ------------------------------------------------------------------------------ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mnaser at vexxhost.com Fri Aug 20 05:02:51 2021 From: mnaser at vexxhost.com (Mohammed Naser) Date: Fri, 20 Aug 2021 01:02:51 -0400 Subject: Wallaby Magnum Issue In-Reply-To: References: <2cce14b7-4cc2-0d89-ff4e-747f177d3ea7@catalyst.net.nz> Message-ID: What does your cluster template and cluster create command look like? On Fri, Aug 20, 2021 at 12:59 AM Karera Tony wrote: > Hello Wang, > > Thanks for the feedback. > > Unfortunately Octavia is not deployed in my environment (at least not yet) > and LB is not enabled on either the cluster template or the cluster itself. > > Regards > > Tony Karera > > > > > On Fri, Aug 20, 2021 at 6:52 AM feilong wrote: > >> Hi Karera, >> >> It's probably a bug. If you do have Octavia deployed, can you try to not >> disable the LB and see how it goes? >> >> >> On 20/08/21 4:18 pm, Karera Tony wrote: >> >> Hello Team, >> >> I deployed Openstack Wallby on Ubuntu20 and enabled Magum, however when I >> create a cluster I get the error below. >> >> >> *Status Reason ERROR: Property error: : resources.api_lb.properties: : >> Property allowed_cidrs not assigned* >> Can someone advise on where I could be wrong. Btw, I disabled load >> balancer while creating the cluster. >> >> Regards >> >> Tony Karera >> >> >> -- >> Cheers & Best regards, >> ------------------------------------------------------------------------------ >> Feilong Wang (王飞龙) (he/him) >> Head of Research & Development >> >> Catalyst Cloud >> Aotearoa's own >> >> Mob: +64 21 0832 6348 | www.catalystcloud.nz >> Level 6, 150 Willis Street, Wellington 6011, New Zealand >> >> CONFIDENTIALITY NOTICE: This email is intended for the named recipients only. >> It may contain privileged, confidential or copyright information. If you are >> not the named recipient, any use, reliance upon, disclosure or copying of this >> email or its attachments is unauthorised. If you have received this email in >> error, please reply via email or call +64 21 0832 6348. >> ------------------------------------------------------------------------------ >> >> -- Mohammed Naser VEXXHOST, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mnaser at vexxhost.com Fri Aug 20 05:05:23 2021 From: mnaser at vexxhost.com (Mohammed Naser) Date: Fri, 20 Aug 2021 01:05:23 -0400 Subject: Active and standby controller nodes In-Reply-To: References: Message-ID: Most openstack services are stateless but a lot of the infrastructure services like RabbitMQ and MariaDB form a quorum therefore need at least 3 replicas or you might have a bad time if an outage occurs On Fri, Aug 13, 2021 at 10:36 PM Midhunlal Nb wrote: > Hi team, > I have a rocky installed openstack environment and it is working fine.In > my set up I have; > > 1 controller node,2 compute nodes and 1 storage node. > > Now we are planning to add 1 more controller node as standby.Is it > possible to add 1 more controller node in existing set up? if it is > possible ,anyone please share the procedure. > > > Thanks & Regards > Midhunlal N B > +918921245637 > > -- Mohammed Naser VEXXHOST, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From feilong at catalyst.net.nz Fri Aug 20 05:06:22 2021 From: feilong at catalyst.net.nz (feilong) Date: Fri, 20 Aug 2021 17:06:22 +1200 Subject: Wallaby Magnum Issue In-Reply-To: References: <2cce14b7-4cc2-0d89-ff4e-747f177d3ea7@catalyst.net.nz> Message-ID: <6ee8aaa9-8499-d72d-1686-1e45462ae078@catalyst.net.nz> OK. fair enough. You can try to set label "master_lb_allowed_cidrs" to workaround it. BTW, without load balancer, you can not create multi master nodes. As a result, you're etcd cluster is not HA which doesn't fit for production workload. On 20/08/21 4:55 pm, Karera Tony wrote: > Hello Wang, > > Thanks for the feedback. > > Unfortunately Octavia is not deployed in my environment (at least not > yet) and LB is not enabled on either the cluster template or the > cluster itself. > > Regards > > Tony Karera > > > > > On Fri, Aug 20, 2021 at 6:52 AM feilong > wrote: > > Hi Karera, > > It's probably a bug. If you do have Octavia deployed, can you try > to not disable the LB and see how it goes? > > > On 20/08/21 4:18 pm, Karera Tony wrote: >> Hello Team, >> >> I deployed Openstack Wallby on Ubuntu20 and enabled Magum, >> however when I create a cluster I get the error below. >> >> *Status Reason >> ERROR: Property error: : resources.api_lb.properties: : Property >> allowed_cidrs not assigned* >> Can someone advise on where I could be wrong. Btw, I disabled >> load balancer while creating the cluster. >> >> Regards >> >> Tony Karera >> >> > -- > Cheers & Best regards, > ------------------------------------------------------------------------------ > Feilong Wang (王飞龙) (he/him) > Head of Research & Development > > Catalyst Cloud > Aotearoa's own > > Mob: +64 21 0832 6348 | www.catalystcloud.nz > Level 6, 150 Willis Street, Wellington 6011, New Zealand > > CONFIDENTIALITY NOTICE: This email is intended for the named recipients only. > It may contain privileged, confidential or copyright information. If you are > not the named recipient, any use, reliance upon, disclosure or copying of this > email or its attachments is unauthorised. If you have received this email in > error, please reply via email or call +64 21 0832 6348. > ------------------------------------------------------------------------------ > -- Cheers & Best regards, ------------------------------------------------------------------------------ Feilong Wang (王飞龙) (he/him) Head of Research & Development Catalyst Cloud Aotearoa's own Mob: +64 21 0832 6348 | www.catalystcloud.nz Level 6, 150 Willis Street, Wellington 6011, New Zealand CONFIDENTIALITY NOTICE: This email is intended for the named recipients only. It may contain privileged, confidential or copyright information. If you are not the named recipient, any use, reliance upon, disclosure or copying of this email or its attachments is unauthorised. If you have received this email in error, please reply via email or call +64 21 0832 6348. ------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mnaser at vexxhost.com Fri Aug 20 05:08:42 2021 From: mnaser at vexxhost.com (Mohammed Naser) Date: Fri, 20 Aug 2021 01:08:42 -0400 Subject: Wallaby Magnum Issue In-Reply-To: References: <2cce14b7-4cc2-0d89-ff4e-747f177d3ea7@catalyst.net.nz> Message-ID: Please keep replies on list so others can help too. I don’t know how well tested the Swarm driver is at this point. I believe most Magnum users are using it for Kubernetes only. On Fri, Aug 20, 2021 at 1:05 AM Karera Tony wrote: > Hello Naser, > > Please check below. > > openstack coe cluster template create swarm-cluster-template1 \ > --image fedora-atomic-latest \ > --external-network External_1700\ > --dns-nameserver 8.8.8.8 \ > --master-flavor m1.small \ > --flavor m1.small \ > --coe swarm > openstack coe cluster create swarm-cluster \ > --cluster-template swarm-cluster-template \ > --master-count 1 \ > --node-count 2 \ > --keypair Newkey > > Regards > > Tony Karera > > > > > On Fri, Aug 20, 2021 at 7:03 AM Mohammed Naser > wrote: > >> What does your cluster template and cluster create command look like? >> >> On Fri, Aug 20, 2021 at 12:59 AM Karera Tony >> wrote: >> >>> Hello Wang, >>> >>> Thanks for the feedback. >>> >>> Unfortunately Octavia is not deployed in my environment (at least not >>> yet) and LB is not enabled on either the cluster template or the cluster >>> itself. >>> >>> Regards >>> >>> Tony Karera >>> >>> >>> >>> >>> On Fri, Aug 20, 2021 at 6:52 AM feilong wrote: >>> >>>> Hi Karera, >>>> >>>> It's probably a bug. If you do have Octavia deployed, can you try to >>>> not disable the LB and see how it goes? >>>> >>>> >>>> On 20/08/21 4:18 pm, Karera Tony wrote: >>>> >>>> Hello Team, >>>> >>>> I deployed Openstack Wallby on Ubuntu20 and enabled Magum, however when >>>> I create a cluster I get the error below. >>>> >>>> >>>> *Status Reason ERROR: Property error: : resources.api_lb.properties: : >>>> Property allowed_cidrs not assigned* >>>> Can someone advise on where I could be wrong. Btw, I disabled load >>>> balancer while creating the cluster. >>>> >>>> Regards >>>> >>>> Tony Karera >>>> >>>> >>>> -- >>>> Cheers & Best regards, >>>> ------------------------------------------------------------------------------ >>>> Feilong Wang (王飞龙) (he/him) >>>> Head of Research & Development >>>> >>>> Catalyst Cloud >>>> Aotearoa's own >>>> >>>> Mob: +64 21 0832 6348 | www.catalystcloud.nz >>>> Level 6, 150 Willis Street, Wellington 6011, New Zealand >>>> >>>> CONFIDENTIALITY NOTICE: This email is intended for the named recipients only. >>>> It may contain privileged, confidential or copyright information. If you are >>>> not the named recipient, any use, reliance upon, disclosure or copying of this >>>> email or its attachments is unauthorised. If you have received this email in >>>> error, please reply via email or call +64 21 0832 6348. >>>> ------------------------------------------------------------------------------ >>>> >>>> -- >> Mohammed Naser >> VEXXHOST, Inc. >> > -- Mohammed Naser VEXXHOST, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From feilong at catalyst.net.nz Fri Aug 20 07:00:49 2021 From: feilong at catalyst.net.nz (feilong) Date: Fri, 20 Aug 2021 19:00:49 +1200 Subject: Wallaby Magnum Issue In-Reply-To: References: <2cce14b7-4cc2-0d89-ff4e-747f177d3ea7@catalyst.net.nz> Message-ID: Oooh, are you using Swarm? I don't think that driver is well maintained. I didn't see any interest in the last 4 years since I involved in the Magnum project. If there is no specific reason, I would suggest go for k8s. On 20/08/21 5:08 pm, Mohammed Naser wrote: > Please keep replies on list so others can help too.  > > I don’t know how well tested the Swarm driver is at this point. I > believe most Magnum users are using it for Kubernetes only.  > > On Fri, Aug 20, 2021 at 1:05 AM Karera Tony > wrote: > > Hello Naser, > > Please check below. > > openstack coe cluster template create swarm-cluster-template1 \ >                      --image fedora-atomic-latest \ >                      --external-network External_1700\ >                      --dns-nameserver 8.8.8.8 \ >                      --master-flavor m1.small \ >                      --flavor m1.small \ >                      --coe swarm > openstack coe cluster create swarm-cluster \ >                         --cluster-template swarm-cluster-template \ >                         --master-count 1 \ >                         --node-count 2 \ >                         --keypair Newkey > > Regards > > Tony Karera > > > > > On Fri, Aug 20, 2021 at 7:03 AM Mohammed Naser > > wrote: > > What does your cluster template and cluster create command > look like? > > On Fri, Aug 20, 2021 at 12:59 AM Karera Tony > > wrote: > > Hello Wang, > > Thanks for the feedback. > > Unfortunately Octavia is not deployed in my environment > (at least not yet) and LB is not enabled on either the > cluster template or the cluster itself. > > Regards > > Tony Karera > > > > > On Fri, Aug 20, 2021 at 6:52 AM feilong > > > wrote: > > Hi Karera, > > It's probably a bug. If you do have Octavia deployed, > can you try to not disable the LB and see how it goes? > > > On 20/08/21 4:18 pm, Karera Tony wrote: >> Hello Team, >> >> I deployed Openstack Wallby on Ubuntu20 and enabled >> Magum, however when I create a cluster I get the >> error below. >> >> *Status Reason >> ERROR: Property error: : resources.api_lb.properties: >> : Property allowed_cidrs not assigned* >> Can someone advise on where I could be wrong. Btw, I >> disabled load balancer while creating the cluster. >> >> Regards >> >> Tony Karera >> >> > -- > Cheers & Best regards, > ------------------------------------------------------------------------------ > Feilong Wang (王飞龙) (he/him) > Head of Research & Development > > Catalyst Cloud > Aotearoa's own > > Mob: +64 21 0832 6348 | www.catalystcloud.nz > Level 6, 150 Willis Street, Wellington 6011, New Zealand > > CONFIDENTIALITY NOTICE: This email is intended for the named recipients only. > It may contain privileged, confidential or copyright information. If you are > not the named recipient, any use, reliance upon, disclosure or copying of this > email or its attachments is unauthorised. If you have received this email in > error, please reply via email or call +64 21 0832 6348. > ------------------------------------------------------------------------------ > > -- > Mohammed Naser > VEXXHOST, Inc. > > -- > Mohammed Naser > VEXXHOST, Inc. -- Cheers & Best regards, ------------------------------------------------------------------------------ Feilong Wang (王飞龙) (he/him) Head of Research & Development Catalyst Cloud Aotearoa's own Mob: +64 21 0832 6348 | www.catalystcloud.nz Level 6, 150 Willis Street, Wellington 6011, New Zealand CONFIDENTIALITY NOTICE: This email is intended for the named recipients only. It may contain privileged, confidential or copyright information. If you are not the named recipient, any use, reliance upon, disclosure or copying of this email or its attachments is unauthorised. If you have received this email in error, please reply via email or call +64 21 0832 6348. ------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From midhunlaln66 at gmail.com Fri Aug 20 08:49:17 2021 From: midhunlaln66 at gmail.com (Midhunlal Nb) Date: Fri, 20 Aug 2021 14:19:17 +0530 Subject: Active and standby controller nodes In-Reply-To: References: Message-ID: Hi Mohammed, If you have any documents or procedure for this set up ,then please share with me. On Fri, Aug 20, 2021, 10:35 AM Mohammed Naser wrote: > Most openstack services are stateless but a lot of the infrastructure > services like RabbitMQ and MariaDB form a quorum therefore need at least 3 > replicas or you might have a bad time if an outage occurs > > On Fri, Aug 13, 2021 at 10:36 PM Midhunlal Nb > wrote: > >> Hi team, >> I have a rocky installed openstack environment and it is working fine.In >> my set up I have; >> >> 1 controller node,2 compute nodes and 1 storage node. >> >> Now we are planning to add 1 more controller node as standby.Is it >> possible to add 1 more controller node in existing set up? if it is >> possible ,anyone please share the procedure. >> >> >> Thanks & Regards >> Midhunlal N B >> +918921245637 >> >> -- > Mohammed Naser > VEXXHOST, Inc. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michal.arbet at ultimum.io Fri Aug 20 11:00:00 2021 From: michal.arbet at ultimum.io (Michal Arbet) Date: Fri, 20 Aug 2021 13:00:00 +0200 Subject: Active and standby controller nodes In-Reply-To: References: Message-ID: Hi Midhunlal, If your infrastructure services which should have minimal 3 nodes to form a quorum (like RabbitMQ and Mariadb and potentially some additional services If you are using some) are running on controller nodes, you should have 3 controllers. If you are HW limited, you also can have 2 nodes, but you can expect some form of split-brain in future. If you still will have only 2 controllers, 1. you should consider to use mariadb arbitrator for mariadb (member of quorum, not replicating data) which should be in some third location 2. Handle cluster_partition_handling in rabbitmq config (probably autoheal for two nodes) Next you have to prepare some loadbalancer (haproxy, nginx , apache ? ), some HA solution (keepalived ? with virtualiP ) and add that two controllers as backends. Edit endpoints to point to HA virtualIP address of loadbalancer That's minimal I think. Michal Arbet Openstack Engineer Ultimum Technologies a.s. Na Poříčí 1047/26, 11000 Praha 1 Czech Republic +420 604 228 897 michal.arbet at ultimum.io *https://ultimum.io * LinkedIn | Twitter | Facebook pá 20. 8. 2021 v 10:57 odesílatel Midhunlal Nb napsal: > Hi Mohammed, > If you have any documents or procedure for this set up ,then please share > with me. > > On Fri, Aug 20, 2021, 10:35 AM Mohammed Naser wrote: > >> Most openstack services are stateless but a lot of the infrastructure >> services like RabbitMQ and MariaDB form a quorum therefore need at least 3 >> replicas or you might have a bad time if an outage occurs >> >> On Fri, Aug 13, 2021 at 10:36 PM Midhunlal Nb >> wrote: >> >>> Hi team, >>> I have a rocky installed openstack environment and it is working >>> fine.In my set up I have; >>> >>> 1 controller node,2 compute nodes and 1 storage node. >>> >>> Now we are planning to add 1 more controller node as standby.Is it >>> possible to add 1 more controller node in existing set up? if it is >>> possible ,anyone please share the procedure. >>> >>> >>> Thanks & Regards >>> Midhunlal N B >>> +918921245637 >>> >>> -- >> Mohammed Naser >> VEXXHOST, Inc. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iurygregory at gmail.com Fri Aug 20 13:10:44 2021 From: iurygregory at gmail.com (Iury Gregory) Date: Fri, 20 Aug 2021 15:10:44 +0200 Subject: [Ironic] Xena Midcycle next week! In-Reply-To: References: Message-ID: I forgot to mention that we will be using the meetpad [1] =) [1] https://meetpad.opendev.org/ironic Em qua., 18 de ago. de 2021 às 18:03, Iury Gregory escreveu: > Hello Ironicers! > > Our schedule for the Midcycle is available in the etherpad[1]. See you > next week! > > [1] https://etherpad.opendev.org/p/ironic-xena-midcycle > > -- > > > *Att[]'sIury Gregory Melo Ferreira * > *MSc in Computer Science at UFCG* > *Part of the ironic-core and puppet-manager-core team in OpenStack* > *Software Engineer at Red Hat Czech* > *Social*: https://www.linkedin.com/in/iurygregory > *E-mail: iurygregory at gmail.com * > -- *Att[]'sIury Gregory Melo Ferreira * *MSc in Computer Science at UFCG* *Part of the ironic-core and puppet-manager-core team in OpenStack* *Software Engineer at Red Hat Czech* *Social*: https://www.linkedin.com/in/iurygregory *E-mail: iurygregory at gmail.com * -------------- next part -------------- An HTML attachment was scrubbed... URL: From iurygregory at gmail.com Fri Aug 20 13:16:50 2021 From: iurygregory at gmail.com (Iury Gregory) Date: Fri, 20 Aug 2021 15:16:50 +0200 Subject: [Ironic] No upstream meeting on Aug 23 Message-ID: Hello Ironicers, I forgot to send this email earlier. Since next week is our midcycle, we won't have the upstream meeting. -- *Att[]'sIury Gregory Melo Ferreira * *MSc in Computer Science at UFCG* *Part of the ironic-core and puppet-manager-core team in OpenStack* *Software Engineer at Red Hat Czech* *Social*: https://www.linkedin.com/in/iurygregory *E-mail: iurygregory at gmail.com * -------------- next part -------------- An HTML attachment was scrubbed... URL: From akanevsk at redhat.com Fri Aug 20 13:58:38 2021 From: akanevsk at redhat.com (Arkady Kanevsky) Date: Fri, 20 Aug 2021 09:58:38 -0400 Subject: [Interop][Refstack] Today's meeting is cancelled Message-ID: Please, see progress on https://etherpad.opendev.org/p/interop . -- Arkady Kanevsky, Ph.D. Phone: 972 707-6456 Corporate Phone: 919 729-5744 ext. 8176456 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonykarera at gmail.com Fri Aug 20 05:10:35 2021 From: tonykarera at gmail.com (Karera Tony) Date: Fri, 20 Aug 2021 07:10:35 +0200 Subject: Wallaby Magnum Issue In-Reply-To: <6ee8aaa9-8499-d72d-1686-1e45462ae078@catalyst.net.nz> References: <2cce14b7-4cc2-0d89-ff4e-747f177d3ea7@catalyst.net.nz> <6ee8aaa9-8499-d72d-1686-1e45462ae078@catalyst.net.nz> Message-ID: Hello Feilong, Thanks a lot, Unfortunately, I am not sure how to set it in the label. Can you assist in how to go about it as I get the error below.. [image: image.png] Regards Tony Karera On Fri, Aug 20, 2021 at 7:06 AM feilong wrote: > OK. fair enough. You can try to set label "master_lb_allowed_cidrs" to > workaround it. BTW, without load balancer, you can not create multi master > nodes. As a result, you're etcd cluster is not HA which doesn't fit for > production workload. > > > On 20/08/21 4:55 pm, Karera Tony wrote: > > Hello Wang, > > Thanks for the feedback. > > Unfortunately Octavia is not deployed in my environment (at least not yet) > and LB is not enabled on either the cluster template or the cluster itself. > > Regards > > Tony Karera > > > > > On Fri, Aug 20, 2021 at 6:52 AM feilong wrote: > >> Hi Karera, >> >> It's probably a bug. If you do have Octavia deployed, can you try to not >> disable the LB and see how it goes? >> >> >> On 20/08/21 4:18 pm, Karera Tony wrote: >> >> Hello Team, >> >> I deployed Openstack Wallby on Ubuntu20 and enabled Magum, however when I >> create a cluster I get the error below. >> >> >> *Status Reason ERROR: Property error: : resources.api_lb.properties: : >> Property allowed_cidrs not assigned* >> Can someone advise on where I could be wrong. Btw, I disabled load >> balancer while creating the cluster. >> >> Regards >> >> Tony Karera >> >> >> -- >> Cheers & Best regards, >> ------------------------------------------------------------------------------ >> Feilong Wang (王飞龙) (he/him) >> Head of Research & Development >> >> Catalyst Cloud >> Aotearoa's own >> >> Mob: +64 21 0832 6348 | www.catalystcloud.nz >> Level 6, 150 Willis Street, Wellington 6011, New Zealand >> >> CONFIDENTIALITY NOTICE: This email is intended for the named recipients only. >> It may contain privileged, confidential or copyright information. If you are >> not the named recipient, any use, reliance upon, disclosure or copying of this >> email or its attachments is unauthorised. If you have received this email in >> error, please reply via email or call +64 21 0832 6348. >> ------------------------------------------------------------------------------ >> >> -- > Cheers & Best regards, > ------------------------------------------------------------------------------ > Feilong Wang (王飞龙) (he/him) > Head of Research & Development > > Catalyst Cloud > Aotearoa's own > > Mob: +64 21 0832 6348 | www.catalystcloud.nz > Level 6, 150 Willis Street, Wellington 6011, New Zealand > > CONFIDENTIALITY NOTICE: This email is intended for the named recipients only. > It may contain privileged, confidential or copyright information. If you are > not the named recipient, any use, reliance upon, disclosure or copying of this > email or its attachments is unauthorised. If you have received this email in > error, please reply via email or call +64 21 0832 6348. > ------------------------------------------------------------------------------ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 39791 bytes Desc: not available URL: From tonykarera at gmail.com Fri Aug 20 05:11:22 2021 From: tonykarera at gmail.com (Karera Tony) Date: Fri, 20 Aug 2021 07:11:22 +0200 Subject: Wallaby Magnum Issue In-Reply-To: References: <2cce14b7-4cc2-0d89-ff4e-747f177d3ea7@catalyst.net.nz> <6ee8aaa9-8499-d72d-1686-1e45462ae078@catalyst.net.nz> Message-ID: Sure, This is well noted Regards Tony Karera On Fri, Aug 20, 2021 at 7:10 AM Karera Tony wrote: > Hello Feilong, > > Thanks a lot, Unfortunately, I am not sure how to set it in the label. > Can you assist in how to go about it as I get the error below.. > [image: image.png] > > > > > Regards > > Tony Karera > > > > > On Fri, Aug 20, 2021 at 7:06 AM feilong wrote: > >> OK. fair enough. You can try to set label "master_lb_allowed_cidrs" to >> workaround it. BTW, without load balancer, you can not create multi master >> nodes. As a result, you're etcd cluster is not HA which doesn't fit for >> production workload. >> >> >> On 20/08/21 4:55 pm, Karera Tony wrote: >> >> Hello Wang, >> >> Thanks for the feedback. >> >> Unfortunately Octavia is not deployed in my environment (at least not >> yet) and LB is not enabled on either the cluster template or the cluster >> itself. >> >> Regards >> >> Tony Karera >> >> >> >> >> On Fri, Aug 20, 2021 at 6:52 AM feilong wrote: >> >>> Hi Karera, >>> >>> It's probably a bug. If you do have Octavia deployed, can you try to not >>> disable the LB and see how it goes? >>> >>> >>> On 20/08/21 4:18 pm, Karera Tony wrote: >>> >>> Hello Team, >>> >>> I deployed Openstack Wallby on Ubuntu20 and enabled Magum, however when >>> I create a cluster I get the error below. >>> >>> >>> *Status Reason ERROR: Property error: : resources.api_lb.properties: : >>> Property allowed_cidrs not assigned* >>> Can someone advise on where I could be wrong. Btw, I disabled load >>> balancer while creating the cluster. >>> >>> Regards >>> >>> Tony Karera >>> >>> >>> -- >>> Cheers & Best regards, >>> ------------------------------------------------------------------------------ >>> Feilong Wang (王飞龙) (he/him) >>> Head of Research & Development >>> >>> Catalyst Cloud >>> Aotearoa's own >>> >>> Mob: +64 21 0832 6348 | www.catalystcloud.nz >>> Level 6, 150 Willis Street, Wellington 6011, New Zealand >>> >>> CONFIDENTIALITY NOTICE: This email is intended for the named recipients only. >>> It may contain privileged, confidential or copyright information. If you are >>> not the named recipient, any use, reliance upon, disclosure or copying of this >>> email or its attachments is unauthorised. If you have received this email in >>> error, please reply via email or call +64 21 0832 6348. >>> ------------------------------------------------------------------------------ >>> >>> -- >> Cheers & Best regards, >> ------------------------------------------------------------------------------ >> Feilong Wang (王飞龙) (he/him) >> Head of Research & Development >> >> Catalyst Cloud >> Aotearoa's own >> >> Mob: +64 21 0832 6348 | www.catalystcloud.nz >> Level 6, 150 Willis Street, Wellington 6011, New Zealand >> >> CONFIDENTIALITY NOTICE: This email is intended for the named recipients only. >> It may contain privileged, confidential or copyright information. If you are >> not the named recipient, any use, reliance upon, disclosure or copying of this >> email or its attachments is unauthorised. If you have received this email in >> error, please reply via email or call +64 21 0832 6348. >> ------------------------------------------------------------------------------ >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 39791 bytes Desc: not available URL: From anyrude10 at gmail.com Fri Aug 20 07:21:17 2021 From: anyrude10 at gmail.com (Anirudh Gupta) Date: Fri, 20 Aug 2021 12:51:17 +0530 Subject: [Kolla-Ansible][Ironic] Baremetal node Cleaning fails in UEFI mode, but succeeds in Legacy Bios Mode In-Reply-To: References: Message-ID: Hi Mark, There was some issue with the cleaning image due to which the issue reported in previous conversation was observed. This was successfully resolved. By setting the parameter in ironic.conf file [pxe] uefi_ipxe_bootfile_name = ipxe-x86_64.efi The "node provide" command successfully executed and the node came in "available" state. *In Legacy:* When I am trying to create the server using "server create " command and a userimage is passed in the command, the procedure is that the node will install userimage over the network and then will be rebooted After the reboot, it will boot up with the Hard disk and with the OS specified in userimage. *In UEFI:* When I am trying to create the server using "server create " command and a userimage is passed in the command, the procedure of installing user image and rebooting remains the same. But After the reboot, despite setting the hard disk as the first priority, it again starts booting over the network and eventually fails. I have also tried passing the *capabilities='boot_option:local' *both in baremetal node and flavor, but the behaviour is the same. Regards Anirudh Gupta On Mon, Aug 16, 2021 at 2:54 PM Anirudh Gupta wrote: > Hi Mark, > > Thanks for your reply. Yes, I am using Centos 8 only. > > I tried changing the settings and restarted the docker container. > > The cleaning process moved a step further but it started showing the error *"Could > not select: Exec format not supported"* > > [image: image.png] > > Regards > Anirudh Gupta > > > > On Mon, Aug 16, 2021 at 1:52 PM Mark Goddard wrote: > >> Hi Anirudh, >> >> Are you using CentOS 8? The iPXE EFI bootloader file is >> named ipxe-x86_64.efi there, so a TFTP request for ipxe.efi will fail. >> >> Could you try setting the following in ironic.conf: >> >> [pxe] >> uefi_ipxe_bootfile_name = ipxe-x86_64.efi >> >> If this works, we should change it in kolla-ansible. Would you be able to >> propose the change via Gerrit? >> >> Mark >> >> On Fri, 13 Aug 2021 at 17:18, Anirudh Gupta wrote: >> >>> Hi Team, >>> >>> I am trying to provision Baremetal node using IRONIC with KOLLA-ANSIBLE. >>> I have enabled the support of "IPXE" in kolla-ansible as well. >>> >>> I am getting an issue that when my baremetal node is booted in UEFI >>> Mode, it is not able to find file *"ipxe.efi"* as a result of which >>> cleaning of the node fails >>> >>> [image: image.png] >>> >>> But when I change the BIOS Mode of my Baremetal Node to Legacy.BIOS, it >>> looks for the file "*undionly.kpxe"* for which the acknowledgment is >>> received and Data Packets are transferred. Eventually the cleaning of node >>> is also a success. >>> >>> [image: image.png] >>> >>> Is there any limitation of IRONIC or KOLLA-ANSIBLE side that >>> provisioning of Baremetal Node can only be done in Legacy Bios Mode? >>> For bare metal provisioning in UEFI mode, is there any other parameter >>> that needs to be enabled. >>> >>> Regards >>> Anirudh Gupta >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 200447 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 91313 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 126227 bytes Desc: not available URL: From dtantsur at redhat.com Fri Aug 20 10:17:06 2021 From: dtantsur at redhat.com (Dmitry Tantsur) Date: Fri, 20 Aug 2021 12:17:06 +0200 Subject: [Kolla][Kolla-Ansible] Ironic Node Cleaning Failed In-Reply-To: References: Message-ID: Hi, On Fri, Aug 13, 2021 at 8:56 AM Anirudh Gupta wrote: > Hi All, > > I had a 900 GB hard disk on my Baremetal Node and it took approx *15 > hours *to make the baremetal node come in *available* state from > *clean_wait* state. > > Once the baremetal node came available, I was able to create a server and > provision it with a user image. > > Is taking 15 hours to erase_device in clean_wait normal for a 900 GB hard > disk in Ironic? > Unfortunately, yes. If your hardware does not support ATA secure erase, the only way we can remove data is to shred the disk (essentially, write all 900 GB several times). If you don't care about residual data on the disks, you can switch to metadata cleaning (only partition tables). This is fast but insecure. I don't know how the options are called in Kolla, but in Ironic you do something like this: [deploy] erase_devices_priority = 0 erase_devices_metadata_priority = 10 Dmitry > > Regards > Anirudh Gupta > > > On Mon, Aug 9, 2021 at 2:01 PM Anirudh Gupta wrote: > >> Hi Mark, >> >> Earlier I was passing the boot_mode as uefi while creating the baremetal >> node. >> On Kolla-Ansible Launchpad, I found some issues related to UEFI mode, so >> I didn't pass the parameter. >> >> With IPXE and without passing UEFI boot mode parameter, my node started >> cleaning. It connected with the TFTP server. >> >> But from the last 2 hours, the state is still in *clean_wait* only. >> >> The ramdisk and kernel images I used were the ones mentioned in the link >> below >> >> >> - >> https://tarballs.openstack.org/ironic-python-agent/dib/files/ipa-centos8-master.kernel >> - >> https://tarballs.openstack.org/ironic-python-agent/dib/files/ipa-centos8-master.initramfs >> >> >> For this I followed the latest kolla ansible document:- >> >> - >> https://docs.openstack.org/kolla-ansible/latest/reference/bare-metal/ironic-guide.html >> >> >> All I can see in *ironic-conductor* logs is: >> >> 2021-08-09 13:49:51.159 7 DEBUG ironic.drivers.modules.agent_base [-] >> Heartbeat from node 8b1ec553-fbc9-4912-bd33-88afc41b8f81 heartbeat >> /var/lib/kolla/venv/lib/python3.6/site-packages/ironic/drivers/modules/agent_base.py:641 >> 2021-08-09 13:49:51.178 7 DEBUG ironic.drivers.modules.agent_client [-] >> Fetching status of agent commands for node >> 8b1ec553-fbc9-4912-bd33-88afc41b8f81 get_commands_status >> /var/lib/kolla/venv/lib/python3.6/site-packages/ironic/drivers/modules/agent_client.py:310 >> 2021-08-09 13:49:51.186 7 DEBUG ironic.drivers.modules.agent_client [-] >> Status of agent commands for node 8b1ec553-fbc9-4912-bd33-88afc41b8f81: >> get_clean_steps: result "{'clean_steps': {'GenericHardwareManager': >> [{'step': 'erase_devices', 'priority': 10, 'interface': 'deploy', >> 'reboot_requested': False, 'abortable': True}, {'step': >> 'erase_devices_metadata', 'priority': 99, 'interface': 'deploy', >> 'reboot_requested': False, 'abortable': True}, {'step': 'erase_pstore', >> 'priority': 0, 'interface': 'deploy', 'reboot_requested': False, >> 'abortable': True}, {'step': 'delete_configuration', 'priority': 0, >> 'interface': 'raid', 'reboot_requested': False, 'abortable': True}, >> {'step': 'create_configuration', 'priority': 0, 'interface': 'raid', >> 'reboot_requested': False, 'abortable': True}, {'step': 'burnin_cpu', >> 'priority': 0, 'interface': 'deploy', 'reboot_requested': False, >> 'abortable': True}, {'step': 'burnin_disk', 'priority': 0, 'interface': >> 'deploy', 'reboot_requested': False, 'abortable': True}, {'step': >> 'burnin_memory', 'priority': 0, 'interface': 'deploy', 'reboot_requested': >> False, 'abortable': True}, {'step': 'burnin_network', 'priority': 0, >> 'interface': 'deploy', 'reboot_requested': False, 'abortable': True}]}, >> 'hardware_manager_version': {'MellanoxDeviceHardwareManager': '1', >> 'generic_hardware_manager': '1.1'}}", error "None"; execute_clean_step: >> result "{'clean_result': None, 'clean_step': {'step': >> 'erase_devices_metadata', 'priority': 99, 'interface': 'deploy', >> 'reboot_requested': False, 'abortable': True, 'requires_ramdisk': True}}", >> error "None"; execute_clean_step: result "None", error "None" >> get_commands_status >> /var/lib/kolla/venv/lib/python3.6/site-packages/ironic/drivers/modules/agent_client.py:342 >> 2021-08-09 13:49:51.186 7 DEBUG ironic.drivers.modules.agent_base [-] *Clean >> step still running for node 8b1ec553-fbc9-4912-bd33-88afc41b8f81:* None >> _get_completed_command >> /var/lib/kolla/venv/lib/python3.6/site-packages/ironic/drivers/modules/agent_base.py:267 >> >> It would be a great help if you could suggest some pointers. >> >> Regards >> Anirudh Gupta >> >> >> >> >> I tried >> >> On Mon, Aug 9, 2021 at 1:43 PM Mark Goddard wrote: >> >>> >>> >>> On Fri, 6 Aug 2021 at 13:49, Anirudh Gupta wrote: >>> >>>> Hi Dmitry, >>>> >>>> I tried taking TCPDUMP while the Baremetal Node was booting up and >>>> looked for tftp protocols and found there was some "*File Not Found" *traces >>>> for bootx64.efi >>>> >>>> [image: image.png] >>>> >>>> Then, I found a related post on openstack Discuss which suggested to >>>> enable IPXE >>>> >>>> http://lists.openstack.org/pipermail/openstack-discuss/2019-October/010329.html >>>> >>>> After re-deploying the setup with IPXE enabled, i found similar traces >>>> now for *ipxe.efi file* >>>> >>>> [image: image.png] >>>> >>>> Can you please now suggest what possibly could be a miss in >>>> configuration and steps to resolve it. >>>> >>> >>> Hi Anirudh, >>> >>> I'd suggest installing a tftp client on your machine and making some >>> requests. The TFTP daemon runs in the ironic_pxe container, and TFTP files >>> are served from /tftpboot in that container. >>> >>> Mark >>> >>>> >>>> For your reference, I am attaching the complete tcpdump logs of both >>>> the Scenarios >>>> >>>> Looking forward to hearing from you. >>>> >>>> Regards >>>> Anirudh Gupta >>>> >>>> >>>> >>>> >>>> >>>> On Thu, Aug 5, 2021 at 4:56 PM Anirudh Gupta >>>> wrote: >>>> >>>>> Hi Team, >>>>> >>>>> On further debugging, I found an error in neutron-server logs >>>>> >>>>> >>>>> Failed to bind port 476d8175-ffc2-49ba-bb12-0a77c1f07e5f on host >>>>> f4a43fa5-9c41-488e-a34d-714ae5a9d300 for vnic_type baremetal using segments >>>>> [{'id': '1a5bbe96-2488-4971-925f-7c9346ba3ef5', 'network_type': 'flat', >>>>> 'physical_network': 'physnet1', 'segmentation_id': None, 'network_id': >>>>> '5b6cccec-ad86-4ed9-8d3c-72a31ec3a0d4'}] >>>>> 2021-08-05 16:33:06.979 23 INFO neutron.plugins.ml2.plugin >>>>> [req-54d11d51-7319-43ea-b70c-fe39d8aafe8a 21d6a238438e4294912746bcdc895e31 >>>>> 3eca725754e1405eb178cc39bd0da3aa - default default] Attempt 9 to bind port >>>>> 476d8175-ffc2-49ba-bb12-0a77c1f07e5f >>>>> >>>>> where 476d8175-ffc2-49ba-bb12-0a77c1f07e5f is the uuid of Baremetal >>>>> Node >>>>> >>>>> However the port is created in openstack, but its state is down >>>>> >>>>> [ansible at localhost ~]$ openstack port list >>>>> >>>>> +--------------------------------------+------+-------------------+---------------------------------------------------------------------------+--------+ >>>>> | ID | Name | MAC Address | >>>>> Fixed IP Addresses | >>>>> Status | >>>>> >>>>> +--------------------------------------+------+-------------------+---------------------------------------------------------------------------+--------+ >>>>> | 07d6b83d-d83c-498f-8ba8-b4f21bef7249 | | fa:16:3e:38:05:9d | >>>>> ip_address='10.0.1.200', subnet_id='7b72c158-2146-4bd6-893b-bd76b4a3e869' | >>>>> ACTIVE | >>>>> | 476d8175-ffc2-49ba-bb12-0a77c1f07e5f | | *98:f2:b3:3f:72:d8* | >>>>> ip_address='10.0.1.202', subnet_id='7b72c158-2146-4bd6-893b-bd76b4a3e869' | *DOWN >>>>> * | >>>>> >>>>> +--------------------------------------+------+-------------------+---------------------------------------------------------------------------+--------+ >>>>> >>>>> *98:f2:b3:3f:72:d8 *is the mac address of my Baremetal Node on which >>>>> PXE is enabled. >>>>> >>>>> Can someone please help in resolving this issue. >>>>> >>>>> *Issue:* >>>>> *Node goes in clean_failed from clean_wait.* >>>>> >>>>> Regards >>>>> Anirudh Gupta >>>>> >>>>> On Tue, Aug 3, 2021 at 8:32 PM Anirudh Gupta >>>>> wrote: >>>>> >>>>>> Hi Dmitry, >>>>>> >>>>>> I might be wrong, but as per my understanding if there would be an >>>>>> issue in dnsmasq, then IP 20.20.20.10 would not have been assigned to the >>>>>> machine. >>>>>> >>>>>> TCPDUMP logs are as below: >>>>>> >>>>>> 20:16:58.938089 IP controller.bootps > 255.255.255.255.bootpc: >>>>>> BOOTP/DHCP, Reply, length 312 >>>>>> 20:17:02.765291 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: >>>>>> BOOTP/DHCP, Request from 98:f2:b3:3f:72:e5 (oui Unknown), length 359 >>>>>> 20:17:02.766303 IP controller.bootps > 255.255.255.255.bootpc: >>>>>> BOOTP/DHCP, Reply, length 312 >>>>>> 20:17:26.944378 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: >>>>>> BOOTP/DHCP, Request from 98:f2:b3:3f:72:e5 (oui Unknown), length 347 >>>>>> 20:17:26.944756 IP controller.bootps > 255.255.255.255.bootpc: >>>>>> BOOTP/DHCP, Reply, length 312 >>>>>> 20:17:30.763627 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: >>>>>> BOOTP/DHCP, Request from 98:f2:b3:3f:72:e5 (oui Unknown), length 359 >>>>>> 20:17:30.764620 IP controller.bootps > 255.255.255.255.bootpc: >>>>>> BOOTP/DHCP, Reply, length 312 >>>>>> 20:17:54.938791 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: >>>>>> BOOTP/DHCP, Request from 98:f2:b3:3f:72:e5 (oui Unknown), length 347 >>>>>> >>>>>> Also the neutron dnsmasq logs and ironic inspector logs are attached >>>>>> in the mail. >>>>>> >>>>>> Regards >>>>>> Anirudh Gupta >>>>>> >>>>>> >>>>>> On Tue, Aug 3, 2021 at 7:29 PM Dmitry Tantsur >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> You need to check the dnsmasq logs (there are two dnsmasqs: from >>>>>>> neutron and from ironic-inspector). tcpdump may also help to determine >>>>>>> where the packages are lost. >>>>>>> >>>>>>> Dmitry >>>>>>> >>>>>>> On Fri, Jul 30, 2021 at 10:29 PM Anirudh Gupta >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Dmitry >>>>>>>> >>>>>>>> Thanks for your time. >>>>>>>> >>>>>>>> My system is getting IP 20.20.20.10 which is in the range defined >>>>>>>> in ironic_dnsmasq_dhcp_range field under globals.yml file. >>>>>>>> >>>>>>>> ironic_dnsmasq_dhcp_range: "20.20.20.10,20.20.20.100" >>>>>>>> >>>>>>>> And in the cleaning network (public1), the range defined is >>>>>>>> 20.20.20.150-20.20.20.200 >>>>>>>> >>>>>>>> As per my understanding, these 2 ranges should be mutually >>>>>>>> exclusive. >>>>>>>> >>>>>>>> Please suggest if my understanding is not correct. >>>>>>>> >>>>>>>> Any suggestions what should I do to resolve this issue? >>>>>>>> >>>>>>>> Regards >>>>>>>> Anirudh Gupta >>>>>>>> >>>>>>>> >>>>>>>> On Sat, 31 Jul, 2021, 12:06 am Dmitry Tantsur, >>>>>>>> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Jul 29, 2021 at 6:05 PM Anirudh Gupta >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hi Team, >>>>>>>>>> >>>>>>>>>> In to the email below, I have some updated information:- >>>>>>>>>> >>>>>>>>>> Earlier the allocation range mentioned in " >>>>>>>>>> *ironic_dnsmasq_dhcp_range*" in globals.yml had an overlapping >>>>>>>>>> range with the cleaning network, due to which there was some issue in >>>>>>>>>> receiving the DHCP request >>>>>>>>>> >>>>>>>>>> After creating a cleaning network with a separate allocation >>>>>>>>>> range, I am successfully getting IP allocated to my Baremetal Node >>>>>>>>>> >>>>>>>>>> - openstack subnet create subnet1 --network public1 >>>>>>>>>> --subnet-range 20.20.20.0/24 --allocation-pool >>>>>>>>>> start=20.20.20.150,end=20.20.20.200 --ip-version=4 --gateway=20.20.20.1 >>>>>>>>>> --dhcp >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> [image: image.png] >>>>>>>>>> >>>>>>>>>> After getting the IP, there is no further action on the node. >>>>>>>>>> From "*clean_wait*", it goes into "*clean_failed*" state after >>>>>>>>>> around half an hour. >>>>>>>>>> >>>>>>>>> >>>>>>>>> The IP address is not from the cleaning range, it may come from >>>>>>>>> inspection. You probably need to investigate your network topology, maybe >>>>>>>>> use tcpdump. >>>>>>>>> >>>>>>>>> Unfortunately, I'm not fluent in Kolla to say if it can be a bug >>>>>>>>> or not. >>>>>>>>> >>>>>>>>> Dmitry >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On verifying the logs, I could see the below error messages >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - In */var/log/kolla/ironic/ironic-conductor.log*, we >>>>>>>>>> observed the following error: >>>>>>>>>> >>>>>>>>>> ERROR ironic.conductor.utils [-] Cleaning for node >>>>>>>>>> 3a56748e-a8ca-4dec-a332-ace18e6d494e failed. *Timeout reached >>>>>>>>>> while cleaning the node. Please check if the ramdisk responsible for the >>>>>>>>>> cleaning is running on the node. Failed on step {}.* >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Note : For Cleaning the node, we have used the below images >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> https://tarballs.openstack.org/ironic-python-agent/dib/files/ipa-centos8-master.kernel >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> https://tarballs.openstack.org/ironic-python-agent/dib/files/ipa-centos8-master.initramfs >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - In /var/log/kolla/nova/nova-compute-ironic.log, we observed >>>>>>>>>> the error >>>>>>>>>> >>>>>>>>>> ERROR nova.compute.manager >>>>>>>>>> [req-810ffedf-3343-471c-94db-85411984e6cc - - - - -] No compute node record >>>>>>>>>> for host controller-ironic: >>>>>>>>>> nova.exception_Remote.ComputeHostNotFound_Remote: Compute host >>>>>>>>>> controller-ironic could not be found. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Can someone please help in this regard? >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Anirudh Gupta >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Jul 27, 2021 at 12:52 PM Anirudh Gupta < >>>>>>>>>> anyrude10 at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Team, >>>>>>>>>>> >>>>>>>>>>> We have deployed 2 node kolla ansible *12.0.0* in order to >>>>>>>>>>> deploy openstack *wallaby* release. We have also enabled ironic >>>>>>>>>>> in order to provision the bare metal nodes. >>>>>>>>>>> >>>>>>>>>>> On each server we have 3 nics >>>>>>>>>>> >>>>>>>>>>> - *eno1* - OAM for external connectivity and endpoint's >>>>>>>>>>> publicURL >>>>>>>>>>> - *eno2* - Mgmt for internal communication between various >>>>>>>>>>> openstack services. >>>>>>>>>>> - *ens2f0* - Data Interface >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Corresponding to this we have defined the following fields in >>>>>>>>>>> globals.yml >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> - kolla_base_distro: "centos" >>>>>>>>>>> - kolla_install_type: "source" >>>>>>>>>>> - openstack_release: "wallaby" >>>>>>>>>>> - network_interface: "eno2" # >>>>>>>>>>> MGMT interface >>>>>>>>>>> - kolla_external_vip_interface: "eno1" # OAM >>>>>>>>>>> Interface >>>>>>>>>>> - kolla_internal_vip_address: "192.168.10.3" # MGMT >>>>>>>>>>> Subnet free ip >>>>>>>>>>> - kolla_external_vip_address: "10.0.1.136" # OAM >>>>>>>>>>> subnet free IP >>>>>>>>>>> - neutron_external_interface: "ens2f0" # Data >>>>>>>>>>> Interface >>>>>>>>>>> - enable_neutron_provider_networks: "yes" >>>>>>>>>>> >>>>>>>>>>> Note: Only relevant fields are being shown in this query >>>>>>>>>>> >>>>>>>>>>> Also, for ironic following fields have been defined in >>>>>>>>>>> globals.yml >>>>>>>>>>> >>>>>>>>>>> - enable_ironic: "yes" >>>>>>>>>>> - enable_ironic_neutron_agent: "{{ enable_neutron | bool and >>>>>>>>>>> enable_ironic | bool }}" >>>>>>>>>>> - enable_horizon_ironic: "{{ enable_ironic | bool }}" >>>>>>>>>>> - ironic_dnsmasq_interface: "*ens2f0*" >>>>>>>>>>> # Data interface >>>>>>>>>>> - ironic_dnsmasq_dhcp_range: "20.20.20.10,20.20.20.100" >>>>>>>>>>> - ironic_dnsmasq_boot_file: "pxelinux.0" >>>>>>>>>>> - ironic_cleaning_network: "public1" >>>>>>>>>>> - ironic_dnsmasq_default_gateway: "20.20.20.1" >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> After successful deployment, a flat provider network with the >>>>>>>>>>> name public1 is being created in openstack using the below commands: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> - openstack network create public1 --provider-network-type >>>>>>>>>>> flat --provider-physical-network physnet1 >>>>>>>>>>> - openstack subnet create subnet1 --network public1 >>>>>>>>>>> --subnet-range 20.20.20.0/24 --allocation-pool >>>>>>>>>>> start=20.20.20.10,end=20.20.20.100 --ip-version=4 --gateway=20.20.20.1 >>>>>>>>>>> --dhcp >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Issue/Queries: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> - Is the configuration done in globals.yml correct or is >>>>>>>>>>> there anything else that needs to be done in order to separate control and >>>>>>>>>>> data plane traffic? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> - Also I have set automated_cleaning as "true" in >>>>>>>>>>> ironic-conductor conatiner settings.But after creating the baremetal node, >>>>>>>>>>> we run "node manage" command which runs successfully. Running "*openstack >>>>>>>>>>> baremetal node provide "* command powers on the >>>>>>>>>>> machine, sets the boot mode on Network Boot but no DHCP request for that >>>>>>>>>>> particular mac is obtained on the controller. Is there anything I am >>>>>>>>>>> missing that needs to be done in order to make ironic work? >>>>>>>>>>> >>>>>>>>>>> Note: I have also verified that the nic is PXE enabled in system >>>>>>>>>>> configuration setting >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> Anirudh Gupta >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Red Hat GmbH, https://de.redhat.com/ , Registered seat: >>>>>>>>> Grasbrunn, >>>>>>>>> Commercial register: Amtsgericht Muenchen, HRB 153243, >>>>>>>>> Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, >>>>>>>>> Michael O'Neill >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, >>>>>>> Commercial register: Amtsgericht Muenchen, HRB 153243, >>>>>>> Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, >>>>>>> Michael O'Neill >>>>>>> >>>>>> -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 38285 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 185546 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 200447 bytes Desc: not available URL: From jeremyfreudberg at gmail.com Fri Aug 20 14:44:09 2021 From: jeremyfreudberg at gmail.com (Jeremy Freudberg) Date: Fri, 20 Aug 2021 10:44:09 -0400 Subject: [sahara] Sahara maintenance - PTL vacancy and call for contributions Message-ID: Hi, I've worked on Sahara for a long time, especially since the Mirantis folks left. I implemented many features and fixes from 2017 through 2019 but barely anything more recently. Now it is time for me to actually move on. I don't plan to be PTL in the upcoming cycle. Sahara is not in especially good shape, given the situation with the vendors and other neglect. Help is needed, in order for Sahara to continue as a useful project. As of now I am not aware of anyone to fill the PTL role or generally contribute to the project. If you use Sahara and have interest in maintaining it, please reach out. Thanks, Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: From hberaud at redhat.com Fri Aug 20 14:51:12 2021 From: hberaud at redhat.com (Herve Beraud) Date: Fri, 20 Aug 2021 16:51:12 +0200 Subject: [release] Release countdown for week R-6, Aug 23 - Aug 27 Message-ID: In last week's email we erroneously announced that this week (August 19) would be the deadline for all non-client libraries, while only Oslo libraries were concerned. See this email for updated dates. Development Focus ----------------- Work on libraries should be wrapping up, in preparation for the various library-related deadlines coming up. Now is a good time to make decisions on deferring feature work to the next development cycle in order to be able to focus on finishing already-started feature work. General Information ------------------- We are now getting close to the end of the cycle, and will be gradually freezing feature work on the various deliverables that make up the OpenStack release. This coming week is the deadline for general libraries (except client libraries): their last feature release needs to happen before "Non-client library freeze" on August 26. Only bugfixes releases will be allowed beyond this point. When requesting those library releases, you can also include the stable/xena branching request with the review (as an example, see the "branches" section here: https://opendev.org/openstack/releases/src/branch/master/deliverables/pike/os-brick.yaml#n2 In the next weeks we will have deadlines for: * Client libraries (think python-*client libraries), which need to have their last feature release before "Client library freeze" (Sept 2nd) * Deliverables following a cycle-with-rc model (that would be most services), which observe a Feature freeze on that same date, September 2nd. Any feature addition beyond that date should be discussed on the mailing-list and get PTL approval. As we are getting to the point of creating stable/xena branches, this would be a good point for teams to review membership in their xena-stable-maint groups. Once the stable/xena branches are cut for a repo, the ability to approve any necessary backports into those branches for xena will be limited to the members of that stable team. If there are any questions about stable policy or stable team membership, please reach out in the #openstack-stable channel. Upcoming Deadlines & Dates -------------------------- Non-client library freeze: August 26 (R-6 week) Client library freeze: September 2nd (R-5 week) Xena-3 milestone: September 2nd (R-5 week) Cycle Highlights Due: September 2nd (R-5 week) Xena final release: October 6th Yeti PTG: October 18-22 -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -------------- next part -------------- An HTML attachment was scrubbed... URL: From juliaashleykreger at gmail.com Fri Aug 20 15:03:14 2021 From: juliaashleykreger at gmail.com (Julia Kreger) Date: Fri, 20 Aug 2021 08:03:14 -0700 Subject: [ironic] Not running for PTL this cycle Message-ID: Greetings everyone, I know I've repeatedly stated over the last few PTGs and midcycle sessions that I wouldn't be running this cycle, but I also realized this morning I had not sent an email. I've served as Ironic's PTL for 7 cycles, and after three and a half years, it is far past time to step down for at least a cycle. Serving the community has been a privilege and an honor, and I'm not planning on going anywhere, but a single person can only take on and handle so much stress. Changes in leadership are also a good thing as it can bring fresh perspective and voices into a project. I encourage Ironic contributors to consider if they would like to serve as the PTL, and to go ahead and submit their candidacy to the elections repository. The only thing I ask is we remain mindful of the needs of the community. I'll be there to help, to guide, and resolve conflicts if necessary. Much as Dmitry, Jim, and Aeva did before me. -Julia From whayutin at redhat.com Fri Aug 20 15:26:23 2021 From: whayutin at redhat.com (Wesley Hayutin) Date: Fri, 20 Aug 2021 09:26:23 -0600 Subject: [tripleo] Changing TripleO's release model In-Reply-To: References: Message-ID: On Fri, Jul 23, 2021 at 8:52 AM Marios Andreou wrote: > On Mon, Jul 19, 2021 at 5:50 PM Marios Andreou wrote: > > > > On Tue, Jun 8, 2021 at 6:21 PM Wesley Hayutin > wrote: > > > > > > Greetings TripleO community! > > > > > > > > > At the most recent TripleO community meetings we have discussed > formally changing the OpenStack release model for TripleO [1]. The > previous released projects can be found here [2]. TripleO has previously > released with release-type[‘trailing’, ‘cycle-with-intermediary’]. > > > > > > > > > To quote the release model doc: > > > > > > ‘Trailing deliverables trail the release, so they cannot, by > definition, be independent. They need to pick between cycle-with-rc or > cycle-with-intermediary models.’ > > > > > > > > > We are proposing to update the release-model to ‘independent’. This > would give the TripleO community more flexibility in when we choose to cut > a release. In turn this would mean less backporting, less upstream and 3rd > party resources used by potentially some future releases. > > > > > > > > > To quote the release model doc: > > > > > > ‘Some projects opt to completely bypass the 6-month cycle and release > independently. For example, that is the case of projects that support the > development infrastructure. The “independent” model describes such > projects.’ > > > > > > > > > The discussion here is to merely inform the greater community with > regards to the proposal and conversations regarding the release model. > This thread is NOT meant to discuss previous releases or their supported > status, merely changing the release model here [3] > > > > > > > > > > > > [0] https://etherpad.opendev.org/p/tripleo-meeting-items > > > > > > [1] https://releases.openstack.org/reference/release_models.html > > > > > > [2] https://releases.openstack.org/teams/tripleo.html > > > > > > [3] > https://opendev.org/openstack/releases/src/branch/master/deliverables/xena > > > > > > > > > > Hello TripleO and friends o/, > > > > It has been over a month since we first introduced this proposal in > > tripleo meetings and weshay started this thread. Now that we have > > allowed enough time for comments and debate, we’d like to re-focus on > > making a decision. > > > > The timing with this change to our release governance is critical to > > stable/xena. One of the main concerns is that CentOS-Stream-9 may not > > be fully available by the xena release. TripleO would have to carry > > both CentOS-Stream-8 and CentOS-Stream-9 across wallaby and xena and > > master, thus exploding our upstream resource consumption. The > > counterpoint to that is that we are only a few months away from xena > > releasing. > > > > As a summary and reminder the three main concerns raised in this > > thread so far were > > > > 1. What about compatibility with (rest of) openstack stable branches > > 2. How are feature freeze dates affected (& coordination with other > > projects around feature freeze) > > 3. How does it affect RDO packaging? > > > > For 2 and 3 as discussed there will be no implications; RDO has no > > plans to stop packaging for any particular branch so non tripleo > > packages will be built as usual, and, feature freeze (with respect to > > the rest of openstack) doesn’t apply for tripleo since it has always > > been trailing release. > > > > For 1 the current proposal is that we will use git tags; a range of > > tags will be designated as compatible with a given stable/release. > > Obviously this needs some more thought and establishing some rules > > (like, bumping major to signal compatibility with a new stable > > branch). To that end we will start a spec (tripleo-specs) to work out > > this and other details and allow folks to comment further. > > spec is posted there > https://review.opendev.org/c/openstack/tripleo-specs/+/801512 please > add your comments > > regards, marios > > > > > > This topic will also be raised in the IRC meeting this coming Tuesday > > 20 July [1] so please join us if you are interested in discussing any > > of the points raised here or any new ones that we missed last time, > > > > regards, marios > > > > > > [1] > http://lists.openstack.org/pipermail/openstack-discuss/2021-July/023657.html > > FYI.. TripleO is now under OpenStack's independent release model governance. Thanks for everyone's time and input :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From iurygregory at gmail.com Fri Aug 20 16:02:22 2021 From: iurygregory at gmail.com (Iury Gregory) Date: Fri, 20 Aug 2021 18:02:22 +0200 Subject: [ironic] Not running for PTL this cycle In-Reply-To: References: Message-ID: Julia, Thank you for being the PTL in the last seven cycles! (WOW, time flies!). You did an amazing job! Em sex., 20 de ago. de 2021 às 17:04, Julia Kreger < juliaashleykreger at gmail.com> escreveu: > Greetings everyone, > > I know I've repeatedly stated over the last few PTGs and midcycle > sessions that I wouldn't be running this cycle, but I also realized > this morning I had not sent an email. > > I've served as Ironic's PTL for 7 cycles, and after three and a half > years, it is far past time to step down for at least a cycle. > > Serving the community has been a privilege and an honor, and I'm not > planning on going anywhere, but a single person can only take on and > handle so much stress. Changes in leadership are also a good thing as > it can bring fresh perspective and voices into a project. > > I encourage Ironic contributors to consider if they would like to > serve as the PTL, and to go ahead and submit their candidacy to the > elections repository. > > The only thing I ask is we remain mindful of the needs of the > community. I'll be there to help, to guide, and resolve conflicts if > necessary. Much as Dmitry, Jim, and Aeva did before me. > > -Julia > > -- *Att[]'sIury Gregory Melo Ferreira * *MSc in Computer Science at UFCG* *Part of the ironic-core and puppet-manager-core team in OpenStack* *Software Engineer at Red Hat Czech* *Social*: https://www.linkedin.com/in/iurygregory *E-mail: iurygregory at gmail.com * -------------- next part -------------- An HTML attachment was scrubbed... URL: From akanevsk at redhat.com Fri Aug 20 16:05:16 2021 From: akanevsk at redhat.com (Arkady Kanevsky) Date: Fri, 20 Aug 2021 12:05:16 -0400 Subject: [ironic] Not running for PTL this cycle In-Reply-To: References: Message-ID: absolutely. Thank you very much for 3 and half great years On Fri, Aug 20, 2021 at 12:04 PM Iury Gregory wrote: > Julia, > > Thank you for being the PTL in the last seven cycles! (WOW, time flies!). > You did an amazing job! > > Em sex., 20 de ago. de 2021 às 17:04, Julia Kreger < > juliaashleykreger at gmail.com> escreveu: > >> Greetings everyone, >> >> I know I've repeatedly stated over the last few PTGs and midcycle >> sessions that I wouldn't be running this cycle, but I also realized >> this morning I had not sent an email. >> >> I've served as Ironic's PTL for 7 cycles, and after three and a half >> years, it is far past time to step down for at least a cycle. >> >> Serving the community has been a privilege and an honor, and I'm not >> planning on going anywhere, but a single person can only take on and >> handle so much stress. Changes in leadership are also a good thing as >> it can bring fresh perspective and voices into a project. >> >> I encourage Ironic contributors to consider if they would like to >> serve as the PTL, and to go ahead and submit their candidacy to the >> elections repository. >> >> The only thing I ask is we remain mindful of the needs of the >> community. I'll be there to help, to guide, and resolve conflicts if >> necessary. Much as Dmitry, Jim, and Aeva did before me. >> >> -Julia >> >> > > -- > > > *Att[]'sIury Gregory Melo Ferreira * > *MSc in Computer Science at UFCG* > *Part of the ironic-core and puppet-manager-core team in OpenStack* > *Software Engineer at Red Hat Czech* > *Social*: https://www.linkedin.com/in/iurygregory > *E-mail: iurygregory at gmail.com * > -- Arkady Kanevsky, Ph.D. Phone: 972 707-6456 Corporate Phone: 919 729-5744 ext. 8176456 -------------- next part -------------- An HTML attachment was scrubbed... URL: From juliaashleykreger at gmail.com Fri Aug 20 16:26:37 2021 From: juliaashleykreger at gmail.com (Julia Kreger) Date: Fri, 20 Aug 2021 09:26:37 -0700 Subject: [Kolla-Ansible][Ironic] Baremetal node Cleaning fails in UEFI mode, but succeeds in Legacy Bios Mode In-Reply-To: References: Message-ID: On Fri, Aug 20, 2021 at 7:07 AM Anirudh Gupta wrote: > Hi Mark, > > There was some issue with the cleaning image due to which the issue > reported in previous conversation was observed. > > This was successfully resolved. > By setting the parameter in ironic.conf file > [pxe] > uefi_ipxe_bootfile_name = ipxe-x86_64.efi > > The "node provide" command successfully executed and the node came in > "available" state. > > *In Legacy:* > When I am trying to create the server using "server create " command and a > userimage is passed in the command, the procedure is that the node will > install userimage over the network and then will be rebooted > After the reboot, it will boot up with the Hard disk and with the OS > specified in userimage. > > *In UEFI:* > When I am trying to create the server using "server create " command and a > userimage is passed in the command, the procedure of installing user image > and rebooting remains the same. > But After the reboot, despite setting the hard disk as the first > priority, it again starts booting over the network and eventually fails. > > This is very very likely an issue with the vendor's firmware. We've seen some instances where the bmc refuses to honor the request to change *or* where it is honored for a single boot operation only. In part some of this may be due to improved support in handling UEFI boot signaling where the wrong thing could occur, at least with IPMI. In order to create a fix or workaround, we need the following information: Are you using IPMI or Redfish? If your using IPMI, you should consider using Redfish. What is the hardware vendor? What is the BMC firmware version? Is the BMC set to always network boot by default completely? In UEFI, what does the machine report for the efibootmgr output. Your deployment agent logs actually have this output already in the journal. Typically /var/log/ironic/deploy_logs. We've seen some hardware act completely disjointed from the EFI NVRAM, or where it resets the EFI NVRAM when we request a one time override. Most importantly, what is the version of ironic and ironic-python-agent? > I have also tried passing the *capabilities='boot_option:local' *both in > baremetal node and flavor, but the behaviour is the same. > > Regards > Anirudh Gupta > > > > > [trim] > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Fri Aug 20 17:56:57 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Fri, 20 Aug 2021 12:56:57 -0500 Subject: [election][tc] TC Candidacy Message-ID: <17b64b5718b.e3f3af7e25103.2411694476309080608@ghanshyammann.com> Hello Everyone, I would like to announce my candidacy for another term on the Technical Committee. First of all, thanks for giving me the opportunity as the Technical Committee member in the previous terms. Apart from TC activities, I am currently a core developer in QA projects and Nova. Also, helping project-config, OpenStack zuul-jobs, Tempest plugins for bug fixes/ Tempest compatibility and in the policy-popup team to make Openstack API policy more consistent and secure. And helping with community-wide goals; because we did not have any community-wide goals for the Xena cycle, I worked on finishing the previous cycles' pending goals. I am serving as TC chair in Xena cycle. TC directions have always been valuable and help to maintain the common standards in OpenStack. In my next term, I would like to continue doing cross-project teams work to solve OpenStack's common problems. Helping secure RBAC with Lance is one of my priority targets for the Yoga cycle, and we are also proposing that as a community-wide goal. Another area I would like to focus on improving TC interaction with community leaders and Board. Apart from that, I will continue working on the activities I am currently doing as TC and help the community grow. Thank you for reading and considering my candidacy. - Ghanshyam Mann (gmann) From amy at demarco.com Fri Aug 20 18:25:22 2021 From: amy at demarco.com (Amy Marrich) Date: Fri, 20 Aug 2021 13:25:22 -0500 Subject: [ironic] Not running for PTL this cycle In-Reply-To: References: Message-ID: Julia, Thanks so much for all the hard work you've done while PTL. You've assisted countless contributors and operators during the last 3.5 years. Amy (spotz) On Fri, Aug 20, 2021 at 10:06 AM Julia Kreger wrote: > Greetings everyone, > > I know I've repeatedly stated over the last few PTGs and midcycle > sessions that I wouldn't be running this cycle, but I also realized > this morning I had not sent an email. > > I've served as Ironic's PTL for 7 cycles, and after three and a half > years, it is far past time to step down for at least a cycle. > > Serving the community has been a privilege and an honor, and I'm not > planning on going anywhere, but a single person can only take on and > handle so much stress. Changes in leadership are also a good thing as > it can bring fresh perspective and voices into a project. > > I encourage Ironic contributors to consider if they would like to > serve as the PTL, and to go ahead and submit their candidacy to the > elections repository. > > The only thing I ask is we remain mindful of the needs of the > community. I'll be there to help, to guide, and resolve conflicts if > necessary. Much as Dmitry, Jim, and Aeva did before me. > > -Julia > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ces.eduardo98 at gmail.com Fri Aug 20 21:25:14 2021 From: ces.eduardo98 at gmail.com (Carlos Silva) Date: Fri, 20 Aug 2021 18:25:14 -0300 Subject: [manila] Collab review Message-ID: Hello, Zorillas! Next Wednesday and Thursday (Aug 25th and 26th), we'll have a Manila collaborative review session, where we'll go through the code and review the following proposed features: August 25th: - Share server migration enhancements [1] - [NetApp] Share server migration through SVM Migrate [2] August 26th: - [NetApp] Add Flexgroup volume support [3] Each session is meant to take one hour, starting at 16:00PM UTC. Meeting notes and videoconference links to the share server migration enhancements meeting will be available here [4]. Meeting notes and videoconference links to the flexgroup volumes support meeting will be available here [5]. [1] https://review.opendev.org/c/openstack/manila/+/803623 [2] https://review.opendev.org/c/openstack/manila/+/803624 [3] https://review.opendev.org/c/openstack/manila/+/803622 [4] https://etherpad.opendev.org/p/server-migration-enhancements-collab-review [5] https://etherpad.opendev.org/p/flexgroups-support-collab-review Feel free to attend if you are interested and available. Hoping to see you there! Regards, Carlos Silva irc: carloss -------------- next part -------------- An HTML attachment was scrubbed... URL: From risson at cri.epita.fr Fri Aug 20 21:47:43 2021 From: risson at cri.epita.fr (Marc 'risson' Schmitt) Date: Fri, 20 Aug 2021 23:47:43 +0200 Subject: [neutron][ovn] Error when listing agents Message-ID: <20210820234743.5dabbfe3@hedgehog.lap.rsn.lama-corp.space> Hi, After ugprading to Wallaby, I get the following error when listing my agents: ``` 2021-08-20 23:42:33.466 24 ERROR neutron.api.v2.resource [req-148cc4ed-c2b1-4e33-9e0c-1a5573652e6a b867d59eb3f34e2eab684b74e2ba7e87 28d6433dd9db4e7298c84b1058ea825a - default default] index failed: No details.: AttributeError: 'Chassis_Private' object has no attribute 'hostname' 2021-08-20 23:42:33.466 24 ERROR neutron.api.v2.resource Traceback (most recent call last): 2021-08-20 23:42:33.466 24 ERROR neutron.api.v2.resource File "/var/lib/kolla/venv/lib/python3.8/site-packages/neutron/api/v2/resource.py", line 98, in resource 2021-08-20 23:42:33.466 24 ERROR neutron.api.v2.resource result = method(request=request, **args) 2021-08-20 23:42:33.466 24 ERROR neutron.api.v2.resource File "/var/lib/kolla/venv/lib/python3.8/site-packages/neutron_lib/db/api.py", line 139, in wrapped 2021-08-20 23:42:33.466 24 ERROR neutron.api.v2.resource setattr(e, '_RETRY_EXCEEDED', True) 2021-08-20 23:42:33.466 24 ERROR neutron.api.v2.resource File "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_utils/excutils.py", line 227, in __exit__ 2021-08-20 23:42:33.466 24 ERROR neutron.api.v2.resource self.force_reraise() 2021-08-20 23:42:33.466 24 ERROR neutron.api.v2.resource File "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_utils/excutils.py", line 200, in force_reraise 2021-08-20 23:42:33.466 24 ERROR neutron.api.v2.resource raise self.value 2021-08-20 23:42:33.466 24 ERROR neutron.api.v2.resource File "/var/lib/kolla/venv/lib/python3.8/site-packages/neutron_lib/db/api.py", line 135, in wrapped 2021-08-20 23:42:33.466 24 ERROR neutron.api.v2.resource return f(*args, **kwargs) 2021-08-20 23:42:33.466 24 ERROR neutron.api.v2.resource File "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_db/api.py", line 154, in wrapper 2021-08-20 23:42:33.466 24 ERROR neutron.api.v2.resource ectxt.value = e.inner_exc 2021-08-20 23:42:33.466 24 ERROR neutron.api.v2.resource File "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_utils/excutils.py", line 227, in __exit__ 2021-08-20 23:42:33.466 24 ERROR neutron.api.v2.resource self.force_reraise() 2021-08-20 23:42:33.466 24 ERROR neutron.api.v2.resource File "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_utils/excutils.py", line 200, in force_reraise 2021-08-20 23:42:33.466 24 ERROR neutron.api.v2.resource raise self.value 2021-08-20 23:42:33.466 24 ERROR neutron.api.v2.resource File "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_db/api.py", line 142, in wrapper 2021-08-20 23:42:33.466 24 ERROR neutron.api.v2.resource return f(*args, **kwargs) 2021-08-20 23:42:33.466 24 ERROR neutron.api.v2.resource File "/var/lib/kolla/venv/lib/python3.8/site-packages/neutron_lib/db/api.py", line 183, in wrapped 2021-08-20 23:42:33.466 24 ERROR neutron.api.v2.resource LOG.debug("Retry wrapper got retriable exception: %s", e) 2021-08-20 23:42:33.466 24 ERROR neutron.api.v2.resource File "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_utils/excutils.py", line 227, in __exit__ 2021-08-20 23:42:33.466 24 ERROR neutron.api.v2.resource self.force_reraise() 2021-08-20 23:42:33.466 24 ERROR neutron.api.v2.resource File "/var/lib/kolla/venv/lib/python3.8/site-packages/oslo_utils/excutils.py", line 200, in force_reraise 2021-08-20 23:42:33.466 24 ERROR neutron.api.v2.resource raise self.value 2021-08-20 23:42:33.466 24 ERROR neutron.api.v2.resource File "/var/lib/kolla/venv/lib/python3.8/site-packages/neutron_lib/db/api.py", line 179, in wrapped 2021-08-20 23:42:33.466 24 ERROR neutron.api.v2.resource return f(*dup_args, **dup_kwargs) 2021-08-20 23:42:33.466 24 ERROR neutron.api.v2.resource File "/var/lib/kolla/venv/lib/python3.8/site-packages/neutron/api/v2/base.py", line 369, in index 2021-08-20 23:42:33.466 24 ERROR neutron.api.v2.resource return self._items(request, True, parent_id) 2021-08-20 23:42:33.466 24 ERROR neutron.api.v2.resource File "/var/lib/kolla/venv/lib/python3.8/site-packages/neutron/api/v2/base.py", line 304, in _items 2021-08-20 23:42:33.466 24 ERROR neutron.api.v2.resource obj_list = obj_getter(request.context, **kwargs) 2021-08-20 23:42:33.466 24 ERROR neutron.api.v2.resource File "/var/lib/kolla/venv/lib/python3.8/site-packages/neutron/plugins/ml2/drivers/ovn/mech_driver/mech_driver.py", line 1159, in fn 2021-08-20 23:42:33.466 24 ERROR neutron.api.v2.resource return op(results, new_method(*args, _driver=self, **kwargs)) 2021-08-20 23:42:33.466 24 ERROR neutron.api.v2.resource File "/var/lib/kolla/venv/lib/python3.8/site-packages/neutron/plugins/ml2/drivers/ovn/mech_driver/mech_driver.py", line 1223, in get_agents 2021-08-20 23:42:33.466 24 ERROR neutron.api.v2.resource agent_dict = agent.as_dict() 2021-08-20 23:42:33.466 24 ERROR neutron.api.v2.resource File "/var/lib/kolla/venv/lib/python3.8/site-packages/neutron/plugins/ml2/drivers/ovn/agent/neutron_agent.py", line 55, in as_dict 2021-08-20 23:42:33.466 24 ERROR neutron.api.v2.resource 'host': self.chassis.hostname, 2021-08-20 23:42:33.466 24 ERROR neutron.api.v2.resource AttributeError: 'Chassis_Private' object has no attribute 'hostname' 2021-08-20 23:42:33.466 24 ERROR neutron.api.v2.resource ``` (pasted here: https://bin.lama-corp.space/o8Q7xYtrGtp0jSKdR8qF1) Should I open a bug report or is it something I'm doing wrong? Lookiing at the code, I see recent changes were made, which maybe introduced a bug, in which case I'd be happy to help. About the setup: neutron with OVN agents, version 18.1.1.dev7, deployed with kolla-ansible, nothing especially fancy. Thanks in advance, -- Marc 'risson' Schmitt CRI - EPITA From gmann at ghanshyammann.com Fri Aug 20 23:41:21 2021 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Fri, 20 Aug 2021 18:41:21 -0500 Subject: [all][tc] What's happening in Technical Committee: summary 20th Aug, 21: Reading: 5 min Message-ID: <17b65f0be01.bc504cb129142.403357922210830592@ghanshyammann.com> Hello Everyone, Here is this week's summary of the Technical Committee activities. 1. TC Meetings: ============ * TC held this week's IRC meeting on Aug 19th Thursday. * I am summarizing the meeting activities in the below sections (Completed or in-progress activities section). To know more details, you can check the full log @ - https://meetings.opendev.org/meetings/tc/2021/tc.2021-08-19-15.00.log.html * We will have next week's meeting on Aug 26th, Thursday 15:00 UTC[1] feel free the topic in agenda by Aug 25th. 2. What we completed this week: ========================= * Discussion on Murano project retirement[2] ** We discussed this in the TC meeting and as Rong Zhu (current PTL) confirmed to continue maintaining it we decided to drop the retirement process. 3. Activities In progress: ================== TC Tracker for Xena cycle ------------------------------ TC is using the etherpad[3] for Xena cycle working item. We will be checking and updating the status biweekly in the same etherpad. Open Reviews ----------------- * Four open reviews for ongoing activities[4]. Combined PTL/TC Election Season for Yoga ---------------------------------------------------- * The nomination period for PTL and TC elections are open, please add your nomination before the deadline[5] * Also encourage people to run for election especially for TC seats. New project application: 'Venus' -------------------------------------- * There is a new project application called 'Venus': Log management service[6]. * Governance patch is also up with all the details[7] and discussion going on. If you have any queries on this, this is the right time to ask on the ML thread or on Gerrit. Moving TC meetings to video/voice calls ------------------------------------------------ * In TC we are thinking of moving the meeting to video/voice calls. Brian also posted Cinder's monthly video call experience which was helpful, feel free to share your experience too if any. * In this week TC meeting, we agreed to try monthly video call (1st weekly meeting of every month) and based on the experience we will discuss it in PTG to make it more formal or so. * We will continue the discussion on which tool to use etc in next week's TC meeting also. Project updates ------------------- * Retiring js-openstack-lib [8] * Retire puppet-monasca[9] Yoga release community-wide goal ----------------------------------------- * Please add the possible candidates in this etherpad [10]. * Current status: Proposed "Secure RBAC" to select for Yoga cycle[11]. PTG planning ---------------- * We are collecting the PTG topics in etherpad[12], feel free to add any topic you would like to discuss. Test support for TLS default: ---------------------------------- * Rico has started a separate email thread over testing with tls-proxy enabled[13], we encourage projects to participate in that testing and help to enable the tls-proxy in gate testing. 4. How to contact the TC: ==================== If you would like to discuss or give feedback to TC, you can reach out to us in multiple ways: 1. Email: you can send the email with tag [tc] on openstack-discuss ML[14]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [15] 3. Office hours: The Technical Committee offers a weekly office hour every Tuesday at 0100 UTC [16] 4. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [2] http://lists.openstack.org/pipermail/openstack-discuss/2021-August/024263.html [3] https://etherpad.opendev.org/p/tc-xena-tracker [4] https://review.opendev.org/q/project:openstack/governance+status:open [5] http://lists.openstack.org/pipermail/openstack-discuss/2021-August/024191.html [6] http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019748.html [7] https://review.opendev.org/c/openstack/governance/+/804824 [8] https://review.opendev.org/c/openstack/governance/+/798540 [9] https://review.opendev.org/c/openstack/governance/+/805105 [10] https://etherpad.opendev.org/p/y-series-goals [11] https://review.opendev.org/c/openstack/governance/+/803783 [12] https://etherpad.opendev.org/p/tc-yoga-ptg [13] http://lists.openstack.org/pipermail/openstack-discuss/2021-June/023000.html [14] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [15] http://eavesdrop.openstack.org/#Technical_Committee_Meeting [16] http://eavesdrop.openstack.org/#Technical_Committee_Office_hours -gmann From haiwu.us at gmail.com Sat Aug 21 01:11:14 2021 From: haiwu.us at gmail.com (hai wu) Date: Fri, 20 Aug 2021 20:11:14 -0500 Subject: how to update existing vm instances 'availability_zone' field in nova database 'instances' table In-Reply-To: References: <329DDA62-FDB6-436A-8D10-90D7649D0E9E@binero.com> Message-ID: I looked further into oslo_versionedobjects. It seems it is some other library, which is not part of openstacksdk. I have no idea on how to use oslo_versionedobjects to update request_spec field for certain VM instance. The only sample code I could find online is this line: versions = ovo_base.obj_tree_get_versions('RequestSpec') Do you have any sample code to show how to use oslo_versionedobjects to update a test VM instance request_spec? On Mon, Aug 9, 2021 at 8:50 AM hai wu wrote: > > Thanks Tobias! I was wondering about this 'request_specs' table > before, and 'availability_zone' in its blob for those VMs were NULL > value IIRC, and I don't know how to update it before. I am not sure > how to use oslo_versionedobjects to update it. > > So basically there would be no way for us to use new > 'availability_zone' aggregate name later for hypervisor hosts? > > I finally worked around this issue by removing hosts from new > availability zone name, which by default put those hosts back to > `nova` zone, and that ensured the live migration process working > again. This is not ideal, but is now working. > > Thanks, > Hai > > On Sun, Aug 8, 2021 at 3:44 AM Tobias Urdin wrote: > > > > Hello, > > > > The availability_zone field in the instances object is a read-only field that doesn’t have anything to do with > > the actual scheduling of instances. This has been covered numerous of times on the mailing list here. > > > > The request_specs table in the nova API database contains the specs for when an instance was launched and > > the JSON blob there (in the spec field) includes the field availability_zone which affects scheduling. > > > > Please not that it’s not supported or recommend to update that field and if you do it should be done using oslo_versionedobjects > > even though updating it directly in the database will make it appear to work but might not be without bugs. > > > > Best regards > > > > > On 6 Aug 2021, at 21:24, hai wu wrote: > > > > > > It seems this 'AvailabilityZoneFilter' is really buggy. The > > > 'instances' table 'availability_zone' field was already updated to > > > match the target desired zone name, but 'AvailabilityZoneFilter' kept > > > rejecting the request. I already restarted nova-api, nova-conductor, > > > nova-scheduler services after updating this database field value, but > > > that's not helpful. > > > > > > In the source code in file > > > '/usr/lib/python3/dist-packages/nova/scheduler/filters/availability_zone_filter.py', > > > how does 'spec_obj' got its availability_zone value? I don't > > > understand this particular code. This issue is really frustrating .. > > > def host_passes(self, host_state, spec_obj): > > > availability_zone = spec_obj.availability_zone > > > > > > On Wed, Aug 4, 2021 at 5:11 PM hai wu wrote: > > >> > > >> Hi, > > >> > > >> How to update existing vm instances 'availability_zone' field in nova > > >> database 'instances' table? It turns out there are many VMs with > > >> default 'nova' availability zone, while the hypervisors are with > > >> another different target aggregate/availability zone name, thus live > > >> migration for these VMs are failing. > > >> > > >> The strange thing is that the 'OS-EXT-AZ:availability_zone' output > > >> from 'openstack server show VM_NAME' is showing these VMs are already > > >> with the target availibity_zone name. No idea why we have this > > >> inconsistency. > > >> > > >> Would it be ok to just update database table entry directly to set > > >> 'availility_zone' to different value for these VMs? Or there might be > > >> better alternatives I am not aware of? > > >> > > >> Thanks, > > >> Hai > > > > > From kkchn.in at gmail.com Sun Aug 22 06:38:03 2021 From: kkchn.in at gmail.com (KK CHN) Date: Sun, 22 Aug 2021 12:08:03 +0530 Subject: Windows2012 VM image importing and Instance Launch Failure In-Reply-To: References: Message-ID: yes. I too suspect this not the problem with image. I have seen the logs: it throwing Errors which pasted here. Its waiting for nova-conductor service as in the logs. Is this the issue? Do I need to explictly statrt conductor service or some other service ? nova-compute logs pasted below the lines. share your thoughts what may the issue. On Fri, Aug 20, 2021 at 8:11 AM Mohammed Naser wrote: > I suggest that you have a look at the compute node logs when it fails to > spawn. I suspect the problem is not Your images but something inside > openstack > > tail: no files remaining cloud at Meghctrl1:~$ sudo tail -f /var/log/nova/nova-compute.log [sudo] password for cloud: 2021-08-19 11:59:59.477 2847961 ERROR oslo_service.periodic_task transport_options=transport_options) 2021-08-19 11:59:59.477 2847961 ERROR oslo_service.periodic_task File "/usr/local/lib/python3.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 642, in _send 2021-08-19 11:59:59.477 2847961 ERROR oslo_service.periodic_task call_monitor_timeout) 2021-08-19 11:59:59.477 2847961 ERROR oslo_service.periodic_task File "/usr/local/lib/python3.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 531, in wait 2021-08-19 11:59:59.477 2847961 ERROR oslo_service.periodic_task message = self.waiters.get(msg_id, timeout=timeout) 2021-08-19 11:59:59.477 2847961 ERROR oslo_service.periodic_task File "/usr/local/lib/python3.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 409, in get 2021-08-19 11:59:59.477 2847961 ERROR oslo_service.periodic_task 'to messageID %s' % msg_id) 2021-08-19 11:59:59.477 2847961 ERROR oslo_service.periodic_task oslo_messaging.exceptions.MessagingTimeout: Timed out waiting for a reply to message ID 7a4e3a4acad3403a9966570cc259f7b7 2021-08-19 11:59:59.477 2847961 ERROR oslo_service.periodic_task 2021-08-19 12:00:01.467 2847961 WARNING oslo.service.loopingcall [-] Function 'nova.servicegroup.drivers.db.DbDriver._report_state' run outlasted interval by 50.03 sec 2021-08-19 12:00:34.012 2847812 WARNING nova.conductor.api [req-afca4d09-bf9c-4bbc-ae88-22008d12b978 - - - - -] Timed out waiting for nova-conductor. Is it running? Or did this service start before nova-conductor? Reattempting establishment of nova-conductor connection...: oslo_messaging.exceptions.MessagingTimeout: Timed out waiting for a reply to message ID 9f5b593361b34c8d91585c00e0514047 2021-08-19 12:00:59.480 2847961 DEBUG oslo_service.periodic_task [req-58a0e182-6e56-4695-b4db-75624ca69c7b - - - - -] Running periodic task ComputeManager._check_instance_build_time run_periodic_tasks /usr/local/lib/python3.7/dist-packages/oslo_service/periodic_task.py:211 2021-08-19 12:00:59.481 2847961 DEBUG oslo_service.periodic_task [req-58a0e182-6e56-4695-b4db-75624ca69c7b - - - - -] Running periodic task ComputeManager._sync_scheduler_instance_info run_periodic_tasks /usr/local/lib/python3.7/dist-packages/oslo_service/periodic_task.py:211 2021-08-19 12:01:01.499 2847961 WARNING oslo.service.loopingcall [-] Function 'nova.servicegroup.drivers.db.DbDriver._report_state' run outlasted interval by 50.03 sec 2021-08-19 12:01:34.040 2847812 WARNING nova.conductor.api [req-afca4d09-bf9c-4bbc-ae88-22008d12b978 - - - - -] Timed out waiting for nova-conductor. Is it running? Or did this service start before nova-conductor? Reattempting establishment of nova-conductor connection...: oslo_messaging.exceptions.MessagingTimeout: Timed out waiting for a reply to message ID e8e478be640e4ecab8a3d27c01960440 essage ID d620b1b3938e4428a0500c00df8d68ee 2021-08-19 12:27:00.387 2847961 ERROR oslo_service.periodic_task [req-58a0e182-6e56-4695-b4db-75624ca69c7b - - - - -] Error during ComputeManager._cleanup_expired_console_auth_tokens: oslo_messaging.exceptions.MessagingTimeout: Timed out waiting for a reply to message ID a493182a404242b79c8f11f8ec350e36 2021-08-19 12:27:00.387 2847961 ERROR oslo_service.periodic_task Traceback (most recent call last): 2021-08-19 12:27:00.387 2847961 ERROR oslo_service.periodic_task File "/usr/local/lib/python3.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 405, in get 2021-08-19 12:27:00.387 2847961 ERROR oslo_service.periodic_task return self._queues[msg_id].get(block=True, timeout=timeout) 2021-08-19 12:27:00.387 2847961 ERROR oslo_service.periodic_task File "/usr/local/lib/python3.7/dist-packages/eventlet/queue.py", line 322, in get 2021-08-19 12:27:00.387 2847961 ERROR oslo_service.periodic_task return waiter.wait() 2021-08-19 12:27:00.387 2847961 ERROR oslo_service.periodic_task File "/usr/local/lib/python3.7/dist-packages/eventlet/queue.py", line 141, in wait 2021-08-19 12:27:00.387 2847961 ERROR oslo_service.periodic_task return get_hub().switch() 2021-08-19 12:27:00.387 2847961 ERROR oslo_service.periodic_task File "/usr/local/lib/python3.7/dist-packages/eventlet/hubs/hub.py", line 298, in switch 2021-08-19 12:27:00.387 2847961 ERROR oslo_service.periodic_task return self.greenlet.switch() 2021-08-19 12:27:00.387 2847961 ERROR oslo_service.periodic_task _queue.Empty 2021-08-19 12:27:00.387 2847961 ERROR oslo_service.periodic_task 2021-08-19 12:27:00.387 2847961 ERROR oslo_service.periodic_task During handling of the above exception, another exception occurred: 2021-08-19 12:27:00.387 2847961 ERROR oslo_service.periodic_task 2021-08-19 12:27:00.387 2847961 ERROR oslo_service.periodic_task Traceback (most recent call last): 2021-08-19 12:27:00.387 2847961 ERROR oslo_service.periodic_task File "/usr/local/lib/python3.7/dist-packages/oslo_service/periodic_task.py", line 216, in run_periodic_tasks 2021-08-19 12:27:00.387 2847961 ERROR oslo_service.periodic_task task(self, context) 2021-08-19 12:27:00.387 2847961 ERROR oslo_service.periodic_task File "/usr/local/lib/python3.7/dist-packages/nova/compute/manager.py", line 10450, in _cleanup_expired_console_auth_tokens 2021-08-19 12:27:00.387 2847961 ERROR oslo_service.periodic_task objects.ConsoleAuthToken.clean_expired_console_auths(context) 2021-08-19 12:27:00.387 2847961 ERROR oslo_service.periodic_task File "/usr/local/lib/python3.7/dist-packages/oslo_versionedobjects/base.py", line 177, in wrapper 2021-08-19 12:27:00.387 2847961 ERROR oslo_service.periodic_task args, kwargs) 2021-08-19 12:27:00.387 2847961 ERROR oslo_service.periodic_task File "/usr/local/lib/python3.7/dist-packages/nova/conductor/rpcapi.py", line 243, in object_class_action_versions 2021-08-19 12:27:00.387 2847961 ERROR oslo_service.periodic_task args=args, kwargs=kwargs) 2021-08-19 12:27:00.387 2847961 ERROR oslo_service.periodic_task File "/usr/local/lib/python3.7/dist-packages/oslo_messaging/rpc/client.py", line 179, in call 2021-08-19 12:27:00.387 2847961 ERROR oslo_service.periodic_task transport_options=self.transport_options) 2021-08-19 12:27:00.387 2847961 ERROR oslo_service.periodic_task File "/usr/local/lib/python3.7/dist-packages/oslo_messaging/transport.py", line 128, in _send 2021-08-19 12:27:00.387 2847961 ERROR oslo_service.periodic_task transport_options=transport_options) 2021-08-19 12:27:00.387 2847961 ERROR oslo_service.periodic_task File "/usr/local/lib/python3.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 654, in send 2021-08-19 12:27:00.387 2847961 ERROR oslo_service.periodic_task transport_options=transport_options) 2021-08-19 12:27:00.387 2847961 ERROR oslo_service.periodic_task File "/usr/local/lib/python3.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 642, in _send 2021-08-19 12:27:00.387 2847961 ERROR oslo_service.periodic_task call_monitor_timeout) 2021-08-19 12:27:00.387 2847961 ERROR oslo_service.periodic_task File "/usr/local/lib/python3.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 531, in wait 2021-08-19 12:27:00.387 2847961 ERROR oslo_service.periodic_task message = self.waiters.get(msg_id, timeout=timeout) 2021-08-19 12:27:00.387 2847961 ERROR oslo_service.periodic_task File "/usr/local/lib/python3.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 409, in get 2021-08-19 12:27:00.387 2847961 ERROR oslo_service.periodic_task 'to message ID %s' % msg_id) 2021-08-19 12:27:00.387 2847961 ERROR oslo_service.periodic_task oslo_messaging.exceptions.MessagingTimeout: Timed out waiting for a reply to message ID a493182a404242b79c8f11f8ec350e36 2021-08-19 12:27:00.387 2847961 ERROR oslo_service.periodic_task 2021-08-19 12:27:01.681 2847961 DEBUG oslo_service.periodic_task [req-58a0e182-6e56-4695-b4db-75624ca69c7b - - - - -] Running periodic task ComputeManager._check_instance_build_time run_periodic_tasks /usr/local/lib/python3.7/dist-packages/oslo_service/periodic_task.py:211 2021-08-19 12:27:01.687 2847961 DEBUG oslo_service.periodic_task [req-58a0e182-6e56-4695-b4db-75624ca69c7b - - - - -] Running periodic task ComputeManager._sync_scheduler_instance_info run_periodic_tasks /usr/local/lib/python3.7/dist-packages/oslo_service/periodic_task.py:211 2021-08-19 12:27:02.368 2847961 WARNING oslo.service.loopingcall [-] Function 'nova.servicegroup.drivers.db.DbDriver._report_state' run outlasted interval by 50.03 sec Error-nov-log-file_while_sch ... e_in _horizaon_dashboard.txt Open with Displaying Error-nov-log-file_while_scheduling_Windows_VM_instance_in _horizaon_dashboard.txt. > If I was to guess it’s probably missing UEFI firmware packages :) > > On Wed, Aug 18, 2021 at 9:17 AM KK CHN wrote: > >> Error : failed to perform requested operation on instance "WindowsVM "the >> instance has error status. Please try again later [Error exceeded maximum >> number of retries. Exhausted all hosts available for retrying build >> failures for instance e3d5c095-7d26-4b1e-89d1-d1a6e20a45041 >> >> I am trying to import a WIndows2012 Single disk VM, to OpenStack Ussuri, >> with glance and Qemu KVM. >> >> In bare machine KVM I am able to import and boot this Windows VM which >> exported from rhevm hypervisor as vhdx image. >> what I have done is >> >> 1. converted this windows image from vhdx to qcow2 >> 2. root at MeghCtrol1:/home/cloud/CMOBB_APP#cirt-install --name WINDOWS >> --ram=1048 --vcups=1 --cpu host --hvm --dick >> path=BackUP2_CMAPP_disk_1_Windows_qcow2_imagefile,device=disk, >> format=qcow2,bus=virtio --graphics vnc --boot uefi >> >> This uploaded the qcow2 image of WindowsVM to KVM hypervisor and its >> working. >> >> But when I do importing to openstack unable to launch instance from >> the image . >> >> These are the steps I performed.. >> >> 1. openstack image create "WindowsVM" --file CMAPP_disk_1.qcow2 >> --disk-format qcow2 --container-format bare --public >> >> 4.openstack image set --property hw_firmware_type=uefi --property >> os_secure_boot=required WindowsVM >> >> 5.openstack image set --property hw_firmware_type=uefi --property >> hw_disk_bus=ide WindowsVM >> >> 6.openstack image show WindowsVM >> >> 7. root at dmzcloud:/home/cloud# openstack image show WindowsVM|grep >> "properties" >> | properties | hw_disk_bus='ide', hw_firmware_type='uefi', >> os_hash_algo='sha512', >> >> os_hash_value='753ee596980409e1e72d6d020c8219c56a6ada8b43f634fb575c594a245725a398e45982c0a1ad72b3fc3451cde62cceb9ff22be044863b31ecdd7893b049349', >> os_hidden='False', os_secure_boot='required', >> owner_specified.openstack.md5='', >> owner_specified.openstack.object='images/WindowsVM', >> owner_specified.openstack.sha256='' | >> root at dmzcloud:/home/cloud# >> >> >> Then I logged into horizon dashboard, from the images selected the >> imported image and try to launch the instance. With a Flavour of 550 GB >> disk, 4 vcpus and 8GB Ram .. >> >> The instance spawning ran for 30 minutes and throws the error which I >> pasted first in the right top corner of horizon dashboard. >> >> How to solve this error and boot the Windows machine successfully .. >> >> >> """ >> Error : failed to perform requested operation on instance "WindowsVM "the >> instance has error status. Please try again later [Error exceeded maximum >> number of retries. Exhausted all hosts available for retrying build >> failures for instance e3d5c095-7d26-4b1e-89d1-d1a6e20a45041 >> >> >> """ >> >> Any help highly appreciated. >> >> Kris >> >> -- > Mohammed Naser > VEXXHOST, Inc. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhangbailin at inspur.com Mon Aug 23 05:46:15 2021 From: zhangbailin at inspur.com (=?utf-8?B?QnJpbiBaaGFuZyjlvKDnmb7mnpcp?=) Date: Mon, 23 Aug 2021 05:46:15 +0000 Subject: =?utf-8?B?562U5aSNOiBbbGlzdHMub3BlbnN0YWNrLm9yZ+S7o+WPkV1bZWxlY3Rpb25d?= =?utf-8?Q?[nova][placement]_PTL_candidacy_for_Yoga?= In-Reply-To: References: <06937d73a50e7be292c64d136292d781@sslemail.net> Message-ID: <5e89a6c74f954492a0adcb5f23b96a28@inspur.com> +1 And thanks gibi, an outstanding leader. In recent release, I have contributed some feature for nova, as you said it’s now entered a period of quiet but productive pace, hoping there are many contributors join, and it will be better under your hand. Best Regards brinzhang Inspur Electronic Information Industry Co.,Ltd. 发件人: Sylvain Bauza [mailto:sylvain.bauza at gmail.com] 发送时间: 2021年8月18日 14:38 收件人: openstack-discuss 主题: [lists.openstack.org代发][election][nova][placement] PTL candidacy for Yoga Hello Nova (and Placement) fellows, That's been some time I started to work on OpenStack and Nova in particular (I leave you guessing it [1]) but I feel this is time for me to run for the Nova PTL election and ask you to accept me for this hot seat (which is not a Yoga mat). First and foremost, I'd like to thank gibi for the hard work he did on the previous cycles, especially during this (hopefully) transient situation we currently face which challenges us in terms of teamwork. Running our team gatherings virtually twice is awfully exhausting and I also thank you all for supporting this situation. Hopefully our next PTG will be the last virtual one but who knows. I personally feel Nova now entered a period of quiet but productive pace. We accepted a solid amount of blueprints over the past cycles but we also delivered a decent ratio of them. That said, many challenges occur as of now which as a PTL I have the intention to continue to stress on and engage discussions between us how to solve them : - CI stability : We recently faced a couple of bugs that prevented us to merge code and I have the feeling that some of them are intertwined. I'd like us to identify all the stressing bits so we could prioritize any kind of tech debt fix that would help to gain better stability and not treat them as just standard bugs that we only look after our feature delivery duties. - Upgrades : I'm very happy to say we solved the long-running problem of version-to-next upgrades which are now painless. We have a couple of tools for helping operators to gain confidence before upgrades and we also have CI jobs that prove their stability. That said, I personally feel we now have another dimension of upgrades we barely scratched to define and I would like us to think about them. Placement reshapes and fast-forward-upgrades are for example two new features that Nova supports but I'd like us to take a second and identify all the improvements we could make for those (and prioritize efforts accordingly) - Contributors diversity : I don't think there is any surprise if I say that our Nova community is smaller than before. I don't think it's a problem and as I already said, we're productive. No, the concern that I have is that I'd love to have a way to help contributors that are maybe not having time to develop on Nova as a primary day-to-day job. We started to discuss on ways to define review priorities and I would like to pursue this direction by wondering what and how we could do for those contributors. Either way, I truly respect the ideal of Open Design. Whatever Nova becomes or evolves in the future, every single contributor is part of it and my role will be to make sure we have a consensus. Thanks, -Sylvain [1] 0x7DD -------------- next part -------------- An HTML attachment was scrubbed... URL: From sz_cuitao at 163.com Mon Aug 23 06:32:22 2021 From: sz_cuitao at 163.com (Tommy Sway) Date: Mon, 23 Aug 2021 14:32:22 +0800 Subject: Is there a new version of FUEL available now? Message-ID: <002e01d797e8$c0124a70$4036df50$@163.com> And there to download it if exists ? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From radoslaw.piliszek at gmail.com Mon Aug 23 07:39:52 2021 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Mon, 23 Aug 2021 09:39:52 +0200 Subject: [masakari] Deprecating process monitor - querying the community in this thread In-Reply-To: References: Message-ID: Dears, I have received no "stop" feedback here nor elsewhere so I will add an official deprecation note to Masakari's release notes. -yoctozepto On Fri, Jun 18, 2021 at 6:20 PM Radosław Piliszek wrote: > > Hello users of Masakari, > > As the Masakari core team, we have discussed the > deprecation/retirement of one of the monitors - the process monitor. > The reason is simple - we consider its mission is better handled by > other software such as Kubernetes, Docker, or systemd, depending on > how you deploy your OpenStack cluster. > I believe the process monitor might have made sense in the > pre-containerisation, pre-systemd world but it does not seem to any > longer. > > Please let us know, by replying to this mail, if you have a use case > for the process monitor that cannot be handled by the aforementioned > software. > > -yoctozepto From arne.wiebalck at cern.ch Mon Aug 23 07:41:41 2021 From: arne.wiebalck at cern.ch (Arne Wiebalck) Date: Mon, 23 Aug 2021 09:41:41 +0200 Subject: [ironic] Not running for PTL this cycle In-Reply-To: References: Message-ID: <7bced356-40b1-e626-8797-2ab3985e6bba@cern.ch> Julia, The long list of added changes (major features as well as little improvements inspired by real deployments), the increasing adoption and interest, and a great community speak volumes how well Ironic has evolved under your lead. Thanks a lot for all the work and effort you put into Ironic as the PTL during these last 7 cycles! Cheers, Arne On 20.08.21 17:03, Julia Kreger wrote: > Greetings everyone, > > I know I've repeatedly stated over the last few PTGs and midcycle > sessions that I wouldn't be running this cycle, but I also realized > this morning I had not sent an email. > > I've served as Ironic's PTL for 7 cycles, and after three and a half > years, it is far past time to step down for at least a cycle. > > Serving the community has been a privilege and an honor, and I'm not > planning on going anywhere, but a single person can only take on and > handle so much stress. Changes in leadership are also a good thing as > it can bring fresh perspective and voices into a project. > > I encourage Ironic contributors to consider if they would like to > serve as the PTL, and to go ahead and submit their candidacy to the > elections repository. > > The only thing I ask is we remain mindful of the needs of the > community. I'll be there to help, to guide, and resolve conflicts if > necessary. Much as Dmitry, Jim, and Aeva did before me. > > -Julia > From skaplons at redhat.com Mon Aug 23 10:19:32 2021 From: skaplons at redhat.com (Slawek Kaplonski) Date: Mon, 23 Aug 2021 12:19:32 +0200 Subject: [neutron] Bug deputy report - week of Aug 16th Message-ID: <18922594.8ifqz4Cz7L@p1> Hi, I was Neutron bug deputy last week. Here is summary of it: **Critical** https://bugs.launchpad.net/neutron/+bug/1940243 - Neutron-tempest-plugin scenario tests - oom-killer is killing mysql process - gate failure, fix proposed https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/ 805057 **High** https://bugs.launchpad.net/neutron/+bug/1940541 - [ovn] metadata readiness check is looking for wrong uuid in chassis - Issue in stable branches only, in progress https://bugs.launchpad.net/neutron/+bug/1940071 - Neutron VPNaaS - growing memory consumption - needs investigation, https://bugs.launchpad.net/neutron/+bug/1940425 - test_live_migration_with_trunk tempest test fails due to port remains in down state - gate failure, needs assignment, **Medium** https://bugs.launchpad.net/neutron/+bug/1940074 - Neutron port bulk creation procedure ignores binding:vnic_type parameter - not assigned yet, seems like low-hanging-fruit https://bugs.launchpad.net/neutron/+bug/1940073 - "Unable to create the network. No available network found in maximum allowed attempts." during rally stress test - Unassigned, seems a bit as low-hanging-fruit for me https://bugs.launchpad.net/neutron/+bug/1940312 - Ussuri-only: Network segments are not tried out for allocation - Assigned, patch proposed already. It's stable only bug, fixed in master https://bugs.launchpad.net/neutron/+bug/1940311 - Quota engine should not retry DB operation when releasing reservation - fix proposed https:// review.opendev.org/c/openstack/neutron/+/805031 https://bugs.launchpad.net/neutron/+bug/1940617 - [ovn] metadata agent needlessly connects to ovsdb cluster leader - In progress, patch proposed https://review.opendev.org/c/openstack/neutron/+/805335 **Low** https://bugs.launchpad.net/neutron/+bug/1940086 - [api-ref] doc does not list resource_request as a field of the response of port bulk create - Needs assignment https://bugs.launchpad.net/neutron/+bug/1940790 - oslo.cache options are missing from neutron.conf generated by "tox -e genconfig" - In progress, patch proposed: https://review.opendev.org/c/openstack/neutron/+/805547 **Whishlist** https://bugs.launchpad.net/neutron/+bug/1940084 - neutron-agent causes 10m delay on start-up - assigned to slaweq https://bugs.launchpad.net/neutron/+bug/1940518 - Add network_ip_availability pagging support - assigned to ralonsoh -- Slawek Kaplonski Principal Software Engineer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From sz_cuitao at 163.com Mon Aug 23 10:59:48 2021 From: sz_cuitao at 163.com (Tommy Sway) Date: Mon, 23 Aug 2021 18:59:48 +0800 Subject: about deploy method Message-ID: <006d01d7980e$030ff320$092fd960$@163.com> Hi: For the four deployment schemes given in the official document, I have the following questions: First, is the charms deployment scheme only applicable to Ubuntu system? Second, what is the difference between kallo and Openstack-Ansible deployment? Thanks ! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot 2021-08-23 185435.png Type: image/png Size: 15569 bytes Desc: not available URL: From wodel.youchi at gmail.com Mon Aug 23 11:48:33 2021 From: wodel.youchi at gmail.com (wodel youchi) Date: Mon, 23 Aug 2021 12:48:33 +0100 Subject: Need some help to understand "Baremetal Provision Configuration" file Message-ID: Hi, I am trying to deploy openstack Wallaby. I need some help to understand the meaning of this file "Baremetal Provision Configuration" Here is the example given in the documentation : First in : https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/deployment/network_v2.html : Provision Baremetal Instances > - name: Controller > count: 3 > defaults: > networks: > - network: ctlplane > subnet: ctlplane-subnet > vif: true > - network: external > subnet: external_subnet > *- network: internalapi > subnet: internal_api_subnet01* > - network: storage > subnet: storage_subnet01 > - network: storagemgmt > subnet: storage_mgmt_subnet01 > - network: tenant > subnet: tenant_subnet01 > network_config: > template: /home/stack/nic-config/controller.j2 > default_route_network: > - external- name: Compute > count: 100 > defaults: > networks: > - network: ctlplane > subnet: ctlplane-subnet > vif: true > *- network: internalapi > subnet: internal_api_subnet02* > - network: tenant > subnet: tenant_subnet02 > - network: storage > subnet: storage_subnet02 > network_config: > template: /home/stack/nic-config/compute.j2 > > Second in : https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/provisioning/baremetal_provision.html#baremetal-provision : Baremetal Provision Configuration > - name: Controller > count: 1 > hostname_format: controller-%index% > ansible_playbooks: > - playbook: bm-deploy-playbook.yaml > defaults: > profile: control > networks: > - network: external > subnet: external_subnet > *- network: internal_api > subnet: internal_api_subnet01* > - network: storage > subnet: storage_subnet01 > - network: storage_mgmt > subnet: storage_mgmt_subnet01 > - network: tenant > subnet: tenant_subnet01 > network_config: > template: templates/multiple_nics/multiple_nics_dvr.j2 > default_route_network: > - external- name: Compute > count: 1 > hostname_format: compute-%index% > ansible_playbooks: > - playbook: bm-deploy-playbook.yaml > defaults: > profile: compute-leaf2 > networks: > *- network: internal_api > subnet: internal_api_subnet02* > - network: tenant > subnet: tenant_subnet02 > - network: storage > subnet: storage_subnet02 > network_config: > template: templates/multiple_nics/multiple_nics_dvr.j2 > > My questions : 1 - Does the name of the network have to match the name of the network (name_lower) in network_data.yaml? because there is an underscore missing in the first example 2 - What is the meaning of the numbers in the subnet name of the network "*internal_api_subnet01 *for controllers and *internal_api_subnet02 *for compute nodes" ? why a different number? What is the meaning of it? I have tried to create the *overcloud-baremetal-deployed.yaml* file several times, and every time I get errors here. Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From radoslaw.piliszek at gmail.com Mon Aug 23 13:13:39 2021 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Mon, 23 Aug 2021 15:13:39 +0200 Subject: about deploy method In-Reply-To: <006d01d7980e$030ff320$092fd960$@163.com> References: <006d01d7980e$030ff320$092fd960$@163.com> Message-ID: On Mon, Aug 23, 2021 at 1:00 PM Tommy Sway wrote: > > Hi: > > > > For the four deployment schemes given in the official document, I have the following questions: > > First, is the charms deployment scheme only applicable to Ubuntu system? Yes, this is technology from Canonical and currently it runs reliably only on Ubuntu but one could obviously port it to other systems if they needed. > Second, what is the difference between kallo and Openstack-Ansible deployment? Kolla (Greek for "glue") deploys using Docker container images (the deployment is done using Kolla Ansible). OpenStack Ansible does not use this approach and instead installs components on demand using virtual environments and (I think still? someone correct me if I'm wrong) optionally LXC. Both projects use Ansible but everything else (e.g., the approach to configuration, deployment, upgrades) differs greatly between the two of them. -yoctozepto From fungi at yuggoth.org Mon Aug 23 13:20:46 2021 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 23 Aug 2021 13:20:46 +0000 Subject: Is there a new version of FUEL available now? In-Reply-To: <002e01d797e8$c0124a70$4036df50$@163.com> References: <002e01d797e8$c0124a70$4036df50$@163.com> Message-ID: <20210823132046.2ejmdu5627puof7u@yuggoth.org> On 2021-08-23 14:32:22 +0800 (+0800), Tommy Sway wrote: > And there to download it if exists ? Fuel was officially removed from OpenStack when https://review.openstack.org/475721 merged over four years ago, by which time all continued development on it seems to have ceased anyway (there were no new changes merged to the fuel-main repository aside from a mechanical bulk edit touching its .gitreview file for the OpenDev Gerrit server name update, and one which replaced all its content with a README.rst file saying the project was abandoned). The last official release of Fuel was 11.0.0 for Ocata: https://releases.openstack.org/ocata/index.html#ocata-fuel -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From juliaashleykreger at gmail.com Mon Aug 23 13:41:23 2021 From: juliaashleykreger at gmail.com (Julia Kreger) Date: Mon, 23 Aug 2021 06:41:23 -0700 Subject: [Kolla-Ansible][Ironic] Baremetal node Cleaning fails in UEFI mode, but succeeds in Legacy Bios Mode In-Reply-To: References: Message-ID: Greetings Anirudh, If you could post your ``openstack baremetal node show `` output for a node which is in this state, where it is configured to boot from local storage, and is booting to network. Along with that, it would be helpful to understand if the machine is configured for UEFI or not. Realistically this is where using IPMI on modern hardware becomes a problem, because there is no actual standard for the signaling behavior as it relates to UEFI boot with IPMI. We encourage operators to use Redfish instead as it is clearly delineated as part of the standard. One last thing. You may want to check and update BMC and system firmware on your hardware. On Mon, Aug 23, 2021 at 12:41 AM Anirudh Gupta wrote: > > Hi Julia, > > Thanks for your reply. > > There is also an update that with Centos 8.4 Partition Disk Image, I am able to successfully provision the baremetal node. With Centos 8.4 ISO and Wholedisk Image the behaviour is the same that it doesn't boot from Hard disk. > > Please find below my setup details: > > I am using HP server DL380 Gen9 with BIOS P89 v2.76 (10/21/2019) with IPMI utility > > Hard disk is the first priority followed by 1GB NIC which I have set to PXE > > I don't find any logs in /var/log/ironic/deploy_logs. However there is a folder /var/log/kolla/ironic/, but there are no deploy_logs in that folder > > I have downloaded the kolla source image from docker hub > > docker pull kolla/centos-source-ironic-conductor:wallaby > > Similar images have been downloaded by kolla ansible for other ironic components > > Regards > Anirudh Gupta > > On Fri, Aug 20, 2021 at 9:56 PM Julia Kreger wrote: >> >> >> >> On Fri, Aug 20, 2021 at 7:07 AM Anirudh Gupta wrote: >>> >>> Hi Mark, >>> >>> There was some issue with the cleaning image due t